Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#6817 closed defect (fixed)

FF Seek Problem On Live TV

Reported by: brad@… Owned by: Janne Grunau
Priority: minor Milestone: 0.22
Component: MythTV - Video Playback Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (1)

MythPlayback.log (22.4 KB) - added by brad@… 15 years ago.
mythtv -v playback log

Download all attachments as: .zip

Change History (25)

Changed 15 years ago by brad@…

Attachment: MythPlayback.log added

mythtv -v playback log

comment:1 Changed 15 years ago by 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.

comment:2 Changed 15 years ago by andres@…

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

comment:3 Changed 15 years ago by 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.

comment:4 in reply to:  2 Changed 14 years ago by 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.

comment:5 Changed 14 years ago by gigem

Component: MythTV - GeneralMythTV - Video Playback
Milestone: unknown0.22
Owner: changed from Isaac Richards to Janne Grunau
Priority: minorcritical
Version: unknownhead

comment:6 Changed 14 years ago by 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

comment:7 Changed 14 years ago by 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

comment:8 Changed 14 years ago by Janne Grunau

Priority: criticalminor

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.

comment:9 Changed 14 years ago by 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.

comment:10 Changed 14 years ago by gigem

Status: newassigned

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.

comment:11 Changed 14 years ago by danielk

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

comment:12 in reply to:  9 Changed 14 years ago by wagabunda

Replying to mjmccans@gmail.com:

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

For me, too - rev. 22291.

comment:13 in reply to:  11 Changed 14 years ago by 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.

comment:14 Changed 14 years ago by 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.

comment:15 in reply to:  14 Changed 14 years ago by wagabunda

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

comment:16 Changed 14 years ago by danielk

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

comment:17 Changed 14 years ago by danielk

Resolution: fixed
Status: assignedclosed

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

comment:18 Changed 14 years ago by 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.

comment:19 Changed 14 years ago by 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

comment:20 Changed 14 years ago by 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.

comment:21 Changed 14 years ago by danielk

Resolution: fixed
Status: closednew

comment:22 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

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

comment:23 Changed 14 years ago by 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

comment:24 Changed 14 years ago by 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.

Note: See TracTickets for help on using tickets.