デスクトップからモバイル、CTVまで、視聴者が動画を楽しむために使用するデバイスの数は多岐にわたり、常に拡大しています。コンテンツ制作者にとっては、生のコンテンツをさまざまな HTML5 動画フォーマットにシームレスに変換する必要があります。

HTML5 によって追加のプラグインが不要になったとはいえ、幅広いデバイスでは、再生可能性、品質、およびセキュリティを最大化するために、さまざまな HTML 動画形式が必要です。具体的な HTML5 動画の種類と、さまざまなシナリオに最適な動画形式を調べる前に、動画がどのようにこれらの形式に変換されるかを詳しく見てみましょう。

ビデオエンコーディングとは何ですか？

簡単に言えば、ビデオエンコーディングとは、カメラからの生のビデオデータをデジタルフォーマットに変換する方法です。

しかし、この圧縮と解凍の行為は、必ずしもすべてのデバイスでコンテンツを利用できるようにするわけではありません。トランスコードは、エンコードと混同されがちだが、圧縮されたビデオをあるフォーマットから別のフォーマットに変換します（たとえば、.movから.mp4へ）。

最初のステップでは、コーデック（コーダー／デコーダーの略）を使って、大きなビデオファイルを伝送と保存の両方で管理しやすいサイズに圧縮する。再生準備が整うと、コーデックはファイルを解凍し、オリジナルまたはオリジナルに近い画質で視聴できるようにします。この圧縮と解凍のプロセスにより、ビデオファイルは、効率的な保存と最小限の帯域幅使用で最適化されます。

しかし、コーデックとは一体何なのか、コンテナとどう違うのでしょうか。

コーデックとコンテナ・フォーマット

• コーデック。コーデックとは、生データの圧縮と解凍に使用されるアルゴリズムやソフトウェアのことです。一般的なHTML5のビデオコーデックにはH.264があり、オーディオコーデックにはAAC、MP3、Opusがあります。
• コンテナ。コンテナは、エンコードされた動画と音声を 1 つのファイルにまとめる HTML5 ファイル形式です。これらのファイルには、メタデータや、クローズド キャプションやチャプター マーカーなどの動画固有の重要な情報も含まれます。

ビデオコーデック

各コーデックは、圧縮効率、ビデオ品質、さまざまなデバイスやプラットフォームとの互換性の面でユニークな利点とトレードオフを提供しています。最も一般的なコーデックの種類をよく理解し、特定のニーズに最適なコーデックを選ぶ必要があります。

• H.264.AVC（Advanced Video Coding）としても知られ、広く使われているこのコーデックは、小さなファイルサイズで高品質のビデオを生成し、ほとんどのデバイスとプラットフォームに対応しています。
• H.265.高効率ビデオコーディング（HEVC）は、AVCの約半分のビットレートを使用するため、4Kのような高画質ビデオに理想的なもう1つの一般的なコーデックです。実際、HVECの「高効率」はその圧縮能力を指しています。
• H.266とオープンソースのコーデックH.266、またはVersatile Video Coding (VVC)は、最新の圧縮規格の1つで、HEVCよりも最大50%高い効率を提供できる。そのため、4Kストリーミングだけでなく、8Kやそれ以降のストリーミングにも理想的です。GoogleのVP9やAlliance for Open MediaのAV1のようなオープンソースのコーデックも、圧縮効率をさらに押し上げている。しかし、VVCや他の新しいコードと同様、採用はまだ始まったばかりで、互換性は比較的限られている。

ブラウザとデバイスのコーデック互換性

ブラウザとデバイスの互換性は、ビデオコーデックによって大きく異なる。AVCはほぼすべての一般的なシステムで最も幅広いサポートを享受しているが、VVCは非常に新しいため、ハードウェアのサポートがまったくない。HEVCもほとんどのデバイスで幅広くサポートされているが、モバイルブラウザではまだ苦戦している。また、VP9とAV1はともに市場で大きく前進しているが、アップルのブラウザやデバイスではまだサポートが不足している。

デスクトップ・ブラウジング・サポート

モバイル閲覧サポート

モバイル機器サポート

スマートTV対応

エンコーディングの考慮事項

• 品質（4K+対応）。HDやUHD（4K以上）の映像配信を目指すコンテンツ制作者にとって、コーデックの選択は最重要事項です。H.265（HEVC）とH.266（VVC）は、低ビットレートで高画質を維持するために最高の圧縮効率を提供します。AV1のようなオープンソースのコーデックも、4Kのような高画質動画には最適です。ただ、ターゲットにしているデバイスやプラットフォームが対応していることを確認してください。
• レイテンシー。レイテンシーとは、動画の再生が始まるまでに経過する時間のことです。例えば、ライブストリーミングやインタラクティブビデオを採用する場合、わずかな遅延でも視聴者の体験に大きな影響を与える可能性があるため、低遅延は非常に重要です。H.264（AVC）は低遅延でよく知られているため、リアルタイム・アプリケーションによく使用されます。AV1のような新しいHTML5コーデックは、より優れた圧縮を提供する可能性がありますが、エンコード処理が複雑なため、遅延が大きくなる可能性があります。
• ライセンス。どのコーデックが最適かを決める際には、ライセンス費用も考慮しましょう。H.265（HEVC）やH.266（VVC）のような独自のコーデックにはライセンス料が必要であり、大規模な配信を行う場合、すぐに膨れ上がる可能性があります。

ビデオ・パッケージとは何ですか？

コーデックがビデオデータを圧縮・解凍したら、視聴者にデータを届ける準備をするのがパッケージングです。

ビデオパッケージングは、高品質の視聴体験に必要なすべての要素を組み合わせるプロセスです。これには、エンコードされたビデオファイルとオーディオファイル、ファイルを同期させるマニフェスト、メタデータ、字幕などが含まれます。

その仕組みを簡単に紹介しましょう：

• エンコード。まず、生のビデオとオーディオデータがコーデックを使ってエンコードされ、保存と伝送を容易にするためにファイルサイズが圧縮されます。
• 多重化（muxing）。エンコードされたビデオストリームとオーディオストリームは、コンテナファイルに結合され、シームレスな再生のために編成されます。例えば、MP4、MKV、WebMなどがあります。
• プロパティの選択。制作者は、ビットレート、フレームレート、解像度など、HTML5 動画フォーマットの主要なプロパティを選択します。
• メタデータの追加。タイトル、再生時間、チャプターマーカー、字幕などのメタデータがコンテナに追加されます。

両者にはいくつかの共通点がありますが、パッケージングとトランスマックスの違いに注意することが重要です。主な違いは、パッケージングは新しいコンテナを作成するのに対し、トランスマックスは元のオーディオ、ビデオ、メタデータのコンテンツを変更することなく、コンテナをあるフォーマットから別のフォーマットに変換することです。たとえば、異なるデバイスやプラットフォームとの互換性をサポートするために、ビデオを MP4 コンテナから WebM コンテナにトランスマックスすることがあります。

HTTPと他のプロトコルとの比較

ファイルがパッケージ化された後、それを配信するプロトコルの選択は、パフォーマンスと互換性に影響を与えます。ここでは、HTTPと他の配信プロトコルとの比較について説明します。

• HTTP。HTTP（Hypertext Transfer Protocol）は、インターネット上で使用される標準プロトコルだ。このため、HTTPベースのストリーミングフォーマットは、ユビキタスブラウザのサポートと、ウェブ用にすでに用意されている大規模でスケーラブルなインフラを活用することができます。HLS（HTTP Live Streaming）やDASH（Dynamic Adaptive Streaming over HTTP）などのHTML5動画フォーマットは、多くの視聴者に効率的にリーチできるため、動画ストリーミングに理想的です。しかし、HTTPは待ち時間が長く、視聴者のネットワーク状況によっては一貫した品質と信頼性を維持することが難しい場合があります。
• WebRTC / SRT / RIST。WebRTC（ウェブ・リアルタイム・コミュニケーション）、SRT（セキュア・リライアブル・トランスポート）、RIST（リライアブル・インターネット・ストリーム・トランスポート）などの他のプロトコルは、レイテンシー、品質、信頼性をよりコントロールすることができます。これらのプロトコルは、ビデオ会議、ライブビデオ制作、コントリビューションストリーム、オンラインゲームなどのリアルタイムアプリケーションに適しています。これらのプロトコルは多くの場合、低遅延で安定した品質を提供しますが、大規模な視聴者に配信するための拡張性に問題があったり、コストがかかったりする場合があります。これらの要因により、小規模または限定された視聴者にとってはより理想的ですが、HTTPベースのソリューションと比較して、おそらく広範なビデオストリーミングには適していません。

ストリーミング・プロトコル

ストリーミング・プロトコルはHTTPベースで、ビデオやオーディオ・コンテンツをリアルタイムで配信するために特別に設計されています。視聴者のネットワーク状況に合わせて適応的に再生することで、バッファリングを減らし、全体的にスムーズな視聴体験を提供します。2つの主要なストリーミング・プロトコルと、1つの中間フォーマットがあります。

• HLS。アップルのHLSは、最も広く使われているストリーミング・プロトコルのひとつだ。ビデオコンテンツをHTTPベースの小さなファイルセグメントに分割し、リアルタイムでダウンロードして再生する。特に適応性の高いプロトコルであるため、バッファリングを減らすのに効果的で、幅広いデバイスと互換性がある。
• MPEG-DASH。DASH は、Moving Picture Experts Group (MPEG) によって開発されたオープンスタンダードで、ビデオコンテンツをセグメント化するという点で HLS と似ている。セグメントは異なる品質でエンコードされるため、動画の途中でも品質レベルを切り替え、現在のネットワーク状況に合わせることができる。様々なコーデックに対応できるため柔軟性が高く、ブラウザやデバイスを問わず広くサポートされている。
• CMAF。Common Media Application Format (CMAF)は、厳密にはプロトコルではないが、HLSとDASHで動作するように設計された中間フォーマットである。アップルとマイクロソフトによって開発された彼らの目標は、オンライン・ビデオ配信の複雑さ、コスト、ストレージの削減に役立つ標準を作ることだった。そのため、MP4、.mov などの個別のファイルを作成し、保存する必要がなく、CMAF は HLS と DASH の両方のストリーミングに単一のビデオ・ファイル・セットを使用する。

ストリーミング・プロトコルとのコーデック互換性

• H.264（AVC）。AVCは、HLS、DASH、およびほぼすべてのストリーミング・プロトコルでネイティブにサポートされている。その高い圧縮効率と幅広い互換性により、視聴者は通常、より良い再生と少ないバッファリングを体験することができます。
• H.265（HEVC）。HEVCはHLSでサポートされており、特にiOS 11以降を実行しているアップルのデバイスでサポートされている。DASHもHEVCと互換性がありますが、互換性のある再生ソフトウェアやデバイスが必要です。
• オープンソースのコーデック。VP9はDASHと互換性があり、主要なブラウザと互換性がある。ただし、DASHとHLSはAV1をネイティブサポートしていない。

包装に関する考慮事項

セキュリティ

不正再生の防止は、多くのメディアブランドにとって重要な検討事項です。しかし、デジタル著作権管理（DRM）の実装は、HLS/DASH パッケージ・フォーマットの多様性により、複雑な場合があります。DRMの実装を合理化するために、業界は共通暗号化（CENC）と呼ばれる標準暗号化モデルを開発しました。

CENC は CMAF フォーマットと連動しており、コンテンツ制作者はメディアを一度エンコードして暗号化した後、必要に応じてさまざまな DRM プロバイダを適用して復号化できます。これを実現するために、HTML5 の video タグは、Encrypted Media Extension（EME）と呼ばれるものをサポートしています。EME は CENC と連携し、暗号化された動画コンテンツの処理方法を標準化します。基本的には、128 ビットまたは 256 ビットの CENC キーを使用して動画を暗号化します。動画を復号して再生するには、Google Widevine、Apple FairPlay、Microsoft PlayReadyなどのDRMシステムを活用することができます。これらのDRMプロバイダは、暗号化されたコンテンツのロックを解除するために必要なキーを管理し、許可されたユーザーのみがアクセスできるようにします。

CENC は、メディアを暗号化するための普遍的な方法を提供することを意図していますが、実際には、CENC の実装が異なるため、HLS と CMAF/DASH コンテンツを別々に扱う必要がある場合があります。

マネタイズ（広告挿入）

最新のHTTPストリーミング標準では、広告挿入による動画コンテンツの収益化が非常に容易になっています。マニフェストと呼ばれる動画プレーヤー用の命令を作成することで、チャンクと呼ばれる動画セグメントを指定できます。これらのチャンクは、明示的なメディア ファイル（segment1.ts、segment2.ts、segment3.ts など）またはバイト範囲リクエスト（mediaFile.mp4 バイト 0 ～ 1000 など）を利用して作成できます。これらのマニフェストはそれぞれ、いつ、どこに広告が挿入されるべきかについての広告シグナリング情報を運びます。Apple 社が 2024 年に発表したHLS の Interstitial 属性のサポートを含め、収益化のためのこの機能は成長を続けています。

広告の区切りを指定するだけでなく、マニフェストを活用することで、プレーヤーを代替コンテンツに誘導し、パーソナライゼーションを向上させることができる。バーチャル・マニフェスト」を通じて、各視聴者または視聴者のグループは、パーソナライズされたマニフェストに接続され、誰が視聴しているかに基づいて、特定の広告をリアルタイムでマニフェストにステッチすることができます。これは、当社のサーバーサイド広告挿入（SSAI）ソリューションの中核をなすもので、各視聴者がそれぞれの嗜好や属性に合わせたターゲット広告を確実に見ることができるようにします。

マニフェスト操作のもうひとつの使用例は、視聴者に代替番組を提供することです。たとえば、CBSのような放送局が、全国放送でサッカーの試合を放映するとします。このフィードに接続されているすべての視聴者は、クリーブランドなどの特定の市場にいない限り、試合を見ることができます。クリーブランドでは、マニフェストの指示により、試合中に代替コンテンツを表示するセカンダリー・フィードをプレーヤーに示すことができます。ブラックアウト」または「代替」番組として知られるこのプロセスは、地域の放送権への準拠を保証し、さまざまな視聴者に合わせた視聴体験を提供します。

HLSとDASHのどちらが広告挿入に効果的ということはありません。どちらもマニフェストを通じて同じ方法でそれを可能にし、ほとんどのブランドはデバイスの互換性を向上させるために両方を使用します。とはいえ、コンテンツと広告の基礎となるコーデックとエンコーディング設定は、最高の視聴体験を提供するために一致させる必要があります。コンテンツと広告が不一致だと、再生や品質に問題が生じる可能性があります。当社のようなSSAIソリューションを使用すれば、コンテンツを作成するのと同じインジェスト・プロファイルで広告を調整するため、このような問題を回避できます。

アクセシビリティ

もう一つの重要な検討事項は、複数の言語トラックや字幕を含むアクセシビリティです。幸いなことに、このプロセスはマニフェストの使用によって効率的に管理することができ、HLSとDASHの両方が同じように有能であることを意味します。これを実現するために、ローカライズされたバリアントは実行時に作成され、マニフェスト内で指定されます。そしてマニフェストは、これらのバリアントと、ビデオ レンディション、オーディオ レンディション、キャプション/字幕レンディションなどの関連する補助ストリームを指し示します。

例えば、当社のパートナーであるSyncWordsは、当社のライブ配信をインジェストし、副音声トラック（代替言語での翻訳および吹き替え）と字幕/キャプショントラックを作成します。当初、エンコードされたオリジナルのライブ配信には、以下のような一次アセットのみが含まれています：

• Master Manifest
• Video Variant 720p
• Video Variant 1080p
• Audio Variant – English
• Caption Variant – English

SyncWordsはマスターマニフェストを受け取り、オーディオトラックおよび/またはキャプショントラックの1つを抽出し、リアルタイム翻訳を実行します。このプロセスは、多言語のキャプションを生成し、AIダビングを適用して、スピーカーの言語を他の希望言語に調整した代替オーディオトラックを生成することができます。これは、テクノロジーがコンテンツの制作と消費の両方を、より効率的で、包括的で、アクセスしやすくし続ける方法の明確な例です。

動画配信の歴史

特定の事例に最適な HTML5 動画形式を知るには、動画のエンコーディングとパッケージングのプロセスを理解する必要があります。しかし、現在の業務を将来に向けて準備したいのであれば、ストリーミング技術の歴史を振り返る価値があります。いくつかの技術革新が現れては消え、どのような技術革新が残り、適応し続けているかに注目する価値があります。

プログレッシブ・ダウンロードと早期ストリーミング

ウェブビデオの黎明期には、Windows Media、QuickTime、RealPlayerといったメディアプレーヤーが、視聴のための主要なプラットフォームでした。これらはプログレッシブ・ダウンロード・テクノロジーを使用しており、ファイルはリニア方式でダウンロードされましたが、ビデオは完全なファイルが転送される前に再生が開始されました。当時としては革新的であったが、この方法はしばしばバッファリングの問題を引き起こし、再生には専用のソフトウェアが必要でした。

FLASH

Adobe Flashでは、さまざまなブラウザで利用可能な共通のフレームワークにより、ウェブ上での視聴が簡素化された。動画はバッファリングが少なくなり、全体的なパフォーマンスは向上したが、重く非効率的なブラウザ・プラグインに依存しており、場合によっては重大なセキュリティ・リスクをもたらしていました。

HLS

アップルiPadの登場は、ビデオストリーミング全体の状況を大きく変えた。セキュリティとバッテリー使用量の問題を理由に、アップルはFlashのサポートを停止した。同じ頃、HTML5 がリリースされ、ブラウザが動画再生をネイティブにサポートするネイティブ HTML5 video タグが含まれるようになった。この技術を活用して、アップルは HLS を導入し、HTTP マニフェストを使用して、HTTP プロトコルを使用してストリーム セグメントを要求する方法をプレーヤーに指示した。この技術革新により、既存のウェブ インフラストラクチャが構築され、標準的な HTTP リクエストと HTML5 video タグによるスケーラブルな動画配信が可能になりました。

MPEG-DASH

アップルに続き、MPEGコンソーシアムはMPEG-DASH（Dynamic Adaptive Streaming over HTTP）と呼ばれるアップル以外の規格を発表した。HLSと同様に、MPEG-DASHはセグメントベースのストリーミングとHTTPプロトコルを使用した。しかし、MPEG-DASHは中立的な標準化団体によってサポートされているため、他の多くのデバイスメーカーに広く採用されました。

CMAF

CMAFは、MPEG-DASHとHLSの両方のマニフェスト・フォーマットと互換性のあるベース・メディア・フォーマットとしてコンテンツを準備できるオープン・スタンダードとして導入されました。これにより、各フォーマットごとにメディア資産を作成する必要がなくなり、コンテンツの準備プロセスが合理化され、効率が向上しました。

COMPLICATIONS AND INNOVATIONS

このような進歩にもかかわらず、HTML5 動画ストリーミングは依然として複雑な分野です。超低遅延、ブラックアウト規則、HDR メタデータなどの課題により、MPEG-DASH、HLS、その他の HTML5 がサポートする動画フォーマットにさまざまな拡張が必要となっています。とはいえ、これらの標準は急速に進化し続けている。例えば、HLS は、Apple 2024 Worldwide Developer Conference（WWDC）において、広告配信を強化し、HDR 宣言をサポートするために、いくつかの新しい拡張を受けました。

歴史が示すように、HTML5 ビデオ フォーマットやストリーミング プロトコルの進化に伴い、既存の技術にも革新が起こり続けます。プロセス、ソフトウェア、ツールの基礎知識を持つことは、可能な限り最高の視聴体験を保証しながら、より迅速に開発に適応するのに役立ちます。