スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« アイデアは色々とあるんだが | トップページ | 2016年はPCを買う? »

やっぱりストリーミングかな

今は、Mirror-DTCの次バージョンを開発中なのだが、昨日書いた様に、目玉候補の新機能を色々と鑑みていたのだが、どうもパッとしない。なので、ずっと前から書いていたストリーミングモードを、今回、追加する事にする。このため、バージョンは1.2.4ではなく、1.3.0にする。

ストリーミングモードという言葉自体は、今回、初めて使っているのだが、要は、フレームレート優先の転送モード、という事になる。

イメージ的には、画面変化が殆ど無い場合には、最高画質での転送、画面変化が大きくなるにつれ、映像圧縮の高画質→バランス→高圧縮みたいな感じで、画質は低下するものの、圧縮率を向上させる事で、フレームレートの低下を防ぐモードになる。

ただし、現行のMirror-DTCには、AGM形式のDCT相当の映像圧縮があるのだが、より圧縮率が高いDCT+は採用していなかった。このため、今回、DCT+も採用する格好にする。

で、DCT+というのは、品質を低下させても、動きのある動画については、それなりに見ていられる様に鑑みた圧縮形式なので、品質値をデフォルトの50ではなく、0にしても、フルHDクラスの画素数があれば、見ていられる映像になる。

それでは、DCT+を採用すると、どの程度の圧縮率が得られるのか、というと、この前リリースしたAG-デスクトップレコーダー Ver1.3.0で、動きが激しいフルHDの60FPS動画をキャプチャーした25分くらいの動画があるのだが、そのmp4バージョンは、4671MBになっている。

で、それを品質値50のDCT+に再エンコードすると、ファイルサイズは2412MB、つまり、半分くらいになっているのだが、更に、品質値0のDCT+に再エンコードすると、ファイルサイズは1295MB、つまり、更に、その半分になっている。

同じ動画は、DCTの品質値50、つまり、Mirror-DTCの映像圧縮(高圧縮)相当で再エンコードしたとしても、4848MBにしかならない。

と、いう事なので、DCT+を採用する事で、Mirror-DTCの映像転送の圧縮率は、それなりの画質を保ちながら、現行版の4倍程度まで、強化できる事になる訳なので、巷のSplashtopなんかのリモートデスクトップソフトと比べても、画質は若干劣る事になる筈なのだが、エンコード負荷や圧縮率では、引けは取らなくなる筈だ。

にもかかにらず、今回まで、このDCT+をMirror-DTCに導入して来なかったのは何故なのか、というと、少なくとも、Aeroが停止できないWindows8.1/10では、全画面キャプチャーを行おうとするとFPS値が低くなったし、領域指定してFPS値を上げた場合には、データ量が少なくなるので、現行の映像圧縮でも必要十分な圧縮率が得られていたからだ。

更に言えば、DCT+というのは、DCTよりもエンコード負荷が高いので、状況的に必要でもないのに、これを採用すると、軽さが売りのMirror-DTC的には、悪印象しか与えない、と、考えたからだ。

で、そのDCT+を、今回採用する事にした理由は、まず、AmuseGraphics Ver1.3.0系の開発時の記事を読んでいる人には判る筈なのだが、この開発で、DCT+のエンコード負荷を重点的に軽くしたので、現状では、総合的には、DCTと比べても遜色ないくらい、処理負荷を軽く出来ているからだ。

また、Desktop Duplication APIを使用する事で、Windows8.1/10でも、画面のキャプチャーレートについては、全画面キャプチャーでも、60FPSまで問題なく行える様になっているので、ボトルネックが従来のキャプチャーレートではなく、データ転送サイズ、つまり、エンコード部の圧縮率になっているからでもある。

と、いう事なので、真面目にDesktop Duplication APIに対応させようとすると、作者的には、DCT+の採用は自然な行為になる訳なのだが、何故、それを躊躇っていたのか、というと、DCT+というのは一般動画の視聴用なので、画質的には、デスクトップ操作には向かないからだ。

具体的には、画像変化時に、以前のフレームの残像がゴミとして一定期間残る事が多いので、自然画では、あまり気にならないものの、くっきりとしたテキスト表示のスクロール映像なんかでは、ゴミがはっきりと見えてしまうので、宜しくない訳だ。

なので、今回、DCT+を採用するといっても、単純にデスクトップ映像をDCT+でエンコードしてクライアントに転送するだけでは済まないので、作業量的には多めになりそうなので、作者的には、やりたくは無かったのだが、サーバーにShell機能を実装する事を鑑みれば、どうという事のない変更量になる筈だ。

多分、2,3日もあれば、とりあえずの実装は終わるので、ストリーミングモードの扱いをどうするかは、その結果を見てからにする事にする。

ちなみに、何故、ストリーミングモードというネーミングにしてあるのか、というと、以前から書いている様に、即応性が要求されるリモートデスクトップソフトでは、普通は、滑らかな映像転送は不可能だからだ。

何故なら、データのバッファリングが許されないので、WiFiなんかでリトライが発生するだけで、0.1秒程度は映像転送が停止するからだ。

つまり、ストリーミングモードというネーミングにしてあるのは、滑らかな映像転送を行う事の優先度を上げるので、基本的には、データのバッファリングも可能にする予定なので、バッファリング量によっては、遅延が大きすぎて、用途は微妙になるからだ。

まあ、遅延が大きすぎるといっても、AGMPlayerでも、数MB分のデータしかバッファリングしていないにも関わらず、十分な安定性があるので、1秒も遅延させれば、十分かもしれないし、0.5秒未満でOkなら、普通の用途にも使える筈ではあるのだが。

と、いう事で、今日は大みそかなので、早めに記事を書いたのだが、明日は元日なので、やはり、あまり真面目な作業は出来ないかもしれない。

= この記事に関連する公開中ソフト =

Mirror-DTC

Mirror-DTC

(2016/05/04追記)

« アイデアは色々とあるんだが | トップページ | 2016年はPCを買う? »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/62975636

この記事へのトラックバック一覧です: やっぱりストリーミングかな:

« アイデアは色々とあるんだが | トップページ | 2016年はPCを買う? »

2017年6月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google