09/07/10 23:31:57 fN2fpFAc
代表的なコーデック
Huffyuv 2.1.1 （安定版）
URLﾘﾝｸ(neuron2.net)
Lagarith Lossless Video Codec
URLﾘﾝｸ(lags.leetcode.net)
Huffyuv_mt （マルチスレッド化）、Lagarith_1315dev_SSE2_719 （SSE2対応化ほか）
URLﾘﾝｸ(www29.atwiki.jp)
YUY2 Lossless Codec (YLC)
URLﾘﾝｸ(ruriruri.zone.ne.jp)
ＬＣＬ （旧ＬＲＣ）
URLﾘﾝｸ(www.geocities.jp)
MSU Lossless Video Codec
URLﾘﾝｸ(www.compression.ru)
CorePNG
URLﾘﾝｸ(www.free-codecs.com)
FastCodec
URLﾘﾝｸ(videosoft.org)
Ut Video Codec Suite
URLﾘﾝｸ(umezawa.dyndns.info)
AMV2MT/AMV3
URLﾘﾝｸ(amamaman.hp.infoseek.co.jp)
3:名無しさん＠編集中
09/07/10 23:39:42 bNoGr+fc
これはポニーテールがどうのこうの乙
4:名無しさん＠編集中
09/07/10 23:55:01 kSUG9WSN
r'ﾆﾆニ二二二ﾆﾆﾆ､ヽ
| | .＠ | | ﾄ､＿＿＿＿, へ
rー┤| |├､ ヽ }
| | | Π | | | ≡三ーーーーｧ /
l l l lﾆ コ .| | | ≡ ／ ／
| l l |_| | | | ≡三 .／ ／
l＿＿l_l＿＿＿＿＿＿|_|__| っ .≡ ／ ／
| / ,ｲ,へ 丶､ ﾍ ≡三.／ ／ ﾉ|
| ,' / /／ ＼| ＼ ﾄ､ ヽ ', つ ≡{ 丶ーーーー' }
!j./l / ` ヽﾄ､ヽ } ゝ､＿＿＿＿＿＿_丿
. | | .!/.! ○ ○ l l |ヽ,' ⊃
l | | .l/////////////! | !.|
.| ! | ﾄ､ ,-ｰ￢ .ｨ| .| l こ、これは>>1乙じゃなくてバギクロスなんだから
| l ! l l` r --.' <j ,' | | 変な勘違いしないでよね！
| .l ', l |ｬ-ミ≡彳ｧﾄｲ ,'! !
.| | ヽ| | l r´ ）/ハy / | ',
5:名無しさん＠編集中
09/07/11 02:38:34 pFoS72j8
姉妹スレ
音声可逆変換ソフト総合スレ
ｽﾚﾘﾝｸ(software板)
6:名無しさん＠編集中
09/07/11 12:00:54 ZxM3rHxN
いちおつ
7:名無しさん＠編集中
09/07/12 17:54:59 liD92ixO
いちおつ
8:名無しさん＠編集中
09/07/13 21:59:32 vKALAP3e
1乙
ところで、みんなは、どのコーデックを利用しているの？
9:名無しさん＠編集中
09/07/13 22:42:29 b8+h8Hrb
UtVideo だけど、AMV3を買ってみようかと思ってる。
AMV3早そうだし。
10:名無しさん＠編集中
09/07/13 23:15:53 lqncRqXI
俺1ペタあるから使わないよ
11:名無しさん＠編集中
09/07/14 00:11:38 EQiGyFdV
>9
どっちが高速化教えてくれい。
UtVideoはインタレ使えないのがネックだな・・・。
12:名無しさん＠編集中
09/07/14 00:42:37 KljUSiE6
>>11
アマレココのページに計測データが載せられている。
自分で測るとしたら……どうすりゃいいんだ？
13:名無しさん＠編集中
09/07/14 01:50:18 6zuJPRSn
Utおいてるとこにある速度計測器でも使ってみたら？
14:名無しさん＠編集中
09/07/15 20:34:18 koqEFiNP
URLﾘﾝｸ(xrowcc.blog.shinobi.jp)
俺は試すのめんどい
15:名無しさん＠編集中
09/07/15 23:38:56 BPTRTu3m
[UtVideo] バージョン 5.3.0
機能追加
ULY0: エンコード時に YUY2 で入力できるようにした。とりあえず作っただけなので、YUY2 入力時のエンコードは遅い。
ULY0: デコード時に YUY2 で出力できるようにした。とりあえず作っただけなので、YUY2 出力時のデコードは遅い。
16:名無しさん＠編集中
09/07/16 00:27:56 CRacHsO+
作者が報告してくれてるの？
それとも誰かが瞬時に発見してるの？
17:名無しさん＠編集中
09/07/16 01:54:11 3r6OoiT2
RSSでチェックしてるとか。>>14は変更点も書いてないから試す気も起こらないな・・・
18:名無しさん＠編集中
09/07/16 22:36:54 jE1TH4Nj
[UtVideo] バージョン 5.3.1
バグ修正
ULY0: フレーム分割の方法が間違っていた。
19:名無しさん＠編集中
09/07/17 06:08:32 W/lH9T6n
絶対宣伝誌に来ると思ってたが案の定宣伝に来たなｗ
死ねクズ
20:名無しさん＠編集中
09/07/17 09:28:17 Mc0/KUnU
>19
バカいってんじゃねーよ。
せっかく報告してくれてんだよ。おまえがどけ
21:名無しさん＠編集中
09/07/17 15:33:32 gpWFfHtG
>>18
報告たすかる
重大なバグがあったのかな？
22:名無しさん＠編集中
09/07/17 16:00:53 EQKFczPl
自分でもアンテナ登録してるからなくても困らないけど報告はありがたいね。
23:名無しさん＠編集中
09/07/18 04:56:27 KSAgM6f+
酷い自演
24:名無しさん＠編集中
09/07/20 13:54:28 tIV1kpEO
自分でちょっと試したらエンコデコともにAMV3よりUtの方が早かったな。
Athlon X2, ULY0とAMV3可逆標準で。
25:名無しさん＠編集中
09/07/20 19:52:16 3TQze3re
アマレコ使う場合はAMV3使わないとコマ落ち増える
AMV3はアマレコキャプ専用
26:名無しさん＠編集中
09/08/08 20:39:45 Xk0rsFc/
やたらと最近（キャプチャ開始してから十分前後で）コマ落ちする。
UtvideoからHuffyuvMTに一回戻してみたけど、状況変わらず。
HDDの空き容量が影響しているのかと、CMカット編集済みの動画を消しても同じ。
くすのきの再生フレームレートが30フレーム近くからじりじり(22フレームくらいまで)
下がっていくので、HDD周りのデバイスドライバを調べなおしたら、
なんか認識されているデバイスドライバが足りてなかった。
いったん削除して、完全に電源を落として再起動して認識させ直したら、
nForceのRAIDドライバがプライマリとセカンダリも認識されなおしたので、再度キャプチャ中。
再生フレームレートは27フレーム前後で特に変化無し。
たぶん問題解決しました。
27:26
09/08/08 20:43:02 Xk0rsFc/
あと、5.3.1まであげて、圧縮率優先→デコード速度優先もやりました。おかげで動画サイズが
2割くらい膨れ上がって、HuffyuvMTと変わらなくなってしまった。
28:名無しさん＠編集中
09/08/08 20:56:35 cv/UFt48
日記はチラ裏にどうぞ
29:名無しさん＠編集中
09/08/09 11:01:58 LDw9MPm8
つうかコーデックと全然関係無い話じゃん
30:名無しさん＠編集中
09/08/09 17:09:33 Zptsww4i
[FFmpeg-devel] [PATCH][RFC] Lagarith Decoder.
URLﾘﾝｸ(lists.mplayerhq.hu)
31:名無しさん＠編集中
09/08/10 15:49:47 xfd/aHgY
外国の厨が出したパッチ自体より、それにつけられたコメントの方が読むと面白い。
32:名無しさん＠編集中
09/08/10 20:38:36 /ajxPb3p
正規のVFW Codecがあるのにわざわざffmpegに組み込む必要性ってなに？
33:名無しさん＠編集中
09/08/10 20:47:18 oeD7oq/t
ffmpegやMPlayer/MEncoderでそのまま扱えるようになるだろ
あそこらへんは現状ではffvhufかffv1しか可逆の選択肢がない
menc2vfw使わないですむなら、それにこしたこともない
34:名無しさん＠編集中
09/08/10 23:25:33 /ajxPb3p
>33
menc2vfwってなに？
ググっても出てこない。コマンドラインからVFW codecでエンコ出来るのかな？
35:名無しさん＠編集中
09/08/11 00:11:32 swlvLeeq
>>34
ああ、ごめん、vfw2mencだった
できることはその通り
本来win用のvfwコーデックをLinux上で使うためのもの
そもそもVirtualDubやAviSynthがネイティブで動くwindowsではたいして意味はない
36:名無しさん＠編集中
09/08/19 00:54:34 4ycnQf3l
インターレースの映像を、インターレースを保持したまま可逆圧縮できるコーデックは、
Huffyuvくらいなものなんでしょうか。
Ut Videoは、YUV420でのインターレースは非対応らしいですが、
YV12でのインターレースは、どうなんでしょう？
Lagarithはググってみたら、海外の掲示板では、どうも対応してないようなことが書いてありましたが、
最新版の1.3.20でも非対応で合ってますか？
37:名無しさん＠編集中
09/08/19 01:58:44 Jj3NpY1w
基本的に同じフォーマットで圧縮・展開すればいいよ
RGB←→YUY2 変換ロス発生
RGB,YUY2←→YV12 変換ロス、インタレ変換の影響
huffyuvのインターレース対応はmethod gradient,medianで１つ上のラインを参照するから
横幅を２倍とみなして偶数・奇数ライン同士を参照するようにして圧縮率を上げている
38:３７
09/08/19 02:21:40 Jj3NpY1w
補足
コーデックの圧縮前の内部フォーマットと異なるフォーマットで入出力すると変換ロスが発生するので
内部フォーマットと同じフォーマットで入出力すればいいよってこと
39:名無しさん＠編集中
09/08/19 03:22:49 le/T8EuZ
AMV2MT/AMV3がYV12に対応していたと思う。
40:名無しさん＠編集中
09/08/19 06:59:06 XPfwaRax
>>36
YV12に対応している物なら、FFV1, Lagarith, UT Video等、何でも良い。
41:名無しさん＠編集中
09/08/19 07:05:56 XPfwaRax
ただ、AviUtl等を使って、YUY2->YV12をやると、縞が崩れてしまうから、
VirtualDubのFast recompressやavs2aviを使う必要は有る。
42:名無しさん＠編集中
09/08/19 20:18:26 aHU8eYju
インターレースYV12をリサンプリングせずにそのまま可逆圧縮するだけなら
インターレースの対応可否は関係ないよ。
43:名無しさん＠編集中
09/08/20 04:06:41 mwrVmBoK
フィルタかけるとつぶれるけどな。
44:名無しさん＠編集中
09/08/20 11:38:05 xdEasAih
フィルタかけるのはリサンプリングに相当するぞ>>43
45:名無しさん＠編集中
09/08/31 19:53:59 R2HQP1/H
UtVideo6ってバグ？
46:名無しさん＠編集中
09/09/01 03:55:31 yq1sIvN4
Visual C++のランタイム絡みらしい。6.0.0のコメント欄に報告がある。
47:名無しさん＠編集中
09/09/07 23:53:25 mNGHLuXA
[UtVideo] バージョン 6.0.0
共通: インターレース映像に対する特別な処理を追加した。
※インストール関連のバグあり
[UtVideo] バージョン 6.0.2
ダイナミックリンクからスタティックリンクに変更した。
※インストール関連のバグ解消（と思う
48:名無しさん＠編集中
09/09/11 11:26:04 TA3md0y2
エンコード作業をオールx64化したいのですが
現状でx64ネイティブなマルチスレッドな可逆圧縮コーデックって何がありますか
49:名無しさん＠編集中
09/09/11 11:34:47 zUQPI7it
>>48
Lagarith
50:名無しさん＠編集中
09/09/11 14:56:39 utqU+W3s
動画エンコ的にはx64のメリットはほとんどないよね・・・
51:名無しさん＠編集中
09/09/11 15:36:49 MLOD8Eeh
そうでもない
たとえば複数のエンコを同時進行する場合は、メモリ4GB超の恩恵はある
この前同時に3本のavsを中間出力（フィルタの都合上、MTなし）したが、メモリ使用量5GBで楽勝でした
そのほかにも32ビットに比べてインターフェース周りとかは強化されてるから、32ビットのアプリでも、
そのもののスピード自体は多少遅くなるが、結果的には変わらないか若干速くなったりすることもある。
言ってみれば車速自体は遅くなったけど、道が走りやすくなったんで、タイムは縮んだみたいなかんじ
52:名無しさん＠編集中
09/09/11 15:57:58 NDkHkDKt
x264なら64bit版で32bitより1割以上早くなるよ
53:名無しさん＠編集中
09/09/11 16:02:24 MM1QHSKc
32bitでもRAMDISKにスワップ置けばトータルメモリ量は増やせるけど、
1アプリ2GB（拡張して3GB）の制限有るから、
フルHDサイズとかでフレーム参照系のオプション増やしてるなら64bitの方が良いな
54:48
09/09/11 16:33:31 TA3md0y2
>>48
早速ありがとうございます
Lagarith Codec (v1.3.20)
Lagarith_1315dev_SSE2.7z
Lagarith_1315dev_SSE2_719.7z
を試しました
しかし、こいつ重たいですね ＾＾；
Phenom9600ではドロップでまくりでD3キャプチャーできませんでした
改めてhuffyuv_mtの軽さを思い知りました
もう少しあがいてみます
55:名無しさん＠編集中
09/09/11 17:34:13 utqU+W3s
x64は対応してるのは本家のだけだと思うけど。x64でキャプできるものもあるのかな。
他の64bitもの
URLﾘﾝｸ(members.optusnet.com.au)
56:名無しさん＠編集中
09/09/11 22:13:05 x4gklbuc
avisynthのフィルター類って32bitだとおもったけど
avsを64bitのx264でそのままエンコってできるの？
57:名無しさん＠編集中
09/09/11 22:16:11 4PboHS/L
>>56
URLﾘﾝｸ(forum.doom9.org)
58:名無しさん＠編集中
09/09/11 22:40:37 x4gklbuc
Thanks!
59:48
09/09/12 00:02:09 XDggAEB5
>>55-56
書き方が足りませんでした
キャプはx86で行います
で、先ほどのLagarithはx86でのキャプチャー時の負荷です
>>57のツールではなくx64 avisynth の使用を前提で考えていたので
x64側のネイティブなデコーダーも必要と考えました
とりあえず、huffyuv-2.1.11のシングルスレッドでギリギリでキャプチャーできるようですので
それでしばらくは対応したいと思います。
ご回答くださいました方々ありがとうございました
60:名無しさん＠編集中
09/09/12 01:47:49 lzAc4G8X
CUDA使って圧縮するコーデックって出れくれないかな。
61:名無しさん＠編集中
09/09/17 01:34:55 YVdBLtKa
完全に中間圧縮専用だな。
ところでUtも64bit対応目指すらしいな。
いつだかこのスレで騒いでたやつを思い出しちゃったよ。
彼の人にAMD64bit機を送りつけたらAMDの最適化もやってくれたりするんかな。
62:名無しさん＠編集中
09/09/17 15:13:01 z4nn4nb7
win7発売と同時か。後はキャプチャーソフトと編集ソフトが対応増えるのを期待かな。
63:名無しさん＠編集中
09/09/22 02:02:47 N22kbizu
Huffyuv_mt_712を導入する際はhuffyuvは一度アンストしたほうがいいんですか？
64:名無しさん＠編集中
09/09/22 03:05:53 RYQswv0a
別物だからそのままでいい
65:名無しさん＠編集中
09/09/22 19:02:21 tbDl/Bm0
>>63のHuffyuv_mtならFourCCがHYMTに変更されてるから共存できる。
ちなみにLagarith1315のMT改造版はFourCCがオリジナルと同じなので共存できない。
66:名無しさん＠編集中
09/09/23 01:13:07 +NUZWci6
huffyuvのアンストの仕方わからない俺涙目。ぐぐる先生にもそれっぽいのないし
67:名無しさん＠編集中
09/09/23 01:26:57 NJYeobWO
>>66
これで上書きできれば、アンインストールできるかも。
URLﾘﾝｸ(breuzehn.hp.infoseek.co.jp)
>huffyuv2.1.1codec
>何故かアンインストール出来ない不具合を不必要だと思いつつも修正したもの
68:名無しさん＠編集中
09/09/23 12:29:32 C3X3eKtK
そんな不具合があったのか・・・。
「アプリケーションの追加と削除」から削除できそうだけど、失敗するのか・・・？
69:名無しさん＠編集中
09/09/28 02:24:58 YkLnYQn6
IgCodec v1.0.0
URLﾘﾝｸ(xrowcc.blog.shinobi.jp)
使うメリットはないけど一応報告
70:名無しさん＠編集中
09/09/28 04:45:45 pQWbgXJF
>>69
LZ系か。ならQuickLZ使うべきだったろうにjk
そこの作者は情報に疎いな何時も
71:名無しさん＠編集中
09/09/28 12:11:04 rGlIueIL
>>70
QuickLZはGPLだからじゃない？
72:名無しさん＠編集中
09/09/29 12:12:35 ZgHXZEtw
>>69
試しに使ってみたけど、
・・・うん、なんだ、UtVideoのままでいいや。
73:名無しさん＠編集中
09/09/29 18:54:25 ekIvIRmS
-------------------------
IgCodecの大雑把なテスト
-------------------------
■ソースファイル：
秒速５センチメートルの公式ページ（URLﾘﾝｸ(5cm.yahoo.co.jp)）で
配信されている予告編第１弾のダウンロード版（teaser8000k1280_720.wmv）の
483-722フレーム（合計240フレーム、10秒、場面切替多め）を選択して使用。
ソースファイルの情報
1280x720 24Bit Windows Media Video V8 24.00fps 7872.00kb/s
Windows Media Audio 9.1 44.10kHz 16Bit 2ch 128.02kb/s
[WindowsMedia] 00:00:45.000 (45.000sec) / 25,557,744Bytes
Sinku.DLL 090902
■PC環境
OS： Windows XP SP2 Home
CPU： Celeron M423 1.06GHz
メモリ： 1.5GB
スペック低すぎるとか笑うんじゃない！これでも大事なメインマシンなんだ！｡･ﾟ･(ﾉ∀`)･ﾟ･｡
■エンコード設定：
Aviutl 0.99h3
フィルタ無し
ソースはDirectShow File Readerで読み込み
標準のAVI出力を利用。音声無し。
74:名無しさん＠編集中
09/09/29 18:56:05 ekIvIRmS
■結果
※IgCodecは内部形式がYUV4:2:2（UYVY)とのことなので、
YUY2形式の可逆圧縮コーデックを比較対象としました。
どのコーデックもYUY2圧縮を有効にしてあります。
※UtVideo Codecは少し古いバージョンです。
コーデック：
エンコード時間 ファイルサイズ
IGC1、IGC2：
３２秒 187,782[KB]
IGC3、IGC4：
２分４６秒 126,553[KB]
UtVideo 5.2.3 ULY2(デコード速度優先)：
２１秒 111,176[KB]
UtVideo 5.2.3 ULY2(圧縮率優先)：
２１秒 85,682[KB]
Huffyuv v2.1.1 PredicMedian(best)：
１８秒 119,481[KB]
う～ん・・・、どれをとってもUtVideoやHuffyuvでいい感じですね・・・。
75:名無しさん＠編集中
09/09/29 18:56:48 ekIvIRmS
■その他
※多分バグだと思うけど、うちの環境だとファイルを選択すると
Explorerが落ちる。どうもサムネイル作成で落ちてるっぽい。
ただ、１秒くらいの動画をエンコした場合は問題なかったので、
何かしらの発生条件があるのかも。
※上にも書いたが今のところ内部形式がYUV4:2:2(UYVY)なので、
RGBソースの場合はRGB→YUV変換による劣化が発生する。
76:名無しさん＠編集中
09/09/29 19:18:45 Ieor7Wy0
utもx64対応になったらvctestもx64対応になるかな。
77:名無しさん＠編集中
09/09/29 19:19:09 0h0Jhy//
データを複数台のＰＣに移動しながら作業したいんだが、
・圧縮率をなにより優先
・RGB色で出力可能(YUVはダメ)
・速度も……悲惨じゃないよ
って条件に合うCODECを調べてくれる変態な人いませんか？
変態じゃなくても構いません
78:名無しさん＠編集中
09/09/29 19:21:05 kzMvJ+7y
>>77
FFV1
"ffmpeg -vcodec ffv1"とするか、ffdshowのVfWから使う。
79:名無しさん＠編集中
09/09/29 19:29:13 Ieor7Wy0
こことか参考に
URLﾘﾝｸ(amalabo.blog35.fc2.com)
RGBだとどうだったかな・・・
80:名無しさん＠編集中
09/09/29 19:35:28 ekIvIRmS
～IgCodecのテスト続き～
IgCodecの説明を見ると差分圧縮と書いてあるんで、
可逆圧縮にしては珍しくフレーム間圧縮をしてるのかなと思い、
1024x768のJPG静止画を拡張編集で24fps 240フレームの長さにして
IgCodecでAVI出力してみました。
IGC1 ３６秒４０２ 337,599[KB]
IGC3 １分５３秒３７０ 284,277[KB]
ULY2デコード優先 ２３秒２５５ 230,510[KB]
ULY2圧縮率優先 ２２秒１７０ 202,502[KB]
うーん・・・？
81:名無しさん＠編集中
09/09/29 20:06:48 lKaknEdC
>>78
FFV1のコード見た。
predictionに緑≒Yなことを使った速度優先的な変換にvariable-length code(標準)もしくはrange coder(-coderが1以上の時)かぁ。
にしても速度最適化の余地が多いコードだな。
URLﾘﾝｸ(forum.doom9.org)
ここみるとRGB24の圧縮率はFFV1(range coder)・MSU・ALPHARYSOFT・LAGARITHの中で、FFV1(range coder)が一番のようだ。
UtVideoとの比較キボン
82:名無しさん＠編集中
09/09/29 20:15:20 Ieor7Wy0
vctest win7RTMx64 core2duoたしか7200 メモリ4G
FFV1 RGB
Size: 176755656/582746112 (30.3%, 3.30)
Encode time: 19192.075003ms/988f = 19.425177ms/f
Decode time: 2.626668ms/988f = 0.002659ms/f
UTデコード優先
Size: 253036980/582746112 (43.4%, 2.30)
Encode time: 1343.400828ms/988f = 1.359717ms/f
Decode time: 2013.050065ms/988f = 2.037500ms/f
UT圧縮優先
Size: 214398748/582746112 (36.8%, 2.72)
Encode time: 1308.437872ms/988f = 1.324330ms/f
Decode time: 3060.007643ms/988f = 3.097174ms/f
こんな感じ。ffdshowのffdshow_rev3092_20090927_sse_icl11のFFV1 RGBはaviutlでは使用できなかった。
83:名無しさん＠編集中
09/09/29 20:22:49 lKaknEdC
ふむ。UTはRGB特殊扱いが無いし、ハフマンだしでFFV1に圧縮率で勝る点は無い。
強いて言えばpredictionが二種あることだが、これがどう影響しているかは分からね。
84:名無しさん＠編集中
09/09/29 20:34:43 Ieor7Wy0
Lagarith_1315dev.7z 要SSE3
Size: 199223055/582746112 (34.2%, 2.93)
Encode time: 6276.757368ms/988f = 6.352993ms/f
Decode time: 8037.621376ms/988f = 8.135244ms/f
追加。バランスだとutだけど圧縮ならFFV1がいいのかな。
85:名無しさん＠編集中
09/09/29 20:57:34 kzMvJ+7y
URLﾘﾝｸ(compression.ru)
少し古いが、これはとても参考になる。
キャプチャー等で速度優先ならUT Video、保存に使うならFFV1が良いと私は思う。
86:名無しさん＠編集中
09/09/29 20:58:23 0h0Jhy//
ご意見ありがとうございます。
色々考えた結果、
UT出力→7z圧縮で移動→出先で解凍
が一番効率がよさそうでした。
7zの繰り返しデータ圧縮効率は異常
87:名無しさん＠編集中
09/09/29 21:00:43 lKaknEdC
>>83は嘘付いた。ULRGでg, r-g+0x80, b-g+0x80してるしplane化もしてる。
ffv1はg, r-g, b-gとplane化の他にgに(r-g + b-g)>>2を足したり(計算してないけど多分誤差を減らすため)、r/bに0x100を足したり(詳しく追ってないので謎)してる。
88:名無しさん＠編集中
09/09/29 21:27:48 lKaknEdC
謎っていうか16bit処理(-0xffから0xff)してるだけか。
確かに8bitで処理するより圧縮率は高くなるな。
89:名無しさん＠編集中
09/09/29 21:59:49 lKaknEdC
RGBの色空間変換の最近のトレンドはYCoCgらしい。
URLﾘﾝｸ(wiki.multimedia.cx)
Co = R - B
t = B + (Co >> 1)
Cg = G - t
Y = t + (Cg >> 1)
YCbCrと比べてどの程度の効果あるのか気になる。
90:名無しさん＠編集中
09/09/29 22:18:47 kzMvJ+7y
H.264のmatrix_coefficientsが8になっていたら、YCgCo
どの実装が、これのエンコード/デコードに対応しているのかは知らない。
91:名無しさん＠編集中
09/09/29 22:20:03 kzMvJ+7y
YCgCo-> YCoCg
x264のヘルプを見ながら書いていたら間違えた。
92:名無しさん＠編集中
09/09/29 22:24:20 kzMvJ+7y
再度訂正
T-REC-H.264-200711-I!!PDF-E.pdfにもYCgCoとあるから、間違いではなかった。
93:名無しさん＠編集中
09/09/29 22:26:26 sZT/EUiQ
>>80
調査乙です。
Igの人のブログ見ると改良していくつもりでもなさそうな感じだし、
Utから乗り換えする必要ないっぽいかなぁ。
>>89
YCoCg…YCbCrとYPbPrの違いもよく分かってないのに他にもあるのか…。
94:名無しさん＠編集中
09/09/29 22:44:48 1EoSCOp3
igCodecがVistaUltimate(x86)でインスコできないんだが解決策わかる人いる？
95:名無しさん＠編集中
09/09/29 22:46:51 1EoSCOp3
ごめん。XP専用だったのね。公式読んでなかった
ちょっと死んでくる
96:名無しさん＠編集中
09/09/29 23:07:48 Z/jyKhJv
YCoCgはRGBと無劣化に相互変換できるフォーマットでYUVと同じように
輝度信号と色差信号で記録される。H.264のHigh444 Profileの対応色空間として
利用できる。
97:名無しさん＠編集中
09/09/30 13:26:01 BHN0iqo3
後発ならどこか一部でも利点のあるもの出さなきゃ
98:名無しさん＠編集中
09/09/30 20:13:55 2BxbpfIO
商用利用可能
99:名無しさん＠編集中
09/09/30 23:32:14 fAtGr6DR
別に商用利用はGPLのHuffyuvやFFV1やUtでも可能だろ
ただ金払うやつがいないってだけで
100:名無しさん＠編集中
09/10/01 16:35:16 XI2cN2lf
FFV1はLGPLでも使えるな。
101:名無しさん＠編集中
09/10/03 03:48:13 BdY8uk7N
>>73-75 >>80 でIgCodec 1.0.0を使ってみたものなんですが、
気になる動作があったので、誰かわかる方いたら試してみていただけないでしょうか。
■現象
デコードできないFOURCCを持つ映像ファイルをDirectShowで再生すると、
「AVI Decompressor」が”igc1”を呼び出してデコードしようとする。
MPC-HCで内蔵フィルタをOFFにし、「FLV Splittter（Gabest）」＋「FLVSplitter付属のFLV4 Video Decoder」で
FLV4を再生しようとしたのですが、メニューの「Play→Filters」の情報を見ると、
「FLV Splitter」はFOURCC＝"FLV4"でデコーダーに渡しているのに、
何故か「AVI Decompressor（igc1）」が呼び出され、デコードを行なっていました。
（当然映像は出ません。というかMPC-HCが落ちました。）
「FLV4 Video Decoder」のメリット値は「AVI Decompressor」より低いようなので、
先に「AVI Decompressor」の判定が行なわれ、何故かigc1にマッチしたとみなされて呼び出されているようです。
また、適当なAVIファイルをバイナリエディタで開き、最初のほうにある２箇所のFOURCCを、
実際には存在しない「PGRW」に書き変えてみたのですが、
それも何故かAVI Decompressorが呼び出され、デコードしようとしてました。
>>75で書いた「サムネ表示で落ちる」という問題も、他では聞きませんし、作者さんの環境でも再現しないそうです。
IgCodecの問題ではなく、うちの環境がおかしいか、インストールに失敗しただけなのかもしれません。
考えてみればインストール直後は特に問題を感じてなかったし、途中で何か変になったのかなあ・・・。
当たり前ですがアンインストールすれば上記の現象は発生しなくなりましたが、
別の環境だとどうなのかなというのが気になりまして。
102:名無しさん＠編集中
09/10/03 03:50:22 BdY8uk7N
ちなみにアンインストールする前にPCの再起動を試したのですが、それでもダメでした。
103:名無しさん＠編集中
09/10/03 11:02:39 z8/v/gVI
>>101
ICDecompressQueryで拒否されれば別のフォーマットのデータで再生しようとはしないはず。
コーデックのチェックが甘いんじゃないの？
試しにUtVideoのソースいじってICDecompressQueryでICERR_OKを返すようにしたら
mplayerが落ちるのを確認できたよ。元に戻すと落ちない。
ただ、設定によっては再現しない時があったけど。
104:101-102
09/10/03 22:58:14 DN2WbC/Y
>>103
うおぅ、なんか実装レベルな詳細ｋｔｋｒ。
ググってもよくわからんかったのですが、「これをデコードできる？」って問い合わせに対して、
IGC1がなんでもかんでも「できるよー」って答えてるということでしょうか。
GraphEditで見てみましたが、とにかくビシバシAVI Decompressorが呼び出されてました。
とりあえず再インストールしても発生したので、環境依存の可能性も含めて報告だけしてみます。
あと別スレで出てましたが、上下反転したり、RGB圧縮してYUY2展開すると崩壊が起きるというバグがあるようです。
うちでも再現しました。
105:名無しさん＠編集中
09/10/03 23:44:41 iriEy1HH
>>104
AVIDecompressorはレンダラからのDirectShowの動的フォーマット変更の要求を受けるよ。
旧レンダラだとYUVのデコードが出来ない古いビデオカードのために、最初はRGBで表示して
途中からYUY2に変えたりする。
BI_BITFIELDなんかも渡されるし、負のHeightも意味がわからなければとりあえず拒否すればいいよ。
106:104
09/10/04 01:00:09 V8/7yfvT
>>105
すみません、書き方がおかしかったかも。
「Aviutlで、IGC1のYUY2圧縮をオフ（つまりRGB圧縮）にしてエンコしたAVIを、
IGC1のYUY2展開をオンにして読み込むと映像の崩壊が起きることがある」
です。
申し訳ないですが私自身は開発者でもなんでもないので詳しいことはよくわからないです・・・（;´Д⊂）
ちなみに負のHeightというのは、まるもさんの2004年6月3日の日記にある件でしょうか。
URLﾘﾝｸ(www.marumo.ne.jp)
以前、
ｽﾚﾘﾝｸ(software板:301-318番)
で、
「VP62でエンコードしたAVIが読み込み方法によっては上下反転する」
という質問をしたことがあるのですが、もしかしてこのVP62の件も
負のHeightというのに由来しているんでしょうか。
107:名無しさん＠編集中
09/10/04 08:05:16 5wypKd+0
>VP62でエンコードしたAVIが
これはyuvの負数Heightの問題よりvp6とvp6fの問題な可能性が高そうな。
108:名無しさん＠編集中
09/10/04 17:44:05 0dUriZIT
>>106
AVI Decompressorは、ICDecompressQuery(ICM_DecompressQueryメッセージ）で
コーデックが処理可能なフォーマットをきちんとチェックしていると想定しているよ。
mpcが落ちたのは多分入力フォーマットのチェックが不十分だったのが原因だと思うよ。
メディアプレーヤやVirtualDubのプレビューで上下反転して再生されるのはまるもさんの説明
の通りなんだけど、この部分はレンダラの違いや、OSやDirectXが新しくなった時に挙動が
変わったりもするので、負の高さを拒否するのもひとつの方法。
以前はColor Space ConverterでRGBに変換していたけど、HDとSDで色変換が異なるので
今のAVI DecompressorはデフォルトではRGBの展開しか受け付けないとか、そういうこともあるし。
VP6 vfwは使ったことが無かったんで、Aviutilのプラグインの順番で上下が反転する問題は
よくわからないけど、DirectShow用のffdshow video decoderとAVI出力時の圧縮設定で
出てくるff_vfwのdecodeタブの有効(libavcodec)／無効の設定が異なってない？
109:名無しさん＠編集中
09/10/04 22:03:41 0dUriZIT
>>106
AVI File Reader（Video For Windows）ではRGBで読み込まれて
AVI/AVI2 File ReaderではYUY2で読み込まれてない？
その場合はAviutilのコーデックの設定でYUY2の展開のチェックを外してみて。
110:名無しさん＠編集中
09/10/05 00:47:11 77Shi33E
>>107
今回の件はVP62だけで試したので、VP6Fとは関係なさそうですが、
FLV4を作るときに、わざわざ上下反転させた映像をVP62でエンコしてffmpegに渡すのは
負の高さというのをFlashPlayerがどう扱うかといったあたりが関連してるんですかねえ・・・。
それを更に反転させて一般プレイヤーでちゃんと再生させるためのFOURCCがVP6Fだと認識してます。
>>108
ありがとうございます。内容についてはもう少し勉強してみます。（;´Д⊂）
ffdshowのVP6は、VFWでもビデオデコーダーでも無効にしています。
>>109
そういえば展開形式を忘れてました orz
■AviutlでVP62のAVIを読み込んだ時のビデオ展開形式と反転状況
・AVI/AVI2 File Reader【VP62のYUY2展開ON】： YUY2 ※上下反転する
・AVI/AVI2 File Reader【VP62のYUY2展開OFF】： RGB
・AVI File Reader（Video for Windows）【VP62のYUY2展開影響なし】： RGB
・DirectShow File Reader【VP62のYUY2展開影響なし】： YUY2
■AvisynthでVP62のAVIをpixel_typeの形式を変えて読み込んだ時の反転状況
●pixel_type="YUY2"
AVISource()、AVIFileSource()、OpenDMLSource()： ※上下反転する
DirectShowSource()： 上下反転しない
●pixel_type="RGB24"
AVISource()、AVIFileSource()、OpenDMLSource()： 上下反転しない
DirectShowSource()： 上下反転しない
DirectShow以外でYUY2展開で読み込むと上下反転してしまう感じなのですね。
動画って色々難しいものですねえ・・・。
111:名無しさん＠編集中
09/10/05 01:02:46 73HmhB9t
FFVideoSource("VP62.avi") とすれば良い。
112:名無しさん＠編集中
09/10/05 03:54:53 J7D85f9c
>>110
ええと。vp6fというのはflashに使われるvp6コーデックの"ffmpegでの"呼び名ね(fourccではない)。flashに使われるvp6は普通のvp6と上下が反対という仕様になってる。
普通のvp6のfourccはVP60, VP61, VP62。
この辺の処理をちゃんとしてなかったり、間違ってたり、強引にやってたりすると上下反対のができる。
113:名無しさん＠編集中
09/10/05 04:15:34 J7D85f9c
って勘違いかも? ffmpegのriff.cにあるからfourccだねぇ>VP6F
on2のデコーダは対応してなかった記憶があるが、その辺の経緯忘れた。
114:名無しさん＠編集中
09/10/05 04:22:15 aD/0mvDP
VP6の話になったらもうスレ違いだよなあ
115:名無しさん＠編集中
09/10/05 23:24:18 sJ9QMwh6
最強可逆コーデック MSU Screen Capture Lossless Codec
URLﾘﾝｸ(replaymugen.seesaa.net)
わかりやすかった
116:名無しさん＠編集中
09/10/05 23:56:01 cYQUrplO
>>110
普通のユーザーは覚えなくても全く問題ないよ。
入力のFourCCについては、ff_vfwが有効になっているフォーマットを全て登録しなくても
再生可能な仕組みでもあるので、チェックが必要。
コーデックに負の高さが渡されるのは、通常はレンダラが用意したDirectXの
サーフェイスであることを示す目印で、RGBでもYUVでも「トップダウン」なので、
コーデックが入力フォーマットの幅と高さを使って処理しているとRGBが反転してしまい、
また、上下反転の意味と捉えるとYUVが反転してしまうというわけ。
VP6がどうだったのかは知らないけど、登場した頃の主な編集ソフトがYUV対応
していなかったりすると、YUVの向きに混乱があっても特に問題ならなかったんだと思う。。
ってことで、Aviutilのコーデック設定でVP6のYUY2圧縮を外してエンコードしたらどうなるの？
反転しなければフォーマットの問題ではなく、on2のコーデック自体の仕様で、VP6Fはon2の
仕様に合わせたものってことでは？
117:名無しさん＠編集中
09/10/07 02:02:55 kACeQjrP
VP6にはバージョンが0-2まであって、それぞれVP60,VP61,VP62のFORCCを持ってる。
これはVP6を作ったOn2が決めた。
VP6Fは、FFMPEGが勝手に決めて使っているVP6のFOURCC。バージョンの区別をしない。
flvファイルの場合、コンテナはVP6のバージョンを区別せず扱ってるので、
flvパーサがvp6のバージョンを知ることは面倒。（vp6のデータの中身を調べる必要がある）
だからlibavcodec(FFMPEG)では便宜的にVP6FのFOURCCを使っているんだと思う。
上下反転は>>116の言う通り、YUVフォーマットの混乱の影響だと思う。
RGBにデコード（AviUtlのコーデックの設定で「YUY2で展開する」のチェックをはずす）すれば反転解消するし。
つーか、VP6スレでやれ
118:名無しさん＠編集中
09/10/07 02:38:14 nCX90d4i
いや、VP6FはflipされたVP6だよ。
flvコンテナではvp6だけが何故かflipされてる。
それでflvからaviへの無変換詰め替えのときに困るってんで、'VP6F'というfourccが生まれた。
ffmpegが対応する前の話。
119:名無しさん＠編集中
09/10/07 08:08:54 Dm53UpbC
>>118
ffmpegが作ったんじゃないなら、VP6Fってのはどこが決めたFOURCCなんだろ？
120:名無しさん＠編集中
09/10/09 22:36:33 pLFH6L7x
IgCodecの圧縮どんなもんか試してみたらサムネ作成らしきタイミングでExplorerが落ちるんでググってやってきました
>>101によると作者環境でも再現せず他の報告もないそうなので諦めて帰ります
XPSP3/C2Q9300@400x6.0/RAM3G+RAMDisk3G
編集・圧縮に使ったソフト：VirtualDubMod 1.5.10.2
121:名無しさん＠編集中
09/10/19 08:03:36 2bV4/Fnc
あまラボで64bitアプリから32bitコーデックを扱えるようにするプロキシコーデックを公開予定になってる。
ほかの32bitコーデックも64bitアプリで使えるらしい。aviutl出力プラグインのmm_srvみたいなものなのかな。
他のコーデックで使うメリットはあんまりないのかなーと思うけどどんな感じだろうね。
122:名無しさん＠編集中
09/10/19 14:06:16 sqrOs7Z+
URLﾘﾝｸ(lists.mplayerhq.hu)
>4-6% faster huffyuv decoding if using left or plane mode and yuv
123:名無しさん＠編集中
09/10/19 17:24:23 zOAGhtLu
64bitで動くエンコードソフトって、VirtualDubのx64版以外だと何があるだろう？
124:名無しさん＠編集中
09/10/19 17:55:01 Ki8xBX4/
x264 64bit版
32bit版より1割以上速くなるよ
125:名無しさん＠編集中
09/10/19 18:13:59 sqrOs7Z+
avidemuxも64bitで動くよ。但しwindows向けの64bitビルドはまだ無いようだけど。
126:名無しさん＠編集中
09/10/19 18:31:19 x0S6Hz/t
肝腎のAviSynthの64bit化が進まないとどうにもねぇ
2.6で64bitバージョンも正式リリース&32bitは開発終了とかやってもらわんと
127:名無しさん＠編集中
09/10/19 20:16:43 UknK+UXf
可逆じゃなくてスマヌ
>>121
有り難う、昔matroxのftpで拾ったDVC-PRO50が使い続けらるなら嬉しい話だ
今のマシンパワーなら可逆圧縮で良いんだけど、昔の取り溜めして放置している素材なんかが・・・
MainConceptだと\80kとかするんよね（他のcodecも入ってだけど）
128:名無しさん＠編集中
09/10/19 20:58:46 sqrOs7Z+
ffmpeg系のプログラムは対応してるはず>DVC-PRO50
ってことでx64版のffdshowじゃ駄目なん?
129:名無しさん＠編集中
09/10/20 01:14:02 bcPzNODS
鬱ビデオCLIで出ないかなぁ
130:名無しさん＠編集中
09/10/20 01:24:26 czJOgAFl
>>126
32bitのavisynthで64bitのx264使う方法はあるよ。
131:名無しさん＠編集中
09/10/20 01:39:19 4En/TOZa
>>130
avs2yuvもモルダーさんのツールも知ってるよ
俺が言いたいのはAviSynthそのものを64bitにしないと、たいした高速化は望めそうもないんじゃないかってこと
ｘ264がいくら速くなってても、synthが足を引っ張ってるのが現状でしょ
132:名無しさん＠編集中
09/10/20 15:09:30 Tv7Jz6o3
>>131
何か勘違いしているようだけどavisynthを64bit化することの利点は速度ではなく使用可能なメモリーサイズが増えることにある
速度は高度な最適化が進まんとたいして速くならんのでフィルター類が64bit化されても速度はたぶん今と変わらないよ
133:名無しさん＠編集中
09/10/20 16:43:42 vY04tZq8
ｽﾚﾘﾝｸ(avi板:87番)
Help Me!
134:名無しさん＠編集中
09/10/20 21:18:04 R2G2bmkn
>>128
をぉ、重ね重ね有り難う
7のアップグレード頼んであるんで届いたら試してみます
135:名無しさん＠編集中
09/10/21 04:21:10 cN1jTIQU
>>133
HuffyuvSはいいのか？と思ってググったけど、
URLﾘﾝｸ(www.megaupload.com)は俺の環境では画像が乱れる。
URLﾘﾝｸ(wiki.nicomas.net)コーデック#te866ea1
MTモードでエンコードしたデータは、オリジナルのHuffyuvではデコードできないので注意。
URLﾘﾝｸ(freesoft.tvbok.com)
huffyuvsは色信号のスケールを変換しない
huffyuvsとhuffyuvの違いを解説しているサイトを探してみた所、なんとCCE販売元NOVACのCCEのFAQで解説されていました。
CINEMA CRAFT ENCODER BasicのFAQ
Ａ．輝度レベルの設定は、入力がRGBの時のみ有効に機能します。
入力がYUY2の時は、変換せずにそのまま使用しています（スケール変換はしていません）。
もともとYUY2はCCE-Basicが受け付けることができる唯一のネイティブフォーマットです。入力としてRGBを受け取った場合、それは内部的に
YUY2に変換されます。そのときの変換方式が２種類あり、その方式は輝度レベルのところで選択可能です。もしネイティブのYUY2がスケール
変換されてしまうのであれば、0-255で変換したYUY2の信号もスケール変換されてしまうはずです（16-235で変換したものは二重に変換されることになってしまいます）。
スケール変換をしているのは huffyuv 自身になります。スケール変換をしたくないのであれば、 HuffyuvS をご使用ください。
FAQなんぞ読まなくても普通に使用するには何にも問題なかったのですが、読んでみるものですね。。。。
huffyuvsは、RGB－YUY2間で行われる無駄な輝度変換を省略する事が出来るようです。
つまりは、動画編集ソフト等で動画を作成する時にキチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されて今い
ますよ。という事らしいです。
ＴＶキャプを行う場合でも、元々がTV信号ですのでhuffyuvsの方が向いているでしょう。
だとさ。
136:名無しさん＠編集中
09/10/21 06:01:37 911ZR/Fr
別にTVキャプなら通常RGBなんて介在しませんからhuffyuvでなんら問題はない
137:名無しさん＠編集中
09/10/21 06:27:43 cN1jTIQU
>>136
TMPGEncはRGBだったと思う...
138:名無しさん＠編集中
09/10/21 06:48:39 kPqsOhG8
ていうか、>>133のツッコミどころは
＞huffyuvsとhuffyuvとマルチスレッドのhuffyuvを右クリックでインストールしたんだが。
のとこだよね。
マルチスレッド版はFOURCCが違うから共存できるとして、
FOURCCが同じHuffyuvsとHuffyuvを同時インストールするとどういう挙動になるんだろう。
しかも両方ともアンインストールがうまくいかないバグがあるようだし。
139:名無しさん＠編集中
09/10/21 07:46:00 kPqsOhG8
ごめんFOURCCが同じとか大嘘だった。いや～ん、こっぱずかすぃ。。｡･ﾟ･(ﾉ∀`)･ﾟ･｡
Huffyuv HFYU
HuffyuvS SHYU
Huffyuv_mt HYMT
自分でもなんでかわからないけど物凄い変な思い込みがあったようだ・・・・orz
・・・・・・あれ？じゃあなんでデコードのミスマッチだの画面が乱れるだの騒いでるんだ？？？
140:名無しさん＠編集中
09/10/21 08:08:34 cN1jTIQU
FourCCがSHYU（HuffyuvS）なのは確認したけど、やっぱ画が乱れる。
>>139は正常に再生できてるの？
141:名無しさん＠編集中
09/10/21 08:40:21 kPqsOhG8
>>140
うちはHuffyuvSは入れてないんだ。
すまんけど、ちょっと今はコーデックまわりをいじりたくないので検証はできそうにない。
142:140(巻添え規制中シベリアより)
09/10/21 15:34:33 KOD/IOCv
>>141
なんか細かい横線が気になったので、
Field Thresholdを288から576に変えたら正常に再生できたｗ
URLﾘﾝｸ(dtv.sakura.ne.jp)
＞フィールド閾値というのは、映像のフィールド数（縦のサイズ）が
＞この数字を超えるとインターレースとして扱うというものです。
＞バージョンによっては設定項目がないものもあります。もっとも、
＞圧縮方法が多少変わるだけで、あまり大きな影響はありません。
＞むしろ、圧縮時と展開時で違っているとダメな場合があるようなので
＞デフォルトのままにしておきましょう。
フィールド敷居値のヘルプ(英語版)↓
Video with more than <threshold> lines will be processed interlaced by Huffyuv.
The default value (used in older versions) is 288.
Warning: Decompressing a interlaced video with a higher current threshold (so that huffyuv will not use field processing) will fail!
The setting in stored in the ini-file, not in the video!
143:140(巻添え規制中シベリアより)
09/10/21 15:35:45 KOD/IOCv
追伸
ところで、ググってたらこんな書き込み見つけた。
識者さん、教えてください。↓
870 ：692[sage]：2009/06/22(月) 19:25:01 ID:sKsKMchC
Huffyuv_MT使って見ましたが、画像遅延は変わりありませんでした。
13分程の録画で開始時はピッタリでしたが、終わりでは画面が少し遅れていました。
Thresholdは何を設定すればいいのでしょう？一番大きい数字を設定しましたが、
720ないので、1080iはもとより720pもちゃんと処理しないのでしょうか？
（【HDMI】BMD Intensity 10枚目【キャプチャー】）
144:名無しさん＠編集中
09/10/22 18:59:20 IxmMTt03
・UtVideo Codec 7.0.0 （x64版の追加）
URLﾘﾝｸ(umezawa.dyndns.info)
・窓の杜 - 【NEWS】64bitアプリケーションで32bit用の動画コーデックを利用可能に「Proxy Codec64」
URLﾘﾝｸ(www.forest.impress.co.jp)
145:名無しさん＠編集中
09/10/23 03:09:50 GBKkev93
俺にとっての問題は64bitOSを使っても用いてるキャプチャソフトも編集ソフトも32bit版しかないということだ
146:名無しさん＠編集中
09/10/23 16:25:55 8ehsYAY0
Linuxだとほぼ全てのアプリケーションにamd64版があるようだけど、Windowsで64bit版が少ないのって何で?
147:名無しさん＠編集中
09/10/23 19:34:16 6VAqc4Ca
作るコスト＞得られる利益 だから。
148:名無しさん＠編集中
09/10/24 00:07:06 bwlt5OW7
UtVideo Codecはファイルは規定の位置にインストールされてるけどvctest・Veedub64では選択できなかった。
Lagarithはx86のほうが早くてProxy Codec64かましたx86が若干x64よりも早かった・・・
149:名無しさん＠編集中
09/10/28 22:29:06 wyXGbleM
>>135
色空間スレでまるもさんが実験したけど
伸張圧縮しないHyffyuvsはRGB<>YUV変換誤差がでかいよ
RGB化したときに切り捨てられる15以下235以上を保持することがメリットってだけ
元はAviutlの伸張圧縮に問題がある次期にそれように作られたもの
ノバックの書き方がおかしいんだが
”キチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう”
んじゃなくて
”伸張圧縮しない環境で輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう”
>>137
それは2.5PLUS時代まで
ExpressシリーズはYUY2だよ
150:名無しさん＠編集中
09/10/30 03:46:03 7qgY3kVS
huffyuvsを64bitのOSにインストするにはどこを書き換えたらいいか
誰か分かる人いますか？huffyuvのインスト方法を参考にやっているのですが、
どうも上手くいきません。
151:名無しさん＠編集中
09/10/30 04:11:47 2U1ICUyD
べつにhuffyuvでいいじゃん
ccespパッチあたってれば問題もないんだし
152:名無しさん＠編集中
09/11/02 20:14:14 CP/HHgSf
Avidemuxの64ビット版ってどこにあるの？
153:名無しさん＠編集中
09/11/03 13:42:41 aMKLOss+
doom9。
でも正直使い物にならない。
154:名無しさん＠編集中
09/11/03 17:31:29 aMKLOss+
>153
ごめん。間違えた。
155:名無しさん＠編集中
09/11/04 21:36:11 0KOYq+w7
誘導されました
元の画質からほぼ無劣化で出力できるコーディックないでしょうか？
Huffyuv211を使ってたのですが最近これで出力すると再生する時に変になります。
220にバージョンアップすると出力99%のとこでVS12が強制終了してしまいます。
どうすれば良いでしょう？何か高画質のままほぼ無劣化で出力できるコーディック教えて下さい
156:名無しさん＠編集中
09/11/04 22:07:04 Gawi44ah
UtVideoでしょ。はやいし。
157:名無しさん＠編集中
09/11/04 22:09:58 eyZ/kLm+
>>155
バカタレ
おれがここに誘導したのは質問しろってことじゃねーよ
読めってことだよ
なぜなら>>2に答えがあるからだ
158:名無しさん＠編集中
09/11/04 23:32:31 0KOYq+w7
>>157
なるほど
では>2の中だとどれが一番オススメでしょう？
159:名無しさん＠編集中
09/11/05 00:28:02 hksH6wCk
すでに2回UtVideo薦められといて、さらにそれを聞くのか
ところで7.0.1が来てるな
160:名無しさん＠編集中
09/11/05 14:07:22 guEmtvx+
UtVideoをインストールすると4つ選べるようになります
どれが一番良いんですか？
161:名無しさん＠編集中
09/11/05 14:22:51 hksH6wCk
さあねえ、あれは状況に応じて使い分けるものだから、どれがいいかなんて考えたこともないな
162:名無しさん＠編集中
09/11/05 23:15:34 krxCtlOv
>>160
ULY2が一番軽い。
163:名無しさん＠編集中
09/11/05 23:38:10 Ef6RJI9A
>>162
お前そういう教え方はイジメだろ・・・ｗ
>>160
色空間がわからないならULRGでも使っとけ。
164:名無しさん＠編集中
09/11/05 23:44:34 hksH6wCk
単純に軽いってんならULY0のほうが軽いだろ
色差の情報量はULY2の半分しかないんだから
165:名無しさん＠編集中
09/11/06 04:53:14 BzYkDogP
>>160
YUVフォーマット及び YUVとRGBの変換
URLﾘﾝｸ(vision.kuee.kyoto-u.ac.jp)
カラーフォーマットのナゾ
URLﾘﾝｸ(www.nnet.ne.jp)
これらのページの熟読推奨
166:名無しさん＠編集中
09/11/06 21:30:13 8Q5ZJdps
なんだかんだ言っても優しいやつらだな (;_;
167:名無しさん＠編集中
09/11/06 23:05:24 mNqPq/k/
>>165
>>160 じゃないけど、こういうの待ってた！！
でも読んだけど、いろんなデータの取り方があるのは解るけど、
どういうときどれ使えばいいのかは結局わからん・・・
そもそも、YUV422 が 16bit/pixel で、それが RGB24 (24bit/pixel でしょ？）
と可逆変換できるのが意味わからん・・・
ましてや YUV420 の出番がいつなのか、まったくもってわからん・・・
168:名無しさん＠編集中
09/11/06 23:31:01 mNqPq/k/
URLﾘﾝｸ(www41.atwiki.jp)
>ULY2の方は(中略)入力をRGBで与えても、
>内部で強制的にYUV422に変換されるため
>完全な可逆圧縮となるわけではありません。
だそうだから、ソースを問わないのは RGB の ULRG。故に
＞色空間がわからないならULRGでも使っとけ。
ってことか、な？
169:名無しさん＠編集中
09/11/07 00:39:49 hRywxXVv
UtVideoに非可逆モードが付くのはいつなんだろうか？
再エンコするので画質そこそこ容量小さめ転送量も少なくHDDに優しい
非可逆モードが欲しい。転送量は10MB/sくらいで。
170:名無しさん＠編集中
09/11/07 01:20:18 nFr82N34
再エンコするから可逆なんだろ？なに言ってるの？
171:名無しさん＠編集中
09/11/07 03:24:56 N7piNmn9
AMVでも使ってろ
172:名無しさん＠編集中
09/11/07 04:42:38 nd0J9vRN
非可逆ならくさるほどあるだろーに。
173:名無しさん＠編集中
09/11/08 14:10:51 91TdnYpi
DV Type2は可逆圧縮できますか？
もしできるとしたら、おおよそ何割くらい小さくできますか？
174:名無しさん＠編集中
09/11/08 14:52:08 ewRe+iAf
>>173
それ質問になってない
175:165
09/11/09 04:58:58 D746S24I
>>167-168
・入力か最終出力が、MPEG-2とかMP4(H.264)とかFLVとかなら、YUV420系を使っておくほうがいい
（インターレース動画の場合はYUV422系がいいかも）
・編集等でアルファチャンネルが必要な段階ではRGBA一択
雑に書くとこんな感じかと。
176:167
09/11/09 06:59:23 o3NoXhw+
>>175
補足ありがと。２つめは当然だね。
１つめの理由は自分で調べるとして、ガイドラインとしては十分ですわ。ありがとー。
177:名無しさん＠編集中
09/11/09 09:28:58 HjrlqfFM
>>173
DV Type2は可逆圧縮ですか？
という質問なら答えられる人がいると思う。
> おおよそ何割くらい小さくできますか？
実際にやってみろよ。
178:173
09/11/15 17:50:53 FvCQHsUT
質問かえますね。
DV Type2をバックアップしたいんですけど、容量を考慮してできるだけ小さいファイルサイズ
にしたいです。
このスレでいう可逆圧縮とはちょっとニュアンスが違うのかもしれませんけど、例えば7-zipや
cab等でも可逆圧縮できますが、データの性質上ほとんど小さくなりません。
圧縮した状態で再生できるかどうかは問いません。存在するかどうかわかりませんが、もし
DV Type2のデータを可逆圧縮でそれなりに小さくするものをご存じでしたらお教えください。
179:名無しさん＠編集中
09/11/15 18:31:09 b+lovGqj
とりあえず世界最強はKGBらしいが
URLﾘﾝｸ(www.dryout.info)
これで縮むかどうかは知らん
180:名無しさん＠編集中
09/11/15 19:24:33 kj+Idcew
DVつーとYUV4:1:1だよなあ。4:1:1に対応したコーデックなんてあんのか？
そういう意味での1次劣化をよしとするならx264のqp=0ならかなり縮むんじゃなかろうか。
181:名無しさん＠編集中
09/12/12 06:52:32 YlVhckni
>>179
推奨システム
CPU: Intel Core™ または AMD Athlon™ 64 と互換性のあるCPU
RAM: 1GB
どんだけメモリ喰うんだｗ
182:名無しさん＠編集中
10/01/01 21:42:40 CckcAv6F
止まってしまったな。
183:名無しさん＠編集中
10/01/19 03:15:35 bz5jALeR
RGBで圧縮したAvi動画がなぜか再生できない。
MedioInfoで確認したところ、情報すら記載されてなかった。
環境はWindows 7 64bitでデコード速度を優先しているんだけど、原因は何だと思われます？
184:名無しさん＠編集中
10/01/19 04:04:46 bz5jALeR
>>183
自己解決した
サイズが2GB上回ってたわ
でも、AVI2.0だと思ってんだが
185:名無しさん＠編集中
10/01/19 04:09:18 u6TWCvkW
>>183
＞RGBで圧縮したAvi動画がなぜか再生できない。
UtVideoのULRGのことだと推測するが、コーデック名くらいしっかり書けよ。
＞MedioInfoで確認したところ、情報すら記載されてなかった。
何の情報だよ。何が言いたいのかさっぱりわからんわ。
＞環境はWindows 7 64bitでデコード速度を優先しているんだけど、原因は何だと思われます？
とりあえずいったんアンインストールして最新版を入れなおしてみれば？
186:名無しさん＠編集中
10/01/19 04:10:27 u6TWCvkW
ぐお、更新してなかった・・・。
>>184
思ってるとかじゃなくちゃんと調べなよ。
187:名無しさん＠編集中
10/01/19 10:51:01 0aKouGO/
>>186
乙かれー
188:名無しさん＠編集中
10/01/19 15:20:12 bz5jALeR
>>185
スマン
コーデックはUtVideoです。Lagarithも同じ現象だった
Mediainfoで記載してなかったって言うのは、ようはコーデックが何に使われてるだとか、
ビットレートの情報が書かれてなかった
最新版には入れなおしても変わりなかった
ただ、AVIを2G以内に収めれば再生もできたし、Mediainfoで情報も記載されてあった
AVI2.0では2G以上でも再生されると思ってたんだが、 エンコードツール・コーデック自体AVI2.0には対応してなかったみたい
189:名無しさん＠編集中
10/01/19 16:36:44 1zJ02p8S
>>188
＞AVI2.0では2G以上でも再生されると思ってたんだが、
＞エンコードツール・コーデック自体AVI2.0には対応してなかったみたい
コーデックは無関係。エンコードツールがAVI 1.0しか吐き出せなかっただけだな。
どんなツール使ってるのか知らんけど、プラグインとかでAVI 2.0に対応してる可能性もあるとは思うが・・・。
あと、こういう場合は質問時にエンコードツールの名前も書いとくと回答がもらいやすいかもね。
190:名無しさん＠編集中
10/01/22 02:47:20 nRuUFSLl
すみません、可逆圧縮コーデックに限った話ではないのですが、１つ質問させて下さい。
質問： コーデックが対応している入出力形式を調べるツールのようなものは、何かありますでしょうか？
例えばUtVideoの場合、readmeなどから推測すると、
URLﾘﾝｸ(goldenhige.cocolog-nifty.com)
にあるように、ULY0だったら入出力ともに「RGB24、RGB32、YUY2、YV12」に対応しているようなのですが、
色々なコーデックについて、このような対応形式を簡単に調べる方法はあるのでしょうか？
一応思いついた方法としては、
・Aviutlの「コーデックの設定」でYUY2圧縮のチェックボックスが有効になっていればYUY2入力に対応？
・AvisynthでAVIFileSource("ULY0.avi",pixel_type="YUY2")といった感じでpixel_typeで色空間を指定して読み込み、
エラーが発生しなければ、その色空間での出力に対応？
といったところなのですが、調べられる項目が限定されていますし、そもそもこれが正しいのかすら自信がなく・・・。
よろしくお願いいたします。
191:名無しさん＠編集中
10/01/22 02:50:11 tOQIZQeQ
readmeとかヘルプとか作者のHPとか見るのが良いんじゃないな。
192:名無しさん＠編集中
10/01/22 03:07:06 nRuUFSLl
>>191
う、それは確かにそうなのですが、何か他にツール的なアプローチは無いものかな～と思いまして。
193:名無しさん＠編集中
10/01/22 03:29:47 7vvChrvK
>>192
AviSynthで読み込み
info() で表示
後はお好きなように・・・
194:名無しさん＠編集中
10/01/22 04:13:41 nRuUFSLl
>>193
ありがとうございます。Info()は結果的にどの色空間で読み込まれたのかは表示されますが、
今回はコーデックの対応形式を知りたかったので、>>190に書いた方法の２番目で、
AvsPのプレビューでエラーの発生有無をチェックしていました。
追記ですが、スレを見直して>>41さんの書き込みからavs2aviというのを初めて知り、試してみました。
avsで適当なソースを読み込んで
ConvertToRGB24()、ConvertToRGB32()、ConvertToYUY2()、ConvertToYV12()
のいずれかを行なってから
avs2avi test.avs -s codec_param.txt -e
を実行すると、その色空間での入力に対応したコーデックがリストアップされて表示されるのですね。
RGB24、RGB32、YUY2、YV12については、このavs2aviを用いた方法と、>>190の２番目の方法とで
入出力の対応がチェックできると思えばよいでしょうか？
仮にこの方法でよいとしても、RGBAやUYVYなどについてはどうやって判定すればよいのでしょう・・・？
他にも良い方法をご存知の方がいらっしゃいましたらよろしくお願いいたします。
195:名無しさん＠編集中
10/01/22 23:38:21 FhgZ336g
UtVideoの作者さんから調査への協力依頼だそうな
URLﾘﾝｸ(umezawa.dyndns.info)
196:名無しさん＠編集中
10/01/23 00:25:49 prxWNPEW
可逆圧縮でもビットレートってあるけど、映像にはまったく影響がないと思っていいの？
何か、レートが100Mbps以上だけどUtVideoのデコード優先と圧縮優先じゃ、30Mbps以上も差があるんだけど
197:名無しさん＠編集中
10/01/23 01:36:00 2sM0IA61
>>196
可逆圧縮なんだから、色空間さえ間違えずに扱えば映像にはまったく影響はない。
一般的には
デコード優先→データ圧縮率は低め＝圧縮後のデータ量は多め→圧縮後のビットレートは高め
圧縮率優先→データ圧縮率は高め＝圧縮後のデータ量は少なめ→圧縮後のビットレートは低め
と考えればいいだけだと思う。
ソースやコーデックへの渡し方によっては結果が違ってくるだろうけど。
198:名無しさん＠編集中
10/01/23 06:39:24 prxWNPEW
あー、なるほど
てことはソースが4k2kとかだったらまた違うのかな？
4k2kとかそれ以上の解像度って高画質であれば100Mbps以上必要でしょ？
199:名無しさん＠編集中
10/01/23 15:39:03 s9Hpd9w6
そりゃソースによるじゃん。極端な話黒1色の静止画なら1kbpsでだって無劣化で圧縮できるし（アルゴリズムによるけど）
200:名無しさん＠編集中
10/01/23 17:53:52 prxWNPEW
可逆圧縮ってまた元に戻せるから可逆って言うんだよね
だったら、可逆圧縮したAVIファイルをカットなんかした後に再度エンコするとき、
可逆圧縮にしたらどうなるの？
可逆→可逆
201:名無しさん＠編集中
10/01/23 18:25:45 mrh65ujR
色空間変換を挟まなければ劣化はない
202:名無しさん＠編集中
10/01/23 19:18:41 gl6qXM43
>>195
Windows7の120日評価版にソースからビルドした7.0.1のx64msiはインストール失敗したので
ICInstallSelfの部分を以前のバージョンに戻してOrcaでmsiにパッチを当てたらインストール
出来ました。
203:名無しさん＠編集中
10/01/23 21:49:49 60QhRN/+
ちょうど資料作りをしてたので、
「可逆圧縮コーデックといえども、途中で色空間の変換が入ると可逆じゃなくなるよ」
っていう件についてのサンプル画像をアップしてみます。
■サンプル画像１
「赤・緑・青・黒のピクセルを敷き詰めたRGB画像」を、
ULY2(YUV422)やULY0(YUV420)で圧縮した場合の劣化パターン
URLﾘﾝｸ(www1.axfc.net)
左がYUV422、右がYUV420。上下の違いは「コーデックの設定」の「YUY2圧縮する」がON(上)かOFF(下)か。（※１）
ピクセルを拡大してみると、色の変わりっぷりがよくわかります。（拡大しなくてもわかるけど）
RGBソースなら、ちゃんとULRGなどを使わないと可逆にはなりません。
※１・・・YUY2圧縮がONだとAviutlがRGB→YC48→YUY2(YUV422)変換したYUV値（この時点で既に劣化）を、
ULY2やULY0が受け取って使う。ULY0の場合はここから更にYUV420化(ここでも劣化)する。
YUY2圧縮がOFFだとAviutlがRGB→YC48→RGB変換したRGB値（この時点では劣化なし）を
ULY2やULY0が受け取り、それぞれの内部でYUV化(ここで劣化)する。
■サンプル画像２
文字を描いたRGB画像をULY0(YUV420)や、x264(YV12=YUV420)でエンコードした場合の劣化
URLﾘﾝｸ(www1.axfc.net)
ニコニコ動画とかで赤い文字がつぶれて見えたりするのも、ほとんどの場合これが原因。
黒背景に赤文字もかなり劣化しますが、灰色背景はもっとすごいことに。
→以前ニコニコ動画に上げてテストした例 URLﾘﾝｸ(www.nicovideo.jp)
上のサンプルではRGB→YUVの劣化にしか触れてませんが、他にもBT.601とかBT.709とかが絡んでくると色々面倒ですね。
204:名無しさん＠編集中
10/01/25 04:01:48 QG59TvId
>>203
ええっ
つまり、BT709で出力したら可逆じゃなくなるのか？！
Aviutlの設定じゃ入力はAutoだけど、出力はBT709になってるぞ
お、おれの可逆動画フォルダすべてが水の泡・・・
205:名無しさん＠編集中
10/01/25 04:08:53 m5Tt1G8v
Aviutlの色空間変換ってデータそのものを変換してる？
動画ファイルの扱いだけが変わってるんじゃないかと思うんだけど
どうなんだろ？
実際Aviutl上で入出力切り替えても見た目ぜんぜん変わらんし・・
206:名無しさん＠編集中
10/01/25 07:35:41 5I8ZVLm6
>>205
RGB出力なら可逆でなくなる
YUVなら変わらない
207:名無しさん＠編集中
10/01/25 14:51:56 PJ+MA5jy
>>204
ソースとか設定によるよ。
>>205
データそのものを変換してるよ
>>206
その言い方は乱暴というか答えになってなくね？
Aviutlの場合の、色空間変換に関係してくる部分を入力側から順にリストアップしてみます。
もちろんデータによっては関係ない部分もあるので大雑把な順番ですが。
変なとこあったらつっこんでください。
１．ソースの内部データ形式（RGB、YUV422(BT.601、BT.709）、YUV420（BT.601、BT.709））
２．入力プラグインの選択（入力プラグイン優先度の設定）
３．入力プラグイン自体の設定（例えばまるもさんのMPEG2読み込みには色空間設定がある）
４．入力プラグインからAviutlへの受け渡し形式（RGB、YUY2、YC48）
５．コーデック自体の内部形式（RGB、YUV422(BT.601、BT.709）、YUV420（BT.601、BT.709））
６．「コーデックの設定」の「YUY2展開する」のON/OFF
７．コーデック自体の出力形式（YUY2出力できるかどうか）
８．Aviutlの入力色空間の設定（BT.601、BT.709、auto）
９．入力時のAviutl内部のRGB→YV48、YUY2→YC48変換
１０．Aviutlの出力色空間の設定（BT.601、BT.709、auto）
１１．「コーデックの設定」の「YUY2圧縮する」のON/OFF
１２．コーデック自体の入力形式（YUY2入力できるかどうか）
１３．コーデック自体の内部保持形式（RGB、YUV422(BT.601、BT.709）、YUV420（BT.601、BT.709））
可逆圧縮しても読み込み方を間違えると元データから変化してしまうので、
このあたりをトータルで見ないと、可逆を可逆として扱えないということになる。
208:名無しさん＠編集中
10/01/25 15:02:07 PJ+MA5jy
あ、あとはYUVのTVスケールとフルスケールというのもあるっけ・・・。
このあたりは主に上の３あたりに含まれるということで・・・。
>>135-149あたりを見ると、５－７、１１－１３あたりも絡んでくるのかな。
209:名無しさん＠編集中
10/01/25 15:32:41 d0QTl4m7
>>207
色変換プラグインというのもあるよ。
プラグインを公開している人は少ないが
8～10の部分をプラグインでいじれる。
210:名無しさん＠編集中
10/01/25 18:53:28 5I8ZVLm6
>>207
>>205の質問の趣旨から外れてるだろ
そりゃフィルター入れりゃ可逆でなくなるのは当たり前
あくまでaviutlでカット編集した時だけの話だろ
211:名無しさん＠編集中
10/01/25 19:36:00 QG59TvId
つまり、aviutlで可逆ファイルを読み込む場合、
色変換の設定の入力・出力は自動で、AVI出力する時、再圧縮なしの可逆のままで出せば問題なし？
可逆読み込み→可逆出力(再圧縮なし)でおk？
今まで未圧縮に再圧縮してたけど・・・
212:名無しさん＠編集中
10/01/25 20:00:43 JV3pQzr9
未圧縮ってのはRGB24だから、もろに色が変わるだろ
213:名無しさん＠編集中
10/01/25 20:03:05 9pLRGCPe
入力／出力の設定はBT.601にすれば従来通り。自動は縦解像度720以上でBT.709と認識するから
709 > 601変換が入る。つーてもカットだけならAviutlは12bit処理なのでマトリクス変換での劣化はない。
まあ再圧縮なしで出力するのが一番いいと思う。未圧縮はRGBだから一番ダメだろ
214:名無しさん＠編集中
10/01/25 20:51:05 m5Tt1G8v
でも601＞709と入出力を切り替えたりしてもAviutl上は
何も変わらんってのはなんでなんだろ？今の見え方を
該当色空間に当てはめてるって事？内部の色の数値は
変わってますよ、って事なんかね？
215:名無しさん＠編集中
10/01/25 21:58:07 QG59TvId
可逆でエンコした動画を再度可逆なら問題なしなの？
今、フォルダから未圧縮すべて消してやり直ししてる
こりゃ、1日以上かかるなorz
216:名無しさん＠編集中
10/01/25 21:59:36 QG59TvId
>>213
いや、可逆したファイルはみんな解像度は1280x720だから、出力をBT709にしてもよかったのか
これは安心した
217:名無しさん＠編集中
10/01/25 22:30:27 QG59TvId
ちょっと待て、再圧縮なしにすると
可逆設定でRGBに設定したから、出力したファイルがRGBになってるぞ
これ正常？
だったら、未圧縮でもRGB何だから変わらないんじゃ？
218:名無しさん＠編集中
10/01/25 22:35:46 9pLRGCPe
>>214
出力は変えてもプレビューには関係ないよ。入力はYUVで読んでればちゃんと変わるが
RGBで読んでたら当たり前だが入力の設定は関係ないぞ。
>>215-216
可逆と非圧縮であることとYUVとRGBであることは全く関係がないぞ。
なんかごっちゃになってないか？言ってることが良く解らん
219:名無しさん＠編集中
10/01/25 23:07:23 QG59TvId
>>218
すまん、えーっと俺の方が勘違いしてるのか？
可逆圧縮コーデックのLagarithやUt VideoでRGB(もしくはRGBA)の設定できると思うが、
これと未圧縮で出力されたRGBと何が違うんだ？
Lagarithでエンコした動画を再圧縮なしにして出力すると、
未圧縮ファイル(RGB)になるんだが、この未圧縮は正常？
220:名無しさん＠編集中
10/01/25 23:09:56 JV3pQzr9
お前、DirectShowで読み込んでないか？
221:名無しさん＠編集中
10/01/25 23:15:16 sYz+wKd2
まず用語を整理しないと混乱する気がする。
再圧縮無し・・・ソースの映像を、形式を変換せずにそのまま出力すること。
出力時にコーデック選択欄の右にある「再圧縮なし」にチェックを入れるとこれになる。
Lagarithで圧縮されたソースを再圧縮なしで出力したらコーデックはLagarithのままだし
ULY2で圧縮されたソースを再圧縮なしで出力したらコーデックはULY2のまま。
※ただし「再圧縮なし」にするとフィルタ等は効かない。
※キーフレーム以外の部分でカット編集した場合は「再圧縮なし」にすることはできず、
必ずなんらかのコーデックで再圧縮（未圧縮も含む）を行なう必要がある。
未圧縮・・・未圧縮RGB、つまりなんの圧縮もされていないRGB映像のこと。
出力時にコーデックの選択で「未圧縮」を選ぶとこれになる。
222:名無しさん＠編集中
10/01/25 23:20:49 QG59TvId
Lagarithで圧縮した可逆ファイルを読み込んだ後、
再圧縮なしにチェック入れるとコーデックには未圧縮になるんだが・・・
バグなのか？
223:名無しさん＠編集中
10/01/25 23:22:44 QG59TvId
>>220
directshow file readerは入ってるが、もしかしてこれのせい？
224:名無しさん＠編集中
10/01/25 23:27:56 sYz+wKd2
>>222-223
とりあえずLagarithで圧縮したファイルを読み込んだら、メニューの「その他→ファイルの情報」を見て、
・ビデオ圧縮
・ファイル制御
・ビデオ展開形式
がどうなってるか確認するんだ。
225:名無しさん＠編集中
10/01/25 23:33:25 QG59TvId
ビデオ圧縮：未圧縮
ファイル制御：DirectShow File Reader
ビデオ展開形式：RGB
になってたよorz
Mediainfoで見ると、ちゃんとLagarithになってるんだけど
どうすればいい・・・？
226:名無しさん＠編集中
10/01/25 23:40:08 JV3pQzr9
AVI/AVI2 File Readerの優先度を一番上にすればいい
227:名無しさん＠編集中
10/01/25 23:46:28 QG59TvId
>>226
マジ、㌧クス
何でDirectShowなんか糞プラグイン入れたんだろ・・・
可逆しなおすため1日費やすかorz
228:名無しさん＠編集中
10/01/25 23:50:36 JV3pQzr9
ds_input.auiは使い方さえ間違えなければとても優秀なプラグイン
糞呼ばわりするようなオマエが糞なんだよ
229:名無しさん＠編集中
10/01/25 23:52:31 QG59TvId
>>228
そうだな、確かにそうかも知れん
とりあえずは感謝する
でも、マジでやり直すの面倒だorz
230:名無しさん＠編集中
10/01/26 00:04:33 M+i4gELY
Lagarithと一口に言っても、「RGB24, RGB32, RGBA, YUY2, YV12」と、内部形式が色々あったりするよね。
圧縮方法と展開方法の組み合わせを間違えるとそこでも色空間変換が・・・。
231:名無しさん＠編集中
10/01/26 00:47:30 L31xexlo
>>230
いや、それは気をつけてるつもり
Lagarithの設定はRGBがデフォで、それをAviutlに読み込ませて
カットした後、再圧縮なしにすればおkじゃない？
Ut Videoも同じ感じで・・・
232:名無しさん＠編集中
10/01/26 02:55:03 jhlWXWIs
やっぱりRGBがサイキョーかぁ～～
233:名無しさん＠編集中
10/01/26 03:20:22 M+i4gELY
ID:QG59TvId ＝ ID:L31xexlo だと思うけど、そもそも何をやりたいのかよくわからない。
BT.709で出力してると言ってるから、なんらかのYUY2ソースを
LagarithのYUY2で圧縮してるのかと思ったらLagarithはRGBで使おうとしてるようだし。
>>231では「Lagarithで圧縮したファイルを読み込んでカットして再圧縮無しで出力」と言ってるから、
別ソフトでRGBで編集した映像データをLagarithのRGBで圧縮して、それをAviutlに読み込んで
不要部分をカットして再圧縮無しで出力したいということなんだろうか？
でもそれならずっとRGBで扱うわけだから、Aviutlの入出力の色空間は関係ないはずだし、
そもそもそんなカット編集だけをAviutlでやる意味がよくわからないというか・・・。
作業する前にそのへんをちゃんと整理して理解しないと、作業が無駄になる気がする。
234:名無しさん＠編集中
10/01/26 03:46:13 L31xexlo
すまん、はっきり言うと
ゲーム動画をlagatithで録画し、aviutlに読み込ませカットした後、
色空間とか触れず、そのままの状態で元に戻したかっだけ
つまりカットと編集をしたかったんだ
BT709で出力はやめて自動にしたけども、ゲーム解像度が1280x720だから大丈夫な気がした
7個目の作業中だよ、今orz
235:名無しさん＠編集中
10/01/26 15:06:57 NRku1dVF
そもそもキャプチャの色空間ってYUVじゃないの？
236:名無しさん＠編集中
10/01/26 15:39:42 jhlWXWIs
キャプチャボードとか使ってないんじゃない？
自画面キャプチャならRGBのが普通なんじゃないの？
わざわざYUVに変える意味は無いと思うし
237:名無しさん＠編集中
10/01/26 15:56:42 Fdwd/7YX
つうかLagarithって圧縮率は高いけどエンコード速度は遅いから
リアルタイムでキャプチャと同時に圧縮していく場合に使うのには向かないんじゃないっけ。
RGBでキャプチャするにしてもHuffyuvとかULRG使ったほうが早いみたいだし。
録画中は無圧縮で中間出力して録画終了時にまとめて圧縮するタイプのソフトなら
Lagarithでもいいかもしれないけど。
あまラボ ビデオコーデック・ベンチマーク2009
URLﾘﾝｸ(amalabo.blog35.fc2.com)
238:名無しさん＠編集中
10/01/26 16:33:07 VYAktjG8
ていうか誰も触れてないけどAviutlならコーデックの設定でYUY2で圧縮のチェック外さないと
RGBで出力できないでしょ。試せばわかるけどYUY2のチェックはいってるとLagarithでRGB指定しても
YUY2でやったときと同一になるから。
239:名無しさん＠編集中
10/01/26 16:42:53 NRku1dVF
>236
ああそっか。PSとかXBOXの取り込みだと思い込んでた。
240:名無しさん＠編集中
10/01/26 17:13:36 Fdwd/7YX
>>238
今色々試してるけど、Lagarithってそのへんわかりにくいね。
UtVideoならRGBとYUV422とYUV420が明確に分かれてるからわかりやすいけど・・・。
241:名無しさん＠編集中
10/01/26 17:33:38 /pJ51WOH
じゃあRGB動画でも[YUY2で展開する]のチェック外さないと
X264GUIに渡す時
RGB>YUY2が
RGB>YC48>YUY2になって劣化するの？
242:名無しさん＠編集中
10/01/26 18:02:46 Fdwd/7YX
>>241
うまく答えづらいけど、まず
「無圧縮のRGB動画」
「ULRGで圧縮したRGB動画」
「LagarithにRGBで入力してRGBモードで圧縮したRGB動画」（※１）
※１・・・>>238にあるようにYUY2入力してRGBモードで圧縮したものは駄目
をAviutlのAVI/AVI2 File Readerで読み込むなら、そもそもYUY2展開ができないので、
コーデックの設定のとこの「YUY2で展開する」のチェックの有無に関わらず、RGBで読み込まれる。
つまり、読み込みの時点では、
RGBデータ→RGBでAviutlへ受け渡し→Aviutl内部で「RGB→YC48変換」
となる。ここまでは劣化なし。
x264GUIに出力する際の流れは以下のようになる。
１．Aviutl内部でYC48→YUY2変換（RGBからのYC48→YUY2変換になるのでこの時点で色空間変換による劣化）
２．１のYUY2データをx264GUI出力プラグインへ渡す
３．x264GUIプラグイン内部で、YUY2→YV12変換（ここでも色空間変換による劣化）
４．３のYV12データをエンコーダであるx264へ渡し、エンコードする。
（ここはそもそも可逆じゃないので非可逆圧縮による劣化が発生）
RGBデータを読み込んでYUV420（x264とか）で出力した場合の劣化具合は>>203のサンプルを参照。
243:名無しさん＠編集中
10/01/26 18:13:56 /pJ51WOH
>>242
ありがとう
なるほど理解できました
244:名無しさん＠編集中
10/01/27 00:58:58 k8i3Cm4Q
x264で一生懸命設定煮詰めたエンコで赤いスカートの縁が
ギザギザになって悩んだっけ・・・
上とは関係ないけど色々ググッたらutのRGB&RGBAの展開の設定を
YUY2で展開するにしてた・・これって展開時に劣化してたって事だよね？
245:名無しさん＠編集中
10/01/27 01:35:02 U5LC0AeY
いやYUY2で展開する設定だったらRGBのものはRGBで展開される。
逆に出力時はRGBで圧縮（YUY2で圧縮のチェック外す）じゃないとRGBで出力されない。
246:名無しさん＠編集中
10/01/27 01:45:34 k8i3Cm4Q
>>245
YUY2で展開する、なのにしてないって事？RGBで展開してるなら問題ないって事だから良いのか・・・
YUY2で展開する、のチェックはずしたらまずいのかな？
出力はグレーアウトしてるからたぶん強制的にRGBになる物なんだと思う
247:名無しさん＠編集中
10/01/27 02:32:25 U5LC0AeY
ああごめんutをutlって読んでたわ。動画読み込んだ際にビデオ展開形式がRGBになってたら大丈夫でしょう、多分。
utはテストしてないから気になるならハッシュでも比較してみてください・・・
248:名無しさん＠編集中
10/01/27 03:26:26 k8i3Cm4Q
>>247
とん、随分Aviutl使ってたけどファイルの情報って知らなかった・・・
249:名無しさん＠編集中
10/01/27 04:27:03 CZaIPNtC
UtVideoのULRGとULRAは、YUY2での出力(デコード)はできないようになってるから
「YUY2で展開する」にチェックを入れても、
「YUY2で出力して渡すのは無理だよー」
ということでRGBで読み込まれる。
「YUY2で圧縮する」のチェックがグレーアウトしてるのは、
YUY2での入力ができないようになっているから。
UtVideoの各コーデックが対応している入出力形式については
公式のreadmeとか>>190のリンク先とかを参照かな。
なんにせよ、読み込んだら「その他→ファイルの情報」を見て、
どのプラグインでどの形式で読み込んだのかをしっかり確認したほうが良いですな。
250:名無しさん＠編集中
10/01/28 12:19:55 hsgeh8rl
ふう、やっと変換作業終わった
1日以上費やしてしまった
これで問題何ひとつないよね
キャプチャボートは使ってない。 DxtoryでLagarithに設定して録画した動画だから
元がLagarithだから、それを無劣化で色空間とか触れずにカットだけするつもりだった
・・・ってコーデックの設定のLagatirh見たら
YUY2で展開する、YUY2で圧縮する、圧縮の設定を保持する全部にチェック入ってるじゃないか！
誰か助けてorz
251:名無しさん＠編集中
10/01/28 12:40:36 5VSRrvw8
もう一度始めから変換するしかない
ｶﾞﾝｶﾞﾚ！
252:名無しさん＠編集中
10/01/28 13:36:29 hsgeh8rl
>>251
おぃ・・orz それ言うなw
マジなのか？
失敗したのか？
やり直しなのか？
253:名無しさん＠編集中
10/01/28 13:52:52 5VSRrvw8
>>252
最近の流の中で勉強した限りでは君がやりたいことをやるためには
少なくとも「YUY2で圧縮する」のチェックを外す必要があると理解した
俺の理解が間違っていたらやり直す必要ないかも
知識のある方のレスを待つましょう (-人-)
254:名無しさん＠編集中
10/01/28 14:47:51 Y57l26L+
別にYUYだから見れたもんじゃないとかそういう事は無いだろう
でもやっぱRGBがサイキョーだな
422とか420とか、端折ってる訳だし
255:名無しさん＠編集中
10/01/28 15:28:35 X2+pqjxH
URLﾘﾝｸ(umezawa.dyndns.info)
Windows 7 Professional 32bit
OS標準に加えて、CCCP(Combined Community Codec Pack)をインストール完了後の状態より検証開始
6.1.0インストール成功、検証用ツールでの表示を確認、アンインストールも正常に完了。
7.0.0 (x86)インストール成功、検証用ツールでの表示を確認、アンインストールも正常に完了。
7.0.1 (x86)インストール成功、検証用ツールでの表示を確認、アンインストールも正常に完了。
7.0.2 (x86)インストール成功、検証用ツールでの表示を確認、アンインストールは実際に使う予定なので行わず。
なお、UACは既定の設定で、インストールやアンインストールの際に1回ずつのみ通知されました。
とある底辺の字幕プレイ動画のうｐ主として、編集時用のコーデックとして使わせていただいております。
奇しくもWin7環境への移行を余儀なくされたので、インストールのついでに調べてみたです。
256:名無しさん＠編集中
10/01/28 17:11:37 cUDCXf4m
どうせ最終的にYV12で保存することになるんだからこまけぇことはいいじゃねえか
257:名無しさん＠編集中
10/01/28 17:33:24 EmlfWJrf
aviutlでエンコするのに
RGBで録画してUVダウンサンプリングフィルタ通してx264guiに渡すのと
YV12で録画してx264guiに渡すんじゃ
出来あがった動画に顕著な差が出るんだろうか？
決定的な差でもなければ下の方が録画時の負荷も低いし
HDD容量もあんまり食わないからそうしたいんだけど
258:名無しさん＠編集中
10/01/28 20:07:38 Y57l26L+
細部重視でシャープとか掛けるならRGBのまま処理した方が良いと思う
Aviutlのビデオフィルタはやっぱ綺麗だと思う・・たぶん
259:名無しさん＠編集中
10/01/28 20:39:42 hsgeh8rl
>>256
いや、それを再度ゲームフォルダに戻す予定
一応、プリレンダリングムービーだから
つまり、それらを可逆で録画後、いらんところカットして
再度、フォルダに戻す
だから、変な劣化は駄目なのです
無劣化として残したいのでorz
260:名無しさん＠編集中
10/01/28 20:42:50 RGDN9yOC
自力で解決する気がないならもう編集とか一切するな
ここはお前のためのサポートスレじゃない
261:名無しさん＠編集中
10/01/28 21:36:05 cIlqKp8k
>>259
>>253であってると思うよ。つまりやり直し。
念のためDxtory＋Lagarithで録画したファイルを読み込んだときに>>224をチェックして、
ちゃんとRGBで読み込まれてるか確認しといたほうがいいだろうね。
すでに>>233とか>>238で忠告されてるし情報も色々出てるんだから、
これを機会に色空間をしっかり理解したほうがいいと思うよ。
Lagarith使うならなおさら。
262:名無しさん＠編集中
10/01/28 22:05:41 5VSRrvw8
えーと…
ご愁傷様です (-人-)ﾅｰﾑ >>252
263:名無しさん＠編集中
10/01/28 22:30:08 ATbKQfML
細かいこといいから
劣化しないベストな方法教えろ
264:名無しさん＠編集中
10/01/28 22:37:24 cIlqKp8k
>>263
色空間を理解し、ツール等の使い方を完璧に把握する。
265:名無しさん＠編集中
10/01/28 23:32:33 hsgeh8rl
>>261
すまん、㌧クスです
Ut Videoなら大丈夫なのかね？
一部、Ut Videoで変換したやつがあって、それはAviutlで読み込んでファイル情報見たらRGBと記述してあった
カットした後も、再圧縮なしで変換したので多分問題ないかな？
Lagarithはやり直しです、頑張りますorz
266:名無しさん＠編集中
10/01/29 01:33:11 2rIRd2Wa
色空間って601とか709とかsRGBとかNTSCとかを言うんじゃないのん？
個人的にデータフォーマットとごっちゃにしてるのって良くないんじゃないかって
思ってたんだよね、YUVとかRGBは色フォーマットと言うべきなんじゃなかろうか
色空間wikiでもビデオフォーマットって言ってるし
まあMpeg2とかh264と誤解しそうなんで色フォーマットとかピクセルフォーマットと
言うのがいい気がする
267:名無しさん＠編集中
10/01/29 01:59:59 BmzV5IIl
National Television System Committeeがどうやったら色空間になるんだ？
RGB color spaceとかCMKY color spaceとか普通に言うだろ
まあ、color formatって言う人もいるだろうけど
268:名無しさん＠編集中
10/01/29 02:16:43 U/pAiuBJ
>>266
厳密には色空間てのはRGBとかYUVとかCMYKといった表色系全体を指す。
BT.601とかBT.709ってのはRGBとの相互変換をする際の行列（カラーマトリクス）を規定したもの（だけじゃないが）で
こいつは本来は色空間とは言わない。sRGBとかNTSCはカラープロファイルじゃないかな？
カラーフォーマットはとかUYVYとかYV12とかRGB32とかいうデータの並び方の違いをいう（この場合必然的に
色空間も限定されるけど）
おれもよくわかんねーんだわ
269:名無しさん＠編集中
10/01/29 04:01:20 0JbFeJXq
つまりUt Videoは気にすることなくエンコできるってことか
反対に、LagarithだとYUY2関連のチェック外さなきゃ駄目なのか
なんとめんどい
270:名無しさん＠編集中
10/01/29 21:13:49 ZkiI53/e
FRAPSはデフォルトでYUY2
3系からRGBも選択できるようになった
271:名無しさん＠編集中
10/01/29 22:20:35 0JbFeJXq
>>270
知ってるけど、たまにRGBにチェック入れても聞かない時あるな
RGBで録画して、チェック外して、再度チェック入れると聞かなくなる
272:名無しさん＠編集中
10/01/30 06:38:01 zRlrCG0U
>>268
なんか勉強になった、トン
273:名無しさん＠編集中
10/01/31 12:32:05 mPY1Iyai
>>269
Aviutlの場合、例えUt Videoが優先でも、デフォでYUY2出力なってなかったっけ
Ut Videoが出力しなくても、チェック外さなきゃ駄目じゃね
274:名無しさん＠編集中
10/01/31 18:12:29 /Rwcq8gP
チェックボックスがグレーアウトしていてYUY2出力が出来ない。
275:名無しさん＠編集中
10/01/31 18:33:28 c+Kqhz80
>>274
RGB限定フォーマットの読み込みはそうなる
AviutlはRGB<>YUY2変換しない
してるのはコーデックだから
コーデックに「RGBで保持してるけど出力はYUY2にもできる」機能・オプションがなければできない
276:名無しさん＠編集中
10/01/31 18:59:04 Vkej2WRq
>>275
>>274は>>273への回答であって、別に悩んでるわけじゃないと思うんだ・・・。
ついでに出力と入力がごっちゃになってないかｗ
あとUtVideoの中の人、入出力形式の情報ありがとうございます。
或るプログラマの一生 ≫ [UtVideo] 対応入出力フォーマット
URLﾘﾝｸ(umezawa.dyndns.info)
277:名無しさん＠編集中
10/02/08 08:21:22 i4qIo0tv
可逆で圧縮したファイルを
カットやら字幕とか付けて編集して、また可逆圧縮するってのは
論理的に劣化してないという考えでいいの？
278:名無しさん＠編集中
10/02/08 11:02:00 nReGv62u
>>277
>>200,201
279:名無しさん＠編集中
10/02/08 19:29:19 GxpWbI7d
話題にも上がらんlgcodecとzerocodecは圧縮率とか速度どうなん
公式見ると「インストールできません」レベルの厨だけしかコメント書いてないが
280:名無しさん＠編集中
10/02/08 20:15:52 ExxjyaCE
自分で試しもせず、このスレのログすら読まないやつが厨とか言っても失笑ものだとしか・・・
281:名無しさん＠編集中
10/02/08 20:16:26 nReGv62u
光るものがあれば話題にのぼるだろ
282:画質は不明。
10/02/11 16:52:05 ifQ9htre
いらっしゃいましぇい、デルでょう。
デル デジタルハイエンドシリーズ U2711 27インチ ワイドTFT液晶モニタ
2560 x 1440 WQHD の高解像度、6 ミリ秒の応答速度 (GTG、標準)
横電解スイッチングテクノロジー (IPS)、80,000:1 のダイナミックコントラスト比 (最大)
ｺﾐｺﾐ 65,375円。（安いかも。情報少なし）
URLﾘﾝｸ(configure.apj.dell.com)
参考スレッド：
DELL U2711 IPS・WQHD(2560x1440 16:9) 1台目
ｽﾚﾘﾝｸ(hard板)
283:名無しさん＠編集中
10/02/14 15:01:41 rW1Hly9a
Windowsムービーメーカーで無圧縮出力したファイル（yuv420p）を可逆圧縮したいのですが、
ffmpeg -vcodec libx264 -cqp 0 -coder 1 -g 30
で可逆圧縮になってるものでしょうか？
見た目では全然分からないのですが、１／６にもなるので本当かなあと・・・
284:名無しさん＠編集中
10/02/14 15:05:37 9Iq59OV5
>>283
x264の可逆よりも、-vcodec ffv1 とした方が良い。
285:名無しさん＠編集中
10/02/14 16:23:50 rW1Hly9a
>>284
レスありがとうございます。
一応、長期保存用なので、汎用的なものの方が良いかと思いまして。
10年位前にLCLでエンコードした動画の再生が今となっては不便で・・・
ffv1でも同程度圧縮されたので、今時はそれくらい圧縮されるのですね。
Huffyuvより数割減るくらいに思っていたので正直驚きました・・・
286:名無しさん＠編集中
10/02/14 16:38:17 rzJoiTDQ
>LCLでエンコードした動画の再生が今となっては不便
LCLはFFmpeg (libavcodec)が独自デコーダを持ってるから、他のコーデックよりは対応プレーヤ多いよ。
仕様も(REされたものだろうけど)公開されているし。
URLﾘﾝｸ(wiki.multimedia.cx)
287:名無しさん＠編集中
10/02/16 21:31:54 7qJIhCxL
>>286
libavcodecのZLIBはマルチスレッドモードやRGB24に対応していないようで・・・
そして、純正LCLは流石にx64では無理なみたいです。
先日来、色々調べたところ、
・Windows7標準ではH.264ロスレスは再生出来ない！
・ffmpegのYUV←→RGBと、AviSynthのYUV←→RGBの変換は異なり、AviSynthの方が高性能
・WMMで編集したら、無圧縮wmvを読み込んで無圧縮保存しても劣化する
・wmv(IYUV)をAviSynthで読み込むとRGB24に変換され劣化する
・wmv(IYUV)やH.264(YV12)を、huffyuv(RGB24)にエンコードしたら劣化する
・wmv(IYUV)やH.264(YV12)を、FFV1(YUY2)やH.264ロスレス(YV12)にエンコードする場合は劣化しない
H.264ロスレスがWindows7標準で再生出来なかったので・・・
ffmpeg -vcodec libx264 -qmin 1 -b 25000k -g 30 -keyint_min 1
-coder 1 -mbd 2 -me_method full -subq 7 -refs 4 -trellis 2
-flags2 mixed_refs -partitions parti4x4+partp8x8
で妥協してしまおうかなと迷い中。ロスレスに比べてサイズ3/4、SSIM0.999程度
288:名無しさん＠編集中
10/02/17 17:24:32 R2+8AroY
YV12->YUY2は劣化する。アプコンだが。
289:名無しさん＠編集中
10/02/17 21:54:23 LV1DseM3
>>288
ご指摘ありがとうございます。
FFV1は、実際はYV12でした。DirectShowSourceで見てしまってYUY2と勘違いしてしまいました。
しかし、YV12->YUY2は、単純に同じ値をコピーするだけではないのですね・・・
290:名無しさん＠編集中
10/02/17 22:02:51 XADv7UWK
結局、色差だけを縦に2倍の拡大をすると言うことだからね。
AviSynth 2.6なら、chromaresampleに自分の好きな補間を選ぶ事ができる。
URLﾘﾝｸ(avisynth.org)
291:名無しさん＠編集中
10/02/17 22:13:43 nGRhhz5c
>>289
＞FFV1は、実際はYV12でした。
FFV1って使ったことないけど、ffdshowのエンコーダー設定見てみたら
YV12、444P、422P、411P、410P、RGBとか色々な色空間に対応してるみたいだけど。
まあそのへんはわかってるのかもしれんけど。
＞しかし、YV12->YUY2は、単純に同じ値をコピーするだけではないのですね・・・
やり方は色々あるんだろうけど、Avisynthの場合は以下のサイトにあるように上下の色差も使って補間してるね。
URLﾘﾝｸ(avisynth.org)
292:名無しさん＠編集中
10/02/17 22:18:02 nGRhhz5c
うお、リロードしてなかった。
>>290に書いてあることは知らなかったよ・・・。>>290ありがとう。
293:名無しさん＠編集中
10/02/18 02:35:25 9db/yS1o
>>290-291
教えて下さってありがとうございます。
単純にffmpeg(r18607) -vcodec ffv1とすると、
YV12、YUY2、RGB、何れの入力でもYV12でエンコードするみたいです。
それをAVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換のようです。多分・・・
294:名無しさん＠編集中
10/02/18 04:26:03 mAfxKDB9
>>293
>AVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換
それはお前のffdshowのデコード設定次第ではないのか？
295:名無しさん＠編集中
10/02/18 05:55:52 2aTmhnRp
>>293
＞ YV12、YUY2、RGB、何れの入力でもYV12でエンコードするみたいです。
YUY2とRGBでエンコしたHuffyuvのAVIを作って
ffmpeg -i YUY2-Huffyuv.avi -vcodec ffv1 yuy2_ffv1.avi
ってやればyuv422pになったし、
ffmpeg -i RGB-Huffyuv.avi -vcodec ffv1 rgb_ffv1.avi
ってやればrgbaになってるけどなあ。
入力ソースにあわせたピクセルフォーマットになると思うけど。
>AVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換
AvisynthのAVISource()はpixel_formatを指定しなければYV12>YUY2>RGB32>RGB24の順で
デコードを試みるから、単にYV12でのデコードに成功したってだけでは。
DirectShowSource()の場合はフィルタの関係上YUY2でしかデコードできなかったとかそんな感じかと。
>>294
＞それはお前のffdshowのデコード設定次第ではないのか？
ffdshowのどこかでFFV1のデコードオプションの設定ってできるっけ？探してみたけど見当たらなかった。
296:名無しさん＠編集中
10/02/18 06:16:54 mAfxKDB9
>>295
URLﾘﾝｸ(img502.imageshack.us)
これのこと
297:名無しさん＠編集中
10/02/18 07:14:53 2aTmhnRp
>>296
あっ・・・！そうか、ありがとう。
なんか「FFV1単体の設定」っていう思い込みに縛られてしまっていたようだ。orz
298:名無しさん＠編集中
10/02/18 22:26:02 9db/yS1o
>>295
＞デコードを試みるから、単にYV12でのデコードに成功したってだけでは。
＞DirectShowSource()の場合はフィルタの関係上YUY2でしかデコードできなかったとかそんな感じかと。
ffdshowがYV12に変換してAviSynthに渡していたのですね・・・、間違えてばかりですみません。
299:名無しさん＠編集中
10/02/19 20:00:02 XV58ntT/
aviutlを可逆圧縮で読み込む時、みんな何プラグイン使ってる？
自分のはなぜかDirectShowになってしまって、ファイルの情報のビデオ圧縮が未圧縮になってしまうんだけど・・・
これで問題ないの？
300:名無しさん＠編集中
10/02/19 20:07:05 9oagF+cu
標準のAVI/AVI2入力で普通に読めるだろ
DirectshowFileReaderの入力優先度を一番下にするってのは常識
301:名無しさん＠編集中
10/02/19 20:17:40 XV58ntT/
>>300
DirectShowは一番下にしたけど、AVI File Readerになるんだが？
そうなると、ビデオ圧縮がMicrosoft Video 1になってしまう
もしかして、Ut Videoは可逆圧縮なのにAVI/AVI2では読み込めないのか？
302:名無しさん＠編集中
10/02/19 20:21:37 emyC7Klv
そりゃAVI File ReaderをAVI/AVI2の上に置いてるからだろ
303:名無しさん＠編集中
10/02/19 20:22:06 9oagF+cu
普通に読めるって言ってるだろうに…
AVI/AVI2を一番上にしろ
304:名無しさん＠編集中
10/02/19 21:07:05 C6zNoPr0
>>301
可逆圧縮は一切関係ない。お前がAviutlの使い方をわかってないだけ。
スレ違いだからうせろ。
305:名無しさん＠編集中
10/02/19 21:51:36 XV58ntT/
>>302-303
AVI/AVI2は一番上ですが？
って、いろいろ調べてみたら
RAD Toolで可逆圧縮すると、Ut Video関係なくなるんだな
ライブラリがないと、Aviutlは可逆を無圧縮と勘違いしてしまうみたいだ
URLﾘﾝｸ(www.dotup.org)
RAD Toolからaviに変換した動画は使用したライブラリにRAD Toolと書かれない
ビデオストリームはちゃんとULRGになってんだけどな・・・
PCゲーム内部の動画なんだけどね
306:名無しさん＠編集中
10/02/19 23:32:20 C6zNoPr0
>>305
何をどう調べたらそこまでめちゃくちゃな俺様理論が出来上がるのか興味があるわ
307:名無しさん＠編集中
10/02/20 02:17:49 +Sk9lgbZ
>>306
PCゲームの.bikファイルをRAD Toolを使って
可逆AVIに変換してみれば分かる
ビデオストリームはULRGでも、aviutlで読み込むとAVI/AVI2では読み込まれないから
RADToolで読み込んでいない、他の可逆ファイルはAVI/AVI2になってたよ
何が俺様理論だよ・・・まじめに答えてるのに
308:名無しさん＠編集中
10/02/20 04:20:20 QIBzS5Ln
かわいそうになってきたので調べてみた。
適当なAVIをRAD Video Toolsで別のコーデックのAVIに変換。
結果：どのコーデックで圧縮してもfccHandler部に書かれるFOURCCがMSVC（Microsoft Video 1）固定になる。
BITMAPINFOHEADERのbiCompressionのほうは、選択したコーデックのFOURCCになる。
結論：RAD Video ToolsのAVI変換機能がまともじゃない。
おかしなAVIだからAVI/AVI2 File Readerは「こんなふざけたAVI読めるかボケェ」とスルーして、
かろうじてAVI File Readerで読み込めてるって状況じゃないかね。
動画編集を始めたばかりでいきなり糞ツールにぶちあたってしまったがゆえの悲劇ってとこかな。
309:名無しさん＠編集中
10/02/20 04:23:08 0Yy+LBu3
FourCCが変なんだったら、バイナリエディタなりNic's FourCC Changerなりで
書き換えればいいんでないの？
310:名無しさん＠編集中
10/02/20 04:26:00 QIBzS5Ln
あ、ちなみに出力したAVIを真空波動研に読ませようとするとフリーズするっぽいので気をつけて。
311:名無しさん＠編集中
10/02/20 04:38:24 QIBzS5Ln
>>309
とりあえずバイナリエディタでfccHandler部を書き換えたらちゃんとAVI/AVI2 File Readerで
読めるようになったから、このツールを使わざるをえないなら当面はその対処がいいかもね。
他にも問題抱えてないか心配ではあるけど。
312:名無しさん＠編集中
10/02/20 05:43:01 7fAmbFUz
情報後出ししといてキレるとかゆとりもいいとこだな
313:名無しさん＠編集中
10/02/20 07:32:03 derdaAnj
bikを変換するならFFmpegに以下のパッチを当てて使うのが良いと思う。
URLﾘﾝｸ(lists.mplayerhq.hu)
まだレビュー中ではあるけど。
# dark shikari氏がレビューしているのにちょっと驚き。
314:名無しさん＠編集中
10/02/20 11:40:29 +Sk9lgbZ
>>311
ありがとう、おかげさまでAVI/AVI2で読み込めるようになった
ただ、これは色空間挟むと同じようにfccHandler部を書き換えると画質劣化は起きるの？
もしそうなら今後、RADTool使うのはためらうんだけども
>>313
RADToolって使用してなかったはずだけど、是非使わせていただきます
315:名無しさん＠編集中
10/02/20 12:18:57 0Yy+LBu3
>>314
>fccHandler部を書き換えると画質劣化は起きるの？
起きるかどうかはデコーダーの性能と設定次第