CN114125482A - 直播连麦处理方法、电子设备及存储介质 - Google Patents

直播连麦处理方法、电子设备及存储介质 Download PDF

Info

Publication number
CN114125482A
CN114125482A CN202111394818.2A CN202111394818A CN114125482A CN 114125482 A CN114125482 A CN 114125482A CN 202111394818 A CN202111394818 A CN 202111394818A CN 114125482 A CN114125482 A CN 114125482A
Authority
CN
China
Prior art keywords
real
time communication
live
communication engine
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.)
Granted
Application number
CN202111394818.2A
Other languages
English (en)
Other versions
CN114125482B (zh
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.)
Tencent Music Entertainment Technology Shenzhen Co Ltd
Original Assignee
Tencent Music Entertainment Technology Shenzhen 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 Tencent Music Entertainment Technology Shenzhen Co Ltd filed Critical Tencent Music Entertainment Technology Shenzhen Co Ltd
Priority to CN202111394818.2A priority Critical patent/CN114125482B/zh
Priority claimed from CN202111394818.2A external-priority patent/CN114125482B/zh
Publication of CN114125482A publication Critical patent/CN114125482A/zh
Application granted granted Critical
Publication of CN114125482B publication Critical patent/CN114125482B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/2187Live feed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/478Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请公开一种直播连麦处理方法和装置、电子设备及存储介质。该直播连麦处理方法,包括第一主播客户端发起与第二主播客户端的连麦操作;所述第一主播客户端使用本地的第一实时通信引擎推送第一直播流;所述第二主播客户端使用本地的第二实时通信引擎推送第二直播流;当所述第一实时通信引擎与所述第二实时通信引擎不相同时,所述第一主播客户端加载本地的第二实时通信引擎,拉取所述第二主播客户端推送的所述第二直播流;当所述第一实时通信引擎与所述第二实时通信引擎不相同时,所述第二主播客户端加载本地的第一实时通信引擎,拉取所述第一主播客户端推送的所述第一直播流。

Description

直播连麦处理方法、电子设备及存储介质
技术领域
本申请涉及互联网技术领域,具体涉及一种直播连麦处理方法、电子设备及存储介质。
背景技术
随着智能移动终端和移动通信技术的迅速发展,以直播为代表的流媒体技术在移动终端获得了广泛的应用。在直播时,主播之间连线能够有效提升直播服务的互动效果以及用户体验,因此在众多直播服务中得到广泛应用。
在直播时、尤其是主播连麦时,音视频的稳定性、实时性成为核心关注场景。当前,有提出在相互连麦的主播设备之间基于RTC(Real-Time Communication)协议进行互联,以便提高主播连麦时的实时性。然而,为在广大区域提供广泛的直播服务,直播服务商可能会基于不同地域使用不同的云服务,这可能导致接入不同云服务的主播设备各自可使用的优选 RTC服务并不相同。这些不同的云服务甚至有可能配备不同的RTC服务。这使得接入不同云服务器的主播设备间实现的连麦效果不佳,甚至无法实现基于RTC协议的连麦。
因此,希望能够提供具有更广泛适应性的且仍具有稳定性、实时性的直播服务的主播连麦解决方案,即使主播设备相距甚远和/或接入了不同的云服务。
本背景技术描述的内容仅为了便于了解本领域的相关技术,不视作对现有技术的承认。
发明内容
因此,本发明实施例意图提供一种直播连麦处理方法和装置以及相关的电子设备和存储介质,其能够在主播设备相距甚远和/或接入了不同的云服务的情况下,仍能提供具有稳定性、实时性的直播服务的主播连麦解决方案,该方案具有广泛的地域适应性。
在第一方面,提供一种直播连麦处理方法,其包括:
第一主播客户端发起与第二主播客户端的连麦操作;
所述第一主播客户端使用本地的第一实时通信引擎推送第一直播流;
所述第二主播客户端使用本地的第二实时通信引擎推送第二直播流;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,所述第一主播客户端加载本地的第二实时通信引擎,拉取所述第二主播客户端推送的所述第二直播流;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,所述第二主播客户端加载本地的第一实时通信引擎,拉取所述第一主播客户端推送的所述第一直播流。
在第二方面,提供一种直播连麦处理方法,其由第一主播客户端实施,所述方法包括:
发送与第二主播客户端连麦的连麦请求;
使用本地的第一实时通信引擎推送第一直播流;
响应于第二主播客户端接受所述连麦请求,检测所述第一实时通信引擎是否与所述第二主播客户端所使用的第二实时通信引擎相同;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,加载本地的第二实时通信引擎,以拉取所述第二主播客户端推送的第二直播流;
对所述第一直播流和第二直播流混流,形成第一混合直播流,并向服务端推送所述第一混合直播流。
在第三方面,提供一种直播连麦处理方法,其由第二主播客户端实施,所述方法包括:
接受第一主播客户端发送的连麦请求;
使用本地的第二实时通信引擎推送第二直播流;
响应于接受第一主播客户端发送的连麦请求,检测所述第一主播客户端所使用的第一实时通信引擎是否与所述第二实时通信引擎相同;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,加载本地的第一实时通信引擎,并拉取所述第一主播客户端推送的第一直播流;
对所述第二直播流和第一直播流混流,形成第二混合直播流,并向服务端推送所述第二混合直播流。
在第四方面,提供一种直播连麦处理装置,其包括:
连麦发起单元,配置成发起第一主播客户端与第二主播客户端的连麦操作;
第一推流单元,配置成使得所述第一主播客户端使用本地的第一实时通信引擎推送第一直播流;
第二推流单元,配置成使得所述第二主播客户端使用本地的第二实时通信引擎推送第二直播流;
可选的检测单元,配置成检测所述第一主播客户端使用的所述第一实时通信引擎与所述第二主播客户端所使用的所述第二实时通信引擎是否相同;
第一拉流单元,配置成当所述第一实时通信引擎与所述第二实时通信引擎不相同时,使得所述第一主播客户端加载本地的第二实时通信引擎,拉取所述第二主播客户端推送的所述第二直播流;
第二拉流单元,配置成当所述第一实时通信引擎与所述第二实时通信引擎不相同时,使得所述第二主播客户端加载本地的第一实时通信引擎,拉取所述第一主播客户端推送的所述第一直播流。
在第五方面,提供一种电子设备,其包括:处理器和存储有计算机程序的存储器,所述处理器被配置为在运行计算机程序时执行本发明任一实施例所述的方法。
在第六方面,提供一种存储介质,所述存储介质存储有计算机程序,所述计算机程序配置成被运行时执行本发明任一实施例所述的方法。
与已知的利用同种RTC服务进行连麦的方案相比,根据本发明实施例在连麦时不寻求改变主播客户端当前连接的RTC服务,而是通过检测主播客户端所使用的RTC服务类型是否相同,并在不相同时分别在各主播客户端本地加载对方所使用的RTC服务类型并仅用于拉流,与此同时仍使用原有的、可能为最佳的RTC服务用于推流。由此,能够在主播设备相距甚远和/或接入了不同的云服务的情况下,仍能提供具有稳定性、实时性的直播服务的主播连麦解决方案,且该方案具有广泛的地域适应性。
本发明实施例的其他可选特征和技术效果一部分在下文描述,一部分可通过阅读本文而明白。
附图说明
以下,结合附图来详细说明本发明的实施例,所示出的元件不受附图所显示的比例限制,附图中相同或相似的附图标记表示相同或类似的元件,其中:
图1示出了示例性的已知直播***提供的连麦方案的示意图;
图2A示出了根据本发明实施例的所提供的连麦方案的第一示意图;
图2B示出了根据本发明实施例的所提供的连麦方案的第二示意图;
图3示出了根据本发明实施例的所提供的连麦方案的架构图;
图4示出了根据本发明实施例的方法的示意性流程图;
图5示出了根据本发明实施例的方法的示意性流程图;
图6示出了根据本发明实施例的方法的示意性流程图;
图7示出了根据本发明实施例的装置的结构示意图;
图8示出了根据本发明实施例的电子设备的硬件结构示意图;
图9示出了根据本发明实施例的电子设备的第一操作***示意图;
图10示出了根据本发明实施例的电子设备的第二操作***示意图;
图11示出了示例性的进行连麦时的用户界面图,其中所述用户界面在观众客户端中呈现。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,下面结合具体实施方式和附图,对本发明做进一步详细说明。在此,本发明的示意性实施方式及其说明用于解释本发明,但并不作为对本发明的限定。
在本发明实施例中,流媒体(Streaming Media)具有本领域的常规含义,是指采用流式传输的方式在互联网上即时传输影音以供观赏的技术,此技术使得数据包得以像流水一样发送。
在本发明实施例中,直播将指网络直播。
在本发明实施例中,直播应用程序(APP)可作宽泛性解释,涵盖以直播为主要功能的APP以及具有直播功能或模块的其他类型APP。例如,在本发明的一些实施例中,所述应用程序(APP)可以为不同类型的具有直播功能或模块的APP,包括但不限于:音乐APP、社交APP、购物APP、视频APP等。
在本发明实施例中,“直播间”可作宽泛性解释,为直播应用程序中设置的独立空间,在其中由主播用户向观众用户提供直播音视频流。在本发明实施例中,所述“直播间”涵盖普通的“直播间”以及具备直播间性质的类似直播空间,如“歌房”等。在本发明的一些实施例中,直播间也可以简称为房间。
直播***可以包括服务端和多个连线到服务端的终端或客户端。所述终端或客户端可以根据直播时的角色,例如作为提供直播的主播或观看直播的观众,推送直播流到服务端和/或从服务端拉取直播流。由此,在本发明实施例中,根据不同类型,终端或客户端可以包括推流(终)端和播放 (终)端或拉流端。或者,终端或客户端可以包括主播客户端(简称为主播端)和观众客户端(简称为观众端)。
连麦为网络直播的一项重要功能。在连麦时,参与连麦的主播客户端在推送直播流的同时,还拉取其他连麦主播客户端推送的直播流。
参考图1,示出了已知直播***提供的连麦方案的示意图,其中主播客户端采用了基于RTC服务的流媒体推送。如图1所示,主播用户A(主播 A)在其直播间进行单主播直播时,例如通过RTC服务推送直播流(推流) 到云服务(器)上,而同时在进行单主播直播的主播用户B(主播B)也在其直播间例如通过RTC服务推流到云服务(器)上。相应地,服务端(云服务器)借助于CDN(内容分发网络)分别使得主播A推送的直播流被作为主播A观众的用户C(观众C)拉取(拉流),用户B推送的直播流被作为主播B观众的用户D(观众D)拉取(拉流)。
继续参考图1,当发起连麦后,例如图11所示的主播PK时,例如可以建立一个新的房间(连麦房间),主播A借助于RTC服务拉取并开始播放主播B的流,同时发起混流指令,把主播A和主播B的内容合成一路(即AB混流),供主播A的观众C观看。主播B借助于同一RTC服务拉取并开始播放主播A的流,同时发起混流指令,把主播B和主播A 的内容合成一路(即BA混流),供主播B的观众D观看。
继续参考图1,此时观众C和观众D的观看方式无变化,即继续CDN 观看。如图11所示,例如在观众C的客户端的用户界面中播放AB混流,此时主播A在左边呈现,主播B在右边呈现;相应地,例如在观众D的客户端的用户界面中播放BA混流,此时主播B在左边呈现,主播A在右边呈现。
然而该方案仍存在有可改善之处。例如,在此方案中,主播A和主播 B在连麦时要采用相同的RTC服务,例如主播A和主播B均接入腾讯云服务,并利用腾讯云服务配备的RTC服务进行连麦的推流/拉流。然而,例如由于地域或其他原因,主播A客户端(A客户端)和主播B客户端(B客户端)能连接的或者优选连接的云服务不尽相同,而不同的云服务器配备的RTC服务也不相同。此时,要实现主播A和主播B的连麦,一种可能的方案是放弃基于UDP协议的RTC服务,而例如采用其他的推流/拉流服务,例如基于TCP协议的各种推流/拉流服务,如RMTP,HLS等;然而,这种方案将丧失了RTC所具有的高稳定性和实时性特征。另一种可能的方案是在连麦时,主播A和主播B在同一直播间(连麦房间)中使用相同的RTC 服务(SDK);在这种情况下,其中的部分的主播客户端(如B客户端)例如不得不切换到非优选的RTC服务并进而采用非优选云服务,由此丧失了使用RTC服务所希望高稳定性和实时性,某些主播客户端重新连接新的云服务更进一步恶化了此情形。
进一步地,在该方案中,观众用户均是基于常规的CDN播放形式进行观看。然而,观看主播连麦如主播连麦PK的观众用户,往往希望在主播连麦时具有更高、更实时的参与感和互动性如打赏,上述基于常规的CDN播放形式带来的延时可能会给观看连麦的观众带来不佳的用户体验。
相应地,在根据本发明的实施例中,提供了一种直播连麦的处理方案,例如直播连麦处理方法和装置。在该实施例中,在连麦时不寻求改变主播客户端当前连接的RTC服务,而是通过检测主播客户端所使用的RTC服务类型是否相同,并在不相同时分别在各主播客户端本地加载对方所使用的RTC服务类型并仅用于拉流,与此同时仍使用原有的、可能为最佳的RTC 服务用于推流。由此,能够克服前述已知方案中可能存在的问题,以避免在某些情况下无法使用RTC服务,而只能利用例如基于TCP协议的各种推流/拉流服务,如RMTP,HLS进行连麦;也避免了在连麦时所有主播客户端均切换到相同的RTC服务进而切换到相同的云服务,造成某些主播客户端并未使用优选的云服务及RTC服务进行连麦。在本发明实施例中,虽然引入了不同的RTC服务分别用于推流和拉流,貌似增加了***的复杂度,然而本发明人发现,这种貌似增加***复杂度的方案能够在主播用户分布不同地域、不同管辖区时,有利地保留基于RTC的***的优势,如高实时性(超低延时)及高可用性(如高QoS)等。
在此,结合参考图2A、2B、图3和图4,描述根据本发明实施例的一种直播连麦处理方法。
如图4所示,所述方法可包括步骤S410至S460。
S410:发起第一主播客户端与第二主播客户端的连麦操作。
本发明的实施例适用于直播连麦场景,连麦直播的终端包括:原生APP、浏览器H5、浏览器WebRTC、微信小程序或者安装有这些元件的设备终端。本发明的实施例中特别适用于互动端和主播端连接于不同的云服务器的场景。不同的云服务器生态中,可能采用不同的实时通信(RTC)引擎。为了实现跨通信引擎直播互动,互动端和直播端上将会运行或者安装有多种不同类型的实时通信(RTC)引擎,以便能够及时接收跨云服务器域的直播流。
在本发明实施例中,直播流数据包括视频数据和/或音频数据,在直播过程中连麦,以传输视频数据和/或音频数据。在此,在示例性实施例中以视频直播为例进行描述,但可以想到根据本发明的实施例可以经改造适用于纯音频直播。
在本发明实施例中,主播作宽泛性解释,涉及参与连麦互动的参与者。由此,本发明实施例所述的主播涵盖但不限于下述情形:在连麦前作为或不作为主播、在连麦前是主播的观众、中途加入到已经进行的连麦中的主播、在连麦结束时继续或不继续作为主播。但在本发明的图示多个示例性实施例中,以所述的主播在连麦前均在作为主播提供直播作为例子,用于描述本发明实施例的技术方案,但是,本领域技术人员可以想到,基于这些例子描述的实施例可以应用于前述的或其他的情形。
在本发明实施例中,连麦具有网络直播的常规含义,其涉及至少两个或更多个(主播)用户在直播间中音频和/或视频连线。在本发明实施例中,所述连麦包括但不限于两个或更多个主播用户之间的连麦,也包括由主播发起的与其观众之间的连麦(在连麦后该观众也成为连麦“主播”)。由此,在本发明的一些实施例中,所述连麦可以包括多种形式,例如主播PK、(直播间)观众连线、(直播间)聊天室、(直播间)KTV等。
进一步地,在本发明实施例中,第一主播和第二主播在所述发起连麦操作之前的状态不作限制。例如,在发起连麦操作之前,第一主播和第二主播均在直播、均未在直播或任一个在直播,本发明实施例对此可以不作限制。
在图2A、图2B和图3所示的示例性实例中,在发起连麦之前,第一主播和第二主播均在直播。
由此,在本发明一些实施例中,在图4所示步骤S410发起第一主播客户端与第二主播客户端的连麦操作之前,所述方法可包括步骤A1至A4。
A1:所述第一主播客户端进入直播间开启直播,探测并连接最佳的第一云服务器,所述第一云服务器适配所述第一实时通信(RTC)引擎;
A2:所述第一主播客户端向服务端推送直播间信息,所述直播间信息包括所述第一实时通信(RTC)引擎的类型信息;
A3:所述第二主播客户端进入直播间开启直播,探测并连接最佳的第二云服务器,所述第二云服务器适配所述第二实时通信(RTC)引擎;
A4:所述第二主播客户端向服务端推送直播间信息,所述直播间信息包括所述第二实时通信(RTC)引擎的类型信息。
在本发明实施例中,该最佳的云服务(器)可以根据不同标准或规定来探测并确定。具体地,如图2A、图2B和图3所示的实例中,最佳的云服务(器)例如可以通过获取主播客户端能最快连接的云服务来确定该最佳的云服务器。连接最佳云服务器对于在全球大范围或者多个管辖区中提供的直播服务而言,非常有利于提升用户体验。例如,位于中国大陆的主播客户端可以最佳地连接如腾讯云(服务器),而位于东南亚的主播客户端可以最佳地连接东南亚当地的云(服务器)。
在本发明实施例中,所述不同的云服务器涉及不同的云服务产品或平台。在本文的一些实施例中,所述不同的云服务器也可能被称为不同的云服务。在本发明实施例中,所述第一和/或第二云服务(器)可以选自多种已知的云服务产品中的一种或多种,涵盖通用或专用的云服务平台,包括但不限于腾讯云、阿里云、百度云、Amazon AWS、MicrosoftAzure、Google Cloud、IBM Cloud Video等。
具体地,如在图3所示的实例中,当第一主播客户端(主播A)开启直播时,其可以向服务端也可以称为后台或后台服务推送直播间(房间) 信息,房间信息可以包括该最佳的第一云服务(器)适配的第一实时通信引擎(ARTC)、如第一实时通信SDK或API相关的信息。本发明实施例意图涵盖以下两种情形。其一,第一主播客户端在进入直播时即使用ARTC 进行推流。其二,第一主播客户端连接至该第一云服务器,且相应地确定 ARTC,其例如可用于连麦,但是在当前直播且尚未连麦时,第一主播客户端未使用ARTC进行推流,而是使用其他的推流服务。这均落入本发明的范围内。所述其他的推流服务可以是本说明书描述的那些。
第二主播客户端(主播B)也可以相应配置,在此不赘述。
在一个具体实施例中,图4所示步骤S410发起第一主播客户端与第二主播客户端的连麦操作可以包括步骤B1至B4。
B1:所述第一主播客户端向服务端发送连麦请求;
B2:响应于所述连麦请求,所述服务端将所述连麦请求以及所述第一主播直播间的房间号同步至即时消息(IM)服务;
B3:所述第二主播客户端通过所述即时消息服务接收带有所述连麦请求的即时消息;
B4:响应于所述第二主播客户端接受所述连麦请求,获取所述第一主播直播间的房间号用于建立所述连麦。
在如图3所示的具体实例中,直播服务可以集成有IM服务。由此,第一主播客户端发送至服务端如后台的连麦请求,被同步在IM服务(器)中,由此第二主播客户端的IM SDK可以向第二主播推送该连麦请求的消息。在具体实施例中,第一主播的直播间房间号显式或隐式地包含在该消息中。本领域技术人员将明白,该直播间房间号可以是伴随着连麦请求推送到后台,再同步至IM服务的;也可以是后台在接收到第一主播客户端的连麦请求后添加至同步消息的。
在本发明实施例中,即时通信(Instant Messaging,IM)服务例如可以基于植入SDK集成聊天、会话、群组、资料管理能力,实现文字、图片、短语音、短视频等富媒体消息收发。
S420:所述第一主播客户端使用本地的第一实时通信(RTC)引擎推送第一直播流。
S430:所述第二主播客户端使用本地的第二实时通信(RTC)引擎推送第二直播流。
在步骤S420和S430中,如前所述,本发明实施例将涵盖两种情形。其一、借助于RTC引擎推送直播流是在发起连麦操作之前即进行的,并可以在发起连麦操作之后持续。其二,借助于RTC引擎推送直播流是在发起连麦操作之后或者响应于连麦操作的发起而进行的,在发起连麦之前可以是如前所述的未在直播或者使用其他推流服务。这均落入本发明的范围内。
具体地,第一主播客户端可以调用本地的第一RTC SDK或API进行推流,更具体地是调用其推流组件进行推流。例如在推流组件中定义推流URL, artcpushurl=”ARTC://ARTC.Acloud.com”,其中ARTC.Acloud.com为第一云服务(器)中提供的用于第一RTC引擎(ARTC)推流的地址的示例。第二主播客户端(主播B)也可以相应配置,如在推流组件中定义推流URL, brtcpushurl=”BRTC://BRTC.Bcloud.com”,其中BRTC.Bcloud.com为第二云服务(器)中提供的用于第二RTC引擎(ARTC)推流的地址的示例。在此不赘述。
可选的S440:检测所述第一主播客户端使用的所述第一实时通信(RTC) 引擎与所述第二主播客户端所使用的所述第二实时通信(RTC)引擎是否相同。
在一些实施例中,所述步骤S440中的检测可以在后台进行。如图3所示且如前所述,第一主播客户端(主播A)和第二主播客户端(主播B)均已向后台推送了RTC引擎的类型,由此可以在后台进行比对,并在比对后发送至第一和第二主播客户端。在另一些实施例中,所述检测可以分别在第一和第二客户端中均进行,在此,后台可以响应于连麦请求的接受,向第一主播客户端发送第二主播客户端使用的RTC引擎类型(BRTC),向第二主播客户端发送第一主播客户端使用的RTC引擎类型(ARTC)。这都落入发明的范围内。
S450:当所述第一实时通信(RTC)引擎与所述第二实时通信(RTC) 引擎不相同时,所述第一主播客户端加载本地的第二实时通信(RTC)引擎,拉取所述第二主播客户端推送的所述第二直播流。
S460:当所述第一实时通信(RTC)引擎与所述第二实时通信(RTC) 引擎不相同时,所述第二主播客户端加载本地的第一实时通信(RTC)引擎,拉取所述第一主播客户端推送的所述第一直播流。
在步骤S450和S460中,第一主播客户端加载并使用第二实时通信引擎(BRTC)以观众身份进入第二主播的直播间进行拉流,例如可以调用拉流组件,例如在拉流组件中定义拉流URL, brtcplayurl=”BRTC://BRTC.Bcloud.com”。类似地,第二主播客户端加载并使用第一实时通信引擎(ARTC)以观众身份进入第一主播的直播间进行拉流,例如可以调用拉流组件,例如在拉流组件中定义拉流URL, artcplayurl=”ARTC://ARTC.Acloud.com”。
在一些实施例中,加载RTC引擎可以包括初始化RTC引擎,例如可以调用初始化组件进行初始化,这例如包括创建推流/拉流对象和/或定义相应的直播模式。
在进一步的实施例中,所述步骤S420可包括:
C1:所述第一主播客户端在未拉取所述第二直播流时,调用所述第一实时通信(RTC)引擎的声音采集模块采集所述第一直播流的声音,并使用所述第一实时通信引擎推送所述第一实时通信引擎的声音采集模块采集的声音;
C2:所述第一主播客户端在拉取所述第二直播流时,停止所述第一实时通信(RTC)引擎的声音采集模块采集所述第一直播流的声音,启用所述第一主播客户端的本地硬件采集所述第一直播流的声音,并使用所述第一实时通信引擎推送所述第一主播客户端的本地硬件采集的声音。
在具体的实施例中,所述步骤S430可包括:
D1:所述第二主播客户端在未拉取所述第一直播流时,调用所述第二实时通信(RTC)引擎的声音采集模块采集所述第二直播流的声音,并使用所述第二实时通信引擎推送所述第二实时通信引擎的声音采集模块采集的声音;
D2:所述第二主播客户端在拉取所述第一直播流时,停止所述第二实时通信(RTC)引擎的声音采集模块采集所述第二直播流的声音,并启用所述第二主播客户端的本地硬件采集所述第二直播流的声音,并使用所述第二实时通信引擎推送所述第二主播客户端的本地硬件采集的声音。
在本发明示例性实施例中,所述硬件例如为如图8所示的电子设备、如移动终端800中的麦克风837和/或耳机接口838***的耳机麦克风所采集,如下文参考图8进一步描述。在本发明示例性实施例中,在基于iOS 或安卓的电子设备中,例如可以通过调用这些***框架原生的组件/服务实现所述本地硬件采集,例如AudioUnit系列API(iOS),MediaRecorder或 AudioRecorder方法(安卓),如下文参考图9和图10进一步描述。在一些实施例中,所述声音采集可以相应地采集音频采样率、音频码率、声道数等参数。
本发明人发现,在发起多路RTC引擎推流/拉流时,可以通过停用用于推流的RTC引擎(SDK)自带的声音采集模块(组件)进行声音采集,并调用客户端本地硬件进行声音采集,获得诸多益处。例如避免了多路RTC 推流/拉流时的声音串扰。更重要的是,在多路RTC推流/拉流时,停用用于推流的RTC引擎(SDK)自带的声音采集模块(组件)进行声音采集能够便于实现回音消除。
结合参考图2A、图2B、图3,在本发明实施例中,所述方法还可以包括多个可选步骤E1至E4。
E1:第一观众客户端获取第一主播客户端使用的实时通信引擎信息,其中所述第一观众为所述第一主播的观众;
E2:所述第一观众客户端获取与第一主播客户端连麦的第二主播客户端使用的实时通信引擎信息;
E3:基于所获取的第一主播客户端使用的实时通信引擎信息,所述第一观众客户端加载本地的第一实时通信(RTC)引擎,以拉取所述第一主播客户端推送的所述第一直播流;
E4:基于所获取的第二主播客户端使用的实时通信引擎信息,所述第一观众客户端加载本地的第二实时通信(RTC)引擎,以拉取所述第二主播客户端推送的所述第二直播流。
更进一步地,所述方法还可以包括多个可选步骤E5至E8。
E5:第二观众客户端获取第二主播客户端使用的实时通信引擎信息,其中所述第二观众为所述第二主播的观众;
E6:所述第二观众客户端获取与第二主播客户端连麦的第一主播客户端使用的实时通信引擎信息;
E7:基于所获取的第二主播客户端使用的实时通信引擎信息,所述第二观众客户端加载本地的第二实时通信(RTC)引擎,以拉取所述第二主播客户端推送的所述第二直播流;
E8:基于所获取的第一主播客户端使用的实时通信引擎信息,所述第二观众客户端加载本地的第一实时通信(RTC)引擎,以拉取所述第一主播客户端推送的所述第一直播流。
在这些实施例中,能够使得至少部分观众用户无需通过CDN进行播放,而是能够充分利用RTC的优势。由此,观看主播连麦如主播PK的观众用户能够在主播连麦时具有更高、更实时的参与感和互动性、如打赏,上述基于常规的CDN播放形式带来的延时可能会给观看连麦的观众带来不佳的用户体验。
如图2A最佳地示出,对于主播A的观众C,其可以加载ARTC拉取主播A的第一直播流,并同时加载BRTC拉取主播B的第二直播流。相关 RTC引擎的加载和拉取可以参考上述实施例的描述,在此不赘述。在如图所示的实施例中,可选地可以在第一观众客户端(观众C)中对主播A的第一直播流和主播B的第二直播流进行混流(且可选地进行回音消除),以得到AB混流,并进行播放。可选地,例如针对视频直播流可以不进行混流,而按照观众C是哪位主播的观众,而在用户界面的相应容器中呈现直播流,如对于观众C而言,在图11所示的左部呈现主播A的直播,右部呈现主播 B的直播。
如图2B最佳地示出,对于主播B的观众D,其可以加载BRTC拉取主播B的第二直播流,并同时加载ARTC拉取主播A的第一直播流。相关RTC 引擎的加载和拉取可以参考上述实施例的描述,在此不赘述。在如图所示的实施例中,可选地可以在第二观众客户端(观众D)中对主播B的第二直播流和主播A的第一直播流进行混流(且可选地进行回音消除),以得到BA混流,并进行播放。可选地,例如针对视频直播流可以不进行混流,而按照观众D是哪位主播的观众,而在用户界面的相应容器中呈现直播流,如对于观众D而言,在图11所示的左部呈现主播B的直播,右部呈现主播 A的直播。
在本发明的进一步优选实施例中,可以提供基于RTC和其他类型推流/ 拉流服务的混合方案。由此,在进一步的实施例中,所示方法可以进一步包括步骤E9-E12。
E9:所述第一主播客户端对所述第一直播流和第二直播流混流,形成第一混合直播流,并推送所述第一混合直播流;
E10:所述第二主播客户端对所述第二直播流和第一直播流混流,形成第二混合直播流,并推送所述第二混合直播流;
E11:第三观众客户端通过内容分发网络(CDN)拉取所述第一混合直播流,其中所述第三观众为所述第一主播的观众;
E12:第四观众客户端通过内容分发网络(CDN)拉取所述第二混合直播流,其中所述第四观众为所述第二主播的观众。
类似地,在这些实施例中(图2A、图2B、图3未示出),所述混流时可选地可做回音消除。
在涉及E9至E12的实施例中,推送混合流(推流)服务/基于CDN的拉流服务可以是基于各种已知的推流/拉流服务实现的,例如基于TCP协议或者UDP协议实现的,包括但不限于RTSP、HLS、RTMP、FLV服务。
RTSP(Real Time Streaming Protocol实时流协议)是由Real Network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。在一些实施例中,可以在基于Android的触屏终端采用所述RTSP。
HLS(HTTP Live Streaming超文本传输协议实时流)协议是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X 和iPhone软件***的一部分。在一些实施例中,可以在基于iOS的触屏终端或Apple公司提供的触屏终端采用所述HLS。
RTMP(Real-Time Messaging Protocol实时消息传送协议)是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的协议。在一些实施例中,可以在支持Flash的触屏终端中采用所述RTMP。
FLV(Flash Video)是Adobe公司推出的另一种视频格式,是一种在网络上传输的流媒体数据存储容器格式。
在一些实施例中,推流端(在此例如为第一和第二主播端)可以基于 Qos算法将音视频流数据通过网络推送到服务端,并由所述服务端例如借助CDN分发。
作为解释而非限制地,在本发明实施例中提供基于RTC和其他类型推流/拉流服务(并通过CDN)的混合方案可能具有特别的优势,例如针对某些用户,如某主播的活跃用户,能够以更高实时性参与直播连麦如PK,而同时可以以相对低廉的成本向普通的直播连麦观众提供仍能令人满意的直播播放服务。
在本发明实施例中,提供了基于两个主播端的连麦,但是可以想到根据本发明的实施例可以应用于多于两个主播端的连麦,例如3个、4个以及高达32个主播端的连麦。
在本发明的实施例中,还可以提供在连麦发起端实现的连麦处理方法。例如所述直播连麦处理方法可以由第一主播客户端实施。
如图5所示的实施例中,所述方法可包括:
S510:发送与第二主播客户端连麦的连麦请求;
S520:使用本地的第一实时通信(RTC)引擎推送第一直播流;
S530:响应于第二主播客户端接受所述连麦请求,检测所述第一实时通信(RTC)引擎是否与所述第二主播客户端所使用的第二实时通信(RTC) 引擎相同;
S540:当所述第一实时通信(RTC)引擎与所述第二实时通信(RTC) 引擎不相同时,加载本地的第二实时通信(RTC)引擎,以拉取所述第二主播客户端推送的第二直播流;
S550:对所述第一直播流和第二直播流混流,形成第一混合直播流,并向服务端推送所述第一混合直播流。
相应地,在本发明的实施例中,还可以提供在连麦接收端实现的连麦处理方法。例如所述直播连麦处理方法可以由第二主播客户端实施。
如图6所示,所述方法可包括:
S610:接受第一主播客户端发送的连麦请求;
S620:使用本地的第二实时通信(RTC)引擎推送第二直播流;
S630:响应于接受第一主播客户端发送的连麦请求,检测所述第一主播客户端所使用的第一实时通信(RTC)引擎是否与所述第二实时通信(RTC) 引擎相同;
S640:当所述第一实时通信(RTC)引擎与所述第二实时通信(RTC) 引擎不相同时,加载本地的第一实时通信(RTC)引擎,并拉取所述第一主播客户端推送的第一直播流;
S650:对所述第二直播流和第一直播流混流,形成第二混合直播流,并向服务端推送所述第二混合直播流。
本领域技术人员将明白,由主播客户端实施的方法特征可以在根据需要应用于由***实施的方法实施例中获得新的实施例。
在图7所示的实施例中,还提供了一种直播连麦处理装置700,其包括连麦发起单元710、第一推流单元720、第二推流单元730、可选的检测单元740、第一拉流单元750、第二拉流单元760。在所示实施例中,所述连麦发起单元710可配置成发起第一主播客户端与第二主播客户端的连麦操作。所述第一推流单元720可配置成使得所述第一主播客户端使用本地的第一实时通信(RTC)引擎推送第一直播流。所述第二推流单元730可配置成使得所述第二主播客户端使用本地的第二实时通信(RTC)引擎推送第二直播流。所述检测单元740可配置成检测所述第一主播客户端使用的所述第一实时通信(RTC)引擎与所述第二主播客户端所使用的所述第二实时通信(RTC)引擎是否相同。所述第一拉流单元750可配置成当所述第一实时通信(RTC)引擎与所述第二实时通信(RTC)引擎不相同时,使得所述第一主播客户端加载本地的第二实时通信(RTC)引擎,拉取所述第二主播客户端推送的所述第二直播流。所述第二拉流单元760可配置成当所述第一实时通信(RTC)引擎与所述第二实时通信(RTC)引擎不相同时,使得所述第二主播客户端加载本地的第一实时通信(RTC)引擎,拉取所述第一主播客户端推送的所述第一直播流。
本领域技术人员将明白,在不引起矛盾的情况下,本实施例的装置可以结合其他实施例所述的方法特征,反之则反。
在本发明的实施例中提供了一种电子设备。在本发明的一个优选实施例中,所述电子设备为移动终端,优选可以为手机。仅作为示例性的实现方案,图8示出了触屏终端、如移动终端800的一个具体实施例的硬件结构示意图;而图9和图10示出了电子设备、如移动终端的一个具体实施例的***结构示意图。
具体地,在本发明的一些实施例中,还可以提供一种直播客户端,所述直播客户端可以为例如图8所示的电子设备,如移动终端,优选为手机。
在一些实施例中,所述直播客户端为第一主播客户端。在一些实施例中,所述直播客户端为第二主播客户端。在一些实施例中,所述直播客户端为第一观众客户端。在一些实施例中,所述直播客户端为第二观众客户端。
在一些实施例中,所述直播客户端为第三观众客户端。在一些实施例中,所述直播客户端为第四观众客户端。本领域技术人员将明白,在不引起矛盾的情况下,这些实施例的客户端可以结合其他实施例所述的相对应的方法特征,反之则反。
在图8所示出的实施例中,移动终端800可以包括处理器801、外部存储器接口812、内部存储器810、通用串行总线(USB)接口813、充电管理模块814、电源管理模块815、电池816、移动通信模块840、无线通信模块 842、天线839和841、音频模块834、扬声器835、受话器836、麦克风837、耳机接口838、按键809、马达808、指示器807、用户标识模块(SIM)卡接口811、显示屏805、摄像装置806,以及传感器模块820等。
可以理解的是,本申请实施例示意的结构并不构成对移动终端800的具体限定。在本申请另一些实施例中,移动终端800可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和硬件的组合实现。
在一些实施例中,处理器801可以包括一个或一个以上处理单元。在一些实施例中,处理器801可以包括以下之一或以下至少两种的组合:应用处理器(AP)、调制解调处理器、基带处理器、图形处理器(GPU)、图像信号处理器(ISP)、控制器、存储器、视频编解码器、数字信号处理器(DSP)、基带处理器、神经网络处理器(NPU)等。不同的处理单元可以是独立的器件,也可以集成在一个或一个以上处理器中。
控制器可以是移动终端800的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号,产生操作控制信号,完成取指令和执行指令的控制。
处理器中还可以设置存储器,用于存储指令和数据。在一些实施例中,处理器中的存储器为高速缓冲存储器。该存储器可以保存处理器刚用过或循环使用的指令或数据。如果处理器需要再次使用该指令或数据,可从所述存储器中直接调用。避免了重复存取,减少了处理器801的等待时间,因而提高了***的效率。
NPU为神经网络(NN)计算处理器,通过借鉴生物神经网络结构,例如借鉴人脑神经元之间传递模式,对输入信息快速处理,还可以不断地自学习。
GPU为图像处理的微处理器,连接显示屏和应用处理器。GPU用于执行数学和几何计算,用于图形渲染。处理器可包括一个或多个GPU,其执行程序指令以生成或改变显示信息。
数字信号处理器(ISP)用于处理数字信号,除了可以处理数字图像信号,还可以处理其他数字信号。
在一些实施例中,处理器801可以包括一个或多个接口。接口可以包括集成电路(I2C)接口、集成电路内置音频(I2S)接口、脉冲编码调制(PCM) 接口、通用异步收发传输器(UART)接口、移动产业处理器接口(MIPI)、通用输入输出(GPIO)接口、用户标识模块(SIM)接口、通用串行总线 (USB)接口等。
可以理解的是,本申请实施例示意的各模块间的接口连接关系,只是示意性说明,并不构成对移动终端的结构限定。在本申请另一些实施例中,移动终端也可以采用上述实施例中不同的接口连接方式,或多种接口连接方式的组合。
移动终端800的无线通信功能可以通过天线839和841、移动通信模块 840、无线通信模块842、调制解调处理器或基带处理器等实现。
移动终端800可以通过音频模块、扬声器、受话器、麦克风、耳机接口,以及应用处理器等实现音频功能。例如音乐播放,录音等。
音频模块用于将数字音频信息转换成模拟音频信号输出,也用于将模拟音频输入转换为数字音频信号。
麦克风用于将声音信号转换为电信号。当拨打电话或发送语音信息时,用户可以通过人嘴靠近麦克风发声,将声音信号输入到麦克风。
传感器模块820可包括下述传感器中的一个或多个:
压力传感器823配置为感受压力信号,将压力信号转换成电信号。
气压传感器824用于测量气压。
磁传感器825包括霍尔传感器。
陀螺仪传感器827可以用于确定移动终端800的运动姿态。
加速度传感器828可检测移动终端800在各个方向上加速度的大小。
距离传感器829可配置为测量距离。
接近光传感器821可以包括例如发光二极管(LED)和光检测器,例如光电二极管。
环境光传感器822用于感知环境光亮度。
指纹传感器831可配置为采集指纹。
触摸传感器832可以设置于显示屏,由触摸传感器与显示屏组成触摸屏,也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器,以确定根据本发明实施例所述的触摸事件类型,例如单击、双击、长按、旋转、滑动、缩放等等。
骨传导传感器833可以获取振动信号。
电子设备(计算机)、如移动终端的软件操作***可以采用分层架构、事件驱动架构、微核架构、微服务架构或云架构。
本文所示的实施例以分层架构的分别以iOS和安卓操作***平台为例,示例性说明移动终端的软件结构。但可以想到,本文的实施例可以在不同的软件操作***中实施。
在图9所示的实施例中,本发明实施例的方案可以采用iOS操作***。 iOS操作***采用四层架构,由上到下依次为可触摸层(Cocoa Touch layer) 910、媒体层(Medialayer)920、核心服务层(Core Services layer)930以及核心操作***层(Core OS layer)940。触摸层910为应用程序开发提供了各种常用的框架并且大部分框架与界面有关,其负责用户在iOS设备上的触摸交互操作。媒体层提供应用中视听方面的技术,如图形图像、声音技术、视频以及音视频传输相关的框架等。核心服务层提供给应用所需要的基础的***服务。核心操作***层包含大多数低级别接近硬件的功能。
在本发明实施例中,UIKit是可触摸层910的用户界面框架。
图10是安卓操作***结构示意图,本发明实施例的方案可以采用安卓操作***。分层架构将软件分成若干个层,层间通过软件接口通信。在一些实施例中,将安卓***分为四层,从上至下分别为应用程序层1010、应用程序框架层1020、安卓运行时(Runtime)和***库1030、以及内核层 1040。
应用程序层1010可以包括一系列应用程序包。
应用程序框架层1020为应用程序层的应用程序提供应用编程接口(API) 和编程框架。应用程序框架层包括一些预先定义的函数。
窗口管理器用于管理窗口程序。
内容提供器用来存放和获取数据,并使这些数据可以被应用程序访问。
视图***包括可视控件,例如显示文字的控件,显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如,包括短信通知图标的显示界面,可以包括显示文字的视图以及显示图片的视图。
电话管理器用于提供移动终端的通信功能。
资源管理器为应用程序提供各种资源,比如本地化字符串,图标,图片,布局文件,视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息,可以用于传达告知类型的消息,可以短暂停留后自动消失,无需用户交互。
安卓Runtime(运行时)包括核心库和虚拟机,安卓Runtime负责安卓***的调度和管理。核心库包含两部分:一部分是java语言要调用的功能函数,另一部分是安卓的核心库。应用程序层和框架层运行在虚拟机中。
***库可以包括多个功能模块。表面管理器用于对显示子***进行管理,并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频,视频格式回放和录制,以及静态图像文件等。
内核层1040是硬件和软件之间的层。内核层可包含显示驱动、摄像头驱动、音频接口、传感器驱动、电源管理和GPS接口。在本发明的一些实施例中,帧动画的显示可以调用显示驱动。
在本发明的一些实施例中,还可以提供一种电子设备,其包括:处理器和存储有计算机程序的存储器,所述处理器被配置为在运行计算机程序时执行任一本发明实施例的方法。
在本发明上述或下述实施例阐明的***、装置、模块或单元,可以由计算机或其关联部件实现。根据具体情况,计算机例如可以为移动终端、智能电话、个人计算机(PC)、膝上型计算机、车载人机交互设备、个人数字助理、媒体播放器、导航设备、游戏控制台、平板电脑、可穿戴设备、智能电视、物联网***、智能家居、工业计算机、服务器或者其组合。
在本发明的一些实施例中,还可以提供一种存储介质。在一些实施例中,所述存储介质存储有计算机程序,所述计算机程序配置成被运行时执行任一本发明实施例所述的方法。
在本发明的实施例的存储介质包括永久性和非永久性、可移动和非可移动的可以由任何方法或技术来实现信息存储的物品。存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。
在本发明的实施例的方法、程序、***、装置等,可以在单个或多个连网的计算机中执行或实现,也可以在分布式计算环境中实践。在本说明书实施例中,在这些分布式计算环境中,可以由通过通信网络而被连接的远程处理设备来执行任务。
本领域技术人员应明白,本说明书的实施例可提供为方法、***或计算机程序产品。因此,本领域技术人员可想到,上述实施例阐明的功能模块/单元或控制器以及相关方法步骤的实现,可以用软件、硬件和软/硬件结合的方式实现。
除非明确指出,根据本发明实施例记载的方法、程序的动作或步骤并不必须按照特定的顺序来执行并且仍然可以实现期望的结果。在某些实施方式中,各步骤的多任务处理和并行/合并处理也是可以的或者可能是有利的。
在本文中,“第一”、“第二”是用于在同一实施例中区分不同的元件,不指代顺序或相对重要性。
在本文中,针对本发明的多个实施例进行了描述,但为简明起见,各实施例的描述并不是详尽的,各个实施例之间相同或相似的特征或部分可能会被省略。在本文中,“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”意指适用于根据本发明的至少一个实施例或示例中,而非所有实施例。上述术语并不必然意味着指代相同的实施例或示例。在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
已参考上述实施例具体示出并描述了本发明的示例性***及方法,其仅为实施本***及方法的最佳模式的示例。本领域的技术人员可以理解的是可以在实施本***及/或方法时对这里描述的***及方法的实施例做各种改变而不脱离界定在所附权利要求中的本发明的精神及范围。

Claims (11)

1.一种直播连麦处理方法,其特征在于,包括:
第一主播客户端发起与第二主播客户端的连麦操作;
所述第一主播客户端使用本地的第一实时通信引擎推送第一直播流;
所述第二主播客户端使用本地的第二实时通信引擎推送第二直播流;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,所述第一主播客户端加载本地的第二实时通信引擎,拉取所述第二主播客户端推送的所述第二直播流;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,所述第二主播客户端加载本地的第一实时通信引擎,拉取所述第一主播客户端推送的所述第一直播流。
2.根据权利要求1所述的方法,其特征在于,还包括:
第一观众客户端获取第一主播客户端使用的第一实时通信引擎的信息,其中第一观众为第一主播的观众;
所述第一观众客户端获取与第一主播客户端连麦的第二主播客户端使用的第二实时通信引擎的信息;
基于所获取的第一主播客户端使用的第一实时通信引擎的信息,所述第一观众客户端加载本地的第一实时通信引擎,以拉取所述第一主播客户端推送的所述第一直播流;
基于所获取的第二主播客户端使用的第二实时通信引擎的信息,所述第一观众客户端加载本地的第二实时通信引擎,以拉取所述第二主播客户端推送的所述第二直播流。
3.根据权利要求1所述的方法,其特征在于,还包括:
第二观众客户端获取第二主播客户端使用的第二实时通信引擎信息,其中第二观众为第二主播的观众;
所述第二观众客户端获取与第二主播客户端连麦的第一主播客户端使用的第一实时通信引擎的信息;
基于所获取的第二主播客户端使用的第二实时通信引擎的信息,所述第二观众客户端加载本地的第二实时通信引擎,以拉取所述第二主播客户端推送的所述第二直播流;
基于所获取的第一主播客户端使用的第一实时通信引擎的信息,所述第二观众客户端加载本地的第一实时通信引擎,以拉取所述第一主播客户端推送的所述第一直播流。
4.根据权利要求1所述的方法,其特征在于,还包括:
所述第一主播客户端对所述第一直播流和第二直播流混流,形成第一混合直播流,并推送所述第一混合直播流;
所述第二主播客户端对所述第二直播流和第一直播流混流,形成第二混合直播流,并推送所述第二混合直播流;
第三观众客户端通过内容分发网络拉取所述第一混合直播流,其中第三观众为第一主播的观众;
第四观众客户端通过内容分发网络拉取所述第二混合直播流,其中第四观众为第二主播的观众。
5.根据权利要求1至4中任一项所述的方法,其特征在于,所述第一主播客户端使用本地的第一实时通信引擎推送第一直播流,包括:
所述第一主播客户端在未拉取所述第二直播流时,调用所述第一实时通信引擎的声音采集模块采集所述第一直播流的声音,并使用所述第一实时通信引擎推送所述第一实时通信引擎的声音采集模块采集的声音;
所述第一主播客户端在拉取所述第二直播流时,停止所述第一实时通信引擎的声音采集模块采集所述第一直播流的声音,启用所述第一主播客户端的本地硬件采集所述第一直播流的声音,并使用所述第一实时通信引擎推送所述第一主播客户端的本地硬件采集的声音;
所述第二主播客户端使用第二实时通信引擎推送第二直播流,包括:
所述第二主播客户端在未拉取所述第一直播流时,调用所述第二实时通信引擎的声音采集模块采集所述第二直播流的声音,并使用所述第二实时通信引擎推送所述第二实时通信引擎的声音采集模块采集的声音;
所述第二主播客户端在拉取所述第一直播流时,停止所述第二实时通信引擎的声音采集模块采集所述第二直播流的声音,启用所述第二主播客户端的本地硬件采集所述第二直播流的声音,并使用所述第二实时通信引擎推送所述第二主播客户端的本地硬件采集的声音。
6.根据权利要求1至4中任一项所述的方法,其特征在于,所述第一主播客户端发起与第二主播客户端的连麦操作,包括:
所述第一主播客户端向服务端发送连麦请求;
响应于所述连麦请求,所述服务端将所述连麦请求以及第一主播直播间的房间号同步至即时消息服务;
所述第二主播客户端通过所述即时消息服务接收所述连麦请求;
响应于所述第二主播客户端接受所述连麦请求,通过所述即时消息服务获取所述第一主播直播间的房间号用于建立所述连麦。
7.根据权利要求1至4中任一项所述的方法,其特征在于,在所述第一主播客户端发起与第二主播客户端的连麦操作之前,所述方法还包括:
所述第一主播客户端进入直播间开启直播,探测并连接最佳的第一云服务器,所述第一云服务器适配所述第一实时通信引擎;
所述第一主播客户端向服务端推送直播间信息,所述直播间信息包括所述第一实时通信引擎的类型信息;
所述第二主播客户端进入直播间开启直播,探测并连接最佳的第二云服务器,所述第二云服务器适配所述第二实时通信引擎;
所述第二主播客户端向服务端推送直播间信息,所述直播间信息包括所述第二实时通信引擎的类型信息。
8.一种直播连麦处理方法,其特征在于,由第一主播客户端实施,所述方法包括:
发送与第二主播客户端连麦的连麦请求;
使用本地的第一实时通信引擎推送第一直播流;
响应于第二主播客户端接受所述连麦请求,检测所述第一实时通信引擎是否与所述第二主播客户端所使用的第二实时通信引擎相同;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,加载本地的第二实时通信引擎,以拉取所述第二主播客户端推送的第二直播流;
对所述第一直播流和第二直播流混流,形成第一混合直播流,并向服务端推送所述第一混合直播流。
9.一种直播连麦处理方法,其特征在于,由第二主播客户端实施,所述方法包括:
接受第一主播客户端发送的连麦请求;
使用本地的第二实时通信引擎推送第二直播流;
响应于接受第一主播客户端发送的连麦请求,检测所述第一主播客户端所使用的第一实时通信引擎是否与所述第二实时通信引擎相同;
当所述第一实时通信引擎与所述第二实时通信引擎不相同时,加载本地的第一实时通信引擎,并拉取所述第一主播客户端推送的第一直播流;
对所述第二直播流和第一直播流混流,形成第二混合直播流,并向服务端推送所述第二混合直播流。
10.一种电子设备,其特征在于,包括:处理器和存储有计算机程序的存储器,所述处理器被配置为在运行计算机程序时执行权利要求1至9中任一项所述的方法。
11.一种存储介质,其特征在于,所述存储介质存储有计算机程序,所述计算机程序配置成被运行时执行权利要求1至9中任一项所述的方法。
CN202111394818.2A 2021-11-23 直播连麦处理方法、电子设备及存储介质 Active CN114125482B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111394818.2A CN114125482B (zh) 2021-11-23 直播连麦处理方法、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111394818.2A CN114125482B (zh) 2021-11-23 直播连麦处理方法、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN114125482A true CN114125482A (zh) 2022-03-01
CN114125482B CN114125482B (zh) 2024-06-28

Family

ID=

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115065832A (zh) * 2022-05-07 2022-09-16 武汉斗鱼鱼乐网络科技有限公司 一种基于WebRtc的直播方法及相关设备
CN115119010A (zh) * 2022-06-29 2022-09-27 北京奇艺世纪科技有限公司 连麦方法、装置、电子设备和存储介质
CN115996213A (zh) * 2022-12-29 2023-04-21 百果园技术(新加坡)有限公司 直播连麦处理方法及其装置、设备、介质
WO2023241575A1 (zh) * 2022-06-16 2023-12-21 抖音视界(北京)有限公司 连麦建立方法、装置、设备、存储介质及程序产品
CN117499688A (zh) * 2023-12-29 2024-02-02 淘宝(中国)软件有限公司 直播连麦中音视频合流处理方法、设备及存储介质

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002334029A (ja) * 2001-05-10 2002-11-22 Ntt Docomo Inc データ配信方法、データ配信システム及びデータ配信設備
US20140115180A1 (en) * 2012-10-19 2014-04-24 Gustavo Neiva de Medeiros Multi-platform content streaming
CN103841353A (zh) * 2014-02-24 2014-06-04 广州华多网络科技有限公司 视频交互方法、终端、服务器及***
US20160164761A1 (en) * 2014-12-03 2016-06-09 Edgecast Networks, Inc. Stream monitoring across a distributed platform
CN106254899A (zh) * 2016-08-16 2016-12-21 网宿科技股份有限公司 一种直播连麦的控制方法和***
CN107027048A (zh) * 2017-05-17 2017-08-08 广州市千钧网络科技有限公司 一种直播连麦及信息展示的方法及装置
CN107707533A (zh) * 2017-09-18 2018-02-16 深圳市迅雷网文化有限公司 基于Web的连麦方法、***及存储介质
CN107846633A (zh) * 2016-09-18 2018-03-27 腾讯科技(深圳)有限公司 一种直播方法及***
CN108076349A (zh) * 2016-11-11 2018-05-25 铂渊信息技术(上海)有限公司 网络互动直播方法、***及电子设备
WO2018121015A1 (zh) * 2016-12-30 2018-07-05 广州华多网络科技有限公司 客户端连麦直播处理方法和装置
US20180255114A1 (en) * 2017-03-06 2018-09-06 Vyu Labs, Inc. Participant selection for multi-party social media sessions
CN109819285A (zh) * 2017-11-21 2019-05-28 乐蜜有限公司 一种直播方法、装置、电子设备及存储介质
WO2019114129A1 (zh) * 2017-12-13 2019-06-20 平安科技(深圳)有限公司 推流服务器的调度装置、方法及计算机可读存储介质
CN111355971A (zh) * 2020-02-20 2020-06-30 北京金山云网络技术有限公司 直播流传输方法、装置、cdn服务器及计算机可读介质
CN111565334A (zh) * 2020-04-30 2020-08-21 广州酷狗计算机科技有限公司 直播回放方法、装置、终端、服务器及存储介质
CN111818394A (zh) * 2019-12-11 2020-10-23 厦门雅基软件有限公司 云游戏直播方法、客户端及计算机可读存储介质
CN112019927A (zh) * 2020-09-23 2020-12-01 Oppo广东移动通信有限公司 视频直播方法、连麦设备、rtc媒体服务器及主播设备
CN112312226A (zh) * 2020-10-28 2021-02-02 北京达佳互联信息技术有限公司 连麦方法、***、装置、电子设备及存储介质
CN112714131A (zh) * 2020-12-31 2021-04-27 北京大米科技有限公司 一种跨平台连麦的方法、装置、存储介质及电子设备
CN113038191A (zh) * 2021-02-26 2021-06-25 北京百度网讯科技有限公司 直播流的调度方法、装置、电子设备及可读存储介质

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002334029A (ja) * 2001-05-10 2002-11-22 Ntt Docomo Inc データ配信方法、データ配信システム及びデータ配信設備
US20140115180A1 (en) * 2012-10-19 2014-04-24 Gustavo Neiva de Medeiros Multi-platform content streaming
CN103841353A (zh) * 2014-02-24 2014-06-04 广州华多网络科技有限公司 视频交互方法、终端、服务器及***
US20160164761A1 (en) * 2014-12-03 2016-06-09 Edgecast Networks, Inc. Stream monitoring across a distributed platform
CN106254899A (zh) * 2016-08-16 2016-12-21 网宿科技股份有限公司 一种直播连麦的控制方法和***
CN107846633A (zh) * 2016-09-18 2018-03-27 腾讯科技(深圳)有限公司 一种直播方法及***
CN108076349A (zh) * 2016-11-11 2018-05-25 铂渊信息技术(上海)有限公司 网络互动直播方法、***及电子设备
WO2018121015A1 (zh) * 2016-12-30 2018-07-05 广州华多网络科技有限公司 客户端连麦直播处理方法和装置
US20180255114A1 (en) * 2017-03-06 2018-09-06 Vyu Labs, Inc. Participant selection for multi-party social media sessions
CN107027048A (zh) * 2017-05-17 2017-08-08 广州市千钧网络科技有限公司 一种直播连麦及信息展示的方法及装置
CN107707533A (zh) * 2017-09-18 2018-02-16 深圳市迅雷网文化有限公司 基于Web的连麦方法、***及存储介质
CN109819285A (zh) * 2017-11-21 2019-05-28 乐蜜有限公司 一种直播方法、装置、电子设备及存储介质
WO2019114129A1 (zh) * 2017-12-13 2019-06-20 平安科技(深圳)有限公司 推流服务器的调度装置、方法及计算机可读存储介质
CN111818394A (zh) * 2019-12-11 2020-10-23 厦门雅基软件有限公司 云游戏直播方法、客户端及计算机可读存储介质
CN111355971A (zh) * 2020-02-20 2020-06-30 北京金山云网络技术有限公司 直播流传输方法、装置、cdn服务器及计算机可读介质
CN111565334A (zh) * 2020-04-30 2020-08-21 广州酷狗计算机科技有限公司 直播回放方法、装置、终端、服务器及存储介质
CN112019927A (zh) * 2020-09-23 2020-12-01 Oppo广东移动通信有限公司 视频直播方法、连麦设备、rtc媒体服务器及主播设备
CN112312226A (zh) * 2020-10-28 2021-02-02 北京达佳互联信息技术有限公司 连麦方法、***、装置、电子设备及存储介质
CN112714131A (zh) * 2020-12-31 2021-04-27 北京大米科技有限公司 一种跨平台连麦的方法、装置、存储介质及电子设备
CN113038191A (zh) * 2021-02-26 2021-06-25 北京百度网讯科技有限公司 直播流的调度方法、装置、电子设备及可读存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
侯艳君;: "融合广电+网络直播的技术实现方案研究", 传媒论坛, no. 09 *
彭永超;费昊;: "基于Webrtc和PWA的视频互动直播***", 电脑编程技巧与维护, no. 02 *
赵永明;: "基于WebRTC的音视频实时教学***建设探究", 数字通信世界, no. 08, 1 August 2020 (2020-08-01) *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115065832A (zh) * 2022-05-07 2022-09-16 武汉斗鱼鱼乐网络科技有限公司 一种基于WebRtc的直播方法及相关设备
WO2023241575A1 (zh) * 2022-06-16 2023-12-21 抖音视界(北京)有限公司 连麦建立方法、装置、设备、存储介质及程序产品
CN115119010A (zh) * 2022-06-29 2022-09-27 北京奇艺世纪科技有限公司 连麦方法、装置、电子设备和存储介质
CN115119010B (zh) * 2022-06-29 2023-07-25 北京奇艺世纪科技有限公司 连麦方法、装置、电子设备和存储介质
CN115996213A (zh) * 2022-12-29 2023-04-21 百果园技术(新加坡)有限公司 直播连麦处理方法及其装置、设备、介质
CN117499688A (zh) * 2023-12-29 2024-02-02 淘宝(中国)软件有限公司 直播连麦中音视频合流处理方法、设备及存储介质
CN117499688B (zh) * 2023-12-29 2024-05-03 淘宝(中国)软件有限公司 直播连麦中音视频合流处理方法、设备及存储介质

Similar Documents

Publication Publication Date Title
US11405678B2 (en) Live streaming interactive method, apparatus, electronic device, server and storage medium
CN103166941B (zh) 一种数据分享的方法及装置
CN103491179B (zh) 基于Web的多屏互动方法及***
US8738783B2 (en) System for interaction of paired devices
CN107371044B (zh) 电子设备互动方法、电子设备、用户终端及服务器
WO2020010819A1 (zh) 基于直播间的数据交互方法、装置、终端和存储介质
US20150304712A1 (en) Method, apparatus, and system for transferring digital media content playback
CN105323628B (zh) 基于dlna跨屏播放的方法及***、浏览器端装置和播放装置
CN109413453B (zh) 视频播放方法、装置、终端及存储介质
CN109194972B (zh) 直播流获取方法、装置、计算机设备及存储介质
CN113141524B (zh) 资源传输方法、装置、终端及存储介质
WO2010147433A2 (en) Apparatus and method for transmitting and receiving a user interface in a communication system
US11671556B2 (en) Method of performing video call and display device
CN113535063A (zh) 直播页面切换方法、视频页面切换方法、电子设备及存储介质
CN106341702A (zh) 一种基于电视节目的互动方法及移动终端
JP2023528958A (ja) ビデオ複合撮影方法、装置、電子機器及びコンピュータ可読媒体
CN112118477A (zh) 虚拟礼物展示方法、装置、设备以及存储介质
CN106998490A (zh) 一种多媒体数据同步方法及装置
CN113590059A (zh) 一种投屏方法及移动终端
CN113741762A (zh) 一种多媒体播放方法、装置、电子设备和存储介质
US9733888B2 (en) Method for rendering data in a network and associated mobile device
US20230051868A1 (en) Livestreaming Interaction Method And Apparatus, Electronic Device, And Computer Readable Storage Medium
CN112055252A (zh) 多屏互动方法、装置、计算机可读介质及电子设备
CN112565657A (zh) 通话互动方法、装置、设备及存储介质
CN114125482B (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