The VideoLAN Forums

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:
Here's the RTSP exchange when using VLC 1.0.5:
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:
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

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

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

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.

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

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.

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

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 ).
cheers,
Bernie Hoeneisen <b@hoeneisen.ch>

--

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

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.