[mythtv] [mythtv-commits] Ticket #9410: Positioning problems with BBC HD and BBC ONE HD recordings

[Taylor Ralph]

>
> Not quite gotten to trying this out yet. Wanted to first try to
> understand what it happening. Is the following anything anywhere near
> how it works?
>
> While the frontend is playing a recording, the backend is parsing the
> stream.

Basically the frontend player uses the position map that is generated
during the recording or the commercial flagging process. This table
gets stored in the database by the backend recorder or commercial
flagger and the frontend uses it when playing back the recording to
know where the keyframes are relative to the file position.

> The bit we are looking at is after demuxing, and is specifically to do
> with handling video packets. Mainly the backend sends them on to the
> frontend, but also it parses the packet itself to read information to
> do with changes of frame size and frame rate. Also it counts frames
> so as to know how far through it is.

During playback the frontend reads all packets, including audio,
video, subtitles, etc, from the file via the ringbuffer protocol. The
player does all the demuxing, parsing, decoding, etc for playback. The
backend is only involved if it is streaming the file via the
ringbuffer.

>
> In the case of the mpeg codec, there is exactly one frame per video
> packet, so counting frames is just counting video packets. In the
> case of H264, there is never more than one frame per video packet,
> but you can get packets with no frame start, hence the need for
> H264PreProcessPkt to return the on_frame flag.
>
> H264PreProcessPkt reads through the packet to the end or until
> it finds a key frame, because it is at key frames where new frame
> sizes or rates may have been detected in the stream. While
> doing that it also is checking whether there is any frame at
> all (or maybe I mean the start of a frame).
>
> Presumably the problem is that the parser (addBytes) gets confused.
> That doesn't stop perfect playback because the whole packet is
> still sent to the frontend, but it can mean the backend misses
> the start of a frame and fails to keep its count up to date.
> (It would also miss changes in frame size if they occured).
>
> The temporary fix is to just treat h264 like mpeg and assume
> one frame per packet, which is generally correct.
>
> Is that anywhere near?

Yes, the hack is to just assume one complete frame per packet which is
not always correct but appears to be in the case of BBC and BBC1 HD.

As Gavin has noted this could cause problems for other recordings if
this assumption isn't true and would require you to remove the hack
and recreate you position maps by re-running the commercial flagger
again. But do this at your own risk. It however is unlikely to
spontaneously catch your system on fire or anything like that. Just
log another ticket if that happens since it's probably unrelated.

And remember, if you do try the hack, be sure to re-run commercial
flagger for all the recordings that have been incorrectly flagged.

Good luck and enjoy.

Regards.
--
Taylor