LongTail Video is now JW Player - New Name, Same Passion For Video

Close

JW Player Support Documentation

Using RTMP Streaming

This guide provides an overview on RTMP streaming with JW Player 6. It is available in all JW6 editions, including Free.

Introduction

RTMP (Real Time Messaging Protocol) is a system for delivering on-demand and live media to Adobe Flash applications (like the JW Player). RTMP supports video in MP4 and FLV and audio in AAC and MP3. RTMP offers several advantages over regular HTTP video downloads:

  • RTMP can do live streaming, so people can watch your video while it is being recorded.
  • RTMP can do dynamic streaming, where the video quality automatically adjusts to changes in bandwidth.
  • Players can seek to later parts in a video, which is particularly useful for files > 10 minutes.
  • Players maintains a tiny buffer, instead of downloading a video during playback, saving bandwidth.

Disadvantages

However, do note that RTMP has its disadvantages too. The most important ones are:

  • RTMP uses different protocols and ports than HTTP, which makes it vulnerable to getting blocked by (corporate) firewalls. This issue can be prevented by streaming in RTMPT (tunneling over HTTP), which comes at a server performance cost.
  • RTMP data is streamed to the player, which means the bandwidth of the connection must be larger than the data-rate of the video. If the connection drops for a couple of seconds, the stream will stutter. This issue can largely be prevented by using dynamic streams that include a low-quality file.

The biggest drawback is that RTMP only works in Flash and not in HTML5. New HTTP streaming protocols, like Apple's HTTP Live Streaming (HLS), have wider device support (e.g. iOS) and will likely replace RTMP over the coming years. JW Player supports Apple HLS in both Flash and HTML5 mode.

Server Support

In order to use RTMP, your host or CDN needs to have a dedicated RTMP server installed. There are two major offerings, both supported by JW Player:

  • The Wowza Media Server is today's most widely used solution. It includes support for almost any streaming protocol, including RTMP. Wowza 3 introduced dedicated support for JW6 SMIL manifests (see below)
  • The Adobe Media Server is another great option. Since Flash is developed by Adobe, new RTMP functionalities find their way in FMS first.

CDNs

The following CDNs (Content Delivery Networks) support RTMP and are tested to work great with JW Player. They all support dynamic streaming and, with the exception of CloudFront, live streaming too:

Live Streaming

A key feature of RTMP is the ability to do live streaming, e.g. of presentations, concerts or sports events. Next to JW Player and an RTMP server, one then also needs a small tool to ingest the live video into the server. There are a bunch of tools available. Flash Live Media Encoder is free and available for Windows and Mac.

With both FMS and Wowza, a live stream is embedded in exactly the same way as an on-demand stream. However, the Akamai, Edgecast and Limelight CDNs require a player to subscribe to a live stream. JW Player 6 supports this mechanism.

JW Player 6 will embed and play a live stream like an on-demand file, with one exception: instead of displaying a slider to scrub through the timeline, the player will display the title of the event in the controlbar.

Load Balancing

For large-scale deployments, JW Player supports 3 mechanism for server load balancing:

  • DNS load balancing, working independent of JW Player.
  • RTMP 302 redirects, as used by Wowza for load balancing. See their user guide for more info.
  • SMIL load balancing, where an initial SMIL file contains the RTMP links to edge nodes. See the section on dynamic streaming below for an example SMIL file.

Closed Captioning

JW Player supports Closed Captioning with RTMP, for both live and on-demand streaming. Only a single CC track is supported and this track must be in TX3G format. Both the Wowza and Adobe media servers are capable of sending TX3G captions over RTMP.

The first time JW Player encounters a TX3G onTextData cue, it places a CC button in the controlbar. If the user chooses to enable CC, this preference will be saved in a cookie and CC will be enabled for any subsequent videos the user watches.

Embedding a Stream

Embedding an RTMP stream into JW Player 6 is simply a matter of providing the full stream URL. Here is a very basic example, playing a single MP4 video:

jwplayer("myElement").setup({
    file: "rtmp://example.com/application/mp4:myVideo.mp4",
    image: "/assets/myVideo.jpg",
    height: 360,
    width: 640
});

Above example only works on desktops, since Flash is not available on mobile. Below is another example, using an MP4 loaded over both RTMP and HTTP. The RTMP stream will be played on desktops, the HTTP download will be played on devices:

jwplayer("myElement").setup({
    playlist: [{
        image: "/assets/myVideo.jpg",
        sources: [{ 
            file: "rtmp://example.com/application/mp4:myVideo.mp4"
        },{
            file: "/assets/myVideo.mp4"
        }]
    }],
    height: 360,
    primary: "flash",
    width: 640
});

Since the primary rendering mode is set to Flash, the RTMP stream is picked over the MP4. If this option were not set, the JW Player would play the HTTP download, since many browsers (e.g. Chrome, Internet Explorer) support that in HTML5 (the default mode in JW6).

See Working with Playlists for more info on loading multiple sources.

Application and Stream

Technically, an RTMP stream consists of two pieces:

  • The application path (e.g. rtmp://example.com/vod/).
  • The stream identifier (e.g. mp4:myFolder/video.mp4).

In JW Player 6, these two pieces are rolled up into a single URL. The JW Player determines the split between application and stream based upon the location of the mp4, flv or mp3 prefix:

  1. An mp4: prefix is required for MP4/M4V/MOV/F4V videos:
    rtmp://example.com/vod/mp4:myFolder/myVideo.mp4
  2. An flv: prefix is required for FLV videos or live streams (with FLV container):
    rtmp://example.com/vod/flv:myFolder/myVideo.flv
    rtmp://example.com/live/flv:myFolder/myLiveStream
    
  3. An mp3: prefix is required for MP3 audio:
    rtmp://example.com/vod/mp3:myFolder/mySong.mp3
    
  4. An mp4: prefix is also required for M4A/F4A/AAC audio files:
    rtmp://example.com/vod/mp4:myFolder/mySong.m4a
    

If no prefix is found, the player splits application/stream after the last / in the filename. The prefix is then automatically added (mp4:, mp3:). Note the flv prefix is not used internally by the Wowza/Adobe server, so JW Player strips that one out before requesting the stream.

Dynamic streaming

In addition to loading a single RTMP stream, JW Player 6 supports loading dynamic streams. A dynamic stream consists of multiple single streams of the same content, all in a different quality. The JW Player allows automated or manual switching between the different qualities in such a stream.

Dynamic streams have to be set up using so-called SMIL manifests. These are simple XML files that contain the location of the RTMP application, plus the path to (one or more) streams stored on the RTMP server. The player always presume a file with the extension .smil is an RTMP SMIL manifest:

jwplayer("myElement").setup({
    file: "/assets/myVideo.smil",
    image: "/assets/myVideo.jpg",
    height: 360,
    width: 640
});

Here is another example, using both an RTMP dynamic stream (for desktops) and a progressive MP4 download (for mobile):

jwplayer("myElement").setup({
    playlist: [{
        image: "/assets/myVideo.jpg",
        sources: [{ 
            file: "/assets/myVideo.smil" 
        },{
            file: "/assets/myVideo.mp4" 
        }]
    }],
    height: 360,
    primary: "flash",
    width: 640
});

Note that SMIL manifests are subject to Cross-domain Security Restrictions. If your SMIL files are located on a different server than your website or player, you have to setup a crossdomain.xml file.

SMIL contents

Here is a basic example, using three different streams:

<smil>
  <head>
    <meta base="rtmp://example.com/vod/" />
  </head>
  <body>
    <switch>
      <video src="myVideo-high.mp4" height="720" system-bitrate="2000000" width="1280" />
      <video src="myVideo-medium.mp4" height="360" system-bitrate="800000" width="640" />
      <video src="myVideo-low.mp4" height="180" system-bitrate="300000" width="320" />
    </switch>
  </body>
</smil>

The switching of quality is automatically done by JW Player, who selects the highest quality:

  • Whose system-bitrate fits the current bandwidth of the connection.
  • Whose width fits the current width of the player screen.

Users are able to override the automated selection by setting the quality from a popup menu. The height attributes of the streams in the manifest are used to set the labels of this menu (e.g. 720p).

Wowza 3

Wowza Media Server 3 introduced dedicated support for these SMIL manifests. If you are running version 3.1.2.15 or higher, append /jwplayer.smil to the URL of your adaptive streams to get these manifests.

Here is how the URL to a SMIL manifest and an M3U8 manifest (for Apple HLS streaming) look like with Wowza3:

http://example.com/vod/smil:myvideo.smil/jwplayer.smil
http://example.com/vod/smil:myvideo.smil/manifest.m3u8

Configuration Options

RTMP supports a few configuration options to tweak playback of the streams. They are set in a dedicated rtmp options block.

Buffer Length

By default, JW Player tries to maintain a buffer length of 3 seconds for RTMP video. This means that 3 seconds of video is fetched from the server and ready to play at all times. This can be changed to another value using the RTMP bufferlength option:

jwplayer("myElement").setup({
    file: "rtmp://example.com/vod/mp4:myVideo.mp4",
    height: 360,
    image: "/assets/myVideo.jpg",
    rtmp: {
        bufferlength: 0.1
    },
    width: 640
});

Sane values range from 0.1 (for low latency live streams) to 10 (to prevent frequent re-buffering).

FC Subscribe

When streaming RTMP live streams using the Akamai, Edgecast or Limelight CDN, players cannot simply connect to the live stream. Instead, they have to subscribe to it, by sending a so-called FC Subscribe call to the server. JW Player includes support for this, using the RTMP subscribe option:

jwplayer("myElement").setup({
    file: "rtmp://example.com/xxxx/myStream",
    height: 360,
    image: "/assets/myLivestream.jpg",
    rtmp: {
        subscribe: true
    },
    width: 640
});

Note this functionality only works for single RTMP streams. For multi-bitrate live streaming, the HLS protocol should be used.

Secure Token

The Wowza Media Server includes a feature called Secure Token that is used to protect your streams from downloading. It works by having the player send a token to the server, which is verified before the stream is started. JW Player supports this mechanism, using the RTMP securetoken option:

jwplayer("myElement").setup({
    file: "rtmp://example.com/vod/mp4:myVideo.mp4",
    height: 360,
    image: "/assets/myVideo.jpg",
    rtmp: {
        securetoken: "Kosif093n203a"
    },
    width: 640
});

Note we do not support the option to compile in the securetoken. SWF provides little incremental security over JS (they're both client-side), especially when the JS code is slightly obfuscated.

Still don't have the new JW Player? Get It Here