CN113645177A - 可靠传输网络中维持实时音讯串流播放延迟的方法及系统 - Google Patents
可靠传输网络中维持实时音讯串流播放延迟的方法及系统 Download PDFInfo
- Publication number
- CN113645177A CN113645177A CN202010394336.6A CN202010394336A CN113645177A CN 113645177 A CN113645177 A CN 113645177A CN 202010394336 A CN202010394336 A CN 202010394336A CN 113645177 A CN113645177 A CN 113645177A
- Authority
- CN
- China
- Prior art keywords
- audio packet
- time
- audio
- playing
- delay
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/131—Protocols for games, networked simulations or virtual reality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/062—Synchronisation of signals having the same nominal but fluctuating bit rates, e.g. using buffers
- H04J3/0632—Synchronisation of packets and cells, e.g. transmission of voice via a packet network, circuit emulation service [CES]
-
- 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/80—Responding to QoS
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Hardware Design (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开一种可靠传输网络中维持实时音讯串流播放延迟的方法及系统。方法包含以下步骤:推算音讯封包的接收时间;检测音讯封包实际的接收时间是否早于所推算的接收时间,若是,定义最小延迟音讯封包,若否,计数检测次数;判断检测次数是否等于预设次数,若否,回到第一步骤,若是,定义最小延迟音讯封包,基于最小延迟音讯封包的接收时间、系统固定延迟时间以及音讯封包的时间长度,推算各音讯封包的开始播放时间;以及判断音讯封包的开始播放时间未超过预定开始播放时间时,播放音讯封包。
Description
技术领域
本发明涉及音讯串流播放,特别是涉及一种可靠传输网络中维持实时音讯串流播放延迟的方法及系统。
背景技术
近年来使用蓝牙耳机连接手机或电视机来观赏视频与玩游戏,对于影音同步的问题格外重视。
连续的音讯数据流在发送端(手机或电视机)切割成一个个区块并压缩后,组成音讯封包经由有线或无线网络传送到接收端(耳机),然后在接收端将音讯封包重组并解压缩后,还原成连续音讯数据后播放出来。
而在网络传输过程中常因网络壅塞,干扰和丢失重送等各种原因,造成每个音讯封包由发送端至接收端的延迟时间抖动(jitter),因此接收端不能在收到音讯封包后立即播放,以免因后续音讯封包延迟过久造成播放中断,而必须用一个抖动缓冲区(jitterbuffer)来缓解。jitter buffer的大小必须取一适当值,值越大可以忍受较大的延迟抖动,相对的播放延迟也会变大。
一般网络传输方式可分为最大努力(best effort)和可靠的(reliable)二种,在reliable网络传输方式,当音讯封包丢失时发送端会重送(re-transmission)该音讯封包以确保接收端收到完整数据。由于音讯封包可能经过多次重送,传送延迟也可能大幅增加。因此在传送音讯数据时发送端会维持一个较大的传送队列(transmission queue),当网络壅塞时音讯封包可先累积在传送队列中,等网络恢复顺畅后再将传送队列中的音讯封包迅速传出。
在best effort网络传输方式,音讯封包允许丢失而不需重送,因此不需要大的传送队列,传送延迟较小,适用于需要低延迟但不需要高音质的应用,例如VOIP。而reliable网络传输方式因音讯封包不会丢失,适用于需要高音质但允许较高延迟的应用,例如播放音乐和看电影。
在观赏视频与玩游戏这些应用,使用者希望高音质并且能达到低延迟,就必须采用reliable网络传输方式,并且尽量压低接收端的jitter buffer不超过如150ms,以免影音不同步。一般的做法是开始播放前收到的音讯封包后先放入jitter buffer,等到jitterbuffer内的音讯封包累积到一定的数量后才由jitter buffer取出音讯封包开始播放。当碰到网络壅塞刚纾解时,由于发送端传送队列累积的大量音讯封包可能发生传送大爆发(transmission burst),迅速将接收端的jitter buffer填满并超出许多,以这种做法播放延迟就会大幅超过预定的150ms。
发明内容
本发明所要解决的技术问题在于,针对现有技术的不足提供一种可靠传输网络中维持实时音讯串流播放延迟的方法,适用于从发送端依序接收多个音讯封包的接收端。可靠传输网络中维持实时音讯串流播放延迟的方法包含以下步骤:(a)将已接收到的音讯封包的接收时间作为推算基准,以推算下一音讯封包的接收时间;(b)检测下一音讯封包实际的接收时间是否早于所推算的接收时间,若是,将下一音讯封包定义为一最小传送延迟音讯封包,并将一检测次数归零,接着回到步骤(a)基于最小传送延迟音讯封包推算最小传送延迟音讯封包的下一音讯封包,若否,计数检测次数,接着执行下一步骤(c);(c)判断检测次数是否等于一预设检测次数,若否,回到步骤(a)以推算又下一个音讯封包,若是,将作为推算基准的音讯封包定义为最小传送延迟音讯封包,接着执行下一步骤(d);(d)将最小传送延迟音讯封包的接收时间加上一系统固定延迟时间,以推算最小传送延迟音讯封包的一开始播放时间;(e)基于最小传送延迟音讯封包的开始播放时间以及各音讯封包播放的时间长度,推算其他各音讯封包的开始播放时间;以及(f)判断各音讯封包的开始播放时间是否已超过一预定开始播放时间,若是,丢掉各音讯封包,若否,在到达开始播放时间时,播放各音讯封包。
在一实施方案中,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,减去在最小传送延迟音讯封包之前接收的所有音讯封包播放的时间长度,以推算最早接收到的音讯封包的开始播放时间。
在一实施方案中,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,减去欲推算的音讯封包播放的时间长度、在最小传送延迟音讯封包之前并在欲推算的音讯封包之后接收的所有音讯封包播放的时间长度,以推算音讯封包的开始播放时间。
在一实施方案中,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,减去最小传送延迟音讯封包前一个接收的音讯封包播放的时间长度,以推算最小传送延迟音讯封包前一个接收到的音讯封包的开始播放时间,以推算最小传送延迟音讯封包前一个接收到的音讯封包的开始播放时间。
在一实施方案中,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,加上最小传送延迟音讯封包播放的时间长度,以推算最小传送延迟音讯封包下一个接收到的音讯封包的开始播放时间。
另外,本发明提供一种可靠传输网络中维持实时音讯串流播放延迟的系统,适用于从发送端依序接收多个音讯封包的接收端。可靠传输网络中维持实时音讯串流播放延迟的系统包含最小延迟检测模块、检测计数模块、检测阀值设定模块、播放时间推算模块以及音讯封包筛选模块。最小延迟检测模块配置以将已接收到的音讯封包的接收时间作为推算基准,以推算下一音讯封包的接收时间。最小延迟检测模块配置以检测到下一音讯封包实际的接收时间早于所推算的接收时间时,将下一音讯封包定义为一最小传送延迟音讯封包。检测计数模块连接最小延迟检测模块。检测计数模块配置以在下一音讯封包实际的接收时间晚于所推算的接收时间时,计数一检测次数,而在找到最小传送延迟音讯封包时,将检测次数归零。检测阀值设定模块连接最小延迟检测模块以及检测计数模块。检测阀值设定模块配置以判断检测次数未等于一预设检测次数时,指示最小延迟检测模块检测后续接收到的音讯封包以找寻最小传送延迟音讯封包。检测阀值设定模块配置以判断检测次数等于预设检测次数且未找到最小传送延迟音讯封包时,指示最小延迟检测模块直接将作为推算基准的音讯封包定义为最小传送延迟音讯封包。播放时间推算模块连接最小延迟检测模块。播放时间推算模块配置以将最小传送延迟音讯封包实际的接收时间加上系统固定延迟时间,以推算最小传送延迟音讯封包的一开始播放时间,并基于最小传送延迟音讯封包的开始播放时间以及各音讯封包播放的时间长度,推算其他各音讯封包的开始播放时间。音讯封包筛选模块配置以判断各音讯封包的开始播放时间已超过一预定开始播放时间时,丢掉音讯封包,判断各音讯封包的开始播放时间未已超过预定开始播放时间时,指示在到达开始播放时间时,播放各音讯封包。
在一实施方案中,播放时间推算模块配置以将最小传送延迟音讯封包的开始播放时间,减去在最小传送延迟音讯封包之前接收的所有音讯封包播放的时间长度,以推算最早接收到的音讯封包的开始播放时间。
在一实施方案中,播放时间推算模块配置以将最小传送延迟音讯封包的开始播放时间,减去欲推算的音讯封包播放的时间长度、在最小传送延迟音讯封包之前并在欲推算的音讯封包之后接收的所有音讯封包播放的时间长度,以推算音讯封包的开始播放时间。
在一实施方案中,播放时间推算模块配置以将最小传送延迟音讯封包的开始播放时间,减去最小传送延迟音讯封包前一个接收的音讯封包播放的时间长度,以推算最小传送延迟音讯封包前一个接收到的音讯封包的开始播放时间,以推算最小传送延迟音讯封包前一个接收到的音讯封包的开始播放时间。
在一实施方案中,播放时间推算模块配置以将最小传送延迟音讯封包的开始播放时间,加上最小传送延迟音讯封包播放的时间长度,以推算最小传送延迟音讯封包下一个接收到的音讯封包的开始播放时间。
如上所述,本发明提供一种可靠传输网络中维持实时音讯串流播放延迟的系统及方法,其有效改善在可靠传输网络中,开始播放时因为接收端的抖动缓冲区(jitterbuffer)超出许多而造成播放延迟大幅增加的问题。
为使能更进一步了解本发明的特征及技术内容,请参阅以下有关本发明的详细说明与图式,然而所提供的图式仅用于提供参考与说明,并非用来对本发明加以限制。
附图说明
图1为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的方法的步骤流程图。
图2为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的方法的音讯封包的发送时间、送达时间以及播放时间的时间轴示意图。
图3为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统应用于从发送端依序接收多个音讯封包的接收端的示意图。
图4为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统应用于从发送端依序接收多个音讯封包的接收端的方块图。
图5为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统的方块图。
具体实施方式
以下是通过特定的具体实施例来说明本发明的实施方式,本领域技术人员可由本说明书所公开的内容了解本发明的优点与效果。本发明可通过其他不同的具体实施例加以施行或应用,本说明书中的各项细节也可基于不同观点与应用,在不背离本发明的构思下进行各种修改与变更。另外,本发明的附图仅为简单示意说明,并非依实际尺寸的描绘,事先声明。以下的实施方式将进一步详细说明本发明的相关技术内容,但所公开的内容并非用以限制本发明的保护范围。另外,本文中所使用的术语“或”,应视实际情况可能包含相关联的列出项目中的任一个或者多个的组合。
请参阅图1和图2,其中图1为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的方法的步骤流程图;图2为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的方法的音讯封包的发送时间、送达时间以及播放时间的时间轴示意图。
如图1所示,本实施例的可靠传输网络中维持实时音讯串流播放延迟的方法包含步骤S101~S121,适用于从发送端依序接收多个音讯封包的接收端,具体说明如下。
在步骤S101,在接收端接收到一音讯封包时,将已接收到的此音讯封包(例如第一个送达至接收端的音讯封包)的接收时间作为推算基准,以基于此音讯封包的接收时间,推算下一个接收到的音讯封包(例如第二个送达至接收端的音讯封包)的接收时间,即推算下一音讯封包送达接收端的时间。
在步骤S103,检测接收端实际接收到下一音讯封包的时间,是否早于所推算的下一音讯封包的接收时间。若是,即下一音讯封包实际的接收时间早于所推算的接收时间时,接着依序执行步骤S105~S107。若否,即下一音讯封包实际的接收时间晚于所推算的下一音讯封包的接收时间时,接着执行步骤S109。
在步骤S105,将此下一音讯封包定义为一最小传送延迟音讯封包,接着执行步骤S107。
在步骤S107,检测次数归零,接着回到步骤S101。具体的,检测次数一开始设定为0。在下一音讯封包实际的接收时间早于所推算的接收时间时,表示在目前接收到的所有音讯封包中,已找到传送延迟最小的音讯封包(即最小传送延迟音讯封包)。在此情况下,检测次数归零为0次。后续在步骤S101中将以此最小传送延迟音讯封包作为推算基准的音讯封包。亦即,在步骤S101中,基于此最小传送延迟音讯封包的接收时间,推算接收端此最小传送延迟音讯封包后续的音讯封包的接收时间,包含此最小传送延迟音讯封包下一个音讯封包的接收时间。
在步骤S109,计数检测次数。具体的,若下一音讯封包实际的接收时间,晚于所推算的下一音讯封包的接收时间,则表示下一个音讯封包的传送延迟时间长度大于作为推算基准的音讯封包的传送延迟时间长度,故下一个音讯封包并非最小传送延迟音讯封包。在此情况下,计数/累加一次检测次数,代表已检测作为推算基准的音讯封包(例如第一个送达接收端的音讯封包)后续接收的音讯封包(例如第二个送达接收端的音讯封包)并非最小传送延迟音讯封包。
在步骤S111,判断检测次数是否等于一预设检测次数。若否,即检测次数未到达预设检测次数时,再次执行步骤S101以推算、检测又下一个音讯封包(例如第三个送达至接收端的音讯封包)实际的接收时间,是否早于(基于第一个送达至接收端的音讯封包)所推算的又下一个音讯封包的接收时间。又下一个音讯封包的接收时间的推算方式同步骤S101的下一音讯封包。反复执行步骤S101~S103以检测多个音讯封包,直到在步骤S105找寻到最小传送延迟音讯封包,或直到检测次数等于(即累积至)预设检测次数后接着执行步骤S113。
举例而言,如图2所示,发送端依序在发送时间点A1、A2、A3、A4、A5向接收端发送五个音讯封包,而接收端依序在送达时间点B1、B2、B3、B4、B5分别接收此五个音讯封包。显然地,在五个音讯封包中,第四个音讯封包的发送时间点A4与送达时间点B4之间相隔的时间最短(表示传送延迟时间长度最短)。
在步骤S113,若作为推算基准的音讯封包(例如第一个送达接收端的音讯封包)后续的音讯封包的实际接收时间皆晚于所推算的接收时间,并且已检测N个音讯封包(N到达预设检测次数)时,代表后续的音讯封包(例如第二个、第三个送达至接收端的音讯封包)的延迟时间长度大于作为推算基准的音讯封包(例如第一个送达接收端的音讯封包)的延迟时间长度。在此情况下,定义步骤S101中作为推算基准的音讯封包(例如第一个送达接收端的音讯封包)为最小传送延迟音讯封包。
在步骤S115,推算开始播放时间,包含将接收到最小传送延迟音讯封包的时间加上一系统固定延迟时间,以推算最小传送延迟音讯封包的一开始播放时间,接着基于最小传送延迟音讯封包的开始播放时间以及各音讯封包播放的时间长度,推算其他各音讯封包的开始播放时间。
举例而言,如图2所示,检测到第四个音讯封包,相比于前三个音讯封包,具有最短传送延迟时间,而定义为最小传送延迟音讯封包。因此,将接收到最小传送延迟音讯封包的时间(即送达时间B4)加上系统固定延迟时间,以推算最小传送延迟音讯封包的开始播放时间C4,以公式表示为:C4=B4+DT,其中DT代表系统固定延迟时间。
在计算出最小传送延迟音讯封包预估开始播放的时间后,方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,减去在最小传送延迟音讯封包之前接收到的所有音讯封包播放的时间长度,以推算最早接收到的音讯封包的开始播放时间。举例而言,如图2所示,将第四个音讯封包的开始播放时间C4减去前三个音讯封包分别的播放时间长度AT1、AT2、AT3,以推算第一个音讯封包的开始播放时间C1,以公式表示为:C1=C4-(AT1+AT2+AT3)。
在计算出最小传送延迟音讯封包预估开始播放的时间后,方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,减去欲推算的音讯封包播放的时间长度、在最小传送延迟音讯封包之前并在欲推算的音讯封包之后接收的所有音讯封包播放的时间长度,以推算音讯封包的开始播放时间。举例而言,如图2所示,将第四个音讯封包的开始播放时间C4减去第二个和第三个音讯封包播放的时间长度AT2、AT3,以推算第二个音讯封包的开始播放时间C2,以公式表示为:C2=C4-(AT2+AT3)。
在计算出最小传送延迟音讯封包预估开始播放的时间后,方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,减去在最小传送延迟音讯封包前一个的音讯封包播放的时间长度,以推算在最小传送延迟音讯封包前一个接收到的音讯封包的开始播放时间。举例而言,如图2所示,将第四个音讯封包的开始播放时间C4减去第三个音讯封包播放的时间长度AT3,以推算第三个音讯封包的开始播放时间C3,以公式表示为:C3=C4-AT3。
在计算出最小传送延迟音讯封包预估开始播放的时间后,方法还包含以下步骤:将最小传送延迟音讯封包的开始播放时间,加上最小传送延迟音讯封包播放的时间长度,以推算在最小传送延迟音讯封包下一个的音讯封包的开始播放时间。举例而言,如图2所示,将第四个音讯封包的开始播放时间C4加上第四个音讯封包播放的时间长度AT4,以推算第五个音讯封包的开始播放时间C5,以公式表示为:C5=C4+AT4。
在步骤S117,判断各音讯封包的开始播放时间是否已超过预定开始播放时间(例如在游戏角色的动作出现的时间点为音讯封包的预定开始播放时间)。若是,执行步骤S119。若否,执行步骤S121。
在步骤S119,若音讯封包的开始播放时间已超过预定开始播放时间,丢掉此音讯封包,即不播放此音讯封包,而是直接在下一动作出现的时间点播放下一动作的音效(即下一个音讯封包)。
在步骤S121,若音讯封包的开始播放时间未已超过预定开始播放时间,则在到达每个音讯封包的开始播放时间时,播放音讯封包。
举例而言,如图2所示,第一预定播放时间代表音讯播放装置开始执行播放作业的时间。在第一预定播放时间的上限值(即第一预定开始播放时间点),等待一段时间后,到达第一个封包的开始播放时间C1时,播放第一个封包,之后在开始播放时间C2、C3、C4、C5到达时,分别播放后续依序接收到的第二个、第三个、第四个、第五个音讯封包。
又例如,第二预定播放时间DT2代表音讯播放装置开始执行播放作业的时间。由于第一个和第二个音讯封包分别的开始播放时间C1、C2皆早于第二预定播放时间DT2,丢掉第一个和第二个音讯封包,等到之后到达开始播放时间C3、C4、C5时,分别播放后续的第三个、第四个和第五个音讯封包。
请参阅图3~图5,其中图3为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统应用于从发送端依序接收多个音讯封包的接收端的示意图;图4为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统应用于从发送端依序接收多个音讯封包的接收端的方块图;图5为本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统的方块图。
如图3所示,发送端TX可为手机,而接收端RX可为耳机,在此仅举例说明,本发明不以此为限。如图3和图4所示,发送端TX将音讯数据AU切割成多个音讯封包PG1~PGn后,向接收端RX发送多个音讯封包PG1~PGn。接收端RX的音讯接收模块RCV经由有线或无线方式(例如但不限于采用蓝牙无线传输技术)依序接收发送端TX发送的多个音讯封包。
为了解决在可靠传输网络中,开始播放时因为接收端的抖动缓冲区(jitterbuffer)超出许多而造成播放延迟大幅增加的问题。如图4所示,本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统SYS应用于接收端RX,并连接接收端RX的音讯接收模块RCV以及音讯播放模块PYT。发送端TX连接接收端RX的音讯接收模块RCV。
如图5所示,本发明实施例的可靠传输网络中维持实时音讯串流播放延迟的系统SYS可包含最小延迟检测模块10、检测计数模块20、检测阀值设定模块30、播放时间推算模块40以及音讯封包筛选模块50。
如图5所示的最小延迟检测模块10连接如图4所示的音讯接收模块RCV以及如图5所示的检测计数模块20、检测阀值设定模块30以及播放时间推算模块40。检测计数模块20连接检测阀值设定模块30。播放时间推算模块40连接音讯封包筛选模块50。
在发送端TX发送的多个音讯封包PG1~PGn依序送达接收端RX的过程中,最小延迟检测模块10依序检测音讯封包PG1~PGn实际的接收时间。
首先,当接收端RX接收到音讯封包PG1时,最小延迟检测模块10基于音讯封包PG1的接收时间,推算下一音讯封包PG2的接收时间。当最小延迟检测模块10检测到下一音讯封包PG2实际的接收时间早于所推算的下一音讯封包PG2的接收时间时,将下一音讯封包PG2定义为一最小传送延迟音讯封包。
检测计数模块20设定检测次数初始为零值,表示为C=0。而当下一音讯封包PG2实际的接收时间晚于所推算的下一音讯封包PG2的接收时间,即未找寻到相比于音讯封包PG1延迟时间较短的音讯封包时,检测计数模块20(例如计数器)计数检测次数,表示为C=1,其中C代表检测次数,表示已检测出在音讯封包PG1后接收到的下一个音讯封包PG2并非为最小传送延迟音讯封包。
检测阀值设定模块30设定一默认检测次数。检测阀值设定模块30判断目前检测次数未等于此预设检测次数时,例如预设检测次数为10,目前仅检测一个音讯封包PG2(目前检测次数C=1),指示最小延迟检测模块10检测后续接收到的音讯封包PG3~PG10。
若检测到在音讯封包PG1的下一个接收音讯封包PG2并非为最小传送延迟音讯封包,接着检测下下个(例如第三个)接收到的音讯封包PG3,最小延迟检测模块10基于接收到的音讯封包PG1,推算音讯封包PG1的下下个音讯封包PG3的接收时间。
同理,当最小延迟检测模块10检测到音讯封包PG3实际的接收时间早于所推算的音讯封包PG3的接收时间时,将下下个音讯封包PG3定义为一最小传送延迟音讯封包。反之,当下下个音讯封包PG3实际的接收时间晚于所推算的下下个音讯封包PG3的接收时间,即未找寻到相比于音讯封包PG1延迟时间较短的音讯封包时,检测计数模块20(例如计数器)计数/累加检测次数,表示为C=2。
在尚未找寻到相比于音讯封包PG1延迟时间较短的音讯封包的情况下,持续检测后续接收的音讯封包PG4~PG10是否为最小传送延迟音讯封包,执行如同上述的检测程序。若在执行音讯封包PG4~PG10的检测程序的过程中,找到后续接收到的音讯封包PG4的延迟时间长度短于音讯封包PG1的延迟时间长度时,定义音讯封包PG4为最小传送延迟音讯封包。
在找到最小传送延迟音讯封包时,检测计数模块20将检测次数归零,表示为C=0。接着,最小延迟检测模块10改由基于最小传送延迟音讯封包例如音讯封包PG4的接收时间,推算后续接收到的音讯封包PG5~PG10的接收时间,以找到是否有传送延迟时间长度比音讯封包PG4更短的音讯封包。
在每检测一个音讯封包PG4~PG10相比于音讯封包PG1并非为最小传送延迟音讯封包时,检测计数模块20每累加一次检测次数。直到目前检测次数累加至预设检测次数例如10时,停止检测程序,即不再检测后续的音讯封包例如音讯封包PG11~PGn。在目前检测次数累加至预设检测次数,却仍未找到任一音讯封包PG4~PG10的延迟时间长度短于音讯封包PG1的延迟时间长度时,定义作为其他音讯封包PG2~~PG10的接收时间的推算基准的音讯封包PG1为最小传送延迟音讯封包。
在找寻到最小传送延迟音讯封包(例如音讯封包PG1或音讯封包PG4)之后,可推算各音讯封包PG1~PGn开始播放的时间。播放时间推算模块40将最小传送延迟音讯封包(例如音讯封包PG4)实际的接收时间加上一系统固定延迟时间,以推算最小传送延迟音讯封包的开始播放时间。
接着,播放时间推算模块40基于最小传送延迟音讯封包(例如音讯封包PG1或音讯封包PG4)的开始播放时间以及各音讯封包PG1~PGn播放的时间长度,推算其他各音讯封包PG1~PGn的开始播放时间,如图上述步骤S115举例的程序,不在此赘述。
音讯封包筛选模块50判断多个音讯封包PG1~PGn中的任一音讯封包例如音讯封包PG5的开始播放时间已超过/晚于音讯播放模块PYT的预定播放时间时,丢掉音讯封包PG5。相反地,音讯封包筛选模块50判断任一音讯封包PG1~PGn的开始播放时间未已超过预定开始播放时间时,指示如图4所示的音讯播放模块PYT在到达开始播放时间,播放对应的音讯封包PG1~PGn。
本发明的其中一有益效果在于,本发明所提供的可靠传输网络中维持实时音讯串流播放延迟的系统及其方法,其有效改善在可靠传输网络中,开始播放时因为接收端的抖动缓冲区(jitter buffer)超出许多而造成播放延迟大幅增加的问题。
以上所公开的内容仅为本发明的优选可行实施例,并非因此局限本发明的权利要求书,所以凡是运用本发明说明书及图式内容所做的等效技术变化,均包含于本发明的权利要求书内。
Claims (10)
1.一种可靠传输网络中维持实时音讯串流播放延迟的方法,适用于从发送端依序接收多个音讯封包的一接收端,其特征在于,所述可靠传输网络中维持实时音讯串流播放延迟的方法包含以下步骤:
(a)将已接收到的所述音讯封包的接收时间作为推算基准,以推算下一所述音讯封包的接收时间;
(b)检测下一所述音讯封包实际的接收时间是否早于所推算的接收时间,若是,将下一所述音讯封包定义为最小传送延迟音讯封包,并将检测次数归零,接着回到步骤(a)基于所述最小传送延迟音讯封包推算所述最小传送延迟音讯封包的下一所述音讯封包,若否,计数所述检测次数,接着执行下一步骤(c);
(c)判断所述检测次数是否等于预设检测次数,若否,回到步骤(a)以推算又下一个所述音讯封包,若是,将作为推算基准的所述音讯封包定义为所述最小传送延迟音讯封包,接着执行下一步骤(d);
(d)将所述最小传送延迟音讯封包的接收时间加上系统固定延迟时间,以推算所述最小传送延迟音讯封包的开始播放时间;
(e)基于所述最小传送延迟音讯封包的所述开始播放时间以及各所述音讯封包播放的时间长度,推算其他各所述音讯封包的所述开始播放时间;以及
(f)判断各所述音讯封包的所述开始播放时间是否已超过预定开始播放时间,若是,丢掉各所述音讯封包,若否,在到达所述开始播放时间时,播放各所述音讯封包。
2.根据权利要求1所述的可靠传输网络中维持实时音讯串流播放延迟的方法,其特征在于,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:
将所述最小传送延迟音讯封包的所述开始播放时间,减去在所述最小传送延迟音讯封包之前接收的所有所述音讯封包播放的时间长度,以推算最早接收到的所述音讯封包的所述开始播放时间。
3.根据权利要求1所述的可靠传输网络中维持实时音讯串流播放延迟的方法,其特征在于,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:
将所述最小传送延迟音讯封包的所述开始播放时间,减去欲推算的所述音讯封包播放的时间长度、在所述最小传送延迟音讯封包之前并在欲推算的所述音讯封包之后接收的所有所述音讯封包播放的时间长度,以推算所述音讯封包的所述开始播放时间。
4.根据权利要求1所述的可靠传输网络中维持实时音讯串流播放延迟的方法,其特征在于,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:
将所述最小传送延迟音讯封包的所述开始播放时间,减去所述最小传送延迟音讯封包前一个接收的所述音讯封包播放的时间长度,以推算所述最小传送延迟音讯封包前一个接收到的所述音讯封包的所述开始播放时间,以推算所述最小传送延迟音讯封包前一个接收到的所述音讯封包的所述开始播放时间。
5.根据权利要求1所述的可靠传输网络中维持实时音讯串流播放延迟的方法,其特征在于,所述可靠传输网络中维持实时音讯串流播放延迟的方法还包含以下步骤:
将所述最小传送延迟音讯封包的所述开始播放时间,加上所述最小传送延迟音讯封包播放的时间长度,以推算所述最小传送延迟音讯封包下一个接收到的所述音讯封包的所述开始播放时间。
6.一种可靠传输网络中维持实时音讯串流播放延迟的系统,适用于从发送端依序接收多个音讯封包的一接收端,其特征在于,所述可靠传输网络中维持实时音讯串流播放延迟的系统包含:
最小延迟检测模块,配置以将已接收到的所述音讯封包的接收时间作为推算基准,以推算下一所述音讯封包的接收时间,检测到下一所述音讯封包实际的接收时间早于所推算的接收时间时,将下一所述音讯封包定义为最小传送延迟音讯封包;
检测计数模块,连接所述最小延迟检测模块,配置以在下一所述音讯封包实际的接收时间晚于所推算的接收时间时,计数检测次数,而在找到所述最小传送延迟音讯封包时,将所述检测次数归零;
检测阀值设定模块,连接所述最小延迟检测模块以及所述检测计数模块,配置以判断所述检测次数未等于预设检测次数时,指示所述最小延迟检测模块检测后续接收到的所述音讯封包以找寻所述最小传送延迟音讯封包,而判断所述检测次数等于所述预设检测次数且未找到所述最小传送延迟音讯封包时,指示所述最小延迟检测模块直接将作为推算基准的所述音讯封包定义为所述最小传送延迟音讯封包;
播放时间推算模块,连接所述最小延迟检测模块,配置以将所述最小传送延迟音讯封包实际的接收时间加上系统固定延迟时间,以推算所述最小传送延迟音讯封包的开始播放时间,并基于所述最小传送延迟音讯封包的所述开始播放时间以及各所述音讯封包播放的时间长度,推算其他各所述音讯封包的所述开始播放时间;以及
音讯封包筛选模块,连接所述播放时间推算模块,配置以判断各所述音讯封包的所述开始播放时间已超过预定开始播放时间时,丢掉所述音讯封包,判断各所述音讯封包的所述开始播放时间未已超过所述预定开始播放时间时,指示在到达所述开始播放时间时,播放各所述音讯封包。
7.根据权利要求6所述的可靠传输网络中维持实时音讯串流播放延迟的系统,其特征在于,所述播放时间推算模块配置以将所述最小传送延迟音讯封包的所述开始播放时间,减去在所述最小传送延迟音讯封包之前接收的所有所述音讯封包播放的时间长度,以推算最早接收到的所述音讯封包的所述开始播放时间。
8.根据权利要求6所述的可靠传输网络中维持实时音讯串流播放延迟的系统,其特征在于,所述播放时间推算模块配置以将所述最小传送延迟音讯封包的所述开始播放时间,减去欲推算的所述音讯封包播放的时间长度、在所述最小传送延迟音讯封包之前并在欲推算的所述音讯封包之后接收的所有所述音讯封包播放的时间长度,以推算所述音讯封包的所述开始播放时间。
9.根据权利要求6所述的可靠传输网络中维持实时音讯串流播放延迟的系统,其特征在于,所述播放时间推算模块配置以将所述最小传送延迟音讯封包的所述开始播放时间,减去所述最小传送延迟音讯封包前一个接收的所述音讯封包播放的时间长度,以推算所述最小传送延迟音讯封包前一个接收到的所述音讯封包的所述开始播放时间,以推算所述最小传送延迟音讯封包前一个接收到的所述音讯封包的所述开始播放时间。
10.根据权利要求6所述的可靠传输网络中维持实时音讯串流播放延迟的系统,其特征在于,所述播放时间推算模块配置以将所述最小传送延迟音讯封包的所述开始播放时间,加上所述最小传送延迟音讯封包播放的时间长度,以推算所述最小传送延迟音讯封包下一个接收到的所述音讯封包的所述开始播放时间。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010394336.6A CN113645177A (zh) | 2020-05-11 | 2020-05-11 | 可靠传输网络中维持实时音讯串流播放延迟的方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010394336.6A CN113645177A (zh) | 2020-05-11 | 2020-05-11 | 可靠传输网络中维持实时音讯串流播放延迟的方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113645177A true CN113645177A (zh) | 2021-11-12 |
Family
ID=78415542
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010394336.6A Pending CN113645177A (zh) | 2020-05-11 | 2020-05-11 | 可靠传输网络中维持实时音讯串流播放延迟的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113645177A (zh) |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1855887A (zh) * | 2005-04-29 | 2006-11-01 | 华硕电脑股份有限公司 | 在接收端中减少数据串流前后跳动的方法及其相关装置 |
CN101160900A (zh) * | 2005-10-11 | 2008-04-09 | 华为技术有限公司 | 分组网络中多媒体实时传输的流同步方法及其装置 |
CN101370175A (zh) * | 2007-08-15 | 2009-02-18 | 华为技术有限公司 | 确定数据发送时间的方法、组播分组方法、装置和系统 |
CN105989844A (zh) * | 2015-01-29 | 2016-10-05 | 中国移动通信集团公司 | 一种音频传输的自适应方法及装置 |
CN109379620A (zh) * | 2018-11-28 | 2019-02-22 | 广州四三九九信息科技有限公司 | 音视频缓冲方法和装置 |
CN110035808A (zh) * | 2016-09-14 | 2019-07-19 | 声感股份有限公司 | 具有同步的多设备音频流传输系统 |
CN115086732A (zh) * | 2022-07-20 | 2022-09-20 | 南京百家云科技有限公司 | 一种音视频数据的同步方法及装置 |
-
2020
- 2020-05-11 CN CN202010394336.6A patent/CN113645177A/zh active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1855887A (zh) * | 2005-04-29 | 2006-11-01 | 华硕电脑股份有限公司 | 在接收端中减少数据串流前后跳动的方法及其相关装置 |
CN101160900A (zh) * | 2005-10-11 | 2008-04-09 | 华为技术有限公司 | 分组网络中多媒体实时传输的流同步方法及其装置 |
CN101370175A (zh) * | 2007-08-15 | 2009-02-18 | 华为技术有限公司 | 确定数据发送时间的方法、组播分组方法、装置和系统 |
CN105989844A (zh) * | 2015-01-29 | 2016-10-05 | 中国移动通信集团公司 | 一种音频传输的自适应方法及装置 |
CN110035808A (zh) * | 2016-09-14 | 2019-07-19 | 声感股份有限公司 | 具有同步的多设备音频流传输系统 |
CN109379620A (zh) * | 2018-11-28 | 2019-02-22 | 广州四三九九信息科技有限公司 | 音视频缓冲方法和装置 |
CN115086732A (zh) * | 2022-07-20 | 2022-09-20 | 南京百家云科技有限公司 | 一种音视频数据的同步方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US12063162B2 (en) | Controlling a jitter buffer | |
WO2017000719A1 (zh) | 一种基于队列时延的拥塞控制方法及装置 | |
US7079486B2 (en) | Adaptive threshold based jitter buffer management for packetized data | |
CN109644162B (zh) | 媒体缓冲 | |
CN106331717B (zh) | 视频码率自适应调整方法及发送端设备 | |
JP4930588B2 (ja) | 中継装置、及び中継方法 | |
EP1906582A2 (en) | Relay apparatus, relay method and relay program | |
CN111935441B (zh) | 一种网络状态检测方法及装置 | |
CN108391289B (zh) | 一种拥塞控制方法和基站 | |
WO2010069234A1 (zh) | 终端处于空闲模式下的业务终止方法、系统和设备 | |
WO2017021682A1 (en) | Monitoring network conditions | |
EP1931068A1 (en) | Method of adaptively dejittering packetized signals buffered at the receiver of a communication network node | |
JP5506591B2 (ja) | 通信システム及び通信品質制御方法 | |
US10382155B2 (en) | Data processing | |
WO2017031928A1 (zh) | 一种数据包传输方法及装置、通信系统 | |
JP2014160911A (ja) | パケット処理装置、方法及びプログラム | |
CN113645177A (zh) | 可靠传输网络中维持实时音讯串流播放延迟的方法及系统 | |
JPS59190757A (ja) | パケツト通信方式 | |
TWI801835B (zh) | 往返估算 | |
TW202143684A (zh) | 在可靠傳輸網路中維持即時音訊串流播放延遲的方法及系統 | |
WO2009141012A1 (en) | Packet latency estimation | |
KR20110075166A (ko) | 무선 통신 시스템에서 신호 송신 방법 및 장치 | |
JP3848222B2 (ja) | 再送方法 | |
US20080170562A1 (en) | Method and communication device for improving the performance of a VoIP call |
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 | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20211112 |