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 7th November 2023, 11:52   #1201  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
No, you didn't miss something.

Sadly development of VirtualDub2 has stopped since then until now.

Quite noticeable as VD2 is best manipulating/ restoring video GUI that I know.
(Of course, behind the seven mountains with the seven dwarves... there is AviSynth...)
nji is offline   Reply With Quote
Old 7th November 2023, 14:34   #1202  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,524
VirtualDub Build 44282, this is what I use too, weekly.
AvsPmod to generate and preview restoration .avs, VD2 to write intermediate .avis
Vegas Pro to edit/compose/render, x264/265 to encode, (sometimes NVEncC265 for quick&dirty preview),
tsMuxer to mux into .m2ts, MP4box to mux into .mp4, mkvtoolnix to mux into .mkv,
BDEdit or DVD-A Pro to mux into BD-R....
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."

Last edited by Emulgator; 7th November 2023 at 14:41.
Emulgator is offline   Reply With Quote
Old 7th November 2023, 15:32   #1203  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,333
Quote:
Originally Posted by nji View Post
Take a mp4/avc1 and write it with same codec (but in it's config
change from YUV 4:2:0 to RGB).

Why is that?
I would expect only minor effects, measurable but not so obvious.

https://c.gmx.net/@11558428876409458...QqiL0KZkxjFo4g

I can't see the image, but likely it's a Rec601 vs. Rec709 matrix mismatch . The color matrix is a major factor governing how YUV <=> RGB conversions are performed

HD uses 709 by convention , SD uses 601 . Vdub uses 601 for RGB conversion

You get slight color shifting with the wrong interpretation . Ideally you would use correct matrix conversion, and flag the metadata correctly as well in the encoder, so the playback device/software has the highest chance of display correct colors as well

There should be a workaround in vdub2 - decode format has 601/709 full vs limited options and/or the alias format and convert format filters

If it's not the color matrix problem, post more information
poisondeathray is offline   Reply With Quote
Old 7th November 2023, 16:28   #1204  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
@poisondeathray:
But that seems to be another pitfall of VD2 then?
If VD2 always uses Rec601 - what about all the implicit filter conversions when working on a Rec709 movie?
Moreover I tried: input AVC1/ Rec709 and output Lagarith (Both with RGB and YUV12 format): Both results are slightly too bright.
Try with AviDemux: Read the above video, write with the lossless codecs... all fine.
nji is offline   Reply With Quote
Old 7th November 2023, 16:44   #1205  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,333
Quote:
Originally Posted by nji View Post
@poisondeathray:
But that seems to be another pitfall of VD2 then?
If VD2 always uses Rec601 - what about all the implicit filter conversions when working on a Rec709 movie?
Moreover I tried: input AVC1/ Rec709 and output Lagarith (Both with RGB and YUV12 format): Both results are slightly too bright.
Try with AviDemux: Read the above video, write with the lossless codecs... all fine.
If the filters work in YUV, there is no problem, because there are no RGB<=>YUV conversions. If you checkmark "show image formats" in the filter options dialog box it will show you which pixel formats are being sent

It's a limitation of vdub classic, which was used in an era that only dealt with SD. 601 was ok back then. Vdub2 has a workaround as mentioned above

There are threads discussing this vdub/vdub2 matrix issue and the workarounds. If you still need help , provide more information, because I'm making some guesses that is your problem
poisondeathray is offline   Reply With Quote
Old 7th November 2023, 17:19   #1206  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
There was a misunderstanding. I didn't noticed you were talking about "classic virtualdub" - and not about VD2.

Of course I'm doing only in VD2 (... the whole thread is about it).
And the problems with enlightened output is with VD2.

Moreover: all those color conversion in a typical filter chain is what I am talking about.

Seems to be much confusion about this...

BTW: If do a VD2 encode to HuffYUV it's OK with YUV12, but brighter in RGB mode.
nji is offline   Reply With Quote
Old 7th November 2023, 17:59   #1207  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,333
Quote:
Originally Posted by nji View Post
There was a misunderstanding. I didn't noticed you were talking about "classic virtualdub" - and not about VD2.

Of course I'm doing only in VD2 (... the whole thread is about it).
And the problems with enlightened output is with VD2.

Moreover: all those color conversion in a typical filter chain is what I am talking about.

Seems to be much confusion about this...
Assuming this is your problem, you need to take control of the RGB <=> YUV conversion steps, instead of letting vdub and/or filters automatically use 601 or the wrong matrix. Many of the older vdub filters that work in RGB, automatically use 601 with YUV input for the RGB conversion. So take control and convert to RGB using 709 before that filter, and if exporting YUV, use 709 instead of 601 . Alternatively, you can use 601 for the YUV to RGB step, but you have to use 601 on the return step to YUV, but flag it as 709

It's possible in vdub2 with the decode format, alias format, convert format, and the compression menu has options as well with the pixel format button (601/709, full vs. limited)

Quote:
BTW: If do a VD2 encode to HuffYUV it's OK with YUV12, but brighter in RGB mode.
But do you mean no filters, or YUV filters ie. YUV to YUV (no RGB step), then that is the expected result
poisondeathray is offline   Reply With Quote
Old 7th November 2023, 19:13   #1208  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
It's hard for me to believe this should be true.
As that situation wouldn't be a pitfall, but a field of pitfalls:

I would have to check for every movie about its color profile
(601/709, full/ limited), also would have to know which VD2 filter
uses which color conversion matrix, and do manually a conversion.
This can't be true!?

Moreover for me personally it's anything but expected that
encoding an avc1/709/YUV421 movie losslessly as HuffYUV
does fine as YUV, but as RGB changes brightness.
nji is offline   Reply With Quote
Old 7th November 2023, 19:45   #1209  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,333
Quote:
Originally Posted by nji View Post
It's hard for me to believe this should be true.
As that situation wouldn't be a pitfall, but a field of pitfalls:

I would have to check for every movie about its color profile
(601/709, full/ limited), also would have to know which VD2 filter
uses which color conversion matrix, and do manually a conversion.
This can't be true!?

Moreover for me personally it's anything but expected that
encoding an avc1/709/YUV421 movie losslessly as HuffYUV
does fine as YUV, but as RGB changes brightness.


Assuming that's your problem, welcome to vdub/vdub2.

vdub2 is based on legacy software . Many of the vdub RGB filters are hardcoded to use Rec601 with YUV input. Many of the legacy compressors (like huffyuv) are also hardcoded to use Rec601 for YUV to RGB conversions.

Just beware of YUV<=>RGB conversions, that's true for all software not just vdub . Pro NLE's potentially have this sort of issue to if you're not careful

Maybe you didn't notice before because you were only using SD sources in the past.

It's actually many more combinations now - with UHD, Rec2020 , HDR . Not just matrix; but transfer, primaries too . There are dozens of more combinations and tonemapping for SDR outputs. Vdub2 doesn't cover them all. Look on the bright side - at least it's still possible to work with HD, RGB filters when using workarounds
poisondeathray is offline   Reply With Quote
Old 10th November 2023, 21:12   #1210  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by nji View Post
Take a mp4/avc1 and write it with same codec (but in it's config
change from YUV 4:2:0 to RGB).

Why is that?
I would expect only minor effects, measurable but not so obvious.

https://c.gmx.net/@11558428876409458...QqiL0KZkxjFo4g
Hi, it is not clear which software do you use for viewing when comparing?
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 11th November 2023, 12:37   #1211  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
Hi. I used in-built software (firmware of my eyes and brain)

I checked again: It depends a bit from movie to movie.

But if you take the one I linked to (see above, re-activated) it is obvious.
(Still you can stop YUV and RGB movies at the same frame; then flip-flop).
If you measure the difference you find about 1 per component (average), max to 3.

One may not notice the difference at a superficial look (but the same holds for many settings).
The more serious this issue is.

Also videos are AVC1/YUV by origin, many modifiying VD filters do in RGB...
Saving in YUV seems to revert the effect sometimes...(?)

What is real cause for this difference?

Last edited by nji; 11th November 2023 at 13:26. Reason: Important edits, sorry.
nji is offline   Reply With Quote
Old 11th November 2023, 15:14   #1212  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,333
Quote:
Originally Posted by nji View Post
Hi. I used in-built software (firmware of my eyes and brain)

I checked again: It depends a bit from movie to movie.

But if you take the one I linked to (see above, re-activated) it is obvious.
(Still you can stop YUV and RGB movies at the same frame; then flip-flop).
If you measure the difference you find about 1 per component (average), max to 3.
Max 3 is expected error for a correct 8bit YUV=>RGB=>YUV conversions due to rounding, clipping, precision issues for 8bit and the YUV/RGB color models (there are many 8bit YUV values that do not map to 8bit RGB - you get negative RGB values, and RGB values >255 - these are clipped in an 8bit conversion). But +/-3 is not noticable under normal viewing conditions . You need RGB float for a lossless round trip


Quote:
The more serious this issue is.
If you have a rec601/709 mismatch, you can have a difference of ~0-30 . It affects reds , greens more than other colors, but the error is much larger than an 8bit "correct" conversion

Last edited by poisondeathray; 11th November 2023 at 15:17.
poisondeathray is offline   Reply With Quote
Old 11th November 2023, 17:41   #1213  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by nji View Post
Hi. I used in-built software (firmware of my eyes and brain)

I checked again: It depends a bit from movie to movie.

But if you take the one I linked to (see above, re-activated) it is obvious.
(Still you can stop YUV and RGB movies at the same frame; then flip-flop).
If you measure the difference you find about 1 per component (average), max to 3.

One may not notice the difference at a superficial look (but the same holds for many settings).
The more serious this issue is.

Also videos are AVC1/YUV by origin, many modifiying VD filters do in RGB...
Saving in YUV seems to revert the effect sometimes...(?)

What is real cause for this difference?
https://i.postimg.cc/P5gGLqrG/image.png

In VD2 you can use shift+mouse move within filter preview to inspect pixel values.
The random difference per component is related with the codec being lossy. But overall (if you average any large portion of the frame) it should stay the same, works for me. Used x264 at crf 20 in this example.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 11th November 2023, 17:47   #1214  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by poisondeathray View Post
Max 3 is expected error for a correct 8bit YUV=>RGB=>YUV conversions due to rounding, clipping, precision issues for 8bit and the YUV/RGB color models (there are many 8bit YUV values that do not map to 8bit RGB - you get negative RGB values, and RGB values >255 - these are clipped in an 8bit conversion). But +/-3 is not noticable under normal viewing conditions . You need RGB float for a lossless round trip




If you have a rec601/709 mismatch, you can have a difference of ~0-30 . It affects reds , greens more than other colors, but the error is much larger than an 8bit "correct" conversion
All of this can be involed in some scenarios, but when you look at the picture in VD2 it is already converted to rgb for display (same YUV-RGB conversion is used either for display, filtering or encoding). And this rgb should not be affected by anything after you send it to rgb codec, except the codec accuracy.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 11th November 2023, 19:40   #1215  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,333
Quote:
Originally Posted by shekh View Post
The random difference per component is related with the codec being lossy. But overall (if you average any large portion of the frame) it should stay the same, works for me. Used x264 at crf 20 in this example.
He was using lagarith, huffyuv earlier, so assuming he didn't change , "lossy" is not the explanation. 8bit YUV=>RGB=>YUV +/-3 expected values explains it nicely


Quote:
Originally Posted by nji View Post
BTW: If do a VD2 encode to HuffYUV it's OK with YUV12, but brighter in RGB mode.
Quote:
Originally Posted by nji View Post
Moreover for me personally it's anything but expected that
encoding an avc1/709/YUV421 movie losslessly as HuffYUV
does fine as YUV, but as RGB changes brightness.




Quote:
Originally Posted by shekh View Post
All of this can be involed in some scenarios, but when you look at the picture in VD2 it is already converted to rgb for display (same YUV-RGB conversion is used either for display, filtering or encoding). And this rgb should not be affected by anything after you send it to rgb codec, except the codec accuracy.

Yes, the preview is an RGB converted representation

For RGB codec, lossless codec like lagarith should be "accurate"...

And when you save out a YUV export directly, there isn't necessarily a RGB step if you do it properly - and there was a claim that lagarith YV12 was also incorrect:


Quote:
Moreover I tried: input AVC1/ Rec709 and output Lagarith (Both with RGB and YUV12 format): Both results are slightly too bright.
Try with AviDemux: Read the above video, write with the lossless codecs... all fine.
This one needs more clarification . Did vdub2 use RGB filters > Did avidemux use the same RGB filters? Because avidemux suffers the same +/- 3 8bit YUV=> 8bit RGB=> 8bit YUV issue because it's simple math and unavoidable with 8bit RGB

If no filters, then lagarith was not used correctly . There should be no colorspace conversion if you set video=>fast recompress . So YV12 in should be YV12 out, lossless. Also, lagarith in RGB(default) mode does not actually convert to RGB, it retains the input colorspace - if you send YV12, RGB(default) actually uses YV12 too - also lossless. But if you send RGB, then RGB(default) uses RGB. So this might be some other issue like a preview issue (eg. your viewing program might be using Rec601 to convert to display for the lagarith YV12 version, but 709 for the MP4 version. But you would expect the same problem with avidemux lossless codecs on playback...)

For the RGB lagarith version, I can see no other explanation than a rec601/709 mismatch - it's converted incorrectly

But if "slightly too bright" refers to the max +/- 25-30 then the Rec601/709 mismatch, is the most common explanation. Either conversion, or playback chain incorrect

Last edited by poisondeathray; 11th November 2023 at 19:42.
poisondeathray is offline   Reply With Quote
Old 11th November 2023, 19:51   #1216  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
Quote:
Originally Posted by shekh View Post
...
The random difference per component is related with the codec being lossy. But overall (if you average any large portion of the frame) it should stay the same, works for me. Used x264 at crf 20 in this example.
For me it's different (BTW x264 @ crf18):
The RGB version is slightly lighter - almost everywhere.
(Checked by frame exports and subtracts).

If it would have been a random pattern I wouldn't get suspicious.
nji is offline   Reply With Quote
Old 11th November 2023, 20:43   #1217  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by nji View Post
For me it's different (BTW x264 @ crf18):
The RGB version is slightly lighter - almost everywhere.
(Checked by frame exports and subtracts).

If it would have been a random pattern I wouldn't get suspicious.
This is weird. Describe 'frame exports'?
Try with this file. Your example 1st frame encoded in rgb avc.
https://wetransfer.com/downloads/785...1193730/8a9661
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 11th November 2023, 22:31   #1218  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
Quote:
Originally Posted by shekh View Post
This is weird. Describe 'frame exports'?...
"That detective, is the right question" (I robot)

Actually I "exported" that 1st frame when displaying the movie with MPC-HC.
And this is the true reason for the lightened RGB frame!
If I export (single frame) with VD2... everything is as expected.

So... wrong forum...
will see if my (default) MPC-HC settings are responsible for that,
or... etc.

However:
Thank you very much for all your help!

Last edited by nji; 11th November 2023 at 22:54.
nji is offline   Reply With Quote
Old 12th November 2023, 11:59   #1219  |  Link
nji
Registered User
 
Join Date: Mar 2018
Location: Germany
Posts: 198
OK, I did a "round-up" test for the topic.

For that I used these programs:
VirtualDub2-32 (newest)
MPC-HC-64 (1.9.23, Aug. 22, not newest)
AviDemux-64 (newest)
IrfanView-32 (newest)
PaintShopPro-32 (7.x, stone age)

1st scenario:
Open the movie (see above) with VD2, MPC, ADM respectively
export the first frame as png.
Result (as of IV and PSP):
VD2 > MPC > ADM (">": significant overall brighter, i.e. not randomly).
The difference is so significant that I would have different manipulation
parameters when working with VD2.
PROBLEM_No1.

2nd scenario:
Open the movie with VD2
write it as h264/ crf18/ RGB.
Now take this result movie and do the same test as in the first scenario.
Result:
All exported RGB frames are (about) the same brightness. (Hurray!)
And their brightness is identical to the original of... of...
VD2.
(This doesn't contradict to my posts above ("RGB is brighter"),
as there I exported the orig frame by MPC (= darker)).

My conclusion of all this:

It seems (!) like MPC, and ADM even more, have bugs of showing/ writing
contents too dark.

Maybe someone checks my results and conclusion?

Last edited by nji; 12th November 2023 at 12:36. Reason: MPC/ AD flaw also in writing.
nji is offline   Reply With Quote
Old 12th November 2023, 18:21   #1220  |  Link
v0lt
Registered User
 
Join Date: Dec 2008
Posts: 1,931
VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg6.1 test 7)
Alternative link

avlib-1.vdplugin (FFmpeg 6.1) source code
v0lt 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 13:55.


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