[VDPAU] [PATCH 2/3] vdpau: define some more H.264/AVC decoding profiles

[Rémi Denis-Courmont]

Le mardi 28 octobre 2014, 12:47:40 José Hiram Soltren a écrit :
> As an immediate fix this seems okay to me. These names are straight out of
> the H.264 spec and well defined.
> 
> I know Wikipedia is not necessarily authoritative but for now let's assume
> that it does a reasonable job of expressing the features in the H264
> spec(s):
> 
> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
> 
> A future direction that I would like to see for the VDPAU API is:
> 
> - continuing the specification defined names for profiles as names for
> VDP_DECODER_PROFILES, but including all of the profiles defined by the spec
> and/or
> - allowing video player applications to pass into VdpDecoderCreate,
> a (codec-specific, versioned) struct or other field with a number of flags
> for actual codec features in use.

That´s very much feasible for H.264. A good example is the RTP payload format, 
that carries the 24 relevant bits verbatim in the SDP: profile ID, constraints 
set and level, 8 bits each.

As it happens VDPAU already more or less maps the level values like the 
specification, that is to say as one decimal fixed point value. So all that´s 
left are the profile ID constant and the constraint bits.

I thought about just mapping the 65536 possible values as a static range of 
VdpDecoderProfile. But there are potential problems with that approach:

- HEVC has a lot more options than AVC, and a generic approach might require 
more bits than are available.
- The existing 3 AVC profiles need to be retained as special cases for backward 
compatibility in any case.
- If the VDPAU driver does not understand that a certain new profile is a 
subset of an existing old profile, decoder initialization will still fail, and 
either the application or the wrapper library will need to implement a 
fallback mechanism (like patch 3/3 in this series).

I don´t have any strong opinion for either solutions. The problem of backward 
compatibility affects both more or less the same way.

> So ideally, a video player could ask the VDPAU API, "I have a video stream
> with these particular features, can I decode it" and the API could return a
> Boolean answer. This would allow finer granularity than the current "does
> this VdpDevice support this VdpDecoderProfile?" implementation of
> VdpDecoderQueryCapabilities.

Considering existing implementations, the application will know:
- the profile and constraints set,
- the level,
- the pixel resolution,
- the chroma sampling and color depth, and
- any other SPS or PPS.
Those are the parameters carried in the stream before decoding starts.

Outside of "walled garden" use cases, the decoding application will not know 
what exact encoder was used. Hence it will not know which exact subset of the 
video codec syntax is used - only the well-defined profile.

-- 
Rémi Denis-Courmont
http://www.remlab.net/