1. Video Encoding

If you are planning on encoding your video into one format only, H.264 video and AAC audio in an MP4 container is the way to go. This will be playable in a native HTML5 video element in the latest versions of Google Chrome, Safari, Internet Explorer and iPad. iPhone will recognize the HTML5 video element and video in this format, but playback will be in full screen (rather than in- context on the web page). Other popular browsers, Mozilla Firefox and Opera, as well as older versions of the aforementioned browsers will also be able to play H.264/AAC encoded video through the use of the Adobe Flash plugin and an embedded Flash video player.

If you are willing to additionally encode into a second format, use VP8 in a WebM container. This format is supported by the HTML5 video element in the latest versions of Mozilla Firefox, Google Chrome and Opera. Thus HTML5 video element in the latest versions of all popular browsers, as well as iPhone and iPad, support at least one of these two formats. For maximal coverage, however, you may still want to include a Flash video player fallback for older browsers, which are still used with significant prevalence.

• http://en.wikipedia.org/wiki/HTML5_video
• http://www.w3schools.com/browsers/browsers_stats.asp
• http://html5video.org/wiki/HTML5_Player_Comparison Introducing XDN

2. Pseudostreaming

Pseudostreaming is a widespread HTTP alternative to a true streaming protocol such as RTM, used to offer viewers the ability to seek to any point in a video prior to its download completion. i.e. basically seeking past the loading bar.

HTML5 Video and HTTP/1.1 206 byte-range requests

HTML5 video handles this natively, but retaining video header information and making HTTP 206 byte-range requests to the server for the raw bits of whichever part of the video you seek to, if that part has not yet loaded. This is very convenient since most servers support byte-range requests right out of the box.

CrowdCache™ fully supports the HTTP 1.1 specification, including these HTTP 206 byte-range requests.

One of the by-products is that any terminal using byterange requests for video seeking is automatically supported, this includes, amongst others: all Apple iOS based devices, browsers that can playback HTML5 video, whether it is WebM or MP4.

Flash and the use of URL Parameters for seeking/scrubbing

A Flash player, unfortunately, cannot set these byte-range request headers, nor manipulate video data on a byte stream level. While some Flash players simply do not support seeking anywhere past what has loaded, those with streaming support implement a different mechanism.

When a user seeks to a part of the video that has not loaded, they make a new request to the server to construct a brand new video file, that starts at the seek point. This is done by appending a time parameter (e.g. start=34.02) to the video URL. The server then (if it supports pseudo-streaming) will actually reconstruct a video file with appropriate header and key-frame information.

How your legacy CDN does it

Different server technologies require differently-named so-called start parameters. For instance, Bitgravity uses "starttime", Edgecast uses "ec_seek”...

A good compilation of information about pseudostreaming is available here, including server-side technologies you can put on your own server:

• http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/12534/video-delivery-http-pseudo-streaming
  

CrowdCache™ nodes support H.264/AAC (MP4) and FLV pseudo- streaming, and will honor most of the common start.

Any of these can be overridden in a CrowdCache™ node's configuration, should you require a different parameter name. Please chat with support@3crowd.com to get directions on using a custom CrowdCache™ config file.

Standard behavior for seeking/scrubbing via CrowdCache™ and XDN™

Out of the box, a CrowdCache™ server will accept the following URL Parameters for seeking, these standard Query Arguments used for pseudo- streaming seeking actions apply to all XDN™ customers.

As you can see in the table below, most of the parameters that are handled by the most common CDNs on the market will not need to be rewritten on your end, therefore reducing the migration overhead to XDN™ significantly.

As mentioned in the previous section, these parameters are manually tunable through the CrowdCache™ config file.

Video seeking pre-requisites:

Whenever time based seeking is enabled, it requires your HTTP Origin to have the correct content-type header set, please go to section Common Pitfalls for details.

Secondly, both your FLV and MP4 files need to be prepared for pseudostreaming, please make sure that your encoding workflow:

• FLV files will require the onMetaData and onCuePoint either populated at encoding time or later using tools such as FLVTool2
• MP4 files will require that their MOOV Atom is shifted to be beginning of the container, either tick the 'Prepare for Streaming' option in your encoder, or run your already encoded MP4s through software such as QtIndexSwapper.air app

3. Sample Embed with HTML5 and Flash support

XDNTM recommends JW player, one of the most widely used players on the internet. The following embed sample will attempt to use HTML5 WebM, HTML5 MP4 and then Flash with pseudo-streaming support. Download and more detailed documentation on configuring the JW player is available at http://www.longtailvideo.com/players/ .

Rearranging the elements in the "modes" array below, you can change your fallback order.

<script type="text/javascript">
  jwplayer("container").setup({
    id: "playerID",
    width: "660",
    height: "464",
    wmode: "transparent",
    file: "http://demo-hostname.3crowd.com/rrx.mp4",
    image: "img/thumb.jpg",
    controlbar: "bottom",
    provider: "video",
    stretching: "fill",
    modes: [
      {
        type: "html5",
        config: {
          levels: [
            {file: "http://demo-hostname.3crowd.com/rrx.mp4"},
            {file: "http://demo-hostname.3crowd.com/rrx.webm"}
          ]
        }
      },
      {
        type: "flash",
        src: "mediaplayer/player.swf",
        config: {
          provider: "http",
          "http.startparam":"starttime"
        }
      },
      {
        type: "download"
      }
    ]
  });
</script>

Flow Player is also available as an alternative player. Here is some sample embed code, configured to use "starttime" as the CrowdCache™ -supported pseudostreaming parameter. For Flowplayer download and documentation visit http://www.flowplayer.org

<div id="player" style="width:480px;height:270px;"></div>
<script type="text/javascript">
flowplayer("player", {"src":"flowplayer/flowplayer-3.2.7.swf", "wmode": "opaque"}, {
  "clip": {
    "provider": "crowdcache",
    "url": "http://demo-hostname.3crowd.com/rrx.mp4"
    "autoPlay": false
  },
  "plugins": {
    "crowdcache": {
      "url": "flowplayer/flowplayer.pseudostreaming-3.2.7.swf",
      "queryString":escape('starttime=${start}')
    },
    "controls": {
      "url": "flowplayer/flowplayer.controls-3.2.5.swf"
    }
  }
});
</script>

4. CrowdCache™ and XDN™ video seeking how-to

XDN™ customers and CrowdDirector™ / CrowdCache™ users

Depending on which one of the two aforementioned classes of users you belong to, the following section might not apply.

• If you are an XDN™ Content Delivery user
  The “magic” behind our elastic delivery network is transparent to you, this means that you will only have to make sure your player can talk to our XDN™ network using the accepted Query Args listed in the previous table called: Standard behavior for seeking/scrubbing via CrowdCache™

• If you are running a CrowdDirector™ / CrowdCache™ based private delivery network, or are a customer of such a provider
  Please refer to the next section to provision “video seekable” Edge-to- Origin mappings using CrowdDirector™ and CrowdCache™

Enabling Pseudo-streaming seeking capability on a CrowdCache™ Edge- to-Origin mapping

Prerequisites:

• A CrowdDirector™ account
• A CrowdCache™ pool, either containing CrowdCache™ nodes you own, or shared to you by a CrowdCache™ node owner

Let's say your videos are being served from videos.company.com ( 1.2.3.4 )

1. Create a Rule Set
   1. Click theRule Setstab
   2. Click theAdd DNS Rule Setbutton
   3. Enter videos.company.com

       

      
   4. ClickSave
2. Set the default action deliver traffic from a CrowdCache™ pool.
   1. Click the videos.company.com rule set
      
      
   2. Click theSet Default Actionbutton
   3. Select your desired CrowdCache™ pool from the second drop down
   4. ClickSave & Exit
      
      
3. Create a Mapping, so that CrowdCache™ nodes in the pool you selected, will know where to fetch and proxy your traffic.
   1. Click the CrowdCache™ tab, thenMappings
   2. Click theAdd Mappingbutton
   3. In theMapping Keysection, select theHostkey videos.company.com
      
      
   4. In theOrigin Serversection, set your origin server URI to 1.2.3.4
   5. Use the host header your origin server is expecting videos.company.com
      
      
   6. For serving video, you will need to configure your mapping deal with URL parameters used for seeking. When a node fetches a video from your origin, it should strip off the start (or equivalent) pseudostreaming parameter, so that the full video file gets cached for future delivery. If you are not using other URL parameters, simply remove the full query string in theCache-miss Behaviorsection.
      
      
4. Edit your NS records. Point videos.company.com to r1.3crowd.com .
   

5. Rate Limiting

In order to avoid delivering video unnecessarily (incurring higher bandwidth cost), you may rate limit your content delivery. If you choose a rate limit which slightly exceeds the video bitrate, your viewers should not experience degraded performance or buffering, but you will deliver less video which will not get viewed. This works particularly well in conjuction with pseudostreaming, since the viewer is still allowed to seek to any part of the video at any time.

• Edit the mapping, and under the Rate Limiting section, add MIME types for the videos you are going to serve. Selecting Automatic Bitrate will use the bitrate found in the video metadata. Presently, this will only work for the MP4 file format..
  

Note about the bitrate meta-data

As an important side remark, the audio-bitrate and video-bitrate absolutely need to be configured for the Auto-Bitrate capability to be working properly.

If not the case, the Rate-Limiting just won't be applied to the corresponding MIME-Type which will in turn be delivered at full speed.

6. Common Pitfalls

Origin and MIME types

CrowdCache™ will serve your videos with the same MIME type as was specified when fetching from your origin.
Ensure that your Origin is set accordingly:

• Your Origin webserver's MIME type for mp4s is set to video/mp4
• Your Origin webserver's MIME type for WebM videos is set to video/webm
• Your Origin webserver's type for FLV video is set to video/x-flv

Making sure your video assets are compliant with pseudo-streaming seeking

As mentioned in the section video Seeking pre-requisites, you need to make sure:

• Correct content types are setup on your origin server if you have timebased seeking
• FLV and MP4 meta-data populated properly in your encoded files
• Audio-bitrate and Video-bitrate populated in your video assets if AutoRate-Limiting is configured for your account.

Behavior on cache-miss

On cache-miss, any CrowdCache™ based edge server (which includes XDNTM) will simultaneously do these two things:

• Proxy-through towards your HTTP origin to serve the video file
• Spawn a parallel HTTP worker thread to fetch the content and fill its cache with that same file.

Make sure you are fully aware of this corner case when testing pseudo-streaming seeking capability on your functionality testing setup.

When Proxying-through on a cache-miss, you (or whatever first user requests the file for that matter) will not be able to perform a pseudo-streaming seek action on that file being served for the 1st time, make sure you test the seeking functionality on a video asset already in cache.