分析http协议的视频流Word文档下载推荐.docx

1、63gp：是一种3g流媒体的格式，主要是为了配合3g网络的高传输速度而开发的，也是目前手机中最为常见的一种视频格式。7Flv：FlashVideo的简称，它形成的文件极小、加载速度极快。8F4v：其实就是flv的改进版本。9Rmvb：在我已知的视频格式中，调用最不方便的一种，手机很少有支持这个格式的视频的。pc端支持这种格式的播放器也不多。二我查到的几种协议，用于网络传输的。httprtspmms1.http：非常常用的一种协议2.rtsp：实时流传输协议。http与Rtsp相比，http传送html，而Rtsp传送的是多媒体数据。http请求由客户机发出，服务器作出响应；使用Rtsp时，客户

2、机和服务器都可以发出请求，即Rtsp可以是双向的。3.mms：目前主流的视频流传输协议，但是现在还是主要应用在pc上。总结：根据我们的需求，我认为，我们要播放的视频最好是客户手机可以支持的视频格式。现在android的手机支持大部分的格式的视频。还有协议很重要，现在android上支持http、https、和rtsp协议的东西。mms的协议在android还没有明确的支持。篇二：视频编解码和流媒体协议Rtp参考文档RFc3550/RFc3551Real-timetransportprotocol）是用于internet上针对多媒体数据流的一种传输层协议。Rtp协议详细说明了在互联网上传递音频和

3、视频的标准数据包格式。Rtp协议常用于流媒体系统（配合Rtcp协议），视频会议和一键通（pushtotalk）系统（配合h.323或sip），使它成为ip电话产业的技术基础。Rtp协议和Rtp控制协议Rtcp一起使用，而且它是建立在udp协议上的。Rtp本身并没有提供按时发送机制或其它服务质量（qos）保证，它依赖于低层服务去实现这一过程。Rtp并不保证传送或防止无序传送，也不确定底层网络的可靠性。Rtp实行有序传送，Rtp中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。Rtp由两个紧密链接部分组成：Rtp传送具有实时属性的数据

4、；Rtp控制协议（Rtcp）监控服务质量并传送正在进行的会话参与者的相关信息。Rtcp实时传输控制协议（Real-timetransportcontrolprotocol或Rtpcontrolprotocol或简写Rtcp）是实时传输协议（Rtp）的一个姐妹协议。Rtcp为Rtp媒体流提供信道外（out-of-band）控制。Rtcp本身并不传输数据，但和Rtp一起协作将多媒体数据打包和发送。Rtcp定期在流多媒体会话参加者之间传输控制数据。Rtcp的主要功能是为Rtp所提供的服务质量（qualityofservice）提供反馈。Rtcp收集相关媒体连接的统计信息，例如：传输字节数，传输分组数

5、，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用Rtcp所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。Rtcp本身不提供数据加密或身份认证。sRtcp可以用于此类用途。sRtp&sRtcp参考文档RFc3711安全实时传输协议（secureReal-timetransportprotocol或sRtp）是在实时传输协议（Real-timetransportprotocol或Rtp）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由davidoran（思科）和Rolfblom（

6、爱立信）开发的，并最早由ietF于20xx年3月作为RFc3711发布。由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（Rtpcontrolprotocol或Rtcp）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（secureRtcp或sRtcp）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密

7、和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。Rtsp参考文档RFc2326是由Realnetworks和netscape共同提出的。该协议定义了一对多应用程序如何有效地通过ip网络传送多媒体数据。Rtsp提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如udp、多播udp与tcp提供途径，并为选择基于Rtp上发送机制提供方法。Rtsp（Realtimestreamingprotocol）是用来控制声音或影像

8、的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用tcp或udp来传送串流内容，它的语法和运作跟http1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Videoconference）。因为与http1.1的运作方式相似，所以代理服务器proxy的快取功能cache也同样适用于Rtsp，并因Rtsp具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。Rt

9、sp和Rtp的关系Rtp不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。Rtsp与Rtp最大的区别在于：Rtsp是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，Rtsp可基于Rtp来传送数据，还可以选择tcp、udp、组播udp等通道来发送数据，具有很好的扩展性。它时一种类似与http协议的网络应用层协议。目前碰到的一个应用：服务器端实时采集、编码并发送两路视频，客户端接收并显示两路视频。由于客户端不必对视频数据做

10、任何回放、倒退等操作，可直接采用udp+Rtp+组播实现。Rtp：实时传输协议（Real-timetransportprotocol）Rtp/Rtcp是实际传输数据的协议Rtp传输音频/视频数据，如果是play，server发送到client端，如果是RecoRd，可以由client发送到server整个Rtp协议由两个密切相关的部分组成：Rtp数据协议和Rtp控制协议（即Rtcp）Rtsp：实时流协议（Realtimestreamingprotocol，Rtsp）Rtsp的请求主要有descRibe,setup,play,pause,teaRdown,options等，顾名思义可以知道起对话

11、和控制作用Rtsp的对话过程中setup可以确定Rtp/Rtcp使用的端口，play/pause/teaRdown可以开始或者停止Rtp的发送，等等Rtcp：Rtcp包括senderReport和ReceiverReport，用来进行音频/视频的同步以及其他用途，是一种控制协议sdp会话描述协议（sdp）为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。sdp即用于将这种信息传输到接收端。sdp完全是一种会话描述格式它不属于传输协议它只使用不同的适当的传输协议，包括会话通知协议（sap）、会话初始协议（

12、sip）、实时流协议（Rtsp）、mime扩展协议的电子邮件以及超文本传输协议（http）。sdp的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，但sdp不支持会话内容或媒体编码的协商。在因特网组播骨干网（mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由sdp完成。sdp连接好会话后，传送足够的信息给会话参与者。sdp信息发送利用了会话通知协议（sap），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是udp数据包，其中包含sap协议头和文本有效载荷（textpayload）。这里文本

13、有效载荷指的是sdp会话描述。此外信息也可以通过电子邮件或www（worldwideweb）进行发送。sdp文本信息包括：会话名称和意图；会话持续时间；构成会话的媒体；有关接收媒体的信息（地址等）。协议结构sdp信息是文本信息，采用utF-8编码中的iso10646字符集。sdp会话描述如下：（标注*符号的表示可选字段）：v=（协议版本）o=（所有者/创建者和会话标识符）s=（会话名称）i=*（会话信息）u=*（uRi描述）e=*（email地址）p=*（电话号码）c=*（连接信息如果包含在所有媒体中，则不需要该字段）b=*（带宽信息）一个或更多时间描述（如下所示）：z=*（时间区域调整）k=

14、*（加密密钥）a=*（0个或多个会话属性行）0个或多个媒体描述（如下所示）时间描述t=（会话活动时间）r=*（0或多次重复次数）媒体描述m=（媒体名称和传输地址）i=*（媒体标题）c=*（连接信息如果包含在会话层则该字段可选）篇三：httplivestreaming直播技术分析与实现httplivestreaming直播技术分析与实现不经意间发现，大半年没写博客了，自觉汗颜。实则20xx后半年，家中的事一样接着一样发生，实在是没有时间。快过年了，总算忙里偷闲，把最近的一些技术成果，总结成了文章，与大家分享。前些日子，也是项目需要，花了一些时间研究了httplivestreaming（hls）技

15、术，并实现了一个hls编码器hlsliveencoder，当然，c+写的。其功能是采集摄像头与麦克风，实时进行h.264视频编码和aac音频编码，并按照hls的协议规范，生成分段的标准ts文件以及m3u8索引文件。通过我的hlsliveencoder和第三方http服务器（例如：nginx），成功实现了httplivestreaming直播，并在iphone上测试通过。我就把这当中的一些收获写在这里。hls技术要点分析httplivestreaming（hls）是苹果公司（appleinc.）实现的基于http的流媒体传输协议，可实现流媒体的直播和点播，主要应用在ios系统，为ios设备（如i

16、phone、ipad）提供音视频直播和点播方案。hls点播，基本上就是常见的分段http点播，不同在于，它的分段非常小。要实现hls点播，重点在于对媒体文件分段，目前有不少开源工具可以使用，这里我就不再讨论，只谈hls直播技术。相对于常见的流媒体直播协议，例如Rtmp协议、Rtsp协议、mms协议等，hls直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。hls协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（mpeg-ts格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，

17、就实现了直播。由此可见，基本上可以认为，hls是以点播的技术方式来实现直播。由于数据通过http协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过hls的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。根据以上的了解要实现httplivestreaming直播，需要研究并实现以下技术关键点1.2.3.4.5.采集视频源和音频源的数据对原始数据进行h264编码和aac编码视频和音频数据封装为mpeg-ts包hls分段生成策略及m3u8索引文件http传输协议其中第1点和第2点，我之前的文章中已经

18、提到过了，而最后一点，我们可以借助现有的http服务器，所以，实现第3点和第4点是关键所在。程序框架与实现通过以上分析，实现hlsliveencoder直播编码器，其逻辑和流程基本上很清楚了：分别开启音频与视频编码线程，通过directshow（或其他）技术来实现音视频采集，随后分别调用libx264和libfaac进行视频和音频编码。两个编码线程实时编码音视频数据后，根据自定义的分片策略，存储在某个mpeg-ts格式分段文件中，当完成一个分段文件的存储后，更新m3u8索引文件。如下图所示：上图中hlsliveencoder当收到视频和音频数据后，需要首先判断，当前分片是否应该结束，并创建新分

19、片，以延续ts分片的不断生成。需要注意的是，新的分片，应当从关键帧开始，防止播放器解码失败。核心代码如下所示：tsmuxer的接口也是比较简单的。hls分段生成策略和m3u81.分段策略hls的分段策略，基本上推荐是10秒一个分片，当然，具体时间还要根据分好后的分片的实际时长做标注通常来说，为了缓存等方面的原因，在索引文件中会保留最新的三个分片地址，以类似“滑动窗口”的形式，进行更新。2.m3u8文件简介m3u8，是httplivestreaming直播的索引文件。m3u8基本上可以认为就是.m3u格式文件，区别在于，m3u8文件使用utF-8字符编码。#extm3um3u文件头，必须放在第一行#ext-x-media-sequence第一个ts分片的序列号#ext-x-taRgetduRation每个分片ts的最大的时长#ext-x-allow-cache是否允许cache#ext-x-endlistm3u8文件结束符#extinFextrainfo，分片ts的信息，如时长，带宽等一个简单的m3u8索引文件运行效果在nginx工作目录下启动hlsliveencoder，并用Vlc播放器连接播放通过iphone播放的效果