Permalink | Reply |
Permalink | Reply |
Permalink | Reply |
headers
strk | 23 Sep 08:25
Gravatar

Re: [Gnash] Gnash/XVideo Patch for 0.8.3

On Wed, Jul 09, 2008 at 06:42:02PM -0600, Craig Kelley wrote:
> On Wed, Jul 9, 2008 at 6:08 PM, strk <strk <at> keybit.net> wrote:
> >
> > On Wed, Jul 09, 2008 at 11:39:05AM -0600, Craig Kelley wrote:
> > > I've updated my XVideo patch for 0.8.3.  It can be found here:
> > >
> > >    http://www.xmission.com/~ink/gnash/gnash-xvideo/
> >
> > The patch makes 'xvideo' look like an actual gui, why ?
> > Also, the patch requires gtk gui and ffmpeg media handler,
> > isn't there a chance to make use of xvideo also from other guis
> > (X-based) and other media handlers ?
> 
> It makes it a gui so that it is completely optional.   It
> fundamentally changes the GTK gui, and I didn't want to upset the
> default build of gnash with it (an early design decision made on IRC,
> but by no means required). 

I see it like the mit-shm extension, no need to be a separate gui,
just a configuration for the existing ones.
I assume NO xvideo will be used at runtime if not requested by user
or not available in the X server in use.

> It requires ffmpeg because it needs an
> rgb->yuv conversion routine, which cannot be provided by gst (yet --
> appsink + ffmpegcolorspace plugin would work, but appsink is in ugly
> right now). 

Would it make sense to expose such routine from the MediaHandler 
interface (new in trunk) ?
(Continue reading)

Permalink | Reply |
headers
Bastiaan Jacques | 23 Sep 16:36

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

On Tue, 23 Sep 2008, strk wrote:

> It's a pity if this patch goes discarded IMHO.
> What do other developers think about putting it in ?

I think this patch is a great idea. I have some nits about the
implementation, but if it is dependent on --enable-xvideo, I'm all for
it. I think having it as a separate GUI is not necessarily the best
idea, however it does achieve abstraction, which I think is crucial for
this patch.

> 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...

Bastiaan
Permalink | Reply |
headers
Craig Kelley | 23 Sep 17:02

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

On Tue, Sep 23, 2008 at 8:36 AM, Bastiaan Jacques <bastiaan <at> bjacques.org> 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,
(Continue reading)

Permalink | Reply |
headers
strk | 25 Sep 18:44
Gravatar

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

On Tue, Sep 23, 2008 at 09:02:26AM -0600, Craig Kelley wrote:
> On Tue, Sep 23, 2008 at 8:36 AM, Bastiaan Jacques <bastiaan <at> bjacques.org> wrote:
> > On Tue, 23 Sep 2008, strk wrote:

> >> 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.

Are you maintaining your patch in a bazaar branch by any chance ?
Or, can you do that on a shared one ?

--strk;
Permalink | Reply |
headers
Markus Gothe | 24 Sep 02:58
Favicon
Gravatar

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

I agree...

//Markus
On 23 Sep 2008, at 16:36, Bastiaan Jacques wrote:

> On Tue, 23 Sep 2008, strk wrote:
>
>> It's a pity if this patch goes discarded IMHO.
>> What do other developers think about putting it in ?
>
> I think this patch is a great idea. I have some nits about the
> implementation, but if it is dependent on --enable-xvideo, I'm all for
> it. I think having it as a separate GUI is not necessarily the best
> idea, however it does achieve abstraction, which I think is crucial  
> for
> this patch.
>
>> 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...
>
> Bastiaan
>
>
> _______________________________________________
> Gnash-dev mailing list
> Gnash-dev <at> gnu.org
> http://lists.gnu.org/mailman/listinfo/gnash-dev
(Continue reading)

Permalink | Reply |

Gmane