異なるビデオ解像度に対応したチャンネルロゴの最適化

FASTチャンネルのロゴ（画面の隅にある小さなマーク）は、すべての番組、すべてのCMブレイク、すべてのスレートにおいて、チャンネル全体で唯一視覚的に一貫しているものです。視聴者が受け取る可能性のあるあらゆる品質レベルで、プロフェッショナルな見た目である必要があります。1つのマスター画像をアップロードし、AWS MediaLiveに各レンディションに合わせてスケーリングさせるという素朴なアプローチでは、1080pでは鮮明なロゴが生成されますが、360pでは明らかにぼやけたロゴになってしまいます。これは、ブロードバンドを利用していないすべての視聴者にとってブランド上の問題です。ここでは、代わりに各レンディションの正確なpixel gridに合わせてロゴのサイズを決定した方法を紹介します。

概要

ビジネス課題

FASTチャンネルは単一の品質レベルを提供するわけではありません。MediaLiveは同じチャンネルを複数のレンディション（1080p, 720p, 480p, 360p）にエンコードし、各視聴者のプレイヤーは接続が維持できる最適なものを選びます。携帯データを利用するモバイル視聴者は360pを視聴し、ブロードバンドを利用するスマートTV視聴者は1080pを視聴します。彼らは皆同じブランドマークを見ており、それがプロフェッショナルに見えることを期待しています。1080pでロゴが鮮明であるにもかかわらず、360pで明らかにぼやけている場合、ブランドに一貫性がありません。ロゴが単一の番組よりも多く視聴者に見られる24時間365日のチャンネルにおいては、これは些細なことではありません。

オーバーレイが実際に適用される場所

マルチレンディションエンコーダーパイプラインでは、オーバーレイは2つの場所で適用できます: 

レンディションごとのスケーラーの前に、1つのマスター画像がsourceに合成され、全体が出力ごとに縮小される場合 — これはMediaLiveがグローバルな StaticImageActivate アクションで行う方法です。

 スケーラーの後に、canvasがすでに最終サイズになった後で、各出力に独自のオーバーレイが適用される場合。API上では小さな違いに見えます。しかし、視覚的にはそうではありません。スケーラーの前に合成されたものはすべて、スケーラーが導入するすべてのartifactを継承し、360pではスケーラーは積極的です。

明らかな修正策が失敗する理由

「1つのマスターをアップロードし、MediaLiveにスケーリングさせる。」 グローバルアクションは、出力ごとのスケーラーが実行される前にマスターを合成します。360p用の64×21pxのロゴにダウンscaledされた大きなマスターは、およそ40倍の縮小です。この比率ではLanczos resamplingでさえ細かいディテールが失われ、その結果はビデオ自体と同じcompression chainを通過します。

「より大きなマスターを使用する。」 これはダウンscale比率を大きくするもので、小さくするものではありません。artifactは改善されるどころか悪化します。

「SD出力でロゴをスキップする。」 コンプライアンスとブランド要件により、すべてのレンディションにマークが必要です。これは選択肢ではありません。

「エンコード時にロゴをsourceビデオに焼き付ける。」 すべての運用上のレバーを失います。キャンペーンごとや地域ごとのロゴ変更はできず、ライブラリ全体を再エンコードしなければ更新できません。

「解像度ごとに手動座標を持つグローバルオーバーレイを使用する。」 グローバルアクションは固定された1920×1080のリファレンスに対して位置を計算するため、それよりも狭いsourceビデオではoff-canvas座標が生成され、ロゴが隅からずれたり、トリミングされたりします。

実際の解決策は、MediaLiveのoverlay scalingを完全にバイパスすることでした。つまり、エンコーダーが触れる前に、各レンディションのcanvasに合わせてロゴのサイズを自分たちで調整するのです。

解決策

各レンディションのロゴは、その正確なpixel寸法に合わせてpre-renderedされ、個別のPNGとして保存されます。各番組の区切りで、Lambda orchestratorは4つの StaticImageOutputActivate アクション（レンディションごとに1つ）を発行し、それぞれが特定の出力に合わせてすでにサイズ調整されたPNGを指します。MediaLiveはオーバーレイに対して一切scalingを行いません。

GLOBAL (素朴なアプローチ)          出力ごと (我々が提供するアプローチ)
master.png ──► source canvasに合成     master.png ──► Lanczos resize (offline)
                                                  で4つの正確なサイズのPNGに
                    │                                  │
                    ▼                                  ▼
           レンディションごとのスケーラー      レンディションごとのスケーラー
           (オーバーレイもスケーリング              (オーバーレイは触られない —
            → SD出力でぼやけたロゴに)             後で、正確なpixelサイズで合成される)

Pythonスクリプトは、単一のマスターからLanczos resamplingを使用して4つのサイズ調整されたPNGを生成します。これは、pixel品質競争に勝つためではなく、小さなサイズでの予測可能で再現性のある動作のために選択されました。各ロゴはcanvas幅のおよそ10%の場所に配置され、邪魔にならない程度に視認できます。新しいレンディションを追加するには、1つのarray entryと1つの新しいPNGが必要です。

注目すべき主要な決定事項

1.5秒のアクティベーション遅延。 ウォーターマークオンのアクションは、正確な切り替えの瞬間ではなく、各入力切り替えから1.5秒後に実行されます。即座にアクティベートすると、まだ安定していないフレームに対してちらつきが発生する可能性があります。この値は経験的に調整され、単一の定数として一元化されているため、将来の調整は1行の変更で済みます。

意図的にofflineで、人間がトリガーするアセット生成。 Lanczos resizeパイプラインは、ビルドステップやCDN側のtransformとしては自動化されていません。ロゴのアセットはめったに変更されないため、1コマンドでの再生成が適切な自動化のレベルです。さらなる自動化を構築するコストは、年に2回スクリプトを実行するコストを上回ります。

「太い」バリアントは存在するが出荷されていない。 ジェネレーターは、低SD bitratesでのH.264 quantizationに耐えるように、より太いストロークを持つdilated-alphaバリアントも生成します。これは本番環境では使用されていません。現在のbitrate範囲では標準バリアントで十分であり、切り替えを正当化する測定結果はまだありません。コードテスト済みのスタンバイとして存在しています。利用可能にしておくのは安価ですが、出荷するには時期尚早です。

今後の検討事項

本番環境のビデオパイプラインが真に完成することはありません。このアプローチを時間をかけて洗練させる機会はまだあります。
現在の実装では、すべてのレンディションが自身の出力解像度に合わせて特別に準備されたロゴを受け取ることを保証し、MediaLiveパイプラインからのruntime overlay scalingを排除しています。しかし、最終的な外観は、特に低bitratesにおいて、各レンディションの解像度とビデオ圧縮によって依然として自然に制限されます。ストリーミングプロファイルが進化するにつれて、異なるロゴ処理がそれらの条件下で測定可能な視覚的メリットを提供するかどうかを引き続き評価していきます。
アセットジェネレーターはすでに標準とより厚いロゴバリアントの両方をサポートしています。将来のテストで、より厚いバージョンが低bitrateのレンディションでより優れたパフォーマンスを示す場合、ロゴバリアントの選択をconfiguration-drivenにし、アプリケーションを再デプロイすることなく変更できるようにします。

結果

すべてのレンディションが、MediaLiveがruntime overlay scalingを一切行わずに、自身のcanvasに合わせて特別にサイズ調整されたロゴを受け取るようになりました。各出力はターゲット解像度用に準備されたアートワークを使用し、runtime overlay scalingによって導入される追加のぼやけを回避しつつ、そのレンディションが提供できる最善の実用的な視覚品質を維持します。
以前のグローバルオーバーレイアプローチで見られた、1920pxよりも狭いsourceビデオでロゴがずれる可能性があったcoordinate-driftバグは、出力ごとのアクティベーションが完全にoutput coordinatesで動作するため、構造的に排除されました。
ロゴの置き換えは、単一のスクリプトでレンディション固有のアセットを再生成し、アップロードするだけの簡単な運用タスクになりました。ビデオの再エンコードやレンディションごとの手動編集は不要です。
この実装は、可能な限りパイプラインの早い段階で問題を解決し、下流のworkaroundに頼るのではなく、プラットフォームの機能を中心に設計するというシンプルなエンジニアリング原則に従っています。エンコード前に正しいアセットを準備することで、ライブパイプラインはよりシンプルで予測可能になり、維持も容易になります。
ライブビデオパイプラインで同様のレンディションやオーバーレイの品質問題に直面している場合は、ご連絡ください。

テクノロジースタック: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)