This week, in Orvieto, Italy, there was OOoCon 2009 and the lscube team (also known as “the rest of the feng developer beside me”) was there to handle the live audio/video steaming.
During the preparations, Luca called me one morning, complaining that the new RTSP parser in feng (which I wrote almost single handedly) refused to play nice with the VLC version shipped with Ubuntu 9.04: the problem was tracked down to be in the parser for the Range header, in particular in the normal play time value parsing: the RFC states that I’m expecting a decimal value with a dot (.) as the separator, but VLC is sending a comma (,) which my parser is refusing.
Given Luca actually woke me up while I was in bed, it was a strange presence of mind that let me ask him which language (locale) was the system set in: Italian. Telling him to try using the C locale was enough to get VLC to comply with the protocol. The problem here is that the separators for decimal places and thousands are locale-dependent characters; while most programming languages obviously limit themselves at supporting the dot, and a lot of software likewise use that no matter what the locale is (for instance right now I have Transmission open and the download/upload stats use the dot, even though my system is configured in Italian). Funny that this problem came up during an OpenOffice event, given that’s definitely one of the most known software that actually rely (and sometimes messes up) with that difference.
To be precise, though, the problem here is not with VLC by itself: the problem is with the live555 (badly named media-plugins/live in Gentoo) library, which provides the generic RTSP code for VLC (and MPlayer). If you ever wrote software that dealt with float to string conversion you probably know that the standard printf()-like interface does not respect locale settings; but live555 is a C++ library and it probably uses string streams.
At any rate, the bug was known and fixed already in live555, which is what Gentoo already have, and the contributed bundled libraries of VLC have (for the Windows and OS X builds), so those three VLC instances are just fine, but the problem is still present in both the Debian and Ubuntu versions of the package which are quite outdated (as xtophe confirmed). Since the RFC does not have any conflicting use of the comma in that particular place, given the extension of the broken package (Ubuntu 9.10 also have the same problem), we decided for working it around inside the feng parser, and accepting the comma-separated decimal value instead.
From this situation, I also ended up comparing the various RTSP clients that we are trying to work with, and the results are quite mixed, which is somewhat worrisome to me:
- latest VLC builds for proprietary operating systems work fine (Windows and OS X);
- VLC as compiled in Gentoo also work fine, thanks Alexis!
- VLC as packaged for Debian (and Ubuntu) uses a very old live555 library; the problem described here is now worked around, but I’m pretty sure it’s not the only one that we’re going to hit in the future, so it’s not a good thing that the Debian live555 packaging is so old;
- VLC as packaged in Fedora fails in many different ways: it goes in a loop for about 15 minutes saying that it cannot identify the host’s IP address, then it finally seem to be able to get a clue, so it’s able to request the connection but… it starts dropping frames, saying that it cannot decode and stuff like that (I’m connected over gigabit lan);
- Apple’s QuickTime X is somewhat strange; on Merrimac, since I used it to test the HTTP tunnel implementation it now only tries connecting to feng via HTTP rather than using RTSP; this works fine with the branch that implements it but fails badly in master obviously (and it doesn’t look like QuickTime gets the hint of changing to RTSP protocol); on the other hand it works fine on the laptop (that has never used the tunnel in the first place), where it uses RTSP properly;
- again Apple’s QuickTime, this time on Windows, seems to be working fine.
I’m probably going to have to check the VLC/live packaging of other distributions to see how many workaround for broken stuff we might have to look out for. Which means more and more virtual machines, I’ll probably have to get one more hard drive by this pace (or I could probably replace one 320G drive with a 500G drive that I still have at home…). And I should try totem as well.
Definitely, RTSP clients are a hell of a thing to test.
Uh what? printf _does_ respect the locale setting, very unfortunately, just like scanf etc.Which is the reason why MPlayer just doesn’t use setlocale anymore.Without a portable way to make it ignore locale nor a thread-safe way to unset it, that basically means that if you are serious you simply can’t use scanf, printf, … in any library at all except for debug output (or other things that will be only for direct consumption by the user).You often can’t even use it reliably for command-line option parsing, e.g. in MPlayer “,” is used as a separator – if it also acts as a decimal separator some things become impossible to parse unambiguously.
I spy…Real Time Streaming Protocol protocolBut yes, multimedia streaming is full of surprises like that.
Great post!When do you code us a vlc plugin that replace this live555 mess?
Reimar, a quick test here tells me that even after a @setlocale()@ call, @fprintf()@ uses the dot for the @%f@ specification… But yes in general it’s quite a bit of a problem, the locale-dependency about that.jb… give me time…
Sure you used setlocale correctly? Sample code:#include <stdio.h>#include <locale.h>int main(void){ setlocale(LC_ALL, “”); printf(“%fn”, 1.234); return 0;}LC_ALL=de_DE ./test 1,234000(note in particular that you must use “”, not NULL, NULL only queries without setting locale)
The includes are supposed to be stdio.h and locale.h, and fprintf(stderr, …) behaves the same as printf of course.
_Goes to hide in a corner._I forgot about the NULL/”” issue and used NULL in the test, sorry!
Hehe, I first tried it with NULL, too, and when it didn’t work decided to actually look at the man page.Perfect example why it’s a good idea to read up the documentation before you use a non-everyday function in production code 🙂
Did you file a bug with Debian?
No, Zeev… but xtophe (from VLC) is the one responsible for that and he knows live555 is outdated.