Re: [CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas

[Tim Murphy]

Hi,

2008/6/8 Christian Thaeter <[EMAIL PROTECTED]>:

> I also think that video processing tasks should be run in a separate
>>> process from the gui so that they can't cause it to crash if they crash
>>> themselves.
>>>
>> No, No, No!
>> That would be completely misguided, IMHO. We should never bend the
>> architecture in order to "isolate" against possible crashes. The
>> application must not crash, period. We should never tolerate
>> "possible" crashes. That's the "broken window" theory, you know.
>>
>
Ha! ;-)  Fair enough.  I suppose that all my most annoying crashes in
Cinelerra have been in the GUI anyhow (according to Valgrind).

I look at the crash output of the program and every time I decide that I
simply don't have the energy to learn enough about Cinelerras internals to
find the root cause of the problem because it's so potentially complex,
being multi-threaded and having it's own GUI toolkit.

Anyhow when a standard toolkit is used I expect that half the problems will
just never happen.

Cheers,

Tim

Re: [CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas

[Christian Thaeter]

I also think that video processing tasks should be run in a separate 
process from the gui so that they can't cause it to crash if they 
crash themselves.

No, No, No!
That would be completely misguided, IMHO. We should never bend the
architecture in order to "isolate" against possible crashes. The
application must not crash, period. We should never tolerate
"possible" crashes. That's the "broken window" theory, you know.

Besides that, there may be arguments in favour of running the GUI in
a separate process, e.g. to have the core and backend running on a
dedicated video processing machine somewhere in the network. But
there is also a massive drawback with this approach: having multiple
processes means you need Inter Process Communication, which is costly
both in terms of execution and development resources.


When a program or just a part of it crashes, then it doesn't fulfil the 
job which was requested, for the user experience both are equally bad. 
Isolating things into subprocesses won't fix this and costs a lot more 
work and performance.


The real problem with a crash is that the user might loose unsaved work.
Lumiera *might* crash sometimes because of programming bugs (we are not 
perfect, but we aim to be) or by problems out of our reach, buggy 
codecs, power failures and so on. We have to ensure that the user *never 
ever* looses any work by a unintended programm termination, point.


The plan is to make it bullet proof against data loss by saving project 
data in a database like dump+log like fashion. This gurantees 
recoverability even better than the current 'Load Backup' feature of 
cinelerra which is already a cool thing. As side effect the user gets 
almost unlimited selective undo too.


Christian

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

[CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas

[Ichthyostega]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tim Murphy schrieb:
> Some people see editing as taking a long film and splitting it up. 
> For me it about organising lots of small clips into a big one and 
> PiTiVi was fairly good for that.

Hi Tim,

yes, both concepts are equally valid and are known since the beginning
of cutting film. I heard some people associate them with the two
prevalent types of editing machines, where the horizontal working
editing desk type machines would rather fit the "split and chain
together" approach, while the vertical working moviola-type machines
would rather tend to support "vaporize it into tiny clips and then
build the movie up".


> I would like tools that make it easy to see all my clips (first 
> frames) organise them into some rough groups and sequences - a kind 
> of album a bit like google picasa but with ordering.
As far as I can see, we (Lumiera devs) are well aware of the importance
of storyboard work, organizing your clips in the media bins etc. It may
look as if we don't care, but this is just due to the fact we need to
concentrate at the goal and with it the timeline first.
Having said that -- especially this "media manager and storyboard" part
would be a nice opportunity, where another developer could work without
much interference with the work on the editing core.

Btw, as our our current planning, Lumiera will have several
"perspective" like GUI arrangements for focussing on different tasks.


> Edit in low resolution
Is one of our prime objectives. Support will be built into the core.

> Use separate, asynchronous processes.
Of course we do it this way ;-)
Our rendering and data backend works mostly asynchronous with respect to
the GUI. Christian is about to build an elaborate cache, which maps to a
user provided caching area/file on disk. I (for the middle layer) will
collect and provide the necessary information to invalidate cached data
precisely on edit operations. I know this is ambitious, so please don't
expect any results soon :-P


> I also think that video processing tasks should be run in a separate 
> process from the gui so that they can't cause it to crash if they 
> crash themselves.
No, No, No!
That would be completely misguided, IMHO. We should never bend the
architecture in order to "isolate" against possible crashes. The
application must not crash, period. We should never tolerate
"possible" crashes. That's the "broken window" theory, you know.

Besides that, there may be arguments in favour of running the GUI in
a separate process, e.g. to have the core and backend running on a
dedicated video processing machine somewhere in the network. But
there is also a massive drawback with this approach: having multiple
processes means you need Inter Process Communication, which is costly
both in terms of execution and development resources.

Cheers,
Hermann V.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITBITZbZrB6HelLIRApskAKCDAcuP8bFZz3RA23d6GzwLhyY4sACdGYVI
jGXSM7oxNCqQWAKu1n+D87M=
=+Gs5
-END PGP SIGNATURE-

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra