Reusing osxvideosink

[Andoni Morales]

2013/6/25 Илья Кулаков <kulakov.ilya at gmail.com>

> Hi,
>
> I'm trying to reuse pipeline which ends which is essentially "filesrc !
> qtdemux ! h264parse ! avdec_h264 ! videoconvert ! osxvideosink
>
> The code can be reduced to:
>
> 1. Init and add elements. register "pad-added" signal on qtdemux
> 2. Set location of filesrc
> 3. Set state of the pipeline to PLAYING
> 4. Wait for EOS using gst_bus_timed_pop_filtered
> 5. Set state of the pipeline to READY
> 6. Set new location of filesrc
> 7. Set state of the pipeline to PLAYING
>
> Unfortunately the deadlock occurs at step 7. Sometimes, when I run it
> through debugger it is able to create new window but that's all because it
> is stuck in deadlock again.
> Stack shown that thread is stuck in waiting for completion of the command
> which is deferred to another, specifically created thread for Cocoa.
>
> Since I'm primarily Mac OS X / Cocoa developer I decided to look into
> implementation.
>
> First of all what is the particular reason to set up new thread and run
> loop for each instance of osxvideosink?
>
Hi,

The sink will only create its own window if the application does not pass a
window handle through the GstVideoOverlay interface and when this window is
created, a run loop needs to be running to defer any Cocoa call to Cocoa's
main thread. When there isn't any run loop running, like for instance when
you run gst-launch, the sink needs to create a new thread and start a run
loop for Cocoa (there is some black magic to make it believe that this new
thread is the main thread). So this new thread with the run loop is only
started when the sink needs to create its own window and the application
didn't start any run loop.
This hack we made to make osxvideosink work with gst-launch, but in a
normal scenario, the application should have started a run loop and this
internal thread will not be created.

Then it looks like thread/run loop can be started multiple times for the
> same instance each time you go ready -> playing.
>
This shouldn't happen at all and if it does it's a bug in the sink. In case
the run loop was started in the first transition, it won't be started again
since it's already running. You should check that
gst_osx_video_sink_run_cocoa_loop
is only called once.


> Also why is window created (destroyed) when we go from ready -> playing
> (and vice versa). I think it would be wise and better to reuse it unless
> state is transitioned to NULL.
>
This must be done this way  because the application can pass a window
handle through the GstVideoOverlay in the next transition from  READY to
PAUSE, and in that case the sink does not need to create its own window.


Could to please open a new bug and attach a test case?


Cheers,
Andoni


> I would be able to fix and address all of these issues, but I'd like to
> know whether it would make sense and be accepted by the community.
>
>
> Best regards,
> Ilya Kulakov
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>



-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130625/91ddaa6a/attachment-0001.html>