视频分享方法、电子设备、存储介质及程序产品与流程

1.本技术涉及终端技术领域，具体地涉及一种视频分享方法、电子设备、存储介质及程序产品。


背景技术：

2.目前，当应用程序需要分享高效率视频编码(high efficiency video coding，hevc)格式的视频时，如果安卓系统确定应用程序不支持hevc格式，那么可以自动将该视频转码为高级视频编码(advanced video coding，avc)格式，进而为应用程序提供avc格式的视频。然而，安卓系统只能对小于默认时长如小于1分钟的视频进行转码，如果该视频的时长超过默认时长，即使应用程序不支持hevc格式，也不会对该视频进行转码。
3.上述默认时长虽然可以灵活调整，但如果默认时长较短，会限制对视频的转码功能，导致不支持hevc格式的应用程序无法分享时长较长的hevc格式视频。但是如果将默认时长调整的过长，那么对视频进行转码的耗时也会较长，导致分享视频的时延增加。


技术实现要素：

4.有鉴于此，本技术提供一种视频分享方法、电子设备、存储介质及程序产品，以解决现有技术分享视频的时延较长的问题。
5.第一方面，本技术实施例提供一种视频分享方法，所述方法应用于电子设备，所述方法包括：接收对目标视频的分享操作，所述分享操作用于指示通过指定应用程序分享所述目标视频；响应于所述分享操作，获取所述目标视频的预转码文件，所述预转码文件为预先将所述目标视频转码为第一格式得到的文件，所述第一格式为所述指定应用程序支持的格式；向所述指定应用程序发送所述预转码文件，以使得所述指定应用程序响应于所述分享操作，对所述预转码文件进行分享。
6.采用该方法，当接收到对目标视频的分享操作时，因目标视频已被预先转码为指定应用程序支持的格式，所以可以获取到目标视频的预转码文件，并发送给指定应用程序，那么指定应用程序此时就无需等待电子设备对目标视频进行转码，可以减少等待时间。相比于在接收到分享操作后再进行转码，本技术实施例可以降低指定应用程序分享目标视频的时延，提高用户体验。
7.在一种可能的实现方式中，所述获取所述目标视频的预转码文件，包括：在确定需要对所述目标视频进行转码的情况下，获取所述目标视频的预转码文件。
8.在一种可能的实现方式中，所述方法还包括：接收对所述目标视频的收藏操作；响应于所述收藏操作，在所述目标视频满足预转码条件的情况下，将所述目标视频转码为所述第一格式，得到所述预转码文件。
9.在一种可能的实现方式中，在所述接收对所述目标视频的收藏操作之后，所述方法还包括：判断所述目标视频的格式是否为第二格式；若所述目标视频的格式不是所述第二格式，则确定所述目标视频不满足所述预转码条件；若所述目标视频的格式是所述第二
格式，则判断所述目标视频的时长是否小于默认转码时长；若所述目标视频的时长小于所述默认转码时长，则确定所述目标视频满足所述预转码条件；若所述目标视频的时长大于等于所述默认转码时长，则确定所述目标视频不满足所述预转码条件。
10.可选地，默认转码时长可以小于1分钟；或者默认转码时长也可以大于等于1分钟，比如还可以为2分钟。因为是在分享目标视频之前对目标视频进行预转码，所以默认转码时长的延长不会对分享目标视频的过程造成影响，实现了在不影响用户体验的前提下，延长默认转码时长，使得app可以分享时长更长的视频。
11.在一种可能的实现方式中，在将所述目标视频转码为所述第一格式，得到所述预转码文件之后，所述方法还包括：将所述目标视频的视频信息加入预转码队列，所述预转码序列为先进先出队列，所述视频信息包括所述目标视频的id；当按照先进先出顺序对所述目标视频的视频信息进行出队处理时，处理所述目标视频的预转码文件。
12.在一种可能的实现方式中，所述处理所述目标视频的预转码文件，包括：将所述目标视频的预转码文件删除。
13.在一种可能的实现方式中，所述视频信息还包括标记位，所述标记位的值为第一标记值或第二标记值，所述第一标记值表示所述目标视频未被分享，所述第二标记值表示所述目标视频已被分享，所述标记位的初始值为所述第一标记值；所述处理所述目标视频对应的预转码文件，包括：获取所述目标视频的视频信息包括的标记位；若所述标记位的值为第一标记值，则将所述目标视频的所述预转码文件删除；若所述目标视频的标记位的值为所述第二标记值，则保留所述目标视频的所述预转码文件。
14.在一种可能的实现方式中，在响应于所述分享操作，获取所述目标视频的预转码文件之后，所述方法还包括：将所述目标视频的标记位的值由所述第一标记值修改为所述第二标记值。
15.在一种可能的实现方式中，所述预转码队列包括预设数量的队列元素，所述队列元素为键值对key-value的格式，key为所述目标视频的id，value为所述标记位。
16.第二方面，本技术实施例提供一种电子设备，包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被所述处理器执行时，触发所述电子设备执行第一方面任一项所述的步骤。
17.第三方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质包括存储的程序，其中，在所述程序运行时控制所述计算机可读存储介质所在设备执行第一方面任意一项所述的方法。
18.第四方面，本技术实施例提供了一种计算机程序产品，所述计算机程序产品包含可执行指令，当所述可执行指令在计算机上执行时，使得计算机执行第一方面任意一项所述的方法。
附图说明
19.为了更清楚地说明本技术实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
20.图1为本技术实施例提供的一种电子设备示意图；
21.图2为本技术实施例提供的一种电子设备的软件结构框图；
22.图3a为本技术实施例提供的一种分享视频的场景示意图；
23.图3b为本技术实施例提供的另一种分享视频的场景示意图；
24.图4为本技术实施例提供的另一种分享视频的场景示意图；
25.图5为本技术实施例提供的一种视频分享方法的流程图；
26.图6为本技术实施例提供的另一种视频分享方法的流程图；
27.图7为本技术实施例提供的一种预转码方法的示意图；
28.图8为本技术实施例提供的一种预转码过程的示意图；
29.图9为本技术实施例提供的另一种视频分享方法的流程图；
30.图10为本技术实施例提供的一种手机内部软件的调用时序图。
具体实施方式
31.为了更好的理解本技术的技术方案，下面结合附图对本技术实施例进行详细描述。
32.为了便于清楚描述本技术实施例的技术方案，在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一指令和第二指令是为了区分不同的用户指令，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
33.需要说明的是，本技术中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本技术中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
34.本技术实施例可应用于平板电脑、个人计算机(personal computer，pc)、个人数字助理(personal digital assistant，pda)、智能手表、上网本、可穿戴电子设备、增强现实技术(augmented reality，ar)设备、虚拟现实(virtual reality，vr)设备、车载设备、智能汽车、机器人、智能眼镜、智能电视等电子设备中。
35.需要指出的是，在一些可能的实现方式中，电子设备也可能称为终端设备、用户设备(user equipment，ue)等，本技术实施例对此不作限制。
36.如图1所示，图1为本技术实施例提供的一种电子设备的示意图，图1所示的电子设备可以包括处理器110、外部存储器接口120、内部存储器121、通用串行总线(universal serial bus，usb)接口130、充电管理模块140、电源管理模块141、电池142、天线1、天线2、移动通信模块150、无线通信模块160、音频模块170、扬声器170a、受话器170b、麦克风170c、耳机接口170d、传感器模块180、按键190、马达191、指示器192、摄像头193、显示屏194、以及用户标识模块(subscriber identity module，sim)卡接口195等。其中，传感器模块180可以包括压力传感器180a、陀螺仪传感器180b、气压传感器180c、磁传感器180d、加速度传感器180e、距离传感器180f、接近光传感器180g、指纹传感器180h、温度传感器180j、触摸传感器180k、环境光传感器180l、以及骨传导传感器180m等。
37.可以理解的是，本技术实施例示意的结构并不构成对电子设备的具体限定。在本技术另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件、或软件和硬件的组合实现。
38.处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，ap)、调制解调处理器(modem)、图形处理器(graphics processing unit，gpu)、图像信号处理器(image signal processor，isp)、控制器、视频编解码器、数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
39.处理器110可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
40.处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
41.在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，i2c)接口、集成电路内置音频(inter-integrated circuit sound，i2s)接口、脉冲编码调制(pulse code modulation，pcm)接口、通用异步收发传输器(universal asynchronous receiver/transmitter，uart)接口、移动产业处理器接口(mobile industry processor interface，mipi)、通用输入输出(general-purpose input/output，gpio)接口、以及用户标识模块(subscriber identity module，sim)接口。
42.i2c接口是一种双向同步串行总线，包括一根串行数据线(serial data line，sda)和一根串行时钟线(derail clock line，scl)。在一些实施例中，处理器110可以包含多组i2c总线。处理器110可以通过不同的i2c总线接口分别耦合触摸传感器180k、充电器，闪光灯、摄像头193等。例如：处理器110可以通过i2c接口耦合触摸传感器180k，使处理器110与触摸传感器180k通过i2c总线接口通信，实现电子设备的触摸功能。
43.i2s接口可以用于音频通信。在一些实施例中，处理器110可以包含多组i2s总线。处理器110可以通过i2s总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过i2s接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。
44.pcm接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过pcm总线接口耦合。音频模块170可以将获取到的下行音频流数据和上行音频流数据通过无线通信模块160传输到与电子设备无线连接的电子设备。
45.在一些实施例中，音频模块170也可以通过pcm接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述i2s接口和所述pcm接口都可以用于音频通信。
46.uart接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。
它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，uart接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过uart接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170可以通过uart接口向无线通信模块160传递音频信号，实现通过蓝牙连接的电子设备获得下行音频流的功能。
47.mipi接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。mipi接口包括摄像头串行接口(camera serial interface，csi)、以及显示屏串行接口(display serial interface，dsi)等。在一些实施例中，处理器110和摄像头193通过csi接口通信，实现电子设备100的拍摄功能。处理器110和显示屏194通过dsi接口通信，实现电子设备的显示功能。
48.可以理解的是，本技术实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本技术另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
49.电子设备的无线通信功能可以通过天线1、天线2、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等实现。
50.天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
51.移动通信模块150可以提供应用在第一电子设备上的包括2g/3g/4g/5g等无线通信的解决方案。在一些实施例中，可以通过移动通信模块150实现两个电子设备之间的通话数据的传输，例如，作为被呼叫方设备时，可以获得来自呼叫方设备的下行音频流数据，以及可以向呼叫方设备传输上行音频流数据。
52.无线通信模块160可以提供应用在电子设备上的包括无线局域网(wireless local area networks，wlan)(如无线保真(wireless fidelity，wi-fi)网络)、蓝牙(bluetooth，bt)、全球导航卫星系统(global navigation satellite system，gnss)、调频(frequency modulation，fm)、近距离无线通信技术(near field communication，nfc)、以及红外技术(infrared，ir)等无线通信的解决方案。
53.在一些实施例中，电子设备的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。在本技术的一个实施例中，电子设备可以通过无线通信模块160实现与另一电子设备的局域网络连接。无线通信技术可以包括全球移动通讯系统(global system for mobile communications，gsm)、通用分组无线服务(general packet radio service，gprs)、码分多址接入(code division multiple access，cdma)、宽带码分多址(wideband code division multiple access，wcdma)、时分同步码分多址(time-division-synchronous code division multiple access，td-scdma)，长期演进(long term evolution，lte)、bt、gnss、wlan、nfc、fm、和/或ir技术等。gnss可以包括全球卫星定位系统(global positioning system，gps)、全球导航卫星系统(global navigation satellite system，glonass)、北斗卫星导航系统(beidou navigation satellite system，bds)、准天顶卫星系统(quasi-zenith satellite system，qzss)、和/或星基增强系统(satellite based augmentation system，sbas)等。
54.显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，lcd)、有机发光二极管(organic light-emitting diode，oled)、有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，amoled)、柔性发光二极管(flex light-emitting diode，fled)、miniled、microled、micro-oled、以及量子点发光二极管(quantum dot light emitting diode，qled)等。在一些实施例中，电子设备可以包括1个或n个显示屏194，n为大于1的正整数。
55.外部存储器接口120可以用于连接外部存储卡，例如micro安全数码(secure digital memory，sd)卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐、视频、录音文件等文件保存在外部存储卡中。
56.内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统、以及至少一个功能所需的应用程序(比如声音播放功能、图像播放功能和录音功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如上行音频数据、下行音频数据和电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、通用闪存存储器(universal flash storage，ufs)等。处理器110通过运行存储在内部存储器121的指令和/或存储在设置于处理器110中的存储器的指令，执行电子设备的各种功能应用以及数据处理。
57.电子设备可以通过音频模块170、扬声器170a、受话器170b、麦克风170c、耳机接口170d、以及应用处理器等实现通话冲突处理功能等。
58.音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
59.受话器170b，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备接听电话或语音信息时，可以通过受话器170b听到呼叫方设备传输的语音。
60.麦克风170c，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170c发声，将声音信号输入到麦克风170c，实现上行音频流的采集。
61.压力传感器180a用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180a可以设置于显示屏194。在一些实施例中，当用户点击按压显示屏194上的接听键时，可实现手动接听通话功能，当用户点击按压显示屏194上的挂断键时，可实现手动挂断通话功能。
62.触摸传感器180k，也称“触控器件”。触摸传感器180k可以设置于显示屏194，由触摸传感器180k与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180k用于检测作用于其上或附近的触摸操作。触摸传感器180k可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180k也可以设置于电子设备的表面，与显示屏194所处的位置不同。
63.按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备可以接收按键输入，产生与电子设备的用户设置以及功能控制有关的键信号输入。
64.马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。
65.sim卡接口195用于连接sim卡。sim卡可以通过插入sim卡接口195，或从sim卡接口195拔出，实现和电子设备的接触和分离。电子设备可以支持1个或n个sim卡接口，n为大于1的正整数。sim卡接口195可以支持nano sim卡，micro sim卡，sim卡等。同一个sim卡接口195可以同时插入多张卡。所述多张卡的类型可以相同，也可以不同。sim卡接口195也可以兼容不同类型的sim卡。sim卡接口195也可以兼容外部存储卡。电子设备通过sim卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备采用esim，即：嵌入式sim卡。esim卡可以嵌在电子设备中，不能和电子设备分离。
66.上述电子设备的软件系统可采用分层结构，本技术实施例以安卓(android)系统的分层架构为例示例性说明电子设备的软件架构。
67.如图2所示，图2为本技术实施例提供的一种电子设备的软件结构框图。
68.分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将android系统分为四层，从上至下分别为应用层、框架层、硬件抽象层和硬件层。
69.应用层(application，app)可以包括一系列应用程序包。例如，应用层可以包括图库、相机、邮件、日历、通话、蓝牙、音乐、视频、微信以及短信等应用程序。
70.其中，相机可以用于录制视频，并将录制好的视频存储于图库中。
71.图库具有分享、收藏等功能。
72.分享功能是指将图库中的视频通过电子设备中的通信类应用程序分享给其他电子设备，通信类应用程序是指能够与其他电子设备进行信息交互的应用程序，比如邮件、微信等。
73.收藏功能用于供用户收藏图库中视频，被收藏的视频可以被存储在一个单独的文件夹中，比如图库中的“个人收藏”文件夹，以方便用户查看或分享。
74.框架层(framework，fwk)为应用层的应用程序提供应用编程接口(application programming interface，api)和编程框架，包括一些预先定义的函数。
75.框架层包括内容解析器(contentresolver)、用户空间守护进程(fusedaemon)、媒体提供器(mediaprovider)、转码助手(transcodehelper)、媒体转码管理器(mediatranscodemanager)、视频轨道转码器(videotracktranscoder)和媒体编解码器(mediacodec)。
76.其中，内容解析器用于从媒体提供器获取应用程序所需的视频文件。
77.用户空间的文件系统(filesystem in userspace，fuse)是在用户态实现的文件系统。用户空间守护进程用于接收并处理其他模块对fuse的访问操作。
78.媒体提供器用于查找应用程序所需的视频文件。
79.转码助手用于受媒体提供器的调用，判断是否需要对视频进行转码。
80.媒体转码管理器用于在转码助手确定需要对视频进行转码的情况下，调用视频轨道转码器对视频进行转码。
81.视频轨道转码器用于调用媒体编解码器对视频进行转码。
82.媒体编解码器是android提供的用于对音视频进行编解码的类，它通过访问底层的codec来实现编解码的功能，是android media基础框架的一部分。
83.硬件抽象层(hal)是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化。它隐藏了特定平台的硬件接口细节,为操作系统提供虚拟硬件平台,使其具有硬件无关性,可在多种平台上进行移植。
84.硬件层(hardware，hw)是位于操作系统最底层的硬件。在图2中，hw包括摄像头1、摄像头2、摄像头3等。其中，摄像头1、摄像头2、摄像头3可对应于电子设备上的多个摄像头。
85.本技术实施例可以应用于电子设备中的app分享本地录制的视频的场景中，具体的，用户可通过电子设备的摄像头录制视频，录制完成后，视频将被存储于电子设备的图库中。
86.例如，在两个电子设备间通过app分享视频的场景中，以电子设备为手机为例，如图3a所示，在手机a安装的app的聊天界面，用户可选择照片按钮，进而手机会显示图库界面。用户在图库界面中选中需要分享的视频，点击发送按钮，则用户选中的视频被上传(upload)到第三方服务器，第三方服务器将该视频发送到手机b的app，即手机b的app从第三方服务器下载(download)该视频，该视频会被显示在手机b的app的聊天界面中，手机b的app可播放该视频。
87.再例如，如图3b所示，用户分享手机a图库中的视频时，可以在图库界面选中一个视频，图3b中右上角有对勾的视频为用户选中的视频。
88.然后用户选择分享按钮，跳转到分享界面，然后用户在分享界面选择一个app，比如微信，选择发送给朋友，从好友列表中选择一个好友，则会显示提示框，确认是否发送给选择的好友，若用户点击确认按钮，则用户选中的视频会被上传到第三方服务器，第三方服务器将该视频发送到手机b的app中，进而手机b的app可播放该视频。
89.第三方服务器为用于支持不同手机中的app通信的服务器，本技术实施例对第三方服务器不作限定。
90.需要说明的是，图3a和图3b中两个app间分享视频的过程仅是本技术实施例例举的一些可能的实现方式，本技术实施对此不作具体限定。
91.具体地，手机录制的视频会按照手机默认的编码格式保存在图库中，例如，使用安卓12系统的手机会将录制的视频保存为hevc格式。hevc格式为h.265标准下的视频编码格式。
92.如图4所示，当手机a中的app分享图库中的hevc视频时，比如在图3a中用户点击发送按钮时，或者在图3b中用户点击确认按钮时，会触发app分享该hevc视频。
93.媒体提供器接收到app分享hevc视频的操作后，可判断该app是否支持hevc格式。
94.如果支持，则向该app返回hevc视频；如果不支持，则判断该hevc视频的时长是否大于等于默认时长如60秒。
95.若大于等于默认时长，则向app返回hevc视频，即返回图库中的原视频；
96.若小于默认时长，则启动转码流程，将hevc视频转码为avc格式的视频，并向app返回avc格式的视频。
97.app获取视频后，将获取到的视频上传至第三方服务器，由第三方服务器将该视频发送给手机b中的app，即手机b的app从第三方服务器下载该视频，并播放视频。
98.在上述过程中，因转码是一项计算开销极大的操作，时长为60秒的hevc视频在谷歌智能手机(pixel)上需要大约20秒才能被转码为avc格式，在打开hevc视频时进行转码会产生延时。所以，目前只对小于默认转码时长如60秒的hevc视频进行转码。对于大于60秒的hevc视频，即使app不支持hevc格式，也不会对该hevc视频进行转码，因此会导致app无法打开并分享该hevc视频。默认转码时长是可更改的，若延长默认时长，将导致转码时间变长，进而导致app分享hevc视频存在较长的时延，严重影响用户体验。可见，不改变默认转码时长则仅仅允许转码一分钟之内的视频，而延长默认转码时长，必定严重影响用户体验，目前现有技术陷入两难问题。
99.为了解决上述问题，本技术实施例提供了一种视频分享方法，该方法可以应用于图1所示的电子设备，如图5所示，该方法包括：
100.s501、接收对目标视频的分享操作。
101.其中，电子设备中的内容解析器可接收该分享操作，该分享操作用于指示通过指定应用程序分享目标视频。
102.例如，在图3a中用户点击发送按钮时，或者在图3b中用户点击确认按钮时，均可以触发指定应用程序对目标视频的分享操作，本技术实施例对此不作具体限制。用户可以通过触摸屏幕、手势控制、语音控制等方式触发指定应用程序对目标视频的分享操作。
103.指定应用程序可以为电子设备中安装的除图库以外的第三方app，比如微信、邮箱等任意具有分享视频功能的app。
104.在接收到对目标视频的分享操作后，电子设备可以响应于分享操作，获取目标视频的预转码文件。
105.在一种实施方式中，电子设备可以在确定需要对目标视频进行转码的情况下，获取目标视频的预转码文件。也就是说，电子设备在获取目标视频的预转码文件之前，还可以执行s502。
106.s502、响应于分享操作，判断是否需要对目标视频进行转码。若是，则执行s503；若否，则执行s505。
107.其中，电子设备中的内容解析器接收到分享操作后，可向媒体提供器转发该分享操作，进而媒体提供器调用转码助手判断是否需要对目标视频进行转码。
108.判断是否需要对目标视频进行转码包括：判断指定应用程序是否支持第二格式，若支持，则判断目标视频的时长是否小于默认转码时长，若小于，则确定需要对目标视频进行转码，可进一步执行s503。其中，第二格式为电子设备的默认编码格式，例如hevc格式。
109.否则，若指定应用程序支持第二格式，或者目标视频的时长大于等于默认转码时长，则确定无需对目标视频进行转码，可进一步执行s505。
110.s503、获取目标视频的预转码文件。
111.其中，预转码文件为预先将目标视频转码为第一格式得到的文件，第一格式为指
定应用程序支持的格式。例如，第一格式为avc格式，avc格式为h.264标准下的视频编码格式。
112.s504、向指定应用程序发送目标视频的预转码文件。
113.可以理解的是，如果系统内存中已缓存有目标视频的预转码文件，则电子设备的媒体提供器可从系统缓存中获取该预转码文件，并发送给指定应用程序。
114.指定应用程序接收到预转码文件后，可向指定应用程序的其他账户分享预转码文件。
115.在执行s504后，该流程结束，无需继续执行s505。
116.s505、向指定应用程序发送目标视频。
117.在指定应用程序支持第二格式的情况下，媒体提供器可以向指定应用程序发送的目标视频，指定应用程序可以正常播放或者分享该第二格式的目标视频。
118.采用本技术实施例提供的方法，当接收到对目标视频的分享操作时，可判断是否需要对目标视频进行转码，在确定需要转码的情况下，因目标视频已被预先转码为指定应用程序支持的格式，所以可以直接获取目标视频的预转码文件，并发送给指定应用程序，那么指定应用程序此时就无需等待电子设备对目标视频进行转码，可以减少等待时间。相比于在接收到分享操作后再进行转码，本技术实施例可以降低指定应用程序分享目标视频的时延，提高用户体验。
119.在一种实施方式中，本技术实施例中的默认转码时长可以与现有技术中的默认转码时长相同，例如本技术实施例中的默认转码时长也可以小于1分钟，因本技术实施例中可以预先对目标视频进行转码，在分享视频时无需等待对目标视频进行转码，可以减少20秒左右的等待时间，可以降低分享视频的时延。
120.另一种实施方式中，本技术实施例中的默认转码时长还可以远大于现有技术中的默认转码时长，比如，本技术实施例中的默认转码时长可以为2分钟。
121.因本技术实施例中可以对目标视频进行预转码，预转码的时间延长不会对分享目标视频的过程产生影响。即使把默认转码时长设置为2分钟，那么大概需要40秒的预转码时间，后续当app需要分享视频时，可以直接为app提供预转码文件，在分享过程中无需等待40秒的转码时间，解决了现有技术中延长默认转码时长会严重影响用户体验，不延长默认转码时长会导致无法对大于1分钟的视频转码的两难问题。也就是说本技术实施例实现了在不影响用户体验的前提下，延长默认转码时长，使得app可以分享时长更长的视频。
122.为了实现图5所示的实施例，需要预先对目标视频进行预转码，以下对预转码的方法进行说明。
123.在一种实施方式中，电子设备可以接收对目标视频的收藏操作，响应于该收藏操作，如果确定目标视频满足预转码条件，则将目标视频由第二格式转码为第一格式，得到预转码文件。
124.如图6所示，用户可以选择图库中的视频，当用户点击收藏按钮时，即触发了对视频的收藏操作。其中，用户还可以通过长按、语音控制等方式选择收藏选项，本技术实施例对此不作具体限定。
125.需要说明的是，图6仅为收藏界面的一种示例，本技术实施例对此不作具体限制。
126.上述预转码条件为目标视频的编码格式为第二格式，且所述目标视频的时长小于
默认转码时长。默认转码时长可按照实际需求设置，作为示例，默认转码时长可以为两分钟。
127.如图7所示，假设目标视频的编码格式是第二格式，当识别到用户点击目标视频的收藏按钮时，可判断目标视频的时长是否超出默认转码时长。
128.若是，则不对目标视频进行预转码；若否，则启动对目标视频的预转码，将目标视频由第二格式转码为第一格式，得到预转码文件。
129.在得到预转码文件后，可将目标视频的视频信息加入预转码队列，并将目标视频的预转码文件缓存于系统内存。
130.其中，预转码队列的长度可以根据实际需求设置，例如长度可以为10，即预转码队列包括10个队列元素，在本技术实施例中，队列元素用于存储视频信息。
131.该预转码队列满足先进先出原则，当某一队列元素移动到队头时，在预转码队列已满的情况下，若再加入一个视频信息，则将队头的队列元素进行出队处理，其他的队列元素都向队头方向移动一个位置，进而新加入的视频信息可以被存储于队尾。
132.其中，出队处理是指从预转码队列中删除队列元素。
133.可选地，预转码队列中的队列元素可以为字典对，也可称为键值对，即key-value的格式，key为视频的身份标识(identity，id)，value用于表示视频是否已被分享。value具体可以为一个标记位，该标记位的值可以为第一标记值或第二标记值，第一标记值表示视频已被分享，第二标记值表示视频未被分享。例如，第一标记值为1，第二标记值为0。
134.参见图7，如果预转码队列当前为空，则目标视频的视频信息被加入预转码队列的队头。作为示例，此时目标视频的视频信息为[120:0]，代表目标视频的id为120，当前目标视频未被分享。
[0135]
后续入队的视频信息均排列在该目标视频的视频信息之后。
[0136]
如果在图5的流程中执行了上述s504，则说明目标视频的预转码文件已被分享，在执行s504的同时，或者在执行s504之后，将预转码队列中目标视频的视频信息修改为[120:1]，从而通过视频信息指示该目标视频的预转码文件已被分享。
[0137]
当预转码队列已满，再有其他视频信息需要加入预转码队列时，对目标视频的视频信息进行出队处理。
[0138]
在对目标视频的视频信息进行出队处理时，如果该视频信息的value为1，则保留已缓存的该目标视频对应的预转码文件；如果该视频信息的value为0，则将已缓存的该目标视频对应的预转码文件删除。
[0139]
采用该方法，当用户收藏hevc格式的视频时，就可以触发电子设备对视频进行预转码，并缓存预转码文件。进而，后续如果接收到app对hevc视频的分享操作，如果该app不支持hevc格式，则可为app提供预转码文件，减少app分享视频的时延。
[0140]
此外，因本技术实施例将已预转码视频的视频信息存储于预转码队列中，在对视频信息进行出队处理时，如果根据视频信息确定视频未被分享，说明该视频的预转码文件后续被分享的可能性也比较小，则将该视频的预转码文件删除，可以防止因缓存过多预转码文件而增大系统内存开销。反之，如果根据视频信息确定视频已被分享，说明该视频还可能再次被分享，所以可以保留该视频的预转码文件，进而可以提高下一次的分享速度，避免重新对视频转码产生的系统处理开销和时延。
[0141]
在本技术实施例的另一种实施方式中，目标视频的视频信息可以只包括视频id，即在将目标视频由第二格式转码为第一格式，得到预转码文件后，可以将预转码文件缓存于系统内存，并将目标视频的id加入预转码队列。
[0142]
当按照先进先出原则需要对目标视频的视频信息进行出队处理时，则将目标视频的id从预转码队列中删除，并将目标视频的预转码文件从系统缓存中删除。
[0143]
采用该方法，在目标视频的id处于预转码队列的时间段内，如果不支持hevc格式的app需要分享目标视频，则可以为app提供目标视频的预转码文件，那么在app分享视频时，就无需等待电子设备对目标视频进行转码，减少了等待时间，进而可以降低app的分享时延，提升用户体验。且在目标视频的id出队时，及时删除目标视频的预转码文件，可以避免目标视频的预转码文件长时间占用系统内存，节省内存资源。
[0144]
在本技术另一实施例中，对图7中启动对目标视频的预转码，将目标视频由第二格式转码为第一格式，得到预转码文件的过程进行介绍。
[0145]
预转码的流程如图8所示，当启动预转码时，转码助手可以向媒体转码管理器(mediatranscodemanager)发送队列请求(enqueuerequest)，即调用媒体转码管理器对目标视频进行预转码。
[0146]
媒体转码管理器通知视频轨道转码器(videotracktranscoder)启动(start)对目标视频的转码。
[0147]
视频轨道转码器通过媒体编解码器(mediacodec)对目标视频进行硬件解码，再由将硬件解码得到的数据编码为第一格式，从而得到目标视频的预转码文件。
[0148]
然后，媒体编解码将预转码文件返回给视频轨道转码器，视频轨道转码器将预转码文件返回给媒体转码管理器，完成对目标视频的转码。
[0149]
在一种可能的场景中，在指定应用程序分享目标视频时，存在两种情况系统内存中不存在目标视频的预转码文件。
[0150]
第一种为目标视频未被收藏，那么该目标视频未被预转码，系统内存中就不存在目标视频的预转码文件。
[0151]
第二种为目标视频曾经被收藏，但是目标视频的视频信息已从预转码队列中出队，相应地目标视频的预转码文件已被从系统内存中删除。
[0152]
考虑到上述两种情况，本技术实施例还提供另一种视频分享方法，该方法应用于图1所示的电子设备，如图9所示，该方法包括：
[0153]
s901、接收对目标视频的分享操作。
[0154]
其中，该分享操作用于指示通过指定应用程序分享目标视频。
[0155]
s902、响应于分享操作，判断是否需要对目标视频进行转码。
[0156]
若是，则执行s903；若否，则执行s906。
[0157]
其中，s901-s902与上述s501-s502相同，可参考上述s501-s502中的相关描述，此处不再赘述。
[0158]
s903、判断是否存在目标视频的预转码文件。
[0159]
若是，则执行s904；若否，则执行s905。
[0160]
电子设备中的多媒体内容提供者确定需要对目标视频进行转码后，可获取目标视频的文件描述符，进而以该文件描述符为索引从系统内存中查找目标视频的预转码文件，
如果查找到，说明系统内存中存在目标视频的预转码文件，进而执行s904。
[0161]
如果未从系统内存中查找到目标视频的预转码文件，说明系统内存中不存在目标视频的预转码文件，进而执行s905。
[0162]
s904、向指定应用程序发送目标视频的预转码文件。
[0163]
可以理解的是，如果系统内存中已缓存有目标视频的预转码文件，则电子设备的媒体提供器可从系统缓存中获取该预转码文件，并发送给指定应用程序。
[0164]
指定应用程序接收到预转码文件后，可向指定应用程序的其他账户分享预转码文件。
[0165]
在执行s904后，该流程结束，无需继续执行s905。
[0166]
s905、将目标视频转码为第一格式，并向指定应用程序发送目标视频的转码文件。
[0167]
在系统内存中不存在目标视频的预转码文件的情况下，媒体提供器可调用转码助手对目标视频进行转码，具体的转码过程可参考图8对应的实施例中的相关描述。
[0168]
s906、向指定应用程序发送目标视频。
[0169]
本技术实施例中，如果不需要对目标视频进行转码，则可直接向应用程序发送目标视频的原文件。
[0170]
采用该方法，当接收到对目标视频的分享操作时，在确定需要对目标视频进行转码的情况下，还需进一步判断是否存在目标视频的预转码文件，若存在，则向指定应用程序发送目标视频的预转码文件，那么指定应用程序就无需等待电子设备对目标视频进行转码，减少了等待时间，可以降低指定应用程序分享目标视频的时延；若不存在，也可以及时对目标视频进行转码，因大部分需要分享的视频已预转码，所以对少量视频进行实时转码不会造成计算开销过大，可以提高指定应用程序获取转码后的视频的效率，进而加快分享速度，提高用户体验。
[0171]
如图10所示，图10为当app需要分享视频时，手机内部软件的调用时序图。
[0172]
其中，图10中的app位于图2的应用层，图10中的其他模块位于图2的框架层。
[0173]
参见图10，该方法具体包括以下步骤：
[0174]
s1001、app向内容解析器发送视频获取请求。
[0175]
其中，当app接收到用户对图库中的视频的分享操作时，app需先获取视频，所以app可以通过opentypedassetfile函数向内容解析器发送视频获取请求。
[0176]
s1002、内容解析器向媒体提供器转发视频获取请求。
[0177]
其中，内容解析器可以通过opentypedassetfile函数向媒体提供器转发视频获取请求。
[0178]
s1003、媒体提供器查找视频文件。
[0179]
其中，媒体提供器可以从系统内存中查找视频文件，并获取视频文件的文件描述符。
[0180]
s1004、媒体提供器调用转码助手判断是否需要对视频进行转码。
[0181]
媒体提供器可以通过shouldtranscode函数触发转码助手判断是否需要对视频进行转码。
[0182]
转码助手可通过s1005-s1007判断是否需要对视频进行转码。
[0183]
s1005、转码助手判断手机是否允许转码。
[0184]
具体有以下两个判断条件：1.sdklevel.isatleasts，即手机的版本至少为谷歌系统的s版本，低于s版本的手机不具有将hevc格式视频转码为avc格式的能力。
[0185]
2.“persist sys.fuse.transcode_enable”以及“transcode_enable”，即手机中的转码开关都是使能状态。
[0186]
在满足以上两个判断条件的基础上，可确定手机允许转码；若不满足任意一个条件，则确定手机不允许转码，进而确定无需对视频进行转码。
[0187]
s1006、转码助手判断视频是否在支持转码的存储路径下。
[0188]
其中，支持转码的存储路径为“dcim/camera/*”，如果视频被存储在该路径中，则确定支持对该视频进行转码，否则确定不支持对该视频进行转码，进而确定无需对视频进行转码。
[0189]
s1007、转码助手判断该视频是否需要被转码。
[0190]
转码助手可以获取app的应用媒体功能(applicatipnmediacapabilities)，从中获取app支持的视频格式。并且，转码助手还可以获取app所请求获取的视频的编码格式。
[0191]
如果该视频的编码格式为app系统支持的视频格式，则该视频不需要被转码；如果该视频的编码格式为app系统不支持的格式，则该视频需要被转码。
[0192]
示例性地，如果app支持的视频格式和视频的编码格式均为hevc或者均为avc，则该视频不需要被转码。
[0193]
如果app支持的视频格式为avc，该视频的编码格式为hevc，则该视频需要被转码。
[0194]
s1008、媒体提供器确定需要对视频进行转码后，从用户空间文件系统打开该视频。
[0195]
媒体提供器可基于s1003中获取的文件描述符，通过openwithfuse函数从用户空间文件系统打开该视频。
[0196]
s1009、用户空间守护进程触发媒体提供器对视频进行转码。
[0197]
用户空间守护进程通过transformforfuse函数触发媒体提供器对用户空间文件系统中的视频进行转码。
[0198]
s1010、媒体提供器判断该视频的转码缓存是否存在。
[0199]
在本技术实施例中，如果已经对该视频进行预转码，则媒体提供器可确定该视频的转码缓存已存在，该视频的转码缓存为上述实施例中描述的预转码文件。
[0200]
如果该视频的转码缓存存在，则媒体提供器可该转码缓存发送给内容解析器，内容解析器将该转码缓存发送给app，进而app可分享该视频。
[0201]
如果该视频的转码缓存不存在，则执行s1011。
[0202]
s1011、媒体提供器调用转码助手对视频进行转码。
[0203]
s1012、转码助手向媒体转码管理器发送对该视频进行转码的队列请求。
[0204]
s1013、媒体转码管理器启动(start)视频轨道转码器对该视频进行转码。
[0205]
后续过程可参考图8实施例中的相关描述。
[0206]
采用该方法，因可以对已收藏的视频进行预转码，并缓存预转码文件，所以在接收到app发送的获取视频请求后，后续媒体提供器可从系统内存中获取预转码文件，也就无需对视频进行转码，可以为app提供已缓存的预转码文件。如此app就无需等待媒体提供器调用转码助手对视频进行转码，app可以更快地获取到视频，降低分享时延。
[0207]
具体实现中，本技术还提供一种计算机存储介质，其中，该计算机存储介质可存储有程序，其中，在所述程序运行时控制所述计算机可读存储介质所在设备执行上述实施例中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体(英文：read-only memory，简称：rom)或随机存储记忆体(英文：random access memory，简称：ram)等。
[0208]
具体实现中，本技术实施例还提供了一种计算机程序产品，所述计算机程序产品包含可执行指令，当所述可执行指令在计算机上执行时，使得计算机执行上述方法实施例中的部分或全部步骤。
[0209]
本技术公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本技术的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。
[0210]
可将程序代码应用于输入指令，以执行本技术描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本技术的目的，处理系统包括具有诸如例如数字信号处理器(digital signal processor，dsp)、微控制器、专用集成电路(application specific integrated circuit，asic)或微处理器之类的处理器的任何系统。
[0211]
程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本技术中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。
[0212]
在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、光盘只读存储器(compact disc read only memory，cd-roms)、磁光盘、只读存储器(read only memory，rom)、随机存取存储器(ram)、可擦除可编程只读存储器(erasable programmable read only memory，eprom)、电可擦除可编程只读存储器(electrically erasable programmable read only memory，eeprom)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如，计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。
[0213]
在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明书附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。
[0214]
需要说明的是，本技术各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方
式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本技术所提出的技术问题的关键。此外，为了突出本技术的创新部分，本技术上述各设备实施例并没有将与解决本技术所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。
[0215]
需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0216]
虽然通过参照本技术的某些优选实施例，已经对本技术进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。