08/05/19 23:06:51 s83aWZ2h
>>99
display2aviとかdisplay2aviとか…金は払いたくないので
101:名無しさん＠編集中
08/05/19 23:17:15 3atCHZRB
YV12で出力出来るとDVDrip物でも使えるんだけど
102:名無しさん＠編集中
08/05/19 23:25:02 12bUl9nk
>>99
俺もkusunokiTVHDだけど駄目なんだがｗ
103:名無しさん＠編集中
08/05/19 23:36:59 EPY0jJVP
俺も楠だけど、無事使えてるよ。1.5時間ほど（映画1本）で、150Gくらいだった。
で、負荷はかかるけど、Q6600とRAID0で、そのまま再生できてる。
作者さんマジで乙です。VerUp期待してます。
104:名無しさん＠編集中
08/05/20 04:18:20 m0K2k4g9
作者が2ｃｈに降臨したりすると後々面倒だぜ
105:名無しさん＠編集中
08/05/20 20:26:58 IdSRUEJs
x64Vistaですけど、普通にくすのきで使えてます＞＜
106:名無しさん＠編集中
08/05/22 00:32:46 VPauiQFA
ふぬああのhunuaa AVI Muxで使えてるよ
４コア利用できて(ﾟдﾟ)
圧縮後のサイズがhuffyuvの半分になってくれれば
HDDに優しくなって更に(ﾟдﾟ)なんだけど期待していますよ
107:名無しさん＠編集中
08/05/22 19:54:25 NjRVPj6g
個人的にはｓｓｅ３とか４とかに対応してさらなる高速化に力を入れてほしいけど
まああんまり要望出し過ぎると>>104が言ってるみたいになりそうだし自重する。
中間ファイルに使うだけだから個人的には十分だからね。
108:名無しさん＠編集中
08/05/22 20:14:01 ezcIq3zv
UtVideoさっそくつかわせていただきました。
MxCapture 最新版 hunuaaAVI Muxで使えてます。
MonsterXでのTrid6200.sys 差し替え版でも問題なく動いている模様です。
2分強のD4ソースですがドロップフレームは発生しませんでした。
サイズはhuffyuvMTで4.5GBが UtVideoでは3.5GBまで縮んでいます。
再生もRAID組んでませんが、huffyuvMTよりもつっかかりが少なくスムーズです。
Q6600定格 DDR800 3GB です。
本当にありがとうございました。
109:名無しさん＠編集中
08/05/23 12:20:31 OG2cHwA+
huffyuvで4.5GBの場合、2.5ＧＢくらいにして欲しいです。
110:名無しさん＠編集中
08/05/23 13:09:20 k4OT17/s
それだけ減れば保険でRAID0にするのも必要なくなるな
111:名無しさん＠編集中
08/05/23 15:47:55 eQx9cUOR
正直、Huffyuvの1.5倍くらいの容量でもいいから、とにかく速度が速くなって欲しいな
112:名無しさん＠編集中
08/05/23 19:40:47 u9i0svRg
それなら無圧縮使えばいいんでない？
huffyuvは現在のCPUなら余力が残ってるけど
HDDの転送速度の余力が無いから、HDDの転送速度は進化が止まってるから
やはりcodecは圧縮率アップの進化の方が正当なんじゃないかな。
113:名無しさん＠編集中
08/05/23 20:36:01 oZyTbmSX
となると容量と速度にはある程度相関関係があると言うことなのか？
114:名無しさん＠編集中
08/05/23 20:43:01 eQx9cUOR
無圧縮は容量でかすぎて、流し確認する時に再生負荷がつらすぎる。
ので、Huffyuvの1.5倍くらいなら大丈夫だろうと。
115:名無しさん＠編集中
08/05/23 22:22:33 50K30CsQ
速けりゃいいんだったらfastcodecでいいんじゃないの
116:名無しさん＠編集中
08/05/23 23:08:48 j1qvtAY6
単純に言うと、メモリに展開する速度が
HDDから読み込む速度より早いコーデックなら容量が小さい方が早い。
117:名無しさん＠編集中
08/05/24 02:25:29 YPoXMwCE
UtVideo ver3.3.1きてるよ
Display2AVI で使えるようになったそうだ
製作者いわく「ちょっとしたバグFixなので現状で問題なかったらそのままどーぞ」だって。
ソースも公開されているから俺も開発追うかなあ…
118:名無しさん＠編集中
08/05/24 03:02:46 94EM19GZ
開発するのならもっと高圧縮の奴お願いします
119:名無しさん＠編集中
08/05/24 10:28:28 aPTtuwlh
Display2AVIで使える！ktkr
さらばHuffyuv、そしてようこそUtVideo
120:名無しさん＠編集中
08/05/24 11:03:23 q3JJoRE8
UtVideo Ver3.3.1を落とそうとするとなぜか拡張子が.manになる
121:名無しさん＠編集中
08/05/24 14:14:22 R2RscPGl
やべ、UtVideo今日始めて知った。これのフレーム分割ってCPUコア数で良いの？
122:名無しさん＠編集中
08/05/24 15:09:03 rNWOszZ2
CPU使用率の使い方を見る限りはコア数ですね。
UtVideo、Huffyuvの2/3と可逆では圧縮率申し分無いんだけど、
画質を少々削っても1/2くらいになる非可逆モードを追加して欲しいです。
123:名無しさん＠編集中
08/05/24 15:46:21 wf6O5Y55
どのコーデックも速度については、どんぐりの背比べだな。
C2QにてUtVideoでフレーム分割数4にしてもCPU負荷が30%弱なんだが、他の人も同じかい？
124:123
08/05/24 16:16:35 wf6O5Y55
フレーム分割数を大きくすると、ファイルサイズとエンコード時間が増える。
CPU負荷は1の時が一番高くてエンコード速度も速い。
フレーム分割数の説明きぼん
125:名無しさん＠編集中
08/05/24 16:43:34 aPTtuwlh
>>124
私もQ9450を使っていますが、フレーム分割数は1より4のほうが高速でした。
後、エンコ素材がシングルスレッドでデコードするものは確かに40％位で負荷が頭打ちでしたが、
マルチスレッドでデコードするものは最大で90％近くは使ってくれました。
どーでもいいですが、Aviutlで出力するときは、AVI出力（マルチスレッド）を使うといいかも
126:名無しさん＠編集中
08/05/24 17:03:38 mh6WNDqt
フレーム分割ってスレッド数のことだったのか
ググってみたら「AVIファイルをフレーム分割してgifファイルを～」みたいな解説サイトがあって？？？だった
127:名無しさん＠編集中
08/05/24 17:42:21 N1sKTTba
馬鹿すぎて泣ける
128:名無しさん＠編集中
08/05/24 19:11:39 wf6O5Y55
>>125
もっかい確認したけど、こっちでは分割数4より1のほうが速いね。
CPU負荷は30%前後、VirtualDub1.8使用。
ちなみにWMV9VCMをパフォーマンス100で使ったりするとCPU負荷は
50%を超えるのでVirtualDub自体はマルチスレッド対応かと。
CPUを効率的に利用するという点では、もちろんデコーダーからフィルタ
まで可能な限りマルチスレッド対応にしたほうがいいね。
129:名無しさん＠編集中
08/05/24 19:12:57 Nd5aE9pW
非可逆なんかいらん、MJPGでも使ってな
今望まれてるのは圧縮率と展開速度重視だね
130:名無しさん＠編集中
08/05/24 19:16:36 EJmeEROI
CPU負荷が高すぎてもソフトウェアキャプだと都合が悪いので30%前後でいいんじゃない。
むしろ4コアムラなく使ってる効率の良さを誉めたい。
131:名無しさん＠編集中
08/05/24 19:26:49 TDAy2Rul
>>129
MJPEGQ19とhuffyuvの間くらいのあったらいいじゃない。
アースDVの量子化マトリックスオール16みたいな奴。
132:名無しさん＠編集中
08/05/24 19:41:37 wf6O5Y55
>>130
そうか、キャプチャー用コーデックなら全くその通りだな。
しかしなぜかウチでは1コアだけ突出して負荷が高い・・・
ところで>>129は突然、非可逆の話を始めてどうしたんだ？
133:名無しさん＠編集中
08/05/24 19:59:57 9WvdDVyJ
可逆が出る前はMJPGが主流だったんす
そういう古参な話も聞いてやれよ
134:名無しさん＠編集中
08/05/24 20:51:45 +0G+BCvk
まぁまぁｗ
MJPGもそろそろ老朽化してきたしMJPGに変わるポストMJPGも欲しいじゃない。
俺は開発能力が無いので神頼みだけど。なによりスレ違いだし。
135:名無しさん＠編集中
08/05/24 23:02:29 WVuhb9OJ
そう言う奴は黙ってカノプHQでも使っておけばおｋ
136:名無しさん＠編集中
08/05/25 14:30:34 Zl7sfA6s
utvideoいいですね
RGBAもきぼんぬ
137:名無しさん＠編集中
08/05/25 16:02:02 bC/VqnTK
Utvideoってメディアプレーヤーだと逆さまになるな
138:名無しさん＠編集中
08/05/25 16:06:27 WsFPxeUx
うちではそんなこと無いけど
139:名無しさん＠編集中
08/05/25 16:20:27 ZZzgznHj
>>137
うちもなった
どう改善していいかわからないもんで、Aviutlでチェックしてる
140:137
08/05/25 16:21:33 bC/VqnTK
インストールするときトラブったから変になったのかな
141:名無しさん＠編集中
08/05/25 16:44:47 DYuDaiqh
ﾜｯｼｮｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｯｼｮｲﾜｯｼｮｲヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノﾜｯｼｮｲ
142:名無しさん＠編集中
08/05/25 16:45:24 DYuDaiqh
誤爆しました
143:137
08/05/25 21:19:16 bC/VqnTK
UtVideo3.4.0で上下反転しなくなったー。作者様ありがとー。
144:名無しさん＠編集中
08/05/26 01:50:38 rd6GV3qF
仕事が速いなぁ。頑張りすぎて途中でぽっきり折れたりしませんように。
145:名無しさん＠編集中
08/05/26 03:02:54 dQyo+7LN
あとはバグフィックスがメインじゃないかな
今でも十分使えるし
146:名無しさん＠編集中
08/05/26 09:30:43 95YJhl8a
>>135
それってこれ？
URLﾘﾝｸ(www.canopus.co.jp)
ただなのがいいけど、使えるコーデックなの？
147:名無しさん＠編集中
08/05/26 09:33:43 95YJhl8a
デコーダだけでした(´･ω･`)
148:名無しさん＠編集中
08/05/26 20:07:42 i9OJXKUW
使えるっていっても、まだhuffyuv_mtから乗り換えるような理由が薄いし
もっとガツっと軽くなるとか、売りがほしい
149:名無しさん＠編集中
08/05/26 20:13:01 tIcsrYy1
まぁ結局中間ファイルだからなぁ…
積極的に乗り換える理由もないけど俺は新しいもの好きだからutvideoに切り替えたわ。
今のところ安定して使えてるし元がでかいから量が増えたら違いもばかにならんしな。
150:名無しさん＠編集中
08/05/26 20:16:18 Vjabn/Ef
Lagarithのが縮むし
151:名無しさん＠編集中
08/05/26 20:17:58 tIcsrYy1
残念ながら俺のしょぼいPCじゃLagarithは問題外
152:名無しさん＠編集中
08/05/26 20:26:18 8NHENfQ8
圧縮速度が速くなるとうれしいんだが
153:名無しさん＠編集中
08/05/26 20:30:04 JbdcHOmJ
AthlonXP2500+でも使えるようになるとうれしい
154:名無しさん＠編集中
08/05/26 20:58:22 7WDobLWu
ﾓﾚも中間ファイルオンリーの使い方だけど、C2Qで
fastcodec
Huffyuv_mt
Huffyuv2.2
Lagarith
FFV1
UTvideo
を設定変えて試したけどHuffyuv2.2が一番速いわ。
部分的にマルチスレッド化しているHuffyuv2.1.1より速いのが意外。
>>149
可逆コーデックの使い道は、キャプチャと中間ファイルがあるから
そういう言い方すると、はぁ？とかいう奴がいるから気をつけるべし。
155:名無しさん＠編集中
08/05/26 21:09:53 tIcsrYy1
ああ、そうか。最近キャプボ買ったから思考が偏ってたわ…
156:名無しさん＠編集中
08/05/26 21:39:26 JbdcHOmJ
>>154
そんなに試したのなら研究発表してくれたらいいのに
157:名無しさん＠編集中
08/05/26 22:53:48 zju9+HGZ
自分はLagarithは色ノイズが出るから中間ファイルの対象外
158:名無しさん＠編集中
08/05/26 23:09:22 Wrqckhwr
ﾓﾚも（笑）
159:名無しさん＠編集中
08/05/26 23:31:08 I1mCo4Uq
TMPGEncだといまだになるけどVirtualDubなら平気だぜ
160:名無しさん＠編集中
08/05/26 23:37:51 7WDobLWu
>>156
自分のメモ程度な上に、たぶん正確じゃないよ。
161:名無しさん＠編集中
08/05/27 18:26:05 BpQWIP+g
うーん、UtVideo3.40でとったファイルが、UleadのMediastudioPro8で
BMPファイルはサポートされてません。
って蹴られる。
どうしてだろう？
162:名無しさん＠編集中
08/05/27 18:28:52 BpQWIP+g
上。yuv422で撮った奴です Aviutlでは問題なく開けましたが。
163:名無しさん＠編集中
08/05/27 18:30:56 BpQWIP+g
RGBモードならうまくいった。 MS8proの問題かな？
164:名無しさん＠編集中
08/05/28 05:17:32 HmGTqhkT
UtVideoの配布先、落ちてる？
OS再インストールしたんで、コーデック拾いに行ったんだが… orz
165:名無しさん＠編集中
08/05/28 05:27:36 JB8Qx2fO
落ちてるね
ドメイン見ると自鯖だな
2,3ミラーしているとこがあったはず
166:名無しさん＠編集中
08/05/28 05:36:34 HmGTqhkT
>>165
ありがとう。
ちょっと探しに行ってくる。 ノシ
167:名無しさん＠編集中
08/05/28 05:48:23 8EpU3fUT
GPLってうｐしてもいいんだっけ？
うｐしようか？
168:名無しさん＠編集中
08/05/28 05:59:19 HmGTqhkT
>>167
探してたんだが、検索キーがマズいのか見つからなかった…
可能ならば、うｐして欲しいです。
169:168
08/05/28 11:30:02 HmGTqhkT
先程配布先行ってみたら、無事復活してた。
やっぱり、鯖が落ちてたらしい…
>>167
改めて、お心遣い感謝！
170:名無しさん＠編集中
08/05/30 22:55:18 bW+iilcN
データが64bitsって分かってるときどうやったら最も効率よく可逆圧縮できますか？
つまり、2^64通りすべてを圧縮したとき圧縮率＝（圧縮後のbit数）/64の期待値を最小に
するような方法です。
171:名無しさん＠編集中
08/05/30 22:58:26 bW+iilcN
あ、ごめんなさい。技術的なスレじゃなかったですね。忘れてください
172:名無しさん＠編集中
08/06/02 07:50:19 tY6zP/fE
UtVideo使わせてもらってます。
VirtualDubModで読み込むと
必ずエンコ終わりで落ちるんですが私だけ？
エンコ自体は成功してるので別にいいんですけど
他の可逆だと落ちないんで。
173:名無しさん＠編集中
08/06/02 08:22:30 jBOqgS8m
>>172
俺もなった
174:名無しさん＠編集中
08/06/02 09:08:07 4BvjoUH1
>>173
俺はならない
175:名無しさん＠編集中
08/06/02 22:01:14 7e2lEb1T
[UtVideo] バージョン 3.5.0
176:名無しさん＠編集中
08/06/02 22:21:49 zwICSPmw
>>172
俺はVirtualDubModでプレビュー再生して停止させたときに落ちる
なんとかなりませんか
177:名無しさん＠編集中
08/06/02 23:27:04 lI4mMKWx
[UtVideo] バージョン 3.5.0
機能追加
ULY2: デコード時に RGB24 で出力できるようにした。最初からアセンブラバージョンがある。
バグ修正
ULY2: RGB24 エンコード時に、横幅が 4 の倍数ではない場合、映像の右端にゴミが発生する。
readme ファイル インストーラ（msi 形式） ソース
ULY2 の RGB24 出力ですが、これにより MS8 や VS12 で読み込めるようになるはずです。
178:名無しさん＠編集中
08/06/03 13:41:43 iczBx5hQ
UtVideo唯一の欠点
作者がニコ厨
179:名無しさん＠編集中
08/06/03 18:17:06 FU5uVkNk
作者の方、アップデートご苦労様です。
BUGFIXがうまくいったか、試してみたいところですが、ちょっと忙しいので待ってください。
180:名無しさん＠編集中
08/06/03 21:32:31 7HOVXjn8
Lagarithほどじゃなくてもhufyuvよりはノイズがあんだけど…
181:名無しさん＠編集中
08/06/04 00:03:38 B2lgVLnd
他の可逆よりhufyuv系の方が画質がいい感じがするんだが気のせいかな
182:名無しさん＠編集中
08/06/04 00:06:22 v4PS2MMU
それってもう可逆じゃないじゃん
183:名無しさん＠編集中
08/06/04 00:07:32 jiB0Rlk+
気のせい
184:名無しさん＠編集中
08/06/04 00:29:22 1AQBZ3qk
爆釣ですね＞＜
185:名無しさん＠編集中
08/06/04 02:33:30 jiB0Rlk+
[UtVideo] バージョン 3.6.0
性能向上
ULY2: RGB24 からのエンコードをアセンブラ化により高速化した。Core 2 の場合で 42% 程度。これでシングルスレッドでも Huffyuv (Predict median) より有意に速くなった。
乙です
186:名無しさん＠編集中
08/06/04 07:54:32 1AQBZ3qk
UtVideoの作者さん乙です。更新はやいな～。
この調子でYUV出力でもHuffYUV2.2より速くなるといいんだが。
187:名無しさん＠編集中
08/06/04 12:28:25 5bkHrXyf
速さの次は出力サイズをHuffYUVの半分にする方向性だな
188:名無しさん＠編集中
08/06/04 15:35:20 fj9WsSbY
10MB/sくらいになればいいなあ
189:名無しさん＠編集中
08/06/04 19:22:06 nx9UtSxp
スレ違いとは思いますが、
いつからか、編集ソフトで作ったファイルをエクスプローラで選択しようとするだけで、
コーデックの種類によってはアプリケーションエラーが出るようになってしまいました。
現状、無圧縮、DV、wmvは大丈夫なのですがHuffYUV、UtVideo、CanopuHQはダメです。
エラーメッセージは以下のような感じです。
～の命令が～のメモリをアクセスできませんでした。
メモリはwritenになることができませんでした。
原因分かりませんでしょうか？
190:名無しさん＠編集中
08/06/04 19:28:50 1AQBZ3qk
>>189
スレ違いと思いながら質問しないでくれ。
次からはWindows板かどっかのエスパースレ池
コーデックパックなんかを入れるとおかしくなる事がある、としか言えない。
191:名無しさん＠編集中
08/06/04 19:31:25 6/ypPIwZ
>>189
>>80かもよ
192:名無しさん＠編集中
08/06/04 19:35:15 1AQBZ3qk
とりあえず直したいだけなら、OS再インスコするか、エクスプローラーの情報を取得を
簡易ツール使ったり、レジストリ弄ったりして止めればいい。
例えば、ここの２とか。
URLﾘﾝｸ(element.dip.jp)
193:189
08/06/04 20:18:18 nx9UtSxp
>>190,191,192
怒涛のレスありがとうございます。
>>190さん、>>191さんを参考にffdshowコーデックパック、Nero7をアンインストール
しましたが同じでした。
ところが、>>192さんを参考にレジストリを書き換えると、おお～！、直りました。
ちょっと強引な方法みたいですが、にっちもさっちも行かない状態だったので
大変助かりました。
本当にありがとうございました。
194:名無しさん＠編集中
08/06/07 23:44:54 ki6U6zEN
Ut更新きてる
[UtVideo] バージョン 3.7.0
URLﾘﾝｸ(umezawa.dyndns.info)
195:名無しさん＠編集中
08/06/07 23:54:00 kRIAQb4g
圧縮率設定も欲しい。
196:名無しさん＠編集中
08/06/08 00:18:38 KsNIpn5H
>>195
たしかに欲しいかもね。
速度重視、圧縮重視、その中間、ぐらいで3段階程度を
197:名無しさん＠編集中
08/06/08 00:32:45 s3nRkH2k
リアルタイムエンコに必要な推奨はintelのCPUならば
速度重視（速度速いが圧縮小）:E1200
中間（速度も圧縮も中間）:E6600
圧縮重視（速度遅いけど圧縮大）:Q9450以上
で
198:名無しさん＠編集中
08/06/08 02:04:00 lrYwOe/Z
YV12への対応を･･･
199:名無しさん＠編集中
08/06/08 02:06:02 B0qjF1jx
UtVideoのインストールがIncompleteになるんだが、
OSがXP MCEだとダメなんかな。
200:名無しさん＠編集中
08/06/08 13:11:19 yGtnXbQg
YV12の対応俺も欲しい
201:名無しさん＠編集中
08/06/08 13:34:00 glL6EwKo
俺も
202:名無しさん＠編集中
08/06/08 13:52:19 qB9FhAIa
YV12は切実に欲しい
TWriteAVIを結構使うが、可逆でYV12だとLagarithくらいしかないんだもん
203:名無しさん＠編集中
08/06/08 17:16:09 /VoNenLr
UtVideoやHuffYUVで圧縮すると、メディアプレーヤでは再生できるのに、
AVIutlで読み込むと、上半分が真っ黒で下半分がノイズの画面になってしまいます。
無圧縮だと大丈夫です。何かの設定でしょうか？
204:名無しさん＠編集中
08/06/08 20:16:16 dbxqssaN
>>203
0.99dで俺もなるな
だから0.99c使ってる。
205:名無しさん＠編集中
08/06/08 20:28:28 3q6EjECo
>>203
おいらは大丈夫だよ。0.99ｄ3で、UtVideo。
Vista ultimateSP1。
206:名無しさん＠編集中
08/06/08 20:33:36 DOEVq503
おいら（笑）
207:名無しさん＠編集中
08/06/08 20:34:25 2yy2J6OQ
だってそれはAviUtlの設定のせいだもん
おかしいとか言うやつはよくわからないくせにデフォから設定弄るなよ
208:名無しさん＠編集中
08/06/08 20:38:04 3q6EjECo
huffyuv_mt_712でもやってみたけど、問題なし。
アニメじゃ問題でないのかな？
実写ですか？
209:名無しさん＠編集中
08/06/08 20:54:29 3q6EjECo
昨日のサッカーの一部をhuffyuv_mt_712、UtVideo3.7でエンコしてみましたが、203さんのような
症状は出ませんでした。
ただ、UtVideo3.7はエンコ終了時AVIutlが落ちましたｗ出来たファイル自体は正常です。
210:名無しさん＠編集中
08/06/08 21:00:29 3q6EjECo
連続カキコ失礼します。
>UtVideo3.7はエンコ終了時AVIutlが落ちましたｗ出来たファイル自体は正常です。
もう一度エンコしたら落ちませんでした。
211:203
08/06/08 23:35:28 /VoNenLr
いろいろレス、サンクス。
その後調べてみると、PremierePro1.5からの出力はダメで、AVIutlから出力した
ファイルはちゃんと読めました。
編集ソフトによって変わることって有りますでしょうか？
212:名無しさん＠編集中
08/06/09 01:54:36 t2OjGTEg
で、UtVideoインスコできないのは俺だけかな。
他にXP MCEで使ってる人いない？
213:名無しさん＠編集中
08/06/09 03:59:40 ZQkQZtGB
>>212
Microsoft Visual C++ 2005 SP1 再頒布可能パッケージ (x86)
↑readmeに書いてるこれ入れた？
214:名無しさん＠編集中
08/06/09 08:24:33 YmOxbdPz
>212 ｲﾝｽｺしてみた。まだDxCaptureでしか使ってないけど動いてるよ。
215:名無しさん＠編集中
08/06/09 11:55:36 mBVd97cN
コンセプトとずれてるかもしれないけど
RGBAのことも片隅に考えて置いてください
216:名無しさん＠編集中
08/06/10 02:40:24 PKGDmeWX
[UtVideo] バージョン 3.8.0
URLﾘﾝｸ(umezawa.dyndns.info)
機能追加
共通: Predict left フレーム内予測方式を追加した。
手元の計測では、今までの実装（Predict median）と比較して、
エンコード速度ほぼ同じ、圧縮率 10% 低下（ファイルサイズが 10% 増える）、
デコード速度 50% 向上（デコード時間が 30% 強短くなる）。
作者の人の人本当にお疲れ様です。
217:名無しさん＠編集中
08/06/10 02:56:22 PoYXaeGE
> デコード速度 50% 向上
まじっすか
218:名無しさん＠編集中
08/06/10 03:01:35 pYJi+xSf
つええなぁ。ゲームの動画なんか撮っててRGBのまま圧縮できる点ですごく重宝してる。
編集中に色が滲んでるの見るの好かないしｗ
219:名無しさん＠編集中
08/06/10 03:13:35 kVIf70Qq
作者氏乙ですがエンコード速度が下がっても圧縮率が上がるモードも欲しい。
220:名無しさん＠編集中
08/06/10 14:17:37 JdZnaoCb
おまいら、どんだけだよｗ
俺はしばらく様子見だな
221:名無しさん＠編集中
08/06/10 17:23:35 JcFzpHa9
いや、人柱がいないとソフトは発展しない
222:名無しさん＠編集中
08/06/10 19:30:30 yV7pOv9W
しかし、進歩の速いこの分野でUtv出るまでずっと鉄板だったhuffyuvが恐ろしい
223:名無しさん＠編集中
08/06/10 19:37:02 UMFHMrbl
超高解像度動画をリアルタイムキャプチャする用途が広まったのなんてつい最近だからね
圧縮にはハードウェアエンコーダ
速度はhuffyuv（シングル版）で十分だったからUtVideoほどの速度は求められてなかった
224:名無しさん＠編集中
08/06/10 19:47:14 7sJg/1hP
Utvideoには期待してるけど、現状ではHuffyuvに入れ替えられないよ・・・
225:名無しさん＠編集中
08/06/10 20:16:43 Iot7rgj0
スレチだけどPIC-MJPEGに変わる新・非可逆キャプ用コーデックが欲しい。
226:名無しさん＠編集中
08/06/10 20:17:28 arUmDCrj
>>224
なぜなのか書かないと意味ないよ
227:名無しさん＠編集中
08/06/10 20:31:31 7sJg/1hP
>>226
Huffyuvと比較して遅いから。
228:名無しさん＠編集中
08/06/10 20:37:13 RX+q5gRS
UtVideoを実験してみた
URLﾘﾝｸ(vcinema2.blog96.fc2.com)
229:名無しさん＠編集中
08/06/10 21:19:35 jBi8YpCD
無償で作ってるんだから頑張れよとしか俺にはいえない
230:名無しさん＠編集中
08/06/10 21:43:55 WKoMgyI5
UtVideoで必ずドロップするのであきらめてたんだけど、MxCaptureのプロセスの
優先順位をリアルタイムにしたらドロップしなくなった。
231:名無しさん＠編集中
08/06/10 21:56:13 DYEqIKxk
よりHuffyuv早くない？
232:名無しさん＠編集中
08/06/10 21:56:45 DYEqIKxk
訂正
Huffyuvより早くない？
233:名無しさん＠編集中
08/06/10 22:01:29 IQq9HrNj
優先度リアルタイムは暴走したときにマシンが完全に固まるから
さすがにやめといたほうがいいぞ…せいぜい「高」ぐらいで。
234:名無しさん＠編集中
08/06/11 00:14:12 uUxxilqn
UtVideo速くなったな。ほぼHuffyuvと互角だな。
中間にしか使わないからもっと速くなったら乗りかえようと思う。
235:名無しさん＠編集中
08/06/11 00:28:38 U+PDlj1w
訂正しても意味不明でﾜﾛﾀ
236:名無しさん＠編集中
08/06/11 00:41:13 q1ixIJEg
RGBAきたこれ
237:名無しさん＠編集中
08/06/11 00:43:33 tj+Ucchg
速くなったけど、HuffyuvをPredict leftにすると
Huffyuvの方がやっぱ速い・・・
UtVideoがんがれ！！
238:名無しさん＠編集中
08/06/11 06:19:26 MGPDUck5
もう4.0.1ですか・・
いやほんと、頭下がります。
239:名無しさん＠編集中
08/06/11 07:13:14 Hmb3BgVv
＞いやね、コード自体は 3.8.0 をリリースした後に千早をプロデュースしつつ
＞2時間弱で書いたんですよ。なんというジェバンニ。
ワロタ
240:名無しさん＠編集中
08/06/11 12:05:33 KhPjqI5B
>>239
DTV関連作者はアニヲタばかりだと思ったらアイマスに侵食されつつあるみたいだな
時代は2次元から2.5次元に進化しているのか
241:名無しさん＠編集中
08/06/11 20:12:46 U+PDlj1w
チンコたつかどうかだろ
進化もクソもない
242:名無しさん＠編集中
08/06/11 20:17:37 m+U8p/NW
映像作品だから当然ではある
人の趣味なんてどうでもいいが
243:名無しさん＠編集中
08/06/12 05:28:02 xihHYelu
作者がニコ厨じゃなけりゃなあ・・・
244:名無しさん＠編集中
08/06/12 06:05:02 LW/WTugL
んなもんどうでもよし
245:名無しさん＠編集中
08/06/12 10:18:46 H7t9iQPx
嫌なら使わなければいいだけ。
他人の趣味にどうこう言う資格なし。
246:名無しさん＠編集中
08/06/12 10:36:40 Y1Dkellq
同じことを繰り返し言ってる(コピペしてる)事から、UtVideoを
潰そうとしてるんだろうけど目的はなんだろうね。
それとも単なるゴミの嫌がらせか？
247:名無しさん＠編集中
08/06/12 11:55:53 4t9SROcL
嫉妬だろ。
UtVideoは優れているし、VerUpも早いし、実際問題なく使えるし
作者はゲームしながらコード書けるほど、有能だし。
批判にもならない難癖をつけて、自分の感情を満足させたいだけ。
でもこの世は実績勝負だから。
UtVideoを作った時点で、HD動画でのキャプチャー、編集、エンコードに
ほんとうに世界的な一歩を記したのは間違いない。
huffyuvとためをはる、日本製の可逆圧縮codecだぜ。ほんとうにすごいことなんだけどな。
248:名無しさん＠編集中
08/06/12 11:58:47 U3Q+GNAF
いや、単純にニコニコ動画がすげー嫌いなだけなんじゃね？ｗ
坊主憎けりゃなんとやらで
249:名無しさん＠編集中
08/06/12 12:17:28 MiEpIvsm
つーか、Huffyuvのマルチスレッドタイプは何故か漏れのところでは安定性が悪い．．．
のでUtVideoを重宝してる。
UtVideoにしてから（マルチスレッド動作が使えるので）、AviUtl-H264エンコ時間が結構速くなった。
これ、以前と比べ可逆デコード処理部分も並列処理になった（結果的に処理全体が並列化）だけだが、
きっちり計ってはいないものの感覚的には15％くらいはエンコ時間短縮になってる雰囲気。
なお、現状（ver3.4）ではコード自体の速さだけならHuffyuvと同等か若干速い程度と思う。
（ver4.0.1は昨日インスコしたばかりでまだ使ってない）
作者に謝々。
250:名無しさん＠編集中
08/06/12 12:31:54 MiEpIvsm
当方、ふぬああと組み合わせてHD映像（D3)の可逆圧縮キャプチャーが主な用途だが、これまで
FastCodec、AlparySoft、Huffyuv．．．といくつかの評判のいい可逆コーデックを試してみて
その中ではやはりHuffyuvが一番だったのでずっと使ってきた。
今回Huffyuvを越えるポテンシャルをもったUtVideoという和製ソフトが出てきたことは嬉しい限りだね。
251:名無しさん＠編集中
08/06/12 13:09:48 tlAME/k5
あとはストライピングが組めない貧乏人の為に圧縮率アップに励んでもらいたい。
huffyuv 1920x1080 *D3 30MB/s
UtVideo 1920x1080 *D3 15MB/s
が理想。だって俺のマザーVIAの糞チップのせいで150MB/sモードしか使えないんだもん。
252:名無しさん＠編集中
08/06/12 13:57:40 tQ82pvlS
･･･
253:名無しさん＠編集中
08/06/12 15:20:29 p4lnNoWe
可逆は限界あるだろ・・・
圧縮率アップ＝エンコードに時間かかるようになるってことだし
無茶言うのが多いな・・・
254:名無しさん＠編集中
08/06/12 15:54:11 Pa22B5u7
だったら非可逆モードを追加すればいい。
255:名無しさん＠編集中
08/06/12 16:09:37 zOYlG7mn
3フレームGOPにしたら画質犠牲にしないで縮みそう。
256:名無しさん＠編集中
08/06/12 16:12:27 LW/WTugL
RAIDカードぶちこめば？
257:名無しさん＠編集中
08/06/12 20:01:56 mVPYzTEj
中の人とかどうでもいいよ
258:名無しさん＠編集中
08/06/12 20:13:13 A+dMbQtU
>>257
何の話だ
RAIDカード?
259:名無しさん＠編集中
08/06/12 20:52:12 H7t9iQPx
>>258
>>257が言ってるのは、中の人=UtVideoの作者のことだろう。
260:名無しさん＠編集中
08/06/12 21:22:05 QC3Gs1Ad
↓のLagarithはいいね圧縮率で他を圧倒している。
URLﾘﾝｸ(www29.atwiki.jp)
261:名無しさん＠編集中
08/06/12 21:22:55 Y1Dkellq
>>249
>UtVideoにしてから（マルチスレッド動作が使えるので）、AviUtl-H264エンコ時間が結構速くなった。
これってどういう事？中間にUtVideo使ってるって事？
ちなみにウチではまだHuffyuvがメインなんだが、クアッドで4コア全部使い果たしてくれるぞ。
HuffyuvはMT版じゃなくて、Huffyuv2.2.0ね。
262:名無しさん＠編集中
08/06/12 21:33:31 jDkahsQV
少し前に張ってあったリンクにも出てたけど
UtVideoからのエンコだとデコード性能の分だけ速くなるよ
フィルター含めてエンコードの設定が軽ければ軽いほど差が出てくるね
入り口のボトルネックが広くなるわけだからね
263:名無しさん＠編集中
08/06/12 21:49:21 NAnE5SgG
軽いだけならHuffyuvのleftも十分軽いけどな
要は用途に合わせて使い分ければいいんだけどね
264:名無しさん＠編集中
08/06/12 22:28:30 oopHg+YE
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(ja.wikipedia.org)
265:名無しさん＠編集中
08/06/12 22:29:36 mVPYzTEj
ハーフワイユーブイって読むんだ
266:名無しさん＠編集中
08/06/12 22:55:33 MiEpIvsm
>>261
もちろん中間使い。
うちはデュアルコアだが、中間可逆がシングルスレッドモード（Huffyuv2.2.0)だと
AviutlとX264を2スレッド指定にしていても2つのコアに目に見える負荷差が出て
トータルCPU負荷が50％～65％にしかならない。差は中間可逆のデコード処理が
相変わらずシングルだからだと思う。
中間可逆もマルチスレッド動作のもの（UtVideoなど)にするとそういう現象がなくなり、
両コアが同レベルで稼動してトータルCPU負荷も70％～85%程度になる。
これうちだけの現象？
267:名無しさん＠編集中
08/06/12 23:09:03 Y1Dkellq
>>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
268:名無しさん＠編集中
08/06/12 23:09:19 Y1Dkellq
"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
269:名無しさん＠編集中
08/06/12 23:13:36 Y1Dkellq
すまん。x264sってのは、seraphy氏のバイナリね。
"x264 core:59 r859 ce13bb6"
270:名無しさん＠編集中
08/06/13 00:42:09 9aIpC98M
Huffyuv恐ろしい子･･･
でも圧縮率とのバランスやキャプチャ用途で考えればUtVideoでよさそうだね
271:名無しさん＠編集中
08/06/13 00:58:31 20K9R2Bt
もうそろそろHuffyuv抜けそうですね作者さん頑張ってください
272:名無しさん＠編集中
08/06/13 01:50:19 ntK7cWe1
ニコ厨は後々必ずボロを出す
273:名無しさん＠編集中
08/06/13 01:50:52 uO7pFJSw
今の所、それぞれの使用環境によるけど無駄を省いていくと、
中間ファイル用→Huffyuv2.2.0
キャプチャ用→UtVideo
ってところかな。
UtVideoのデコード効率がよくなりHuffyuvを抜くのも間近か！？
274:名無しさん＠編集中
08/06/13 03:43:51 xv9ngt4A
俺は逆かな
キャプチャ用がHuffyuvで中間がUtVideo
NTSCやD3みたいにインターレースだとHuffyuvのほうがまだ強い
あとはエンコード、デコード効率が良くなればUtVideoオンリーでいけそう
275:名無しさん＠編集中
08/06/13 06:40:48 qvPTg+6m
>>272
んなこと言うならHuffyuvだって、2.1.1はCCESPパッチがあるし、
2.2.0なんてRGBバグ持ちのまま放置でボロだしまくりじゃねえか
276:名無しさん＠編集中
08/06/13 07:31:04 uO7pFJSw
荒らしに反応しているというよりHuffyuv2.2.0を使ってる人間をバカにしてるように見えるな。
誰もRGBなんて使ってないだろうに。
277:名無しさん＠編集中
08/06/13 07:40:44 hKcOiFcq
>>274
UtVideoはhuffyuvにくらべてD3でもデコードは現状でも十分速いと思うよ
エンコードはあまり違わないけどそれでも多少は速い
サイズに関しては似たり寄ったりなのでコンセプト的に限界なんだろうな
278:名無しさん＠編集中
08/06/13 09:40:05 U/OTLpmY
うちの環境だとHuffyuvがPremiere Elementsとすごく相性が悪いんでUtVideoはありがたい
279:名無しさん＠編集中
08/06/13 10:26:49 Q22Y5K7s
つか優先すべきは圧縮率でしょう。
キャプ用につかっても中間に使っても本数多かったり長時間だったりすると圧縮率は高いほどいい。
HDDを湯水のように買える金持ちは知らん。
280:名無しさん＠編集中
08/06/13 10:41:05 JksTnJOk
>>279
つ非可逆圧縮
281:名無しさん＠編集中
08/06/13 10:49:48 4z0riFcO
お前らよく考えろ。
作者がニコ厨云々言ってるやつは、それ以外はUtVideo完璧だと言ってるのと同じだぜ？
282:名無しさん＠編集中
08/06/13 12:33:28 5dzZ/rgq
つられすぎ
283:名無しさん＠編集中
08/06/13 14:49:52 iOVhrj5N
>>280
PIC-MJPEG以外のフリーで画質がいいキャプ用非可逆コーデックって何がありますか？
284:名無しさん＠編集中
08/06/13 19:23:04 KENR9LMQ
せっかく無視してきたのに
285:名無しさん＠編集中
08/06/13 21:30:09 d2HCpfer
>>278
俺も全く同じだ
286:名無しさん＠編集中
08/06/13 21:54:51 KENR9LMQ
adibe製はRGBじゃないとうまくいかないとか聞いたことあるけどそれのせいかもしれない
287:名無しさん＠編集中
08/06/13 22:21:01 d2HCpfer
>>286
そうなのか！ｼﾗﾝｶｯﾀ
ありがとう
288:名無しさん＠編集中
08/06/14 01:11:45 8GnGe2Dt
UtVideo唯一の欠点
~~~~~~~~~~~~~
作者がニコ厨
唯一の欠点
~~~~~~~~~~~~~
289:名無しさん＠編集中
08/06/14 02:03:19 oQDdL+Fa
もうそっとしといてやれよ
290:名無しさん＠編集中
08/06/14 07:05:57 BWvPXpka
Uさんの開発力に脱帽ｗｗｗ
これからも応援しようZe！
291:名無しさん＠編集中
08/06/14 07:30:26 /ax5GiZ4
読み方は欝ビデオでいいのかな？
292:名無しさん＠編集中
08/06/14 10:29:40 UGco6vKy
>>291
欝に成りたくないでござる(ry
293:名無しさん＠編集中
08/06/15 17:29:39 1YT2RWhH
このスレはUtVideoで盛り上がってるけど
俺が試した中ではhuffyuvやLagarith、ましてやUtVideoなんかより
YUY2 Lossless Codec (YLC) version 0.25
が一番優秀なんだけど
294:名無しさん＠編集中
08/06/15 17:35:35 tk8ISaKE
中間コーデックとして？
295:名無しさん＠編集中
08/06/15 17:54:56 PaNmC+4u
>>293
何が優秀なのか書け。
・エンコード/デコードが早い
・容量が小さくなる
・若干の非可逆を許容してる
とか比較の観点があるだろ。
296:名無しさん＠編集中
08/06/15 18:12:14 ij62XmyA
Q. 何が優秀なのか書け。
A. なんとなく。
297:名無しさん＠編集中
08/06/15 18:20:02 aeXZt52y
サイズは小さくなるがデコードが遅い感じ
298:名無しさん＠編集中
08/06/15 18:20:46 1YT2RWhH
このスレのレベルが低いのはわかったよ
もうこない
299:名無しさん＠編集中
08/06/15 18:23:00 43CD7pFt
よ ほ う 診 医 精 一 忠 は あ ま
さ う け 察 .者 神 度 告 て き さ
そ が .た を の 科 す た れ し
う の る な く
だ が ：
､＿__ ＿__ ：
(＿＿＿＿＿,／::::::::::::｀ヽ、
/::rー‐-ｰ-､:::l＿＿, , -─
_|:lr_‐､￣-=､l:::| /／
/)Y ´ﾟ｀ri ､'ﾟﾞ' |/,〉 /´
|｀ |l /ヽ _,ノｌ |ﾉ|
ヽ_| '-=ニ=-l !/
/|ﾊ -‐ /＼
＿,. -ｰ'`´ l l ＼ /'/! l`ー-､＿
300:名無しさん＠編集中
08/06/15 18:29:44 j/J1Ab5/
実際今まで話題になってないし優秀だというデータも提示しないで逆ギレだもんな。
でもAviUtl本家ので今まで話題になってないってのは不自然な感じだけど
使ったことある人いるのかな。
301:名無しさん＠編集中
08/06/15 18:31:22 bhAfbilc
＞でもAviUtl本家ので今まで話題になってないってのは不自然な感じだけど
作成されのは大分前っぽいけど、公開されたのがかなり遅かったからじゃない？
302:名無しさん＠編集中
08/06/15 19:32:59 M4/9Si7e
>>293
オレも最初そう思ったけどな
以前エンコしたものと比べるとぼやけてたからやめた
303:名無しさん＠編集中
08/06/15 20:11:56 NsnhlS5l
>>300
使ったことあるけど>>302と同じ感想。
304:名無しさん＠編集中
08/06/15 20:41:31 j/J1Ab5/
>>302-303
なるほど。Losslessでもぼやけるんならいまいちかな。
まあaviutlが優秀すぎるんでコーデックまでは望まないからいいんだけど。
305:名無しさん＠編集中
08/06/15 20:52:31 Dg8fNU4M
自演なの？
釣りなの？
ぼやけるわけないじゃんｗ
306:名無しさん＠編集中
08/06/15 21:12:23 aeXZt52y
readme読めよ
307:名無しさん＠編集中
08/06/15 21:17:02 Dg8fNU4M
YUY2形式の可逆圧縮codecです。
動画編集時の中間ファイル保存等のお役に立てば幸いです。
SSE(MMX2)命令を使用していますのでSSEの使えるCPU専用です。
RGB形式での入出力にも対応していますがRGB<->YUY2変換が
入る為に画質が劣化したり若干処理速度が低下したりします。
＞劣化
ぼやけるわけないじゃんｗ
308:名無しさん＠編集中
08/06/15 22:22:51 vgKATWMk
劣化するからぼやけるんじゃね
309:名無しさん＠編集中
08/06/15 22:53:17 +eVlioOH
RGBからYUY2に変換される時に何が起こってるか知らないんじゃね。
一般的に用いられる映像じゃ仮にそれがRGB→YUY2変換されても違いなんか気づけないし。
310:名無しさん＠編集中
08/06/15 23:23:50 43CD7pFt
YUY2とか色減るし ロスレスじゃないし
311:名無しさん＠編集中
08/06/15 23:37:42 bhAfbilc
RGBから変換する奴ってそんなにいるんだ。
自分の場合はAviSynthから中間ファイルでHuffyuvのYUY2使ってたよ。
312:名無しさん＠編集中
08/06/16 00:08:28 jywTwT5V
YUY2のみで済む人はリップ厨が多い事実
すべてではないけどさ
313:名無しさん＠編集中
08/06/16 00:18:20 Ve1bGPvZ
色空間にまでこだわってるなら、可逆圧縮にこだわる必要あるんか？
314:名無しさん＠編集中
08/06/16 13:12:40 nmH9eaVA
aviutl使わない俺的にはRGBの必要性を感じない
315:名無しさん＠編集中
08/06/16 19:23:33 eSso243P
YUY2やYV12の方が重要だ
316:名無しさん＠編集中
08/06/16 20:56:38 PnWBa8Fy
色空間についてじゃなくて単にDg8fNU4Mの「ぼやけるわけが無い」発言に対してのレスだろ？
ありえないと断言して馬鹿にするようなこと言ってたからだ。
317:名無しさん＠編集中
08/06/16 21:00:16 Ve1bGPvZ
結局YLCは優秀なのか？
huffyu 20GがYLC 13Gとか縮むけど
318:名無しさん＠編集中
08/06/16 21:40:04 eO/p7ZLa
>>311
RGBが必要な人は案外多いよ
市販の編集ソフトでMADとか作ってる連中とかね
UtVideo作者もこいつらのために作ってるようなもんだろ
319:名無しさん＠編集中
08/06/16 22:54:13 DCsyACwc
上でぼやけるとか言ってるのは釣りでしょ。いつまで引っ張るつもりだ。
>>318
ほー、そうなんだ。井の中の蛙とはまさに自分の事だったわ。
320:名無しさん＠編集中
08/06/17 00:12:35 ItSmyuM4
＞「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
＞「Ut Video Codec Suite」は「ユーティー ビデオ コーデック スイート」と読むんだよ！
＞
＞大事なことなので2度言ったよ！
だそうです。
321:名無しさん＠編集中
08/06/17 00:44:44 J4kzLiI1
要するに一般ユーザーはUtVideoよりYLCのほうが使えるってことだねｗ
322:名無しさん＠編集中
08/06/17 00:54:02 7ZdOqkRC
正式名称は判明したけど愛称は欝ビデオということですね。
323:名無しさん＠編集中
08/06/17 02:30:29 03ZRTj7H
俺もゲームをキャプチャしたり編集するからRGBが無いと困るなあ
今までまともに使えるのはHuffyuvだけだったからUtVideoはありがたいね
324:名無しさん＠編集中
08/06/17 03:18:14 NI9Mfsit
Premiere Elementsが偏食で困る。すげーわがまま。UtVideoは本当にありがたい
325:名無しさん＠編集中
08/06/17 19:29:04 XcMeOqwS
高圧縮タイプのUtVideoまだぁ？
326:名無しさん＠編集中
08/06/17 19:35:41 wPmuvlqm
MSU使え
327:名無しさん＠編集中
08/06/17 19:57:57 ZA7NTWRl
UtVideo唯一の欠点
~~~~~~~~~~~~~
作者がニコ厨
唯一の欠点
~~~~~~~~~~~~~
328:名無しさん＠編集中
08/06/17 20:04:36 v8m+pqu1
そこまでして煽りたいかね
329:名無しさん＠編集中
08/06/17 20:13:36 7ZdOqkRC
あぼんしやすいから問題ない。つーかわさるな。
330:名無しさん＠編集中
08/06/17 20:31:22 5nKLnpye
もともとニコ厨がニコ厨のために作ってるコーデックだからねぇ…
331:名無しさん＠編集中
08/06/19 02:33:04 J5yf0ss1
UtVideoに個人的に欲しいのはやっぱり圧縮のプロファイルだな。
・圧縮率優先（負荷とかマジ考えずに圧縮率追求したのが欲しいっす）
・エンコ速度優先
・デコード速度優先
・バランス
こんな感じであれば嬉しい。
332:名無しさん＠編集中
08/06/19 02:58:33 tkq7Cdd8
UtVideo
唯
一
の
欠
点
作
者
が
ニ
コ
厨
|唯
|一
|の
|欠
|点
333:名無しさん＠編集中
08/06/19 03:57:11 rPnN7Swr
>>331
それに少し画質を犠牲にした非可逆モードなんかも。
IBP単位GOPなんか導入したら楽しいかも。
334:名無しさん＠編集中
08/06/19 05:04:03 Vs4/Vv2G
>画質を犠牲にした非可逆モード
w
335:名無しさん＠編集中
08/06/19 10:39:44 bjjICbyb
>>334
ま、確かにDivXでも使っとけって思うわな。
336:名無しさん＠編集中
08/06/19 10:49:05 geEEki0N
非可逆ならHuffyuvでいいんじゃね？
337:名無しさん＠編集中
08/06/19 14:03:51 KuZnYj/9
DivXは暗部が汚いので嫌
h264くらいの画質があれば
338:名無しさん＠編集中
08/06/19 14:18:00 4md+7rbV
333はY8以下の色空間での可逆を望んでいるんだよ！
339:名無しさん＠編集中
08/06/19 21:47:03 aMsmxncD
予想通りのスーパー乞食タイムだな
340:名無しさん＠編集中
08/06/19 22:51:40 2XGSGNWS
作者に伝えたい、
ここで書かれているような要望なんて無視していいから、とりあえず
本人が満足するぐらいまで、UtVideoを完成してほしい。
341:名無しさん＠編集中
08/06/19 22:55:04 MWR7JkLC
作者も馬鹿じゃないんだから>>340みたいなのも
余計なお世話だと思わんでもない
342:名無しさん＠編集中
08/06/19 23:46:37 2XGSGNWS
確かにごもっとも。俺死ぬわ
343:名無しさん＠編集中
08/06/20 01:35:52 JBMmjaBg
ユーザーに出来ることは不具合報告とかデータ収集ぐらいしか
344:名無しさん＠編集中
08/06/20 09:46:54 Qa+bQSj0
ここまで公にしたんだからUtVideoはもう作者一人のものではなくなった。
皆の要望を切実に聞くべきだろう。
345:名無しさん＠編集中
08/06/20 09:50:09 6nJnxrXh
と、乞食が申しております。
346:名無しさん＠編集中
08/06/20 10:00:53 vMc9ofko
と、作者が申しております。
347:名無しさん＠編集中
08/06/20 11:21:15 1tZ/EP2f
URLﾘﾝｸ(wiki.nicomas.net)
アニオタ、エンコオタは無視ですが、アイマス厨の要望には真摯に取り組んでいるようです
まさに余計なお世話ってな感じですね
348:名無しさん＠編集中
08/06/20 13:04:55 UQk4Zxrm
作者の趣味がなんだろうと使用者にとっては関係無い。自分の目的に沿っていれば感謝しながら使うだけ。
しかし、こーゆーマンセーは見てて気に食わない。
>シングルスレッドの場合でも、Huffyuv (Predict median) よりデコードが速い。もちろんマルチスレッドなら圧倒的に速い。
>マルチスレッドの場合は Huffyuv (Predict median) はもちろん、同じスレッド数での Huffyuv_mt (Predict median) よりエンコードも速い。
正直、デコードについては、タスクマネージャーを見てる程度では動画によって振幅が大きいのでわからんが、
エンコード速度は自分の使用環境では確実にHuffyuv2.2.0のほうが速いよ。
349:名無しさん＠編集中
08/06/20 17:44:00 6eBd2R85
（速度に関しては Core 2 の場合）って注釈入ってるんだし
ドロップしない範囲ならＵｔ使うほうが圧縮率いいわけで
使い分けたらいいんじゃないかな。
で、YLCの使用感も話題も全くでないのはなんで？
350:名無しさん＠編集中
08/06/20 18:00:01 JBMmjaBg
相手が日本語が通じる分ありがたいと思った方が良い
351:名無しさん＠編集中
08/06/20 18:16:43 1tZ/EP2f
>>348
RGBがまともに扱えない2.2.0は、彼らにとっては評価の対象外です
352:名無しさん＠編集中
08/06/20 18:39:26 DNPGTvxU
>>348
環境さらさないと屁の突っ張りにもならん
353:名無しさん＠編集中
08/06/20 18:52:13 RABfjvpL
映像ソースにも差が出るんじゃ
354:名無しさん＠編集中
08/06/20 18:59:59 UQk4Zxrm
>>351
なるほど。そういう事か。
>>352
上のほうでちょっと投稿してるんだがな。時間作ってもうちょいまともなテストするよ。
ちなみにテスト環境、方法晒すなら、ある程度詳しく書く必要があると思うが、>>347もきちんと晒してないよね。
355:名無しさん＠編集中
08/06/20 19:12:16 DNPGTvxU
>>354
今やっているからちょっと待ってろw
356:名無しさん＠編集中
08/06/20 19:37:24 UQk4Zxrm
>>355
期待age
一応、後でこっちでもやるぜ
357:名無しさん＠編集中
08/06/20 20:02:48 TwsXDVh8
RGBでやってくれるのは真面目にありがたいわ。
俺がやってんのはアマレココつかったネトゲのキャプチャーだがね。
Huffyuvでやると警告系の赤い字とか隣に色が移って編集中すごく気持ち悪いんだ。
どうせ最終的には縮小かけたり非可逆の圧縮することが多いから気持ちの問題といえば気持ちの問題だけどなｗ
358:352
08/06/20 20:06:51 DNPGTvxU
とりあえず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の方が速いね
359:352
08/06/20 20:47:31 DNPGTvxU
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の方が断然速い
360:名無しさん＠編集中
08/06/21 00:43:48 Z9W0hHUl
Phenom(笑)
361:名無しさん＠編集中
08/06/21 00:56:43 EhGTpcnE
>>359
そっかRGBの場合はhuffuv_mtの方が速いのか
huffuvだと何故か時々壊れたﾌｧｲﾙが作られちゃうんだよな
OS再ｲﾝｽｺからやり直すかな
362:名無しさん＠編集中
08/06/21 01:17:19 K9x9hWnN
huffuv_mtは安定してないね。こっちでも。
まともに再生されないファイルができたりする。
363:名無しさん＠編集中
08/06/21 01:22:45 RYXA0jcM
レンダリング～～～90%くらいで何の前触れもなくアプリごと落ちる
Premiere Elementsと本当に相性悪いな・・・huffuvは
364:名無しさん＠編集中
08/06/21 01:33:13 K9x9hWnN
yが抜けてるけど誰も修正しないｗ
Normalだと不具合はないかな。こっちでは。
365:名無しさん＠編集中
08/06/21 01:54:18 ezCdNOgt
他を調べてもRGBはHuffyuvが得意で、YUY2はUtVideoが得意なようだな
366:名無しさん＠編集中
08/06/21 02:40:19 w2rTJXkI
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
367:名無しさん＠編集中
08/06/21 02:40:47 w2rTJXkI
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から読み込ませたら以下の結果に。
368:名無しさん＠編集中
08/06/21 02:41:08 w2rTJXkI
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
369:名無しさん＠編集中
08/06/21 02:41:21 w2rTJXkI
両Huffyuvの1回目については何故かCPU負荷が上がりエンコード速度も速くなった。
その後再現できないので、なんとも言えない。他のコーデックにも起こりうると思う。
さらにAviSynthから読ませると全体的にCPU負荷が下がりマルチスレッドで働いて無いのでは？
と感じたので、最後にマルチスレッドをOFFにしたら速度はあがった。
Q6600でもテストしようと思ってたけどHuffyuv2.2.0が速い、という意見の食い違いの原因がわかったからもういいや。
デコードに関しては、>>267-268でいいんじゃね？って事で。
この検証はあくまでも自分の環境ではこうなる、というサンプルにしかすぎない事に注意。
370:名無しさん＠編集中
08/06/21 02:50:23 w2rTJXkI
結局、自分の使い方では、中間ファイル→avs→x264.exeなので、
長いこと使ってて実績があるHuffyuv2.2.0を選んでる感じだなぁ。
YV12版Huffyuvを使ってる人の使用感聞きたいわ。
371:名無しさん＠編集中
08/06/21 02:57:02 K9x9hWnN
シングルスレッドでHuffyuv2.2.0が一番早かったって結論？
372:名無しさん＠編集中
08/06/21 04:59:38 ezCdNOgt
CPUの負担が50％前後で頭打ちになっているということは、
シングルスレッド性能は何となくテストできているけど
マルチスレッド性能は全く引き出せていないわけだからな・・・
HDDとかアプリの入出力あたりでオーバーヘッドが出ているだけだろうけど
373:名無しさん＠編集中
08/06/21 09:46:03 w2rTJXkI
>>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%前後
374:名無しさん＠編集中
08/06/21 09:46:23 w2rTJXkI
番外編 出力先を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を使っている事がわかる。
375:名無しさん＠編集中
08/06/21 09:46:40 w2rTJXkI
ソースを格納している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を効率的に使ってくれない、という事だと思う。
376:名無しさん＠編集中
08/06/21 10:02:16 w2rTJXkI
>>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のせいかと。
結局、自分の環境ではディスクがボトルネックになっているという事は無さそう。
377:名無しさん＠編集中
08/06/21 10:06:49 CSZtvxtf
速度と圧縮率上げてください
378:名無しさん＠編集中
08/06/21 12:16:12 ezCdNOgt
HDDのリード・ライト性能が十分ならアプリ側の入出力処理が
追いついていないだけだと思う
リード・ライトを同時に行うなら読み込みだけでもDirectShowを使わないと
処理が頭打ちして厳しいらしいよ
379:名無しさん＠編集中
08/06/21 13:54:08 lAaFqhvX
WDの10000rpm、320GBで3万以上かたけー
1TBの7200rpmHDDが2個買えるな
ストライピングは片方のHDDが逝くとデータが消失するので嫌だしな
やっぱり圧縮率のアップがいいかな
HDDの速度よりCPUの速度の方がムーアの法則的に上がるだろうし
380:名無しさん＠編集中
08/06/21 14:03:06 w2rTJXkI
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の変換が自動でかかってるんだよな？
単なる動作テストだから色空間がおかしくなろうがどうでもいいが。
ぼく、もう疲れたよパトラッシュ・・・
381:名無しさん＠編集中
08/06/21 18:00:58 K9x9hWnN
>>380
乙。YLCはやっぱ使う必要はなさそうだね。
後はあれかなフレーム分割数増やした場合のcpu負荷がどうなるかかな。
382:名無しさん＠編集中
08/06/21 18:24:51 V01+PvlW
YLCの利点は容量なんだけどねｗ
383:名無しさん＠編集中
08/06/21 18:51:30 PqhjLvFx
或るプログラマの一生より
可逆VCMコーデック用ベンチマーク
～略～
動画コーデックをベンチマークする専用のソフトは見つかりません。
というわけでしょうがないので作ってみました。
なんかｋｔｋｒ
384:名無しさん＠編集中
08/06/21 18:53:45 L78Qz5Zh
おお、
385:名無しさん＠編集中
08/06/21 19:40:31 K9x9hWnN
試してみたけどutもｙｌｃコーデックも認識しない
helixとffdshowだけしか選択肢にでないね。
環境xpｓｐ3
386:名無しさん＠編集中
08/06/21 19:45:33 mEFkklzx
これは無圧縮を別の圧縮にってベンチでしょ
utやylcで取り込んだものは一度無圧縮に変換して
exeにドラッグしてやれば「ほげほげ」って画面が出てくるからコーデック選択してOK
387:名無しさん＠編集中
08/06/21 19:50:39 mEFkklzx
ログのとり方がわからんｗ
388:名無しさん＠編集中
08/06/21 19:55:00 K9x9hWnN
ドロップしたら実行されるけどログがとれない
でバッチ作って試したけど
f:\vctest f:\12.avi -c >a.txt
例外 unknown software exception (0xc000000d) がアプリケーションの 0x00407571 で発生しました。
プログラムを終了するには [OK] をクリックしてください
プログラムをデバッグするには [キャンセル] をクリックしてください
こういうエラーがでる。
389:名無しさん＠編集中
08/06/21 19:55:40 rIakc/9M
>>383
どっかにないかと探してたんだ。ありがとうっ！行ってくるよ。
390:名無しさん＠編集中
08/06/21 20:09:44 mEFkklzx
バッチでコピペしたらログかｗ
391:名無しさん＠編集中
08/06/21 20:27:09 mEFkklzx
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
392:名無しさん＠編集中
08/06/21 20:32:28 K9x9hWnN
乙。その結果見るとYLCが一番いいように見えるんだけど
他の設定はどうなってるんだろ
393:名無しさん＠編集中
08/06/21 20:40:23 mEFkklzx
無圧縮 148MB 5秒の動画
UtVideo 52.3MB
YLC 55.2MB
Huffyuv v2.1.1 65.0MB
YLCは30分ぐらいだと容量低いのに5秒だとUtVideoのほうが低い
YLCは圧縮率は長時間にならないと効果でないね
逆に言えばUtVideoは長時間に弱いのか…バージョンアップで改善されるのかな
394:名無しさん＠編集中
08/06/21 20:41:17 mEFkklzx
>>392
UtVideoYUVが一番だよ
395:名無しさん＠編集中
08/06/21 20:48:54 K9x9hWnN
お疲れ様。UtVideoが一番いいってことでｏｋか。
長時間の圧縮ならＹＬＣがいいってことはやっぱアニメとかのキャプ用ってわけと。
396:名無しさん＠編集中
08/06/21 23:12:15 YfMAuzlJ
あ
397:名無しさん＠編集中
08/06/21 23:42:15 FZQmmcpj
>>392
どこをどう見たらYLCが一番なんだよｗ
元ファイルと比べた容量とエンコード時間だぞｗ
398:名無しさん＠編集中
08/06/21 23:47:37 K9x9hWnN
見直したらさすがに理解したよｗ
399:名無しさん＠編集中
08/06/22 08:19:46 9VNlii0W
UtVideoはHuffyuvの半分くらいのサイズにして欲しい
400:名無しさん＠編集中
08/06/22 08:33:04 AMVOoaOc
UtVideoはエンコが一瞬で終わるようにしてほしい
401:名無しさん＠編集中
08/06/22 09:37:17 dUqDF/Eb
いやな、中間ファイルに使ってる人もいればキャプ用に使う人もいるだろう。
中間ファイルならばエンコが早い方がいいんだろうけど
キャプ用ならばよりよく圧縮してくれた方がいい。
使用用途によって設定できればいいんだけどな。
402:名無しさん＠編集中
08/06/22 09:37:24 H/CY6HW+
わんぱくでもいい
403:名無しさん＠編集中
08/06/22 12:17:51 AN8LmEJZ
キャプ用でhuffyuvで無問題な環境を整えちゃうと、
エンコ速度や圧縮率が多少変わっても影響ないんだよね。
デコード速度は、その後のエンコ速度が変わるから速くなって欲しい。
404:名無しさん＠編集中
08/06/22 12:55:19 gldk4Qk1
>>403
そりゃこんなHDDを買える超金持ちなら影響無いでしょうよ。
URLﾘﾝｸ(www.westerndigital.com)
貧乏人が使ってるWD5000AAKSシングルで無理なくキャプれる圧縮率になるのは夢なのか？
405:名無しさん＠編集中
08/06/22 12:59:25 Qpn0wHN9
WD5000AAKSシングルで1080iならIntenでキャプれるよ
406:名無しさん＠編集中
08/06/22 13:27:52 hkXw1K29
安定してキャプれるかどうかだな
キャプる前デフラグ必須だと問題外。
安定してキャプる為には
UtVideo 1920x1080 *D3 15MB/s
は実現して欲しい＞欝ビデオの作者氏へ
407:名無しさん＠編集中
08/06/22 13:40:44 1VGc9VKf
>>404みたいに逆ギレしちゃう奴って可哀想な人？
「ｵﾚ様は○○が必要なくらい凄い事をしてるが、おまえはそんな物を必要としないチンケな事してるから関係無いんだろ」
とでも言いたいのだろうか。
用途なんて人それぞれだし、いくら必死に喚いたところで開発者が聞いてくれなきゃ、それまでの話なのに。
そんなに大変なら非可逆でキャプればいいんでねーの？
どうせ最後は非可逆になるんだろうし、大した差は無いんじゃね
408:名無しさん＠編集中
08/06/22 13:47:34 L1jfCUgh
この時代に圧縮率気にする奴はキャプしない方がいいと思うんだけどな
409:名無しさん＠編集中
08/06/22 13:59:45 Igsk/aBX
なんでこのスレのやつらこんなに偉そうなの？
410:名無しさん＠編集中
08/06/22 14:13:36 LBu47+Bv
>>407
非可逆スレが欲しいので立てて。
411:名無しさん＠編集中
08/06/22 14:50:43 1VGc9VKf
>>410
おまえはスレ検索すらできないアホか？気に入らないなら自分で立てろ。
ｽﾚﾘﾝｸ(avi板)
ｽﾚﾘﾝｸ(avi板)
ｽﾚﾘﾝｸ(avi板)
ｽﾚﾘﾝｸ(avi板)
412:名無しさん＠編集中
08/06/22 14:55:09 FztaTLzC
>>411
俺はね、再エンコの為のcodecスレを要求した訳じゃない。
キャプチャ用の非可逆圧縮スレが欲しいの。
スレ立てすぎで立てれないんだよ。
413:名無しさん＠編集中
08/06/22 15:34:52 89MT9U+c
>>402
たくましく育って欲しい
414:名無しさん＠編集中
08/06/22 15:35:37 HlMpTMkT
>>413
ハイレハイレフレハイレホー
415:名無しさん＠編集中
08/06/22 16:17:23 gMPeTJGk
>>412
うわああああああ
416:名無しさん＠編集中
08/06/22 17:41:45 OkwjzTQm
そのWDのHDDは読み書きが速いのではなくて
ランダムアクセスが強い（速い）んだぜ
高回転型はそういった狙いで作っているのだし
キャプチャはHDDの最内周（最悪値）を考慮してシステムを
組むのが俺のやり方
今どきのHDDだと２台でストライピングしておいた方が安心
それと非可逆はスレチだろ・・・
417:名無しさん＠編集中
08/06/22 18:28:39 1VGc9VKf
>>412
まともなテンプレ作ったら建ててやるよ。糞スレになるのが目に見えるようなテンプレは勘弁な。
ちなみに俺は興味ないから。
418:名無しさん＠編集中
08/06/22 19:03:24 esNMeNX+
>>417
すいません。今フリーで出てるキャプ用非可逆コーデックって、
「PICVideo MJPEG Codec」
URLﾘﾝｸ(www.pegasusimaging.com)
「Canopus HQ Codec」
URLﾘﾝｸ(www.canopus.co.jp)
「Black magic 8bit MJPEG」
「DeckLink MJPEG」
URLﾘﾝｸ(www.blackmagic-design.jp)
「アースソフト フレーム内圧縮コーデック」
URLﾘﾝｸ(earthsoft.jp)
「MotionJpeg2000Codec」
URLﾘﾝｸ(www.morgan-multimedia.com)
くらいしか知りません。他知ってるのがあれば追加よろしくお願いします。
スレの趣旨は、
■綺麗でサイズの小さいキャプチャー用非可逆コーデックについて情報交換しましょう。
●「我こそは世界で最も綺麗でサイズの小さい非可逆コーデックを作ってやる」と活き込んでる開発者（神様）を募集中。
×調べもしないで「いい非可逆コーデックはありませんか？」とか「コーデックの設定について教えてください」とかいう厨房はお断り。
【現在存在してる各非可逆コーデックのリンク先】
ってな感じでいいです。
419:名無しさん＠編集中
08/06/22 19:14:30 1VGc9VKf
>>418
テンプレ作れって言われたらさ、代理で建てる奴が何も考えずにコピペできるように作れよ。
ｽﾚﾘﾝｸ(avi板)
420:名無しさん＠編集中
08/06/22 19:16:59 esNMeNX+
>>419
おおっ！あなたはもしや★か●持ち。
無理な申し立てをしてすいません。
ありがとございます。
421:名無しさん＠編集中
08/06/22 19:53:30 H9JW3jw9
非可逆じゃないのも含まれてるじゃんｗ
422:名無しさん＠編集中
08/06/24 00:38:03 mdozhUPc
[UtVideo] バージョン 4.0.2
ULRG: デコード時に RGB32 で出力する場合、安全のためアルファチャンネルと解釈されうるフィールドは 255 で埋めるようにした。
共通: エンコード時に出力の biBitCount には入力の実効ビット数を設定するようにした。
423:名無しさん＠編集中
08/06/24 10:46:37 3NaJD/6w
保管庫にLagarithが３種類あるけどどれがいいの？（Core2Duo
前スレは完全に追えなかった…
424:名無しさん＠編集中
08/06/24 18:23:00 m543kj38
Lagarithは現状使い道はないと思うけど
425:名無しさん＠編集中
08/06/24 20:02:05 5Q7e9+OC
圧縮率稼ぎたい奴が使うんじゃね？
426:名無しさん＠編集中
08/06/24 21:23:39 4j6l/a9/
ｱﾘｸｲってよ､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
427:名無しさん＠編集中
08/06/24 21:40:48 N6HqJZHI
>>423
URLﾘﾝｸ(www.23ch.info)
これの802と817見てみな
で今Lagarithのサイト見てきたんだが、更新されてね？
428:名無しさん＠編集中
08/06/24 22:03:24 wsVRTRej
>>426
このコピペ初めて見たけどむちゃくちゃ面白いなｗ
一瞬で一番好きなコピペになってしまったｗ
429:名無しさん＠編集中
08/06/24 22:41:50 3NaJD/6w
>>427
ありがとです。719版を使うのが正しい感じですね。というか716版って何なんだろう…まあいいか。
430:名無しさん＠編集中
08/06/24 22:44:45 H9tUjCcO
TMPGでのバグが直ったのか？もうTMPG使わないからあれだけど
431:名無しさん＠編集中
08/06/27 01:52:04 QjC20s8N
非可逆スレの人気に嫉妬
人々はサイズが小さくてHDDに優しいコーデックを求めてるのだよな
432:名無しさん＠編集中
08/06/27 08:10:22 +5I5NttI
ソフトウェアキャプで可逆圧縮だと、みんなCPUはQuad使ってる？
現状くらいなら、Duoでもそんなに差は出ないかな？
433:名無しさん＠編集中
08/06/27 17:12:59 wMn+bXap
>人々はサイズが小さくてHDDに優しいコーデックを求めてるのだよな
だろうな
CPUよりHDDの性能が落ちるPC使ってるヲタが多そう
>Duoでもそんなに差は出ないかな？
差って、具体的に「何の」差を聞きたいわけ？
434:名無しさん＠編集中
08/06/27 17:23:13 VGRcwrUl
LagarithがHDD的にはやさしい
435:名無しさん＠編集中
08/06/28 03:12:01 cHmyEij2
>>433
たぶんＨＤＤは割れの方に金をかけてキャプには金をかけたくないのだろう
436:名無しさん＠編集中
08/06/28 06:23:48 5T++A/st
「PICVideo MJPEG Codec」
(・∀・)ｲｲ!!
◎...
○...
△...
･ﾟ･(ﾉД`)･ﾟ･ﾀﾞﾒ!
▼...
▽...
×...
な感じで。
437:名無しさん＠編集中
08/07/01 02:32:12 esuuPEpT
MSU Screen Capture Lossless Codec縮み過ぎわろた。
鬱とかLagarithとかの1/4も縮んでやがる。
ただしちょっと遅いし動きの多いやつじゃ怪しいらしい。
使いどころが難しいな。
438:名無しさん＠編集中
08/07/01 10:17:27 Hv2/O3Zn
>>437
俺のスペックでは遅延が起こる。。。
最適な設定なんかあればな。。。E6600
439:名無しさん＠編集中
08/07/01 10:37:38 AOnWkre9
そんなに縮むロスレスが有るの？驚き。
>>438
遅延って何の遅延ですか。
440:名無しさん＠編集中
08/07/01 10:42:32 WKAQFobJ
試してみたけど縮みすぎｗ
フレームレート落としても問題ないようなプレイ動画なら使えそうな感じだね。
441:名無しさん＠編集中
08/07/01 12:32:10 WKAQFobJ
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だとドロップが多発する。
用途は限定されるだろうね。
442:名無しさん＠編集中
08/07/02 01:04:27 N6E1QcSW
比較結果のまとめあった
URLﾘﾝｸ(replaymugen.seesaa.net)
縮みすぎだろこれ
443:名無しさん＠編集中
08/07/02 02:05:51 kQZBhVQv
見た感じだと色空間が統一されていなくて
結果が極端になっているだけのような気がする
444:名無しさん＠編集中
08/07/02 02:34:33 9nUGQB4f
>>442
縮みすぎだろｗ
まあエンコード、デコード共に負荷が大きそうだな。
保存専用にしか使い道が思いつかん。
445:名無しさん＠編集中
08/07/02 03:33:11 NldDCYL2
バラつきがあるにせよどの道圧縮率が現時点では異常。
ただ負荷が大きくてキャプチャーも再生もお勧めできない。
使ってみると分かるけど色々もてあましてる感じ。
とりあえず編集待ちのソースを片っ端からコイツにしてHDDの空きを確保＾ｐ＾
ま、俺のCPUは6400+だがねｗ
446:名無しさん＠編集中
08/07/02 04:28:03 xGpKw0mv
あれは負荷でかくついてんのか？
可逆でない気がする
447:名無しさん＠編集中
08/07/02 04:36:03 wtMkziqz
vctestでの結果もあるしロスレスでしょ。
448:名無しさん＠編集中
08/07/02 05:18:10 xGpKw0mv
vctestはいつの間にロスレスしか認識しない仕様になったんだ？
449:名無しさん＠編集中
08/07/02 05:44:44 wtMkziqz
Lossless Checking is enabled
ってでてるしチェックしてるんじゃ？
そもそも本家でLossless Codecと言ってるのに
可逆じゃないと根拠なしに言ってるほうがおかしいでしょ。
450:名無しさん＠編集中
08/07/02 08:56:01 xGdMgKXW
>>442
長期の保存用に良いなこれ。
451:名無しさん＠編集中
08/07/02 16:31:08 xGpKw0mv
>>449
作った奴のことをそのまま信じるのか？
根拠って映像見てあれを可逆だと思うのか？
452:名無しさん＠編集中
08/07/02 17:09:20 NldDCYL2
ID:xGpKw0mv
そういうお前も言ってることに根拠がないぞ。
とりあえず「負荷でカクついてるのか」と言う疑問に対しては負荷でカクついていると俺は考える。
なぜならMSU-SCLC（縮めても名前長いな）で圧縮した動画をを別な可逆に再び圧縮する（もしくは未圧縮に戻す）と
特に速度面では異常なく再生することが出来ていたから。
お前は画質については振れてないようだけど、
元動画とMSU-SCLCで圧縮した動画の任意の同じ１コマをを
差分検出ツールを用いて違いがあるか調べてみたけど違いは見られなかった。
Detect Fadeの有無にかかわらず同じ結果だったと付け加えておく。
俺はこのコーデックが可逆であるかについてとくに疑いを持ってないから
やり方は簡単にしたけどコレぐらいなら可逆だと考えるに値すると思うんだけどどうかね。
453:名無しさん＠編集中
08/07/02 17:14:25 9nUGQB4f
MSU-SCLCでｴﾝｺしたらUtVideoより膨らんだ…。
454:名無しさん＠編集中
08/07/02 17:16:13 wtMkziqz
ソースによるのかな？できたらvctestあたりでの結果が知りたいけど。
455:名無しさん＠編集中
08/07/02 17:44:10 NldDCYL2
そういや俺のも若干膨らんでるな。
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の項にはキーフレームの指定が無いのが気がかり。
456:名無しさん＠編集中
08/07/02 17:49:55 gtuQvytA
テストの為、アニメのオープニングを640x480に縮めてMSU-SCLCを使ったら
huffyuvの2倍以上になった
MSUのキーフレームは1フレーム毎にしないと画が出てこなかったからその設定
全然お話にならん感じ
457:名無しさん＠編集中
08/07/02 17:52:54 wtMkziqz
こっちも某シューティングゲーム撮ってUTと比較したけど
UT 4.2G MSU-SCLC 3.6Gで劇的な差はでなかった。
動きの激しいものはダメっぽいねぇ
458:名無しさん＠編集中
08/07/02 20:23:19 kQZBhVQv
RuSHと同じで、フレーム参照圧縮もしているんじゃないかなぁ
それだと重いだろうし、動きやピクセル誤差があるとフレーム参照が効かなくて縮まないしね
459:名無しさん＠編集中
08/07/02 22:26:19 Mi7su3i4
Screen Captureっていうくらいだから、デスクトップキャプチャみたいな
静止部分の多い動画にフォーカスしてるんじゃないの？
460:名無しさん＠編集中
08/07/03 09:31:03 Re6doKWc
結論：huffyuvで今はいい
461:名無しさん＠編集中
08/07/03 10:08:40 Hh8yyqIs
MSU-SCLCをマルチスレッドとSSE最適化なりすれば実用域に入るかもしれない。
今でも動きが少ないものなら使えそうだし。
462:名無しさん＠編集中
08/07/03 15:25:59 Hh8yyqIs
vctestがあがってた。キーフレーム率の設定できるようになったらしい。
Lossless checking enabled
>（最後に -c を付けた場合）は「Lossless checking enabled」になってチェックします。
>たとえば RGB で入出力するけど内部保持形式が YUV422 の場合は、
>見た目が同じでも完全にロスレスにはなっていないので、チェックしないで実行する必要があります。
だそうだ。
463:名無しさん＠編集中
08/07/03 20:28:53 0AniDPJ2
>>461
videoではなく(デスクトップ的な意味で)screenって言うくらいだから動きの少ないものを想定してるんだろ
464:名無しさん＠編集中
08/07/03 20:52:45 3fVINDLX
>>463
>>459を読んでみろ
465:名無しさん＠編集中
08/07/10 02:13:45 i7JVqcLy
最近の楽しみはUtVideoの発展だったのだが作者は力尽きたのかしら。
アイマスが楽しそうですね、っと。
466:名無しさん＠編集中
08/07/10 02:21:27 j3H2bA9H
例の隠しコマンドかｗ
467:名無しさん＠編集中
08/07/12 11:18:17 fMW1GrNj
この時代に隠しコマンドってだけで興奮するわけだが
468:名無しさん＠編集中
08/07/14 00:41:40 xVmEzpQZ
iM@S MultiColor Keying for AviSynth
469:名無しさん＠編集中
08/07/14 01:19:04 zi2IoQSk
可逆圧縮と関係ないだろｗ
何張ってんだよｗｗｗ
470:名無しさん＠編集中
08/07/14 01:29:34 K2Q/EbzS
>>468
俺もそれみてｸｿﾜﾛﾀｗｗ
471:名無しさん＠編集中
08/07/14 02:43:36 sETQSuZ7
自演乙だります！
472:名無しさん＠編集中
08/07/14 03:01:46 tXNNrnRV
aviutl版も作ってくれ
473:名無しさん＠編集中
08/07/15 23:58:08 wcU890OU
～前略～
それよりも注目すべきは YLC。圧縮比 4.55 倍は、エンコード時間がそれほど長くないことを加味すると圧巻です。YLC はエンコード中の CPU 使用率を見る限りシングルスレッド動作しているようなのですが、マルチスレッド対応したら最強じゃんこれ。
こうなってくると YLC がどういうアルゴリズムでエンコードしているのか非常に気になります。教えてＫＥＮくん！ってここで叫んでどーする。
コメント1
そんな大したアルゴリズムでもないので
後で簡単に文章にして送りますよ！ by KENくん
474:名無しさん＠編集中
08/07/16 00:50:41 itP5A/gC
YLCはデュアル専用じゃなかったけｗ
475:名無しさん＠編集中
08/07/18 23:05:21 nhV1FtuI
utの人のところで今後の方向性？聞いてるっぽいんで言うのはタダなんで書いてみる
MSU のような動き予測追加かなあYLCマルチスレッドにしてもUt Videoとそんなに差があるとは思えないし・・・
476:名無しさん＠編集中
08/07/19 00:34:28 spSI43C2
YV12対応してほしいです。
masktools使う関数（例えばDidee氏の作った関数はほぼ全て）は
YUY2からYV12に変換しなけりゃならないので、
masktools使う激重の関数をいくつか連荘で並べたスクリプトの場合に
メモリの都合から連荘の途中で一旦可逆で出力したい、って時に
Lagarithよりエンコード・デコードが速い可逆があると非常に助かります。
477:名無しさん＠編集中
08/07/19 02:55:22 molBihcg
>Huffyuv と同じ圧縮率で、エンコードが 1～2 割ほど速く、デコードが 3 割
>ほど速い（現在の ULY2 よりちょっと速い）ものを作れることは分かってい
>ます。どうしましょ。
ぜひやってくれ。速いに越したことはない。
>圧縮率を上げる方向は、ハフマン符号の代わりに Range Coder を使うことに
>すれば、まあまあ圧縮率を稼ぐことができます。それ以上を狙うと、MSU の
>ように動き予測などをしなければいけないのでしょうが、それだったら MSU
>を使った方が幸せなように思えます。と思ったけど MSU はマルチスレッド動
>作していない雰囲気ですね。
ぜひやってくれ。圧縮率が高いことに越したことはない。
結論、両方組み込んで速度重視と圧縮重視の2つのプロファイルを実装。
478:名無しさん＠編集中
08/07/19 23:23:40 CD9P95G2
色ずれ補正とか付いてたらいいな
479:名無しさん＠編集中
08/07/20 00:16:34 tnuys7Te
それぐらい、フィルタでやれよ
480:名無しさん＠編集中
08/07/20 01:46:05 VJ+xPxke
動き予測までしなくても
フレーム間の画素差分取る様にすれば
それなりに圧縮率は上がるんじゃね？
その方が簡単だし
481:名無しさん＠編集中
08/07/20 10:55:01 fNSr1gC6
詳しいことは分からんけど、フレーム間圧縮やるとAVIのフリをさせるのが
大変なんじゃないの？
少し圧縮率が上がったくらいでは元が取れないのジャマイカ。
482:名無しさん＠編集中
08/07/20 14:33:58 Dwz3g8ke
>>481
前方向のみで処理をすれば多分大丈夫
483:名無しさん＠編集中
08/07/22 11:50:41 SLk4tero
シークとか逆再生とか全く考慮しなければ効率いいものができそうだね。
484:名無しさん＠編集中
08/07/22 21:21:38 EjPAwgpn
キーフレームはフル圧縮が必要だろ
キーフレームの頻度が上がるとサイズが大きくなる、下がるとシークが遅くなる
485:名無しさん＠編集中
08/07/22 22:47:34 rb7shy/F
フレーム間圧縮をやる場合、シーク速度が肝になるな。
差分フレームは最大何フレーム分取るか？(GOP長？)
キーフレームの自動挿入はやるか？
キーフレームのバッファをどのくらい取るか？
そんなんで変わってくるんだろうな・・・
486:名無しさん＠編集中
08/07/23 21:03:08 1SpLFfOJ
huffyuvsってのは何なの？
487:名無しさん＠編集中
08/07/23 22:11:29 1zsSw0N1
>>486
なんか凄いのｷﾀｰ
488:名無しさん＠編集中
08/07/26 12:31:22 c2hlx7O7
Lagarith Lossless Video Codec v1.3.17来てたのね・・
489:名無しさん＠編集中
08/07/26 20:01:46 pvix+UTH
>>488
いつのまに！
490:名無しさん＠編集中
08/07/27 00:46:55 dBZmcj1R
utってさ、64bitで使えるの？使えたら試した印だけども…
491:名無しさん＠編集中
08/07/27 01:09:34 0XMRymGX
使えたよ。
492:名無しさん＠編集中
08/07/28 09:24:06 Dp10YZez
>>490
試せるなら使ってみれば？
493:名無しさん＠編集中
08/07/29 17:03:15 ic3Xz836
うｎ、後でやってみる
494:名無しさん＠編集中
08/07/30 20:12:29 QTX00PQ4
【社会】 「息子が柔道ごっこでいじめられた」と思い込んだ山口組系暴力団組長、中学生３人を投げ飛ばして逮捕…宮崎★２
ｽﾚﾘﾝｸ(newsplus板)l50
★１１０番・１１９番：傷害容疑で暴力団組長逮捕 ／宮崎
・２８日、宮崎市鶴島、山口組系暴力団組長、根本倫夫容疑者（６０）を傷害・暴行容疑で。
２４日、市内の公園で、中学１年の男子生徒３人に対して、「小学生の長男をいじめた」と
因縁をつけて投げ飛ばし、うち２人に全治５～７日の打撲を負わせた疑い。
直前に、被害者の中学生グループが長男らの小学生グループと「柔道ごっこ」をしていた。
この際、長男が倒れ込み、泣いて帰宅。長男から事情を聴いた根本容疑者が公園に
戻って３人に暴行した。
URLﾘﾝｸ(mainichi.jp)
・警察によりますと、根本容疑者は、今月２４日の昼頃、宮崎市内の公園で中学１年生３人に
対し、小学生の長男をいじめたなどと因縁をつけて地面に投げ飛ばすなどの暴行を加え、
中学生２人にそれぞれ７日間と５日間の打撲などのけがを負わせたということです。
被害にあった中学生３人は、根本容疑者の長男を含む小学生数人と、公園で柔道をして
遊んでいましたが、過って中学生のうちの１人が根本容疑者の長男の上に倒れ込んで
しまい、泣いて帰った長男の話を聞いた根本容疑者が、長男が中学生にいじめられたと
思いこみ、暴行をしたということです。
調べに対し、根本容疑者は容疑を否認しているということですが、警察では目撃者の
証言などから根本容疑者を傷害と暴行の疑いで逮捕して調べています。（一部略）
URLﾘﾝｸ(www.nhk.or.jp)
※前：ｽﾚﾘﾝｸ(newsplus板)
495:名無しさん＠編集中
08/08/05 23:19:27 NKQqOpMd
UtVideoの今後の方針が出たようですね
496:名無しさん＠編集中
08/08/05 23:32:07 DqNHIfTR
つーか、C++で高速コーデックとか笑っちまうな
しかも、ループの中でnewしてるし
497:名無しさん＠編集中
08/08/05 23:34:09 OiRCQ/wZ
＞これにより Huffyuv より圧縮率は多少悪くなってしまいます。速度最優先なので仕方のないところではありますが。
圧縮率を稼ぎたい人が多いようだが、俺的にはｷﾀｰだな。
498:名無しさん＠編集中
08/08/06 00:21:36 uCQfOk5q
ほとんどの人にとって可逆圧縮の主な用途は中間ファイルだろうから
圧縮率はそれなりにあれば、あとは速度最優先なのは良いことだ
499:名無しさん＠編集中
08/08/06 02:59:56 2gu9An9Z
ニコ厨が作ったコーデックなんざゴミ
500:名無しさん＠編集中
08/08/06 03:13:25 QPuM/FNa
そう思うなら使わなければいい
501:名無しさん＠編集中
08/08/06 03:13:56 kKFpQ7rI
>>498
＞ほとんどの人にとって可逆圧縮の主な用途は中間ファイルだろうから
だから、それは思い込みだっつーのｗ
502:名無しさん＠編集中
08/08/06 08:48:50 OFKndX0d
アニソンをflacとかmonkeyでリッピングしまくって聴いてるアフォみたいなやつのことか
503:名無しさん＠編集中
08/08/06 08:53:53 SkO/I2ES
UtVideo、PE4と相性悪い・・・のは俺だけ？
504:名無しさん＠編集中
08/08/06 08:56:30 yDchCsI2
CD焼くならimgファイルなわけで・・・・・・
EACだと音がずれないとかいうけどそんなことはないわけで・・・・・
そもそも音楽情報が消えてCUEになるわけで・・・・
焼くのが目的なのにapeとかはもうあっち系の人が使ってるだけなわけで・・・・
パソコンで聞く分にはAPE利用できるけどそれは中間じゃないわけで・・・・・・
505:名無しさん＠編集中
08/08/06 15:04:10 BmsJ46tu
すごく、病的です…
506:名無しさん＠編集中
08/08/06 16:03:21 ZFgDB3LW
1時間45ギガもあるともうちょっと圧縮してくれた方がいいようなきがする
507:名無しさん＠編集中
08/08/06 17:51:59 vqPFEbR/
音声は今の時代無圧縮のまま保存してるやつだって多いけど
さすがに映像を無圧縮や可逆で長期保存してるやつは病気だな。
HDD1PBあってあまって仕方がないとか言うならしょうがない。
508:名無しさん＠編集中
08/08/06 18:07:10 kKFpQ7rI
＞さすがに映像を無圧縮や可逆で長期保存してるやつは病気だな。
んな奴いるわけねーべ
509:名無しさん＠編集中
08/08/06 20:55:06 ziWO3Dm2
>>503
どう悪いのかとりあえず書いてみたら？
PE4側の問題なら難しいだろうけど、UtVideo側なら作者さんが対応
してくれるかもよ？
510:名無しさん＠編集中
08/08/07 02:50:29 xLGnJ48O
>>507
可逆圧縮のままHDDに溜め込むのがデフォな奴の方が病気だろ
大事な物ならまだしも・・
全てを可逆でって奴は1Pでも10PでもHDD買い足すような奴だよ
511:名無しさん＠編集中
08/08/07 02:53:17 xLGnJ48O
('A`)ｲﾛｲﾛﾏﾁｶﾞｴﾀ・・・ｺﾞﾒﾝﾈ
512:名無しさん＠編集中
08/08/07 08:40:52 RUH8vcrJ
怒りは非可逆圧縮で最小に
513:名無しさん＠編集中
08/08/07 13:28:20 z4jqxzKB
素材は非可逆のまま置いておくことはある
514:名無しさん＠編集中
08/08/07 13:39:25 OhqP0A5Q
>>513
それ普通じゃね？
515:名無しさん＠編集中
08/08/07 14:35:19 FDYmwF7G
>>513
普通だな
516:名無しさん＠編集中
08/08/08 06:56:06 b1qpKYBG
test
517:名無しさん＠編集中
08/08/08 11:26:58 OZF/FqiB
>>516
testだな
518:名無しさん＠編集中
08/08/12 16:52:00 /IjZ8Ja6
test1.avi
test2.avi
test3.avi
519:名無しさん＠編集中
08/08/12 18:11:27 yJMah+7v
omanko
520:名無しさん＠編集中
08/08/12 20:30:27 8ASRTX3o
Huffyuvマルチスレッドコーデックで特定の番組のキャプチャが
TMPGEncでのエンコード中に高確率でエラー吐いてバッチが
落ちる症状が出てましたが、
ぐぐって最新版入手して切り替えたら、どうやら落ちなくなってくれたようです。
キャプチャ時の容量も二割くらい少なくなってますな。
これなら早くバージョン上げりゃ良かった。ありがたやありがたや。
521:名無しさん＠編集中
08/08/12 23:29:08 XAcPxPTz
なんだかんだでLagarith Lossless Video Codecが一番だとわかった
522:名無しさん＠編集中
08/08/12 23:56:18 lv2unIuD
くすのきHDTVでキャプってるけど、鬱ビデオ使ってると
たまに音声だけで映像がキャプれてないってことがあるから、HuffyuvMTに落ち着いた
523:名無しさん＠編集中
08/08/13 00:47:13 nt4uBklP
くすのきTVHDだと思ってた
524:352
08/08/13 23:47:22 z3G0r7+J
>>522
ほぼ毎日キャプでUtVideo使っているがいまだにそんなトラブルはないな
どこかがおかしんじゃね？
525:名無しさん＠編集中
08/08/14 00:31:24 8gepXc3/
utvideoもylcもTMPGEncの編集作業中フリーズして強制終了しないといけなくなることが多々ある
だから私はLagarithかHuffyuv
526:名無しさん＠編集中
08/08/14 03:55:13 3zCFJX1s
UtVideoもバージョン4.02で今のところ止まってるよな
加速度的なバージョンアップのときはこのスレも賑わっていたのに
やっぱりいろいろ面倒なんでしょうかね
527:名無しさん＠編集中
08/08/14 19:13:35 M1CVwYiL
新しいアルゴリズムがどうとか言ってたような・・・
まぁ利用者は気長に待つべきかな
528:名無しさん＠編集中
08/08/15 06:18:53 5g6rYTds
tmpgで編集するとひっかかったり
utvideo→他の形式にエンコした動画のシークでひっかかるとか
あるね。
huffyuvではいずれも問題なし。
529:名無しさん＠編集中
08/08/15 12:35:47 hrzuGJIb
それ根本的にどっかおかしいだろ。
530:名無しさん＠編集中
08/08/15 19:59:50 ejRXLHbu
うん、そうだね
根本的におかしいね
お前の頭がｗ
531:名無しさん＠編集中
08/08/15 23:10:55 3KY0eUZS
うん、そうだね
根本的におかしいね
>>530の頭がｗ
532:名無しさん＠編集中
08/08/16 01:52:31 2WujIrgr
どんだけ沸点低いんだ
533:名無しさん＠編集中
08/08/25 14:51:49 uz9kNrpV
21日にUtVideoの進展があったようだが、その後の日記はアイマス
まあユーザーとしては気長に待つかな
534:名無しさん＠編集中
08/08/25 17:33:34 NlLWtIb6
PremiereからAviUtlへの中間CodecにYLC使ってるんだけど、
AviUtlで他の形式(MP4とか)に書き出すときに例外が起きない？
継続させればファイルはできあがるんだけどなんか気分悪い・・・
535:名無しさん＠編集中
08/08/26 02:32:08 Y7gwx7LR
Version 1.3.18
536:名無しさん＠編集中
08/08/26 04:01:56 eu7VJD5F
>>535
ぉ、あがったのか
537:名無しさん＠編集中
08/08/26 04:03:44 R/FNd6Sg
>>535
何が？
538:名無しさん＠編集中
08/08/26 04:04:27 eu7VJD5F
>>537
Lagarith Lossless Video Codec
539:名無しさん＠編集中
08/08/26 04:43:25 Jz7sxSFO
はじめて入れてみたがいきなりマルチスレッド対応なのな
エンコードよりデコードのほうが負荷高い
540:名無しさん＠編集中
08/08/27 16:29:07 YqRzNRBn
だからなんだよ
家はマルチスレッドの設定自分でチェックしたぞ
初期設定はオフだったｗ
541:名無しさん＠編集中
08/08/28 10:18:24 yqqhCStT
普通、ソフトの初期設定は一番弱い環境を想定して作りこんでおくもんだし、
それでいいんじゃね？
542:名無しさん＠編集中
08/08/28 10:20:19 v7f1D3Re
Lagarithのマルチスレッドってバグ持ちだからチェックしない方が
良いとかいうのは直ったの？
543:名無しさん＠編集中
08/08/28 12:56:02 1e5DX82/
>>541
>はじめて入れてみたがいきなりマルチスレッド対応なのな
>>539の環境では違うんじゃねぇの
544:名無しさん＠編集中
08/08/28 18:55:48 E/CmksCF
マルチお断りｗって言われた
545:名無しさん＠編集中
08/08/29 01:49:26 /jrQ0VXQ
>>542
結構前に直ってるんで問題ないよ
546:名無しさん＠編集中
08/08/29 02:30:56 rnILTWk+
Huffyuv v2.1.1 CCE SP-Patchってなに？
普通の2.1.1よりも凄いの？
547:名無しさん＠編集中
08/08/29 03:22:14 rnILTWk+
>>442のサイトに書いてあった
すみませんでした
Cinema Craft Encoder用のHuffyuv改造版
輝度スケールが変換されないように施されている
548:名無しさん＠編集中
08/08/29 03:24:14 rnILTWk+
ってかこのサイトH.264 losslessもテストしてほしいな
549:名無しさん＠編集中
08/08/29 13:38:45 ocpUei2h
>>522
激亀レスで申し訳ないが、うちはHuffyuvでも起こる。
くすのきHDTV起動させっぱなしで録画開始→録画停止を繰り返すと起きる気がするんで
録画毎にくすのき再起動で対応してる
今のところこれで音のみにはなっていないが…
どこかおかしいんだろか
550:名無しさん＠編集中
08/08/29 16:17:13 OU/Kk8fK
くすのきTVHDだと思ってた
551:名無しさん＠編集中
08/08/29 17:51:54 /G42iNW4
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だと思ってた
この流れにデジャヴを感じるんだが・・・何故だろう・・・
552:名無しさん＠編集中
08/08/29 18:19:23 NlLuFZE8
もうすぐリセットされるからね
553:名無しさん＠編集中
08/08/31 00:56:26 eAdCba7O
UtVideoの作者様
avs2aviで使えるようにしていただけませんでしょうか。
554:553
08/08/31 01:01:31 eAdCba7O
失礼いたしました色空間の問題でした。
YV12にも対応していただくことをお願いできますでしょうか。
ソースから最終までYV12で一括可能になるとさらに速度的にも
便利かと思いまして。
555:553
08/08/31 01:32:42 eAdCba7O
よくみたらHPにかいてありました・・・。
すみません。
556:名無しさん＠編集中
08/08/31 16:58:02 jD+PpIpC
とりあえず落ち着け…
557:名無しさん＠編集中
08/09/01 01:17:01 LwfHS4Fx
ソースがYV12ってダウソ厨かリップ厨だからスルーな
558:名無しさん＠編集中
08/09/01 01:40:15 zoPI7IZE
【審議中】
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・｀) ∧∧
( ´・ω) Ｕ) ( つと ﾉ(ω・｀ )
｜ Ｕ ( ´・) (・｀ ) と ﾉ
ｕ-ｕ （l ) ( ﾉu-ｕ
`ｕ-ｕ'. `ｕ-u'
559:名無しさん＠編集中
08/09/01 02:03:10 k7EBDMNj
>>557
560:名無しさん＠編集中
08/09/01 08:33:54 RbOE7zzu
逆に今時YUY2のソースってのがなんなのか知りたい・・・。
561:名無しさん＠編集中
08/09/01 09:33:54 4y4mZpt2
MPEG-2ソースならふつーに4:2:2だろうが
562:名無しさん＠編集中
08/09/01 13:24:41 oFhfo2wZ
…
563:名無しさん＠編集中
08/09/01 18:34:20 zoPI7IZE
Aviutlに騙されてる奴大杉
564:名無しさん＠編集中
08/09/01 19:28:02 SeRiOaaf
意味不明
565:名無しさん＠編集中
08/09/01 20:26:10 /JCVEbW1
まあ馬鹿はほっといて、俺もYV12対応をwktkしながら待っている
圧縮率はHuffyuv程度まで落ちてもいいから、エンコード、デコードの速いのが欲しい
Lagarithはやっぱデコード遅いよ