[Kdenlive-devel] transitions

[Rolf Dubitzky]

On Tuesday 20 May 2003 00:48, Jason Wood wrote:
> On Monday 19 May 2003 2:25 pm, Rolf Dubitzky wrote:
> > > Video/Audio (like we currently do) to simplify the timeline. However in
> > > this case, I would assume that the transition of sound and video would
> > > be linked together?
> >
> > linked yes, but they will still be different things. for any transition
> > between tracks you will have to specify a video and an audio transition.
> > Of course tere can be some 'default' audio transition connected to any
> > given video transition, but still there will be two objects connected to
> > a transition, one audio, one video.
>
> Ok, I see what you mean. I am wondering though, if this is more a case of
> prioritising having separate video/audio tracks? At the point where you
> want to perform different transitions on video and audio, I wonder if it is
> less confusing to treat them separately.
>
> Either way, I think the two transitions would be "merged" into one for the
> timeline, and treated as a super video-audio transition in which you can
> change the two transitions in the same way that you can change video/audio
> codecs separately.
>
> > Anoter thing is, even if you treat audio separet from video, the two
> > tracks should still be locked (at least per default) so that if you move
> > the audio part, the video gets moved synchronously.
>
> Of course :-) though there should also be the option to unlock them so that
> you can use them asynchronously ;-)
>
> > > I think that one addition that should be made to the transition picture
> > > is that there should not necessarily be only a single variable that
> > > changes within a transition - if we assume an audio/visual track for
> > > the moment, and a crossfade transition, video could have it's own
> > > crossfade 'red line', and audio could have it's own crossfade line.
> >
> > sure. in the separate dialog you can handle as many variables as you
> > want, and there will be probably not only variables of type "double",
> > which can be visualized as a "red line", but also of type "Color",
> > "Point", "Box", etc....
>
> You know, I'm itching to write the colour keyframe widget/track, but
> there's so much other stuff that needs to be done first :-)
>
> > I have started to add some new features to piave targeting this stuff and
> > have already commited them in the last weeks/days. Since they break VEML
> > compatibility with kdenlive I opened a new CVS-branch "V00-03-devel"
> > which will eventually become piave 0.3.0 . To handle effects and
> > transitions we'll have to modify VEML just a little. piave doesn't really
> > work right now, but there is a new subdirectory 'examples' where you can
> > see two VEML files. I think I'll get te examples working in the next
> > weeks. Concider the 'V00-03-devel' branch as 'unstable' and the CVS HEAD
> > as the 'stable' branch.
>
> Cool, keep me informed :-)

Ok, the following example works. 
(except: 
 - 'size' is not yet dynamic, 
 - width,heigth are meaningless at the moment, 
 - effect in/outpoint are ignored)
 - keyframe time is not relative between 0.0-1.0, but absolut localtime
 - the overlayed bitmaps are rgb while the video is yuv, gives funny effects
)

<veml>
    <scenelist>
        <scene duration="2" >
            <effect tracks="1">
                <inputs>
                    <input file="../samples/4x3-PAL.dv" inpoint="0" />
                </inputs>
                <video effect="textmaster" inpoint="0.5" outpoint="1.5">
                    <dtext>Some test AV ??</dtext>
		    <font>/mnt/win/windows/Fonts/spacetoa.ttf</font>
		    <size>
			<keyframe time="0.0">0.06</keyframe>
                    </size>
                    <position>
 		        <keyframe time="0.0" x="0.0" y="0.1" width="0.8" height="0.2"/>
 			<keyframe time="1.0" x="0.1" y="0.1" width="0.8" height="0.2" />
 			<keyframe time="2.0" x="0.3" y="0.6" width="0.8" height="0.2" />
                    </position>
                </video>
            </effect>
        </scene>
    </scenelist>
</veml>


> My own plan of action is to finish polishing the
> current timeline functionality, adding more keyboard shortcuts (including
> menu options), finishing implementing inpoints/outpoints, and at the moment
> I am reworking the snap-to-grid functionality so that it applies to all
> tools - you may have noticed that resizing did not snap to clip borders,
> nor did razoring, etc. This is what I am fixing.

Great, thats an important thing

> After that, I was actually going to look at piave and see if I can get
> import/export of sequences of images working and exposed to kdenlive, which
> will probably involve some work on the import/export dialogs.

Great.

> I still think that we need a couple of formats, just to prove that piave is
> capable of it :-) As I say, I'll take a look once I am happy with the state
> of the Gui - about a month away, then - and get up to speed so that I can
> discuss the finer workings of piave with you ;-)

Sounds great. I looked at enix again, and maybe things are in a much better 
shape than I though ;-)

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky          http://hep.phy.tu-dresden.de/~dubitzky
 e-mail:         Rolf.Dubitzky at Physik dot TU-Dresden dot de
***************************************************************