[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 #45 from Matt Staples <staples255 at gmail.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #44)
> I was thinking in another approach to activate this 'low-latency' mode.
> Assuming that this case is going to happen mostly with live sources, why not
> enable it when upstream reports the source as a live one?
> 
>     query = gst_query_new_latency ();
>     is_live = FALSE;
>     /* Check if upstream is live. If it isn't we can enable frame based
>      * threading, which is adding latency */
>     if (gst_pad_peer_query (GST_VIDEO_DECODER_SINK_PAD (vdec), query)) {
>       gst_query_parse_latency (query, &is_live, NULL, NULL);
>     }
>     gst_query_unref (query);
> 
>     gst_vaapi_decoder_h264_set_low_latency (decoder, is_live);
> 
> What do you think?

Interesting idea, but I'm not sure the need for this mode correlates entirely
with live sources. Wouldn't playback of recorded live streams have the same
behavior?  

Although I called it 'low-latency' mode, it's largely about avoiding the
jittery rendering that's caused when the actual latency exceeds the value that
the decoder reports to the sink. So I think it would be useful in playback as
well as for live streams.

Conversely, I don't know whether it's possible for live streams to have the
IBB... pattern for which the low-latency mode breaks strict conformance. If it
is, then users might still want the strict behavior for those streams.

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