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?

Eductive

Answer 1

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.

Immortal

Answer 2

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.

Selfeffacement

Hmm, are you sure this is limited to progressive download? I think I heard someone from one of the video sites (maybe youtube, but I could be wrong) say that they use progressive download for their videos, but you can still skip and start watching from the middle a part that has not downloaded yet. – Eductive

I believe youtub is a hybrid of some sort, but those videos are def streaming... true progressive you have to wait for each byte to download before you can play it – Pedo

'true progressive download'? You say that like there is a spec. Youtube.com seeks by making another HTTP-request. Their servers then seek to the middle of the file, pad the appropriate headers, and send the media from that point. It is not rocket science. Research terms like mod_flv and mod_h264_streaming for details. – Immortal

Let me clarify -- I meant it worked out of the box with no fiddling. I'm aware that a savvy IT/Ops dept. can make this work without an RTMP server, but generally if you're doing Flash work for a client (98% of Flash work, as far as I can tell) you want something you can install (or have any random dude install) and then drop when you leave for your next project. – Selfeffacement

this is false, because of HTTP Range Requests, players will use an http request to get the specific chunk of a file when the user seeks. – Helbona

You're probably right, now. In 2009 when I wrote that comment none of my clients supported HTTP range requests. – Selfeffacement

Answer 3

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.

Blasien

Interesting, but are you talking about True HTTP Streaming or a modified http progressive download? I might look at Viddler since they appear to have some white-label services I wasn't aware of, but I'm still interested in understanding the technology. – Eductive

IMO the term 'progressive' is misleading, but that's what we're doing :) – Blasien

trying not to be too market-y -- feel free to send any questions my way todd at viddler : ) – Blasien