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 colour/chroma signals).
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 transcode 0.6.13.
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...