Gstreamer-VAAPI and Totem

Nicolas Dufresne nicolas.dufresne at collabora.co.uk
Wed Jun 6 13:20:16 PDT 2012


Le mercredi 06 juin 2012 à 22:00 +0200, Julien Moutte a écrit :
> 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 :) )

The main issue is that it impose on video player dev the choice. I think
it's an error to have two cluttersink. We should have one, with the
automatic sink capabilities. In a way that when it's possible, it's not
going to use an external sink element.

This way, if it's raw, or using video/x-surface (the format behind
GstSurfaceBuffer format), it would simply render to the texture like the
original cluttersink. I don't understand in the first place why it was
decided that two elements was the way.

I agree that vaapisink is in a terrible state and should be fixed. But I
don't agree that it shall be used with Clutter, or know about Clutter. I
also have a strong opinion on choosing design toward Open Source
solution first, and then offering ways for maybe close source
alternative later.

cheers,
Nicolas



More information about the gstreamer-devel mailing list