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

[Taylor Ralph]

On Thu, Dec 30, 2010 at 3:31 PM, Paul Gardiner <lists at glidos.net> wrote:
> On 30/12/2010 20:05, Taylor Ralph wrote:
>>>
>>> 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.
>
> Ah right. I realised just after posting that my description
> couldn't be quite right because you'd already said that regenerating
> the position map was necessary after making the change. So the
> code path we've been referring to is used during recording rather
> than playback, and also in commercial flagging? Both use instances of
> AvFormatDecoder? Is it used for anything else? Just interested.

Yes, avformatdecoder is used in many areas but for this problem the
recorder, commercial flagger and player are all that are involved.

>
>> 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.
>
> Yeah, it wasn't that I thought the workaround might be risky. I
> was just interested in understanding it, and also wondering if I
> could help out more by actually doing the proper fix, but I guess
> that requires fixing the low level H264 parser to recognise cases
> its not actually handling, and that in turn would require poring
> through the h264 spec.
>

Yes, knowledge of the h264 spec is required to work on the parser. Any
help is always appreciated.

FYI, thanks for the ticket and samples. A+.

Regards.
--
Taylor