CN116055738A

CN116055738A - 视频压缩方法及电子设备

Info

Publication number: CN116055738A
Application number: CN202210749107.0A
Authority: CN
Inventors: 李艳强
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-05-30
Filing date: 2022-06-29
Publication date: 2023-05-02
Anticipated expiration: 2042-06-29
Also published as: CN116055738B

Abstract

本申请公开了一种视频压缩方法及电子设备。该方法应用于电子设备，该电子设备的编解码能力支持对多种视频规格的视频进行N路编解码，该电子设备可以获取到待压缩视频的初始规格，将该多种视频规格中最接近初始规格的视频规格作为目标规格来压缩该待压缩视频。其中，N路由电子设备对视频进行编辑时所需的编解码资源峰值决定。从而可以实现，在编解码资源足够的情况下，采用更优的目标规格对视频进行压缩，既保证压缩视频的成功率，又提高了电子设备的编解码资源利用率，还提高对压缩后的视频进行编解码的可行性。

Description

视频压缩方法及电子设备

技术领域

本申请涉及终端领域，尤其涉及一种视频压缩方法及电子设备。

背景技术

随着视频信息量的与日俱增，在对视频进行导入、下载以及传输等的过程中，需要对视频进行压缩，压缩是指采用编解码器对解码后的视频按照目标规格进行重新编码。将视频压缩为何种目标规格，是当前研究的方向。

发明内容

本申请公开了一种视频压缩方法及电子设备。在该方法中，该电子设备的编解码能力支持对多种视频规格的视频进行N路编解码，该电子设备可以获取到待压缩视频的初始规格，将该多种视频规格中最接近初始规格的视频规格作为目标规格来压缩该待压缩视频。其中，N路由电子设备对视频进行编辑时所需的编解码资源峰值决定。

第一方面，本申请提供了一种视频压缩方法，该方法应用于电子设备，该方法包括：该电子设备接收到针对第一视频的第一操作；该第一视频的视频规格为第一规格；该电子设备根据该第一规格，和，该电子设备的编解码能力，确定目标规格；该电子设备的编解码能力支持对多种视频规格的视频进行N路编解码，该目标规格为该多种视频规格中小于并最接近该第一规格的规格，该N由对视频进行编辑时所需的编解码资源峰值决定；该电子设备对该第一视频进行压缩，得到第二视频，该第二视频的视频规格为该目标规格。

实施第一方面提供的方法后，从而可以实现，在编解码资源足够的情况下，采用更接近待压缩视频初始规格的规格对视频进行压缩，既保证压缩视频的成功率，又提高了电子设备的编解码资源利用率，还提高对压缩后的视频进行编解码的可行性。

结合第一方面提供的方法，该方法还包括：该电子设备接收针对该第二视频的编辑操作；该电子设备对该第二视频进行N路编解码，得到第三视频，该第三视频的视频规格为该目标规格。

这样，在电子设备将待压缩视频压缩为目标规格的视频后，当接收到用户对该压缩后的视频的编辑操作时，有足够的编解码资源支持电子设备根据编辑操作对该目标规格的视频进行编解码，从而保证对压缩后的视频进行编辑的可行性。

结合第一方面提供的方法，该电子设备完成对该第一视频压缩之后，该方法还包括：电子设备显示提供的第一用户界面，该第一用户界面中显示针对该第二视频的编辑操作对应的第一控件。

这样，在电子设备可以通过接收到用户输入的对压缩后得到的第二视频的编辑操作，对第二视频进行编辑。

结合第一方面提供的方法，该视频规格包括以下任意一个或多个：帧率，分辨率。

这样，电子设备可以根据待压缩视频的初始帧率、初始分辨率，以及电子设备的编解码能力获取到目标帧率和目标分辨率的压缩后的视频。

结合第一方面提供的方法，该编解码能力包括：硬件编解码能力和软件编解码能力；该硬件编解码能力根据该硬件编解码支持的视频规格和该硬件编解码的每秒钟占用宏块数(macro block per second，MBPS)决定；该软件编解码能力根据该软件编码支持的视频规格和视频格式决定。

结合第一方面提供的方法，该目标规格满足以下任意一种条件：该硬件编解码的MBPS，大于或等于，对该目标规格的视频进行N路编解码时占用的宏块资源数；或者，该硬件编解码的MBPS，大于或等于，对该目标规格的视频进行N-1路编解码时占用的宏块资源数，并且该软件编解码支持对该第一视频的视频格式进行编解码，并且硬件编解码和软件都支持对目标规格进行编解码。

这样，电子设备可以仅根据电子设备的硬件编解码能力确定压缩视频时的目标规格；或者可以结合硬件编解码能力和软件编解码能力来确定压缩视频时的目标规格，该多种目标规格的确定方法进一步的提高了本申请的可实施性。

结合第一方面提供的方法，在该电子设备接收第一操作之前，该方法还包括：该电子设备显示第一应用程序提供的第一二用户界面，该第一二用户界面显示有该第一视频的预览窗口，和，第二控件；该第一操作包括：作用于该第二控件的操作。

这样，电子设备可以根据用户输入的作用于第二控件的第一操作，触发电子设备确定对第一视频进行压缩时采用的目标规格。

结合第一方面提供的方法，该方法还包括：该电子设备对该第一视频进行压缩的过程中，该电子设备显示第三用户界面，该第三用户界面中显示进度条，该进度条用于指示该电子设备对该第一视频进行压缩的进度。

这样，在电子设备对第一视频进行压缩时，可以显示压缩进度用以提醒用户，提高用户体验。

结合第一方面提供的方法，该电子设备对该第一视频进行压缩，得到第二视频之后，该方法还包括：该电子设备输出指示完成对该第一视频的压缩的提示信息。

这样，在电子设备完成对第一视频的压缩后，可以显示压缩成功的提示信息，提高用户体验。

结合第一方面提供的方法，该第一用户界面由第一应用程序提供，该第二用户界面和该第三用户界面由第二应用程序提供；该第一应用程序和该第二应用程序为相同应用或不同应用。

这样，用于触发电子设备压缩视频和触发电子设备编辑视频的两个操作可以是同一应用提供的，也可以是不同应用提供的，提高本申请方法的应用场景。

结合第一方面提供的方法，该第一应用程序为视频编辑应用，该第二应用程序为图库应用。

这样，用户可以通过在图库中选择待压缩视频，然后又视频编辑类APP对其压缩并为该压缩后的视频提供编辑功能。

第二方面，本申请提供了一种电子设备，该电子设备包括一个或多个处理器和一个或多个存储器；其中，该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行所述计算机指令时，使得该电子设备执行：该电子设备接收到针对第一视频的第一操作；该第一视频的视频规格为第一规格；该电子设备根据该第一规格，和，该电子设备的编解码能力，确定目标规格；该电子设备的编解码能力支持对多种视频规格的视频进行N路编解码，该目标规格为该多种视频规格中小于并最接近该第一规格的规格，该N由对视频进行编辑时所需的编解码资源峰值决定；该电子设备对该第一视频进行压缩，得到第二视频，该第二视频的视频规格为该目标规格。

实施第二方面提供的电子设备后，从而可以实现，在编解码资源足够的情况下，电子设备可以采用更接近待压缩视频初始规格的规格对视频进行压缩，既保证压缩视频的成功率，又提高了电子设备的编解码资源利用率，还提高对压缩后的视频进行编解码的可行性。

结合第二方面提供的电子设备，该电子设备还可以执行：电子设备接收针对该第二视频的编辑操作；该电子设备对该第二视频进行N路编解码，得到第三视频，该第三视频的视频规格为该目标规格。

结合第二方面提供的电子设备，该电子设备完成对该第一视频压缩之后，该电子设备还可以执行：电子设备显示提供的第一用户界面，该第一用户界面中显示针对该第二视频的编辑操作对应的第一控件。

结合第二方面提供的电子设备，该视频规格包括以下任意一个或多个：帧率，分辨率。

结合第二方面提供的电子设备，该编解码能力包括：硬件编解码能力和软件编解码能力；该硬件编解码能力根据该硬件编解码支持的视频规格和该硬件编解码的每秒钟占用宏块数(macro block per second，MBPS)决定；该软件编解码能力根据该软件编码支持的视频规格和视频格式决定。

结合第二方面提供的电子设备，该目标规格满足以下任意一种条件：该硬件编解码的MBPS，大于或等于，对该目标规格的视频进行N路编解码时占用的宏块资源数；或者，该硬件编解码的MBPS，大于或等于，对该目标规格的视频进行N-1路编解码时占用的宏块资源数，并且该软件编解码支持对该第一视频的视频格式进行编解码，并且硬件编解码和软件都支持对目标规格进行编解码。

结合第二方面提供的电子设备，在该电子设备接收第一操作之前，该电子设备还可以执行：该电子设备显示第一应用程序提供的第一二用户界面，该第一二用户界面显示有该第一视频的预览窗口，和，第二控件；该第一操作包括：作用于该第二控件的操作。

结合第二方面提供的电子设备，该电子设备还可以执行：该电子设备对该第一视频进行压缩的过程中，该电子设备显示第三用户界面，该第三用户界面中显示进度条，该进度条用于指示该电子设备对该第一视频进行压缩的进度。

结合第二方面提供的电子设备，该电子设备对该第一视频进行压缩，得到第二视频之后，该电子设备还可以执行：该电子设备输出指示完成对该第一视频的压缩的提示信息。

结合第二方面提供的电子设备，该第一用户界面由第一应用程序提供，该第二用户界面和该第三用户界面由第二应用程序提供；该第一应用程序和该第二应用程序为相同应用或不同应用。

结合第二方面提供的电子设备，该第一应用程序为视频编辑应用，该第二应用程序为图库应用。

第三方面，本申请提供一种芯片，该芯片应用于电子设备，该芯片包括一个或多个处理器，该处理器用于调用计算机指令以使得该电子设备执行如第一方面中任一项描述的方法。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质包括指令，当该指令在电子设备上运行时，使得该电子设备执行如第一方面中任一项描述的方法。

附图说明

图1为本申请实施例提供的一种电子设备100的硬件架构示意图；

图2为本申请实施例提供的一种电子设备100的软件结构框图；

图3为本申请实施例提供的一种视频压缩方法示意图；

图4A-图4D为本申请实施例提供的一组界面示意图；

图5为本申请实施例提供的一种确定压缩策略方法流程示意图；

图6为本申请实施例提供的一种压缩帧率的方法流程示意图；

图7为本申请实施例提供的一种降低分辨率的方法流程示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行清楚、详尽地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本申请所描述的实施例可以与其它实施例相结合。

本申请以下实施例中的术语“用户界面(user interface，UI)”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面是通过java、可扩展标记语言(extensible markuplanguage，XML)等特定计算机语言编写的源代码，界面源代码在电子设备上经过解析，渲染，最终呈现为用户可以识别的内容。用户界面常用的表现形式是图形用户界面(graphicuser interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的文本、图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

随着数字视频信息量与日俱增，视频所包含的数据量也越来越大。以一个分辨率为1080逐行扫描(progressive scan，P)，时长为2小时的视频为例，该视频的数据量大约为4171G。因此，在很多场景中，都需要对视频进行压缩。例如，在将图库中的视频导入视频编辑APP的场景下，由于后续需要对视频进行编辑，编辑操作涉及到对编辑前的视频进行解码然后对编辑后的视频再编码，当编辑操作对应的编解码业务较复杂时，需要占用较多的编解码资源，因此为了提高后续编辑视频的可行性，在将视频导入编辑类APP时，需要尽可能将该待压缩视频从初始规格压缩为目标规格，使得后续编辑操作对应的编解码业务所占用的编解码资源足够支持对目标规格的视频进行编解码。本申请对压缩视频的场景不作限制，除了导入视频的场景之外，还有从网络中下载视频、向其他设备传输视频的等场景，这样便可以减少视频存储的空间，或者是减少视频传输的带宽。

在涉及压缩视频的场景中，通常直接将视频压缩为一个默认规格，该默认规格通常是业界各个平台的编解码资源都支持的最小规格，直接将视频压缩为默认规格，虽然成功压缩了视频，但会出现视频数据丢失严重，影响用户体验，以及浪费编解码的资源问题。

为了解决上述问题，本申请提供了一种视频压缩方法及电子设备。在该方法中，电子设备获取到待压缩视频的初始规格，根据该初始规格以及电子设备当前的软硬件编解码能力，确定目标规格，并按照目标规格对待压缩的视频进行压缩，之后电子设备还可以利用软硬件编解码资源对目标规格的视频进行编解码。从而可以实现，根据不同平台的编解码能力，在编解码能力支持的情况下，采用更优的视频规格对该视频进行压缩，既保证了压缩视频的成功率，又提高了电子设备的编解码资源利用率，还提高对压缩后的目标规格的视频进行编解码的可行性。

接下来，先对本申请涉及概念、术语等进行介绍，具体如下：

视频规格包括但不限于：视频帧率和视频分辨率等。

视频帧率是用于测量显示帧数的量度，测量单位为每秒显示帧数(Frames perSecond，fps)，常用的帧率包括但不限于：16画面每秒显示帧数(Frame Per Second，fps)，24fps、25fps、30fps、40fps、50fps和60fps。当视频帧率越高时，该视频的播放效果更流畅，画面更连贯。

视频分辨率是用于度量图像内数据量多少的一个参数。其中，常用的视频分辨率包括但不限于：480逐行扫描(progressive scan，P)、720P、1080P、2K和4K等等。其中，480p常见的分辨率有640*480、720*480、800*480、854*480；720P常见的分辨率有1280*720；1080P常见的分辨率有1920*1080和1920*824等；2K对应的场景分辨率有2048*1080，4K对应的常见的分辨率有4096*2160。当视频分辨率越大时，视频越清晰。也就是说，视频帧率越高，视频分辨率越大则说明该视频的规格更优，播放该规格的视频能为用户带来的更好的视觉体验。

初始规格是指，待压缩视频在压缩之前的规格。具体的，以将视频从图库中导入至视频编辑类APP的场景为例，初始规格是电子设备在导入视频之前，在图库中存储的规格。在本申请中，该初始规格又可以称为第一规格，具有初始规格的待导入视频又可以称为第一视频。

目标规格是指，电子设备根据初始规格以及编解码能力确定的压缩策略中的目标规格。具体的，当电子设备根据待压缩视频的初始规格和编解码能力确定压缩策略后，该目标规格是在初始规格的基础上，通过压缩帧率或者还包括压缩分辨率而得到的较小的视频规格。关于电子设备确定目标视频规格的具体实现方法可以参考后文方法流程中的描述，在此暂不赘述。在本申请中，对初始规格下的第一规格进行压缩后得到的目标规格的视频可以称为第二视频。在对第二视频进行编辑例如添加特效后得到的视频又称为第三视频。

硬件编解码(Codec)能力具体可用硬件Codec的资源和硬件Codec所支持的视频规格来衡量。其中硬件Codec的资源可以用宏块资源来表示，硬件Codec所支持的视频规格具体可用帧率、分辨率等来衡量。当硬件Codec的宏块资源越多，则表示硬件Codec的能力越强；硬件Codec所支持的视频的帧率上限越高、分辨率上限越大，则表示硬件Codec的能力越强。

软件编解码(Codec)能力具体可用软件Codec的所支持的视频规格和视频规格来衡量。当软件Codec所支持的视频格式的种类越多时，则表示软件Codec的能力越强；当软件Codec所支持的视频的分辨率的范围越大时，则表示软件Codec的能力越强。例如，当软件Codec支持的分辨率的短边最小为98，长边最大为1920时的能力，强于，软件Codec支持的分辨率的短边最小为1080，长边最大为1920时的能力。

视频格式包括但不限于：LOG格式、HDR格式、HDR10+格式。其中，LOG即对数函数(Logarithmic)，是一种采用对数函数应用到曝光曲线上的视频记录形式，LOG格式主要是指相机视频功能的log模式，该模式下拍摄的视频可以最大限度地保留高光和阴影部分的细节；HDR格式的视频具有高动态范围(High dynamicrange)；HDR10+也称为HDR10 Plus，HDR10+通过添加动态元数据来更新HDR10，动态元数据可用于在逐个场景或逐帧的基础上更精确地调整HDR的亮度级别。

接下来，先介绍本申请提供的视频压缩方法所应用的电子设备。

电子设备可以是搭载

或者其它操作系统的便携式终端设备，例如手机、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、人工智能(artificial intelligence,AI)设备、可穿戴式设备、车载设备、智能家居设备和/或智慧城市设备，等等。

参考图1，图1示例性示出电子设备100的硬件架构示意图。

如图1所示，电子设备100可以包括：处理器110，通用串行总线(universal serialbus，USB)接口120、外部存储器接口130、内部存储器140、显示屏150、通信模块160，摄像头170，视频编解码器180，传感器模块190等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。例如电子设备100还可以包括音频模块、充电模块、电源管理模块、按键、马达、指示器、SIM卡等等。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器180，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在本申请实施例中，处理器110可用于根据检测到的用户的触发操作，从存储器中获取待压缩视频，以及待压缩视频的初始规格，并调用第一应用程序根据编解码能力和初始规格，获取压缩时的目标规格，并控制视频编解码器180根据该目标规格对待压缩视频进行压缩。具体的，处理器110可用于根据检测到的用户的触发操作，触发电子设备中的相应模块(例如压缩策略模块)确定压缩视频时采用的压缩策略，并控制相应模块(例如导出模块)根据该压缩策略，采用对应的硬件编解码资源或者软件编解码资源，对待压缩的视频进行解码后再编码，得到压缩后的视频。关于处理器110控制导出策略模块确定编解码视频时的编解码策略，以及控制导出模块根据该策略，去控制对应的硬件编解码器或者软件编解码器进行编解码的操作可以参考后文方法流程的详细描述，在此暂不赘述。

在本申请实施例中，电子设备的硬件编码器是指独立于CPU的一个芯片，软件编解码则是指运行在CPU上的程序，软件编解码的速度依赖与CPU的算力。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括通用串行总线USB接口120、外部存储器接口130等。

USB接口120是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口120可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

外部存储器接口130可以用于连接外部的非易失性存储器，实现扩展电子设备100的存储能力。外部的非易失性存储器通过外部存储器接口130与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部的非易失性存储器中。

在本申请一些实施例中接口还可以包括图1中未示出的集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，和/或用户标识模块(subscriber identity module，SIM)接口等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

内部存储器140可以包括一个或多个随机存取存储器(random access memory，RAM)和一个或多个非易失性存储器(non-volatile memory，NVM)。

随机存取存储器可以包括静态随机存储器(static random-access memory，SRAM)、动态随机存储器(dynamic random access memory，DRAM)、同步动态随机存储器(synchronous dynamic random access memory,SDRAM)、双倍资料率同步动态随机存取存储器(double data rate synchronous dynamic random access memory,DDR SDRAM，例如第五代DDR SDRAM一般称为DDR5 SDRAM)等；

非易失性存储器可以包括磁盘存储器件、快闪存储器(flash memory)。

快闪存储器按照运作原理划分可以包括NOR FLASH、NAND FLASH、3D NAND FLASH等，按照存储单元电位阶数划分可以包括单阶存储单元(single-level cell,SLC)、多阶存储单元(multi-level cell,MLC)、三阶储存单元(triple-level cell,TLC)、四阶储存单元(quad-level cell,QLC)等，按照存储规范划分可以包括通用闪存存储(英文：universalflash storage，UFS)、嵌入式多媒体存储卡(embedded multi media Card，eMMC)等。

随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如机器指令)，还可以用于存储用户及应用程序的数据等。

非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。

在本申请实施例中，上述存储器可用于存储压缩前的视频和压缩后的视频。具体的，在电子设备将图库的视频导入到视频编辑类APP之前，图库中存储有一个或多个视频，电子设备将图库的视频导入到视频编辑类APP之后，电子设备可以生成并存储压缩后的视频。

电子设备100通过GPU，显示屏150，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏150和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏150用于显示图像，视频等。显示屏150包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)。显示屏面板还可以采用有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode，AMOLED)，柔性发光二极管(flexlight-emitting diode，FLED)，miniled，microLed，micro-oled，量子点发光二极管(quantum dot light emitting diodes，QLED)等制造。在一些实施例中，电子设备100可以包括1个或N个显示屏150，N为大于1的正整数。

在本申请实施例中，上述显示屏150可用于显示运行图库、视频编辑类APP所提供的用户界面，其中，图库提供的用户界面包括视频预览框，具体参考后文对图4A的介绍；其中，视频编辑类APP提供的界面中的内容包括但不限于从图库导入的视频，以及编辑控件等，具体参考后文对图4D的介绍。

电子设备100可以通过ISP，摄像头170，视频编解码器180，GPU，显示屏150以及应用处理器等实现拍摄功能。

ISP用于处理摄像头170反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头170中。

摄像头170用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头170，N为大于1的正整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器180用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器180。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

在本申请实施例中，视频编解码器180则是硬件编解码器和/或软件编解码器，视频编解码器180可以在Mediacodec通过msm_vidc的控制下，对待压缩的视频进行解码后再按照压缩策略中的目标规格对解码后的视频进行编码，编码后的视频即压缩后的视频。

电子设备100可以通过音频模块，扬声器，受话器，麦克风，耳机接口，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块还可以用于对音频信号编码和解码。在一些实施例中，音频模块可以设置于处理器110中，或将音频模块的部分功能模块设置于处理器110中。

在本申请实施例中，音频模块可用于在播放图库中的视频的同时，或者播放视频剪辑类APP中的视频的同时，播放该视频对应的音频。

通信模块160可以包括移动通信模块、无线通信模块。移动通信模块可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。无线通信模块可以提供应用在电子设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(globalnavigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。

传感器模块190可以包括但不限于压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、环境光传感器、指纹传感器、触摸传感器、骨传导传感器等。

电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

图2是本申请实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图2所示，应用程序包可以包括视频编辑类应用程序(Application，APP)，图库，相机，以及未示出的日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

在本申请实施例中，视频编辑类APP和图库可以是两个应用程序。或者，视频编辑类APP可以集成在图库应用程序中，相当于图库的一个服务组件。并且视频编辑类APP可以是对用户不可见的应用程序，即用户想要运行该APP需要通过图库调用视频编辑类APP，或者视频编辑类APP也可以是为用户提供特有的入口，例如通过点击应用程序图标进入。本申请实施例对视频编辑类APP的类型不作限制，关于视频编辑类APP的作用具体如下:

视频编辑类APP可以包括UI模块、压缩策略模块、压缩SDK和编辑主流程模块等。

其中，UI模块用于调用显示屏194显示视频编辑类APP提供的内容，关于视频编辑类APP所显示的内容，具体可以参考后文UI实施例中介绍的图4D示出的内容，本申请实施例对此不作限制。并且，UI模块还可以根据用户作用在显示屏194上的用于导入视频、编辑视频和导出视频的操作，根据该操作执行对应的事件等等，例如UI模块可以根据用户输入的导入操作，确定用户选择的待导入(还可以称为待压缩)的视频，以及待导入视频的规格。值得注意的是，导入操作可以是直接输入在视频编辑类APP提供的界面，例如在视频编辑类APP中点击导入视频的控件后，视频编辑类APP从图库中获取供用户选择的视频，用户选择好视频后便完成导入操作的输入；或者，导入操作也可以是输入在图库提供的界面，例如图库中选择视频，然后点击编辑控件，便完成导入操作的输入。

其中，压缩策略模块用于确定导入视频时所采用的压缩策略，具体的，压缩策略模块可以调用应用程序框架层中的编解码资源查询模块查询编解码资源，具体包括从宏块资源查询模块中查询硬件编解码资源，和从媒体编解码器(Mediacodec)查询软件编解码资源，并根据编解码资源和待导入视频的规格确定导入视频时的压缩策略。该压缩策略包括但不限于：采用的编解码资源，和目标规格等。具体的，关于压缩策略模块确定导入视频时所采用的压缩策略的具体实现方法可以参考后文的方法描述，在此暂不赘述。

其中，压缩SDK用于接收压缩策略模块发送的压缩策略，并根据该压缩策略控制应用程序框架层中的媒体编解码器(Mediacodec)初始化对应的编解码器，然后控制使用该编解码器对待导入的视频进行编码即压缩，并将压缩后的视频导入至视频编辑类APP，以供用户在该APP中对导入的视频进行编辑。

其中，编辑主流程模块用于从UI模块处接收UI模块检测到的用户操作，执行用户操作对应的事件。

可以理解的是，关于视频编辑类APP包含的上述UI模块、压缩策略模块、压缩SDK和编辑主流程模块的名称仅为示例，本申请实施例这四个模块所使用的名称不作限制，关于这些模块的作用已经在上文和下文中的方法流程中详细记载。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图2所示，应用程序框架层可以包括但不限于：宏块资源查询模块，Mediacodec，内容提供器，窗口管理器，视图系统，通知管理器等。

其中，宏块资源查询模块的作用是，为上层应用提供硬件编解码器的宏块资源查询接口，以供上层应用(例如视频编辑类APP中的压缩策略模块)调用该接口查询硬件编解码器的宏块资源并根据宏块资源确定压缩策略。在本申请另一些实施例中，该宏块资源查询接口可以包括两类接口，一类接口用于查询上述剩余宏块资源，另一类接口则用于查询总宏块资源。

Mediacodec是系统提供的用于对视频进行编解码的类，即为上层应用提供的一个用于对视频进行编解码的统一接口，该接口通过访问底层的编解码器来实现编解码的功能。具体的，在本申请实施例中，上层应用例如视频编辑类APP中的压缩SDK可以调用Mediacodec进行编解码器的创建，即初始化编解码器。此外，Mediacodec为上层应用提供软件编解码的资源查询接口，以供上层应用(例如视频编辑类APP中的压缩策略模块)调用该接口查询软件编解码的资源并根据宏块资源确定压缩策略。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

内核层是硬件和软件之间的层。内核层包含但不限于编解码器驱动(msm_vidc)、显示驱动，摄像头驱动，音频驱动，传感器驱动等等。

msm_vidc用于与硬件层中的编解码器进行交互，负责控制编解码器执行对视频的编解码任务。msm_vidc中的芯片组件的文件中存储有硬件编解码器的宏块资源，具体由msm_vidc在每次开机时将硬件编解码器的宏块资源写入到上述文件中。

在本申请实施例中，电子设备100的软件架构还包括系统库。系统库中的AndroidRuntime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

基于上文对电子设备的软硬件架构的介绍，接下来结合图3所示的方法流程来详细介绍本申请提供的视频压缩方法。

可以理解的是，涉及对视频进行压缩场景有很多，用于触发电子设备对视频进行压缩的具体操作不同。包括但不限于：在导入视频场景下，触发电子设备对视频进行压缩的操作具体为选择图库视频并点击用于导入到视频编辑类APP的控件的操作；在下载视频的场景下，触发电子设备对视频进行压缩的操作具体为选择视频并点击用于下载的控件的操作；或者在电子设备进行传输视频的场景下，触发电子设备对视频进行编解码的操作具体为选择视频并点击用于发送的控件的操作。也就是说，本申请实施例提供的视频压缩方法可以适用于多种涉及对视频进行压缩的场景，但后文所述的视频压缩方法仅以导入视频这一场景为例来详细介绍，其他场景下的压缩方法流程类似，本申请不再赘述。

如图3所示，本申请提供的视频压缩方法流程包括以下步骤：

阶段1(S301)：电子设备根据用户操作，选择待压缩的视频。

S301，电子设备的UI模块接收用户操作。

具体的，电子设备的UI模块可以接收到用户操作，该用户操作是指用于触发电子设备对视频进行压缩的操作。该用户操作又可以称为第一操作。

其中，UI模块具体为电子设备安装的图库和视频编辑类APP包括的模块，关于UI模块的介绍可以参考前文对电子设备软件架构的描述，在此暂不赘述。

其中，用户操作具体为选择图库视频并点击用于导入到视频编辑类APP的控件的操作。

参考图4A，图4A示例性示出在导入视频的场景下，用户输入的用于输触发电子设备进行压缩的操作示意图。

如图4A所示，该用户界面为图库提供的用户界面，具体显示有预览窗口411，和编辑控件412。其中，该预览窗口411可用于显示图库中存储的视频，编辑控件412用于触发电子设备将预览窗口411中的文件导入至电子设备的视频编辑类APP中，以供用户在该APP中对导入的视频进行编辑。在本申请实施例中，图库还可以被称为第二应用程序。图库提供的用户界面还可以称为第二用户界面，该第二用户界面中预览窗口411显示的视频为第一视频，显示的编辑控件412还可以被称为第二控件。

在本申请实施例中，在电子设备接收到上文步骤S301所述的用于从触发电子设备对视频进行压缩的操作后，响应于该操作，电子设备需要确定该视频的压缩策略，用于根据该压缩策略确定目标规格，并在对待压缩的视频进行解码后，按照目标规格再编码，以得到压缩后的视频。该目标规格具体为在电子设备的编解码资源足够的情况下，最优的视频规格，可以既满足在播放该目标规格的视频时用户的视觉体验，又提高了电子设备的编解码资源利用率。

关于电子设备确定压缩策略的具体步骤为后文的S306，也可以参考后文所述的S52-S57-2。

阶段2(S302-S306)：电子设备根据软硬件编解码能力确定压缩策略。

S302,电子设备的UI模块向压缩策略模块发送导入视频的指令。

具体的，在电子设备的UI模块接收到上文步骤S301所述的用于从触发电子设备进行压缩的操作，具体为导入视频的操作后，响应于该操作，UI模块会向压缩策略模块发送导入视频的指令，以使得压缩策略模块获取待压缩视频的压缩策略。该导入视频的指令具体可以携带但不限于以下信息：待导入(也称待压缩)视频的规格，其中待压缩视频的规格为该视频在图库中存储时的初始规格。

其中，压缩策略模块与UI模块一样，都是电子设备安装的视频编辑类APP所包括的模块，关于压缩策略模块的介绍可以参考前文对电子设备软件架构的描述，在此暂不赘述。

S303,电子设备的压缩策略模块向宏块资源模块发送查询硬件编解码能力的请求。

具体的，在电子设备的压缩策略模块接收到UI模块发送的导入视频的指令后，响应于该指令，电子设备的压缩策略模块需要获取电子设备软硬件编解码能力，以为后续确定压缩策略提供判断依据。由于电子设备在确定压缩策略的过程中优先考虑使用硬件编解码资源进行压缩，若硬件编解码的能力不够时再考虑使用软件编解码能力。因此在步骤S303中，电子设备的压缩策略模块先向宏块资源模块发送查询宏块资源的请求，以获取硬件编解码的能力。

其中，硬件编解码的能力包括：硬件编解码的宏块资源、硬件编解码支持的视频规格等等。

其中，宏块资源查询模块是电子设备的应用程序框架层中包括的模块，关于该宏块资源查询模块的介绍可以参考前文对电子设备软件架构的描述，在此暂不赘述。

S304,电子设备的宏块资源查询模块从芯片组件中查询到的硬件编解码能力。

具体的，电子设备的宏块资源查询模块可以为上层应用(即视频编辑类APP的压缩策略模块)提供相应的接口，通过该接口可以从芯片组件的文件中查询到硬件编解码能力，包括硬件编解码的宏块资源、硬件编解码支持的视频规格等等。该芯片组件的文件具体可以存储在电子设备的内核层中的msm_vidc中，并且该芯片组件的文件由msm_vidc在每次开机的时候写入。

S305,电子设备的宏块资源查询模块向压缩策略模块发送查询到的硬件编解码能力。

具体的，响应于电子设备的压缩策略模块发送的查询宏块资源的请求，电子设备的宏块资源查询模块将查询到的硬件编解码能力返回给压缩策略模块。

S306,电子设备的压缩策略模块确定压缩策略。

待压缩具体的，电子设备根据步骤S302中获取的待压缩视频的初始规格，和在步骤S305中获取的硬件编解码能力，确定压缩策略。在本申请实施例中，压缩策略包括：目标规格、编解码资源。其中，目标规格是指将待压缩视频从初始规格压缩为何种目标规格，编解码资源是指，在对压缩后的视频进行后续编辑的过程中，使用硬件编解码资源，或者，结合硬件编解码资源和软件编解码资源根据编辑操作对压缩后的视频进行编解码。

值得注意的是，在确定压缩策略的过程中，当仅采用硬件编解码资源进行压缩时没有可行的压缩策略，则还可以结合软件编解码资源，以确定可行的压缩策略。其中涉及到获取软件编解码能力，具体的压缩策略模块在确定只采用硬件编解码资源无法压缩视频时，则可以通过向Mediacodec发送查询软件编解码能力的请求，Mediacodec将查询到的软件编解码能力返回给压缩策略模块，以供压缩策略模块结合软硬件编解码能力确定压缩策略。

关于压缩策略的具体确定方法具体可以参考后文图5所述的确定压缩策略流程。在此暂不赘述。

阶段3(S307-S315)：电子设备根据压缩策略对待压缩视频进行压缩。

S307,电子设备的压缩策略模块向压缩SDK发送压缩策略。

具体的，电子设备的压缩策略模块将上文步骤S306所述的压缩策略发送至压缩SDK，用于指示压缩SDK根据该压缩策略来压缩视频，当压缩完成后相当于将视频成功导入至视频编辑类APP。

S308,电子设备的压缩SDK调用Mediacodec根据压缩策略初始化编解码器。

具体的，电子设备压缩SDK接收到压缩策略后，可以解析该压缩策略，从中获得目标规格，并调用Mediacodec根据目标规格初始化编解码器。

S309,电子设备的Mediacodec调用msm_vidc初始化编解码器。

具体的，当电子设备的压缩SDK调用Mediacodec根据目标规格初始化编解码器后，Mediacodec可以调用msm_vidc初始化编码器。

S310,电子设备的msm_vidc创建编解码对象。

具体的，电子设备的msm_vidc创建目标规格所对应的编解码对象。例如，目标规格是帧率＝30fps，分辨率为1920*1080时，则msm_vidc创建的编解码对象则长边为1920，短边为1080。

S311,电子设备的msm_vidc向Mediacodec发送编解码对象。

具体的，当电子设备的msm_vidc创建完目标规格所对应的编解码对象之后，msm_vidc则将其返回给Mediacodec。

S312，电子设备的Mediacodec向压缩SDK发送编解码对象。

具体的，当电子设备的Mediacodec接收到msm_vidc发送的目标规格所对应的编解码对象之后，Mediacodec则将其返回给压缩SDK。

S313，电子设备的压缩SDK调用Mediacodec对待压缩视频进行编解码。

具体的，当电子设备的压缩SDK接收到Mediacodec返回的编解码对象之后，则压缩SDK确定编解码对已经创建成功，即编解码器已经完成初始化，则压缩SDK开始调用Mediacodec对待压缩视频进行编解码。

S314，电子设备的Mediacodec调用msm_vidc对待压缩视频进行编解码。

具体的，当电子设备的Mediacodec接收到压缩SDK发送的调用指令后，则调用msm_vidc对待压缩视频进行编解码。

S315，电子设备的msm_vidc根据创建的编解码对象对待压缩视频进行编解码。

具体的，当采用编解码器进行编解码时，则msm_vidc先对待压缩视频执行解码操作，然后根据S310中创建的编解码对象对解码后的视频进行编码，相当于压缩。

阶段4(S316-S318)：电子设备输出指示压缩成功的提示信息。

S316，电子设备的msm_vidc向压缩SDK发送视频压缩成功的指示信息。

具体的，电子设备的msm_vidc检测到完成对视频的编解码时，则可以向压缩SDK返回压缩成功的指示信息。

可选的，在msm_vidc对视频的进行编码(即压缩)的过程中，msm_vidc还可以将编解码进度的相关信息发送至压缩SDK，用于压缩SDK通知UI模块去控制显示屏显示对应的压缩进度。在导入视频场景中，UI模块输出的视频压缩进度具体为视频导入进度，该视频导入进度与压缩进度对应。

关于电子设备的UI模块输出的导入进度具体可以参考图4B，图4B示例示出电子设备输出导入进度421的用户界面示意图，该导入进度421具体为17％，17％代表已经成功压缩了整个视频的17％。导入进度421所显示的进度与编解码进度(即压缩进度)对应，当电子设备对待导入视频的编码(压缩)进度越多时，则输出的导入进度也越多。

S317，电子设备的压缩SDK向UI模块发送视频压缩成功的指示信息。

具体的，电子设备的压缩SDK接收到msm_vidc返回压缩成功的指示信息之后，压缩SDK可以将该指示信息发至UI模块，以使得UI模块输出对应的提示信息。

S318，电子设备的UI模块输出压缩成功的提示信息。

具体的，电子设备的UI模块接收到压缩成功的指示信息之后，则控制显示屏输出指示压缩成功的提示信息。

在导入视频场景中，UI模块输出的视频压缩成功指示信息的形式可以是，视频导入进度为100％，或者还可以是直接跳转显示视频编辑类APP提供视频编辑的用户界面。

参考图4C，图4C示例性示出电子设备输出导出成功的界面示意图。

如图4C所示，用户界面中显示有导入进度421，该导入进度421的进度由图4B中的17％变为100％，100％代表已经成功压缩了整个视频，也代表将视频成功导入至视频编辑类APP。

参考图4D，图4D示例性示出图库提供的预览导入视频的界面。

如图4D所示，该用户界面显示有预览窗口422，视频编辑操作栏425、视频编辑操作栏426、控件423和控件424等等。

其中，预览窗口422用于显示用户正在编辑的视频对象，该视频对象是用户预先导入在该视频编辑类APP中的视频。当用户对该视频进行编辑时，该预览窗口422中显示的视频也会根据用户的编辑操作做出相应的变化，例如当用户对该视频添加音乐或者文字素材时，则当该预览窗口422播放音频时，则会显示相应的文字素材，或者播放相应的音乐等等。

其中，视频编辑操作栏425包含一系列对视频进行的编辑的操作控件，包括但不限于：分割、截取、音量、变速、删除等控件。

其中，视频编辑操作栏426页包含一系列对视频进行的编辑的操作控件，包括但不限于：剪辑、滤镜、音乐、文字、特效等控件。

在本申请实施例中，视频编辑操作栏425和视频编辑操作栏426显示的一系列控件还可以称为第一控件。

其中，控件423用于查看导出视频的规格，视频的规格包括但不限于视频的分辨率、帧率和视频的大小等。通常的，视频的帧率默认为40画面每秒传输帧数(Frame PerSecond，fps)，视频的分辨率通常为导入该视频时视频的分辨率，该导入视频的帧率可能和导入之前存储在图库中的原始视频的帧率相同，也可能不同，即一些视频编辑类APP会根据自己的导入压缩策略对导入的视频的规格进行微调。

其中，控件424用于触发导出视频。

可以理解的是，图4D所示的用户界面仅仅示例性示出视频编辑类APP为用户提供的用于编辑视频的一系列操作控件，不应构成对本申请的限制，本申请实施例对视频编辑类APP所显示的视频编辑界面包括的内容不做限制。

在本申请实施例中，视频编辑类APP还可以被称为第一应用程序。上述图4D所示的视频编辑类APP提供的用户界面还可以称为第一用户界面，该第一用户界面中预览窗口411显示的视频为第二视频，视频编辑操作栏426中显示的控件还可以被称为第一控件。

基于上文对图3所示视频压缩方法流程的介绍，接下来详细介绍上述视频压缩方法流程中步骤S306涉及的压缩策略确定方法。

在本申请实施例中，确定压缩策略具体是根据待压缩的视频的初始规格和电子设备的编解码能力来确定压缩视频时的目标规格，该目标规格还需要满足，电子设备的编解码资源足够支持对该目标规格的视频进行N路编解码，其中,N具体由电子设备对视频进行编辑时所需的编解码资源峰值决定。其中，电子设备的编解码能力支持对多种规格的视频进行N路编解码，电子设备确定的目标规格为该多种规格中最接近待压缩视频的初始规格的一种规格。该多种规格是指帧率和分辨率有高到低划分为多个不同等级的规格。

具体的，电子设备的编解码能力支持对某种规格的视频进行N路编解码包括以下几种情况：

1，该电子设备的硬件编解码能力支持对某种规格的视频进行N路编解码。

具体的，第1种情况指该电子设备的宏块资源数大于或等于，对该某种规格进行N路编解码时占用的宏块资源数。

2，该电子设备的软件编解码能力结合硬件编解码能力，支持对某种规格的视频进行N路编解码。

具体的，第2种情况指该电子设备的宏块资源数大于或等于，对该某种规格进行N-1路编解码时占用的宏块资源数；软件编解码能力支持对该待编码视频的视频格式进行编解码；软件编解码能力支持对该某种规格的视频进行编解码；硬件编解码能力支持对该某种规格的视频进行编解码。

参考图5，图5示例性输出本申请提供的确定压缩策略方法流程。

如图5所示，该方法流程包括以下步骤：

S51，电子设备的压缩策略模块开启确定压缩策略流程。

具体的，在上文步骤S301-S305所述的电子设备的压缩策略模块接收到导入视频的指令获得待导入(待压缩)视频的初始规格，并且获取到电子设备的硬件编解码能力之后，便开启确定压缩策略流程，在确定压缩策略的过程中，若执行到后文步骤S34-1，则还会涉及到获取到电子设备的硬件编解码能力。

接下来，具体介绍确定压缩策略的方法，即确定目标规格的方法。

S52(可选步骤)，电子设备判断待压缩视频的帧率是否大于/等于预设值且分辨率大于/等于预设值。

具体的，电子设备判断待压缩视频的规格中的帧率是否大于预设值且分辨率是否大于预设值，当两者都分别大于对应的预设值时，则电子设备执行后续的S53-1；当两者中任一个或两个不满足大于对应的预设值时，则电子设备执行后续的S53-2。

其中，待压缩视频的规格为待压缩视频的初始规格或者是在初始规格中进行压缩帧率和/或降低分辨率后的视频规格。具体的，当电子设备首次进入压缩策略确定流程时，则S52具体是判断待压缩的视频的初始规格是否满足上述预设值的条件；而当电子设备已经执行过后续S53-1至S57-2的对初始规格进行压缩帧率和/或降低分辨率后再次循环执行到S52时，则此时视频的规格是经过对初始规格压缩后的视频规格，或者是经过对初始规格进行多次压缩后的视频规格。

可以理解的是，步骤S52为可选步骤。当电子设备不执行步骤S52时则直接从步骤S51跳转至下文的步骤S53-1。具体的，通常视频的帧率越高分辨率越高，视频越流畅清晰，为了使得压缩后的视频仍然能为用户带来良好的视觉体验，需要预先设定压缩视频时的目标规格的最低值，例如目标规格中帧率的预设值为30fps，分辨率的预设值为1080P(1920*1080)。由于人眼的特殊生理结构，通常来说，当帧率高于16fps时，会认为视频的每个画面是连续的，但对包含特殊画面内容的视频来说，例如包含交互类的例如射击场景时，如果帧率低于30fps的话，画面会显得不连贯，因此，帧率大于等于30fps都是可以给用户带来良好视觉体验的。当分辨率低于1080P时，人眼会觉得视频明显的不清晰。因此，上述帧率的预设值30fps和分辨率的预设值1080P(1920*1080)只是本申请采取的最优示例，但本申请对此不作具体限制。

S53-1，电子设备判断硬件编解码(Codec)是否支持3路实时编解码。

首先，由于硬件Codec的编解码速率快于软件Codec的编解码速率，因此在确定压缩策略时，优先判断硬件Codec的资源是否足够，当硬件Codec的资源不够时，则需要考虑结合硬件Codec和软件Codec来对待压缩视频进行压缩。

其次，由于用户极有可能对压缩后的视频做其他处理，对视频的处理通常涉及到对视频进行编解码，为了保证有足够的编解码资源支持对压缩后的视频进行编解码，因此在确定压缩策略时，预先考虑后续对压缩后的视频进行编解码所需编解码资源的峰值。具体的，步骤S53-1中的3路实时编解码资源仅仅是在导入视频场景下是根据具体的编解码业务峰值决定的数值，不构成对本申请的限制。可以理解的是，在不同应用场景下，对压缩后的视频的处理不同，会涉及到不同的编解码业务，因此所需编解码资源的峰值也不同。本申请实施例对此不作限制。

接下来，以将视频导入至视频编辑类APP这一场景为例，详细介绍以3路实时编解码资源作为后续的对压缩后的视频进行编解码所需编解码资源的峰值的过程。

当用户将视频从图库导入至视频编辑APP中时，需要对该视频进行编辑，例如添加特效、添加音乐、剪辑视频等等。这些编辑涉及到对编辑前的视频(导入的视频)进行解码然后再编码，当编辑操作对应的编解码业务较复杂时，则需要占用较多的编解码资源，因此为了提高后续编辑视频的可行性，需要预先根据编辑操作对应的编解码业务所需编解码资源的峰值来判断压缩视频时采用的目标规格。其中，“融合转场”的特效可以将前后两个视频片段无缝连接在一起，例如当一个10秒长的待压缩视频中的前5秒拍摄的是景点A的画面，后5秒转场到景点B，为了使得第5秒钟前后两个片段能够连贯播放，可以在第5秒钟添加一个“融合转场”的特效，而该特效的具体实现方法就是需要实现对3路视频的实时编解码，其中1路是用于解码(即播放)添加特效之前的视频，另外2路分别用于同时解码(即播放)添加特效处(第5秒)前后一个时间段(如1秒时长)的视频，也就是说有1路用于对无特效的视频进行解码以播放无特效视频，当播放到第4-5秒时，需要利用第2路对第5-6秒视频进行解码以实现在播放第4-5秒视频时同时播放5-6秒的视频；当播放到第5-6秒时，需要利用第3路对第4-5秒视频进行解码以实现在播放第5-6秒视频时同时播放4-5秒的视频，这样便可以实现在第5秒钟添加“融合转场”特效。可以理解的是，添加“融合转场”的特效对应的业务是视频编辑中所需编解码资源最多的业务，即峰值业务，当满足峰值业务的需求后则一定满足所有业务的需求。

因此，在确定压缩策略流程中，优先在步骤53-1中判断硬件Codec是否支持3路实时编解码，当硬件Codec不支持3路实时编解码则考虑结合软件Codec进行编解码即跳转执行后文的步骤S54-1；当硬件Codec的足够支持3路实时编解码，则无需再对该待压缩视频的规格进行压缩(这里的待压缩视频的规格即前文步骤S52中所述的两种)，即执行后文的步骤S54-2。

其中，计算硬件Codec是否足够支持3路实时编解码的法则为：判断硬件Codec的每秒钟占用宏块数(macro block per second，MBPS)是否满足关系式“MBPS>分辨率*帧率/256*3路”。其中，MBPS的获取方法可具体参考后文方法流程的描述；其中，分辨率和帧率分别为上述待压缩视频的规格中的分辨率和帧率；其中，256为每个宏块的大小，一个宏块占用16*16大小的像素，其中，3路是指在导入场景下对压缩后的视频进行编辑所需的编解码资源峰值。

以一个具体的示例来看，例如，当待压缩的视频规格为帧率是30fps、分辨率是1920p*1080p时，MBPS用X来表示时，若MBPS满足关系式“X≥1920*1080*30/256*3路”，则认为硬件编解码Codec是否支持3路实时编解码；若不满足上述关系式，则认为硬件编解码Codec不支持3路实时编解码。

S53-2，电子设备确定无可行压缩策略。

具体的，电子设备在步骤S52判断得到待压缩视频的规格中的帧率和分辨率中任一个或两个不满足大于对应的预设值时，则电子设备认为无法再对当前待压缩视频的规格进行压缩，并停止执行后续步骤S54-1至37-2。以免压缩得到的视频帧率和分辨率过低，数据丢失严重，影响用户体验。此外，电子设备还可以输出用于指示压缩失败的提示信息。

当在导入视频场景下，若电子设备确定无可行压缩策略时，则拒绝导入该视频并输出提示用户导入视频不成功的提示信息。

S54-1，电子设备在硬件Codec支持2路实时编解码的前提下判断软件Codec是否支持待压缩视频的格式。

具体的，电子设备在步骤S53-1判断得到硬件Codec的资源不够支持3路实时编解码时，则需要考虑结合硬件Codec和软件Codec来对待压缩视频进行压缩。即，电子设备需要判断软件Codec是否支持待压缩视频的格式，这是因为，如今视频格式种类丰富，电子设备的原生软编解码可能不支持其中的部分视频的格式。值得注意的是，在判断软件Codec是否支持待压缩视频的格式的同时，还需判断硬件Codec是否支持2路实时编解码，只有在硬件Codec支持2路实时编解码且软件Codec支持待压缩视频的格式的情况下，电子设备才会执行后续的步骤S55-1；否则电子设备则会执行后续的步骤S55-2。

其中，视频格式包括但不限于：LOG格式、HDR格式、HDR10+格式等等。电子设备的原生软编解码不支持其中的部分视频的格式，例如：LOG格式、HDR格式、HDR10+格式。当电子设备判断待压缩视频的格式不属于上述软编解码不支持的格式时，则执行后续步骤S55-1，否则之后后续的S55-2。

可以理解的是，上述软编解码不支持视频的格式仅为示例，当使用不同操作系统的电子设备，或者不同型号的电子设备，其软编解码所支持的视频的格式不同。

S54-2，电子设备不对待压缩视频进行压缩。

具体的，电子设备在步骤S53-1判断得到硬件Codec支持3路实时编解码时，则说明电子设备的硬件编解码资源足够支持对待压缩视频进行任何编辑操作，因此无需对待压缩的视频的规格进行压缩。其中，待压缩的视频的规格即为步骤S52中待压缩的视频的规格，即待压缩视频的初始规格或者是在初始规格中进行压缩帧率和/或降低分辨率后的视频规格。具体的，当电子设备首次根据触发电子设备对视频进行压缩的操作进入压缩策略确定流程时，则待压缩的视频规格为初始规格(存储在图库的规格)；而当电子设备已经执行过后续S54-1至S57-2的对初始规格进行压缩帧率和/或降低分辨率后循环执行到S54-2时，则此时视频的规格是压缩后的视频规格。

S55-1，电子设备判断硬件Codec是否支持待压缩视频的规格。

具体的，在上文电子设备已经确定硬件Codec无法支持3路实时编解码但软件Codec支持对视频的格式的情况下，则说明此时电子设备需要考虑结合软硬件编解码资源来同时支持对压缩后的视频进行编解码。因此，电子设备则需要进一步确定硬件Codec和软件Codec是否都支持待压缩视频的规格，首先电子设备优先考虑硬件Codec是否支持待压缩视频的规格，若硬件Codec支持待压缩视频的规格，则电子设备执行步骤S56-1中的判断软件Codec是否支持待压缩视频的规格；若硬件Codec不支持待压缩视频的规格，则电子设备执行步骤S56-2中的对初始规格进行压缩帧率和/或降低分辨率。

其中，判断硬件Codec是否支持待压缩视频的规格的方法为：判断待压缩视频的规格中的帧率是否小于/等于预设帧率，并且，待压缩视频的规格中的分辨率中的长边是否小于/等于预设分辨率中的长边，并且，待压缩视频的规格中的分辨率中的短边是否小于/等于预设分辨率中的边边。当同时满足上述三个条件时，则说明硬件Codec支持待压缩视频的规格；当同时不满足上述三个条件时，则说明硬件Codec不支持待压缩视频的规格；当满足上述三个条件中的任意一个或两个时，则进一步判断待压缩视频的规格所对应的宏块是否小于/等于预设宏块，若小于/等于预设宏块，则说明硬件Codec支持待压缩视频的规格；若大于预设宏块，则硬件Codec不支持待压缩视频的规格。在本申请中，预设帧率、预设分辨率和预设宏块是根据硬件Codec的属性相关的值，不同硬件Codec对应的预设帧率、预设分辨率和预设宏块可能不同。

以一个具体的示例来看，当预设帧率为30fps，预设分辨率为2520*1080，其中长边为2520短边为1080，预设宏块为2520*1080*30＝81648000时：

若待压缩视频的规格为：帧率＝30fps，分辨率为2048*1080，由于待压缩视频的帧率等于预设帧率，待压缩视频分辨率的长边2048小于预设分辨率的长边2520，待压缩视频分辨率的短边1080等于预设分辨率的短边1080，则确定硬件Codec支持待压缩视频的规格(30fps，2048*1080)。

若待压缩视频的规格为：帧率＝30fps，分辨率为2048*1280，由于待压缩视频的帧率等于预设帧率，待压缩视频分辨率的长边2048小于预设分辨率的长边2520，但是待压缩视频分辨率的短边1280大于预设分辨率的短边1080，则判断待压缩视频的规格对应的宏块是否小于预设宏块，由于2048*1280*30<2520*1080*30，因此确定硬件Codec支持待压缩视频的规格(30fps，2048*1280)。

若待压缩视频的规格为：帧率＝60fps，分辨率为4096*2160，由于待压缩视频的帧率大于预设帧率，待压缩视频分辨率的长边4096大于预设分辨率的长边2520，待压缩视频分辨率的短边2160大于预设分辨率的短边1080，则确定硬件Codec不支持待压缩视频的规格(60fps，4096*2160)。

S55-2，电子设备确定无可行的压缩策略。

具体的，电子设备在步骤S54-1判断得到软件Codec不支持待压缩视频的格式时，则电子设备认为无法再对当前待压缩视频的规格进行压缩，并停止执行后续步骤S56-1至37-2。以免在后续对压缩后的视频进行编辑时需要占用3路编解码资源时，由于硬件编解码资源不足够3路需要结合软件编解码资源，而软件Codec不支持待压缩视频的格式，从而导致编辑失败的问题，影响用户体验。此外，电子设备还可以输出用于指示压缩失败的提示信息。

S56-1，电子设备软件Codec是否支持待压缩视频的规格。

具体的，在电子设备判断硬件Codec支持待压缩视频的规格后，则继续判断软件Codec是否支持待压缩视频的规格。在软件Codec支持待压缩视频的规格的情况下，电子设备才会执行后续的步骤S57-1；否则电子设备则会执行后续的步骤S57-2。

其中，判断软件Codec是否支持待压缩视频的规格的方法为：判断待压缩视频的规格中的帧率是否小于/等于预设帧率，并且，待压缩视频的规格中的分辨率中的长边和短边都在预设分辨率范围内，即长边是否小于/等于最大值、短边是否大于/等于最小值。当同时满足上述三个条件时，则说明软件Codec支持待压缩视频的规格；否则，说明软件Codec不支持待压缩视频的规格。在本申请中，预设帧率、预设分辨率是根据软件Codec的属性对应的值，不同软件Codec对应的预设帧率、预设分辨率可能不同。

以一个具体的示例来看，当预设帧率为30fps，预设分辨率中短边最小值为98，长边最大值为1920时：

若待压缩视频的规格为：帧率＝30fps，分辨率为2048*1080，由于待压缩视频的帧率等于预设帧率，虽然待压缩视频分辨率的短边1080大于最小值98，但是待压缩视频分辨率的长边2048大于最大值1920，则确定软件Codec不支持待压缩视频的规格(30fps，2048*1080)。

若待压缩视频的规格为：帧率＝30fps，分辨率为1920*1080，由于待压缩视频的帧率等于预设帧率，待压缩视频分辨率的短边1080大于最小值98，待压缩视频分辨率的长边1920等于最大值1920，则确定软件Codec支持待压缩视频的规格(30fps，2048*1080)。

S56-2，电子设备对待压缩视频的规格进行压缩帧率和/或降低分辨率。

具体的，由于电子设备在步骤S55-1中判断得到硬件Codec不支持待压缩视频的规格的情况下，说明此时待压缩视频的规格中的帧率和/或降低分辨率较大，需要压缩视频的规格，即压缩帧率和/或降低分辨率。

当电子设备执行完步骤S56-2得到经过压缩帧率和/或降低分辨率的视频规格后，则基于该视频规格跳转至步骤S52，即重复执行图3所示的方法流程，直至电子设备确定无可行压缩策略(即执行步骤S53-2或S55-2)，或者确定压缩策略并按照压缩策略对待压缩视频进行压缩，以得到目标规格的视频(即执行步骤S57-1)。

值得注意的是，步骤S56-2中所述的此时待压缩视频的规格可能为待压缩视频的初始规格，也可能是经过压缩帧率和/或降低分辨率后的规格。当电子设备在确定压缩策略的过程中首次执行步骤S56-2时，则此时待压缩视频的规格为待压缩视频的初始规格。若电子设备在确定压缩策略的过程中非首次执行步骤S56-2，即执行完步骤S56-2或步骤S57-2后循环到步骤S52，又重复执行步骤S56-2时，则此时待压缩视频的规格为上一次执行步骤S56-2或步骤S57-2后电子设备确定的对初始规格压缩后的规格。

关于压缩帧率的具体实现方法可以参考后文对图6所示的方法流程的介绍，这里暂不赘述。

关于降低分辨率的具体实现方法可以参考后文对图7所示的方法流程的介绍，这里暂不赘述。

S57-1，电子设备确定压缩策略。

具体的，在电子设备确定软件Codec支持待压缩视频的规格的情况下，电子设备可以确定压缩策略，该压缩策略指示了压缩后的视频的规格，即目标规格。该目标规格具体用于上文图3所述的方法流程中步骤S307-S315所述的电子设备可以按照目标规格对视频进行压缩，以得到目标规格的视频。

其中，目标规格可能是待压缩视频的初始规格，也可能是对初始规格经过压缩帧率和/或降低分辨率后的规格。具体的，当电子设备未执行过上述步骤S56-2或者步骤S57-2时，则目标规格是待压缩视频的初始规格；当电子设备执行过上述步骤S56-2或步骤S57-2时，则目标规格为，上一次执行完步骤S56-2或步骤S57-2后电子设备对初始规格进行压缩后得到的规格。

以导入视频场景为例，在步骤S57-1中电子设备压缩视频的过程中还会输入如图4B所述的提示信息，该提示信息用于提示用户视频导入的进度，该进度与视频压缩的进度相对应，当视频压缩成功后则说明视频导入完成，此时还会能显示如图4C所示的导入进度条为100％的提示信息，或者此时还会显示如图4D所示的视频编辑APP提供的视频编辑界面。

S57-2，电子设备对待压缩视频的规格进行压缩帧率和/或降低分辨率。

具体的，由于电子设备在步骤S56-1中判断得到软件Codec不支持待压缩视频的规格的情况下，说明此时待压缩视频的规格中的帧率和/或降低分辨率较大，需要压缩视频的规格，即压缩帧率和/或降低分辨率。

当电子设备执行完步骤S57-2得到经过压缩帧率和/或降低分辨率的视频规格后，则基于该视频规格跳转至步骤S52，即重复执行图3所示的方法流程，直至电子设备确定无可行压缩策略(即执行步骤S53-2或S55-2)，或者确定压缩策略并按照压缩策略对待压缩视频进行压缩，以得到目标规格的视频(即执行步骤S57-1)。

值得注意的是，步骤S57-2中所述的此时待压缩视频的规格可能为待压缩视频的初始规格，也可能是经过压缩帧率和/或降低分辨率后的规格。具体的，当电子设备在确定压缩策略的过程中首次执行步骤S57-2，并且电子设备未执行过上述步骤S56-2时，则此时待压缩视频的规格即目标规格是待压缩视频的初始规格；当在确定压缩策略的过程中首次执行步骤S57-2，并且电子设备执行过上述步骤S56-2时，则此时待压缩视频的规格为，执行完步骤S56-2后电子设备对初始规格进行压缩后得到的规格；当电子设备在确定压缩策略的过程中非首次执行步骤S57-2时，即执行完步骤S57-2后循环到步骤S52，又重复执行步骤S57-2时，则此时待压缩视频的规格为，上一次执行完步骤S57-2后电子设备对初始规格进行压缩后得到的规格。

可以理解的是，图5所述的确定压缩策略涉及的多个判断步骤的顺序为本申请提供的一种最优的实现顺序，本申请对每个判断步骤的顺序不作限制，在本申请另一些实施例中，电子设备还可以先执行判断步骤S53-1后执行步骤S52，即先判断软件codec是否支持待压缩视频的规格，后判断硬件codec是否支持对待压缩视频进行3路实时编解码。

基于上文对视频压缩方法流程的介绍，接下来详细介绍上述视频压缩方法流程中步骤S56-2和步骤S56-2涉及的对待压缩视频的规格进行压缩帧率和/或降低分辨率的具体实现方法。

在本申请实施例中，可以同时压缩帧率和降低分辨率，也可以只压缩帧率，也可以只降低分辨率，也可以先压缩帧率后降低分辨率，或者也可以先降低分辨率后压缩帧率。本申请实施例对此不作限制，但优选的可以先压缩帧率，后降低分辨率。具体原因如下：

由于人眼的特殊生理结构，对于帧率来说，当帧率高于30fps时画面都是连贯的，因此人眼对帧率高于30fps的情况下，对帧率压缩的感知能力较弱，也就是说，只要保证视频帧率大于30fps，压缩视频帧率不会影响用户的视觉体验或者说对用户的视觉体验的影响较小。但是，对于分辨率来说，由于人眼对分辨率降低的感知能力强于帧率压缩(大于30fps)的感知能力。因此在对待压缩视频的规格进行压缩时，优先压缩帧率，在压缩帧率后得到的视频规格仍然不满足上文步骤S52-S56-1所述的条件时，则再降低待压缩视频的分辨率。

参考图6，图6示例性示出压缩帧率的方法流程。

如图6所示，该方法流程包括以下步骤：

S61，电子设备的压缩策略模块开启压缩帧率流程。

具体的，在上文步骤S56-2或者57-2所述的电子设备的压缩策略模块对待压缩视频的规格进行压缩帧率时，压缩策略模块便先开启压缩帧率流程。

接下来，具体介绍压缩帧率的方法。

S62(可选步骤)，电子设备判断待压缩视频的帧率是否大于预设值。

具体的，电子设备的压缩策略模块判断待压缩视频的规格中的帧率是否大于预设值，当待压缩视频的规格中的帧率大于对应的预设值时，则电子设备执行后续的S63-1；当待压缩视频的规格中的帧率不满足大于对应的预设值时，则电子设备执行后续的S63-2。

其中，待压缩视频的规格为待压缩视频的初始规格或者是在初始规格中进行压缩帧率和/或降低分辨率后的视频规格。具体的，当电子设备首次进入压缩策略确定流程时相当于首次进入压缩帧率的流程，则S62具体是判断待压缩的视频的初始规格中的帧率是否满足大于上述预设值的条件；而当电子设备之前已经执行过后续的63-1中的对初始规格进行压缩帧率的流程。

可以理解的是，步骤S62为可选步骤。当电子设备不执行步骤S62时则直接从步骤S61跳转至下文的步骤S63-1。具体的，通常视频的帧率越高，视频越流畅，为了使得压缩后的视频仍然能为用户带来良好的视觉体验，需要预先设定压缩视频时的目标规格的最低值，例如目标规格中帧率的预设值为30fps，则需要判断待压缩视频的规格中的帧率是否大于30fps，只有大于30fps的情况下，待压缩视频的规格中的帧率才有继续压缩的空间。

S63-1，电子设备将帧率压缩后返回至重新执行确定压缩策略流程。

具体的，电子设备可以根据待压缩视频的帧率，以及帧率对应的预设值，将帧率逐级压缩，并保证压缩后的帧率仍然大于预设值例如30fps，然后将压缩后的帧率作为待压缩视频的新帧率，并基于该待压缩视频的新帧率重新执行确定压缩策略流程，即返回至前文所述的步骤S52以重新执行图5所示的方法流程。

帧率逐级压缩具体可以为从大到小依次包括但不限于以下等级：60fps、50fps、40fps和30fp。以一个具体的压缩示例来看，当待压缩视频的帧率大于60fps时，则将其先压缩为60fps；当待压缩视频的帧率大于50fps且小于/等于60fps时，则将其先压缩为50fps；当待压缩视频的帧率大于40fps且小于/等于50fps时，则将其先压缩为40fps；当待压缩视频的帧率大于30fps且小于/等于40fps时，则将其先压缩为30fps。

可以理解的是，上述逐级压缩帧率的方法仅为示例，在本申请另一些实施例中，还可以通过划分其他更多或者更少等级的帧率，以实现逐级压缩帧率，本申请对此不作限制。

S63-2，电子设备的压缩策略模块确定进入降分辨率流程。

具体的，当电子设备的压缩策略模块在步骤S62中判断得到待压缩视频的规格中的帧率不满足大于对应的预设值时，则说明此时的帧率没有可压缩的空间，因此则考虑降分辨率，即进入降分辨率流程，重新判断在压缩帧率以及降分辨率后得到的规格是否满足压缩策略流程中给出的条件。具体见图7所示的降低分辨率的方法流程。

参考图7，图7示例性示出降低分辨率的方法流程。

如图7所示，该方法流程包括以下步骤：

S71，电子设备的压缩策略模块开启降低分辨率流程。

具体的，当电子设备执行过图6所示的压缩帧率流程，并且已将帧率压缩到预设值后仍然没能得到S57-1所述的压缩策略，则电子设备开始执行降低分辨率的流程。

接下来，具体介绍压缩帧率的方法。

S72(可选步骤)，电子设备判断待压缩视频的分辨率是否大于预设值。

具体的，电子设备的压缩策略模块判断待压缩视频的规格中的分辨率是否大于预设值，当待压缩视频的规格中的分辨率大于对应的预设值时，则电子设备执行后续的S73-1；当待压缩视频的规格中的分辨率不满足大于对应的预设值时，则电子设备执行后续的S73-2。

其中，待压缩视频的规格为待压缩视频的初始规格或者是在初始规格中进行压缩帧率和/或降低分辨率后的视频规格。具体的，当电子设备首次进入压缩策略确定流程时相当于首次进入压缩分辨率的流程，则S72具体是判断待压缩的视频的初始规格中的分辨率是否满足大于上述预设值的条件；而当电子设备之前已经执行过后续的73-1中的对初始规格进行降低的流程，则S72具体是判断待压缩的视频的初始规格中的帧率是否满足大于上述预设值的条件。

可以理解的是，步骤S72为可选步骤。当电子设备不执行步骤S72时则直接从步骤S71跳转至下文的步骤S73-1。具体的，通常视频的分辨率越高，视频越清晰，为了使得降低分辨率后的视频仍然能为用户带来良好的视觉体验，需要预先设定降低分辨率后得到的目标规格的最低值，例如目标规格中分辨率的预设值为1920*1080时，则需要判断待压缩视频的规格中的分辨率的长边是否大于1920，短边是否大于1080。只有在两者都分别大于对应值的情况下，待压缩视频的规格中的分辨率才有继续降低的空间。

S73-1，电子设备将分辨率降低后返回至重新执行确定压缩策略流程。

具体的，电子设备可以根据待压缩视频的分辨率，以及分辨率对应的预设值，将分辨率逐级压缩，并保证降低后的分辨率仍然大于预设值例如1920*1080，然后将降低后的分辨率作为待压缩视频的新分辨率，并基于该待压缩视频的新分辨率重新执行确定压缩策略流程，即返回至前文所述的步骤S52以重新执行图5所示的方法流程。

分辨率逐级压缩具体可以为从大到小依次包括但不限于以下等级：4K，2K，1080P；其中4K对应的场景分辨率有4096*2160，4K对应的场景分辨率有2048*1080；1080P对应的常见的分辨率有1920*1080和1920*824等。值得注意的是同一分辨率对应有多种宽高比，例如1080P对应的常见的分辨率有1920*1080和1920*824。因此在逐级降低分辨率时，还要考虑到待压缩视频初始规格中的宽高比，例如当宽高比为21:9时，则将分辨率降低为1080P时，其对应的分辨率具体为1920*824。以一个具体的降低分辨率示例来看，当待压缩视频的分辨率大于4K时，则将其先降低为2K；当待压缩视频的帧率大于1080P且小于/等于2K时，则将其先压缩为1080P。

可以理解的是，上述逐级降低分辨率的方法仅为示例，在本申请另一些实施例中，还可以通过划分其他更多或者更少等级的分辨率，以实现逐级降低分辨率，本申请对此不作限制。

S73-2，电子设备的压缩策略模块确定无可行的压缩策略。

具体的，当电子设备的压缩策略模块在步骤S72中判断得到待压缩视频的规格中的分辨率不满足大于对应的预设值时，则说明此时的分辨率没有可降低的空间，因此则确定无可行压缩策略。

此外，电子设备还可以输出指示压缩失败的提示信息，该指示压缩失败的提示信息具体可以为导入失败的提示信息。

综上所述，实施本申请提供的压缩视频的方法后，具有以下技术效果：

首先，在编解码资源足够的情况下，能够采用更优的视频规格作为目标规格来对该视频进行压缩，既提升压缩视频的成功率，又提高了电子设备的编解码资源利用率。

其次，在确定目标规格的过程中，考虑到用户极有可能对压缩后的视频进行其他操作。特别是在将图库中的视频导入视频编辑APP的场景下，由于后续需要对压缩后的视频进行编辑，当编辑操作对应的编解码业务较复杂时，需要占用较多的编解码资源，因此本申请确定的目标规格是根据占用编解码资源峰值而确定的。也就是说，电子设备的编解码资源足够支持，对目标规格的视频进行任何编辑操作，包括占用较多编解码资源的复杂编辑操作，因此提高后续编辑视频的可行性，提高用户体验。

应理解，本申请提供的上述方法实施例中的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

本申请还提供一种电子设备，该电子设备可以包括：存储器和处理器。其中，存储器可用于存储计算机程序；处理器可用于调用所述存储器中的计算机程序，以使得该电子设备执行上述任意一个实施例中的方法。

本申请还提供了一种芯片系统，所述芯片系统包括至少一个处理器，用于实现上述任意一个实施例中电子设备执行的方法中所涉及的功能。

在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和数据，存储器位于处理器之内或处理器之外。

该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

可选地，该芯片系统中的处理器可以为一个或多个。该处理器可以通过硬件实现也可以通过软件实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等。当通过软件实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现。

可选地，该芯片系统中的存储器也可以为一个或多个。该存储器可以与处理器集成在一起，也可以和处理器分离设置，本申请实施例并不限定。示例性地，存储器可以是非瞬时性处理器，例如只读存储器ROM，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型，以及存储器与处理器的设置方式不作具体限定。

示例性地，该芯片系统可以是现场可编程门阵列(field programmable gatearray，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processorunit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。

本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述任一个实施例中电子设备执行的方法。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行上述任一个实施例中电子设备执行的方法。

本申请的各实施方式可以任意进行组合，以实现不同的技术效果。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid StateDisk)等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

总之，以上所述仅为本发明技术方案的实施例而已，并非用于限定本发明的保护范围。凡根据本发明的揭露，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种视频压缩方法，其特征在于，所述方法应用于电子设备，所述方法包括：

所述电子设备接收到针对第一视频的第一操作；所述第一视频的视频规格为第一规格；

所述电子设备根据所述第一规格，和，所述电子设备的编解码能力，确定目标规格；所述电子设备的编解码能力支持对多种视频规格的视频进行N路编解码，所述目标规格为所述多种视频规格中小于并最接近所述第一规格的规格，所述N由对视频进行编辑时所需的编解码资源峰值决定；

所述电子设备对所述第一视频进行压缩，得到第二视频，所述第二视频的视频规格为所述目标规格。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述电子设备接收针对所述第二视频的编辑操作；

所述电子设备对所述第二视频进行N路编解码，得到第三视频，所述第三视频的视频规格为所述目标规格。

3.根据权利要求2所述的方法，其特征在于，所述电子设备完成对所述第一视频压缩之后，所述方法还包括：

所述电子设备显示提供的第一用户界面，所述第一用户界面中显示有第一控件，针对所述第二视频的编辑操作包括作用于所述第一控件的用户操作。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述视频规格包括以下任意一个或多个：帧率，分辨率。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述编解码能力包括：硬件编解码能力和软件编解码能力；

所述硬件编解码能力根据硬件编解码支持的视频规格和所述硬件编解码的每秒钟占用宏块数MBPS决定；

所述软件编解码能力根据软件编码支持的视频规格和视频格式决定。

6.根据权利要求5所述的方法，其特征在于，所述目标规格满足以下任意一种条件：

所述硬件编解码的MBPS，大于或等于，对所述目标规格的视频进行N路编解码时占用的宏块资源数；

或者，所述硬件编解码的MBPS，大于或等于，对所述目标规格的视频进行N-1路编解码时占用的宏块资源数，并且所述软件编解码支持对所述第一视频的视频格式进行编解码，并且所述硬件编解码和所述软件都支持对所述目标规格进行编解码。

7.根据权利要求1-6中任一项所述的方法，其特征在于，在所述电子设备接收第一操作之前，所述方法还包括：

所述电子设备显示第二用户界面，所述第二用户界面显示有所述第一视频的预览窗口，和，第二控件；所述第一操作包括：作用于所述第二控件的操作。

8.根据权利要求1-7中任一项所述的方法，其特征在于，所述方法还包括：

所述电子设备对所述第一视频进行压缩的过程中，所述电子设备显示第三用户界面，所述第三用户界面中显示进度条，所述进度条用于指示所述电子设备对所述第一视频进行压缩的进度。

9.根据权利要求1-8中任一项所述的方法，其特征在于，所述电子设备对所述第一视频进行压缩，得到第二视频之后，所述方法还包括：

所述电子设备输出指示完成对所述第一视频的压缩的提示信息。

10.根据权利要求7-9中任一项所述的方法，其特征在于，所述第一用户界面由第一应用程序提供，所述第二用户界面和所述第三用户界面由第二应用程序提供；所述第一应用程序和所述第二应用程序为相同应用或不同应用。

11.根据权利要求10所述的方法，所述第一应用程序为视频编辑应用，所述第二应用程序为图库应用。

12.一种芯片，所述芯片应用于电子设备，所述芯片包括一个或多个处理器，所述处理器用于调用计算机指令以使得所述电子设备执行如权利要求1-11中任一项所述的方法。

13.一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-11中任一项所述的方法。

14.一种电子设备，其特征在于，所述电子设备包括一个或多个处理器和一个或多个存储器；其中，所述一个或多个存储器与所述一个或多个处理器耦合，所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，使得所述电子设备执行如权利要求1-11中任一项所述的方法。