flash / flex：渐进式下载与rtmp [英] flash/flex: progressive download vs. rtmp

问题描述

我试图理解并确定什么时候使用渐进式下载与flex / flash中的rtmp。看来，主要的一点是rtmp没有与http服务，而渐进式下载是。由于不是rtmp，资源是受保护的，因为无法从swf外部连接到rtmp服务器。

即使用户可以看到该对象的代码，并可以计算出位置

 < object data =http://media.example.com/jw-player/player.swf> 
 & amp; amp; amp; file = 1330 / title / folder2 / theflvresource.flv 
& amp; amp; amp; amp; amp; id = FlvPlayername =flashvars> 
< / object> 
  

他们将无法连接到rtmp。所以当你想要保护资源时，rtmp似乎更有用。这是所有的吗？

解决方案

我同意 xtat 更多。

RTMP（或任何基于UDP的流媒体协议）与渐进式下载（它实际上只是基于HTTP的流媒体的一个子集） ）在我不庸俗的意见：

• 基于UDP的流
  
  
  
  
  • 赞成
    
    
    
    
    • 目前盗版流明显困难
    
    
    • 目前支持live，基于HTTP
    
    
    • 
      
    • 
      
    • 
      
      $ b
      
      
      • 相对于基于http的方式，资源使用量明显增加
        
      • 需要专门的服务器（FMS，Red5，Wowza等等）
      
      
      • 更明显的缓冲功能
      
      
      • 防火墙问题，尤其是公司客户
      
      
    
    
  
  
  • 基于HTTP的流量ming
    
    
    
    
    • 优点
      
      
      
      
      • 死简单
      
      
      • 可以寻找媒体。 FLV和MP4（有些努力）
        
        
        $ b
        
        
        • 琐事偷盗流。例如：Real Downloader
        
        
        • 实时流不是现在可能的，但是给它一年。苹果正在把这变成现实。 没有多播广播
        >
        
        

        整个基于HTTP的方法充满了和/但/ if 的情况，对于什么是不可能的误解，以及缺乏通用的定义。在讨论基于HTTP的流媒体时，人们正在考虑两个基本特性：搜索和规定的带宽。从这一点上，我们得到了所有这些术语，如伪流，渐进式下载等。
        
        这些是我用来描述基于HTTP流媒体服务器： b
        $ b

        
        
        • 规定比特率：平面媒体文件由服务器解析，快速，因为玩家需要播放媒体而不缓冲。
        
        
        • 寻找：网络服务器寻找媒体的能力，并有效地创造一个新的文件，供客户使用。类似于http字节范围请求，除了标题和媒体元数据被添加/修改。
          
        • 渐进式下载：只需发送文件，可能。基本上，将媒体文件放在Web服务器上，以哑的方式发送给客户端，就像一个大的.iso或.zip文件一样。
          
        • 伪流媒体 ：Web服务器以规定的比特率将媒体文件发送到客户端并查找文件的能力。
        
        
        
        

        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?

        解决方案

        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.

        这篇关于flash / flex：渐进式下载与rtmp的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！