[mythtv-users] Odd response to forward

[Michael T. Dean]

On 04/01/2014 06:39 PM, Jean-Yves Avenard wrote:
> On 25 March 2014 02:44, Michael T. Dean wrote:
>
>> You've just discovered why MythTV has seek tables.  In video, when you seek,
>> you have to either play all the video from now until the desired time or
>> "guess".  Since playing all the video between now and--even a small--30sec
>> seek could take a long time (up to 30s on some barely-capable systems), we
>> don't generally do this.  To guess, you generally take the bitrate (bits per
>> second) and compute how many bits from a given point you'll need to skip to
>> hit a given number of seconds.  In a video with variable bitrate (read,
>> nearly all videos today), this approach can yield unexpected results--even
>> to the point of skipping backwards for a forwards seek.
> I never thought this day would come where I would have to correct you :)
>
> seek tables really aren't necessary for seeking, and unless the video
> is corrupted with very wrong pts, what you describe will just *never*
> (or as you write /never/) happen. Because that's just not what ffmpeg
> does for seeking.
>
> When you want to seek in a video, yes, the bitrate will first be used
> to estimate *approximately* where in the file we should look. But that
> doesn't stop there.
> ffmpeg then looks for the pts and determine if it's the right place,
> if not it starts a binary search until it finds the right spot.
> while it can take a while, with local files it should be pretty fast,
> as as most you read log(n) of the file size

I'll be the first to admit you know the player code (and ffmpeg/libav 
code), and I don't.

However, regardless of whether it's required because of broken encoding 
or because of "code doesn't want to spend too much time seeking around 
randomly to get to the exact spot, so we shortcut the process", it seems 
that >90% (possibly 100%) of my MPEG-2 recordings need it for proper 
seeking.  Whether using MythTV to play a recording without a seek table 
or using a different ffmpeg/libav-based player (xine/mplayer/vlc) that 
doesn't have seek tables, I don't get proper seeks (often skipping in 
the range of -15 to +15s for my 7s seek forward, and rather wrong 
(though seldom going backwards) for 15s seeks, and getting closer (but 
still not exact) for my 30s or 60s seeks.  Since all of my OTA ATSC is 
MPEG-2, that's enough that I very much appreciate the seek table.

> seek tables as used by mythtv serves one purpose only: display
> accurate duration; because yes otherwise it wouldn't be accurate with
> variable bitrate streams.
>
> To be honest, I think our use of the seek table is greatly overused. I
> can't think of another media player doing things that way.
> ffplay, mlpayer and xbmc certainly can manage to seek properly
> everytime. None are using seek tables.

And I notice that (or at least notice how badly they seek in MPEG-2) 
every time I'm away from MythTV watching my recordings on the road.  :)

> I guess they aren't that concerned about having the duration displayed
> to be accurate...
> Myth makes constant access to the database during recording and
> playback just for that... It was using a jackhammer to solve an
> accuracy issue.

I'll admit that none of my MPEG-4 (ASP or better) has ever needed them.  
I thought it was just because the MPEG-2 stream in MPEG Systems 
container (I've seen it in both PS and TS) had problems that we solved 
with seek tables.

Mike