当前位置: 首页 > article >正文

音视频技术在手机上的应用与挑战

  //  

编者按:随着手机相机功能日益强大,4k,8k,各类特色短视频的拍摄,编辑、播放需求日益增长,短视频应用的火爆也对当前的手机音视频技术提出了更高的要求,如何更好地提高用户体验成为了行业共同的命题。LiveVideoStackCon 2023 上海站邀请了小米的吴昊,从一名开发者的角度为大家分享他关于手机端音视频技术的一些思考与经验。

文/吴昊

整理/LiveVideoStack

大家好,本次我将从手机厂商音视频SDK开发的角度和大家分享工作中我总结的一些经验,也虚心接收更好的建议。

1c7c40462e9968eca90b27b9aa93c735.png

目前我们的主要工作是开发小米内部自用的多媒体组件,它支持小米天气、相册、文管、短信、视频的业务领域涉及的本地播放、网络播放、音乐播放、图片浏览、视频编辑和新场景探索等功能。

b9185acf9491c47eced32e438b96c8b9.png

本次分享将分为五部分:一是从厂商角度介绍对手机音视频现状的理解;二是分享对平衡体验和资源占用的一些工作经验;三是基于网络播放场景列举具体的优化实例;四是介绍我日常使用的开源资源;最后进行一些未来展望。

-01-

手机音视频现状

01c44ce6a70d59e89e845d027a616d25.png

提起手机音视频,大家的第一印象可能是上面列举的抖音、快手、爱奇艺和小米视频等在线视频平台,其中我们的小米视频是一个聚合平台,用户可以通过它观看各大流媒体平台的视频资源。

f85245eea12cf3fbb3de6f56de701e8d.png

而手机厂商在此基础上还需重点关注本地视频播放应用的开发和优化。如上图所示,我们对小米手机的相册应用丰富了各种各样的功能,如视频变速播放、编辑、图片Seekbar浏览等。

此外,近年来各大厂商对手机影像的内卷之势也愈演愈烈,为了充分发挥硬件实力也在不断加强相机应用的各种功能。

80586f4ebdf8ebeef21e66d2de654d5c.png

我个人认为,当前的手机音视频应用具备以上几个特点:第一是便携性,这有助于提高用户粘度;第二是多功能性,除了单纯的播放功能外还要具备各种剪辑编辑相关的能力;第三是高清晰度,这是当今用户的基本需求;第四是实时性,保证用户可以随时随地使用;社交性和互动性可以为微信等社交应用提供服务。

-02-

性能与体验

5682cb6aa801f63726b668e871a7bc9d.png

接下来分享我个人对平衡体验和资源占用的一些优化经验。在此之前首先向大家推荐小米公司的官方应用小米社区。我们的产品经理和研发会不时参与社区讨论,并从社区话题中选取大家感兴趣的新功能进行立项研发,欢迎小米用户们积极发表自己的想法和建议。

2d1d780c82c58143fd1978b3bb9e06fc.png

依据自网络和小米社区的调研结论,我们发现对于音视频应用。用户主要关注以上几点特性:一是满足用户的画质需求;二是需要支持各种不同的视频格式;三是除播放外应具备更多的功能(如视频编辑等);四是要保证播放的流畅度;五是要提高应用稳定性;六是要尽可能节约设备电量。

b10ab9f07ebdc5f757ffbb5a295e1d2d.png

通过分析提炼用户需求,我们在技术上将其转换为具体的优化方案。

3935614c70000082b85d20e118013cc5.png

我们认为可以从以上六个方面来展开优化。

86be3be5a75237c1a0b48bb0997bbb94.png

首先,控制包体积有效缩短了APK的下载时间,使用户可以更快地安装应用程序;其次是有利于节约手机设备的存储空间;第三是更小的APK启动速度更快,应用程序响应更迅速,提高了用户体验;最后,压缩APK体积减轻了传输时占用的网络带宽,节约了厂商的网络和存储成本。

3bb1b98a463068e96202bfdae9c17e3e.png

以上是我总结的几项优化方案:一是精简动态库符号表;二是去除无用代码,依据场景需求优化调用逻辑,减少代码调用层级;三是对FFmpeg进行定制化编译。

388e137f2696f647624353d61639db81.png

内存占用优化一是可以有效控制因应用占用内存大,内存堆积溢出导致的OOM,或是容易被系统清理的问题;二是减少频繁GarbageCollection (GC)导致的应用卡顿、掉帧现象;三是从手机厂商角度需尽量避免原生应用内存占用大,变相挤压第三方应用运行环境。

91c373edbc5f8d6a6cc54699dac0f142.png

针对安卓平台,首先可以使用Android studio、dumpsys或meminfo等工具对应用进行内存占用分析,明确大内存分配的代码并评估必要性,为后续优化提供决策依据;

二是减少频繁内存创建销毁,借助jemalloc等内存分配器,可以实现对一些重复对象的复用;

三是减少数据的拷贝流转。

bb1e1cd070d8437abd1e813c627f5ffb.png

作为手机厂商,应用功耗是我们高度关注的一项指标,控制功耗首先有利于减少手机的充电次数,延长电池寿命;其次可以减少手机发热,降低硬件损耗;三是发热更少可以避免手机CPU频繁降频,有利于提高设备的整体性能和相应速度。

c5e919bee28ce07bf5aaed4781e37940.png

控制功耗首先可以在不影响应用运行的前提下尽量降低网络访问频率;第二要充分考虑VPU、CPU和GPU的特性,合理分配硬件资源;第三要做好无用线程的排查;第四是可以依据实际情况将显示模式切换为surfaceview。

c595ba0cbdb410d73dc905a8cdca2000.png

从优化SDK网络播放的角度,提升流畅性可以采取以下措施:

一是做好视频文件的数据调整,如注意mp4文件moov box的排列顺序等;

二是可以采用数据预缓存;三是采用视频预渲染;四是优先考虑硬解。

4e781639b53a22a333a0d120f7a3b842.png

提升应用稳定性首先可以在平时的工作中保证随时自动化测试的条件,提高效率;二是要重视预防和监控,可以成立一些代码评审监控机制;三是针对发现的问题要做好举一反三。

1a782c5f0f2ec115e832a9b7d6a73c01.png

丰富应用的特色功能是维持用户粘度的关键。做好这点首先要注意多和业务相关的各方交流讨论,广开思路;二是要及时关注其他平台的特色功能,并考虑手机应用场景及实现技术,研究移植的可行性;三是从自身角度努力提升技术实力,多关注新兴技术,与时俱进。

-03-

场景案例

0ebed5394afeb8b165f280d0129a5b62.png

接下来介绍一个基于网络播放场景的优化案例。在该案例中,业务方对网络播放的起播速度提出了更高要求。

由于向业务方最初提供的SDK集成了在线、本地视频播放和视频编辑等功能,本身体积过重,优化空间有限,因而我们决定基于纯网络播放推出专门的播放器内核,提高起播速度。

15fdf7dd205143448d372b8cfd609ee4.png

各位开发者在规划优化方案前要注意做好调研,与产品方做好沟通,明确具体优化需求,本次该案例从业务方角度提出的需求包括起播速度快、SDK体积小、快速切换和内存小四项。

从开发者角度,为了便于后续成果复用,响应用户可能提出的额外需求,有必要对SDK接口的简单化和可拓展性做出考虑。

df282d9c35f5265dd90dd12c0ff767b9.png

基于以上需求我们进行了架构选型调研。综合考虑开发时间,适配难度,后期维护以及成果复用的最大化,最终决定基于原有播放器框架进行精简及模块化,并就稳定性及起播耗时等核心指标进行专项开发。

54213e31c7d3c85cfaad9af62f5f407a.png

我们从以上几方面着手压缩SDK体积。首先是分离原播放器中与网络播放场景无关的功能;其次是有针对性的选取满足用户需求的网络协议、封装格式和编码格式;最后是针对网络播放场景简化原有判断逻辑。

0a955cd52e3323a875b548480dc723f8.png

播放器架构优化前后的对比如上所示。

600036a80b7886969c306dcb7facae70.png

在该案例基础上,我们正在考虑将原有体积重,集成各种功能的播放器SDK解耦为功能池,后续依据不同用户的场景需求进行针对性的架构定制。

970402e71a0fadf3958c3c97c81ba4ab.png

对优化内存占用我们采取了以上措施:一是通过内存分析找到高占用的代码,进行针对性优化;二是进行缓存区优化,如自定义内存管理、进行缓存区调优等;三是针对Android平台采用MediaCodec直接送显;最后是将显示模式切换为surfaceview。

a850d70a9f8465f7ddb54e986a330d32.png

在该案例中,缩短起播时间是业务方的核心需求。我们对不同起播时间给用户带来的感受进行了分析,结论如上表所示。

视频起播从SDK开始到显示播放需经历以上五个阶段,我们在各个阶段采用了一些相对简单的优化策略。

82fbbe79af42ee3d7abb44a50a4ddbeb.png

首先在申请url地址阶段,可以在部分场景下提前获取视频url;在DNS解析阶段,可以酌情考虑采用host缓存,缩短解析时间;在连接服务器阶段,可以考虑进行服务端调优;在数据缓存阶段,可以提前缓存部分数据;在解码显示阶段可以选用支持快速解码的解码器。

4acb7462df969b24d2ba7850a138c09c.png

针对手机侧优化我们采用了以上方案。

4c8f6af540b21da7d2112fbb9b994a31.png

经过测试,我们在该案例中选择预缓存待播视频的开头1到2秒,大家在实际工作中可以结合场景需求自行调整需要缓存的时长。

8917a09f4ad0add37de639c636998228.png

通过复用提前缓存时分配的缓冲区buffer,可以有效降低起播缓存区的水位线,提高抗网络抖动能力。

3e388e1602b42530f0c426edf1198566.png

针对快速切换播放多个视频的场景可以采用播放器多实例方案。在前一个视频播放时,提前创建另一个播放器加载下一个视频,后续以此类推。

4308d46a7f3abdb183bef19c402b7afe.png

鉴于精确seek受网络条件影响可能会拖慢画面送显,我们会基于用户主观体验设置时间阈值(该案例下为900ms),如果精确seek所需时间超出该值则先送显该时点下能够解码的画面,避免长时间黑屏等待。

0a234829d09c9bb7b8925c6c982fdecc.png

换个角度考虑,针对相同问题,从资源侧进行优化有时效果要胜于SDK侧方案。

d29fb94580f94fa28b492b0d47c5461b.png

在验证优化可行性时,我使用apache2搭设了自有服务器辅助测试,其中上图右侧展示了设置网速限制的过程。

ba2a8f43eb77f8f8c7f662976c313c29.png

我发现在预缓存请求网络MP4时,会出现MP4文件头和文件尾来回请求的情况,这增加了播放耗时。

216e52110d853b5950526765d91e3488.png

这实际上是包含视频索引信息的moov在MP4文件中后置导致的。

在使用FFmpeg将其改为前置后,缓存机制可正常生效,短视频起播明显加快。

1b241fe5203030e6a9b91bd51a9a92de.png

调整moov位置后的MP4文件box tree如上图所示。

be99a576797f50d7574a490d0d51f682.png

moov会随着视频时长的增加而变大,例如上图中两小时左右的视频moov体量达到了约4MB。由于播放前需全部下载,导致起播速度仍然较慢。

9c6f402b60b747dc9a802625879d3d1f.png

为了缩短长视频起播时间,我考虑将mp4改为ts流,使播放器可以从视频流的任一片段独立解码,但导致seek的速度较慢。

通过改为使用HLS流,使起播和seek速度都获得了大幅提升。

cceb95e1c1e75331061732e36e1c51cc.png

综上,代码优化需要我们明确需求、逐项拆解从而精准施策。

同时要注意与各方形成合力,从多角度进行分析,还要考虑代码的模块化。

-04-

开源资源

785c960ee6e03f06642fb655886d4a16.png

接下来介绍几个我日常较多使用的音视频开源软件。

bb3ea97708d06898c9b863c677d279c1.png

Mp4box是一个可以在线解析、查看MP4 box结构的工具。

cde6401555ebf352a4db6714a064f1c4.png

Bento4是一款用于读写MP4文件的专业开源库。

0f567e2065a8bbb1bf233e706ebf5baf.png

YUView是我个人强烈推荐的一款码流分析软件,它支持带封装视频解析和显示、支持H.264/H.265/H.266/AV1裸码流解析和显示。

7dbbf95620f46d3ded2abf238cab95a0.png

它支持查看H.265流的详细码流分析信息,包括Slice个数、CU划分、CU模式类别、参考帧索引、运动矢量等等。

0246ea66bdeadde3f2935bb1c8b7e15b.png

它支持对比两段视频。

78b725069ede914d3a3e89c24a4f75a7.png

它支持类似mediainfo的媒体信息显示。

80b41cb5161b14f1aeb8b65089fdee54.png

它支持各种媒体编码信息查询。

f77089a70448bcc29526f8725586d8a2.png

它支持查看码流变化曲线。

d871d5e2c7bb687e8fff1bd0ab807332.png

biTStream由一系列C语言的头文件组成,它是在MIT许可证下发布的,可以辅助进行代码字节和结构解析。

-05-

未来展望

2b6b21078a39cfaf0cff9302d71878fa.png

最后从个人角度分享一些未来展望。一是随着AR/VR技术的不断发展,未来音视频可能会更加注重增强现实和虚拟现实的体验;二是5G技术的到来会加快音视频的传输速度,为应用创新带来更多可能性;三是AI技术的发展将为音视频应用带来更多可能。

我今天的分享就到这里,谢谢大家!


7天倒计时!深圳站大会亮点前瞻!

8c8ebe6459fd1f59aba0c5087cca33ff.png


http://www.kler.cn/a/134304.html

相关文章:

  • C 语言 【模拟实现内存库函数】
  • 申论1_概括、分析
  • Jmeter基础篇(22)服务器性能监测工具Nmon的使用
  • request爬虫库的小坑
  • 并发基础:(淘宝笔试题)三个线程分别打印 A,B,C,要求这三个线程一起运行,打印 n 次,输出形如“ABCABCABC....”的字符串【举一反三】
  • 【go从零单排】Timer、Epoch 时间函数
  • GPT-4要点内容记录
  • 迪克森电荷泵
  • 网络割接用VRRP替换HSRP
  • 二叉树oj题集(LeetCode)
  • vnodeToString函数把vnode转为string(innerhtml)
  • Rust动态数组Vec
  • Linux调试器---gdb的使用
  • Spark 平障录
  • c++中的特殊类设计
  • Linux——编译器gcc/g++、调试器gdb以及自动化构建工具makefilemake详解
  • 【数据库表及字段统计SQL】【mysql】【clickhouse】【oracle】
  • AIGC之Stable Diffusion
  • YOLOv8优化策略:轻量级Backbone改进 | VanillaNet极简神经网络模型 | 华为诺亚2023
  • Linux系统编程 day02 vim、gcc、库的制作与使用
  • 龙芯 Loongson 架构 UOS 系统编译 Qt 5.15.2 源码
  • boomYouth
  • 2023.11.18html中如何使用input/button进行网页跳转
  • GIT无效的源路径/URL
  • SOME/IP 协议介绍(五)指南
  • 基于灰狼算法(GWO)优化的VMD参数(GWO-VMD)