First, is it possible to explain using TaskScheduler::scheduleDelayedTask(), as you suggested, a little better?
In your implementation of "doGetNextFrame()", if no input data is currently available to be delivered to the downstream object, then you could just call "TaskScheduler::scheduleDelayedTask()" with a delay parameter of 10000 (i.e., 10 ms), and passing a pointer to a function (that you would write) that would call "doGetNextFrame()" once again, to retry. Then, after calling "TaskScheduler::scheduleDelayedTask()", just return.
For example, you could look at the code on lines 58-74 of "liveMedia/MPEG4VideoFileServerMediaSubsession.cpp", which does something slightly similar.
Second, I also suspect that the freezing issue has to do with the timestamps and the duration. I am setting the duration in microsecs as 26122 (for 44.1 KHz, MP3 frames of 1152 samples) for audio, and 33333 (30 fps) for video. The presentation time is obtained from gettimeofday(). However, I find that the audio is called much more often than 26122 microsecs. Audio is called only at intervals of a few thousand microsecs (about 10 times more than what it should be). Can you explain what may be going on. I am using MP3 in MPEG1or2AudioRTPSink.
Are you *sure* your "doGetFrame()" implementation is setting the "fDurationInMicroseconds" (and "fFrameSize" and "fPresentationTime") variable, before it calls "FramedSource::afterGetting()"? One way you can check this is by looking at the parameters to the (subsequent) call to "MultiFramedRTPSink:: ::afterGettingFrame()", and checking that they are correct.
-- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
