RTSP keeplive & video freezing

[dhirwinjr]

All,

I use VLC to view live MPEG4 video from video encoder appliances (such as Optelecom or Coretec). In most cases I view video using multicast but sometimes I need to view unicast video from these encoders using RTSP. Up to now I've been stuck using VLC version 0.8.6d because the best i can it's the last version of VLC where the live video didn't lock up after 15-30 seconds. In all the new versions of VLC (tried versions 1.0.*) the video locks up. I'd really like to get away from using this really old version of VLC but I can't until this RTSP issue is resolved.

When using VLC 0.8.6d I see the following RTSP exchange:

Code: Select all

Sending request: OPTIONS rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTSP/1.0 CSeq: 6 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Server: Optelecom-NKF RTSPServer/1.0 Public: OPTIONS, DESCRIBE, SETUP Sending request: DESCRIBE rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTSP/1.0 CSeq: 7 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 7 Server: Optelecom-NKF RTSPServer/1.0 Content-Type: application/sdp Content-Length: 239 Need to read 239 extra bytes Read 239 extra bytes: v=0 o=- 1272987392 1272987392 IN IP4 10.20.100.90 s=Video: input1 encoder1 transmitter5 m=video 0 RTP/AVP 101 a=control:rtsp://10.20.100.90/video/input1/encoder1/transmitter5 a=rtpmap:101 MP4V-ES/90000 a=fmtp:101 profile-level-id=1 Sending request: SETUP rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RT SP/1.0 CSeq: 8 Transport: RTP/AVP;unicast;client_port=1750-1751 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received SETUP response: RTSP/1.0 200 OK CSeq: 8 Server: Optelecom-NKF RTSPServer/1.0 Session: 429183932;timeout=20 Transport: RTP/AVP;unicast;client_port=1750-1751;server_port=5008-5009 Accept-Ranges: NPT Sending request: PLAY rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTS P/1.0 CSeq: 9 Session: 429183932 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received PLAY response: RTSP/1.0 200 OK CSeq: 9 Server: Optelecom-NKF RTSPServer/1.0 Range: npt=now- MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds t he client's buffer size (65536). 214 bytes of trailing data will be dropped! ################################# # Here the video has started. Then approximately every 20 seconds VLC will send out # a GET_PARAMETER request to the RTSP server. This continues as long as the video # is playing. ################################# Sending request: GET_PARAMETER rtsp://10.20.100.90/video/input1/encoder1/transmi tter5 RTSP/1.0 CSeq: 10 Session: 429183932 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received GET_PARAMETER response: RTSP/1.0 200 OK CSeq: 10 Server: Optelecom-NKF RTSPServer/1.0 Session: 429183932 Sending request: GET_PARAMETER rtsp://10.20.100.90/video/input1/encoder1/transmi tter5 RTSP/1.0 CSeq: 11 Session: 429183932 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received GET_PARAMETER response: RTSP/1.0 200 OK CSeq: 11 Server: Optelecom-NKF RTSPServer/1.0 Session: 429183932 ################################# # Here I manually stop the stream ################################# Sending request: TEARDOWN rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTSP/1.0 CSeq: 12 Session: 429183932 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received TEARDOWN response: RTSP/1.0 200 OK CSeq: 12 Server: Optelecom-NKF RTSPServer/1.0

Here's the RTSP exchange when using VLC 1.0.5:

Code: Select all

Sending request: OPTIONS rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTSP/1.0 CSeq: 6 User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.07) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 6 Server: Optelecom-NKF RTSPServer/1.0 Public: OPTIONS, DESCRIBE, SETUP Sending request: DESCRIBE rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTSP/1.0 CSeq: 7 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.07) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 7 Server: Optelecom-NKF RTSPServer/1.0 Content-Type: application/sdp Content-Length: 239 Need to read 239 extra bytes Read 239 extra bytes: v=0 o=- 1272987392 1272987392 IN IP4 10.20.100.90 s=Video: input1 encoder1 transmitter5 m=video 0 RTP/AVP 101 a=control:rtsp://10.20.100.90/video/input1/encoder1/transmitter5 a=rtpmap:101 MP4V-ES/90000 a=fmtp:101 profile-level-id=1 Sending request: SETUP rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RT SP/1.0 CSeq: 8 Transport: RTP/AVP;unicast;client_port=1750-1751 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) Received SETUP response: RTSP/1.0 200 OK CSeq: 8 Server: Optelecom-NKF RTSPServer/1.0 Session: 429183932;timeout=20 Transport: RTP/AVP;unicast;client_port=1750-1751;server_port=5008-5009 Accept-Ranges: NPT Sending request: PLAY rtsp://10.20.100.90/video/input1/encoder1/transmitter5 RTS P/1.0 CSeq: 9 Session: 429183932 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2010.01.10) Received PLAY response: RTSP/1.0 200 OK CSeq: 9 Server: Optelecom-NKF RTSPServer/1.0 Range: npt=now-

Unlike with the 0.8.6d version VLC does NOT occasionally transmit a GET_PARAMETER request every once in a while. My guess is that the RTSP server will stop transmitting video if it doesn't receive a GET_PARAMETER within a certain period of time (kind of like a keep alive). In the VLC messages window I also get this right as the video locks up:

Code: Select all

main error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 150 ms main error: ES_OUT_RESET_PCR called main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 0%

I tried this against three different encoders (i.e. RTSP servers) and they all behaved the same way (0.8.6d runs fine, later versions of VLC fail). Based on this I would assume that it's an issue with Live555. I've looked at the RTSP specification and there is a mention of using GET_PARAMETER as a way to test client or server liveness ("ping") but it says "may", doesn't say "must".

There was a bug ticket filed here http://webcache.googleusercontent.com/s ... clnk&gl=si and looks like it was resolved. But I don't have access to some of links within the ticket to see how it was resolved or how I should enable it the 1.0.* versions of VLC. Any ideas?

Thanks for any feedback,
Dave Irwin

[packetship]

Hi Dave,

(also in reply to your PM)

I was the original reporter of Bug#1881 which was originally filed because VLC had stopped supporting GET_PARAMETER at all; in the 1.0.x line it does support GET_PARAMETER keepalives but only in certain conditions...

It looks to me like your encoder's RTSP server does not advertise GET_PARAMETER in its OPTIONS response; that is what VLC now uses to determine whether to send GET_PARAMETER as keepalives, because (as I understand it) Darwin Streaming Server doesn't support it and fails badly if it is used. The server really ought to be advertising support of GET_PARAMETER if it requires it for keepalive!

So I'm afraid you'll have to go back to the encoder manufacturer(s) and point this out. It should be trivial for them to fix in the encoder firmware. I can't see VLC changing since what it does is reasonable and navigates a fine course between other broken server implementations.

Best regards

Paul

[dhirwinjr]

Thanks Paul for your response.

Does the RTSP specification specify one way or another how to handle this? The only language I saw in the spec said that using the GET_PARAMETER may be used for the purpose of keepalive but didn't sound like it required it. I haven't contacted the encoder vendor yet but I can imagine push back from them if they feel their RTSP server currently meets spec even if the change required on their part is minor.

Thanks,
Dave

[Rémi Denis-Courmont]

Some servers fail if GET_PARAMETER is used (and they're allowed to do so; GET_PARAMETER is not mandatory). In older VLC versions, GET_PARAMETER was blindly sent which was a bug. Now VLC will only use GET_PARAMETER if it is supported, as specified in the OPTIONS result.

Your server does not claim to support GET_PARAMETER, so VLC won't use it.

[bhoeneis]

Hi!

Would it be possible to make the usage of GET_PARAMETER requests configurable, i.e. the user can explicitly override what has been negotiated with the OPTIONS method, to always (or never) use GET_PARAMETER requests?

This way VLC would provide a workaround for poor server implementations (and only if the user chooses so).

----

BTW:
Looking at the RFC 2326 <http://tools.ietf.org/html/rfc2326>, I could not find anything that would disallow a client to use GET_PARAMETER even if not negotiated. Only if you get a 501, the client should not try again:

"If a server does not support a particular method, it MUST return "501 Not Implemented"
and a client SHOULD not try this method again for this server."

Besides this, a server that fails if getting a GET_PARAMETER (such as Darwin Streaming Server obviously does) is definitely not compliant with RFC 2326 as it must reply with a 501 to any unknown method.

Furthermore I could not find in RFC 2326 that a server is obliged to state, what methods it supports in an OPTIONS request.

[If what I found is correct, this would mean that the current behaviour of VLC (as opposed to the earlier versions) is to help non-compliant server implementations, whereas servers that are RFC 2326 compliant (but just don't send optional stuff) do not work properly with VLC...]

---

It would be great if you could make the usage of GET_PARAMETER at least configurable!

Thanks in advance!

cheers,
Bernie

[Rémi Denis-Courmont]

The server does not list GET_PARAMETER in the OPTIONS Public header. It would be completely idiotic to try.

Sure we could do that. Sure we will NOT do that. Fix your server. Frankly, we have enough bugs of our own to not deal with others.

[bhoeneis]

Thanks for your quick response!

Why would it be idiotic to try, just because the server does not inform about this feature in its "Public" Header Field? (In this case the server [Server: WMServer/9.1.1.3814] does not even send a "Public" Header Field. )

I cannot fix MY server as it is NOT MY server. I am on the client side...

Could you please point me to the place in the source code, and I will try to write a patch (which you might or might not include to the source code later-on, depending on your preferences).

cheers,
Bernie

[bhoeneis]

Below you can find a patch that adds a configuration option to enforce sending GET_PARAMETER for keep-alive, if the user explicitly wants this.

This is a workaround for RTSP servers that are badly behaving (i.e. they do not inform that they need GET_PARAMETER requests for keep-alive, but stop the media stream after a short time if they do not get GET_PARAMETER requests ).

@developers:
Feel free to include the patch (or a variant of it) to the source code as it fits.

(At least a bigger proportion of the VLC user community can be made be happy, if VLC worked with such badly behaving RTSP servers.)

---

After applying the patch, you can find the new setting on:
Tools -> Preferences -> [Show Settings: All] -> Input / Codes -> Demuxers -> RTP/RTSP -> [Always send GET_PARAMETER for keep-alive]
or, alternately, add the following lines to your "vlcrc" config file (on Ubuntu this config file is: ~/.config/vlc/vlcrc ).

Code: Select all

# Always send GET_PARAMETER for keep-alive (boolean) rtsp-force-get-param=1

cheers,
Bernie Hoeneisen <b@hoeneisen.ch>

--

http://ucom.ch/
Tech Consulting for Internet Standardization

Code: Select all

--- vlc-1.0.6/modules/demux/live555.cpp 2010-04-18 15:34:12.000000000 +0200 +++ ../vlc-1.0.6/modules/demux/live555.cpp 2010-07-11 00:31:26.000000000 +0200 @@ -137,6 +137,10 @@ add_string( "rtsp-pwd", NULL, NULL, PASS_TEXT, PASS_LONGTEXT, true ) change_safe() + add_bool( "rtsp-force-get-param", false, NULL, + N_("Always send GET_PARAMETER for keep-alive"), + N_("Always send GET_PARAMETER for keep-alive"), true ) + change_safe() vlc_module_end () @@ -1063,7 +1067,13 @@ if( p_sys->i_timeout <= 0 ) p_sys->i_timeout = 60; /* default value from RFC2326 */ - /* start timeout-thread only if GET_PARAMETER is supported by the server */ + /* Workaround for buggy servers: If configured, override timout-thread behavior + (i.e. force sending GET_PARAMETER even if server does not indicate support) */ + if( var_CreateGetBool( p_demux, "rtsp-force-get-param" ) ) + p_sys->b_get_param = true; + + /* start timeout-thread only if GET_PARAMETER is supported by the server + (or enforced by configuration) */ if( !p_sys->p_timeout && p_sys->b_get_param ) { msg_Dbg( p_demux, "We have a timeout of %d seconds", p_sys->i_timeout );

[Rémi Denis-Courmont]

I thought I made myself clear but to reiterate:
1/ No, we won't add an option for this. There are already enough obscure options in VLC, including in the RTSP stack. This does not solve the problem in any meaningful way. One in a million user would know to use that option to work around a broken RTSP server.
2/ The bug is in the RTSP server. The fix belongs in the RTSP server. The VideoLAN project has enough of its own bugs to cope with.
3/ For servers that don't support GET_PARAMETER (or pretend not to), VLC or rather liblive555 also sends RTCP-RR. So there is no excuse for RTSP server to time out VLC-based clients.

Open-source is not a synonym for working around bug in proprietary software. Quite the opposite - those who make money from their software have no excuse not to fix their bugs.