CN115604496A - 一种显示设备、直播切台方法及存储介质 - Google Patents

Abstract

本申请一些实施例提供一种显示设备、直播切台方法及存储介质，该显示设备包括控制器，控制器被配置为在直播时响应于将第一直播源切换为第二直播源的切台指令，同时获取第二直播源对应的HLS数据和组播数据，并控制显示器对第二直播源对应的组播数据进行播放，在组播数据与HLS数据的数据帧对齐的情况下，停止获取组播数据，继续播放HLS数据。在切台时通过同时获取HLS数据和组播数据，并在组播数据与HLS数据的数据帧对齐之前先播放组播数据，可以解决显示设备在切台后获取HLS数据所带来的播放延迟和卡顿问题，从而提升用户的观看体验。

Description

一种显示设备、直播切台方法及存储介质

技术领域

本申请涉及视频直播技术领域，尤其涉及一种显示设备、直播切台方法及存储介质。

背景技术

显示设备是指能够输出显示画面的设备，可以包括智能电视、通信终端等。随着因特网的快速发展，显示设备的功能也越来越丰富，例如：显示设备可以基于因特网应用技术，实现网络直播或者网络点播等功能。为了应对因特网有限的带宽，媒体产生端在网上发布的各种音视频节目主要采用流媒体技术，也就是传统的音视频文件会转换为像水流一样的流媒体文件，从而使得显示设备可以边下载边播放，无需全部下载整个文件后再进行播放。

流媒体文件在传输时可以采用基于超文本传输协议(Hyper Text TransferProtocol，HTTP)的自适应码率流媒体传输协议(Http Live Streaming，HLS)，HLS主要是将整个流媒体文件分成多个传输流(Transport Stream，TS)分片文件，以供显示设备进行下载和播放。然而，在利用显示设备播放任一频道的直播时，为了避免该频道的HLS数据的最新TS分片文件未就绪所带来的播放卡顿的问题，显示设备通常会从当前时刻以前的预设数量的TS分片文件开始获取数据，因此该频道的直播会存在一定的延迟。当用户切换频道时，显示设备需要重新获取新频道的HLS数据，从而会造成大量的时间浪费，进而导致用户不能平滑切台，引发切台播放卡顿，影响用户的观看体验。

发明内容

本申请一些实施例提供了一种显示设备、直播切台方法及存储介质。以解决相关技术中，切台时显示设备需要重新获取新频道的HLS数据并进行解析，会造成大量的时间浪费，进而导致切台播放卡顿，影响用户观看体验的问题。

第一方面，本申请一些实施例提供一种显示设备，包括：

显示器，被配置为显示播放数据；

控制器，被配置为：

响应于将第一直播源切换为第二直播源的切台指令，获取所述第二直播源对应的自适应码率流媒体传输协议HLS数据，以及同时获取所述第二直播源对应的组播数据；

控制所述显示器播放所述第二直播源对应的组播数据；

在所述组播数据与所述HLS数据的数据帧对齐的情况下，停止获取所述第二直播源对应的组播数据，并控制所述显示器播放所述HLS数据。

第二方面，本申请一些实施例提供一种直播切台方法，应用于显示设备，所述方法包括：

响应于将第一直播源切换为第二直播源的切台指令，获取所述第二直播源对应的自适应码率流媒体传输协议HLS数据，以及同时获取所述第二直播源对应的组播数据；

播放所述第二直播源对应的组播数据；

在所述组播数据与所述HLS数据的数据帧对齐的情况下，停止获取所述第二直播源对应的组播数据，并播放所述HLS数据。

第三方面，本申请一些实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被控制器执行时实现如第二方面所述的直播切台方法。

由以上技术方案可以看出，本申请一些实施例提供了一种显示设备、直播切台方法及存储介质。在将第一直播源切换为第二直播源时，可以同时获取第二直播源对应的HLS数据和组播数据，并对第二直播源对应的组播数据进行播放，在组播数据与HLS数据的数据帧对齐的情况下，停止获取组播数据，播放HLS数据。在切台时通过同时获取HLS数据和组播数据，并在组播数据与HLS数据的数据帧对齐之前先播放组播数据，可以解决显示设备在切台后获取HLS数据所带来的播放延迟和卡顿问题，从而提升用户的观看体验。

附图说明

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

图1示出了本申请一些实施例的显示设备的使用场景示意图；

图2示出了本申请一些实施例的控制装置100的配置框图；

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

图4示出了本申请一些实施例的显示设备200的软件配置框图；

图5示出了本申请一些实施例的显示设备200中应用程序的图标控件界面显示图；

图6示出了本申请一些实施例的HLS数据的结构示意图；

图7示出了本申请一些实施例的HLS数据直播的流程图；

图8示出了本申请一些实施例的直播切台方法的流程图；

图9示出了本申请一些实施例的直播切台方法的数据流示意图；

图10示出了本申请一些实施例的显示设备播放第一直播源的数据的效果示意图；

图11示出了本申请一些实施例的显示设备播放第二直播源的数据的效果示意图；

图12示出了本申请一些实施例的显示设备与服务器的交互流程示意图。

具体实施方式

为使本申请的目的和实施方式更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

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

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

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

本申请实施方式提供的显示设备可以具有多种实施形式，例如，可以是电视、智能电视、激光投影设备、显示器(monitor)、电子白板(electronic bulletin board)、电子桌面(electronic table)等。本申请实施例在此对显示设备的具体形态不做限制。本申请实施例中以显示设备为电视机为例进行示意说明。图1和图2为本申请的显示设备的一种具体实施方式。

图1示出了本申请一些实施例的显示设备的使用场景示意图。如图1所示，用户可通过智能设备300或控制装置100操作显示设备200。

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

在一些实施例中，也可以使用智能设备300(如移动终端、平板电脑、计算机、笔记本电脑等)以控制显示设备200。例如，使用在智能设备上运行的应用程序控制显示设备200。

在一些实施例中，显示设备200可以不使用上述的智能设备300或控制装置100接收指令，而是通过触摸或者手势等接收用户的控制。

在一些实施例中，显示设备200还可以采用除了控制装置100和智能设备300之外的方式进行控制，例如，可以通过显示设备200设备内部配置的获取语音指令的模块直接接收用户的语音指令控制，也可以通过显示设备200设备外部设置的语音控制设备来接收用户的语音指令控制。

在一些实施例中，显示设备200还与服务器400进行数据通信。可允许显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。服务器400可以向显示设备200提供各种内容和互动。服务器400可以是一个集群，也可以是多个集群，可以包括一类或多类服务器。

图2示出了本申请一些实施例的控制装置100的配置框图。如图2所示，控制装置100包括控制器110、通信接口130、用户输入/输出接口140、存储器、供电电源。控制装置100可接收用户的输入操作指令，且将操作指令转换为显示设备200可识别和响应的指令，起到用户与显示设备200之间交互中介作用。

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

在一些实施例中，控制器250包括处理器，视频处理器，音频处理器，图形处理器，RAM，ROM，用于输入/输出的第一接口至第n接口。

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

显示器260可为液晶显示器、OLED显示器、以及投影显示器，还可以为一种投影装置和投影屏幕。

通信器220是用于根据各种通信协议类型与外部设备或服务器进行通信的组件。例如：通信器可以包括Wifi模块，蓝牙模块，有线以太网模块等其他网络通信协议芯片或近场通信协议芯片，以及红外接收器中的至少一种。显示设备200可以通过通信器220与控制装置100或服务器400建立控制信号和数据信号的发送和接收。

用户接口，可用于接收控制装置100(如：红外遥控器等)的控制信号。

检测器230用于采集外部环境或与外部交互的信号。例如，检测器230包括光接收器，用于采集环境光线强度的传感器；或者，检测器230包括图像采集器，如摄像头，可以用于采集外部环境场景、用户的属性或用户交互手势，再或者，检测器230包括声音采集器，如麦克风等，用于接收外部声音。

外部装置接口240可以包括但不限于如下：高清多媒体接口接口(HDMI)、模拟或数据高清分量输入接口(分量)、复合视频输入接口(CVBS)、USB输入接口(USB)、RGB端口等任一个或多个接口。也可以是上述多个接口形成的复合性的输入/输出接口。

调谐解调器210通过有线或无线接收方式接收广播电视信号，以及从多个无线或有线广播电视信号中解调出音视频信号，如以及EPG数据信号。

在一些实施例中，控制器250和调谐解调器210可以位于不同的分体设备中，即调谐解调器210也可在控制器250所在的主体设备的外置设备中，如外置机顶盒等。

控制器250，通过存储在存储器上中各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250控制显示设备200的整体操作。例如：响应于接收到用于选择在显示器260上显示UI对象的用户命令，控制器250便可以执行与由用户命令选择的对象有关的操作。

在一些实施例中，控制器250包括中央处理器(Central Processing Unit，CPU)，视频处理器，音频处理器，图形处理器(Graphics Processing Unit，GPU)，RAM RandomAccess Memory，RAM)，ROM(Read-Only Memory，ROM)，用于输入/输出的第一接口至第n接口，通信总线(Bus)等中的至少一种。

用户可在显示器260上显示的图形用户界面(GUI)输入用户命令，则用户输入接口通过图形用户界面(GUI)接收用户输入命令。或者，用户可通过输入特定的声音或手势进行输入用户命令，则用户输入接口通过传感器识别出声音或手势，来接收用户输入命令。

“用户界面”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面常用的表现形式是图形用户界面(Graphic User Interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的一个图标、窗口、控件等界面元素，其中控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

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

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

框架层为应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层相当于一个处理中心，这个中心决定让应用层中的应用程序做出动作。应用程序通过API接口，可在执行中访问系统中的资源和取得系统的服务。

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

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

图5示出了本申请一些实施例的显示设备200中应用程序的图标控件界面显示图。在一些实施例中，如图5中所示，应用程序层包含至少一个应用程序可以在显示器中显示对应的图标控件，如：直播电视应用程序图标控件、视频点播应用程序图标控件、媒体中心应用程序图标控件、应用程序中心图标控件、游戏应用图标控件等。

在一些实施例中，直播电视应用程序，可以通过不同的信号源提供直播电视。例如，直播电视应用程序可以使用来自有线电视、无线广播、卫星服务或其他类型的直播电视源的输入提供电视信号。以及，直播电视应用程序可在显示设备200上显示直播电视信号的视频。

在一些实施例中，视频点播应用程序，可以提供来自不同存储源的视频。不同于直播电视应用程序，视频点播提供来自某些存储源的视频显示。例如，视频点播可以来自云存储的服务器端、来自包含已存视频节目的本地硬盘储存器。

在一些实施例中，媒体中心应用程序，可以提供各种多媒体内容播放的应用程序。例如，媒体中心，可以为不同于直播电视或视频点播，用户可通过媒体中心应用程序访问各种图像或音频所提供服务。

在一些实施例中，应用程序中心，可以提供储存各种应用程序。应用程序可以是一种游戏、应用程序，或某些和计算机系统或其他设备相关但可以在智能电视中运行的其他应用程序。应用程序中心可从不同来源获得这些应用程序，将它们储存在本地储存器中，然后在显示设备200上可运行。

在一些实施例中，显示设备在利用配置的播放器进行直播时，直播数据主要采用基于超文本传输协议(Hyper Text Transfer Protocol，HTTP)的自适应码率流媒体传输协议(Http Live Streaming，HLS)进行传输。HLS协议的工作原理是把整个媒体流切分成一个个小的基于HTTP的文件来下载，每次只下载一片，从而使得客户端可以边下载边播放，无需将整个媒体流全部下载后再进行播放。相较于实时传输协议(real-time transportprotocol，RTP)，HLS数据可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，从而拥有更强的稳定性。其中，HTTP是一个简单的请求响应协议，它通常运行在传输控制协议(Transmission Control Protocol，TCP)之上，用于定义客户端与服务器之间交换数据的过程。客户端连上服务器后，若想获得服务器中的某个资源，需遵守一定的通讯格式，HTTP协议用于定义客户端与服务器通迅的格式。

图6示出了本申请一些实施例的HLS数据的结构示意图。在一些实施例中，如图6中所示，HLS数据包括索引文件(Index file)和传输流(Transport Stream，TS)分片文件。索引文件也就是M3U8文件，M3U8文件实际上就是一个播放列表(Playlist)，类似于一个媒体播放列表(Media Playlist)，其内部信息记录的是一系列媒体片段资源，顺序播放该片段资源，即可完整展示多媒体资源。在一些实施例中，如图6中所示，M3U8文件中可以记载至少一个二级索引文件的地址，例如：M3U8文件中记载三个二级索引文件的地址，分别为Alternate-A index file、Alternate-B index file和Alternate-C index file。每个二级索引文件的地址中记载的均为多媒体资源的各个TS分片文件的下载地址，客户端通过各个TS分片文件的下载地址可以下载对应的TS分片文件。二级索引文件相当于备用源，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，从而允许客户端与服务器之间的流媒体会话适应不同的数据速率。在另一些实施例中，每个二级索引文件也可以继续嵌套，例如：每个二级索引文件中记载至少一个三级索引文件的地址。在又一些实施例中，M3U8文件中可以直接记载多媒体资源的各个TS分片文件的下载地址，而不存在嵌套层级的索引文件。

例如：M3U8文件的具体格式可以为：

{#EXTM3U,#EXT-X-MEDIA-SEQUENCE,#EXT-X-TARGETDURATION:10,#EXTINF:10.0,http://media.example.com/first.ts,#EXTINF:9.99,http://media.example.com/second.ts,#EXT-X-ENDLIST}

其中，#EXTM3U表示M3U8文件头，放在第一行；#EXT-X-MEDIA-SEQUENCE表示第一个TS分片文件的序列号，一般情况下是0，但是在直播场景下，这个序列号标识直播段的起始位置；#EXT-X-TARGETDURATION:10表示每个TS分片文件的最大时长为10秒(s)；#EXTINF表示每个TS分片文件的时长；#EXT-X-ENDLIST表示M3U8文件的结束符。如果一个M3U8文件不存在#EXT-X-ENDLIST标签，则可以认为它是直播，会有新的TS分片文件添加到播放列表末尾。客户端的显示设备在播放直播时，需要不停地更新M3U8文件，以获取最新的TS分片文件进行播放。

图7示出了本申请一些实施例的HLS数据直播的流程图。在一些实施例中，如图7中所示，媒体制作方提供的音频/视频输入数据(Audio/video inputs)传输到服务器(Server)上，在服务器上被转换成HLS数据，其中，Media encoder是转码模块，负责将音频/视频输入数据转码成目标编码格式的数据，媒体制作方提供的数据的编码格式可以是任何的音频/视频编码格式。在一些实施例中，目标编码格式可以为MPEG2-TS格式。转码成目标编码格式的数据之后，在stream segmenter模块将目标编码格式的数据切片，切片的结果就是HLS数据，包括索引文件和TS分片文件。HLS数据传输到Distribution，其中，Distribution是普通的HTTP文件服务器。客户端(Client)通过HTTP协议依次获取各个TS分片文件并播放，就能播放媒体制作方所提供的整个音频/视频流。

在一些实施例中，TS分片文件的时长可以为一个完整图片组(Group ofPictures，GOP)时长的整数倍。其中，一个GOP就是一组连续的画面，包括多个数据帧。GOP的第一个数据帧必须为I帧，I帧是内部编码帧，也就是关键帧，可以理解为一个完整的画面。MPEG编码将数据帧分为I帧、P帧、B帧三种，P帧是前向预测帧，B帧是双向内插帧，P帧和B帧记录的是相对于I帧的变化，P帧表示跟前一帧的差别，B帧表示前后帧差别。

在一些实施例中，客户端在利用显示设备实现任一频道的直播时，为了避免该频道的HLS数据的最新TS分片文件未就绪所带来的播放卡顿的问题，在该频道直播的起播阶段，显示设备通常会从倒数第三个TS分片文件开始获取数据，也就是从当前直播时刻往回追溯一定时段的TS分片文件。由于播放HLS数据是以文件索引和下载的方式进行，因此播放延迟受TS分片文件大小影响，直播通常延迟三个TS分片文件的时长左右，例如：每个TS分片文件的时长为10秒左右，直播延迟30秒左右，或者，每个TS分片文件的时长为2秒左右，直播延迟可降低至6秒左右。当减小TS分片文件的时长时，可以降低直播延迟，但是会增加单位时间内TS分片文件的数量，进而会带来HTTP协议短时间大量GET导致的性能损耗。

当用户切换频道时，也就是需要切换直播源时，显示设备需要重新获取新直播源的HLS数据，基于HLS协议的特性，显示设备需要解析HLS数据获取M3U8文件，并从M3U8文件中获取TS分片文件的下载地址，然后下载对应的TS分片文件，这一过程的时间浪费，会导致用户不能平滑切台，从而引发切台播放卡顿，影响用户的观看体验。

基于此，为了解决显示设备在直播切台时播放卡顿的问题，本申请一些实施例提供一种直播切台方法，该方法能够在接收到切台指令后，在播放组播数据的同时解析HLS数据，并在组播数据与解析得到的HLS数据对齐以后再断开组播数据，继续播放HLS数据。由于本申请一些实施例解析HLS数据的同时在播放组播数据，因此在切台时不会出现卡顿，而且本申请一些实施例通过在组播数据与解析得到的HLS数据对齐以后再断开组播数据，继续播放HLS数据，不仅能够使得用户观看的直播数据是连续的，而且HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，也很容易使用内容分发网络来传输媒体流，具有较好的直播优势，用户体验较好。

图8示出了本申请一些实施例的直播切台方法的流程图。如图8所示，所述方法具体包括如下内容：

S101：响应于将第一直播源切换为第二直播源的切台指令，获取第二直播源对应的HLS数据，以及同时获取第二直播源对应的组播数据。

在一些实施例中，用户可以通过智能设备或控制装置向显示设备发出切台指令，例如：用户可以通过在控制装置如遥控器上按键、语音输入、控制面板输入等输入切台指令，来控制显示设备。用户也可以通过显示设备上配置的获取语音指令的模块或者外置的语音控制设备来发出语音切台指令。用户还可以通过在显示设备上进行触摸或者手势操作等发出切台指令。

示例性地，上述切台指令可以为显示设备中的通信器接收到的，在通信器接收切台指令后，显示设备中的控制器基于切台指令，可以获取第二直播源对应的HLS数据，以及同时获取第二直播源对应的组播数据。

在一些实施例中，与显示设备进行交互的服务器可以包括流媒体服务器和组播服务器。流媒体服务器用于将各个直播源的直播数据转换为HLS数据，组播服务器可以根据各个直播源的组播地址，将各个直播源的直播数据向对应客户端进行发送。其中，组播数据表示无延时的实时直播数据。显示设备可以从流媒体服务器获取第二直播源对应的HLS数据，同时基于第二直播源的组播地址，从组播服务器获取第二直播源对应的组播数据。显示设备在从流媒体服务器获取第二直播源对应的HLS数据时，由于直播数据会不断增加，因此显示设备会不断地从流媒体服务器获取更新后的HLS数据，以便于获取到最新的TS分片文件。

S102：播放第二直播源对应的组播数据。

显示设备在获取到第二直播源对应的组播数据后，会对组播数据进行解封装处理和解码处理，得到各个数据帧，各个数据帧包括I帧、B帧、P帧等。将解码得到的数据帧储存在缓存里，同时显示出数据帧所对应的画面。例如：显示设备在当前直播时刻获取到第二直播源对应的组播数据后，可以从当前直播时刻的数据帧开始播放对应的画面。

在一些实施例中，在播放第二直播源对应的组播数据的同时，显示设备还会同时解析第二直播源对应的HLS数据，得到第二直播源对应的HLS数据中的索引文件。然后，基于索引文件，下载TS分片文件。显示设备会从当前直播时刻往回追溯一定时段的TS分片文件开始下载，直至下载到最新生成的TS分片文件，例如：显示设备从当前直播时刻往回追溯三个TS分片文件开始下载。

在一些实施例中，显示设备基于索引文件，下载TS分片文件，包括：显示设备基于索引文件，向流媒体服务器发送第一请求报文，并接收来自流媒体服务器的第一响应报文。

其中，第一请求报文用于请求TS分片文件，第一请求报文包括TS分片文件的下载地址。第一响应报文中携带TS分片文件。第一请求报文和第一响应报文是基于HTTP协议的HTTP报文。

在一些实施例中，第一请求报文通过TCP长连接的方式发送，第一响应报文通过chunked的方式发送。其中，将第一请求报文中的Connection字段设置为keep-alive状态，以此保证流媒体服务器和显示设备可以基于HTTP长连接获取数据。如果开启keep-alive,则流媒体服务器在返回响应后不关闭TCP连接,显示设备在接收完响应报文后也不关闭TCP连接,在发送下一个HTTP请求时会继续使用该TCP连接。将第一响应报文中的Transfer-Encoding字段设置为chunked，代表该内容的长度不固定，显示设备可以一直接收数据直至链接中断。由于每请求一个TS分片文件，都会向服务器发送一个请求，每发送一个请求都要重新建立TCP连接会带来极大的性能损耗，采用TCP长连接的方式可以有效降低GET的次数，以减少HLS协议带来的资源消耗。

例如：第一请求报文的具体格式可以为：

{POST cctvx.m3u8 HTTP/1.1,…,Connection:Keep-Alive,…}

例如：第一响应报文的具体格式可以为：

{HTTP/1.1206Partial Content，…,Transfer-Encoding:chunked，…,Connection:Keep-Alive,…}

S103：在组播数据与HLS数据的数据帧对齐的情况下，停止获取第二直播源对应的组播数据，并播放HLS数据。

在播放组播数据的同时，还在解析HLS数据，下载TS分片文件，由于TS分片文件的下载速度与数据帧的播放速度存在差异，因此，虽然显示设备会从当前直播时刻往前回溯一段时间的TS分片文件开始下载，但是下载速度通常会超过播放速度，进而显示设备可以在某一时刻下载到对应的最新生成的TS分片文件。例如：显示设备从10点开始播放实时的组播数据，同时，从9点59分的TS分片文件开始下载，一分钟之后，已下载到了10点零1分所对应的最新的TS分片文件，也就是获取到了最新生成的数据帧，而此时组播数据也播到了最新生成的数据帧，此时，组播数据与HLS数据的数据帧实现对齐。

在一些实施例中，检测组播数据与HLS数据的数据帧是否对齐，可以比对每个预设时段内获取到的数据是否完全相同。其中，预设时段可以根据一个完整的GOP的时长来设定，比如：2秒。示例性地，从当前直播时刻开始，每获取到2秒的组播数据和HLS数据，就进行一次比对，如果不相同，则继续进行下一个2秒的比对，直至数据完全相同后，判定组播数据与HLS数据的数据帧实现对齐。

在一些实施例中，在组播数据与HLS数据的数据帧不对齐的情况下，显示设备继续播放第二直播源对应的组播数据，同时继续解析第二直播源对应的HLS数据，并下载TS分片文件，与组播数据进行下一预设时段内的数据比对，直至组播数据与HLS数据的数据帧对齐。

在一些实施例中，断开组播数据后，可以从对齐数据帧或对齐数据帧的下一数据帧开始播放HLS数据。其中，对齐数据帧为组播数据与HLS数据对齐时的数据帧。这样，断开组播数据后，可以继续播放HLS数据，画面显示较为连贯，不仅避免HLS协议带来的延迟，而且也能够节省资源。

在一些实施例中，显示设备在未接收到将第一直播源切换为第二直播源的切台指令的情况下，继续获取第一直播源对应的HLS数据，并播放第一直播源对应的HLS数据。HLS数据的播放流程参见前述相关表述，此处不再赘述。

图9示出了本申请一些实施例的直播切台方法的数据流示意图。如图9中所示，如果未接收到切台指令，则获取第一直播源对应的HLS数据，并播放第一直播源对应的HLS数据。如果接收到切台指令，则同时获取第二直播源对应的HLS数据，和第二直播源对应的组播数据。针对第二直播源对应的HLS数据，解析并下载TS分片文件，针对第二直播源对应的组播数据，播放组播数据。如果组播数据和HLS数据的数据帧对齐，则断开组播数据，继续播放HLS数据。如果组播数据和HLS数据的数据帧不对齐，则继续获取第二直播源对应的HLS数据，和第二直播源对应的组播数据。

本申请一些实施例提供的直播切台方法，能够在接收到切台指令后，在播放组播数据的同时解析HLS数据，并在组播数据与解析得到的HLS数据对齐以后再断开组播数据，继续播放HLS数据。由于解析HLS数据的同时在播放组播数据，因此在切台时不会出现卡顿，而且通过在组播数据与解析得到的HLS数据对齐以后再断开组播数据，继续播放HLS数据，不仅能够使得用户观看的直播数据是连续的，而且HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，也很容易使用内容分发网络来传输媒体流，具有较好的直播优势，用户体验较好。

基于上述实施例中提供的直播切台方法，在本申请的一些实施例中还提供一种显示设备。显示设备200包括：显示器260和控制器250。其中，显示器260被配置为显示播放数据。在控制器250正常播放第一直播源对应的HLS数据，并且未接收到切台指令的情况下，图10示出了本申请一些实施例的显示设备播放第一直播源的数据的效果示意图。如图10所示，控制器250继续获取第一直播源对应的HLS数据，并控制显示器260播放第一直播源对应的HLS数据。

在控制器250正常播放第一直播源对应的HLS数据，并且接收到将第一直播源切换为第二直播源的切台指令的情况下，图11示出了本申请一些实施例的显示设备播放第二直播源的数据的效果示意图。如图11所示，控制器250在接收到切台指令后会同时获取第二直播源对应的HLS数据和组播数据，并控制显示器260播放第二直播源对应的组播数据。

图12示出了本申请一些实施例的显示设备与服务器的交互流程示意图。如图12所示，在控制器250接收到将第一直播源切换为第二直播源的切台指令的情况下，控制器250、显示器260、流媒体服务器和组播服务器分别被配置为执行以下程序步骤：

S201：控制器250响应于将第一直播源切换为第二直播源的切台指令，从组播服务器获取第二直播源对应的组播数据。

S202：控制器250控制显示器260播放第二直播源对应的组播数据。

S203：控制器250从流媒体服务器获取第二直播源对应的HLS数据。

其中，控制器250从组播服务器获取第二直播源对应的组播数据的同时，可以从流媒体服务器获取第二直播源对应的HLS数据。

S204：控制器250解析第二直播源对应的HLS数据，得到第二直播源对应的HLS数据中的索引文件。

S205：控制器250基于索引文件，从流媒体服务器下载TS分片文件。

上述步骤202与步骤203-步骤205可以同时执行。

S206：控制器250检测组播数据与HLS数据的数据帧是否对齐。

S207：在组播数据与HLS数据的数据帧未对齐的情况下，控制器250继续从组播服务器获取第二直播源对应的组播数据并播放。

S208：在组播数据与HLS数据的数据帧对齐的情况下，控制器250停止从组播服务器获取第二直播源对应的组播数据。

S209：控制显示器播放第二直播源对应的HLS数据。

其中，步骤S208和步骤S209同时执行。

本申请一些实施例提供的显示设备，能够在接收到切台指令后，在播放组播数据的同时解析HLS数据，并在组播数据与解析得到的HLS数据对齐以后再断开组播数据，继续播放HLS数据。由于解析HLS数据的同时在播放组播数据，因此显示设备在切台时不会出现卡顿，而且通过在组播数据与解析得到的HLS数据对齐以后再断开组播数据，继续播放HLS数据，不仅能够使得用户观看的直播数据是连续的，而且HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器，也很容易使用内容分发网络来传输媒体流，具有较好的直播优势，用户体验较好。

在本申请的一些实施例中还提供一种计算机可读存储介质，其中，该计算机可读存储介质可存储有程序，该程序执行时可包括本申请提供的直播切台方法的各实施例中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体(readonly memory，ROM)或随机存储记忆体(random access memory，RAM)等。

由以上技术方案可以看出，本申请一些实施例提供的显示设备可以在直播过程中，响应于将第一直播源切换为第二直播源的切台指令，同时获取第二直播源对应的HLS数据和组播数据，并对第二直播源对应的组播数据进行播放，在组播数据与HLS数据的数据帧对齐的情况下，停止获取组播数据，播放HLS数据。在切台时通过同时获取HLS数据和组播数据，并在组播数据与HLS数据的数据帧对齐之前先播放组播数据，可以解决显示设备在切台后获取HLS数据所带来的播放延迟和卡顿问题，从而提升用户的观看体验。

本申请提供的实施例之间的相似部分相互参见即可，以上提供的具体实施方式只是本申请总的构思下的几个示例，并不构成本申请保护范围的限定。对于本领域的技术人员而言，在不付出创造性劳动的前提下依据本申请方案所扩展出的任何其他实施方式都属于本申请的保护范围。

Claims (10)

1.一种显示设备，其特征在于，包括：

显示器，被配置为显示播放数据；

控制器，被配置为：

响应于将第一直播源切换为第二直播源的切台指令，获取所述第二直播源对应的自适应码率流媒体传输协议HLS数据，以及同时获取所述第二直播源对应的组播数据；

控制所述显示器播放所述第二直播源对应的组播数据；

在所述组播数据与所述HLS数据的数据帧对齐的情况下，停止获取所述第二直播源对应的组播数据，并控制所述显示器播放所述HLS数据。

2.根据权利要求1所述的显示设备，其特征在于，所述控制器被配置为控制所述显示器播放所述HLS数据，包括：

控制所述显示器从对齐数据帧或所述对齐数据帧的下一数据帧开始播放所述HLS数据，所述对齐数据帧为所述组播数据与所述HLS数据对齐时的数据帧。

3.根据权利要求1所述的显示设备，其特征在于，在所述控制器控制所述显示器播放所述第二直播源对应的组播数据的同时，所述控制器还被配置为：

解析所述第二直播源对应的HLS数据，得到所述第二直播源对应的HLS数据中的索引文件；

基于所述索引文件，下载传输流TS分片文件。

4.根据权利要求3所述的显示设备，其特征在于，所述控制器被配置为基于所述索引文件，下载传输流TS分片文件，包括：

基于所述索引文件，向流媒体服务器发送第一请求报文，所述第一请求报文用于请求所述TS分片文件，所述第一请求报文包括所述TS分片文件的下载地址；

接收来自所述流媒体服务器的第一响应报文，所述第一响应报文中携带所述TS分片文件。

5.根据权利要求4所述的显示设备，其特征在于，所述第一请求报文通过TCP长连接的方式发送，所述第一响应报文通过chunked的方式发送。

6.根据权利要求1所述的显示设备，其特征在于，在所述控制器未接收到所述切台指令的情况下，所述控制器还被配置为：

获取所述第一直播源对应的HLS数据；

控制所述显示器播放所述第一直播源对应的HLS数据。

7.根据权利要求1所述的显示设备，其特征在于，所述控制器被配置为获取所述第二直播源对应的自适应码率流媒体传输协议HLS数据，以及同时获取所述第二直播源对应的组播数据，包括：

从流媒体服务器获取所述第二直播源对应的所述HLS数据；

同时基于所述第二直播源的组播地址，从组播服务器获取所述第二直播源对应的组播数据。

8.一种直播切台方法，应用于显示设备，其特征在于，所述方法包括：

响应于将第一直播源切换为第二直播源的切台指令，获取所述第二直播源对应的自适应码率流媒体传输协议HLS数据，以及同时获取所述第二直播源对应的组播数据；

播放所述第二直播源对应的组播数据；

在所述组播数据与所述HLS数据的数据帧对齐的情况下，停止获取所述第二直播源对应的组播数据，并播放所述HLS数据。

9.根据权利要求8所述的方法，其特征在于，所述播放所述HLS数据，包括：

从对齐数据帧或所述对齐数据帧的下一数据帧开始播放所述HLS数据，所述对齐数据帧为所述组播数据与所述HLS数据对齐时的数据帧。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被控制器执行时实现如权利要求8和9中任一项所述的直播切台方法。

Images