GNOME Bugzilla – Bug 405213
mp3 plays too fast in totem or rhythmbox
Last modified: 2007-02-14 09:56:14 UTC
Please describe the problem: A few of my mp3s play too fast with totem or rhythmbox. I get errors like this: ** (totem:22359): WARNING **: Internal GStreamer error: clock problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. [gstbaseaudiosink.c(619): gst_base_audio_sink_render (): /play/visbin/abin/audiosinkbin/audio-sink/bin1/alsasink0: Unexpected discontinuity in audio timestamps of more than half a second] If I play the files manually (gst-launch filesrc location="test.mp3" ! mad ! alsasink) it works fine. Steps to reproduce: 1. Get test.mp3 (will either attach it or url to it) 2. Play test.mp3 with madplay (see how it is supposed to sound) -- should play for 8 seconds. 3. Play with totem Actual results: totem plays it way too fast (3 seconds instead of 8). Expected results: totem plays it at the right speed. Does this happen every time? Yes. Other information:
Created attachment 82062 [details] Test mp3 Here is an mp3 that demonstrates this.
This file is actually a wav file, with mp3 in it rather than a plain mp3. madplay and friends work, because they skip the wav header implicitly (looking for an mp3 frame), and then play the remainder of the file correctly because it is mp3. Changing wavparse to not generate output timestamps, allowing the mp3 decoder to timestamp things itself makes it work. wavparse is trying to use the recorded bps (of 44100) when generating output timestamps, making the timestamps increment then drop back sharply.
Ah, that would explain it. I guess this would also explain why gstreamer apps won't play slightly corrupted mp3s that players like xmms/madplay will work ok with. It'd be nice if gstreamer could handle non-standard files more robustly. One question... Why does it work when you use gst-launch ... ! mad ! alsasink ?
It works when fed to mad directly for the same reason it works in madplay - the element skips the 'wav' header part at the start of the file because it is looking for an MP3 frame marker, and the wav header just looks like junk. I'd like to see any 'slightly corrupted' mp3 files that xmms/madplay play better than GStreamer - in general that shouldn't be true, it's not the same case as this really at all.
the only way to solve this is to disable the timestamping in wavparse for compressed formats and simply feed bytes to the decoders. Will see if I can cook up a patch.
* gst/wavparse/gstwavparse.c: (gst_wavparse_class_init), (gst_wavparse_reset), (gst_wavparse_init), (gst_wavparse_destroy_sourcepad), (gst_wavparse_fmt), (gst_wavparse_parse_file_header), (gst_wavparse_stream_init), (gst_wavparse_perform_seek), (gst_wavparse_peek_chunk_info), (gst_wavparse_stream_headers), (gst_wavparse_parse_stream_init), (gst_wavparse_add_src_pad), (gst_wavparse_stream_data), (gst_wavparse_loop), (gst_wavparse_chain), (gst_wavparse_pad_convert), (gst_wavparse_pad_query), (gst_wavparse_srcpad_event), (gst_wavparse_change_state), (plugin_init): * gst/wavparse/gstwavparse.h: Update docs. Use boilerplate. Various code cleanups. When the bitrate is not known (bps == 0 or compressed formats) let downstream element guestimate the duration and position and don't generate timestamps or durations. Fixes #405213. Fix EOS and ERROR conditions in chain mode, we just need to forward the error flowreturn upstream.