[Live-devel] How to implement non-blocking fashion in custom doGetNextFrame()

[Cristiano Belloni]

Hi to all,

In my custom FramedSource, documentation recommends that doGetNextFrame 
should not call deliverFrame() if there is no frame ready.
So, I do something like that in doGetNextFrame.

isAwaitingData() functions checks if my real-time source has new encoded 
data (It's crafted in a way that it will always return the last frame, 
even if it's not a new one and it has been already used. isAwaitingData 
returns true if there's a new frame ready, false if there's an already 
returned frame):

if (!isAwaitingData()) {

         // We're not ready for the data yet
         return;
     }
           
   deliverFrame();
   
   // If, for some reason, the source device stops being readable
   // (e.g., it gets closed), then you do the following:

   if (isClosed) {
         handleClosure(this);
     return;

if there's new data, deliverFrame will be called and will set the 
correct "out" values for the frame (fFrameSize and so on).
If there's no new data, we return immediately leaving the parameters 
untouched.

The problem is, deliverFrame returns the very first frame OK, then 
doGetNextFrame is called again before a new frame is captured, and I 
return immediately. Then, I don't know why, liveMedia never calls 
doGetNextFrame again. It just stays stuck and apparently does nothing.

Why? What I'm doing wrong?

If I remove that block of code, conversely, doGetNextFrame never blocks 
and always return "old" frames until the next frame is acquired, filling 
rapidly the CPU resources.

Thanks.

Regards,

Cristiano.


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>