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

[Paul Gardiner]

On 03/01/2011 15:52, Taylor Ralph wrote:
> On Sun, Jan 2, 2011 at 9:36 AM, Paul Gardiner<lists at glidos.net>  wrote:
>> On 01/01/2011 18:35, MythTV wrote:
>>>
>>> #9410: Positioning problems with BBC HD and BBC ONE HD recordings
>>> -------------------------------------+-----------------------------
>>>   Reporter:  mythtv@…                 |          Owner:  janne
>>>       Type:  Bug Report               |         Status:  assigned
>>>   Priority:  minor                    |      Milestone:  unknown
>>> Component:  MythTV - Video Playback  |        Version:  Unspecified
>>>   Severity:  medium                   |     Resolution:
>>>   Keywords:                           |  Ticket locked:  0
>>> -------------------------------------+-----------------------------
>>>
>>> Comment (by jpoet):
>>>
>>>   When trying to detect a "new" access unit (AU), one of the things to look
>>>   for is a change in the nal_ref_idc value.
>>>
>>>   nal_ref_idc is part of '''every''' NAL UNIT, and we are currently testing
>>>   to see if it changed for '''every''' NAL UNIT.  Re-reading
>>>   T-REC-H.264-200711-I!!PDF-E.pdf, I don't think that is correct.  When
>>>   looking for a "new" AU, the nal_ref_idc should only be tested when the
>>>   current NAL UNIT is a "slice".
>>>
>>>   I have attached a patch which makes this change.  I have tested it with
>>>   HD-PVR recordings, and it does not seem to cause anything bad to happen.
>>>
>>>   It would be nice if someone else would read the spec to see if they
>>>   interpret it the same way.
>>
>> I've partially tried the patch, in that I've rebuilt mythtv on my
>> backend with the patch included, and then regenerated positions maps
>> for some of my recordings using mythcommflag --rebuild. I haven't
>> rebuilt myth on my frontend yet because I use minimyth, and building
>> it from scratch can take 10 hours, plus I'll need to remind myself
>> how to add patches to minimyth. The patch doesn't seem to have fixed
>> the problem completely, but then again I don't know if you would expect
>> it to have, or whether it need to be applied to both frontend and
>> backend.
>>
>> I'm just rebuilding position maps for all my old BBC HD rercordings
>> to see if the problem looks fixed for any of them.
>>
>> Cheers,
>>         Paul.
>
> The patch you are trying will not fix the issue. It's a problem John
> Poet found with the h264 parser when debugging the problem.

Thanks for info. I thought that was probably the case, but not being
completely sure, I decided to try it and post my results on the off
chance they could be useful.

> He has
> since discovered what is most likely the root cause of the bad pos
> map. It appears that BBC is sending FU-A and FU-B type RTP packets
> that our parser currently ignores. Parsing for these type of packets
> will most likely need to be added to properly support these new
> broadcasts streams.

That's great news... well, assuming FU-A and FU-B packets aren't
horrendously complicated.

Cheers,
	Paul.