GNOME Bugzilla – Bug 575972
[GnlComposition] Switch to using regular segment seeks instead of GST_SEEK_FLAG_SEGMENT
Last modified: 2009-09-21 09:49:23 UTC
Currently in GnlComposition, we rely entirely on GST_MESSAGE_SEGMENT_DONE to know when objects have finished processing the current segment. The problem is that we might have queues in the give objects/sources/operations after the element driving the pipeline (like a demuxer or a basesource element). This results in the composition receiving the message *before* that given source/operation has actually pushed out all the buffers/tags/events for that given segment. This effect is even worse with gnlfilesource (using decodebin(2) internally) to such a point that for some short files the message will be received before *any* buffers are outputted. The proposal is therefore to replace the seeks that GnlComposition is sending to the contained objects by: * *NOT* setting the GST_SEEK_FLAG_SEGMENT flag * putting even_probes on top-level source pads which, when they see EOS events, discard them and informs the composition * once all EOS have been received, call update_pipeline with the segment->start.
*** Bug 575961 has been marked as a duplicate of this bug. ***
*** Bug 355560 has been marked as a duplicate of this bug. ***
*** Bug 518010 has been marked as a duplicate of this bug. ***
Sweet. That explains why short audio files don't work well. (?) A workaround is to do it the same way Jokosher currently does. They have their own decodebin, which is queue-less. Have a look at http://bazaar.launchpad.net/~jokosher-code/jokosher/main/annotate/head%3A/Jokosher/elements//singledecodebin.py SingleDecodeBin can be used instead of gnlfilesource: ... #self.audio = gst.element_factory_make("gnlfilesource", "audio1") #self.audio.set_property("location", filename) self.audio = gst.element_factory_make("gnlsource", "audio1") caps = gst.caps_from_string("audio/x-raw-int;audio/x-raw-float") f = "file://" + filename self.single_decode_bin = SingleDecodeBin(caps=caps, uri=f) self.audio.add(self.single_decode_bin) # self.audio.set_property("start", long(0) * gst.SECOND) self.audio.set_property("duration", long(10) * gst.SECOND) self.audio.set_property("media-start", long(0) * gst.SECOND) self.audio.set_property("media-duration", long(10) * gst.SECOND) self.audio.set_property("priority", 0) self.composition.add(self.audio) ...
Yes, I know, check the author at the top of singledecodebin.py :) But... we shouldn't have to resort to such hacks. It makes it impossible to make simple usage of gnonlin in any applications (C?). Having sources without queues also causes problems in timelines with HD videos (or any computationaly intensive files), because we don't allow for any buffering before the files ARE played.
*** Bug 574276 has been marked as a duplicate of this bug. ***
*** Bug 449435 has been marked as a duplicate of this bug. ***
commit 8176747c4538b4d60d7ade9d2b52a24088b13064 Author: Edward Hervey <bilboed@bilboed.com> Date: Sat Mar 21 15:41:15 2009 +0100 GnlComposition: Switch to using regular segment seeks. Fixes #575972
Is this a problem in GnlFileSource too? I'm having seeking problems (Sending seek event failed! error msg), and see GST_SEEK_FLAG_SEGMENT is used there.
Ah, looks like I'm seeing bug #395054 except I don't have mp3parse installed, just flump3dec. Is it probably a bug in flump3dec then?
yes.