[MPlayer-dev-eng] [PATCH] further dvr-ms playback improvements
John Donaghy
johnfdonaghy at gmail.com
Mon Sep 25 17:17:01 CEST 2006
> >
> committed with doubles. Thanks John
Cheers, and thanks to you and to Uoti for working with me on this.
Unfortunately, however, it appears that you commited an earlier
version of my patch than the latest one. It's probaly my fault because
I reasised after I sent it that there was a better way to do it and I
just sent the updated patch as an attachment in a reply. Maybe that's
not how it's supposed to be done.
The issue is that the 'average frame rate' cant be read reliably from
the file. So for example, the 'today.dvr-ms' sample I posted will
play far too quickly with the latest patch. I know for certain that
some files have a correct 'average frame time' and some dont (I
suspect all HD content doesnt and all SD content does but that's a
complete guess).
Anyway I discovered that the PTS values in the file can be used to
calculate an accurate 'average frame time'. The values in the file are
always slightly inaccurate but stay very close to the real value. So
after about 1-2 seconds of playback you can easily calculate an
accurate 'average frame time' for both HD ans SD content.The latest
patch does this without the need to read the extended stream
properties.
So what should I do now? Repost my patch against the current
Subversion sources? Or is it possible to undo the commit and apply my
new patch instead (once deemed acceptable).
I've attached the new patch and also pasted the text of the associated
email below.
John.
"I assuming now that it isnt possible to reliably get the average frame
time directly from the container because the value isnt always right
for HD content. However it is always possible to calculate it from the
pts values in the video stream. While these pts values arent accurate
for displaying an individual frame they are always pretty close and by
the time you've read a couple of seconds of video you can use them to
accurately determine the average frame time pretty accurately.
So in the attached version of the patch I keep recalculating the
average frame time until the end of playback unless the user performs
a seek.
I could possibly stop recalculating the average frame time after a few
seconds and it wouldnt make much difference to the adjusted pts
values. (I'm also assuming that the frame count wont overflow here.)
I'm not sure it is possible to recalculate the average frame time
after a seek because I dont know a way to get the frame number at that
point.
So, in this version there shouldn't be a problem as long as the user
doesnt attempt a seek in the first second or so of playback."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asfpts2.patch
Type: application/octet-stream
Size: 2386 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060925/7c44fc9b/attachment.obj>
More information about the MPlayer-dev-eng
mailing list