Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## [PiTiVi] Thoughts on Transitions

 [PiTiVi] Thoughts on Transitions From: Brandon Lewis - 2010-02-17 05:14:24 ```One way to think of transitions is as being defined by two clips A and B. Let's define the start of Transition(A, B) as B.start, and the duration as (A.end - B.start). A transition could be an object that observes A and B, updating the properties of the gnloperation and gst.Controller objects it owns when A and B change (I already have code which implements this). The question is, "when should Transition objects be created and destroyed?" Our notion of transitions implies that they can only exist when at least two clips "overlap" each other on the same layer (have equal priority), like this (here the clips are staggered for clarity): [AAAAAAAAA] [BBBBBBBBBBBB] |---Time---------------> Furthermore, Transition(A, B) is invalid (should not exist) in these situations: [AAAAAAAAA] [BBBB] [AAA] [BBBBBBBBBBB] Do we consider Transition(A, B) and Transition(B, A) to be the same transition? It will probably be simpler to implement if we think of transitions as "directional", and require that transitions always go from earliest to latest. Thus Transition(A, B) is not the same as Transition(B, A). So Transition(A, B) is invalid in the following case [but Transition(B, A) is valid]. [AAAAAAA] [BBBBBBBB] In other words, Transition(A, B) is valid (should exist) IFF * A.priority = B.priority, and * A.start < B.start < A.end < B.end So much for the case when there are exactly two clips to consider. If have three or more overlapping clips, there suddenly seem to be too many cases to consider. [AAAAAAA] [BBBBBBBB] [CCCCCC] [CCCCCC] [CCCCCCCCCC] [C] [CCCCCCCCCC] .... I would argue that we should add the restriction that a transition can only exist when exactly two clips overlap. Put another way, we should also consider Transition(A, B) invalid if there exists some clip C that intersects the area defined by Transition(A, B). The simplest approach for automatically managing transitions is just to do some house-keeping after any operation which adds, removes, or modifies at least one clip: * remove any existing transitions which have become invalid * create transitions for valid pairs which do not already have transitions In pseudocode: transitions = hashtable() procedure updateTransitions: for each A, B in transitions: if not valid(A, B): del transitions[A, B] for 0 < i < max_priority: for each A, B in getOverlapping(i): if not (A, B) in transitions: transitions[A, B] = Transition(A, B) The tricky part is defining valid(), because you need to check for clips which might intersect the region between A and B. Once you have valid() you can write getOverlapping(), which returns all the valid pairs at the given priority. I could develop this approach, but it doesn't lend itself to giving instantaneous feedback during interactive operations (i.e. showing when transitions are created or destroyed while the user is moving the mouse). I'm concerned that iterating over all transitions and track objects repeatedly will create lag in the U.I. Any ideas? Is the any of the gap prevention code relevant? ```

 [PiTiVi] Thoughts on Transitions From: Brandon Lewis - 2010-02-17 05:14:24 ```One way to think of transitions is as being defined by two clips A and B. Let's define the start of Transition(A, B) as B.start, and the duration as (A.end - B.start). A transition could be an object that observes A and B, updating the properties of the gnloperation and gst.Controller objects it owns when A and B change (I already have code which implements this). The question is, "when should Transition objects be created and destroyed?" Our notion of transitions implies that they can only exist when at least two clips "overlap" each other on the same layer (have equal priority), like this (here the clips are staggered for clarity): [AAAAAAAAA] [BBBBBBBBBBBB] |---Time---------------> Furthermore, Transition(A, B) is invalid (should not exist) in these situations: [AAAAAAAAA] [BBBB] [AAA] [BBBBBBBBBBB] Do we consider Transition(A, B) and Transition(B, A) to be the same transition? It will probably be simpler to implement if we think of transitions as "directional", and require that transitions always go from earliest to latest. Thus Transition(A, B) is not the same as Transition(B, A). So Transition(A, B) is invalid in the following case [but Transition(B, A) is valid]. [AAAAAAA] [BBBBBBBB] In other words, Transition(A, B) is valid (should exist) IFF * A.priority = B.priority, and * A.start < B.start < A.end < B.end So much for the case when there are exactly two clips to consider. If have three or more overlapping clips, there suddenly seem to be too many cases to consider. [AAAAAAA] [BBBBBBBB] [CCCCCC] [CCCCCC] [CCCCCCCCCC] [C] [CCCCCCCCCC] .... I would argue that we should add the restriction that a transition can only exist when exactly two clips overlap. Put another way, we should also consider Transition(A, B) invalid if there exists some clip C that intersects the area defined by Transition(A, B). The simplest approach for automatically managing transitions is just to do some house-keeping after any operation which adds, removes, or modifies at least one clip: * remove any existing transitions which have become invalid * create transitions for valid pairs which do not already have transitions In pseudocode: transitions = hashtable() procedure updateTransitions: for each A, B in transitions: if not valid(A, B): del transitions[A, B] for 0 < i < max_priority: for each A, B in getOverlapping(i): if not (A, B) in transitions: transitions[A, B] = Transition(A, B) The tricky part is defining valid(), because you need to check for clips which might intersect the region between A and B. Once you have valid() you can write getOverlapping(), which returns all the valid pairs at the given priority. I could develop this approach, but it doesn't lend itself to giving instantaneous feedback during interactive operations (i.e. showing when transitions are created or destroyed while the user is moving the mouse). I'm concerned that iterating over all transitions and track objects repeatedly will create lag in the U.I. Any ideas? Is the any of the gap prevention code relevant? ```
 Re: [PiTiVi] Thoughts on Transitions From: Alessandro Decina - 2010-02-17 10:23:36 ```On Wed, Feb 17, 2010 at 6:14 AM, Brandon Lewis wrote: > The question is, "when should Transition objects be created and > destroyed?" Our notion of transitions implies that they can only exist > when at least two clips "overlap" each other on the same layer (have > equal priority), like this (here the clips are staggered for clarity): > > [AAAAAAAAA] >     [BBBBBBBBBBBB] > |---Time---------------> Ok > Furthermore, Transition(A, B) is invalid (should not exist) in these > situations: > > [AAAAAAAAA] >   [BBBB] > >    [AAA] > [BBBBBBBBBBB] Ok > Do we consider Transition(A, B) and Transition(B, A) to be the same > transition? It will probably be simpler to implement if we think of > transitions as "directional", and require that transitions always go > from earliest to latest. Thus Transition(A, B) is not the same as > Transition(B, A). So Transition(A, B) is invalid in the following case > [but Transition(B, A) is valid]. > >      [AAAAAAA] > [BBBBBBBB] > > In other words, Transition(A, B) is valid (should exist) IFF > * A.priority = B.priority, and > * A.start < B.start < A.end < B.end > > So much for the case when there are exactly two clips to consider. If > have three or more overlapping clips, there suddenly seem to be too many > cases to consider. > > [AAAAAAA] >     [BBBBBBBB] >      [CCCCCC] > [CCCCCC] >  [CCCCCCCCCC] >      [C] >        [CCCCCCCCCC] > .... > > I would argue that we should add the restriction that a transition can > only exist when exactly two clips overlap. Put another way, we should > also consider Transition(A, B) invalid if there exists some clip C that > intersects the area defined by Transition(A, B). Agreed. Let's keep it simple for now. > The simplest approach for automatically managing transitions is just to > do some house-keeping after any operation which adds, removes, or > modifies at least one clip: [...] > The tricky part is defining valid(), because you need to check for clips > which might intersect the region between A and B. Once you have valid() > you can write getOverlapping(), which returns all the valid pairs at the > given priority. > > I could develop this approach, but it doesn't lend itself to giving > instantaneous feedback during interactive operations (i.e. showing when > transitions are created or destroyed while the user is moving the > mouse). I'm concerned that iterating over all transitions and track > objects repeatedly will create lag in the U.I. Any ideas? Is the any of > the gap prevention code relevant? Yes, in fact I think reusing the existing gap prevention code is the easiest solution. We already track overlapping clips having the same priority. At the moment when we detect overlaps (a gap has duration < 0), we rearrange clips so that they never overlap. MoveContext.finish() in pitivi/timeline/timeline.py uses the gap code and implements the logic to avoid gaps while moving clips. Take a look at that it's pretty simple. Ciao Alessandro ```
 Re: [PiTiVi] Thoughts on Transitions From: Jeff - 2010-02-17 13:16:32 Attachments: Message as HTML ``` > We already track overlapping clips having the same priority. At the > moment > when we detect overlaps (a gap has duration < 0), we rearrange clips > so that they never overlap. > > MoveContext.finish() in pitivi/timeline/timeline.py uses the gap code > and > implements the logic to avoid gaps while moving clips. Take a look at > that it's pretty simple. >From what I understand, this would mean that you wouldn't see the transition area appearing "live" while you drag the clips to overlap, only when you release the mouse button will it show. From a technical standpoint it makes sense and is probably much easier to implement. It's just that "ideally", in a perfect world, it would be nicer to be able to see the transition area form (or opacity keyframes move around into place) as you drag, however. I think this was what caused Brandon some headaches (detecting collisions "in real time" :) (demonstration in comment #1 of https://bugzilla.gnome.org/show_bug.cgi?id=579230 ) ```
 Re: [PiTiVi] Thoughts on Transitions From: Alessandro Decina - 2010-02-17 14:05:20 ```2010/2/17 Jeff : > >From what I understand, this would mean that you wouldn't see the > transition area appearing "live" while you drag the clips to overlap, only > when you release the mouse button will it show. From a technical standpoint > it makes sense and is probably much easier to implement. > > It's just that "ideally", in a perfect world, it would be nicer to be able > to see the transition area form (or opacity keyframes move around into > place) as you drag, however. I think this was what caused Brandon some > headaches (detecting collisions "in real time" :) We can move the code around to create transitions as you drag. We were already doing that to track gaps and overlapping clips at some point. I changed that since the way it works now felt nicer. Ciao Alessandro ```
 Re: [PiTiVi] Thoughts on Transitions From: Jay Dresser - 2010-02-18 06:25:19 Attachments: Message as HTML ```On Tuesday 16 February 2010 21:14:15 Brandon Lewis wrote: > > [AAAAAAAAA] > [BBBBBBBBBBBB] > ..... > Do we consider Transition(A, B) and Transition(B, A) to be the same > transition? It seems obvious that it cannot because B starts then A ends. Specifying Transition(B, A) would jump from A to B, transition B to A, then jump to B. However you may want to specify the start and end independent of the clip start/end. For example you may want to start the A->B transition a few seconds after the B starts, and/or end it before the end of A so you can align, and then specify the start/end of transition. ```
 Re: [PiTiVi] Thoughts on Transitions From: sam tygier - 2010-02-19 10:53:46 ```Brandon Lewis wrote: > One way to think of transitions is as being defined by two clips A and > B. Let's define the start of Transition(A, B) as B.start, and the > duration as (A.end - B.start). A transition could be an object that > observes A and B, updating the properties of the gnloperation and > gst.Controller objects it owns when A and B change (I already have code > which implements this). > > The question is, "when should Transition objects be created and > destroyed?" Our notion of transitions implies that they can only exist > when at least two clips "overlap" each other on the same layer (have > equal priority), like this (here the clips are staggered for clarity): > > [AAAAAAAAA] > [BBBBBBBBBBBB] > |---Time---------------> > why not require that transitions happen between clips on the same video layer --------- ------------ aaaaaaaa| |bbbbbbbbbbb --------- ------------ when you slide them into each other, they overlap ----------//------------ aaaaaaaa // bbbbbbbbbbbb --------//-------------- or _______________ ____________ _______| | aaaaaa | _________| bbbbbbbbbbb _______| |_____________________ Sam ```