flash/flex: progressive download vs. rtmp

Question

I'm trying to understand and really pinpoint when to use progressive download vs. rtmp in flex/flash. It seems that the main point is that rtmp is not served with http, whereas progressive download is. Since it's not rtmp, the resource is protected since there is no way to connect to the rtmp server from outside the swf.

Even if the user can see that object code and can figure out the location

<object data="http://media.example.com/jw-player/player.swf" >
    <param value="streamer=rtmp://sub.example.com/video
           &amp;file=1330/title/folder2/theflvresource.flv
           &amp;id=FlvPlayer" name="flashvars">
</object>

they would not be able to connect to rtmp. So rtmp seems to be more useful when you want to protect a resource? Is that all there is to it?

Answer 1

Personally, the main reason to choose RTMP over progressive download is it allows your user to skip to the middle of a video without having to download the whole file.

Answer 2

These days unless you need to record, there's not really any point to using RTMP. HTTP is simpler and obviously much more widely supported, easier to debug and indeed it does allow for seeking, even over CDNs. This is what I have set up at Viddler.

Answer 3

I agree with xtat, but want to add much more.

The pros and cons of RTMP (or any UDP-based streaming protocol) vs. 'progressive download' (which is really just a subset of HTTP-based streaming) in my not-so-humble opinion:

• UDP-based streaming
  • Pros
    • Currently significantly more difficult to pilfer streams
    • Currently supports live, which HTTP-based does not
    • Multi-cast capable, which can be desirable on intranets
  • Cons
    • Dramatically higher resource usage, relative to http-based approach
    • Need for specialized servers (FMS, Red5, Wowza, whatever)
    • More noticeable buffering
    • Firewall issues, especially with corporate customers
• HTTP-based streaming
  • Pros
    • Dead simple
    • Can seek into media. FLV and MP4 (with some effort)
  • Cons
    • Trivial to pilfer streams. E.g.: Real Downloader
    • Live streams not currently possible, but give it a year. Apple is making this a reality.
    • no multi-casting

The entire HTTP-based approach is filled with and/but/if situations, lots of misunderstandings about what is and is not possible, and a lack of common definitions.

There are two basic characteristics people are looking at when discussing HTTP-based streaming: seeking and regulated bandwidth. From that, we get all these terms like 'pseudo-streaming', 'progressive download', etc.

These are the definitions I use to describe HTTP-based streaming servers:

• regulated bit-rate: The flat media file is parsed by the server, and it send media as fast as the player needs to play the media without buffering.
• seeking: the ability of a web-server to seek into the media and effectively create a new 'file' on the fly for use by the client. Similar to an http byte-range request, except that headers and media meta data are added/modified.
• progressive download: Just send the file, as fast as possible. Basically, put media file on web server that sends to client in a 'dumb' manner, like like a large .iso or .zip file.
• pseudo streaming: the ability of a web server to send media files to the client with a regulated bit-rate and to seek into files.