H.264動画では、暗部や青色部分のブロック感(もやもやざわざわ動いている感じ)が気になるというのは、昔から知られていて、
x264 HAQ (Haali Adaptive Quantization parameter)のような対策が打ち出されているわけですが、そもそもどうしてざわざわしてしまうのでしょう。実はQPを変えるだけでは対策になってないかもしれない、そう思っていろいろ調べてみました。
そのものずばりの情報は得られなかったので、とりあえず推測を幾つか挙げてみます。
リンク: https://www.find-job.net/fj/show_job.pl?id=66851
今、うちの会社でWebサイトを作るエンジニア、Webのサービスを作るエンジニアを「たくさん」募集しています。アルバイト的にお手伝いいただける学生さんも大歓迎です。
詳しくはFind Job!さんの求人ページをご覧ください。
⇒ 新設Webシステム開発部門 オープニングスタッフ大募集! Perl,MySQL,PHP,JavaScript
VAQ (Variance-based Adaptive QP) の趣旨は「のっぺりしたところからビットレートを取り上げてファイルサイズを減らしましょう」で、 HAQ (Haali Adaptive QP)は「(x264の尺度で)同じ平坦に見えても、暗い部分はブロックが目立つので、逆にビットレートを割きましょう」と、実は 目的がかなり違う。
VAQでもHAQでも問題になっているのは、
QPを調整する対象ブロックを選ぶ尺度が、まだ人間の感覚と一致していないこと。暗部のブロック感を抑えようとするとQP調整の対象を広げることになって、全体を低いQPでエンコするのと変わらなくなったりする。
⇒ seraphy氏による詳しい解説
そこでseraphy氏は、QPの調整対象を自己流の尺度で選ぶようにした「OreAQ」を開発。
⇒ ここの「x264OreAQ.***.release**.rar」がコンパイル済の実行ファイル。
Charlieも早速使ってみた。
IT業における生産性は人によって20倍違うという説を聞いたことがありますが、この調査で言われている「労働生産性」はそういう属人的な能力の尺度ではなくて、単金とか人月単価とか呼ばれているものを言い替えたもののようです。
Flash Blockerのせいで、クリップボードへのコピーができないFx環境のための苦肉の策。 標準環境の人はFirefoxでタイトルとURLと選択文字列をクリップボードにコピーするbookmarklet @ saĉja TTT-protokoloを使った方が楽です。
x264 Core56 Sharktooth版でエンコードした結果のファイルとCore58 Dark Shikari版のファイルとをmkvmergeで結合したところ、後ろに結合したDark Shikari版の部分の表示がおかしくなった (MPC + CoreAVC or ffdshow)。
パンする部分で16x16ブロックくらいの大きさでところどころ位置が数ドットずれる。 結合前のファイルでは症状が再現しないので、再生に必要なパラメータに互換性がなかったのだろう。結合するなら、エンコーダのビルドは一つに固定しておくのが無難だろう。
関連記事
星空を含む場合は--aq-*を使うとよいで書いたように、ブロックごとに最適な量子化パラメータを推定して、同じ容量で画質を改善する機能がx264の一部ビルドに試験的に実装されていましたが、3月末に公式に取り入れられました。
一方、公式のものより更に改良を進めたVAQ2.0の試験公開も始まっていて、 どのビルドでどの機能が使えて、パラメータはどうすれば良いのかが 分かりにくくなってきたので、簡略にまとめてみました。
このブログに「時空を超えて (ときをこえて) | II MIX ΔDELTA @ Charlie's volatile short」という記事があるのですがGoogleで検索すると何故か
( 時空を超えて)ときをこえて @ | II MIX ΔDELTA Charlie's volatile ...
というタイトルに。括弧と@の位置が変わってます。 HTMLのTITLE要素をそのまま記録せず、記号に対して何か処理を行なったものを記録しているように見えますね。仕様なのか意図せずそうなっているのか分かりませんが、またまた不思議ですね。
関連記事
(2008/03/04 03:55追記) 上記の検索例は現時点で正しくなっていました。特定の時期の処理に発生した現象で、クロールし直したら正しいデータで上書きされたのでしょうか? 他にも同じような状態のタイトルが幾つか残っています…
多くの人が言う「考えた」というのは、「考えようとした」のことらしい。 (略)ほんの一瞬だけ考えようとしたくらいで「考えた」なんて言わないでほしい。
本当に考えたの? @ MORI LOG ACADEMY
3年で1000個思いつき、100個作り、10個リリースして、1個のイノベーションを起こすこと。
僕のサイボウズラボでの仕事について @ 西尾泰和のはてなダイアリー
つまり、「考える」ということには以下の2段階があるということです。
- 小さなアウトプットを重ねて穴=自分が何がわかっていないかを可視化する
- 問題が穴埋め問題に変換できたところで最終的な解決を導き出す
たいていの人は問題はこうやって2段階で「考える」のだということを知りません。それで一気に最終的な解決案を導き出そうとして「できません」なんて言う。(略)
そういう人には「考える」って頭を使うことじゃなく手を使うことですよって言いたい。「考える」のは頭じゃなくて、目の前の紙と手の組み合わせなんだって。
Fw:本当に考えたの?(それは「考えた」と言わない。) @ DESIGN IT! w/LOVE
激しく同意。 手を動かして物を作ることは、アイディアを考えることの役に立つ。