Ch's barn

avs2pipemod その14

2012-02-18T02:34:00.000+09:00

更新しました。

avs2pipemod-0.3.0.7z
https://github.com/chikuzen/avs2pipemod

*新機能 "dumpyuv" を追加

これを読んでたら自分も欲しくなったので、機能を追加しました。
RGBデータを扱いたい場合は

ColorBars()
Y=ShowGreen("Y8").ConvertToYV24()
U=ShowBlue("Y8")
V=ShowRed("Y8")
YToUV(U, V, Y)

とでもして下さい。

avs2pipemod その13

2012-02-16T21:50:00.000+09:00

更新しました。

avs2pipemod-0.2.2.7z
https://github.com/chikuzen/avs2pipemod

*x264raw/x264bdの出力内容に"--frames"を追加

rawvideo出力等で"-trim=*,*"を使っている場合は、こちらも同様にtrimを追加して下さい。
両方で同じ指定をしないと、フレーム数の整合がとれなくなります。

Pythonで関数の引数の順序を入れ替える

2012-02-05T20:27:00.001+09:00

メモ替わり

L-SMASHのコードで使われている関数のいくつかについて、引数の順序を入れ替える必要が発生した。

こういった作業はIDEを使っていれば簡単にできるのかも知れないが、何かしら書くときはいつもテキストエディタを使い、コンパイルはCLI操作で済ませているので、使い方がいまだにさっぱり分からない。
かといっていちいち関数名で検索しては手作業で修正するのも面倒なので、久々にPythonを書いた。

制限事項：
一つの関数の記述が複数行にまたがる場合

int var = ItIsNoNeedToCareAboutTheLengthOfFunctionNamesBecauseEverybodyUsesIDE(foo,
                                                                               bar,
                                                                               fizz,
                                                                               buzz,
                                                                               bleh,
                                                                               fuck);

は処理できないので、warningを頼りに手動で修正すること。

avs2pipemod その12

2012-01-30T08:42:00.001+09:00

更新しました。

avs2pipemod-0.2.1.7z
https://github.com/chikuzen/avs2pipemod

*新機能'x264raw','x264rawtc'を追加

最近はdither hackやらx264がRGB圧縮に対応したりやらのおかげで、y4m出力の代りにrawvideo出力を使う頻度が結構高くなりました。
YUV4MPEG2は仕様で「使えるフォーマットは8bitのplanarYUVのみ」と決められているので、これらのためには使えないのです。
で、仕方がないので

$ avs2pipemod -rawvideo=vflip input.avs | x264_x64 - --demuxer raw --input-csp bgr --input-res 1280x720 --output-csp rgb --fps ...

とかやるわけですが、長いコマンドがいい加減めんどうなので省力化することにしました。

使い方

$ avs2pipemod -x264raw 1280x720_30fps_rgb24.avs

てな感じのコマンドを実行すると

- --demuxer raw --input-csp bgr --input-depth 8 --input-res 1280x720 --fps 30/1 --output-csp rgb

と標準出力に出力されます。

dither packageやflash3kyuu_debandのinterleaved出力を使う場合は、引数でinput-depthを指定するとwidthを1/2にしたコマンドラインが出力されます。

$ avs2pipemod -x264raw=16 2560x719_ntsc-film_16bit_yv24.avs
- --demuxer raw --input-csp i444 --input-depth 16 --input-res 1280x719 --fps 24000/1001 --output-csp i444

'x264rawtc'は、--tcfile-inを使う場合のためのもので、"--fps fpsnum/fpsden"は出力されません。

$ avs2pipemod -x264rawtc 640x480_yv411.avs
- --demuxer lavf --input-fmt rawvideo --input-csp yuv411p --input-depth 8 --input-res 640x480 --output-csp i422

筆者のようにCLIにCygwinやMSYSのBash/shell scriptを使っている人なら

$ avs2pipemod -rawvideo input.avs | x264 $(avs2pipemod -x264raw=16 input.avs) --crf 22 --preset slower ...

てな感じで、コマンド置換を利用すれば結構ラクになると思います。

cmd.exeな人の場合は…あいにく筆者はdosコマンドやbatは数年前に憶えることを放棄したので、さっぱりわかりません。
まあ、某ペンギン様も「batを憶えるくらいならPerlをインストールしろ」とか言ってますし、それでいいかと思っています。

avs2pipemod その11

2012-01-28T23:03:00.000+09:00

更新しました。
avs2pipemod-0.1.2.7z
https://github.com/chikuzen/avs2pipemod

エラーの出るavsを使用した際にクラッシュしていたのを修正。

生まれて初めてバグレポート頂きました。
これまでずっとレポートする側だったので、なんか新鮮な気分です。

ConvertToRGB

2012-01-07T02:21:00.000+09:00

avcodecに10bit-AVCデコーダがcommitされて随分経つのにいまだによく解らない人のための乱暴な解説。

まずはこちらの方の解説を読みましょう。
自分が知るかぎりでは、もっともシンプルでわかりやすい説明をされています。
ＤＴＶかくし味 - ＹＵＶとＲＧＢの比較

特にこの図、

いかに暗部の色数が少ないか、なぜ暗部にシルバーグレインを撒く(=Yの値だけまばら且つ適当に上げる)とマシに見えるようになるかが一発で理解できます。

さて、「YUVはRGBで表現できる範囲をすべてカバーしています。（が、細かい諧調はRGBに分があります。）」とまとめられていますが、これをちょっと具体的に計算してみましょうか。

/* yuv2rgb.c */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define SATURATE(X) X = (X < 0) ? 0 : (X > 255) ? 255 : X

int intcmp(const void* a, const void* b)
{
    return (*(int*)a - *(int*)b);
}

int main(void)
{
    const struct {
        char *name;
        int coef[6];
    } matrix[] = {
        {"rec601", {76309, 104597, 25675, 53279, 76308, 132201}},
        {"pc601",  {65536,  91881, 22553, 46801, 65536, 116129}},
        {"rec709", {76309, 117504, 13954, 34903, 76308, 138453}},
        {"pc709",  {65536, 103219, 12257, 30659, 65536, 121621}},
        {NULL}
    };

    int *rgb = (int*)malloc(256 * 256 * 256 * sizeof(int));
    if (!rgb) {
        fprintf(stderr, "malloc failed\n");
        return -1;
    }
    for (int m = 0; matrix[m].name; m++) {
        int count = 0;
        int x = !strncmp(matrix[m].name, "rec", 3) ? 16 : 0;
        for (int y = 0; y < 256; y++)
            for (int u = 0; u < 256; u++)
                for (int v = 0; v < 256; v++) {
                    /* 下記計算式は茂木和博氏のm2v.vfpのreadmeより引用しました */
                    int r = (matrix[m].coef[0] * (y - x) + matrix[m].coef[1] * (v - 128)) >> 16;
                    int g = (matrix[m].coef[0] * (y - x) - matrix[m].coef[2] * (u - 128)
                                                         - matrix[m].coef[3] * (v - 128)) >> 16;
                    int b = (matrix[m].coef[4] * (y - x) + matrix[m].coef[5] * (u - 128)) >> 16;
                    SATURATE(r);
                    SATURATE(g);
                    SATURATE(b);
                    rgb[count++] = ((r << 16) | (g << 8) | b);
                }
        qsort(rgb, count, sizeof(int), intcmp);
        int num = 1;
        for (int i = 1; i < count; i++)
            if (rgb[i] != rgb[i - 1])
                num++;
        printf("%s: %d\n", matrix[m].name, num);
    }
    free(rgb);
    return 0;
}

このコードでBT.601とBT.709で8bitYUV->8bitRGBに変換した際、RGBで使われる色数がわかります。で、結果は

BT.601 TVレンジ(伸張)      2,956,082色
BT.601 PCレンジ(ストレート) 4,261,687色
BT.709 TVレンジ(伸張)      3,048,157色
BT.709 PCレンジ(ストレート) 4,400,772色

となります。
いやぁ、ほんと色数少ないですね。TrueColorRGBの16,777,216色のうち、最大でも4分の1程度しか使われていません。
バンディングが発生するのも当たり前です。
これが10bitYUV->8bitRGBだとどの程度になるのかは、適当な計算式がとりあえず見当たらなかったのでやってませんが、8bit->10bitでY,U,Vの精度がそれぞれ4倍になることを考えれば、色数もかなり良い感じに増えそうです。

てなわけで、10bitエンコードの力を確認するためにバカ高い業務用モニタ等は別に必要ありません。
民生品でもそこそこの品質があれば違いは確実にわかります(もちろん、良いものであればもっとよく分かるでしょうが)。

つーか、AviUtlのプレビューがやたら綺麗に見える理由って、まさにこれだよね。

avs2pipemod その10

2012-01-05T21:54:00.000+09:00

更新しました。

avs2pipemod-0.1.1.7z
https://github.com/chikuzen/avs2pipemod

コードの大部分を書き直しました。

* avisynth.libが要らなくなった。
これまではビルドするためにavisynth.libを使う必要がありましたが、これをやめてLoadLibrary()を使うようにしました。
これにより64bit用もビルド出来るようになりました。

* avisynth.dllのバージョンを検出し、挙動を切り替えるようにした。
てなわけでavs2pipe26modはなくなりました。

* おまけ
SetMTModeに応じてDistributor()を自動追加する機能もコードには存在します。
もし、この機能が欲しい人は、make時に'XCFLAGS=-DBLAME_THE_FLUFF'を追加して自ビルドして下さい。

avs2pipemod その9

2011-12-31T05:19:00.003+09:00

更新しました。

avs2pipemod-20111230.zip
https://github.com/chikuzen/avs2pipemod

*ビデオ出力処理をavs2pipeの最新のものから移植。

久しぶりにdoobry氏がDoom9に現れgithubのレポを公開しました。
さっそく最新のコードを見てみると…うーむ、こんな手があったのか。
手元のベンチマーク結果をみてもこれのほうが速かったので、早速パクりました。
つくづく彼のコードは自分にとって素晴らしい教材です。

追記
たくあん氏から、以前のバージョンより遅くなっているとの報告を受けたので、検証して見ました。

#sample.avs
LoadPlugin("DGDecode.dll")
MPEG2Source("1400x1080x2990frames.d2v", idct=3)

これを前回(20110911)と今回(20111230)で比較
pattern1:
 $ time avs2pipemod -y4mp sample.avs > sample.y4m
pattern2:
 $ time avs2pipemod -y4mp sample.avs | x264 - --demuxer y4m --preset ultrafast -o sample.264
pattern3:
 $ time avs2pipemod -y4mp sample.avs | x264 - --demuxer y4m --preset medium -o sample.264

それぞれを3回ずつ回すと(数値はエンコード終了までの時間)
              pattern 1      |      pattern2      |      pattern3
          20110911  20111230 | 20110911  20111230 | 20110911  20111230
1st(sec)   122.094   112.451 |   39.919    42.416 |  181.153   183.238
2nd(sec)   122.200   113.405 |   40.099    42.426 |  183.994   182.490
3rd(sec)   118.490   114.094 |   39.976    42.716 |  184.112   182.664
avg(sec)   120.928   113.317 |   39.998    42.519 |  183.086   182.797

他のエンコーダにpipeせず、直接y4mやrawで保存する場合は20111230のほうが速いです。
そして、他のエンコーダにpipeした場合は、以前の方が速くなります。
エンコーダ側の設定がある程度重くなると律速する…どうしようかなぁ…。

現実的な使用例を考えるとpattern2よりも1か3の使い方のほうが多いと思いますので、このまま行くことにします。

AviSynth Script Reader for AviUtl

2011-12-09T21:00:00.001+09:00

VFR_maniac改めMP4_maniac氏がlsmashinput.aui(L-SMASHとLibavを利用したAviUtl用入力プラグイン)を発作的に書き始めてしまったのに付き合っていた流れで、AviUtlの入力プラグインの書き方が少しだけ理解できるようになった。

AviUtlといえば前から不思議に思っていたのが「なぜavsを読むのにわざわざ別に入力プラグインが必要なのか」である。
そもそもAviSynthはスクリプトをAVIに偽装するソフトウェアである。
もし任意のソフトウェアがVFWのAVIFileOpen関数を使って拡張子がavsのファイルを開こうとすれば、レジストリ登録情報によりavisynth.dllが動いて、ただのテキストはAVIとして扱われるような仕組みになっている。
AviUtlにはVFWを使用する入力プラグイン(AVI File Reader)が内蔵されているのだから、本来外部プラグイン(avsinp.aui)は必要ないはずなのだ。

で、このたびPluginSDKのサンプルコード(avi_input.cpp)を読んでみたら、疑問はすぐに解決した。
AviUtlは、まずファイルの拡張子を見てプラグインが対応しているかどうかを判別するため、*.avsというファイルはAVI File Readerには渡されないというだけのことだった。

てなわけで、ちょっと実験。
まず、avi_input.cppのINPUT_PLUGIN_TABLE構造体のfilefilter変数の中身を*.aviから*.avsに変更。
入力プラグイン名をAviSynth Script Reader (VFW)にして、コメント以外の日本語文字を除去(CP932は色々面倒)、ついでにファイル名を.cppから.cにして(avi_input.cppはC++ではなくCで書かれている)、あとはGCCでコンパイルしてやれば…

gcc -c avi_input.c -o avsread.o
gcc -o avsread.aui -shared -Wl,--dll,--add-stdcall-alias avsread.o -lavifil32

ああ、読めた。

つまり、KENくん氏が内蔵のAVI File Readerに拡張子*.avsを追加してくれれば、avsinp.auiは要らなくなるんだよなぁ…。

Oneiric入れてみた

2011-10-15T02:46:00.000+09:00

Ubuntu11.10(OneiricOcerot)が出たのでWindows7上のVMWarePlayer3.1.4(4.0は様子見中)に入れてみました。

インターフェース

とうとうVMWarePlayerでもUnityになってしまいました。
まあ、UbuntuのUIは最初に9.10を入れたときの感想が「なんか林檎臭くてやな感じ」で特に気に入っていたわけでもありませんし、別にどうということもありません。
メインで使ってるわけでもないし、多分一ヶ月もすれば慣れてるんじゃないかと思います。
それに当たり前のことではありますが、Terminalの使い勝手はMSYSやCygwinよりも遥かにいいわけですしね。
(でも、画面左のランチャーは、Windows7のタスクバーに比べて遥かに糞だと思います)

さて、自分にとってとりあえず重要なのはwine(というか、avisynthが動くこと)とmingwですので、早速試してみることにしましょう。

wineとavisynth

wineは使い始めた当初よりLatest official releaseのPPAを利用しています。
launchpadに行ってみたら、Oneiric用のパッケージも既に配布されていました。
今後は1.3だけの配布になるのかな？

$ sudo add-apt-repository ppa:ubuntu-wine/ppa
$ sudo apt-get update
$ sudo apt-get install wine1.3

あとはsourceforgeからavisynth2.6.0α3とVirtualDubをDLして、avisynthはwine経由でインストール、VirtualDubは~/.wine/drive_c/Program Files以下に展開。

さて、ここで注意したいのは、最近のwine1.3ではそのままではavisynthが動かないこと。
どうやらmsvcrt関連に1.3.1xのあたりで大きな変更があったらしく、runtimeの追加が必要になっています。
と言ってもやることは簡単で、Winetricks->Select the default wineprefix->Install a Windows DLL or componentでvcrun6をインストールするだけです。
Windows実機でMicrosoftからVC++XX再頒布可能パッケージとかをDLしてインストールするよりも遥かに速くて楽ですし、どのWindowsアプリケーションでどのruntimeが要求されるかもわかりませんので、vcrun*は全て入れてしまってもいいかも知れません。

これでavisynthは動きます。

mingw

GCCを使ったWindows用アプリケーションのビルドは、MSYSやCygwinよりもLinux上でクロスコンパイルしたほうが速いです。
特にconfigureのスピードは桁違いで、MSYS環境だと3分はかかるffmpegのconfigureが、LinuxだとVM上でも15秒で終わります。
ただ11.04までのUbuntuのmingw関連は、mingw32はGCC4.2.1のまま放置、mingw-w64はGCCこそ4.4.3と少しはマシのようだけどいろいろぶっ壊れていたりして、使いものになりませんでした(getopt.hとかが無いってどーいうことよ？)

さて、今回のパッケージはどうでしょうか？
とりあえずmingw32のほうは相変わらず放置のままのようですが、mingw-w64はGCC4.6.1に更新されていて抜けていたヘッダーもちゃんとあります。
triplexもi586-mingw32msvc/amd64-mingw32msvcという「お前はGCCなのかMSVCなのかはっきりしろ」と言いたくなるようなDebian流のものから、i686-w64-mingw32/x86_64-w64-mingw32というmingw-w64の標準的なものに変更されてていい感じです。

しかし、ここで一つ問題に気づきました。
このパッケージにはlibvfw32.aが入っていません。
mingw-w64はmingw32よりも開発が活発でどんどん良くなっていってはいるのですが、まだまだいくつかライブラリに抜けがあったりして、ときどきハマることがあります。
libvfw32.aが追加されたのはたしか7月の終わりあたり…そしてこのパッケージはバージョンを見ると5月終わり頃のもののよう。
折りしもmingw-w64は数日前にv2.0をリリースしたばかりだし、GCCも4.6.2がすぐに出ます(っていうか、たしか今月頭に出るはずだったんだが)…結局今回も11.04同様、自ビルドすることになりそうですorz

GPL violation?

2011-10-11T03:26:00.000+09:00

「x264LLCと契約した某社が、libx264を使うBD用エンコードソフトのベータ版を出した」とkierank氏に聞いたので、ダウンロードしてみることにした。
まずは配布ページに行ってユーザー登録。次にインストーラをDL。
商用ソフトのベータ版というだけあってインストーラはinnoやmsiではなく最新のInstall Shieldだった。うーむ、これでは7zipでは解凍できないね。
仕方ないのでインストーラをダブルクリックしてみると、EULAの次に表示されたのがこれ。

えー、なんでー？　これって商用なんでしょ？
正式リリース後はお金払わなきゃ使えなくなるんでしょ？
開いたままふさがらない口を閉めつつ、早速カスタマーサポートに次のようなメールを送ってみることにした。

この度御社のhogehogeベータ版をインストールしたところ、fugafuga.dllのライセンスに関して、
GNU General Public License Version3であるとの提示がありました。
GPLなプログラムを配布する場合は、そのプログラム自体のソースコードはもとより、プログラムをプラグインとして
使用するアプリケーション本体等に関しても、OSやコンパイラが提供する「システムライブラリ」以外は全て
ソースコードの開示義務が発生することはご存知であると思います。
つきましては、GPLで保護された配布物の受領者として、全ソースコードの開示請求の権利を行使いたしたく思います
ので、よろしくお取り計らいいただけますようお願いいたします。

でもって数日後に返ってきたお返事はこんな感じ

お問い合わせの件ですが、まず、fugafuga.dllについては、GPLライセンス下のプログラムとなりますので、
ご要望とあれば、ソースコードを郵送でお送りさせていただきます。お届け先のお名前、ご住所、お電話番号を
お知らせください。
また、「（GPL）プログラムをプラグインとして使用するアプリケーション本体等に関しても、OSやコンパイラが
提供する「システムライブラリ」以外は全てソースコードの開示義務が発生すること」については、過去の例を含めて
再度確認いたしましたが、開示義務があると断定することはできません。
ただ、今後もこのようなご意見を頂戴することも考えられますので、本日よりfugafuga.dllの提供を停止させて
いただきました。
今後とも、hogehogeをよろしくお願いいたします。

そりゃあ、義務があると断定するためには裁判所の判決が必要になるでしょうが、少なくともGPLの条文には義務が生じると書かれています。
foobar2000とSecretRabitCodeの一件*とか、裁判まではいかなくても揉めた事例はいくつもあるわけで。
もし誰かがFSFに垂れ込んだら、ひょっとすると本気で食いついてくるかも知れないよ？
動画編集用Free-softwareの開発は、GNUのHigh Priority Free Software Projectsの一つとしてここ数年間、ずっと掲げられているのを知ってる？
そもそもGPLなライブラリを簡単に使えるんだったら、なんであんたらx264LLCと契約したの？
LGPLと勘違いしてないか？
まあ、自分は当初の目的(この会社をからかって遊ぶこと、及びこのライブラリの使用を即刻やめさせること)は果たしたので、これ以上何かするつもりはないんですけどね。

なんで使用をやめさせたかったかといえば、このソフトが商売としてちゃんと成功して欲しいと思っているから(自分が買う予定はまったくないけど)。
x264LLCに入った利益はlibx264の開発に貢献した度合いに応じて各開発者に分配されることになっており、現にPegasysのTMVW5やSplitMediaLabsのXSplitといった商用ソフトのライセンス料の分配は始まっている。
日本人の自分から見ればそれほどたいした金額ではないみたいなんだけど、例えばロシア人の某氏が受け取ったお金は、彼の本職のサラリー数カ月分に相当するそうである(JEEB氏によれば、彼の給料はロシアでは結構もらってるほうらしい)。
ソフトウェアの共同開発を楽しみながらそこそこの小遣い稼ぎも出来るのであれば、特に物価の安いロシア/東欧/南米といった地域から生きの良い開発者が新たに出現する可能性は高くなるだろう。
そして、そういう仕組みが出来上がったところでH.265が正式に勧告され、x264がx265になったら(もちろん彼らはそれくらいのことは既に考え始めている)、かなり面白いことになるんじゃないかな？
そういう夢をみるためには、一つでも多くの成功事例が必要なのです。

で、それはそれとして一人でニヤニヤしてればいいのに、なんでわざわざこんなのを書いているかといえば、似たようなライセンス爆弾を抱えているツールだのプラグインだのを結構見かけたりするから。
すでにそのようなバイナリを配布しているあなたや、これから配布しようと思っているあなた、ホントにそれで大丈夫ですか？
不注意から起こったトラブルでストレス貯めこんでハゲても知りませんよ？
まあ、うっかりなんてことはそれこそ誰でもやっちゃうものですから、直せるなら早めに直したほうがいいでしょう。

*foobar2000は無料で配布されているWindows用オーディオプレーヤー(プラグインSDK以外のコードは非公開)。

SecretRabitCode(別名libsamplerate)は現在最も高品質と言われているオーディオリサンプル用ライブラリ(x264と同様のGPLv2又は商用の二重ライセンス)。

かつてSRCを使用したfoobar2000用リサンプラープラグインが書かれたことがあるが、これを見つけたSRCの作者Erik氏はプラグイン作者にfoobar2000の全コード、もしくはSRCの商用ライセンス料の支払いを要求し、件のプラグインは開発/配布の永久停止となった(まあ、探せばどこかで拾えるでしょうが)。

RawSource.dll その6

2011-09-26T09:41:00.000+09:00

RawSource26(avisynth2.6.0以降専用)を更新しました。

rawsource_26_dll_20110925.zip
https://github.com/chikuzen/RawSource_2.6x

*widthの最大値を65536に変更。
*あらたに最大解像度を設定(width x height <= 134217728)。
*その他少々の手直し(出力には影響なし)

必要なもの
avisynth2.6.0α2以降
sseが使えるマシン
msvcr100.dll (Microsoft Visual C++ 2010 再頒布可能パッケージのことです)

以前、読み込み用のバッファの確保をオリジナルのMAX_WIDTH x 4から動的確保に変更したので、現在のコードベースにおけるwidth及び解像度の上限は、単に非常識に大きな数値を入力された場合のout of memory回避のために設けてあります。
とりあえず最大width4096で十分だろうと思っていたのですが、一部の変な人達にはそれでは足りないらしいので増やしました。
まあ、たとえwidth=65536, height=2048の場合でも、
読み込み用バッファのサイズは65536*4=256KiB (RGB32の場合)
avisynthが用意する1フレーム分のメモリは134217728x4=512MB(RGB32の場合)
なので、とりあえずこれだけでクラッシュすることは無い(はず)です......大丈夫だといいなぁ

それにしても最近のDoom9はMTとhigh-bit-colorと64bitでグチャグチャになっておりますな。
自分はそういうハックに夢中になる暇があるなら、とりあえずさっさと2.6.0の正式リリースに漕ぎ着けられるよう、協力体制を取って欲しいものですが。
2.6.0が正式リリースになれば2.5.8なんて誰も使わないのは目に見えてるんですから、もはや2.5.8でも使えるような配慮は単なる時間の無駄だと思っています。

xvidcore-1.4.0

2011-09-20T08:51:00.002+09:00

今月に入ってxvidのMLに幾つかビルド関連のパッチを投げたりしてみた。
http://list.xvid.org/pipermail/xvid-devel/2011-September/thread.html

もともと自分はただビルドするだけなのにパッチを当てたりするのは嫌いである。
第一に、パッチの存在を知らない人間にはパッチは役に立たない。
第二に、パッチを管理するのはめんどくさい。
第三に、殆どの場合ビルドエラーの原因はあほらしい理由によるものなので、原因が分かったときに激しい虚しさに襲われることになる。

たしかに開発本家にパッチ投げるのってパッチ書く以上にめんどいけど、やらないといつまでもその状態が続いてしまうので、とりあえず出来そうなところは修正してもらったほうがいいだろう。

で、まあ、結果としていくつか採用されてsvnにコミットされたので、いままで必要だった手間は幾分減ることになった。
次のstable release予定の1.4.0では、インストール時にライブラリを別名でコピーするくらいで済むのかな。

追記 2011年10月22日
Ubuntu11.10上でクロスコンパイルしようかと思いsvnのログを確認してみたら、ライブラリ名変更のリクエストもちゃんと受理してもらえてました。
http://websvn.xvid.org/cvs/viewvc.cgi?view=rev&revision=2044
これで自分としてはパッチは完全に不要になりました。
Isibaarさん、ありがとうございました！

avs2pipemod その8

2011-09-19T11:40:00.001+09:00

更新しました。

avs2pipemod-20110919.zip
https://github.com/chikuzen/avs2pipemod

*新機能'trim'を追加。

Doom9で「avs2yuvみたいに-seekや-framesをサポート出来ないか」とリクエストを受けたので追加してみました。
内部でavisynthのTrim()を呼び出すだけの簡単なお仕事だし、まああっても邪魔にはならないと思ったので。

使い方
avs2pipemod -y4mp -trim=100,200 input.avs > output.y4m
というふうにすれば、avsの最後にTrim(100,200)を書いたのと同じようになります。
-infoと-x264bdでは無視されます。

ところでリクエストしてきたStephen R. Savage氏は別名thewebchatというファンサブ界の厄介者らしい。
そーいや昔120fpsAVIの作り方とか調べてたな…物好きなこと。

コンパイラによる最適化の押し付けにむかついた件について

2011-09-04T03:18:00.004+09:00

GCCの各オプティマイズレベルで有効になる最適化を調べるを読んでちょっと興味がわいたので、いろいろ手元の環境でも確認してみた。
試したマシンはQ9450とT7300のせいかどれもリンク先と同じ結果になったわけですが、とにかく意外だったのは
*-O2と-Osの違いは-finline-functionsの有無だけ(-Osは有り、-O2は無し)。

-Osはサイズ優先の最適化のはずだけど、-O3(とにかくスピード優先)でも-finline-functionsがつくのであれば、これを有効にすればそこそこスピードアップの可能性があるということだろう。
じゃあ、-O2の存在意義って一体なあに？
-O3程ではないが、それなりにスピード優先のはずなんだけど…。

とまあ、前置きはこのくらいにして、今度は各プロジェクトが設定しているデフォルトの最適化設定を調べてみた。

例えばx264は--extra-cflagsを設定しなければ

"-O3 -ffast-math -march=i686 -mfpmath=sse -msse -fomit-frame-pointer -fno-tree-vectorize -fno-zero-initialized-in-bss"

がつく(x86の場合)。
いかにも互換性を気にしつつも速そうな設定という感じですね。
まあ、クリティカルな部分はほぼすべてasmで書かれてCPU検出で自動的に有効にするので、コンパイラによるCコードの最適化はあまり影響しないそうですが。

これがxvidだと

"-O2 -fstrength-reduce -finline-functions -ffast-math -fomit-frame-pointer"

となっている。
configure.inには

First we test if CFLAGS have been passed on command line

I do that because autoconf defaults (-g -O2) suck and they would kill performance.

To prevent that we define a good defult CFLAGS at the end of the script if and only

if CFLAGS has not been passed on the command line

なんて書かれてますが、それにしては中途半端という印象が否めない。
現在でも更新は続いているんだから、いい加減sseをデフォルトにするくらいはしてもいいのでは？
configure.inにはこのデフォルト値に対して"Default CFLAGS -- Big impact on overall speed"とも書かれているあたり、コンパイラによる最適化はかなり重要みたいなんだけど…自分で設定したほうがよさそうですな。

さて問題はa52dec。
これのconfigure.inは以下のような感じになっている。

if test x"$GCC" = x"yes"; then

    changequote(<<,>>)

    OPT_CFLAGS=`echo "$CFLAGS"|sed "s/-O[0-9]*//g"`

    changequote([,])

    OPT_CFLAGS="$OPT_CFLAGS -O3"

    AC_TRY_CFLAGS([$OPT_CFLAGS],[CFLAGS=$OPT_CFLAGS])

なんとコンパイラがGCCだったら有無を言わさず-O3強制です。
たとえば何らかの理由でデバッグビルドしようと思ってCFLAGS="-O0 -g"しても、-O0は削除されて"-g -O3"なんていうへんてこりんなコードが出力されてしまいます。
しかも-O3は勝手につけるのに、-fno-tree-vectorizeはなし。
liba52はとても古いプロジェクトでCVSの最終更新は7年前。もはや死んだといってもおかしくない。
当時は-O3だけでも問題なかったのかも知れませんが、現在ではまともな出力が得られるかどうか非常に疑わしい、地雷コードと化しています。
これは不安定な-ftree-vectorizeを-O3で有効にしたままなかなか直さない(直せない?)GCCが悪いとも言えるかも知れないけど、素人がコードいじらなきゃいけないような自体はなるべく避けて欲しいなぁ。
とりあえずこんなパッチを書いてみたので、何かの事情で今時a52decをビルドしなければならない人は当てたほうがいいかもしれません。

あともう一つ、openjpegプロジェクト。
現在のstable release?であるはずのopenjpeg_v1_4_sources_r697.tgzをビルドしてみたら、設定したCFLAGSが全く反映されません。
なんでかな？とlibopenjpeg/Makefile.amを見てみたら

INCLUDES = -I.. -I.

COMPILERFLAGS = -Wall -O3 -ffast-math -std=c99

if with_sharedlibs

COMPILERFLAGS += -DOPJ_EXPORTS

else

COMPILERFLAGS += -DOPJ_STATIC

libopenjpeg_la_LDFLAGS += -static

endif

CFLAGS = $(COMPILERFLAGS) $(INCLUDES)

お前もかよ(そしてこれも-fno-tree-vectorizeなし)。
svnの最新コードなら直ってるかなと見てみると今度はcomfigure.acのほうで

if test "x${want_debug}" = "xyes" ; then

   OPJ_COMPILER_FLAG([-g])

   OPJ_COMPILER_FLAG([-O0])

else

   OPJ_COMPILER_FLAG([-O3])

fi

あくまでも-O3は決定ですかそーですか...........むかつくわホント

バッファサイズ

2011-07-09T14:05:00.000+09:00

前回の記事で筆者は「avs2yuvはバッファが512Bしかないから、256KiBのavs2pipemodよりも遅い」と書いたわけですが、これを読んだ人なら誰でも「じゃあ、avs2yuvのほうもバッファを増やせば速くなるんじゃね？」と考えるのではないでしょうか？

はい、もちろん速くなります。

バッファの拡張なんていうとなにやら大げさですが、やることといえば単にsetvbuf()というCの標準関数を使うだけです。
試しにavs2yuvの書き込みバッファを128KiBに増やして前回のベンチマークをもう一度回してみると…平均284.48fps。
ぐは、今度はavs2pipemodが負けた…orz

悔しいので、avs2pipemodのほうのバッファサイズを256KiBから128KiBに減らしてみると…平均285.05fps。どうやら引き分けといったところでしょうか。

             avs2yuv     avs2pipemod     avs2pipemod
buffsize     128KiB         256KiB          128KiB
1st (fps)    285.18         279.97          281.66
2nd (fps)    283.45         274.59          285.96
3rd (fps)    281.75         272.27          286.85
4th (fps)    285.86         271.92          285.63
5th (fps)    286.16         274.00          285.18
avg (fps)    284.48         274.55          285.05

このように、バッファサイズは少なすぎてはいけませんが、かといって多ければいいというものでもない。
ハードや扱う素材等によっても最適値は変化するでしょう。
でもそこらへんまで追求を始めると「湾岸ミッドナイト」な世界に突入してしまいそうです。
まあ、64KiB～256KiBくらいにしておくのが無難じゃないですかね。

てなわけで、このへんでお開き。
とりあえずバッファを128KiBにしたavs2yuv(MasterNobody版ベース)とavs2pipemodを置いときます。
avs2yuv_c99-mod.zip
avs2pipemod-20110709.zip

追記 2011.09.21
Doom9でこのことについて少し書いたら、MasterNobody氏がこれを取り込んだバージョンを出しました。
http://forum.doom9.org/showthread.php?t=162578
avs2yuv-0.24bm2.zip
追加機能でi422/i444対応も入っているので、自分の改造板avs2yuvを使うメリットはもはやありません。
MasterNobody氏のavs2yuvを使うことをおすすめします。

avs2yuv その２

2011-07-09T03:43:00.003+09:00

前回avs2yuvの修正/改造版をリリースしたら、直後に今度はMasterNobody(Anton Mitrofanov、別名BugMaster)氏がC言語版のavs2yuvを出した。
avsからy4mで出力するツールが一気に増えてしまったので、ここらへんで整理してみようかと思う。

まずavs2yuvを使うならどれがいいのか？
avs2yuvは本家(pengvado版)、kemuri-_9版、MasterNobody版、そして筆者のものの4種類がありますが、一番のオススメはMasterNobody氏の最新版です。
スピードや出力自体はどれもたいして変わりませんが、終了時、及びエラー時の処理が一番丁寧に行われています。
加えてバイナリのサイズも一番小さく、筆者版のように追加で必要なランタイムもありません。
さらにavisynthMTを使っている場合は自動でavsの最後にDistributor()を追加するようにもなっています。
おまけにmingw用のコードなので、LinuxやMacでも簡単にクロスコンパイル出来ます。
ついでに言えば、64bit用バイナリも同梱されています。
avs2yuvを使うなら、多分これが一番いいでしょう。

では他のツールも含めた場合ならどれがいいのか？
とりあえず使用目的が32bitのavisynthの出力をpipeで64bitのx264に渡すこと、もしくはwineでavisynthを使うことなら、現状ではavs2pipemodが一番いいです。
理由は単純に一番速いから。
avs2yuvの現在配布されているバイナリすべて、そしてavs2pipe-0.0.3は、ファイル書き込み用バッファを512Byteしか持っていません(stdio.hで定義されている値をそのまま使っています)。
非圧縮フォーマットであるy4mにとって、これはいささか少なすぎます。
ffmpegに至っては、avs2yuvよりもさらに遅い上にオプションがやたら長くなります。

ffmpeg -v 0 -i foo.avs -pix_fmt yuv420p -vcodec rawvideo -an -f yuv4mpegpipe - | x264 - --demuxer y4m ...

一方avs2pipemodは、以前書いたように書き込み用バッファを拡張しています(20110703版の時点では256KiByte)。
これにより発生するスピード差は次のようなベンチマークをしてみれば一目瞭然です。


#!/bin/bash

echo ColorBars\(1280,720,\"YV12\"\).Trim\(0,4999\) > ./ColorBars.avs

#avs2yuvとavs2pipemodで同じavs(5000フレーム)をそれぞれ5回ずつ回してみる。
#avs2yuvはMasterNobody版を使用

for i in {1..5}; do
avs2yuv ./ColorBars.avs -o - | x264 - --demuxer y4m --preset ultrafast -o /dev/null
done

for i in {1..5}; do
avs2pipemod -y4mp ./ColorBars.avs | x264 - --demuxer y4m --preset ultrafast -o /dev/null
done

さて、自分の環境での結果は以下の通りでした。


        avs2yuv     avs2pipemod
1st    213.04fps     276.53fps
2nd    211.18fps     273.69fps
3rd    213.53fps     275.32fps
4th    213.69fps     276.53fps
5th    213.07fps     276.59fps
avg    212.90fps     275.73fps

実際のエンコードにおいてはこんなに軽いavsを使うことはないでしょうし、x264の設定もずっと重くなりますから、差はかなり縮まるでしょう。
しかし、avs2pipemodがavs2yuvよりも遅くなることは、まずありえない話です。

avs2yuv

2011-07-04T23:26:00.002+09:00

Windows7を使い始めてからしばらくした頃、avs2yuvがクラッシュするようになった。
Doom9とかでは特に問題になっていなかったので自分の環境だけかと思っていたのだが、しばらくしてdoom10のほうにこんなスレッドが立ち、自分以外にも同じ問題を抱えている人がいることを知った。

解決策が見つからないので、しばらくの間はavs2yuvのかわりにffmpegを使っていた。
そのうちにdoobry氏がavs2pipeをリリースしたので自分はこちらに乗り換え、さらにこれをより自分好みなツールに改造すべくC/C++の学習を本格的に始めてしまったわけだが、avs2yuvの件はずっと脳内の片隅に引っ掛かっていた。

さて、今日になってこのスレッドを何気なく読んでいたら、とても気になる記述が…。

avs2yuv 0.24 fix: http://forum.doom9.org/showthread.php?t=145912

まさか２年以上前に、すでに解決策が出ていたとはなぁ…不覚orz
とりあえず、このパッチを適用したバイナリはどこにもないようなので、ビルドして配布することにした。
ついでに-hfyu用のエンコーダーをmencoderからffmpegに変更(現在のmencoderはffmpeg以上に信用出来ない地雷ツールなので)したので、もうちょっと便利になったと思う。

avs2yuv-0.24m.zip (要msvcr100.dll)
https://github.com/chikuzen/avs2yuv

avs2pipemod その7

2011-07-03T14:28:00.004+09:00

更新。
この前waviのコードを読んだのをきっかけに、RIFF-WAVEフォーマットについていろいろ調べてみました。
どうやらものに出来たようなので、avs2pipemodに新機能を追加。

avs2pipemod-20110703.zip
https://github.com/chikuzen/avs2pipemod

*'-audio'オプションを廃止し、'-wav'と'-extwav'オプションを追加
'-wav'は、一般的なriff-wave(.wav)フォーマットで出力します。
'-extwav'は、チャンネルマスク付きのwave extensible formatで出力します。
チャンネルマスクはチャンネル数に応じて決め打ちになるので、特殊なスピーカー配置の場合はwaviを使ったほうが良いでしょう。
PCM音声の場合、wave extensible formatが普通のwavよりいいところはチャンネルマスクを付けられる点だけなわけですが、これをサポートしているソフトはそれほど多くはないようです。
よく分からない場合は'-wav'を使いましょう。
ちなみにこれまでの'-audio'は「チャンネルマスク無しのwave extensible format」という微妙すぎるものしか出力できませんでした。

*'-rawvideo'の引数にvflipを追加
avs2pipemod -rawvideo=vflip input.avs とすれば、映像の上下を反転して出力します。
RGB出力時の反転対策です。

追記
Doom9に投稿したらIanB氏にオプションを変えたことでお小言をくらってしまったので、-audioでも-extwavと同じ挙動をするように変更しました。
avs2pipemod-20110703-2.zip

ARDeformation.dll その２

2011-06-23T01:16:00.002+09:00

さて、この前公開してみたARDeformation.dllですが、よく考えてみると設計ミスをしていることに気づきました。
ARResizeの引数の順番が、どう考えてもおかしい。
modeを一番最初にもってきてしまっているため、使用時は"dar"であれ"sar"であれ、常にmodeを指定するか、引数を名前付きで指定しなければならなくなってしまっています。

例)
DAR16:9にリサイズしたい場合　…　ARResize("dar", 16, 9)　もしくは　ARResize(ar_x=16, ar_y=9)
SAR40:33にリサイズしたい場合 …　ARResize("sar", 40, 33)

これでは使いにくいので、引数の順番を変更しました。
とりあえずmodeは一番最後に変更したため、sar/parの場合は常にmode="sar"(or "par")とするようになりました。

例)
DAR16:9にリサイズしたい場合　…　ARResize(16, 9)
SAR40:33にリサイズしたい場合 …　ARResize(40, 33, mode="sar")

他の順番も少し変更したので、詳細はreadmeを読んでください。

ARDeformation_20110622.zip
https://github.com/chikuzen/ARDeformation

Fix wavi

2011-06-17T02:55:00.003+09:00

昨日、ちょっとしたきっかけで、wavi.exeがクラッシュすることがあるのに気づいた。
なぜか音声ファイル(.wav)の書き出し終了時に落ちるのである。

(Chikuzen) wavi.exeが何故かクラッシュするのでコードを覗いてみたが
(Chikuzen) あまりにも汚いので10分の1で投げ出してしまった
(VFRmaniac) 笑
(Chikuzen)とりあえずCleanupAndExit()でクラッシュするみたいなので、そのあたりにfprintfを大量に仕込んでみると
(Chikuzen) LocalFree()で失敗することがわかった
(VFRmaniac) いきなり長文のstderrで吹いた
(VFRmaniac) 二重解放？
(Chikuzen) 多分そう　＞二重開放
(Chikuzen) そもそもどこでバッファ確保してるんだろ、これ
(VFRmaniac) ちょっとまて...
(VFRmaniac) LPBYTE buffer[2][BUFFER_SIZE];
(VFRmaniac) これ、動的に確保してなくね？
(VFRmaniac) LocalAlloc も LocalReAllocもみつかんねーぞ！
(VFRmaniac) http://msdn.microsoft.com/ja-jp/library/cc430156.aspx
(VFRmaniac) この行不要じゃね？
(Chikuzen) そうよね、配列使って静的に確保してるよね

てなわけで直ったので、ついでにtebasuna51氏のパッチあててDoom9に置いてきました
http://forum.doom9.org/showthread.php?t=161639

RawSource.dll その5

2011-06-15T05:43:00.000+09:00

AviSynth2.6用に大幅に書き直したものです。

RawSource_26_dll_20110614.zip
https://github.com/chikuzen/RawSource_2.6x

*I444,YV24の読み込みに対応。
*YUV411をYUY2ではなくYV411で読み込むように変更。
*I422,YV16はYV16で読み込むように変更。
*Y8はYV12ではなくY8で読み込むように変更(これにより奇数解像度に対応)。

必要なもの
AviSynth2.6.0alpha2以降
SSEマシン
msvcr100.dll

ARDeformation.dll

2011-06-14T21:06:00.003+09:00

さて、前回のコードにさらに手を加えてみたのがこのプラグインです。

更新しました
https://github.com/chikuzen/ARDeformation

使い方

DARPadding(clip, float "dar_x", float "dar_y", int "align", int "color")

　　指定したDARにあわせて、左右または上下にベタを付与します。
　　dar_x: DARの分子(水平方向)の値　(デフォルト：clip.width)
　　dar_y: DARの分母(垂直方向)の値　(デフォルト：clip.height)
　　align：左(または上)にパディングされるベタの幅を、この値の倍数になるように調整する(デフォルト：16)
　　color：ベタの色指定　(デフォルト：$00000000(黒))

なんらかの理由でレターボックス/ピラーボックスにしてエンコしないといけない場合に使うといいかも知れません(もちろん使わないにこしたことはありませんが)。
alignのデフォルトは16なので、そのまま使えば若干左寄り(若しくは上寄り)になります。それが嫌な場合はalignを1にすれば、(ほぼ)ど真ん中になります。

ARResize(clip, string "mode", float "ar_x", float "ar_y", bool "expand", float "src_left", float "src_top",
　　　　　float "src_right", float "src_bottom", string "resizer", float "ep0", float "ep1", int "dest_w", int "dest_h")

　　指定したアスペクト比にあわせて、本体内蔵のリサイザを使ってリサイズします。
　　mode: アスペクト比のタイプ("dar","sar","par")を指定します。(デフォルト："dar")
　　ar_x: アスペクト比の分子(水平方向)の値。(デフォルト：clip.width(dar) or 1(sar/par))
　　ar_y: アスペクト比の分母(垂直方向)の値。(デフォルト：clip.height(dar) or 1(sar/par))
　　expand: 拡大するか縮小するかを選びます。(デフォルト：true(拡大))
　　src_*：avisynthの各リサイザの引数と同じです。 (デフォルト：0)
　　resizer: 呼び出すリサイザを指定します。(デフォルト："Bicubic")
　　ep0: 各リサイザ固有の引数その1。lanczosの"taps"やBicubicの"b"を指定します。 (デフォルト：各リサイザの規定値)
　　ep1: 各リサイザ固有の引数その2。Bicubicの"c"がこれにあたります。(デフォルト：1.0/3)
　　dest_w: 出力のwidthをこの値に矯正します。(デフォルト：0(無効))
　　dest_h: 出力のheightをこの値に矯正します。dest_wが0以外の場合は無視されます。(デフォルト：0(無効))
　　なおdest_w,dest_hを設定した場合は、expandは無視されます。

例えばDVDソースにARResize("dar",16,9,true,8,0,-8,0,"lanczos4")とすれば、無効領域を削ってLanczos4Resizeで16:9に拡大(854x480、PALなら1024x576)します。

二つとも必要な計算を行って、avisynth.dll内の関数を呼び出しているだけなので、スクリプトでも可能でしょう。
しかし、ARResizeのほうは…これと同等のものをスクリプトで書きたいとは思いませんね。めんどすぎます。そもそもavsのfloatでの計算だと精度が落ちるような気もするし。

興味がある人は、自分でもなにかやってみてください。
結構面白いです。

スクリプトをプラグインにしてみる

2011-06-14T06:31:00.007+09:00

前回は簡単な関数をプラグインにしたので、今回は簡単なユーザースクリプト関数をプラグインにしてみることにしました。

まずこんなスクリプトを用意してみます。


#DAR_Padding.avs
function DAR_Padding(clip c, float "dar_x", float "dar_y", int "color", int "align") {
    dar_x = default(float(dar_x), float(c.width))
    dar_y = default(float(dar_y), float(c.height))
    color = default(color, $000000)
    align = default(align, 16)

    Assert(dar_x > 0 && dar_y > 0, "\"dar_x\" and \"dar_y\" need to be positive values.")
    Assert(align >= 1, "align needs to be 1 or heigher integer.")

    flag = c.width * dar_y - c.height * dar_x
    subsample_h = c.IsYUY2 || c.IsYV16 || c.IsYV12 ? 2 : 1
    #IsYV411は現時点(avisynth2.6.0a3)ではまだ作られてないので、YV411非対応
    subsample_v = c.IsYV12 ? 2 : 1

    dest_width  = flag < 0 ? int(ceil(c.height * dar_x / dar_y)) : c.width
    dest_width  = dest_width + (dest_width % subsample_h)

    dest_height = flag > 0 ? int(ceil(c.width * dar_y / dar_x)) : c.height
    dest_height = dest_height + (dest_height % subsample_v)

    pad_left = (dest_width - c.width) / 2
    pad_left = pad_left - (pad_left % subsample_h)
    pad_left = adjust_align(pad_left, align, subsample_h)

    pad_right = dest_width - (c.width + pad_left)

    pad_top = (dest_height - c.height) / 2
    pad_top = pad_top - (pad_top % subsample_v)
    pad_top = adjust_align(pad_top, align, subsample_v)

    pad_bottom = dest_height - (c.height + pad_top)

    return c.AddBorders(pad_left, pad_top, pad_right, pad_bottom, color)
}

function adjust_align(int pad, int align, int subsample) {
    return pad % align == 0 ? pad : adjust_align(pad - subsample, align, subsample)
}

はやい話が指定したDARにあわせて左右（または上下)に自動的にAddBordersでパディングするという関数です。
さて、これをC++で書いてみるとこうなりました。


//DAR_Padding.dll
#include <math.h>
#include "windows.h"
#include "avisynth26.h"

#pragma  warning(disable:4996)

class DAR_Padding : public GenericVideoFilter {

    PClip padded;

public:
    DAR_Padding(PClip _child, const float _dar_x, const float _dar_y,
                const int align, const int color, IScriptEnvironment* env);
    ~DAR_Padding() { }
    PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
};

DAR_Padding::
DAR_Padding(PClip _child, const float _dar_x, const float _dar_y, const int color,
            const int align, IScriptEnvironment* env) : GenericVideoFilter(_child)
{
    double dar_x = !_dar_x ? (double)vi.width : (double)_dar_x;
    double dar_y = !_dar_y ? (double)vi.height : (double)_dar_y;

    double flag = vi.width * dar_y - vi.height * dar_x;
    int dest_width = flag < 0 ? (int)ceil(vi.height * dar_x / dar_y) : vi.width;
    int dest_height = flag > 0 ? (int)ceil(dest_width * dar_y / dar_x) : vi.height;

    int subsample_h = vi.SubsampleH();
    int subsample_v = vi.SubsampleV();
    //SubsampleH(),SubsampleV()は、自分で作ってavisynth.hに追加した関数(YV411対応)。
    dest_width += dest_width % subsample_h;
    dest_height += dest_height % subsample_v;

    int pad_left = (dest_width - vi.width) >> 1;
    pad_left -= (pad_left % subsample_h);
    while(pad_left % align)
        pad_left -= subsample_h;

    int pad_right = dest_width - (vi.width + pad_left);

    int pad_top = (dest_height - vi.height) >> 1;
    pad_top -= (pad_top % subsample_v);
    while(pad_top % align)
        pad_left -= subsample_h;

    int pad_bottom = dest_height - (vi.height + pad_top);

    vi.width = dest_width;
    vi.height = dest_height;

    try {
        AVSValue padargs[6] = {child, pad_left, pad_top, pad_right, pad_bottom, color};
        padded = env->Invoke("AddBorders", AVSValue(padargs, 6)).AsClip();
    } catch (IScriptEnvironment::NotFound) {
        env->ThrowError("DAR_Padding: Couldn't Invoke AddBorders.");
    }
}

PVideoFrame __stdcall DAR_Padding::
GetFrame(int n, IScriptEnvironment* env)
{
    return padded->GetFrame(n, env);
}

AVSValue __cdecl Create_DAR_Padding(AVSValue args, void* user_data, IScriptEnvironment* env)
{
    const float dx = args[1].AsFloat(0.0);
    const float dy = args[2].AsFloat(0.0);
    const int cl = args[3].AsInt(0);
    const int al = args[4].AsInt(16);

    if (dx < 0 || dy < 0)
        env->ThrowError("DAR_Padding: \"dar_x\" and \"dar_y\" need to be positive values.");
    if (align < 1)
        env->ThrowError("DAR_Padding: \"align\" needs to be 1 or higher integer.");

    return new DAR_Padding(args[0].AsClip(), dx, dy, cl, al, env);
}

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env)
{
    env->AddFunction("DAR_Padding", "c[dar_x]f[dar_y]f[color]i[align]i", Create_DAR_Padding, 0);
    return 0;
}

わかったこと
たしかにC/C++で書くための煩雑な手続き（クラスの宣言とか）は必要になりますが、if/for/whileといったものが使える分、プラグインのほうがむしろ書きやすいかもしれません。
それに、AviSynthの内部情報に直接アクセスできる点も有利です。
三項演算子や再帰を使ってあれこれ考えるのに飽きた人は挑戦してみるといいかも。

FCollections.dll

2011-06-05T05:59:00.001+09:00

RawSource.dllの改造も一段落ついたような気がしたので、なにか新しいものを書いてみたくなりました。

あまり難しいものは書けそうにないし、そもそもネタもない。
なにか簡単そうなやつがいいということで、あれこれ考えているうちに目をつけたのがfilter script用関数。
つまりint()とかstring()とかIsClip()とかの類のことですね。
すでに役に立ちそうな関数はあらかた本体の方に揃っているので、それほど役に立つものは書けないだろうけど、初心者の学習用には調度良いような気がしたのでやってみました。

FCollections-20110604.zip
https://github.com/chikuzen/FCollections

以下、説明。

必要なもの:
AviSynth2.5x or later
SSEが使えるマシン(拡張命令セットでSSE有効にしています)
msvcr100.dll

TimeStringToMilliSecond(string "time string"):
時間をあらわす文字列"xx:xx:xx.xxx"をミリ秒単位の整数に変換します。
関数名がやたら長いのでTS2MS()でも使えるようにしてあります。
最初は秒単位の浮動小数点に変換するつもりだったのですが、AviSynthスクリプトはdouble(倍精度浮動小数点)をfloat(単精度浮動小数点)にキャストしてしまうようで、仕方なく整数で返すようにしました(floatの精度では酷い誤差が出てしまう…orz)
SSE搭載マシン(PentiumIII)の発売が1999年、AviSynth2.5の開発はavisynth.hによれば2002年ですから、倍精度をサポートしてないのは首をひねってしまうところですが…。

GCD(int val1, int val2, ...):
最大公約数を返します。

LCM(int val1, int val2, ...):
最小公倍数を返します。

Fibo(int n):
フィボナッチ数を返します。
AviSynthスクリプトの扱える整数は(今のところ)int32_t(-2147483648から2147483647)なので、フィボナッチ数は46(1836311903)までしか扱えません(47は2971215073でout of range)。
0を含めて全部で47しかないなら、わざわざその場で計算させることもなかろうということで、テーブル化してしまいました。
はたしてこれに使い途があるのかどうかはさっぱりわかりません。

IsEven(int n):
nが偶数ならtrue、奇数ならfalseを返します。
(n % 2 == 0)と同じですね。

Clamp(val, low, high):
StickBoy氏のMinMax.dllのやつと全く同じです。
valがlowより小さければlowを、highより大きければhighを、lowとhighの間の値だったらvalをそのまま返します。
FCollectionsを書くに当たって参考にしたのがまさにMinMax.dllのコードだったわけですが、Min()とMax()はAviSynth2.5.8で本体にも入ったのにClamp()は入ってないのでついでに入れてしまいました。

なにか追加してみたい関数が見つかったら、更新するつもりです。

RawSource.dll その4

2011-05-30T06:17:00.003+09:00

さて、これまで色々RawSourceのコードをいじって遊んできたわけですが、考えてみれば原著作者であるWarpEnterprises氏の許可は一切取っていませんでした。
avs2pipemodの場合はオリジナルがGPLv3だったのでなんの気兼ねもなくいじってよかったわけですが、RawSourceの場合はライセンスに関する記載が全くありません。
AviSynth自体はGPLv2ですが、プラグインに関しては過去の経緯から作者がライセンスを自分で決めてよいことになっています。
まあ、コードも公開されているわけですから多分問題は起きないとは思うけど、ほおっておくのも気持ち悪い。
てなわけで、とりあえずメールで問い合せてみたら、すぐにお返事が来ました。


Hi!
 The code has no explicit license, so I am glad someone uses it or the ideas behind,
as long as it keeps as open as possible (like GPL describes, I think).
 There were also some small contributions by others, if I remember correctly (Wilbert, billou2k),
which I integrated but not mentioned them (shame on me, didn't care and know much about licenses back then).
I hope it's ok for you if I put your version on my filter colllection website occasionally.

Greetings from Austria,
Ernst / WarpEnterprises

結局ライセンスは決まらずじまいですがとりあえず許可は貰えたので、これからも好きにやってよさそうですね。
よかった、よかった。

気を良くしたので更新
RawSource_25_dll_20110529.zip
*widthの最大値を2880から4096に変更
*引数にfpsnumとfpsdenを追加(デフォルトはそれぞれ25と1)
*エラーチェックを強化

RawSource.dll その3

2011-05-23T20:16:00.003+09:00

更新。
ABGRとNV12/NV21をサポートしました。

RawSource_25_dll_20110523.zip

ソースコード
https://github.com/chikuzen/RawSource_2.5x

これでAviSynth2.5でサポートできそうな8bitフォーマットはだいたい網羅できたはず。
次は2.6用に書き直してみるかな。

RawSource.dll その２

2011-05-21T23:26:00.004+09:00

ここ最近、avs2pipemodを色々いじったおかげで、C/C++及びYUV4MPEG2/RAWデータ、そしてAviSynthの内部処理への理解が自分としては結構進んだように思います。
なんだかようやく初心者といっても良いレベルになれたかも。

さて、今年の1月にやったRawSource.dllの改造は、実は結構まずいものでした(YUV422なY4Mに対応したようでいて、実はUとVがswapしてしまったりとか)。
どーしたもんかとずっと気にはなっていたけど悲しいことに実力不足で手が付けられなかったわけですが…昨日改めてコードを読みなおしてみたらあらびっくり、理解できるようになっていました。
てなわけで早速修正版リリース。
あとついでに、YV411の対応とか、Y4Mのインタレ周りの処理(これは元々WarpEnterprises氏のころから変だった)の修正とかもやりました。

バイナリ
更新したので削除しました

RawSource_25_dll_20060728(WarpEnterprises最終版)からの変更点
*64文字以上のYUV4MPEG2ヘッダーに対応(最大128文字)
*I422(YUV422planar)に対応
*I411(YUV411planar)、YV411(YVU411planar)に対応(出力は色差補間なしのYUY2)
*ARGBに対応
*pixel_type指定にYUY2とIYUVを追加(これまではYUYV/I420しか指定できなかった)
*I420以外の色空間のYUV4MPEG2に対応(ただし、YUV444/YUV444alphaを除く)
*YUV4MPEG2ヘッダーのIタグによるフィールドオーダー指定を修正(これまではなぜかItやIbだとフィールドベースになるという謎仕様だった。なお、Imには未対応のまま)
*msvcr100.dllが必要(どーやったらstatic linkに出来るんでしょうね？)

ソースコードはこちら
https://github.com/chikuzen/RawSource_2.5x

contributor

2011-05-14T03:30:00.001+09:00

自分が書いたパッチがx264の公式gitレポにコミットされました。

まあ、パッチと言ってもわずか一行、lavf入力時のエラーチェックを増やしただけなんですが。

2011年4月28日、#x264dev@freenode
(Chikuzen) Dark_Shikari: http://pastebin.com/xxxxxxxx
(Dark_Shikari) explain?
(Chikuzen) e.g x264 - --demuxer lavf --input-csp yuyv420 --input-res ... <- go to fail
(Dark_Shikari) what about ffms?
(Dark_Shikari) and why
(Chikuzen) I mistook yuyv420 for yuyv422 a minute ago
(Chikuzen) but encoding was done, and i wasted my time
(saintdev) yuyvvuy444
(Chikuzen) this is a case in raw input
(Chikuzen) ffms can't accept raw
(Dark_Shikari) ok

パッチを書いた理由も効果も取るに足らないものですが、これでもx264のrevは一つ上がり、晴れて自分はcontributorとしてChangelogに名前がのることになったわけです。

何が言いたいかといえば、
・不具合や不満があるなら開発者本人に伝えること。
　英語が苦手？　俺だってそうだよ。
　"All your base are belong to us"レベルの間違いは山ほどやってらぁ
・どんなつまらないパッチでも、そう変更すべき理由があると思うならちゃんと提出すること。
ですかね。

High-bit-depth AVCデコーダ

2011-05-11T10:01:00.010+09:00

この度、ついにlibavにH.264/AVCのHigh bit depth対応デコーダがコミットされた。

思い起こせばx264がhigh-bit-depthをサポートしたのがr1666(2010年7月)だから、かれこれ10ヶ月前。
以来、使いたくてもデコーダがないから使う甲斐が無いというなんとももどかしい状態からやっと開放される時がやって来た！(MainConcept? 悪いけど趣味に合わないんで…)

というわけで、以下、色々なところで起こったちょっとしたお祭り騒ぎの記録より。

#x264dev@freenode
(BBB) irock: 10bit pushed

#L-SMASH@freenode
(Chikuzen) うお、10bitデコーダがlibavにも入った？
(JEEB) yes
(Chikuzen) ええい、mplayer2の次のリリースはまだか
(Chikuzen) JEEB: ちょっとuau氏かlachs0r氏をぶん殴って新しいの出させてきてよ
(JEEB) おう

#mplayer2@freenode
(JEEB) 10bit H.264 decoding got into libav \o/
(JEEB) uau, how much work do you think it'd be to add 10bit H.264 support into mplayer2? libswscale seems to handle 10bit 4:2:0 to "your usual" RGB already :3

秘密の某所にて
(JEEB) 10bit support getting into libav patch-by-patch gentlemen!
(JEEB) YEAAAAAAAH
(elenril) all hail BBB
(JEEB) all hail BBB!
(Dark_Shikari) now we need:
(Dark_Shikari) 1) dither
(Dark_Shikari) 2) support in ffdshow
(Dark_Shikari) 3) make sure normal playback does the dither
(elenril) send patches =p
(Dark_Shikari) 4) cccp release
(Dark_Shikari) elenril: dither patches are already sent
(JEEB) also, just kicked uau on the issue :3
(jfs) ooooh I know, patch vsfilter to render subs on 16 bit/plane surfaces!
(jfs) ._.
(Dark_Shikari) when we switch to 10 bit
(Dark_Shikari) THIS MEANS YOU HAVE TO STOP ENCODING AT 5 BILLION MBPS OK?
(Dark_Shikari) crf 22 is now OK. No crf 14.
(Dark_Shikari) Because you can no longer complain about banding.

#libav-devel@freenode
*Dark_Shikari join #libav-devel
*ChanServ mode +o Dark_Shikari
(Dark_Shikari) so, explain to me how this 10-bit h264 templating works
(Dark_Shikari) and how it'll apply to asm
(Dark_Shikari) and I'll submit some asm patches
(kshishkov) Dark_Shikari: it's easy - you just initialize pointer to different functions depending on bits provided
(Dark_Shikari) kshishkov: I meant how do I make it compile a file twice?
(Dark_Shikari) once with 10-bit, once with 8-bit
(Dark_Shikari) also where the fuck did my fate samples folder go
(kshishkov) Dark_Shikari: templating - define things, include file, redefint things, include file again
(Dark_Shikari) in asm?
(kshishkov) why not?
(kshishkov) even Nasm has %include
(Dark_Shikari) where's the rsync command to download fate samples?
(Dark_Shikari) I lost mine
(lu_zero) Dark_Shikari: there is a make target that should work
(lu_zero) make fate-rsync
(lu_zero) rsync -vaLW rsync://fate-suite.libav.org/fate-suite/ $place
(Dark_Shikari) lu_zero: thx, running
(BBB) Dark_Shikari you're awesome if you do the asm
(Jumpyshoes) has 10-bit been pushed?
(Dark_Shikari) yes
(Jumpyshoes) oh
(Jumpyshoes) well there goes my excuse
(Dark_Shikari) ｗｗｗｗ
(Dark_Shikari) so yeah, time to asm

#L-SMASH
(Chikuzen) 10bitがコミットされるやいなや#libav-develにjoinするD_S
(Chikuzen) ホント、現金なアンチャンだこと
(JEEB) ですな
(silverfilain) その貪欲さが彼をあそこまでにしてるんだろうなぁ
(Chikuzen) この前#libav-develでわめき散らしたのはなんだったのかと
(Chikuzen) まあ、君子豹変と言えなくもないが…

#mplayer2
(lachs0r) http://**********/mplayer2-high-bit-depth-20110510.7z

#L-SMASH
(Chikuzen) もう来たのか
(JEEB) いぇす
(Chikuzen) やっぱ、みんな待ち焦がれてたのね

なんで騒いでるのかわからない？
ならばあなたはまだ動画エンコードの泥沼に浸かってない(もしくは足を洗った)一般人ってことですね。
それはとても良いことですから、気にしなくてもいいですよ、いやほんとに。

追記、というか登場人物紹介
BBB　　Ronald S. Bultje、Libav developerのリーダー格、ffmpeg-mtや今回のデコーダの不具合解消に大活躍中の人
Chikuzen　　筆者
Dark_Shikari　　Jason Garrett-Glaser、x264 lead developer
elenril　　Anton Khirnov、Libav developer/committer
irock　　Oskar Arvidsson、x264のhigh-bit-depthエンコーダ、そして今回のデコーダを書いた人
Jumpyshoes　　Daniel Kang、x264 / Libav developer
JEEB　　アニオタフィンランド人兼二代目CCCP maintainer?
jfs　　Niels Martin Hansen、Aegisub main developer
kshishkov　　Kostya Shishkov、Libav developer/committer
lachs0r　　mplayer2 project member、Windows用ビルド担当
lu_zero　　Luca Barbato、Gentoo developer、Libav developer/committer
silverfilain　　L-SMASH developer、猫科研究所の中の人
uau　　Uoti Urpala、mplayer2 project leader

avs2pipemod その6

2011-05-10T13:08:00.005+09:00

…更新。

x264のchangelogを眺めていたらr1939でbluray-compat+fake-interlacedのときはpic-structが要らなくなったと書いてあったので、こっちも削っておくかとコードを見直してみたら…なんか色々、avs2pipe0.0.3の時点で間違ってるようです。

とりあえずNTSC/PALのSDでDARが4：3なソースの場合の対応のために、オプションをまた変更。
これまでのx264bd=tffをx264bdtにしてしまい、=4:3を付けた場合はDAR4:3のソースとみなすことにしました。
具体的には`avs2pipemod.exe -x264bdt=4:3 720x480x60i.avs`といった感じです。
それとBD規格ではやはりBFFはないようなので、x264bdbは作りませんでした。
BFFなソースは事前にDoubleWeave().SelectOdd()でもして、フィールドオーダーをTFFにしてください。

バイナリ
追記：バグあったわ…自分の書いたところでorz
最新は20110510.zipです。
avs2pipemod-20110510.zip

ソース
http://github.com/chikuzen/avs2pipemod

avs2pipemod その5

2011-05-07T20:47:00.002+09:00

しつこく更新。
一つ一つの関数が長すぎるのをなんとかしようと、分割したり色々していたら、いつの間にか一部の機能が変わってしまった。

　*'packedraw'を廃止して'rawvideo'に変更
　これまでは映像のraw出力はpacked formatのみでしたが、planar formatでも出来るようにしました。
　planar YUVの出力部はYUV4MPEG2と共通なので、planeの並び方はY->U->Vに限定されています。
　この並び方はffmpeg/libavのpix_fmt(YUV444pとかYUV422pとか)と同じなので、使用上の都合はYV16やYV24(並び方がY->V->U)より良いのですが、いくら探してもFourCCみたいなものが見つかりません。
　x264のfullhelpでは、これをi422とかi444と書いていますが…そんな呼び方、他所では聞いたことがない。
　どうもkemuri_-9氏が、i420を真似て自分で作ってしまったのではないだろうか…。

追記：Y8の処理でバグがあったので修正、バイナリを更新しました。

バイナリ
更新しました

ソース
http://github.com/chikuzen/avs2pipemod

avs2pipemod その４

2011-05-04T23:41:00.007+09:00

更新。いろいろオプションを増やしすぎた感じがしたのでgetoptを使うことにしました。
その他、いろいろ書きなおしたりヘッダーファイルを追加したりあれこれ…かえってカオスな感じになったような…

使い方は以下のようになります。


avs2pipemod -audio=24bit input.avs | neroAacEnc -q 0.3 -if - -of output.mp4
avs2pipemod -y4mt=40:33 input.avs | x264 - --demuxer y4m -o output.mkv

aud16やrawaud24とかはなくなり、かわりにオプションの後ろに'=16bit'とかを付けるようにしました。
付けない場合は、音声出力なら変更なし、y4m出力ならアスペクト比の指定なし(0:0)として扱われます。

あと、x264bdの出力をx264のr1936以降(--bluray-compatあり)用に変更（正直、自分にはほとんど興味のない分野だけど…この機能、使ってる人いるのかな？）。
こちらもこれまでのように、avsのフィールドベース/フレームベースによる判定ではなく、'=tff(bff)'で、インタレの判定を行います（ところでBDでbottom firstってありえるのかいな？）。

バイナリはこちら
更新したので削除

ソースはこちら
https://github.com/chikuzen/avs2pipemod

avs2pipemod その３

2011-05-01T15:39:00.005+09:00

更新しました。

　*YUV4MPEG2出力時の色空間変換を改良
　これまでの色空間変換はインタレやBT.709は特に考慮されていませんでしたが、今回の更新で対応しました。
　高さが720以上のRGBはRec.709でYUVに、またy4mt/y4mbの際に他の色空間からYUV420で出力する場合はConvertToYV12(interlaced=True)の処理が入ります(これまではすべてinterlaced=falseで処理されています)。

追記：
さらに更新。

　*新オプション'rawaudio''rawaud16''rawaud24'を追加
　このツールの音声出力はwav extensible formatという、RIFF-WAVE(いわゆる.wav)の拡張形式を使います。
　ただのwavよりもいいところも色々あるのですが、あまり一般的ではないため、いくつかのオーディオエンコーダー(例：LAME、oggenc2等)はこれを入力として受け取ることが出来ません。
　今回の新規オプションはこの対策のため、ヘッダーの全くない生のPCMとして出力します。

バイナリ
更新したので削除

ソース
https://github.com/chikuzen/avs2pipemod

avs2pipemod その２

2011-04-28T11:44:00.003+09:00

バグ修正、および新機能の追加等を行いました。

*'packedraw'オプションを追加

入力がpacked format(RGB32/24、YUY2、Y8)のときのみ使える限定機能。
RAW(非圧縮)データをそのままなんのヘッダーも付けずに標準出力します。
RGBをYUVに変換せずに出力したい、及びavisynth2.5でYUY2をYV12に変換せずに出力したい場合に使います。
YV24/YV16/YV411/YV12はY4Mで出力できるので、あえてRAWで出力する必要はないかと思い対象から除外。
実際にこれを使うとすれば、*nix+wineでavisynthを使っていて、これらのデータをネイティブなFFmpeg/MEncoderに入力したい場合くらいでしょうかね。

しかし我ながら、なんとも間の抜けた響きのオプション名ですな…orz

バイナリはこちら
更新したので削除

ソースはこちらへ
https://github.com/chikuzen/avs2pipemod

avs2pipemod

2011-04-26T00:33:00.013+09:00

ここ最近、avs2pipeのコードをずっといじっておりました。

最初はavisynth2.6用にYUV444やYUV422でYUV4MPEG2出力出来る機能を追加するだけのつもりだったのが、ついでに自分のほしい機能を幾つか追加したり既存の機能を自分向けに改造したり色々試していたらこうなった。

オリジナルとの違い

*'audio'オプションの他に'aud16''aud24'というオプションを作った

aud16はConvertAudioTo16bit、aud24はConvertAudioTo24bitを入力音声に追加して出力を行う機能。
avs2pipeの売りの一つはvfwインターフェイスを通さないから音声の16bit整数自動変換を避けられることなんだけど、世の中にはあえて32bit浮動小数点を16bit/24bit整数で出力したいということもあるだろうと思い追加した。
スクリプトにConvertAudioTo16bit/24bitを書けばいいだけなのだが、こっちのほうが多分楽である。

*'video'オプションを'y4mp''y4mt''y4mb'の3種類に変更

avs2pipeの'video'オプションは、avsがフィールドベースだったらインタレと判定し、さらにAssumeBFFしていればBFF、それ以外はTFFとして扱うようになっている。
しかし、この判定を利用するためにわざわざスクリプトにAssumeFieldBased().AssumeBFF()とか書くのはどうも煩雑に感じる。
ということで、あえてオプションでフィールドオーダーを指定することにした。
y4mpを指定すれば問答無用でプログレ、y4mtならTFFなインタレ、y4mbならBFFなインタレとしてY4M出力を行う。

*入力がフィールドベースだったときのフレームベースへの変換

上記のvideoオプションの変更を行ったことで、あえてフィールドベースでの入力を許容する意味が無くなってしまったので、強制的にフレームベースにしてしまうことにした。
もしY4M出力時に入力がフィールドベースだったら、AssumeFrameBased()かWeave()を行う（手動選択）。

*'info'の出力情報を変更

pixel_type(色空間)を16進数表示って手抜きすぎるだろってことで、ちゃんとRGB32とかYUY2とか表示するようにした。

*経過時間の表示

音声/Y4M出力終了時に総経過時間を表示するようにした（途中経過はなし)。
bashなりを使っていればtimeコマンドがあるので本当は不要だが、まあ、'time　'と5文字打つ手間が省けるということで。

*'benchmark'オプションを追加

いままで筆者はフィルタのスピードを計測するのにavs2aviかx264cliをNULL出力で使っていたが不満な点があった。
avs2aviはvfwインターフェースを通してavsを読むため、読み込み時に余分な処理が入る。
x264はCインターフェースを使うからavs2aviよりも速いが、たとえpreset ultrafastでも必ずエンコード処理が入る。
そしてどちらもNULL出力とはいえ、書き込み処理も一応入る。
そういう不満を解消すべく作ったのがこのbenchmarkモードである。
処理内容はひたすらavs_get_frame()とavs_release_frame()だけを繰り返し、50フレームごとに途中経過を報告する。
時間計算/表示以外の余分な処理は一切入らないから、理論上はこれが最速だろうし、実際x264よりもわずかながら速い(環境によっては遅いかも知れないけど)。
つーかx264速すぎだろ…こっちも時間計算はdoubleではなくint64で行うべきなのかなぁ…
ちなみにCインターフェースなので、SetMTModeとか使ってる人はDistributor()が当然要ります。

*Y4M出力時のstdoutのバッファを拡張

これはもともとオリジナルの作者のdoobry氏がすでに実装しているようなのだが、現時点ではそれをリリースしていない。
参考：http://forum.doom9.org/showpost.php?p=1490576&postcount=59
つーか、何をもったいつけてるのか知らんが一向にリリースしないので、待ちきれずに自分で実装してしまった。
なるほど、彼の言うとおり随分速くなりますね。

ここまでやったところで、一旦公開してみることにします。

追記:試しに時間計算でx264を真似てみたら、本当にわずかながら速くなりました。
追記:ひどいバグを見つけたので公開停止。
追記:更新しました。

ソースコードが欲しい人はこちらへ。
https://github.com/chikuzen/avs2pipemod

とりあえずひと月ほど待っても彼が新バージョンをリリースしないようなら、Doom9でも発表してしまおうかな。

AviSynth2.6.0α on *nix

2011-03-05T04:23:00.001+09:00

以前やったベンチマークがWindowsだけであることに、某フランス人が不満そうだったので。


#benchmark.avs
ImageSource("Z:\home\chikuzen\Pictures\1920x1080.bmp", 0, 999)
BlackmanResize(720, 480)  
Spline64Resize(1920, 1080)  
GaussResize(512, 384)  
 
$ for i in {1..3}; do wine avs2avi benchmark.avs -c null -o n; done
 
            2.5.8                 2.6.0α(JEEB's)
1st   00:03:40.414 (4.54fps)   00:01:56.483 (8.58fps)
2nd   00:03:32.149 (4.71fps)   00:01:56.722 (8.57fps)
3rd   00:03:31.894 (4.72fps)   00:01:56.471 (8.59fps)
 
Ubuntu 10.10 / wine 1.3.14
Core2Duo T7300@2GHz / 2GB RAM

やっぱり速いよ、2.6.0。

How to compile ffmpeg/x264 for Windows --English(or Engrish) version--

2011-02-22T12:41:00.040+09:00

Download this script

ふわふわさん part2

2011-02-01T21:39:00.001+09:00

(Chikuzen) TheFluff氏が叫んでますな
(Chikuzen) 「空の境界」ってもともとSD制作だったの？
(JEEB) いや
(JEEB) ハイビジョン制作っす
(JEEB) 画像を見れば一部だけがなぜかワープシャープかかってる
(Chikuzen) なぜにwarpsharp...
(JEEB) その答えを見つけるためとりあえずマスタリングした会社の連絡先を見つけないとなぁ・・・
(Chikuzen) そこだけmasterなくしちゃったから、DVDソース使ったとか

カワイソス

中間出力のマルチプロセス化

2011-01-31T00:08:00.001+09:00

先日、JEEB氏がAviSynth2.6.0αの非公式ビルドを始めた。

(JEEB) そういや、うちのAvs2.6ビルドってChikuzen氏がテストした奴と性能がどんな感じ？
(Chikuzen) 若干スピードが上がってるみたいよ
(Chikuzen) ちょっとベンチマーク回してみるか

　　　   official 2.6.0α2       JEEB's 2.6.0(20110125)
1st   00:01:11.003(14.08fps)   00:01:07.254(14.87fps)
2nd   00:01:11.010(14.08fps)   00:01:07.003(14.92fps)
3rd   00:01:10.753(14.13fps)   00:01:07.003(14.92fps)　（スクリプト等は前回と同じ)

(JEEB) interesting

たしかに興味深い。
どうやら最適化はα2配布後にさらに進んでいたようである。

さて、前回、自分はマルチスレッドによる高速化ではなく、マルチプロセスによる高速化を選んだことを書いた。
ここで問題となるのが、同時にエンコードするための複数のソースがない場合である。
そもそも自分は放送ソースの保存用エンコなんてまったくしない。そんなことには興味がない。
いろいろなフィルタやエンコーダーを試して遊ぶのが好きなのである。
当然、エンコードするべきソースは大抵1本しかなく、3本同時にエンコードなんていままでに数えるほどしかやったことがない。

では、どうすればいいのか？
エンコード対象がひとつしかないのであれば、ひとつを複数に分割してやればいいだけだ。
3本同時にエンコードできる余裕があるなら、1本を3分割してそれぞれ中間出力し、ふたたびくっつけてやればよい。
それが簡単にできるのがAviSynthである。
中間出力用のファイルサイズを気にするような時代でもないしね。

てことで、自動で分割->中間出力->結合->エンコードを行うAvsPマクロを書いた。

#multiprocess intermediate file generator.py
#dividing source script into X -> generate intermediate files at same time -> final encode
#requiaments : VirtualDub.exe, vcf file, ffmpeg or x264 (optional)
import sys
import os.path
import subprocess

vdub = r'C:\VirtualDub-1.9.11\VirtualDub.exe'
vcf  = r'C:\VirtualDub-1.9.11\fastrecomp_uly0_noaudio.vcf'

entries = avsp.GetTextEntry(['Number of dividing', 'SetMemoryMax(?)'], ['3', '1024'])
dnum, mmax = [int(i) for i in entries]

imf_outdir = avsp.GetDirectory('Select a directory to output intermediate files.')

encbin  = avsp.GetFilename('Set Path to Encoder(ffmpeg or x264)')
#encbin = r'G:\Enctools\ffmpeg.exe'
#encbin = r'G:\Enctools\x264_x64.exe'
encout  = avsp.GetSaveFilename('Set final output file name')
encopts = avsp.GetTextEntry('Input commandline options').split(' ')

source = avsp.SaveScript()
frames = avsp.GetVideoFramecount()

if dnum > 1 and mmax > 0 and imf_outdir and frames and os.path.isfile(vdub) and os.path.isfile(vcf):
    start = 0
    vdubprocess = []
    catfilename = os.path.splitext(source)[0] + '_imf.avs'
    catfile = open(catfilename, 'w')

    for i in range(dnum):
        end = frames / dnum * (i + 1)
        if i < dnum - 1:
            trimline = 'trim(%i, %i)' % (start, end)
        else:
            trimline = 'trim(%i, 0)' % start
        lines = 'SetMemoryMax(%i)\nImport("%s")\n%s\n' % (mmax, source, trimline)
        start = end + 1

        imf_avsname = os.path.join(imf_outdir, os.path.basename(source)).rstrip('avs') + 'imf_%02i.avs' % i
        file = open(imf_avsname, 'w')
        file.write(lines)
        file.close()

        imf_aviname = os.path.splitext(imf_avsname)[0] + '.avi'
        vdubargs = [vdub, '/s', vcf, '/p', imf_avsname, imf_aviname, '/r', '/c', '/x']
        p = subprocess.Popen(vdubargs)
        vdubprocess.append(p)

        if i < dnum - 1:
            catfile.write('AVISource("%s") + \\\n' % imf_aviname)
        else:
            catfile.write('AVISource("%s")\n' % imf_aviname)

    catfile.close()

    if encbin and encout:
        for p in vdubprocess:
            p.wait()

        if os.path.basename(encbin).count('ffmpeg'):
            encargs = [encbin, '-i', catfilename] + encopts + ['-y', encout]
        elif os.path.basename(encbin).count('x264'):
            encargs = [encbin, catfilename, '-o', encout] + encopts
        else:
            sys.exit()

        subprocess.Popen(encargs)

AviSynth2.6.0α

2011-01-18T21:43:00.004+09:00

さまざまな試行と思索（ってほどのものでもないが）の結果、現在の自分はAviSynth2.6.0α(32bit)を使っている。

Q.なぜ64bitAviSynthじゃないの？
A.いろいろ不具合が多い上に開発が止まっているから。
　開発が順調なら人柱覚悟で使ってバグレポートもするが、現状停止中でforkする人もいないでは使う甲斐がない。
　まあ、気長に待つしかないかなぁ。

Q.なんでMT使わないの？
A.SetMTMode()はとにかく不安定すぎる。
　しかも同じスクリプトでもクラッシュしたりしなかったりと運用で回避を図ろうにも傾向がつかめない。
　たとえ速くても、完走出来ないマラソンランナーは正選手にはなれないのである。
　MT()のほうはSetMTMode()ほどひどくはないが…。

Q.なんでstableな2.5.8ではなく、2.6.0αなの？
A.安定していて速いから。

そう、2.6.0αはまだアルファなのに安定している。
どれくらい安定しているかといえば、既知の問題がα2公開後1年以上経つのにこの程度しかないくらい堅い。
しかも2.5.8に存在するバグもいくつか取れている。(これではどちらがstableなのかと小一時間…)

そして速い。2.5.8->2.6.0の最適化の進み具合はすさまじい。例えば次のようなベンチマークをしてみるとよくわかる。


#benchmark.avs
ImageReader("test_1280x720.bmp", 0, 999)
BlackmanResize(720, 480)
Spline64Resize(1920, 1080)
GaussResize(512, 384)

$ for i in {1..3}; do avs2avi benchmark.avs -c null -o n; done

これを2.5.8と2.6.0αでやってみると結果は


              2.5.8                   2.6.0α
1st   00:02:26.256(6.84fps)    00:01:10.753(14.13fps)
2nd   00:02:26.256(6.84fps)    00:01:10.764(14.13fps)
3rd   00:02:26.257(6.84fps)    00:01:10.753(14.13fps)　　(CPU使用率はすべて30%弱）

特に重めなresizerをRGB32でかけた結果がこれである。
たまに高速化のためと称してMT()使って縦横別々にリサイズとかしてる人を見かけるけど、そんなもの手間をかけて無駄にCPU使用率を上げているだけですな。

2.6.0αはMT対応はしていないが、それ自体は高速である。
問題はプラグインのほうで、これがボトルネックになるわけだが…でもその場合はCPU自体はそれほど使ってないよね？
CPUに余裕があるなら同時に複数本走らせればいいだけだ。
この場合、1本あたりのスピードは低下してしまうが、3本同時にやれば終了するまでにかかる時間は1本ずつ3本エンコするのと比べてだいたい半分程度にはなるだろう。
1本あたり最大2GBのメモリを使うことになるが（pipeを使えばもう少し増える）、自分の環境は64bitOSで8GBつんでいるので、まだ余裕はある。
・スピードが結果的に倍程度まであがり
・CPUを無駄なく使い
・安定した出力を得られ
・互換性も特に気にする必要がない

現状ではやはりこれが一番いいんじゃないかなぁ。

RawSource.dll

2011-01-11T19:40:00.007+09:00

AviSynthのRawSourceがffmpegやy4m.auoで出力したY4Mファイルを読めないので何とかしたいというお話。

YUV4MPEG2(Y4M)は非圧縮なYUVデータに動画の解像度やフレームレートといったものをヘッダーとして追加したシンプルなファイル形式である。
もともとはMJPEGToolsなるもので使われていたものらしいが、なかなか取り扱いが便利なので、今日ではffmpeg,MEncoder,x264といろいろなエンコーダーがY4M入力に対応している。
たとえばx264はただのYUVもY4Mも入力に使用出来るが、ただのYUVだと


$ x264 input.yuv --input-csp i420 --input-res 720x480 --fps 24000/1001 --sar 40:33 \
[other options] -o output.h264

てな具合にオプションを指定しなければならない。
一方、Y4Mファイルであれば、解像度等はヘッダーに書かれているので

$ x264 input.y4m [other options] -o output.h264

と、手間が省ける。
うん、便利だね。

さて、RawSource.dllは非圧縮ファイルを扱うためのAviSynthプラグインである。
このRawSource、Y4Mも読めることになってはいるのだが、いかんせん書かれたのが2006年と古いせいか、想定されているヘッダーが旧式である。ffmpegやAviUtlのYUV4MPEG2出力プラグインで出力される新しい形式（Cタグで色空間指定付）のものだと"YUV4MPEG2 header error"となって手が出ない。
「だれか何とかしてくれないかなー」と最初にこのことに気づいてから、かれこれ一年半ほど待ってみたが、そのような奇特な人はついに現れなかった（まあ黙って待っててもそうそう都合のいいことが起こるわけもないわな）。
そこで一念発起して自分でやってみることにしたのである。

まずC言語入門講座とかその手のサイトを2つほど回って、Hello Worldとかfizzbuzzとかを書くこと5日間。
そろそろ出来るかなと、ためしにやってみたら本当に出来た。ちなみに一番難しかったのはVisualStudioの操作方法だった。なんでAviSynthプラグインはmingwでビルドできないんだよチクショウめ。

とりあえず出来上がったものはDoom9に投稿したので、あとはツッコミ待ちである。

TAEC.py

2010-12-19T12:39:00.018+09:00

またまた某所にて

(silverfilain) どうせならMaxMBPSとMaxFSも考慮して幅・高さ・fpsから
最適なレベルを表示するのも作って欲しいぉ
(Chikuzen) じゃあ、ちょっと調べてみる

てな感じで、また書くことになった。

#!/bin/env python
# coding: utf-8
#****************************************************************************
#  TAEC(Tiny Avc Encode Consultant).py 
#                                                     written by Chikezun
#  Reference literature:
#    Rec. ITU-T H.264 (03/2010) – Prepublished version
#    インプレス標準教科書シリーズ改訂版 H.264/AVC教科書
#           著者：（監修）大久保 榮／（編者）角野 眞也、菊池 義浩、鈴木 輝彦
#    http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
#    猫科研究所( http://www.up-cat.net/ )
#        　x264(vbv-maxrate,vbv-bufsize,profile,level),H.264(Profile/Level)
#
#****************************************************************************

__version__ = '0.3.3'
import sys
import getopt
import math

def set_default():
    width   = int(1280) 
    height  = int(720)
    fpsnum  = int(30000)
    fpsden  = int(1001)
    profile = 'high'
    mode    = 'progressive'
    return [[width, height], [fpsnum, fpsden], profile, mode]

def usage():
    param = set_default()
    print "\nUsage: taec.py [options]\n"
    print "  -r, --resolution <string> :set 'width x height' ('%ix%i')" % tuple(param[0])
    print "  -f, --fps <string>        :set 'fpsnum / fpsden' ('%i/%i')" % tuple(param[1])
    print "  -p, --profile <string>    :set 'profile' ('%s')" % param[2]
    print "  -i, --interlaced          :specify interlaced mode (not specified)"
    print "  -v, --version             :display version"
    print "  -h, --help                :display this help and exit\n"

def check_res_and_fps(arg, r_or_f):
    try:
        param = [abs(int(i)) for i in arg.split('x' * r_or_f or '/')]
        if len(param) != 2:
            raise SyntaxError
    except:
        print "\nERROR : invalid %s setting." % ('resolution' * r_or_f or 'fps')
        usage()
        sys.exit()
    else:
        return param

def check_profile(profile, ipflag):
    if profile in ('baseline', 'main', 'high'):
        if profile != 'baseline' or ipflag != 'interlaced':
            return 1
        else:
            print "\nERROR : baseline cannot accept interlaced."
    print "\nERROR : invalid profile setting."
    usage()
    sys.exit()

def calc_bs(resolution, fps, ipflag):
    fstmp = [int(math.ceil(i / 16.0)) for i in resolution]
    fs = dbp = fstmp[0] * fstmp[1]
    mbps  = fs * fps[0] // fps[1]
    if ipflag == 'interlaced':
        dbp += fstmp[0] * (fstmp[1] % 2)
    return [mbps, fs, dbp]

def calc_lv(bs, ipflag, spec):
    for i in spec:
        if bs[0] <= i[1] and bs[1] <= i[2] and bs[2] <= i[3]:
            return i[0]
    if ipflag == 'interlaced':
        print "ERROR : interlaced encoding cannot be done to this video."
    print "ERROR : there is no suitable setting."
    usage()
    sys.exit()

def calc_result(profile, bitstream, line):
    vbv = [int(i * ((profile == 'high') * 1.25 or 1)) for i in line[4]]
    ref = [16 * (i > 16) or i for i in [line[3] // bitstream[2]]]
    return tuple([line[0]] + vbv + ref)

def display_result(level, profile, bitstream, spec):
    index = [i[0] for i in spec]
    try:
        for i in xrange(len(index)):
            if index[i] == level:
                line = spec[i]
                print "%5s%12i%13i%8i" % calc_result(profile, bitstream, line)
                level = index[i + 1]
    except:
        return 0

def get_spec():
#H.264/AVC spec [(level, MaxMBPs, MaxFS, MaxDbpMBs, [MaxBR, MaxCPB], ipflag]}
    return [('1.0',   1485,    99,    396, [    64,    175], 'p'),
            ('1b ',   1485,    99,    396, [   128,    350], 'p'),
            ('1.1',   3000,   396,    900, [   192,    500], 'p'),
            ('1.2',   6000,   396,   2376, [   384,   1000], 'p'),
            ('1.3',  11880,   396,   2376, [   768,   2000], 'p'),
            ('2.0',  11880,   396,   2376, [  2000,   2000], 'p'),
            ('2.1',  19800,   792,   4752, [  4000,   4000], 'i'),
            ('2.2',  20250,  1620,   8100, [  4000,   4000], 'i'),
            ('3.0',  40500,  1620,   8100, [ 10000,  10000], 'i'),
            ('3.1', 108000,  3600,  18000, [ 14000,  14000], 'i'),
            ('3.2', 216000,  5120,  20480, [ 20000,  20000], 'i'),
            ('4.0', 245760,  8192,  32768, [ 20000,  25000], 'i'),
            ('4.1', 245760,  8192,  32768, [ 50000,  62500], 'i'),
            ('4.2', 491520,  8192,  34816, [ 50000,  62500], 'p'),
            ('5.0', 589824, 22080, 110400, [135000, 135000], 'p'),
            ('5.1', 983040, 36864, 184320, [240000, 240000], 'p')]

def set_param(opts, param):
    for opt, arg in opts:
        if opt in ("-r", "--resolution"):
            param[0] = check_res_and_fps(arg, 1)
        elif opt in ("-f", "--fps"):
            param[1] = check_res_and_fps(arg, 0)
        elif opt in ("-p", "--profile"):
            param[2] = arg
        elif opt in ("-i", "--interlaced"):
            param[3] = 'interlaced'
        elif opt in ("-h", "--help"):
            usage()
            sys.exit()
        elif opt in ("-v", "--version"):
            print "tiny avc encode consultant %s" % __version__
            sys.exit()
    return param

if __name__ == '__main__':
    try:
        opts, args = getopt.getopt(sys.argv[1:], "r:f:p:ihv",
            ["resolution=","fps=","profile=","interlaced","help","version"])
    except:
        usage()
        sys.exit()

    param = set_default()

    if len(opts) > 0:
        param = set_param(opts, param)
    else:
        usage()

    check_profile(param[2], param[3])

    print
    print " resolution       : %i x %i" % tuple(param[0])
    print " fps              : %i / %i" % tuple(param[1])
    print " profile          : %s"      % param[2]
    print " encoding mode    : %s\n"    % param[3]

    bitstream = calc_bs(param[0], param[1], param[3])
    print " MBPS ... %6iMB/s" % bitstream[0]
    print " FS   ... %6iMBs"  % bitstream[1]
    print " DPB  ... %6iMBs\n"  % bitstream[2]

    if param[3] == 'interlaced':
        avcspec = [i for i in get_spec() if i[5] == 'i']
    else:
        avcspec = get_spec()

    minlv = calc_lv(bitstream, param[3], avcspec)

    print " suitable settings are ...\n"
    print " level  vbv-maxrate  vbv-bufsize  max-ref"
    print " ----------------------------------------"
    display_result(minlv, param[2], bitstream, avcspec)

#changelog
# 2010/12/19     0.1.0　公開
# 2010/12/19     0.1.1　いろいろ計算がおかしかったのを修正
# 2010/12/20     0.2.0　lambda式面白い
# 2010/12/21     0.3.0　リスト内包とgetoptの存在を知る
#    〃          0.3.1  getoptの長文形式における要引数要素に=を付けていなかったのを修正
# 2010/01/02     0.3.2  処理が重複する関数(check_resolution, check_fps)をひとつにまとめた
# 2011/03/17     0.3.3  cosmetics

# 2011/10/12     0.3.4  Fix 10L

なにせ「コンサルタント」ですから、まず役にたたないと思われます。

avc_refcalc.py

2010-12-18T18:42:00.010+09:00

某所にて

(boiled_sugar) level計算機とかないのかなー
(Chikuzen) どんな計算したいの？
(boiled_sugar) 解像度とlevelで最大ref計算
(Chikuzen) この前D_Sがそんなの書いてx264に組み込んでなかったっけ？
(boiled_sugar) 独立したプログラムが欲しい

というわけで、書いてみた。

#!/bin/env python
# coding: utf-8

#****************************************************************************
#  avc_refcalc.py 0.20
#                                   written by Chikezun
#  Reference literature:
#    インプレス標準教科書シリーズ改訂版 H.264/AVC教科書
#           著者：（監修）大久保 榮／（編者）角野 眞也、菊池 義浩、鈴木 輝彦
#    http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
#    猫科研究所(http://www.up-cat.net/FrontPage.html)
#        　x264(vbv-maxrate,vbv-bufsize,profile,level),H.264(Profile/Level)
#
#****************************************************************************

import sys
import math

def usage():
    print "Usage: avc_refcalc.py [options]\n"
    print "  -r, --resolution <string> :set 'width x height' ('1280x720')"
    print "  -l, --level <string>      :set 'level' ('4.1')"
    print "  -p, --profile <string>    :set 'profile' ('high')"
    print "  -i, --interlaced          :specify interlaced mode (not specified)"
    print "  -h, --help                :display this help and exit\n"

def check_prof(pr, ip):
    for i in ['baseline', 'main', 'high']:
        if i == pr:
            if i != 'baseline' or ip != 'interlaced':
                return i
            else:
                print "ERROR : baseline cannot accept interlaced."
    print "ERROR : invalid profile setting.\n"
    usage()
    sys.exit()

def check_level(lv, ip, dic):
    lvl = lv.replace('0','').replace('.','')
    if dic.has_key(lvl):
        if ip[0] != 'i' or dic.get(lvl)[0] == 'i':
            return lvl
        else:
            print "ERROR : specified level cannot accept interlaced."
    print "ERROR : invalid level value.\n"
    usage()
    sys.exit()

def calc_mbs(w, h, ip):
    mbh = int(math.ceil(float(w) / 16))
    mbv = int(math.ceil(float(h) / 16))
    if mbv % 2 == 1 and ip == 'interlaced':
        mbv += 1
    mbs = mbh * mbv
    if mbs > 0:
        return mbs
    else:
        print "ERROR : invalid resolution setting.\n"
        usage()
        sys.exit()

def calc_vbv(lv, pr, dic):
    vbvmax = dic.get(lv)[1]
    vbvbuf = dic.get(lv)[2]
    if pr == 'high':
        return [int(vbvmax * 1.25), int(vbvbuf * 1.25)]
    else:
        return [vbvmax, vbvbuf]

def calc_maxref(lv, mbs, dic):
    ref = int(dic.get(lv)[3] / mbs)
    if ref > 16:
        ref = 16
    if ref > 0:
        return ref
    else:
        print "ERROR : resolution is too large to level.\n"
        usage()
        sys.exit()

options = sys.argv
len_opt = len(options)

#set default values
width  = 1280
height = 720
level  = '4.1'
prof   = 'high'
mode   = 'progressive'
help   = 0

#H.264/AVC level dictionary {level: [interlaced flag, MaxBR, MaxCPB, MaxDbpMbs]}
avcdic = {'1' :['p',     64,    175,    396], '1b':['p',    128,    350,    396],
          '11':['p',    192,    500,    900], '12':['p',    384,   1000,   2376],
          '13':['p',    768,   2000,   2376], '2' :['p',   2000,   2000,   2376],
          '21':['i',   4000,   4000,   4752], '22':['i',   4000,   4000,   8100],
          '3' :['i',  10000,  10000,   8100], '31':['i',  14000,  14000,  18000],
          '32':['i',  20000,  20000,  20480], '4' :['i',  20000,  25000,  32768],
          '41':['i',  50000,  62500,  32768], '42':['p',  50000,  62500,  34816],
          '5' :['p', 135000, 135000, 110400], '51':['p', 240000, 240000, 184320]}

if len_opt > 1:
    for i in range(len_opt):
        try:
            if options[i] == '-r' or options[i] == '--resolution':
                res    = options[i + 1].split('x')
                width  = int(res[0])
                height = int(res[1])
            if options[i] == '-l' or options[i] == '--level':
                level = options[i + 1]
            if options[i] == '-p' or options[i] == '--profile':
                prof = options[i + 1]
            if options[i] == '-i' or options[i] == '--interlaced':
                mode = 'interlaced'
            if options[i] == '-h' or options[i] == '--help':
                help = 1

        except:
            print "ERROR : invalid arguments\n"
            help = 1

        else:
            pass

    if help == 1:
        usage()
        sys.exit()

else:
    usage()

profile = check_prof(prof, mode)
lv_tmp  = check_level(level, mode, avcdic)
mbs     = calc_mbs(width, height, mode)
vbv     = calc_vbv(lv_tmp, profile, avcdic)
maxref  = calc_maxref(lv_tmp, mbs, avcdic)

print " resolution       : %i x %i" % (width, height)
print " level            : %s" % level
print " profile          : %s" % profile
print " mode             : %s" % mode
print " vbv-maxrate(vlc) : %i" % vbv[0]
print " vbv-bufsize(vlc) : %i" % vbv[1]
print " max ref number   : %i" % maxref

mod16

2010-11-26T16:52:00.004+09:00

およそ動画系の話題を扱うforumであればたまに出てくる話題に"mod16"なるものがある。
そう、「動画の解像度は縦横ともに16の倍数にすべきである」ってやつですな。
これは正しいといえば正しいが、正しくないといえば正しくない。
とりあえず事実だけを言うのであれば「(mpeg系のエンコーダーは)解像度が16の倍数でないと圧縮出来ない」になるだろう。

mpeg系エンコーダー(そしてこれらの影響を受けているH.263とかVPxとか)は、まず映像を左上を原点にとって16x16のMB(マクロブロック)の集まりに分割してから動き検索やらDCT(離散コサイン変換)やらを行う。
規格によっては16x16のMBをさらに4x4に分割したり8x8とか8x16とかにも分割したりするが(SMB:サブマクロブロック)、とりあえず一回16x16で分割しないことには何も始まらない。
さあ、16x16の集まりに分割するのだ。

でも、たとえば642x484なんていう解像度を圧縮する場合はどうすればいいのよ？
右端の2x16とか下端の16x4とか一番右下の2x4は処理できないじゃん。
困るよ、おい。

これを何とかするため、16の倍数になっていないものの場合はエンコーダーの内部でpadding(パディング)なるものが行われるようになっている。
paddingを英和辞典で引けば「詰め物」とかそういった感じの意味で載っているだろう。
つまり、本来存在しない映像をを付け足して、16の倍数になるようにするわけだ。642x484であれば、映像の右端に幅14ピクセル、下端に幅12ピクセルのダミーをくっつけて656ｘ496にしてしまう。

よーし、これで圧縮にとりかかれますな。

ところでこのpaddingされる映像ってどんなものなのか、知ってます？
黒ベタ？　灰色ベタ？
正解は右端および下端の縁の色です。
つまり、こんな感じ。

なんでこんな絵の具が垂れたみたいな感じに？
それは、このようにpaddingを行うのが一番、本来の映像に影響を与えずに圧縮できるから。
単色ベタ塗りは色々とまずいことがあるのですよ。色々ね。
もし自分でこのようなpaddingをしてみたければ、AviUtlなら「"縁塗りつぶし"を"縁の色で塗る"にチェックを入れて値をマイナスに設定」、AviSynthなら「"AddBorders"と"BorderControl"または"FillMargins"を併用」で可能です。

#padding.avs
AVISource("642x484.avi")
AddBorders(0,0,14,12)

#BorderControlの場合
LoadPlugin("BorderControl.dll")
BorderControl(XRS=14,YBS=12)

#FillMarginsの場合
LoadPlugin("FillMargins.dll")
FillMargins(0,0,14,12)

さて、これで圧縮は出来たけど、いざ動画を再生するときに、こんな変な部分まで表示されたら、それはそれで嫌ではないかな？
本来存在しないはずのものまで見えるのってうざいと思うよっつーかうざいんだよボケ。心霊写真じゃあるまいし。
そういう文句が出ることは分かりきっているので、paddingされたデータはまともなデコーダーならデコード時にはcropしてしまうようになっています。つまりさっきくっつけた右端14ピクセルと下端12ピクセルは表示されず、もとの642ｘ484として表示される。
やれやれ、これにて一件落着。

でもね。
影響の少ないダミーによる水増しとはいえ、映像は642ｘ484ではなく656ｘ496の状態で圧縮されてるわけですよ。
解像度が大きければ、その分ファイルサイズも当然大きくなります。
もし640x480だったならばpaddingも必要なく、ファイルサイズも小さくなるだろうに…。
表示されない屑データのために膨れるなんて、そんな贅肉見苦しいんだよ、メタボだよ、ああむかつくこんちくしょう、うーんと、えーっと、そもそも水平2ピクセル、垂直4ピクセルくらいなら、削っちゃっても問題なくね？フフフそうだよそれくらい削っても気にならないだろ普通は、っつーかむしろ気にするやつのほうがおかしいだろ頭悪いだろキ○○イだろフヒヒヒヒええい削ってしまえバカヤローウギャー…orz

というわけで、やたら圧縮率にこだわる人であれば16の倍数になるようにするでしょう。
これが「動画の解像度は縦横ともに16の倍数にするべきである」の正体です。
まあ、もともと16の倍数になるように絵が作られていれば、こんな葛藤も起こらないわけで、それにこしたことはないんですが…はぁ(ため息)。

ちなみにたまに「mod16に出来ないならば、次善の策としてmod8(8の倍数)にするべきである」という人がいますが、これは迷信の類です。
mod16でなければpaddingは起こります。
そしてpaddingされるデータ量は、解像度を16で割った余りが16に近ければ近いほど小さくなります。
644x484、648x488、652x492という3種類の映像があったとすれば、ファイルサイズに対してpadding分のデータ量の占める割合は、644x484 > 648x488 > 652x492です。
つまりpaddingは少ないほどよいってことですね。
｢652ｘ492か。縦横12ずつ削るってのはさすがに嫌だよなあ…でも縦横4ずつくらいならそれほど嫌じゃないぞ。よし、648x488でmod8にしよう」
「それはつまり、大事な映像をわざわざ削った挙句に無駄になるデータを増やそうってことですかそーですか…手前の馬鹿さ加減にゃあ父ちゃん情けなくって涙出てくらぁ!!」(CV:東野英心)

あと、「mod16じゃないと、映像の端がゆがむ」という人もいますが、これもどうなんでしょうかね。
よっぽどひどいエンコーダーでもない限り、前述したような適切なpaddingを行っていれば、まず人間の目ではソースと並べて見比べてもなかなか視認出来るものではないはずなんですが。

Console2

2010-10-23T07:23:00.004+09:00

XhmikosR氏のファイル置き場を眺めていたら、/toolsにconsole_2.00_Beta_b146というのがあった。
なんだろうと思ってググって見たら、sourceforgeの本家のページが見つかったので、最新のzipをDLして、ヘルプを読んでみた。

Console is a Windows console window enhancement.
(consoleはWindowsのコンソールウィンドウの拡張用ツールです)
Console is simply a nice-looking front end for a shell of your choice (cmd.exe, 4NT, bash, etc.) Other command-line utilities can also be used as 'shells' by Console.
(単純に言ってしまえば、consoleはあなたの選んだshell(cmd.exeとかbashとか)のためのかっこいいフロントエンドであり、他のCLIユーティリティでもshell同様に使えます)

どうやら複数のCLI端末のウィンドウをタブで管理できたり、コピペ操作がテキストエディタぽくマウスで出来たり、フォントを変えたり、背景を個別に設定できたりするらしい。
端末がタブで扱えるのは大変うれしいので、早速使ってみることにした。

1. とりあえずzipを解凍し、適当なところに置く。
2. 次にヘルプ(.chm)を開き、軽く目を通す。
3. console.exeをダブルクリック。
4. ヘルプのSetting -> Language settingを読みながら、フォントの設定を行う。
5. その他設定を行う。

ためしに「console2　日本語」で検索したら、4のあたりの情報がいくつか出てきた。ヘルプを読むのは大事よね。

とりあえずタブの設定は3種類作ってみた。
ひとつはcmd.exe用
Shellとして、C:\Windows\System32\cmd.exeを登録し、Startup dirはC:\にした。
2つ目はmsysのbash用。
これは

@echo off
G:\msys\bin\sh.exe --login -i

だけ書いたbatを用意して、それをShellとして登録する。
3つ目はCygwinのbash用。
これもmsysと同様にbatを登録するだけ。

これでやることはとりあえず終了。
いざ使ってみると…これはイイ！
新しい端末をショートカットキー一発でタブで開けて、切り替えもラクラク。
特にノートPCとか狭い画面で複数の端末を操作する必要がある人にはお奨めですね。
あとは背景とかも設定できるのでいろいろいじってみるのもいいかも。

GPACが

2010-10-22T05:05:00.001+09:00

mingw / mingw-w64共に再びビルドできるようになったみたい。(SVN rev2183時点)

でも

./configure --cross-prefix=x86_64-w64-mingw32-

ってやったら

C   compiler: x86_64-w64-mingw32-gcc
C++ compiler: g++

と表示されるあたり、次に壊れるのも早そう…つーか、まだ直ってはいないといったほうがいいのかも。

AvsPのブックマーク位置をずらすマクロ

2010-10-19T19:14:00.005+09:00

AvsP(mod)でTrimSelectionを使ってCMカットすると、各パートの終端フレームにブックマークが打たれた状態になる。
これが結構曲者で、例えば動画にチャプターを打つ場合、チャプターポイントは各パートの先頭フレームに来るように打つものであるが、ブックマークが打たれている場所が各パートの終端だと、そのまま"Bookmarks to Chapter.py"を使うわけにいかない。
各パートの終端フレームの次のフレームは当然、次のパートの先頭フレームになるわけだが、この1フレームのずれを修正するために、いちいちブックマークを消して、1フレーム移動して、もう一度ブックマークを打ち直すのはめんどくさい、なんとかならんもんかいな？

と思ったので、これもマクロで何とかしてみようというのが今回のお話。
-----------------------------------------------------------------------------
既存のブックマークすべてを1フレーム右(未来方向)にずらすだけなら簡単である。

#Shift Bookmarks right+1.py
before=avsp.GetBookmarkList()
if len(before):
    after = [i + 1 for i in before]
    after.sort()
    avsp.SetBookmark(before) #ブックマークは二重に打つと消える。
    avsp.SetBookmark(after)

しかし、これをそのまま使うと、もし最終フレームにブックマークが打たれていた場合、そのブックマークは範囲外に飛び出して消えてしまう。
それに、すでにブックマークを1フレームずらし終えたのに、何らかの操作ミスでもう一回ずらしてしまったらどうしよう？マクロを使った場合、undoは効かないよ？
はたまた、例えばブックマークを打ち終え、チャプターを出力する段になったところでトリムのし残しを発見してしまった場合は？その部分が全部で10個打ったブックマークの2番目と3番目の間に30フレームあったりしたら、1番目と2番目は打ち直すとしても、3番目以降のためにこれを30回実行するの？
ずらすフレーム数を任意に指定できるようにしたとして、全部で10000フレームしかないクリップに対して、桁を間違えて100000なんて指定してしまったら？
などと不測の事態についていろいろ考えていたら、最後にはこうなっていた。

#Shift Bookmarks.py
def newBM(present, shift, last):
    if 0 <= present + shift <= last:
        return present + shift
    elif present + shift > last:
        return newBM(present, shift - last - 1, last)
    else:
        return newBM(present, shift + last + 1, last)

input = avsp.GetTextEntry('Input an integer value',default='1')
shift = int(input)
before = avsp.GetBookmarkList()
if shift and len(before):
    framecount = avsp.GetVideoFramecount() 
    after = [newBM(old, shift, framecount - 1) for old in before]
    after.sort()
    avsp.SetBookmark(before)
    avsp.SetBookmark(after)

うーむ、再帰なんて初めて使ったよ。
-------------------------------------------------------------------------
使い方：
ブックマークが打たれた状態でマクロを実行するとダイアログが現れるので、数値を入力する。デフォルトは1。
正ならば右(未来方向)、負ならば左(過去方向)にすべてのブックマークが指定した数値分だけ移動する。
最終フレーム + 1 = 0番フレーム(0番フレーム - 1 = 最終フレーム)として循環処理される。
数値以外の文字列を入力した場合はエラーとなり何もしない。小数点以下は切り捨て。
操作を取り消したい場合はもう一度マクロを実行し、事前の指定値の反数を入力すること。

CM検出マクロ for AvsP

2010-10-18T03:24:00.017+09:00

この前のSCx264 to Bookmarksは、少々時間がかかり過ぎるので、CMカットにはいまいち不向きなようだった。
もっと短時間で可能な方法はないものだろうか？
しばし悩んだ末、そういえばAviUtlにもなにやらCMカット用のシーンチェンジ検出プラグインがあると小耳に挟んだことを思い出したので、見てみることにした。

「チャプター編集 for AviUtl by ぽむ + 無音＆シーンチェンジ検索機能 by ru」
読み込んでいる動画の音声トラックをスキャンし、無音連続部分を検出して、その「開始部分」にチャプターを打ちます。
その後チャプターへのシーク時に無音部分内のシーンチェンジを検出し、その位置へ移動できます。

うーむ、なるほど…。
シーンチェンジ検出を無音部分に限定すれば高速化が可能かも！？
-------------------------------------------------------------------------
では早速やってみましょう。

まずサンプルクリップを用意します。
今回はMPEG2-TS、音声AACで再生時間31分、総フレーム数55749フレームの地デジソース(1440ｘ1080)です。

#sample.avs
MPEG2Source("sample.d2v")
AudioDub(last, WAVSource("sample.wav"))

#とりあえず普通に再生できる音声(FAWとかの偽装WAVはこの場合は駄目)でディレイ補正処理を済ませておく。
#今回はソースが地デジTSなので、とりあえず
#[DGIndexでdemuxしたaac　->　FAWを2回通してディレイ処理済のaac　->　FAADでPCM.wavに変換]
#したものを使った。
#処理終了後に差し替えれば、偽装WAVでも大丈夫。
#もしaacを直読みしたい場合は、BassAudioでも使ってDelayAudio()で補正することになる。

このクリップの無音部分を検出しなければならんわけですが、使えそうな道具は…MinMaxAudioかな？
AudioMax(0)が-100dbよりも低ければ、そのフレームは無音と判定することにしましょう(テキトー)。

#sample.avs
MPEG2Source("sample.d2v")
AudioDub(last, WAVSource("sample.wav"))

LoadPlugin("MinMaxAudio.dll")
AudioDub(BlankClip(last, width=160, height=80), last)
#スピードアップのため、クリップを映像160x80で真っ黒、音声はそのままに変換する
WriteFileIf("silence.log", "AudioMax(0) < -100", "current_frame")
#該当フレームのフレーム番号をテキストに書き出す

このavsをVirtuaDubの"Run Video Analysis pass"にかけてやると、約1250fpsくらいのスピードでsilence.logが生成されます。
結果を見てみると、どうやら無音のフレームは、各CM及び本編の切れ目あたりにだいたい10～30フレーム入るみたいです。
具体的には全55749フレームのうち、41-53、475-504、926-954、1376-1402、1825-1837、2289-2302、2725-2738、9077-9092、9990-10003、10874-10905、26915-26923、27373-27385、27808-27821、28707-28738、46494-46507、49179-49206、49628-49656、50078-50103、50525-50553、50975-50987、51439-51451、51874-51902、52783-52788、53043-53101、53523-53535、54422-54434、54886-54898、55320-55350、55735-55748の全29箇所561フレームが無音(-100db未満）です。

そこでsample.avsをこうしてやり

#sample.avs
MPEG2Source("sample.d2v")
AudioDub(last, WAVSource("sample.wav"))

PointResize(last.width / 4, last.height / 4)
#シーンチェンジ検出には320ｘ270程度で十分なのでPointResizeでリサイズ
FreezeFrame(0,41,41)
FreezeFrame(53,475,475)
FreezeFrame(504,926,926)
#途中24行省略
FreezeFrame(54898,55320,55320)
FreezeFrame(55350,55735,55735)
FreezeFrame(55748,0, 0)

#AviSynthの仕様ではFreezeFrameでコピーされるフレームはデコードされないので、
#MPEG2Sourceのボトルネックが解消されるはず

このavsをこの前のSCx264 to Bookmarks.pyにかけてやると、x264はなんと約2200fpsという想像を絶するスピードでシーンチェンジ検出を終え、ブックマークを打ち終わりました。
あとはFreezeFrameの行を消してやれば…YATTA!!
-----------------------------------------------------------------------------
てなことがありまして、これらの操作を自動で行うべく書いたAvsPマクロが以下の通りです。
使い方は、とりあえずAudioDubまで書いたavsを用意して、マクロを実行するだけです。
FAW使用者は、実行後に音声を偽装WAVに差し替えればいいです。ちょっと書き換えれば、そこらへんも自動化できるでしょう
前回約10分かかってたのが、約1分まで縮まりました(on Q9450定格)。
著作権は…発生するのかどうか知りませんが、もし発生するのであればGPLv3です(なんとなく）。
つーか、Pythonスクリプトですから、バイナリと違って秘密にはしようがないと思うけど…。

EDIT:
よく考えたらavs2aviのnull出力とx264の--preset ultrafast -o nul ではスピードは大して変わらないので(っていうか、今度はMinMaxAudioがボトルネックになっているので)、avs2aviをx264に変更。
avs2aviは要らなくしました。

#Silent_Scenechanges to Boolmarks.py for AvsP
#Author : Chikuzen (http://csbarn.blogspot.com/)
#Requiament: MinMaxAudio.dll, x264.exe, (avs2avi.exe)

#--------------preparation----------------------------------
import os

avsname = avsp.SaveScript()
script_org = avsp.GetText()

#あらかじめ各ツールのパスを設定しておくこと
#ファイルパスを変数に入れる際、前にrをつけるのはPythonのお約束
mmaudio = r'C:\AviSynth 2.5\Plugins_x86\MinMaxAudio.dll'
x264cli = r'G:\Enctools\x264_x86.exe'
#avs2avi = r'G:\Enctools\avs2avi.exe'
if mmaudio and x264cli and avsname and script_org:
#if mmaudio and x264cli and avs2avi and avsname and script_org:
#--------------------------------------------------------------
    #Search Silence
    logfile_si = avsname + '_silence.log'
    text1 = '\nLoadPlugin("%s")' % mmaudio
    text1 += '\nAudioDub(BlankClip(last, width = 160, height = 120), last)'
    text1 += '\nWriteFileIf("%s", "AudioMax(0) < -100", "current_frame", append = false)' % logfile_si
    avsp.InsertText(text1, pos = -1, index = None)
    avsp.SaveScript()
    os.system('%s %s --preset ultrafast --crf 51 -I infinite -o nul' % (x264cli, avsname))
    #os.system('%s %s -c null -o n' % (avs2avi, avsname))

    #silence_log to freezeframelines
    avsp.SetText(script_org)
    sifile=open(logfile_si)
    lines_si=sifile.readlines()
    sifile.close()
    text2='\nPointResize(last.width / 4, last.height / 4)'
    if len(lines_si):
        x = 0
        for line_si in lines_si:
            log_si = int(line_si.strip())
            if x != log_si - 1:
                text2 += '\nFreezeFrame(%i, %i, %i)' % (x, log_si, log_si)
                x = log_si
            else:
                x += 1
        text2 += '\nFreezeFrame(%i, %i, %i)\n' % (int(lines_si[-1].strip()), 0, 0)
    avsp.InsertText(text2, pos = -1, index = None)
    avsp.SaveScript()
    
    #SCx264
    logfile_sc = avsname + '_scenechange.log'
    opts = '--preset ultrafast --crf 30 -I infinite -i 1 --scenecut 50 -o nul'
    os.system('%s %s -p 1 --stats %s %s' % (x264cli, avsname, logfile_sc, opts))
    avsp.SetText(script_org)
    avsp.SaveScript()

    #scenechange_log to bookmarks
    scfile = open(logfile_sc)
    lines_sc = scfile.readlines()
    scfile.close()
    bookmarks = []
    for line_sc in lines_sc:
        log_sc = line_sc.split(' ')
        if log_sc[2] == 'type:I':
            bmpoint = int(log_sc[0].lstrip('in:'))
            bookmarks.append(bmpoint)
    avsp.SetBookmark(bookmarks)

Syntax Highlighting

2010-10-16T08:55:00.004+09:00

Henry氏の薦めもあって、このブログにSyntax Highlightingを入れてみた。

初めはこちらのwidgetを入れてみたのだが、いざ適用してみるとFirefox3.6やIE8だとちゃんとHighlightingしてくれない。
してくれないだけならまだいいが、ついでに"can't find brush for:python"なんていうのまで表示される。
それも適用したコード全てに対して表示されるので、例えばコードが10個あれば10回、100個あれば100回表示されるという始末である。
Chromeなら大丈夫みたいだけど、みんながみんなChromeを使っているわけではないだろうから(そもそも自分自身、メインで使っているのはFirefoxである)すぐにやめた。

で、結局こちらのほうを見ながら、テンプレートの編集なんてことをやる羽目になったわけだが、いざ導入してみると、これはこれで対応している言語が少ない、少ない、少なすぎる。

AviSynthがないのは仕方ない(つーかavsをHighlightingできるところなんて、世界広しと言えどもCCCPastebinくらいのものだろう。流石はMeWikiのメンテナーcheckers氏がやってるだけのことはある)けど、shellに対応してないってのは痛いなぁ…。

まあ、ないものは仕方がないので他で代用することにした。
とりあえずAviSynthはPythonでいいだろう。なんか似てるし。
Shellはどうしようとなやんだが、これも結局Pythonにした。特に問題はないみたいだし。

やっぱりCSSとかも勉強したほうがいいのかな。

SCx264 to Bookmarks for AvsP

2010-10-16T03:29:00.014+09:00

またまたAvsPマクロネタ。

さて、AviSynthのプラグインにはいろいろと毛色の変わったものがありますが、そんな中にSClavcとSCXvidというものがあります。
オリジナルのSClavcはx264のペンギン様ことLoren Merritt氏作、SCXvidの作者は#darkholdのいかつい人、MyrsloikことFredrik Mellbin氏であります。(以前一度、JEEB氏に写真を見せてもらったことがあるのですが、Myrsloik氏はやたら人相の怖い太っちょでした。一方、一緒に写ってたTheFluff氏は小柄で柔和そうな感じで、普段の言動から受ける印象とあまりにも違いすぎるので、思わず大笑いしたものです)

で、これらが何のためにあるかというと、要するにffmpegやXvidの2pass用のログを利用して、クリップ内のシーンチェンジの場所とかを割り出して色々利用しようというものらしい。
なんで「らしい」かといえば、使い方がよくわからないから。
とりあえずavs書いてVirtualDubに食わせて"Run Video Analysis pass"を走らせるなりすれば、2pass用のlogファイルが作られるわけですが、そこから先がどうしたものやら…。
AviSynth.infoによれば、「元々は、Yattaにおいて、libavcodecのシーンチェンジ・メトリクスの利用を可能するために書かれた。」とありますが、Yattaってねぇ…あれの使い方がわかる日本人なんているのかしら？
7月ごろにJEEB氏に「#yattaでmenter氏が初心者講習会を開くので来ないか？」と誘われたのでROMってみましたが、何をしゃべってるのかさっぱりわかりませんでした。(そもそも知りたかったのは理論やテクニックではなく、操作方法そのものなのですが、そこらへんはやってくれなかったし…orz)

まあ、Yattaの使い方は今もさっぱりわかりませんが、2pass用logからシーンチェンジ検出というのは理解できます。
そこでふと思ったことが「それならx264のlogファイル使ったほうがよくね？　lavcのmpeg4やXvidよりもlog出力速いじゃん」。
で、こんなのを書いてみた。

#SCx264 to bookmarks.py
frames = avsp.GetVideoFramecount()
logfilename = avsp.GetFilename(title='Select x264_logfile')

if logfilename:
    logfile = open(logfilename)
    logs = logfile.readlines()
    logfile.close()
    if len(logs) == frames + 1:
        bookmarks = []
        for logline in logs:
            log = logline.split(' ')
            if log[2] == 'type:I':
                bmpoint = int(log[0].lstrip('in:'))
                bookmarks.append(bmpoint)
        avsp.SetBookmark(bookmarks)
    else:
        avsp.MsgBox('This log is not corresponding to the number of frames of current clip.',title='Warning')

あらかじめx264.exeで --pass 1 をつけてエンコしたlogから、IDRフレームと判定されたフレームにブックマークを自動で打つマクロである。(またブックマークか…)
とりあえずシーンチェンジを検出して、ちゃんとIDRと判定されるようなオプションにしていれば、ほぼ100%検出できるはずである。

さて、ただlog読んでブックマーク打つだけでは面白くないので、さらに発展させてみる。

#SCx264 to bookmarks AUTO.py
import os
avsname = avsp.SaveScript()
#使用するx264.exeを毎回指定したい場合はこちら
#exe = avsp.GetFilename(title = 'Specify x264.exe used.')
#x264.exeのパスを固定したい場合は、こちらにフルパスで書いておく
exe = r'G:\Enctools\x264_x86.exe'

if avsname and exe:
    x264opt = '--preset ultrafast --crf 30 -p 1 -I infinite -i 1'
    thresh = '--scenecut 50'
    logfilename = avsname + '.sc_log'
    os.system('%s %s %s %s --stats %s -o nul' % (exe, avsname, x264opt, thresh, logfilename))

    logfile = open(logfilename)
    logs = logfile.readlines()
    logfile.close()
    bookmarks = []
    for logline in logs:
        log = logline.split(' ')
        if log[2] == 'type:I':
            bmpoint = int(log[0].lstrip('in:'))
            bookmarks.append(bmpoint)
    avsp.SetBookmark(bookmarks)

log出力も一緒にやるようにしてみた。

ううむ、これをどう使えばいいのだろうか？

例えばMPEG2Source("hogehoge.d2v")だけのavsの状態でこれを実行するとCMカットは楽になる。
なぜって、ただブックマーク移動していくだけで本編とCMの切れ目を確実にシークできるから。
AvsP初期装備のTrimEditorと併用すれば、ほとんどストレスなくCMカットできるはず(ただし、TrimEditorでTrimを実行する際は、ブックマークをすべてクリアしてからにすること。これを忘れるとプレビューの更新で随分時間を食うことになります)。
x264は--preset ultrafastならものすごく高速です。自分のそろそろ時代遅れなQ9450でも、1440x1080
のMPEG2-TSを90fps～100fpsで処理します。つーかMPEG2Sourceがボトルネックになっているので、本当はもっと速いです。2本同時にlog出力したりするといいかもしれません。

なお、「30分のTSだとlog出力だけで10分かかるじゃねえか、それだけあればCMカットなんか終わってるよ」とかいう意見は無視します…orz

分割結合マクロ for AvsP

2010-10-15T15:42:00.006+09:00

前回のTrimEditorは、いざ使ってみるとメリットはそれほどなかったような気もするけど、まあ、マクロの練習にはなった。
さて、今回もBookmarkを使ったマクロを書いてみる。

#Divide and Concatenate.py
bookmarks=avsp.GetBookmarkList()
if bookmarks:
    bookmarks.sort()
    start, trim, cat = 0, "", "\n"
    for i in xrange(len(bookmarks)):
        trim += "\nV%02i = last.Trim(%i, %i)" % (i, start, bookmarks[i] - 1)
        cat += "V%02i ++ " % i
        start = bookmarks[i]
    i += 1
    trim += "\nV%02i = last.Trim(%i, 0)" % (i, start) 
    cat += "V%02i\n" % i
    avsp.InsertText(trim + cat, pos=None, index=None)

例えば

AVISource("hoge.avi")
AudioDub(Last, WAVSource("hoge.wav"))

なんていうavsがあったとして、1234,5678,9012フレームにブックマークを打ってからこのマクロを実行すると

AVISource("hoge.avi")
V01 = Last.Trim(0, 1233)
V02 = Last.Trim(1234, 5677)
V03 = Last.Trim(5678, 9011)
V04 = Last.Trim(9012, 0)
V01 + V02 + V03 + V04
AudioDub(Last, WAVSource("hoge.wav"))

というように、いったんブックマークの位置で分割して、最後に結合するスクリプトが挿入される(挿入位置はカーソルの位置)。
なににこんなものを使うかといえば、

AVISource("hoge.avi")
V01 = Last.Trim(0, 999).Sharpen(1.0)
V02 = Last.Trim(1000, 1999).Blur(1.0)
V03 = Last.Trim(2000, 2999).FlipVertical()
V04 = Last.Trim(3000, 0).FlipHorizontal()
V01 + V02 + V03 + V04
AudioDub(Last, WAVSource("hoge.wav"))

てな感じでFilterRangeのかわりにするとか、はたまたEasyVFRとか使う人には便利かもしれない。

俺様TrimEditor for AvsP

2010-10-13T20:26:00.009+09:00

スクリプトなんて簡単なBash scriptとAviSynth scriptしか書けない私ですが、最近はほんの少しだけPythonをいじるようになりました。
なんでPythonかといえば、AvsP(AviSynth script editor)がPythonで書かれていて、マクロもPythonで書かないといけないから。

さて、本日のお題はTrimEditor。
AvsPには始めからTrimEditorが付いていますが、これが自分にはどうも使いにくい。
まずHomeを押すと出現するダイアログがウザい。
~~ある範囲を選択(削除)するごとにTrim(a,b)を1行挿入するので、Trimし終わったころには、それだけで7,8行のスクリプトになってしまうのもウザい。~~
というわけで、自分用のTrimEditorをでっち上げます。

#Bookmarks to TrimLine.py
bookmarks = avsp.GetBookmarkList()
num = len(bookmarks)
if num % 2 == 0 and num:
    bookmarks.sort()
    text = ''
    for i in range(0, num, 2):
        trimrange = bookmarks[i:i+2]
        cattext = '++Trim( %i, %i)' % (trimrange[0], trimrange[1])
        text += cattext
    avsp.InsertText(text.lstrip('++') + '\n', pos=None, index=None)
else:
    avsp.MsgBox('The number of bookmarks is odd (or zero).', title='Warning')

使い方：
ブックマーク(Ctrl+B)を適当にガンガン打って、マクロ実行。
2つのブックマークにはさまれた部位を残すスクリプトが、カーソル位置に1行で挿入されます。

例)ブックマークを1000,2000,3000,4000,5000,6000フレームに打って実行したら Trim(1000,2000)++Trim(3000,4000)++Trim(5000,6000) となる

なお、10行目のpos=Noneをpos=-1に書き換えると、スクリプトの最後に挿入位置が変更されます。

regression test

2010-10-03T06:44:00.004+09:00

#ffmpeg-develでDark Shikari氏のregression test用スクリプトを見つけた。

#!/bin/sh
vid=videos/foreman_cif.y4m
for tune in film zerolatency
do for m in "--intra-refresh" ""
  do for j in "" "--no-cabac"
    do for i in "--keyint 250 --slice-max-size 1000" "--no-weightb --interlaced"
      do for p in ultrafast superfast veryfast faster fast medium slow slower
        do ./x264 $vid --quiet --preset $p --tune $tune $i $j $m -o test.h264 --dump-yuv test.yuv
           ~/x264/JM/bin/ldecod.exe -i test.h264 > /dev/null
           cmp test.yuv test_dec.yuv
        done
      done
    done
  done
done

えーと、2x2x2x2x8=128パターンか。

JMェ

2010-09-27T00:14:00.002+09:00

そーいえば、UbuntuにはJM reference入れてなかったなー、と思い出し、ビルドすることにした。

wget http://iphome.hhi.de/suehring/tml/download/jm17.2.zip
unzip ./jm17.2.zip
cd ./JM
chmod +x ./unixprep.sh && ./uniexprep.sh
make

/JM/binにldecod.exeとlencod.exeの出来上がり！…って、.exe？

どうやらJMの中の人たちにとって、UNIXとはCygwinのことらしいです。

Spamming Dutchman

2010-09-20T14:24:00.003+09:00

x264.nlが配布しているx264.exe(for 32bit Windows)のr1722でmp4出力が出来なかった件について。

#L-SMASH@freenodeにて
2010年9月18日
00:15 (golgol7777) seems GPAC guys commited the patch today.
00:16 (jarod) what patch?
00:16 (jarod) something good?
00:17 (golgol7777) this patch@r2043 https://sourceforge.net/tracker/?func=detail&aid=3058368&group_id=84101&atid=571738
00:18 (golgol7777) but mingw build is still broken...
00:21 (Chikuzen) jarod: GPAC broke completely as it is impossible to compile with mingw after all.
00:21 (Chikuzen) you cannot update GPAC any longer.
00:22 (jarod) ah ok, well thats their problem then
00:22 (jarod) my script will keep using latest working libs it has
00:23 (jarod) and when x264 no longer thinks it should use gpac, we shall move along

2010年9月19日
20:55 (Chikuzen) jarod: https://sourceforge.net/projects/gpac/forums/forum/287547/topic/3857579
23:01 (jarod) Chikuzen
23:01 (jarod) - gpac revision 2053 done
23:02 (jarod) but i heard its making x264 buggy
23:02 (jarod) with .mp4 output
23:03 (Chikuzen) indeed
23:04 (jarod) but it does compile (and create the lib)
23:07 (Chikuzen) realy? I challenged and got failed for about three hours ago.
23:10 (Chikuzen) if you are good in build at r2053 , then use it
23:10 (Chikuzen) r2053 has finished the bug fix
23:11 (Chikuzen) r2053 includes wewk's patch
23:34 (jarod) but cruncher reports x264 failing with .mp4 output
23:44 (Chikuzen) x264_x86_r1722_nl.exe --help
23:45 (Chikuzen) .mp4 -> MP4 if compiled with GPAC support (no)
23:46 (Chikuzen) your binary has not linked libgpac_static.a
23:47 (jarod) lol ok
23:47 (jarod) that explains
23:50 (jarod) but then x264 fails to link but continues compiling
23:50 (jarod) lemme test
23:52 (jarod) Warning: gpac is too old, update to 2007-06-21 UTC or later
23:52 (jarod) gpac: no
23:52 (jarod) hihi
01:05 (jarod) ok
01:05 (jarod) gpac 2039 is now being used
01:05 (jarod) better something then nothing :)

「GPACの更新はしないように」って、ちゃんと釘を刺しといたんだけど…orz
golgol氏曰く「 libgpac_static.a は ar で固めてるだけなんだから、例えビルドに失敗してても.aが生成されるのは当たり前」だそうである。

jarod氏がGPAC公式のsvnを使わずgolgol氏のgitレポを使えばすべては解決する。
golgol氏のレポは色々なバグフィックスが行われていて、最新のmingwでも問題なくビルドできるようになっているから。
しかし、このオランダ人はとにかくplainビルドにこだわり、自分が配布するバイナリには絶対にパッチをあてたりしないのである。
確かにx264自体はplainにこだわる必要があるだろう。彼のバイナリはx264のバグ検出用という重要な側面がある。
でも、バグがあるにもかかわらず半ば放置状態のGPACまでplainにこだわる必要はあるんかいな？

ちなみに、こんな人がビルドしてるx264.nlのバイナリですが、信頼性は(基本的には)高いです。
なんせ周りにいる人たち(主にkemuri_9氏)が面倒見てますから。
どこのビルドのx264を使えばいいのかわからない人は、x264.nlのバイナリを使ってください。

ふわふわさん

2010-09-10T15:27:00.002+09:00

某月某日某所にて
19:23 (Chikuzen) "Reminder: only 152 days left"ってなんのことだろうと思ったら
19:23 (JEEB) wwww
19:24 (Chikuzen) 「空の境界」のBD発売までのカウントダウンかよ
19:24 (JEEB) TheFluff氏が予約したしねぇｗ
19:26 (TheFluff) kara no kyoukai is important ok

Anime makes you stupidってのは、自分のことなのだな…

x264_L-SMASHのビルド

2010-09-07T08:10:00.021+09:00

以前書いたlavf/ffmsつきx264のビルドに関する記事を数ヶ月ぶりに読み返してみた。
なんというか冷や汗ものである。
このまま放置しておくのは色々危険そうな気がするので、もう一度書いておく。
でも、普通のx264では面白くないので、今回は現在開発進行中のx264_L-SMASHのビルドにする。

用意するもの
autoconf/libtoolが使えるmsys環境、mingw、pkg-config、wget、subversion、msysgit、nasm、yasm、~~pthread-w32~~、zlib、bzip2
あきれるほどマメなMPC-HC開発者XhmikosR氏がこちらで配布しているセットを使えば、msysgit以外すべて揃っているのでとても楽である。（説明の手間が省けるので)
あとは自分の環境に合わせて/etc/fstabと/etc/profileをいじり、別にインストールしたmsysgitのgit.exeにPATHを通すなりすればよい。

1.x264_L-SMASH_clone.sh
x264_L-SMASHはこちらで公開されているが、そのままgit cloneすると、バイナリのバージョン表記がおかしくなるので、ここにあるx264_L-SMASH_clone.shを使ってcloneする。
DLしたら、この.shを＄HOMEに置いておくこと。
もしくは
wget http://up-cat.net/wiki.cgi?action=ATTACH&page=L-SMASH&file=x264_L-SMASH_clone.sh -O ＄HOME/x264_L-SMASH_clone.sh
を、スクリプトに追加する。

2.ビルド
あとは以下のスクリプトを実行すればおしまい。現状で使用できるaudio用codecを全部リンクしたx264.exeが出来る。
変数の内容は各自で自分の環境にあわせていじるように。
QuickTime SDKをインストールしていない場合や、libfaacをリンクさせたくない場合は、適当にコメントアウトすること。

#!/bin/sh
#Preparation
WORK=$HOME/LSMASH
PREF32=/mingw/i686-pc-mingw32
PREF64=/mingw/x86_64-w64-mingw32
HOST64=x86_64-w64-mingw32
CROSS64=x86_64-w64-mingw32-
QTSDK=/g/quicktime_sdk

cp /bin/pkg-config.exe /bin/${CROSS64}-pkg-config.exe

mkdir $WORK/src

#download src
cd $WORK/src
wget\
    http://downloads.sourceforge.net/project/lame/lame/3.98.4/lame-3.98.4.tar.gz\
    http://downloads.sourceforge.net/faac/faac-1.28.tar.bz2\
    http://downloads.sourceforge.net/project/opencore-amr/opencore-amr/0.1.2/opencore-amr-0.1.2.tar.gz
git clone git://github.com/mstorsjo/vo-aacenc.git
git clone git://github.com/mstorsjo/vo-amrwbenc.git
git clone git://git.libav.org/libav.git libav
svn co http://ffmpegsource.googlecode.com/svn/trunk/ ffms
$HOME/x264_L-SMASH_clone.sh
cp -r . $WORK/x86
cp -r . $WORK/x64

#32bit
cd $WORK/x86
for i in ./*.gz ; do tar zxvf $i ;done
for i in ./*.bz2 ; do tar jxvf $i ; done
rm ./*.gz ./*.bz2

cd ./lame*
./configure\
    --prefix=$PREF32\
    --disable-shared\
    --enable-nasm
make clean && make && make install-strip

cd ../faac*
./configure\
    --prefix=$PREF32\
    --disable-shared\
    --without-mp4v2
make clean &% make && make install-strip

cd ../opencore*
./configure\
    --prefix=$PREF32\
    --disable-shared
make clean && make && make install-strip

cd ../vo-aacenc
autoreconf
./configure\
    --prefix=$PREF32\
    --disable-shared
make clean && make && make install-strip

cd ../vo-amrwbenc
autoreconf
./configure\
    --prefix=$PREF32\
    --disable-shared
make clean && make && make install-strip

cd ../libav
./configure\
    --prefix=$PREF32\
    --cpu=i686\
    --disable-doc\
    --disable-ffprobe\
    --enable-gpl\
    --enable-version3\
    --enable-postproc\
    --disable-network\
    --enable-w32threads\
    --enable-runtime-cpudetect\
    --enable-memalign-hack\
    --enable-libopencore-amrnb\
    --enable-libopencore-amrwb\
    --enable-libvo-aacenc\
    --enable-libvo-amrwbenc\
    --disable-encoders\
    --enable-encoder=aac,ac3,alac,vorbis,libopencore_amrnb,libvo_aacenc,libvo_amrwbenc\
    --disable-muxers\
    --disable-hwaccels\
    --disable-devices\
    --disable-protocols\
    --enable-protocol=concat,file,pipe,md5\
    --disable-debug\
    --extra-cflags=-fno-strict-aliasing
make clean && make && make install

cd ../ffms
PKG_CONFIG_PATH=${PREF32}/lib/pkgconfig/ \
./configure\
    --prefix=$PREF32
make clean && make && make install-strip

cd ../x264_L-SMASH
PKG_CONFIG_PATH=${PREF32}/lib/pkgconfig/ \
./configure\
    --qtsdk=$QTSDK\
    --enable-win32thread\
    --enable-nonfree
make clean && make
cp ./x264.exe /usr/local/bin/x264ls_x86_\
`x264 --version|grep "x264"|awk '{print $2}'|awk -F . '{print $3}'`.exe

#64bit
cd $WORK/x64
for i in ./*.gz ; do tar zxvf $i ;done
for i in ./*.bz2 ; do tar jxvf $i ; done
rm ./*.gz ./*.bz2

cd ./lame*
./configure\
    --host=$HOST64\
    --prefix=$PREF64\
    --disable-shared\
    --enable-nasm
make clean && make && make install-strip

cd ../faac*
./configure\
    --host=$HOST64\
    --prefix=$PREF64\
    --disable-shared\
    --without-mp4v2
make clean && make && make install-strip

cd ../opencore*
./configure\
    --host=$HOST64\
    --prefix=$PREF64\
    --disable-shared
make clean && make && make install-strip

cd ../vo-aacenc
autoreconf
./configure\
    --host=$HOST64\
    --prefix=$PREF64\
    --disable-shared
make clean && make && make install-strip

cd ../vo-amrwbenc
autoreconf
./configure\
    --host=$HOST64\
    --prefix=$PREF64\
    --disable-shared
make clean && make && make install-strip

cd ../libav
./configure\
    --prefix=$PREF64\
    --target-os=mingw32\
    --cross-prefix=$CROSS64\
    --cpu=x86_64\
    --arch=x86_64\
    --disable-doc\
    --disable-ffprobe\
    --enable-gpl\
    --enable-version3\
    --enable-postproc\
    --disable-network\
    --enable-w32threads\
    --enable-runtime-cpudetect\
    --enable-memalign-hack\
    --enable-libopencore-amrnb\
    --enable-libopencore-amrwb\
    --enable-libvo-aacenc\
    --enable-libvo-amrwbenc\
    --disable-encoders\
    --enable-encoder=aac,ac3,alac,vorbis,libopencore_amrnb,libvo_aacenc,libvo_amrwbenc\
    --disable-muxers\
    --disable-hwaccels\
    --disable-devices\
    --disable-protocols\
    --enable-protocol=concat,file,pipe,md5\
    --disable-debug\
    --extra-cflags=-fno-strict-aliasing
make clean && make && make install

cd ../ffms
PKG_CONFIG_PATH=${PREF64}/lib/pkgconfig/ \
./configure\
    --host=$HOST64\
    --prefix=$PREF64
make clean && make && make install-strip

cd ../x264_L-SMASH
PKG_CONFIG_PATH=${PREF64}/lib/pkgconfig/ \
./configure\
    --host=$HOST64\
    --cross-prefix=$CROSS64\
    --enable-win32thread\
    --enable-nonfree
make clean && make
cp ./x264.exe /usr/local/bin/x264ls_x64_\
`x264 --version|grep "x264"|awk '{print $2}'|awk -F . '{print $3}'`.exe

L-SMASH

2010-09-07T01:36:00.005+09:00

最近、x264のビルダーやってる人たちの多くが採用しているパッチにmp4muxer.diffなるものがある。
このパッチ、オリジナルはVFR_maniac氏によるもので、内容はlibgpacなしでもx264でmp4出力出来る様にするというものであるが、実はそれだけではなく他にも色々と追加機能(音声やchapterのmuxとか)が盛り込まれていたりする。
色々と盛りだくさんなので、たしかに使わないよりは使ったほうがいいかもしれないが、ときどき不思議に思うのである。
「みんなよくこんなわけのわからんものを平気でホイホイ使うよなぁ…しかも自分で使うだけではなく他人にまで配布するなんて」
自分の知る限りでは、このパッチの内容(なにが出来るかとか）を把握できているビルダーは、VFR_maniac氏本人を除けば、あとはHenry氏とwipple氏しかいない。JEEB氏も知っているだろうと思う人もいるかもしれないが、彼は基本的にmkv大好きな人なので、これに関しては先の2名ほど熱心ではないと思う。彼らは全てL-SMASH projectのメンバーではあるが、そこにはやはり、それなりの温度差というものが存在するのではなかろうか。

それにしても、注目されているのかいないのかよくわからないプロジェクトである。
#x264における評判は悪くないんだけどフォーラムにもIRCチャンネルにも質問しに来る人間が一人もいない。
やっぱりmkvではなくmp4だからかな？

Ubuntu奮戦記　その７

2010-09-02T13:34:00.000+09:00

長いことご無沙汰してました。
もはや当時なんで苦労していたのかさっぱり覚えていません。
たしかパッケージに関することだったと思うんだけど…なんだっけなぁ。
checkinstallを使ってあれこれやってたはずなんだが。

忘れてしまったものは仕方がないので、このテーマはこれで終了にします。

Ubuntu奮戦記　その６　wine+AviSynth(2)

2010-05-02T15:49:00.002+09:00

しばらく書くのをサボっていたら、どこまで書いたのか忘れてしまった。
えーと、再生環境と編集＆フィルタリングは済んだから、あとはエンコードか。

Windows用のエンコーダーはx264もffmpegもmencoderもavs(AviSynth script file)に対応しているが、Linux用のバイナリは対応していない。
たとえばwindowsなら
x264 source.avs -o video.264
とやればx264でエンコード出来るが、Linuxだとこれが通用しないわけだ。
じゃあ、どうすれば良いかといえば方法は主に二つに分かれる

1.wineを使ってWindows用エンコーダーを利用する。
wineを使えばWindows用のx264もffmpegも普通に動く。
たとえばWindows用のx264.exeを$HOME/.wine/drive_c/windows/system32に突っ込んでやれば、あとは
wine x264.exe source.avs -o video.264
で、エンコードできる。
これがffmpegなら、音声もエンコードできる。
wine ffmpeg.exe -i source.avs -vcodec ffv1 -acodec pcm_s16le movie.avi
これで映像はFFV1、音声はPCMのaviになる。
Windows用のx264はx264.nlで手に入る。
ffmpegはramiro氏のAutomated Build、mencoderなら、sherpya氏なりKovensky氏なりのところにいけばいい。
わざわざMinGWを入れてクロスコンパイルする必要もないし、非常に楽である。

2.wineを使ってavsの内容を標準出力し、Linux用エンコーダーにパイプで渡す。
いくらwineを使えばWindows用バイナリが動くといっても、やはりwine上ではいまいちエンコードは遅くなる。
このためよく使われるのがこの手である。
とりあえずwindows用バイナリにはavsの読み込みだけをさせて、他形式へのエンコードはLinux用バイナリを使うわけだ。
この方法なら大して手間も変わらず、より高速にエンコードできる。
この方法で使うWindows用バイナリは、wineで動いて、標準出力出来るものなら別にffmpegでもmplayerでもなんでも良いが、一番よく使われているのはavs2yuvだろう。

avs2yuvはx264teamの総大将、pengvadoことLoren Merritt氏が、まだmplayerの開発を主にやってたころに作ったWindows用アプリケーションである。
出来ることはavsを読み込み、raw yuv、y4m、そしてHuffyuvで圧縮したaviを出力することだけだが、出力は標準出力でも行えるのがポイントである。
avs2yuv.exeを$HOME/.wine/drive_c/windows/system32にいれて
wine avs2yuv.exe source.avs -o -|x264 - --demuxer y4m -o video.264
とすれば、Linux用のx264でエンコードできる。
avs2yuvは映像のみにしか対応していないので、音声に関してはwaviかffmpegを使えばよい。
wine wavi.exe source.avs -|neroAacEnc -q 0.5 -if - -of audio.mp4

やはりLinux使うなら、エンコード用のバイナリはできるだけLinux用のものを使いたい。
そうでなければ、始めからWindows使えばよいのである。
というわけで、次回はLinux用バイナリのビルドのお話。

Ubuntu奮戦記その5 wine+avisynth

2010-04-04T17:31:00.001+09:00

さて、再生環境が整ったので、次はフィルタリングツールとエンコーダーである。

フィルタは非常に簡単。
wine+AviSynthで決まりだ。
launchpadのwineのPPAを登録してインストールし、wineからAviSynthをインストールすればよい。

そもそもLinuxネイティブなエンコードツール類にはまともに使えそうなモノがない。
ffmpegやmplayerでもフィルタはかけられるが、品質や数に関しては正直今ひとつだし、だいたいプレビューなしでどうやってtrimしたり細かい調整したりすればいいというのか。
え、Avidemux？　うーん…
AvidemuxはWindowsでなら何度か使ったことがあるが、残念な印象しか持っていない。

残念その１：遅くて不安定

gtk+であれQtであれクロスプラットフォームなGUI一般に言えることだが、これらをWindowsで動かすととにかく遅い。これがmkvmergeGUIなら遅いだけですむが、Avidemuxは遅い上に不安定でクラッシュしまくる。
まあQtアプリもLinux上なら結構速いようだから、これは見当違いなのかもしれない。

残念その２：よいフィルタが少ない

mplayerよりはフィルタも多いが、それでも数が少ないし、品質はイマイチ。
例えばリサイザーにしてもsplineやNearestNeighborだって使いたいことがあるのに、Bilinear、Bicubic、Lanczosしかない。わざわざAviSynthのリサイザーとswscale(MPlayerResize)の2種類用意するくらいなら、もっと種類増やせよ。だいたいswscaleにだってSplineとかあるじゃない。

残念その３：muxerが変

ffmpegと同じlavf使ってるはずなのに、出力が変である。
これでエンコした動画をPSPで再生しようとすると蹴られた。同じ動画をmp4boxやffmpegでremuxすればちゃんと再生できたのに、どーなってるの？(ひょっとするとここ数ヶ月の更新で治ってるのかもしれないけど)

残念その４：処理がYV12オンリー

AviSynthのように色空間を使い分けられるか、さもなくばAviUtlのYC48のような過剰ともいえる高品質処理が出来ないのでは、結局満足出来ないのですね。

avsのエディタはとりあえずUbuntu標準のgeditを使い、プレビューはwine経由でVirtualDubを使うことにした(AvsPはwineでも動かない)。ことの発端がvim用syntax fileなんだからvimを使うのが筋なのかもしれないが、あれになれるのはなかなか難しそうなので、とりあえず保留…。
geditは結構いいと思う。notepad++ほどではないが、機能は一通り揃っているし、拡張性も高そうである。それにこれ以上の高機能を求めるなら「だったらemacs使えよ」と言われてしまうだろう。
VirtualDubはWindowsと同様サクサク動く(ただ、メニューのフォントが見にくいのが難点か)。
ためしにAviUtlもwineで動かしてみたら、一応動いた。必要なruntimeやdll(.NETとか)をインストールすれば、こちらも普通に使えるのかもしれない。今度試してみよう。

問題はcodecである。
Windows用のVCMはインストールしても使えるものと使えないものがあるようだ。
とりあえずUtVideoは使えなかった。正確には、インストールは出来たがULRG以外はVirtualDubのダイアログボックスに表示されなかった。
ffdshowはインストール出来たし、vfwも使えるようだが、それなら入力はffms2、出力はffmpegを使ったほうがいいだろう。
どうやらLinux上ではffmsやDGMPGDecのように、フィルタ自身がデコーダーを内蔵するタイプのソースフィルタ以外は使い物にならないと思った方がいいらしい。ffmsの最大の開発理由は「Linux上における安定したソースフィルタの不在」であると聞いたことがあったが、それが実感できた。

次回に続く

Ubuntu奮戦記その4 mplayerビルド

2010-04-03T21:13:00.000+09:00

FFmpeg is a versatile tool to encode and convert a multitude of video and audio formats. x264 encodes high-quality video superior to other popular encoders.

Although FFmpeg and x264 are available in the Ubuntu repositories, you may need to compile from source. For example, the ffmpeg-user mailing list requires that you use the latest FFmpeg svn before asking for help. Since FFmpeg and x264 are updated frequently, you may also like to have the bleeding-edge for encoding videos. Also, FFmpeg in the Ubuntu repository may not support necessary encoders, decoders, and formats.

以上、HOWTO: Install and use the latest FFmpeg and x264より引用。

前回、筆者はUbuntuレポのmplayerをガラクタと呼んだ。理由は上記のとおりである。
x264もffmpegもmplayerも開発は活発に続いており、常に機能の向上とバグフィックスが進められている。もし使用中になんらかの不都合に直面したとしても、使っているモノが新しくなければ助けを求めても鼻も引っ掛けてもらえない。
"It's outdated."
"Update your x264(,ffmpeg or mplayer)."
こんなやりとりをここ数ヶ月で何度目にしたことか。

まあ、これがGIMPとかなら、何の疑問も持たずにレポのもの使うんですがね(ヲイ

さて、mplayerのビルドである。
筆者はx264とffmpegならmsys+mingwでビルドしたことがあるが、mplayerは一度もない。
ものが単なるエンコーダーやデコーダーではなくプレーヤーであるから、必要になるツールやライブラリも多くなるであろうことは簡単に想像がつく。一体何が要るんだろ？

<JEEB>    :Chikuzen氏はもうmplayerはビルドしましたかな？
<Chikuzen>:まだ、ただいまビルドに必要なものを調査中
<JEEB>    :sudo aptitude build-dep mplayer
<JEEB>    :sudo aptitude install git-core subversion
<JEEB>    :あとはgit clone git://repo.or.cz/mplayer-built.git
<Chikuzen>:それだけ？
<JEEB>    :うん
<JEEB>    :追加であと二つくらい要るような憶えがあるけど、なんだっけ
<Chikezen>:まあいいや、とりあえずやってみる
<Chikuzen>:えーと、READMEのとおりに
<Chikuzen>:まず./enable-mt
<Chikuzen>:次に./init
<Chikuzen>:そしてmake
<Chikuzen>:エラーで止まった。autoreconfというコマンドがないと言ってる
<JEEB>    :思い出した。autoconfとlibtoolが要る
<Chikuzen>:あとよく見るとyasmもnoになってるね
<JEEB>    :要るの？
<Chikuzen>:アセンブラなしではつらいでしょ
<JEEB>    :ならsudo aptitude install autoconf libtool yasm
<Chikuzen>:ふむ、./cleanしてもう一度make
<Chikuzen>:よし、今度はエラーでないぞ
<Chikuzen>:それにしてもこれほど楽だとはなぁ、msys+mingwが馬鹿みたいだ
<JEEB>    :uau氏のブランチはmkv対応も強化されてるし、ビルド用スクリプトもあるから楽ちん
<Chikuzen>:お、ビルド終わった
<Chikuzen>:PSP用にエンコしたやつでテストしてみる
<Chikuzen>:cd ./mplayer && ./mplayer ~/Change_vs_Neo_ep02.mp4

<Chikuzen>:おお、上手くいったみたい
<JEEB> :おめ
<Chikuzen>:thx

ここから先が長かった…

次回に続く

Ubuntu奮戦記　その３　再生環境

2010-03-31T05:18:00.000+09:00

動画のエンコード環境構築は、まず適切な再生環境を準備することから始まる。
適切な再生環境抜きでは、成果(エンコ後の動画)に対して評価を下すことが出来ない。
目的がiPhoneやPSP等向けの携帯動画なら実機を用意して再生確認をしなければならないし、ニコニコやzoomeへの投稿であるならば、投稿前の確認はFlashPlayerコンポーネントを使用するFLVPlayer(Flavie等)で行うべきである。
例えば「AviUtl+x264gui.auoでエンコードしています。投稿前にMPCで確認した時は大丈夫だったのに、ニコニコに投稿した動画はブラウザで見ると色が滲んで変に見えます。どうしてですか？」といった質問がたまにyoutube板のエンコードスレに来ることがある。
答えは「FlashPlayerはYUV420->RGB変換の際に色差情報の補間を一切行わないから」。
YUV420で圧縮された動画には、色差情報の不足のため、色が滲んでいたりエッジがギザギザになっているものがけっこうある。しかし、それではあんまりなので、一般的な再生環境はこれに補間処理を行って情報不足を目立たなくするようになっている。しかし、FlashPlayerは(おそらく処理量を低減し、少しでも再生を軽くするため)これをしない。言ってみれば安くあげるために手を抜いている。
このため、ある程度ニコニコ投稿経験をつんだAviUtlユーザーは、UVダウンサンプリングフィルタをYUV420-lanczos2(or lanczos3)で最後にかけることで対策を行う。これはある意味AviUtlの特徴であるYC48による高品質な処理を台無しにしてしまう行為になりかねないのだが、再生環境がFlashPlayerである場合はやむを得ないのである。

と、前置きがやたら長くなってしまったが、要はUbuntuで使うプレーヤーはどれにしようかというお話である。
結論から言えば、これは最初からmplayerに決まっていた。
#x264や#ffmpegにはたまに自分の環境で上手く再生できないと相談にやってくるLinuxユーザーやmacユーザーがいる。
「上手く再生できないんだけど、どうしたらええんかいな？」
「プレーヤーは何を使ってるんだ？」
「VLC（またはTotemとかQuickTimeとか)だよ」
「mplayer使えよ」
こういったやりとりが週に一度はあるような気がする。
特にVLCはデコード時に必要な参照フレームをすっ飛ばすために映像が崩壊するバグが数年間放置されており、また字幕周りもひどいということで甚だ評判が悪い。
Linuxならmplayerが一番と皆が口を揃えて言うのだから、やはりそれが正解なのだろう。

さて、さっそくmplayerを9.10にいれようと、synapticを開いて探してみたが…
「えーと、svn20090426…なにこれ？」
あらかじめ用意されているものは、たいへん古く、使い物にならないガラクタだった。
やはり、物事は簡単にはいかないものらしい。

次回に続く

Ubuntu奮戦記　その２　*nix使えよ!?

2010-03-29T20:01:00.001+09:00

x264の公式フォーラムであるDoom10 Forumの特徴の一つは、登録メンバーにLinuxユーザーが多いことである。
以前の公式フォーラムに指定されていたDoom9(といっても今でもこっちの方が情報は多いけど)ではLinuxやmac関連の情報は少なく、一体彼らはどこで情報を手に入れているのか不思議に思っていた。(その後判明したが、彼らの情報交換は主にIRCや各ディストロの公式フォーラムで行われていた)
だからDoom10が出来たとき、それまでDoom9ではあまり見かけたことのない名前がいろいろ出てきてLinuxでのエンコードについて語っているのを見たときはちょっと驚いたものだった。

さて、このスレッドである。
http://doom10.org/index.php?topic=180.0
LinixやBSD(たぶんmacも含まれる)においてAviSynthを使うための簡単なガイドラインといったもので、とりあえず必要なツール類と簡単なスクリプトの例、そしてvimのsyntax fileがあげられていた。
「Windows以外のOSでは、こんなことせにゃならんのか…なんだか大変そうだねぇ、素直にWindows使えばいいのに」
とか思いながら読んでいたら、昔AviSynthBlogで読んだこの記事を思い出した。
自分では使ったこともないけど、なにかの役に立つかもしれないと思い、「vimならこんなのもあるみたいよ」と書き込んだ。
そしたらお礼の言葉とともに「お前も*nixを使うべきだよ」と返事が返ってきた。
まあ、せっかく勧めてくれたことだし、気が向いたら試してみるかななんて思っていたところで、前回のような状況になった。
かくして筆者はLinux体験をすることになったのである。

とりあえずディストロはUbuntuにした。
一番簡単で使いやすいとどこかで聞いた覚えがあったからだ。
Ubuntuの公式サイトから9.10のisoをDLしてimgburnでCDに焼いて、再起動。
言語設定とキーボードを日本語にして、あとは待つこと20分程度でインストールはとりあえず終了。
「再起動する」を選んで、CDを取り出してEnter。
なぜ「とりあえず」かというと、このあと初回のアップデートに結構時間がかかるからである。
アップデートが済んだらもう一度再起動。さらにハードウェアドライバの設定でビデオカード(GF8400M GS)のドライバーをNVIDIA製のもの(185)に変更してさらに再起動。
ここまででかかった時間は約1時間といったところだった。

次回に続く

Ubuntu奮戦記　その１：香港映画の悪夢

2010-03-25T20:51:00.002+09:00

ここ数日間Ubuntu9.10をいじっている。
慣れないことだらけで、やたら苦労している。

「一体俺は何でこんなことをしているのだろうか？」

苦闘の果て、昨日やっと一段落ついたような感触を得たので振り返ってみた。
えーと、なんだったかなぁ...
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

すべての始まりは香港映画のDVDだった。

その日筆者は暇であった。
何もすることがないので、DVDを観ることにした。
20秒ほど本棚を眺め、手に取ったのはジャッキー・チェン監督／主演の「奇跡(miracle)」だった。
たしか数年前にTSUTAYAの安売りコーナーで500円くらいで買ったものである。
ドライブにディスクを突っ込んでMPCHCを起動した。
デコーダーはMS DTV-DVD Decoder、レンダラーはEVR-custom。
インターレース処理はビデオカードにおまかせ。
そして再生を開始すると…

DVDは4:3のレターボックスで収録されていた。
スクイーズでないことにまず腹が立った。
そして時々チラチラするような妙な違和感を覚えた。
訝しがりながらMPCHCの表示を見ると、60fpsで再生されていた。
Radeonのプルダウン検出が効いていない…だと…。
再生を中止し、調査を開始した。

DVDは60iで収録されていた。HD5870は間違っていなかった。
試しにYadif(mode=1)をかけた状態でコマ送りしてみると、同じフレームが１枚、2枚…そして前後のフレームが混ざりあったような残像のあるフレームが至るところに存在していた。
あきらかにPALソースをNTSCに無茶なやり方で変換したものである。
ひどい、ひどすぎる。
元々素材は24fpsなんだから、AssumeFPS(24000,1001,true)して、3:2プルダウンかければいいだけなのに、これを作った香港のオーサリング屋は、一旦PAL用に25p変換したものをブレンド処理して60iにしやがった。
ほんと映像業界って、どこの国でも…。
まあ最近はひどいDVDは少なくなったみたいだけど、かわりにひどいBDが増えているわけで。

こんなこと考える人間はあまりいない。
筆者も初めてこのDVDを観たときは、こんなことは少しも気にならなかった。
世の中、それで済んだほうがいいのである。
どうやらここ数年の経験は、あきらかに間違った方向に筆者を導いているらしい。
しかし、いまさらこの手の経験を‌リセットするのも無理である。
よせばいいのに、「修正してやる！」という気になってしまった。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

さて、PAL->NTSCによるブレンドの修正は次のような処理を行う。

MPEG2Source("video.d2v")
#最初に上下左右の黒べたをフィールドオーダーが狂わないようにしながらcrop
Crop(left,top,right,bottom)
#次に60i->25pの修正
#なんらかの方法でBob(60fps化)
Bob()
#そしてSRestoreをかける
SRestore()
#これでブレンドはほぼ除去され、60iは25PのPALに戻される。
#今回の場合は素材は劇場用映画なのだから、これをさらに24fpsにしてやる
Audio=NicAC3Source("audio.ac3")
AudioDub(last,Audio)
AssumeFPS(24,1,true)
ResumpleAudio(48000)
return last

問題はBobになにを使うかである。
まずavisynth内蔵のBobではガタガタで論外。
Yadif(mode=1)を使ってみたが、どうにも汚い。
Yadifmod+NNEDI2でも汚い。
結局MCBobが一番よかったので、これでいくことにした。
avsをVirtualDubにセットし、ULY0で中間出力開始。
終了までにかかる時間は、えーと…約17時間ですと！？

さすがMCBob、SD未満のサイズですらこれであるorz

かくしてメインPCは占領され、筆者は再び暇になってしまった。
しかたがないのでサブノートを引っ張り出した。
半年ぶりくらいに電源を入れた。
起動したOSは、バンドルのXPsp2だった。
Windows7にすっかり慣れてしまった現在では、どうにも使う気になれなかった。
どうしたものかとしばらく天井を眺めていたら、このスレッドのことを思い出した。
http://doom10.org/index.php?topic=180.0

次回に続く

デザイン変更

2010-03-09T19:48:00.002+09:00

ブログを書き始めて2ヶ月ほど(といっても更新はあまりしない)たって、初めてコメントが付いた。
まさか読む人がいるとは思わなかったのでびっくりした。
書いてる本人ですら三日に一度くらいしか開かないというのに...そもそもBarn(物置小屋)なんて、そんなもんでしょ。

とりあえず新着コメントの有無くらいはわかるようにしようとガジェットを追加してみた。
ついでにレイアウトもなんだか殺風景すぎる気がしたので変更(といってもBloggerのテンプレを別のものに変えただけ)。

やってみて改めて思ったが、我ながらこの手のことにはさっぱりセンスがないな...まあ、いいや。
物置小屋なんてこんなもんで十分でしょ。

ffmpegsourceのmpegsource入力

2010-03-08T17:23:00.003+09:00

ffmpegsourceは、myrsloik氏をリーダーとして#darkholdのメンバーが開発しているffmpegのwrapperである。
lavfでdemuxし、lavcでデコードして,swscaleで色空間変換やリサイズを扱い、lavfilterでその他のフィルタを掛けることが出来るAviSynth用ソースフィルターであり、最近ではx264の入力にも使われるようになった。
ffmpegが使われているだけあって非常に多くのフォーマットやコーデックに対応しており便利なことこの上ないのだが、弱点も幾つかある。なんでもlavfのmpeg parserは問題があるのでかわりにHaali氏のparser(HaaliMediaSplitterで使われているもの)を利用することにしたのだが、これはこれでやはり問題があるらしく、しかもHaaliはソースが公開されていないため、不具合に対処しようがないというのである。

一方、AviSynthでmpeg入力とくれば、真っ先にあげられるのはneuron2氏のDGMPGDecである。
こちらのほうもしょっちゅうヘマをするが、そのたびにneuron2氏はソースに手を入れ何とかしてきたので、AviSynthユーザーは特に理由がない限り、普通はmpegソースにはこちらを使う。

これは#darkholdメンバーにしてみれば、非常に面白くない事態であろう。
なんせ、世にあふれる動画ソースは殆どがPS(DVD)かTS(放送)かm2ts(BD)であるのに、あのneuron2のツールを使わねばならないのである。
くっ、悔しい...で(ry
(なんで#darkholdがneuron2氏を嫌うのか分からない人は、#darkholdがなんなのかとか、neuron2氏の過去の言動を、CCCPのサイトやDoom9等で調べてみればいい)

てな感じのことがあって、このたび#darkholdの重鎮の一人であるTheFluff氏が自前のmpeg parserをスクラッチで書く気になったみたいだ、とJEEB氏から聞いた。
以下、某IRCのログより適当に抜粋

(JEEB) そういや、TheFluff氏は夕べdgindexのソースのTSパーサーなど読んでた
(JEEB) 結局諦めたのかｗｗｗ
(JEEB) <Lord> anyway are you really sure you want to steal that code? :P
(JEEB) <TheFluff> no, it seems way too annoying
(JEEB) <TheFluff> I'd rather write a ts parsing library instead
(JEEB) <TheFluff> from scratch
(JEEB) <TheFluff> I mean, how hard can it be!?!!?!111
(JEEB) dgindexのソースを読んでみたら色々面白いものが見つかったけど、再利用出来る部分があまりなかったｗ
(JEEB) <TheFluff> rather than check how much data he has read and deciding to stop parsing after not encountering any headers after a certain amount of data, he gets the current time in milliseconds and aborts parsing if headers have been found for more than 5 wallclock seconds
(JEEB) ↑dgindexから
(JEEB) ５秒内でTSヘッダが見つからない→止まるｗ
(JEEB) どれぐらいデータが読み込めたかに関わらずｗ
(chikuzen_) TSならまるもプラグインのほうが速いよ
(chikuzen_) ソースも公開してるから見てみるのもいいかもね
(JEEB) ほほぉ
(JEEB) あと、日本専用のソースならねぇ・・・　他にATSCなどなTSファイルがあるからねぇ
(JEEB) まぁ、何もないよりマシかとｗ
(chikuzen_) http://www.marumo.ne.jp/mpeg2/
(chikuzen_) GPLみたいなケチくさいこと言わないのがまるもさんのいいところ
(JEEB) ライセンスは？
(JEEB) 再配布の禁止
(JEEB) ↑これがあるけどねぇ
(chikuzen_) そのままではね
(JEEB) ふむ
(chikuzen_) つまりいじったものに関しては一切関知しない
(JEEB) おぉー、readme.enでちゃんと書いてある
(JEEB) まぁ、ちゃんとライセンスを書いてくれる人は嬉しいわ
(JEEB) 書いてない人は「書いてないなら、何も出きない」という法律的な理屈を理解してないかなｗ
(chikuzen_) LanczosResizeのオリジナルは彼だけど、うやむやのうちにavisynthオリジナルみたいになっちゃったりして
(chikuzen_) 結構腹が立ったこともあるんじゃないかな
(JEEB) ほほぉ
(chikuzen_) まあ、120fpsAVIの生みの親でもあるんだけどね
(JEEB) それは言わないことにしようｗ
(chikuzen_) 本職のコーデックプログラマだから、フリーのエンコーダーは書けないって前に日記に書いてたな
(JEEB) ほほぉ
(JEEB) まぁ、TheFluff氏は今他のことをやってるけど、とりあえず#darkholdで貼ってみた

数時間後

(JEEB) chikuzen_, あのMPEG-2プラグインを紹介してくれてありがとうｗ　ソースはこんな初心者の目で見る限りでも、かなりdgindexより再利用できそうｗ
(chikuzen_) まあそのままは使えないだろうけど、parserなりdemuxerなりの‭参考くらいにはなるかも
(JEEB) うん

さて、どうなることやら

それにしても、草を生やすのが好きなフィンランド人である。

JM Reference Software

2010-03-02T21:28:00.000+09:00

JM Reference Softwareが更新されたと小耳に挟んだので見に行ってみた。
http://iphome.hhi.de/suehring/tml/

おお、本当に更新されてるじゃんってことで早速DLしてビルド。

用意するもの
・Microsoft VisualC++2008 ExpressEdision
・WindowsSDK for Windows7 and .NET Framework3.5SP1

手順
・JMのzipを解凍する
・中にあるjm_vc9.slnをVC++2008で開く
・"ソリューション構成"を"Release"にする
・ldecodとlencodのプロジェクトをそれぞれ”ビルド"する

これでbinフォルダの中にldecod.exeとlencod.exeができるので、あとはbinフォルダをまるごとコピーして、好きな場所に保存すればおしまい。

x264vfwの復活

2010-03-01T18:19:00.000+09:00

前回の記事を書いた後にDoom9に行ってみたら、x264vfwのスレッドが何故か賑わっていた。
何事だろうと訝しがりつつ新着投稿を読んでみると、あらびっくり。死んだと思われていたvfwが華麗なる復活を遂げているではないですか。
これはすごいと言うしかない。

そもそもvfwの何が悪かったかといえば、いわゆる"one frame in, one frame out"の原則である。
vfwはその仕組み上、エンコード前のフレームを1枚入力すると、そのフレームをエンコードして1枚出力しない限り、次のフレームを入力することが出来ない様になっている。これでは、Bフレームのように未来を参照するフレームのエンコードが原則的に出来ないし、処理速度をあげるためにマルチスレッド化を行おうにも、1枚のフレームを複数に分割して処理することしか許されない。複数枚のフレームを一度に処理するのと違って、圧縮率が低下するは、処理速度の大幅な向上は望めないはで問題がありすぎた。
xvidやDivX5等が主流の頃は、これを何とかしようとPackedBitStreamなる、なんともややこしいハックが行われたりしていたが、それはそれで問題が合ったりして、そうこうするうちにvfwは可逆圧縮コーデック専用のような扱いになりかけていた。

今回のx264vfw-r1471は今までとは明らかに一線を画す改造である。
vfwはまず1枚のフレームをエンコーダーに渡す。
エンコーダーは入力フレームを1枚受け取ると、エンコードしないでそのフレームをキャッシュしておき、かわりに真っ黒なフレームをエンコード済のフレームとして出力する。vfwは入力したフレームが無事に出力されたと騙されて、次のフレームをエンコーダーに渡し、受け取った真っ黒なフレームをAVIとして出力する。
これを繰り返すとエンコーダーには複数枚のフレームがキャッシュされていくが、ある程度のフレーム(x264ならrc-lookaheadによるだろう)が貯まった時点で、初めてエンコーダーはエンコードを始める。複数のフレームを同時に扱えるので、Bフレームの使用もまったく問題ないし、マルチスレッドによる高速な処理も行える。そしてエンコードされたフレームは、vfwによって作られた偽物のAVIとは別の場所に、mp4やmkvとして保存される。
この仕組だと、ACMによってエンコードされた音声は偽物のAVIのほうに格納されてしまうので、従来のものよりは少し扱いづらいことにはなるが、そもそも音声は別処理して後で改めて結合するのが今時の常識であるから、それほど大した問題ではない。
バッチ処理すると複数のダミーが出来るのがウザイと思う人もいるかも知れないが、それにしたって映像だけのAVIならどんどん上書きすればいいだけだから、出来上がるダミーは結局一つで済む。

そして今回の改造の一番すごいところは、他のエンコーダーにも応用可能な点である。
この仕組みを使えばmpeg2だろうがmpeg4だろうがtheoraだろうが、すべてvfwで実装出来る。極端な話、ffmpeg vfw codec(ffdshowではない)すら可能であろうと言うことだ。

VirtualDubはすでにPhaeron(Avery Lee)氏がCLIエンコーダーとの連携機能実装に動いているため、今回のx264vfw-r1471の恩恵を受けることはそれほど大きくはないだろう。
しかし他のソフト(TMPGEnc、Premiere、Vegas、Nive、紙芝居クリエーター、CrystelEngine等)のユーザーにとってはこれは非常に素晴らしい前進と言えるのではないかな。

x264.exeでavi出力

2010-03-01T03:54:00.000+09:00

komisar氏のサイトを眺めていたら、なにやら見たことのないnewパッチがあった。
x264_avi_out.v2.diff
名前から察するに、ｘ264.exeでAVI出力出来るようになるパッチらしい。
面白そうなので、さっそくビルドに挑戦してみた。

パッチ自体は問題もなく当てることが出来たが、いざ出来上がったバイナリでAVI出力を試してみると、エラーが出て上手くいかない。
他のMKVやMP4は普通に出力できるのに、なんでだろうと思いながらパッチの中身を覗いてみたらなんとなく理由がわかった。
このパッチはどうやらlavfのavimuxerを使用するものらしい。
そういや自分のビルドに使ってるffmpegは、configureで--disable-muxersにしているんだった。これでは駄目なはずだわな。

つーことで、ffmpegからビルドし直してみることにした。
いままでの設定は

./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --enable-cross-compile --target-os=mingw32 --host-cc=gcc --enable-gpl --enable-postproc --enable-memalign-hack --enable-runtime-cpudetect --disable-devices --disable-filters --disable-encoders --disable-network --disable-muxers --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio

これが

./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --enable-cross-compile --target-os=mingw32 --host-cc=gcc --enable-gpl --enable-postproc --enable-memalign-hack --enable-runtime-cpudetect --disable-devices --disable-filters --disable-encoders --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio --disable-muxer=ac3,adts,aiff,amr,as*,au,avm2,c*,d*,e*,f*,g*,h*,i*,m*,n*,o*,p*,r*,s*,t*,v*,w*,y*

に変った。
ただでさえ長ったらしいconfigureが、さらに長くなっちゃったよ… 。

さて、enable-muxer aviになってることを確認して、ffmpegをビルド。
お次はx264をもう一度ビルドし直し。
再度AVI出力を試してみたら、今度は無事にAVIで出力出来ました！

しかし、こんなもん、一体何に使えばいいんでしょうかね？
FLV出力以上に使い道が思い浮かばないんだよなぁ…。

SWF用DirectShowFilter　その２

2010-02-16T01:38:00.001+09:00

前回の記事に書いたSWF用DirectShowFilter(以下DSF)に、新たなる欠点を発見した。
どうもDirectShow使ってるせいか、動きが止まっている部分で、本来表示されなければいけないフレーム数よりも少ないフレーム数になってしまうことがある。

つまり、本当は全く同じ絵が5回連続で表示されるべきところが、1回だけ表示して、すぐ次の絵になってしまう、といったことが起こるのである。
一方、swf_vfpだとそのようなことは起こらない。
5フレーム同じ絵が続く場面では、きっちり5フレーム表示され、4フレームすっ飛ばしたりはしないのだ。

フレームをすっ飛ばしてしまうということは、音ズレとしてはっきりわかってしまうので、非常にまずい。特に止め絵を多用するものだと、終りのほうは悲惨なものになってしまう。

やはり信頼性はswf_vfpの方が高い。
DSFはスプライトが使われている部分の差し替え用AVI作成以外には使えないと思った方がいいようだ。

SWF用DirectShowFilter

2010-02-14T00:43:00.003+09:00

Doom9のこのスレでSWF用DirectShowFilterなるものが紹介されていた。
SWFでDirectShowといえばMPCを思い浮かべるが、あれはただIE用FlashPlayerをそのまま使っているだけで、ブラウザ以上のことは特に何もできない。

これが本当ならすげえやってことで、さっそくDL。
http://www.medialooks.com/products/directshow_filters/flash_source.html
どうやらフリーのようだが、要登録らしい。
あと、IE用FlashPlayerを利用しているようで、こちらも必須とのこと。

さて、インストールしてみて、まずはWMP12でSWFを再生出来るか試してみた…が再生出来ない。
どうもActiveXでセキュリティに引っかかっているようだね。
IE同様、WMPでもSWFの再生はブロックがかかるのか…はじめて知ったよ。
ではこれならってことで、QonohaPlayerで試してみると…上手くいきました！

特にコマ落ちしてる様子もなく、なによりもスプライトを使っている部分もちゃんと動いてる！　すごい！（何がすごいか分からない人は、SWFをAVIやMP4に変換しようとしたことのない人でしょう。経験者ならみんな驚くと思います）

さて、再生出来るなら、当然変換にも使えるはずってことで、AviUtlのDirectShowFileReaderで読み込めるか試してみると…クラッシュしたやんけ、オイ…。
ではVirtualDubならどうかとDirectShow input driverで試してみると…これもだめ。
AviSynthならどうかとDirectShowSource使って…orz
ならばこれはどうかとDSS2を使ってみると…やったぁ、読み込めた！

さっそくVirtualDubでAVIに変換…順調に行きました。

でも、なんでDSS２以外はダメなのかしら？ってことでしばらく試行錯誤してみると…どうやら音声を同時に読み込もうとするとクラッシュすることが判明。DirectShowSourceでもaudio=falseにしたら読み込めた(DSS2はもともと音声は読めないから無問題なわけね)。
そういえば、swf_vfpの履歴にmp3音声がどうこうってあったなぁ…あれと同じでPCMを使ってれば読めるのかもしれないけど、手元にPCM音源のSWFがみつからなかったので、調査は保留。
まあ、音声はいままでも別処理だったし、状況は好転したと言えますね。

さて、スプライト関連も上手く再現出来ることだし、これはswf_vfpもいよいよお役御免かなぁ…なんて思ってたところで、一つ不具合を見つけた。
どうやらレイヤーの重ね方だかアルファチャンネルの透過度の具合のせいか、色がおかしくなることがある。同じ現象はswfdrop.exeを使った場合も起こったことを思い出した。

うーん、swf_vfpなら、これは起こらないんだよなぁ…やっぱりすごいよ、まるもさん。

とりあえず、基本はやはりswf_vfp、スプライトの部分はこのDSF、どちらでもダメな場合はデスクトップキャプチャでAVIを作って、切り貼りするってことになるかな。

＊今回の実験に使用したSWFは、過去に筆者がニコニコ投稿用エンコードを代理したものを使わせて頂きました。作った人、勝手に使ってごめんね。

lavf/ffms付きx264_x64ビルド

2010-02-05T02:22:00.002+09:00

ちょっとサボっていたら、前回の更新から一週間以上経っていた。
誰も読まないチラシの裏替わりとはいえ、やはりサボるのはあまり良くないだろう。

ここ数日はx264.exe(x64)の自ビルドでlavf/ffms入力を有効にするために四苦八苦していた。
Windows&AviSynthユーザーとしては、全く要らないといってもいい機能ではあるが、やはり出来る事ならば有効にしておきたいのが人情というもの。

以下にその手順を書いておく
なお、これはr1416現在の情報なので、あとあと使えなくなっても知らない。

クロスコンパイルできるビルド環境構築は各自でやってるものとする。
参考：
http://komisar.gin.by/mingw/add/MinGW%20cross-compile%20toolchain%20(EN)/
http://zoome.jp/VFR_maniac/diary/89/
ちなみに筆者はkomisar氏のcross-mingw.gcc443.generic.20100124を使用している。
fstabは

e:/msys/mingw /mingw
e:/msys/local/ /usr/local
e:/msys/tmp /tmp1

まずpthread、zlib、bzip2はkomisar氏の配布しているものをそのまま使用しているので省略。

　yasm(0.8.0):
$ wget -c http://www.tortall.net/projects/yasm/releases/yasm-0.8.0.tar.gz
$ tar zxvf yasm-0.8.0.tar.gz
$ cd yasm-0.8.0
$ ./configure --prefix=/mingw
$ make
$ make install
$ cd ~

GPAC:
$ cvs -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac login
passwordはなし
$ cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
$ cd gpac
$ cvs update -D "2010-01-23 UTC"
$ wget -c http://pastebin.php?dl=m59b9d49c
$ mv pastebin.php@dl=m59b9d49c muken_20100123.diff
$ patch -uNp0 < muken_20100123.diff
$ ./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32- --cpu=x86_64 --static- mp4box
$ make lib apps
$ make install-lib
$ cp -p ./bin/gcc/MP4Box.exe /e/mp4tools/mp4box.exe
$ cd ~
ちなみに途中であてているパッチはVFR maniac氏の最新パッチ(どうやら現在、非公開の様子)
/e/mp4toolsは各自適当に変更して欲しい。

FFMPEG(今回は2010-02-01のスナップショット):
$ wget -c http://ffmpeg.org/releases/ffmpeg-checkout-snapshot.tar.bz2
$ tar jxvf ffmpeg-checkout-snapshot.tar.bz2
$ cd ffmpeg-checkout-snapshot
ここで./libswscale/swscale_template.cの2500行目あたりを次のように書き換え

#if ARCH_X86_64 && AV_GCC_VERSION_AT_LEAST(3,4)
:: "m" (src1), "m" (dst), "g" (dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#else

を

#if ARCH_X86_64 && AV_GCC_VERSION_AT_LEAST(3,4)
:: "m" (src1), "m" (dst), "g" ((x86_reg)dstWidth), "m" (xInc_shr16), "m" (xInc_mask),
#else

にする(1行だけ)。
$ ./configure --prefix=/mingw/x86_64-pc-mingw32 --cross-prefix="x86_64-pc-mingw32-" --enable-cross-compile --target-os=mingw32 --host-cc=gcc --enable-gpl --enable-postproc --enable-memalign-hack --enable-runtime-cpudetect --disable-devices --disable-filters --disable-encoders --disable-muxers --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio
$ make
$ make install
$ cd ~
configure長すぎる...でもバイナリが小さくなるし、無効にしても影響のない機能はなるべく切るべきだと思う。
なお、pthreadをautostaticでビルドしておけば、--enable-pthreadsもいけるそうだが、今回はパス。

ffms(現時点では275):
$ svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffms2
$ cd ffms2
$ PKG-CONFIG="/mingw/x86_64-pc-mingw32/bin/pkg-config.exe" ./configure --prefix=/mingw/x86_64-pc-mingw32 --host=x86_64-pc-mingw32
$ make
$ make install
$ cd ~
なおpkg-config.exeは
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.23-3_win32.zip
glibは
http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.22/glib_2.22.3-1_win32.zip
からDLして、あらかじめ/mingw/x86_64-PC-mingw32以下にまとめてぶちこんでおくこと

x264：
$ git clone git://git.videolan.org/x264.git x264
$ cd x264
$ ./configure --cross-prefix=x86_64-pc-mingw32- --host=x86_64-pc-mingw32
$ make fprofiled VIDS="/g/for_test/soccer_4cif.y4m"
$ make install
$ cp -p /usr/local/bin/x264.exe /e/x264/mine/x264_r1416.exe
$ exit
なんか-march=core2はあまり速くならないようなので、最近はあまりつけていない
fprofiledの動画はなんでもいいらしいが、とりあえずhttp://media.xiph.org/video/derf/y4m/soccer_4cif.y4mを使っている。
mp4box同様、/e/x264/mineのあたりは各自で適当に変えること
上には書いてないが、NAL-HRDパッチとkomisar氏のlog_fileパッチはいつも当てている。

以上で終了。
筆者にIRCで丁寧に教えてくれたVFR maniac氏とJEEB氏に感謝します。

弄りたがる人達

2010-01-26T03:37:00.003+09:00

komisar氏がGCC4.4.3の配布を始めたので4.4.2から差し替えた。
別にこれといって変わった様にも思えないし、4.4.2で何も困ってはいなかったのだが、ソフトウェアに関してはなぜか最新を使っていないと気が済まないという難儀な性格なので仕方がない。

最新といえば、MPC-HCがr1552でMPEG2のDXVAに対応したらしいので、こちらも更新してみた。
いつもどおりAlexin女史のところ(xvidvideo.ru)からr1557をDLしてインストール。
とりあえずmpeg2でも内部フィルターでDXVAは効くようになったみたいだが、ffdshowのlibavcodec使用時と比べても、CPU使用率は全く下がらない。3%～15%程度をうろうろしている。(後で気づいたが、実はこのとき使われていたデコーダーは、MPC-HCのものではなく、MS製のほうだった。MPC-HCのデコーダーではDXVAは働かなかったようである）
WMP12 ＆ MS DTV-DVD VIDEO DECODERだと常に5%未満なんだが…DVD鑑賞には結局WMP12が一番いいみたい。
とりあえず再生開始時にフル画面で立ち上がるのをやめてくれればなぁ…どこかに設定出来るところがあるのかしら？

と、まあ、このように筆者自身色々弄り回すのが好きな人間なのであまりでかいことは言えないかもしれないが、世の中には兎角、ワケも分からず色々と弄り回して事態を悪化させるのが好きな人が多いようである。
例えば昨日の2chDTV板のx264スレの書き込み。

自分のエンコード環境はaviutlで編集しavsファイルを作りavsをaviutlに読み込ませて aviutlとavisynthを使い”x264出力(mp4/mkv)プラグイン”でmp4ファイルを作っています。
オプションは
--crf 20 --profile high --preset medium --level 4.2 --ref 3 --mixed-refs --bframes 3 --qpstep 8 --weightb --weightp 0 --trellis 0 --direct auto --subme 7 --no-fast-pskip --no-dct-decimate --partitions p8x8,b8x8,i8x8,i4x4 --8x8dct --scenecut 75 --me umh --merange 32 --aq-mode 0 --psy-rd 0:0 --no-mbtree --b-adapt 1 --threads auto --thread-input

これを見たDark_Shikari氏の反応はこのようなものだった

20:09 (Dark_Shikari) also, the non-saging post asking for settings help
20:09 (Dark_Shikari) with unbelievably bad commandline
20:09 (Dark_Shikari) smells like megui

確かにひどい設定だと思う。一体何を考えたらこんな設定になるのか意図がさっぱりつかめない。

こんなことするくらいなら、ただ単に
--preset slow --tune animation --profile high --level 4.2
としたほうが絶対にいいに決まっている。

なんでこんな設定にするのやら…多分、大昔に書かれたあやふやな情報を読んで、それを鵜呑みにしてるんだろうなぁ。
tobinaka氏はかつてサイトを閉じる際に、それまでに彼が書いた記事を削除した。
あれはやっぱり正解なんだと思う。

日記

2010-01-23T13:47:00.001+09:00

UtVideoの梅澤氏がなにやら不具合の調査をしたいらしい。
http://umezawa.dyndns.info/wordpress/?p=1468
サンプルは少しでも多い方がいいだろうから、とりあえず適当に英訳してDoom9に投稿しておいた。
実は梅澤氏もDoom9にはレジストしているので、やろうと思えばご自分で出来るのだが、英語は苦手なのでパスとのことだ。
筆者も英語は得意でも何でもないんだけどね…tobinaka氏はどこいったんだ？

x264はとうとうr1400になった。
速いなぁ…まだlavf/ffms2のビルドの仕方、わかんないよ…。
とりあえずいつも通り、nal-hrdパッチを当ててビルドした。これもいい加減、正式にcomittしてくれないかな。
kierank氏がんばって－。

P.S. インタレエンコでCBP Bufferが変なことになってる…これは、しばらくは駄目なのかなorz

I have caught a cold.

2010-01-17T10:12:00.001+09:00

昨日から体調が思わしくない。
どうやら風邪をひいた模様。
IRCで「風邪ひいた」と言ったら、kierank氏から「それは俺のがうつったに違いない」と言われた。
まさかイギリス人に風邪をうつされるとは...IRCって恐ろしい(を

x264_r1391用nal-hrdパッチをmuken氏が書いてくれたので、さっそくビルドし直し。
試しに寝る前にDVDを一本インタレ保持でセットしておいたが、どうやら問題はない様子。

自ビルドを公開している人の最新を幾つか見てみたが、lavf/ffms2を有効にしている人は少ない模様。
やっぱりそうだよなぁ、winの場合は、正直あんまり需要ないもんなぁ。
むしろ、gui.auoとかx264Encoderみたいなものにとっては、この変更はかなり痛いのかも。
たしかmuken氏も「これは大打撃」とか言ってたし...。

x264が久々の更新

2010-01-14T21:04:00.000+09:00

r1376が昨年の12月15日だから、約1ヶ月ぶりか。

RIPはとりあえずニコニコ用には使えないだろうな。
IDRがなければシークが効かないのがflashplayerだから。

ffms2とlavfをenableにするにはどうすればいいのだろうか？
ffms2もffmpegも自ビルドしたことがないからさっぱりわからん。
そのうちDoom9かDoom10に解説が出るだろうから、それまでは様子見しとこう。
どのみちAviSynth使う分には関係ないし。

問題はnal-hrdのほうかな。
早く誰かパッチ書いてくれないかしら。

SWFをAVIに変換する方法

2010-01-14T04:05:00.000+09:00

前回「ちょっと調べれば自分で出来る」と書いた。
SWFからのエンコードのことである。
書いたときはそう思っていたのだが、その後、頭の中のもう一人の自分がこうささやいた。
「本当にちょっとで済むのか？」

ちょっとで済むに決まっている。
済むだろう。
済むはずだ。
なんせSWFなんて作ったことのない筆者ですらなんとかなっているのだから。
念のために確認してみようと思い「swf mp4 変換」で検索してみた。

…

検索にBingなんか使ったのがまずかったのかと思い、googleでも検索してみる。

…

どうもちょっとでは済まないみたい。
これならいけるだろうという方法を詳しく紹介しているページは見つからなかった。

一度、やり方をまとめて書いておいた方がいいのかもしれない。

早起き

2010-01-12T07:58:00.004+09:00

朝の4時前に目が覚めた。
SWFをMP4にして欲しいとの依頼がスレに来ていたので、1時間半程度で仕上げた。
今回の依頼も部分的にスプライトを使っているようで、swf.vfpではうまく変換出来なかった。

ニコニコが出来て2年以上が経ち、βやγの頃は少なかった手描き動画も今では大量に投稿されるようになった。
つべ板の手描き動画スレを覗いてみれば、トレス／非トレス／二次創作ではない完全なオリジナル(これは少ないみたいだけど)と、皆さん色々誘惑に耐えながら「日産10枚」とか「半年かかった」とか、なかなか大変そうなご様子である。

筆者は昔、某エロゲのプレイ動画を投稿していたことがあるのだが、シリーズ2本を完結させたところで投稿することをやめてしまった。
画面をキャプチャーしながらゲームをするという作業に嫌気がさしたのだ。
ああマンドクサ、やってらんねぇ…。

もともとプレイ動画なんてものは、手描きに比べればかかる労力は遥かに低い。多少編集に凝ってみたところでたかが知れている。ましてやアクションゲームではなくエロゲである。気を付けることなんてテキストを送るスピードをどの程度にするかくらいのものだ(あとは〇〇なシーンの修正とか…)。

そういう人間であるから、彼／彼女らの書き込みを眺めていると、その情熱には本気で感心してしまう。

キャプチャーしながらゲームをするのは嫌だったが、編集とエンコードは結構楽しめた。
特にエンコードは楽しい。
限られた容量、ビットレートのなかで、いかにしてより良い結果を叩きだすか…うん、いいねぇ。

とりあえずエンコだけならそんなに手間はかからないし、平均点くらいはもらえる程度の知識は持っているつもりなので、他人の作った動画のエンコを代わりにやるというお遊びを、かれこれ2年ほどやってきたわけだが、今回のような依頼をこなす際にいつも考えることがある。
「もし代理でエンコするような人がいなかったらこの人はどうしたのだろう？」
「そもそも自分のここ数カ月の労力の結晶を他者に委ねるということに抵抗はないのだろうか？」
「ちょっと調べれば自分で出来るだろうに…」

そう、「ちょっと調べれば」自分で出来るだろう。
でも現実にはそれが出来ない人がいるわけである。
おそらく彼ら／彼女らは、動画のエンコードという行為に楽しさをあまり感じることがないのだろう。好きでないことに取り組んだところで良い結果が生まれることは殆どない。これが受験とかならば嫌でも頑張るしかないわけだが、ましてや趣味の世界のこととなればなおのこと。

筆者は絵を描くという行為に何ら喜びを見いだすことがないため、幼少の頃から禄に落書きすらしなかった人間である。

多分、これと同じことなんだろうなぁ。

接触事故？

2010-01-11T23:20:00.002+09:00

父親が自転車と接触事故を起こしたらしい。
話を聞いてみると、信号を左折中に直進してきた自転車が車体の左後部にぶつかった模様。
相手側(女性)には怪我もなく、自転車も壊れてはいないようなので、大事には至りそうにないが、なにやら父の「後方不注意」とかいってゴネたがっているらしい。
さて、どうなることやら。

ベネディクト戦記　エンコード設定

2010-01-11T02:45:00.005+09:00

この前筆者がエンコした動画に「エンコ設定教えてよ」というコメントがついていたので、ここに書いておくことにする。
<a href="http://www.nicovideo.jp/watch/sm9293085">【ニコニコ動画】ボーダーブレイク　ベネディクト戦記15　第3採掘島（B）</a>

0.使用したものとか

エンコード素材：
DVDレコーダーによる録画（VOBファイル、19725フレーム、10分58秒)

使用ツール：
DGMPGDec 1.5.7
AviSynth 2.5.8MT(SEt)
VirtualDub 1.9.8(プレビュー用)
avs2yuv.exe
pipebuf.exe
x264.exe (rev1376/64bit)
wavi.exe
neroaacenc.exe 1.5.3.0
mp4box.exe

なお解説にあたってはファイルパスは省略

1.d2vファイルと音声ファイルの作成
DGIndex.exe -ai source.vob -o source -ia 3 -fo 0 -yr 2 -om 2 -hide -exit >null

2.avisynth scriptの作成
#ベネディクト戦記 #16 movie.avs
SetMemoryMax(1024)
SetMTMode(2,0)
LoadPlugin("DGDecode.dll")
LoadPlugin("NicAudio.dll")
LoadPlugin("YadifMod.dll")
LoadPlugin("NNEDI2.dll")
LoadPlugin("mt_masktools-25.dll")
LoadPlugin("RemoveGrainSSE2.dll")
Import("LimitedSharpenFaster.avs")
LoadPlugin("mvtools2.dll")
LoadPlugin("AddGrainC_11.dll") #メモリリーク回避のためver.1.1を使用
LoadPlugin("Gradfun2db.dll")
Import("Gradfun2dbmod.avs")
Import("GrainFactory3.avs")
#映像、音声の読み込み
MPEG2Source("source.d2v", cpu=6) #ブロックノイズがひどいのでcpu=6
AudioDub(NicAC3Source("source T80 2_0ch 256kbps DELAY24ms.ac3", channels=2))
DelayAudio(0.024)
Normalize(volume=1.0,show=false)
#動画の開始部分の崩れた映像を1秒弱削る
Trim(25,0)
#インターレース解除
#60fps? ニコニコでは再生重過ぎ&ビットレート足りないだろｊｋ
interp=NNEDI2(qual=3)
YadifMod(edeint=interp)
#周囲の黒ベタを全部削り、16：9にリサイズ
＃アスペクト比はほんの少し狂うが、画面の大きさ&見やすさ優先
Spline36Resize(768,432,15,21,-17,-16)
#とにかくボケボケのソースなので思いっきりSharpenかけてから512x288にリサイズ
Sharpen(1.0)
LimitedSharpenFaster(dest_x=512, dest_y=288, SMode=4, LMode=4, strength=200)
#30fpsの動きの悪さをごまかす＆ビットレート削減のため、ちょっと強めにモーションブラー
#ベネディクト戦記はやたら動きが激しいので、モーションブラーかけるとカッコイイ(と思う)
super=MSuper()
bw_vec=MAnalyse(super, isb=true)
fw_vec=MAnalyse(super, isb=false)
MFlowBlur(super, bw_vec, fw_vec, blur=45)
#壁や地面ののっぺり対策にディザとシルバーグレインをかける
#ただし、明部にかけるとノイズが目立ちすぎるので、中間部と暗部のみ
GradFun2dbmod(custom="GrainFactory3(g1str=10, g2str=10, g3str=0, g1shrp=50, g2sharp=50,g1size=1.4, g2size=1.1, th3=120, th4=120)
Distributor()
return last #スクリプト終了

３.音声のエンコード
とりあえずHE-AACで64kbps使っとけば、まず音質で文句はでない
wavi.exe movie.avs audio.wav
neroaacenc.exe -br 64000 -2pass -if audio.wav -of audio.aac

4.映像のエンコード
基本方針はプレミアム会員のファイルサイズ100MBをほぼ使い切る＆多少のノイズは気にしないでディテール重視。
x264は非常に優秀なので、あれこれオプションをいじってもいいことは殆どない。適当に任せておけば、うまいこと良い感じに誤魔化してくれる。
pipebuf.exe avs2yuv.exe movie.avs -o video.y4m -o - : ^
x264_x64.exe - stdin y4m --pass 1 --bitrate 1182 --tune film --bframes 5 --b-pyramid normal --direct auto --weightp 0 --keyint 300 --aq-mode 2 -o null

x264_x64.exe video.y4m --pass 2 --bitrate 1182 --tune film --bframes 5 --b-pyramid normal　--ref 8 --keyint 300 --direct auto --me umh --subme 10 --trellis 2 --colormatrix smpte170m
--weightp 0 --no-dct-decimate --aq-mode 2 -o video.264

５.映像と音声を結合
mp4box.exe -add video.264:fps=30000/1001 -add audio.aac -new result.mp4

以上で全行程終了
所要時間　約１時間半(Core2Quad Q9450 定格 / Windows7pro x64 / メモリ8GB)

６.最後に
筆者は、このゲームをやったことはおろか、実物を見たことすらありません(近所のゲーセンには入っていませんでした)。
仕方が無いので、画質に関しては自分の好み＆視聴者受けしそうな感じになるように、適当にフィルターかけていじってます。
いままでのシリーズ16回のうち14回は自分がエンコしました。
もし変だったらごめんね、ベネディクトさん...

活動記録

2010-01-11T02:17:00.002+09:00

10日(日)
朝っぱらからニコニコ用代理エンコを2本(依頼人は同一)
内容：作業用BGM
ソース：VC-1

始まりました

2010-01-11T01:45:00.000+09:00

いつまで続くことやら…。