16年前のWeb会議

Web会議のご先祖様ってなんでしょう?

テレビ会議?テレビ電話?……いくつか切り口があると思いますが、ここでは汎用的なコンピュータやカメラを使って会議をする、という点から時間を遡ってみたいと思います。

下の写真は、いまから16年前に私が研究開発していた多拠点映像会議システムの実験風景です。

cannon.png

机の上にコンピュータとディスプレイ、ディスプレイの上にカメラが設置されていますね。このコンピュータはパソコンではなく、サン・マイクロシステムズのワークステーション。当時のパソコンはまだWindows95の時代で、高度なネットワーク処理や映像処理にはワークステーションと呼ばれる専門的なコンピュータを必要としていました。このときのもので、だいたい1台200万円くらいではないかと思います。

カメラは、Canon の VC-C1 ですね。41万画素、といういまのWebカメラではもう考えられないくらい少ない画素数ですが、こちらも1台20万円ほどのものでした。

同じようなシステムを今では、数万円のPCと数千円のWebカメラで実現できるようになりました。僕が16年前を振り返ってみると、このことは単に価格が安くなった、普及しやすくなったというだけでなく、僕らがいつ、どんなふうに映像でやりとりするのか、という映像の使いこなしに大きな影響を与えているように思われます。

 (この項、つづきます)

自分の顔を見ながら話す

Web会議ではたいてい相手の顔だけでなく自分の顔も画面に表示されるようになっていますね。

これはどうしてでしょうか?
よく考えてみると、僕らは普段、実際に人と会って話をするときには自分の顔を見ることはありません。(相手の背中に鏡でもあれば別ですが。)

VNV_20130915.jpg

上のスライドでは、その理由のごく一部について触れています。

遠隔地間のコミュニケーションで送受信できる情報は限定されていること(撮影範囲、鮮明度、映像や音以外の情報について)、僕らがどういう場面でなんのためにこのようなシステムを使うのかということ(会社で?プライベートで?)、僕らがどれくらいカメラ越しのコミュニケーションに慣れているかということ(なんだか恥ずかしい?慣れると対面より話しやすいことも?)、など、自映像を表示することには技術やメディア、そして暮らしについての様々な要素が関係しています。

ヴァーバル・ノンヴァーバル・コミュニケーション研究会では例えばこうしたことを議論しています。
このつづきは、またの機会に。

ヴァーバル・ノンヴァーバル・コミュニケーションとWeb会議

ときどき研究者のかたとお話すると、Web会議のような映像と音声、資料を中心とした遠隔地間コミュニケーションにおいて、どういう現象が起こっているのか、興味をもって聞いていただけます。

私自身も、ヴァーバル・ノンヴァーバル・コミュニケーション(VNV)研究会(電子情報通信学会 HCG 第3種研究会)
という場で議論に参加させていただいています。以前は研究者としての参加でしたが、いまは企業の立場での参加となります。

最近の興味については先月のVNV研究会で話題提供させていただきました。またこちらのブログでもその時の話を少しずつ書いてゆければと思います。

なにせVNVは4時間しゃべりつづける場なので、盛りだくさんですよ……。

CEATEC2013出展

10月1日より4日まで、CEATEC2013へ出展していました。ブースへお越しくださった皆様、ありがとうございました。

例年出展していますが、4年前のCEATECに比べると、展示できるものが増えたな、と思います。

こちらが今年2013年の弊社ブース。Web会議 SaasBoard、スマートフォン版 SaasBoard/SP と、ビジュアルコールセンター “もしもしConcierge” を展示しています。

45571_10201905902911693_2586795_n.jpg

こちらが2010年のときのブース。たしかこのディスプレイとノートPCとで早稲田とつないで、SaasBoardのWeb会議デモをやっていたように記憶します。いまはスマートフォン・タブレットを並べていますので、時代の変化も感じられるところですね。

ceatec101005-01-320.jpg

展示に書き文字が入るのは相変わらずです。今年もこんなんでした。

603941_10201911912421927_2094551242_n.jpg

周りのブースはフォーマルな展示が多いので、ときどきこういう手作り要素が入ると、アピールできるように思っています。

iOS7でのマイク利用

iOS7ではサードパーティーアプリからのオーディオ・ビジュアル機能の利用方法が変わりましたね。

moshimoshi_mic.jpg

弊社のiOS版アプリ、SaasBoard(Web会議)でも、もしもしConcierge(ヴィジュアルコールセンター)でも、Papaar(ペーパレス会議)でも、利用者の音声をマイク入力して通話します。iOS7ではアプリがマイク入力を利用するとき、ユーザがそれを許可するか確認するダイアログが表示されるようになりました。弊社の前記サービスをご利用される場合は【OK】を押してください。仮に【許可しない】を押しますと、アプリ側でマイクがONになっていても音声入力されません。

世の中には利用者の許可なく盗聴をはじめる悪いアプリも混ざっているかもしれませんので、あらためてOS側が確認ダイアログを出すのは良いことだと思います。

ダイアログが表示されるのは各アプリにつきはじめの一度だけで、以降ははじめに選択した結果 【許可しない】 or 【OK】 を覚えており、それが適用されます。

選択結果を後から変更したい場合は、iOSの「設定」を開きます。
「設定」->「プライバシー」->「マイク」を選ぶと下のような画面が出てきて、アプリごとに 【OK】 と 【許可しない】 を変更できます。緑色になってると【OK】。

2013-09-20 12.03.35.png

アプリが立ち上がっている間は変えられないことがあるので、アプリは一旦、完全に終了させたほうがよいです。

しかし、このプライバシー設定における 【許可しない】 【OK】 の設定は、アプリをアンインストールして再インストールしてもまだ消えずに残っていますね。

あと、アプリがマイクを利用するときユーザの許可を求めるようにしたのは判るけど、カメラ映像を利用するときも同じようにしなかったのはなぜ?

SaasBoard ver 3.11リリース

27日より接続性や使い勝手を強化したSaasBoard ver 3.11をご提供しています.

技術的なところでは,SaasBoardは自動的に適切な接続先ポートを選ぶようデザインされているのですが,運用上のご要望や,あとどうしても「自動」では漏れてしまう場合をフォローするために,手動でも設定できるようにしました.

エコー/ハウリング抑制機能も現在試験中です.


このほか急ピッチで新機能の開発を進めており,忙しくもにぎやかな夏になりそうです!

DBIx::Class::ResultClass::HashRefInflatorが無視されるケース

$rs->result_class(‘DBIx::Class::ResultClass::HashRefInflator’);
がときどき無視されてしまうのはこれかー.
http://lists.scsys.co.uk/pipermail/dbix-class/2008-February/005733.html

the custom result_class is written *only* into the $rs->{result_class} slot (by the result_class() accessor/mutator generated by Class::Accessor::Grouped), whereas when ResultSet->new() is (secretly) invoked to build the resulting resultset (yes, new() is called even on a simple find() with some \%attrs), the custom result_class is searched
*only* in the $rs->{attrs}{result_class} slot (please see ResultSet.pm line 101), which however is never assigned by the result_class() mutator. Consider also that ResultSet->new() is invoked this way ( from a ResultSet instance – for example by search_rs() ):
my $rs = (ref $self)->new($self->result_source, $new_attrs); so once in new() we’ve lost $self and the opportunity to read its result_class slot, which is why it should have somehow been copied into $new_attrs->{result_class} before calling new().

なんだってー!
まぁ,いかにもCatalyst的に起こりそうな不具合なので,もっと早く調べておけば良かったな.
DBIx::Class::ResultClass::HashRefInflatorはもともとラッパ関数経由で使っているので,そこんとこを
 $rs->result_class(‘DBIx::Class::ResultClass::HashRefInflator’);
 $rs->{attrs}{result_class} = ‘DBIx::Class::ResultClass::HashRefInflator’;
に変えて対処.
これまでここんとこでくねくねしてたので影響でかいわ.