はい、どーも!!

上記の広告は１ヶ月以上更新のないブログに表示されています。新しい記事を書く事で広告が消せます。

Twitterばっかりに書いてるとログがすぐに吹っ飛んでいくので、たまにはブログもかく！

今は相互配信アプリ(名称未定)というものを作成中です。
相互配信という言葉がそもそもあるのかわかりませんが、要するにグループビデオチャットツールです。
デスクトップからカメラまで相互に配信でき、音声ももちろん可能です。
お手軽かつ低遅延(1秒以下)なので、

オンラインゲームの居場所を互いに確認しあったり、
オフラインゲームを身内でやる際に進捗を伝え合うのに使ったり、
または、普通にテレビ電話のように使う


といった使い方ができます。
あくまでも身内で使うコミュニケーションツールで、不特定多数に配信するためのツールではありません。

iPhoneのリモートを作って、そろそろ飽きてきていたころに友人より依頼されたアプリです。
これまで培ってきたリモート関連のテクを総動員して作られているために、
なにやら配信アプリにしてはやたらと軽量だったりするそうです。


■アプリ概要
・最大32人で相互に配信できます。
　・ひとつのウィンドウ内にグループ参加者の配信映像が流れます。

・映像、音声の配信ができます。
　・映像ソースはスクリーンキャプチャ、webカメラから選択可能。
　・音声ソースは各入力デバイス、Vista以降の場合は出力デバイスも選択可能です。
　・ラグ１秒以下の低遅延配信

・高い接続性
　・グループ内の誰か一人がポートを開放できる環境である必要があります。
　・他の参加者に特に制限はなく、接続ができればグループ全員に配信ができます。


■簡単な技術情報
・映像、音声のエンコード、デコードにはかの有名なlibavcodec(FFMPEG)を使用しています。
・映像フォーマットは低遅延低ビットレート向けとして有名(？)なWMVを採用しています。
　・映像ビットレートは100〜520kbps、解像度はQVGAです。
　・フレームレートは1〜60の間で選択可能。
・音声フォーマットはかの有名なAACを利用します。
　・音声ビットレートは64〜192kbps、ステレオのみ。
　・WindowsVista以降ではWASAPIを利用した低遅延再生、再生デバイスからのループバック録音が可能です。
　・WindowsXPではWaveXx APIを利用して再生や録音がされます。
　・各配信の音量は専用ボリュームコントロールを用いて独立に調整できます。
　・入力は２系統選択できます。各音量は独立で調整できます。
・映像、音声の配信設定は配信中に瞬時に変更可能。(配信を止める必要はありません。)
・映像、音声ともに遅延は1秒を大きく下回ります。
・DirectShowを利用したWebカメラからの直接取り込みができます。(キャプチャーボード等は現状非対応)
・選択範囲を指定してのキャプチャ、ウィンドウを指定してのキャプチャができます。
　・選択範囲をウィンドウに追従させることもできます。
　・デスクトップをドラッグ操作によってキャプチャ範囲を指定できます。
　・マルチディスプレイ環境に対応しています。
・Windows7以降のAero環境下でも高速にキャプチャーすることができます。
・DirectXを利用した低負荷再生。(配信を見るだけならば、Core2Duoで負荷5%以下、配信時で30%以下。)
・通信にはUDPを利用します。
　・使用ポートはひとつです。
　・一人がサーバーとなる必要があり、そこに各クライアントが接続します。
　・サーバーはSTUNサーバーの役割をし、各クライアントが直接通信可能な場合はそちらを利用します。
　・直接通信できない場合はサーバー経由で配信されます。
　・サーバーは他のクライアントよりも大きな上り帯域を必要とします。(光回線推奨)
　・サーバー以外はポートが開く環境である必要はありません。


現状サーバーがそこそこ大きな上り帯域が必要、という点が弱点ですね。
各クライアント同士で直接の接続が不可能であった場合は、サーバーはすべての動画データを中継することになります。たとえば10人参加のネットワークの場合、配信に必要な上り帯域は配信ビットレートだいたい10x10=100倍にまで膨れ上がります。320kbpsの場合は32Mbpsも使うという計算ですね。
最低設定の100kbpsにしたとしても10Mbpsも使うことになります。

逆に全員が相互に接続可能である場合は、各クライアントは自分の動画を全員に配信する分だけしかアップロードが発生しないために、配信ビットレートの約10倍(正確には9倍)の帯域1Mbpsで配信することができます。

STUNを利用して各クライアント間の相互接続を試みますが、いろいろ厳しくて、市販のルーターなんかであっても、現状ポートの開いている環境間くらいでしか接続することができません。(ポートが開いていれば、そのクライアントは他の全クライアントと直接通信が可能です。)
ここをどう解決していくかが今後の課題ですね。。。

今のとこ5人程度で集まって配信したりして遊んでいますが、
その場合は320kbpsの設定でもADSL環境でサーバーをこなせるので、通常はあまり気にしなくていいのかもしれません。
10人集まって使うなんて、それこそオンラインゲームなどの用途くらい。

ふと、「1ピクセルってRGBのセル３つセットで成り立ってるんだよなぁ。なら、ピクセルをまたいでもRGBが連続して光ってさえいればそれは白に見えるんじゃないだろか？」と、思い、MSペイントで簡単に検証してみた。

■基本的な情報
・今現在の一般的な表示機器は、それぞれ自在に色を変化させることができる粒[ピクセル]の集まりでできている。
・一般的にピクセルは正方形で格子状に並んでいる。
・１つのピクセルは赤(R)、緑(G)、B(B)の3つの長方形を組み合わせてものである。
・RGBセルはR、G、Bの順番でピクセル内部に横１列に並んでいる。
・RGBセルは隙間なくびっちりならんでいるわけでなく、大体仕組みの問題で極小さな隙間があいている。

(255,255,255)はRGBすべてのセルが全開に光ってるから白色に見えます。
ならば(0, 255, 255)=水色,(255, 0, 0)=赤っていう２つのピクセルを並べて見てはどうでしょうか。
この２色をくっつけて縦線を描くと、画像の意味的には水色の線と赤の線っていう２色２本の線ですが、
表示機器からすると、RGBの順番に点灯しているか、GBRの順番に点灯しているかの違いしかありません。
(ただし、後者のBとRの間には、構造上1ピクセル内のRGBセルの間隔より広い隙間があると思われます。)


それを実際に再現してみたら次の画像のようになります。




緑から上の縦線の構造は以下の通り。
左から

1. (255,255,255)のただの白線(幅1ピクセル)
2. (0, 255, 255)と(255, 0, 0)の２色の線(幅2ピクセル)
3. (0, 0, 255)と(255, 255, 0)の２色の線(幅2ピクセル)
4. (255, 0, 255)のただの紫線(幅1ピクセル)
5. (0, 0, 255)と(255, 0, 0)の青と赤の２色の線(幅2ピクセル)

緑線以下は幅2ピクセルの線のみ左右の順番を入れ替えたものになってます。
(画像は必ず100%状態で表示してください。)


表示機器によりけりなんですが、
1,2,3は大体白に見えるはずです。
ただし、2,3は1よりも使っているRGBセルの間隔が均一ではないために、白線の両サイドに元の色が見える、みたいな状況かもしれません。
構成を左右いれかえると、あら不思議、完全に２色に見えます。
(上が２色に見える場合はBGRの順に1ピクセルが構成されているんだろうなぁ。)

それどころか、２色の間に黒線が見えるかもしれません。
2番の場合、左右入れ替えるとB,G,Rの順で0が並び、少なくとも1ピクセル分程度の大きさの黒色ができます。


4と5はGを使わなかった場合です。
白のときに比べて、4,5はほとんど同じに色に見えるかもしれません。
5番の両サイドに赤と青が見えるなんてことは少ないはず。

これは4のただの紫線の時点で間にGセル分の隙間が開いているせいと考えられます。
5番は使っているBとRのセルの間にピクセルの境界があるので、その分離れています。
つまりどっちもRとBのセルの間に隙間があるわけで、これが大体同じの表示機器の場合、この２つは同じに色に見える、というわけですな。

5番の左右を入れ替えると白色の場合以上の黒色の隙間ができるため、決して紫線と同じもののようには見えないはずです。



これがわかったところで、で？って感じですが、、、この1/3ピクセルの単位を使ってなんかできるかもしれません。

マルチモニター環境に対応すべくiPhone側のモニター選択画面作ってました。
出来は画像の通りで、Safariのタブ選択画面っぽい感じにしてみました。
見た目通りに真ん中に来てるモニターが選ばれて、完了を押すとその画面のリモートに切り替わります。
それぞれのサムネイルは静止画ではなくカクカクではあるものの定期的に更新される動画になっています。

Safariの場合は選択するとサムネイルが画面のサイズに拡大されて、ブラウザにスムーズに切り替わりますが、今回のこれはそうはなっていません。というのも、サムネイルが常に画面全体を映してないとだめなわけで、常に画面全体を写しているわけではないリモート操作時の画面とスムーズに繋げられないからです。この選択画面に入るときに操作画面を急速縮小するっていう手がありますが、多分見た目的には微妙です。

サムネイルがやや小さく見えるのは、サムネイルの最大縦横を固定しているからで、最近の横長モニターを表示するとどうしても横長になってしまいます。最大縦横が固定ってことからサムネイルの大きさは実際のモニター解像度に依存してません。この画像でいうと左のモニターの解像度は1920x1080ですが、右のは1280x800なんですが、右の方が幅固定の影響で大きく写っています。もっと解像度比を見た目で表現できればよかったんですがいいアイディアが出ず。
同じくこの画面では各モニターのピクセル的なつながりも表現できていません。プライマリモニターが実はセカンダリモニターの右にあっても、この表示になってしまいます。

モニターを実際の大きさ比で、実際の配置にならべて表示するようにしたほうがよかったかなぁ。。。


■技術的なこと
この画面はOpenGLでごりごり書いたりせずに素直にUIViewとかで作ってます。
サムネイルはUIImageViewで出していますが、問題は影。
UIViewのCALayerで影を出すってのを横見ますが、この方法を使うと激重になります。
考えれば当然で、Viewの描画のたびに影の形状を再計算しているんでしょうから、そりゃー重い。
そこで私の場合は、Quartzで影を描いたUIImageを作ってそれを表示しています。
そうすれば重いのは最初の一回だけで、以降は画像の表示だけになるんでサクサク動作になります。
(他に影を高速描画するって方法あるのかなぁ。知らないだけの可能性が高いか。)

QuartzではUIGraphicsBeginImageContextで準備をし、取り出したcontextに描画した内容をUIGraphicsGetImageFromCurrentImageContextでUIImageにできるのでそれを使います。パスに沿って図形を描画する際に影を描画する機能があるので、かなり簡単に影を描けます。単純に画像なら透明度は保存されないんですけど、こうやると透明度付き画像としてUIImageが作られるので便利。

■苦労
苦労は描画部分ではなく通信部分でした。
TCPの接続一本をリモートの画像取得とサムネイル取得を切り替えて使うわけですが、サムネイル画面への遷移はユーザー操作なわけで、レスポンスを遅らせるわけにはいかずに、即遷移させます。
つまり遷移時に前の通信の最中である場合があり、見た目とは別の部分の通信をしていることがあるというわけです。この画面を閉じるときはViewのメモリが開放されたあとに、通信が完了してデータがやってくる場合もあるので、一歩間違えればエラーで落ちてしまいます。内部で待たせたりしても、デッドロックの危険が出たりとなかなかに厄介。さらには通信が不安定な3Gでの動作も考えると、、、
ただでさえ通信とか描画などスレッドがある上に、Viewも複数あると頭がついていかなくなりますね。。。

iPhone用リモートアプリはじめました。
おもにTwitterで開発記を書いてましたが、せっかくなんでブログでもいろいろ書いてみたいと思います。

完成予定のリモートアプリの概要をまず。

■表面的な概要
・独自方式のリモートデスクトップアプリ(VNCやRDPとは互換性なし)
・Mac、Windows両対応
・部分最大30fpsの高速画面更新
・44.1kHzステレオの高音質低遅延な音声転送
・AES128bitの暗号化通信
・マルチディスプレイ環境への対応
・画面上でカーソルを動かすトラックパッドモード、Safariのようにタップした場所でクリックされるタッチスクリーンモードの２通りの操作方法
・iPhoneのIMEを使って文字を入力する方法、キーボードの入力をそのままPCに伝える方法の２通りの入力方法
・shift、alt、controlといった代表的な修飾キーや、F1〜F12、tab、esc、半角キーなどの特殊キーが入力可能

といった具合になっています。
基本的にRDPアプリにありがちな機能をほぼ網羅しているはずです。

■技術的な細かいこと
・画面キャプチャーはWindowsではBitBlt、MacではCGDisplayを使用しています。
　・Windowsはすべてのレイヤーをキャプチャーするので、高速キャプチャー時、PC側のカーソルが点滅します。
　・MacはOpenGLによるキャプチャーの方が数段高速に動作しますが、OSX Lionで使用できなくなりました。
・3G、WiFi両対応ですが、回線の応答速度の都合上3Gでは部分最大7fps程度が限度です。
・部分最大30fpsは画面全体が30fpsでキャプチャーできる性能があること、iPhoneとPC双方で30fpsで処理しきれる範囲である必要があります。(PCとiPhoneのハード性能の向上で30fpsがでやすくなります。)
・画像形式にはjpegを利用しています。(内部にはRGB565のオプションが残っていますが。。。)
　・サーバー側ではlibjpeg-turboを、クライアント側ではARM NEONを使用できるように独自に改造したlibjpegを使用しています。
　・画質は4段階用意しています。(画質20〜80)
　・グレースケールはありません。
　・動画性能の向上のために、動きの強い部分は解像度を半減させています。負荷低減により、ウィンドウのドラッグなどもスムーズに表示されます。
　・広範囲の30fpsはこの機能によるところが大きいですが、オフにすることもできます。性能によりますが、オフの場合でも20fps程度はだすことができます。
・音声はiRemoteで使った携帯電話用ADPCMコーデックをそのまま利用しています。
　・AACより独自でADPCMをエンコード、デコードした方が低遅延で動作するようです。
　・内部ではPCMをストリーミング再生しています。
　・モノラル、ステレオはもちろん、音質も11kHz、22kHz、44kHzと変更できます。
・タッチスクリーンモードはiPhoneでよくみるUIScrollViewとほぼ同様の挙動をします。
　・UIScrollViewは動作重かったので、OpenGLを使い挙動を極力似せた独自のViewを使用しています。
・トラックパッドモードではカーソルがPC側カーソルと同じ画像がiPhone側でも表示されます。
　・カーソルの動作は指の動く速度により加速度がかかったような動きをします。
・操作方法によらず、タップでクリック、ダブルタップでダブルクリック、ロングタップで右クリック、タップからのパン操作でドラッグ、ピンチアウトで拡大、ピンチインで縮小です。
・ホイールの動作は２本指パンでは動作しません。
　・ツールバーのホイールボタンを押すことでホイール専用の操作モードになります。
　・ホイールモード中は指の移動量がそのままホイール回転量になります。(指にスクロールが追従します。)

いろいろ書きましたが、独自満載でえらいことになってます。
ただし、操作方法、表示はiPhoneらしさということを最重要に考えて作っているので、いうほど独自性は感じ無いはずです。ツールバーもオーソドックスに下部配置でボタンも５つしかありません。ごちゃごちゃとボタンだらけだったり、iPhoneでは見慣れないような仕組みを使ってツールバーを出し入れしたり、複雑なジェスチャーをつけたりはしないようにしています。

そんなこんなで目指すところは、最高にオーソドックスでありながらあらゆることが簡単にできる。です。

進捗状況は現在70%程度で、完成は11月下旬、公開は12月程度を予定しています。
今後はちょくちょくブログで各機能について書いていきますんで、どうぞよろしくお願いします〜。