RGB Compression using x264

[ramprasad85]

Does x264 convert RGB/BGR to YUV420? or is there an error in my command line?

c:\bin>x264 -h
x264 core:120 r2120 0c7dab9
...

c:\bin>x264 rgb.avs -q 0 -o rgg.264
avs [info]: 352x288p 0:0 @ 25/1 fps (cfr)
resize [warning]: converting from bgr24 to yuv420p
[swscaler @ 01b9e280] full chroma interpolation for destination format 'yuv420p' not yet implemented
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle Cache64
x264 [info]: profile High 4:4:4 Predictive, level 1.3, 4:2:0 8-bit
...


Thanks
Ramprasad

[LoRd_MuldeR]

As far as I know, H.264 uses the YCbCr color model. Thus RGB data unavoidably has to be converted to YCbCr. You can convert it back to RGB after decoding.

Note that the color-space conversion itself is lossless (except for rounding errors), but the '4:2:0' color sub-sampling means a certain loss, compared to the original RGB source.

H.264 also supports a '4:4:4' mode (i.e. no color sub-sampling at all), but I don't think x264 does support this yet. Most H.264 decoders probably wouldn't either...

[MasterNobody]

As far as I know, H.264 uses the YCbCr color model. Thus RGB data unavoidable has to be converted to YCbCr.
Incorrect, H.264 can compress RGB more or less effectivly with 4:4:4 profile. Also there is colormatrix value in VUI for signaling RGB (GBR really).

Note that the color-space conversion itself is lossless (except for rounding errors)
That is already not lossless (and it is not only rounding errors).
H.264 also supports a '4:4:4' mode (i.e. no color sub-sampling), but I don't think x264 does support this yet. Most H.264 decoders probably wouldn't either...
Your data are outdated. Both x264 and ffmpeg/libav supports 4:4:4 (and RGB also) now.

ramprasad85
You need to use --output-csp rgb because default is i420 (lossless or lossy encoding you do indifferent)

[LoRd_MuldeR]

Incorrect, H.264 can compress RGB more or less effectivly with 4:4:4 profile. Also there is colormatrix value in VUI for signaling RGB (GBR really).

Yeah, after thinking a bit more about it, that makes sense:

If we have 3 three channels with full resolution in '4:4:4' mode anyway, we can "simply" use those to store RGB values rather than YCrCb values.

It just needs a way to signal the decoder that we use RGB (GBR). And, as you say, the VUI can do that.

That is already not lossless (and it is not only rounding errors).

How is the transform (+inverse transform) lossy, if we assume perfect/infinity precision? :confused:

Your data are outdated. Both x264 and ffmpeg/libav supports 4:4:4 (and RGB also) now.

Good to know :)

[Asmodian]

How is the transform (+inverse transform) lossy, if we assume perfect/infinity precision? :confused:

Well you cannot really assume infinite precision. ;)

But Microsoft agrees with you:

"YUV is not inherently any more compact than RGB. Unless the chroma is downsampled, a YUV pixel is the same size as an RGB pixel. Also, the conversion from RGB to YUV is not lossy. If there is no downsampling, a YUV pixel can be converted back to RGB with no loss of information."

[poisondeathray]

But Microsoft agrees with you:


Originally Posted by MSDN
"YUV is not inherently any more compact than RGB. Unless the chroma is downsampled, a YUV pixel is the same size as an RGB pixel. Also, the conversion from RGB to YUV is not lossy. If there is no downsampling, a YUV pixel can be converted back to RGB with no loss of information."




It depends on the context, because YUV to RGB can be lossy, since all possible RGB values can convert to YUV , but the reverse isn't true (they are non overlapping color models)

http://forum.doom9.org/showthread.php?t=154731

http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/ch6_color_models.html

see "RGB Colors Cube in the YUV Color Space" diagram

[LoRd_MuldeR]

Well you cannot really assume infinite precision. ;)

But Microsoft agrees with you:

That why I said the transform itself should be lossless, except for rounding errors. :)

In reality there will be some loss due to the limited precision (rounding errors), but whether these will be visible is a different question.

Also dithering could be used to minimize the problem...

YUV to RGB can be lossy, since all possible RGB values can convert to YUV , but the reverse isn't true

Still, if we start with RGB data, we can convert all possible values to YUV (actually YCbCr).

And, as these values originate from RGB values, they should map to the part of the YUV space that represents valid RGB values and thus can be converted back to RGB.

After all, this RGB -> YUV -> RGB transform should be lossless - except for the rounding errors, of course.

I see, however, that squeezing the whole RGB space into a small subset of the YUV space causes more rounding errors than using the whole range would (at fixed bpp).

[pandy]

Instead of YCbCr you may use YCoCg or unfold RGB to 3 separate grayscale combined as one image.

[ramprasad85]

Thanks to x264, FFmpeg and especially to you all



ffmpeg -i rgb.avs -frames 1 src.bmp

x264 rgb.avs -q 0 -o rgb.264 --output-csp rgb
ffmpeg -i rgb.264 -frames 1 decoded.bmp

fc /b src.bmp decoded.bmp
Comparing files src.bmp and DECODED.BMP
FC: no differences encountered

[Keiyakusha]

ramprasad85
Thanks for sharing that info.

What about compression ratio of the rgb encode, нow it is in terms of file size compared to YUV 4:4:4 and 4:2:0 encodes (yes I know it won't be lossless anymore but real visual quality difference unnoticeable so interesting to know that anyway)? Anyone did any tests?

[Zerofool]

Hi, I was wondering the same thing, and I did some tests two months ago for my own satisfaction :).
The sources were 720p RGB video-game clips. Unfortunately, I don't remember all the details (like if I did the colorspace conversion in avisynth or directly through x264, and if I retained the full-range or converted it to TV levels), but anyways, I used the same conditions for 444/420/RGB and the results were the same with all my source clips. I used the same CRF value for the encodes (I think it was 20 or 21), but probably the value scales are different for these three cases, so take the results with a pinch of salt as they say :). The 4:4:4 encodes were always smallest (surprisingly), followed by the 4:2:0 encodes (~5% bigger), and RGB encodes were last (~40% bigger than 4:4:4). And if I remember correctly, there were no decoders available at that time that could correctly decode the RGB stream... anyhow, it's probably a good idea to re-do these experiments again soon, quite a few things have changed since.

[benwaggoner]

But Microsoft agrees with you:
...assuming uncompressed, that is.

A main point of using Y'CbCr is that the HSV doesn't percieve chroma frequency nearly as precisely as it does luma frequency, so in the real world Cb and Cr can be compressed a whole lot more without visual impact, and generally have a lot less entropy in the source channels.

That's also why we can generally get away with throwing away 75% of chroma samples with 4:2:0. And why 10-bit encoding only gives 10-bit to the Y' channel. Y'CbCr is a more efficient color space for natural images.

. Where RGB is interesting in when trying to record synthetic images that use the full RGB gamut (there are colors that exist in RGB but not in Y'CbCr, the same way that Y'CbCr can have a highly saturated white, which isn't possible in RGB).

[MasterNobody]

And why 10-bit encoding only gives 10-bit to the Y' channel.
Incorrect. 10-bit encoding mean all channels are 10-bit not only luma (at least if you mean x264 10-bit encoding).

[Dark Shikari]

here RGB is interesting in when trying to record synthetic images that use the full RGB gamut (there are colors that exist in RGB but not in Y'CbCr, the same way that Y'CbCr can have a highly saturated white, which isn't possible in RGB).YCgCo

[benwaggoner]

Incorrect. 10-bit encoding mean all channels are 10-bit not only luma (at least if you mean x264 10-bit encoding).
Sorry, I was actually thinking of professional 10-bit capture codecs ala DNxHD, which are 10-bit luma and 8-bit chroma.

Hmm. I wonder where x264 would get >8-bit chroma channels from for natural images. Probably RED or something like that.

[Dark Shikari]

Sorry, I was actually thinking of professional 10-bit capture codecs ala DNxHD, which are 10-bit luma and 8-bit chroma.ffmpeg doesn't even have a pixel format for what you're describing (ergo, not a single format it supports uses it). Going by the code, both DNXHD and Prores output in 10-bit chroma and luma, making absolutely no distinction in formatting between chroma or luma, ex:

for (i = 0; i < 8; i++) {
ctx->dsp.clear_block(ctx->blocks[i]);
ctx->decode_dct_block(ctx, ctx->blocks[i], i, qscale);
}

dct_y_offset = dct_linesize_luma << 3;
dct_x_offset = 8 << shift1;
ctx->dsp.idct_put(dest_y, dct_linesize_luma, ctx->blocks[0]);
ctx->dsp.idct_put(dest_y + dct_x_offset, dct_linesize_luma, ctx->blocks[1]);
ctx->dsp.idct_put(dest_y + dct_y_offset, dct_linesize_luma, ctx->blocks[4]);
ctx->dsp.idct_put(dest_y + dct_y_offset + dct_x_offset, dct_linesize_luma, ctx->blocks[5]);

if (!(ctx->avctx->flags & CODEC_FLAG_GRAY)) {
dct_y_offset = dct_linesize_chroma << 3;
ctx->dsp.idct_put(dest_u, dct_linesize_chroma, ctx->blocks[2]);
ctx->dsp.idct_put(dest_v, dct_linesize_chroma, ctx->blocks[3]);
ctx->dsp.idct_put(dest_u + dct_y_offset, dct_linesize_chroma, ctx->blocks[6]);
ctx->dsp.idct_put(dest_v + dct_y_offset, dct_linesize_chroma, ctx->blocks[7]);
}

[benwaggoner]

ffmpeg doesn't even have a pixel format for what you're describing (ergo, not a single format it supports uses it). Going by the code, both DNXHD and Prores output in 10-bit chroma and luma, making absolutely no distinction in formatting between chroma or luma, ex:
Hmmm. I have this firmly lodged as a fact in my mind, but I've been wrong before :).

All my video books are still boxed up from my move, but I'll double check as soon as I get down to that strata of cardboard.