GNOME Bugzilla – Bug 758533
State change to READY too slow on iOS (possible interaction between RTSP and VideoToolbox?)
Last modified: 2018-01-23 20:28:03 UTC
Created attachment 316087 [details] Crash 1 I have a pipeline as follows: rtspsrc latency=0 location=rtspt://192.168.1.1:8554/test ! decodebin ! videoconvert ! autovideosink name=video-sink I'm using this on iOS with the GStreamer framework. I'm testing it in poor network conditions (at the edge of WiFi range) and backgrounding the app. When it tries to stop the stream during the background, I sometimes get a crash. The reason for the crash is "failed to scene-update after 10.00s". Looking at the stack trace, I can see I'm trying to stop the stream and there is a mutex lock held at the end of a change state stack trace. I spoke to __tim on IRC and he said that state changes of the pipeline are synchronous, but shouldn't take too long. It looks like in this case, the pipeline state change is taking too long. Is the shutdown of the rtspsrc element perhaps taking too long? Could it be because I'm using rtspt (TCP)? I also noticed in one of the crash logs that VideoToolbox was involved in the stack trace so I'm not sure if there are actually a few ways for this to happen. Side question - should I be making state changes to the pipeline on the main thread on iOS? I followed the tutorials in that regard...
Created attachment 316088 [details] Crash 2 - with VideoToolbox
A small update - I think I've found a way to produce a long delay more reliably. Killing the wifi altogether and then trying to pause will create a long delay. In my app, if it turn Wifi off, a component notices this and tries to shut down the stream. It does this by first moving to the paused state, then killing the main loop (see deinit, in the iOS tutorial code: http://cgit.freedesktop.org/~slomo/gst-sdk-tutorials/tree/gst-sdk/tutorials/xcode%20iOS/Tutorial%204/VideoViewController.m#n78) While moving to the paused state the stream seems to hang for quite a while. Now, after looking at the tutorial code again, I realise I might be able to get away with just killing the main loop with the stream running, and not trying to move to the paused state. To me it still seems that there is something 'up' - in that moving to the paused state shouldn't take that long. I'll leave it up to you all if this warrants more investigation or not...
Sorry no one ever looked at this in more detail. This looks like a possible duplicate of bug #779247 or bug #778434 to me, but a lot else has changed and possibly been fixed since then - any chance you could re-test with a recent GStreamer version?
Sorry, I'm no longer using gstreamer. I worked on this project over 2 years ago. The repro instructions I left seem at least worth trying....
Thanks for the follow-up. I'll close this then. Chances are it's been fixed. People are using similar pipelines successfully with recent versions to the best of my knowledge. If it's still a problem someone will file a new bug.