Making of RubyKaigi - Making of KaigiFreaks 配信班

初稿：2011-09-26

書いた人：鈴木則夫

序文

RubyKaigi2011 での KaigiFreaks 配信班の一員であった鈴木則夫です。普段は「鈴木」で通したりもしているのですが、RubyKaigi スタッフには、他の「すずき」さんや、「のりお」さんがおり、Namespace 問題が発生するので、RubyKaigi ではフルネームを使っています。

今回は RubyKaigi2011 での KaigiFreaks 配信班の仕事について書かせて頂くことになりました。

KaigiFreaks との関わり

2008 年頃から日本の IT 系のイベントで、個人による Ustream でのライブ中継が始まっていて、それを知った私は「なにそれスゴイ！」と思っていました。ちなみにこの頃は、イベントでライブ中継をしている人達は「動画配信職人」と呼ばれていました。

ちょうど同じ頃の RubyKaigi2008 に一般参加したところ、2 会場での同時ライブ中継を行っていたり、会場に IRC 用のスクリーンが用意されていたり、イベントとしてのクオリティに驚きつつ、「動画配信職人」ではなく「KaigiFreaks」という名称の存在を知って「なにそれカッコイイ！」と思ったのでした (なお、KaigiFreaks という名称自体は、RubyConf 等の動画配信をしている Confreaks からネーミングされたものと後から教えて頂きました) 。

RubyKaigi2008 以降、KaigiFreaks に憧れつつ、私も動画配信職人の仲間入りをし、PHP 勉強会などでの Ustream 配信を行なっていました。そんな中、RubyKaigi2009 では配信の手伝いに声をかけて頂き KaigiFreaks の仕事を手伝いました。また、RubyKaigi2010 では当日スタッフとして KaigiFreaks に参加して配信機器の設置や操作をし、そして今年は実行委員として動画配信全体の設計を任されるということになり、出世魚的に KaigiFreaks と関わってきました。そろそろ KaigiFreaks の一員だ！と名乗っていいんじゃないか？と思ったところで RubyKaigi が終わってしまいました。

配信の設計

KaigiFreaks の配信班では、基本的に講演者の発表スライドを Ustream によるライブ配信をするスタイルで行っています。また、講演者の発表している姿を観ていただこうと考え、発表スライドの邪魔にならない程度に PinP (Picture in Picture) により発表者の姿を映像に載せたりもしています。

また、ライブ配信以外に、映像記録を残すのも配信班の仕事になります。Ustream でも録画はしているのですが、ネットワーク回線が不安定になった場合に、録画が途切れてしまうことがあります。そうなるとせっかくの発表の一部が記録に残せなくなってしまいます。そのリスクを回避するために、Ustream 以外にも QuickTime による録画も実施しています。これは、私が加入 (？) する前の KaigiFreaks から受け継いでいる伝統的な方式です。

また、クリアな音声を配信・記録するために、会場の音響設備から直接ラインを提供して頂くことにしています。これにより、会場のスピーカーから聴こえる音と同じ音をライブ中継や QuickTime 録画に利用できます。

更に今回は、HD ビデオカメラを撮影に加え、これを記録映像の第一候補として使う計画を立てました。もし、それが何らかの原因で録画失敗した場合には QuickTime 録画での映像を記録として利用、更に QuickTime 録画が失敗した場合には、Ustream 録画を記録として利用するという三段構成による冗長化を計画しました。

これらを実現するために、RubyKaigi 2011 大ホールでの配信・記録用に設計した接続図の実物がこちらです。このような接続図を作る文化も先輩の KaigiFreaks から受け継いだ伝統 (笑) です。 diagram900.png

今回の目玉は、講演者の姿を映すビデオカメラ (iVIS HV20) の HDMI 出力を HDMI ビデオキャプチャ (ADVC-HD50) で FireWIre 化しているところです。これにより、HD 映像をそのまま Ustream へ出力できるようにしました。さらにビデオキャプチャ (TwinPact100) の FireWire 出力を HUB にまとめ、MacBook Pro に2つの FireWire 機器を接続する形にしてあります。しかし、実はこの接続、正しくありません。詳細は後述しますが、もし、この記事を参考にする場合はお気をつけ下さい。

それから、会期の後半で気がついたのですが、iVIS HV20 には FireWire 出力端子 (i.LINK 出力端子) が存在していました。つまり、実は ADVC-HD50 は不要だったと言うオチです。このビデオカメラはお借りしたものだったので、この辺りの調査が足りていませんでした。

また、論理的な接続図の他に、ケーブル配線図も作成しました。これは、特に VGA ケーブルや LAN ケーブルなど、特に長いケーブルが必要になることを考えてのことです。今回、LAN ケーブルはネットワーク班が考えてくれていたので、あまり心配はしていなかったのですが、VGA ケーブルは毎回なかなか手強い相手なので、事前に必要な長さの目処を付けました。 cable900.png

この図は練馬文化センターが公開しているステージの平面図を元に、発表者の位置と KaigiFreaks の機材の位置を考えてケーブルレイアウトを組んだものです。これによれば必要な VGA ケーブルは 10m を超える程度で、15m あればなんとかなるだろうと考えました。

幸い、手持ちの機材に 15m の VGA ケーブルがあったので、それで良しということにしました。

前日設営

RubyKaigi クラスのイベントでは「開場前の1時間で全てを準備」などは到底不可能な規模ので、前日に設営時間が設けられています。他のスタッフに混ざって、配信班もこの時からセッティングを行いました。

しかし、ここで (やはり) トラブルが発生しました。

機器の設置位置などが前述の配線図どおりにはいかずに、現場でいろいろとレイアウト変更をしているうちに、講演者のPCとプロジェクター及び TwinPact100 を接続する VGA ケーブルの長さが足りないことが分かりました。練馬文化センターの大ホールのステージは、本当に大きくて、用意した 15m のケーブルでは変更したレイアウトに対応できませんでした。

もっと長いケーブルを買いに行かないとダメかも知れないと思い始めたときに、会場のプロジェクターに VGA のスルー出力端子が備わっているのに気づき、そこを経由することで回避しつつ、やっぱりもう少しだけ足りずに延長用のコネクタなどを使いつつギリギリ配線を行いました。

なんとか配線を終えた後、Ustream Producer という配信用のソフトで配信チェックを行なおうとしたのですが、ここでもまたトラブルが発生しました。ADVC-HD50 と TwinPact100 を MacBook Pro に繋げたところ、その2台を同時に使うことができない旨のエラーが発生し、機器を認識してくれないのです。

自宅で配信チェックをしていた時にはそんなエラーは一度も出たことがなく、また、設営可能時間のタイムリミットが近づいていたので、「えっ？、なにこれ、えっ？」と、ちょっとパニック気味になってしまいました。「慌てるな、落ち着け、落ち着け」と自分に言い聞かせながら、一度 Ustream Producer を初期状態に戻し、イチからライブショット (入力ソース) を追加して行くと、2つの機器とも認識してくれるではありませんか。

どうやら、私が作った構成が「規格外」だったのが原因のようでした。

その原因を説明をする前に、FireWire について少しおさらいします。FireWire には複数の規格があって、FireWire 400 や FireWire 800 と呼ばれています。それぞれ転送速度が 400Mbps / 800Mbps になっているため、このような呼び方になっているようです。

今回使用した MacBook Pro は FireWire 800 の規格で、ADVC-HD50 や TwinPact100、FireWIre HUB は FireWire 400 の規格の製品になっています。800 の機器で 400 の機器を使うのは下位互換性もあり、スピードが 400Mbps になってしまう以外の問題ないはずだと思っていました。しかし、どうやら、FireWire 400 上を流すことのできるリアルタイムビデオ映像データは1本が限界とされているようで、入力ソースに2本の FireWire 機器が設定してあった状態の Ustream Producer では、起動時にその制限チェックでエラーを発していたのではないかと推測しています。

Ustream Producer の初期状態から入力ソースを1本ずつ追加して行くと、そのエラーチェックを通らないのか、2本の FireWire 機器を登録することができました。自宅での検証作業では、TwinPact100 でのテスト後に ADVC-HD50 を追加して確認をしていたので、このエラーに遭遇しなかったようです。

規格上の限界を超えていたのかも知れないのですが、実際に配信はできていたので、本番ではこの構成のまま配信を行ないました。内心は結構ヒヤヒヤしていましたが。

配信の作業について

初日の最初の Ustream 配信でもトラブルがありました。Ustream サーバとの接続がときどき切れてしまい、配信が停止してしまうということと、音声が輻輳してしまい、聴こえるというものです。

前者については、ネットワーク班が対処してくれて、お昼までには問題解消できました。後者の音声問題については、当初原因が不明でどうすれば良いのか考えあぐねていたのですが、iVIS HV20 の HDMI 出力からの音声が紛れ込んでしまっているのではないかという仮説まではなんとかたどり着きました。iVIS HV-20 の設定で音声出力をカットすれば良いのだろうと考えて、設定メニューをいろいろ調べてみても、音声をカットできそうな設定が見当たりませんでした。

ビデオカメラでの配信を諦めかけてたところで、小ホールで配信していた @iogi さんからアイデアを貰いました。「ビデオカメラのマイク入力端子へ、ダミーのプラグを挿し込んでしまえばいい」というものです。実際にそれを行ったところ、輻輳の問題も解決しました。

その後は、トラブルらしいトラブルもなく、快適に配信ができました。

記録映像の作業について

配信の後は、記録映像をオンラインへアップして、いつでも誰でも見られるようにする仕事が待っています。今年はアップ先を Vimeo にしました。選択したポイントとしては、このようなものがあります。

  1. 長時間の HD 映像をアップできる。
  2. フォーマット変換が不要。
  3. 外国人の方にも比較的アクセスしやすい。

特に 2 については圧倒的に便利でした。最近のビデオカメラは AVCHD という方式で録画されるものが多いのですが、この AVCHD データを PC で使おうと思うと、実は非常に厄介です。例えばアップロード用のフォーマットが H.264 に指定されている場合、AVCHD から H.264 へフォーマット変換しなければなりません。単純な作業ですが、例えば1時間分のフォーマット変換作業が数時間かかったりします。これを3日間分ある録画データに対し、全て実行した場合に何日かかるのか、あまり考えたくない状況になります。

ところが、Vimeo は、AVCHD フォーマットのままアップロードすることができ、必要なコンバートはサーバ側で勝手に実施してくれます。また、通常アカウントではなく、有料アカウント (Vimeo Plus) を使えば、大容量の HD 映像もアップできるようになります。これにより、特に編集作業が不要な録画データをどんどんアップロードすることができました。

実際にアップロードした映像を確認して見ると、オリジナルよりは画質が落ちているものの、スライドの文字や講演者の仕草などが充分に分かりました。HD 映像は凄いと実感した瞬間です。

また、Vimeo の iOS / Android アプリを使えば、スマートフォンでも Vimeo の映像が見られることが後に分かりました。検索機能で「rk11」を探すと、いろいろ出てくると思います。これなら通勤時間などでも観ることができます。

最後に

初期の頃に比べると、Ustream 配信を行なうイベントも増えてはいますが、まだまだ情報が足りずにいろいろと試行錯誤している方も多いのではないかと思います。そういう方々に一つの事例としてこの資料が参考になれば幸いです。