[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 #26 from Matt Staples <staples255 at gmail.com> ---
Created attachment 352653
  --> https://bugzilla.gnome.org/attachment.cgi?id=352653&action=edit
send frames out as soon as possible

This patch replaces my previous patch, with corrections for handling
interleaved data, and for handling negative POC values.  It plays all of the
attached samples (as well as all other sources I've tested with).

In reply to sreerenj's comment (#25):
I agree with everything you've said; the un-modified vaapi code decodes and
displays in the correct order.  This bug only has to do with how long it holds
onto frames before sending them downstream.  So it's about timing, not order.

The display-order problems that I mentioned above were just with my proposed
patch, and only with the attached samples, not with any other sources I've
tested with, including those with B-frames.  
I've been struggling to correct that, and I believe this new patch works as
well as the software decoder does with those files.

My patch doesn't have any problems with your first example. It sends the
initial I-frame (POC=0) downstream immediately.  The next decoded frame, POC=6,
indicates a gap, so it can't be sent downstream until after frames with POC=2
and POC=4 are decoded.  So the timing of sending frames downstream looks
something like the following: 
Decode order:              I  P  B  B    P
POC in Dec order:          0  6  2  4    12
Frames sent after decode:   0     2  4 6

The attached test file has the problem that first decoded frame is not also the
first first frame in display order. (I believe that's unusual or maybe
something that only happens when a file starts in mid-GOP?)  Anyway, frame
-72/-71 gets sent downstream immediately.  Then, when frame -76/-75 is decoded,
it's too late to display it in the proper order, so I have no choice but to
drop it and the next couple frames.  The next frame sent downstream is -70/-69
and then the rest of file plays in the proper order with no dropped frames. 

Note that the software decoder appears to have the same issue and actually
drops more frames with that file than my patched code does.

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