01
背景
|
|
|
|
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
![](https://oscimg.oschina.net/oscnet/355060f5-c09d-430b-93f6-1b130568b277.png)
2. 写真の主な利用シーン
|
|
|
|
---|---|---|---|
表紙絵 |
![]() |
動作チャート |
![]() |
![]() |
|||
リソースマップ |
![]() |
素材画像 |
![]() |
![]() |
|||
アバター画像 |
![]() |
UGC |
![]() |
3. 画像フォーマットの進化
![](https://oscimg.oschina.net/oscnet/ea52e454-a662-455a-9fab-d9d3bf9277c7.png)
-
2020年第3四半期以前: iQiyi APPは主にJPEG形式の画像を使用します -
2020年第3四半期: iQiyi APPはWebP形式の画像の使用を優先します -
2022 年第 3 四半期: iQiyi APP は HEIC 形式の画像の使用を優先します -
2023 年第 3 四半期: iQiyi APP は AVIF 形式の画像の使用を優先します
4. 映像の生産と消費のパノラマ
画像形式の切り替えは、画像のサフィックスを変更するだけの簡単な問題のように見えますが、iQiyi APP 内の画像は本番環境から変更されているため、大量の iQiyi APP コンテンツ画像をすべて新しい形式に変更するのは非常に複雑なプロセスです。アップロード、制作、配布から最終的な表示まで、制作と消費のプロセス全体に複数の戦略があり、全体的なリンクは非常に長く、ほぼすべてのリンクが変換に関与する必要があります。
1) 制作プロセス: AI 合成、ビデオ フレーム抽出、オペレーション/プロデューサー提供、オフサイト キャプチャ、およびさまざまな形式のその他の画像ソースを含みます。
2) アップロード リンク:異なるプロデューサーが異なるバックエンド システムを通じてアップロードするため、変換の範囲は広いです。
3) 制作プロセス:アップロードされた画像は通常、目的に応じてさまざまな戦略を使用して前処理する必要があります。たとえば、ビデオのカバー画像の場合、バックエンド システムは専用のパラメータを使用して、フォーマット制作、比率調整、インテリジェントなクロッピング、ズームなどの一連の制作前操作を実行し、複数のフォーマットでビデオ画像を事前制作します。画像の形式とサイズの情報はメディア ライブラリ エンティティに書き込まれ、さまざまなシナリオで使用するために各エンドに提供されます。たとえば、APP 内のロゴなどの素材画像がアップロードされます。コンテンツ管理システムを介して変換され、指定された形式を生成するためにのみトランスコードされ、さまざまなサイズで生成されることはありません。
4) 配信リンク: CDN および APP ビジネス バックエンド インターフェイスが配信を担当します。
CDN は画像の形式とサイズのオンデマンド制作をサポートする必要がある
カバー画像の非標準サイズ 666*666 の AVIF 画像など、バックエンド システムのプリプロダクション範囲内にないサイズの場合は、サイズと形式のサフィックス 666_666 を指定することで、オンデマンドでリアルタイムに生成できます。アヴィフ。
-
APP ビジネス バックエンド インターフェイスは、フロントエンドの特性に基づいて、指定された形式とサイズの画像 URL を返す必要があります。 さまざまなビジネス シナリオに応じて、さまざまなサイズのカバー画像が返されます。たとえば、ウォーターフォール フローでは 579*772、映画やドラマ チャンネルの編集者では 405*540、S カードの検索では 1248*624 が使用されます。
![](https://oscimg.oschina.net/oscnet/c6ccae77-eb87-46c0-89eb-3e7fddff310f.png)
![](https://oscimg.oschina.net/oscnet/2de65f83-d66f-42a3-b4e2-dca00302f896.png)
02
WebP形式の実装実践
1. 背景
2020 年 3 月、iQiyi モバイル端末は、画像 CDN コストを節約するために、当時主に使用されていた JPG、PNG、GIF 形式に代わる WebP 画像形式を完全に適用する準備を進めています。
2. 困難
モバイル ページで使用される画像 URL は、基本的にモバイル バックエンド インターフェイスによって返されます。モバイル バックエンド インターフェイスには、画像 URL を WebP 形式で返すようにこれらのインターフェイスを変更するコストが高すぎます。将来的には、他の画像形式を再度変換する必要があり、これには非常に時間と労力がかかります。
3. 解決策
ネットワーク全体のアダプティブピクチャアーキテクチャ(略称キャプリストソリューション)
原則:モバイル画像ライブラリは、画像 URL の後に caplist パラメータを自動的に入力して、現在のデバイスでサポートされている画像形式を画像 CDN に伝え、画像 CDN は最適な画像形式を返します。
-
たとえば、画像の元の URL は http://...xxx.jpg ですが、画像ライブラリによって発行された画像リクエストにより http://...xxx.jpg?caplist=webp,jpg に変換されます。 CDN 側は画像リクエストを受信し、パラメータ caplist を解析し、事前定義された優先順位 (avif > heic > webp > jpg > png) に基づいて、caplist でサポートされている画像形式の範囲内で、次の形式で画像を返そうとします。優先度が高くなります。このプロセスでは、まずキャッシュを確認し、オンデマンド プロダクションをサポートしているかどうかを確認します。その具体的なロジックは次の図に示されています。すべての試行が失敗すると、404 (HTTP_NOT_FOUND) エラー コードが応答され、イメージ ライブラリは指定されたイメージをレンダリングできません。 -
制限事項:イメージ要求に必要な時間が長くなるダウングレードは避けてください。したがって、caplist ソリューションに適した高品質の画像形式には 2 つの特性がある必要があります (WebP 形式はこれに準拠しています)。 -
高い実稼働前比率 (一次キャッシュ クエリのヒット率の向上) -
オンデマンドの生産は時間がかかり、コストがかかります (ダウングレードを回避し、時間のかかるリクエストを削減します)
![](https://oscimg.oschina.net/oscnet/4c2798e5-0a99-43e9-b660-6c8302626aff.png)
4. オンライン効果
03
HEICフォーマット実装の実践
1. 背景
iQiyi が初めて WebP 画像形式を本格的に使用した 2020 年 5 月の時点で、ファイル圧縮率がより高い HEIC 画像形式がモバイル端末に実装される可能性をすでに調査していました。その時点での評価結論は次のとおりでした。
このモデルは互換性が高く、iOS11以降とAndroid9以降はシステムレベルでHEIC形式の画像をサポートしており、互換性には問題ありません。
高いファイル圧縮率: 同じ画質でも、HEIC 画像は WebP 画像より 30% 以上小さくなります。
デコード パフォーマンス: iOS 側のハード デコードは WebP よりも高速で優れたパフォーマンスを発揮しますが、Android 側はソフト デコードのみをサポートしており、WebP の 7.75 倍の時間がかかり、WebP の 3.76 倍のメモリ スペースを消費します。
Android システムにおける HEIC 画像形式のデコード パフォーマンスが低いため、HEIC 画像形式は iOS 側の特定のシナリオで小規模に試験的にのみ使用されました。
2年後の2022年5月には、コスト削減と効率化を背景に、複数部門が連携してHEIC画像フォーマットの導入を推進し、さまざまな最適化手法によりHEIC画像フォーマットへのアクセス割合を増加させました。
2. 困難
-
Android システムは HEIC 形式をサポートしていますが、デコードのパフォーマンスが低く、オープンソースの HEIC デコーダのパフォーマンスが理想的ではなく、全体的な実装が要件を満たしていません。 -
HEIC图片格式编码性能较差,耗时较长,不能满足CDN按需生产的要求。之前落地WebP格式过程中非常高效成功的caplist方案非常依赖按需生产能力。如果请求的图片没有预生产过HEIC格式,也不支持按需生产,就会直接降级到低优先级的格式,这会导致图片请求耗时增加。因此,caplist方案在HEIC格式落地中不适用,这大大提高了HEIC格式落地的难度和时间成本。 -
已生产的HEIC图片仅覆盖2020年之后生产的部分图片,占比不够高 -
动图流量占比大,但是iOS和Android系统都不支持HEIC动图
3、解决方案
1)自研HEIC解码器,解决Android端HEIC图片解码性能问题
HEIC图片格式是使用H265编码格式压缩的,而爱奇艺在H265视频编解码方面有丰富经验,于是决定自研HEIC图片解码方案。经过不懈努力,自研解码器的性能相对于系统解码器提升了5倍以上。解码性能虽然仍然比WebP差一点,但是考虑到CDN成本节省,图片下载耗时降低等优势,已具备上线要求。
2)通过后端接口直接返回HEIC格式图片URL的方式落地HEIC格式,解决项目前期caplist方案不能用的问题 由于HEIC格式编码耗时长,不满足caplist方案需要图片格式支持按需生产的前提,那就只能是用最简单直白的方法了,即通过移动后端接口直接返回有预生产好的HEIC格式的图片URL,来让移动前端加载HEIC格式的图片。
但是由于移动后端接口需要聚合的各个业务后端接口非常多,非常分散,而且某个图片是否有预生产好HEIC格式这个信息业务后端接口可能没有传递给移动后端接口,给移动后端接口改造也带来了难度。我们只能通过线上热度数据分析排出要改造的接口的优先级,联合多个业务后端团队有选择地挑选一些影响较大的接口,优先进行改造,以控制改造成本。
3)解决HEIC编码器性能问题,部分使用caplist方案解决项目后期HEIC格式访问量占比增长乏力的问题
Android端自研HEIC解码器的成功研发和落地也为HEIC编码性能较差问题提供了解决思路。技术团队又自研出了高性能HEIC编码方案——Q265编码器,其HEIC编码耗时接近于WebP,比老的X265编码器缩短70%,性能已满足实时生产的需求。这使得caplist方案又能够被采用了。不过,Q265编码器经过几次上线后的迭代改进,中间版本生产出来的HEIC图片有一些问题需要避免使用,因此,caplist覆盖范围必须设置为最终稳定版上线日期之后生产的HEIC图片。加上使用Q265编码器的图片生产工具没有被部署到所有图片CDN服务器,所以,针对HEIC格式的caplist方案是受限制的。
4)针对热度较高的历史图片进行补生产,进一步提升HEIC格式访问量占比
分析发现2020年之前生产的老图片仍然有较高的访问量,但是又没有预生产HEIC格式的图片,并且分布极为分散,难以通过移动后端接口改造的方式来返回HEIC格式给前端,也无法用caplist方案覆盖,因为caplist只能覆盖Q265编码器上线后生产的图片。
最终,我们通过统计线上图片的访问热度,对访问量较高的历史图片补生产了HEIC格式。
5)双端自研动图编解码渲染方案,提高降CDN成本的收益
分析发现移动端有20%-30%的图片流量来自动图,HEIC动图可以像视频编码压缩算法一样支持前后帧合成,文件压缩率比静图更高,但是当时没有现成的HEIC动图的生产端编码和移动端解码方案,需要全新自研。
-
生产端编码方案:自研HEIC动图编码器 使用H265格式编码,使用自研库进行格式封装,配置和调校参数以达到最优效果。实验了全I帧、IP帧、PB帧等多个方案,最终选择了自研IP帧方案,兼顾了兼容性和文件大小。 -
Android端解码方案:自研HEIC动图解码器 -
iOS端解码方案:自研HEIC动图解码器
![](https://oscimg.oschina.net/oscnet/bcc97a81-8522-4ad1-b3d0-4b0646be0498.png)
4、上线效果
截止2023年3月8日,移动端HEIC格式图片相对于所有图片格式的访问量占比40%+,相比WebP节省流量13%+。HEIC图片格式之所以没能达到WebP格式当时85%的访问量占比,原因如下:
通过移动后端接口改造的手段返回HEIC格式图片给移动前端成本较高,仅覆盖了少数访问量高的业务场景;
通过caplist方案将非HEIC格式图片让CDN优先返回HEIC格式的手段,因Q265编码器上线时间不长,图片CDN服务器未全面部署等原因,仅覆盖了某个日期之后生产的某些图片CDN域名下的图片,范围较小;
补生产的历史图片数量有限,全量补生产代价较大。
04
AVIF格式落地实践
1、背景
比HEIC更新、更先进的图片格式是AVIF(AV1 Image File Format,是由开放媒体联盟开发,采用AV1视讯编码技术压缩图像的一种图像档案格式),其具有更高的图片压缩率,如果能推广落地,又能进一步降低图片CDN成本。经调研,iOS16+,Android12+系统层面对AVIF格式图片进行了支持。
由于在HEIC格式落地的过程中积累了很多成功经验,技术团队对支持更先进的AVIF图片格式信心满满。于是在2023年5月,我们又启动了AVIF图片格式落地专项,基本可以照搬HEIC格式落地的模式。
2、难点
系统解码性能不佳
由于iOS和Android系统解码层面依然存在解码性能差的问题,并且对于系统版本要求过高(Android 12+、iOS 16+),符合要求的线上设备数量占比不够高,导致无法直接使用系统解码作为上线方案。
不支持透明图
由于爱奇艺自研的QAV1编码器之前一直应用于视频编码,对于透明内容没有硬性要求,因此AVIF编解码器刚开始不支持透明内容。而在图片的使用过程中,透明图是比较常见的场景。
-
图片覆盖范围不广 在AVIF全面上线后,根据CDN团队的反馈,caplist方案仅能覆盖有AVIF预生产且支持按需生产的部分图片CDN域名下的部分目录,AVIF格式访问量整体占比依然偏低。通过数据分析发现访问量占比较大的一些目录还未支持AVIF格式图片预生产。另一方面,目前AVIF按需生产的支持范围依然不是很广。这两方面导致caplist方案覆盖范围非常受限。
![](https://oscimg.oschina.net/oscnet/4ecbab04-f6c1-471b-b54d-ddfef0a82006.png)
3、解决方案
-
自研avif解码器,解决移动端AVIF解码性能不佳的问题 得益于爱奇艺QAV1视频编解码器已经广泛使用,可以将成果复用于图片的编解码方案。最终编解码团队自研的AVIF解码器支持iOS9+,Android7+以上的系统版本,并且解码性能优于libheif、libaom、libdav1等开源解码器。 -
改进自研的avif编解码器,解决透明图问题 经过编解码团队的不懈努力,在2023Q4对AVIF透明图的编解码进行了支持。 -
用caplist方案覆盖更多图片CDN目录,提高AVIF格式占比 后台系统在2023Q4对相关目录进行了预生产支持,使得这些目录下预生产日期之后生产的图片可以被caplist方案覆盖到。但是整体覆盖的目录下的图片访问占比仍然偏低。 CDN团队正在研发全按需方案:所有图片CDN域名,所有目录都支持按需生产,且不需要使用caplist参数,通过文件名后缀指定图片格式。届时可以解决不同域名和路径对AVIF的支持。
4、上线效果
通过分析线上数据,观察到图片文件体积优化效果:
静图:HEIC比WebP小30%,AVIF比HEIC小11%,AVIF比WebP小38%;
动图:HEIC比WebP小60%,AVIF比HEIC小30%,AVIF比WebP小72%。
![](https://oscimg.oschina.net/oscnet/15e997c9-9234-4128-b3fd-31fdc35d06a6.png)
![](https://oscimg.oschina.net/oscnet/49e1cb79-ccb5-4b59-bff8-02b6d45524ba.png)
05
总结与展望
通过图片生产消费全流程跨部门通力合作,核心技术攻关,HEIC/AVIF编解码完整方案全自研等实践,爱奇艺逐步将主要图片格式从JPG迁移到最新的AVIF,在保证图片显示质量的前提下,有效地降低了图片CDN带宽成本。
未来,爱奇艺将继续努力提高AVIF图片格式的使用率,实现极致的图片CDN成本控制。
![](https://oscimg.oschina.net/oscnet/a4d99aa4-b8d6-4d38-8dc1-d55f48d0ad4a.jpg)
本文分享自微信公众号 - 爱奇艺技术产品团队(iQIYI-TP)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
{{o.name}}
{{m.name}}