CN112073727B - 转码方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例公开了一种转码方法、装置、电子设备以及存储介质。所述方法包括：转码服务节点响应于转码指令，获取主播端的RTC媒体流；将所述RTC媒体流进行转码操作生成RTMP媒体流；将所述RTMP媒体流推送给观众端。通过上述方法，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求。

Description

转码方法、装置、电子设备及存储介质

技术领域

本申请涉及直播技术领域，更具体地，涉及一种转码方法、装置、电子设备以及存储介质。

背景技术

随着移动互联网的发展，网络直播、在线教育等直播类应用得到迅猛发展。相关的直播技术方案大多是基于传统的RTMP(Real Time Messaging Protocol，实时消息传输协议)方式实现。相关的基于RTMP方式实现的直播技术方案，可支撑起海量给观众的观看需求，但是很难解决技术方案本身所带来的的高时延问题。

发明内容

鉴于上述问题，本申请实施例提出了一种转码方法、装置、电子设备以及存储介质，以改善上述问题。

第一方面，本申请实施例提供了一种转码方法，所述方法包括：转码服务节点响应于转码指令，获取主播端的RTC媒体流；将所述RTC媒体流进行转码操作生成RTMP媒体流；将所述RTMP媒体流推送给观众端。

第二方面，本申请实施例提供了一种转码装置，所述装置包括：RTC媒体流获取单元，用于转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流；转码单元，用于将所述RTC媒体流进行转码操作生成RTMP媒体流；媒体流推送单元，用于将所述RTMP媒体流推送给用户客户端。

第三方面，本申请实施例提供了一种电子设备，包括一个或多个处理器以及存储器；一个或多个程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行以实现上述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有程序代码，其中，在所述程序代码被处理器运行时执行上述的方法。

本申请实施例提供的一种转码方法、装置、电子设备以及存储介质，转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流，然后将RTC媒体流进行转码操作生成RTMP媒体流，将RTMP媒体流推送给用户客户端。通过上述方法，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请一实施例提出的一种转码方法的应用场景示意图；

图2示出了本申请一实施例提出的一种转码方法中的插件管理服务节点的应用场景示意图；

图3示出了本申请一实施例提出的一种转码方法的流程图；

图4示出了本申请另一实施例提出的一种转码方法的流程图；

图5示出了本申请又一实施例中提出的一种转码方法的流程图；

图6示出了本申请再一实施例提出的一种转码方法的流程图；

图7示出了本申请一实施例提出的一种转码装置的结构图；

图8示出了本申请再一实施例中提出的一种转码装置的结构图；

图9示出了本申请一实施例提出的一种转码装置的结构框图；

图10示出了本申请再一实施例提出的一种转码装置的结构框图；

图11示出了本申请实时中的用于执行根据本申请实施例的转码方法的电子设备的结构框图；

图12示出了本申请实时中的用于保存或者携带实现根据本申请实施例的转码方法的程序代码的存储单元。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

随着视频技术的发展，视频直播等领域逐渐活跃起来，RTMP作为业内广泛使用的协议也重新被相关开发者重视起来，RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。RTMP协议规定，播放一个流媒体有两个前提步骤：第一步，建立一个网络连接(NetConnection)；第二步，建立一个网络流(NetStream)。其中，网络连接代表服务器端应用程序和客户端之间基础的连通关系。网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流。相关的直播技术方案大多是基于传统的RTMP的方式实现，只有一小部分直播技术方案是通过RTC方式实现。

而发明人在对相关的直播技术方案的研究中发现，相关的直播技术方式中，基于RTMP的实现方式的直播技术方案，可支撑起海量给观众的观看需求，但是很难解决技术方案本身所带来的的高时延问题。

因此，发明人提出了本申请实施例中的转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流，然后将RTC媒体流进行转码操作生成RTMP媒体流，将RTMP媒体流推送给用户客户端，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求的转码的方法、装置、电子设备以及存储介质。

下面将对本申请实施例所涉及的一种应用环境进行介绍。

如图1所示，在图1所示的应用环境中，包括有服务注册与发现节点、管理服务调度节点、转码服务节点、RTC媒体服务节点以及RTMP媒体服务节点。

其中，服务注册与发现节点具有服务注册与服务发现的功能，可以具体用于实时更新转码服务节点中各工作进程的工作状态。管理服务调度节点可以用于监听服务注册与发现节点及转码服务节点中各工作进程的健康状态的变动，根据实时监测的状态调度转码服务。

可选的，转码服务节点可以用于进行转码服务操作。为了充分利用转码服务节点的计算资源，提高单服务器节点的处理能力，在转码服务节点内部，可以采用单管理进程+多工作进程的方式进行转码服务。其中，工作进程的数量默认和CPU核数一致，减少了进程之间竞争CPU资源和进程切换的开销。其中，CPU核数指的是物理服务器搭载的CPU核数。并且，每一个工作进程可以包括RTC拉流模块、转码模块以及RTMP推流模块，具体的，所述RTC拉流模块可以用于从RTC媒体服务节点中获取RTC媒体流；所述转码模块可以用于执行转码操作，将RTC媒体流转换成RTMP媒体流；所述RTMP推流模块可以用于向观众端推送RTMP媒体流。

进一步的，针对转码服务需要较高的稳定性，为了满足转码服务较高的稳定性，在转码服务节点中还可以包括工作进程信息模块，所述工作进程信息模块可以用于记录转码服务节点中各工作进程的进程信息以及各工作进程内的任务信息。具体的，在进行信息记录时，可以将各工作进程的进程信息和各工作进程内的任务信息同时记录存储在进程内存空间内的工作表和持久化记录表两部分中。

可选的，在转码服务节点中还可以利用管理进程守护并管理各工作进程。当管理进程检测到有工作进程发生异常时，可以先从工作表中查找与发生异常的工作进程对应的信息来创建新的工作进程。可选的，在工作表中信息异常丢失时，可从持久化记录表中快速恢复创建新的工作进程，并恢复与该工作进程相关的转码任务，进而可做到工作进程异常退出后无差别的恢复相关转码任务。

可选的，所述转码服务节点内还可以包括监督进程。通过监督进程监督守护管理进程。具体的，针对集群部署的服务管理的需求，管理进程向服务注册与发现节点注册服务；管理服务调度节点监听服务注册与发现节点及各工作进程的健康状态的变动，根据实时监测的状态调度转码服务。

可选的，所述RTC媒体服务节点用于从主播端抓取RTC媒体流。所述RTMP媒体服务节点用于向观众端推送RTMP媒体流。

可选的，上述服务注册与发现节点、管理服务调度节点、转码服务节点、RTC媒体服务节点以及RTMP媒体服务节点等多个节点可以为同一个服务器中的不同节点，也可以各自为一个单独的服务器中的节点，或者各自为一个单独的服务器。进一步的，所述转码服务节点中的各进程也可以为单独的服务器中的进程，或者也可以为单独的服务器。

可选的，如图2所示，所述应用环境中还可以包括插件管理服务节点。在追求个性化和差异化的直播时代，可以通过插件管理服务节点为业务开发者定制个性化的媒体处理。具体的，业务开发者可按照约定的标准开发自己的插件并上传，编排媒体的处理管线；管理服务调度节点可以根据分配给开发者的账号信息从插件库中获取媒体处理管线模型，并下发到转码服务节点，进而转码服务节点可以根据媒体处理管线模型从插件管理服务节点中获取对应的插件，编排生成个性化的工作进程，进行媒体处理。其中，媒体的处理管线可以理解为多个插件；所述媒体处理管线模型中可以包括多个插件的各参数值以及多个插件之间的连接顺序等。其中，媒体处理管线模型可以被设置于转码服务节点中。

进一步的，所述工作进程中可以包括多个不同的模块，具体的，可以包括RTC拉流模块、Rtmp推流模块、HLS分发模块、插件A模块以及插件B模块。其中，所述HLS分发模块用于将插件分发给CDN(Content Delivery Network，内容分发网络)网络。

可选的，所述插件管理服务节点可以为与转码服务节点处于同一个服务器中的一个节点，也可以为一个单独的服务器中的一个节点或者一个单独的服务器。

下面将结合附图具体描述本申请的各实施例。

请参阅图3，本申请实施例提供的一种转码方法，所述方法包括：

S110：转码服务节点响应于转码指令，获取主播端的RTC媒体流。

其中，所述RTC媒体流可以包括主播端的媒体流以及主播与观众进行互动的媒体流，其中，所述互动可以理解为与主播端进行连麦操作，并且，所述主播端的媒体流可以理解为主播端单方的直播媒体流，所述主播端与观众进行互动的媒体流可以理解为主播端与观众端进行连麦操作时，双方进行交互的媒体流。

作为一种方式，转码服务节点响应于管理服务调度节点发送的转码指令，从RTC服务器获取主播端的RTC媒体流。具体的，所述转码指令可以为管理服务调度节点根据监测到的转码服务节点内执行转码服务的各工作进程的工作状态发送的指令。其中，所述转码指令中可以携带有转码服务节点内的工作进程的标识，根据所述标识可以确定唯一的工作进程。

可选的，所述转码指令可以为管理服务调度节点根据指定时间周期发送的转码指令，其中，所述指定时间周期可以根据主播端的直播时间进行设置。示例性的，如果主播的直播时间为每天的下午3点，那么可以将指定时间周期设置为每天下午3点，进而管理服务调度节点可以在每天下午3点时向转码服务节点发送转码指令。

S120：将所述RTC媒体流进行转码操作生成RTMP媒体流。

作为一种方式，转码服务节点接收到管理服务调度节点发送的转码指令时，可以根据转码指令中携带的标识去调度与所述标识对应的工作节点来将RTC媒体流进行转码操作生成RTMP媒体流。

其中，可以通过转码服务节点中的与标识对应的工作进程中的转码模块将RTC媒体流转换成RTMP媒体流。

S130：将所述RTMP媒体流推送给观众端。

作为一种方式，转码服务节点可以在接收到转终端发送的媒体流获取请求时，将RTMP媒体流推送给观众端。

具体的，在转码模块完成转码操作时，工作进程可以向管理进程发送一个确认信息，当管理进程接收到工作进程发送的确认信息时，可以确定转码操作已经完成。当管理进程检测到转码服务节点内与标识对应的工作进程中的转码模块的转码操作完成时，可以向观众端发送一个通知信息，当观众端接收到该通知信息时，可以向转码服务节点发送媒体流获取请求，进而，转码服务节点在接收到转终端发送的媒体流获取请求时，可以将RTMP媒体流推送给观众端。

可选的，RTMP协议传输是通过握手的方式建立通道，然后传输RTMP媒体流。进一步的，RTMP协议传输时会对数据做自己的格式化，这种格式的消息称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message拆分为带有Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据Chunk中包含的data的长度，Message ID和Message的长度把Chunk还原成完整的Message，从而实现信息的收发。其中，发送端在发送Chunk时，必须在一个Chunk发送完成之后才能开始发送下一个Chunk。

进一步的，通过拆分，数据量较大的Message可以被拆分成较小的“Message”，这样就可以避免优先级低的消息持续发送阻塞优先级高的数据，比如在视频流数据的传输过程中，可以包括视频帧，音频帧和RTMP控制信息，如果持续发送音频数据或者控制数据的话可能就会造成视频帧的阻塞，然后就会造成卡顿现象。同时对于数据量较小的Message，可以通过对Chunk Header的字段来压缩信息，从而减少信息的传输量，其中，所述Chunk Header为Chunk数据包的包头。

本实施例提供的一种转码方法，转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流，然后将RTC媒体流进行转码操作生成RTMP媒体流，将RTMP媒体流推送给用户客户端。通过上述方法，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求。

请参阅图4，本申请实施例提供的一种转码方法，所述方法包括：

S210：转码服务节点响应于转码指令，获取主播端的RTC媒体流。

S210所包括的步骤的详细解释可以参照前述实施例中的对应步骤，这里不再赘述。

S220：从所述RTC媒体流中获取RTP媒体包。

作为一种方式，RTC底层的媒体数据传输采用的是RTP(Real-time TransportProtocol，实时传输协议)协议，RTP协议会根据RTP协议的标准将媒体数据进行打包。进而，转码服务节点内的工作进程中的RTC拉流模块可以根据RTP协议定义的标准从RTC媒体流中提取RTP媒体包。

其中，RTP协议具体用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。

可选的，转码服务节点可以通过工作进程中的RTC拉流模块从RTC媒体流中获取RTP媒体包。

S230：解析所述RTP媒体包，获取媒体数据和RTP报头。

作为一种方式，所述媒体数据包括音频数据和视频数据。所述解析RTP媒体包可以通过工作进程中的转码模块对RTP媒体包进行解析。

具体的，可以将RTP媒体包解析为RTP协议中规定的特定格式的媒体数据，进而可以从特定格式的媒体数据中获取RTP媒体头以及音视频媒体数据。

S240：根据所述媒体数据和RTP报头构建RTMP媒体流。

作为一种方式，所述RTMP媒体流可以理解为RTMP Message。转码服务节点可以根据RTMP协议的标准将媒体数据和RTP报头构建生成RTMP Message，并将RTMP Message拆分成多个chunk数据包。

具体的，在将媒体数据和RTP报头构建生成RTMP Message时，可以按照RTMP协议的标准中指定的连接方式将媒体数据和RTP报头进行连接。

S250：将所述RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。

作为一种方式，观众端可以包括参与互动的观众端以及未参与互动的观众端。具体的，可以通过工作进程中的RTMP推流模块将RTMP媒体流推送给未参与互动的观众端。

进一步的，在将RTMP媒体流推送给目标观众端时，可以通过RTMP协议将音视频数据流推送到内容分发网络服务器，即转码后的音视频流可以通过RTMP协议推送到CDN上。进而目标观众端可以通过CDN拉流地址播放直播流。其中，播放一个RTMP协议的流媒体需要经过以下几个步骤：握手，建立连接，建立流以及播放。RTMP连接都是以握手作为开始的；建立连接阶段用于建立客户端与服务器之间的“网络连接”；建立流阶段用于建立客户端与服务器之间的“网络流”；播放阶段用于传输音视频数据。

可选的，对于参与互动的观众端，不需要将RTC媒体流转码成RTMP媒体流，可以直接将RTC媒体流直接推送给参与互动的观众端，进而可以保证流畅的互动效果。

本实施例提供的一种转码方法，首先转码服务节点响应于转码指令，获取主播端的RTC媒体流，然后从RTC媒体流中获取RTP媒体包，并解析该RTP媒体包，获取媒体数据和RTP报头，再根据媒体数据和RTP报头构建RTMP媒体流，并将RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。通过上述方法，只需要做RTP媒体包的解包以及RTMP的封包，无需做音视频的解码再编码，实现了视频编解码的零转码，不仅降低了对CPU资源的消耗，提升了转码服务器的处理能力，同时也大大降低了因转码带来的延时。进一步的，将RTC媒体流通过转码操作生成RTMP媒体流并推送给未参与互动的观众，可以满足低延时互动直播的高并发观看的需求。

请参阅图5，本申请实施例提供的一种转码方法，所述方法包括：

S310：转码服务节点响应于转码指令，获取主播端的RTC媒体流。

S320：从所述RTC媒体流中获取RTP媒体包。

S330：解析所述RTP媒体包，获取媒体数据和RTP报头。

S310、S320以及S330所包括的步骤的详细解释可以参照前述实施例中的对应步骤，这里不再赘述。

S340：获取预先设置的合流参数。

作为一种方式，所述预先设置的合流参数可以包括是否合流、RTC媒体服务器的接入参数、RTMP媒体服务器的推流参数以及所需合流的视频流该如何布局等参数。具体的，所述合流参数可以为开发者预先设置的。

S350：基于所述合流参数，确定所述媒体数据是否需要合流。

其中，所述合流可以理解为将多路视频流进行合流操作合成一路媒体流，以及将多路音频流进行合流操作合成一路媒体流的操作。

作为一种方式，可以根据合流参数中的是否合流参数来确定媒体数据是否需要进行合流操作。具体的，如果合流参数中的是否合流参数被设置为需要合流，则确定媒体数据需要进行合流操作；如果合流参数中的是否合流参数被设置为不需要合流，则确定媒体数据不需要进行合流操作。

S360：若需要合流，对所述媒体数据进行解码操作，得到解码后的媒体数据。

作为一种方式，在根据合流参数确定需要将音频流数据和视频流数据进行合流操作时，对上述音频流数据和视频流数据按照预设的解码规则进行解码操作，解码成H264裸数据，得到解码后的音视频数据。

作为另一种方式，在根据合流参数确定不需要将音频流数据和视频流数据进行合流操作时，通过优化RTP、RTMP的打包机制，在转码服务节点只做RTP的解包操作以及RTMP的封包操作，无需做音视频媒体数据的解码再编码，实现了音视频媒体数据编解码的零转码，不仅降低了对CPU资源的消耗，提升了转码服务节点的处理能力，同时也大大降低了因转码操作带来的延时。其中，所述优化RTP、RTMP的打包机制可以理解为没有对音视频媒体数据进行编码再解码的操作，只是根据RTP协议的标准从RTP包头中取出对媒体包的描述，从负载中取出音视频媒体数据的内容，然后再根据RTMP协议的标准，将媒体数据和RTP报头封装成RTMP包。其中，RTMP包中封装的音视频媒体数据流，其实和FLV(Flash Video)封装音频和视频数据的方式是相同的，所以，可以按照FLV封装H264和AAC的方式，即可生成可播放的音视频数据流。

S370：将所述解码后的媒体数据根据所述合流参数进行合流，对合流后的媒体数据进行编码操作。

作为一种方式，将解码后的音视频媒体数据根据合流参数进行合流，按照合流参数将音视频媒体数据按照预设的布局进行合流，其中，所述预设的布局可以包括音视频数据和本地音视频数据各自的显示位置，显示区域大小等。在将音视频媒体数据进行合流后，可以将合流后的音视频媒体数据按照预设的编码规则进行编码操作。其中，所述音视频数据可以是采集的摄像头视频和麦克风音频。进一步的，在将摄像头视频和麦克风音频分别进行合流操作后，可以对摄像头视频和麦克风音频分别进行H264编码和AAC编码。

S380：根据编码后的媒体数据和所述RTP报头构建RTMP媒体流。

S390：将所述RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。

S380以及S390所包括的步骤的详细解释可以参照前述实施例中的对应步骤，这里不再赘述。

本实施例提供的一种转码方法，首先转码服务节点响应于转码指令，获取主播端的RTC媒体流，然后从RTC媒体流中获取RTP媒体包，并解析该RTP媒体包，获取媒体数据和RTP报头，再获取预先设置的合流参数，基于合流参数，对媒体数据进行解码操作，得到解码后的媒体数据，再根据编码后的媒体数据和RTP报头构建RTMP媒体流，并将RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。通过上述方法，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求。

请参阅图6，本申请实施例提供的一种转码方法，所述方法包括：

S410：获取所述转码服务节点的工作状态。

作为一种方式，所述转码服务节点的工作状态可以包括上线状态或者下线状态。当转码服务节点上线时，转码服务节点会自动向服务注册与发现节点进行注册；当转码服务下线时，转码服务节点会自动向服务注册与发现节点进行反注册，告诉服务注册与发现节点自己要下线了。进而，服务注册与发现节点可以实时获取到转码服务节点的工作状态。

进一步的，转码服务节点上线后，服务注册与发现节点也会与转码服务节点维持心跳包，当服务注册与发现节点检测到心跳包消失时，服务注册与发现节点会认为转码服务节点已经下线，此时服务注册与发现节点也会进行状态更新。

S420：基于所述工作状态，更新管理服务调度节点的服务列表，其中，所述服务列表记录所述转码服务节点内各工作进程的状态信息。

作为一种方式，通过上述方法，当服务注册与发现节点获取到转码服务节点的工作状态后，服务注册与发现节点会进行状态更新，进而管理服务调度节点可以根据服务注册与发现节点更新的转码服务节点的工作状态来更新服务列表。

进一步的，管理服务调度节点可以监测服务注册与发现节点以及转码服务节点的变动，进而可以根据实时监测到的服务注册与发现节点以及转码服务节点的健康状态的变动去调度转码服务。可选的，在调度服务时，有三个调度原则：一是向健康的转码服务节点调度转码服务；二是根据RTC媒体服务器就近调度转码服务；三是向负载低的转码服务节点调度转码服务，其中，转码服务节点上线后，服务注册与发现节点会与转码服务节点维持心跳包，转码服务节点会在心跳包中带上自己的负载情况。

可选的，可以将转码服务节点内各工作进程的状态信息进行存储。作为一种方式，获取所述转码服务节点内各工作进程的进程信息和任务信息；将所述各工作进程的进程信息和任务信息存储在工作表以及持久化记录表中，其中，所述工作表位于内存中，所述持久化记录表位于硬盘中。

具体的，可以将转码服务节点内的各工作进程的进程信息和任务信息存储在内存中，供快速的读写，另外，也可以同时将码服务节点内的各工作进程的进程信息和任务信息存储在硬盘中，以便内存中的状态信息因一场情况丢失时，还可以从硬盘中恢复。通过“内存+硬盘”的方式实现了转码服务节点内各工作进程状态信息的两级维护。

S430：根据所述服务列表，触发转码指令。

作为一种方式，所述服务列表中可以存储有转码服务节点中的各工作进程与各工作进程相关的信息的对应关系，进而管理服务调度节点可以获取预先设置的合流参数，将所述合流参数以及所述服务列表发送给转码服务节点，转码服务节点进而可以根据合流参数各服务列表触发转码指令。

S440：转码服务节点响应于转码指令，获取主播端的RTC媒体流。

S440所包括的步骤的详细解释可以参照前述实施例中的对应步骤，这里不再赘述。

S450：将所述RTC媒体流进行转码操作生成RTMP媒体流。

作为一种方式，在转码服务节点进行转码操作时，可以检测所述转码服务节点内的各工作进程是否有异常；若检测到有工作进程发生异常，根据所述工作表以及持久化记录表中存储的信息重新创建工作进程，并在新创建的工作进程中恢复发生异常的工作进程的转码任务。

其中，若检测到有工作进程发生异常，检测所述工作表中存储的与所述发生异常的工作进程对应的进程信息和任务信息是否丢失；若丢失，则根据所述持久化记录表中存储的与发生异常的工作进程对应的进程信息和任务信息重新创建进程，并在新创建的工作进程中恢复所述发生异常的工作进程的转码任务。

具体的，可以通过转码服务节点中的管理进程来监测各工作进程是否异常退出，来确定转码服务节点内的各工作进程是否有异常。当管理进程监测到转码服务节点中有工作进程异常退出时，确定转码服务节点内的工作进程有异常；反之，则确定转码服务节点内的工作进程无异常。

进一步的，当管理节点监测到有工作进程异常退出时，可以根据工作进程信息模块中记录的信息重建工作进程，并恢复工作进程的相关任务，可做到工作进程异常退出后无差别的恢复相关转码任务。其中，在根据工作进程信息模块中的信息重建工作进程时，首先从内存中的工作表读取记录的发生异常的工作进程的信息来重建工作进程，如果内存中的工作表中记录的信息异常丢失时，再选择从硬盘中的持久化记录表中读取发生异常的工作进程的信息来重建工作进程。

S460：将所述RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。

S460所包括的步骤的详细解释可以参照前述实施例中的对应步骤，这里不再赘述。

本实施例提供的一种转码方法，获取转码服务节点的工作状态，根据转码服务节点的工作状态，更新管理服务调度节点的服务列表，其中，所述服务列表记录所述转码服务节点内各工作进程的状态信息，然后根据服务列表，触发转码指令，转码服务节点响应于转码指令，获取主播端的RTC媒体流，并将RTC媒体流进行转码操作生成RTMP媒体流，再将RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。通过上述方法，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求。

请参阅图7，本申请提供的一种转码装置500，所述装置500包括：

RTC媒体流获取单元510，用于转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流。

转码单元520，用于将所述RTC媒体流进行转码操作生成RTMP媒体流。

作为一种方式，所述转码单元520，具体用于从所述RTC媒体流中获取RTP媒体包；解析所述RTP媒体包，获取媒体数据和RTP报头；根据所述媒体数据和RTP报头构建RTMP媒体流。

进一步的，所述转码单元520，还具体用于获取预先设置的合流参数；基于所述合流参数，确定所述媒体数据是否需要合流；若不需要合流，执行所述根据所述媒体数据和RTP报头构建RTMP媒体流；若需要合流，对所述媒体数据进行解码操作，得到解码后的媒体数据；将所述解码后的媒体数据根据所述合流参数进行合流；对合流后的媒体数据进行编码操作。

媒体流推送单元530，用于将所述RTMP媒体流推送给用户客户端。

所述媒体流推送单元530，具体用于将所述RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端。

作为一种方式，如图8所示，所述装置500，还包括：

工作状态获取单元540，用于获取所述转码服务节点的工作状态。

列表更新单元550，用于基于所述工作状态，更新管理服务调度节点的服务列表，其中，所述服务列表记录所述转码服务节点内各工作进程的状态信息；根据所述服务列表，触发转码指令。

作为一种方式，如图9所示，所述装置500，还包括：

存储单元560，用于获取所述转码服务节点内各工作进程的进程信息和任务信息；将所述各工作进程的进程信息和任务信息存储在工作表以及持久化记录表中，其中，所述工作表位于内存中，所述持久化记录表位于硬盘中。

作为一种方式，如图10所示，所述装置500，还包括：

进程创建单元570，用于检测所述转码服务节点内的各工作进程是否有异常；若检测到有工作进程发生异常，根据所述工作表以及持久化记录表中存储的信息重新创建工作进程，并在新创建的工作进程中恢复发生异常的工作进程的转码任务。

具体的，所述进程创建单元570，用于若检测到有工作进程发生异常，检测所述工作表中存储的与所述发生异常的工作进程对应的进程信息和任务信息是否丢失；若丢失，则根据所述持久化记录表中存储的与发生异常的工作进程对应的进程信息和任务信息重新创建进程，并在新创建的工作进程中恢复所述发生异常的工作进程的转码任务。

需要说明的是，本申请中装置实施例与前述方法实施例是相互对应的，装置实施例中具体的原理可以参见前述方法实施例中的内容，此处不再赘述。

下面将结合图11对本申请提供的一种电子设备进行说明。

请参阅图11，基于上述的转码方法、装置，本申请实施例还提供的另一种可以执行前述转码方法的电子设备100。电子设备100包括相互耦合的一个或多个(图中仅示出一个)处理器102、存储器104以及网络模块106。其中，该存储器104中存储有可以执行前述实施例中内容的程序，而处理器102可以执行该存储器104中存储的程序。

其中，处理器102可以包括一个或者多个处理核。处理器102利用各种接口和线路连接整个电子设备100内的各个部分，通过运行或执行存储在存储器104内的指令、程序、代码集或指令集，以及调用存储在存储器104内的数据，执行电子设备100的各种功能和处理数据。可选地，处理器102可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(ProgrammableLogic Array，PLA)中的至少一种硬件形式来实现。处理器102可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器102中，单独通过一块通信芯片进行实现。

存储器104可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。存储器104可用于存储指令、程序、代码、代码集或指令集。存储器104可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储终端100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

所述网络模块106用于接收以及发送电磁波，实现电磁波与电信号的相互转换，从而与通讯网络或者其他设备进行通讯，例如和音频播放设备进行通讯。所述网络模块106可包括各种现有的用于执行这些功能的电路元件，例如，天线、射频收发器、数字信号处理器、加密/解密芯片、用户身份模块(SIM)卡、存储器等等。所述网络模块106可与各种网络如互联网、企业内部网、无线网络进行通讯或者通过无线网络与其他设备进行通讯。上述的无线网络可包括蜂窝式电话网、无线局域网或者城域网。例如，网络模块106可以与基站进行信息交互。

请参考图12，其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机可读介质800中存储有程序代码，所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。

计算机可读存储介质800可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。可选地，计算机可读存储介质800包括非易失性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质800具有执行上述方法中的任何方法步骤的程序代码810的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码810可以例如以适当形式进行压缩。

本实施例提供的一种转码方法、装置、电子设备以及存储介质，转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流，然后将RTC媒体流进行转码操作生成RTMP媒体流，将RTMP媒体流推送给用户客户端。通过上述方法，将获取的主播端的RTC媒体流通过转码操作生成RTMP媒体流，将低时延的RTC技术运用在主播端，在将媒体流推送给观众端时，将RTC媒体流进行转码操作生成RTMP媒体流，进而可以低成本的同时满足低延时互动直播的高并发观看的需求。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种转码方法，其特征在于，所述方法包括：

转码服务节点响应于转码指令，获取主播端的RTC媒体流，所述转码指令为管理服务调度节点根据监测到的转码服务节点内执行转码服务的各工作进程的工作状态发送的指令；

将所述RTC媒体流进行转码操作生成RTMP媒体流；

将所述RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端；

将所述RTC媒体流推送给参与互动的观众端。

2.根据权利要求1所述的方法，其特征在于，所述将所述RTC媒体流进行转码操作，生成RTMP媒体流，包括：

从所述RTC媒体流中获取RTP媒体包；

解析所述RTP媒体包，获取媒体数据和RTP报头；

根据所述媒体数据和RTP报头构建RTMP媒体流。

3.根据权利要求2所述的方法，其特征在于，所述根据所述媒体数据和RTP报头构建RTMP媒体流之前还包括：

获取预先设置的合流参数；

基于所述合流参数，确定所述媒体数据是否需要合流；

若不需要合流，执行所述根据所述媒体数据和RTP报头构建RTMP媒体流；

若需要合流，对所述媒体数据进行解码操作，得到解码后的媒体数据；

将所述解码后的媒体数据根据所述合流参数进行合流；

对合流后的媒体数据进行编码操作。

4.根据权利要求1所述的方法，其特征在于，所述转码服务节点响应于转码指令，触发获取主播端的RTC媒体流之前还包括：

获取所述转码服务节点的工作状态；

基于所述工作状态，更新管理服务调度节点的服务列表，其中，所述服务列表记录所述转码服务节点内各工作进程的状态信息；

根据所述服务列表，触发转码指令。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

获取所述转码服务节点内各工作进程的进程信息和任务信息；

将所述各工作进程的进程信息和任务信息存储在工作表以及持久化记录表中，其中，所述工作表位于内存中，所述持久化记录表位于硬盘中。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

检测所述转码服务节点内的各工作进程是否有异常；

若检测到有工作进程发生异常，根据所述工作表以及持久化记录表中存储的信息重新创建工作进程，并在新创建的工作进程中恢复发生异常的工作进程的转码任务。

7.根据权利要求6所述的方法，其特征在于，所述若检测到有工作进程发生异常，根据所述工作表以及持久化记录表中存储的信息重新创建工作进程，并在新创建的工作进程中恢复发生异常的工作进程的转码任务，包括：

若检测到有工作进程发生异常，检测所述工作表中存储的与所述发生异常的工作进程对应的进程信息和任务信息是否丢失；

若丢失，则根据所述持久化记录表中存储的与发生异常的工作进程对应的进程信息和任务信息重新创建进程，并在新创建的工作进程中恢复所述发生异常的工作进程的转码任务。

8.一种转码装置，其特征在于，所述装置包括：

RTC媒体流获取单元，用于转码服务节点响应于转码指令，触发获取主播客户端的RTC媒体流，所述转码指令为管理服务调度节点根据监测到的转码服务节点内执行转码服务的各工作进程的工作状态发送的指令；

转码单元，用于将所述RTC媒体流进行转码操作生成RTMP媒体流；

媒体流推送单元，用于将所述RTMP媒体流推送给目标观众端，其中，所述目标观众端为未参与互动的观众端；将所述RTC媒体流推送给参与互动的观众端。

9.一种电子设备，其特征在于，包括一个或多个处理器以及存储器；一个或多个程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行权利要求1-7任一所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有程序代码，其中，在所述程序代码被处理器运行时执行权利要求1-7任一所述的方法。

Images