RTSP stream support broken for some RTSP servers

[grzesiekb]

Hello.

We are developing video analysis software, and using FFMPEG as back-end library.
Few months ago everything was working fine - we are using IP Cameras, gathering data via RTSP stream.

Few days ago we started next stage of development and it suddenly turned out that something is wrong - connection with remote IP camera couldn't be handled properly.

After few days of tracking this problem we found it in FFMPEG (commit 229e2631be528c595650a7568c1d4df8af9c4944):

commit 229e2631be528c595650a7568c1d4df8af9c4944
Author: Martin Storsjö <martin@martin.st>
Date:   Wed Mar 30 23:35:28 2011 +0300

    rtsp: Use GET_PARAMETER for keep-alive for generic RTSP servers

    According to the RFC, GET_PARAMETER should be used for
    this, and according to a report from Tim Ouellette,
    OPTIONS doesn't work for keeping the connection alive for some
    servers. Also, live555 uses GET_PARAMETER for this purpose.

    Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This change breaks RTSP support for some servers (tested on few IP cameras).

In our application connection is lost after approximately 30 seconds (probably depending on rtsp server implementation).

strace:

recvfrom(3, 0x7fffdcf8513f, 1, 0, 0, 0) = -1 ECONNRESET (Connection reset by peer)

In my opinion something is wrong there, because live555 + vlc is working without problems.

This problem is also present in 0.6.90-rc0.

Latest working version is da3534b01e00502b202ed3f51ffde12866e5111d.
I hope this will help other people who have same problem with rtsp stream handling.

Anyway - thanks for great work with FFMPEG !

Regards,

Grzegorz Bizon
ntsn.pl software development
​http://ntsn.pl/en

[compn]

any chance you have a sample url that shows the problem?

[grzesiekb]

Sorry, currently we don't have camera with remote access available. But I can supply additional information if you tell me what you require.

Regards,

Grzegorz Bizon
​http://ntsn.pl/en

[Martin Storsjö]

If we can't get access to test things out ourselves, a pcap capture of both VLC and libavformat trying to play back the stream would be very helpful.

As I wrote in the commit msg, VLC/Live555 should behave the same way, as far as I can read the VLC/Live555 source - ​http://git.videolan.org/?p=vlc/vlc-1.1.git;a=blob;f=modules/demux/live555.cpp;hb=master#l1128 - shows that they call getMediaSessionParameter, which sends a GET_PARAMETER request.

[grzesiekb]

Replying to mstorsjo:

If we can't get access to test things out ourselves, a pcap capture of both VLC and libavformat trying to play back the stream would be very helpful.

Attached above. I removed frame data from files. If you want complete files I can send them on mailbox (large files).

VLC version: 1.1.7-3

Regards,

Grzegorz Bizon
​http://ntsn.pl

[Martin Storsjö]

My wireshark doesn't seem to be able to display anything from the files past the removed frame data - what application did you use to remove the data?

After taking a closer look at things, it appears that VLC only sends these keep-alive requests if the server explicitly replied that it supports GET_PARAMETER, ​http://git.videolan.org/?p=vlc/vlc-1.1.git;a=blob;f=modules/demux/live555.cpp;hb=master#l1081 ​http://git.videolan.org/?p=vlc/vlc-1.1.git;a=blob;f=modules/demux/live555.cpp;hb=master#l562. I've asked Tim Ouellette to test my patch to make sure it doesn't break his setup.

[grzesiekb]

Hello again.

For telling truth - I used vim :). I include summary of communication below, I think it is quite clear:

VLC (binary data and cseqs etc - skipped):

> OPTIONS rtsp://192.168.1.64 RTSP/1.0
> User-Agent: LibVLC/1.1.7 (LIVE555 Streaming Media v2010.04.09)

< RTSP/1.0 200 OK
< Public: DESCRIBE, PLAY, SETUP, TEARDOWN

> DESCRIBE rtsp://192.168.1.64 RTSP/1.0
> Accept: application/sdp
> User-Agent: LibVLC/1.1.7 (LIVE555 Streaming Media v2010.04.09)

< RTSP/1.0 401 Unauthorized
< WWW-Authenticate: Basic realm="/"


> DESCRIBE rtsp://192.168.1.64 RTSP/1.0
> Accept: application/sdp
> Authorization: Basic [HASH]
> User-Agent: LibVLC/1.1.7 (LIVE555 Streaming Media v2010.04.09)

< RTSP/1.0 200 OK
< Content-Type: application/sdp
< Content-Length: 455
< v=0
< o=- 1109162014219182 1109162014219192 IN IP4 x.y.z.w
< s=Media Presentation
< e=NONE
< c=IN IP4 0.0.0.0
< t=0 0
< a=range:ntp=now-
< a=control:*
< m=video 0 RTP/AVP 96
< a=rtpmap:96 MP4V-ES/90000
< a=fmtp:96 profile-level-id=8; config=000001B0F5000001B50900000100000001200886C40013628087828C;
< a=range:ntp=now-
< a=control:trackID=1
< a=Media_header:MEDIAINFO=494D4B48010100000400030000000000000000000000000000000000000000000000000000000000;
< a=appversion:1.0

> SETUP rtsp://192.168.1.64/trackID=1 RTSP/1.0
> Transport: RTP/AVP;unicast;client_port=53426-53427
> Authorization: Basic [HASH]
> User-Agent: LibVLC/1.1.7 (LIVE555 Streaming Media v2010.04.09)

< RTSP/1.0 200 OK
< Session:         53025553
< Transport: RTP/AVP;unicast;client_port=53426-53427;server_port=8202-8203;ssrc=3FBF092C

> PLAY rtsp://192.168.1.64 RTSP/1.0
> Session: 53025553
> Range: npt=0.000-
> Authorization: Basic [HASH]
> User-Agent: LibVLC/1.1.7 (LIVE555 Streaming Media v2010.04.09)

< RTSP/1.0 200 OK
< Session:         53025553
< Range: npt=now-
< RTP-Info: url=trackID=1;seq=49035

[ FRAME DATA ]

> TEARDOWN rtsp://192.168.1.64 RTSP/1.0
> Session: 53025553
> Authorization: Basic [HASH]
> User-Agent: LibVLC/1.1.7 (LIVE555 Streaming Media v2010.04.09)

< RTSP/1.0 200 OK
< Session: 53025553

AVFormat:

> OPTIONS rtsp://192.168.1.64:554 RTSP/1.0

< RTSP/1.0 200 OK
< Public: DESCRIBE, PLAY, SETUP, TEARDOWN

> DESCRIBE rtsp://192.168.1.64:554 RTSP/1.0
> Accept: application/sdp

< RTSP/1.0 401 Unauthorized
< WWW-Authenticate: Basic realm="/"

> DESCRIBE rtsp://192.168.1.64:554 RTSP/1.0
> Accept: application/sdp
> Authorization: Basic [HASH]

< RTSP/1.0 200 OK
< Content-Type: application/sdp
< Content-Length: 455
< v=0
< o=- 1109162014219182 1109162014219192 IN IP4 x.y.z.w
< s=Media Presentation
< e=NONE
< c=IN IP4 0.0.0.0
< t=0 0
< a=range:ntp=now-
< a=control:*
< m=video 0 RTP/AVP 96
< a=rtpmap:96 MP4V-ES/90000
< a=fmtp:96 profile-level-id=8; config=000001B0F5000001B50900000100000001200886C40013628087828C;
< a=range:ntp=now-
< a=control:trackID=1
< a=Media_header:MEDIAINFO=494D4B48010100000400030000000000000000000000000000000000000000000000000000000000;
< a=appversion:1.0

> SETUP rtsp://192.168.1.64:554/trackID=1 RTSP/1.0
> Transport: RTP/AVP/UDP;unicast;client_port=5000-5001
> Authorization: Basic ...


< RTSP/1.0 200 OK
< Session: 1130582642
< Transport: RTP/AVP/UDP;unicast;client_port=5000-5001;server_port=8208-8209;ssrc=3FBF092C

> PLAY rtsp://192.168.1.64:554 RTSP/1.0
> Range: npt=0.000-
> Session: 1130582642
> Authorization: Basic ...

[ FRAME DATA ]

> GET_PARAMETER rtsp://192.168.1.64:554 RTSP/1.0
> Session: 1105072745
> Authorization: Basic ...

[ CONNECTION RESET BY PEER ] 

Don't use this summary as strong reference - I removed some important parts (like authentication problems with VLC) - you can read those pcap files in Vim for example. As I said - I can send complete files on email.

It is clear that VLC + Live555 doesn't send GET_PARAMETER and GET_PARAMETER is problem in this case.

Regards,

Grzegorz Bizon
​http://ntsn.pl

[Martin Storsjö]

Yeah, I also tried vim, but I had wanted to see the packet timings too, which weren't really obvious when watching the binary data directly :-) Does the attached patch fix the issue for you?

[grzesiekb]

I will try it as soon as possible and then let you know.

Grzegorz Bizon

[grzesiekb]

Replying to mstorsjo:

Does the attached patch fix the issue for you?

Yes. Everything is working now. Thanks for great work !

Patch is applicable on 0.6.90-rc0 (with small, 1 line offset).

Regards,

Grzegorz

[Michael Niedermayer]

Ive pulled Martins patch amongth others in.
thx to both Martin for the patch and Grzegorz for the report.