CN117857824A - 一种直播进度控制方法、电子设备及服务器 - Google Patents

Abstract

本申请提供一种直播进度控制方法、电子设备及服务器，服务器获取电子设备发送给的直播数据请求，直播数据请求携带有目标延迟时间。服务器根据确定为首播的分片数据时间点与当前时间点计算实际延时时间。如果实际延迟时间大于目标延迟时间，则将丢弃数据之后的分片数据反馈至电子设备。如果实际延迟时间小于或等于目标延迟时间，则将确定的首播的分片数据反馈至电子设备。这样在直播接入过程中，如果实际延迟超过了可以容忍的延时时间，则将首播的分片数据的前N秒丢弃，使得实际延迟时间缩短至小于目标延迟时间，从而保持播放进度稳定，提升直播效果，提升用户使用体验。

Description

一种直播进度控制方法、电子设备及服务器

技术领域

本申请涉及通信技术领域，尤其涉及一种直播进度控制方法、电子设备及服务器。

背景技术

随着网络技术的发展以及终端功能的多样化，人们越来越喜欢通过网络与其他人进行数据共享，例如，人们可以通过终端建立直播房间，并在该直播房间中进行网络直播，其他人可以进入该直播房间，观看直播内容，或与该直播房间的发起者进行互动。

直播数据的传输方式通常为流式传输，即将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，由服务器向客户端连续、实时传送。客户端通过解压软件对这些数据进行解压后，即可在客户端播放视频和音频等多媒体文件。

在视频直播过程中，由于网络环境差等因素可能会造成一定的直播延迟。通常系统会设置可以容忍的目标延迟时间，但是如果直播过程中实际延迟时间大于目标延迟时间，则会造成直播效果较差，导致用户的体验较差。因此亟需一种保持播放进度稳定的方法。

发明内容

本申请提供了一种直播进度控制方法、电子设备及服务器，用于解决如果直播过程中实际延迟时间大于目标延迟时间，则会造成直播效果较差，导致用户的体验较差的问题。

第一方面，本实施例提供一种服务器，所述服务器用于执行：

接收电子设备发送的直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值；

根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据，以及根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间，其中确定的首播的所述分片数据的状态为切片已完成状态；

如果所述实际延迟时间大于所述目标延迟时间，则将确定的首播的所述分片数据的前N秒数据丢弃，以使所述实际延迟时间小于或等于所述目标延迟时间，将丢弃数据之后的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据丢弃数据之后的所述分片数据播放直播视频；

如果所述实际延迟时间小于或等于所述目标延迟时间，则将确定的首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据所述分片数据播放直播视频。

第二方面，本实施例提供一种电子设备，包括：

显示器；

控制器，用于执行：

向服务器发送直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值；

如果实际延迟时间大于所述目标延迟时间，则接收所述服务器反馈的分片数据，以及根据所述分片数据在所述显示器上开始播放直播视频，其中所述分片数据为丢弃数据之后的所述分片数据，所述分片数据为确定的首播的分片数据，丢弃数据以使所述实际延迟时间小于或等于所述目标延迟时间，所述实际延迟时间为根据确定的首播的所述分片数据的时间点与当前时间点计算得到的时间，首播的所述分片数据为根据所述分片数据的时长和已生成的所述分片数据的信息确定的数据；

如果所述实际延迟时间大于所述目标延迟时间，则接收所述服务器反馈的分片数据，以及根据所述分片数据控制在所述显示器上开始播放直播视频。

第三方面，本实施例提供一种直播进度控制方法，所述方法应用于服务器，所述方法包括：

接收电子设备发送的直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值；

根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据，以及根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间，其中确定的首播的所述分片数据的状态为切片已完成状态；

如果所述实际延迟时间大于所述目标延迟时间，则将确定的首播的所述分片数据的前N秒数据丢弃，以使所述实际延迟时间小于或等于所述目标延迟时间，将丢弃数据之后的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据丢弃数据之后的所述分片数据播放直播视频；

如果所述实际延迟时间小于或等于所述目标延迟时间，则将确定的首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据所述分片数据播放直播视频。

本申请实施例提供的直播进度控制方法、电子设备及服务器，服务器获取电子设备发送给的直播数据请求，直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值。服务器根据分片数据的时长和已生成的分片数据的信息确定首播的分片数据，以及根据确定的首播的分片数据的时间点与当前时间点计算实际延时时间，其中确定的首播的分片数据的状态为切片已完成状态。如果实际延迟时间大于目标延迟时间，则将确定的首播的分片数据的前N秒数据丢弃，以使实际延迟时间小于或等于目标延迟时间，将丢弃数据之后的分片数据反馈至电子设备，以使电子设备开始根据丢弃数据之后的分片数据播放直播视频。如果实际延迟时间小于或等于目标延迟时间，则将确定的首播的分片数据反馈至电子设备，以使电子设备开始根据分片数据播放直播视频。这样在直播接入过程中，如果实际延迟超过了可以容忍的延时时间，则将首播的分片数据的前N秒丢弃，使得实际延迟时间缩短至小于目标延迟时间，从而保持播放进度稳定，提升直播效果，提升用户使用体验。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1示出了根据一些实施例的显示设备与控制装置之间操作场景；

图2示出了根据一些实施例的控制设备100的硬件配置框图；

图3示出了根据一些实施例的显示设备200的硬件配置框图；

图4示出了根据一些实施例的显示设备200中软件配置图；

图5示出了根据一些实施例中直播播放分片数据切片原理图；

图6示出了根据一些实施例的直播进度控制系统框架图；

图7示出了根据一些实施例的直播进度控制过程信令图；

图8示出了根据一些实施例中又一种直播播放分片数据切片原理图；

图9示出了根据一些实施例中又一种直播播放分片数据切片原理图；

图10示出了根据一些实施例中又一种直播播放分片数据切片原理图；

图11示出了根据一些实施例中显示设备200提供的用户界面示意图；

图12示出了根据一些实施例中通过丢帧实现缩短实际延迟时间的具体实施流程图；

图13示出了根据一些实施例中通过延迟请求播放实现缩短实际延迟时间的具体实施流程图；

图14示出了根据一些实施例中通过倍速或选时实现缩短实际延迟时间的具体实施流程图；

图15示出了根据一些实施例中通过倍速或选时实现缩短实际延迟时间的具体实施流程图；

图16示出了根据一些实施例中通过倍速或选时实现缩短实际延迟时间的具体实施流程图；

图17示出了根据一些实施例中又一种直播进度控制系统框架示意图；

图18示出了根据一些实施例中直播进度控制方法流程图。

具体实施方式

为使本申请一些实施例的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请一些实施例技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。

需要说明的是，本申请一些实施例中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请一些实施例的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

本申请一些实施例中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换。

术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，举例来说，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

本申请中访问的术语“遥控器”，是指显示设备(如本申请中公开的显示设备)的一个组件，通常可在较短的距离范围内无线控制显示设备。一般访问红外线和/或射频(RF)信号和/或蓝牙与显示设备连接，也可以包括WiFi、无线USB、蓝牙、动作传感器等功能模块。举例来说：手持式触摸遥控器，是以触摸屏中用户界面取代一般遥控装置中的大部分物理内置硬键。

本申请中的电子设备可以是显示设备，也可以是其他具有语音助手功能的电子设备，以下以显示设备为示例进行方案的阐述。图1为本申请一些实施例提供的显示设备与终端设备之间操作场景的示意图。如图1中示出，用户可通过移动终端300和终端设备100操作显示设备200。

在一些实施例中，终端设备100可以是遥控器，遥控器和显示设备的通信包括红外协议通信或蓝牙协议通信，及其他短距离通信方式等，通过无线方式或其他有线方式来控制显示设备200。用户可以通过遥控器上按键，语音输入、控制面板输入等输入用户指令，来控制显示设备200。

在一些实施例中，移动终端300可与显示设备200安装软件应用，通过网络通信协议实现连接通信，实现一对一控制操作和数据通信的目的。也可以将移动终端300上显示音视频内容传输到电子设备200上，实现同步显示功能。

如图1中还示出，显示设备200还与服务器400通过多种通信方式进行数据通信。可允许显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。

显示设备200除了提供广播接收电视功能之外，还可以附加提供计算机支持功能的智能网络电视功能，包括但不限于，网络电视、智能电视、互联网协议电视(IPTV)等。

图2为本申请一些实施例提供的图1中显示设备200的硬件配置框图。

在一些实施例中，显示设备200包括调谐解调器210、通信器220、检测器230、外部装置接口240、控制器250、显示器260、音频输出接口270、存储器、供电电源、用户接口中的至少一种。

在一些实施例中，检测器230用于采集外部环境或与外部交互的信号。

在一些实施例中，显示器260包括用于呈现画面的显示屏组件，以及驱动图像显示的驱动组件，用于接收源自控制器输出的图像信号，进行显示视频内容、图像内容以及菜单操控界面的组件以及用户操控UI界面等。

在一些实施例中，通信器220是用于根据各种通信协议类型与外部设备或服务器400进行通信的组件。

在一些实施例中，控制器250，通过存储在存储器上中各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250控制显示设备200的整体操作。

在一些实施例中，用户可在显示器260上显示的图形用户界面(GUI)输入用户命令，则用户输入接口通过图形用户界面(GUI)接收用户输入命令。

在一些实施例中，用户接口280，为可用于接收控制输入的接口。

图3为本申请一些实施例提供的图1中终端设备的硬件配置框图。如图3所示，终端设备100包括控制器111、通信接口130、用户输入/输出接口、存储器、供电电源。

终端设备100被配置为控制显示设备200，以及可接收用户的输入操作指令，且将操作指令转换为显示设备200可识别和响应的指令，起到用户与显示设备200之间交互中介作用。

在一些实施例中，终端设备100可是一种智能设备。如：终端设备100可根据用户需求安装控制显示设备200的各种应用。

在一些实施例中，如图1所示，移动终端300或其他智能显示设备，可在安装操控显示设备200的应用之后，可以起到终端设备100类似功能。

控制器111包括处理器112和RAM 113和ROM 114、通信接口130以及通信总线。控制器111用于控制终端设备100的运行和操作，以及内部各部件之间通信协作以及外部和内部的数据处理功能。

通信接口130在控制器111的控制下，实现与显示设备200之间控制信号和数据信号的通信。通信接口130可包括WiFi芯片131、蓝牙模块132、NFC模块133等其他近场通信模块中至少之一种。

用户输入/输出接口140，其中，输入接口包括麦克风141、触摸板142、传感器143、按键144等其他输入接口中至少一者。

在一些实施例中，终端设备100包括通信接口130和输入输出接口140中至少一者。终端设备100中配置通信接口130，如：WiFi、蓝牙、NFC等模块，可将用户输入指令通过WiFi协议、或蓝牙协议、或NFC协议编码，发送至显示设备200。

存储器190，用于在控制器的控制下存储驱动和控制终端设备100的各种运行程序、数据和应用。存储器190，可以存储用户输入的各类控制信号指令。

供电电源180，用于在控制器的控制下为终端设备100各元件提供运行电力支持。

图4为本申请一些实施例提供的图1中显示设备中软件配置示意图，在一些实施例中，将系统分为四层，从上至下分别为应用程序(Applications)层(简称“应用层”)、应用程序框架(Application Framework)层(简称“框架层”)、安卓运行时(Android runtime)和系统库层(简称“系统运行库层”)，以及内核层。

在一些实施例中，应用程序层中运行有至少一个应用程序，这些应用程序可以是操作系统自带的窗口(Window)程序、系统设置程序、时钟程序、相机应用等；也可以是第三方开发者所开发的应用程序。

框架层为应用程序层的应用程序提供应用编程接口(Aplication PogrammingIterface，API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层相当于一个处理中心，这个中心决定让应用层中的应用程序做出动作。

如图4所示，本申请一些实施例中应用程序框架层包括管理器(Managers)、内容提供者(Content Provider)和视图系统(View System)等。

在一些实施例中，活动管理器用于：管理各个应用程序的生命周期以及通常的导航回退功能。

在一些实施例中，窗口管理器用于管理所有的窗口程序。

在一些实施例中，系统运行库层为上层即框架层提供支撑，当框架层被访问时，安卓操作系统会运行系统运行库层中包含的C/C++库以实现框架层要实现的功能。

在一些实施例中，内核层是硬件和软件之间的层。如图4所示，内核层至少包含以下驱动中的至少一种：音频驱动、显示驱动、蓝牙驱动、摄像头驱动、WIFI驱动、USB驱动、HDMI驱动、传感器驱动(如指纹传感器，温度传感器，触摸传感器、压力传感器等)等。

在一些实施例中，内核层还包括用于进行电源管理的电源驱动模块。

在一些实施例中，图4中的软件架构对应的软件程序和/或模块存储在图2或图3所示的第一存储器或第二存储器中。

直播数据的传输方式可以是流式传输，即将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，由服务器向客户端连续、实时传送。客户端通过解压软件对这些数据进行解压后，即可在客户端播放视频和音频等多媒体文件。

根据视频编解码特点，一个编解码序列由一个关键帧和若干参考帧组成，参考帧必须依赖关键帧才能完成解码，所以播放器必须以一个关键帧作为解码的起始位置，否则参考帧无法正常解码，而一个编解码序列的长度从几百毫秒到几秒不等。启动播放时如何选择合适的起始下载位置，直接影响了播放出首帧画面的时长和播放启动后的延迟时长。

在一些实施例中，在视频直播过程中，由于网络环境差等因素可能会造成一定的直播延迟。通常系统会设置可以容忍的目标延迟时间，但是如果直播过程中实际延迟时间大于目标延迟时间，则会造成直播效果较差，导致用户的体验较差。

例如，图5所示的直播播放分片数据切片原理图，在当前时间点分片1、分片2以及分片3已经在服务器生成分片文件，即分片1、分片2以及分片3在当前时间点的状态均为切片已完成状态。当前时间点即向服务器请求直播数据的时间点。此时由于分片4的状态为切片未完成状态，即在服务器切片4的数据还未完成，只能将分片3确定为首次获取的分片文件。因此在当前时间点只能从分片3开始播放，如果从分片3开始播放，则实际延迟时间为8秒。如果目标延迟时间为5秒，即系统设置的用户可容忍的延迟时间为5秒，此时实际延迟时间大于目标延时时间，则会造成直播效果较差，用户观看体验较差。

为了解决上述实施例中的问题，本申请实施例提供一种直播进度控制方法，本申请实施例提供的训练课程提示方法可以应用于图6所示的系统。如图6所示，该系统中可以包括：服务器400和用户使用的显示设备200。其中，服务器400举例来说可以是云服务器、分布式服务器等任意形式的数据处理服务器。服务器400可以执行本申请实施例训练课程提示方法，以向使用显示设备200的用户展示提示信息。

如图7所示的信令图，图7所示信令图中的方法应用于图6所示的系统，在该信令图中，显示设备200接收到用户输入直播数据请求指令，根据该指令向服务器400发送直播数据请求。这里可以是用户在显示设备通过点击直播控件输入的直播数据请求指令。直播数据请求携带有目标延迟时间。延迟时间具体的为首播的分片数据时间点至当前时间点的时间差值。例如图5所示实施例中的首播的分片数据为分片3，首播的分片数据时间点到当前时间点的延迟时间为8秒。本申请中延迟时间包括目标延迟时间和实际延迟时间，目标延迟时间为系统保存的延迟时间阈值，实际延迟时间为直播过程中直播数据实际的延迟时间。

这里目标延迟时间可以是系统根据经验自动设置的延迟时间。也可以是用户在系统中设置的延迟时间。例如为了体验更好的直播观看体验，用户可以在目标延迟时间设置栏中选择较小值的目标延迟时间，在观看直播时通过较小的目标延迟时间调整实际延迟时间。然而调整实际延迟时间也需要占用计算资源，为了避免占用较多的计算资源，用户也可以在目标延迟时间设置栏中该选择较大值的目标延迟时间。这样实际延迟时间可以在较大的范围内波动。

服务器400接收到直播数据请求之后，根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据，以及根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间，其中确定的首播的所述分片数据的状态为切片已完成状态。本申请中只有状态为已完成的分片数据，服务器400才能够反馈至显示设备200。

如果所述实际延迟时间大于所述目标延迟时间，则服务器400将确定的首播的所述分片数据的前N秒数据丢弃。丢弃前N秒数据之后，实际延迟时间则会小于或等于所述目标延迟时间。即将实际延迟时间更改在目标延迟时间范围之内。之后服务器400将丢弃数据之后的所述分片数据反馈至所述显示设备200。显示设备200开始根据丢弃数据之后的所述分片数据播放直播视频。这里显示设备200开始根据丢弃数据之后分片数据播放直播视频指的是，从丢弃数据之后的分片数据开始按照该分片数据之后的分片数据依次播放对应的视频数据。

如果所述实际延迟时间小于或等于所述目标延迟时间，则将服务器400将确定的首播的所述分片数据反馈至所述显示设备200，以使所述显示设备200开始根据所述分片数据播放直播视频。

举例来说，如图8所示的直播播放分片数据切片原理图中，分片数据的时长为5秒，服务器400接收到显示设备200发送的直播数据请求时，已经切片完成的分片为分片1、分片2以及分片3，并且分片4已经生成3秒的数据。根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据为分片3。根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间为8秒。如果目标延迟时间为10秒，则实际延迟时间小于目标延迟时间，则服务器400可以直接将分片3反馈至显示设备200，显示设备200则根据分片3播放直播视频。即显示设备200从分片3的开始时间开始播放直播视频。

如果目标延迟时间为5秒，则实际延迟时间大于目标延迟时间，则服务器400可以将分片3前3秒的数据丢弃，并将丢弃数据后的分片3反馈至显示设备200。即显示设备200从分片3的第4秒开始播放直播视频。这样可以将实际延迟时间从8秒缩短至5秒，使得实际延迟时间在目标延迟时间的范围之内。服务器400也可以将分片3前4秒的数据丢弃，并将丢弃数据后的分片3反馈至显示设备200。即显示设备200从分片3的第5秒开始播放直播视频。这样可以将实际延迟时间从8秒缩短至4秒，同样使得实际延迟时间在目标延时时间范围之内。上述实施例的缩短实际延迟时间的方法为丢帧。

本申请中对分片数据丢帧处理可以是在服务器400进行的，也可以是在显示设备200中进行的。具体的服务器400将完整的分片数据反馈至显示设备200之后，显示设备200将完整分片中的部分数据丢弃之后，从丢弃数据之后的数据开始时间点播放直播视频。

举例来说，图8所示的事例中，服务器400可以将分片3完整的反馈至显示设备200。显示设备200接收到完整的分片3之后，将前3秒的数据丢弃，即显示设备200不播放分片3前3秒的数据，而是从分片3的第4秒开始播放直播视频。这样也可以将实际延迟时间从8秒缩短至5秒，使得实际延迟时间在目标延迟时间的范围之内。

在一些实施例中，确定的首播的分片数据的状态为已完成状态，而确定的首播的所述分片数据的下一分片数据的状态为切片未完成状态，此时所述服务器还可用于执行：如果所述实际延迟时间大于所述目标延迟时间，则在当前时间点等待确定的首播的所述分片数据的下一片所述分片数据切片完成之后，将确定的首播的所述分片数据的下一片所述分片数据重新确定为首播的所述分片数据，以及将重新确定为首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据重新确定为首播的所述分片数据播放直播视频。上述实施例的缩短实际延迟时间的方法为延迟请求播放的方法。

举例来说，如图9所示的又一种直播播放分片数据切片原理图中，服务器400接收到显示设备200发送的直播数据请求时，已经切片完成的分片为分片1、分片2以及分片3，并且分片4已经生成3秒的数据。根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据为分片3。根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间为8秒。

如果目标延迟时间为5秒，则实际延迟时间大于目标延迟时间。服务器400可以等待分片4切片完成，即等待2秒。服务器400在等待的过程中不向显示设备200发送数据。当分片4切片完成，服务器400再将分片4的数据反馈至显示设备200。显示设备200即从分片3的开始时间开始播放直播视频。此时从图9可以得出，实际延迟时间更改为5秒在目标延迟时间的范围内。

在一些实施例中，确定首播的所述分片数据的过程中，所述服务器用于执行：获取所述分片数据的时长和目标延迟时间，如果所述目标延迟时间与所述分片数据的时长的除值M大于1，则将在已完成切片的所述分片数据中排序倒数第M个的分片数据确定为首播的所述分片数据；如果所述目标延迟时间与所述分片数据的时长的除值M小于或等于1，则将在已完成切片的所述分片数据中排序倒数第1个的分片数据确定为首播的所述分片数据。

举例来说，图5所示的直播播放分片数据切片原理图，在当前时间点分片1、分片2以及分片3已经在服务器生成分片文件，即分片1、分片2以及分片3在当前时间点的状态均为切片已完成状态，而分片4的状态为切片未完成状态。本实施例中目标延迟时间为10秒。本申请可以采用基于最新播放基点倒排的方式确定首播的分片数据。具体的将目标延迟时间10s除以分片数据时长5s，10秒/5秒＝2，即从已下载数据的分片文件中的倒数第2个分片文件开始下载数据进行播放。在图5中，分片1、分片2、分片3以及分片4已下载数据，分片3为倒数第2个分片，则将分片3确定为首播的分片数据。分片3的开始时间点至当前时间点之间的时间差即为实际延迟时间。

在一些实施例中，如果目标延迟时间较小，通过延迟请求播放的方法缩短实际延迟时间不能够实现将实际延迟时间缩短至小于目标延迟时间的目的，而通过丢帧的方法缩短实际延迟时间，可能需要丢弃较多的数据造成用户错过观看比较观看的时段。本实施例可以采用倍速播放的方法缩短实际延迟时间，即通过追赶进度的方法缩短实际延迟时间。

举例来说，如图10所示的又一种直播播放分片数据切片原理图中，服务器400接收到显示设备200发送的直播数据请求时，已经切片完成的分片为分片1、分片2以及分片3，并且分片4已经生成3秒的数据。根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据为分片3。根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间为8秒。如果目标延迟时间为3秒，如果采用延迟请求播放的方法以缩短实际延迟时间，服务器400只等待分片4切片完成即反馈数据，缩短后的实际延迟时间为5秒，则实际延迟时间仍然大于目标延迟时间。

如果采用丢帧的方法以缩短实际延迟时间，服务器400需要将分片3的内容整个丢弃，才能使得实际延迟时间在目标延迟时间范围之内。如果采用倍速的方法，服务器400具体的将分片3的数据反馈至显示设备200之后，显示设备200以1.5倍速播放已经获取的直播文件，只需要2.5秒即可播放完分片3的数据。此时分片4也切片完成，接着显示设备200从服务器400获取分片4的数据，显示设备200继续以1.5倍速播放分片4的数据。同样的只需要2.5秒即可播放完分片4的数据。此时播放进度向前提起了5秒的内容，实际延迟时间即从8秒缩短至3秒，实现将实际延迟时间控制在目标延迟时间的范围之内的目的。

在一些实施例中，如果目标延迟时间较小，通过延迟请求播放的方法缩短实际延迟时间不能够实现将实际延迟时间缩短至小于目标延迟时间的目的，而通过丢帧的方法缩短实际延迟时间，可能需要丢弃较多的数据造成用户错过观看比较观看的时段。本实施例可以采用选时播放的方法缩短延迟时间，即同样通过追赶进度的方法缩短实际延迟时间。与倍速播放的方法不同的是，倍速播放时加快直播视频播放速度，本实施例是通过跳转播放的方法，即直接跳转至当前时间点之后的某个时间点，从而缩短实际延迟时间。

举例来说，如图10所示的示例中，如果目标延迟时间为4秒，如果采用延迟请求播放的方法以缩短实际延迟时间，服务器400只等待分片4切片完成即反馈数据，缩短后的实际延迟时间为5秒，则实际延迟时间仍然大于目标延迟时间。如果采用丢帧的方法以缩短实际延迟时间，服务器400需要将分片3的大部分内容丢弃，才能使得实际延迟时间在目标延迟时间范围之内。如果采用选时播放的方法，服务器400具体的将分片3的数据反馈至显示设备200之后，正常播放之后，在当前时间点跳转至被选定的跳转时间点继续进行直播数据的播放，例如跳转至分片4的第2秒进行播放，从而将实际延迟时间缩短至1秒。需要说明的是，选时播放的方法应用的前提是服务器缓存的数据满足跳转需求。

在一些实施例中，如果服务器支持低延迟播放，例如满足CMFA(Common MediaApplication Format，通用媒体应用程序格式)标准，这种格式定义了一种碎片化的MP4容器，其中可以封装视频、音频及文本数据。该格式最大的特点在于能够降低直播时的延迟时间。如果服务器支持CMFA格式的直播数据播放，则在编码切片完成既可以同步发送分片文件已完成编码的部分内容，例如发送chunk块中的内容。如果按照上述计算首播的分片数据的方法，需要从倒数第一个分片文件开始下载，此时到处第1个分片文件可能刚生成1秒的内容，因此实际延迟播放时间为1秒，符合小于目标延迟时间3秒的要求。

上述实施例均为直播接入过程中延迟时间控制的过程。在直播播放过程中也可能会由于网络播放、服务终端等因素造成播放进度发送偏离，即产生较大的实际延迟时间，因此可能也需要实时的对播放进度进行监控并及时干预，使播放延迟时间恢复到目标延迟时间之内。具体的，可以获取播放状态和指标：目标延迟时间、允许的播放速率、播放延迟时间、播放缓存时间、下载缓存大小、最小缓存时间、安全缓存时间、当前播放码率、用户网络带宽等。

其中，目标延迟时间和允许的播放速率从服务器提供的manifest(播放配置文件)中直接获取。播放延迟时间为最新直播时间与前播放时间的差值。播放缓存时间＝解封装完成的最后一包数据的时间戳–当前播放时间+下载缓存大小/当前播放码率。下载缓存大小可以直接从下载模块获取，其是没有进行解封装的已经下载到终端的数据。最小缓存时间和安全缓存时间由播放器设定(低于最小缓存时间时可能发生播放卡顿，高于安全缓存时间时表明数据足够、播放稳定)。当前播放码率直接从下载模块获取，它是正在下载的分片文件的播放码率档位。用户网络带宽从网络带宽估算模块获取，它表示终端某一时刻的网络状态。播放过程中给的延迟控制方法可以采用上述实施例中的，倍速播放方法和选时播放方法，具体的控制过程可以参见播放接入过程实施例中的阐述，本实施例不再赘述。

在进行播放码率的切换过程中，因为要根据播放位置重新请求新的播放码率对应的媒体文件，此时会加大播放延迟，虽然很多播放方案支持了无缝码率切换，但仍然可能因为选择不合适的码率(比如选择高于自己带宽的码率)而引起卡顿，进而加大播放延迟。因此在切换播放码率时，也需要对延迟时间进行控制。具体的控制过程可以参见播放接入过程实施例中的阐述，本实施例不再赘述。

在一些实施例中，在直播数据接入的过程中，如果实际延迟时间超出目标延迟时间，可以提示用户采用何种方法缩短实际延迟时间。

举例来说，如图11所示的用户界面中，用户点击直播1的开始控件之后，显示设备200监测到此时实际延迟时间超出目标延迟时间，则在界面中弹出提示对话框。该提示对话框中包括提示信息“当前延迟时间较差，请选择缩短延时时间方式”，还包括“丢帧”控件和“等待”控件。如果用户选择“丢帧”控件，显示设备200接收到用户输入的指令后，直接向服务器400请求数据。服务器400接收到请求后，向显示设备200反馈丢帧后的数据，从而实现缩短实际延迟时间的目的。如果用户选择“等待”控件，显示设备200接收到用户输入的指令后，并不直接向服务器400请求数据，而是等待一段时间(等待的时间计算方法参见上述实施例)之后，才向服务器400发送数据请求。服务器400接收到请求后，向显示设备200反馈分片数据。

如图12所示的流程图，通过丢帧实现缩短实际延迟时间的具体实施过程可以如下所示：

下载直播视频的配置文件，配置文件中包含了分片文件列表，以及每个分片文件的播放时长，起始位置等信息，另外还包含了设置的目标延迟时间等信息。根据配置文件中分片文件的播放时长和目标播放延迟时间，计算起始下载分片位置，其中起始下载位置对应的分片的计算方法：(当前时间-直播起始时间–目标延迟时间)/分片播放时长。

根据目标播放延迟时间计算起始播放点，其中起始播放点的计算方法：当前时间-直播起始时间-目标延迟时间。启动播放器，并将起始播放点写入播放器，其中起始播放点是播放器开始播放时出现的第一帧画面的播放时间，下载数据的位置包含起始播放点位置，比起始播放点更早，即下载的数据有冗余。依次顺序下载分片文件并将数据写入播放器。播放器开始对数据进行解码，其中播放器解码必须从关键帧开始，通常分片文件都是以关键帧开始的，因此从分片文件的开始位置下载数据并发送给播放器。判断解码后的数据的时间戳是否小于起始播放点，如果解码后的数据的时间戳大于或等于起始播放点，则将解码后的数据传入渲染模块，进行渲染输出。如果解码后的数据的时间戳小于起始播放点，则丢弃该部分数据之后，将解码后的数据传入渲染模块，进行渲染输出。其中解码后的数据是以帧(一般几十毫秒)为单位，每帧数据都有时间戳，且不再有前后帧依赖关系，相对独立，可以直接渲染。

如图13所示的流程图，通过延迟请求播放实现缩短实际延迟时间的具体实施过程可以如下所示：

下载直播视频的配置文件，配置文件中包含了分片文件列表，以及每个分片文件的播放时长，起始位置等信息，另外还包含了设置的目标延迟时间等信息。计算即将生成的分片还需等待多久，等待时间的计算方法：配置文件中最后一个分片的起始位置+它的播放时长*2-当前时间。判断当前等待时间是否到达，如果等待时间到达，则启动播放器，依次顺序下载分片文件并将数据写入播放器。播放器开始对数据进行解码，将解码后的数据传入渲染模块，进行渲染输出。如果等待时间未到达，则继续等待等待时间，直至等待时间到达之后，启动播放器，依次顺序下载分片文件并将数据写入播放器。

如图14所示的流程图，图15所示的流程图以及图16所示的流程图，通过倍速或选时播放实现缩短实际延迟时间的具体实施过程可以如下所示，其中图15所示的流程为图14所示的流程中判断播放延迟时间未超出目标延迟时间*200％之后的步骤。图16所示的流程为图15所示的流程中判断播放延迟时间超出目标延迟时间*110％之后的步骤。

在直播视频播放过程中，计算播放延迟时间，其中播放延迟时间的计算方法：当前时间-当前播放时间点。计算播放缓存时间，其中播放缓存时间的计算方法：下载缓存中数据量/当前播放码率+最后一包解封装的数据包时间戳-当前播放时间点。如果播放延迟时间超出目标延迟时间*200％，如果正在等待播放选时结束，则根据目标延迟时间计算选时播放的时间点，之后通知播放器进行选时播放。这样可以避免反复多次选时加剧卡顿，导致无法达到稳定状态，而如果通过速率播放需要相当长时间才能达到稳定状态，此时通过选时可以快速达到目标状态。其中选时播放时间点的计算方法：当前时间-目标播放延迟。如果播放延迟时间未超出目标延迟时间*200％，且播放延迟时间超出目标延迟时间*110％，为播放落后状态，此时播放延迟时间低于预期，大于目标延迟时间的110％，需要追赶进度。则继续判断播放缓存是否大于安全缓存大小。如果播放缓存大于安全缓存大小，且不是正在进行速率(快进)播放，则通知播放器进行速率(快进)播放。如果播放缓存大于安全缓存大小，且正在进行速率(快进)播放，同时播放缓存小于最小缓存大小，则通知播放器恢复正常速度播放。这是由于如果进度追赶时播放缓存不足，为避免卡顿，需要停止追赶过程。

如果播放延迟时间未超出目标延迟时间*200％，且播放延迟时间未超出目标延迟时间*110％，同时播放延迟时间低于目标延迟时间*90％，此种情况为激进状态，此时播放延迟时间超出预期，小于目标延迟时间的90％，需要减缓进度，此时需要继续判断是否正在进行速率(慢进)播放。如果未进行速率(慢进)播放，则通知播放器进行速率(慢进)播放。如果播放延迟时间未超出目标延迟时间*200％，且播放延迟时间未超出目标延迟时间*110％，同时播放延迟时间未低于目标延迟时间*90％，此时需要判断是否正在进行速率播放且播放延迟时间在目标延迟时间±5％范围内，如果正在进行速率播放且播放延迟时间在目标延迟时间±5％范围内，则通知播放器恢复正常速度播放。这是由于如果播放进度处于稳定状态(目标状态)，此时播放延迟时间落在目标延迟时间±5％范围内。

如图17所示的流程图，本申请涉及系统框架如下所示，其中浅灰色箭头表示数据流，深灰色箭头表示控制流。本申请的系统包括数据下载模块、带宽估算模块、带宽选择模块、播放器、播放控制等几个模块，数据下载模块负责通过网络协议从网络下载播放配置文件和播放媒体文件，带宽估算模块统计从数据下载模块流向播放器的数据流量情况计算用户的网络带宽，带宽自适应模块根据用户网络带宽选择合适的分片文件并通知下载模块进行下载，播放器负责数据缓存的解封装、解码播放，播放控制模块负责搜集各模块的状态，并对播放器进行干预和控制。

具体的播放控制模块根据用户网络带宽、分片信息等参数对直播数据的播放开始时间、播放速率、播放选时进行控制。播放器根据播放控制模块反馈的参数，进行数据缓存、数据解封装、数据帧缓存、数据解码、数据渲染等操作。同时播放器还向播放控制模块反馈当前的直播数据的播放时间、播放状态、播放缓存时长、最小播放缓存时长、安全播放缓存时长等数据。播放控制模块同时结合播放器反馈的数据进一步调整数据播放参数。

本申请提供一种直播进度控制方法。图18是根据一示例性实施例示出的一种直播进度控制方法的流程图。该直播进度控制方法适用于图1所示实施环境的服务器400。如图18所示，该直播进度控制方法方法，可以包括以下步骤：

在步骤S101中，接收电子设备发送的直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值。

在步骤S102中，根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据，以及根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间，其中确定的首播的所述分片数据的状态为切片已完成状态；

在步骤S103中，如果所述实际延迟时间大于所述目标延迟时间，则将确定的首播的所述分片数据的前N秒数据丢弃，以使所述实际延迟时间小于或等于所述目标延迟时间，将丢弃数据之后的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据丢弃数据之后的所述分片数据播放直播视频。

在步骤S104中，如果所述实际延迟时间小于或等于所述目标延迟时间，则将确定的首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据所述分片数据播放直播视频。

在一些实施例中，如果所述动作评分大于所述第二分数阈值，则向所述显示设备反馈第三提示信息，以使在所述显示设备上展示所述第三提示信息，其中所述第三提示信息用于提示用户可继续跟练当前训练课程且不需要调整动作以提高所述动作评分。

在一些实施例中，确定的首播的所述分片数据的下一分片数据的状态为切片未完成状态，所述方法还可包括：

如果所述实际延迟时间大于所述目标延迟时间，则在当前时间点等待确定的首播的所述分片数据的下一片所述分片数据切片完成之后，将确定的首播的所述分片数据的下一片所述分片数据重新确定为首播的所述分片数据，以及将重新确定为首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据重新确定为首播的所述分片数据播放直播视频。

在一些实施例中，确定首播的所述分片数据的过程中，所述方法具体包括：

获取所述分片数据的时长和目标延迟时间，如果所述目标延迟时间与所述分片数据的时长的除值M大于1，则将在已完成切片的所述分片数据中排序倒数第M个的分片数据确定为首播的所述分片数据；

如果所述目标延迟时间与所述分片数据的时长的除值M小于或等于1，则将在已完成切片的所述分片数据中排序倒数第1个的分片数据确定为首播的所述分片数据。

本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“控制器”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。举例来说，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (10)

1.一种服务器，其特征在于，所述服务器用于执行：

接收电子设备发送的直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值；

根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据，以及根据确定为首播的所述分片数据的时间点与当前时间点计算实际延时时间，其中确定为首播的所述分片数据的状态为切片已完成状态；

如果所述实际延迟时间大于所述目标延迟时间，则将确定为首播的所述分片数据的前N秒数据丢弃，以使所述实际延迟时间小于或等于所述目标延迟时间，将丢弃数据之后的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据丢弃数据之后的所述分片数据播放直播视频；

如果所述实际延迟时间小于或等于所述目标延迟时间，则将确定的首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据所述分片数据播放直播视频。

2.根据权利要求1所述的服务器，其特征在于，确定的首播的所述分片数据的下一分片数据的状态为切片未完成状态，所述服务器还可用于执行：

如果所述实际延迟时间大于所述目标延迟时间，则在当前时间点等待确定首播的所述分片数据的下一片所述分片数据切片完成之后，将确定为首播的所述分片数据的下一片所述分片数据重新确定为首播的所述分片数据，以及将重新确定为首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据重新确定为首播的所述分片数据播放直播视频。

3.根据权利要求1所述的服务器，其特征在于，所述服务器用于执行：

获取所述分片数据的时长和目标延迟时间，如果所述目标延迟时间与所述分片数据的时长的除值M大于1，则将在已完成切片的所述分片数据中排序倒数第M个的分片数据确定为首播的所述分片数据；

如果所述目标延迟时间与所述分片数据的时长的除值M小于或等于1，则将在已完成切片的所述分片数据中排序倒数第1个的分片数据确定为首播的所述分片数据。

4.根据权利要求1所述的服务器，其特征在于，所述服务器还用于执行：

如果所述实际延迟时间超出所述目标延迟时间的时间值大于延迟阈值，则根据所述目标延迟时间计算选时播放时间点，以及将所述选时播放时间点的所述分片数据反馈至所述电子设备，以使所述电子设备跳转至开始根据所述选时播放时间点的所述分片数据播放直播视频，其中所述延时阈值为允许的所述实际延迟时间超出所述目标延迟时间的最大值。

5.根据权利要求4所述的服务器，其特征在于，所述服务器还用于执行：

如果所述实际延迟时间超出所述目标延迟时间的时间值小于或等于所述延迟阈值，则向所述电子设备反馈分片数据的同时反馈快进播放指令，以使所述电子设备根据所述快进播放指令根据所述分片数据快进播放直播视频。

6.一种电子设备，其特征在于，包括：

显示器；

控制器，用于执行：

向服务器发送直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值；

如果实际延迟时间大于所述目标延迟时间，则接收所述服务器反馈的分片数据，以及根据所述分片数据在所述显示器上开始播放直播视频，其中所述分片数据为丢弃数据之后的所述分片数据，所述分片数据为确定的首播的分片数据，丢弃数据以使所述实际延迟时间小于或等于所述目标延迟时间，所述实际延迟时间为根据确定的首播的所述分片数据的时间点与当前时间点计算得到的时间，首播的所述分片数据为根据所述分片数据的时长和已生成的所述分片数据的信息确定的数据；

如果所述实际延迟时间大于所述目标延迟时间，则接收所述服务器反馈的分片数据，以及根据所述分片数据控制在所述显示器上开始播放直播视频。

7.根据权利要求6所述的电子设备，其特征在于，确定为首播的所述分片数据的下一分片数据的状态为切片未完成状态，所述控制器还可用于执行：

如果确定为首播的所述分片数据的下一分片数据的状态为切片未完成状态，则在当前时间点等待确定的首播的所述分片数据的下一片所述分片数据切片完成之后，从所述服务器接收重新确定为首播的所述分片数据，以及根据重新确定为首播的所述分片数据控制在所述显示器上开始直播视频，其中重新确定为首播的所述分片数据为确定的首播的所述分片数据的下一片所述分片数据。

8.一种直播进度控制方法，其特征在于，所述方法应用于服务器，所述方法包括：

接收电子设备发送的直播数据请求，其中所述直播数据请求携带有目标延迟时间，延迟时间为首播的分片数据时间点至当前时间点的时间差值；

根据所述目标延迟时间和已生成的所述分片数据的信息确定首播的所述分片数据，以及根据确定的首播的所述分片数据的时间点与当前时间点计算实际延时时间，其中确定的首播的所述分片数据的状态为切片已完成状态；

如果所述实际延迟时间大于所述目标延迟时间，则将确定的首播的所述分片数据的前N秒数据丢弃，以使所述实际延迟时间小于或等于所述目标延迟时间，将丢弃数据之后的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据丢弃数据之后的所述分片数据播放直播视频；

如果所述实际延迟时间小于或等于所述目标延迟时间，则将确定的首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据所述分片数据播放直播视频。

9.根据权利要求8所述的直播进度控制方法，其特征在于，确定的首播的所述分片数据的下一分片数据的状态为切片未完成状态，所述方法还可包括：

如果所述实际延迟时间大于所述目标延迟时间，则在当前时间点等待确定的首播的所述分片数据的下一片所述分片数据切片完成之后，将确定的首播的所述分片数据的下一片所述分片数据重新确定为首播的所述分片数据，以及将重新确定为首播的所述分片数据反馈至所述电子设备，以使所述电子设备开始根据重新确定为首播的所述分片数据播放直播视频。

10.根据权利要求8所述的服务器，其特征在于，确定首播的所述分片数据的过程中，所述方法具体包括：

获取所述分片数据的时长和目标延迟时间，如果所述目标延迟时间与所述分片数据的时长的除值M大于1，则将在已完成切片的所述分片数据中排序倒数第M个的分片数据确定为首播的所述分片数据；

如果所述目标延迟时间与所述分片数据的时长的除值M小于或等于1，则将在已完成切片的所述分片数据中排序倒数第1个的分片数据确定为首播的所述分片数据。