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 645531 - flushing seek to reverse playback direction changes frame
flushing seek to reverse playback direction changes frame
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-22 14:40 UTC by Andy Wingo
Modified: 2018-11-03 12:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Andy Wingo 2011-03-22 14:40:45 UTC 
Steps to reproduce:

1. Open any video file in ./seek 16 file:///....

I was able to reproduce this problem with MPEG4 video and AAC audio in an MPEG4 container, and with the pitivi 0.13.1-final.ogv movie, so it should be general.

2. Play forward until there is a scene with some movement, so you can tell if the frame changes or not.  Hit pause.

3. Go to the "rate" box, add a minus sign before the 1.000, and hit enter.

Expected results:

The showed frame does not change.

Actual result:

The frame changes to the next one in the new play direction.
Comment 1 Luis de Bethencourt 2011-03-22 16:45:48 UTC 
I think Andy means...

Expected results:

The frame changes to the next one in the new play direction.

Actual result:

The showed frame does not change.


I'm seeing the same error in my frame-stepping code:
http://pastebin.com/C5izS0GZ
Comment 2 Andy Wingo 2011-03-22 16:51:15 UTC 
I did not mean that, actually.  A seek to a position should resolve to the same frame, regardless to play speed or direction.
Comment 3 Jonathan Roy 2016-05-17 20:50:44 UTC 
The "current" frame, by definition, is the one with the largest time stamp less than or equal to the current pipeline position. In reverse playback, frames are time stamped backwards, so for a given position, the current frame in forward and reverse is *not* the same, actually, unless the current position exactly equals the time stamp of the current frame.
Comment 4 GStreamer system administrator 2018-11-03 12:14:51 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/gstreamer/issues/20.