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 637522 - Not-negotiated errors when there are gaps in the timeline
Not-negotiated errors when there are gaps in the timeline
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: Timeline
Git
Other Linux
: Normal blocker
: 0.14
Assigned To: Pitivi maintainers
Pitivi maintainers
: 644828 646951 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-12-18 18:03 UTC by Jean-François Fortin Tam
Modified: 2011-05-24 00:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screencast (530.36 KB, video/ogg)
2010-12-18 18:03 UTC, Jean-François Fortin Tam
Details

Description Jean-François Fortin Tam 2010-12-18 18:03:45 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.
Comment 1 Jean-François Fortin Tam 2011-01-23 20:30:03 UTC
Ugh. For some reason, I can't reproduce this bug (with the same clip) anymore, with either stock gstreamer version or gst-jhbuild.
Comment 2 Jean-François Fortin Tam 2011-02-09 15:26:38 UTC
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.
Comment 3 Jean-François Fortin Tam 2011-02-10 15:07:22 UTC
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.
Comment 4 Jean-François Fortin Tam 2011-02-10 16:56:00 UTC
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).
Comment 5 Jean-François Fortin Tam 2011-03-18 15:39:07 UTC
*** Bug 644828 has been marked as a duplicate of this bug. ***
Comment 6 Jean-François Fortin Tam 2011-03-28 02:38:27 UTC
Symptoms: until you restart pitivi, playback performance is completely destroyed and some UI elements may respond erraticly (or not at all).
Comment 7 Thibault Saunier 2011-05-22 23:01:25 UTC
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
Comment 8 Jean-François Fortin Tam 2011-05-24 00:32:11 UTC
*** Bug 646951 has been marked as a duplicate of this bug. ***