Details
-
Bug
-
Resolution: Cannot Reproduce
-
P3: Somewhat important
-
None
-
5.2.1, 5.3.0 Beta1
-
None
Description
I have an application which frequently stops and starts different MediaPlayer elements.
While this is working nicely on my desktop, I am experiencing problems with my imx6 based embedded system, probably due to it being wastly less powerful.
It seems that stopping one MediaPlayer and starting a second one in parallel does block the main thread too long for the second MediaPlayer to start up. I get the error message:
"Failed to start video surface due to main thread blocked"
Looking into the code it seems that this problem was to be expected:
" QMetaObject::invokeMethod(this, ""queuedStart"", Qt::QueuedConnection);
124
125 /*
126 Waiting for start() to be invoked in the main thread may block
127 if gstreamer blocks the main thread until this call is finished.
128 This situation is rare and usually caused by setState(Null)
129 while pipeline is being prerolled.
130
131 The proper solution to this involves controlling gstreamer pipeline from
132 other thread than video surface.
133
134 Currently start() fails if wait() timed out.
135 */
136 if (!m_setupCondition.wait(&m_mutex, 1000))
"
Is there any chance that this might be differently implemented in the near future?
Currently, I can workaround this by postponing the stopping of one MediaPlayer by about 300ms. This works for me currently, as the MediaPlayers are started sequentially. But I want to change that and start/stop them independently, which would be impossible currently.