超圧縮。
えー、ちょっと前にも書きましたけど、TrueRemoteにはついている「超高速」が、Brynhildrにはついていない事についての補足とゆーか御説明出来る内容が増えたよゆーかそーゆー時期とゆーかそんな感じです。
Brynhildrの映像圧縮エンジンは、TrueRemoteのGaeBolgVideoCodecをベースにしたものなのですが、これが２年くらい前からあんまり進化しておりません。その間は別に何もしてなかったという事では無いのですが、まず音声伝送の部分を作っていたという事があります。仕事の合間合間なので集中して開発できていなかったという事もありまして結構ズルズルな感じで伸びていましたがようやく完成してました、数か月前に。それでBrynhildrが公開できたワケです。
で、肝心の映像圧縮エンジンについてですが、Brynhildrには暗号化通信の処理があるので、その分映像圧縮展開処理が遅くなってしまっているというのは前に御説明したかと思います。映像圧縮エンジンの高速化は予定はしておりますが、もう少し先のお話で御座います。一応、高速化の内容までは決まっておりまして、これまでまったく使っていなかったMMXやSSEなどのCPU拡張命令を使う事や、C言語で書かれている圧縮展開エンジンのアセンブラ化、通信部分の最適化などなどです、まだ未定内容ですけど。だいたい倍くらいにはなってくれるのでは無いかと希望的観測です、全然わかりませんけど。
が、しかしどれだけ速度が速くなっても残り課題があります。
「圧縮率」です。
ここがGaeBolgVideoCodecの最大の欠点である事は随分と前から気づいてはいたのですが。上に書いてあるような処理性能が向上していくら処理速度が倍になっても、通信量も倍では全然面白くありません。ましてや映画とかアニメとかゲームだととんでもない通信量になってしまいます。全然エコじゃありません。
そこで２年くらい前から開発してきたものが、「超高速」ではなく
「超圧縮」です。
超ってついてますけど別に世紀の大発見的な感じでも何でも無く、いたって普通の映像圧縮だったりするんですが。とは言いつつもこれまでのGaeBolgVideoCodecと比較すると、映像データのサイズが約1/10～1/100になるので超圧縮なんですけど。そんな映像超圧縮エンジンの開発をここ２年間ほど、夜中を中心にゲームをしながらとか映画を見ながらとかモタモタと開発してきたわけで御座います。ちなみに開発コードは「叢雲」で御座います。
映像圧縮とありますが、GaeBolgVideoCodecは仕組み的には、「画像圧縮＋差分処理」に過ぎず、本格的な映像圧縮となると、特許の絡みでまず個人事業主レベルが手を出す分野では無いよーな感じです。てかそもそも技術的にもレベルが高く、自分では全く手が出せないところではあるんですけど。数学は【計り知れない強さ】です。
そこで、世に出てる映像圧縮アルゴリズムを利用しよーと思ったワケで御座います。いやこれが結構、選定とか調査とかライセンスとかコンパイルとかコンパイルとか大変で御座いました。画質とか処理速度とかも重要なので、色んな要素をひっくるめてムムム・・・となっていわワケで御座います。
まー例えばあれですかねー、「H.264」とかー王道中の王道なんですけど、開発で使うとなるとx264とかなんでしょうけど、GPLライセンスなんで静的リンクだとソースコード公開が義務化とかで大変ですし、MPEG-LA社保有の特許の絡みがあるのでそこはx264LLCと契約とかなっても費用もかかるワケで大変ですけど、そもそもx264LLCとの契約書の英語が読めませんし。正直、詰んでます。使いたいですけど使えません。
さて・・・どうしよう？やっぱ自作？
ちょっと長くなってきたので、続きは後日！
Brynhildrの映像圧縮エンジンは、TrueRemoteのGaeBolgVideoCodecをベースにしたものなのですが、これが２年くらい前からあんまり進化しておりません。その間は別に何もしてなかったという事では無いのですが、まず音声伝送の部分を作っていたという事があります。仕事の合間合間なので集中して開発できていなかったという事もありまして結構ズルズルな感じで伸びていましたがようやく完成してました、数か月前に。それでBrynhildrが公開できたワケです。
で、肝心の映像圧縮エンジンについてですが、Brynhildrには暗号化通信の処理があるので、その分映像圧縮展開処理が遅くなってしまっているというのは前に御説明したかと思います。映像圧縮エンジンの高速化は予定はしておりますが、もう少し先のお話で御座います。一応、高速化の内容までは決まっておりまして、これまでまったく使っていなかったMMXやSSEなどのCPU拡張命令を使う事や、C言語で書かれている圧縮展開エンジンのアセンブラ化、通信部分の最適化などなどです、まだ未定内容ですけど。だいたい倍くらいにはなってくれるのでは無いかと希望的観測です、全然わかりませんけど。
が、しかしどれだけ速度が速くなっても残り課題があります。
「圧縮率」です。
ここがGaeBolgVideoCodecの最大の欠点である事は随分と前から気づいてはいたのですが。上に書いてあるような処理性能が向上していくら処理速度が倍になっても、通信量も倍では全然面白くありません。ましてや映画とかアニメとかゲームだととんでもない通信量になってしまいます。全然エコじゃありません。
そこで２年くらい前から開発してきたものが、「超高速」ではなく
「超圧縮」です。
超ってついてますけど別に世紀の大発見的な感じでも何でも無く、いたって普通の映像圧縮だったりするんですが。とは言いつつもこれまでのGaeBolgVideoCodecと比較すると、映像データのサイズが約1/10～1/100になるので超圧縮なんですけど。そんな映像超圧縮エンジンの開発をここ２年間ほど、夜中を中心にゲームをしながらとか映画を見ながらとかモタモタと開発してきたわけで御座います。ちなみに開発コードは「叢雲」で御座います。
映像圧縮とありますが、GaeBolgVideoCodecは仕組み的には、「画像圧縮＋差分処理」に過ぎず、本格的な映像圧縮となると、特許の絡みでまず個人事業主レベルが手を出す分野では無いよーな感じです。てかそもそも技術的にもレベルが高く、自分では全く手が出せないところではあるんですけど。数学は【計り知れない強さ】です。
そこで、世に出てる映像圧縮アルゴリズムを利用しよーと思ったワケで御座います。いやこれが結構、選定とか調査とかライセンスとかコンパイルとかコンパイルとか大変で御座いました。画質とか処理速度とかも重要なので、色んな要素をひっくるめてムムム・・・となっていわワケで御座います。
まー例えばあれですかねー、「H.264」とかー王道中の王道なんですけど、開発で使うとなるとx264とかなんでしょうけど、GPLライセンスなんで静的リンクだとソースコード公開が義務化とかで大変ですし、MPEG-LA社保有の特許の絡みがあるのでそこはx264LLCと契約とかなっても費用もかかるワケで大変ですけど、そもそもx264LLCとの契約書の英語が読めませんし。正直、詰んでます。使いたいですけど使えません。
さて・・・どうしよう？やっぱ自作？
ちょっと長くなってきたので、続きは後日！
Verethragna
KeroKeyboard