[MPlayer-users] -ss sometimes jumping dramatically in some mpg/mpeg2files

[Nico Sabbi]

Heitzso wrote:

> I've been digging through the mplayer code to see why some -ss seeks
> go bonkers in some of my video files, but not in most of them.
>
> The problem arises from my mpg(2) files not having a pts for mplayer
> to find in the last 500,000 bytes of the file.  This causes mplayer to 
> fallback
> to guess-timating where to seek into the file based on the video bit 
> rate.
> But mplex stuck the max bit rate into the video file header (assume, 
> based
> on other emails in transcode list) which is 9000, but that's twice the
> average bit rate and therefore mplayer easily falls off the cliff (so 
> to speak)
> when trying to seek into the latter part of the video file.
>
> I backed up that 500,000 to 1,000,000 and now that class of seek problem
> went away.  This is any easy fix in my case because I know my video 
> files are
> all larger than 1,000,000 bytes.  A more elegant fix would be to 
> insure that
> we haven't pushed into a negative number.  Anyway, the fix should be
> applied to demux_mpg.c, around line 110:
>
> int demux_mpg_open (demuxer_t * demuxer) {
>    stream_t *s = demuxer->stream;
>    off_t pos = stream_tell (s);
>    off_t end_seq_start = demuxer->movi_end - 1000000;    // 500000 is 
> a wild guess
>
> Note this is not patchable, I reformatted the C files to correct
> indenting.  But the above mod is certainly simple enough for
> someone to change by hand.
>
> Note the "500000 is a wild guess".  That was certainly a clue for me.
>
> ANYWAY,
>
> A better code sequence would be to calculate the end_seq_start then
> test to see if it is less than 0, and, if it is, to recalculate as ?? 
> 1% of total
> length, or some other? algorithm.  IF the powers that be would like
> me to mod that one line in an official not-re-formatted version of this
> file and submit a simple patch I will.  Let me know off this list and 
> I'll
> set it up and change the wild guess number at the same time.
>
> If anyone knows why backing up to 1,000,000 char before the end and
> then looking for the pts is problematic please let me know.
>
> Thanks,
> Heitzso
>

the proper patch would be: implement -idx scanning all pes headers and 
storing
a map of filepos => "sane" pts (or, even better, the other way around),
where as "sane" I mean a translated pts when/if the timer wraps around.
Anything else is just a waste of time
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Visita aziendeinaffari.it, troverai tutte le aziende industriali, artigianali e di servizi del Canavese, per ogni tua esigenza 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3607&d=4-7