[Ardour-Dev] video timeline patch testing

[Robin Gareus]

On 07/21/2010 04:41 AM, Patrick Shirkey wrote:
> On 07/21/2010 04:33 AM, Robin Gareus wrote:
>> On 07/20/2010 03:08 PM, Patrick Shirkey wrote:
>>   
[[.. ardour video editor ..]
>> 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
> paradigm.

It's not about paradigms. While a technician may be able to handle the
app. It's a very rare gift having a feeling for more than one medium.

How many persons do you know who write great stories, shoot &
brilliantly direct it, edit it just right, do their own magnificent
soundtrack and maybe even publish it themselves?

anyway we're getting way OT. Let's resume that discussion when planning
for the ardour-NLE version, or move it to the Lumiera list for now.


As bottom-line I conclude that the the current state and usability of
the video-timeline and video-monitor integration in ardour3 is great
but for the fact that it lacks edit capabilities :)

[..]
>>> 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.
>>
>>    
> 
> ahem, videojack anyone?

videojack is inter-process communication layer; like JACK it does not
allow to request specific data (eg give me frame X from file Y).

icsd is a server with frame-cache and parallel video decoders.
The most elaborate interface to access the frame-cache is currently HTTP
but the codebase already includes a shared-mem interface which can be
used to connect a video-monitor.

The motivation behind using HTTP is that video-server(s) can be run on
external machine(s).

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

It's by design. Just like no webserver can connect to your browser.

The first version actually had bi-directional communication using a
custom socket interface and I've dropped that.

Using some side-band channel or a persistent HTTP connection for feeding
back notifications may get re-introduced later.

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

I will do that.

[..]
>>> 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 

That really depends. In the Pro world people don't want things
added/removed without their knowledge. They only want to have A/V
aligned properly and get markers where things have changed.
For the Home-video world software needs to do all the magic.

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

It's about knowing what edit operation took place at the other end and
do the same on our end. It either requires session-exchange or a shared
backend.

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

It's already implemented just not exposed yet. You will be able to
trigger it with http://localhost:1554/admin?cmd=flush_cache (or whatever
IP/port you make icsd listen to).

There's two main reason why it's not yet available: I want to first put
optional password protection for admin functions in place and there's
need for a coherence protocol in case multiple video-servers are used.

The ardour GUI has priority to get it ready for the 3.0 beta-1. And
maybe someone else can take over maintaining it when I shift focus on
the video-server again.

>>> 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 ;-)

I don't care. I'm not writing this to sell it to those guys.

The current goal is to provide a good, reliable & fun way to do
soundtracks for movies. And most of the time it does not even need a
video-timeline.

> It's about the personal gratification aspect more than anything else.

In my case it's about the the end-product: the completed film.

Well that's not the whole truth; It's elating to learn from
movie-directors that I'm quick tweaking things to his or her
preferences, even more so since I use FLOSS.

> Look what I can do with my system and aren't I clever!!!

"Sure, all very fine, but we still need to be working on that Climax,
the pace is too fast and we wanted to bring back the musical theme for
the subconscious story..."

> If I had a dollar for everytime I have seen a techy do this I would be able to make
> my next rent payment.

LOL.
robin