可逆圧縮総合スレ

可逆圧縮関連総合スレです

前スレ
http://pc5.2ch.net/test/read.cgi/avi/1056587462/

2ｽﾞｻ━━━━⊂（ﾟДﾟ⊂⌒｀つ≡≡≡━━━━!!

3ｹﾞﾄｰ

4sama

コーデック名によるスレ検索を不可能にすることによってスレを廃れさせるとは…
>>1はかなりの策士と見た！

ふっふゅv

Huffyuv v2.1.1
ttp://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html

DVStormって、DVハードエンコらしいけど、可逆圧縮？
超高画質でコマ単位の編集が可能らしい。

DVなら可逆じゃないだろ。
Iフレのみで28Mbpsじゃなかったか？

CorePNG

CorePNG
http://corecodec.org/projects/corepng/

特徴：
デルタフレーム装備。ソースによっては大きな効果。
デルタフレームを使用しなくても一般にhuffyuvよりも縮む。
ただし、エンコードだけでなくデコードも重い。

Huffyuv2.2.0の正式なダウンロード元ってどこだ？

age

性能だけならLCLのYUV1：1：1：が最も優れてるよ

>>8
ハードウェアDVエンコーダとしてはかなり糞
デッキは勿論民生用ハンディカムのが全然いい
編集は楽だが環境を選ぶ

CorePNGってアニメ向け？実写で中間ファイル吐き出してみたんだけど、遅い割りにたいして縮まなかったよ。
Huffyuvに比べてね。

Scale = 720dots x 480dots = 345,600(dots^2)
ColorDepth = 24bits
FPS = 29.97fps

BPS = Scale x ColorDepth x FPS = 248,583,168bps = 237Mbps
= 31,072,896Bps = 29.63MBps

BPM = BPS x 60sec/min = 1,864,373,760Bpm = 1,778MBpm

(30 minutes)
BPM x 30min = 55,931,212,800B = 52.1GB

(1 hour)
BPM x 60min/hour x 1hour = 111,862,425,600B = 104.2GB

(2 hours)
BPM x 60min/hour x 2hours = 223,724,851,200B = 208.36GB


250GB以上のHDDがあれば、無圧縮でもいけるな。

可逆圧縮なんて中間ファイルとしてしか使わないから
圧縮率はそこそこでいいから圧縮速度が高いのがいいな

>>17
MSYUVで非圧縮YUY2にすりゃその2/3にさらに縮むんでない？

29.63MB/s

HDDが間に合わないな。

間に合うだろ

>>20のHDDはPIOモード

揚げ

HDD目いっぱい使うと間に合わんだろうな。
最近の7200rpmのHDDは25MB/s〜50MB/s（速い部分と遅い部分の差はほぼ倍だからね）

　　　　　　　　　　　　　　　　／＼
　　　　　　　 　　　　　　　／／＼＼
　　　　　　　　　　　　　／／ .◎ .＼＼
　　　　　　　　　　　 ／／　　　　　　＼＼
　　　　 　　　　 　／／　　　　　　　　　＼＼
　　　 　　　　　／／　　　　　　　　　　　│　＼
　　　　　　　／／ 　　　　 　　　　　　　　＼＿ ＼
　　 　　　／／　　　　　　　　　　　 　　　　　 　＼＼
　　　　／／ 　　　　　　　　　 　　　　　　　　　　　＼＼
.　.　／／　　　　　　　　　.　 ／￣＼ 　　　　　.　　　＼＼
　／／◎　 　　　　　　　　　| 　　　　| 　　 　.　 　　 ◎＼＼
　|＼＼　　　　　　　　　　.　 ＼＿_／　　　　 　.　　　 　　＼＼
　|:::::＼＼　　　　　　　　　　　　　　　　 　　 　　　 　　　 　　＼＼
　|::::::::::＼＼＿　　　　　　　　　　　　　　　 　　　 　　　　　 　　＼＼
.　＼:::::::::＼ 　 ＼　　　　　　　　　 　　　　　　　 　　　　　　 　　　＼＼
　　 ＼::::::::::＼　 |　　　　　　　　　　　　　　　　　　 　　 　　　　　 　　＼＼
　　　　＼::::::::::＼＼　　　　　　　　　　　　　　　　　　　　　　　　 　◎／／|
　 　 　 　＼:::::::::::＼＼◎　　　　／￣＼ 　　　 　.　 　　 　 　 　　／／.：|
　　　　　　　＼:::::::::::＼＼　　 　|　　　 　|　　　 　.　　　.　　　　／／：／
　　　　　　　 　＼:::::::::::＼＼　　 ＼＿／　　　　　　 　　　　 ／／　／
　　　　　　　　　　＼:::::::::::＼＼　　　　　　　　　　　　 　　／／　.／
　 　 　　　　　　　 　＼:::::::::::＼＼　　　　　　　.　　　 　／／　／
　　　　　　　　 　　　 　＼:::::::::::＼＼　　　 .　　　　　／／　／
　　　　　　　　　　　　　 　＼:::::::::::＼＼　　.　　 　／／　／
　　　　　　　　　　　　　　　　＼:::::::::::＼＼. ◎ .／／　／
　　　　　　　　　　　　　　　　 　＼:::::::::::＼＼／／　／
　　　　　　　　　　　　　　 　　　　 ＼:::::::::::＼／　／
　　　　　　　　　　　　　　 　　　　　　＼::::::::::|　／
　　　　　　　　　　　　　　　　　　　　　　＼::::|／

↑メーカーが無いのでバッタもんですね。

64bit版のHuffyuvってあります？？

>>17
なにをいまさら
そんなもん、チラシの裏でやっとけ、ボケが

>>28
低学歴のくせに

>>28
チラシの裏じゃ、皆に見えないだろ。

お前の言うとおり、こんなもんだからな。
誰もやらずにいつの間にか度忘れしてるってのがオチ。

Huffyuv

ふふゆぶ

Alparysoft Lossless Video Codecってどうよ？
リアルタイムキャプもいける
ttp://www.alparysoft.com/

>>33
何これ？登録しないと駄目なの？

Huffyuvより縮むね。アニも実写も。でも重い。スピード重視だとデカくなる。
悩ましいところだ。

>>33
いいね.
圧縮率を求めるとHuffyuvより重くなるけど
predictのチェックを外して圧縮レベルをaverageにすると
2pass用の中間ファイルとしては,かなりバランス良い感じ.

>>36
その設定が一番無難だな

スピード重視だとHuffyuvよりでかくなる上にデコードが遅くて役に立たないｗ

avs（ver2.5）を通してVirtualDubMod（1.4.13日本語版）の再圧縮[完全]で
huffyuvエンコしたら、ファイルが読み出せなかった。
そのときのhuffyuv（v2.2.0）の設定は、
YUY2出力設定はPredict left(fastest)、
RGB出力設定はPredict left/no decorr.(fastest)。
フィールドしきい値は288行。他はチェックを付けない。

同じ設定で、再圧縮[高速]でエンコした場合は、読み出すことができた。
色空間の問題だろうか。

>>38
VDMの内部色空間はRGB
入力が非RGBの場合VDMは入力CODECへRGB変換を要求する
Avisynthはスクリプトで明示しない限りRGBを出力しない
ってことでない？

Avisynthから渡されたものは、どの色空間にしろ無圧縮。
VDはYV12以外は自前でRGB32に変換する。
YV12だけはサポートしてるCODECを探してCODECに依頼する。
完全使う場合、出力色空間は指定されたものになるが、デフォはRGB24だった気がする。
これで変になる気はしないんだがなあ？

少し実験してみた。
YUY2ソースをAvisynth経由でVDに渡す

・Full processing modeだとアクセス例外発生。
・Full processing modeでも、フィルタを挟むと大丈夫な場合もある。
・HuffyuvをUncompressed(RGB/YCbCr)にするとアクセス例外は起きないが画像が壊れている。
・Normal ｒｅｃｏｍｐｒｅｓｓだと正常

・一旦Direct stream copyで中間ファイルに保存してsynth経由なしでやってみるも、結果は同じ。
・ふぬああでHuffyuvキャプした生YUY2を入力してやってみるも結果は同じ。
（この時点でsynthが原因の線は消えた）

なんかVDのRGB32->RGB24変換バグのような気がするなあ。

昨日Huffyuvs初導入試みたんだがインストール時に「認証テストに失敗」ってでたんだが

誰か教えてくれないか？あれはなんなんだ？無視していいものか？

>>38,41
Huffyuv2.2.0はRGBだと上手く動作しない感じ

今更Huffyuvsて

>>44
TMPGenc2.X系かCanopusProcodder使いなら
使ってるヤシもおろうよ

>>45
どうせなら2.2.0使えって事でない？

>>46

>>46
なぜか使えない環境があるのは前スレでガイシュツ
参照形式のあれ使えば回避できるという話だが
ぶっちゃけうちの64機だと使えない（フレームが壊れる）
Athlon XPのほうは平気なんだがなぁ

保守

http://forum.doom9.org/showthread.php?s=&threadid=67121&perpage=20&pagenumber=3
http://forum.doom9.org/showthread.php?s=&threadid=76396

age

>>17
>Scale = 720dots x 480dots = 345,600(dots^2)
普通は720 x 480dots
なんだ、dots^2ってｗ

縦1dot x 横1dot = 平方1dot^2
それの複数形？

ほしゅ

>>53
dot=平方だろ

dotはもともと点という意味。
dpi = dots per inch
の例でもわかる通り、厳密には平方（2次元）という意味ではない。

pixel

りんごが縦に40個、横に30個並んでいる。
全部で　40個x30個=120(個^2)


(笑)

全部で　40個x30個=120(個^2)


(笑)(笑)

要するに単位にはデジタルな単位とアナログな単位の2種類があるということだ。

全部で 40個x3個=12(個^2)

(笑)(笑)(笑)

今気付いた＿|￣|○

(笑)^2

>>62
まぁｶﾞﾝｶﾞﾚ(笑)^2

Huffyuv以外で可逆圧縮YUY2対応コーデックありませんか？

CorePNG

早速試してみました。でもエンコ速度遅くてちょっと実用的ではないかも・・・
サイズもHuffyuvより大きくなりました。

MSU ロスレスコーデックはどう?

MSU試したら糞重たかった。フィルターかけずにしても
秒間1fpsしかエンコ速度でない_|￣|〇

なんだそりゃw

Canopusもひっそりロスレスコーデック作ってたりして。

結局huffyuvが速度、圧縮率ともに最強っぽい

圧縮率だけならMSU LossLess codec

Alparysoft Lossless Video Codec
CorePNG
Huffyuv
Lagarith Lossless Video Codec
MSU Lossless Video Codec

本当に初歩的な質問かと思いますが、
WinXPに可逆圧縮コーデックの
ＬＣＬ、AVImszh をインストールするにはどうしたらよいでしょうか？
対応してないですか？

>>75
普通に使えるけどね。
LCL使うってことはアイコラビデオでも作るの？

>>76
ご回答ありがとうございます。

なにぶんPC初心者で四苦八苦しております。
普通に使えるとの事ですが、ReadmeにXPでのインストール方法が記載しておらず、
ファイルを右クリックでメニューを開き→インストールというのはXPではできないようです。
ＸＰの方の設定の問題でしょうか・・。

＞LCL使うってことはアイコラビデオでも作るの？
いえいえ、個人でアニメーションを作っています。
女の人も出ないような、マジメなものです^^;

可逆圧縮って何？

INF書き換えてAddRegNTを追加しないとダメだったかな？
HuffYUVのINFを参考に書き換えてみたら？

>>77
自己責任でよろ
ttp://49uper.com:8080/html/img-s/34091.zip
パスはこの板

>>79
ご回答ありがとうございます。
が・・専門用語が理解できず、、、。
HuffYUVというのが、別の可逆圧縮コーデックなのは知っているんですが。
ちょっと、ＰＣ初心者の私には無謀だったのかな。

一応HuffYUVもダウンロードしてしてみました。
INFのファイルはありますが、参考にするというのはどういう事なんでしょう・・・。

>>81
AVIMSZHだけINF書き換えてインストーラーで包んでおいたよ。
すぐ消すからね

>>82
何だかとてつもなくお手数をお掛けしていますね。
本当にありがとうございます。
ファイルの方、落とさせて頂きましたm(__)m

ちょっとパスの方が分かりません^^;
パスはこの板、、アドレスとか色々入れてみましたが、、、
ド素人過ぎてすみません・・。

アルファベット三文字ですｗ

アルファベット３文字。
孤軍奮闘中です。
ＡＶＩ違う・・ＣＧＩ違う・・２ｃｈ・・違うわね。

マジメにDTVやってる人かと思ったのに・・
釣られてしまったか・・

>>86
長い間本当にありがとうございました。
おそらくできたのではないかと思いますので、可逆圧縮で書き出してみます。
ここはＤＴＶ板というのですね・・検索で直接きてしまって知りませんでした・・
ＤＴＶ（動画編集）、、初めて動画を作るにしても知識不足でした・・。
それにしても、ＰＣにお詳しくてうらやましい限りです。
お世話になりましたm(__)m

エンコ板になってるもんな。
俺もその一部だけど。

LCLってXPに対応してないの？

huffyuvに2.2.0があるのを最近知って探していたら、
huffyuv_ccesp-patch_0.2.5.dllなるモノを見つけたんですよ。
タイムスタンプを見ると「2004年5月18日、20:16:42」と新しそう。
CCE-Basicを使っている場合、どっちを使った方が良いのでしょうか？
まだ2.2.0は見つけてないんですけど・・・。
それよりccesp-patchは何が違うんでしょうか。
普段の作業の流れは、

１．huffyyuvでキャプチャ
２．AviUtlでカット（ソースによってフィルタ使う）
３．「再圧縮無し」で保存
４．CCEでエンコード

としています。
どなたかアドバイスよろしくお願いします。

huffy情報局の後継スレみたいなのでここで聞きましたが、
スレ違いの場合は申し訳ありませんでした。
出来れば誘導お願いします。

>>90
> ３．「再圧縮無し」で保存
AviUtlで再圧縮無し保存すると、フィルター掛けの効果が無効になるんじゃ
なかったっけ？
カットは生かされると思うけど。

私はhuffyuvで中間ファイル吐いて、TMPGEncでエンコしてる。

>>90

>>50

>>50
検索から辿っていったんだけど、huffyuv_ccesp-patch_0.2.5.dllはたぶんそこでゲットしました。
でも、これを使うと何が良いのかいまいち分かっていません・・・。
普通のhuffyuvを使っても>>90に書いた1から４までYUY2で出来るんじゃないのかなと思うのですが。
だったらどこにメリットがあるんだろうか・・・。
その時の経過とか調べても出てこないしお手上げです。
とりあえずhuffyuv_ccesp-patch_0.2.5.dllを使っとけって事ですかね。
どなたか違いなど説明お願いします。

>>91
再圧縮なしだとフィルタは無視されますね。
今まで気づきませんでしたよ。(TT)

220はRGB comprtessionにﾊﾞｸﾞがあるらすぃい

うそーん　まじー？

正常にデコードできないだけで特に問題はない

録画はできるけど見れないってことですか（汗）

ぽっぽっぽー、ぬるぽっぽー。
ガッがほしいかそらやるぞー。
みんなで仲良くガッガ汁。
ぬるぽおおぉぉぁぁぁぁ

　　　　　　　　　 ＿
　　　　　　ミ　∠＿）
　　　　　　　　　/
　　　　　　　　 /　　　＼＼
　ｳｲｰﾝ　　Γ/了 　 　 |　|
　　ｳｲｰﾝ　 |.＠|　　　　|　|　ｶﾞｯｶﾞｯｶﾞｯ
　　　　　　　| / | . 　 　 人
　　　　　　　|/　|　　　 < 　>_Λ∩
　　　　　 ＿/　 | ／／. Ｖ｀Д´）/>>98
　 　 　　（＿フ彡 　 　 　 　 　 /

⊂⌒~⊃｡Д｡)⊃このスレでもたたかれるのか

>>100
ここは可逆圧縮スレだから、どれだけ叩かれても何ともないはずだ

▽｀）つ　ぬるぽー

huffyuv_ccesp-patch_0.2.5のベストな設定教えて

huffyv12ってどうよ？http://homepages.pathfinder.gr/ffvfw/

これか。。。
http://forum.doom9.org/showthread.php?s=d267556da47d8a2f6d71cc46241f85cb&threadid=38389&perpage=20&pagenumber=1

何を今頃.......今はffdshowに統合されてるでしょ > VfWインターフェース

2pass用のテンポラリファイルにならFFV1もいいかも,とか言ってみる実験
(仕様固まってないみたいなんで保存にゃ向かないが

huffyv ってなんて読むの？？？
ふゅっふゅ〜？ふゅっふぃ〜？？

ハフマン符号化したYUVだから
"はふわいゆーぶい"でいいんじゃないの？

マジレスしちゃった上に間違ってるよ

フッフユブ！ヽ(`Д´)ﾉ

はふやふ

ぼくも、はふわいゆーぶい、かな。

かわいく、ふゆゆ、でもいいかもしんない。

http://www.geocities.jp/zero_jp_2005/

実験CODECですが、可逆を作ってみました。
実写向けで、まだ遅いです。
最適化の余地はかなりありますが、今は後回しにしています。
需要があるなら最適化しようと考えています。

最適化済んだら公開して

インストールできない(´･ω･`)

>>113
Huffyuvと比較して有利な点は何？

Huffyuvと比較して有利な点は、今のところ圧縮率だけです。
あとはアルゴリズム的に並列演算を意識して組んでありますのでSIMDに適応率が高い、といったところです。
今はべたなC++で記述してありますが、最適化することで化ける可能性がある（かもしれない）、かな。

なるほど、応援してるからがんばってね

inf右栗でインスコでけへんけどどうやんの？
WinXP

自分で作れるなんてすごいね。ｶﾞﾝｶﾞﾚ

右クリでも"ハードウェアの追加と削除"でもインスコできないなぁ@XPSP1a

サイトには「遅い」とあるけど、リアルタイムキャプチャーに使うのは厳しいですかねやっぱり

>>122
そう言うのは君がやってみて、作者さんに情報をフィードバックするもんですよ。

>>119,121

責任は持てん
http://ari-sin3.hp.infoseek.co.jp/cgi-bin/source2/No_0008.zip

インスコ法は作者さんとこに書いてあったよ

2005年1月24日(月)

インストールがうまくいかない

そういえば、あのinfはちょっと特殊な方法でインストールしないとうまく動きません。

次回リリースには直します。
インストールするには、コマンドプロンプトで

rundll32 setupapi.dll,InstallHinfSection CODEC 132 インストールしたパス\codec.inf

必ずインストールしたパスをドライブレターまで含めたフルパスで記述してください。
これでインストールできるはずです。

日記転載しちゃった
すまん

はっひゅふふぶ

ぬるぽ

がっ！

((( )))
（´∀`）

hosyu

ｈｕｆｆｙｕｖ 2.2.1 まだ？

http://www.compression.ru/video/ls-codec/index_en.html
どうよ？

>>134
Alparysoft Lossless Video Codecに似てないか？

http://ai.yimg.jp/bdv/jishakou/20050304/c0kcdxxx-b.gif
http://www.geocities.co.jp/Playtown-Denei/2837/soft.htm

過疎気味。

>>113に期待age

hosyu

あげ

今日からここは俺のスレ

Huffyuvより圧縮率高くて負荷の低い可逆コーデック作って>>141

最強可逆圧縮コーデック
LCL　マルチスレッド対応
http://www.geocities.co.jp/Playtown-Denei/2837/

AVIzlibは設定が色空間に合わせて細かくできるのが面白いけど、
エンコ速度も圧縮率も、結局のところhuffyuvsに劣る。

ハフユヴ

ふふゅｖ

huffyuvのDirectshowデコーダー希望

>>147
ffdshow

保守

huffyuv2.1.1
fastestよりbestで圧縮した方がデコードが高速？

音楽編集ソフトで出力する種類が”WMAの可逆圧縮”で保存できるようなソフトはあるのでしょうか？

音の可逆圧縮はけっこういっぱいあるけど
俺はTTA使ってる
圧縮スピードが速いので。

>>152
ありがとうございます
しかし、SonicStageを使用していましてそれ用+保存用にと思いましてWaveをWMAかMP3の可逆圧縮にするようなソフトを探しているのですが、見つかりません。
フリーソフト、市販ソフト問わないのですが、ありますでしょうか？

DigiOnSoundで可能

>>154
ありがとうございました
Windows Media 9 Audio Encoding Helperというフリーソフトで出来るみたいなのでこれを使ってみたいと思います
_(_ _)_ﾍﾟｺﾘ

[EAC](クラシック) マーラー交響曲全集（ショルティ／シカゴ）(ape＋cue)
をダウンロードしましたがZIPファイルなのに解凍しようとするとアーカイブじゃないと
言われて、とにかくどうやったら再生できるんでしょうか。ほんとにおねがいします。

ｶｴﾚ

面倒くさいからひゅーひゅーぶいと呼ぶことにしたよ。

ハフマンコでいいと思うよ

もっと簡単に「あれ」でいいじゃん

エッチで良いじゃん

はっっっひゅぅぉおおおおおーーーーーぶっっ！！！！！！

はっフゥーーーーーーーーー！！！

すいません、ミスりました。
自分のパソコン今動画でＨＤＤがいっぱいになっています。
でもＤＶＤＲドライブがついていないので、一度圧縮してＣＤＲに保存し、友人に渡してＤＶＤＲにやいてもらおうと思っています。
ＲＡＲみたいな可逆な圧縮ツールで、一番圧縮率が高いのを教えてください。
ＲＡＲで３０ＭＢのものを圧縮したら２５ＭＢにしかなりませんでした。
しかも時間めちゃかかりました・・・

圧縮された動画をさらに可逆圧縮しようなんて無茶はやめておけよ

デコードが軽いんならそれでもいいさ

>>164
もう一個HDDを買う。
それしかない

最新のでも\5000〜ぐらいからあるんだから
焼きDVDドライブを買えよ

誰かからドライブ借りれば良いんじゃね-の？

6000円のDVDドライブすら買えないニートですか

170 ：名無しさん＠編集中 ：2005/10/16(日) 19:07:14 ID:/OxTKuUw
6000円のDVDドライブすら買えないニートです

パイオニアのＤＶＤドライブすら買えないニートです

バイトして買えばいいじゃない

２層DVDを早く一枚１００円にしてください。おながいします。

そんなのよりﾌﾞﾙﾚｲ

Huffyuv CCESP Patchのデフォの設定教えて
いじってたら分からなくなっちゃった
あとCCEでエンコする前提で使うときの最適も教えて欲しいな

あちょー

ZLCの人戻ってこないね・・・

いつかdaemonで対応してくれんかな・・・

YV12対応のロスレスvideo codecをいくつか試したので貼っておきまつ。
ソースは720x480 YV12 4558frames (29.97fps 2分32秒 実写60i)

2,392,067,600 Byte YV12未圧縮
1,597,114,940 Byte Huffyuv YUY2 (UV補間なしでYUY2に変換してからエンコ)
1,549,154,856 Byte GLZW (Key frame interval 256)
1,373,044,396 Byte VBLE
1,339,646,776 Byte LossLessJPEG
1,235,916,360 Byte Huffyv12 (Median) (Adaptive huffman tables)
1,276,531,546 Byte Alparysoft
1,185,157,886 Byte H264LossLess
1,153,836,792 Byte Loco (Interlaced) (loco004.zip)
1,138,798,648 Byte CorePNG (Key frame interval 31)
1,107,159,962 Byte Lagarith
1,052,576,378 Byte FFV1 (VLC) (Key frame 250)
1,047,320,718 Byte FFV1 (AC) (Key frame 250)
1,032,021,950 Byte MSU (Max compression slow decompr.)

圧縮率優先での速度。P3-1Ghz
エンコード 　　　　　　　　　　 　　　　　　　高速←　　　　　→低速
Huffyv12 > Huffyuv ≒ VBLE > Lagarith > Loco ≧ FFV1(VLC) > JPEG > FFV1(AC) > GLZW > H264 ≧ CorePNG > MSU
デコード　　 　　　　　　　　 　　　　　　　　高速←　　　　　→低速
Huffyv12 > Lagarith > Huffyuv > CorePNG > JPEG > FFV1(VLC) ≒ GLZW > VBLE ≒ Loco ≧ FFV1(AC) > H264 > MSU

>>180
乙

？

Lagarithいいな
かなり高速なのにシーンによってはHuffyuvよりもめちゃくちゃ縮む

dsx

Lagarith
Version 1.3.8 released on 03-11-2006

ape　cue　apl
ZIPファイルを解凍したら、以上の三つが出てきた。
EACで何をすればいいんだ？

ﾀﾞﾎﾞｰｸｯﾘｸ

EACぐぐってみたけど音楽関係っぽいので板違いだな

MP3の可逆圧縮ってある？

>>189
もしあったとしても、仕組みから非圧縮よりサイズが大きくなりそうだ。

EAC=可逆　っていう発想はダウソ房

apeだと可逆以外にもできるんだったけ？

EAC = ape っていう発想はダウソ房

そういえばZeroの人はどうなったんだろうな

Huffyv12 でのエンコードってどうやるのでしょうか？
AVIUTLの場合。

>>195
avisynth使え

>>195
ffdshowのvfwインターフェースからYV12なHuffyuv使えるよ

猿のMcIntosh版ってないよね。FLAC使うしかない？

>>198
Macintosh版はある。
McIntosh版はない。

ググれ。

　　 /＼
＿_（　　ゝ‐''ｱ￣~ﾞ''ヽ
＼　 ゝ`r'ソﾉ＿＿,,､_」
　　ﾞ‐-/'" /,,-＼）,,-, ＼
　　 ／　 / |il　　 |il　!　 ＼
　＜　　ﾙゝ.ﾞﾞﾞ lフ ﾞﾞ丿､　　 ＞　２００ＧＥＴ鴨〜♪
　　'^v､ゝ　/⌒ﾌvフ､fm)^ ､ゝ
　　　　　 /｀ｿ.　ゝ 〉ﾉ）ノ
　　（＼／　/「〉:=＝〈
　　 ,ゝと　ｿ /,, =＝ﾞﾞiﾌ 　　
　　 ﾞﾞ-‐'''　r'i⌒ﾞi''i⌒i 　
　　　　　　　|　　| !　 | 　　
　　　　　 ／　 丿 ゝ　｀ヽ,,_
　　　　 /､　　/　　　＼ ノ　''
　　　　iゝ'~~ﾞy　　　　 /ｪメ　!
　　　〈,,＿￣ _,,）　　 (,,＿_,,ノ

canopusLossless

TTAふぬああで使えね

おれバカだから計算できないんだけど、24bit RGB(無圧縮)って何メガbpsになるの？
　

普通に30fpsの動画とすると
　
(24bit * 3色) * 30fps ＝ 21.6Kbps？

640X480x24x30=221.184Mbps

thx！ありがとー！！ﾁｭｯ

Version 1.3.9 released on 06-22-2006
Fixed a memory leak that occurred with Adobe Premiere. Thanks to Alexey Gankov for reporting this bug and providing a patch.
Fixed a bug that allowed YUY2 and YV12 video to be decoded as RGB16.
Fixed the close button on the settings dialog box. Thanks to Zarxrax for reporting this error.

>>207
なんのコーデック？

>>208
>>185

RGB16って何？

RGB565かRGB555のことかと

軽めのキャプチャーソフトを色々と試しているんですが、
モノよってはコーデックにHuffyuvが選べません、っていうか選択肢に出てきません。
どうしてなんでしょうか？

このスレで聞かれても分かりません。そのキャプチャソフトの名前は何ですか？

キャプチャソフトの設定で、Huffyuvがサポートしている色空間にしないと候補に出ないよ
当たり前。
ちなみにキャプチャソフトのデフォがRGB565ってのは酷い。

レスさんくす。
今試したのはUlead VideoStudio 8 8SE。
YUY2、RGB24のどちらに設定してもHuffyuが出てきませんでした。

Lagarithってなかなかffvfwに取り込まれないね

ffvfwはlibavcodecのインターフェイスみたいなもん
libavcodecの開発者が興味を持たなきゃ永久に取り込まれることはない

300種類以上ある映像コーデックの中でも無名な方じゃないのか？

ふぬああで使うのにお勧めは？
Athlon XP 2500+(Barton)です。
Lagarithはまあ何とか使えます。

FFV1だめぽ　設定で何とかならないのか・・（全部ﾃﾞﾌｫﾙﾄ）
リアルタイム用ではLagarithが最強？
>>180見ると。

一応ふぬああでのキャプなら枯れてるHuffyuvがお勧め
Lagarithでもいいけど豚コア2500+じゃ負荷きついからドロップに気をつけてね

28.60secで244MB・・・
やっぱりHuffyuvでいいです。

結局実用的で汎用性のあるロスレス圧縮形式って何なの？

汎用性は要らないだろ。そんな形式で外部に持っていくことはまあ無いし。
圧縮率が1.x倍とか大して変わらないなら速さが最優先になるよ。
これは編集作業してみれば一発で実感できるはず。
15GBが13GBになっても、8分が10分になるんじゃ結局使わなくなる。

たとえば今DVDに焼くようなムービーは、DVDにおさまるように
非可逆圧縮しなきゃいけないけど、近い将来ブルーレイ等の次世代DVDや
新メディアが普及すれば、もっといい画質のまま焼けるようになるかもしれない。

そういうときのために生のままのデータを残しておきたいが、
残しておくにはムービーのサイズはあまりにも大きすぎるので
圧縮率が低くても少しでもサイズを減らしたいときに可逆圧縮はとても
便利だと思う。でも汎用性がないと将来使おうとしたときに
伸張できないとかいう事態を避けたいという事です。

ロスレス圧縮はどんなに頑張っても劇的にサイズが小さくなるもんじゃない。
12GBが11GBになったらこれは非常に大きな成果（飛び上がって喜んでもいいくらい）
で凄いことだが、使う側に立ってみれば50歩100歩でどう違うの？ってなるよ。

ってことは私の>>225みたいな使い方をする場合は
非圧縮aviとかを使ってればokってことですよね？

>>225
つまり汎用性というのは「将来のOSで再生できるかどうか」ということ？

VFWが存在してれば今のコーデックがインスコできるだろうし
もし廃止されてたらどのコーデックが生き残るのかははっきり言って不明。
無圧縮ならそりゃ確実だろうけど、そもそもavi自体をMSは廃止したがってるぞ。

>>228
そういうことです

>>229
aviも確実じゃないんですねorz

>>225
マイナーな形式でもなんでもいいから可逆圧縮で圧縮すればいい
今のOSが現役である限りはね

そのコーデックが次のOSで使えなくなると分かったら
そのときまた将来使える可逆圧縮形式で圧縮すればいい

>>231
確かに、可逆圧縮の強みを生かして必要なときに
圧縮し直すのがベストですね。

レスしてくださった皆さん、ありがとうございました。

TTAのDirectShow Filter キボン

>>233
ffdshowじゃだめ?

つttp://www.true-audio.com/TTA_Lossless_Audio_Codec_-_Directshow_Filters

それはaviutlでもhunuaaでもでてこない

aviutlとかhunuaaで使える音声の可逆圧縮のコーデックはないのだろうか

hunuaaでは無圧縮推奨。
音声データなんてもともと映像データに比べりゃ微々たるもんだから
可逆だと精々40%程度だし全体のファイルサイズに比べて殆ど効果なし。
たんに不安定にさせるだけ。

音声をOggDSにしたら1/4ぐらいになったような気がしたけど気のせいだったのか

OggDS・・・・

身も蓋もない質問で恐縮だが
XPの「ドライブを圧縮してディスク領域を空ける」フォルダに無圧縮(iso形式)と
通常フォルダにHuffyuvを比べると(容量的に)大差ないように感じる。
時間的には圧倒的に無圧縮が有利なわけで、可逆圧縮のメリットってなによ

>XPの「ドライブを圧縮してディスク領域を空ける」フォルダに無圧縮(iso形式)
>(iso形式)
>(iso形式)
>(iso形式)
>(iso形式)
>(iso形式)

エンコの中間ファイルとして可逆使ってるんだけど
Lagarithが一番かもしれんなぁ
Huffyuvが無難なんだろうけど、Huffyuvとエンコ速度的にそうかわんないのに
Lagarithのがぜんぜん縮む
CorePNGはHuffyuvよりは縮むけどエンコ糞遅いし微妙すぎた

中間に使う場合、エンコスピード、デコードスピードがほぼ唯一の要因となるけどね。
サイズは気にならないさ
（1〜2GB大きくたってそれが何？最終エンコし終わったら即削除なのに）

LagarithはHuffyuvの改良系だからそれでいいんだよ

とんちんかんなこといってるかも知れないけど
YV12のブツをLagarithで圧縮してMeGUIに渡してx264でエンコしようとすると
ConvertToYV12追加しろって怒られるんだ
Huffyuvだとこんなことないんだけど、LagarithでHuffyuvと同じように使えないの？

どうせLagarithの設定がYV12になってないだけだろ？

設定はYV12にしても改善しませんでした
スクリプトの書き方がおかしかったようで
DirectShowSourceからAVISourceで読み込む様にしたらMeGUIに怒られることもなくなりました
初歩的なことだったようですみません
DirectShowSourceで読み込むとRGB32扱いになるんですねー・・・

って、HuffyuvだとDirectShowSourceでも大丈夫だったんだよなぁ・・・
スキルないんで大人しくHuffyuvつかっときます('A`)

DirectShowSourceてあんた

可逆圧縮を非可逆方式でデコードするって正気の沙汰とは思えない

>>249
スキルないならおとなしくAVISource使ってろ
DirectShowSourceはAVISourceで読めないときに使うものだ

Lagarith codec and installer (v1.3.10)

This codec was build using the Huffyuv source as a template,
and uses some Huffyuv code, most notably the routine to upsample YUY2 video to RGB.
Other colorspace conversion routines were taken from AviSynth.

After Effects 6.5から
Huffyuvを使って書き出すと
動画の上半分が崩れていて
たまに、そのファイルを選択しただけでエクスプローラが落ちます。
これってメジャーな不具合なんでしょうか？
回避方法ってありますか？

>>255
Huffyuv 2.2.0だろ？それはRGBのバグ持ちで使えん。verダウンしろ。

確かに220でした。
散々悩んだのに、そういうことでしたか。
今、211を手に入れたのでこちらで試してみます。
ありがとうございました。

After Effectsでも問題なく使えるようになりました。
これが原因だったのか・・・・。

2.2.0でエンコードしたファイルは再生画が乱れるように
なってしまいましたがこれは仕方なしと言ったところでしょうね。

ありがとうございました。

Version 1.3.11 released on 11-12-2006

Lagarithは自ビルドした方が絶対いい

#ソース
ColorBars(640,480,"YUY2")
trim(0,2000)

公式     →5.5秒
自ビルド→2.5秒

びっくりした

Lagarith使ってるけど
なんでそんな違うの？
ビルドとかよくわかんないんだけど

どの環境でも安定して動くように
あんまり最適化して無いからだと思う

うｐしてみた
http://www.mediafire.com/?cyvmhyhkthm
※SSE2有効

動かなかったら↓いれてくれ
http://www.microsoft.com/downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-9c99-220b62a191ee&DisplayLang=ja

>>262
もう削除しちゃったの？
再うｐおながいしまつ。

>>263
画面右あたりの「Click here to start download」に注目。

インスコの方法わかんね
dellをsystem32に放り込んだだけじゃだめだし
公式ビルドのdelを>>262に置き換えてinfからインストール選んでも無理だし

使った事ないし分からんけど、
公式ビルドをインストールしてDLLを置き換えじゃないの？

vcredist_x86.exe入れても動作しないので、本家の入れた。

再ビルド+inf
ttp://www.mediafire.com/?8nmxyzdnzrr

ランタイムいらないようにした
262が使えるならそっち使ったほうがよいと思われ

わざわざありがと
Athlon64X2 3800+なんだけど、同じソースで公式と比べてみたら
公式で17分かかってたやつが>>268だと12分になった

非常に興味があるんですがAthlonXPなどのSSE2に対応していないCPUでも動きますか？

動くと思います

でも一応あげとこうかな?SSE有効ビルド
http://www.mediafire.com/?coxfvnowzoj

てかコンパイル環境何？

VS2005Expです
アセンブラはVisual C++ 6.0 Processor Pack内のMASM使用

後､262はバグあったので削除しました

わかりにくくなったので再うｐ

SSE2対応
ttp://www.mediafire.com/?8nyfdjzw2jo
SSE対応
ttp://www.mediafire.com/?coydmnqt1zm

どちらもランタイム必要無し&inf付

otu

これが本当のビルドうｐ

Version 1.3.12 released on 11-17-2006
Fixed a bug introduced with 1.3.11 that would cause the codec to crash when multithreading on processors without SSE2. Thanks to Ken Schultz for reporting this bug.
Fixed a memory leak introduced with 1.3.11 when downsampling the colorspace during compression.
Fixed a possible deadlock situation I missed in 1.3.11.
Tracked down and fixed the cause of a bug that would cause frames to occasionally decode incorrectly when multithreading was enabled. I though I fixed this in 1.3.11, but I had only reduced the severity so that it usually only affected one or two pixels.

Lagarith公式潰れてないか？移転？

Lagarith1.3.12エンコの最後でメモりアクセスでエラーでる。

Lagarith公式復活age

報告乙

Huffyuvでエンコしたんだけど
画質が暗くなっちゃうのは、設定が悪いのかな？

うん

>>283 THK
predict median(best) ←convert to YUV2
に設定してますが、他にいじくるところあるの？

誰がコーデックの設定だといった？
受信機の設定いじりな

ゲフォだとコントラストが落ちるかも。
ソースRGB表示->HuffyuvでYUY2に強制変換->YUY2をゲフォでオーバーレイ表示
だとゲフォはYUVオーバーレイがストレートRGB変換だとか言ってた気がするし。

>>285>>286
ありがとう

Lagarith圧縮率高いな
FRAPSコーデックで圧縮された動画が3分の1に縮む

高いけどCPU負荷がhuffyuvより高くてコマ落ちが激しい
Pen4の3GHzなのに…何か設定間違えてるんだろうか

入力とカラースペース合わせないと変換入ってめちゃくちゃ重くなるが

>>290
調べ方&やり方を詳しくお願いします

調べ方:とりあえず非圧縮でキャプってAviUtlとかで開いてフォーマット見る
やり方:設定開いて選ぶ
こんなこともわからないのか？

わからんから聞いてはるんやろね

LagarithってTMPGenc2.5で読み込むと赤と緑のノイズのる時あるな

Lagarithのマルチスレッドにバグあるみたいだからオプションでチェックしないように

シングルコア(Pen4)でも頻度は(C2D)より少なくなるけどノイズ出てるよ

圧縮率が一番高いと謳うMSU Lossless Codecってどうなん？
使ってみてやたらおっそいからスルーしたけど

Huffyuvの後継がLagarithのようである
http://en.wikipedia.org/wiki/Lagarith

Speed; while not as fast as Huffyuv, encoding speed is comparable to many other lossless video codecs, although decoding speed may be slower. Recent versions also support parallelizing on multi-processor systems.

>>33-37
これ見て入れてみました。
デフォルトの
Lossless compression で Enable prediction オン Realtime で
Huffyuv や Lagarith と余り変わらない速度、そしてサイズになりますね。
再生は重いけど中間ファイルとして使う場合は、エンコの時間さえ早ければいいから使えそうだ。
デフォルトではチェックが付いていないけど
Source video の Adjust interlace はインターレース有りの意味になるのですかね？
だとしたら付けないとダメですよね？

Alparysoftはデコードがネックだわ
MPEGなりにエンコする時間がHuffyuv や Lagarith に比べると倍ぐらいかかる
>>36は２年前だからバージョンアップで状況が変わってるみたいだ
この設定にするとデフォの７倍ぐらい時間がかかるのにサイズも大きくなるぞ

・MSU Lossless Video Codec
http://www.compression.ru/video/ls-codec/index_en.html#Download

　「圧縮率に自信あり！」と歌うcodec。
　公式サイトを見る限りではダントツの圧縮率を誇る。

・LCL
http://www.geocities.jp/sandk_project/LRC.htm

　かなり昔からある純国産コーデック。
　pngフィルターやnull flameを実装しており、オプション選択することが可能

・HUFFYUV
http://cowscorpion.com/Codec/HuffYUV.html
HuffYUV2.2.0-Win32ロスレスビデオコーデック (公式サイト不明・・つか消えてる？)

　LCLと同じく昔からあるcodec
　知名度はほとんど同じなものの、速度・圧縮率共に若干上回る。
　公式サイトが消失している為ダウンロードサイトからしか入手できない

・Alparysoft Lossless Video Codec
http://www.alparysoft.com/products.php?id=9&item=35

　企業によるLosless codec。
　メーカー商品にも関わらず完全無料なところがありがたい。
　同サイト内にjpeg2000云々があるが、motion j2k codecの開発も進めているのだろうか？

・Luna AVI lossless video codec
http://www11.plala.or.jp/russianblue/luna/luna.html

　純国産lossless codec。
　知名度は今ひとつなものの1/5〜1/3程度の圧縮率を誇り、huffyuvよりも良好な圧縮率を誇る

・CorePNG
http://www.free-codecs.com/download/CorePNG.htm

　オープンソースによって開発が進められているcodec。
　名の通りpngを圧縮アルゴニズムに採用している。
　公式サイトは　http://corecodec.org/projects/corepng/　のはずだが、なぜかアクセスできないのでダウンロードサイトにリンク

・FastCodec
http://videosoft.org/codecs/

　高速圧縮を目指したロスレスコーデック
　名前が非常にわかりやすい
　（なんて紹介文だ；；）

・LZOcodec
http://usuarios.lycos.es/lzocodec/

・Lagarith Lossless Video Codec
http://lags.leetcode.net/codec.html

　あー・・；；ここまでくると紹介しようが無くなってくる。

　また、このほかにもjpeg2000 codec project　があるが、現状ではデコーダ（再生）しか提供されていない。

仕事人現る！激しく乙

乙

>>301-302
どこかで見た文章だ

見つけた
ttp://nex.xrea.jp/index.php/date/1167147881

・Lagarith Lossless Video Codec
http://lags.leetcode.net/codec.html

Huffyuvの後継コーデック。Huffyuvソースを一部使用している。
圧縮速度はHuffyuvより劣るが圧縮率は前者を凌駕する。
YUY2で圧縮すると更に縮む。

YV12で圧縮するとさらに縮む。

なんか俺の環境だとLagarithのがHuffyuvより圧縮速度も圧縮率もいいんだよなー

YV12じゃかなり重くなりそう

最近のクアッドコアとかならLagarithでリアルタイムキャプしてもコマ落ちないんじゃね

>>301
HUFFYUVはffdshowでエンコ・デコするのがお勧め
オリジナルじゃデコードできないけど、YV12も対応してる

scalefacの意味を教えてください。
ググってもいまいち引っかかりませんでした。

TMPEGenc 4でLagarith使うとよく変なノイズが混じるんですけど。
他に同じ症状の方います？
ちなみにDubやAviUtlだと大丈夫なんですが。

他の可逆コーデックでも試してみるかな〜(ﾟεﾟ)

>>314
>>294-

>>315
書き忘れましが、マルチスレッドチェックしてもしなくても
ノイズでます。

メールで報告するという事が出来ないのかね

FastCodecが一番速いな．．．
PenD3.0Gで６０ｆｐｓエンコできる。

Ｈｕｆｆｙｕｖｓなら１２０ｆｐｓでウンコできるがな．．．

Huffyuvは最終音声にノイズが載る
Lagarithは最終画像にノイズが載る
結局、市販編集ソフトとも相性がいいAlparysoftで中間作ってる

そりゃお前の環境が腐ってるせいだろと

音声にノイズが乗るとかどう考えてもコーデックのせいじゃねえｗ

>>322
再生の時に映像が遅れた場合に音声が同期をとるような感じ
音声がダブったり、と切れるような感じになる所が出る
音楽番組を録っている俺的な、だめ出しだから
中間のHuffyuvではならないけどmpegなりDivXの最終エンコでなる。

リーブ２１すりゃイイじゃん．．．

お

Huffyuvって何て読むのよ。
ふっふぃゆぅヴ？

フゥフュヴイ

どもども

ああ・・・

はっふぃゅーヴぃ

〉〉330よめねえw

はふわいゆーう゛い

アホな質問だったらｽﾐﾏｾｿ・・・
可逆圧縮って、
デコードすると、元のAVIとバイナリまで完全に一致するファイルが取り出せるんですか？？

ファイルとして一致するかはどう出力するかによるだろうね

すみません・・・もうちょっとわかりやすくお願いできますか？

ファイルとして一致するかはどう出力するかによるだろうね

Lagarithて適当にクロップして変な解像度ではきだすとファイルサイズ
増えるみたいね。
試しに黒ペタ追加して縦横とも16の整数倍になるようにはきだしたのと
くらべたら2：3くらい差がでた。

解像度弄りゃそりゃあ・・

元々縦横比が定番であることが前提で圧縮率稼いでたりするものだし…

>>335
aviファイルには、画像データ以外にも管理用ヘッダ情報とかのファイルとしての付属情報が付く。
これはアプリケーションによって内容もサイズも異なってくるのでその辺を考慮して！
さらにaviファイルだと画像ストリーム以外にも音声ストリームやデータストリームが別に存在する
こともある。この場合、音声データもまったく同一だと仮定したとしても、
インターリーブ値が変われば当然ながらブロック管理データもインデックス値も変わってくる。
可逆なら純画像データだけは一致するってことは言えるが、ファイルとしては
そのファイルをどのように作成するか、その点にかかってくる。

画像と音声が一致すれば実用上はそう問題ないと思うけどな。

ファイルとして一致するかはどう出力するかによるだろうね

色空間の知識がないと、うっかり間違えて色空間変換をしてしまって可逆にならないってこともあるので初心者は注意

http://wiki.multimedia.cx

sage

huffyuvｵﾜﾀ

むしろLagarithあちこちで取り込んでください…
Win上オンリーでしか使えない不便さがどうにも

保守

秘酒

MSU

FastCodecよりLagarit YUY2の方が早い、俺の環境の場合

huffyuv2.1.1使ってPremierePro1.5で書き出しても大丈夫なのに、
PremierePro2.0で書き出すと画面上にノイズが乗るんですが。
原因分かるエロイ人教えて。

そこでCCEPatchedとかffdshowvfwですよ

Lunaってどうなんですか？

ｵﾜｯﾄﾙ

そうですか、どうもです。
あきらめてPremiere1.5でやることにします。

かわりにLagarithでも使ってればいいじゃない

Lagarithで出力しても画面上方に色ノイズが出ました。
Premiere2.0と何かがダブルブッキングでもしてるんでしょうか？

とりあえずどんな物を出力してるのかわからんけど
16の倍数じゃないとノイズが入るとかそういうのあるけど解像度大丈夫か？
意外とRGBAだとノイズ入らないとか不思議現象もある
むしろffvfwにあるHuffyuvやLosslessJPEGでも
そのノイズ入るのかよければ試してもらいたいんだが・・・

>>359
これから試してみて後で報告します。

あ、ちなみに解像度は640×480です。

ぐぐっても特に情報出てこないな
TMPGでもノイズ出るコーデックあるが、Huffyuvで問題は聞いた事ないし
多少なりともなんか原因はあるとは思うんだがな…
最悪Adobeにｺﾞﾙｧメール入れるとかしてみないと、わからないかもしれない

試してみましたがやはり画面上方に滲んだノイズが入ります。
メールして聞いてみます。
Pro1.5のときに大丈夫で2.0でノイズが入るってことは2.0の何かがおかしいみたいです。
他のエンコソフトを体験版含めて片っ端から試してみましたが綺麗なもんです。
Premiere2.0だけHuffyuvだけでなく可逆圧縮のほとんどのコーデックでノイズが乗ります。

(´･ω･`)知らんがな

でも363読んだからもう知ってるがな

>>363
全然関係ないと思うけれど、ドライブのルートにファイル書き出してるとか。

Premiere Elements 3.0は、ドライブのルートに書き出すと、
正常に書き出せないことがあるとかって、書いてあった。

363です。

>>366
どうもです。
別のドライブにも書き出してみます。

>>366
外付けドライブに書き出してみましたが同じでした・・・orz

>>367
あと、Premiere Elementsで、ffdshow_beta2a_20070322_clsid.exeの
huffyuvsとか試したら、こっちでもノイズ乗ってた(´･ω･`)

でも、単品のhuffyuvsとかlocoは、大丈夫だったよ。
一つ前のLagarithは、エンコード終了時にPremiereがクラッシュしてた。

>>369
レスどうもです。
単品の2.1.1でやりましたがだめでした。
Lagarithは同じくプレミアが強制終了してしまいました。
Premiere1.5まではhuffyuvsで問題なかったのでかなりショックです。

自分が持っている4種類有る編集ソフト全てに相性問題が出なかった
Alparysoft Lossless Video Codec を使ってる
デコードのスピードに難ありだけど....
色々試した結果このコーデックに落ち着いた
何故か無料なのにレジストしないと動画にロゴが出るので注意

んなめんどくせえもん使うかよ

>>372
コピペも出来ない低脳乙

エンコスピードはキャプチャ時CPUに余裕があれば十分
容量も可逆圧縮だと目くそ鼻くそなのでどれでもいい(13GBが12GBになっても嬉しくない）
だがデコード速度は編集してエンコする派には命ともいえる最重要点

問題ないならhuffyuvsでもLagarithでも使えばいいじゃん

Lagarithは異常だぞ…アニメとかベタ塗り多いとおかしいくらいに縮む

Lagarithは異常というか環境限定されすぎ
TMPEGencでmpegを作るとノイズが乗る
MeGUIでH.264/AVCを作るのにYV12のモードにエンコすると白黒の映像になる

結局、あう゛ぃコンテナのDivXビデオ専用じゃん

TMPGencとは相性悪いね。AVviUtlとかVirtualDubなら問題ないよ。

MeGUIで使ってもなんともないが

>>377
ちょっと待て
ウチMeGUIで使ってるけど白黒なんてならないぞ
環境いかれてないか？

横槍でスマン
MeGUIは関係ない
aviutlでLagarithのmodeをYV12でエンコすると
自分も白黒になった記憶が....
ただ、MeGUIがYV12と違えばavsにコマンドが追加されるからYUY2のまま読み込ませられるよ

あー
MeGUIで白黒になったのでは無く
中間ファイルの時点でなっていたのか
MeGUI使いの方お詫び申し上げます
Lagarithは使える人だけが使えばいいじゃん

こういう知ったかぶりのクズしか居ないから困る

煽るばっかで実はマトモなアドバイスも出来ない輩がのさばるからますます困る

もちろん俺もその手合いだけどな

>ただ、MeGUIがYV12と違えばavsにコマンドが追加されるからYUY2のまま読み込ませられるよ

本当だ
ConvertToYV12()
が追加されているのねん
追加されていても同じエラーが出るのは
再読込をする必要が有るのねん
再読込も自動なら完璧なのに・・・

結局Lagarithは糞って事でFA?

いや普通に使えるだろ、バグも特定の場合以外でないから気をつければOK！
あの圧縮率はやっぱみりきてきだろ。

�_奇的

だからLagarithは使える人だけが使えばいいじゃん
相性問題で悩んでいる人はAlparysoftを使えばいいじゃん
後は好みでhuffyuvsでもFastCodecでも使えばいいじゃん

やった事の結果を書いただけなのに、煽るばかりで無く>>381の様に的もなアドバイを書けばいいじゃん>>383

Huffyuvが無難。どうせ中間ファイルにしか使わないもんだし

全部マルチスレッド対応してるの？

Lagarithは対応してる

>>391
それ有効にすると色ノイズ大量生産になる

うちだと完全可逆でSSIM1になるんだが・・・

Lagarith Lossless Video Codec v1.3.13

ソースも更新しておくれ

ttp://uploader.fam.cx/img/u9485.bmp
この位の劣化はしょうがないものですか？
あごのあたりが目立つ

無圧縮の色空間はRGB24ですか？
それともYUV444？

マッハバンドとかいう奴かな？

>>398
RGB24です

試しに>>397の画像をHuffyuv v2.1.1で出力してみたが
可逆圧縮だから当然だけど劣化は全く起こらなかった。
途中に何らかの処理が入っているんじゃない？

それとも、>>397が
「この程度のマッハバンドは、ノンリニア編集ではしょうがないもの」
という意味で言っているのなら、俺には何ともいえないです。

YUY2でやるとそうなる

現在WMPで可逆圧縮で取り込んでいますが
HDDの容量がばかにならないため
MP3（128ｋ）にしようかと思っていますが当然
音質が落ちますよね、しかし私の耳では
どちらでもそう変わりない気がしますが
実際のところどうなんでしょうか

不可逆圧縮なんだから音質が落ちるのは当たり前だろ
問題は人の耳にその音質の劣化が分かるかどうか
ソースにも依るけどMP3 128kbpsなら音質の劣化を認識できる人はそう多くはいないと思われる

128kbpsで取り込むんだったらMP3よりAACやWMAやOGGの方が優れていると思うんだが

>>404
ありがとう。
やはりそうですか。

HuffyuvはソースがYUVであればそのまま、RGBであればRGB→YUV4:4:4変換をして
ハフマン符号化により圧縮し、デコード時は元のフォーマットで出力する、という流れで
しょうか？（「Convert to YUY2」設定を除く）

GraphEditで、
「HDYC4:2:2ソース」→「AVI Decompressor」（YUV4:2:2に変換）→「Huffyuv」→「AVI Mux」→「File Writer」
という流れで.aviファイルにすると、サンプルサイズが24bitになります。
それで、AVIUtl0.99に読み込ませると、色バグが起こることから、HuffyuvはRGBでAVIUtlに
渡しているようです。

Huffyuvの挙動が把握できないです。

ttp://www10.plala.or.jp/p205tb16/colorghost.html
すみません、このページを見ると、色バグが起こるときというのは、Huffyuvが
YUY2でAVIUtlに渡したときに起こるみたいですね。
ということは、AVI Decompressorから渡されるYUV4:2:2はRGB変換を行うことなくHuffyuvで
可逆圧縮保存される、と解釈したくなりますが、そうすると保存ファイルの24bitが理解できません･･･。

>>407
Huffyuv211なら、Enable console-window loggingにチェック入れてアプリを再起動。
それでファイルを読み込めば、コンソールウィンドウが開いて
圧縮のbit数/method種別とDecompress出力のbit数等が表示される。

DecompressBegin: input = HFYU, 16 bits, method 0, output = 0, 24 bits

FourCC HFYU=Huffyuv圧縮
16bit=YUY2 24bit=RGB24 32bit=RGB32/RGBA
method : 圧縮type 0=Predict left 1=Predict gradient 2=Predict Median (16bit時）
　　　　　　　　　　　　0=Predict left/no corr. 64=Predict left 65=Predict gradient(24/32bit時)
　　　　　　　　　　　　0,1,2=<- Convert to YUY2 (YUY2のmethod指定に従う） (24bit時)

なお、RGB24/32/RGBAはConvert to YUY2指定時を除いてそのままのフォーマットで圧縮する。

>>408
とても詳しく、ありがとうございます！
おかげさまで、.aviファイルのプロパティで24bitと表示される謎が解けました。

まず、.aviファイルを選択した時点で、エクスプローラーからのDecompressQueriyに対して
24bitRGBで返しています。（サムネイル用画像用）
その後、右クリック→プロパティと進めて、再びDecompressQueryが来るのですが、このとき
outputは(null)となります。
それで、直前の24bitがそのまま表示された、ということのようです。

ありがとうございました！

Huffyuv220だと、console-windowが開かないね。
それにRGBの圧縮も正常にできないし。

Lagarith 速度 C　圧縮率 A

FastCodec 速度 S　圧縮率C

Huffyuf 速度 A　圧縮率D

MSU 速度 E　圧縮率 S

lagarth Version 1.3.14 released on 7-20-2007
Fixed a bug that would corrupt video when downsampling to YUY2 and the resolution was not a multiple of 32.
Fixed a bug that would cause crashes when downsampling to YV12.
Restored manual installation instructions to the readme for people having problems with the install.bat file.

ttp://slashdot.jp/article.pl?sid=07/07/27/0034216
これはやくコーデック化してくれぇ！

lagarthバージョンアップしてるな・・・色ノイズは解決されているのかな？

マルチコア対応のHuffyuvがあるらしいのですがご存知の方いらっしゃいますか？

>>260氏のビルドまだ？

CamStudio Lossless Codec
ttp://sourceforge.net/project/showfiles.php?group_id=131922
話題になったところみたことないから多分しょぼいんだろうな……。

>>417
ほんとに可逆圧縮なのか・・・？
SWFに変換できるよと書いてあるけど

>>418
ごめんごめん、書くの忘れてた。
Camstudio自体は単なるキャプチャソフトで、
肝心のコーデックはそのページの下のところのCamstudioCodec-1.0-w32.zipです。

>>417
CamStudioもfastcodecもLagarithもそうだけどhuffyuv以外は
キャプチャで失敗するのなんでだろう。

コーデックの比較をちょっとしてみたよ。
キャプチャソースは1920x1080を28分
huffyuv:54.7GB
fastcodec:31.0GB
Lagarith(YUY2):22.2GB
Lagarith(YV12):15.5G
ただ、LagarithのYV12はプログレッシブで保存されるので
インターレース素材には使えないけど
それでもLagarith作った人は天才だね。

>>421
それキャプチャソースはHDDに保存してあるファイルから、
それぞれのコーデックで圧縮したんだよな？

問題はリアルタイムキャプチャでコマ落ちしないためにはCPUがどれくらい必要かだな。

ところでたいした知識がないので常識だったら申し訳ない質問なんだが
可逆圧縮にインタレとかプログレッシブとか関係あるのか？

>>422
キャプチャソースが同じじゃなきゃ比較にならんでしょ？
キャプチャ開始と終了は数秒違いはあるけど誤差と思ってくれ。

>>423
ＣＰＵは[email protected]でＣＰＵ使用率はプレビューありで
LagarithがYUY2なら90%くらいYV12なら80%くらい
ちなみにhuffyuvは正常にプレビューできるけど
Lagarithとfastcodecのプレビューはこま落ちしまくり
キャプチャには問題ないからそこは心配なし。

可逆っていうのは圧縮の前後で可逆という意味であって
オリジナルソースと可逆という意味ではないよ。
ざっくり言うとオリジナルソースをAとしたら
それから作られるYUY2データがB
YV12データがC
BとCをそれぞれ可逆圧縮しても元が別なんだから別物でしょ？

で、プログレッシブのYV12はフィールドが混ざるのがだめ。
症状としてはコーミングが出るところで色が混ざる。
インタレのYUY2ソースをプログレッシブYV12とYUY2でキャプチャしたらわかるよ。

ああ色変換のところで劣化するってことか。理解した、ｻﾝｸｽ。

Lagarith 速度 C　圧縮率 A

FastCodec 速度 S　圧縮率C

Huffyuf 速度 A　圧縮率D

MSU 速度 E　圧縮率 S

>>426
SはAよりいいの？

Aはきす
Bはぺってぃんぐ
Cはxxx
Sになると…

>>416
ソース公開され次第、うｐする予定だから待っててね

早いのはいいけどデータ正常に一致してる？

>>424
インターレース素材をプログレッシブでキャプチャーしてもなんか大丈夫なんじゃない？
AVISynthのスレとか読むとフィールドを分離だのって話してるし

>>426
今色々なソースで試したけど、fastcodecの圧縮率Cは有り得ない
極僅かな差でhuffyuvの方が縮む

lagarith最新版でもPremiereProv7.0の初期版だと
いまだにレンダリングできてもクラッシュするAVIができあがるだけだなあ

いいかげんPremiereアップグレードするか(´Д`)

Lagarith1314とFastcodecでキャプチャすると
逆テレシネができなくなる
おれだけかな？

テレシネパターン一定のソースで
doubleweaveしたときに縞の現れるパターンに
規則性が見られない
TFF、BFFのどちらでもおかしかった。
でもhuffyuvでキャプチャすると特に問題なし。

Lagarithとfastcodecのデコードに問題があるのかも？

どうもキャプチャしたファイルだけ
フレームデコードの問題が発生してる。
VirtualDubでエンコードしたファイルは正常だ。
何が悪いんだろう？

可逆圧縮の形式って普通に再生すると同じ解像度の非可逆より重いな。
エンコードが早いからデコードも軽いのかと思ってた。

ファイルサイズが大きい分、
HDD読み込みのオーバーヘッドが大きいからな

あ、CPUを結構使用するってことね。

可逆でキャプルならRAID0、これ常識

俺の場合、ふぬああでLagarithを使って録画しようとすると必ずコマ落ちする。
Huffyuvなら問題ないので、録画にはそっちを使っている。

D4キャプチャでE6400だとHuffyuvで20%前後、Lagarithだと80%越える。
圧縮率は魅力的だけどこの負荷だとコマ落ちが怖いので俺ももっぱらHuffyuvだな。
せっかく開発が進んでる新しいコーデックで色空間もいろいろ選べるから
使ってみたいんだけどなあ、ちょっと残念。

ああもうひとつ理由がキャプチャ時のプレビューが紙芝居ってのもある。
数分のキャプチャでは一応ファイルはコマ落ちしてなかったが精神的に不安だな。

容量に十二分な空きがあるなら、コマ落ちするときは非圧縮でも良いだろと思ったり

fastcodec使え

>>444
fastcodecの1.0beta使ったけど
こま落ちしたよ・・・
どのバージョンならいいの？

Lagarithで圧縮した物を7zのLZMA圧縮かけたら更に知人でワラタ
写真みたいな静止画が連続したような動画だと1/6くらいに縮む

1/6って6Gが1G程度に縮むの？すごくない！？

静止画なら全然すごくない

ヌルフレームつかってないなら全然すごくない

ﾇﾙﾇﾙ恩にしたらすごいすごい

マルチスレッド対応ないの

Huffyuvってそのままアルファベットで読めば良いの？

俺は脳内で「ハッフユブ」と発音してる

ハフマン圧縮のyuvだから、はふゆぶとかよんどきゃいいんじゃね？

http://speeddemosarchive.com/kb/index.php/Analog_Capture
ここにはpronounced "Huff Why You Vee,"って書いてあるが

翻訳すると、"はふぃゆーヴぃー"と発音する、かな？

YUV は、そのまんまということだろ

>>456
はふ　わい　ゆー　う゛ぃー

だな

マルチスレッド対応のhuffyuvってニーズあるんだろか。
いや、うちで使うのに嫁が作ってくれたんだけどね。
Lagarithほどの圧縮率はいらんから、ふたつのコアを効率よく使えるようにしたいと
思って作ってもらった。
AthlonX2 BE-2350使ってIntensity-ふぬああでキャプチャして、フルHDサイズの
動画がコマ落ちしなくなったよ。

自己責任で使ってみたいって人がいるなら、ソース綺麗にしてからどっかにアップ
するって言ってる。＜嫁

>>459
すごい嫁だな

>>459
もちろん是非欲しい
マルチスレッドでLagarith動かすと結構不安定だからさ

>>459の嫁は化け物か！

持つべきは化け物の嫁だな

なんかいやなフレーズだなｗ

>>459
ぜひお願いする。

zipで嫁うｐ

俺もマルチスレッドの嫁が欲しいのでハッシュpls

嫁はやらんがなｗ

なんか意外に反響あったんで、ソースきれいにしてオプション設定項目をもうちょいいじって、
明日あたりアップしてみるね。
アップ先でどっかいいとこあったら教えて欲しい。

ソースクレクレ
そしてff系に取り込めると幸せ

ひさびさの新ネタ
huffyuvって枯れまくってると思っていたけどこんなところであたらしい亜流がでてくるとは
encもdecもマルチなのかな？
ソースを見たことあるけどマルチで実行するのって結構面倒かと思った
どんな単位で処理を分けるんだろう？
どんな実装になっているのか興味津々
・・・なんてことを言ったせいで公開が遅れたら鬱

というか妻すごすぎ

はふ　わいふー　う゛ぃー

だな

>>472
誰が下手なことを言えと言ったwww

脳内って見てて寒いよ

お待たせです、嫁謹製のマルチスレッド版をアップしてみました。再配布はご自由に。
ソースも同梱されてるんで、改良できる部分があれば誰かお願い。
http://iroiro.zapto.org/cmn/jb/data/jb4667.zip

>>470
俺はプログラミングは素人なんでうまく説明できるか自信ないんだけど、以下嫁の話のまとめ。

オリジナルのHuffyuvの処理をそのままマルチスレッド化するのは確かに難しい。
内部処理でマルチスレッド化できる部分をなんとかマルチスレッド対応にしてみた。
出力されるファイルはオリジナルと互換性あり。
　↓
どうも期待したほど高速化しない。
更にアセンブラコードに手を入れたり、いろいろ試すがうまくいかず。
　↓
ぶち切れてオリジナルとのファイル互換性維持を断念。
動画フレームが入力された時点でコア数に応じてフレームをぶった切り、ぶった切られた
フレームそれぞれを各コアに流して圧縮処理実行、処理完了後のフレームをくっつけて出力、
というすさまじく乱暴な処理を行うことにしたんだそうな。
デコード時には、圧縮時に分割された数に応じたスレッドが生成されるらしい。
なので、デュアルコアCPUのPCでキャプったデータを4コアCPUのPCで再生させても
4スレッドは立ち上がらない。
逆に4CPUのPCでキャプったデータをデュアルコアCPUのPCで再生する場合は、
2スレッドずつ1コアに流す形で実行する形になるんだって。
一応生成スレッド数を設定するオプションをつけてあるので、デュアルコアCPUで
4スレッド、8スレッドを生成することも可能。
ただしスレッド分割のオーバーヘッドは発生するんで、効率はよくないかもなぁとのこと。

という感じでずいぶん強引な方法でマルチスレッド化をやっていて、なおかつオリジナルのHuffyuvで
出力されたファイルはマルチスレッドで再生できないんで、あんまり期待しないでね、と＜嫁
あくまでこの改造版でキャプったデータを、この改造版でデコードという使い方を想定してます。
試して大きな不具合があれば、ここに書いてもらえば嫁に伝えます。
嫁は基本的に2ちゃん見ない人なんで、俺が代わりにここでの対応はしますですよ。

>>475
りんちゃん乙

これが後に>>459氏嫁と呼ばれるウィザード級ハッカーの誕生である。

これは47氏を超えたな
459嫁

いやRinちゃんだろ

俺嫁と結婚してもいい

嫁をマルチスレッド化

むしろこの嫁はマルチスレッド済みだな

しごくよめ。。。。。。。
えっち

>>459
嫁に愛してるって伝えておいてくれ

凄いんだけど、これを入れていないPCでは
見れないのか。

で、みんなこれ使ってみた？

>>459
凄すぎる、このＭＴ版huffyuv使ったらエンコ速度も上がったよ。
公開してくれた459さんとその嫁さんに最大の感謝を<(_ _)>

しごく嫁すげーーーーー

DLしてみたが嫁が入ってなくてがっかりだ

俺の嫁入りだった

嫁の仕事っぷりに惚れた

もしかしてえりかとさとるの関係者かい

>>421 >>424
凄い亀レスですまんが、LagarithのYV12ってﾌﾟﾛｸﾞﾚというのはどこソースか教えてくれまいか。

フィールドが混ざっているように思えないだよなぁ…

可逆なのに混ざるとか普通に無いから…

Huffyuvマルチスレッド互換性無いのに同じ名前だとちょっと厄介になるから
できれば変えてほしいと思うんだがどうだろうか

Huffyomeでおｋ

お前天才だな

>>493
自分は421じゃないが、
> インタレのYUY2ソースをプログレッシブYV12とYUY2でキャプチャしたらわかるよ。
って書いてあるじゃないか。
YUY2ソースから内部でYV12に変換する時に、インタレとして扱ってないし、
そういうオプションもない。
要するにLagarithに変換させるとダメってことだね。
インタレYV12としてLagarithに入れて、出す時もインタレYV12として扱えば問題ない。

おまえらなんで

嫁

ってところにやたらこだわるわけ？

なんでって・・・
嫁が組んで夫が公開するなんて面白すぎるだろｗ

反応した奴には縁遠い言葉だからじゃね？

wktkしながら試してみたが、よく考えたらうちのPCシングルコアだったｗ

たしかに名前は変えてほしいね
huffyomeはともかく、命名権は嫁にあり

やっぱりマルチスレッド化は難しかったか
それぞれのスレッドがはき出すhuffmanのビットストリームをつなぎ合わすのどうすんだろうとか思ってた
エンコードはまだしもデコードはストリームのどこからスレッドに分ければいいかの判断ができない気がしたし
偶数フレーム、奇数フレームとかで分ければいけるのかな？とも思うが、
エンコード時にスレッド分のフレームを渡してもらえなければ処理できないし

一時期、CUDAを使うように移植できないかなとか考えてたんだけどそこらで挫折したんだよね
脳内でだけど

とりあえず動作確認した人間は環境さらして報告しては？
かくいう自分はまだインストールもしてませんが

別に普通に使えてるから動作確認も何もない。

自分もPCもシングルなので意味がありません＞＜

じゃ報告倍近く速くなりますた。
　　　　　ﾍ⌒ヽﾌ
　　　　（　・ω・）　�d
　　　　/ ~つと）

じゃ報告嫁はプログラマーにしようと決めました

ﾄ
　ﾝ

huffrinがあるときいてきますた

60fpsくらいでて正直HDが追いつきません

>>497
あ、なるほど!人に教えるセンスアルね。thx!

正常に動いてるみたいでよかった、検証報告thx＞試してくれた人

>>494
>>502
うーん、名前を変えて欲しいってのはすごくよくわかるんだけど、正直抵抗あるのよね。
まったくの新規コーデックってわけじゃなくて、圧縮/伸長のアルゴリズム自体はHuffyuvの
ままらしいのよ＜嫁談
嫁のやったことは、例えばPhotoshopがバージョンアップしましたってなレベルの話でさ。
CS3のファイルは5.5では正常に開けないけど、Photoshopであることには変わりないでしょ。
それと同じようなもんだから、これで名前変えちゃうのは他人の手柄横取りしてるようなわけで、
俺らふたり「それはできんよなあ」と意見が一致した。
マルチスレッドモードのチェック外すと、オリジナルのHuffyuvと完全に同一の動作して、
互換性のあるファイルが出力できるわけだし、勘弁してもらえんだろうかというのが本音。

>>503
圧縮時のみマルチスレッド対応のものだったら、ファイル互換性保ったままで行けてたんだけどね。
圧縮後のフレーム末尾に12バイト分のデータを付加して、そこに分割位置の情報を書き込むって
処理をしていたようで、オリジナルではその12バイトの領域を認識しないので、オリジナルでも
読めていたんだって。
うちで検証した結果、このバージョンでは確かにキャプ時にはマルチスレッドで動作するんだけど、
再生時には全くと言っていいほど効果がなく、再生を速くするためにってあれこれ試行錯誤した
結果がこないだ公開したバージョンというわけで。

>>512
名前ですが、マルチスレッド版でしか再生出来ないのでしたら
名前で分かるようにしないと混乱しませんかね？
まったく別の名前とかじゃなくて、お尻にMTとかなんとか付けるとか
単純なもので良いと思うのですが。
ご再考お願い致します。

俺もそう思う基本的にアップグレードしてるわけじゃなく全然別物になってる
（互換性がない）わけだから名前変えない方が失礼かも。

>>513
>>514

やっぱりね、別の名前でリリースするのはどうかと思うのよ。
なので、例えばファイル名を「huffyuv_mt.dll」にして、コーデック選択画面で出てくる名称を
「Huffyuv v2.1.1 - Multi-Threading Patch v1.0」にするっていうのでどうだろう。
バージョン表記画面もちょいといじってさ。

これで同意してもらえるようだったら、変更加えた上で改めてファイル公開し直すけど。

あと、俺が誤解してるようだったら申し訳ないんだけど、「Enable Multi-threading mode」の
チェックをオフにしておけば、Huffyuv v2.1.1 - CCESP Patch v0.2.5 と機能的にも出力ファイル
も変わらないというのは理解してもらってるんだろうか。
なので、仮にHuffyuvで出力したファイルをどこかで公開するということであれば、MTオフにしてから
出力してもらえば、オリジナルのHuffyuvが入ってるPCでも問題なく再生できるファイルができる
ということになる。
確かにMTをオンにしてから出力するファイルはオリジナルと互換性がないんだが、MT版DLL自体は
完全に互換性を捨て去っているというわけではないことはわかっておいて欲しい。

はっきり言って名前なんてどうでもいい

1920*1080の無圧縮avi
普通-4：43
嫁-4：26

>>517
？

Huffyuv_yomeで良いよ、もう。

+　　　+
　 ∧＿∧ 　+
　（0゜・∀・）　　　ワクワクテカテカ
　（0゜∪ ∪ + 　　　　　　　
　と＿_）__）　+

>>515
立派な派生だし、ファイル名を変えるのが流儀だと思うけどな。

互換性のないファイルの入出力も出来るわけだから
ファイル名が同じだとまずくない？

Huffyuv_yomeがいいな

まあ真面目に考えるとhuffyuv_mtが妥当かな

あーもういいや、流儀って言われてもよくわからんし、公開停止するよ。
派生バージョンではあるが、根本のソースを嫁が作ったわけじゃないから、新しい名前に
するのは逆にまずいだろうという判断なんだ、俺らは。
ファイル名に何か付加するなりというのは異存はないが、別の名前にしろというのはねえ、
悪いが同意しかねる。
そもそも自宅で使うために作ったものを、他の人にも役に立てばと思って出したに過ぎない
わけで、混乱招くのが本意ではないのでね。

今手元にある人は好きに使ってもらって結構だし、再配布もご自由に。
再配布する際にファイル名変えてもらっても構わんです。

>>521
お前が流儀とかごちゃごちゃ言うからだろーが
氏ね

>>524
新しい名前というのは
> 例えばファイル名を「huffyuv_mt.dll」にして、コーデック選択画面で出てくる名称を
> 「Huffyuv v2.1.1 - Multi-Threading Patch v1.0」にするっていうのでどうだろう。
で異存なしって事。

>>524
とても残念です。
大事に使わせていただきます。

>>524
気が向いたらまたきてください。大事に使いますんで

>>515で異存なしです。
大事に使わせてもらいます。
気長にワクテカしてます。

>>459
あー。間に合わなかったか…。

チェック外して互換性がOUTなら別名の方がと思ってソースからコンパイルした奴使ってバイナリみてたんだけど、
問題なかったから、実際、パッチって意見でOKだったんだけど…。

512で作成者の考えを書いてるし、チェック外せば互換性を維持してるんだし
ソース付きで出してくれてるし、別名つけてゴタゴタしたくないだろうなと思って…。
俺も昔JPパッチ含んだもので面倒になったんで、その気分はわかる。
別名希望レスつけてる人も単なるネタとしてつけてただけだろうから、あんまり気分を害さないでね。

一応報告。
Q66、ntensity Pro で2時間ものDropなしでOK。
まあ録画側はHDDがネックだったんだけど、再生時に4coreつかってくれるので、そのまま再生できるものが出てきた。
嫁さんにお伝えください。ありがとうございました。

ということで誰かソース改造してうｐしてくれ

アホが作りもできねぇくせに作者にネーミング程度のことでゴチャゴチャ抜かしやがって・・・

>>524
他の作者も同じように考えるかどうかは知らないけど、私の場合はソースに
改変を加えたものを配布する場合は名前を変えてもらった方が嬉しい。
(少なくとも別のものだと判断できるようにしといてほしい)

つーのは、改変版のバグレポートを本家の方に投げられても困るからね。
パッチを本家に投げて、本家に採用してもらうっつーなら別なんだけど。

まー今は公開停止してるみたいだし、次に何かすることがあったら参考に
してください。

1080iで録画すると再生時にはやっぱりカクカクするなあ・・・

公開停止しなくてもいいじゃん・・・。

誰か>>475の再配布して。

このまま消えるのはあまりにも勿体無いと思うんでとりあえずミラーしといた
ttp://www.be55.com/huffyuv_mt.zip

>>515の案で良かったんですが、残念です。

何か説明下手なヤツのせいでごちゃごちゃになっとんな。
>>515の案でokだと思うんだけど。

うｐ主と嫁がhuffyuvの名にこだわるのは当然だし、
そこに異論を挟むヤツはこのスレにはいないだろう。
むしろ完全別名なんてhuffyuv作者に失礼。
例えばopen offeceのソースをちょいいじって、
2ch offeceなんて名乗るのは馬鹿だけだろ。

で、photoshopの例で言えば、広義ではCS3も5.5もphotoshopファイル、
厳密には「CS3のファイルだと5.5では読めない」っつー説明ができる。
スレ住人としてはこの「CS3」「5.5」にあたる、
派生バージョンと分かる名称が欲しいだけなんだよね。
ただ、あくまでも改変版なのだから「huffyuv」だけだと、
原版の作者に迷惑がかかる可能性もあるしな。

ていうかああしろこうしろ言う時点でおかしいだろ。
何が「案でok」だよ

抽出 ID:tAR3U42D (3回)

532　　 名無しさん＠編集中 [sage] 　2007年10月08日(月) 15:39:52 ID:tAR3U42D　 　

アホが作りもできねぇくせに作者にネーミング程度のことでゴチャゴチャ抜かしやがって・・・

534　　 名無しさん＠編集中 [sage] 　2007年10月08日(月) 15:44:15 ID:tAR3U42D　 　

1080iで録画すると再生時にはやっぱりカクカクするなあ・・・

540　　 名無しさん＠編集中 [sage] 　2007年10月08日(月) 20:08:59 ID:tAR3U42D　 　

ていうかああしろこうしろ言う時点でおかしいだろ。
何が「案でok」だよ

専ブラ使い始めの頃って無意味に抽出したりして喜んでたわ
>>541は新参だろ

>>541
で？っていう

抽出 D:OwRsHIoz (4回)

518 名前：名無しさん＠編集中[sage] 投稿日：2007/10/08(月) 14:11:28 ID:OwRsHIoz
>>517
？

523 名前：名無しさん＠編集中[sage] 投稿日：2007/10/08(月) 14:38:19 ID:OwRsHIoz
まあ真面目に考えるとhuffyuv_mtが妥当かな


531 名前：名無しさん＠編集中[sage] 投稿日：2007/10/08(月) 15:02:21 ID:OwRsHIoz
ということで誰かソース改造してうｐしてくれ


541 名前：名無しさん＠編集中[sage] 投稿日：2007/10/08(月) 20:17:58 ID:OwRsHIoz
抽出 ID:tAR3U42D (3回)

532　　 名無しさん＠編集中 [sage] 　2007年10月08日(月) 15:39:52 ID:tAR3U42D　 　

アホが作りもできねぇくせに作者にネーミング程度のことでゴチャゴチャ抜かしやがって・・・

534　　 名無しさん＠編集中 [sage] 　2007年10月08日(月) 15:44:15 ID:tAR3U42D　 　

1080iで録画すると再生時にはやっぱりカクカクするなあ・・・

540　　 名無しさん＠編集中 [sage] 　2007年10月08日(月) 20:08:59 ID:tAR3U42D　 　

ていうかああしろこうしろ言う時点でおかしいだろ。
何が「案でok」だよ

使い分けしたいから別物にしてほしいわ
互換性無いんだし
上書きされるのは正直困るよ

たぶん名前とか関係なしにみんなが嫁狙ってるから逃げたんだとおもう

プログラムソースあるんだし使い分けしたい人は自分で修正すればいい
うｐ主と嫁さんとりあえずありがとん

コーデック一覧に出てくる名前を変えようとしてるのだがソースのどこが反映されるのかわからん
それらしい場所を変えてコンパイルしてみても反映されなくて挫折気味
マルチしなければ互換あるんだしこのままでもいい気分になってきた・・・

まあ、公開した以上は一定の責任は取らんといかんと思うので、名称変更版を1日だけ
公開するよ。
昼には用意してあったんで、このまま削除るのももったいないし。

http://iroiro.zapto.org/cmn/jb/data/jb4815.zip

明日の22時には消すんで、落としたい人はどうぞ。
てか、一応前に公開したバージョンも、コーデック一覧で表示される名前の最後に
[M]って入ってたんだけどね、わかりにくかったよね。

いろいろお騒がせしてすまんかったよ。
これ以上の変更や改造は、誰か腕に自信のある人にお任せする。

>>549
落とさせていただきました。
本当にありがとうございます。

よくわからんが
普通のHuffyuvとマルチ版のHuffyuvて共存できるんじゃないの
別に上書きしなくてもインストールできるし

じゃinfも公開してよ

ヘッダがどちらもHFYU
MT情報の入ったhuffyuvファイルを本家が読んだらエラー吐く

MT使用時のみ、"HFY2"とでも変えてくれないかな

ffdshowの設定でHuffyuvを無効にしたら本家もマルチも読めたよ

すげえ伸びてると思ったら名前のことでもめてたのかｗ
普通に考えて名前変えないとまずいだろ　この夫婦の理屈はちょっと理解できんｗ

吐き出されるバイナリに互換性が無いんだから、
名前かえるだけで問題なくなるのにね

私家版なんだから名前なんて改造者の好きにすれば良いだけなんじゃないの？
俺にとってはありがたく使わせていただいていますので、名前なんてどうでも良いです。
459さん＆嫁さん ありがとうございました。
だいたい、huffyuv自体が他人のPCとの互換性をあまり必要としないコーデックなんだから。
同じ名前でも混乱も起きにくいでしょうが。
原理原則持ち出すにもほどがあると思うがね。

乞食がパンもらって不味いと言ってるようなもんだぜ

huffyuv_ccesp-patch_0.2.5.zipの中のinfを書き換えれば
なんか共存できるような気がする

huffyuvでキャプったaviを、VDMのlanczos3でリサイズして、huffyuv_mtを使って中間ファイル作ると、
画面が上下半分に切られて、切られた上と下が入れ替わっちゃた。
中間ファイルをhuffyuvでやれば問題ないんだけどなんでだろう？

じゃついでに日本語化してくれ

>>561
出来た中間ファイルを
huffyuvでデコードしてるからだろ

上書きがめんどくさくなくていいよ
大体、中間ファイルなのに互換性とか考える必要も無いと思うんだけど
そもそも全く互換性が無い訳じゃないんだし

ｍｔﾖｲﾖー

>>549のやつはHuffyuv_mt.dllをHuffyuv.dllにリネームして上書きすればいいの？

俺の場合はhuffyuv_ccesp-patch_0.2.5.dllだな

つーかGPLで公開されてる以上作者は改変配布大歓迎な訳で


改変者がアレだっただけにこういうことになっちまったがｗ

ＭＴ→本家は読めない
本家→ＭＴは読める（CPU40%前後）
ＭＴ→ＭＴは読める（CPU85%前後）

んでもってGPLのものを改変したﾌﾞﾂもこれまたGPLなわけで・・・
まあ改変しよっと

文句言いながら使うなよ乞食が

>>571お前みたいのってどんなジャンルの世界にもいるよな

>>572
お前みたいなのもな

>>570
改変するなら、MT 版 (フレーム分割版) では FourCC 変えた方が良いと思うよ。
その方が混乱は少ないだろうし。
# 一人で使い続けるなら関係ない話だけど。

>>573
はいはい＾＾

まあそいつの相手をした時点で相手と同じレベルなわけで・・・

hunuaa + huffyuvマルチ(2スレッド)、huffyuv本家より
音ずれ防止の挿入フレーム増えね？

huffyome取り逃した

>>578
GPLで再配布自由だから、うｐるよ。
ちょっとまってなー

しかし、なんで嫁の旦那は名前ごときで切れたの？
機能の違うソフトを作ったのなら名前を変えて別物であることをアピールするのは
オープンソース改変でも、それはソフト作りとしては基本でしょう？
MT物なんてみんながほしがる物なんだから、ちゃんと名前を設定して公式に配布して
さらに別の人が派生ソフトを作ってって感じで進化していく物なのに。

ほい。
459嫁版再配布
ttp://ccfa.info/cgi-bin/up/src/up9498.zip

>>580
お前みたいな乞食が多かったからじゃね？

むしろ乞食はただヘーコラしてて問題点とか何も考えてないんじゃねーの？

上書きウザイんでHuffyuv互換部分外して
別名でインストールできるようにしてくれ
ついでに日本語化してくれ

>>584
ソースあるんだから、自分でしろ。

>>580
お前が改変して名前変えて進化させりゃいいんだよ。
それもせずにあーだーこーだ言うだけの乞食ばっかりだから嫌になって当然だろな。

余計なこと言わずにこんなのがあるよ的に紹介すればよかったのに
いちいち「嫁がどうの〜」ってアピールするから怪しいと思っていた

こうやって作る人のモチベーションが下がるのであった。

嫁が作ってくれたから公開するよ
↓
オリジナル版と混乱するかもしれないから名前変えたらどうだろう
↓
そういうのよくわかんないから公開やめるよ

この流れはなんかおかしいよな。
そもそも名前変更だって「変えたくないしそのままで問題ない」と
はっきり答えて、プログラムは放置でも別に良かったと思うけど。
実際、変更してもそれは一覧の名前が変わっただけで、FourCCは変わってないから
互換性のないファイルをffdshowが読み込んでしまうとかの問題は残ったまま。
（これはffdshowのHuffyuvデコードを無効にすればいいだけだが）

誰も公開やめてほしいなんて思ってないし、
ライセンス違反とかじゃないんだから、俺は放置しても無責任とは思わない。
公開するしないは作者の自由だから仕方ないけどさ。

2ちゃんで公開するにはさく〜しゃに耐性が必要なのは間違いない。

>>589
その辺もきっちりやってくれたら本物の神として語り継がれただろうに
画竜点睛を欠いた感じだな。

>>589
俺は変えないよ、つってたのにゴチャゴチャ抜かす乞食が後たたんかったから
「めんどくせーから公開やめるわ」
となったんだろ、歪曲すんなｗ

乞食が不味そうに与えられたパンを食ってる様子が目に浮かんだ

ここをダウソ板か何かと勘違いしてる池沼連中のせいで
せっかくの神アイテムがこれっきりのアップになったのかよ
バージョンアップで使い勝手の向上もあっただろうに
ホント馬鹿ばっかりじゃのぉｗｗｗ

この手のは何言ってもこれっきりにはならないから安心しろ

2chが始まってから、もう100回単位で繰り返されているようなことだしね。

>>581
もろた
ありがと

利用者にうだうだ言われるのがいやで結局引っ込めるのならば
はじめっから公開せずｵﾅﾆｰに留めておけばよかったものを
作者が何をしたかったのかよくわかんね

>>598
いいつつ使う乞食乙。

Pアドレス 122.24.122.29
ホスト名 iroiro.zapto.org
IPアドレス割当国 日本 ( jp )
市外局番 該当なし
接続回線 光
都道府県 神奈川県

. [IPネットワークアドレス] 122.24.0.0/15
b. [ネットワーク名] OCN
f. [組織名] オープンコンピュータネットワーク
g. [Organization] Open Computer Network

ほう・・・神奈川か

>>600
すげえ
アプロダのIPから嫁の住居地が解るなんて天才じゃねｗｗｗｗｗ

何を言っているんだ君は

>>598
乞食乙。

>>589
善意を踏みにじる乞食の仕業ダロが。

まあ乞食どもはリアル世界でもはなつまみ者だから心配ｽﾝﾅ。

嫁から見ればお前ら全員乞食だけどな。

今頃終わってから来たのだが
これは嫁が切れたのか旦那が切れたのか。

まあ、みんな薄々感じているのが
旦那=嫁説もしくは459=嫁説

>607は見なかった聴かなかったことにしとこう

敢えて459=459の嫁説を唱えてみる

おれの嫁は右手
右手だけでプログラミングしてやんぞ

使って欲しいけど責任を負うのはイヤだってのは凄く分かる

名称を変更すべき箇所が分かってる奴は
そこだけ改変して自分が派生させたと言えば
それを嫁がまた改変してくれたかもしれないのに

2chでソフト公開するときはスルー力が重要
バグ報告以外の自分に都合悪いのは全部スルーするのがいい

とりあえず自分の都合のいいように修正。

http://www12.axfc.net/uploader/93/so/File_1864.zip.html

mingw(gcc+MASM)ビルド用に若干修正
fourcc変更(HYMTとした)
inf追加(オリジナルとは別物でインストール)

h削るの忘れた･･･

>>613
otu

しごく嫁の次は
無意味神か

乙！

乙

【これは>>613乙じゃなくてﾎﾟﾆｰﾃｰﾙ中】

　くくってやんよ　　
　　　　　　　　　　　　ﾏﾁﾞﾃﾞ
ｷﾞｭｯ　 　∧,,∧　∧,,∧
　∧∧ (´・ω・) (・ω・｀) ∧∧　･･･
(ω・`ｎ乙　⊃) ( つと ﾉ(ω・｀ )
｜　　ノ(・`*乙) (・｀　乙)　と ﾉ
　ｕ-ｕ 　（l 　　 )⊂　　　ﾉu-ｕ
　　　　 　`ｕ-ｕ'.　`ｕ-u'

ありがとうございました

最高1/3！ ロスレス圧縮コーデックオプション「Pixwork VCM 2.0」

推奨マシンスペック
Pentium Xeon Dual×2 3GHz相当以上／メモリ4GB以上
http://www.atpress.ne.jp/view/7095

Xeonて高くて買えねーだろぼけｗ

俺の友達Xeonで4000x4000くらいの動画編集してるよ

ポスプロなら普通のスペックだけど・・・

>>613のはデコードがおかしい。
スレッドで分割した時と逆の順序で表示される。

>>459入れたらこれもダメだったので元からのバグだね。

ttp://www12.axfc.net/uploader/93/so/File_1972.zip.html
修正版

( ・ω・)つ乙

何がおかしかったのかわからんが乙

>>626
*-+。・+。-*｡+｡*
＼　 　 　 　。*ﾟ
　∩　　　 *
　(´･ω･`)
　 。ヽ、　 つ
　*　　ヽ、 ⊃
+ﾟ　　　 ∪~　　　☆
ﾟ+｡*。・+。-*｡+。*ﾟ

>>625の逆順ってのを直したのか。
threads2.cpp:
@@ -436,7 +436,7 @@
DecompressUnit decunit[MAX_PROCESSOR_NUM];
DWORD height_offs = 0;
bool rgb = (GetBitmapType(icinfo->lpbiOutput)>1) ? true : false;
- for(i=0,m=0; i<cut_num; i++){
+ for(i=cut_num-1,m=0; i>=0; i--){
decunit[i].pCodec = this;
decunit[i].retval = ICERR_OK;
decunit[i].icinfo = icinfo;

ところで，手元のMASM8ではアセンブルに失敗するんだけど，>>613ではMASMでアセンブルしたと言っているんだよね。
movdとmovqのメモリオペランドにdword ptrとかqword ptrとかがないのでエラーになっているっぽい。
そこだけ直せばMSから配布されてるVC++2005 ExpressとMASMでbuildできた。

>>626
うちでは>>626のデコードがおかしくて>>613が正常なんだが…

>>632
うちでも>>613の方が正常。>>626にするとデコードしたら上下が真ん中から入れ替わる。

>>633に同じく。>>626のは上下が真ん中から入れ替わる。

わけわからん

>>625の環境が特殊っぽいね
今までそんな重大なバグ報告なかったし

RGB->YUVにバグがある気がする。
Aviutl0.98dで試すと
「YUV2で圧縮する」にチェックを入れると>>613で正常。
入れないと>>626で入れ替わる。

書き忘れたがCODEC側の設定は「best」で「Convert to YUV2」な。

キャプった動画は>>613ので正常だった･･･。
テストはavisynthのサンプルをVDMでエンコしてた。

>>631
masm32使ってる

お、俺も>>625と同じ
>>475も>>613も上下逆、中央に太い黒の線が入って使えないと判断してた

ソースはRGB32でVirtualDubで圧縮してた

うちも>>626つかったら上下逆分割動画出てきてびびったわ
>>613に戻した

どっちが正しいんだ・・・

オリジナルキャプ→459,613,626下半分乱れ再生

613キャプ→613正常再生
613キャプ→626分割再生

626キャプ→626分割再生
626キャプ→613正常再生

オリジナルは普通に再生できるぜ？

459キャプ→613,626下半分乱れ再生 だな
そろそろファイル整理せんとわけわからん…

あー違う！
459キャプ→オリジナルDLL だorz

>>459のつかってhuffyuv-MTを使って吐き出す場合
・VirtualDubModだと　→上下逆
・AVIUtilだと　　　　　　→正常
・ふぬああでキャプ　　→正常

なにかVirtualDubModとhuffyuv-MTの相性が悪いように思えてきた

613が正解？

RGB<->YUY2変換時、上下反転するフィルタが間に挟まってるか否かの違いだと思う

いや上から下か下から上かの違いをMT版が判別せずに無条件で決めうちしてるのかな？

>>626はVirtualDubとその派生を使う人用だね
俺は>>626で正常になった

ttp://www12.axfc.net/uploader/93/so/File_2008.zip.html

VirtualDub で上下逆になるバグ修正してみた。
Compressの方がバグってたみたい。
うちの環境だと一応直ったように見える。
デバッグしたのが549 のソースなんで、そっちでうp。
613 はソース覗いてないけど、たぶんthreads2.cpp の差分でいけると思われ。

作者が増えてどれがどれの修正かややこしくなってきた

おれ的メモ：
>>475 [forceCC:HFYU]初期版,YUY2用
>>549 [forceCC:HFYU]コーデック選択画面での名称変更,YUY2用
>>613 [forceCC:HYMT]forceCC変更,YUY2用
>>626 [forceCC:HYMT]613の修正版,RGB用
>>652 [forceCC:HFYU]549の修正版,RGB用

※もともとのhaffyuvのforceCCは"HFYU"

>>654
いろいろとスペル間違えてるぞ

>>655 サンきゅ
forceCC > fourCC
haffyuv > huffyuv

>>652
いいね。>>613に取り込んでコンパイルしたよ。
これで613と626は不要になるはず。

http://www12.axfc.net/uploader/93/so/File_2011.zip.html

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　>>626─デコード部修正
　 　 　 　 　 　 　 　 　 　　　　　　　　　　　　　　　　　　　　　　 │　　VirtualDubで正常、それ以外で異常
　　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 　 ┌─>>613─┴───┬─>>657
Huffyuv v2.1.1──>>475─────>>549─┤　　　│　　　　　　 　 │　　　│
　 　 　│　 　 　　　　　│　　 　 　　　　　│　　 │FourCC変更:HYMT .│　　今ココ
　オリジナル　　マルチスレッド化　名称変更　└───>>652───┘
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Compress修正
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　VirtualDub正常

発展した派生品が色々と出てきて頼もしい限り。ついでに
この辺を参考に、64ビット対応版追加や（起きるなら）アン
インストールできない不具合の修正もやってもらえるとさらに
便利になりそうだから、可能な方はぜひお願いします m(_ _)m

[Microsoft Windows XP Profssional x64 Edition FAQ]
ttp://teamcroud.fc2web.com/winxp64.html
>XP x64でHuffyuv v2.1.1を正常にインストールするためのhuffyuv.infの修正方法

[貰い物(預かり物)のページ]
ttp://breuzehn.hp.infoseek.co.jp/soft.html
>huffyuv2.1.1codec
>何故かアンインストール出来ない不具合を不必要だと思いつつも修正したもの


必要性は低いだろうけど、日本語化も需要が高いかも。

一気に活性化したな。スレが

そういえばHuffyuv v2.2.0ってあるけどどうなんだろ？
こっちのマルチ版とか出たらさらにややこしくなるなｗ

Huffyuvとしてマルチ化するなら互換性あるから問題ないだろ

>>661
2.2.0はRGB形式でバグ持ちだとか、縦方向の半分が壊れるといった
話があり、相手にされてない。回避・修正方法も出てきておらず、
心配せずともマルチスレッド対応は2.1.1だけってことで。

2.2.0は、RGBの圧縮でモザイクになって使えないし、コンソールウィンドウも表示されない
なぜか片方向だけCロジックしかなかったのがASM(MMX)になっただけで、
YUY2専用で使うなら使ってもいいというバグ版。
（YUY2->RGB、もしかしたら逆だったかも知れん）

そろそろリポジトリ用意して
ちゃんと開発しろよｗ

ffvhuffって結構縮むな

ttp://www12.axfc.net/uploader/93/so/File_2079.zip.html

機能に変更はなし。
>>659を参考にアンインスコできるようにしたのと
VC++2005Express+MASM8.0でもコンパイルできるようにしたセット。

>667
gj

>>667
乙

>>667
乙
>>657の修正？

是非Vista64bitにも対応してくれ

>>667は>>657からの修正ね

うちには64bit環境無いので他の人におまかせ

VC++2005ExpressとMASM8.0をインスコしてビルドしてみた。

動くけどファイルサイズが>>667の半分以下になってる…？

ランタイムライブラリ使うか内蔵かっていう事では？

スタティックかダイナミックか

�d
「構成プロパティ」→「C/C++」→「コード生成」のランタイムライブラリを変更したら
大分近くなったけど>>667よりまだ小さい…
100kbいかないんだけどまだ何かあるのかな。

とりあえず適当に日本語化してるんだけど、ポップアップで出てくるやつの翻訳がめんどい。
もう今日は寝よう。

大元には日本語化パッチがあるから
それの丸パクリでいいんじゃない？ｗ

しばらく見ない内にレスが伸びてるな
シングルコアの俺涙目

>>667 乙であります
今プレスコだけど、近日中にクアッドにします
あとはx264がマルチコア対応してくれれば天国です

英語のリソースなんだけど、Ignore is-interlaced flagで出てくるツールチップに
unknown huffyuv derivatesってあるけどderivatives（派生）の間違いかな？

あとマルチスレッディングのスレッド数のとこのツールチップで
Set the number of threads as selected intentionally.ってあるけど
intentionallyって悪意がこめられた故意らしいからmanuallyとかの方がいいかなと思ってみたり。

【HDMI】BMD Intensity 6枚目【キャプチャー】
http://pc11.2ch.net/test/read.cgi/avi/1191298636/
スレより転載

>>266
エリートのHDMIでつなげてます。
こんな感じです。mtのが1ピクセルだけ混じってしまいます。
http://yoda.dip.jp/PC/Intensity_Huffyuv.png
http://yoda.dip.jp/PC/Intensity_Huffyuv_mt.png
http://yoda.dip.jp/PC/Intensity_Mjpeg.png

マジか。
うちでMTVX2006HFをソフトウェアエンコで録ったやつ（Microsoft Raw uncompressed YUV 4:2:2）
をHuffyuvとhuffyuv_mtでエンコして未圧縮で出力したらハッシュ一致したけど。

こんなのも。あった。うちでも再現。
http://pc11.2ch.net/test/read.cgi/software/1190983464/426
426 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2007/10/22(月) 19:06:20 ID:jSkEBFbS0
huffyuv_MTを圧縮コーデックに設定して、拡張avi出力を使うとエラー吐くのはうちだけかしら？
普通のhuffyuvで出す分には問題ない。

デバッグしてみるかと思ったけど
681も682もうまく再現できない……。
どんなエラー吐いてんの？

AviUtl0.99
拡張Avi出力0.3.14（0.3.9でも発生）
"0x096c9643" の命令が "0xa2084c74" のメモリを参照しました。
メモリが "read" になることはできませんでした。

17フレーム目で発生。音声を無しにすると最後までいく。。
Aviutlか拡張Avi出力側の問題かもね。ちなみに拡張Avi出力plusでも発生。

>>684
すまんが出力時の解像度と、音声形式も教えてくれないだろうか。
手元じゃ再現してないんだ。

ま、まるも氏ですか

ソースを真空波動研↓
AVI2.0 720x480 24Bit 不明HYMT 29.97fps 97309f 64737.46kb/s
PCM 48.00kHz 16Bit 2ch 1536.05kb/s
[RIFF]

左右合計16ドットクリッピングして704x480/48.000kHz 16ビット ステレオ
60FPS・インターリーブ1・AVI1.0

あとそれを640x480にリサイズしたのと640x360と
音声をPCM 44.100kHz 16ビット ステレオにしてみたり
120FPSにしてみたりAVI2.0にしてみたりしたがダメ。


今発見。ソースがMicrosoft Raw uncompressed YUV 4:2:2なら発生しない。

ついでに

mmcでINとOUTを指定したものを出力したファイルに
シーケンスヘッダがないのは

1) 故意
2) 付けるのを忘れた

どちらでしょうか?

>>679
x264はだいぶ前からマルチスレッド対応しているぞ。

>>686
手元では再現できずにいるので、もう少し助けてほしい。

こちらで試したこと
・aviutl 0.99 を新しいフォルダに展開
・aviutl の新規コピー先に plugins フォルダを作成して、exavi.auo (ver. 0.3.14) をコピー
・真空波動研で
　　720x480 24Bit 不明HYMT 29.97fps 2697f 66872.83kb/s
　　PCM 48.00kHz 16Bit 2ch 1536.00kb/s
　　[RIFF(AVI2.0)] 00:01:29.989 (89.989sec) / 769,665,024Bytes

　　真空波動研 070808 / DLL 070808
　と表示されるもの (686 となるべく条件を同じにした) を aviutl で読み込み
・クリッピング&リサイズで 左 8 画素、右 8 画素削除、リサイズは「なし」に設定
・それ以外のフィルタは全て設定せず
・拡張 AVI 出力から huffyuv_mt (>>667 の) を
　　ttp://www.marumo.ne.jp/junk/img/huffyuv_mt_cfgdlg.png
　と設定し、それ以外の設定は
　　ttp://www.marumo.ne.jp/junk/img/exavi_cfgdlg.png
　として、出力開始

で特に例外が発生することなく終了してしまった。
(XP SP2 [AMD64 3700+] と Vista [C2D E6400] で確認)

とりあえず、上と同じ手順でも 686 の問題が発生するかどうか試してみて

・同じ問題が発生する場合
　ソースファイルの作成方法について、詳しく教えてほしい
　# 使ったキャプチャアプリ
　# huffyuv_mt の設定
　あるいは、問題が再現する小さなファイルがある場合は
　　ftp://www.marumo.ne.jp/incoming
　にファイルを放り込んでおいてほしい

・問題が発生しない場合
　問題が発生する常用環境の設定に少しずつ近づけていって、
　どの設定を有効にした場合に問題が再現するようになったか
　教えてほしい

面倒だろうけど、お願い。

Huffyuv-mtで1ピクセル混じる件ですが、
私の、動画から静止画の切り出し環境に問題があるかもしれません。
ZoomPlayerで再生してフレームキャプチャしているだけですが、
YUV > RGB変換に問題があるのかも。
(Lagarithで試しても1ピクセル混じりました)

動画から静止画を切り出すお勧めの方法はありませんか?

Aviutlでフレームをクリップボードにコピーしてみては？

>>690
ごめんなさい。huffyuv_mt関係なかった。
てか再現できてませんでした。早とちりorz

結論
問題のあるファイルを拡張avi出力通すとコーデック関係なく落ちる。
問題＝音声がPCM 48.001kHz
MTVX2006HFのソフトウェアエンコで録ってるんだけどサンプリング周波数がズレてるらしい。
オンボサウンドのせいだろうか…？

ファイル要ります？

>>693
あー exavi.auo の中で自前で処理してる周波数変換処理の問題ですね。
ヘッダ書き換えで 48001 Hz オーディオの AVI を作って手元環境でも
再現しました。

現在修正作業中ですが、ちと問題が根深いので週末まで待ってください。

>>692
ありがとう。
でもAviutlでコピーしてみたら、Mjpeg並にボケボケになってしまいました。

スレ違いだけど許してほしい
>>693
報告してもらったバグを修正した ver. 0.3.15 を公開しました
# ttp://www.marumo.ne.jp/auf/exavi-0.3.15.lzh

>>688 あれっ？そうなのか、片スレだけ100%に張り付いていて
トータル50%だったんで、未対応かと思ってた。
うちに帰ったら追試してみる。
x264を2プロセス立ち上げると綺麗に両スレ100%になるけど。

>>696
乙です。動きました。

ところで>>667のHuffyuv_mt.infをインストールするとオリジナルのHuffyuv.dllが置き換わることがある。
うちだけ？

BMDスレでVisita64対応の派生品を発見。対応環境を持っている方はレポよろ。

ttp://pc11.2ch.net/test/read.cgi/avi/1191298636/323

323 名無しさん＠編集中 sage New! 2007/10/26(金) 22:04:02 ID:u1GXKxRn
ttp://www12.axfc.net/uploader/93/so/File_2152.zip.html

前huffyuvがVista64に入らないっていってた人いたから
可逆圧縮スレのリンク参考にインストーラ直してみた。
中のhuffyuvはmt版。
（略）

>693
ttp://hgsym.dip.jp/~hgsym/blog/item/140?memberid=1
こんなんあるよ。

ふぬああでキャプチャしてるならキャプチャ値や実測値と異なる値に
ファイルヘッダだけ書き換えることはできるだろ
muxの設定画面みてみろ

ttp://www12.axfc.net/uploader/93/so/File_2171.zip.html

日本語リソース追加・英語リソース微修正・>>699のinfを取り込み
64bit環境ないので検証キボン
[DestinationDirs.NTamd64]とかできるのかな？

ttp://www12.axfc.net/uploader/93/so/File_2173.zip.html

すみません、こっちで。

うわ、まるもの中の人ですか！
MV-300リンクの中に俺のサイトが残ってらー(現在はページ消滅)

いつの間にか大量のディストリが出てるけど、
結局マルチスレッドのhuffyuvを使おうと思ったら
どの配布物を使ったらいいんだ？

>>703って>>667を日本語化して64bit環境でも
インストールできるようにしたものなんだよね？

64bitでインストールできた報告がまだないね…

703のでもVista64bitにインストールできないみたい
俺の環境では

x64Vistaじゃ>>703使えなかった
ちなみに>>699はいけてる

>>708-709
ttp://www12.axfc.net/uploader/93/so/File_2219.txt.html
これでどう？
拡張子infに変えてね。

>710
おし、いけたよ
圧縮も再生もＯＫ

>>667と>>703と>>710をまとめたもの
ttp://www12.axfc.net/uploader/93/so/File_2222.zip.html

おお、いけたか。

[DestinationDirs.NTamd64]ってダメなのかぁ。
[DestinationDirs.ntx86]はググったらでてきたからいけるかと思ったが。

Lagarith 1.3.15dev
http://www.mediafire.com/?fmshzttggiz
※Pen4以上でないと動きません

#ソース
ColorBars(640,480,"YUY2")
trim(0,2000)

公式     →4.500秒
自ビルド →1.751秒

わお！

すげえけどバグとか無いよな？

>>714
Athlon 64 X2じゃ動かないってこと？

このスレいいな。もったいないからコーデックの保管場所作ってほしいよ。

>>716
ソースは弄って無いから、ソース自体にバグ無ければ大丈夫

↓のなら「Pen4以上」以外でも動くはず
http://www.mediafire.com/?adnvmx2ovd1
↑でもPen4用と同じくらい速度は出るみたい

よろしければどうそ

う、今会社でアクセス規制されてDLできない
帰宅するまで残っていることを願う

権利的に問題ないのならgeoあたり適当に借りてずっと保管してくれるとうれしい

なんかインストールに失敗する

環境書こうぜ。
俺のXPでは入った。

それ以前にどれを入れようとしたのか

ブランチも糞もない現状混乱しまくりだがや

(･∀･)ｲｲﾖｲｲﾖｰ

投げそこないのボールｗ

>>658で一時期かなりまとまったんだけど、また混乱かｗ

HuffyuvMT入れてから一部の画面が破綻したりするようになってしまったのは俺だけ？

報告するなら実物ageましょう。君だけです。

破綻したっていう元ファイル＋可逆圧縮かかった一枚絵が必要だな。

不安定だから結局本家に戻る

ffdshowのHuffyuvを無効にするのを忘れずに

流れを止めてすまない、質問なんだ
TMPGenc Plus2.5 で中間ファイル、その後mencoderにてflv作成
今までは中間にhuffyuvを使ってたんだがこれをhuffyuvsにしたい
しかしそうすると今度はmencoderが食べてくれない

mencoderの中の(フォルダmplayer)codecs.confにコーデック記述を追加すれば
その他の可逆形式も対応するはずなんだがそのやり方がわからない
デフォでLagarithの記述がすでにされてあるがそれさえも食べてくれない
実行するフォルダにcodecs.confをコピーしてきてもだめ
なぜか無圧縮のRGB24だと赤っぽくなるし八方塞がり

アホな頭ではググってもこの程度しか分からない。どうか教えてください

huffyuをttp://cocorico.or.tv/solveig/でカット編集してるんだけどもっと使いやすいソフトがあったら教えてください。
aviutで編集は挫折しました。

>>735
TMPGEnc 4.0 XPressは
Huffyuvの編集で使ったことないけど

Lagarith速過ぎ縮みすぎﾜﾗﾀ

tmpgenc 4.0 expressは再エンコするみたい。できれば再エンコしないで欲しいのです。

>>738
ｽﾏｿ再ｴﾝｺなしだったのか…
AviUTLしか思いつかん…
ってAviUTLの編集ってそんなに不便？
ずっとこれ使ってんだけど
VirtualDubも再ｴﾝｺなしで編集できるはず
3、4年前に使ったきりだから良く覚えてないけど

aviutlの編集まだ慣れてないのでもっといじってみようと思います。ありがとうございました。

何したいのかよくわからんがaviutlでも再エンコされないか？
huff→無圧縮aviや、huff→huffはできるがそれも一応はエンコードしてるよ。劣化はしないとしても。
カットなら右下の│← →│のボタンで指定した範囲がエンコードされる。
もっと細かいことしたいなら、同じく範囲選択して、コピー、貼り付け、カット
もできる。ファイルメニューから追加読み込みも可。
あと思い出せるのがavidemuxとかvideostudioとかavisplitとか。もう少しあった気がするが

>>714のLagarithインストールしてもVirtualDubとかで認識されないんで色々試したら
"Microsoft Visual C++ 2005 SP1 再頒布可能パッケージ (x86)"
をインストールすると大丈夫だったよ。
うちの環境だとMSVCR80.DLLがなかったのが悪かったみたい。
認識されない人は試してみるといいかも。

>>742
うちでも認識されてなかったから試したらインストールのところで落ちる…

入れたがやっぱり認識されない

DLLを手動でコピーしたりiniファイル書き換えたりしたらできたわ。

>>744
Lagarith一度消して入れなおした？
再インストで認識した

aviutl0.99aでマルチスレッド対応されて
huffMTで爆速エンコだな

>>746
それでも無理だった

>>748
効果があるかどうかはしらんがｗ

[version]
signature="$CHICAGO$"
Class = MEDIA

[DefaultInstall]
CopyFiles=LAG.Files.Inf,LAG.Files.Dll
AddReg=LAG.Reg
UpdateInis=LAG.INIs
MediaType = SOFTWARE

[DefaultUnInstall]
DelFiles=LAG.Files.Dll,LAG.Files.Inf,LAG.Files.Ini
DelReg=LAG.Reg
UpdateInis=LAG.INIs.Del
MediaType = SOFTWARE

[SourceDisksNames]
1="Lagarith lossless video codec",,1

>>749
やっぱりﾀﾞﾒﾎﾟ
おとなしくhuffyuv使うことににするよ

MT版のインストールしても、失敗してるんだけど、DLLのバージョン情報を見ると
「Copyright ｩ 2007」って文字化けしてる
公式のは「Copyright c 2007」ってなってるので、やっぱりDLLの何かがおかしいとしか思えないな

Copyright c 2007
　　　　　　↑
　公式のはコピーライトマークね。MT版はｩ

どのMT版？
>>712のやつの日本語版は「Copyright (C) 2000」になってるはずだけど。
あと©がゥになるのはShftJISのせいらしいから別に問題ないんじゃないかと思う。
てか©のままでビルドしたらゥになったけど使えたよ。

>>714のやつ。SSE2版もいっしょ。

「サウンドとオーディオデバイス」の「ハードウェア」の「ビデオCODEC」の「プロパティ」をみると
一応Lagarithが入ってるけど、Lagarithのプロパティを開こうとすると正常に使用できませんと出て、
設定をクリックすると「ドライバを読み込めません。ドライバファイルが見つからない可能性〜」となる。

Aviutlとかで開こうとしても、コーデックの欄に空欄が一行増えてるだけで使えない

Lagarithの方か。MT版も元から何もマルチスレッド対応じゃ…

うちのXPでは普通に使えるね。ｩになってるけど。
64bit使ってたり？

すまん、
Microsoft Visual C++ 2005 SP1 再頒布可能パッケージ (x86)
を入れたら解消した。

つーかこういうのが必要なら必要だといってほしいものだ。

>>673みたいになってるってことかな。

Lagarithが4コアに対応してくれたら
HDソースでもキャプチャできると思うんだけど。

>>714はSSE3、>>716はSSE2対応CPUでないと駄目
という認識でおｋ？

ほしゅ

Huffyuv MT版 の FourCC も 非MT版と同じ HFYU にして欲しい。
それとも、FourCCだけじゃなく、内部のエンコード形式も違うんだったっけ？

俺もMT版でもMTなしの場合ならHFYUのままが良いと思うので
（逆にMT使った場合は変えなきゃダメ）
設定によりFourCCを切り替えるようにしてちょん

順番が逆。最初FourCCが同じものを出されたから
「オリジナルで読めないデータフォーマット吐くんだからFourCCかえてほしい」
という声のもとに別人が変更した物だぞ。

オリジナルと共存できるんだから
MT使わないならオリジナルの方使っとけよ

inf書き換えればfourCC変更してインストールできるよ

動的にかつ自動的に切り替えてちょんって言ってんだがなあ

無理でしょ。

そうか？ffdshow VFWはその都度、圧縮形式とfourCCも選べるぞ。

なんかものすごい話がずれてる悪寒・・・

>>762
マルチスレッドのオプション外して使うなら
オリジナルと完全に同一なんだから
>>764の言うとおりオリジナルを使えって話だよ（＾＾；；；

それは不都合を運用で逃げろって言ってるわけで本来論では無いということに気づけ

不満があるならなおせばいいじゃない。

直せないなら自分がまず変わろうよ。

要望に文句つけるって不思議な行動だな

そーだね。ほんときもいね。こゆとこには近づかないほうがいいよ。

ソース公開されてるんだから欲しけりゃ自分で作れよ
ここで公開されてるのだって誰かが作ったのを改造してったものなんだから
しかも改造したのは1人じゃないし

バカばっかし

まーぶっちゃけると、それによってどんなメリットがあるのか
「バカ」にも納得させることができれば「バカ」を使うことが
できるんだけどね。
「バカ」扱いして悦に入ってても要望が受け入れられることは
ないんだが。

はあ？何言ってんのかわかんねえよ馬鹿

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　_,,.,､､,.ｨ-- ti- ､､､....,,,,_ 　 ',
　　　　　　 　 ,,..､､ri':'ﾞ/~ 　 ﾚ　　 　 '　 ﾞﾍ:l : : : :~,＞
　　 _,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、 　 !l!;: r '"
'''＜:::::::::::::;､r'　　　　　　　　　　`'' ‐-`.､ /
-、 l::::::::::::l　　　　　　 　 　 ＜"ﾞ'i;ｿ'　　 ',
~.ヽ l:::::::::::l　　　　　　　　　　　　 ~' 　 　 '､
/ .） .l::::::::::!　　　　　　　　　　　 　 　 　 　 '､
　ヽ　.l:!l:::::l ヽ　　　　　　　　　　　　　　　 　 '､
＼ '　 l! l::!l!　ヽ　　　　　　　　　 　 　 　 　 　 ,'
　 ﾞ　 　 ヾ　　　　　　　　　　　　　　　‐'" ,. r ﾞ
ｰ-‐i　　　　　　　　　　　　 　 ,.r,,iilll鬚髯ｦ 　　　そんなに何も見えてないんじゃ
.　　 l　　　　　　　　　　　　`''' ‐‐ ---t‐' 　　　　
￣￣￣￣￣￣~"''､' ‐ ､ 　 　 　 ー‐ノ 　　　　　生きてても面白くないでしょう
　　　　　　　　 　 　 ',　 ヽ　　　　 　 l
　　　　 　 　 　 　 　 ｌ　　 l　　 　 　 l
　　　　　　　 　 　 　 l　 　 l　　　　 ﾉ

吉井さんっ…

HDDのなかが動画でパンパンだぜ

うｐろだから消える前に拾って保存しておいた。
http://www29.atwiki.jp/lossless/pages/11.html

神ｷﾀ━━━(ﾟ∀ﾟ)━(｡Ａ｡)━(ﾟ∀ﾟ)━(｡Ａ｡)━(ﾟ∀ﾟ)━━━!!!!

>>783
乙。

ブランチのとこ編集してきた。

１年ぶりくらいに来てみたらめちゃめちゃ伸びてて驚いた
>>783乙

久々に最新verに入れ替えるかな

＞１年ぶりくらいに
慌てるな。とりあえず読むんだ。
それから考えてもいいだろう。

>>714はarch:SSE2、>>716はオプション無しって事だよね？

× >>716
○ >>719

>>789

>>714はIntel C++ コンパイラで/QaxN /QxN
>>719はVC8 SP1で多分arch:SSE (忘れた)

HuffyuvとLagarithで圧縮してみた動画が両方とも画が劣化してるんだけどこれってまずいですかね。

なんか変な動画系ソフト入れてスプリッターとデコーダーのメリット値が変になってる
と再生したとき変になって見えることある。

>>714入れた環境でで最近のffdshow入れたら競合か相性かLagarithのデコードがぐちゃぐちゃになった
>>719入れるかLagarithのバージョン下げたら直った

デコードがぐちゃぐちゃってどんな症状か詳しく

kwsk

>>794
俺もなった。例えて言うならHDBenchの2Dグラフィック性能を計るテストで、
カラーの四角形がガーッて画面いっぱいに溢れかえる、あれみたいだったｗ
俺の場合、バージョン下げてもおかしくなったキャプチャ動画は再生できんし、
エンコードの方がおかしくなってたのかも？
今はまだ怖いので、安定するまでは大事な動画のキャプには使わないでおこう・・・

>カラーの四角形がガーッて画面いっぱいに
そうそれそれ

あぁそれ俺もなったｗ
オリジナルのLagarithで圧縮したやつを
オリジナルのLagarith消してSSE3版Lagarith入れて再生してみたら…

単にLagarithのバージョン互換性がないからバグってるだけじゃないの？
俺も1.3.15devにしたら1.3.14で圧縮したファイルが読めなくなったし。

うちでは1.3.14で圧縮した奴1.3.15でデコードできてる
にもかかわらず1.3.15でエンコした奴をSSE3版1.3.15でデコードしたら四角形に

すまん、間違ってた。YUY2のソースで検証してみたが、こんな結果になった。

　　　　　　　　　　　1.3.14　　>>714　>>719
1.3.14（公式）　　　　○　　　　×　　　 ○
1.3.15dev（714）　　 ×　　　　○　　　 ×
1.3.15dev（719）　　 ○　　　　×　　　 ○

1.3.14（公式）と1.3.15dev（719）は同じファイルを出力し、
デコードも同じようにできたので、1.3.15dev（714）だけ互換性がない。
ソースはいじってないそうなので、エンコード・デコード処理が
SSE3最適化したときとそうでないときで異なっていると思われる。

ちなみに、ファイルとDLLのバージョンを揃えて
Huffyuvで再エンコしてみたが、同一のファイルができた。
互換性がないだけで、処理自体は問題ない模様。

>>798
おれも、大量の赤い四角が一瞬入り込む現象にあった。
編集ソフトでそのフレーム削って、前後のフレームをコピーして対処したけど。

1.3.15devの四角形バグキャプ
http://www.dotup.org/uploda/www.dotup.org3009.jpg

Lagarithは色ノイズが出ると上の方にも書かれていたが
これはひどいな

Lagarithの1.3.14ずっと使ってるんですがなぜか最近不具合が出るようになりました
最新版は2.2.3ですがそれよりお勧めな安定したバージョンってありますか？

>>783に置いてあるLagarithがインストールできNeeeeeee! と思っていたら、
>>262に書いてある「Microsoft Visual C++ 2005 再頒布可能パッケージ」ではだめで、
「Microsoft Visual C++ 2005 SP1 再頒布可能パッケージ」ならOKだった。

よくよく見たら>>756に書いてあった。
つまんないことでさんざん悩んでしまった(´･ω･`)
ﾁﾗ裏ｽﾏｿ

Lagarithはうちでもノイズが発生することがあるんだよね。
それも常時じゃなくて、突然脈絡もなく1フレームだけノイズが混じったりするのでたちが悪い。
エンコした物を再度目をこらして全て確認しなくてはならないので非常に困る。
もっと安定しないと使えないな。

互換性無くなるのだけは勘弁

1.3.15系はHuffyufの2.2.0(バグ有り)と同じ道辿りそうだな

ちょっと質問なのですが、YUY2減色バグ解決方法でhuffyuvいれて、
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32以下の
VIDC.UYVY, 　　VIDC.YUY2, 　　VIDC.YVYUの値を、
msyuv.dllからhuffyuv.dllに変える。
というのがあったと思うのですが、これはWindowsXPとかVISTAでもやるべきことですか？
又、マルチスレッドバージョンを入れたときはmsyuv.dllをどういう名前に変更すればよいのでしょうか？

DX9以前の話をぶり返して楽しいか？

>>808
なんてこった…今まで飛ばし見で大丈夫そうだったから使ってたけど
もしかしたら見逃してただけかもしれないのか…

やはりエンコしたら１度きちんと見ないと駄目だな

エンコ後に見直す気が起きなかった程度の動画なら、
そのままエンコしても問題ないだろ

所詮1こまだし、再生して問題になることはない

>>804
それって再現性はあるの？

YUY2出力かYV12出力するかでLagarithのダイアログでフォーマットを合わせておいてもバグるのかな？

とりあえず1.3.14に戻して様子見

>>809
714版を使って出るノイズはこちらのビルドのせい。
Lagarith作者は悪くない。

719版をおすすめします。714はロダから消しますね。

あと、SP1のCRT必要といってなかった。すまない。

>>817
やっぱり。

まぁ、ここで俺含む人柱が常に検証して、使えるものかどうか判断してるから、
多少は気にしてもらいながら、どんどん高速なモノつくってくれ

ちなみに普通のLagarithでも1フレームだけノイズかかるときあるんだよな
Laga自体のバグなのかも

>>817
俺が使っていたのも普通の奴だけどノイズ乗ったよ。
804みたいな物じゃなくて砂嵐がかぶる様な感じのノイズだけど。

Lagarithコンパイルしようと思ってttp://lags.leetcode.net/codec.htmlからソース落としたけどエラーがあってコンパイルできない
適当に直したらdebugでコンパイルした場合しか動かない>>719はどうしてるんだろう？

自己解決しました

自己解決しました

意味
俺は自己解決できたから同じところで困っているヤツは自分で何とかしろカス

｢自己解決しました｣

あらゆる掲示板の書き込みの中で一番役にたたない書き込みだよなｗ

以下に解決方法がｶｷｺされてない場合はな。

｢自己解決しました｣　のあとに解決方法が書き込まれていたのをみたことないが

そうなのか？
少なくとも俺は簡単にだが書くようにしているし
その件に関して質問があれば答えるようにはしている。

ごくたまにあるな。

>>824の言ってることはほぼあってるんだから良いだろ細かいことはｗ
実際>>821がこのあと詳細報告する確率なんてまず無いし。

ちょっとまて、>>822は騙りの可能性もあるぞ。質問の直後に
無関係の奴が「自己解決しました」と書いて妨害してるのを見たことある。
本人だとしたら俺にも教えてくださいお願いします。

そういえば質問スレで質問主を装って
「すみません急いでるんで早くしてください」とか書くのがあったな

>>829
なんで雑談にそんなに必死なんだ?
自分の主張を他人に押し付けないと気がすまないタイプ?

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　_,,.,､､,.ｨ-- ti- ､､､....,,,,_ 　 ',
　　　　　　 　 ,,..､､ri':'ﾞ/~ 　 ﾚ　　 　 '　 ﾞﾍ:l : : : :~,＞
　　 _,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、 　 !l!;: r '"
'''＜:::::::::::::;､r'　　　　　　　　　　`'' ‐-`.､ /
-、 l::::::::::::l　　　　　　 　 　 ＜"ﾞ'i;ｿ'　　 ',
~.ヽ l:::::::::::l　　　　　　　　　　　　 ~' 　 　 '､
/ .） .l::::::::::!　　　　　　　　　　　 　 　 　 　 '､
　ヽ　.l:!l:::::l ヽ　　　　　　　　　　　　　　　 　 '､
＼ '　 l! l::!l!　ヽ　　　　　　　　　 　 　 　 　 　 ,'
　 ﾞ　 　 ヾ　　　　　　　　　　　　　　　‐'" ,. r ﾞ
ｰ-‐i　　　　　　　　　　　　 　 ,.r,,iilll鬚髯ｦ 　　　そんなに何も見えてないんじゃ
.　　 l　　　　　　　　　　　　`''' ‐‐ ---t‐' 　　　　
￣￣￣￣￣￣~"''､' ‐ ､ 　 　 　 ー‐ノ 　　　　　生きてても面白くないでしょう
　　　　　　　　 　 　 ',　 ヽ　　　　 　 l
　　　　 　 　 　 　 　 ｌ　　 l　　 　 　 l
　　　　　　　 　 　 　 l　 　 l　　　　 ﾉ

見えすぎていると、生き辛いものだよ
すこしくらいKYな方がいい

なんだか荒れてるようだから説明
'y' : 定義されていない識別子です。
と同じようなのが5個ほど出てきてコンパイル出来なかったのを、最初は適当に宣言したので、だめだった模様(警告が大量に出ていた)
次はエラーが出てない部分を見て真似して、修正したら該当部の警告はでなくなった
コンパイルも成功して、それでエンコードも出来たのでたぶん解決したと思う。
自分が勝手に修正したソース
ttp://www15.axfc.net/uploader/93/so/File_2808.rar.html

>>835
乙。俺も同じように修正したんだが、俺のほうはまだ警告が残ってる。

C:\Program Files\Microsoft Platform SDK\Include\mmreg.h : warning C4819: ファイルは、現在のコード ページ (932) で表示できない文字を含んでいます。データの損失を防ぐために、ファイルを Unicode 形式で保存してください。
lagarith\decompression.cpp(286) : warning C4293: '<<' : シフト数が負の値であるか、大きすぎます。定義されていない動作です
lagarith\decompression.cpp(308) : warning C4293: '<<' : シフト数が負の値であるか、大きすぎます。定義されていない動作です
lagarith\prediction.cpp(433) : warning C4731: 'ASM_BlockRestore' : インライン アセンブラ コードにより変更されたフレーム ポインタ レジスタ 'ebp' です。
lagarith\prediction.cpp(477) : warning C4731: 'ASM_BlockRestore' : インライン アセンブラ コードにより変更されたフレーム ポインタ レジスタ 'ebp' です。

ここら辺の直し方がよくわからないし、ビルドしたDLLでエンコすると
>>714のビルドみたいに互換性がなくなってお手上げ状態だったんで、
これの直し方がわかればと思ったんだがそっちは問題ない？

つまり
お前等がコンパイルしたビルドなんて
信用できないってことだ
な

全部ワーニングじゃんか
気持ち悪いかもしれんが動作には問題ない部分だと思うよ
互換性は別の問題でコンパイルオプションを見直したほうがいい
作者によってはワーニングを撲滅する人もいるけどそのまま放って置く人もいる
どんな原因でどういう影響があるのかが分かってれば

俺なんか大量のコンパイルエラーが出ると燃えるけどな
ま、度を越えると死にたくなる

ソース見てないけど、シフト演算子のワーニングはちょっと確認要かもしれん。
暗黙の優先順位がちがってて演算の区切りがおかしいのかも。
式を()でくくるように修正したほうがいいかも。

>>836
mmreg.hのはもともとのバグでこれに限ったことじゃないよ。最初これかと思って直したけど違ってた
たしかmmreg.h内に文字化けしたのが一ヶ所あるから出てるみたい。場所はぐぐらないとちょっと忘れたけど
あくまでもコンパイルできるように直しただけなので警告は消してない。一応動いたからいいかなと思って

ごめん820じゃなくて>>821だった

lagarith\decompression.cpp(286) : warning C4293: '<<' : シフト数が負の値であるか、大きすぎます。定義されていない動作です
lagarith\decompression.cpp(308) : warning C4293: '<<' : シフト数が負の値であるか、大きすぎます。定義されていない動作です

これは直さなきゃ駄目だろ
本家がどう思ってるか知らんが

color|=color<<32;
あんまりプログラム詳しくないんだけどこれは意味あるのか？

ソース見てみた。
問題なかった。作者すまん。
この警告は無視してOK。

>>831
昔質問書いて「よろしくお願いします」って書き忘れてたんで
数分後それだけ書き込んだら
「そんな早く答えもらえるわけないだろ！」って怒られたの思い出したｗ

コンパイルオプション変えてやってみたけど互換性はなくなったまま…。
改造を考えてるわけじゃないので、あきらめることにするよ。
色々教えてくれてありがとう。

【Winny,Share】@nifty専用クラスタ【絶賛規制中】
http://tmp6.2ch.net/test/read.cgi/download/1196442850/l50

悪いこと言わない
1.3..14で我慢しとけ

う、うん…

とりあえずlagarithカスタムビルドは719がstableでFA？

質問があります。
こちらＣＰＵQX9650のXPproのMEM3GHzです。HDでの編集を趣味としとります。
>>719をインストールして、最終エンコード前、ノンリニアソフトからの吐き出しに
使わせてもらっています。>>719が安定版と上で書かれていますが、どうも変です。
確かに容量が200ＭbpsのＨＤ映像並の容量になるので神業に感謝していますが、再度
その中間ファイルをノンリニアソフトで使おうとすると、俗に言われてる「四角形」映像になります。
アドビのpremiere aftereffects CanopusのEDIUS pro 4.5の3ソフトで確認できます。
　もしかして、>>714のSSE3版の方にした方がよかったのでしょうか？それとも意味ないでしょうか？

　あと一つ。エンコードは>>719より>>714の方が早いのでしょうか？
　諸先輩方教えてください。

use Multithredingのせいじゃない？
おれもpremiere書き出しではノイズでたからoffにしてる
aviutlMT,tmpgencでは問題ないからpremiereのMTと相性わるいのかねぇ．．．
ちなみにHuffyuvMTでも、premiereはなかなか安定しなかった

>>ちなみにHuffyuvMTでも、premiereはなかなか安定しなかった
むむ、そうですか。
>>use Multithredingのせいじゃない？
そうなのですか、仕方ありませんね。

と思ったら、[use Multithreding]を外しても↓になってしまうんですが一体どうしたら…
http://aaabbbccc.s6.x-beat.com/upload/src/up15576.jpg
ちなみにAE内のキャプチャです。

設定でRGB output onで読み込むと
直ると思う

そうすると今度は真っ黒に↓　んーー
http://aaabbbccc.s6.x-beat.com/upload/src/up15577.jpg

う−ん再現しないねぇ．．．
wmpで再生できるか、出来るならAEの問題として設定いじってみるとか
問題を絞っていくしかないと思うよ

一般的なプレーヤ、それにエンコーダソフト類ではちゃんと認識しますね。adobe
製品だけの話ならよかったのですが、EDIUSもなのでノンリニアソフトとは相性悪いんでしょうかね。

Lagarith は市販の編集ソフト類で問題が出ることがあるのは、出たころからずっとそう。
だからうちでは未だに Huffyuv(非MT） が現役。

EDIUS なら Canopus HQ 使うのが一番安定してると思うよ。

Canopus HQは可逆じゃ無いだろ

可逆じゃないけど何の問題もないでしょ。安定しないより100倍マシ。
Premiere でも AE でも Huffyuv と併用してるが、ちゃんと使えてるよ。

最終出力が何なのか知らないけど、非可逆にこだわる理由も見当たらないし。
Adobe なら Huffyuv でいいけど思うけどね。

? 非可逆にこだわる
○ 可逆にこだわる

だったスマソ

まあ、何回も中間ファイル出力しなおさないんであれば低圧縮の非可逆でもいいんじゃね？
2回3回と中間ファイル加工して再出力するなら可逆のほうがいいが。
がしかしここは可逆圧縮スレだ、そろそろスレ違い。

>Lagarith は市販の編集ソフト類で問題が出ることがあるのは

わかりました。それならHuffyuvを使うまでですね。HDDがすぐ埋まっちゃうので、使ってましたがしかたない。
再出力は最低4回します。だから可逆がいいんです。

質問です。
なぜかわからないのですが、あるファイルを何のエフェクト無しでTMPGenc Xpress4　でHuffyuv書き出しと、
AfterEffectsで書き出しをしました。なぜか全く容量が合いません。premiere Afterefffectsでは300MBになり、
TMPGだと174MB(元素材DVCPROHD 112MB)です。Aftereffects側で自分が設定間違っているのでしょうか？

AfterEffectsについては知らないけど読み込み時、コーデックに渡される時の
色空間はTmpgといっしょなの？

うん　(framerateとかピクセルはもとより)

Lagarithだと、なぜかTMPGでもAEでもほぼ同容量(+-10MB)になりました。
Huffyuv-MTにするとどうも元素材からTMPGで2倍,AEだと3倍の幅のある容量差です。
解決するすべはありませんか？

Canopus HQってどうやったら手にはいるの？
OHPのダウンロードにはないようだけど。

もしかしてAEはYUY422ではなくRGBとして読んでしまっているのかも・・・？

>>886
原因がなんであれAEの方の出力がRGBになってると思われ。Lagarithはたぶん
エンコード時に強制的にYUY2に変換してるんだろう。huffyuvもRGB圧縮の設定を
<-- Convert to YUY2にすれば容量的には近くなるはず。当然YUY2>RGB>YUY2
変換の劣化が起きるけどな。

俺は残念ながらPremiere Elementsしか持ってないがこれの設定ではどこ探しても
色深度が設定できなくてウチもhuffyuvで出力させるとRBGになってる。
DVD出力するための編集を意図してる製品ながらRGBでしか出せないってのも変な話だな。
AEはプロ向きの製品だからYUY2も選べるような気がするが。

>>870
Canopus HQはライセンス製品だからこのコーデックのついてる製品買え。
AVCHDからの変換ならフリーでツールを配布してるみたいだけどな。

>>872
�d。
製品版でしたか。
でもEDIUSとかなんて買えないよ…。(´・ω・｀)
MonsterXでのエンコードなのでM-JPEGより
画質が良かったらかえようかと思っていたけど。

>872
ああそうかあ、ありがとう、解決できて安心、(とは言え…)

色深度は変えられるけどRGBorYUYなんて設定は・・・・対応しないかなあ…

AEのプロ版なら確かあったような
お望みのYUY422まであったかは記憶にないけどね

ふぬああとaviutlでlagarith大活躍
未だに問題起きたこともないし、俺のfusiana眼力じゃ違い分からんし
この程度の使い方で満足しちゃってる俺勝ち組だな

すみません。MPGencでHuffyuv　2.1.11で圧縮したら
何故か動画が逆さまになってしまいました。(´・ω・｀)
正位置で出力するにはどうやったらいいですか？

普通はそうならないと思うけど、色空間をYUY2に無理やり変換してないか？
そういうことをやると可逆にならずに劣化するよ

MPGencにつっこんで圧縮する前にソースの範囲を確認
した時点で逆さまになってます。
普通はならないんですか？

ソースがFLV4とかいったらぶっ飛ばす

ＤＶDをrip NEtで一部分だけ抜いたＶＯＢファイルです
ＤＶＤ２ＡＶＩだと正常に読み込むんですけど…
どうしてだろう？

MPGEencってナニ

ＴＭＰＧＥｎｃでしたorz
ソース、リッ○ングしたって書いたら
まじぃかなと思って、あえて書きませんでした
後出しですみません。
ＤＶＤｓｈrinkで抜いてもひっくりかえります。＞＜

　わからない五大理由
１　読まない
２　調べない
３　試さない
４　理解力が足りない
５　人を利用することしか頭にない

Huffyuvで圧縮したら上下反転した（つまり言外に圧縮しない、別ので圧縮したら反転しないの意を含む）
ってことでは無かったってことか？

>>883
わからない五大理由
１　読まない
２　調べない
３　試さない
４　理解力が足りない
５　人を利用することしか頭にない

<新>わからない七大理由
1. 読まない ・・・説明書などを読まない。読む気などさらさらない。
2. 調べない ・・・過去スレ、ググるなど最低限の内容も自分で調べようとしない。
3. 試さない ・・・めんどくさいなどの理由で実行しない。する気もない。
4. 理解力が足りない ・・・理解力以前の問題で理解しようとしない。
5. 人を利用することしか頭にない ・・・甘え根性でその場を乗り切ろうとする。
6.感謝しない・・・教えてもらって当たり前。事がすんだらさようなら。
7.逆切れする・・・自分の思うようにならないと逆切れする｡









小学生乙
ていうか消えてくれ
微妙にスレ違いだし

コレが自治厨というやつか

887が冬休みになって沸いたゆとりにしか見えない

結局、現時点で容量と速度のバランスが取れてるのはどれよ？
っていうか、おまえら何を愛用してんの？

>>889
無難にHuffyuv

Huff嫁

>>889
SDならLagarith
HDならHuffyuv

>>890-892
そうだんだ！
何も考えずにHuffyuv使ってたけど正しかったみたい。
おまえら参考になったよ。ありがとう。

720×480はSDだよな？
Lagarithに乗り換えるか…

HDでHuffyuvってのは速度を考慮してでしょ？
速度をそれほど気にしない状況ではLagarithのがよいんでは

C2DならHDでLagarith余裕じゃね

お、バッファなおったかもしれん

Huffyuv-mtの712のやつでキャプっていたら2時間くらいのところで落ちた。
drwtsn32.exeの強制終了。

既出もいいとこだけど640x546とか変態解像度Lagarithで圧縮すると
640x480を同じ設定で圧縮したときより200MB位サイズが増えた(当然動画の長さにもよるが)

可逆圧縮なんだから解像度が増えれば容量も増えると思うが・・・

まぁ640x480より640x478のほうが容量増えるけどね。

>>896
QX6700@3GHzでもHDでLagarithは
無理なんだけど、
解像度は1920x1080で
キャプチャソフトはkusunokiTVHDだよね？
ちなみにhunuaaだと正しくドロップ検出できないよ。

vobかisoをフリーソフトで可逆圧縮できますか？

ZIPでしろ

>>904
ガチレスありがとうございます。

じpにしろほかの形式にしろMPEG2はすでに圧縮されてるんだから
可逆圧縮なら大して縮まんだろうな。

c2d

7zて何故あんなに縮むんだろ

DGCAは？

toponokyって実際どうなの？
fastcodec譲りの高速エンコードはhuffyuvのmt超えてるってうわさだけど

RGB32のみってあんま使い道ないな。

ほしゅ

あううう。MPG2JPG用いてhuffyuvで可逆圧縮動画作ってもファイルはそれなりに出来ても再生が・・・
カラフルな砂嵐が出てプレーヤが落ちて終わり。何が原因なのかさっぱりわからんですが以下の状況で何か
問題のある箇所があったりするでしょうか？

OS windowsXP SP2 pro
CPU opteron175 dualcoreoptimizer+AMDドライバ導入
マザー　GA-K8NSULtra939(n-force3)
HDD hitachi 500GB IDE raid構成無し
WMP11導入住み、huffyuv220、aviutl99bで出来たファイルを参照しても下半分カラフル砂嵐状態。
素人丸出しの状況説明ですがこれで何かわかる超能力をお持ちの方ご教示頂けないでしょうか。

MPG2JPGとか(作者には申し訳ないが)なんでそんなんでAVIつくんの？
utlから直で読ませることに何か不都合でも？

出来上がったvobをaviutlで扱おうとすると23分の動画なのですがバッチ登録画面で見ても
9分強の時間と認識しており実際にエンコードを終えても再生には問題なくともきっちり9分間で
切れる動画に。フレームは23分全フレーム拾ってるのですがエンコード処理においては9分と
vobを再生（powerDVD WMP11 GOMにおいて)する分にはきっちり再生時間認識して問題ありません。
aviutlで無理なら別のもので劣化無しで中間吐けばうまくいくかなと思ってやってみたのですが
解決すべき問題はむしろvobをaviutlでうまく認識できるようにすることからですね。失礼しました。

MPEG系読ませるなら普通DGMPGDec使ってd2vでVFAPIるだろＪＫ

おほっ、物凄いインスピレーション受けました。さっそく試してきます。
見ての通りDTVのド素人ですが親切にどうもありがとうデス┏○ﾍﾟｺｯ

>>916
aviutlでただしく再生時間吐かせることが出来ましたありがとうございますありがとうございますありがとうございます

utlだとd2v経由だとRGB変換はいるので個人的にはMPEG2 VIDEO File readerから
直でVOB読ませるほうを勧めておく。ただしこの場合VOBを連結して読み込ますと
結合部で2フレームほど欠落するのでDVD-ripとかの場合は1ファイル出力
などしないといけないけどな。

d2vじゃなくてm2vから読ませりゃいいじゃん

hoshu

どうせならageればいいのに。

Huffyuv MT版を色深度32bit対応に改造してくれんーかなあ
用途は画面上のキャプなんだがHuffyuvは24bitにしか対応してないから
デスクトップを16ビットにいちいち切替えないとキャプできないので悩んでる

神来ませんなぁ

Huffyuvってホントに可逆？
RGBソースだと劣化してるけど。

設定の文章も読めない文盲ですか？

さて、設定をどうしたらいいのやら
少なくとも、convert to YUY2にはしてないわけだが。
ソースは黒を背景に斜めに白と赤
Ｗの文字が白でへこんでるところが赤で塗られてるモノなのだが。
拡大したら、明らかに劣化してた。

>>927
RGB使うな

あるいは2.2.0使うな

>>928
2.2.0←そこか！
他のバージョンで確認してみる

ダメだったー
RGBは使うなってことか

tta+cueからAACに変換してくれるツールありませんか？

WAVEに変換してからやるしかないんでしょうか？

板違いだな

PremierでMAD編集してるんだけど、デコードが重いとタイミング取りづらくてきつい。
どのコーデックがデコ早いですかね？
Huffyuvあたりだとサイズが大きいからHDDがネックになってやっぱり遅くて。
動画サイズでかい場合はあきらめるしかない？

どんなHDDなんだ？

CPUが糞じゃねーの

今の可逆圧縮って元データの何％まで圧縮できるの？

>>936
元データ次第

テレビ番組とかビデオカメラやデジカメで撮った動画がほとんどだけど半分位になる？

MPEG2とかはもう圧縮されてるデータ
可逆にするとデータ量は増えてしまうぜ？

可逆はbmpをpngに変換みたいなもんだと俺は勝手に認識してる

>>939
微妙に違う
BMPをZIPに変換：エンコード(圧縮)してるようなもの
画像見るときだけZIPをBMPデコード(解凍)してる

と思ってる

jpgをbmpで保存し直して7-zipで圧縮したものをデコード。

pngはzipですよ

pngとzipの違いは圧縮対象のフォーマットを限定しているかの違い。
どうでもいいけど可逆圧縮はフレーム内圧縮しかしてない場合が多いから
zipとかで圧縮するとさらに縮むよ。当然ソースによるけど。

>>939
MPEG2じゃなくてVHSとかDVとかMJPEGとかのデータ。
>>943
ZIPって動画も縮むの？
exeだけかと思ってたよ。
つべ動画でも圧縮して試してみる。

普段解凍しかしないけど初めてZIPで圧縮してみた。
やっぱ動画は無理みたいで手持ちのいくつか試したけど2％とかしか縮まない。
静止画はJPEGがまったく縮まない。
BMPが80％も縮んだ。
動画圧縮ソフトもZIPと同じ程度？

可逆圧縮っつってるじゃないかｗ

可逆圧縮のスレなのになんで>>944とか>>945みたいのが来るの？

頭が弱いから

>>923
RGBA圧縮有効でいけない？

VHSデータって

7zipって恐ろしく縮むが、あれ動画の可逆に使えんのかね

なんなんだこの何だかなぁの流れはw
ここはDTVだぞw データ圧縮の話はソフト板でやってくれよw

>>945
JPEGはMPEGなんかと同じで不可逆で目一杯圧縮しているから。

一応MJPGには可逆もアル

huffyuvのほうが軽い罠

俺が試したコーデックが糞だったのかもしれないが。

ZLIB
http://ja.wikipedia.org/wiki/AVIzlib
Huffyuv
http://ja.wikipedia.org/w/index.php?title=Huffyuv&action=edit

huffyuvのマルチスレッド版使っている人いるかな？
安定していますか？

>>957
使ってる、安定してるよ

>>958
そうですか、安心しました。情報ありがとうございます。
おいらも使うことにします。

YUY2 Lossless Codec (YLC) version 0.25 2008/3/8
ttp://ruriruri.zone.ne.jp/aviutl/

なんかｷﾀよよよ

>>960
うおー激しく試してぇ

実用向きじゃないっぽいね
ただのおまけだから仕方ないか

俺もオマケでコーデック作れちゃうような人になりたい

次スレ用リンク纏めはこうですか？わかりません＞＜


Huffyuv 2.1.1（安定版）
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html

Huffyuv_mt（マルチスレッド化）
http://www29.atwiki.jp/lossless/pages/11.html

Lagarith Lossless Video Codec
http://lags.leetcode.net/codec.html

YUY2 Lossless Codec (YLC)
http://ruriruri.zone.ne.jp/aviutl/

YLCえらく縮まね？

Lagarith程ではない

今のところ私家版Lagarithが一番縮むと思う

>>965
ＬＣＬが抜けてる

ＬＣＬ　
http://www.geocities.jp/sandk_project/LRC.htm

http://www29.atwiki.jp/lossless/pages/11.html

http://www29.atwiki.jp/lossless/?plugin=ref&serial=13

>>719 Lagarith_1315dev_SSE2_719.7z 要SSE2

これが一番最強

Lagarithだけど、720pや1080iをキャプるのに使っている御仁はいらっしゃるか？

ウチ(Q6600@3GHz)だと>>719版をマルチスレッドで使っても
720pをキャプチャしようとするとドロップしまくりで使えない。

Lagarithは確かに圧縮率は魅力だけどHDキャプだとコマオチしなくてもプレビューガクガクだから使えなかった。
どうせ再圧縮かけるしいまでもhuffyuvつかってる。YLCの負荷が低ければこっちに乗り換えてもいいかなぁ。

加えてみた

Huffyuv 2.1.1 （安定版）
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html

Lagarith Lossless Video Codec
http://lags.leetcode.net/codec.html

Huffyuv_mt （マルチスレッド化）、Lagarith_1315dev_SSE2_719 （SSE2対応化ほか）
http://www29.atwiki.jp/lossless/pages/11.html

YUY2 Lossless Codec (YLC)
http://ruriruri.zone.ne.jp/aviutl/

ＬＣＬ （旧ＬＲＣ）
http://www.geocities.jp/sandk_project/LRC.htm

全然抜けてる

MSU Lossless Video Codec
http://www.compression.ru/video/ls-codec/index_en.html#Download

CorePNG
http://www.free-codecs.com/download/CorePNG.htm

FastCodec
http://videosoft.org/codecs/

>>972
おっとYLCを忘れてた…
というわけで試してみたけどマルチスレッド時のLagarithより重かった…無念。
キャプチャ中のCPU使用率を見る限りマルチスレッド化もされてないみたい。
（マルチスレッド化されたら結構イケるのかも？）

huffyuvの偉大さに改めて感動。

huffyuv MT版使うと1分に5ﾌﾚｰﾑずつくらいドロップするなあ
ノーマルhuffyuvや無圧縮だと1時間でドロップは1ﾌﾚｰﾑくらいなのに、なんでだろ