[MPlayer-dev-eng] PATCH: Fixes seeking based on percentage formpg's with timestamps not starting at 0

[elupus]

Nico Sabbi wrote:
> elupus wrote:
> 
>> Hi,
>> 
>> Not sure if you guys are interested, but i'll check anyways. This 
>> patch attempts to fix seeking based on percentage of total time in 
>> mpgs that has timesstamps that doesn't start from 0. (I can provide a 
>> sample should that be needed). A variant of this patch has been 
>> implemented in xbmc's variant of mplayer to allow current playtime to 
>> be reported correctly and seeking by percentage to work. As it is 
>> now, seeking by percentage in such a file just makes end of file to 
>> be reached directly.
>> 
>> It attempts to fix this by remembering what the pts value (timestamp) 
>> found when buffer is filled for the first time. This is based on that 
>> value of
>> mpg->last_pts, i suppose this really should be offset with the
>> current buffer size as even proper mpg's report a nonzero value 
>> here(allthough small).
>> 
>> This value can then also be used by the OSD to offset sh_video->pts 
>> to display current playtime, but i didn't include that part in the 
>> patch as that isn't done very cleanly in the current version used in 
>> xbmc mplayer.
>> 
>> Ts/ty files suffer from the same problem at times (atleast the time 
>> reported, haven't seen issued with seeking), so something similar 
>> should probably be implemented in those demuxer too.
>> 
>> Anyway, as mplayer normally doesn't seek by percentage and the 
>> current playtime is't really used for anything important, this patch 
>> isn't that important. But I thought it might be interesting 
>> nontheless.
>> 
>> Regards
>> elupus Team XBMC
>> 
>> 
> 
> Hi,
> 
>  >          if (mpg_d->final_pts > 0.0)
>  >-            newpos += rel_seek_secs * (demuxer->movi_end -
> demuxer->movi_start) / mpg_d->final_pts;
>  >+            newpos += rel_seek_secs * (demuxer->movi_end -
> demuxer->movi_start) / (mpg_d->final_pts - firstpts);
>  >           else if (oldpts > 0.0)
>  >-            newpos += rel_seek_secs * (oldpos -
> demuxer->movi_start) / oldpts;
>  >+            newpos += rel_seek_secs * (oldpos -
> demuxer->movi_start) / (oldpts - firstpts);
> 
> I don't understand what guarantees that (mpg_d->final_pts - firstpts)
> > 0 and (oldpts - firstpts). 
> 
>     Nico

At the moment nothing, it was kinda a quick fix that helped some vobs.

Am I correct in assuming that sh_video->pts is a ever increasing number (ie
no discontinuties), since this is used to keep audio and video in sync. I'm
not sure how sh_video->pts gets set in the case of mpg's couldn't find it at
quick glance. This is based on frametime no? Then perhaps this offset should
be implemented on that level instead of demuxer level.

Since oldpts can have discontinuties, but oldpos not. Calculating a average
bitrate using these seem rather dangerous. How about basing oldpts of
sh_video->pts (offset from starting value) instead then, this would limit
the possibility that oldpts - firstpts would result in a negative number. 

elupus

Ps. Sorry this will get double posted possibly. Sent from wrong email at
first. Ps.