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 8th June 2013, 01:33   #1  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
x264 rgb vs i444 - What's the difference?

Hello!
Probably a noob question. I was wondering what's difference between using "--output-csp rgb" and "--output-csp i444 --range PC"?
Apart from the fact that the latter is about half the size, while all other settings are the same. What does rgb mean? If I understand correctly the h.264 format can't encode into rgb.
mzso is offline   Reply With Quote
Old 8th June 2013, 01:45   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,900
Well, "i444" stands for YUV 4:4:4, I think, while "rgb" stands for, well, RGB.

While the YUV 4:4:4 format is similar, in a way, to the RGB format in that it does not subsample the chroma and takes the same number of bits per pixel (as "raw" data), YUV (YCbCr) and RGB still a two different ways of storing "color" information.

Also I think x264 does support encoding in the RGB (or BGR) format for quite a while now:
http://git.videolan.org/?p=x264.git;...edda65db0e6aea

(I think encoding in RGB might be less efficient than YCbCr, because the latter decorrelates the "chromaticity" and "brightness" information. Maybe also related to what the CABAC contexts are optimized/designed for?)
__________________
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; 8th June 2013 at 02:05.
LoRd_MuldeR is offline   Reply With Quote
Old 8th June 2013, 02:50   #3  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 649
Quote:
Originally Posted by mzso View Post
If I understand correctly the h.264 format can't encode into rgb.
It can. There's colormatrix BGR with coefficients like:
Y = B
Cb = G
Cr = R
You can even use subsampling (though it doesn't make any sense), 10+ bit depth and so on...

Technically, for x264 the only difference is --colormatrix (GBR vs undef, which would default to Rec709 for HD, but x264 would use Rec601 for rgb -> yuv conversion. That's why you should perform rgb -> yuv conversion using avisynth).
RGB encoding is very inefficient, at least because you can't increase chroma quantizer (well, you can, but result will be weird). I think the only reason to use it is for lossless encoding. But even in that case 10-bit YCgCo could be more efficient.

So if you want to lossy encode your fraps video I would recommend using 10-bit 4:4:4 YUV.

Last edited by vivan; 8th June 2013 at 03:14.
vivan is offline   Reply With Quote
Old 8th June 2013, 12:13   #4  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by vivan View Post
It can. There's colormatrix BGR with coefficients like:
Y = B
Cb = G
Cr = R
You can even use subsampling (though it doesn't make any sense), 10+ bit depth and so on...

Technically, for x264 the only difference is --colormatrix (GBR vs undef, which would default to Rec709 for HD, but x264 would use Rec601 for rgb -> yuv conversion. That's why you should perform rgb -> yuv conversion using avisynth).
RGB encoding is very inefficient, at least because you can't increase chroma quantizer (well, you can, but result will be weird). I think the only reason to use it is for lossless encoding. But even in that case 10-bit YCgCo could be more efficient.

So if you want to lossy encode your fraps video I would recommend using 10-bit 4:4:4 YUV.
Ok. So from a user viewpoint i444 would be more efficient but I can't use it because the colors will be borked?

Quote:
Originally Posted by LoRd_MuldeR View Post
While the YUV 4:4:4 format is similar, in a way, to the RGB format in that it does not subsample the chroma and takes the same number of bits per pixel (as "raw" data)
Well, 4:4:4 doesn't subsample either otherwise it wouldn't be 4:4:4.

Quote:
Originally Posted by LoRd_MuldeR View Post
Also I think x264 does support encoding in the RGB (or BGR) format for quite a while now:
http://git.videolan.org/?p=x264.git;...edda65db0e6aea
I thought the format was pretty much yuv only.

Quote:
Originally Posted by LoRd_MuldeR View Post
(I think encoding in RGB might be less efficient than YCbCr, because the latter decorrelates the "chromaticity" and "brightness" information. Maybe also related to what the CABAC contexts are optimized/designed for?)
This makes sense then.
mzso is offline   Reply With Quote
Old 8th June 2013, 12:24   #5  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
One more thing. The x264 help claims that "--range" is not used by the encoder but the end result is different the pc range encode results in a somewhat larger output file and also the color is full range (verified with madvr) while without it it's limited range.
mzso is offline   Reply With Quote
Old 8th June 2013, 12:29   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by mzso View Post
Ok. So from a user viewpoint i444 would be more efficient but I can't use it because the colors will be borked?
I have no idea where this idea came from, but the colors in YUV mode are not "borked" in any way I can think of.

Quote:
Originally Posted by mzso View Post
I thought the format was pretty much yuv only.
Nope, it's not.

Quote:
Originally Posted by mzso View Post
One more thing. The x264 help claims that "--range" is not used by the encoder but the end result is different the pc range encode results in a somewhat larger output file and also the color is full range (verified with madvr) while without it it's limited range.
--range affects the output range used by the YUV conversion process. If you're trying to make x264 assume the input is a particular range, you might want to look at --input-range.
Dark Shikari is offline   Reply With Quote
Old 8th June 2013, 14:03   #7  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by Dark Shikari View Post
I have no idea where this idea came from, but the colors in YUV mode are not "borked" in any way I can think of.
Well, the output is wrong. (maybe it's lightness) How would you say it then? Any way to make the output look "right", without using another program? (People suggested using avisynth)

Quote:
Originally Posted by Dark Shikari View Post
--range affects the output range used by the YUV conversion process. If you're trying to make x264 assume the input is a particular range, you might want to look at --input-range.
That's cool, but it's in the VUI section in the help, where it's stated: "The VUI settings are not used by the encoder but are merely suggestions to the playback equipment." So this isn't true.
mzso is offline   Reply With Quote
Old 8th June 2013, 14:15   #8  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,900
The "--input-range" is under the input/output options (not VUI) and it's used by x264 to handle colorspace conversions of the input, before the actual encoding.

At the same time "--range" is used to indicate the range that the decoder shall use for any colorspace conversions that may be required after decompressing the video.

As x264 is not involved in the decoding process, all it can do is write the desired "--range" into the VUI and hope that the decoder will take care of that...

(BTW: If you get any "wrong" colors with YUV 4:4:4 then there obviously is at least one "wrong" YUV/RGB conversion somewhere between your original RGB video that you feed into x264 and the final RGB output you get to see on the screen when watching the encoded video. There are many places where this can happen, including the encoder, the decoder and the video renderer)
__________________
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; 8th June 2013 at 14:23.
LoRd_MuldeR is offline   Reply With Quote
Old 8th June 2013, 14:38   #9  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by LoRd_MuldeR View Post
The "--input-range" is under the input/output options (not VUI) and it's used by x264 to handle colorspace conversions of the input, before the actual encoding.
Really? This wasn't clear at all from the former comments.
Quote:
Originally Posted by LoRd_MuldeR View Post
At the same time "--range" is used to indicate the range that the decoder shall use for any colorspace conversions that may be required after decompressing the video.

As x264 is not involved in the decoding process, all it can do is write the desired "--range" into the VUI and hope that the decoder will take care of that...

(BTW: If you get any "wrong" colors with YUV 4:4:4 then there obviously is at least one "wrong" YUV/RGB conversion somewhere between your original RGB video that you feed into x264 and the final RGB output you get to see on the screen when watching the encoded video. There are many places where this can happen, including the encoder, the decoder and the video renderer)
DS just said that it "affects the output range used by the YUV conversion" and not just specify the range. Also with --range PC the output is like 13% larger.


I guess I'll try forcing "--input-range"
mzso is offline   Reply With Quote
Old 8th June 2013, 14:39   #10  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by mzso View Post
That's cool, but it's in the VUI section in the help, where it's stated: "The VUI settings are not used by the encoder but are merely suggestions to the playback equipment." So this isn't true.
The conversion process is not part of the encoder. The range flag indeed does not affect the encoding process, but it does affect the conversion process if your input needs to be converted first by swscale.

Also, I kind of wrote the code. If the documentation says otherwise, the documentation is probably wrong. That particular line dates to around half a decade before x264cli even had the ability to perform colorspace conversion.
Dark Shikari is offline   Reply With Quote
Old 8th June 2013, 14:41   #11  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by Dark Shikari View Post
The conversion process is not part of the encoder. The range flag indeed does not affect the encoding process, but it does affect the conversion process if your input needs to be converted first by swscale.

Also, I kind of wrote the code. If the documentation says otherwise, the documentation is probably wrong. That particular line dates to around half a decade before x264cli even had the ability to perform colorspace conversion.
Ok, now I'm getting confused. So I get different file sizes because different color space conversion and so different input to the actual encoding process?

Anyway I just pointed out a conflict with help text, I'm sure what you say is valid.

Last edited by mzso; 8th June 2013 at 14:46.
mzso is offline   Reply With Quote
Old 8th June 2013, 14:51   #12  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Yup: there's four possible outputs of the conversion process:

1. Assume input is full range (--input-range), convert to full range (--range).
2. Assume input is full range, convert to limited range.
3. Assume input is limited range, convert to full range.
4. Assume input is limited range, convert to limited range.

The encoder then encodes the resulting stream and flags it based on --range. So based on which conversion is done, the output might be different. The "doesn't affect output" can be seen with cases 1 and 4: no conversion is done here, so the encoder will get the same input no matter what you do, so the output should be the same.
Dark Shikari is offline   Reply With Quote
Old 8th June 2013, 15:18   #13  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,900
Quote:
Originally Posted by mzso View Post
Really? This wasn't clear at all from the former comments.

DS just said that it "affects the output range used by the YUV conversion" and not just specify the range. Also with --range PC the output is like 13% larger.
I think I was missing one point: The color conversion performed by x264 prior to the encoding is influenced by both, "--input-range" and "--range".

Still the value of "--range" (and only that one) also needs to be written into the VUI and we have to hope the decoder/renderer is going to take care of that properly...
__________________
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.


LoRd_MuldeR is offline   Reply With Quote
Old 8th June 2013, 17:26   #14  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
I can't make it right with i444. It never looks right.
If the input range option isn't changed the result is similar, but subtly different. (Also if --range PC the sun seemingly increases). If I force the input range too the result is obviously too light.

Source:


Rgb (rather indistinguishable):


i444 (results in TV range.):


i444 --range PC:


i444 --input-range PC --range PC

Last edited by mzso; 8th June 2013 at 17:33.
mzso is offline   Reply With Quote
Old 8th June 2013, 18:11   #15  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 649
As I said earlier this is rgb -> yuv conversion issue.
Quote:
Originally Posted by vivan View Post
which would default to Rec709 for HD, but x264 would use Rec601 for rgb -> yuv conversion. That's why you should perform rgb -> yuv conversion using avisynth).
This is your "i444 (results in TV range.):" picture, converted to yv24 using Rec709 matrix and then back to rgb using Rec601 matrix.
http://5.firepic.org/5/images/2013-0...3usdvxlsnv.png
Looks as source, right?

If you don't want to use avisynth for proper rgb -> yuv conversion you have to add --colormatrix bt470bg to x264 encdoing string. However it will work only with madVR + LAV video decoder, other renderers ignore colormatrix flag, and other decoders doesn't send it to the renderer.

As for
Quote:
i444 --input-range PC --range PC
Strange that it doesn't look like just i444. Are you using madVR and LAV video decoder?

Last edited by vivan; 8th June 2013 at 18:19.
vivan is offline   Reply With Quote
Old 8th June 2013, 18:44   #16  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by vivan View Post
As I said earlier this is rgb -> yuv conversion issue.

This is your "i444 (results in TV range.):" picture, converted to yv24 using Rec709 matrix and then back to rgb using Rec601 matrix.
http://5.firepic.org/5/images/2013-0...3usdvxlsnv.png
Looks as source, right?

If you don't want to use avisynth for proper rgb -> yuv conversion you have to add --colormatrix bt470bg to x264 encdoing string. However it will work only with madVR + LAV video decoder, other renderers ignore colormatrix flag, and other decoders doesn't send it to the renderer.

As for Strange that it doesn't look like just i444. Are you using madVR and LAV video decoder?
But why can't x264 do it properly, why do I need to use avisynth?

Yes, I use LAV + madVR.
mzso is offline   Reply With Quote
Old 8th June 2013, 19:24   #17  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
x264 doesn't currently have the ability to select whether or not to use BT.709 or BT.601 matrixes when doing conversion; patches welcome.

This only matters when converting from RGB->YUV within x264 for input.
Dark Shikari is offline   Reply With Quote
Old 8th June 2013, 21:13   #18  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by Dark Shikari View Post
x264 doesn't currently have the ability to select whether or not to use BT.709 or BT.601 matrixes when doing conversion; patches welcome.

This only matters when converting from RGB->YUV within x264 for input.
Too bad...
I seem to always find something that's not doable. Whether it's ffmpeg or x264 doesn't matter.

Last edited by mzso; 8th June 2013 at 21:16.
mzso is offline   Reply With Quote
Old 8th June 2013, 21:29   #19  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,414
Quote:
Originally Posted by mzso View Post
Too bad...
I seem to always find something that's not doable. Whether it's ffmpeg or x264 doesn't matter.
It's "doable" with avisynth

ffmpeg can do it with -vf colormatrix=bt601:bt709 , (and -pix_fmt yuv444p for i444), but for some reason the quality is noticably lower than doing it through avisynth (I suspect something is wrong with the colormatrix patch in ffmpeg)
poisondeathray is offline   Reply With Quote
Old 8th June 2013, 21:45   #20  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 758
Quote:
Originally Posted by poisondeathray View Post
It's "doable" with avisynth

ffmpeg can do it with -vf colormatrix=bt601:bt709 , (and -pix_fmt yuv444p for i444), but for some reason the quality is noticably lower than doing it through avisynth (I suspect something is wrong with the colormatrix patch in ffmpeg)
On the other hand you can't make ffmpeg to keep full range with libx264 nor can it encode into rgb.

I'll just stick with rgb. Even though I have to in two/three steps. A good encoder tool just doesn't exist.
(I even tried mencoder, but it doesn't accept output_csp even though it's in the documentation and fails with "FATAL: Cannot initialize video driver." which I can't even comprehend )
mzso 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 04:24.


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