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

Sam Gerstein sgerstein
Wed Mar 24 21:16:06 CET 2010


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

That was my conclusion, yes.  I think the alternative would be to
require applications using the library to have a monitor thread that
would enforce its own idea of end-of-stream timeout, which seems
overly complex.

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

Yes, BYE packet seems to be the way to signal end-of-stream.. an
interesting discussion of it here (haven't researched it further):
http://tools.ietf.org/html/draft-zeng-mmusic-rtsp-announce-01


On Wed, Mar 24, 2010 at 3:52 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 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.

I don't know what a reasonable default value is, but I'm happy to go
with 10s.  I agree that the initial approach is flaky :)
I'll implement a configurable timeout, and maybe look at BYE support.
Thanks,
Sam



More information about the ffmpeg-devel mailing list