CN115065832A - 一种基于WebRtc的直播方法及相关设备 - Google Patents

一种基于WebRtc的直播方法及相关设备 Download PDF

Info

Publication number
CN115065832A
CN115065832A CN202210491810.6A CN202210491810A CN115065832A CN 115065832 A CN115065832 A CN 115065832A CN 202210491810 A CN202210491810 A CN 202210491810A CN 115065832 A CN115065832 A CN 115065832A
Authority
CN
China
Prior art keywords
stream
client
rtc
live
server
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
CN202210491810.6A
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.)
Wuhan Douyu Network Technology Co Ltd
Original Assignee
Wuhan Douyu Network 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 Wuhan Douyu Network Technology Co Ltd filed Critical Wuhan Douyu Network Technology Co Ltd
Priority to CN202210491810.6A priority Critical patent/CN115065832A/zh
Publication of CN115065832A publication Critical patent/CN115065832A/zh
Pending legal-status Critical Current

Links

Images

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
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种基于WebRtc的直播方法及相关设备。该方法包括：接收第一客户端发送的RTC直播流；将上述RTC直播流以UDP协议方式发送到RTC流媒体系统；将上述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。通过本申请实施例提供的直播方法，不仅降低了直播延时，还为观众提供了多种拉流方式，丰富了直播的拉流方式，并可以在一定程度上降低RTC拉流时服务器的负荷。

Description

一种基于WebRtc的直播方法及相关设备
技术领域
本说明书涉及直播领域，更具体地说，本发明涉及一种基于WebRtc的直播方法及相关设备。
背景技术
在当前的直播过程中，通常采用CDN推流的方式，CDN推流通常采用TCP协议进行数据传输，虽然保证了直播数据的可靠性，但数据丢失后会一直重传，会导致直播过程的延时大大增加，直播转推的过程和播放端会缓存大量的数据，导致直播的延时较高。
发明内容
在发明内容部分中引入了一系列简化形式的概念，这将在具体实施方式部分中进一步详细说明。本发明的发明内容部分并不意味着要试图限定出所要求保护的技术方案的关键特征和必要技术特征，更不意味着试图确定所要求保护的技术方案的保护范围。
为了提出一种低延迟，高稳定性的直播方案，第一方面，本发明提出一种基于WebRtc的直播方法，上述方法包括：
接收第一客户端发送的RTC直播流；
将上述RTC直播流以UDP协议方式发送到RTC流媒体系统；
将上述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。
可选的，上述服务器是根据上述第一客户端发送的推流服务地址确定的。
可选的，在上述接收第一客户端发送的RTC直播流的步骤之前，还包括：
接收上述第一客户端发送的信令交互信息，其中，上述信令交互信息包括joinchannel信令和publish_stream信令；
与上述第一客户端进行publish_stream信令交互，以使上述服务器和上述第一客户端建立传输链路；
根据上述joinchannel信令管理上述第一客户端对应的直播房间。
可选的，上述与上述第一客户端进行publish_stream信令交互，以使和上述第一客户端建立传输链路，包括：
基于上述publish_stream信令交互，确定与上述第一客户端执行推流操作的媒体会话描述信息和交互式连接建立信息；
根据上述媒体会话描述信息和上述交互式连接建立信息与上述第一客户端建立传输链路。
可选的，在上述将所述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流的步骤之后，还包括：
接收上述第二客户端发出的调度请求信息；
基于上述调度请求信息生成的拉流协议确定与其对应的服务器，其中，上述标服务器为与上述第二客户端距离最近的服务器；
接收上述第二客户端发出的subscribe_stream信令，其中，上述subscribe_stream信令包括第二客户端的媒体会话描述信息和交互式连接建立信息；
根据上述subscribe_stream信令与上述第二客户端建立第一音视频通道链路；
通过上述音视频通道链路将上述第一客户端发送的RTC直播流发送至上述第二客户端。
可选的，在上述接收上述第二客户端发出的调度请求信息的步骤之后还包括：
基于上述调度请求信息生成的拉流协议确定上述第二客户端是否可以启用RTC拉流；
在上述第二客户端不可以启用RTC拉流的情况下，通过CDN系统向上述第二客户端推送RTMP直播流。
可选的，在上述通过上述音视频通道连接将上述第一客户端发送的RTC直播流发送至上述第二客户端之后，还包括：
在接收到上述第二客户端发出的基于分辨率切换生成的调度请求信息的情况下，基于上述调度请求信息建立第二音视频通道链路；
基于上述调度请求信息进行转码操作以获取低分辨率RTC直播流；
将上述低分辨率RTC直播流通过上述第二音视频通道链路发送至上述第二客户端。
第二方面，本发明还提出一种基于WebRtc的直播装置，包括：
接收单元，用于接收第一客户端发送的RTC直播流；
发送单元，用于将上述RTC直播流以UDP协议方式发送到RTC流媒体系统；
推送单元，用于将上述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。
第三方面，一种电子设备，包括：储存器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，上述处理器用于执行存储器中存储的计算机程序时实现如上述的第一方面任一项的基于WebRtc的直播方法的步骤。
第四方面，本发明还提出一种计算机可读存储介质，其上存储有计算机程序，上述计算机程序被处理器执行时实现第一方面上述任一项的基于WebRtc的直播方法。
综上，本申请实施例提出的一种基于WebRtc的直播方法包括：接收第一客户端发送的RTC直播流；将上述RTC直播流以UDP协议方式发送到RTC流媒体系统；将上述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。通过本申请实施例提供的方法，主播端采用RTC方式推送直播流至服务器可以大大降低延时，服务器在接收到RTC直播流的情况下，不仅对RTC直播流通过UDP协议方式发送到RTC流媒体系统，还会对RTC直播流进行协议转换通过RTMP协议方式推送到CDN流媒体系统，用户端可以根据拉流请求选择相应的流媒体系统进行拉流，从而观看直播。本直播方法不仅降低了直播延时，还为观众提供了多种拉流方式，丰富了直播的拉流方式，并可以在一定程度上降低RTC拉流时服务器的负荷。
本发明的基于WebRtc的直播方法，本发明的其它优点、目标和特征将部分通过下面的说明体现，部分还将通过对本发明的研究和实践而为本领域的技术人员所理解。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本说明书的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1为本申请实施例提供的一种RTC互动系统直播方式示意图；
图2为本申请实施例提供的一种主播端推流方式示意图；
图3为本申请实施例提供的另一种主播端推流方式示意图；
图4为本申请实施例提供的一种媒体会话信息交互流程流程示意图；
图5为本申请实施例提供的一种基于WebRtc直播方法流程示意图；
图6为本申请实施例提供的一种StreamServer服务器的工作流程示意图；
图7为本申请实施例提供的一种RTC流转RTMP流方法示意图；
图8为本申请实施例提供的一种RTMP流转RTC流方法示意图；
图9为本申请实施例提供的一种拉流侧用户端和RTC互动系统的信令交互流程示意图；
图10为本申请实施例提供的一种拉流侧用户端拉流方法示意图；
图11为本申请实施例提供的一种拉流侧用户端切换分辨率的拉流方法示意图；
图12为本申请实施例提供的一种基于WebRtc的直播装置；
图13为本申请实施例提供的一种基于WebRtc的直播电子设备结构示意图。
具体实施方式
通过本申请实施例提供的方法，主播端采用RTC方式推送直播流至服务器可以大大降低延时，服务器在接收到RTC直播流的情况下，不仅对RTC直播流通过UDP协议方式发送到RTC流媒体系统，还会对RTC直播流进行协议转换通过RTMP协议方式推送到CDN流媒体系统，用户端可以根据拉流请求选择相应的流媒体系统进行拉流，从而观看直播。本直播方法不仅降低了直播延时，还为观众提供了多种拉流方式，丰富了直播的拉流方式，并可以在一定程度上降低RTC拉流时服务器的负荷。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。
由于直播过程中需要执行很多服务，而这些服务可以由一个服务器划分为不同的服务区去执行，也可以有多个服务器组成一个系统去执行，本申请为了便于解释本方案，提出了一种有多个服务器组成的RTC互动系统，当并不限制本方法用于一个服务器去完成直播。如图1所示，为一种基于WebRtc的Licode的超低延时直播系统，该系统主要分为主播侧、RTC互动体系和拉流侧，RTC互动体系为服务器端，主播侧和拉流侧为客户端，其中RTC互动体系中又包含流接收和分发系统、转码系统、CDN系统，同时本系统还兼容连麦RTC系统，以实现在直播模式与连麦模式无缝切换。
在RTC互动系统中：
SignalAgent服务是信令服务系统，信令协议使用protobuf3，负责客户端与服务端，服务端与服务端之间消息的转发；
RtcRoom服务是进行直播房间号维度的管理；
StreamServer服务是基于Licode的RTC流接收与分发系统；
WebLiveServer服务是RTC推流接收端与级联，功能类似于StreamServer，不同的是，接收到RTC推流后，会转推到CDN系统；
MixerServer服务是音视频混流服务，当处于连麦模式，负责处理音视频的混流任务，然后将混流推给CDN系统；
CDN系统是供拉流侧进行RTMP、HLS、HTTP和FLV等协议拉流。
用户侧采用斗鱼自定义RTC拉流协议进行拉流，当RTC拉流多次失败后切换到CDN拉流。
在一些实施方式中，某些直播场景下需要极低的延时，诸如在线教育、医疗，直播带货等领域，为了控制是否开启本实施例提供的RTC推流方法，同时兼容CDN推流，如图2所示，根据主播的直播领域设置RTC推流开关，采用白名单控制，判断主播是否在RTC推流白名单内，如果该主播在白名单内则开启RTC推流，当RTC推流失败后就回退RTMP推流，推到CDN系统，简称CDN推流，如图1所示的主播侧的CDN推流。此CDN推流方式与当前的常规CDN推流方式相同，在此不做赘述。
在一些实施方式中，为了降低直播延迟，要在众多的服务器中选取合适的执行直播任务的服务器，服务器是根据上述第一客户端发送的推流服务地址确定的。
具体的，以图1所示的RTC互动系统为例，当主播侧开启RTC推流后，首先需要获取推流服务地址，通过推流服务地址确定RTC流推到哪个服务器，通过就近调度原则获取距离主播最近的信令转发服务器SignalAgent和流接收和分发服务器StreamServe。
需要特别说明的，通过选取最近的服务器进行推流可以降低主播侧与服务器间的通讯延时。
在一些实施方式中，主播侧与服务器进行推流之前还需要进行信令交互，具体包括步骤S100至步骤S102：
S100、接收上述第一客户端发送的信令交互信息，其中，上述信令交互信息包括joinchannel信令和publish_stream信令；
S101、与上述第一客户端进行publish_stream信令交互，以使上述服务器和上述第一客户端建立传输链路；
S102、根据上述joinchannel信令管理上述第一客户端对应的直播房间。
具体来说，可参阅图3第一客户端即为主播端，在接收到第一客户端发送的推流服务地址后，调用了与其距离最近的转发服务器SignalAgent和流接收和分发服务StreamServe器，然后主播端向服务器发送信令交互信息，包括joinchannel信令和publish_stream信令，StreamServer服务器与主播端进行publish_stream信令交互，以使主播端和服务器端获取彼此的音视频编解码能力、网络带宽、传输协议和IP地址等信息，双端获取彼此的信息后才可以建立传输链路，用来传输主播端发出的RTC推流。在接收到主播端的joinchannel信令后，由信令转发服务期SignalAgent转发到RtcRoom服务器，通知RtcRoom服务器将该主播加入主播房间号管理系统。
需要特别说明的是，服务器端和主播端可以通过信令交互获取双方的信息，以建立传输链路用于RTC推流。
在一些实施方式中，为了降低建立传输链路的时间，步骤S101具体还可以包括步骤S1001和步骤S1002：
S1001、基于上述publish_stream信令交互，确定与上述第一客户端执行推流操作的媒体会话描述信息和交互式连接建立信息，其中，上述媒体会话描述信息中的音频编解码信息为Opus，视频编解码信息为H.264，上述交互式连接建立信息为最先通过联通性检测的预设数量个可用地址，上述信令交互采用的协议为protobuf3协议；
S1002、根据上述媒体会话描述信息和上述交互式连接建立信息与上述第一客户端建立传输链路。
具体的，如图4为基于WebRtc的主播侧客户端与基于Licode的StreamServer服务媒体会话信息交互流程。在进行媒体会话信息交互时，可以通过省略某些不重要信息的方式减少交互的信息，以降低主播端与服务器进行信令交互的时间，达到降低直播延迟的目的，如图4为WebRtc的主播端与基于Licode的StreamServer服务媒体会话信息交互流程，具体的降低交互时间的方式可以通过下述方式实现：
A：将交互媒体会话描述信息中的编解码信息确定为H.264。由于Web端、IOS、Android、PC、MAC不同端的差异性导致它们对音视频的支持能力不同，在进行一些音视频会话之前，需要交互下彼此的音视频编解码能力、网络带宽和传输协议等信息，这些需要协商的信息需要用媒体会话描述信息SDP来描述。由于主播侧设备进行SDP信息交互前，需要收集设备本身所支持的音视频编解码能力，本申请实施例中为了降低延时，去除收集一些冗余的编解码信息，IOS、Android、PC端编解码主要以H264为主。
B：将交互式连接建立信息定义为最先通过联通性检测的预设数量个可用地址。ICE(Interactive Connectivity Establishment，交互式连接建立)，它是一种端到端交互的技术，可以让两个终端相互知道对方的公网IP，可以不借助一个公网server完成端到端(Peer to peer，P2P)的通信，即获取对方有效的的公网IP并且能够端到端通信。由于现有的ICE收集会等待收集到多路端到端的有效连接才会停止收集，本申请实施例中对ICE收集也进行简化，按优先顺序对收集候选地址进行联通性检测，检测到预设数量个可用地址就停止检测，待ICE信息收集完毕与SDP信息一并发送到服务端，极大的降低交互延时。进一步地预设数量可以设置为2。
C:信令交互采用的协议为protobuf3协议。由于客户端与服务端的信令交互采用protobuf3，protobuf3的连接采用的是TCP，保证了信令的可靠性，同时对发送的信令消息进行加密。而基于WebRtc的音视频数据传输是基于UDP传输，而音视频数据不包含主播侧与服务端交互的一些重要信息，数据可被外界解析，因此为了降低音视频数据处理的延时，去除了音视频DTLS的加密，同时也降低主播侧与服务端的算力，此优化同时运用在客户端RTC拉流侧。
需要特别说明的是，本实施例通过减少信令交互的内容可以缩短信令交互的时间以达到缩短直播延迟的目的。
在一些实施方式中，为了在执行RTC推流的同时，用户侧也可以进行CDN拉流，提出一种基于WebRtc的直播方法，如图5所示，具体包括步骤S110至步骤S130：
S110、接收第一客户端发送的RTC直播流；
示例性的，以图1所示的RTC互动系统为例，主播端在与客户端建立传输链路后，主播端将RTC流发送至StreamServer服务器。
S120、将上述RTC直播流以UDP协议方式发送到RTC流媒体系统；
示例性的，StreamServer服务器在接收到RTC直播流后与其他的StreamServer服务器进行级联和分发，将RTC直播流以UDP协议方式发送到RTC流媒体系统。
RTC互动系统中的StreamServer服务器主要负责RTC音视频流的接收和分发。其中RTC流的级联调度采用Source和Sink的方式管理，如图6所示，Source和Sink是StreamServer服务器的别称，其中Source表示能从该服务读取到RTC流数据，包括推流侧用户推送过来的RTC流以及级联从其他StreamServer拉到的流，Sink表示需要往该服务写入RTC流数据，包括用户侧拉取的RTC流以及StreamServer主动推送给其他服务的流。一个Source下面可以挂载多个Sink，对于非用户侧的Source，会标记为Link，表示级联流，即非用户侧直接推的RTC流。StreamServer之间的级联也是基于UDP转发，去除了DTLS的加密过程，只做音视频数据的转发，不涉及编解码部分，从而可以提升RTC直播流分发的速度。
S130、将上述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。
示例性的，同时，StreamServer服务器在接收到RTC直播流后将RTC流以RTMP协议方式通过WebLiveServer服务器转推到CDN系统。具体的，可以通过RTC互动系统中的StreamServer服务器的RtpToRtmp模块，实现RTC直播流转成RTMP流，如图7所示，RtpToRtmp模块实现RtcSink接口，将RTC流转为RTMP流，同时将RTMP流注册到RtmpSource对象，实现Rtp到Rtmp的协议转换，由于Rtp数据包可能不是顺序到达StreamServer服务，并且可能存在丢包，因此RtmpToRtp模块中集成NetEQ和JitterBuffer，NetEQ和JitterBuffer分别为音频抖动缓冲和视频抖动缓冲，负责音视频数据包的乱序排序，同时进行音视频的同步操作。另外，在RTMP协议与RTP协议转换时，由于两种协议支持的音频格式不同，因此音频数据需要做AAC格式和OPUS格式的互相转换。
此外，StreamServer服务器中的RtmpToRtp模块包含音视频流Rtmp协议向Rtp协议的互转功能，如图8所示，RtmpToRtp模块实现RtmpSink接口，将RTMP流转为RTC流，同时将RTC流注册到RtcSource对象，以便拉流侧用户可以拉取到RTC流。
需要特别说明的是，本申请实施例提供的方法，主播端采用RTC方式推送直播流至服务器可以大大降低延时，服务器在接收到RTC直播流的情况下，不仅对RTC直播流通过UDP协议方式发送到RTC流媒体系统，还会对RTC直播流进行协议转换通过RTMP协议方式推送到CDN流媒体系统，用户端可以根据拉流请求选择相应的流媒体系统进行拉流，从而观看直播。本直播方法不仅降低了直播延时，还为观众提供了多种拉流方式，丰富了直播的拉流方式，并可以在一定程度上降低RTC拉流时服务器的负荷。
在一些实施方式中，在主播侧通过步骤S110至步骤S130进行推流后，用户端可通过步骤S210至步骤S250进行拉流：
S210、接收上述第二客户端发出的调度请求信息；
S220、基于上述调度请求信息生成的拉流协议确定与其对应的服务器，其中，上述标服务器为与上述第二客户端距离最近的服务器；
S230、接收上述第二客户端发出的subscribe_stream信令，其中，上述subscribe_stream信令包括第二客户端的媒体会话描述信息和交互式连接建立信息；
S240、根据上述subscribe_stream信令与上述第二客户端建立第一音视频通道链路；
S250、通过上述音视频通道链路将上述第一客户端发送的RTC直播流发送至上述第二客户端。
具体的，第二客户端即为用户端，在发出调度请求信息后，拉流侧用户端和RTC互动系统之间的信令交互流程，如图9所示，RTC交互系统中的调度服务器基于调度请求信息生成拉流协议，并通过拉流协议可以解析出距离用户端最近的SignalAgent服务器和StreamServer服务器，建立连接。然后，拉流侧用户端向SignalAgent服务器发送订阅流subscribe_stream信令，该信令中包含SDP、ICE等信息，通过SignalAgent服务器转发到StreamServer服务器，拉流侧用户端StreamServer服务与建立音视频通道链路，建立连接过程与RTC推流过程雷同，在此不做赘述，最后StreamServer服务下发RTC音视频数据到拉流用户端。
需要说明的是，拉流协议URL的格式如下：
yrtc://10.1.40.11:4322/432002/467003/192062？room_id＝305447&user_id＝900101000&env＝live&stream_server_bak＝467001_467002&signal_agent_bak＝10.1.40.11-4323-432003_10.1.40.11-4321-432001&token＝679522a9fae7e899900fb3fef754a511&expire＝1624846945044
基本结构为：
dyrtc://<signal_agent_ip>:<signal_agent_port>/<signal_agent_id>/<stream_server_id>/<stream_id>与param1＝value1&param2＝value2。
其中：
dyrtc://表示斗鱼私有协议；
signal_agent_ip、signal_agent_port、signal_agent_id表示拉流用户端需要建立连接的信令服务IP、端口和SignalAgent服务器ID；
stream_server_id表示拉流用户端需要建立连接的StreamServer服务器ID；
stream_id表示拉流用户端观看的流信息标识。
env＝live表示用户端连接环境，分为测试、预发布、线上环境；
stream_server_bak表示备用的StreamServer服务器ID数组，元素之间以下划线分割；signal_agent_back表示备用的信令服务器IP、端口数组，元素之间以下划线分隔，ip、port、server_id之间以-分隔；
token表示用户的鉴权信息，token加密规则为：md5(uid+expire+passwd)；
expire表示token的过期时间；
在一些实施方式中，由于拉流侧的用户端较多，为了防止RTC互动系统突然遭受大规模的并发拉流导致系统的不稳定性，因此对拉流侧是否开启RTC拉流进行限制。是否开启RTC拉流调度采用如图10所示的方法去判断，即在步骤S220之后，通过步骤S1301判断是否可以启动RTC拉流:
S1301、基于上述调度请求信息生成的拉流协议确定上述第二客户端是否可以启用RTC拉流；
示例性的，拉流侧用户端请求拉流调度服务，拉流调度服务器会根据用户设备端、拉流房间号、用户ID等信息配置白名单用户，然后拉流侧用户端会根据调度的返回结果中是否配置有RTC拉流协议，选择是否启用RTC拉流。如果开启RTC拉流，就会根据返回的RTC拉流协议与服务端进行连接，根据步骤S230至步骤S250上述的方法进行RTC拉流。
如果无法开启RTC拉流则在通过步骤S1302实现RTMP拉流:
S1302、在上述第二客户端不可以启用RTC拉流的情况下，通过CDN系统向上述第二客户端推送RTMP直播流。
示例性的，由于RTC互动系统即推送了RTC直播流，同时也推送了RTMP直播流，在上述第二客户端不可以启用RTC拉流的情况下，通过CDN系统向上述第二客户端推送RTMP直播流，以满足用户端观看直播的需求。
在一些实施方式中，在用户端观看直播时当主播侧RTC推流码率较高，而拉流侧的个别用户网络较差时，这些用户观看直播的体验感就会变差，为了解决这问题，在步骤S250之后还包括步骤S260和步骤S270：
S260、在接收到上述第二客户端发出的基于分辨率切换生成的调度请求信息的情况下，基于上述调度请求信息建立第二音视频通道链路；
S270、基于上述调度请求信息进行转码操作以获取低分辨率RTC直播流；将上述低分辨率RTC直播流通过上述第二音视频通道链路发送至上述第二客户端。
示例性的，如图11所示，在拉流侧用户端网络较差时，需要从高分辨率挡位切换到低分辨率挡位时，首先会请求拉流调度服务，然后根据拉流调度服务返回的RTC流URL中包含的挡位和码率信息，与StreamServer服务其重新建立连接以建立第二音视频通道链路，StreamServer服务其就会下发低分辨率、低码率的音视频流数据，以保证用户的直播观看体验感。如图11所示，主播侧开播向StreamServer服务器推送的RTC直播流为原画质流，该流为高分辨率、高码率流，当拉流侧用户从StreamServer服务器拉取低分辨率、低码率的流时，会触发转码请求事件，事件会通知到控制转发服务器CommandServer服务，再由CommandServer服务器通知转码系统进行转码操作。每个转码系统中会分配一个对应的StreamServer服务器，该StreamServer服务器支持RTMP和RTP协议的互转。拉流侧用户拉取转码流时，最终会级联订阅到该StreamServer上，如果转码流还没处理完，StreamServer需要等待转码任务处理完毕，才能下发流数据。
请参阅图12，本申请实施例中的基于WebRtc的直播装置的一个实施例，可以包括：
接收单元41，用于接收第一客户端发送的RTC直播流；
发送单元42，用于将上述RTC直播流以UDP协议方式发送到RTC流媒体系统；
推送单元43，用于将上述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。
如图13所示，本申请实施例还提供一种电子设备200，包括存储器310、处理器320及存储在存储器320上并可在处理器上运行的计算机程序511，处理器320执行计算机程序311时实现上述基于WebRtc的直播的任一方法的步骤。
由于本实施例所介绍的电子设备为实施本申请实施例中一种基于WebRtc的直播装置所采用的设备，故而基于本申请实施例中所介绍的方法，本领域所属技术人员能够了解本实施例的电子设备的具体实施方式以及其各种变化形式，所以在此对于该电子设备如何实现本申请实施例中的方法不再详细介绍，只要本领域所属技术人员实施本申请实施例中的方法所采用的设备，都属于本申请所欲保护的范围。
在具体实施过程中，该计算机程序311被处理器执行时可以实现图1对应的实施例中任一实施方式。
需要说明的是，在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其它实施例的相关描述。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式计算机或者其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
本申请实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机软件指令，当计算机软件指令在处理设备上运行时，使得处理设备执行如图1对应实施例中的基于WebRtc的直播方法的流程。
计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种基于WebRtc的直播方法，用于服务器，其特征在于，包括：
接收第一客户端发送的RTC直播流；
将所述RTC直播流以UDP协议方式发送到RTC流媒体系统；
将所述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。
2.如权利要求1所述的方法，其特征在于，所述服务器是根据所述第一客户端发送的推流服务地址确定的。
3.如权利要求2所述的方法，其特征在于，在所述接收第一客户端发送的RTC直播流的步骤之前，还包括：
接收所述第一客户端发送的信令交互信息，其中，所述信令交互信息包括joinchannel信令和publish_stream信令；
与所述第一客户端进行publish_stream信令交互，以使所述服务器和所述第一客户端建立传输链路；
根据所述joinchannel信令管理所述第一客户端对应的直播房间。
4.如权利要求3所述的方法，其特征在于，所述与所述第一客户端进行publish_stream信令交互，以使和所述第一客户端建立传输链路，包括：
基于所述publish_stream信令交互，确定与所述第一客户端执行推流操作的媒体会话描述信息和交互式连接建立信息；
根据所述媒体会话描述信息和所述交互式连接建立信息与所述第一客户端建立传输链路。
5.如权利要求1所述的方法，其特征在于，在将所述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流之后，还包括：
接收所述第二客户端发出的调度请求信息；
基于所述调度请求信息生成的拉流协议确定与其对应的服务器，其中，所述标服务器为与所述第二客户端距离最近的服务器；
接收所述第二客户端发出的subscribe_stream信令，其中，所述subscribe_stream信令包括第二客户端的媒体会话描述信息和交互式连接建立信息；
根据所述subscribe_stream信令与所述第二客户端建立第一音视频通道链路；
通过所述音视频通道链路将所述第一客户端发送的RTC直播流发送至所述第二客户端。
6.如权利要求5所述的方法，其特征在于，在所述接收所述第二客户端发出的调度请求信息的步骤之后还包括：
基于所述调度请求信息生成的拉流协议确定所述第二客户端是否可以启用RTC拉流；
在所述第二客户端不可以启用RTC拉流的情况下，通过CDN系统向所述第二客户端推送RTMP直播流。
7.如权利要求5所述的方法，其特征在于，在所述通过所述音视频通道连接将所述第一客户端发送的RTC直播流发送至所述第二客户端之后，还包括：
在接收到所述第二客户端发出的基于分辨率切换生成的调度请求信息的情况下，基于所述调度请求信息建立第二音视频通道链路；
基于所述调度请求信息进行转码操作以获取低分辨率RTC直播流；
将所述低分辨率RTC直播流通过所述第二音视频通道链路发送至所述第二客户端。
8.一种基于WebRtc的直播装置，其特征在于，包括：
接收单元，用于接收第一客户端发送的RTC直播流；
发送单元，用于将所述RTC直播流以UDP协议方式发送到RTC流媒体系统；
推送单元，用于将所述RTC直播流以RTMP协议方式推送到CDN流媒体系统，以使第二客户端根据拉流请求选择相应的流媒体系统进行拉流。
9.一种电子设备，包括：储存器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-7中任一项所述的基于WebRtc的直播方法的步骤。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的基于WebRtc的直播方法。
CN202210491810.6A 2022-05-07 2022-05-07 一种基于WebRtc的直播方法及相关设备 Pending CN115065832A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210491810.6A CN115065832A (zh) 2022-05-07 2022-05-07 一种基于WebRtc的直播方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210491810.6A CN115065832A (zh) 2022-05-07 2022-05-07 一种基于WebRtc的直播方法及相关设备

Publications (1)

Publication Number Publication Date
CN115065832A true CN115065832A (zh) 2022-09-16

Family

ID=83196771

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210491810.6A Pending CN115065832A (zh) 2022-05-07 2022-05-07 一种基于WebRtc的直播方法及相关设备

Country Status (1)

Country Link
CN (1) CN115065832A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117499688A (zh) * 2023-12-29 2024-02-02 淘宝（中国）软件有限公司 直播连麦中音视频合流处理方法、设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108076349A (zh) * 2016-11-11 2018-05-25 铂渊信息技术（上海）有限公司 网络互动直播方法、系统及电子设备
CN112543297A (zh) * 2019-09-20 2021-03-23 北京新媒传信科技有限公司 一种视频会议直播方法、装置和系统
CN113259706A (zh) * 2021-06-28 2021-08-13 北京新唐思创教育科技有限公司 直播处理方法、装置、电子设备以及存储介质
CN113301353A (zh) * 2020-04-01 2021-08-24 阿里巴巴集团控股有限公司 数据传输方法、装置、电子设备及计算机可读存储介质
CN113766251A (zh) * 2020-06-22 2021-12-07 北京沃东天骏信息技术有限公司 直播连麦的处理方法、系统、服务器及存储介质
CN114025191A (zh) * 2021-11-04 2022-02-08 北京睿芯高通量科技有限公司 一种基于Nginx-rtmp的webrtc低延迟直播方法及系统
CN114125482A (zh) * 2021-11-23 2022-03-01 腾讯音乐娱乐科技（深圳）有限公司 直播连麦处理方法、电子设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108076349A (zh) * 2016-11-11 2018-05-25 铂渊信息技术（上海）有限公司 网络互动直播方法、系统及电子设备
CN112543297A (zh) * 2019-09-20 2021-03-23 北京新媒传信科技有限公司 一种视频会议直播方法、装置和系统
CN113301353A (zh) * 2020-04-01 2021-08-24 阿里巴巴集团控股有限公司 数据传输方法、装置、电子设备及计算机可读存储介质
CN113766251A (zh) * 2020-06-22 2021-12-07 北京沃东天骏信息技术有限公司 直播连麦的处理方法、系统、服务器及存储介质
CN113259706A (zh) * 2021-06-28 2021-08-13 北京新唐思创教育科技有限公司 直播处理方法、装置、电子设备以及存储介质
CN114025191A (zh) * 2021-11-04 2022-02-08 北京睿芯高通量科技有限公司 一种基于Nginx-rtmp的webrtc低延迟直播方法及系统
CN114125482A (zh) * 2021-11-23 2022-03-01 腾讯音乐娱乐科技（深圳）有限公司 直播连麦处理方法、电子设备及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117499688A (zh) * 2023-12-29 2024-02-02 淘宝（中国）软件有限公司 直播连麦中音视频合流处理方法、设备及存储介质
CN117499688B (zh) * 2023-12-29 2024-05-03 淘宝（中国）软件有限公司 直播连麦中音视频合流处理方法、设备及存储介质

Similar Documents

Publication Publication Date Title
US9674252B2 (en) System and method for efficient delivery of repetitive multimedia content
CN101365096B (zh) 提供视频内容的方法及相关业务设备和系统
RU2647654C2 (ru) Система и способ доставки аудиовизуального контента в клиентское устройство
US20080160911A1 (en) P2P-based broadcast system and method using the same
US20080209065A1 (en) Method for sending stream media, signaling forwarding device and stream media system
EP1598741A1 (en) Information processing apparatus and content information processing method
JP2015080210A (ja) 会議セッションの現在状況に対する、会議システムのリアルタイム適合システム及び方法
WO2016049987A1 (zh) 一种数据处理方法、装置及相关服务器
US9178924B1 (en) IPv6 to web architecture
KR20210047933A (ko) 비디오 스크린 프로젝션 방법과 장치, 컴퓨터 장비, 및 저장 매체
RU2454806C2 (ru) Способ, устройство и система для уведомления о событиях протокола потоковой передачи в реальном времени
CN112019927A (zh) 视频直播方法、连麦设备、rtc媒体服务器及主播设备
KR100937681B1 (ko) 사용자간 통신을 위한 통신 모듈 및 방법, 그러한 통신 모듈을 포함하는 서버, 그러한 서버를 포함하는 방송 세트, 그러한 사용자간 통신 방법을 수행하는 컴퓨터 프로그램 제품을 저장한 저장 매체
CN102195955A (zh) 一种直播业务和时移业务的切换方法以及相应设备
CN107547517B (zh) 音视频节目录制方法和网络设备及计算机装置
CN114040232A (zh) 投屏系统、方法、电子设备和存储介质
CN115065832A (zh) 一种基于WebRtc的直播方法及相关设备
JP2007527576A (ja) コンテンツを配信するためのシステム、レシーバ、方法及びプログラム
CN108668140B (zh) 音视频交互状态同步方法及装置
CN112995697B (zh) 一种流数据恢复方法、服务器、存储介质及计算机设备
CN112073727B (zh) 转码方法、装置、电子设备及存储介质
CN113055636B (zh) 一种数据处理方法及会议系统
CN114629897A (zh) 数据处理方法以及系统
CN114143616A (zh) 目标视频的处理方法和系统、存储介质及电子装置
CN113115065A (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