[mythtv-users] Odd response to forward

[Jim Stichnoth]

On Tue, Apr 1, 2014 at 3:39 PM, Jean-Yves Avenard <jyavenard at gmail.com>wrote:

> 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.
>

My view of this - the main reason for today's heavy-handed use of seek
tables is to deal with such incorrectly encoded broadcast videos.  One of
the common ways of breaking pts values is when the broadcaster simply
splices in commercial breaks without recomputing pts.  Another example that
might be done correctly by the broadcaster but maybe not handled correctly
by ffmpeg is framerate changes within the video, such as sending the main
video in 720p but commercial breaks in 1080i.  I don't receive any channels
where that happens, but others have this regularly (e.g. David Engel).


>
> 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.
>

I would add "accurate seeking" based on my comment above.

But deep down, the playback architecture of MythTV is frame-based whereas
ffmpeg is timecode-based, and seektables try to bridge this chasm.  One of
the bigger items on my list is to try to fix this.


>
> 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.
>
> 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.
>
> Constant access during playback?  That shouldn't be.  My recollection is
that the entire seektable is read into the player at startup of playback.
 For live TV or an in-progress recording, seektable updates are handled by
myth protocol requests which don't touch the DB on the player or recorder
side.  As for the recording side, I don't remember the specifics of the
behavior, but I don't see why the DB seektable should be updated more than
once per minute or so, though I'm sure it's actually more frequent today.
 Because of the protocol-based communication for in-progress recordings,
any DB updates before the recording ends are more of a failsafe against the
backend crashing before the recording ends (though there could perhaps be
issues with real-time commflagging if for some reason it doesn't use the
protocol method of getting seektable updates).

Going back to the OP's question.  I've seen problems with improperly
encoded videos where e.g. the video framerate is reported as 30fps but the
frame intervals in the video actually correspond to 24fps while the audio
is indeed at 30fps (not entirely sure I'm remembering the audio situation
correctly).  Discrepancies like this cause video frames to be occasionally
repeated or dropped during playback.  This consistent repetition or
dropping is not reflected in the seektable because the recorder and
mythcommflag --rebuild are both unaware of it.  This causes problems where
a seek will go to the wrong location; however, subsequent seeks are more or
less consistent until enough frame repetition/dropping pulls things out of
sync again.  That could be the case here.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140404/e5803f03/attachment.html>