[MPlayer-dev-eng] Re: [PATCH] dvr-ms fixes for pts, key frame detection and seeking

John Donaghy johnfdonaghy at gmail.com
Thu Feb 8 19:19:48 CET 2007


> How does anything else play this? Do they really try to calculate
> average frametime? Are you sure there is no overall (constant) framerate
> indicator elsewhere in this case?


I'm not sure that there isnt one, but there is insufficient documentation on
this particular variant of asf and I havent been able to find a reliable
value. There is an average frame time in the asf container but in the case
of dvr-ms it often appears to be wrong - there are several instances of
things like this happening in dvr-ms files, timestamps being the primary
example. For some reason the dvr-ms timestamps are stored in the 'payload
extension system' - completely undocumented anywhere but eventually I
discovered them. I've no idea why this is the case

> The technique I've tested to get round the first issue also avoids the
> need
> > to use correct-pts for the second - which I think is a good thing.
>
> But it can only be correct if all videos stored in this container are
> constant framerate. Are they?


I dont know for sure, so what I'm doing at the minute is recalculating the
average everytime I find an I-frame - by subtracting the pts of the previous
I-frame and dividing by the number of frames in the GOP. I always use the
pts for I-frames directly, and for B and P frames I simply add to that the
newest average x the relative frame number.

The only problem I've had is in one sample where an I-frame appeared halfway
through a GOP and I believe this is due to the signal switching from SD to
HD. I'm still not sure how to handle that situation correctly. I posted an
.mpg version recently that illustrates the issue.

John

_______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>



More information about the MPlayer-dev-eng mailing list