Lagarith vs. HD YV12 Rec.709 content

[fvisagie]

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

[poisondeathray]

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)

[raffriff42]

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)

"phaeron" Posted: May 14 2013, 12:54 AM
The YV12 FOURCC corresponds to Rec. 601, and attempting to push Rec. 709 through it results in a situation where programs reading it have no idea which color space they are dealing with and thus you get color handling errors in the pipeline. Therefore, if you do have bogus YV12 data that is actually Rec. 709, you need to re-alias it to the 709 format so VirtualDub knows what it is actually dealing with.

[fvisagie]

Originally Posted by raffriff42

Here's something (virtualdub forum)

That is something very useful you're showing me here :-). I was not aware of the alias filter.

Originally Posted by poisondeathray

If you use avisynth or vapoursynth for everything, you control precisely where the conversions are occurring and how (interlaced vs progressive, which matrix) .

Thanks, that's what I hoped would work.

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.

[poisondeathray]

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.

[fvisagie]

Originally Posted by poisondeathray

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.

How did you check the output - compare results with equivalent processing in Avisynth, or some other way?

[poisondeathray]

Originally Posted by fvisagie

How did you check the output - compare results with equivalent processing in Avisynth, or some other way?

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

[shekh]

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.

[poisondeathray]

Originally Posted by shekh

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.

ffmpeg uses Rec601 and standard range (ie. rec601 matrix, progressive) by default, just like vdub, unless you use the proper range , matrix (and interlaced) flags for -vf scale, or sws flags

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

[shekh]

Yes thats not problem because my source is tagged "full range 709" by camera and I applied that.
I am curious to test it again if you point me some encoded/decoded references.

[poisondeathray]

Originally Posted by shekh

Yes thats not problem because my source is tagged "full range 709" by camera and I applied that.
I am curious to test it again if you point me some encoded/decoded references.

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)

[shekh]

Originally Posted by poisondeathray

"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)

Agree.

Originally Posted by poisondeathray

What is the "problem" ? Can you be more specific ?

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.

[poisondeathray]

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

[shekh]

I compared RGB images copied from vdub, so "2 wrongs effect" was not involved
So do you have example where vdub decodes yuv->rgb, all setup right, yet the result is wrong? Or I have lost what are we talking about

[poisondeathray]

Originally Posted by shekh

I compared RGB images copied from vdub, so "2 wrongs effect" was not involved
So do you have example where vdub decodes yuv->rgb, all setup right, yet the result is wrong? Or I have lost what are we talking about

now it's confusing

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)

[shekh]

Originally Posted by poisondeathray

now it's confusing
(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)

I thing I got it. I assumed using correct colorspace setting, either by alias filter or otherwise. Btw it seems that code did not change somewhere from 2012 but I am not historian

Default setting is responsibility of input driver, can be quite different from 601.

[poisondeathray]

Originally Posted by shekh

I thing I got it. I assumed using correct colorspace setting, either by alias filter or otherwise. Btw it seems that code did not change somewhere from 2012 but I am not historian

Default setting is responsibility of input driver, can be quite different from 601.

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.

[shekh]

Originally Posted by poisondeathray

I would argue that the input driver ideally should leave the input as is

Totally agree. But correct way of doing this is to tag yuv format as 709 if it is tagged as 709 in the file. There is no conflict here.
(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.

Originally Posted by poisondeathray

When you take a screenshot with vdub with default settings, it's using the default Rec.601 to convert to RGB

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).

[fvisagie]

Originally Posted by poisondeathray

I use known colorbar and calibration videos (known YUV and RGB values).

Thanks.

Originally Posted by poisondeathray

unless you use the proper range , matrix (and interlaced) flags for -vf scale, or sws flags

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

Your prescience is impressive! I was planning to look into ffmpeg's colour-space handling next.

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?

[poisondeathray]

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