High-bit-depth AVCデコーダ

この度、ついに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

ふわふわさん part2

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

カワイソス

Console2

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とか狭い画面で複数の端末を操作する必要がある人にはお奨めですね。
あとは背景とかも設定できるのでいろいろいじってみるのもいいかも。

regression test

#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パターンか。

Spamming Dutchman

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のバイナリを使ってください。

ふわふわさん

某月某日某所にて
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ってのは、自分のことなのだな…

L-SMASH

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

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

接触事故？

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