Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th December 2011, 20:51   #1  |  Link
ramprasad85
Registered User
 
Join Date: Oct 2008
Location: Chennai India
Posts: 31
RGB Compression using x264

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
ramprasad85 is offline   Reply With Quote
Old 18th December 2011, 21:02   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,205
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...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 18th December 2011 at 21:39.
LoRd_MuldeR is offline   Reply With Quote
Old 18th December 2011, 21:40   #3  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 533
Quote:
Originally Posted by LoRd_MuldeR View Post
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).
Quote:
Originally Posted by LoRd_MuldeR View Post
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).
Quote:
Originally Posted by LoRd_MuldeR View Post
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)
MasterNobody is offline   Reply With Quote
Old 18th December 2011, 23:23   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,205
Quote:
Originally Posted by MasterNobody View Post
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.

Quote:
Originally Posted by MasterNobody View Post
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?

Quote:
Originally Posted by MasterNobody View Post
Your data are outdated. Both x264 and ffmpeg/libav supports 4:4:4 (and RGB also) now.
Good to know
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 18th December 2011 at 23:25.
LoRd_MuldeR is offline   Reply With Quote
Old 19th December 2011, 03:05   #5  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,198
Quote:
Originally Posted by LoRd_MuldeR View Post
How is the transform (+inverse transform) lossy, if we assume perfect/infinity precision?
Well you cannot really assume infinite precision.

But Microsoft agrees with you:
Quote:
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."
Asmodian is online now   Reply With Quote
Old 19th December 2011, 05:03   #6  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,605
Quote:
Originally Posted by Asmodian View Post
But Microsoft agrees with you:

Quote:
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/prod...or_models.html

see "RGB Colors Cube in the YUV Color Space" diagram
poisondeathray is offline   Reply With Quote
Old 19th December 2011, 16:06   #7  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,205
Quote:
Originally Posted by Asmodian View Post
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...

Quote:
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).
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 19th December 2011 at 18:24.
LoRd_MuldeR is offline   Reply With Quote
Old 20th December 2011, 13:33   #8  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,044
Instead of YCbCr you may use YCoCg or unfold RGB to 3 separate grayscale combined as one image.
pandy is offline   Reply With Quote
Old 23rd December 2011, 22:50   #9  |  Link
ramprasad85
Registered User
 
Join Date: Oct 2008
Location: Chennai India
Posts: 31
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
ramprasad85 is offline   Reply With Quote
Old 24th December 2011, 00:18   #10  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,578
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?
Keiyakusha is offline   Reply With Quote
Old 26th December 2011, 01:17   #11  |  Link
Zerofool
VR, 3D & HDR UHD fan
 
Join Date: Mar 2006
Location: Sofia, Bulgaria
Posts: 53
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.
Zerofool is offline   Reply With Quote
Old 3rd January 2012, 23:25   #12  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,730
Quote:
Originally Posted by Asmodian View Post
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).
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd January 2012, 23:38   #13  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 533
Quote:
Originally Posted by benwaggoner View Post
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).
MasterNobody is offline   Reply With Quote
Old 3rd January 2012, 23:58   #14  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Quote:
Originally Posted by benwaggoner View Post
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
Dark Shikari is offline   Reply With Quote
Old 4th January 2012, 01:55   #15  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,730
Quote:
Originally Posted by MasterNobody View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th January 2012, 02:11   #16  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Quote:
Originally Posted by benwaggoner View Post
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:

Code:
    for (i = 0; i < 8; i++) {
        ctx->dsp.clear_block(ctx->blocks[i]);
        ctx->decode_dct_block(ctx, ctx->blocks[i], i, qscale);
    }
Code:
    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]);
    }
Dark Shikari is offline   Reply With Quote
Old 10th January 2012, 21:18   #17  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,730
Quote:
Originally Posted by Dark Shikari View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.