Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

サポートされている色標準は、非定輝度の 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 Studio から HLS 取り込み URL を取得する

YouTube Creator Studio ウェブインターフェースで、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=

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

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

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

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

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

HLS プロトコルの要件

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

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 Help Center をご覧ください。

一般に、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（受理済み）レスポンスは、YouTube サーバーがそのメディアセグメントを含むメディアプレイリストを受信する前にメディアセグメントを受信したことを示します。これは、そのセグメントの処理の遅延を防ぐために、そのメディアセグメントを含むメディアプレイリストをできるだけ早く送信する必要があることをクライアントに示します。エンコーダがすべてのメディアセグメントに対して更新されたメディアプレイリストを送信する場合、これは問題になりません。

400（不正なリクエスト）

HTTP 400（不正なリクエスト）レスポンスは、次のいずれかの問題が発生したことを示します。

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

401（未承認）

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

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

HTTP 405（メソッドが許可されていません）レスポンスは、リクエストが POST、PUT、DELETE リクエストではなかったことを示します。

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

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