On Tue, 2009-03-24 at 01:13 +0100, Carl Eugen Hoyos wrote:

I'd like to post three links to HDTV recordings that all . Play fine with vlc . Play fine with ffplay . Transcode fine with ffmpeg and desync immediately with mplayer, no matter if -correct-pts or -fps 100 are used or not.

(Since there were misunderstandings in the past: This is not about "off by one frame", but "off by hundreds of frames every minute", so it also doesn't matter that all three samples are not very good when it comes to "how do I see if the sample is exactly synced?")

I think the basic problem with those samples is that the demuxer creates a separate packet for each field, but the decoder only produces one frame for every two packets that go in. So there are lots of "false" timestamps that do not correspond to any output, and that is not handled too well. Current git mplayer does not lose overall sync with -correct-pts (svn is probably worse), but the frame timing still isn't quite correct. The premiere-paff.ts sample shows overall sync loss when played with -demuxer lavf; that seems to be caused by the lavf demuxer returning AV_NOPTS_VALUE as the timestamp sometimes. I can think of two main ways to fix it in MPlayer (if the demuxer and decoder behaviors with mismatched packet/frame correspondence stay the same): either add a special case for raw MPEG container formats to attempt timing based on dts instead of pts, or add a mode to reorder pts values in the h264 decoder.