CN112584134A - 视频会议码流的测试方法、装置、计算机设备和存储介质 - Google Patents
视频会议码流的测试方法、装置、计算机设备和存储介质 Download PDFInfo
- Publication number
- CN112584134A CN112584134A CN202011418543.7A CN202011418543A CN112584134A CN 112584134 A CN112584134 A CN 112584134A CN 202011418543 A CN202011418543 A CN 202011418543A CN 112584134 A CN112584134 A CN 112584134A
- Authority
- CN
- China
- Prior art keywords
- code stream
- sample data
- stream sample
- video
- rtp
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N17/00—Diagnosis, testing or measuring for television systems or their details
- H04N17/004—Diagnosis, testing or measuring for television systems or their details for digital television systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/14—Systems for two-way working
- H04N7/15—Conference systems
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- General Health & Medical Sciences (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
本申请涉及一种视频会议码流的测试方法、装置、计算机设备和存储介质。所述方法包括:接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。采用本方法能够有效提高视频码流的测试效率。
Description
技术领域
本申请涉及计算机技术领域,特别是涉及一种视频会议码流的测试方法、装置、计算机设备和存储介质。
背景技术
随着计算机技术的发展,5G时代的来临,互联网的出现给现代生活带来了极大的便利,越来越多的企业可以通过使用在线平台与多个用户终端进行实时的视频通讯,例如,视频直播、视频会议等。
然而,目前的视频会议测试方式中,视频数据包传输所经过的网络,往往是许多复杂的异构的网络所组成,而数据包一般采用明文传输方式,使得传输不可靠,常常伴随丢包的现象。当出现丢包时,远端每次发送视频编码关键帧请求之后,都需要等待一段时间才能接收到返回的视频编码关键帧数据,无法马上恢复图像解码,数据包的丢失造成解码参考数据帧不完整,解码出来的图像也难以确保准确,容易导致视频码流的测试效率较低。
发明内容
基于此,有必要针对上述技术问题,提供一种能够提高视频码流测试效率的视频会议码流的测试方法、装置、计算机设备和存储介质。
一种视频会议码流的测试方法,所述方法包括:
接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;
在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;
若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。
在其中一个实施例中,所述将所述码流样本数据按照顺序进行发送,包括:
从头开始读取所述码流样本数据,每次读取一个RTP数据包后,重新对RTP协议头部的字段信息进行更新赋值,得到更新赋值后的RTP协议头部的字段信息;其中,所述RTP协议头部的字段信息包括RTP包头的序列号字段、时间戳字段以及同步源字段;
将所述更新赋值后的RTP协议头部的字段信息进行发送。
在其中一个实施例中,所述从头开始读取所述码流样本数据,每次读取一个RTP数据包之后,所述方法还包括:
判断是否读取到所述码流样本文件的尾部;
当读取到所述码流样本数据尾部的最后一个数据包时,则返回到所述码流样本数据开头的位置,重新读取数据;
并根据上一个已发送的RTP数据包,对下一个数据包的所述RTP协议头部的序列号字段、时间戳字段以及同步源字段进行更新赋值后再发送。
在其中一个实施例中,所述将所述码流样本数据按照顺序进行发送包括:
当每次完成数据包的发送后,记录下当前数据包的在所述码流样本数据中的位置;所述位置用于当下一次获取到处理器的处理时间片时,从所述码流样本数据中上次中断的位置开始发送数据包。
在其中一个实施例中,所述接收到对端发送的视频会话的呼叫请求之前,所述方法还包括:
在初始化时,抓取码流样本数据保存至本地文件夹中,所述码流样本数据中包括不同类型的音视频源数据格式;
对每一个所述码流样本数据进行分析,记录每一个视频关键帧在所述码流样本中的位置。
在其中一个实施例中,所述方法还包括:
当接收到所述对端发送的视频解码关键帧申请信令时,根据预先建立的不同呼叫会话对应的文件指针进行查找;所述文件指针用于标记每一个视频关键帧在所述码流样本中的位置;
若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到所述下一个视频关键帧对应的位置,并以所述下一个视频关键帧对应的位置为起点,继续将所述码流样本数据按照顺序进行发送;
若未查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳回到所述码流样本数据开头的位置,重新发送数据包。
在其中一个实施例中,所述若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到所述下一个视频关键帧对应的位置之后,所述方法还包括:
当跳转到所述下一个视频关键帧对应的位置时,根据上一个已发送的RTP数据包,对当前RTP数据包对应的RTP包序列号、时间戳以及同步源字段进行相应的更新赋值;
并将更新赋值后的RTP数据包进行发送。
一种视频会议码流的测试装置,所述装置包括:
接收模块,用于接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;
查找模块,用于在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;
发送模块,用于若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。
一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现以下步骤:
接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;
在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;
若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。
一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现以下步骤:
接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;
在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;
若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。
上述视频会议码流的测试方法、装置、计算机设备和存储介质,通过接收到对端发送的视频会话的呼叫请求,呼叫请求中携带预设协议。在本地文件夹中查找与预设协议对应音视频格式的码流样本数据,码流样本数据是预先存储在本地文件夹中。若查找到,则与对端建立呼叫连接,并将码流样本数据按照顺序进行发送。由此使得,一个模拟终端能同时与多个端点同时会话进行测试,每个会话都可以访问各自对应格式的码流样本文件,即使涉及多点测试的大容量的测试场景,也能够在降低测试成本的条件下,有效提高视频码流的测试效率。
附图说明
图1为一个实施例中视频会议码流的测试方法的应用环境图;
图2为一个实施例中视频会议码流的测试方法的流程示意图;
图3为一个实施例中将码流样本数据按照顺序进行发送步骤的流程示意图;
图4为一个实施例中判断是否读取到码流样本文件的尾部步骤的流程示意图;
图5为另一个实施例中将码流样本数据按照顺序进行发送步骤的流程示意图;
图6A为一个实施例中记录每一个视频关键帧在码流样本中的位置步骤的流程示意图;
图6B为一个实施例中接收到对端发送的视频关键帧请求时的处理流程示意图;
图7为一个实施例中当接收到对端发送的视频解码关键帧申请信令时步骤的流程示意图;
图8为一个实施例中视频会议码流的测试装置的结构框图;
图9为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供的视频会议码流的测试方法,可以应用于如图1所示的应用环境中。其中,终端102通过网络与对端104通过网络进行通信。终端102接收到对端104发送的视频会话的呼叫请求,呼叫请求中携带预设协议。终端102在本地文件夹中查找与预设协议对应音视频格式的码流样本数据,码流样本数据是预先存储在本地文件夹中。若终端102查找到,则终端102与对端104建立呼叫连接,并将码流样本数据按照顺序进行发送至对端104。其中,终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备,对端104可以用独立的服务器或者是多个服务器组成的服务器集群来实现,也可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。
在一个实施例中,如图2所示,提供了一种视频会议码流的测试方法,以该方法应用于图1中的终端为例进行说明,包括以下步骤:
步骤202,接收到对端发送的视频会话的呼叫请求,呼叫请求中携带预设协议。
针对多点会议即同时有成千上百的端点,或者测试多态MCU设备,MCU(MultiControl Unit)即多点接入单元,MCU可以分解为MC(Multipoint Controller,多点控制器)和MP(Multipoint Processor,多点处理器),其中MC处理多点的信令,MP负责多点通信的媒体处理。当需要对多态MCU设备进行测试时,实体设备需求量庞大,测试成本直线上升,因而为了减少测试多点会议需要的大量实体设备成本,可以利用模拟器来实现成千上百的实体设备的功能。例如,一种虚拟的H.323功能的终端模拟器,这种模拟器不依赖于特定的硬件,能有效降低音视频会议的多点接入单元设备、端点设备开发对接码流的测试环境的搭建成本,能够在开发过程中进行测试及时发现存在的问题。
具体的,终端接收到对端发送的视频会话的呼叫请求,呼叫请求中携带预设协议。以H.323终端为例进行说明。H.323终端是指可以提供在点对点或者多点会议中音视频数据和信令的通信能力,比如在一台机器上(可以是PC端即Personal Computer、小型服务器等)运行一个终端模拟器,模拟出用于测试的点对点和多点会议的码流。其中,该终端模拟器可以集成H.323协议栈、SIP协议栈,能进行视频会议H.323/SIP呼叫、被呼。H.323是指H.323协议族规定了在主要包括IP网络在内的基于分组交换的网络上提供多媒体通信的部件、协议和规程。此协议总体上介绍了基于包交换网络的视频会议系统和终端的要求,解释了呼叫建立的基本过程。SIP(Session Initiation Protocol)即会话初始协议,是由IETF(Internet Engineering Task Force,因特网工程任务组)制定的多媒体通信协议。同时,该终端模拟器也能够读取Wireshark、tcpdump等软件抓取的码流数据包。其中,对端可以为多点会议中任意的一个端。预设协议是指呼叫协商内容和流程需要遵循的协议,例如H.323或SIP协议,这些协议都是由若干个文件进行详细阐述。
步骤204,在本地文件夹中查找与预设协议对应音视频格式的码流样本数据,码流样本数据是预先存储在本地文件夹中。
步骤206,若查找到,则与对端建立呼叫连接,并将码流样本数据按照顺序进行发送。
当终端接收到对端发送的视频会话的呼叫请求之后,终端可以根据呼叫请求中携带预设协议,在本地文件夹中查找与预设协议对应音视频格式的码流样本数据,其中,码流样本数据是预先存储在本地文件夹中。每个码流样本文件在创建的时候,就保存好这份码流文件是属于哪一种协议、分辨率、帧率等属性,当终端接收到对端发送的呼叫请求时,终端可以根据呼叫请求中携带的预设协议查找匹配的码流文件。例如,在呼叫协商阶段,终端模拟器可以根据协商到的公共能力集合,查找对应音视频格式的码流样本文件。呼叫协商的是媒体能力即公共能力集合,对于视频而言,公共能力集合可以包括视频编码协议、带宽、帧率、分辨率格式等等,对于音频而言,公共能力集合可以包括音频编码协议、带宽、采样率等等,还有一些诸如加密、解密、非标准能力等。当终端获取到协商好的公共能力后,就可以查找每个码流样本文件的属性是否符合要求,若终端查找到本地文件夹中已有的码流样本文件与对端的呼叫能力吻合,则终端可以与对端建立呼叫连接,并将查找到的码流样本数据按照顺序发送至对端。即如果查找到,则终端读取该码流样本文件,作为发送的数据源。如果终端遍历所有码流样本文件均不符合协商的公共能力集合中所有的能力,则协商失败,呼叫建立失败。
例如,预先可以使用WireShark、tcpdump等软件或带有网络镜像功能交换机等硬件来抓取网络数据包,若抓取到的视频样本文件有以下几个:2Mbps H.264 1080P 30、2Mbps H.264 1080P 50、2Mbps H.264 1080P 60、4Mbps H.2641080P 30、4Mbps H.2641080P 60。当呼叫发起时,终端可以根据接收到的对端发送的呼叫请求中携带的预设协议,匹配本地文件夹中已有的码流样本文件与对端的呼叫能力是否吻合,比如发起呼叫的对端具有能力集1Mbps、2Mbps、4Mbps、H.264、H.265、1080P、720P、60fps以及30fps。终端在本地文件夹中进行查找后发现与之最佳匹配的是4Mbps H.264 1080P 60,则终端与该对端建立呼叫,否则挂断呼叫。
当终端与对端建立呼叫连接之后,终端将查找到的与该对端匹配的码流样本数据按照顺序进行发送。其中,呼叫建立后,终端模拟器可以根据呼叫请求中携带的预设协议,从头开始读取码流样本文件,每次读取一个RTP数据包后,重新对RTP协议头部的序列号字段、时间戳字段以及同步信源(SSRC)标识符等字段进行赋值,重新赋值的目的是为了重新适应新的RTP会话,即终端模拟器每次读取一个RTP数据包后,根据下一个RTP会话对RTP协议头部的字段进行重新赋值。RTP即实时传输协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,它详细说明了在互联网上传递音频和视频的标准数据包格式。当同时有其他端点的呼叫发起时,只需要重复上述步骤就可以建立呼叫连接,即终端根据每个端点发送的呼叫请求,查找符合预设协议的码流样本文件,一份码流样本文件可以同时与多个对端通话,只需要建立不同呼叫会话对应的文件读取指针以及会话必要的上下文记录,彼此之间互不影响。对于一种码流格式来说,只需要抓取一份码流样本文件,就可以对所有的相同格式的码流发送能力需求的会话。
传统的测试音视频会议设备的方法,是使用实体设备构建相应的网络环境,按照用户使用的操作对音视频设备进行测试。这种方法更适用于“点对点”的视频会议终端通讯,当涉及使用MCU进行多点会议的场景时,或者测试多态MCU设备,实体设备需求量庞大,测试成本直线上升。而本实施例中,通过接收到对端发送的视频会话的呼叫请求,呼叫请求中携带预设协议。在本地文件夹中查找与预设协议对应音视频格式的码流样本数据,码流样本数据是预先存储在本地文件夹中。若查找到,则与对端建立呼叫连接,并将码流样本数据按照顺序进行发送。由此使得,一个模拟终端能同时与多个端点同时会话进行测试,每个会话都可以访问各自对应格式的码流样本文件,即使涉及多点测试的大容量的测试场景,也能够在降低测试成本的条件下,同时有效提高视频码流的测试效率。
在一个实施例中,如图3所示,将码流样本数据按照顺序进行发送的步骤包括:
步骤302,从头开始读取码流样本数据,每次读取一个RTP数据包后,重新对RTP协议头部的字段信息进行更新赋值,得到更新赋值后的RTP协议头部的字段信息;其中,RTP协议头部的字段信息包括RTP包头的序列号字段、时间戳字段以及同步源字段。
步骤304,将更新赋值后的RTP协议头部的字段信息进行发送。
若终端查找到本地文件夹中已有的码流样本文件与对端的呼叫能力吻合,则终端可以与对端建立呼叫连接,并将查找到的码流样本数据按照顺序发送至对端。具体的,终端可以根据接收到的对端发送的呼叫请求中携带的预设协议,从头开始读取查找到的码流样本数据,每次读取一个RTP数据包后,重新对RTP协议头部的字段信息进行更新赋值,得到更新赋值后的RTP协议头部的字段信息。其中,RTP协议头部的字段信息包括RTP包头的序列号字段、时间戳字段以及同步源字段。进一步的,终端将更新赋值后的RTP协议头部的字段信息和对应的RTP数据包进行发送。当有其他端点的呼叫发起时,只需要重复上述步骤就可以建立呼叫连接,即终端根据每个端点发送的呼叫请求,在本地文件夹中查找是否存在符合预设协议的码流样本文件,若查找到对应的码流样本文件就可以建立呼叫。当终端收到对端发送的挂断信令后,则终端停止发送数据包,回收资源,结束与对端的会话,同时与其他端的对话保留不变。由此使得,多个端点(终端、MCU)均可同时向终端模拟器进行呼叫会话,终端模拟器以样本数据包作为音视频数据源,提供呼叫、挂断、发送音视频数据等测试功能,实现了每个会话都可以访问各自对应格式的码流样本文件,即使涉及多点测试的大容量的测试场景,也能够在降低测试成本的条件下,同时有效提高视频码流的测试效率。
在其中一个实施例中,如图4所示,从头开始读取码流样本数据,每次读取一个RTP数据包之后,该方法还包括判断是否读取到码流样本文件的尾部的步骤,具体包括:
步骤402,判断是否读取到码流样本文件的尾部。
步骤404,当读取到码流样本数据尾部的最后一个数据包时,则返回到码流样本数据开头的位置,重新读取数据。
步骤406,并根据上一个已发送的RTP数据包,对下一个数据包的RTP协议头部的序列号字段、时间戳字段以及同步源字段进行更新赋值后再发送。
若终端查找到本地文件夹中已有的码流样本文件与对端的呼叫能力吻合,则终端可以与对端建立呼叫连接,并将查找到的码流样本数据按照顺序发送至对端。终端可以根据接收到的对端发送的呼叫请求中携带的预设协议,从头开始读取查找到的码流样本数据,每次读取一个RTP数据包后,终端可以判断是否读取到码流样本文件的尾部。当终端读取到码流样本数据尾部的最后一个数据包时,则返回到码流样本数据开头的位置,重新读取数据,并根据上一个已发送的RTP数据包,对下一个数据包的RTP协议头部的序列号字段、时间戳字段以及同步源字段进行更新赋值后再发送。
具体的,终端每次读取一个RTP数据包后,终端需要判断当前读取的数据包是否为该码流样本数据尾部的最后一个数据包,若是,则终端返回到码流样本数据开头的位置,重新读取数据,而RTP协议头部的序列号字段、时间戳字段、同步信源标识符等字段则继续承接上一个数据包进行赋值,即终端按照新的一个数据帧来重新赋值发送。由于码流样本文件的大小有限,一个会话可以是几分钟、几小时或者几天,当码流样本文件读取到尾部之后,则重新开始读取,以保证测试时传输的数据包不会中断。其中,重新赋值的最主要是两个字段,RTP协议头部的序列号字段是终端每次发送一个数据包后,下一个数据包对应的就RTP协议头部的序列号字段就加一(比如,赋值的数值为0到65535之间循环),时间戳字段是描述当前帧与下一帧之间的显示时间,每增加一帧就会增加一个步进(如90kHz/帧率,即帧率为30时,步进为90000/30=3000)。这些都是根据预设协议描述的进行更新。由此使得,在模拟测试中,避免了采集过多的数据样本,方便循环用,通过将预先抓取的音视频数据码流分割成RTP数据包,读取到内存,循环发送给对端,避免了音频或视频从摄像头采集到信号转换、编码、打包发送等流程,降低了整个测试环境软硬件的测试成本,能够在降低测试成本的条件下,同时有效提高视频码流的测试效率。
在其中一个实施例中,将码流样本数据按照顺序进行发送的步骤包括:
当每次完成数据包的发送后,记录下当前数据包的在码流样本数据中的位置,该位置用于当下一次获取到处理器的处理时间片时,,从码流样本数据中上次中断的位置开始发送数据包。
若终端查找到本地文件夹中已有的码流样本文件与对端的呼叫能力吻合,则终端可以与对端建立呼叫连接,并将查找到的码流样本数据按照顺序发送至对端。具体的,当终端每次完成数据包的发送后,终端记录下当前数据包的在码流样本数据中的位置,该位置用于当下一次获取到处理器的处理时间片时,,终端可以从码流样本数据中上次中断的位置开始发送数据包。例如,进行视频会话时,终端模拟器按照两端点协商好的视频格式选择对应的码流样本数据包,并读取该数据包到内存,然后预设协议的码率发送数据包,每一个发送的数据包在发送出去之前都更新RTP包头的序列号字段、时间戳字段以及同步源字段。其中,时间戳字段是按帧数更新的。比如,呼叫建立后第一个数据包的序号从一个随机的数开始。当发送完一次数据包时,记录下当前数据包的在码流样本数据中的位置A。记录下当前的数据包在码流样本数据中的位置,是为了下次获取到CPU的处理时间片的时候,从上次中断的位置即位置A处开始继续发送数据。数据包是一个接一个发的,数据包与数据包之间总会有时间间隔的,CPU调度一次只会发送一段数据,不会一直占用CPU的处理,如果一直占用CPU处理,就无法实现大容量场景下的并发测试。
例如,当终端需要同时进行多个会话时,就需要每个会话都要有各自对应的上下文标识。比如,MCU(多点会议的处理单元)在某一时刻向终端模拟器发起了一个会话A,在另一时刻发起了另一个会话B,终端可以分别根据每个会话对应的上下文标识和文件读取指针传输对应的数据包。比如,上下文标识可以为RTP包头的序列号字段。若会话A的码流数据包在传输过程中丢失了部分,MCU为了避免解码查错扩散,会向终端模拟器申请I帧,而终端模拟器在寻找与当前码流数据对应的下一个I帧时,如果RTP协议头部的序列号字段一直保持不改变(即始终使用码流样本数据中固定的字段),那么终端发送出去的RTP协议头部的序列号字段是不连续的,MCU接收到终端发送的数据包之后,就有可能误以为有丢包,继续申请I帧容错。而本实施例中,终端模拟器每次读取一个数据包后,均需要根据下一个RTP会话对RTP协议头部的字段进行重新赋值,由此使得,能够有效的提高并发测试数量,同时当测试遇到问题时,也可以将预先抓取的疑似有问题的数据包,作为模拟器的数据源,与测试设备展开会话,减低重现问题所需经过的繁多步骤,有效提升测试效率。
在一个实施例中,如图5所示,接收到对端发送的视频会话的呼叫请求之前,该方法还包括记录每一个视频关键帧在码流样本中的位置的步骤,具体包括:
步骤502,在初始化时,抓取码流样本数据保存至本地文件夹中,码流样本数据中包括不同类型的音视频源数据格式。
步骤504,对每一个码流样本数据进行分析,记录每一个视频关键帧在码流样本中的位置。
在终端接收到对端发送的视频会话的呼叫请求之前,终端可以预先抓取不同格式的样本数据包。例如,终端可以使用WireShark、tcpdump等软件或带有网络镜像功能交换机等硬件来抓取网络数据包。比如在H.323或SIP会议的环境中,从呼叫会议开始抓取对应的样本数据包,并将样本数据包保存到本地文件夹中。召开不同码流压缩协议(如H.264、H.265等)码率、帧率的会议,抓取数据包的多种格式,各自独立保存至本地文件夹中。抓取数据包的个数可以按照需要测试环境的需求而定。对于视频文件,抓取视频码流数据要从视频关键帧开始抓取。对于音视频样本文件的内容可以按照具体测试需求抓取对应的内容。例如,视频样本内容一般包括一段动态内容连贯的图像,方便测试时发现图像是否卡顿。音频样本可以是一段音乐,也可以是一段讲话。
具体的,终端在初始化时,终端将抓取的码流样本数据保存至本地文件夹中,码流样本数据中包括不同类型的音视频源数据格式。进一步的,终端对每一个码流样本数据进行分析,记录每一个视频关键帧在码流样本中的位置。终端预先从网络上抓取的样本码流文件,是一个个数据包按照某种格式存储起来的。要利用的时候需要知道这个码流样本文件的属性,也就是视频的码率、分辨率、帧率、编码协议等。同时,获取I帧位置的列表也需要读取文件指针(一个个数据包去读取),每碰到I帧的标记时可以记录对应的位置。可以在终端初始化时,自动从样本码流文件中进行推算并标记出来,也可以手动在收集样本数据包时标记好并存储,便于后续终端可以直接读取。文件指针是指打开文件的句柄,通过这个句柄可以实现读取文件,跳转等操作。此外,在终端收集每一个样本数据包时,需要确保收集若干对应的视频编码关键帧。这个关键帧可以通过多种方式获取,如通讯的两端点,一端点按照一定的预设时间间隔向对端申请视频关键帧。由此使得,由于数据源是预先抓取并且拆分好的RTP网络数据包,因此,只需要抓取不同格式的样本数据,即使没有相关的软硬件设备的情况下,也可以进行产品测试,能够提供一种十分灵活而全面的数据源,更好地覆盖产品测试场景。
在一个实施例中,如图6A所示,该方法还包括当接收到对端发送的视频解码关键帧申请信令时的步骤,具体包括:
步骤602,当接收到对端发送的视频解码关键帧申请信令时,根据预先建立的不同呼叫会话对应的文件指针进行查找,文件指针用于标记每一个视频关键帧在码流样本中的位置。
步骤604,若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到下一个视频关键帧对应的位置,并以下一个视频关键帧对应的位置为起点,继续将码流样本数据按照顺序进行发送。
步骤606,若未查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳回到码流样本数据开头的位置,重新发送数据包。
视频会议两端点通话中,视频数据包传输所经过的网络,往往是许多复杂的异构的网络所组成,常常伴随的丢包的现象。H.264是指国际标准化组织(ISO)和国际电信联盟(ITU)共同提出的继MPEG4之后的新一代数字视频压缩格式。对于H.264等视频编码码流,接收端解码时需要基于参考帧为基础运算。数据包的丢失造成解码数据帧不完整,解码出来的图像也难以确保准确。一种常见的容错手段是,接收端向远端申请一个视频解码关键帧,发送端收到申请的信令后,编码一个视频关键帧,接收端收到了这个视频关键帧后,就能解码基于该关键帧以及往后的视频序列,使视频解码图像序列恢复正常。其中,在H.264等视频压缩标准中,视频关键帧是携带初始化解码器参数的一幅压缩图像,解码器接收到此帧图像后能解码出原图像,以及解码出基于该视频关键帧编码的压缩图像。
一般的码流模拟器没有编码关键帧的功能,因此,如何提高发送关键帧的响应效率是本申请的关键。具体的,如图6B所示,为终端模拟器接收到对端发送的视频关键帧请求时的处理流程示意图。当终端发送完一次数据包时,记录下当前数据包的在码流样本数据中的位置为A。当终端模拟器接收到来自通讯的对端发送的视频关键帧申请信令时,则终端可以从当前位置A开始往下查找,查找与位置A最近的下一个视频关键帧的位置,如果查找到,则终端跳转到这个位置,并以下一个视频关键帧对应的这个位置为起点,继续将码流样本数据按照顺序进行发送。如果未查找到,则终端跳回到码流样本数据开头的位置,重新发送数据包。其中,位置跳跃后,RTP包序列号接着上一个已发送的数据包,时间戳与同步源字段也需要相应更新。在终端读取码流样本文件查找与位置A对应的下一个视频关键帧的位置时,可以根据预设设置的文件指针来标记读到文件的哪一个位置,文件指针是预先标记好的关键帧位置的记录。比如,文件大小是5000,在1000、2000、3000位置是关键帧对应的位置,那么当文件指针读取到2500时,终端接收到对端发送的关键帧请求时,终端根据文件指针进行查找,跳转到3000这个位置,并以3000这个位置为起点,开始发送关键帧。
本实施例中,相对于传统的方式,远端每次发送视频编码关键帧请求时,都要等待一段时间才能发送视频编码关键帧数据,而本实施例中,通过预先查找所有关键帧的位置,在每次收到对端的视频编码关键帧请求时都能及时响应,无需等待,使得对端能够马上恢复图像解码,实现了快速响应视频解码关键帧申请的响应策略,从而有效提高了视频码流的测试效率。
在其中一个实施例中,如图7所示,若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到下一个视频关键帧对应的位置之后,该方法还包括对当前RTP数据包对应的RTP包序列号、时间戳以及同步源字段进行相应的更新赋值的步骤,具体包括:
步骤702,当跳转到下一个视频关键帧对应的位置时,根据上一个已发送的RTP数据包,对当前RTP数据包对应的RTP包序列号、时间戳以及同步源字段进行相应的更新赋值。
步骤704,并将更新赋值后的RTP数据包进行发送。
当终端发送完一次数据包时,记录下当前数据包的在码流样本数据中的位置为A。当终端模拟器接收到来自通讯的对端发送的视频关键帧申请信令时,则终端可以从当前位置A开始往下查找,查找与位置A对应的下一个视频关键帧的位置,如果查找到,则终端跳转到这个位置,并以这个位置为起点,继续将码流样本数据按照顺序进行发送。当跳转到下一个视频关键帧对应的位置时,终端可以根据上一个已发送的RTP数据包,对当前RTP数据包对应的RTP包序列号、时间戳以及同步源字段进行相应的更新赋值,并将更新赋值后的RTP数据包进行发送。由此使得,位置跳跃后,RTP包序列号接着上一个已发送的数据包,时间戳与同步源字段也相应更新。如果RTP协议头部的序列号字段一直保持不改变(即始终使用码流样本数据中固定的字段),那么终端发送出去的RTP协议头部的序列号字段是不连续的,MCU接收到终端发送的数据包之后,就有可能误以为有丢包,继续申请I帧容错。而本实施例中,终端模拟器每次读取一个数据包后,均需要根据下一个RTP会话对RTP协议头部的字段进行重新赋值,由此使得,能够有效的提高并发测试数量,即使出现丢包的情况下,也能够在每次收到对端的视频编码关键帧请求时都能及时响应,无需等待,使得对端能够马上恢复图像解码,实现了快速响应视频解码关键帧申请的响应策略,从而有效提高了视频码流的测试效率。
应该理解的是,虽然图1-7的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,图1-7中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中,如图8所示,提供了一种视频会议码流的测试装置,接收模块802、查找模块804和发送模块806,其中:
接收模块802,用于接收到对端发送的视频会话的呼叫请求,呼叫请求中携带预设协议。
查找模块804,用于在本地文件夹中查找与预设协议对应音视频格式的码流样本数据,码流样本数据是预先存储在本地文件夹中。
发送模块806,用于若查找到,则与对端建立呼叫连接,并将码流样本数据按照顺序进行发送。
在一个实施例中,该装置还包括:读取模块。
读取模块用于从头开始读取码流样本数据,每次读取一个RTP数据包后,重新对RTP协议头部的字段信息进行更新赋值,得到更新赋值后的RTP协议头部的字段信息;其中,RTP协议头部的字段信息包括RTP包头的序列号字段、时间戳字段以及同步源字段。发送模块还用于将更新赋值后的RTP协议头部的字段信息进行发送。
在一个实施例中,该装置还包括:判断模块。
判断模块用于判断是否读取到码流样本文件的尾部,当读取到码流样本数据尾部的最后一个数据包时,则返回到码流样本数据开头的位置,重新读取数据,并根据上一个已发送的RTP数据包,对下一个数据包的RTP协议头部的序列号字段、时间戳字段以及同步源字段进行更新赋值后再发送。
在一个实施例中,该装置还包括:记录模块。
记录模块用于当每次完成数据包的发送后,记录下当前数据包的在码流样本数据中的位置,位置用于当下一次获取到处理器的处理请求时,从码流样本数据中上次中断的位置开始发送数据包。
在一个实施例中,该装置还包括:保存模块。
保存模块用于在初始化时,抓取码流样本数据保存至本地文件夹中,码流样本数据中包括不同类型的音视频源数据格式。记录模块还用于对每一个码流样本数据进行分析,记录每一个视频关键帧在码流样本中的位置。
在一个实施例中,该装置还包括:查找模块。
查找模块用于当接收到对端发送的视频解码关键帧申请信令时,根据预先建立的不同呼叫会话对应的文件指针进行查找,文件指针用于标记每一个视频关键帧在码流样本中的位置;若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到下一个视频关键帧对应的位置,并以下一个视频关键帧对应的位置为起点,继续将码流样本数据按照顺序进行发送;若未查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳回到码流样本数据开头的位置,重新发送数据包。
在一个实施例中,该装置还包括:赋值模块。
赋值模块用于当跳转到下一个视频关键帧对应的位置时,根据上一个已发送的RTP数据包,对当前RTP数据包对应的RTP包序列号、时间戳以及同步源字段进行相应的更新赋值,并将更新赋值后的RTP数据包进行发送。
关于视频会议码流的测试装置的具体限定可以参见上文中对于视频会议码流的测试方法的限定,在此不再赘述。上述视频会议码流的测试装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提供了一种计算机设备,该计算机设备可以是终端,其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信,无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种视频会议码流的测试方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏,该计算机设备的输入装置可以是显示屏上覆盖的触摸层,也可以是计算机设备外壳上设置的按键、轨迹球或触控板,还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解,图9中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一个实施例中,提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现上述各个方法实施例的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory,ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory,RAM)或外部高速缓冲存储器。作为说明而非局限,RAM可以是多种形式,比如静态随机存取存储器(Static Random Access Memory,SRAM)或动态随机存取存储器(Dynamic Random Access Memory,DRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。
Claims (10)
1.一种视频会议码流的测试方法,所述方法包括:
接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;
在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;
若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。
2.根据权利要求1所述的方法,其特征在于,所述将所述码流样本数据按照顺序进行发送,包括:
从头开始读取所述码流样本数据,每次读取一个RTP数据包后,重新对RTP协议头部的字段信息进行更新赋值,得到更新赋值后的RTP协议头部的字段信息;其中,所述RTP协议头部的字段信息包括RTP包头的序列号字段、时间戳字段以及同步源字段;
将所述更新赋值后的RTP协议头部的字段信息进行发送。
3.根据权利要求2所述的方法,其特征在于,所述从头开始读取所述码流样本数据,每次读取一个RTP数据包之后,所述方法还包括:
判断是否读取到所述码流样本文件的尾部;
当读取到所述码流样本数据尾部的最后一个数据包时,则返回到所述码流样本数据开头的位置,重新读取数据;
并根据上一个已发送的RTP数据包,对下一个数据包的所述RTP协议头部的序列号字段、时间戳字段以及同步源字段进行更新赋值后再发送。
4.根据权利要求1所述的方法,其特征在于,所述将所述码流样本数据按照顺序进行发送包括:
当每次完成数据包的发送后,记录下当前数据包的在所述码流样本数据中的位置;所述位置用于当下一次获取到处理器的处理时间片时,从所述码流样本数据中上次中断的位置开始发送数据包。
5.根据权利要求1所述的方法,其特征在于,所述接收到对端发送的视频会话的呼叫请求之前,所述方法还包括:
在初始化时,抓取码流样本数据保存至本地文件夹中,所述码流样本数据中包括不同类型的音视频源数据格式;
对每一个所述码流样本数据进行分析,记录每一个视频关键帧在所述码流样本中的位置。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
当接收到所述对端发送的视频解码关键帧申请信令时,根据预先建立的不同呼叫会话对应的文件指针进行查找;所述文件指针用于标记每一个视频关键帧在所述码流样本中的位置;
若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到所述下一个视频关键帧对应的位置,并以所述下一个视频关键帧对应的位置为起点,继续将所述码流样本数据按照顺序进行发送;
若未查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳回到所述码流样本数据开头的位置,重新发送数据包。
7.根据权利要求6所述的方法,其特征在于,所述若查找到与当前码流位置对应的下一个视频关键帧的位置时,则跳转到所述下一个视频关键帧对应的位置之后,所述方法还包括:
当跳转到所述下一个视频关键帧对应的位置时,根据上一个已发送的RTP数据包,对当前RTP数据包对应的RTP包序列号、时间戳以及同步源字段进行相应的更新赋值;
并将更新赋值后的RTP数据包进行发送。
8.一种视频会议码流的测试装置,其特征在于,所述装置包括:
接收模块,用于接收到对端发送的视频会话的呼叫请求,所述呼叫请求中携带预设协议;
查找模块,用于在本地文件夹中查找与所述预设协议对应音视频格式的码流样本数据;所述码流样本数据是预先存储在本地文件夹中;
发送模块,用于若查找到,则与所述对端建立呼叫连接,并将所述码流样本数据按照顺序进行发送。
9.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011418543.7A CN112584134B (zh) | 2020-12-07 | 2020-12-07 | 视频会议码流的测试方法、装置、计算机设备和存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011418543.7A CN112584134B (zh) | 2020-12-07 | 2020-12-07 | 视频会议码流的测试方法、装置、计算机设备和存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112584134A true CN112584134A (zh) | 2021-03-30 |
CN112584134B CN112584134B (zh) | 2022-10-21 |
Family
ID=75127988
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011418543.7A Active CN112584134B (zh) | 2020-12-07 | 2020-12-07 | 视频会议码流的测试方法、装置、计算机设备和存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112584134B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113612962A (zh) * | 2021-07-15 | 2021-11-05 | 深圳市捷视飞通科技股份有限公司 | 视频会议处理方法、系统和装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100220787A1 (en) * | 2009-03-02 | 2010-09-02 | Oki Electric Industry Co., Ltd. | Video encoding and decoding apparatus, method, and system |
CN104394117A (zh) * | 2014-03-10 | 2015-03-04 | 贵阳朗玛信息技术股份有限公司 | Rtp包的传输方法及装置 |
CN109167750A (zh) * | 2018-07-06 | 2019-01-08 | 北京金山安全软件有限公司 | 一种数据包传输方法、装置、电子设备及存储介质 |
CN109905697A (zh) * | 2019-02-27 | 2019-06-18 | 苏州科达科技股份有限公司 | 视频会议测试方法、装置及存储介质 |
-
2020
- 2020-12-07 CN CN202011418543.7A patent/CN112584134B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100220787A1 (en) * | 2009-03-02 | 2010-09-02 | Oki Electric Industry Co., Ltd. | Video encoding and decoding apparatus, method, and system |
CN104394117A (zh) * | 2014-03-10 | 2015-03-04 | 贵阳朗玛信息技术股份有限公司 | Rtp包的传输方法及装置 |
CN109167750A (zh) * | 2018-07-06 | 2019-01-08 | 北京金山安全软件有限公司 | 一种数据包传输方法、装置、电子设备及存储介质 |
CN109905697A (zh) * | 2019-02-27 | 2019-06-18 | 苏州科达科技股份有限公司 | 视频会议测试方法、装置及存储介质 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113612962A (zh) * | 2021-07-15 | 2021-11-05 | 深圳市捷视飞通科技股份有限公司 | 视频会议处理方法、系统和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN112584134B (zh) | 2022-10-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8649278B2 (en) | Method and system of multimedia service performance monitoring | |
WO2020006912A1 (zh) | 网络传输质量分析方法、装置、计算机设备和存储介质 | |
TW201328332A (zh) | 提供與傳送複合濃縮串流之方法以及系統 | |
EP2924998A1 (en) | Method, apparatus and system for acquiring playback data stream of real-time video communication | |
JP2020184805A (ja) | ビデオサービス品質の評価方法及び装置 | |
CN112073543B (zh) | 一种云视频录制方法、系统和可读存储介质 | |
Lei et al. | Design and implementation of streaming media processing software based on RTMP | |
WO2018028547A1 (zh) | 频道切换的方法及装置 | |
CN110662017B (zh) | 一种视频播放质量检测方法和装置 | |
Vega et al. | Enabling virtual reality for the tactile Internet: Hurdles and opportunities | |
JP5651558B2 (ja) | 管理サーバ、映像配信制御システム及び映像配信制御方法 | |
EP3399713B1 (en) | Device, system, and method to perform real-time communication | |
CN114071131B (zh) | 用于视频编解码设备的测试装置、方法、电子设备和介质 | |
CN112584134B (zh) | 视频会议码流的测试方法、装置、计算机设备和存储介质 | |
JP6116240B2 (ja) | 送信装置、送信方法、及びプログラム | |
CN104486665A (zh) | 移动终端的远程协助方法及装置 | |
EP2405649B1 (en) | Method and terminal for synchronously recording sounds and images of opposite ends based on circuit domain video telephone | |
JP2012195831A (ja) | 送信装置及び送信方法、並びにプログラム | |
CN108012085B (zh) | 一种多媒体信息处理方法、服务器及存储介质 | |
CN113612962A (zh) | 视频会议处理方法、系统和装置 | |
Wu et al. | Monitoring video resolution of adaptive encrypted video traffic based on HTTP/2 features | |
US11265357B2 (en) | AV1 codec for real-time video communication | |
EP3891962B1 (en) | Synchronized jitter buffers to handle codec switches | |
TW201441935A (zh) | 視訊截圖系統及方法 | |
CN101296166A (zh) | 基于索引的多媒体数据的测量方法 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
PE01 | Entry into force of the registration of the contract for pledge of patent right | ||
PE01 | Entry into force of the registration of the contract for pledge of patent right |
Denomination of invention: Testing methods, devices, computer equipment, and storage media for video conference bitstreams Effective date of registration: 20230912 Granted publication date: 20221021 Pledgee: Guangxi Guangtou Zhanxin Investment Fund Partnership Enterprise (L.P.) Pledgor: IFREECOMM TECHNOLOGY Co.,Ltd. Registration number: Y2023980056247 |