265を試そう

もうそろそろx265を試してみてもいいかもしれない、と思い始めたので試してみました。

ほぼx264互換だろ、とか思ってたらいろんなところにはまったのでメモ。
・--demuxerオプションがなくなって、--y4mに変わってたってか入力がYUVかY4Mしかない
→オプションを変えるだけ

・mp4出力に対応していない
→mp4という拡張子を付けても出来上がるのは.h265なので、mp4boxで取り込む

・--tcfileinに対応しない(raw出力だし)
→仕方がないのでtc2mp4とかを使ってmp4boxでのインポート時にタイムコードを付加(予定)

・使ってたmp4boxが(古いから)hevc/h265に対応していない
→新しいのを使う

・新しい(0.70)mp4boxに放り込んだら大量に「Error parsing slice header: byte_align not found at end of header !」と言われる
→https://github.com/gpac/gpac/issues/801によるとrev3以降ではで治ったらしい。ってかgpacのdlページにある070rev0は安定最新版ではないのか・・・仕方がないので0.72DEV最新版(rev357)にする

・mp4boxを0.72DEVにしたら、最近(ここ5年ぐらい？)のmp4boxは既存ファイルを上書きしないようになってる(から昔のを使い続けていたのですが)のが、いつの間にか治っていたと喜ぶ
mp4boxからunicodeで吐かれてたファイル名がちゃんと表示されるようになったのを鑑みると、ようやくunicode絡みのfilehandlingが治ったのでは？という想像(変更履歴とか確認してません)
と、思ったところ、I/O errorは出なくなったけど、代わりに-outオプションを受け付けなくなっている・・・？もしくはsjisで入力するのがいけないのかもしれませんが。
あとcmdの標準出力の変数を弄っているのかなんかで、mp4boxを使った後のコンソールで日本語がおかしくなる。
具体的には
echo "%SOURCE%.h265" >>"%LOGFILE%"
%mp4box% -add "%SOURCE%.h265" "%SOURCE%.mp4"
echo "%SOURCE%.h265" >>"%LOGFILE%"
というコマンドを実行すると、mp4boxの後のechoでは%SOURCE%から吐き出される2byte文字が化ける(おそらくutf8を吐いてる)
chcpをしても932と帰ってくるのに、chcp 932と打ちなおすと治る
→捜したところ、videohelpに0.70.rev27があったので、それを使えばいいんじゃね？結局unicode絡みのは治ってないけど。



・そして、なぜかmediumよりもslowの方がサイズがでかい。倍の時間かかってるのに・・・(以下はavsでフィルタかけてるのでエンコーダだけの速度ではないですが)
-D 8 --crf 20 --preset fast ：encoded 2867 frames in 253.06s (11.33 fps), 3029.28 kb/s, Avg QP:21.97
-D 8 --crf 20 --preset medium：encoded 2867 frames in 303.84s (9.44 fps), 2831.89 kb/s, Avg QP:22.07
-D 8 --crf 20 --preset slow ：encoded 2867 frames in 486.78s (5.89 fps), 2926.29 kb/s, Avg QP:21.93

-D 10 --crf 20 --preset medium：encoded 2867 frames in 340.40s (8.42 fps), 2883.66 kb/s, Avg QP:21.40
-D 10 --crf 20 --preset slow ：encoded 2867 frames in 699.76s (4.10 fps), 3106.87 kb/s, Avg QP:21.42

まぁ、h265の利点は高ビットレートがキレイ、というよりは低ビットレートでも破綻が少なく「そこそこ見れる」ように圧縮ができることと思っているので、いままでcrf28位までだな、と思っていたのをもっと大きくしてみましょう。ってかcrfではなくbitrateでもいいのかな。ツールとか。

・tc2mp4modだとタイムコードの変換がうまくいかない・・・
cfrじゃないとか言われるが、mukenさんがソースを公開していないみたいなので言っている意味が分からない(「ソースが汚いから公開しないぜ！」と言っていたみたいw)。
zmiさんが作っている元のperlのを解析するしかないのか・・・

とりあえず01/24/2007版のperlで、
2か所「.*\/>」となっているのを「.*>」に直した(/っていらなくね？という)ら一応変換してくれるようになった。・・・が、出来上がったmp4のシークがおかしい・・・何故だ・・・

→上手く動かないのはmp4boxが新しいから。吐き出すnhmlがちょっと変わってる。あと、シークができないのはmp4boxの仕様？0.51,0.52,0.62,0.70,0.72のいずれのバージョンでも
あるh265に対して
mp4box -add temp.h265  -new test.mp4
mp4box -nhml 1 test.mp4
mp4box -add test.nhml -new test1.mp4
とやるとシークできない(キーフレームがないような挙動を示して時間がかかる)test1.mp4が出来上がる。
はて？
というわけで、
https://gpac.wp.imt.fr/mp4box/media-import/nhml-format/
を読んでみます・・・isRAPが怪しい気がする・・・

→上記のnhmlをエクスポートしてそこからmp4を再構成するとシークができないやつ、nhntなら問題なさそうです。
・・・nhntをバイナリで弄るスクリプトに変更するのか、その他の方法を考えるのか・・・というかnhmlとnhntで何の情報が異なるのかを確認すればいいのかな。

→というかmp4boxの仕様なのでgithubで質問したら、24時間立たずに修正されたコードがリリースされた(0.7.2.rev359)。
どうもnhntが正しく働いていたわけではなく、isRAPフラグが1bitしかないため、本当は立てるべきではない時？(OpenGOPの場合)でも立てていた、というのが正解なのかな？
修正後はnhmlでisRAPの代わりにSAPTypeというのが追加されて、Pフレームの時にはそれが立つ(3になる)ような感じになってた。


が、なぜか日本語のファイルの扱いが微妙・・？気のせいかもしれませんが、もうちょっと確認してみます
ワイドキャラクタに対するファイルの扱いが↓の辺で治った・・・のかと思いきや、現在の最新でも日本語のファイル名を入力とした場合に変になることが・・・
https://github.com/gpac/gpac/issues/883
https://github.com/gpac/gpac/pull/919
例えば、
mp4box.exe -add tc.nhml test.mp4
はせいこうするものの、
mp4box.exe -add てすと.nhml test.mp4
は失敗します。(2つのnhmlのファイルの中身は全く同じです)