My experiences with VLC (All windows versions)

[CharredPC]

I thought I'd share my experience with using VLC, from a different perspective. I am part of a little start-up company that offers mobile streaming versions of public IPTV streams. We looked into various transcoding softwares, and the only RTSP transcoding solution we found came with a $8000+ price tag; this forced us to try finding a free solution. What we came up with was VLC and Darwin Streaming Server. The initial tests were very promising. Our dedicated servers (quad core machines running Windows Server 2008) would end up being our only cost; that was too tempting not to try it out.

It became my job to find a workable implementation of this. 1.1.4 simply wouldn't work, since it crashes nonstop when switching / ending / dealing with RTSP streams (which some of our source feeds are). The public internet consensus seems to be that 0.8.6 is the best streamlined, no-frills, lightweight stable version of VLC before the GUI 'fluff' and bloat; 1.0.5 is the next best thing, offering stability with the newer features and increased compatibility; 1.1.2 or 1.1.3 is the best usable latest version. I ended up testing them all in our transcoding setup.

0.8.6 unfortunately doesn't appear modern enough to create the type of x264/mp4a rtsp/sdp mobile streaming format we need, nor can it accept php stream links (which is what some of our sources use). I therefore set things up using 1.1.3. This worked fairly well after working out the various command line settings, but had a tendency to stop transcoding for no discernible reason. The application still responded, but the process just stopped. I got the same results for 1.1.2. Switching to 1.0.5 seemed to solve this, after tweaking the command line once again to be compatible. Using this setup, one server was able to handle about seven channels before hitting 90% cpu load. The $8000+ transcoding software makers claimed we would be able to run 12-24 streams per quad core machine, so seven was a slightly disappointing. But the price difference was worth it!

After a while, the constant manual restarting of VLC instances got tiresome, so I looked into how to automate it. This led to another restructuring of the command line we were using. On a side note, let me join in the voices here saying that while I completely understand the security reasons behind the VLC team removing the acceptance of command line instructions within playlists, someone should really compile a version that does it. In trying to find an older version that still allowed this but is compatible with our streaming, I tried 0.9.4. While it didn't allow playlist commands, I was shocked to notice that each instance used only half the resources of 1.0.5. With a couple more tweaks, our command line worked fine with this older version, produced the same results- but now we're currently running ten channels at about 60% cpu load per server.

It did come with a price. 0.9.4 doesn't appear to be quite as stable as 1.0.5. It's not bad, but there have been a few instances where the wrong source feed triggers a complete crash, or is simply incompatible. For that reason, we still use 1.0.5 on the occasional problematic stream. Hoping for a happy medium, I did also try 9.9.9; it instantly crashed with our command line, so I didn't pursue it further. Now I have each instance of VLC set to close if the stream disconnects, Windows Task Scheduler set to restart them as needed (the source stream url's are dynamic and expiring, so unfortunately can't be entered into a playlist or put on loop- a separate headache in and of itself), and a full nightly kill of all VLC processes (in case of lockups, freezing, multiple instances, etc). Hardly a robust or professional solution, but for our current limited budget and short time frame, it does function. When we get the time, I may try a Linux/FFMPEG solution instead and see if that works better.

I'd like to thank the makers of VLC for a versatile, free, useful (if confusing) product. In my experience with software revisions, there isn't usually this Russian Roulette of versions, each having a shining point not found in others. If someone were to take the the stability of 1.0.5 (few if any random crashes, switches RTSP streams and opens php url's fine), the streamlined small no-nonsense executable style of 0.8.6 (opens instantly, no repetitious font caching or interface 'fluff'), the low cpu use of 0.9.4 (newer build = double the cpu use for the same results? ), and the updated codec/source (FFMEG) compatibility of the 1.1.x line, they would have the ultimate application. I know I'd pay money for it. Hrm, maybe that's all the $8,000+ transcoding software vendor did...

If anyone has questions or input/advice on our setup, I'd be happy to collaborate and share.

[CharredPC]

Here's an update on my streaming experiences, after a few months of trying to use VLC as a full-time transcoding system. No matter what version we use, including the most recent 1.1.5 version, trying to transcode a stream results in three issues:


Problem 1) The process crashes, VLC closes. The only "fix" I could come up with was running VLC from a batch file, in which I created a loop that restarts the command line each time it closes. For example:

Code: Select all

:Start del C:\Users\Administrator\AppData\Roaming\vlc\crashdump call "C:\Program Files\VideoLAN\VLC\vlc.exe" "mms://sourceurl.com/stream.wmv" --sout="#transcode{width=320,height=240,venc=x264{bframes=0,nocabac,crf=24,profile=baseline,level=3.0,vbv-maxrate=140,vbv-bufsize=1000,keyint=36,fps=18},vcodec=h264,vfilter=canvas{height=240,width=320,aspect=16:9},vb=110,audio-sync,acodec=mp4a,ab=34,channels=1,samplerate=44100}:rtp{mp4a-latm,dst=127.0.0.1,port=1020,sdp=file:///C:\streams\vlc.sdp}" goto Start

This will automatically reboot VLC and restart the transcoding process if saved to a .cmd file. The crashdump line is needed because inexplicably VLC offers no way to turn off crash reporting. Unless you want the process to wait until you click on a pop-up each time (or hang permanently if running this as a service, as we do), you'll need to add this line. It's also likely specific to each PC, so will need to be edited. Of course this doesn't fix the crashing, but at least it will restart quickly on its own each time.


Problem 2) The process locks up, using all cpu time available. There's no real fix for this either, and I couldn't even come up with a workaround. Once several instances do this, it can bring all other encoding processes to a grinding halt, as the defunct threads steal all cpu cycles. The only way to minimize the damage at all is to use a program such as Process Lasso, which can automatically lower the priority of 'runaway' threads. I was hoping to find an application that automatically ended them instead, but haven't found one. Therefore this requires constant manual babysitting, watching cpu usage, and clicking End Task every time one goes over 20% cpu (how it shows up on a quad core server).


Problem 3) The process locks up, and doesn't respond at all. In this case, the instance uses no cpu, but doesn't close either- it's simply frozen. When running in GUI mode, this can be spotted by the stopped transcoding timer (if the source sends a starting time stamp). When run as a service, you just have to again babysit the task manager, looking for a 0% cpu instance to End Task.


These are the three most major issues, though we've run into others. Occasionally a process will also start eating up memory while no longer functioning (spotted in task manager by the ridiculously high- and climbing- memory usage). Other times it will seem to be functioning, but constantly buffer every few seconds on the client side until restarted. And of course multiple versions (0.9.6, 1.0.5, 1.1.5) have to be kept installed since newer versions cannot properly transcode some source streams that older versions have no trouble with.

Our current setup uses Windows 2008 Server machines running (mainly) VLC 1.1.5, transcoding 10 streams from mostly Windows Media format to mobile h264/mp4a and serving it through Darwin Streaming Server. Each instance uses a batch file (as shown above), triggered and run through Windows Task Scheduler as a service. When it runs, the system works wonderful. The streams are good quality at a reasonable bitrate. Unfortunately, VLC in this capacity is about as stable as Windows ME. Even with constant supervision, there's still dozens of manual restarts required daily, adding up to a very inconsistent, undesirable end-user result... as well as needing a 24/7 attendant. Certain source streams trigger these effects quicker than others, but they happen on each instance eventually. I've been forced to come to conclusion that while VLC can't be beat as a marvelous application for playing nearly any media file, its transcoding capability is more of an unfinished side-feature that isn't meant for long-term use. Surprisingly, aside from the $8000+/4 channel software solution I mentioned in my previous post, I've yet to find anything else that can live transcode Windows Media streams to h264. I have a month to find an alternative, or the transcoding we're offering will be shut down. VLC simply does not work as a reliable solution for full-time streaming.

Again, I welcome others' comments, suggestions, and questions, either here or in private message. If the VLC team feels my next month's worth of server logs would be helpful in stabilizing their product, I'll happily turn them over.

[Sébastien Escudier]

about the crash when you stop a RTSP stream in 1.1.4, it is fixed in 1.1.5
For the other things, the bugs you find in versions < 1.1 will never be fixed because these versions are not maintained anymore.
For the problems you have in latest versions, you should create a separate topic for each, in the right forum section, or fill a bug report.

[CharredPC]

about the crash when you stop a RTSP stream in 1.1.4, it is fixed in 1.1.5
For the other things, the bugs you find in versions < 1.1 will never be fixed because these versions are not maintained anymore.
For the problems you have in latest versions, you should create a separate topic for each, in the right forum section, or fill a bug report.

I'm aware that the major RTSP stopping bug did get resolved in 1.1.5 (though I've still seen 1.1.5 crash or lock up when trying to stop or exit while playing an RTSP stream). I'm also aware that previous versions are not maintained. No offense, but I've seen how successful new threads are, especially with the type of long-term stability problems I've described. They're hard to diagnose, and would end up permanently unanswered on the fifth page after a week, like questions about increasing volume during transcoding or anything else without a quick, easy answer.

[Sébastien Escudier]

I'm aware that the major RTSP stopping bug did get resolved in 1.1.5 (though I've still seen 1.1.5 crash or lock up when trying to stop or exit while playing an RTSP stream).

I would be interested if you find a way to reproduce it easily, because I corrected this bug in 1.1.4

No offense, but I've seen how successful new threads are, especially with the type of long-term stability problems I've described. They're hard to diagnose, and would end up permanently unanswered on the fifth page after a week, like questions about increasing volume during transcoding or anything else without a quick, easy answer.

Unfortunately, some bugs are hard to find, especially when it's hard to reproduce.
So you can create a post, and if a developer is interested maybe he will work on your bug. Or you can try to solve it yourself (if you know how to code)

[VLC_help]

If you know how to use gdb, you can provide quite detailed crash backtrace which can get the bugs fixed easier.

[CharredPC]

If you know how to use gdb, you can provide quite detailed crash backtrace which can get the bugs fixed easier.

I'm not familiar with GDB, but if you can direct me to any documentation on how to set it up in a Windows environment, I'd be happy to do so. VLC would be an essentially perfect product if it were stable.

[Sébastien Escudier]

you'll need a debug version of vlc.
And gdb on windows is not easy to use. (I never had nice backtraces on windows).
Much simpler on linux.

[VLC_help]

http://nightlies.videolan.org/build/win32/?C=M;O=D debug versions can be downloaded there (branch is 1.1.x). For gdb
viewtopic.php?f=14&t=84430&p=279282&hilit=gdb#p279282