GNOME Bugzilla – Bug 698750
playbin: gapless playback using "about-to-finish" doesn't work with http URIs
Last modified: 2013-10-28 10:50:35 UTC
Created attachment 242332 [details] Program to reproduce. Find version with Makefile and test-sound on https://github.com/hzeller/gstreamer-gapless-test Using the 'about-to-finish' callback to set the next URI to play to get gapless playback (as documented) leaks threads on network URIs. With each new URL that is chained, one thread is created and lingers around in the process until it stops working after ~100 streams played. To reproduce, see https://github.com/hzeller/gstreamer-gapless-test (this code exposes different problems in 0.10 and 1.0, so the README.md explains both). Note, this works with file URIs, it only leaks threads with network URIs. This might be due to different fetching/buffering techniques (and might help narrowing down what the problem is).
0.10 is not maintained any longer, so let's focus on the 1.0 issue: I can reproduce this with git master: gapless playback using "about-to-finish" does work fine for local files, but not over http for some reason. It plays fine the first time, and then "about-to-finish" is emitted repeatedly. There might be a race, because I think I had it play twice when running in valgrind. It works fine from local file. $ ps aux | grep web tpm 23643 webfsd -r /usr/share/sounds/ -p 9999 tpm@zingle:~/gst/glib-git/code$ ./test-loop http://localhost:9999/KDE-Sys-Log-In.ogg Now playing: http://localhost:9999/KDE-Sys-Log-In.ogg Running... about-to-finish; setting next to http://localhost:9999/KDE-Sys-Log-In.ogg (left: 6) about-to-finish; setting next to http://localhost:9999/KDE-Sys-Log-In.ogg (left: 5) about-to-finish; setting next to http://localhost:9999/KDE-Sys-Log-In.ogg (left: 4) about-to-finish; setting next to http://localhost:9999/KDE-Sys-Log-In.ogg (left: 3) about-to-finish; setting next to http://localhost:9999/KDE-Sys-Log-In.ogg (left: 2) about-to-finish; setting next to http://localhost:9999/KDE-Sys-Log-In.ogg (left: 1) Returned, stopping playback Deleting pipeline I added the countdown bits to make it stop after N iterations. The about-to-finish lines all run through in about a second.
Definitely a race somewhere. Works better with G_SLICE=always-malloc GST_DEBUG=playbin*:6,*decode*:6,*demux:6,*dec*:6 ./test-loop http://localhost:9999/KDE-Sys-Log-In.ogg 2>dbg.log plays 2 times before it rattles through to the end. About 1 second after round 3 started playing back, it went to emit all those about-to-finish again.
Uh, looks like two bugs got a bit crossed up. I actually filed two different bugs, one for 0.1 and one for 1.0. Here you're referring to the 1.0 - bug 698750 "playbin2" leaks threads playing gapless from network URIs (<- this one. Originally) - bug 698306 Gapless playing using 'about-to-finish' callback fails with HTTP-URIs. So you analysis, probably should go to the second one ( https://bugzilla.gnome.org/show_bug.cgi?id=698306 ). Or maybe we should link these bugs together as duplicate ? (I admit, that I probably made it a bit confusing by having the same source for two different bug reports). Anyway, I now confirmed, that the leaking threads are as well happening in gstreamer 1.0, even without the about-to-finish (which is the very race-condition now handled in this bug). To minimize confusion, I'll file that separately as 1.0.6 bug.
Ah yes, sorry. Let's keep this for the about-to-finish issue. Please file another bug about the threads leak you're seeing. I will mark the other bug as a duplicate of this.
*** Bug 698306 has been marked as a duplicate of this bug. ***
I suspect this could be related to bug 686153 , see my comment there. Henner, could you extend your test case by adding a second sound file that has a longer duration, then use a sequence of [short track, long track, long track, ...] for gapless playback? If this is the same bug, the first track should play correctly, the second track should start playing at the timestamp where the first track ended, and all the repeated long tracks should not play at all because they start at their end, causing repeated "about-to-finish" signals.
I just had some time to modify your test case to play a short file first, then a file with longer duration. And indeed, symptoms are the same as in bug 686153 . So this bug 698750 is actually a "special case" of 686153, with only one track in the sequence. See my results here: https://github.com/w-flo/gstreamer-gapless-test/blob/master/Results.md The modified test program is supposed to play the given sequence in order, then repeat the last track until canceled. However, only the first track is played correctly. The second track, when played for the first time, starts playing at the timestamp where the first track ended. The second time the second track is supposed to be played, there is no sound at all. Instead, "about-to-finish" signals are repeated about once a second, indicating that playback was actually started at the end of the track. On the other hand, even http:// URIs work fine and don't show any symptoms of this bug when used with *.mp3 files. Using a more complex tool (gnome-music) based on playbin and gstreamer-1.0, it appears like things are even a little more complicated: Using the seek_simple method of playbin during playback seems to influence the timestamp at which the next track starts playing. For example, seeking to a position 10 seconds before the end of the current track, the next track will start playback at 0:10. This seems to be independent of the length of the current track. These combinations are affected: HTTP / ogg, file / wav (according to bug 686153 ) These combinations are not affected: HTTP / mp3, file / mp3, file / ogg
Interesting - these findings indeed hint that it is probably due to _not_ resetting the stream-position; or some threading problem that does not do it in the right sequence. Looks like the bug is more and more surrounded :)
I have merged the additions Florian made to my sample code in https://github.com/hzeller/gstreamer-gapless-test Including sample *.wav and *.ogg files to demonstrate the bug. From the: https://github.com/hzeller/gstreamer-gapless-test/blob/master/README.md Does _not_ work: ./test-loop-1.0 http://localhost:9999/12.ogg http://localhost:9999/1234567.ogg ./test-loop-1.0 file://`pwd`/sounds/12.wav file://`pwd`/sounds/1234567.wav Does work: ./test-loop-1.0 http://localhost:9999/12.wav http://localhost:9999/1234567.wav ./test-loop-1.0 file://`pwd`/sounds/12.ogg file://`pwd`/sounds/1234567.ogg This is essentially the same problem described in bug 686153
Another data-point: file and HTTP url both seem to work with FLAC WAV OGG FLAC HTTP ok FAIL ok FILE FAIL ok ok (just added examples with FLAC in the example code)
Created attachment 244371 [details] FAILING invocation of ./test-loop-1.0 http://localhost:9999/12.ogg http://localhost:9999/1234567.ogg
Created attachment 244372 [details] SUCCESSFUL invocation of ./test-loop-1.0 http://localhost:9999/12.wav http://localhost:9999/1234567.wav
Added two GST_DEBUG=*:5 logs that illustrate the failing HTTP URI invocation with *.ogg and the successful uri invocation with *.wav.
This is a possibly unrelated observation: In the failing invocation log, line 60948 is > 0:00:02.047959784 15686 0x7fdaf8007590 DEBUG bin gstbin.c:3603:bin_query_duration_fold:<audiosink-actual-sink-pulse> got duration 0 In the successful log, line 29069 is > 0:00:02.830741835 15353 0x7f224006dd90 DEBUG bin gstbin.c:3603:bin_query_duration_fold:<audiosink-actual-sink-pulse> got duration 2666394558 Maybe the issue is a bad duration query result of 0? Note that the failing log has "got duration 1532517006" as well, so it's not always 0.
Is there more information you need for this one ? For my project [gmrender-resurrect], I can't really recommend any gstreamer version without problems to my users right now: 0.10 has bug #699794, that has been fixed in 1.0.8-git, but 1.0 has this bug, which makes it not usable for streaming certain formats.
Should be better with latest git master
Indeed, I couldn't reproduce the problem in the current git-head. Closing for now.