HTTP Streaming.doc

HTTP Streaming: What You Need to Know 理解这种混合交付方法的关键是强大的流媒体解决方案推进 Understanding this hybrid delivery approach is key to advancing robust streaming solutions 由蒂姆Siglin by Tim Siglin 2010年3月11日 March 11, 2010 本文首次出现在2010年流媒体产业的原始资料。 This article first appeared in the 2010 Streaming Media Industry Sourcebook . 在流媒体世界中，有许多术语，制造混乱，以单词分流“，”这是经常使用的术语“渐进式下载互换开始。”即使编解码器的话，形式，制度，包装/容器通常交替使用，尽管不正确。 In the world of streaming, there are many terms that create confusion, starting with the word “streaming,” which is often used interchangeably with the term “progressive download.” Even the words codec, format, system, and wrapper/container are often used interchangeably, albeit incorrectly. 所有的条款，不过，那个似乎周围的最大的不确定性是HTTP流。 Of all of the terms, though, the one that seems to have the most uncertainty around it is HTTP streaming. 由于最近在2007年，这个词很容易被解雇是一个错误，因为HTTP是一种协议，允许的内容将通过80端口路由而流往往需要一个单独的端口。 As recently as 2007, the term was easily dismissed as a mistake because HTTP was a protocol that allowed content to be routed through port 80 while streaming often required a separate port. 在过去的2年，但是，HTTP流已成为现实，无论是实时和点播内容。 In the past 2 years, however, HTTP streaming has become a reality, both for live and on-demand content. 现在反过来，往往混淆另一种技术，可以陪HTTP流的自适应比特率流。 It is now, in turn, often confused with another technology that can accompany HTTP streamingadaptive bitrate streaming. 在这篇文章中，我将解决中美分歧的HTTP流，通用流和渐进下载。 In this article, Ill address the differences between HTTP streaming, generic streaming, and progressive downloads. 我还要提到一个技术位的自适应比特率，即使这些技术是数位新生和球员的主要尚未完全坚定融入HTTP流的技术。 Ill also touch a bit on adaptive bitrate technologies, even though these technologies are a bit nascent and several of the major players have yet to fully firm up the technologies integration into HTTP streaming. 定义HTTP流 Defining HTTP Streaming 因此，一集的定义是从一开始就秩序。 As such, a set of definitions is in order from the outset. 首先，让我们来看看渐进下载，流媒体和混合解决方案。 First, lets look at progressive downloads, streaming media, and hybrid solutions. 渐进式下载 Progressive Download 渐进式下载是一个预编码的文件已被设置为开始播放前的全部下载完成。 A progressive download is a pre-encoded file that has been set to begin playing prior to the completion of the full download. 在过去，一个文件将完全下载之前就开始播放，这意味着用户必须等待（或小时）之前，他或她可以观看录像几分钟。 In the old days, a file would completely download before it began playing, which meant the user had to wait several minutes (or hours) before he or she could watch the video. 为逐步与串流下载混乱的原因是渐进下载的文件播放行为有点像流媒体文件，它通常在3月10日开始播放的文件被选中时秒。 The reason for the confusion of progressive downloading with streaming is that progressive downloaded file playback behaves somewhat like a streaming file, in that it often begins playing within 310 seconds of the time the file is selected. 流往往需要一个缓冲区，并逐步下载，以解决网络不一致;播放后，才首次播放缓冲区开始加载。 Streaming often requires a buffer, as does progressive downloading, to address network inconsistencies; playback begins only after an initial playback buffer is loaded. 随着流媒体，用户可以在任何一个文件沿线的时间表位置单击并开始观看后的缓冲几秒钟的视频。 With streaming, a user can click on any location along a files timeline and begin to watch the video after a few seconds of buffering. 进下载另一方面，需要的文件被下载线性，也就是说，用户的带宽可以限制从前面跳几分钟的用户至少在此之前的视频文件的一部分，已被下载。 Progressive downloads, on the other hand, require the file to be downloaded linearly, meaning that a users bandwidth may constrain the user from jumping ahead several minutes, at least until that portion of the video file has been downloaded. 为了解决这一逐步限制和允许下载命令，如快进，快退，暂停，或位置寻求解决方案提供了一些渐进式下载“的把戏模式”的要求，将分流下载到该用户要求文件的一部分。 To address this limitation in progressive downloads and to allow commands such as fast-forward, rewind, pause, or location seek, some progressive download solutions offer “trick mode” requests that will divert downloading to the portion of the file that the user has requested. 要做到这一点，该文件需要分割的，我们以后会看到的是至关重要的自适应码率发展和HTTP串流传送串流。 To do this, the file needs to be segmented, which well later see is critical to the development of adaptive bitrate streaming and HTTP streaming delivery. 流媒体 Streaming Media 不同于渐进下载，而这往往是从一个HTTP服务器就像一个PDF文件可通过HTTP传送下载，流媒体内容，到现在为止，需要有一个单独的协议来传输流数据包。 Unlike progressive downloads, which can often be downloaded from an HTTP server just as a PDF document can be delivered via HTTP, streaming content has, until now, required the use of a separate protocol to deliver streaming packets. 长标准的实时协议（RTP），这是由视频会议和语音IP的解决方案中使用，是由一个同伴一起，以此来区别于HTTP内容，交通流的具体协议（RTSP），其中最经常使用的端口80，并没有随着时间的作为流媒体内容敏感。 The long-standard real-time protocol (RTP), which was used by videoconferencing and voice-over-IP solutions, was joined by a companion, streaming-specific protocol (RTSP) as a way to differentiate traffic from HTTP content, which most often used port 80 and was not as time-sensitive as streaming content. 不幸的是，一个80端口分流比其他港口的使用也意味着它很容易被发现，而这又意味着流媒体内容可以在路由器阻止由IT部门在保持流从“破坏”自己的网络内容的意图。 Unfortunately, the use of a port other than port 80 for streaming also meant it was easily identified, which in turn meant that streaming content could be blocked at the router by IT departments intent on keeping streaming content from “damaging” their network. 除了先前提到的特技模式，还有一个在流，使内容能够迅速推出创新。 Besides the trick modes previously mentioned, there is another innovation in streaming that allows content to be rapidly launched. 被称为“快速启动”或“暗示”，这种快速分流创新使流媒体服务器，让玩家开始播放无缓冲，几乎保证流媒体内容将开始播放速度比渐进式下载的内容。 Known as “fast start” or “hinting,” this rapid streaming innovation allowed the streaming server to allow the player to begin playback without a buffer, almost guaranteeing that streaming content would begin playing back faster than progressive download content. One example of this is Instant-On, Apples patent-pending streaming technology, which offers content that begins to play as soon its link is clicked. 这一解决方案，对苹果的HTTP直接影响流的自适应比特率的内容解决方案。 This solution has direct bearing on Apples HTTP streaming solutions of adaptive bitrate content. 另一本已在过去对解决网络不一致的一块拼图是用多比特率视频文件的每个编码。 Another piece to this puzzle that has been used in the past to address network inconsistencies is the encoding of multiple bitrates for each video file. 最初的播放要求，包括测量带宽，这引发了一个离散的文件，最紧密匹配用户的预期比特率（四舍五入到下一个最低的比特率选择）。 The initial playback request included a bandwidth measurement, which triggered the selection of a discrete file that most closely matched the users anticipated bitrate (rounded down to the next lowest bitrate). 该解决方案在某些情况下有效，但它假定初始请求的带宽是一致的带宽。 This solution was effective in some instances, although it assumes that the bandwidth of the initial request is a consistent bandwidth. 口吃是内容交付时出现流带宽低于流的最佳比特率下降拖延。 Stuttering is the stalling of content delivery that occurs if the streaming bandwidth falls below the streams optimal bitrate. 即使是多比特率流容易，因为最初的带宽可能不等于持续带宽，这意味着一个可持续的视觉体验不能维持下去。 Even multiple bitrate streaming was susceptible to this because the initial bandwidth may not equal the sustained bandwidth, meaning that a sustainable viewing experience cannot be maintained. 对于点播内容，口吃是烦人。 For on-demand content, stuttering is annoying. 内容传递是暂时停止，后来在采摘后，在缓冲区补充流点了。 Content delivery is momentarily stopped and is later picked up at that point in the stream once the buffer is replenished. 对于生活的内容，但是，这口吃是致命的，如视频或音频流的继续，而观众对他或她是等待网络恢复到足以恢复播出。 For live content, however, this stuttering is deadly, as the video or audio stream continues while the viewer is waiting for his or her network to recover enough to resume the broadcast. 一旦网络恢复，广播流跳过前面拿起实时直播。 Once the network recovers, the broadcast stream skips ahead to pick up the live broadcast in real time. 然而，正如我将在本文后面，在multibitrate流也是关键新兴HTTP流解决方案的基础。 Yet, as Ill cover later in this article, the basis of multibitrate streaming is also key to emerging HTTP streaming solutions. 最后，流在交货方面的一些效率，包括能够消除过多的长式的内容下载，用户可以通过中途放弃。 Finally, streaming has some efficiencies in terms of delivery, including the ability to eliminate excessive downloading of long-form content that a user may abandon partway through. 当涉及到累进下载，具有非常快速连接的用户可以下载不到半年的时间，需要查看该文件的整个视频文件。 When it comes to progressive downloads, users with very fast connections may be able to download an entire video file in less than half the time it takes to view the file. 如果一个用户，然后选择放弃通过观看时间的一半内容，内容提供有“浪费”的下载更多的内容比用户观看了近50的位。 Should a user then choose to abandon the content halfway through the viewing time, the content delivery has “wasted” almost 50% of the bits by downloading much more content than the user watched. 流另一方面，只有在用户提供内容，直到放弃观看的内容，限制浪费的位数。 Streaming, on the other hand, only delivers content until the user abandons viewing the content, limiting the number of wasted bits. 近年来，渐进下载已获得的能力，是扼杀，这意味着只有一个稍微高带宽下载允许无论用户的可能的带宽，这也限制了浪费比特数应用户放弃前一个文件的末尾查看。 In recent years, progressive downloads have gained the ability to be throttled, meaning that only a slightly higher bandwidth download is allowed regardless of the users possible bandwidth, which also limits the number of wasted bits should a user abandon viewing before the end of a file. 节流的渐进式下载的缺点是，它往往限制了观众能够跳过分钟前，而不是几秒钟。 The downside of progressive download throttling is that it often limits the ability for viewers to skip ahead by minutes rather than by a few seconds. 这种效率现在还包裹成HTTP流如果采用自适应比特率。 This efficiency is also now wrapped into HTTP streaming if adaptive bitrates are used. 其他提高效率的一个流媒体文件，是不是在观众的硬盘驱动器保存。 One other efficiency in streaming is that files are not saved on the viewers hard drive. 这通常被认为主要是有利于从权利管理或版权的立场。 This is often viewed as primarily beneficial from a rights management or copyright standpoint. 但在执行效率的是，影片的长度有没有影响的用户数量的硬盘空间需要查看一个视频文件。 But the delivery efficiency is that video length has no bearing on the amount of user hard disk space required to view a video file. 由于流媒体内容，必须restreamed来看待第二次，是渐进式下载内容节流往往也意味着，此内容将被迅速抛弃，需要一个相同内容的第二观看重新下载，除非是做第二次观看后立即在第一次观看。 As streaming content has to be restreamed to be viewed a second time, the throttling of progressive download content often also means that this content will be rapidly jettisoned, requiring redownloading for a second viewing of the same content, unless the second viewing is done immediately following the first viewing.Hybrid solutions 除了流和渐进式下载功能，在过去几年里，带来一个很狭窄的范围内交货之间的两种基本功能的进展，更多的混合解决方案已提出。 Besides the progress of streaming and progressive download features over the past few years, which brings basic functionality between the two types of delivery within a very narrow range, additional hybrid solutions have been proposed. 微软光滑流 微软的光滑流相结合的HTTP传输和自适应比特率技术。 Microsoft Smooth Streaming Microsofts Smooth Streaming combines HTTP delivery and adaptive bitrate technology. 有三个主要的需求推动了这些混合解决方案：效率，可扩展性和普遍性。 Three major needs have pushed these hybrid solutions forward: efficiency, scalability, and ubiquity. 在效率方面，有许多用于包装RTSP流成HTTP数据包视频流量过去的解决方案。 On the efficiency front, there are numerous past solutions that wrap RTSP streaming video traffic into HTTP packets. “透过RTSP流 HTTP数据包.看来相同标准的网站流量，因此通过大多数防火墙允许的，”苹果公司表示在对RTSP和HTTP流之间的差异文件。 “RTSP streaming via HTTP packets appear identical to standard web traffic and therefore are permitted through most firewalls,” Apple stated in a document about the difference between RTSP and HTTP streaming. “这涉及到1架空层额外然而，在一个更大的带宽需求造成的。” “This involves an extra layer of overhead however, resulting in a greater demand for bandwidth.” 闪光HTTP流是另一个例子。 Flash HTTP streaming is another example. 到Adobe的它的HTTP /自适应比特率的解决方案公布截至（这并没有为写这篇文章时发射）指任何人作为HTTP流实际上是HTTP隧道闪烁。 Up until Adobes announcement of its HTTP/adaptive bitrate solution (which had not launched as of the time of this writing) anyone referring to Flash as HTTP streaming actually meant HTTP tunneling. 此用词不当，理由是相当简单：闪光服务器所使用的实时媒体协议（RTMP协议）的目的是要交付的TCP而不是UDP的较传统的RTSP提供热气腾腾的协议。 The reasoning for this misnomer is fairly simple: The Flash server that used the real-time media protocol (RTMP) was designed to be delivered on TCP rather than the UDP delivery of the more traditional RTSP steaming protocol. 鉴于RTMP数据的能力，提供通过TCP，Adobe公司的综合RTMP数据通过HTTP隧道的实时和点播内容。 Given RTMPs ability to deliver via TCP, Adobe integrated RTMP tunneling via HTTP for both live and on-demand content. 这似乎相当于HTTP流。 This appears equivalent to HTTP streaming. 但事实上，隧道工程，导致了一个额外的延迟，可能无法在所有情况下可以接受的一点。 But the tunneling, in fact, causes a bit of an extra delay that might not be acceptable in all situations. 基于效率的限制，Adobe和苹果公司选择了走向真正的HTTP移动流媒体解决方案。 Based on the efficiency limitations, both Adobe and Apple have chosen to move toward true HTTP streaming solutions. 苹果公司推出HTTP流，存储区域网络自适应比特率流，为在2007年时推出iPhone手机。 Apple debuted HTTP streaming, sans adaptive bitrate streaming, for the iPhone when the phone launched in 2007. 有些内容交付网络（CDN）供应商是指在其任期HTTP来下载视频文件的HTTP或HTTP下载流进步。 Some content delivery network (CDN) vendors refer to their HTTP video file downloads or HTTP progressive downloads by the term HTTP streaming. 在扩展性方面，要坚持规模内容的电视级的观众在任何一天，而无需为每个网络电视事件预案星期，导致解决方案的讨论，使分流到规模，这些水平。 In terms of scalability, the need to consistently scale content to television-level audiences on any given day, without requiring weeks of preplanning for every web television event, has led to discussions of solutions that will allow streaming to scale to these levels. 在文章的最后，我将讨论多播和同行的对等解决方案的交付作为长期的。 At the end of the article, Ill discuss multicasting and peer-to-peer delivery as long-term solutions. 短期解决方案是一个渐进的分流和下载的利益相结合。 The short-term solution is a combination of the benefits of streaming and progressive downloading. 最后，在普及方面，如前面提到的，很多的RTP / RTSP协议的交通阻断了防火墙的高数量，使其难以提供流可靠。 Finally, on the ubiquity front, as previously mentioned, much RTP/RTSP traffic is blocked by a high number of firewalls, making it difficult to deliver streams reliably. 甚至是即时通讯的音频和视频会议功能，例如由Skype或iChat使用的，依赖于RTSP协议。 Even instant messaging audio and video conferencing capabilities, such as those used by Skype or iChat, rely on RTSP. 甚至超出了典型的防火墙，但是，是能够处理不同类型的内容交付网络。 Even beyond the typical firewall, however, is the ability to handle content delivery between different network types. 苹果公司选择去到HTTP串流的iPhone主要基于概念的RTSP视频流媒体的iPhone将是一个设备，通常与全球移动系统的移动（全球通）和Wi - Fi网络的困难。 Apple chose to go to HTTP streaming for the iPhone primarily based on the concept that RTSP video streaming on the iPhone would be difficult for a device that routinely moves between Global System for Mobile (GSM) and Wi-Fi networks.HTTP Streaming Meets Adaptive Streaming 流通过HTTP下载没有进步带来的额外好处，将是一个微乎其微一点，因为从双方的利益传递选项形态是为了提高效率，可扩展性很重要，无处不在。 Streaming via HTTP, without the additional benefits of progressive downloading, would be a bit of a nonstarter because the gestalt of benefits from both delivery options are important for efficiency, scalability, and ubiquity. 为了实现共同利益的，HTTP流解决方案所需的另一个方面，这是所谓的，一般地，自适应比特率流。 To realize the joint benefits, HTTP streaming solutions needed another aspect, which is called, generically, adaptive bitrate streaming. 这种混合方法，如流媒体传输的行为，但使用渐进式下载，它使用传统的HTTP流量如端口80，同时，在一小块系列内容。 This hybrid media delivery method acts like streaming but uses progressive downloadit uses port 80 like traditional HTTP traffic and delivers content in a series of small chunks. 这不是multibitrate老流如前所述，其中一个文件的多个版本的完整编码和一个版本是在用户的要求，首先选择观看。 This is not the multibitrate streaming of old as previously mentioned, where several full versions of a file were encoded and a single version was chosen at the outset of a users viewing request. 每个自适应比特率流文件具有明显的比特率，但是每个文件，然后分割到小“块2-10秒”，以一致的每个文件之间的同时所有块。 Each adaptive bitrate streaming file has a distinct bitrate, but each file is then segmented down to small “chunks” of 210 seconds, with all chunks aligned simultaneously between each of the files. 像multibitrate流，自适应比特率流选择一个特定的比特率流最初单一的文件。 Like multibitrate streaming, adaptive bitrate streaming chooses a single file of a particular bitrate to initially stream. 一旦比特率选择，单块（或数块，根据技术供应商）立即开始播放。 Once the bitrate is chosen, a single chunk (or several chunks, depending on the technology provider) begins to play immediately. 额外的块之前被发送，但是，用户的播放机发回的资料，另一组可用带宽的服务器，然后选择是否继续派遣当前文件块，或切换到一个不同带宽的文件。 Before additional chunks are sent, however, the users player sends back another set of available bandwidth information to the server, which then chooses whether to continue sending chunks from the current file or to switch to a file of a different bandwidth. 这个决策的过程也发生在整个流媒体多次会议，可容纳网络波动都降低，提高可用带宽。 This decision-making process happens multiple times throughout a streaming session and can accommodate network fluctuations that both lower and raise the available bandwidth. 有什么大不了的？ Whats the Big Deal? 那么，为什么是HTTP流重要？ So why is HTTP streaming important? 首先，在以前的解决方案价格的基础上，HTTP的流媒体传输的成本可能最终会被比传统的RTP / RTSP服务器的解决方案为低。 First, based on the pricing of previous solutions, the costs of HTTP streaming delivery may end up being lower than that of traditional RTP/RTSP server solutions. 我说“可能”有两个原因：第一，这是历史性的价格在那里有一些CDNs提供基本的HTTP渐进式下载送货服务结构为基础，而不称他们为HTTP串流，并已收取本不是真正流媒体传送服务少;第二， HTTP服务器是非常符合成本效益，而且有能力在一个HTTP的规模比传统的流媒体服务器价格低廉的服务器。 I say “may” for two reasons: first, this is based on historic pricing structures where some CDNs have offered basic HTTP progressive download delivery services, without calling them HTTP streaming, and have charged less for this service than true streaming delivery; second, HTTP servers are extremely cost-effective, and there is the ability to scale HTTP servers at a lower price than traditional streaming servers. 第二个原因HTTP流是重要的，如前面提到的，是真正的HTTP流提供了能够推动视频流通过端口80，这是许多防火墙打开，以便让传统的网络通信是通过HTTP传递的内容，同时还保留的能力，油门回上方的播放器的内容，数据传输速率。 The second reason HTTP streaming is important, as previously mentioned, is that true HTTP streaming provides the ability to push video streaming content through port 80, which is open on many firewalls in order to allow traditional web traffic that is delivered via HTTP, while still retaining the ability to throttle back the content to a data rate just above that of the player. 例如，微软的HTTP流协议“是在一个固定的速度流或数据传送速率密切关联的1速率的视频将被接收器显示合适。” For instance, Microsofts HTTP Streaming Protocol “is suitable for streaming delivery at a fixed rate or at a data rate correlating close