Defining RTMP sources | JW6

Embedding an RTMP stream using JW HTML Config is simply a matter of providing the full stream URL* as a source and setting the type attribute to stream/rtmp:

<div class="jw-settings" id="my_simple_settings">
     <video id="my_simple_video" poster="/posters/big-buck-bunny-preview.jpg" preload="none">
          <source src="rtmpt://s2pchzxmtymn2k.cloudfront.net/cfx/st/mp4:sintel.mp4" type="stream/rtmp" />
     </video>
</div>

This simple configuration results in the following stream being rendered in JW Player:

Setting dynamic quality level switching is as simple as providing additional sources for each quality level available – by including the data-bitrate and/or data-width parameters for each source.

Because RTMP is dependent on Adobe Flash, it is also sensible to include fall-back sources in the case that the user doesn’t have Flash installed.

<div class="jw-settings" id="my_simple_settings">
     <video id="my_simple_video" poster="/posters/big-buck-bunny-preview.jpg" preload="none">
          <source src="rtmpt://s2pchzxmtymn2k.cloudfront.net/cfx/st/mp4:sintel-360.mp4" type="stream/rtmp" data-bitrate="555000" data-width="360" data-label="SD" />
          <source src="rtmpt://s2pchzxmtymn2k.cloudfront.net/cfx/st/mp4:sintel-540.mp4" type="stream/rtmp" data-bitrate="777000" data-width="540" />
          <source src="rtmpt://s2pchzxmtymn2k.cloudfront.net/cfx/st/mp4:sintel-720.mp4" type="stream/rtmp" data-bitrate="999000" data-width="720" data-label="HD" />
          <!-- non-Flash fall-back sources -->
          <source src="/videos/mp4/big-buck-bunny.mp4" type="video/mp4"/>
          <source src="/videos/webm/big-buck-bunny.webm" type="video/webm"/>
     </video>
     <div class="jw-modes">
          <div class="jw-mode" data-type="flash"></div>
          <div class="jw-mode" data-type="html5"></div>
     </div>
</div>

Additionally, now we have provided non-Flash sources but would prefer the RTMP sources to be considered first, we need to include a div.jw-modes block inside the div.jw-settings specifying we should try Flash mode first:

Extended options

In JW Player 6 there are some extra RTMP settings available which allow you to tweak the playback of streams. These can be configured using JW HTML Config by including a div.jw-extended block inside the div.jw-settings block with the data-type attribute set to rtmp.

The following settings can be added as data- attributes to this block in order to configure RTMP further:

  • data-bufferlength – 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 using this setting.
  • data-subscribe – When streaming RTMP live streams using the Akamai, Edgecast or Limelight CDN, players cannot simply connect to the live stream. Setting this to true tells JW Player to send the necessary additional FC Subscribe setting to the server.
  • data-securetoken – 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. By setting this to your token value, JW Player will pass this to the server for verification before the stream is started.
  • data-streamer – If all RTMP stream configurations are coming from the same server / application then the application part of the Full Stream URL can be specified here. This in turn means you would only need to specify the stream identifier part of the stream in the defined sources.

Below is an example of how to use the RTMP extended block:

<div class="jw-settings" id="my_simple_settings">
     <video id="my_simple_video" poster="/posters/big-buck-bunny-preview.jpg" preload="none">
          <source src="mp4:sintel-360.mp4" type="stream/rtmp" data-bitrate="555000" data-width="360" data-label="SD" />
          <source src="mp4:sintel-540.mp4" type="stream/rtmp" data-bitrate="777000" data-width="540" />
          <source src="mp4:sintel-720.mp4" type="stream/rtmp" data-bitrate="999000" data-width="720" data-label="HD" />
          <!-- non-Flash fall-back sources -->
          <source src="/videos/mp4/big-buck-bunny.mp4" type="video/mp4"/>
          <source src="/videos/webm/big-buck-bunny.webm" type="video/webm"/>
     </video>
     <div class="jw-modes">
          <div class="jw-mode" data-type="flash"></div>
          <div class="jw-mode" data-type="html5"></div>
     </div>
     <!-- Extended RTMP Block -->
     <div class="jw-extended" data-type="rtmp" data-streamer="rtmpt://s2pchzxmtymn2k.cloudfront.net/cfx/st/" data-bufferlength="5" data-subscribe="true" data-securetoken="Kosif093n203a"></div>
</div>

*Full stream URL

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 JW6, these two pieces are rolled up into a single URL.

JW HTML Config makes use of this new simple single configuration when defining sources in both JW5 and JW6 – except, as detailed above, in the case where the data-streamer attribute is specified as part of the extended configuration.

RTMP Tunnelling

In the documentation for JW Player 5, the following is stated:

RTMP is a different protocol than HTTP and is sent over a different port (1935 instead of 80). Therefore, RTMP is frequently blocked by (corporate) firewalls. The JW Player detects and circumvents this issue.

However, in the JW Player 6 documentation this reference has changed to:

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.

Given this is the only reference to RTMPT in the JW6 documentation, coupled with fact the tunneling functionality was slated for removal in the JW6 beta release notes, it is fair to assume that RTMPT is no longer supported in JW6.

Due to the diversity of RTMP setups (ports, firewalls, protocols), the automated RTMP tunneling feature in JW5 tended to create as many issues as it solved. Therefore, this is removed from JW6. Instead, we ensure the onError() event is called when an RTMP server cannot be reached. Publishers can then fallback from RTMP in any way they wish using a few lines of JavaScript code.

Assuming this is the case, there may be a large section of your audience who aren’t able to view your videos. One way to overcome this is to force tunneling by specifying rtmpt:// rather than rtmp:// in the application path.

Clearly this is not ideal as performance will degrade – especially the buffer times, which may double – as the video is tunneled over HTTP and port 80 rather than the UDP transmission protocol over port 1935. The server may also need to be configured explicitly in order to allow tunneling.