Gstreamer-VAAPI and Totem

[Julien Moutte]

On Wed, Jun 6, 2012 at 10:20 PM, Nicolas Dufresne <
nicolas.dufresne at collabora.co.uk> wrote:
>
> 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.
>

What you are describing is what autocluttersink is about iirc. The fact
that it is nesting the native clutter-gst video sink in the normal scenario
is just to keep things clean. It's a bin that plugs the proper element on
the fly and the child element can be used independently as well.

This design is present in many other elements in GStreamer. Here the
application developer has the choice to use the clutter-gst video sink
directly if they really want to (like they could force ximagesink in the
past), but it's recommended to use the autoplugger to support as much video
formats as possible.

This also gives flexibility to deploy new features on an existing software
park which was not possible at all when Totem was creating a clutter sink
element by calling a static function shortcircuiting the GStreamer registry
completely.



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

Simply because there are other formats than raw RGB/YUV and video/x-surface
out there... Sure you're probably gonna say that you don't care and that
everybody should use an unstable API that is defined in
gstreamer-plugins-bad since november 2011. That's quite radical and I don't
see the point really, evenmore now that we know that this is gonna change
*again* in GStreamer 1.0.

Note that I am not criticizing your design on the videocontext stuff. We
proposed the exact same thing a long while ago and there was just not
enough consensus around it to make it happen (cairo was regarded as the
magic solution that was going to fix all our issues at that time).


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

Personally I care about the user experience. Users have been able to play
video files with video acceleration on Totem for quite a while because the
design was flexible (playbin2 using discovered video sinks, and
autovideosink allowing us to plug a different sink without touching the
application) and we could automagically integrate our Fluendo VA decoder
and Fluendo VA sink element. We had to overcome many regressions and
behavior changes to continue supporting our user community across Ubuntu
and Fedora releases but we managed it.

If you take that flexibility away due to personal convictions and force
others to go by your design or stay out of the trip I think you are doing
more damage to the OpenSource community than helping it. But that is just
my personal opinion.

By the way I think the opposite than you. I think that Clutter should not
know about GStreamer at all, it should provide a proper API to upload video
surfaces from any media framework and eventually have some helper widgets
as a side project leveraging GStreamer. It has always been GStreamer's
responsibility to provide plugins to integrate with various rendering
subsystems.

Julien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120606/ecee032e/attachment-0001.htm>