After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 355560 - [GnlFileSource] Switches before end of segment
[GnlFileSource] Switches before end of segment
Status: RESOLVED DUPLICATE of bug 575972
Product: GStreamer
Classification: Platform
Component: gnonlin
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
Edward Hervey
: 397634 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-09-12 10:57 UTC by Edward Hervey
Modified: 2009-03-19 15:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2006-09-12 10:57:17 UTC
GnlComposition relies on SEGMENT_DONE messages to know when to reconfigure the internal pipeline.

Their is a problem with GnlFileSource though, because of the queues it contains. What happens is that the demuxer emits GST_MESSAGE_SEGMENT_DONE before the decoders have actually decoded the whole segment.
Comment 1 Edward Hervey 2006-09-12 10:58:51 UTC
The choice here is:
_ either rely on a hack in GnlFileSource to cache the emitted messages and emit them when the queue emits 'underrun'
_ have decodebin cache segment-done and emit it once the queues are drained.
Comment 2 Edward Hervey 2007-01-17 14:56:01 UTC
*** Bug 397634 has been marked as a duplicate of this bug. ***
Comment 3 Laszlo Pandy 2007-02-07 00:15:53 UTC
I discovered in Jokosher that the audio will end just before the position marker reaches the end of the clip, making things look a few millimetres off (which is not very much). However I think this bug has a larger impact than just that. The more pieces of audio you have in a gnlcomposition, the farther off the time and audio become. 
Note: I have not confirmed if this is the same bug or a different one, but see my theory below.

What I think is happening is gnonlin is receiving the SEGMENT_DONE message before the end of the clip, and it thinks I has to be at the end, so it sets its internal time to the value of the "stop" property on the media in an attempt to reduce the error of the time it took the SEGMENT_DONE to be processed. This makes the gaps between pieces of audio the proper length, but also makes the clip playing time drift further from what it should be. The next clip will start a little early and end twice as early as the first. The more clips of audio there are, the more this small difference adds up, and the further apart everything the actual pipeline time if from the audio that is playing.

A few millimetres is not a big deal, but when multiplied by the number of clips it becomes a very large and noticeable number.
Comment 4 Mike Hogye 2007-05-20 14:09:25 UTC
Is there a workaround for this?
Comment 5 Mike Hogye 2007-05-24 17:39:47 UTC
This behavior seems to be affected, sometimes for better, sometimes for worse, by having the USE_DECODEBIN2 environment variable set.

I've been having the problem that my movie only plays a few seconds, even if I set the duration to a large number. With USE_DECODEBIN2, my movie plays for the desired duration.

However, with USE_DECODEBIN2 set, the test case from Bug 397634 doesn't play anything at all -- it just hangs.
Comment 6 Edward Hervey 2007-06-18 11:24:41 UTC
the workaround is to create your own pipelines that don't use queues and put that into a gnlsource.

FYI, there's a python based queue-less single-stream decodebin in pitivi that we use to workaround this issue. See pitivi/elements/singledecodebin.py
Comment 7 gareth foster 2007-08-08 12:01:36 UTC
Just wanted to add a me too on this bug, its stopping Jokosher being useful to me, which is a real shame because things were going well.

Can the priority not be upped a bit? Surely loads of people are having this issue?
Comment 8 gareth foster 2007-08-13 20:38:57 UTC
I'll sling a tenner on paypal as a bounty to anyone who sorts this out in the next week or two (provided it fixes the Jokosher bug that depends on it of course).
Comment 9 Edward Hervey 2009-03-19 15:22:25 UTC

*** This bug has been marked as a duplicate of 575972 ***