[Ardour-Dev] video timeline patch testing
pshirkey at boosthardware.com
Tue Jul 20 19:41:47 PDT 2010
On 07/21/2010 04:33 AM, Robin Gareus wrote:
> 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).
Certainly. No reason to put it in place now. Have to make sure the
system is robust and stable first :-)
> 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.
That's the current status quo but with ardour and blender working
together there is a distinct opportunity for people to adapt to the new
> 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.
I already do. It's actually quite handy :-)
>> 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
> 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.
ahem, videojack anyone?
> 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.
Is this just a case of not having implemented it or is there a
significant blocker to the codebase that will prevent it form being put
in place at a later date.
> 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.
I think it would be a very handy menu item.
> 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".
Well I expect that in this mode people would want it to autosync and
that is where things will get very tricky. I conceed that there is a
fair amount of effort required to enable that to be possible.
>> 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.
Sounds like you have some ideas for how to improve on this?
>> 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.
On this point I agree but real world experience has taught me that most
of the people I know don't actually stick to this and in fact do really
enjoy showing off what *they* can do with their very cool software ;-)
It's about the personal gratification aspect more than anything else.
Look what I can do with my system and aren't I clever!!! If I had a
dollar for everytime I have seen a techy do this I would be able to make
my next rent payment.
Boost Hardware Ltd
More information about the Ardour-Dev