一种媒体文件合并方法及装置与流程

1.本技术涉及多媒体数据处理技术领域，尤其涉及一种媒体文件合并方法及装置。


背景技术：

2.在直播、点播等媒体业务场景中，经常遇到将媒体文件进行串联或者合并成一个文件的需求，例如：体育直播集锦、前置垫片流化、课件制作等功能。在这类业务场景中，常见的做法是一般是将多个不同格式文件转码成相同codec参数的文件，然后再统一连接起来成为一个文件，从而实现合并的目的。
3.这种做法属于简单暴力型做法，由于需要进行转码，其硬件成本较高，尤其是高分辨率的情况下，普通的机器可能需要满负荷运行，而且普通pc、超极本和不带硬件加速的设备进行转码速度极慢，几乎无法在用户可接受的情况下完成该工作。


技术实现要素：

4.基于上述技术现状，本技术提出一种媒体文件合并方法及装置，能够降低媒体文件合并的硬件成本，并且提高媒体文件合并效率。
5.一种媒体文件合并方法，包括：
6.对待合并的各媒体文件进行帧格式修正，使所述待合并的各媒体文件的帧格式统一；
7.对所述待合并的各媒体文件分别进行边界裁剪处理，使所述待合并的各媒体文件的音频内容和视频内容的边界对齐；
8.对所述待合并的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增。
9.可选的，在对待合并的各媒体文件进行帧格式修正后，所述方法还包括：
10.对所述待合并的各媒体文件进行帧率修正，使所述待合并的各媒体文件的帧率统一。
11.可选的，所述方法还包括：
12.为合并后的媒体文件添加媒体头。
13.可选的，所述为合并后的媒体文件添加媒体头，包括：
14.为合并后的媒体文件添加包含媒体文件特性标识的媒体头；
15.其中，所述媒体文件特性标识，用于表示合并后的媒体文件的profile和level。
16.可选的，所述对合并后的媒体文件进行时间戳修正处理，包括：
17.将合并后的媒体文件的起始位置的显示时间戳和解码时间戳设置为零；
18.从合并后的媒体文件的起始位置开始，依次对合并后的媒体文件的音频和视频进行升序交织以及同步设置显示时间戳和解码时间戳，其中，同步设置的显示时间戳和解码时间戳设置为设定时间基准下的显示时间戳和解码时间戳。
19.一种媒体文件合并装置，包括：
20.帧格式修正单元，用于对待合并的各媒体文件进行帧格式修正，使所述待合并的各媒体文件的帧格式统一；
21.边界裁剪单元，用于对所述待合并的各媒体文件分别进行边界裁剪处理，使所述待合并的各媒体文件的音频内容和视频内容的边界对齐；
22.时间戳修正单元，用于对帧率修正后的所述待合并的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增。
23.可选的，所述装置还包括：
24.帧率修正单元，用于对帧格式修正后的所述待合并的各媒体文件进行帧率修正，使所述待合并的各媒体文件的帧率统一。
25.可选的，所述装置还包括：
26.媒体头添加单元，用于为合并后的媒体文件添加媒体头。
27.可选的，所述为合并后的媒体文件添加媒体头，包括：
28.为合并后的媒体文件添加包含媒体文件特性标识的媒体头；
29.其中，所述媒体文件特性标识，用于表示合并后的媒体文件的profile和level。
30.可选的，所述对合并后的媒体文件进行时间戳修正处理，包括：
31.将合并后的媒体文件的起始位置的显示时间戳和解码时间戳设置为零；
32.从合并后的媒体文件的起始位置开始，依次对合并后的媒体文件的音频和视频进行升序交织以及同步设置显示时间戳和解码时间戳，其中，同步设置的显示时间戳和解码时间戳设置为设定时间基准下的显示时间戳和解码时间戳。
33.本技术提出的媒体文件合并方法，通过对待合并的各媒体文件进行帧格式修正、帧率修正，使各媒体文件的帧格式统一、音视频边界对齐，在此基础上对帧格式统一、音视频边界对齐的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增，以满足播放器播放要求。该方案可以在不需要对媒体文件进行转码的情况下，直接对媒体文件进行合并，从而可以降低媒体文件合并的硬件成本，在普通机器中也能实现媒体文件合并，并且，由于不需要进行媒体文件转码，因此处理速度更快，媒体文件合并效率更高。
附图说明
34.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
35.图1是本技术实施例提供的一种媒体文件合并方法的流程示意图；
36.图2是本技术实施例提供的另一种媒体文件合并方法的流程示意图；
37.图3是本技术实施例提供的又一种媒体文件合并方法的流程示意图；
38.图4是本技术实施例提供的一种媒体文件合并装置的结构示意图。
具体实施方式
39.本技术实施例技术方案适用于对媒体文件进行合并的应用场景，采用本技术实施
例技术方案，能够直接对媒体文件进行合并，不需要对媒体文件进行转码，从而降低媒体文件合并的硬件成本，提高媒体文件合并效率。
40.在常规技术方案中，媒体文件合并常见的做法一般是将多个不同格式文件转码成相同codec参数的文件方能进行合并，而媒体转码这种处理方式会导致资源和时间成本非常高。
41.具体表现为，常见的媒体文件合并的做法一般是将多个不同格式文件转码成相同codec参数的文件，然后再统一link起来成为一个文件，从而实现合并的目的。
42.这种做法属于简单暴力型做法，缺点主要有4点：
43.1、极高的硬件成本，尤其是高分辨率情况下，普通的机器可能负载直接打满；
44.2、极高的时间成本，转码速度巨慢，可能需要几倍于视频本身时长的转码时间；
45.3、设备限制条件高，普通pc、超极本和不带硬件加速的设备转码极慢，移动设备由于其本身电池和定位几乎无法在用户可接受的情况下完成该工作；
46.4、画质损失大，转码必定会带来一定的画质损失，具体和设定相关参数正相关。
47.鉴于上述的媒体文件合并方法的缺陷和不足，本技术实施例提出一种直接合并媒体文件的方案，该方案能够在不需要对媒体文件进行转码的情况下，直接对媒体文件进行合并，从而降低媒体文件合并的硬件成本，提升媒体文件合并效率。
48.本技术技术方案的发明人通过对媒体文件的codec参数和媒体流化特性进行分析研究发现，在媒体文件合并业务场景中，涉及的媒体文件合并可以分为如下三大类：
49.1)相同codec类型，profile相同，level一致或不同；
50.2)相同codec类型，profile不同，level一致或不同；
51.3)不同codec类型(如h264和h265完全不同)。
52.其中，codec类型用于表示媒体文件的编解码方式和适用的编解码器类型。profile用于表示媒体文件压缩特性，如压缩画质、颜色采样数等；level用于表示媒体文件本技术特性，如码率、分辨率等。简言之，profile越高，说明采用了越高级的压缩特性，level越高，则视频的码率，分辨率、fps等规格越高。
53.对于上述的第三类媒体文件合并情况，如果不对不同codec类型的媒体文件进行转码，则合并后的媒体文件不能通过通用播放器播放。如果想要通过通用播放器对合并后的媒体文件进行播放，则仍然需要转码为统一codec参数后再进行合并。如果想要不转码实现不同codec类型的媒体文件的合并，需要配合特定的播放器进行解码播放，特定的播放器增加了文件描述列表配合压包，然后解码时根据文件描述+尾端双buffer预解码方案来保障流程解码播放。
54.本技术实施例技术方案主要是针对上述的相同codec类型的媒体文件的合并，即，相同codec类型，profile相同或不同、level一致或不同的媒体文件的合并。
55.对于上述的第三类媒体文件合并情况，即不同codec类型的媒体文件的合并，可以根据上述介绍，参照本技术实施例介绍的媒体文件合并方法进行合并，然后，再对合并文件添加文件描述列表配合压包，然后解码时根据文件描述+尾端双buffer预解码方案来保障流程解码播放，即通过本技术实施例提出的媒体文件合并方案对不同codec类型的媒体文件进行合并，配合特定的播放器实现对合并媒体文件的正常播放。
56.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完
整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
57.本技术实施例首先提出一种媒体文件合并方法，参见图1所示，该方法包括：
58.s101、对待合并的各媒体文件进行帧格式修正，使所述待合并的各媒体文件的帧格式统一。
59.具体的，上述的待合并的各媒体文件，是指需要进行合并的至少两个媒体文件。
60.示例性的，该至少两个媒体文件，具体是codec类型相同，profile相同或不同，level一致或不同的媒体文件。
61.不同的媒体文件，可能采用不同的封装容器格式，而不同的封装容器格式，其对数据包的描述头(即数据包起始码)和切割方式(如切割间隔、切割的数据包大小等)不完全一致。
62.本技术实施例对待合并的各媒体文件进行帧格式修正，具体是将待合并的各个不同帧格式的媒体文件，修正为与其中某一个待合并的媒体文件的帧格式(可视为目标帧格式)相同的帧格式。具体实现时，将与目标帧格式不同的待合并的媒体文件的帧格式，修正为目标帧格式即可。
63.比如，avc/hevc的packet数据存储在磁盘上时，裸流文件中的是annexb格式，而网络传输时或者是mp4格式的文件则多是avcc格式，此时，需要修正待合并的各媒体文件的这些帧格式的不同，以保持合并后的媒体文件的帧格式统一。
64.通常情况下，annexb格式的文件是以00 00 00 01作为数据包起始码，而avcc格式的文件则是以4字节的数据包大小标识作为数据包起始码。
65.针对上述情况，本技术实施例依次对待合并的各媒体文件的所有封包数据(nalu)单元按照相同方式进行切割，然后将avcc格式文件的数据包起始码替换为annexb格式文件的数据包起始码，从而使得所有数据包的起始码相同。
66.示例性的，上述的依次对待合并的各媒体文件的所有封包数据(nalu)单元按照相同方式进行切割，可以是针对待合并的各个媒体文件，分别按照相同方式进行封包数据单元切割；也可以是对待合并的各媒体文件进行合并后，再对合并后的完整媒体文件按照相同方式进行封包数据单元切割。
67.示例性的，上述的对媒体文件按照相同方式进行封包数据单元切割，可以先从4字节的封包数据单元起始码解析确定数据包大小，假设以“size”表示，然后从数据包起始位置偏移“size”大小的地址，作为切割位置。在该切割位置进行切割，得到一个封包数据包。然后再执行下一次封包数据单元切割。
68.s102、对所述待合并的各媒体文件分别进行边界裁剪处理，使所述待合并的各媒体文件的音频内容和视频内容的边界对齐。
69.具体的，理论上，一个封装完好的媒体文件的音视频交织是均匀的，不会出现数据空洞，但是实际中，在对媒体文件进行合并时，经常发现媒体文件头尾交织处会出现冗余音频包或视频包，具体表现为文件的音频包没有对应的视频包，或者文件的视频包没有对应的音频包。
70.在这种情况下，如果直接对各个媒体文件进行合并，则会导致在不同媒体文件合
并位置处出现卡顿，例如只有图像没有声音，或者只有声音没有图像。因此，需要对待合并的各媒体文件的边界位置进行裁剪处理，使其边界位置处的音频内容和视频内容的边界对齐。
71.示例性的，假设以“＝”表示音频内容和视频内容对齐的状态，而以
“‑”
表示只有音频内容或者只有视频内容的状态，也就是单行的数据。假设某一媒体文件的音频内容和视频内容分布状态为
“‑‑‑‑
＝＝＝＝＝＝
‑‑‑‑‑‑”
，则，当该媒体文件参与媒体文件合并时，将该媒体文件头部的单行数据
“‑‑‑‑”
，以及尾部的单行数据
“‑‑‑‑‑‑”
删除，得到的媒体文件的音频内容和视频内容分布状态为“＝＝＝＝＝＝”，即，使得媒体文件的音频内容和视频内容的边界对齐。
72.s103、对所述待合并的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增。
73.具体的，待合并的各个媒体文件的显示时间戳都是独立的，而播放器要求播放的媒体文件的显示时间戳pts必须是单调递增的，因此在将待合并的各媒体文件进行合并后，需要对合并后的媒体文件的显示时间戳进行修正，并且，统一媒体文件的时间基准，使合并后的媒体文件的显示时间戳单调递增。
74.示例性的，将待合并的各媒体文件进行合并得到合并后的媒体文件后，从该合并后的媒体文件的起始位置开始，按照统一的时间基准，从0开始按照单调递增的顺序，依次为该媒体文件设置显示时间戳pts，直至合并后的媒体文件结束。
75.具体的，上述的对合并后的媒体文件进行时间戳修正处理，具体可以通过执行如下步骤a1
‑
a2实现：
76.a1、将合并后的媒体文件的起始位置的显示时间戳和解码时间戳设置为零。
77.具体的，在将待合并的各个媒体文件进行合并得到合并后的媒体文件后，将该合并后的媒体文件的起始位置的显示时间戳和解码时间戳设置为零，即，将合并后的媒体文件的start pts，以及start dts，均设置为零。
78.a2、从合并后的媒体文件的起始位置开始，依次对合并后的媒体文件的音频和视频进行升序交织以及同步设置显示时间戳和解码时间戳，其中，所设置的显示时间戳和解码时间戳，为设定时间基准下的显示时间戳和解码时间戳。
79.具体的，在对合并后的媒体文件的起始位置的显示时间戳和解码时间戳置零后，从该合并后的媒体文件的起始位置开始，依次对合并后的媒体文件的音频和视频进行升序交织，以及随着交织的推进，以单调递增的方式同步为交织后的媒体文件内容设置显示时间戳和解码时间戳。
80.上述的对合并后的媒体文件的音频和视频进行升序交织，是指按照视频帧和音频帧从前到后的顺序，也就是按照视频帧号和音频帧号从小到大的顺序，依次对视频帧和音频帧进行交织，使媒体文件的音频和视频对应融合。经过升序交织后，在播放媒体文件时，能够在同一时刻从媒体文件中解码得到视频帧以及与视频帧对应的音频帧，即能够解码出相对应的视频和音频。以满足用户视听需求。
81.在对交织文件设置显示时间戳和解码时间戳时，将显示时间戳和解码时间戳设置为以1/1000000为时间基准的时间戳。
82.其中，设定时间基准下的显示时间戳和解码时间戳可以通过对原显示时间戳和解
码时间戳的时间基准进行转换而实现。即，将原时间基准下的显示时间戳和解码时间戳等价转换为设定时间基准下的显示时间戳和解码时间戳。
83.例如，如果想要对交织文件设置以timebase＝1/1000000为时间基准的显示时间戳和解码时间戳，则目标时间基准tb_b＝timebase，假设显示时间戳的原时间基准为tb_a，则通过公式pts_a*tb_a＝pts_b*tb_b，即可将原显示时间戳pts_a转换为以timebase＝1/1000000为时间基准的显示时间戳pts_b。
84.同理，解码时间戳的设置可以参照上述方式执行。
85.通过上述介绍可见，本技术实施例提出的媒体文件合并方法，通过对待合并的各媒体文件进行帧格式修正、帧率修正，使各媒体文件的帧格式统一、音视频边界对齐，在此基础上对帧格式统一、音视频边界对齐的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增，以满足播放器播放要求。该方案可以在不需要对媒体文件进行转码的情况下，直接对媒体文件进行合并，从而可以降低媒体文件合并的硬件成本，在普通机器中也能实现媒体文件合并，并且，由于不需要进行媒体文件转码，因此处理速度更快，媒体文件合并效率更高。
86.图2示出了另一种媒体文件合并方法的流程示意图，参见图2所示，本技术实施例提出的另一种媒体文件合并方法，包括：
87.s201、对待合并的各媒体文件进行帧格式修正，使所述待合并的各媒体文件的帧格式统一。
88.具体的，上述的待合并的各媒体文件，是指需要进行合并的至少两个媒体文件。
89.示例性的，该至少两个媒体文件，具体是codec类型相同，profile相同或不同，level一致或不同的媒体文件。
90.不同的媒体文件，可能采用不同的封装容器格式，而不同的封装容器格式，其对数据包的描述头(即数据包起始码)和切割方式(如切割间隔、切割的数据包大小等)不完全一致。
91.本技术实施例对待合并的各媒体文件进行帧格式修正，具体是将待合并的各个不同帧格式的媒体文件，修正为与其中某一个待合并的媒体文件的帧格式(可视为目标帧格式)相同的帧格式。具体实现时，将与目标帧格式不同的待合并的媒体文件的帧格式，修正为目标帧格式即可。
92.比如，avc/hevc的packet数据存储在磁盘上时，裸流文件中的是annexb格式，而网络传输时或者是mp4格式的文件则多是avcc格式，此时，需要修正待合并的各媒体文件的这些帧格式的不同，以保持合并后的媒体文件的帧格式统一。
93.通常情况下，annexb格式的文件是以00 00 00 01作为数据包起始码，而avcc格式的文件则是以4字节的数据包大小标识作为数据包起始码。
94.针对上述情况，本技术实施例依次对待合并的各媒体文件的所有封包数据(nalu)单元按照相同方式进行切割，然后将avcc格式文件的数据包起始码替换为annexb格式文件的数据包起始码，从而使得所有数据包的起始码相同。
95.示例性的，上述的依次对待合并的各媒体文件的所有封包数据(nalu)单元按照相同方式进行切割，可以是针对待合并的各个媒体文件，分别按照相同方式进行封包数据单元切割；也可以是对待合并的各媒体文件进行合并后，再对合并后的完整媒体文件按照相
同方式进行封包数据单元切割。
96.示例性的，上述的对媒体文件按照相同方式进行封包数据单元切割，可以先从4字节的封包数据单元起始码解析确定数据包大小，假设以“size”表示，然后从数据包起始位置偏移“size”大小的地址，作为切割位置。在该切割位置进行切割，得到一个封包数据包。然后再执行下一次封包数据单元切割。
97.s202、对所述待合并的各媒体文件分别进行边界裁剪处理，使所述待合并的各媒体文件的音频内容和视频内容的边界对齐。
98.具体的，理论上，一个封装完好的媒体文件的音视频交织是均匀的，不会出现数据空洞，但是实际中，在对媒体文件进行合并时，经常发现媒体文件头尾交织处会出现冗余音频包或视频包，具体表现为文件的音频包没有对应的视频包，或者文件的视频包没有对应的音频包。
99.在这种情况下，如果直接对各个媒体文件进行合并，则会导致在不同媒体文件合并位置处出现卡顿，例如只有图像没有声音，或者只有声音没有图像。因此，需要对待合并的各媒体文件的边界位置进行裁剪处理，使其边界位置处的音频内容和视频内容的边界对齐。
100.示例性的，假设以“＝”表示音频内容和视频内容对齐的状态，而以
“‑”
表示只有音频内容或者只有视频内容的状态，也就是单行的数据。假设某一媒体文件的音频内容和视频内容分布状态为
“‑‑‑‑
＝＝＝＝＝＝
‑‑‑‑‑‑”
，则，当该媒体文件参与媒体文件合并时，将该媒体文件头部的单行数据
“‑‑‑‑”
，以及尾部的单行数据
“‑‑‑‑‑‑”
删除，得到的媒体文件的音频内容和视频内容分布状态为“＝＝＝＝＝＝”，即，使得媒体文件的音频内容和视频内容的边界对齐。
101.s203、对所述待合并的各媒体文件进行帧率修正，使所述待合并的各媒体文件的帧率统一。
102.具体的，上述的帧率，是指每秒输出的视频画面数量或音频样本单元数据量，即通常所说的fps。
103.显而易见的，不同的媒体文件的帧率很可能不同，如果将不同帧率的媒体文件直接合并，会导致合并的媒体文件的帧率不一致的情况，因此，需要对参与合并的各媒体文件的帧率进行修正，使各个待合并的媒体文件的帧率统一，从而解决不同媒体文件中的视频帧率差异和音频采样标准化的问题。
104.示例性的，本技术实施例在对待合并的各个媒体文件进行帧率修正时，将各个媒体文件的音频采样率重采样为统一的采样率，例如，将44100的采样率统一重采样为48000，或者将48000的采样率统一重采样为44100，具体可以通过ffmpeg实现音频采样率的转换。
105.对于各个媒体文件中的视频，在保证视频帧与相应的音频同步的情况下，可以根据音频帧的帧率设置视频帧帧率，以及，根据每帧视频帧的持续时长duration，设定显示时间戳pts。
106.例如，对于44100采样率的音频，其每秒包含44100个样本点，假设每帧包含1024个样本点，则一帧的持续时长duration为(1s/44100)*1024＝0.023s，所以，第一帧的显示时间戳pts为0.023s，那么第二帧就是0.023*2s，以此类推。同时可以确定，音频帧率为1/0.023＝43.478。
107.对于媒体文件中的视频：比如fps＝25，即每秒播放25帧视频帧，那么每一视频帧的持续时长duration＝1/25＝0.040s。因此，第一视频帧的显示时间戳pts为0.040s，第二视频帧的显示时间戳就是0.040*2s，以此类推。同时可以确定视频帧率为1/0.040＝25。
108.需要说明的是，本技术实施例所提出的媒体文件合并方法，使得合并后的文件能够通过通用播放器进行解码播放。通常情况下，通用播放器只能针对某一帧率的文件进行解码播放，因此需要执行上述步骤s203，实现对媒体文件的帧率统一。当播放器支持变帧率解码时，可以跳过上述步骤s203，即不需要执行帧率统一处理，此时，变帧率播放器可以适配媒体文件的不同帧率部分进行变帧率解码。
109.s204、对所述待合并的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增。
110.具体的，待合并的各个媒体文件的显示时间戳都是独立的，而播放器要求播放的媒体文件的显示时间戳pts必须是单调递增的，因此在将待合并的各媒体文件进行合并后，需要对合并后的媒体文件的显示时间戳进行修正，并且，统一媒体文件的时间基准，使合并后的媒体文件的显示时间戳单调递增。
111.示例性的，将待合并的各媒体文件进行合并得到合并后的媒体文件后，从该合并后的媒体文件的起始位置开始，按照统一的时间基准，从0开始按照单调递增的顺序，依次为该媒体文件设置显示时间戳pts，直至合并后的媒体文件结束。
112.可以理解，本技术实施例提出的媒体文件合并方法，采用了媒体文件边界整流技术，使得待合并的各媒体文件的音频内容和视频内容的边界对齐，从而可以避免数据衔接空洞带来的画面或声音不同步的问题。
113.图3示出了另一种媒体文件合并方法的流程示意图，参见图3所示，本技术实施例提出的另一种媒体文件合并方法，包括：
114.s301、对待合并的各媒体文件进行帧格式修正，使所述待合并的各媒体文件的帧格式统一。
115.具体的，上述的待合并的各媒体文件，是指需要进行合并的至少两个媒体文件。
116.示例性的，该至少两个媒体文件，具体是codec类型相同，profile相同或不同，level一致或不同的媒体文件。
117.不同的媒体文件，可能采用不同的封装容器格式，而不同的封装容器格式，其对数据包的描述头和切割方式不完全一致。
118.比如，avc/hevc的packet数据存储在磁盘上时，裸流文件中的是annexb格式，而网络传输时或者是mp4格式的文件则多是avcc格式，此时，需要修正待合并的各媒体文件的这些帧格式的不同，以保持合并后的媒体文件的帧格式统一。
119.通常情况下，annexb格式的文件是以0000 00 01作为封包起始码，而avcc格式的文件则是以4字节的数据包大小标识作为起始字节。
120.针对上述情况，本技术实施例依次对待合并的各媒体文件的所有封包数据(nalu)单元进行切割，然后将avcc格式文件的数据包起始码替换为annexb格式文件的数据包起始码，从而使得所有数据包的起始码相同。
121.示例性的，上述的依次对待合并的各媒体文件的所有封包数据(nalu)单元进行切割，可以是针对待合并的各个媒体文件，分别进行封包数据单元切割；也可以是对待合并的
各媒体文件进行合并后，再对合并后的完整媒体文件进行封包数据单元切割。
122.示例性的，上述的对媒体文件进行封包数据单元切割，可以先从4字节的封包数据单元起始码解析确定数据包大小，假设以“size”表示，然后从数据包起始位置偏移“size”大小的地址，作为切割位置。在该切割位置进行切割，得到一个封包数据包。然后再执行下一次封包数据单元切割。
123.s302、对所述待合并的各媒体文件分别进行边界裁剪处理，使所述待合并的各媒体文件的音频内容和视频内容的边界对齐。
124.具体的，理论上，一个封装完好的媒体文件的音视频交织是均匀的，不会出现数据空洞，但是实际中，在对媒体文件进行合并时，经常发现媒体文件头尾交织处会出现冗余音频包或视频包，具体表现为文件的音频包没有对应的视频包，或者文件的视频包没有对应的音频包。
125.在这种情况下，如果直接对各个媒体文件进行合并，则会导致在不同媒体文件合并位置处出现卡顿，例如只有图像没有声音，或者只有声音没有图像。因此，需要对待合并的各媒体文件的边界位置进行裁剪处理，使其边界位置处的音频内容和视频内容的边界对齐。
126.示例性的，假设以“＝”表示音频内容和视频内容对齐的状态，而以
“‑”
表示只有音频内容或者只有视频内容的状态，也就是单行的数据。假设某一媒体文件的音频内容和视频内容分布状态为
“‑‑‑‑
＝＝＝＝＝＝
‑‑‑‑‑‑”
，则，当该媒体文件参与媒体文件合并时，将该媒体文件头部的单行数据
“‑‑‑‑”
，以及尾部的单行数据
“‑‑‑‑‑‑”
删除，得到的媒体文件的音频内容和视频内容分布状态为“＝＝＝＝＝＝”，即，使得媒体文件的音频内容和视频内容的边界对齐。
127.s303、对所述待合并的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增。
128.具体的，待合并的各个媒体文件的显示时间戳都是独立的，而播放器要求播放的媒体文件的显示时间戳pts必须是单调递增的，因此在将待合并的各媒体文件进行合并后，需要对合并后的媒体文件的显示时间戳进行修正，并且，统一媒体文件的时间基准，使合并后的媒体文件的显示时间戳单调递增。
129.示例性的，将待合并的各媒体文件进行合并得到合并后的媒体文件后，从该合并后的媒体文件的起始位置开始，按照统一的时间基准，从0开始按照单调递增的顺序，依次为该媒体文件设置显示时间戳pts，直至合并后的媒体文件结束。
130.s304、为合并后的媒体文件添加媒体头。
131.具体的，为合并后的媒体文件添加媒体头，主要是在合并后的媒体文件的头部插入sps/pps等关键头信息，这样在支持动态解析的播放器上可以实时获取到相关信息的变化，刷新缓存配置和数据，重新进行解析处理。
132.进一步的，由于本技术实施例是对合并后的媒体文件添加媒体头，为了能够更加准确、全面地表达媒体文件的属性信息，本技术实施例为合并后的媒体文件添加包含媒体文件特性标识的媒体头。
133.其中，媒体文件的特性标识，用于表示合并后的媒体文件的profile和level。
134.示例性的，假设参与合并的各媒体文件是相同codec类型，profile相同，level一
致或不同的媒体文件，则合并后的媒体文件的特性标识中的level，按照参与合并的各媒体文件中的高level规格配置进行统一标识。也就是说，当参与合并的各个媒体文件的level不同时，在合并后，合并文件的level的值，设定为参与合并的各个媒体文件的level中的高level取值。
135.假设参与合并的各媒体文件是相同codec类型，profile不同，level一致或不同的媒体文件，则合并后的媒体文件的特性标识，按照参与合并的各媒体文件中的高level和profile的配置进行统一标识，例如level3.0(规格等级3.0)、profie high(技术等级高级画质)。
136.上述的为合并后的媒体文件添加媒体头的操作，使得合并后的媒体文件可以成功被播放器动态解码播放，从而解决了合并媒体文件对播放器的兼容性问题。
137.与上述的媒体文件合并方法相对应的，本技术实施例还提出一种媒体文件合并装置，参见图4所示，该装置包括：
138.帧格式修正单元100，用于对待合并的各媒体文件进行帧格式修正，使所述待合并的各媒体文件的帧格式统一；
139.边界裁剪单元110，用于对所述待合并的各媒体文件分别进行边界裁剪处理，使所述待合并的各媒体文件的音频内容和视频内容的边界对齐；
140.时间戳修正单元120，用于对所述待合并的各媒体文件进行合并，并对合并后的媒体文件进行时间戳修正处理，使合并后的媒体文件的显示时间戳单调递增。
141.可选的，所述装置还包括：
142.帧率修正单元，用于对所述待合并的各媒体文件进行帧率修正，使所述待合并的各媒体文件的帧率统一。
143.可选的，所述装置还包括：
144.媒体头添加单元，用于为合并后的媒体文件添加媒体头。
145.可选的，所述为合并后的媒体文件添加媒体头，包括：
146.为合并后的媒体文件添加包含媒体文件特性标识的媒体头；
147.其中，所述媒体文件特性标识，用于表示合并后的媒体文件的profile和level。
148.可选的，所述对合并后的媒体文件进行时间戳修正处理，包括：
149.将合并后的媒体文件的起始位置的显示时间戳和解码时间戳设置为零；
150.从合并后的媒体文件的起始位置开始，依次对合并后的媒体文件的音频和视频进行升序交织以及同步设置显示时间戳和解码时间戳，其中，同步设置的显示时间戳和解码时间戳设置为设定时间基准下的显示时间戳和解码时间戳。
151.具体的，上述的媒体文件合并装置的各个单元的具体工作内容，请参见上述方法实施例的内容，此处不再赘述。
152.对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
153.需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
154.本技术各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减，各实施例中记载的技术特征可以进行替换或者组合。
155.本技术各实施例种装置及终端中的模块和子模块可以根据实际需要进行合并、划分和删减。
156.本技术所提供的几个实施例中，应该理解到，所揭露的终端，装置和方法，可以通过其它的方式实现。例如，以上所描述的终端实施例仅仅是示意性的，例如，模块或子模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个子模块或模块可以结合或者可以集成到另一个模块，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
157.作为分离部件说明的模块或子模块可以是或者也可以不是物理上分开的，作为模块或子模块的部件可以是或者也可以不是物理模块或子模块，即可以位于一个地方，或者也可以分布到多个网络模块或子模块上。可以根据实际的需要选择其中的部分或者全部模块或子模块来实现本实施例方案的目的。
158.另外，在本技术各个实施例中的各功能模块或子模块可以集成在一个处理模块中，也可以是各个模块或子模块单独物理存在，也可以两个或两个以上模块或子模块集成在一个模块中。上述集成的模块或子模块既可以采用硬件的形式实现，也可以采用软件功能模块或子模块的形式实现。
159.专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
160.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件单元，或者二者的结合来实施。软件单元可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd
‑
rom、或技术领域内所公知的任意其它形式的存储介质中。
161.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
162.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的
一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。