或るプログラマの一生

BSDソケットインターフェースの話ですが。

ファイルディスクリプタをノンブロッキングに設定すると、読めるデータがない（受信バッファにデータがない）場合は read() / recv() から -1 が返ってきて、errno が EAGAIN に設定されます。一方これとは別に、ソケットに対して recv() する場合、第4引数（フラグ）に MSG_WAITALL を指定すると、第3引数で指定した分だけ読めるまで返ってきません（基本的には）。

Premiere Pro 以外でも試してみました。具体的には、Adobe After Effects CS5、Thomson-Canopus EDIUS Pro 6、Sony Vegas Pro 10 です。すべて Windows 版。

試してみたんですが、どれも汎用 AVI 出力する際にコーデックに 8bit を超える色深度で渡そうとしないようです。Vegas に至ってはそもそも外部コーデックを使う方法が分かりません（だれか教えて…）。それぞれの独自の出力プラグインを経由して 8bit を超える色深度で渡すことはできるようですが、汎用のインターフェースではどうやらできないように見えます（QuickTime だとどうなるかは不明）。Vegas なんか出力プラグインを追加できるかどうかすら分かりませんでした。

汎用インターフェースが存在してそれを使ってくれるようであれば、それに沿ったコーデックを書けばおしまい（8bit 色深度では VCM インターフェースがこれに相当する）ですが、編集ソフトごとに出力プラグインを書くとなるとかなり大変なことになります。ソフト全部集めてこなきゃいけないし。

ちくしょー

一応、技術的興味はあるので、仮想環境内に Pr CS5 の体験版をインストールして、Pr が VCM コーデックに対してどんなエンコード入力フォーマットをチェックしてくるかを見てみたのですが、Premiere Elements と同様、8/16/24/32bit RGB しかチェックしてきません。アカンがな…

ひょっとして QuickTime 経由じゃないと RGB 以外のフォーマットをコーデックに渡すことができない？

Premiere Elements 4 を買ってから3年近くたつのですが、10bit YUV 4:2:2 出力に対応していることに今頃気づきました…というか忘れてました。出力すると FourCC v210 になるみたいです。

大体残念な回答になっていますが。

Vegas Movie Studio HD Platinum 10.0 （以下 Vegas）で Ut Video Codec Suite でエンコードされた映像を素材として使っているとかなり落ちやすい、という報告を受けました。

体験版で試したところ確かに落ちるんですが、デバッガで一般保護例外を捕まえられません。Vegas はマネージドコードで動いているようなのですが、最初はマネージドコードとしてアタッチしてしまって utvideo.dll すら見えないという状態でした。これはネイティブコードとしてデバッグするように明示したらとりあえず utvideo.dll が見えるようになったのでこれに関してはOK。しかし落ちてもデバッガで例外を捕まえることができず、Vegas が内蔵しているエラーリポート機能が起動してしまいます。ブレークポイントを設定すると止めることはできますが、秘孔を突いて1発で落ちるような問題ではないので、これでは意味がありません。

これではデバッグができない…

ここしばらくは Range Coder と格闘していましたが、結果として Lagarith より圧縮率がちょっと（2%ぐらい）良くて、エンコード速度がちょっと速い（シングルスレッドの場合）ものが作れそうだ、という技術的検証まではできました（デコード処理は書いてないので不明）。まあ、Lagarith のアルゴリズムをほんのちょっとだけ改良しただけなのでこんなもんでしょう。アルゴリズムに新規性が無いのは昔からなのでその点は気にしないことにします。

いつものように twitter を眺めていたら、sizeof(a++) という摩訶不思議な式が。

いやまあ、sizeof の中に型名だけでなく変数名や構造体のメンバ名も書けることは知っているわけです。たとえば以下のように。

Ut Video Codec Suite は、開発初期の目標はともかくとして、「そこそこの圧縮率でかなりの速度の編集用コーデック」という方向にバージョンアップを重ねています。「かなりの速度」という点に関しては、アルゴリズムレベルや実装（アセンブラ）レベルでの継続的な改良により、満足できるレベルを達成できていると思っています。

性能向上

• 共通: x86 でのデコードを 10% ほど高速化した。
• 共通: x64 版をアセンブラ化し、おおむね x86 版と同程度の速度にした。