Browse code

doc/muxers: sort muxers by name

Stefano Sabatini authored on 2013/06/29 20:53:58
Showing 1 changed files
... ...
@@ -258,6 +258,90 @@ each of the YUV420P components. To read or write this image file format,
258 258
 specify the name of the '.Y' file. The muxer will automatically open the
259 259
 '.U' and '.V' files as required.
260 260
 
261
+@section matroska
262
+
263
+Matroska container muxer.
264
+
265
+This muxer implements the matroska and webm container specs.
266
+
267
+The recognized metadata settings in this muxer are:
268
+
269
+@table @option
270
+
271
+@item title=@var{title name}
272
+Name provided to a single track
273
+@end table
274
+
275
+@table @option
276
+
277
+@item language=@var{language name}
278
+Specifies the language of the track in the Matroska languages form
279
+@end table
280
+
281
+@table @option
282
+
283
+@item stereo_mode=@var{mode}
284
+Stereo 3D video layout of two views in a single video track
285
+@table @option
286
+@item mono
287
+video is not stereo
288
+@item left_right
289
+Both views are arranged side by side, Left-eye view is on the left
290
+@item bottom_top
291
+Both views are arranged in top-bottom orientation, Left-eye view is at bottom
292
+@item top_bottom
293
+Both views are arranged in top-bottom orientation, Left-eye view is on top
294
+@item checkerboard_rl
295
+Each view is arranged in a checkerboard interleaved pattern, Left-eye view being first
296
+@item checkerboard_lr
297
+Each view is arranged in a checkerboard interleaved pattern, Right-eye view being first
298
+@item row_interleaved_rl
299
+Each view is constituted by a row based interleaving, Right-eye view is first row
300
+@item row_interleaved_lr
301
+Each view is constituted by a row based interleaving, Left-eye view is first row
302
+@item col_interleaved_rl
303
+Both views are arranged in a column based interleaving manner, Right-eye view is first column
304
+@item col_interleaved_lr
305
+Both views are arranged in a column based interleaving manner, Left-eye view is first column
306
+@item anaglyph_cyan_red
307
+All frames are in anaglyph format viewable through red-cyan filters
308
+@item right_left
309
+Both views are arranged side by side, Right-eye view is on the left
310
+@item anaglyph_green_magenta
311
+All frames are in anaglyph format viewable through green-magenta filters
312
+@item block_lr
313
+Both eyes laced in one Block, Left-eye view is first
314
+@item block_rl
315
+Both eyes laced in one Block, Right-eye view is first
316
+@end table
317
+@end table
318
+
319
+For example a 3D WebM clip can be created using the following command line:
320
+@example
321
+ffmpeg -i sample_left_right_clip.mpg -an -c:v libvpx -metadata stereo_mode=left_right -y stereo_clip.webm
322
+@end example
323
+
324
+This muxer supports the following options:
325
+
326
+@table @option
327
+
328
+@item reserve_index_space
329
+By default, this muxer writes the index for seeking (called cues in Matroska
330
+terms) at the end of the file, because it cannot know in advance how much space
331
+to leave for the index at the beginning of the file. However for some use cases
332
+-- e.g.  streaming where seeking is possible but slow -- it is useful to put the
333
+index at the beginning of the file.
334
+
335
+If this option is set to a non-zero value, the muxer will reserve a given amount
336
+of space in the file header and then try to write the cues there when the muxing
337
+finishes. If the available space does not suffice, muxing will fail. A safe size
338
+for most use cases should be about 50kB per hour of video.
339
+
340
+Note that cues are only written if the output is seekable and this option will
341
+have no effect if it is not.
342
+
343
+@end table
344
+
261 345
 @anchor{md5}
262 346
 @section md5
263 347
 
... ...
@@ -363,6 +447,42 @@ point on IIS with this muxer. Example:
363 363
 ffmpeg -re @var{<normal input/transcoding options>} -movflags isml+frag_keyframe -f ismv http://server/publishingpoint.isml/Streams(Encoder1)
364 364
 @end example
365 365
 
366
+@section mp3
367
+
368
+The MP3 muxer writes a raw MP3 stream with an ID3v2 header at the beginning and
369
+optionally an ID3v1 tag at the end. ID3v2.3 and ID3v2.4 are supported, the
370
+@code{id3v2_version} option controls which one is used. The legacy ID3v1 tag is
371
+not written by default, but may be enabled with the @code{write_id3v1} option.
372
+
373
+For seekable output the muxer also writes a Xing frame at the beginning, which
374
+contains the number of frames in the file. It is useful for computing duration
375
+of VBR files.
376
+
377
+The muxer supports writing ID3v2 attached pictures (APIC frames). The pictures
378
+are supplied to the muxer in form of a video stream with a single packet. There
379
+can be any number of those streams, each will correspond to a single APIC frame.
380
+The stream metadata tags @var{title} and @var{comment} map to APIC
381
+@var{description} and @var{picture type} respectively. See
382
+@url{http://id3.org/id3v2.4.0-frames} for allowed picture types.
383
+
384
+Note that the APIC frames must be written at the beginning, so the muxer will
385
+buffer the audio frames until it gets all the pictures. It is therefore advised
386
+to provide the pictures as soon as possible to avoid excessive buffering.
387
+
388
+Examples:
389
+
390
+Write an mp3 with an ID3v2.3 header and an ID3v1 footer:
391
+@example
392
+ffmpeg -i INPUT -id3v2_version 3 -write_id3v1 1 out.mp3
393
+@end example
394
+
395
+To attach a picture to an mp3 file select both the audio and the picture stream
396
+with @code{map}:
397
+@example
398
+ffmpeg -i input.mp3 -i cover.png -c copy -map 0 -map 1
399
+-metadata:s:v title="Album cover" -metadata:s:v comment="Cover (Front)" out.mp3
400
+@end example
401
+
366 402
 @section mpegts
367 403
 
368 404
 MPEG transport stream muxer.
... ...
@@ -426,88 +546,19 @@ Alternatively you can write the command as:
426 426
 ffmpeg -benchmark -i INPUT -f null -
427 427
 @end example
428 428
 
429
-@section matroska
430
-
431
-Matroska container muxer.
432
-
433
-This muxer implements the matroska and webm container specs.
434
-
435
-The recognized metadata settings in this muxer are:
436
-
437
-@table @option
438
-
439
-@item title=@var{title name}
440
-Name provided to a single track
441
-@end table
442
-
443
-@table @option
444
-
445
-@item language=@var{language name}
446
-Specifies the language of the track in the Matroska languages form
447
-@end table
448
-
449
-@table @option
450
-
451
-@item stereo_mode=@var{mode}
452
-Stereo 3D video layout of two views in a single video track
453
-@table @option
454
-@item mono
455
-video is not stereo
456
-@item left_right
457
-Both views are arranged side by side, Left-eye view is on the left
458
-@item bottom_top
459
-Both views are arranged in top-bottom orientation, Left-eye view is at bottom
460
-@item top_bottom
461
-Both views are arranged in top-bottom orientation, Left-eye view is on top
462
-@item checkerboard_rl
463
-Each view is arranged in a checkerboard interleaved pattern, Left-eye view being first
464
-@item checkerboard_lr
465
-Each view is arranged in a checkerboard interleaved pattern, Right-eye view being first
466
-@item row_interleaved_rl
467
-Each view is constituted by a row based interleaving, Right-eye view is first row
468
-@item row_interleaved_lr
469
-Each view is constituted by a row based interleaving, Left-eye view is first row
470
-@item col_interleaved_rl
471
-Both views are arranged in a column based interleaving manner, Right-eye view is first column
472
-@item col_interleaved_lr
473
-Both views are arranged in a column based interleaving manner, Left-eye view is first column
474
-@item anaglyph_cyan_red
475
-All frames are in anaglyph format viewable through red-cyan filters
476
-@item right_left
477
-Both views are arranged side by side, Right-eye view is on the left
478
-@item anaglyph_green_magenta
479
-All frames are in anaglyph format viewable through green-magenta filters
480
-@item block_lr
481
-Both eyes laced in one Block, Left-eye view is first
482
-@item block_rl
483
-Both eyes laced in one Block, Right-eye view is first
484
-@end table
485
-@end table
486
-
487
-For example a 3D WebM clip can be created using the following command line:
488
-@example
489
-ffmpeg -i sample_left_right_clip.mpg -an -c:v libvpx -metadata stereo_mode=left_right -y stereo_clip.webm
490
-@end example
429
+@section ogg
491 430
 
492
-This muxer supports the following options:
431
+Ogg container muxer.
493 432
 
494 433
 @table @option
495
-
496
-@item reserve_index_space
497
-By default, this muxer writes the index for seeking (called cues in Matroska
498
-terms) at the end of the file, because it cannot know in advance how much space
499
-to leave for the index at the beginning of the file. However for some use cases
500
-index at the beginning of the file.
501
-
502
-If this option is set to a non-zero value, the muxer will reserve a given amount
503
-of space in the file header and then try to write the cues there when the muxing
504
-finishes. If the available space does not suffice, muxing will fail. A safe size
505
-for most use cases should be about 50kB per hour of video.
506
-
507
-Note that cues are only written if the output is seekable and this option will
508
-have no effect if it is not.
509
-
434
+@item -page_duration @var{duration}
435
+Preferred page duration, in microseconds. The muxer will attempt to create
436
+pages that are approximately @var{duration} microseconds long. This allows the
437
+user to compromise between seek granularity and container overhead. The default
438
+is 1 second. A value of 0 will fill all segments, making pages as large as
439
+possible. A value of 1 will effectively use 1 packet-per-page in most
440
+situations, giving a small seek granularity at the cost of additional container
441
+overhead.
510 442
 @end table
511 443
 
512 444
 @section segment, stream_segment, ssegment
... ...
@@ -728,57 +779,6 @@ ffmpeg -re -i in.mkv -codec copy -map 0 -f segment -segment_list playlist.m3u8 \
728 728
 @end example
729 729
 @end itemize
730 730
 
731
-@section mp3
732
-
733
-The MP3 muxer writes a raw MP3 stream with an ID3v2 header at the beginning and
734
-optionally an ID3v1 tag at the end. ID3v2.3 and ID3v2.4 are supported, the
735
-@code{id3v2_version} option controls which one is used. The legacy ID3v1 tag is
736
-not written by default, but may be enabled with the @code{write_id3v1} option.
737
-
738
-For seekable output the muxer also writes a Xing frame at the beginning, which
739
-contains the number of frames in the file. It is useful for computing duration
740
-of VBR files.
741
-
742
-The muxer supports writing ID3v2 attached pictures (APIC frames). The pictures
743
-are supplied to the muxer in form of a video stream with a single packet. There
744
-can be any number of those streams, each will correspond to a single APIC frame.
745
-The stream metadata tags @var{title} and @var{comment} map to APIC
746
-@var{description} and @var{picture type} respectively. See
747
-@url{http://id3.org/id3v2.4.0-frames} for allowed picture types.
748
-
749
-Note that the APIC frames must be written at the beginning, so the muxer will
750
-buffer the audio frames until it gets all the pictures. It is therefore advised
751
-to provide the pictures as soon as possible to avoid excessive buffering.
752
-
753
-Examples:
754
-
755
-Write an mp3 with an ID3v2.3 header and an ID3v1 footer:
756
-@example
757
-ffmpeg -i INPUT -id3v2_version 3 -write_id3v1 1 out.mp3
758
-@end example
759
-
760
-To attach a picture to an mp3 file select both the audio and the picture stream
761
-with @code{map}:
762
-@example
763
-ffmpeg -i input.mp3 -i cover.png -c copy -map 0 -map 1
764
--metadata:s:v title="Album cover" -metadata:s:v comment="Cover (Front)" out.mp3
765
-@end example
766
-
767
-@section ogg
768
-
769
-Ogg container muxer.
770
-
771
-@table @option
772
-@item -page_duration @var{duration}
773
-Preferred page duration, in microseconds. The muxer will attempt to create
774
-pages that are approximately @var{duration} microseconds long. This allows the
775
-user to compromise between seek granularity and container overhead. The default
776
-is 1 second. A value of 0 will fill all segments, making pages as large as
777
-possible. A value of 1 will effectively use 1 packet-per-page in most
778
-situations, giving a small seek granularity at the cost of additional container
779
-overhead.
780
-@end table
781
-
782 731
 @section tee
783 732
 
784 733
 The tee muxer can be used to write the same data to several files or any