「録画できた」を、MP4ファイルが保存された状態だと思っていた
クラウド録画を考え始めたころ、私は録画を「動画ファイルを作って保存する処理」として捉えていました。ローカルの録画装置では自然な考え方です。
Amazon Kinesis Video Streams（KVS）では、カメラから届いた映像は、最初から利用者向けのMP4ファイルとして並ぶわけではありません。Producerはフレームを送り、KVSではフラグメント単位で扱われます。再生やファイル取得では、目的に応じたAPIや再生方式を選びます。
既存IPカメラをKVSへつなぐPoCでは、コンソールで映像を確認するところまで進みました。しかし、最終的に独自ビュワーとして提供するなら、「コンソールでは映るのにファイルとして取れない」「指定時刻の映像がずれる」「再接続後だけ再生できない」といった現象を別々に扱う必要があります。
独自ビュワーの要件まで考えると、「KVSコンソールで再生できること」と「指定時間帯をGetClipでMP4として取得できること」は同じ合格条件ではありません。ローカル録画装置のファイル感覚をそのまま持ち込むと、この境界を見落とします。
この記事では、フレーム、フラグメント、チャンク、時刻、再生APIの関係を整理します。
読者と前提
- 対象読者：KVSへ映像を送り始めたが、保存と再生の境界が分かりにくい人
- 前提知識：H.264、キーフレーム、HTTP APIの概要
- 経験時点：筆者は2021年にUSBカメラの送信と、既存IPカメラ製品をKVSへ接続するPoC、コンソール再生を確認。独自ビュワーは要求設計まで
- 2026年時点の補足：データモデルとAPI仕様はAWSの現行Developer Guideで確認
- 扱わない範囲：MKVバイナリ構造の詳細、プレイヤー実装、料金試算
フレームをまとめた単位がフラグメントになる
フレームは、動画を構成する個々の画像です。ただし、圧縮動画ではすべてのフレームを単独で復号できるとは限りません。
KVSのProducer APIでは、フレームをまとめた自己完結したシーケンスをフラグメントとして送ります。AWSの現行資料では、フラグメントに含まれるフレームは、別のフラグメントのフレームへ依存しないことが求められています。
Producer SDKの設定では、キーフレームを契機に新しいフラグメントを開始できます。フラグメント境界とキーフレームの関係が崩れると、後から切り出した映像を復号しにくくなります。
KVSから返るのは用途別に同じ形ではない
KVSへ保存された映像を使う方法は一つではありません。
| 目的 | 主な方法 | 受け取るもの |
|---|---|---|
| 低遅延で独自処理する | GetMedia |
MKV形式のチャンクストリーム |
| ブラウザ等でライブ／保存映像を見る | HLS、MPEG-DASH | 再生セッションURL |
| 指定時間帯をファイル取得する | GetClip |
MP4クリップ |
| フレーム単位で解析する | Parser Library等 | MKV内のフレームデータ（映像化には別途デコード） |
GetMediaで取得できるものを、そのまま完成済みのMP4ファイルと考えないことが大切です。独自処理では、チャンクからフラグメントやフレームを取り出す処理が必要になります。
一方、GetClipは保存済みのオンデマンド映像から、指定時間範囲のMP4クリップを取得するAPIです。データ保持期間が0より大きいこと、各フラグメントの映像トラックに有効なCodec Private Dataが含まれ、指定区間内でその内容とトラック構成が変わらないことなどの成立条件があります。
二つの時刻を混ぜない
KVSはフラグメントに、Producer側の時刻とサーバー側の時刻を保持します。
- Producer timestamp：Producerがフラグメントへ付与した時刻
- Server timestamp：KVSがフラグメントを受信した時刻
通常運用では近い値に見えても、端末時計のずれ、ネットワーク断、バッファリング、再送が入ると意味が変わります。
例えば「10時に起きた現象を探す」という要求でも、カメラが記録した10時なのか、クラウドが受信した10時なのかを決めなければ、検索結果を一意に説明できません。
PoCでは、次を記録します。
- 端末の時計と同期状態
- Producer timestamp
- Server timestamp
- 切断開始と復旧時刻
- 再接続時に送られた映像の範囲
当時は回線断と再接続を使った時刻差の測定までは行っていません。ここで示しているのは、独自ビュワーを設計するなら分けて記録すべき観測項目です。
コンソールで映っても、独自ビュワーの完成ではない
KVSコンソールで映像が見えたとき、次の要素はある程度つながっています。
- ProducerからKVSへ映像が届いている
- KVSが対象ストリームを認識している
- コンソールが扱えるコーデック条件を満たしている
- 再生対象に利用できるフラグメントがある
しかし、それだけでは次を確認できません。
- 任意の時間範囲を
GetClipで取得できる - 長時間運用後もトラック構成が一貫している
- 再接続後のフラグメントを連続再生できる
- Producer時刻で正しい映像を検索できる
- 複数のConsumerが必要な速度で読み出せる
コンソール再生は、独自ビュワーの合格証拠ではない
コンソールで映像が見えたことは、送信からコンソール再生までの経路を確認した証拠です。HLS、GetMedia、GetClipは、利用目的ごとに別の合格条件と証拠を用意します。
再生できないときは取り込みから順に見る
再生に失敗したとき、次の順で確認します。
-
PutMedia.IncomingFramesとPutMedia.IncomingFragmentsが増えているか - 対象時間帯にフラグメントが存在するか
- Producer／Serverのどちらの時刻を使っているか
- H.264等のトラック情報が途中で変わっていないか
- キーフレームとフラグメント境界が適切か
- HLS、
GetMedia、GetClipのどの経路で失敗しているか
この順序なら、ファイル取得の問題をカメラ接続の問題へ戻して調べ続けることを避けられます。
録画の要件は「ファイル形式」だけでは決まらない
クラウド録画の要件を決めるときは、MP4が必要かという出口だけでなく、次を決めます。
- 何を一つのストリームとするか
- どの時刻を検索基準にするか
- どこまで保持するか
- ライブ再生と保存再生をどう分けるか
- フレーム解析を行うか
- 回線断中の映像をどう扱うか
この設計が決まると、Producer SDK、HLS、GetMedia、GetClipの役割も決めやすくなります。