媒体数据处理方法及装置、系统、电子设备和存储介质与流程

1.本公开涉及计算机和通信技术领域，具体而言，涉及一种媒体数据处理方法及装置、系统、电子设备和计算机可读存储介质。


背景技术：

2.相关技术中，由于网络(web)浏览页面端和客户端使用的媒体协议不同，从而导致使用浏览页面的用户(可以称之为web用户)与使用客户端的用户(可以称之为客户端用户)之间无法进行顺畅地媒体通信。


技术实现要素：

3.本公开实施例提供一种媒体数据处理方法及装置、系统、电子设备和计算机可读存储介质，能够实现采用不同媒体协议的目标页面浏览端与目标客户端之间传输媒体数据。
4.本公开实施例提供一种媒体数据处理方法，方法由流媒体服务器执行，流媒体服务器包括媒体传输通道和代理传输通道。其中，方法包括：通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据；通过媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道；利用代理传输通道将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据；通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
5.本公开实施例提供一种媒体数据处理装置，媒体数据处理装置设置于流媒体服务器，流媒体服务器包括媒体传输通道和代理传输通道。装置包括：待发布媒体数据接收单元，用于通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据；待发布媒体数据转发单元，用于通过媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道；待发布媒体数据转换单元，用于利用代理传输通道将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据；待发布媒体数据发送单元，用于通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
6.本公开实施例提供一种媒体数据传输系统，系统包括流媒体服务器，流媒体服务器包括媒体传输通道和代理传输通道。其中，媒体传输通道用于从目标网页登录终端接收采用网页通信媒体协议封装的待发布媒体数据，并将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道；代理传输通道用于将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据，并将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端登录终端。
7.本公开实施例提供了一种计算机可读存储介质，其上存储有计算机程序，程序被处理器执行时实现如上述实施例中的媒体数据处理方法。
8.本公开实施例提供了一种电子设备，包括：至少一个处理器；存储装置，配置为存
储至少一个程序，当至少一个程序被至少一个处理器执行时，使得至少一个处理器实现如上述实施例中的媒体数据处理方法。
9.根据本公开的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例的各种可选实现方式中提供的媒体数据处理方法。
10.在本公开的一些实施例所提供的技术方案中，通过在流媒体服务器中增加代理传输通道，并使该代理传输通道具有网页通信媒体协议和客户端媒体协议之间的转换功能，从而使得当该流媒体服务器中的媒体传输通道从目标页面浏览端接收到采用该网页通信媒体协议封装的待发布媒体数据时，可以将该采用该网页通信媒体协议封装的待发布媒体数据转发至该代理传输通道，该代理传输通道能够将采用该网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据，借助该代理传输通道再将该采用客户端媒体协议封装的待发布媒体数据传输至相应的目标客户端，实现了将目标页面浏览端发送的基于网页通信媒体协议封装的待发布媒体数据传输至基于客户端媒体协议的目标客户端，即实现了采用不同媒体协议的目标页面浏览端与目标客户端之间的互联互通。
附图说明
11.图1示出相关技术中的流媒体服务器的示意图。
12.图2示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。
13.图3示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。
14.图4示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。
15.图5示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。
16.图6示意性示出了根据本公开的一实施例的流媒体服务器的示意图。
17.图7示意性示出了根据本公开的一实施例的媒体数据传输系统的示意图。
18.图8示意性示出了根据本公开的一实施例的上行媒体数据流的传输时序图。
19.图9示意性示出了根据本公开的一实施例的下行媒体数据流的传输时序图。
20.图10示意性示出了根据本公开的一实施例的媒体数据处理装置的框图。
21.图11示出了适于用来实现本公开实施例的电子设备的结构示意图。
具体实施方式
22.现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本公开将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。
23.本公开所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知
方法、装置、实现或者操作以避免模糊本公开的各方面。
24.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和步骤，也不是必须按所描述的顺序执行。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
25.本说明书中，用语“一个”、“一”、“该”、“所述”和“至少一个”用以表示存在至少一个要素/组成部分/等；用语“包含”、“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”、“第二”和“第三”等仅作为标记使用，不是对其对象的数量限制。
26.webrtc(web real
‑
time communication，网页实时通信)是html5(hyper text markup language 5，超文本标记语言5，简写为h5)支持的重要特性之一，webrtc是一种可以支持网络浏览器进行实时多媒体通信的技术，与传统的基于本地客户端或浏览器插件的多媒体通信方式不同，webrtc通过将多媒体通信所必须的处理(采集、编码和增强)、网络传输和会话控制等核心模块集成到浏览器内部，从而使第三方应用开发者仅需通过简单的javascript(是一种具有函数优先的轻量级、解释型或即时编译型的编程语言，简写为js)api(application programming interface，应用程序接口)调用即可获得实时的多媒体通信能力。
27.图1示出相关技术中的流媒体服务器的示意图。
28.如图1所示，以开源的janus流媒体服务器为例，主要由三个部分组成，分别是核心(core)101、插件(plugin)102和传输通道(transport)103。
29.其中，core 101的作用是处理数据流的转发，以及各种协议的接入，包括ice(interactive connectivity establishment，交互式连接建立)、dtls(datagram transport layer security，数据报传输层安全)、rtp(real
‑
time transport protocol，实时传输协议)、rtcp(real
‑
time transport control protocol，实时传输控制协议)、srtp(secure real
‑
time transport protocol，安全实时传输协议)、sctp(stream control transmission protocol，流控制传输协议，是一种在网络连接两端之间同时传输多个数据流的协议，sctp提供的服务与udp(user datagram protocol，用户数据报协议)和tcp(transmission control protocol，传输控制协议)类似)、sdp(session description protocol，描述会话协议，是一种信息格式的描述标准，本身不属于传输协议，但是可以被其他传输协议用来交换必要的信息，用于两个会话实体之间的媒体协商)，是webrtc技术的具体实现。
30.janus的业务管理是按照plugin 102的方式管理的，因此开发者可以在janus中根据自己的需要实现自己的业务插件。实际上，对于一般性的需求，janus已经有相关的插件，例如视频房间(videoroom)、视频呼叫(videocall)、文本房间(textroom)、流(streaming)、sip(session initiation protocol，会话初始协议)、音频房间(audioroom)。其中，可使用videoroom视频房间插件进行多人音视频互动。
31.transport 103是janus的信令传输层。janus并没有限定信令接口使用的信令传输协议，当前支持的协议有http(hypertext transfer protocol，超文本传输协议)、websocket(网络套接字)、mqtt(message queuing telemetry transport，消息队列遥测传输)、nanomsg(是一种消息队列)和rabbitmq(是一种消息队列)。
32.但是，图1所示的流媒体服务器只能实现多个web用户(例如，通过网络浏览器登录的用户)与基于webrtc传输协议栈的用户之间的互联互通，却无法实现web用户与客户端媒体协议例如私有音视频协议系统中的用户互联互通。而客户端媒体协议例如私有音视频协议有别于webrtc等开源的传输协议栈，可以做到更加精细化的网络传输控制，目前比较难以替换。
33.基于上述相关描述，本公开实施例提出了一种媒体数据处理方法。本公开各实施例提供的媒体数据处理方法可以由上述所提及的任一电子设备执行，该电子设备可以是服务器(包括流媒体服务器、信令服务器和媒体服务器等)，也可以是终端(包括目标网页登录终端和目标客户端登录终端等)，也可以是服务器和终端之间交互实现。
34.本公开实施例中的服务器可以是独立的服务器，也可以是多个服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
35.下面结合附图对本公开示例实施方式进行详细说明。
36.图2示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。图2实施例提供的方法以流媒体服务器执行为例进行举例说明，但本公开并不限定于此。本公开实施例提供的方法可以应用于视频点播、视频会议、视频聊天、语音聊天、远程教育、远程医疗和在线直播等涉及媒体数据传输的应用场景中。
37.本公开实施例中，流媒体指以流方式在网络中传送音频、视频和多媒体文件等媒体数据的媒体形式。相对于下载后观看的网络播放形式而言，流媒体可以把连续的音频和视频信息等压缩后放到网络服务器上，用户边下载边观看，而不必等待整个文件下载完毕。
38.本公开实施例中，流媒体服务器(media server)的主要功能是对流媒体内容进行采集、缓存、调度和传输播放，例如可以处理web用户的音视频数据流，并且转发给其它对应的用户。流媒体服务器可以是任意一台或者多台被选择用于处理当前待处理的媒体数据的流媒体服务器。在下面的举例说明中，以流媒体服务器为mediasoup为例进行举例说明，但本公开并不限定于此。
39.其中，mediasoup是一个开源的sfu(selective forwarding unit，选择性转发单元)模式的流媒体服务器。
40.如图2所示，本公开实施例提供的方法可以包括以下步骤。
41.在步骤s210中，通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据。
42.本公开实施例中，网页通信媒体协议是指能够实现页面浏览端媒体通信的协议。在下面的举例说明中，均以网页通信媒体协议为webrtc传输协议栈(简称为网页实时通信协议)为例进行举例说明，但本公开并不限定于此。与此对应的，基于网页通信媒体协议的媒体传输通道可以标记为webrtctransport，即基于webrtc传输协议栈或者网页实时通信协议的传输通道。
43.本公开实施例中，流媒体服务器中的传输通道(transport)可以包括上述基于网页通信媒体协议的媒体传输通道，还可以包括下文的代理传输通道，传输通道可以基于udp或者sctp等。
44.在示例性实施例中，媒体传输通道可以包括用于发布流(publish)的媒体传输通道，可以用于实现目标页面浏览端到目标客户端的上行媒体数据(即待发布媒体数据)的传输。
45.本公开实施例中，目标页面浏览端是指用户(均以用户a为例)浏览web网页的一端，例如通过其上安装的某一浏览器浏览目标网页，该目标页面浏览端对应的终端可以称之为目标网页登录终端(均以终端a为例)。在下面的举例说明中，均以该用户a通过目标网页登录终端上的浏览器中的webrtc模块发起实时的媒体数据的传输，例如实时语音、实时视频等为例进行举例说明，此时也可以称该用户a为web用户或者浏览器用户。
46.本公开实施例中，待发布媒体数据是指web用户或者浏览器用户当前准备发送给目标客户端的上行媒体数据，例如上行语音流、上行视频流等。
47.在步骤s220中，通过媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道。
48.本公开实施例中，代理传输通道具有网页通信媒体协议和下文的客户端媒体协议的相互转换功能，且具有媒体数据的转发功能。
49.在示例性实施例中，代理传输通道可以包括用于订阅流(subscribe)的代理传输通道。
50.在示例性实施例中，在通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据之前，该方法还可以包括：通过用于发布流的媒体传输通道接收目标页面浏览端发起的第一生产者角色创建请求消息；用于发布流的媒体传输通道响应第一生产者角色创建请求消息，在用于发布流的媒体传输通道上生成第一生产者角色，并保存第一生产者角色的第一生产者角色标识；通过用于发布流的媒体传输通道向用于订阅流的代理传输通道发送第一消费者角色创建请求消息；通过用于订阅流的代理传输通道接收并响应第一消费者角色创建请求消息，在用于订阅流的代理传输通道上生成第一消费者角色；用于订阅流的代理传输通道使得第一消费者角色订阅第一生产者角色标识，形成第一消费者角色和第一生产者角色之间的发布订阅关系。进一步地，还可以保存第一消费者角色的第一消费者角色标识。
51.在示例性实施例中，在通过用于发布流的媒体传输通道接收目标页面浏览端发起的第一生产者角色创建请求消息之前，该方法还可以包括：通过流媒体服务器中的媒体流处理进程接收目标页面浏览端发起的第一传输通道创建请求消息；媒体流处理进程响应第一传输通道创建请求消息，在媒体流处理进程中创建用于发布流的媒体传输通道和用于订阅流的代理传输通道；媒体流处理进程生成用于发布流的媒体传输通道的标识(identity，id)和用于订阅流的代理传输通道的标识，并将用于发布流的媒体传输通道的标识和用于订阅流的代理传输通道的标识返回至目标页面浏览端。
52.在步骤s230中，利用代理传输通道将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据。
53.本公开实施例中，客户端媒体协议是指用于实现客户端媒体数据通信的协议，例如客户端采用的私有音视频协议。其中，私有音视频协议是指协议内容未公开的音视频协议，可以根据实际需求自定义。在下面的举例说明中，若客户端媒体协议为私有音视频协议中的私有音频协议，则该代理传输通道可标记为audiotransport。
54.可以理解的是，当媒体数据(包括上述待发布媒体数据以及下文的待订阅媒体数据)为音视频数据时，本公开实施例中的私有音视频协议可以仅包括私有音频协议(例如语音会话场景)，也可以仅包括私有视频协议，或者同时包括私有音频协议和私有视频协议，本公开对此不作限定。
55.本公开实施例中，代理传输通道知悉网页通信媒体协议例如webrtc和客户端媒体协议的编解码规则，因此，代理传输通道接收到采用网页通信媒体协议封装的待发布媒体数据时，可以利用网页通信媒体协议的解码规则从中解析出待发布媒体数据，然后利用客户端媒体协议的编码规则，重新打包该待发布媒体数据，生成采用客户端媒体协议封装的待发布媒体数据。
56.在步骤s240中，通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
57.本公开实施例中，目标客户端是指其它用户(即非上述浏览器用户以外的用户)在终端上安装的本地客户端，对应的终端称之为目标客户端登录终端，例如若该终端为移动终端，则其上安装的客户端称之为移动app(application，应用程序)端，对应的用户称之为移动app端用户；若该终端为非移动终端，例如pc端，则其上安装的客户端称之为pc客户端，对应的用户称之为pc客户端用户。
58.本公开实施例中，目标客户端采用客户端媒体协议与对应的媒体服务器进行媒体数据通信，该媒体服务器可以对采用客户端媒体协议的待发布媒体数据进行处理，例如确定要发送给哪些目标客户端，则可以将该采用客户端媒体协议的待发布媒体数据传输至这一个或多个目标客户端(即可以是一对一通信，也可以是一对多通信)。由于上述步骤s230中，流媒体服务器中的代理传输通道已经将浏览器用户发送的待发布媒体数据从网页通信媒体协议转换为与该目标客户端对应的客户端媒体协议，因此，可以通过该代理传输通道将该待发布媒体数据传输至该目标客户端。
59.本公开实施例中的客户端可以是游戏客户端、社交客户端等中的任意一种。其中，社交客户端是指通过网络实现用户和用户之间的信息交互的软件。该社交客户端可包括以下至少一种：即时通讯客户端，信息交流类客户端，等等。即时通讯是指一种允许两人或多人使用网络即时地传递文字、档案、语音等信息以及音视频交流的终端服务。
60.在示例性实施例中，通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据，可以包括：通过用于发布流的媒体传输通道，从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据。
61.其中，通过媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道，可以包括：基于第一消费者角色和第一生产者角色之间的发布订阅关系，通过用于发布流的媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至用于订阅流的代理传输通道。
62.其中，利用代理传输通道将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据，可以包括：利用用于订阅流的代理传输通道解析采用网页通信媒体协议封装的待发布媒体数据；用于订阅流的代理传输通道将解析获得的所述待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据。
63.其中，通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至
目标客户端，包括：通过用于订阅流的代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
64.本公开实施方式提供的媒体数据处理方法，通过在流媒体服务器中增加代理传输通道，并使该代理传输通道具有网页通信媒体协议和客户端媒体协议之间的转换功能，从而使得当该流媒体服务器中的媒体传输通道从目标页面浏览端接收到采用该网页通信媒体协议封装的待发布媒体数据时，可以将该采用该网页通信媒体协议封装的待发布媒体数据转发至该代理传输通道，该代理传输通道能够将采用该网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据，借助该代理传输通道再将该采用客户端媒体协议封装的待发布媒体数据传输至相应的目标客户端，实现了将目标页面浏览端发送的基于网页通信媒体协议封装的待发布媒体数据传输至基于客户端媒体协议的目标客户端，即实现了采用不同媒体协议的目标页面浏览端与目标客户端之间的互联互通。
65.图3示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。图3实施例中，描述了用于发布流的媒体传输通道和用于订阅流的代理传输通道协同，实现目标页面浏览端到目标客户端的上行媒体数据(即待发布媒体数据)的传输过程。且图3实施例中以网页通信媒体协议为网页实时通信协议，客户端媒体协议为私有音视频协议为例。
66.如图3所示，本公开实施例提供的方法可以包括以下步骤。
67.在步骤s301中，通过流媒体服务器中的媒体流处理进程接收目标页面浏览端发起的第一传输通道创建请求消息。
68.本公开实施例中，流媒体服务器中的媒体流处理进程(worker)，是指流媒体服务器中负责处理媒体流的进程或子进程，例如mediasoup中负责处理媒体流的进程。
69.在步骤s302中，媒体流处理进程响应第一传输通道创建请求消息，在媒体流处理进程中创建用于发布流的媒体传输通道和用于订阅流的代理传输通道。
70.在步骤s303中，媒体流处理进程生成用于发布流的媒体传输通道的标识和用于订阅流的代理传输通道的标识，并将其返回至目标页面浏览端。
71.在步骤s304中，通过用于发布流的媒体传输通道接收目标页面浏览端发起的第一生产者角色创建请求消息。
72.在示例性实施例中，流媒体服务器还可以包括脚本语言运行环境，脚本语言运行环境可以用于从分布式消息队列接收第一生产者角色创建请求消息，并将第一生产者角色创建请求消息发送至用于发布流的媒体传输通道。
73.本公开实施例中，脚本语言运行环境表示为nodejs，是一个基于chrome v8引擎的javascript运行环境。以流媒体服务器为mediasoup例，则该脚本语言运行环境表示为mediasoup nodejs。mediasoup可以包括mediasoup nodejs和mediasoup worker，mediasoup nodejs和mediasoup worker之间可以通过进程间通信。
74.本公开实施例中，可以采用任意合适的分布式消息队列，只要其能够满足性能上的要求即可，例如低延迟、吞吐量以及可靠性等。在下面的举例说明中，均以nats为例进行举例说明，但本公开并不限定于此，在其他实施例中，例如还可以采用activemq、kafka、rabbitmq、redis、kestrel、nsq等中的任意一种。
75.其中，nats是一个开源的轻量高性能的分布式消息队列，nats支持各种消息传递
模型，包括：发布订阅(publish subscribe)，发布者在subject上发送消息，并且监听该subject的订阅者都会收到该消息。
76.其中，分布式消息队列可以用于从信令服务器中的用户代理接收第一生产者角色创建请求消息。
77.本公开实施例中，信令服务器(sigserver)可以用于直接与web用户对应的目标页面浏览端通过websocket进行交互，接收web用户的指令/信令，例如控制媒体流开始、暂停、结束等行为。
78.其中用户代理本质上是一个类对象，它可以包含目标页面浏览端上目标网页的用户信息、用于发布流的媒体传输通道的标识和用于订阅流的代理传输通道的标识等，还可以包括下文中提及的用于订阅流的媒体传输通道的标识和用于发布流的代理传输通道的标识等，这些媒体传输通道和代理传输通道的标识可以统一标记为transport id，例如可包括发布流和订阅流的webrtctransport id，发布流和订阅流的代理传输通道的id等。
79.例如，用户信息可以包含通过目标页面浏览端登录目标网页的浏览器用户的一些基本信息，如用户id、用户登录票据、roomid、websdk连接的websocket等。其中roomid是指用户待发起语音或视频等通信的房间的标识。
80.用户代理可以理解为浏览器用户通过目标页面浏览端上的浏览器，在信令服务器上创建了一个标识自己的对象，后续浏览器用户通过目标页面浏览端上的浏览器的操作，都表现为操作该对象向流媒体服务器例如mediasoup发出相应的命令。在信令服务器中增加用户代理，可以用于标识浏览器用户、对浏览器用户进行合法性校验，以及响应浏览器用户的发布流与订阅流的操作，获得相应的返回值给目标页面浏览端上的浏览器。
81.在示例性实施例中，用户代理可以用于响应目标页面浏览端发送的发布流信令生成第一生产者角色创建请求消息，并将第一生产者角色创建请求消息发送至分布式消息队列。
82.在示例性实施例中，信令服务器可以用于响应目标页面浏览端发送的加入信令，在信令服务器中创建用户代理，并控制用户代理向分布式消息队列发送第一传输通道创建请求消息。分布式消息队列还可以用于将第一传输通道创建请求消息发送至脚本语言运行环境。脚本语言运行环境还可以用于将第一传输通道创建请求消息发送至媒体流处理进程。
83.在步骤s305中，用于发布流的媒体传输通道响应第一生产者角色创建请求消息，在用于发布流的媒体传输通道上生成第一生产者角色，并保存第一生产者角色的第一生产者角色标识。
84.producer是指生产者角色，对应于本公开实施例中产生媒体数据(包括上述待发布媒体数据和下文的待订阅媒体数据)例如音频或者视频的抽象实体。本公开实施例中的生产者角色包括这里的第一生产者角色和下文的第二生产者角色，第一生产者角色对应目标页面浏览端产生的待发布媒体数据，第二生产者角色对应下文目标客户端产生的待订阅媒体数据。发布流(publish)对应于producer的产生媒体数据例如视频或音频的行为。
85.在步骤s306中，通过用于发布流的媒体传输通道向用于订阅流的代理传输通道发送第一消费者角色创建请求消息。
86.在步骤s307中，通过用于订阅流的代理传输通道接收并响应第一消费者角色创建
请求消息，在用于订阅流的代理传输通道上生成第一消费者角色。进一步地，还可以保存第一消费者角色的第一消费者角色标识。
87.consumer是指消费者角色，对应于本公开实施例中消费媒体数据例如音频或者视频的抽象实体。本公开实施例中的消费者角色包括这里的第一消费者角色和下文的第二消费者角色，第一消费者角色对应消费待发布媒体数据，第二消费者角色对应消费待订阅媒体数据。订阅流(subscribe)对应于consumer的接收媒体数据例如音频或视频的行为。
88.在步骤s308中，用于订阅流的代理传输通道使得第一消费者角色订阅第一生产者角色标识，形成第一消费者角色和第一生产者角色之间的发布订阅关系。
89.在步骤s309中，通过用于发布流的媒体传输通道，从目标页面浏览端接收采用网页实时通信协议封装的待发布媒体数据。
90.在步骤s310中，基于第一消费者角色和第一生产者角色之间的发布订阅关系，通过用于发布流的媒体传输通道将采用网页实时通信协议封装的待发布媒体数据，发送至用于订阅流的代理传输通道。
91.在步骤s311中，利用用于订阅流的代理传输通道解析采用网页实时通信协议封装的待发布媒体数据，将其转换为采用私有音视频协议封装的待发布媒体数据。
92.在示例性实施例中，用于订阅流的代理传输通道内可以包括媒体服务对象，媒体服务对象与媒体服务器之间维持用户数据报协议数据通道。
93.其中，利用用于订阅流的代理传输通道解析采用网页通信媒体协议封装的待发布媒体数据，将其转换为采用客户端媒体协议封装的待发布媒体数据，可以包括：利用媒体服务对象解析采用网页通信媒体协议封装的待发布媒体数据，将其转换为采用客户端媒体协议封装的待发布媒体数据。
94.在步骤s312中，通过用于订阅流的代理传输通道将采用私有音视频协议封装的待发布媒体数据，发送至采用私有音视频协议的媒体服务器。
95.其中，通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至采用客户端媒体协议的媒体服务器，可以包括：利用用户数据报协议数据通道(udp数据通道)，将采用客户端媒体协议封装的待发布媒体数据，发送至媒体服务器。
96.在步骤s313中，媒体服务器将采用私有音视频协议封装的待发布媒体数据发送至目标客户端。
97.本公开实施方式提供的媒体数据处理方法，通过流媒体服务器中的用于发布流的媒体传输通道和用于订阅流的代理传输通道，可以实现目标页面浏览端到目标客户端的上行媒体数据的传输，即实现了将目标页面浏览端发送的基于网页通信媒体协议封装的待发布媒体数据传输至基于客户端媒体协议的目标客户端，即使得用户web浏览器产生的待发布媒体数据例如音视频数据可以通过此代理传输通道注入到基于客户端媒体协议例如私有音视频协议的后台服务器或媒体服务器，解决了网页通信媒体协议与客户端媒体协议之间的上行媒体数据交换问题。即实现了将目标页面浏览端发送的基于网页实时通信协议封装的待发布媒体数据传输至基于客户端媒体协议的目标客户端，例如使得浏览器用户通过web浏览器产生的音视频数据可以通过此代理传输通道注入到基于私有音视频协议的媒体服务器，解决了开源的网页实时通信协议与私有音视频协议之间的数据交换问题，使得应用私有音视频协议的媒体通信系统可以实现与web端的互联互通，实现了web端与移动端以
及pc(personal computer，个人计算机)端上安装的本地客户端之间的互联互通。
98.图4示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。如图4所示，与上述图2实施例相比，本公开实施例提供的方法的不同之处在于，进一步还可以包括以下步骤。
99.在步骤s410中，通过代理传输通道从目标客户端接收采用客户端媒体协议封装的待订阅媒体数据。
100.其中采用客户端媒体协议封装的待订阅媒体数据可以是目标客户端先发送至媒体服务器，然后，该媒体服务器再将采用客户端媒体协议封装的待订阅媒体数据发送至流媒体服务器中的代理传输通道。
101.本公开实施例中，待订阅媒体数据是指目标客户端对应的其它端的用户(例如其它端的音视频用户)当前准备发送给目标页面浏览端对应的web用户或者浏览器用户的下行媒体数据，例如下行语音流、下行视频流等。
102.在示例性实施例中，媒体传输通道可以包括用于订阅流的媒体传输通道，代理传输通道可以包括用于发布流的代理传输通道。
103.其中，在通过代理传输通道从目标客户端接收采用客户端媒体协议封装的待订阅媒体数据之前，该方法还可以包括：通过用于发布流的代理传输通道接收目标页面浏览端发起的通知新用户发布流消息；用于发布流的代理传输通道响应通知新用户发布流消息，在用于发布流的代理传输通道上生成第二生产者角色，并保存第二生产者角色的第二生产者角色标识；通过用于发布流的代理传输通道向用于订阅流的媒体传输通道发送第二消费者角色创建请求消息；通过用于订阅流的媒体传输通道接收并响应第二消费者角色创建请求消息，在用于订阅流的媒体传输通道上生成第二消费者角色；通过用于订阅流的媒体传输通道使得第二消费者角色订阅第二生产者角色标识，形成第二消费者角色和第二生产者角色之间的发布订阅关系。进一步地，还可以保存第二消费者角色的第二消费者角色标识。
104.在示例性实施例中，在通过用于发布流的代理传输通道接收目标页面浏览端发起的通知新用户发布流消息之前，该方法还可以包括：通过流媒体服务器中的媒体流处理进程接收目标页面浏览端发起的第二传输通道创建请求消息；媒体流处理进程响应第二传输通道创建请求消息，在媒体流处理进程中创建用于订阅流的媒体传输通道和用于发布流的代理传输通道；媒体流处理进程生成用于订阅流的媒体传输通道的标识和用于发布流的代理传输通道的标识，并将用于订阅流的媒体传输通道的标识和用于发布流的代理传输通道的标识返回至目标页面浏览端。
105.在示例性实施例中，通过代理传输通道从目标客户端接收采用客户端媒体协议封装的待订阅媒体数据，可以包括：通过用于发布流的代理传输通道，从媒体服务器接收采用客户端媒体协议封装的待订阅媒体数据。其中采用客户端媒体协议封装的待订阅媒体数据是媒体服务器从目标客户端接收的。
106.在步骤s420中，通过代理传输通道将采用客户端媒体协议封装的待订阅媒体数据，转换为采用网页通信媒体协议封装的待订阅媒体数据。
107.其中，通过代理传输通道将采用客户端媒体协议封装的待订阅媒体数据，转换为采用网页通信媒体协议封装的待订阅媒体数据，可以包括：利用用于发布流的代理传输通道解析采用客户端媒体协议封装的待订阅媒体数据；用于发布流的代理传输通道将解析获
得的待订阅媒体数据，转换为采用网页通信媒体协议封装的待订阅媒体数据。
108.在步骤s430中，通过代理传输通道将采用网页通信媒体协议封装的待订阅媒体数据，发送至媒体传输通道。
109.其中，通过代理传输通道将采用网页通信媒体协议封装的待订阅媒体数据，发送至媒体传输通道，可以包括：基于第二消费者角色和第二生产者角色之间的发布订阅关系，通过用于发布流的代理传输通道将采用网页通信媒体协议封装的待订阅媒体数据，发送至用于订阅流的媒体传输通道。
110.在步骤s440中，通过媒体传输通道将采用网页通信媒体协议封装的待订阅媒体数据发送至目标页面浏览端。
111.其中，通过媒体传输通道将采用网页通信媒体协议封装的待订阅媒体数据发送至目标页面浏览端，可以包括：通过用于订阅流的媒体传输通道将采用网页通信媒体协议封装的待订阅媒体数据发送至目标页面浏览端。
112.本公开实施方式提供的媒体数据处理方法，通过在流媒体服务器中增加基于客户端媒体协议的代理传输通道，在该流媒体服务器中的基于客户端媒体协议的代理传输通道从媒体服务器接收到采用该客户端媒体协议封装的待订阅媒体数据时，该代理传输通道能够解析采用该客户端媒体协议封装的待订阅媒体数据，并将其转换为采用网页通信媒体协议封装的待订阅媒体数据，借助该代理传输通道再将该采用网页通信媒体协议封装的待订阅媒体数据传输至采用该网页通信媒体协议的媒体传输通道，从而使得采用该网页通信媒体协议的媒体传输通道能够将协议转换后的待订阅媒体数据发送至目标页面浏览端，实现了将目标客户端发送的基于客户端媒体协议封装的待订阅媒体数据传输至基于网页通信媒体协议的目标页面浏览端，即使得目标客户端产生的待订阅媒体数据例如音视频数据可以通过此代理传输通道注入到基于网页通信媒体协议，解决了网页通信媒体协议与客户端媒体协议之间的数据交换问题。
113.图5示意性示出了根据本公开的一实施例的媒体数据处理方法的流程图。图5实施例中，描述了用于订阅流的媒体传输通道和用于发布流的代理传输通道协同，实现目标客户端到目标页面浏览端的下行媒体数据(即待订阅媒体数据)的传输过程。且图5实施例中以网页通信媒体协议为网页实时通信协议，客户端媒体协议为私有音视频协议为例。
114.可以理解的是，本公开实施例中，假设媒体传输通道和代理传输通道均为单工通信，因此需要针对上行媒体数据(待发布媒体数据)的传输采用用于发布流的媒体传输通道和用于订阅流的代理传输通道，针对下行媒体数据(待订阅媒体数据)的传输采用用于订阅流的媒体传输通道和用于发布流的代理传输通道，但本公开并不限定于此。
115.还是以媒体数据为音视频数据为例，每个目标页面浏览端创建两个peerconnection分别用于发送待发布媒体数据和接收待订阅媒体数据，发送端用于发送承载本地videotrack(视频轨)和audiotrack(音频轨)的localstream(本地流)，接收端接收来自其它目标客户端的remotestream(远程流)。
116.如图5所示，与上述图3实施例相比，本公开实施例提供的方法还可以进一步包括以下步骤。
117.在步骤s501中，通过流媒体服务器中的媒体流处理进程接收目标页面浏览端发起的第二传输通道创建请求消息。
118.其中，信令服务器还可以用于响应目标页面浏览端发送的加入信令，在信令服务器中创建用户代理，并控制用户代理向分布式消息队列发送第二传输通道创建请求消息。分布式消息队列还可以用于将第二传输通道创建请求消息发送至脚本语言运行环境。脚本语言运行环境还可以用于将第二传输通道创建请求消息发送至媒体流处理进程。
119.在步骤s502中，媒体流处理进程响应第二传输通道创建请求消息，在媒体流处理进程中创建用于订阅流的媒体传输通道和用于发布流的代理传输通道。
120.在步骤s503中，媒体流处理进程生成用于订阅流的媒体传输通道的标识和用于发布流的代理传输通道的标识，并将其返回至目标页面浏览端。
121.在步骤s504中，通过用于发布流的代理传输通道接收目标页面浏览端发起的通知新用户发布流消息。
122.在示例性实施例中，流媒体服务器中的脚本语言运行环境还可以用于从分布式消息队列接收通知新用户发布流消息，并通过进程间通信将通知新用户发布流消息发送至用于订阅流的代理传输通道。
123.其中，分布式消息队列还可以用于从信令服务器中的用户代理接收通知新用户发布流消息。用户代理还可以用于响应目标页面浏览端发送的通知新用户发布流信令生成通知新用户发布流消息，并将通知新用户发布流消息发送至分布式消息队列。
124.本公开实施例中，通知新用户发布流(addnewusertrack)消息和通知新用户发布流信令中的新用户是指与浏览器用户进行媒体数据传输的其它用户，例如浏览器用户与之发起语音或者视频通话的移动app端用户和/或pc客户端用户，addnewusertrack消息/信令用于告知代理传输通道创建该新用户对应的发布流，以用于传输该新用户发布的媒体数据即待订阅媒体数据或者下行媒体数据。
125.在步骤s505中，用于发布流的代理传输通道响应通知新用户发布流消息，在用于发布流的代理传输通道上生成第二生产者角色，并保存第二生产者角色的第二生产者角色标识。
126.在步骤s506中，通过用于发布流的代理传输通道向用于订阅流的媒体传输通道发送第二消费者角色创建请求消息。
127.在步骤s507中，通过用于订阅流的媒体传输通道接收并响应第二消费者角色创建请求消息，在用于订阅流的媒体传输通道上生成第二消费者角色。
128.进一步地，还可以保存第二消费者角色的第二消费者角色标识。
129.在步骤s508中，通过用于订阅流的媒体传输通道使得第二消费者角色订阅第二生产者角色标识，形成第二消费者角色和第二生产者角色之间的发布订阅关系。
130.在步骤s509中，通过用于发布流的代理传输通道，从媒体服务器接收采用私有音视频协议封装的待订阅媒体数据。
131.在步骤s510中，利用用于发布流的代理传输通道解析采用私有音视频协议封装的待订阅媒体数据，将其转换为采用网页实时通信协议封装的待订阅媒体数据。
132.在步骤s511中，基于第二消费者角色和第二生产者角色之间的发布订阅关系，通过用于发布流的代理传输通道将采用网页实时通信协议封装的待订阅媒体数据，发送至用于订阅流的媒体传输通道。
133.在步骤s512中，通过用于订阅流的媒体传输通道将采用网页实时通信协议封装的
待订阅媒体数据发送至目标页面浏览端。
134.本公开实施例中，通过在流媒体服务器中增加代理传输通道，从而可以联通webrtc的浏览器用户和采用客户端媒体协议的其它端的用户，实现采用不同类型媒体协议的用户之间交换媒体数据例如音视频数据的功能，因此，也可以将该增加了代理传输通道的流媒体服务器作为webrtc网关。可以理解的是，虽然上述举例说明中，该webrtc网关用于不同类型媒体协议的用户之间交换媒体数据，但实际应用中，该webrtc网关也可以用于在不同的webrtc的浏览器用户之间交换媒体数据例如音视频数据，只是可以少了上述解析和转换过程。
135.本公开实施方式提供的媒体数据处理方法，通过流媒体服务器中的用于订阅流的媒体传输通道和用于发布流的代理传输通道，可以实现目标客户端到目标页面浏览端的下行媒体数据的传输，即实现了将目标客户端发送的基于客户端媒体协议封装的待订阅媒体数据传输至基于客户端媒体协议的目标页面浏览端，解决了网页通信媒体协议与客户端媒体协议之间的下行媒体数据交换问题。
136.图6示意性示出了根据本公开的一实施例的流媒体服务器的示意图。
137.图6实施例中，以网页通信媒体协议为webrtc为例，浏览器用户通过目标页面浏览端上的浏览器登录目标网页(例如社交或者游戏网页)，该浏览器可以包括webrtc模块621。
138.流媒体服务器610可以包括媒体流处理进程(worker)611，worker 611中可以包括用于发布流的媒体传输通道6111和用于订阅流的代理传输通道6112，以及用于订阅流的媒体传输通道6113和用于发布流的代理传输通道6114。
139.其中，浏览器用户通过浏览器上的操作，可以通过webrtc模块621向用于发布流的媒体传输通道6111发送基于webrtc传输协议栈的待发布媒体数据，用于发布流的媒体传输通道6111通过上述确定的用于发布流的媒体传输通道6111中的第一生产者角色和用于订阅流的代理传输通道6112中的第一消费者角色之间的发布订阅关系，可以将该基于webrtc传输协议栈的待发布媒体数据发送至用于订阅流的代理传输通道6112。该用于订阅流的代理传输通道6112接收到该基于webrtc传输协议栈的待发布媒体数据后，对其进行解析，然后重新打包成基于客户端媒体协议(这里以私有音视频协议为例)的待发布媒体数据，再将其发送至用于提供音视频服务的媒体服务器630，该媒体服务器630和其它端的音视频用户例如移动app端用户641和pc客户端用户642之间通过私有音视频协议进行通信，从而能够将该待发布媒体数据在其它端的音视频用户对应的目标客户端上播放。
140.其它端的音视频用户可以通过目标客户端向提供音视频服务的媒体服务器630发送基于私有音视频协议的待订阅媒体数据(例如待订阅音视频数据)，该媒体服务器630可以将该基于私有音视频协议的待订阅音视频数据发送至用于发布流的代理传输通道6114，用于发布流的代理传输通道6114可以对其进行解析，转换为基于webrtc传输协议栈的待订阅音视频数据，用于发布流的代理传输通道6114通过上述确定的用于发布流的代理传输通道6114中的第二生产者角色和用于订阅流的媒体传输通道6113中的第二消费者角色之间的发布订阅关系，可以将基于webrtc传输协议栈的待订阅音视频数据发送至用于订阅流的媒体传输通道6113，然后，用于订阅流的媒体传输通道6113可以将基于webrtc传输协议栈的待订阅音视频数据传输至浏览器用户对应的目标页面浏览端。
141.相关技术中的mediasoup的方案解决的是使用webrtc传输协议栈的用户之间的音
视频通信。它的router(路由)对象可以抽象成一个room，用户在room的管理下互相交换音视频数据，room下可以有很多用户。并且它们的信令层会在mediasoup nodesjs层做扩展，未做到信令与媒体服务的分离，不便于整个系统的动态扩容或缩容，一旦流媒体服务器出现故障，会导致整个系统不可用。图7实施例中，引入信令服务器sigserver和分布式消息队列nats，可以解决上述动态扩容问题。
142.图7示意性示出了根据本公开的一实施例的媒体数据传输系统的示意图。图7实施例以将本公开实施例提供的方法应用到游戏客户端的web语音房间为例进行举例说明，浏览器用户在目标页面浏览端例如pc或手机的h5页面访问游戏客户端的语音房间时，将提供web语音房间的语音通信能力。
143.其中，实时的语音房间其可使得与用户之间具备虚拟场景社交关系的其它用户均加入进去，进而在虚拟场景社交关系所对应的用户范围内实现实时语音。但本公开实施例提供的方法可以应用任意媒体数据传输的场景，例如网络电视直播、视频分享、在线电台、视频点播、视频会议、在线音乐点播等等，并不限定于此。
144.如图7所示，本公开实施例提供的媒体数据传输系统可以包括浏览器用户对应的目标页面浏览端、流媒体服务和提供语音服务的游戏语音系统。图7、图8和图9中以媒体服务器为游戏语音系统中的语音后台服务器为例进行举例说明。
145.目标页面浏览端的浏览器可以包括websdk模块622和webrtc模块621。其中，websdk模块622主要通过websocket和信令服务器(sigserver)650之间交互信令，webrtc模块621主要用于负责媒体流的生成、接收和传输。
146.参阅图7，流媒体服务部分可以包括信令服务器(sigserver)650、分布式消息队列(这里以nats为例)660和流媒体服务器。其中流媒体服务器(以mediasoup为例)又分为mediasoup nodejs 612和mediasoup worker 611部分，这两者通过进程间通信来交换信息。
147.图7实施例中，sigserver 650的作用包括维持与浏览器用户之间的信令联系。
148.sigserver 650可用于维持各个mediasoup的可发现状态，这类消息可包括各个mediasoup的心跳消息、各个mediasoup的负载信息(例如各个mediasoup上的用户数量，cpu(central processing unit，中央处理器)利用率，内存瞬时数据等)，在浏览器用户发送加入信令时，sigserver 650可以根据各个mediasoup的心跳消息确定能够正常通信的mediasoup，然后根据各个mediasoup的负载信息从能够正常通信的mediasoup中，选择最匹配的mediasoup来作为处理当前待处理的媒体数据的流媒体服务器，例如选择当前负载最轻的mediasoup来为浏览器用户服务，起到负责均衡的作用。
149.图7实施例中的代理传输通道可以包括图6实施例中的用于订阅流的代理传输通道6112和用于发布流的代理传输通道6114，流媒体服务器中还可以包括图6实施例中的用于发布流的媒体传输通道6111和用于订阅流的媒体传输通道6113，sigserver 650并不会处理流(例如媒体数据的传输)，sigserver 650用于传递流相关的消息，例如可以包括：通知流媒体服务器创建用于发布流的媒体传输通道和用于订阅流的代理传输通道的第一传输通道创建请求消息、通知流媒体服务器创建用于订阅流的媒体传输通道和用于发布流的代理传输通道的第二传输通道创建请求消息、通知用于发布流的媒体传输通道创建第一生产者角色的第一生产者角色创建请求消息、通知用于发布流的代理传输通道创建第二生产
者角色的通知新用户发布流消息、接收浏览器用户发送的发布流信令、接收浏览器用户发送的订阅流信令、以及通知流媒体服务器设置dtls参数的消息等。
150.nats 660作为一种低延迟的消息队列，在图7实施例中的作用是传递sigserver 650和mediasoup之间的消息，保持sigserver 650和mediasoup的一种松耦合结构。
151.同时，图7实施例中，信令传输与媒体数据传输分离的方式使得mediasoup与信令服务650之间是一种松耦合的关系，从而可以根据整个系统的负载状态，动态地增加mediasoup或sigserver 650来支持服务的正常运行，而不需要把整个系统停下来。而nats 660的作用是维系信令服务器650和mediasoup之间通信的桥梁。
152.mediasoup nodejs 612层可以方便mediasoup的扩展，可以方便的利用到nodejs相关的庞大工具库。在本公开实施例中mediasoup nodejs 612层主要用于在nats 660和流媒体服务器的媒体流处理进程worker 611之间透传参数，同时也可以对一些参数做简单的处理。
153.提供语音服务的游戏语音系统主要包含语音后台服务器631和各个客户端(例如移动app端和pc客户端)的sdk(software development kit，软件开发工具包)等部分。通过将用于实现语音通信的通信sdk植入到应用程序客户端中，并将对应的sdk植入到应用程序的后台服务器中，应用程序客户端中的通信sdk和后台服务器中的sdk之间通过私有语音协议完成音频通信。
154.图7实施例中，webrtc的信令传输可以慢些但需要可靠，而流媒体则优先考虑实时性，可以存在丢包、错包，因此，采用基于tcp的可靠传输协议用于信令等传输，采用基于udp的rtp协议(这里以该协议为例进行举例说明，但本公开并不限定于此，也可以采用其他协议)用于实时的媒体数据的传输。
155.webrtc为了保证媒体数据传输的安全性，可以通过dtls传输媒体数据，dtls是tls在udp数据传输上的扩展，可以理解为加密的udp数据传输通道。rtp相当于dtls上传输的数据包的一种格式。
156.图7实施例中，在信令服务器650中创建一个用户代理(client)，该用户代理负责保存浏览器用户的用户信息，并且控制mediasoup worker 611创建代理传输通道，该代理传输通道具有理解私有语音协议和rtp数据格式的能力，代理传输通道将浏览器用户webrtc 621传输过来的rtp数据(待发布媒体数据)中的媒体流信息解包出来，重新用私有语音协议打包，并且转发给提供语音服务的游戏语音系统。同时在该代理传输通道收到提供语音服务的游戏语音系统的私有语音协议的待订阅媒体数据的时候，将其语音载荷解包出来，重新包装成rtp数据包转发给浏览器用户对应的浏览器端播放。
157.图7实施例中，为了能够在mediasoup中实现基于私有语音协议的媒体数据和基于webrtc的媒体数据互通，简化了router的概念，去掉了router之内用户广播媒体数据和消息的能力，每一个web用户与同router中的其它用户不再直接产生媒体数据交换，它们都将媒体数据经过私有语音后台，然后再从私有语音后台接收媒体数据。每一个用户代理的媒体数据通道仅向自己的代理数据通道发布与订阅数据流，同样的自己的代理数据通道也仅向媒体数据通道发布和订阅数据流。媒体数据的广播在私有语音后台(可以扩展到音视频)实现而非在router中实现数据的广播扩散。
158.下面结合图8和图9对利用图7实施例提供的系统实现媒体数据传输的过程进行举
例说明。
159.图8示意性示出了根据本公开的一实施例的上行媒体数据流的传输时序图。图8实施例中以上行媒体数据流为上行语音流为例进行举例说明。
160.如图8所示，在步骤s11中，浏览器用户通过目标页面浏览端向信令服务器发送浏览器用户的加入信令。
161.图8实施例中的加入信令可以携带该浏览器用户的用户信息，例如用户id(可以是用户名、身份证号、手机号等能够唯一标识该浏览器用户的任意信息)、用户登录票据以及roomid等。
162.信令服务器接收到该加入信令之后，触发对该浏览器用户的合法性验证，若验证通过，则在信令服务器中生成一个用户代理用于保存该浏览器用户的相关信息，例如这里首先保存上述浏览器用户的用户信息。若验证不通过，则信令服务器可以向浏览器用户对应的目标页面浏览端返回一个拒绝加入通知消息。
163.用户代理本质上是一个类对象，是浏览器用户通过浏览器在信令服务器创建了一个标识自己的对象，后续浏览器用户通过浏览器的操作都表现为操作该对象向流媒体服务器例如选择的mediasoup发出相应的命令。
164.在步骤s12中，信令服务器向流媒体服务器发送创建媒体传输通道和代理传输通道的信令(这里为第一传输通道创建消息)。
165.步骤s12中，当用户代理成功创建后，信令服务器通过该用户代理向nats传递第一传输通道创建消息，nats将该第一传输通道创建消息再传递至mediasoup nodejs，mediasoup nodejs向mediasoup worker发送该第一传输通道创建消息。
166.在步骤s13中，流媒体服务器向游戏语音后台服务器发送语音后台进房信令。
167.mediasoup worker接收到该第一传输通道创建消息之后，mediasoup向游戏语音后台服务器发送语音后台进房请求信令(joinroom信令)。
168.在步骤s14中，游戏语音后台服务器向流媒体服务器返回进房成功通知消息。
169.游戏语音后台服务器接收到该joinroom信令之后，对其进行鉴权，若鉴权通过，则向mediasoup返回进房成功通知消息，若鉴权未通过，则向mediasoup返回拒绝进房通知消息。该进房成功通知消息中可携带sdp信息。
170.当mediasoup接收到进房成功通知消息之后，响应上述第一传输通道创建消息，在mediasoup worker中创建用于发布流的媒体传输通道和用于订阅流的代理传输通道，并生成用于发布流的媒体传输通道的id和用于订阅流的代理传输通道的id。
171.在步骤s15中，流媒体服务器向信令服务器返回创建成功通知消息。
172.当mediasoup worker中成功创建用于发布流的媒体传输通道和用于订阅流的代理传输通道之后，mediasoup worker通过mediasoup nodejs和nats向信令服务器返回创建成功通知消息，该创建成功通知消息中可携带用于发布流的媒体传输通道的id和用于订阅流的代理传输通道的id、以及上述sdp信息。
173.在步骤s16中，信令服务器向浏览器用户返回sdp信息与传输通道的id。
174.信令服务器接收到该创建成功通知消息后，可以向浏览器用户对应的目标页面浏览端返回用于发布流的媒体传输通道的id和用于订阅流的代理传输通道的id、以及上述sdp信息。目标页面浏览端可以将用于发布流的媒体传输通道的id和用于订阅流的代理传
输通道的id通过websdk传递至信令服务器中的用户代理，使得该用户代理同时也包含了用于发布流的媒体传输通道的id和用于订阅流的代理传输通道的id。
175.在步骤s17中，流媒体服务器向游戏语音后台服务器发送语音握手消息。
176.例如，mediasoup向游戏语音后台服务器发送语音hello消息。
177.在步骤s18中，游戏语音后台服务器向流媒体服务器返回握手成功消息。
178.例如，若游戏语音后台服务器向mediasoup返回hello成功消息，则表示mediasoup和游戏语音后台服务器握手成功。
179.在步骤s19中，浏览器用户向信令服务器发送发布流信令。
180.例如，浏览器用户通过目标页面浏览端向信令服务器发送publish信令。publish信令是为了通知mediasoup创建一个producer，即第一生产者角色。
181.在步骤s110中，信令服务器向流媒体服务器发送创建生产者角色的信令(这里为第一生产者角色创建请求消息)。
182.信令服务器接收到publish信令后，通过用户代理向nats发送第一生产者角色创建请求消息，nats再将该第一生产者角色创建请求消息发送至mediasoup nodejs，mediasoup nodejs再将该第一生产者角色创建请求消息透传至mediasoup worker中的用于发布流的媒体传输通道，用于发布流的媒体传输通道接收到该第一生产者角色创建请求消息之后，创建第一生产者角色，并保存第一生产者角色标识。
183.在步骤s111中，流媒体服务器向信令服务器返回创建成功消息。
184.当mediasoup中成功创建第一生产者角色后，mediasoup worker通过mediasoup nodejs和nats向信令服务器返回创建成功消息。
185.用于发布流的媒体传输通道(webrtctransportpub)向用于订阅流的代理传输通道(audiotransportsub)发送第一消费者角色创建请求消息，用于订阅流的代理传输通道接收并响应第一消费者角色创建请求消息，在用于订阅流的代理传输通道上生成第一消费者角色，并保存第一消费者角色标识，使得第一消费者角色订阅第一生产者角色标识(producerid)，形成第一消费者角色和第一生产者角色之间的发布订阅关系。这样web浏览器端的待发布媒体数据就可以传导到audiotransportsub。
186.在步骤s112中，信令服务器向浏览器用户返回发布成功消息。
187.当信令服务器接收到步骤s111中的创建成功消息之后，向浏览器用户对应的目标页面浏览端返回发布成功消息。
188.在步骤s113中，浏览器用户向信令服务器发送dtls信令。
189.dtls信令用于将web浏览器端的用于数据加密的加密算法和密钥告知对方。sdp有部分字段是需要填充数据的加密算法和密钥。
190.在步骤s114中，信令服务器向流媒体服务器发送设置dtls参数的消息。
191.信令服务器接收到dtls信令之后，控制用户代理并依次通过nats和mediasoup nodejs向mediasoup worker发送设置dtls参数的消息。
192.在步骤s115中，流媒体服务器向信令服务器返回设置成功消息。
193.mediasoup worker接收到设置dtls参数的消息之后，设置dtls参数，在设置成功之后，通过mediasoup nodejs和nats向信令服务器返回设置成功消息。
194.在步骤s116中，信令服务器向浏览器用户返回设置成功消息。
195.信令服务器接收到步骤s115返回的设置成功消息之后，向浏览器用户对应的目标页面浏览端返回设置成功消息。
196.在步骤s117中，浏览器用户向流媒体服务器发送ice创建会话的信令。
197.目标页面浏览端接收到步骤s116返回的设置成功消息之后，向mediasoup发送ice创建会话的信令。
198.在步骤s118中，流媒体服务器向浏览器用户返回媒体传输通道建立的消息。
199.mediasoup接收到ice创建会话的信令之后，建立浏览器和mediasoup之间媒体数据的传输通道作为媒体传输通道，建立成功后，向目标页面浏览端返回媒体传输通道建立的消息。
200.在步骤s119中，浏览器用户向流媒体服务器发送上行媒体数据流。
201.目标页面浏览端接收到媒体传输通道建立的消息之后，就可以向mediasoup发送上行媒体数据流(即待发布媒体数据)。
202.在步骤s120中，流媒体服务器通过代理传输通道向游戏语音后台服务器传输该上行媒体数据流。
203.mediasoup中的用于发布流的媒体传输通道接收到该上行媒体数据流(这里以上行语音流为例进行举例说明)，基于上述第一生产者角色和第一消费者角色的发布订阅关系，将其转发至用于订阅流的代理传输通道，用于订阅流的代理传输通道对其解析，重新打包成基于私有语音协议的上行语音流之后再转发至游戏语音后台服务器。
204.本公开实施例中，audiotransportsub内部有一个成员叫audioserver的对象(媒体服务对象)，它负责将基于webrtc的待发布媒体数据从rtp包中解包出媒体载荷，并且按照私有语音协议重新打包成基于私有语言协议的待发布媒体数据。
205.这里audioserver对象与游戏语音后台服务器之间维持着一个udp数据通道，并且有心跳协议保活，这个通道是双工的，利用它可以向游戏语音后台服务器发送web浏览器端的语音数据，也可以接收来自游戏语音后台服务器的语音数据，将它解包出语音载荷，然后再封装成rtp数据包。
206.上行语音的传输如上图8所示，当浏览器用户需要发布流的时候，首先需要通过加入信令加入到流媒体服务中，这个过程中信令服务器的用户代理以及mediasoup中的用于发布流的媒体传输通道和用于订阅流的代理传输通道创建好了。之后通过publish和dtls信令，交换了webrtc用于创建会话的sdp信息，代理数据通道负责解析webrtc传输的rtp数据流并且将其转换成私有语音协议的上行语音流，转发给游戏语音后台服务器，游戏语音后台服务器可以将其发送至其它端的语音用户。
207.图9示意性示出了根据本公开的一实施例的下行媒体数据流的传输时序图。图9实施例中以下行媒体数据流为下行语音流为例进行举例说明。
208.如图9所示，在步骤s21中，浏览器用户向信令服务器发送用户加入信令。
209.步骤s21可以参考上述步骤s11。
210.在步骤s22中，信令服务器向流媒体服务器发送创建媒体传输通道和代理传输通道的信令(这里为第二传输通道创建消息)。
211.步骤s22中，当用户代理成功创建后，信令服务器通过该用户代理向nats传递第二传输通道创建消息，nats将该第二传输通道创建消息再传递至mediasoup nodejs，
mediasoup nodejs向mediasoup worker发送该第二传输通道创建消息。
212.在步骤s23中，流媒体服务器向游戏语音后台服务发送语音后台进房请求信令。
213.mediasoup worker接收到该第二传输通道创建消息之后，mediasoup向游戏语音后台服务器发送语音后台进房请求信令(joinroom信令)。
214.在步骤s24中，游戏语音后台服务向流媒体服务器返回进房成功通知消息。
215.游戏语音后台服务器接收到该joinroom信令之后，对其进行鉴权，若鉴权通过，则向mediasoup返回进房成功通知消息，若鉴权未通过，则向mediasoup返回拒绝进房通知消息。该进房成功通知消息中可携带sdp信息。
216.当mediasoup接收到进房成功通知消息之后，响应上述第二传输通道创建消息，在mediasoup worker中创建用于发布流的代理传输通道和用于订阅流的媒体传输通道，并生成用于发布流的代理传输通道的id和用于订阅流的媒体传输通道的id。
217.在步骤s25中，流媒体服务器向信令服务器返回创建成功通知消息。
218.当mediasoup worker中成功创建用于发布流的代理传输通道和用于订阅流的媒体传输通道之后，mediasoup worker通过mediasoup nodejs和nats向信令服务器返回创建成功通知消息，该创建成功通知消息中可携带用于发布流的代理传输通道的id和用于订阅流的媒体传输通道的id、以及上述sdp信息。
219.在步骤s26中，信令服务器向浏览器用户返回sdp信息与传输通道的id。
220.信令服务器接收到该创建成功通知消息后，可以向浏览器用户对应的目标页面浏览端返回用于发布流的代理传输通道的id和用于订阅流的媒体传输通道的id、以及上述sdp信息。目标页面浏览端可以将用于发布流的代理传输通道的id和用于订阅流的媒体传输通道的id通过websdk传递至信令服务器中的用户代理，使得该用户代理同时也包含了用于发布流的代理传输通道的id和用于订阅流的媒体传输通道的id。
221.在步骤s27中，流媒体服务器向游戏语音后台服务器发送语音握手消息。
222.在步骤s28中，游戏语音后台服务器向流媒体服务器返回握手成功消息。
223.步骤s27
‑
s28可以参考上述步骤s17
‑
s18。
224.在步骤s29中，浏览器用户向信令服务器发送通知新用户发布流消息(addnewusertrack信令)。
225.通知新用户发布流消息中的新用户可以是指其它端的语音用户，有新用户上麦，可能发出语音数据，这里需要提前把传输通道建立好。
226.在步骤s210中，信令服务器向流媒体服务器发送代理创建发布流的消息。
227.信令服务器接收到通知新用户发布流消息之后，信令服务器中的用户代理通过nats、mediasoup nodejs向mediasoup worker发送代理创建发布流的消息，通知mediasoup worker中的用于发布流的代理传输通道创建发布流。用于发布流的代理传输通道响应该代理创建发布流的消息，在该用于发布流的代理传输通道上生成第二生产者角色，并保存第二生产者角色标识，并获得发送者id，这里的发送者id即新用户标识，用于标识发布待订阅媒体数据的新用户。
228.在步骤s211中，流媒体服务器向信令服务器返回创建成功通知消息。
229.成功创建第二生产者角色之后，mediasoup通过nats向信令服务器返回创建成功通知消息，该创建成功通知消息携带发送者id和第二生产者角色标识。
230.在步骤s212中，信令服务器向浏览器用户对应的目标页面浏览端返回发送者id。
231.在步骤s213中，浏览器用户向信令服务器发送订阅流信令。
232.该subscribe信令用于通知mediasoup创建一个消费者角色即第二消费者角色。
233.在步骤s214中，信令服务器向流媒体服务器发送创建消费者角色的消息，这里即第二消费者角色创建请求消息。
234.信令服务器接收到subscribe信令之后，通过nats向mediasoup发送第二消费者角色创建请求消息，用于订阅流的媒体传输通道响应第二消费者角色创建请求消息，在用于订阅流的媒体传输通道上生成第二消费者角色，并保存第二消费者角色的第二消费者角色标识，使得第二消费者角色订阅上述第二生产者角色标识，形成第二消费者角色和第二生产者角色之间的发布订阅关系。
235.在mediasoup内部建立producer和consumer的对应关系，接收到的上行语音流和下行语音流才可以通过producer转发到对应的consumer。而创建发布流的过程就是创建一个producer。producer对应的是生产流的一个对象，它的流是基于transport传输的。consumer对应的是消费流的一个对象，它的流也是基于transport传输的。
236.当web端上的浏览器用户需要听到别的用户的声音时，首先会发送一个addnewusertrack信令，通知用户代理操作audiotransportpub(用于发布流的代理传输通道)生成一个producer(第二生产者角色)，然后操作webrtctransportsub(用于订阅流的媒体传输通道)生成一个consumer(第二消费者角色)，然后consumer订阅该producer，形成一个发布订阅关系。其中，一个rtcpeerconnection可以承载多个track(媒体流)，因此当麦上有了新用户的时候就重新发布一个addnewusertrack信令。
237.在步骤s215中，流媒体服务器向信令服务器返回创建成功消息。
238.在步骤s216中，信令服务器向浏览器用户返回成功消息。
239.在步骤s217中，浏览器用户向信令服务器发送dtls信令。
240.在步骤s218中，信令服务器向流媒体服务器发送设置dtls参数的消息。
241.在步骤s219中，流媒体服务器向信令服务器返回设置成功消息。
242.在步骤s220中，信令服务器向浏览器用户返回设置成功消息。
243.在步骤s221中，浏览器用户向流媒体服务器发送ice创建会话的信令。
244.在步骤s222中，流媒体服务器向浏览器用户返回媒体传输通道建立的消息。
245.步骤s215
‑
s222可以参考上述步骤s111
‑
s118。
246.图8和图9实施例中，上行和下行对应于两个transport，具体到web浏览器端就是两个rtcpeerconnection，是两个独立的连接。因为这里的传输通道是单工的，所以需要重复传输通道建立的过程。
247.在步骤s223中，流媒体服务器通过代理传输通道从游戏语音后台服务器接收下行语音流(待订阅媒体数据)。
248.mediasoup利用上述用于发布流的代理传输通道从游戏语音后台服务器接收下行语音流，并对其进行解析重新打包成基于webrtc传输协议栈的下行语音流，然后发送至用于订阅流的媒体传输通道。
249.在步骤s224中，流媒体服务器向浏览器用户发送下行媒体数据流。
250.下行语音的传输过程如上图9所示，与图8相比，增加一个通知代理创建发布流的
信令，在发布流之后，浏览器用户再主动订阅该发布流，建立完整的发布
‑
订阅数据通路。之后代理传输通道接收到基于私有语音协议的下行语音流之后，将其解包并且重新包装成rtp数据流，然后转发给浏览器用户。
251.本公开实施例中，audiotransport的audioserver成员实现了rtp包和私有语音包解包和封包的逻辑。audioserver中udp数据通道是双工的，它收到媒体数据后，需要到router中找到audiotransportpub这个用于发布流的代理传输通道，然后把媒体数据传递给audiotransportpub，假装audiotransportpub收到了网络数据，而实际上audiotransportpub的数据并非直接来自网络，而是来audioserver的udp数据通道。利用audiotransportpub与webrtctransportsub之间的发布订阅关系，数据最终传导到浏览器用户的浏览器端。
252.本公开实施方式提供的媒体数据处理方法，继承了开源的流媒体服务器mediasoup稳定且易扩展的优势，并在其上进行了二次开发，在其上通过用户代理创建代理传输通道，使得web浏览器产生的音视频数据可以通过此代理传输通道注入到采用私有音视频协议的客户端对应的后台服务器，同时web端也可以通过此代理传输通道接收采用私有音视频协议的客户端的媒体数据，解决了webrtc通信与私有音视频协议之间的数据交换问题，使得私有音视频通信系统可以实现与web端的互联互通。
253.图10示意性示出了根据本公开的一实施例的媒体数据处理装置的框图。如图10所示，本公开实施例提供的媒体数据处理装置1000可以设置于流媒体服务器，流媒体服务器可以包括媒体传输通道和代理传输通道。媒体数据处理装置1000可以包括待发布媒体数据接收单元1010、待发布媒体数据转发单元1020、待发布媒体数据转换单元1030以及待发布媒体数据发送单元1040。
254.本公开实施例中，待发布媒体数据接收单元1010可以用于通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据。待发布媒体数据转发单元1020可以用于通过媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道。待发布媒体数据转换单元1030可以用于利用代理传输通道将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据。待发布媒体数据发送单元1040可以用于通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
255.在示例性实施例中，媒体传输通道可以包括用于发布流的媒体传输通道，代理传输通道可以包括用于订阅流的代理传输通道。其中，媒体数据处理装置1000还可以包括：第一生产者角色创建请求消息接收单元，可以用于在通过媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据之前，通过用于发布流的媒体传输通道接收目标页面浏览端发起的第一生产者角色创建请求消息；第一生产者角色生成单元，可以用于发布流的媒体传输通道响应第一生产者角色创建请求消息，在用于发布流的媒体传输通道上生成第一生产者角色，并保存第一生产者角色的第一生产者角色标识；第一消费者角色创建请求消息发送单元，可以用于通过用于发布流的媒体传输通道向用于订阅流的代理传输通道发送第一消费者角色创建请求消息；第一消费者角色生成单元，可以用于通过用于订阅流的代理传输通道接收并响应第一消费者角色创建请求消息，在用于订阅流的代理传输通道上生成第一消费者角色；第一发布订阅关系形成单元，可以用于订阅流的代理
传输通道使得第一消费者角色订阅第一生产者角色标识，形成第一消费者角色和第一生产者角色之间的发布订阅关系。
256.在示例性实施例中，媒体数据处理装置1000还可以包括：第一传输通道创建请求消息接收单元，可以用于在通过用于发布流的媒体传输通道接收目标页面浏览端发起的第一生产者角色创建请求消息之前，通过流媒体服务器中的媒体流处理进程接收目标页面浏览端发起的第一传输通道创建请求消息；第一传输通道创建单元，可以用于媒体流处理进程响应第一传输通道创建请求消息，在媒体流处理进程中创建用于发布流的媒体传输通道和用于订阅流的代理传输通道；第一传输通道标识返回单元，可以用于媒体流处理进程生成用于发布流的媒体传输通道的标识和用于订阅流的代理传输通道的标识，并将用于发布流的媒体传输通道的标识和用于订阅流的代理传输通道的标识返回至目标页面浏览端。
257.在示例性实施例中，流媒体服务器还可以包括脚本语言运行环境，脚本语言运行环境可以用于从分布式消息队列接收第一生产者角色创建请求消息，并通过进程间通信将第一生产者角色创建请求消息发送至用于发布流的媒体传输通道。
258.其中，分布式消息队列可以用于从信令服务器中的用户代理接收第一生产者角色创建请求消息，其中用户代理包含目标页面浏览端上目标网页的用户信息、用于发布流的媒体传输通道的标识和用于订阅流的代理传输通道的标识。
259.用户代理可以用于响应目标页面浏览端发送的发布流信令生成第一生产者角色创建请求消息，并将第一生产者角色创建请求消息发送至分布式消息队列。
260.在示例性实施例中，信令服务器可以用于响应目标页面浏览端发送的加入信令，在信令服务器中创建用户代理，并控制用户代理向分布式消息队列发送第一传输通道创建请求消息。
261.分布式消息队列还可以用于将第一传输通道创建请求消息发送至脚本语言运行环境。
262.脚本语言运行环境还可以用于将第一传输通道创建请求消息发送至媒体流处理进程。
263.在示例性实施例中，待发布媒体数据接收单元1010可以包括：发布流媒体传输通道接收单元，可以用于通过用于发布流的媒体传输通道，从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据。
264.其中，待发布媒体数据转发单元1020可以包括：发布流媒体传输通道转发单元，可以用于基于第一消费者角色和第一生产者角色之间的发布订阅关系，通过用于发布流的媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至用于订阅流的代理传输通道。
265.其中，待发布媒体数据转换单元1030可以包括：订阅流代理传输通道解析单元，可以用于利用用于订阅流的代理传输通道解析采用网页通信媒体协议封装的待发布媒体数据；待发布媒体数据协议转换单元，可以用于订阅流的代理传输通道将解析获得的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据。
266.其中，待发布媒体数据发送单元1040可以包括待发布媒体数据代理发送单元，可以用于通过用于订阅流的代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
267.在示例性实施例中，用于订阅流的代理传输通道内可以包括媒体服务对象，媒体服务对象与媒体服务器之间维持用户数据报协议数据通道。其中，待发布媒体数据转换单元1030可以包括：媒体服务对象解析单元，可以用于利用媒体服务对象解析采用网页通信媒体协议封装的待发布媒体数据，将采用网页通信媒体协议封装的待发布媒体数据转换为采用客户端媒体协议封装的待发布媒体数据。
268.其中，待发布媒体数据发送单元1040可以包括：用户数据报协议数据通道传输单元，可以用于利用用户数据报协议数据通道，将采用客户端媒体协议封装的待发布媒体数据，发送至媒体服务器，以便媒体服务器将采用客户端媒体协议封装的待发布媒体数据传输至目标客户端。
269.在示例性实施例中，媒体数据处理装置1000还可以包括：待订阅媒体数据接收单元，可以用于通过代理传输通道从目标客户端接收采用客户端媒体协议封装的待订阅媒体数据；待订阅媒体数据解析单元，可以用于通过代理传输通道将采用客户端媒体协议封装的待订阅媒体数据转换为采用网页通信媒体协议封装的待订阅媒体数据；待订阅媒体数据发送单元，可以用于通过代理传输通道将采用网页通信媒体协议封装的待订阅媒体数据，发送至媒体传输通道；待订阅媒体数据转发单元，可以用于通过媒体传输通道将采用网页通信媒体协议封装的待订阅媒体数据发送至目标页面浏览端。
270.在示例性实施例中，媒体传输通道可以包括用于订阅流的媒体传输通道，代理传输通道可以包括用于发布流的代理传输通道。其中，媒体数据处理装置1000还可以包括：通知新用户发布流消息接收单元，可以用于在通过代理传输通道从目标客户端接收采用客户端媒体协议封装的待订阅媒体数据之前，通过用于发布流的代理传输通道接收目标页面浏览端发起的通知新用户发布流消息；第二生产者角色生成单元，可以用于发布流的代理传输通道响应通知新用户发布流消息，在用于发布流的代理传输通道上生成第二生产者角色，并保存第二生产者角色的第二生产者角色标识；第二消费者角色创建请求消息发送单元，可以用于通过用于发布流的代理传输通道向用于订阅流的媒体传输通道发送第二消费者角色创建请求消息；第二消费者角色生成单元，可以用于通过用于订阅流的媒体传输通道接收并响应第二消费者角色创建请求消息，在用于订阅流的媒体传输通道上生成第二消费者角色，并保存第二消费者角色的第二消费者角色标识；第二发布订阅关系形成单元，可以用于通过用于订阅流的媒体传输通道使得第二消费者角色订阅第二生产者角色标识，形成第二消费者角色和第二生产者角色之间的发布订阅关系。
271.在示例性实施例中，待订阅媒体数据接收单元可以包括：发布流代理传输通道接收单元，可以用于通过用于发布流的代理传输通道，从媒体服务器接收采用客户端媒体协议封装的待订阅媒体数据，其中采用客户端媒体协议封装的待订阅媒体数据是媒体服务器从目标客户端接收的。
272.其中，待订阅媒体数据解析单元可以包括：发布流代理传输通道解析单元，可以用于利用用于发布流的代理传输通道解析采用客户端媒体协议封装的待订阅媒体数据；发布流代理传输通道转换单元，可以用于发布流的代理传输通道将解析获得的待订阅媒体数据，转换为采用网页通信媒体协议封装的待订阅媒体数据。
273.其中，待订阅媒体数据发送单元可以包括：发布流代理传输通道发送单元，可以用于基于第二消费者角色和第二生产者角色之间的发布订阅关系，通过用于发布流的代理传
specific integrated circuit)，或者是被配置成实施本公开实施例的一个或多个集成电路。
288.存储器1103可以包含高速ram(random access memory，随机存取存储器)存储器，也可以还包括非易失性存储器(non
‑
volatile memory)，例如至少一个磁盘存储器。
289.其中，程序可具体用于：通过流媒体服务器中的媒体传输通道从目标页面浏览端接收采用网页通信媒体协议封装的待发布媒体数据；通过媒体传输通道将采用网页通信媒体协议封装的待发布媒体数据，发送至代理传输通道；利用流媒体服务器中的代理传输通道将采用网页通信媒体协议封装的待发布媒体数据，转换为采用客户端媒体协议封装的待发布媒体数据；通过代理传输通道将采用客户端媒体协议封装的待发布媒体数据，发送至目标客户端。
290.根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例的各种可选实现方式中提供的方法。
291.需要理解的是，在本公开附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
292.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
293.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。