【Next零 ;更新記事】

機材台車
（伊波桜化）
＊

Canon HF G20
ワイコン比較テスト
＊

自作LANCリモコン
製作レポート
＊

JVC GY-HM650
試用レポート
＊

Bluetoothインカム
＊

EDIUS @ Mac
＊

FUJINON XT17s
レンズレポート
＊

EDIUS6 レポート
＊

LEDビデオライト
SONY HVL-LBPA
＊

GPGPU と NLE
＊

HDR-XR520V
使用レポート
＊

FIRECODER Blu
レポート
＊

Core i7 で NLE
＊

HVR-S270J
関連レポート
＊

HD→SDダウンコン検証

【Note; Affiliate】

楽天市場

Ｂ＆Ｈ

Amazon.co.jp

・　・　・

　>>Grass Valley
　>>Adobe
　>>SONY
　>>Panasonic
　>>Manfrotto

・

　>>楽天市場
　>>ビデオ近畿
　>>SYSTEM5
　>>kakaku.com

【Next零 ;Key Contents】

reTMCD
＊

Eye-One Display2
レンタル
＊

非公式データバンク
EDIUS Bench
＊

HVR-S270J
関連レポート

【Note; Affiliate】

Article offer cooperation

* * *
ACC*Software Leading...

Hosting Management by

*　*　*

～　創想雑誌　～

－>>2017/10/03/(Tue)　Switching Logger （_prt）: ■はじめに
　この度、タイムコード・ラボでは「Switching Logger（_prt）」を開発した。

　この黒い箱は、映像スイッチャーのスイッチング情報を、タイムコードと紐付けて記録するための装置である。
　「Switching Logger」を使うことで、収録現場でのスイッチングを XML形式を介してノンリニア編集機のタイムライン上で再現する事が可能で有り、スイッチング収録後の修正編集、フィニッシングを容易にする事が可能となる。

　「Switching Logger（_prt）」は、Roland V-1SDI のスイッチングトリガーを受けて、スイッチングされた瞬間のタイムコードを付加して、ログを取る単純なシステムだ。
　タイムコードは、各カメラや本線収録機にも分配され、全て同期している。

＜「Switching Logger」には V-1SDIのシリアルデータと外部タイムコードを入力する＞

　つまり、タイムコードが同期している要素として、
①スイッチングタイミングデータ
②本線収録
③各カメラのパラ素材
　を得ることが出来る。

　これらのデータを、統合することでノンリニア編集プロジェクト上に現場スイッチングを再現することが可能となる。

■旧来の現場スイッチング
　現場スイッチング収録の最大のメリットは、編集時間の短縮だ。
　例えば6時間のイベント記録の場合、現場スイッチングであればイベント中にリアルタイムでスイッチングを行うために、基本となるスイッチングは当日の6時間で終わり、後日の修正編集は短時間で済む。
　一方、現場でスイッチングせず、カメラでパラ撮りした素材をノンリニア編集上でスイッチング（マルチカム編集）する場合、編集を作り込むことは出来るが、その代わり6時間のイベントをもう一度再生しながらスイッチングする必要があり、後編集の時間が膨大になる。

　ただし、現場スイッチングもメリットばかりではない。
　後日の修正編集が手間なのだ。
　通常、マルチカメラによる現場スイッチング収録では、スイッチングアウトを本線収録として、それを下敷きにして、スイッチングミスやカメラミス、または構成の変更を行う。
　ただ、本線収録はノンリニア上では一本のクリップとして認識されるため、スイッチングのタイミングは、編集者が見つけ出してカット点を付け加える必要がある。

＜ノンリニア上では一本のクリップに見える為、スイッチング点を探す必要がある。＞

　例えば、スイッチするカメラを入れ替えたい場合は、該当箇所を見つけてそのIN/OUT点をカットして、次に本線に同期さているカメラ素材と入れ替える必要がある。
　さらに、ディゾルブ箇所の変更などを行いたい場合は、ディゾルブが適用されている２つのカメラに跨がった部分のIN/OUT点を見つけて修正を行う必要がある。ディゾルブが連続している場合は、１カ所の修正のために前後の数カット分もやり直す必要があるだろう。

■「Switching Logger」のメリット
　「Switching Logger」を利用した場合は、ノンリニアのプロジェクトに展開された段階で、全て編集点（カット点）がついている為、カメラの入れ替えやタイミングの修正は簡単だ。
　従来のノンリニア編集上のマルチカム編集と同じ手法で修正が行える。

＜ノンリニア上ではこの様に表示され、編集点やONタリーカメラの把握が容易。＞
　
　この場合、ノンリニア編集ソフトのタイムラインが本線収録と同等と考えられるので、極端な話、現場で本線収録をする必要も無い。
　スイッチャーを持ち込むにも拘わらず、本線を巻き取る必要が無いのである。

　さて、この「Switching Logger」には、ノンリニア編集での修正を容易にするというメリット以外にも幾つかのメリットが生まれる。

Ａ：出力の遅延したカメラを使用できる
Ｂ：HD収録に4Kカメラを活用できる
Ｃ：カメラ情報（キャラ）を出したままにできる

　以上が考えられる。
　以下、具体的に解説していこう。

Ａ：出力の遅延したカメラを使用できる
　これは、昨今散見される問題で、カメラの HD-SDI や HDMI からの出力映像が何フレームか遅延しているという物だ。
　カメラ側の処理が高度化した為に、最終的な出力が送れてしまっているという問題だ。
　特に、4Kカメラから HDにダウンコンした場合に大きな遅延が見られるため、従来のスイッチング現場では、そういったカメラは混成不可能と言われてきた。
　しかし、遅延しているのは飽くまでも出力であって、カメラ内部の記録ではない。
　「Switching Logger」を使うシステムでは、ノンリニア編集上でのタイムラインが本線であり、カメラで収録された素材を直接参照するため、現場の出力の遅延は問題にならない。
　「Switching Logger」を使うことで、出力遅延のあるカメラも混成することが可能になる。

Ｂ：HD収録に 4Kカメラを活用できる。
　HD収録が基本となる収録に 4Kカメラを利用することのメリットは、編集時に拡大やズームワーク、またはパンなどができることだ。
　しかし、スイッチング収録の現場では 4Kのカメラを入れたとしても、本線はHDで収録されてしまっており、また編集時には１本になっている本線収録クリップ内から、4Kカメラを活用したカットを見つけ出して、そのIN/OUT点を手動で付けて、4Kカメラで収録した素材に置き換えて、拡大などの処理をする必要があり、4Kカメラを使えば使うほど手動作業が増えて面倒になってしまう。
　しかし、「Switching Logger」では、何度も繰り返すように、既にノンリニア編集上でのタイムラインで編集点が付いており、4Kカメラを使った箇所は明確になっており、直ちに 4K素材に対して任意の処理を掛ける事ができる。
　積極的に4Kカメラを使っても、編集時に苦にならない。

Ｃ：カメラ情報（キャラ）を出したままにできる。
　カメラ出力（HD-SDI や HDMI）に、撮影情報（アイリス値やズーム、REC状態など）の表示をスーパーインポーズしたまま、スイッチングできる。
　本来であれば、キャラ付きの本線収録は事故以外の何物でもなかったが、「Switching Logger」を使うことで、飽くまでも活用するのはカメラ本体が収録するファイルとなるため、カメラ出力をキャラ付きにしても問題ない。
　小型スイッチャーとデジなどを使ったマルチカム収録現場は、低予算でスイッチャーがスイッチングをしながら幾つかの役務を兼任することは当たり前になっている。
　別途 VEを用意したりすることは難しいので、カメラの状態監視はそれぞれのカメラマンの責任なるが、その点では事実上スタンドアローンと変わらないので、事故やミスも起きやすい。
　キャラ付きの映像をスイッチャーベースで確認できることで、録画忘れやメディア残量チェックの他、誤ってゲインやシャッターが入っていたり、フォーカス値が極端に狂っていたり等の状態を把握することができる。
　また無人カメラの状態も、同様に確認できるため、安心感が違うだろう。

■現場への導入
　先日、これらのメリットを活用すべく、マルチカメラ収録の現場に「Switching Logger」を導入し、収録を無事に終えることができた。

　写真の通り、4Kミラーレスカメラの DC-GH5 をセンター引きカメとして使用し、スイッチャーに入力している。
　GH5は舞台全景よりもやや広めに画角を作って安全マージンを確保し、編集時に53%ぐらいに修正してやることで舞台全景にする。

　また、4Kからのダウンコンなので少々の遅延があるが「Switching Logger」のシステムには関係ない。

　さらに、無人配置したGH5のメディア残量の把握や、各有人カメラの状況を把握する為に、HD-SDI や HDMI にはキャラ（文字情報）を載せたままにしている。
　そのため、メディア残量を心配したりREC忘れを憂慮することもなく、また有人カメラに対してはアイリス値を見て値を揃えさせる指示をだせたり、フォーカス値が舞台撮影ではあり得ない数値になっていたため修正を促したりできた。

　一応、テストでスイッチングアウトを本線として収録しているが、当然 GH5は遅延し、キャラが乗ったままの本線収録ファイルができあがっている。
　もちろん、この“本線収録”を利用することはない。

＜それぞれのカメラ映像にも、本線収録（左下）にもキャラが乗っている＞

■XMLへの変換と課題
　さて「Switching Logger」は「何時何分何秒何フレームに何カメをスイッチしたか？」というデータがひたすらログとして記録されるだけで、そのログ自体はノンリニア編集のプロジェクトデータになっていない。
　この「時間とスイッチ」のデータを元に、ノンリニア編集ソフト上で読み込めるプロジェクト形式にコンバートする必要がある。
　当初は、単純に EDLにコンバートする事を考えたが、EDLの場合は本線収録にカット点が付いただけのプロジェクトになってしまい、裏……つまり“OFFタリー”のカメラを扱うのに向いていない。
　その為、XML仕様で編集プロジェクトを組み立てることにした。

　XMLであれば、タイムラインをそのまま再現できる為“ONタリー”と“OFFタリー”のカメラの把握と活用が容易になる。

＜明るい部分が“ONタリー”、暗い部分が“OFFタリー”状態だ＞

　また、XMLであれば一般的なノンリニア編集ソフトがそのプロジェクトインポートをサポートしているため、様々なソフトで編集を行う事ができる。
　私がテストしているだけでも、EDIUS 、Premiere、DaVinci Resolve、Final Cut Pro で XMLの利用が可能である。

　また「Switching Logger」も、仕組みとしては「スイッチングした」というトリガーにタイムコードを紐付けているだけなので、スイッチャーを Roland V-1SDI に限る必要も無い。
　特にタリー出力のあるスイッチャーであれば、それをトリガーにしてタイムコード付きのログを取ることが可能だ。

　さて XMLの活用だが、現時点では XMLの仕様を把握し、サンプルとしての XMLベースの編集プロジェクトの生成に成功しているという段階だ。
　まだ、ログからの XML生成は開発途上にある。

　また、今回の XML検証で分かった事は、EDIUS の XMLインポート機能には幾つかのバグが見られるということで、結構苦労している。
　最大の問題は、XML上に記述されている「クリップの有効／無効」のフラグが認識されていないことだ。
　つまり、ONタリーのクリップもOFFタリーのクリップも関係なく、全てON（有効）になってしまっており、このままでは最上段トラックのクリップがひたすら再生されるだけになってしまう。※EDIUS 9／EDIUS 8.53で修正済

~~＜EDIUSでは全てのクリップが有効……ONタリーになるため、実際には最上段の紫のクリップしか表示されない＞~~

　当然、他のノンリニア編集ソフトは、ちゃんと有効／無効フラグを認識しており、正しいスイッチングタイムラインを再現している。

＜同じ XMLファイルを読み込んだもの。~~EDIUSだけ他のソフトと処理が違うのが分かる~~＞
　

　このバグは、早期に EDIUS側が修正してくれると思うが、修正までにこちらの収録案件の納期が間に合わないので（笑）、解決策を思い付いた。
　有効クリップだけマージして、最上段のトラックに並べてしまうのだ。
　勿論、EDIUS内のマルチカム編集のマージ機能は使えないので、XMLにコンバートする段階でマージトラックを生成してしまうつもりだ。
　当然、パラ収録素材が並ぶトラック上で、ONタリークリップを把握するのは面倒だが、スイッチング本線をタイムライン上で再現するという目的は果たせるし、修正作業自体には大きな不利にはならないだろう。
　

＜有効クリップだけマージする~~という苦肉の策。EDIUSのバグ修正に期待だ~~＞

　さらに現在、再現条件の確認中なのだが、例えば12:59:00;00をタイムラインの冒頭タイムコードにして、そこにクリップを配置した XMLをインポートすると、何故か24時間後の 12:59:00;00 にクリップが配置されてしまう。
　最初、冒頭タイムコードを設定した XMLをインポートした際に、クリップがタイムラインに配置されなかったため、冒頭タイムコードを設定すると、EDIUSはクリップを読み込めないバグがあるのかと思ったが、タイムラインを縮小してみると24時間後の部分に配置されていて、目が点になった……。　
　勿論、その他の XML対応のノンリニア編集ソフトではその様な問題は起こっていない。

　さらにさらに辛いのが、EDIUSには XMLエクスポートの機能が無いことだ。
　「Switching Logger」での XML生成ワークフローでは、一旦、ノンリニア編集ソフトのタイムライン上で、各カメラの素材クリップを各トラックに配置して、その同期だけは合わせておく必要がある。
　これは同期が合っているだけのノーカットのタイムラインプロジェクトになるのだが、その状態を XMLとしてエクスポートして、それによって生成された XMLをベースにして「Switching Logger」で取得したカット点を自動的に挿入していく仕組みだ。
　その為、ノンリニア編集ソフト上でのクリップの同期合わせは重要な作業なのだが、EDIUSに XMLエクスポート機能が存在しないために、他のソフトを使って作業をする必要がある。
　しかし、使い慣れていないせいもあってか、他のソフトが非常に使いにくい。
　タイムラインの初期タイムコードの設定の仕方も分かりにくかったが、素材クリップが持っているオリジナルのタイムコードをどこで確認したら良いのか分からないので、トラック間の同期合わせや、そのクリップとタイムラインのタイムコードの一致させ方などが分からない。
　このシステムでは、タイムラインのタイムコードと素材クリップのタイムコードも揃っている必要があるのだ。
　つまり、タイムコードをフリーランで走らせた素材クリップで、13時に収録が始まったとすれば、タイムライン上の13:00:00;00に素材クリップの13:00:00;00を配置する必要がある。
　まぁ、この仕様は「13:00:00;00を00:00:00;00とみなす」というタイムコードのオフセット処理を掛ける事で変更可能であるが…（と言うことを昨夜の風呂で思い付いた）

　いずれにせよ、EDIUS をメインソフトで編集している私としては、EDIUS は XMLの取扱に対しては最も遅れているノンリニア編集ソフトであるということを、初めて認識させられた。
　当初、クリップの有効／無効フラグを認識できていないと知ったときは、本気で編集ソフトの乗り換えを考えた。
　その後すぐに思い付いた解決策を見出さなかったら、DaVinci Resolve へ移行していた可能性が大きい（笑
　ともあれ、EDIUS には XMLの取扱に対して、今後大きく改善を望みたい。

■デジ主体の現場スイッチングの未来へ
　本文で、しれっと登場している Roland V-1SDI は実はこの8月に購入した物だ。
　私にとっては、初めてのスイッチャー機材だ。
　実は「Switching Logger」は、V-1SDIを導入してから思い付いた物ではない。
　自分が業務にスイッチャーを導入するならば、必ず必要となる修正編集のワークフローを十全に（楽に）してからでないと、労力が嵩むだけだと思い、ずっとログシステムのことはアイディアとして温めていた。
　いよいよスイッチャーを用いる業務が増えてきて「Switching Logger」を現実の物にする必要が迫ってきた時に Roland V-1SDI であれば、RS-232Cからのシリアルデータもリファレンス公開されており、思い描いているシステムが作れると確証できたので V-1SDIを「Switching Logger」実現のために導入したのだ。

＜2017年夏、プログラマーの松ケンとの開発風景＞

　勿論、先にも述べたように、このシステムはスイッチングトリガーを取り出せるスイッチャーであれば、どれにでも応用可能だ。

　ただ、この「Switching Logger（_prt）」はプロトタイプだ。
　現在の仕様では、V-1SDIの RS-232Cから出ているシリアルデータを利用しているが、取り出せる情報が少なく、発展性には課題がある。
　今後は USB-MIDI側のデータを利用して、更に応用を進めていく予定だ。
　既に発展的な利用方法を企画・提案しており、「Switching Logger」を中核としたデジクラスでのマルチカム・スイッチング収録の現場環境を改善していく計画である。
　いずれ、改めて公開したい。

　「Switching Logger」は、現場スイッチングによるメリットと、マルチカム編集でのメリットを両立させることが出来るシステムである。
　もしくは、現場スイッチングによるデメリットとマルチカム編集によるデメリットを排除したシステムである。

　まずは、先日のマルチカム収録案件で基礎となる「Switching Logger」のシステムを確立し、未来の開発に繋げていきたい。

「Switching Logger（_prt）」

△このページのTOPへ戻る; ツイート

君島里之(2017/10/09 12:14)
素晴らしいです。流石ですね。FaceBookでも書きましたが、私もこんな物を作ってみました。https://youtu.be/Hg-IZBUF4Y0
ediusでのedlリストはマルチカメラ編集にはダメだと思って、ハードウェアで考えた結果、こういうか形になりました。
xmlファイルというのを初めて知りました。実体は未だ見た事がありませんが。それとtimecodeとタリー信号とを紐付けて記録することが、私の能力では、てきませんでした。arduinoで出来る事は際限ないですね。これからの発展を楽しみにしています。

宏哉(2017/10/12 14:34)
ありがとうございます！
DTMF信号を拾って、テンキーのシグナルに変換して現場スイッチングを再現する！っていうのに、思わず唸ってしまいました。いろいろなアイディアがあって楽しいです！
必要は発明の母！　これからも色々なアイディアを形にしていきたいですね！

Name　　　Message　
　日本の首都を入力する認証です→　

－>>2017/10/20/(Fri)　“Switching Logger”システム、稼動開始。: 　先日発表した“Switching Logger”だが、その後段のワークフローとなる“Switched XML.exe”のプロトタイプが完成した。

　つまり、現場のライブスイッチングをタイムライン上に再現するシステムの基礎が完成した。

　ワークフローは、こうだ。

　現場でスイッチャーを使って、通常のスイッチングを行い“Switching Logger”でスイッチングのログを取る。
　この場合、各カメラではパラ収録を行っておき、一方でスイッチャーからのプログラムアウトは収録してなくても構わない。
　また、タイムコードは全カメラと“Switching Logger”が同期してることが望ましいが、場合によってはカメラ1台と“Switching Logger”のタイムコードが同期していれば、後のカメラは編集時に同期を合わせるのでも問題ない。

　次に編集工程。
　通常のマルチカメラ編集と同様に、各カメラ素材の同期をタイムライン上で取る。
　また、全トラックの冒頭を切り揃えて、その点をタイムラインの頭に持ってくる。
　例えば、12:59:00;00 の様に全てのクリップの冒頭を揃える。
　次に、クリップ冒頭ＴＣとタイムラインのスタートＴＣを揃える。
　クリップ冒頭ＴＣが 12:59:00;00 の場合、タイムラインのスタートＴＣも 12:59:00;00とする。
　ここがズレていると、スイッチング結果が狂ってしまう。

＜4GB分割されたクリップでも連続していれば問題ない＞

　同期と冒頭ＴＣを揃えたら、XMLにエクスポート。
　この XML をノーカットXML もしくは Synced XML と呼称する。

　次に、Switching Logger で取ったスイッチングログと、先ほど作った Synced XML を“Swiched XML.exe”にドラッグ＆ドロップし、生成ボタンを押す。
　Swiched XML.exe からログを元に生成したスイッチング済み XMLが吐き出される。
　この XML を Swiched XML と呼称する。

＜Swiched XML.exe のプロトタイプ。とりあえず、4カメ対応版。＞

　最後に、Swiched XMLを任意のノンリニア編集ソフトでインポートすると、現場スイッチングを再現したタイムラインを得ることが出来る。
　タイムラインは Track 1　から順に 1カメ…2カメと並び、最上段のTrackにはスイッチングで選択されたクリップがマージされた状態で配置される。

　あとは、通常のノンリニア編集を行う事ができる。

＜DaVinci Resolve で再現されたスイッチングタイムライン＞

＜EDIUS Pro 8 で再現されたスイッチングタイムライン＞

　なお、現状のシステムでは、現場で行ったディゾルブ効果などは記録されない。
　現場でのトランジション完了タイミングがスイッチングの頭として再現されている。

　さらに、EDIUSでは XML内に記述されている「クリップの無効フラグ」を正しく読まないために、スイッチングで選択されたカメラも、選択されなかったカメラも、タイムライン上では全て有効クリップとして再現されてしまう。
　EDIUS側の問題であるので、当方では改善のしようがない。※EDIUS 9／EDIUS 8.53で修正済

~~＜EDIUS Pro 8 の場合、全てのクリップが有効化してしまう＞~~

　また、Premeireでは現在 Swiched XMLが読み込めない不具合に遭遇している。
　原因究明中だ。

　まだまだ、デバッグなどの検証作業を重ねていく必要があるが、基本的なワークフローは最後まで行う事が出来た。
　とりあえず、10月にスイッチング収録を行った案件の再編集は、この“Switching Logger”システムを活用して完成させていく予定だ。

＜“Switching Logger”システム概念図＞

　“Switching Logger”は、スイッチャーからタリートリガーが取り出せればスイッチャーの種類を問わず、またXMLが読み込めればノンリニア編集ソフトの種類も問わないシステムだ。
　例えば、SONYの MCX-500 と RM-30BPの組み合わせでも、LNAC信号にタリートリガービットが乗っている為、LANCプロトコルの解析を行うプログラムを“Switching Logger”のArduinoで走らせれば、以降は同様のソリューションを享受することが出来る。
（※スイッチャー別のトリガー受信I/Fと解析プログラムの設計は必要となる）

　まだ、課題は残っているが、柔軟なシステム対応が出来るポテンシャルがあるので、今後もご注目いただきたい。

△このページのTOPへ戻る; ツイート