CN105992049A - 一种rtmp直播回看方法及系统 - Google Patents

Abstract

本发明公开了一种RTMP直播回看方法及系统，所述方法包括：根据预先配置下载RTMP音视频流并解码得到音视频文件；根据预先设定的策略将所述音视频文件编码生成音视频数据；生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；将所述回看音视频文件通过服务器发布。本发明实施例的方案，能够将RTMP直播流转成了flv等格式的直播流，实现flv点播回看的功能，极大的提高了用户体验度。

Description

一种RTMP直播回看方法及系统

技术领域

本发明涉及互联网技术领域，特别涉及一种RTMP直播回看方法及系统。

背景技术

RTMP是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP，是一个协议簇，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe MediaServer/Ultrant Media Server/red5等。

RTMP有三种变种：

1)工作在TCP之上的明文协议，使用端口1935；

2)RTMPT封装在HTTP请求之中，可穿越防火墙；

3)RTMPS类似RTMPT，但使用的是HTTPS连接。

RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视/音频数据。

一个单一的连接可以通过不同的通道传输多路网络流。这些通道中的包都是按照固定大小的包传输的。

一个Actionscript连接并播放一个流的简单代码：

var videoInstance：Video＝your_video_instance；

var nc：NetConnection＝new NetConnection()；

var connected：Boolean＝nc。connect("RTMP：/localhost/myapp")；

var ns：NetStream＝new NetStream(nc)；

videoInstance。attachVideo(ns)；

ns。play("flvName")；

默认端口为1935。

RTMP包包含一个固定长度的包头和一个最长为128字节的包体。包头可以是下面4种长度的任意一种：12，8，4，or 1 byte(s)。

第一个字节的前两个Bit很重要，它决定了包头的长度。它可以用掩码0xC0进行"与"计算。下面的表格罗列了可能的包头长度：

Bits Header Length

00 12 bytes

01 8 bytes

10 4 bytes

11 1 byte

其实RTMP包结构就是使用了AMF格式。

下面是一个关于客户端向服务器端发送流的流程：

Client→Server：发送一个创建流的请求。

Server→Client：返回一个表示流的索引号。

Client→Server：开始发送。

Client→Server：发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来唯一标识)。

现有技术中，RTMP流只能提供直播流方式，也就是说用户只能通过RTMP看直播，而不能看点播，即无法实现回看视频。因而，亟需要一种新的可以满足用户对于RTMP直播流的回看和点播需要的方案，以提高用户体验度。

发明内容

本发明提供一种RTMP直播回看方法及系统，用以解决现有技术中码RTMP直播流无法进行回看和点播的问题。

本发明提供一种RTMP直播回看方法，包括：

根据预先配置下载RTMP音视频流并解码得到音视频文件；

根据预先设定的策略将所述音视频文件编码生成音视频数据；

生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；

将所述回看音视频文件通过服务器发布。

所述方法还包括：

将所述RTMP音视频流解码为h264和aac数据并存入数据链表。

所述方法还包括：

将所述数据链表中的h264和aac数据按照每第一预设时长生成一个音视频文件。

所述方法还包括：

所述索引文件头包括所述音视频文件对应的TVM二进制数据遗迹对应的音视频编码信息。

所述方法还包括：

每第二预设时长根据所述音视频文件的信息生成一个索引文件；所述索引文件包括时间信息与所述音视频文件的位置。

所述方法还包括：

根据用户点播回看请求信息，查找索引文件；根据索引文件获取对应的回看音视频文件；重新封装后发送给用户。

一种RTMP直播回看系统，包括：

下载单元，用于根据预先配置下载RTMP音视频流并解码得到音视频文件；

编码单元，用于根据预先设定的策略将所述音视频文件编码生成音视频数据；

索引单元，用于生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；

发布单元，将所述回看音视频文件通过服务器发布。

所述系统还包括：

数据链表单元，用于存储所述的音视频文件。

所述系统还包括：

预设单元，用于设置第一预设时长和第二预设时长；

所述第一预设时长用于所述数据链表单元将数据按照每第一预设时长生成一个音视频文件；

所述第二预设时长用于所述索引单元每第二预设时长根据所述音视频文件的信息生成一个索引文件；所述索引文件包括时间信息与所述音视频文件的位置。

所述系统还包括：

检索单元，用于根据用户点播回看请求信息，查找索引文件；根据索引文件获取对应的回看音视频文件。

本发明实施例根据预先配置下载RTMP音视频流并解码得到音视频文件；根据预先设定的策略将所述音视频文件编码生成音视频数据；生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；将所述回看音视频文件通过服务器发布。本发明实施例的方案，能够将RTMP直播流转成了flv等格式的直播流，实现flv点播回看的功能，极大的提高了用户体验度。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

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

图1为本发明实施例1提供的一种RTMP直播回看方法原理流程图；

图2为本发明实施例3提供的一种RTMP直播回看系统结构示意图。

具体实施方式

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

如图1所示，为本发明实施例1提供的一种RTMP直播回看方法原理流程图，其中，

步骤11，根据预先配置下载RTMP音视频流并解码得到音视频文件。

本实施例中，首先需要获取RTMP音视频流。这里对于RTMP流的获取，可以根据预先设定的下载策略进行，也可以根据用户指定的地址进行。例如，可以预先配置好下载策略，在策略生效后，根据该下载策略进行具体的下载。

通常，RTMP协议基于TCP，是一个协议簇，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe MediaServer/Ultrant Media Server/red5等。

RTMP协议有三种变种：工作在TCP之上的明文协议，使用端口1935；RTMPT封装在HTTP请求之中，可穿越防火墙；RTMPS类似RTMPT，但使用的是HTTPS连接。

RTMP协议封包由一个包头和一个包体组成，包头可以是4种长度的任意一种：12，8，4，1 byte(s)。完整的RTMP包头应该是12bytes，包含了时间戳，AMFSize，AMFType，StreamID信息，8字节的包头只纪录了时间戳，AMFSize，AMFType，其他字节的包头纪录信息依次类推。包体最大长度默认为128字节，通过chunkSize可改变包体最大长度，通常当一段AFM数据超过128字节后，超过128的部分就放到了其他的RTMP封包中，包头为一个字节。

完整的12字节RTMP包头每个字节的含义：用途大小(Byte)含义、Head_Type1包头、TiMMER3时间戳、AMFSize3数据大小、AMFType1数据类型、StreamID4流ID。

一、Head_Type

第一个字节Head_Type的前两个Bit决定了包头的长度。它可以用掩码0xC0进行"与"计算：

Head_Type的前两个Bit和长度对应关系：

BitsHeader Length

0012 bytes

018 bytes

104 bytes

111 byte

Head_Type的后面6个Bit和StreamID决定了ChannelID。

StreamID和ChannelID对应关系：StreamID＝(ChannelID-4)/5+1参考red5。

ChannelIDUse02Ping和ByteRead通道；

03Invoke通道；connect()publish()和自字写的NetConnection。Call()数据都是在这个通道的。

04Audio和Vidio通道；

05 06 07服务器保留，经观察FMS2用这些Channel也用来发送音频或视频数据。

例如在RTMP包里面经常看到的0xC2，就表示一字节的包头，channel＝2。

二、TiMMER

TiMMER占3个字节纪录的是时间戳，音视频流的时间戳是统一排的。可分为绝对时间戳和相对时间戳。

fms对于同一个流，发布的时间戳接受的时间戳是有区别的。

publish时间戳，采用相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个媒体包的绝对时间戳之间的差距，也就是说音视频时间戳在一个时间轴上面。单位毫秒。

play时间戳，相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个同类型媒体包的绝对时间戳之间的差距，也就是说音视频时间戳分别为单独的时间轴，单位毫秒。

flv格式文件时间戳，绝对时间戳，时间戳长度3个字节。超过0xFFFFFF后时间戳值等于TimeStamp & 0xFFFFFF。

flv格式文件影片总时间长度保存在onMetaData的duration属性里面，长度为8个字节，是一个翻转的double类型。

三、AMFSize

AMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。如果超过了128字节，那么由多个后续RTMP封包组合，每个后续RTMP封包的头只占一个字节。一般就是以0xC？开头。

四、AMFType

AMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。

AMFType是包的类型

0×01Chunk Sizechanges the chunk size for packets

0×02Unknown

0×03Bytes Readsend every x bytes read by both sides

0×04Pingping is a stream control message，has subtypes

0×05Server BWthe servers downstream bw

0×06Client BWthe clients upstream bw

0×07Unknown

0×08Audio Datapacket containing audio

0×09Video Datapacket containing video data

0x0A-0x0EUnknown

0x0FFLEX_STREAM_SENDTYPE_FLEX_STREAM_SEND

0x10FLEX_SHARED_OBJECTTYPE_FLEX_SHARED_OBJECT

0x11FLEX_MESSAGETYPE_FLEX_MESSAGE

0×12Notifyan invoke which does not expect a reply

0×13Shared Objecthas subtypes

0×14Invokelike remoting call，used for stream actions too。

0×16StreamData这是FMS3出来后新增的数据类型，这种类型数据中包含AudioData和VideoData。

五、StreamID

StreamID是音视频流的ID，如果AMFType！＝0x08或！＝0x09那么StreamID为0。

ChannelID和StreamID之间的计算公式：StreamID＝(ChannelID-4)/5+1参考red5。

例如当ChannelID为2、3、4时StreamID都为1当ChannelID为9的时候StreamID为2。

六、封包分析

例如有一个RTMP封包的数据03 00 00 00 00 01 02 14 00 00 00 00 02 00 0763 6F 6E 6E 65 63 74 00 3F F0 00 00 00 00 00 00 08，，，

数据依次解析的含义：

03表示12字节头，channelid＝3

000000表示Timmer＝0

000102表示AMFSize＝18

14表示AMFType＝Invoke方法调用

00 00 00 00表示StreamID＝0

//到此，12字节RTMP头结束。

本步骤中，通常将RTMP音视频流解码为h264和aac数据并存入数据链表。

步骤12，根据预先设定的策略将音视频文件编码生成音视频数据。

将所述数据链表中的h264和aac数据按照每第一预设时长生成一个音视频文件。这里的第一预设时长是根据文件大小的需要设定的，例如，可以设置为1个小时。每一个小时的数据生成一个音视频文件。

H264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT，Joint VideoTeam)提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC(或者AVC/H.264或者H.264/MPEG-4AVC或MPEG-4/H.264AVC)而明确的说明它两方面的开发者。H264标准各主要部分有Access Unit delimiter(访问单元分割符)，SEI(附加增强信息)，primary coded picture(基本图像编码)，Redundant Coded Picture(冗余图像编码)。还有Instantaneous DecodingRefresh(IDR，即时解码刷新)、Hypothetical Reference Decoder(HRD，假想参考解码)、Hypothetical Stream Scheduler(HSS，假想码流调度器)。

aac是一种专为声音数据设计的文件压缩格式，与Mp3不同，它采用了全新的算法进行编码，更加高效，具有更高的“性价比”。利用aac格式，可使人感觉声音质量没有明显降低aac标志的前提下，更加小巧。aac所采用的运算法则与MP3的运算法则有所不同，aac通过结合其他的功能来提高编码效率。aac的音频算法在压缩能力上远远超过了以前的一些压缩算法(比如MP3等)。它还同时支持多达48个音轨、15个低频音轨、更多种采样率和比特率、多种语言的兼容能力、更高的解码效率。号称「最大能容纳48通道的音轨，采样率达96KHz，并且在320Kbps的数据速率下能为5.1声道音乐节目提供相当于ITU-R广播的品质。

本步骤中，将音视频文件经过重新编码，生成音视频数据，存储在数据链表中。

步骤13，生成音视频数据的索引文件头，将索引文件头和音视频数据封装成为回看音视频文件。

索引文件头包括音视频文件对应的TVM二进制数据遗迹对应的音视频编码信息。例如，每个小时生成一个数据文件，文件格式为：文件最开始为“TVM”二进制数据，然后后面跟着视频编码信息，如视频分辨率码率，及视频时间等信息，然后后面是h264与aac数据，另外每小时再生成一个索引文件，记录时间信息与在数据文件中的位置。

每第二预设时长根据音视频文件的信息生成一个索引文件；索引文件包括时间信息与所述音视频文件的位置。这里的第二预设时长同样根据需要设定，通常设置为一个小时。

步骤14，将回看音视频文件通过服务器发布。

根据用户点播回看请求信息，查找索引文件；根据索引文件获取对应的回看音视频文件；重新封装为flv格式，发送给用户。

用户请求直播或点播视频时前面nginx代理会把请求转到后边程序当中去，该程序收到请求时会根据用户请求观看视频的时间参数去索引文件中查找视频数据在数据文件位置，然后会去读数据文件，找到相关视频数据然后封装成flv视频流返回给用户。当用户请求直播时会返回最新的flv直播视频。请求过去的视频时会查找那个时刻的视频数据文件读取相关的视频数据然后封装成flv返回给用户点播视频。

本发明实施例2提供的一种RTMP直播回看方法，其中，

配置RTMP直播流地址。

根据配置下载RTMP直播流，将下载的RTMP直播流解成h264和aac数据，将这些数据存入链表中。

每个小时生成一个数据文件，文件格式为：文件最开始为“TVM”二进制数据，然后后面跟着视频编码信息，如视频分辨率码率，及视频时间等信息，然后后面是h264与aac数据，另外每小时再生成一个索引文件，记录时间信息与在数据文件中的位置。

用户请求直播或点播视频时前面nginx代理会把请求转到后边程序当中去，该程序收到请求时会根据用户请求观看视频的时间参数去索引文件中查找视频数据在数据文件位置，然后会去读数据文件，找到相关视频数据然后封装成flv视频流返回给用户。当用户请求直播时会返回最新的flv直播视频。请求过去的视频时会查找那个时刻的视频数据文件读取相关的视频数据然后封装成flv返回给用户点播视频。

本实施例将RTMP直播流转成了flv直播流，同时也实现flv点播回看的功能。

如图2所示，为本发明实施例3提供的一种RTMP直播回看系统结构示意图，其中，

下载单元31，用于根据预先配置下载RTMP音视频流并解码得到音视频文件；

编码单元32，用于根据预先设定的策略将音视频文件编码生成音视频数据；

索引单元33，用于生成音视频数据的索引文件头，将索引文件头和音视频数据封装成为回看音视频文件；

发布单元34，将回看音视频文件通过服务器发布。

特别的，上述系统还包括：

数据链表单元35，用于存储的音视频文件。

特别的，上述系统还包括：

预设单元36，用于设置第一预设时长和第二预设时长；

第一预设时长用于数据链表单元35将数据按照每第一预设时长生成一个音视频文件；

第二预设时长用于索引单元33每第二预设时长根据音视频文件的信息生成一个索引文件；索引文件包括时间信息与音视频文件的位置。

特别的，上述系统还包括：

检索单元37，用于根据用户点播回看请求信息，查找索引文件；根据索引文件获取对应的回看音视频文件。

综上所述，本发明实施例根据预先配置下载RTMP音视频流并解码得到音视频文件；根据预先设定的策略将所述音视频文件编码生成音视频数据；生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；将所述回看音视频文件通过服务器发布。本发明实施例的方案，能够将RTMP直播流转成了flv等格式的直播流，实现flv点播回看的功能，极大的提高了用户体验度。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种RTMP直播回看方法，其特征在于，包括：

根据预先配置下载RTMP音视频流并解码得到音视频文件；

根据预先设定的策略将所述音视频文件编码生成音视频数据；

生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；

将所述回看音视频文件通过服务器发布。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

将所述RTMP音视频流解码为h264和aac数据并存入数据链表。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

将所述数据链表中的h264和aac数据按照每第一预设时长生成一个音视频文件。

4.如权利要求1或3所述的方法，其特征在于，所述方法还包括：

所述索引文件头包括所述音视频文件对应的TVM二进制数据遗迹对应的音视频编码信息。

5.如权利要求1或3所述的方法，其特征在于，所述方法还包括：

每第二预设时长根据所述音视频文件的信息生成一个索引文件；所述索引文件包括时间信息与所述音视频文件的位置。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

根据用户点播回看请求信息，查找索引文件；根据索引文件获取对应的回看音视频文件；重新封装后发送给用户。

7.一种RTMP直播回看系统，其特征在于，包括：

下载单元，用于根据预先配置下载RTMP音视频流并解码得到音视频文件；

编码单元，用于根据预先设定的策略将所述音视频文件编码生成音视频数据；

索引单元，用于生成所述音视频数据的索引文件头，将所述索引文件头和音视频数据封装成为回看音视频文件；

发布单元，将所述回看音视频文件通过服务器发布。

8.如权利要求7所述的系统，其特征在于，所述系统还包括：

数据链表单元，用于存储所述的音视频文件。

9.如权利要求7所述的系统，其特征在于，所述系统还包括：

预设单元，用于设置第一预设时长和第二预设时长；

所述第一预设时长用于所述数据链表单元将数据按照每第一预设时长生成一个音视频文件；

所述第二预设时长用于所述索引单元每第二预设时长根据所述音视频文件的信息生成一个索引文件；所述索引文件包括时间信息与所述音视频文件的位置。

10.如权利要求7所述的系统，其特征在于，所述系统还包括：

检索单元，用于根据用户点播回看请求信息，查找索引文件；根据索引文件获取对应的回看音视频文件。