Re: [Gnash-dev] Re: [Gnash] Gnash/XVideo Patch for 0.8.3

[Craig Kelley]

On Tue, Sep 23, 2008 at 8:36 AM, Bastiaan Jacques <address@hidden> wrote:
> On Tue, 23 Sep 2008, strk wrote:
>
>>Would it make sense to expose such routine from the MediaHandler
>>interface (new in trunk) ?

That would be great.  It would be nice to support converting from RGB
to the following:

#define YUY2   0x32595559   // 6  - YUY2 (packed, 16bpp)
#define UYVY   0x59565955   // 7  - UYVY (packed, 16bpp)
#define YVYU   0x55595659   // 8  - YVYU (packed, 16bpp)
#define YV12   0x32315659   // 9  - YV12 (planar, 12bpp)
#define I420   0x30323449   // 10 - I420 (planar, 12bpp)
#define NV12   0x3231564e   // 11 - NV12 (planar, 12bpp)
#define NV21   0x3132564e   // 12 - NV21 (planar, 12bpp)

ffmpeg's swscale doesn't support RGB->YVYU in the version I used to
build this.  It's all keyed on the FOURCC number.  The XVideo code has
a prioritized list for doing acceleration.  It tries to use an RGB Xv
port, because that's what AGG blots to, but if the hardware only
supports a YUV format, it tries to use the highest bandwidth packed
format first, then the highest bandwidth planar formats.

Video cards of the future will want to use OpenGL acceleration, but
embedded systems will probably not have that option for years to come.

It would be nice to abstract hw acceleration out, such that we had a
"rendered buffer" and a "hardware screen" independent of GUI and
backend.  That may not work so well with something like Cairo+OpenGL,
but I'm no expert on that front.  Also, there is no obvious way (that
I know of) to embed hw acceleration in a KDE application.

>> My suggestion is just use --enable-xvideo.
>
> I concur. That said, it would be great if Gnash would fallback on x11
> rendering if xv turns out not to work, even if --enable-xvideo is
> enabled. But this may be difficult...

That sounds good to me.  I was planning on waiting for the next
release and taking a look at it again.

-- 
http://inconnu.islug.org/~ink finger address@hidden for PGP block