CN117560517A - 直播合唱的音频流缓存处理方法、系统、设备及存储介质 - Google Patents

直播合唱的音频流缓存处理方法、系统、设备及存储介质 Download PDF

Info

Publication number
CN117560517A
CN117560517A CN202311391996.9A CN202311391996A CN117560517A CN 117560517 A CN117560517 A CN 117560517A CN 202311391996 A CN202311391996 A CN 202311391996A CN 117560517 A CN117560517 A CN 117560517A
Authority
CN
China
Prior art keywords
buffer length
stream
jitter buffer
chorus
client
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
CN202311391996.9A
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.)
Guangzhou Baiguoyuan Information Technology Co Ltd
Original Assignee
Guangzhou Baiguoyuan Information Technology 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 Guangzhou Baiguoyuan Information Technology Co Ltd filed Critical Guangzhou Baiguoyuan Information Technology Co Ltd
Priority to CN202311391996.9A priority Critical patent/CN117560517A/zh
Publication of CN117560517A publication Critical patent/CN117560517A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/233—Processing of audio elementary streams
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4394—Processing of audio elementary streams involving operations for analysing the audio stream, e.g. detecting features or characteristics in audio streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Electrophonic Musical Instruments (AREA)

Abstract

本申请实施例公开了一种直播合唱的音频流缓存处理方法、系统、设备及存储介质。本申请实施例提供的技术方案，通过确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值；根据各个第一播放进度差值调整下发至观众端的伴奏流的缓存长度；基于最小延时控制规则调整下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整下发至观众端的混合流的缓存长度。采用上述技术手段，可以以适应不同角色客户端对直播合唱音频流的端到端延时、卡顿率和歌声伴奏同步需求，使得不同角色的客户端都可以达到较佳的直播合唱体验。

Description

直播合唱的音频流缓存处理方法、系统、设备及存储介质
技术领域
本申请实施例涉及音频处理技术领域，尤其涉及一种直播合唱的音频流缓存处理方法、系统、设备及存储介质。
背景技术
目前，随着网络直播的广泛普及，越来越多用户借助直播应用的线上K歌功能进行合唱，以满足用户随时随地与好友一起合唱的需求。在直播合唱过程中，会将不同角色(如领唱、合唱)的直播客户端的歌声流通过混音服务器进行混合，进而通过调整混合的歌声流和伴奏流的缓存长度，达到歌声伴奏同步的效果，提升观众客户端的观看体验。
但是，对于直播合唱中领唱、合唱和观众等不同的角色，其对直播合唱的音频流的侧重需求不同，仅仅追求观众端的歌声伴奏同步效果难以适应其他角色客户端对音频流的需求，导致部分角色客户端的直播合唱体验欠佳。
发明内容
本申请实施例提供一种直播合唱的音频流缓存处理方法、系统、设备及存储介质，能够分别针对直播合唱场景中的不同角色进行音频流缓存处理，解决直播合唱音频流播放无法适应不同角色客户端需求的技术问题。
在第一方面，本申请实施例提供了一种直播合唱的音频流缓存处理方法，包括：
获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传；
根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度；
基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。
在第二方面，本申请实施例提供了一种直播合唱的音频流缓存处理系统，包括：
获取模块，配置为获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传；
第一调整模块，配置为根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度；
第二调整模块，配置为基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。
在第三方面，本申请实施例提供了一种直播合唱的音频流缓存处理设备，包括：
存储器以及一个或多个处理器；
所述存储器，配置为存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的直播合唱的音频流缓存处理方法。
在第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令在由计算机处理器执行时配置为执行如第一方面所述的直播合唱的音频流缓存处理方法。
在第五方面，本申请实施例提供了一种计算机程序产品，所述计算机程序产品中包含有指令，当指令在计算机或处理器上运行时，使得计算机或处理器执行如第一方面所述的直播合唱的音频流缓存处理方法。
本申请实施例通过获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传；根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度；基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。采用上述技术手段，根据歌声流、伴奏流的不同接收端，适应性进行其歌声流歌伴奏流抖动缓冲长度调整，以适应不同角色客户端对直播合唱音频流的端到端延时、卡顿率和歌声伴奏同步需求，使得不同角色的客户端都可以达到较佳的直播合唱体验，提升直播合唱效果。
附图说明
图1是本申请实施例提供的一种直播合唱的音频流缓存处理方法的流程图；
图2是本申请实施例中不同角色客户端的音频流传输示意图；
图3是本申请实施例中第一抖动缓冲长度的调整示意图；
图4是本申请实施例中第三抖动缓冲长度的调整示意图；
图5是本申请实施例提供的一种直播合唱的音频流缓存处理系统的结构示意图；
图6是本申请实施例提供的一种直播合唱的音频流缓存处理设备的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
本申请提供的直播合唱的音频流缓存处理方法，旨在根据歌声流、伴奏流的不同接收端，适应性进行其歌声流歌伴奏流抖动缓冲长度调整，以适应不同角色客户端对直播合唱音频流的端到端延时、卡顿率和歌声伴奏同步需求。
在直播合唱场景中，影响用户使用体验的技术指标主要为：端到端延时、卡顿率和歌声伴奏同步效果。而不同的角色(如领唱、合唱和观众)对于这三个技术指标的侧重点不同。例如，观众追求更好的歌声伴奏同步效果和更低的卡顿率，对端到端延时的要求相对较低；而合唱者对收到合唱者的音频流要求超低的端到端延时，否则本端唱歌节奏会受对端歌声影响而被带跑偏，反而不太关心对端声音是否卡顿。而相关的直播合唱音频流处理方案中，没有对不同角色客户端接收的音频流进行细化处理，通常只会通过调整混合的歌声流和伴奏流的缓存长度，达到歌声伴奏同步的效果，进而下发缓存的音频流至各个角色的客户端，因此不能同时保证为每个角色都提供最佳的使用体验。由于直播合唱场景中，端到端延时、卡顿率、歌声伴奏同步效果三个技术指标相互影响，不同角色的客户端对这三个技术指标的要求也不尽相同。基于此，提供本申请实施例的一种直播合唱的音频流缓存处理方法，以解决直播合唱音频流播放无法适应不同角色客户端需求的技术问题。
实施例：
图1给出了本申请实施例提供的一种直播合唱的音频流缓存处理方法的流程图，本实施例中提供的直播合唱的音频流缓存处理方法可以由直播合唱的音频流缓存处理设备执行，该直播合唱的音频流缓存处理设备可以通过软件和/或硬件的方式实现，该直播合唱的音频流缓存处理设备可以是两个或多个物理实体构成，也可以是一个物理实体构成。一般而言，该直播合唱的音频流缓存处理设备为直播合唱场景中用于音频流处理的媒体服务器。
下述以该媒体服务器为执行直播合唱的音频流缓存处理方法的主体为例，进行描述。参照图1，该直播合唱的音频流缓存处理方法具体包括：
S110、获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传。
本申请实施例在对直播合唱的音频流进行缓存处理时，通过调整待下发至不同角色客户端的音频流的抖动缓冲长度，以达到适应性调节端到端延时、卡顿率或者歌声伴奏同步的效果，使得下发的音频流可以适应不同客户端的直播合唱需求。
其中，在直播合唱过程中，对于领唱者的客户端，定义为领唱客户端，领唱客户端实时上传的音频流包括一路歌声流和一路伴奏流。对于合唱者的客户端，定义为合唱客户端，合唱客户端实时上传的音频流包括一路歌声流。一般而言，领唱客户端为一个，合唱客户端可以有多个。此外，根据实际直播设置，还可以在观众端中选择相应数量的上麦客户端参与到直播合唱中。上麦嘉宾可以在直播过程中直接与领唱和合唱者进行语音互动，上麦客户端可以有多个，定义上麦客户端上传的音频流定义为聊天流。
参照图2，提供本申请实施例中不同角色客户端的音频流传输示意图。其中，对于领唱客户端，会上传歌声流S1以及伴奏流S伴至媒体服务器(MEDIA SERVER),合唱客户端会上传歌声流S2至媒体服务器，上麦客户端1会上传聊天流S3，上麦客户端2会上传聊天流S4。即对于领唱、合唱、上麦嘉宾等角色，都会推一路包含自己人声的音频流。除此之外，领唱额外推一路伴奏流。基于接收到的音频流，媒体服务器会向领唱、合唱和上麦嘉宾的客户端透传接收到的其他客户端的音频流，保证交互的及时性。如对于领唱客户端，其接收媒体服务器透传的音频流为S2、S3和S4。同理，其他参与直播合唱的合唱客户端和上麦客户端，会直接由媒体服务器透传相应的音频流。而观众端则接收上述媒体服务器接收到的所有音频流的混音音频流，以节约流量成本。需要说明的是，对于合唱客户端，其本地会同步播放伴奏流，因此无需透传伴奏流至合唱客户端。
在媒体服务器传输各类型音频流至各个不同角色的客户端时，为了适应不同角色客户端对端到端延时、卡顿率、歌声伴奏同步效果三个技术指标的侧重需求，则需要适应性对待传输音频流的抖动缓冲长度进行调整，以使得不同角色的客户端都可以达到较佳的直播合唱体验，提升直播合唱效果。
其中，各个客户端在上传音频流时，可以在音频协议中携带发端角色信息，媒体服务器根据接收到音频流携带的角色信息以及待下发音频流的接收端的角色信息，共同决策出最适合该路流的抖动缓冲区延时策略，从而保证每种角色都能在直播合唱场景中获得更好的体验。
具体地，对于直播合唱场景中不同角色的用户，将其分为如下三个角色：领唱、合唱和观众，即Ruser＝{LEADER,CHOIR,AUDIENCE}。其中，部分观众的角色可以是上麦嘉宾。将音频流分为如下三种流：伴奏流、歌声流和聊天流，即Rstream＝{ACCOMPANIMENT,SINGING,CHATTING}。对于下发至不同角色客户端的伴奏流、歌声流和聊天流，通过适应性进行其抖动缓冲区延时控制，以达到适应不同角色客户端对端到端延时、卡顿率、歌声伴奏同步效果三个技术指标的侧重需求。
通过获取领唱客户端和合唱客户端上传的各路歌声流，以及领唱客户端上传的伴奏流，首先确定对应的播放进度差值，以用于根据播放进度差值进行人声伴奏同步控制。对于每一路歌声流，均与伴奏流确定播放进度差值，定义为第一播放进度差值。第一播放进度差值计算公式为：
skew0＝musicindexSINGING-musicindexACCOMPANIMENT
其中，skew0表示第一播放进度差值，musicindexSINGING表示一路歌声流，musicindexACCOMPANIMENT表示伴奏流。基于该第一播放进度差值即可用于在传输伴奏流至观众端时，进行伴奏流的抖动缓冲长度调整。
进一步地，对于观众端，其接收到的歌声流包含领唱客户端和合唱客户端的歌声流，因此需要首先确定各个歌声流的混合流，进而确定混合流与伴奏流的第二播放进度差值，以使用第二播放进度差值进行该混合流的抖动缓冲长度调整。第二播放进度差值计算公式为：
skew1＝musicindexSINGING-混合-musicindexACCOMPANIMENT
其中，skew1表示第二播放进度差值，musicindexSINGING-混合表示混合流，musicindexACCOMPANIMENT表示伴奏流。
S120、根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度。
进一步地，基于已确定的第一播放进度差值，则可以适应性进行待下发伴奏流的抖动缓冲长度的调整，定义伴奏流抖动缓冲区的抖动缓冲长度为第一抖动缓冲长度。在调整伴奏流的抖动缓冲区时，由于只有观众端会收到伴奏流并播放，且观众端更关心伴奏流和唱歌流的同步效果及其卡顿情况，因此可以适当加大延时。如果存在落后于伴奏流的歌声流时，则说明当前伴奏流的抖动缓冲区大小不足以保证和所有歌声流保持同步并且不卡顿，因此需要将伴奏流的抖动缓冲区在当前基础上调大，否则，说明当前伴奏流的抖动缓冲区已经处于合适的缓存长度，维持原状即可。
可选地，根据各个第一播放进度差值调整第一抖动缓冲长度，包括：
S1201、确定各个第一播放进度差值中的最小进度差值，并获取自适应抖动控制算法实时估计的伴奏流的第一基础抖动缓冲长度，获取设定的第一基础延时；
S1202、在最小进度差值大于或者等于0的情况下，以第一基础抖动缓冲长度和第一基础延时之和作为第一抖动缓冲长度；
S1203、在最小进度差值小于0的情况下，以第一基础抖动缓冲长度、第一基础延时以及第一设定调整值之和作为第一抖动缓冲长度，第一设定调整值等于最小进度差值与伴奏流的帧长度的乘积。
其中，第一抖动缓冲长度计算公式如下所示：
其中，JACCOMPANIMENT表示第一抖动缓冲长度，Jneteq1为neteq(自适应抖动控制算法)模块估算出来的当前伴奏流的基础抖动缓冲长度，定义为第一基础抖动缓冲长度。Neteq模块通过测量数据包到达收端的时间间隔,来预测包在网络中的传输时间延时，进而根据收到的包但还未播放的缓冲数据的大小来评估抖动的大小。offset1为额外附加的基础延时。可以理解的是，因为neteq模块估算出来的第一基础抖动缓冲长度更适用于端到端通话这种追求超低延时的场景，而对于直播合唱场景，需要牺牲部分延时，换取更低的卡顿风险，提升整体的听感。因此通过引入额外的基础延时，认为Jneteq1+offset1对应的抖动缓冲区的缓存长度可以同时兼顾较低延时和较低卡顿风险。如若不存在伴奏流领先于歌声流，即min{skew0}≥0，则可以直接调整第一抖动缓冲长度为Jneteq1+offset1。而当存在落后于伴奏流的歌声流时，为了保证和所有歌声流保持同步并且不卡顿则需要在“Jneteq1+offset1”的抖动缓冲长度的基础上，对应增加“|min{skew0}|*Frame”的缓存长度，Frame1为伴奏流的帧长度，这样既能保证歌声和伴奏的同步，又不会增加卡顿风险。
需要说明的是，实际应用中，还可以在确定不存在伴奏流领先于歌声流时，直接使用该第一基础抖动缓冲长度为第一抖动缓冲长度，并在存在落后于伴奏流的歌声流时，在第一基础抖动缓冲长度的基础上增加设定长度为第一抖动缓冲长度。本申请实施例对具体的第一抖动缓冲长度调整不做固定限制，在此不一一赘述。
S130、基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。
在向观众端、领唱客户端或者合唱客户端下发歌声流时，对于不同角色的客户端，其传输的歌声流不同，领唱客户端或者合唱客户端为透传的歌声流，观众端为所有歌声流混合得到的混合流。其中，观众端对于混合流要求和伴奏流同步且不卡顿，因此对于第三抖动缓冲长度，如果当前混合流和伴奏流同步，则不做调整；如果当前混合流落后于伴奏流，也不做调整。因为如果要实现混合流和伴奏流同步，该歌声流需要调低当前的抖动缓冲区的缓存长度，这样会增加卡顿风险；而如果当前混合流领先于伴奏流，则需要将当前的抖动缓冲区的缓存长度调高。另一方面，领唱客户端和合唱客户端对于待接收的歌声流的要求超低延时，不关心是否卡顿，因此可以基于最小延时控制规则对其抖动缓冲区进行调整，得到第二抖动缓冲长度。
其中，基于最小延时控制规则调整第二抖动缓冲长度，包括：
对应下发至领唱客户端或者合唱客户端的歌声流，获取自适应抖动控制算法实时估计的第二基础抖动缓冲长度，获取设定的延时阈值，以第二基础抖动缓冲长度和延时阈值中的最小值作为第二抖动缓冲长度。
对于直接采用neteq模块估算出来的待下发歌声流的基础抖动长度，定义为第二基础抖动缓冲长度，结合设定延时阈值MINDELAY，选择两者中的最小值作为第二抖动缓冲长度。MINDELAY为可配置的阈值，用于防止网络抖动导致的延时过大的情况。
另一方面，根据第二播放进度差值调整第三抖动缓冲长度，包括：
S1301、对应混合流获取自适应抖动控制算法实时估计的第三基础抖动缓冲长度，获取设定的第二基础延时；
S1302、在第二播放进度差值小于或者等于0的情况下，以第三基础抖动缓冲长度和第二基础延时之和作为第三抖动缓冲长度；
S1303、在第二播放进度差值大于0的情况下，以第三基础抖动缓冲长度、第二基础延时以及第二设定调整值之和作为第三抖动缓冲长度，第二设定调整值等于第二播放进度差值与混合流的帧长度的乘积。
其中，对于待下发歌声流的抖动缓冲长度，其计算公式如下所示：
其中，JSINGING表示待下发歌声流的抖动缓冲长度，包括第二抖动缓冲长度和第三抖动缓冲长度；Jneteq2为neteq(自适应抖动控制算法)模块估算出来的当前待下发至领唱客户端或者合唱客户端的歌声流的基础抖动缓冲长度，定义为第二基础抖动缓冲长度；Jneteq3为neteq(自适应抖动控制算法)模块估算出来的当前待下发至观众端的混合流的基础抖动缓冲长度，定义为第三基础抖动缓冲长度，offset2为额外附加的基础延时。可以理解的是，因为neteq模块估算出来的第三基础抖动缓冲长度更适用于端到端通话这种追求超低延时的场景，而对于直播合唱场景，需要牺牲部分延时，换取更低的卡顿风险，提升整体的听感。因此通过引入额外的基础延时，认为Jneteq3+offset2对应的抖动缓冲区的缓存长度可以同时兼顾较低延时和较低卡顿风险。因此，不同于上述伴奏流缓存长度的调整方式，在调整混合流缓存长度时，如若存在伴奏流领先于混合流，即skew1≤0，则可以直接调整第三抖动缓冲长度为Jneteq3+offset2。而当存在混合流领先于伴奏流时，为了保证混合流与伴奏流保持同步并且不卡顿，则需要在“Jneteq3+offset2”的抖动缓冲长度的基础上，对应增加“skew1*Frame2”的缓存长度，Frame2为混合流的帧长度，这样既能保证歌声和伴奏的同步，又不会增加卡顿风险。
需要说明的是，实际应用中，还可以在确定当前混合流落后于伴奏流时，直接使用该第三基础抖动缓冲长度为第三抖动缓冲长度，并在当前混合流领先于伴奏流时，在第三基础抖动缓冲长度的基础上增加设定长度为第三抖动缓冲长度。本申请实施例对具体的第三抖动缓冲长度调整不做固定限制，在此不一一赘述。
此外，可选地，本申请实施例的直播合唱的音频流缓存处理方法还包括：
获取观众端中的上麦客户端上传的聊天流，将对应的聊天流下发至领唱客户端、合唱客户端、其他的观众端或者其他的上麦客户端。
可以理解的是，由于上麦客户端可以参与到直播合唱中，上传一路聊天流，因此媒体服务器对于聊天流的处理，也需要对应不同角色的客户端分别进行适应性进行聊天流的抖动缓冲区调整。
其中，将对应的聊天流下发至领唱客户端、合唱客户端、其他的观众端或者其他的上麦客户端，包括：
对应下发至领唱客户端、合唱客户端或者其他的上麦客户端的聊天流，获取自适应抖动控制算法实时估计的第四基础抖动缓冲长度，获取设定的第三基础延时，基于第四基础抖动缓冲长度和第三基础延时之和为第四抖动缓冲长度，以第四抖动缓冲长度为对应的聊天流的缓存长度；
对应下发至其他的观众端的聊天流，获取自适应抖动控制算法实时估计的第五基础抖动缓冲长度，获取设定的第四基础延时和第五基础延时，基于第五基础抖动缓冲长度、第四基础延时以及第五基础延时之和为第五抖动缓冲长度，以第五抖动缓冲长度为对应的聊天流的缓存长度。
聊天流的抖动缓冲区调整公式如下：
其中，JCHATTING表示待下发聊天流的抖动缓冲长度，包括第四抖动缓冲长度和第五抖动缓冲长度；Jneteq4为neteq(自适应抖动控制算法)模块估算出来的当前待下发至领唱客户端、合唱客户端的或者上麦客户端的基础抖动缓冲长度，定义为第四基础抖动缓冲长度；Jneteq5为neteq(自适应抖动控制算法)模块估算出来的当前待下发至观众端的聊天流的基础抖动缓冲长度，定义为第五基础抖动缓冲长度，offset3、offset4和offset5为额外附加的基础延时。对于领唱、合唱和上麦嘉宾的客户端，直接用Jneteq4+offset3为第四抖动缓冲长度；对于观众端，则使用Jneteq5+offset4+offset5为第五抖动缓冲长度，以此来降低聊天流的卡顿风险。
需要说明的是，实际应用中，上述各个基础延时、基础抖动缓冲长度可以取相同的取值。为了更精准地进行抖动缓冲区控制，则对于不同的音频流，其使用的基础延时、基础抖动缓冲长度均可取不同的值。
至此，通过从不同角色客户端对端到端延时、卡顿率和同步效果三个技术指标的侧重需求，根据客户端角色和音频流的角色，确定出不同的抖动缓冲区延时策略，进而提升直播合唱效果。
上述，通过获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传；根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度；基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。采用上述技术手段，根据歌声流、伴奏流的不同接收端，适应性进行其歌声流歌伴奏流抖动缓冲长度调整，以适应不同角色客户端对直播合唱音频流的端到端延时、卡顿率和歌声伴奏同步需求，使得不同角色的客户端都可以达到较佳的直播合唱体验，提升直播合唱效果。
在上述实施例的基础上，图5为本申请提供的一种直播合唱的音频流缓存处理系统的结构示意图。参考图5，本实施例提供的直播合唱的音频流缓存处理系统具体包括：获取模块21、第一调整模块22和第二调整模块23。
其中，获取模块，配置为获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传；
第一调整模块，配置为根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度；
第二调整模块，配置为基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。
具体地，根据各个第一播放进度差值调整第一抖动缓冲长度，包括：
确定各个第一播放进度差值中的最小进度差值，并获取自适应抖动控制算法实时估计的伴奏流的第一基础抖动缓冲长度，获取设定的第一基础延时；
在最小进度差值大于或者等于0的情况下，以第一基础抖动缓冲长度和第一基础延时之和作为第一抖动缓冲长度；
在最小进度差值小于0的情况下，以第一基础抖动缓冲长度、第一基础延时以及第一设定调整值之和作为第一抖动缓冲长度，第一设定调整值等于最小进度差值与伴奏流的帧长度的乘积。
基于最小延时控制规则调整第二抖动缓冲长度，包括：
对应下发至领唱客户端或者合唱客户端的歌声流，获取自适应抖动控制算法实时估计的第二基础抖动缓冲长度，获取设定的延时阈值，以第二基础抖动缓冲长度和延时阈值中的最小值作为第二抖动缓冲长度。
根据第二播放进度差值调整第三抖动缓冲长度，包括：
对应混合流获取自适应抖动控制算法实时估计的第三基础抖动缓冲长度，获取设定的第二基础延时；
在第二播放进度差值小于或者等于0的情况下，以第三基础抖动缓冲长度和第二基础延时之和作为第三抖动缓冲长度；
在第二播放进度差值大于0的情况下，以第三基础抖动缓冲长度、第二基础延时以及第二设定调整值之和作为第三抖动缓冲长度，第二设定调整值等于第二播放进度差值与混合流的帧长度的乘积。
此外，该直播合唱的音频流缓存处理系统还包括：
获取观众端中的上麦客户端上传的聊天流，将对应的聊天流下发至领唱客户端、合唱客户端、其他的观众端或者其他的上麦客户端。
其中，将对应的聊天流下发至领唱客户端、合唱客户端、其他的观众端或者其他的上麦客户端，包括：
对应下发至领唱客户端、合唱客户端或者其他的上麦客户端的聊天流，获取自适应抖动控制算法实时估计的第四基础抖动缓冲长度，获取设定的第三基础延时，基于第四基础抖动缓冲长度和第三基础延时之和为第四抖动缓冲长度，以第四抖动缓冲长度为对应的聊天流的缓存长度；
对应下发至其他的观众端的聊天流，获取自适应抖动控制算法实时估计的第五基础抖动缓冲长度，获取设定的第四基础延时和第五基础延时，基于第五基础抖动缓冲长度、第四基础延时以及第五基础延时之和为第五抖动缓冲长度，以第五抖动缓冲长度为对应的聊天流的缓存长度。
上述，通过获取多路歌声流和一路伴奏流，确定各个歌声流分别与伴奏流的第一播放进度差值，确定各个歌声流的混合流与伴奏流的第二播放进度差值，歌声流分别由领唱客户端和合唱客户端上传，伴奏流由领唱客户端上传；根据各个第一播放进度差值调整第一抖动缓冲长度，第一抖动缓冲长度为下发至观众端的伴奏流的缓存长度；基于最小延时控制规则调整第二抖动缓冲长度，第二抖动缓冲长度为下发至领唱客户端或者合唱客户端的歌声流的缓存长度；根据第二播放进度差值调整第三抖动缓冲长度，第三抖动缓冲长度为下发至观众端的混合流的缓存长度。采用上述技术手段，根据歌声流、伴奏流的不同接收端，适应性进行其歌声流歌伴奏流抖动缓冲长度调整，以适应不同角色客户端对直播合唱音频流的端到端延时、卡顿率和歌声伴奏同步需求，使得不同角色的客户端都可以达到较佳的直播合唱体验，提升直播合唱效果。
本申请实施例提供的直播合唱的音频流缓存处理系统可以配置为执行上述实施例提供的直播合唱的音频流缓存处理方法，具备相应的功能和有益效果。
在上述实际上例的基础上，本申请实施例还提供了一种直播合唱的音频流缓存处理设备，参照图6，该直播合唱的音频流缓存处理设备包括：处理器31、存储器32、通信模块33、输入装置34及输出装置35。存储器作为一种计算机可读存储介质，可配置为存储软件程序、计算机可执行程序以及模块，如本申请任意实施例所述的直播合唱的音频流缓存处理方法对应的程序指令/模块(例如，直播合唱的音频流缓存处理系统中的获取模块、第一调整模块和第二调整模块)。通信模块配置为进行数据传输。处理器通过运行存储在存储器中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的直播合唱的音频流缓存处理方法。输入装置可配置为接收输入的数字或字符信息，以及产生与设备的用户设置以及功能控制有关的键信号输入。输出装置可包括显示屏等显示设备。上述提供的直播合唱的音频流缓存处理设备可配置为执行上述实施例提供的直播合唱的音频流缓存处理方法，具备相应的功能和有益效果。
在上述实施例的基础上，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令在由计算机处理器执行时配置为执行一种直播合唱的音频流缓存处理方法，存储介质可以是任何的各种类型的存储器设备或存储设备。当然，本申请实施例所提供的一种计算机可读存储介质，其计算机可执行指令不限于如上所述的直播合唱的音频流缓存处理方法，还可以执行本申请任意实施例所提供的直播合唱的音频流缓存处理方法中的相关操作。
在上述实施例的基础上，本申请实施例还提供一种计算机程序产品，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机程序产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备、移动终端或其中的处理器执行本申请各个实施例所述直播合唱的音频流缓存处理方法的全部或部分步骤。

Claims (10)

1.一种直播合唱的音频流缓存处理方法，其特征在于，包括：
获取多路歌声流和一路伴奏流，确定各个所述歌声流分别与所述伴奏流的第一播放进度差值，确定各个所述歌声流的混合流与所述伴奏流的第二播放进度差值，所述歌声流分别由领唱客户端和合唱客户端上传，所述伴奏流由所述领唱客户端上传；
根据各个所述第一播放进度差值调整第一抖动缓冲长度，所述第一抖动缓冲长度为下发至观众端的所述伴奏流的缓存长度；
基于最小延时控制规则调整第二抖动缓冲长度，所述第二抖动缓冲长度为下发至所述领唱客户端或者所述合唱客户端的所述歌声流的缓存长度；根据所述第二播放进度差值调整第三抖动缓冲长度，所述第三抖动缓冲长度为下发至所述观众端的所述混合流的缓存长度。
2.根据权利要求1所述的直播合唱的音频流缓存处理方法，其特征在于，所述根据各个所述第一播放进度差值调整第一抖动缓冲长度，包括：
确定各个所述第一播放进度差值中的最小进度差值，并获取自适应抖动控制算法实时估计的所述伴奏流的第一基础抖动缓冲长度，获取设定的第一基础延时；
在所述最小进度差值大于或者等于0的情况下，以所述第一基础抖动缓冲长度和所述第一基础延时之和作为所述第一抖动缓冲长度；
在所述最小进度差值小于0的情况下，以所述第一基础抖动缓冲长度、所述第一基础延时以及第一设定调整值之和作为所述第一抖动缓冲长度，所述第一设定调整值等于所述最小进度差值与所述伴奏流的帧长度的乘积。
3.根据权利要求1所述的直播合唱的音频流缓存处理方法，其特征在于，所述基于最小延时控制规则调整第二抖动缓冲长度，包括：
对应下发至所述领唱客户端或者所述合唱客户端的所述歌声流，获取自适应抖动控制算法实时估计的第二基础抖动缓冲长度，获取设定的延时阈值，以所述第二基础抖动缓冲长度和所述延时阈值中的最小值作为所述第二抖动缓冲长度。
4.根据权利要求1所述的直播合唱的音频流缓存处理方法，其特征在于，所述根据所述第二播放进度差值调整第三抖动缓冲长度，包括：
对应所述混合流获取自适应抖动控制算法实时估计的第三基础抖动缓冲长度，获取设定的第二基础延时；
在所述第二播放进度差值小于或者等于0的情况下，以所述第三基础抖动缓冲长度和所述第二基础延时之和作为所述第三抖动缓冲长度；
在所述第二播放进度差值大于0的情况下，以所述第三基础抖动缓冲长度、所述第二基础延时以及第二设定调整值之和作为所述第三抖动缓冲长度，所述第二设定调整值等于所述第二播放进度差值与所述混合流的帧长度的乘积。
5.根据权利要求1所述的直播合唱的音频流缓存处理方法，其特征在于，还包括：
获取所述观众端中的上麦客户端上传的聊天流，将对应的所述聊天流下发至所述领唱客户端、所述合唱客户端、其他的所述观众端或者其他的所述上麦客户端。
6.根据权利要求5所述的直播合唱的音频流缓存处理方法，其特征在于，所述将对应的所述聊天流下发至所述领唱客户端、所述合唱客户端、其他的所述观众端或者其他的所述上麦客户端，包括：
对应下发至所述领唱客户端、所述合唱客户端或者其他的所述上麦客户端的所述聊天流，获取自适应抖动控制算法实时估计的第四基础抖动缓冲长度，获取设定的第三基础延时，基于所述第四基础抖动缓冲长度和所述第三基础延时之和为第四抖动缓冲长度，以所述第四抖动缓冲长度为对应的所述聊天流的缓存长度；
对应下发至其他的所述观众端的所述聊天流，获取自适应抖动控制算法实时估计的第五基础抖动缓冲长度，获取设定的第四基础延时和第五基础延时，基于所述第五基础抖动缓冲长度、所述第四基础延时以及所述第五基础延时之和为第五抖动缓冲长度，以所述第五抖动缓冲长度为对应的所述聊天流的缓存长度。
7.一种直播合唱的音频流缓存处理系统，其特征在于，包括：
获取模块，配置为获取多路歌声流和一路伴奏流，确定各个所述歌声流分别与所述伴奏流的第一播放进度差值，确定各个所述歌声流的混合流与所述伴奏流的第二播放进度差值，所述歌声流分别由领唱客户端和合唱客户端上传，所述伴奏流由所述领唱客户端上传；
第一调整模块，配置为根据各个所述第一播放进度差值调整第一抖动缓冲长度，所述第一抖动缓冲长度为下发至观众端的所述伴奏流的缓存长度；
第二调整模块，配置为基于最小延时控制规则调整第二抖动缓冲长度，所述第二抖动缓冲长度为下发至所述领唱客户端或者所述合唱客户端的所述歌声流的缓存长度；根据所述第二播放进度差值调整第三抖动缓冲长度，所述第三抖动缓冲长度为下发至所述观众端的所述混合流的缓存长度。
8.一种直播合唱的音频流缓存处理设备，其特征在于，包括：
存储器以及一个或多个处理器；
所述存储器，配置为存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-6任一所述的直播合唱的音频流缓存处理方法。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令在由计算机处理器执行时配置为执行如权利要求1-6任一所述的直播合唱的音频流缓存处理方法。
10.一种计算机程序产品，其特征在于，所述计算机程序产品中包含有指令，当所述指令在计算机或处理器上运行时，使得所述计算机或处理器执行如权利要求1-6任一所述的直播合唱的音频流缓存处理方法。
CN202311391996.9A 2023-10-24 2023-10-24 直播合唱的音频流缓存处理方法、系统、设备及存储介质 Pending CN117560517A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311391996.9A CN117560517A (zh) 2023-10-24 2023-10-24 直播合唱的音频流缓存处理方法、系统、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311391996.9A CN117560517A (zh) 2023-10-24 2023-10-24 直播合唱的音频流缓存处理方法、系统、设备及存储介质

Publications (1)

Publication Number Publication Date
CN117560517A true CN117560517A (zh) 2024-02-13

Family

ID=89819406

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311391996.9A Pending CN117560517A (zh) 2023-10-24 2023-10-24 直播合唱的音频流缓存处理方法、系统、设备及存储介质

Country Status (1)

Country Link
CN (1) CN117560517A (zh)

Similar Documents

Publication Publication Date Title
US11949922B2 (en) Simulating a local experience by live streaming sharable viewpoints of a live event
US10334207B2 (en) Audio video streaming system and method
US7593354B2 (en) Method and system for low latency high quality music conferencing
US10021177B1 (en) Peer-to-peer communications
CN110910860B (zh) 线上ktv实现方法、装置、电子设备及存储介质
CN106488265A (zh) 一种发送媒体流的方法和装置
US20070039025A1 (en) Method for application sharing
US11516518B2 (en) Live streaming with live video production and commentary
US20060008117A1 (en) Information source selection system and method
US8571189B2 (en) Efficient transmission of audio and non-audio portions of a communication session for phones
CN117560517A (zh) 直播合唱的音频流缓存处理方法、系统、设备及存储介质
KR20150042628A (ko) 분산 텔레프레즌스 서비스 제공 방법 및 장치
CN114710687A (zh) 音视频同步方法、装置、设备及存储介质
JP2018530944A (ja) 異種ネットワーキング環境におけるメディアレンダリングの同期化
CN112770165A (zh) 一种音视频流分布式同步方法
CN114765695B (zh) 一种直播数据处理方法、装置、设备及介质
WO2024027272A1 (zh) 多媒体资源的传输方法、装置、电子设备及存储介质
US20230290329A1 (en) Acoustic signal cancelling

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