After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734441 - videodecoder: in reverse playback, flush the output queue after decoding each keyframe chain
videodecoder: in reverse playback, flush the output queue after decoding each...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-07 15:46 UTC by George Kiagiadakis
Modified: 2014-08-11 08:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gstvideodecoder: in reverse playback, flush the output queue after decoding each keyframe chain (5.56 KB, patch)
2014-08-07 15:46 UTC, George Kiagiadakis
committed Details | Review

Description George Kiagiadakis 2014-08-07 15:46:08 UTC
Created attachment 282823 [details] [review]
gstvideodecoder: in reverse playback, flush the output queue after decoding each keyframe chain

There is a problem in reverse playback when the upstream parser/demuxer is not fully parsing the stream and is not providing each keyframe chain separately to the decoder. In that case, the decoder outputs frames in the wrong order and this patch fixes that.

The patch commit message explains this in detail.
Comment 1 Sebastian Dröge (slomo) 2014-08-11 08:49:59 UTC
commit a4d97f49e209eedd59891e27fa28d4d67cc38046
Author: George Kiagiadakis <george.kiagiadakis@collabora.com>
Date:   Thu Aug 7 18:10:41 2014 +0300

    videodecoder: In reverse playback, flush the output queue after decoding each keyframe chain
    
    This fixes the reverse playback scenario when upstream is not fully
    parsing the stream and does not send every keyframe chain separately
    with the DISCONT flag on the keyframe.
    
    To explain this, let's suppose we have this stream:
     0 1 2 3 4 5 6 7 8
     K     K     K
    
    In most circumstances, the upstream parser will chain in the
    decoder the buffers in the following order:
    
     6 7 8 3 4 5 0 1 2
     D     D     D
    
    In this case, GstVideoDecoder will flush the parse queue every time
    it receives discont (D) and we will eventually get in the output queue:
    
      (flush here) 8 7 6  (flush here) 5 4 3 (flush here) 2 1 0
    
    In case the upstream parser doesn't do this work, though,
    GstVideoDecoder will receive the whole stream at once and will flush
    the parse queue afterwards:
    
     0 1 2 3 4 5 6 7 8
     D
    
    During the flush, it will look backwards for keyframes and will
    decode in this order:
    
     6 7 8 3 4 5 0 1 2
    
    This is the same order that it would receive from upstream if
    upstream was parsing and looking for the keyframes, only that now
    there is no flushing of the output queue in between keyframes,
    which will result in the output queue looking like this:
    
     2 1 0 6 5 3 8 7 6
    
    This will confuse downstream obviously and will play incorrectly.
    This patch forces the decoder to flush the output queue every time
    it picks a new keyframe to decode, so it will end up decoding 6 7 8
    and then flushing before picking 3 for decoding, so the output will
    get 8 7 6 before 6 5 3 and the video will play back correctly.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=734441
: