[Bug 762509] H.264 decoder stores too many pictures in the DPB before output

[GStreamer (GNOME Bugzilla)]

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

--- Comment #4 from sreerenj <bsreerenj at gmail.com> ---
Okay, finally I did some analysis :)

-- This patch is actually tweaking the spec....As per spec we are allowed to do
dpb_bump() in 6 scenarios (section C.4.5.3) which all are covered
by the current code .

In detail: the only cases where we can do dpb_bump() other than reaching a dpb
full condition are:
   1: the stream should have adaptive memory control enabled for ref picture 
marking (which is not the case for attached stream)
   2: an IDR frame appeared in the stream

So I am not confident whether the patch is safe for all the decoding scenarios.
For eg: if there is a p frame (which is not yet decoded) which encoded with
lower poc than the poc of currently outputting picture (i mean currently
outputting picture due to the enablement of your patch) , it will break the
whole process.

-- As per my knowledge, for a correctly encoded stream, it should have a VUI()
header with bitstream_restriction_flag set to TRUE and max_dec_frame_buffering
field set with appropriate value which get preference over the value we
calculated otherwise from LEVEL limits.
So in theory, the stream you have attached should have the VUI header extension
with max_dec_frame_buffering value set to 1. Because all the frames have at
most one ref frames, and i can't see any order change in POC. But unfortunately
this stream doesn't have the VUI extension, so we calculated the dpb size
from LEVEL specification (Table provided in A.3.1) which is 9.
Which ended up accumulating more frames in dpb before outputting the queued
frames.

-- Are you getting better performance with software decoder?? I can see buffer
dropping while using avdec_h264 too.

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