動画の学校の受講生、Aさんが、夏祭りの中継を終えた翌日に訪ねてきた。3キャリアのSIMを束ねたボンディング機材を持ち込んだのに、日が暮れて人出が増えるほど映像が荒れたという。 私は、乱れ始めた時刻と会場の人の流れを尋ねた。答えは回線の本数ではなく、時間帯にあると見たからだ。 モバイル回線は、周囲の利用者と同じ道を分け合う仕組みになっている。本数を増やす行為は、渋滞した道に車線を描き足すのではなく、同じ道に車を並べることに近い。Aさんは静かにうなずいた。 そこで私は、ネットワークスライシングの話をした。5G SAの網を仮想的に分け、中継のためだけの専用レーンを予約する技術だ。

国際拠点を跨ぐリモートプロダクションでは、時刻同期の設計が安定運用の生命線になる。動画の学校の受講生、Rさんの事例を共有する。 海外拠点と日本国内を接続するプロジェクトで、短い周期のクロック異常が発生した。これは一般的な音切れとは明確に異なる挙動だった。私はまず、異常発生の周期を正確に実測するようRさんに助言した。 測定された周期は、精密時刻同期プロトコル(IEEE1588、国際電気電子学会が策定、日本国内の放送設備でも標準的に採用)が内部で再同期を行う間隔と一致していた。複数拠点の機材が、それぞれ基準時刻の主導権を主張し合う競合状態が原因だった。 この事例の要点は、同じ「

配信専門のプロダクションで働く、動画の学校の受講生、Tさん。社内ネットワークが混み合う時間帯になると、音声だけが不安定になる現象に悩んでいた。帯域は十分に足りているはずなのに、だった。🖧 私が注目したのは、音声パケットに付けられている優先度の印だった。その印が、ネットワークの経路の途中で消えてしまうことがある。消えた瞬間、音声パケットは他の通信と同じ扱いになり、混雑時だけ後回しにされてしまう。 Tさんの現場を確認すると、まさにその印がある区間だけ消えていた。スイッチの設定を一か所見直すだけで、混雑時間帯の不安定さはきれいに収まった。帯域の問題だと思い込んでいたら、一生気づけなかっ

動画の学校の受講生Mは、撮影の現場で十年を数える技術者だ。その彼が、ある夜の夜景ロケのライブ配信でブロックノイズに悩まされ、私を訪ねてきた。回線は何度測っても正常だという。 私は水道管の話をした。蛇口を全開にしても、管の太さが決まっていれば流れる水の量には限りがある。固定ビットレートとは、その管の太さを先に決める方式だ。普段なら十分に流れる水も、ノイズという濁った水が一度に押し寄せると管から溢れ、粗い画面になって現れる。 Mは、実測ビットレートが目標値の上限に当たっている様子を見て、深く頷いた。「管を疑わずに、水源を疑うのか」と彼は言った。水源とは、暗所で増幅されたセンサーのノイ

動画の学校の受講生Tが青ざめた顔でメッセージを送ってきた。「先生、バックアップしていたはずなのに、フォルダが空でした…」 TはNASへの自動バックアップを設定していた。設定自体は動いていた。ところが、バックアップ先のドライブが半年前から静かに容量不足になっており、処理がスキップされ続けていたのだ。誰も確認していなかった。 「バックアップを"取っている"と"復元できる"は全く別の話だ」 RPO（どこまで遡れるか）とRTO（どれだけで戻せるか）。この2つの数字を決めてから設計するのが正しい順序だと伝えると、Tは静かに頷いた。月1回のリストアテスト

LEDウォールを背景にしたとき、画面を横切る分裂線。あれはカメラとLEDの呼吸を合わせれば出なくなる。 LEDの面は、上から下へ順番に描き替えられている。一方、多くのカメラも上の行から順に読み出している。描き替えの途中の行をカメラが読んでしまうと、画面の上と下で描画のタイミングが1フレームずれ、境目に段差があらわれる。これがテアリングと呼ばれる症状だ。厄介なのは、カメラもLEDも、それぞれは正しく動いていることだ。二つが出会ったところにだけ症状が出る。 動画の学校の受講生Aさんは、新製品発表の収録でこの線に出会った。バーチャルプロダクションが話題になり、LEDを背にした撮影は身近

測れないものは、直せない。これは映像の現場で何度も確かめてきたことだ。 動画の学校の受講生、Aさんは、小さな配信スタジオで技術を担当している。最近、演出家から「なんだか反応が鈍い」と言われるようになった。機材の仕様書には遅延の公称値が書いてあり、それを見る限り問題はない。なのに、現場の体感は違う。どこを疑えばいいのか分からず、私に相談してきた。 私はAさんに、スマートフォンを一台出してもらった。ストップウォッチを表示させ、それをカメラで撮る。そして送出側の画面と、モニタ側の画面を一枚の写真に収める。二つの画面に映った数字の差が、そのまま「ガラスからガラスまで」の遅延になる。高価な

拍手が鳴ってから引きの画に変わるまで、ほんの一瞬。その一瞬が、会場の熱を冷ましてしまうことがある。 動画の学校の受講生、Mさんは、ある企業のハイブリッド型タウンホールでスイッチングを任されていた。会場とオンライン参加者をつなぐ集会である。社長が質問に答え終え、客席から大きな拍手が湧いた。ここで全体ショットへ抜く。段取りどおりだ。ところが配信の画面では、拍手が流れているあいだ、質問者のアップが居座っていた。 「私、ボタンを押すのが遅いんでしょうか」とMさんは言った。 私はまず、彼女の演出用モニタがどこから映像を受けているかを尋ねた。答えを聞いて合点がいった。オンエアの経路と、

「ブレーカーを大きいものに替えてもらったのに、また落ちました」 動画の学校の受講生、Kさんは配信スタジオの立ち上げを任されていた。初日の朝、機材の電源を入れた瞬間に分電盤のブレーカーが落ちる。施設の電気工事担当に頼んで容量の大きいものへ交換してもらったが、翌週、まったく同じことが起きた。 話を聞きながら、私はひとつ問いを投げた。 「4K収録でコマが落ちるとき、カードを128GBから512GBに替えたら直るか」 Kさんは即座に首を振った。容量の問題ではない。書き込み速度のクラスが、ビットレートに追いついていないのだ。 ブレーカーもよく似た作りをしている。電源投入の

動画の学校の受講生Lさんは、トラブルが起きるたびに私に連絡をくれていた。それ自体は悪いことではない。ただ、ある時から様子が変わった。 編集アシスタントが半年かけて自分の判断で色調補正を始められるようになるように、Lさんもまた、経験を積むごとに自走できる範囲が広がっていった。 ある日Lさんは、自分でトラブルシューティングの早見表を作って見せてくれた。症状・疑うべき原因・確認方法という3つの軸で整理されたその表は、私が教えたものより現場に即して実用的だった。 私が伝えた知識が、Lさんの中で経験と結びつき、独自の型に育っていた瞬間だった。教えることの本当の目的は、いつか相手が自分

IP伝送のユニバース設計を丸ごと見直したいと、動画の学校の受講生Cさんが相談に来たのは、現場での「原因不明の重さ」に何度も苦しんでいたからだ。 撮影に例えるなら、被写体を1本の広角レンズだけで全部撮ろうとしているようなものだった。全ての照明ユニバースを一つの塊として扱っていたのだ。 私が提案したのは、Net・Sub-Net・Universeという階層構造でデータを整理し直すことだった。レンズを用途ごとに使い分けるように、ノード側で受信するユニバースを絞り込む。すると各ノードが処理すべきデータ量だけが、驚くほどきれいに整理された。 設定を変えた直後、Cさんはノードのステータス

「ビットレートのグラフが天井に張り付いて、そのあと固まるんです」 地方のスポーツ大会を配信している動画の学校の受講生Sさんは、スクリーンショットを何枚も見せてくれた。エンコーダーの出力は適正だ。回線の速度も足りている。なのに試合が盛り上がるほど送信側のグラフが上限に貼り付き、やがて画が止まる。 SRTは、失われたパケットを送り直すための帯域を、あらかじめ取り分けて使う仕組みである。その取り分が足りなければ、再送が本来の映像と場所を奪い合うことになる。 設定を開くと、再送用の余裕を決める値は初期値の25％のまま。会場はモバイル回線で、ロスの多い環境だった。さらに、この余裕を含

動画の学校の受講生、Uさんは、ハイブリッド形式の社内カンファレンスで音響を担当した。 サウンドチェックは順調だった。ただ、控えめな音量で確認を終えたことが、彼女には少し引っかかっていた。本番では会場が満席になり、登壇者の声量も上がる。この状態のまま臨んでいいのか。相談は、その小さな違和感から始まった。 私は彼女に、配信のテストをどう行っているか尋ねた。本番と同じビットレート、同じ解像度で流す、と即答だった。低いビットレートで問題がなくても、本番設定で帯域が足りるとは限らない。それを知っているからこその答えである。 ハウリング対策の確認も、まったく同じ考え方で行う。まず何も処

動画の学校の受講生、Yさんは、書店の小さなイベントスペースで著者対談の収録と配信を担当していた。 演者の足元に返しのモニターを置いたところ、ある距離まで寄せると声に金属的な響きが乗り、やがてかすかに鳴きはじめる。どこに置くのが正解なのか。それが相談の中身だった。 私はYさんに、インタビュー撮影のライティング比を思い出してもらった。キーとフィルを3:1に取ると、顔にほどよい立体感が出る。比率で決めておけば、会場が変わっても同じ画が作れる。 音の配置にも、同じように頼れる比率がある。マイクから話し手の口までの距離を1としたとき、近くのスピーカーやモニターはその3倍以上離す。3:

配信の安定性を語るとき、多くの人はカメラかネットワーク機器を疑う。だが原因はもっと手前にあることがある。 動画の学校の受講生Fさんは、社内向け大規模ウェビナー配信の技術設計を任されていた。複数拠点のカメラをIPネットワークに集約する構成で、あるカメラだけ映像が不安定になるという症状が繰り返し発生していた。機材構成に問題は見当たらず、対応に苦慮していたという。 調べてみると、そのカメラの映像だけ表示要件に合わせて解像度を一段階引き上げてから送出していた。しかし引き上げても新しい情報が生まれるわけではなく、単に送信データ量が増えるだけだ。ネットワークの容量は無限ではないため、その分の

背景に写り込む金網フェンスが、まさか事故の原因になるとは誰も思わない。 動画の学校の受講生Dさんは、屋外中継の技術スタッフとして4Kカメラ映像をIP経由でHD番組用に変換する業務を担当していた。本番中、背景の金網フェンス部分だけ画面がチラつくという報告が制作側から入った。カメラにもケーブルにも異常はなく、原因の特定に時間がかかったという。 これは解像度変換の仕組みそのものに理由がある。細かい繰り返し模様は、情報量を落とす工程で別の模様に置き換わって現れる。ジャケットの柄でも金網でも、原理は同じだ。現場で目立つかどうかは、被写体の運不運ではなく、変換設計の完成度で決まる。 私

地域の夏祭りを記録するのは、Gさんにとって毎年の恒例行事だ。動画の学校の受講生Gさんは、地域のボランティアとして祭りの様子を撮影し、モバイル回線経由でその場から配信している。夕暮れから夜へと移り変わる空のグラデーションは、Gさんが毎年一番力を入れる場面だった。今年はその空に、これまでなかった段差が浮かんでしまった。原因を探るGさんから届いた映像を見て、私はすぐに気づいた。今年から使い始めた新しいモバイル配信機材が、回線の細さに合わせて自動的に暗い場面のデータ量を削っていたのだ。設定をひとつ手動に切り替えるだけで、来年の空はまた元の滑らかさを取り戻せる。Gさんは安堵したように言った。「新しい機

先日、動画の学校の受講生Aさんから相談があった。新しい配信会場でAPの電源を入れたのに、5GHzだけが一覧に出てこないという。2.4GHzは一瞬で表示された。だが5GHzは30秒経っても、1分経っても現れない。Aさんは機材の故障を疑い、予備のAPに交換しようとしていた。 私はまず、その会場で使っているチャンネル番号を尋ねた。案の定、5GHz帯の中でも特定の番号域を使っていた。実はその帯域は、気象レーダーと周波数を共有している。APは電波を出す前に、そこにレーダーが本当にいないかを一定時間だけ黙って確認する義務を負っている。壊れていたわけではない。法律が定めた「確認の時間」を、Aさんは不

大規模なハイブリッドカンファレンスの制作を任された「動画の学校」の受講生Iさんから、本番二週間前に連絡があった。本社会場、海外拠点、オンライン登壇者という三種類の出演形態をひとつの進行表でまとめようとして、時間配分がどうしても崩れるという相談だった。台本は綿密に作り込まれていたが、リハーサルのたびに微妙なズレが積み重なっていた。 私はまず、それぞれの出演形態にかかる遅延を個別に実測することを勧めた。オンライン登壇者は経路によって数百ミリ秒から数秒までの幅があり、海外拠点の衛星中継はさらに大きな遅延を抱えていた。ひとつの共通進行表で全員を管理しようとしていたこと自体が、そもそもの構造的な

本番中に照明がフェードインした瞬間、卓の奥でモニターが一瞬フリーズする。動画の学校の受講生Bさんから届いたメッセージには、そう書かれていた。「原因は多分、ネットワークの帯域です」と彼は自己診断していたが、症状を聞くほど、私の中では別の答えが固まっていった。 照明が明るくなる瞬間というのは、電気の世界では「大きな塊の負荷が急に入る瞬間」でもある。発電機はその塊を受け止めようとして、電圧を一瞬だけ落とす。人間の目には映らないその沈み込みが、映像機材の電源ユニットにとっては致命的な一撃になる。帯域はまったく無関係だった。 配信の現場は、映像・音声・照明という三つの部門がそれぞれ別々の理