[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: [announce] xine aRts plugin 0.3-beta
From:       Martin Vogt <mvogt () rhrk ! uni-kl ! de>
Date:       2002-04-22 7:23:12
[Download RAW message or body]

On Sun, Apr 21, 2002 at 07:49:03PM -0400, George Staikos wrote:
> On April 21, 2002 05:39, Martin Vogt wrote:
> > On Sun, Apr 21, 2002 at 03:41:03AM -0400, George Staikos wrote:
> >
> > It was my intention to port KWinTV to the new image library.
> > There should be a common Video renderer for KDE.
> > I currently do not know the V4L interfaces, but I assume
> > its enough to pass V4L a pointer to an xv surface.
> > So I expect no big problems here.
> 
>    Don't port the old kwintv.  It's not worth it.  We're rewriting...  I agree 
> that we should have all of this code in a common library.  Moritz Wenk is 
> also working on the V4L code.  We have some working interfaces that we like 
> and already partially work.  Please have a look in kdenonbeta/kwintv3/ for an 
> example.  IIRC the Xv interface is in there too.  These are all functionally 
> incomplete, but they represent several iterations of redesign.  Do they work 
> with an arts design philosophy also? 

Hm, I didnt found the Xv code but as I see it, the current code
grabs into a QImage, is that right?
It seems 4vl supports overlay, but the code seems not
to have the necessary hooks yet.
If you stay with the QImage interface (grabbing to it)
I see no problem to replace this image later with an
"arts-enabled" one.(Even if QImage is now slow as hell)

The QImage will become later an arts image, or a direct VOImage.
In the arts case you can diretely render into the image
memory, you will have access to the mem over shared memory,
and then "flush" the image back into the arts pipeline.
You wont have to deal with details like overlay, if its
possible the image will already be an overlay image.
So if the tv-card supports overlay you can always pass it the
pointer and fall back to grabbing in the other case. 
(Is that right?)

All the other "properties" of the image come over arts-mcop, whereas
the image memory is embedded from arts into your
application over shared memory.
Additionally the image library will support a common KDE widget
which you can use for embedding and fullscreen switching(including
popup menues).(This only a partial information about
what you can expect in the image library, but maybe it gives you an idea)

regards,

Martin

_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]