Opened 14 years ago

Closed 13 years ago

#692 closed defect (fixed)

Odd seek behavior in DVB/HDTV recordings

Reported by: fracmak@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Been using the latest SVN for a while now and I've recently noticed something weird about HDTV recordings. When I ask it to record an hour long show, it records it just fine, but the OSD will report that the show is actually 56 minutes and 11 seconds long instead of a full hour. Also, if I watch the show for about 5 or 10 minutes, then try and seek back, it ends up seeking a little forward instead of backwards, but the 2nd time I try and seek back it works just fine. This also affects when I cut out commercials, it seems like mythtv is confused as to where my position in the file is at any point and time so when I place a cut or seek, it doesn't always seek to the right place. Regular TV recordings work just fine, this only happens with the DVB/HDTV capture card I'm using. I've tried this on both a pcHD3000 and an Air2PC tuner cards with the same results.

Attachments (1)

Changeset7902-revert.diff (25.2 KB) - added by Stuart Auchterlonie 14 years ago.
Reverts Changeset 7902, applies over 8035

Download all attachments as: .zip

Change History (17)

comment:1 Changed 14 years ago by adeffs@…

I've also noticed that the commercial detect is way off, not coming close to a scene change or black frames, it jumps to the middle of a scene or commercial, I don't know if it is due to this same issue with positioning though and the actual detection is working fine?

comment:2 Changed 14 years ago by fracmak@…

From what I coudl tell, the actual commercial flagging was working fine, but seeking was way off. Like it would detect a 3 minute commercial, but put me 30+ seconds past the commercial when I seeked.

comment:3 Changed 14 years ago by anonymous

that sounds like what I found, I didn't have time to play with it as the g/f was trying to watch tv...

comment:4 Changed 14 years ago by anonymous

I observed problems with over-that-air commercial insertion by some local stations during HDTV broadcasts while using a different application. The carrier is always HD format, but the commercials are obviously NTSC inserted into the signal. They are low quality and have black vertial bars at the edges. The picture often jumps from low res to HD when the local commericals end and the network HD feed starts. Sometimes there is a bit of the show in low res until the station cuts over to the network feed. This cut is not well synchronized. It always glitches the picture and sound. Sometimes it crashes the Windows application. I wonder if this sloppy switching may be fouling up the time codes in the transport stream. Not all the local stations have this problem.

comment:5 Changed 14 years ago by fracmak@…

That might be causing problems, but this is a recent occurance, I'm wondering if it had anything to do with changeset #7902 which made a change related to keyframes in TS packets. When I get a chance, I'll revert back to prior to that change and see if the problem still exists.

comment:6 Changed 14 years ago by Stuart Auchterlonie

As suspected [7902] is the cause of the problem.

I reverted this changeset and now my seeking fwd & back works as expected.

I'll attach a patch which reverts [7902] that can be applied on top of rev 8035.

Changed 14 years ago by Stuart Auchterlonie

Attachment: Changeset7902-revert.diff added

Reverts Changeset 7902, applies over 8035

comment:7 Changed 14 years ago by Stuart Auchterlonie

May have jumped the gun a little bit.

After starting watching a recording, seeking works as expected.

After I have been watching the recording for a while seeking backwards seeks to a point best described as a formula.

loc = x + f*t

where

x = the position it should seek to.

t = length of time since you last attempted a seek.

f = scale factor

ie. the longer you have been watching a recording, the larger the error in the seeking.

comment:8 Changed 14 years ago by danielk

Stuart, if you increase search window in FindKeyframes? it should fix any keyframe problem with 7202. Where it says, "return (idx >= 10*TSPacket::SIZE);" in DTVRecorder::FindKeyframes?() increase the "10". But I doubt this is the problem, my guess would be some change in avformatdecoder is letting it calculate the actual instantanious keyframe distance for DTV Recordings.

comment:9 Changed 14 years ago by Stuart Auchterlonie

Daniel,

Put back 7202 and increased the "10" as you suggested. Picked random number "100" to use instead. This shows the same behaviour as with 7202 removed.

So I agree with you 7202 doesn't look like the problem.

comment:10 Changed 14 years ago by fracmak@…

I've noticed that if I go back a month or so and watch HDTV recordings, everything is fine, seeking and so forth. It seems like new recordings are the only ones that have this problem. Hopefully that helps in tracking this down.

comment:11 Changed 14 years ago by danielk

Owner: changed from Isaac Richards to danielk

fracmak, this might help if you state it a little less ambiguously.

Does a recording made with a month old MythTV playback fine in the latest SVN? Or does a recording made with the latest SVN playback fine in a month old MythTV?

If it is the first, this is probably a keyframe map creation problem in DTVRecorder, if the latter it is probably a keyframe map use problem in the NVP or avformatdecoder.

comment:12 Changed 14 years ago by Stuart Auchterlonie

Looks like the calculation of the total length of a program is incorrect.

A movie I've just been watching is listed as 1hr33m via mythweb. The OSD shows a total length of 1h23m and has been sitting at 1h23m of 1h23m for the last few minutes. It was recorded on 6th Nov.

comment:13 Changed 14 years ago by gdragon

fyi, I have noticed the same thing as francmak (I assume).

Daniel, in my case I'm running current-ish svn, and playing month-old recordings works great, while current recording exhibit the behavior.

So it looks like it's the former case.

comment:14 Changed 14 years ago by danielk

glen, can you try making a recording with the current SVN? [7902] seems like the most likely cause. It was reverted in [8042] to address #689.

comment:15 Changed 14 years ago by danielk

Status: newassigned

It doesn't appear that [7902] was the cause, but something on the recording side is causing this.

It looks like recordings with [7300] are ok. But recordings made with [8042] are not.

I'll try isolate the revision where things break and report back on what I find.

comment:16 Changed 13 years ago by danielk

Resolution: fixed
Status: assignedclosed

(In [8080]) Fixes #692.

FindKeyFrames?() stopped looking for frames once it had seen a keyframe stream id. But FindKeyFrames?() doesn't just find key frames, it also tracks the total number of frames seen. So this meant that streams that contain GOP headers would be undercounted by one frame per keyframe interval.

This doesn't effect all streams, so I put a little note of warning into the comments for anyone wishing to optimize this function in the future.

Note: See TracTickets for help on using tickets.