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. |
8th June 2013, 01:33 | #1 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
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. |
8th June 2013, 01:45 | #2 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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?)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 8th June 2013 at 02:05. |
8th June 2013, 02:50 | #3 | Link |
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643
|
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. |
8th June 2013, 12:13 | #4 | Link | |||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Quote:
Quote:
This makes sense then. |
|||
8th June 2013, 12:24 | #5 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
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.
|
8th June 2013, 12:29 | #6 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Nope, it's not. --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. |
|
8th June 2013, 14:03 | #7 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
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. |
|
8th June 2013, 14:15 | #8 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
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)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 8th June 2013 at 14:23. |
8th June 2013, 14:38 | #9 | Link | ||
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Quote:
I guess I'll try forcing "--input-range" |
||
8th June 2013, 14:39 | #10 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
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. |
|
8th June 2013, 14:41 | #11 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
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. |
|
8th June 2013, 14:51 | #12 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
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. |
8th June 2013, 15:18 | #13 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
8th June 2013, 17:26 | #14 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
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. |
8th June 2013, 18:11 | #15 | Link | ||
/人 ◕ ‿‿ ◕ 人\
Join Date: May 2011
Location: Russia
Posts: 643
|
As I said earlier this is rgb -> yuv conversion issue.
Quote:
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:
Last edited by vivan; 8th June 2013 at 18:19. |
||
8th June 2013, 18:44 | #16 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
Yes, I use LAV + madVR. |
|
8th June 2013, 21:13 | #18 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
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. |
|
8th June 2013, 21:29 | #19 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
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) |
|
8th June 2013, 21:45 | #20 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
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 ) |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|