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 > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th September 2015, 20:40   #1  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
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
fvisagie is offline   Reply With Quote
Old 13th September 2015, 21:08   #2  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
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)
poisondeathray is offline   Reply With Quote
Old 13th September 2015, 22:37   #3  |  Link
raffriff42
Retried Guesser
 
raffriff42's Avatar
 
Join Date: Jun 2012
Posts: 1,377
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:
"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.
raffriff42 is offline   Reply With Quote
Old 14th September 2015, 09:20   #4  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Quote:
Originally Posted by raffriff42 View Post
Here's something (virtualdub forum)
Quote:
"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.
That is something very useful you're showing me here :-). I was not aware of the alias filter.

Quote:
Originally Posted by poisondeathray View Post
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.

Last edited by fvisagie; 14th September 2015 at 16:23. Reason: Added PS
fvisagie is offline   Reply With Quote
Old 14th September 2015, 15:13   #5  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
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.
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 13:00   #6  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Quote:
Originally Posted by poisondeathray View Post
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?
fvisagie is offline   Reply With Quote
Old 15th September 2015, 15:51   #7  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
Quote:
Originally Posted by fvisagie View Post
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
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 17:13   #8  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 497
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.
shekh is offline   Reply With Quote
Old 15th September 2015, 17:22   #9  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
Quote:
Originally Posted by shekh View Post
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
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 17:41   #10  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 497
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.
shekh is offline   Reply With Quote
Old 15th September 2015, 17:47   #11  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
Quote:
Originally Posted by shekh View Post
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)
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 18:19   #12  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 497
Quote:
Originally Posted by poisondeathray View Post
"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.

Quote:
Originally Posted by poisondeathray View Post
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.
shekh is offline   Reply With Quote
Old 15th September 2015, 18:27   #13  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
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.
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 18:46   #14  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 497
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
shekh is offline   Reply With Quote
Old 15th September 2015, 18:53   #15  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
Quote:
Originally Posted by shekh View Post
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)
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 19:12   #16  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 497
Quote:
Originally Posted by poisondeathray View Post
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.
shekh is offline   Reply With Quote
Old 15th September 2015, 19:28   #17  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
Quote:
Originally Posted by shekh View Post
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.
poisondeathray is offline   Reply With Quote
Old 15th September 2015, 21:34   #18  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 497
Quote:
Originally Posted by poisondeathray View Post
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.

Quote:
Originally Posted by poisondeathray View Post
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).
shekh is offline   Reply With Quote
Old 16th September 2015, 11:11   #19  |  Link
fvisagie
Registered User
 
Join Date: Aug 2008
Location: Isle of Man
Posts: 586
Quote:
Originally Posted by poisondeathray View Post
I use known colorbar and calibration videos (known YUV and RGB values).
Thanks.

Quote:
Originally Posted by poisondeathray View Post
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?
fvisagie is offline   Reply With Quote
Old 16th September 2015, 14:23   #20  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,412
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
poisondeathray 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 03:27.


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