Conversion Matrices

[Seth Willits]

After a bit of digging, it appears to me that libyuv only does conversion from RGB<->YUV using the BT.601 conversion matrices? I don't see a way to use BT.709. At least with the C routines (I assume the SSE and Neon versions use the same coefficients), it boils down to RGBToY/U/V inside of row_common.cc, which uses BT.601 conversion.

[Frank Barchard]

Correct.

The rationale is libyuv is intended for webcam formats converted to I420 BT.601 for video codecs such as H264 and VP8.

The exception being MJPG as a webcam format is BT.709.   But noone has noticed :-)

The C, Neon and SSSE3 use the same coeffecients, but there are minor differences in subsampling and fixed point accuracy.

Is it important that BT.709 to/from RGB also be supported?

[Seth Willits]

I am not familiar enough with the webcam side of things, but wouldn't HD cameras be producing BT.709 buffers anyway? Or is libyuv intended only for the sub-HD resolution cameras which I presume would then be using BT.601?

In my case, I have HD resolution (and higher) buffers natively in RGB using the BT.709 primaries and transfer function, and I need to pass them along in 8 bit 422 to H264 etc. For HD video, that's a pretty typical path I'd think.

Additionally, one of my specific interesting needs is the ability to do conversion to and from full range YUV, in addition to the normal video range. Looking around I found another project called PixFC which comes close but unfortunately is GPL and the full range conversion is only in BT.601. 

While I've done some coding with SSE before, I've only been using the intrinsics because my assembly skills are virtually nil, so I'm not sure how much good will come of me digging around in the libyuv code myself to see if I could hack something up.

[Frank Barchard]

On Sun, Nov 18, 2012 at 12:11 PM, Seth Willits <fre...@gmail.com> wrote:

I am not familiar enough with the webcam side of things, but wouldn't HD cameras be producing BT.709 buffers anyway? Or is libyuv intended only for the sub-HD resolution cameras which I presume would then be using BT.601?

In my case, I have HD resolution (and higher) buffers natively in RGB using the BT.709 primaries and transfer function, and I need to pass them along in 8 bit 422 to H264 etc. For HD video, that's a pretty typical path I'd think.

BT.709 only applies to YUV.

If you have RGB and need to convert to 422 for H264 etc, the YUV is BT.601.

Additionally, one of my specific interesting needs is the ability to do conversion to and from full range YUV, in addition to the normal video range. Looking around I found another project called PixFC which comes close but unfortunately is GPL and the full range conversion is only in BT.601. 

Full range is BT.709.  Its not supported by H264/VP8 etc?

Sounds like you want to convert from RGB to BT,709 with LGPL code

I've entered a bug

http://code.google.com/p/libyuv/issues/detail?id=159

[Seth]

 

BT.709 only applies to YUV.

If you have RGB and need to convert to 422 for H264 etc, the YUV is BT.601.

Rec 709 specifies the primaries color space as well as the conversion matrix for RGB<-->YCbCr. The RGB data I have is already color matched to be in Rec 709's colorspace. That is, you can imagine this a frame in full YCbCr Rec 709 glory, that was then converted to RGB. Everything about is 709 but it's simply in RGB form. (And now I want to convert it to full range YCbCr using the matrix in Rec 709.) Additionally, H264 certainly does not require BT.601. It has support for many colorspaces, and certainly now the most popular one is that used by HD video - Rec 709.

 

Additionally, one of my specific interesting needs is the ability to do conversion to and from full range YUV, in addition to the normal video range. Looking around I found another project called PixFC which comes close but unfortunately is GPL and the full range conversion is only in BT.601. 

Full range is BT.709.  Its not supported by H264/VP8 etc?

Mmm... I think you misunderstood what I said, and looking at the bug report you filed I think you're missing something else as well.

PixFC's conversion from RGB to full range YCbCr is done with the 601 matrix. There's no option to use 709's. It is completely possible to do it with both. "Full range" is not specific to 601 or 709. Both specify the digital 8 bit video range (16-235/240). Both can certainly be in full range by simply not using the video range.  Also, I'm not involving either H264 or VP8 etc here, but H264 does support full range values when the video_full_range_flag bit is set.

Basically, I'm coming from the expectation that libyuv would be an all-encompassing general purpose library for converting from RGB to YCbCr (and back) using either the SD or HD matrices, in either full or video range, as well as handling subsampling (444, 422, 420 etc), and multiple formats (uyvy vs yuyv, planar vs interleaved etc). It's clear to me now that libyuv started with a particular purpose, and the specific needs I have libyuv doesn't (yet?) implement.

 

Sounds like you want to convert from RGB to BT,709 with LGPL code

I've entered a bug

http://code.google.com/p/libyuv/issues/detail?id=159

I've made comments on this report, but for conversation's sake:

libjpeg does not use BT.709, it uses BT.601, but it does indeed use full range values. Y Cb and Cr all use the full range of 0-255, with 128 being "0" for Cb and Cr. 

[Frank Barchard]

libyuv aims for realtime conversions and scaling to/from YUV in support of WebRTC and Hangouts.

Would you be able to provide/adapt the C versions to an api and matrix you're expecting?

I expect its very similar code to the current ARGBToI420 and I420ToARGB, in row_common.cc, convert.cc and convert_from.cc.

From there, I could optimize it to SSSE3 and Neon.  They may be able to share code, if the matrix is supplied.