[VDPAU] Support H264 Hi10 via vdpau

[Stephen Warren]

Christian König wrote at Tuesday, October 29, 2013 9:31 AM:
> Am 29.10.2013 15:58, schrieb Stephen Warren:
> > Christian König wrote at Tuesday, October 29, 2013 2:06 AM:
> >> Am 28.10.2013 18:47, schrieb Stephen Warren:
> >>> ... although actually looking at the new fields you're adding, won't
> >>> the values *always* be "10" if the new profile is in use? I think you
> >>> only need to do one of adding a new profile value, or adding new
> >>> fields to the picture info struct, not both? Re: [PATCH 1/2] hi10:
> >>> bump version in configure.ac
> >> Nope, IIRC the spec says that those two fields *can* be larger than 0 if
> >> you have Hi10P (e.g. represent 9 or 10 bits per luma/chroma component),
> >> but they don't *have to*!
> > I'm assuming that "but they don't have to" means:
> >
> > * If the stream is 8-bit, those fields can be 0, or 8.
> >
> > * If the stream is 9-/10-bit, those fields must be non-zero in order to
> >   indicate that.
> 
> Just the other way around. The H264 spec defines a field named
> "profile_idc" and only if this field has a certain value the two field
> bit_depth_luma_minus8 and bit_depth_chroma_minus8 are encoded in the SPS.
> 
> So if you have a Hi10P stream the bit_depth_(luma|chroma)_minus8 fields
> are encoded and *can* have values of 1 or 2 (indicating 9 or 10 bits of
> encoding) but they can also be zero (which indicates 8 bits encoding).
> 
> If you don't have a Hi10P stream then those two fields are inferred to
> be zero all the time.
> 
> >
> > Presumably these fields don't vary throughout the stream, so I would expect
> > the application algorithm to be:
> >
> > * If the stream is 8-bit, then use the existing VDP_DECODER_PROFILE_H264_*
> >
> > * If the stream is 9-/10-bit, then use the new VDP_DECODER_PROFILE_H264_HI10.
> >
> > So, perhaps it makes sense to add the new fields for the HI10 profile, but
> > not the existing profiles.
> 
> Nope again, the profile can actually change at any time (this is pretty
> normal for TV broadcasts).
> 
> So what the media player application needs to do is:
> 1. Decode the headers (SPS/PPS/slice header).
> 2. Determine what profile we have based on the var "profile_idc" from
> the SPS.
> 3. Create the proper decoder or fall back to software decoding if this
> profile isn't supported by the hardware.

OK, so this ends up working almost like I suggested, except that the app
keys off profile_idc rather than the bit_depth_* fields, the upshot being
that only the new profile needs the new fields/struct.

Hopefully the fact that the bit depth can change is just an internal
implementation detail of the decoder itself; the app would always need to
allocate/use 10-bpc surfaces in case the stream used that capability.

I suppose thinking back, as Aaron said, simply adding the new fields to
the existing struct could work out OK; drivers would need to only access
those fields in the Hi10 profile case, for backwards-compatibility. Old
drivers or apps, or even new drivers/apps using the existing profiles,
would never access the new fields.

-- 
nvpublic