I have been diagnosing an issue on a client's system which is streaming
six live encoded H264 streams vis multicast RTP and I think the problem
lies in the triggerEvent() method.
The problem is that some of the streams just stop after a while. I added
extensive tracing to our code and identified that the last call to the
library is triggerEvent() to notify the library of a new frame but
deliverFrame() is never called after this.
I guess the problem is that triggerEvent() is not thread safe. My
solution is to derive BasicTaskScheduler and wrap the triggerEvent()
call with a mutex. I have yet to test that this fixes the problem.
I'm a bit confused though because I had thought that triggerEvent() was
thread safe. e.g, based on the content of this thread:
http://lists.live555.com/pipermail/live-devel/2012-June/015296.html
But I can't see how the implementation of triggerEvent() can be thread
safe, e.g, the last line:
fTriggersAwaitingHandling |= eventTriggerId;
must load, modify and store the value at fTriggersAwaitingHandling and
this won't be atomic.
Regards,
Robert Smith.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
