或るプログラマの一生

2017年08月にいただいた寄付は以下の3件です。ありがとうございました。

バグ修正

• 一度 ICDecompressBegin に失敗すると、それ以降のファイルでデコードしようとしなくなっていた。

その他

• 十分に -q オプションが指定されている時に ICDecompressBegin が失敗した場合、エラー表示するのではなく結果のデコード速度でハイフンを表示するようにした。

2017年07月にいただいた寄付は以下の2件です。ありがとうございました。

なお、2017年06月には寄付はありませんでした。

(This article is English translation of Japanese version)

I found that the video clips that I generated are not compressed very much. The compression ratio is 1.06 in case of AMV4/DR2. I think it is not good and have to search other clips.

クリップを作ってみたけど圧縮してみたら全然圧縮できないことに気づいたわけです。ちなみにこのあと AMV4 の DR2 で圧縮してみたら圧縮比 1.06 になってしまい、いやこれはさすがにダメでしょと思い、ちゃんと圧縮できるクリップを別途用意することにしました。圧縮できないクリップもそれはそれで計測価値があるので crowd_run も使います。

先日の記事で作った4Kのクリップをザックリ圧縮してみました。

その他

• UQxx: フレーム分割数のデフォルトが論理プロセッサ数と同じになるようにした。

「寄付について」ページで、「直接渡し」「WebMoney or Amazon.co.jp ギフト券」での受け取りについて明記しました。

増やした、というのは必ずしも正確ではなく、受け付けることを明示した、なのですけど。

(This article is English translation of Japanese version)

I use full HD video clips to benchmark Ut Video Codec Suite and other video codecs. When I began to benchmark codecs, using full HD video clips is a reasonable choice. However, measurement error is not ignorable nowadays because recent codecs including UtVideo are very fast and they take only 1ms to process one frame in case of YUV420. Because so, I’m planning to switch to 4K video clips. (The author of MagicYUV also advised me to do so)

現状、 Ut Video Codec Suite などの性能測定にはフルHDのクリップを使っています。使い始めた頃はこれでよかったのですが、UtVideo 自身の高速化や他の高速なコーデック（具体的には MagicYUV）の登場により1フレームを処理する時間が内部形式によっては1msを切る時代になり、そろそろ計測誤差を無視することができなくなってきました。そのため、次は4Kのクリップを使おうと考えています。（というか、MagicYUV の作者にそうすることを勧められた）