Using Nginx as a media streaming edge

magento2-nginx-configuration

I’d like to pay attention at the communication between Wowza Streaming Engine and Nginx as origin – edge. Here will be shown the synopsys of this structure and detailed software configuration.

How media streaming works


You can skip this part of post if you know the streaming architecture and just want to set up origin with edge. Basically default media streaming infrastructure has the next schema.

wowzaoriginedge1

Origin servers receive streams and convert them to deliver to the global network. Original source, mostly UDP multicast, usually has a 8-10 mbit/s bitrate and it couldn’t be sent directly. Origin makes two basic processes: packetization and transcoding. Packetization means stream conversion to format of special network protocol. It could be HLS, HDS, RTMP, whatever. After packetization stream has much lower bitrate and getting ready to be shipped. Transcoding means packetized stream conversion to many instances with customized bitrate and resolution. When you see a choice of qualities in video hosting like Youtube – that’s a transcoding job.

Edge servers drag processed streams from origin servers, cache them and deliver to end-users. You could ask: why do we need one more layer, when origin can make this task by itself? But this way of streaming is much more decentralized, and that’s a big plus. Transcoding operation brings too much overhead on the servers. It’s better to maintain just one network connection per stream with edge. The edge takes responsibility for network high load. The main idea – take a stream just once and deliver this instance for everybody. It saves a big part of network bandwidth.

Configure Wowza HTTP Origin


1. Create at the Wowza Manager new Live HTTP Streaming application. Note: for this purpose you’ll need extended Wowza license. It doesn’t work with trial license. For example, let’s call our new app “catchup”.

2. Edit to the application config file ([wowza_dir]/conf/[app_name]/Application.xml). Add to the <HTTPStreamer>/<Properties> XML block new properties.

<HTTPStreamer>
<!-- Properties defined here will override any properties defined in conf/HTTPStreamers.xml for any HTTPStreamer loaded by this applications -->
    <Properties>
        <Property>
            <Name>httpOriginMode</Name>
            <Value>on</Value>
            <Type>String</Type>
         </Property>
         <Property>
             <Name>cupertinoCacheControlPlaylist</Name>
             <Value>max-age=1</Value>
             <Type>String</Type>
        </Property>
        <Property>
            <Name>cupertinoCacheControlMediaChunk</Name>
            <Value>max-age=3600</Value>
            <Type>String</Type>
        </Property>
    </Properties>
</HTTPStreamer>

For this example I just set up HLS caching configuration. You can check the full list of available options for HDS, MPEG-DASH and Smooth at this Wowza article.

3. Restart Wowza application to enable configuration changes.

Create new stream


Just start to stream anything from live source. There are some ways to add a stream to Wowza VHost: Alias module, stream files, startup streams and so on. Here is my URL for stream:

http://wowza.test.com:1935/live/mystream/playlist.m3u8

I’ve put at this URL 1935 port. Because Wowza streams at 1935 port by default independently from protocol.

Configure Nginx virtual host


Basically Wowza is intended to serve edge software too. But it will be new instance which means more costs on business. As an alternative we can use almost every proxy server. One main requirement – ability to cache dynamic content with a little latency. Nginx is a great solution for this goal.

All we need – ensure that we have proxy_cache module (nginx -V to help) and configure this.

Configuration is pretty straightforward. At first create a proxy_pass at the /etc/nginx/nginx.conf config file.

proxy_cache_path /usr/local/WowzaStreamingEngine/cache levels=1:2 keys_zone=hls:1m inactive=1s;

The next, create new virtual host file at /etc/nginx/sites-available directory.

server {

listen 80;
server_name stream.sample.com;
root /usr/local/WowzaStreamingEngine/conf;
proxy_cache hls;
       add_header X-Proxy-Cache $upstream_cache_status;
       proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_valid any 1s;

location /wowza_cache {
            proxy_pass http://wowza.test.com:1935/live
    }

}

Here I take a ready HLS stream from origin and accept user requests to deliver this stream. Also Nginx can get non-HTTP streams like RTMP or RTP, but it can’t cache them. At this case Nginx will be useful only as a proxy. There still be one connection per request to origin server instead of one per stream.

The Nginx cache configuration is really flexible. You could change cache valid time, available HTTP methods and so on. Nginx blog has a brilliant post about proxy cache configuration.

For this example we’ll get the next URL to play stream:

http://stream.example.com/wowza_cache/mystream/playlist.m3u8

If your virtual host listens another TCP port – include this port at the URL after server name.

That’s all! Now Nginx delivers media content to end-users just in time. The latency I noticed is absolutely miserable! Have fun to experiment with origin-edge communication. You might also realize it with VOD application. This example with live stream is just representative. It allowed us to check the ability to ship dynamic content from Nginx.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s