[mythtv] Latest svn BBC HD playback/recording failing

[John P Poet]

On Fri, Nov 14, 2008 at 9:03 AM, Janne Grunau <janne-mythtv at grunau.be> wrote:
> On Friday 14 November 2008 15:22:32 Rafael Moslin wrote:
>> > Can you try disabling the 'wait for seq start' option in the DVB
>> > card in
>>
>> mythtv-setup?
>>
>> Just gave that a go, made no difference, and in the interest of
>> bipartisanship I've also tried the only two other HD channels I have
>> access to, ITV and something called LuxeTV and they respond in the
>> same way
>
> should be fixed by [19094].
>
> John,
>
> waiting for an IDR slice breakes BBC HD recordings. As far as I can see
> they don't have no explicit IDR slices. at least that's that ffmpeg -
> debug 1 reports for all frame_num = 0 slices. Should we se se seen_IDR
> true if we see a keyframe/slice with frame_num == 0?

Excerpts from the H.264 documentation:

----------------------------------------------------------------------------------------------
* The first picture of each coded video sequence is an IDR picture.

* picture order count: A variable having a value that is
non-decreasing with increasing picture position in
  output order relative to the previous IDR picture in decoding order
or relative to the previous picture
  containing the memory management control operation that marks all
reference pictures as "unused for
  reference".

* ... an IDR access unit begins a new coded video sequence

* The first access unit of each coded video sequence is an IDR access unit.

* When present, an access unit following an access unit that contains
an end of sequence NAL unit shall be an IDR access unit.

* The end of sequence RBSP specifies that the next subsequent access
unit in the bitstream in decoding order (if any) shall
   be an IDR access unit.

* idr_pic_id identifies an IDR picture. The values of idr_pic_id in
all the slices of an IDR picture shall remain unchanged.
  When two consecutive access units in decoding order are both IDR
access units, the value of idr_pic_id in the slices of
  the first such IDR access unit shall differ from the idr_pic_id in
the second such IDR access unit. The value of
  idr_pic_id shall be in the range of 0 to 65535, inclusive.
----------------------------------------------------------------------------------------------

idr_pic_id is *only* decoded, if nal_unit_type==5, and for the BBC,
nal_unit_type is never equal to 5.

Best I can come up with from all of that, is that the *next* AU after
a "end of sequence" is seen, is a IDR.  I have a feeling, though, that
if BBC is not generating IDR NALs (NAL_type==5), then they are
probably also not generating end-of-sequence NALs (NAL_type==10), or
access-unit-delimiter NALs (NAL_type==9).  If the BBC *is* generating
NAL_type==9 or NAL_type==10, then we should be able to key off them.

It is well defined that if the NAL is a IDR, then frame_num=0.
However, I cannot find anywhere where it says that frame_num==0
implies that the NAL is a IDR.  That being said, I bet we could assume
that, and that is a lot easier to handle than looking for NAL_type==9
or NAL_type==10.

I am sure that

    if (NAL_type == SLICE_IDR)
    {
        frame_num = 0;
        seen_IDR = true;
    }
    else if (frame_num == 0)
        seen_IDR = true;

would not break things for the HD-PVR, but we would need someone in
the UK to try it for BBC stuff.

I could also come up with a patch which sets seen_IDR after NAL_type 9
or 10 is seen.

Comments?   Mark Kendall no longer lives in the UK, but he might have
some insight, since he got it all working for the BBC in the first
place:

http://svn.mythtv.org/trac/ticket/1926


John
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?