[VirtualDubMod] 1.5.10.2 released (updated) <2006-02-21>

[avexplorer]

Hi i have exactly the same problem. If i open the AVS Editor before i load an avs everything works. But after i loaded a simple avs and opened then the AVS Editor VirtualDubMod crashes with a typical close or details Windows error. I`am using VirtualDubMod 1.5.10.1 build 2407 and Avisynth 2.53. System: AMD 1600+ Win98 SE

I guess this is a Vdubmod 1.5.10.1 Win98SE bug...

Does this happen with anyone using WinXP ?

[stax76]

seems like the range encoding is broke, it encoded the range twice so output is twice as long/big

VirtualDub.Open("E:\\records\\MTV.avs",0,0);
VirtualDub.video.SetMode(1);
VirtualDub.subset.AddRange(0,22020);
VirtualDub.video.SetCompression(0x78766964,0,10000,0);
VirtualDub.SaveAVI("E:\\records\\MTV_FirstPass.avi");

[Leak]

Originally posted by Dolemite
seems like the range encoding is broke, it encoded the range twice so output is twice as long/big.

Try adding

VirtualDub.subset.Clear();

before your AddRange command; as of this version the whole file is selected by default IIRC.

np: B. Fleischmann - 02/00 (Welcome Tourist)

[avexplorer]

I've installed WinXP and the script editor crash is gone.

Is there anyone running Win98SE, Vdubmod 1.5.10.1 with no crashes using the Script editor?

[Belgabor]

Its probably an unicode issue. Didnt have time to look into it yet.

[stax76]

Try adding

VirtualDub.subset.Clear();

thanks, I'll try it and report back if it still don't work

[kilg0r3]

Currently it seems to be something like common sense in the xvid secrtion here that vdmod 1.5.10 is buggy with xvid. I must admit, however, that I do not know in what respect. Are those problems alreday fixed?

cheers!

[stax76]

also interesting to know is if Suiryc stopped working on VDM because of his new project

[gatormac]

Originally posted by kilg0r3
Currently it seems to be something like common sense in the xvid secrtion here that vdmod 1.5.10 is buggy with xvid. I must admit, however, that I do not know in what respect. Are those problems alreday fixed?

cheers!

I personally have found those statements to be false. I've been using VDM 1.5.10 and XVID 1.0 RC2 and now RC3 with no problems whatsoever.

Well, the only thing that might be considered a problem is how VDM handles certain shades of blue. I've encoded School of Rock using Gknot, VDM, and Xvid...everything looks great except for some points in the concert scene near the end where flourescent-type blue lights mesh with the dark background and fog....makes things look very pixelated.

The only reason I assume it is VDM is that eyeballing the video in Gknot it looks fine, but when I load the .avs file in VDM it looks pixelated (only where there is that flourescent blue on the screen). For some reason it doesn't look pixelated within VDM if I ConvertToRGB() on the last line of the .avs file, but the resulting .avi file still looks pixelated, but not quite as bad without the ConvertToRGB().

Its not a bitrate issue as I like to encode at 80% after running gknots compression test...my encodes usually run anywhere from 1 to 1.5GB. Everything else is pretty straight forward, I set XVID no QPEL, no GMC, no packed bit stream, MPEG, B-VOPs 2-1.50-1.00, MSP 6, VHQ 1, chroma motion on, Quants 2-31, trellis enabled. I like to keep things simple and hopefully compatible with standalones (whenever they make a decent one). My encodes all look great, this is the only exception. I even set that scene to a zone with a Q of 1 and it still looks pixelated (especially when they show the boy with the fog machine...look at his face...frames 140280 to 140370).

Is anyone else having this problem?

[Suiryc]

Originally posted by Dolemite
also interesting to know is if Suiryc stopped working on VDM because of his new project

Nope.
I am just lacking free time at the moment.

@gatormac
Maybe it's an issue regarding the colorspace. VDM may display YV12 while GKnot may display YUY2 or maybe even RGB (dunno how it works there).

[Suiryc]

I just fixed the speed issues introduced in 1.5.10.1
Speed issues were as follow:

1. When switching (the issue doesn't appear if you don't switch the value) to 'Even lower', 'Lower', 'Higher' or 'Even higher' the thread priority of the current job, then the rate drop to 0fps (except for people having HT capable processors, according to some reports).

2. When having VBR audio as input (e.g. VBR MP3 in AVI, or external VBR MP3 file), the rate of muxing (at least in Direct Stream Copy) would be 10 times slower than usual.

This makes a new bugfix release (build 2439) availabe on SourceForge.

[loni_blues]

I´m sorry, but bugfix release (build 2439) at Sourceforge seems to be empty!

Regards,
loni_blues

[Suiryc]

Originally posted by loni_blues
I´m sorry, but bugfix release (build 2439) at Sourceforge seems to be empty!

Regards,
loni_blues

I just tested and the zip file is OK.
Maybe you selected a server that actually doesn't have (yet) a copy of the file. In this case just try to download it from another server.

[loni_blues]

Well, it is strange, but I´ve just tried it once more from the same server and now it is there.
Thanks a lot,
loni_blues

[loni_blues]

Hi,

Is there a way to recover virtualdubmod default options besides manually editing the registry?

[Karovaldas]

I just installed the newest bugfix (build 2439) and still can't the AC3 audio to play. When switch to the full processing mode get this error:

"No audio decompressor could be found to decompress the source audio format"

The same audio stream plays fine in 1.5.4.1

The update improved MPEG-2 import speed, though.

Am I missing something?

[Wilbert]

Are people still working on VDubMod? The latest commits seem to be two months old

[erratic]

Originally posted by Karovaldas
I just installed the newest bugfix (build 2439) and still can't the AC3 audio to play. When switch to the full processing mode get this error:

"No audio decompressor could be found to decompress the source audio format"

The same audio stream plays fine in 1.5.4.1

The update improved MPEG-2 import speed, though.

Am I missing something?

This is from the latest changelog:
- Removed internal AC3 decompressing since fccHandler made an ACM codec for AC3.
So you need the AC-3 ACM Decompressor by fccHandler.

[hartford]

Version: build 2439

Crashes on "View file information"

[DoC hEx]

Great work guys, but I just noticed after upgrading my VitualDubMod with the one in the GKnot install (2439) my Xivd & Ogg Audio would slowly go out of sync over time. It takes about 90 minutes before its noticeable. Then by around 110 mintes its very easy to spot at least 1/2 second. I don't know if this is VirtulDubMod problem or a Besweet one as I updated all of them at once with the latest GKnot pack.