<div class="gmail_quote">On Wed, Jun 6, 2012 at 10:20 PM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas.dufresne@collabora.co.uk" target="_blank">nicolas.dufresne@collabora.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The main issue is that it impose on video player dev the choice. I think<br>
it's an error to have two cluttersink. We should have one, with the<br>
automatic sink capabilities. In a way that when it's possible, it's not<br>
going to use an external sink element.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This way, if it's raw, or using video/x-surface (the format behind<br>
GstSurfaceBuffer format), it would simply render to the texture like the<br>
original cluttersink. I don't understand in the first place why it was<br>
decided that two elements was the way.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree that vaapisink is in a terrible state and should be fixed. But I<br>
don't agree that it shall be used with Clutter, or know about Clutter. I<br>
also have a strong opinion on choosing design toward Open Source<br>
solution first, and then offering ways for maybe close source<br>
alternative later.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Julien</div></div>