CN115734011A - 视频数据的处理方法及视频播放系统 - Google Patents

Abstract

本发明涉及视频数据的处理方法、视频播放系统，以及计算机可读存储介质。该视频数据的处理方法应用于该视频播放系统，包括以下步骤：提供系统层接口及应用层接口；经由所述系统层接口或所述应用层接口，获取视频数据；以及响应于从所述系统层接口获取的视频数据，设置系统层的第一解码单元对所述视频数据进行解码处理，并从所述系统层向视频播放器传输解码数据。通过执行这些步骤，该视频数据的处理方法能够提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

Description

视频数据的处理方法及视频播放系统

技术领域

本发明涉及视频数据的处理技术，尤其涉及一种视频数据的处理方法、一种视频播放系统，以及一种计算机可读存储介质。

背景技术

随着汽车工业的不断发展，车机系统与手机终端的互联技术(以下简称：车机互联技术)已经被广泛应用到各大主流品牌的车辆。通过集成车机互联方案，车机系统可以充分利用手机侧的算力来实现驾驶导航、影音播放等各种扩展功能，从而为用户提供功能更加丰富的使用体验。

目前市场上主要包括苹果的CarPlay、百度的Carlife、华为的HiCar、博泰的擎Mobile和亿联等多种主流的车机互联方案。这些车机互联方案都需要针对视频元素流(Element Stream，ES)的播放方案，先将手机侧传输的视频ES数据解码为图像数据，再将解码获得的图像数据渲染输出到车机屏幕上。

然而，现有的车机互联技术涉及大量不同的硬件方案和系统接口，不具备统一的标准通信接口，需要上层互联应用(Application，App)针对各种平台单独进行适配，因而增加了互联App的开发难度。此外，现有的视频元素流播放方案普遍涉及系统层与应用层的多次数据交换，会造成车机系统CPU的额外占用，并导致车机系统性能下降。

为了克服现有技术存在的上述缺陷，本领域亟需一种视频数据处理技术，用于提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之前序。

为了克服现有技术存在的上述缺陷，本发明提供了一种视频数据的处理方法、一种视频播放系统，以及一种计算机可读存储介质，能够提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

具体来说，本发明的第一方面提供的上述视频数据的处理方法应用于视频播放系统，包括以下步骤：提供系统层接口及应用层接口；经由所述系统层接口或所述应用层接口，获取视频数据；以及响应于从所述系统层接口获取的视频数据，设置系统层的第一解码单元对所述视频数据进行解码处理，并从所述系统层向视频播放器传输解码数据。通过执行这些步骤，该视频数据的处理方法能够提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

本发明的第二方面提供的上述视频播放系统包括存储器及处理器。所述处理器连接所述存储器，并被配置用于实施本发明的第一方面提供的上述视频数据的处理方法。通过实施该视频数据的处理方法，该视频播放系统能够提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

本发明的第三方面提供的上述计算机可读存储介质，其上存储有计算机指令。所述计算机指令被处理器执行时，实施本发明的第一方面提供的上述视频数据的处理方法。通过实施该视频数据的处理方法，该计算机可读存储介质能够提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了根据本发明的一些实施例提供的初始化视频播放系统的流程示意图。

图2示出了根据本发明的一些实施例提供的开发插件的流程示意图。

图3示出了根据本发明的一方面提供的视频数据处理方法的流程示意图。

图4示出了根据本发明的一些实施例提供的视频元素流播放方案的示意图。

图5示出了根据本发明的一些实施例提供的通用播放控制接口的示意图。

图6示出了根据本发明的一些实施例提供的互联应用的系统层实现的示意图。

图7A示出了传统的视频输出缓冲队列的示意图。

图7B示出了根据本发明的一些实施例提供的视频输出缓冲队列的示意图。

具体实施方式

以下由特定的具体实施例说明本发明的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本发明的其他优点及功效。虽然本发明的描述将结合优选实施例一起介绍，但这并不代表此发明的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介绍的目的是为了覆盖基于本发明的权利要求而有可能延伸出的其它选择或改造。为了提供对本发明的深度了解，以下描述中将包含许多具体的细节。本发明也可以不使用这些细节实施。此外，为了避免混乱或模糊本发明的重点，有些具体细节将在描述中被省略。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

另外，在以下的说明中所使用的“上”、“下”、“左”、“右”、“顶”、“底”、“水平”、“垂直”应被理解为该段以及相关附图中所绘示的方位。此相对性的用语仅是为了方便说明之用，其并不代表其所叙述的装置需以特定方位来制造或运作，因此不应理解为对本发明的限制。

能理解的是，虽然在此可使用用语“第一”、“第二”、“第三”等来叙述各种组件、区域、层和/或部分，这些组件、区域、层和/或部分不应被这些用语限定，且这些用语仅是用来区别不同的组件、区域、层和/或部分。因此，以下讨论的第一组件、区域、层和/或部分可在不偏离本发明一些实施例的情况下被称为第二组件、区域、层和/或部分。

如上所述，现有的车机互联技术涉及大量不同的硬件方案和系统接口，不具备统一的标准通信接口，需要上层互联App针对各种平台单独进行适配，因而增加了互联App的开发难度。此外，现有的视频元素流播放方案普遍涉及系统层与应用层的多次数据交换，会造成车机系统CPU的额外占用，并导致车机系统性能下降。

为了克服现有技术存在的上述缺陷，本发明提供了一种视频数据的处理方法、一种视频播放系统，以及一种计算机可读存储介质，能够提供系统层和应用层的通用播放控制接口以便于不同互联App的接入，并取消视频数据在系统层与应用层之间多次交换的需求以提升车机系统的性能。

在一些非限制性的实施例中，本发明的第一方面提供的上述视频数据的处理方可以由本发明的第二方面提供的上述视频播放系统来实施。具体来说，该视频播放系统包括但不限于车辆的车载信息娱乐(In-Vehicle Infotainment，IVI)系统，其上配置有存储器及处理器。该存储器包括但不限于本发明的第三方面提供的上述计算机可读存储介质，其上存储有计算机指令。该处理器连接该存储器，被配置用于执行该存储器上存储的计算机指令，以实施本发明的第一方面提供的上述视频数据的处理方法。

以下将结合一些视频数据的处理方法来描述该视频播放系统的工作原理。本领域的技术人员可以理解，这些视频数据的处理方法只是本发明提供一些非限制性的实施方式，旨在清楚地展示本发明的主要构思，并提供一些便于公众实施的具体方案，而非用于限制该视频播放系统的全部工作方式或全部功能。同样地，该视频播放系统也只是本发明提供一种非限制性的实施方式，不对这些视频数据处理方法中各步骤的执行端构成限制。

请参考图1，图1示出了根据本发明的一些实施例提供的初始化视频播放系统的流程示意图。

如图1所示，在本发明的一些实施例中，响应于车辆的上电启动，车辆的视频播放系统(例如：IVI系统)将自动进行初始化，以激活系统层的Native接口及应用层的Java接口，并根据自身的硬件特性配置至少一个解码单元的插件和/或至少一个渲染单元的插件。

具体来说，在配置解码单元插件的过程中，视频播放系统可以首先抽象解码单元以提供至少一个解码抽象接口。该至少一个解码抽象接口包括但不限于解码插件初始化接口、解码插件资源释放接口、视频元素流(Video Element Stream)数据输入接口、视频框架(Video Frame)获取接口、视频框架(Video Frame)释放接口、解码器状态获取接口中的至少一者。之后，视频播放系统可以解析自身的硬件特性，并根据该硬件特性从预先构建的插件库选择至少一个满足上述各解码抽象接口的解码插件，再以插件(plugin)的形式将该至少一个解码插件组入视频播放系统，以提供至少一个解码单元。

之后，在配置渲染单元插件的过程中，视频播放系统可以首先抽象渲染单元以提供至少一个渲染抽象接口。该至少一个渲染抽象接口包括但不限于渲染插件初始化接口、渲染插件资源释放接口、图层创建接口、图层释放接口、显示区域设置接口、图像Mute设置接口中的至少一者。之后，视频播放系统可以解析自身的硬件特性，并根据该硬件特性从预先构建的插件库选择至少一个满足上述各渲染抽象接口的渲染插件，再以插件的形式将该至少一个渲染插件组入视频播放系统，以提供至少一个渲染单元。

通过提供上述抽象标准来接入解码器插件和/或渲染器插件，本发明提供的上述视频播放系统具有很高的可扩展性，不仅能够为WinCE、Linux、Android等主流的车机平台提供适应的插件实现方案，还能适用于各种小众、非主流及未来开发的其他车机平台，为其提供适应的插件实现方案。

在一些实施例中，针对插件库中缺少所需插件的情况，视频播放系统可以向开发端上报自身的硬件特性，以请求其发布适应自身硬件特性的解码插件和/或渲染插件。请参考图2，图2示出了根据本发明的一些实施例提供的开发插件的流程示意图。

如图2所示，在本发明的一些实施例中，响应于插件库中缺少指定插件(例如：图1所示的Android Native Media Codec硬件解码插件)和/或对应配置文件的情况，开发端的开发人员和/或开发处理器(以下简称开发者)可以首先根据视频播放系统提供的硬件解码器、硬件图像处理单元和OpenGL等硬件特性开发对应的插件，并将其加入到框架程序中。例如，开发者可以根据IMX6平台提供的视频处理单元(Video Processing Unit，VPU)的硬件特性参数开发硬件解码插件。又例如，开发者可以根据IMX6平台提供的G2D+帧缓冲区(Framebuffer)的硬件特性参数开发硬件渲染器插件。在一些实施例中，对Android NativeMedia Codec硬件解码插件的开发流程可以基于安卓原生开发工具包(NativeDevelopment Kit，NDK)来实现。

由于在部分硬件平台的视频输出实现中，用于输出视频的硬件图层无法与解码输出的视频图像帧匹配。因此，视频播放系统通常需要在输出视频帧之前通过软件实现的方式进行色彩格式转换。这种通过软件实现的色彩格式转换方法，其CPU占用率高、效率低，无法满足视频输出帧率的要求。通过开发并优先配置基于硬件的插件，本发明能够优先采用硬件解码器及硬件渲染器替代车辆视频播放系统的CPU来执行视频ES数据解码及视频渲染的处理操作，从而充分利用平台的解码、图像处理能力等硬件设备能力来实现高效的数据处理。

之后，开发者可以根据开发的插件生成对应的配置文件，以供视频播放系统运行对应插件时使用。再之后，开发者可以编写并编译该配置文件，以决定输出插件库的插件种类。再之后，开发者可以根据开发的插件及配置文件编译生成对应的框架程序及插件库，并向视频播放系统发布该框架程序、插件库及配置文件。视频播放系统可以下载该框架程序、插件库及配置文件，根据所需至少一个插件确定至少一个对应的配置文件，并分别执行各配置文件来加载预先构建的插件库，以分别将对应的插件组入视频播放系统。

通过提供上述根据视频播放系统的具体请求开发对应插件的功能，本发明不仅能够适用于WinCE、Linux、Android等主流的车机平台，并为其提供适应其主流芯片方案的插件实现方案，以充分利用其硬件解码器、硬件图像处理单元和OpenGL的硬件平台能力，还能适用于各种小众、非主流及未来开发的其他车机平台，为其提供适应其主流芯片方案的插件实现方案，以充分利用其硬件解码器、硬件图像处理单元和OpenGL的硬件平台能力。

请继续参考图1，在图1所示的实施例中，视频播放系统可以根据自身的硬件特性，以插件的形式组入Android Standard Media Codec的Android SDK硬件解码单元，以提供在平台Java层解码视频ES数据的功能。此外，视频播放系统还可以根据自身的硬件特性，以插件的形式组入基于NDK开发的Android Native Media Codec的Android NDK硬件解码单元，以提供在平台Native层解码视频ES数据的功能。此外，视频播放系统还可以根据自身的硬件特性，以插件的形式组入Windows和Linux操作系统下X86平台的X86PlatformCustomization Codec的硬件解码单元，以提供在PC平台上与上层互联App进行联调的功能。

对应地，视频播放系统还可以根据自身的硬件特性，以插件的形式组入AndroidCommon Render的Android SDK渲染单元，以提供在平台Java层渲染输出视频LVDS数据的功能。此外，视频播放系统还可以根据自身的硬件特性，以插件的形式组入Android GLRender的Android SDK+OpenGL渲染单元，以提供在平台Java层渲染输出视频LVDS数据的功能。此外，视频播放系统还可以根据自身的硬件特性，以插件的形式组入基于Android NDK开发的Android Native Render的Android NDK+OpenGL渲染单元，以提供在平台Native层渲染输出视频LVDS数据的功能。此外，视频播放系统还可以根据自身的硬件特性，以插件的形式组入Windows和Linux操作系统下X86平台的X86 Platform Customization Render的渲染单元，以提供在PC平台上与上层互联App进行联调的功能。

通过提供多种解码插件来实现硬件解码功能，并提供多种渲染插件来实现渲染输出功能，本发明提供的上述视频播放系统能够充分利用WinCE、Linux、Android等主流车机平台的芯片支持的硬件解码器、硬件图像处理单元和OpenGL的硬件特性，从而实现高效的数据处理能力。

此外，通过制定接入标准，本发明提供的上述视频播放系统还具有很高的可扩展性，能够通过配置不同的解码插件和/或渲染插件来达到在WinCE、Android、Linux等多种平台上跨平台使用的效果。例如，在WinCE操作系统下，本发明能够实现CSR、MTK、Telechips等平台方案的视频解码器插件和视频渲染器插件。又例如，在Linux操作系统下，本发明能够实现NXP、Panasoinc等平台方案的视频解码器插件和视频渲染器插件。又例如，在Android操作系统下，本发明能够实现NXP、MTK等平台方案的视频解码器插件和视频渲染器插件，同时也能够基于Android SDK实现视频解码器插件和视频渲染器插件。因此，基于本发明提供的上述视频播放系统实现的互联App不需要关注特定平台的视频解码及渲染输出的实现方式，从而使得互联App方案也具有跨平台特性，并降低互联App的开发难度。

进一步地，在一些实施例中，本发明提供的上述视频播放系统配置了Windows和Linux操作系统下，X86平台的X86 Platform Customization Codec视频解码器插件和X86Platform Customization Render视频渲染器插件。通过提供X86平台的插件配置，本发明提供的上述视频播放系统能够支持在PC平台上进行互联App与视频ES解码播放器的联调功能。相比于现有互联App的开发过程中，需要先完成视频ES播放方案的开发，再通过视频ES播放方案来进行互联App的开发验证的情况，本发明能够在PC平台上实现互联App与视频ES解码播放器的联调，因此能够并行实施视频ES播放方案的实现流程与互联App的开发流程，从而大幅提升互联App的开发效率。

在完成初始化流程之后，视频播放系统即可根据配置的至少一个解码单元及至少一个渲染单元，向用户提供驾驶导航、影音播放等各种基于车机互联技术的扩展功能。请结合参考图3～图6。图3示出了根据本发明的一方面提供的视频数据处理方法的流程示意图。图4示出了根据本发明的一些实施例提供的视频元素流播放方案的示意图。图5示出了根据本发明的一些实施例提供的通用播放控制接口的示意图。图6示出了根据本发明的一些实施例提供的互联应用的系统层实现的示意图。

如图3、图4及图5所示，在本发明的一些实施例中，当需要通过车机互联技术在车机屏幕上实现驾驶导航、影音播放等各种扩展功能，用户可以首先通过Wi-Fi、蓝牙、USB数据线等通信方式，将手机、平板电脑等用户终端连接到车辆的车机系统。之后，响应于手机终端通过Wi-Fi、蓝牙、USB数据线等通信方式提供的车机互联请求，车辆的视频播放系统(例如：IVI系统)可以首先验证该手机终端的车机互联权限，再向通过权限验证的手机终端提供系统层的Native接口及应用层的Java接口。

由于苹果的CarPlay、百度的Carlife、华为的HiCar、博泰的擎Mobile和亿联等主流的车机互联方案一般是基于软件开发工具包(Software Development Kit，SDK)进行开发，而这些SDK的发布形式既包括基于Java层实现的Java SDK，又包括基于Native层的实现Native SDK。因此，通过同时向手机终端提供系统层的Native接口及应用层的Java接口，本发明的互联App能够支持苹果的CarPlay、百度的Carlife、华为的HiCar、博泰的擎Mobile和亿联的各种SDK的发布形式，兼容地为手机互联SDK提供与其形式一致的视频ES播放器，以便于直接接入上述Java SDK及Native SDK。此外，通过同时向手机终端提供系统层的Native接口及应用层的Java接口，本发明的互联App不需要关注具体车机平台的差别，就能确保视频解码及渲染输出功能的正常使用。

在完成与手机终端的通信连接之后，视频播放系统将对手机终端提供的通信接口进行互联形式的判断。若手机终端提供的通信接口采用了基于Native层的实现NativeSDK，则视频播放系统可以判定其互联形式为系统层互联，从而经由系统层的Native接口从手机终端获取其提供视频ES数据。反之，若手机终端提供的通信接口采用了基于Java层的实现Java SDK，则视频播放系统可以判定其互联形式为应用层互联，从而经由应用层的Java接口从手机终端获取其提供视频ES数据。

如图3、图4及图6所示，在一些实施例中，响应于从系统层的Native接口获取的视频ES数据，视频播放系统将选用设置于系统层的Android Native Media Codec硬件解码单元对输入的视频ES数据进行解码处理，从而在系统层生成YUV RAW解码数据。之后，视频播放系统还将选用同样设置于系统层的Android Native Render硬件渲染单元对生成的YUVRAW解码数据进行渲染处理，再通过帧缓冲区(Framebuffer)或V4L从系统层向视频播放器传输LVDS解码数据。

如上所述，该Android Native Media Codec硬件解码单元是开发者根据视频播放系统的硬件特性，并基于NDK在系统层开发的Android NDK硬件解码单元，而上述AndroidNative Render硬件渲染单元是开发者根据视频播放系统的硬件特性，并基于NDK在系统层开发的Android NDK+OpenGL硬件渲染单元。相比于现有技术(图6中虚线部分)需要先将视频ES数据从系统层的Native接口跨层传输到应用层的Android Standard Media Codec解码单元进行解码处理，再将YUV RAW解码数据从应用层的Android Standard Media Codec解码单元跨层传输回系统层的Android Native Render渲染单元进行渲染输出的方案，本发明不需要对视频数据进行任何跨层传输，能够在系统层完整地完成对视频ES数据的解码及渲染输出处理，因此能够避免数据的跨层传输引起额外的CPU占用，从而整体地提升视频播放系统的数据处理效率。

进一步地，在本发明的一些实施例中，设置于系统层的Android Native MediaCodec硬件解码单元及Android Native Render硬件渲染单元之间，还可以优选地配置有独立的视频输出缓冲队列。通过配置该独立的视频输出缓冲队列，能够在本发明提供的上述视频播放系统中达到分离视频解码动作与视频渲染动作的效果，从而在安卓系统满足苹果的CarPlay互联App对视频后台解码的要求。

请结合参考图7A及图7B。图7A示出了传统视频输出缓冲队列的示意图。图7B示出了根据本发明的一些实施例提供的视频输出缓冲队列的示意图。

如图7A所示，在传统的安卓视频播放系统中，视频输出缓冲队列被配置于视频渲染单元中。视频播放系统需要在解码动作开始的之前，预先建立解码单元和视频渲染单元的绑定关系，才能为解码单元提供可用的输出通道，并支持解码单元进行解码处理。此时，如果视频渲染单元被系统释放，解码单元将因失去可用的输出通道而无法正常工作，因此无法达到后台解码的效果。

如图7B所示，在一些实施例中，通过在Android Native Media Codec解码单元和Android Native Render视频渲染单元之间配置独立的视频输出缓冲队列，本发明能够解除解码单元和视频渲染单元之间的绑定需求。如此，即使用户临时切出车机互联App导致视频渲染单元被系统临时释放，解码单元仍可以将该独立的视频输出缓冲队列作为可用的输出通道，持续地将完成解码处理的解码数据输入该独立的视频输出缓冲队列，以提供不输出视频画面的后台解码的功能。进一步地，在一些实施例中，视频播放系统还可以在后台解码的状态下持续地检测并判断对应的渲染单元是否重新回复到运行状态。之后，响应于用户重新启用车机互联App并重新运行对应渲染单元的判断结果，视频播放系统可以将视频输出缓冲队列缓存的YUV RAW解码数据传输到渲染单元进行渲染处理，再经由该渲染单元向视频播放器传输渲染获得LVDS解码数据，以提供输出视频画面的视频显示功能。

通过在解码单元及渲染单元之间配置该独立的视频输出缓冲队列，本发明能够在安卓视频播放系统中达到分离视频解码动作与视频渲染动作的效果，从而在安卓系统满足苹果的CarPlay互联App对视频后台解码的要求。

本领域的技术人员可以理解，上述从系统层的Native接口获取视频ES数据，并在系统层完成视频ES数据的解码及渲染输出的方案，只是本发明提供的一种非限制性的实施方式，旨在清楚地展示本发明的主要构思，并提供一种便于公众实施的具体方案，而非用于限制本发明的保护范围。

可选地，在另一些实施例中，响应于从应用层的Java接口获取的视频ES数据，视频播放系统可以选用设置于应用层的Android Standard Media Codec解码单元对输入的视频ES数据进行解码处理，从而在应用层生成YUV RAW解码数据。之后，视频播放系统还将选用同样设置于应用层的Android GLRender渲染单元对生成的YUV RAW解码数据进行渲染处理，再通过帧缓冲区(Framebuffer)或V4L从系统层向视频播放器传输LVDS解码数据。

如上所述，该Android Standard Media Codec解码单元是设置于应用层的Android SDK解码单元，而上述Android GLRender渲染单元是设置于应用层的Android NDK+OpenGL渲染单元。相比于现有技术需要将YUV RAW解码数据从应用层的Android StandardMedia Codec解码单元跨层传输到系统层的Android Native Render渲染单元进行渲染输出的方案，本发明不需要对视频数据进行任何跨层传输，能够在应用层完整地完成对视频ES数据的解码及渲染输出处理，因此能够避免数据的跨层传输引起额外的CPU占用，从而整体地提升视频播放系统的数据处理效率。

进一步地，在本发明的一些实施例中，设置于应用层的Android Standard MediaCodec解码单元及Android GLRender渲染单元之间，也可以优选地配置有独立的视频输出缓冲队列。通过配置该独立的视频输出缓冲队列，能够在本发明提供的上述视频播放系统中达到分离视频解码动作与视频渲染动作的效果，从而在安卓系统满足苹果的CarPlay互联App对视频后台解码的要求。

如图4所示，在本发明的一些实施例中，在通过帧缓冲区(Framebuffer)或V4L从系统层向视频播放器传输LVDS解码数据之后，视频播放系统可以使用视频播放器加载该LVDS解码数据，从而在视频播放系统的显示界面(即车载显示屏幕)显示视频ES数据对应的图像，和/或通过视频播放系统的扬声器播放视频ES数据对应的声音。

本领域的技术人员可以理解，上述经由系统层的Native接口或应用层的Java接口获取视频ES数据以在车机播放手机中视频的方案，只是本发明提供的一种非限制性的实施方式，旨在清楚地展示本发明的主要构思，并提供一种便于公众实施的具体方案，而非用于限制本发明的保护范围。

可选地，在另一些实施例中，视频播放系统还可以根据手机终端通信接口的互联形式，经由对应的Native接口或Java接口向手机终端传输用户通过车辆的触摸屏、方控按键等设备输入的操作指令，以同样达到兼容支持苹果的CarPlay、百度的Carlife、华为的HiCar、博泰的擎Mobile和亿联等各种发布形式的SDK操作回控手机终端的效果，并达到不需要关注具体车机平台的差别就能确保操作回控功能正常使用的效果。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将可理解，信息、信号和数据可使用各种不同技术和技艺中的任何技术和技艺来表示。例如，以上描述通篇引述的数据、指令、命令、信息、信号、位(比特)、码元、和码片可由电压、电流、电磁波、磁场或磁粒子、光场或光学粒子、或其任何组合来表示。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

尽管上述的实施例所述的视频播放系统可以通过软件与硬件的组合来实现。但是可以理解，该视频播放系统也可以单独在软件或硬件中加以实施。对于硬件实施而言，该视频播放系统可以在一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、用于执行上述功能的其它电子装置或上述装置的选择组合来加以实施。对软件实施而言，该视频播放系统可以通过在通用芯片上运行的诸如程序模块(procedures)和函数模块(functions)等独立的软件模块来加以实施，其中每一个模块可以执行一个或多个本文中描述的功能和操作。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (12)

1.一种视频数据的处理方法，其特征在于，所述处理方法应用于视频播放系统，并包括以下步骤：

提供系统层接口及应用层接口；

经由所述系统层接口或所述应用层接口，获取视频数据；以及

响应于从所述系统层接口获取的视频数据，设置系统层的第一解码单元对所述视频数据进行解码处理，并从所述系统层向视频播放器传输解码数据。

2.如权利要求1所述的处理方法，其中，所述经由所述系统层接口或所述应用层接口，获取视频数据的步骤包括：

响应于用户终端提供的通信接口，判断所述通信接口的互联形式；

响应于所述互联形式为系统层互联的判断结果，经由所述系统层接口从所述用户终端获取所述视频数据；以及

响应于所述互联形式为应用层互联的判断结果，经由所述应用层接口从所述用户终端获取所述视频数据。

3.如权利要求1所述的处理方法，其中，在执行所述采用第一解码单元在系统层对所述视频数据进行解码的步骤之前，所述处理方法还包括以下步骤：

利用本地开发工具包开发配置于所述系统层的所述第一解码单元。

4.如权利要求1所述的处理方法，其中，所述从所述系统层向视频播放器传输解码数据的步骤包括：

经由配置于所述系统层的第一渲染单元向所述视频播放器传输所述解码数据。

5.如权利要求4所述的处理方法，其中，所述第一解码单元与所述第一渲染单元之间配置有视频输出缓冲队列，所述经由配置于所述系统层的第一渲染单元向所述视频播放器传输所述解码数据的步骤包括：

将完成所述解码处理的所述解码数据，输入所述视频输出缓冲队列；

判断所述第一渲染单元是否运行；以及

响应于所述第一渲染单元正在运行的判断结果，向所述第一渲染单元传输所述解码数据，经由所述第一渲染单元向所述视频播放器传输所述解码数据。

6.如权利要求1所述的处理方法，其中，在执行所述经由所述系统层接口或所述应用层接口获取视频数据的步骤之后，所述处理方法还包括以下步骤：

响应于从所述应用层接口获取的视频数据，设置应用层的第二解码单元对所述视频数据进行解码处理，并经由配置于所述应用层的第二渲染单元从所述应用层向所述视频播放器传输解码数据。

7.如权利要求1所述的处理方法，其中，在执行所述提供系统层接口及应用层接口的步骤之前，所述处理方法还包括以下步骤：

抽象解码单元和/或渲染单元，以提供至少一个抽象接口；

解析所述视频播放系统的硬件特性，并根据所述硬件特性确定满足各所述抽象接口的至少一个插件；以及

将所述至少一个插件组入所述视频播放系统，以提供至少一个解码单元和/或至少一个渲染单元。

8.如权利要求7所述的处理方法，其中，所述将所述至少一个插件组入所述视频播放系统的步骤包括：

根据至少一个所述插件确定至少一个对应的配置文件；以及

分别执行各所述配置文件来加载预先构建的插件库，以分别将对应的插件组入所述视频播放系统。

9.如权利要求8所述的处理方法，其中，在执行所述根据所述硬件特性确定满足各所述抽象接口的至少一个插件的步骤之前，所述处理方法还包括以下步骤：

分析所述视频播放系统的硬件特性；

根据所述硬件特性确定所述视频播放系统需要的至少一个所述插件；

判断当前的插件库中是否存在各所述插件；以及

响应于当前的插件库中不存在任一所述插件的判断结果，开发缺少的插件并编写对应的配置文件，并将开发的所述硬件插件及其对应的配置文件关联地添加到所述插件库中。

10.如权利要求1所述的处理方法，其中，在执行所述从所述系统层向视频播放器传输解码数据的步骤之后，所述处理方法还包括以下步骤：

使用所述视频播放器加载所述解码数据，以在所述视频播放系统的显示界面显示所述视频数据的图像，和/或通过所述视频播放系统的扬声器播放所述视频数据的声音。

11.一种视频播放系统，其特征在于，包括：

存储器；以及

处理器，所述处理器连接所述存储器，并被配置用于实施如权利要求1～10中任一项所述的视频数据的处理方法。

12.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述计算机指令被处理器执行时，实施如权利要求1～10中任一项所述的视频数据的处理方法。

Images