[Bug 758533] New: State change to READY too slow on iOS (possible interaction between RTSP and VideoToolbox?)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758533

            Bug ID: 758533
           Summary: State change to READY too slow on iOS (possible
                    interaction between RTSP and VideoToolbox?)
    Classification: Platform
           Product: GStreamer
           Version: 1.6.1
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: samduke474 at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 316087
  --> https://bugzilla.gnome.org/attachment.cgi?id=316087&action=edit
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...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.