一种基于云会议的多媒体处理方法、装置及存储介质与流程

本申请涉及云会议技术领域，具体而言，涉及一种基于云会议的多媒体处理方法、装置及存储介质。

背景技术：

现有的音视频录制采用客户端录制的方法，客户端的音视频录制方法需要将录制的音视频保存在用户终端上然后在录制完成之后，进行上传。在音视频上传完成之后，由上传者通知用户上传地址，用户通过自己的终端设备将音视频完全下载后并进行解压缩才能进行播放，当音视频文件较大时，会造成大量的时间浪费同时消耗带宽。

云会议是基于云计算技术的一种高效、便捷、低成本的会议形式，可在世界各地使用多种终端方式如电话、手机、电脑、专用终端等通过共享音频、视频、终端桌面、文档、白板等进行远程沟通和远程协助。云端音视频的录制指的是在服务器端使用云计算技术对客户端生成的音频和视频数据进行录制然后通过播放器回放。在云会议过程，多个云会议客户端对应一个云端，即云端录制是一个服务器同时录制一场云会议中的多个端同时产生的音频和视频，能够达到实时、快捷的播放视频内容。

在现实情况下，由于云会议的场景复杂，在音视频回放的过程中，可能会出现一些异常的情况，对音视频回放的正确性产生影响。

技术实现要素：

为了解决现有技术中存在的问题，本申请提供了一种基于云会议的多媒体处理方法、装置及存储介质。

为实现上述目的，本申请采用的技术方案为：

本申请第一方面提供一种基于云会议的多媒体处理方法，包括：

根据至少1个所述客户端传输的多媒体流，录制多媒体数据；

获取接收所述多媒体流中多个采样帧的接收时间戳；

根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息；

将所述时间信息写入所述多媒体数据，获取多媒体文件。

可选地，所述根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息，包括：

获取所述采样帧中任意相邻两帧的所述接收时间戳和所述传输时间戳；

根据相邻两帧的所述接收时间戳和所述传输时间戳，分别计算接收时间差、传输时间差；

根据所述接收时间差、所述传输时间差，计算修正时间信息；

根据所述修正时间信息修正所述接收时间戳，获取所述时间信息。

可选地，所述根据所述接收时间差、所述传输时间差，计算所述修正的时间信息，包括：

根据所述接收时间差、所述传输时间差，判断是否存在时间戳反转；

若存在所述时间戳反转，则根据预设算法、以及预设时钟频率，计算所述修正的时间信息。

可选地，所述方法还包括：

接收所述多媒体流的第一帧时，记录所述第一帧的接收时间戳、以及所述第一帧的传输时间戳。

可选地，所述根据所述修正时间信息修正所述接收时间戳，获取所述时间信息之前，还包括：

根据预设映射关系，获取当前帧的所述接收时间戳、与所述第一帧的所述接收时间戳之间的映射时间；

根据所述修正时间信息修正所述接收时间戳，获取所述时间信息，包括：

根据所述修正时间信息、所述映射时间修正所述接收时间戳，获取所述时间信息。

可选地，所述多媒体流为音频流时，根据所述接收时间差、所述传输时间差，判断是否存在时间戳反转之后，还包括：

若时间戳未反转，则根据所述传输时间戳以及预设时钟频率，对所述多媒体流进行补包；

若时间戳反转，则根据所述接收时间戳以及预设时钟频率，对所述多媒体流进行补包。

本申请第二方面提供一种基于云会议的多媒体处理装置，包括：录制模块、获取模块、写入模块；

所述录制模块，用于根据至少1个所述客户端传输的多媒体流，录制多媒体数据；

所述获取模块，用于获取接收所述多媒体流中多个采样帧的接收时间戳；根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息；

所述写入模块，用于将所述时间信息写入所述多媒体数据，获取多媒体文件。

可选地，所述获取模块，用于获取所述采样帧中任意相邻两帧的所述接收时间戳和所述传输时间戳；

根据相邻两帧的所述接收时间戳和所述传输时间戳，分别计算接收时间差、传输时间差；

根据所述接收时间差、所述传输时间差，计算修正时间信息；

根据所述修正时间信息修正所述接收时间戳，获取所述时间信息。

可选地，所述获取模块，用于根据所述接收时间差、所述传输时间差，判断是否存在时间戳反转；

若存在所述时间戳反转，则根据预设算法、以及预设时钟频率，计算所述修正的时间信息。

可选地，所述装置还包括：记录模块；

所述记录模块，用于接收所述多媒体流的第一帧时，记录所述第一帧的接收时间戳、以及所述第一帧的传输时间戳。

可选地，所述获取模块，用于根据预设映射关系，获取当前帧的所述接收时间戳、与所述第一帧的所述接收时间戳之间的映射时间；

根据所述修正时间信息、所述映射时间修正所述接收时间戳，获取所述时间信息。

可选地，所述多媒体流为音频流时，所述装置还包括：补包模块；

所述补包模块，用于若时间戳未反转，则根据所述传输时间戳以及预设时钟频率，对所述多媒体流进行补包；

若时间戳反转，则根据所述接收时间戳以及预设时钟频率，对所述多媒体流进行补包。

本申请第三方面提供一种基于云会议的多媒体处理装置，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当所述装置运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行上述第一方面提供的方法。

本申请第四方面提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面提供的方法。

本申请提供的基于云会议的多媒体处理方法、装置及存储介质中，根据至少1个所述客户端传输的多媒体流，录制多媒体数据；获取接收所述多媒体流中多个采样帧的接收时间戳；根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息；将所述时间信息写入所述多媒体数据，获取多媒体文件。通过采样帧的接收时间戳以及采样帧携带的传输时间戳获取准确的多媒体文件的时间信息，解决了多媒体回放过程中的时间戳异常情况对多媒体回放的影响，提高了多媒体回放的正确率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例提供的一种基于云会议的多媒体处理方法的流程示意图；

图2为本申请另一实施例提供的一种基于云会议的多媒体处理方法的流程示意图；

图3为本申请另一实施例提供的一种基于云会议的多媒体处理方法的流程示意图；

图4为本申请一实施例提供的一种基于云会议的多媒体处理装置示意图；

图5为本申请另一实施例提供的一种基于云会议的多媒体处理装置示意图；

图6为本申请另一实施例提供的一种基于云会议的多媒体处理装置示意图；

图7为本申请一实施例提供的一种基于云会议的多媒体处理装置结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本申请的实施例中的特征可以相互结合。

云会议是基于云计算技术的一种高效、便捷、低成本的会议形式，可在世界各地使用多种终端方式如电话、手机、电脑、专用终端等通过共享音频、视频、终端桌面、文档、白板等进行远程沟通和远程协助。云端音视频的录制指的是在服务器端使用云计算技术对客户端生成的音频和视频数据进行录制然后通过播放器回放。在云会议过程，多个云会议客户端对应一个云端，即云端录制是一个服务器同时录制一场云会议中的多个端同时产生的音频和视频。在复杂的云会议环境下，要保证录制回放的正确性需要设法解决可能导致回放异常的一些特殊场景。

录制的最终结果是生成可播放多媒体文件，多媒体文件可以包括视频和/或音频，如mp4、m3u8、flv等格式的文件。多媒体文件的每一帧播放由这一帧对应的时间信息决定，本申请实施例中，这些多媒体文件的每一帧的显示时机可以通过媒体文件中每一帧数据的显示时间戳pts(presentationtimestamp，简称pts)决定。pts用来“告诉”播放器该在什么时候显示这一帧的数据。一般情况下pts值是编码之后视频文件根据录制时间自己生成的，但在某些情况下，为了满足设计需求，需要对pts值进行修正。

pts是一个时间衡量值，它的单位跟播放它的视频流中时间基相关。时间基是播放程序ffmpeg(fastforwardmpeg，简称ffmpeg)中的一个时间衡量单位，用time_base表示，如time_base＝{1，90000}，表示把一秒钟分成90000等份，每一份是1/90000秒。一般播放的流媒体中流默认的时间基就是time_base＝{1，90000}，pts和时间基一起作用才能用来表达通常的时间值。时间的衡量是有起点的，在客户端时间基跟采样频率(预设时钟频率)相关，pts的值以一个随机值为起点，然后以时间基为单元逐渐递增。如time_base＝{1，90000}，pts起始值为161979300，当前值为162069300，则表示的当前时间为(162069300-161979300)/90000＝1秒。

音视频录制过程中容易出现pts错误导致回放不正确，可能由于以下因素导致：1、音视频文件的pts未从0开始；2、视频文件的时间戳反转和时间戳重置；3、音频文件补包不正确；4、音视频文件的pts多段衔接不正确。

本申请实施例提供一种基于云会议的多媒体处理方法，用于解决上述技术问题。图1为本申请一实施例提供的一种基于云会议的多媒体处理方法的流程示意图。该方法的执行主体可以是云会议系统中的云端服务器，如图1所示，该方法包括：

s101、根据至少1个所述客户端传输的多媒体流，录制多媒体数据。

在本申请实施例中，多媒体数据可以包括视频和/或音频。云会议过程中，多个客户端对应一个云端，本申请实施例中，根据至少1个客户端传输的多媒体流，录制多媒体数据，即云端录制可以是云端服务器同时录制一场云会议中的多个端同时产生的音频和/或视频。

一般多媒体数据的录制需要解码后编码，在编码的时候pts会自动生成，这样就不需要对pts进行额外的处理。本申请实施例的云端录制视频，录的是不需要再进行解码、编码的多媒体流，例如h264流，所以需要在封装多媒体数据包的时候设置pts值。

最简单的pts设置方法就是把多媒体数据包中的时间戳设置为pts值，例如，h264包的时间戳是从客户端传过来的，是每个h264包根据采样时钟在采样时刻设置进去的，能正确标识该帧显示的时间。需要说明的是，本申请实施例中，封装多媒体数据包时设置的pts值也可以称为采样帧携带的传输时间戳。

s102、获取接收所述多媒体流中多个采样帧的接收时间戳。

在本申请实施例中，云端服务器接收到一帧一帧的多媒体数据，根据预设规则采样获取其中的采样帧，该采样帧携带有传输时间戳。另外，云端服务器还会记录接收到该采样帧的时间，记为接收时间戳。

s103、根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息。

需要说明的是，在本申请实施例中，采样帧携带的传输时间戳是由客户端传输时记录的，采样帧的接收时间戳是由云端服务器在接收时记录的，采样帧携带的传输时间戳和采样帧的接收时间戳属于不同的两个时间序列。根据两个时间序列可以计算获取准确的时间信息，进而记录每一帧对应的时间信息。

s104、将所述时间信息写入所述多媒体数据，获取多媒体文件。

在本实施例中，将时间信息写入多媒体数据，最终获取得到多媒体文件。

本申请提供的基于云会议的多媒体处理方法，根据至少1个所述客户端传输的多媒体流，录制多媒体数据；获取接收所述多媒体流中多个采样帧的接收时间戳；根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息；将所述时间信息写入所述多媒体数据，获取多媒体文件。通过采样帧的接收时间戳以及采样帧携带的传输时间戳获取准确的多媒体文件的时间信息，解决了云会议多媒体回放过程中的时间戳异常情况对多媒体回放的影响，提高了多媒体回放的正确率。

其中，传输时间戳和采样帧的接收时间戳属于不同的两个时间序列，为了避免由于时间序列不同，导致多媒体文件的播放异常，可以利用接收时间戳以及采样帧携带的传输时间戳对采样帧的时间序列进行修正，最终获取得到正确的时间信息。

图2为本申请另一实施例提供的一种基于云会议的多媒体处理方法的流程示意图。如图2所示，在本申请一些实施例中，步骤s103、根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息，包括：

s1031、获取所述采样帧中任意相邻两帧的所述接收时间戳和所述传输时间戳。

在本申请实施例中，云端服务器获取每一帧从客户端传输的多媒体流，可以是获取多媒体流中相邻两帧的接收时间戳和传输时间戳。由于云端服务器和客户端所使用的时间序列不同，因此相邻两帧的接收时间戳和传输时间戳存在差异。

s1032、根据相邻两帧的所述接收时间戳和所述传输时间戳，分别计算接收时间差、传输时间差。

云端服务器分别对获取的多媒体流中相邻两帧的接收时间戳和传输时间戳作差，即用上一帧的接收时间戳减去下一帧的接收时间戳，获取接收时间差，上一帧的传输时间戳减去下一帧的传输时间戳，获取传输时间差。

可以理解的是，在本实施例中传输时间戳和接收时间戳分别是由客户端和云端服务器的时间序列记录的，可能存在差异。但是即使时间序列存在差异，相邻两帧之间的时间差包括接收时间差以及传输时间差应该是一致的。

相邻两帧之间的传输时间差dt的单位为采样时钟的单位，视频采样频率为90000，即每1/90000秒采样一个数据，相邻两帧之间的接收时间差du以毫秒为单位，所以需要把dt转换为毫秒，即用dt除以90得到毫秒值，这样dt和du的单位都是毫秒。

因此，在完全理想情况下，相邻两帧之间的传输时间差dt和相邻两帧之间的接收时间差du是相等的，客户端发送两帧数据f1和f2的时间差和云端服务器接收f1和f2的时间差是相等的。如果du等于dt，则完全可以用du代替dt来设置pts，但是在实际复杂的网络环境中，多媒体流数据可能因为网络拥塞堵塞而丢失或者延迟，这些都是不可预知的，所以du不能代替dt。

s1033、根据所述接收时间差、所述传输时间差，计算修正时间信息。

由于du和dt可能会存在一些细小的差异，在本申请实施例中，使用接收时间差du以及传输时间差dt对时间信息进行修正。示例性地，在本实施例中，相对于数据帧时间戳反转和重置情况，du的变化是很小的，利用接收时间差、传输时间差结合作为时间戳反转和重置情况的判断条件。

将时间戳反转和重置的传输时间戳进行时间修正，得到修正时间信息。

s1034、根据所述修正时间信息修正所述接收时间戳，获取所述时间信息。

需要说明的是，传输时间戳以及接收时间戳都可以用来决定多媒体文件的播放顺序。在本实施例中，利用修正时间信息修正接收时间戳，获取得到正确的时间信息。

需要说明的是，在本申请实施例中，该时间信息可以是修正后的pts时间序列。具体可以是将接收时间戳修正后的pts时间序列重新写入各帧携带的传输时间戳，从而获取具有准确时间信息的多媒体文件。

图3为本申请另一实施例提供的一种基于云会议的多媒体处理方法的流程示意图。如图3所示，在本申请一些实现方式中，步骤s1033、所述根据所述接收时间差、所述传输时间差，计算所述修正的时间信息，包括：

s301、根据所述接收时间差、所述传输时间差，判断是否存在时间戳反转。

在本申请实施例中，时间戳反转具体为，网络传输中的实时数据包(real-timeprocess，简称rtp)的时间戳的字段可以是32位的无符号整形值，这个字段最大值是4294967295，超出之后时间戳会反转从溢出值开始。示例性地，当max＝4294967295，时间戳pts＝max+1时，pts的值发生溢出，pts的值变为0。这种场景，在当视频开启的时间比较长的情况下是特别容易出现的。

客户端在采样视频数据的时候，采样时钟是规律的不断往前走，时间戳是不断往上递增的。但是在某些异常情况下，如客户端崩溃拉起，这会导致采样被重置，从而使时间戳变成了新的时间系列，这样时钟重置导致产生的新的时间戳就不能同重置前的时间戳进行计算。重置后的采样时间戳是从一个随机数重新开始的，所以在云端服务器侧也没直观的条件去判断是否发生了重置。

需要说明的是，在本申请实施中，时间戳反转和时间戳重置的处理方式相同。

接收时间差du、以及传输时间差du在完全理想的情况下，二者是相等的。而在实际复杂的网络环境中，数据可能因为网络拥塞堵塞而丢失或者延迟，因此du不能代替dt。但相对于数据帧时间戳反转和重置情况，du的变化是很小的。示例性地，如果业务需求能容忍的延迟是5秒，即du和dt即使不相等，但允许的最大误差为5秒也就是5000毫秒，设最大误差mt(maxtime)为5000，则可以认为du-dt的绝对值是不可能大于mt的，一旦大于mt则认为时间戳发生了反转或者已被重置。即时间戳发生了反转或者已被重置的判断条件为|du-dt|>mt。

需要说明的是，本申请实施例中最大误差mt的值可以根据业务需求来进行设定，本实施例对此不做限制。

s302、若存在所述时间戳反转，则根据预设算法、以及预设时钟频率，计算所述修正的时间信息。

当判断时间戳发生了反转或者已被重置之后，后面的时间戳系列是一个新的系列，对于一个新的时间戳系列，需要将其与前一个时间戳系列接续起来。在本申请实施例中，当判断时间戳发生反转或者重置后，将时间戳发生反转或者重置前，最后一个采样帧携带的传输时间戳记为lt。正常情况下对于时钟频率为90000的数据，两个连续帧的时间戳差值为90000，lt的下一个时间戳应该是lt+90000，所以对新的时间戳系列使用，t‘＝tn‘-t1‘的映射公式得到映射到以0为起始的时间戳的值之后，用于设置pts的时间戳，即修正的时间信息ct可以是：ct＝lt+90000+t。修正后得到的pts就是对时间戳反转和时间戳重置修正之后的正确结果。

需要说明的是，在本申请实施例中，t1‘表示时间戳反转之后，云端服务器接收到第一个采样帧的接收时间戳，tn‘可以表示时间戳反转之后，云端服务器接收到第n个采样帧的接收时间戳。

时钟频率并不是固定的，可以根据业务需求进行适当地调整。在本实施例中，将时钟频率表示为ft，则修正的时间信息ct＝lt+ft+t‘，这样得到的修正的时间信息ct就是对时间戳反转和时间戳重置修正之后的正确结果。

可选地，在上述实施例的基础上，为了解决多媒体数据从0开始的问题，该方法还包括：接收所述多媒体流的第一帧时，记录所述第一帧的接收时间戳、以及所述第一帧的传输时间戳。

需要说明的是，在本申请实施例中，客户端所传输的采样帧数据并不是从0开始的时间戳序列，因此采样帧携带的传输时间戳也并不是从0开始。为了使采样帧的时间序列从0开始，需要记录第一帧的接收时间戳、以及第一帧的传输时间戳，以进行时间戳的映射。

可选地，所述根据所述修正时间信息修正所述接收时间戳，获取所述时间信息之前，还包括：

根据预设映射关系，获取当前帧的接收时间戳、与第一帧的接收时间戳之间的映射时间；根据修正时间信息修正接收时间戳，获取时间信息，包括：根据修正时间信息、映射时间修正接收时间戳，获取时间信息。

需要说明的是，在本申请实施例中，记第一个采样帧的时间戳(采样帧携带的传输时间戳)为p1，建立线性映射关系p＝pn-p1，pn为云端服务器每次收到对应采样帧的时间戳，p为转换到以0起始的时间戳。这样计算之后的p，不仅可以用于修正mp4的时间信息，同样可以用于设置其他如m3u8、flv等可播放媒体文件格式的时间信息。

在本申请实施例中，对于多段视频的衔接问题，其处理方式和时间戳发生反转或者重置的处理方式相同。

多段视频的衔接，即多段录制指的是在录制的过程中，允许用户暂停录制，即在客户端设置开启录制和暂停录制的按钮，当用户想录制时则开启录制，此时录制服务器和客户端同时接收采样帧数据，当用户暂停录制时，客户端继续接收采样帧数据，但录制服务器不再接收采样帧数据，只有等用户再开启录制时，服务器和当前的客户端同步接收数据，即暂停录制时段的数据对云端服务器是被过滤掉的。这种情况下对于云端服务器来说，采样帧数据因为数据的断裂让时间戳发生了跳变，如果暂停之后继续录制的情况下不对时间戳进行调整，则录制下来的视频在播放的时候暂停的这一段数据是空白的，播放效果可能是黑屏也可能是停在上一帧不动。如果暂停的时间很长，那只能在毫无意义的情况下增加录制文件的大小、占用云端服务器的资源。所以对于暂停录制的这一段应该去掉，暂停后重新开启录制的这一段需同前一段拼接起来形成一个完整的有内容的视频，这个就是采样帧时间戳的拼接。

在本实施例中，将多段录制造成的时间戳跳变当作时钟被重置来处理，即没段录制开始的第一帧都可以当作新的第一帧来处理，相应地，多段录制导致时间跳变的处理算法也是ct＝lt+ft+t‘。

可选地，在本申请一些实现方式中，当所述多媒体流为音频流时，根据所述接收时间差、所述传输时间差，判断是否存在时间戳反转之后，还包括：

若时间戳未反转，则根据所述传输时间戳以及预设时钟频率，对所述多媒体流进行补包；若时间戳反转，则根据所述接收时间戳以及预设时钟频率，对所述多媒体流进行补包。

对于多媒体数据，视频出现的时间戳错误，具体可以是pts错误一样，音频也会出现，但它们的处理方法有所区别。在云会议的音频录制过程中，音频需要编解码，所以音频的pts由编码器产生，但编码器产生的pts来源于编码前的音频数据帧avframe的值，avframe是ffmpeg的一个帧结构，里面决定pts的关键数据是一帧音频的样本数nb_samples和采样率(时钟频率)sample_rate。在采样率固定的情况下，样本数按比例等价于时间。示例性地，采样率8k的自适应多速率编解码(adaptivemulti-ratecodec，简称amr)，40毫秒的数据就是320个样本，即8k采样率的情况下，320个样本等价于40毫秒的时间。把320个8k的amr样本转码成8k的aac音频编码，那同等采样率下320个样本即使变成了aac编码的数据了但依然是40ms，只是aac编码一帧是1024个样本即1024/8毫秒，所以在时间基为90000的情况下编码之后的pts＝90000*(1024/8000)＝11520，如果编码器设置时间基为8000，则pts就是样本的个数。

所以要保证音频pts计算准确，只需保证样本个数准确。在网络传输过程中，如果因为网络环境问题导致丢包使样本个数减少，如果不采取措施的话，音频总时间会减小。在云会议回放过程中，以音频为整场录制回放的时间轴，所以音频样本个数的增多和减少都是至关重要的。要保证音频时间的准确，需要解决音频补包的准确性问题。所以同视频一样需要解决音频数据包时间反转、时钟重置、多段录制的时间跳变的问题。

音频的pts由样本数决定，音频的样本数受补包数的支配，音频补包的多少依赖于相邻两个包之间的传输时间差dt和服务器接收到数据包的接收时间差du。

同视频一样，音频数据中时间戳的反转和时间戳的重置的判断条件满足|du-dt|>mt，和视频不一样的是当满足条件|du-dt|>mt时，音频是要进行补包处理。当|du-dt|>mt时，采样时间戳和之前的时间戳系列已不属于同一个系列，不能再使用采样时间戳来进行计算，应以服务器接收数据帧的时间来暂时替代。ft为预设时钟频率，即ft为固定采样音频数据帧的时间，因为音频需要多流合流混音，而合流混音是每ft毫秒的时间合一次然后输出，对于云端服务器来说可以认为每ft毫秒时间应该能接收到一个音频包，如果ft＝40毫秒，则可以认为一个包在时间上代表40毫秒，录制的音频文件要想在播放时还原整个录制现场，必须时间长度上等同于录制现场的时间，并且音频时间轴上排布的包要同现场实时采样时的包在同一个时间轴上对齐，所以录制的时候音频的时间轴上有包排包，没包补包。

需要说明的是，在本申请实施例中，当时间戳未反转时，则根据传输时间戳以及预设时钟频率，对多媒体流进行补包。

示例性地，由于客户端的预设时钟频率固定，因此客户端在固定的时间点会采集得到一个采样帧，可以是40ms、80ms、120ms、160ms…，得到一个采样帧，当客户端在40ms得到一个采样帧后，下一个得到采样帧的时间为120ms时，则需要在40ms-160ms之间进行补包。需要说明的是，本申请实施中，所补的数据包具体可以是静默音频数据包。

当时间戳未反转时，所补充的数据包的个数fc＝dt/ft。需要说明的是，dt表示连续两个采样帧传输时间戳的差值，示例性地，若客户端应该每40ms得到一个采样帧，当某种情况下，得到的采样帧的时间为40ms、120ms时，则dt＝120ms-40ms，ft为预设时钟频率。

当时间戳反转时，即|du-dt|>mt时，则根据接收时间戳以及预设时钟频率，对多媒体流进行补包。具体表示为：补包个数fc＝du/ft。

其中，du为云端服务器接收到连续两个数据帧的差值，即接收时间戳的差值。

同视频一样，音频也要考虑多段录制的pts衔接问题。音频的pts衔接主要是断裂处如何补包的问题。新一段音频录制开启的时候，无论有没有音频包，音频都算是已经开始了，此时云端服务器记录开启录制的时间为lu，而此时可能没有音频的采样帧传输过来，所以没有lt。等新一段录制的第一个音频的采样帧进入云端服务器，记其采样帧的接收时间为cu，则音频数据要完成pts衔接，需要补充的数据包个数为：fc＝(cu-lu)/ft。

可以理解的是，本申请实施例提供的基于云会议的多媒体处理方法，通过对音频数据帧的补包操作，以及对音视频数据帧的时间戳反转以及重置后的时间戳修正操作，解决了云会议多媒体回放过程中的时间戳异常情况对多媒体回放的影响，提高了多媒体回放的正确率。

本申请实施例提供一种基于云会议的多媒体处理装置，用于执行前述一种基于云会议的多媒体处理方法。图4为本申请实施例提供的基于云会议的多媒体处理装置示意图，如图4所示，该基于云会议的多媒体处理装置，包括：录制模块401、获取模块402、写入模块403。

所述录制模块401，用于根据至少1个所述客户端传输的多媒体流，录制多媒体数据。

所述获取模块402，用于获取接收所述多媒体流中多个采样帧的接收时间戳；根据所述接收时间戳、以及所述采样帧携带的传输时间戳，获取时间信息。

所述写入模块403，用于将所述时间信息写入所述多媒体数据，获取多媒体文件。

可选地，所述获取模块402，用于获取所述采样帧中任意相邻两帧的所述接收时间戳和所述传输时间戳；根据相邻两帧的所述接收时间戳和所述传输时间戳，分别计算接收时间差、传输时间差；根据所述接收时间差、所述传输时间差，计算修正时间信息；根据所述修正时间信息修正所述接收时间戳，获取所述时间信息。

可选地，所述获取模块402，用于根据所述接收时间差、所述传输时间差，判断是否存在时间戳反转；若存在所述时间戳反转，则根据预设算法、以及预设时钟频率，计算所述修正的时间信息。

图5为本申请另一实施例提供的基于云会议的多媒体处理装置示意图，如图5所示，该装置还包括：记录模块404；

所述记录模块404，用于接收所述多媒体流的第一帧时，记录所述第一帧的接收时间戳、以及所述第一帧的传输时间戳。

可选地，所述获取模块402，用于根据预设映射关系，获取当前帧的所述接收时间戳、与所述第一帧的所述接收时间戳之间的映射时间；根据所述修正时间信息、所述映射时间修正所述接收时间戳，获取所述时间信息。

图6为本申请另一实施例提供的基于云会议的多媒体处理装置示意图，如图6所示，该装置还包括：补包模块405；

所述补包模块405，用于若时间戳未反转，则根据所述传输时间戳以及预设时钟频率，对所述多媒体流进行补包；若时间戳反转，则根据所述接收时间戳以及预设时钟频率，对所述多媒体流进行补包。

图7为本申请实施例提供的基于云会议的多媒体处理装置的结构示意图，对应于一种基于云会议的多媒体处理方法；该基于云会议的多媒体处理装置可以包括：处理器710、存储介质720和总线730，存储介质720存储有处理器710可执行的机器可读指令，当电子设备运行时，处理器710与存储介质720之间通过总线730通信，处理器710执行机器可读指令，以执行上述方法实施例的步骤。具体实现方式和技术效果类似，这里不再赘述。

本申请实施例提供了一种存储介质，该存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述方法。

上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。