7

我试图了解并真正确定何时在 flex/flash 中使用渐进式下载与 rtmp。似乎主要的一点是 rtmp 不与 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 似乎更有用？这就是它的全部吗？

4

3 回答 3

6

我同意xtat，但想补充更多。

RTMP（或任何基于 UDP 的流式传输协议）与“渐进式下载”（实际上只是基于 HTTP 的流式传输的一个子集）的优缺点，在我看来并不那么谦虚：

  • 基于 UDP 的流式传输
    • 优点
      • 目前盗取数据流的难度要大得多
      • 目前支持直播，基于 HTTP 的不支持
      • 多播能力，这在 Intranet 上可能是可取的
    • 缺点
      • 相对于基于 http 的方法，资源使用率显着提高
      • 需要专门的服务器（FMS、Red5、Wowza 等）
      • 更明显的缓冲
      • 防火墙问题，尤其是企业客户
  • 基于 HTTP 的流式传输
    • 优点
      • 死简单
      • 可以找媒体。FLV 和 MP4（努力）
    • 缺点
      • 微不足道的偷溪流。例如：真正的下载器
      • 目前无法进行直播，但给它一年时间。苹果正在使这成为现实。
      • 没有多播

整个基于 HTTP 的方法充满了and/but/if情况，对什么是可能的和不可能的有很多误解，并且缺乏共同的定义。

人们在讨论基于 HTTP 的流式传输时会考虑两个基本特征：寻找和调节带宽。由此，我们得到了所有这些术语，如“伪流”、“渐进式下载”等。

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

  • 调节比特率：平面媒体文件由服务器解析，并以播放器播放媒体所需的速度发送媒体，无需缓冲。
  • 搜索：网络服务器搜索媒体并在运行中有效地创建新的“文件”以供客户端使用的能力。类似于 http 字节范围请求，除了添加/修改标头和媒体元数据。
  • 渐进式下载：尽可能快地发送文件。基本上，将媒体文件放在以“愚蠢”方式发送到客户端的 Web 服务器上，例如大型 .iso 或 .zip 文件。
  • 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.
于 2009-11-17T09:30:26.013 回答
2

就个人而言，选择 RTMP 而不是渐进式下载的主要原因是它允许您的用户跳到视频的中间而无需下载整个文件。

于 2009-11-17T01:55:14.260 回答
2

这些天，除非您需要录制，否则使用 RTMP 没有任何意义。HTTP 更简单，显然支持更广泛，更易于调试，并且确实允许搜索，甚至通过 CDN。这是我在 Viddler 设置的。

于 2009-11-17T04:00:04.110 回答