ﾚﾝﾀﾙDVDをﾋﾞﾃﾞｵのようにﾀﾞﾋﾞﾝｸﾞしたい

さてと、お仕事がお忙しいみたいで説明してくれないようなので、
トランスコード圧縮について僭越ながら説明するかな。以下3レス連投。

「Bフレーム」自体が間引かれてしまっては、元々のGOP構造自体が成立しないから。
「Bフレームを間引く」のではなく「Bフレームの『データ』を間引く」という表現であれば
まだ不正確ではあっても意味は通じるし、馬鹿が説明しているサイト以外では「今は」
そう説明してる。

初心者に説明する場合でも「フレームを間引く」とは言わないで「データを間引く」と言おうねｗ
（最初の頃は「Bフレームを間引くから、GOPがIBBPなら原理的に50%まで圧縮できる」なんて
　説明をしていた商用記事もあったけどねｗ）
http://www.mediachance.com/cowboywho/compiling_and_testing.htm と
http://arena.nikkeibp.co.jp/rev/soft/20031021/106295/ の違いは判る？

DVD Shrinkの初期の頃もDVD2Oneも、全てのトランスコード圧縮の基本としては、
前後予測によりフレームを構成する「Bフレーム」が、最近のプレイヤーの
デコードエンジンに対しては冗長に「データ」を保持していることに着目して、
時間軸方向（フレーム間での）離散コサイン変換の量子化パラメータを変えることで
劣化を少なく圧縮しているわけ。

そのため他のフレームについて再計算することなく高速に圧縮可能なわけだが、
「冗長」だとの判断は実装した作者にしか判らないところなんだけど、
必要以上にデータを削った結果、ブロックノイズが発生してしまう。
実装についてはShrinkTo5の1.7がソース公開されているのでそれを読めばわかるかと。
（ShrinkTo5の実利用は勧めない･･･特に2.0になってAd-wareがついてきてるからなおさら）

現在のDVD Shrinkでは、離散コサイン変換のパラメータ変更をしている点については同じだが
I/Pフレームについても「空間圧縮」しているので（基準フレームの圧縮＝JPEGと同じ）
連続する同じGOP内のフレームについてエラー保障をした方が良い（ShrinkのAEC）。
それでも逆離散コサイン変換時の差分計算でおかしい点についてだけの修正で済むので、
まあ、エンコードよりは全然早い。
（ICが先にその方向性を示した。D2Oはそちらに行かず速度とビットレート配分の強調に向かった）

ただし、静止画（基準フレーム）の圧縮については、モスキートノイズなどの原因となるため、
静止画比較においてD2O＞Shrinkの評価が出てしまいがち。実際は動画で判断しないといけないから、
どちらが良いとも言えないんだけどね。

離散コサイン変換とMPEG圧縮の関係については
http://laputa.cs.shinshu-u.ac.jp/~yizawa/InfSys1/advanced/image_cod/index.htm
が、判りやすいかな。

参考までに「Mpeg4 AVC(H.264) Main」のフレーム内予測と整数変換の技術についても
抑えておけば、よりMpeg2の圧縮方式についても理解が深まると思われる。