初めに

WWDC 2020 で Apple Low Latency HLS が GA してから、はや 2 年。
あまりサポートしているという情報をきかず、Appleのツールでしか確認できてませんでした。
LDASH (CMAF-ULL) はよく聞きますが、LL-HLS の話は全然されてません。

実際にどのようにプレイリストを作るのか分かれば、自分で使えるかも?
というわけで、週末の時間を使って作ってみました。

前提

コミュニティベースで生まれた規格で、CMAF-ULL との互換のある規格です。

EXT-X-PREFETCH タグによる、プリロード対象を Chunked transfer で読むという方法で
低遅延を実現しており、Appleを対象としてない、独自の低遅延HLSはコレです。

Apple が提唱している低遅延HLS の規格となります。
2020 年に beta が取れて、Apple 製のプレイヤーでは受けられるようになっています。

特徴は以下の通りです。

要するに、今までの 1 セグメントを分割可能になり、分割した単位で更新が可能で
プレイリストがアップデートされるまで、リクエストをロングポーリング可能になった
というものになります。

これらをオリジンが実装する必要があり、上記の LHLS のような単純なものではないのが欠点です。

ここでは、ライブ再生に必要な以下の 3 つをサポートしてみます。

実際に作ってみたのが、以下のリポリトジになります

python 製のツールで、標準入力で受け取ると、HTTPサーバになり
オンメモリで /playlist.m3u8 にプレイリストを出力します。

一応、以前に node.js 製で作ったものを移植した形です。
node.js でも、Python でもやっていることは同じですので、好きな方をみてください

やっていることは超単純で、TS をデマックスして、キーフレームでセグメント分割します。

実際に LAN 内で通信したところ、delta update と bloking request により
従来の TARGETDURATION より高い頻度で更新が出来ている事が確認できました。

遅延も 1 秒までは Apple のプレイヤーでは抑える事が出来そうです。
1 秒はプレイヤーが強制的にバッファするためになります。

なかなかルールが分からず、mediastreamvalidator のお世話になりました。
Safari でエラー表示してくれればよいのですが...

LHLS の方が、オリジン, ストレージ, CDN が chunked-transfer をサポートすれば
楽にスケールするため、あまり乗り気ではないというのが、現状なのかなと思いました。

CMAF-ULL を考えると Apple を無視して LHLS にするのが得策なのかもしれないですね。