GNOME Bugzilla – Bug 680252
[playbin2] Hang during OGG -> FLAC transition
Last modified: 2014-12-23 11:40:53 UTC
- play ogg vorbis file - seek near to the end - wait for about-to-finish - set new uri property (flac file) - playbin2 hangs when the transition should happen - a position query returns always the same value - state is still playing Testcase: http://pastie.org/pastes/4283968/text (edit the uris..) Output: GST_STATE_PLAYING 252 file:///home/user/a.ogg GST_STATE_PLAYING 254 file:///home/user/a.ogg GST_STATE_PLAYING 255 file:///home/user/a.ogg GST_STATE_PLAYING 256 file:///home/user/a.ogg about to finish, set flac as next song GST_STATE_PLAYING 257 file:///home/user/a.flac GST_STATE_PLAYING 257 file:///home/user/a.flac GST_STATE_PLAYING 257 file:///home/user/a.flac GST_STATE_PLAYING 257 file:///home/user/a.flac GST_STATE_PLAYING 257 file:///home/user/a.flac .... IRC-log: <bilboed> yah, known issue <lazka> bilboed, do you mean me? <bilboed> yes <lazka> Any hints where to find it in the bugtracker? <bilboed> don't think there is an open bug about it <lazka> Should I open one? <bilboed> that could help <lazka> ok
*** Bug 680260 has been marked as a duplicate of this bug. ***
I enconter this bug too with quodlibet : http://code.google.com/p/quodlibet/issues/detail?id=994
Rhythmbox is also affected by this bug: http://bugs.debian.org/668109 It's not just the transition from ogg to flac. But from mp3 to ogg or mp3 to flac.
Using Totem (3.4.2-1) to play an Ogg and a FLAC file I cannot reproduce this. Using Rhythmbox to play a playlist composed of these two files I can reproduce this. This system is Debian Sid/unstable with libgstreamer-plugins-base0.10-0 0.10.36, self-built Rhythmbox 2.98-1 and Totem 3.4.2-1.
With Totem (and not with Rhythmbox) I hit bug 688837. (Playing just one Ogg file in a loop does not work the second time.) Tim tested that GStreamer 1.0.x (with Totem 3.7) does not show this problem. Could somebody please test with GStreamer 1.0.x, which are already in Debian Sid/unstable? [1] https://bugzilla.gnome.org/show_bug.cgi?id=688837
Testing the script from the original reported with GStreamer 0.10.36, I cannot *exactly* reproduce the behavior. Playback of the FLAC file starts after the amount of seconds the Ogg file was played beforehand. $ python --version Python 2.7.3 $ python test.py start seek to 5 seconds before the ogg finishes GST_STATE_PLAYING 106 file:///tmp/a.ogg GST_STATE_PLAYING 107 file:///tmp/a.ogg GST_STATE_PLAYING 108 file:///tmp/a.ogg about to finish, set flac as next song GST_STATE_PLAYING 109 file:///tmp/a.flac GST_STATE_PLAYING 110 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 5 file:///tmp/a.flac GST_STATE_PLAYING 6 file:///tmp/a.flac GST_STATE_PLAYING 7 file:///tmp/a.flac GST_STATE_PLAYING 8 file:///tmp/a.flac GST_STATE_PLAYING 9 file:///tmp/a.flac GST_STATE_PLAYING 10 file:///tmp/a.flac GST_STATE_PLAYING 11 file:///tmp/a.flac Now with starting twenty seconds before end. $ python test.py start seek to 20 seconds before the ogg finishes GST_STATE_PLAYING 91 file:///tmp/a.ogg GST_STATE_PLAYING 92 file:///tmp/a.ogg GST_STATE_PLAYING 93 file:///tmp/a.ogg GST_STATE_PLAYING 94 file:///tmp/a.ogg GST_STATE_PLAYING 95 file:///tmp/a.ogg GST_STATE_PLAYING 96 file:///tmp/a.ogg GST_STATE_PLAYING 97 file:///tmp/a.ogg GST_STATE_PLAYING 98 file:///tmp/a.ogg GST_STATE_PLAYING 99 file:///tmp/a.ogg GST_STATE_PLAYING 100 file:///tmp/a.ogg GST_STATE_PLAYING 101 file:///tmp/a.ogg GST_STATE_PLAYING 102 file:///tmp/a.ogg GST_STATE_PLAYING 103 file:///tmp/a.ogg GST_STATE_PLAYING 104 file:///tmp/a.ogg GST_STATE_PLAYING 105 file:///tmp/a.ogg GST_STATE_PLAYING 106 file:///tmp/a.ogg GST_STATE_PLAYING 107 file:///tmp/a.ogg GST_STATE_PLAYING 108 file:///tmp/a.ogg about to finish, set flac as next song GST_STATE_PLAYING 109 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 0 file:///tmp/a.flac GST_STATE_PLAYING 20 file:///tmp/a.flac GST_STATE_PLAYING 21 file:///tmp/a.flac GST_STATE_PLAYING 22 file:///tmp/a.flac GST_STATE_PLAYING 23 file:///tmp/a.flac GST_STATE_PLAYING 24 file:///tmp/a.flac GST_STATE_PLAYING 25 file:///tmp/a.flac
Created attachment 230090 [details] test-ogg-flac-transition.py (test updated to GStreamer 1.0) This works fine on debian sid with 1.0.x GStreamer packages for me: tpm@zingle:~/tmp$ python test-ogg-flac-transition.py start <enum GST_STATE_CHANGE_ASYNC of type StateChangeReturn> (<enum GST_STATE_CHANGE_SUCCESS of type StateChangeReturn>, <enum GST_STATE_PAUSED of type State>, <enum GST_STATE_VOID_PENDING of type State>) 2160 seek to 5 seconds before the ogg finishes <enum GST_STATE_CHANGE_ASYNC of type StateChangeReturn> GST_STATE_PLAYING 2155 file:///home/tpm/a.ogg GST_STATE_PLAYING 2156 file:///home/tpm/a.ogg GST_STATE_PLAYING 2157 file:///home/tpm/a.ogg GST_STATE_PLAYING 2158 file:///home/tpm/a.ogg about to finish, set flac as next song GST_STATE_PLAYING 2159 file:///home/tpm/b.flac GST_STATE_PLAYING 0 file:///home/tpm/b.flac GST_STATE_PLAYING 1 file:///home/tpm/b.flac GST_STATE_PLAYING 2 file:///home/tpm/b.flac GST_STATE_PLAYING 3 file:///home/tpm/b.flac GST_STATE_PLAYING 4 file:///home/tpm/b.flac GST_STATE_PLAYING 5 file:///home/tpm/b.flac GST_STATE_PLAYING 6 file:///home/tpm/b.flac GST_STATE_PLAYING 7 file:///home/tpm/b.flac GST_STATE_PLAYING 8 file:///home/tpm/b.flac GST_STATE_PLAYING 9 file:///home/tpm/b.flac GST_STATE_PLAYING 10 file:///home/tpm/b.flac GST_STATE_PLAYING 11 file:///home/tpm/b.flac GST_STATE_PLAYING 12 file:///home/tpm/b.flac GST_STATE_PLAYING 13 file:///home/tpm/b.flac GST_STATE_PLAYING 14 file:///home/tpm/b.flac
Closing, since it works in 1.x.
I've bisected it to revision 0a111bf26e02e199 [1]. Reverting it on top of 0.10.36 fixes the problem. Ubuntu/Fedora/Debian don't ship gst1.0 players -> Please reconsider. [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=0a111bf26e02e19901969db3b3e83082d594ae55
Reconsider what exactly?
(In reply to comment #10) > Reconsider what exactly? I guess fixing it for 0.10.x. ;-)
(In reply to comment #9) > I've bisected it to revision 0a111bf26e02e199 [1]. Reverting it on top of > 0.10.36 fixes the problem. Thanks a lot for doing that! The commit message mentions fixing bug 640859. I followed up on it and hope that they might know what regressed. > Ubuntu/Fedora/Debian don't ship gst1.0 players -> Please reconsider. Maybe Felipe knows a fix. I hope so. > [1] > http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=0a111bf26e02e19901969db3b3e83082d594ae55
Since there is no 0.10 bugfix release planned... I'd like to know if it is safe to revert the commit in question so e.g. Debian can ship a patch.
It was fixed in 1.0 by this commit commit c9428c96b1ad3dc3ffd9b3041d316f0d1e95e28a Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Tue Jul 10 18:32:13 2012 +0200 baseaudiosink: Resync when ringbuffer resets When the ringbuffer gets restarted (like in setcaps), we *will* have to resync against the new values. Without this we end up blindly assuming the new samples align to the old ones. diff --git a/gst-libs/gst/audio/gstaudiobasesink.c b/gst-libs/gst/audio/gstaudiobasesink.c index 3c5bc29..6997a9c 100644 --- a/gst-libs/gst/audio/gstaudiobasesink.c +++ b/gst-libs/gst/audio/gstaudiobasesink.c @@ -903,6 +903,12 @@ gst_audio_base_sink_setcaps (GstBaseSink * bsink, GstCaps * caps) if (!gst_audio_ring_buffer_acquire (sink->ringbuffer, spec)) goto acquire_error; + /* We need to resync since the ringbuffer restarted */ + sink->priv->avg_skew = -1; + sink->next_sample = -1; + sink->priv->eos_time = -1; + sink->priv->discont_time = -1; + if (bsink->pad_mode == GST_PAD_MODE_PUSH) { GST_DEBUG_OBJECT (sink, "activate ringbuffer"); gst_audio_ring_buffer_activate (sink->ringbuffer, TRUE);
I can confirm that the above fix also works for 0.10 diff --git a/gst-libs/gst/audio/gstbaseaudiosink.c b/gst-libs/gst/audio/gstbasea index e7ff30d..5066ca9 100644 --- a/gst-libs/gst/audio/gstbaseaudiosink.c +++ b/gst-libs/gst/audio/gstbaseaudiosink.c @@ -921,6 +921,12 @@ gst_base_audio_sink_setcaps (GstBaseSink * bsink, GstCaps * if (!gst_ring_buffer_acquire (sink->ringbuffer, spec)) goto acquire_error; + /* We need to resync since the ringbuffer restarted */ + sink->priv->avg_skew = -1; + sink->next_sample = -1; + sink->priv->eos_time = -1; + sink->priv->discont_time = -1; + if (bsink->pad_mode == GST_ACTIVATE_PUSH) { GST_DEBUG_OBJECT (sink, "activate ringbuffer"); gst_ring_buffer_activate (sink->ringbuffer, TRUE);
Thanks for testing, I've cherry-picked this into the 0.10 branch now. commit 969fe8c0b97ae4ac58aacf7530ca1bfbc2b5969a Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Tue Jul 10 18:32:13 2012 +0200 baseaudiosink: Resync when ringbuffer resets When the ringbuffer gets restarted (like in setcaps), we *will* have to resync against the new values. Without this we end up blindly assuming the new samples align to the old ones. Conflicts: gst-libs/gst/audio/gstbaseaudiosink.c