videodecoder: Don't queue frames in TRICKMODE_KEY_UNITS
authorEdward Hervey <edward@centricular.com>
Tue, 10 Jan 2017 14:59:55 +0000 (15:59 +0100)
committerEdward Hervey <bilboed@bilboed.com>
Sat, 20 May 2017 15:37:27 +0000 (17:37 +0200)
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

index f748587..7f0b569 100644 (file)
@@ -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 {