VirtualDub2

[nji]

No, you didn't miss something.

Sadly development of VirtualDub2 (https://sourceforge.net/projects/vdfiltermod/files/plugins/)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 (http://avisynth.nl/index.php/Main_Page)...)

[Emulgator]

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

[poisondeathray]

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/@1155842887640945833/o46DBll3QqiL0KZkxjFo4g


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

[nji]

@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 (https://avidemux.sourceforge.net/): Read the above video, write with the lossless codecs... all fine.

[poisondeathray]

@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 (https://avidemux.sourceforge.net/): 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

[nji]

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.

[poisondeathray]

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)


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

[nji]

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.

[poisondeathray]

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

[shekh]

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/@1155842887640945833/o46DBll3QqiL0KZkxjFo4g

Hi, it is not clear which software do you use for viewing when comparing?

[nji]

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?

[poisondeathray]

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



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

[shekh]

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.

[shekh]

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.

[poisondeathray]

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



BTW: If do a VD2 encode to HuffYUV it's OK with YUV12, but brighter in RGB mode.


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.





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:



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

[nji]

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

[shekh]

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/785d636866ea30a89df3b9cee91cc0f020231111193712/e2cb907ef0a14390096f45abd8addbec20231111193730/8a9661

[nji]

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 (https://github.com/clsid2/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! :) :)

[nji]

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?

[v0lt]

VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg6.1 test 7) (https://www.sendspace.com/file/3iawvw)
Alternative link (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)

avlib-1.vdplugin (FFmpeg 6.1) source code (https://github.com/v0lt/avlib_vdplugin)

[danbow]

Hi Doom9!
I very much love VirtualDub2 and it is very a pity, that it is stopped on 44282 version in 2020.
I love WindowsXP even more:) and i use ffmpeg xpmod by Reino Wijnsma: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D
Right now last version ffmpeg-6.1 (2023-09-04) for xp, there is and sources, but alls it only x86 (i do not know why for xp-64 does not do).
Maybe this is useful for compile.

[Emulgator]

I would guess that Reino might have no XP64 bit installation and building tools available (me neither)
But since he was so kind to publish his build configuration
https://forum.doom9.org/showthread.php?t=181802&highlight=ffmpeg
one who has all that (and the knowledge) should be able to compile himself.

[v0lt]

VirtualDub2 includes only one plugin that uses FFmpeg DLLs. This is avlib-1.vdplugin.
Old version of avlib-1.vdplugin uses old versions of FFmpeg DLLs. New versions of FFmpeg differ in the names of the DLL files. The FFmpeg API has also been changed.

[tormento]

VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg6.1 test 7)
Tried to drag and drop a AVS file and it simply hangs.

[v0lt]

Tried to drag and drop a AVS file and it simply hangs.
It doesn't freeze for me, but it gives me an error.
I disabled support for AviSynth scripts in avlib-1.vdplugin.

VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg6.1 test 8) (https://www.sendspace.com/file/tzul6n)
Alternative link (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)

avlib-1.vdplugin (FFmpeg 6.1) source code (https://github.com/v0lt/avlib_vdplugin)

[v0lt]

VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg 6.1.1 test 9) (https://www.sendspace.com/file/rsdacd)
Alternative link (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)

avlib-1.vdplugin (FFmpeg 6.1.1) source code (https://github.com/v0lt/avlib_vdplugin)

[Morku]

It's nice to see updates here, but using VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg 6.1.1 test 9) the process stays open in background after closing VD2. I need to close in task-manager.
To reproduce I need to drag and drop an Avisynth avs script, containing and loading a video:
LWLibavVideoSource("IMG_0001.MOV")
Closing VD2 and it still run.

[v0lt]

@Morku
I think the problem is not with avlib-1.vdplugin (test 9). Because this plugin should not be used with AviSynth scripts.

[Morku]

Yes, that makes me also wondering, but using last VirtualDub2_44282 64Bit version, the exact same video and script, it doesn't get stuck. Using test 9, the process get stuck after closing again.
Don't know why and what exactly is the cause, but with the Avisynth script is my observation. When I drag and drop the MOV directly, VD2 test 9 just closes fine.

[v0lt]

What happens if you open a simpler script?
Colorbars(1280,720)

[Morku]

Also don't close proper. I need to close in task-manager. (AviSynth+ 3.7.3)

[v0lt]

Also don't close proper. I need to close in task-manager. (AviSynth+ 3.7.3)
I confirm the problem. But I don’t know what to do with it yet.

[Morku]

One more thing with test 9. Loading a DV avi gives me error:

FFMPEG: Unsupported channel layout.

File to test: https://www.sendspace.com/file/p7eghe

Loading fine with 44282.

[v0lt]

One more thing with test 9. Loading a DV avi gives me error:

FFMPEG: Unsupported channel layout.
Older versions of FFmpeg recognized audio from DV as stereo. Newer versions of FFmpeg recognize audio as 2 channels with an unknown channel layout.

I tried to solve this problem.
VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg 6.1.1 test 10) (https://www.sendspace.com/file/1hek7e)
Alternative link (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)

[Morku]

That was quick and I can confirm, the DV loads fine now :)

[v0lt]

Also don't close proper. I need to close in task-manager. (AviSynth+ 3.7.3)
Fixed.
VirtualDub2 x64 with updated avlib-1.vdplugin (ffmpeg 6.1.1 test 11) (https://www.sendspace.com/file/hf1rb8)
Alternative link (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)

[tormento]

It's a pity that I can't get working AVS+ support.

Hope in some future release.

[v0lt]

It's a pity that I can't get working AVS+ support.
AviSynth+ scripts open for me.
https://i.ibb.co/FnxvjYp/Avi-Synth-373-in-VD2.jpg (https://ibb.co/FnxvjYp)

[LigH]

It might be the issue I once reported: Selecting the Cached vs. AviFile input driver (https://forum.doom9.org/showthread.php?p=1988797#post1988797) when opening AVS files.

[v0lt]

It might be the issue I once reported: Selecting the Cached vs. AviFile input driver (https://forum.doom9.org/showthread.php?p=1988797#post1988797) when opening AVS files.
I don't have this problem with the latest test build.
You may be using FFmpegSource2, which builds an index file for the video file being opened.

[tormento]

I don't have this problem with the latest test build.
After having tested your last build for some days, I can say that it works really well, with AVS scripts as well.

Thank you!

Does it decode video in hw or sw? I have noticed some stuttering when scrolling backward.

[v0lt]

Does it decode video in hw or sw? I have noticed some stuttering when scrolling backward.
avlib-1.vdplugin decodes in software mode.

[tormento]

avlib-1.vdplugin decodes in software mode.
Can you do something for reverse frame by frame (left arrow)?

It's so slow compared to forward mode.

Try with hevc.

[LigH]

That would require the caching of the whole GOP decoding sequence of P frames from the previous IDR frame to your current "mini GOP" of B frames between the surrounding I/P frames. That would cost a lot of RAM and a serious amount of code.

[v0lt]

Can you do something for reverse frame by frame (left arrow)?
I'm updating FFmpeg and fixing bugs that appeared after the update. I do not plan to change the functionality of the plugin; I do not have the time and competence for this.

[tormento]

That would require the caching of the whole GOP decoding sequence of P frames from the previous IDR frame to your current "mini GOP" of B frames between the surrounding I/P frames. That would cost a lot of RAM and a serious amount of code.
The "old" VirtualDub2 isn't so slow.

[LigH]

But it uses a severely outdated ffmpeg version with a different set of interface functions. Well possible that to make it support modern A/V formats better, some features had to be implemented in a different way, and to make full use of those, we would need a specialist in ffmpeg APIs in different major versions...

[v0lt]

The "old" VirtualDub2 isn't so slow.
I didn't see much difference. Moving backward within the current GOP is fast, but there is a slight delay when moving to an earlier GOP. This is the same for old and new avlib-1.vdplugin.

If you have a very large distance between keyframes, then you can try increasing the cache size in the "Cashing input driver" settings. By default there is 0.5 GB.

[nji]

First of all:
I never touched that frameserving thing;
I only now that VD2 may use AviSynth as frameserver and by this
may use AviSynth's very special filters.

Now I came to the point of using an ffmpeg filter and
do further manipulation in VD2.
I did this using an intermediate lossless file.
Not so nice.

So I wonder... if someone can drop some info about frameserving
from ffmpeg to VD2.
(Or is there a different way of using an ffmpeg filter in VD2?)

[Emulgator]

1. Make an empty .avs.
2. It will be an one-liner. Call your desired ffmpeg-based source filter
http://avisynth.nl/index.php/FFmpegSource
FFmpegSource2("<yourpathhere>")
OR
http://avisynth.nl/index.php/LSMASHSource
LWLibavVideoSource("<yourpathhere>")
3. Drag and drop your .avs onto VD, may it be VD shortcut or open VD window.