[MPlayer-dev-eng] mplayer libmpdemux
Nico Sabbi
nicola_sabbi at fastwebnet.it
Thu Jul 26 00:39:58 CEST 2007
MoRpHeUz wrote:
> Hi,
>
> While doing some application that makes use of mplayer's slave
> feature I reached a problem about seeks and get_time_pos .
>
> Problem scenario: I have this mpeg2ts file recorded from a dvb
> stream using mythtv and while playing it, if I try using
> "get_time_pos" I always get high values like 8779.4, even at the
> beginning of the file (this file starts at 8779.1). I noticed also
> that while playing, the last significant digit increases 1 per second.
> Working like this, I have a problem while seeking to absolute
> positions as the function "seek" just works with values in seconds.
seeking in plain mpegts (e.g. from dvb) is simply hopeless;
you can approximate something resembling semi-precise seeking
but it's doomed to fail more often than not, so better commit your
time to something more deterministic :-)
>
> Looking at mplayer's code I found the file
> "mplayer/libmpdemux/video.c" and at line 630 we have:
>
> sh_video->pts+=frame_time;
> if(picture_coding_type<=2 && sh_video->i_pts){
> sh_video->pts=sh_video->i_pts;
> sh_video->i_pts=pts;
> } else {
> if(pts){
> if(picture_coding_type<=2) sh_video->i_pts=pts;
> else {
> sh_video->pts=pts;
> }
> }
> }
>
>
> This file is reaching that last else and so it has
> picture_coding_type==3 (maybe this means that it's macroblock type b
> ?).
b-frame
>
> I'm trying to figure out a solution for this problem (even a patch
> if this is a bug)
> but I need some help to understand this scenario. Could you give me a
> little help on this ?
>
> Regards,
>
as above. Just think of the scary things that would happen on a
multi-day recording ..., but even without going that far the simple
fact that timers can reset at any time is enough to prevent precise
seeking without building a time-map on the whole file like the one
that avidemux saves as .idx
More information about the MPlayer-dev-eng
mailing list