一种多路音视频同步直播方法和系统与流程

1.本技术涉及网络直播技术领域，特别是涉及一种多路音视频同步直播方法和系统。


背景技术：

2.随着直播行业快速发展，用户对于观看音视频的创新需求随之增加，多屏同步互动、多角度同步直播等新颖的直播方式，在生活中也逐步得到应用，然而，如何保证多路音视频直播的同步性，是目前待解决的核心问题。
3.在相关技术中，由于各路视频的帧率、分辨率、码率等参数存在差异，导致生成的切片文件的速度、切片包含的视频长度等都存在固有的差异。例如，采用当前主流的hls协议将rtmp视频流封装为一个个ts切片文件时，多路音视频流的帧率、分辨率、码率等参数差异会导致生成ts文件的速度、ts文件包含的视频长度等差异，进而导致多路视频的播放起始画面不同步以及播放速度的不一致。
4.因此，无法采用传统的方式对多路音视频进行校准，即使可以对起始切片校准，但是，由于切片的速度和长度均不同，随着播放的进行多路音视频也会越来越不同步，即出现多路视频的帧时间戳是同步的但是画面却不同步的情况。
5.目前针对相关技术中多路音视频无法同步播放的问题，尚未提出有效的解决方案。


技术实现要素：

6.本技术实施例提供了一种多路音视频同步直播方法、系统、计算机设备和计算机可读存储介质，以至少解决相关技术中多路音视频无法同步播放的问题。
7.第一方面，本技术实施例提供了一种多路音视频同步直播方法，所述方法包括：服务端采集多路音视频，分别对各路音视频进行格式转换，生成各路音视频对应的切片文件和索引文件，并提取每个切片文件音频时间戳和序号并将其写入在所述索引文件中；终端发送播放请求，从所述服务端获取各路音视频对应的索引文件，根据所述索引文件中的音频时间戳，分别在每一路音视频中选择一个切片文件作为起始切片，其中，各路音视频选中的起始切片之间，所述音频时间戳的差值最小，在各路起始切片的音频时间戳中，选择时间进度最快的一个作为基准时间戳，实时下载索引文件中各路音视频的切片文件，并根据所述基准时间戳校准各路音视频的切片文件后进行播放。
8.在其中一些实施例中，根据所述基准时间戳校准各路音视频的切片文件后进行播放，包括：获取所述基准时间戳对应的基准路音视频；分别计算其他各路音视频的起始切片文件的音频时间戳，与所述基准时间戳的差
值，得到其他各路音视频的校准时间差；根据所述校准时间差，校准其他各路音视频的起始切片，并播放所述起始切片，之后，按照切片序号，顺序播放各路音视频的后续切片文件。
9.在其中一些实施例中，分别计算其他各路音视频的起始切片文件的音频时间戳，与所述基准时间戳的差值之后，所述方法还包括：获取所述各路音视频在所述终端上的加载时间，计算所述其他各路音视频的加载时间与所述基准路音视频的加载时间差值；基于所述加载时间差值和所述基准时间戳的差值，得到其他各路音视频的校准时间差；根据所述校准时间差，校准其他各路音视频的起始切片，并播放所述起始切片，之后，按照切片序号，顺序播放各路音视频的后续切片文件。
10.在其中一些实施例中，根据所述校准时间差，校准其他各路音视频的起始切片，包括：将所述其他各路音视频的起始切片，按照所述校准时间差快进至与所述基准时间戳相同的时间进度。
11.在其中一些实施例中，顺序播放各路音视频的后续切片文件之后，所述方法还包括：实时获取各路视频的累计播放时间；根据所述累计播放时间检测多路音视频是否同步播放，若否，获取播放最快的一路音视频画面的播放时间，并以其为基准时间，对其他路画面重新进行校准。
12.在其中一些实施例中，实时下载索引文件中各路音视频的切片文件，并根据所述基准时间戳校准各路音视频的切片文件后进行播放的过程中，所述方法还包括：所述终端接收用户自定义操作指令，根据所述自定义操作指令，在前端显示界面上，分别对所述各路音视频的画面进行编辑处理，其中，所述自定义操作指令包括：画面缩放指令、画面移动指令、画面悬浮指令和画面删减指令。
13.在其中一些实施例中所述多路音视频是rtmp流文件，所述服务端分别将每一路音视频的rtmp流文件转换为hls文件，分别得到多组切片文件和一个索引文件。
14.第二方面，本技术实施例提供了一种多路音视频同步直播系统，其特征在于，所述系统包括：服务端和终端，其中；所述服务端用于，采集多路音视频，分别对各路音视频进行格式转换，生成各路音视频对应的切片文件和索引文件，并提取每个切片文件音频时间戳和序号并将其写入在所述索引文件中；所述终端用于，发送播放请求，从所述服务端获取各路音视频对应的索引文件，根据所述索引文件中的音频时间戳，分别在每一路音视频中选择一个切片文件作为起始切片，其中，各路音视频选中的起始切片之间，所述音频时间戳的差值最小，以及，在各路起始切片的音频时间戳中，选择时间进度最快的一个作为基准时间戳，实时下载索引文件中各路音视频的切片文件，并根据所述基准时间戳校准各路音视频
的切片文件后进行播放。
15.第三方面，本技术实施例提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的方法。
16.第四方面，本技术实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的方法。
17.相比于相关技术，本技术实施例提供的多路音视频同步直播方法，至少具备如下有益效果：基于音频时间戳进行校准，在应用切片流文件传递多路音视频的场景下，对于视频参数（码率、帧率、分辨率等）不同的多路音视频件，也能够实现良好的同步直播效果；传统方式中为了克服多路视频流切片无法准确校准，从而将多路音视频合并为一路视频发送至终端的方式，本实施例中，用户接收到的是多个独立的视频流，用户在体验同步播放的同时，仍可以按照自身需求独立编辑每一路音视频画面，且仍然可以维持原有视频画质。
附图说明
18.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：图1是根据本技术实施例的多路音视频同步直播方法的应用环境示意图；图2是根据本技术实施例的一种多路音视频同步直播方法的流程图；图3是根据本技术实施例中的根据基准时间戳校准个路音视频的切片文件后的流程图；图4是根据本技术实施例的一种多路音视频同步直播系统的结构框图；图5是根据本技术实施例的电子设备的内部结构示意图。
具体实施方式
19.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。基于本技术提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
20.显而易见地，下面描述中的附图仅仅是本技术的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本技术应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本技术公开的内容相关的本领域的普通技术人员而言，在本技术揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本技术公开的内容不充分。
21.在本技术中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显
式地和隐式地理解的是，本技术所描述的实施例在不冲突的情况下，可以与其它实施例相结合。
22.除非另作定义，本技术所涉及的技术术语或者科学术语应当为本技术所属技术领域内具有一般技能的人士所理解的通常意义。本技术所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本技术所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块（单元）的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本技术所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本技术所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本技术所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。
23.本技术体提供的多路音视频直播互动方法，可以应用在如图1所示的应用环境中，图1是根据本技术实施例的多路音视频同步直播方法的应用环境示意图，如图1所示，服务端10采集多路音视频，并分别将每一路音视频封装为多组特定切片文件，并在每个切片文件的索引中，添加音频时间戳和序号。进一步的，终端11通过发送播放请求，从服务端获取各路音视频，并基于索引文件中的音频时间戳，对各路音视频进行校准后实现同步播放。
24.需要说明的是，上述服务端10可以是物理服务器、也可以是分布式的云服务器，终端11包括但不限于是智能手机、平板电脑和笔记本电脑等互联网终端，其可以通过独立的视频播放软件或者网页端实现多路音视频同步直播。
25.本技术提供了一种多路音视频同步直播方法，图2是根据本技术实施例的一种多路音视频同步直播方法的流程图，如图2所示，该流程包括如下步骤：s201，服务端采集多路音视频；其中，该服务端通过无线网络采集多路音视频，该多路音视频可以是在相同时间段内，从不同角度拍摄的同一个对象的视频，例如，不同角度拍摄的同一主播的视频，不同角度拍摄的相同建筑或景观的视频等。
26.进一步的，该服务端可以是分布式文件服务器，其上搭建有cdn网络（content delivery network，内容分发网络，简称cdn），并由分布在不同区域的边缘节点服务器群组成。
27.其中，cdn网络应用广泛，支持多种行业、多种场景内容加速，例如：图片小文件、大文件下载、视音频点播、直播流媒体、全站加速和安全加速等。本实施例中，基于cdn网络实现对多路音视频的存储和管理。
28.s202，分别对各路音视频进行格式转换，生成各路音视频对应的切片文件和索引文件，并提取每个切片文件的音频时间戳和序号，并将其写入在索引文件中；其中，多路音视频可以是多种格式，对其转换得到的文件也可以是基于多种协议的文件，具体的：音视频文件可以是基于rtmp（real time messaging protocol，实时消息传输协
议）的文件，也可以是其他协议的音视频文件；进一步的，可以将音视频文件转换为基于hls协议或dash协议的音视频文件，另外，索引文件包括但不限于是m3u8文件和txt文件等；需说明的是，具体采用的文件协议不同，处理方式也可能存在具体差异，但是，应该理解，采用何种方式将原视频转换得到多个切片流文件和索引文件，由每个索引文件关联到这些切片流文件的方式，都应该属于本技术权利要求的保护范围之内。
29.本实施例中，由于rtmp协议和hls协议是本领域主流的直播协议，且更易于cdn网络分发和具备更好的穿透性，因此，本实施例中，采集的音视频文件优选为rtmp流文件，格式转换优选为将其转换为hls协议的文件，具体举例如下：在服务端将rtmp流音视频转换为hls文件，得到一个m3u(8)的索引文件、多个ts媒体切片文件和key加密串文件，进一步的，将每个ts媒体切片的音频时间戳写入到索引文件中；具体的，每个音视频可以产生多少个ts媒体切片，每个切片的速度和切片中包含的视频视场，由音视频文件的具体参数（如帧率、码率等）所确定，且每个切片都具备一个独立的序号；m3u8文件是指utf-8编码格式的m3u文件，其中录入了一个索引纯文本文件，终端打开它时播放软件并不是播放它，而是根据它的索引找到对应的音视频文件的网络地址进行在线播放；进一步的，本实施例中，在索引文件中额外添加了一层标记信息，即针对与每一路音视频文件，将其封装得到的每个切片文件的音频时间戳和序号添加在该索引文件中，用于后续校准。
30.s203，终端发送播放请求，从服务端获取各路音视频对应的索引文件，根据索引文件中的音频时间戳，分别在每一路音视频中选择一个切片文件作为起始切片，其中，各路音视频选中的起始切片之间，音频时间戳的差值最小；需要说明的是，一个音视频被拆分为多个切片文件，假设每个切片文件的时长大概为2s，各路音视频的索引文件中对应的切片文件，随直播进行而动态变化，但索引中对应的切片文件数量总数则保持不变。
31.如下表1所示：若现有三路音视频参与同步直播，每一路音视频中的切片大小均为2s。若从各路音视频中选择的起始切片依次为：一路（切片
①
）、二路（切片
②
）、三路（切片
⑤
），此时各路的音视频的时间戳刻度分别为1s、3s和7s。
32.若要实现多路通步，则需要把1路和2路的切片快进到第7s，但是，由于网络限制，此时第1路的视频可能还尚未下载
⑤
个切片的数据，那必然无法直接将第一路音视频快进到第5个切片对应的第7s的视频画面，若继续执行快进将导致画面暂停或倒放等异常情况。
33.在本技术实施例中，由于从各路中确定的起始切片根据音频时间戳所确定的，且
选取的各路起始切片之间的差值最小。因此，可以保证不同路中的起始切片的时间差异时钟不会超过一个切片的时长，对应的，后续在同步处理中，就相当于不同路的音视频是限制在同一个切片上进行快进，因此，可以有效的避免上述问题。
34.进一步的，还需说明的是，若按照序号选择起始切片，由于各路视频的具体参数不同，导致生成切片文件的速度和长度都存在差异，在直播进行较长时间之后，由于累计的切片之间的差异，即使同一序号的切片，不同路音视频之间的真实时间刻度也可能存在很大差异，例如第一路音视频中，切片800的时间戳为第1600秒，但是第三路音视频中，同样序号的切片800的时间戳可能已波动至第1610秒；该种情况下，若三路音视频都选择切片800作为起始切片进而执行校准，则仍然不可避免的出现上述由于尚未下载到对应数据，导致快进异常的问题。
35.相比较于传统方式，本实施例中，通过判断各路音视频之间的音频时间戳的差值，来获取起始切片，从而可以避免后续校准过程中，由于尚未下载到后续数据导致校准异常的情况，从而进一步保障了同步过程中的稳定性，提升了同步效果、s204，在各路起始切片的音频时间戳中，选择时间进度最快的一个作为基准时间戳，实时下载索引文件中各路音视频的切片文件，并根据基准时间戳校准各路音视频的切片文件后进行播放。
36.需要说明的是，由于多路视频之间存在帧率、码率、分辨率等多种参数差异，采用常规的时间戳作为同步基准参数时，即使初始画面同步播放，但是随着播放的进行会出现越来越不同步的情况；而本实施例中，将音频时间帧写入在索引文件中，根据直播进度，动态的从当前索引文件中选择合适的起始切片并进一步确定基于音频的同步基准参数，由于音频参数单一，多路音频具有很高的一致性，不会出现随着播放的进行越来越不同步的情况，因此以音频作为基准参数进行同步于校准，对于视频参数不同的多路音视频流的切片文件，仍然能取得良好的同步效果。
37.通过上述步骤s201至s203，相比较于相关技术中的多路音视频同步直播方法，客户端在获取不同路音视频的索引之后，可以根据其中的音频时间戳选择起始切片，进而以起始切片中最快的时间戳为基准实现多路同步。因此，对于视频参数不同的多路音视频流仍然能取得良好的同步效果。
38.而且，相比较于现有技术中将多路音视频合并为一路音视频发送至终端的方法，本技术中，基于切片和索引之间的关系，在保障同步直播的同时，终端仍然可以独立的接收不同路的音视频，因此，可以支持用户独立调整每一路音视频画面的大小、界面位置、画中画等，以满足不同的观看需求，且终端获取的视频仍然可以原画质。
39.在其中一些实施例中，图3是根据本技术实施例中的根据基准时间戳校准个路音视频的切片文件后的流程图，如图3所示，该流程包括如下步骤：s301，将基准时间戳所在的起始切片，对应的一路音视频记为基准路音视频；s302，分别计算其他各路音视频的起始切片文件的音频时间戳，与基准时间戳的差值，得到各路音视频的校准时间差；可以理解，其他各路音视频是除基准路音视频之外的各路音视频；s303，根据校准时间差，首先，校准各路音视频的起始切片，并播放起始切片，其
次，按照切片序号，顺序播放各路音视频的后续切片文件。
40.其中，校准各路音视频其实切片的过程即相当于，将时间戳较慢的一路或几路切片，按照时间戳差值，快进与进度最快的一路音视频相同的播放时间点。
41.如下表2所示：三路音视频中选定的起始切片的时间戳分别为第1s、第1.2s和1.6秒，该种情况下，即将第一路和第二路的画面均快进到第1.6s，实现多路同步。
42.在其中一些实施例中，由于网络波动干扰，多路音视频画面的加载时间也可能不同，加载时间的不同进而也会导致播放的不同步，因此，为了进一步提升同步直播的稳定性，本技术实施例中，在计算各路音视频的校准时间差的过程中，还包括如下步骤：获取各路音视频在终端上的加载时间，计算其他各路音视频的加载时间与基准路音视频的加载时间差值；根据加载时间差值和基准时间戳的差值，得到其他各路音视频的校准时间差；再根据上述校准时间差，校准各路音视频的起始切片。
43.具体的，如下表3所示：音视频线路一二三音频时间戳2.1s2.2s2.3s加载时间0.2s0.5s0.3s结合上述表3，可以看出由于加载时间不同，第一路视频在0.2s之后才能播放第2.1s的画面，第二路视频在0.5s之后才能播放第2.2s的内容，第三路视频在0.3s之后才播放第2.3s的画面。对应的，依次类推，第一路将在0.5s之后播放第2.4s的内容，第三路视视频将在0.5s之后播放第2.5s的内容。 因此，综合考虑音频时间戳差值和加载时间差值之后，确定第三路为基准路音视频，基准时间戳是2.5s，第一路和第二路音视频的校准时间差分别为0.1s和0.3s，对应的，则需要把第一路音视频和第二路音视频分别向前快进0.1s和0.3s至第三路的2.5s，以实现三路同步。
44.在其中一些实施例中，由于多路视频流走等异常情况，在实现同步播放的过程中，仍然可能出现因异常原因干扰导致直播不同步的现象；因此，本实施例中，在播放过程中持续记录各路音视频的播放时间，进而对播放过程进行监控，在检测到某一路或某几路播放画面与其他路不同步时，确定播放最快的一路音视频画面的音频时间戳，并以其为基准时间戳，对其他路画面重新进行校准。
45.具体的，如何进行校准与上述步骤s301至s303中相似，此处不再赘述。
46.在其中一些实施例中，由于本技术中用户终端接收到的仍然是互相独立的多路音视频，因此，可以支持用户对各路音视频进行独立编辑调整，以满足用户的多样化需求，提升用户体验，具体包括：终端接收用户自定义操作指令，根据自定义操作指令，在前端显示界面上，分别对
各路音视频的画面进行编辑处理，其中，自定义操作指令包括但不限于是：画面缩放指令、画面移动指令和画面悬浮指令和画面删减指令等。
47.在其中一些实施例中，多路音视频可以是rtmp流文件，也可以是其他格式的文件，进一步的，可以将多路音视频转换为hls格式，也可以转换为与hls协议相似的dash协议，由于hls协议更能适配于分布式网络，本实施例中，优选应用hls协议。
48.本实施例还提供了一种多路音视频同步直播系统，该系统用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
49.图4是根据本技术实施例的一种多路音视频同步直播系统的结构框图，如图4所示，系统包括：服务端40和终端41，其中；服务端40用于，采集多路音视频，分别对各路音视频进行格式转换，生成各路音视频对应的切片文件和索引文件，并提取每个切片文件音频时间戳和序号并将其写入在索引文件中；终端41用于，发送播放请求，从服务端40获取各路音视频对应的索引文件，根据索引文件中的音频时间戳，分别在每一路音视频中选择一个切片文件作为起始切片，其中，各路音视频选中的起始切片之间，音频时间戳的差值最小，以及，在各路起始切片的音频时间戳中，选择时间进度最快的一个作为基准时间戳，实时下载索引文件中各路音视频的切片文件，并根据基准时间戳校准各路音视频的切片文件后进行播放。
50.在一个实施例中，图5是根据本技术实施例的电子设备的内部结构示意图，如图5所示，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图5所示。该电子设备包括通过内部总线连接的处理器、网络接口、内存储器和非易失性存储器，其中，该非易失性存储器存储有操作系统、计算机程序和数据库。处理器用于提供计算和控制能力，网络接口用于与外部的终端通过网络连接通信，内存储器用于为操作系统和计算机程序的运行提供环境，计算机程序被处理器执行时以实现一种多路音视频同步直播方法，数据库用于存储数据。
51.本领域技术人员可以理解，图5中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
52.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（rom）、可编程rom（prom）、电可编程rom（eprom）、电可擦除可编程rom（eeprom）或闪存。易失性存储器可包括随机存取存储器（ram）或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram（sram）、动态ram（dram）、同步dram（sdram）、双数据率sdram（ddrsdram）、增强型sdram（esdram）、同步链路（synchlink） dram（sldram）、存储器总线（rambus）直接ram
（rdram）、直接存储器总线动态ram（drdram）、以及存储器总线动态ram（rdram）等。
53.本领域的技术人员应该明白，以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
54.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。