(This article is English translation of Japanese version)
I am working on adding simple interframe compression to UMxx. Because this interframe compression is not effective for the clips that are made in part 1 and part 2, we need other clips.
Read the rest of this entry
macOS 10.13 High Sierra の次のベータで 32bit アプリ起動時に警告が出るようになったそうで。以前から「High Sierra は 32bit アプリを『妥協無しに (without compromise)』サポートする最後の macOS である」とはアナウンスされていましたが、実際にそういう挙動になってきたということになります。
『妥協無しに』がどういう意味合いなのか分からないので 10.14 以降でどうなるのか（完全に動かなくなるのか、最適化レベルが下がる程度なのか、とか）判然としないのですが、私としては QuickTime がどうなるのか気になります。QuickTime は 32bit のフレームワークだからです。64bit のプロセスからはプロセス間通信を経由して使うようになっています。
まさか QuickTime のためだけに 32bit プロセスを動かす機能を維持するとも思えない（そもそも QuickTime は macOS SDK から削除されている）ので、10.14 か遅くとも 10.15 あたりで 32bit サポートと一緒に QuickTime も消滅するのでしょう。
今頃 iMovie をバージョン 9 （正確なバージョンは忘れた）からバージョン 10.1.8 にアップデートしたんですが、バージョン 10 以降では動画を出力する際に任意の QuickTime の映像コーデックを使うことができなくなってるようです。mp4 （たぶん中身は H.264）か ProRes だけ。読み込みはできるっぽい（ちゃんと検証してない）。
普通の使い方なら別に何の問題もないんですが、私は自分の映像コーデックのテストに使ってるので何もできなくなってしまいました。というわけでフリーでちゃんとメンテナンスされていて任意の QuickTime の映像コーデックを使える編集ソフトないですか。（必ずしも編集できる必要はないんだけど）
現在の Ut Video Codec Suite の圧縮はハフマン符号によって行っているのですが、ハフマン符号だと命令レベルの並列性が低いとかSIMDにやさしくないとかの問題があり、性能は頭打ちとなっています。
ここしばらくSIMDにやさしいアルゴリズムを考えていて、ある程度実装した結果まあまあ満足できる性能を達成できることが分かったので、これを正式に実装しようと考えています。実装した結果は github で見れます。
実際の性能ですが、2k/RGB24 の crowd_run （ここで使っているもの）で圧縮比 1.74、 i7-2600K でエンコード 95fps デコード 150fps、 i7-4770 で 180fps/300fps 程度です（シングルスレッド時）。AMV4 DR3 と比較して圧縮比は少し高く、処理速度は少し低いという感じになります。なお、 AMV4 は時間方向に圧縮する機能があって変化の少ない映像だと高い圧縮比を達成できますが、UtVideo の方では future works ということにしたいと思います（効率よく処理する手法を思い付けていない）。
AVI を再生しようとした時に Huffyuv と UtVideo とで挙動（というか、出てくる media type の形態）が違う点について調べていたのですが、 avidemux element が FourCC に応じて自分で設定している、つまり「コンテナを処理するコードがコーデックごとに処理を変えている」ようだ、ということが分かりました。 FourCC が HFYU の場合は「知っている」ので video/x-huffyuv になり、 ULRG の場合は「知らない」ので video/x-avi-unknown; fourcc=(int)0x47524C55 になります。
Read the rest of this entry