録画 | SENCA ドキュメント

配信と録画

このページの見出し

仕組み
録画の状態とフィールド
自動録画（配信開始で録画を始める）
手動で開始・停止する
一覧・取得・変更・削除
VOD の再生（HLS）
MP4 のエクスポート
サムネイル
再接続と不連続
中断と復旧
保持期限
予約（スケジュール）
録画の保存先（S3 互換のオブジェクトストレージ）
関連するページ

録画したものは、VOD（録画をあとから見る配信）として再生したり、MP4 や HLS としてエクスポートしたりできます。後半では、決まった時刻に録画を始める予約（スケジュール）と、録画を S3 互換のオブジェクトストレージに置く方法を扱います。たとえば「毎週月曜と水曜の講義を録画し、その時間帯以外の配信は断る」といった運用ができます。

例で使う API・TOKEN・H は、取り込みと再生と同じです。

仕組み

録画は、ライブの HLS と同じセグメントをそのまま保存したものです。録画のために多重化し直すことはなく、コンテナー形式もストリームの hls.container（TS か fMP4）と同じになります。区切りの単位もセグメントで、録画を始めたときに作成中だったセグメントから、停止した時刻を含むセグメントまでが入ります。

セグメントをファイルに書き出すのは、録画中のストリームがあるときだけです。置き場所は {data-dir}/segments/{stream}/{run}/ で、一時的な名前で書いて fsync してから本来の名前に変え、その後は二度と変更しません。同じ時間帯に録画が何本あっても同じファイルを共有するので、ディスクは 1 本分しか使いません。

録画ごとに、追記だけのインデックス {data-dir}/recordings/{id}/index.jsonl があり、各行は begin・init・segment・gap・end のどれかです。セグメントを書き終えてから追記するので、インデックスに載っているセグメントは必ず完全です。

書き込みはライブ配信より後回しです。書き込み待ちのキューがあふれたらセグメントを捨てて gap（queue_overflow）として記録し、ライブ配信のほうは止めません。キューの長さは --record-queue で決まり、既定は 4096、ストリームごとのキューはその 1/64（16〜4096 の範囲）です。

クラスターでは、録画のファイルは録画を作ったノードのディスクにだけあり、ほかのノードには複製しません（クラスターとグリッドを参照）。S3 互換の保存先を設定しておけば、確定した録画がそこへアップロードされ、同じ保存先を設定したどのノードからでも再生・エクスポートができるようになります（下の「録画の保存先」を参照）。

録画の状態とフィールド

`state`	説明
`recording`	録画中です
`finalized`	正常に終わり、確定しています
`interrupted`	ノードの停止や書き込みの失敗などで、途中で止まりました。止まるまでの部分は再生・エクスポートができます

削除している途中の録画（状態は deleting）は、一覧にも取得の結果にも出てきません。

録画のフィールド:

フィールド	説明
`id`・`stream`・`name`・`generation`	録画の ID、元のストリームの ID、名前、更新の世代番号です
`state`	録画の状態です（上の表を参照）
`started_at`・`ended_at`	録画の開始時刻と終了時刻です
`retention_until`	保持期限です。`null` は無期限です
`legal_hold`	法的保全（legal hold）です。`true` の間は、削除も、期限切れによる自動の削除も行いません
`schedule`	予約によって作られた録画の場合に、その予約の ID が入ります
`duration_ms`・`segments`・`bytes`	録画の長さ、セグメントの数、合計の大きさです。インデックスから集計します
`gaps`	欠落の一覧 `[{at, reason, dropped}]` です。`reason` は `publisher_reconnect`（配信者の再接続）か `queue_overflow`（書き込みが追いつかなかった）です。録画中でも、欠落が起きた時点で反映されます
`thumbnail`	サムネイルがあるかどうかです
`storage`	保存先へのアップロードが終わっていれば `{"uri": "s3://…", "archived_at": "…"}`、まだなら `null` です（下の「録画の保存先」を参照）

自動録画（配信開始で録画を始める）

ストリームの recording.enabled を true にしておくと、配信者が接続した時点で録画が始まり、1 回の配信が 1 本の録画になります。desired_state が stopped のストリームでは始まりません。

再接続の猶予時間（--reconnect-grace、既定 30 秒）の中で配信者が戻れば、録画は同じ 1 本のまま続きます（下の「再接続と不連続」を参照）。猶予時間が過ぎて配信が終わると録画は finalized になり、次の接続では新しい録画が作られます。

何日残すかは recording.retention_days で決めます。retention_until は開始時刻にこの日数を足した日時です。

自動で録画して 30 日間残すストリームを作る例です。

curl -s -X POST "$API/streams" "${H[@]}" -d '{"name":"lecture","recording":{"enabled":true,"retention_days":30}}'

手動で開始・停止する

自動録画を使わず、API で好きなときに始めたり止めたりもできます。

# 開始する（本文は省略できます）
curl -s -X POST "$API/streams/$SID/recordings" "${H[@]}" -d '{"name":"manual-1","retention_days":30}'
# 停止する
curl -s -X POST "$API/recordings/$RID/stop" "${H[@]}"

操作	リクエスト	権限	結果
開始	`POST /streams/{id}/recordings` `{name?, retention_days?}`	`stream:write`	202 と録画（`state: recording`）、`Location` ヘッダー
停止	`POST /recordings/{id}/stop`	`stream:write`	202。録画中でない場合は 409 を返します

retention_days は 1〜36500 です。配信者がまだ来ていなくても開始でき、その場合は配信者が接続してからのセグメントが記録されます。ストリームが stopped なら 409 です。同じストリームで同時に動かせる録画は、自動・手動・予約を合わせて 8 本までで、超えると 403 QUOTA_EXCEEDED になります。

停止の処理は応答を返したあとで進むので、応答の時点ではまだ state が recording のこともあります。確定したかどうかは GET /recordings/{id} で確かめてください。なお、配信が終わる（猶予時間が過ぎる）と、手動で始めた録画も一緒に確定します。

一覧・取得・変更・削除

操作	リクエスト	権限
一覧	`GET /recordings?stream={id}&state={recording\|finalized\|interrupted}&limit&cursor`	`recording:read`
取得	`GET /recordings/{id}`	`recording:read`
変更	`PATCH /recordings/{id}` `{retention_until?, legal_hold?, name?}`（`If-Match` が必須）	`stream:write`
削除	`DELETE /recordings/{id}`	`recording:delete`

retention_until には RFC 3339 の日時か null（無期限）を、name には 128 文字までの文字列を指定します。legal_hold を true から false に戻すには、recording:delete の権限も要ります。

削除を送ると 202 {"id": "...", "state": "deleting"} が返ります。録画中なら止めてから消し、法的保全中なら 409 で断ります。セグメントは、ほかの録画が使っていればそのまま残し、どのインデックスからも参照されなくなったものだけを消します。

録画を法的保全の対象にして、保持期限をなくす例です。

ETAG=$(curl -s -D - -o /dev/null "$API/recordings/$RID" -H "Authorization: Bearer $TOKEN" | awk -F': ' 'tolower($1)=="etag"{print $2}' | tr -d '\r')
curl -s -X PATCH "$API/recordings/$RID" "${H[@]}" -H "If-Match: $ETAG" -d '{"legal_hold":true,"retention_until":null}'

VOD の再生（HLS）

録画を HLS で再生するには、ライブと同じように署名付きの URL を発行します。権限は recording:read です。

curl -s -X POST "$API/recordings/$RID/playback-url" "${H[@]}" -d '{"ttl_secs":3600}'

{"expires_at":"2026-11-03T02:23:37Z",
 "playback":{"hls":"http://127.0.0.1:24080/s/1793669017/hMRgjzJPEFVV0OgLFjdkww/vod/b8bc7a7d6b9ff6df2639d7c07d22177f/index.m3u8","mp4":null}}

ttl_secs の決まりはライブと同じで、既定 300 秒、上限は --max-playback-ttl です。応答の mp4 は今のところ常に null なので、MP4 が欲しいときは下の「MP4 のエクスポート」を使ってください。

プレイリストには #EXT-X-PLAYLIST-TYPE:VOD と #EXT-X-ENDLIST が付きます。録画中に開くと EVENT になり、ENDLIST のないまま伸びていきます。セグメントの名前は {epoch}-{sequence}.ts（fMP4 では .m4s と init.mp4）で、Range（1 区間だけ）に対応し、Cache-Control: max-age=3600 が付きます。配信者が再接続したところには #EXT-X-DISCONTINUITY が入ります（下の「再接続と不連続」を参照）。

プレイリストの例（猶予時間の中で 1 回再接続した録画）:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-INDEPENDENT-SEGMENTS
#EXTINF:2.000,
0-0.ts
#EXTINF:2.000,
0-1.ts
#EXTINF:2.000,
1-2.ts
#EXT-X-DISCONTINUITY
#EXTINF:2.000,
1-3.ts
…
#EXT-X-ENDLIST

HLS のまま持ち出したいなら、VOD のプレイリストとセグメントがそのまま使えます。1 つのファイルにまとめるときは、ffmpeg -i "$VOD_URL" -c copy out.ts のように再エンコードせずに取り出してください。

クラスターで、録画を持っていないノードに VOD のリクエストが来ると、録画を作ったノードへ 307 でリダイレクトします。保存先にアップロード済みの録画ならリダイレクトはせず、受けたノードが保存先から読んで返します。

MP4 のエクスポート

録画を 1 つの MP4 ファイルとしてダウンロードできます。権限は recording:read です。

curl -s -o rec.mp4 "$API/recordings/$RID/export.mp4" -H "Authorization: Bearer $TOKEN"

応答には Content-Type: video/mp4 と Content-Disposition: attachment; filename="{id}.mp4" が付きます。再エンコードはせず、セグメントをばらして先頭に moov を置いた MP4 に組み立て直します。組み立てはメモリの上で行うので、セグメントの合計が 4 GiB を超える録画はエクスポートできません（413 PAYLOAD_TOO_LARGE）。録画中のものと中身が空のものは 409 です。

再接続で時刻が飛んだ区間は、前の区間の終わりに詰めてつなぎ、空白の時間は入れません。予約による録画は、予約の開始・終了の時刻（インデックスの not_before_ms・not_after_ms）で切り出し、開始位置は直前のキーフレームまでさかのぼります。予約の前後に広げた部分（pre-roll・post-roll）は VOD には残りますが、MP4 には入りません。

クラスターでは、保存先にアップロード済みの録画ならどのノードの API からでもエクスポートできます。まだのものは、録画を作ったノードの API に要求してください。保存先がある録画では、録画全体のエクスポートを最初に作ったときに保存先にも置き、次からはそれを返します。start・end を指定したエクスポートは毎回組み立てます。

範囲を指定してエクスポートする

start と end（RFC 3339 の時刻）を付けると、その範囲だけをエクスポートします。たとえば 1 時間の講義から最初の 10 分だけを切り出す、といった使い方です。予約による録画では、予約の範囲と重なる部分が対象になります。再エンコードしないので、開始位置は直前のキーフレームまでさかのぼります。

時刻は実際の時刻（壁時計）で指定します。位置はセグメントごとの開始時刻から求めるので、再接続で詰めた区間をまたいでもずれません。

curl -s -o part.mp4 "$API/recordings/$RID/export.mp4?start=2026-11-04T01:00:00Z&end=2026-11-04T01:10:00Z" -H "Authorization: Bearer $TOKEN"

時刻の書き方が誤っている、end が start と同じかそれより前、start・end 以外のクエリがある、のどれかなら 400 です。範囲の中に録画がなければ 409 になります。

サムネイル

録画が確定すると、録画の中から等間隔に最大 12 枚のキーフレームをデコードし、真っ黒・真っ白・変化のない画面・ぶれた画面を避けて 1 枚を選びます。

curl -s -o thumb.jpg "$API/recordings/$RID/thumbnail" -H "Authorization: Bearer $TOKEN"

サムネイルを作るにはデコードが必要です。H.264/H.265 の録画では、GPU のデコーダーがなければ作られません（コーデックと特許を参照）。その場合、録画の thumbnail は false で、取得しようとすると 404 が返ります。保存先にアップロード済みの録画なら、どのノードからでも取得できます。

再接続と不連続

配信者の接続が切れ、猶予時間の中で同じキーで戻ってきた場合（プロトコルは前と違ってもかまいません）、録画は次のように扱われます。

ストリームの epoch が 1 増えます。
録画のインデックスに gap（reason: publisher_reconnect）を追記し、続くセグメントに不連続の印を付けます。
VOD のプレイリストには #EXT-X-DISCONTINUITY が入ります。録画は 1 本のまま続きます。
MP4 のエクスポートでは、区間の間を詰めてつなぎます。

猶予時間を過ぎてからの再接続は別の配信になり、自動録画なら新しい録画が始まります。ただし予約による録画は例外で、予約の時間帯の中であれば同じ録画に続けて記録します。欠落と不連続の記録は上と同じです（下の「予約（スケジュール）」を参照）。

中断と復旧

強制終了や停電で録画の途中にノードが止まっても、それまでの分は失われません。次の起動時に復旧の処理が走り、録画は interrupted として閉じられます。終了時刻は最後のセグメントの終わりで、そこまでは再生もエクスポートもできます。

具体的には、end の行がないインデックスの書きかけの最後の行を切り捨て、end（interrupted）を追記します。状態が recording のままでインデックスがない録画も interrupted にします。どのインデックスからも参照されていないセグメントは、消さずに segments/{stream}/orphans/{run}/ へ移します。読み込めないインデックスがあれば、その録画には手を付けず、セグメントの移動も行いません。

起動時に各セグメントの SHA-256 をインデックスと照合したいときは --verify-recordings を付けます。一致しないものはログに出ます。ノードが動いている間にディスクへの書き込みに失敗した録画も、interrupted になります。

ログの例（録画中に kill -9 で止め、再起動した場合）:

recovery: recording b0316a943b097502b1c041ea3810a5a5 closed as interrupted (3 segments)

保持期限

--retention-sweep の間隔（既定 60 秒）ごとに、retention_until を過ぎた finalized・interrupted の録画を削除します。legal_hold が true のものは残します。

保持期限のもとになる値は、録画の始め方で違います。あとから PATCH で変えることもできます。

自動録画: ストリームの recording.retention_days
手動の録画: 開始するときに指定した retention_days
予約による録画: 予約の retention_days

保存先にアップロードした録画なら、保存先のオブジェクト（セグメント・インデックス・サムネイル・エクスポートしたファイル）も消します。保存先に接続できないときは「削除中」のまま残し、次の定期処理でやり直します。

予約（スケジュール）

予約は、ストリームに時間帯を決めて、その間だけ決まった動作をさせる機能です。動作は action で選びます。

`action`	時間帯の間に行うこと
`record`	録画します。録画の `schedule` に予約の ID が、`name` に予約の名前が入ります
`live`	配信を受け付けます。時間帯の外では、配信を断ります
`snapshot`	`snapshot_interval_secs` 秒ごとに静止画を保存します（`reason` は `schedule`）

毎週月曜と水曜の講義を、日本時間で 30 回分録画する例です。

curl -s -X POST "$API/schedules" "${H[@]}" -d '{
  "stream": "'"$SID"'",
  "name": "monday-wednesday-lecture",
  "action": "record",
  "start_at": "2026-11-04T00:50:00Z",
  "end_at": "2026-11-04T02:30:00Z",
  "pre_roll_ms": 60000,
  "post_roll_ms": 120000,
  "recurrence": {"freq": "weekly", "weekdays": [1, 3], "timezone": "Asia/Tokyo", "count": 30},
  "retention_days": 365
}'

フィールド	既定	制約	説明
`stream`	（必須）	同じテナントのストリーム	対象のストリームの ID です
`name`	なし		予約の名前です。録画の名前にも使います
`action`	（必須）	`record`・`live`・`snapshot`	時間帯の間に行う動作です（上の表を参照）
`start_at`・`end_at`	（必須）	RFC 3339。`end_at` は `start_at` より後で、長さは 24 時間まで。`end_at` が過去であってはいけません	最初の回の時間帯です
`pre_roll_ms`・`post_roll_ms`	0	0〜300000	時間帯の前と後ろに広げる長さ（ミリ秒）です
`grace_ms`	60000	0〜3600000	開始時刻（`start_at - pre_roll_ms`）を過ぎていても、この時間の中であれば途中から実行します。この時間も過ぎた場合、その回は `missed` になります
`snapshot_interval_secs`	なし	`snapshot` のときだけ必須。1〜3600	静止画を保存する間隔（秒）です
`recurrence`	なし	下の表を参照	繰り返しの設定です
`retention_days`	なし		`record` で作った録画を残しておく日数です

recurrence のフィールド:

フィールド	説明
`freq`	繰り返しの単位です。`daily`（毎日）か `weekly`（毎週）を指定します
`weekdays`	`weekly` のときの曜日です（0 が日曜、6 が土曜）。指定すると、その曜日だけ実行します。`start_at` の日も、曜日が合わなければ実行しません。空の場合は、`start_at` の曜日から 7 日ごとに実行します
`timezone`	IANA のタイムゾーン名です（例: `Asia/Tokyo`）。`--zoneinfo`（既定は `/usr/share/zoneinfo`）から情報を読み込みます。`UTC` はいつでも使えます。見つからない場合は 400 を返します
`until_ms`	繰り返しを終える時刻です（UTC のミリ秒）。ちょうどその時刻に始まる回は含みません
`count`	実行する回数の上限です（最大 1000）

2 回目以降も、最初の回の現地時刻（指定したタイムゾーンでの時刻）に始まります。夏時間の切り替えをまたいでも時刻はずれません。夏時間が始まる日のようにその時刻が存在しなければ後ろにずらし、終わる日のように同じ時刻が 2 回あれば早いほうを使います。

同じストリームで同時に動かせる record の予約は、前後に広げた部分も含めて 4 本までです。超えると 409 が返り、details.overlaps に重なっている予約が入ります。予約は 1 つのテナントで 1000 件まで作れます。

予約の確認・参照・変更

操作	リクエスト	権限
作成	`POST /schedules`	`stream:write`
作成前の確認	`POST /schedules/check`（本文は作成と同じ）	`stream:read`
一覧	`GET /schedules?stream=&state=&limit&cursor`	`stream:read`
取得	`GET /schedules/{id}`（`last_run` に直近の回が入ります）	`stream:read`
実行履歴	`GET /schedules/{id}/runs`（直近 100 回）	`stream:read`
変更	`PATCH /schedules/{id}`（`If-Match` が必須）	`stream:write`
削除	`DELETE /schedules/{id}`	`stream:write`

check を使うと、作る前に重なりを確かめられます。応答は {"ok": true, "overlaps": [...], "shared_input": true|false} です。時間帯が重なる録画の予約どうしは、同じ入力と同じセグメントを共有します。

PATCH で変えられるのは name・start_at・end_at・pre_roll_ms・post_roll_ms・grace_ms・snapshot_interval_secs・retention_days と state です。state には取り消しを表す "canceled" しか指定できず、ほかの値は 400 です。実行中の予約の start_at は変えられません（409）。action・stream・recurrence を変えたいときは、予約を作り直してください。

予約と回の状態

予約の state:

`state`	意味
`pending`	次の回を待っています
`running`	実行中です
`completed`	終わりました
`missed`	開始時刻に間に合わず、実行しませんでした
`canceled`	取り消されました
`failed`	実行に失敗しました

1 回ごとの実行（run）も同じ値を取り、reason（missed・failed になった理由）と recording（作った録画の ID）が付きます。繰り返しの予約は、1 回分が終わる（completed・missed・failed になる）たびに pending に戻り、全部の回が終わったところで completed になります。

実行の規則

予約は 250 ms ごとに見回り、変更があったときはすぐに見直します。録画の開始などの処理は、状態を保存してから行います。

record の予約は、start_at - pre_roll_ms に録画を始め、end_at + post_roll_ms で止めます。配信者がいなくても録画は始まり、配信者が来てからのセグメントが記録されます。インデックスには start_at と end_at を not_before_ms・not_after_ms として残し、MP4 のエクスポートはこの範囲で切り出します（上の「MP4 のエクスポート」を参照）。

回の開始時にストリームがない、ストリームが stopped、同時に動かせる録画の数が上限に達している、のどれかなら、その回は failed になります。ノードが止まっている間に回の時間帯が終わってしまった場合は、次の起動時にその回を completed にし、録画は復旧の処理で interrupted になります。

注意点

予約による録画は、時間帯の終わりまで続きます。 途中で配信が終わって猶予時間が過ぎても、録画は確定しません。同じ時間帯のうちに配信者が戻れば同じ録画に続けて記録し、途切れていた間は欠落（gap、reason: publisher_reconnect）として、VOD には #EXT-X-DISCONTINUITY として残ります。戻らなければ、時間帯の終わりで確定します。

live の予約が配信を断るのは、その予約が pending か running の間だけです。 その間は、時間帯の外から来た配信を断ります。終わった予約（completed・missed・failed）や取り消した予約は、配信の邪魔をしません。繰り返しの予約は全部の回が終わるまで pending に戻り続けるので、回と回の間の配信も断られる点に注意してください。

実行中の予約を取り消す（state: "canceled"）か削除すると、その回の録画と静止画の保存が止まります。 録画は finalized として確定し、その回の state は canceled、reason には取り消されたことが記録されます。クラスターでは、録画を作ったノードが止めます。

録画の保存先（S3 互換のオブジェクトストレージ）

録画はデータディレクトリの外にも置けます。保存先には AWS S3 のほか、MinIO や Cloudflare R2 のように S3 互換の API を持つサービスが使えます。設定はノードのオプションで行います（設定の「録画の保存先」を参照）。

senca-node --data-dir /var/lib/senca \
  --recording-storage s3://my-recordings/senca \
  --s3-region ap-northeast-1 \
  --s3-credentials /etc/senca/s3.json

保存の流れ

保存先を設定しても、録画はまず手元のデータディレクトリに書き込まれます。障害に備えた書き込みの順序（上の「中断と復旧」）は変わりません。

書き終えたセグメントはもう変更されないので、アップロードは録画の途中から始まります。録画が確定してサムネイルができると、残りのセグメント・サムネイル・インデックスを送り、録画の storage に保存場所と時刻が入ります。保存先に置くインデックスの各行には、オブジェクトのキーが書かれています。

手元のコピーは、アップロードが終わってから --recording-keep-local 秒（既定 86400 秒、つまり 1 日）たつと消えます。0 にすれば、アップロードが終わりしだい消します。

アップロードに失敗したら、最大 5 分の間隔を空けてやり直します。ノードを再起動した場合も、残っている録画のアップロードを続けます。

録画の読み込み

VOD、MP4 のエクスポートし、サムネイルは、手元にあれば手元から、なければ保存先から読みます。VOD の Range 付きのリクエストは、範囲をそのまま保存先に渡します。

アップロード済みの録画は、同じ保存先を設定したクラスターのどのノードからでも返せるので、録画を作ったノードへのリダイレクトは起きません。まだアップロードしていない録画は、従来どおりリダイレクトします。録画全体の MP4 は、最初に作ったものを保存先の recordings/{録画 ID}/export.mp4 に置き、次からはそれを返します。

保存先に置くもの

オブジェクトのキーは、「プレフィックス + データディレクトリの中での相対パス」です。

キー	内容
`{プレフィックス}/segments/{ストリーム ID}/{run}/…`	セグメントと fMP4 の初期化セグメント
`{プレフィックス}/recordings/{録画 ID}/index.jsonl`	インデックス（各行にオブジェクトのキーが入ります）
`{プレフィックス}/recordings/{録画 ID}/thumbnail.jpg`・`thumbnail.json`	サムネイル
`{プレフィックス}/recordings/{録画 ID}/export.mp4`	エクスポートした MP4

--s3-part-size（既定は 16 MiB）より大きいもの（主にエクスポートした MP4）は、分けてアップロードします（マルチパートアップロード）。

保存先からの削除

API で削除したときも、保持期限が切れたときも、保存先のオブジェクトを一緒に消します。ほかの録画と共有しているセグメントは残します。クラスターでは録画を作ったノードが消しますが、削除のリクエストはどのノードの API に送ってもかまいません。保存先に接続できなければ「削除中」のまま残し、--retention-sweep の定期処理でやり直します。

バケットのライフサイクルのルールでオブジェクトを消すのは避けてください。SENCA はそれを知らないので、再生やエクスポートで欠けた部分が出てきます。削除は SENCA の保持期限（上の「保持期限」を参照）に任せるのが安全です。

認証情報と権限

認証情報は、JSON のファイル（--s3-credentials）か、環境変数 AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY で渡します。一時的な認証情報なら AWS_SESSION_TOKEN も渡してください。ファイルは所有者だけが読めるようにしておきます（chmod 600）。

{"access_key_id": "AKIA...", "secret_access_key": "...", "session_token": null}

SENCA が呼ぶのは、プレフィックスの下での PutObject・GetObject・HeadObject・DeleteObject・ListObjectsV2 と、マルチパートアップロードの操作（CreateMultipartUpload・UploadPart・CompleteMultipartUpload・AbortMultipartUpload）です。AWS の IAM では、s3:PutObject・s3:GetObject・s3:DeleteObject・s3:AbortMultipartUpload と、プレフィックスに限った s3:ListBucket を許可してください。

保存先は管理者が設定する宛先なので、--egress-allow による外部への接続の制限はかかりません。同じネットワークの中の MinIO（http://10.0.0.5:9000 など）にもそのままつながります。

サービスごとの例

サービス	オプション
AWS S3	`--recording-storage s3://bucket/prefix --s3-region ap-northeast-1`（宛先は `https://s3.{リージョン}.amazonaws.com` で、バケット名をホスト名に含める形式になります）
MinIO	`--recording-storage s3://bucket/prefix --s3-endpoint http://minio:9000`（バケット名をパスに含める形式になります）
Cloudflare R2	`--recording-storage s3://bucket/prefix --s3-endpoint https://{アカウント ID}.r2.cloudflarestorage.com --s3-region auto`

クラスターで使うとき

すべてのノードに同じ保存先と認証情報を設定してください。保存先がないノードは、アップロード済みの録画でも、録画を作ったノードへリダイレクトしてしまいます。

あとから保存先を変えた場合、それまでにアップロードした録画は録画の storage.uri の場所から読みます。そのとき使う認証情報は、ノードにいま設定されているものです。

録画

仕組み