专栏首页腾讯大讲堂的专栏秒开率达90%:腾讯看点客户端 GIF 转视频优化方案

秒开率达90%:腾讯看点客户端 GIF 转视频优化方案

导语 |众所周知,在动图场景中, GIF 一直是应用得最广泛的技术,然而 GIF 文件体积太大的劣势,导致了一些诸如客户端 GIF 加载慢、服务器占用带宽大等问题。那么,在 GIF 占比如此高的今天,有没有一些更合适的动图格式,既能减小文件体积和服务器带宽,又能在客户端有不俗的性能表现?本文将介绍信息流场景下一套 GIF 体验提升的通用解决方案,该方案已经在腾讯看点内短内容场景中落地。

问题背景

看点短内容是看点信息流的重要内容,短内容有些类似微博段子,内容大多以娱乐、搞笑为主,因此有大量的 GIF 动图。我们发现在一些网络较差的情况下,GIF 动图加载极慢,有些甚至达到了 10+s 之久(如下视频所示)。另一方面,信息流动图使用场景密集,大量的GIF图下载导致带宽成本增加。面对体验和成本问题,我们开始预研和寻找优化方案。

为了方便对比动图优化前后的效果,我们首先对 GIF 做了相关数据上报,主要包括 GIF 文件体积以及加载耗时。在大盘数据中,我们的统计数据结果如下:

从以上数据得知,有超过一半的 GIF 文件体积超过了 1M,有大约一半的 GIF 耗时超过了1s ,长尾部分的用户等待时间长达数十秒,在弱网状态下情况变得很糟糕,可见这其中还有许多优化空间。从客户端的角度,如果仅仅是为了减少用户等待动图加载的时间,其实可以使用一些常规的手法,比如预加载等,但是为了节省网络带宽,我们可以直接替换成另一种动图格式来进行优化。最终,我们采用了 GIF 转 MP4 视频的技术方案,方案架构图如下所示,后台在 GIF 入库时会预先将 GIF 转化成 MP4 视频,并生成视频 vid,后台将视频 vid 下发到客户端后,客户端根据视频 vid 向内容中心请求视频链接,获取到视频链接后在客户端进行播放:

动图技术方案

当前的动图技术除了 GIF 外,常用的技术方案有以下几种:

APNG

APNG(Animated Portable Network Graphics)是一种基于 PNG 的拓展动图格式,不同于 GIF 只有 1 位透明通道,APNG 动图格式支持 8 位透明通道,所以 APNG 动图会有更好的质量。APNG 采用 Deflate 算法,另外由于继承 PNG 的 filter,利用相邻像素的近似性使得压缩率大大提高。但是,由于 APNG 未得到 PNG 开发组织的支持(PNG 有自己的亲儿子 MPNG,奈何亲儿子不争气),APNG 在浏览器方面兼容较差,一开始仅得到 Mozila FireFox 的兼容支持,因此没有流行起来。

WebP

WebP 由 Google 主导开发,是一种同时提供了有损压缩与无损压缩的图片文件格式,派生自影像编码格式 PV8,自从谷歌在 2010 年推出以来,应用得越来越广泛。它同时也支持动图(Animated Webp),国内一些 APP 比如抖音在某些场景中就是用 WebP替代了 GIF。

SharpP

SharpP 是公司自主研发的一种图片格式,它基于HEVC 视频压缩编码标准开发,并且已经广泛运用于公司内众多产品(腾讯新闻、空间相册、天天快报等),并支持 Windows、Linux、Android、iOS 四大平台,而且已经移植在 X5 浏览器内核中。

MP4 视频

Facebook 早在2014年就尝试将 GIF 转成 MP4,这帮助他们节省了大量带宽,如下是 Twitter 中的 GIF 动图的展示,实际上这些是一个个 MP4 视频,用户体验非常好:

方案对比

根据相关文章的评测数据,WebP、H264、HEVC 和 SharpP 的压缩率对比如下:

我们自己选取了一张 GIF 图片转换成APNG、WebP(85 质量)、SharpP(两个等级) 和 MP4(H264、H265)四种格式,得到下面的数据:

我们可以看到在压缩率方面,APNG 和 WebP 的压缩率均远低于 SharpP 和 MP4,而且是差距比较大。另外我们还研究了今日头条、微博、Twitter 以及 天天快报这几个 APP 中类似的 GIF 场景,得到的结论如下表所示:

APP

动图方案

弱网表现

头条

GIF

较差

微博

大图动图使用H.264 视频,多图动图 沿用 GIF 格式

较好

Twitter

只有大图动图,使用H.264 视频

较好

天天快报

SharpP

较好

可见,GIF 转视频是业界比较通用的解决方案,在某些场景下(例如大图 GIF),使用视频替代 GIF 是一个不错的选择。在公司开发的几款产品(天天快报、QQ 浏览器、腾讯新闻)中,SharpP 动图也是应用得比较广泛的动图格式。考虑到文件压缩比,我们将在 SharpP 和 MP4 之间选择动图方案。接下来我们比较两种方案哪种更适合我们的场景。

在 CPU 占用方面,选择一张 GIF 动图转化成 SharpP 和 MP4,并使用 Android Studio 查看两者在播放时的 CPU 占用率,如下图所示,上图为 SharpP,下图为 MP4:

从上面两张图的对比中可以看出,SharpP 整体比较稳定,大概占比在7%到9%之间,而 MP4 在一开始会有个小高峰,随后立马下降。MP4 的这个小高峰实际上是打开链接时产生的消耗,这个过程只会在动图播放时产生一次。因此,在 Android 上两者的 CPU 占比是十分接近的。

SharpP 和视频其他方面的对比如下表:

SharpP

H264

H265

编码速度比

10

3

140

透明通道支持

支持

不支持

不支持

通用性

第三方平台(浏览器等)不兼容

通用

通用

硬解支持

不支持

基本支持

部分机型不支持

可以看到,视频在通用性和硬解支持相对于 SharpP 有优势,另外视频还支持边下边播,可以帮助我们快速出图,加上官方本身缺乏对 SharpP 动图组件的支持,所有的下载和解码需要我们进行开发,开发成本比视频大。此外,视频也很适合我们的场景,因此,我们最终选择了视频作为我们的解决方案。

优化效果

使用视频替代 GIF 的方案在弱网的表现优化效果如下视频所示,可以看到经过优化,动图体验好了很多,基本属于秒开级别:

该方案上线后,我们统计了大盘数据,优化后取得的效果如下图所示,文件大小减小了62%,秒开率(1s 内打开动图的比例)从 50%提高到了 90%,用户等待时间减少了75%:

另外,通过 ABTest,该技术方案有效拉动了业务指标的增长,短内容有效曝光增长约5.62%,极大地提升了短内容的转化效率,如下图所示:

不过,并不是所有的 GIF 场景都适合转化成视频,由于视频在 CPU 上的消耗比 GIF 文件要多,在其他场景比如页面中同时存在多个 GIF 时,非视频的动图格式(比如 GIF、WebP)还是更优的方案。

总结

为了能让这个方案更加通用化,我们的目的是针对信息流搭建一套适用于信息流的动图组件,支持 GIF 和视频动图,并提供多种播放策略控制能力(比如在动图滑出屏幕外、切后台等不可见场景时默认不播放,滑入屏幕内再开始播放)、底层换链能力(兼容不同业务的换链方案)等。

根据上线后的效果来看,GIF 转视频带来的收益不仅包含了网络带宽的节省,用户等待 GIF 加载时长的减少等技术上的收益,在业务上还带来了短内容曝光等指标的增长,是技术推动业务增长的一个不错的案例。长期看来,由于视频编解码技术仍在不断发展中,比如 H.266 ,采用视频格式的动图以后也能进行无缝切换。综上,GIF 转视频是一个值得推广的技术方案。

本文分享自微信公众号 - 腾讯大讲堂(TX_DJT),作者:leopjqian

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 虚假新闻视频防不胜防?6招助你练出分辨真伪的火眼金睛

    在今年2月份的时候,有个视频火了:用AI技术将朱茵扮演的黄蓉换成杨幂的脸。 ? 视频里杨幂版黄蓉,一颦一笑,非常自然,若不是预先知晓这是经过处理的视频,不少...

    腾讯大讲堂
  • 【客户端技术】深入了解视频播放器工作原理与实现

    | 导语 想在APP中玩转视频播放吗?本文主要探讨播放器的工作原理及优化方向,并基于腾讯视频的开源TVKPlayer的设计,详解视频播放器的内部架构。 在下面...

    腾讯大讲堂
  • 腾讯正在参与制定一个国际标准,让看片儿更简单

    腾讯大讲堂
  • 教你用 Python 生成 GIF 动图 !

    最近啊 ,微信订阅号改变频繁 ,很多读者后台说 :小詹啊 ,我总是容易错过你公号的消息 ,现在没有置顶功能很难过啊 !

    小小詹同学
  • 10万+的短视频被批量生产了,Python表示不服

    前期有些自媒体大 V 靠搬运一些搞笑、好玩的 GIF,然后利用剪辑软件合成一段视频,再添加一个节奏感强的 BGM 后,上传各大自媒体平台后,能带来不错的阅读量和...

    sergiojune
  • 基于云的编码如何提高视频流质量

    演讲者是来自Harmonic的视频战略副主席,同时也是Ultra HD论坛的现任主席,MPEG roadmap委员会的联合主席。演讲的主要内容一方面是视频市场的...

    用户1324186
  • 5.源码分析---SOFARPC调用服务

    我们这一次来接着上一篇文章《4. 源码分析---SOFARPC服务端暴露》讲一下服务暴露之后被客户端调用之后服务端是怎么返回数据的。

    luozhiyun
  • okhttp——RetryAndFollowUpInterceptor

    okhttp的网络请求采用interceptors链的模式。每一级interceptor只处理自己的工作,然后将剩余的工作,交给下一级interceptor。本...

    Oceanlong
  • ASCII,Unicode和UTF-8

    一、ASCII码 我们知道,计算机内部,所有信息最终都是一个二进制值。每一个二进制位(bit)有0和1两种状态,因此八个二进制位就可以组合出256种状态,这被称...

    Angel_Kitty
  • 字符编码笔记:ASCII,Unicode和 UTF-8

    1. ASCII码 我们知道,在计算机内部,所有的信息最终都表示为一个二进制的字符串。每一个二 进制位(bit)有0和1两种状态,因此八个二进制位就可以组合出...

    wangxl

扫码关注云+社区

领取腾讯云代金券