Building professional video editor using AviSynth?

[squadjot]

Hi, has anybody build a vegas/premire like frontend for AviSynth.

Is it possible?

(i personally like doing advanced GUI stuff, so if anybody is up..i'm in)

[Adub]

Several projects have started and stopped, but nothing has been completed. Just run a search and you should find a few things here and there.

[TheFluff]

There are a lot of vaporware ones, like that particularly entertaining Celluloid project from a while back. There have been other tries but every single one of them has ended in oblivion with many pretty interface mockups and few lines of actual code.

[squadjot]

Oke, nice to know..

I'm very green when coming to AviSynth, but i like it alot already.

The two things i would like to do first, would be the multitrack look/feel from vegas so u can easily trim/fade/transition/position video and sound.

Also the crop/pan features from vegas.. where u can either drag handles, or type numeric values, + use shortcuts to "fit to scene..", "reset size..." etc

The most difficult thing i can think of..would be to have an application with an internal video player.. i don't have a clue how to do that. Sofar i would have to write single images to display video = no realtime playback =/ , maybe not a big issue.. just.. it's not very cool to have a video editor that cannot playback in-gui imo.

[mikeytown2]

I'm also slightly interested in something like this. The closest thing we have ATM is AvsP (http://avisynth.org/qwerpoi/). What's needed is a generalized way to edit only certain parts of the video. Right now, its a jumble of Trims() (http://avisynth.org/mediawiki/Trim); if a simplified way of applying filters to certain parts of the clip can be done, then making a gui all of a sudden becomes a lot easier. In terms of size/crop I made a script that makes this "brain-dead": ZoomBox() (http://forum.doom9.org/showthread.php?p=1111789#post1111789).

[vlada]

Avidemux has an Avisynth input proxy that works quite nice and it is fast too. So it should be possible to play video in GUI. I'm working on an Avisynth based application in Python, which is to slow to be usable as a video editor. But if you go with C and GTK+, it should work.

[mikeytown2]

I would probably use http://avisynth.org/stickboy/ JDL_ApplyRange to apply filters to a range. Keeping things organized IMHO is one of the hardest things to do; this should help a little bit.

[mikeytown2]

Also having an order of operations... tweeks, fades, trims OR tweeks, trims, fades; and enforcing this throughout the entire editing process is another hard problem to solve. Too often people work on the GUI part first, and then they get stuck because there is no framework/classifications of how to apply the various filters; generalizing the scripting is still the hard part IMHO.

[JonE]

This is something I've been working on in the background. But as "TheFluff" has said, all such attempts have previously failed, and I suspect I'll be in that category too. However, at least I'm hoping some useful libraries will come out of it.

To put together a worthwhile GUI requires an aweful lot of upfront work and a clear idea from the start of exactly what you are / are not going to implement. There is no way a GUI can be as flexible as an AviSynth script, the best that could be hoped for is something that did the more routine stuff, perhaps an entry point for the less techy who, if interested, could go on to learn from the scripts that the GUI would generate.

@squadjot, re the internal video player, check out the DirectShowLib on SourceForge, it includes simple player samples. If you let Windows choose the playback components, a video player is but a few lines of code (in theory, with simple files and no dratted codec packs).

TTFN,
Jon

[tin3tin]

Maybe the time would be better spend by improving the avisynth integration in existing gui's. Like Blender which can import Avisynth with this build: http://graphicall.org/builds/builds/showbuild.php?action=show&id=751
And this solution improves the import af HDV and AVC in Blender: http://www.openfilmmaking.com/wiki/index.php?title=BlenderAVC

And two Linux NLE with very nice GUIs to keep an eye out for(no Window ports yet): KDEnlive (http://www.kdenlive.org/) and OpenShot (http://www.openshotvideo.com/).

[Sagekilla]

Here's an idea: A node based GUI with a video preview ;) I think something like graphedit but for avisynth would actually work pretty nicely. Just open a source video, connect some filters to your source node, click and adjust the filter nodes and see how it changes.

Of course, just an idea. If I actually had the GUI experience I could -try- doing something but I have no knowledge of the GUI APIs available.

[JonE]

Maybe the time would be better spend by improving the avisynth integration in existing gui's.

Depends on the motivation. I'm migrating / re-structuring my existing C++ DirectShow libs to .NET, need a platform to tinker with some GUI stuff, to say nothing of getting to find out just what _can_ be done with AviSynth that would lend itself to GUI-isation. Its not like I want to write an editor, rather I've a whole pile of coding related things I want to look up and an editor just happens to fill the brief. Personally, I'm quite happy with AviSynth text files as far as processing my videos is concerned.

...I think something like graphedit but for avisynth...

An interesting idea, but you can't represent timeline information that way.

TTFN,
Jon

[tin3tin]

...I think something like graphedit but for avisynth...
A previous attempt to something like that: http://avisynth.org/vion11/aveguide.html

@ JonE - Looking forward to see where you're heading. :)

A timeline GUI add on to AvsP would be übercool(but that's python and wxpython).

[squadjot]

Nice info..

The main reason i wanted to make such editor is that sometimes you need to pan around, zoom in/out in video, these operations would be hard to do by handwriting a avs script. An editor like Vegas's simply gives more creative freedom imo. Another reason: I really dig opensource/freewares like AviSynth and all the other amazing projects out there.. but most of them requires you to be an "computer-expert" to use them, atleast thats how it seems to totally normal people that just want to be creative with video. No such editor exists (free)..so why not contribute to build one.

!!! Ouch, the last thing that just came to think of is that in vegas..you can keyframe your panning/positioning.. and the app will automatically tween* between the keyframes

*tween - word used in flash..when you make two keyframs and the program automatically animates in between. hence the word.

That particular feature is imo very important, but i'm not sure how easy it would be to get AviSynth to do something like that, but i guess if you just feed AviSynth with the correct x/y/xscale/yscale/offset -values, then it should be possible, unless someone build a AviSynth plugin that can do that for me?

-

For GUI i'm using Flash wrapped in an executeable. It can do all the filehandling, com/dll communication etc etc. Anyways..for gui, flash offers all the things i need, and know.. cause flash/design/scripting is really what i do most.
I'm quite confident that the GUI part can be as advanced as i want.. there's no limits as i make it all from scratch, as i want. =)

[squadjot]

Oh my, the waveform preview of the sound... a thing that would require some coding/sound knowledge.
Drawing a scaleable vector representation is not the biggie, the problem, for me, would be getting the "2d"-values so i can draw it correctly.

edit: it's important imo, again to support the visual idea of you can "see" the sound.. so u know where to make the right cuts/effects compared to the soundtrack.

[Gavino]

sometimes you need to pan around, zoom in/out in video, these operations would be hard to do by handwriting a avs script.
Check out mikeytown2's Ken Burns Effect (http://forum.doom9.org/showthread.php?t=135776). Certainly, a GUI to set the parameters would be a nice addition, but the operations are there.

As for visualising the sound track, see AudioGraph (http://avisynth.org.ru/docs/english/externalfilters/audiograph.htm).

[Sagekilla]

An interesting idea, but you can't represent timeline information that way.


A node based GUI with a video preview

;) It would still be possible to use timeline information. For a timeline, you can have it so you can just select a snippet of video, and apply video effects to that snippet.

e.g, a new timeline would pop up for every Source() filter you use, and something to the effect of JDL_ApplyRange() (though not quite) would handle filtering for sections of your timeline.

[squadjot]

Check out mikeytown2's Ken Burns Effect (http://forum.doom9.org/showthread.php?t=135776). Certainly, a GUI to set the parameters would be a nice addition, but the operations are there.

At a glance it seems like being it!.. alltho i don't have a clue how to use it :D .. hopefully i dont have to look too much into that...depends on what happens.

As for visualising the sound track, see AudioGraph (http://avisynth.org.ru/docs/english/externalfilters/audiograph.htm).
Nice, but i'm not sure how i would implement it.. sounds like it has to run dynamic.. i was expecting to use somekind of tool that could convert the wav data to numbers..left/right, then i would use those values to draw a static vector from that. Ofcourse it should reload after sound/volume changes..so it always represents the "edited" sound. The thing of me..is how to correctly interpretate the values..so it's an exact representation of the sound compared to the video in time.

[mikeytown2]

At a glance it seems like being it!.. alltho i don't have a clue how to use it :D

I'm willing to do a walk through on this forum on how to use it; once your get the hang of it, it's quite handy :cool:

[squadjot]

I'm willing to do a walk through on this forum on how to use it; once your get the hang of it, it's quite handy :cool:

Apreciate it! , Depending on how this project works out i'll get back when i'm surtain your help is not wasted =)

[Gavino]

a new timeline would pop up for every Source() filter you use, and something to the effect of JDL_ApplyRange() (though not quite) would handle filtering for sections of your timeline.
In a NLE, you generally have clips from multiple sources assembled on the timeline (or on a given timeline track), not a separate timeline for each source.

And although a timeline can be represented as a filter graph consisting of trims and splices, that's not a very natural way of viewing a timeline for most people. So I see the filtergraph editor approach as a neat idea, but an entirely different project.

[squadjot]

In a NLE, you generally have clips from multiple sources assembled on the timeline (or on a given timeline track), not a separate timeline for each source.

The editor must support multiple timelines, nad offcourse it should be possible to have two sources on the same timeline, it should be up to the user. Only sound and video cannot be on the same timeline. timelines as in layers.

[tin3tin]

I think that the first big step would be an EDL (http://en.wikipedia.org/wiki/Edit_decision_list) parser/import/export plugin for Avisynth. For an easy conversion of a timeline GUI into an editied film, for easier working with proxies, and easy import/export to other editing apps.

Previously the has been an unfinished attempt to write an EDL parser in Avisynth script here (http://forum.doom9.org/showthread.php?t=95903&highlight=edl).

And Mug Funky did this fine scene change to EDL scripthere (http://forum.doom9.org/showthread.php?t=145143&highlight=edl).

Maybe an EDL is just another intermediate element like an avisynth script - and will be parsed(as a c++ plugin) at the same speed as an avisynth script? I wonder what are the devs thoughts on this?

One could say about the EDL format that it's very limited compared to avisynth script, but if the actual clips adressed in the EDL are avisynth scripts instead of ex. avi it would be possible to get the best of both worlds(editing & processing).

[JonE]

On the subject of timelines, I think normal linear timelines as used in the editors I've seen, isn't enough.

Rather I see timelines-within-timelines. Not sure how to describe it, but imagine a rectangle on one timeline that can expand into its own internal timelines (which in themselves could be further subdivided).

Although I like VideoStudio, like many editors I found if say I had three videos, one on each timeline, and all ending at the same point in time, I couldn't do a transition into a following fourth video - the transition would only apply to one of teh group of three initial videos. By combining the three videos into their own block, they can then all appear apparently on a single timeline and hence transitioning would apply to all of the videos in that block (is this making sense ?).

A consequence of this is that once happy that a block is good enough for now, you could create a low(ish) quality preview render for that block and the preview is then used when rendering the overal project during the editing phase. This could significantly improve both the time taken to render a script and make the script run quicker i.e. better chance of being able to play in real time.

The trick is to make this all easilly manageable by the user, which could be managed by wizards for various effects such as picture-in-picture - newbie users wont need to delve into how the effect is done, but "power users" (I hate that term) can delve into the details and tweak 'em.

TTFN,
Jon

[smok3]

JonE, sure, the problem is how to handle the history, like
- what happens if the block/sub-timeline length changes?

I think the project itself would be, how the video editor should work/behave/look like...., i we seen a lot of good ideas (or parts of them) over the years, but none is really perfect. If you do some searches over this forum, you will see that some can't even grasp the dual (player/recorder) concept..., well vegas took 9 versions to buy that as well :) http://www.sonycreativesoftware.com/vegaspro

the output notes;
So the final result is what? avisynth script? media? 'direct' frameserve?
how would i encode the final result to DVD with chapters?
what type of metadata/chapter data/edl data will be available to export?
... willl add more later

[vlada]

the output notes;
So the final result is what? avisynth script? media? 'direct' frameserve?
how would i encode the final result to DVD with chapters?
what type of metadata/chapter data/edl data will be available to export?
... willl add more later

I think this is the easy part. The output might be Avisynth script, but you can easily use XviD, x264 or other free coders to convert the video to convert the video to olmost any format.

I think the difficult part is to create a GUI which can play Avisynth scripts smoothly. Another big problem is to create a system, which converts a timeline to the actual script. But it should be doable to. I have thought about it a lot because I also had the plan to create a NLE editor based on Avisynth. If somebody's interested in my ideas, I will be glad to share them.

[JonE]

JonE, sure, the problem is how to handle the history, like - what happens if the block/sub-timeline length changes?

Ahead of you there. One thing that bugged me with VideoStudio was that if I changed the length of an item on the main timeline then other timelines didn't change - so all those subtitles, other overlays, etc, were now misaligned.

So, the logic is to move all objects on the same timeline as the block according to how the block length changed and shift all items that started after the start of teh original block forward. When shortening, this could result in a conflict - something on another timeline overlapping something else on teh same timeline, in which case the user will need to be presented with options to reolve it.

So the final result is what? avisynth script? media? 'direct' frameserve?

Just the AVISynth script plus a way of producing an archive of all material needed to re-create the project, plus support to encode via Ffmpeg (so that base users don't even need to realise there is a script). Small set of preset output options provided as standard (DV, MPEG2, MPEG4) but user can create further presets. Other output options via other apps can be added afterwards.

As regards going the whole hog and do a DVD, nice but this can be added in at a later date (I was already planning to mark points in the video so I can quickly navigate to them, these could later become chapters). But I think there is already a good free util for DVD creation ?

I think the difficult part is to create a GUI which can play Avisynth scripts smoothly.

Absolutely. This is a reason to try and partition the timeline into blocks so that you can create a temporary video (preview) for a block and use that during other parts of the editing. There should also be (I rekon) three settings, 'draft' 'preview' and 'full', each enabling more of the graph features. For example, if you are setting up an overlay video, do you really care if the video is deinterlaced, colour corrected, temporally smoothed, etc ? Nope, so the script can be sped up by omitting these whilst concentrating on positioning the overlay, setting its border colour, etc etc.

Another big problem is to create a system, which converts a timeline to the actual script. But it should be doable to.

Timeline isn't to bad TBH, other than perhaps optimising conversions between YUY2, RGB32, etc as needed by different filters.

[quote]If somebody's interested in my ideas, I will be glad to share them.[/qoute]

Nows the time to voice 'em. Even if my pipe dream comes to nought, at least its captured for someone else to pick up.

TTFN,
Jon

[smok3]

Ahead of you there.
maybe :)

But I think there is already a good free util for DVD creation ?

chapter points must align with I frames for example...

[JonE]

chapter points must align with I frames for example...

Yep, but as I'm (as a starting point) going via Ffmpeg I don't think I'm in control of the exact location of I-Frames. But the main focus is an editor, integrating DVD creaion would be nice but is a project in its own right.

I've not investigated DVD creation utils other than I use TMPG and VideoStudio and they also do the encoding. If I were to export just the AviSynth script is there a standard file format for containing chapter point info in an additional file that could be picked up by any DVD creation utils ?

TTFN,
Jon

[Gavino]

On the subject of timelines, I think normal linear timelines as used in the editors I've seen, isn't enough.

Rather I see timelines-within-timelines. Not sure how to describe it, but imagine a rectangle on one timeline that can expand into its own internal timelines (which in themselves could be further subdivided).
Exactly my thinking. Ideally you should be able to combine the basic building blocks (clips) in a hierarchic way, to any degree of nesting (also allowing repetition - a clip can appear more than once), with the ability to attach processing of your choice at any point in the hierarchy.
Of course, this maps quite naturally on to Avisynth's notion of a clip.

Do any existing editors support such a model?

[JonE]

...also allowing repetition - a clip can appear more than once...

Only to a point. The idea is you import a clip into a project's "library" and can (optionally) apply various functions to it, but with the restriction that the there is no concept of a timeline at that point. Smooth it, crop/resize image, inverse telecine it, etc all work, but altering the duration = no. When you then add the clip to a timeline there are two options,
1) The clip on the timeline references whatever functions were applied to the library version. Modify the library version and the timeline clip automatically takes on the changes
2) Automatically inherits a _copy_ of whatever was applied to the library version i.e. once on the timeline you can modify the settings but this doesn't feed back to the original library version.

With case (1), if the duration of the library version were allowed to change, it could potentially affect lots of timeline clips, some buried within blocks as described in previous message. I don't fancy trying to sort out the overal project's timeline after such a change.

Of course, this maps quite naturally on to Avisynth's notion of a clip.

I agree. It should render to an Avi script reasonably easilly.

Do any existing editors support such a model?

Not that I'm aware of.

I think viewing the hierarchy may turn out to look just like "GraphEdit" mentioned earlier in the thread.

TTFN,
Jon

[fvisagie]

I think the project itself would be, how the video editor should work/behave/look like

Hi All,

A very interesting discussion and thanks for pointing me here, Gavino.

Some very good points raised IMO and the most important one at this time is the one above - what are the specs of the NLE?

In my professional work as product manager I've seen many a worthy project sunk because the initial scope was so large it just drowned everybody from system engineers through developers to testers. The rule of thumb is to start off with something clean, simple yet extensible so that it can later be meaningfully extended with minimal rework. Use feedback after each release to help shape the next version in addition to what was already imagined. This makes work much more granular and manageable and ultimately meaningful to the users.

To put it differently: it seems everybody wants to become famous for writing the famous "professional-level open-source NLE". No harm in that objective, only in the approach. Big-bang attempts so far have stalled or ended in failure. What are the ramifications of that?

Most people are incapable of AVS scripting and are therefore excluded from supporting it. They certainly would have used, tested and supported an Avisynth-based NLE, had it existed, but are left with nothing. NOTHING, not even a simple, clean and functional NLE.

In my experience most people don't even need or use more than that, but they still don't have even that because people have been aiming too high to start off with.

So, engage the majority of videophiles out there, provide them with a simple, clean and functional implementation. They will love it, become involved and help support on-going phases.

What else to bear in mind when specifying this work? As an ex-developer myself, I know one can get carried away at the prospect of re-doing something in a much better way, but this normally helps drowning a project by creating huge amounts of unnecessary work, right at the vulnerable outset. Don't re-invent any wheel, especially if it works really well.

So, following some of the points raised in this thread, let's start trimming down towards a suggested initial baseline feature set. At the end I'll provide an absolutely surprising and very impressive example of just how achievable this is.

Media:
Handling all the popular formats, input, converting, processing, rendering etc. This is important and integral to a usable NLE. No question, just integrate with/build on top of AVS - it's all there already.

Encoders:
Out for now. Fantastic external encoders like ffmpeg can already input AVS. Don't over-complicate the initial NLE version with unnecessary integration, leave that for later.

DVD authoring:
Out for now, there are 100% perfect open-source tools for that already (e.g. GUI for dvdauthor/MuxMan). Can be integrated later. While on the topic, there was mention of chapter boundaries on I frames. Muxers like MuxMan automatically adjust your requested chapter points to the nearest I frame.

What does that leave? Well, just the NLE GUI really.

Following is a suggested set of baseline features. Don't be put off if it appears daunting at first sight, it isn't really, just bear with me. The example to follow of an existing graphical NLE will show how extraordinarily simply much of this can actually be achieved.

GUI:
modern, but simple, GUI
keyboard shortcuts for common operations
ability to cut video clips
ability to add still clips
clips are automatically assigned customisable default names
clips are graphically identified by thumbnail icons of their content
clips can be trimmed, split, copied, pasted etc.
ability to hierarchically manage clip collections
realtime preview of individual clips
graphical timeline with clip drag-and-drop support
clips on timeline are shown with their thumbnail icons and text names
ability to add configurable transitions
ability to add configurable in-line text (titles, credits etc.)
ability to add configurable inlay text (captions, subtitles etc.)
ability to add video effects to selected clips
ability to add audio effects such as volume adjustment, mute etc. to selected clips
additional audio track supporting same audio effects as above
timeline content can be edited (trim, split, delete, paste etc.) independently of original clips
IMPORTANT: selectable anchor on/off for items on separate tracks. This gives the user control over what happens when the master timeline track is edited.
realtime timeline preview
fast keyboard timeline navigation - jumpt to next/previous item etc.
timeline can be zoomed and scrolled with the mouse
custom AVS commands
Optional/for next version:
audio from video can be expanded down to separate track for ease-of-use
transitions shown on separate track for ease-of-use
inlay text shown on separate track for ease-of-use
effects shown on separate track for ease-of-use
tracks can be associated and then expanded/collapsed to simplify collective operations

To give you some idea of the kind of simplicity of operation but good workflow I have in mind above, refer to the Windows Movie Maker GUI. Yes, do look past its stability and media handling issues, we're talking about its GUI: it is clean, functional and intuitive. (Important functionality which it does lack: the ability to anchor (or not) items on secondary tracks to points on the master track.)

So, finally, let's look at that promised example! How difficult does it really have to be to implement a NLE with the above GUI elements on top of AVS? Well, barring thumbnailing of items, multiple tracks, built-in subtitling support and its rudimentary look-and-feel, the brilliant little AVSCutter implements all of the above basic functionality, in its executable of all of 625KB!

In doing so, in my view AVSCutter demonstrates: 1) that implementing an NLE workflow on top of AVS is entirely achievable, and 2) that even a simple initial implementation can achieve really great functionality.

So, I thank you for the opportunity for contributing these thoughts. I hope they are useful and help inspire the writing of a clean, intuitive and engaging Avisynth NLE GUI. As things develop I will be honoured if I could contribute further.

Best regards,
Francois

[JonE]

Hi fvisagie,

Thats some great input there. I'll give a fuller answer once I've digested some of the points made - I'd also like to take a peek at this AVSCutter first.

Progress has been continuing, more on a set of libraries for doing some of the jobs that really are independant of how the GUI progresses - DirectShow library has stalled a bit as no one will tell me any details about how to use Ffdshow's DirectShow interface and I refuse to bang on the registry to configure it !

I'm relatively new to AviSynth myself so am doing a bit of learning there. Results will be appearing on my website once I get a few more together - quite prepared for them to be in the AviSynth Wiki, but whilst on my site the are "under development" whilst once on the Wiki people will expect them to be fully sorted.

I've already started work on use cases; it is vital to have a clear view of exactly what the editor will (and wont) do, as well as how it might expand. For example, from day one, ffmpeg will be used as the final rendering engine, however later interfacing to other options will be a must so provided the rendering module is designed with this in mind it'll save a lot of hassle later.

Anyhow, more detailed response later, but wanted to get back to you ASAP after you'd provided such a lot of useful input there.

TTFN,
Jon

[Mug Funky]

i'm thinking if an avs based editor were to be able to compete with the likes of FCP and avid, avisynth would become a very small part of a massive project. basically the "engine".

and also, it'd need to support handling compressed videos (so if your timeline is set to "DV", any DV elements in it will be passed through untouched, and any different formats would be rendered to DV at export).

i see two possibilities, which could both eventually be in the one program.

- offline editing. the emphasis here would be on speed and compatibility with existing frameworks like CMX EDLs, or XML, or even AAF and MXF in the future. but an EDL compatibility mode would be great - it'd prevent the editor from doing anything that can't be represented within an EDL, so what is cut in AVS-NLE would reconform perfectly in any other NLE.

- effects/finishing mode. this would possibly take a timeline from "offline mode" and allow you to apply avs filterchains to clips in the timeline. avid does something similar where effects are stored in "bins" and you can drop them onto clips. final cut also kind of does this. this mode wouldn't require EDL compatibility as it would be the final step before finishing the project. but it should be able to load EDLs and make sense of them.

the main things other edit suites do which is outside the scope of avisynth is logging and capturing, outputting to tape, deck control and media management.

i think this is possible, but so much of it is outside the scope of avisynth, it would be simpler to just write an entire NLE and use avisynth as the media layer.

[edit]

the reason i think a program like this would be necessary and novel is that avs is extremely lightweight, and NLE programs certainly are not. it'd be great to have a tool that can be used on cheap systems to do rough cuts, and still be fully compatible with the bigger edit systems when it comes time to do the heavy stuff. a lightweight but full featured editing system would be sweet.

[JonE]

The rule of thumb is to start off with something clean, simple yet extensible so that it can later be meaningfully extended with minimal rework.
“Simple yet extensible” – so easy to say, but is only truly possible if you have a clear picture of the final goal and also adopt design processes that inevitably increase the amount of coding effort . For example, if you hard coded effects into the code, you will require more than minimal rework to add configurable effects later. Know that it is the goal, even if you code only a subset of whats required, and rework is simplified later. Example (touched on later) is using ffmpeg as the output encoder; knowing other methods will be added influence the initial design even though from day 1 only ffmpeg will be supported.
For my own purposes, I want to be able to re-use the editor so that it uses DirectShow’s Direct Editing Services instead of AVISynth and that influences the design even though initially only AVISynth will be implemented.
In my professional work as product manager I've seen many a worthy project sunk because the initial scope was so large it just drowned everybody from system engineers through developers to testers.
Absolutely. It is vital to be clear about exactly what the purpose is and as a result what is to be implemented (and is genuinely required) and what will be left out.
Personally, priority number 1 is the user should be able to go from a bundle of source clips to a finished video file without knowing about command lines or AVISynth/ffmpeg syntaxes unless they *choose* to.
Following is a suggested set of baseline features ... (Useful feature list)
Mostly agreed and planned in, but I’ll just pick a few points here.
“clips on timeline are shown with their thumbnail icons and text names” The problem is, if a clip isn’t very large when displayed there is little room for anything. Therefore, it is better to rely on having a separate panel dedicated to displaying details about a selected clip, not just thumbnails and name but applied effects and such like. Now, if the timeline is drawn sufficiently large then the first thing to put on the timeline might be a thumbnail, and then if it is large enough also add a name. But, a separate panel is the way to go. And for example 16 pixel high thumbnails are of little use, so to display a useful thumbnail on a timeline means making the timelines particularly large – better is a pop-up window as the mouse is moved over a timeline element, allowing larger preview thumbnails without using up too much display real estate for the timeline display itself. One thing to ensure is that the thumbnail is configurable as to where the image comes from, at least one editor I tried always used the first image from the stream, not helpful when the source video starts as a black image!
“keyboard shortcuts for common operations” : Agreed – and such support greatly extends usability, not just due to user preference but also for devices used for those with disabilities, through to enhanced operation such as external controllers (forgotton product name at the moment, but basically a device with a “whirly wheel” for navigation and a few customisable buttons).
“IMPORTANT: selectable anchor on/off for items on separate tracks." Hmm, not considered this – earlier in thread I mentioned an approach for managing how other timelines might change should the duration of an element on the primary timeline change, and for the “basic” user thats enough. But anchor points would provide greater control for the more experienced users, so consider the idea well and truly pinched :-)
“custom AVS commands” – Well, as a primary goal is that a user should not need to be aware of AVISynth commands, this is definitely phase 2 – if at all. Better is to provide appropriate wizards to achieve functionality – if someone is up to entering AVS commands directly then TBH they are probably happier to write the script without a NLE GUI, or are perfectly happy with the available simpler editors. If AVS commands were to be implemented then a lot of background coding is required in order to support the feature, such as validation and managing script errors. However, the ability to be able to add external scripts – for example to do effects or transitions – is a requirement, but it must be wrapable in a user friendly way. Very much a phase 2 thing, but in essence is just an extension of how initial effects would be implemented.
“transitions shown on separate track for ease-of-use” When screen real-estate is at a premium – and it is – then anything that avoids separate timeline for transitions is favourable. One approach is to provide alternative timeline views; view timeline as one would expect of a typical editor, but an alternative is to view a sequence as a sequence of blocks totally devoid of actual timing information (kinda hinted at as GraphEdt type of view earlier in thread). Hard to put into text, but consider clip A of 30 mins duration, clip B of 20 mins duration, and between them a transition of 3 seconds. You can display this as three equal size boxes shown as clip A, a transition, and clip B, making it easy to select the transition whereas selecting a 3 second transition on 50 mins of a normal timeline display would be a pain in the wotsit.
One thing that needs addressing and is omitted from editors I’ve seen is the ability to modify multiple transitions – for example, you’ve implemented a wizard that enables the user to import 100 still images with a transition between each image. Then later down the line you go “DOH! I meant to use that other transition type” – don’t fancy individually modifying 100 transitions but that is exactly what I’ve been faced with by existing editors.
“effects shown on separate track for ease-of-use” Again, takes up real estate. What is certainly required though is the ability for the user to see an overview of all of the effects that might be applied to a particular timeline clip and modify the effects as appropriate.
Also, as kind of hinted at in previous posts, there needs to be the concept of global effects – effects that apply to the source clip and repeated whenever that source clip is added to a timeline, and any modifications to the source clip automatically effect all timeline clips derived from the source clip – and local effects that apply only to that specific instance of a clip on the timeline. So, if you select a clip on a timeline and modify an effect, there must be a way for the user to reflect that change across all instances of that clip should they wish to.

Media:
Handling all the popular formats, input, converting, processing, rendering etc. This is important and integral to a usable NLE. No question, just integrate with/build on top of AVS - it's all there already.
Yes, handle standard formats, but cannot totally rely on AVISynth. Must support DirectShow sources in which case codec management is vital – this is why I’m trying to programmatically manage ffdshow configuration (and getting frustrated with it :-( ). If trying to include base level users then you cannot rely on them understanding exactly what combinations of directshow components work and which ones clash, and I have no wish to answer all the tech support that uncontrolled usage of DirectShow will generate (all codec pack creators will be second against the wall when the revolution comes but second only because Nero will be the first!!)
Also, some formats are not editor friendly, such as slow and inaccurate frame positioning, and when encountering such formats the user should be warned and offered the option to convert the source video to a more editor-friendly format.
Encoders:
Out for now. Fantastic external encoders like ffmpeg can already input AVS. Don't over-complicate the initial NLE version with unnecessary integration, leave that for later.
Disagree there. The user absolutely must be able to create a real video file at the end – no point hiding them from the complexity of an AVIsynth script only to then baffle them with working out command line parameters for ffmpeg (hell, I ‘aint managed to fully understand them yet!). Instead, they select a profile – “MPEG2 for DVD”, “YouTube”, etc, and programmatically you just need to launch ffmpeg with the appropriate command line parameters and monitor progress, which programmatically is straight forward. Adding the ability for the more savvy user to create their own profiles is also fairly trivial.
So, Ffmpeg output from day one. Longer term there are alternatives to ffmpeg, but as long as they are something that recognise AVISynth scripts and can be launched from the command line then supporting them should be straightforward as long as this has been considered during initial development.
In fact the only issue is cater for variations between ffmpeg versions and also to work around some of the ffmpeg bugs such as not always interpreting AVI headers correctly (e.g. if audio stream is in the AVI header but its length is zero -> “only kidding, there is no audio really” but chokes certain ffmpeg versions). But, as far as the editor goes, outputting a real video file from day one is a must.
DVD authoring:
Out for now, there are 100% perfect open-source tools for that already (e.g. GUI for dvdauthor/MuxMan)..
Couldn’t agree more, DVD creation is an app in its own right. The only consideration is that of being generate any information that may be picked up by DVD creation programs, initially I’m thinking about chapter points but later it would be good to be able to enter subtitles in the editor that can then be picked up in the DVD creator (if that is at all possible) – subtitle positions (as in timeline positions) will vary as changes are made to timelines, therefore generating subtitle information has to be a feature of the editor.

---
Another design item to consider is more and more users are using multiple monitors (in fact my w*rk PC has three monitors) and with just a little forethought it is possible to make things much easier to use when multiple monitors exist simply due to the very much larger screen real estate thats available.
Finally, one further aspect is to consider platforms. I use Windows at home, I code commercial video apps using Windows at work, and coding will be primarily .NET. But as .NET is (i believe) also available for other OS’s then I think portability needs to be considered early on. So, for example cleanly isolating GUI and platform specific I/O from the underlying functionality is a must – I certainly don’t have any experience of porting .NET code to other OS’s (‘C/C++’ yes, ‘.NET’ no) , but I’m sure such an approach would ease a future migration to other platforms.

@Mug Funky :-

and also, it'd need to support handling compressed videos (so if your timeline is set to "DV", any DV elements in it will be passed through untouched, and any different formats would be rendered to DV at export).

Everything is done via an AVISynth script, therefor the video will always be re-compressed, even if it is DV-to-DV.

...compatibility with existing frameworks like CMX EDLs, or XML, or even AAF and MXF...

I recognised "XML" but 'fraid the rest of that totally baffled me :confused: Projects will be saved as XML so if someone wanted to they could parse it and convert to whatever form some other app might like - but very much their problem not mine :)

...and capturing, outputting to tape...
Definately outside the scope of this project, it is best left to stand alone apps (in fact, already written one :)). Video files come in, video files go out, the only help in obtaining input files is to auto-search plugged-in devices for likely video files.

TTFN,
Jon

[vlada]

I have some comments too.

Direct stream copy

I completely agree with Mug Funky about the need for "smart rendering" (AKA Direct Stream Copy) function. Even if you use Avisynth as the engine, it should be possible. Not easy, but possible. I think the workflow might look like this:
1) Identify the parts, which don't need recompression.
2) Find the frames, which are suitable for cut (I-frame for start and I/P for end)
3) Export all the parts as copy of the original stream
4) Export the rest with recompression
5) Join all the parts together

It will have the benefits of increasing output quality and export speed. It will be much more significant for modern camcorders, which use H.264 video compression (AVCHD). I think this is extremely important feature, because I (and I beleive also the majority of people) usually only need to recompress about 10% of the footage (transitions, titles). The rest remains untouched.

What I'm not certain about is the way to export the video. I think it is a good idea to export video and audio separately because the splitting points for stream/recompression might be different. If your target output format is AVI, it should be possible to join such video using AVI-Mux GUI (controlled by a script). MKVToolnix supports video/audio joining, but it might need to be done separately for audio and video. I'm totally uncertain about MPEG-TS/PS and MP4.

Another option might be using the FFmpeg libraries (libavformat, libavcodec) directly, but I have no experience with it.

Clip display

Regarding GUI and clip representation I think there is no need to have other views then classic timeline. With a zoom function you can easily access a 1s part within a 1h video.

Video reading

I quite successfully managed to read video into AviSynth by first analyzing it using MediaInfo and then reading it either by FFmpegSource (reads 95% of videos), DirectShowSource (reads all video if filters are installed), DGMPGDec, DGAVCDec or AVISource. The drawback of all these filters, except of DirectShowSource and AVISource, is that you need to index the video before reading it. But this can be done in the background.

Porting

Since AviSynth only runs on Windows, it is impossible to port such program to other OS. I'm a fan of Linux, so I would like to see a good NLE for Linux, but AviSynth is a show stopper here. :-(

[MfA]

What would be the goal exactly? Simply to be able to use avisynth filters inside a NLE?

Once the gstreamer wrapper gets finished you could just make a dll shim for the wrapper with MSVC so it could be used with existing binary avisynth filters under windows and use those with PiTiVi (not quite finished, but getting there).

If you want to see a portable NLE with avisynth filter support an approach using portable frameworks (gstreamer, MLT, NMM) with wrappers is the most reasonable way ... and gstreamer+PiTiVi is the road of least resistance (kdenlive would be a much harder port to windows).

[smok3]

as a script kiddie i would say:
a. avisynth doesn't seem like a valid option
b. the thing should be writen for the native system, preferably some sort of linux (ubuntu studio may be a good distro?)
b2. the thing could be a live CD as well (the entire bootable os)
c. avisynth is meant for other stuff and as such a port would be welcome

[JonE]

...about the need for "smart rendering" (AKA Direct Stream Copy) function
It isn’t a need, but I agree that avoiding un-necessary re-compression would be great. However its an awful lot of work and it falls outside what can be done in an AviSynth script for which the whole purpose of the editor is a front end for AviSynth.
I guess what might be a possibility later on is to get the editor to only generate the sections of video that required re-compression along with say some XML that contained information that could be parsed by a third party application that could generate the remaining sections and then stitch them together.
What I'm not certain about is the way to export the video. I think it is a good idea to export video and audio separately..
Hadn’t considered this. Can you clarify the reason why someone would do this ? It oughta be a doddle to implement if there is a clear reason for doing so.
Another option might be using the FFmpeg libraries (libavformat, libavcodec) directly, but I have no experience with it.
I’ve had a quick look at it, out of curiosity, but not for this editor – I see no point as ffmpeg sucks in an AVISynth script and spits out a video file in more formats than you can shake a stick at whilst in effect having been tested by millions of users and I don’t need to modify my code to keep pace with any latest changes to libraries.
Regarding GUI and clip representation I think there is no need to have other views then classic timeline. With a zoom function you can easily access a 1s part within a 1h video.
Have you ever had a chance to play with VideoStudio ? This implements this two modes of display and it works really well, saving a lot of zooming in and out. It allows you to concentrate on the order of objects, and given the timeline-within-timeline structure of the main timeline I feel this alternative view is essential.
I quite successfully managed to read video into AviSynth by first analyzing it using MediaInfo ...
Intended method is when user imports a new video clip then I generate a number of AVISynth scripts to read the clip using all available methods and then choose the most appropriate one that works automatically (with option for user to override method should they choose). This has the big advantage of making it automatically take account improvements over time ; for example, if in the future FfmpeSource supports a new wizzo video format then I won’t need to modify the editor code. The one exception is DirectShowSource – this can be crippled by inappropriate component installation, so initially I might not support it and hope that if the editor really does see the light of day I can get to work with whoever wrote the DirectShowSource and see if we can’t make it robust - I hasten to add, not DirectShowSource’s fault, but these [bleep][bleep] brain dead DirectShow component writers mentioning no names (Leronix, Nero ...) not helped by the mostly dangerous “codec packs” that are knocking about.
Since AviSynth only runs on Windows, it is impossible to port such program to other OS.
You know, I was getting so used to useful progs being cross platform I’d just assumed AviSynth would be cross platform. But I guess VFW / DirectShow are very Windows-specific.

What would be the goal exactly? Simply to be able to use avisynth filters inside a NLE?

Some goals of an NLE are
*) Buffers the user from knowing what a script is - unless they *choose* to.
*) Yes, utilise the fantasic range of filters that are available (or at least an appropriate subset).
*) Allow users to easilly create complex effects
*) Provide a range of wizards for common tasks.

What it is NOT is
*) An attempt to wrap all of AVISynths possibilites in a nice gui - that is impossible
*) Something that an experienced scripter would want to use - once you are used to the range of tools currently available and are happy with scripts then hiding it all behind a GUI is actually a bad idea.
*) The last word in image quality.

An example of a common task would be to take a recording that was from VHS, pre-process it with a predefined selection of filters with some default values, trim it, and create an DVD ready MPEG from it. A base user shouldn't need to know what filters and parameters are there; an average user might want to access some parameters and tweak them to better suit a particular recording. A video expert will want much better control and probably want to experiment with other filters and fine tweak the the final compressor ... sorry, not supported !

TTFN,
Jon

[MfA]

Some goals of an NLE are
*) Buffers the user from knowing what a script is - unless they *choose* to.
*) Yes, utilise the fantasic range of filters that are available (or at least an appropriate subset).
*) Allow users to easilly create complex effects
*) Provide a range of wizards for common tasks.
Well, if you don't need the NLE to output an Avisynth script then a PiTiVi port to windows (has already been done as an experiment) with a shim to load binary avisynth filters is the most obvious way. It would still be portable, to the extent that all filters with source code can be ported to *nix.

Seems foolish to implement yet another NLE GUI (but then, I'm not familiar with the PiTiVi code).

[JonE]

Seems foolish to implement yet another NLE GUI...
Depends if it offers something different, and besides I'm not writing it specifically for others to use, rather I'm writing it for my own selfish learning purposes BUT if others find it or just some of the libraries/controls useful too then that would be cool.

As well as being interested in AviSynth, I need to evaluate DES and MediaFoundation, so need a test bed for that, and also try alternative GUI's (WPF and the rather neat Krypton controls (http://www.componentfactory.com/)). Hence designing an editor.

Getting distracted by anything else -however worthy - just means the bits I need to do don't get done.

TTFN,
Jon

[vlada]

JonE> The suggestion to export video and audio separately and to use FFmpeg libraries was related to the smart rendering feature. But even if you won't implement it, it might be useful to separate audio and video. For example Muxman doesn't support muxed video and other muxing tools also prefer separated streams. I'm not sure if the ffmpeg muxers are good enough. I think that specialized programs (such as MKVToolnix, AVI-Mux GUI or MP4Creator) will do a much better job.

According to the timeline view, I used Pinnacle for some time and I agree it is a good option. I just don't give it that high importance. But it is your project and the priorities are up to you. :-)

There was a project of multiplatform Avisynth 3.0, the developers even released a version which compiled on Linux and used GStreamer to read video. But the project is unfortunately stalled for many years now.

MfA> Using Avisynth as an engine has a lot of advantages. It provides high quality filters, allows complicated compositing, track layering and a lot of other features. It can do everything a standard NLE can. But to do a more complicated job, the scripting is very difficult to use. So a GUI for Avisynth is a good idea IMHO. The only serious problem I can see is portability.

There are some opensource NLEs like Lumiera (not released yet), PiTiVi, Kdenlive (not many features), Cinelerra (unintuitive UI), Open Movie Editor, LiVES (not many features, not user friendly). But none of them runs on Windows. I hope that PiTiVi will be ported, because along with Kdenlive it seems to be going the right direction.

[MfA]

There are some opensource NLEs like Lumiera (not released yet), PiTiVi, Kdenlive (not many features), Cinelerra (unintuitive UI), Open Movie Editor, LiVES (not many features, not user friendly). But none of them runs on Windows. I hope that PiTiVi will be ported, because along with Kdenlive it seems to be going the right direction.
You missed Openshot (another Python with GTK+ application). Although again this uses MLT, which is portable in theory but I don't think anyone ever attempted it.

[mbcd]

Come on guys ...

You try to do a thing far from all gods.

You try to make an application which includes 3 or more different hugh apps.

I dont think that there will be some good result, becuse its too big. Otherwise you get only less functionality and nobody wants to use it.

For DVD-Authoring there are lots of Programs out there. Look at non-OpenSource how big this is and how complicated.

I dont think that it is possible to use AVS on such a way, because its not bild for "simple plugin"-use.


Look out there: I didnt find only ONE good Editor for AVS with a simple preview window.

Even the impliaction of new filter is quite a hugh work for noobs, because its an absolute catastrophy.

You need the Plugin.dll and sometimes some version-matched-filter from third-parts to get the Filter run.
Using properties of a filter is quite a big problem, because they are not given by the plugin automaticly, you have to find out by reading the info or readme-file.

Working with AVS takes a LOT of time, because its not realized on a good way. AVS is imazing -- really -- but the way it works is very worse.

[fvisagie]

Hi All,

Picking up on some points made here:

GUI timeline, clip thumbnail size etc.
JonE and others, I share the concerns you raised, but they don't need rocket science to address. Windows Movie Maker very successfully addressed all of them (as mentioned, that's where my GUI crib list came from ;-)). It has hierarchical clip folders on the top left, preview on the top right, configurable display (thumbnail, name, details etc.) of the selected clip folder's contents in the top middle, and the zoomable timeline along the bottom. Not that everything needs to follow that layout; just to give you an idea of a clean simple layout which works very well. Additionally Movie Maker has a storyboard view, where only the timeline is swapped out with the storyboard - clip thumbnails and transitions aren't scaled to time and so on, making composition on the storyboard very simple.

Smart rendering
Very good point. And once again, this is something which was achieved completely transparently in my example of Movie Maker (at least in the case of DV which I'm familiar with). No need for the user to mark, render, reconstruct, or even remember. Movie Maker just renders, and in the case of similar input and output formats it does a direct copy of frames it didn't modify with overlay, effect or transition.

Separating video and audio
Not a good idea in my view to do this before the encoder. Video and audio sync problems are so easily introduced this way. If the NLE includes an encoder, then of course no problem from that point of view if the NLE outputs elementary video and audio, already encoded. However, if the NLE is built for external encoders (or for users who elect to use external ones), it's very much preferable to render multiplexed. By the way, in my experience so far, ffmpeg multiplexing has been squeaky clean in the following tool chain involving the very finicky MuxMan:
Movie Maker (multiplexed DV) -> ffmpeg (multiplexed MPEG-2) -> AviDemux (elementary M2V & AC3) -> GUI for MuxMan

I agree with mbcd that the scope of the discussion at this point is too large for a manageable project. Of course, there's the issue of what people are capable of and interested in contributing on the one hand, but on the other there's what is practically possible to glue together and make work in a meaningful whole.

Which leads to the following paradox: a little can make a whole, but a lot will leave a hole (tm). :)

[smok3]

1. things could be separated (development wise), say project manager could be a separated app (and not necessarily needed for editing), very few editors i saw has a better management than your prefered system file manager anyway, you can study: avtodesk smoke and/or lightworks if you need a usefull idea on that behalf, linkage:
http://www.lwks.com/ , http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=5561833
2. you can edit completely without any thumbnails on the timeline, so thats basically barbie stuff
3. separating audio and video, whats that supposed to mean?
4. ok, so windows has movie maker, make it linux then, see my previous post (personally i wouldn't want to contribute anything to the windows-only platform)

[JonE]

You try to make an application which includes 3 or more different hugh apps.
Hmm .. re-read this thread, you will see I’ve already said that things like DVD creation aren’t initially planned. The only DVD-related support (other than outputting MPEG2) is if there are simple things like subtitle lists that might be generated and picked up by a separate DVD creation program.
Working with AVS takes a LOT of time, because its not realized on a good way. AVS is imazing -- really -- but the way it works is very worse.
Script-wise, it seems very well structured to me.
However, programming AVISynth directly is a bit of a nightmare – from some very unfriendly data structures through to little info on how to do it. But chucking a script directly at DirectShow gets around that issue.

Windows Movie Maker very successfully addressed all of them (as mentioned, that's where my GUI crib list came from ;-)).
Most of the list you provided is very much planned.
Additionally Movie Maker has a storyboard view,...
Once you’ve had that feature, it’s difficult to do without! I was impressed with VideoStudio 10 and it too has this feature, with each clip separated by a box into which you can drop transition effects.
(Smart rendering) ... this is something which was achieved completely transparently in my example of Movie Maker (at least in the case of DV which I'm familiar with)
DV isn’t temporally compressed and is one of the reasons its great for editing. MPEG2, MPEG4, etc are temporally compressed and are a nightmare to cut and you still have to render some frames next to cut points. This is a nightmare and way _way_ outside my area of knowledge.
(Seperating video and audio) ... Not a good idea in my view to do this before the encoder.
I agree, splitting audio and video and then recombining them later always fills me with dread :-(. However, outputting video only (audio thrown away) and output audio only (video thrown away) are things I want anyway, so outputting both separately is very little additional effort.
I agree with mbcd that the scope of the discussion at this point is too large for a manageable project.
Not sure I agree. Yes, smart-rendering and DVD creation would make this a huge project, but I’ve said this aint gonna happen. The focus is on an easy to use editor, video comes in, video goes out, and under the hood only supporting capabilities that are part of AVISynth.
The key design element (the one that’s giving me a headache) is the design of the timeline control itself and the appropriate structure of the equivalent script.
One area that might really help though is for people willing to submit appropriate scripts for the various effects once an appropriate set of initial effects has been identified.

you can edit completely without any thumbnails on the timeline, so thats basically barbie stuff
No, not “Barbie stuff”, essential stuff to get non-expert users to be able to use the system. And if you have a timeline with 200 still images named img001,img002, etc, then you will definitely appreciate thumbnails !
separating audio and video, whats that supposed to mean?
Output the two as separate streams sourced from the same timeline structure. Personally I don't need such a feature, but I don’t have detailed knowledge of available utilities and what they require – so if a few people think its useful, and it takes negligible time to do it, then why not provide the facility ?
... (personally i wouldn't want to contribute anything to the windows-only platform)
Sorry, but with all due respect that attitude isn’t helpful. Yes, the current end result is Windows-only, but there has been a prototype AVISynth for Linux so presumably that will happen sometime and ffmpeg is already available for Linux. The editor will be .NET and I’m targeting version 2 of the framework since that is the latest supported by the Mono project whereas I’d usually use the 3.5 framework. So the potential is there.

TTFN,
Jon

[vlada]

JonE> Tin3tin has a lot of effects and transitions in his DVDslideshowGUI (http://download.videohelp.com/tin2tin/). From this program you can get an impression on how to do effects and transitions in Avisynth.

I had an idea to do it this way:
1) Each timeline is one clip variable
2) Each line consists of many pieces: video1a++transition1a++video1b++transition1c++video1c
3) The transition is defined separately as overlay (with some effects) of 2 clips
4) To each clip you'll have to first apply per clip filters and then adjust the clip to match the rest of the project (resolution, interlacing, framerate)
5) In the last line fill the empty parts with black clip, in other lines fill it with transparent clip.
6) Apply per line filters and per project filters

I'm not sure if I'm clear enough. If not, I'll provide a sample script.

Such file will be almost unreadable for a human. But it would allow you to use the AVS to store projects.

According to GUI layout, I would make it with customizable layout - dockable panels.

[Gavino]

The key design element (the one that’s giving me a headache) is the design of the timeline control itself and the appropriate structure of the equivalent script.
This is probably obvious to you already, but a key part of the design is the form of the internal data structure used to represent the timeline.

I see this as being a tree structure (or possibly a DAG), each node of which represents an operation like a filter application, a splice, an overlay, etc, and whose leaves are the source clips. This should be designed in such a way that each element maps easily into an Avisynth script expression. Then generating the overall script can be done by a recursive traversal of the data structure to combine all the elements appropriately, using only (or mostly) local data at each point.

As you said before, having a clear specification of what operations will be supported is essential to this design.

[JonE]

@vlada

Yes, I understand what you mean, its kinda what I ended up with having wasted time going round the houses and down a few dead ends.

I agree that effects need to be applied per clip, per timeline or per timeline group (==project).

Such file will be almost unreadable for a human
Not convinced; timelines and timeline objects can be given names by the user and these would form the basis of the varialble names used in the script. Also, the script can be broken down into multiple scripts with "includes", which lends itself nicely to being able to repeat a the same timeline group multiple times. An effort must be made to keep the script human-readable otherwise it'll be a debugging nightmare!

According to GUI layout, I would make it with customizable layout - dockable panels.

These work if you really have to display lots of things at once, but they can also be a nuiscence (Visual Studio's docakable layout drives me nuts at time).

Instead, I'm hoping to adopt a more context-driven approach; consider an "box" on the dialog; you click a timeline object, you see object's properties and available filters in that box. Click on a timeline, you see its properties and a (thumbnailed) list of library objects you could drop on that timeline. Click on the video window and you see maybe properties of the output (image size, frame rate, selected compression, etc). This'd minimise the amount of information that is shown at any one time and hence makes it simpler to use. (Incidently, I haven't got as far as detailed planning of this bit - one option is a floating panel for library objects that opens up when you put your mouse over it so you get a nice big list to select from and that list auto shrinks when you beging dragging an object out of teh library).

@Gavino, as it is getting difficult to put things in words, I've attached a pdf with some suitable pictures and desciptions of the intended structure and some pseudo-code as to how the script might be generated. Would appreciate any comments - I'm trying to second guess what methods might be more or less efficient.

TTFN,
Jon