[Oculus]3D動画をストリーミング再生する方法 – 12 –

前回の記事では、通信処理に Socket.IO を用いることで fps の改善を図りました。
今回は、前回の記事から3点、試行錯誤を行った結果について掲載させていただきます。

■画像のフォーマットについて
 Androidのカメラで撮影した画像は、形式が「YUV」というものになっています。
 今回の調査で、このままの状態のデータだと、サイズが非常に大きいことがわかりました。
 前回は、これをJPEG画像に変換していましたが、この画像を更に小さいサイズにすることが
 できれば、fps の改善を図れると考えました。

 Androidでは、YUV形式の画像から変換できるフォーマットに、以下3種類があります。
  JPEG
  PNG
  WEBP

 そこで、PNG、WEBPそれぞれにデータを変換し、fpsがどのようになるのか測定したところ、
 PNGは、JPEGに比べてファイルサイズが大きくなり、結果的に fps が落ちました。

 WEBPというのは、Googleが開発している静止画フォーマットです。
 こちらに変換を行ってみたところ、同一環境下の場合、JPEGと比較して2割~3割、
 画像サイズが小さくなりました。
 ただし、そもそもの変換処理が遅く、通信ではなく、そちらのほうで遅延が発生し、
 結果として fps が落ちてしまいました。(数fps程度にまで落ちてしまいます)

 よって、最適なフォーマットは前回利用していたJPEGという結論になりました。
 このため、フォーマットを変更することでの改善は見込めませんでした。

 ただし、リアルタイムに動画を配信するという仕組みにおいては
 WEBPを利用することはそぐわなかったですが、
 大量の枚数の画像を、サーバに保存しておく場合には、
 JPEGよりも容量の軽い、こちらのフォーマットのほうが適しています。
 今後、開発を進めていくうえで、WEBPを利用するシーンが出てくるかもしれません。

■画像の圧縮率について
 JPEG画像を作成する際、圧縮率を設定することができます。
 0~100の間で指定することができ、数値が小さいほうが、より画像サイズが小さくなります。

 詳しい話は、他者様のページに詳しく記載があるので割愛しますが、
 動画をリアルタイムで再生するという用途であれば、
 最低でも75の圧縮率はないと、品質的に問題があります。

 数値を下げるほうが効果は上がりますが、品質は下がるため、
 今回はひとまず80とし、この値を今後、どうしていくのかは、
 さらに色々と改善を図った後で、最後に決定しようと思います。

■画像を1秒単位でまとめて送信する
 複数の画像を一度にアップロードする方が、通信負荷を低減でき、速度が改善する
 のではないかと推測し、画像データを複数枚、端末で保持しておいた後で、
 1秒単位で一度にサーバに送信するように、修正してみました。

 現在、Socket.IOの通信部分はブラウザ(HTML)で実施しており、
 画像の送信については、form 部品の text タグに、
 画像データを Base64 変換したものを設定しています。

 クライアント側は単純に、text タグの数を複数用意して、すべてのタグが
 埋まったところで送信するようにし、サーバ側ではその画像を一気に保存、
 所定の枚数に達した時点で動画変換を行う
 というようなロジックに修正しました。

 この結果、画像サイズ「512×384」で20fps迄、性能を改善することができました。
 ※前回は、画像サイズ「448×336」で15fps


図1 200枚の画像が10秒でアップされています


図2 画像サイズが「512×384」となっています

■今後の改善について
 ここから先、さらにfps値を改善していくためには、
 今のところは主に、携帯端末側と、サーバ側のボトルネックとなっている部分を
 1つ1つ、改善していく必要がありますが、
 どこがボトルネックとなっているのかを、まだ把握できていません。

 次週は、現段階の仕組みでの、各部分に要している時間を計測することで、
 今後、どこを改善していくのかをまとめようと思います。


弊社では全国各地の請負い(ご自宅)で作業協力頂ける、フリーランスエンジニアの方を常時探しております。
ご興味ある方は、お気軽にお問い合わせ下さい。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*