一种媒体数据跳变续播方法及显示设备与流程

1.本发明涉及显示设备领域，尤其涉及一种媒体数据跳变续播方法及显示设备。


背景技术：

2.atsc3.0是高级电视系统委员会(advanced television systems committee，atsc)创建的电视广播atsc标准的版本之一，atsc3.0中具有route dash媒体播放协议。在一些应用场景中，对于支持atsc3.0的显示设备，在切台或是plp(packet level protocol，分组级协议)包数据解析异常等情况发生时，可能使显示设备获取到的媒体数据中segment(分片)产生跳变，即因segment不连续而出现断片、缺片，由此引发解复用后解析出的es(elementary stream，基本码流)数据的pts(presentation time stamp，显示时间戳)不连续，导致解码器无法正常解码，进而在媒体数据播放过程中出现如黑屏、卡顿、花屏、音画不同步等问题，往往需要用户关闭并重启播放器或是换台并返回，影响用户观看体验。


技术实现要素：

3.为解决上述背景技术中存在的问题，本发明提供一种媒体数据跳变续播方法及显示设备。
4.第一方面提供的显示设备，包括：
5.解复用器，用于对媒体数据进行解析处理，得到视频流数据和音频流数据；
6.视频解码器，用于对所述视频流数据进行解码；
7.音频解码器，用于对所述音频流数据进行解码；
8.显示器，用于显示解码后的视频流数据；
9.声音播放器，用于播放解码后的音频流数据；
10.控制器，被配置为执行：
11.在媒体数据起播之后，若监听到解复用器发送的用于指示视频流数据和/或音频流数据的显示时间戳不连续的消息，控制视频解码器和音频解码器执行seek操作；
12.在监听到视频解码器发送的第一seek完成消息和音频解码器发送的第二seek完成消息时，控制视频解码器获取并解码所述视频流数据，以及控制音频解码器获取并解码所述音频流数据；
13.控制显示器显示解码后的视频流数据，控制声音播放器播放解码后的音频流数据。
14.在第一方面提供技术方案中，解复用器对媒体数据进行解析处理后，可以分离音视频，并形成音视频的es流，解复用器通过音频流数据和视频流数据中的显示时间戳，即可确定是否出现音、视频流播放不连续的问题，当音频流数据和视频流数据中至少一种存在pts不连续，则解复用器都会广播用于指示出现pts不连续的消息。本技术中增设监听机制，当监听到解复用器发送的消息时，同时触发音视频解码器内置的seek操作，所述seek操作是指音视频解码器暂停接收数据，并清空当前缓存的全部数据，相当于对音视频解码器进
行重置，通过执行seek操作可规避音视频解码器对es流数据连续性的要求，从而克服因音视频解码器识别到pts不连续而导致的无法正常解码。在音视频解码器seek完成后，控制器监听到音视频解码器分别发送的seek完成消息，则使音视频解码器继续接收并解码数据，此时相当于直接seek到不连续数据的起始帧进行续播，即跳变数据不会被丢弃，即便媒体数据发生跳变也能实现自动接续(不间断)解码播放，无需用户手动修复，避免显示设备的黑屏、卡顿、花屏、音画不同步等问题，保证音视频播放的同步性和流畅性，并且基本不影响媒体数据的播放，提升用户观看体验。
15.在第一方面第一种示例性的实现方式中，在控制视频解码器和音频解码器执行seek操作之后，所述控制器还被配置为执行：将所述视频流数据缓存到第一链表，以及，将所述音频流数据缓存到第二链表。
16.在第一方面第二种示例性的实现方式中，在监听到视频解码器发送的第一seek完成消息和音频解码器发送的第二seek完成消息时，所述控制器具体被配置为执行：控制视频解码器从所述第一链表中读取所述视频流数据，以及，控制音频解码器从所述第二链表中读取所述音频流数据。
17.对于前述第一方面第一种和第二种示例性的实现方式，控制器可创建第一链表和第二链表，第一链表用于在视频解码器seek期间缓存从解复用器接收到的视频流数据，第二链表用于在音频解码器seek期间缓存从解复用器接收到的音频流数据，这样即可通过链表保存解码器seek期间发生跳变的音视频流数据，便于后续解码器seek完毕后访问链表，并读取链表中缓存的数据，即可解码并续播出现跳变的音视频流数据。
18.在第一方面第三种示例性的实现方式中，所述第一链表设置于第一目标插件内，所述第一目标插件链接于所述解复用器和所述视频解码器间；所述第二链表设置于第二目标插件内，所述第二目标插件链接于所述解复用器和所述音频解码器间。在该实现方式中，控制器中设置有第一目标插件和第二目标插件，用于分别创建及维护第一链表和第二链表，便于在发生视频流数据和/或音频流数据的pts非连续的事件时，控制跳变数据的缓存和读取消耗，保证音视频解码器seek完成后准确有效地续播跳变数据。
19.在第一方面第四种示例性的实现方式中，在监听到用于指示视频流数据和/或音频流数据的显示时间戳不连续的消息时，所述控制器还被配置为执行：
20.根据所述第一目标插件的第一标识以及所述第二目标插件的第二标识，遍历预先构建的播放管道，查找所述第一目标插件和所述第二目标插件；
21.其中，所述播放管道包括媒体数据解码播放前涉及的解复用器、输入选择器、第一目标插件、第二目标插件以及其他功能模块或插件。
22.对于前述第一方面第四种示例性的实现方式，对于支持gstreamer播放器的显示设备，gstreamer播放器会创建一个播放管道(pipeline)，pipeline中包括若干项element，每个element相当于一个功能模块/插件，用以实现某种限定的功能，例如解复用器、用于将解复用后的音视频流数据分离传输至后续element的输入选择器、第一目标插件、第二目标插件以及其他必要的功能模块/插件等，每个element都具有全局唯一性的标识(例如各不相同的名称)，因此通过识别标识即可在pipeline中定位及查找到指定的element。在监听到pts不连续的消息时，为便于快速、准确地访问链表并读取链表中缓存的es数据，可利用第一目标插件的第一标识和第二目标插件的第二标识，准确定位到当前pipeline中的第一
目标插件和第二目标插件。
23.在第一方面第五种示例性的实现方式中，所述控制器还被配置为执行：
24.在查找到所述第一目标插件后，将所述第一目标插件的第一属性接口设置为第一属性值，所述第一属性值用于指示所述第一目标插件将接收到的视频流数据缓存在所述第一链表中；
25.在查找到所述第二目标插件后，将所述第二目标插件的第二属性接口设置为第二属性值，所述第二属性值用于指示所述第二目标插件将接收到的音频流数据缓存在所述第二链表中。
26.对于前述第一方面第五种示例性的实现方式，在第一目标插件中预设第一属性接口，第二目标插件中预设第二属性接口，在监听到指示pts不连续的消息时，可以遍历pipeline查找到第一目标插件和第二目标插件，然后分别对其中的第一属性接口和第二属性接口进行设置。以第一目标插件为例，此时视频解码器处于seek状态，不从第一目标插件读取视频流数据，将第一属性接口设置为第一属性值，作为一种示例，例如第一属性接口配置的属性为“play
‑
state
‑
is
‑
ready”，第一属性值为false，第一目标插件读取到“play
‑
state
‑
is
‑
ready”＝false，即接收到播放状态未准备好的消息，则调用链表功能，将接收到的视频流数据先缓存于第一链表中。第二目标插件的第二属性接口设置与第一目标插件基本相似，这里不再赘述。
27.在第一方面第六种示例性的实现方式中，在监听到视频解码器发送的第一seek完成消息和音频解码器发送的第二seek完成消息时，所述控制器还被配置为执行：
28.将所述第一目标插件的第一属性接口设置为第三属性值，所述第三属性值用于指示所述第一目标插件停止将视频流数据缓存在所述第一链表中，并将后续接收到的视频流数据缓存在自身的内存中；
29.将所述第二目标插件的第二属性接口设置为第四属性值，所述第四属性值用于指示所述第二目标插件停止将音频流数据缓存在所述第二链表中，并将后续接收到的音频流数据缓存在自身的内存中。
30.对于前述第一方面第六种示例性的实现方式，在监听到解码器发送的seek完成消息时，解码器可以恢复获取数据，即播放状态已准备就绪，此时可以变更第一属性接口和第二属性接口的属性值。以第一目标插件为例，将第一属性接口设置为第三属性值，作为一种示例，例如第一属性接口配置的属性为“play
‑
state
‑
is
‑
ready”，第三属性值为true，第一目标插件读取到“play
‑
state
‑
is
‑
ready”＝true，即接收到播放状态已准备就绪的消息，则关闭第一链表的接收功能，即停止将视频流数据继续缓存在第一链表中，而后续所接收的视频流数据(认为pts已恢复连续状态)默认缓存在第一目标插件的内存中，此时视频解码器先读取在其seek期间第一链表中缓存的视频流数据，待第一链表中数据读取并消耗为空时，再转而从第一目标插件的内存中继续读取视频流数据，从而保证视频流数据解码播放的有序性和连续性。第二目标插件的第二属性接口设置与第一目标插件基本相似，这里不再赘述。
31.在第一方面第七种示例性的实现方式中，所述控制器还被配置为执行：
32.在所述第一链表中的视频流数据被全部读取并消耗为空时，释放所述第一链表占用的内存资源，控制所述视频解码器从所述第一目标插件的内存中继续读取所述视频流数
据；
33.在所述第二链表中的音频流数据被全部读取并消耗为空时，释放所述第二链表占用的内存资源，控制所述音频解码器从所述第二目标插件的内存中继续读取所述音频流数据。
34.对于前述第一方面第七种示例性的实现方式，以第一链表为例，视频解码器seek完成后优先从第一链表中读取视频流数据，每读取完一帧即可将该帧数据从第一链表中清除，这样第一链表中的数据会被逐渐消耗，当消耗为空时，第一链表中的数据已被视频解码器全部读取完毕，则视频解码器转而向第一目标插件的内存继续读取视频流数据，此时第一链表对应于当前次的数据跳变事件的功能已全部执行，则可释放掉第一链表占用的资源，退出链表功能。第二链表的功能与第一链表相似，区别仅在于针对的流类型不同，第一链表针对视频流，第二链表针对音频流。
35.在第一方面第八种示例性的实现方式中，所述控制器还被配置为执行：
36.在未监听到解复用器发送的用于指示视频流数据和/或音频流数据的显示时间戳不连续的消息时，所述视频解码器和所述音频解码器均不执行所述seek操作；
37.控制所述视频解码器从所述第一目标插件的内存中持续读取所述视频流数据，控制所述音频解码器从所述第二目标插件的内存中持续读取所述音频流数据。
38.对于前述第一方面第八种示例性的实现方式，在未监听到pts不连续的消息时，即可按照正常的播放流程处理，音视频解码器均不执行seek操作，并且第一目标插件和第二目标插件中的链表功能都处于关闭状态，解复用后的视频流数据缓存至第一目标插件的内存，视频解码器从第一目标插件的内存中持续读取视频流数据并进行解码；解复用后的音频流数据缓存至第二目标插件的内存，音频解码器从第二目标插件的内存中持续读取音频流数据并进行解码。
39.第二方面提供的媒体数据跳变续播方法，包括：
40.在媒体数据起播之后，若监听到解复用器在对媒体数据进行解析后发送的用于指示视频流数据和/或音频流数据的显示时间戳不连续的消息，控制视频解码器和音频解码器执行seek操作；
41.在监听到视频解码器发送的第一seek完成消息和音频解码器发送的第二seek完成消息时，控制视频解码器获取并解码所述视频流数据，以及控制音频解码器获取并解码所述音频流数据；
42.控制显示器显示解码后的视频流数据，控制声音播放器播放解码后的音频流数据。
43.第二方面包括的其他示例性实现方式以及具备的有益效果，可以适应性参照前述第一方面的相关说明，这里不再赘述。
附图说明
44.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要访问的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
45.图1示出了根据一些实施例的显示设备的使用场景；
46.图2示出了根据一些实施例的控制装置100的硬件配置框图；
47.图3示出了根据一些实施例的显示设备200的硬件配置框图；
48.图4示出了根据一些实施例的显示设备200中软件配置图；
49.图5示例性示出了一种媒体数据跳变续播方法的流程图；
50.图6示例性示出了本技术媒体数据跳变续播机制下对应的pipeline结构示意图；
51.图7示例性示出了另一种媒体数据跳变续播方法的流程图。
具体实施方式
52.为使本技术的目的和实施方式更加清楚，下面将结合本技术示例性实施例中的附图，对本技术示例性实施方式进行清楚、完整地描述，显然，描述的示例性实施例仅是本技术一部分实施例，而不是全部的实施例。
53.需要说明的是，本技术中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本技术的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。
54.本技术中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换。
55.术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。
56.术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。
57.图1为根据实施例中显示设备的使用场景的示意图。如图1所示，显示设备200还与服务器400进行数据通信，用户可通过智能设备300或控制装置100操作显示设备200。
58.在一些实施例中，控制装置100可以是遥控器，遥控器和显示设备的通信包括红外协议通信或蓝牙协议通信，及其他短距离通信方式中的至少一种，通过无线或有线方式来控制显示设备200。用户可以通过遥控器上按键、语音输入、控制面板输入等至少一种输入用户指令，来控制显示设备200。
59.在一些实施例中，智能设备300可以包括移动终端、平板电脑、计算机、笔记本电脑，ar/vr设备等中的任意一种。
60.在一些实施例中，也可以使用智能设备300以控制显示设备200。例如，使用在智能设备上运行的应用程序控制显示设备200。
61.在一些实施例中，也可以使用智能设备300和显示设备进行数据的通信。
62.在一些实施例中，显示设备200还可以采用除了控制装置100和智能设备300之外的方式进行控制，例如，可以通过显示设备200设备内部配置的获取语音指令的模块直接接收用户的语音指令控制，也可以通过显示设备200设备外部设置的语音控制装置来接收用户的语音指令控制。
63.在一些实施例中，显示设备200还与服务器400进行数据通信。可允许显示设备200
通过局域网(lan)、无线局域网(wlan)和其他网络进行通信连接。服务器400可以向显示设备200提供各种内容和互动。服务器400可以是一个集群，也可以是多个集群，可以包括一类或多类服务器。
64.在一些实施例中，一个步骤执行主体执行的软件步骤可以随需求迁移到与之进行数据通信的另一步骤执行主体上进行执行。示例性的，服务器执行的软件步骤可以随需求迁移到与之数据通信的显示设备上执行，反之亦然。
65.图2示例性示出了根据示例性实施例中控制装置100的配置框图。如图2所示，控制装置100包括控制器110、通信接口130、用户输入/输出接口140、存储器、供电电源。控制装置100可接收用户的输入操作指令，且将操作指令转换为显示设备200可识别和响应的指令，起用用户与显示设备200之间交互中介作用。
66.在一些实施例中，通信接口130用于和外部通信，包含wifi芯片，蓝牙模块，nfc或可替代模块中的至少一种。
67.在一些实施例中，用户输入/输出接口140包含麦克风，触摸板，传感器，按键或可替代模块中的至少一种。
68.图3示出了根据示例性实施例中显示设备200的硬件配置框图。
69.在一些实施例中，显示设备200包括调谐解调器210、通信器220、检测器230、外部装置接口240、控制器250、显示器260、音频输出接口270、存储器、供电电源、用户接口中的至少一种。
70.在一些实施例中控制器包括中央处理器，视频处理器，音频处理器，图形处理器，ram，rom，用于输入/输出的第一接口至第n接口。
71.在一些实施例中，显示器260包括用于呈现画面的显示屏组件，以及驱动图像显示的驱动组件，用于接收源自控制器输出的图像信号，进行显示视频内容、图像内容以及菜单操控界面的组件以及用户操控ui界面等。
72.在一些实施例中，显示器260可为液晶显示器、oled显示器、以及投影显示器中的至少一种，还可以为一种投影装置和投影屏幕。
73.在一些实施例中，调谐解调器210通过有线或无线接收方式接收广播电视信号，以及从多个无线或有线广播电视信号中解调出音视频信号，如以及epg数据信号。
74.在一些实施例中，通信器220是用于根据各种通信协议类型与外部设备或服务器进行通信的组件。例如：通信器可以包括wifi模块，蓝牙模块，有线以太网模块等其他网络通信协议芯片或近场通信协议芯片，以及红外接收器中的至少一种。显示设备200可以通过通信器220与控制装置100或服务器400建立控制信号和数据信号的发送和接收。
75.在一些实施例中，检测器230用于采集外部环境或与外部交互的信号。例如，检测器230包括光接收器，用于采集环境光线强度的传感器；或者，检测器230包括图像采集器，如摄像头，可以用于采集外部环境场景、用户的属性或用户交互手势，再或者，检测器230包括声音采集器，如麦克风等，用于接收外部声音。
76.在一些实施例中，外部装置接口240可以包括但不限于如下：高清多媒体接口接口(hdmi)、模拟或数据高清分量输入接口(分量)、复合视频输入接口(cvbs)、usb输入接口(usb)、rgb端口等任一个或多个接口。也可以是上述多个接口形成的复合性的输入/输出接口。
77.在一些实施例中，控制器250和调谐解调器210可以位于不同的分体设备中，即调谐解调器210也可在控制器250所在的主体设备的外置设备中，如外置机顶盒等。
78.在一些实施例中，控制器250，通过存储在存储器上中各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250控制显示设备200的整体操作。例如：响应于接收到用于选择在显示器260上显示ui对象的用户命令，控制器250便可以执行与由用户命令选择的对象有关的操作。
79.在一些实施例中，所述对象可以是可选对象中的任何一个，例如超链接、图标或其他可操作的控件。与所选择的对象有关操作有：显示连接到超链接页面、文档、图像等操作，或者执行与所述图标相对应程序的操作。
80.在一些实施例中控制器包括中央处理器(central processing unit，cpu)，视频处理器，音频处理器，图形处理器(graphics processing unit，gpu)，ram random access memory，ram)，rom(read
‑
only memory,rom)，用于输入/输出的第一接口至第n接口，通信总线(bus)等中的至少一种。
81.cpu处理器。用于执行存储在存储器中操作系统和应用程序指令，以及根据接收外部输入的各种交互指令，来执行各种应用程序、数据和内容，以便最终显示和播放各种音视频内容。cpu处理器，可以包括多个处理器。如，包括一个主处理器以及一个或多个子处理器。
82.在一些实施例中，图形处理器，用于产生各种图形对象，如：图标、操作菜单、以及用户输入指令显示图形等中的至少一种。图形处理器包括运算器，通过接收用户输入各种交互指令进行运算，根据显示属性显示各种对象；还包括渲染器，对基于运算器得到的各种对象，进行渲染，上述渲染后的对象用于显示在显示器上。
83.在一些实施例中，视频处理器，用于将接收外部视频信号，根据输入信号的标准编解码协议，进行解压缩、解码、缩放、降噪、帧率转换、分辨率转换、图像合成等视频处理中的至少一种，可得到直接可显示设备200上显示或播放的信号。
84.在一些实施例中，视频处理器，包括解复用模块、视频解码模块、图像合成模块、帧率转换模块、显示格式化模块等中的至少一种。其中，解复用模块，用于对输入音视频数据流进行解复用处理。视频解码模块，用于对解复用后的视频信号进行处理，包括解码和缩放处理等。图像合成模块，如图像合成器，其用于将图形生成器根据用户输入或自身生成的gui信号，与缩放处理后视频图像进行叠加混合处理，以生成可供显示的图像信号。帧率转换模块，用于对转换输入视频帧率。显示格式化模块，用于将接收帧率转换后视频输出信号，改变信号以符合显示格式的信号，如输出rgb数据信号。
85.在一些实施例中，音频处理器，用于接收外部的音频信号，根据输入信号的标准编解码协议，进行解压缩和解码，以及降噪、数模转换、和放大处理等处理中的至少一种，得到可以在扬声器中播放的声音信号。
86.在一些实施例中，用户可在显示器260上显示的图形用户界面(gui)输入用户命令，则用户输入接口通过图形用户界面(gui)接收用户输入命令。或者，用户可通过输入特定的声音或手势进行输入用户命令，则用户输入接口通过传感器识别出声音或手势，来接收用户输入命令。
87.在一些实施例中，“用户界面”，是应用程序或操作系统与用户之间进行交互和信
息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面常用的表现形式是图形用户界面(graphic user interface，gui)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的一个图标、窗口、控件等界面元素，其中控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、widget等可视的界面元素中的至少一种。
88.在一些实施例中，用户接口280，为可用于接收控制输入的接口(如：显示设备本体上的实体按键，或其他等)。
89.在一些实施例中，显示设备的系统可以包括内核(kernel)、命令解析器(shell)、文件系统和应用程序。内核、shell和文件系统一起组成了基本的操作系统结构，它们让用户可以管理文件、运行程序并使用系统。上电后，内核启动，激活内核空间，抽象硬件、初始化硬件参数等，运行并维护虚拟内存、调度器、信号及进程间通信(ipc)。内核启动后，再加载shell和用户应用程序。应用程序在启动后被编译成机器码，形成一个进程。
90.参见图4，在一些实施例中，将系统分为四层，从上至下分别为应用程序(applications)层(简称“应用层”)，应用程序框架(application framework)层(简称“框架层”)，安卓运行时(android runtime)和系统库层(简称“系统运行库层”)，以及内核层。
91.在一些实施例中，应用程序层中运行有至少一个应用程序，这些应用程序可以是操作系统自带的窗口(window)程序、系统设置程序或时钟程序等；也可以是第三方开发者所开发的应用程序。在具体实施时，应用程序层中的应用程序包不限于以上举例。
92.框架层为应用程序层的应用程序提供应用编程接口(application programming interface，api)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层相当于一个处理中心，这个中心决定让应用层中的应用程序做出动作。应用程序通过api接口，可在执行中访问系统中的资源和取得系统的服务。
93.如图4所示，本技术实施例中应用程序框架层包括管理器(managers)，内容提供者(content provider)等，其中管理器包括以下模块中的至少一个：活动管理器(activity manager)用与和系统中正在运行的所有活动进行交互；位置管理器(location manager)用于给系统服务或应用提供了系统位置服务的访问；文件包管理器(package manager)用于检索当前安装在设备上的应用程序包相关的各种信息；通知管理器(notification manager)用于控制通知消息的显示和清除；窗口管理器(window manager)用于管理用户界面上的括图标、窗口、工具栏、壁纸和桌面部件。
94.在一些实施例中，活动管理器用于管理各个应用程序的生命周期以及通常的导航回退功能，比如控制应用程序的退出、打开、后退等。窗口管理器用于管理所有的窗口程序，比如获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕，控制显示窗口变化(例如将显示窗口缩小显示、抖动显示、扭曲变形显示等)等。
95.在一些实施例中，系统运行库层为上层即框架层提供支撑，当框架层被使用时，安卓操作系统会运行系统运行库层中包含的c/c 库以实现框架层要实现的功能。
96.在一些实施例中，内核层是硬件和软件之间的层。如图4所示，内核层至少包含以下驱动中的至少一种：音频驱动、显示驱动、蓝牙驱动、摄像头驱动、wifi驱动、usb驱动、hdmi驱动、传感器驱动(如指纹传感器，温度传感器，压力传感器等)、以及电源驱动等。
97.以上实施例介绍了显示设备的硬件/软件架构以及功能实现等内容。在一些应用
场景中，对于支持atsc3.0标准的显示设备，则支持route(real
‑
time object delivery over unidirectional transport，单向实时对象传输协议)dash(dynamic adaptive streaming over http，基于http的动态自适应流媒体)媒体播放协议，它提供了一种服务端与播放器端流媒体传输与播放方案，服务端可将媒体内容分割为一系列segment(分片)，每个分片可具有不同的编码形式、分辨率和码率等，播放器端可根据自身的性能和带宽等情况，下载相应码率和分辨率的segment，并进行解复用、解码和播放。
98.route dash中引入mpd(media presentation description，媒体展示说明)，mpd是一种xml文件，完整记录了媒体信息，包括但不限于视频长度、不同segment的码率和分辨率、分片时长、各分片对应的url(uniform resource locator，资源定位符)等，显示设备端下载并解析媒体项目对应的mpd文件，可获取到与自身性能和带宽相匹配的分片序列。每个segment可由一个对应的url指定，也可由相同的url与不同的byte range(字节范围)指定，显示设备作为route dash客户端，可通过http协议来获取url对应的分片数据。
99.显示设备下载mpd文件后，解复用器(demux)首先对mpd文件进行解析，并通过url下载segment数据，然后对segment数据进行解复用处理，得到分离后音视频的es流数据，分别命名为视频流数据和音频流数据。视频流数据和音频流数据分别包括多个帧，音/视频流数据包的包头中记录有pts信息，pts为显示时间戳，用于指示解码后的音/视频帧的显示时间。作为一种示例，例如视频流数据包括3帧，其中第1帧在媒体数据起播时即刻显示，第2帧的pts指示为其在媒体起播后的第40ms启动显示，第3帧的pts指示为其在媒体起播后的第100ms启动显示，也就是说，第1帧的显示时间为0～40ms，第2帧的显示时间为40ms～100ms，第3帧的显示时间为100ms～播放结束，这样第1帧～第3帧的pts呈连续性，若因为某些异常因素导致丢帧，比如丢掉了第2帧，则第40ms～100ms出现间断，导致pts不连续。
100.在实际应用场景中，例如，由于不同频道对应的媒体数据不同，用户在切换频道时segment可能会发生跳变；又例如，route dash协议的解析依赖于plp包数据，在plp保数据解析异常时，可能出现segment数据与mpd文件的记录无法完全统一的现象，导致segment可能出现断片、缺片等跳变问题。在segment出现跳变时，由此会导致解复用后得到的es流数据的pts不连续，并由于解码器对pts敏感，一旦pts不连续，则解码器将无法正常解码，导致跳变数据无法被解码及播放，进而导致媒体数据播放过程中可能出现黑屏、卡顿、花屏等问题，若视频流数据的pts连续但音频流数据的pts不连续，或者音频流数据的pts连续但视频流数据的pts不连续，还可能会出现音画不同步问题。为消除这些问题，用户很多时候不得不进行播放重置，例如关闭并重启播放器，或者用户当前观看的频道1出现卡顿，需要切换到频道2，然后再切回频道1，然后看频道1播放效果是否改善，这些都需要用户手动操作去修复，严重降低用户观看体验。
101.为解决上述技术问题，如图5所示，在一些实施例中提供一种媒体数据跳变续播方法，该方法是从显示设备的控制器250的控制和执行角度进行描述，控制器250分别对解复用器、视频解码器、音频解码器、显示器和声音播放器进行控制，其中声音播放器可以是显示设备内置的扬声器，或者是通过如hdmi或蓝牙等方式连接的外部功放。具体地，所述方法包括如下程序步骤：
102.步骤s101，在接收到用户对媒体数据的点播操作时，起播所述媒体数据。
103.在一些示例性的实现方式中，所述媒体数据可以是数字电视的频道节目，也可能
是来自浏览器或视频应用的媒资，本技术不作具体限定。
104.步骤s102，是否监听到解复用器发送的discontinuous消息。
105.其中，解复用器在解析得到视频流数据和音频流数据后，分别对视频流数据和音频流数据的显示时间戳连续性进行检测。当解复用器检测到视频流数据和/或音频流数据的显示时间戳不连续，即音视频流数据中至少一种发生跳变时，解复用器都会生成discontinuous消息并进行广播发送。若控制器未监听到discontinuous消息，则执行步骤s103；反之，若控制器监听到discontinuous消息，则执行步骤s104～步骤s106。
106.步骤s103，保持当前播放状态继续播放所述媒体数据。
107.步骤s104，控制视频解码器和音频解码器执行seek操作。
108.当监听到discontinuous消息时，同时触发视频解码器和音频解码器内置的seek操作，所述seek操作是指音视频解码器暂停接收数据，并清空当前缓存的全部数据，相当于对音视频解码器进行重置，通过执行seek操作可规避音视频解码器对es流数据连续性的要求，从而克服因音视频解码器识别到pts不连续而导致的无法正常解码。这里同时触发音视频解码器的seek操作的目的在于，同步重置音视频解码器，保证后续在seek点续播跳变数据时音画保持同步。
109.步骤s105，在监听到视频解码器发送的第一seek完成消息和音频解码器发送的第二seek完成消息时，控制视频解码器获取并解码所述视频流数据，以及控制音频解码器获取并解码所述音频流数据；
110.步骤s106，控制显示器显示解码后的视频流数据，控制声音播放器播放解码后的音频流数据。
111.音视频解码器seek结束时，会广播发送seek done消息，为便于区分，将视频解码器发送的seek done消息命名为第一seek完成消息，将音频解码器发送的seek done消息命名为第二seek完成消息。控制器监听到第一seek完成消息和第二seek完成消息时，即可恢复向音视频解码器推送待解码的es流数据，由于在音视频解码器seek期间，pts不连续部分对应的音视频流跳变数据未被丢弃，因此使音视频解码器继续接收并解码数据，此时相当于直接seek到跳变数据的起始帧进行续播，即便媒体数据发生跳变也能实现自动接续(不间断)解码播放，无需用户手动修复，避免显示设备的黑屏、卡顿、花屏、音画不同步等问题，保证音视频播放的同步性和流畅性，并且基本不影响媒体数据的播放，提升用户观看体验。
112.作为一种示例，假设用户当前观看频道1，对于视频解码器的buffer，可以按照pts顺序对当前已缓存的视频流中的各帧进行排序，形成解码队列，解码队列中排序最末的一帧frame
i
即为当前最后被解码的帧，假设frame
i
的pts指示为在第60s显示，此时若用户切换至频道2，视频解码器无法识别频道已切换，实际上视频解码器接收到的下一帧frame
i 1
为频道2的视频流的起始帧，frame
i 1
的pts指示为在第0s(即频道2起播时)显示，显然视频解码器识别到相邻的frame
i
和frame
i 1
的pts不连续，即frame
i
和frame
i 1
之间发生跳变，则因无法正常解码而导致媒体播放出现问题。而通过本技术的处理机制，解复用器解析频道2的媒体数据后，检测到频道2视频流的起始帧frame
i 1
与解复用器其向视频解码器推送的前一帧frame
i
相比，pts无法连续，则发送discontinuous消息；控制器监听到discontinuous消息，则触发视频解码器的seek操作，视频解码器暂停接收视频流数据，并将当前已缓存的解码队列清空，seek完成后广播seek done，之后即可接收频道2视频流的起始帧frame
i 1
及其
后续的其他帧数据，由于frame
i
及其之前的视频帧数据都已清除，视频解码器已无法识别frame
i
和frame
i 1
的pts不连续，即可正常解码并起播频道2的视频流，有效避免了因切台出现数据跳变而导致视频播放出现问题。
113.在图5所示实施例的基础上，在一种示例性的实现方式中，控制器可创建第一链表和第二链表，第一链表用于在视频解码器seek期间缓存从解复用器接收到的视频流数据，第二链表用于在音频解码器seek期间缓存从解复用器接收到的音频流数据。在控制器监听到第一seek完成消息和第二seek完成消息时，音视频解码器即可恢复接收数据，具体地，控制视频解码器从第一链表中读取视频流数据，以及控制音频解码器从第二链表中读取音频流数据。该实现方式中通过链表保存解码器seek期间发生跳变的音视频流数据，便于后续解码器seek完成后访问链表，并读取链表中缓存的数据，即可在seek点解码并续播出现跳变的音视频流数据。可选地，在链表中缓存的数据被全部读取并消耗空后，可以释放链表资源，后续按照媒体数据连续场景下的常规播放流程执行即可。可选地，第一链表和第二链表可采用cache链表形式。
114.在一种示例性的实现方式中，前述媒体数据跳变续播机制可以应用于gstreamer播放器，gstreamer播放器是一种用于构建流媒体应用的开源多媒体架构，应用程序可以通过pipeline(管道)将多媒体播放处理中的各个环节串联起来，每个环节是基于创建对应的element(元素)来实现其功能。在pipeline运行过程中，各个element之间需要进行消息交互，可以在gstreamer播放器中创建bus(消息总线)，在pipeline中注册bus的回调函数，用以监听解复用器发送的discontinuous消息，也可监听如音视频解码器发送的seek done消息等，pipeline根据监听到的消息类型，触发对应的处理逻辑。
115.在一种示例性的实现方式中，图6示例一种媒体数据跳变续播机制下对应的pipeline结构，参照图6，该pipeline包括但不限于curlhttpsrc、typefind、dashdemux、qtdemux、inputselector_0、inputselector_1、videoessink和audioessink等element。
116.其中，curlhttpsrc用于根据用户起播观看的目标媒体的url链接，获取媒体数据，所述媒体数据包括所述目标媒体的mpd文件等；typefind用于根据目标媒体的容器类型，查找相匹配的解复用插件；dashdemux和qtdemux是解复用器中的两个插件，dashdemux用于解析mpd文件，得到目标媒体的相关播放信息以及获取segment数据等；qtdemux用于将segment数据处理为es流数据，即分离出视频流数据和音频流数据，本技术中在qtdemux环节中增设了检测视频流数据和音频流数据的pts连续性，在检测到视频流数据和/或音频流数据存在跳变，则生成并发送discontinuous消息；inputselector_0和inputselector_1是输入选择器，inputselector_0用于将qtdemux输出的视频流数据导入videoessink，inputselector_1用于将qtdemux输出的音频流数据导入audioessink，至此划分为两条支路，分别处理音频流和视频流的解码播放。
117.在一种示例性的实现方式中，videoessink和audioessink属于pipeline的末端插件，其中videoessink链接于inputselector_0和videodecoder(视频解码器)间，videodecoder从videoessink中读取视频流数据，并对视频流数据进行解码，并将解码后的视频流数据传输给显示器进行显示。可选地，videoessink作为第一目标插件，可用于创建并控制第一链表的功能实现。
118.audioessink链接于inputselector_1和audiodecoder(音频解码器)间，
audiodecoder从audioessink中读取音频流数据，并对音频流数据进行解码，并将解码后的音频流数据传输给声音播放器进行播放。可选地，audioessink作为第二目标插件，可用于创建并控制第二链表的功能实现。
119.对于图6所示pipeline，其工作流程为，当pipeline bus监听到qtdemux发送的discontinuous消息时，同时触发两个动作，动作一是对整个pipeline中的element进行遍历，查找到第一目标插件videoessink和第二目标插件audioessink，由于pipeline中每个element都具有全局唯一性的标识，例如每个element的名称都不同，通过识别标识即可在pipeline中定位及查找到指定的element，因此根据videoessink具备的第一标识以及audioessink具备的第二标识，来查找到videoessink和audioessink，然后将discontinuous消息同步通知到videoessink和audioessink，以使videoessink暂停向videodecoder推送视频流数据，将接收到的视频流数据缓存至第一链表，以及，使audioessink暂停向videodecoder推送音频流数据，将接收到的音频流数据先缓存到第二链表；动作二是分别触发videodecoder和audiodecoder的seek操作，之后videodecoder和audiodecoder在seek完成时即恢复从末端插件读取数据。
120.在pipeline bus监听到videodecoder和audiodecoder的seek完成消息时，pipeline将seek完成消息同步转发给videoessink和audioessink。videoessink接收到seek完成消息时，停止将视频流数据缓存在第一链表，转而将接收到的视频流数据缓存在videoessink默认的内存中，此时第一链表中缓存有跳变部分的视频流数据，videodecoder需要先读取第一链表中缓存的视频流数据，待第一链表中的数据被全部读取并消耗空时，可以释放第一链表占用的资源，关闭第一链表功能，之后videodecoder继续从videoessink的内存中读取视频流数据。
121.同理，audioessink接收到seek完成消息时，停止将音频流数据缓存在第二链表，转而将接收到的音频流数据缓存在audioessink默认的内存中，此时第二链表中缓存有跳变部分的音频流数据，audiodecoder需要先读取第二链表中缓存的音频流数据，待第二链表中的数据被全部读取并消耗空时，可以释放第二链表占用的资源，关闭第二链表功能，之后audiodecoder继续从audioessink的内存中读取音频流数据。媒体播放时，本技术能实现数据跳变时自动续播，使得pipeline可全程保持playing状态，不会因数据跳变而退化到pause状态、ready状态、null状态，改善数据跳变场景下的媒体播放效果。
122.可选地，videoessink中设置有第一render数据接收线程，即第一render数据接收线程链接于inputselector_0和videoessink，第一链表设置于第一render数据接收线程内；audioessink中设置有第二render数据接收线程，第二render数据接收线程链接于inputselector_1和audioessink，第二链表设置于第二render数据接收线程内。videodecoder中具有第一数据消耗线程，即第一数据消耗线程链接于videoessink与videodecoder；audiodecoder中具有第二数据消耗线程，即第二数据消耗线程链接于audioessink与audiodecoder。
123.当videoessink接收到discontinuous消息时，第一render数据接收线程将接收到的视频流数据缓存至第一链表中，第一数据消耗线程暂时处于阻塞状态，直至videoessink接收到seek完成消息，第一render数据接收线程停止将接收到的视频流数据存入第一链表，第一数据消耗线程恢复读取数据，首先读取第一链表中缓存的视频流数据，每读取完一
帧即可将该帧数据从第一链表中清除，这样第一链表中的数据会被逐渐消耗，当消耗为空时，第一链表中的数据已被videodecoder全部读取完毕，则释放第一链表cache，第一数据消耗线程继续读取并消耗第一render数据接收线程所接收的视频流数据。
124.当audioessink接收到discontinuous消息时，第二render数据接收线程将接收到的音频流数据缓存至第二链表中，第二数据消耗线程暂时处于阻塞状态，直至audioessink接收到seek完成消息，第二render数据接收线程停止将接收到的音频流数据存入第二链表，第二数据消耗线程恢复消耗数据，首先读取第二链表中缓存的音频流数据，每读取完一帧即可将该帧数据从第二链表中清除，这样第二链表中的数据会被逐渐消耗，当消耗为空时，第二链表中的数据已被audiodecoder全部读取完毕，则释放第二链表cache，第二数据消耗线程继续读取并消耗第二render数据接收线程所接收的音频流数据。
125.在一些实施例中，pipeline bus未监听到qtdemux发送的discontinuous消息时，保持当前的播放状态，按照正常的播放流程处理即可，videodecoder和audiodecoder均不执行seek操作，并且videoessink和audioessink的链表功能均处于关闭状态，videodecoder可持续地从videoessink读取视频流数据，audiodecoder可持续地从audioessink读取音频流数据。
126.在一些示例性的实现方式中，第一链表可以预设在videoessink中，第二链表可以预设在audioessink中，在es数据出现跳变时，调用链表功能去缓存末端插件在解码器seek期间所接收的数据；在解码器seek完成后，第一链表和第二链表无数据存入，仅消耗数据，即处于“只出不进”状态，当第一链表和第二链表中的数据消耗空时，释放掉链表占用的资源，关闭链表功能，从而可恢复至正常播放流程。
127.在其他示例性的实现方式中，videoessink也可在每次接收到discontinuous消息时临时创建第一链表，audioessink也可在每次接收到discontinuous消息时临时创建第二链表，并执行链表功能，在解码器seek完成后，第一链表和第二链表中的数据被消耗空时，将第一链表和第二链表销毁即可。需要说明的是，链表的创建和维护等功能实现方式不限于本技术实施例所述。
128.在一些示例性的实现方式中，参照图6示例的pipeline架构，为便于videoessink/audioessink接收并响应discontinuous消息和seek done消息，可选择为videoessink和audioessink分别扩展属性接口，为便于区分，在videoessink中预设第一属性接口，audioessink中预设第二属性接口。pipeline通过bus监听到discontinuous消息时，会遍历各element，以定位查找到videoessink和audioessink，然后pipeline将第一属性接口设置为第一属性值，将第二属性接口设置为第二属性值，所述第一属性值用于指示videoessink将接收到的视频流数据缓存在第一链表中，所述第二属性值用于指示audioessink将接收到的音频流数据缓存在第二链表中。
129.作为一种示例，例如第一属性接口配置的属性为“play
‑
state
‑
is
‑
ready”，第一属性值为false，videoessink读取到“play
‑
state
‑
is
‑
ready”＝false，即接收到当前播放状态未准备好的消息指示，则调用链表功能，将接收到的视频流数据先缓存于第一链表中。audioessink的第二属性接口设置与videoessink基本相同，这里不再赘述。
130.在一种示例性的实现方式中，pipeline通过bus监听到音视频解码器发送的seek done消息时，pipeline将第一属性接口变更为第三属性值，将第二属性接口变更为第四属
性值，所述第三属性值用于指示videoessink停止将视频流数据缓存在第一链表中，并将后续接收到的视频流数据缓存在自身的内存中；所述第四属性值用于指示audioessink停止将音频流数据缓存在第二链表中，并将后续接收到的音频流数据缓存在自身的内存中。
131.作为一种示例，例如第一属性接口配置的属性为“play
‑
state
‑
is
‑
ready”，第三属性值为true，videoessink读取到“play
‑
state
‑
is
‑
ready”＝true，即接收到播放状态已准备就绪的消息指示，则关闭第一链表的接收功能，即停止将视频流数据继续缓存在第一链表中，而后续所接收的视频流数据(认为解码器seek后pts已恢复连续状态)默认缓存在videoessink的内存中，此时videodecoder先读取在其seek期间第一链表中缓存的视频流数据，待第一链表中数据读取并消耗为空时，再转而从videoessink的内存中继续读取视频流数据，从而保证视频流数据解码播放的有序性和连续性。audioessink的第二属性接口设置与videoessink基本相同，这里不再赘述。
132.如图7所示，在一些实施例中提供另一种媒体数据跳变续播方法，该方法是从gstreamer播放器中pipeline的控制和执行角度进行描述，pipeline的架构和包括的element可参照图6的示例，所述方法包括如下程序步骤：
133.步骤s201，在设置route dash url后，启动gstreamer播放器。
134.在实际应用中，atsc3.0 route dash协议解析完成后，媒体数据通过回调方式被放入local server(本地服务)中，设置route dash url的播放链接之后，启动gstreamer播放器，即可执行后续的播放器内pipeline的跳变续播流程或正常播放流程。
135.步骤s202，注册bus监听函数。
136.步骤s203，是否监听到qtdemux发送的discontinuous消息。
137.若pipeline通过bus未监听到discontinuous消息，则执行步骤s204；反之，若pipeline通过bus监听到discontinuous消息，则执行步骤s205～步骤s106。
138.步骤s204，保持当前播放状态继续播放所述媒体数据。
139.步骤s205，控制videodecoder和audiodecoder执行seek操作。
140.步骤s206，遍历pipeline内部element，查找到videoessink和audioessink。
141.其中，步骤s205和步骤s206可在监听到discontinuous消息时被同时触发执行。
142.步骤s207，设置第一属性接口为第一属性值，设置第二属性接口为第二属性值。
143.步骤s208，videoessink将视频流数据缓存入第一链表，audioessink将音频流数据缓存入第二链表。
144.步骤s209，是否监听到videodecoder和audiodecoder的seek done消息。若pipeline通过bus未监听到seek done消息，则继续等待；若pipeline通过bus监听到seek done消息，则执行步骤s210。
145.步骤s210，设置第一属性接口为第三属性值，设置第二属性接口为第四属性值。
146.步骤s211，videodecoder从第一链表读取视频流数据，audiodecoder从第二链表读取音频流数据。
147.步骤s212，在seek点起播音视频流数据。
148.在步骤s212之后，即可根据第一链表和第二链表中数据的消耗状态，确定是否关闭链表功能以及恢复至正常播放流程，具体请参照前述实施例的说明，此处不再赘述。
149.本技术中提及的atsc3.0、route dash、gstreamer和pipeline等更细节的内容可
适应性参照现有技术，本技术不再对其基础内容和通用的处理流程进行解释说明。另外，本技术中媒体数据跳变续播机制不局限应用于gstreamer播放器。
150.本领域技术人员可清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。具体实现中，本发明还提供一种计算机存储介质，该计算机存储介质可存储有程序。当计算机存储介质位于显示设备200中时，该程序执行时可包括前述各实施例中的媒体数据跳变续播方法所涉及的程序步骤。其中，计算机存储介质可为磁碟、光盘、只读存储记忆体(英文：read
‑
only memory，简称rom)或随机存储记忆体(英文：random access memory，简称ram)等。
151.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。
152.为了方便解释，已经结合具体的实施方式进行了上述说明。但是，上述示例性的讨论不是意图穷尽或者将实施方式限定到上述公开的具体形式。根据上述的教导，可以得到多种修改和变形。上述实施方式的选择和描述是为了更好的解释原理以及实际的应用，从而使得本领域技术人员更好的使用所述实施方式以及适于具体使用考虑的各种不同的变形的实施方式。