[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Bug with ARGB32 buffer canvas when stride != output width * 4

On Tue, 2006-04-04 at 11:36 +0900, Carsten Haitzler wrote:
> yup - i know :) i have handled this in emotion and it does it just fine (thank
> god) thus dvd playback using emotion is a doodle :) xine does the heavy lifting
> - emotion just plugs the right things in the right places. since for me the
> video is just another object - it just is under all the OSD objects within the
> canvas - its the reverse to what you do as the canvas is within the video stream

I actually do this as well.  My xine driver will composite a buffer
(rendered by evas) onto a running movie independent of the vo driver,
and it will also copy the current frame to a buffer of my choosing so
that I can render a running video to a canvas.  (Like emotion, but uses
shared memory and some basic IPC so xine can run in a separate process.)
So I can have canvas on top of movie or movie on top of canvas.

I wrote a high level canvas API in Python (called kaa.canvas) on top of
evas that supports all of this.  One cool feature of this is that I can
"detach" a canvas movie object.  If it's running on the canvas, I can
detach it so that it stops rendering to the canvas and begins rendering
to another window.  For x11, this other window is a subwindow of the
main application window, so it's a sort of fullscreen mode which lets me
use Xv and it's quite seamless.

Here's a working example:

        import kaa, kaa.canvas
        c = kaa.canvas.X11Canvas((640, 480))
        movie = c.add_child(kaa.canvas.Movie("dvd://"), width="50%",
                            opacity = 0.5, hcenter="50%", vcenter="50%")
This little program (which works as is) creates a 640x480 window, loads
background.png on it, and opens dvd:// on the canvas, making it 50% of
the width (of its parent, which is the main window), having it
vertically and horizontally centered (which is correct regardless of the
movie's aspect ratio) and 50% opacity.  After 5 seconds of running, the
movie will detach, which means the movie will be passed through to
xine's xv vo driver and that will occupy the full window (i.e. evas is

Of course you can reattach at any time, for example if you want to view
an EPG or navigate the menus with the video playing as a thumbnail.
Incidentally, the movie object has an 'osd' attribute which is another
Canvas.  This is the buffer canvas that uses the other part of the
special driver that handles overlay compositing.  So this works:

   movie.osd.add_child(kaa.canvas.Text("Hello E!"))
   movie.osd.show() # osd is hidden by default

Here's a screenshot of OSD running on top of xine's window:


dvd:// would be handled using Xine, but mplayer is also supported.  It
makes an intelligent decision about which one to use (if both are
available); for example, dvd:// would be handled using Xine.  mpg as
well, as Xine's deinterlacers are superior to mplayer.  (Both YUY2 and
YV12 are supported of course.)  If you're playing an avi, mkv, etc. it
will use mplayer by default, as mplayer has better post processing
filters (I can't live without fspp).  OTOH, for music, it will use xine,
so we get goom.  Here's a screenshot of xine playing music with goom
being rendered onto an evas x11 canvas:


So all this is what freevo 2.0 will be based on.  Evas and xine (and
mplayer to a lesser extent) are the workhorses here.  The kaa.canvas API
abstracts quite a bit on top of evas to provide a lot of nice features,
like lazy instantiation (you can define objects on a canvas without
actually needing to create the canvas right away), plus a basic layout
model (relative positioning, margins, padding, vbox, hbox, etc.).

Those interested can read more about the canvas API at:


(The doc is a bit behind the current state of things.)

So this turned into a bit of of a tangent.  Sorry about that.  I just
get excited about cool stuff. :)

> actually you dont need a new canvas - just get the engine info - change the
> outbuf pointer, set the info back, the output w/h and viewport and it will work
> with a live/existing canvas.

Ah!  I didn't know you could do that.  Excellent, yes, this is the right
way to solve the problem.