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
***************************************************************
