VirtualDub2

[coolgit]

I see a risk of redundancy here. Most of the features this pack provides (via FFInputDriver.vdplugin, built in 2021) seems to be already covered by VirtualDub2 v2.x (via avlib-1.vdplugin, built in 2025).

Original source URL: https://github.com/h4aLkon/smldap/releases/

The additional filters are in the plugins{32|64}\*.vdf files in the ZIP archive; I would recommend to try not to add any other files to a recent VirtualDub2 installation.

Where?? When I update to new version in new folder ffdeband etc are not there. I have to do it myself.

[LigH]

Obviously you did not understand what I said.

I recommended not to put the FFInputDriver.vdplugin and ffdlls subdirectory from this plugins pack into the same directory as the avlib-1.vdplugin provided by VirtualDub2 because both input plugins do the same (enabling support of different containers and A/V formats as input) and may clash.

You may manually add the FF*.vfd filter files if you like. They should not hurt. But I do not recommend to mix everything from the plugins pack to a recent VirtualDub2 installation.

[coolgit]

Obviously you did not understand what I said.

I recommended not to put the FFInputDriver.vdplugin and ffdlls subdirectory from this plugins pack into the same directory as the avlib-1.vdplugin provided by VirtualDub2 because both input plugins do the same (enabling support of different containers and A/V formats as input) and may clash.

You may manually add the FF*.vfd filter files if you like. They should not hurt. But I do not recommend to mix everything from the plugins pack to a recent VirtualDub2 installation.

I never had any issue for years. Can you back this up?

I do some experiment for now.

OK here the thing.

I removed FFInputDriver_64.vdplugin and all ff... filters seemingly working. The only thing is when I open a file, the open with ffmpeg option no longer exist and I can only use catching input driver.

I removed ffdlls folder and only 4 of the 7 ff... filters show up. deband, deblock and unsharp does not show up. The 4 that do show up will not work and crashes vdub. Put the ffdlls folder back in and all is working.

As far as my experiment goes removing FFInputDriver_64.vdplugin doesn't affect the 7 ff... filters but simply remove the option to open a file with ffmpeg. Sometimes when opening mp4 files using catching input driver, it is a pain when seeking and jumping ahead as the video doesn't get decoded properly. When i use ffmpeg as 2nd option it will seek ahead properly. Therefore leaving FFInputDriver_64.vdplugin in merely give user another option and doesn't clash with avlib at all, based on my experience.

[v0lt]

https://mega.nz/file/XmBnBJpK#QmW3DlmxwYPvvOhl50HfXLDd0iVk6Sce7pMPpRIqWow
Ok. I added the following command at the beginning:
VirtualDub.Open("","Test video input driver (internal)",0,"AQA=");
I loaded the project file and there was no crash, there were no errors either.

I don't have a "plugins" folder.
List of files in the "plugins64" folder:
avlib-1.vdplugin
avlib-1_history.txt
avlib-1_Readme.md
blur.vdf
clrtools64.vdf
ColorMill.vdf
FFDeband.vdf
Filtres_JPSDR.vdf
gradation.vdf
Lagarith.vdplugin
master_blend.vdf
MPEG264.vdplugin
readme.txt
rgb_levels.vdf
rgb_scale.vdf
scripted.vdplugin
scripted_history.txt
scripted_Readme.md
sixaxis.vdf
x264-8.vdplugin
x264-10.vdplugin

PS: I also opened the original "vdub 2.3.vdproject" and nothing happened either.

[coolgit]

Ok. I added the following command at the beginning:
VirtualDub.Open("","Test video input driver (internal)",0,"AQA=");
I loaded the project file and there was no crash, there were no errors either.

I don't have a "plugins" folder.
List of files in the "plugins64" folder:
avlib-1.vdplugin
avlib-1_history.txt
avlib-1_Readme.md
blur.vdf
clrtools64.vdf
ColorMill.vdf
FFDeband.vdf
Filtres_JPSDR.vdf
gradation.vdf
Lagarith.vdplugin
master_blend.vdf
MPEG264.vdplugin
readme.txt
rgb_levels.vdf
rgb_scale.vdf
scripted.vdplugin
scripted_history.txt
scripted_Readme.md
sixaxis.vdf
x264-8.vdplugin
x264-10.vdplugin

PS: I also opened the original "vdub 2.3.vdproject" and nothing happened either.

VirtualDub.Open("","Test video input driver (internal)",0,"AQA=");

Added above code and ran your test. It load yes, same as any other files. When i save direct copy or ffv1 it crashes.

[v0lt]

I tried different methods, but I was unable to make VirtualDub crash.

Test build VirtualDub2 v2.4.0.891 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Fixed saving scripts.

[coolgit]

In general, scripts for old versions will not be compatible with version v2.4 if you use avlib_vdplugin.

You said it yourself that old script will not work with 2.4. So why are you testing my 2.3 script and saying it is fine? You are confusing,

[v0lt]

You said it yourself that old script will not work with 2.4. So why are you testing my 2.3 script and saying it is fine? You are confusing,
Because you said that you have crashes with VirtualDub2 v2.4 when using "vdub 2.3.vdproject" (https://forum.doom9.org/showthread.php?p=2021951#post2021951). I'm trying to reproduce the problem.

As far as I understand, you have no problems with the file "vdub 2.4.vdproject". I don't understand why you posted it. But I checked it again in VirtualDub2 v2.4.0.891. Everything is fine.

[coolgit]

Here the thing. I dl the latest Test build VirtualDub2 v2.4.0.891.

Load old project from 2.3 and it is working so far. Graduation filter is now working.

It seems you have fixed the bugs... good job.

[v0lt]

I redesigned the Display settings window in v2.4.0.894 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA).
https://i.ibb.co/hxQjnHrP/891.jpg (https://ibb.co/hxQjnHrP)https://i.ibb.co/cXsN8pZK/894.jpg (https://ibb.co/cXsN8pZK)

[LigH]

Seems more precise to the desired meaning to me.

BTW: Did you release MPC-BE 1.8.6 already? (link in your sig)

[StainlessS]

Did you release MPC-BE 1.8.6 already?
3 weeks ago.

[LigH]

And now the sig is up to date.

[rgr]

I redesigned the Display settings window in v2.4.0.894 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA).
https://i.ibb.co/hxQjnHrP/891.jpg (https://ibb.co/hxQjnHrP)https://i.ibb.co/cXsN8pZK/894.jpg (https://ibb.co/cXsN8pZK)

By the way, I have a question - which option is the best? (Adrenaline drivers, APU Vega 8)

[v0lt]

By the way, I have a question - which option is the best? (Adrenaline drivers, APU Vega 8)
There is no answer to your question. Check it on your machine yourself.

Previously, DirecDraw was the default. But it seemed to me that sometimes it was slow to render (I can't reproduce it now). Now I made Direct3D 9, it is more functional and well supported.

[rgr]

Are there any downsides to using DirectX11 or OpenGL?

PS. I've always had some issues with color ranges (limited vs. full range). They would arbitrarily switch when starting playback and revert to the previous value when stopped. Now it works fine in any mode.

[jay123210599]

How do I add attachments like fonts to videos using VirtualDub2?

[LigH]

I am mildly surprised that this should even be possible (it is a risk of malware to embed binaries into media files). Almost certainly not with the multiplexers built into VirtualDub2. Maybe if you configure external multiplexers in Options - External encoders...

[v0lt]

How do I add attachments like fonts to videos using VirtualDub2?
No way. Use MKVToolNix.

[v0lt]

Are there any downsides to using DirectX11 or OpenGL?
I tested the increase in frame size.
GDI - Point
DirectDraw - Bilinear
Direct3D 9 - Point/Bilinear/Bicubic
Direct3D 11 - Point/Bilinear/Bad Bicubic
OpenGL - Point/Bilinear/Bad Bicubic

Frame reduction works visually the same for different APIs.

Direct3D 9 supports transparency.

[rgr]

I tested the increase in frame size.
GDI - Point
DirectDraw - Bilinear
Direct3D 9 - Point/Bilinear/Bicubic
Direct3D 11 - Point/Bilinear/Bad Bicubic
OpenGL - Point/Bilinear/Bad Bicubic

Frame reduction works visually the same for different APIs.

Direct3D 9 supports transparency.

Thanks. So it's best to stick with DirectX9.

[nji]

When restoring movies I sometimes have to use lossless format as intermediate step.

Most (if not all) lossless formats use YUV as pixel format.
Now I realized that default subsampling is 422, if not 420.
This worries me.

Doesn't mean anything but 444 mean information loss?
(I hope this question isn't too... well... :)

[LigH]

The most common consumer video formats with an efficient compression use YUV 4:2:0 chroma subsampling anyway. Subsampling 4:2:2 may be used in more or less professional encoder profiles which are hardly used in digital broadcast or disc media standards.

The Ut Codec package offers a variety of specialized lossless codecs with separate FourCC identifiers per subsampling and bitdepth.

[nji]

So... if I choose one of VD2's lossless codecs (x265 lossless, FFV1 lossless, HUFYUV lossless)
with default subsampling settings I won't get lossless?
I explicitely have to change subsampling to YUV 4:4:4 to get true lossless?

(I wonder why the combination of codecs called "lossless" with anything but YUV4:4:4 or RGB
is called lossless at all. Isn't it misleading?).

Only uncompressed and lagarith do real lossless?

(If that's the case it's probably not only me to be shocked... for all the data lost)

[LigH]

Rather the opposite. I would always recommend to use a codec for intermediate files which matches the same chroma subsampling as the output of your workflow up to that point. If you did not change the pixel format during a previous edit, then it shall be the same as the input video's.

If you force a higher chroma resolution than your original workflow's, then the codec may have to upscale the chrominance planes which may not be a lossless operation. And it is also a waste of space.

[nji]

Sorry, but no, you must be wrong.

Take an example of RGB input format;
then do some filter (say blur just of an example. format stays RGB(A)).

Now I want to save it lossless (to do some external manipulation or whatever).

If I use one of the mentioned lossless codecs above:

FFMPEG / x265 lossless takes YUV 4:2:0: (larger data loss).
FFMPEG Huffyuv lossless takes YUV4:2:2 P16 : data loss.
FFMPEG Huffyuv lossless takes RGB24: OK.

I'm puzzled (that's why I'm asking)...
Or does x265 lossless do some trick so that 4:2:0 acutally is without data loss?

[LigH]

Of course, if your original footage is RGB (e.g. the output of a 3D animation system or a screen recording), and you don't convert it during your filtering, then use a lossless RGB codec.

But no DVB / DVD / Blu-ray is encoded in RGB. Consumer formats use an efficiently compressed video format (e.g. H.264 or VC-1) in YUV, almost certainly with 4:2:0 chroma subsampling.

If you convert your video to YUV 4:4:4 during your filtering, then use a YUV 4:4:4 codec.

[nji]

So you got me wrong all the time.

I never adressed the task of simple format conversion of movies (Source in, destination out).

As I explained in my first post I'm about to lossless save a movie within my workflow.

Usually it's not me to explicitely perform pixel format conversion,
but many filters in VD2 do (e.g. output RGBA),
and obviously most of the explicitely stated lossless codecs do data loss
due to their default subsampling.
(Actually I don't understand what "lossless" means at all in these cases?)

[LigH]

OK, once again for dummies...

If your filtering workflow returns RGB, then using a lossless RGB codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.
If your filtering workflow returns YUV 4:4:4, then using a lossless YUV 4:4:4 codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.
If your filtering workflow returns YUV 4:2:2, then using a lossless YUV 4:2:2 codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.
If your filtering workflow returns YUV 4:2:0, then using a lossless YUV 4:2:0 codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.

If any of your filters convert between two color spaces, there will be a loss between the video input and the filtering output in addition to the filter effect.
Using AviSynth filtering may avoid this because most AviSynth filters support many color spaces without a required color space/subsampling conversion.

[nji]

OK, once again for dummies...

Pardon, I don't see why it was you pointing the possibility of having to change the default subsampling (even when lossless codec chosen), but me.

Moreover I don't think "dummies" is appropriate in the forum.

[LigH]

:o Sorry for that, today I have several sources of stress in parallel...

[rgr]

So... if I choose one of VD2's lossless codecs (x265 lossless, FFV1 lossless, HUFYUV lossless)
with default subsampling settings I won't get lossless?

If your source is YUV420, then lossless YUV420 will be lossless. If your source is YUV422, then lossless YUV422 will be lossless (but lossless YUV420 will not be lossless). If your source is YUV444, then lossless YUV444 will be lossless (but lossless YUV420 and YUV422 will not).

[rgr]

Take an example of RGB input format;
then do some filter (say blur just of an example. format stays RGB(A)).

Now I want to save it lossless (to do some external manipulation or whatever).

If I use one of the mentioned lossless codecs above:

FFMPEG / x265 lossless takes YUV 4:2:0: (larger data loss).
FFMPEG Huffyuv lossless takes YUV4:2:2 P16 : data loss.
FFMPEG Huffyuv lossless takes RGB24: OK.

I'm puzzled (that's why I'm asking)...
Or does x265 lossless do some trick so that 4:2:0 acutally is without data loss?

No RGB->YUV conversion is completely lossless, although RGB->YUV444 can be considered as such.

[LigH]

And if you have a YUV420 source, but you filter the video before saving and the filter converts to RGB, then use an RGB lossless codec.

[nji]

Thankyou for all your kind help.

So the situation in general seems quite easy I might think.

BUT the point is:
I would never have expected that when choosing a lossless codec
(without further regard to pixel format) it would be lossless only
when there's a pixel formats' matching for filter graph output and encoder.

"Lossless means lossless" that's what I always thought.
(And I suspect I'm not the only "simple" user thinking so).
Now I'm aware that I produced lot of quality loss due to that presumption.

My proposal would be to have matching pixel formats as default
for lossless formats.

However I found out that some lossless formats do well only for
appropriate pixel values (lagarith-rgb, avc-yuv,...).

Moreover I made the observation that if I choose matching pixel formats
then the various lossless codecs don't seem to have much difference in
file size (bits/pixel is always about bitdepth) ???

The way it is now one seems have to take utmost care no to have
quality drop.

[LigH]

Lossless codecs have a limit of compressibility. Claude Shannon, father of the modern Theory of Information, called it the entropy.

[poisondeathray]

No RGB->YUV conversion is completely lossless, although RGB->YUV444 can be considered as such.

8bit RGB <=> YUV444P10 can be lossless and reversible if done properly. This was proven for all 16777216 8bit RGB colors in other threads


My proposal would be to have matching pixel formats as default
for lossless formats.


It would be difficult to implement properly, because of the myriad of pixel formats, and many codecs only support a tiny subset of formats. e.g. YUV420P10 is getting quite common, but lagarith, huffyuv do not support it

Actually official lagarith (not vdub lagarith) RGB default setting will use whatever pixel type is sent and reproduce it, if supported. e.g. If you send RGB24, it will use RGB24, if you send YUY2, it will use YUY2, if you send YV12, it will use YV12


However I found out that some lossless formats do well only for
appropriate pixel values (lagarith-rgb, avc-yuv,...).


Not sure what "do well" means...? Does that mean user error ? Does it mean unsupported pixel type and some inserted auto-conversion ? Does that mean compression ratio ?

lagarith supports YV12, YUY2, RGB . Lossless AVC supports 8 and 10bit YUV, all common subsampled formats 420,422,444, and RGB


Moreover I made the observation that if I choose matching pixel formats
then the various lossless codecs don't seem to have much difference in
file size (bits/pixel is always about bitdepth) ???


How much is "much difference" for you ?

lagarith should generally be a few% smaller than huffyuv in the same pixel format. The trade off is it's slower for encode/decode speed

The most significant factor in most situations for lossless compression ratio will be the use of I-frame only vs. long GOP (temporal compression) lossless compression . On average you might expect between 10-35% smaller, it's content dependent . Lagarith /huffyuv/ut video are i-frame only. x264/x265/ffv1 have long GOP options



The way it is now one seems have to take utmost care no to have
quality drop.

It always has been that way. Not just for video and audio. If you're sloppy with anything in life, you run a higher risk of quality problems (e.g if you're painting a fence, if you're fixing a car, fixing plumbing ....)

[LigH]

YUV can be several different color spaces, depending on the angles towards the RGB color cube. There is a special color space YCgCo or YCoCg which uses a symmetric orientation, this conversion from and to RGB is indeed lossless and reversible even in 8 bit precision only.

[Leo 69]

Thanks to v0lt for continuous updates for this crucial application.

[v0lt]

Test build VirtualDub2 v2.4.0.917 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Fixed crash of 64-bit version when using highpass, lowpass audio filters.
avlib_vdplugin 1.0.0.377.

[rgr]

Something's wrong with ProRes encoding -- YUV444 profiles save in YUV422 format.
YUV444+alpha profiles, on the other hand, always save in YUV444P12 (maybe that's how it's supposed to be, but I think without XQ, it should save in P10).

There's a missing YUV444P10 profile, but there should be two:

10-bit 4:4:4 Profiles:
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444XQ (10-bit)

.

[v0lt]

Something's wrong with ProRes encoding -- YUV444 profiles save in YUV422 format.
YUV444+alpha profiles, on the other hand, always save in YUV444P12 (maybe that's how it's supposed to be, but I think without XQ, it should save in P10).
Show a screenshot of the settings when you get the wrong result.

There's a missing YUV444P10 profile, but there should be two:

10-bit 4:4:4 Profiles:
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444XQ (10-bit)

And they were there (at least one) before the encoder window changed.
The "4444" and "4444xq" profiles are available when selecting the "YUV 4:4:4 + Alpha" format.

[rgr]

https://i.imgur.com/VfHbgha.png

Which prores_ks setting is Quality equivalent to? Bitrate?

[poisondeathray]

Something's wrong with ProRes encoding -- YUV444 profiles save in YUV422 format.


In Apple ProRes terminology (see the whitepaper), "HQ" indicates 10bit422 pixel type only . The term "HQ" is reserved. "HQ" is not a quality control slider for a given pixel type. For example, you cannot have "Prores HQ" and 4:4:4 .

4:4:4:4 pixel type can only be Apple Prores 4:4:4:4 and Apple Prores 4:4:4:4XQ

So the profile "HQ" setting selection in vdub2 is probably overriding the YUV 444 settings, and that would be correct behaviour. Perhaps it could be redesigned so "illegal" combinations are greyed out, or maybe a warning message

[v0lt]

https://i.imgur.com/VfHbgha.png
It works correctly for me. Here's how it plays in ffplay
Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 640x480, 17283 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)

Which prores_ks setting is Quality equivalent to? Bitrate?
-qscale:v
https://trac.ffmpeg.org/wiki/Encode/VFX#Prores

[poisondeathray]

It works correctly for me. Here's how it plays in ffplay
Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 640x480, 17283 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)



I'd argue that's technically incorrect - and that could cause compatibility issues in some programs

fourcc "apch" indicates Apple ProRes 422 (HQ)

[rgr]

It works correctly for me. Here's how it plays in ffplay
Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 640x480, 17283 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)


It doesn't matter anymore (last post)
The source was 16-bit YUV444?
I'll check again.

-qscale:v
https://trac.ffmpeg.org/wiki/Encode/VFX#Prores[/QUOTE]

Thx.

[rgr]

I'd argue that's technically incorrect - and that could cause compatibility issues in some programs

fourcc "apch" indicates Apple ProRes 422 (HQ)

I think it would be best to use the options provided here: https://github.com/oyvindln/vhs-decode/wiki/ProRes-The-Definitive-FFmpeg-Guide

Profiles can be the following:
10-bit 4:2:2 Profiles
-profile:v 0 -pixel_format yuv422p10lep - ProRes Proxy
-profile:v 1 -pixel_format yuv422p10lep - ProRes LT
-profile:v 2 -pixel_format yuv422p10lep - ProRes 422 (Standard)
-profile:v 3 -pixel_format yuv422p10lep - ProRes HQ

10-bit 4:4:4 Profiles
-profile:v 4 -pix_fmt yuva444p10le ProRes 4444 (10-bit)
-profile:v 5 -pix_fmt yuva444p10le ProRes 4444QX (10-bit)

12-bit 4:4:4 Profiles
(Well when FFmpeg finally pushes a fix for ProRes 12-bit...) -- ???
-profile:v 4 -pix_fmt yuva444p12le ProRes 4444 (12-bit)
-profile:v 5 -pix_fmt yuva444p12le ProRes 4444QX (12-bit)


The FourCC codec IDs for the different Apple ProRes variants:
Apple ProRes 422 High Quality: apch (hcpa in little-endian)
Apple ProRes 422 Standard Definition: apcn (ncpa in little-endian)
Apple ProRes 422 LT: apcs (scpa in little-endian)
Apple ProRes 422 Proxy: apco (ocpa in little-endian)
Apple ProRes 4444: ap4h (h4pa in little-endian)
Apple ProRes 4444XQ: ap4x (x4pa in little-endian)

[rgr]

https://gcdnb.pbrd.co/images/v4mbaPC26ICN.png?o=1

gives:

Video: APCH 1920x1080 59.94fps 1012627kbps [V: prores hq, yuv422p10le, 1920x1080, 1012627 kb/s] (MediaInfo)

but also MediaInfo:
Video
ID : 1
Format : ProRes
Format version : Version 1
Format profile : 422 HQ
Codec ID : apch
Duration : 67 ms
Bit rate mode : Constant
Bit rate : 1 013 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) FPS
Color space : YUV
Chroma subsampling : 4:4:4
Scan type : Progressive
Bits/(Pixel*Frame) : 8.147
Stream size : 8.06 MiB (100%)
Writing library : Lavc
Matrix coefficients : BT.709

ffmpeg:
Stream #0:0[0x1]: Video: prores (HQ) (apch / 0x68637061), yuv444p10le, 1920x1080, 1012627 kb/s, 59.94 fps, 59.94 tbr, 60k tbn (default)

The results are ambiguous :)

Now I know why Vegas is going crazy with these files and interpreting them however it wants :)

Edit:
But looking at frame properties makes it even more interesting :)

frame,video,0,1,0,0.000000,0,0.000000,0,0.000000,1001,0.016683,36,2105459,1920,1080,0,0,0,0,yuv444p12le,N/A,I,0,0,0,0,tv,bt709,unknown,unknown,unspecified
frame ,video,0,1,1001,0.016683,1001,0.016683,1001,0.016683,1001,0.016683,2109591,211401 6,1920,1080,0,0,0,0,yuv444p12le,N/A,I,0,0,0,0,tv,bt709,unknown,unknown,unspecified

[poisondeathray]

I think it would be best to use the options provided here: https://github.com/oyvindln/vhs-decode/wiki/ProRes-The-Definitive-FFmpeg-Guide


That would be ideal ;

But for any alpha channel 4444 profiles, prores_ks should be used instead - because -c:v prores still has the "not full alpha channel bug" . eg. for 12bit you get 4092 instead of 4095 . This leads to partial transparency when something should be 100% opaque. (But this is not a vdub2 issue , it's a libavcodec issue)




The results are ambiguous :)

Now I know why Vegas is going crazy with these files and interpreting them however it wants :)

That's why it's important to get as close as to apple certified specifications as possible. Various bugs and handling issues in different programs