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 679250 - matroska: Reverse playback not working with webm file
matroska: Reverse playback not working with webm file
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 679502 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-07-02 10:02 UTC by Xavi Artigas
Modified: 2018-11-03 14:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Basic tutorial 13 from the GStreamer SDK tutorials (3.44 KB, application/octet-stream)
2012-07-02 10:02 UTC, Xavi Artigas
Details

Description Xavi Artigas 2012-07-02 10:02:35 UTC
Created attachment 217815 [details]
Basic tutorial 13 from the GStreamer SDK tutorials

The attached code exercises multiple trick modes.
With a webm file, frame stepping and fast forward seem to work correctly, but, going backwards (press 'D') is completely ignored for HTTP files and hangs with this message for local files:
CRITICAL **: gst_matroska_demux_seek_to_previous_keyframe: assertion `demux->seek_index' failed

gst-playback-test is reported as not working nicely either.
Comment 1 Sebastian Dröge (slomo) 2012-07-02 10:06:17 UTC
Frame stepping and changing the playback speed is unreliable for me though, sometimes just stopping the video and blocking the application thread.
Comment 2 Sebastian Dröge (slomo) 2012-07-04 08:27:28 UTC
Moving this to gst-plugins-good for the reverse playback brokeness only. The broken step events will be handled in another bug.
Comment 3 Sebastian Dröge (slomo) 2012-07-18 08:54:47 UTC
Changing the seeks to flushing seeks works a bit better, it just hangs at a single frame all the time and for backwards playback it goes to "duration-position" instead of staying at the current position.

When changing the code to use a non-flushing seek without positions with 1.0 (instead of forward) or 2.0 (instead of backward) the change to 2.0 works but when changing back to 1.0 playback stops soon.
Comment 4 Mark Nauwelaerts 2012-07-18 09:58:14 UTC
[as also discussed on IRC]

Part of what happens with a _NONE seek (changing e.g. rate) with current position at 5s is:
* start and stop of segment remain unchanged
* FLUSH clears current state

So a segment (0, duration) is sent followed by buffers at the current position (5s), which delays playback until running_time/clock reaches 5s.

Likely something similar occurs in non-FLUSH since the additional accumulated/base segment time merely matches the current clock-time but will still leave a "gap" for future running time.

No idea at present on index disappearing though ...
Comment 5 Sebastian Dröge (slomo) 2012-07-18 10:12:07 UTC
*** Bug 679502 has been marked as a duplicate of this bug. ***
Comment 6 Sebastian Dröge (slomo) 2012-07-19 11:22:47 UTC
Current status:

* flushing seek with position:
  + playback speed changes work
  + reversing playback direction works
* flushing seek without a position:
  + playback speed changes work
  - reversing playback direction doesn't work (shows last frame)
* non-flushing seek with position: 
  - normal non-flushing seeks are a bit broken too, playback stutters after going to the new seek position
  - playback speed changes work after quite some time but this does not seem to be related to wrong segments, lots of buffers are dropped with GST_FLOW_OK between demuxer and sink
  + reversing playback direction works once without problems but not again
* non-flushing seek without position:
  - playback speed changes work after some time, most of the time
  - reversing playback direction doesn't work
Comment 7 Sebastian Dröge (slomo) 2012-07-19 14:18:16 UTC
One of the problems with reversing playback direction without providing positions is, that the segment has no stop position and thus matroskademux outputs everything from the current position until EOS. Changing it to stop at the seek position (for rate < 0) makes "flushing seek without a position" for reverse playback working.
Comment 8 Sebastian Dröge (slomo) 2012-07-20 09:16:52 UTC
commit 3be8742262d02f47747f0525cc5bda156ec69787
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri Jul 20 11:07:58 2012 +0200

    matroskademux: Fix reverse playback for seeks without stop position

commit e58d777454fe664bf1e73d632b647b1f52d6a25b
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri Jul 20 11:07:16 2012 +0200

    matroskademux: Use correct newsegment values for all the different seek types
    
    This fixes rate changes for flushing seeks without positions.

commit 75016c4795d8078a88fdcc2e8f596825d85f8888
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri Jul 20 10:48:34 2012 +0200

    matroskademux: Only take the stream_start_time into account for SET seeks
    
    For other seeks the stream_start_time is already added to the
    segment values.
Comment 9 Sebastian Dröge (slomo) 2012-07-20 11:20:01 UTC
Remaining problems are:

* flushing seek without positions:
 - playback does not continue at the current position but goes back in time sometimes
 - reverse playback stops at the last keyframe before position 0
* non-flushing seek with positions:
 - after seeking playback is stuttering quite often
 - playback needs some time to start and starts not at the expected position
* non-flushing seek without positions:
 - Reverse playback fails (gst_matroska_demux_seek_to_previous_keyframe: assertion `demux->seek_index' failed)
 - after seeking playback is stuttering quite often
 - playback needs some time to start and starts not at the expected position
Comment 10 Tim-Philipp Müller 2014-11-27 01:03:16 UTC
Reverse playback of sintel-trailer-480p.webm works "fine" for me with the playback sample app (rate=-1.0,seek to end), where "fine" means it stutters a bit when crossing GOP boundaries, but that's because there's not enough buffering in playbin. Did not try the test code yet.
Comment 11 GStreamer system administrator 2018-11-03 14:46:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/65.