h264协议.docx

h264协议.docx

《h264协议.docx》由会员分享，可在线阅读，更多相关《h264协议.docx（7页珍藏版）》请在冰豆网上搜索。

h264协议

竭诚为您提供优质文档/双击可除

h264协议

　　篇一：

如何学习h.264协议

　　如何学习h.264协议

　　首先，我假定你已经具有如下基础：

　　1了解基本的视频知识，知道什么是ycbcr/yuV；

　　2知道基本的视频压缩原理；

　　如果这两条还不具备，那么，停一下，补一下课。

这方面的相关文章在网上一找一大把。

　　now，你为什么要学习h.264呢？

可能你是个在校学生，要写论文，拿着复杂的jm代码无从下手。

可能你是个开发人员要往已有的代码里添加一个码率控制算法，但是拿着前人开发的代码又感到一头雾水。

无论你具体做什么，对264协议有个比较深的理解还是有必要的。

　　那先准备好以下几样东西：

　　1h.264_mpeg-4part10whitepaper；

　　2h.264Visa和streameye;

　　这是两个码流分析软件，前者有免费版本，后者有个免费版，屏蔽了一些功能，但是对初学者，足够了。

　　3码流。

你可以随便去下两个，很多地方都可以下到的。

　　4matlab

　　你可能注意到，我提供的清单里没有h.264协议，没有jm代码，为什么？

因为这两样东西，太复杂，不合适初学者。

即使现在，我看到h.264协议原本都还觉得复杂，jm代码更是没有怎么看过。

这两样东西，不到做具体开发的时候没有必要去详细地研究。

　　那么，如何理解h.264协议呢。

容易，我们可以手工完成一个264码流的解码过程，相信我，你如果专心，最多花30小时，就能基本完成这个过程。

264协议，其实也使用了与以前的协议类似的方法，但在各个环节中，都加入了不少的改进而已。

　　下面先简要说明一下各个模块的要点。

　　1帧内预测。

　　这是个新概念，但其实就是使用相邻的块来预测当前块。

我们先只考虑4x4亮度块的例子。

　　使用h.264Visa打开一个码流文件。

从第一帧第一块开始（无疑，是个i块）。

然后一个小块一个小块地做预测。

需要注意的是，预测一个小块，就重建一个小块。

重建你只需要把预测值加上残差就可以了。

你可以使用matlab来帮你完成这个过程。

残差值，现在先直接使用就可以，不必残差是如何来的。

重建后的小块就可以作为进一步预测的参考块了。

注意，要使用pre-loopfilter的数据。

2帧间预测。

　　请先用264Visa和streameye打开码流，查看第一个p帧（通常是第2帧）。

树状的块结构层次。

你可以用streameye查看一下，能很容易地看到各个宏块的结构类型。

　　mv。

你可以在h.264Visa中查看一下，看看每个part的mv是多少，注意，因为运动矢量是以1/4像素为单位的，所以（4,8），实际代表偏移了（1,2）个像素。

然后可以根据mv到上一帧找一下参考块的位置，然后比较一下参考块和预测块，看看两者是否近似（非整点情况）或相同（整点情况，比如mv=（4,4））。

mv的预测。

找到当前块的a、b、c块，然后预测一下mv，再看实际的mv是多少。

　　自己根据mv，找到参考块。

再在matlab中写个插值程序，应该可以插出正确的值。

　　注意，做这个练习，应该在第一个p帧中来做，如果到第二个p帧中做，因为涉及多参考帧的问题，找参考帧会比较麻烦。

　　3变换量化。

264中变换量化已经合在一起了，白皮书上已经有详细说明。

可以自己用matlab来算一下白皮书上的题目，再在码流中找一个块，做下反量化反变换，最后看看结果，和h.264Visa的结果比一下。

　　4caVlc。

　　没什么可说的，理解一下ca，然后知道其实就是个改进了的Run-level编码就可以。

　　5deblocking

　　理解一下bs，理解一下阈值。

注意，当梯度小于阈值时才做加权，为什么？

在h.264Visa中比较一下pre-loopfilter和final的数据。

　　6码流结构和语法。

　　用streameye可以查看码流及其分析结果。

　　有了这两个码流分析工具，再结合白皮书，应该很快能掌握i块，p块的重建方法，并能熟悉码流结构。

　　jm代码太复杂，没必要在这个阶段看。

协议，更烦琐，不做完整开发的话也没必要看了。

可以看看市面上的相关的参考书。

　　篇二：

h264媒体和数据传输介绍

　　h264媒体简单说明

　　一、h264简介

　　h264分层结构由五层组成：

　　序列参数集（sps）

　　图像参数集（pps）

　　片（slice）

　　宏块、

　　子块

　　其中后面层应用前面层（或则说从属关系）；其中序列的第一个帧叫做idR帧，用于清空参考帧队列，避免错误累积。

　　h264nalu包Rtp传输一般分为三种情况：

单一nalu模式，一般nalumtu

　　二、h264的文件存储和传输区别

　　h264的文件存储：

　　每一个nalu包前都会多一个000001or00000001的起始头，作为nalu包之间的分隔标识；并通过给非起始头的0000后插入0x03来避免标识冲突。

取数据后，起始头需要丢掉，0x03数据也需要去除。

　　依据不同帧的情况来实现不同打包，代码可参考nalu打包demo

　　h264的文件传输：

　　nalu包属于传输包的自然分割，不需要加起始头。

　　包格式一般是：

x串+h264nalu头+h264data比如Rtp传输，x串往往就是Rtp头（一般12字节）三、h264和mp4关系

　　是itu-t与iso/iec两个组织联合进行开发的视频编解码方案。

　　itu-t命名为h264

　　iso/iec命名为mpeg-4aVc是mpeg-4标准的第10部分其中标准h264格式的文件存储不是国际标准格式

　　相关传输协议简单说明（本次使用到）

　　一、Rtp/Rtcp、Rtsp、sip等

　　Rtp/Rtcp是传输层的传输和控制协议，是一个传输子层，运行在tcp/udp之上Rtsp/sip是更上一层的传输协议

　　sip运行在Rtp之上

　　Rtsp直接在tcp/udp上运行二、Rtp包头

　　音频和视频采用不同端口，初期先考虑仅h264视频

　　三、Rtcp

　　在Rtp会话期间，各参与者周期性地传送Rtcp包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。

分为五类：

　　200sR发送端报告主要考虑201RR接收端报告202sdes源点描述203bye结束传输204app特定应用

　　sR主要包括：

相应的Rtp流的ssRc（丢失率、累计丢包数、接收抖动、上次sR以来的延时等）、Rtp流中最新产生的Rtp分组时间戳和ntp、Rtp流包含的分组数、字节数。

详情参见附录三Rtcp包结构说明

　　Rtp发往对端udp的偶数端口n，Rtcp发往对端udp的奇数端口n+1

　　发送周期（限制Rtcp占Rtp会话量的一小部分,通常不超过5%），计算起来比较麻烦

　　暂时先简化试试：

每20个Rtp包发送一个RtcpsRandRR包？

小文件传输测试时，先不发Rtcp包，看能不能找到个demo来编程参考，这部分很繁杂

　　Rtcp执行下列四大功能：

　　主要是提供数据发布的质量反馈。

是作为Rtp传输协议的一部分，与其他传输协议的流和阻塞控制有关。

反馈对自适应编码控制直接起作用，但ip组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。

　　Rtcp带有称作规范名字（cname）的Rtp源持久传输层标识。

如发现冲突，或程序重新启动，既然ssRc标识可改变，接收者需要cname跟踪参加者。

接收者也需要cname与

　　相关Rtp连接中给定的几个数据流联系

　　前两种功能要求所有参加者发送Rtcp包，因此，为了Rtp扩展到大规模数量，速率必须受到控制。

让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。

该数量用语计算包发送的速率。

　　第四个可选功能是传送最小连接控制信息，如参加者辨识。

最可能用在"松散控制"连接，那里参加者自由进入或离开，没有成员控制或参数协调，Rtcp充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。

在ip组播场合应用Rtp时，前3个功能是必须的，推荐用于所有情形。

Rtp应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。

　　四、Rtsp

　　是一个多媒体播放控制协议，通过tcp传输

　　Rtsp分为请求消息和响应消息，常用方法如下：

　　a.option，得到服务器提供的可用方法

　　b.descRibe，得到服务器的会话描述信息（sdp）c.setup，提醒服务器建立会话，并确定传输模式d.play，发送播放请求

　　e.teaRdown，发起关闭请求

　　f.其他如get/set_paRameteR、pause、RediRect等

　　使用朗驰摄像头实现思科视频对接过程注意内容

　　一、思科视频数据要求

　　基于sip协议，使用Rtp传输协议Rtp包格式：

　　Rtp包头（一般12字节）+h264nalu头+h264naludata二、朗驰摄像头数据源输入：

　　可以有两种方式：

　　a模式，作为客户端通过Rtsp方式获得数据b模式，调用sdk获得数据两者都可以通过udp传输三、数据解析说明（目前无朗驰提供格式说明，以下数据仅通过抓包直接解析获得，不排除低概率

　　的特殊内容出现）a模式

　　x头（12字节）+h264nalu头+h264naludata

　　和Rtp头差别，x头中时间戳为0；抓包工具不识别，播放软件可忽略该数据。

需要进行Rtsp协议会话、udp解包（修改时间戳）、转发包、增加Rtcp消息

　　b模式，两种情况

　　udp头（8字节）+a模式（x串+起始码（00000001）+h264nalu头+h264data）

　　x串000001…一直到00000001之前结束（共28/26字节，如：

0000000161（28字节），00000001f000（26字节）），存在个别情况x串和0000000167之间又增加了一个朗驰说明数据（tcp数据通过udp传输了？

），鉴别方法，000001~00000001处理即可

　　udp头（8字节）+b模式（h264data，上一个起始码（00000001）内容的的后续数据）没有x串

　　需要解包（去除不需要内容）、重新打包、增加Rtp包头、增加Rtcp

　　相对而言，采用a模式更简明，与ptsp的会话参见下面的附录一和附录二

　　篇三：

Rtsp-Rtp实现h.264视频直播

　　Rtsp/Rtp

　　实现h.264视频直播

　　20xx年06月

　　文档修订控制记录

　　1、综述

　　目前在流媒体传输技术中使用最多的就是基于Rtsp/Rtp的流媒体传输。

Rtsp对应iso网络七层参考模型的应用层，和http有点类似，也是一种文本协议，主要是实现对流的控制。

　　有关Rtsp/Rtp以及Rtcp之间的关系可以参考下图：

　　通过上图可以看出三者之间的关系，Rtsp协议基于tcp完成Rtsp请求报文和响应报文的传输，Rtp协议基于udp协议完成流媒体数据的实时传输，Rtcp协议基于udp协议提　　

供客户端和服务器有关当前网络拥塞和以及实时流传输质量等信息。

　　在智能网络相机上也需要实现基于Rtsp/Rtp的h.264实时流的传输。

Rtcp暂时还未实现，这在流媒体技术中是比较高级的应用。

　　2、Rtsp方法

　　Rtsp协议文档的官方编号是RFc2336，有关该协议的相关规范，可以参考RFc2336文档，在此不再赘述。

　　结合调试经验，先把调试过程中用到的Rtsp协议的几个重要方法简单总结一下：

　　图2-1高清网络智能相机Rtsp协议截图

　　图2-1高清网络智能相机Rtsp协议

　　如图所示：

ip192.168.1.100是Rtsp客户端，在测试的过程中，使用的Vlc2.0.1播放

　　器作为Rtsp客户端，ip192.168.1.42是Rtsp服务器端，即网络智能相机。

整个过程中使用的Rtsp协议的方法主要有以下几个：

options、descRibe、setup、play以及teaRdown.

　　options方法：

　　用于得到服务器提供的可用方法；

　　首先，客户端发出Rtsp请求报文option.如图2-2所示：

　　Rtps服务器端收到此报文后，返回Reply报文作为回应，并在public字段中指明了Rtsp服务器可提供的方法种类：

如图2-3所示：

　　图2-2Rtsp请求报文：

options

　　通过public字段可看到，在我们使用的高清网络智能相机的Rtsp

　　服务器可支持的方

　　图2-3对option报文的回应报文

　　法有：

　　options、descRibe、setup、teaRdown、play、pause、get_paRameteR、set_paRameteR。

　　descRibe方法

　　接着客户端向服务器端发descRibe请求报文，用于得到uRi所指定的媒体描述信息，一般是sdp信息。

客户端通过accept头指定客户端可以接受的媒体述信息类型,如图2-4所示：

　　图2-4descRibe请求报文

　　服务器端收到descRibe请求报文后，给出回应报文，在回应报文中，给出了sdp信息，如图2-5所示

　　图2-5descRibe回应报文

　　仔细分析sdp信息，其中最关键的部分是以下几个字段：

　　mediadescription（m）：

指出了我们将要传输的媒体是基于Rtp协议的类型为96的媒体；mediaattribute（a）：

指明了我们使用的Rtp类型为96的媒体是h264，且h264采用率为90000；mediaattribute（a）：

指明了h264profile-leve-id为64001F，即prorfile_id为100，level_id为3.1。

　　（注：

实际我们使用的h264的profile_id

　　为基本框架

　　66，leVel_id为40，即4.0，因为我们使用的是appRo提供的liVe555移植过来的，所以这些信息还没在源码中改，需要完善源码）