CN117294805A - 一种视频会议云录制的方法、装置、电子设备和存储介质 - Google Patents

一种视频会议云录制的方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
CN117294805A
CN117294805A CN202311393120.8A CN202311393120A CN117294805A CN 117294805 A CN117294805 A CN 117294805A CN 202311393120 A CN202311393120 A CN 202311393120A CN 117294805 A CN117294805 A CN 117294805A
Authority
CN
China
Prior art keywords
data
media
video
conference
frame
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311393120.8A
Other languages
English (en)
Inventor
丛俊锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Haoxin Cloud Beijing Network Communication Co ltd
Original Assignee
Haoxin Cloud Beijing Network Communication Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Haoxin Cloud Beijing Network Communication Co ltd filed Critical Haoxin Cloud Beijing Network Communication Co ltd
Priority to CN202311393120.8A priority Critical patent/CN117294805A/zh
Publication of CN117294805A publication Critical patent/CN117294805A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/91Television signal processing therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请实施例提供一种视频会议云录制的方法、装置、电子设备和存储介质,该方法包括获取实时传输协议RTP数据包,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据;解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件;保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。本申请实施例的方法能够节省存储空间且相对较少占用计算资源。

Description

一种视频会议云录制的方法、装置、电子设备和存储介质
技术领域
本申请涉及通信领域,具体而言,涉及一种视频会议云录制的方法、装置、电子设备和存储介质。
背景技术
随着通信技术的发展,视频会议成为人们日常生活和工作中非常重要的一种沟通方式。云录制是对视频会议内容进行录制并保存到云端,以便参会人员可以在会议过后回放会议内容。与云录制相对应的是本地录制,云录制保存在云端,本地录制则保存在电脑本地,与本地录制相比,由于云录制具有保存方便,不会占用设备的存储空间,可随时查看等优点,云录制在视频会议中成为非常重要的功能。
然而,现有方案中,云录制会存在占用大量云端存储空间或需要较高的计算资源的问题。
因此,如何提供一种能够节省存储空间且相对较少占用计算资源的云录制方法,成为亟待解决的问题。
发明内容
本申请的一个实施例的目的在于提供一种视频会议云录制的方法、装置、电子设备和存储介质,通过本申请的实施例的技术方案可以节省存储空间且相对较少占用计算资源。
第一方面,本申请实施例提供了一种频会议云录制的方法,包括:获取实时传输协议RTP数据包,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,其中一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据;解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据,其中,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件;保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。
由于本申请实施例在云录制服务阶段会对RTP数据进行解析恢复成媒体编码数据,由于媒体编码数据的数据量小于RTP数据包,因此,本申请实施例能够降低存储空间,且由于在云录制服务阶段对RTP数据包进行解析而无需对媒体编码数据进行解码,由于解析相对解码会占用较小计算资源,因此,本申请实施例能够在节省存储空间的同时且相对较少占用计算资源。
在一种实施方式中, 在生成和保存与所述媒体编码数据对应的控制文件之前,所述方法还包括:将所述RTP数据包的时间戳进行转换与时间轴对齐,得到所述媒体编码数据的时间戳信息。
在一种实施方式中,在保存所述至少一个会议终端的媒体编码数据之前,所述方法还包括:确定所述媒体编码数据有效。
在一种实施方式中,所述方法还包括:根据控制文件中的时间戳信息按照时间顺序整理所述媒体编码数据;根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件。
在一种实施方式中,所述媒体编码数据包括视频媒体文件,所述云录制文件包括视频文件,所述根据控制文件中的时间戳信息按照时间顺序整理所述媒体编码数据,包括:根据所述控制文件中的时间戳信息,对所述控制文件中的视频媒体文件进行补帧处理,得到补帧后的视频帧数据描述信息;所述根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件,包括:根据所述补帧后的视频帧数据描述信息的时间戳信息,将相同时间戳信息的视频帧作为同一分组进行转码服务,得到转码后的视频文件。
在一种实施方式中,所述媒体编码数据包括音频媒体文件,所述云录制文件包括音频文件,所述根据控制文件中的时间戳信息按照时间顺序整理所述媒体编码数据,包括:根据所述控制文件中的时间戳信息,按照预设时间间隔对所述控制文件中的音频媒体文件进行补帧处理,得到补帧后的音频帧数据描述信息;所述根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件,包括:根据所述补帧后的音频帧数据描述信息的时间戳信息,将相同时间戳信息的音频帧作为同一分组进行转码处理,得到转码后的音频文件。
在一种实施方式中,所述控制文件包括会议头部信息字段和数据结构字段,其中所述会议头部信息字段包括会议属性信息,所述会议属性信息包括所述媒体编码数据的起始地址信息;所述数据结构字段包括所述媒体编码数据的属性信息,所述媒体编码数据的属性信息包括时间戳信息和存储地址信息。
第二方面,本申请的一个实施例提供了一种视频会议云录制的装置,包括:获取单元,用于获取实时传输协议RTP数据包,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,其中一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据;解析单元,用于解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据,其中,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件;保存单元,用于保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。
在一种实施方式中,所述保存单元还用于在生成和保存与所述媒体编码数据对应的控制文件之前,将所述RTP数据包的时间戳进行转换与时间轴对齐,得到所述媒体编码数据的时间戳信息。
在一种实施方式中,在保存所述至少一个会议终端的媒体编码数据之前,所述保存单元还用于确定所述媒体编码数据有效。
在一种实施方式中,所述装置还包括:转码单元,用于根据控制文件的时间戳信息按照时间顺序整理所述媒体编码数据;根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件。
在一种实施方式中,所述媒体编码数据包括视频媒体文件,所述转码单元具体用于根据所述控制文件中的时间戳信息,对所述控制文件中的视频媒体文件进行补帧处理,得到补帧后的视频帧数据描述信息;根据所述补帧后的视频帧数据描述信息的时间戳信息,将相同时间戳信息的视频帧作为同一分组进行转码服务,得到转码后的视频文件。
在一种实施方式中,所述转码单元具体用于根据所述时间戳信息,将同一会议画面中的多路视频帧补帧为统一帧率,得到所述补帧后的视频帧队列。
在一种实施方式中,所述媒体编码数据包括音频媒体文件,所述转码单元具体用于根据所述控制文件中的时间戳信息,按照预设时间间隔对所述控制文件中的音频媒体文件进行补帧处理,得到补帧后的音频帧数据描述信息;根据所述补帧后的音频帧数据描述信息的时间戳信息,将相同时间戳信息的音频帧作为同一分组进行转码处理,得到转码后的音频文件。
在一种实施方式中,所述控制文件包括会议头部信息字段和数据结构字段,其中所述会议头部信息字段包括会议属性信息,所述会议属性信息包括所述媒体编码数据的起始地址信息;所述数据结构字段包括所述媒体编码数据的属性信息,所述媒体编码数据的属性信息包括时间戳信息和存储地址信息。
第三方面,本申请的一个实施例提供一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时可实现如第一方面及第一方面的任一实施方式所述的方法。
第四方面,本申请的一个实施例提供一种电子设备,包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序,其中,所述处理器执行所述程序时可实现如第一方面及第一方面的任一实施方式所述的方法。
第五方面,本申请的一个实施例提供一种计算机程序产品,所述的计算机程序产品包括计算机程序,其中,所述的计算机程序被处理器执行时可实现如第一方面及第一方面的任一实施方式所述的方法。
附图说明
为了更清楚地说明本申请的一个实施例的技术方案,下面将对本申请的一个实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1为本申请的一个实施例提供的视频会议录制系统示意图;
图2为本申请的一个实施例提供的非实时云录制方案整体流程图;
图3为本申请的一个实施例提供的视频会议云录制的方法流程图;
图4为本申请的一个实施例提供的云录制服务的过程示意图;
图5为本申请的一个实施例提供的一种流文件排序示意图;
图6为本申请的一个实施例提供的转码服务的过程示意图;
图7为本申请的一个实施例提供的视频会议云录制的装置示意图;
图8为本申请的一个实施例提供的一种电子设备示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。
如图1所示,图1为本申请的一个实施例提供的视频会议录制系统示意图,如图1所示的系统包括:媒体服务器和云录制服务器。
媒体服务器可以为网页实时通信(Web Real-Time Communications,WebRTC)架构下的多点会议单元(Multipoint Conferencing Unit,MCU)或选择性转发单元(SelectiveForwarding Unit,SFU),媒体服务器用于将参与视频会议的会议终端产生的媒体流发送至云录制服务器,云录制服务器用于对接收到的媒体流进行录制。
应理解,本申请实施例中的会议终端也可以称为客户端或者用户端或者用户设备或者终端设备,本申请实时例中,会议终端可以安装有浏览器,可以通过浏览器进行实时通信,或者安装有APP或者小程序,通过APP或者小程序进行实时会议通信。本申请中终端设备可以包括智能手机、平板电脑、(personal digital assistant,PDA个人数字助理)、计算机、游戏机、可穿戴设备、平板电脑(portable android device, PAD)等,本申请实施例并不限于此。
应理解,本申请实施例中的会议终端上运行的操作系统可以是移动版的安卓(Android)、乌班图(Ubuntu)移动版、泰泽(Tizen)等基于Linux内核的操作系统以及Windows、Mac OS、Linux等桌面操作系统,但本发明并不限于此。
云录制可以分为实时录制和非实时录制两种方式,以非实时云录制方案为例,非实时云录制方案整体流程参见图2,如图2所示。媒体服务器将媒体流(即RTP数据包)发送至云录制服务器,云录制服务器接收到RTP数据包后进行两个服务,云录制服务和转码服务,云录制服务负责录制保存接收到的媒体流数据,即保存数据文件到文件存储,转码服务负责将保存的媒体流数据进行解码、编辑、混合降噪等处理后再进行编码到视频文件和/或音频文件,具体而言,转码服务通过读取媒体数据文件并对读取的文件进行转码之后保存转码后的视频文件和/或音频文件到文件存储。
现有方案中,非实时录制主要有三种方案,以下对现有的三种非实时录制进行详细说明。
方案一:对接收的媒体流直接保存RTP数据包。方案一的优点是消耗CPU和内存资源较少,几乎不用处理直接保存RTP数据包即可,缺点是存储文件相对较大,对网络质量要求很高,同时因不对RTP包进行解析和组装成媒体数据包进行校验,无法确定接收到的RTP数据包解析和组装成媒体数据包送入媒体解码器是否有效,后期转码时无效RTP数据包组装成媒体压缩数据包将无法解码,这样会造成视频丢失且无法恢复。
方案二:对接收的媒体流RTP数据包组装成媒体数据包并进行媒体解码,将解码后的媒体流数据进行保存。方案二的优点是转码时无需再进行媒体解码,可直接进行媒体数据的编辑、混合、降噪等处理,缺点是录制时进行解码会增加CPU和内存资源消耗,保存数据文件占用存储空间大,即方案二虽然降低了存储空间但是需要较高的计算资源。
方案三:与方案二方法相似,但会将媒体流转换成另外一种媒体编码再进行保存。方案三的优点是占用硬盘空间小,保存的媒体数据有效性高,缺点是录制时进行解码和再编码会增加CPU和内存资源消耗,即方案二虽然降低了存储空间但是需要较高的计算资源。
可见,现有方案中,云录制会存在占用大量云端存储空间或需要较多的计算资源,无法达到降低存储空间且相对较少占用计算资源的问题。
因此,如何提供一种能够节省存储空间且相对较少占用计算资源的云录制方法,成为亟待解决的问题。
鉴于以上问题,本申请提供一种视频会议云录制的方法,能够节省存储空间且相对较少占用计算资源。
以下,为了便于理解和说明,作为示例而非限定,以将本申请的实时通信的方法在实时通信系统中的执行过程和动作进行说明。
下面结合附图3示例性阐述本申请的一个实施例提供的视频会议云录制的方法。
应理解,本申请的方法虽然叫做视频会议云录制的方法,但是实际应用中云录制的媒体流中可以仅有音频数据,也可能仅有视频数据,也可能既有音频又有视频数据,本申请实施例并不对此做限定。
应理解,本申请实施例所示的方法可以应用于非实时云录制的场景中,也可以应用于实时云录制的场景中,区别在于,非实时云录制时云录制服务和转码服务可以断开执行,即在云录制服务与转码服务可以连续。实时云录制情况下,云录制服务和转码服务是连续的,即执行完云录制服务后就继续执行转码服务。下文仅以非实时云录制的例子为例进行说明,实时云录制的方案可以参照非实时云录制的情况。
如图3所示的方法应用于如图1所示的视频会议录制系统中,图3所示的方法可以由云录制服务器执行,云录制服务器进行视频会议录制时主要包括两个过程即云录制服务和转码服务。其中,针对实时录制和非实时录制,云录制服务和转码服务云均可以是由云录制服务器执行的;可替代的,针对非实时录制云录制服务可以由录制服务器执行,转码服务也可以由其他设备执行,本申请实施例并不对此做限定。下文仅以非实时录制为例描述本申请实时例的视频会议云录制的方法,针对实时录制而言,可以参照非实时录制的方案,将非实时录制的两个服务过程即云录制服务和转码服务连续执行即可,本申请不再对实时录制的过程赘述。
如图3所示的方法包括:
310,获取实时传输协议RTP数据包。
其中,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,其中一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据。
具体而言,一个会议终端可以对应参与会议的一个用户或者多个用户(该多个用户通过该一个会议终端参与视频会议)。一个会议中的数据流数据可以仅包括音频数据流,也可以仅包括视频流数据,也可以既包括音频流也包括视频流数据,具体的一个会议终端的数量流数据包括的数据可以根据云录制服务器的订阅情况来定(例如,仅订阅音频数据流或者仅订阅视频数据流或者音频和视频流都订阅)或者根据该一个会议终端的硬件设备(例如,是否包括摄像头或麦克风)以及使用该会议终端的用户的操作(例如,是否开启麦或者摄像头等)来确定,本申请实施例并不限于此。
可选的,RTP数据包包括的数据流可以仅包括参与会议的多个会议终端中的部分会议终端的数据流。例如,在演讲者模式下,可以仅包括演讲者的数据流;在画廊模式下,可以仅包括一屏的画面,例如,一屏画面显示有9、16、25或36个用户的画面,在实际云录制时,可以根据实际参会人员的多少以及一个画面的用户显示数量来确定RTP数据包中包括具体哪些会议终端的数据流。其中,在画廊模式下,录制的多个会议终端的属性可以按照预设规则设置或者更换,例如,可以仅录制一个画面人员数量个用户终端的数据流,具体的录制的这个画面的用户可以为位于用户列表中靠前的用户。具体的用户列表的排序可以根据用户的加入时间或者用户的权限或者用户的等级(例如是否为焦点用户,在用户为焦点用户时,不管焦点用户是否发言,焦点用户可以一直位于录制的画面中)或者用户是否发言等等情况调整,本申请实施例并不对此做限定。
还应理解,本申请实施例中,云录制服务器可以是基于默认设置在会议开始时直接录制的,也可以是基于有权限的用户,例如,主持人或者主讲人的请求来录制的。云录制可以是在上述有权限的用户请求后停止,也可以是在会议结束时停止录制,本申请实施例并不限于此。
转码后,云录制服务器可以将该录制的会议发送给媒体服务器,用户可以通过会议终端向媒体服务器请求查看录制的视频会议。同时用户也可以再用户中心中查看、收藏或者删除该云录制会议。
320,解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据。
其中,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件。
具体而言,云录制服务器录制视频会议时,对RTP数据进行解析,恢复成媒体编码数据。
例如,对RTP数据解析包括将接收到的多个数据包进行处理,将同一数据流中相同时间戳的数据包的包头去掉并进行合并,例如,同一数据流中针对一帧画面,RTP数据中包括多个小包,本申请可以将同一帧画面中的多个小包进行合并,合并成一个视频帧数据包。应理解,本申请实施例中传输的RTP数据包的编码形式不限定,可以是VP9、VP8、H264、H265等协议的编码数据,本申请实施例并不限于此。
由于本申请实施例通过对RTP数据进行解析后恢复成的媒体编码数据由于去掉了包头,所以本申请实施例能够降低数据的大小,降低数据的存储空间。
330,保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件。
其中,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。
由于本申请实施例在云录制服务阶段会对RTP数据进行解析恢复成媒体编码数据,由于媒体编码数据的数据量小于RTP数据包,因此,本申请实施例能够降低存储空间,且由于在云录制服务阶段对RTP数据包进行解析而无需对媒体编码数据进行解码,由于解析相对解码会占用较小计算资源,因此,本申请实施例能够在节省存储空间的同时且相对较少占用计算资源。
可选的,作为另一实施例,在保存所述至少一个会议终端的媒体编码数据之前,所述方法还可以包括:确定所述媒体编码数据有效。
具体而言,本申请实施例中在对RTP数据进行解析,恢复成媒体编码数据后,还可以对媒体编码数据的有效性进行校验,在校验通过后,再保存数据。
例如,本申请可以通过解码器的相关函数进行有效性校验,具体的校验方法可以参见现有校验方法,此处不再详述。
可选的,在校验未通过的情况下,本申请实施例方法还包括云录制服务器向媒体服务器请求重传数据或发送关键帧。
可选的,作为另一实施例,在生成和保存与所述媒体编码数据对应的控制文件之前,所述方法还包括:
将所述RTP数据包的时间戳进行转换与时间轴对齐,得到所述媒体编码数据的时间戳信息。
具体而言,由于音视频数据涉及到后期转码处理需要建立统一的时间轴进行同步,因此,本申请实施例中可以以建立录制会议时间为时间轴的起始时间,所有接收到的媒体RTP数据的时间戳均进行转换与时间轴进行对齐。
由于RTP数据包传输时有自己时间戳,然而一般情况下,RTP数据包的时间戳是从建立发送开始第一帧随机生成的时间戳,后续帧的时间戳通过与第一帧的时间戳的时间间隔往上累加得到。然而在解码时,RTP数据包中之前随机生成的第一帧的时间戳和后续帧的时间戳由于不是实际的物理实际,因此没有对应的物理意义,因此,无法使用。因此,本申请实施例中对接收的包做合并处理的同时,把合并后的所有帧的时间做转换,转换成真实的物理时间,或者转换成自定义的时间。这样通过时间转换,便于后续的转码服务进行统一时间轴的同步。
时间转换之后,本申请实施例根据媒体数据的存储地址和转换后的时间戳信息生成控制文件,即将媒体数据的存储地址和时间戳信息记录在控制文件中。
可选的,作为另一实施例,所述控制文件包括会议头部信息字段和数据结构字段,其中所述会议头部信息字段包括会议属性信息,所述会议属性信息包括所述媒体编码数据的起始地址信息;所述数据结构字段包括所述媒体编码数据的属性信息,所述媒体编码数据的属性信息包括时间戳信息和存储地址信息。
具体而言,在云录制服务过程阶段,云录制服务器,对接收到的RTP数据包括进行解析得到媒体编码数据,即音频媒体文件和/或视频媒体文件,并生成包括媒体编码数据的时间戳信息和存储地址等信息的控制文件。得到控制文件和媒体编码数据后即完成了云录制服务过程。在后续转码服务过程阶段可以通过分析保存的控制文件和媒体数据文件进行处理转码并保存转码后的媒体文件。
下面结合图4的例子描述本申请实施例的云录制服务的过程的具体方案。
云端录制音视频时,云录制服务器接收到媒体服务器发送的RTP数据包后,解析RTP数据包并组装为源媒体压缩数据(即媒体编码数据),之后云录制服务器验证媒体编码数据的有效性,若数据无效则向媒体服务器请求重传数据或重传关键帧。在验证数据有效后,保存媒体文件,其中在RTP数据包括音频和视频流时,保存的媒体文件包括视频媒体文件、音频媒体文件和控制文件。
也就是说本申请实施例中存储的文件可以包括三种文件,即控制文件和两种媒体文件(视频媒体文件和音频媒体文件)。
可选的,作为另一实施例,本申请实施例中保存的文件还可以包括字幕数据文件,即保存四个数据文件,分别为控制文件、视频数据文件、音频数据文件和字幕数据文件。控制文件中可以保存音频媒体数据、视频媒体数据和字幕数据在相应数据文件中的保存的物理位置关系和数据的基本信息。视频数据文件保存的是多路视频媒体流的媒体编码数据(例如VP9或其他视频编码格式的数据),音频数据文件保存的是多路音频媒体流的媒体编码数据(例如OPUS或其他音频编码格式的数据),字幕数据保存视频会议相关的文字信息。例如,字幕数据保存的是视频会议过程中的音频识别的结果,例如,会议过程中音频对应的字幕;或者字幕数据保存的是会议过程中的聊天记录或者聊天弹幕,本申请实施例并不限于此。
应理解,本申请实施例中,云录制服务器保存的媒体数据文件可以为无序数据,即保存的数据可以不按照实际数据的时间先后存储,具体的媒体数据的顺序可以由控制文件保存,后期转码服务阶段处理时可以根据控制文件来进行整理和转码。对应的,控制文件中的各类型媒体数据字段也为无序混合状态,即本申请实施例中云录制服务阶段针对数据帧为先收先验证先保存,具体各个数据帧的时间信息会保存在控制文件中。
例如,如图5所示,流在文件中的顺序无序的,例如,排序为流1第1帧(F1 frame1)、流1第2帧(F1 frame2)、流2第1帧(F2 frame1)、流1第3帧(F1 frame3)、流2第2帧(F2frame2)…流N第N帧。其中,相邻帧后一帧的起始地址为前一帧的结束地址。
应理解,本申请实施例中,不同的流的媒体流ID(MID)不同,同一会议终端可以仅包括一个媒体流,例如音频流或者视频流;也可以同时包括音频流和视频流,在这种情况下,该一个会议终端可以对应两个媒体流ID取值,这两个媒体流ID分别对应音频流和视频流。
由于不同的会议终端的帧率和网络等有差异,云录制服务器获取的媒体数据的不同的数据流的时序可能是不同的,因此,本申请实施例在云录制服务阶段保存时可以根据恢复后的媒体编码数据的先后顺序直接保存,即先获取哪个数据帧就保存哪个数据帧,无需进行数据帧的时间先后的排序,减少计算资源。
可选的,在视频数据涉及到要录制的视频对象无视频流(例如,用户关闭视频摄像头或者用户的会议终端无可以的视频摄像头)的情况,这中情况下控制文件中还包括空帧开始和结束的标记数据。
可选的,控制文件中还可以包括用于指示视频流结束的字段。
应理解,控制文件还可以包括其他用于记录和转码的相关信息。例如还可以包括录制模式,媒体类型、媒体流ID以及一些扩展信息等,作为示例而非限定,下面结合表1和表2描述本申请实施例中生成的控制文件数据结构。
应理解,控制文件中的各类型媒体数据对应帧数据描述数据结构可以为无序混合状态,本申请实施例是对数据先接收先验证先保存,同时生成的控制文件中数据帧描述也对应可以是无序状态。控制文件中的数据帧描述的数据帧均为经过检验有效的数据帧,无效的数据帧在云录制服务阶段会丢弃掉,由于后期转码服务处理时无效数据是无法解码的,本申请实施例通过这种方式能够避免浪费存储空间保存无用数据。
可选的,本本申请实施例中控制文件主要包括头部信息数据结构和帧数据描述数据结构。作为示例而非限定,下文表1中展示了头部信息数据结构的主要字段,表2中展示了帧数据描述数据结构的主要字段。
如表1所示展示了头部信息的主要字段的参数名称、对应的中文解释、对应的数据类型、各个字段的长度以及备注。其中备注中描述了各个字段的取值描述。
其中,参数K为录制的视频的分辨率是否为4K,长度为1比特(bit),其中在取值为0x0表示否(false),例如为2K,在取值为0x1时,表示是(true)即为4k。类似的,其他参数的情况于此类似,其余字段的含义长度以及取值情况可以参见表1中的描述此处不再一一赘述。其中,参数M表示录制模式,在取值为0x0表示为演讲者模式(RCMODE_SPEAKER),在取值为0x1是表示为视图模式(RCMODE_VIEW),视图模式与上文中的画廊模式对应,也可以称为画廊模式。需要说明的是,参数数据起始地址(address)是媒体数据的起始地址,也是头部信息结束的地址。数据数量(len)为整个会议录制的数据的数量;会议录制时间戳(timestamp)为发起会议录制时的时间戳,即为开始录制时的时间戳。
表1
序号 参数名称 中文解释 数据类型 长度 备注
1 K 是否4k bit 1 0x0.false 2k 0x1.true 4k
2 M 录制模式 bit 2 0x0. RCMODE_SPEAKER 演讲者模式0x1. RCMODE_VIEW 视图模式
3 SN 每页视频显示数量 bit 6 最大值63
4 TLEN 会议主题字符串长度 bit 8 最大值255
5 ULEN 发起者昵称字符串长度 bit 6 最大值63
6 ext 扩展 bit 9 保留,暂时未使用
7 address 数据起始地址 bit 32
8 len 数据数量 bit 32
9 timestamp 会议录制时间戳 bit 64 发起会议录制时的时间戳
如表2所示,表2中展示了帧数据描述数据结构和主要字段的参数名称、对应的中文解释、对应的数据类型、各个字段的长度以及备注。其中备注中描述了各个字段的取值描述。
其中,字段MT表示媒体类型,长度为4比特,其中取值为0x1表示为视频(VIDEO),取值为0x2表示为音频(AUDIO),取值为0x3表示为共享视频(SHARED_VIDEO),取值为0x4表示为共享音频(SHARED_AUDIO),取值为0x5表示为字幕(SUBTITLES)。其中,索引(INDEX)的取值决定视频流合成画面时所处的位置,即在画廊模式下一个界面中多个用户画面的排布位置,索引值在画面分布的位置可以由录制会议设置的布局决定。
类似的,其他参数的情况于此类似,其余字段的含义长度以及取值情况可以参见表2中的描述此处不再一一赘述。需要说明的是,字段N表示数据帧类型,针对视频帧而言,在取值为0x0表示非空帧(FRAME),在取值为0X1表示空帧开始(NULL_FRAME_START),在取值为0X2表示中间空帧(NULL_FRAME),取值为0X3表示空帧结束(NULL_FRAME_END),在取值为0x4表示当前视频流结束(STREAM_END)。
表2
序号 参数名称 中文解释 数据类型 长度 备注
1 MT 媒体类型 bit 4 0x1.VIDEO;0x2.AUDIO;0x3.SHARED_VIDEO;0x4.SHARED_AUDIO;0x5.SUBTITLES;
2 N 数据帧类型 bit 4 0x0.FRAME:非空帧0X1.NULL_FRAME_START:空帧开始0X2.NULL_FRAME:中间空帧0X3.NULL_FRAME_END:空帧结束0x4.STREAM_END:当前视频流结束
3 AT 音频类型 bit 2 0x0.NONE:没有音频0x1.VOIP:网络语音模式0x2.PHONE:电话模式0x3.UNKNOW:未知模式
4 AS 音频状态 bit 1 0x0.audio音频开启0x1.audio 音频关闭
5 VT 视频类型 bit 2 0x0.NONE:没有视频0x1.CAMERA:摄像头视频
6 VS 视频状态 bit 1 0x0.video 视频开启0x1.video 视频关闭
7 VOLUME 音量 bit 4 [0-9]
8 K 关键帧 bit 1 仅视频帧有效 0x0.非关键帧 0x1.关键帧
9 EXT 扩展 bit 13 保留,暂未使用
10 MID 媒体流id bit 32 单次录制会议中,每路媒体流拥有的唯一id(同一生产者产生的视频流/音频流,若退订后又重新订阅则产生新的MID),相同MID的帧数据将被规划到相同分组中处理。
11 INDEX 索引 bit 32 索引位置决定视频流合成画面时所处的位置(索引值在画面分布的位置由录制会议设置的布局决定)。
12 TIMESTAMP 媒体帧的时间戳 bit 64 转换为以头部中timestamp为起始时间的时间戳(1/1000单位)
13 ADDRESS 物理地址 bit 64 媒体帧数据所在媒体缓存文件中的物理地址,媒体缓存文件由MT决定。
14 LEN 媒体帧所占的字节数 bit 32 在ADDRESS读取LEN bit数据即为完整数据帧。
在云端录制结束后,在转码服务阶段,云录制服务器可以基于控制文件的相关字段内容随时都可以通过读取分析保存的控制文件和媒体数据文件进行处理转码并保存为视频文件和音频文件,例如保存为H.264/AAC编码格式的MP4视频和AAC(Advanced AudioCoding,高级音频编码)编码格式的M4A音频文件。具体如何根据控制文件来进行转码服务可以参见下文中关于转码服务过程阶段中描述。
对应在录制服务之后,如图3所示的方法还可以包括转码服务,对应的,作为另一实施例,如图3所示的方法还可以包括:根据控制文件的时间戳信息按照时间顺序整理所述媒体编码数据;根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件。
具体而言,本申请实施例在转码服务过程中首先是对控制文件中的帧数据描述信息进行补帧处理,例如,在控制文件记录的帧数据描述信息中的同一画面中的不同视频流的视频帧数据的帧率不同时,需要进行补帧处理。应理解,此处的补帧处理可以是仅补充控制文件中的控制数据,即补充的是帧数据的描述信息,而不需要补充实际的媒体数据。在控制文件记录的音频帧间隔时间较大,例如大于20ms时,也需要进行音频帧的补帧处理。同样的,音频帧的补帧也可以只是补的是控制文件中的帧数据的描述信息,而不需要补充实际的媒体数据。即媒体文件没有变动。在完成补帧后,云录制服务器会按照补帧后的控制文件的控制数据根据时间戳的顺序将不同流同一时间戳的视频帧或音频帧作为一组来进行转码服务,其中,对于前述需要补帧的媒体帧,云录制服务器读取到帧数据的描述信息后使用对应的媒体帧文件来进行转码。例如,对于补帧的视频帧使用其前一帧的视频帧,或者使用后一帧的视频帧或者使用前一帧和后一帧视频帧生成的视频帧来进行转码。对于补帧的音频帧也可以使用其前一帧的音频帧或者使用后一帧的音频帧或者使用前一帧和后一帧音频帧生成的音频帧来进行转码。
可选的,所述媒体编码数据包括视频媒体文件,所述云录制文件包括视频文件,所述根据控制文件的时间戳信息按照时间顺序整理所述媒体编码数据,包括:根据所述控制文件中的时间戳信息,对所述控制文件中的视频媒体文件进行补帧处理,得到补帧后的视频帧数据描述信息;所述根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件,包括:根据所述补帧后的视频帧数据描述信息的时间戳信息,将相同时间戳信息的视频帧作为同一分组进行转码服务,得到转码后的视频文件。
可选的,作为另一实施例,所述根据所述控制文件中的时间戳信息,对所述控制文件中的视频媒体文件进行补帧处理,得到补帧后的视频帧数据描述信息,包括:根据所述时间戳信息,将同一会议画面中的多路视频帧补帧为同一帧率,得到得到补帧后的视频帧数据描述信息。
例如,本申请实施例中由于不同的数据流的帧率可能不一样,本申请实施例可以将同一画面中的多路视频流的帧率补帧为统一帧率,例如该最高帧率为同一画面中多路视频流中帧率最高值。例如,统一画面包括25个用户,那么本申请实施例中可以将除了最高帧率视频流之外的24个视频流进行补帧,补帧后的视频流的帧率均为最高帧率。
可选的,本申请实施例中补帧的方式不限定。例如可以使用前一帧数据进行补充,或者使用空缺的后一帧的数据进行补帧,或者使用相邻的两个帧来进行中间空缺帧的补帧,例如根据两帧的均值补帧,或者根据两帧的中间值补帧等等。
可选的,在视频空帧标记闭环中即在空帧开始和空帧结束之间本申请实施例在转码服务之前也需要进行空帧补帧,具体的空帧补充的视频帧可以为预设的空帧。
可选的,所述媒体编码数据包括音频媒体文件,所述云录制文件包括音频文件,所述根据控制文件的时间戳信息按照时间顺序整理所述媒体编码数据,包括:根据所述控制文件中的时间戳信息,按照预设时间间隔对所述控制文件中的音频媒体文件进行补帧处理,得到补帧后的音频帧数据描述信息;所述根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件,包括:根据所述补帧后的音频帧数据描述信息的时间戳信息,将相同时间戳信息的音频帧作为同一分组进行转码处理,得到转码后的音频文件。
例如,本申请实施例中对于音频数据,也可以进行补帧处理,例如,按照20ms的间隔进行音频数据帧的补帧,补充的音频数据类似的也可以根据前一帧或者后一帧或者前后两帧来进行补帧。
下面结合图6的例子描述本申请实施例的转码服务的过程的具体方案。如图6所示的转码过程,首先包括云录制服务器中的转码控制器先获取控制数据,即获取控制文件中的控制数据,且对控制数据按照时序整理,具体整理过程包括补帧处理(具体补帧的方案可以参见上文视频帧和音频帧的补帧方案的描述)等,得到整理后的视频帧队列和音频帧队列(应理解,此处补帧可以是补充的控制文件中的帧数据的描述信息,例如,补帧的描述信息为控制文件中前一帧的描述信息),之后转码控制器按照整理后的时间顺序到媒体文件中读取对应的数据帧,例如,针对视频帧而言,包括25路数据流,按照整理后的帧率的时间间隔顺序去读取对应的数据帧,例如,针对某一帧时刻,其中有1路或多路视频帧为媒体文件中存储的视频帧,另外的几路为补帧视频帧,对于补帧视频帧,会根据读取的补帧数据的描述信息读取该路视频流中对应的视频帧,例如,读取该时刻之前的一帧的视频帧(或者之后的一帧视频帧或者前后两帧生成的视频帧)作为该补帧视频帧。之后将该25路同一时间戳的视频帧输入到解码器,以使解码器将该25路视频帧合成为一个会议视频画面。其中对于空帧,本申请实施例可以直接使用预设好的空帧来和其他同意时间戳的视频帧一起进行解码。类似的,对于音频帧而言,与此类似。通过这种方式,无需对实际的媒体帧进行补帧,仅补充其对应的控制数据(即帧数据的描述信息),本申请实施例能够节省内存,同时降低计算资源。
应理解,补帧的视频描述信息可以为完整的如表2所示的数据帧数据描述数据,也可以为指示该补帧为与哪一个帧一致的信息,例如与前一帧一致的信息。本申请实施例并不限于此。
再之后,如图6所示,云录制服务器中的视频处理器将相同时序中的不同视频源的视频编码数据作为一个分组通过视频解码器进行视频解码(即将不同流中时间戳一样或相近的视频帧作为一组同时按照视频帧的索引进行解码,其中,一个视频帧分组对应画廊模式下的一个会议视频画面),通过画面处理器进行画面处理(包括缩放、绘制、空帧绘制,画面混合等操作)然后通过视频H.264编码器进行H.264编码并写入到MP4文件,得到录制结果。音频处理器通过音频解码器将相同时序不同音频源的音频编码数据作为一个分组进行解码,然后通过音频处理进行混音、降噪等处理然后通过音频ACC编码器进行AAC编码后分别写入到MP4和M4A文件,得到录制结果。
应理解,上文描述了转码服务过程由云录制服务器执行的例子,可选的,该转码服务过程也可以由另外的设备执行,本申请实施例并不限于此。
请参考图7,图7示出了本申请的一个实施例提供的视频会议云录制的装置的组成框图。图7所示的装置700可以为云录制服务器,应理解,该装置700与上述方法实施例中的云录制服务器对应,能够执行上述方法实施例涉及的云录制服务器执行的各个步骤,该装置700的具体功能可以参见上文中的描述,为避免重复,此处适当省略详细描述。
图7所示的装置700包括至少一个能以软件或固件的形式存储于存储器中或固化在该装置中的软件功能模块,图7所示的装置700包括:
获取单元710,用于获取实时传输协议RTP数据包,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,其中一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据;解析单元720,用于解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据,其中,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件;保存单元730,用于保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。
在一种实施方式中,所述保存单元还用于在生成和保存与所述媒体编码数据对应的控制文件之前,将所述RTP数据包的时间戳进行转换与时间轴对齐,得到所述媒体编码数据的时间戳信息。
在一种实施方式中,在保存所述至少一个会议终端的媒体编码数据之前,所述保存单元还用于确定所述媒体编码数据有效。
在一种实施方式中,所述装置还包括:转码单元,用于根据控制文件的时间戳信息按照时间顺序整理所述媒体编码数据;根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件。
在一种实施方式中,所述媒体编码数据包括视频媒体文件,所述转码单元具体用于根据所述控制文件中的时间戳信息,对所述控制文件中的视频媒体文件进行补帧处理,得到补帧后的视频帧数据描述信息;根据所述补帧后的视频帧数据描述信息的时间戳信息,将相同时间戳信息的视频帧作为同一分组进行转码服务,得到转码后的视频文件。
在一种实施方式中,所述转码单元具体用于根据所述时间戳信息,将同一会议画面中的多路视频帧补帧为统一帧率,得到所述补帧后的视频帧队列。
在一种实施方式中,所述媒体编码数据包括音频媒体文件,所述转码单元具体用于根据所述控制文件中的时间戳信息,按照预设时间间隔对所述控制文件中的音频媒体文件进行补帧处理,得到补帧后的音频帧数据描述信息;根据所述补帧后的音频帧数据描述信息的时间戳信息,将相同时间戳信息的音频帧作为同一分组进行转码处理,得到转码后的音频文件。
在一种实施方式中,所述控制文件包括会议头部信息字段和数据结构字段,其中所述会议头部信息字段包括会议属性信息,所述会议属性信息包括所述媒体编码数据的起始地址信息;所述数据结构字段包括所述媒体编码数据的属性信息,所述媒体编码数据的属性信息包括时间戳信息和存储地址信息。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置的具体工作过程,可以参考前述方法中的对应过程,在此不再过多赘述。
如图8所示,本申请的一个实施例提供一种电子设备800,该电子设备800包括:存储器810、处理器820以及存储在存储器810上并可在处理器820上运行的计算机程序,其中,处理器820通过总线830从存储器810读取程序并执行所述程序时可实现如上述任意实施例中的方法。可选的,图8所示的设备还可以包括收发器,该收发器可以用于数据流的发送和/或接收。
处理器820可以处理数字信号,可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中,处理器820可以是微处理器。
存储器810可以用于存储由处理器820执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码,用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器820可以用于执行存储器810中的指令以实现上述方法。存储器810包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。
本申请的一个实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时可实现如上述实施例提供的上述方法。
本申请的一个实施例还提供了一种计算机程序产品,所述的计算机程序产品包括计算机程序,其中,所述的计算机程序被处理器执行时可实现如上述实施例提供的上述方法。
应注意,本发明实施例中的处理器(例如,图8中的处理器)可以是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digital signal processor,DSP)、专用集成电路(application specificintegrated crcuit,ASIC)、现成可编程门阵列(field programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
可以理解,本发明实施例中的存储器(例如,图8中的存储器)可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(read-only memory,ROM)、可编程只读存储器(programmable ROM,PROM)、可擦除可编程只读存储器(erasable PROM,EPROM)、电可擦除可编程只读存储器(electricallyEPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic RAM,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM,ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM,DR RAM)。应注意,本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例涉及到的应用程序包括安装在请求端上的任何应用,包括但不限于浏览器、电子邮件、即时消息服务、文字处理、键盘虚拟、窗口小部件(Widget)、加密、数字版权管理、语音识别、语音复制、定位(例如由全球定位系统提供的功能)、音乐播放等等。
应理解,本发明实施例中的收发单元或收发器也可以称为通信单元。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时,全部或部分地产生按照本发明实施例的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriber line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,高密度数字视频光盘(digitalvideo disc,DVD))、或者半导体介质(例如,固态硬盘(solid state disk,SSD))等。
在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如,部件可以是但不限于,在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示,在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中,部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外,这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据,例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
应理解,说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此,在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外,这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解,在本发明的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
另外,本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
应理解,在本发明实施例中,“与A相应的B”表示B与A相关联,根据A可以确定B。但还应理解,根据A确定B并不意味着仅仅根据A确定B,还可以根据A和/或其它信息确定B。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接,也可以是电的,机械的或其它的形式连接。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
总之,以上所述仅为本发明技术方案的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (10)

1.一种视频会议云录制的方法,其特征在于,包括:
获取实时传输协议RTP数据包,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,其中一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据;
解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据,其中,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件;
保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。
2.根据权利要求1所述的方法,其特征在于,在生成和保存与所述媒体编码数据对应的控制文件之前,所述方法还包括:
将所述RTP数据包的时间戳进行转换与时间轴对齐,得到所述媒体编码数据的时间戳信息。
3.根据权利要求1所述的方法,其特征在于,在保存所述至少一个会议终端的媒体编码数据之前,所述方法还包括:
确定所述媒体编码数据有效。
4.根据权利要求1至3中任一项所述的方法,其特征在于,所述方法还包括:
根据控制文件中的时间戳信息按照时间顺序整理所述媒体编码数据;
根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件。
5.根据权利要求4所述的方法,其特征在于,所述媒体编码数据包括视频媒体文件,所述云录制文件包括视频文件,所述根据控制文件中的时间戳信息按照时间顺序整理所述媒体编码数据,包括:
根据所述控制文件中的时间戳信息,对所述控制文件中的视频媒体文件进行补帧处理,得到补帧后的视频帧数据描述信息;
所述根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件,包括:
根据所述补帧后的视频帧数据描述信息的时间戳信息,将相同时间戳信息的视频帧作为同一分组进行转码服务,得到转码后的视频文件。
6.根据权利要求4所述的方法,其特征在于,所述媒体编码数据包括音频媒体文件,所述云录制文件包括音频文件,所述根据控制文件中的时间戳信息按照时间顺序整理所述媒体编码数据,包括:
根据所述控制文件中的时间戳信息,按照预设时间间隔对所述控制文件中的音频媒体文件进行补帧处理,得到补帧后的音频帧数据描述信息;
所述根据整理的媒体编码数据进行转码处理,得到视频会议的云录制文件,包括:
根据所述补帧后的音频帧数据描述信息的时间戳信息,将相同时间戳信息的音频帧作为同一分组进行转码处理,得到转码后的音频文件。
7.根据权利要求1至3中任一项所述的方法,其特征在于,所述控制文件包括会议头部信息字段和数据结构字段,其中所述会议头部信息字段包括会议属性信息,所述会议属性信息包括所述媒体编码数据的起始地址信息;所述数据结构字段包括所述媒体编码数据的属性信息,所述媒体编码数据的属性信息包括时间戳信息和存储地址信息。
8.一种视频会议云录制的装置,其特征在于,包括:
获取单元,用于获取实时传输协议RTP数据包,所述RTP数据包包括参与会议的至少一个会议终端的数据流数据,其中一个会议终端的数据流数据包括音频数据流数据和/或视频数据流数据;
解析单元,用于解析所述RTP数据包,得到所述至少一个会议终端的媒体编码数据,其中,一个会议终端的所述媒体编码数据包括与所述一个会议终端的数据流数据对应的音频媒体文件和/或视频媒体文件;
保存单元,用于保存所述至少一个会议终端的媒体编码数据,并生成和保存与所述媒体编码数据对应的控制文件,所述控制文件包括所述媒体编码数据的时间戳信息和存储地址信息。
9.一种电子设备,其特征在于,包括存储器、处理器以及存储在所述存储器上并在所述处理器上运行的计算机程序,其中,所述计算机程序被所述处理器运行时执行如权利要求1-7中任意一项权利要求所述的方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,其中,所述计算机程序被处理器运行时执行如权利要求1-7中任意一项权利要求所述的方法。
CN202311393120.8A 2023-10-25 2023-10-25 一种视频会议云录制的方法、装置、电子设备和存储介质 Pending CN117294805A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311393120.8A CN117294805A (zh) 2023-10-25 2023-10-25 一种视频会议云录制的方法、装置、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311393120.8A CN117294805A (zh) 2023-10-25 2023-10-25 一种视频会议云录制的方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
CN117294805A true CN117294805A (zh) 2023-12-26

Family

ID=89240811

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311393120.8A Pending CN117294805A (zh) 2023-10-25 2023-10-25 一种视频会议云录制的方法、装置、电子设备和存储介质

Country Status (1)

Country Link
CN (1) CN117294805A (zh)

Similar Documents

Publication Publication Date Title
US9763002B1 (en) Stream caching for audio mixers
CN111901674B (zh) 一种视频播放控制方法及装置
KR101477315B1 (ko) 프레임 손실에 의해 야기된 실시간 비디오 아티팩트를 은폐하는 메커니즘
JP6475228B2 (ja) コンテナフォーマットでのメディアファイルの構文を意識した操作
US10476928B2 (en) Network video playback method and apparatus
US8223851B2 (en) Method and an apparatus for embedding data in a media stream
WO2020155964A1 (zh) 音视频的切换方法、装置、计算机设备及可读存储介质
CN109688365B (zh) 视频会议的处理方法和计算机可读存储介质
US20180063477A1 (en) Tablet docking stations as adapter for video conferencing system
US20140369528A1 (en) Mixing decision controlling decode decision
CN103327361A (zh) 实时视频通讯回放数据流的获取方法、装置及系统
WO2017116419A1 (en) Method and apparatus for metadata insertion pipeline for streaming media
CN109874024A (zh) 一种基于动态视频海报的弹幕处理方法、系统及存储介质
WO2024098836A1 (zh) 视频对齐方法及装置
CN117294805A (zh) 一种视频会议云录制的方法、装置、电子设备和存储介质
EP4184924A1 (en) Network live broadcast interaction method and device
US10798142B2 (en) Method, apparatus and system of video and audio sharing among communication devices
CN108200481B (zh) 一种rtp-ps流处理方法、装置、设备及存储介质
JP2012151622A (ja) 受信端末、パケットデータ受信方法、送信端末、送受信システム、中継端末およびパケットデータの中継方法
US20140137148A1 (en) System for Managing the Streaming and Recording of Audiovisual Data
US11882170B2 (en) Extended W3C media extensions for processing dash and CMAF inband events
US20230224557A1 (en) Auxiliary mpds for mpeg dash to support prerolls, midrolls and endrolls with stacking properties
Calvo‐Flores et al. Integrating multimedia streaming from heterogeneous sources to JavaME mobile devices
US20240129537A1 (en) Method and apparatus for signaling cmaf switching sets in isobmff
US11588870B2 (en) W3C media extensions for processing DASH and CMAF inband events along with media using process@append and process@play mode

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination