Currently I am working on an application using gstreamer 1.0, this application should to open a stream over rtsp, all work fine if no problem is detected on stream. But when arrived an ERROR or EOS message and I try to call:
gst_element_set_state(pipeline, GST_STATE_NULL)
over the pipeline, this call block the thread and nothing happen.
Could anyone help me with this issue on GStreamer.?
As per my understanding We should not call gst_element_set_state() in any of the gstreamer thread. It may cause deadlock.
Related
To get all bus messages from my GStreamer pipelines, I am currently calling gst_bus_set_sync_handler (returning GST_BUS_DROP from my handler). This seems to work perfectly as far as I can tell, but the documentation states:
This function is usually only called by the creator of the bus.
Applications should handle messages asynchronously using the gst_bus
watch and poll functions.
Should I be worried? I assume that the "creator of the bus" is not the same as the creator of the pipeline (me), or is it?
There are a couple considerations I'm aware of regarding the use of gst_bus_set_sync_handler.
Firstly, since it runs your code synchronously in the same thread that posted the message, you'll be blocking that thread from doing other work for as long as your callback runs. If you do a fair bit of work when handling a message, this could cause performance issues.
Secondly, you may not reliably be able to use gst_element_set_state in a synchronous message handler, because elements are not allowed to set their own state in their streaming thread. Whether or not this is a problem will depend on which streaming thread in the pipeline sent the message, something you normally don't have to worry about in asynchronous messaging handlers.
I would recommend using asynchronous messaging whenever possible, as it has fewer caveats. On the other hand, if gst_bus_set_sync_handler works for you, using it shouldn't be a problem.
I have a GStreamer pipeline whose topology is changed on occasion. What we do is:
gst_element_set_state(pipeline, GST_STATE_READY);
gst_element_unlink(node1, tee);
gst_element_link(node1, oldfilm);
gst_element_link(oldfilm, tee);
gst_element_set_state(pipeline, GST_STATE_PLAYING);
We assume the pipeline must be stopped while elements are re-connected. Problem: Our app hangs, typically video stops streaming after the first few times we change topology, and then the next call to gst_element_set_state(pipeline, GST_STATE_PLAYING) never returns. The app still responds to ^C, which of course kills it.
We conclude we are not doing this right. What is the right way to alter pipeline topology while the application is running?
Back in 2016 at the GStreamer conference I heard a talk about this topic which felt quite useful in this context.
Slides:
https://gstreamer.freedesktop.org/data/events/gstreamer-conference/2016/Jose%20A.%20Santos%20-%20How%20to%20work%20with%20dynamic%20pipelines%20using%20GStreamer.pdf
Talk:
https://gstconf.ubicast.tv/videos/how-to-work-dynamic-pipelines/
I hope this explains how to work with these type of problems.
so basically I am having problems when trying to run EdsDownloadEvfImage from the Canon EOS SDK on a separate thread. The program then does... unexpected things, freezes, etc.
Basically, what it does is that the worker thread freezes on EdsDownloadEvfImage when trying to lock a mutex from main thread, which is simply mind-blowing for me.
I've found out that doing any of the EdsOpenSession, EdsCreateMemoryStream, etc. on a thread is an absolute killer, but that doesn't mind, the only really time-consuming operation is that image download.
Based on the documenatation, I've ensured that the worker thread has
CoInitializeEx( NULL, COINIT_APARTMENTTHREADED )
called before the download. I've also tried it without it and it was without any difference. Maybe there's some problem with executing this function?
Or would a working alternative be running the entire EDSDK on a worker thread? (with initializeSDK etc.)
Thanks for reponses.
Btw: I'm using the SDK in a Qt application.
Problem solved, I just put everything on a separate thread and now it's working fine.
I am using the USB-Hid Class to communicate with my USB-Device in a C++ Application.
Can someone tell me, what the routine HidD_FlushQueue() exactly does? https://msdn.microsoft.com/en-us/library/windows/hardware/ff538876%28v=vs.85%29.aspx
I am using it to flush the input queue before sending a command. I was told to do so to guarantee the input queue is empty.
This normally works great but in some circumstances, my programm gets stuck in this funtion and does not return.
I am not using some asynchronious methods that acess the queue could block it. Is it possible, that the problem lies on the side of the USB device? Any advices?
A HID device can send Input Reports to the host. Windows accumulates these reports in a queue. HidD_FlushQueue() removes all the reports accumulated by Windows from the queue.
I call the function at the beginning of my reading thread and I've never had a problem, although my device doesn't send reports until they're requested.
I have an iPhone app that is recording audio and then broadcasting it across the network. In response to a "stop" from the far end it queues a notification to stop the recording. Alas when it gets to the AudioQueueStop call the application just hangs (ie Stop never exits). Thanks to the notification all AudioQueue manipulation is happening on the same thread.
Has anyone got any idea whats going on here?
Edit: I have set up a listener in the UI thread that handles the recorder.
Then from my network thread I use a "postNotificationName" beliving that it was post a message to the UI thread and everything would run from that thread. This does not appear to be the case. When I break point the function that is called by the postNotificationName it appears that the call is being made on the networking thread and NOT on the UI Thread.
I assume this is my error. Anyone know how to make it work by notifying the UIThread to handle it?
Edit2: OK I've re-written it to use performSelectorOnMainThread. And it still crashes.
On the plus side I just learnt how to get a lot more info out of XCode so I can see the call stack goes:
semaphore_timedwait_signal_trap
semaphore_timedwait_signal
_pthread_cond_wait
pthread_cond_timedwait_relative_np
CAGuard::WaitFor
ClientAudioQueue::ServicePendingCallbacks
AudioQueueStop
[etc]
Anyone got any ideas why it hangs?
How do you call AudioQueueStop ? The function supports two modes: synchronous and asynchronous.
The preferred way is to use the asynchronous stopping as the function will return immediately, while the remaining buffers will be played/recorded.
If you want to go synchronous and you get a hang, then maybe there is a dead-lock or a race condition somewhere. Have you tried to pause the application under the debugger and check the threads' stack-frames to see where the problem is ?