Wowza Community

VLC Mobile Streaming How-To (Seeking Alternative or Solution)

I’m the sole IT force behind a small endeavor to provide live mobile streaming to BlackBerry phones. We’ve spent the past few months trying to use VLC as a full-time transcoding system. Our current setup uses Windows 2008 Server machines running (mainly) VLC 1.1.5, transcoding 10 streams each from primarily Windows Media format to mobile h264/mp4a RTSP streams. Each instance uses a batch file (as shown below), triggered and run through Windows Task Scheduler as a service. When it runs, the system works wonderfully. The streams are good quality at a reasonable bitrate, and play smoothly on 3G. Unfortunately, VLC in this capacity is about as stable as Windows ME. No matter what version we use, including the most recent 1.1.5 version, trying to transcode a stream always results in three eventual 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:

 :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 it 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 sticks 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 the latest version cannot properly transcode some source streams that older versions have no trouble with (VP6 Shoutcast streams, for example).

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. Other than MComm Transcode’s $8000+ software solution, I’ve yet to find anything else that can live transcode Windows Media streams to h264. I now 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.

I’m hoping someone here can offer some ideas or share their own results. If there were a stable build of VLC, it would be perfect in this capacity. It seems unlikely that there are only two possible ways of accomplishing this task. One would think that a simple ffmpeg-based application which transcodes live streams to 3GP output would have been developed somewhere. I’m also happy to answer any questions anyone may have about our setup.

Interesting stuff.

I did a quick search using Google and there does appear to be a version of ffmpeg which supports the mms protocol, looks like you have to add a patch to it, so might be worth a try compiling it and see if it fairs any better ?

[edit]My experience tells me a *nix based platform may fair better, but definately be easier to automate the management side of things, such as process watching, memory usage and running processes etc. This is a huge leap if all the skills are Windows based.[/edit]

Shamrock

I use VLC on Windows 7 64

Richard

Hi use LINUX server for transcode, I have 40 channels doing similar task, running VLC into Linux box and this work well… possible the issue with VLC is with the Windows 7 version.

how about using ffmpeg without mms.

You should be able to configure Windows Media to support RTSP then you could use ffmpeg out of the box, depending on the codec support of course

example being

ffmpeg -re -i rtsp://<windows media ip>/<publishing point name> -strict experimental -acodec aac -ab 32000 -ar 44100 -f rtsp rtsp://<wowza ip>/<app name>/myStream_32.sdp

now this is a very basic example, produces a 32k aac output into Wowza, and ffmpeg does not support spitting codecs, so the source would need to be audio only, rather than say a playlist/live of audio/video files.

it seems pretty stable, but of course would need some work yourside and not tried it under Windows OS.

Shamrock

Hi use LINUX server for transcode, I have 40 channels doing similar task, running VLC into Linux box and this work well… .

Could you give some hints regarding verstion of VLC and parameters used to run smoothly?

Interesting stuff.

I did a quick search using Google and there does appear to be a version of ffmpeg which supports the mms protocol, looks like you have to add a patch to it, so might be worth a try compiling it and see if it fairs any better ?

[edit]My experience tells me a *nix based platform may fair better, but definately be easier to automate the management side of things, such as process watching, memory usage and running processes etc. This is a huge leap if all the skills are Windows based.[/edit]

Shamrock

I’m primarily Windows / OSX savvy, so Linux will be a bit a hurdle. If anyone can verify that VLC is actually stable on that platform, though, I’m willing to learn. Patching and compiling code seems to be a nightmare I’ve never been successful at under Windows.

I use VLC on Windows 7 64

Richard

Yes, but do you use it 24/7 to live transcode? That’s where the instability comes in.

how about using ffmpeg without mms.

You should be able to configure Windows Media to support RTSP then you could use ffmpeg out of the box, depending on the codec support of course

example being

ffmpeg -re -i rtsp://<windows media ip>/<publishing point name> -strict experimental -acodec aac -ab 32000 -ar 44100 -f rtsp rtsp://<wowza ip>/<app name>/myStream_32.sdp

now this is a very basic example, produces a 32k aac output into Wowza, and ffmpeg does not support spitting codecs, so the source would need to be audio only, rather than say a playlist/live of audio/video files.

it seems pretty stable, but of course would need some work yourside and not tried it under Windows OS.

Shamrock

This would work if the source stream were under my control; unfortunately it isn’t. We’re stuck with mms:// format input.