GNOME Bugzilla – Bug 637522
Not-negotiated errors when there are gaps in the timeline
Last modified: 2011-05-24 00:32:11 UTC
Created attachment 176671 [details] screencast Yeah. Method 1: 1. blank timeline, insert a clip at the beginning 2. split it in three 3. move part 3 to the right, creating a gap 2. (optional) move part 2 to the center, creating two gaps Method 2: - insert a clip in a blank timeline without inserting it at the beginning. Result: not negotiated errors and pitivi isn't able to do anything until restarted. See attached screencast.
Ugh. For some reason, I can't reproduce this bug (with the same clip) anymore, with either stock gstreamer version or gst-jhbuild.
Reopening as I can now reproduce this again with both stock gstreamer and gst jhbuild. I guess you just have to try with various clips.
I found out the tricky part to reproduce this: you *have* to set the project resolution to match the clips first (ex: 1280x720 @ 24fps for me) for the bug to happen. Otherwise (with incorrect project settings), you will not get any errors.
This is two sneaky bug variants in one: - Variant 1: when you create a blank project, set the project settings, import clips and create a gap. Hard to test because most of the time in emdash's project settings refactoring, you can't actually set the project settings manually - Variant 2: with pitivi head, create and save a blank project with correct resolution/framerate settings. Now, the steps to trigger the bugs are the same as in variant 1, the only difference is that instead of creating a blank project during the test procedure, you load this existing one. So 1) load project 2) insert clip in the timeline twice 3) create a gap between the two clips. The weird thing that makes this a "variant" of the bug is that it triggers the bug even on revisions where variant #1 can be tested (ie: you can set project settings) but where variant 1 does not trigger the bug... For example, 5d80c8c7a5a3c85f51f99b77ab6755476f3dabde triggers variant 2 but not variant 1. To make this easier to understand, I have screencasted the testing procedure for the two variants: http://jeff.ecchi.ca/public/pitivi-637522-variant1.ogv http://jeff.ecchi.ca/public/pitivi-637522-variant2.ogv Because those two variants behave kinda behave independently, I spent way too much time bisecting this. Here are my findings: - Variant 1 occured somewhere between 5d80c8c7a5a3c85f51f99b77ab6755476f3dabde (bad) and 1833a5f0fe77322cf44d417a4bfc78906b441bc5 (good). This is the merge of emdash's refactoring of project settings. I am unable to be more precise in pinpointing the location of the faulty commit, because the revisions between those two are not really possible to test (you can't open the project settings dialog!) - Variant 2 occured at commit 8dd8daba71d49c9487285cc457c56f96edd89a68 according to git bisect and my testing (the commit "right before it" works).
*** Bug 644828 has been marked as a duplicate of this bug. ***
Symptoms: until you restart pitivi, playback performance is completely destroyed and some UI elements may respond erraticly (or not at all).
commit 0cbfbf0d9fff7777ad599e1bf5763673afd3985d Author: Thibault Saunier <thibault.saunier@collabora.co.uk> Date: Tue May 17 21:19:23 2011 -0400 pitivi: Update the video caps of the default_source when project setting change This avoid lot of NNE introduced by different caps on VideoSources and VideoTestSource fixes #637522 and #613767
*** Bug 646951 has been marked as a duplicate of this bug. ***