Friday, November 26, 2010

take a rest for a while

disconnect

[MacOSX] x264 binary revision 1804 [64bit]

x264_MacOSX_rev1804.zip


※パッチは当てていません

[x264] Revision 1793, 1796, 1797 and 1802

今回のコミットのうち、4つに何らかの形で関わることになりました。
一番大きいのはr1802ですけど、順番通りに一つ一つ触れます。

まずr1793
これはr1796が関係しています。
r1796のパッチで
HAVE_LAVF ? "/libavformat" : ""

HAVE_FFMS ? "/ffmpegsource" : ""
などを使用していますが、これがエラーを吐くことから発見されたもの。
configureが中途半端なために起こるものだったので、これを修正したのがr1793です。
詳細はコミットメッセージを読んでください(僕が書きましたw)。
ちなみに最初は僕が修正して#x264devに提出して、D_S氏にokを貰ったのですが、
ラスボスのペンギン様に「if/elseが多すぎる」とドリルくちばしを喰らってお流れに。
修正しようと思ったら既にkemuri氏が素早くcoolに直してしまっていました(笑)
コミットメッセージが僕のになってるのはそういう経緯です。

次はr1796
libswscale/libavformat/ffmpegsourceのバージョン、ライセンス表示のパッチです。
バージョン情報についてはぶっちゃけそれほど役に立たない疑惑がありますが…(笑)
あったらあったで便利かなと。
実はこのパッチ、最初は#x264devに提出するつもりではなかったのですよね。
自分が欲しかっただけで、需要があるとも思えなかったので。
ただ、どうせなのでライセンス表示も弄ろうとしたら、意外な発見をすることに。
./configureのとき、--disable-lavf、--disable-swscale、--disable-ffmsが選択可能です。
libavformatとffmpegsourceはどちらもlibswscaleを必要とします。
なので、./configureを走らせるときに、--disable-swscaleを有効にした場合は、
自動的にlibavformatとffmpegsourceも無効になります。
一方libswscaleはlibavformatを必要とはしないので、--disable-lavfを有効にしても
libswscaleは無効にはなりません。
実際にlibavformatが無効でも、--vfのresizeフィルターでlibswscaleが使用されます。
しかし修正前のx264は、lavf=yesかどうかでライセンスの表示の有無を判断していました。
以上の問題があったので、これを修正してライセンス表記を正確にしたのがこのパッチ。
libswscaleのみ使用している場合は
libswscale license: ***
libswscaleとlibavformatの2つを使用している場合は
libswscale/libavformat license: ***
libswscaleとlibavformatとffmpegsourceの3つを使用している場合は
libswscale/libavformat/ffmpegsource license: ***
 などのような感じに表示されるようになっています。

次にr1797
これは僕が提出したr1793に相当するはずだったパッチでに含まれていたものですが、
kemuri氏のパッチに置き換わったので、その分を補完する形になったものです。
上にも書いたようにswscaleが無効ならlavfもffmsもyesかどうか判断する必要はありません。
後半のlavf、swscale、ffmpegsourceの部分が肝心の内容ですが、
統一されていないインデントが気になったのでついでにそれも修正しました。

最後にr1802
実はこれ、僕のパッチが形を変えてコミットされたものです(笑)
[x264] Disable Duplication in Weighted Prediction for P-frames [patch]
新しい--weightp 1は、僕のパッチの--weightp 2 + --no-weightp-dupに相当します。
Blu-rayやPSPやCoreAVC(1系)やFlashPlayer(10.0系)での再生を考えるなら、
--weightp 2ではなく--weightp 1を使えば今後デコードが壊れなくなるはずです。

以上、僕が関わったコミットに関する簡単な説明でした。
ビルドはまた今度。

[x264] Revision 1793, 1796, 1797 and 1802

今回のコミットのうち、4つに何らかの形で関わることになりました。
一番大きいのはr1802ですけど、順番通りに一つ一つ触れます。

まずr1793
これはr1796が関係しています。
r1796のパッチで
HAVE_LAVF ? "/libavformat" : ""

HAVE_FFMS ? "/ffmpegsource" : ""
などを使用していますが、これがエラーを吐くことから発見されたもの。
configureが中途半端なために起こるものだったので、これを修正したのがr1793です。
詳細はコミットメッセージを読んでください(僕が書きましたw)。
ちなみに最初は僕が修正して#x264devに提出して、D_S氏にokを貰ったのですが、
ラスボスのペンギン様に「if/elseが多すぎる」とドリルくちばしを喰らってお流れに。
修正しようと思ったら既にkemuri氏が素早くcoolに直してしまっていました(笑)
コミットメッセージが僕のになってるのはそういう経緯です。

次はr1796
libswscale/libavformat/ffmpegsourceのバージョン、ライセンス表示のパッチです。
バージョン情報についてはぶっちゃけそれほど役に立たない疑惑がありますが…(笑)
あったらあったで便利かなと。
実はこのパッチ、最初は#x264devに提出するつもりではなかったのですよね。
自分が欲しかっただけで、需要があるとも思えなかったので。
ただ、どうせなのでライセンス表示も弄ろうとしたら、意外な発見をすることに。
./configureのとき、--disable-lavf、--disable-swscale、--disable-ffmsが選択可能です。
libavformatとffmpegsourceはどちらもlibswscaleを必要とします。
なので、./configureを走らせるときに、--disable-swscaleを有効にした場合は、
自動的にlibavformatとffmpegsourceも無効になります。
一方libswscaleはlibavformatを必要とはしないので、--disable-lavfを有効にしても
libswscaleは無効にはなりません。
実際にlibavformatが無効でも、--vfのresizeフィルターでlibswscaleが使用されます。
しかし修正前のx264は、lavf=yesかどうかでライセンスの表示の有無を判断していました。
以上の問題があったので、これを修正してライセンス表記を正確にしたのがこのパッチ。
libswscaleのみ使用している場合は
libswscale license: ***
libswscaleとlibavformatの2つを使用している場合は
libswscale/libavformat license: ***
libswscaleとlibavformatとffmpegsourceの3つを使用している場合は
libswscale/libavformat/ffmpegsource license: ***
 などのような感じに表示されるようになっています。

次にr1797
これは僕が提出したr1793に相当するはずだったパッチでに含まれていたものですが、
kemuri氏のパッチに置き換わったので、その分を補完する形になったものです。
上にも書いたようにswscaleが無効ならlavfもffmsもyesかどうか判断する必要はありません。
後半のlavf、swscale、ffmpegsourceの部分が肝心の内容ですが、
統一されていないインデントが気になったのでついでにそれも修正しました。

最後にr1802
実はこれ、僕のパッチが形を変えてコミットされたものです(笑)
[x264] Disable Duplication in Weighted Prediction for P-frames [patch]
新しい--weightp 1は、僕のパッチの--weightp 2 + --no-weightp-dupに相当します。
Blu-rayやPSPやCoreAVC(1系)やFlashPlayer(10.0系)での再生を考えるなら、
--weightp 2ではなく--weightp 1を使えば今後デコードが壊れなくなるはずです。

以上、僕が関わったコミットに関する簡単な説明でした。
ビルドはまた今度。

Monday, November 22, 2010

[MacOSX] x264 binary revision 1788 (patched) [64bit]



Print-video-info-when-lavf-ffms-inputをちょっとだけ更新。
 rawvideoのときに、--demuxer ffms を使うようwarning出すようにしました。

Friday, November 19, 2010

[Vim] .vimrcと.gvimrcのメモ [MacVim]

Vimをちょっぴりカスタマイズ。
例によって備忘録。
.gvimrcの方はMacVim専用にしてあるけど、Windows等もほぼ一緒の設定でいけるはず。
一部設定は.vimrcではなく.gvimrcに書かないと反映されないので注意。

Thursday, November 18, 2010

[Vim] .vimrcと.gvimrcのメモ [MacVim]

Vimをちょっぴりカスタマイズ。
例によって備忘録。
.gvimrcの方はMacVim専用にしてあるけど、Windows等もほぼ一緒の設定でいけるはず。
一部設定は.vimrcではなく.gvimrcに書かないと反映されないので注意。


Tuesday, November 16, 2010

[雑談] 5x3≠3x5 [悪しき教育]

なんかさっきツイッターで流れてきたんですけど、なんともアホらしい…。
話題の元はこれ↓
そういえば掛け算にはそんなルールがあったな

これに限らないけど、なんで日本の教育は「答えは一つ」にしたがるのか。
算数の教育において、日本では「2+3=?」という形式がほとんど。
欧米の教育では、逆らしい。
つまり、「5=?+?」という聞き方。
もちろん、1+4、2+3、3+2、4+1など、全てがマル。
もしかしたら、ちょっとしたマセガキは「-2+7」なんて答えるかもしれない。
それだって立派な「正解」。
ある生徒が「1+4」と答えても、別の生徒が「2+3でもいい」と答える。
そういう教育の方が楽しいじゃない。
教える方の体力は必要だろうけどさ。
意見まとめるの大変だろうし、答えが一つの方が教えてて楽だろうし。
でも一つの物事を多角的な観点から見る力って、こういう教育の中で育つのだと思う。

お釣りの計算だって、国によって違う。
例えばこれ↓
イタリアと日本のお釣りの支払い方の違い?!

ねえ、これもどちらかが「間違い」なの?

Sunday, November 14, 2010

[Firefox] BarTabアドオンが素晴らしい

少し前にSafariを快適にする記事を書きましたが、今日Safariを使うのを止めました(笑)
理由はBarTabという素晴らしいFirefoxのアドオンを見つけたからです。

僕は再起動をよくするので、再起動の度に前回のセッションで開いておいたタブを一度に
全て読み込むのは結構負担になるし、操作可能になるまでの時間が勿体無い。
このBarTabをインストールしておけば、最低限のタブのみ読み込んで起動してくれます。
メモリ消費も抑えてくれるし、起動後から操作可能になるまで時間がかなり短縮されます。

一番うれしいのは一定時間閲覧しないまま経過したタブを自動で待機にしてくれること。
僕は30秒操作しないタブを自動で待機するように設定しました。
メモリ節約メモリ節約…。
この機能で気をつけて欲しいのは、待機させたくないサイトをきちんと設定すること。
例えば読み込み後に一定時間経たないとリンクが現われないサイトなど。
リンクが出る前に待機モードになってしまうと、また最初からやり直しになります。
アップローダなどにはそのようなものが結構ありますね。
他にも日記を書いていたのに他の作業やっていたら待機モードになって消えた!とか(笑)
(実はこの記事を書くときにも勝手に待機になってしまって書いた内容が消えた…w)
他にも定期的にアクセスするサイトなども除外しておいたほうがいいかな。
GoogleReaderやGmailを利用している人はwww.google.co.jpをリストに入れておきましょう。
(正規表現は使えないのかしらん…orz)

それにしても素晴らしいアドオン…。
常時200MB前後しかメモリを消費しない…。

[MacOSX] x264 binary revision 1772 (patched) [64bit]



Add-no-weightp-dup-optionパッチもちょっとだけ更新。

[Firefox] BarTabアドオンが素晴らしい

少し前にSafariを快適にする記事を書きましたが、今日Safariを使うのを止めました(笑)
理由はBarTabという素晴らしいFirefoxのアドオンを見つけたからです。

僕は再起動をよくするので、再起動の度に前回のセッションで開いておいたタブを一度に
全て読み込むのは結構負担になるし、操作可能になるまでの時間が勿体無い。
このBarTabをインストールしておけば、最低限のタブのみ読み込んで起動してくれます。
メモリ消費も抑えてくれるし、起動後から操作可能になるまで時間がかなり短縮されます。

一番うれしいのは一定時間閲覧しないまま経過したタブを自動で待機にしてくれること。
僕は30秒操作しないタブを自動で待機するように設定しました。
メモリ節約メモリ節約…。
この機能で気をつけて欲しいのは、待機させたくないサイトをきちんと設定すること。
例えば読み込み後に一定時間経たないとリンクが現われないサイトなど。
リンクが出る前に待機モードになってしまうと、また最初からやり直しになります。
アップローダなどにはそのようなものが結構ありますね。
他にも日記を書いていたのに他の作業やっていたら待機モードになって消えた!とか(笑)
(実はこの記事を書くときにも勝手に待機になってしまって書いた内容が消えた…w)
他にも定期的にアクセスするサイトなども除外しておいたほうがいいかな。
GoogleReaderやGmailを利用している人はwww.google.co.jpをリストに入れておきましょう。
(正規表現は使えないのかしらん…orz)


それにしても素晴らしいアドオン…。
常時200MB前後しかメモリを消費しない…。

Saturday, November 13, 2010

[MacOSX] x264 binary revision 1766 (patched) [64bit]



[x264] Disable Duplication in Weighted Prediction for P-frames [patch]

ここ数日weightp関連のコードをずっと眺めていました。
それで一つパッチを書きましたので、こっそり公開。
おそらくある程度の需要はあると思うし、自分も今後使っていくつもりです。
ただこのパッチ、#x264devにおいてDark_Shikari氏にrejectされたパッチです。
(というかrejectされてコミットされないから自分のブログで公開してるんですけどね…w)
有用性と危険性をきちんと理解した上で自己責任で使用してください。

patch -> here

ことの発端はこの記事
Leopardのときは本当に意味不明な挙動で何が原因かサッパリわからなかったのですが、
SnowLeopardにOSを更新してからやっと不具合の出る原因にパターンが見え始めました。
(OSと一緒にQuickTime Player のバージョンも上がっています)
どうやらx264でエンコードするときに
--ref 15 & --weightp 2 または --ref 16 & --weightp 1 または --ref 16 & --weightp 2
のいずれかを指定するときちんとデコードできない動画ができあがるらしい。
(つまり ref + weightp > 16 のときにデコードがおかしくなる)

それでweightp関連のコードを読み始めたんですが、encoder/encoder.c:1418の
int x264_weighted_reference_duplicate( x264_t *h, int i_ref, const x264_weight_t *w )
以下処理が絡んでいるみたいなんですね。

それでこの処理を丸々無効にするオプション"--no-weightp-dup"を作ってみました。
そのパッチがこれ
パッチを覗いてもらえればわかると思いますけど、実装方法は至ってシンプルです。


まず、このパッチの有用性は何かと言うと、

  1. weightpを使った動画だとデコードがぶっ壊れたデコーダでもデコード可能になる
    (例えばCoreAVCのバージョン1系、FlashPlayerのバージョン10.0系など)
  2. refに制限があるハードを対象にしたエンコードにおいてweightpの選択肢が増える
    (例えばPlayStation Portableなど)
  3. weightpを使用しないよりはフェードが改善する
    (Duplicationを行なった場合ほどではないですが)
  4. weightpを使用したエンコードにおいてエンコード速度上がる
    (特に --weightp 2 の場合はDuplicationありに比べて速度向上が大きいです)

おそらく一番大きな影響は1番目ですかね。
知人の協力も得て、古いCoreAVCとFlashPlayerで再生可能なことを確認しています。
Dark_Shikari氏のこの記事で批判されている一連のデコーダですね…(笑)
次に2番目の件ですが、例えばPSPにおいてはこのような報告が出ていますが、
(どうやら、PSPは ref + weightp > 3 になると駄目みたい)
このパッチを使うと--ref 3 & --weightp 2 などのエンコードができるようになるはずです。
PSP持ってないのでこちらは確認できていないですが、たぶん大丈夫だと思います(笑)
3番目と4番目の説明は略。
興味がある方はご自分でエンコードして確認してみてください。
エンコードされた動画をバイナリエディタやMediaInfoで見てみると、
今までweightp=2などと書き込まれていた部分が、weightp=2:1などになっているはずです。
Duplicationが有効だと:1が付き、無効だと:0が付きます。


次に、このパッチが蹴られた理由は何かと言うと、

  1. デコードが壊れるのが嫌なら--weightp 0 を使えばいい
    (実際に人達はそうしている)
  2. Duplicationを使う方がフェードの質が上がる
    (そもそも質を上げるためにこんな処理をしている)
  3. 不正確な実装のデコーダを助長してしまう
    (不正確な実装のデコーダでもデコードできてしまうので)

以上がコミットされない大きな理由です。
他にもk-means(--weightp 3として実装予定かつ実装未定のもの)でDuplicationが有用とか、
mbaffとの関わりでとか、いろいろ理由があるらしいです。
そんなこんなで、"I reject this patch on principle"と言われました(笑)


ですが。
個人的には--weightp 0よりは --no-weightp-dup & --weightp > 0 の方が質は上がってると思うし、
PSP用エンコは現状 --ref 1 & --weightp 2 か --ref 2 & --weightp 1 しかweightpの選択肢がないし、
k-meansはいつ実装されるかサッパリだし(肝心のdylan氏が行方不明)、
mbaffとか自分にとっては関係ないし…。
などの理由で今後も使うことにしました。
デフォルトではDuplicationをきちんと行いますし、現状ではそこまで悪影響はないかと。
今後公開していくバイナリでもこのパッチを当てていくつもりです。
もし今後weightpの実装が変わり、このパッチがcriticalな影響を及ぼす危険があったら、
そのときはすぐに使用を止めればいいだけかなと。



例えばニコニコ動画など、限られたビットレートで画質を維持しないといけない上に
FlashPlayerを全員が最新にしているとは限らない、という場で結構使えるんじゃないかな。
他には、CoreAVCで見たいけどバージョン更新するお金がない人とか…?
あと、Blu-ray Disc用エンコードでは現在 --weightp 0 が推奨となっているらしいですが、
もしかしたらこのパッチでweightpが使えるようになるかもしれないとかそうじゃないとか。
まあどの層に需要があるかはまだハッキリしませんが、役に立てたらうれしいです(笑)



なお、今回の件でも普段からお世話になっている方々にテストなどでお世話になりました。
Special thanks for boiled_sugar, Chikuzen, and  JEEB.

[x264] Disable Duplication in Weighted Prediction for P-frames [patch]

ここ数日weightp関連のコードをずっと眺めていました。
それで一つパッチを書きましたので、こっそり公開。
おそらくある程度の需要はあると思うし、自分も今後使っていくつもりです。
ただこのパッチ、#x264devにおいてDark_Shikari氏にrejectされたパッチです。
(というかrejectされてコミットされないから自分のブログで公開してるんですけどね…w)
有用性と危険性をきちんと理解した上で自己責任で使用してください。

patch -> here