2009年11月22日
ONScripter for PSP テスト版２
前回の JPEG の制限ですが、七次元さんの言ってたみたいに、
PSP の API の方でエラー出した時は LIBJPEG でデコードする様にしました。
これで対応してない形式だったりサイズだったりしても、
PSP の API を使った程ではありませんが通常よりは速いです。
続いて今回の目玉。
どんな機種でもムービーが再生可能な連番ムービーですが問題もあります。
動画のフレームを１つ１つを画像ファイルにするので、
アーカイブ化しないとコピーやらディスク上のサイズやら問題が出ます。
アーカイブ化したらしたで、ONS 側のファイルインデックスを大量に消費するので、
インデックスの為のメモリが増え、他のファイルの検索性を損ないます。
そこでファイル単一でムービー再生が可能な SMJPEG ですが、
こちらは音声が ADPCM なので音質が悪くサイズも大きいです。
先日出したテスト版の方では改善されてますが、
デコード速度の問題で音飛びやノイズなどが入ったりもしました。
そこで考えたのは MJPEG + OGG や MP3 でした。
SMJPEG の形式に習うのは面倒だったので独自形式に。
JPEG のデコードと描画は PSP の API の方に任せ、
音声の再生は ONS に投げる事にしました。
折角の独自形式なんだからと同じフレームを動画に含めず、
再生時にそこに来た時は待機する様にと考えました。
単純に画像数が減るので容量も小さくなりますし、
再生時もそこの時は待機するので負荷が減ります。
そして ffmpeg でデコード＆エンコードされた JPEG よりも、
直接動画から引き抜いた画像からの方が一致し易いと考え、
DirectShow を使って画像と音声を抽出し画像は内部でエンコード。
音声はリサンプリングの問題で取り合えずは別ツールで。
そんな感じで SMJPEG に代わる 独自MJPEG を作ってみました。
音質も問題なく 100MHz でも余裕で 30fps 出るので、
動画に関してはもうこれでいいんじゃないかなーと。
変換のツールとやり方はファイルの中に入れてありますので、
是非試してみて下さい。
onscripter-20090331vX_psp.zip
PSP の API の方でエラー出した時は LIBJPEG でデコードする様にしました。
これで対応してない形式だったりサイズだったりしても、
PSP の API を使った程ではありませんが通常よりは速いです。
続いて今回の目玉。
どんな機種でもムービーが再生可能な連番ムービーですが問題もあります。
動画のフレームを１つ１つを画像ファイルにするので、
アーカイブ化しないとコピーやらディスク上のサイズやら問題が出ます。
アーカイブ化したらしたで、ONS 側のファイルインデックスを大量に消費するので、
インデックスの為のメモリが増え、他のファイルの検索性を損ないます。
そこでファイル単一でムービー再生が可能な SMJPEG ですが、
こちらは音声が ADPCM なので音質が悪くサイズも大きいです。
先日出したテスト版の方では改善されてますが、
デコード速度の問題で音飛びやノイズなどが入ったりもしました。
そこで考えたのは MJPEG + OGG や MP3 でした。
SMJPEG の形式に習うのは面倒だったので独自形式に。
JPEG のデコードと描画は PSP の API の方に任せ、
音声の再生は ONS に投げる事にしました。
折角の独自形式なんだからと同じフレームを動画に含めず、
再生時にそこに来た時は待機する様にと考えました。
単純に画像数が減るので容量も小さくなりますし、
再生時もそこの時は待機するので負荷が減ります。
そして ffmpeg でデコード＆エンコードされた JPEG よりも、
直接動画から引き抜いた画像からの方が一致し易いと考え、
DirectShow を使って画像と音声を抽出し画像は内部でエンコード。
音声はリサンプリングの問題で取り合えずは別ツールで。
そんな感じで SMJPEG に代わる 独自MJPEG を作ってみました。
音質も問題なく 100MHz でも余裕で 30fps 出るので、
動画に関してはもうこれでいいんじゃないかなーと。
変換のツールとやり方はファイルの中に入れてありますので、
是非試してみて下さい。
onscripter-20090331vX_psp.zip
2009年11月16日
ONS for PSP でムービー再生２
過去の記事 はこちらから。
大分前に提示した連番画像でのムービー再生方式。
今にして思えば色々となんだかなーなやり方を使ってた部分が多々あり。
折角改良版を公開していた、ひとつもりさんのサイトも閉鎖されてしまったので、
ここいらでまとめ的なスクリプトを公開しておこうかと思います。
まずは二分検索をやっていた、ひとつもりさんの追加部分の簡略化・最適化。
3156枚を 18回検索していたのが 12回へと 2/3 まで減らす事が出来ました。
NS 形式のスクリプトとしては、綺麗にまとまったんじゃないかと思います。
続いて無限ループ部分の for next 命令を goto へ変更。
for に 9 を沢山入れる方法は私がやり出した奴なのですが、
ONS では for よりも goto 使った方が速いですし、
NS 仕様の for は色々と危ういので避けられるなら避けるべきです。
for next を排除した事で jump 系命令も必要なくなります。
最後に同じ画像の表示をしない為の処理を追加。
まぁ物によっては無駄な処理になる可能性もなくはないですが。
如何でしょう？ 以前に比べて大分すっきりしたのではないかと。続きを読む
大分前に提示した連番画像でのムービー再生方式。
今にして思えば色々となんだかなーなやり方を使ってた部分が多々あり。
折角改良版を公開していた、ひとつもりさんのサイトも閉鎖されてしまったので、
ここいらでまとめ的なスクリプトを公開しておこうかと思います。
まずは二分検索をやっていた、ひとつもりさんの追加部分の簡略化・最適化。
3156枚を 18回検索していたのが 12回へと 2/3 まで減らす事が出来ました。
NS 形式のスクリプトとしては、綺麗にまとまったんじゃないかと思います。
続いて無限ループ部分の for next 命令を goto へ変更。
for に 9 を沢山入れる方法は私がやり出した奴なのですが、
ONS では for よりも goto 使った方が速いですし、
NS 仕様の for は色々と危ういので避けられるなら避けるべきです。
for next を排除した事で jump 系命令も必要なくなります。
最後に同じ画像の表示をしない為の処理を追加。
まぁ物によっては無駄な処理になる可能性もなくはないですが。
如何でしょう？ 以前に比べて大分すっきりしたのではないかと。続きを読む
2009年11月14日
ONScripter for PSP テスト版
久々にテスト版をリリース。
画像の読み込み部分を最適化して高速化を目指そうというモノです。
PSP-1000 CFW5.00M33-6 SanDisk ultraII 4.0GB CPU333MHz
PNG32=(97.092KB) JPEG24+MASK=(38.907KB)
JPEG24(28.617KB)+PNG8(7.681KB)=(36.298KB)
JPEG24(28.617KB)+JPEG8(10.204KB)=(38.821KB)
従来は SDL_image の 16bpp で PNG32 や JPEG24+MASK を使用していました。
散々言われていた事ですが、24bit のマスク付きJPEG よりも、
32bit のαチャンネルを持つ PNG の方が断然早いです。
これは JPEG がマスクのせいで横幅が倍になっている為です。
これでは幾らサイズが小さくてデコード速度が早くても追いつけない訳ですね。
とは言え JPEG24+PNG8 だと大分切迫しますね、全然使われてませんが。
まずは SDL_image を使わずライブラリ単体でデコードしてみます。
PNG は僅かなものですが、JPEGはそこそこ早くなってますね。
結論はやっぱり SDL_image はダメダメという事で。
LIB 系って環境依存しにくいのに内部で何やってんだろ…。
でもまだ PNG よりは遅いです。
なので次は PSP の API を使ってみると、すこぶる早くなりました。
元々は MJPEG 用の物なので多分色々犠牲にしたりしているのでしょうが、
この速さは特筆すべきものがありますね、素晴らし過ぎる。
でも良い事ばかりではありません、512x512 のサイズ制限があるっぽいです。
これは PSP の解像度が 480x272 で MJPEG ムービー用だからでしょう。
もうお気づきかと思いますが、16bpp より 32bpp の方が速度出るんですよね。
ここの bpp は最終描画部分だけなので、最後の変換で差が出てるのでしょう。
そんな感じで 220.8ms を 75.3ms にする事が可能となった訳です。
どこぞの赤い奴みたく３倍近い速度が出ています。
更にこれで動画系も試してみます。
JPEG ベースライン標準 画質90 3156枚
当初の BLT を使った連番動画は 10fps も出てなかったという…。
LIBJPEG 単体だと２倍、PSP API だと更に２倍近い速度が出ます。
PSP API はバッファリングしたら、もっと速度出るんでしょうけど。
SMJPEG は元からそこそこ速度が出ていた様ですね。
PSP API を組み込んでみると 222MHz でも余裕で 30fps 出ました。
長くなりましたが、今回は PSP の API で JPEG をデコードしいます。
その関係上 512x512 以上のサイズやプログレッシブ形式に対応出来ません。
なのでツールによっては使えない画像が出てくるでしょう。
その場合は一つ前の記事にある imageUtility でも使ってみて下さい。
BLT2 というのは今回追加した PSP 専用の BLT 命令です。
BTNDEF と BLT を足した感じの命令で、この様な感じで使えます。
”BLT2 ファイル名, dx, dy, dw, dh, sx, sy, sw, sh”
そんな感じで制限が微妙ですが、実際の使用感などを
コメント頂けるば幸いです。
onscripter-20090331vX_psp.zip
画像の読み込み部分を最適化して高速化を目指そうというモノです。
PSP-1000 CFW5.00M33-6 SanDisk ultraII 4.0GB CPU333MHz
PNG32=(97.092KB) JPEG24+MASK=(38.907KB)
JPEG24(28.617KB)+PNG8(7.681KB)=(36.298KB)
JPEG24(28.617KB)+JPEG8(10.204KB)=(38.821KB)
| Library | Image | 16bpp | 32bpp |
|---|---|---|---|
| SDL_image | PNG32 | 170.6ms | 164.4ms |
| SDL_image | JPEG24+MASK | 220.8ms | 215.4ms |
| SDL_image | JPEG24+PNG8 | 181.3ms | 167.5ms |
| SDL_image | JPEG24+JPEG8 | 221.6ms | 195.6ms |
従来は SDL_image の 16bpp で PNG32 や JPEG24+MASK を使用していました。
散々言われていた事ですが、24bit のマスク付きJPEG よりも、
32bit のαチャンネルを持つ PNG の方が断然早いです。
これは JPEG がマスクのせいで横幅が倍になっている為です。
これでは幾らサイズが小さくてデコード速度が早くても追いつけない訳ですね。
とは言え JPEG24+PNG8 だと大分切迫しますね、全然使われてませんが。
| Library | Image | 16bpp | 32bpp |
|---|---|---|---|
| Liblary Only | PNG32 | 147.8ms | 134.7ms |
| Liblary Only | JPEG24+MASK | 163.8ms | 152.0ms |
| Liblary Only | JPEG24+PNG8 | 161.0ms | 148.9ms |
| Liblary Only | JPEG24+JPEG8 | 154.1ms | 142.5ms |
まずは SDL_image を使わずライブラリ単体でデコードしてみます。
PNG は僅かなものですが、JPEGはそこそこ早くなってますね。
結論はやっぱり SDL_image はダメダメという事で。
LIB 系って環境依存しにくいのに内部で何やってんだろ…。
でもまだ PNG よりは遅いです。
| Library | Image | 16bpp | 32bpp |
|---|---|---|---|
| PSP API | JPEG24+MASK | 87.6ms | 75.3ms |
| PSP API | JPEG24+PNG8 | 118.1ms | 109.8ms |
| PSP API | JPEG24+JPEG8 | 112.6ms | 99.3ms |
なので次は PSP の API を使ってみると、すこぶる早くなりました。
元々は MJPEG 用の物なので多分色々犠牲にしたりしているのでしょうが、
この速さは特筆すべきものがありますね、素晴らし過ぎる。
でも良い事ばかりではありません、512x512 のサイズ制限があるっぽいです。
これは PSP の解像度が 480x272 で MJPEG ムービー用だからでしょう。
もうお気づきかと思いますが、16bpp より 32bpp の方が速度出るんですよね。
ここの bpp は最終描画部分だけなので、最後の変換で差が出てるのでしょう。
そんな感じで 220.8ms を 75.3ms にする事が可能となった訳です。
どこぞの赤い奴みたく３倍近い速度が出ています。
更にこれで動画系も試してみます。
JPEG ベースライン標準 画質90 3156枚
| Library | Method | 16bpp | 32bpp |
|---|---|---|---|
| SDL_image | BTNDEF+BLT | 763(7.25fps) | 852(8.09fps) |
| LIBJPEG | BTNDEF+BLT | 1530(14.5fps) | 1927(18.3fps) |
| PSP API | BLT2 | 3063(29.1fps) | 3048(28.9fps) |
| LIBJPEG | SMJPEG | 2628(24.9fps) | |
| PSP API | SMJPEG | 3156(30.0fps) | 3156(30.0fps) |
当初の BLT を使った連番動画は 10fps も出てなかったという…。
LIBJPEG 単体だと２倍、PSP API だと更に２倍近い速度が出ます。
PSP API はバッファリングしたら、もっと速度出るんでしょうけど。
SMJPEG は元からそこそこ速度が出ていた様ですね。
PSP API を組み込んでみると 222MHz でも余裕で 30fps 出ました。
長くなりましたが、今回は PSP の API で JPEG をデコードしいます。
その関係上 512x512 以上のサイズやプログレッシブ形式に対応出来ません。
なのでツールによっては使えない画像が出てくるでしょう。
その場合は一つ前の記事にある imageUtility でも使ってみて下さい。
BLT2 というのは今回追加した PSP 専用の BLT 命令です。
BTNDEF と BLT を足した感じの命令で、この様な感じで使えます。
”BLT2 ファイル名, dx, dy, dw, dh, sx, sy, sw, sh”
そんな感じで制限が微妙ですが、実際の使用感などを
コメント頂けるば幸いです。
2009年11月13日
imageUtility v0.12
取り合えずこっちから。
JPEG にベースラインとプログレッシブの形式選択オプションを追加しました。
PNG にインタレース形式を選択オプションを追加しました。
プログレッシブとインタレースは読み込みが遅くなるので、
低スペックな機器での使用目的なら基本的に使わない方がいいです。
JPEG のベースラインの最適化は僅かながらに容量を抑えられるのでオススメです。
αチャンネルを持つ画像を読み込んだ場合の最適化オプションを追加しました。
画像にもよりますが、PhotoShop で作られた PNG なんかには効果があります。
αブレンドの32bit同士の演算の一部が抜けていたミスを修正しました。
あーいやまぁαブレンドは色々とぐだぐだになってしまいましたな。
あと、前回の PNG の測定時間が間違ってたので修正してあります。
imageUtility012.zip
JPEG にベースラインとプログレッシブの形式選択オプションを追加しました。
PNG にインタレース形式を選択オプションを追加しました。
プログレッシブとインタレースは読み込みが遅くなるので、
低スペックな機器での使用目的なら基本的に使わない方がいいです。
JPEG のベースラインの最適化は僅かながらに容量を抑えられるのでオススメです。
αチャンネルを持つ画像を読み込んだ場合の最適化オプションを追加しました。
画像にもよりますが、PhotoShop で作られた PNG なんかには効果があります。
αブレンドの32bit同士の演算の一部が抜けていたミスを修正しました。
あーいやまぁαブレンドは色々とぐだぐだになってしまいましたな。
あと、前回の PNG の測定時間が間違ってたので修正してあります。
imageUtility012.zip
2009年11月10日
ONS の画像読み込み
ONScripter for PSP の画像の読み込みで、
JPEG で 512x512 ピクセル以下であれば、
現状の２倍以上の速度で読み込めそうなんですが、
512x512 よりも大きいとダメなんですよね。
そういうサイズで使ってる人っているのでしょうか？
JPEG で 512x512 ピクセル以下であれば、
現状の２倍以上の速度で読み込めそうなんですが、
512x512 よりも大きいとダメなんですよね。
そういうサイズで使ってる人っているのでしょうか？
