可逆圧縮総合スレ Part2
可逆圧縮関連総合スレです
Part1 http://pc11.2ch.net/test/read.cgi/avi/1098022448/
祖先スレ http://pc5.2ch.net/test/read.cgi/avi/1056587462/
Part1 http://pc11.2ch.net/test/read.cgi/avi/1098022448/
祖先スレ http://pc5.2ch.net/test/read.cgi/avi/1056587462/
|
|
|
・huffyuv_mt
http://www29.atwiki.jp/lossless/pages/11.html
・Lagarith 私家版
http://www29.atwiki.jp/lossless/pages/11.html
・Lagarith Lossless Video Codec
http://lags.leetcode.net/codec.html
・huffyuv
http://cowscorpion.com/Codec/HuffYUV.html
・LCL
http://www.geocities.jp/sandk_project/LRC.htm
・YLC
http://ruriruri.zone.ne.jp/aviutl/
・MSU Lossless Video Codec
http://www.compression.ru/video/ls-codec/index_en.html
http://www29.atwiki.jp/lossless/pages/11.html
・Lagarith 私家版
http://www29.atwiki.jp/lossless/pages/11.html
・Lagarith Lossless Video Codec
http://lags.leetcode.net/codec.html
・huffyuv
http://cowscorpion.com/Codec/HuffYUV.html
・LCL
http://www.geocities.jp/sandk_project/LRC.htm
・YLC
http://ruriruri.zone.ne.jp/aviutl/
・MSU Lossless Video Codec
http://www.compression.ru/video/ls-codec/index_en.html
さっき見たら落ちてたので、とりあえず立てました。
乙
俺の場合、音感からは、ギクシャクを連想するので
カクカク動画に変換されてないかというような潜在的な不安がある
カクカク動画に変換されてないかというような潜在的な不安がある
>>2
なぜcowscorpion
なぜcowscorpion
8 ：名無しさん＠編集中：2008/03/15(土) 11:08:07 ID:wHbmVmIp
H.264 Losslessテンプレにも入ってないけど使ってるやつっているの?
sage忘れスマソ
乙
>>2
前スレにあったリンクと大分違うじゃないか
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/
前スレにあったリンクと大分違うじゃないか
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/
>>1
乙
乙
保守
>>11
この中でだとどれが一番CPUの負荷が少ない？
この中でだとどれが一番CPUの負荷が少ない？
CorePNGはクラッシュしたので試せなかったが、
ウチの環境(Q6600)だとhuffyuvが一番軽いな。
というか唯一HDキャプチャできるのがhuffyuv。
MT版は自分の環境に合わせてどうぞ。
ウチの環境(Q6600)だとhuffyuvが一番軽いな。
というか唯一HDキャプチャできるのがhuffyuv。
MT版は自分の環境に合わせてどうぞ。
あ、上で言ってるのはエンコード時の負荷ね。
YLCとhuffyuvはどっちがいいの？
軽さならhuffyuv、圧縮率ならYLC
AviUtl→TMPGencの流れでDVD用のMPEG2作ってるけど
YLCとhuffyuvで比べたら明らかにYLC使った方がぼやけて色が薄くなってる
YLCとhuffyuvで比べたら明らかにYLC使った方がぼやけて色が薄くなってる
色空間変換の方法が違うのではないでしょうか
おそらくTMPGEncで読み込むときにRGBになっているのでは？
ソースがYUY2ならなるべくYUY2のみで作業をすることをお勧めします
おそらくTMPGEncで読み込むときにRGBになっているのでは？
ソースがYUY2ならなるべくYUY2のみで作業をすることをお勧めします
このスレの職人達の活躍を見て、自分も動画圧縮プログラム作成に挑戦したくなったので試しに作ってみました。
な、なかなか難しいですな・・・
「使えるアルゴリズム」を考えた人がどれだけ凄いのか分かった気がします。
自分がヘボすぎるのもありますが。とりあえず結果を書きます。
ソース１は格闘ゲームをキャプチャしたもの。
設定は、512*384、30fps、24bit、Divx CBR650kbps。時間は約4分50秒。
無圧縮で約5GBが5分かかって約900MBになりました。
本家HuffYUVで試したところ、サイズは約1.7GBと倍近くになりましたが、時間は1分くらいで済みました。
ソース２は、背景固定で前景がフェードインアウトやスライドばっかりの動きの少ないもの。
VP6 VBR350kbps、FPS15、その他は同じ。時間は約1分半。
無圧縮だと約800MB、1分かかって約90MBになりました。
HuffYUVは10秒で約250MBです。
圧縮率ではHuffYUVを上回っていますが、速度が話にならないという結果になりました。
ソース自体が劣化してるのであまり参考にならないかもしれませんが。
自分の作ったやつは、基本的にフレーム間の差分をBZip2で圧縮してるだけなので、
圧縮アルゴリズム次第で圧縮率と速度が決まってしまうという何とも言い難い仕様です。
空間方向にもなんらかの処理を行えば圧縮率の改善につながるとは思うのですが・・・ここで挫折してしまいました。
結局自分で書いたのは、フレーム間差分抽出をMMXで最適化(?)したところくらいです。
こんなクソコードでもよければ、要望があればAgeます。
な、なかなか難しいですな・・・
「使えるアルゴリズム」を考えた人がどれだけ凄いのか分かった気がします。
自分がヘボすぎるのもありますが。とりあえず結果を書きます。
ソース１は格闘ゲームをキャプチャしたもの。
設定は、512*384、30fps、24bit、Divx CBR650kbps。時間は約4分50秒。
無圧縮で約5GBが5分かかって約900MBになりました。
本家HuffYUVで試したところ、サイズは約1.7GBと倍近くになりましたが、時間は1分くらいで済みました。
ソース２は、背景固定で前景がフェードインアウトやスライドばっかりの動きの少ないもの。
VP6 VBR350kbps、FPS15、その他は同じ。時間は約1分半。
無圧縮だと約800MB、1分かかって約90MBになりました。
HuffYUVは10秒で約250MBです。
圧縮率ではHuffYUVを上回っていますが、速度が話にならないという結果になりました。
ソース自体が劣化してるのであまり参考にならないかもしれませんが。
自分の作ったやつは、基本的にフレーム間の差分をBZip2で圧縮してるだけなので、
圧縮アルゴリズム次第で圧縮率と速度が決まってしまうという何とも言い難い仕様です。
空間方向にもなんらかの処理を行えば圧縮率の改善につながるとは思うのですが・・・ここで挫折してしまいました。
結局自分で書いたのは、フレーム間差分抽出をMMXで最適化(?)したところくらいです。
こんなクソコードでもよければ、要望があればAgeます。
うｐしないとわかんねだろ
ttp://kanechan.oh.land.to/soft/LossLessVideo.zip
↑とりあえずテスト版です。
ボタンを押してダイアログでファイルを選択するとテストが始まります。
圧縮ファイル名は「元のファイル名.mllv」になります。
VFW版コーデックがインストールされていない場合はたぶんエラーになります。
読み込んだフレームを圧縮し、解凍してフォームに表示します。
最後のフレームに到達するまで止まりませんのでご注意下さい。
読み込むファイルは2GBの制限がありますが、書き込みはファイルシステムの限界までいけます。
本当はコーデックとして作りたかったのですが、資料が全く見つからず・・・
↑とりあえずテスト版です。
ボタンを押してダイアログでファイルを選択するとテストが始まります。
圧縮ファイル名は「元のファイル名.mllv」になります。
VFW版コーデックがインストールされていない場合はたぶんエラーになります。
読み込んだフレームを圧縮し、解凍してフォームに表示します。
最後のフレームに到達するまで止まりませんのでご注意下さい。
読み込むファイルは2GBの制限がありますが、書き込みはファイルシステムの限界までいけます。
本当はコーデックとして作りたかったのですが、資料が全く見つからず・・・
自分の知る限りHuffyuvやLagarith, ffdshowはソース公開されているから、
VFWコーデックとして登録する部分の手掛かりに使えるかもしれない。
VFWコーデックとして登録する部分の手掛かりに使えるかもしれない。
そりゃまあ bzip2 はすんげー重いからなぁ。
右クリックからインスコしてもコーデックの選択画面にLagarithが出てこない俺はどうしたらいい？
OSはXP。スレチなら誘導よろしくお願いします。
OSはXP。スレチなら誘導よろしくお願いします。
デバマネのビデオコーデック見れ
Lagarithあるならソフトの操作をわかってない。ないならインスコできてない。
Lagarithあるならソフトの操作をわかってない。ないならインスコできてない。
デバマネにはありました。
プロパティを開くとLagarith lossless codec [LAGS] ドライバを読み込めません。ドライバファイルが見つからない可能性があります。
ドライバをインストールしなおすか、またはシステム管理者に問い合わせてください。
とあります。
これは俺はソフトの操作をわかっていなかったってことですかね。
プロパティを開くとLagarith lossless codec [LAGS] ドライバを読み込めません。ドライバファイルが見つからない可能性があります。
ドライバをインストールしなおすか、またはシステム管理者に問い合わせてください。
とあります。
これは俺はソフトの操作をわかっていなかったってことですかね。
見つからないっていってるならlegarith.dllをsystem32にでも突っ込んどけ
system32にはlagarith.dllあった。
とりあえず再起動
ん？32bit版だよね？
再起動してみたけど駄目でした。
使いたいのは32bit版です。
何かこれ以上インスコできないって質問するのも
スレチになってるような気がするので諦めます。
どうもありがとうございました。
使いたいのは32bit版です。
何かこれ以上インスコできないって質問するのも
スレチになってるような気がするので諦めます。
どうもありがとうございました。
huffyuvでエンコしたaviを再生すると映像も音もカクカクになるんですが、
ググっても同じ症状出てる人がいないような気がします。
皆さんは普通に再生できていますか？
ググっても同じ症状出てる人がいないような気がします。
皆さんは普通に再生できていますか？
単にスペックが足りてないだけじゃないの？
俺のスペックでGOMで再生するとカクカク、PowerDVDでぬるぬる
39 ：名無しさん＠編集中：2008/04/13(日) 17:24:27 ID:bqd7Yanr
huffyuvはデコードが重い
デコードが一番軽いのってどれだろう
デコードが一番軽いのってどれだろう
それ、デコードじゃなくファイルの転送速度が遅くてカクついてるだけじゃない？
huffyuvのデコードが遅いのは確か。一番速いはずのpredict leftでもかなり遅い。
デコードだけならYLCやLagarithの方が速いが、huffyuv_mtだともっと速い。
計測環境はQ6600ね。
デコードだけならYLCやLagarithの方が速いが、huffyuv_mtだともっと速い。
計測環境はQ6600ね。
速度に関係するのはCPUだけじゃないと何度言えば
fastcodec早いよ
44 ：名無しさん＠編集中：2008/04/14(月) 21:06:34 ID:FFWLA2Q5
toponokyってどうなん
http://videosoft.org/codecs/toponoky
http://videosoft.org/codecs/toponoky
Version 1.3.15 released on 4-13-2008
Fixed a bug that would cause the top left corner to have chroma errors when encoding to YV12 with a video who's width was not a multiple of 32. Thanks to Marc for reporting this.
Fixed a bug where a solid colored YUY2 frame would decode as black. Thanks to Markus Krapf and Bart Barenbrug for reporting this.
Added more error checking, this should help prevent crashes with corrupted files from Premiere.
Changed to using Visual Studio 2005 to compile the 32bit dll, thanks to gl.tter for helping with porting the project.
Fixed a bug that would cause the top left corner to have chroma errors when encoding to YV12 with a video who's width was not a multiple of 32. Thanks to Marc for reporting this.
Fixed a bug where a solid colored YUY2 frame would decode as black. Thanks to Markus Krapf and Bart Barenbrug for reporting this.
Added more error checking, this should help prevent crashes with corrupted files from Premiere.
Changed to using Visual Studio 2005 to compile the 32bit dll, thanks to gl.tter for helping with porting the project.
Lagarith codec (v1.3.15)
toponokyをちょっと試してみた。YUY2ソースね。
普通のソースだと、処理が重いわ小さくならないわでこれはちょっと。
huffyuvに速度も圧縮も両方負けてちゃダメだろ…
白黒なYUY2ソース（字幕動画）だとhuffyuvより縮むけど、
今度はLagarith（nullフレーム無効）に速度も圧縮も負ける。
というわけで、私の意見としては「全く使えない」という結論になりました。
普通のソースだと、処理が重いわ小さくならないわでこれはちょっと。
huffyuvに速度も圧縮も両方負けてちゃダメだろ…
白黒なYUY2ソース（字幕動画）だとhuffyuvより縮むけど、
今度はLagarith（nullフレーム無効）に速度も圧縮も負ける。
というわけで、私の意見としては「全く使えない」という結論になりました。
48 ：名無しさん＠編集中：2008/04/16(水) 17:12:41 ID:s5wN79KF
すみませんがスレ違いならスルーお願いします。
無圧縮AVIファイルを
ttp://homepage2.nifty.com/sabokoha/KZ/HOKOUKEC.htm
等を参考にHuffyuv2.1.1をインストールして可逆圧縮したんですけどVirtualDubでもAfterEffectsでも
圧縮どころか元ファイルの3倍に膨れ上がってしまいます
助けてください
無圧縮AVIファイルを
ttp://homepage2.nifty.com/sabokoha/KZ/HOKOUKEC.htm
等を参考にHuffyuv2.1.1をインストールして可逆圧縮したんですけどVirtualDubでもAfterEffectsでも
圧縮どころか元ファイルの3倍に膨れ上がってしまいます
助けてください
ａｖｉｕｔｌでやれば
つかエンコしてるAVIは実は無圧縮じゃないという落ちな気がする
無圧縮aviを可逆圧縮したら確実に縮む
膨れ上がるなんて100％有り得ない
DivXとかH264のAVIってオチだろ
膨れ上がるなんて100％有り得ない
DivXとかH264のAVIってオチだろ
52 ：48：2008/04/17(木) 03:49:26 ID:k76XJqYp
真空波動研に入れたら
720x480 24Bit DV Codec(DVSD) 29.97fps 8128f PCM 48.00kHz 16Bit 2ch 1536kbps
と出ました
DVSDで検索してみましたがよくわかりませんでした
720x480 24Bit DV Codec(DVSD) 29.97fps 8128f PCM 48.00kHz 16Bit 2ch 1536kbps
と出ました
DVSDで検索してみましたがよくわかりませんでした
…
それでわかんないなら誰が何言っても無駄だから諦めろ
それでわかんないなら誰が何言っても無駄だから諦めろ
1536kbps
Huffyuv2.2.0のバグって具体的にどんなの?
ぬるぽ。
>>48
答えは>>50なわけだけど質問に対する回答をするなら
そのソース（圧縮前の動画ファイル）は無圧縮ではなく、「DV Codec(DVSD) 」というコーデックによる非可逆圧縮がなされています。
よってそのソースに対して、一般に非可逆圧縮よりも圧縮効率の悪い可逆圧縮を行うとデータサイズが膨れ上がります。
ちなみにソースが未圧縮であるのならば真空波動研では以下のように明確に「無圧縮」と表記があるはずです。
320x240 24Bit 無圧縮 29.97fps 395f 55244.54kb/s
答えは>>50なわけだけど質問に対する回答をするなら
そのソース（圧縮前の動画ファイル）は無圧縮ではなく、「DV Codec(DVSD) 」というコーデックによる非可逆圧縮がなされています。
よってそのソースに対して、一般に非可逆圧縮よりも圧縮効率の悪い可逆圧縮を行うとデータサイズが膨れ上がります。
ちなみにソースが未圧縮であるのならば真空波動研では以下のように明確に「無圧縮」と表記があるはずです。
320x240 24Bit 無圧縮 29.97fps 395f 55244.54kb/s
保守
あ
ﾎﾞｰﾝ？(´・ｪ・｀)
Huffyuv_mt （マルチスレッド化）って転載OK?
HuffyuvはGPL。当然ｍｔも感染してGPL
あとは押して知るべし
あとは押して知るべし
Huffyuv_mtはx264で使えないの？
使えるよ
>>67
AviSynth使ってます。そのせいかな？
AviSynth使ってます。そのせいかな？
>>69
VirtualDubで開けなくて調べてみたところ、
原因は入力ファイルをDirectShowSource(...)で開いていたからでした。
AVISource（...）で開くとエンコードできました。初歩的なことですいません。
ありがとうございました。
VirtualDubで開けなくて調べてみたところ、
原因は入力ファイルをDirectShowSource(...)で開いていたからでした。
AVISource（...）で開くとエンコードできました。初歩的なことですいません。
ありがとうございました。
だれかHuffyuv_mtのコマンドライン版作ってくれないかな？
avsから直につなげたいんです。
avsから直につなげたいんです。
mencoder使えばよくね？
Q9300でhuffyuv_mt使おうと思ったのですが、ドロップしてしまいます。
huffyuvではおきません。Quad環境では安定してないのでしょうか？
huffyuvではおきません。Quad環境では安定してないのでしょうか？
Q6600で問題ありません＞＜
huffyuv2.1.1を初めて導入してキャプりましたが、出来たaviファイルを
エクスプローラからクリックしただけでエクスプローラが落ちます。
落ちる理由はhuffyuv.dllです。
アンインストしてhuffyuv_mt_712を入れましたが同じです。
落ちる理由はhuffyuv_mt.dllです。
試しに他のソースからhuffyuvでエンコしたaviファイルも落ちます。
しかし、キャプったのもエンコしたのもAviUtlでは普通に読み込め再生ウィンドウから
再生できエンコ(DivX等に)も出来ます。
削除はフォルダごと、または、DOSプロンプトから出来ます。
エクスプローラでさわれないだけのようなのですが、改善の方法がありますでしょうか？
Xp pro sp2 です。よろしくお願いします。
エクスプローラからクリックしただけでエクスプローラが落ちます。
落ちる理由はhuffyuv.dllです。
アンインストしてhuffyuv_mt_712を入れましたが同じです。
落ちる理由はhuffyuv_mt.dllです。
試しに他のソースからhuffyuvでエンコしたaviファイルも落ちます。
しかし、キャプったのもエンコしたのもAviUtlでは普通に読み込め再生ウィンドウから
再生できエンコ(DivX等に)も出来ます。
削除はフォルダごと、または、DOSプロンプトから出来ます。
エクスプローラでさわれないだけのようなのですが、改善の方法がありますでしょうか？
Xp pro sp2 です。よろしくお願いします。
縮小表示やめれ
エクスプローラの表示形式をいろいろ変えてもダメでした。
縮小版だけは縮小版に切りかえただけで落ちます。
あとの表示形式はファイルをクリックすると落ちます。
縮小版だけは縮小版に切りかえただけで落ちます。
あとの表示形式はファイルをクリックすると落ちます。
DOS窓から開けばイイよ．．
>>76
同じ症状になったことがある。
-----
Explorerが落ちたときにageるスレ その3
http://pc11.2ch.net/test/read.cgi/win/1167477933/
78 ：名無し~3.EXE ：2007/10/16(火) 01:05:54 ID:1B/tUYQ+
>>7
と同じ症状に俺もなった。
コーデック入れなおしたりとか試したけど治らず。
フォルダオプション→ファイルの種類からAVI削除して
もう一度AVI追加したら何故か治ってた。
参考までに。
-----
↑これで一時的に直ったんだけど、また同じ症状に。
原因を探っていったら、オイラの環境ではNero8とHuffyuvの相性が悪かったらしく
Nero8をアンインストールしたら解決した。Nero6では不具合なし。
参考にならんかもしれんけど一応。
同じ症状になったことがある。
-----
Explorerが落ちたときにageるスレ その3
http://pc11.2ch.net/test/read.cgi/win/1167477933/
78 ：名無し~3.EXE ：2007/10/16(火) 01:05:54 ID:1B/tUYQ+
>>7
と同じ症状に俺もなった。
コーデック入れなおしたりとか試したけど治らず。
フォルダオプション→ファイルの種類からAVI削除して
もう一度AVI追加したら何故か治ってた。
参考までに。
-----
↑これで一時的に直ったんだけど、また同じ症状に。
原因を探っていったら、オイラの環境ではNero8とHuffyuvの相性が悪かったらしく
Nero8をアンインストールしたら解決した。Nero6では不具合なし。
参考にならんかもしれんけど一応。
>>80
うわぁぁっ、解決しました！！
ちょっと興奮していますっ。
ググっても全然載ってなくて、いろいろやっても出来なくて困っていました。
Nero8 ←モロこいつでした。
アンインストしたら落ちなくなりました。
＞原因を探っていったら、オイラの環境ではNero8とHuffyuvの相性が悪かったらしく
よくわかりましたね。ありがとうございました。感謝です。
うわぁぁっ、解決しました！！
ちょっと興奮していますっ。
ググっても全然載ってなくて、いろいろやっても出来なくて困っていました。
Nero8 ←モロこいつでした。
アンインストしたら落ちなくなりました。
＞原因を探っていったら、オイラの環境ではNero8とHuffyuvの相性が悪かったらしく
よくわかりましたね。ありがとうございました。感謝です。
>>75
バージョン 3.3.0でてた
バージョン 3.3.0でてた
エロサイトの転送アドレス貼って業者必死だな
今見たら転送停止扱いになってるがご愁傷様ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
今見たら転送停止扱いになってるがご愁傷様ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
捕捉されたって書いてある。
期待してますぜ。
期待してますぜ。
高速化したらしいしかなり期待できそう。
次のエンコで使ってみるかな。
次のエンコで使ってみるかな。
>>84が何を言ってるのか分からない
バージョン 3.3.0
性能向上
* 共通: デコードを高速化した。Core 2 の場合で 20% 程度。これでシングルスレッドでも Huffyuv (Predict median) より有意に速くなった。
* 共通: エンコードを高速化した。Core 2 の場合で 8% 程度。
* ULY2: RGB32 へのデコードをアセンブラ化により高速化した。Core 2 の場合で 47% 程度（前述の共通の高速化の効果を含む）。
バグ修正
* 共通: 処理できないフォーマットを渡してエンコード/デコードを開始しようとしてもエラーにならない。
ささいなことだけどバグ修正のところがならなないになってた。
性能向上
* 共通: デコードを高速化した。Core 2 の場合で 20% 程度。これでシングルスレッドでも Huffyuv (Predict median) より有意に速くなった。
* 共通: エンコードを高速化した。Core 2 の場合で 8% 程度。
* ULY2: RGB32 へのデコードをアセンブラ化により高速化した。Core 2 の場合で 47% 程度（前述の共通の高速化の効果を含む）。
バグ修正
* 共通: 処理できないフォーマットを渡してエンコード/デコードを開始しようとしてもエラーにならない。
ささいなことだけどバグ修正のところがならなないになってた。
CPU:QX6700@3GHz,Mem:DDRII667
ソース:MotionJpeg,30fps,35s,1920x1080
スレッド数はhuffyuvMT,UtVideo(3.3.0)ともに4スレッド
huffyuvはPredict leftを使用
LagarithはYUY2でマルチスレッド、NULLをオン
ViutualDub1.8.0でFastRecompressを使用
huffyuvMT:75fps,1.41GB
UtVideo:64fps,1.04GB
Lagarith:19fps,999MB
以上が圧縮の比較。
デコードの比較としてエンコードしたソースを
huffyuvMTに再エンコードする速度を見た。
huffyuvMT:60fps
UtVideo:49fps
Lagarith:14fps
ちなみにソースをhuffyuvMTのPredict medianにして
huffyuvMTのPredict leftに再エンコードするときは45fpsで
作者様の言うとおりUtVideoのほうが速い。
ただし、Predict medianは圧縮率も向上し1.14GBになった。
ソース:MotionJpeg,30fps,35s,1920x1080
スレッド数はhuffyuvMT,UtVideo(3.3.0)ともに4スレッド
huffyuvはPredict leftを使用
LagarithはYUY2でマルチスレッド、NULLをオン
ViutualDub1.8.0でFastRecompressを使用
huffyuvMT:75fps,1.41GB
UtVideo:64fps,1.04GB
Lagarith:19fps,999MB
以上が圧縮の比較。
デコードの比較としてエンコードしたソースを
huffyuvMTに再エンコードする速度を見た。
huffyuvMT:60fps
UtVideo:49fps
Lagarith:14fps
ちなみにソースをhuffyuvMTのPredict medianにして
huffyuvMTのPredict leftに再エンコードするときは45fpsで
作者様の言うとおりUtVideoのほうが速い。
ただし、Predict medianは圧縮率も向上し1.14GBになった。
91 ： ◆Ut/Ut/NqTI ：2008/05/18(日) 17:50:37 ID:BKgw0e9A
>>89
あ、ご指摘どうも…直しときました。
あ、ご指摘どうも…直しときました。
おっと作者登場？今はまだ使ってないけど期待してるよ
作者ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!
3．3.0いただきました。
3．3.0いただきました。
作者様、ｖｆｗだけじゃなくｃｌi版も作ってくださいな。
mencoderとかメンドくて・・
mencoderとかメンドくて・・
試してみたけどDScalerで使えんな…
今のところ中間ファイルに利用してる人が大多数だと思うんだけど、
速度が速くなるのは、圧縮率があがるよりありがたいね。
速度が速くなるのは、圧縮率があがるよりありがたいね。
ファイルサイズも一番小さいLagarithと比較しても殆ど同等で
速度は圧倒的にUtVideoが速いからいいね
速度は圧倒的にUtVideoが速いからいいね
あとはキャプチャソフトに使えれば文句なしだな
>>98
kusunokiTVHDで使えてるけど？
kusunokiTVHDで使えてるけど？
>>99
display2aviとかdisplay2aviとか…金は払いたくないので
display2aviとかdisplay2aviとか…金は払いたくないので
YV12で出力出来るとDVDrip物でも使えるんだけど
>>99
俺もkusunokiTVHDだけど駄目なんだがｗ
俺もkusunokiTVHDだけど駄目なんだがｗ
俺も楠だけど、無事使えてるよ。1.5時間ほど（映画1本）で、150Gくらいだった。
で、負荷はかかるけど、Q6600とRAID0で、そのまま再生できてる。
作者さんマジで乙です。VerUp期待してます。
で、負荷はかかるけど、Q6600とRAID0で、そのまま再生できてる。
作者さんマジで乙です。VerUp期待してます。
作者が2ｃｈに降臨したりすると後々面倒だぜ
x64Vistaですけど、普通にくすのきで使えてます＞＜
ふぬああのhunuaa AVI Muxで使えてるよ
４コア利用できて(ﾟдﾟ)
圧縮後のサイズがhuffyuvの半分になってくれれば
HDDに優しくなって更に(ﾟдﾟ)なんだけど期待していますよ
４コア利用できて(ﾟдﾟ)
圧縮後のサイズがhuffyuvの半分になってくれれば
HDDに優しくなって更に(ﾟдﾟ)なんだけど期待していますよ
個人的にはｓｓｅ３とか４とかに対応してさらなる高速化に力を入れてほしいけど
まああんまり要望出し過ぎると>>104が言ってるみたいになりそうだし自重する。
中間ファイルに使うだけだから個人的には十分だからね。
まああんまり要望出し過ぎると>>104が言ってるみたいになりそうだし自重する。
中間ファイルに使うだけだから個人的には十分だからね。
UtVideoさっそくつかわせていただきました。
MxCapture 最新版 hunuaaAVI Muxで使えてます。
MonsterXでのTrid6200.sys 差し替え版でも問題なく動いている模様です。
2分強のD4ソースですがドロップフレームは発生しませんでした。
サイズはhuffyuvMTで4.5GBが UtVideoでは3.5GBまで縮んでいます。
再生もRAID組んでませんが、huffyuvMTよりもつっかかりが少なくスムーズです。
Q6600定格 DDR800 3GB です。
本当にありがとうございました。
MxCapture 最新版 hunuaaAVI Muxで使えてます。
MonsterXでのTrid6200.sys 差し替え版でも問題なく動いている模様です。
2分強のD4ソースですがドロップフレームは発生しませんでした。
サイズはhuffyuvMTで4.5GBが UtVideoでは3.5GBまで縮んでいます。
再生もRAID組んでませんが、huffyuvMTよりもつっかかりが少なくスムーズです。
Q6600定格 DDR800 3GB です。
本当にありがとうございました。
huffyuvで4.5GBの場合、2.5ＧＢくらいにして欲しいです。
それだけ減れば保険でRAID0にするのも必要なくなるな
正直、Huffyuvの1.5倍くらいの容量でもいいから、とにかく速度が速くなって欲しいな
それなら無圧縮使えばいいんでない？
huffyuvは現在のCPUなら余力が残ってるけど
HDDの転送速度の余力が無いから、HDDの転送速度は進化が止まってるから
やはりcodecは圧縮率アップの進化の方が正当なんじゃないかな。
huffyuvは現在のCPUなら余力が残ってるけど
HDDの転送速度の余力が無いから、HDDの転送速度は進化が止まってるから
やはりcodecは圧縮率アップの進化の方が正当なんじゃないかな。
となると容量と速度にはある程度相関関係があると言うことなのか？
無圧縮は容量でかすぎて、流し確認する時に再生負荷がつらすぎる。
ので、Huffyuvの1.5倍くらいなら大丈夫だろうと。
ので、Huffyuvの1.5倍くらいなら大丈夫だろうと。
速けりゃいいんだったらfastcodecでいいんじゃないの
単純に言うと、メモリに展開する速度が
HDDから読み込む速度より早いコーデックなら容量が小さい方が早い。
HDDから読み込む速度より早いコーデックなら容量が小さい方が早い。
117 ：名無しさん＠編集中：2008/05/24(土) 02:25:29 ID:YPoXMwCE
UtVideo ver3.3.1きてるよ
Display2AVI で使えるようになったそうだ
製作者いわく「ちょっとしたバグFixなので現状で問題なかったらそのままどーぞ」だって。
ソースも公開されているから俺も開発追うかなあ…
Display2AVI で使えるようになったそうだ
製作者いわく「ちょっとしたバグFixなので現状で問題なかったらそのままどーぞ」だって。
ソースも公開されているから俺も開発追うかなあ…
開発するのならもっと高圧縮の奴お願いします
Display2AVIで使える！ktkr
さらばHuffyuv、そしてようこそUtVideo
さらばHuffyuv、そしてようこそUtVideo
UtVideo Ver3.3.1を落とそうとするとなぜか拡張子が.manになる
やべ、UtVideo今日始めて知った。これのフレーム分割ってCPUコア数で良いの？
CPU使用率の使い方を見る限りはコア数ですね。
UtVideo、Huffyuvの2/3と可逆では圧縮率申し分無いんだけど、
画質を少々削っても1/2くらいになる非可逆モードを追加して欲しいです。
UtVideo、Huffyuvの2/3と可逆では圧縮率申し分無いんだけど、
画質を少々削っても1/2くらいになる非可逆モードを追加して欲しいです。
どのコーデックも速度については、どんぐりの背比べだな。
C2QにてUtVideoでフレーム分割数4にしてもCPU負荷が30%弱なんだが、他の人も同じかい？
C2QにてUtVideoでフレーム分割数4にしてもCPU負荷が30%弱なんだが、他の人も同じかい？
フレーム分割数を大きくすると、ファイルサイズとエンコード時間が増える。
CPU負荷は1の時が一番高くてエンコード速度も速い。
フレーム分割数の説明きぼん
CPU負荷は1の時が一番高くてエンコード速度も速い。
フレーム分割数の説明きぼん
>>124
私もQ9450を使っていますが、フレーム分割数は1より4のほうが高速でした。
後、エンコ素材がシングルスレッドでデコードするものは確かに40％位で負荷が頭打ちでしたが、
マルチスレッドでデコードするものは最大で90％近くは使ってくれました。
どーでもいいですが、Aviutlで出力するときは、AVI出力（マルチスレッド）を使うといいかも
私もQ9450を使っていますが、フレーム分割数は1より4のほうが高速でした。
後、エンコ素材がシングルスレッドでデコードするものは確かに40％位で負荷が頭打ちでしたが、
マルチスレッドでデコードするものは最大で90％近くは使ってくれました。
どーでもいいですが、Aviutlで出力するときは、AVI出力（マルチスレッド）を使うといいかも
フレーム分割ってスレッド数のことだったのか
ググってみたら「AVIファイルをフレーム分割してgifファイルを～」みたいな解説サイトがあって？？？だった
ググってみたら「AVIファイルをフレーム分割してgifファイルを～」みたいな解説サイトがあって？？？だった
馬鹿すぎて泣ける
>>125
もっかい確認したけど、こっちでは分割数4より1のほうが速いね。
CPU負荷は30%前後、VirtualDub1.8使用。
ちなみにWMV9VCMをパフォーマンス100で使ったりするとCPU負荷は
50%を超えるのでVirtualDub自体はマルチスレッド対応かと。
CPUを効率的に利用するという点では、もちろんデコーダーからフィルタ
まで可能な限りマルチスレッド対応にしたほうがいいね。
もっかい確認したけど、こっちでは分割数4より1のほうが速いね。
CPU負荷は30%前後、VirtualDub1.8使用。
ちなみにWMV9VCMをパフォーマンス100で使ったりするとCPU負荷は
50%を超えるのでVirtualDub自体はマルチスレッド対応かと。
CPUを効率的に利用するという点では、もちろんデコーダーからフィルタ
まで可能な限りマルチスレッド対応にしたほうがいいね。
非可逆なんかいらん、MJPGでも使ってな
今望まれてるのは圧縮率と展開速度重視だね
今望まれてるのは圧縮率と展開速度重視だね
CPU負荷が高すぎてもソフトウェアキャプだと都合が悪いので30%前後でいいんじゃない。
むしろ4コアムラなく使ってる効率の良さを誉めたい。
むしろ4コアムラなく使ってる効率の良さを誉めたい。
可逆が出る前はMJPGが主流だったんす
そういう古参な話も聞いてやれよ
そういう古参な話も聞いてやれよ
まぁまぁｗ
MJPGもそろそろ老朽化してきたしMJPGに変わるポストMJPGも欲しいじゃない。
俺は開発能力が無いので神頼みだけど。なによりスレ違いだし。
MJPGもそろそろ老朽化してきたしMJPGに変わるポストMJPGも欲しいじゃない。
俺は開発能力が無いので神頼みだけど。なによりスレ違いだし。
そう言う奴は黙ってカノプHQでも使っておけばおｋ
utvideoいいですね
RGBAもきぼんぬ
RGBAもきぼんぬ
Utvideoってメディアプレーヤーだと逆さまになるな
うちではそんなこと無いけど
インストールするときトラブったから変になったのかな
ﾜｯｼｮｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｯｼｮｲﾜｯｼｮｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｯｼｮｲ
誤爆しました
UtVideo3.4.0で上下反転しなくなったー。作者様ありがとー。
仕事が速いなぁ。頑張りすぎて途中でぽっきり折れたりしませんように。
あとはバグフィックスがメインじゃないかな
今でも十分使えるし
今でも十分使えるし
デコーダだけでした(´･ω･`)
使えるっていっても、まだhuffyuv_mtから乗り換えるような理由が薄いし
もっとガツっと軽くなるとか、売りがほしい
もっとガツっと軽くなるとか、売りがほしい
まぁ結局中間ファイルだからなぁ…
積極的に乗り換える理由もないけど俺は新しいもの好きだからutvideoに切り替えたわ。
今のところ安定して使えてるし元がでかいから量が増えたら違いもばかにならんしな。
積極的に乗り換える理由もないけど俺は新しいもの好きだからutvideoに切り替えたわ。
今のところ安定して使えてるし元がでかいから量が増えたら違いもばかにならんしな。
Lagarithのが縮むし
残念ながら俺のしょぼいPCじゃLagarithは問題外
圧縮速度が速くなるとうれしいんだが
AthlonXP2500+でも使えるようになるとうれしい
ﾓﾚも中間ファイルオンリーの使い方だけど、C2Qで
fastcodec
Huffyuv_mt
Huffyuv2.2
Lagarith
FFV1
UTvideo
を設定変えて試したけどHuffyuv2.2が一番速いわ。
部分的にマルチスレッド化しているHuffyuv2.1.1より速いのが意外。
>>149
可逆コーデックの使い道は、キャプチャと中間ファイルがあるから
そういう言い方すると、はぁ？とかいう奴がいるから気をつけるべし。
fastcodec
Huffyuv_mt
Huffyuv2.2
Lagarith
FFV1
UTvideo
を設定変えて試したけどHuffyuv2.2が一番速いわ。
部分的にマルチスレッド化しているHuffyuv2.1.1より速いのが意外。
>>149
可逆コーデックの使い道は、キャプチャと中間ファイルがあるから
そういう言い方すると、はぁ？とかいう奴がいるから気をつけるべし。
ああ、そうか。最近キャプボ買ったから思考が偏ってたわ…
>>154
そんなに試したのなら研究発表してくれたらいいのに
そんなに試したのなら研究発表してくれたらいいのに
自分はLagarithは色ノイズが出るから中間ファイルの対象外
ﾓﾚも（笑）
TMPGEncだといまだになるけどVirtualDubなら平気だぜ
>>156
自分のメモ程度な上に、たぶん正確じゃないよ。
自分のメモ程度な上に、たぶん正確じゃないよ。
うーん、UtVideo3.40でとったファイルが、UleadのMediastudioPro8で
BMPファイルはサポートされてません。
って蹴られる。
どうしてだろう？
BMPファイルはサポートされてません。
って蹴られる。
どうしてだろう？
上。yuv422で撮った奴です Aviutlでは問題なく開けましたが。
RGBモードならうまくいった。 MS8proの問題かな？
UtVideoの配布先、落ちてる？
OS再インストールしたんで、コーデック拾いに行ったんだが… orz
OS再インストールしたんで、コーデック拾いに行ったんだが… orz
落ちてるね
ドメイン見ると自鯖だな
2,3ミラーしているとこがあったはず
ドメイン見ると自鯖だな
2,3ミラーしているとこがあったはず
GPLってうｐしてもいいんだっけ？
うｐしようか？
うｐしようか？
170 ：名無しさん＠編集中：2008/05/30(金) 22:55:18 ID:bW+iilcN
データが64bitsって分かってるときどうやったら最も効率よく可逆圧縮できますか？
つまり、2^64通りすべてを圧縮したとき圧縮率＝（圧縮後のbit数）/64の期待値を最小に
するような方法です。
つまり、2^64通りすべてを圧縮したとき圧縮率＝（圧縮後のbit数）/64の期待値を最小に
するような方法です。
あ、ごめんなさい。技術的なスレじゃなかったですね。忘れてください
UtVideo使わせてもらってます。
VirtualDubModで読み込むと
必ずエンコ終わりで落ちるんですが私だけ？
エンコ自体は成功してるので別にいいんですけど
他の可逆だと落ちないんで。
VirtualDubModで読み込むと
必ずエンコ終わりで落ちるんですが私だけ？
エンコ自体は成功してるので別にいいんですけど
他の可逆だと落ちないんで。
>>172
俺もなった
俺もなった
>>173
俺はならない
俺はならない
[UtVideo] バージョン 3.5.0
177 ：名無しさん＠編集中：2008/06/02(月) 23:27:04 ID:lI4mMKWx
[UtVideo] バージョン 3.5.0
機能追加
ULY2: デコード時に RGB24 で出力できるようにした。最初からアセンブラバージョンがある。
バグ修正
ULY2: RGB24 エンコード時に、横幅が 4 の倍数ではない場合、映像の右端にゴミが発生する。
readme ファイル インストーラ（msi 形式） ソース
ULY2 の RGB24 出力ですが、これにより MS8 や VS12 で読み込めるようになるはずです。
機能追加
ULY2: デコード時に RGB24 で出力できるようにした。最初からアセンブラバージョンがある。
バグ修正
ULY2: RGB24 エンコード時に、横幅が 4 の倍数ではない場合、映像の右端にゴミが発生する。
readme ファイル インストーラ（msi 形式） ソース
ULY2 の RGB24 出力ですが、これにより MS8 や VS12 で読み込めるようになるはずです。
UtVideo唯一の欠点
作者がニコ厨
作者がニコ厨
作者の方、アップデートご苦労様です。
BUGFIXがうまくいったか、試してみたいところですが、ちょっと忙しいので待ってください。
BUGFIXがうまくいったか、試してみたいところですが、ちょっと忙しいので待ってください。
Lagarithほどじゃなくてもhufyuvよりはノイズがあんだけど…
他の可逆よりhufyuv系の方が画質がいい感じがするんだが気のせいかな
それってもう可逆じゃないじゃん
気のせい
爆釣ですね＞＜
[UtVideo] バージョン 3.6.0
性能向上
ULY2: RGB24 からのエンコードをアセンブラ化により高速化した。Core 2 の場合で 42% 程度。これでシングルスレッドでも Huffyuv (Predict median) より有意に速くなった。
乙です
性能向上
ULY2: RGB24 からのエンコードをアセンブラ化により高速化した。Core 2 の場合で 42% 程度。これでシングルスレッドでも Huffyuv (Predict median) より有意に速くなった。
乙です
UtVideoの作者さん乙です。更新はやいな～。
この調子でYUV出力でもHuffYUV2.2より速くなるといいんだが。
この調子でYUV出力でもHuffYUV2.2より速くなるといいんだが。
速さの次は出力サイズをHuffYUVの半分にする方向性だな
10MB/sくらいになればいいなあ
スレ違いとは思いますが、
いつからか、編集ソフトで作ったファイルをエクスプローラで選択しようとするだけで、
コーデックの種類によってはアプリケーションエラーが出るようになってしまいました。
現状、無圧縮、DV、wmvは大丈夫なのですがHuffYUV、UtVideo、CanopuHQはダメです。
エラーメッセージは以下のような感じです。
～の命令が～のメモリをアクセスできませんでした。
メモリはwritenになることができませんでした。
原因分かりませんでしょうか？
いつからか、編集ソフトで作ったファイルをエクスプローラで選択しようとするだけで、
コーデックの種類によってはアプリケーションエラーが出るようになってしまいました。
現状、無圧縮、DV、wmvは大丈夫なのですがHuffYUV、UtVideo、CanopuHQはダメです。
エラーメッセージは以下のような感じです。
～の命令が～のメモリをアクセスできませんでした。
メモリはwritenになることができませんでした。
原因分かりませんでしょうか？
とりあえず直したいだけなら、OS再インスコするか、エクスプローラーの情報を取得を
簡易ツール使ったり、レジストリ弄ったりして止めればいい。
例えば、ここの２とか。
ttp://element.dip.jp/~hm/memo/winsetting/explorer/document.html
簡易ツール使ったり、レジストリ弄ったりして止めればいい。
例えば、ここの２とか。
ttp://element.dip.jp/~hm/memo/winsetting/explorer/document.html
>>190,191,192
怒涛のレスありがとうございます。
>>190さん、>>191さんを参考にffdshowコーデックパック、Nero7をアンインストール
しましたが同じでした。
ところが、>>192さんを参考にレジストリを書き換えると、おお～！、直りました。
ちょっと強引な方法みたいですが、にっちもさっちも行かない状態だったので
大変助かりました。
本当にありがとうございました。
怒涛のレスありがとうございます。
>>190さん、>>191さんを参考にffdshowコーデックパック、Nero7をアンインストール
しましたが同じでした。
ところが、>>192さんを参考にレジストリを書き換えると、おお～！、直りました。
ちょっと強引な方法みたいですが、にっちもさっちも行かない状態だったので
大変助かりました。
本当にありがとうございました。
194 ：名無しさん＠編集中：2008/06/07(土) 23:44:54 ID:ki6U6zEN
圧縮率設定も欲しい。
リアルタイムエンコに必要な推奨はintelのCPUならば
速度重視（速度速いが圧縮小）:E1200
中間（速度も圧縮も中間）:E6600
圧縮重視（速度遅いけど圧縮大）:Q9450以上
で
速度重視（速度速いが圧縮小）:E1200
中間（速度も圧縮も中間）:E6600
圧縮重視（速度遅いけど圧縮大）:Q9450以上
で
YV12への対応を･･･
UtVideoのインストールがIncompleteになるんだが、
OSがXP MCEだとダメなんかな。
OSがXP MCEだとダメなんかな。
YV12の対応俺も欲しい
俺も
YV12は切実に欲しい
TWriteAVIを結構使うが、可逆でYV12だとLagarithくらいしかないんだもん
TWriteAVIを結構使うが、可逆でYV12だとLagarithくらいしかないんだもん
UtVideoやHuffYUVで圧縮すると、メディアプレーヤでは再生できるのに、
AVIutlで読み込むと、上半分が真っ黒で下半分がノイズの画面になってしまいます。
無圧縮だと大丈夫です。何かの設定でしょうか？
AVIutlで読み込むと、上半分が真っ黒で下半分がノイズの画面になってしまいます。
無圧縮だと大丈夫です。何かの設定でしょうか？
おいら（笑）
だってそれはAviUtlの設定のせいだもん
おかしいとか言うやつはよくわからないくせにデフォから設定弄るなよ
おかしいとか言うやつはよくわからないくせにデフォから設定弄るなよ
huffyuv_mt_712でもやってみたけど、問題なし。
アニメじゃ問題でないのかな？
実写ですか？
アニメじゃ問題でないのかな？
実写ですか？
昨日のサッカーの一部をhuffyuv_mt_712、UtVideo3.7でエンコしてみましたが、203さんのような
症状は出ませんでした。
ただ、UtVideo3.7はエンコ終了時AVIutlが落ちましたｗ出来たファイル自体は正常です。
症状は出ませんでした。
ただ、UtVideo3.7はエンコ終了時AVIutlが落ちましたｗ出来たファイル自体は正常です。
連続カキコ失礼します。
>UtVideo3.7はエンコ終了時AVIutlが落ちましたｗ出来たファイル自体は正常です。
もう一度エンコしたら落ちませんでした。
>UtVideo3.7はエンコ終了時AVIutlが落ちましたｗ出来たファイル自体は正常です。
もう一度エンコしたら落ちませんでした。
いろいろレス、サンクス。
その後調べてみると、PremierePro1.5からの出力はダメで、AVIutlから出力した
ファイルはちゃんと読めました。
編集ソフトによって変わることって有りますでしょうか？
その後調べてみると、PremierePro1.5からの出力はダメで、AVIutlから出力した
ファイルはちゃんと読めました。
編集ソフトによって変わることって有りますでしょうか？
で、UtVideoインスコできないのは俺だけかな。
他にXP MCEで使ってる人いない？
他にXP MCEで使ってる人いない？
>212 ｲﾝｽｺしてみた。まだDxCaptureでしか使ってないけど動いてるよ。
コンセプトとずれてるかもしれないけど
RGBAのことも片隅に考えて置いてください
RGBAのことも片隅に考えて置いてください
[UtVideo] バージョン 3.8.0
http://umezawa.dyndns.info/wordpress/?p=325
機能追加
共通: Predict left フレーム内予測方式を追加した。
手元の計測では、今までの実装（Predict median）と比較して、
エンコード速度ほぼ同じ、圧縮率 10% 低下（ファイルサイズが 10% 増える）、
デコード速度 50% 向上（デコード時間が 30% 強短くなる）。
作者の人の人本当にお疲れ様です。
http://umezawa.dyndns.info/wordpress/?p=325
機能追加
共通: Predict left フレーム内予測方式を追加した。
手元の計測では、今までの実装（Predict median）と比較して、
エンコード速度ほぼ同じ、圧縮率 10% 低下（ファイルサイズが 10% 増える）、
デコード速度 50% 向上（デコード時間が 30% 強短くなる）。
作者の人の人本当にお疲れ様です。
> デコード速度 50% 向上
まじっすか
まじっすか
つええなぁ。ゲームの動画なんか撮っててRGBのまま圧縮できる点ですごく重宝してる。
編集中に色が滲んでるの見るの好かないしｗ
編集中に色が滲んでるの見るの好かないしｗ
作者氏乙ですがエンコード速度が下がっても圧縮率が上がるモードも欲しい。
おまいら、どんだけだよｗ
俺はしばらく様子見だな
俺はしばらく様子見だな
いや、人柱がいないとソフトは発展しない
しかし、進歩の速いこの分野でUtv出るまでずっと鉄板だったhuffyuvが恐ろしい
超高解像度動画をリアルタイムキャプチャする用途が広まったのなんてつい最近だからね
圧縮にはハードウェアエンコーダ
速度はhuffyuv（シングル版）で十分だったからUtVideoほどの速度は求められてなかった
圧縮にはハードウェアエンコーダ
速度はhuffyuv（シングル版）で十分だったからUtVideoほどの速度は求められてなかった
Utvideoには期待してるけど、現状ではHuffyuvに入れ替えられないよ・・・
スレチだけどPIC-MJPEGに変わる新・非可逆キャプ用コーデックが欲しい。
>>224
なぜなのか書かないと意味ないよ
なぜなのか書かないと意味ないよ
>>226
Huffyuvと比較して遅いから。
Huffyuvと比較して遅いから。
UtVideoを実験してみた
ttp://vcinema2.blog96.fc2.com/blog-entry-20.html
ttp://vcinema2.blog96.fc2.com/blog-entry-20.html
無償で作ってるんだから頑張れよとしか俺にはいえない
UtVideoで必ずドロップするのであきらめてたんだけど、MxCaptureのプロセスの
優先順位をリアルタイムにしたらドロップしなくなった。
優先順位をリアルタイムにしたらドロップしなくなった。
よりHuffyuv早くない？
訂正
Huffyuvより早くない？
Huffyuvより早くない？
優先度リアルタイムは暴走したときにマシンが完全に固まるから
さすがにやめといたほうがいいぞ…せいぜい「高」ぐらいで。
さすがにやめといたほうがいいぞ…せいぜい「高」ぐらいで。
UtVideo速くなったな。ほぼHuffyuvと互角だな。
中間にしか使わないからもっと速くなったら乗りかえようと思う。
中間にしか使わないからもっと速くなったら乗りかえようと思う。
訂正しても意味不明でﾜﾛﾀ
RGBAきたこれ
速くなったけど、HuffyuvをPredict leftにすると
Huffyuvの方がやっぱ速い・・・
UtVideoがんがれ！！
Huffyuvの方がやっぱ速い・・・
UtVideoがんがれ！！
もう4.0.1ですか・・
いやほんと、頭下がります。
いやほんと、頭下がります。
＞いやね、コード自体は 3.8.0 をリリースした後に千早をプロデュースしつつ
＞2時間弱で書いたんですよ。なんというジェバンニ。
ワロタ
＞2時間弱で書いたんですよ。なんというジェバンニ。
ワロタ
チンコたつかどうかだろ
進化もクソもない
進化もクソもない
映像作品だから当然ではある
人の趣味なんてどうでもいいが
人の趣味なんてどうでもいいが
243 ：名無しさん＠編集中：2008/06/12(木) 05:28:02 ID:xihHYelu
作者がニコ厨じゃなけりゃなあ・・・
んなもんどうでもよし
嫌なら使わなければいいだけ。
他人の趣味にどうこう言う資格なし。
他人の趣味にどうこう言う資格なし。
同じことを繰り返し言ってる(コピペしてる)事から、UtVideoを
潰そうとしてるんだろうけど目的はなんだろうね。
それとも単なるゴミの嫌がらせか？
潰そうとしてるんだろうけど目的はなんだろうね。
それとも単なるゴミの嫌がらせか？
嫉妬だろ。
UtVideoは優れているし、VerUpも早いし、実際問題なく使えるし
作者はゲームしながらコード書けるほど、有能だし。
批判にもならない難癖をつけて、自分の感情を満足させたいだけ。
でもこの世は実績勝負だから。
UtVideoを作った時点で、HD動画でのキャプチャー、編集、エンコードに
ほんとうに世界的な一歩を記したのは間違いない。
huffyuvとためをはる、日本製の可逆圧縮codecだぜ。ほんとうにすごいことなんだけどな。
UtVideoは優れているし、VerUpも早いし、実際問題なく使えるし
作者はゲームしながらコード書けるほど、有能だし。
批判にもならない難癖をつけて、自分の感情を満足させたいだけ。
でもこの世は実績勝負だから。
UtVideoを作った時点で、HD動画でのキャプチャー、編集、エンコードに
ほんとうに世界的な一歩を記したのは間違いない。
huffyuvとためをはる、日本製の可逆圧縮codecだぜ。ほんとうにすごいことなんだけどな。
いや、単純にニコニコ動画がすげー嫌いなだけなんじゃね？ｗ
坊主憎けりゃなんとやらで
坊主憎けりゃなんとやらで
つーか、Huffyuvのマルチスレッドタイプは何故か漏れのところでは安定性が悪い．．．
のでUtVideoを重宝してる。
UtVideoにしてから（マルチスレッド動作が使えるので）、AviUtl-H264エンコ時間が結構速くなった。
これ、以前と比べ可逆デコード処理部分も並列処理になった（結果的に処理全体が並列化）だけだが、
きっちり計ってはいないものの感覚的には15％くらいはエンコ時間短縮になってる雰囲気。
なお、現状（ver3.4）ではコード自体の速さだけならHuffyuvと同等か若干速い程度と思う。
（ver4.0.1は昨日インスコしたばかりでまだ使ってない）
作者に謝々。
のでUtVideoを重宝してる。
UtVideoにしてから（マルチスレッド動作が使えるので）、AviUtl-H264エンコ時間が結構速くなった。
これ、以前と比べ可逆デコード処理部分も並列処理になった（結果的に処理全体が並列化）だけだが、
きっちり計ってはいないものの感覚的には15％くらいはエンコ時間短縮になってる雰囲気。
なお、現状（ver3.4）ではコード自体の速さだけならHuffyuvと同等か若干速い程度と思う。
（ver4.0.1は昨日インスコしたばかりでまだ使ってない）
作者に謝々。
当方、ふぬああと組み合わせてHD映像（D3)の可逆圧縮キャプチャーが主な用途だが、これまで
FastCodec、AlparySoft、Huffyuv．．．といくつかの評判のいい可逆コーデックを試してみて
その中ではやはりHuffyuvが一番だったのでずっと使ってきた。
今回Huffyuvを越えるポテンシャルをもったUtVideoという和製ソフトが出てきたことは嬉しい限りだね。
FastCodec、AlparySoft、Huffyuv．．．といくつかの評判のいい可逆コーデックを試してみて
その中ではやはりHuffyuvが一番だったのでずっと使ってきた。
今回Huffyuvを越えるポテンシャルをもったUtVideoという和製ソフトが出てきたことは嬉しい限りだね。
あとはストライピングが組めない貧乏人の為に圧縮率アップに励んでもらいたい。
huffyuv 1920x1080 *D3 30MB/s
UtVideo 1920x1080 *D3 15MB/s
が理想。だって俺のマザーVIAの糞チップのせいで150MB/sモードしか使えないんだもん。
huffyuv 1920x1080 *D3 30MB/s
UtVideo 1920x1080 *D3 15MB/s
が理想。だって俺のマザーVIAの糞チップのせいで150MB/sモードしか使えないんだもん。
･･･
可逆は限界あるだろ・・・
圧縮率アップ＝エンコードに時間かかるようになるってことだし
無茶言うのが多いな・・・
圧縮率アップ＝エンコードに時間かかるようになるってことだし
無茶言うのが多いな・・・
だったら非可逆モードを追加すればいい。
3フレームGOPにしたら画質犠牲にしないで縮みそう。
RAIDカードぶちこめば？
中の人とかどうでもいいよ
↓のLagarithはいいね圧縮率で他を圧倒している。
ttp://www29.atwiki.jp/lossless/pages/11.html
ttp://www29.atwiki.jp/lossless/pages/11.html
>>249
>UtVideoにしてから（マルチスレッド動作が使えるので）、AviUtl-H264エンコ時間が結構速くなった。
これってどういう事？中間にUtVideo使ってるって事？
ちなみにウチではまだHuffyuvがメインなんだが、クアッドで4コア全部使い果たしてくれるぞ。
HuffyuvはMT版じゃなくて、Huffyuv2.2.0ね。
>UtVideoにしてから（マルチスレッド動作が使えるので）、AviUtl-H264エンコ時間が結構速くなった。
これってどういう事？中間にUtVideo使ってるって事？
ちなみにウチではまだHuffyuvがメインなんだが、クアッドで4コア全部使い果たしてくれるぞ。
HuffyuvはMT版じゃなくて、Huffyuv2.2.0ね。
少し前に張ってあったリンクにも出てたけど
UtVideoからのエンコだとデコード性能の分だけ速くなるよ
フィルター含めてエンコードの設定が軽ければ軽いほど差が出てくるね
入り口のボトルネックが広くなるわけだからね
UtVideoからのエンコだとデコード性能の分だけ速くなるよ
フィルター含めてエンコードの設定が軽ければ軽いほど差が出てくるね
入り口のボトルネックが広くなるわけだからね
軽いだけならHuffyuvのleftも十分軽いけどな
要は用途に合わせて使い分ければいいんだけどね
要は用途に合わせて使い分ければいいんだけどね
http://ja.wikipedia.org/w/index.php?title=UtVideo&action=edit&redlink=1
http://ja.wikipedia.org/wiki/Huffyuv
http://ja.wikipedia.org/wiki/Huffyuv
ハーフワイユーブイって読むんだ
>>261
もちろん中間使い。
うちはデュアルコアだが、中間可逆がシングルスレッドモード（Huffyuv2.2.0)だと
AviutlとX264を2スレッド指定にしていても2つのコアに目に見える負荷差が出て
トータルCPU負荷が50％～65％にしかならない。差は中間可逆のデコード処理が
相変わらずシングルだからだと思う。
中間可逆もマルチスレッド動作のもの（UtVideoなど)にするとそういう現象がなくなり、
両コアが同レベルで稼動してトータルCPU負荷も70％～85%程度になる。
これうちだけの現象？
もちろん中間使い。
うちはデュアルコアだが、中間可逆がシングルスレッドモード（Huffyuv2.2.0)だと
AviutlとX264を2スレッド指定にしていても2つのコアに目に見える負荷差が出て
トータルCPU負荷が50％～65％にしかならない。差は中間可逆のデコード処理が
相変わらずシングルだからだと思う。
中間可逆もマルチスレッド動作のもの（UtVideoなど)にするとそういう現象がなくなり、
両コアが同レベルで稼動してトータルCPU負荷も70％～85%程度になる。
これうちだけの現象？
>>262,266
CPU Q6600 のウチではこんな感じ。x264でエンコード中のCPU負荷は上が90%強、下が80%半ばくらい。
数回試したが、ほぼ同じ結果。
"E:\asatte_huffyuv.avi"の出力設定
HuffYUV v2.2.0
Predict left (fastest)
フィールド閾値 480
▼"E:\asatte_huffyuv_test.avs"の記述内容
AviSource("E:\asatte_huffyuv.avi").ConvertToYV12(interlaced=False)
E:\>x264s --crf 18 --aq-mode 0 --no-psnr --no-ssim --threads auto --thread-input --progress --output "D:\asatte_eizo02.mp4" "E:\asatte_huffyuv_test.avs"
avis [info]: 704x480 @ 23.98 fps (2146 frames)
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 0 (scale 24000)
x264 [info]: slice I:33 Avg QP:15.36 size: 453400:00:00
x264 [info]: slice P:2113 Avg QP:18.34 size: 6583
x264 [info]: mb I I16..4: 30.9% 0.0% 69.1%
x264 [info]: mb P I16..4: 4.1% 0.0% 3.9% P16..4: 31.2% 15.1% 5.1% 0.0% 0.0% skip:40.6%
x264 [info]: kb/s:1377.1
encoded 2146 frames, 103.97 fps, 1377.20 kb/s
CPU Q6600 のウチではこんな感じ。x264でエンコード中のCPU負荷は上が90%強、下が80%半ばくらい。
数回試したが、ほぼ同じ結果。
"E:\asatte_huffyuv.avi"の出力設定
HuffYUV v2.2.0
Predict left (fastest)
フィールド閾値 480
▼"E:\asatte_huffyuv_test.avs"の記述内容
AviSource("E:\asatte_huffyuv.avi").ConvertToYV12(interlaced=False)
E:\>x264s --crf 18 --aq-mode 0 --no-psnr --no-ssim --threads auto --thread-input --progress --output "D:\asatte_eizo02.mp4" "E:\asatte_huffyuv_test.avs"
avis [info]: 704x480 @ 23.98 fps (2146 frames)
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 0 (scale 24000)
x264 [info]: slice I:33 Avg QP:15.36 size: 453400:00:00
x264 [info]: slice P:2113 Avg QP:18.34 size: 6583
x264 [info]: mb I I16..4: 30.9% 0.0% 69.1%
x264 [info]: mb P I16..4: 4.1% 0.0% 3.9% P16..4: 31.2% 15.1% 5.1% 0.0% 0.0% skip:40.6%
x264 [info]: kb/s:1377.1
encoded 2146 frames, 103.97 fps, 1377.20 kb/s
"E:\asatte_utvideo.aviの出力設定"
UtVideo 4.0.1 YUV422
フレーム分割数 4
デコード優先(Predict left)
▼"E:\asatte_utvideo_test.avs"の記述内容
AviSource("E:\asatte_utvideo.avi").ConvertToYV12(interlaced=False)
E:\>x264s --crf 18 --aq-mode 0 --no-psnr --no-ssim --threads auto --thread-input --progress --output "D:\asatte_eizo03.mp4" "E:\asatte_utvideo_test.avs"
avis [info]: 704x480 @ 23.98 fps (2146 frames)
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 0 (scale 24000)
x264 [info]: slice I:33 Avg QP:15.36 size: 45340:00:00
x264 [info]: slice P:2113 Avg QP:18.34 size: 6583
x264 [info]: mb I I16..4: 30.9% 0.0% 69.1%
x264 [info]: mb P I16..4: 4.1% 0.0% 3.9% P16..4: 31.2% 15.1% 5.1% 0.0% 0.0% skip:40.6%
x264 [info]: kb/s:1377.1
encoded 2146 frames, 96.51 fps, 1377.20 kb/s
UtVideo 4.0.1 YUV422
フレーム分割数 4
デコード優先(Predict left)
▼"E:\asatte_utvideo_test.avs"の記述内容
AviSource("E:\asatte_utvideo.avi").ConvertToYV12(interlaced=False)
E:\>x264s --crf 18 --aq-mode 0 --no-psnr --no-ssim --threads auto --thread-input --progress --output "D:\asatte_eizo03.mp4" "E:\asatte_utvideo_test.avs"
avis [info]: 704x480 @ 23.98 fps (2146 frames)
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 SSSE3 Cache64
mp4 [info]: initial delay 0 (scale 24000)
x264 [info]: slice I:33 Avg QP:15.36 size: 45340:00:00
x264 [info]: slice P:2113 Avg QP:18.34 size: 6583
x264 [info]: mb I I16..4: 30.9% 0.0% 69.1%
x264 [info]: mb P I16..4: 4.1% 0.0% 3.9% P16..4: 31.2% 15.1% 5.1% 0.0% 0.0% skip:40.6%
x264 [info]: kb/s:1377.1
encoded 2146 frames, 96.51 fps, 1377.20 kb/s
すまん。x264sってのは、seraphy氏のバイナリね。
"x264 core:59 r859 ce13bb6"
"x264 core:59 r859 ce13bb6"
Huffyuv恐ろしい子･･･
でも圧縮率とのバランスやキャプチャ用途で考えればUtVideoでよさそうだね
でも圧縮率とのバランスやキャプチャ用途で考えればUtVideoでよさそうだね
もうそろそろHuffyuv抜けそうですね作者さん頑張ってください
272 ：名無しさん＠編集中：2008/06/13(金) 01:50:19 ID:ntK7cWe1
ニコ厨は後々必ずボロを出す
今の所、それぞれの使用環境によるけど無駄を省いていくと、
中間ファイル用→Huffyuv2.2.0
キャプチャ用→UtVideo
ってところかな。
UtVideoのデコード効率がよくなりHuffyuvを抜くのも間近か！？
中間ファイル用→Huffyuv2.2.0
キャプチャ用→UtVideo
ってところかな。
UtVideoのデコード効率がよくなりHuffyuvを抜くのも間近か！？
俺は逆かな
キャプチャ用がHuffyuvで中間がUtVideo
NTSCやD3みたいにインターレースだとHuffyuvのほうがまだ強い
あとはエンコード、デコード効率が良くなればUtVideoオンリーでいけそう
キャプチャ用がHuffyuvで中間がUtVideo
NTSCやD3みたいにインターレースだとHuffyuvのほうがまだ強い
あとはエンコード、デコード効率が良くなればUtVideoオンリーでいけそう
荒らしに反応しているというよりHuffyuv2.2.0を使ってる人間をバカにしてるように見えるな。
誰もRGBなんて使ってないだろうに。
誰もRGBなんて使ってないだろうに。
>>274
UtVideoはhuffyuvにくらべてD3でもデコードは現状でも十分速いと思うよ
エンコードはあまり違わないけどそれでも多少は速い
サイズに関しては似たり寄ったりなのでコンセプト的に限界なんだろうな
UtVideoはhuffyuvにくらべてD3でもデコードは現状でも十分速いと思うよ
エンコードはあまり違わないけどそれでも多少は速い
サイズに関しては似たり寄ったりなのでコンセプト的に限界なんだろうな
うちの環境だとHuffyuvがPremiere Elementsとすごく相性が悪いんでUtVideoはありがたい
つか優先すべきは圧縮率でしょう。
キャプ用につかっても中間に使っても本数多かったり長時間だったりすると圧縮率は高いほどいい。
HDDを湯水のように買える金持ちは知らん。
キャプ用につかっても中間に使っても本数多かったり長時間だったりすると圧縮率は高いほどいい。
HDDを湯水のように買える金持ちは知らん。
>>279
つ非可逆圧縮
つ非可逆圧縮
お前らよく考えろ。
作者がニコ厨云々言ってるやつは、それ以外はUtVideo完璧だと言ってるのと同じだぜ？
作者がニコ厨云々言ってるやつは、それ以外はUtVideo完璧だと言ってるのと同じだぜ？
つられすぎ
>>280
PIC-MJPEG以外のフリーで画質がいいキャプ用非可逆コーデックって何がありますか？
PIC-MJPEG以外のフリーで画質がいいキャプ用非可逆コーデックって何がありますか？
せっかく無視してきたのに
>>278
俺も全く同じだ
俺も全く同じだ
adibe製はRGBじゃないとうまくいかないとか聞いたことあるけどそれのせいかもしれない
288 ：名無しさん＠編集中：2008/06/14(土) 01:11:45 ID:8GnGe2Dt
UtVideo唯一の欠点
~~~~~~~~~~~~~
作者がニコ厨
唯一の欠点
~~~~~~~~~~~~~
~~~~~~~~~~~~~
作者がニコ厨
唯一の欠点
~~~~~~~~~~~~~
もうそっとしといてやれよ
Uさんの開発力に脱帽ｗｗｗ
これからも応援しようZe！
これからも応援しようZe！
読み方は欝ビデオでいいのかな？
>>291
欝に成りたくないでござる(ry
欝に成りたくないでござる(ry
このスレはUtVideoで盛り上がってるけど
俺が試した中ではhuffyuvやLagarith、ましてやUtVideoなんかより
YUY2 Lossless Codec (YLC) version 0.25
が一番優秀なんだけど
俺が試した中ではhuffyuvやLagarith、ましてやUtVideoなんかより
YUY2 Lossless Codec (YLC) version 0.25
が一番優秀なんだけど
中間コーデックとして？
Q. 何が優秀なのか書け。
A. なんとなく。
A. なんとなく。
サイズは小さくなるがデコードが遅い感じ
このスレのレベルが低いのはわかったよ
もうこない
もうこない
299 ：名無しさん＠編集中：2008/06/15(日) 18:23:00 ID:43CD7pFt
よ ほ う 診 医 精 一 忠 は あ ま
さ う け 察 .者 神 度 告 て き さ
そ が .た を の 科 す た れ し
う の る な く
だ が ：
､＿__ ＿__ ：
(＿＿＿＿＿,／::::::::::::｀ヽ、
/::rー‐-ｰ-､:::l＿＿, , -─
_|:lr_‐､￣-=､l:::| /／
/)Y ´ﾟ｀ri ､'ﾟﾞ' |/,〉 /´
|｀ |l /ヽ _,ノｌ |ﾉ|
ヽ_| '-=ニ=-l !/
/|ﾊ -‐ /＼
＿,. -ｰ'`´ l l ＼ /'/! l`ー-､＿
さ う け 察 .者 神 度 告 て き さ
そ が .た を の 科 す た れ し
う の る な く
だ が ：
､＿__ ＿__ ：
(＿＿＿＿＿,／::::::::::::｀ヽ、
/::rー‐-ｰ-､:::l＿＿, , -─
_|:lr_‐､￣-=､l:::| /／
/)Y ´ﾟ｀ri ､'ﾟﾞ' |/,〉 /´
|｀ |l /ヽ _,ノｌ |ﾉ|
ヽ_| '-=ニ=-l !/
/|ﾊ -‐ /＼
＿,. -ｰ'`´ l l ＼ /'/! l`ー-､＿
実際今まで話題になってないし優秀だというデータも提示しないで逆ギレだもんな。
でもAviUtl本家ので今まで話題になってないってのは不自然な感じだけど
使ったことある人いるのかな。
でもAviUtl本家ので今まで話題になってないってのは不自然な感じだけど
使ったことある人いるのかな。
＞でもAviUtl本家ので今まで話題になってないってのは不自然な感じだけど
作成されのは大分前っぽいけど、公開されたのがかなり遅かったからじゃない？
作成されのは大分前っぽいけど、公開されたのがかなり遅かったからじゃない？
自演なの？
釣りなの？
ぼやけるわけないじゃんｗ
釣りなの？
ぼやけるわけないじゃんｗ
readme読めよ
YUY2形式の可逆圧縮codecです。
動画編集時の中間ファイル保存等のお役に立てば幸いです。
SSE(MMX2)命令を使用していますのでSSEの使えるCPU専用です。
RGB形式での入出力にも対応していますがRGB<->YUY2変換が
入る為に画質が劣化したり若干処理速度が低下したりします。
＞劣化
ぼやけるわけないじゃんｗ
動画編集時の中間ファイル保存等のお役に立てば幸いです。
SSE(MMX2)命令を使用していますのでSSEの使えるCPU専用です。
RGB形式での入出力にも対応していますがRGB<->YUY2変換が
入る為に画質が劣化したり若干処理速度が低下したりします。
＞劣化
ぼやけるわけないじゃんｗ
劣化するからぼやけるんじゃね
RGBからYUY2に変換される時に何が起こってるか知らないんじゃね。
一般的に用いられる映像じゃ仮にそれがRGB→YUY2変換されても違いなんか気づけないし。
一般的に用いられる映像じゃ仮にそれがRGB→YUY2変換されても違いなんか気づけないし。
310 ：名無しさん＠編集中：2008/06/15(日) 23:23:50 ID:43CD7pFt
YUY2とか色減るし ロスレスじゃないし
RGBから変換する奴ってそんなにいるんだ。
自分の場合はAviSynthから中間ファイルでHuffyuvのYUY2使ってたよ。
自分の場合はAviSynthから中間ファイルでHuffyuvのYUY2使ってたよ。
YUY2のみで済む人はリップ厨が多い事実
すべてではないけどさ
すべてではないけどさ
色空間にまでこだわってるなら、可逆圧縮にこだわる必要あるんか？
aviutl使わない俺的にはRGBの必要性を感じない
YUY2やYV12の方が重要だ
色空間についてじゃなくて単にDg8fNU4Mの「ぼやけるわけが無い」発言に対してのレスだろ？
ありえないと断言して馬鹿にするようなこと言ってたからだ。
ありえないと断言して馬鹿にするようなこと言ってたからだ。
結局YLCは優秀なのか？
huffyu 20GがYLC 13Gとか縮むけど
huffyu 20GがYLC 13Gとか縮むけど
＞「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
＞「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
＞
＞大事なことなので2度言ったよ！
だそうです。
＞「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
＞
＞大事なことなので2度言ったよ！
だそうです。
要するに一般ユーザーはUtVideoよりYLCのほうが使えるってことだねｗ
正式名称は判明したけど愛称は欝ビデオということですね。
俺もゲームをキャプチャしたり編集するからRGBが無いと困るなあ
今までまともに使えるのはHuffyuvだけだったからUtVideoはありがたいね
今までまともに使えるのはHuffyuvだけだったからUtVideoはありがたいね
Premiere Elementsが偏食で困る。すげーわがまま。UtVideoは本当にありがたい
高圧縮タイプのUtVideoまだぁ？
MSU使え
UtVideo唯一の欠点
~~~~~~~~~~~~~
作者がニコ厨
唯一の欠点
~~~~~~~~~~~~~
~~~~~~~~~~~~~
作者がニコ厨
唯一の欠点
~~~~~~~~~~~~~
そこまでして煽りたいかね
あぼんしやすいから問題ない。つーかわさるな。
もともとニコ厨がニコ厨のために作ってるコーデックだからねぇ…
UtVideoに個人的に欲しいのはやっぱり圧縮のプロファイルだな。
・圧縮率優先（負荷とかマジ考えずに圧縮率追求したのが欲しいっす）
・エンコ速度優先
・デコード速度優先
・バランス
こんな感じであれば嬉しい。
・圧縮率優先（負荷とかマジ考えずに圧縮率追求したのが欲しいっす）
・エンコ速度優先
・デコード速度優先
・バランス
こんな感じであれば嬉しい。
UtVideo
唯
一
の
欠
点
作
者
が
ニ
コ
厨
|唯
|一
|の
|欠
|点
唯
一
の
欠
点
作
者
が
ニ
コ
厨
|唯
|一
|の
|欠
|点
>画質を犠牲にした非可逆モード
w
w
>>334
ま、確かにDivXでも使っとけって思うわな。
ま、確かにDivXでも使っとけって思うわな。
非可逆ならHuffyuvでいいんじゃね？
DivXは暗部が汚いので嫌
h264くらいの画質があれば
h264くらいの画質があれば
333はY8以下の色空間での可逆を望んでいるんだよ！
予想通りのスーパー乞食タイムだな
作者に伝えたい、
ここで書かれているような要望なんて無視していいから、とりあえず
本人が満足するぐらいまで、UtVideoを完成してほしい。
ここで書かれているような要望なんて無視していいから、とりあえず
本人が満足するぐらいまで、UtVideoを完成してほしい。
作者も馬鹿じゃないんだから>>340みたいなのも
余計なお世話だと思わんでもない
余計なお世話だと思わんでもない
確かにごもっとも。俺死ぬわ
ユーザーに出来ることは不具合報告とかデータ収集ぐらいしか
ここまで公にしたんだからUtVideoはもう作者一人のものではなくなった。
皆の要望を切実に聞くべきだろう。
皆の要望を切実に聞くべきだろう。
と、乞食が申しております。
と、作者が申しております。
ttp://wiki.nicomas.net/index.php?%E3%82%B3%E3%83%BC%E3%83%87%E3%83%83%E3%82%AF#n17fc52a
アニオタ、エンコオタは無視ですが、アイマス厨の要望には真摯に取り組んでいるようです
まさに余計なお世話ってな感じですね
アニオタ、エンコオタは無視ですが、アイマス厨の要望には真摯に取り組んでいるようです
まさに余計なお世話ってな感じですね
作者の趣味がなんだろうと使用者にとっては関係無い。自分の目的に沿っていれば感謝しながら使うだけ。
しかし、こーゆーマンセーは見てて気に食わない。
>シングルスレッドの場合でも、Huffyuv (Predict median) よりデコードが速い。もちろんマルチスレッドなら圧倒的に速い。
>マルチスレッドの場合は Huffyuv (Predict median) はもちろん、同じスレッド数での Huffyuv_mt (Predict median) よりエンコードも速い。
正直、デコードについては、タスクマネージャーを見てる程度では動画によって振幅が大きいのでわからんが、
エンコード速度は自分の使用環境では確実にHuffyuv2.2.0のほうが速いよ。
しかし、こーゆーマンセーは見てて気に食わない。
>シングルスレッドの場合でも、Huffyuv (Predict median) よりデコードが速い。もちろんマルチスレッドなら圧倒的に速い。
>マルチスレッドの場合は Huffyuv (Predict median) はもちろん、同じスレッド数での Huffyuv_mt (Predict median) よりエンコードも速い。
正直、デコードについては、タスクマネージャーを見てる程度では動画によって振幅が大きいのでわからんが、
エンコード速度は自分の使用環境では確実にHuffyuv2.2.0のほうが速いよ。
（速度に関しては Core 2 の場合）って注釈入ってるんだし
ドロップしない範囲ならＵｔ使うほうが圧縮率いいわけで
使い分けたらいいんじゃないかな。
で、YLCの使用感も話題も全くでないのはなんで？
ドロップしない範囲ならＵｔ使うほうが圧縮率いいわけで
使い分けたらいいんじゃないかな。
で、YLCの使用感も話題も全くでないのはなんで？
相手が日本語が通じる分ありがたいと思った方が良い
>>348
RGBがまともに扱えない2.2.0は、彼らにとっては評価の対象外です
RGBがまともに扱えない2.2.0は、彼らにとっては評価の対象外です
>>348
環境さらさないと屁の突っ張りにもならん
環境さらさないと屁の突っ張りにもならん
映像ソースにも差が出るんじゃ
>>351
なるほど。そういう事か。
>>352
上のほうでちょっと投稿してるんだがな。時間作ってもうちょいまともなテストするよ。
ちなみにテスト環境、方法晒すなら、ある程度詳しく書く必要があると思うが、>>347もきちんと晒してないよね。
なるほど。そういう事か。
>>352
上のほうでちょっと投稿してるんだがな。時間作ってもうちょいまともなテストするよ。
ちなみにテスト環境、方法晒すなら、ある程度詳しく書く必要があると思うが、>>347もきちんと晒してないよね。
>>354
今やっているからちょっと待ってろw
今やっているからちょっと待ってろw
RGBでやってくれるのは真面目にありがたいわ。
俺がやってんのはアマレココつかったネトゲのキャプチャーだがね。
Huffyuvでやると警告系の赤い字とか隣に色が移って編集中すごく気持ち悪いんだ。
どうせ最終的には縮小かけたり非可逆の圧縮することが多いから気持ちの問題といえば気持ちの問題だけどなｗ
俺がやってんのはアマレココつかったネトゲのキャプチャーだがね。
Huffyuvでやると警告系の赤い字とか隣に色が移って編集中すごく気持ち悪いんだ。
どうせ最終的には縮小かけたり非可逆の圧縮することが多いから気持ちの問題といえば気持ちの問題だけどなｗ
とりあえずYUY2のエンコード速度
huffyuv_mt 4thread best ：1m32s 5,893,188KB
huffyuv_mt 4thread fastest：1m34s 6,149,104KB
Ut Video 4thread median：1m26s 5,490,107KB
Ut Video 4thread left：1m29s 5,831,831KB
エンコ素材：シリーズ世界遺産の一部（約2分間）をモンスターXでD3 huffyuv_mt best で録画
エンコ方法：素材をVirtualDubにて開きYUY2展開＞YUY2出力 音声無しで各設定で出力
環境：WinXP SP3 Phenom9600無印 メモリー：3GB
素材HDD：WD640AAKS
保存HDD：WD640AAKS
とりあえずこの条件ではUtVideoの方が速いね
huffyuv_mt 4thread best ：1m32s 5,893,188KB
huffyuv_mt 4thread fastest：1m34s 6,149,104KB
Ut Video 4thread median：1m26s 5,490,107KB
Ut Video 4thread left：1m29s 5,831,831KB
エンコ素材：シリーズ世界遺産の一部（約2分間）をモンスターXでD3 huffyuv_mt best で録画
エンコ方法：素材をVirtualDubにて開きYUY2展開＞YUY2出力 音声無しで各設定で出力
環境：WinXP SP3 Phenom9600無印 メモリー：3GB
素材HDD：WD640AAKS
保存HDD：WD640AAKS
とりあえずこの条件ではUtVideoの方が速いね
RGB24でのエンコード速度
huffyuv_mt 4thread best ：2m38s 9,947,989KB
huffyuv_mt 4thread fastest：2m55s 12,581,658KB
Ut Video(ULRG) 4thread median：3m55s 8,775,365KB
Ut Video(ULRG) 4thread left：3m57s 8,927,684KB
エンコ素材：シリーズ世界遺産の一部（約2分間）をモンスターXでD3 huffyuv_mt best で録画
エンコ方法：素材をVirtualDubにて開きRGB24展開＞RGB24出力 音声無しで各設定で出力
この条件ではHuffyuv_mtの方が断然速い
huffyuv_mt 4thread best ：2m38s 9,947,989KB
huffyuv_mt 4thread fastest：2m55s 12,581,658KB
Ut Video(ULRG) 4thread median：3m55s 8,775,365KB
Ut Video(ULRG) 4thread left：3m57s 8,927,684KB
エンコ素材：シリーズ世界遺産の一部（約2分間）をモンスターXでD3 huffyuv_mt best で録画
エンコ方法：素材をVirtualDubにて開きRGB24展開＞RGB24出力 音声無しで各設定で出力
この条件ではHuffyuv_mtの方が断然速い
Phenom(笑)
huffuv_mtは安定してないね。こっちでも。
まともに再生されないファイルができたりする。
まともに再生されないファイルができたりする。
レンダリング～～～90%くらいで何の前触れもなくアプリごと落ちる
Premiere Elementsと本当に相性悪いな・・・huffuvは
Premiere Elementsと本当に相性悪いな・・・huffuvは
yが抜けてるけど誰も修正しないｗ
Normalだと不具合はないかな。こっちでは。
Normalだと不具合はないかな。こっちでは。
他を調べてもRGBはHuffyuvが得意で、YUY2はUtVideoが得意なようだな
TS抜きしたアニメのOP(解像度：1440x1080 1:30 割と動く)を24p化しfastcodec(YUV)に
エンコードした物をVirtualDub1.81に読ませ、FastRecompressにチェック
エンコードが終わるたびにVirtualDubは再起動。
同じコーデックを連続でテストせず、ローテーションを3回まわした。
CPU：E6850定格動作 ソース、保存先それぞれ別HDDを使用。
HuffYUV v2.2.0
設定 "Predict left"
CPU負荷 Encode 50%前後
1回目 2:06
2回目 2:05
3回目 2:05
ファイルサイズ 2032478364byte
HuffYUV MT v1.1.1 Multi-Threding Patch v1.0
設定 "Predict left" マルチスレッディングモードにチェック スレッド数2
CPU負荷 Encode 50%強
1回目 1:59
2回目 1:59
3回目 1:59
ファイルサイズ 2032404440byte
YLC
CPU負荷 Encode 50%前後
1回目 2:17
2回目 2:17
3回目 2:17
ファイルサイズ 1920197508byte
エンコードした物をVirtualDub1.81に読ませ、FastRecompressにチェック
エンコードが終わるたびにVirtualDubは再起動。
同じコーデックを連続でテストせず、ローテーションを3回まわした。
CPU：E6850定格動作 ソース、保存先それぞれ別HDDを使用。
HuffYUV v2.2.0
設定 "Predict left"
CPU負荷 Encode 50%前後
1回目 2:06
2回目 2:05
3回目 2:05
ファイルサイズ 2032478364byte
HuffYUV MT v1.1.1 Multi-Threding Patch v1.0
設定 "Predict left" マルチスレッディングモードにチェック スレッド数2
CPU負荷 Encode 50%強
1回目 1:59
2回目 1:59
3回目 1:59
ファイルサイズ 2032404440byte
YLC
CPU負荷 Encode 50%前後
1回目 2:17
2回目 2:17
3回目 2:17
ファイルサイズ 1920197508byte
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
CPU負荷 Encode 55%前後
1回目 2:05
2回目 2:04
3回目 2:04
ファイルサイズ 1583877276byte
結果は見ての通りだが、"HuffYUV MT版"が一番速い。が以前試した時は確かにHuffyuv2.2.0が一番速かったはず、
と思い、AviSynthから読み込ませたら以下の結果に。
設定 デコード速度優先(Predict left) フレーム分割数2
CPU負荷 Encode 55%前後
1回目 2:05
2回目 2:04
3回目 2:04
ファイルサイズ 1583877276byte
結果は見ての通りだが、"HuffYUV MT版"が一番速い。が以前試した時は確かにHuffyuv2.2.0が一番速かったはず、
と思い、AviSynthから読み込ませたら以下の結果に。
HuffYUV v2.2.0
1回目 2:00 CPU負荷 50%強
2回目 2:19 CPU負荷 50%弱
3回目 2:19 CPU負荷 50%弱
4回目 2:19 CPU負荷 50%弱
HuffYUV MT v1.1.1 Multi-Threding Patch v1.0
1回目 2:01 CPU負荷 50%強
2回目 2:25 CPU負荷 50%弱
3回目 2:26 CPU負荷 50%弱
4回目 2:19 CPU負荷 50%強 マルチスレッドOFF
YLC
1回目 2:20 CPU負荷 50%前後
2回目 2:20 CPU負荷 50%前後
3回目 2:20 CPU負荷 50%前後
4回目 2:20 CPU負荷 50%前後
UtVideo-4.0.1 YUV422
1回目 2:29 CPU負荷 50%弱
2回目 2:30 CPU負荷 50%弱
3回目 2:30 CPU負荷 50%弱
4回目 2:20 CPU負荷 50%強 スレッド数1
1回目 2:00 CPU負荷 50%強
2回目 2:19 CPU負荷 50%弱
3回目 2:19 CPU負荷 50%弱
4回目 2:19 CPU負荷 50%弱
HuffYUV MT v1.1.1 Multi-Threding Patch v1.0
1回目 2:01 CPU負荷 50%強
2回目 2:25 CPU負荷 50%弱
3回目 2:26 CPU負荷 50%弱
4回目 2:19 CPU負荷 50%強 マルチスレッドOFF
YLC
1回目 2:20 CPU負荷 50%前後
2回目 2:20 CPU負荷 50%前後
3回目 2:20 CPU負荷 50%前後
4回目 2:20 CPU負荷 50%前後
UtVideo-4.0.1 YUV422
1回目 2:29 CPU負荷 50%弱
2回目 2:30 CPU負荷 50%弱
3回目 2:30 CPU負荷 50%弱
4回目 2:20 CPU負荷 50%強 スレッド数1
両Huffyuvの1回目については何故かCPU負荷が上がりエンコード速度も速くなった。
その後再現できないので、なんとも言えない。他のコーデックにも起こりうると思う。
さらにAviSynthから読ませると全体的にCPU負荷が下がりマルチスレッドで働いて無いのでは？
と感じたので、最後にマルチスレッドをOFFにしたら速度はあがった。
Q6600でもテストしようと思ってたけどHuffyuv2.2.0が速い、という意見の食い違いの原因がわかったからもういいや。
デコードに関しては、>>267-268でいいんじゃね？って事で。
この検証はあくまでも自分の環境ではこうなる、というサンプルにしかすぎない事に注意。
その後再現できないので、なんとも言えない。他のコーデックにも起こりうると思う。
さらにAviSynthから読ませると全体的にCPU負荷が下がりマルチスレッドで働いて無いのでは？
と感じたので、最後にマルチスレッドをOFFにしたら速度はあがった。
Q6600でもテストしようと思ってたけどHuffyuv2.2.0が速い、という意見の食い違いの原因がわかったからもういいや。
デコードに関しては、>>267-268でいいんじゃね？って事で。
この検証はあくまでも自分の環境ではこうなる、というサンプルにしかすぎない事に注意。
結局、自分の使い方では、中間ファイル→avs→x264.exeなので、
長いこと使ってて実績があるHuffyuv2.2.0を選んでる感じだなぁ。
YV12版Huffyuvを使ってる人の使用感聞きたいわ。
長いこと使ってて実績があるHuffyuv2.2.0を選んでる感じだなぁ。
YV12版Huffyuvを使ってる人の使用感聞きたいわ。
シングルスレッドでHuffyuv2.2.0が一番早かったって結論？
CPUの負担が50％前後で頭打ちになっているということは、
シングルスレッド性能は何となくテストできているけど
マルチスレッド性能は全く引き出せていないわけだからな・・・
HDDとかアプリの入出力あたりでオーバーヘッドが出ているだけだろうけど
シングルスレッド性能は何となくテストできているけど
マルチスレッド性能は全く引き出せていないわけだからな・・・
HDDとかアプリの入出力あたりでオーバーヘッドが出ているだけだろうけど
>>371-372
混乱させて悪い。>>368-369のAviSynthの話は忘れてくれ。これはたぶんアプリの相性の問題。
で、マルチスレッドで動いてないように勘違いされているので>>366と同じ条件で以下の追試をした。
時間がかかるので、それぞれ1回づつ。非可逆も使ってるのはマルチスレッディングのテストという事で。
Microsoft Windows Media Video 9
c 2003 Microsoft Corporation. All rights reserved
設定：デフォルト設定から、パフォーマンスのスライダーを一番左に変更
かかった時間：2:53
CPU負荷：60-70%
Microsoft Windows Media Video 9
c 2003 Microsoft Corporation. All rights reserved
設定：デフォルト設定から、パフォーマンスのスライダーを一番右に変更
かかった時間：14:50
CPU負荷：80-90%
x264 - H.264/MPEG-4 AVC codec
Core 52 svn-573, build Oct 1 2006 10:11:38
設定：デフォルト設定から、スレッド数を2に変更
かかった時間：5:48
60-80%
Lagarith lossless codec Version 1.3.15 dev
設定：Mode YUY2：Use Multithreading
かかった時間：2:47
65%前後
混乱させて悪い。>>368-369のAviSynthの話は忘れてくれ。これはたぶんアプリの相性の問題。
で、マルチスレッドで動いてないように勘違いされているので>>366と同じ条件で以下の追試をした。
時間がかかるので、それぞれ1回づつ。非可逆も使ってるのはマルチスレッディングのテストという事で。
Microsoft Windows Media Video 9
c 2003 Microsoft Corporation. All rights reserved
設定：デフォルト設定から、パフォーマンスのスライダーを一番左に変更
かかった時間：2:53
CPU負荷：60-70%
Microsoft Windows Media Video 9
c 2003 Microsoft Corporation. All rights reserved
設定：デフォルト設定から、パフォーマンスのスライダーを一番右に変更
かかった時間：14:50
CPU負荷：80-90%
x264 - H.264/MPEG-4 AVC codec
Core 52 svn-573, build Oct 1 2006 10:11:38
設定：デフォルト設定から、スレッド数を2に変更
かかった時間：5:48
60-80%
Lagarith lossless codec Version 1.3.15 dev
設定：Mode YUY2：Use Multithreading
かかった時間：2:47
65%前後
番外編 出力先をRamdisk(Gavotte)にした。書き込み速度のボトルネックは無いはず。
Ut Video Codec Suite, Version 4.0.1 Copyright (C) 2008 UMEZAWA Takeshi
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
かかった時間 2:05
CPU負荷 Encode 55%前後
出力先がHDDの場合と結果は変わらず。
タスクマネージャーで見ると、両方のCoreを使っている事がわかる。
Ut Video Codec Suite, Version 4.0.1 Copyright (C) 2008 UMEZAWA Takeshi
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
かかった時間 2:05
CPU負荷 Encode 55%前後
出力先がHDDの場合と結果は変わらず。
タスクマネージャーで見ると、両方のCoreを使っている事がわかる。
ソースを格納しているHDD
HD Tune: ST3320620NS Benchmark
Transfer Rate Minimum : 36.0 MB/sec
Transfer Rate Maximum : 79.7 MB/sec
Transfer Rate Average : 65.5 MB/sec
Access Time : 13.1 ms
Burst Rate : 111.3 MB/sec
CPU Usage : 1.6%
出力先のHDD
HD Tune: WDC WD5000AAKS-00TMA Benchmark
Transfer Rate Minimum : 40.2 MB/sec
Transfer Rate Maximum : 85.8 MB/sec
Transfer Rate Average : 68.5 MB/sec
Access Time : 13.2 ms
Burst Rate : 118.8 MB/sec
CPU Usage : 1.8%
OS：WindowsXP Pro SP3
どの場合もエンコード中の物理メモリは大体500MB以上の空きがある。
推論だけ述べるとHuffyuvMT版やUtVideoはマルチスレッドで動いているがCPUを効率的に使ってくれない、という事だと思う。
HD Tune: ST3320620NS Benchmark
Transfer Rate Minimum : 36.0 MB/sec
Transfer Rate Maximum : 79.7 MB/sec
Transfer Rate Average : 65.5 MB/sec
Access Time : 13.1 ms
Burst Rate : 111.3 MB/sec
CPU Usage : 1.6%
出力先のHDD
HD Tune: WDC WD5000AAKS-00TMA Benchmark
Transfer Rate Minimum : 40.2 MB/sec
Transfer Rate Maximum : 85.8 MB/sec
Transfer Rate Average : 68.5 MB/sec
Access Time : 13.2 ms
Burst Rate : 118.8 MB/sec
CPU Usage : 1.8%
OS：WindowsXP Pro SP3
どの場合もエンコード中の物理メモリは大体500MB以上の空きがある。
推論だけ述べるとHuffyuvMT版やUtVideoはマルチスレッドで動いているがCPUを効率的に使ってくれない、という事だと思う。
>>374の番外編が片手落ちな気がしたので、もう２パターンテスト。
ソース格納元をRamdisk(Gavotte)に、出力先がWD5000AAKS
Ut Video Codec Suite, Version 4.0.1 Copyright (C) 2008 UMEZAWA Takeshi
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
かかった時間 2:04
CPU負荷 60%弱
ソース格納元をRamdisk(Gavotte)に、出力先も同じRamdisk(Gavotte)に。
Ut Video Codec Suite, Version 4.0.1 Copyright (C) 2008 UMEZAWA Takeshi
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
かかった時間 2:04
CPU負荷 60%弱
結果、ほぼ変わらず。
CPU負荷が若干上がったような気がするのは、たぶんGavotteのせいかと。
結局、自分の環境ではディスクがボトルネックになっているという事は無さそう。
ソース格納元をRamdisk(Gavotte)に、出力先がWD5000AAKS
Ut Video Codec Suite, Version 4.0.1 Copyright (C) 2008 UMEZAWA Takeshi
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
かかった時間 2:04
CPU負荷 60%弱
ソース格納元をRamdisk(Gavotte)に、出力先も同じRamdisk(Gavotte)に。
Ut Video Codec Suite, Version 4.0.1 Copyright (C) 2008 UMEZAWA Takeshi
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
かかった時間 2:04
CPU負荷 60%弱
結果、ほぼ変わらず。
CPU負荷が若干上がったような気がするのは、たぶんGavotteのせいかと。
結局、自分の環境ではディスクがボトルネックになっているという事は無さそう。
速度と圧縮率上げてください
HDDのリード・ライト性能が十分ならアプリ側の入出力処理が
追いついていないだけだと思う
リード・ライトを同時に行うなら読み込みだけでもDirectShowを使わないと
処理が頭打ちして厳しいらしいよ
追いついていないだけだと思う
リード・ライトを同時に行うなら読み込みだけでもDirectShowを使わないと
処理が頭打ちして厳しいらしいよ
WDの10000rpm、320GBで3万以上かたけー
1TBの7200rpmHDDが2個買えるな
ストライピングは片方のHDDが逝くとデータが消失するので嫌だしな
やっぱり圧縮率のアップがいいかな
HDDの速度よりCPUの速度の方がムーアの法則的に上がるだろうし
1TBの7200rpmHDDが2個買えるな
ストライピングは片方のHDDが逝くとデータが消失するので嫌だしな
やっぱり圧縮率のアップがいいかな
HDDの速度よりCPUの速度の方がムーアの法則的に上がるだろうし
VirtualDubでDirectShow読みのやり方がわからんかった。
AviSynth使えばできるが>>368-369の問題がでるのでNG
AviUtl99d3で試したがCPU負荷は70%くらいになったが速度が遅くなった。通常の挙動がよくわからないのでパス。
入力のfastcodecがデカすぎるんだな、という事で普通は意味が無い、ソースをXvidのBフレOFFの物に差し替えてのエンコードに切り替えた(他は>>366と同じ)。
結果は見ての通り、fastcodecの場合と明らかな差が出た。
HuffYUV v2.2.0
設定 "Predict left"
CPU負荷：50%強
かかった時間：0:30
HuffYUV MT v1.1.1 Multi-Threding Patch v1.0
設定 "Predict left" マルチスレッディングモードにチェック スレッド数2
CPU負荷：50-60%をうろうろ
かかった時間：0:30
YLC
CPU負荷 Encode 50%前後
かかった時間：0:37
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
CPU負荷：70%前後
かかった時間：0:30
面白いのが3者横並びの速度の割には、UtVideoの負荷が高い。
ちなみにXvidを読ませてるけど、これってYV12→YUY2の変換が自動でかかってるんだよな？
単なる動作テストだから色空間がおかしくなろうがどうでもいいが。
ぼく、もう疲れたよパトラッシュ・・・
AviSynth使えばできるが>>368-369の問題がでるのでNG
AviUtl99d3で試したがCPU負荷は70%くらいになったが速度が遅くなった。通常の挙動がよくわからないのでパス。
入力のfastcodecがデカすぎるんだな、という事で普通は意味が無い、ソースをXvidのBフレOFFの物に差し替えてのエンコードに切り替えた(他は>>366と同じ)。
結果は見ての通り、fastcodecの場合と明らかな差が出た。
HuffYUV v2.2.0
設定 "Predict left"
CPU負荷：50%強
かかった時間：0:30
HuffYUV MT v1.1.1 Multi-Threding Patch v1.0
設定 "Predict left" マルチスレッディングモードにチェック スレッド数2
CPU負荷：50-60%をうろうろ
かかった時間：0:30
YLC
CPU負荷 Encode 50%前後
かかった時間：0:37
UtVideo-4.0.1 YUV422
設定 デコード速度優先(Predict left) フレーム分割数2
CPU負荷：70%前後
かかった時間：0:30
面白いのが3者横並びの速度の割には、UtVideoの負荷が高い。
ちなみにXvidを読ませてるけど、これってYV12→YUY2の変換が自動でかかってるんだよな？
単なる動作テストだから色空間がおかしくなろうがどうでもいいが。
ぼく、もう疲れたよパトラッシュ・・・
YLCの利点は容量なんだけどねｗ
或るプログラマの一生より
可逆VCMコーデック用ベンチマーク
～略～
動画コーデックをベンチマークする専用のソフトは見つかりません。
というわけでしょうがないので作ってみました。
なんかｋｔｋｒ
可逆VCMコーデック用ベンチマーク
～略～
動画コーデックをベンチマークする専用のソフトは見つかりません。
というわけでしょうがないので作ってみました。
なんかｋｔｋｒ
おお、
試してみたけどutもｙｌｃコーデックも認識しない
helixとffdshowだけしか選択肢にでないね。
環境xpｓｐ3
helixとffdshowだけしか選択肢にでないね。
環境xpｓｐ3
これは無圧縮を別の圧縮にってベンチでしょ
utやylcで取り込んだものは一度無圧縮に変換して
exeにドラッグしてやれば「ほげほげ」って画面が出てくるからコーデック選択してOK
utやylcで取り込んだものは一度無圧縮に変換して
exeにドラッグしてやれば「ほげほげ」って画面が出てくるからコーデック選択してOK
ログのとり方がわからんｗ
ドロップしたら実行されるけどログがとれない
でバッチ作って試したけど
f:\vctest f:\12.avi -c >a.txt
例外 unknown software exception (0xc000000d) がアプリケーションの 0x00407571 で発生しました。
プログラムを終了するには [OK] をクリックしてください
プログラムをデバッグするには [キャンセル] をクリックしてください
こういうエラーがでる。
でバッチ作って試したけど
f:\vctest f:\12.avi -c >a.txt
例外 unknown software exception (0xc000000d) がアプリケーションの 0x00407571 で発生しました。
プログラムを終了するには [OK] をクリックしてください
プログラムをデバッグするには [キャンセル] をクリックしてください
こういうエラーがでる。
>>383
どっかにないかと探してたんだ。ありがとうっ！行ってくるよ。
どっかにないかと探してたんだ。ありがとうっ！行ってくるよ。
バッチでコピペしたらログかｗ
YLC
Size: 58298384/155520000 (37.5%, 2.67)
Encode time: 940.211530ms/150f = 6.268077ms/f
min 6.063749
max 6.984989
Decode time: 2374.975972ms/150f = 15.833173ms/f
min 14.281304
max 17.179842
UtVideoYUV
Size: 54928088/155520000 (35.3%, 2.83)
Encode time: 399.097918ms/150f = 2.660653ms/f
min 2.523615
max 3.153070
Decode time: 821.321029ms/150f = 5.475474ms/f
min 5.332965
max 6.426920
Huffyuv v2.1.1
Size: 68209140/155520000 (43.9%, 2.28)
Encode time: 868.442498ms/150f = 5.789617ms/f
min 5.332221
max 6.485308
Decode time: 1389.884927ms/150f = 9.265900ms/f
min 9.029340
max 10.193499
Size: 58298384/155520000 (37.5%, 2.67)
Encode time: 940.211530ms/150f = 6.268077ms/f
min 6.063749
max 6.984989
Decode time: 2374.975972ms/150f = 15.833173ms/f
min 14.281304
max 17.179842
UtVideoYUV
Size: 54928088/155520000 (35.3%, 2.83)
Encode time: 399.097918ms/150f = 2.660653ms/f
min 2.523615
max 3.153070
Decode time: 821.321029ms/150f = 5.475474ms/f
min 5.332965
max 6.426920
Huffyuv v2.1.1
Size: 68209140/155520000 (43.9%, 2.28)
Encode time: 868.442498ms/150f = 5.789617ms/f
min 5.332221
max 6.485308
Decode time: 1389.884927ms/150f = 9.265900ms/f
min 9.029340
max 10.193499
乙。その結果見るとYLCが一番いいように見えるんだけど
他の設定はどうなってるんだろ
他の設定はどうなってるんだろ
無圧縮 148MB 5秒の動画
UtVideo 52.3MB
YLC 55.2MB
Huffyuv v2.1.1 65.0MB
YLCは30分ぐらいだと容量低いのに5秒だとUtVideoのほうが低い
YLCは圧縮率は長時間にならないと効果でないね
逆に言えばUtVideoは長時間に弱いのか…バージョンアップで改善されるのかな
UtVideo 52.3MB
YLC 55.2MB
Huffyuv v2.1.1 65.0MB
YLCは30分ぐらいだと容量低いのに5秒だとUtVideoのほうが低い
YLCは圧縮率は長時間にならないと効果でないね
逆に言えばUtVideoは長時間に弱いのか…バージョンアップで改善されるのかな
>>392
UtVideoYUVが一番だよ
UtVideoYUVが一番だよ
お疲れ様。UtVideoが一番いいってことでｏｋか。
長時間の圧縮ならＹＬＣがいいってことはやっぱアニメとかのキャプ用ってわけと。
長時間の圧縮ならＹＬＣがいいってことはやっぱアニメとかのキャプ用ってわけと。
あ
見直したらさすがに理解したよｗ
UtVideoはHuffyuvの半分くらいのサイズにして欲しい
UtVideoはエンコが一瞬で終わるようにしてほしい
いやな、中間ファイルに使ってる人もいればキャプ用に使う人もいるだろう。
中間ファイルならばエンコが早い方がいいんだろうけど
キャプ用ならばよりよく圧縮してくれた方がいい。
使用用途によって設定できればいいんだけどな。
中間ファイルならばエンコが早い方がいいんだろうけど
キャプ用ならばよりよく圧縮してくれた方がいい。
使用用途によって設定できればいいんだけどな。
わんぱくでもいい
キャプ用でhuffyuvで無問題な環境を整えちゃうと、
エンコ速度や圧縮率が多少変わっても影響ないんだよね。
デコード速度は、その後のエンコ速度が変わるから速くなって欲しい。
エンコ速度や圧縮率が多少変わっても影響ないんだよね。
デコード速度は、その後のエンコ速度が変わるから速くなって欲しい。
>>403
そりゃこんなHDDを買える超金持ちなら影響無いでしょうよ。
http://www.westerndigital.com/jp/products/products.asp?driveid=459
貧乏人が使ってるWD5000AAKSシングルで無理なくキャプれる圧縮率になるのは夢なのか？
そりゃこんなHDDを買える超金持ちなら影響無いでしょうよ。
http://www.westerndigital.com/jp/products/products.asp?driveid=459
貧乏人が使ってるWD5000AAKSシングルで無理なくキャプれる圧縮率になるのは夢なのか？
WD5000AAKSシングルで1080iならIntenでキャプれるよ
安定してキャプれるかどうかだな
キャプる前デフラグ必須だと問題外。
安定してキャプる為には
UtVideo 1920x1080 *D3 15MB/s
は実現して欲しい＞欝ビデオの作者氏へ
キャプる前デフラグ必須だと問題外。
安定してキャプる為には
UtVideo 1920x1080 *D3 15MB/s
は実現して欲しい＞欝ビデオの作者氏へ
>>404みたいに逆ギレしちゃう奴って可哀想な人？
「ｵﾚ様は○○が必要なくらい凄い事をしてるが、おまえはそんな物を必要としないチンケな事してるから関係無いんだろ」
とでも言いたいのだろうか。
用途なんて人それぞれだし、いくら必死に喚いたところで開発者が聞いてくれなきゃ、それまでの話なのに。
そんなに大変なら非可逆でキャプればいいんでねーの？
どうせ最後は非可逆になるんだろうし、大した差は無いんじゃね
「ｵﾚ様は○○が必要なくらい凄い事をしてるが、おまえはそんな物を必要としないチンケな事してるから関係無いんだろ」
とでも言いたいのだろうか。
用途なんて人それぞれだし、いくら必死に喚いたところで開発者が聞いてくれなきゃ、それまでの話なのに。
そんなに大変なら非可逆でキャプればいいんでねーの？
どうせ最後は非可逆になるんだろうし、大した差は無いんじゃね
この時代に圧縮率気にする奴はキャプしない方がいいと思うんだけどな
なんでこのスレのやつらこんなに偉そうなの？
>>407
非可逆スレが欲しいので立てて。
非可逆スレが欲しいので立てて。
>>410
おまえはスレ検索すらできないアホか？気に入らないなら自分で立てろ。
http://pc11.2ch.net/test/read.cgi/avi/1081819976/
http://pc11.2ch.net/test/read.cgi/avi/1018287433/
http://pc11.2ch.net/test/read.cgi/avi/987071822/
http://pc11.2ch.net/test/read.cgi/avi/1033350305/
おまえはスレ検索すらできないアホか？気に入らないなら自分で立てろ。
http://pc11.2ch.net/test/read.cgi/avi/1081819976/
http://pc11.2ch.net/test/read.cgi/avi/1018287433/
http://pc11.2ch.net/test/read.cgi/avi/987071822/
http://pc11.2ch.net/test/read.cgi/avi/1033350305/
>>402
たくましく育って欲しい
たくましく育って欲しい
>>413
ハイレハイレフレハイレホー
ハイレハイレフレハイレホー
>>412
うわああああああ
うわああああああ
そのWDのHDDは読み書きが速いのではなくて
ランダムアクセスが強い（速い）んだぜ
高回転型はそういった狙いで作っているのだし
キャプチャはHDDの最内周（最悪値）を考慮してシステムを
組むのが俺のやり方
今どきのHDDだと２台でストライピングしておいた方が安心
それと非可逆はスレチだろ・・・
ランダムアクセスが強い（速い）んだぜ
高回転型はそういった狙いで作っているのだし
キャプチャはHDDの最内周（最悪値）を考慮してシステムを
組むのが俺のやり方
今どきのHDDだと２台でストライピングしておいた方が安心
それと非可逆はスレチだろ・・・
>>417
すいません。今フリーで出てるキャプ用非可逆コーデックって、
「PICVideo MJPEG Codec」
http://www.pegasusimaging.com/picvideomjpeg.htm
「Canopus HQ Codec」
http://www.canopus.co.jp/catalog/hqcodec/hq_codec.htm
「Black magic 8bit MJPEG」
「DeckLink MJPEG」
http://www.blackmagic-design.jp/support/software/
「アースソフト フレーム内圧縮コーデック」
http://earthsoft.jp/PV/download.html
「MotionJpeg2000Codec」
http://www.morgan-multimedia.com/M-JPEG2000/
くらいしか知りません。他知ってるのがあれば追加よろしくお願いします。
スレの趣旨は、
■綺麗でサイズの小さいキャプチャー用非可逆コーデックについて情報交換しましょう。
●「我こそは世界で最も綺麗でサイズの小さい非可逆コーデックを作ってやる」と活き込んでる開発者（神様）を募集中。
×調べもしないで「いい非可逆コーデックはありませんか？」とか「コーデックの設定について教えてください」とかいう厨房はお断り。
【現在存在してる各非可逆コーデックのリンク先】
ってな感じでいいです。
すいません。今フリーで出てるキャプ用非可逆コーデックって、
「PICVideo MJPEG Codec」
http://www.pegasusimaging.com/picvideomjpeg.htm
「Canopus HQ Codec」
http://www.canopus.co.jp/catalog/hqcodec/hq_codec.htm
「Black magic 8bit MJPEG」
「DeckLink MJPEG」
http://www.blackmagic-design.jp/support/software/
「アースソフト フレーム内圧縮コーデック」
http://earthsoft.jp/PV/download.html
「MotionJpeg2000Codec」
http://www.morgan-multimedia.com/M-JPEG2000/
くらいしか知りません。他知ってるのがあれば追加よろしくお願いします。
スレの趣旨は、
■綺麗でサイズの小さいキャプチャー用非可逆コーデックについて情報交換しましょう。
●「我こそは世界で最も綺麗でサイズの小さい非可逆コーデックを作ってやる」と活き込んでる開発者（神様）を募集中。
×調べもしないで「いい非可逆コーデックはありませんか？」とか「コーデックの設定について教えてください」とかいう厨房はお断り。
【現在存在してる各非可逆コーデックのリンク先】
ってな感じでいいです。
非可逆じゃないのも含まれてるじゃんｗ
[UtVideo] バージョン 4.0.2
ULRG: デコード時に RGB32 で出力する場合、安全のためアルファチャンネルと解釈されうるフィールドは 255 で埋めるようにした。
共通: エンコード時に出力の biBitCount には入力の実効ビット数を設定するようにした。
ULRG: デコード時に RGB32 で出力する場合、安全のためアルファチャンネルと解釈されうるフィールドは 255 で埋めるようにした。
共通: エンコード時に出力の biBitCount には入力の実効ビット数を設定するようにした。
保管庫にLagarithが３種類あるけどどれがいいの？（Core2Duo
前スレは完全に追えなかった…
前スレは完全に追えなかった…
Lagarithは現状使い道はないと思うけど
圧縮率稼ぎたい奴が使うんじゃね？
ｱﾘｸｲってよ､1日に三万匹ｱﾘ食うんだってwww3日で九万匹wwwｱﾘいなくなっちゃうよ!
ﾌﾗﾐﾝｺﾞって､なんで片足か知ってる?冷えるんだってよwwww
でも､水ん中入ってるんだぜ? だったら出りゃいいじゃんww
ﾓｸﾞﾗのﾄﾝﾈﾙ掘るｽﾋﾟｰﾄﾞはｶﾀﾂﾑﾘの進む速度の1/3だってwww遅いよwww得技だろよwwそのｽﾋﾟｰﾄﾞなら地上でろ地上でろ!
羊は前歯が下あごにしか生えてないんだって｡
その代わり上あごの歯茎が歯より固いんだってwwww
生えればいいのにww歯が生えればいいのにww
ｶﾀﾂﾑﾘってすげぇんだぜ｡ｶﾀﾂﾑﾘってよ､
-120℃でも死なないんだぜ｡-120℃だぜ｡
普通-120度だったら動物全滅するだろ｡ただｶﾀﾂﾑﾘだけは氷河期になっても生き残るんだよ｡
すげぇ生命力だよな｡
ただよ､-120℃になるとｶﾀﾂﾑﾘのｴｻが無いんだってwwwww
｢草木が生えないから結果死にますね｣だってwwwwwwww
人間ってよ血液型何種類か知ってる?4種類だろ｡
じゃ馬｡馬は何種類か知ってる?3兆wwwwwwwwwwwwwwwwww
ちなみにｺﾞﾘﾗはみんなB型だってwww少なくねwwwww
全部自己中だよｺﾞﾘﾗwwwwww
ｺﾞﾘﾗってよ､あれ通称ってこと知ってんだろ｡
あれの本名､つまり学名ってなんだか知ってる?知ってる?
ｺﾞﾘﾗ･ｺﾞﾘﾗだってwwwww
まんまじゃねえか｡まんまじゃねえかおい｡それがﾛｰﾗﾝﾄﾞｺﾞﾘﾗだとなんだか知ってる?
ｺﾞﾘﾗ･ｺﾞﾘﾗ･ｺﾞﾘﾗだってwwwwwwwwwちょwwおまwwwww
ﾌﾗﾐﾝｺﾞって､なんで片足か知ってる?冷えるんだってよwwww
でも､水ん中入ってるんだぜ? だったら出りゃいいじゃんww
ﾓｸﾞﾗのﾄﾝﾈﾙ掘るｽﾋﾟｰﾄﾞはｶﾀﾂﾑﾘの進む速度の1/3だってwww遅いよwww得技だろよwwそのｽﾋﾟｰﾄﾞなら地上でろ地上でろ!
羊は前歯が下あごにしか生えてないんだって｡
その代わり上あごの歯茎が歯より固いんだってwwww
生えればいいのにww歯が生えればいいのにww
ｶﾀﾂﾑﾘってすげぇんだぜ｡ｶﾀﾂﾑﾘってよ､
-120℃でも死なないんだぜ｡-120℃だぜ｡
普通-120度だったら動物全滅するだろ｡ただｶﾀﾂﾑﾘだけは氷河期になっても生き残るんだよ｡
すげぇ生命力だよな｡
ただよ､-120℃になるとｶﾀﾂﾑﾘのｴｻが無いんだってwwwww
｢草木が生えないから結果死にますね｣だってwwwwwwww
人間ってよ血液型何種類か知ってる?4種類だろ｡
じゃ馬｡馬は何種類か知ってる?3兆wwwwwwwwwwwwwwwwww
ちなみにｺﾞﾘﾗはみんなB型だってwww少なくねwwwww
全部自己中だよｺﾞﾘﾗwwwwww
ｺﾞﾘﾗってよ､あれ通称ってこと知ってんだろ｡
あれの本名､つまり学名ってなんだか知ってる?知ってる?
ｺﾞﾘﾗ･ｺﾞﾘﾗだってwwwww
まんまじゃねえか｡まんまじゃねえかおい｡それがﾛｰﾗﾝﾄﾞｺﾞﾘﾗだとなんだか知ってる?
ｺﾞﾘﾗ･ｺﾞﾘﾗ･ｺﾞﾘﾗだってwwwwwwwwwちょwwおまwwwww
>>423
ttp://www.23ch.info/test/read.cgi/avi/1098022448/
これの802と817見てみな
で今Lagarithのサイト見てきたんだが、更新されてね？
ttp://www.23ch.info/test/read.cgi/avi/1098022448/
これの802と817見てみな
で今Lagarithのサイト見てきたんだが、更新されてね？
>>427
ありがとです。719版を使うのが正しい感じですね。というか716版って何なんだろう…まあいいか。
ありがとです。719版を使うのが正しい感じですね。というか716版って何なんだろう…まあいいか。
TMPGでのバグが直ったのか？もうTMPG使わないからあれだけど
非可逆スレの人気に嫉妬
人々はサイズが小さくてHDDに優しいコーデックを求めてるのだよな
人々はサイズが小さくてHDDに優しいコーデックを求めてるのだよな
ソフトウェアキャプで可逆圧縮だと、みんなCPUはQuad使ってる？
現状くらいなら、Duoでもそんなに差は出ないかな？
現状くらいなら、Duoでもそんなに差は出ないかな？
>人々はサイズが小さくてHDDに優しいコーデックを求めてるのだよな
だろうな
CPUよりHDDの性能が落ちるPC使ってるヲタが多そう
>Duoでもそんなに差は出ないかな？
差って、具体的に「何の」差を聞きたいわけ？
だろうな
CPUよりHDDの性能が落ちるPC使ってるヲタが多そう
>Duoでもそんなに差は出ないかな？
差って、具体的に「何の」差を聞きたいわけ？
LagarithがHDD的にはやさしい
>>433
たぶんＨＤＤは割れの方に金をかけてキャプには金をかけたくないのだろう
たぶんＨＤＤは割れの方に金をかけてキャプには金をかけたくないのだろう
「PICVideo MJPEG Codec」
(・∀・)ｲｲ!!
◎...
○...
△...
･ﾟ･(ﾉД`)･ﾟ･ﾀﾞﾒ!
▼...
▽...
×...
な感じで。
(・∀・)ｲｲ!!
◎...
○...
△...
･ﾟ･(ﾉД`)･ﾟ･ﾀﾞﾒ!
▼...
▽...
×...
な感じで。
MSU Screen Capture Lossless Codec縮み過ぎわろた。
鬱とかLagarithとかの1/4も縮んでやがる。
ただしちょっと遅いし動きの多いやつじゃ怪しいらしい。
使いどころが難しいな。
鬱とかLagarithとかの1/4も縮んでやがる。
ただしちょっと遅いし動きの多いやつじゃ怪しいらしい。
使いどころが難しいな。
試してみたけど縮みすぎｗ
フレームレート落としても問題ないようなプレイ動画なら使えそうな感じだね。
フレームレート落としても問題ないようなプレイ動画なら使えそうな感じだね。
UtVideoRGB
Size: 370878468/1597346688 (23.2%, 4.31)
Encode time: 4148.951898ms/3691f = 1.124073ms/f
Decode time: 8446.063562ms/3691f = 2.288286ms/f
MSU Screen Capture Lossless Codec
Size: 41077057/1597346688 ( 2.6%, 38.89)
Encode time: 21919.195896ms/3691f = 5.938552ms/f
Decode time: 20900.899060ms/3691f = 5.662666ms/f
元動画はフラッシュ。
ただ640×480の30fpsでキャプするとcore2duo3.2Gだとドロップが多発する。
用途は限定されるだろうね。
Size: 370878468/1597346688 (23.2%, 4.31)
Encode time: 4148.951898ms/3691f = 1.124073ms/f
Decode time: 8446.063562ms/3691f = 2.288286ms/f
MSU Screen Capture Lossless Codec
Size: 41077057/1597346688 ( 2.6%, 38.89)
Encode time: 21919.195896ms/3691f = 5.938552ms/f
Decode time: 20900.899060ms/3691f = 5.662666ms/f
元動画はフラッシュ。
ただ640×480の30fpsでキャプするとcore2duo3.2Gだとドロップが多発する。
用途は限定されるだろうね。
見た感じだと色空間が統一されていなくて
結果が極端になっているだけのような気がする
結果が極端になっているだけのような気がする
バラつきがあるにせよどの道圧縮率が現時点では異常。
ただ負荷が大きくてキャプチャーも再生もお勧めできない。
使ってみると分かるけど色々もてあましてる感じ。
とりあえず編集待ちのソースを片っ端からコイツにしてHDDの空きを確保＾ｐ＾
ま、俺のCPUは6400+だがねｗ
ただ負荷が大きくてキャプチャーも再生もお勧めできない。
使ってみると分かるけど色々もてあましてる感じ。
とりあえず編集待ちのソースを片っ端からコイツにしてHDDの空きを確保＾ｐ＾
ま、俺のCPUは6400+だがねｗ
あれは負荷でかくついてんのか？
可逆でない気がする
可逆でない気がする
vctestでの結果もあるしロスレスでしょ。
vctestはいつの間にロスレスしか認識しない仕様になったんだ？
Lossless Checking is enabled
ってでてるしチェックしてるんじゃ？
そもそも本家でLossless Codecと言ってるのに
可逆じゃないと根拠なしに言ってるほうがおかしいでしょ。
ってでてるしチェックしてるんじゃ？
そもそも本家でLossless Codecと言ってるのに
可逆じゃないと根拠なしに言ってるほうがおかしいでしょ。
>>442
長期の保存用に良いなこれ。
長期の保存用に良いなこれ。
ID:xGpKw0mv
そういうお前も言ってることに根拠がないぞ。
とりあえず「負荷でカクついてるのか」と言う疑問に対しては負荷でカクついていると俺は考える。
なぜならMSU-SCLC（縮めても名前長いな）で圧縮した動画をを別な可逆に再び圧縮する（もしくは未圧縮に戻す）と
特に速度面では異常なく再生することが出来ていたから。
お前は画質については振れてないようだけど、
元動画とMSU-SCLCで圧縮した動画の任意の同じ１コマをを
差分検出ツールを用いて違いがあるか調べてみたけど違いは見られなかった。
Detect Fadeの有無にかかわらず同じ結果だったと付け加えておく。
俺はこのコーデックが可逆であるかについてとくに疑いを持ってないから
やり方は簡単にしたけどコレぐらいなら可逆だと考えるに値すると思うんだけどどうかね。
そういうお前も言ってることに根拠がないぞ。
とりあえず「負荷でカクついてるのか」と言う疑問に対しては負荷でカクついていると俺は考える。
なぜならMSU-SCLC（縮めても名前長いな）で圧縮した動画をを別な可逆に再び圧縮する（もしくは未圧縮に戻す）と
特に速度面では異常なく再生することが出来ていたから。
お前は画質については振れてないようだけど、
元動画とMSU-SCLCで圧縮した動画の任意の同じ１コマをを
差分検出ツールを用いて違いがあるか調べてみたけど違いは見られなかった。
Detect Fadeの有無にかかわらず同じ結果だったと付け加えておく。
俺はこのコーデックが可逆であるかについてとくに疑いを持ってないから
やり方は簡単にしたけどコレぐらいなら可逆だと考えるに値すると思うんだけどどうかね。
MSU-SCLCでｴﾝｺしたらUtVideoより膨らんだ…。
ソースによるのかな？できたらvctestあたりでの結果が知りたいけど。
そういや俺のも若干膨らんでるな。
dwLength = 161
dwScale=1
dwRate=15
MSU-SCLC
Size: 162037756/379846656 (42.7%, 2.34)
Ut
Size: 157102192/379846656 (41.4%, 2.42)
動きの多い奴だと圧縮率が怪しいって話どおりなのかなぁ。
カメラワークが激しい奴の一部分を抜いてきたんだけど。
実際にAviUtlで圧縮したのも似たような傾向でUtのほうが小さかった。
ただvctestの項にはキーフレームの指定が無いのが気がかり。
dwLength = 161
dwScale=1
dwRate=15
MSU-SCLC
Size: 162037756/379846656 (42.7%, 2.34)
Ut
Size: 157102192/379846656 (41.4%, 2.42)
動きの多い奴だと圧縮率が怪しいって話どおりなのかなぁ。
カメラワークが激しい奴の一部分を抜いてきたんだけど。
実際にAviUtlで圧縮したのも似たような傾向でUtのほうが小さかった。
ただvctestの項にはキーフレームの指定が無いのが気がかり。
テストの為、アニメのオープニングを640x480に縮めてMSU-SCLCを使ったら
huffyuvの2倍以上になった
MSUのキーフレームは1フレーム毎にしないと画が出てこなかったからその設定
全然お話にならん感じ
huffyuvの2倍以上になった
MSUのキーフレームは1フレーム毎にしないと画が出てこなかったからその設定
全然お話にならん感じ
こっちも某シューティングゲーム撮ってUTと比較したけど
UT 4.2G MSU-SCLC 3.6Gで劇的な差はでなかった。
動きの激しいものはダメっぽいねぇ
UT 4.2G MSU-SCLC 3.6Gで劇的な差はでなかった。
動きの激しいものはダメっぽいねぇ
RuSHと同じで、フレーム参照圧縮もしているんじゃないかなぁ
それだと重いだろうし、動きやピクセル誤差があるとフレーム参照が効かなくて縮まないしね
それだと重いだろうし、動きやピクセル誤差があるとフレーム参照が効かなくて縮まないしね
Screen Captureっていうくらいだから、デスクトップキャプチャみたいな
静止部分の多い動画にフォーカスしてるんじゃないの？
静止部分の多い動画にフォーカスしてるんじゃないの？
結論：huffyuvで今はいい
MSU-SCLCをマルチスレッドとSSE最適化なりすれば実用域に入るかもしれない。
今でも動きが少ないものなら使えそうだし。
今でも動きが少ないものなら使えそうだし。
vctestがあがってた。キーフレーム率の設定できるようになったらしい。
Lossless checking enabled
>（最後に -c を付けた場合）は「Lossless checking enabled」になってチェックします。
>たとえば RGB で入出力するけど内部保持形式が YUV422 の場合は、
>見た目が同じでも完全にロスレスにはなっていないので、チェックしないで実行する必要があります。
だそうだ。
Lossless checking enabled
>（最後に -c を付けた場合）は「Lossless checking enabled」になってチェックします。
>たとえば RGB で入出力するけど内部保持形式が YUV422 の場合は、
>見た目が同じでも完全にロスレスにはなっていないので、チェックしないで実行する必要があります。
だそうだ。
>>461
videoではなく(デスクトップ的な意味で)screenって言うくらいだから動きの少ないものを想定してるんだろ
videoではなく(デスクトップ的な意味で)screenって言うくらいだから動きの少ないものを想定してるんだろ
最近の楽しみはUtVideoの発展だったのだが作者は力尽きたのかしら。
アイマスが楽しそうですね、っと。
アイマスが楽しそうですね、っと。
例の隠しコマンドかｗ
この時代に隠しコマンドってだけで興奮するわけだが
iM@S MultiColor Keying for AviSynth
可逆圧縮と関係ないだろｗ
何張ってんだよｗｗｗ
何張ってんだよｗｗｗ
>>468
俺もそれみてｸｿﾜﾛﾀｗｗ
俺もそれみてｸｿﾜﾛﾀｗｗ
自演乙だります！
aviutl版も作ってくれ
～前略～
それよりも注目すべきは YLC。圧縮比 4.55 倍は、エンコード時間がそれほど長くないことを加味すると圧巻です。YLC はエンコード中の CPU 使用率を見る限りシングルスレッド動作しているようなのですが、マルチスレッド対応したら最強じゃんこれ。
こうなってくると YLC がどういうアルゴリズムでエンコードしているのか非常に気になります。教えてＫＥＮくん！ってここで叫んでどーする。
コメント1
そんな大したアルゴリズムでもないので
後で簡単に文章にして送りますよ！ by KENくん
それよりも注目すべきは YLC。圧縮比 4.55 倍は、エンコード時間がそれほど長くないことを加味すると圧巻です。YLC はエンコード中の CPU 使用率を見る限りシングルスレッド動作しているようなのですが、マルチスレッド対応したら最強じゃんこれ。
こうなってくると YLC がどういうアルゴリズムでエンコードしているのか非常に気になります。教えてＫＥＮくん！ってここで叫んでどーする。
コメント1
そんな大したアルゴリズムでもないので
後で簡単に文章にして送りますよ！ by KENくん
YLCはデュアル専用じゃなかったけｗ
utの人のところで今後の方向性？聞いてるっぽいんで言うのはタダなんで書いてみる
MSU のような動き予測追加かなあYLCマルチスレッドにしてもUt Videoとそんなに差があるとは思えないし・・・
MSU のような動き予測追加かなあYLCマルチスレッドにしてもUt Videoとそんなに差があるとは思えないし・・・
YV12対応してほしいです。
masktools使う関数（例えばDidee氏の作った関数はほぼ全て）は
YUY2からYV12に変換しなけりゃならないので、
masktools使う激重の関数をいくつか連荘で並べたスクリプトの場合に
メモリの都合から連荘の途中で一旦可逆で出力したい、って時に
Lagarithよりエンコード・デコードが速い可逆があると非常に助かります。
masktools使う関数（例えばDidee氏の作った関数はほぼ全て）は
YUY2からYV12に変換しなけりゃならないので、
masktools使う激重の関数をいくつか連荘で並べたスクリプトの場合に
メモリの都合から連荘の途中で一旦可逆で出力したい、って時に
Lagarithよりエンコード・デコードが速い可逆があると非常に助かります。
>Huffyuv と同じ圧縮率で、エンコードが 1～2 割ほど速く、デコードが 3 割
>ほど速い（現在の ULY2 よりちょっと速い）ものを作れることは分かってい
>ます。どうしましょ。
ぜひやってくれ。速いに越したことはない。
>圧縮率を上げる方向は、ハフマン符号の代わりに Range Coder を使うことに
>すれば、まあまあ圧縮率を稼ぐことができます。それ以上を狙うと、MSU の
>ように動き予測などをしなければいけないのでしょうが、それだったら MSU
>を使った方が幸せなように思えます。と思ったけど MSU はマルチスレッド動
>作していない雰囲気ですね。
ぜひやってくれ。圧縮率が高いことに越したことはない。
結論、両方組み込んで速度重視と圧縮重視の2つのプロファイルを実装。
>ほど速い（現在の ULY2 よりちょっと速い）ものを作れることは分かってい
>ます。どうしましょ。
ぜひやってくれ。速いに越したことはない。
>圧縮率を上げる方向は、ハフマン符号の代わりに Range Coder を使うことに
>すれば、まあまあ圧縮率を稼ぐことができます。それ以上を狙うと、MSU の
>ように動き予測などをしなければいけないのでしょうが、それだったら MSU
>を使った方が幸せなように思えます。と思ったけど MSU はマルチスレッド動
>作していない雰囲気ですね。
ぜひやってくれ。圧縮率が高いことに越したことはない。
結論、両方組み込んで速度重視と圧縮重視の2つのプロファイルを実装。
色ずれ補正とか付いてたらいいな
それぐらい、フィルタでやれよ
動き予測までしなくても
フレーム間の画素差分取る様にすれば
それなりに圧縮率は上がるんじゃね？
その方が簡単だし
フレーム間の画素差分取る様にすれば
それなりに圧縮率は上がるんじゃね？
その方が簡単だし
詳しいことは分からんけど、フレーム間圧縮やるとAVIのフリをさせるのが
大変なんじゃないの？
少し圧縮率が上がったくらいでは元が取れないのジャマイカ。
大変なんじゃないの？
少し圧縮率が上がったくらいでは元が取れないのジャマイカ。
>>481
前方向のみで処理をすれば多分大丈夫
前方向のみで処理をすれば多分大丈夫
シークとか逆再生とか全く考慮しなければ効率いいものができそうだね。
キーフレームはフル圧縮が必要だろ
キーフレームの頻度が上がるとサイズが大きくなる、下がるとシークが遅くなる
キーフレームの頻度が上がるとサイズが大きくなる、下がるとシークが遅くなる
フレーム間圧縮をやる場合、シーク速度が肝になるな。
差分フレームは最大何フレーム分取るか？(GOP長？)
キーフレームの自動挿入はやるか？
キーフレームのバッファをどのくらい取るか？
そんなんで変わってくるんだろうな・・・
差分フレームは最大何フレーム分取るか？(GOP長？)
キーフレームの自動挿入はやるか？
キーフレームのバッファをどのくらい取るか？
そんなんで変わってくるんだろうな・・・
486 ：名無しさん＠編集中：2008/07/23(水) 21:03:08 ID:1SpLFfOJ
huffyuvsってのは何なの？
>>486
なんか凄いのｷﾀｰ
なんか凄いのｷﾀｰ
Lagarith Lossless Video Codec v1.3.17来てたのね・・
>>488
いつのまに！
いつのまに！
utってさ、64bitで使えるの？使えたら試した印だけども…
使えたよ。
>>490
試せるなら使ってみれば？
試せるなら使ってみれば？
うｎ、後でやってみる
【社会】 「息子が柔道ごっこでいじめられた」と思い込んだ山口組系暴力団組長、中学生３人を投げ飛ばして逮捕…宮崎★２
http://mamono.2ch.net/test/read.cgi/newsplus/1217358063/l50
★１１０番・１１９番：傷害容疑で暴力団組長逮捕 ／宮崎
・２８日、宮崎市鶴島、山口組系暴力団組長、根本倫夫容疑者（６０）を傷害・暴行容疑で。
２４日、市内の公園で、中学１年の男子生徒３人に対して、「小学生の長男をいじめた」と
因縁をつけて投げ飛ばし、うち２人に全治５～７日の打撲を負わせた疑い。
直前に、被害者の中学生グループが長男らの小学生グループと「柔道ごっこ」をしていた。
この際、長男が倒れ込み、泣いて帰宅。長男から事情を聴いた根本容疑者が公園に
戻って３人に暴行した。
http://mainichi.jp/area/miyazaki/news/20080729ddlk45040570000c.html
・警察によりますと、根本容疑者は、今月２４日の昼頃、宮崎市内の公園で中学１年生３人に
対し、小学生の長男をいじめたなどと因縁をつけて地面に投げ飛ばすなどの暴行を加え、
中学生２人にそれぞれ７日間と５日間の打撲などのけがを負わせたということです。
被害にあった中学生３人は、根本容疑者の長男を含む小学生数人と、公園で柔道をして
遊んでいましたが、過って中学生のうちの１人が根本容疑者の長男の上に倒れ込んで
しまい、泣いて帰った長男の話を聞いた根本容疑者が、長男が中学生にいじめられたと
思いこみ、暴行をしたということです。
調べに対し、根本容疑者は容疑を否認しているということですが、警察では目撃者の
証言などから根本容疑者を傷害と暴行の疑いで逮捕して調べています。（一部略）
http://www.nhk.or.jp/miyazaki/lnews/06.html
※前：http://mamono.2ch.net/test/read.cgi/newsplus/1217318077/
http://mamono.2ch.net/test/read.cgi/newsplus/1217358063/l50
★１１０番・１１９番：傷害容疑で暴力団組長逮捕 ／宮崎
・２８日、宮崎市鶴島、山口組系暴力団組長、根本倫夫容疑者（６０）を傷害・暴行容疑で。
２４日、市内の公園で、中学１年の男子生徒３人に対して、「小学生の長男をいじめた」と
因縁をつけて投げ飛ばし、うち２人に全治５～７日の打撲を負わせた疑い。
直前に、被害者の中学生グループが長男らの小学生グループと「柔道ごっこ」をしていた。
この際、長男が倒れ込み、泣いて帰宅。長男から事情を聴いた根本容疑者が公園に
戻って３人に暴行した。
http://mainichi.jp/area/miyazaki/news/20080729ddlk45040570000c.html
・警察によりますと、根本容疑者は、今月２４日の昼頃、宮崎市内の公園で中学１年生３人に
対し、小学生の長男をいじめたなどと因縁をつけて地面に投げ飛ばすなどの暴行を加え、
中学生２人にそれぞれ７日間と５日間の打撲などのけがを負わせたということです。
被害にあった中学生３人は、根本容疑者の長男を含む小学生数人と、公園で柔道をして
遊んでいましたが、過って中学生のうちの１人が根本容疑者の長男の上に倒れ込んで
しまい、泣いて帰った長男の話を聞いた根本容疑者が、長男が中学生にいじめられたと
思いこみ、暴行をしたということです。
調べに対し、根本容疑者は容疑を否認しているということですが、警察では目撃者の
証言などから根本容疑者を傷害と暴行の疑いで逮捕して調べています。（一部略）
http://www.nhk.or.jp/miyazaki/lnews/06.html
※前：http://mamono.2ch.net/test/read.cgi/newsplus/1217318077/
UtVideoの今後の方針が出たようですね
つーか、C++で高速コーデックとか笑っちまうな
しかも、ループの中でnewしてるし
しかも、ループの中でnewしてるし
＞これにより Huffyuv より圧縮率は多少悪くなってしまいます。速度最優先なので仕方のないところではありますが。
圧縮率を稼ぎたい人が多いようだが、俺的にはｷﾀｰだな。
圧縮率を稼ぎたい人が多いようだが、俺的にはｷﾀｰだな。
ほとんどの人にとって可逆圧縮の主な用途は中間ファイルだろうから
圧縮率はそれなりにあれば、あとは速度最優先なのは良いことだ
圧縮率はそれなりにあれば、あとは速度最優先なのは良いことだ
ニコ厨が作ったコーデックなんざゴミ
そう思うなら使わなければいい
アニソンをflacとかmonkeyでリッピングしまくって聴いてるアフォみたいなやつのことか
UtVideo、PE4と相性悪い・・・のは俺だけ？
CD焼くならimgファイルなわけで・・・・・・
EACだと音がずれないとかいうけどそんなことはないわけで・・・・・
そもそも音楽情報が消えてCUEになるわけで・・・・
焼くのが目的なのにapeとかはもうあっち系の人が使ってるだけなわけで・・・・
パソコンで聞く分にはAPE利用できるけどそれは中間じゃないわけで・・・・・・
EACだと音がずれないとかいうけどそんなことはないわけで・・・・・
そもそも音楽情報が消えてCUEになるわけで・・・・
焼くのが目的なのにapeとかはもうあっち系の人が使ってるだけなわけで・・・・
パソコンで聞く分にはAPE利用できるけどそれは中間じゃないわけで・・・・・・
すごく、病的です…
1時間45ギガもあるともうちょっと圧縮してくれた方がいいようなきがする
音声は今の時代無圧縮のまま保存してるやつだって多いけど
さすがに映像を無圧縮や可逆で長期保存してるやつは病気だな。
HDD1PBあってあまって仕方がないとか言うならしょうがない。
さすがに映像を無圧縮や可逆で長期保存してるやつは病気だな。
HDD1PBあってあまって仕方がないとか言うならしょうがない。
＞さすがに映像を無圧縮や可逆で長期保存してるやつは病気だな。
んな奴いるわけねーべ
んな奴いるわけねーべ
('A`)ｲﾛｲﾛﾏﾁｶﾞｴﾀ・・・ｺﾞﾒﾝﾈ
怒りは非可逆圧縮で最小に
素材は非可逆のまま置いておくことはある
>>513
それ普通じゃね？
それ普通じゃね？
>>513
普通だな
普通だな
test
>>516
testだな
testだな
test1.avi
test2.avi
test3.avi
test2.avi
test3.avi
omanko
Huffyuvマルチスレッドコーデックで特定の番組のキャプチャが
TMPGEncでのエンコード中に高確率でエラー吐いてバッチが
落ちる症状が出てましたが、
ぐぐって最新版入手して切り替えたら、どうやら落ちなくなってくれたようです。
キャプチャ時の容量も二割くらい少なくなってますな。
これなら早くバージョン上げりゃ良かった。ありがたやありがたや。
TMPGEncでのエンコード中に高確率でエラー吐いてバッチが
落ちる症状が出てましたが、
ぐぐって最新版入手して切り替えたら、どうやら落ちなくなってくれたようです。
キャプチャ時の容量も二割くらい少なくなってますな。
これなら早くバージョン上げりゃ良かった。ありがたやありがたや。
なんだかんだでLagarith Lossless Video Codecが一番だとわかった
くすのきHDTVでキャプってるけど、鬱ビデオ使ってると
たまに音声だけで映像がキャプれてないってことがあるから、HuffyuvMTに落ち着いた
たまに音声だけで映像がキャプれてないってことがあるから、HuffyuvMTに落ち着いた
くすのきTVHDだと思ってた
utvideoもylcもTMPGEncの編集作業中フリーズして強制終了しないといけなくなることが多々ある
だから私はLagarithかHuffyuv
だから私はLagarithかHuffyuv
UtVideoもバージョン4.02で今のところ止まってるよな
加速度的なバージョンアップのときはこのスレも賑わっていたのに
やっぱりいろいろ面倒なんでしょうかね
加速度的なバージョンアップのときはこのスレも賑わっていたのに
やっぱりいろいろ面倒なんでしょうかね
新しいアルゴリズムがどうとか言ってたような・・・
まぁ利用者は気長に待つべきかな
まぁ利用者は気長に待つべきかな
tmpgで編集するとひっかかったり
utvideo→他の形式にエンコした動画のシークでひっかかるとか
あるね。
huffyuvではいずれも問題なし。
utvideo→他の形式にエンコした動画のシークでひっかかるとか
あるね。
huffyuvではいずれも問題なし。
それ根本的にどっかおかしいだろ。
うん、そうだね
根本的におかしいね
お前の頭がｗ
根本的におかしいね
お前の頭がｗ
どんだけ沸点低いんだ
21日にUtVideoの進展があったようだが、その後の日記はアイマス
まあユーザーとしては気長に待つかな
まあユーザーとしては気長に待つかな
PremiereからAviUtlへの中間CodecにYLC使ってるんだけど、
AviUtlで他の形式(MP4とか)に書き出すときに例外が起きない？
継続させればファイルはできあがるんだけどなんか気分悪い・・・
AviUtlで他の形式(MP4とか)に書き出すときに例外が起きない？
継続させればファイルはできあがるんだけどなんか気分悪い・・・
Version 1.3.18
>>535
ぉ、あがったのか
ぉ、あがったのか
>>535
何が？
何が？
>>537
Lagarith Lossless Video Codec
Lagarith Lossless Video Codec
はじめて入れてみたがいきなりマルチスレッド対応なのな
エンコードよりデコードのほうが負荷高い
エンコードよりデコードのほうが負荷高い
だからなんだよ
家はマルチスレッドの設定自分でチェックしたぞ
初期設定はオフだったｗ
家はマルチスレッドの設定自分でチェックしたぞ
初期設定はオフだったｗ
普通、ソフトの初期設定は一番弱い環境を想定して作りこんでおくもんだし、
それでいいんじゃね？
それでいいんじゃね？
Lagarithのマルチスレッドってバグ持ちだからチェックしない方が
良いとかいうのは直ったの？
良いとかいうのは直ったの？
543 ：名無しさん＠編集中：2008/08/28(木) 12:56:02 ID:1e5DX82/
マルチお断りｗって言われた
>>542
結構前に直ってるんで問題ないよ
結構前に直ってるんで問題ないよ
Huffyuv v2.1.1 CCE SP-Patchってなに？
普通の2.1.1よりも凄いの？
普通の2.1.1よりも凄いの？
ってかこのサイトH.264 losslessもテストしてほしいな
>>522
激亀レスで申し訳ないが、うちはHuffyuvでも起こる。
くすのきHDTV起動させっぱなしで録画開始→録画停止を繰り返すと起きる気がするんで
録画毎にくすのき再起動で対応してる
今のところこれで音のみにはなっていないが…
どこかおかしいんだろか
激亀レスで申し訳ないが、うちはHuffyuvでも起こる。
くすのきHDTV起動させっぱなしで録画開始→録画停止を繰り返すと起きる気がするんで
録画毎にくすのき再起動で対応してる
今のところこれで音のみにはなっていないが…
どこかおかしいんだろか
くすのきTVHDだと思ってた
549 名無しさん＠編集中 sage 2008/08/29(金) 13:38:45 ID:ocpUei2h
>>522
激亀レスで申し訳ないが、うちはHuffyuvでも起こる。
くすのきHDTV起動させっぱなしで録画開始→録画停止を繰り返すと起きる気がするんで
録画毎にくすのき再起動で対応してる
今のところこれで音のみにはなっていないが…
どこかおかしいんだろか
550 名無しさん＠編集中 sage New! 2008/08/29(金) 16:17:13 ID:OU/Kk8fK
くすのきTVHDだと思ってた
この流れにデジャヴを感じるんだが・・・何故だろう・・・
>>522
激亀レスで申し訳ないが、うちはHuffyuvでも起こる。
くすのきHDTV起動させっぱなしで録画開始→録画停止を繰り返すと起きる気がするんで
録画毎にくすのき再起動で対応してる
今のところこれで音のみにはなっていないが…
どこかおかしいんだろか
550 名無しさん＠編集中 sage New! 2008/08/29(金) 16:17:13 ID:OU/Kk8fK
くすのきTVHDだと思ってた
この流れにデジャヴを感じるんだが・・・何故だろう・・・
もうすぐリセットされるからね
UtVideoの作者様
avs2aviで使えるようにしていただけませんでしょうか。
avs2aviで使えるようにしていただけませんでしょうか。
失礼いたしました色空間の問題でした。
YV12にも対応していただくことをお願いできますでしょうか。
ソースから最終までYV12で一括可能になるとさらに速度的にも
便利かと思いまして。
YV12にも対応していただくことをお願いできますでしょうか。
ソースから最終までYV12で一括可能になるとさらに速度的にも
便利かと思いまして。
よくみたらHPにかいてありました・・・。
すみません。
すみません。
とりあえず落ち着け…
ソースがYV12ってダウソ厨かリップ厨だからスルーな
【審議中】
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・｀) ∧∧
( ´・ω) Ｕ) ( つと ﾉ(ω・｀ )
｜ Ｕ ( ´・) (・｀ ) と ﾉ
ｕ-ｕ （l ) ( ﾉu-ｕ
`ｕ-ｕ'. `ｕ-u'
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・｀) ∧∧
( ´・ω) Ｕ) ( つと ﾉ(ω・｀ )
｜ Ｕ ( ´・) (・｀ ) と ﾉ
ｕ-ｕ （l ) ( ﾉu-ｕ
`ｕ-ｕ'. `ｕ-u'
逆に今時YUY2のソースってのがなんなのか知りたい・・・。
MPEG-2ソースならふつーに4:2:2だろうが
…
Aviutlに騙されてる奴大杉
意味不明
まあ馬鹿はほっといて、俺もYV12対応をwktkしながら待っている
圧縮率はHuffyuv程度まで落ちてもいいから、エンコード、デコードの速いのが欲しい
Lagarithはやっぱデコード遅いよ
圧縮率はHuffyuv程度まで落ちてもいいから、エンコード、デコードの速いのが欲しい
Lagarithはやっぱデコード遅いよ
そんなこといったらCanopusのコーデックもHuffyuvとかもYUY2だな。
YV12だとインターレースの問題があるからYUY2の方が都合がいい。
ところでLagarithのYV12ってインターレースはちゃんと処理できてるのか？
オプションで切り替えるとかは出来ないようだけど。
YV12だとインターレースの問題があるからYUY2の方が都合がいい。
ところでLagarithのYV12ってインターレースはちゃんと処理できてるのか？
オプションで切り替えるとかは出来ないようだけど。
UtVideoの作者がんばれワッショイ！
ワッショイ！
ワショーイ
ワショショイ
utの人のところのアンケート
* 横幅が 8 の倍数でなければならないという制約をつけたとして、どれくらい困りますか？
* 同様に 16 の倍数（360が対象外になる）だとどうですか？
* 同様に 32 の倍数（360と720が対象外になる）だとどうですか？
8は問題ないとして16・32もまあ多少気になるけどいいか。
前のバージョンも別に残せるなら特に問題にはならない気はするし。
大体でもどのくらい差が出るのかわかれば答えやすいけどね。
* 横幅が 8 の倍数でなければならないという制約をつけたとして、どれくらい困りますか？
* 同様に 16 の倍数（360が対象外になる）だとどうですか？
* 同様に 32 の倍数（360と720が対象外になる）だとどうですか？
8は問題ないとして16・32もまあ多少気になるけどいいか。
前のバージョンも別に残せるなら特に問題にはならない気はするし。
大体でもどのくらい差が出るのかわかれば答えやすいけどね。
モードを選べるようにしれ
俺が悪かった
396ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
まぁ上下にボーダーつけて400にすりゃ済む話だし8倍制限でいいと思うけどね
まぁ上下にボーダーつけて400にすりゃ済む話だし8倍制限でいいと思うけどね
やっぱその制約でどれくらいエンコ/デコード速度と圧縮率に違いが出るか次第だなぁ
あまり違いがないようならx8でいいけど、かなり違ってくるようならx32でもいい
中間出力するときに黒帯つけて、中間からのエンコの時に黒帯部分を削除すれば良いだけだし
あまり違いがないようならx8でいいけど、かなり違ってくるようならx32でもいい
中間出力するときに黒帯つけて、中間からのエンコの時に黒帯部分を削除すれば良いだけだし
追記：
制約を入れたいメインの理由は「汚いコードをメンテしたくない」なので、モードを分けて制約から外れるものも残す、というのは全く意味がありません。
制約を入れたいメインの理由は「汚いコードをメンテしたくない」なので、モードを分けて制約から外れるものも残す、というのは全く意味がありません。
>>577
ですね。どのくらい違うのかを明記してくれればアンケートにも答えやすいな
ですね。どのくらい違うのかを明記してくれればアンケートにも答えやすいな
x8はよいけど地デジ4:3の場合は1080x1080にCropして（中間ファイル）から4:3にリサイズだから
16以上は困る・・・。
16以上は困る・・・。
制限がMod 8 以上になるのは困るな
理由はD3キャプチャに使っているから
理由はD3キャプチャに使っているから
個人的にUtVideo作者には現状の改良よりインタレ対応のYV12版を期待してる
>>572
私が作るなら「YUY2 の幅 2 の倍数制限以上の制約はつけない」を選ぶかな。
多分 SIMD コードがらみなんだろうけど、X の倍数部分と端数部分のコード
書くだけで済むし、「エンコード/キャプチャ/中間出力しようとしたら落ち
ました何がいけないのでしょうか」とかのウザイ質問に煩わされたくないから。
私が作るなら「YUY2 の幅 2 の倍数制限以上の制約はつけない」を選ぶかな。
多分 SIMD コードがらみなんだろうけど、X の倍数部分と端数部分のコード
書くだけで済むし、「エンコード/キャプチャ/中間出力しようとしたら落ち
ました何がいけないのでしょうか」とかのウザイ質問に煩わされたくないから。
つーかLagarithで事足りね？
>584
遅いんだよ。
遅いんだよ。
そしてHuffyuvがもっとも楽であるという結論にたった
>>584
色ノイズも出るし
色ノイズも出るし
WMAの可逆圧縮に対応したポータブルプレイヤーってないの？
アンケートに答えてなかった
可逆で横360はあまり意味をなさないような気もするから、x16制限がいいかなぁ
まぁ可読性・性能ともに劇的に変わるんでなければあんまりきつい制限はないほうがいいのかも
可逆で横360はあまり意味をなさないような気もするから、x16制限がいいかなぁ
まぁ可読性・性能ともに劇的に変わるんでなければあんまりきつい制限はないほうがいいのかも
非可逆スレにもたまには顔を出してくれ。
nVidiaのBadaboom、完成されれば良いものになりそう。
nVidiaのBadaboom、完成されれば良いものになりそう。
x8とかx16制限とか訳分からん
内部処理ではx8とかx16で処理して(満たないものはダミーデータを付加)、
外部からは隠蔽するだけとちゃうんかいね？
つーか、そういった柔軟な発想もできんのかね、あの作者は
まあ、ソースコード見る限り、プログラム技術はたかが知れてるが
内部処理ではx8とかx16で処理して(満たないものはダミーデータを付加)、
外部からは隠蔽するだけとちゃうんかいね？
つーか、そういった柔軟な発想もできんのかね、あの作者は
まあ、ソースコード見る限り、プログラム技術はたかが知れてるが
じゃあお前がやれ
今更口だけって奴が来るのも珍しいな。昔は多かったが。
DCT変換するやつはそういうことをやってるやつも多いが俺はやれとまでは思ってない。
端数あるせいで(わずかながら)符号化効率下がるしな。
端数あるせいで(わずかながら)符号化効率下がるしな。
最終的にx264でエンコするので、それに合わせて16の倍数に1票。
SSEも16バイト単位だしなんかきりいい感じがする。
（いや、x264自体は8とか4の倍数でもいけるよ、警告されるけど）
SSEも16バイト単位だしなんかきりいい感じがする。
（いや、x264自体は8とか4の倍数でもいけるよ、警告されるけど）
3の倍数の時だけ
huffyuv_mtがこのスレに登場してすぐに落として使っていたんだけど
マルチスレッドのチェックがあった事を最近気づいた。
速い速い・・・・
マルチスレッドのチェックがあった事を最近気づいた。
速い速い・・・・
いや・・・HDDが限界なんだからRAIDでもない限り速くないだろ
そんなの環境によりけり
>>600
自分の糞環境をさらしても何もならんと思うがw
自分の糞環境をさらしても何もならんと思うがw
,r;;;;ﾐﾐﾐﾐﾐﾐヽ,,_
,i':r" ＋ `ﾐ;;,
__,､ ≡ 彡 ﾐ;;;i
〃ﾆ;;::`lヽ,,_ ≡ 彡 ,,,,,、 ,,,,､､ ﾐ;;;!
〈 (lll!! ﾃ-;;;;ﾞfn __,,--､_ .. ,ゞi"￣ ﾌ‐!￣~~|-ゞ, ≡
／ヽ-〃;;;;;;;llllll7,,__／" ＼三=ー"."ヾi `ー‐'､ ,ゝ--､' 〉;r' ≡
>､/:::/＜;;;lllメ ＼ヾ、 ヽTf=ヽ `,| / "ii" ヽ |ﾉ
j,, ヾて）r=- | ヾ: :ヽ;;: | l | l ''t ←―→ ）/ｲ^ ≡ 私は、自分自身を客観的に見れるんです。あなたと違うんです。
,ｲ ヽ二)l(_,＞" l| ::＼;:: | | | ヽ,,-‐、i' ／ V
i、ヽ--ｲll"/ ,, ,//,, :;; l // l く> /::l"'i::lll1-=::::￣＼
ヾ＝=:"::^::;;:::／;;;;;;;;;:::::::::::::: :::::ゞ ﾉ/ L／〈:::t_ｲ::/ll|─-=＝ ヾ
＼__::::::::／::::::::::::＿;;;;;;;;;;;;;;;;;ノノ ﾍ >(ﾞ ）l:::l-┴ヾ、ヽ ）
￣~~￣￣／ :::|T==--::::: ／／ / ﾄ=-|:|-─ （ l /
／ :: ::l l::::::::::::::::::/ /:::::::::::/:::::(ヽ--─ / | /
ヽ＿=--"⌒￣ﾞﾞヾ:/ /:::::::／:::::::::`<==-- ﾉ / /
,i':r" ＋ `ﾐ;;,
__,､ ≡ 彡 ﾐ;;;i
〃ﾆ;;::`lヽ,,_ ≡ 彡 ,,,,,、 ,,,,､､ ﾐ;;;!
〈 (lll!! ﾃ-;;;;ﾞfn __,,--､_ .. ,ゞi"￣ ﾌ‐!￣~~|-ゞ, ≡
／ヽ-〃;;;;;;;llllll7,,__／" ＼三=ー"."ヾi `ー‐'､ ,ゝ--､' 〉;r' ≡
>､/:::/＜;;;lllメ ＼ヾ、 ヽTf=ヽ `,| / "ii" ヽ |ﾉ
j,, ヾて）r=- | ヾ: :ヽ;;: | l | l ''t ←―→ ）/ｲ^ ≡ 私は、自分自身を客観的に見れるんです。あなたと違うんです。
,ｲ ヽ二)l(_,＞" l| ::＼;:: | | | ヽ,,-‐、i' ／ V
i、ヽ--ｲll"/ ,, ,//,, :;; l // l く> /::l"'i::lll1-=::::￣＼
ヾ＝=:"::^::;;:::／;;;;;;;;;:::::::::::::: :::::ゞ ﾉ/ L／〈:::t_ｲ::/ll|─-=＝ ヾ
＼__::::::::／::::::::::::＿;;;;;;;;;;;;;;;;;ノノ ﾍ >(ﾞ ）l:::l-┴ヾ、ヽ ）
￣~~￣￣／ :::|T==--::::: ／／ / ﾄ=-|:|-─ （ l /
／ :: ::l l::::::::::::::::::/ /:::::::::::/:::::(ヽ--─ / | /
ヽ＿=--"⌒￣ﾞﾞヾ:/ /:::::::／:::::::::`<==-- ﾉ / /
>>603
お疲れ様
お疲れ様
[UtVideo] バージョン 4.1.0
性能向上
共通: エンコードをほんのわずかだけ高速化した。
共通: デコードをほんのわずかだけ高速化した。
ｷﾀｰｰｰｰｰｰｰｰｰｰ
性能向上
共通: エンコードをほんのわずかだけ高速化した。
共通: デコードをほんのわずかだけ高速化した。
ｷﾀｰｰｰｰｰｰｰｰｰｰ
>605
地味だがすばらしい改良。
YV12頼む！
地味だがすばらしい改良。
YV12頼む！
で、圧縮率は上がったのか？
＞共通: エンコードをほんのわずかだけ高速化した。
＞共通: デコードをほんのわずかだけ高速化した。
＞共通: デコードをほんのわずかだけ高速化した。
アマレココのページに「AMV2がYUY2可逆圧縮で最速、展開も速いです」
なんて記事が載ってる･･･。実際どうなんだろ。
なんて記事が載ってる･･･。実際どうなんだろ。
610 ：名無しさん＠編集中：2008/09/17(水) 01:58:25 ID:ctUyz1E6
今んとこ圧縮率と速度のバランスが取れてるLagarithの一人勝ち
Lagarithが一番
ちょっと重いけどUtよりまし
ちょっと重いけどUtよりまし
あと一歩だな
一通り試した後、結局無圧縮に戻る。
HDDには容量と速度というものがあってね
速度重視でhuffyuv
LCL削除の仕方わからなくてイライラ
2chから世界最強の可逆コーデックが発信されると信じて疑わない時期が私にはありました
鬱はノイズが入ってくるからおいらは今日もhuffyuv!!
PremiereとHuffyuvの相性がよろしくないので色んな可逆が出てくるのは大歓迎だ。
>618
UtVideoのバグってこと？
詳しく。
UtVideoのバグってこと？
詳しく。
多分プレミアとの相性だと思うよ。
作者がやってるのか知らんがあちこち張られまくってて若干うざい
シェアウェアだから買うのが嫌だけどどんなもんか知りたい
聞く前に最低限のことぐらい調べろ。
金払わないとロゴが入るだけで金払わなくても使える。
だから自分で使ってみて考えろ。
どうせPC環境も用途も人によってばらついて、
何がいいかなんて変わるんだからな。
金払わないとロゴが入るだけで金払わなくても使える。
だから自分で使ってみて考えろ。
どうせPC環境も用途も人によってばらついて、
何がいいかなんて変わるんだからな。
627 ：sage：2008/09/21(日) 09:18:12 ID:Dbxw0WnN
次のような条件では、どの可逆圧縮コーデックを使うのがいいでしょうか？
映像ソース：VHSとLD、ジャンルは実写映画とアニメ。60時間分ぐらいの量。
目的：可逆圧縮で永久保存。映像のマスターソースとして保存。
自分で調べた限りだと、圧縮率と軽さのバランスのよさからLagarithが
良いようですが、前スレから目を通していると、ノイズが出る報告があるので
使うのが心配です。
映像のマスターソースにしたいので、60時間分もノイズがないか
意識して調べるのはつらすぎます。
バグが少なく安心して使えるコーデックを教えてください。
映像ソース：VHSとLD、ジャンルは実写映画とアニメ。60時間分ぐらいの量。
目的：可逆圧縮で永久保存。映像のマスターソースとして保存。
自分で調べた限りだと、圧縮率と軽さのバランスのよさからLagarithが
良いようですが、前スレから目を通していると、ノイズが出る報告があるので
使うのが心配です。
映像のマスターソースにしたいので、60時間分もノイズがないか
意識して調べるのはつらすぎます。
バグが少なく安心して使えるコーデックを教えてください。
>>627
マスターにしたいなら全編チェックするもんだ。
マスターにしたいなら全編チェックするもんだ。
>>627
永久保存ならオープンソースだな。
永久保存ならオープンソースだな。
>>627
安心のhuffyuvか、新鋭のUtVideoかな。
安心のhuffyuvか、新鋭のUtVideoかな。
新鋭ｗ
こんなもんに何を期待するんだｗ
こんなもんに何を期待するんだｗ
開発者が2ちゃんに書き込むとロクなことにならないよ
>>620
noiseがはいるのは別にプレミアってことではない。てかプレミアは使わない。確認できたのは、HSL中のSとH
ぶつぶつ入ってくる。AE TMPGenc aviutlどれでも出た。lagarithも出る。huffyuvはでない！
noiseがはいるのは別にプレミアってことではない。てかプレミアは使わない。確認できたのは、HSL中のSとH
ぶつぶつ入ってくる。AE TMPGenc aviutlどれでも出た。lagarithも出る。huffyuvはでない！
>634
詳しく整理して作者に伝えてもらえないだろうか。
場合によっては可逆圧縮として致命的だし。
詳しく整理して作者に伝えてもらえないだろうか。
場合によっては可逆圧縮として致命的だし。
>>635
ただの煽りにお願いしてどうするよw
ただの煽りにお願いしてどうするよw
煽ってない、作者が気づいて直せそうor興味を持ったらぜひやってほしい。
てか非圧縮と可逆圧縮ごを誰でもいい、みんな比較してみん。絶対入るから。
HSL(V),LBA,CMY,RGB(これじゃあんまし解らないかも)とか
てか非圧縮と可逆圧縮ごを誰でもいい、みんな比較してみん。絶対入るから。
HSL(V),LBA,CMY,RGB(これじゃあんまし解らないかも)とか
youはまずjapanese
634が言いたいことを要約すると・・
UtVideo、Legarithに共通して、
AfterEfects、TMPGEnc、Aviutlの全てでHSLの中のSとHにノイズと思われるものが混入していたと。
HSLとは色の成分の種類ということでおｋ？
HSLとかCMYKとかRGBとかフォトショで確か扱えたやつだったか・・。
UtVideo、Legarithに共通して、
AfterEfects、TMPGEnc、Aviutlの全てでHSLの中のSとHにノイズと思われるものが混入していたと。
HSLとは色の成分の種類ということでおｋ？
HSLとかCMYKとかRGBとかフォトショで確か扱えたやつだったか・・。
HuffyuvからUtに乗り換えた口だが、
確かにちょっとモスキートノイズみたいなざわついたノイズがちょっと多いかなーみたいな印象はある。
それがそのノイズの事を指しているのかわからないけれど。
確かにちょっとモスキートノイズみたいなざわついたノイズがちょっと多いかなーみたいな印象はある。
それがそのノイズの事を指しているのかわからないけれど。
可逆ではなかった疑惑
無圧縮のキャプも並べてくれよと
ソースYUY2でVirtualDubとTMpgで吐き出した
UtとHuffyuvをavisynth経由でAvspでスクショとったbmpのハッシュ一致。
AviUtlで開いて以下同文もハッシュ一致。
UtとHuffyuvをavisynth経由でAvspでスクショとったbmpのハッシュ一致。
AviUtlで開いて以下同文もハッシュ一致。
だから色空間のなんたるかもわかってないやつのくだらん煽りに反応するなよ
>645
もしかしてということはあるから検証は必要でしょ。
少なくとも今まで正確に検証した人はほとんどいなかったみたいだし。
特定のシーンだけノイズがのる（overflowおこすとか）とかあるかもしれないから
こっちでも検証してみようと思う。
もしかしてということはあるから検証は必要でしょ。
少なくとも今まで正確に検証した人はほとんどいなかったみたいだし。
特定のシーンだけノイズがのる（overflowおこすとか）とかあるかもしれないから
こっちでも検証してみようと思う。
とっくの昔に検証はしてるでしょ・・・でないと使えないし
YUY2において10個ほどのサンプルでPSNR、SSIM検証した結果は差異は見られなかった
YUY2において10個ほどのサンプルでPSNR、SSIM検証した結果は差異は見られなかった
この所のスレの流れを見て、可逆圧縮について実験してみた。
(a)無圧縮(RGB24bit)のAVIファイル
(b)Huffyuv v2.1.1で圧縮したAVIファイル
(a)と(b)の間では相互に変換できて、
変換を繰り返してもファイルは劣化せずバイナリは一致するはず、と仮定して
(a1)→(b1)→(a2)→(b2)→(a3) と変換してファイルを作成した。
(a1)(a2)(a3)とできた無圧縮ファイルは、ファイルサイズは完全に一致するが
fc /bでバイナリ比較すると微妙に違う。
10と11とか、BFとC0とか、1ビットだけデータが違う。
テストした環境は、AviUtl 0.99fとHuffyuv v2.1.1。
AviUtlはインストールした直後の状態でプラグインはいれていない。
フィルターも使っていない。デフォルト設定のまま。
Huffyuvの設定は、圧縮率を(fastest)～(best)までかえて実験したが
結果は同じだった。
正直、自分でも信じられない。
どこか設定を間違っていると思うので指摘してください。
仮定が間違っているのか？
(a)無圧縮(RGB24bit)のAVIファイル
(b)Huffyuv v2.1.1で圧縮したAVIファイル
(a)と(b)の間では相互に変換できて、
変換を繰り返してもファイルは劣化せずバイナリは一致するはず、と仮定して
(a1)→(b1)→(a2)→(b2)→(a3) と変換してファイルを作成した。
(a1)(a2)(a3)とできた無圧縮ファイルは、ファイルサイズは完全に一致するが
fc /bでバイナリ比較すると微妙に違う。
10と11とか、BFとC0とか、1ビットだけデータが違う。
テストした環境は、AviUtl 0.99fとHuffyuv v2.1.1。
AviUtlはインストールした直後の状態でプラグインはいれていない。
フィルターも使っていない。デフォルト設定のまま。
Huffyuvの設定は、圧縮率を(fastest)～(best)までかえて実験したが
結果は同じだった。
正直、自分でも信じられない。
どこか設定を間違っていると思うので指摘してください。
仮定が間違っているのか？
>>648
理由は色空間の変換誤差
理由は色空間の変換誤差
自虐なの？
色空間の変換誤差に対応できてないアピールですか？
色空間の変換誤差に対応できてないアピールですか？
ねえねえ丸め誤差ってしってる？
適当なこといって恥かかないようにね
適当なこといって恥かかないようにね
仕方がないからヒントをあげよう
Aviutlのコーデックの設定でHuffyuvのYUY2で展開・圧縮のチェックをはずして再起動、
でもって無圧縮動画をHuffyuvで出力。その際にRGB compression methodを
Convert to YUY2に"しない"。
これでもわからんのなら出直してきたほうがいい
Aviutlのコーデックの設定でHuffyuvのYUY2で展開・圧縮のチェックをはずして再起動、
でもって無圧縮動画をHuffyuvで出力。その際にRGB compression methodを
Convert to YUY2に"しない"。
これでもわからんのなら出直してきたほうがいい
653 ：名無しさん＠編集中：2008/09/23(火) 12:56:02 ID:yXI1noOE
>>649
>>652
ありがとう。
標準の設定だと、コーデックに対してYUY2読み書きするようになっているのでした。
RGB→YUY2→RGBなら誤差も出るよね。
ttp://jumper-x.hp.infoseek.co.jp/begin/1aviutl/4/index.html
ここ見てコーデック側への設定がたりないことに気づきました。
fc /Bしても差異のないファイルが出来ました。
ありがとうございました。
>>652
ありがとう。
標準の設定だと、コーデックに対してYUY2読み書きするようになっているのでした。
RGB→YUY2→RGBなら誤差も出るよね。
ttp://jumper-x.hp.infoseek.co.jp/begin/1aviutl/4/index.html
ここ見てコーデック側への設定がたりないことに気づきました。
fc /Bしても差異のないファイルが出来ました。
ありがとうございました。
なんで、huffyuvはでないっていうはなしで、huffyuvの検証してるの？
他のコーデックの検証しなきゃ意味無いじゃん
他のコーデックの検証しなきゃ意味無いじゃん
ここはUtvideoだけを応援するスレです。他はカス
ID:deY/4Ael
うけるｗ
うけるｗ
657 ：名無しさん＠編集中：2008/09/23(火) 19:03:50 ID:w3aDEOVs
Lagarith1.3.19
>654
全くだ。
全くだ。
検証した
無圧縮、huffyuv2.1.1、huffyuv2.1.1multithredingpacthv1.0、Lagarith1.3.19、utVideo4.1.0でYUY2とRGB24で書き出して、
PSNR測定ソフト（MSU Video Quality Measurement Tool）でRGBものはR、G、BでYUY2ものはY、U、Vそれぞれの項目でで全フレーム100db（∞）張り付きを確認した
つまり俺の環境では全くノイズの混入は認められなかった。
（サンプルはNHK-hiをMonsterXでhuffyuvでキャプしたもの50フレーム。それをVDでそれぞれの色空間で書き出しして検証）
RGBAについてはうちではそんな使いかたしないので使う人が検証してくださいな
無圧縮、huffyuv2.1.1、huffyuv2.1.1multithredingpacthv1.0、Lagarith1.3.19、utVideo4.1.0でYUY2とRGB24で書き出して、
PSNR測定ソフト（MSU Video Quality Measurement Tool）でRGBものはR、G、BでYUY2ものはY、U、Vそれぞれの項目でで全フレーム100db（∞）張り付きを確認した
つまり俺の環境では全くノイズの混入は認められなかった。
（サンプルはNHK-hiをMonsterXでhuffyuvでキャプしたもの50フレーム。それをVDでそれぞれの色空間で書き出しして検証）
RGBAについてはうちではそんな使いかたしないので使う人が検証してくださいな
色空間を解ってないとか言われるとムカつくんですが？言葉が足らなかったから？
では付け足しで、全部RGB24下で試した。XENAっていう非圧縮で取り込める機械を使いました。知ってる人は知ってるよね？
そこから主要な可逆圧縮を試した。可逆(キャプ含み)→可逆とかした結果ではありません。
また、HLS HSVはPSにはないと思うよ。自分とこの環境依存かもしれないから、同じ設備で誰かやっていただけませんかね・・・。
個人的にAEからの吐き出しが気になります。
あと、皆さんすみません。荒れさせるつもりはありませんでした。気になっていたのでほかの方の環境下ではって言うのが知りたかったというのが本音のスレでした。
では付け足しで、全部RGB24下で試した。XENAっていう非圧縮で取り込める機械を使いました。知ってる人は知ってるよね？
そこから主要な可逆圧縮を試した。可逆(キャプ含み)→可逆とかした結果ではありません。
また、HLS HSVはPSにはないと思うよ。自分とこの環境依存かもしれないから、同じ設備で誰かやっていただけませんかね・・・。
個人的にAEからの吐き出しが気になります。
あと、皆さんすみません。荒れさせるつもりはありませんでした。気になっていたのでほかの方の環境下ではって言うのが知りたかったというのが本音のスレでした。
まあまあ、落ち着いて。
まったく別のCodecの話だと思ったけどAMDだと不具合出るとか、確かに
あり得る話。
環境依存だろうが、可逆圧縮で完全一致しなかったら問題だし。
まったく別のCodecの話だと思ったけどAMDだと不具合出るとか、確かに
あり得る話。
環境依存だろうが、可逆圧縮で完全一致しなかったら問題だし。
AMDだと可逆じゃなくなる疑惑
使うフロントエンドで出たり出なかったりって何度もループしてる話題でしょ
665 ：名無しさん＠編集中：2008/09/25(木) 03:11:41 ID:bwSfp4Jz
みんなが同じ環境じゃないし気違いの相手して遊ぶのも程々にしとけお前らｗ
だってutの更新もないしヒマなんだもん
>>666
ですよね～
ですよね～
んだんだ。
YV12対応だけでもお願いしたい。
YV12対応だけでもお願いしたい。
64bit版作ったところで対応アプリは存在するのか…？
というかそもそもVCMは64bitコードで使えるのだろうか。調べてない。
YV12は進行中ですが遅々として進まず、です。
コメント by 梅澤 威志
というかそもそもVCMは64bitコードで使えるのだろうか。調べてない。
YV12は進行中ですが遅々として進まず、です。
コメント by 梅澤 威志
対応アプリってｗ
wavpackってx1とx6だとx6の方が圧縮率が良いんですよね？
>669
くじけずがんばれ！
YV12はすごそこだ！
くじけずがんばれ！
YV12はすごそこだ！
のんびりでも良い、皆が忘れても良い
いつかでいいからYV12をひっそりと待たせて頂きます
いつかでいいからYV12をひっそりと待たせて頂きます
アニメ録画ならYLCの圧縮率が良い
実写だとYLCはアホみたいに膨らむ
実写だとYLCはアホみたいに膨らむ
アマレコ作者のベンチマークによるとアマレコ最強らしいな
アマレコは非可逆です
可逆と非可逆選べるんだろ？
ま、実際そうなのかについては自分では調べてないけど。
なんつーか今回はめずらしくAMDに向いたコーデックだったって結論になるのかな。
売り物にするならIntelに向いたものに仕上げるほうがベターだとは思うがAMD使いなので喜ぶことにするｗ
ま、実際そうなのかについては自分では調べてないけど。
なんつーか今回はめずらしくAMDに向いたコーデックだったって結論になるのかな。
売り物にするならIntelに向いたものに仕上げるほうがベターだとは思うがAMD使いなので喜ぶことにするｗ
UtVideoのULRGをAthlon64X2 で使うと遅いらしいってことか。
ＡＭＤでエンコードが遅いってのは多少は気になるな。
原因が特定できればいいんだろうけど。
ＡＭＤでエンコードが遅いってのは多少は気になるな。
原因が特定できればいいんだろうけど。
Readmeに出てくる単語を見れば分かるように
UtVideoはCore2最適化だから
それ以外のCPUを使ってるとあまり恩恵が無いんだよね
完全にCore2専用のSSSE3やSSE4を使ってないから他のCPUでも使えるって程度で
UtVideoはCore2最適化だから
それ以外のCPUを使ってるとあまり恩恵が無いんだよね
完全にCore2専用のSSSE3やSSE4を使ってないから他のCPUでも使えるって程度で
AMD使いも多いだろうからAMDも見捨てないでください～ > UtVideo
IntelにもAMDにも両方強いというのは構造上むりなんかね
ほとんどのソフトがそうです
エンコにはIntel系がいいのはそのせいだったのか？
単にSIMDの性能がAthlonはそこまでよくないだけ。というかCoreが優秀すぎる。
多分AMD最適化してもAthlonがちょっと早くなるくらいでCoreと逆転することは無理だろう
多分AMD最適化してもAthlonがちょっと早くなるくらいでCoreと逆転することは無理だろう
SSE2あたりは1クロックあたりの命令実行数よりクロック自体を重視したPentiumにあわせて作ってるから
AthlonがSSE2を実行できるとしてもたいして効果が見込めないんだとか何とか。
ま、いまはCoreがね…
AthlonがSSE2を実行できるとしてもたいして効果が見込めないんだとか何とか。
ま、いまはCoreがね…
LagarithはYV12対応していてRGBとかの圧縮率もいいけどエンコ速度がイマイチなんだよな
UtVideoがYV12対応してくれれば最強なのに
UtVideoがYV12対応してくれれば最強なのに
Lagarithでh.264に変換した時、1時間の番組エンコで3時間かかったｗ
core2なのにorz
core2なのにorz
デコードが遅いんだよな
最終フォーマットがYV12なら、やっぱその手前のマスターもYV12にしといたほうが
エンコの効率はいいんだろうか？
>>634
今頃じゃ多分見てないだろうけど、新しくPC組んでみたら？もちろんCPUはIntelで
エンコの効率はいいんだろうか？
>>634
今頃じゃ多分見てないだろうけど、新しくPC組んでみたら？もちろんCPUはIntelで
話題ないな・・・
691 ：名無しさん＠編集中：2008/10/21(火) 13:46:49 ID:rMZc43d4
AMDつかいならAMV2なんじゃないの？
AMDのCPUもってないが・・・
AMDのCPUもってないが・・・
AMV2はIntelCPUにも最適化されたけどシェアウェアだからな
693 ：名無しさん＠編集中：2008/10/21(火) 19:27:31 ID:rMZc43d4
>>692
Intelに最適化されちゃうとAMDで使っちゃいけないわけじゃないでしょ
AMDのほうが早いかもよ？
公式のテストベンチは、まったく参考にならなくて笑う
それに、今ならにこ動あたりに一月動画載せればタダだよ
Intelに最適化されちゃうとAMDで使っちゃいけないわけじゃないでしょ
AMDのほうが早いかもよ？
公式のテストベンチは、まったく参考にならなくて笑う
それに、今ならにこ動あたりに一月動画載せればタダだよ
日本語でおｋ
>>694
ごめん、書いた後に日本語じゃないことに気づいた
ごめん、書いた後に日本語じゃないことに気づいた
huffyuvとUtVideoのYV12対応まだー？
huffyuvのYV12版ならffdshowに入ってるだろ
使ったことないからどんなもんか良く知らんけど
使ったことないからどんなもんか良く知らんけど
出来るわけねぇだろｗ
>>700が誰に対してのレスなのかさっぱりわかんない
Ｙ１２対応についてだろ
確かにY12=輝度12bitの超分解能にはだれも対応しないだろうな
ああ、分かった。ffdshowでエンコできないって思ってるわけか。気付くのに少し掛かったわｗ
何も分かってないなｗ
アマレココのってどんなんだろな？
>>706
コーデックは知らないが録画ソフトとしてはなかなかいいと思った
コーデックは知らないが録画ソフトとしてはなかなかいいと思った
Lagarithのサイト死んでる？
なんか、ここ数日、くすのきでやたらめったらドロップフレームが出て、キャプチャが失敗しまくってたけど、
BlackMagicSpeedTestを回したら直った？
活いれてHDDの勢いが戻るって一体…。
BlackMagicSpeedTestを回したら直った？
活いれてHDDの勢いが戻るって一体…。
と、思ったらまたドロップしました。
と、なると原因はバージョン挙げたTMPGenc4.0（4.3.267）を裏で回しているせいか？
と、なると原因はバージョン挙げたTMPGenc4.0（4.3.267）を裏で回しているせいか？
PCI-Eの帯域は足りてるか
PCI-Eに突き刺さってるのは、Geforce8800GTSとIntensity無印だけなんで余ってると思います。
さっき、TMPGencのバージョンを4.5.2.255に戻しても症状が治りませんでした。
G80コアが対応してないのに気がつかずにCUDAを試そうとしてバージョン上げたビデオドライバも
元に戻してみます…。
さっき、TMPGencのバージョンを4.5.2.255に戻しても症状が治りませんでした。
G80コアが対応してないのに気がつかずにCUDAを試そうとしてバージョン上げたビデオドライバも
元に戻してみます…。
追記
あ、TMPGenc止めても発生しております。
Seagate500GB×2でRAID0なんだけどなあ…。
あ、TMPGenc止めても発生しております。
Seagate500GB×2でRAID0なんだけどなあ…。
hunuaaでためす
ケーブル周り見直し
ケーブル周り見直し
いまふぬああで試してます。
さて、最後までのだめ巴里編がドロップフレーム無しで録れるかな？
さて、最後までのだめ巴里編がドロップフレーム無しで録れるかな？
DPC Latencyは大丈夫だよな？
>>714
ふぬああだと、Intensityのフィルタでフレーム計測出来ないので、
ドロップフレームが解りませんでした。
どうも編集済みを入れている250GB×2ドライブだと問題ないようで、
キャプチャを放り込む500GB×2だとドロップフレームが出る状態なのです。
ある時期まで問題ないのに急に発生したので、いろいろと調べてみたら、
なにやらキャプチャ用ドライブにむやみやたらとディスクアクセスが
発生しているようなので、ふと気になってタスクマネージャを見たら、
「CTHELPER.EXE」とか言う全部大文字の胡散臭いプログラムが…。
ひょっとして、これワーム？これのせい？
同名のファイルはサウンドブラスター関連のプログラムにあるけど、
とりあえず、タスクマネージャのプロセス上で止めて、対策プログラム回して
もう一回キャプチャを試してみます。
ふぬああだと、Intensityのフィルタでフレーム計測出来ないので、
ドロップフレームが解りませんでした。
どうも編集済みを入れている250GB×2ドライブだと問題ないようで、
キャプチャを放り込む500GB×2だとドロップフレームが出る状態なのです。
ある時期まで問題ないのに急に発生したので、いろいろと調べてみたら、
なにやらキャプチャ用ドライブにむやみやたらとディスクアクセスが
発生しているようなので、ふと気になってタスクマネージャを見たら、
「CTHELPER.EXE」とか言う全部大文字の胡散臭いプログラムが…。
ひょっとして、これワーム？これのせい？
同名のファイルはサウンドブラスター関連のプログラムにあるけど、
とりあえず、タスクマネージャのプロセス上で止めて、対策プログラム回して
もう一回キャプチャを試してみます。
x264とか進化し続けるけど可逆ってのは伸び代があまり無いのかしら
可逆は新しい技術注ぎ込むこともできるけど
負荷と速度のバランスがあるから難しいかと
負荷と速度のバランスがあるから難しいかと
>>717
いろんなとこで相性問題でてるからSB関連の常駐は全部切れ。
はっきり言ってぜんぜん必要じゃない。
スレ違いになるがオーディオコンソールを使っているなら
Creative Audio Engine Licensing Serviceだけは要る。
いろんなとこで相性問題でてるからSB関連の常駐は全部切れ。
はっきり言ってぜんぜん必要じゃない。
スレ違いになるがオーディオコンソールを使っているなら
Creative Audio Engine Licensing Serviceだけは要る。
HDカメラもTSで録画してTSのまま保存できてテレビもTSをそのまま
可逆は外部入力のゲームキャプやデスクトップキャプぐらいしか用途がなくなった
可逆は外部入力のゲームキャプやデスクトップキャプぐらいしか用途がなくなった
UtVideoに進展あり
のんびり見守らせていただきます
のんびり見守らせていただきます
鬱ビデオの作者ってもしかして女性？
まさか体型の話が出たから言ったとかじゃなかろうなｗ
男性だよ
UtVideoはAMDシステムで遅くなる不具合直してほしい
あと64bit版が欲しい
>>724-725
失望した。
失望した。
>>727
vista64bitで使ってるよ
vista64bitで使ってるよ
VISTA64bitで使えるのはわかってるけど32bitでしょ
dub64bit版で中間ファイルの編集に使いたいのよ
だから64bit版が欲しい
dub64bit版で中間ファイルの編集に使いたいのよ
だから64bit版が欲しい
64bitだとアセンブラ書き直しじゃない？検証もしんどいし
さすがにそこまで求めるのは酷かもね
だれか奇特な人がソースを弄ってくれるなら別だけど
さすがにそこまで求めるのは酷かもね
だれか奇特な人がソースを弄ってくれるなら別だけど
いずれは64bitなんてみなが知ってること
それを酷だとかなんだとか文句言うぐらいならはじめから作らなきゃいい
フリーだから義務も責任もないとかいい加減すぎる
少なくともプログラマーとして仕事してる人はそんないい加減な気持ちじゃできない
それを酷だとかなんだとか文句言うぐらいならはじめから作らなきゃいい
フリーだから義務も責任もないとかいい加減すぎる
少なくともプログラマーとして仕事してる人はそんないい加減な気持ちじゃできない
そしてUt Video Codec Suiteは一人のクレーマーの手によって消し去られてしまうのだった。
さすがに釣れないな。
つーかその辺の要望は本当に要求してるんだった作者のブログに書いて来い。
>>730のは少なくとも理由として通るものだろうし。
ダメならダメで奇数解像度のように切り捨てられるだけだ。
さすがに釣れないな。
つーかその辺の要望は本当に要求してるんだった作者のブログに書いて来い。
>>730のは少なくとも理由として通るものだろうし。
ダメならダメで奇数解像度のように切り捨てられるだけだ。
最近64ビットはこのまま普及しないんじゃないかと思い始めた俺がいる
32ビットをずるずる続けたあと、いきなり128に飛んだりしないだろうか？
32ビットをずるずる続けたあと、いきなり128に飛んだりしないだろうか？
Windowsが無くならない限り32bitも無くならないだろうね
そしてWindowsが無くならないなんて考えているとしたら
少しは歴史から学んだ方がいいだろうね
そしてWindowsが無くならないなんて考えているとしたら
少しは歴史から学んだ方がいいだろうね
windowsも32bitはそのうちやめるっつーの
32bitはwindows7までって言ってるし
32bitはwindows7までって言ってるし
じゃあおまえ作ればいいじゃん勉強でも何でもしてさ
俺は他人の作った物を使うだけだから
「PGはこうあるべき」までは言えないよ
俺は他人の作った物を使うだけだから
「PGはこうあるべき」までは言えないよ
>>738
たぶん32bitの切り捨ては後10年は無理だろうな
次世代Windows系OSでソフトウエア総取っ替えって事になったら
コンシューマレベルでは文句言いながらもついてくるだろうけど企業レベルでは無理だと思うよ
どうせならプラットフォームも金のかからんlinux系+openofficeにってこともあるだろうからできんでしょw
windows7に移行した大口顧客には64bit版OFFICEをタダでつけますとかやれば別だろうけどね
たぶん32bitの切り捨ては後10年は無理だろうな
次世代Windows系OSでソフトウエア総取っ替えって事になったら
コンシューマレベルでは文句言いながらもついてくるだろうけど企業レベルでは無理だと思うよ
どうせならプラットフォームも金のかからんlinux系+openofficeにってこともあるだろうからできんでしょw
windows7に移行した大口顧客には64bit版OFFICEをタダでつけますとかやれば別だろうけどね
OSは64bitのみだけど今まで通り32bitバイナリも動くようにするってことじゃないの？
>>743
おまえ馬鹿すぐる
おまえ馬鹿すぐる
>>744
俺は馬鹿だがおまえはさらに馬鹿すぐる
俺は馬鹿だがおまえはさらに馬鹿すぐる
いくらなんでも釣られすぎだろｗｗｗｗ
それとも共謀して荒らしでもやってんのか？ｗ
それとも共謀して荒らしでもやってんのか？ｗ
748 ：名無しさん＠編集中：2008/11/13(木) 21:39:13 ID:RiWIQ936
ニコ厨が作り出した物なんて所詮そんなもん
お久しぶりです。
お得意のコピペはどうしました？
お得意のコピペはどうしました？
30分アニメを2Gくらいに圧縮できる可逆でねーかな
192x108程度の解像度ならラクショー
Y8でおｋ
UtVideo5.0.0 ｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ
ネタかと思ったらマジか
Ut、キャプってるとたまに画面が止まるんだよな
自環境だけなんかも知らんが、似たような人って居ない？
Huffyuvだと特に問題ないんだけども
自環境だけなんかも知らんが、似たような人って居ない？
Huffyuvだと特に問題ないんだけども
エンコードはLAGSとさほど変わらないけどデコード速度は笑っちまった
AviUtlでYV12出力出来ないのは仕様？
それとも俺が馬鹿？
それとも俺が馬鹿？
入出力フォーマットは YV12 のみです。ってサイトに書いてあるじゃん。
Utlはコーデックに渡す段階でRGBかYUY2。
Utlはコーデックに渡す段階でRGBかYUY2。
そっか、そうですよね
UtlでYV12出力したかったな
UtlでYV12出力したかったな
781 ：名無しさん＠編集中 ：sage ：2008/11/27(木) 23:10:43 ID:QCwwJ7xB
流れ読まずに俺メモ
mencoderはhuffyuvsに対応してないがFourCCを書き換えることで対応可
TMPGEnc2.5使いにとっては朗報かも
流れ読まずに俺メモ
mencoderはhuffyuvsに対応してないがFourCCを書き換えることで対応可
TMPGEnc2.5使いにとっては朗報かも
UtVideo 5.1.0
乙
ULY0ってインタレースに対応してるんだろうか
そういや外人ってUtVideoとかHuffyuv_mtとか知ってるのかな。
中間ファイルの用途としてFastCodecが速くて満足してるけど
わずかに劣化してるとか？なんかあまり語られてないけど。
そんな画質命の映像じゃないからFastCodec使うぜ！願わくばアップデートしてほしいが
わずかに劣化してるとか？なんかあまり語られてないけど。
そんな画質命の映像じゃないからFastCodec使うぜ！願わくばアップデートしてほしいが
可逆なのに劣化してるってそれじゃ可逆じゃないじゃん
全く劣化しないか可逆なんてない
おいおい
あると思ってるのか？
完全に復号しないのなら「可逆」じゃねーだろ。
zip圧縮したらデータが変わるんですって
772 ：名無しさん＠編集中：2008/12/13(土) 00:02:59 ID:d1z5UPVo
可逆を理解できない方々
自分でテストすらせずデータも示さず可逆なんて無いって言い張る人多いよね('∀`)
FastCodecだってVisuallyLosslessなんだからいいじゃん！
お前らどんな大層な目を持ってるのかと。
そんなに1bitも変えたくない映像があるのかと。アニメなんだろ？Divxでおｋ
お前らどんな大層な目を持ってるのかと。
そんなに1bitも変えたくない映像があるのかと。アニメなんだろ？Divxでおｋ
中間ファイルやエンコードのソースという用途があってだな。
馬鹿か
実写ならDivXでもありかもしれんが、アニメでDivXはねーよ
実写ならDivXでもありかもしれんが、アニメでDivXはねーよ
FastCodecだってちゃんとした可逆だぞ。
Aviutlで特定の一コマだけBMP出力して差分検出して何も出てこなかったら可逆とみなしてる。
一番ベタなのって色空間間違えてるパターンだよな…
一番ベタなのって色空間間違えてるパターンだよな…
ソースがRGBならYUV変換のときに情報が減らされるね。
ソースがYUVなら欠落はまったくないはず。
RGBをRGBのまま扱える可逆もあるが。
ソースがYUVなら欠落はまったくないはず。
RGBをRGBのまま扱える可逆もあるが。
＞可逆なのに劣化してるってそれじゃ可逆じゃないじゃん
＞自分でテストすらせずデータも示さず可逆なんて無いって言い張る人多いよね('∀`)
＞FastCodecだってVisuallyLosslessなんだからいいじゃん！
＞FastCodecだってちゃんとした可逆だぞ。
＞自分でテストすらせずデータも示さず可逆なんて無いって言い張る人多いよね('∀`)
＞FastCodecだってVisuallyLosslessなんだからいいじゃん！
＞FastCodecだってちゃんとした可逆だぞ。
劣化するのは扱い方が悪いんだろ
色空間の変換で非可逆になってるとか抜かすやつは相当なおばかさんだな
＞劣化するのは扱い方が悪いんだろ
＞色空間の変換で非可逆になってるとか抜かすやつは相当なおばかさんだな
＞色空間の変換で非可逆になってるとか抜かすやつは相当なおばかさんだな
RGBをRGBのまま扱う可逆コーデックと言えばアニメーションコーデック100%とかがあるね。
音声は無圧縮のPCM？
俺は気分的な理由で無圧縮だな。
せっかく音声だけはBDと比べても聴き劣りしないんだから、セコセコ削ることもあるまいｗ
下手に可逆にすると再生環境限られちゃうしなー
せっかく音声だけはBDと比べても聴き劣りしないんだから、セコセコ削ることもあるまいｗ
下手に可逆にすると再生環境限られちゃうしなー
無圧縮って何の話してんだ？
RGBなるお
>>784
アニメーションコーデックなんてはじめて聞いたから何のことかとおもえばQuickTime用かよ
アニメーションコーデックなんてはじめて聞いたから何のことかとおもえばQuickTime用かよ
ちゃんとRGBで格納してるっぽいんだけど、デコード後のフレームがソースとバイナリ不一致になるふしぎ。
>>791
サンプル見せてくれ。ウチでなったことはない
サンプル見せてくれ。ウチでなったことはない
24と32の違いとか？
ごめん今やったら一致した。
昔いろいろ検証したとき不一致だった記憶があったんだが。
昔いろいろ検証したとき不一致だった記憶があったんだが。
>>790
そう？CGとかアニメとか、AEなんかで合成した後はアニメーションで出す事多いよ。Win機でもQuickTimeはどうせインストールしなきゃ
話になんないし、単調なイラスト系とかだとかなりデータ量削減出来るのがうれしい。
そう？CGとかアニメとか、AEなんかで合成した後はアニメーションで出す事多いよ。Win機でもQuickTimeはどうせインストールしなきゃ
話になんないし、単調なイラスト系とかだとかなりデータ量削減出来るのがうれしい。
WindowsにQuickTimeはないわ
QuickTimeは腹立つなぁ。できる限りインスコしなくない
なんだかんだと理由をつけてインストールを促す林檎
QuickTimeでもiTunesでも良いけど代わりにコマンドラインから使えるaacエンコーダーだして
くれたらインストする必要なくなるんだけどな、個人的に。
くれたらインストする必要なくなるんだけどな、個人的に。
NeroのAACエンコーダーでいいじゃん
某スレのテンプレからコピペ
・Nero AAC コーデック（AAC用コーデック）
ttp://www.nero.com/ena/downloads-nerodigital-nero-aac-codec.php
・Simple NeroAACEnc GUI : NeroAAC用のフロントエンド（Doom9のフォーラム/英語）
ttp://forum.doom9.org/showthread.php?t=110970
・Nero AAC/AAC+ UI : NeroAAC用のフロントエンド
ttp://www.digitalradiotech.co.uk/nero_aac_ui.htm
・Nero AAC コーデック（AAC用コーデック）
ttp://www.nero.com/ena/downloads-nerodigital-nero-aac-codec.php
・Simple NeroAACEnc GUI : NeroAAC用のフロントエンド（Doom9のフォーラム/英語）
ttp://forum.doom9.org/showthread.php?t=110970
・Nero AAC/AAC+ UI : NeroAAC用のフロントエンド
ttp://www.digitalradiotech.co.uk/nero_aac_ui.htm
つか、cliのAACエンコーダがほしいって人が
今の今までNeroのやつを知らないってのが不思議で仕方が無い
今の今までNeroのやつを知らないってのが不思議で仕方が無い
いや、NeroよりAppleのほうが音が好みだからだよ。他のAACエンコーダー教えてくれなんて言ってない。
faacに比べたらどんなエンコーダーでもありがたい
WinにQuickTime入れなきゃ話にならない、という一瞬釣りかとも思えるような表現の後に
代わりにコマンドラインから使えるaacエンコーダーだしてくれたら、って流れだったんだから
他のAACエンコーダの話が出るのは自然だろ
そこに音が好みだから、なんて書き込んでも…
代わりにコマンドラインから使えるaacエンコーダーだしてくれたら、って流れだったんだから
他のAACエンコーダの話が出るのは自然だろ
そこに音が好みだから、なんて書き込んでも…
コマンドラインから使えるaacエンコーダー（をAppleが）だしてくれたら
（わざわざWinにQuickTime、iTunes）インストする必要なくなる
読解力なさすぎ、冬休みだな。
（わざわざWinにQuickTime、iTunes）インストする必要なくなる
読解力なさすぎ、冬休みだな。
だからさ、「Winに（略）話にならない」なんて極論の後なわけよ
QuickTimeに良い印象を持ってない人もいるんだからApple製以外の物が出てきた流れ
読解力じゃなくて心情の問題だな
QuickTimeに良い印象を持ってない人もいるんだからApple製以外の物が出てきた流れ
読解力じゃなくて心情の問題だな
「読解力なさすぎ」
じゃなくて「おまえがエスパー求めすぎ、冬休みだな」
の方が正しいよねとでもつっこんでほしがってる？
じゃなくて「おまえがエスパー求めすぎ、冬休みだな」
の方が正しいよねとでもつっこんでほしがってる？
誰かがiTunesからdllとして抽出してくれるんじゃない？
812 ：名無しさん＠編集中：2008/12/19(金) 04:34:14 ID:xHDMt6o+
よ ほ う 診 医 精 一 忠 は あ ま
さ う け 察 .者 神 度 告 て き さ
そ が .た を の 科 す た れ し
う の る な く
だ が ：
､＿__ ＿__ ：
(＿＿＿＿＿,／::::::::::::｀ヽ、
/::rー‐-ｰ-､:::l＿＿, , -─
_|:lr_‐､￣-=､l:::| /／
/)Y ´ﾟ｀ri ､'ﾟﾞ' |/,〉 /´
|｀ |l /ヽ _,ノｌ |ﾉ|
ヽ_| '-=ニ=-l !/
/|ﾊ -‐ /＼
＿,. -ｰ'`´ l l ＼ /'/! l`ー-､＿
さ う け 察 .者 神 度 告 て き さ
そ が .た を の 科 す た れ し
う の る な く
だ が ：
､＿__ ＿__ ：
(＿＿＿＿＿,／::::::::::::｀ヽ、
/::rー‐-ｰ-､:::l＿＿, , -─
_|:lr_‐､￣-=､l:::| /／
/)Y ´ﾟ｀ri ､'ﾟﾞ' |/,〉 /´
|｀ |l /ヽ _,ノｌ |ﾉ|
ヽ_| '-=ニ=-l !/
/|ﾊ -‐ /＼
＿,. -ｰ'`´ l l ＼ /'/! l`ー-､＿
ほう、tobinakaがdoom9でUtvideo紹介したら、結構反響があるみたいだね
安定版がでたら64bitに移植するってさ
安定版がでたら64bitに移植するってさ
見つけたからURL置いとく
ttp://forum.doom9.org/showthread.php?t=143624
ttp://forum.doom9.org/showthread.php?t=143624
ま た t o b i n a k a か
比較してるHuffyuv_mtもYLCもLagarith 1.3.16最適化版も日本のだから知名度は低そうだし
それら除いたら比較にならないくらい優秀だから反響は大きそう。
yuvにも対応したしね。
けど64bit版はあんまり恩恵はないな・・・どのくらいの差がでるのかは気になるけど。
それら除いたら比較にならないくらい優秀だから反響は大きそう。
yuvにも対応したしね。
けど64bit版はあんまり恩恵はないな・・・どのくらいの差がでるのかは気になるけど。
>>815
tobinakaってだれ？
tobinakaってだれ？
x264の日本独自のパッチをDoom9で紹介したりしてたな。
2chウケは良くない。
2chウケは良くない。
つーかUtVideoの更新をここじゃなく、Doom9で知ることになろうとは思いもせなんだ
tobinakaか、ブログをたまに読みに行くけど心証は最悪です
しかし、これで Ut Video のテストが多くの人によっておこなわれることになるな。
822 ：名無しさん＠編集中：2008/12/23(火) 08:32:18 ID:pSnASKJU
ぶっちゃけLagarithで間に合ってます
勝手に使命を感じて暴走してる痛い人。
特にx264のくだりは読んでて気持ち悪くなる。
何かに貢献しているという達成感を得るにはコスパがいいんだろうなぁ。
特にx264のくだりは読んでて気持ち悪くなる。
何かに貢献しているという達成感を得るにはコスパがいいんだろうなぁ。
妄想乙
>>823
まさにそんな感じだな。謎の1人勝手な使命感。
第三者からみると馬鹿としか言えない。
でもx264関連についてはアホほどエンコテストしたデータを公開しているので
たま～に役に立つｗ
てか最近スレ違が多いな
まさにそんな感じだな。謎の1人勝手な使命感。
第三者からみると馬鹿としか言えない。
でもx264関連についてはアホほどエンコテストしたデータを公開しているので
たま～に役に立つｗ
てか最近スレ違が多いな
しかしそのおかげでバグが１つつぶれたぜ。
なんでそんなにしつこくたたくのかわからん。
なんでそんなにしつこくたたくのかわからん。
x264Wikiのせいかね。
立ち上げたはいいものの誰も編集しなかったからやめますと言って畳んだ。
しかし間もなく再開。
立ち上げたはいいものの誰も編集しなかったからやめますと言って畳んだ。
しかし間もなく再開。
腕の良い奴ほど変人が多いですから
そんなに腕が立つ人間なの？
ひんと 自演
変人差別の多い国ですから
Doom9で話題になってたx264 の --b-pyramid のバグも彼が指摘するまで
2chのx264スレの誰も話題にしてなかった。
とりあえず自分のエンコでは問題なかったから良かったけど正直助かった。
2chのx264スレの誰も話題にしてなかった。
とりあえず自分のエンコでは問題なかったから良かったけど正直助かった。
俺は気にせず--b-pyramid使い続けてるｗ
doom9に紹介するのにUtVideoの作者の了解を取ってるのか
知らないけど、取ってるんだったらそれでいいんじゃねーの？
知らないけど、取ってるんだったらそれでいいんじゃねーの？
取ってるらしいよ
彼、うちのサイトにリンク貼ってくれてるけどサイト名間違ってるんだよね
バグ報告するのもいいけどその辺のバグもきちんとしようね
バグ報告するのもいいけどその辺のバグもきちんとしようね
本人に直接言えばいいじゃないか
そういうのは愚痴る前に言えよ
ここ最近、可逆コーデック以外の雑談が多い件について
まあ何も更新とか無いから仕方ないんだけど
まあ何も更新とか無いから仕方ないんだけど
非可逆スレよりのびてるから大丈夫だろ
何が大丈夫なのか知らんが
何が大丈夫なのか知らんが
ところでだれかｘ264のロスレスって試したことありますか？
初心者なもんで、
・本当にロスレスかどうなのか？
・中間ファイルとして使う場合、avs書くときはDirectShow使わなきゃいけないけど、これは画質に影響するのか？
確認する方法がわかりません
どうやったら確認できるか教えて下さい
ｒ1061でとりあえず2000フレームくらい試してみたら、UtVideo（ULY0、デコード速度優先)より、エンコもデコードも速いような気がするんですが…
サイズはPフレーム使うから、もちろんずっと小さいわけですが…
初心者なもんで、
・本当にロスレスかどうなのか？
・中間ファイルとして使う場合、avs書くときはDirectShow使わなきゃいけないけど、これは画質に影響するのか？
確認する方法がわかりません
どうやったら確認できるか教えて下さい
ｒ1061でとりあえず2000フレームくらい試してみたら、UtVideo（ULY0、デコード速度優先)より、エンコもデコードも速いような気がするんですが…
サイズはPフレーム使うから、もちろんずっと小さいわけですが…
初心者を盾にする奴はろくな奴がいない
まぁとりあえずH.264のコーデックを触ったことがある俺に言わせると、
PCMというモードがあって、それを使えばロスレスにはなるぞ。
でもCAVLCやCABACといった可逆圧縮部分は通らないので、データはでかくなる。
x264はどうだか知らないが、H.264のPCMとはそういうモードだ。
PCMというモードがあって、それを使えばロスレスにはなるぞ。
でもCAVLCやCABACといった可逆圧縮部分は通らないので、データはでかくなる。
x264はどうだか知らないが、H.264のPCMとはそういうモードだ。
>>841
＞本当にロスレスかどうなのか？
PSNR測定ツールを使えば？
＞avs書くときはDirectShow使わなきゃいけないけど、これは画質に影響するのか？
DS云々よりx264はYV12専用なのでソースがYUY2などだったらそこで情報は削られる
＞本当にロスレスかどうなのか？
PSNR測定ツールを使えば？
＞avs書くときはDirectShow使わなきゃいけないけど、これは画質に影響するのか？
DS云々よりx264はYV12専用なのでソースがYUY2などだったらそこで情報は削られる
diffをとるってのが、いまいちわからんのですがとりあえずやってみます
1：同じファイル（d2v)をｘ264とHelix YV12 codecでそれぞれエンコード（YV12のままでフィルタなし）
2：ｘ264の方を
DirectShowSource（”ｘ264.mp4”)#デコードはffdshow
でVirtualDubでHelixに再エンコード
3：１のHelix.aviと２のHelix.aviをｆｃ /n でいいんでしょうか？
>>843
ttp://forum.doom9.org/showthread.php?t=143748
を読んだ限りでは、とりあえずCABACやCAVLCも使うようです
1：同じファイル（d2v)をｘ264とHelix YV12 codecでそれぞれエンコード（YV12のままでフィルタなし）
2：ｘ264の方を
DirectShowSource（”ｘ264.mp4”)#デコードはffdshow
でVirtualDubでHelixに再エンコード
3：１のHelix.aviと２のHelix.aviをｆｃ /n でいいんでしょうか？
>>843
ttp://forum.doom9.org/showthread.php?t=143748
を読んだ限りでは、とりあえずCABACやCAVLCも使うようです
両方無圧縮ではいてハッシュ比較すればいいんじゃねーの
圧縮した動画のうち何枚かをBMPで切り出してバイナリ比較が
現実的でしょ。
現実的でしょ。
>>846のやり方で結局やりました（出かける前にバッチをセットで）
2つのaviをそれぞれmp4boxでYV12のrawstreamだけ取り出して、バイナリ比較したところ、完全に一致するようです
50フレームずつ5箇所ほど試したので、まず間違いない…のかな？
>>846のDoom9のスレをもう一度読んでみたら、すでに何度か試されてる人がいたようで…orz
2つのaviをそれぞれmp4boxでYV12のrawstreamだけ取り出して、バイナリ比較したところ、完全に一致するようです
50フレームずつ5箇所ほど試したので、まず間違いない…のかな？
>>846のDoom9のスレをもう一度読んでみたら、すでに何度か試されてる人がいたようで…orz
850 ：名無しさん＠編集中：2009/01/01(木) 21:58:26 ID:2wPSxABx
某セガ系ハード向けツールのreadme読んでたら
* このソフトウェアはフリーソフトウェアです。
* このソフトウェアに関する著作権は、全て作者である神野遊夢こと梅澤威志に帰属します。
こんな記述があったんだがUtvideoの作者と同一人物ですか?
* このソフトウェアはフリーソフトウェアです。
* このソフトウェアに関する著作権は、全て作者である神野遊夢こと梅澤威志に帰属します。
こんな記述があったんだがUtvideoの作者と同一人物ですか?
知らん。他所で聞け。
名前が厨二病っぽいな
恥ずかしいペンネームで小説もといポエム書いた過去がある奴は多いはず。
RGB555扱える可逆って何か無いかね？
アマレココに新しいコーデックが出来たみたいだ
856 ：名無しさん＠編集中：2009/01/31(土) 01:13:15 ID:NbasRzo6
アマレココ
日付 2009.1.29
バージョン 3.01
サイズ654kB
・ 主に不具合修正。
・ 本ソフトウエアを利用するにはAMV3ビデオコーデックが必要です。
・ アマレココで利用する場合に限りAMV3の制限を解除するレジストキーがreadme.txtに記載してありますのでご利用下さい。
・ 取扱説明書はオンラインヘルプとなります。
※ プラグインファイルを「plugin」フォルダーに置くように変更しました。詳細はアマレココの取扱説明書を参照して下さい。
日付 2009.1.29
バージョン 3.01
サイズ654kB
・ 主に不具合修正。
・ 本ソフトウエアを利用するにはAMV3ビデオコーデックが必要です。
・ アマレココで利用する場合に限りAMV3の制限を解除するレジストキーがreadme.txtに記載してありますのでご利用下さい。
・ 取扱説明書はオンラインヘルプとなります。
※ プラグインファイルを「plugin」フォルダーに置くように変更しました。詳細はアマレココの取扱説明書を参照して下さい。
あれ？3.00はインストーラだった気がするんだけど
バージョンアップは上書きすればいいのかな
バージョンアップは上書きすればいいのかな
アマレココ3.01に更新したら、YLCでの録画でファイルサイズが256MB付近になったときに
強制終了するようになってしまった。
強制終了するようになってしまった。
作者に報告すると喜ばれますよ
よく見ると可逆スレだからスレ違いだね。
コーデックの話じゃないし。
コーデックの話じゃないし。
付属のコーデックは可逆非可逆切り替えられるYV12のコーデックだよ一応。
ソフトのほうはスレ違いだけど。
ソフトのほうはスレ違いだけど。
YLCが他のツールでも不具合起こるならYLCのせいだろうけど
特定のソフトだけならキャプチャスレでの話題でしょ。
MV3 ver3.00bの話ならまだわかるけど。
でここはyuy2とかyv12の可逆はありなんだろうか。
特定のソフトだけならキャプチャスレでの話題でしょ。
MV3 ver3.00bの話ならまだわかるけど。
でここはyuy2とかyv12の可逆はありなんだろうか。
別に>>585がスレ違いじゃないよって言いたかったわけじゃないんだけど。
スレ違いだよ、とも明確には言わなかったけど>>859で察してほしかったな。
だいたいどの発言までのことを言ってるかわかりづらかったんだよ！
スレ違いだよ、とも明確には言わなかったけど>>859で察してほしかったな。
だいたいどの発言までのことを言ってるかわかりづらかったんだよ！
>>862
ここの住人は、ソースがYUY2やYV12である場合がほとんどだから、むしろRGB使用者のほうが少数派だ
TSが当たり前になったから可逆圧縮の必要性は薄れたが、そこらへんは勘違いしないでもらいたいな
ここの住人は、ソースがYUY2やYV12である場合がほとんどだから、むしろRGB使用者のほうが少数派だ
TSが当たり前になったから可逆圧縮の必要性は薄れたが、そこらへんは勘違いしないでもらいたいな
まあ自分もRGBは使わないし前スレあたりでロスレス云々と非可逆でスレ分かれたから聞いてみただけ。
>>864
>TSが当たり前になったから可逆圧縮の必要性は薄れたが
そんなことはないよ。なんだかんだで中間ファイルの必要性は高い。
単にキャプ物をエンコする人より、色んなソースで中間ファイルを作るような編集をしてる人が
むしろこのスレではメイン。そこらへんは勘違いしないでもらいたいな
>TSが当たり前になったから可逆圧縮の必要性は薄れたが
そんなことはないよ。なんだかんだで中間ファイルの必要性は高い。
単にキャプ物をエンコする人より、色んなソースで中間ファイルを作るような編集をしてる人が
むしろこのスレではメイン。そこらへんは勘違いしないでもらいたいな
AMV3は良さそうなんだが試用ではロゴが入るのが欠点だよな・・・
Canopus Losslessはどうなの？
やっぱ今のところデコード早いのはUtVideo？
870 ：名無しさん＠編集中：2009/02/11(水) 11:18:26 ID:WeHgrtqq
「無圧縮」→「Huffyuv」にエンコする時に、
TMPGEncを使った時だけ、ファイルサイズが異常に小さくなります。何故でしょうか？
（バッチエンコが楽なTMPGEncを、本当は使いたいのですが･･･）
無圧縮：91.5 MB
TMPGEnc4 … 24.1 MB
Virtual Dub … 45.2 MB
erEffects7 … 45.2 MB
Premier Pro2 … 45.2 MB
＜設定＞
OS：WindowsXP
コーデック：Huffyuv V2.1.1
コーデック設定：
YUY2 Compression method … Predict Left(fastes)
RGB Compression method … Predict Left decorr(fastes)
チェックボックスはすべてOFF
TMPGEncを使った時だけ、ファイルサイズが異常に小さくなります。何故でしょうか？
（バッチエンコが楽なTMPGEncを、本当は使いたいのですが･･･）
無圧縮：91.5 MB
TMPGEnc4 … 24.1 MB
Virtual Dub … 45.2 MB
erEffects7 … 45.2 MB
Premier Pro2 … 45.2 MB
＜設定＞
OS：WindowsXP
コーデック：Huffyuv V2.1.1
コーデック設定：
YUY2 Compression method … Predict Left(fastes)
RGB Compression method … Predict Left decorr(fastes)
チェックボックスはすべてOFF
多分色空間が変換されてるんじゃないか
俺もTMPGEncだけYUY2に変換されていると思う。
無圧縮のデータがRGBであればTMPGEncを使用すべきではないね。
可逆にならないから。
無圧縮のデータがRGBであればTMPGEncを使用すべきではないね。
可逆にならないから。
ちなみにテストしてないようだがAviutlもコーデックの設定でYUY2出力のチェックはずさないと
可逆にならないから注意な。つかTMPGEncも似たような設定でもあるんじゃねーの。持ってないけど
可逆にならないから注意な。つかTMPGEncも似たような設定でもあるんじゃねーの。持ってないけど
>>871 >>872 >>873
有り難うございます。問題解決できました。
873さんの言うとおり、TMPGEncの環境設定にありました。
（環境設定の中の、AVI設定で、Huffyuvの「Encode in YUV」のチェックを外しました）
ずっと困って多ので、助かりました(＾＾)
有り難うございます。問題解決できました。
873さんの言うとおり、TMPGEncの環境設定にありました。
（環境設定の中の、AVI設定で、Huffyuvの「Encode in YUV」のチェックを外しました）
ずっと困って多ので、助かりました(＾＾)
[UtVideo] バージョン 5.2.2
ULY2: エンコード時に RGB32 で入力できるようにした。アセンブラ化済み。
ULY0: エンコード時に RGB32 で入力できるようにした。とりあえず作っただけなので、RGB32 入力時のエンコードは遅い。
ULY0: デコード時に RGB32 で出力できるようにした。とりあえず作っただけなので、RGB32 出力時のデコードは遅い。
ULY2: エンコード時に RGB32 で入力できるようにした。アセンブラ化済み。
ULY0: エンコード時に RGB32 で入力できるようにした。とりあえず作っただけなので、RGB32 入力時のエンコードは遅い。
ULY0: デコード時に RGB32 で出力できるようにした。とりあえず作っただけなので、RGB32 出力時のデコードは遅い。
876 ：名無しさん＠編集中：2009/02/27(金) 12:52:30 ID:vc8cdT3l
H.264 LossLess Apple LossLessでmp4作れる？
つくれるよ
再生できるかどうかはデコーダやプレーヤーによるだろうけど
再生できるかどうかはデコーダやプレーヤーによるだろうけど
3000kbps以下の可逆圧縮コーデックを教えてください
元動画の解像度は800×600です
元動画の解像度は800×600です
ないんじゃね？
ほとんど動きがなければAMV2MTとかなら可能かもしれないがw
ほとんど動きがなければAMV2MTとかなら可能かもしれないがw
超圧縮可逆だけがお望みならMSU Screen Capture Lossless Codecオヌヌメ。
881 ：名無しさん＠編集中：2009/03/04(水) 14:05:21 ID:9LlYn5a4
>>880-881
なにこれ最早ギャグのレベル
なにこれ最早ギャグのレベル
エミュの動画を保存する時にAVI1.0でしか書き出せないからRAVIを使ってるんだが、
MSUやh.264使おうとするとエンコできずに落ちたり再生画面がめちゃくちゃになったりするんだけどこれはRAVIとの相性の問題？
今はなんとかLagarithで落ち着いてるけど高解像度で保存したい時なんかどうしても相当の圧縮率が必要になるしなんとかならないかな・・・
MSUやh.264使おうとするとエンコできずに落ちたり再生画面がめちゃくちゃになったりするんだけどこれはRAVIとの相性の問題？
今はなんとかLagarithで落ち着いてるけど高解像度で保存したい時なんかどうしても相当の圧縮率が必要になるしなんとかならないかな・・・
>>883
その原因はわかんないけど、
俺はそのRAVIでダメなら
http://www.vector.co.jp/soft/win95/art/se279572.html
を使う（正式名称は何？ REFCODEC？）。
huffyuvsを使う時はこっち。こっちの方が削除時のツールなどが整ってて便利。
しかしUtVideoはうまく差し替えられない。
今のところ、
REFCODEC？…huffyuvsでの分割圧縮（ホントはこっちでUtVideoCodecを使いたい）
RAVI…UtVideoCodecでの分割圧縮
これで何とかしてる。
その原因はわかんないけど、
俺はそのRAVIでダメなら
http://www.vector.co.jp/soft/win95/art/se279572.html
を使う（正式名称は何？ REFCODEC？）。
huffyuvsを使う時はこっち。こっちの方が削除時のツールなどが整ってて便利。
しかしUtVideoはうまく差し替えられない。
今のところ、
REFCODEC？…huffyuvsでの分割圧縮（ホントはこっちでUtVideoCodecを使いたい）
RAVI…UtVideoCodecでの分割圧縮
これで何とかしてる。
アマレココ使えよ。
シェアだけど、がんばって開発してるんだし。
シェアだけど、がんばって開発してるんだし。
>>883>>884
そんなマイナーなよくわからんもの使わんでAviSynthにしろよ
AVISource("hoge.avi")
って、たった1行メモ帳で書いて、VirtualDubなりAviUtlなりに読み込ませるだけだから
>>885
エミュのリプレイ出力なんだろ
そんなマイナーなよくわからんもの使わんでAviSynthにしろよ
AVISource("hoge.avi")
って、たった1行メモ帳で書いて、VirtualDubなりAviUtlなりに読み込ませるだけだから
>>885
エミュのリプレイ出力なんだろ
ｈ.264の方はしらんがMSUはエンコード・デコード共に負荷が非常に高いから
デスクトップキャプチャのように画面の大半に変化のない映像以外でのリアルタイムキャプチャや再生には不向き。
一般用途では完全な保存用と考えたほうがいい。
正直Lagarith級で一杯一杯だと先が思いやられるから普通にHDDを増設・交換するのがいいと思う
デスクトップキャプチャのように画面の大半に変化のない映像以外でのリアルタイムキャプチャや再生には不向き。
一般用途では完全な保存用と考えたほうがいい。
正直Lagarith級で一杯一杯だと先が思いやられるから普通にHDDを増設・交換するのがいいと思う
MSUは完全にドット絵の圧縮向けで
3Dゲームや実写の動画をエンコするとLagarithどころかHuffyuvより膨らむ
3Dゲームや実写の動画をエンコするとLagarithどころかHuffyuvより膨らむ
ベストバランスはUtVideo？
AviSynthはフィールドオーダー指定しないとボトム読みするバグがあるから駄目なんよ
バグ？最近は仕様でも気に入らない動作ならバグなん？馬鹿なの？
ああん？ボトムフィールドファーストなんて死語やんけ
あんさんちっともわかっとらへんな
トップフィールドファーストが基本でっせ
あんさんちっともわかっとらへんな
トップフィールドファーストが基本でっせ
1行書くだけじゃん
つかインタレソースならどっちにせよ書く癖つけようぜ
つかインタレソースならどっちにせよ書く癖つけようぜ
好きなほう使え。AssumeTFF/BFFのほうが新しいらしいがな。
Avisynthはデコード済みの（無圧縮に展開された）ストリームもらうから
ソースがDVなのかそうでないかの判断はできないはず。だからデフォルトだと
ちょい前まで一般的だったDVとしてフィールドオーダーを設定するんだと思うよ。
Avisynthはデコード済みの（無圧縮に展開された）ストリームもらうから
ソースがDVなのかそうでないかの判断はできないはず。だからデフォルトだと
ちょい前まで一般的だったDVとしてフィールドオーダーを設定するんだと思うよ。
>>880-881
すごい^^
すごい^^
これ、どうホンとかな？
ttp://www.sokuhou.co.jp/library/TI/TI-Maekawa42.html
＜↑からの抜粋↓＞
・1000分の1に圧縮してもロスレス
・インターネット回線でハイビジョン画像の伝送が出来る
・この画期的な的な技術を実現したのはイメージインテック株式会社
ttp://www.sokuhou.co.jp/library/TI/TI-Maekawa42.html
＜↑からの抜粋↓＞
・1000分の1に圧縮してもロスレス
・インターネット回線でハイビジョン画像の伝送が出来る
・この画期的な的な技術を実現したのはイメージインテック株式会社
1000分の1って超適当に計算したら地デジでも24分1.5Gが2G弱くらいでlosslessに
できそうなんだけど…
できそうなんだけど…
圧縮の検証はカラーバーを使用 とかかもよｗ
冗談はさておきレントゲン画像の話をしているから1000分の1になるのは
そういうモノクロで黒と白がはっきりしているような場合なんだろう。
それならPNGでも100分の1くらいは普通に行くからな。
冗談はさておきレントゲン画像の話をしているから1000分の1になるのは
そういうモノクロで黒と白がはっきりしているような場合なんだろう。
それならPNGでも100分の1くらいは普通に行くからな。
圧縮時には大概エントロピーの限界があってエントロピーを大きく超えた圧縮は無理なはずなんだけど、
一度圧縮の勉強した時にzipでも結構頑張ったアルゴリズムで7zのソリッド圧縮なんて
もの凄いアルゴリズムだと思ったもんだけど、7zでも一番圧縮できるテキスト形式でも大体10分の1なんだよな、
リンク先はレントゲン写真で1000分の1って言ってるけど、
レントゲン写真って白と黒の2色がメインだからそれくらい縮むと思うけど、
風景写真とかになるとそこまで縮んだりはしないと思う、ものが出ないと何とも言えないけども、
でもpngに置き換わる圧縮形式だといいな。
一度圧縮の勉強した時にzipでも結構頑張ったアルゴリズムで7zのソリッド圧縮なんて
もの凄いアルゴリズムだと思ったもんだけど、7zでも一番圧縮できるテキスト形式でも大体10分の1なんだよな、
リンク先はレントゲン写真で1000分の1って言ってるけど、
レントゲン写真って白と黒の2色がメインだからそれくらい縮むと思うけど、
風景写真とかになるとそこまで縮んだりはしないと思う、ものが出ないと何とも言えないけども、
でもpngに置き換わる圧縮形式だといいな。
今なら、エントロピーコーディングにCABACを使えるH.264 High 4:4:4 Predictive Profileがベスト。
なぜそれほどに素晴らしい圧縮技術が1年以上を経ても話題にならないのか
それは極限られた環境でしか有効に機能しないからである
それは極限られた環境でしか有効に機能しないからである
圧縮技術で特許取ったら儲かる？
無料で使えるもっといいのが出てきて淘汰される、
GIFの時もPNGが出てきたし。
GIFの時もPNGが出てきたし。
悲しいけどこれ現実なのよね
きっと元のデータが各ピクセル256bitとかのくせに使ってるのは16階調くらいなんだよ。
まあ落ち着け。
909 ：名無しさん＠編集中：2009/04/01(水) 23:21:36 ID:3Mg0drCh
>>898
件のイメージインテックの技術を使った配信実験。
どうなんだろうね。
ポニーキャニオン、フルハイビジョン・ストリーミング配信実験を開始 - プレスリリース配信代行・ニュースリリース・PRの【＠Press｜アットプレス】
http://www.atpress.ne.jp/view/10576
ポニーキャニオン、フルHD/AVC動画配信の実用実験 -AV Watch
http://av.watch.impress.co.jp/docs/news/20090401_80277.html
こんな話もある。
アニメ「冬のソナタ」の配信技術が怪しい件：IIC PLAYER技術による動画配信？ | 808statement（was h-tee blog)
http://h-tee.jugem.jp/?eid=120
件のイメージインテックの技術を使った配信実験。
どうなんだろうね。
ポニーキャニオン、フルハイビジョン・ストリーミング配信実験を開始 - プレスリリース配信代行・ニュースリリース・PRの【＠Press｜アットプレス】
http://www.atpress.ne.jp/view/10576
ポニーキャニオン、フルHD/AVC動画配信の実用実験 -AV Watch
http://av.watch.impress.co.jp/docs/news/20090401_80277.html
こんな話もある。
アニメ「冬のソナタ」の配信技術が怪しい件：IIC PLAYER技術による動画配信？ | 808statement（was h-tee blog)
http://h-tee.jugem.jp/?eid=120
可逆圧縮音楽についての質問はここでいいんですかね？
曲ごとに作成したAPEファイルを一つのAPEファイルに結合するにはどうしたら良いのでしょうか？
(01.ape,02.ape,03.ape.......→OOO.ape) というようにアルバム単位でのAPEファイルを作成したいのですが。
曲ごとに作成したAPEファイルを一つのAPEファイルに結合するにはどうしたら良いのでしょうか？
(01.ape,02.ape,03.ape.......→OOO.ape) というようにアルバム単位でのAPEファイルを作成したいのですが。
すみません、別のスレで1280x960のXvidを中間ファイルとして使っているのですが、それを作るのに5時間かかってしまいます。
それであまり時間を書けずに可逆圧縮をするコーデックはfastcodecでよろしいでしょうか?
それであまり時間を書けずに可逆圧縮をするコーデックはfastcodecでよろしいでしょうか?
>>910
誘導しときます。
ttp://pc12.2ch.net/test/read.cgi/software/1136974601/
ttp://pc12.2ch.net/test/read.cgi/software/1219683003/
フォローすると、APEはmkaやm4aなどの諸コンテナが対応していないので、
チャプター付きでコンテナに格納という手法がとれなかったはずです。
ですが、リッピング時にcueシートで書き出すとか、
そこからaplファイルを作成するとかで、ご希望の動作が可能なはずです。
もっとシンプルに複数のapeをチャプターなしの1ファイルのapeにしてもいいなら、
fb2kで1ファイルに結合することができます（再エンコードですが可逆なので無問題）。
誘導しときます。
ttp://pc12.2ch.net/test/read.cgi/software/1136974601/
ttp://pc12.2ch.net/test/read.cgi/software/1219683003/
フォローすると、APEはmkaやm4aなどの諸コンテナが対応していないので、
チャプター付きでコンテナに格納という手法がとれなかったはずです。
ですが、リッピング時にcueシートで書き出すとか、
そこからaplファイルを作成するとかで、ご希望の動作が可能なはずです。
もっとシンプルに複数のapeをチャプターなしの1ファイルのapeにしてもいいなら、
fb2kで1ファイルに結合することができます（再エンコードですが可逆なので無問題）。
最近ＵｔＶｉｄｅｏを使い始めたんですが、Ａｖｉｓｙｎｔｈで読めないみたいです。
Ａｖｉｓｙｎｔｈで読める方法は何かありますか？
Ａｖｉｓｙｎｔｈで読める方法は何かありますか？
>>915
AVISource("utvideo.avi")
AVISource("utvideo.avi")
>916 即答ありがとうございます。
早速やってみます。
早速やってみます。
おいおい・・・＾＾；
どうやって読もうとしていたのかとても気になるね！
俺もｗ
ぬるぽ
がっ
ロスレスは寧ろ携帯動画の方に需要があると思うんだが。
携帯電話や携帯オーディオには有機ELやハイエンド液晶などの
高品質ディスプレイが増えているのに高品質コンテンツがない。
携帯向けに企画すればいいのにな。ワイドQVGAクラスなら15Mbps～20Mbps
あれば十分余裕なのに。
携帯電話や携帯オーディオには有機ELやハイエンド液晶などの
高品質ディスプレイが増えているのに高品質コンテンツがない。
携帯向けに企画すればいいのにな。ワイドQVGAクラスなら15Mbps～20Mbps
あれば十分余裕なのに。
でもそうなると32GのSDカードしか使えないからコスト的にも今はまだ無理か。
いくらなんでもH.264でビットレート割けば十分だと思うが
それじゃ、このスレ的には面白くないだろｗ
SDカードが今の8Gぐらいの値段じゃないと無理かもな。
携帯の処理能力もどんどん上がっているし、５年以内ならあるいは。
SDカードが今の8Gぐらいの値段じゃないと無理かもな。
携帯の処理能力もどんどん上がっているし、５年以内ならあるいは。
>>936
5年も経ったら携帯用メディアでもTBじゃねえのw
5年も経ったら携帯用メディアでもTBじゃねえのw
容量少な目な分安い物のほうが売れると思われ
一応一年で倍のペースだから
09 64G
10 128G
11 256G
12 512G
13 1T越え
でちょうど5年以内に１Ｔ越え出来るかどうかだな。
09 64G
10 128G
11 256G
12 512G
13 1T越え
でちょうど5年以内に１Ｔ越え出来るかどうかだな。
931 ：名無しさん＠編集中：2009/05/05(火) 12:34:50 ID:s6gKZm5k
質問
今あるＡＶＩファイルをデータ量を小さくしたい。
何か良いソフトありませんか？
フリーで。
AVIUTLっていうのは使ってたんですが、途中で墜ちたりして・・
なんでかわからんけど
今あるＡＶＩファイルをデータ量を小さくしたい。
何か良いソフトありませんか？
フリーで。
AVIUTLっていうのは使ってたんですが、途中で墜ちたりして・・
なんでかわからんけど
>931
DGCAとか7zipとか使えば？
DGCAとか7zipとか使えば？
933 ：名無しさん＠編集中：2009/05/05(火) 13:14:57 ID:s6gKZm5k
DGCAも圧縮する動画を選択すると墜ちます。
他の一太郎とかは大丈夫なのに・・
あと7zipって動画の圧縮できます？
他の一太郎とかは大丈夫なのに・・
あと7zipって動画の圧縮できます？
934 ：名無しさん＠編集中：2009/05/05(火) 13:16:11 ID:s6gKZm5k
DGCAも圧縮する動画を選択すると墜ちます。
他の一太郎とかは大丈夫なのに・・
あと7zipって動画の圧縮できます？
再圧縮ですね
ＡＶＩからＭＰＧとかそういう圧縮
他の一太郎とかは大丈夫なのに・・
あと7zipって動画の圧縮できます？
再圧縮ですね
ＡＶＩからＭＰＧとかそういう圧縮
スレタイ……っていうか、「可逆」の意味理解してる？
>>932を真に受けてるとこでｵﾜﾃﾙw
>>936
無劣化かDivXどうかを書いてない時点で既ｎ（ｒｙ
無劣化かDivXどうかを書いてない時点で既ｎ（ｒｙ
でわ プレミアでHDVで取り込むとmpegファイルになりますが
これを編集し統合し再編集しても劣化させないフォーマット形式は、何でしょうか？
ハイビジョン撮影し劣化させないで編集したいのですが・・・
これを編集し統合し再編集しても劣化させないフォーマット形式は、何でしょうか？
ハイビジョン撮影し劣化させないで編集したいのですが・・・
ここで聞くより検索した方が何が定番なのかすぐわかるだろ
utvideo-5.2.2は超重いな。
俺のE6600ではOCしてもコマ落ちする。（CPU使用率8割以上）
4.0.2は軽かったんだけどな。
あれをリアルタイムに使いたければCore i7 920かQ9650以上のCPUが必須だな。
俺のE6600ではOCしてもコマ落ちする。（CPU使用率8割以上）
4.0.2は軽かったんだけどな。
あれをリアルタイムに使いたければCore i7 920かQ9650以上のCPUが必須だな。
ULY2使ってください
ULY2は軽いな。
ただちょっとCPU負荷が高いのでもうちょっと負荷を低くする低負荷モードが欲しい。
ただちょっとCPU負荷が高いのでもうちょっと負荷を低くする低負荷モードが欲しい。
プログレYV12で一旦中間ファイル吐きたい時、時間重視なら
ULY0とｆｆdshow-huffyuvとLagarithでどれがオススメ？
ULY0とｆｆdshow-huffyuvとLagarithでどれがオススメ？
時間重視ならHelixだろ
あれって圧縮はしないから、スピードなら最強
あれって圧縮はしないから、スピードなら最強
>>18
NHKの労組を潰さない限りNHKの体質は改善されないよ。
日放労（NHK労組）
http://www.nipporo.com/
↑こいつ等が諸悪の根源。
ちなみに民主党の選挙母体の一つだったりする。
NHKの労組を潰さない限りNHKの体質は改善されないよ。
日放労（NHK労組）
http://www.nipporo.com/
↑こいつ等が諸悪の根源。
ちなみに民主党の選挙母体の一つだったりする。
ffdshowやVLCなどが使っているffmpegのLCLデコーダがクリーンアップ中のようだ。
949 ：名無しさん＠編集中：2009/06/17(水) 06:44:51 ID:DjAeX0he
すみません。LIVEDVDの音声抽出をしてmp3で聴こうとしたのですが、
音声がザーっとノイズのような感じになってしまうのはどうしてでしょうか？
どう対応したらいいかわかりません。
今までは同じ方法でやってもノイズみたいになってしまうことはなかったので
困っています。
何か方法はありますでしょうか？
音声がザーっとノイズのような感じになってしまうのはどうしてでしょうか？
どう対応したらいいかわかりません。
今までは同じ方法でやってもノイズみたいになってしまうことはなかったので
困っています。
何か方法はありますでしょうか？
どういう方法をどういう手順でやってるかも知らせず
わかれって正気か？
何よりスレ違いなことに気づけないってのも正気か・
わかれって正気か？
何よりスレ違いなことに気づけないってのも正気か・
エスパーすると違うバージョンのソフトを使えばうまくいく
952 ：名無しさん＠編集中：2009/06/17(水) 21:13:24 ID:POMiFTS7
すいません。DVD Decrypter_3.5.4.0で分離させて
Xilisoft Audio Converter Proで変換しています。
音声を分離させている時に問題があるのか、変換の時に問題があるのかも
わからないので。よろしくお願いします。
Xilisoft Audio Converter Proで変換しています。
音声を分離させている時に問題があるのか、変換の時に問題があるのかも
わからないので。よろしくお願いします。
ここは可逆圧縮のすれで、基本的に映像オンリー
おまえの質問は音声でしかも非可逆だろが
おまえの質問は音声でしかも非可逆だろが
954 ：名無しさん＠編集中：2009/06/17(水) 22:15:45 ID:POMiFTS7
ありがとうございます。色々ご迷惑おかけしました。
HuffyuvとHuffyuvSとの使い分けってどうすんの？
VHSからのキャプチャなんだけど、輝度ぐらいはいじりそうなので
ストレート変換のHuffyuvSを使ったほうがよいのだろうか。
Huffyuvはキャプった時にYC伸張してるのかな？
それとも出力時にYC伸張してるのだろうか？
VHSからのキャプチャなんだけど、輝度ぐらいはいじりそうなので
ストレート変換のHuffyuvSを使ったほうがよいのだろうか。
Huffyuvはキャプった時にYC伸張してるのかな？
それとも出力時にYC伸張してるのだろうか？
956 ：名無しさん＠編集中：2009/06/20(土) 07:33:48 ID:54fwDKD/
>>955
死ね
死ね
957 ：955：2009/06/21(日) 01:30:37 ID:cQknHUja
ストレート好きのおれは、HuffyuvS一本で行くことに決めた。
PCでみるには、こっちのほうが、好き。
PCでみるには、こっちのほうが、好き。
utvideoはゲーム取り込みに良いと思ったけど、もうちょっと負荷軽いの他にあるかな
デュアルコアで1コアゲームで占有させるとちょっと厳しい
デュアルコアで1コアゲームで占有させるとちょっと厳しい
>>958
俺の質問に答えろよ、池沼が
俺の質問に答えろよ、池沼が
>>960
早く寝ろ
早く寝ろ
958 名前：名無しさん＠編集中[sage] 投稿日：2009/06/21(日) 23:00:25 ID:VCsyBQAK
utvideoはゲーム取り込みに良いと思ったけど、もうちょっと負荷軽いの他にあるかな
デュアルコアで1コアゲームで占有させるとちょっと厳しい
959 名前：955[sage] 投稿日：2009/06/21(日) 23:39:17 ID:cQknHUja
>>958
俺の質問に答えろよ、池沼が
典型的な汚物連合職員(笑)
連合職員は乞食在日朝鮮土人と民主党議員つれて朝鮮半島へ帰れよ。
日本にしがみつくな。
utvideoはゲーム取り込みに良いと思ったけど、もうちょっと負荷軽いの他にあるかな
デュアルコアで1コアゲームで占有させるとちょっと厳しい
959 名前：955[sage] 投稿日：2009/06/21(日) 23:39:17 ID:cQknHUja
>>958
俺の質問に答えろよ、池沼が
典型的な汚物連合職員(笑)
連合職員は乞食在日朝鮮土人と民主党議員つれて朝鮮半島へ帰れよ。
日本にしがみつくな。
UtVideoの配布先鯖落ちてる…
ミラー探してみても見つからないんだがミラーってそもそも存在する？
ミラー探してみても見つからないんだがミラーってそもそも存在する？
>>963
おい、誰に向かって口聞いてんだ？ぁ？
おい、誰に向かって口聞いてんだ？ぁ？
Ut Video + PremierePro 使ってるんですが、
ちょっと確認？質問？させてください。
民生用AVCHDカムで撮影したソース(Canon HF10)を
UtVideoでエンコする時の色空間は、YUV420でいいんですよね？
あと、YUV420なソースでより上位な(？)色空間、
たとえばYUV422を使っても、問題ナッシン？
ちゃんと元ソースのYUV420でなきゃダメ？
ちょっと確認？質問？させてください。
民生用AVCHDカムで撮影したソース(Canon HF10)を
UtVideoでエンコする時の色空間は、YUV420でいいんですよね？
あと、YUV420なソースでより上位な(？)色空間、
たとえばYUV422を使っても、問題ナッシン？
ちゃんと元ソースのYUV420でなきゃダメ？
>>968 ＆ >>970 です。
>>969 で回答を頂きましたが、また混乱してきました。(汗
話では、出力の時点でRGB指定で書き出してやればおｋとのこと。
でも、色空間変換時のパターンはいくつかあるわけですが、
下記のどの手順が最も劣化を抑えられるんでしょうか？
やっぱ969さんが仰った(2)なんでしょうか？
ソースは AVCHD、エンコは TMpgEnc4.0Xpress + UtVideo、
編集は PremireProCS3、オーサリングは TMpgEncAuthoringWorks4 です。
(1) 色空間YUVオンリーの場合
ソース（YUV420） ⇒ エンコ（YUV420） ⇒ PremierePro【内部RGB32】 ⇒ 書き出し（YUV420） ⇒ オーサリング
(2) Premiereの書き出しにRGB変換する場合
ソース（YUV420） ⇒ エンコ（YUV420） ⇒ PremierePro【内部RGB32】 ⇒ 書き出し（RGB32） ⇒ オーサリング
(3) Premiere編集前にRGBに変換する場合
ソース（YUV420） ⇒ エンコ【RGB変換】 ⇒ PremierePro ⇒ 書き出し（RGB） ⇒ オーサリング
(4) 手順(3)のPremiereで書き出しの際、YUVに戻してやる場合
ソース（YUV420） ⇒ エンコ【RGB変換】 ⇒ PremierePro ⇒ 【YUVに変換】 ⇒ オーサリング
はぁ～色空間ってムズいですねェ。
お詳しい方、教えて下され。
>>969 で回答を頂きましたが、また混乱してきました。(汗
話では、出力の時点でRGB指定で書き出してやればおｋとのこと。
でも、色空間変換時のパターンはいくつかあるわけですが、
下記のどの手順が最も劣化を抑えられるんでしょうか？
やっぱ969さんが仰った(2)なんでしょうか？
ソースは AVCHD、エンコは TMpgEnc4.0Xpress + UtVideo、
編集は PremireProCS3、オーサリングは TMpgEncAuthoringWorks4 です。
(1) 色空間YUVオンリーの場合
ソース（YUV420） ⇒ エンコ（YUV420） ⇒ PremierePro【内部RGB32】 ⇒ 書き出し（YUV420） ⇒ オーサリング
(2) Premiereの書き出しにRGB変換する場合
ソース（YUV420） ⇒ エンコ（YUV420） ⇒ PremierePro【内部RGB32】 ⇒ 書き出し（RGB32） ⇒ オーサリング
(3) Premiere編集前にRGBに変換する場合
ソース（YUV420） ⇒ エンコ【RGB変換】 ⇒ PremierePro ⇒ 書き出し（RGB） ⇒ オーサリング
(4) 手順(3)のPremiereで書き出しの際、YUVに戻してやる場合
ソース（YUV420） ⇒ エンコ【RGB変換】 ⇒ PremierePro ⇒ 【YUVに変換】 ⇒ オーサリング
はぁ～色空間ってムズいですねェ。
お詳しい方、教えて下され。
Lagarith Lossless Video Codec Version 1.3.20 Release
http://lags.leetcode.net/codec.html
アップサンプリング機能がついたんだそうな。
あとインストーラーが64bit対応した。
http://lags.leetcode.net/codec.html
アップサンプリング機能がついたんだそうな。
あとインストーラーが64bit対応した。
>972
Prevent・・・逆じゃないか？
Prevent・・・逆じゃないか？
>>971
PremiereにAVIくわせるんならRGBにしといたほうが、処理が減る
オーサリングするんなら、インタレのこともあるし、YUY2あたりが無難
ってなわけで、俺なら
AVCHD→RGB32→Premiere→YUY2→オーサリング
かな
PremiereにAVIくわせるんならRGBにしといたほうが、処理が減る
オーサリングするんなら、インタレのこともあるし、YUY2あたりが無難
ってなわけで、俺なら
AVCHD→RGB32→Premiere→YUY2→オーサリング
かな
[UtVideo] バージョン 5.2.3
バグ修正
共通: 特定の性質を持つフレームをエンコードする際に、稀にフレームが破損する。
バグ修正
共通: 特定の性質を持つフレームをエンコードする際に、稀にフレームが破損する。
zerocodecつーのを開発したそうだ。
http://x-row.cc/blog/download/zerocodec.php?file=100
開発途上で、たいした事なさそうな臭いがするが一応情報共有と言うことで。
http://x-row.cc/blog/download/zerocodec.php?file=100
開発途上で、たいした事なさそうな臭いがするが一応情報共有と言うことで。
適当にAviUtlで出力してみたが圧縮も遅いしサイズも縮まない(huffyuv比)
おまけに再生したらノイズだらけで全然可逆じゃない
使えませんな
おまけに再生したらノイズだらけで全然可逆じゃない
使えませんな
979 ：名無しさん＠編集中：2009/07/09(木) 18:58:22 ID:YKALP87c
在日が支配しとるテレビ・パチンコ広告が頼みの新聞じゃ絶対報道しない、黒すぎる小沢・鳩山が国会でコテンパンになっとる！！
6/29国会で小沢・鳩山フルボッコ 1
http://www.youtube.com/watch?v=g6VZ5ODch5w&eurl=http%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fuser%2F875ex82z&feature=player_profilepage
6/29国会で小沢・鳩山フルボッコ 2
http://www.youtube.com/watch?v=A-WLOqN-CbA&eurl=http%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fuser%2F875ex82z&feature=player_profilepage
6/29国会で小沢・鳩山フルボッコ 3
http://www.youtube.com/watch?v=vNXMPBBUKpw&eurl=http%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fuser%2F875ex82z&feature=player_profilepage
マスゴミが全力スルーでかばう両者がフルボッコにされて見ていて非常に気分がいい！
6/29国会で小沢・鳩山フルボッコ 1
http://www.youtube.com/watch?v=g6VZ5ODch5w&eurl=http%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fuser%2F875ex82z&feature=player_profilepage
6/29国会で小沢・鳩山フルボッコ 2
http://www.youtube.com/watch?v=A-WLOqN-CbA&eurl=http%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fuser%2F875ex82z&feature=player_profilepage
6/29国会で小沢・鳩山フルボッコ 3
http://www.youtube.com/watch?v=vNXMPBBUKpw&eurl=http%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fuser%2F875ex82z&feature=player_profilepage
マスゴミが全力スルーでかばう両者がフルボッコにされて見ていて非常に気分がいい！
元のところにも微妙と書いてたし最適化はこれからと書かれてたから今後に期待で。
方向性はamvコーデックと同じだろうし。
方向性はamvコーデックと同じだろうし。
アマレココとアマレコライトで試してみたけど、>>978と同じくグチャグチャになっちゃうな。
いまのところAMVよりもかなり重いので今後に期待かな。
いまのところAMVよりもかなり重いので今後に期待かな。
期待度zerocodec
zerocodecはzlibベースのようだ。zlibベースなら既に老舗で仕様が公開されているLCLがある(*1)わけで。
*1 http://wiki.multimedia.cx/index.php?title=Lossless_Codec_Libraries
中途半端なものを作るだけで注目されるってのが納得出来んなぁ。まぁ改善する気があるなら頑張ってほしいけど。
*1 http://wiki.multimedia.cx/index.php?title=Lossless_Codec_Libraries
中途半端なものを作るだけで注目されるってのが納得出来んなぁ。まぁ改善する気があるなら頑張ってほしいけど。
元祖国産コーディックはパナソニックのH.264Losslessで十分だよ。
もう980超えてるし20分ぐらいしたら次スレ立ててくるわ。
スレタイは「映像可逆圧縮総合スレPart3」にするけどいいよな。
たまに音声の話で迷いこんでくる奴がいるし、その予防ってことで。
代表的なコーデックリストは>>11のやつに
UtVideoとAMV2/3を加えた奴でいいよな？
あと非可逆スレは過疎ってるし書かなくてもいいよな。
スレタイは「映像可逆圧縮総合スレPart3」にするけどいいよな。
たまに音声の話で迷いこんでくる奴がいるし、その予防ってことで。
代表的なコーデックリストは>>11のやつに
UtVideoとAMV2/3を加えた奴でいいよな？
あと非可逆スレは過疎ってるし書かなくてもいいよな。
長電話で遅くなってしまった…
http://pc11.2ch.net/test/read.cgi/avi/1247236230/
http://pc11.2ch.net/test/read.cgi/avi/1247236230/
次スレもたったようだし、埋めるか
今週信用全力買いで種の4割飛ばしました＞＜
これからどーすればよかとですか・・・
今週信用全力買いで種の4割飛ばしました＞＜
これからどーすればよかとですか・・・
>>988
信用売りして全部飛べ
信用売りして全部飛べ
もちろん来週からは売りで参戦予定だぜ！
ここはなんのスレなんだぜ？
資産は非可逆だったという事ですよ
そんな事より梅るんだ。
>992
可逆じゃ増やすこともできないしな
可逆じゃ増やすこともできないしな
株をギャンブル感覚でやるバカが多すぎる。
そういう奴がカモになるから儲けることもできるわけで
>>995
次スレヨロ
次スレヨロ
う
映像可逆圧縮総合スレ Part3
http://pc11.2ch.net/test/read.cgi/avi/1247236230/
http://pc11.2ch.net/test/read.cgi/avi/1247236230/
1000
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。