FF Seek Problem On Live TV

[brad@…]

When watching live TV, and pausing it for a substantial period of time (2min+), unpausing, and trying to seek forward, the video will jump backwards (instead of forwards).

It is almost as if during the pause, the player gets confused about the total number of frames.

Also if you do two or three of these problem jumps, the timeline of the video will get messed up. So the player will think you have hit 30 minutes, when you are really only 20 minutes through the show.

I am using the hauppauge hd-pvr for recordings, and vdpau for playback on the latest trunk.

I have also attached a mythfrontend -v playback log in case it is useful.

[brad@…]

mythtv -v playback log

[anonymous]

I am experiencing the same issue with my HD-PVR recordings, and it also occurs while watching a recording that is currently being recorded. If you FF or REW the time gets confused and the desired result is not achieved (it skips to some totally different part of the video). Often pressing FF will actually skip to a much earlier part of the recording, and it is sometimes impossible to then FF to the correct place without closing the recording and opening it again.

[andres@…]

Same problem here using a dvb-s2 tuner on rev 21502.

[Mark McCans <mjmccans@…>]

I also have this same issue my HD-PVR, and it makes watching recordings while they are recording difficult. As described by Anonymous above, pressing FF (to skip a commercial for example) will often move to an earlier position in the recording and then there is often no way to get back to the correct position without exiting and restarting playback. Please let me know if I can supply any more useful information.

[wagabunda]

Replying to andres@yesbutno.nl:

Same problem here using a dvb-s2 tuner on rev 21502.

In my case (DVB-S/S2) affected only the channels encoded in h264, MPEG2 working properly.

[Janne Grunau]

(In [22279]) fix libavformat's seeking in avformatdecoder

the seek timestamp didn't took the start timestamp into account probably broken by a ffmpeg sync. Refs #4862 might fix Refs #6817, livetv shouldn't use libavformat's seeking but the behaviour described in the ticket matched what I saw with normal files without posmap

[brad@…]

Janne,

I did some quick testing on trunk [22280], and it appears you fixed the problem. Thank you! I will do some more elaborate testing over the next day or so to give a more definitive answer.

• brad

[Janne Grunau]

decreasing the priority to minor as seeking is working now. We still have to investigate why libavformat seeking is used. The only suspicion I have is the usually higher keyframe intervall of h264 recordings.

[mjmccans@…]

Thanks for looking into this issue but I am running rev 22294 and this issue is not fixed for me. When watching a recording that is in the process of recording, skipping ahead still actually skips backwards and messes up the time on the video, just as before. Perhaps the fix only worked for livetv. Unless I have missed something, I think that this issue still exists in trunk. It would be great if you had a chance to look into this issue further. Thanks again.

[gigem]

I saw the problem again myself this evening. This is a fairly serious issue for anyone who watches some shows, particularly sports, as they are being recorded, so I'm reopening this ticket.

[danielk]

gigem: if you force needToSave to true at the start of RecorderBase::SavePositionMap?(), does that resolve the issue for you?

[wagabunda]

Replying to mjmccans@gmail.com:

I am running rev 22294 and this issue is not fixed for me.

For me, too - rev. 22291.

[gigem]

Replying to danielk:

gigem: if you force needToSave to true at the start of RecorderBase::SavePositionMap?(), does that resolve the issue for you?

No, that doesn't fix the problem. I have found an easy way to produce it, though, by doing the following.

Start a recording, start playing it and catch up to real time.

Watch the program for a few minutes to get familiar with the content and then choose a good reference point such as the start or end of a commercial break.

Pause the playback and wait a couple of minutes.

Unpause the playback and press skip forward.

Instead of skipping forward, playback will actually pick up slightly before where it was paused.

[danielk]

(In [22308]) Refs #6817. Make sure position map is saved at least every 10 seconds. The code was keyed to the keyframe distance, and the throttling was based on the function being called for every keyframe, but it is now from another thread and not necessarily called once for every keyframe.

[wagabunda]

I checked rev. 22308 on a few HD channels and it was OK.

[danielk]

(In [22392]) Refs #6817. Improve error checking and reporting in RingBuffer::Seek()

[danielk]

(In [22396]) Fixes #6817. AvFormatDecoder? was inserting bogus entries into the seek map for h.264 material.

The change is to simply not insert seek entries from within the avformatdecoder for in progress recordings nor for non-mpeg-2 material.

[danielk]

(In [22399]) Refs #6817. Fixes a couple bugs noticed when looking at the FF Seek problem with in progress H.264 recordings.

1/ indexOffset was only initialized when the position map came from the DB, also do this when it comes from the backend via the Myth Protocol. 2/ When updating the position map using info from the backend, we inserted the entries blindly which can result in a non-monotonicly increasing list if two or more keyframes get updated via another means while we don't have the m_positionMap lock. This would of course make seeking unreliable.

[eric.bosch@…]

I'm guessing this is the offending patch, but I've just noticed, I can FF just fine, but can no longer skip back

[anonymous]

I also have the same issue with rev 22399 and an HD-PVR. Skipping forward on live tv seems to work correctly now but skipping back moves way too far back (sometimes all the way to the start of the recording, even if you are an hour into it). Thanks for all the hard work figuring this one out, and it would be great if there was a fix found.

[danielk]

(In [22423]) Fixes #6817. Fix REW Seek problem too..

The REW Seek was broken as well, but [22396] made it worse. This makes sure the seek map is updated on reverse seek too, if needed.

[Janne Grunau]

(In [22427]) fixes frame count for H264 streams in avformatdecoder. Fixes #6817

libavformat delivers fields seperately for interlaced H264 streams. For a proper frame count we have to use the h264 parser in H264PreProcessPkt() to decide if the packet contains a frame. This fix is analogous to fixes we did in the h264 capable recorders

[Janne Grunau]

(In [22445]) Adds a test for H264 bitstream format. Refs #6817

Our H264 parser only handles the Annex-B bitstream format found in mainly in MPEG-TS containers. [22427] broke playback of H264 formats using the NAL unit stream format like mkv and mp4. Keyframe detection is only for annex b reliable.