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 162833 - [ffdec_mp3] Requires mp3parse to seek
[ffdec_mp3] Requires mp3parse to seek
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 609434 660559 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-03 18:00 UTC by Christian Fredrik Kalager Schaller
Modified: 2011-09-30 13:58 UTC
See Also:
GNOME target: 2.14.x
GNOME version: 2.13/2.14



Description Christian Fredrik Kalager Schaller 2005-01-03 18:00:32 UTC
If you don´t have mad plugin installed the ffmpeg mp3 plugin is used instead.
But this does not support seeking and if you try to seek it crashes the
application in question (tested with rhythmbox and totem)
Comment 1 Christian Fredrik Kalager Schaller 2005-01-03 18:07:46 UTC
The crash only happens if the mp3 have tags. For non-tagged songs the seeker
gets disabled.
Comment 2 Christian Fredrik Kalager Schaller 2005-01-03 18:25:15 UTC
Sometimes the seeker bar actually moves, but trying to move it with the mouse
still cause a hang.

I see that after seek totem and rb goes to 100% cpu and becomes unresponsive.
Comment 3 Michaël Arnauts 2005-03-02 14:32:27 UTC
when i try to seek, rhythmbox skips to the next song, i am using the latest cvs
from the 0.8 branch
Comment 4 Andreas Eibach 2005-08-06 06:40:26 UTC
Hi, I have the same problem (still). 
ffd does not skip correctly at all, and the hangs which Michaël reported can 
be confirmed when I use MAD lib for mp3 playback 
(which is standard in rhythmbox btw) 
 
The hangs are so severe that rhythmbox will have to be restarted. 
It's better to not skip at all at the moment. 
Using gstreamer/gst-plugins 0.8.10 / rhythmbox 0.8.8. 
 
Any chance of this being fixed in cvs? 
Comment 5 Andreas Eibach 2005-08-06 06:43:40 UTC
Sorry, the hangs were reported by Christian of course (Christian I could bet 
you're using 'mad' for mp3 playback too!). The skips to next song (instead of 
skipping within current song) which Michaël reported occur if and only if I 
use ffd for mp3 playback and not mad. 
 
Comment 6 Christian Fredrik Kalager Schaller 2005-10-05 10:39:46 UTC
No I am using only ffmpeg mp3 decoder for the issue reported. With mad I had no
problems.
Comment 7 Christian Fredrik Kalager Schaller 2006-01-31 16:31:09 UTC
Discussed this with Thomas and Wingo today. There is a general issue here of how to handle ffmpeg decoders which we don't really use, like mp3 and mpeg2. I think there was some concensus that until someone bothers fixing them we should as a minimum make sure they don't autoplug with playbin. So that if you try to play a mp3 in a playbin based application you are told to get a mp3 plugin (like mad or fluendo mp3) instead of getting crappy mp3 playback from a semi-working ffmpeg plugin. I will try looking into solving by setting rank to none on the affected decoders.
Comment 8 Edward Hervey 2006-02-02 08:59:21 UTC
(In reply to comment #7)
> Discussed this with Thomas and Wingo today. There is a general issue here of
> how to handle ffmpeg decoders which we don't really use, like mp3 and mpeg2. I
> think there was some concensus that until someone bothers fixing them we should
> as a minimum make sure they don't autoplug with playbin. So that if you try to
> play a mp3 in a playbin based application you are told to get a mp3 plugin
> (like mad or fluendo mp3) instead of getting crappy mp3 playback from a
> semi-working ffmpeg plugin. I will try looking into solving by setting rank to
> none on the affected decoders.
> 
Indeed, decodebin filters out pluginfeatures with a rank below GST_RANK_MARGINAL. That should do it.
Comment 9 Christian Fredrik Kalager Schaller 2006-02-02 10:45:42 UTC
Commited Rank None to CVS. Closing this as fixed.
Comment 10 Alexander Kojevnikov 2010-02-12 07:09:26 UTC
*** Bug 609434 has been marked as a duplicate of this bug. ***
Comment 11 Alexander Kojevnikov 2010-02-12 07:13:34 UTC
Re-opening the bug, the issue is still there (see the duplicate).

Steps to reproduce:

 * Install gstreamer0.10-ffmpeg
 * Uninstall gstreamer0.10-ugly-plugins if it's installed
 * Try playing an mp3 in Totem

The mp3 plays but Totem cannot seek it (it's shown as streaming). It should either allow to seek or propose to install the ugly plugins for mp3 files.
Comment 12 Edward Hervey 2010-02-12 11:59:42 UTC
The problem is that the ffmpeg mp3 decoder doesn't handle seeking. It requires having a parser before it (like mp3parse provided by gst-plugins-ugly).
Comment 13 Tim-Philipp Müller 2010-08-04 11:40:02 UTC
Technically I would regard this as WONTFIX, but I guess the problem from the user point of view is valid, which is exacerbated by the fact that mp3parse is (still) in -ugly.

A hackish workaround might be to make ffdec_mp3 check if mp3parse is available when changing from NULL->READY state and posting a missing-plugin message if it's not.
Comment 14 Tim-Philipp Müller 2011-05-20 13:41:42 UTC
Since we now have an mp3 parsers in -good, this shouldn't be a problem any longer for users, so let's just fix this as OBSOLETE.
Comment 15 Rob D 2011-06-21 23:34:44 UTC
It has been suggested that https://bugzilla.gnome.org/show_bug.cgi?id=653124 is a duplicate of this bug.
I have Kubuntu 11.04 with all latest supported packages, including gstreamer0.10-plugins-good, and I'm still (and only sometimes - see bug) unable to seek.

Has this update been done to the gstreamer good plugins since 11.04 was released? As otherwise, the bug is very much still there... Or it's not a duplicate.

Rob
Comment 16 Bastien Nocera 2011-09-30 13:58:05 UTC
*** Bug 660559 has been marked as a duplicate of this bug. ***