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

[xcsmith at rockwellcollins.com]

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

1. Are you inheriting from FramedSource, from DeviceSource, or modifying 
DeviceSource?
2. Is "isAwaitingData()" function an abbreviation for 
"isCurrentlyAwaitingData()", or are these separate functions?
3. When you copy your data to fTo in deliverFrame(), are you using 
"memcpy()" or similar function to write the data?
4. Does your "deliverFrame()" call "afterGetting()"?  You have to call 
"afterGetting()" so that the downstream filter / sink can begin handling 
your data. (Ross said this on the last thread post)
5. Does your "afterGetting() function set fIsCurrentlyAwaitingData? If you 
don't set fIsCurrentlyAwaitingData to False, then as you see in 
FramedSource::getNextFrame(), the source->sink chain will quit. 
FramedSource.cpp line 64.


Ross provided a general solution email earlier.  If you have more 
questions, I'd be interested in looking at what you've written.  I enjoy 
working with the filter code.  The source you've posted isn't enough for 
me to help more specifically.  Can you post all / more of your file or 
just send it to me?
~xo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20080303/26199abc/attachment-0001.html