[FFmpeg-devel] [VAAPI] H264 need sample with long term reference
Stephen Warren
swarren
Wed Jun 17 17:36:03 CEST 2009
Cyril Russo wrote:
> I've discussed a lot with VA API specialist. The un-official statement
> is than, 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.
A note on this: I have some streams with long references. However, I
believe they're copyright, so unfortunately I can't provide them to
anyone else. However, I did just test them using ffmpeg/VDPAU/MPlayer,
and they decode with corruption. With ffmpeg SW decoding, they either
have no corruption, or significantly less.
In one particular case (where ffmpeg SW decode appears perfect), the
top 1/2 of the image is non-corrupt, and the bottom half corrupt. This
seems like it could be due to differing reference lists per slice.
Hence, the ffmpeg/VDPAU "DPB" extraction logic probably isn't correct,
Assuming there aren't any other issues at play too.
YI, the files are named mmco0[12345].264 in case anyone else has them.
> 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 ?
--
nvpublic
More information about the ffmpeg-devel
mailing list