[FFmpeg-devel] rtsp.c udp_read_packet() fails to return when stream ends, simple fix

[Luca Barbato]

On 03/24/2010 07:44 PM, Martin Storsj? wrote:
> Hi,
> 
> On Wed, 24 Mar 2010, Sam Gerstein wrote:
> 
>> I've seen this discussed here and there, but not submitted as a patch; it's
>> simple enough that I'm proposing it, and hoping someone familiar with the
>> module will review and comment.  This solution solves the problem I have,
>> but I wonder if it would be problematic in case of, eg. a flaky connection.
>>
>> The problem:
>> when udp_read_packet calls select() to look for new data on its sockets, it
>> only handles the case where some socket signals.  Non-positive return values
>> from select() are ignored, ie. timeouts are ignored and the function
>> continues to loop looking for data.
>>
>> The trivial solution:
>> {see patch below}
>>
>> Questions:
>> -Is there a case where we would like to continue looping when a timeout
>> occurs?  a flaky connection?
>>   - if so, how about making a fixed number of tries before giving up?
>> -Should the timeout be adjusted from its current value of 100ms?
> 
> First and foremost - the timeout is used for rechecking url_interrupt_cb() 
> regularly, so we can't increase it arbitrarily. Instead, an "end of 
> stream" timeout could be checked separately from the select() timeout.
> 
> On to the actual probem - do you suggest that not receiving any RTP packet 
> for x seconds should be interpreted as end of stream? What would be a 
> suitable timeout for this? In order to handle non-perfect network 
> conditions, I'd say this should be on the order of tens of seconds? But 
> generally, this may be a good idea.
> 
> What's the proper way of signalling end of stream, by the way? A quick 
> test with DSS here shows that the server sends a RTCP BYE packet and 
> closed the RTSP control connection, but this happens only 50-100 seconds 
> after the stream finished. An RTCP BYE packet can be missed of course, so 
> some kind of timeout probably is a good fallback.

Other implementations keep sending rtcp bye and then close their side if
they don't get an rtsp TEARDOWN then.

> When using RTSP, the control connection may also timeout on the OS level, 
> if the connection gets closed/broken, but a timeout for packets received 
> may also be a good idea. And for a pure RTP stream initialized from a 
> local SDP file, there's no control connection, so this would be needed 
> indeed.

the local sdp stuff is an hack...

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero