GNOME Bugzilla – Bug 612717
Experiencing gaps in unrelated playbacks when starting a new playback, or even using playbin2's "gapless" playback with about_to_finish
Last modified: 2010-03-15 08:58:31 UTC
Easiest way to reproduce would be to 1. Have one video playing with GStreamer, using e.g. playbin or playbin2. 2. Set an unrelated (audio or video) playbin2 (or playbin1) to playing state from another state, whether it's been played back previously, stopped in between, or none of the previous. The video will momentarily stop. With audio, it's a short gap, but in case of the new file being played back being huge, it may be longer. Otherwise the videos and audio files play nicely together without disturbing eachother. The gap might be related to the creation of a new thread instead of just the switch to "playing" state, which I deduce from the following: I tried to have a video playing (without sound) and then starting so called "gapless" playback of audio files with playbin2, so that the about_to_finish signal would launch a new URI. With 0.10.28 there was no state switch, but there *WAS* a visible gap induced in the unrelated video playback. I don't know if there is a gap also in the audio, because the first file happened to be completely silent. The behavior is not related to the whole program being locked in some kind of I/O operation, because otherwise the program doesn't experience any delays - everything happens in gstreamer's own threads. Also I would like to note that it doesn't matter how many videos or similar you have playing. They *all* will experience a gap whenever a new playback is started.
Uhm... can be probably closed. After writing this I found out the "idle" function processing the frames is not called at all during playback start, possibly because new threads are created and the glib or whatever main loop never goes idle.
So, for anyone experiencing a similar issue, force checking if new buffers have arrived instead of using "g_idle_add_full(G_PRIORITY_HIGH_IDLE, ...)" or so.
So this is a bug in the application then? GStreamer doesn't make use of the GLib main loop or any timeouts/idle callbacks in there. Bug #602437 might also be interesting here.
Bug in the application indeed. The glib loop is just used in many examples, I didn't even consider it wasn't necessary to iterate. I thought there was some part of gstreamer living in the "main" thread as well. And why would starting a new playback delay the idle calls... maybe some shared resources? Still good to know this isn't the case, because I had no other use for the glib main loop. However there was some memory bug caused by using the about_to_finish callback to set a new URI, e.g. it caused random memory corruption. I'm not sure if it was my code or something with playbin2. Just thought it would be good to mention. The crashes appeared when making calls from the bus' state switch callback, at a random spot in otherwise working code. Identical state change handling code has worked fine without the about_to_finish, and the URI was changed successfully on the fly, without an intermediate state switch. Anyway probably just a bug in my code. I have no need for the about_to_finish now that playback starting doesn't cause gaps elsewhere. I just used it to test whether it would cause gaps in other playbacks as well... Oh BTW, I think using the same URI twice in a row did cause some problem (crash?) as well, which could be dangerous. I can test this again some time in the future, though right now I'm busy with other stuff.
Just a thought: Maybe looping could be implemented by setting the same URI again ;-)
Ok, let's close this bug then. For any other problems please file separate bugs, one per problem. For crashers please also attach the backtraces for the crash.