Brynhildr

KeroRemote

リモートデスクトップエンジニアのブログ。

デスクトップ画面リアルタイム同時配信アプリ「Refill」

コメント欄で御要望のありました、デスクトップ画面をリアルタイムで同時に配信できるアプリの公開でございます。現状ではまだ不安定の要素が多数ありますので、とりあえずプロトタイプとゆー事で御理解を頂ければと思います。もしいけそーな感じでしたら、セミナーとか勉強会とか会議とかでどうぞどうぞ。

Refill 0.1.0 Download

上の画像の用に、1つのサーバーアプリに対して同時接続が可能なのですが、上の画像は1台の端末で100個のクライアントアプリを起動して、別の端末の全て異なるTCPポートに接続するとゆー極めて珍しいパティーンです。意味不明です。絵柄的に面白そうなのでやってみただけです。ちょっとインンパクトはありますが。



で、アプリですが、例によって「refill.exe」の1つだけです。Brynhildrで言うところのサーバーモードとして起動するだけで、指定するのはTCPポート範囲とパスワードのみです。シンプルです。複数のTCPポートを用意して、クライアント1台につき1個のTCPポートを利用します。ベースはもちろんおなじみのBrynhildrでございます。画像はMotionJPEGで転送しております。通信にはTCPは利用しております。

で、クライアントなんですが「Brynhildr 2.0.0」以降と「KeroRemote」のみ接続できます。「Brynhildr 2.0.0」は、まだRC版しか出ていなくて恐縮なんですが。あくまでもデスクトップ画面配信に特化してますんで、遠隔操作や音声伝送やその他の機能の多くは無効になっております。ただ、パスワードと暗号化通信にはしっかりと対応しております。まだ「Refill」もプロトタイプですのでおかしな事が起こるかもしれませんがその際は御手数ではございますが御報告くださいませ。

あと、上の画像ですとクライアント側でBrynhidlrが100個も起動しておりまして、クライアント側のPCのCPU負荷は約100%なんですが、サーバー側のRefillのCPU負荷はともーしますと、なんと「約8%」です。数年前のCorei3のCPUを載せたデスクトップマシンですが、デフォルト設定なんで画質も悪いですし、FPSも低く設定しておりますが、サーバー側で別のアプリの操作ができるくらいに負荷が小さくまとまっております。ここ重要かなと。

但し、メモリーとの戦いでして、当方の環境ですと、同時に150台くらいの接続でメモリーがいっぱいいっぱいになります。メモリーいっぱいいっぱいの時は、接続した際にエラーでRefillが終了する仕組みです。環境に応じて、TCPポート範囲を調整ください。理論的には、TCPポート「1~65535」指定で、最大で65535台いけるはずだったんですが、完全に夢物語に終わりました。非常に残念でなりません。チッキショー。

あと、通信量も調整しないとアカンです。ちなみに、100台からの接続でも、「画質」と「最大FPS」と「ズームロック」の各設定は、サーバー側の設定したもので配信されます。設定は、タスクトレイのRefillのアイコン上で右クリックしてメニューから指定できます。ズームロックとかありますし、意外とこれ最新型です。環境に応じて自由に調整ください。

んなとこですかね。質問とか不具合とかございましたら御気軽に下のコメント欄に書き込んでくださいませ。ちなみに、名前は「Refill」 と書いて「レヴィル」と読むみたいです。

よろしくですー。




8件のコメント ... ( 管理人承認制 )



これ音声機能(+コメント機能)を搭載したらp2pニコ生みたいですね
それはそうとこれってn台で接続すると回線の使用帯域もn倍なんでしょうか
そしてもう1つまあ書いていないのでできないのでしょうけど
配信元->迂回サーバ->n個のクライアント
のように配信元以外から接続しても視聴できるような機能はないでしょうか
外で低性能端末且つ細回線で配信して自宅の高性能端末且つ太回線に一度送りそこから分岐させて視聴させられると便利なんですけど


匿名  2015/11/30


> これ音声機能(+コメント機能)を搭載したらp2pニコ生みたいですね


そうですね。ただ、インターネットで利用する事を想定しておりませんので、もしニコ生のように御利用するとしたら改良が必要ですね。


> それはそうとこれってn台で接続すると回線の使用帯域もn倍なんでしょうか


n倍ですね。途中で分配するような仕組みがあれば話は別でしょうけど。


> そしてもう1つまあ書いていないのでできないのでしょうけど
> 配信元->迂回サーバ->n個のクライアント
> のように配信元以外から接続しても視聴できるような機能はないでしょうか


開発したアプリに中継サーバーの「DyneCloud」というものがありまして、プロトコルは同じ仕様ですので、こちらを改良する事で、上にも書きました分配が可能となります。


ただ、この「Refill」は、イントラネットでの利用を想定しており、設計に基づきもし音声伝送を可能にするとしますと形式はPCMとなります。映像はMotionJPEGで、音声はPCMとなりますと、インターネットを介した配信ではまるで不向きでして現実的ではありません。


ニコ生のように不特定多数の方が視聴するようなケースを考えると、やはりブラウザで視聴できた方が良いと思いますし、映像や音声のコーデックは異なるものを利用したほうが良いと思います。


> 外で低性能端末且つ細回線で配信して自宅の高性能端末且つ太回線に一度送りそこから分岐


なるほど。ちょっと面白そうですね。頭の中では何となくできるような気はします。が、当方でのキャパシティ的に非常に難しく、協力して頂ける企業様がいらっしゃらないと完成させる自信がありませんw
宜しく御願い致します。


IchiGeki  2015/11/30


RTSPでUDPマルチキャストしてしまうのがいいんじゃないかと。
VIDEOタグ使ってブラウザに配信できますし。


電子猫  2015/12/01


> RTSPでUDPマルチキャスト


そうですね、不特定多数に配信であればそのようなスタイルがベストではないかと思います。


Refillは、リモートデスクトップのBrynhildrの通信制御をそのまま利用していますので、TCPで独自プロトコル(独自コンテナ)ですし、そもそも複数配信を想定しておりません。「Brynhildr 2.0.0」ではVP8に対応しておりますが、キーフレームを利用していないので、他と比べて圧縮率が高いと思います。同時配信となるとキーフレームは必須となるでしょうし、その辺も考慮したコーデックや通信制御が必要になるかなとは思っております。何か別の凄いアイデアが出れば良いのですが。ですので現状では、フレーム全てがキーフレームであるMotionJPEGのみ対応となっております。


宜しく御願い致します。


IchiGeki  2015/12/01


以前にこの欄でお願いをしたものです。
あっという間にRefillというフリーソフトを開発してくださってありがとうございます。すごいですね、本当に助かります。
これから試してみたいと思います。また報告させていただきます。


kankan  2015/12/08


> すごいですね、本当に助かります


いえいえ、ちょっとまだ改善させたい部分がありまして、バージョンアップを予定しております。次期版との利用方法に大きな違いはありませんが、まずは動きを御確認して頂けますと幸いです。宜しく御願い致します。


IchiGeki  2015/12/08


videoqualityですが、前回起動時の設定を記憶していないようです。
refill.iniの中にも該当する項目が存在しません。
他の項目と同様にrefill.iniにvideoqualityの値を設定できるようには出来ませんか?


shigesan  2016/06/25


> videoqualityの値を設定できるようには出来ませんか?


誠に恐れ入りますが、現在のところRefillは各種設定を保存をしておりません。ただ、時間を見つけて対応させて頂きたいと思いますので暫く御待ちくださいませ。宜しく御願い致します。


IchiGeki  2016/06/25




... 不具合報告の際は、アプリのバージョンやOS等の動作環境の記載を御願い致します。

表記されている会社名・製品名・システム名などは、各社の商標、または登録商標です。
当サイトはAmazon.co.jpアソシエイトプログラムに参加しています。
Copyright (C) IchiGeki All Rights Reserved.