[FFmpeg-user] rtsp streams stop after ~80 seconds

Tommy Winther tommy at net-comm.dk
Fri Feb 24 10:27:35 CET 2012

Anyone had a chance to look into this?
I have looked into it multiple times and my guess at the moment is this:
(See the tcpdump attached on https://ffmpeg.org/trac/ffmpeg/ticket/945)

In the response to the keep-alive "OPTIONS" request:
RTSP/1.0 200 OK
CSeq: 9
Date: Fri, 27 Jan 2012 20:40:52 GMT
Session: 9791-5;timeout=79
Server: Helix Mobile Server Version (sunos-5.10-sparc64)
(RealServer compatible)
TurboPlay: 1
RealChallenge1: 11a655c999a75aa0d8473e04a446486e
StatsMask: 8

the server responds with:
+.......Ja.;.N.).E.5k.y....-.f...{....K....T....+.OPTIONS * RTSP/1.0
CSeq: 1
Session: 9789-3

and then the CSeq: 1 at the end of the response is incorrectly parsed by
ffmpeg as a header and thus overwrites the current rt->seq.
Probably the keep-alive request sent in rtspdec.c should make sure that 
the return_on_interleaved_data is set to 1 in the ff_rtsp_read_reply(..)
method in rtsp.c - then we avoid parsing the CSeq: 1 as a header.

Does this sound reasonable?


søn, 19 02 2012 kl. 19:35 +0100, skrev Tommy Winther:
> Hey, I'm having problem with rtsp streams for a specific provider.
> The streams stop after ~80 seconds.
> This is an example stream url, but it only works for a short while and
> for customers of the provider.
> rtsp://
> With the attached patch - a one-line change - 
> the streams plays correctly, but I'm wondering if this is just a
> workaround for a different problem.
> It looks like the keep-alive is sent using an incorrect session id,
> which causes the stream to stop.
> I have also opened a trac ticket a while back with tcpdump of the
> communication without the patch applied.
> https://ffmpeg.org/trac/ffmpeg/ticket/945
> Br.
> Tommy

More information about the ffmpeg-user mailing list