Presumably you want your videos to be as high-quality, low bandwidth, and platform-compatible as possible. The emergence of new digital video container formats and codecs offers more compressed, higher resolution video on the internet than ever before.

When moving from a traditional video serving infrastructure to the 3Crowd world, be it from a legacy CDN or your own HTTP video delivery server, we believe this quick tutorial will help you hit the ground running.

Don't hesitate to let us know of any gotchas that our team of highly skilled engineers have missed and we will integrate them to the current content.

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

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.

Flash and the use of URL Parameters for seeking/scrubbing

A Flash player, unfortunately, can not 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 pseudostreaming) will actually reconstruct a video file with appropriate header and keyframe information. Different server technologies require differently-named so-called start parameters. For instance, Bitgravity uses "starttime", Edgecast uses "ec_seek...

The table below lists the different parameters (query args) used by most legacy CDNs:

CDN	Parameter name
Akamai	aktimeoffset in seconds, works on FLV
Limelight	fs in bytes, works on FLV
Level(3)	start will use .mp4 or .flv file extensions to assume bytes for FLV and seconds for MP4
Edgecast	ec_seek automatically assumes bytes for FLV and seconds for MP4
CDNetworks	Choose your own seeking URL parameter [seek] through the admin GUI and configure file extensions for MP4 seeking. Use bytes on FLV and seconds on MP4 with the same [seek] parameter.
BitGravity	ap_start in bytes for FLV starttime in seconds for MP4 and FLV

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) pseudostreaming, and will honor most of the common start parameters which signify start time of the video to deliver: start, starttime (BitGravity), ec_start (Limelight), fs (Akamai). For FLV, byte offset based start parameters are also supported.
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™

Out of the box, a CrowdCache™ server will accept the following URL Parameters for seeking:

Seeking method / MIME-Type	FLV	MP4
Time (in seconds)	starttime, start, apstart, ec_seek, fs	start
Byte-offset (in bytes)	start (native CrowdCache parameter)	not available

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

3Crowd 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 pseudostreaming 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>
				

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 the Rule Sets tab
   2. Click the Add DNS Rule Set button
   3. Enter videos.company.com
      
   4. Click Save
2. Set the default action deliver traffic from a CrowdCache™ pool.
   1. Click the videos.company.com rule set
      
      
   2. Click the Set Default Action button
   3. Select your desired CrowdCache™ pool from the second drop down
   4. Click Save & 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, then Mappings
   2. Click the Add Mapping button
   3. In the Mapping Key section, select the Host key videos.company.com
      
      
   4. In the Origin Server section, 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 the Cache-miss Behavior section.
      
      
4. Edit your NS records. Point videos.company.com to r1.3crowd.com.
   

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..
  

CrowdCache™ will serve your videos with the same MIME type as was specified when fetching from your origin. Ensure that your MIME type for mp4s is set to video/mp4 and your MIME type for WebM videos is set to video/webm