[FFmpeg-devel] [VAAPI] H264 need sample with long term reference
Wed Jun 17 11:13:20 CEST 2009
Michael Niedermayer a ?crit :
>> Either we intepret the VAAPI doc as what you're suggesting, where each
>> slice accumulate in the ref array that is send first (in that case, I need
>> to merge the ref in decode_slice function).
>> I think the former is the intended case, even if, I agree, it isn't a very
>> smart choice.
> i dont suggest anything,
> the code and the comments have no relation
> the per frame code uses per slice fields that are not valid for more
> than a single slice, this looks like a serious bug. If it is not so it has
> to be elaboretly justified and documented, not hidden as it is.
> What you do is like saying the first name of the first page describes the
> phone book in which it is written. I hope this makes it clear where the
> issue is.
I've discussed a lot with VA API specialist. The un-official statement
is that, to simplify the hardware vendor drivers, the current VAAPI
implementation should follow ITU. H264 Annex C guideline.
This means that we must maintain a DPB (decoded picture buffer):
"The ReferenceFrames array holds the DPB and it needs to be filled
according to the C.4.4 and C.4.5 sections in the H.264 spec."
There isn't such thing in FFmpeg currently, and the current VAAPI H264
code "recreate" the most simplest DPB in its start_frame call.
VDPAU on the opposite, use short_ref and long_ref to recreate their
DPB from each slice.
However, Gwenole initially interpreted the ReferenceFrame array as the
DPB for the first slice only, as the other slice have their own
reference frame list.
The H264 standard state that the RefFrameArray should be updated for
each frame (so we must keep it in the context, not recreate it from
scratch for each frame like it is currently).
As Michael pointed out, it's not clear, and I would like to get a
definitive answer here.
While it works for the samples I have, I'm wondering if a video sample
with long term reference would work.
So, do you guys have such a sample laying around so I can test the
different implementations to sort that out ?
More information about the ffmpeg-devel