[Bug 762509] vaapidecoder: h264: decoder stores too many pictures in the DPB before output

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762509

--- Comment #11 from Matt Staples <staples255 at gmail.com> ---
I have had this same problem with a number of sources (specifically, security
cameras accessed via RTSP) that don't provide the optional vui header
information. I see the same behavior where lots of decoded pictures are held in
the DPB, and not sent downstream until they're bumped out by the next reference
frame.  For some sources, the sink ends up dropping many of those frames (as
too late), creating a very jittery presentation. 

Note that if I replace the vaapi decoder with avdec_h264, the same streams play
smoothly and with low latency.  In order to get the vaapi decoder to play
smoothly, without dropping any frames, I have to add about 500ms of latency to
the pipeline, so that's not really a viable solution for viewing and
controlling PTZ cameras.

So I think there may be two problems here: one is that given the current
design, the vaapi h264 decoder element seems to be under-reporting its latency.
 If it's going to potentially hold on to, say, 16 frames, then I think it needs
to report that much latency so that the sink doesn't end up dropping frames
when they're eventually released.

The second problem is that I think the current design could be improved to
reduce latency by following the ffmpeg library's model and outputting frames
for display as soon possible, but while leaving references to those frames in
the DPB per requirements of the h264 spec.  (Even if a is still potentially
needed for reference, it should be displayable as soon as its fully decoded and
there are no sequence gaps that need to be filled in by later frames.)

So I've been experimenting with that approach, and I believe I've proved the
concept, but I don't know the best way to determine when there are gaps in the
sequence.  h264dec.c from ffmpeg has some complicated bookkeeping along those
lines, but I'm not yet familiar enough either set of code to see how to apply
the ffmpeg logic to vaapidecoder_h264.  
Is that something that could be inferred by comparing the number of 'ready'
frames in the DPB with the GstVaapiDecoderH264Private members,
RefPicList0_count and RefPicList1_count?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.