CN116781678A - 流媒体数据的传输方法及装置 - Google Patents

Abstract

本申请公开了一种流媒体数据的传输方法及装置。方法的一具体实施方式包括：基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。本申请基于直播服务和视频会议服务之间的连接，实现直播转RTC，以及RTC转直播的效果。

Description

流媒体数据的传输方法及装置

技术领域

本申请实施例涉及计算机技术领域，具体涉及实时交互技术领域，尤其涉及一种流媒体数据的传输方法、装置、计算机可读介质及电子设备。

背景技术

直播服务是基于实时传输协议，对实时流媒体数据进行分发的服务。视频会议服务是基于互联网的通信方式，通过网络技术使人们能够在不同地点进行面对面的交流、协作或互动的服务。现实中，存在基于单一的直播服务或视频会议服务，无法满足用户对流媒体数据的各种操作需求的情形。

发明内容

本申请实施例提出了一种流媒体数据的传输方法、装置、计算机可读介质及电子设备。

第一方面，本申请实施例提供了一种流媒体数据的传输方法，包括：基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。

在一些示例中，在上述基于第一服务的推流端的推流请求，获取待推流的流媒体数据之前，还包括：确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块；基于第一中继传输模块和第二中继传输模块，建立第一服务和第二服务之间的连接。

在一些示例中，上述确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块，包括：根据接收到的自定义操作，确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

在一些示例中，上述第一服务为直播服务，第二服务为视频会议服务，以及上述基于第一服务的推流端的推流请求，获取待推流的流媒体数据，包括：基于第一服务的推流端的推流请求，获取采用预设初始传输协议、预设初始音视频编码格式的直播流媒体数据；将直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

在一些示例中，上述将直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据，包括：响应于确定预设初始传输协议为第一传输协议、预设初始音视频编码格式为第一音视频编码格式，对所获取的直播流媒体数据进行传输协议转换，得到采用第二传输协议、第一音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一数据源；将第一数据源中的直播流媒体数据进行格式转换和编码格式转换，得到采用第三传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第二数据源；将第二数据源中的直播流媒体数据进行格式转换，得到采用自定义的第四传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一中继传输模块，其中，第四传输协议为预设目标传输协议，第二音视频编码格式为预设目标音视频编码格式。

在一些示例中，上述第一服务为直播服务，第二服务为视频会议服务，以及上述基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端，包括：基于拉流请求和连接，通过第二服务中的第二中继传输模块，确定第一服务中的第一中继传输模块中的直播流媒体数据；将所获取的直播流媒体数据进行传输协议转换，得到采用第五传输协议的直播流媒体数据；将转换后的直播流媒体数据分发至第二服务的拉流端。

在一些示例中，上述第一服务为视频会议服务，第二服务为直播服务，以及上述基于第一服务的推流端的推流请求，获取待推流的流媒体数据，包括：基于第一服务的推流端的推流请求，生成第一服务的推流端对应的流媒体数据生产者对象；基于流媒体数据生产者对象，获取第一服务的推流端的视频会议流媒体数据。

在一些示例中，上述第一服务为视频会议服务，第二服务为直播服务，以及上述基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端，包括：根据接收到的第二服务的拉流端的拉流请求，在第一数据源、第二数据源和第一中继传输模块中依次进行回源，并基于连接，将第一中继传输模块中的拉流请求回源至第二中继传输模块；基于连接，通过第二中继模块将视频会议流媒体数据依次在第一中继传输模块、第二数据源、第一数据源中进行回调，并将回调后的视频会议流媒体数据分发至第二服务的拉流端。

第二方面，本申请实施例提供了一种流媒体数据的传输装置，包括：获取单元，被配置成基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定单元，被配置成确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；传输单元，被配置成响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。

在一些示例中，上述装置还包括：建连单元，被配置成：确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块；基于第一中继传输模块和第二中继传输模块，建立第一服务和第二服务之间的连接。

在一些示例中，上述建连单元，进一步被配置成：根据接收到的自定义操作，确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

在一些示例中，上述第一服务为直播服务，第二服务为视频会议服务，以及上述获取单元，进一步被配置成：基于第一服务的推流端的推流请求，获取采用预设初始传输协议、预设初始音视频编码格式的直播流媒体数据；将直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

在一些示例中，上述获取单元，进一步被配置成：响应于确定预设初始传输协议为第一传输协议、预设初始音视频编码格式为第一音视频编码格式，对所获取的直播流媒体数据进行传输协议转换，得到采用第二传输协议、第一音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一数据源；将第一数据源中的直播流媒体数据进行格式转换和编码格式转换，得到采用第三传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第二数据源；将第二数据源中的直播流媒体数据进行格式转换，得到采用自定义的第四传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一中继传输模块，其中，第四传输协议为预设目标传输协议，第二音视频编码格式为预设目标音视频编码格式。

在一些示例中，上述第一服务为直播服务，第二服务为视频会议服务，以及上述传输单元，进一步被配置成：基于拉流请求和连接，通过第二服务中的第二中继传输模块，确定第一服务中的第一中继传输模块中的直播流媒体数据；将所获取的直播流媒体数据进行传输协议转换，得到采用第五传输协议的直播流媒体数据；将转换后的直播流媒体数据分发至第二服务的拉流端。

在一些示例中，上述第一服务为视频会议服务，第二服务为直播服务，以及上述获取单元，进一步被配置成：基于第一服务的推流端的推流请求，生成第一服务的推流端对应的流媒体数据生产者对象；基于流媒体数据生产者对象，获取第一服务的推流端的视频会议流媒体数据。

在一些示例中，上述第一服务为视频会议服务，第二服务为直播服务，以及上述传输单元，进一步被配置成：根据接收到的第二服务的拉流端的拉流请求，在第一数据源、第二数据源和第一中继传输模块中依次进行回源，并基于连接，将第一中继传输模块中的拉流请求回源至第二中继传输模块；基于连接，通过第二中继模块将视频会议流媒体数据依次在第一中继传输模块、第二数据源、第一数据源中进行回调，并将回调后的视频会议流媒体数据分发至第二服务的拉流端。

第三方面，本申请实施例提供了一种计算机可读介质，其上存储有计算机程序，其中，程序被处理器执行时实现如第一方面任一实现方式描述的方法。

第四方面，本申请实施例提供了一种电子设备，包括：一个或多个处理器；存储装置，其上存储有一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面任一实现方式描述的方法。

本申请实施例提供的流媒体数据的传输方法及装置，通过基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端，从而基于直播服务和视频会议服务之间的连接，实现直播转RTC(Real-Time Communication，实时交互)，以及RTC转直播的效果；一方面，通过视频会议服务级联直播服务，可以降低中转线路节点引入的延时，同时也能实现直播入会的效果；另一方面，通过直播服务级联视频会议服务，可以满足旁路直播、云端录制等需求，能够进一步优化节省分发带宽，而且，视频会议服务集群可支持大型级联部署，极大提升并发能力。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请的一个实施例可以应用于其中的示例性系统架构图；

图2是根据本申请的流媒体数据的传输方法的一个实施例的流程图；

图3是根据本实施例的流媒体数据的传输方法的应用场景的示意图；

图4是根据本申请的流媒体数据的传输方法的一个实施例的框架流程图；

图5是根据本申请的流媒体数据的传输方法的又一个实施例的流程图；

图6是根据本申请的流媒体数据的传输方法的又一个实施例的流程图；

图7是根据本申请的流媒体数据的传输装置的一个实施例的结构图；

图8是适于用来实现本申请实施例的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

需要说明的是，本公开的技术方案中，所涉及的用户个人信息的采集、收集、更新、分析、处理、使用、传输、存储等方面，均符合相关法律法规的规定，被用于合法的用途，且不违背公序良俗。对用户个人信息采取必要措施，防止对用户个人信息数据的非法访问，维护用户个人信息安全、网络安全和国家安全。

图1示出了可以应用本申请的流媒体数据的传输方法及装置的示例性架构100。

如图1所示，系统架构100可以包括终端设备101、102、103、108、109、110，网络104、107和服务器105、106。终端设备101、102、103之间通信连接构成拓扑网络，网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。终端设备108、109、110之间通信连接构成拓扑网络，网络107用以在终端设备108、109、110和服务器106之间提供通信链路的介质。网络104、107可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与部署直播服务的服务器105交互，也可以使用终端设备108、109、110通过网络107与部署视频会议服务的服务器106交互，以接收或发送流媒体数据等。终端设备可以是支持网络连接从而进行数据交互和数据处理的硬件设备或软件。当终端设备为硬件时，其可以是支持网络连接，信息获取、交互、显示、处理等功能的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、膝上型便携计算机和台式计算机等等。当终端设备为软件时，可以安装在上述所列举的电子设备中。其可以实现成例如用来提供分布式服务的多个软件或软件模块，也可以实现成单个软件或软件模块。在此不做具体限定。

服务器105、106可以是提供直播服务、视频会议服务的服务器，例如，将直播服务和视频会议服务级联，对于处于直播服务或视频会议服务中的推流端、拉流端(具体表现为终端设备101、102、103、108、109、110)，进行流媒体数据传输的后台处理服务器。作为示例，服务器105、106可以是云端服务器。

需要说明的是，服务器可以是硬件，也可以是软件。当服务器为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当服务器为软件时，可以实现成多个软件或软件模块(例如用来提供分布式服务的软件或软件模块)，也可以实现成单个软件或软件模块。在此不做具体限定。

还需要说明的是，本申请的实施例所提供的流媒体数据的传输方法可以由服务器执行，也可以由终端设备执行，还可以由服务器和终端设备彼此配合执行。相应地，流媒体数据的传输装置包括的各个部分(例如各个单元)可以全部设置于服务器中，也可以全部设置于终端设备中，还可以分别设置于服务器和终端设备中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。当流媒体数据的传输方法运行于其上的电子设备不需要与其他电子设备进行数据传输时，该系统架构可以仅包括流媒体数据的传输方法运行于其上的电子设备(例如服务器或终端设备)。

继续参考图2，示出了流媒体数据的传输方法的一个实施例的流程200，包括以下步骤：

步骤201，基于第一服务的推流端的推流请求，获取待推流的流媒体数据。

本实施例中，流媒体数据的传输方法的执行主体(例如图1中的终端设备或服务器)可以通过有线网络连接方式或者无线网络连接方式从远程，或从本地获取第一服务的推流端的推流请求，并基于第一服务的推流端的推流请求，获取待推流的流媒体数据。

其中，第一服务为直播服务、视频会议服务中的一种服务。例如，当第一服务为直播服务时，上述执行主体在接收到直播服务中的推流端的推流请求后，会实时获取推流端所直播录制的音频、视频等直播流媒体数据。又例如，当第一服务为视频会议服务时，上述执行主体在接收到视频会议服务中的推流端的推流请求后，会实时获取推流端正在录制的音频、视频等视频会议流媒体数据。

步骤202，确定接收到的拉流请求是否来自第二服务的拉流端。

本实施例中，上述执行主体可以确定接收到的拉流请求是否来自第二服务的拉流端。其中，第二服务为直播服务、视频会议服务中的另一种服务。

作为示例，当第一服务为直播服务时，第二服务为视频会议服务；当第一服务为视频会议服务时，第二服务为直播服务。

本实施例中，上述执行主体可以对接收到的拉流端的拉流请求进行解析，进而根据解析得到的请求参数确定拉流请求来自于直播服务还是视频会议服务。

步骤203，响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。

本实施例中，响应于确定接收到的拉流请求来自第二服务的拉流端，上述执行主体可以基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。

本实施例中，预先建立第一服务和第二服务之间的连接关系。作为示例，上述执行主体可以利用API(Application Programming Interface，应用程序编程接口)接口进行第一服务和第二服务之间的交互。具体的，利用直播服务提供商和视频会议服务提供商所开放的相关的API接口，实现两种服务之间的数据交流和信息共享，从而实现在某些场景下的功能互通。

作为又一示例，上述执行主体可以利用第三方平台协调第一服务和第二服务之间的交互。具体的，一些第三方在线互动平台和消息中间件，可以集成直播服务和视频会议服务，并且提供一些嵌入式组件或者插件，来帮助两个服务之间进行联动或者跨平台互通。

基于直播服务和视频会议服务之间的连接，上述执行主体可以将其中一个服务中的推流端所推流的流媒体数据转发至另一个服务的拉流端，实现两个服务之间的信息交互。

需要说明的是，响应于确定接收到的拉流请求是来自第一服务的拉流端，也即，推流端和拉流端均属于直播服务，或均属于视频会议服务，则直播服务或视频会议服务按照自身的业务逻辑进行自身服务内部的视频收发。此时，直播服务、视频会议服务之间不再进行流媒体数据的交互。

以推流端和拉流端均属于直播服务为例，在推流端，首先，使用摄像头或其他音视频设备，获取目标声音和图像的流媒体数据；然后，将音视频流媒体数据进行编码压缩处理，以便于后续传输、存储和播放；然后，将音视频数据进行封装打包处理，生成符合常用网络协议的传输数据包；然后，通过网络连接方式，将封装打包好的音视频数据流上传到流媒体服务器中，并请求对应的Stream ID(流标识)；最后，将Stream ID和推流URL(UniformResource Locator,统一资源定位器)发往拉流端，开始推流的远程发布过程。

在拉流端，首先，采用拉流请求的方式，通过推流地址或媒体ID来获取对应音视频流的有效播放地址；然后，使用网络协议，向流媒体服务器发起连接，建立TCP(传输控制协议，Transmission Control Protocol)或UDP(User Datagram Protocol，用户数据报协议)等传输链接通道；然后，通过网络传输方式将服务端的音视频数据流进行下载，将获取到的音视频数据进行解封装、解密和解码处理，还原为可供播放的数据格式；最后，将还原后的音视频数据进行渲染和播放输出，呈现到拉流客户端的屏幕上。

以推流端和拉流端均属于视频会议服务为例，在推流端，首先，推流端通过媒体采集设备获取音视频数据。然后，推流端使用WebRTC技术建立与信令服务器的连接，并通过信令通道发送相关信息，如SDP(Session Description Protocol，会话描述协议)信息；然后，信令服务器将SDP转发给拉流端或者MCU(Multipoint Control Unit，多方控制单元)进行处理。然后，如果是点对点连接，则拉流端或推流端回应一个匹配的SDP，以建立双向媒体传输通道。如果是多方视频会议，则信令服务器会将SDP转发到MCU，由MCU进行协调并建立对应的媒体通道。最后，推流端将音视频数据通过WebRTC传输到接收方客户端或MCU。

在拉流端，首先拉流端向服务器请求加入指定的房间。然后，服务器返回有关媒体流的描述性元数据，包括可用质量、编解码器信息、以及其他参数。然后，拉流方使用WebRTC技术建立与服务器端的连接，并通过信令通道与服务器交换SDP(即拉流方的适当的Answer)。然后，服务器将SDP转发回拉流端。然后，拉流端调用WebRTC API开始从服务器端拉取媒体流数据。最后，拉流端解码获取到的音视频数据并对其进行播放。

继续参见图3，图3是根据本实施例的流媒体数据的传输方法的应用场景的一个示意图300。在图3的应用场景中，用户301、302通过部署视频会议服务的服务器303进行视频会议；用户304通过部署直播服务的服务器305正在进行直播。用户301、302在视频会议的探讨过程中，产生观看用户304的直播内容的需求，用户301向服务器303发出拉流请求，服务器303通过与服务器305的连接，获取用户304的直播流媒体数据，并将直播流媒体数据转发至用户301、302的视频会议界面。

本申请的上述实施例提供的方法，通过基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端，从而基于直播服务和视频会议服务之间的连接，实现直播转RTC(Real-Time Communication，实时交互)，以及RTC转直播的效果；一方面，通过视频会议服务级联直播服务，可以降低中转线路节点引入的延时，同时也能实现直播入会的效果；另一方面，通过直播服务级联视频会议服务，可以满足旁路直播、云端录制等需要，能够进一步优化节省分发带宽，而且，视频会议服务集群可支持大型级联部署，极大提升并发能力。

继续参考图4，示出了根据本申请的流媒体数据的传输方法的又一个实施例的框架流程图。

在本实施例的一些可选的实现方式中，在执行上述步骤201之前，上述执行主体还可以执行如下操作：

第一，确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

作为示例，上述执行主体可以在直播服务(第一服务)中添加第一中继传输模块RelayioSource，RelayioSource模块支持直播服务中流媒体数据的转换以及转发；在视频会议服务(第二服务)中添加第二中继传输模块RelayioTransport，RelayioTransport模块支持视频会议服务中流媒体数据的转换以及转发。

具体的，RelayioSource模块和RelayioTransport模块可以基于UDT(UDP-basedData Transfer Protocol，基于UDP(User Datagram Protocol，用户数据报协议)的数据传输协议)实现，包括速率控制、应答、负面应答、重传、连接维护等功能。

其中，在速率控制方面，根据拉流端的接收能力动态调整发送速率，以避免网络拥塞和数据丢失。在应答方面，拉流端收到流媒体数据后，通过中继传输模块会发送一个确认报文(ACK)给推流端，以表示已经成功收到流媒体数据。在负面应答方面，如果拉流端检测到数据包出现错误或者丢失，会通过中继传输模块发送一个负面确认报文(NAK)给推流端，以指示需要重新发送流媒体数据。在重传方面，如果推流端收到拉流端发来的NAK报文，或者没有及时收到ACK报文，就会进行数据包的重传。在连接维护方面，中继传输模块还需要维护推流端和拉流端之间的连接状态，确保数据包正确地发送和接收。

第二，基于第一中继传输模块和第二中继传输模块，建立第一服务和第二服务之间的连接。

本实现方式中，第一中继传输模块和第二中继传输模块之间建立连接关系，以基于UDT协议进行流媒体数据的交互，从而实现第一服务和第二服务之间的连接。

本实现方式中，提供了一种建立第一服务和第二服务之间的连接的具体实现方式，基于第一中继模块和第二中继模块，提高了第一服务和第二服务之间的信息交互能力。

在本实施例的一些可选的实现方式中，上述执行主体可以通过如下方式执行上述第二步骤：根据接收到的自定义操作，确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

作为示例，第一中继传输模块和第二中继传输模块的开发人员可以对流媒体数据的转发逻辑、传输协议，以及上述的速率控制、应答、负面应答、重传、连接维护等功能进行自定义操作，从而得到确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

本实现方式中，基于自定义开发方式，提高了第一中继传输模块、第二中继传输模块，与第一服务、第二服务的适配性，以及开发过程的灵活性，有助于提高连接后的第一服务和第二服务之间的数据传输效率和准确度。

在本实施例的一些可选的实现方式中，上述第一服务为直播服务，第二服务为视频会议服务，本实现方式中，上述执行主体可以通过如下方式执行上述步骤201：

第一，基于第一服务的推流端的推流请求，获取采用预设初始传输协议、预设初始音视频编码格式的直播流媒体数据。

作为示例，预设初始传输协议可以是RTMP(Real-Time Messaging Protocol，实时消息传输协议)、SRT(Secure Reliable Transport，安全可靠传输协议)、RTC(Real-TimeCommunication，实时交互)等传输协议；预设初始音视频编码格式可以是AAC(AdvancedAudio Coding，高级音频编码)、VAC(Advanced Video Coding，高级视频编码)等编码格式。

本实现方式中，支持多种预设初始传输协议和多种预设初始音视频编码格式。

第二，将直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

其中，预设目标传输协议表征直播流媒体数据最终被期望采用的传输协议，预设目标音视频编码格式表征直播流媒体数据最终被期望采用的编码格式。

对于直播服务所支持的多种预设初始传输协议、预设目标音视频编码格式，当预设初始传输协议与预设目标传输协议不同、预设初始音视频编码格式与预设目标音视频编码格式不同时，可以进行一次或多次的传输协议转换和编码格式转换，以最终得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

本实现方式中，基于传输协议转换和编码格式转换操作，上述执行主体在支持推流请求采用多种预设初始传输协议和多种预设初始音视频编码格式的基础上，能够转换得到适合于数据传输的流媒体数据，有助于提高信息传输过程的效率，以及流媒体数据与服务之间的适配性。

在本实施例的一些可选的实现方式中，上述执行主体可以通过如下方式执行上述第二步骤：

首先，响应于确定预设初始传输协议为第一传输协议、预设初始音视频编码格式为第一音视频编码格式，对所获取的直播流媒体数据进行传输协议转换，得到采用第二传输协议、第一音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一数据源。

作为示例，对于采用SRT传输协议、AAC编码格式的流媒体数据，一般中转至SRTSource，上述执行主体可以通过SRT2RTMPBridge模块将SRTSource中的流媒体数据转换为采用RTMP传输协议、AAC编码格式的流媒体数据，并将转换后的数据中转至第一数据源RTMPSource。

然后，将第一数据源中的直播流媒体数据进行格式转换和编码格式转换，得到采用第三传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第二数据源。

作为示例，对于第一数据源RTMPSource中的流媒体数据，通过RTMP2RTCBridge模块将其转换为采用RTC传输协议、Opus编码格式的流媒体数据，并将转换后的数据中转至第二数据源RTCSource。

最后，将第二数据源中的直播流媒体数据进行格式转换，得到采用自定义的第四传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一中继传输模块。其中，第四传输协议为预设目标传输协议，第二音视频编码格式为预设目标音视频编码格式

作为示例，对于第二数据源RTCSource中的直播流媒体数据，通过RTC2RelayioBridge模块将其转换为采用自定义的relayIO传输协议、Opus编码格式的流媒体数据，并将转换后的数据中转至第一中继传输模块RelayioSource。

如上所述，本实现方式中的推流请求支持多种预设初始传输协议。例如，当推流请求对应的直播流媒体数据采用RTMP协议、AAC编码格式，上述执行主体可以将中转至RTMPSource中的流媒体数据转换为采用RTC协议、AAC编码格式，并将转换后的流媒体数据中转至RTCSource中。进而，对于第二数据源RTCSource中的直播流媒体数据，将其转换为采用自定义的relayIO传输协议、Opus编码格式的流媒体数据，并将转换后的数据中转至第一中继传输模块RelayioSource。

又例如，当推流请求对应的直播流媒体数据采用RTC协议，只需将第二数据源RTCSource中的直播流媒体数据，转换为采用自定义的relayIO传输协议、Opus编码格式的流媒体数据，并将转换后的数据中转至第一中继传输模块RelayioSource。

本实现方式中，提供了直播服务中的流媒体数据的具体转换方式，进一步提高了数据传输过程的效率，以及流媒体数据与服务之间的适配性。

在本实施例的一些可选的实现方式中，对于上述第一服务为直播服务，第二服务为视频会议服务的情形，上述执行主体可以通过如下方式执行上述步骤203：

第一，基于拉流请求和连接，通过第二服务中的第二中继传输模块，确定第一服务中的第一中继传输模块中的直播流媒体数据。

第二，将所获取的直播流媒体数据进行传输协议转换，得到采用第五传输协议的直播流媒体数据。

本实现方式中，上述执行主体可以对第一中继传输模块中的直播流媒体数据进行传输协议转换，得到采用UDT传输协议的直播流媒体数据。

第三，将转换后的直播流媒体数据分发至第二服务的拉流端。

作为示例，分发过程如下：

1、ConsumerClient创建WebRtcTransport以建立与SignalServer(信令服务器)的连接。

ConsumerClient是消费端对直播流进行拉取和观看的客户端应用程序。它通过创建WebRtcTransport对象建立与SignalServer的连接来请求拉流并设置接收参数(如媒体类型、码率等)以及规定如何采样和发送数据的格式。

2、SignalServer收到拉流请求后创建CreateSubScriber。

SignalServer是整个系统的信令服务器。当它收到ConsumerClient发送的拉流请求后，会根据请求内容向Worker(工作节点)请求创建相应的Subscriber(订阅)。

3、Worker收到请求后，在AsyncBuildRelayPath与RtpRelayIO之间建路。

Worker组件是位于SignalServer和RtpRelayIO之间的中间组件，它负责处理信令信息并控制多个RtpRelayIO组件的行为，实现RelayTransport连接的建立和维护。在这一步骤中，Worker处理订阅请求并通知RtpRelayIO模块，在AsyncBuildRelayPath与RtpRelayIO之间建路。

4、RtpRelayIO收到后将心跳通过RelayServer模块中继到对应发布流的RtpRelayIO模块。

当RtpRelayIO模块接收到Subscription Request后，它会向上游的RtpRelayIO发送心跳信号和状态信息，并在日志或控制台上输出此次传输的一些关键数据。

5、上行Producer(生产者)对应的Worker收到建路请求后，创建SDP信息，并发送到RtpRelayIO中继。

在这个阶段，Producer的Worker接收到Subscriber请求，并生成SDP信息。这个信息描述与Producer相关的媒体流，包括编码格式、媒体类型、带宽等详细信息。Worker将这个信息发送给RtpRelayIO组件，然后通过中继将信息从推流端转发到拉流端。

6、通过中继后Subscriber Worker收到对应的SDP信息后，创建RelayTransport。

当Subscriber的Worker收到Producer的SDP信息时，它会开始解析该信息并建立RelayTransport连接。通过RelayTransport连接，拉流端和推流端之间可以进行实时音视频的传输。这个过程还包括了与协商相关的步骤，例如ICE(Interactive ConnectivityEstablishment)候选项交换和NAT(Network Address Translation，网络地址转换)穿透等操作。

7、建路成功后，Producer worker会将rtpData分发到下行订阅Consumer Worker。

建立RelayTransport连接后，Producer和Consumer(消费者)的Worker之间建立通道，并开始实时传输音视频数据。在这个过程中，Producer worker发送RTP(Real-timeTransport Protocol，实时传输协议)数据包到RtpRelayIO组件，RtpRelayIO再将这些数据包分发到订阅端的Consumer worker中。

8、Consumer Client通过WebRtcTransport收到对应Worker的分发流。

视频会议服务可以基于mediasoup实现，其中涉及有以下三种Transport类型：

WebRtcTransport：用于WebRTC连接上的媒体传输。该Transport支持数据加密，并提供了复杂的网络拓扑追踪和拥塞控制功能。

PlainRtpTransport：用于非WebRTC应用程序和设备之间的媒体流传输。该Transport不支持数据加密和网路拥塞控制功能，但具有廉价、简单和易于使用的优点。

PipeTransport：可以看作是PlainRtpTransport的升级版，它提供与PlainRtpTransport相同的特性，同时还具有对称加密、鲁棒性、动态路由和慢启动等更高级的功能。PipeTransport通常被用于媒体网关或其他需要处理大量媒体流数据的高级应用程序环境中。

本实现方式中，提供了一种视频会议服务中的拉流端对应的拉流请求的操作过程，基于上述操作过程，视频会议服务中的拉流端可以便捷地查看直播服务中的直播流媒体数据，提高了视频会议服务和直播服务的交互性。

在本实施例的一些可选的实现方式中，上述第一服务为视频会议服务，第二服务为直播服务。本实现方式中，上述执行主体可以通过如下方式执行上述步骤201：

第一，基于第一服务的推流端的推流请求，生成第一服务的推流端对应的流媒体数据生产者对象。

第二，基于流媒体数据生产者对象，获取第一服务的推流端的视频会议流媒体数据。

作为示例，首先，ProducerClient创建一个WebRtcTransport连接，并使用SignalServer(信令服务器)提供的信令通道建立连接。然后，Signal Server收到推流请求后，会向MediasoupWorker发送CreateProducer请求，用于创建流媒体数据生产者对象。然后，MediasoupWorker接收到CreateProducer请求后，会异步调用AsyncBuildRouter与RtpProducer来构建路由和注册RTP生产者。在这个过程中，MediasoupWorker会生成一个SDP要约，其中包含有需要等待的媒体传输协议端口，以便客户端可以向该端口推送媒体数据。最后，在ProducerClient接收到SDP要约请求后，会选择合适的编码格式以及网络参数进行编码，并发送RTP数据到MediasoupWorker提供的端口。同时，它还使用Signal Server提供的信令通道将响应SDP变更后的Answer发送回到Signal Server。

本实现方式中，提供了一种视频会议服务中的推流端对应的推流请求的操作过程。

在本实施例的一些可选的实现方式中，在第一服务为视频会议服务，第二服务为直播服务的情形下，上述执行主体可以通过如下方式执行上述步骤203：

第一，根据接收到的第二服务的拉流端的拉流请求，在第一数据源、第二数据源和第一中继传输模块中依次进行回源，并基于连接，将第一中继传输模块中的拉流请求回源至第二中继传输模块。

作为示例，首先，拉流端Player将拉流请求播放到LiveServer；然后，LiveServer将拉流请求回源到RtmpSource模块；然后，RtmpSource回源拉流请求到RtcSource模块；然后，RtcSource模块回源请求到RelayioSource模块；最后，RelayioSource模块触发建路操作，将拉流请求回源到直播服务。

第二，基于连接，通过第二中继模块将视频会议流媒体数据依次在第一中继传输模块、第二数据源、第一数据源中进行回调，并将回调后的视频会议流媒体数据分发至第二服务的拉流端。

作为示例，RelayioSource模块收到视频会议流媒体数据后，通过Relayio2RtcBridge模块回调到RtcSource模块，RtcSource将RTP数据通过Rtc2RtmpBridge回调到RtmpSource；Player收到LiveServer分发的视频会议流媒体数据。

本实现方式中，提供了一种直播服务中的拉流端对应的拉流请求的操作过程，基于上述操作过程，直播服务中的拉流端可以便捷地查看视频会议服务中的流媒体数据，提高了视频会议服务和直播服务的交互性。

继续参考图5，示出了根据本申请的流媒体数据的传输方法的又一个实施例的示意性流程500，包括如下步骤：

步骤501，基于直播服务的推流端的推流请求，获取采用预设初始传输协议、预设初始音视频编码格式的直播流媒体数据。

步骤502，将直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

步骤503，确定接收到的拉流请求是否来自视频会议服务的拉流端。

步骤504，响应于确定是，基于拉流请求和连接，通过视频会议服务中的第二中继传输模块，确定直播服务中的第一中继传输模块中的直播流媒体数据。

步骤505，将所获取的直播流媒体数据进行传输协议转换，得到采用第五传输协议的直播流媒体数据。

步骤506，将转换后的直播流媒体数据分发至视频会议服务的拉流端。

从本实施例中可以看出，与图2对应的实施例相比，本实施例中的流媒体数据的传输方法的流程500具体说明了视频会议服务的拉流端获取直播服务中的推流端的直播流媒体数据的过程，可以降低中转线路节点引入的延时，同时也能实现直播入会的效果，并且，通过直播服务级联视频会议服务，可以满足旁路直播、云端录制等需求，能够进一步优化节省分发带宽，而且，视频会议服务集群可支持大型级联部署，极大提升并发能力。

继续参考图6，示出了根据本申请的流媒体数据的传输方法的又一个实施例的示意性流程600，包括如下步骤：

步骤601，基于视频会议服务的推流端的推流请求，生成视频会议服务的推流端对应的流媒体数据生产者对象。

步骤602，基于流媒体数据生产者对象，获取视频会议服务的推流端的视频会议流媒体数据。

步骤603，确定接收到的拉流请求是否来自直播服务的拉流端。

步骤604，响应于确定是，根据接收到的直播服务的拉流端的拉流请求，在第一数据源、第二数据源和第一中继传输模块中依次进行回源，并基于连接，将第一中继传输模块中的拉流请求回源至第二中继传输模块。

步骤605，基于连接，通过第二中继模块将视频会议流媒体数据依次在第一中继传输模块、第二数据源、第一数据源中进行回调，并将回调后的视频会议流媒体数据分发至直播服务的拉流端。

从本实施例中可以看出，与图2对应的实施例相比，本实施例中的流媒体数据的传输方法的流程600具体说明了直播服务的拉流端获取视频会议服务中的推流端的视频会议流媒体数据的过程，能够满足直播过程中对于视频会议服务中的流媒体数据的获取需求，提高了直播服务和视频会议服务之间的交互性。

继续参考图7，作为对上述各图所示方法的实现，本申请提供了一种流媒体数据的传输装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图7所示，流媒体数据的传输装置700包括：获取单元701，被配置成基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定单元702，被配置成确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；传输单元703，被配置成响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。

在本实施例的一些可选的实现方式中，上述装置还包括：建连单元(图中未示出)，被配置成：确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块；基于第一中继传输模块和第二中继传输模块，建立第一服务和第二服务之间的连接。

在本实施例的一些可选的实现方式中，上述建连单元(图中未示出)，进一步被配置成：根据接收到的自定义操作，确定第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

在本实施例的一些可选的实现方式中，上述第一服务为直播服务，第二服务为视频会议服务，以及上述获取单元701，进一步被配置成：基于第一服务的推流端的推流请求，获取采用预设初始传输协议、预设初始音视频编码格式的直播流媒体数据；将直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

在本实施例的一些可选的实现方式中，上述获取单元701，进一步被配置成：响应于确定预设初始传输协议为第一传输协议、预设初始音视频编码格式为第一音视频编码格式，对所获取的直播流媒体数据进行传输协议转换，得到采用第二传输协议、第一音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一数据源；将第一数据源中的直播流媒体数据进行格式转换和编码格式转换，得到采用第三传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第二数据源；将第二数据源中的直播流媒体数据进行格式转换，得到采用自定义的第四传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一中继传输模块，其中，第四传输协议为预设目标传输协议，第二音视频编码格式为预设目标音视频编码格式。

在本实施例的一些可选的实现方式中，上述第一服务为直播服务，第二服务为视频会议服务，以及上述传输单元703，进一步被配置成：基于拉流请求和连接，通过第二服务中的第二中继传输模块，确定第一服务中的第一中继传输模块中的直播流媒体数据；将所获取的直播流媒体数据进行传输协议转换，得到采用第五传输协议的直播流媒体数据；将转换后的直播流媒体数据分发至第二服务的拉流端。

在本实施例的一些可选的实现方式中，上述第一服务为视频会议服务，第二服务为直播服务，以及上述获取单元701，进一步被配置成：基于第一服务的推流端的推流请求，生成第一服务的推流端对应的流媒体数据生产者对象；基于流媒体数据生产者对象，获取第一服务的推流端的视频会议流媒体数据。

在本实施例的一些可选的实现方式中，上述第一服务为视频会议服务，第二服务为直播服务，以及上述传输单元703，进一步被配置成：根据接收到的第二服务的拉流端的拉流请求，在第一数据源、第二数据源和第一中继传输模块中依次进行回源，并基于连接，将第一中继传输模块中的拉流请求回源至第二中继传输模块；基于连接，通过第二中继模块将视频会议流媒体数据依次在第一中继传输模块、第二数据源、第一数据源中进行回调，并将回调后的视频会议流媒体数据分发至第二服务的拉流端。

本实施例中，流媒体数据的传输装置中的获取单元基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定单元确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；传输单元响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端，从而基于直播服务和视频会议服务之间的连接，实现直播转RTC(Real-Time Communication，实时交互)，以及RTC转直播的效果；一方面，通过视频会议服务级联直播服务，可以降低中转线路节点引入的延时，同时也能实现直播入会的效果；另一方面，通过直播服务级联视频会议服务，可以满足旁路直播、云端录制等需求，能够进一步优化节省分发带宽，而且，视频会议服务集群可支持大型级联部署，极大提升并发能力。

下面参考图8，其示出了适于用来实现本申请实施例的设备(例如图1所示的设备101、102、103、105)的计算机系统800的结构示意图。图8示出的设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括处理器(例如CPU，中央处理器)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM803中，还存储有系统800操作所需的各种程序和数据。处理器801、ROM802以及RAM803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被处理器801执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，程序设计语言包括面向目标的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在客户计算机上执行、部分地在客户计算机上执行、作为一个独立的软件包执行、部分在客户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到客户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器，包括获取单元、确定单元和传输单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，传输单元还可以被描述为“响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端的单元”。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该装置执行时，使得该计算机设备：基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，第一服务为直播服务、视频会议服务中的一种服务；确定接收到的拉流请求是否来自第二服务的拉流端，其中，第二服务为直播服务、视频会议服务中的另一种服务；响应于确定是，基于第一服务和第二服务之间的连接，将流媒体数据传输至第二服务的拉流端。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (11)

1.一种流媒体数据的传输方法，包括：

基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，所述第一服务为直播服务、视频会议服务中的一种服务；

确定接收到的拉流请求是否来自第二服务的拉流端，其中，所述第二服务为直播服务、视频会议服务中的另一种服务；

响应于确定是，基于所述第一服务和所述第二服务之间的连接，将所述流媒体数据传输至所述第二服务的拉流端。

2.根据权利要求1所述的方法，其中，在所述基于第一服务的推流端的推流请求，获取待推流的流媒体数据之前，还包括：

确定所述第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和所述第二服务中用于对流媒体数据进行中继传输的第二中继传输模块；

基于所述第一中继传输模块和所述第二中继传输模块，建立所述第一服务和所述第二服务之间的连接。

3.根据权利要求2所述的方法，其中，所述确定所述第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和所述第二服务中用于对流媒体数据进行中继传输的第二中继传输模块，包括：

根据接收到的自定义操作，确定所述第一服务中用于对流媒体数据进行中继传输的第一中继传输模块，和所述第二服务中用于对流媒体数据进行中继传输的第二中继传输模块。

4.根据权利要求2所述的方法，其中，所述第一服务为直播服务，所述第二服务为视频会议服务，以及

所述基于第一服务的推流端的推流请求，获取待推流的流媒体数据，包括：

基于所述第一服务的推流端的推流请求，获取采用预设初始传输协议、预设初始音视频编码格式的直播流媒体数据；

将所述直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据。

5.根据权利要求4所述的方法，其中，所述将所述直播流媒体数据进行传输协议转换和编码格式转换，得到采用预设目标传输协议、预设目标音视频编码格式的直播流媒体数据，包括：

响应于确定所述预设初始传输协议为第一传输协议、所述预设初始音视频编码格式为第一音视频编码格式，对所获取的直播流媒体数据进行传输协议转换，得到采用第二传输协议、第一音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第一数据源；

将所述第一数据源中的直播流媒体数据进行格式转换和编码格式转换，得到采用第三传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至第二数据源；

将所述第二数据源中的直播流媒体数据进行格式转换，得到采用自定义的第四传输协议、第二音视频编码格式的直播流媒体数据，并将转换后的直播流媒体数据中转至所述第一中继传输模块，其中，所述第四传输协议为所述预设目标传输协议，所述第二音视频编码格式为所述预设目标音视频编码格式。

6.根据权利要求2所述的方法，其中，所述第一服务为直播服务，所述第二服务为视频会议服务，以及

所述基于所述第一服务和所述第二服务之间的连接，将所述流媒体数据传输至所述第二服务的拉流端，包括：

基于所述拉流请求和所述连接，通过所述第二服务中的第二中继传输模块，确定所述第一服务中的第一中继传输模块中的直播流媒体数据；

将所获取的直播流媒体数据进行传输协议转换，得到采用第五传输协议的直播流媒体数据；

将转换后的直播流媒体数据分发至所述第二服务的拉流端。

7.根据权利要求1所述的方法，其中，所述第一服务为视频会议服务，所述第二服务为直播服务，以及

所述基于第一服务的推流端的推流请求，获取待推流的流媒体数据，包括：

基于所述第一服务的推流端的推流请求，生成所述第一服务的推流端对应的流媒体数据生产者对象；

基于所述流媒体数据生产者对象，获取所述第一服务的推流端的视频会议流媒体数据。

8.根据权利要求5所述的方法，其中，所述第一服务为视频会议服务，所述第二服务为直播服务，以及

所述基于所述第一服务和所述第二服务之间的连接，将所述流媒体数据传输至所述第二服务的拉流端，包括：

根据接收到的所述第二服务的拉流端的拉流请求，在所述第一数据源、所述第二数据源和所述第一中继传输模块中依次进行回源，并基于所述连接，将所述第一中继传输模块中的拉流请求回源至所述第二中继传输模块；

基于所述连接，通过所述第二中继模块将所述视频会议流媒体数据依次在所述第一中继传输模块、所述第二数据源、所述第一数据源中进行回调，并将回调后的视频会议流媒体数据分发至所述第二服务的拉流端。

9.一种流媒体数据的传输装置，包括：

获取单元，被配置成基于第一服务的推流端的推流请求，获取待推流的流媒体数据，其中，所述第一服务为直播服务、视频会议服务中的一种服务；

确定单元，被配置成确定接收到的拉流请求是否来自第二服务的拉流端，其中，所述第二服务为直播服务、视频会议服务中的另一种服务；

传输单元，被配置成响应于确定是，基于所述第一服务和所述第二服务之间的连接，将所述流媒体数据传输至所述第二服务的拉流端。

10.一种计算机可读介质，其上存储有计算机程序，其中，所述程序被处理器执行时实现如权利要求1-8中任一所述的方法。

11.一种电子设备，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-8中任一所述的方法。