GNOME Bugzilla – Bug 753575
python gapless playback not functioning properly
Last modified: 2018-01-25 13:28:51 UTC
I've posted a gist on github that contains 4 test files, and python code that demonstrates the problem. https://gist.github.com/virtuald/0aa9f7e30ed82c0270de On GST 1.4.5, track4.mp3 stalls for ~10s or so without playing, but there is no audio for track3 or track4. Other tests I've conducted track3 does have audio, but there is still a pause. On GST 1.5.2, there is no volume for track3.mp3 or track4.mp3, but no stall occurs... so it's been partially fixed? I didn't realize that gst-play existed (neat), but I found it and tried it out: gst-play-1.0 --gapless track1.flac track2.flac track3.mp3 track4.mp3 And it works just fine. So... just a problem with python bindings, or is my code wrong? I glanced through gst-play, and there doesn't seem to be anything particularly different about what it's doing. Connects to 'about-to-finish', and sets the URI. I've attached the debug log. The debug log was taken *removing* the seek from the middle, which isn't necessary to demonstrate the no-audio condition on 1.5.2. No audio starts probably about 10s in.. This bug was originally reported on Exaile's bug tracker at https://github.com/exaile/exaile/issues/41
Created attachment 309191 [details] gzipped debug log
Dustin, have you find any solution on this? I also got ~10s or so pause on my test python program with "about-to-finish" signal. Tested the same videos with gst-play-1.0 --gapless, and it's working fine. I'm using python 2.7, GObject Introspection (pygobject3-base-3.14.0). GStreamer version 1.6.0
I just tested that and with 1.6.3 your testcase 'works' problem is when we transition between mp3 samples where I can here a 'bop', that same issue happens with gst-play.
(In reply to Jason Kim from comment #2) > Dustin, have you find any solution on this? > > I also got ~10s or so pause on my test python program with "about-to-finish" > signal. Tested the same videos with gst-play-1.0 --gapless, and it's > working fine. > > I'm using python 2.7, GObject Introspection (pygobject3-base-3.14.0). > GStreamer version 1.6.0 I dug further and realized that "about-to-finish" was emitted multiple times. I'm guessing multiple streams(audio and video) are related to this. Based on my testing, *video-only* uri emitted "about-to-finish" twice, and normal video with audio stream emitted the signal four times. Is it possible the signal was emitted only once, but the callback was called multiple times ? Anyway, I think I can handle this by counting the number of streams of the current uri and set the next uri after multiple "about-to-finish" callbacks.. :) Anyone has better idea???
possibly related to bug #722769 then.
The signal should definitely be only emitted once per stream (and not once for audio, once for video, once for each subtitle stream, ...). Is this still a problem with latest GIT master?
Since the first "about-to-finish" signal was emitted too early, I was trying to set uri on the second signal to avoid the long pause, but it didn't work as I hoped.. Should uri be set on the first "about-to-finish" signal? Does anyone know why there is long time gap between the first and the second signal?
There should only be a single about-to-finish
(In reply to Sebastian Dröge (slomo) from comment #8) > There should only be a single about-to-finish Thanks for the clarification. Will try the newer version.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!