VirtualDub2

[v0lt]

Test build VirtualDub2_v2.3.0.819
VirtualDub2 is now a Unicode application.
Improved support for file paths with Unicode characters.
Removed obsolete "Disk I/O write mode" setting.

PS: updated to 2.3.0.819.

[isidroco]

Originally Posted by v0lt

I don't understand you.

My script takes in account WHICH version of VirtualDub is installed and changes it's behaviour accordingly. For that basically I use something like:

vDub64.exe /queryVersion >nul
if not errorlevel 42475 ( REM if ver<42475 old version of virtualDub
    set noWavHeader= & REM don't use in new vdub versions
    set oldVDub=// & REM bars "// " comments out newer commands
    set xCompr=H& REM *H* default h264 vfw compressor for old Vdub
)

In a batch, "IF ERRORLEVEL 100" gives true if error is Less or Equal than 100.
As you can see in my example, if the errorlevel returned by /queryVersion is LESS than 42475, implies that is an OLD version of VirtualDub and some workarounds are SET for it.
Your NEW version of VirtualDub breaks natural ascending version order. And ALSO breaks program name (it has ALWAYS been VirtualDub.exe / VirtualDub64.exe ). Whats worst, now both x32 and x64 versions have SAME NAME: VirtualDub2.exe

All those breaking things breaks consistency, and makes your program unusable for me: My script decides to use VirtualDub x32 if certain filters that only exist on x32 are used, or else uses faster x64 platform (h264/h265 are at least twice as fast) under x64. But my script must work on ANY virtualDub version, and your unneeded and unjustified changing both, VirtualDub names and version number lower than before breaks everything and makes a nightmare of exceptions.

I'm dissapointed that instead of improving we have all these problems. And I can't see any advantage in changing an already established naming and versioning convention that you are refusing to follow. VirtualDub x32/x64 has always been on same folder...

[v0lt]

Originally Posted by isidroco

And ALSO breaks program name (it has ALWAYS been VirtualDub.exe / VirtualDub64.exe ).

No. You often forget about "Veedub64.exe".

I'm dissapointed that instead of improving we have all these problems. And I can't see any advantage in changing an already established naming and versioning convention that you are refusing to follow.

I suggested you earlier suggested checking the name of the folder name and the executable file. I also showed how to get the version of the executable file. You don't want this - that's your right. My right to make my version of VirtualDub2 as I like.

VirtualDub x32/x64 has always been on same folder...

You are writing a lie.
Avery Lee released 32 and 64 bit versions of VirtualDub in two different archives. I don't remember him recommending unpacking the two versions into the same folder.

[isidroco]

Originally Posted by v0lt

No. You often forget about "Veedub64.exe".....
You are writing a lie.
Avery Lee released 32 and 64 bit versions of VirtualDub in two different archives. I don't remember him recommending unpacking the two versions into the same folder.

What I meant is that it was always possible to put everything on one folder.
Agreed about Veedub64.exe. But it has never had the SAME name, almost no x86/x64 utility has the same name (ie: PSTOOLS has 64 appended to each utility). If VirtualDub folders are on PATH, it's impossible to know which version will be called when you write VirtualDub2.exe on command prompt. It only creates possible misunderstanding and errors. I would understand if there's an advantage of doing that, but I can't see any. Using same name for two different programs is a mistake. Choose the name that you want, but please use different naming for x86/x64.

You didn't answer about breaking natural version ascending order.

[v0lt]

Originally Posted by isidroco

What I meant is that it was always possible to put everything on one folder.

There is VirtualDub2 v2.1.3.667 x64 and win32, in which the EXE files are named as you want. But it seems you did not even try to write everything in one folder. Otherwise you would have realized that one of the versions would not work properly.

You didn't answer about breaking natural version ascending order.

I answered. The full version number increases monotonically.

I think your approach to defining the VirtualDub type is wrong. I will not support it.

I would make two variables.
The first variable defines the VirtualDub type: original VirtualDub, VirtualDubMod or VirtualDub2.
The second variable defines the architecture: win32 or x64.

[isidroco]

Originally Posted by v0lt

Otherwise you would have realized that one of the versions would not work properly.
...
The first variable defines the VirtualDub type: original VirtualDub, VirtualDubMod or VirtualDub2.
The second variable defines the architecture: win32 or x64.

I didn't realize that, as I didn't put it on use because of the Versioning issue.
Either you should use version numbers starting from 45000 or rename this project to VirtualDub3, as there already is this one with same name: https://sourceforge.net/projects/vdfiltermod/ and version of that one is 44282.
Even on different folders, having same name for both versions will make mistakes possible when launching without specifying full path.

I can't understand why you refuse to return a version number higher than previous VirtualDub versions.

[v0lt]

In version 2.3.0.819, the "/queryVersion" command has been deprecated and now always returns 50000.

[isidroco]

Originally Posted by v0lt

In version 2.3.0.819, the "/queryVersion" command has been deprecated and now always returns 50000.

Thanks, I'm really sorry of being so insistant and bothering you, when I'm grateful of all your work to continue improving this. I would appreciate /queryVersion not being deprecated, but just be used like you did before but starting in 50xxx ie: 50819, etc
And also I would be greatful, if you can consider having different names for x32/x64 versions. As my script is given with vdub name and must figure out which version (by calling /queryVersion) and platform (x32/x64) based on it's name. As a workaround I could check if "64" is on it's path, but it's a weak solution, as it may be altered if user decides to use another folder name.

[Hellboy.]

isidroco
Stop trying to obligate v0lt to change his VirtualDub because you don't want to change your script.
You haven't mentioned a real reason why you can't change your script.
All the excuses you mentioned don't make any sense.
The only conclusion i can see is that you didn't write that script and you don't know how to change it.

[blob2500]

Hi. If I set the VirtualDub.ini file, I found that Virtualdub2 is not completely portable; for example regarding the parameters of the integrated x264 codec, it releases the values ​​in the windows registry. I think this should not happen, or am I wrong?

[shekh]

blob2500

It works that way. VirtualDub.ini holds settings of the main app only, any plugin is on its own. (I still consider this behaviour of codec portable since it does not require installation and registry settings do little harm if any).

[blob2500]

I understand, but with other internal codecs, even plugins, it doesn't happen. Examples: Lagarith, FFmpeg x264...

If they were user-added plugins it would make sense, but since they are internal, provided with the basic package, they should all behave the same way.

[isidroco]

Originally Posted by Hellboy.

isidroco
Stop trying to obligate v0lt to change his VirtualDub because you don't want to change your script.
You haven't mentioned a real reason why you can't change your script.
All the excuses you mentioned don't make any sense.
The only conclusion i can see is that you didn't write that script and you don't know how to change it.

You are extremely disrespectful. I'm not forcing anyone, and explained the lack of logic in having a NEW version of a program with a value less than previous. Also explained that I use BOTH x32 and x64 virtualDubs, and it's difficult to tell which one you are using if they have the SAME name, and I can't predict which folder name user will use. I can change my script, but I also want to mantain compatibility with previous versions as I always did.
Now I'm adding a whole avisynth Noise reduction and preparing an installer because it's getting difficult for a regular user to install and use.

[Leo 69]

v0lt,

Do you know why I get artifacts every time I try to play any H.265 10-bit video in VirtualDub? The issue is very easy to reproduce with basically any 10-bit video encoded with H.265 codec. When played back, about 50% of video is shown normally and 50% is filled with artifacts like this. What can be done? Also, when I try to convert any such video into any other format from within VirtualDub, these artifacts will be in the resulting file as well. So could there be anything wrong with the built-in decoder?

[v0lt]

Originally Posted by Leo 69

The issue is very easy to reproduce with basically any 10-bit video encoded with H.265 codec.

I don't have your "any video".
I have "LG Colors of Journey HDR UHD 4K Demo.mkv" and it plays without artifacts in VirtualDub2 x64 v2.3.0.829.

So could there be anything wrong with the built-in decoder?

The 64-bit build 2.3.0.829 uses FFmpeg 7.1.1 (official build). I don't know what could be wrong there.

[Leo 69]

Originally Posted by v0lt

I don't have your "any video".
I have "LG Colors of Journey HDR UHD 4K Demo.mkv" and it plays without artifacts in VirtualDub2 x64 v2.3.0.829.


The 64-bit build 2.3.0.829 uses FFmpeg 7.1.1 (official build). I don't know what could be wrong there.

Thanks for replying. Upon inspection, I found that 8-bit H.265 videos also have the same issue. Could you please try playing back this sample on your end?

https://app.filen.io/#/d/022ef330-53...jgBv8dGiwdMQmi

I also tried the LG : Colors Of Journey HDR video and can confirm that it doesn't have this issue. I also have several other 60 FPS demos and they don't have this issue, but videos with more regular framerates (23.976, 25 and 29.97) have.

[SeeMoreDigital]

Originally Posted by Leo 69

v0lt,

Do you know why I get artifacts every time I try to play any H.265 10-bit video in VirtualDub?

All fine at my end when feeding VirtualDub2 v2.1.3.667 with HEVC streams extracted from 4K UHD discs.

[Leo 69]

Originally Posted by SeeMoreDigital

All fine at my end when feeding VirtualDub2 v2.1.3.667 with HEVC streams extracted from 4K UHD discs.

Have you tried the sample I posted?

[LigH]

Originally Posted by Leo 69

Could you please try playing back this sample on your end?

https://app.filen.io/#/d/022ef330-53...jgBv8dGiwdMQmi

VirtualDub2 r44282 (release): OK
VirtualDub2 r44282 + avlib 0.7.1.220: broken
VirtualDub2 v2.2.0.755: broken
VirtualDub2 v2.3.0.829: broken

[v0lt]

The "avlib_vdplugin" log when playing "sample.mkv" looks like this:

FFLog: Could not find ref with POC 14
FFLog: Could not find ref with POC 14
FFLog: Could not find ref with POC 14
...
FFLog: Could not find ref with POC 17
FFLog: Could not find ref with POC 17
FFLog: Could not find ref with POC 17

I found a similar issue: https://github.com/mpv-player/mpv/issues/3440