[MPlayer-dev-eng] [PATCH] further dvr-ms playback improvements

[John Donaghy]

I know this is getting ridiculous but I've discovered that the last
patch I submitted doesn't always work very well because in some cases
the audio tends to drift out of sync. It worked for a lot of my files
but for some it didnt. So I'd like to save Nico the trouble of
reviewing it and withdraw it. Later I'll submit something else,
probably in smaller chunks to make it easier to review.

The attached graph illustrates why the approach I tried can fail if
you're interested. What it comes down to is that you cant calculate an
accurate enough average frame time without reading ahead significantly
in the stream. So the average frame time based on the first few frames
can be badly wrong which is enough to make the video drift out of sync
with the audio.  There are ways I could improve the situation to
minimize the likelihood of this but I haven't found a good enough way
yet to guarantee the video wont drift out over time.

The current version in SVN is fine for straight playback because it
reads the average frame time from the container. This value is
normally perfect in in all the recordings I have but it was wrong in
my one HD sample, which is why I tried instead to calculate it. (In
the file in question the average frame time was set to 0.0166833 in
what I think is a PAL format HD recording. That value is half the
frametime of what an NTSC frame should be so maybe the recording was
actually NTSC progressive scan but I dont know. And I dont know what
the average frame time should be for progressive scan - presumably it
is half??? I need more samples where I can be sure of the source).

Seeking will still not work correctly with the current version because
you really need the frame number after the seek to set the correct PTS
value based on the average frame time. I dont know if there's a way to
calculate it though. The alternative is to use the file based PTS as
the starting point after the seek and then start adding the average
frame time but if the first file PTS value is significantly wrong then
the audio and video might not be exactly in sync after a seek.

The last thing I want to say is that if you look at the graph you'll
see that there is a 'first segment PTS' and a 'last segment PTS' for
each frame. The mid point of these 2 values is often very close to the
PTS based on the average frame time. I wonder if this mid point value
is good enough? Should the PTS values supplied by the container always
be exactly evenly spaced anyone or is a little fluctuation acceptable?

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audio_out_of_sync_graph.png
Type: image/png
Size: 13944 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20061031/0971fbdf/attachment.png>