VirtualDub2

[LigH]

Did just a very quick test (slow preset CRF, custom option "--nr"). Encoded well, result comparable to a previous encode with same options, open in VDub2 again, play in MPC-BE.

Just like the previous encode with the shipped x264-8b, both encodes also had the same error: Premature abort during playback in VDub2, "requested frame not found; next valid frame = 484" near the end (but all frames are displayed when going forward frame by frame). May not be the fault of the encoder but of the playback system or multiplexers, same error with MP4 +faststart, MOV +faststart, and MKV. / x264-10b, MP4 +faststart

[v0lt]

@LigH
Thank you.

Test build VirtualDub2 v2.5.0.1057
Improved Unicode support.
Updated x264 video encoders (libx264 core 165 r3215 32c3b80). Thanks to autodidact from https://forum.videohelp.com/.
Updated avlib_vdplugin 1.1.0.428.
Updated scripted_vdplugin 0.3.2.133:
- Fixed a crash when opening AviSynth+ scripts in some rare situations.

PS: Updated to v2.5.0.1057.

[rgr]

xxxxx

[v0lt]

Test build VirtualDub2 v2.5.0.1064
Fixed display of video window in capture mode.
Updated avlib_vdplugin 1.1.0.430:
- Updated FFmpeg 8.0.1.

[rgr]

Originally Posted by v0lt

Test build VirtualDub2 v2.5.0.1064
Fixed display of video window in capture mode.
Updated avlib_vdplugin 1.1.0.430:
- Updated FFmpeg 8.0.1.

I don't know if this has already been corrected, but I'm sending the discussion for you to read:
https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20709
Source file: MP4 H265 lossless from VDub.

[v0lt]

Test build VirtualDub2 v2.5.0.1075
Added remembering of video and audio file formats in save dialogs.

[rgr]

Has anyone noticed that when opening an AviSynth script using Caching I.Dr., the first frames of the audio are cut off (not always)? (v1005)

Caching I.D.:



AviFile:

[v0lt]

VirtualDub2 v2.5.1.1095

Changes:
Improved Unicode support.
Script, job, project and settings files are now saved in UTF-8 encoding.
Set "activeCodePage=UTF-8" in the application manifest. This will add support for AviSynth+ scripts with Unicode character paths for Windows 10 v1903 or later.
API change: The VDXAudioEncDefinition structure has been replaced with VDXAudioEncDefinition2, whose mpDriverTagName field points to a wide string.
Added the ability to load processing setting files (.vdscript) using drag-and-drop.
Updated x264 video encoders (libx264 core 165 r3215 32c3b80). Thanks to autodidact from https://forum.videohelp.com/.
Fixed display of video window in capture mode.
Added remembering of video and audio file formats in save dialogs.
Fixed opening of ACM codec settings.
Minor optimizations and cosmetic changes.

Updated avlib-1.vdplugin to version 1.1.1.438.
- Updated FFmpeg 8.0.1.
- Closed GOPs is used for the "x265 - HEVC lossless" encoder.
- API change: The mpDriverTagName field for audio encoders now contains a wide string (see VDXAudioEncDefinition2 in VirtualDub2 v2.5).
- Added "Rate control" parameter for ProRes video encoder.
- Fixed a crash when opening AviSynth+ scripts in some rare situations.
- Added "Load defaults" button for audio encoders.
- Fixed muting of the first audio samples for some media files.

Updated scripted.vdplugin to version 0.3.3.136.
- Fixed a crash when opening AviSynth+ scripts in some rare situations.

[SupermanTV]

v0lt, thank you for the new stable release.

Unfortunately, that ProRes 'Default' setting we discussed here weeks ago is still unusable for me.. (Mb/s capped at 233 / flawed/jumpy frames in output, looks like sync issue)
I do Capturing in ProRes HQ (Camera YUY2 input) and this new setup is awkward.. I have to remember to switch from Default to 'qs slider control'..
Why was it changed in the first place?
Hopefully you can retake/revise the issue... Thanks.

[v0lt]

Originally Posted by SupermanTV

I have to remember to switch from Default to 'qs slider control'..

You only need to set the encoder once and your choice setting will be saved.

[tebasuna51]

Originally Posted by v0lt

VirtualDub2 v2.5.1.1095

Don't work in my old W10 (last test version v2.5.0.1075 work fine), the file avcodec-62.dll is present in the folder:

[v0lt]

Originally Posted by tebasuna51

Don't work in my old W10 (last test version v2.5.0.1075 work fine), the file avcodec-62.dll is present in the folder:

I have VirtualDub2 running and working without any problems.
Windows 10 22H2 x64, VirtualDub2 x 64 v2.5.1.1095, avcodec-62.dll n8.0.1-28-g9c93070155-20251211

PS: The SetThreadDescription function is available starting with Windows 10 v1607. It looks like something is wrong with your Windows.

PPS: You can also try the Win32 version. It has fewer external dependencies.
Or use dll from older version of FFmpeg - ffmpeg-n8.0.1-24-g0cc8bfa50f-win64-gpl-shared-8.0.zip

[rgr]

Originally Posted by SupermanTV

v0lt, thank you for the new stable release.

Unfortunately, that ProRes 'Default' setting we discussed here weeks ago is still unusable for me.. (Mb/s capped at 233 / flawed/jumpy frames in output, looks like sync issue)
I do Capturing in ProRes HQ (Camera YUY2 input) and this new setup is awkward.. I have to remember to switch from Default to 'qs slider control'..
Why was it changed in the first place?
Hopefully you can retake/revise the issue... Thanks.

Does this also happen with other codecs (UTVideo, others)?

[tebasuna51]

Originally Posted by v0lt

PPS: You can also try the Win32 version. It has fewer external dependencies.

Thanks.
Win32 version works fine

Or use dll from older version of FFmpeg

Also with these dll's.

[rgr]

Is VDub freezing for anyone else using DirectX9? I didn't have this problem before, but now it freezes when switching to another window while playing a VDub file. I switched to DirectX11 and the problem disappeared. Switching back to DirectX9, the problem persists.
v1005

[v0lt]

Originally Posted by rgr

Is VDub freezing for anyone else using DirectX9? I didn't have this problem before, but now it freezes when switching to another window while playing a VDub file...
v1005

I don't care about bugs in older versions when a newer release has been released.
I have no issues with Direct3D 9. VirtualDub2 x64 v2.5.1.1095, Windows 10 22H2, Intel UHD 750.

PS:
Test buildVirtualDub2 v2.5.2.1105
Fixed display of the duration of the selected range in the status.
Potential memory leaks have been fixed.

[rgr]

I don't upgrade as long as I have some program windows open.

However, in the latest version, "Source frame rate adjustment" -> "Change so video and audio durations match" doesn't work.

After selecting this option, nothing happens. However, after entering the value in parentheses in the "Change frame rate to:" field, the timeline is corrected.

Edit: however, I can confirm that the latest versions solve the problem of bad audio timeline using Caching input driver+AVS script.

[v0lt]

Originally Posted by rgr

However, in the latest version, "Source frame rate adjustment" -> "Change so video and audio durations match" doesn't work.

I would remove this feature altogether. It always worked incorrectly.

[rgr]

Originally Posted by v0lt

I would remove this feature altogether. It always worked incorrectly.

I suggest not. At least it shows the correct value (I think). And I'd like to point out that entering this value in the field causes the correct behavior (I think).

[v0lt]

I think I understand why you think "Change so video and audio durations match" isn't working. That's because the "Cashing input driver" reports the same duration for both video and audio.
But if you use the built-in "AVI input driver," it will show you something like this.

Current: 23.976 fps. This is the correct value for the video.
"Change so video and audio durations match": 23.982 fps.
This estimated fps value may not be accurate for various reasons:
1. The actual video and audio durations often differ slightly. This is not a reason to change the video frame rate.
2. The audio bitrate specified in the AVI file header may be incorrect. This often happens when 44100 Hz audio is encoded into MP3 using a Fraunhofer encoder. In this case, the header states 128000 bps, but the actual bitrate is approximately 127704 bps. In this case, you need to adjust the audio bitrate, and leave the video frame rate alone.