CN112203097A - 一种自适应视频解码方法、装置，终端设备及存储介质 - Google Patents

Abstract

本申请提供一种自适应视频解码方法、装置，终端设备及存储介质。该方法包括：接收第一视频流；其中，所述第一视频流采用H265编码；判断所述终端设备是否支持H265硬解码；当所述终端设备不支持所述H265硬解码时，对所述第一视频流进行H265软解码。通过该方式，实现了终端设备对于采用H265编码的第一视频流的自适应解码，进而保证了当终端设备不支持H265硬解码时，也能够通过切换自身的解码链路来对第一视频流进行软解码，消除了部分终端设备由于不支持H265硬解码，导致无法正常显示视频画面，影响用户使用需求的问题，提高了用户体验。

Description

一种自适应视频解码方法、装置，终端设备及存储介质

技术领域

本申请涉及视频解码技术领域，具体而言，涉及一种自适应视频解码方法、装置，终端设备及存储介质。

背景技术

随着智能硬件和互联网流媒体技术的快速发展，将两者相结合，可以为用户带来更好更新的体验。

但是全球的厂商所生产的终端设备是多种多样的，同一款软件在不同的终端设备上面，由于硬件和***的不兼容，会导致有些软件的功能不能正常使用。如在一些终端设备上面，硬件对H265解码存在兼容性问题，终端设备不能进行正常解码渲染显示视频画面，进而导致目前的一些终端设备，在不支持H265硬解码时，只能进行报错，无法满足用户的使用需求。

发明内容

本申请实施例的目的在于提供一种自适应视频解码方法、装置，终端设备及存储介质，以改善“目前的一些终端设备，在不支持H265硬解码时，只能进行报错，无法满足用户的使用需求”的问题。

本发明是这样实现的：

第一方面，本申请实施例提供一种自适应视频解码方法，应用于终端设备，所述方法包括：接收第一视频流；其中，所述第一视频流采用H265编码；判断所述终端设备是否支持H265硬解码；当所述终端设备不支持所述H265硬解码时，对所述第一视频流进行H265软解码。

在本申请实施例中，终端设备在接收到采用H265编码的第一视频流后，首先判断是否支持H265硬解码；当不支持H265硬解码时，切换解码链路，对第一视频流进行H265软解码。通过该方式，实现了终端设备对于采用H265编码的第一视频流的自适应解码，进而保证了当终端设备不支持H265硬解码时，也能够通过切换自身的解码链路来对第一视频流进行软解码，消除了部分终端设备由于不支持H265硬解码，导致无法正常显示视频画面，影响用户使用需求的问题，提高了用户体验。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述判断所述终端设备是否支持H265硬解码，包括：接收***API接口发送的状态码；基于所述状态码判断所述终端设备是否支持所述H265硬解码。

在本申请实施例中，终端设备在接收到第一视频流后，可以根据***API接口发送的状态码来实现兼容性检测。以安卓***为例，终端设备在接收到第一视频流后，会从***API接口收到两类状态码，第一类状态码的数值为-10000，第二类状态码状态码为0和-1。而终端设备仅能够在收到第二类状态码状态码时进行H265硬解码，当接收到数值为-10000的状态码时无法进行H265硬解码，因此，通过终端设备所接收到的状态码的数值能够有效的实现兼容性检测。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述判断所述终端设备是否支持H265硬解码，包括：采用硬解码链路对所述第一视频流进行解码；判断显示界面中是否显示所述第一视频流；其中，当所述显示界面显示有所述第一视频流时，表征所述终端设备支持所述H265硬解码；当所述显示界面未显示所述第一视频流时，表征所述终端设备不支持所述H265硬解码。

在本申请实施例中，终端设备在接收到第一视频流后，还可以直接通过硬解码链路对第一视频流进行解码，然后根据显示界面的显示情况来实现兼容性检测。也即，当显示界面显示有第一视频流时，表征终端设备支持H265硬解码；当显示界面未显示第一视频流时，表征终端设备不支持所述H265硬解码。该方式也适用于当终端设备虽然支持H265硬解码，但是H265硬解码不稳定的情况。也即虽然终端设备支持H265硬解码，但是当前显示界面中并未显示第一视频流时，也可以通过后续步骤对解码链路进行切换。通过上述步骤能够有效地对终端设备进行检测，进而合理的选择对应的解码链路。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述对所述第一视频流进行H265软解码，包括：通过第一线程对所述第一视频流进行解码，得到YUV数据；并将所述YUV数据进行格式转换，得到格式类型为RGB565的第一数据；在渲染线程调用AndroidNativeWindow_update接口，对所述第一数据进行渲染。

在本申请实施例中，对第一视频流进行H265软解码时，首先在第一线程对第一视频流进行解码，得到YUV数据，然后将YUV数据转换为AndroidNativeWindow_update渲染接口所需的RGB565格式的第一数据后，在渲染线程中调用AndroidNativeWindow_update接口对第一数据进行渲染。通过该方式，能够实现在终端设备现有的接口中实现对第一视频流的H265软解码，且通过不同的线程能够提高处理器的使用率。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述终端设备与流媒体设备通信连接；所述接收第一视频流，包括：实时接收所述流媒体设备传输的所述第一视频流。

在本申请实施例中，终端设备与流媒体设备通信连接。也即，终端设备可以实时接收流媒体设备下发的第一视频流进行自适应视频解码。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，在所述终端设备不支持所述H265硬解码时，所述方法还包括：向所述流媒体设备发送适配指令，以使所述流媒体设备降低传输的第二视频流的分辨率。

在本申请实施例中，由于软解码给处理器带来额外的数据处理压力，当采用H265软解码时，会向与终端设备通信连接的流媒体设备发送适配指令，以使流媒体设备降低传输的第二视频流的分辨率，进而降低处理器的数据处理压力以及后续解码时处理器的占用率。

第二方面，本申请实施例提供一种自适应视频解码装置，应用于终端设备，所述装置包括：接收模块，用于接收第一视频流；其中，所述第一视频流采用H265编码；判断模块，用于判断所述终端设备是否支持H265硬解码；软解码模块，用于当所述终端设备不支持所述H265硬解码时，对所述第一视频流进行H265软解码。

第三方面，本申请实施例提供一种终端设备，包括：处理器和存储器，所述处理器和所述存储器连接；所述存储器用于存储程序；所述处理器用于调用存储在所述存储器中的程序，执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式提供的方法。

结合上述第三方面提供的技术方案，在一些可能的实现方式中，所述处理器与流媒体设备通信连接，所述处理器用于接收所述流媒体设备传输的所述第一视频流。

第四方面，本申请实施例提供一种存储介质，其上存储有计算机程序，所述计算机程序在被处理器运行时执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种终端设备的结构示意图。

图2为本申请实施例提供的一种自适应解码方法的步骤流程图。

图3为本申请实施例提供的一种终端设备与流媒体设备的交互图。

图4为本申请实施例提供的一种终端设备与无人机的应用场景图。

图5为本申请实施例提供的一种自适应解码装置的模块框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

基于目前的某些终端设备，存在当不支持H265硬解码时，只能进行报错，无法满足用户的使用需求的问题，本申请发明人经过长期的研究探索，提出一种自适应视频解码方法、装置，终端设备及存储介质以解决上述问题。

请参阅图1，图1为本申请实施例提供的一种应用自适应视频解码方法及装置的终端设备100的结构示意图。本申请实施例中，终端设备100可以是，但不限于智能手机(如搭载安卓***的智能手机)、平板电脑等。在结构上，终端设备100可以包括处理器110、存储器120以及显示器130。

处理器110、存储器120以及显示器130直接或间接地电性连接，以实现数据的传输或交互，例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。自适应视频解码装置200包括至少一个可以软件或固件(Firmware)的形式存储在存储器120中或固化在终端设备100的操作***(Operating System，OS)中的软件模块。处理器110用于执行存储器120中存储的可执行模块，例如，自适应视频解码装置200所包括的软件功能模块及计算机程序等，以实现自适应视频解码方法。处理器110可以在接收到执行指令后，执行计算机程序。

其中，处理器110可以是一种集成电路芯片，具有信号处理能力。处理器110也可以是通用处理器，例如，可以是中央处理器(Central Processing Unit，CPU)、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、分立门或晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。此外，通用处理器可以是微处理器或者任何常规处理器等。

存储器120可以是，但不限于，随机存取存储器(Random Access Memory，RAM)、只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-OnlyMemory，PROM)、可擦可编程序只读存储器(Erasable Programmable Read-Only Memory，EPROM)，以及电可擦编程只读存储器(Electric Erasable Programmable Read-OnlyMemory，EEPROM)。存储器120用于存储程序，处理器110在接收到执行指令后，执行该程序。

显示器130可以是，但不限于，OLED(OrganicLight-EmittingDiode，有机发光二极管)显示器、TFT(ThinFilmTransistor，薄膜场效应晶体管)显示器，LCD(Liquid CrystalDisplay，液晶)显示屏。

需要说明的是，图1所示的结构仅为示意，本申请实施例提供的终端设备100还可以具有比图1更少或更多的组件，或是具有与图1所示不同的配置。此外，图1所示的各组件可以通过软件、硬件或其组合实现。

请参阅图2，图2为本申请实施例提供的自适应视频解码方法的步骤流程图，该方法应用于图1所示的终端设备100。需要说明的是，本申请实施例提供的自适应视频解码方法不以图2及以下所示的顺序为限制，该方法包括：步骤S11-步骤S14。

步骤S11：接收第一视频流；其中，所述第一视频流采用H265编码。

需要解释的是，视频流是指视频数据的传输，例如，它能够被作为一个稳定的和连续的流通过网络处理。因为流动，客户机浏览器或插件能够在整个文件被传输完成前显示多媒体数据。H265是继H264之后所制定的新的视频编码标准。H265标准围绕着现有的视频编码标准H264，保留原来的技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。如提高了压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。因此，越来越多的视频流采用H265编码技术进行编码。

步骤S12：判断所述终端设备是否支持H265硬解码。

由于现在越来越多的视频流采用H265编码技术进行编码，因此，当终端设备在接收到采用H265编码的第一视频流后，会进行兼容性检测，以检测本地是否支持H265硬解码。

作为一种可选的兼容性检测方式，判断终端设备是否支持H265硬解码包括：接收***API(Application Programming Interface，应用程序接口)接口发送的状态码；基于状态码判断终端设备是否支持H265硬解码。

下面以安卓***的为例，AMediaCodec_dequeueOutputBuffer接口是安卓***的标准API接口。终端设备在接收到第一视频流后，会从AMediaCodec_dequeueOutputBuffer接口收到两类状态码，第一类状态码的数值为-10000，第二类状态码状态码为0和-1。而终端设备仅能够在收到第二类状态码状态码时进行H265硬解码，当接收到数值为-10000的状态码时无法进行H265硬解码，因此，于本申请实施例中，通过终端设备所接收到的状态码的数值能够有效的实现兼容性检测。

相应的，在其他的操作***中，也可以根据***API接口发送的状态码来进行兼容性检测，只是不同的操作***所接收的状态码的数值会存在差异。

作为另一种可选的兼容性检测方式，判断终端设备是否支持H265硬解码包括：采用硬解码链路对所述第一视频流进行解码；判断显示界面中是否显示第一视频流。

也即，当接收到第一视频流后，可以直接通过播放软件的硬解码链路来对第一视频流进行解码测试，然后判断显示界面中是否显示有第一视频流。其中，显示界面即为终端设备的显示器呈现的界面。当显示界面显示有第一视频流时，表征终端设备支持H265硬解码；当显示界面未显示第一视频流时，表征终端设备不支持所述H265硬解码。

另外，该方式也同样适用于当终端设备虽然支持H265硬解码，但是H265硬解码不稳定的情况。比如实现H265硬解码的硬件GPU(Graphics Processing Unit，图形处理器)出现异常，此时GPU无法正常进行H265硬解码。因此，通过上述兼容性检测方式，能够在终端设备虽然支持H265硬解码，但是当前显示界面中并未显示第一视频流时，也确定为当前终端设备不支持H265硬解码，进而通过后续步骤对解码链路进行切换。也即，通过上述步骤能够有效地对终端设备进行检测，进而合理的选择对应的解码链路。

由于第一视频流可能初始画面为黑色，可能会影响判断结果，因此，还可以设定预设时间，来判断显示界面中是否显示有第一视频流。比如，预设时间可以是10秒，20秒，当接收到第一视频流，且采用硬解码链路对第一视频流进行解码后，若是20秒后当前显示界面仍然处于黑屏状态，则表征终端设备不支持H265硬解码。对此，本申请不作限定。

终端设备在通过上述兼容性检测之后，若不支持H265硬解码，则执行步骤S13，若支持H265硬解码，则执行步骤S14。

步骤S13：对第一视频流进行H265软解码。

当终端设备不支持H265硬解码时，则切换解码链路，对第一视频流进行H265软解码。

当采用上述实施例中的第一种兼容性检测方式时，其具体的代码如下：

其具体的代码如下：

也即，上述代码可以理解为当接收到的状态码为-10000时，采用notify通知函数进行链路的切换，进而将硬解码链路切换为软解码链路。

需要说明的是，对第一视频流进行H265软解码，即通过终端设备的处理器实现解码。具体的，H265软解码的过程包括：通过第一线程对第一视频流进行解码，得到YUV(Luminance-Bandwidth-Chrominance，一种颜色编码方法)数据；并将YUV数据进行格式转换，得到格式类型为RGB565的第一数据；在渲染线程调用AndroidNativeWindow_update接口，对所述第一数据进行渲染。

其中，RGB565为一种彩色模式，R(Red)表示红色，G(Green)表示绿色，B(Blue)表示蓝色，RGB565模式中每个像素用16比特位表示，一个像素占两个字节，RGB分量分别为5位、6位、5位。调用的AndroidNativeWindow_update接口为终端设备现有的接口，该接口仅能够对RGB565格式的数据进行渲染，因此，于本申请实施例中，先将第一视频流解码为YUV数据，再将YUV数据进行格式转换，得到RGB565格式的第一数据，最后通过AndroidNativeWindow_update接口实现数据的渲染，完成对第一视频流的H265软解码。通过该方式，实现了在终端设备现有的接口中实现对第一视频流的H265软解码，且通过不同的线程能够提高处理器的使用率。当然，在其他实施例中，也可以采用同一个线程执行上述步骤，本申请不作限定。

其中，AndroidNativeWindow_update接口的完整名称为AndroidNativeWindow_update(pANwindow，mPixels，mWidth，mHeight，WINDOW_FORMAT_RGB_565)。也即，第一数据的完整格式表达式为WINDOW_FORMAT_RGB_565。

上述的将第一视频流进行解码，得到YUV数据，以及将YUV数据转换为RGB565格式的第一数据均可采用FFmpeg(Fast Forward Mpeg)软件技术。FFmpeg是一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。它包含了先进的音频/视频编解码库libavcodec。

步骤S14：采用H265硬解码链路对第一视频进行H265硬解码。

当终端设备支持H265硬解码时，则直接使用硬解码链路，对第一视频流进行H265硬解码。继续以安卓***为例，如果终端设备兼容H265硬解码，则使用硬解码链路进行解码，如使用安卓原生NDK(Native Development Kit，基于原生程序接口的软件开发工具包)硬解码显示渲染接口AMediaCodec_releaseOutputBuffer(mediaCodc,status,bRender)，对第一视频流进行渲染显示。

综上，在本申请实施例中，终端设备在接收到采用H265编码的第一视频流后，判断是否支持H265硬解码；当不支持H265硬解码时，切换解码链路，对第一视频流进行H265软解码。通过该方式，实现了终端设备对于采用H265编码的第一视频流的自适应解码，进而保证了当终端设备不支持H265硬解码时，也能够通过切换自身的解码链路来对第一视频流进行软解码，消除了部分终端设备由于不支持H265硬解码，导致无法正常显示视频画面，影响用户使用需求的问题，提高了用户体验。

作为一种应用场景，终端设备与流媒体设备通信连接。也即，终端设备接收的第一视频流为流媒体设备实时下发的第一视频流。为了便于理解，请参阅图3，图3为本申请实施例提供的终端设备与流媒体设备的交互图。具体的，方法步骤包括：步骤S21-步骤S24。

步骤S21：流媒体设备向终端设备发送第一视频流；其中，所述第一视频流采用H265编码。

需要说明的是，流媒体设备可以是指的流媒体服务器，也可以指能够直接产生视频流的设备，如无人机，监控设备等等。当流媒体设备为无人机时，可以参考图4所示出的场景图。无人机在飞行过程中，能够实时的进行视频采集，并将视频流发送至终端设备。而目前大多数无人机在传输视频流时，也都是采用H265编码，因此，终端设备可接收无人机所传输的采用H265编码的第一视频流，然后通过后续步骤进行解码，实时显示无人机拍摄的画面。当流媒体设备为流媒体服务器时，终端设备可以通过播放软件来接收第一视频流，然后通过后续步骤进行解码，显示第一视频流。

步骤S22：终端设备判断是否支持H265硬解码。

当终端设备不支持H265硬解码时，执行步骤S23，当终端设备支持H265硬解码时，执行步骤S24。

步骤S23：对第一视频流进行H265软解码。

步骤S24：采用硬解码链路对第一视频进行H265硬解码。

需要说明的是，步骤S22-步骤S24在上述实施例中的步骤S12-S14中已有详细说明，为了避免累赘，此处不作赘述，相同部分互相参考即可。

可选地，当终端设备不支持H265硬解码时，该方法还包括步骤S25，即终端设备向流媒体设备发送适配指令，以使流媒体设备降低传输的第二视频流的分辨率。

需要说明的是，由于采用H265软解码会给处理器带来额外的数据处理压力，因此，于本申请实施例中，当采用H265软解码时，会向与之通信连接的流媒体设备发送适配指令，以使流媒体设备降低传输的第二视频流的分辨率，比如将分辨率为1080P的第二视频流改为分辨率为720P的第二视频流进行传输，通过该方式，降低处理器数据处理压力以及后续解码时处理器的占用量，提高了H265软解码过程的流程性。

可选地，在步骤S23对第一视频流进行H265软解码时，该方法还包括：获取处理器的占用率，判断处理器的占用率是否大于预设阈值，若是，则向流媒体设备发送更改指令，以使流媒体设备更改视频编码方式，采用H264进行编码。

其中，上述的预设阈值可以设定80％，90％等，本申请不作限定。该方式主要应用于流媒体设备为无人机和监控设备的场景。也即，当处理器采用H265软解码时超负荷了，可以向无人机或监控设备发送更改视频编码方式的更改指令，使得无人机或监控设备采用H264进行编码。后续终端设备在接收到无人机或监控设备采用H264进行编码的视频流后，便可直接采用H264硬解码即可。

相应的，在终端设备接收流媒体设备所传输的视频流时，该方法还可以包括识别视频流的编码格式。也即，终端设备在接收到流媒体设备所传输的视频流后，首先判断流媒体设备传输的视频流的编码格式。进而根据不同的编码格式来进行后续不同的解码。比如终端设备识别到流媒体设备传输的视频流的编码格式为H264后，直接采用H264硬解码链路进行解码。若终端设备识别到流媒体设备传输的视频流的编码格式为H265后，判断是否支持H265硬解码，然后再选择采用H265硬解码链路还是H265软解码链路进行解码。

请参阅图5，基于同一发明构思，本申请实施例还提供一种自适应视频解码装置200，该装置应用于终端设备100，所述装置包括：接收模块201、判断模块202、软解码模块203。

接收模块201，用于接收第一视频流；其中，所述第一视频流采用H265编码。

判断模块202，用于判断所述终端设备是否支持H265硬解码。

软解码模块203，用于当所述终端设备不支持所述H265硬解码时，对所述第一视频流进行H265软解码。

可选地，判断模块202具体用于接收***API接口发送的状态码；基于所述状态码判断所述终端设备是否支持所述H265硬解码。

可选地，判断模块202具体用于采用硬解码链路对所述第一视频流进行解码；判断显示界面中是否显示所述第一视频流；其中，当所述显示界面显示有所述第一视频流时，表征所述终端设备支持所述H265硬解码；当所述显示界面未显示所述第一视频流时，表征所述终端设备不支持所述H265硬解码。

可选地，软解码模块203具体用于通过第一线程对所述第一视频流进行解码，得到YUV数据；并将所述YUV数据进行格式转换，得到格式类型为RGB565的第一数据；在渲染线程调用AndroidNativeWindow_update接口，对所述第一数据进行渲染。

可选地，接收模块201还用于实时接收所述流媒体设备传输的所述第一视频流。

可选地，自适应视频解码装置200还包括发送模块204。发送模块204用于在所述终端设备不支持所述H265硬解码时，向所述流媒体设备发送适配指令，以使所述流媒体设备降低传输的第二视频流的分辨率。

需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

基于同一发明构思，本申请实施例还提供一种存储介质，其上存储有计算机程序，计算机程序在被运行时执行上述实施例中提供的方法。

该存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种自适应视频解码方法，其特征在于，应用于终端设备，所述方法包括：

接收第一视频流；其中，所述第一视频流采用H265编码；

判断所述终端设备是否支持H265硬解码；

当所述终端设备不支持所述H265硬解码时，对所述第一视频流进行H265软解码。

2.根据权利要求1所述的自适应视频解码方法，其特征在于，所述判断所述终端设备是否支持H265硬解码，包括：

接收***API接口发送的状态码；

基于所述状态码判断所述终端设备是否支持所述H265硬解码。

3.根据权利要求1所述的自适应视频解码方法，其特征在于，所述判断所述终端设备是否支持H265硬解码，包括：

采用硬解码链路对所述第一视频流进行解码；

判断显示界面中是否显示所述第一视频流；其中，当所述显示界面显示有所述第一视频流时，表征所述终端设备支持所述H265硬解码；当所述显示界面未显示所述第一视频流时，表征所述终端设备不支持所述H265硬解码。

4.根据权利要求1所述的自适应视频解码方法，其特征在于，所述对所述第一视频流进行H265软解码，包括：

通过第一线程对所述第一视频流进行解码，得到YUV数据；并将所述YUV数据进行格式转换，得到格式类型为RGB565的第一数据；

在渲染线程调用AndroidNativeWindow_update接口，对所述第一数据进行渲染。

5.根据权利要求1所述的自适应视频解码方法，其特征在于，所述终端设备与流媒体设备通信连接；

所述接收第一视频流，包括：

实时接收所述流媒体设备传输的所述第一视频流。

6.根据权利要求5所述的自适应视频解码方法，其特征在于，在所述终端设备不支持所述H265硬解码时，所述方法还包括：

向所述流媒体设备发送适配指令，以使所述流媒体设备降低传输的第二视频流的分辨率。

7.一种自适应视频解码装置，其特征在于，应用于终端设备，所述装置包括：

接收模块，用于接收第一视频流；其中，所述第一视频流采用H265编码；

判断模块，用于判断所述终端设备是否支持H265硬解码；

软解码模块，用于当所述终端设备不支持所述H265硬解码时，对所述第一视频流进行H265软解码。

8.一种终端设备，其特征在于，包括：处理器和存储器，所述处理器和所述存储器连接；

所述处理器用于存储程序；

所述处理器用于运行存储在所述存储器中的程序，执行如权利要求1-6中任一项所述的方法。

9.根据权利要求8所述的终端设备，其特征在于，所述处理器与流媒体设备通信连接，所述处理器用于接收所述流媒体设备传输的所述第一视频流。

10.一种存储介质，其特征在于，其上存储有计算机程序，所述计算机程序在被计算机运行时执行如权利要求1-6中任一项所述的方法。

Images