[Live-devel] Idle waiting in a MediaSource/Sink

[Ross Finlayson]

>- is the getNextFrame method allowed to block?

No.  Your implementation of the "doGetNextFrame()" virtual function must either
1/ deliver date immediately to the client (and then call 
"FramedSource::afterGetting()"), or
2/ arrange (somehow) for data to be delivered to the client later 
(when it becomes available, via the event loop), and then *return 
immediately*v.  This allows the code to continue processing events.

As a general rule, *no* code that uses the "LIVE555 Streaming Media" 
libraries should block, waiting for data.  Instead, pending data 
should be handled via the event loop (which should be running continuously).

>- if the answer is NO, then what is the currect way to handle the 
>case that the source temporarily can't provide any data?

As I noted above, pending data should be handled via the event 
loop.  If your data is available on a socket, then you can just call 
"TaskScheduler::turnOnBackgroundReadHandling()" to schedule an event 
to be handled when new data arrives on the socket.  Otherwise, you 
can perhaps use the "watchVariable" parameter to 
"TaskScheduler::doEventLoop()" (see, for example, 
<http://lists.live555.com/pipermail/live-devel/2005-September/003276.html>). 
In more complex situations, you could write your own subclass of 
"TaskScheduler" (to reimplement "doEventLoop()").  (Note that 
"BasicTaskScheduler" is intended to be just that - a 'basic' task 
scheduler, not one that's intended to be used for every possible application.)

>I believe that a similiar scenario already exists in Live555, which 
>is the RTPSource.

No.  If you look at the code, you'll see that "MultiFramedRTPSource" 
calls "RTPInterface::startNetworkReading()", which in turn calls 
"TaskScheduler::turnOnBackgroundReadHandling()".  I.e., incoming RTP 
packets are handled using the event loop.

>  it can only provide data to its sink if there is data to read from 
> the socket. what does RTPSource do if there is no data waiting at 
> the RTP socket?

It returns immediately (see "MultiFramedRTPSource::doGetNextFrame()" 
and "MultiFramedRTPSource::doGetNextFrame1()").


>I have a similiar problem with a MediaSink which does the reverse 
>operation of my source, i.e. it receives data from an RTPSource and 
>passes it into our own framework:
>
>    RTPSource --> MyMediaSink ---> [queue] (another thread)
>
>this is done through a queue of fixed size. the data is read from 
>the queue by another thread, so the situation is similiar: if the 
>queue runs full, the MediaSink can't request any data from the 
>RTPSource until it gets notified by the other thread that there are 
>free slots in the queue again. I have solved this by blocking in the 
>afterGetting method. the result may be data loss at the receiver 
>socket, which, however, is no acceptable

I don't understand this.  If your receiving queue fills up, you have 
to expect to lose incoming packet data.  The underlying OS will 
buffer incoming packet data to a certain extent (and you can control 
this by calling "increaseReceiveBufferTo()" (note that 
"MultiFramedRTPSource" sets the OS's receive buffer to 50 
kBytes)).  But if incoming packet data arrives faster than you can 
process it, you must always expect some to get lost.


	Ross Finlayson
	Live Networks, Inc. (LIVE555.COM)
	<http://www.live555.com/>