<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 1, 2014 at 3:39 PM, Jean-Yves Avenard <span dir="ltr"><<a href="mailto:jyavenard@gmail.com" target="_blank">jyavenard@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>seek tables really aren't necessary for seeking, and unless the video<br></div>
is corrupted with very wrong pts, what you describe will just *never*<br>
(or as you write /never/) happen. Because that's just not what ffmpeg<br>
does for seeking.<br></blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
seek tables as used by mythtv serves one purpose only: display<br>
accurate duration; because yes otherwise it wouldn't be accurate with<br>
variable bitrate streams.<br></blockquote><div><br></div><div>I would add "accurate seeking" based on my comment above.</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To be honest, I think our use of the seek table is greatly overused. I<br>
can't think of another media player doing things that way.<br>
ffplay, mlpayer and xbmc certainly can manage to seek properly<br>
everytime. None are using seek tables.<br>
<br>
I guess they aren't that concerned about having the duration displayed<br>
to be accurate...<br>
Myth makes constant access to the database during recording and<br>
playback just for that... It was using a jackhammer to solve an<br>
accuracy issue.<br><br></blockquote><div>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).</div>
</div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Jim</div></div>