I converted an MPEG-2 video to an h.264 video using VirtualDub, exporting to an AVI container. 59.94 fps (using bob doubler, etc) 720x540.
In "File Information", I see "Decompressor ffdshow Video Pack (H264) for this video in Virtual Dub.
I have a related audio track as an uncompressed WAV file.
When I mux it together with this "AVI" using mkvmerge, I get an MKV file which I then try to playback in various players: VLC, Windows Media Player, MPC-HC, etc.
All of them play it back out of sync. Audio comes in 110ms later than it should, but in virtualdub it's absolutely correct - both when I play it back and when
I check it on the frame by frame basis, looking at the time stamp of some obvious sound related event with that sound in my WAV file.
Does anyone know what's going on here?
I can always "correct it" so it plays back correctly in VLC, but then I don't have it line up if I work with it in VirtualDub.
Who is right here, is my question?
When I load this AVI into VirtualDub, what puzzles me is that the first 10 frames look "black", before the video shows up, so I am kind of confused where the "first frame" is.(if I load MKV into VDub, first 10 frames are "green", otherwise no difference
+ Reply to Thread
Results 1 to 8 of 8
Maybe it's some problem with b-frames and/or frame reordering. AVI isn't really recommended for H.264. I don't know what encoder you use but if it's x264vfw you can try the following things:
1.) disable b-frame encoding of x264vfw (compression will take a hit, though.)
2.) toggle "VirtualDub Hack" in x264vfw
3.) use x264vfw's "file" output. It will write to a separate file and VirtualDub will only receive dummy data.
4.) use VirtualDub's "External Encoders" feature. It can properly pipe to x264 and other video/audio encoders and also automatically mux using e.g. mkvmerge. This will bypass all AVI/VfW problems. See VirtualDub's help or this videohelp thread.
I recommend #4.
I suppose the conflict in my title betrays my inability to understand whether its VD that's wrong, or "all the other players" I am using.
How do I go about figuring that out?
The first ten frames looking black roughly lines up with the audio being 110ms out. If that's the cause it should be 167ms, but it sounds like that could be the problem.
If, for some unknown reason, the AVI began with 10 null frames (which shouldn't be there) and they were retained when remuxing, that'd put the audio sync out, and if for some reason VirtualDub ignores them when opening the MKV, it might explain why the audio sync is fine.
You could use MKVCleaver to extract the video timecodes from the MKV to see if the first frame is at zero.
How are you opening the MKV with VirtualDub? In my experience the FFMPEG Input Driver is the most reliable, but it can't be used for Direct Stream Copy whereas the old Matroska plugin can. Maybe use the FFMPEG Input Driver to compare the total frame count of the encode with the source (I assume it should be double). Or check to see if using a different plugin changes the total frame count when opening the AVI or MKV with VirtualDub.
I'd recommend trying the external encoder feature with the command line version of x264. It's likely to be less problematic for h264 encoding. It's under VirtualDub's Options menu and a bit fiddly to set up. You need to set up an encoder, then create an encoder preset to use it, and the video is encoded via the File/Export menu.
For creating an encoder setup, this works for me.
Command line (anything prior to --demuxer raw is optional).
--level 4.1 --preset slow --tune film --crf 18.0 ---vbv-bufsize 78125 --vbv-maxrate 62500 --demuxer raw --input-csp i420 --input-res %(width)x%(height) --fps %(fpsnum)/%(fpsden) -o "%(tempvideofile)" -
Save that as an encoder setup, then use it to create an encoder preset. You can add audio and muxing to a preset but you don't have to. That'll write the output file as MKV.
AVISynth to prepare and read in the video files for my future needs, and then have this problem of choosing a good compressor to recompress them without losing too much quality while keeping the file size manageable. I have been using XVid at maximum quality, but then decided to try x264vfw. I am seeing, based on the responses, that I should try to not use AVI container for x264, but go directly to MKV from VirtualDub using this External Encoder option instead of the "Save as AVI" with a Compression chosen under the Video menu.
So, to answer your points.
This is what I get from MKVCleaver
# timecode format v2
What does this mean?
I am opening my MKV files by simply double clicking on them. I had set them up to automatically open in VirtualDub some time ago. I think I had to download some splitters or whatever. And I do remember something about having to install "Matroska plugin".
How do I find out the specifics of how I am opening something in VirtualDub?
Is there a tool that shows the way the different installed plugin files on my system are used during open?
This is what I can notice:
It flashes a pop up window with a "frame parsing" progress bar which is titled Parsing Matroska file.
The "File Information" menu option brings up a window titled "Matroska Plugin v3.1" - File Information.
I have also observed that VD reports a Key frame every 250 frames, with the first frame (0) being a Key frame.
Sadly, I have lost the source MPEG2, although your debugging suggestion regarding comparing frame count is a good one. When I extract MPEG-2 files they are usually from a ripped DVD, and maybe if during that stage I don't begin at a keyframe, there might be a problem. (I use MPEG Streamclip to do the extraction of MPEG2s, usually, or maybe dgindex plugin for AVISynth, one or the other).
Is there no way to determine based on just what I have, what the issue is with this file - in other words, "who is right": VD or the other players?
MPC-HC will scan it so you can seek. It doesn't matter though because when you remux it an index is created and you'd generally remux to add audio. You can open the MKV while the video is still being encoded. That's less likely to be the case for raw video streams.
If you're opening the video via an Avisynth script you mightn't need VirtualDub. Unless you're using it's filters. You could send the script to the encoder via the command line instead, or maybe use a GUI that'll do it for you. MeGUI, for example.
# timecode format v2
It seems they're rounded to milliseconds, but it also seems I was confused. If the audio is starting late due to a delay it'd be a delay to the audio stream, not the video stream. You can also check that with MediaInfo. If you open an MKV and use the View/Text or View/HTML menu you'll see more detail than the default view. If the audio and video streams don't begin together, it's shown as some sort of audio delay. If it's a negative audio delay it means there's a positive video delay (MKV doesn't allow negative audio delays but that's how MediaInfo displays a positive video delay). If there's no delay shown in the audio section, there shouldn't be one (MediaInfo displays audio delays pretty reliably for MKV, although not always for other file types).
I had the video delay idea in my head because of the green/black problem with the first few frames, however extra frames or a video delay would mean the audio would be early, not late. Sorry about that.
ffmpeg plugin's entry is "FFMpeg Supported Files". There's also a small checkbox labelled "ask for extended options". If you check it, a window pops up before the file opens so you can configure any options for that particular plugin.
The ffmpeg input driver plugin seems to open Avisynth scripts by default when it's installed. If you want VirtualDub to open them directly as it normally would, select "AVI File Input Driver" in the file type list.
Chances are you've noticed navigating backwards and forwards isn't always reliable in VirtualDub, especially for h264 video. You can go back to an earlier keyframe a second time to find a different frame is displaying in the preview. That sort of thing. It shouldn't happen if you open video with the ffmpeg input driver and there shouldn't be green frames at the beginning.
MKVMergeGUI. It'll delete an appropriate amount from the beginning if the audio delay is negative, so the resulting MKV mightn't have any audio delay, or it might have a small positive audio delay, depending on how accurately the audio can be cut.
If you work it out, please post back. I'm curious.