[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 #29 from Matt Staples <staples255 at gmail.com> ---
(In reply to sreerenj from comment #27)
> (In reply to Matt Staples from comment #26)
> > Created attachment 352653 [details] [review] [review]
> > send frames out as soon as possible
> > 
> 
> It could be rare, but technically it is valid to have a GOP of "IBB..." in
> decoding order, and B frames come before the first I frame in display order.
> So dropping frame is not seems to be the solution.

Could you point me to an example of that?  I'm curious how libav decoder would
handle that. I suspect it wouldn't handle it well since it drops frames in a
similar way to my proposed patch.  As I've learned though the gstlibavdec
element is not requesting strict compliance from the ffmpeg decoder code, so I
believe the vaapidecoder is simply more correct.

I found that unlike gstlibavenc, which exposes a 'compliance' property,
gstlibavdec just uses the default value of FF_COMPLIANCE_NORMAL.  By hacking
the code to use FF_COMPLIANCE_STRICT, I got it to behave more like vaapidecoder
does. Specifically, with the 2nd attached file, it holds on to about 9 more
frames before sending any downstream, and it doesn't appear to drop any frames.
 Whereas the as-is (FF_COMPLIANCE_NORMAL) version of libavdec behaves more like
my patched version of vaapidecoder.

So anyway, I think there's a president for having some sort of compliance
property to allow users to decide between strict compliance and lower latency
(for applicable video sources).  It might be even be nice to add that property
to both libavdec and vaapidec, although to avoid introducing problems with
existing code, they'd need to have different default behavior.

Would that be an acceptable solution?

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