[Live-devel] Blocking vs Non-Blocking doGetNextFrame()???

[Silvain Beriault]

>
>> 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?