diff options
author | Michael Niedermayer <michaelni@gmx.at> | 2012-06-04 22:54:15 +0200 |
---|---|---|
committer | Michael Niedermayer <michaelni@gmx.at> | 2012-06-04 22:59:32 +0200 |
commit | 944d049eaa1ca829d97c2877ec9524c049148e14 (patch) | |
tree | 472292bb64fb4b786c5c2bd22835f9bdb0f227b5 /doc/ffmpeg.texi | |
parent | df03ae8dd80b28e0461611709e290bc61db3cdca (diff) | |
parent | 41e9682af22336bd08a5906629731c0c32aa00c6 (diff) | |
download | ffmpeg-944d049eaa1ca829d97c2877ec9524c049148e14.tar.gz |
Merge remote-tracking branch 'qatar/master'
* qatar/master:
movenc: Write chan atom for all audio tracks in mov mode movies.
mpegtsenc: use avio_open_dyn_buf(), zero pointers after freeing
doc/avconv: add some details about the transcoding process.
avidec: make scale and rate unsigned.
avconv: check output stream recording time before each frame returned from filters
avconv: split selecting input file out of transcode().
avconv: split checking for active outputs out of transcode().
avfiltergraph: make some functions static.
Conflicts:
ffmpeg.c
libavfilter/avfiltergraph.c
libavfilter/internal.h
libavformat/mpegtsenc.c
tests/ref/fate/acodec-alac
tests/ref/fate/acodec-pcm-s16be
tests/ref/fate/acodec-pcm-s24be
tests/ref/fate/acodec-pcm-s32be
tests/ref/fate/acodec-pcm-s8
tests/ref/lavf/mov
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Diffstat (limited to 'doc/ffmpeg.texi')
-rw-r--r-- | doc/ffmpeg.texi | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index e6d2aac244..9f68bc8b90 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@ -79,6 +79,126 @@ The format option may be needed for raw input files. @c man end DESCRIPTION +@chapter Detailed description +@c man begin DETAILED DESCRIPTION + +The transcoding process in @command{ffmpeg} for each output can be described by +the following diagram: + +@example + _______ ______________ _________ ______________ ________ +| | | | | | | | | | +| input | demuxer | encoded data | decoder | decoded | encoder | encoded data | muxer | output | +| file | ---------> | packets | ---------> | frames | ---------> | packets | -------> | file | +|_______| |______________| |_________| |______________| |________| + +@end example + +@command{ffmpeg} calls the libavformat library (containing demuxers) to read +input files and get packets containing encoded data from them. When there are +multiple input files, @command{ffmpeg} tries to keep them synchronized by +tracking lowest timestamp on any active input stream. + +Encoded packets are then passed to the decoder (unless streamcopy is selected +for the stream, see further for a description). The decoder produces +uncompressed frames (raw video/PCM audio/...) which can be processed further by +filtering (see next section). After filtering the frames are passed to the +encoder, which encodes them and outputs encoded packets again. Finally those are +passed to the muxer, which writes the encoded packets to the output file. + +@section Filtering +Before encoding, @command{ffmpeg} can process raw audio and video frames using +filters from the libavfilter library. Several chained filters form a filter +graph. @command{ffmpeg} distinguishes between two types of filtergraphs - +simple and complex. + +@subsection Simple filtergraphs +Simple filtergraphs are those that have exactly one input and output, both of +the same type. In the above diagram they can be represented by simply inserting +an additional step between decoding and encoding: + +@example + _________ __________ ______________ +| | | | | | +| decoded | simple filtergraph | filtered | encoder | encoded data | +| frames | -------------------> | frames | ---------> | packets | +|_________| |__________| |______________| + +@end example + +Simple filtergraphs are configured with the per-stream @option{-filter} option +(with @option{-vf} and @option{-af} aliases for video and audio respectively). +A simple filtergraph for video can look for example like this: + +@example + _______ _____________ _______ _____ ________ +| | | | | | | | | | +| input | ---> | deinterlace | ---> | scale | ---> | fps | ---> | output | +|_______| |_____________| |_______| |_____| |________| + +@end example + +Note that some filters change frame properties but not frame contents. E.g. the +@code{fps} filter in the example above changes number of frames, but does not +touch the frame contents. Another example is the @code{setpts} filter, which +only sets timestamps and otherwise passes the frames unchanged. + +@subsection Complex filtergraphs +Complex filtergraphs are those which cannot be described as simply a linear +processing chain applied to one stream. This is the case e.g. when the graph has +more than one input and/or output, or when output stream type is different from +input. They can be represented with the following diagram: + +@example + _________ +| | +| input 0 |\ __________ +|_________| \ | | + \ _________ /| output 0 | + \ | | / |__________| + _________ \| complex | / +| | | |/ +| input 1 |---->| filter |\ +|_________| | | \ __________ + /| graph | \ | | + / | | \| output 1 | + _________ / |_________| |__________| +| | / +| input 2 |/ +|_________| + +@end example + +Complex filtergraphs are configured with the @option{-filter_complex} option. +Note that this option is global, since a complex filtergraph by its nature +cannot be unambiguously associated with a single stream or file. + +A trivial example of a complex filtergraph is the @code{overlay} filter, which +has two video inputs and one video output, containing one video overlaid on top +of the other. Its audio counterpart is the @code{amix} filter. + +@section Stream copy +Stream copy is a mode selected by supplying the @code{copy} parameter to the +@option{-codec} option. It makes @command{ffmpeg} omit the decoding and encoding +step for the specified stream, so it does only demuxing and muxing. It is useful +for changing the container format or modifying container-level metadata. The +diagram above will in this case simplify to this: + +@example + _______ ______________ ________ +| | | | | | +| input | demuxer | encoded data | muxer | output | +| file | ---------> | packets | -------> | file | +|_______| |______________| |________| + +@end example + +Since there is no decoding or encoding, it is very fast and there is no quality +loss. However it might not work in some cases because of many factors. Applying +filters is obviously also impossible, since filters work on uncompressed data. + +@c man end DETAILED DESCRIPTION + @chapter Stream selection @c man begin STREAM SELECTION |