显示设备及数据处理方法

技术领域

本申请实施例涉及数据处理技术。更具体地讲，涉及一种显示设备及数据处理方法。

背景技术

随着终端技术的不断发展，投屏技术越来越成熟。尤其将小屏设备上的媒资投屏到大屏设备(显示设备)上进行播放，能够为用户提供更好地观看体验。

在投屏视频流传输过程中，有些类型的设备的一帧视频数据包括一个包基本流(Packetized Elementary Stream，pes)数据，有些类型的设备的一帧视频数据包括多个pes数据，且目前在解复用(demux)的过程中通常不进行parse的处理(即分析每个pes包的帧头，将属于一帧视频数据的多个pes包合成为一帧数据处理)，一个pes数据经过解复用处理之后，得到一个基础流(Elementary Stream，es)数据。因此，对于一帧视频数据包括多个pes数据的情况，多个pes数据经过解复用处理之后得到多个es数据，多个es数据会被分别送到解码器(decoder)中(即属于一帧视频数据的数据会分多次送到decoder中)进行解码处理，如此就会导致decoder对于的输出缓冲区(outputbuffer)和输入缓冲区(inputbuffer)的个数存在差异。

然而，在安卓系统一些较新的版本中，decoder机制发生了变化，底层会去检测outputbuffer和inputbuffer的个数差异，若是个数差异超过一定阈值，会触发底层异常，不再工作，进而导致投屏过程卡住，用户体验较差。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请实施例提供了一种显示设备及数据处理方法，可以避免投屏过程卡住，提高投屏流畅度。

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

控制器，被配置为：获取接收到的第一帧包基本流数据；

对第一帧包基本流数据进行第一解复用处理，得到第一帧基础流数据，第一解复用处理不包括parse处理；

在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，第二解复用处理包括parse处理。

第二方面，本申请实施例提供了一种数据处理方法，包括：

获取接收到的第一帧包基本流数据；

对第一帧包基本流数据进行第一解复用处理，得到第一帧基础流数据，第一解复用处理不包括parse处理；

在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，第二解复用处理包括parse处理。

第三方面，本申请实施例提供了一种计算机可读存储介质，包括：计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如第二方面所示的数据处理方法。

第四方面，本申请实施例提供了一种计算机程序产品，包括：当计算机程序产品在计算机上运行时，使得计算机实现如第二方面所示的数据处理方法。

本申请实施例提供的技术方案与现有技术相比具有如下优点：本申请实施例中，获取接收到的第一帧包基本流数据；对第一帧包基本流数据进行第一解复用处理，得到第一帧基础流数据，第一解复用处理不包括parse处理；在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，第二解复用处理包括parse处理。在对当前帧包基本流数据进行不包括parse处理的解复用处理得到当前帧基础流数据之后，在当前帧基础流数据的时间戳与上一帧基础流数据的时间戳相同的情况下，说明当前帧基础流数据与上一帧基础流数据属于同一帧视频数据，也就是说一帧视频数据被分为多个包基础流数据，多个包基础流数据经过第一解复用处理之后，会分别被送到decoder，然后底层会检测到outputbuffer和inputbuffer的个数差异，当个数差异超过一定阈值时，会触发底层异常，不再工作，进而导致投屏过程卡住，用户体验较差。因此，本申请实施例中，在当前帧基础流数据的时间戳与上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行包括parse处理的第二解复用处理，从而在对接收到的包基础流数据进行解复用处理时，会分析一帧包基础流数据是否是一帧完整的视频数据，如果不是，会将属于一帧视频数据的包基础流数据进行合成为一帧数据，如此，可以使得送入decoder的数据是一帧视频数据，不会导致outputbuffer和inputbuffer的个数差异，进而也就不会因outputbuffer和inputbuffer的个数差异触发底层异常，导致投屏过程卡住，可以提高投屏的流畅性，提高用户体验。

附图说明

为了更清楚地说明本申请实施例或相关技术中的实施方式，下面将对实施例或相关技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

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

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

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

图4示出了根据一些实施例的投屏示意图；

图5示出了根据一些实施例的投屏过程的软件架构示意图；

图6示出了根据一些实施例的数据处理方法的流程示意图之一；

图7示出了根据一些实施例的数据处理方法的流程示意图之二；

图8示出了根据一些实施例的数据处理方法的流程示意图之三；

图9示出了根据一些实施例的数据处理方法的流程示意图之四；

图10示出了根据一些实施例的数据处理方法的流程示意图之五；

图11示出了根据一些实施例的数据处理方法的流程示意图之六。

具体实施方式

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

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

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

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

本申请实施方式提供的显示设备可以具有多种实施形式，例如，可以是电视、智能电视、激光投影设备、显示器(monitor)、电子白板(electronic bulletin board)、电子桌面(electronic table)、手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备等。

图1为根据实施例中显示设备与控制设备之间操作场景的示意图，其中控制设备包括智能设备或控制装置。如图1所示，用户可通过智能设备300或控制装置100操作显示设备200。

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

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

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

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

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

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

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

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

用户接口280，可用于接收控制装置100(如：红外遥控器等)的控制信号。也可以用于直接接收用户的输入操作指令，且将操作指令转换为显示设备200可识别和响应的指令，此时可以称为用户输入接口。

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

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

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

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

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

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

其中，RAM也叫主存，是与控制器直接交换数据的内部存储器。它可以随时读写(刷新时除外)，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储介质。它与ROM的最大区别是数据的易失性，即一旦断电所存储的数据将随之丢失。RAM在计算机和数字系统中用来暂时存储程序、数据和中间结果。ROM以非破坏性读出方式工作，只能读出无法写入信息。信息一旦写入后就固定下来，即使切断电源，信息也不会丢失，所以又称为固定存储器。

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

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

如今投屏看电视已成为广大用户使用智能电视的一项基本使用需求，投屏过程的视频播放体验也越来越重要。本申请实施例主要应用在移动电子设备(如手机)端或者非移动电子设备(如个人计算机(Personal Computer，PC))端投屏，即实时把移动电子设备端或者非移动电子设备端的画面在电视端播放的镜像投屏场景，以提高投屏的播放流畅度。如图4所示，为将手机端或PC端的视频画面镜像投屏到电视端显示的示意图。

本申请实施例中的镜像投屏可以包括mircast投屏，airplay投屏，自研协议比如说实时传输协议(Real-time Transport Protocol或简写RTP)+用户数据报协议(UDP，UserDatagram Protocol)投屏等，具体可以根据实际情况确定，此处不做限定。

以下以mircast投屏为例介绍：

mircast是封装的一种实时流传输协议(Real Time Streaming Protocol，RTSP)，目前由上层应用进行解密得到传输流(Transport Stream，ts)供播放器进行播放。

micrast投屏播放架构如下图5所示，播放器端收到应用端的播放请求后，会先创建播放器。设置surface后，开始配置播放器，根据投屏场景配置解码器，待投屏数据来了后，读取数据开始投屏。

miracast要求投屏延迟在100ms以内，为了达到该目标，因此播放器中在demux时采取不parse的策略，这样的话可以减少一帧缓存，从而降低时延。目前市场上大多数设备(如手机等)都是一帧视频数据(video)是一个pes数据，然而有些设备存在一帧视频数据分为了2个pes数据，在将每个pes数据进行不包括parse的解复用处理之后，输出的es数据送decoder时，属于一帧视频数据的2个pes因不进行parse，故解复用得到的2个es数据分2次送到decoder进行解码处理。

在支持安卓系统一些较新的版本(Android 13(T)之后的版本)的设备中decoder机制有变化，底层会去检测outputbuffer和inputbuffer的个数差异，若是个数差的的过多，会触发底层异常，不再工作，导致投屏过程卡住，用户投屏体验不好。

本申请实施例提供了一种显示设备及数据处理方法，其中，显示设备可以实现本申请实施例提供的数据处理方法或者显示设备中的功能模块或功能实体可以实现本申请实施例提供的数据处理方法。该显示设备包括：控制器，对应上述图3中的控制器250。

本申请一些实施例中，控制器，被配置为：获取接收到的第一帧包基本流数据；对第一帧包基本流数据进行第一解复用处理，得到第一帧基础流数据，第一解复用处理不包括parse处理；在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，第二解复用处理包括parse处理。

其中，第一帧包基本流数据为一帧pes数据，第一帧基础流数据为一帧es数据，第一解复用处理为不采用parse处理的demux，第二解复用处理为采用parse处理的demux。

其中，一帧包基础流数据的时间戳为该一帧包基础流数据所属的一帧视频数据的时间戳；一帧基础流数据的时间戳也为该一帧基础流数距所属的一帧视频数据的时间戳，在一帧包基础数据进行解复用得到一帧基础流数据的情况下，该一帧包基础数据的时间戳与该一帧基础流数据的时间戳相同。

可以理解，若一帧视频数据仅有一个pes数据，则第一帧基础流数据对应一帧完整的视频数据，第一帧基础流数据对应的上一帧基础流数据也对应一帧完整的是数据，第一帧基础流数据的时间戳和上一帧基础流数据的时间戳，分别为对应的基础流数据所属的一帧视频数据的时间戳，因此第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳不同，若每次都是属于一帧视频数据的es数据被送入decoder进行解码，则decoder对应的outputbuffer和inputbuffer的不会发生个数差异。

可以理解，若一帧视频数据包括多个pes数据，以下以一帧视频数据包括2个pes数据为例，若通过不采用parse处理的demux对pes数据进行解复用处理，则对属于一帧视频数据的两个相邻帧pes数据进行解复用处理之后，得到的两个相邻帧es数据的时间戳相同；对不属于一帧视频数据的两个相邻帧pes数据进行解复用处理之后，得到的两个相邻帧es数据的时间戳不同。因此，若一直通过不采用parse处理的demux对pes数据进行解复用处理，则对于每处理属于一帧视频数据的两个相邻帧pes数据，decoder对应的outputbuffer和inputbuffer的个数差异就会加1，如此，累加下去，就会因outputbuffer和inputbuffer的个数差异超过一定阈值，触发底层异常，不再工作，导致投屏过程卡住，用户投屏体验不好。

可以理解，在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳不同的情况下，不能确定一帧视频数据是否包括多个pes数据，但是在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，可以确定一帧视频数据包括多个pes数据。

本申请实施例中，在对当前帧包基本流数据进行不包括parse处理的解复用处理得到当前帧基础流数据之后，在当前帧基础流数据的时间戳与上一帧基础流数据的时间戳相同的情况下，说明当前帧基础流数据与上一帧基础流数据属于同一帧视频数据，也就是说一帧视频数据被分为多个包基础流数据，多个包基础流数据经过第一解复用处理之后，会分别被送到decoder，然后底层会检测到outputbuffer和inputbuffer的个数差异，当个数差异超过一定阈值时，会触发底层异常，不再工作，进而导致投屏过程卡住，用户体验较差。因此，本申请实施例中，在当前帧基础流数据的时间戳与上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行包括parse处理的第二解复用处理，从而在对接收到的包基础流数据进行解复用处理时，会分析一帧包基础流数据是否是一帧完整的视频数据，如果不是，会将属于一帧视频数据的包基础流数据进行合成为一帧数据，如此，可以使得送入decoder的数据是一帧视频数据，不会导致outputbuffer和inputbuffer的个数差异，进而也就不会因outputbuffer和inputbuffer的个数差异触发底层异常，导致投屏过程卡住，可以提高投屏的流畅性，提高用户体验。

本申请一些实施例中，由于若一帧视频数据包括多个pes数据，则控制对每一针pes数据进行采用parse处理的demux，则会造成投屏延时过大，也会导致用户投屏体验较差。而且底层不是检测到outputbuffer和inputbuffer存在个数差异，就触发底层异常，而是当个数差异超过一定阈值时才触发底层异常。因此，本申请实施例中，该控制器，具体被配置为：在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，第一计数器计数加1；在第一计数器的计数值等于第一计数阈值的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，并对第一计数器进行置零处理。

其中，第一计数阈值可以根据触发底层异常的outputbuffer和inputbuffer的个数差异的最小值确定，第一计数阈值小于触发底层异常的outputbuffer和inputbuffer的个数差异的最小值，具体可以根据实际情况确定，此处不做限定。

可以理解，通过设置第一计数器统计相邻两帧基础流数据的时间戳相同的次数，每次检测到相邻两帧基础流数据的时间戳相同，则第一计数器计数加1，当第一计数器的计数值等于第一计数阈值时，确定下一帧基础流数据进行采用parse的demux，具体可以为，当第一计数器的计数值等于第一计数阈值时，开启demux中的parse。同时第一计数器的计数值清零。如此，在对下一帧基础流数据进行demux时采用包括parse的demux，进而在demux时会将属于一帧视频数据的多个pes数据合成为一个数据，demux之后输出的es数据也就对应一帧视频数据，进而不会导致底层因outputbuffer和inputbuffer的个数差异而触发异常，可以提高投屏的流畅度。而且第一计数器清零不会使得显示设备重复开启demux中的parse。

本申请一些实施例中，可以在第一计数器计数加1之后，判断第一计数器的计数值是否等于第一计数阈值，若第一计数器的计数值等于第一计数阈值，则开启demux中的parse，并在接收到下一帧包基础流数据之后，对下一帧包基础流数据进行第二解复用处理；也可以在接收到下一帧包基础流数据之后，判断第一计数器的计数值是否等于第一计数阈值，若第一计数器的计数值等于第一计数阈值，则开启demux中的parse，并对下一帧包基础流数据进行第二解复用处理；具体可以根据实际情况确定，此处不做限定。

本申请一些实施例中，该控制器，还被配置为：在第一计数器的计数值小于第一计数阈值的情况下，对接收到的下一帧包基础流数据进行第一解复用处理(此时第一计数器的计数值不变)。如此，在不触发底层异常的情况下，可以降低投屏时延。

本申请一些实施例中，该控制器，还被配置为：在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳不同的情况下，对接收到的下一帧包基础流数据进行第一解复用处理(此时第一计数器的计数值不变)。如此，在不触发底层异常的情况下，可以降低投屏时延。

本申请一些实施例中，在投屏开始时，默认使用不包括parse处理的demux对基础流数据进行解复用处理，如此，可以在投屏开始降低投屏时延，同时开启第一计数器，并在每次检测到相邻两帧基础流数据的时间戳相同的情况下，第一计数器计数加1，直至第一计数器的计数值等于第一计数阈值，开启demux中的parse，以对下一帧基础流数据进行包括parse处理的demux处理。

本申请一些实施例中，在开启demux中的parse之后，为了降低投屏时延，可以在预设时长之后或第二计数器的技术值等于第二计数阈值的情况下，将demux去parse，即禁止demux中的parse，也即下一帧基础流数据执行不采用parse的demux。其中，预设时长可以根据实际情况确定，第二计数阈值也可以根据实际情况确定，预设时长、第二计数阈值可以根据底层统计的outputbuffer和inputbuffer的个数差异清零所需时长确定。其中，预设时长大于或等于个数差异清零所需时长，第二计数阈值大于或等于个数差异清零所需时长内，解复用包基础流数据的帧数。

本申请实施例中，预设时长和第二计数阈值，还可以根据投屏时延确定，具体可以根据实际情况确定，此处不做限定。

示例性地，通常情况下，预设时长为1s，第二计数阈值为1s内解复用包基础流数据的帧数。

本申请实施例中，在对第一计数器置零处理之后，开启第二计时器，且每次检测到相邻两帧基础流数据的时间戳不相同时，第二计数器计数加1。

本申请一些实施例中，该控制器，还被配置为：在该对接收到的下一帧包基础流数据进行第二解复用处理，并对第一计数器进行置零处理之后，获取接收到的第二帧包基础流数据；对第二帧包基础流数据进行第二解复用处理，得到第二帧基础流数据；第二计数器计数加1；在第二计数器的计数值等于第二计数阈值的情况下，对接收到的下一帧包基础流数据进行第一解复用处理，并对第二计数器进行置零处理。

可以理解，由于parse是对属于一帧视频数据的多个包基础流数据合成一帧数据，因此在开启demux中的parse之后，demux输出的基础流数据是对应一帧完整视频数据的数据，因此，任意相邻的两帧基础流数据分别属于不同的两帧视频数据，进而任意相邻的两帧基础流数据的时间戳不同。

本申请实施例中，在通过第二计数器统计相邻两帧基础流数据的时间戳不同的次数等于第二计数阈值时，去掉demux中的parse，以对下一帧接收到的包基础流数据进行不包括parse的demux，如此，可以在一定程度上降低投屏时延。而且对第二计数器进行置零处理，可以表面反复进行去掉demux中的parse的操作。

本申请实施例中，在对第二计数器进行置零处理的同时，开启第一计数器开始计数。

本申请一些实施例中，该控制器，还被配置为：在第二计数器的计数值小于第二计数阈值的情况下，对接收到的下一帧包基础流数据进行第一解复用处理。如此，可以保证不会导致outputbuffer和inputbuffer的个数差异增加，不会触发底层异常。

本申请实施例中，通过根据实时检测相邻两帧基础流数据的时间戳相同或者不同的个数(相邻两帧基础流数据的时间戳不同，说明一帧视频数据没有被分成多帧包基础流数据，若是相邻两帧基础流数据的时间戳相同，则说明一帧视频数据没有被分成多帧包基础流数据)，灵活开启parse或去parse，以切换解复用是否包括parse，从而实现低延时模式下视频流畅播放。如此既能保证一定的投屏低延时又能流畅投屏，提高用户投屏使用过程中的体验。

示例性地，手机端和电视端通过rtsp协议进行视频流的控制和传输，投屏协议端解析收到的数据包，创建播放器，播放器配置(configure)时设置低延时属性等，同时协议端解析ts流数据，把解析得到的包基础流数据放到buffer中，播放器端从buffer中读取视包基础流数据进行demux，若是投屏低延时模式，则开始默认不parse，demux后比较当前帧基础流数据的时间戳和上一帧基础流数据的时间戳是否相同，若当前帧基础流数据的时间戳和上一帧基础流数据的时间戳相同，则第一计数器计数加1，当第一计数器的计数值等于阈值5时，开启demux中的parse，第一计数器的计数值清零；若是当前帧基础流数据的时间戳和上一帧基础流数据的时间戳不同，则第二计数器计数加1。本申请实施例中，通过实时检测，实时切换，实现投屏低延时又能流畅投屏。

为了更加详细的说明本方案，以下将以示例性的方式结合图6至图10进行说明，可以理解的是，图6至图10中所涉及的步骤在实际实现时可以包括更多的步骤，或者更少的步骤，并且这些步骤之间的顺序也可以不同，以能够实现本申请实施例中提供的数据处理方法为准。该数据处理方法应用于通过控制设备进行控制的显示设备，该数据处理方法的执行主体可以为显示设备，也可以为显示设备中能够实现该数据处理方法的功能模块或功能实体，此处不做限定。而且对本申请实施例提供的数据处理方法的具体描述可以参考对上述显示设备的相关描述，且可以实现相同或相似的技术效果，此处不再赘述。

图6为根据本申请一个或多个实施例实现数据处理方法的步骤流程图，该数据处理方法可以包括下述S601至S603。

S601、获取接收到的第一帧包基本流数据。

S602、对第一帧包基本流数据进行第一解复用处理，得到第一帧基础流数据，第一解复用处理不包括parse处理。

S603、在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，第二解复用处理包括parse处理。

本申请一些实施例中，结合图6，如图7所示，上述S603具体可以通过下述S603a至S603b实现。

S603a、在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳相同的情况下，第一计数器计数加1。

S603b、在第一计数器的计数值等于第一计数阈值的情况下，对接收到的下一帧包基础流数据进行第二解复用处理，并对第一计数器进行置零处理。

本申请一些实施例中，结合图7，如图8所示，在上述S603a之后，本申请实施例中还可以包括下述S604。

S604、在第一计数器的计数值小于第一计数阈值的情况下，对接收到的下一帧包基础流数据进行第一解复用处理。

在上述S604之后，返回执行上述S601，如此循环往复执行上述S601至S605之中的部分或全部步骤，直至执行S603b。

本申请一些实施例中，结合图8，如图9所示，在上述S602之后，本申请实施例中还可以包括下述S605。

S605、在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳不同的情况下，对接收到的下一帧包基础流数据进行第一解复用处理。

其中，在第一帧基础流数据的时间戳，与第一帧基础流数据对应的上一帧基础流数据的时间戳不同的情况下，保持第一计数器的计数值不变。

在上述步骤S605之后，返回执行上述S601，如此循环往复执行上述S601至S605之中的部分或全部步骤，直至执行S603b。

本申请一些实施例中，结合图9，如图10所示，在上述S603之后，本申请实施例中还可以包括下述S606至S609。

S606、获取接收到的第二帧包基础流数据。

S607、对第二帧包基础流数据进行第二解复用处理，得到第二帧基础流数据。

S608、第二计数器计数加1。

S609、在第二计数器的计数值等于第二计数阈值的情况下，对接收到的下一帧包基础流数据进行第一解复用处理，并对第二计数器进行置零处理。

本申请实施例在，在上述步骤S609之后，返回执行上述步骤S601，如此循环往复执行上述步骤S601至S609中的全部或部分步骤，直到投屏结束为止。

本申请一些实施例中，结合图10，如图11所示，在上述S608之后，本申请实施例中还可以包括下述S610。

S610、在第二计数器的计数值小于第二计数阈值的情况下，对接收到的下一帧包基础流数据进行第一解复用处理。

本申请实施例在，在上述步骤S610之后，返回执行上述步骤S606，如此循环往复执行上述S606至S610中的全部或部分步骤，直至S609之后，返回执行上述步骤S601。

本发明实施例提供还提供了一种计算机可读存储介质，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现上述数据处理方法执行的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，该计算机可读存储介质可以为只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

本发明提供一种计算机程序产品，包括：当所述计算机程序产品在计算机上运行时，使得所述计算机实现上述的数据处理方法。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

为了方便解释，已经结合具体的实施方式进行了上述说明。但是，上述示例性的讨论不是意图穷尽或者将实施方式限定到上述公开的具体形式。根据上述的教导，可以得到多种修改和变形。上述实施方式的选择和描述是为了更好的解释原理以及实际的应用，从而使得本领域技术人员更好的使用所述实施方式以及适于具体使用考虑的各种不同的变形的实施方式。