Odd seek behavior in DVB/HDTV recordings

[fracmak@…]

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.

[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?

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

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

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

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

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

[Stuart Auchterlonie]

Reverts Changeset 7902, applies over 8035

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

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

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

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

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

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

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

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

[danielk]

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.

[danielk]

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