直播视频流推送控制方法、装置、设备及存储介质与流程

本申请涉及网络直播控制技术，尤其涉及一种直播视频流推送控制方法、装置、设备及存储介质。

背景技术：

网络直播时，直播间中的主播用户，其摄像设备获取的视频流，会被编码后，通过主播用户的电子设备与服务器之间的推流链路推送到服务器，由服务器对视频流进行处理后，再推送到直播间中进行显示。主播用户接收服务器回传的视频流后也可在其直播间图形用户界面中对回传的视频流进行播放。

主播用户在向服务器推送视频流的过程中，有时会发生屏幕方向切换的操作，例如将其用于摄像的手机从纵向放置的状态旋转切换到横向旋转的状态，反之也是。可想而知，由于手机旋转的同时带动摄像头旋转，这种切换常会导致服务器回传的视频流在显示时同步这一效果，用户端此时将感觉到景物的方向发生了错乱，这种异常的显示效果，不符合应用需求。

现有技术的一种解决方式中，是在获知主播用户旋转手机设备时，便停止向服务器推送视频流，服务器此时便只能向直播间用户报错或者不再输出任何信息，而直播间用户则无法接收到任何视频流，于是往往只能在原有的视频播放窗口报错或者让播放窗口处于无内容的状态。

另一种解决方式中，是在获知主播用户旋转手机设备时，不停止向服务器推送视频流，只是同步地修改相关配置信息以通知服务器用户设备进行了屏幕方向切换。这种情况下，服务器一直保持第一方向的配置信息的同时，突然收到第二方向的配置信息，这一突然性会被传递给直播间所有用户，因此，直播间用户的视频播放窗口中，从第一方向的显示状态突然切换到第二方向的显示状态时，两种尺寸画面之间没有过渡，切换效果欠佳。

由此可见，现有技术的两种方式对于主播用户的视频流突然被切换屏幕方向的情况的处理均存在美中不足之处，均会由于一些不受主播侧控制的因素，影响视频流的画面切换的平滑性，因而存在可以进一步改进以提升用户体验的空间。

技术实现要素：

本申请的首要目的在于提供一种直播视频流推送控制方法，以便解决网络直播过程中因切换屏幕方向所引发的视频流画面过渡的问题，以提升用户观看体验。

作为本申请的另一目的，提供一种与前述的方法相适应的直播视频流推送控制装置。

作为本申请的又一目的，基于前述的方法而提供与之相适应的一种电子设备。

作为本申请的再一目的，提供一种适于存储依据所述的方法实现的计算机程序的非易失性存储介质。

为满足本申请的各个目的，本申请采用如下技术方案：

适应本申请的首要目的而提出的一种直播视频流推送控制方法，其包括如下步骤：

响应本机设备在直播间推送视频流过程中接收的屏幕方向切换指令，获取与目标屏幕方向相对应的视频流编码配置信息；

在维持视频流既有的推流链路的同时，暂停执行对所述视频流的编码，按照所述编码配置信息更新视频流编码所需的相应配置；

重启执行对所述视频流的编码以便向直播间继续推送视频流，以使直播间用户将后续接收的视频流按照目标屏幕方向相适配的布局显示。

一类实施例中，本机设备的直播间用户界面上提供切换控件用于受控切换、触发所述的屏幕方向切换指令，对该切换控件的奇数次触控导致产生第一屏幕方向切换指令，确定目标屏幕方向为纵向/横向；对该切换控件的偶数次触控导致产生第二屏幕方向切换指令，确定目标屏幕方向为横向/纵向。

另一类实施例中，本机设备通过识别自身加速度传感器的运动数据对所述目标屏幕方向进行预判，当所述运动数据与所述屏幕方向切换指令的触发条件相匹配时，判定所述的目标屏幕方向为横向或纵向并触发相应的屏幕方向切换指令。

进一步的实施例中，所述的编码配置信息包括与所述目标屏幕方向相对应的分辨率信息、编码格式信息、传输码率信息。

较佳的实施例中，所述推流链路在本机设备与服务器之间通过心跳包进行维持，重启执行对所述视频流的编码后，本机设备通过所述推流链路发送心跳包以确保维持所述推流链路。

进一步的实施例中，本方法还包括如下后续步骤：

接收直播间回传所述视频流，对该视频流进行解码，解码成功后按照所述目标屏幕方向相适配的布局显示所述的视频流。

较佳的实施例中，所述目标屏幕方向相适配的布局与所述编码配置信息中包含的一种或多种具体信息相关联。

适应本申请的另一目的而提出的一种直播视频流推送控制装置，其包括：

切换单元，用于响应本机设备在直播间推送视频流过程中接收的屏幕方向切换指令，获取与目标屏幕方向相对应的视频流编码配置信息；

控制单元，用于在维持视频流既有的推流链路的同时，暂停执行对所述视频流的编码，按照所述编码配置信息更新视频流编码所需的相应配置；

重启单元，用于重启执行对所述视频流的编码以便向直播间继续推送视频流，以使直播间用户将后续接收的视频流按照目标屏幕方向相适配的布局显示。

适应本申请的又一目的而提供的一种电子设备，包括中央处理器和存储器，所述中央处理器用于调用运行存储于所述存储器中的计算机程序以执行本申请所述的直播视频流推送控制方法的步骤。

适应本申请的再一目的而提供的一种非易失性存储介质，其存储有依据所述的直播视频流推送控制方法所实现的计算机程序，该计算机程序被计算机调用运行时，执行该方法所包括的步骤。

相对于现有技术，本申请的优势如下：

首先，本申请的实施，能够提升网络直播的视频流推送过程的稳定度。

原理上，本申请通过响应在直播间视频流推送过程中接收的屏幕方向切换指令而启动执行，进一步在维持视频流当前推送链路的情况下，暂停执行对视频流的编码，将当前视频流的编码配置更新为目标屏幕方向相应的视频流的编码配置，之后重启执行视频流编码，由此，直播间用户在主播侧暂停编码时，由于推流链路不会断开而不会导致断流报错，可以维持暂停编码前的最后画面，当主播侧重启编码时，可从其接收的视频流中解析出新的编码配置信息，按照新的配置根据目标屏幕方向的布局进行匹配显示。可以理解，由于本申请通过暂停执行对其视频流的编码而不是暂停视频流推流链路，更不是同时停止推流链路和编码的方式来更新视频流推送的配置信息，能有效解决由于主播用户切换终端的屏幕方向而导致出错或画面过渡不受控制的问题。

其次，本申请的实施使直播间视频流即使在主播用户切换屏幕方向时，也能够保持自然的切换过渡。如前所述，由于推流链路得以维持，只是暂停和重启编码，因此，观众用户的视频播放窗口处，当主播用户停止编码时，观众用户的视频播放窗口按其既有的实现逻辑自然显示停止编码前的最后一帧图像，既不报错，也不会进行拉伸、放大等操作，画面保持自然，直到收到重新编码的视频流时，视频播放窗口即从该视频流中解析出新的编码配置信息将视频流调整为目标屏幕方向的显示布局，这个过程便较为平滑自然，改善了用户体验，更不必对直播间应用程序所调用的视频播放插件进行任何代码修改。

此外，本申请为直播间应用程序提供了多种识别主播用户切换屏幕方向的能力，通过这些能力，可以便于主播用户进行更便利的控制，用户无论是通过图形用户界面上的控件控制切换屏幕方向，抑或是由用户的终端设备通过加速度传感器预判切换屏幕方向的事件，均是便于主播用户控制以达到前述的各种效果的有效手段，为程序开发层面带来较大的效率提升。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为实施本申请的技术方案相关的一种典型的网络部署架构示意图；

图2为本申请的直播视频流推送控制方法的典型实施例的流程示意图；

图3为根据本申请的直播视频流推送控制方法实现的一种计算机程序在运行时，其在网络部署架构实施的一个交互过程的示意图；

图4为本申请的直播视频流推送控制装置的典型实施例的原理框图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“客户端”、“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，进行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他诸如个人计算机、平板电脑之类的通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；pcs(personalcommunicationsservice，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；pda(personaldigitalassistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或gps(globalpositioningsystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“客户端”、“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“客户端”、“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是pda、mid(mobileinternetdevice，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本申请所称的“服务器”、“客户端”、“服务节点”等名称所指向的硬件，本质上是具备个人计算机等效能力的电子设备，为具有中央处理器(包括运算器和控制器)、存储器、输入设备以及输出设备等冯诺依曼原理所揭示的必要构件的硬件装置，计算机程序存储于其存储器中，中央处理器将存储在外存中的程序调入内存中运行，执行程序中的指令，与输入输出设备交互，借此完成特定的功能。

需要指出的是，本申请所称的“服务器”这一概念，同理也可扩展到适用于服务器机群的情况。依据本领域技术人员所理解的网络部署原理，所述各服务器应是逻辑上的划分，在物理空间上，这些服务器既可以是互相独立但可通过接口调用的，也可以是集成到一台物理计算机或一套计算机机群的。本领域技术人员应当理解这一变通，而不应以此约束本申请的网络部署方式的实施方式。

请参阅图1，本申请相关技术方案实施时所需的硬件基础可按图中所示的架构进行部署。本申请所称的服务器80部署在云端，作为一个前端的应用服务器，其可以充当或者负责进一步连接起相关数据服务器、视频流服务器、针对即时视频流进行评分的评分服务器以及其他提供相关支持的服务器等，以此构成逻辑上相关联的服务机群，来为相关的终端设备例如图中所示的智能手机81和个人计算机82提供服务。所述的智能手机和个人计算机均可通过公知的网络接入方式接入互联网，与云端的服务器80建立数据通信链路，以便运行所述服务器所提供的服务相关的终端应用程序。在本申请的相关技术方案中，服务器80负责建立直播间运行服务，终端则对应运行与该直播间相对应的应用程序。

本申请所称的网络直播，是指一种基于前述的网络部署架构所实现的一种直播间网络服务。

本申请所称的直播间，是指依靠互联网技术实现的一种视频聊天室，通常具备音视频播控功能。直播间的活动的开展，依赖于众多直播间用户的参与，p这些直播间用户主要包括主播用户和观众用户，主播用户与观众用户之间可通过语音、视频、文字等公知的线上交互方式来实现互动，一般是主播用户以音视频流的形式为观众用户表演节目，并且在互动过程中还可产生经济交易行为。当然，直播间的应用形态并不局限于在线娱乐，也可推广到其他相关场景中，例如教育培训场景、视频会议场景、产品推介销售场景以及其他任何需要类似互动的场景中。

通常，提供直播间网络直播服务的平台方会提供相关的应用程序，以便主播用户和观众用户可以通过各处相关应用程序在终端电子设备上运行而接入云端服务器，来实现直播交互。这些应用程序当然还可以提供其他附带业务和增值服务。

直播间的应用程序运行后，用户通过相关入口进入特定的直播间，该直播间相应提供一个图形用户界面供用户之间进行交互。通常，直播间的图形用户界面中，包括一个由视频播放器展现的视频播放窗口，用于解码播放服务器推送的通常由主播用户产生的视频流，此外还设置供用户实施信息交互的相关控件。直播间通常也可以允许视频播放窗口以全屏的方式进行播放，而对供信息交互的相关控件进行暂时隐藏。具体的界面设计方案不一而足，恕不赘述。

众所周知，直播间的视频流产生自用户的电子设备的摄像单元，这种摄像单元既可以是电子设备自带的摄像头，也可以是外置并保持与电子设备电性连接的摄像机等。电子设备除了可以驱动摄像单元获取视频流之外，还可以依据用户设置或者结合由其自身携带的加速度传感器来判断电子设备的当前屏幕的座向是横向还是纵向，由此可以根据这种座向关系确定当前屏幕方向，进一步，包括直播间应用程序在内的各种应用程序，便可利用屏幕方向调整摄像单元所产生的视频流的画幅方向，典型的，例如将分辨率从1080*1920调整为1920*1080。

直播间主播用户将其电子设备从横向放置调整为纵向放置，为了让视频流的画面同步于主播用户的当前屏幕方向，通常便涉及到视频流画幅方向的改变，而对视频流画幅的设置通常是在对视频流进行编码以便传输给服务器的阶段实现的，因此，直播设备的屏幕方向的切换，需要对其相关的编码方式进行调整。

服务器会根据网络情况及其提供的服务，为主播用户制定不同屏幕方向下的编码配置信息，编码配置信息通常包括视频流画幅的分辨率、适配网络带宽的转码率、用于指示主播用户电子设备的网络信号较弱时所采取的配置方案，以及为服务器所接收的编码格式等。与此相对应，编码配置信息通常包括分辨率信息、传输码率信息、弱网配置信息以及编码格式信息等。对视频流进行编码一般均需遵守这一原理，本领域技术人员可以知晓，且能灵活的指定其中的某种信息为必需，某种信息为非必需，例如本申请中，编码格式信息(如指定为h.264格式)与分辨率信息(如某一屏幕方向下指定为1080*1920)是必需的，余者即可灵活处理。有鉴于此，恕不再对编码配置信息的各个具体信息进行展开说明。

相应的，直播间用户，特别是主播用户可以事先向服务器获取不同屏幕方向情况下的相适配的编码配置信息，也即与目标屏幕方向的编码配置信息通常被事先下载到主播用户的终端设备中，方便直播间应用程序在需要时调用。当然，应用程序可以按需向服务器重新请求获取最新的与不同屏幕方向相匹配的编码配置信息，随时更新本地相应数据。

在理解在先揭示的若干概念和各类原理的基础上，本领域技术人员对此应当知晓：本申请的各种方法，虽然基于相同的概念而进行描述而使其彼此间呈现共通性，但是，除非特别说明，否则这些方法都是可以独立执行的。同理，对于本申请所揭示的各个实施例而言，均基于同一发明构思而提出，因此，对于相同表述的概念，以及尽管概念表述不同但仅是为了方便而适当变换的概念，应被等同理解。

请结合图2和图3，本申请的一种直播视频流推送控制方法的典型实施例表现为包括如下步骤：

步骤s11，响应本机设备在直播间推送视频流过程中接收的屏幕方向切换指令，获取与目标屏幕方向相对应的视频流编码配置信息：

图3给出的原理示意图中，是基于程序开发思维而给出的逻辑原理框图，示意出了服务器端及用户端的实现，其中用户端包括主播端和观众端，通常均安装有直播间应用程序，而媒体sdk实际上是集成该应用程序中的一个开发工具包。也就是说，直播间应用程序理论上可实现图中示出的主播端、用户端以及媒体sdk中的所有功能，视为使用用户的不同而做不同情况的执行。以下在描述时，将分别说明图3所涉的各个具体交互动作之间的执行主体，以便不至于混淆。

本方法是在主播用户开播并推送视频流的过程中执行的，因此，导致本方法执行的场景，是直播正在进行中，而主播用户突然发起屏幕方向切换指令。对于本机设备而言，可以通过一种或多种方式来识别这种屏幕方向切换指令。具体而言，可以参照如下方式：

一种方式中，直播间应用程序在开发时，便为直播间的图形用户界面提供一个切换控件，允许通过该切换控件的切换作用，向本机设备发出屏幕方向切换指令，实现表征本机设备的屏幕处于横向与处于纵向之间的状态切换。对于主播用户而言，其将从本机设备的直播间用户界面上看到的所述的切换控件，从而以指点的方式触发该切换控件产生所述的屏幕方向切换指令。较为简易直接的实现方式是将该切换控件设计为单向的开关，也即，对该切换控件的奇数次触控用于触发产生第一屏幕方向切换指令，确定目标屏幕方向为纵向/横向；而对该切换控件的偶数次触控用于触发产生第二屏幕方向切换指令，确定目标屏幕方向为横向/纵向。由此，用户可以通过奇数次或偶数次的触控来实现发出不同的屏幕方向切换指令。

另一种方式中，直播间应用程序可以不提供所述的切换控件，而由应用程序利用主播用户的终端设备的加速度传感器的运动数据所体现的运动趋势来实施对该终端设备的屏幕切换意向的预判。通过加速度传感器预判屏幕切换方向的技术为本领域技术人员所熟知，由此，直播间应用程序可以在本机设备产生屏幕切换的趋势时，依据本机设备触发的相关系统通知或系统事件，检验相关数据满足屏幕方向切换指令的触发条件时，预判主播用户即将发出针对目标屏幕方向的屏幕切换指令。例如，当直播间应用程序预判相关数据表征本机设备正在朝纵向倾斜时，即触发第一屏幕方向切换指令，并将纵向确定为相对应的目标屏幕方向；同理，当直播间应用程序预判相关数据表征本机设备正在朝横向倾斜时，即触发第二屏幕方向切换指令，并将横向确定为相对应的目标屏幕方向。

参照以上揭示的各种构成触发屏幕方向切换指令及其相对应的目标屏幕方向的示例，可以理解，直播间应用程序以所述屏幕方向切换指令的触发为执行本申请的方法为入口，启动对后续流程的执行。

在确定了所述的屏幕方向切换指令及其相应的目标屏幕方向之后，直播间应用程序便可进一步获取与目标屏幕方向相对应的视频流编码配置信息。如前所述，直播间应用程序可以根据所述的目标屏幕方向为纵向或横向，而相应调用纵向或横向的编码配置信息。在本申请的一个示例中，可以假设所述编码配置信息仅包括分辨率信息、传输码率信息以及编码格式信息，恕不赘述。

结合图3的程序实现示例将能更清楚地理解本步骤：实际上，程序开发时，可以通过构造一个监听指令来实现，其监听屏幕方向切换指令，即图3所示的screenorientationchanged指令。当其监听到触发了屏幕方向切换指令后，便也可相应获知目标屏幕方向，由此可根据目标屏幕方向获取对应的编码和预览配置，此处的编码和预览配置，在本申请的行文中为叙述的使得而统称为编码配置信息。可见，经此步骤的执行，便获得了与目标屏幕方向相对应的编码配置信息。

步骤s12，在维持视频流既有的推流链路的同时，暂停执行对所述视频流的编码，按照所述编码配置信息更新视频流编码所需的相应配置：

在主播端向服务器推送视频流的过程中，维持着一个推流链路，当经编码的视频流源源不断地向服务器上传时，意味着该推流链路持续作用因而得以维持，一旦视频流不再上传，且服务器未能再经推流链路收到主播用户传输的相关数据标记，那么，服务器将视为该推流链路已经中断。因此，本申请可由程序开发人员评估本步骤的实施所用的时间是否影响该推流链路的维持，而灵活考虑在暂停对视频流编码上传给服务器的临时过程中，是否向服务器发送相关数据标记以维持该推流链路。

通常，出于保守的策略，为确保推流链路的维持，本申请推荐在本机设备通过该推流链路向服务器发送心跳包，心跳包作为数据标记供服务器判定推流链路是否继续存在。藉此，通过该推流链路，在主播用户的本机设备和服务器之间定时发送心跳包，可以确保所述推流链路的维持，而不影响本申请的创造精神的实现。

本申请的关键步骤的实现，依赖于所述的推流链路的持续存在，也即是说，在该推流链路得以维持的同时，本申请通过暂停对视频流的编码，重新配置编码所需的编码配置信息，完成这一配置后才重新推送经编码的视频流。

参照图3，对应于本步骤，直播间应用程序在获取编码配置信息后，下达一个stopencoder的指令，通知该应用程序集成的媒体sdk停止对视频流的编码，继而，执行updatepreviewandencodeconfig指令，该指令被构造为用于实现对媒体sdk进行编码所依赖的编码配置信息的重新配置，经此配置，媒体sdk后续对视频流进行编码时，将应用新的分辨率、编码格式、传输码率以及弱网配置信息而实施编码。

可以理解，如果原来媒体sdk是按照1080*1920的画幅分辨率对视频流实施的编码，则经配置后，后续可能改为按照1920*1080的画幅分辨率来进行编码。同理也可理解，任何接收经媒体sdk按照这种方式编码的解码程序，均可根据这一分辨率提供的信息，来识别和确定目标屏幕方向，从而可以对在视频播放窗口播放的视频流的显示布局做适应性的调整(也可不自动调整，视乎应用程序开发逻辑灵活设定)。

由于主播端与服务器之间的推流链路自始至终均得以维持，因此，服务器不会断开其与直播间其他用户之间的推流链路，也不会向其他用户报障，对于其他用户而言，由于推流链路中一直维持着，但没有新的编码视频流到达，因此，此时其图形用户界面的视频播放窗口中通常会显示最后一帧到达的视频流的画面。

步骤s13，重启执行对所述视频流的编码以便向直播间继续推送视频流，以使直播间用户将后续接收的视频流按照目标屏幕方向相适配的布局显示：

请继续结合图3，当应用程序下达指令更新其集成的媒体sdk的编码配置信息之后，通常表现为向某处写入或替换该些编码配置信息，此时便完成了编码配置信息的更新，于是，便可向媒体sdk下达startencoder指令，可以理解，该指令旨在通知媒体sdk按照正常流程，调用所述更新后的编码配置信息对视频流继续执行编码并上传到所述的服务器，使直播间其他用户继续接收到更新编码后的视频流。

对于直播间的观众用户而言，其图形用户界面的视频播放窗口中维持着停止编码前的视频流的最后一帧画面，该画面呈现的布局关于，是与主播用户的本机设备原来所处的屏幕方向(例如横向)相匹配的。

当主播用户上传的更新了编码配置信息的视频流被服务器推送给直播间用户，当这些流信息到达用户侧的直播间应用程序时，该应用程序集成的媒体sdk便可对其进行解码。媒体sdk通过解码所接收的视频流的视频帧，可以获知新的编码配置信息已由原来的例如横向改为当前的纵向，于是，直播间用户便可以根据这一变动，按照新的目标屏幕方向调整相应的布局与之匹配，使得用户侧的视频布局可以基本同步于主播侧。

可以理解，此处所称的目标屏幕方向相适配的布局，不仅可以包括依据编码配置信息中的诸如分辨率之类的信息，对视频流播放时呈现的画幅尺寸做横向或纵向的布局显示，具体如依据分辨率信息改变当前视频播放窗口(也包括视频流画幅)的宽高比或将之横置、纵置等，也可以包括对视频流画幅的尺寸、直播间图形用户界面中与视频流相关的控件的显示方向等的调整，本领域技术人员据此应当可以理解。

进一步可以理解，当重新编码后到达的视频流被显示到视频播放窗口时，实际上便完成了整个切换屏幕方向的过程，这个过程在现实中通常也是较为短暂的，观众侧用户在观看到一幅停留的视频帧的画面之后，很快会适应主播用户的目标屏幕方向而对后续视频流做显示布局的调整，视频播放窗口中的画面没有断开，也没有报错，更不会出现画面拉伸变形，整个过程既稳定又能相对平滑过渡。

需要指出的是，如图3所示，作为直播间应用程序自带的媒体sdk，也一并集成在主播用户一侧，因此，主播用户在其向服务器上传所述重新编码的视频流后，同理也可以在后续的一个步骤中，接收所述服务器回传的视频流，然后将该视频流显示到其图形用户界面的视频播放窗口中，实现主播用户与观众用户的视频内容的同步，由此，可以从主播用户的直播间图形用户界面同步看到执行了本方法之后获得的界面效果。

请再参阅图3，在主播用户侧，当其完成编码配置信息的更新并重新开始编码视频流上传到服务器后，便调用一个指令updateheart向服务器发送所述的心跳包，显然，该心跳包的发送是考虑到经过停止编码、更新编码配置信息、重启编码的整个过程中可能存在导致推流链路断开的风险，而作为保险措施调用执行的。事实上，心跳包可以在步骤s12的整个过程的任意时间节点中触发执行，或者多次执行，均可实现同样的保险效果。

需要再次强调的是，图3仅用于展示程序开发的一种实现逻辑，其中的媒体sdk中实现的各个功能步骤，不宜用于限制本方法解决问题的步骤及其流程，无论是主播用户还是观众用户，其安装的直播间应用程序均可包含该媒体sdk，但是所采用的功能可能不同。按照本申请以上的揭示，图3所示的各个sdk实现的功能，理论上可以在主播用户侧得以完全验证，但考虑到本申请主要解决控制视频流产生并编码推送的问题，因此，其中关于解码视频帧这一功能，也可不在主播用户侧实施调用，但这一解码视频帧的功能却是观众用户侧所必需赖以实施的。

进一步，可以通过将上述各实施例所揭示的方法中的各个步骤进行功能化，构造出本申请的一种直播视频流推送控制装置，按照这一思路，请参阅图4，其中的一个典型实施例中，该装置包括：

切换单元11，用于响应本机设备在直播间推送视频流过程中接收的屏幕方向切换指令，获取与目标屏幕方向相对应的视频流编码配置信息；

控制单元12，用于在维持视频流既有的推流链路的同时，暂停执行对所述视频流的编码，按照所述编码配置信息更新视频流编码所需的相应配置；

重启单元13，用于重启执行对所述视频流的编码以便向直播间继续推送视频流，以使直播间用户将后续接收的视频流按照目标屏幕方向相适配的布局显示。

进一步，为便于本申请的执行，本申请提供一种电子设备，包括中央处理器和存储器，所述中央处理器用于调用运行存储于所述存储器中的计算机程序以执行如前所述的各实施例中所述直播视频流推送控制方法的步骤。

可以看出，存储器适宜采用非易失性存储介质，通过将前述的方法实现为计算机程序，安装到手机之类电子设备中，相关程序代码和数据便被存储到电子设备的非易失性存储介质中，进一步通过电子设备的中央处理器运行该程序，将其从非易性存储介质中调入内存中运行，便可实现本申请所期望的目的。因此，可以理解，本申请的一个实施例中，还可提供一种非易失性存储介质，其中存储有依据所述的直播视频流推送控制方法各个实施例所实现的计算机程序，该计算机程序被计算机调用运行时，执行该方法所包括的步骤。

综上所述，本申请确保网络直播时，即使发生屏幕方向切换的事件，也可保证视频推流链路的稳定，使接收视频流的用户获得更为自然过渡的视频画面。

本技术领域技术人员可以理解，本申请包涉及用于执行本申请中所述操作、方法中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其存储器之内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本申请公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本申请中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本申请中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本申请中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。