Possible to stream videos using Amazon S3/CloudFront with HTML5 player?

Something I have done successfully recently is to use the Video.js HTML5 player (open source) video player, with videos hosted on S3. Basically you just upload your video into your S3 bucket, then the code on the page looks something like this (after including the Video.js CSS and JS files into your page):

<video id="example_video_1" class="video-js vjs-default-skin"
    controls preload="auto" width="1600" height="900"
    poster="http://mys3bucket.s3.amazonaws.com/videoImage.jpg"
    data-setup='{"example_option":true}'>
    <source src="http://mys3bucket.s3.amazonaws.com/myvideofile.mp4" type='video/mp4' />
    <source src="http://mys3bucket.s3.amazonaws.com/myvideofile.webm" type='video/webm' />
</video>

poster is just the still image to display on the video player while the video is loading or not playing. As for the <source> tags, you can link as many or as few of these as you have videos for. More formats just means better support across different platforms (e.g. some vanilla Linux distributions may not play MP4 etc.).

See the Video.js quick start guide here.

When deciding whether to use S3 or CloudFront: IMHO S3 is more appropriate for video in general because the cost is cheaper when you're storing a lot of data (because CloudFront distributes copies of everything to all of its edge servers, although you can limit that somewhat via options). Some people do prefer CloudFront though due to the speed, although remember CloudFront is intended primarily as a content delivery network where super fast response times are required (e.g. for site graphics, stylesheets, JS files etc.), so it's a trade-off depending on your needs. If your videos are all very small then you may find CloudFront actually is appropriate for your needs.

For analysing costs more definitively you can use Amazon's monthly cost calculator.

Much of what @Wayne Koorts posted provides the basis for a good answer. The disconnect it seems is that you can "stream" video via progressive download. This works with any html5 compatible video file, as he illustrated.

In order to get the best performance in a progressive download of mp4 files, you need the moov atom meta data to appear at the beginning of the file. Insuring that your mp4 files have this property is one of the reasons that the qtfaststart program is included with ffmpeg.

Of course, progressive download is not a "streaming media server". Streaming media servers were designed to support a number of different features including:

• Security and DRM
• Adaptive streaming/interleaving (support for multiple bit rates interleaved into a specific file)
• Seeking

It seems the particular concern expressed here is the seeking feature. As it happens this is supported fine in html5 and by s3/cloudfront.

What is confusing is that cloudfront of video files has several options. One option is to have the files delivered by their network of licensed Adobe FMS servers. This is where the confusion about the use of RTMP comes into play. However, that is only an option. Files can be distributed to cloudfront in standard "download" form and they will have the seeking property due to the implementation of byte ranges and support for what is popularly known as pseudo streaming.

There seems to be a lot of confusion about the term "Pseudo streaming" but in the case of html5, it's simply the requirement that the HTTP server supports the 1.1 specification. When seeking, the client sends a byte range request and the server is responsible for delivering that portion of the file.

In other words... seeking with the html5 player does work with the cloudfront servers because they are HTTP 1.1 compatible.

As for some of the other functions that streaming servers provide, there are a variety of competitive servers that have implemented "H264 streaming" or elements of MPEG-DASH as an alternative to the use of RTMP and FMS compatible servers. A number of flash based players support these functions, which go above and beyond simple seeking. The JWPlayer and Flowplayer are 2 examples of players that support some or all of the features, however HTML5's video player has no support for any of these features. You can learn more looking at http://h264.code-shop.com/trac#H264StreamingModuleIntroductionversion2

If that's not enough confusion for you, Apple implemented their own "HTTP Live Streaming" protocol, sometimes known as m3u8, which they support in ios and quicktime. I mention this because frequently people want a way to support a variety of different devices.

I hope this helped clarify things a bit.