CN113573003A - 一种基于弱网的音视频实时通信方法、装置以及设备 - Google Patents
一种基于弱网的音视频实时通信方法、装置以及设备 Download PDFInfo
- Publication number
- CN113573003A CN113573003A CN202110920355.2A CN202110920355A CN113573003A CN 113573003 A CN113573003 A CN 113573003A CN 202110920355 A CN202110920355 A CN 202110920355A CN 113573003 A CN113573003 A CN 113573003A
- Authority
- CN
- China
- Prior art keywords
- packet loss
- packet
- rtcp
- rate
- request
- 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
- H04N7/00—Television systems
- H04N7/14—Systems for two-way working
- H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种基于弱网的音视频实时通信方法,所述方法包括:接收发送端发送的流媒体数据和RR包;对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放;对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项;通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。能够实现在配置相对低端设备下保证弱网视频通话质量、提高用户的会话体验。
Description
技术领域
本发明涉及音视频通信技术领域,尤其涉及一种基于弱网的音视频实时通信方法、装置以及设备。
背景技术
目前开源大都是基于PC机进行设计的,其框架都比较庞大。现有主流音视频框架如ffmpeg、webRTC等等,一方面是整体项目庞大包括库的大小,对内存和CPU有较高的要求,而在低内存和CPU性能情况下对于弱网视频质量条件比较严苛,实现一个相对完整的弱网解决方案难度较大;另一方面大量采用了STL标准库函数,不适用于低配置Linux嵌入式终端产品,而低配置设备对于弱网下音视频解决方案比较单一,部分只能支持简单的丢包重传功能,弱网对抗效果比较一般。因此,现有方案中的低配置设备无法在弱网下提供比较好的音视频通话效果。
发明内容
有鉴于此,本发明的目的在于提出一种基于弱网的音视频实时通信方法、装置以及设备,能够实现在配置相对低端设备下保证弱网视频通话质量、提高用户的会话体验。
为实现上述目的,本发明提供一种基于弱网的音视频实时通信方法,所述方法包括:
接收发送端发送的流媒体数据和RR包;
对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放;
对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项;
通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。
优选的,所述对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放的步骤包括:
对所述流媒体数据的序列号进行丢包统计得到丢包队列,并将所述丢包队列发送至所述第一RTCP以生成NACK请求;
根据所述丢包队列判断是否达到丢包预设值,和/或对所述解码进行分析是否存在解码错误,是则发送至所述第一RTCP以生成关键帧PLI请求。
优选的,所述对所述流媒体数据的序列号进行丢包统计得到丢包队列的步骤包括:
当接收到旧包到达时将对应的序列号从所述丢包队列中移除。
优选的,在所述对所述RR包进行往返时间RTT和丢包率统计之后,还包括:
根据所述丢包率和往返时间RTT、以及对所获取的所述流媒体数据的数据大小和接收时间进行处理,得到当前带宽的预测码率并发送至所述第一RTCP以生成REMB请求。
优选的,所述处理进一步包括:
利用卡尔曼滤波或神经网络进行处理。
优选的,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
若收到所述NACK请求时,则解析所述丢包队列后检查每个序列号是否过时、当前重传的流量是否超过预设流量,是则进一步检查所述丢包队列是否存在于缓存队列中,是则重传对应的流量包。
优选的,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
若收到所述关键帧PLI请求时,则判断是否存在短时间多次请求,是则向解码器请求生成关键帧进行发送。
优选的,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
若收到所述REMB请求时,则根据所述REMB请求解析出速率值,并根据所述丢包率和往返时间RTT通过TFRC进行计算得到发送速率值的下限;
根据所述丢包率、所述往返时间RTT以及所述速率值对所述发送速率值进行修正,并基于预设速率范围计算所述当前带宽的码率和分辨率发送至解码器进行修改。
为实现上述目的,本发明还提供一种基于弱网的音视频实时通信装置,所述装置包括:
接收单元,用于接收发送端发送的流媒体数据和RR包;
组装单元,用于对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放;
监控单元,用于对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项;
修正单元,用于通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。
为实现上述目的,本发明还提供一种基于弱网的音视频实时通信设备,包括处理器、存储器以及存储在所述存储器内的计算机程序,所述计算机程序能够被所述处理器执行以实现如上述实施例所述的一种基于弱网的音视频实时通信方法。
有益效果:
以上方案,通过采用自研的RTCP对于流量控制、丢包请求等进行统一控制,整体设计紧凑,且对于***的flash占用小、内存和cpu消耗更少,通过简化内部实现,只针对特定的弱网功能提供相应的支持,减少不必要的开销,使得整体更为轻量化,响应更为快速,适用于各种配置相对小的Linux终端设备使用,保证了弱网视频的质量提升。
以上方案,利用丢包重传、关键帧请求、带宽预测、动态码率和帧率保证了弱网下视频通话的质量,低带宽下实现了高延迟和丢包下视频流畅的播放。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明一实施例提供的一种基于弱网的音视频实时通信方法的流程示意图。
图2为本发明一实施例提供的辅助处理***的结构示意图。
图3为本发明一实施例提供的一种基于弱网的音视频实时通信装置的结构示意图。
图4为本发明一实施例提供的基于弱网的音视频实时通信设备的结构示意图。
发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
为使本发明实施方式的目的、技术方案和优点更加清楚,下面将结合本发明实施方式中的附图,对本发明实施方式中的技术方案进行清楚、完整地描述,显然,所描述的实施方式是本发明一部分实施方式,而不是全部的实施方式。基于本发明中的实施方式,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式,都属于本发明保护的范围。因此,以下对在附图中提供的本发明的实施方式的详细描述并非旨在限制要求保护的本发明的范围,而是仅仅表示本发明的选定实施方式。基于本发明中的实施方式,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式,都属于本发明保护的范围。
在本发明的描述中,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
以下结合实施例详细阐述本发明的内容。
现有中一般只有高配置设备才能提供音视频弱网对抗的解决方案,大部分的低配置设备无法在弱网下提供比较好的音视频通话效果。由于很多弱网方案都是移植开源webRTC库或者进行二次优化,整体比较冗余,并不是适合特定场景下的弱网对抗。而移植开源项目整体开发周期较为短,但是也引入了很多冗余功能增加***资源消耗,***相对复杂,数据处理和响应周期更长,不适用于一些特定视频通话场景。因此,本方案通过提出了一种轻量化的Linux终端弱网视频通话的解决方案,利用C/C++代码实现这个算法具有更为广泛的平台适用性,嵌入到现成的C或者C++语言构建的音视频框架即可使用。能够对于弱网下的丢包、抖动、时延都有比较好的支持,能够很好的保证弱网下音视频通话质量。
需要说明的是,本申请实施例提出的通信方法、通信装置以及辅助处理***应用于部署有简易的音视频框架(如FFmpeg或webRTC)的终端中。
参照图1所示为本发明实施例提供的一种基于弱网的音视频实时通信方法的流程示意图。
本实施例中,该通信方法基于辅助处理***实现,其中,辅助处理***可参见图2所示。通过本申请提出的通信方法可以辅助提升现有音视频框架弱网下的音视频通话质量。
其中,该通信方法包括:
S11,接收发送端发送的流媒体数据和RR包。
S12,对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放。
其中,所述对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放的步骤包括:
S12-1,对所述流媒体数据的序列号进行丢包统计得到丢包队列,并将所述丢包队列发送至所述第一RTCP以生成NACK请求;
S12-2,根据所述丢包队列判断是否达到丢包预设值,和/或对所述解码进行分析是否存在解码错误,是则发送至所述第一RTCP以生成关键帧PLI请求。
在本实施例中,接收来自发送端的流媒体数据,对流媒体数据进行重新排列并组装有效的视频帧。而对于不完整的视频帧通过等待一定时间保证视频帧的正确接收。根据流媒体的序列号进行统计得到丢包队列,当接收到旧包到达时将对应的序列号从丢包队列中移除,以确保视频帧的流畅、避免冗余重复。并将丢包队列发送至第一RTCP以生成NACK请求,其中,第一RTCP为接收端RTCP,第二RTCP为发送端RTCP。根据当前丢包队列的丢包量判断是否达到预设的丢包容量值,判断在解码时是否存在解码错误,判断抖动缓冲区所存储的流媒体数据是否超出存储预设值,若是则发送至第一RTCP以生成关键帧PLI请求。
S13,对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项。
进一步根据所述丢包率和往返时间RTT、以及对所获取的所述流媒体数据的数据大小和接收时间进行卡尔曼滤波处理,得到当前带宽的预测码率并发送至所述第一RTCP以生成REMB请求。
在本实施例中,接收发送端的RR包进行往返时间RTT和丢包统计,同时定时检查是否需要发送关键帧PLI请求、是否需要发送NACK请求、是否需要发送REMB包、是否需要发送SR包等等。
S14,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。
其中,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
S14-1,若收到所述NACK请求时,则解析所述丢包队列后检查每个序列号是否过时、当前重传的流量是否超过预设流量,是则进一步检查所述丢包队列是否存在于缓存队列中,是则重传对应的流量包。
S14-2,若收到所述关键帧PLI请求时,则判断是否存在短时间多次请求,是则向解码器请求生成关键帧进行发送。
S14-3,若收到所述REMB请求时,则根据所述REMB请求解析出速率值,并根据所述丢包率和往返时间RTT通过TFRC进行计算得到发送速率值的下限;
根据所述丢包率、所述往返时间RTT以及所述速率值对所述发送速率值进行修正,并基于预设速率范围计算所述当前带宽的码率和分辨率发送至解码器进行修改。
本申请通过采用自研的弱网对抗方案,整体的代码体积控制在300k以内,同时整合到音视频框架内新增flash大小在300k以内,运行时前后对比对于整体的内存用量在3M以内,实现了更低的内存用量和代码体积。同时大部分的组件采用纯C编写,不依赖与于标准的STL库,方便移植到其他平台进行实现。低配置的Linux终端设备能够在4CIF分辨率、1024kb码率下视频通话,当丢包30%和延迟800ms的弱网下视频可以正常播放。主要通过采用自研的RTCP,对于流量控制、丢包请求进行统一控制,整体设计紧凑,支持主流SR、RR、BYE、NACK、PLI、REMB等协议报文。另外,本申请还实现了主流弱网对抗的丢包重传、网络带宽预测、视频抖动缓冲区、动态码率和动态分辨率等功能,对于弱网下视频质量有很好的提升。
在图2中,该辅助处理***包括接收端和发送端,其中,接收端包括抖动缓冲区组件M1、丢包统计组件M2、关键帧请求组件M3、接收端速率估算组件M4、第一RTCP组件M5;发送端包括第二RTCP组件M6、丢包重传组件M7、关键帧重传组件M8、发送端速率估算组件M9、动态分辨率、码率组件M10。具体的:
抖动缓冲区组件M1:接收来自发送端的流媒体数据,对流媒体数据包进行重新排列,并组装有效的视频帧,对于不完整的视频帧通过等待一定时间保证视频帧的正确接收,同时将流媒体序列号发送给M2。
丢包统计组件M2:根据接收的流媒体序列号进行统计得到丢包队列,当接收到旧包到达时将序列号从队列移除,并将丢包队列传送给M5。
关键帧请求组件M3:判断当前是否达到丢包容量最大值,是否出现解码错误,是否抖动缓冲区存储超出最大包等信息,通知M5发送关键帧PLI请求。
接收端速率估算组件M4:根据M5接收到RTCP RR数据包得到丢包率、往返时间,同时接收流媒体包的数据大小和接收时间进行卡尔曼滤波最终得到一个对于当前带宽的码率预测值并传给M5。
RTCP接收端组件M5:接收发送端M6的RR包进行往返时间RTT和丢包统计,同时定时检查是否需要发送关键帧PLI请求,是否需要发送NACK请求,是否需要发送REMB包,是否需要发送SR包等等,进行统一发送给发送端的M6。
RTCP发送端组件M6:接收到RTCP包进行解析,根据SR包回复RR包同时根据不同请求解析触发不同的回调函数,对于NACK请求,解析丢包列表传送给M7;对于关键帧PLI请求,传送给M8;对于REMB请求,解析预测码率传送给M9。
丢包重传组件M7:缓冲一定数量的流媒体数据包,当接收到丢包队列时,分别检查每个序列号是否过时,检查当前重传的流量是否超过媒体流量,如果都符合条件,进而检查是否存在缓存队列中,如果存在则重传该流量包。
关键帧重传组件M8:接收到关键帧请求后,先判断是否存在短时间多次请求,如果满足条件则向解码器请求生成关键帧发送。
发送端速率估算组件M9:根据接收到的REMB解析出来的估算速率,同时根据接收到丢包率和往返时间RTT利用TFRC计算公式得到发送速率的下限,并且根据当前的丢包速率对于接收的带宽估计进行修正,并将最终的发送端速率、丢包率、RTT传送给M10。
动态分辨率、码率组件M10:根据接收到的速率值、丢包率、RTT进行速率值修正,并且最终根据速率范围利用经验表最终得到当前带宽下的最适码率和分辨率,通知解码器修改当前发送的码率和分辨率。
具体的,将接收端音视频流引入M1进行抖动对抗,并将M1视频帧加入到接收端解码器进行解码播放;同时发送端需要将编码器发送数据接入到M7进行流媒体包的缓存,并且M8请求关键帧和M10修改分辨率和码率需要作用到发送端编码器进行修改生效。特别的,在上述中M4和M10采用的算法还可以用深度学习的神经网络来预测结果进行替换。通过上述卡尔曼滤波或神经网络能够使得带宽预测与动态分辨率正确性更高,从而进一步提升整个会话的性能。
参照图3所示为本发明实施例提供的一种基于弱网的音视频实时通信装置的结构示意图。
本实施例中,该装置30包括:
接收单元31,用于接收发送端发送的流媒体数据和RR包;
组装单元32,用于对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放;
监控单元33,用于对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项;
修正单元34,用于通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。
其中,所述组装单元32,还包括:
第一生成单元,用于对所述流媒体数据的序列号进行丢包统计得到丢包队列,并将所述丢包队列发送至所述第一RTCP以生成NACK请求;
第二生成单元,用于根据所述丢包队列判断是否达到丢包预设值,和/或对所述解码进行分析是否存在解码错误,是则发送至所述第一RTCP以生成关键帧PLI请求。
其中,所述第一生成单元,还用于:
当接收到旧包到达时将对应的序列号从所述丢包队列中移除。
其中,所述监控单元33,还包括:
第三生成单元,用于根据所述丢包率和往返时间RTT、以及对所获取的所述流媒体数据的数据大小和接收时间进行处理,得到当前带宽的预测码率并发送至所述第一RTCP以生成REMB请求。其中,所述处理进一步包括:利用卡尔曼滤波或神经网络进行处理。
其中,所述修正单元34,还用于:
若收到所述NACK请求时,则解析所述丢包队列后检查每个序列号是否过时、当前重传的流量是否超过预设流量,是则进一步检查所述丢包队列是否存在于缓存队列中,是则重传对应的流量包。
其中,所述修正单元34,还用于:
若收到所述关键帧PLI请求时,则判断是否存在短时间多次请求,是则向解码器请求生成关键帧进行发送。
其中,所述修正单元34,还用于:
若收到所述REMB请求时,则根据所述REMB请求解析出速率值,并根据所述丢包率和往返时间RTT通过TFRC进行计算得到发送速率值的下限;
根据所述丢包率、所述往返时间RTT以及所述速率值对所述发送速率值进行修正,并基于预设速率范围计算所述当前带宽的码率和分辨率发送至解码器进行修改。
该装置30的各个单元模块可分别执行上述方法实施例中对应步骤,故在此不对各单元模块进行赘述,详细请参见以上对应步骤的说明。
本发明实施例还提供一种基于弱网的音视频实时通信设备,包括处理器、存储器以及存储在所述存储器内的计算机程序,所述计算机程序能够被所述处理器执行以实现如上述实施例所述的基于弱网的音视频实时通信方法。
如图4所示,所述基于弱网的音视频实时通信设备可包括但不仅限于处理器、存储器。本领域技术人员可以理解,所述示意图仅仅是基于弱网的音视频实时通信设备的示例,并不构成对基于弱网的音视频实时通信设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如所述基于弱网的音视频实时通信设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,所述基于弱网的音视频实时通信设备的控制中心,利用各种接口和线路连接整个基于弱网的音视频实时通信设备的各个部分。
所述存储器可用于存储所述计算机程序和/或模块,所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块,以及调用存储在存储器内的数据,实现所述基于弱网的音视频实时通信设备的各种功能。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘,智能存储卡(Smart MediaCard,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
其中,所述基于弱网的音视频实时通信设备集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实现上述实施例方法中的全部或部分流程,也可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。
需说明的是,以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外,本发明提供的装置实施例附图中,模块之间的连接关系表示它们之间具有通信连接,具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例中的实施方案可以进一步组合或者替换,且实施例仅仅是对本发明的优选实施例进行描述,并非对本发明的构思和范围进行限定,在不脱离本发明设计思想的前提下,本领域中专业技术人员对本发明的技术方案作出的各种变化和改进,均属于本发明的保护范围。
Claims (10)
1.一种基于弱网的音视频实时通信方法,其特征在于,所述方法包括:
接收发送端发送的流媒体数据和RR包;
对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放;
对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项;
通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。
2.根据权利要求1所述的一种基于弱网的音视频实时通信方法,其特征在于,所述对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放的步骤包括:
对所述流媒体数据的序列号进行丢包统计得到丢包队列,并将所述丢包队列发送至所述第一RTCP以生成NACK请求;
根据所述丢包队列判断是否达到丢包预设值,和/或对所述解码进行分析是否存在解码错误,是则发送至所述第一RTCP以生成关键帧PLI请求。
3.根据权利要求2所述的一种基于弱网的音视频实时通信方法,其特征在于,所述对所述流媒体数据的序列号进行丢包统计得到丢包队列的步骤包括:
当接收到旧包到达时将对应的序列号从所述丢包队列中移除。
4.根据权利要求1所述的一种基于弱网的音视频实时通信方法,其特征在于,在所述对所述RR包进行往返时间RTT和丢包率统计之后,还包括:
根据所述丢包率和往返时间RTT、以及对所获取的所述流媒体数据的数据大小和接收时间进行处理,得到当前带宽的预测码率并发送至所述第一RTCP以生成REMB请求。
5.根据权利要求4所述的一种基于弱网的音视频实时通信方法,其特征在于,所述处理进一步包括:
利用卡尔曼滤波或神经网络进行处理。
6.根据权利要求2所述的一种基于弱网的音视频实时通信方法,其特征在于,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
若收到所述NACK请求时,则解析所述丢包队列后检查每个序列号是否过时、当前重传的流量是否超过预设流量,是则进一步检查所述丢包队列是否存在于缓存队列中,是则重传对应的流量包。
7.根据权利要求2所述的一种基于弱网的音视频实时通信方法,其特征在于,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
若收到所述关键帧PLI请求时,则判断是否存在短时间多次请求,是则向解码器请求生成关键帧进行发送。
8.根据权利要求4所述的一种基于弱网的音视频实时通信方法,其特征在于,通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传的步骤包括:
若收到所述REMB请求时,则根据所述REMB请求解析出速率值,并根据所述丢包率和往返时间RTT通过TFRC进行计算得到发送速率值的下限;
根据所述丢包率、所述往返时间RTT以及所述速率值对所述发送速率值进行修正,并基于预设速率范围计算所述当前带宽的码率和分辨率发送至解码器进行修改。
9.一种基于弱网的音视频实时通信装置,其特征在于,所述装置包括:
接收单元,用于接收发送端发送的流媒体数据和RR包;
组装单元,用于对所述流媒体数据进行重新排列并组装有效的视频帧,将所述视频帧进行解码播放;
监控单元,用于对所述RR包进行往返时间RTT和丢包率统计,并基于预设时间通过第一RTCP对网络参数进行监控是否生成请求发送至所述发送端,其中,所述网络参数包括关键帧PLI、NACK、REMB包和SR包中的至少一项;
修正单元,用于通过第二RTCP根据不同的所述请求触发对应的回调函数,通过所述回调函数动态修正编码器的相关值和丢包数据的重传。
10.一种基于弱网的音视频实时通信设备,其特征在于,包括处理器、存储器以及存储在所述存储器内的计算机程序,所述计算机程序能够被所述处理器执行以实现如权利要求1至8任意一项所述的一种基于弱网的音视频实时通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110920355.2A CN113573003B (zh) | 2021-08-11 | 2021-08-11 | 一种基于弱网的音视频实时通信方法、装置以及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110920355.2A CN113573003B (zh) | 2021-08-11 | 2021-08-11 | 一种基于弱网的音视频实时通信方法、装置以及设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113573003A true CN113573003A (zh) | 2021-10-29 |
CN113573003B CN113573003B (zh) | 2023-08-01 |
Family
ID=78171345
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110920355.2A Active CN113573003B (zh) | 2021-08-11 | 2021-08-11 | 一种基于弱网的音视频实时通信方法、装置以及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113573003B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114513474A (zh) * | 2022-02-08 | 2022-05-17 | 聚好看科技股份有限公司 | 视频发送方法、视频发送终端、媒体服务器及存储介质 |
CN115277654A (zh) * | 2022-07-19 | 2022-11-01 | 宁波菊风***软件有限公司 | 一种rtc***的带宽资源分配*** |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101931632A (zh) * | 2010-09-21 | 2010-12-29 | 天地阳光通信科技(北京)有限公司 | 一种利用实时传输协议通道进行服务质量保证的方法 |
CN103581767A (zh) * | 2012-07-24 | 2014-02-12 | 鸿富锦精密工业(深圳)有限公司 | 视频质量调节***、终端及方法 |
CN105306888A (zh) * | 2015-10-03 | 2016-02-03 | 上海大学 | 基于丢包区分的移动视频监控带宽自适应方法 |
CN107438031A (zh) * | 2017-08-07 | 2017-12-05 | 成都三零凯天通信实业有限公司 | 多信道自适应网络带宽的音视频流传输控制方法及*** |
CN113099310A (zh) * | 2021-04-08 | 2021-07-09 | 李蕊男 | 基于安卓平台的实时媒体内视音频协调法 |
-
2021
- 2021-08-11 CN CN202110920355.2A patent/CN113573003B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101931632A (zh) * | 2010-09-21 | 2010-12-29 | 天地阳光通信科技(北京)有限公司 | 一种利用实时传输协议通道进行服务质量保证的方法 |
CN103581767A (zh) * | 2012-07-24 | 2014-02-12 | 鸿富锦精密工业(深圳)有限公司 | 视频质量调节***、终端及方法 |
CN105306888A (zh) * | 2015-10-03 | 2016-02-03 | 上海大学 | 基于丢包区分的移动视频监控带宽自适应方法 |
CN107438031A (zh) * | 2017-08-07 | 2017-12-05 | 成都三零凯天通信实业有限公司 | 多信道自适应网络带宽的音视频流传输控制方法及*** |
CN113099310A (zh) * | 2021-04-08 | 2021-07-09 | 李蕊男 | 基于安卓平台的实时媒体内视音频协调法 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114513474A (zh) * | 2022-02-08 | 2022-05-17 | 聚好看科技股份有限公司 | 视频发送方法、视频发送终端、媒体服务器及存储介质 |
CN114513474B (zh) * | 2022-02-08 | 2024-03-05 | 聚好看科技股份有限公司 | 视频发送方法、视频发送终端、媒体服务器及存储介质 |
CN115277654A (zh) * | 2022-07-19 | 2022-11-01 | 宁波菊风***软件有限公司 | 一种rtc***的带宽资源分配*** |
CN115277654B (zh) * | 2022-07-19 | 2024-02-27 | 宁波菊风***软件有限公司 | 一种rtc***的带宽资源分配*** |
Also Published As
Publication number | Publication date |
---|---|
CN113573003B (zh) | 2023-08-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Wu et al. | Enabling adaptive high-frame-rate video streaming in mobile cloud gaming applications | |
RU2634908C2 (ru) | Способ и устройство для управления доставкой медиаданных | |
US8127040B2 (en) | Signaling buffer parameters indicative of receiver buffer architecture | |
US11792130B2 (en) | Audio/video communication method, terminal, server, computer device, and storage medium | |
CN111147606B (zh) | 数据传输的方法、装置、终端及存储介质 | |
CN105451071B (zh) | 一种视频流的处理方法、装置和*** | |
KR20120042833A (ko) | 역방향의 강력한 헤더 압축 수신기 | |
CN113573003A (zh) | 一种基于弱网的音视频实时通信方法、装置以及设备 | |
CN109379620B (zh) | 音视频缓冲方法和装置 | |
CN110740380A (zh) | 视频处理方法和装置、存储介质及电子装置 | |
CN113727185B (zh) | 视频帧播放方法及*** | |
CN114221909B (zh) | 数据传输方法、装置、终端及存储介质 | |
EP3096524A1 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
EP3127289B1 (en) | Method and apparatus for signaling and operation of low delay consumption of media data in mmt | |
KR102118678B1 (ko) | 부호화된 비디오 스트림 전송 장치 및 방법 | |
EP3096525A1 (en) | Communication apparatus, communication data generation method, and communication data processing method | |
CN116318545A (zh) | 视频数据传输方法、装置、设备及存储介质 | |
CN112153322B (zh) | 数据分发方法、装置、设备及存储介质 | |
CN110855645B (zh) | 流媒体数据播放方法、装置 | |
CN106534137B (zh) | 媒体流传输方法及装置 | |
CN112165655A (zh) | 基于视联网的数据传输方法、装置、设备及介质 | |
CN115942000B (zh) | H.264格式的视频流转码方法及装置、设备及介质 | |
CN115086285B (zh) | 一种数据处理方法、装置、存储介质及电子设备 | |
CN114900716B (zh) | 云视频数据的传输方法、云平台、云终端及介质 | |
WO2022228037A1 (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 |