VLC and Wowza sitting in a tree…

…. K-I-S-S-I-N-G.. 🙂

So as I’ve told you before, it’s been a busy few months and a lot has been going on. Currently working on a project for a client where we need to capture Multicasted IPTV Header, transcode it and then broadcast it to mobile terminals (iPhone’s, Android’s and older terminals as well – 3gpp).

It’s been an interesting time trying to figure out how to get VLC to jump through hoops and make it work together with Wowza, without getting a lot of qualityloss on the way.
During the testingphase of the project, about the same time as I was testing Wowza Media Server 3 Preview, we tried out the transcoding addon from Wowza. It might have gotten better in handling stuff since the preview I did but since we planned on being done BEFORE the release of Wowza Media Server 3 – we decided against using it.

Enter VLC Media Player

My readers from before will know that I’m sort of a *nix-nerd and as such I ‘refuse’ to use other operatingsystems if I can help it. So the operating systems on the below setup is CentOS 6 straight through. And after a few hours, more like a day, to get VLC to compile into the version I needed –  I actually gave up and went out hunting. And found, precompiled, versions of what I needed out there on the net. Installed and whammo.

Running VLC from commandline with a ‘cfg’-file is an interesting thing. Documentation, that I could find, are scarse. I’ll give you an example below of how I configured one of the channels, and told VLC to pick up the multicasted ts-stream and then send it on to Wowza.
[pre_code]
new channel1 broadcast enabled
setup channel1 option program=480
setup channel1 input “udp://@127.0.0.1:1112″
setup channel1 output #duplicate{dst=”transcode{venc=x264
{keyint=60,profile=baseline,level=3.0,nocabac},vfilter=
canvas{width=480,height=270,aspect=16:9},vcodec=x264,
vb=416,scale=1.0,acodec=mp4a,ab=64,channels=1,samplerate=
44100}”,select=”program=480″}:duplicate{dst=rtp{mux=ts,
dst=172.16.1.2,port=40010,ttl=3},select=”program=480″}
control channel1 play
[/pre_code]

So what am I doing? In short… setting up a new channel, telling the channel that multicast programID we’re looking for is 480 and that the multicast is at localhost UDP port 1112. The output should be double, in effect, I want to transcode it and then send the transcoded material on to another machine and a certain port on that machine. The I tell it to start doing it’s job. Then rinse and repeat, in this case, 7 times with double encodings on both.. so the above, 14 times per encoder.

If we put it mildly, the processing-power of these machines are nice. Dual processors with 12 cores each and 24 gigs of ram. Still.. the VLC-process gulps up about 600% of the CPU.. which looks weirder than it is.. the load? about 3 when humming along…

Wowza backend configuration

The “backend”-Wowza server is roughly half in size and processingpower than the encoders (and the frontend wowza). This is mainly due to the fact that it doesn’t get very much to do. It receives all the encoded material on it’s different ports. I’ve set it up as a liveorigin, this is mainly because I want the frontend to be scalable in an easy fashion. Adding more hardware and frontend streamingservers is quite easy if you use Wowza’s own loadbalancing solution for it. That’s the main reason why I set up origin-edge from scratch. With the start of the service I could probably have survived most of the traffic on this machine alone – but client wants scalable, client gets scalable. The backend-wowza is ONLY available on the internal network in this setup. The only port available to the outside is the streammanager, so we can reset streams if needed – without restart Wowza completely.

Wowza frontend configuration

A workhorse to say the least. Expandable hardware is nice. It’s basically a 2U version of the encoders and have 24gigs of ram and the same processor and core-count. I’ve even milked the support-personnel at Wowza for optimizing this setup so it gets as good as I can without overdoing it.

Example: I have 24gigs of ram. Wowza Support doesn’t recommend giving Wowza itself more than 8gig. Why? Because then Garbage Collection on the javaside starts taking too long and that hampers performance. But it’s basically doing a liveedge setup, times two since we’ve had to implement and old workaround (feature) in Wowza that makes it possible to change mp4 (android/iphone) to 3gpp (mp4latm) instead, for the ooooold terminals. How I wish that people would kick their old phones to the curb and get new ones. Would surely make my life a lot easier.

This machine is currently the only one available to the public.

Endpoint?

Well.. as usual, when it comes down to projects I’m involved in, the product isn’t available outside of Sweden and not outside of a certain cell network in Sweden. So I can’t show you anything worthwhile ‘live’ and direct. If you are interested in seeing the end product… what you can do is ask me and I can, perhaps, provide you with a temporary link that you can try out.

I can, however, show you a screencapture from my iPhone 4 (the old one, not the new and improved one)

And the only thing I’ve done is to hide the channel and the subtitling – I’m sure someone can decode what channel and program it is anyways but I’ve tried at least. The image actually looks better on my iPhone than it does in the “real world”.

If you have any questions in regards to this setup, don’t hesitate to ask – if the questions gets too intricate then we can discuss the consultingfees 🙂

Recommended Posts

No comment yet, add your voice below!


Add a Comment

Your email address will not be published. Required fields are marked *