C++ でも最近はスマートポインタが使えるわけですが、 std::shared_ptr を作る関数である std::make_shared が IDE の静的解析と相性が悪くて辛みを感じています。(とりあえず CLion での挙動ですが、 VS でも同じような感じじゃないかなぁ…)

  • std::make_shared<Hoge>( とまで打った時に出てくる引数サジェストが Args&&... になってて全く役に立たない。 Hoge クラスのコンストラクタから情報を引っ張ってきてほしい。ついでに言うと引数間違えてても IDE からは警告が出ない(コンパイルして初めて間違っていることが分かる)。
  • Hoge クラスのコンストラクタを右クリックして呼び出し元を検索しても出てこず、よくよく考えたら make_shared 経由なので自分で書いたコードからは直接呼ばれてなかった。make_shared を書いた位置がヒットしてほしい。

make_shared に限らないし、根本的にはスマートポインタにも限らないし標準ライブラリにも限らないわけですが、何とかならんのですかねこれ。

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 の映像コーデックを使える編集ソフトないですか。(必ずしも編集できる必要はないんだけど)

機能追加
  • UMxx: QuickTime 版のエンコーダを追加した。
性能向上
  • UMxx: 全体的に高速化した。
バグ修正
  • ULxx: エンコーダに誤った設定をしてもエラーを返さなかった。

Read the rest of this entry

バージョン 19.0.1 で追加された UtVideo T2 (UMxx) ファミリの詳細などです。

Read the rest of this entry

機能追加
  • 速度を重視した新しいコーデック (FourCC: UMRA, UMRG, UMY4, UMY2, UMH4, UMH2) を追加した。QuickTime コンポーネントではデコードのみ。

Read the rest of this entry

1つのベクタレジスタ(たとえば __m128i のこと)を返すラムダはきれいにインライン展開される(つまり、妙な一時変数がメモリ上に取られたりしない)ことは分かっているんですが、複数のベクタレジスタを返す普通の(=ラムダではない)関数がインライン展開されるときはどうなのか、というのが気になりました。

Read the rest of this entry

std::tuple の要素アクセスで std::get はあっても std::set がないのはなんでだろうか、と思ってたんだけど、 std::get は参照を返すのでそこに代入すればそれでいい、ということに気づいた。

あと std::set はコンテナクラスである…

現在の 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 ということにしたいと思います(効率よく処理する手法を思い付けていない)。

そういや C++ で算術右シフト (arithmetic right shift) するにはどう書けばいいんだろう、 intrinsic ないよなぁ…と思ってたんですが、「ほとんどのコンパイラでは」符号付き整数を右シフトすれば算術右シフトになるようです。

ただ、(負の)符号付き整数を右シフトした時の動作は処理系定義なので、論理右シフトになる処理系をうっかり踏むかもしれません。以下のような static_assert を書いておけば安心でしょう。

static_assert(-1 >> 1 == -1, "signed right shift is not arithmetic.");

ちなみに負の整数をシフトした場合は未定義動作らしいです。怖い。