Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So I've been bouncing between CDN's trying to optimize our serving solution. We're serving short video clips into our code that display either an html5 video element (MP4 or OGG) or a flash swf (FLV) as a fallback.

We're using Amazon S3 for the storage of these media files and CloudFront as our content delivery network. We've been experimenting with the flash fallback using CloudFront's Flash Media Server distribution and we're streaming the FLV into the Flash fallback. This works great :)

However, I'd like to accomplish the same setup (Origin > Streaming CDN > Client) with the MP4 and OGG files into the HTML5 placement. To do this, I need to stream them over RTP or RTSP, rather than CloudFront & FMS's RTMP.

So far I haven't had much luck finding a CDN that supports RTSP streams. Is there a way to use CloudFront's Streaming Server and somehow convert the stream protocol into RTSP using the mp4 and ogg as the source files?

(I should also note that price is a fairly big factor here. The project is sort of dependent on the price point on a per TB/GB/MB level.)

share|improve this question

1 Answer 1

I don't believe there is pervasive support for the RTSP/RPT protocols in HTML5 browsers. Apple devices might be able to use RTSP, and perhaps IE9 will as well (since older Windows Media servers also used RTSP before the advent of Smooth Streaming in Silverlight). But the HTML5 standard does not define protocols or codecs to be used.

Our current video serving logic is:

  1. use MP4 at multiple bit-rates with HTTP Dynamic Streaming via flash if Flash 10.1 or higher is installed

  2. Fallback to MP4 with progressive download over HTTP in a Flash player if flash v9 or higher is present

  3. Fallback to HTML5 video with source elements for both MP4 and WebM files, which lets the browser sort it out. MP4 is listed first and is therefore preferred. This is also HTTP progressive download.

This scheme gets us 99+% delivery to all our viewers, which are mostly corporate and not home users. Corporate firewalls and dedicated streaming protocols like RTMP and RTSP generally don't mix in our experience - they are often blocked. Very few of our visitors can even receive an RTSP or RTMP stream through their firewall, and the "solution" of tunneling RTP or RTMP inside an HTTP stream is less bandwidth-efficient that just simple HTTP download.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.