GNOME Bugzilla – Bug 609792
segments in wrong order
Last modified: 2011-02-03 17:23:57 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. http://jeff.ecchi.ca/public/pitivi-transition-black-frame.tar
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?
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.
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: http://github.com/emdash/pitivi/tree/default_sources 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)
I just landed a branch that should fix this. Can you check again?
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.
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.
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; GST_DEBUG_OBJECT (comp, @@ -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; break; } } @@ -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));
Re-assigning to gnonlin. Alessandro, can you attach a git patch here ?
Created attachment 155488 [details] [review] proposed fix
commit c0ca78c23c7ee1e53e01322727d4b007e2567651 Author: Edward Hervey <bilboed@bilboed.com> 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 <bilboed@bilboed.com> 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 <alessandro.d@gmail.com> 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. https://bugzilla.gnome.org/show_bug.cgi?id=609792
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.
Jeff, do you still see this issue ?
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.
Closing bug. If issue surfaces again, please open a bug in pitivi.