Background

In a prior post, I detailed the HTML5 audio standard, which is useful for embedding songs and podcasts directly into websites. Today we take the HTML5 standard a step further by showing its use in embedding videos. The ease of implementation, sleek professionalism and cross-browser compatibility makes HTML5 the modern alternative to Flash-based videos. By hosting videos yourself, you can avoid ads, third-party branding and size limitations.

The huge size of video files makes them cumbersome to stream, and no user likes to wait as their video lags during playback. Fortunately, Rackspace Cloud Files runs on technology designed for one purpose: stable and speedy delivery of large media like videos. Here, we explore supercharging HTML5 videos with Rackspace Cloud Files.

HTML5 Video

Historically, video has been embedded using Flash, and most hosting has been on large social sharing sites like YouTube and Vimeo. Relative to Flash, HTML5 video requires few lines of code. In addition, modern browsers natively support HTML5, whereas Flash normally requires a plugin. This extends to smartphones and tablets, where HTML5 videos play without any tweaking, yet Flash is rarely supported at all. (Try it – play the videos on this page on your smartphone and tablet!)

Note, though, that HTML5 video does not provide content protection – users may download the source video files without hindrance, whereas websites like YouTube use Flash because it prevents end users from being able to easily download the source video. Keep this in mind if you are hosting copyrighted content.

The Rackspace Cloud Files Advantage

Video files are huge. In fact, video consumes about half of all bandwidth in the US, according to Ars Technica. Traditional file servers do not handle the requirements of video well because of the high bandwidth and large file sizes. Worse, when a site is under load, video can hog so much of the server resources that the main website slows to a halt.

It was for this reason that content delivery networks (CDNs) came to prominence. Every day, large corporations use distributed global networks to silently deliver your videos, applications and songs. The Akamai-powered Rackspace Cloud Files network makes this technology accessible for businesses of any size, and flat bandwidth-based pricing makes it affordable.

The advantage comes with the scalability of Rackspace Cloud Files – it copies your video files to servers around the world, and whether you serve dozens or thousands of users, the network’s technology silently scales to keep quick load times.

Implementation

Preparing The Files

As with HTML5 audio, while the HTML5 video standard is made to work easily, unfortunately no single video format is supported across all web browsers. As this Wikipedia table shows, there are three main formats used on the web. The reason for multiple formats is that the incumbent H.264 codec is covered by a patent, and some wish to use only open-source codecs to avoid licensing issues.

From a practical standpoint, the supported codecs by each browser continue to change, so for stability and long-term compatibility, it is best to provide a video in all three formats – H.264, Ogg Theora and WebM. In addition, note that the patents covering the H.264 codec allow free use of the format only when videos are available for free to the end user (source). If you intend to charge for access to videos, I advise conducting your own due diligence on licensing.

For this example, I am using a video of my dog chasing snowballs:

• Snowball.mp4 (H.264)
• Snowball.ogv (Ogg Theora)
• Snowball.webm (WebM)

The main difficulty for me was converting the videos to the necessary formats. Even with a professional video editing suite, I had difficulty. I found that the easiest way on Mac computers to convert videos was with the Miro Video Converter, which is available for free in the Mac App Store. Alternatives for Windows and Linux are also available.

Uploading To Rackspace Cloud Files

On the Rackspace Cloud Control Panel, first choose an existing container or create a new container to host your content. Upload the three video files and publish them in the container. Click the sprocket next to each file and then select “View All Links.” Copy the HTTP links for the video files.

Alternatively, the open-source and free Cyberduck software, which is available for both Mac and Windows, makes it easier to upload multiple files. If you manage Rackspace file containers often, Cyberduck makes it quicker to manage these files.

Embedding

The basic HTML5 video player above uses this code:

<video width="356" height="200" controls poster="http://0639ac876cdeb83a534d-95c931daa7c80b903aae4215b472f9f8.r4.cf1.rackcdn.com/Snowball.png"  >
<source src="http://0639ac876cdeb83a534d-95c931daa7c80b903aae4215b472f9f8.r4.cf1.rackcdn.com/Snowball.mp4" type="video/mp4" />
<source src="http://0639ac876cdeb83a534d-95c931daa7c80b903aae4215b472f9f8.r4.cf1.rackcdn.com/Snowball.ogv" type="video/ogg" />
<source src="http://0639ac876cdeb83a534d-95c931daa7c80b903aae4215b472f9f8.r4.cf1.rackcdn.com/Snowball.mp4" type="video/webm" />
<em>Sorry, your browser doesn't support HTML5 video.</em>
</video>

You may copy the code into your website, replacing the file links with your own Rackspace Cloud Files URLs. Also, note that the file names are case sensitive!

Let’s walk through the various parts of the code and explain what they do:

• <video>: The video tag initializes the HTML5 video player.
  • Controls in the opening tag tells the browser to show controls (like play, pause and full screen) for the video.
  • The poster attribute controls which picture to show when the video is not playing. If you do not specify a poster, the browser will show a frame from the video. The poster is optional, but adds a degree of professionalism, and allows you to show a logo or title before the user clicks “play.” Using Rackspace Cloud Files to host the photo will provide a speed increase, but you may wish to use a native media browser (such as that in WordPress) instead to host the video.
  • Width and height control the dimensions of the video player, in pixels. This does not have to match the video file precisely, but it should match the dimensions of the poster image in order for it to display correctly.

In the opening tag, other useful attributes include:

• Autoplay: Plays the video as soon as the page loads.
• Preload: Begins loading the video file as soon as the page loads, rather than when the play button is clicked. This means that the page loads more slowly, but the file is immediately available when the user is ready to play it.
• Loop: Continuously replays the video file until it is paused.
• Muted: Disables audio during playback.
• <source>: These lines declare different source files and their formats. If there is only one format and source video, it may be declared with a src in the opening video tag. Due to compatibility reasons, the src attribute is rarely used in the opening tag.
• Incompatibility: The text between the video tags is displayed only if the browser does not support HTML5. Here, I display a simple message that the browser is incompatible. To see what it looks like, try using Browser Shots on this page or your website, it can show you how an older website displays HTML5 audio content. It is possible to embed JavaScript or Flash between the video tags as a fall-back player for older browsers.

Conclusion

If you have any questions, please post them in the comment section below. Other good HTML5 Video resources include:

• HTML5 Video (Wikipedia)
• Video.js Open-Source Project

For more information on high performance media that’s fast, simple and reliable, be sure to check out the new Rackspace Media Hosting on the Cloud website at: http://www.rackspace.com/cloud/media/.

Background

HTML5

HyperText Markup Language, or HTML, has served as the basic formatting language of the Internet for over two decades. As the content of the Internet has changed, so too has the language. The World Wide Web Consortium (W3C) controls the standard for HTML, and previous revisions to the language have introduced content such as tables and images to the World Wide Web.

HTML5 marks the latest version of HTML, and it adds new ways to interact with content and share media. In the past, JavaScript and Flash were used to accomplish much of the same goals, but the HTML5 standard brings security, cross-browser compatibility, and ease of implementation to many of these now-common tasks.

This month, W3C finalized the HTML5 definitions, and in 2014 they expect to adopt them as official web standards. However, web browsers released over the past year, including those on smartphones, have already incorporated HTML5 technology, so there is no need to wait until 2014 to begin utilizing its powerful features!

HTML5 Audio

In the past, embedding audio such as music or podcasts required using JavaScript or Flash, such as with this open-source MP3 player.

Rather than using this complicated code, HTML5 allows a simple <audio></audio> tag for embedding audio, similar to an HTML link. These tags link directly to the audio files. However, this means that anybody viewing the source code of the web page may then download sound file, so this is not a protected embedding of sound.

Rackspace Cloud Files / Akamai Advantage

A music or podcast file may easily be larger than the rest of a webpage combined. Thus, ensuring playback is quick and scalable on a normal file server is taxing. Rackspace Cloud Files is optimized to serve content such as podcasts to millions at blazing speeds. The Akamai content delivery network (CDN) technology behind Rackspace Cloud Files also powers many of the top media sites, making it an industry benchmark for speed and stability. And, with Rackspace Cloud Files, anybody can access this sophisticated technology at a low price.

Implementation

Preparing the Files

While HTML5 audio has been adopted by all major web browsers, one quirk remains – not every web browser can play every type of sound file! As this chart on Wikipedia shows, we have to provide the same audio file in multiple formats to ensure that is plays in all major browsers.

In general, providing audio in the MP3 and Ogg Vorbis formats allows it to be played in all major browsers.

For this demo, I am using these two files:

• RackspaceCloudFiles.mp3
• RackspaceCloudFiles.ogg

I found that the easiest way to convert files to .mp3 and .ogg was with the website Media.io.

Uploading to Rackspace Cloud Files

On the Rackspace open cloud interface, first choose an existing container or create a new container to host your content. Upload the .mp3 and .ogg files and publish them in the container. Click the sprocket next to each file, and then select “View All Links.” Copy the HTTP links for the two audio files.

Embedding

The basic HTML5 audio player above uses this code:

<audio controls>
<source src="http://0639ac876cdeb83a534d-95c931daa7c80b903aae4215b472f9f8.r4.cf1.rackcdn.com/RackspaceCloudFiles.mp3" type="audio/mpeg" />
<source src="http://0639ac876cdeb83a534d-95c931daa7c80b903aae4215b472f9f8.r4.cf1.rackcdn.com/RackspaceCloudFiles.ogg" type="audio/ogg" />
<em>Sorry, your browser doesn't support HTML5 audio.</em>
</audio>

You may copy the code into your website, replacing the .mp3 and .ogg file links with your own.

Let’s walk through the various parts of the code and explain what they do:

• <audio>: The audio tag initializes the HTML5 audio player. Controls in the opening tag tells the browser to show controls for the audio. In the opening tag, other useful attributes include:
  • Autoplay: Begins the audio as soon as the page loads
  • Preload: Begins loading the audio file as soon as the page loads, rather than when the play button is clicked. This means that the page loads more slowly, but the file is immediately available when the user is ready to listen to it.
  • Loop: Continuously replays the sound file until it is paused.
• <source>: These lines declare different source files and their formats. If there is only one format, a src may be declared in the opening audio tag. However, because no single audio format is compatible across all major browsers, using source tags is the most common way to embed multiple audio formats.
• Incompatibility: The text between the audio tags is displayed only if the browser does not support HTML5. Here, I display a simple message that the browser is incompatible. To see what it looks like, try using Browser Shots on this page or your website, it can show you how an older website displays HTML5 audio content. It is possible to embed JavaScript between the audio tags as a fall-back player for older browsers.

Conclusion

If you have any questions, please post them in the comment section below. Other good HTML5 Audio resources include:

• HTML5 Audio (Wikipedia)
• JPlayer jQuery HTML5 Audio / Video Library (OpenSource)

Check back tomorrow when I’ll discuss supercharging HTML5 video with Rackspace Cloud Files.

For more information on high performance media that’s fast, simple and reliable, be sure to check out the new Rackspace Media Hosting on the Cloud website at: http://www.rackspace.com/cloud/media/.

Background
I decided to use the Akamai Content Delivery Network as a host after reading an article about the use of Jekyll and Akamai in the Obama fundraising campaign. In general, hosting a static website on a CDN gives extremely quick load times with nearly unlimited scalability. However, CDNs were built for delivering content, not whole websites, so making this setup work requires some finagling.

This guide assumes:

• An existing Rackspace account
• Familiarity with cURL statements
• Access to and understanding of your site’s DNS
• Basic familiarity with the Rackspace interface (including access to your API key)
• A working Jekyll site, and a basic understanding of it

Container Creation
In the Rackspace Cloud Files interface, first create a Cloud Files container, then publish it to the CDN. Note the published URL, as it is used to configure the CNAME in DNS, below.

Also decide on a TTL for your domain – this will be the maximum time items are cached. I keep mine at seven days, but this also means that any whole-site changes could take up to a week to propagate. Also note that we can override a TTL with Edge Purge, as discussed below.

DNS
In order to set your URL (ex. www.example.com) to the CDN, set the CNAME record to the published URL of your cloud container that was noted in the above step (omitting the “http://”). For using www.example.com, this means setting the www CNAME to the published URL.

Note: Because Cloud Files requires a CNAME instead of an A record, in general we must use a subdomain. Therefore, the naked domain (e.g. example.com) cannot be used. While it is technically against standards, some nameserver-level services such as Cloudflare allow naked domain CNAME records. I have had limited success with naked domain CNAME records and do not suggest it.

Uploading
After you have configured DNS, the next step is uploading your Jekyll site to the CDN. First, run the command Jekyll to compile your site into the _site folder.

In order to upload my site to the CDN, I use this Jekyll to Rackspace Cloud Files Python script. It requires having Python installed on your computer – if you are unsure of how to do this, Google the directions, because installation on each operating system differs.

Save the script to your root Jekyll directory, and edit it to put in your Rackspace username, API key and container name. To run the file, thus uploading your site to the CDN, use the command:

python cloudfiles_jekyll_upload.py

Warning: Add the uploading script to the exclude in your _config.yml, and consider adding it to your .gitignore. Otherwise, the access credentials for your Rackspace account could be compromised.

Note: You may upload the contents of your _site folder however you wish; I find the above script most efficient, but using the web interface or Cyberduck is equally viable.

Setting a Web Index
If you type in the root URL of your website now, e.g. www.example.com, it will show an error. However, accessing a specific file works – e.g. www.example.com/index.html. This is because, when accessing the root URL, you are not calling a specific file, just the container. We need to tell Akamai which file to show when somebody accesses just the container. Here, we will make index.html the web index of the container, so that visiting www.example.com will show the file at http://www.example.com/index.html.

We do this in two steps using the Rackspace API. First, we authenticate to receive an authorization token, which gives us access to the files for 24 hours, and also to find the CDN URL where we will send our request. Second, we set the container’s web index to index.html.

API Authentication
This step authenticates with Rackspace and gives us an authentication token (valid for 24 hours) to access the container through API. It also gives us the CDN URL for managing your containers.

Note: The CDN URL is different from the published URL for your container that we put in your CNAME record. The CDN URL is obtained through the API, and it gives you the ability to control all of your containers. The published URL is specific to a container, and is the public view of a container’s files. Use the CDN URL for cURL statements / management, and use the published URL to update your DNS records.

In order to obtain an authentication token and in order to see the CDN URL, you need your Rackspace username and Rackspace API Key (available in your Rackspace Account information). Run this cURL command:

cURL -H "X-Auth-User: [Rackspace Username]" -H "X-Auth-Key: [Your Rackspace API Key]" https://auth.api.rackspacecloud.com/v1.0/ -v

In the response, there are two important lines for this guide. X-Storage-Url is your CDN URL, and X-Auth-Token is your authentication token. Record both of these, as we will use them in the next step.

Setting Web Index
Now that we have the authentication token and CDN URL, we can set the web index file using the below cURL command. The command is specific to a container, so you need your container name, which you append to the CDN URL. Here, I am setting the web index to index.html, but you could hypothetically set it to any file in the container.

cURL -X POST -H "X-Container-Meta-Web-Index: index.html" -H "X-Auth-Token: [Authentication Token]" [CDN URL]/[Container Name]/ -v

It should take a few minutes for this to propagate, but you then should be able to navigate to your root URL, e.g. www.example.com, and see the contents of index.html.

Error Pages
Rackspace also allows 401 (unauthorized) and 404 (not found) error pages to be configured for a container. This means that if somebody navigates to www.example.com/nonexistent_file, you can show your own 404 error page instead of the default Rackspace error. This adds professionalism to your site.

To start, you need to add two static pages to Jekyll: 401error.html and 404error.html. Rackspace is a bit idiosyncratic in that you must have both a 401 page and a 404 page to use their custom error pages. The query for configuring error pages is almost exactly the same as creating a web index, and requires information from the preceding API authentication step. Once you have uploaded the error pages and obtained the authentication token and CDN URL, run this cURL statement:

cURL -X POST -H "X-Container-Meta-Web-Error: error.html" -H "X-Auth-Token: [Authentication Token]" [CDN URL]/[Container Name]/ -v

Note that we set the web error page to error.html, even though we created the pages 401error.html and 404error.html. This is because Rackspace preprends the error code to the page we set. Thus, if you want the error pages to be 401request.html and 404request.html, you could update the above statement with request.html in place of error.html.

Pushing Changes with Edge Purge
Updating the site is a simple matter of running the upload script. However, updates on existing pages may not be visible for the time length of your TTL. That means that, if your TTL is one week, it could take one week for your change to propagate through the CDN. This section covers how to override the TTL in order to push changes immediately so that changes are visible in minutes, rather than days.

Updating a Page
If you are updating a single file in the root of your container (e.g. www.example.com/about.html), you can use a basic Edge Purge. Edge Purge overrides the TTL of a file, and resets it across the CDN in a couple minutes.

Executing an Edge Purge is simple through the Rackspace Open Cloud Files control panel. When viewing the contents of the container, click the sprocket on the left and select Refresh File (Purge). The update should then be visible in a few minutes.

If you use Cyberduck to manage your cloud files, the software supports Edge Purge with its “invalidation” command.

Note: Rackspace limits you to 25 Edge Purges per day.

Updating a Page in a Directory
If you have a file at www.example.com/folder/index.html (for example a Jekyll blog post), you can access it three ways:
www.example.com/folder
www.example.com/folder/
www.example.com/folder/index.html

In our structural directories, we see this as one file. However, Akamai uses a flat file database. This means when you upload /folder/index.html it creates three separate files to match the above files. If you Edge Purge the index.html file, only one of the three file paths will be updated:
www.example.com/folder/index.html

The other paths will remain unchanged because Akamai sees them as separate files:
www.example.com/folder
www.example.com/folder/

This is a problem because the permalink structure of Jekyll posts will use the www.example.com/folder/ path in navigation, which does not reflect an update to www.example.com/folder/index.html. Thus, attempting to update a blog post can be difficult.

In order to overcome this, we need to use the API again. We run three separate purges – one for each of the file structures. However, these purges are destructive, meaning that you must upload the corrected file after running these queries.

Run these three queries, subbing in your authorization token, CDN URL and container name. They are structured to delete the file path /folder/index.html; modify the query for folders or sub-folders. In addition, you can insert your email address and Akamai will email you when the purge is complete. In my experience, deleting files through this method takes about 10 minutes.

Delete /folder

cURL -D – -X DELETE -H "X-Auth-Token: [Auth Token]" -H "X-Purge-Email: [Your Email]" [CDN URL]/[Container Name]/folder -v

Delete /folder/

cURL -D – -X DELETE -H "X-Auth-Token: [Auth Token]" -H "X-Purge-Email: [Your Email]" [CDN URL]/[Container Name]/folder/ -v

Delete /folder/index.html

cURL -D – -X DELETE -H "X-Auth-Token: [Auth Token]" -H "X-Purge-Email: [Your Email]" [CDN URL]/[Container Name]/folder -v

At this point, you have successfully deleted the old file. Now, upload your corrected /folder/index.html file, and changes should be reflected online in about five minutes.

Note: Each of these purges counts against your daily limit of 25 Edge Purges through Rackspace.

Site-wide change
If you are making a large-scale change to your Jekyll site (like updating the footer on every page), consider setting up a new container and starting fresh. After re-configuring the index and error pages, updating your CNAME will put the new site live. Rackspace does offer a whole-container edge purge that you may request through a support ticket, but I have found problems with the script (specifically related to the flat file structure) and am currently working with Rackspace to fix these problems.

A Note on SSL
Cloud Files CDN does support SSL delivery, but the certificate is valid only for the Rackspace domain. This means that you cannot use SSL on your own domain using this static site method.

I have been on a discounted trial with my current hosting provider so cost has not been an issue. With the trial concluding, I sought a new host because the convenience afforded by the service does not justify its full cost.

Enter Jekyll
A recent article about the technology behind the Obama fundraising campaign piqued my interest. Their network used Jekyll-generated static pages hosted on the Akamai CDN to accept $250 million in campaign donations. WordPress caching plugins essentially aim to serve the site with static pages, so the idea of generating static pages locally using Ruby then serving a purely static site made logical sense.

Jekyll, however, is not an automated content management system – it requires basic familiarity with Ruby, HTML and CSS. The technical granularity coupled with the ability to version-control the website with Git appealed to me.

Using a CDN to purely serve a website intrigued me most because of the potential for extremely fast speeds with near-infinite scalability. Putting my personal website on Akamai would be like strapping a Kestrel rocket on the back of my Honda Civic.

Switch
The full code for my website is available on Github here. Learning Jekyll and using its plugins proved quite trivial.

The tedious part of the shift was redirecting the permalinks from my WordPress site to the Jekyll site. My previous website was based on the naked domain, whereas using a CDN requires a subdomain (for a CNAME record). Thus, I had to switch both permalink structure and domain. I did this manually with 301 directs in .htaccess served by Heroku. That file is here. After putting the redirects online, I then manually submitted a crawl request through Google for each old page. This process, though tedious, preserves inbound links and SEO.

Rackspace offers access to the Akamai CDN through Cloud Files. Using Akamai with Jekyll required much tinkering because the platform was not designed to serve a full website. After many calls to Rackspace’s Fanatical Support team, I was able to overcome all issues, including caching limitations. I have decided to provide a full guide to interfacing Jekyll with Akamai in a separate forthcoming blog post in order to cover all of these idiosyncrasies in sufficient deal.

Results

With my prior hosting provider, I consistently clocked page load times under two seconds. With this Jekyll implementation, load times closer to 300 milliseconds have been average, with the occasional sub-100-millisecond reading, as shown above (via Pingdom). While these speeds are outrageous, it is exciting to realize that with Akamai as a host this speed is essentially independent of scale, and the network can accommodate nearly any traffic level I could expect.

Of note, though, these page load speeds are so excellent because the site is static content. Making a website scale at these speeds with database queries and sessions would be much more difficult.

This post is the first in a two-part series. Tune in tomorrow for a guide to maintaining a Jekyll website on the Rackspace Cloud Files CDN Network powered by Akamai.