Unless you're doing some pass-through (i.e. no re-encoding at all),|
transcode decodes the video you supply to a raw format (i.e. fixed
length frames, a pixel is always represented by a fixed number of bits,
no compression whatsoever) and then the raw format is encoded (again).
It would be logical to choose RGB24 (three bytes per pixel, one for red,
one for green and for blue, like your monitor works) for the raw format.
That's indeed possible (--use-rgb) but not recommended for most video
codecs. That has to do with the way the human eye works, it's much more
sensitive for difference in amount of light (= luminance) than the
actual colour of the light (= chrominance). This fact is used by all
video codecs, so more bits are used for luminance ("luma") than
chrominance ("chroma"). This trick was already used back in the analogue
days, with all of PAL, NTSC and SECAM.
The difference in the amount of bits used for chroma versus luma AND the
order these bits are in, makes the colour format / colour format. Within
transcode it's sometimes wrongly called "codec", you should forget that.
Back to the old days again. In NTSC and PAL terminology, three "signals"
are bound together to make the final colour signal. These are (again)
not R, G and B, but signals called Y, U and V.
You start with the luma signal which is simply (R + G + B) / 3, in other
words, a black and white signal. Then the DIFFERENCE between the luma
and the R signal is calculated which makes Cr (= component red) and
between the luma and the B signal, which makes Cb (= component blue). So
you end up with three signals luma and Cb/Cr, which sort of carry the
information what colour to show. Depending on what colour standard
(PAL/NTSC/SECAM) is used, some transformations are applied to these
signal (e.g. for spreading the bandwidth evenly) and after that, the
signals are called Y (which is still luma) and U/V (which are the
Modern digital signal actually has nothing to do with YUV because they
are signals that are defined for analogue transmission. But some reason
people always stick to terms they already know, so now YUV is used to
describe the fact that an image consists of (luma, chroma, chroma) pairs
instead of (r,g,b) pairs. YCrCb would be the proper name btw.
Then, dependant on how the bits are spread over the Y, Cr and Cb parts
of the pixels AND the layout that is used for the whole frame,
determines the name of the format.
Two popular YUV formats, which transcode can handle, are YUV420 (aka
YV12) and YUV422 (aka uyuv).
YUV420 means that for every four luma (Y) bytes there are two chroma
bytes (alternating Cr and Cb)
YUV422 means that for every luma byte there is one chroma byte
(alternating Cr and Cb).
So, YUV420 makes the smallest frames while YUV422 makes better quality
in chroma resolution.
Most encoders (like standard mpeg1/2/4) use YUV420 though, because it's
good enough most of the time. So that's why we made it default for
In some situations you are in a position that your transcode import
plugin/decoder can supply YUV422 data with actual better quality than
YUV420 (i.e. it's not converted YUV420) AND your transcode export
plugin/encode can handle YUV422 data natively (i.e. not with conversion
to YUV420). In that case it would be a waste to convert from YUV422 to
YUV420 to YUV422 (both qualitywise and speedwise), which transcode might
do. In that case you specify --uyuv to transcode and transcode will work
with YUV422 raw frames internally instead of YUV420.
Most of the time the default YUV420 will be the correct choice though.
AFAIK there is only one codec that insists on delivering RGB raw data,
and that's ImageMagick. If you want to use that, you must add --use-rgb
on the command line, to switch to the RGB raw format.
> Homework: google for "packed versus planar" and "progressive versus
> interlaced" ;-)
I gotta get to this...