[theora-dev] Re: YUV to RGB

Timothy B. Terriberry tterribe at email.unc.edu
Tue Jan 15 22:28:57 PST 2008

wesley kiriinya wrote:
> Instead of storing YUV in the stream I would store RGB values. The
> y_width and uv_width would be the same. I am only doing this so that I

Note that the current encoder does not support a 4:4:4 pixel format,
only 4:2:0, so uv_width is actually required to be half of y_width. The
encoder on the new thusnelda branch is halfway to full 4:4:4 support
(and the decoder has supported it for some time), but thusnelda needs
some more work before it can replace the current mainline encoder.

Theora is designed to approximate whatever values you give it, so you
_could_ set Y' to the G channel and sub-sample B and R into Cb and Cr,
respectively, but this is not likely to look all that great. Also, be
sure you use a non-linear RGB space (e.g., sRGB), and not a linear one.

200x200 is small enough that the computational load of doing the
conversion is not likely to be too bad: an entire Y'CbCr frame fits in
64K, so cache misses, usually the dominant factor, shouldn't be a problem.

Finally, note that the YUV overlay SDL uses is normally handled by the
Xv extension, which actually uses the graphics drivers to do the
conversion, often in hardware. This is part of the reason libtheora does
not provide its own conversion routines: there's usually almost always a
better method available. The other part is that such conversions are not
codec-specific, and so do not belong in a codec library. liboggplay is,
in fact, the right place for the Y'CbCr->RGB direction. We don't have a
similar layer for encoding, yet, but when we do, that's where the other
direction should go. I disagree that we should ever include one in
libtheora itself.

More information about the theora-dev mailing list