aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAnton Khirnov <anton@khirnov.net>2012-06-04 11:00:34 +0200
committerAnton Khirnov <anton@khirnov.net>2012-06-04 14:22:16 +0200
commit2b1f105f1b3ac5b705ef9451826f502d93b5247c (patch)
tree8c673bf25462cc92208137c32ebd40cea381329c
parenta982e5a031c9c92726593851cee7a3792e3cbed7 (diff)
downloadffmpeg-2b1f105f1b3ac5b705ef9451826f502d93b5247c.tar.gz
doc/avconv: add some details about the transcoding process.
-rw-r--r--doc/avconv.texi120
1 files changed, 120 insertions, 0 deletions
diff --git a/doc/avconv.texi b/doc/avconv.texi
index 2ebfe9fe44..776a326369 100644
--- a/doc/avconv.texi
+++ b/doc/avconv.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{avconv} 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{avconv} 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{avconv} 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{avconv} can process raw audio and video frames using
+filters from the libavfilter library. Several chained filters form a filter
+graph. @command{avconv} 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{avconv} 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