flash/flex：渐进式下载与 rtmp

我试图理解并真正确定何时在 Flex/flash 中使用渐进式下载与 rtmp。看来主要的一点是 rtmp 不与 http 一起提供服务，而渐进式下载则由 http 提供。由于它不是 rtmp，因此资源受到保护，因为无法从 swf 外部连接到 rtmp 服务器。

即使用户可以看到该目标代码并且可以找出位置

<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>

他们将无法连接到 rtmp。那么当你想保护资源时 rtmp 似乎更有用？这就是全部内容了吗？

我同意xtat，但还想添加更多。

在我不那么谦虚的观点中，RTMP（或任何基于 UDP 的流媒体协议）与“渐进式下载”（实际上只是基于 HTTP 的流媒体的子集）的优缺点：

• UDP-based streaming
  • Pros
    • 目前窃取流的难度要大得多
    • 目前支持直播，基于HTTP不支持
    • 具有多播功能，这在 Intranet 上可能是理想的
  • Cons
    • 相对于基于 http 的方法，资源使用率显着提高
    • 需要专门的服务器（FMS、Red5、Wowza 等）
    • 缓冲效果更明显
    • 防火墙问题，尤其是企业客户的防火墙问题
• HTTP-based streaming
  • Pros
    • 简单极了
    • Can寻求媒体。 FLV 和 MP4（需要一些努力）
  • Cons
    • 窃取流是微不足道的。例如：真实下载器
    • 目前无法进行直播，但请等待一年。苹果正在让这成为现实。
    • 没有多播

整个基于HTTP的方法充满了和/但是/如果对什么是可能的、什么是不可能的存在很多误解，并且缺乏共同的定义。

在讨论基于 HTTP 的流媒体时，人们会关注两个基本特征：seeking and 调节带宽。由此，我们得到了所有这些术语，如“伪流”、“渐进式下载”等。

这些是我用来描述基于 HTTP 的流服务器的定义：

• 调节比特率：平面媒体文件由服务器解析，并根据播放器播放媒体所需的速度发送媒体，无需缓冲。
• seeking：网络服务器寻找媒体并有效地动态创建新“文件”以供客户端使用的能力。与 http 字节范围请求类似，只是添加/修改了标头和媒体元数据。
• 渐进式下载：只要尽快发送文件即可。基本上，将媒体文件放在以“哑”方式发送到客户端的 Web 服务器上，就像大型 .iso 或 .zip 文件一样。
• 伪流式传输：Web 服务器以规定的比特率向客户端发送媒体文件并查找文件的能力。