From dfa548dc5b88d52e46c81d33d3f96193e68f8efe Mon Sep 17 00:00:00 2001 From: Edward Hervey Date: Tue, 10 Jan 2017 15:59:55 +0100 Subject: [PATCH] videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS When the input is TRICKMODE_KEY_UNITS, we expect to only receive keyframes which we want to decode/push immediately. Therefore don't queue them. If upstream didn't send just keyframes (which is the ideal situation), two different things can happen: 1) Either the subclass checks the segment flags and properly configures the decoder implementation to only decode/output keyframes, 2) Or the subclass really decodes and outputs everything, in which case the reverse frames will end up arriving "late" downstream (and will be dropped). If upstream did properly send GOP in reverse order, we still end up just showing keyframes (but at the overhead of decoding everything). https://bugzilla.gnome.org/show_bug.cgi?id=777094 --- gst-libs/gst/video/gstvideodecoder.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gst-libs/gst/video/gstvideodecoder.c b/gst-libs/gst/video/gstvideodecoder.c index f748587693..7f0b569d61 100644 --- a/gst-libs/gst/video/gstvideodecoder.c +++ b/gst-libs/gst/video/gstvideodecoder.c @@ -3052,7 +3052,8 @@ gst_video_decoder_finish_frame (GstVideoDecoder * decoder, gst_video_decoder_release_frame (decoder, frame); frame = NULL; - if (decoder->output_segment.rate < 0.0) { + if (decoder->output_segment.rate < 0.0 + && !(decoder->output_segment.flags & GST_SEEK_FLAG_TRICKMODE_KEY_UNITS)) { GST_LOG_OBJECT (decoder, "queued frame"); priv->output_queued = g_list_prepend (priv->output_queued, output_buffer); } else {