[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 #33 from Matt Staples <staples255 at gmail.com> ---
(In reply to sreerenj from comment #31)
> I liked the idea of compliance property STRICT/NORMAL(may be something other
> than normal could be more ideal since we tweaking the spec).
> 
Ok, I'll work on adding a new property.  And per the code review, I'll try to
make it specific to h264 instead of being available to all flavors of
vaapidecode.
I was assuming it would default to the current behavior, which I might call
"strict". Maybe "low-latency" for the new mode?

> BTW, there are other things which we should consider: your patch checking
> for a difference in POC <=2 , which is not true always. There could be poc's
> like 0,4,8 with only I and P frames. A perfect real life use case example is
> Hierarchical P frame encoded sample with 3 layers were the
> application(streaming source or something) or the decoder it self is
> dropping the 3rd layer.
> 
In the case of POC spacing > 2, I the patch would be unable to send frames
frames sooner.  So it wouldn't provide low-latency, but since all frames will
eventually get sent in the proper order upon normal calls to dpb_bump(), it
will naturally fall back to original (strict) behavior.

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