[Live-devel] Framed Source Issue

[Ross Finlayson]

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