『再エンコード』のクチコミ掲示板

よくＨＤからDVD-Rに焼く時の再エンコードによる画質劣化を気にする人がいますが、本当に劣化しているんでしょうか？

同じエンコードロジックで同じビットレートであればデジタルで扱っていれば劣化しないと思うのですがどうなんでしょう？

デコードしても圧縮のブロック単位がかわらなければ再エンコードしても同じなんじゃないかと思います。
なので　ＸＰ->ＳＰ　より　ＳＰ->ＳＰ　のが劣化が少ないと思っているのですが間違っているでしょうか？

書込番号：834038

[ideal]

同じビットレートでも再エンコードが伴うのであれば、劣化します。

同じロジックでエンコードする場合にも元が違うものであれば、エンコードの
結果が異なります。

MPEGによる圧縮は一般には非可逆圧縮です。
いま、ある画像Aをエンコードしたものを「再」エンコードすると、デコードに
よりAとは異なるA'に戻ります。これをエンコードしたものを視聴するときに
はさらにそれをデコードしてA''を見ることになります。

AとA'の差、A'とA''の差がいかほどかは別にしますと、原理的にはMPEG圧縮が
可逆でない限りにおいては、必ず劣化します。

元をXPモードで録画することは、SPモードで録画する場合に比べてAとA'との
差を縮められる可能性を求める行為でしょう。

> デジタルで扱っていれば劣化しない

とおっしゃる部分については、別の部分で正しくて、D/A変換やA/D変換に伴う
量子化ノイズが混入しない、ということでしょう。(MPEG圧縮するということ
は別の量子化があろうかとは思いますけれど。)

書込番号：834113

画像A,B,C,D,E,Fと続く場合をMPEG2圧縮を考えると

(1)AをIピクチャ化 -> A'
(2)A'とDで動き探索でベクトルV(A',D)を算出
(3)D-V(A',D)の差分をDCT->Q -> D''

A = A' + e1
D = D' + e2 e1,e2は圧縮誤差(残差）

これを再圧縮する事を考えたら

(4)A'をIピクチャ化 -> A''　
(5)A''とD'で動き探索でベクトルV(A'',D')を算出
(6)D'-V(A'',D')の差分をDCT->Q -> D''

A' = A'' + e3
D' = D'' + e4 e2,e3は圧縮誤差(残差）

(6)のDCT対象となるマクロブロックは

D'-V(A'',D') = D- e2 - V( A'-e3 , D- e2 )
= D- e2 - V( A-e3-e1 , D- e2 )

で仮にＩピクチャの再圧縮で残差が出ない(e3 = 0)と仮定しても

D'-V(A'',D') = D - e2 - V(A-e1 , D- e2)

(3)のDCT対象となるマクロブロックは

D-V'(A',D) = D - V( A- e1, D )

で (3) != (6) なんで(6)のDCT演算後の値は(3)の場合と異なる値と
なり、それを量子化(Q)すると新たに捨てられるデータが発生する。　

よって 、e4 は０にはならない。

よって、２回目のエンコードD''は1回目のエンコードD'より劣化する。

より綺麗に録画する為には、残差eを極力発生させないようにする。

＝＞　ＸＰの方が有利

こんな所でドウでしょう。

書込番号：834273

あと上記例でA->Dと進んでるのはGOP=IBBPBBBP・・・なんで

A,B,C,D,E,F,G・・・

は

A->D->B->C->G->E->F・・・

って順番にエンコードされるからです。

書込番号：834288

[Panasonicfan]

ＭＰＥＧやＪＰＥＧは、非可逆圧縮であることが特徴のようですが、
これって意図的にそういう風に作ったんですかね？

可逆圧縮だと　なにか　まずいのかしら？
という疑問を持ってしまいますね。

書込番号：836358

idealさん、まいむまいむさん　わかりやすい説明ありがとうございます。動きに関する圧縮は考えてませんでした(^^;

一応、私が劣化しないんじゃないかと思った理由を書きます。
動きは考えてなかったので一枚絵だと思って下さい。

まず不可逆圧縮ですが、不可逆圧縮であっても可逆圧縮になるポイントがあるのでは？これは極端な例をだすと真っ白な画像を何度も再エンコードしたからといって黒くならないのでは？という発想です。
Jpegの場合、特定のブロック内の色の平均から外れた色をならして（色数が減る）圧縮していたと思います。その時のブロックの大きさ、色の許容範囲を変えることで圧縮率が変わります。
なので、すでに平均化された同一ブロックは同じロジックで平均化しても結果は同じになるんじやないでしょうか？

ＸＰ->ＳＰのが画像が悪くなるという考えは上記の考えが正しいとした場合、ＸＰとＳＰではブロックサイズが異なります。
仮にＸＰを7dot、ＳＰを10dotとすると（プロックノイズの一辺）ＸＰで7dot単位で区切られていたブロックを10dot単位で平均化しなおすと3dot分は隣のブロックから持ってくることになります。ということはその3dotは8〜14dotまでの要素が入っておりＳＰで区切った10dotには1〜14dotまでの要素で構成されるからです。
これがＳＰ->ＳＰの場合、10dotで区切られたものを10dotで区切るので1〜10dotの要素だけで構成できます。
dot数が多くなるほどボケてくるのでＳＰ->ＳＰのが綺麗ではないかと思いました。
ただしブロックのdot数がＸＰのがＳＰの半分以下の場合はＸＰ->ＳＰのが綺麗だと思います。

とまぁ私がおもっているだけなので、間違っていたら指摘してください。

書込番号：836387

>可逆圧縮だと　なにか　まずいのかしら？

圧縮率が全然違うのと再生時（デコード）のスピードが問題ですね。
試しにBMPファイルをLZH(Lharc)で圧縮すると時間がかかる上1/2ぐらいにしかならないと思います。
jpegは約1/10ぐらい、Mpegは1/100ぐらいにできたと思います。

書込番号：836403

チョット長くなりますが・・・

LHAとかの圧縮はエントロピー符号化と呼ばれるもので、ビット列の中
で発生頻度の高いビットパターンほど短い符号列に、発生頻度の低い
ものほど長い符号列に変換する変換テーブルを使う事で元データの
サイズをちじめる可逆変換。

でJPEG/MPEGの圧縮はどうかと言えば、基本は同じエントロピー符号化
です。ではどうしてLHAとかより高圧縮できるかと言うと、
エントロピー符号化がより効率よく機能する為の事前処理を行っている
からです。　

JPEG/MPEG圧縮の基本は
(MPEGの動きに関しては今回考えません、Iピクチャのみです）

[入力行列] ->(1) DCT ->(2) Q -> (3)エントロピー符号化
　-> [出力ビットパターン]

で構成されます。

ブロックと呼ばれる入力されるデータは、元画像を縦８pixelｘ８pixel
のサイズで切り出したものです。圧縮レートにより、この基本サイズが
大きくなったり小さくなったりする事は決してありません。

書込番号：837800

(1)のDCT演算は、元画像の座標系をそのまま表す入力行列を周波数行列
に並べ替える処理です。細かい説明は省きますが、この変換により
行列の左上座標[0,0]方向に重要な情報が集まり、右下座標[8,8]方向に
行くほど重要でないデータが集まります。

書込番号：837802

(2)のQ（量子化）は、この(1)の出力行列を各要素毎にデータの重み
付けを替える処理です。　
------------------------------------------------------------------
貯金箱のお金を計算する事を考えて下さい。まず第１の作業で５００円、
１００円。５０円、１０円、５円、１円のグループに分けますよね。　
で、計算する場合

５００円は１枚の単位で数える 例) 34枚 -> 34　17,000円　誤差 0円
１００円は２枚の単位で数える 例) 13枚 -> 6 1,300円　誤差100円
５０円は　４枚の単位で数える 例）29枚 -> 7　 1,450円　誤差 50円
５円は　４０枚単位で数える 例）76枚 -> 1 380円　誤差180円
１円は２００毎の単位で数える 例）89枚 -> 0　　　89円　誤差 89円

このような変換をしても、実際に貯金箱に入っていたデータ(20,219円）
とは誤差は419円(2%)しか出ません。

逆にデータは{34,13,29,76,89} から { 34,06,07,01,00 } と言う値に
変化されます。

この変換が(3)のエントロピー符号化に効果的に作用します。
------------------------------------------------------------------
量子化処理は量子化テーブル（規格で定義されている）と呼ばれる
重み付けテーブルを用いて行います。　高圧縮する場合はこのテーブル
を整数倍(この値＝Q値）します。

１倍すると{34,13,29,76,89}-> {34,06,07,01,00}で誤差は419円(2%)
２倍すると{34,13,29,76,89}-> {17,03,03,00,00}で誤差は819円(4%)
４倍すると{34,13,29,76,89}-> {08,01,01,00,00}で誤差は2619円(13%)

書込番号：837816

(3)のエントロピー符号化はビット列の中で発生頻度の高いビット
パターンほど短い符号列に、発生頻度の低いものほど長い符号列に
変換する変換テーブルを使う事で元データのサイズをちじめる
可逆変換と説明しました。

JPEGやMPEG2では既にこの変換の為のテーブルは規格の中に定義されて
おり、この規定にしたがって変換されます。

先ほどの例でビット列として考えて見ると

{34,13,29,76,89} = 00100010_00001101_00011101_01001100_01011001
{34,06,07,01,00} = 00100010_00000101_00000111_00000001_0000000}
{17,03,03,00,00} = 00010001_00000011_00000011_00000000_0000000}
{08,01,01,00,00} = 00001000_00000001_00000001_00000000_0000000}

見ての通り0の連続する数を考えると量子化値を上げた物ほど0の連続が
多い事が判りますね。よって量子化値を上げるほど誤差は増えますが、
エントロピー符号化での圧縮率があがります
（ビットレートが少なくてすみます）

こんなとこでしょうか。　長文失礼しました(^^;

書込番号：837821

>すでに平均化された同一ブロックは同じロジックで平均化しても結果は
>同じになるんじやないでしょうか？

A(n): エンコード後の画像、nはエンコード回数、A(0)は元画像
E(n): 残差成分、　nはエンコード回数

とすると

A(n+1) = A(n) + E(n)


A(1) = A(0) + E(0)
A(2) = A(1) + E(1) = A(0) + E(0) + E(1)
・・・・
A(n) = A(n-1) + E(n) = A(1) + E(1)+E(2)+...+E(n)

と言う事で、n回エンコードした場合は途中で１回でも大きな誤差が
発生したら元画像からの合計差分は大きくなりますネ。

同じ符号化システムを用いて量子化値が同じであれば

E(1)>E(2)>E(3)>....> E(n) ≒ 0

となる事が予測れますので、誤差は収束していくと言う考えは
間違ってないと思います。

かと言って誤差蓄積がどのくらいで止まるかと言われても困りますが(^^;

書込番号：837923

訂正です(^^;

>A(n) = A(n-1) + E(n) = A(1) + E(1)+E(2)+...+E(n)

A(n) = A(n-1) + E(n) = A(0) + E(0)+E(1)+...+E(n)

A(n) = A(0) + ΣE(n)

>E(1)>E(2)>E(3)>....> E(n) ≒ 0

E(0) > E(1) > E(2) > E(3) >.... > E(n) ≒ 0

書込番号：837941

まいむまいむさん、わかりやすい説明ありがとうございます。
貯金箱の説明わかりやすかったです(^^;

もう一点だけいいでしょうか？
>ブロックと呼ばれる入力されるデータは、元画像を縦８pixelｘ８pixel
のサイズで切り出したものです。圧縮レートにより、この基本サイズが
大きくなったり小さくなったりする事は決してありません。

ということですが、この8×8がブロックノイズのサイズということでいいのでしょうか？
計ったわけでは無いのですがもっと大きいような気がするのですが、画面で見られるブロックノイズは違う理由ででるのでしょうか？

書込番号：837972

基本的には８ｘ８サイズで発生すると思います。量子化値が大きくなると
８ｘ８の単位で平均かされ、隣接ブロックとの境界で差分ができてしまう
のがブロックノイズですネ。

ただＤＣＴの単位は８ｘ８ですが、その単位で動き探索とかすると計算
が膨大で大変です。よってMPEGの制御処理はマクロブロックと呼ばれる
単位で行います。
マクロブロックはブロックを横に２個、縦に２個で構成されますから、
１６ｘ１６単位ですね。　先ほど説明した量子化値の変更の最小単位は
このマクロブロック単位で行うので(MPEG2もこの単位かどうかは自信は
ないです）大きく見える場合があるのかも知れません。

DMRシリーズはエンコード処理とは別に事前に視覚重み付けと呼ばれる
人が良く見る部分には情報量を多く与え、余り見ない所は情報量を減らす
画像検査とかが入っているようなので、マクロブロック単位で量子化値を制御してる事が予測されますので、その辺りも関係しているのかも。

あとデコード後のポストフィルターとしてブロックノイズＮＲとかの
適用があり、ブロックノイズ化しそうな隣接するブロック同士の境界
を目立たなくさせる処理とかもあるんで、大きめに見えるのかも。

あと、DVDレコーダーの圧縮はプログレッシブではなくNTSCであるので
ブロックの見え方が縦倍に見えるのかな？

すみません、NTSC(インターレース）での圧縮は良く知りません。

書込番号：838062

あとハイブリットVBRオンだと、動きによってHalf-D1とかになるんで
デコード時に横倍されるって言う機能もありますね。動きによってって
事はブロックノイズが発生しやすい状況と言う事でもありますし・・・

書込番号：838088

とても勉強になりました。ありがとうございました。

書込番号：838174

まさか価格comでデータ圧縮の話があるとは思いもよりませんでした。

現在、可逆圧縮が可能な新しい規格 JPEG2000 および
その動画像バージョンが策定されています。
なお、JPEG2000 では原理的にブロックノイズが発生しません。
今現在は対応ソフトも少ないですが、これからどんどん広まるでしょう。
楽しみですね。

書込番号：842200

[ideal]

もし、参考にできるページがあったら教えていただけないでしょうか。> ESTさん

書込番号：842244

＞まさか価格comでデータ圧縮の話があるとは思いもよりませんでした

すみません調子にのってしまいました(^^;

JPEG2000/MotionJPEG2000ってウェーブレット変換でしたネ。

書込番号：842501

データ圧縮は専門分野なのです。しかも今 JPEG2000 を勉強中 :-)

＞ideal さん
＞もし、参考にできるページがあったら教えていただけないでしょうか。> ESTさん

参考文献および製品などの対応については各社Webページで調べるか、
google などを使って調べていただいた方が良いかと思います。
また、コンピュータ専門雑誌でも紹介されたことがあります。
とりあえずリンクをひとつ
http://www.zdnet.co.jp/news/0012/04/jpeg2000.html

その将来性については、静止画像は今の JPEG を置き換えるでしょうし、
動画像も、今の MPEG と同程度にまで広まるかもしれません。
もっとも、モーションJPEG2000が普及するのは随分先のことだと思います。

書込番号：844177

[ideal]

ありがとうございます_o_

JPEG2000を動画に利用しようという計画があることを存じ上げませんでしたの
で。

書込番号：844193

MacOS10用のQuickTime6ではJPEG2000対応されています。(確かフル対応じゃなかったと思いますが)
でMotionJPEG2000はずっと期待していたのですが今のハードではまだ処理速度が足らなさそうですね。
QT6でムービーをJPEG2000にしてみたのですが滅茶苦茶時間かかりました(^^;

書込番号：844542

[Panasonicfan]

期待のJPEG-2000は、処理速度の点で普及が遅れそうですね。
JPEG-2000関連のニュースを去年あたりまでは、聞いたことありましたが、
最近は聞かないです。

ＨＤＤやＤＶＤやメモリの容量増大とどちらが早いでしょうか。

書込番号：851349

[ideal]

19日頃からのJPEGライセンス問題(?)で結構聞きましたけれど... 2000はどう
なんだ、とかいうのばかりですけど(^^;

書込番号：851730

[Panasonicfan]

JPEGライセンス問題って　ソニーがウン億円払うやつですか？

書込番号：861489