httplivestreaming协议.docx
- 文档编号:29274027
- 上传时间:2023-07-21
- 格式:DOCX
- 页数:10
- 大小:22.82KB
httplivestreaming协议.docx
《httplivestreaming协议.docx》由会员分享,可在线阅读,更多相关《httplivestreaming协议.docx(10页珍藏版)》请在冰豆网上搜索。
httplivestreaming协议
竭诚为您提供优质文档/双击可除
http,live,streaming,协议
篇一:
http-live-streaming-architecture
(1)
http-live-streaming-architecture
(原文地址)
一般来说,httplivestream是由三部分组成的:
服务组件部分,视频分布存储组件部分,客户端软件部分。
服务组件部分(server):
这个一般是用来进行视频数据的录入以及编码过程,把他们按照一个统一的数据格式进行编码用来传递以及为视频存储组件部分做准备。
视频存储分布组件部分(distribution):
这个部分一般是有一个标准的web服务器构成的,他们用来相应客户端的请求以及传递已经处理好的相应请求多媒体信息。
对大规模的分布,edge网络或其他内容分发网络也可以使用。
客户端软件部分(client):
客户端软件负责确定适当的媒体来请求,下载这些资源,然后重新组装它们,这样的媒体可以呈现给用户一个连续的流。
客户端软件包含在ios3.0和以后和电脑安装了safari4.0或更高。
在一个典型的配置、硬件编码器需要音像输入,将其作为h.264视频和aac音频,并将这些内容作为mpeg-2数据流传输,然后由软件流分段程序分解成一系列简短的媒体文件,这些文件放置在web服务器。
这个分段程序还创建并维护索引文件包含一个媒体文件的列表。
索引文件的uRl用来发布到web服务器上。
客户端软件读取索引,请求媒体文件,并将其显示出来,并且用户感觉不到任何的停顿或段之间的差距。
如下是一个大致的架构图
其中输入源可以非为直播输入源或者已经准备好的输入源。
通常我们需要把他们数字化编码为mpeg-4(h.264视频,aac音频)然后再包装成mpeg-2的格式通过商用软件进行传递。
mpeg-2的编码流然后会被切割成许多个小的片段(.ts文件)保存起来,这个过程我们通常是使用苹果的streamsegmenter小工具来完成的.
其中需要注意的就是,当如果仅仅是音频流的话只支持aac类型的并且是adts打头的文件,或者是mp3文件。
苹果的这个分段程序(streamsegmenter)还创建一个索引文件。
索引的文件中包含了一系列媒体文件。
索引文件还包含元数据。
索引文件是一个".m3u8"播放列表。
索引文件的uRl是由客户机访问,然后请求索引文件在序列。
服务组件部分(server)
这个部分需要一个媒体编码器,可以采用商用软件.然后再把编码之后的文件进行一个切割保存。
其中切割保存的这个部分可以采用苹果的软件mediastreamsegmenter来完成。
媒体编码器
媒体编码器通过一个外置设备(摄像机等)来获取一个数据信号,然后再进行一个编码,封
装和传递。
其中编码应该按照h.264的视频格式,he-aac的音频格式。
目前传递的数据编码格式只能是mpeg-2的视频或者是mpeg的音频。
然后通过网络把mpeg-2编码格式的数据流进行一个网络传输,并利用streamsegmenter来进行文件的切割。
文件流切割器(streamsegmenter)
文件切割器一般是从网络中读取已经编码好的流文件,然后把他们根据一个时间间隔切割成许多个很小的单元文件。
虽然每段是在一个单独的文件中,但是这些视频文件是可以无缝地重建。
这个分段程序还创建一个索引文件包含单个媒体文件的引用。
每次分段程序完成了一个新的媒体文件,索引文件被更新。
索引用于跟踪和确定媒体文件可用性和位置。
这个分段程序也可以对每个媒体加密并且创建密钥文件。
媒体将会以为".ts"文件形式保存起来(mpeg-2的可传递的流文件)。
索引文件保存将会以".m3u8"播放列表形式保存起来。
文件切割器(Filesegmenter)
如果你已经有了编码好的文件,那么你只需要使用文件切割器把这个文件包装成mpeg的流,然后再把他们按照一定的时间长度进行一个切割。
这个文件切割器跟文件流切割器的区别就是,文件切割器一般会选取已经存在的文件进行一个切割。
多媒体切割文件组(mediasegmentFiles)
切割之后的多媒体片文件组一般是由文件流切割器产生的,一般是通过一个数字化编码器中录入的,通常是有多个".ts"的片文件组成,并且是通过mpeg-2的传输流(h.264的视频和aac的音频)来进行传递.通常对于音频文件的传递,这个切割器能够产生mpeg的格式.要么是aac的音频格式并且包含adts,或者直接就是mp3的文件。
索引文件(播放列表文件)
索引文件通常是由数据流切割器或者文件切割器产生的。
通常是以".m3u8"的文件形式保存起来的。
对于是mp3的文件一般会以".m3u"的形式保存起来。
注意一下,你同时也可以采用苹果公司提供的文件切割器进行对于mpeg-4编码的视
频文件进行切割或者对aac或者是mp3的音频文件进行切割。
索引文件还可能包含加密密钥文件的url和备用索引文件针对不同的带宽,为了获取更多详细的信息,你可以参考httplivestreamingspecification.
通常索引播放文件都是自动产生的,但是这并不代表你不能手动创建或者修改。
特殊的情况下,我们是可以手动创建一个".m3u8"类型的文件,然后通过编辑器对这个文件进行一个修改。
只要你编译后的文件时适合发布的标准的都是ok的。
对于音频的文件,我们开业创建一个".m3u8"类型的文件,然后添加一些mp3格式的文件。
视频存储分布组件部分(distribution)
这个存储分布系统是有一个web服务器或者一个web的缓存系统通过http协议来进行索引文件和切割的小文件传递。
这个服务器并不一定需要做什么复杂的配置,通常只需要做一些典型的配置就ok了。
通常在配置的时候我们需要做如下的内容限制。
索引文件一般是以".m3u8"文件形式保存,切割的单个小文件是要以".ts"的文件存储
需要注意的就是对于直播类型的".m3u8"文件是在随着时间不停的变化的,应为直播的内容是不固定的,所以这个文件就在不停的进行重写。
因此我们就需要考虑到一个缓存的问题,添加一个版本的信息,确保每次客户端进行读取的时候都是最新的文件。
客户端软件部分(client)
客户端一般是通过请求索引播放列表文件来获取具体的文件播放地址,然后获取相对应的文件流进行数据的播放。
在获取的时候一般是采用按照一定序列的方式进行下载播放。
当有足够多的流可以进行播放的时候,客户端就可以开始播放组装好的流。
同样,客户端也是需要获取,或者提供用户认证的界面,从而进行解密,达到视频播放的效果。
通常当客户端读取的索引文件如果遇到“#ext-x-endlist”标志的时候就会终止,但是如果没有“#ext-x-endlist”这个标志,那么一般可以理解为是在线直播。
在直播期间,客户端会随着时间进行一个索引文件的更行。
客户端呢然后就寻找更新好的信息,然后再添加到播放队列中去。
篇二:
浅谈httpadaptivestreaming技术及其前景
浅谈httpadaptivestreaming技术及其前景(20xx-09-0217:
40:
05)
转载▼
关键词:
ott流媒体httpadaptivestreaming
本文已发表于《世界宽带网络》20xx.6第18卷第5期总200期
httpadaptivestreaming(以下简称“has”)技术结合了传统的流媒体技术和http渐进式下载播放的特点,以http的方式向用户传送媒体内容,该技术的采用可以大大提升用户的媒体播放体验,同时该技术降低了头端服务器的技术复杂度。
基于http的传送方式提升了媒体内容在网络设备中的穿透能力,该技术目前已成为流媒体视频行业发展的趋势。
一、传统流媒体技术
近些年,互联网视频迅猛发展,视频内容的流量已占到了整个互联网流量的一半。
谈到互联网视频就不得不提到流媒体技术,正是流媒体技术的不断发展促进了目前互联网视频的迅猛发展。
传统的媒体内容分发技术主要有两大类,一类是以Rtsp/Rtp(Realtimestreamingprotocol/Realtimetransferprotocol)为代表的面向连接的流媒体技术,另一类则是目前主流视频网站采用的无连接的http渐进式下载。
1.Rtsp/Rtp的流媒体方案
Rtsp是一种传统的流媒体控制协议,其具有状态性的特点意味着从一个客户端开始连接至服务端一直到连接中断的整个过程,服务端会一直监听客户端的状态。
客户端通过Rtsp协议向服务器传达控制命令,如播放、暂停或中断等。
Rtp/Rtcp(Realtimetransfercontrolprotocol)是端对端基于组播的应用层协议。
其中,Rtp用于数据传输,Rtcp用于统计、管理和控制Rtp传输,两者协同工作,能够显著提高网络实时数据的传输效率。
基于此架构的流媒体技术方案,服务端和客户端之间建立连接之后,服务器开始持续不断地发送媒体数据包,媒体数据包采用Rtp进行封装,客户端控制信息通过Rtsp信息包以udp或tcp的方式传送。
1/11
另外,类似的流媒体协议还包括了adobe的Rtmp(Realtimemessagingprotocol)以及Real公司的RtspoverRdt(Realdatatransportprotocol),本文就不在此对这些流媒体协议逐一进行介绍了。
2.http渐进式下载
http渐进式下载技术与有状态的Rtsp/Rtp技术相比,采用了无状态的http协议。
当http客户端向前端请求数据时,服务端将请求的数据下发给客户端,但是服务端并不会记录客户端的状态,每次http请求都是一个一次性独立的会话。
渐进式下载的功能目前主流的终端播放器均支持,如adobe的Flash、微软的silverlight以及windowsmediaplayer。
所谓的渐进式下载,即终端播放器可以在整个媒体文件被下载完成之前即可开始媒体的播放,客户端及服务端如果均支持http1.1,终端还可从没下载完成的部分中任意选取一个时间点开始播放。
目前,主流的视频网站均采用了http渐进式下载的方式来实现流媒体的分发,如优酷网、土豆网等等。
3.方案对比
作为最简单和原始的流媒体解决方案,http渐进式下载尤其显著的优点在于它仅需要维护一个标
准的web服务器,其安装和维护的工作量和复杂性比起专门的流媒体服务器来说要简单和容易得多。
2/11
然而,其缺点和不足也很明显。
首先是带宽容易浪费。
当一个用户在开始下载观看一个内容之后选择停止观看,那么已经下载完成的内容则是对带宽资源的一种浪费。
其次,基于http的渐进式下载仅仅适用于点播内容,而不支持直播内容。
最后,此方式缺乏灵活的会话控制功能和智能的流量调节机制。
而基于Rtsp/Rtp的流媒体系统专门针对大规模流媒体直播和点播等应用而设计,需要专门的流媒体服务器支持,与http渐进下载相比主要具有如下优势。
流媒体播放的实时性。
与渐进下载客户端需要先缓冲一定数量媒体数据才能开始播放不同,基于Rtsp/Rtp的流媒体客户端几乎在接收到第一帧媒体数据的同时就可以启动播放。
支持进度条搜索、快进、快退等高级VcR控制功能。
平滑、流畅的音视频播放体验。
在基于Rtsp的流媒体会话期间,客户端与服务器之间始终保持会话联系,服务器能够对来自客户端的反馈信息动态做出响应。
当因网络拥塞等原因导致可用带宽不足时,服务器可通过适当降低帧率等方式来智能调整发送速率。
支持大规模用户扩展。
普通的web服务器主要针对大量小的html文件下载而进行优化,在传输大容量媒体文件方面缺少性能优势。
而专业的流媒体服务器在大容量媒体文件硬盘读取、内存缓冲和网络发送等方面进行了优化,可支持大规模用户接入。
内容版权保护。
在渐进下载模式中,下载后的文件缓存在客户端硬盘的临时目录中,用户可将其拷贝至其他位置供以后再次播放。
而在基于Rtsp/Rtp的流媒体系统中,客户端只在内存中维持一个较小的解码缓冲区,播放后的媒体数据随时清除,用户不容易截取和拷贝。
此外还可利用dRm等版权保护系统进行加密处理。
尽管如此,基于Rtsp/Rtp的流媒体系统在实际的应用部署中仍然遇到了不少问题,主要体现在:
与web服务器相比,流媒体服务器的安装、配置和维护都较为复杂,特别是
对于已经建有cdn(内容分发网络)等基础设施的运营商来说,重新安装配置支持Rtsp/Rtp的流媒体服务器工作量很大;
Rtsp/Rtp协议栈的逻辑实现较为复杂,与http相比支持Rtsp/Rtp的客户端软硬件实现难度较大,特别是对于嵌入式终端来说;
Rtsp协议使用的网络端口号(554)可能被部分用户网络中的防火墙和nat等
封堵,导致无法使用。
虽然有些流媒体服务器可通过隧道方式将Rtsp配置在http的80端口上承载,但实际部署起来并不是特别方便。
二、http码率自适应
上一节中我们谈到了基于Rtsp/Rtp的流媒体技术以及基于http的渐进式下载,但是我们可以清楚看到两种方案均存在着各自的缺点。
这时has技术应运而生,它融合了传统Rtsp/Rtp流媒体技术以及基于http渐进式下载技术的优点,具有高效、可扩展以及兼容性强的特点。
下图为has技术的实现原理。
3/11
has技术是一种混合的媒体分发方式,
给用户的体验是流的方式,但是实际上与http渐进式下载方式一样采用http协议完成了内容的下载分发,但这些媒体内容都被切割成了一系列的媒体分块进行传输。
has技术的一个关键就是媒体数据的切割分块,每个分块的时间长度相同,一般为2~10秒。
在视频编码层,这意味着每个分块都由若干个完整的视频gop组成(每个分块都有一个关键i帧),以此保证每个分块都与过去及将来的媒体分块无关联。
媒体分块存储在httpweb服务器中,客户端以线性的方式向web服务器请求媒体分块,并以传统的http方式进行媒体分块的下载,当媒体分块下载至客户端时,客户端按照顺序播放这一系列媒体分块。
因为这些媒体分块按照约定的规则进行编码,各个媒体分块之间没有内容的重叠或不连续,对于用户来说,则看到了一个无缝平滑的播放效果。
4/11
若一份内容在编码输出时已提供了多种码率,则内容切片模块会将其切割成多种码率的媒体分块。
因为web服务器传输数据是尽可能地利用网络带宽来进行内容的下载,没有流量的控制机制,客户端可以很容易地检测到web服务器到客户端的可用网络带宽,从而决定下载更大或更小的媒体分块,实现码率的自适应。
从图5我们可以看出,has的关键技术主要由两大部分,一是内容的准备,包括了支持多屏的转码平台以及媒体的分割切片模块,其次是内容的分发,包括了基于http的内容源服务器以及面向终端的内容分发网络,完成并发流数量的放大功能。
三、has技术特点分析
1.采用has的优势
has与其他基于http传输媒体的方式一样,和传统的流媒体分发技术相比,具有以下优势:
web服务器更容易部署,因为has技术采用了通用的http协议,传统的
http缓存/代理、防火墙等网络设备可以完美兼容;
提供了更好的兼容性和到达率,可根据最后接入网的带宽大小动态地调整码率,实现内容的分发;
对于用户来说体验更好,且不需要业务提供者去考虑收看用户的带宽。
has除了上述优势之外,还有以前任何技术均不具备的特点,具体如下:
用户等待的时间更短,可以快速实现播放——客户端初始化默认选择低码率,开始播放后逐步向高码率进行切换,因此,其服务质量是在可用带宽范围之内不断被进行调整和优化;
不需要大的缓存,不间断地播放,没有抖动的平滑视频播放体验;
基于网络状况和cpu解码能力的无缝码率切换;
客户端不需要下载超过它实际消耗的内容。
综上所述,相对于传统的流媒体技术,它能够提供更好的服务质量,因为它可以使用整个可用的带宽,而非自适应流技术则是强制客户端选择一个低于可用带宽的固定比特率。
可以预见,has技术在不久的将来将得到广泛的部署及应用。
2.需要面对的问题
5/11
篇三:
软件销售协议
软件开发协议书
甲方:
乙方:
甲乙双方依据《中华人民共和国合同法》及相关法律法规,本着相互合作、互利互惠的原则,经充分协商,订立本合同。
第一条项目内容
甲方同意作为购买方向乙方采购手机视频直播系统。
第二条项目所涉及产品说明及价格
产品价格:
a.android客户端+ios客户端+流媒体服务器:
300,000人民币;
b.流媒体服务器第三方授权费用:
每台流媒体服务器10,000人民币;
第三条合同金额及付款方式
1.合同总金额为人民币贰拾万元整,¥320,000,包括2台流媒体服务器的授权许可费用。
2.付款方式:
(1)甲方应于本合同签字之日起5个工作日内支付乙方人民币壹拾陆万元整,¥160,000。
(2)甲方应于20xx年10月31日前支付乙方剩余款项人民币壹拾陆万元整,¥160,000。
甲方支付的全部款项均以支票或转帐方式支付于乙方以下帐户。
收款单位:
开户行:
帐号:
第四条交付、安装、测试与验收
甲方应于合同签订后的20个工作日内提供本合同约定软件产品。
乙方将按照下列安排对本合同第二条项下的软件进行安装:
1.乙方安排技术工程师与甲方技术人员配合实施。
2.测试期限:
甲方系统部署完成后,甲方应在乙方的指导下在3个工作日内进行测试,否则视为该项安装已经合格;
3.验收:
甲方项目用户应于测试完毕后3天内验收,并即时就验收结果出具书面文件予乙方;甲方项目用户未按本合同的规定进行验收并出具书面验收结果予乙方的,视为甲方项目用户已验收并认定合格。
第五条产品修改和升级、技术支持服务
1.本协议期内,乙方有权对许可软件进行更新升级,并应在60日内通知甲方,得到
甲方同意后,可对甲方已安装的软件产品版本更新或升级,并提供售后技术支持、服务和维护。
2乙方产品升级引起的软件问题,由许乙方负责提供升级版本及技术支持。
3技术支持服务包括电话、邮件和远程支持。
第六条服务
本合同期内所列的所有服务及技术支持,可以由乙方免费提供。
本合同期外,甲方还需乙方提供服务和技术支持,维护费每年按本合同金额的15%支付。
第七条变更与解除
经本合同双方同意,可以变更或解除本合同;由于战争或其他军事行动、地震、水灾、火灾、台风、干旱等自然灾害不能预见并对其发生或后果不能合理预防或改变的不可抗力致使本合同的全部或部分义务不能履行的,遭受不可抗力的一方有权通知他方解除合同并在24小时内将事件的情况用电报、传真或电话通知他方,并在30日内就不可抗力事件的详细情况以合法的书面形式通知他方。
由于一方在本合同约定的期限内没有履行合同,本合同任何一方有权通知对方解除合同。
第八条违约责任
1.双方不得因主体变更而违反合同约定。
2.如合同一方未能履行其于本合同项下承担的义务,构成合同违约,致使本合同解除,给他方造成损失的,除应支付违约金外,还应赔偿守约方超过违约金的实际损失。
违约金按未付货款、未供货款的10%支付违约金。
第九条本合同的解释及争议的解决,均适用中国法律、行政法规。
第十条双方在解释或履行本合同、章程时发生争议,应尽量通过友好协商解决。
经协商无效,可向杭州市仲裁委员会提请仲裁解决。
第十一条在解决争议期间,除争议事项外,双方应继续履行本合同规定的其他各项条款。
第十二条本合同各附录、附件、附图均为本合同的组成部分,并具有与合同同等的法律效力。
第十三条未经合同另一方事先书面同意,合同任何一方均不得发布或发表任何公告、新闻或公开声明,透露本合同的有关条款、条件或情况。
第十四条本合同任何一方可书面通知对方确认其同意下列事项:
延长合同的履行时间;放弃在本合同内遵守的任何保证;放弃或变更对方对其任何义务的履行。
第十五条本合同和附件生效后,与中国公布的法律、行政法规有抵触的,本合同应予修改、变更。
第十六条本合同一式肆份,甲乙双方各执贰份,均具同等法律效力。
甲方:
乙方:
签字:
签字:
日期:
日期:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- httplivestreaming 协议