[VDPAU] ffmpeg and HEVC: Reference handling

[Philip Langdale]

Hi José,

On 2015-06-02 13:33, José Hiram Soltren wrote:
>> As for specific glitches, one that really stands out to me is if I try
>> and decode RPS_C_ericsson_4.bit
> 
> I'm not able to find this one. We have a stream called 
> RPS_C_ericsson_5.bit
> internally:
> 
> $ sha1sum RPS_C_ericsson_5.bit
> a148b9ec005bfcf82310cc01a5cef4ab6c05d90f  RPS_C_ericsson_5.bit

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

> The RPS_* bit streams test reference picture sets. Recall from the
> Specification that the decoder must maintain a number of reference 
> picture sets
> and switch between them during decoding.
> 
> This is all more clear in the internal video playing application that I 
> am
> hoping to be able to release in the near future.
> 
>> , everything seems fine until I get to
>> frame 23, at which point it suddenly outputs a frame that is
>> bit-identical to frame 21 and then everything goes south from there. I
>> don't know what to make of that.
> 
> Does the value of short_term_ref_pic_set_idx happen to change around 
> frame 21,
> 22, or 23?

Indeed. I did more research over the weekend and what I see is my code 
works fine
when the slice is using the RPS in the slice header. It all goes wrong 
when it tries
to use one of the SPS RPS entries. I'm tracking the idx correctly, as 
best I can tell,
so I must be doing something else wrong.

On that subject:

I'm current basing the RefPic entries and the 
StCurrBefore/StCurrAfter/LtCurr on data
that the primary hevc decoder in ffmpeg is calculating and publishing at 
the frame
level. This seems to be the right thing to do, but given these problems, 
I fear I'm
missing something. The logic I have here is the same as the dxva 
implementation which
works, I'm told, so I don't know what to make of it.

My code is here, FWIW:

https://github.com/philipl/FFmpeg/commits/vdpau-hevc

Thanks,

--phil