一种在传输层上传输H.265编码视频数据的方法与流程

本发明涉及视频数据传输技术领域，尤其涉及一种在传输层上传输h.265编码视频数据的方法。

背景技术：

近年来，由于高码率、高画质视频的普及，特别是vr视频这种需要极致体验的视觉观看体验的视频，就需要更高的网络带宽来传输。一种方法是用户主动升级网络带宽大小，另一种是使用新的视频编码方式在保证画质不变的前提下，降低码率从而可以在不需要消耗很高带宽资源情况下传输高画质的视频数据。本发明就是使用第二种思路来解决在相对不是很高码率下传输超高画质视频数据的解决方案。

技术实现要素：

为了解决现有技术存在的不足，本发明的目的在于提供一种在传输层上传输h.265编码视频数据的方法，在使用压缩率更高的h.265编码方式在视屏直播流传输层协议上分发传输更高画质的画面。

为实现上述目的，本发明提供的在传输层上传输h.265编码视频数据的方法，包括以下步骤：

1)对直播视频进行h.265编码；

2)修改rtmp或http-flv协议头的codecid字段和metadata信息，对rtmp协议或http-flv协议的数据结构进行修改；

3)采用修改后的rtmp或http-flv协议进行h.265编码视频数据的传输；

4)选择h.265解码器进行解码和视频播放。

进一步地，步骤2)所述修改rtmp或http-flv协议头的codecid字段和metadata信息，包括，

在rtmp协议或http-flv协议的协议头中增加codecid＝10的数据用来标识流的编码类型为h.265；

在rtmp协议的metadata信息中增加codecid为10表示使用的是h.265编码。

进一步地，还包括以下步骤：

如果hevcpackettype字段为0时，增加vps数据；

将265帧数据封装进rtmp或http-flv的视频包载荷。

更进一步地，所述步骤4)进一步包括，

判断rtmp协议或http-flv协议的协议头是否有codecid＝10标识；

判断rtmp协议或http-flv协议metadata中标识codecid是否为10；

播放器选择h.265解码器进行视频数据解码。

本发明提供的在传输层上传输h.265编码视频数据的方法，使用h.265编码方式在保证画质不变的前提下，降低码率从而可以在不需要消耗很高带宽资源情况下传输高画质的视频数据。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，并与本发明的实施例一起，用于解释本发明，并不构成对本发明的限制。在附图中：

图1为现有rtmp协议中消息的报文结构示意图；

图2为现有rtmp协议中消息块的报文结构示意图；

图3为现有rtmp协议中消息分块过程示意图；

图4为根据本发明在传输层上传输h.265编码视频数据的方法流程图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

rtmp(http-flv与rtmp协议相同，后面不再赘述)协议是一个互联网tcp/ip五层体系结构中应用层的协议。rtmp协议中基本的数据单元称为消息(message)。当rtmp协议在互联网中传输数据的时候，消息会被拆分成更小的单元，称为消息块(chunk)。

1消息

消息是rtmp协议中基本的数据单元。不同种类的消息包含不同的messagetypeid，代表不同的功能。rtmp协议中一共规定了十多种消息类型，分别发挥着不同的作用。图1为现有rtmp协议中消息的报文结构示意图，如图1所示，messagetypeid在1-7的消息用于协议控制，这些消息一般是rtmp协议自身管理要使用的消息，用户一般情况下无需操作其中的数据。messagetypeid为8，9的消息分别用于传输音频和视频数据。messagetypeid为15-20的消息用于发送amf编码的命令，负责用户与服务器之间的交互，比如播放，暂停等等。消息首部(messageheader)有四部分组成：标志消息类型的messagetypeid，标志消息长度的payloadlength，标识时间戳的timestamp，标识消息所属媒体流的streamid。

2消息块

在网络上传输数据时，消息需要被拆分成较小的数据块，才适合在相应的网络环境上传输。rtmp协议中规定，消息在网络上传输时被拆分成消息块(chunk)。图2为现有rtmp协议中消息块的报文结构示意图，如图2所示，消息块首部(chunkheader)有三部分组成：用于标识本块的chunkbasicheader，用于标识本块负载所属消息的chunkmessageheader，以及当时间戳溢出时才出现的extendedtimestamp。

3消息分块

在消息被分割成几个消息块的过程中，消息负载部分(messagebody)被分割成大小固定的数据块(默认是128字节，最后一个数据块可以小于该固定长度)，并在其首部加上消息块首部(chunkheader)，就组成了相应的消息块。图3为现有rtmp协议中消息分块过程示意图，如图3所示，一个大小为307字节的消息被分割成128字节的消息块(除了最后一个)。

rtmp传输媒体数据的过程中，发送端首先把媒体数据封装成消息，然后把消息分割成消息块，最后将分割后的消息块通过tcp协议发送出去。接收端在通过tcp协议收到数据后，首先把消息块重新组合成消息，然后通过对消息进行解封装处理就可以恢复出媒体数据。

图4为根据本发明在传输层上传输h.265编码视频数据的方法流程图，下面将参考图4，对本发明的在传输层上传输h.265编码视频数据的方法进行详细描述。

首先，在步骤401，采用h.265视频编码标准对直播视频进行编码；

h.265是itu-tvceg继h.264之后所制定的新的视频编码标准。h.265标准围绕着现有的视频编码标准h.264，保留原来的某些技术，同时对一些相关的技术加以改进，其使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括：提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。h264由于算法优化，可以低于1mbps的速度实现标清数字图像传送；h.265则可以实现利用1～2mbps的传输速度传送720p(分辨率1280*720)普通高清音视频传送。

在步骤402，对rtmp协议的数据结构进行修改；

rtmp协议头的frametype字段不变，在rtmp协议头(rtmpheader)的codecid字段新增codecid＝10的数据用来标识流的编码类型为h.265(264使用的是7)。并且在rtmp协议的metadata信息中增加codecid为10(264编码的采用的是7)表示使用的是h.265编码，用来让播放器选择h.265解码器进行视频数据解码。

如果hevcpackettype字段为0时(表示的是hevc的sequenceheader),即265视频流的一些配置信息，在原本264的sequenceheader基础上(sps+pps数据)，增加了vps数据[vps:videoparameterset(视频参数集)]，辅助解码。

在rtmp的视频包载荷将265帧数据封装进去。此机制跟264相同，只是载荷内容不同。

在步骤403，对http-flv协议的数据结构进行修改；

http-flv协议支持h.265和rtmp协议相同，启用新的codecid用来表示h.265编码方式。

在步骤404，采用修改后的rtmp、http-flv协议进行h.265编码视频数据的传输；

在步骤405，播放器选择h.265解码器进行视频数据解码、播放。

rtmp协议和http-flv协议新增codecid＝10用来标识h.265编码器。需要在协议metadata中标识codecid为10表示使用的是h.265编码，用来让播放器选择h.265解码器进行视频数据解码。

rtmp视频包负载数据结构rtmpheader+rtmpbody(5字节header+4个字节nalu大小+真实是视频数据)，其中bodyheader结构如下：

byte[0]＝[1-byteheader]

byte[1]＝[1-bytecodecconfigindicator(1-videodata,0-codecconfigpacket)]

byte[2..4]＝[3-bytetimedifferencebetweendtsandptsinmilliseconds]byte[5..8]＝[4-bytenalusize]

其中nalu字段大小由lengthsizeminusone决定。

hevc字段定义如下表所示：

hevc视频解码配置信息数据结构:

http-flv协议支持h.265和rtmp协议相同，启用新的codecid用来表示h.265编码方式。

本领域普通技术人员可以理解：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作-的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。