[Kdenlive-devel] real-time preview?

[Rolf Dubitzky]

Hi Reinhard,

On Tuesday 26 November 2002 01:22 pm, Reinhard Amersberger wrote:
> since my opinion is 'to have a real-time preview is the most important
> feature' I would like to ask you if kdenlive will be able to do that.

of course the goal is to have real time preview, but there are many steps 
towards this goal.

> AVID impressed me VERY MUCH in this matter, because this tool offers you a
> real 'real-time preview'.
>
> For example, you put a transition between two clips, position your curser
> before this and hit space to start play and AVID show you DIRECTLY the
> result in a very high quality. And my machine isn't very fast, it's just an
> 1,2 GHz Athlon with 528 MB RAM!

1) piave is designed for _absolut_ minimum memcopy and optimal reuse of frame 
buffers. The tree like approach makes it possible to render all effects 'in 
place' where this is possible at all. This part is well designed (IMHO) and 
operational. Only thing I can think of is a z-buffer like algorith to 
discover parts of the underlying image which do not have to be rendered at 
all. This is not in planning.

2) The effect algorithms themselves are mostly unoptimized. I am sure with a 
little thought it is possible to improve their speed by factors between 1.1 
and 100 ;-)

3) piave cannot display simple DV in realtime. even kino can't on my PC but 
kino is much faster. piave does not use xv X-extension to display and libdv 
is not a very fast decoder.

4) Right now, it does not much of a difference if I just display a video or if 
I compute AlphaBlend / ShiftIn / framedecor / etc. filters. I canclude, that 
we will be able to all this in realtime with no problem. Scaling for PicInPic 
takes a bit, but I use gdk-pixbuf, which is _not_ optimized for this purpose.

My priority list is as follows and is subject to change and discussion:

1) Have any effects at all. No real time.
    - I have some, most are proof-of-concept but need a finish (hint;-)
      ( e.g. shift in can only shift in from top, not from bottom, which is 
      trivial to implement etc.)

2) Be able to display DV video in realtime.
    - right now, we cannot even play DV _without_ any effect
      in realtime. I am working on libavcodec IFace. For writing this seems
      doable and for reading it needs some work. dv decoding lin libavcodec
      is maybe faster than in libdv but maybe poorer quality. When they 
      support audio it might be an option.

3) Prerender complex effets to a cache.
    - given 2) we then can display in RT

4) Extend the render engine for different layers of
   effect quality (I already though about this extension when
   designing the who;e thing, it's no problem)
    - every effect will then be available in different qualities, where
      lower quality means faster. One can think of:
      - lowest:   use if not in cache
      - medium:   use to prerender to cache
      - high:     use for final production

      especially -lowest is very challenging. I can think of all kinds of
      OpenGL for your brand new 1024bit 2GHz 512MB graphic card.
      I have no clue about GL, any help is welcome. If nobody steps up when 
      the time for this optimization comes, I plan to steel shamelessly from 
      jahkashaka as long as they are still GPL.

      The effect does not necessarily need to look exactly the same. E.g.
      I just implemented the text effect, and when using a dynamic effect 
      (changing size, rotation, glow, etc..) I have to rerender each letter 
      for every frame. for preview I could just render them once and cach the 
      bitmap as I do for static text effects.

Thoughts? Comments?

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************