このページは Cloud Translation API によって翻訳されました。

HLS による YouTube ライブコンテンツの配信

このドキュメントでは、HTTP Live Streaming（HLS）プロトコルを使用して、エンコーダから YouTube でライブデータをストリーミングする方法について説明します。このドキュメントは、製品に HLS 取り込みサポートを追加したいエンコーダベンダーを対象としています。HLS 取り込みは、比較的高いレイテンシで高品質と高解像度を必要とするプレミアムコンテンツに適しています。YouTube ライブストリーミングがサポートするさまざまな取り込みプロトコルの簡単な比較については、YouTube ライブストリーミングの取り込みプロトコルの比較をご覧ください。

HLS を使用してライブデータをストリーミングするには、エンコーダが HTTP PUT リクエストまたは POST リクエストを使用して、一連のメディア再生リストとメディアセグメントを YouTube の HLS エンドポイントに送信する必要があります。エンコーダから見ると、YouTube HLS エンドポイントはパッシブ HTTP サーバーのように見えます。

各メディアセグメントは、1 ～ 4 秒間のストリームの短い部分の実際のマルチメディアコンテンツを表します。各メディア再生リストには、メディアセグメントを正しいストリーム順序で再構成する方法が記述されています。

メディア形式の要件

YouTube HLS 取り込みでは、動画コンテンツと音声コンテンツに関して次の要件が適用されます。

動画と音声は M2TS 形式で多重化する必要があります。
サポートされている動画コーデ��クは H.264 と HEVC です。
最大 60 fps のフレームレートがサポートされています。
クローズド GOP のみがサポートされています。
サポートされているオーディオコーデックは AAC で、シングルトラックのオーディオのみがサポートされています。

詳細な要件については、メディアセグメントのセクションをご覧ください。

HDR

ハイダイナミックレンジ（HDR）動画は HEVC コーデックを使用してサポートされ、以下の追加要件があります。

サポートされているカラー規格は、非定輝度の 10 ビット PQ と HLG です。具体的には次のようになります。
- クロマ形式は YUV 4:2:0 10 ビットである必要があります。
- 伝達関数は PQ（SMPTE ST 2084 とも呼ばれます）または HLG（ARIB STD-B67 とも呼ばれます）である必要があります。
- 色域は Rec. 2020 でなければなりません。
- カラーマトリックス係数は Rec. 2020 非定輝度でなければなりません。
リミテッドレンジ（または MPEG レンジ）とフルレンジ（または JPEG レンジ）の両方のサンプル値がサポートされています。範囲は、コンテンツが使用するサンプル値の範囲に従って設定することが重要です。範囲が制限されたサンプル値をおすすめします。

HLS 取り込み URL を取得する

YouTube API から HLS 取り込み URL を取得する

完全な取り込み URL を取得するには、エンコーダで YouTube Live Streaming API を使用して、次のプロパティを持つ liveStream リソースを挿入します。

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

API レスポンスの cdn.ingestionInfo.ingestionAddress フィールドはプライマリ取り込み URL を指定し、cdn.ingestionInfo.backupIngestionAddress フィールドはバックアップ取り込み URL を指定します。詳細については、liveStreams リソースのドキュメントをご覧ください。

YouTube クリエイターツールから HLS 取り込み URL を取得する

YouTube クリエイターツール��ウェブインターフェースで、クリエイターが [ストリームを作成] をクリックすると、英数字とハイフンで構成される [ストリームキー] が YouTube に表示されます。このシークレットキーは、クリエイターとストリームの両方を YouTube に識別します。

このストリームキーから、次のように HLS URL を作成できます。

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

ここで、$STREAM_KEY はウェブインターフェースに表示されるストリームキーです。たとえば、https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file= です。

信頼性を高めるために、取り込みの冗長な 2 つ目のコピーをこのバックアップ URL に送信できます。

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

バックアップ URL は、ホスト名と copy= パラメータの両方が変更されているため、プライマリ URL とは 2 つの違いがあります。バックアップ取り込みでは、ストリームの破損を避けるため、プライマリ取り込みとは異なる copy= パラメータ値を送信する必要があります。

HLS 取り込み URL を完成させる

どちらの方法で取得した URL も不完全なテンプレートであり、それぞれ空の file= クエリパラメータで終わります。最終ページ URL を作成するには、エンコーダはメディアプレイリストまたはメディアセグメントのファイル名を URL の末尾に追加して、file= パラメータを完成させる必要があります。

file= パラメータの値には次のルールが適用されます。

エンコーダは、英数字、アンダースコア、スラッシュ、ハイフン、ピリオドからメディアプレイリストまたはメディアセグメントのファイル名を構成できます。他の文字はサポートされていません。
エンコーダはファイル名を URL エンコードしてはなりません。
エンコーダは、ファイル名に相対パスまたは絶対パスのコンポーネントを含めることができますが、これは必須ではありません。エンコーダがメディアセグメントのファイル名にパスコンポーネントを含める場合、対応するプレイリストエントリで同じパスを参照する必要があります。

HLS プロトコルの要件

エンコーダから送信されるメディア再生リストとメディアセグメントは、HTTP Live Streaming 第 2 版の仕様に準拠している必要があります。

HLS 仕様では、メディアプレイリストとマスタープレイリストの 2 種類のプレイリストが定義されています。YouTube はストリーミングコン��ンツをさまざまな解像度とビットレートにトランスコードするため、エンコーダはさまざまなビットレートのコンテンツを YouTube に送信する必要はありません。そのため、YouTube は HLS 取り込み用のメディアプレイリストのみをサポートし、マスタープレイリストは無視されます。（マスタープレイリストは、同じコンテンツの異なるバージョンをそれぞれ記述する一連のバリアントストリームを提供します）。

エンコーダは、次の要件を満たす必要があります。

ユーザーに配信する最高解像度のエンコード済みストリームを 1 つだけ送信します（単一の解像度とコーデック）。
音声と動画を多重化します。
すべてのリクエストで HTTPS と永続接続を使用します。

以降のセクションでは、メディアプレイリストとメディアセグメントに関するより具体的な要件について説明します。

メディアの再生リスト

メディア再生リストには、連続したデコード可能なマルチメディアストリームを表すために連結できるメディアセグメントのリストが含まれています。メディアプレイリストは、サーバーにどのメディアセグメントを想定し、再構成されたストリームでそれらを適切に順序付ける方法を伝えます。

要件

メディアプレイリストのファイル名の末尾は .m3u8 または .m3u にする必要があります。
ストリーム用に送信される最初のメディアプレイリストはシーケンス番号 0 で始まり、シーケンス番号は単調増加する必要があります。
EXT-X-MEDIA-SEQUENCE タグは、再生リストに記載されている最初のメディアセグメントのシーケンス番号を指定する必要があります。
メディアプレイリストに未取得のセグメントが 5 つ以上含まれていてはなりません。サーバーがセグメントを受信していないか、受信を確認していない場合、そのセグメントは未処理です。

未処理のセグメントに加えて、各メディアプレイリストにいくつかの確認済みのセグメントを含めます。この方法により、サーバー側でメディアプレイリストが失われた場合にセグメントがスキップされる可能性が低くなります。たとえば、各メディアプレイリストに最大 2 つの確認済みセグメントと最大 5 つの未確認セグメントを含めることができます。

サーバーは、メディアセグメントのアップロード時に 200（OK）または 202（Accepted）レスポンスを返すことで、メディアセグメントの受信を確認します。202 レスポンスは、サーバーがそのセグメントを識別するプレイリストよりも前にセグメントを受信したことを示します。
メディア再生リストが失われた場合にサーバーが迅速に復元できるように、すべてのメディアセグメントについて更新されたメディア再生リストを送信します。
サーバーがメディアセグメントの受信を確認したら、EXT-X-MEDIA-SEQUENCE タグ値をインクリメントして、メディア再生リストが長くなりすぎないようにします。たとえば、サーバーが最初の 9 つのメディアセグメントの受信をすでに確認している��合、次のメディアプレイリストには 8 番目、9 番目、10 番目のメディアセグメントがリストされる可能性があります。
EXT-X-KEY タグと EXT-X-SESSION-KEY タグはサポートされていません。

例

エンコーダが送信するファイルの一例を次に示します。

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

次の例は、ライブ動画ストリームの途中で送信されるメディア再生リストを示しています。この例はストリームの中間から取得したものであるため、EXT-X-MEDIA-SEQUENCE タグの値はゼロ以外です。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

メディアセグメント

メディアセグメントの要件は次のとおりです。

ファイル名
- URL のメディアセグメントファイル名には .ts ファイル名拡張子が含まれており、プレイリストのファイル名と一致している必要があります。
- メディアセグメントのファイル名は、エンコーダの再起動とストリームの再起動の間で一意である必要があります。
形式
- メディアセグメントは M2TS 形式で、自己初期化可能である必要があります。
- 各 M2TS セグメントには 1 つの MPEG-2 プログラムが含まれている必要があります。
- M2TS セグメントには PAT と PMT が含まれていなければなりません。また、セグメント内の最初の 2 つのトランスポートストリームパケットは PAT と PMT でなければなりません。
コンテンツ
- 動画と音声は多重化されている必要があります。
- サポートされている動画コーデックは H.264 と HEVC です。
- HEVC を使用した HDR がサポートされている（HDR の要件を参照）。
- 最大 60 fps のフレームレートがサポートされています。
- クローズド GOP のみがサポートされています。
- サポートされているオーディオコーデックは AAC で、シングルトラックのオーディオのみがサポートされています。
- メディアセグメントの長さは 1 ～ 4 秒にすることをおすすめします。次のセクションで説明します。メディアセグメントの長さは 5 秒を超えてはなりません。
- メディアセグメントは、HTTPS を使用して TLS/SSL レイヤでのみ暗号化する必要があります。他の暗号化メカニズムはサポートされていません。

メディアセグメントの長さ

HLS 取り込みは、高画質と高解像度を必要とするプレミアムコンテンツで使用されることが想定されています。HLS 取り込みはセグメントベースであるため、通常、RTMP ベースおよび WebRTC ベースの取り込みよりもレイテンシが高くなります。

メディアセグメントの長さを短くすると、リバッファ率が高くなり、エンコード効率が低下するものの、レイテンシを短縮できるため、メディアセグメントの長さは 1 ～ 4 秒にすることをおすすめします。前のセクションで説明したように、メディアセグメントは 5 秒以内にする必要があります。

ビットレート

YouTube ヘルプセンターには、ビットレート設定のガイドラインが記載されています。

一般的に、HEVC は H.264 と比べて、同じ画質で 25 ～ 50% 多くのデータを圧縮できます。そのため、推奨範囲の下限に近いビットレート値を HEVC で使用して帯域幅を節約できます。これは 4K コンテンツで特に有効です。

その他の要件

エンコーダは、次の構文を使用して HTTP リクエストの User-Agent ヘッダーを設定する必要があります。この構文には、メーカー名、モデル名、バージョンが含まれます。
```
User-Agent: <manufacturer> / <model> / <version>
```
注: この情報はデバッグのみに使用されます。ストリーム処理の機能的な決定には使用されません。

字幕

HLS 取り込みでは、クローズドキャプションの送信に次の 2 つのオプションがサポートされています。

個別の HTTP POST リクエストを使用してクローズドキャプションを送信します。これはすべての HLS 取り込みで機能します。
埋め込み型 608/708 字幕は、H264 動画コーデックを使用する HLS 取り込みでは機能します��、HEVC 動画コーデックを使用する取り込みでは機能しません。詳しくは、YouTube ヘルプセンターのライブ字幕の要件をご覧ください。

HTTP レスポンスコード

以降のセクションでは、HLS を使用して配信されたメディアセグメントとメディアプレイリストに対するレスポンスとして YouTube が返すレスポンスコードについて説明します。

200（OK）

PUT リクエストまたは POST リクエストに対する HTTP 200（OK）レスポンスは、YouTube サーバーが想定されたオペレーションを受信し、正常に処理したことを示します。

DELETE リクエストに対する HTTP 200（OK）レスポンスは、YouTube サーバーがリクエストを受信して無視したことを示します。YouTube サーバーは、クライアントがストリーム内のリソースを削除することを要求せず、DELETE リクエストを無視します。パフォーマンス上の理由から、YouTube はクライアントが DELETE を送信しないことを推奨しています。

202 (受理済み)

HTTP 202（Accepted）レスポンスは、YouTube サーバーが、そのメディアセグメントを含むメディアプレイリストを受信する前に、メディアセグメントを受信したことを示します。これは、そのメディアセグメントを含むメディアプレイリストをできるだけ早く送信して、そのセグメントの処理の遅延を防ぐ必要があることをクライアントに示します。エンコーダがすべてのメディアセグメントに対して更新されたメディアプレイリストを送信する場合、この問題は発生しません。

400（不正なリクエスト）

HTTP 400（Bad Request）レスポンスは、次のいずれかの問題が発生したことを示します。

URL の形式が正しくありません
再生リストを解析できないか、サポートされていないタグが含まれている

401（未承認）

HTTP 401（Unauthorized）レスポンスは、YouTube HLS エンドポイントのベース URL の cid パラメータが破損しているか期限切れであることを示します。クライアントは、続行するために cid パラメータを更新する必要があります。

405（メソッドが許可されていません）

HTTP 405（Method Not Allowed）レスポンスは、リクエストが POST、PUT、DELETE リクエストではなかったことを示します。

500（内部サーバーエラー）

HTTP 500（Internal Server Error）レスポンスは、サーバーがリクエストを処理できなかったことを示します。このエラーについては、指数バックオフを使用してリクエストを再試行することをおすすめします。