VirtualDub2

[rgr]

But I must say that I haven't been able to get Yuv444p10 with FFmpeg either. FFmpeg (7 and 8) happily reports that "output will be in Yuv44p10," but the final output is always 12-bit.

Report submitted: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20468

[rgr]

prores_ks should be used instead

Right.

[poisondeathray]

But I must say that I haven't been able to get Yuv444p10 with FFmpeg either. FFmpeg (7 and 8) happily reports that "output will be in Yuv44p10," but the final output is always 12-bit.

Report submitted: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20468


Apple Prores 4444 is supposed to be 12bit (the whitepaper says "up to") , and up to 16bit for the alpha

Funny because Years ago, people were complaining that the ffmpeg variant was 10bit only, it finally got fixed 12bit to match official Prores 4444 a few years ago. Now you're complaining you want 10bit ??? :D

But I've never seen Official Apple Prores 4444 come in 10bit (from a certified implementation) . There are old ffmpeg produced 10bit4444 prores streams which sometimes caused problems in editors such as glitched frames - I wouldn't consider those completely valid streams, but early days for ffmpeg prores

[rgr]

Apple Prores 4444 is supposed to be 12bit (the whitepaper says "up to")

"Up" doesn't mean "only".

From official spec:
Like standard Apple ProRes 4444, this codec supports up
to 12 bits per image channel and up to 16 bits for the alpha channel.

[rgr]

OK, available profiles:


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 (unavailable now)
-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
-profile:v 4 -pix_fmt yuva444p12le ProRes 4444 (12-bit)
-profile:v 5 -pix_fmt yuva444p12le ProRes 4444QX (12-bit)

And pix_fmt doesn't have to be specified.

[poisondeathray]

Profile 4 and 5 for 10bit are the same as 4 and 5 for 12 bit. (ie. There is no 6 or 7; it's not a typo, you can look at the ffmpeg libavcodec code)

I'd feel better if you could produce an official Apple Certified Prores 4444 stream at 10bit . I tried before with various Apple Certified software, it's not possible (at least back then). If you could do that, it would provide evidence for developer to make that a valid option

When you make hacked streams that software does not expect or it's a bit "off" from the certified implementations, you potentially end up with problems. Look at your Sony Vegas experience with some of these streams.

If you really wanted to, try using a ffmpeg build about 6-7 years ago. The Prores 4444 streams were 10bit only (12bit was not available) - this is what people were complaining about . Those streams had problems in software like Resolve (I'm not sure if it was the direct reason)

[rgr]

Profile 4 and 5 for 10bit are the same as 4 and 5 for 12 bit. (ie. There is no 6 or 7; it's not a typo, you can look at the ffmpeg libavcodec code)

Yes, I know -- in these cases pix_fmt determines the bit depth (i.e. it should, because it doesn't work).

[rgr]

Those streams had problems in software like Resolve (I'm not sure if it was the direct reason)

Are you suggesting that if an app has a problem with a file encoded according to the official specification, it's the video file's fault, not the app? :)

[poisondeathray]

Are you suggesting that if an app has a problem with a file encoded according to the official specification, it's the video file's fault, not the app? :)

There are no problems with Apple certified streams (or very rare compared to the ffmpeg/libavcodec produced prores )

The situation has improved significantly with "unofficial" ffmpeg/libavcodec created prores encodes - but you still get cases of bugs and odd behaviour . The "unofficial" streams have a significantly higher failure rates on Mac HW silicon decoding affecting many programs (Resolve, Adobe, FCPX) - bugs like flickering, odd bad frames . SW decodes tend to have fewer problems, but they still occur albeit much less frequently than 5-10 years ago

[rgr]

I'm just noticing that last month VirtualDub created a YUV444P10 file for me using the HQ profile :)

frame,video,0,1,0,0.000000,0,0.000000,0,0.000000,1001,0.016683,36,2649757,1920,1080,0,0,0,0,yuv444p10le,N/A,I,0,0,0,0,tv,bt709,unknown,unknown,unspecified

And this despite the fact that Media Info at MPC thinks otherwise.

Video: APCH 1920x1080 59.94fps 1155238kbps [V: prores hq, yuv422p10le, 1920x1080, 1155238 kb/s]

[v0lt]

Test build VirtualDub2 v2.4.0.918 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
avlib_vdplugin 1.0.0.386.
The FFmpeg 8.0 x64 build from BtbN is used.
The FFmpeg 8.0 win32 build from Defisym is used.
Adjusted profile selection for ProRes encoder.

[jpsdr]

It exists nsVDXPixmap::kPixFormat_RGB_Planar32F and nsVDXPixmap::kPixFormat_RGBA_Planar32F, but is opening RGBPS or RGBAPS implemented in Virtualdub2 ?
If i ask, it's because of this (https://forum.doom9.org/showthread.php?p=2022500#post2022500).

[v0lt]

It exists nsVDXPixmap::kPixFormat_RGB_Planar32F and nsVDXPixmap::kPixFormat_RGBA_Planar32F, but is opening RGBPS or RGBAPS implemented in Virtualdub2 ?
Obviously you should make a correct video file with such RAW format and check.

If i ask, it's because of this (https://forum.doom9.org/showthread.php?p=2022500#post2022500).
VirtualDub works with AviSynth via a virtual AVI file. This mode has many limitations.

[coolgit]

2.4.0.891
Job control files crash every 3 files.

[v0lt]

2.4.0.891
Job control files crash every 3 files.
I couldn't reproduce the crash.
v2.4.0.918 x64.

[Washka]

Hello,
Can someone from China download this if possible and put on some Gdrive or Mega?
https://wenku.csdn.net/doc/4xtmw3ftrf

There are FF* filters inside, probably newer than on codec com, files are bigger.

[v0lt]

Test build VirtualDub2 v2.4.0.918 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
avlib_vdplugin 1.0.0.389.
Allowed opening AviSynth scripts.

[jay123210599]

How do I create my own custom filters for VirtualDub2? I want to create one that debands videos with these settings:

clip = vstools.depth(clip1, 32)
default_mpv_deband = core.placebo.Deband(clip, planes=7, iterations=4, threshold=3.44, radius=16.0, grain=0.5)
default_mpv_deband = vstools.depth(default_mpv_deband, 8)

[LigH]

VirtualDub filters (*.vdf files) must be written in a high level language (e.g. C++) to be compiled as a DLL with a specific interface.

I wonder if it might be possible to write a VapourSynth host filter as VDF. But I doubt its efficiency, you can as well just open the VS script completely filtering the source.

[jay123210599]

VirtualDub filters (*.vdf files) must be written in a high level language (e.g. C++) to be compiled as a DLL with a specific interface.

So it's impossible?

[LigH]

As Far As I Know ™ - it's not as simple as writing a script. It is rather comparable to writing a binary plugin for AviSynth because a script alone can't handle the problem.

But with a little patience, someone who already wrote such software will tell you for sure.

[v0lt]

How do I create my own custom filters for VirtualDub2?
A good example of a video filter with comments.
http://acobw.narod.ru/samples.zip

[_Al_]

How do I create my own custom filters for VirtualDub2? I want to create one that debands videos with these settings:

clip = vstools.depth(clip1, 32)
default_mpv_deband = core.placebo.Deband(clip, planes=7, iterations=4, threshold=3.44, radius=16.0, grain=0.5)
default_mpv_deband = vstools.depth(default_mpv_deband, 8)
Instead of creating a dll, just create a python function, import it and then use it.

[v0lt]

VirtualDub2 v2.4.1.930 (https://github.com/v0lt/VirtualDub2/releases/tag/2.4.1)

Changes:
Settings are now stored in HKEY_CURRENT_USER\SOFTWARE\VirtualDub2\VirtualDub.
Saving of some settings has been reworked.
The "Display" settings panel has been redesigned.
Fixed crash of 64-bit version when using highpass, lowpass audio filters.
Code refactoring for modern compilers.
Cosmetic changes.

Updated avlib-1.vdplugin to version 1.0.1.393.
- The FFmpeg 8.0 x64 build from BtbN is used.
- The FFmpeg 8.0 win32 build from Defisym is used.
- Added saving and reading of encoder settings from the registry.
- Added hardware video encoders NVENC, QSV, AMF for H.264 and HEVC.
- Added hardware video encoders NVENC, AMF for AV1.
- FFV1 version 0 video encoding is no longer supported.
- Adjusted profile selection for ProRes encoder.
- Allowed opening AviSynth scripts.
- Cosmetic changes.

[Washka]

I try this new version VirtualDub2 v2.4.1.930 64bit and sometimes when load *.avi file from avs i got some error: requested frame not found; next valid frame = 39

Codecs are:

Video: ProRes (apch) 720x576 25fps [Video 1 [Default] (ProRes (apch), 720x576, 25.000 fps)]
Audio: MP3 48000Hz 2.0 chn [Audio 1 (MP3, 48.0 kHz, 2.0 chn)]

When i start play with second play button in VirtualDub its going ok, but when rewind video and start again few times, sometimes error to pop, video won`t start, left video window go black and got error message: requested frame not found; next valid frame = 39 but this number is random. VirtualDub2_v2.3.0.845 64Bit < works with no problem. I did not try to capture from VHS with this new version from today. Probably is working fine.

avs file is

SetFilterMTMode("QTGMC", 2)
FFVideoSource("Test.mkv", cachefile="Test.ffindex")
AssumeTFF()
QTGMC(Preset="Very Slow", FPSDivisor=1, TR2=3, Sharpness=0.4, EZKeepGrain=0.6, SourceMatch=3, Lossless=2, EdiThreads=6, matchpreset="Very Slow", matchpreset2="Very Slow")
Crop(10,0,-10,-8)
Spline64Resize(768,576)
Prefetch(16)
Tweak(hue=0, sat=1.11, bright=-8, cont=1.0, coring=false, realcalc=true)
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)

I this case i`m adding external normalized *.mp3 file as Direct Stream Copy and in final saved video have no audio. Audio is there only if i put in full processing mode. Usual i have PCM audio when capturing so there is no loss and need for 2x compression.

[v0lt]

sometimes when load *.avi file from avs i got some error: requested frame not found; next valid frame = 39
...
FFVideoSource("Test.mkv", cachefile="Test.ffindex")
I don't understand you.

Also, if you write "sometimes," it's likely that the preview won't play without your video file. Have you tried other files in different formats? The Avisynth filters you're using may also be causing the issue. Try disabling everything except FFVideoSource.

[LigH]

I have some issues too.

When I just select a very complex *.avs file in the File-Open dialog, VirtualDub2 v2.4.1.930 already takes so much time to analyze it that the process does not respond for dozens of seconds.

Trying to "save and reload" [F5] the file after editing, I get an error that the file cannot be opened for writing. A second time it seems to write it (no write error), but FFmpeg cannot open the video. Another time there is a more complex error:

---------------------------
File open error
---------------------------
Avisynth open failure:
nnedi3: Error with the TheadPool while getting UserId!
(..\import.avsi, line XX)
(script.avs, line YY)
---------------------------
OK
---------------------------

And quitting the application,

An out-of-bounds memory access (access violation) occurred in module 'VirtualDub2'...
...reading address 0000000000000000.

Apparently the script was not even saved.

VirtualDub2 v2.4.0.917 does not delay the selection of AVS files. It saves the script and reopens it in the main window reliably.

VirtualDub2 v2.4.0.918 (which uses a newer libav set for the first time) works just as well.

[v0lt]

@Washka, @LigH
In VirtualDub2 v2.4.1 you can select "input driver" for AviSynth script files:
Cashing input driver
AVIFile/Avisynth input driver (internal)

[LigH]

I could, but...

When I select an MKV or MP4 file in the same directory, then the Open dialog defaults to the "Caching input driver".

And when I select an AVS file after that, it tries to read it with the "Caching input driver" again, so I need to select the "AVIFile/Avisynth input driver" again (after waiting until the application responds again).

It would possibly be useful if VirtualDub2 2.4.1 were able to remember that it should use the "AVIFile/Avisynth input driver" for AVS files by default. That might require an extension/driver preference dialog.

[rgr]

@Washka, @LigH
In VirtualDub2 v2.4.1 you can select "input driver" for AviSynth script files:
Cashing input driver
AVIFile/Avisynth input driver (internal)

What's the difference between them? (I didn't even notice it, I'm using the default one, which is probably AVIFile).

[LigH]

"Caching input driver" uses libav functions, the core of ffmpeg. (cache, not cash)

"AVIFile/Avisynth input driver" uses (probably the AviSynth API for AviSynth scripts?, and) the good old AVIFile functions Windows provides since "Video for Windows" was introduced in Windows 3.1x to handle AVI files.

[v0lt]

The "Caching input driver" uses FFmpeg. Therefore, it supports more AviSynth+ formats (http://avisynth.nl/index.php/Avisynthplus_color_formats). Video parameters (BT.601/709, limited/full range) should also be detected correctly.

[LigH]

I agree, AVIFile functions don't know about AviSynth+ enhancements. So FFmpeg, which uses most recent AviSynth+ headers, is suprior ... when it works reliably.

It worked reliably in VirtualDub2 2.4.0.917 with avcodec-61 and avformat-61.
It worked reliably in VirtualDub2 2.4.0.918 with avcodec-62 and avformat-62.

It fails irreliably in VirtualDub2 2.4.1.930 with avcodec-62 and avformat-62. I'll gladly try to help solving this issue if I am able to.

[v0lt]

Test build VirtualDub2 v2.4.2.931
Updated avlib_vdplugin 1.0.2.396.
- Avisynth scripts are identified by file extension. This should fix the file open window freezing for some scripts.

[rgr]

The "Caching input driver" uses FFmpeg. Therefore, it supports more AviSynth+ formats (http://avisynth.nl/index.php/Avisynthplus_color_formats). Video parameters (BT.601/709, limited/full range) should also be detected correctly.

I didn't even know about it.
After selecting the *.avs file, the Caching/AVFile selection window is grayed out, and I can't change it. I can only change it by selecting FFmpeg:video or AviFile input driver.
However, when I open it via Caching, I generally get "Error reading source frame xx, requested frame not found, next valid frame=17."
There's no problem with AviFile.

v 918.

[LigH]

VirtualDub2 v2.4.1.931 has no more delay selecting AviSynth scripts in the Open dialog.

But it cannot save anymore the script just loaded into the editor (as if it is opened exclusively without sharing flag and kept open):

---------------------------
Error
---------------------------
The file cannot be opened for writing.
---------------------------
OK
---------------------------

[v0lt]

But it cannot save anymore the script just loaded into the editor (as if it is opened exclusively without sharing flag and kept open)
It is a very bad idea to edit files opened with the "Caching input driver".

I could make the "AVIFile/Avisynth input driver (internal)" default. But I don't think that's the best solution.

However, when I open it via Caching, I generally get "Error reading source frame xx, requested frame not found, next valid frame=17."
You must understand that the problem that is reproduced only for you does not exist for everyone else. Unfortunately, in my experience, most users don't understand this.

[LigH]

It is a very bad idea to edit files opened with the "Caching input driver".

Eeh ... excuse me??? That always worked in all the previous VirtualDub2 versions since VirtualDubMod:

Open the *.avs file; pop up the internal AviSynth source editor; edit the script; save the script [F2]

[v0lt]

Eeh ... excuse me??? That always worked in all the previous VirtualDub2 versions since VirtualDubMod:
And have you always used the "Caching input driver" for AviSynth scripts?

[LigH]

I always used the driver VirtualDub2 selected by default, I never selected any other. Let's check all the previous versions I still have installed in parallel:


VirtualDub2 (build 44282/release-AMD64): "AVIFile/Avisynth input driver (internal)" is preselected when selecting a *.avs file and locked
VirtualDub2 x64 v2.2.0.755: "AVIFile/Avisynth input driver (internal)" is preselected when selecting a *.avs file and locked
VirtualDub2 x64 v2.3.0.845: "AVIFile/Avisynth input driver (internal)" is preselected when selecting a *.avs file and locked


Same behaviour since "forever":
https://www.ligh.de/pics/VD2_avs_input.png

You changed it for v2.4.1, now it fails.

I guess if you want to support AviSynth+ with the modern API, you might need to write a new input driver which allows saving the script being edited, and use this only when a *.avs[i] file is selected.

[v0lt]

Test build VirtualDub2 v2.4.2.932 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Updated avlib_vdplugin 1.0.2.397.
- Set the lowest priority for AviSynth scripts. This returns the default "AVIFile/Avisynth input driver" selection for .avs files.

[rgr]

You must understand that the problem that is reproduced only for you does not exist for everyone else. Unfortunately, in my experience, most users don't understand this.

I tested the latest test version.
1. When selecting an AVS file, I can choose Caching or AVIFile.
2. When selecting "Caching...", the "Error reading source frame xx" errors disappeared -- everything seems to work (at first glance). So, the error wasn't unique to me, but only I had thoroughly tested it.
3. It's unfortunate that the ProRes encoder selection window doesn't reflect the prores_ks profiles. I haven't tested further.

[LigH]

Test build VirtualDub2 v2.4.2.932

File - Open: Selecting an MKV or MP4, "Caching input driver" is preselected and locked. Selecting an AVS, "AVIFile/Avisynth input driver (internal)" is preselected but I could change it.

Opening an AVS with "AVIFile/Avisynth input driver (internal)", I can freely move through the timeline. Also to frame 0. No issues so far.

Opening an AVS with "Caching input driver", I can freely move through the timeline. But when I return to frame 0, I get this error "Error reading source frame XX: requested frame not found; next valid frame = YYY". And YYY is the last frame VD2 displayed before I jumped back to frame 0. Every frame between 0 and YYY-1 is now unavailable and grey until I reach frame YYY, from there every frame is available again, even before YYY, until I reach frame 0 again.

Also: When I opened the AVS with the A/A-id, I can save the edited script out of the internal script editor. But when I opened the AVS with the C-id, saving is not possible.

[v0lt]

Ok. I reproduced the issue with accessing some frames using the scripts from C:\Program Files (x86)\AviSynth+\Examples\

avlib_vdplugin uses four methods to obtain the desired frame from FFmpeg. It turned out that the wrong one was used for AviSynth. I changed it to the one used for image sequences, and it seems to work well.

Test build VirtualDub2 v2.4.2.934 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Updated avlib_vdplugin 1.0.2.401.
- Fixed frame navigation for Avisynth script files.

[LigH]

Seeking in the timeline is now reliable.

But not being able to save the script in the editor makes opening the script with the C-id useless.

[v0lt]

But not being able to save the script in the editor makes opening the script with the C-id useless.
Use the "AVIFile/Avisynth input driver" for .avs files. It's now the default (in the latest test build).

If the "Caching input driver" is automatically selected for .avs files, you only need to force the "AVIFile/Avisynth input driver" to be selected once in the file opening dialog. Or reset the settings.

[LigH]

Of course I will prefer the A/A-id for AVS. Thank you for making it the extension's default again.

Still, I wonder if there is any reason to use the C-id for AVS, at least a theoretical advantage of additional information useful in any workflow inside VD2. If so ... how about adding the AviSynth+ API to the A/A-id?

[v0lt]

Still, I wonder if there is any reason to use the C-id for AVS, at least a theoretical advantage of additional information useful in any workflow inside VD2
A simple example:
BlankClip(width=1280, height=720, pixel_type="YUVA420P8")
Info()
Also, the following formats will not work: RGBPS, RGBAPS, Y16, YUVA420P16, YUVA422P8, YUVA422P16.

[LigH]

"Special" colour spaces, I see ...

So, in your opinion, would adding the native AviSynth+ API to the A/A-id be "close to impossible"?

[v0lt]

You can also test the following scripts:
Colorbars(1280, 720)
ConvertToYUV444(matrix="Rec601")
propShow(size=40)
Colorbars(1280, 720)
ConvertToYUV444(matrix="Rec709")
propShow(size=40)

So, in your opinion, would adding the native AviSynth+ API to the A/A-id be "close to impossible"?
I don't plan to make any major changes to VirtualDub2. The code is complex, and I don't have much time for that.