<br><font size=2><tt>> The problem is, deliverFrame returns the very
first frame OK, then <br>
> doGetNextFrame is called again before a new frame is captured, and
I <br>
> return immediately. Then, I don't know why, liveMedia never calls
<br>
> doGetNextFrame again. It just stays stuck and apparently does nothing.<br>
> <br>
> Why? What I'm doing wrong?<br>
> <br>
> If I remove that block of code, conversely, doGetNextFrame never blocks
<br>
> and always return "old" frames until the next frame is acquired,
filling <br>
> rapidly the CPU resources.<br>
> <br>
> Thanks.<br>
> <br>
> Regards,<br>
> <br>
> Cristiano.<br>
> <br>
</tt></font>
<br><font size=2><tt>1. Are you inheriting from FramedSource, from DeviceSource,
or modifying DeviceSource?</tt></font>
<br><font size=2><tt>2. Is "isAwaitingData()" function an abbreviation
for "isCurrentlyAwaitingData()", or are these separate functions?</tt></font>
<br><font size=2><tt>3. When you copy your data to fTo in deliverFrame(),
are you using "memcpy()" or similar function to write the data?</tt></font>
<br><font size=2><tt>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)</tt></font>
<br><font size=2><tt>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.</tt></font>
<br>
<br>
<br><font size=2><tt>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?</tt></font>
<br><font size=2><tt>~xo</tt></font>