TheBashar
24th July 2005, 23:33
I am curious if anyone knows why I am experiencing a predictable video delay when using VFR in MKV. Let me explain in more detail.
I have a video which I process with DGIndex. It saves out the AC3 indicating a 0ms delay. I open an AVS in VDMod and play through to the first visually indentifiable sound point. I look at time timestamp. I now play the AC3 audio file and note the timestamp of the sound. They match, all is well.
Now, I transcode the AC3 to HE-AAC. I recheck the audio and the timestamp of the sound is still correct. Now I encode the movie to x264 from an AVS script which utilizes DeInt and DeDup. DeDup is configured to chop out a lot of duplicate and almost identical frames. It outputs a version 2 timecode file to use to adjust the frames playback.
Now, I reorder my timecode file based on tritical's AVCTcA to account for out-of-order frames (b-frames). I use this reordered timecode file in mkmerge with my MP4 x264 video file to make a correctly timed VFR MKV.
Here is where I start to notice the problem. Now if I play the MKV, the timestamp of the visually identifiable sound point is later than it was (and obviously later than the audio file).
The interesting point is that the amount the audio now needs to be delayed (alternatively the amount the video got behind) is always precisely the value of the first non-zero timecode in the non-reordered timecode file.
I'm almost certain this is not happening because of the timecode reordering. Which leaves only generation of the original timecode file or the mkvmerge process as causing this video delay. Does anyone have an informed idea as to why this video delay is happening?
Thanks!
I have a video which I process with DGIndex. It saves out the AC3 indicating a 0ms delay. I open an AVS in VDMod and play through to the first visually indentifiable sound point. I look at time timestamp. I now play the AC3 audio file and note the timestamp of the sound. They match, all is well.
Now, I transcode the AC3 to HE-AAC. I recheck the audio and the timestamp of the sound is still correct. Now I encode the movie to x264 from an AVS script which utilizes DeInt and DeDup. DeDup is configured to chop out a lot of duplicate and almost identical frames. It outputs a version 2 timecode file to use to adjust the frames playback.
Now, I reorder my timecode file based on tritical's AVCTcA to account for out-of-order frames (b-frames). I use this reordered timecode file in mkmerge with my MP4 x264 video file to make a correctly timed VFR MKV.
Here is where I start to notice the problem. Now if I play the MKV, the timestamp of the visually identifiable sound point is later than it was (and obviously later than the audio file).
The interesting point is that the amount the audio now needs to be delayed (alternatively the amount the video got behind) is always precisely the value of the first non-zero timecode in the non-reordered timecode file.
I'm almost certain this is not happening because of the timecode reordering. Which leaves only generation of the original timecode file or the mkvmerge process as causing this video delay. Does anyone have an informed idea as to why this video delay is happening?
Thanks!