Ai-Ballをハックする超小型無線LAN内蔵カメラAi-BallでiPhoneから自宅を監視可能にするでも紹介されていましたが、Ai-BallのようにMJPEGストリームを送信できるカメラが楽しいです。ここではその映像をandroidで受信する方法について紹介します。利用形態は左図のようなイメージです。AsyncTask」で既に紹介されています。Collectionが一秒間に多数回実行される端末によっては映像の遅れが1秒以上起こるとなり、少し性能が物足りないです。Viewer」がありますが、これも同様の問題を抱えています。この問題を解決するため、その高速版として「SimpleMjpegView」を作成して公開しました。Playからダウンロードできるようにしました。Play)メモリ使用量を削減し、jpegのデコードにJNI経由でlibjpegを利用しているのが主な変更点です。上記の問題に対しては下記のように解決されています。1秒)このコードをベースに作成したのが下記の、WifiカメラAi-Ballを搭載したプラレールです。2012にて展示させて頂きました。ここでは、そこでの体験なども含め、MJPEGストリームをAndroidで表示する方法についてまとめてみたいと思います。Ai-Ballが用いている方式で、カメラ自体がアクセスポイントになります。メリットはとにかく小型であることです。Planexからも多数のネットワークカメラが発売されていますが、それらで動作するかは試していません。URLはデフォルトではhttp://192.168.2.1:80/?action=streamとなります。WebcamというフリーソフトをインストールしてWifiカメラ化し、そこからの映像をWifiルーター経由で受信するという方式です。(1)よりも無線が安定するのではないかと導入してみました。URLはデフォルトではhttp://192.168.x.y:8080/videofeedとなります。(3)スマホ(テザリング)+スマホ(2)と同じですが、Wifiルーターの代わりにスマートフォンのテザリング機能を用いるものです。部品点数が減るのがメリットですが、送信側のスマートフォンの電池持ちが悪くなるのがデメリットです。streamerというソフトウェアを導入して、UVC対応のUSBカメラの映像をルーター経由で送信します。様々なカメラを用いることができるのがメリットですが、PCとカメラを有線接続する必要があるため、規模が大きくなるのがデメリットです。Piで使っている方々がいらっしゃいます。Pi専用のカメラモジュールを用いる方法です。画質も良いのでお勧めの方法です。下記で解説しています。overflowで公開されているサンプルと、性能改善したSimpleMjpegViewとで性能を比較したのが下記の表です。Ai-Ballを用いました。解像度640x480、30fpsの映像が送られてきます。手元にあった端末が全てカスタムOSが載ったものだったのですが、結果は公式OSでも変わりません。OSのバージョンにもあまり依存しないようです。オリジナルのサンプルから。1ここで見るべきポイントは以下の通りです。(GC)が実行されるフレーム数はそれほど悪くないが、1秒以上の映像の時間遅れがある端末がある新しい端末の方が性能が良いとは限らない。Arcの性能も良い一方、性能改善したアプリでは下記のようになります。1見るべきポイントは下記の通りです。上の表で見た通り、映像表示の性能には端末による差があり、なおかつ新しい端末の方が性能が良いとは限らない、という現象が見られます。性能改善したSimpleMjpegViewを用いる場合、映像表示するだけならそれほど差は見られませんが、上のプラレールの動画のように、画像処理に基づいて制御を行う場合、微妙な性能差が結果に影響を及ぼすことがあるので注意が必要です。下記の端末で特に性能が悪かったのが印象的です。Arcを用いているのは、古い端末で安価に入手できるにも関わらず映像表示の性能が良いためです。S3の価格が下がって入手しやすくなればそちらに乗り換えるかもしれません。この端末による性能差の原因はわかっていませんが、ハードウェアの違いやkernelのドライバに起因する問題ではないかと現在のところは考えています。Wifiの干渉についての体験記このようなWifiカメラの利用法の一つとして、自作のロボットなどに搭載して遊ぶ、というものが考えられます。個人で遊ぶぶんには何の問題もないのですが、大勢の人が集まる展示会でデモしようとすると、Wifiの干渉により映像が遅れるなどして、期待の動作をしないということがあります。この現象は個人で再現することがなかなか難しく、有効な対策ができない場合が多いのですが、ここでは私が展示会で体験した経験をいくつか紹介したいと思います。結論から先に述べると、「利用形態」の(3)で紹介した「スマホ(テザリング)+スマホ」が、Wifiの干渉に最も強い組み合わせでした。Arcで受信しました。この場合、映像が3~5秒くらい遅れて届いたため、画像処理に基づく制御はあきらめ、Bluetooth経由での手動制御を中心に紹介しました。Ai-BallはWifiのチャンネルを手動で変更する機能がついているのですが、それを行っても焼け石に水という感じでした。Ai-Ballでの展示はあきらめ、「利用形態」(2)で紹介した「スマホ+ルーター+スマホ」の組み合わせで行いました。Webcamを入れてWifiカメラ化し、プラレールに搭載します(左図)。結果はボチボチ、といったところでした。カメラの映像は基本的にはスムーズに届き、画像処理に基づく制御もうまく機能しました。不安定で、1~2分おきに映像が届かなくなる現象が起こりました。そんなときはルーターとスマホの位置関係を変えると突然映像が復帰することが多かったので、そのまま展示を続けることができました。不安定ではありましたが、少なくとも昼から17時までの展示はなんとか乗り切ることができました。2012の2日目です。前日と同様に「スマホ+ルーター+スマホ」の組み合わせで行こうとしたのですが、前日と異なり映像が頻繁に途切れてうまく流れません。想像ですが、恐らく会場では私と同様に2.4GHz帯の無線を使って何かデモをしようとした方が大勢いらっしゃったと思います。初日に無線の干渉の問題でデモに失敗した方が、2日目にリベンジとして別の無線機器を持ち込んだ、ということがあったかもしれません。いずれにせよ前日の組み合わせではうまくいかなかったので、「利用形態」の(3)で紹介した「スマホ(テザリング)+スマホ」の組み合わせを試してみたところ、(何故か)非常に安定して映像が送受信でき、終日それで乗り切りました。1日目のルーターを噛ませる場合に比べて安定性はかなり上でした。Webcamも動作させました。テザリングはdocomoの公式OSでもカスタムOSでも問題なくできます(SIMは刺さずにデモしました)。電池の持ちは悪いので予備バッテリーは必須です。10:00~17:00の展示で、Rayの電池は2回交換したと思います。Wifi干渉についてのまとめ以上、展示会3日分の体験を紹介しました。少なくともこの3日間の体験から判断するなら、安定性は「スマホ(テザリング)+スマホ」で決まり、なのですが、もう少し検証をしたい気もします。展示会ほど無線が飛び交う状況をなかなか作れないので、新たに展示会に出展することでしか検証は難しいのですが。あと、この3日間で用いた無線の規格は802.11gか11nのどちらかです。802.11aを用いたらどうなるだろう、という興味もありますが、この場合、映像の送信側も受信側も802.11aに対応している必要があります。SXが小型で11aに対応しているので送信側に適してそうな気がしています。おしまい以上、私自身の体験も交えてWifiカメラからのMJPEGストリームをandroidで表示する方法についてまとめてみました。気が向いたら、画像処理の方法(ピクセルを直接いじる方法、OpenCVを用いる方法)や複数個のカメラからの映像を一つの端末で受信する方法などについても書いてみたいと思います。18:50はじめまして。私は、無線LANでのリアルタイムで画像を送信する技術に興味があり、上のリンクからダウンロードさせていただき、Eclipseでインポートしてみました。そのアプリにボタンを付けたいのですが、activity_main.xmlを使ったことしかないのでやり方がわかりません。素人の突然の質問で大変申し訳ないのですが、少しでもヒントをいただけましたら幸いです。22:39せっかくなのでレイアウトにxmlを用いる方式に変更してみました。10:34はじめまして。ストリーミングを実験しています。Androidへストリーミングするさいに、SimpleMjpegViewerを改造して利用させていただきました。ありがとうございます。m(__)m改造したソースコードを以下にて公開いたしましたが、もし問題がありましたら削除いたします。12:40連絡ありがとうございます。ご自由にお使いください。