[VDPAU] VDPAU HEVC example parser

[Philip Langdale]

On Fri, 12 Jun 2015 19:55:11 -0700
Philip Langdale <philipl at overt.org> wrote:

> So, I built it and ran it, and I have two quick observations:
> 
> 1) The frames themselves seems ok, so there's hope for my code.
> 
> 2) The inability to display the frames correctly is exactly the same
> as my code. I see the top half of the frame stretched to the full
> height, and if I tell it to interpret it as a bottom field, it shows
> the bottom half (minus the lines at the bottom).
> 
> I don't know why José was seeing something different, but this is the
> exact problem I've been talking about. It's simply not possible to
> display a decoded frame correctly - even if you manually de-interleave
> the two halfs, part of the data is lost in the alignment area between
> the two 'fields' and cannot be recovered by an application.

Ok, I can now report on some of what I've been able to learn in terms
of correctly populating the picture info.

1) NumShortTermPictureSliceHeaderBits

This is documented as:

    /** Section 7.6.3.1 of the H.265/HEVC Specification defines the
    syntax of the slice_segment_header. This header contains
    information that some VDPAU implementations may choose to skip. The
    VDPAU API requires client applications to track the number of bits
    used in the slice header for structures associated with short term
    and long term reference pictures. First, VDPAU requires the number
    of bits used by the short_term_ref_pic_set array in the
    slice_segment_header. */

but it turns out that this value needs to track the entire if/else
block described in the spec, not just the case where
short_term_ref_pic_set_sps_flag is false, which is what it sounds like.
If that flag is true, there is no rps in the slice header - rather some
bits are used to indicate which sps rps is used, and those bits must be
counted here.

This is in sharp contrast to dxva which doesn't count those bits and
ignores this bit count if the flag is true.

The documentation needs to be explicit about this - it's not at all
obvious, even in retrospect.

2) IsLongTerm for reference frames

The example app doesn't set IsLongTerm at all, for any reference,
regardless of whether it's long term or not. Well great. If I set it,
which I did, of course, then I see glitches on frames with long term
references. When I comment that out of my code, the frames are rendered
correctly. Oh dear. Either the driver needs to keep working if the flag
is set or the flag needs to be removed from the API, or there are sure
to be differences between implementations.

I can see why this flag would be pointless as the information could be
derived from RefPicSetLtCurr. But either way, something needs to change.

3) Even after all that, I still see glitches in many samples - some of
which are the same in both my code and the example app, and some of
which are unique to one or the other (oh dear).

I'll call out one that's interesting.

http://fate-suite.ffmpeg.org/hevc-conformance/LTRPSPS_A_Qualcomm_1.bit

In this sample, the frame with POC 223 is glitched in the same way for
both applications. This frame has a long term reference to POC 192 and
what you can see, visually, is parts of POC 192 showing up, but clearly
not in the right way. There are quite a few other glitched frames in
this sample, and they may or may not be the same problem.

--phil