直播推流方法、装置、设备、存储介质及计算机程序产品与流程

1.本公开涉及数据处理技术领域，具体涉及互动直播、云服务、图像处理等技术领域，尤其涉及一种直播推流方法、装置、电子设备、计算机可读存储介质及计算机程序产品。


背景技术：

2.随着直播行业的兴起，直播的方式和种类也随着不断发展、更新，以期带给观众更好的收看体验。
3.当前的直播方式根据是否有除主播端和观众端外的第三方互动端，可分为由主播端仅面向观众端的普通直播方式，和第三方互动端向住主播端发起连麦互动，将主播端和连麦端的直播内容一起给到观众端的互动直播方式。由于普通直播方式和互动直播方式往往采用不同的推流方式，导致在两种直播方式切换时经常会产生时延、卡顿，进而影响观看体验。
4.因此，如何尽可能的消除因直播方式切换所带来的时延、卡顿，是本领域技术人员亟待解决的问题。


技术实现要素：

5.本公开实施例提出了一种直播推流方法、装置、电子设备、计算机可读存储介质及计算机程序产品。
6.第一方面，本公开实施例提出了一种直播推流方法，包括：接收连麦端传入的连麦端音视频；统一主播端音视频和连麦端音视频的格式，并对格式统一后的主播端音视频和连麦端音视频进行混流，得到混合音视频；将所述混合音视频通过实时消息传输协议推送给直播收看端。
7.第二方面，本公开实施例提出了一种直播推流装置，包括：连麦端音视频接收单元，被配置成接收连麦端传入的连麦端音视频；格式统一及混流单元，被配置成统一主播端音视频和连麦端音视频的格式，并对格式统一后的主播端音视频和连麦端音视频进行混流，得到混合音视频；rtmp协议复用单元，被配置成将混合音视频通过实时消息传输协议推送给直播收看端。
8.第三方面，本公开实施例提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现如第一方面中任一实现方式描述的直播推流方法。
9.第四方面，本公开实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行时能够实现如第一方面中任一实现方式描述的直播推流方法。
10.第五方面，本公开实施例提供了一种包括计算机程序的计算机程序产品，该计算机程序在被处理器执行时能够实现如第一方面中任一实现方式描述的直播推流方法。
11.本公开实施例提供的直播推流方法包括：接收连麦端传入的连麦端音视频；统一主播端音视频和连麦端音视频的格式，并对格式统一后的主播端音视频和连麦端音视频进行混流，得到混合音视频；将混合音视频通过实时消息传输协议推送给直播收看端。
12.本公开由接受连麦端发起的连麦申请的主播端，在主播端本地对连麦端音视频和自己的主播端音视频进行格式统一和混流操作，并通过继续使用已开启的实时消息传输协议(rtmp，real time messaging protocol)所具有的单路音视频流推流能力，来实际上完成两路音视频流的推流，由于直播收看端因无需切换协议避免了卡顿、缩短了时延、提升了画面的连贯性，进而提升了观看体验。
13.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
14.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：
15.图1是本公开可以应用于其中的示例性系统架构；
16.图2为本公开实施例提供的一种直播推流方法的流程图；
17.图3a为本公开实施例提供的非连麦场景下的单向推流示意图；
18.图3b为本公开实施例提供的连麦场景下的单向推流示意图；
19.图4为本公开实施例提供的一种格式统一方法的流程图；
20.图5为本公开实施例提供的另一种格式统一方法的流程图；
21.图6为本公开实施例提供的一种混流方法的流程图；
22.图7为本公开实施例提供的一种基于缓冲队列的混流示意图；
23.图8为本公开实施例提供的一种直播推流装置的结构框图；
24.图9为本公开实施例提供的一种适用于执行直播推流方法的电子设备的结构示意图。
具体实施方式
25.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。
26.本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
27.图1示出了可以应用本公开的直播推流方法、装置、电子设备及计算机可读存储介质的实施例的示例性系统架构100。
28.如图1所示，系统架构100可以包括主播端101、连麦端102、中转服务器103、直播收看端104，各端之间可通过有线或无线的方式实现数据的传输。
29.主播可通过主播端101配置的功能组件(例如收音组件、拍摄组件)采集音视频数
据，连麦用户也可以通过连麦端102配置的功能组件采集音视频数据，直播收看端104可通过从终端服务器103出拉流将取回的音视频呈现为直播收看用户。主播端101、连麦端102、中转服务器103和直播收看端104上可以安装有各种用于实现各端之间进行信息通讯的应用，例如直播类应用、互动直播类应用、即时通讯类应用等。
30.主播端101、连麦端102、中转服务器103、直播收看端104通常为硬件，其中，主播端101、连麦端102以及直播收看端104通常表现为配置有能够采集和播放音视频数据的功能组件的终端设备，例如智能手机、平板电脑、台式电脑等；中转服务器103则可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。
31.主播端101通过内置的各种应用可以提供各种直播服务，以可以在连麦场景为直播收看用户提供无卡顿的互动直播服务的互动直播类应用为例，主播端101在运行互动直播类应用时可实现如下效果：首先，接收连麦端102通过rtp(real
‑
time transport protocol，实时传输协议)直接传入的连麦端音视频；然后，在本地统一主播端音视频和连麦端音视频的格式，并对格式统一后的主播端音视频和连麦端音视频进行混流，得到混合音视频；最后，将混合音视频通过实时消息传输协议(rtmp)经中转服务器103的中转，最终将混合音视频推送给直播收看端104。在上述场景下，直播收看端104持续通过rtmp接收推流数据。
32.本公开后续各实施例所提供的直播推流方法一般由拥有较强运算能力、较多运算资源的主播端101来执行，因为主播端101的配置通常考虑到要向众多观众提供高质量的音视频数据，因此主播端101通常拥有较强的运算能力和拥有较多的运算资源。相应地，直播推流装置一般也设置于主播端101中。
33.应该理解，图1中的直播端、连麦端、中转服务器、直播收看端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的直播端、连麦端、中转服务器、直播收看端。
34.请参考图2，图2为本公开实施例提供的一种直播推流方法的流程图，其中流程200包括以下步骤：
35.步骤201：接收连麦端传入的连麦端音视频；
36.本步骤旨在由直播推流方法的执行主体(例如图1所示的主播端101)接收连麦端(例如图1所示的连麦端102)传入的连麦端音视频。
37.本公开中所描述的主播端是指存在收看其直播内容的观众的主播所在的一端，连麦端则是指向主播端发起连麦请求的连麦者所在的一端，当连麦端的连麦者也有自己的观众时，连麦端也同时属于直播端，即此时的两端在属于主播端的同时也互为对端的连麦端。
38.为了尽可能的表达清楚本公开的方案，仅从一对存在连麦关系的主播端和连麦端来描述本公开的技术方案。
39.具体的，上述执行主体可通过rtp协议接收到连麦端传入的连麦端音视频，由于通常连麦端与主播端之间存在距离，连麦端音视频的传输将通常需要经过至少一次路由转发，转发次数通常与距离成正比。
40.步骤202：统一主播端音视频和连麦端音视频的格式，并对格式统一后的主播端音视频和连麦端音视频进行混流，得到混合音视频；
41.在步骤201的基础上，本步骤旨在由上述执行主体在自身的本地存储空间中，统一由自身功能组件收集到的主播端音视频和接收到的连麦端音视频的格式，并对格式统一的
主播端音视频和连麦端音视频进行混流，最终得到混流的方式得到一路混合音视频，即通过上述执行主体在本步骤的操作将两路音视频混流为一路混合音视频，进而得以匹配仅能传输一路音视频的rtmp协议。
42.步骤203：将混合音视频通过实时消息传输协议推送给直播收看端。
43.在步骤202的基础上，本步骤旨在由上述执行主体将经过格式统一、混流操作后得到的一路混流音视频通过仅能传输一路音视频的rtmp协议向外推流，并最终将其推送给同样采用rtmp收看直播的直播收看端(例如图1所示的直播手段看104)。即通过混流操作将原来分别来自主播端和连麦端的两路音视频混合为一路混流音视频，使得可以复用rtmp进行数据的传输。
44.本公开实施例提供的直播推流方法，由接受连麦端发起的连麦申请的主播端，在主播端本地对连麦端音视频和自己的主播端音视频进行格式统一和混流操作，其中格式统一不仅方便混流、提升混流效果，也避免了未经格式统一的混合音视频到达直播收看端后由直播收看端进行多路解码所造成的时延和卡顿，而且相较于直播收看端的性能，主播端通常拥有更强的运算能力，更适合来做格式统一和混流操作。而由于通过混流操作将原来的两路音视频整合为一路，因此可继续使用已开启的rtmp协议所具有的单路音视频流推流能力，来实际上完成两路音视频流的推流，使得直播收看端因无需切换协议避免了卡顿、缩短了时延、提升了画面的连贯性，进而提升了观看体验。
45.为了加深对本公开所提供的上述方案的理解，此处还通过呈现现有方案的图3a和呈现本公开所提供方案的图3b的比对，来更清晰的展示本公开所提供方案的改进点：
46.图3a示出了现有方案给出的非连麦场景下的单向推流方案，由于此时处于非连麦场景，可认为只有由clienta代表的主播端和由clientc代表的直播收看端，整个推流过程为：设置在主播端的source(资源)模块收集到主播端音视频(audio capture和video record)，并由source模块分别将主播端音频和主播端视频发送至enoder(编码)模块编码为二进制字符串，再由enoder模块将分别编码好的音频字符串和视频字符串整合为flv格式的音视频数据包，最终通过rtmp socket(实时消息传输协议的套接字)经由fvl media(媒体资源)server(服务)传输至直播收看端。
47.区别于图3a方案所处的非连麦场景，图3b所处的是有由clientb代表的连麦端参与连麦的连麦场景，区别于常规的采用webrtc框架(是一种基于浏览器接口的音视频传输框架)实现的多路推流方式，图3b所示方案是在图3a所示的单向推流方案基础上改进得到，即仍使用rtmp无需直播收看端切换至webrtc框架。
48.如图3b所示，由clientb代表的连麦端通过webrtc media server将连麦端音视频传输至由clienta代表的主播端(同时也通过webrtc media server接收主播端发来的主播端音视频)，主播端通过自身的webrtc框架接收到连麦端音视频，并通过增设的trans模块将连麦端音视频和由source render模块采集到的主播端音视频进行格式统一，然后再通过增设的mixer(混流)模块将两路格式统一的音频整合为一路混合音频、将两路格式统一的视频整合为一路混合视频，然后将混合音频和混合视频依次通过已存在图3中的enoder模块、flv packer(打包)模块、rtmp socket、fvl media server传输至由clientc代表的直播收看端。
49.即图3b区别于图3a的部分，主要是用于格式统一的trans模块和用于混流的mixer
模块，借助这两个模块使得直接使用rtmp协议传输互动直播数据成为可能，避免了直播收看端因切换至webrtc框架来解析多路音视频带来的时延、卡顿现象出现。
50.为了加深对上述执行主体具体如何实现格式统一，本公开还通过图4和图5提供了两种不同的实现方式，以适配不同的实际应用场景。
51.其中，如图4所示的一种格式统一方法包括以下步骤：
52.步骤401：从本地编解码组件中读取生成当前的主播端音视频的第一音视频参数；
53.即本步骤旨在由上述执行主体(主播端)在本地的用于编码生成主播端音视频的编解码组件中直接读取到第一音视频参数，以尽可能的快速的获取到该第一音视频参数。此种方式比通过对编码组件所编解码得到的主播端音视频进行参数分析从而确定到第一音视频参数的方式，耗时更短。应当理解的是，不同的音视频参数将导致形成格式不同的音视频数据。
54.步骤402：根据连麦端音视频确定连麦端音视频采用的第二音视频参数；
55.由于无法直接像步骤401一样直接访问到用于生成连麦端音视频的编解码组件，因此本步骤仅能够由上述执行主体通过对连麦端音视频进行分析来确定第二音视频参数。
56.具体的，音视频参数可包括：音视频的编码率、采样率，编码格式、封装格式等。
57.步骤403：控制编解码组件按照第二音视频参数生成新的主播端音视频。
58.在步骤402的基础上，本步骤旨在由上述执行主体直接控制编解码组件按照第二音视频参数生成新的主播端音视频，即通过直接按照连麦端音视频采用的第二音视频来调整主播端音视频的生成参数，从而达成音视频格式的统一。
59.但需要说明的是，本实施例所提供方案需要建立在主播端的设备可临时改变用于生成音视频数据的参数的情况下。
60.区别于图4，图5所提供的另一种格式统一方法建立在主播端的设备无法临时改变用于生成音视频数据的参数的情况下，其流程500包括以下步骤：
61.步骤501：从本地的编解码组件中读取生成主播端音视频的第一音视频参数；
62.步骤502：根据连麦端音视频确定连麦端音视频采用的第二音视频参数；
63.上述步骤501
‑
步骤502与步骤401
‑
步骤402一致，此处不再赘述。
64.步骤503：根据第一音视频参数、第二音视频参数、预设的基准音视频参数，确定与目标格式对应的目标音视频参数；
65.在步骤501、步骤502的基础上，本步骤旨在由上述执行主体在第一音视频参数、第二音视频参数、预设的基准音视频参数中，确定适合作为与目标格式对应的目标音视频参数。
66.其中，该基准音视频参数是一个被配置为建议参照该音视频参数作为格式统一目标的参数。
67.一种包括且不限于的实现方式为：
68.响应于第一音视频参数或第二音视频参数与基准音视频参数相同，将基准音视频参数设置为目标音视频参数。即若已经有第一音视频参数或第二音视频参数与基准音视频参数相同，那么说明该基准音视频参数较为合适作为目标音视频参数，那么此时只需要将与该目标音视频参数不同的那端音视频进行参数调整即可。
69.另一种包括且不限于的实现方式为：
70.响应于第一音视频参数、第二音视频参数均不同于基准音视频参数，分别计算按第二音视频参数调整主播端音视频的第一转换代价、按第一音视频参数调整连麦端音视频的第二转换代价；
71.根据第一转换代价和第二转换代价，将拥有最小转换代价的音视频参数确定为目标音视频参数。即在基准音视频参数不适合作为共同格式的音视频参数时(因为如果作为目标音视频参数，就需要同时对主播端音视频和连麦端音视频进行不同的参数转换)，因此该实现方式将计算从第一音视频参数调整为第二音视频参数或者反过来进行的转换代价，从而将与转换代价最小的转换方式对应的转换后音视频参数确定为目标音视频参数。
72.步骤504：调整得到按目标音视频参数生成的新的主播端音视频和连麦端音视频。
73.在上述任意实施例的基础上，本公开实施例还通过图6提供了一种将格式统一后的连麦端音视频和主播端音视频进行混流的实现方式，其中流程600包括以下步骤：
74.步骤601：将接收到的连麦端音视频按照接收次序依次存入预设的缓冲队列；
75.可见该缓冲队列的作用为暂存接收到的连麦端音视频，存储单位通常按照以帧为单位，影响帧数大小的帧率可以自行设定。
76.步骤602：判断缓冲队列中是否存储有还未使用过的新连麦端音视频数据，若存储有，执行步骤603，否则执行步骤604；
77.本步骤旨在由上述执行主体判断缓冲队列中是否存储有还未使用过的新连麦端音视频数据，并根据判别结果选择不同的处理分支。
78.步骤603：使用新连麦端音视频数据与当前时刻的主播端音视频数据进行混流，得到当前时刻的混合音视频数据；
79.本步骤建立在步骤602的判断结果为缓冲队列中存储有还未使用过的新连麦端音视频数据的基础上，旨在使用能够描述连麦端最新连麦数据的新连麦端音视频数据与当前最新的主播端音视频数据进行混流，以使混合得到的混合音视频数据包含有最新的互动直播内容。
80.步骤604：使用最新存入缓冲队列的连麦端音视频数据与当前时刻的主播端音视频数据进行混流，得到当前时刻的混合音视频数据。
81.本步骤建立在步骤602的判断结果为缓冲队列中未存储有还未使用过的新连麦端音视频数据的基础上，为尽可能的表现连麦端的存在感，本步骤将复用最新存入缓冲队列的连麦端音视频数据与当前时刻的主播端音视频数据进行混流，得到当前时刻的混合音视频数据。
82.为了避免相同的连麦端音视频数据被多次连续使用形成连续时刻的混合音视频数据，还可以控制相同连麦端音视频数据的最大使用次数，或者通过调整间隔使用，从而避免连续使用造成的卡音或者卡画面现象出现。
83.与上述步骤603或步骤604对应的混流方案，可参见相匹配的示意图图7，其中的local video/audio buffer指用于存储主播端音视频的缓存器，remote video/audio buffer则指用于存储连麦端音视频的缓存器，在remote video/audio buffer还设置有一个bufferlist(缓冲队列)，来自remote video/audio buffer的各帧连麦端音视频数据将按照时序依次存入该bufferlist，再输出时也将按照先入先出顺序，最终在mix模块与local video/audio buffer的各帧主播端音视频数据混流。
84.需要说明的是，步骤604并不一定要作为与步骤603相反的另一处理分支的唯一处理方案，也可以选择其它的处理方案，本实施例仅作为一个同时将上述两种具体处理方案作为相反的两支的优选实施例。
85.进一步参考图8，作为对上述各图所示方法的实现，本公开提供了一种直播推流装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。
86.如图8所示，本实施例的直播推流装置800可以包括：连麦端音视频接收单元801、格式统一及混流单元802、rtmp协议复用单元803。其中，连麦端音视频接收单元801，被配置成接收连麦端传入的连麦端音视频；格式统一及混流单元802，被配置成统一主播端音视频和连麦端音视频的格式，并对格式统一后的主播端音视频和连麦端音视频进行混流，得到混合音视频；rtmp协议复用单元803，被配置成将混合音视频通过实时消息传输协议推送给直播收看端。
87.在本实施例中，直播推流装置800中：连麦端音视频接收单元801、格式统一及混流单元802、rtmp协议复用单元803的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201
‑
203的相关说明，在此不再赘述。
88.在本实施例的一些可选的实现方式中，格式统一及混流单元802可以包括被配置成统一主播端音视频和连麦端音视频的格式的格式统一子单元，格式统一子单元可以被进一步配置成：
89.从本地编解码组件中读取生成当前的主播端音视频的第一音视频参数；
90.根据连麦端音视频确定连麦端音视频采用的第二音视频参数；
91.控制编解码组件按照第二音视频参数生成新的主播端音视频。
92.在本实施例的一些可选的实现方式中，格式统一及混流单元802可以包括被配置成统一主播端音视频和连麦端音视频的格式的格式统一子单元，格式统一子单元可以包括：
93.第一音视频参数读取模块，被配置成从本地的编解码组件中读取生成主播端音视频的第一音视频参数；
94.第二音视频参数确定模块，被配置成根据连麦端音视频确定连麦端音视频采用的第二音视频参数；
95.目标音视频参数确定模块，被配置成根据第一音视频参数、第二音视频参数、预设的基准音视频参数，确定与目标格式对应的目标音视频参数；
96.参数调整模块，被配置成调整得到按目标音视频参数生成的新的主播端音视频和连麦端音视频。
97.在本实施例的一些可选的实现方式中，目标音视频参数确定模块可以被进一步配置成：
98.响应于第一音视频参数或第二音视频参数与基准音视频参数相同，将基准音视频参数设置为目标音视频参数。
99.在本实施例的一些可选的实现方式中，目标音视频参数确定模块可以被进一步配置成：
100.响应于第一音视频参数、第二音视频参数均不同于基准音视频参数，分别计算按
第二音视频参数调整主播端音视频的第一转换代价、按第一音视频参数调整连麦端音视频的第二转换代价；
101.根据第一转换代价和第二转换代价，将拥有最小转换代价的音视频参数确定为目标音视频参数。
102.在本实施例的一些可选的实现方式中，格式统一及混流单元802可以包括被配置成对格式统一后的主播端音视频和连麦端音视频进行混流得到混合音视频的混流子单元，混流子单元可以包括：
103.缓冲队列存入模块，被配置成将接收到的连麦端音视频按照接收次序依次存入预设的缓冲队列；
104.新数据混流模块，被配置成响应于缓冲队列中存储有还未使用过的新连麦端音视频数据，使用新连麦端音视频数据与当前时刻的主播端音视频数据进行混流，得到当前时刻的混合音视频数据。
105.在本实施例的一些可选的实现方式中，混流子单元还可以包括：
106.旧数据混流模块，被配置成响应于缓冲队列中未存储有未使用过的新连麦端音视频数据，使用最新存入缓冲队列的连麦端音视频数据与当前时刻的主播端音视频数据进行混流，得到当前时刻的混合音视频数据；其中，缓冲队列中的任一连麦端音视频数据参与混流的次数不超过预设次数。
107.本实施例作为对应于上述方法实施例的装置实施例存在，本实施例提供的直播推流装置，由接受连麦端发起的连麦申请的主播端，在主播端本地对连麦端音视频和自己的主播端音视频进行格式统一和混流操作，并通过继续使用已开启的rtmp协议所具有的单路音视频流推流能力，来实际上完成两路音视频流的推流，由于直播收看端因无需切换协议避免了卡顿、缩短了时延、提升了画面的连贯性，进而提升了观看体验。
108.根据本公开的实施例，本公开还提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现上述任意实施例所描述的直播推流方法。
109.根据本公开的实施例，本公开还提供了一种可读存储介质，该可读存储介质存储有计算机指令，该计算机指令用于使计算机执行时能够实现上述任意实施例所描述的直播推流方法。
110.本公开实施例还提供了一种计算机程序产品，该计算机程序在被处理器执行时能够实现上述任意实施例所描述的直播推流方法。
111.图9示出了可以用来实施本公开的实施例的示例电子设备900的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
112.如图9所示，设备900包括计算单元901，其可以根据存储在只读存储器(rom)902中的计算机程序或者从存储单元908加载到随机访问存储器(ram)903中的计算机程序，来执
行各种适当的动作和处理。在ram 903中，还可存储设备900操作所需的各种程序和数据。计算单元901、rom 902以及ram 903通过总线904彼此相连。输入/输出(i/o)接口905也连接至总线904。
113.设备900中的多个部件连接至i/o接口905，包括：输入单元906，例如键盘、鼠标等；输出单元907，例如各种类型的显示器、扬声器等；存储单元908，例如磁盘、光盘等；以及通信单元909，例如网卡、调制解调器、无线通信收发机等。通信单元909允许设备900通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
114.计算单元901可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元901的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元901执行上文所描述的各个方法和处理，例如直播推流方法。例如，在一些实施例中，直播推流方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元908。在一些实施例中，计算机程序的部分或者全部可以经由rom 902和/或通信单元909而被载入和/或安装到设备900上。当计算机程序加载到ram 903并由计算单元901执行时，可以执行上文描述的直播推流方法的一个或多个步骤。备选地，在其他实施例中，计算单元901可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行直播推流方法。
115.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
116.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
117.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd
‑
rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
118.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机
具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
119.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
120.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端
‑
服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(vps，virtual private server)服务中存在的管理难度大，业务扩展性弱的缺陷。
121.根据本公开实施例的技术方案，由接受连麦端发起的连麦申请的主播端，在主播端本地对连麦端音视频和自己的主播端音视频进行格式统一和混流操作，并通过继续使用已开启的rtmp协议所具有的单路音视频流推流能力，来实际上完成两路音视频流的推流，由于直播收看端无需切换协议进而避免了卡顿、提升了观看体验。
122.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
123.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。