Gstreamer-VAAPI and Totem

[Julien Moutte]

I am talking about the Video Accelerated decoder which is supposed to work
with other video sinks than just the Clutter one.

Adopting GstVideoBuffer means using it both in the decoder and in the sink,
meaning that our decoder would only work with recent GStreamer versions
breaking our support agreeements.

So we have to stick to our own decoder and sink sharing hardware
accelerated buffers with a common library which we provide ourself. We also
provide a clutter video sink that uses that same library and that will be
able to render VA buffers in clutter as long as clutter is recent enough to
contain the fixes we provided.

Hope this makes it clearer. But in the end those are 2 different topics.
Having an autocluttersink makes a lot of sense IMHO as we were using the
exact same design before with autovideosink and the
prepare-xid/window-handle logic. I can imagine many different hardware
vendors that will want to support Clutter and hardware accelerated decoding
and that will want to do it their own way by providing a sink element. (and
I think we already had that discussion in a bug somewhere :) )

Salut ! :)

*Julien MOUTTE*
C.T.O.

FLUENDO Influencing the Multimedia World

San Francisco, USA & Barcelona, SPAIN
Contact phone:
Spain:  +34 933 175 153
United States: +1 415 773 5353
www.fluendo.com

Please consider the environment before printing this e-mail.



On Wed, Jun 6, 2012 at 8:03 PM, Bastien Nocera <hadess at hadess.net> wrote:

> On Wed, 2012-06-06 at 19:52 +0200, Julien Moutte wrote:
> > Hi,
> >
> >
> > autocluttersink's role is just to provide a way for different platform
> > specific sink plugins to be automatically discovered and used to
> > render video buffers into clutter.
> >
> >
> > Now that being said, every clutter sink element just has to respect a
> > common api to draw in the proper actor/texture. The way you handle
> > this drawing and the fact that it's optimal or suboptimal is just a
> > detail here.
> >
> >
> > To reply to your question about Fluendo's design choice here, you have
> > to take in account that we always try to support old versions of
> > GStreamer because of our customers.
> >
> >
> > We can't just make our products depend on a very recent API added for
> > gst-vaapi and tell all our customers using old GStreamer versions to
> > go to hell.
>
> Given that you need a new version of clutter-gst for this to not
> deadlock, this is a bit of a weird requirement.
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120606/a9c5b3e8/attachment.htm>