MP4文件实时流化网关控制系统及控制流程的制作方法

mp4文件实时流化网关控制系统及控制流程
技术领域
1.本发明涉及视频存储处理领域，尤其涉及mp4文件实时流化网关控制系统及控制流程。


背景技术：

2.随着目前互联网业务的蓬勃发展，视频在互联网中的重要性越来越突出，围绕着视频的各种业务形态层出不穷，长视频、短视频、直播、点播、卖货、社交等等方方面面都离不开视频技术的支持；互联网视频技术在这几年也有了长足的发展，各个厂家不断的开发新的产品和技术，不断的提升用户的体验；并且已经实现了电脑、手机、电视等的全终端的覆盖，从前几年的点播业务为主的方式，发展到了以点播和直播为主，并通过ai、ar、vr等技术来进一步丰富使用场景和效果，以增强用户的感受；
3.视频的品质也从标清化向高清化转变，随着内容的不断高清化，对于内容的传输、存储、转换的成本也在不断的提升；各厂家为了保证不同终端和业务场景的需求，需要对于视频进行多格式的处理。
4.目前有两个问题点需要解决：
5.1、存储问题：一个mp4格式的视频文件，如果支持手机使用，就需要转换出一个m3u8的格式内容，系统就需要保存两分不同格式的内容，存储量会增加一倍以上，在进行切片或转码的过程中，需要消耗大量的计算资源，如果通过云存储访问，还需要清耗大量的网络资源；
6.2、效率问题：对于一个mp4格式的视频文件，在进行切片或转码的过程中，不能够提供访问，用户需要等待处理完成后，才可以进行访问。


技术实现要素：

7.1.要解决的技术问题
8.本发明的目的是为了解决现有技术中视频存储和视频转码的问题，而提出的mp4文件实时流化网关控制系统及控制流程。
9.2.技术方案
10.为了实现上述目的，本发明采用了如下技术方案：
11.mp4文件实时流化网关控制系统，包括视频文件存储系统、odts系统和redis集群系统，所述视频文件存储系统的输出端与odts系统的输入端连接，所述odts系统的输出端与redis集群系统的输入端连接，所述视频文件存储系统包括云储存、nas和localdisk，所述云储存、nas和localdisk的输出端均与odts系统的输入端连接。
12.优选地，所述odts系统包括mp4头文件的分析、m3u8流文件的生成和ts文件片的实时生成。
13.优选地，所述mp4头文件的分析是指metadata信息的分析，mp4文件中的所有数据都装在box(quicktime中为atom)中，也就是说mp4文件由若干个box组成，每个box有类型和
长度，可以将box理解为一个数据对象块。
14.优选地，所述m3u8流文件的生成是根据获取的metadata的内容，从stss中提取的关键帧列表为基础生成m3u8列表文件，因为每个切片的第一帧都必须为关键帧，所以要以关键帧进行处理；并根据stts的内容生成每片的播放时长及每帧的pts和dts内容。
15.优选地，所述ts文件片的实时生成是根据m3u8访问的请求过来的ts切片请求，切片中含有帧的起始和终止帧号，服务接收到靖求后，通过分析mp4头文件的结果，得出需要获取的mp4的起始和终止位置，从服务器上下载相应的文件片段，并对于片段进行分解和重新封包处理，并返回ts的文件流。
16.本发明还提出了mp4文件实时流化网关控制系统的控制流程，包括以下步骤：
17.步骤1：odts服务从点播服务器接收http，并发送到redis获取缓存记录；
18.步骤2：所述步骤1中无缓存记录，则odts服务从点播服务器请求mp4头，获取mp4头后将数据发送到mp4头文件分析程序；
19.步骤3：所述mp4头文件分析程序将步骤2中分析的信息发送到redis，进行分析结果的保存。
20.优选地，所述步骤2中点播服务器接收请求，然后片段返回。
21.优选地，所述步骤1中redis如果有缓存记录，odts服务则生成m3u8文件。
22.优选地，所述mp4头文件分析程序的分析范围包括提取关键帧、提取sps/pps和提取tts。
23.优选地，所述步骤1中redis如果有缓存记录，同时向点播服务器请求片段下载，获取片段后发送到ts封包程序，ts封包程序提出音视频帧，然后进行ts封包，生成ts。
24.3.有益效果
25.相比于现有技术，本发明的优点在于：
26.(1)本发明中，odts通过对于mp4文件的实时流化来提供视的m3u8格式内容的访问，通过保留的mp4文件，实时的完成m3u8的格式转换，解决了多格式、多终端的视频内容的访问，实现用户秒播的体验，无需等待，还大大的降低了客户的存储成本。
27.(2)本发明中，只需保存一份mp4的原始视频即可，不需要再保存一分m3u8的格式内容，可以节省大量的存储空间；在观看播放时也只是把需要播放的部分下载到本地，与普通的ts内容的传输基本一致，并不会增加网络带宽的使用。
28.(3)本发明中，用户mp4视频内容上传完成后，即可进行访问，不需要再进行切片和迁移的工作，所以等待时间几乎为零；会极大的提升用户的操作体验。
29.(4)本发明中，因为现在基于m3u8协议的视频内容越来越普级，几乎已经是全终端的覆盖，而支持mp4格式的视频的播放还没有很普及，所以在互联网中使用最多的还是m3u8格式的内容，而通过该服务即可实现mp4和m3u8的双协议输出，可以方便的把业务扩展到各个终端上。
附图说明
30.图1为本发明提出的mp4文件实时流化网关控制系统的示意图；
31.图2为本发明提出的mp4文件实时流化网关控制系统的控制流程示意图。
具体实施方式
32.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。
33.实施例1：
34.参照图1
‑
2，mp4文件实时流化网关控制系统，包括视频文件存储系统、odts系统和redis集群系统，视频文件存储系统的输出端与odts系统的输入端连接，odts系统的输出端与redis集群系统的输入端连接，视频文件存储系统包括云储存、nas和localdisk，云储存、nas和localdisk的输出端均与odts系统的输入端连接；
35.本发明中，odts系统包括mp4头文件的分析、m3u8流文件的生成和ts文件片的实时生成，mp4头文件的分析是指metadata信息的分析，mp4文件中的所有数据都装在box(quicktime中为atom)中，也就是说mp4文件由若干个box组成，每个box有类型和长度，可以将box理解为一个数据对象块；
36.本发明中，box中可以包含另一个box，这种box称为containerbox。一个mp4文件首先会有且只有一个“ftyp”类型的box，作为mp4格式的标志并包含关于文件的一些信息；之后会有且只有一个“moov”类型的box(movie box)，它是一种container box，子box包含了媒体的metadata信息；mp4文件的媒体数据包含在“mdat”类型的box(midia data box)中，该类型的box也是container box，可以有多个，也可以没有(当媒体数据全部引用其他文件时)，媒体数据的结构由metadata进行描述。
37.本发明中，提取视音频的内容首先需要从分析mp4文件的moov box入手；moov信息中包含多个container box，trak box：其子box包含了该track的媒体数据引用和描述(hint track除外)。一个mp4文件中的媒体可以包含多个track，且至少有一个track，这些track之间彼此独立，有自己的时间和空间信息。“trak”必须包含一个“tkhd”和一个“mdia”，此外还有很多可选的box(略)。其中“tkhd”为track header box，“mdia”为media box，该box是一个包含一些track媒体数据信息box的container box。
38.本发明中，sample description box(stsd)：box header和version字段后会有一个entry count字段，根据entry的个数，每个entry会有type信息，如“vide”、“sund”等，根据type不同sample description会提供不同的信息，例如对于video track，会有“visualsampleentry”类型信息，对于audio track会有“audiosampleentry”类型信息。视频的编码类型、宽高、长度，音频的声道、采样等信息都会出现在这个box中。
39.本发明中，time to sample box：存储了sample的duration，描述了sample时序的映射方法，我们通过它可以找到任何时间的sample。“stts”可以包含一个压缩的表来映射时间和sample序号，用其他的表来提供每个sample的长度和指针。表中每个条目提供了在同一个时间偏移量里面连续的sample序号，以及samples的偏移量。递增这些偏移量，就可以建立一个完整的time to sample表。
40.本发明中，sample size box(stsz)：定义了每个sample的大小，包含了媒体中全部sample的数目和一张给出每个sample大小的表。这个box相对来说体积是比较大的。
41.本发明中，sample to chunk box(stsc)：用chunk组织sample可以方便优化数据获取，一个thunk包含一个或多个sample。“stsc”中用一个表描述了sample与chunk的映射关系，查看这张表就可以找到包含指定sample的thunk，从而找到这个sample。
42.本发明中，sync sample box(stss)：确定media中的关键帧。对于压缩媒体数据，关键帧是一系列压缩序列的开始帧，其解压缩时不依赖以前的帧，而后续帧的解压缩将依赖于这个关键帧。“stss”可以非常紧凑的标记媒体内的随机存取点，它包含一个sample序号表，表内的每一项严格按照sample的序号排列，说明了媒体中的哪一个sample是关键帧。如果此表不存在，说明每一个sample都是一个关键帧，是一个随机存取点。
43.本发明中，chunk offset box(stco)：定义了每个thunk在媒体流中的位置。位置有两种可能，32位的和64位的，后者对非常大的电影很有用。在一个表中只会有一种可能，这个位置是在整个文件中的，而不是在任何box中的，这样做就可以直接在文件中找到媒体数据，而不用解释box。需要注意的是一旦前面的box有了任何改变，这张表都要重新建立，因为位置信息已经改变了。
44.本发明中，m3u8流文件的生成是根据获取的metadata的内容，从stss中提取的关键帧列表为基础生成m3u8列表文件，因为每个切片的第一帧都必须为关键帧，所以要以关键帧进行处理；并根据stts的内容生成每片的播放时长及每帧的pts和dts内容；
45.本发明中，ts文件片的实时生成是根据m3u8访问的请求过来的ts切片请求，切片中含有帧的起始和终止帧号，服务接收到靖求后，通过分析mp4头文件的结果，得出需要获取的mp4的起始和终止位置，从服务器上下载相应的文件片段，并对于片段进行分解和重新封包处理，并返回ts的文件流。
46.本发明中，mp4文件实时流化网关控制系统的控制流程，包括以下步骤：
47.步骤1：odts服务从点播服务器接收http，并发送到redis获取缓存记录，redis如果有缓存记录，odts服务则生成m3u8文件，redis如果有缓存记录，同时向点播服务器请求片段下载，获取片段后发送到ts封包程序，ts封包程序提出音视频帧，然后进行ts封包，生成ts；
48.步骤2：步骤1中无缓存记录，则odts服务从点播服务器请求mp4头，获取mp4头后将数据发送到mp4头文件分析程序，mp4头文件分析程序的分析范围包括提取关键帧、提取sps/pps和提取tts，点播服务器接收请求，然后片段返回；
49.步骤3：mp4头文件分析程序将步骤2中分析的信息发送到redis，进行分析结果的保存。
50.本发明中，odts通过对于mp4文件的实时流化来提供视的m3u8格式内容的访问，通过保留的mp4文件，实时的完成m3u8的格式转换，解决了多格式、多终端的视频内容的访问，实现用户秒播的体验，无需等待，还大大的降低了客户的存储成本。
51.本发明中，只需保存一份mp4的原始视频即可，不需要再保存一分m3u8的格式内容，可以节省大量的存储空间；在观看播放时也只是把需要播放的部分下载到本地，与普通的ts内容的传输基本一致，并不会增加网络带宽的使用。
52.本发明中，用户mp4视频内容上传完成后，即可进行访问，不需要再进行切片和迁移的工作，所以等待时间几乎为零；会极大的提升用户的操作体验。
53.本发明中，因为现在基于m3u8协议的视频内容越来越普级，几乎已经是全终端的覆盖，而支持mp4格式的视频的播放还没有很普及，所以在互联网中使用最多的还是m3u8格式的内容，而通过该服务即可实现mp4和m3u8的双协议输出，可以方便的把业务扩展到各个终端上。
54.以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，根据本发明的技术方案及其发明构思加以等同替换或改变，都应涵盖在本发明的保护范围之内。