>So, basically you are suggesting classical
>timeline editing with addition of hierarchial
>grouping of video fragments and transition
>effects?
I guess so. I don't know all the video-editing
terminology yet. :-)
Being able to treat video production as a bunch of
independent but combinable parts, in my mind,
allows for a lot of the touch-and-go that it takes
to produce a video in the real world. For
instance, most scenes are shot several times.
Each take should be easily inserted and removed,
so that they can be viewed together with takes of
other scenes, and otherwise strongly support the
desire of the director to futz around with it
until it comes out feeling right. Also, being
able to store various versions of the same video
in one source file, i.e. different top-level
mixes of the same pieces, allow directors to
contemplate different versions of the video more
easily. Or say that a better method has been
found for preprocessing some piece of raw video.
It should be possible to make those changes, and
allow the effects to bubble up through a hierarchy
that describes how the video is to be made.
Basically, I'm not sure how I would live without
this sort of hierarchical composition of
independent pieces. It sounds like it would be
tedious and error-prone. I've already edited
three short movies with lavmix, and the ability to
make small changes and rebuild the movie was a
godsend to the editing phase.
>>Attached to this e-mail is an example
>>script-file for a tool I wrote about two years
>>ago.
>
>It looks like Kino's SMIL on steroids.. Except
>for that it isn't SMIL format. :)
I hadn't heard of SMIL format when I wrote lavmix.
I had heard *of* XML, but never looked into it.
>>But it's text-file based
>
>Writing scripts (and GUI's to those scripts) to
>manipulate SMIL files and do complex video
>editing on DV files is a lot easier than adding
>those features to Kino.
That's a really good point! Maybe I'll flesh out
lavmix as a command-line tool, with an XML/SMIL
source format, then turn to writing a GUI. That
gets everyone using it as early as possible, and
any major architectural flaws and limitations will
be found before tons of time is invested in a GUI.
Plus, I'll be able to release this a lot earlier
than I thought!
(Though first, I'll probably implement some
long-planned improvements to y4mdenoise. I think
I can seriously increase the quality and
performance again.)
>So, are you planning to create an alternative to
>Kino?
There are several open-source video-editing
projects out there. Off the top of my head, I
know of lvs (Linux Video Studio, part of the
mjpegtools family as far as I know), kino,
cinelerra, and hvirtual. I'm sure there are more.
Their suitability for what I want to do probably
mostly depends on whether the programmers
commented their source code and wrote design
documentation and so on. I'm sick of slogging
through non-documented code, and if they're all
like that, I'll probably write my own from
scratch.
Steven Boswell
ulatekh at yahoo dot com
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
