rookandpawn
2nd October 2009, 07:25
Summary: my 720p 60FPS x264 video has video that slightly lags behind audio, unless you hit stop and play again and it will play perfectly.
I have a 60 FPS 720p video that is having slight sync issues, when you first play the video, the video is slightly behind the audio.
If you hit stop, then play again, the video is correctly in sync. I have tested this on multiple PC's and the phenomena is the same.
My encoding is simply the Megui profile for 2 pass HQ insane, but modified the Ref Frames to 5 and the b-frames to 4.
Here is what I have done to try to fix it, but no avail. I want the video to play correctly in sync on the first play , and not through some avisynth solution like assureVBRsync() etc..
1. I thought the problem could be audio related, so instead of muxing an MP3, i encoded my audio as AAC with nero. This didnt fix it.
2. I realized if the video is lagging slightly behind the audio, this could because the X264 Profile is too high for the CPU chip, and thus causing frames to lag, because the threshold for Frame Dropping is set to default, and I must be hitting just below the threshold, where the differences start to accumulate. But this wouldnt explain why the video goes into sync after one stops the player and hits play again. So i know its not an issue with the x264 decoding time/frames not dropping.
3. I resaved my original work huffyUV avi with avisynth .info()
and saved it and re-encoded this. I then turned on FFDShow's OSD and tried to notice if the FFDShow "FRAME COUNT" was slightly behind the timestamp from avisynth, and lo and behold, the first play seems to create a small but noticeable lag, between the framestamp in the video and the frame that FFDShow is claiming to represent. This lag is about 9-10 frames in a 60 Frames per second video, so roughly
166 milliseconds delay. This delay goes away on the replay, if the video player is not closed.
4. I also tried using MKV over MP4, but the exact behaviour persisted. This leads me to believe this is not a format issue, nor an x264 issue, but something about buffering. I dont know more than this.
5. This was tested on a multiple pcs including a bare bones refactored nlite with 6 services winxp sp2 + ffdshow and a typical dell, and another pc. So background cpu useage isnt really the issue, i think it has to do with how a video first loads.
Does anyone else know a way to solve this?
If someone is willing to look into it i will upload the small (~ 50MB mp4 video file)
I have a 60 FPS 720p video that is having slight sync issues, when you first play the video, the video is slightly behind the audio.
If you hit stop, then play again, the video is correctly in sync. I have tested this on multiple PC's and the phenomena is the same.
My encoding is simply the Megui profile for 2 pass HQ insane, but modified the Ref Frames to 5 and the b-frames to 4.
Here is what I have done to try to fix it, but no avail. I want the video to play correctly in sync on the first play , and not through some avisynth solution like assureVBRsync() etc..
1. I thought the problem could be audio related, so instead of muxing an MP3, i encoded my audio as AAC with nero. This didnt fix it.
2. I realized if the video is lagging slightly behind the audio, this could because the X264 Profile is too high for the CPU chip, and thus causing frames to lag, because the threshold for Frame Dropping is set to default, and I must be hitting just below the threshold, where the differences start to accumulate. But this wouldnt explain why the video goes into sync after one stops the player and hits play again. So i know its not an issue with the x264 decoding time/frames not dropping.
3. I resaved my original work huffyUV avi with avisynth .info()
and saved it and re-encoded this. I then turned on FFDShow's OSD and tried to notice if the FFDShow "FRAME COUNT" was slightly behind the timestamp from avisynth, and lo and behold, the first play seems to create a small but noticeable lag, between the framestamp in the video and the frame that FFDShow is claiming to represent. This lag is about 9-10 frames in a 60 Frames per second video, so roughly
166 milliseconds delay. This delay goes away on the replay, if the video player is not closed.
4. I also tried using MKV over MP4, but the exact behaviour persisted. This leads me to believe this is not a format issue, nor an x264 issue, but something about buffering. I dont know more than this.
5. This was tested on a multiple pcs including a bare bones refactored nlite with 6 services winxp sp2 + ffdshow and a typical dell, and another pc. So background cpu useage isnt really the issue, i think it has to do with how a video first loads.
Does anyone else know a way to solve this?
If someone is willing to look into it i will upload the small (~ 50MB mp4 video file)