[Ardour-Dev] video timeline patch testing

[Robin Gareus]

On 07/20/2010 03:08 PM, Patrick Shirkey wrote:
> Now that I have this patch running here I have a better idea of what the
> potential is.
> 
> Apart from the obvious inevitable requests for multitrack video editing
> in ardour 
well, maybe in ardour4 (or 5).

Unless you plan to fork ardour it's something to discuss with Paul.

I don't see it happen for the reason that persons who are good
video-editors are rarely (or almost never) good audio-editors. There's
simply no professional demand. Thus using different applications - each
optimized for the task at hand - is the way to go.
Then of course the inter-app communication is something that becomes
very important. That however should happen on session-exchange level
rather than monitoring rendered-media-files on disk.
It may turn out that it's easier to write a two-in-one application than
pushing some inter-app communication protocol through the communities.
Either way, apart from audio and some some GUI templates a
video-NLE-ardour would have very little in common with what ardour is now.

> which I think the current approach will make realtively
> modular when the time comes there is also the question of having another
> app, for example, blender rendering the video at the same time it is
> being worked on in ardour. I know there is the jack transport sync in
> the latest blender which solves a lot of the issues but there is also
> the possibility that someone will like to have ardour
> videotimeline+xjadeo running at the same time as a blender session.

I'm sure there's also someone who'd like to have gnome + KDE running at
the same time.

> The question I have is how difficult would it be to make the timeline
> auto refresh when changes are made to the video file from an external
> program?

technically easy; conceptually tricky; practically hard :-)

1) I don't know a good cross-platform way to receive
file-changed-notifications but for polling the file itself.
If the frame is cached, icsd's response times (incl HTTP overhead) is
currently less than 1 ms. Checking the filemtime for every frame-request
would slow things down dramatically. It'd require a 'smart' algorithm.

2) There's no way to trigger actions in ardour from the
video-server (that'd monitor the video-file for changes). ardour3 asks
the server for video-info and -frames; but the server can not send
notifications on its own.

3) Apart from the fact that it's recommended to use some dedicated file
(for frame-accurate seeking & performance issues), working on the same
file is tricky: the 'other application' may not have written the
video-header to disk or use a video-container where the header is at the
end of the file rather than the beginning. So the
file-change-notification would need to detect "end of file changes by
the other app".
Using SGI-style (one file per video-frame) may be an option.

That being said: there's [internal] functions to flush the cache and
trigger a re-open-file in xjadeo but they're not accessible. A "re-read
video-file now" button (in ardour) would be the pragmatic
solution; but it is somewhat lame.

To sum it up: it's surely not a no-brainer and for me it's a "implement
later, if at all" feature.

> I realise it is an awkward issue but I do see some potential for making
> peoples lives easier if this case is handled gracefully.

IMHO this is a false assumption. Even if the software can provide it,
rapidly switching between Sound-design & Video-editing just slows you
down, making live harder.

Furthermore it'd require much more inter-app communication. eg when you
insert a few video-frames, you'll need to move or expand the audio at
that position as well. It'll fire back with users complaining: "the
video has shifted but my soundtrack has not".

> So does the timeline autorefresh or is that something that is on/off the
> roadmap? Reasons for/against could be helpful for determining how useful
> this would be.

ardour caches the images for the current-screen + 1 to the left & right.
Hiding/Showing the timeline flushes ardour's frame-cache.

The video-server's cache can not yet be cleared by simple means.
For now you can just kill and restart it.

> In terms of usability for non technical types I see it as a no brainer
> but in terms of implementation hassles I'm not sure of the requirements.
> 
> Clearly it's not a high priority but it would be pretty cool to show off
> with ;-)

Indeed, but showing-off is the only use-case I see in this.
The reasons against: It is not part of any usual workflow and I don't
want the app to _try to_ be smart.

Better show off with a very cool movie & soundtrack you made with that
software rather than with the software itself.

> Cheers.

Thanks for the feedback. You got me thinking.

best,
robin