ハイライト
Apple は低遅延 HLS をベータ版から iOS 14、tvOS 14、macOS にプッシュし、HTTP/2 プッシュをブロッキング プリロード ヒントに置き換えて、低遅延ライブ ブロードキャストが HLS のビット レート スイッチング、FairPlay、fMP4 CMAF、CDN 拡張機能を維持できるようにします。
主要内容
ライブ ビデオを実行する場合、遅延は通常、単純な問題によって発生します。クライアントは新しいメディア クリップが表示されるまで待機する必要があり、サーバーと CDN はそれをエッジ ノードに送信する必要があり、プレーヤーはリクエストを再度開始する必要があります。 2019 年の低遅延 HLS は方向性を示していますが、プレイリストの更新時に新しいクリップをクライアントにプッシュするのは HTTP/2 プッシュに依存しています。今年 Apple が受け取ったフィードバックは明らかでした。多くのコンテンツ配信リンクはプッシュに適しておらず、広告でサポートされているコンテンツは特にアクセスが困難です。
このセッションの焦点は、低遅延 HLS を展開可能なプロトコルに変えることです。 2020 年にベータ版がリリースされ、その年に iOS 14、tvOS 14、macOS に搭載されました。当初特別な資格が必要だった実験的な機能は、ネイティブ アプリで直接使用できる HLS 機能になり、コード レートの切り替え、FairPlay ストリーミング、fMP4 CMAF などの既存の機能も引き続きサポートされます。
プロトコル レベルでの主な変更点は、HTTP/2 プッシュをブロッキング プリロード ヒントに置き換えることです。クライアントは事前に次の部分をリクエストし、サーバーはコンテンツの準備ができるまで待ってから戻ります。リクエストはクライアントによって開始され、CDN エッジ ノードはプッシュのためにエッジ ノードとオリジン サイト間の余分なラウンド トリップを必要とせずに、キャッシュ フィルを簡単にトリガーできます。ライブ ブロードキャスト プラットフォームの場合、この変更により、低遅延機能が共通の CDN モデルに戻ります。
Apple は同時にプレイリスト更新モデルも強化しました。レンディション レポートは、オンデマンド コマンドによって個別に選択されることはなくなりましたが、同じ更新に対して多数の異なる URL が生成されるのを避けるために、プレイリストの更新ごとに実行されます。デルタ アップデートでは、リスト全体を再送信することなく、最新の日付範囲のタグ、長い DVR ウィンドウ、および高密度のメタデータを伝送できます。パートおよびレンディション レポートにはギャップ シグナリングが追加され、クライアントがエンコードの中断をより適切に処理できるようになりました。
詳細
低遅延 HLS ベータ版の終了
(00:17) Roger Pantos は展開の結論で始まりました。低遅延 HLS はベータ版を終了し、同年 iOS 14、tvOS 14、macOS で利用可能になります。これは、HLS プロトコルの一連の低遅延拡張機能に属しています。目標は、既存のプレーヤー スタックを置き換えるのではなく、ストリーム遅延を 2 秒未満にして HLS エコシステムを使い続けることです。
Low-Latency HLS availability
- iOS 14
- tvOS 14
- macOS in 2020
Supported HLS features
- bit-rate switching
- FairPlay Streaming
- fMP4 CMAF
- native application playback
- no entitlement required
キーポイント:
iOS 14、tvOS 14、macOS in 2020利用可能なプラットフォームは、このプレゼンテーションに明確にリストされています。 -bit-rate switching低遅延ライブ ブロードキャストがマルチビットレート適応機能を保持していることを示します。 -FairPlay Streaming保護されたコンテンツは DRM (デジタル著作権管理) を放棄する必要がないことを説明します。 -fMP4 CMAFコンテンツ制作リンクが断片化された MP4 および CMAF (Common Media Application Format) を引き続き使用できるようにします。 -no entitlement required2019 年に試用しきい値が削除され、通常のネイティブ アプリがアクセスできるようになります。
仕様が HLS RFC ドラフトに入る
(00:45) 低遅延 HLS のルールが、ietf.org の HLS RFC の第 2 改訂草案に追加されました。 Apple はまた、低遅延サーバー構成プロファイルと CDN チューニング アルゴリズムという 2 つの付録も追加しました。開発者はアドホック ベータ ページを見るだけでなく、HLS 仕様および Apple のオーサリング仕様に従ってデバイスのサポートを確認できます。
HLS RFC second revision draft
- Low-Latency protocol rules
- Low-Latency Server Configuration Profile appendix
- CDN tune-in algorithm appendix
Apple developer documentation
- HLS authoring specification
- Apple device support information
キーポイント:
Low-Latency protocol rulesドラフト HLS RFC の入力は、これらのルールがコア HLS 仕様の一部となることを意味します。 -Server Configuration Profileサーバー側の構成は、オリジン、パッケージャー、CDN が同じ制約セットに従って動作するのに役立ちます。 -CDN tune-in algorithmライブ ストリームに入るときにクライアントがどのように CDN と連携してブロードキャスト パスでの待機を短縮するかを説明します。 -HLS authoring specificationサポートされている Apple デバイスの範囲を確認するためのエントリ ポイントです。
ブロッキング プリロード ヒントが HTTP/2 プッシュを置き換えます
(01:41) セグメント遅延を削減するために、元の低遅延設計では HTTP/2 プッシュを使用して、プレイリストの更新とともに新しいセグメントを送信します。フィードバックによると、Push は多くのコンテンツ配信方法には適しておらず、広告でサポートされる多くのストリームにも適していないことが示されています。新しいアプローチは、ブロッキング プリロード ヒントと呼ばれます。クライアントは事前に次の部分を要求し、サーバーはそれが利用可能になった後に戻ります。
Old delivery path
1. Server creates a new segment.
2. Playlist update becomes available.
3. HTTP/2 Push sends the segment with that playlist update.
Updated delivery path
1. Client asks for the next part before it is ready.
2. Server holds the request.
3. Server responds when the part is ready.
4. The client-driven request triggers CDN cache fill.
キーポイント:
Old delivery pathHTTP/2 プッシュに依存するには、プッシュ動作をサポートする CDN とサーバー リンクが必要です。 -Client asks for the next part before it is readyこれは、プリロード ヒントのブロックの中心となるアクションです。 -Server holds the requestブロック動作に対応して、サーバーは空の結果をすぐには返しません。 -triggers CDN cache fillApple が強調している CDN フレンドリーな点は、クライアントからリクエストが発行された後にエッジ ノードが自然にキャッシュを埋めることができるということです。- 音声では引き続き CDN が HTTP/2 をサポートする必要がありますが、CDN がプッシュをサポートする必要はなくなりました。
レンディション レポートは、代わりにプレイリストの更新とともに配布されます。
(03:13) CDN チームは、クライアントが特定のレンディション レポートをリクエストできる場合、同じプレイリストの更新が多数の異なる URL に対応すると報告しました。 URL の組み合わせの数が増えると、キャッシュ ヒット率が低下します。 Apple はレポート配信ディレクティブを削除し、代わりに各プレイリスト更新にすべてのレンディション レポートを含めます。
Before
playlist update + requested rendition report set
=> many URLs for the same update
=> lower CDN cache efficiency
Now
playlist update
=> all Rendition Reports included
=> one cacheable update shape
キーポイント:
requested rendition report setこれは、古いスキームによって引き起こされる URL 組み合わせの肥大化の原因です。 -many URLs for the same updateこれにより、CDN は同じ更新を複数のオブジェクトとしてキャッシュします。 -all Rendition Reports includedより安定したキャッシュ形状と引き換えに、応答本文のサイズを少量犠牲にします。- この変更は、大規模なライブ ブロードキャストの CDN 効率に直接役立ちます。
デルタ更新は日付範囲タグをサポートします
(03:40) 多くのライブ ストリームには長い DVR ウィンドウがあり、番組、コマーシャル、またはイベントのメタデータを表すために日付範囲タグが頻繁に使用されます。完全なプレイリストはますます長くなります。 Apple は、更新に最新の日付範囲タグのみが含まれるように、日付範囲タグの処理メソッドをプレイリスト デルタ アップデートに追加しました。
Long DVR playlist
- old media segments
- current media segments
- many date-range tags
Playlist Delta Update
- recent playlist changes
- the most recent date-range tag
キーポイント:
Long DVR playlist長いルックバック ウィンドウの下で完全なプレイリストを説明します。 -many date-range tagsこれは、メタデータ集約型のストリームにとって一般的な負担です。 -Playlist Delta Update増分のみが送信されるため、クライアントと CDN 間の繰り返し送信が削減されます。 -the most recent date-range tagこの講義からの変更により、増分更新で日付範囲のメタデータを運ぶ問題が解決されます。
ギャップ シグナリングはパートとレンディションのレポートをカバーします
(04:00) 低遅延のライブ ブロードキャストは、エンコードの中断の影響をより受けやすくなります。 Apple は、ギャップ シグナリングを使用してストリーム内のギャップの存在を示す新しい属性を Part タグと Rendition Report タグに追加しました。クライアントは、これらの信号に基づいて利用できないコンテンツをスキップできるため、欠落したセグメントで立ち往生するリスクが軽減されます。
Gap signaling targets
- Part tags
- Rendition Report tags
Client behavior enabled by the signal
- detect encoded outages
- avoid waiting on unavailable low-latency parts
- continue recovery using rendition information
キーポイント:
Part tags低遅延ストリームの部分セグメント レベルに相当します。 -Rendition Report tags異なるレンディション間の同期情報に相当します。 -encoded outagesスピーチの中で明示的に言及された失敗シナリオです。 -continue recovery using rendition informationギャップ信号の値を指定して、エラーをログに記録するだけでなく、クライアント側でパスを復元します。
HLS ツールチェーンとリファレンス サーバーの更新
(04:17) Apple は、低遅延サーバーのリファレンス実装を更新しました。昨年のツール セットは、低遅延ストリームを生成できます。 2020 バージョンでは、断片化された MPEG-4 パッケージが追加され、出力が CMAF と互換性を持つようになります。 Web サーバーの設定も簡素化されています。以前は、独自の Web サーバーを構成してから、PHP スクリプトを接続する必要がありました。これで、Go スクリプトを実行し、配信ディレクティブと HTTP/2 Web サーバーを同時に実装できるようになりました。
Updated Low-Latency HLS tools
- fragmented MPEG-4 packaging for CMAF compatibility
- Go script for delivery directives
- HTTP/2 web server in the same package
- included in the regular HLS tools download
キーポイント:
fragmented MPEG-4 packaging2019 年後半にスピーチで追加されたオプションに対応します。 -CMAF compatibility同じメディア パッケージが標準化された配布リンクに簡単に入力できるようにします。 -Go script参照サーバーをローカルに構築する手順を削減します。 -delivery directivesそしてHTTP/2 web serverこれらを同じパッケージに入れると、開発者が実験フローを再現しやすくなります。 -regular HLS tools download低遅延ツールが統合ダウンロード エントランスに戻ることを示します。
重要ポイント
-
低遅延のライブ スポーツ プレーヤーを作成
- 対処法: ライブ ブロードキャスト画面の横にスコア、弾幕、またはリアルタイム統計を重ねて表示し、画面とインタラクティブ データをほぼ同期させます。
- 実行する価値がある理由: 低遅延 HLS は、ストリーム遅延を 2 秒未満にすることを目標にしており、ビットレートの切り替えと FairPlay ストリーミングを維持します。
- 開始方法: まず、HLS ツールを使用して低遅延ストリームを生成し、次にプレーヤー側で iOS 14、tvOS 14、macOS の再生パスを確認します。
-
CDN の原点回帰効率監視パネルを作成
- 内容: プレイリストの更新、レンディション レポート、パーツ リクエスト、CDN キャッシュ フィル ヒットを監視します。
- 実行する価値がある理由: プリロード ヒントのブロックはリクエストを開始するクライアントに変更され、Apple はそれが CDN キャッシュ フィルをトリガーする可能性があることを明確に指摘しています。
- 開始方法: オリジンと CDN ログのプレイリスト更新、パーツ URI、レンディション ディメンションごとにリクエストを集約し、同じ更新によって生成される URL のバリエーションが多すぎるかどうかを観察することに重点を置きます。
-
長時間の DVR ライブ ブロードキャスト メタデータ検証ツールを作成する
- 対処方法: 長いルックバック ウィンドウで日付範囲タグを確認し、最近の変更のみがプレイリスト デルタ更新に渡されているかどうかを確認します。
- 実行する価値がある理由: 講演では、多数の日付範囲タグが長い DVR ウィンドウに影響を与えると述べており、2020 年の合意では関連する処理がデルタ アップデートに追加されました。
- 開始方法: HLS プレイリスト パーサーを使用して完全なプレイリストとデルタ プレイリストを読み取り、最新の日付範囲タグが増分更新に表示されることを確認します。
-
低遅延ストリームの障害回復テスト ストリームを作成
- 何をすべきか: コーディング ギャップを人為的に作成し、パートとレンディション レポートのギャップ シグナリングに従ってプレーヤーが再生を継続できるかどうかを観察します。
- 実行する価値がある理由: Apple は、エンコードされた停止を処理するために、パート タグとレンディション レポート タグにギャップ シグナリングを追加します。
- 開始方法: 複数のレンディション ライブ ストリームを準備し、一部の出力にギャップを作成し、プレーヤーの待機時間、切り替え時間、再開時間を記録します。
-
低遅延の HLS ローカル実験環境を作成します
- 対処方法: 更新された HLS ツールを使用して、ローカル オリジンを迅速に構築し、fMP4 CMAF 互換の低遅延ストリームを生成します。
- 実行する価値がある理由: リファレンス実装では、配信ディレクティブと HTTP/2 Web サーバーが Go スクリプトに統合されており、構築コストが古い PHP ソリューションよりも低くなります。
- 開始方法: 通常の HLS ツール パッケージをダウンロードし、その中の低遅延ツールを使用して断片化された MPEG-4 コンテンツを生成し、リファレンス サーバーを介してクライアントのリクエスト リズムをテストします。
関連セッション
- HLS ブロッキング プリロード ヒントの発見 - 事前に次の部分をリクエストするクライアントと、サーバーのブロック、待機、復帰の実装の詳細について引き続き説明します。
- HLS Blocking Playlist Reload による遅延の削減 — プレイリストのリロードにより、クライアントが新しいセグメントを検出するまでの待ち時間がどのように短縮されるかについて説明します。
- HLS プレイリスト デルタ更新によるライブ ストリームの最適化 — 長い DVR ウィンドウと大量のメタデータを含むシナリオでのプレイリストの増分更新について説明します。
- 広告挿入を低遅延 HLS に適応させる — サーバー側の広告挿入がどのように低遅延 HLS に適応するかについて説明します。
- HLS ツールによるストリーム オーサリングの改善 - HLS ツール チェーンがライブ ストリームとオンデマンド ストリームを生成、検査、改善する方法について説明します。
コメント
GitHub Issues · utterances