Frame Accurate Software Player

[CarlEdman]

As recounted at great length in another thread on the forum (http://forum.doom9.org/showthread.php?p=1723491), all the popular software players I tried on Win 8.1 x64 machine seem to be substantially off in both their frame count and timing, in particular when displaying H264 embedded in MP4.

I first noticed this when some audio was desynced by more than 100ms in my H264/MP4s. This was audible in WMP, VLC, PotPlayer, MPC-BE and MP.NET. The latter three also allowed this to be confirmed by frame/exact time searches.

At first I thought that the problem might be with my files, but using a known frame-accurate process (DGIndexNV/DGSource/VirtualDub), I was able to confirm that the timing in the files was perfectly accurate.

So can anybody recommend a player which does not suffer this problem or suggest another solution?

[nevcairiel]

I can assure you that files which are muxed *properly* will work just fine in the majority of players, without any desync. 100ms is quite visible, and people would have noticed. ;)
In the MP4 case, do not use edit lists, they are not supported well by anything other than QuickTime.

Also note that players are not meant to be "frame accurate" in the strictest sense. I do not know how you counted frames, but its quite likely that whatever method you used to count frames inside your player was flawed.
That doesn't mean that it will desync, just that counting/timing your "identifiable frames" might be broken.

[huhn]

madVR is calculation the difference between video clock and audio clock and it dropping or repeating frame to counter this. but every play should have something like this.

have you checked if you didn't have a huge input lag on your screen. a TV like the ax900 easily reaches input lags like 250 ms

[CarlEdman]

@nevcairiel: One would think that these sort of audio desyncs would be complained about before, but nonetheless it does happen and, if you go to the original thread linked above, I explain in some detail exactly how I reached this conclusion.

To summarize the method I used to determine the frame inaccuracies: First, I took the files (equivalent MKV/MP4s), ran DGIndexNV, loaded them into VirtualDub using the DGSource() filter (which is frame accurate), and then noted the frame numbers and timing of certain identifiable frames (such as first frames in new scenes). The MKV and MP4 versions of the files showed exactly the same frame numbers and timing.

Then I loaded the files into the various players listed above. For all of them the MKV video was relatively closely in sync with the audio, the MP4 video was out of sync with the audio. Then, for the players that have a go-to-frame or equivalent option (PotPlayer, MPC-BE, and MP.NET), I identified the frames again (by time and frame number). The timings were off somewhat for MKV and by quite a lot for MP4. Moreover, for the MP4s the audible audio desync was consistent with the video desync confirmed by looking at frames.

@huhn: I used the software players on a PC. Conceivably video card/monitor issues could cause a desync from the audio separately delivered to the speakers, but that could not explain the discrepancies between equivalent MP4s and MKVs and the frame issues I separately checked.

[nevcairiel]

Then, for the players that have a go-to-frame or equivalent option (PotPlayer, MPC-BE, and MP.NET), I identified the frames again (by time and frame number). The timings were off somewhat for MKV and by quite a lot for MP4. Moreover, for the MP4s the audible audio desync was consistent with the video desync confirmed by looking at frames.

This is what I meant - seeking is NOT frame accurate, and your Go To Frame function will put you anywhere, but not at the frame you want.
In short, your test was flawed, and your conclusions are invalid.

[CarlEdman]

@nevcairiel: If I understand you correctly, the playback in these software players is accurate, but the go-to-frame or go-to-time functions are not.

I guess that is possible, but it would not explain why audio in the MP4s is desynced during regular playback. Also, it would be quite a coincidence that the audio desync seems to be exactly commensurate with the amount the go-to-frame/time functions are inaccurate.

Again, as explained in the linked thread, while the reasonable suspicion--indeed my first suspicion--is that if the MKV seems to play close to correctly and the converted MP4 does not, there is something wrong in the conversion process, that is not the case. The MKV and MP4 have the same frames with the same timing. This has been confirmed two ways: (1) by loading them both up in DGIndexNV/DGSource/VirtualDub and (2) by extracting the timings from the MKV (as t2c) and from the MP4 (as nhml) and finding that they match within a fractional ms rounding error.

[starla]

I guess that is possible, but it would not explain why audio in the MP4s is desynced during regular playback. Also, it would be quite a coincidence that the audio desync seems to be exactly commensurate with the amount the go-to-frame/time functions are inaccurate.

If A/V sync drifts during the playback (with more than one player) it is highly likely that the file itself has A/V sync issue (after all you cannot make sure even when the timestamps are continuous does the audio / video streams contain correct data).

Players usually use audio render as reference clock and then drop / repeat the video frames to keep A/V sync correct (quite much simplified but the basics are same with all players).

[CarlEdman]

If A/V sync drifts during the playback (with more than one player) it is highly likely that the file itself has A/V sync issue (after all you cannot make sure even when the timestamps are continuous does the audio / video streams contain correct data).

As I said before, that was my first suspicion too, as detailed at greater length in the thread linked at the top. But after all the tests I performed and described here, that seems highly unlikely.

In particular, the various tests independently confirm that the two files have the same frames at the same time stamps. For the audio, I've tried both conversion to AAC and straight AC3 copy.

The result is always the same: The MP4 muxed file has a substantially more severe audio desync problem than the MKV muxed file. BTW, the desync appears in all cases to be approximately constant ~100ms, not a drift as the file plays.