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

[Florian Winter]

hi,

I have written a MediaSource class which injects multimedia data from 
our own multimedia framework into a Live555 flowgraph. the data is 
produced by another thread and written into a buffer queue from which my 
sink reads data, i.e.

    (another thread) [queue] ---> MyMediaSource --> (optional) framer 
--> RTPSink

now I have the following problem(s):

if the source has currently no buffer to read from, then
1. it can not pass any data to the RTPSink when the RTPSink requests data.
2. it has to wait idle until there is data to send
(normally there should always be data to send. but this can't always be 
guaranteed if the data comes from a live source or there is some jitter 
in the incoming data stream)

in my current implementation, the getNextFrame method in the source 
simply waits for another thread to be notified that there is new data 
(the whole Live555 event loop runs in a separate thread). this causes 
the whole Live555 event loop to block. we have been using this 
implementation for a while now and it worked more or less. however we 
sometimes had problems with data loss, which might be related to the 
blocking getNextFrame. for example I imagine the RTPSink not being able 
to send packets of data it already has. but it might be also be no 
problem at all.

so my question is:
 - is the getNextFrame method allowed to block?
 - if the answer is NO, then what is the currect way to handle the case 
that the source temporarily can't provide any data?

I believe that a similiar scenario already exists in Live555, which is 
the RTPSource. 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?

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 because if it can't be averted by increasing the queue up to 
a reasonable limit, the only way out is to drop data that can't be 
processed. but there may be other issues too...

so my second question is:
 - is the afterGetting method of a sink allowed to block?
 - if the answer is NO, then what is the correct way to make the sink 
wait idle and then start requesting data again?

one idea I had is to simply stop playback at the sink and restart it 
when the queue has free slots again. at the source, I could do the same, 
just stop the RTPSink and restart it when there is data to process 
again. however the problem here is that when I know that I have run out 
of data, the RTPSink has already requested data (i.e. it has called 
getNextFrame), so I have to fill the buffer with something...

is my current implementation good enough? or is stopping the Live555 
graph the right way to do it? any better ideas?

regards,
fw