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 609792 - segments in wrong order
segments in wrong order
Product: GStreamer
Classification: Platform
Component: gnonlin
git master
Other Linux
: Normal major
: 0.10.15
Assigned To: GStreamer Maintainers
Edward Hervey
Depends on:
Blocks: 641377
Reported: 2010-02-12 21:19 UTC by Jean-François Fortin Tam
Modified: 2011-02-03 17:23 UTC
See Also:
GNOME target: ---
GNOME version: ---

proposed fix (1.77 KB, patch)
2010-03-07 18:13 UTC, Alessandro Decina
committed Details | Review

Description Jean-François Fortin Tam 2010-02-12 21:19:27 UTC
As requested by slomo, here is a new bug report. The packages from the gstreamer developers PPA, combined with pitivi git, don't solve the bug where a black frame appears on some points where clips switch between each other or where there are transitions with videomixing (emdash also reported that this seems to occur with audio as well).

This only happens on render, not on live playback.
This can be seen in pitivi's previewer while rendering, as well as in the rendered file.

Here is a brand new sample pitivi project to easily reproduce it. Included is a screencast demonstrating the problem, and the rendered output file. Enjoy.
Comment 1 Sebastian Dröge (slomo) 2010-02-18 13:57:35 UTC
After adding some debug output to videomixer, this happens:

changing z-order (sink_1): 0 -> 0
changing z-order (sink_0): 10000 -> 10000
EOS (sink_0)
EOS (sink_1)
requesting (sink_2)
changing z-order (sink_0): 10000 -> 10000
changing z-order (sink_1): 0 -> 0
changing z-order (sink_2): 2 -> 9999
EOS (sink_0)
EOS (sink_2)
EOS (sink_1)
releasing (sink_0)
changing z-order (sink_2): 9999 -> 9999
changing z-order (sink_1): 0 -> 0
EOS (sink_2)
EOS (sink_1)

The black frame happens about the time where sink_2 is requested. Why are there 3 sinkpads used by pitivi?
Comment 2 Sebastian Dröge (slomo) 2010-02-19 05:17:18 UTC
Ok, so apparently pitivi plugs a videotestsrc here, which outputs black frames. This is causing the black frames because  at the time when the video stream goes EOS the first time there's still some duration left of the black stream, which then gets a black frame rendered.

Unfortunately this black stream is necessary to force videomixer to a constant framerate if using inputs with multiple framerates (as long as the black stream has the highest framerate). Was this the reason why you have it in pitivi, Brandon?

Anyway, the black stream should be removed from pitivi in any case. If problems arise because the downstream framerate changes the solution would be, to let videomixer choose the downstream framerate instead of always using the highest input framerate. This should be quite easy to implement.
Comment 3 Sebastian Dröge (slomo) 2010-02-19 12:03:40 UTC
Ok, so this is really a pitivi bug. A black frame source is definitely needed in exactly one case: when there are gaps between video streams. In that case one black frame more or less doesn't hurt. In other cases, if there's no black frame source, everything will work just fine.

Edward said, that this branch here implements this:

Some background, the problem here is, that at EOS the following situation happens: the video stream's last frame end timestamp is a bit before the videotestsrc's last frame end timestamp. Videomixer then first mixes those two buffers and afterwards pushes a short-duration black frame.

(Actually it's not end timestamps but accumulated durations but that shouldn't matter unless elements produce incorrect timestamps/durations)
Comment 4 Alessandro Decina 2010-02-28 21:56:03 UTC
I just landed a branch that should fix this.

Can you check again?
Comment 5 Sebastian Dröge (slomo) 2010-03-02 11:45:40 UTC
Well, there's no black frame flashing anymore when trying the example by Jean-François in comment #1 but instead the transition is completely broken :)

The second track is always completely opaque and the first track becomes transparent from the point where the second track starts. That's the theory and how it worked before.

With latest GIT the following happens: Second track plays, at the point where the two tracks overlap the first track becomes more and more transparent until it's invisible but a black background appears instead of the second stream. At the time where the first stream ends, the black background is immediately replaced by the second stream.
Comment 6 Alessandro Decina 2010-03-02 23:56:36 UTC
I had a look at this with pitivi git and gnonlin git.
It looks like we're hitting a gnonlin bug here now.

If you have two sources laid out like this:

[  source1  ]
[blank][  source2  ]

and in blank you _don't_ have a default source (which is what pitivi git does now), gnonlin will activate source2 only after the source1 segment, since it uses NEWSEGMENTS internally to track when to update the composition.
Comment 7 Alessandro Decina 2010-03-03 00:27:32 UTC
Edward what do you think about this?

index 218a566..4b3f9c1 100644
--- a/gnl/gnlcomposition.c
+++ b/gnl/gnlcomposition.c
@@ -1286,6 +1286,7 @@ get_stack_list (GnlComposition * comp, GstClockTime timestamp,
   GNode *ret = NULL;
   GstClockTime nstart = GST_CLOCK_TIME_NONE;
   GstClockTime nstop = GST_CLOCK_TIME_NONE;
+  GstClockTime first_out_of_stack = GST_CLOCK_TIME_NONE;
   guint32 highest = 0;
@@ -1314,6 +1315,7 @@ get_stack_list (GnlComposition * comp, GstClockTime timestamp,
     } else {
       GST_LOG_OBJECT (comp, "too far, stopping iteration");
+      first_out_of_stack = object->start;
@@ -1330,6 +1332,8 @@ get_stack_list (GnlComposition * comp, GstClockTime timestamp,
   /* convert that list to a stack */
   tmp = stack;
   ret = convert_list_to_tree (&tmp, &nstart, &nstop, &highest);
+  if (GST_CLOCK_TIME_IS_VALID (first_out_of_stack) && nstop > first_out_of_stack)
+    nstop = first_out_of_stack;
   GST_DEBUG ("nstart:%" GST_TIME_FORMAT ", nstop:%" GST_TIME_FORMAT,
       GST_TIME_ARGS (nstart), GST_TIME_ARGS (nstop));
Comment 8 Edward Hervey 2010-03-07 18:09:27 UTC
Re-assigning to gnonlin. Alessandro, can you attach a git patch here ?
Comment 9 Alessandro Decina 2010-03-07 18:13:37 UTC
Created attachment 155488 [details] [review]
proposed fix
Comment 10 Edward Hervey 2010-03-07 18:26:58 UTC
commit c0ca78c23c7ee1e53e01322727d4b007e2567651
Author: Edward Hervey <>
Date:   Sun Mar 7 19:23:46 2010 +0100

    tests: Adjust simple test for slight behaviour change introduced in last commit

commit ef35533b74ab9aae5776cb0c685efa9c029578c1
Author: Edward Hervey <>
Date:   Sun Mar 7 19:24:17 2010 +0100

    tests: Add a new test for checking fix introduce by last commit.

commit 13019676ac7514cc60f014e275a8be7b2bcb5d9d
Author: Alessandro Decina <>
Date:   Sun Mar 7 19:12:07 2010 +0100

    gnlcomposition: fix a bug figuring out the segments.
    If we have two sources (with no default sources) laid out like this:
        [  source1         ]
                   [   source2   ]
    We need to configure 3 different segments and therefore build 3 different
    stacks. One in which only source1 is active, one in which both source1 and
    source2 are active and finally one in which only source2 is active.
Comment 11 Jean-François Fortin Tam 2010-03-19 01:45:22 UTC
Sigh. I still see this kind of bug with pitivi git (with the transitions branch merged in master), the packages from the PPA on jaunty, etc.
Comment 12 Edward Hervey 2010-05-31 14:35:33 UTC
Jeff, do you still see this issue ?
Comment 13 Jean-François Fortin Tam 2010-06-18 01:23:23 UTC
Well, yes and no: now the transition doesn't work at all anymore (pitivi git, gst ppa, etc.). It just lags and hardcuts to the other clip, but I guess once the transitions start functioning again, this bug would resurface as well.
Comment 14 Edward Hervey 2010-09-06 14:46:09 UTC
Closing bug. If issue surfaces again, please open a bug in pitivi.