According to the DeviceSource.cpp template, the doGetNextFrame()
should deliver a frame "in a non-blocking fashion i.e., so that we
return immediately from this function even if no data is currently
available."
However, if no data is available, the afterGetting() function is not
invoked within doGetNextFrame (since no new data is delivered) and
this causes the doGetNextFrame() function never to be called again by
the internal live555 API. Any suggestions on how this problem should
be handled?
When the new data does arrive - later - it must be handled as an
'event' - i.e., within the event loop. The event handler can then
call "doGetNextFrame()" again.
Unfortunately there's no one standard way of handling the arrival of
new data as an 'event', because it depends on your particular
environment (in particular, the nature of your input device). If your
input device can be treated as an open file, then it's easy, because
you can use the event loop's existing "select()" mechanism.
If, however, your input device cannot be treated as an open file, then
you have to do something else to handle the arrival of new data as an
'event'. Some people use the optional "watchVariable" parameter (to
"TaskScheduler::doEventLoop()") for this purpose. (Others may subclass
"TaskScheduler" to implement their own event loop, although that is
more difficult.)
Thank you for your suggestions. In my application, data is being pulled
from a circular queue containing uncompressed video data which I
compress and write to fTo within the doGetNextFrame() function. My
application is multi-threaded (with a single thread accessing the
live555 API as mentioned in the FAQ). So under those premise, do you see
any potential problem with having a doGetNextFrame() function that
blocks when there is no data available in the queue?
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
