このページは 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 を取得する

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

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

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

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

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 はプライマリ URL と 2 つの点で異なります。ホスト名と copy= パラメータの両方が変更されています。ストリームの破損を回避するため、バックアップの取り込みでは、プライマリインジェクションとは異なる 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 にする必要があります。
ストリームに送信される最初の Media Playlist は、シーケンス番号 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 セグメントには、単一の 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 リクエストは無視されます。パフォーマンス上の理由から、クライアントは DELETE を送信しないことをおすすめします。

202 (受理済み)

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

400（不正なリクエスト）

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

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

401（未承認）

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

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

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

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

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