[mythtv] [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length

Janne Grunau janne-mythtv at grunau.be
Wed Oct 3 18:20:58 UTC 2007


On Wednesday 03 October 2007 15:29:51 Daniel Kristjansson wrote:
> On Wed, 2007-10-03 at 08:17 -0500, Robert Kulagowski wrote:
> > Maybe I'm not following along, but why try to calculate the
> > recording length based on total frames / frame rate when we _know_
> > what time we started recording and what time we ended?  time(now) -
> > time(start) = length?
>
> The reported length is just a side effect. We skip around the
> recording based on the keyframe map, so unless we know the frame rate
> those keyframes are delivered at we can't say skip backwards by 30
> seconds when the user asks us to. But it might make sense to record a
> timestamp in the keyframe map and then we could always skip based on
> time no matter what the current framerate. The only problem with that
> is that it might be space inefficient. When the framerate changes it
> really only changes one or two dozen times during a recording so
> putting a timestamp in every keyframe entry, while the simplest
> option, would probably make the DB 30% larger in one fell swoop.

I want to replace chanid and starttime for the recordedseek table with a 
recordedid (Chris Pinkham's multiple files per recording work might 
atually include it).
That would save 6 bytes per entry. If we add a int as timestamp we still 
save 2 bytes.

It has one big problem though, updating the old seek tables.

> There are also other problems that this ticket covers, such as when
> we miscount frames simply because our frame scanning method for
> MPEG-2 video is quite crude.

I'm still not sure how we can solve this issue. Reusing ffmpeg is at 
least for the recorders not feasible.
I doubt that the simplistic parsing is to blame for the seeing twice the 
number of frames. Bogus start codes in video stream can only occur 
cross the PES packet header payload boundary.
The picture header is not nice to parse but I'll add it.

Janne


More information about the mythtv-dev mailing list