映像可逆圧縮総合スレ Part3

>>133
HuffyuvSはいいのか？と思ってググったけど、
http://www.megaupload.com/?d=F388AL8Sは俺の環境では画像が乱れる。

http://wiki.nicomas.net/index.php?コーデック#te866ea1
MTモードでエンコードしたデータは、オリジナルのHuffyuvではデコードできないので注意。

http://freesoft.tvbok.com/movie_encode/about_codec/huffyuvs.html
huffyuvsは色信号のスケールを変換しない
huffyuvsとhuffyuvの違いを解説しているサイトを探してみた所、なんとCCE販売元NOVACのCCEのFAQで解説されていました。
CINEMA CRAFT ENCODER BasicのFAQ
Ａ．輝度レベルの設定は、入力がRGBの時のみ有効に機能します。
入力がYUY2の時は、変換せずにそのまま使用しています（スケール変換はしていません）。
もともとYUY2はCCE-Basicが受け付けることができる唯一のネイティブフォーマットです。入力としてRGBを受け取った場合、それは内部的に
YUY2に変換されます。そのときの変換方式が２種類あり、その方式は輝度レベルのところで選択可能です。もしネイティブのYUY2がスケール
変換されてしまうのであれば、0-255で変換したYUY2の信号もスケール変換されてしまうはずです（16-235で変換したものは二重に変換されることになってしまいます）。
スケール変換をしているのは huffyuv 自身になります。スケール変換をしたくないのであれば、 HuffyuvS をご使用ください。

FAQなんぞ読まなくても普通に使用するには何にも問題なかったのですが、読んでみるものですね。。。。
huffyuvsは、RGB−YUY2間で行われる無駄な輝度変換を省略する事が出来るようです。
つまりは、動画編集ソフト等で動画を作成する時にキチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されて今い
ますよ。という事らしいです。
ＴＶキャプを行う場合でも、元々がTV信号ですのでhuffyuvsの方が向いているでしょう。

だとさ。

別にTVキャプなら通常RGBなんて介在しませんからhuffyuvでなんら問題はない

>>136
TMPGEncはRGBだったと思う...

ていうか、>>133のツッコミどころは
　　＞huffyuvsとhuffyuvとマルチスレッドのhuffyuvを右クリックでインストールしたんだが。
のとこだよね。

マルチスレッド版はFOURCCが違うから共存できるとして、
FOURCCが同じHuffyuvsとHuffyuvを同時インストールするとどういう挙動になるんだろう。
しかも両方ともアンインストールがうまくいかないバグがあるようだし。

ごめんFOURCCが同じとか大嘘だった。いや〜ん、こっぱずかすぃ。。｡･ﾟ･(ﾉ∀`)･ﾟ･｡

　　Huffyuv　　　HFYU
　　HuffyuvS　　SHYU
　　Huffyuv_mt　HYMT

自分でもなんでかわからないけど物凄い変な思い込みがあったようだ・・・・orz

・・・・・・あれ？じゃあなんでデコードのミスマッチだの画面が乱れるだの騒いでるんだ？？？

FourCCがSHYU（HuffyuvS）なのは確認したけど、やっぱ画が乱れる。
>>139は正常に再生できてるの？

>>140
うちはHuffyuvSは入れてないんだ。
すまんけど、ちょっと今はコーデックまわりをいじりたくないので検証はできそうにない。

>>141
なんか細かい横線が気になったので、
Field Thresholdを288から576に変えたら正常に再生できたｗ

http://dtv.sakura.ne.jp/contents4/001.html
＞フィールド閾値というのは、映像のフィールド数（縦のサイズ）が
＞この数字を超えるとインターレースとして扱うというものです。
＞バージョンによっては設定項目がないものもあります。もっとも、
＞圧縮方法が多少変わるだけで、あまり大きな影響はありません。
＞むしろ、圧縮時と展開時で違っているとダメな場合があるようなので
＞デフォルトのままにしておきましょう。

フィールド敷居値のヘルプ(英語版)↓
Video with more than <threshold> lines will be processed interlaced by Huffyuv.
The default value (used in older versions) is 288.

Warning: Decompressing a interlaced video with a higher current threshold (so that huffyuv will not use field processing) will fail!
The setting in stored in the ini-file, not in the video!

追伸

ところで、ググってたらこんな書き込み見つけた。
識者さん、教えてください。↓
870 ：692[sage]：2009/06/22(月) 19:25:01 ID:sKsKMchC
Huffyuv_MT使って見ましたが、画像遅延は変わりありませんでした。
13分程の録画で開始時はピッタリでしたが、終わりでは画面が少し遅れていました。
Thresholdは何を設定すればいいのでしょう？一番大きい数字を設定しましたが、
720ないので、1080iはもとより720pもちゃんと処理しないのでしょうか？
（【HDMI】BMD Intensity 10枚目【キャプチャー】）

・UtVideo Codec 7.0.0 （x64版の追加）
　　http://umezawa.dyndns.info/wordpress/?p=1305

・窓の杜 - 【NEWS】64bitアプリケーションで32bit用の動画コーデックを利用可能に「Proxy Codec64」
　　http://www.forest.impress.co.jp/docs/news/20091022_323662.html

俺にとっての問題は64bitOSを使っても用いてるキャプチャソフトも編集ソフトも32bit版しかないということだ

Linuxだとほぼ全てのアプリケーションにamd64版があるようだけど、Windowsで64bit版が少ないのって何で?

作るコスト＞得られる利益 だから。

UtVideo Codecはファイルは規定の位置にインストールされてるけどvctest・Veedub64では選択できなかった。
Lagarithはx86のほうが早くてProxy Codec64かましたx86が若干x64よりも早かった・・・

>>135
色空間スレでまるもさんが実験したけど
伸張圧縮しないHyffyuvsはRGB<>YUV変換誤差がでかいよ
RGB化したときに切り捨てられる15以下235以上を保持することがメリットってだけ
元はAviutlの伸張圧縮に問題がある次期にそれように作られたもの
ノバックの書き方がおかしいんだが
”キチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう”
んじゃなくて
”伸張圧縮しない環境で輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう”

>>137
それは2.5PLUS時代まで
ExpressシリーズはYUY2だよ