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. |
13th September 2015, 20:40 | #1 | Link |
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
Lagarith vs. HD YV12 Rec.709 content
How do you guys handle HD YV12 Rec.709 content with the Lagarith encoder? Of the 17-odd yuv420-type formats VirtualDub 1.10.4 provides, it seems the Lagarith encoder only supports "YCbCr (Rec.601) Limited 4:2:0 -". No full-range formats, no dedicated interlaced formats, and no Rec.709-based formats.
What does this imply for working with HD content in Lagarith - is this the time to abandon it? Or, is it still chroma-safe to work with YV12 -> RGB32 -> YV12 round-trips, provided one uses Rec.601 conversions both before and after? Any other ideas? Thanks, François |
13th September 2015, 21:08 | #2 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
It depends on your workflow, which programs and decoders you are using. But it can work fine
If you use avisynth or vapoursynth for everything, you control precisely where the conversions are occurring and how (interlaced vs progressive, which matrix) . If you use common NLE's , YUV lossless codecs usually get converted to RGB incorrectly (superbrights/darks get clipped) |
13th September 2015, 22:37 | #3 | Link | |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
You can control the conversion in VirtualDub too. Don't convert to RGB unless you really have to (eg, certain vdub filters).
Here's something (virtualdub forum) Quote:
|
|
14th September 2015, 09:20 | #4 | Link | |||
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
Quote:
Quote:
In other words, for perfectly symmetrical conversions (not mixing 601 and 709 coefficients) around VirtualDub filtering when VirtualDub is not doing any conversion ('-' = process boundary): {"709 YV12"AVS"RGB32"}-{VirtualDub filtering}-{"RGB32"AVS"709 YV12"}-{encode} Or, perhaps less desirably, would having VirtualDub do both conversions work correctly as follows? {"709 YV12"AVS}-{"601 YV12""aliased to 709 YV12""RGB32"VirtualDub filtering"RGB32""709 YV12""aliased to 601 YV12"}-{"709 YV12"AVS}-{encode} For space-saving I would probably opt for the latter, rendering YV12 from VirtualDub to disk. Seeing that aliasing can unambiguously inform VirtualDub of colour coefficients, what are the pros and cons of of Avisynth vs. VirtualDub doing the inital 709 YV12-to-RGB32 conversion? Is it correct to say that working with VirtualDub's YV12 render would require some care, always to ensure it is actually treated as Rec.709 YV12? And the same care would need to be taken with the encoder, ensuring it recognises or is told it is working with Rec.709 YV12? PS. VirtualDub's broken interlaced YV12 chroma treatment should not be an issue here, because I foresee all HD content being progressive. Last edited by fvisagie; 14th September 2015 at 16:23. Reason: Added PS |
|||
14th September 2015, 15:13 | #5 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
I tested vdub's color space input/output options and alias filter about a year ago - they didn't work properly then but it might be fixed by now. I just ran test charts, color bars through various combinations and checked the output.
|
15th September 2015, 15:51 | #7 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Yes, I'm very thorough with these types of tests. I make sure I know exactly what decoder, splitter, etc.. is being used at what stage. I also test other compression and different uncompressed fourcc versions in case the handling is slightly different. I use known colorbar and calibration videos (known YUV and RGB values). Avisynth's default conversion is a slightly "off" compared to other methods (this is known and discussed in other threads, possibly due to 8bt and rounding), but vdub's was way way off. It might be fixed by now
|
15th September 2015, 17:13 | #8 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
I did some test 1 year ago: compared yuv->rgb by VirtualDub vs ffmpeg. Also compared to this picture passed through to x264 and decoded again - no difference.
I wasnt very thorough however, just wanted to get rid of low/full range hell and it worked. |
15th September 2015, 17:22 | #9 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
in_range out_range in_color_matrix out_color_matrix https://ffmpeg.org/ffmpeg-filters.html#scale-1 https://ffmpeg.org/ffmpeg-scaler.htm...er_005foptions |
|
15th September 2015, 17:47 | #11 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
What is the "problem" ? Can you be more specific ? "Tagged" full range in the camera metadata doesn't necessarily mean content is full range If your camera is recording YUV, but has excursions into "super whites and darks" (ie.. <16, >235) , then a standard range RGB conversion will clip them. Most consumer cameras actually record 16-255 anyways If you use the wrong 601, vs 709, the colors will be slightly off when viewing (esp. skin tones) |
|
15th September 2015, 18:19 | #12 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
Forgive me my english. You told there was problem. I replied with "it works for me". So I dont have or cant see a problem. |
|
15th September 2015, 18:27 | #13 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
The problem is clipping data (not lossless) when letting ffmpeg or vdub do the default conversion, and/or wrong matrix (wrong colors) when doing YUV<=>RGB conversions. (YUV<=>RGB isn't lossless in the first place, so I'm talking about additional losses to that)
But if the conversion is symmetrical, the color issue is less of a problem (still the rounding issues, slightly off, but neglible most of the time). What I mean by symmetrical is you use the "wrong" 601 matrix to convert from YUV source to RGB, and the "wrong" 601 matrix to convert back to YUV - you get almost the same colors as what you started with. In effect, "2 wrongs" almost make a "right' . If you do it at higher bit depth than the default 8, you get even closer to what you started with (more precise, less rounding error). But the clipping issue still occurs for superbright/superdark data with the Rec matrices. You won't "see" the loss on a display because a Rec matrix is normally used to view in the first place. But if you look at a waveform monitor, all those values >235, <16 will be lost (clipped) , or you can measure the loss with metrics Last edited by poisondeathray; 15th September 2015 at 18:35. |
15th September 2015, 18:53 | #15 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
There would 1 wrong in that case, because it will have been converted to RGB using 601 (+/- the data loss you didn't see) You would compare that by doing the proper RGB conversion using 709 using a known method like avisynth (you should see the color difference) (It might be "fixed" by now in vdub , where you can specify a YUV to RGB conversion using 709 . It definitely was not working about a year ago, and definitely uses 601 by default, even now) |
|
15th September 2015, 19:12 | #16 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
Default setting is responsibility of input driver, can be quite different from 601. |
|
15th September 2015, 19:28 | #17 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
What I'm saying tests I did with vdub ~1 year ago didn't yield the correct results either with different combinations of alias filter, or the input/output csp settings (video=>color depth=>other , there is a list of many choices) I would argue that the input driver ideally should leave the input as is. If you want to apply a transformation later (e.g. colormatrix or convert to RGB , whatever) that should be separate. Usually that is the case in vdub anyway, but some input filters might apply a "hidden" conversion When you "see" the preview in vdub, it's being converted to RGB . When you take a screenshot with vdub with default settings, it's using the default Rec.601 to convert to RGB. Ideally you should be able to use some combination of input/output and alias to instead convert to RGB using Rec709 (ie to have some additional control) . Those options definitely didn't work correctly in the past. I don't know if they work now. |
|
15th September 2015, 21:34 | #18 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
(VirtualDubs 709/601 and FR format variations are essentially tags). We can talk about my driver instead of abstract one I tried to preserve image bytes and pass correct tags when possible. So that if tags are available there is no intervention needed (no need to select input format or alias filter) and otherwise at least the bytes are not destroyed before reaching filters etc. If it is tagged as 709, then it is always converted to rgb as 709, whichever reason for conversion (at least latest code works that way). |
|
16th September 2015, 11:11 | #19 | Link | ||
Registered User
Join Date: Aug 2008
Location: Isle of Man
Posts: 588
|
Quote:
Quote:
Even when no specified or implied resizing is required, is the 'scale' filter the correct/only way of specifying input and output formats and ranges? |
||
16th September 2015, 14:23 | #20 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
You don't have to actually do any scaling of dimensions with -vf scale - just set width, height =-1
There are other ways, such as using -pix_fmt (e.g. yuvj420p "j" would be full range) , sws flags, -vf colormatrix (to change in YUV, it's like avisynth's colormatrix). I don' t know if any of them are the "proper" way But it's always changing in ffmpeg land - it's hard to keep up unless you're actively checking it. At one point those scale options didn't work properly, but maybe 1/2 year ago they did, and there was at least 1 build in between where it didn't work. There are slight "gotchas" for each method, sometimes quality issues. For example, even though -vf colormatrix is ported from avisynth, it tends to yield lower quality. And produces slightly different results from ffmbc's -vf colormatrix yet all are derived from the same code! Theoretically it should have given the same results. All the ffmpeg conversions are 8bit currently. Higher quailty way, without a doubt, is to use higher bit depth conversion in vapoursynth or stack16 in avisynth. It's easy to demonstrate how your output values deviate more compared to output when using any of the 8bit conversion methods |
Thread Tools | Search this Thread |
Display Modes | |
|
|