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 702778 - REGRESSION : Backward seeking doesn't work with mp3 files.
REGRESSION : Backward seeking doesn't work with mp3 files.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal blocker
: 1.1.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-20 21:14 UTC by Mathieu Duponchelle
Modified: 2013-07-12 19:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Mathieu Duponchelle 2013-06-20 21:14:24 UTC 
That's probably a problem in baseparse.

Very easily reproducible with the playback-test binary in base :

./playback-test 1 "filesrc location=/music/mp3 ! mad ! audioconvert ! autoaudiosink"

Seek to some place, then seek back at the beginning : no more sound.

This bug is most likely related to https://bugzilla.gnome.org/show_bug.cgi?id=691481#c25 , comment 25 actually pointed it out.
Comment 1 Tim-Philipp Müller 2013-06-20 21:51:48 UTC 
How weird, I'm quite sure that got fixed..
Comment 2 Tim-Philipp Müller 2013-06-20 21:53:13 UTC 
Actually, please reproduce and test with decodebin or playbin. mad alone does not support seeking any more with 1.0, you need an mpegaudioparse in front of it. But I can reproduce this with playbin and git master.
Comment 3 Mathieu Duponchelle 2013-06-20 21:55:12 UTC 
Oh damn I'm sorry ! I posted the bad pipeline, this one shows the problem :

./playback-test 1 "uridecodebin uri=file:///home/music.mp3 ! autoaudiosink"
Comment 4 Youness Alaoui 2013-07-02 21:32:11 UTC 
I can confirm, I have the same issue with seeking in MP3. I tried with totem, and it indeed doesn't seek backwards.
Note that if we do a query_position after the seek, it will keep returning the old position before the seek, and the position won't advance, i.e: it's not playing anymore.
Comment 5 Wim Taymans 2013-07-03 19:28:31 UTC 
commit 97b1e17b097f6e510920618d17433fda5e5a039e
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Jul 3 21:23:44 2013 +0200

    baseparse: reset PTS after seek
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702778
Comment 6 Tim-Philipp Müller 2013-07-12 19:35:39 UTC 
This bug never applied to the 1.0.x series, only a temporary regression in git master in the development series. (Made it wrongly into 1.0.8 release notes though unfortunately, I should've checked close)