CMAF Ingest

DASH-IF Live Media Ingest Protocol Interface-1 / シーマフインジェスト

ライブエンコーダーからパッケージャーへ、CMAFのチャンクをHTTP POSTで押し込む取り込みの取り決めです。DASH-IFがLive Media Ingest Protocolとして仕様化し、エンコーダーとパッケージャーを別メーカーで組み合わせられるようにしました。

仕様名
DASH-IF Live Media Ingest Protocol(Interface-1がCMAF Ingest)
策定
DASH Industry Forum(DASH-IF)
送る中身
CMAFのトラック(fMP4のヘッダーに続いてフラグメントを連ねたもの)
使うHTTPメソッド
HTTP/1.1のPOSTまたはPUT
長さが決まらない配信
chunked transfer encodingで送り続けられる
Interface-2
パッケージ済みのDASH・HLS一式をストレージやCDNへ押し込む取り決め
土台の規格
ISO/IEC 23000-19(CMAF)

エンコーダーとパッケージャーを別のメーカーでそろえると、まず引っかかるのが「どうやって渡すか」です。RTMPでは複数の画質段や字幕を一度に運びにくく、メーカーごとの独自のプッシュ方式では組み合わせが固定されてしまいます。CMAF Ingestは、この受け渡しをHTTP POSTに統一するための取り決めです。

CMAF Ingestが使われる場面

クラウドのライブ配信では、圧縮するところとマニフェストを作るところを分けるのが一般的な構成になっています。エンコーダーが画質段ごとのCMAFトラックを作り、パッケージャーが受け取ってHLSとMPEG-DASHのマニフェストを組み立て、DRMの暗号化を掛けます。この間をつなぐのがCMAF Ingestです。

オンプレミスのエンコーダーからクラウドのパッケージャーへ上げる構成でも使われます。HTTPなので途中のファイアウォールやプロキシを通しやすく、HTTPSにすればそのまま暗号化されます。冗長化も素直で、同じストリームを2台のエンコーダーから2つの取り込みURLへ送り、受け側で同じセグメントとして扱う構成がよく取られます。

24時間編成のチャンネルを運用する場面では、エンコーダーを更新しても取り込みの形が変わらないことが効いてきます。パッケージャー側の設定を作り直さずに、送り手だけ差し替えられます。

CMAF Ingestの仕組み

DASH-IFのLive Media Ingest Protocolは、取り込みの形を2つの面に分けています。Interface-1がCMAF Ingestで、エンコーダーからパッケージャーへ加工前のトラックを渡す面です。Interface-2はパッケージ済みのDASHやHLSの一式をストレージやCDNへ押し込む面で、受け側は中身に手を入れません。

Interface-1の流れは次の通りです。

  • エンコーダーは画質段ごと、音声ごと、字幕ごとに別のトラックとして、それぞれのURLへPOSTを開く
  • 最初にfMP4のヘッダー(ftypとmoov)を送り、続いてフラグメント(moofとmdat)を連ねて送り続ける
  • 長さが事前に決まらないので、chunked transfer encodingで1本のPOSTを開いたまま流す方法が使える
  • 低遅延の配信では、セグメントをさらに小さなチャンクに割って送る
  • TCPが切れたら、エンコーダーは同じURLに対して新しい接続を張り直す

ヘッドオブラインブロッキングを避けるために、トラックごとに別の接続を並列で張るのが推奨されています。接続が止まったときの扱いも仕様に書かれていて、セグメントの長さに比べて送信が滞ったら接続を閉じて張り直します。エラーの応答についても、400や415のように送り手側を直す必要があるものと、5xxのように再送すべきものが区別されています。

CMAF Ingestの設定で間違えやすい点

  • POSTのURLの組み立て規則が送り手と受け手でずれ、トラックが別のストリームとして登録される
  • 画質段ごとのセグメントの切れ目がそろっておらず、ABRの切り替えで再生が止まる。エンコーダー側でIDRの位置をそろえる設定が要る
  • 音声と映像でタイムスタンプの基準が違い、パッケージャーが同じプレゼンテーションとして束ねられない
  • 冗長構成で2台のエンコーダーを使うとき、両者のセグメントの時刻が一致していないと受け側が二重のストリームとして扱う
  • chunked transfer encodingを途中のプロキシが解いてしまい、低遅延のチャンク送出が効かなくなる

よくある質問

CMAF IngestとRTMPはどちらを使うべきですか

配信サイトへ1本のストリームを上げるだけならRTMPで足りますが、複数の画質段や多言語の音声、字幕をまとめて渡し、パッケージャー側でDRMやマニフェストを作る構成ならCMAF Ingestが向きます。H.265やAV1のように、RTMPでは扱いが定まっていないコーデックを運ぶ場合も理由になります。

CMAF IngestはCMAFでしか使えませんか

Interface-1で運ぶのはCMAFの条件に沿ったfMP4のトラックです。パッケージャーはそれを受けてから、出力としてTSセグメントのHLSを作ることもできます。取り込みの形と出力の形は別に決められます。

CMAF Ingestに対応した製品はどうやって確認しますか

エンコーダー側は「CMAF ingest出力」や「DASH-IF live ingest」といった名前で書かれます。受け側はパッケージャーやオリジンサービスの入力形式の欄を見ます。同じCMAF Ingestでも対応している範囲は製品ごとに違うので、字幕トラックや低遅延のチャンク送出が要る場合は、その項目まで確認しておくと安全です。

この用語を扱ったコラム

似ている形式との違い

名前主に使う場面CMAF Ingestとの違い
CMAF配信セグメントの形式CMAFはセグメントの中身の規格。CMAF Ingestはそれをどうやってパッケージャーへ渡すかという通信の取り決め
RTMP配信サイトへのライブ送信1本のストリームを押し込む古くからの方法。H.264とAACに実質限られ、複数の画質段や字幕を一度に運びにくい
SRT拠点間のライブ伝送損失のある回線でTSを届けるための伝送プロトコル。取り込む先はエンコーダーやデコーダーで、パッケージャーへの取り込みとは層が違う

関連する用語

最終更新