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

Ronald S. Bultje rsbultje
Wed Mar 24 20:52:31 CET 2010


Hi,

On Wed, Mar 24, 2010 at 2:44 PM, Martin Storsj? <martin at martin.st> wrote:
> On Wed, 24 Mar 2010, Sam Gerstein wrote:
>> 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.
[..]
> 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.
>
> 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.

Timeout is fine, this patch is a bit flaky. Ideally we'd have a define
or maybe even a configurable option (10s initial value sounds
reasonable, so 100 loops of 100ms) that'd cause a return of
AVERROR(ETIME) (it's not an EOF, so AVERROR_EOF sounds problematic).
Other than that, RTCP/Bye support is lacking, patch welcome. That'd
return AVERROR_EOF.

Ronald



More information about the ffmpeg-devel mailing list