<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">It's not the only solution.<div><br></div><div>gstreamer could spawn another process and share framebuffer (e.g. by using IOSurface).</div><div><br><div><div>On 26.06.2013, at 16:17, Andoni Morales <<a href="mailto:ylatuya@gmail.com">ylatuya@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/26 Ilya Kulakov <span dir="ltr"><<a href="mailto:kulakov.ilya@gmail.com" target="_blank">kulakov.ilya@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">> So this new thread with the run loop is only<br>
> started when the sink needs to create its own window and the application<br>
> didn't start any run loop.<br>
> This hack we made to make osxvideosink work with gst-launch, but in a<br>
> normal scenario, the application should have started a run loop and this<br>
> internal thread will not be created.<br>
</div>This does not explain why new thread is created for each instance. It to should be created once for the whole class and reused.<br>
Used hack does not support scenario with multiple osxvideosink instances which is pretty possible even with get-launch.<br>
<br>
Also the hack itself is very very unstable. One should not mangle with mainThread like this and just let the main thread to be what AppKit decides.<br>
Since, as you pointed, the only real use case when osxvideosink has to create new thread is with gst-launch, wouldn't it be simpler to update it in the same manner<br>
as other cross platform UI frameworks work (like Qt or wxWidgets)?<br></blockquote><div><br></div><div>I wish it was that easy :) It's something we have been discussing several times and we haven't found a better solution. Like I commented before, if this thread is started more than once it's a bug and it shouldn't happen at all. This scenario doesn't not only happens with gst-launch, it could also happen with any small application that doesn't start a run loop in the main thread and instead blocks it with its own polling using gst_bus_timed_pop_filtered. What happens than? The sink can very likely be started on a completely different and with the main thread blocked, how do you run any Cocoa stuff with the main thread blocked? So the only solution in this case is to start a dedicated thread for it and make it believe it's the main thread. For UI frameworks like QT or GTK it's completely different because they start a main loop in in the main thread, and in this main loop they integrate the run loop. We can ask to do that for every simple app because it's platform specific and because it's only required for osxvideosink and when no window handle is provided to the sink.<br>
<br></div><div>Cheers,<br></div><div>Andoni<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> Could to please open a new bug and attach a test case?<br>
<br>
</div><a href="https://bugzilla.gnome.org/show_bug.cgi?id=703100" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=703100</a></blockquote></div><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br>
<a href="http://www.longomatch.ylatuya.es/">http://www.longomatch.ylatuya.es</a>
</div></div>
</blockquote></div><br></div></body></html>