[VDPAU] [PATCH] v3: Extend the public VDPAU API to support HEVC Decoding

[José Hiram Soltren]

Hi Rémi - my thoughts are below. I wonder what others on this list might think.

On 07/28/2014 02:28 PM, Reimar Döffinger wrote:
> On Mon, Jul 28, 2014 at 02:07:31PM -0500, José Hiram Soltren wrote:
>> This is version three of this patch, incorporating a suggestion from Rémi
>> Denis-Courmont to add VdpChromaType values for 10- and 12-bit formats.
> 
> Maybe I'm stating the obvious, and maybe it's not very relevant.
> But it would be nice if whatever mechanism is used for higher bit-depth
> formats would either directly work or at least be easily extensible to
> work with e.g. 10-bit H.264.

This is implementation dependent, but, the attributes of VdpChromaType are
independent of the choice of codec. I do not see any conflicts here. An
implementation would need to do some work to implement this extension but at
the API level I think this is sufficient.

Given that higher bit depth handling is codec agnostic, I propose that we
discuss this topic separately from the HEVC patches, to give it the attention
it deserves. (A response from Stephen Warren, received while I was composing
this, seems to agree.)

> I guess this might in particular involve considering if the numbers
> assigned to them are ok or if some space should be reserved for e.g.
> 9-bit, 14-bit and 16-bit from the start (which seem to be the only other
> bit depths I see used anywhere - though I did not look too hard).

Bit depth and subsampling are also independent attributes. Perhaps it would
make more sense to specify them separately? "VdpChromaType" is an unfortunate
name as it implies both.

Perhaps something like:

typedef uint32_t VdpChromaType;
#define VDP_CHROMA_TYPE_420   (VdpChromaType)0
#define VDP_CHROMA_TYPE_422   (VdpChromaType)1
#define VDP_CHROMA_TYPE_444   (VdpChromaType)2

typedef uint32_t VdpChromaDepth;
#define EIGHT_BIT      (VdpChromaDepth)8
#define NINE_BIT       (VdpChromaDepth)9
#define TEN_BIT        (VdpChromaDepth)10

...etc. For existing implementations EIGHT_BIT would be the default unless
otherwise specified. This seems less tedious than enumerating the entire set of
subsampling-depth tuples particularly if we add some additional attribute in
the future.

I would prefer for any changes to be non-breaking. Specifically, I do not want
to increment VDPAU_INTERFACE_VERSION.

I am not aware of any VDPAU implementations at the moment which support bit
depths greater than 8. I would like to know what could be helpful to API
implementers.

> I also wonder: is the API still powerful enough to _conveniently_
> figure out all the different capabilities?
> I mean, there are several bit-depths and chroma subsampling variants,
> of which a subset might be supported for displaying, and of that two
> completely different subsets might be supported for decoding and
> deinterlacing respectively.

At the moment, we have the Query functions:

VdpVideoSurfaceQueryCapabilities()
VdpOutputSurfaceQueryCapabilities()
VdpBitmapSurfaceQueryCapabilities()
VdpDecoderQueryCapabilities()
VdpVideoMixerQueryFeatureSupport()
VdpVideoMixerQueryParameterSupport()
VdpVideoMixerQueryAttributeSupport()
VdpVideoMixerQueryParameterValueRange()
VdpVideoMixerQueryAttributeValueRange()

vdpauinfo[1] is an example of how to use these to determine what a particular
decoder can do.

If we go with the proposal above to add a VdpChromaDepth, we would necessarily
need to alter VdpVideoSurfaceQueryCapabilities(), or add a new function, to be
bit depth aware.

> Can a player application still reasonably figure out what it should
> best use VDPAU for and in what way?

I hope the Query functions provide enough information for a player to make an
informed choice. I assume you mean that a player can choose to use VDPAU for
any or all (or none!) of decoding, post processing, and presentation. If not:
what additional information is helpful to a player?

> Or even which format it should
> request from e.g. a server if it has the choice?

Forgive me, I'm not sure I follow. Perhaps an example could illustrate your
point here?

Thanks,
--José

> Regards,
> Reimar
> 
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------