Hi,<div><br></div><div>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.</div><div><br></div><div>
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.</div>
<div><br></div><div>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.</div><div><br></div><div>
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.</div><div><br></div><div>So I believe this is a good enough design to give freedom to everyone. There's several clutter sink elements out there and if you can make the gst-vaapi based on respect the common requirement to be usable with autocluttersink then it should just work no ?</div>
<div><br></div><div>Best regards,</div><div><br clear="all"><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><b>Julien MOUTTE</b><br>C.T.O.<br><br>FLUENDO <font size="1"><span style="color:rgb(51,51,51)">Influencing the Multimedia World</span><div style="color:rgb(102,102,102)">
<br style="color:rgb(192,192,192)"><span style="color:rgb(192,192,192)">San Francisco, USA & Barcelona, SPAIN</span></div><span style="color:rgb(192,192,192)">Contact phone:</span><br style="color:rgb(192,192,192)"><font color="#c0c0c0">Spain: </font><a value="+34933175153"><font color="#c0c0c0">+34 933 175 153</font></a><br style="color:rgb(192,192,192)">
<font color="#c0c0c0">United States: </font><a value="+14157735353"><font color="#c0c0c0">+1 415 773 5353</font></a><br style="color:rgb(192,192,192)"><a href="http://www.fluendo.com/" target="_blank"><font color="#c0c0c0">www.fluendo.com</font></a></font><div style="color:rgb(102,102,102)">
<br><span style="color:rgb(0,153,0)"><font size="4">P</font><font size="1">lease consider the environment before printing this e-mail.</font></span></div></span><br>
<br><br><div class="gmail_quote">On Wed, Jun 6, 2012 at 7:41 PM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas.dufresne@collabora.co.uk" target="_blank">nicolas.dufresne@collabora.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mercredi 06 juin 2012 à 18:30 +0100, Bastien Nocera a écrit :<br>
> > Bastien, any input where I can follow the issue? Even better, any chance<br>
> > of seeing Totem working with VA-API backported to 3.4 so that I don't<br>
> > have to get all the 3.5.* libraries? :)<br>
><br>
> Totem 3.5 makes use of autocluttersink, which rely on bug fixes in<br>
> clutter-gst. If you update those two, it might be enough.<br>
<br>
autocluttersink has never been tested along with gstreamer-vaapi (this<br>
arrived after my work). Instead of wrapping an X windows into a some DRI<br>
pixbuf, cluttersink (not autocluttersink) uses an new API in gstreamer<br>
that let it use the GstBuffer as textures that are directly rendered<br>
into the clutter scene.<br>
<br>
I do think this approach is more efficient then the autocluttersink one,<br>
and that fluendo could have implemented the GstVideoBuffer interface for<br>
the VA buffer rather then using this. It's a bit of a design war, my<br>
apology if this creates flames.<br>
<br>
cheers,<br>
Nicolas<br>
<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>