Below you can find a quick description about the protocols we offer. In the following chapters we will provide all details about the protocols.
|Wowza Media Server||Wowza Streaming Engine is a unified streaming media server software developed by Wowza Media Systems. The server is used for streaming of live and on-demand video. Wowza supports most protocols and is the primary choice.||RTMP, RTSP, Apple HTTP Live Streaming, MPEG-DASH, Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming and QuickTime over RTSP|
|Windows Media||Windows Media Services (WMS) is a streaming media server from Microsoft that allows an administrator to generate streaming media (audio/video). Only Windows Media, JPEG, and MP3 formats are supported. It only supports RTSP, MMS and MMS proxied over HTTP.||Windows Media (RTSP, MMS and MMS proxied over HTTP)|
|Microsoft Smooth Streaming||Smooth Streaming, an IIS Media Services extension, enables adaptive streaming of media to Silverlight and other clients over HTTP. Smooth Streaming provides a high-quality viewing experience that scales massively on content distribution networks, making true HD 1080p media experiences a reality.||Microsoft Smooth Streaming and Apple HTTP Live Streaming|
|Icecast||Icecast is a streaming media server which supports AAC and MP3 audio streams. It is primary used to support older internet radios.||Icecast protocol (HTTP)|
|Webdav Push HTTP Live Streaming||VDO-X is capable of handling a HLS live stream that is pushed using WebDAV by external encoders. This way you can use your one encoder with your own pre-chunked material.||Apple HTTP Live Streaming|
|Origin Pull HTTP Streaming||VDO-X is capable of pulling HTTP streams using a caching mechanism. The following pre-chunked formats are supported: Apple HTTP Live Streaming, Adobe HTTP Dynamic Streaming and Microsoft Smooth Streaming.||Apple HTTP Live Streaming, Adobe HTTP Dynamic Streaming and Microsoft Smooth Streaming|
For streaming there are 2 types of protocols:
- True streaming protocols: These protocols provide a continues stream which results in minimal delays(about 3 seconds). RTMP, RTSP, Icecast and Windows Media are True Streaming protocols. You need a specific player to play this content. It will not work on mobile devices and it cannot be cached. MultiCDN is not possible with these protocols.
- HTTP based protocols: These protocols chunk the video in 10 seconds. It uses the standard HTTP protocol, this way it can be cached or used with MultiCDN and works on mobile devices. A specific player is not needed for this content, because of the chunking process you have a delay of around 40 seconds. Apple HTTP Live Streaming, MPEG-DASH, Microsoft Smooth Streaming and Adobe HTTP Dynamic Streaming are HTTP based protocols.
When minimal delays are necessary for your livestream you should use a true streaming protocol in all other cases we recommend HTTP based protocols.
n order to set up a Windows Media live stream, start the Live stream wizard (see Add a livestream for more information) and select Windows Media as stream type. A Windows Media live stream supports true streaming, both push and pull ingest, and multiple bit rates.
Please keep the following points in mind when working with Windows media:
when creating a pull stream, source addresses must start with http:// or rtsp:// - it is not possible to pull a stream that uses mms:// as protocol in the URL
although the wizard does not mention it, Windows Media streams do support multiple bit rates. You may simply add the wanted bit rates in the encoder.
In order to set up a Microsoft Smooth Streaming live stream, start the Live stream wizard (see Add a livestream for more information) and select the Microsoft Smooth Streaming as stream type. Microsoft Smooth Streaming is one of the standard HTTP streaming technologies and supports both push and pull ingest, as well as multiple bit rates, which may be added in the encoder and will be automatically detected.
A Microsoft Smooth stream needs an encoder when it is pushed to our platform. The recommended encoder is the Microsoft Expression Encoder. Only the pro version of the Microsoft Expression Encoder supports livestreaming.
Keep in mind though that when you create a pull stream the source location(s) should always start with http:// and have file extension .smil.
In order to set up a IceCast radio stream, start the Live stream wizard (see Add a livestream for more information) and select IceCast as the stream type. Icecast supports both push and pull ingest. For pushing your stream to our platform you need an encoder. An example of a good IceCast encoder is AltaCast. We recommend to use mp3 or aac as the audio codec.
If you choose to use pull ingest, notice that the source location(s) must start with http://.
Please note that IceCast works on port 8000. You need to be able to access port 8000 from the viewers network, otherwise you cannot listen to the stream. With the following URL you can test if you can access port 8000: portquiz.net:8000.
VDO-X is capable of handling a HLS live stream that is pushed using WebDAV by external encoders. In other words: the external encoder creates chunks for a HLS live stream and pushes the chunks and playlist to VDO-X using WebDAV. Subsequently VDO-X ensures that this stream of chunks is properly handled and distributed to the viewers. It is also possible to use HTTP pull instead of Webdav. See Origin HTTP Live streaming for more information.
The encoder must support basic HTTP authentication in order to connect to the XL-Media Server. We strongly advise to configure the encoder to clean up chunks that have already been used, because otherwise you may hit the account storage quota which will cause the live stream to stop without notification. A proven setup is to keep about 10 chunks, which is around 1 minute and 40 seconds of movie. But of course, if you have sufficient quota, you may deviate from this.
In order to set up a WebDAV push HLS stream, start the Live stream wizard (see Add a livestream for more information) and select the option Webdav Push HTTP Live Streaming.
Like any other push stream, all that is required after selecting the user and clicking 'Next', is to choose a stream name. On the summary page you may notice:
- The stream name is transformed into a directory name. As a result chunks from multiple simultaneous streams will not get mixed up.
- VDO-X adds the file name playlist.m3u8. This ensures that the stream is recognized as a HLS stream. Remember however that in order to request this stream from the Rediraptor you have to postfix the stream name you chose with the string %2Fplaylist.m3u8. The Embed Code Generator will do this automatically for you.
Make sure your encoder pushes the HLS manifest to the file playlist.m3u8 and that all chunks are pushed to the proper folder. Also note that HLS streaming is only supported when the stream is encoded using H264 video and AAC audio.
Multi bit rate streams are supported, as long as you make sure that you add the required bit rates to the manifest file and make sure the required chunks are also available in the right directory.
VDO-X is capable of pulling HTTP streams using a caching mechanism. The following pre-chunked formats are supported: Apple HTTP Live Streaming, Adobe HTTP Dynamic Streaming and Microsoft Smooth Streaming.
In order to use this technique you should set up an external HTTP server where the chunks can be downloaded. This server needs to be accessible for our platform (18.104.22.168,22.214.171.124,,126.96.36.199,188.8.131.52,184.108.40.206,220.127.116.11).
Any Expire (HTTP) headers sent by your origin server(s) will be respected by VDO-X. Incorrect headers may cause:
the live stream may not play at all, or
the live stream may stop at some point
the live stream may keep repeating a small segment
VDO-X may suddenly start to repeat requests a lot
If you experience any of this happening, the first thing to check is the Expire headers created by your origin server(s). ###Setup example
In order to setup an Origin Pull HTTP Stream start the Live stream wizard (See Add a livestream for more information) and select the option 'Origin Pull HTTP Streaming'. Then click on the next button.
Now you need to specify the source URL (origin). Eventually you can add a secondary a secondary origin for high availability. The second origin should have the same content as the primary. The urls provided should be resolvable to a livestream in one of the three supported formats (HLS, HDS and MSS).
The publishing point name is generated dynamically based on the primary source location. When you provided the primary and eventualy the secondary source location you click on the button next. A confirmation page will be shown with the information provided. Click on next. The Origin Pull HTTP Stream is now created.