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

Paul Gardiner lists at glidos.net
Thu Dec 30 19:13:14 UTC 2010

On 28/12/2010 21:32, Taylor Ralph wrote:
> On Tue, Dec 28, 2010 at 12:55 PM, Paul Gardiner<lists at glidos.net>  wrote:
>> On 28/12/2010 00:59, Gavin Hurlbut wrote:
>>>>   I've confirmed this is related to the h264 parser not detecting on_frame
>>>>   properly while playing back or running commercial detection.
>>>>   A temporary work around until this is fixed would be to return true
>>>> always
>>>>   for H264PreProcessPkt in avforatdecoder.cpp and rerunning commercial
>>>>   flagging.
>>> This sounds like it's likely to mess up just as much as it fixes.
>>> That area of the code has been rather problematic for us, and every
>>> seemingly quick fix here tends to come back and bite us later on.  I
>>> hope we get the real fix soon, whatever that may be. :)
>> I'd be interested to give it a try, but I'm not sure I understand
>> the suggested work around. H264PreProcessPkt looks to me like it
>> recognises GOPs and pulls out info about changes in frame rate
>> and size. Is the suggestion that this processing is unnecessary
>> in streams that don't change size, and hence that you can skip
>> it completely, or do you still have to walk some of the data?
>> Cheers,
>>         Paul.
> No, just replace 'return on_frame' with 'return true' at the end of
> the H264PreProcessPkt function.
> Also, the dev who is the expert on the parser is aware of the issue
> and will be looking at it when he gets a chance.

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

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?


More information about the mythtv-dev mailing list