Slomo asked me here https://coaxion.net/blog/2013/10/gstreamer-1-0-examples-for-ios-android-and-in-general/comment-page-1/#comment-50051 to file this bug.

Does it work with tutorial 4 or 5 on a video file, or is it also broken there?


Can you provide a GStreamer debug log with tutorial 3, i.e. by doing gst_debug_set_default_threshold(GST_LEVEL_DEBUG) somewhere before starting the pipeline?

Created attachment 305898 [details]
debug log of tuto 3

First the log after launching the pipeline. And below the log after hitting "play".

Above debug log is for tuto 3 with
pipeline = gst_parse_launch("videotestsrc ! warptv ! videoconvert ! autovideosink", &error);

And tutorial 4 works with playbin and setting the uri.

There's no more output after the last line?

> 0:03:28.669232000 [331m17850[00m  0x28ae0a8 [36mINFO   [00m [00m           glcontext gstglcontext.c:1272:gst_gl_context_create_thread:<glcontexteagl0>[00m Attempting to create opengl context. user chosen api(s) (any), compiled api support (gles2) display api (opengl opengl3 gles2)

Created attachment 305902 [details] [review]
eagl: Don't dispatch_sync() to the main thread if we are on the main thread

This will otherwise deadlock.

This might fix it, please test

Ok I will try it. Sorry I am not sure where I must modify this file? And whether I will have to rebuild the pkg after modifying it?

Comment on attachment 305902 [details] [review]
eagl: Don't dispatch_sync() to the main thread if we are on the main thread

Doesn't help. The problem is that gst_gl_context_create() is called from the main thread, which then calls gst_gl_context_create_thread() from another thread and waits until that thread is finished with creating the context. Unfortunately that thread needs to call something from the main thread to finish, which is not possible because the main thread is waiting.

So both threads wait on each other.

I think to fix that we need to replace the g_cond_wait() there with a vfunc, and in the case of iOS would iterate the NSRunLoop on the main thread there (or if not called from the main thread, just wait in whatever way we want).

Also I would expect this to be broken in 1.4 too, IIRC it was always like this with the context creation threads.

I confirm that I don't have that issue with 1.4.5, it works fine.
And for your earlier question if there's more input after the last line, no it is the last line.

As a workaround you can for now set the pipeline to PAUSED/PLAYING from another thread than the main thread

maybe in 1.4 we didn't create a context as direct result of the the state change but only created it later from the streaming thread

Currently all the things we do in dispatch_sync() blocks should be possible to do from our current thread, at least if CALayer is thread-safe on iOS (it is on OSX).

Created attachment 306904 [details] [review]
gl/eagl: Don't call anything synchronously from the main thread

This will deadlock if the main thread is the one who creates the GstGLContext.
All things we call from the main thread should be possible from any thread.

Comment on attachment 306904 [details] [review]
gl/eagl: Don't call anything synchronously from the main thread

This patch makes things work for me on iOS - pushing.

Hi Guys,

I've tried 1.5.2 release and got the same issue. I'm wondering, if it was included into 1.5.2, despite that the changelog states yes - http://gstreamer.freedesktop.org/releases/gst-plugins-bad/1.5.2.html, but looks like it was not. Could you confirm?

Thanks

No, the fix will only be in 1.5.3 when we roll that. I'm not sure how it ended up in the fixed bug list for 1.5.2