What I am doing is resizing a 1024x768 video to 1440x1080. The results look good (in WMP, in VLC they look washed out but I am told it's a hardware thing even though I don't seem to have any other such issue using VLC to check brightness/color).
But, VirtualDub is creating this weird grid crap at the start of the video:
Otherwise it looks normal. I also read that the sound in VirtualDub might be off by 400ms. Now I'm looking at my video and wondering. The program says it's perfect, but I don't know. I'm not sure.
I also tried to recut it direct-stream but that didn't work, it just made fresh garbage on the shorter clip. Another program seemingly discarded 8 seconds of my video when I told it to remove the offending 13 frames; so much for that idea...
Would, perhaps, VirtualDub2 be any good?
Using VirtualDub 1.10.4. Codec, x264vfw.
+ Reply to Thread
Results 1 to 3 of 3
Well, x264vfw may be able to store it in an AVI container, but H.264 (AVC) video doesn't belong there. I wonder which of your installed VfW codecs attempts to decode that. Decoding with AviSynth plugins may help or not. Decoding with VirtualDub2 internal ffmpeg decoders may help or not. Both are at least worth a try. But for the future, avoid x264vfw and do it correctly instead. VirtualDub2 supports saving e.g. as AVC video with a current x264 codec into an MP4 or MKV container, both supporting the complex structure of AVC video much better than the nowadays quite obsolete AVI container.
In general, regardless of the container, you will not be able to cut AVC video at any arbitrary frame number without getting garbage, because with the exception of the GOP start frames, all other frames are stored as difference to a reference, and when you cut the reference off, you will end up with the difference to ... nothing.
And regarding the "audio decoder lag": It depends on the used audio codec, but it's a known topic, and modern editors and players know to compensate it.
Last edited by LigH.de; 3rd Apr 2019 at 02:49.