2012年3月DTV105: 映像可逆圧縮総合スレ Part3 (578)
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
【TM6200】HDMI VideoCapture【HDCAPPCIE・DM626】4 (288)
放送TSをBDAV化する方法 Part3 (564)
ガンマイク、結局どれがいいの? (681)
編集マンのつぶやき 【ED9】 (963)
SATELLA1・サテラ1改造版 17台目 (549)
【HDMI】BMD Intensity 17枚目【キャプチャー】 (387)
映像可逆圧縮総合スレ Part3
1 :09/07/10 映像可逆圧縮関連総合スレです Part2 http://pc11.2ch.net/test/read.cgi/avi/1205486331/ Part1 http://pc11.2ch.net/test/read.cgi/avi/1098022448/ 祖先スレ http://pc5.2ch.net/test/read.cgi/avi/1056587462/
2 :09/07/10 代表的なコーデック Huffyuv 2.1.1 (安定版) http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html Lagarith Lossless Video Codec http://lags.leetcode.net/codec.html Huffyuv_mt (マルチスレッド化)、Lagarith_1315dev_SSE2_719 (SSE2対応化ほか) http://www29.atwiki.jp/lossless/pages/11.html YUY2 Lossless Codec (YLC) http://ruriruri.zone.ne.jp/aviutl/ LCL (旧LRC) http://www.geocities.jp/sandk_project/LRC.htm MSU Lossless Video Codec http://www.compression.ru/video/ls-codec/index_en.html#Download CorePNG http://www.free-codecs.com/download/CorePNG.htm FastCodec http://videosoft.org/codecs/ Ut Video Codec Suite http://umezawa.dyndns.info/wordpress/?cat=28 AMV2MT/AMV3 http://amamaman.hp.infoseek.co.jp/
3 :09/07/10 これはポニーテールがどうのこうの乙
4 :09/07/10 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 姉妹スレ 音声可逆変換ソフト総合スレ http://pc12.2ch.net/test/read.cgi/software/1219683003/
6 :09/07/11 いちおつ
7 :09/07/12 いちおつ
8 :09/07/13 1乙 ところで、みんなは、どのコーデックを利用しているの?
9 :09/07/13 UtVideo だけど、AMV3を買ってみようかと思ってる。 AMV3早そうだし。
10 :09/07/13 俺1ペタあるから使わないよ
11 :09/07/14 >9 どっちが高速化教えてくれい。 UtVideoはインタレ使えないのがネックだな・・・。
12 :09/07/14 >>11 アマレココのページに計測データが載せられている。 自分で測るとしたら……どうすりゃいいんだ?
13 :09/07/14 Utおいてるとこにある速度計測器でも使ってみたら?
14 :09/07/15 http://xrowcc.blog.shinobi.jp/Entry/388/ 俺は試すのめんどい
15 :09/07/15 [UtVideo] バージョン 5.3.0 機能追加 ULY0: エンコード時に YUY2 で入力できるようにした。とりあえず作っただけなので、YUY2 入力時のエンコードは遅い。 ULY0: デコード時に YUY2 で出力できるようにした。とりあえず作っただけなので、YUY2 出力時のデコードは遅い。
16 :09/07/16 作者が報告してくれてるの? それとも誰かが瞬時に発見してるの?
17 :09/07/16 RSSでチェックしてるとか。>>14 は変更点も書いてないから試す気も起こらないな・・・
18 :09/07/16 [UtVideo] バージョン 5.3.1 バグ修正 ULY0: フレーム分割の方法が間違っていた。
19 :09/07/17 絶対宣伝誌に来ると思ってたが案の定宣伝に来たなw クズ
20 :09/07/17 >19 バカいってんじゃねーよ。 せっかく報告してくれてんだよ。おまえがどけ
21 :09/07/17 >>18 報告たすかる 重大なバグがあったのかな?
22 :09/07/17 自分でもアンテナ登録してるからなくても困らないけど報告はありがたいね。
23 :09/07/18 酷い自演
24 :09/07/20 自分でちょっと試したらエンコデコともにAMV3よりUtの方が早かったな。 Athlon X2, ULY0とAMV3可逆標準で。
25 :09/07/20 アマレコ使う場合はAMV3使わないとコマ落ち増える AMV3はアマレコキャプ専用
26 :09/08/08 やたらと最近(キャプチャ開始してから十分前後で)コマ落ちする。 UtvideoからHuffyuvMTに一回戻してみたけど、状況変わらず。 HDDの空き容量が影響しているのかと、CMカット編集済みの動画を消しても同じ。 くすのきの再生フレームレートが30フレーム近くからじりじり(22フレームくらいまで) 下がっていくので、HDD周りのデバイスドライバを調べなおしたら、 なんか認識されているデバイスドライバが足りてなかった。 いったん削除して、完全に電源を落として再起動して認識させ直したら、 nForceのRAIDドライバがプライマリとセカンダリも認識されなおしたので、再度キャプチャ中。 再生フレームレートは27フレーム前後で特に変化無し。 たぶん問題解決しました。
27 :09/08/08 あと、5.3.1まであげて、圧縮率優先→デコード速度優先もやりました。おかげで動画サイズが 2割くらい膨れ上がって、HuffyuvMTと変わらなくなってしまった。
28 :09/08/08 日記はチラ裏にどうぞ
29 :09/08/09 つうかコーデックと全然関係無い話じゃん
30 :09/08/09 [FFmpeg-devel] [PATCH][RFC] Lagarith Decoder. http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073903.html
31 :09/08/10 外国の厨が出したパッチ自体より、それにつけられたコメントの方が読むと面白い。
32 :09/08/10 正規のVFW Codecがあるのにわざわざffmpegに組み込む必要性ってなに?
33 :09/08/10 ffmpegやMPlayer/MEncoderでそのまま扱えるようになるだろ あそこらへんは現状ではffvhufかffv1しか可逆の選択肢がない menc2vfw使わないですむなら、それにこしたこともない
34 :09/08/10 >33 menc2vfwってなに? ググっても出てこない。コマンドラインからVFW codecでエンコ出来るのかな?
35 :09/08/11 >>34 ああ、ごめん、vfw2mencだった できることはその通り 本来win用のvfwコーデックをLinux上で使うためのもの そもそもVirtualDubやAviSynthがネイティブで動くwindowsではたいして意味はない
36 :09/08/19 インターレースの映像を、インターレースを保持したまま可逆圧縮できるコーデックは、 Huffyuvくらいなものなんでしょうか。 Ut Videoは、YUV420でのインターレースは非対応らしいですが、 YV12でのインターレースは、どうなんでしょう? Lagarithはググってみたら、海外の掲示板では、どうも対応してないようなことが書いてありましたが、 最新版の1.3.20でも非対応で合ってますか?
37 :09/08/19 基本的に同じフォーマットで圧縮・展開すればいいよ RGB←→YUY2 変換ロス発生 RGB,YUY2←→YV12 変換ロス、インタレ変換の影響 huffyuvのインターレース対応はmethod gradient,medianで1つ上のラインを参照するから 横幅を2倍とみなして偶数・奇数ライン同士を参照するようにして圧縮率を上げている
38 :09/08/19 補足 コーデックの圧縮前の内部フォーマットと異なるフォーマットで入出力すると変換ロスが発生するので 内部フォーマットと同じフォーマットで入出力すればいいよってこと
39 :09/08/19 AMV2MT/AMV3がYV12に対応していたと思う。
40 :09/08/19 >>36 YV12に対応している物なら、FFV1, Lagarith, UT Video等、何でも良い。
41 :09/08/19 ただ、AviUtl等を使って、YUY2->YV12をやると、縞が崩れてしまうから、 VirtualDubのFast recompressやavs2aviを使う必要は有る。
42 :09/08/19 インターレースYV12をリサンプリングせずにそのまま可逆圧縮するだけなら インターレースの対応可否は関係ないよ。
43 :09/08/20 フィルタかけるとつぶれるけどな。
44 :09/08/20 フィルタかけるのはリサンプリングに相当するぞ>>43
45 :09/08/31 UtVideo6ってバグ?
46 :09/09/01 Visual C++のランタイム絡みらしい。6.0.0のコメント欄に報告がある。
47 :09/09/07 [UtVideo] バージョン 6.0.0 共通: インターレース映像に対する特別な処理を追加した。 ※インストール関連のバグあり [UtVideo] バージョン 6.0.2 ダイナミックリンクからスタティックリンクに変更した。 ※インストール関連のバグ解消(と思う
48 :09/09/11 エンコード作業をオールx64化したいのですが 現状でx64ネイティブなマルチスレッドな可逆圧縮コーデックって何がありますか
49 :09/09/11 >>48 Lagarith
50 :09/09/11 動画エンコ的にはx64のメリットはほとんどないよね・・・
51 :09/09/11 そうでもない たとえば複数のエンコを同時進行する場合は、メモリ4GB超の恩恵はある この前同時に3本のavsを中間出力(フィルタの都合上、MTなし)したが、メモリ使用量5GBで楽勝でした そのほかにも32ビットに比べてインターフェース周りとかは強化されてるから、32ビットのアプリでも、 そのもののスピード自体は多少遅くなるが、結果的には変わらないか若干速くなったりすることもある。 言ってみれば車速自体は遅くなったけど、道が走りやすくなったんで、タイムは縮んだみたいなかんじ
52 :09/09/11 x264なら64bit版で32bitより1割以上早くなるよ
53 :09/09/11 32bitでもRAMDISKにスワップ置けばトータルメモリ量は増やせるけど、 1アプリ2GB(拡張して3GB)の制限有るから、 フルHDサイズとかでフレーム参照系のオプション増やしてるなら64bitの方が良いな
54 :09/09/11 >>48 早速ありがとうございます Lagarith Codec (v1.3.20) Lagarith_1315dev_SSE2.7z Lagarith_1315dev_SSE2_719.7z を試しました しかし、こいつ重たいですね ^^; Phenom9600ではドロップでまくりでD3キャプチャーできませんでした 改めてhuffyuv_mtの軽さを思い知りました もう少しあがいてみます
55 :09/09/11 x64は対応してるのは本家のだけだと思うけど。x64でキャプできるものもあるのかな。 他の64bitもの ttp://members.optusnet.com.au/squid_80/
56 :09/09/11 avisynthのフィルター類って32bitだとおもったけど avsを64bitのx264でそのままエンコってできるの?
57 :09/09/11 >>56 http://forum.doom9.org/showthread.php?p=1234822
58 :09/09/11 Thanks!
59 :09/09/12 >>55-56 書き方が足りませんでした キャプはx86で行います で、先ほどのLagarithはx86でのキャプチャー時の負荷です >>57 のツールではなくx64 avisynth の使用を前提で考えていたので x64側のネイティブなデコーダーも必要と考えました とりあえず、huffyuv-2.1.11のシングルスレッドでギリギリでキャプチャーできるようですので それでしばらくは対応したいと思います。 ご回答くださいました方々ありがとうございました
60 :09/09/12 CUDA使って圧縮するコーデックって出れくれないかな。
61 :09/09/17 完全に中間圧縮専用だな。 ところでUtも64bit対応目指すらしいな。 いつだかこのスレで騒いでたやつを思い出しちゃったよ。 彼の人にAMD64bit機を送りつけたらAMDの最適化もやってくれたりするんかな。
62 :09/09/17 win7発売と同時か。後はキャプチャーソフトと編集ソフトが対応増えるのを期待かな。
63 :09/09/22 Huffyuv_mt_712を導入する際はhuffyuvは一度アンストしたほうがいいんですか?
64 :09/09/22 別物だからそのままでいい
65 :09/09/22 >>63 のHuffyuv_mtならFourCCがHYMTに変更されてるから共存できる。 ちなみにLagarith1315のMT改造版はFourCCがオリジナルと同じなので共存できない。
66 :09/09/23 huffyuvのアンストの仕方わからない俺涙目。ぐぐる先生にもそれっぽいのないし
67 :09/09/23 >>66 これで上書きできれば、アンインストールできるかも。 ttp://breuzehn.hp.infoseek.co.jp/soft.html >huffyuv2.1.1codec >何故かアンインストール出来ない不具合を不必要だと思いつつも修正したもの
68 :09/09/23 そんな不具合があったのか・・・。 「アプリケーションの追加と削除」から削除できそうだけど、失敗するのか・・・?
69 :09/09/28 IgCodec v1.0.0 ttp://xrowcc.blog.shinobi.jp/Entry/434/ 使うメリットはないけど一応報告
70 :09/09/28 >>69 LZ系か。ならQuickLZ使うべきだったろうにjk そこの作者は情報に疎いな何時も
71 :09/09/28 >>70 QuickLZはGPLだからじゃない?
72 :09/09/29 >>69 試しに使ってみたけど、 ・・・うん、なんだ、UtVideoのままでいいや。
73 :09/09/29 ------------------------- IgCodecの大雑把なテスト ------------------------- ■ソースファイル: 秒速5センチメートルの公式ページ(ttp://5cm.yahoo.co.jp/teaser/index.html)で 配信されている予告編第1弾のダウンロード版(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 ■結果 ※IgCodecは内部形式がYUV4:2:2(UYVY)とのことなので、 YUY2形式の可逆圧縮コーデックを比較対象としました。 どのコーデックもYUY2圧縮を有効にしてあります。 ※UtVideo Codecは少し古いバージョンです。 コーデック: エンコード時間 ファイルサイズ IGC1、IGC2: 32秒 187,782[KB] IGC3、IGC4: 2分46秒 126,553[KB] UtVideo 5.2.3 ULY2(デコード速度優先): 21秒 111,176[KB] UtVideo 5.2.3 ULY2(圧縮率優先): 21秒 85,682[KB] Huffyuv v2.1.1 PredicMedian(best): 18秒 119,481[KB] う〜ん・・・、どれをとってもUtVideoやHuffyuvでいい感じですね・・・。
75 :09/09/29 ■その他 ※多分バグだと思うけど、うちの環境だとファイルを選択すると Explorerが落ちる。どうもサムネイル作成で落ちてるっぽい。 ただ、1秒くらいの動画をエンコした場合は問題なかったので、 何かしらの発生条件があるのかも。 ※上にも書いたが今のところ内部形式がYUV4:2:2(UYVY)なので、 RGBソースの場合はRGB→YUV変換による劣化が発生する。
76 :09/09/29 utもx64対応になったらvctestもx64対応になるかな。
77 :09/09/29 データを複数台のPCに移動しながら作業したいんだが、 ・圧縮率をなにより優先 ・RGB色で出力可能(YUVはダメ) ・速度も……悲惨じゃないよ って条件に合うCODECを調べてくれるな人いませんか? じゃなくても構いません
78 :09/09/29 >>77 FFV1 "ffmpeg -vcodec ffv1"とするか、ffdshowのVfWから使う。
79 :09/09/29 こことか参考に ttp://amalabo.blog35.fc2.com/blog-entry-44.html RGBだとどうだったかな・・・
80 :09/09/29 〜IgCodecのテスト続き〜 IgCodecの説明を見ると差分圧縮と書いてあるんで、 可逆圧縮にしては珍しくフレーム間圧縮をしてるのかなと思い、 1024x768のJPG静止画を拡張編集で24fps 240フレームの長さにして IgCodecでAVI出力してみました。 IGC1 36秒402 337,599[KB] IGC3 1分53秒370 284,277[KB] ULY2デコード優先 23秒255 230,510[KB] ULY2圧縮率優先 22秒170 202,502[KB] うーん・・・?
81 :09/09/29 >>78 FFV1のコード見た。 predictionに緑≒Yなことを使った速度優先的な変換にvariable-length code(標準)もしくはrange coder(-coderが1以上の時)かぁ。 にしても速度最適化の余地が多いコードだな。 http://forum.doom9.org/archive/index.php/t-90031.html ここみるとRGB24の圧縮率はFFV1(range coder)・MSU・ALPHARYSOFT・LAGARITHの中で、FFV1(range coder)が一番のようだ。 UtVideoとの比較キボン
82 :09/09/29 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 ふむ。UTはRGB特殊扱いが無いし、ハフマンだしでFFV1に圧縮率で勝る点は無い。 強いて言えばpredictionが二種あることだが、これがどう影響しているかは分からね。
84 :09/09/29 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 http://compression.ru/video/codec_comparison/pdf/msu_lossless_codecs_comparison_2007_eng.pdf 少し古いが、これはとても参考になる。 キャプチャー等で速度優先ならUT Video、保存に使うならFFV1が良いと私は思う。
86 :09/09/29 ご意見ありがとうございます。 色々考えた結果、 UT出力→7z圧縮で移動→出先で解凍 が一番効率がよさそうでした。 7zの繰り返しデータ圧縮効率は異常
87 :09/09/29 >>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 謎っていうか16bit処理(-0xffから0xff)してるだけか。 確かに8bitで処理するより圧縮率は高くなるな。
89 :09/09/29 RGBの色空間変換の最近のトレンドはYCoCgらしい。 http://wiki.multimedia.cx/index.php?title=YCoCg Co = R - B t = B + (Co >> 1) Cg = G - t Y = t + (Cg >> 1) YCbCrと比べてどの程度の効果あるのか気になる。
90 :09/09/29 H.264のmatrix_coefficientsが8になっていたら、YCgCo どの実装が、これのエンコード/デコードに対応しているのかは知らない。
91 :09/09/29 YCgCo-> YCoCg x264のヘルプを見ながら書いていたら間違えた。
92 :09/09/29 再度訂正 T-REC-H.264-200711-I!!PDF-E.pdfにもYCgCoとあるから、間違いではなかった。
93 :09/09/29 >>80 調査乙です。 Igの人のブログ見ると改良していくつもりでもなさそうな感じだし、 Utから乗り換えする必要ないっぽいかなぁ。 >>89 YCoCg…YCbCrとYPbPrの違いもよく分かってないのに他にもあるのか…。
94 :09/09/29 igCodecがVistaUltimate(x86)でインスコできないんだが解決策わかる人いる?
95 :09/09/29 ごめん。XP専用だったのね。公式読んでなかった ちょっと死んでくる
96 :09/09/29 YCoCgはRGBと無劣化に相互変換できるフォーマットでYUVと同じように 輝度信号と色差信号で記録される。H.264のHigh444 Profileの対応色空間として 利用できる。
97 :09/09/30 後発ならどこか一部でも利点のあるもの出さなきゃ
98 :09/09/30 商用利用可能
99 :09/09/30 別に商用利用はGPLのHuffyuvやFFV1やUtでも可能だろ ただ金払うやつがいないってだけで
100 :09/10/01 FFV1はLGPLでも使えるな。
101 :09/10/03 >>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ファイルをバイナリエディタで開き、最初のほうにある2箇所のFOURCCを、 実際には存在しない「PGRW」に書き変えてみたのですが、 それも何故かAVI Decompressorが呼び出され、デコードしようとしてました。 >>75 で書いた「サムネ表示で落ちる」という問題も、他では聞きませんし、作者さんの環境でも再現しないそうです。 IgCodecの問題ではなく、うちの環境がおかしいか、インストールに失敗しただけなのかもしれません。 考えてみればインストール直後は特に問題を感じてなかったし、途中で何か変になったのかなあ・・・。 当たり前ですがアンインストールすれば上記の現象は発生しなくなりましたが、 別の環境だとどうなのかなというのが気になりまして。
102 :09/10/03 ちなみにアンインストールする前にPCの再起動を試したのですが、それでもダメでした。
103 :09/10/03 >>101 ICDecompressQueryで拒否されれば別のフォーマットのデータで再生しようとはしないはず。 コーデックのチェックが甘いんじゃないの? 試しにUtVideoのソースいじってICDecompressQueryでICERR_OKを返すようにしたら mplayerが落ちるのを確認できたよ。元に戻すと落ちない。 ただ、設定によっては再現しない時があったけど。
104 :09/10/03 >>103 うおぅ、なんか実装レベルな詳細ktkr。 ググってもよくわからんかったのですが、「これをデコードできる?」って問い合わせに対して、 IGC1がなんでもかんでも「できるよー」って答えてるということでしょうか。 GraphEditで見てみましたが、とにかくビシバシAVI Decompressorが呼び出されてました。 とりあえず再インストールしても発生したので、環境依存の可能性も含めて報告だけしてみます。 あと別スレで出てましたが、上下反転したり、RGB圧縮してYUY2展開すると崩壊が起きるというバグがあるようです。 うちでも再現しました。
105 :09/10/03 >>104 AVIDecompressorはレンダラからのDirectShowの動的フォーマット変更の要求を受けるよ。 旧レンダラだとYUVのデコードが出来ない古いビデオカードのために、最初はRGBで表示して 途中からYUY2に変えたりする。 BI_BITFIELDなんかも渡されるし、負のHeightも意味がわからなければとりあえず拒否すればいいよ。
106 :09/10/04 >>105 すみません、書き方がおかしかったかも。 「Aviutlで、IGC1のYUY2圧縮をオフ(つまりRGB圧縮)にしてエンコしたAVIを、 IGC1のYUY2展開をオンにして読み込むと映像の崩壊が起きることがある」 です。 申し訳ないですが私自身は開発者でもなんでもないので詳しいことはよくわからないです・・・(;´Д⊂) ちなみに負のHeightというのは、まるもさんの2004年6月3日の日記にある件でしょうか。 http://www.marumo.ne.jp/db2004_6.htm 以前、 http://pc12.2ch.net/test/read.cgi/software/1251184231/301-318 で、 「VP62でエンコードしたAVIが読み込み方法によっては上下反転する」 という質問をしたことがあるのですが、もしかしてこのVP62の件も 負のHeightというのに由来しているんでしょうか。
107 :09/10/04 >VP62でエンコードしたAVIが これはyuvの負数Heightの問題よりvp6とvp6fの問題な可能性が高そうな。
108 :09/10/04 >>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 >>106 AVI File Reader(Video For Windows)ではRGBで読み込まれて AVI/AVI2 File ReaderではYUY2で読み込まれてない? その場合はAviutilのコーデックの設定でYUY2の展開のチェックを外してみて。
110 :09/10/05 >>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 FFVideoSource("VP62.avi") とすれば良い。
112 :09/10/05 >>110 ええと。vp6fというのはflashに使われるvp6コーデックの"ffmpegでの"呼び名ね(fourccではない)。flashに使われるvp6は普通のvp6と上下が反対という仕様になってる。 普通のvp6のfourccはVP60, VP61, VP62。 この辺の処理をちゃんとしてなかったり、間違ってたり、強引にやってたりすると上下反対のができる。
113 :09/10/05 って勘違いかも? ffmpegのriff.cにあるからfourccだねぇ>VP6F on2のデコーダは対応してなかった記憶があるが、その辺の経緯忘れた。
114 :09/10/05 VP6の話になったらもうスレ違いだよなあ
115 :09/10/05 最強可逆コーデック MSU Screen Capture Lossless Codec http://replaymugen.seesaa.net/article/93730113.html わかりやすかった
116 :09/10/05 >>110 普通のユーザーは覚えなくても全く問題ないよ。 入力のFourCCについては、ff_vfwが有効になっているフォーマットを全て登録しなくても 再生可能な仕組みでもあるので、チェックが必要。 コーデックに負の高さが渡されるのは、通常はレンダラが用意したDirectXの サーフェイスであることを示す目印で、RGBでもYUVでも「トップダウン」なので、 コーデックが入力フォーマットの幅と高さを使って処理しているとRGBが反転してしまい、 また、上下反転の意味と捉えるとYUVが反転してしまうというわけ。 VP6がどうだったのかは知らないけど、登場した頃の主な編集ソフトがYUV対応 していなかったりすると、YUVの向きに混乱があっても特に問題ならなかったんだと思う。。 ってことで、Aviutilのコーデック設定でVP6のYUY2圧縮を外してエンコードしたらどうなるの? 反転しなければフォーマットの問題ではなく、on2のコーデック自体の仕様で、VP6Fはon2の 仕様に合わせたものってことでは?
117 :09/10/07 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 いや、VP6FはflipされたVP6だよ。 flvコンテナではvp6だけが何故かflipされてる。 それでflvからaviへの無変換詰め替えのときに困るってんで、'VP6F'というfourccが生まれた。 ffmpegが対応する前の話。
119 :09/10/07 >>118 ffmpegが作ったんじゃないなら、VP6Fってのはどこが決めたFOURCCなんだろ?
120 :09/10/09 IgCodecの圧縮どんなもんか試してみたらサムネ作成らしきタイミングでExplorerが落ちるんでググってやってきました >>101 によると作者環境でも再現せず他の報告もないそうなので諦めて帰ります XPSP3/C2Q9300@400x6.0/RAM3G+RAMDisk3G 編集・圧縮に使ったソフト:VirtualDubMod 1.5.10.2
121 :09/10/19 あまラボで64bitアプリから32bitコーデックを扱えるようにするプロキシコーデックを公開予定になってる。 ほかの32bitコーデックも64bitアプリで使えるらしい。aviutl出力プラグインのmm_srvみたいなものなのかな。 他のコーデックで使うメリットはあんまりないのかなーと思うけどどんな感じだろうね。
122 :09/10/19 http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2009-October/025021.html >4-6% faster huffyuv decoding if using left or plane mode and yuv
123 :09/10/19 64bitで動くエンコードソフトって、VirtualDubのx64版以外だと何があるだろう?
124 :09/10/19 x264 64bit版 32bit版より1割以上速くなるよ
125 :09/10/19 avidemuxも64bitで動くよ。但しwindows向けの64bitビルドはまだ無いようだけど。
126 :09/10/19 肝腎のAviSynthの64bit化が進まないとどうにもねぇ 2.6で64bitバージョンも正式リリース&32bitは開発終了とかやってもらわんと
127 :09/10/19 可逆じゃなくてスマヌ >>121 有り難う、昔matroxのftpで拾ったDVC-PRO50が使い続けらるなら嬉しい話だ 今のマシンパワーなら可逆圧縮で良いんだけど、昔の取り溜めして放置している素材なんかが・・・ MainConceptだと\80kとかするんよね(他のcodecも入ってだけど)
128 :09/10/19 ffmpeg系のプログラムは対応してるはず>DVC-PRO50 ってことでx64版のffdshowじゃ駄目なん?
129 :09/10/20 鬱ビデオCLIで出ないかなぁ
130 :09/10/20 >>126 32bitのavisynthで64bitのx264使う方法はあるよ。
131 :09/10/20 >>130 avs2yuvもモルダーさんのツールも知ってるよ 俺が言いたいのはAviSynthそのものを64bitにしないと、たいした高速化は望めそうもないんじゃないかってこと x264がいくら速くなってても、synthが足を引っ張ってるのが現状でしょ
132 :09/10/20 >>131 何か勘違いしているようだけどavisynthを64bit化することの利点は速度ではなく使用可能なメモリーサイズが増えることにある 速度は高度な最適化が進まんとたいして速くならんのでフィルター類が64bit化されても速度はたぶん今と変わらないよ
133 :09/10/20 ttp://pc11.2ch.net/test/read.cgi/avi/1254106514/87 Help Me!
134 :09/10/20 >>128 をぉ、重ね重ね有り難う 7のアップグレード頼んであるんで届いたら試してみます
135 :09/10/21 >>133 HuffyuvSはいいのか?と思ってググったけど、 http://www.megaupload.com/?d=F388AL8S は俺の環境では画像が乱れる。 http://wiki.nicomas.net/index.php? コーデック#te866ea1 MTモードでエンコードしたデータは、オリジナルのHuffyuvではデコードできないので注意。 http://freesoft.tvbok.com/movie_encode/about_codec/huffyuvs.html huffyuvsは色信号のスケールを変換しない huffyuvsとhuffyuvの違いを解説しているサイトを探してみた所、なんとCCE販売元NOVACのCCEのFAQで解説されていました。 CINEMA CRAFT ENCODER BasicのFAQ A.輝度レベルの設定は、入力がRGBの時のみ有効に機能します。 入力がYUY2の時は、変換せずにそのまま使用しています(スケール変換はしていません)。 もともとYUY2はCCE-Basicが受け付けることができる唯一のネイティブフォーマットです。入力としてRGBを受け取った場合、それは内部的に YUY2に変換されます。そのときの変換方式が2種類あり、その方式は輝度レベルのところで選択可能です。もしネイティブのYUY2がスケール 変換されてしまうのであれば、0-255で変換したYUY2の信号もスケール変換されてしまうはずです(16-235で変換したものは二重に変換されることになってしまいます)。 スケール変換をしているのは huffyuv 自身になります。スケール変換をしたくないのであれば、 HuffyuvS をご使用ください。 FAQなんぞ読まなくても普通に使用するには何にも問題なかったのですが、読んでみるものですね。。。。 huffyuvsは、RGB−YUY2間で行われる無駄な輝度変換を省略する事が出来るようです。 つまりは、動画編集ソフト等で動画を作成する時にキチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されて今い ますよ。という事らしいです。 TVキャプを行う場合でも、元々がTV信号ですのでhuffyuvsの方が向いているでしょう。 だとさ。
136 :09/10/21 別にTVキャプなら通常RGBなんて介在しませんからhuffyuvでなんら問題はない
137 :09/10/21 >>136 TMPGEncはRGBだったと思う...
138 :09/10/21 ていうか、>>133 のツッコミどころは >huffyuvsとhuffyuvとマルチスレッドのhuffyuvを右クリックでインストールしたんだが。 のとこだよね。 マルチスレッド版はFOURCCが違うから共存できるとして、 FOURCCが同じHuffyuvsとHuffyuvを同時インストールするとどういう挙動になるんだろう。 しかも両方ともアンインストールがうまくいかないバグがあるようだし。
139 :09/10/21 ごめんFOURCCが同じとか大嘘だった。いや〜ん、こっぱずかすぃ。。。・゚・(ノ∀`)・゚・。 Huffyuv HFYU HuffyuvS SHYU Huffyuv_mt HYMT 自分でもなんでかわからないけど物凄い変な思い込みがあったようだ・・・・orz ・・・・・・あれ?じゃあなんでデコードのミスマッチだの画面が乱れるだの騒いでるんだ???
140 :09/10/21 FourCCがSHYU(HuffyuvS)なのは確認したけど、やっぱ画が乱れる。 >>139 は正常に再生できてるの?
141 :09/10/21 >>140 うちはHuffyuvSは入れてないんだ。 すまんけど、ちょっと今はコーデックまわりをいじりたくないので検証はできそうにない。
142 :09/10/21 >>141 なんか細かい横線が気になったので、 Field Thresholdを288から576に変えたら正常に再生できたw http://dtv.sakura.ne.jp/contents4/001.html >フィールド閾値というのは、映像のフィールド数(縦のサイズ)が >この数字を超えるとインターレースとして扱うというものです。 >バージョンによっては設定項目がないものもあります。もっとも、 >圧縮方法が多少変わるだけで、あまり大きな影響はありません。 >むしろ、圧縮時と展開時で違っているとダメな場合があるようなので >デフォルトのままにしておきましょう。 フィールド敷居値のヘルプ(英語版)↓ Video with more than <threshold> lines will be processed interlaced by Huffyuv. The default value (used in older versions) is 288. Warning: Decompressing a interlaced video with a higher current threshold (so that huffyuv will not use field processing) will fail! The setting in stored in the ini-file, not in the video!
143 :09/10/21 追伸 ところで、ググってたらこんな書き込み見つけた。 識者さん、教えてください。↓ 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 ・UtVideo Codec 7.0.0 (x64版の追加) http://umezawa.dyndns.info/wordpress/?p=1305 ・窓の杜 - 【NEWS】64bitアプリケーションで32bit用の動画コーデックを利用可能に「Proxy Codec64」 http://www.forest.impress.co.jp/docs/news/20091022_323662.html
145 :09/10/23 俺にとっての問題は64bitOSを使っても用いてるキャプチャソフトも編集ソフトも32bit版しかないということだ
146 :09/10/23 Linuxだとほぼ全てのアプリケーションにamd64版があるようだけど、Windowsで64bit版が少ないのって何で?
147 :09/10/23 作るコスト>得られる利益 だから。
148 :09/10/24 UtVideo Codecはファイルは規定の位置にインストールされてるけどvctest・Veedub64では選択できなかった。 Lagarithはx86のほうが早くてProxy Codec64かましたx86が若干x64よりも早かった・・・
149 :09/10/28 >>135 色空間スレでまるもさんが実験したけど 伸張圧縮しないHyffyuvsはRGB<>YUV変換誤差がでかいよ RGB化したときに切り捨てられる15以下235以上を保持することがメリットってだけ 元はAviutlの伸張圧縮に問題がある次期にそれように作られたもの ノバックの書き方がおかしいんだが ”キチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう” んじゃなくて ”伸張圧縮しない環境で輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう” >>137 それは2.5PLUS時代まで ExpressシリーズはYUY2だよ
150 :09/10/30 huffyuvsを64bitのOSにインストするにはどこを書き換えたらいいか 誰か分かる人いますか?huffyuvのインスト方法を参考にやっているのですが、 どうも上手くいきません。
151 :09/10/30 べつにhuffyuvでいいじゃん ccespパッチあたってれば問題もないんだし
152 :09/11/02 Avidemuxの64ビット版ってどこにあるの?
153 :09/11/03 doom9。 でも正直使い物にならない。
154 :09/11/03 >153 ごめん。間違えた。
155 :09/11/04 誘導されました 元の画質からほぼ無劣化で出力できるコーディックないでしょうか? Huffyuv211を使ってたのですが最近これで出力すると再生する時に変になります。 220にバージョンアップすると出力99%のとこでVS12が強制終了してしまいます。 どうすれば良いでしょう?何か高画質のままほぼ無劣化で出力できるコーディック教えて下さい
156 :09/11/04 UtVideoでしょ。はやいし。
157 :09/11/04 >>155 バカタレ おれがここに誘導したのは質問しろってことじゃねーよ 読めってことだよ なぜなら>>2 に答えがあるからだ
158 :09/11/04 >>157 なるほど では>2の中だとどれが一番オススメでしょう?
159 :09/11/05 すでに2回UtVideo薦められといて、さらにそれを聞くのか ところで7.0.1が来てるな
160 :09/11/05 UtVideoをインストールすると4つ選べるようになります どれが一番良いんですか?
161 :09/11/05 さあねえ、あれは状況に応じて使い分けるものだから、どれがいいかなんて考えたこともないな
162 :09/11/05 >>160 ULY2が一番軽い。
163 :09/11/05 >>162 お前そういう教え方はイジメだろ・・・w >>160 色空間がわからないならULRGでも使っとけ。
164 :09/11/05 単純に軽いってんならULY0のほうが軽いだろ 色差の情報量はULY2の半分しかないんだから
165 :09/11/06 >>160 YUVフォーマット及び YUVとRGBの変換 http://vision.kuee.kyoto-u.ac.jp/~hiroaki/firewire/yuv.html カラーフォーマットのナゾ http://www.nnet.ne.jp/~hi6/lab/pixel/ これらのページの熟読推奨
166 :09/11/06 なんだかんだ言っても優しいやつらだな (;_;
167 :09/11/06 >>165 >>160 じゃないけど、こういうの待ってた!! でも読んだけど、いろんなデータの取り方があるのは解るけど、 どういうときどれ使えばいいのかは結局わからん・・・ そもそも、YUV422 が 16bit/pixel で、それが RGB24 (24bit/pixel でしょ?) と可逆変換できるのが意味わからん・・・ ましてや YUV420 の出番がいつなのか、まったくもってわからん・・・
168 :09/11/06 ttp://www41.atwiki.jp/nicomasmaking/?cmd=word&word=ULY2&type=normal&page=%E3%82%B3%E3%83%BC%E3%83%87%E3%83%83%E3%82%AF >ULY2の方は(中略)入力をRGBで与えても、 >内部で強制的にYUV422に変換されるため >完全な可逆圧縮となるわけではありません。 だそうだから、ソースを問わないのは RGB の ULRG。故に >色空間がわからないならULRGでも使っとけ。 ってことか、な?
169 :09/11/07 UtVideoに非可逆モードが付くのはいつなんだろうか? 再エンコするので画質そこそこ容量小さめ転送量も少なくHDDに優しい 非可逆モードが欲しい。転送量は10MB/sくらいで。
170 :09/11/07 再エンコするから可逆なんだろ?なに言ってるの?
171 :09/11/07 AMVでも使ってろ
172 :09/11/07 非可逆ならくさるほどあるだろーに。
173 :09/11/08 DV Type2は可逆圧縮できますか? もしできるとしたら、おおよそ何割くらい小さくできますか?
174 :09/11/08 >>173 それ質問になってない
175 :09/11/09 >>167-168 ・入力か最終出力が、MPEG-2とかMP4(H.264)とかFLVとかなら、YUV420系を使っておくほうがいい (インターレース動画の場合はYUV422系がいいかも) ・編集等でアルファチャンネルが必要な段階ではRGBA一択 雑に書くとこんな感じかと。
176 :09/11/09 >>175 補足ありがと。2つめは当然だね。 1つめの理由は自分で調べるとして、ガイドラインとしては十分ですわ。ありがとー。
177 :09/11/09 >>173 DV Type2は可逆圧縮ですか? という質問なら答えられる人がいると思う。 > おおよそ何割くらい小さくできますか? 実際にやってみろよ。
178 :09/11/15 質問かえますね。 DV Type2をバックアップしたいんですけど、容量を考慮してできるだけ小さいファイルサイズ にしたいです。 このスレでいう可逆圧縮とはちょっとニュアンスが違うのかもしれませんけど、例えば7-zipや cab等でも可逆圧縮できますが、データの性質上ほとんど小さくなりません。 圧縮した状態で再生できるかどうかは問いません。存在するかどうかわかりませんが、もし DV Type2のデータを可逆圧縮でそれなりに小さくするものをご存じでしたらお教えください。
179 :09/11/15 とりあえず世界最強はKGBらしいが http://www.dryout.info/product/kgbarchiver/ これで縮むかどうかは知らん
180 :09/11/15 DVつーとYUV4:1:1だよなあ。4:1:1に対応したコーデックなんてあんのか? そういう意味での1次劣化をよしとするならx264のqp=0ならかなり縮むんじゃなかろうか。
181 :09/12/12 >>179 推奨システム CPU: Intel Core™ または AMD Athlon™ 64 と互換性のあるCPU RAM: 1GB どんだけメモリ喰うんだw
182 :10/01/01 止まってしまったな。
183 :10/01/19 RGBで圧縮したAvi動画がなぜか再生できない。 MedioInfoで確認したところ、情報すら記載されてなかった。 環境はWindows 7 64bitでデコード速度を優先しているんだけど、原因は何だと思われます?
184 :10/01/19 >>183 自己解決した サイズが2GB上回ってたわ でも、AVI2.0だと思ってんだが
185 :10/01/19 >>183 >RGBで圧縮したAvi動画がなぜか再生できない。 UtVideoのULRGのことだと推測するが、コーデック名くらいしっかり書けよ。 >MedioInfoで確認したところ、情報すら記載されてなかった。 何の情報だよ。何が言いたいのかさっぱりわからんわ。 >環境はWindows 7 64bitでデコード速度を優先しているんだけど、原因は何だと思われます? とりあえずいったんアンインストールして最新版を入れなおしてみれば?
186 :10/01/19 ぐお、更新してなかった・・・。 >>184 思ってるとかじゃなくちゃんと調べなよ。
187 :10/01/19 >>186 乙かれー
188 :10/01/19 >>185 スマン コーデックはUtVideoです。Lagarithも同じ現象だった Mediainfoで記載してなかったって言うのは、ようはコーデックが何に使われてるだとか、 ビットレートの情報が書かれてなかった 最新版には入れなおしても変わりなかった ただ、AVIを2G以内に収めれば再生もできたし、Mediainfoで情報も記載されてあった AVI2.0では2G以上でも再生されると思ってたんだが、 エンコードツール・コーデック自体AVI2.0には対応してなかったみたい
189 :10/01/19 >>188 >AVI2.0では2G以上でも再生されると思ってたんだが、 >エンコードツール・コーデック自体AVI2.0には対応してなかったみたい コーデックは無関係。エンコードツールがAVI 1.0しか吐き出せなかっただけだな。 どんなツール使ってるのか知らんけど、プラグインとかでAVI 2.0に対応してる可能性もあるとは思うが・・・。 あと、こういう場合は質問時にエンコードツールの名前も書いとくと回答がもらいやすいかもね。
190 :10/01/22 すみません、可逆圧縮コーデックに限った話ではないのですが、1つ質問させて下さい。 質問: コーデックが対応している入出力形式を調べるツールのようなものは、何かありますでしょうか? 例えばUtVideoの場合、readmeなどから推測すると、 ttp://goldenhige.cocolog-nifty.com/blog/2010/01/utvideo-039d.html にあるように、ULY0だったら入出力ともに「RGB24、RGB32、YUY2、YV12」に対応しているようなのですが、 色々なコーデックについて、このような対応形式を簡単に調べる方法はあるのでしょうか? 一応思いついた方法としては、 ・Aviutlの「コーデックの設定」でYUY2圧縮のチェックボックスが有効になっていればYUY2入力に対応? ・AvisynthでAVIFileSource("ULY0.avi",pixel_type="YUY2")といった感じでpixel_typeで色空間を指定して読み込み、 エラーが発生しなければ、その色空間での出力に対応? といったところなのですが、調べられる項目が限定されていますし、そもそもこれが正しいのかすら自信がなく・・・。 よろしくお願いいたします。
191 :10/01/22 readmeとかヘルプとか作者のHPとか見るのが良いんじゃないな。
192 :10/01/22 >>191 う、それは確かにそうなのですが、何か他にツール的なアプローチは無いものかな〜と思いまして。
193 :10/01/22 >>192 AviSynthで読み込み info() で表示 後はお好きなように・・・
194 :10/01/22 >>193 ありがとうございます。Info()は結果的にどの色空間で読み込まれたのかは表示されますが、 今回はコーデックの対応形式を知りたかったので、>>190 に書いた方法の2番目で、 AvsPのプレビューでエラーの発生有無をチェックしていました。 追記ですが、スレを見直して>>41 さんの書き込みからavs2aviというのを初めて知り、試してみました。 avsで適当なソースを読み込んで ConvertToRGB24()、ConvertToRGB32()、ConvertToYUY2()、ConvertToYV12() のいずれかを行なってから avs2avi test.avs -s codec_param.txt -e を実行すると、その色空間での入力に対応したコーデックがリストアップされて表示されるのですね。 RGB24、RGB32、YUY2、YV12については、このavs2aviを用いた方法と、>>190 の2番目の方法とで 入出力の対応がチェックできると思えばよいでしょうか? 仮にこの方法でよいとしても、RGBAやUYVYなどについてはどうやって判定すればよいのでしょう・・・? 他にも良い方法をご存知の方がいらっしゃいましたらよろしくお願いいたします。
195 :10/01/22 UtVideoの作者さんから調査への協力依頼だそうな http://umezawa.dyndns.info/wordpress/?p=1468&cpage=1#comment-21142
196 :10/01/23 可逆圧縮でもビットレートってあるけど、映像にはまったく影響がないと思っていいの? 何か、レートが100Mbps以上だけどUtVideoのデコード優先と圧縮優先じゃ、30Mbps以上も差があるんだけど
197 :10/01/23 >>196 可逆圧縮なんだから、色空間さえ間違えずに扱えば映像にはまったく影響はない。 一般的には デコード優先→データ圧縮率は低め=圧縮後のデータ量は多め→圧縮後のビットレートは高め 圧縮率優先→データ圧縮率は高め=圧縮後のデータ量は少なめ→圧縮後のビットレートは低め と考えればいいだけだと思う。 ソースやコーデックへの渡し方によっては結果が違ってくるだろうけど。
198 :10/01/23 あー、なるほど てことはソースが4k2kとかだったらまた違うのかな? 4k2kとかそれ以上の解像度って高画質であれば100Mbps以上必要でしょ?
199 :10/01/23 そりゃソースによるじゃん。極端な話黒1色の静止画なら1kbpsでだって無劣化で圧縮できるし(アルゴリズムによるけど)
200 :10/01/23 可逆圧縮ってまた元に戻せるから可逆って言うんだよね だったら、可逆圧縮したAVIファイルをカットなんかした後に再度エンコするとき、 可逆圧縮にしたらどうなるの? 可逆→可逆
201 :10/01/23 色空間変換を挟まなければ劣化はない
202 :10/01/23 >>195 Windows7の120日評価版にソースからビルドした7.0.1のx64msiはインストール失敗したので ICInstallSelfの部分を以前のバージョンに戻してOrcaでmsiにパッチを当てたらインストール 出来ました。
203 :10/01/23 ちょうど資料作りをしてたので、 「可逆圧縮コーデックといえども、途中で色空間の変換が入ると可逆じゃなくなるよ」 っていう件についてのサンプル画像をアップしてみます。 ■サンプル画像1 「赤・緑・青・黒のピクセルを敷き詰めたRGB画像」を、 ULY2(YUV422)やULY0(YUV420)で圧縮した場合の劣化パターン ttp://www1.axfc.net/uploader/Img/so/70968.bmp 左がYUV422、右がYUV420。上下の違いは「コーデックの設定」の「YUY2圧縮する」がON(上)かOFF(下)か。(※1) ピクセルを拡大してみると、色の変わりっぷりがよくわかります。(拡大しなくてもわかるけど) RGBソースなら、ちゃんとULRGなどを使わないと可逆にはなりません。 ※1・・・YUY2圧縮がONだとAviutlがRGB→YC48→YUY2(YUV422)変換したYUV値(この時点で既に劣化)を、 ULY2やULY0が受け取って使う。ULY0の場合はここから更にYUV420化(ここでも劣化)する。 YUY2圧縮がOFFだとAviutlがRGB→YC48→RGB変換したRGB値(この時点では劣化なし)を ULY2やULY0が受け取り、それぞれの内部でYUV化(ここで劣化)する。 ■サンプル画像2 文字を描いたRGB画像をULY0(YUV420)や、x264(YV12=YUV420)でエンコードした場合の劣化 ttp://www1.axfc.net/uploader/Img/so/70976.bmp ニコニコ動画とかで赤い文字がつぶれて見えたりするのも、ほとんどの場合これが原因。 黒背景に赤文字もかなり劣化しますが、灰色背景はもっとすごいことに。 →以前ニコニコ動画に上げてテストした例 ttp://www.nicovideo.jp/watch/sm7534784 上のサンプルではRGB→YUVの劣化にしか触れてませんが、他にもBT.601とかBT.709とかが絡んでくると色々面倒ですね。
204 :10/01/25 >>203 ええっ つまり、BT709で出力したら可逆じゃなくなるのか?! Aviutlの設定じゃ入力はAutoだけど、出力はBT709になってるぞ お、おれの可逆動画フォルダすべてが水の泡・・・
205 :10/01/25 Aviutlの色空間変換ってデータそのものを変換してる? 動画ファイルの扱いだけが変わってるんじゃないかと思うんだけど どうなんだろ? 実際Aviutl上で入出力切り替えても見た目ぜんぜん変わらんし・・
206 :10/01/25 >>205 RGB出力なら可逆でなくなる YUVなら変わらない
207 :10/01/25 >>204 ソースとか設定によるよ。 >>205 データそのものを変換してるよ >>206 その言い方は乱暴というか答えになってなくね? Aviutlの場合の、色空間変換に関係してくる部分を入力側から順にリストアップしてみます。 もちろんデータによっては関係ない部分もあるので大雑把な順番ですが。 変なとこあったらつっこんでください。 1.ソースの内部データ形式(RGB、YUV422(BT.601、BT.709)、YUV420(BT.601、BT.709)) 2.入力プラグインの選択(入力プラグイン優先度の設定) 3.入力プラグイン自体の設定(例えばまるもさんのMPEG2読み込みには色空間設定がある) 4.入力プラグインからAviutlへの受け渡し形式(RGB、YUY2、YC48) 5.コーデック自体の内部形式(RGB、YUV422(BT.601、BT.709)、YUV420(BT.601、BT.709)) 6.「コーデックの設定」の「YUY2展開する」のON/OFF 7.コーデック自体の出力形式(YUY2出力できるかどうか) 8.Aviutlの入力色空間の設定(BT.601、BT.709、auto) 9.入力時のAviutl内部のRGB→YV48、YUY2→YC48変換 10.Aviutlの出力色空間の設定(BT.601、BT.709、auto) 11.「コーデックの設定」の「YUY2圧縮する」のON/OFF 12.コーデック自体の入力形式(YUY2入力できるかどうか) 13.コーデック自体の内部保持形式(RGB、YUV422(BT.601、BT.709)、YUV420(BT.601、BT.709)) 可逆圧縮しても読み込み方を間違えると元データから変化してしまうので、 このあたりをトータルで見ないと、可逆を可逆として扱えないということになる。
208 :10/01/25 あ、あとはYUVのTVスケールとフルスケールというのもあるっけ・・・。 このあたりは主に上の3あたりに含まれるということで・・・。 >>135-149 あたりを見ると、5−7、11−13あたりも絡んでくるのかな。
209 :10/01/25 >>207 色変換プラグインというのもあるよ。 プラグインを公開している人は少ないが 8〜10の部分をプラグインでいじれる。
210 :10/01/25 >>207 >>205 の質問の趣旨から外れてるだろ そりゃフィルター入れりゃ可逆でなくなるのは当たり前 あくまでaviutlでカット編集した時だけの話だろ
211 :10/01/25 つまり、aviutlで可逆ファイルを読み込む場合、 色変換の設定の入力・出力は自動で、AVI出力する時、再圧縮なしの可逆のままで出せば問題なし? 可逆読み込み→可逆出力(再圧縮なし)でおk? 今まで未圧縮に再圧縮してたけど・・・
212 :10/01/25 未圧縮ってのはRGB24だから、もろに色が変わるだろ
213 :10/01/25 入力/出力の設定はBT.601にすれば従来通り。自動は縦解像度720以上でBT.709と認識するから 709 > 601変換が入る。つーてもカットだけならAviutlは12bit処理なのでマトリクス変換での劣化はない。 まあ再圧縮なしで出力するのが一番いいと思う。未圧縮はRGBだから一番ダメだろ
214 :10/01/25 でも601>709と入出力を切り替えたりしてもAviutl上は 何も変わらんってのはなんでなんだろ?今の見え方を 該当色空間に当てはめてるって事?内部の色の数値は 変わってますよ、って事なんかね?
215 :10/01/25 可逆でエンコした動画を再度可逆なら問題なしなの? 今、フォルダから未圧縮すべて消してやり直ししてる こりゃ、1日以上かかるなorz
216 :10/01/25 >>213 いや、可逆したファイルはみんな解像度は1280x720だから、出力をBT709にしてもよかったのか これは安心した
217 :10/01/25 ちょっと待て、再圧縮なしにすると 可逆設定でRGBに設定したから、出力したファイルがRGBになってるぞ これ正常? だったら、未圧縮でもRGB何だから変わらないんじゃ?
218 :10/01/25 >>214 出力は変えてもプレビューには関係ないよ。入力はYUVで読んでればちゃんと変わるが RGBで読んでたら当たり前だが入力の設定は関係ないぞ。 >>215-216 可逆と非圧縮であることとYUVとRGBであることは全く関係がないぞ。 なんかごっちゃになってないか?言ってることが良く解らん
219 :10/01/25 >>218 すまん、えーっと俺の方が勘違いしてるのか? 可逆圧縮コーデックのLagarithやUt VideoでRGB(もしくはRGBA)の設定できると思うが、 これと未圧縮で出力されたRGBと何が違うんだ? Lagarithでエンコした動画を再圧縮なしにして出力すると、 未圧縮ファイル(RGB)になるんだが、この未圧縮は正常?
220 :10/01/25 お前、DirectShowで読み込んでないか?
221 :10/01/25 まず用語を整理しないと混乱する気がする。 再圧縮無し・・・ソースの映像を、形式を変換せずにそのまま出力すること。 出力時にコーデック選択欄の右にある「再圧縮なし」にチェックを入れるとこれになる。 Lagarithで圧縮されたソースを再圧縮なしで出力したらコーデックはLagarithのままだし ULY2で圧縮されたソースを再圧縮なしで出力したらコーデックはULY2のまま。 ※ただし「再圧縮なし」にするとフィルタ等は効かない。 ※キーフレーム以外の部分でカット編集した場合は「再圧縮なし」にすることはできず、 必ずなんらかのコーデックで再圧縮(未圧縮も含む)を行なう必要がある。 未圧縮・・・未圧縮RGB、つまりなんの圧縮もされていないRGB映像のこと。 出力時にコーデックの選択で「未圧縮」を選ぶとこれになる。
222 :10/01/25 Lagarithで圧縮した可逆ファイルを読み込んだ後、 再圧縮なしにチェック入れるとコーデックには未圧縮になるんだが・・・ バグなのか?
223 :10/01/25 >>220 directshow file readerは入ってるが、もしかしてこれのせい?
224 :10/01/25 >>222-223 とりあえずLagarithで圧縮したファイルを読み込んだら、メニューの「その他→ファイルの情報」を見て、 ・ビデオ圧縮 ・ファイル制御 ・ビデオ展開形式 がどうなってるか確認するんだ。
225 :10/01/25 ビデオ圧縮:未圧縮 ファイル制御:DirectShow File Reader ビデオ展開形式:RGB になってたよorz Mediainfoで見ると、ちゃんとLagarithになってるんだけど どうすればいい・・・?
226 :10/01/25 AVI/AVI2 File Readerの優先度を一番上にすればいい
227 :10/01/25 >>226 マジ、dクス 何でDirectShowなんか糞プラグイン入れたんだろ・・・ 可逆しなおすため1日費やすかorz
228 :10/01/25 ds_input.auiは使い方さえ間違えなければとても優秀なプラグイン 糞呼ばわりするようなオマエが糞なんだよ
229 :10/01/25 >>228 そうだな、確かにそうかも知れん とりあえずは感謝する でも、マジでやり直すの面倒だorz
230 :10/01/26 Lagarithと一口に言っても、「RGB24, RGB32, RGBA, YUY2, YV12」と、内部形式が色々あったりするよね。 圧縮方法と展開方法の組み合わせを間違えるとそこでも色空間変換が・・・。
231 :10/01/26 >>230 いや、それは気をつけてるつもり Lagarithの設定はRGBがデフォで、それをAviutlに読み込ませて カットした後、再圧縮なしにすればおkじゃない? Ut Videoも同じ感じで・・・
232 :10/01/26 やっぱりRGBがサイキョーかぁ〜〜
233 :10/01/26 ID:QG59TvId = ID:L31xexlo だと思うけど、そもそも何をやりたいのかよくわからない。 BT.709で出力してると言ってるから、なんらかのYUY2ソースを LagarithのYUY2で圧縮してるのかと思ったらLagarithはRGBで使おうとしてるようだし。 >>231 では「Lagarithで圧縮したファイルを読み込んでカットして再圧縮無しで出力」と言ってるから、 別ソフトでRGBで編集した映像データをLagarithのRGBで圧縮して、それをAviutlに読み込んで 不要部分をカットして再圧縮無しで出力したいということなんだろうか? でもそれならずっとRGBで扱うわけだから、Aviutlの入出力の色空間は関係ないはずだし、 そもそもそんなカット編集だけをAviutlでやる意味がよくわからないというか・・・。 作業する前にそのへんをちゃんと整理して理解しないと、作業が無駄になる気がする。
234 :10/01/26 すまん、はっきり言うと ゲーム動画をlagatithで録画し、aviutlに読み込ませカットした後、 色空間とか触れず、そのままの状態で元に戻したかっだけ つまりカットと編集をしたかったんだ BT709で出力はやめて自動にしたけども、ゲーム解像度が1280x720だから大丈夫な気がした 7個目の作業中だよ、今orz
235 :10/01/26 そもそもキャプチャの色空間ってYUVじゃないの?
236 :10/01/26 キャプチャボードとか使ってないんじゃない? 自画面キャプチャならRGBのが普通なんじゃないの? わざわざYUVに変える意味は無いと思うし
237 :10/01/26 つうかLagarithって圧縮率は高いけどエンコード速度は遅いから リアルタイムでキャプチャと同時に圧縮していく場合に使うのには向かないんじゃないっけ。 RGBでキャプチャするにしてもHuffyuvとかULRG使ったほうが早いみたいだし。 録画中は無圧縮で中間出力して録画終了時にまとめて圧縮するタイプのソフトなら Lagarithでもいいかもしれないけど。 あまラボ ビデオコーデック・ベンチマーク2009 http://amalabo.blog35.fc2.com/blog-entry-44.html
238 :10/01/26 ていうか誰も触れてないけどAviutlならコーデックの設定でYUY2で圧縮のチェック外さないと RGBで出力できないでしょ。試せばわかるけどYUY2のチェックはいってるとLagarithでRGB指定しても YUY2でやったときと同一になるから。
239 :10/01/26 >236 ああそっか。PSとかXBOXの取り込みだと思い込んでた。
240 :10/01/26 >>238 今色々試してるけど、Lagarithってそのへんわかりにくいね。 UtVideoならRGBとYUV422とYUV420が明確に分かれてるからわかりやすいけど・・・。
241 :10/01/26 じゃあRGB動画でも[YUY2で展開する]のチェック外さないと X264GUIに渡す時 RGB>YUY2が RGB>YC48>YUY2になって劣化するの?
242 :10/01/26 >>241 うまく答えづらいけど、まず 「無圧縮のRGB動画」 「ULRGで圧縮したRGB動画」 「LagarithにRGBで入力してRGBモードで圧縮したRGB動画」(※1) ※1・・・>>238 にあるようにYUY2入力してRGBモードで圧縮したものは駄目 をAviutlのAVI/AVI2 File Readerで読み込むなら、そもそもYUY2展開ができないので、 コーデックの設定のとこの「YUY2で展開する」のチェックの有無に関わらず、RGBで読み込まれる。 つまり、読み込みの時点では、 RGBデータ→RGBでAviutlへ受け渡し→Aviutl内部で「RGB→YC48変換」 となる。ここまでは劣化なし。 x264GUIに出力する際の流れは以下のようになる。 1.Aviutl内部でYC48→YUY2変換(RGBからのYC48→YUY2変換になるのでこの時点で色空間変換による劣化) 2.1のYUY2データをx264GUI出力プラグインへ渡す 3.x264GUIプラグイン内部で、YUY2→YV12変換(ここでも色空間変換による劣化) 4.3のYV12データをエンコーダであるx264へ渡し、エンコードする。 (ここはそもそも可逆じゃないので非可逆圧縮による劣化が発生) RGBデータを読み込んでYUV420(x264とか)で出力した場合の劣化具合は>>203 のサンプルを参照。
243 :10/01/26 >>242 ありがとう なるほど理解できました
244 :10/01/27 x264で一生懸命設定煮詰めたエンコで赤いスカートの縁が ギザギザになって悩んだっけ・・・ 上とは関係ないけど色々ググッたらutのRGB&RGBAの展開の設定を YUY2で展開するにしてた・・これって展開時に劣化してたって事だよね?
245 :10/01/27 いやYUY2で展開する設定だったらRGBのものはRGBで展開される。 逆に出力時はRGBで圧縮(YUY2で圧縮のチェック外す)じゃないとRGBで出力されない。
246 :10/01/27 >>245 YUY2で展開する、なのにしてないって事?RGBで展開してるなら問題ないって事だから良いのか・・・ YUY2で展開する、のチェックはずしたらまずいのかな? 出力はグレーアウトしてるからたぶん強制的にRGBになる物なんだと思う
247 :10/01/27 ああごめんutをutlって読んでたわ。動画読み込んだ際にビデオ展開形式がRGBになってたら大丈夫でしょう、多分。 utはテストしてないから気になるならハッシュでも比較してみてください・・・
248 :10/01/27 >>247 とん、随分Aviutl使ってたけどファイルの情報って知らなかった・・・
249 :10/01/27 UtVideoのULRGとULRAは、YUY2での出力(デコード)はできないようになってるから 「YUY2で展開する」にチェックを入れても、 「YUY2で出力して渡すのは無理だよー」 ということでRGBで読み込まれる。 「YUY2で圧縮する」のチェックがグレーアウトしてるのは、 YUY2での入力ができないようになっているから。 UtVideoの各コーデックが対応している入出力形式については 公式のreadmeとか>>190 のリンク先とかを参照かな。 なんにせよ、読み込んだら「その他→ファイルの情報」を見て、 どのプラグインでどの形式で読み込んだのかをしっかり確認したほうが良いですな。
250 :10/01/28 ふう、やっと変換作業終わった 1日以上費やしてしまった これで問題何ひとつないよね キャプチャボートは使ってない。 DxtoryでLagarithに設定して録画した動画だから 元がLagarithだから、それを無劣化で色空間とか触れずにカットだけするつもりだった ・・・ってコーデックの設定のLagatirh見たら YUY2で展開する、YUY2で圧縮する、圧縮の設定を保持する全部にチェック入ってるじゃないか! 誰か助けてorz
251 :10/01/28 もう一度始めから変換するしかない ガンガレ!
252 :10/01/28 >>251 おぃ・・orz それ言うなw マジなのか? 失敗したのか? やり直しなのか?
253 :10/01/28 >>252 最近の流の中で勉強した限りでは君がやりたいことをやるためには 少なくとも「YUY2で圧縮する」のチェックを外す必要があると理解した 俺の理解が間違っていたらやり直す必要ないかも 知識のある方のレスを待つましょう (-人-)
254 :10/01/28 別にYUYだから見れたもんじゃないとかそういう事は無いだろう でもやっぱRGBがサイキョーだな 422とか420とか、端折ってる訳だし
255 :10/01/28 http://umezawa.dyndns.info/wordpress/?p=1468 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回ずつのみ通知されました。 とある底辺の字幕プレイ動画のうp主として、編集時用のコーデックとして使わせていただいております。 奇しくもWin7環境への移行を余儀なくされたので、インストールのついでに調べてみたです。
256 :10/01/28 どうせ最終的にYV12で保存することになるんだからこまけぇことはいいじゃねえか
257 :10/01/28 aviutlでエンコするのに RGBで録画してUVダウンサンプリングフィルタ通してx264guiに渡すのと YV12で録画してx264guiに渡すんじゃ 出来あがった動画に顕著な差が出るんだろうか? 決定的な差でもなければ下の方が録画時の負荷も低いし HDD容量もあんまり食わないからそうしたいんだけど
258 :10/01/28 細部重視でシャープとか掛けるならRGBのまま処理した方が良いと思う Aviutlのビデオフィルタはやっぱ綺麗だと思う・・たぶん
259 :10/01/28 >>256 いや、それを再度ゲームフォルダに戻す予定 一応、プリレンダリングムービーだから つまり、それらを可逆で録画後、いらんところカットして 再度、フォルダに戻す だから、変な劣化は駄目なのです 無劣化として残したいのでorz
260 :10/01/28 自力で解決する気がないならもう編集とか一切するな ここはお前のためのサポートスレじゃない
261 :10/01/28 >>259 >>253 であってると思うよ。つまりやり直し。 念のためDxtory+Lagarithで録画したファイルを読み込んだときに>>224 をチェックして、 ちゃんとRGBで読み込まれてるか確認しといたほうがいいだろうね。 すでに>>233 とか>>238 で忠告されてるし情報も色々出てるんだから、 これを機会に色空間をしっかり理解したほうがいいと思うよ。 Lagarith使うならなおさら。
262 :10/01/28 えーと… ご愁傷様です (-人-)ナーム >>252
263 :10/01/28 細かいこといいから 劣化しないベストな方法教えろ
264 :10/01/28 >>263 色空間を理解し、ツール等の使い方を完璧に把握する。
265 :10/01/28 >>261 すまん、dクスです Ut Videoなら大丈夫なのかね? 一部、Ut Videoで変換したやつがあって、それはAviutlで読み込んでファイル情報見たらRGBと記述してあった カットした後も、再圧縮なしで変換したので多分問題ないかな? Lagarithはやり直しです、頑張りますorz
266 :10/01/29 色空間って601とか709とかsRGBとかNTSCとかを言うんじゃないのん? 個人的にデータフォーマットとごっちゃにしてるのって良くないんじゃないかって 思ってたんだよね、YUVとかRGBは色フォーマットと言うべきなんじゃなかろうか 色空間wikiでもビデオフォーマットって言ってるし まあMpeg2とかh264と誤解しそうなんで色フォーマットとかピクセルフォーマットと 言うのがいい気がする
267 :10/01/29 National Television System Committeeがどうやったら色空間になるんだ? RGB color spaceとかCMKY color spaceとか普通に言うだろ まあ、color formatって言う人もいるだろうけど
268 :10/01/29 >>266 厳密には色空間てのはRGBとかYUVとかCMYKといった表色系全体を指す。 BT.601とかBT.709ってのはRGBとの相互変換をする際の行列(カラーマトリクス)を規定したもの(だけじゃないが)で こいつは本来は色空間とは言わない。sRGBとかNTSCはカラープロファイルじゃないかな? カラーフォーマットはとかUYVYとかYV12とかRGB32とかいうデータの並び方の違いをいう(この場合必然的に 色空間も限定されるけど) おれもよくわかんねーんだわ
269 :10/01/29 つまりUt Videoは気にすることなくエンコできるってことか 反対に、LagarithだとYUY2関連のチェック外さなきゃ駄目なのか なんとめんどい
270 :10/01/29 FRAPSはデフォルトでYUY2 3系からRGBも選択できるようになった
271 :10/01/29 >>270 知ってるけど、たまにRGBにチェック入れても聞かない時あるな RGBで録画して、チェック外して、再度チェック入れると聞かなくなる
272 :10/01/30 >>268 なんか勉強になった、トン
273 :10/01/31 >>269 Aviutlの場合、例えUt Videoが優先でも、デフォでYUY2出力なってなかったっけ Ut Videoが出力しなくても、チェック外さなきゃ駄目じゃね
274 :10/01/31 チェックボックスがグレーアウトしていてYUY2出力が出来ない。
275 :10/01/31 >>274 RGB限定フォーマットの読み込みはそうなる AviutlはRGB<>YUY2変換しない してるのはコーデックだから コーデックに「RGBで保持してるけど出力はYUY2にもできる」機能・オプションがなければできない
276 :10/01/31 >>275 >>274 は>>273 への回答であって、別に悩んでるわけじゃないと思うんだ・・・。 ついでに出力と入力がごっちゃになってないかw あとUtVideoの中の人、入出力形式の情報ありがとうございます。 或るプログラマの一生 ≫ [UtVideo] 対応入出力フォーマット http://umezawa.dyndns.info/wordpress/?p=1482
277 :10/02/08 可逆で圧縮したファイルを カットやら字幕とか付けて編集して、また可逆圧縮するってのは 論理的に劣化してないという考えでいいの?
278 :10/02/08 >>277 >>200 ,201
279 :10/02/08 話題にも上がらんlgcodecとzerocodecは圧縮率とか速度どうなん 公式見ると「インストールできません」レベルの厨だけしかコメント書いてないが
280 :10/02/08 自分で試しもせず、このスレのログすら読まないやつが厨とか言っても失笑ものだとしか・・・
281 :10/02/08 光るものがあれば話題にのぼるだろ
282 :10/02/11 いらっしゃいましぇい、デルでょう。 デル デジタルハイエンドシリーズ U2711 27インチ ワイドTFT液晶モニタ 2560 x 1440 WQHD の高解像度、6 ミリ秒の応答速度 (GTG、標準) 横電解スイッOテクノロジー (IPS)、80,000:1 のダイナミックコントラスト比 (最大) コミコミ 65,375円。(安いかも。情報少なし) ttp://configure.apj.dell.com/dellstore/config.aspx?c=jp&cs=jpbsd1&l=ja&oc=5159OU2711FAX&s=bsd 参考スレッド: DELL U2711 IPS・WQHD(2560x1440 16:9) 1台目 http://pc11.2ch.net/test/read.cgi/hard/1264999994/
283 :10/02/14 Windowsムービーメーカーで無圧縮出力したファイル(yuv420p)を可逆圧縮したいのですが、 ffmpeg -vcodec libx264 -cqp 0 -coder 1 -g 30 で可逆圧縮になってるものでしょうか? 見た目では全然分からないのですが、1/6にもなるので本当かなあと・・・
284 :10/02/14 >>283 x264の可逆よりも、-vcodec ffv1 とした方が良い。
285 :10/02/14 >>284 レスありがとうございます。 一応、長期保存用なので、汎用的なものの方が良いかと思いまして。 10年位前にLCLでエンコードした動画の再生が今となっては不便で・・・ ffv1でも同程度圧縮されたので、今時はそれくらい圧縮されるのですね。 Huffyuvより数割減るくらいに思っていたので正直驚きました・・・
286 :10/02/14 >LCLでエンコードした動画の再生が今となっては不便 LCLはFFmpeg (libavcodec)が独自デコーダを持ってるから、他のコーデックよりは対応プレーヤ多いよ。 仕様も(REされたものだろうけど)公開されているし。 http://wiki.multimedia.cx/index.php?title=Lossless_Codec_Libraries
287 :10/02/16 >>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 YV12->YUY2は劣化する。アプコンだが。
289 :10/02/17 >>288 ご指摘ありがとうございます。 FFV1は、実際はYV12でした。DirectShowSourceで見てしまってYUY2と勘違いしてしまいました。 しかし、YV12->YUY2は、単純に同じ値をコピーするだけではないのですね・・・
290 :10/02/17 結局、色差だけを縦に2倍の拡大をすると言うことだからね。 AviSynth 2.6なら、chromaresampleに自分の好きな補間を選ぶ事ができる。 http://avisynth.org/mediawiki/Convert
291 :10/02/17 >>289 >FFV1は、実際はYV12でした。 FFV1って使ったことないけど、ffdshowのエンコーダー設定見てみたら YV12、444P、422P、411P、410P、RGBとか色々な色空間に対応してるみたいだけど。 まあそのへんはわかってるのかもしれんけど。 >しかし、YV12->YUY2は、単純に同じ値をコピーするだけではないのですね・・・ やり方は色々あるんだろうけど、Avisynthの場合は以下のサイトにあるように上下の色差も使って補間してるね。 ttp://avisynth.org/mediawiki/Sampling#YV12_progressive_conversion_-.3E_YUY2
292 :10/02/17 うお、リロードしてなかった。 >>290 に書いてあることは知らなかったよ・・・。>>290 ありがとう。
293 :10/02/18 >>290-291 教えて下さってありがとうございます。 単純にffmpeg(r18607) -vcodec ffv1とすると、 YV12、YUY2、RGB、何れの入力でもYV12でエンコードするみたいです。 それをAVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換のようです。多分・・・
294 :10/02/18 >>293 >AVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換 それはお前のffdshowのデコード設定次第ではないのか?
295 :10/02/18 >>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 >>295 http://img502.imageshack.us/img502/4433/ffdshow.jpg これのこと
297 :10/02/18 >>296 あっ・・・!そうか、ありがとう。 なんか「FFV1単体の設定」っていう思い込みに縛られてしまっていたようだ。orz
298 :10/02/18 >>295 >デコードを試みるから、単にYV12でのデコードに成功したってだけでは。 >DirectShowSource()の場合はフィルタの関係上YUY2でしかデコードできなかったとかそんな感じかと。 ffdshowがYV12に変換してAviSynthに渡していたのですね・・・、間違えてばかりですみません。
299 :10/02/19 aviutlを可逆圧縮で読み込む時、みんな何プラグイン使ってる? 自分のはなぜかDirectShowになってしまって、ファイルの情報のビデオ圧縮が未圧縮になってしまうんだけど・・・ これで問題ないの?
300 :10/02/19 標準のAVI/AVI2入力で普通に読めるだろ DirectshowFileReaderの入力優先度を一番下にするってのは常識
301 :10/02/19 >>300 DirectShowは一番下にしたけど、AVI File Readerになるんだが? そうなると、ビデオ圧縮がMicrosoft Video 1になってしまう もしかして、Ut Videoは可逆圧縮なのにAVI/AVI2では読み込めないのか?
302 :10/02/19 そりゃAVI File ReaderをAVI/AVI2の上に置いてるからだろ
303 :10/02/19 普通に読めるって言ってるだろうに… AVI/AVI2を一番上にしろ
304 :10/02/19 >>301 可逆圧縮は一切関係ない。お前がAviutlの使い方をわかってないだけ。 スレ違いだからうせろ。
305 :10/02/19 >>302-303 AVI/AVI2は一番上ですが? って、いろいろ調べてみたら RAD Toolで可逆圧縮すると、Ut Video関係なくなるんだな ライブラリがないと、Aviutlは可逆を無圧縮と勘違いしてしまうみたいだ ttp://www.dotup.org/uploda/www.dotup.org668610.jpg RAD Toolからaviに変換した動画は使用したライブラリにRAD Toolと書かれない ビデオストリームはちゃんとULRGになってんだけどな・・・ PCゲーム内部の動画なんだけどね
306 :10/02/19 >>305 何をどう調べたらそこまでめちゃくちゃな俺様理論が出来上がるのか興味があるわ
307 :10/02/20 >>306 PCゲームの.bikファイルをRAD Toolを使って 可逆AVIに変換してみれば分かる ビデオストリームはULRGでも、aviutlで読み込むとAVI/AVI2では読み込まれないから RADToolで読み込んでいない、他の可逆ファイルはAVI/AVI2になってたよ 何が俺様理論だよ・・・まじめに答えてるのに
308 :10/02/20 かわいそうになってきたので調べてみた。 適当な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 FourCCが変なんだったら、バイナリエディタなりNic's FourCC Changerなりで 書き換えればいいんでないの?
310 :10/02/20 あ、ちなみに出力したAVIを真空波動研に読ませようとするとフリーズするっぽいので気をつけて。
311 :10/02/20 >>309 とりあえずバイナリエディタでfccHandler部を書き換えたらちゃんとAVI/AVI2 File Readerで 読めるようになったから、このツールを使わざるをえないなら当面はその対処がいいかもね。 他にも問題抱えてないか心配ではあるけど。
312 :10/02/20 情報後出ししといてキレるとかゆとりもいいとこだな
313 :10/02/20 bikを変換するならFFmpegに以下のパッチを当てて使うのが良いと思う。 http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083512.html まだレビュー中ではあるけど。 # dark shikari氏がレビューしているのにちょっと驚き。
314 :10/02/20 >>311 ありがとう、おかげさまでAVI/AVI2で読み込めるようになった ただ、これは色空間挟むと同じようにfccHandler部を書き換えると画質劣化は起きるの? もしそうなら今後、RADTool使うのはためらうんだけども >>313 RADToolって使用してなかったはずだけど、是非使わせていただきます
315 :10/02/20 >>314 >fccHandler部を書き換えると画質劣化は起きるの? 起きるかどうかはデコーダーの性能と設定次第
316 :10/02/22 >>313 のパッチが本線に入った。ってことで新しいFFmpeg使えばbikを直接変換できる。 http://multimedia.cx/eggs/bink-video-in-ffmpeg/ それと、Ut VideoがFFmpegにポートされるかも。FFmpegのGoogle SoCタスクとして。
317 :10/02/22 FFmpegがUT Videoに対応すれば、Windows以外の環境でもhuffyuvは使われなくなるだろうな。
318 :10/02/27 vista64でUTVIDEO7.0.2なんだけど after effectsの出力ダイアログだとx86しか出てこないんだけど これは32bitアプリだとx64は使えないって事でいいんですか? 公式のチェックツールでは両方大丈夫でした
319 :10/02/27 >>318 そう。例えば、64bit版のVirtualDubだと、64bit版のUTが使える。 http://virtualdub.sourceforge.net/
320 :10/02/27 >>319 なるほどありがとうございました
321 :10/02/28 > いつもどおり可逆圧縮スレを眺めていたら、 > 「Ut Video が FFmpeg に移植されるかも」という書き込みが。えっ、マジ? ワwwwwロwwwwwwタwwwwwwwwww とは言え実現するかはまだわからんのね
322 :10/02/28 フレーム分割数って何? ググってもよくわからないんだけど、誰かkwsk教えて
323 :10/02/28 "フレーム分割数"の検索結果 50 件中 1 - 50 件目 したがってそれを使った人にどういうつもりで定義してるか訊くべし
324 :10/02/28 あほ相手してたら、実が持たんぞ マニュケ
325 :10/03/04 デル デジタルハイエンドシリーズ U2410 1920x1200 24インチワイド TFT 液晶モニタ/IPS パネル 構成例価格 36,900円 コミコミ 38,475円 3月2日からこの値段に。まだ下がるかも? ttp://configure.apj.dell.com/dellstore/config.aspx?c=jp&cs=jpbsd1&fb=1&l=ja&oc=5113OU2410EM&s=bsd
326 :10/03/06 >>325 そんなゴミ誰が買うのかねぇ http://kakaku.com/prdsearch/prdcompare.asp?PrdKey=K0000033135.00850812704.00851112657.00852512596.K0000049736
327 :10/03/06 >>326 スレ違いだが液晶パネルの種類とか色々調べてみるといいよ。あまりこだわらないなら安いので十分。
328 :10/03/06 >>326 TNで26インチ以上とかゴミすぎ…
329 :10/03/06 24IPSでその価格ってところがイイネ。 IPSもピンキリなんだろうけどTNよりゃ万倍マシだろ。
330 :10/03/08 >>326 > そんなゴミ誰が買うのかねぇ
331 :10/03/09 可逆圧縮にこだわる人が韓国製TNパネルのクソ液晶って・・・
332 :10/03/14 (スレ違いだが) 「TN,PVA、IPSは、液晶そのものの方式」 「TFT、TFDは、電気の方式」 ってあったけど、>>325 も>>326 もTNじゃないの?
333 :10/03/14 >>325 はIPS リンク先に書いてあるでしょ
334 :10/03/15 TFDなんて久しぶりに聞いた
335 :10/04/13 Doom9(ttp://www.doom9.org/index.html?/software2.htm)で公開されている huffyuv_ccesp-patch_025 .zip について調べていたのですが、よくわからない点があるので詳しい方おられましたら教えていただけないでしょうか。 長文失礼いたします。 ググったり過去ログ読んで調べたところ、このCCESPパッチ版というのは、 以下のようなものらしいということまではわかりました。 (どこまで正しいのかはよくわからないので間違ってたり不足があれば指摘してください) 1.バージョンの古いCCE(Cinema Craft Encoder)では、huffyuvとYUY2の取り扱いに食い違いがあったため 全てのフレームにおいて正常な画像が得られなかった。 それを回避するためにオリジナルhuffyuvでは[Always suggest RGB for output]を有効にする必要があった。 これだとパフォーマンスのロスになるので、オリジナルのHuffyuvに改造を入れた。
336 :10/04/13 2.オリジナルのHuffyuvでは映像の縦解像度が288以上ならインタレースとして処理していた。 これはPALソース向けの数値として固定値として処理しており、変更はできなかった。 NTSCソースなら240が適切だし、プログレッシブソースを扱う場合は、 この値を縦解像度以上にしておけば予測効率が上がり圧縮率の向上を見込むことができる。 そのため、設定に「Field Threshold(フィールド閾値)」を追加し、自由に設定できるようにした。 (CCESPパッチ0.2.4まではこれをiniファイルに保存していたため、 違う閾値設定でエンコードしたファイルをデコードする場合はわざわざコーデック設定まで 変えないと正しくデコードできず、映像が崩れることがあり好ましくなかった。 >>133->>143 のHuffyuvSの問題は、まさにこれが原因。 HuffyuvSはCCESPパッチ0.2.2版を元に作られたものであるため、この問題が発生する。 0.2.5ではインタレース情報をエンコードしたファイル中に保持するように変わったため、 ファイルごとに適切にデコードできるようになった。) 3.オリジナルのHuffyuvでエンコードしたファイルはCCESPパッチ版でデコードできるが、 CCESPパッチ版のHuffyuvでエンコードしたファイルはオリジナルのHuffyuvではデコードできない場合がある。
337 :10/04/13 質問1.上記1の「YUY2の扱いの食い違い」とはどういうものだったのでしょう? 質問2.上記1のために入れられた改造というのはどういうものだったのでしょう? また、CCE以外で使う場合に、どのような影響があるものなのでしょうか? 質問3.ttp://amamaman.hp.infoseek.co.jp/hosoku/amv210benchi.htm を見ると、 「HuffyuvMTは「convert to YUY2」も高速なのでシングルスレッドで使う場合でもお勧め」 とあります。HuffyuvMTはCCESPEパッチ0.2.5版Huffyuvをベースに開発されたようですが、 シングルスレッドでも高速ということは、「convert to YUY2」の高速化はマルチスレッド版での改造ではなく CCESPパッチ0.2.5で実装されたものなのでしょうか?
338 :10/04/13 いちおうググりまくったつもりなのですが、CCESPパッチについて詳細に書かれたページが見つからなかったので、 参考になるページなどありましたら、そちらも教えていただければ助かります。 何卒よろしくお願いいたします。
339 :10/04/16 ソースの差分見るのが一番はやいんじゃないかな
340 :10/04/17 >>339 う、残念ながらさすがにソースまでは読めません。 その後Huffyuv2.2.0についてるhuffyuv.htmlで以下の記述を発見しましたが、 抜粋のようですし、いまいち回答に結びつきませんでした。 HuffYUV CCESP-patch 0.2.2 As this version is based on the CCESP-patch 0.2.2 I will also include the changelist here: * Version 0.2.2 allows you to set the output buffer size. Might fix crashing. * No need to check "Always suggest RGB format for output" checkbox anymore (though checking it might be a good idea). * CCE will run faster if you are using YUY2 compressed avis (i.e. if you are using RGB compression, nothing will change). * Cleaner configuration dialog with tooltips. * Option to change the field threshold.
341 :10/04/17 あと、 "HuffYUV revisited" 2.2.0 released - Doom9's Forum ttp://forum.doom9.org/showthread.php?t=67121&pp=20 のbastel氏のレスとかを見る限り、 0.2.3・・・一部のデータの初期化処理を変更 0.2.4・・・インタレースフラグをエンコードデータの中に持たせるようにしたが 実装方法がいまいちだったので取り下げたバージョン 0.2.5・・・インタレースフラグの持たせ方をHuffyuv2.2.0と同じ方法にして 互換性を考慮してみたバージョン という感じのようですね。
342 :10/05/25 可逆圧縮について質問したいのですが 動画を非可逆圧縮する際は、余程高スペPCでない限りは別作業はしないべきですが 可逆圧縮は元データを消さず劣化させない、という事は 別作業などして負荷をかけても映像は劣化せず、作業結果も同じ(時間や数MB程度の差は出たとしても) という事でしょうか? それとも何かしら影響はでますか?
343 :10/05/25 釣りだと思うけど一応マジレスしとくと 可逆圧縮は劣化しないから可逆(=元に戻せる)圧縮であって、 可逆でも非可逆でもエンコード中に他の作業をしても画質もサイズも変わらない
344 :10/05/25 まじかー、ちょっとググッたら時間は延びても画質は変わらないというのが殆どのようだ 昔そういう記事がよくあってそんな感じの知識がついた覚えがあったんだけどなぁ いつも気にしてたのは無駄だったということかw という事はゲームプレイや動画見たりなどのグラボ使うようなものも処理には影響なく 処理落ちやコマ落ちなども起きないって事ですね(時間は延びるけど エラー発生する事が多少あるかもしれない、程度なのかな
345 :10/05/25 >>343 圧縮と展開の間が可逆であって圧縮前に非可逆で劣化になることしてるのもあるんだけどね
346 :10/05/26 動画エンコード中にわざわざエラーの原因作るような作業をする神経が理解できん。
347 :10/05/26 fpsゲームのfraps撮影動画ファイルを中間ファイルにするため Huffyuv、UtVideoを使ってaviutl、VirtualDubで試したのですが どれも元ファイル1.12GBよりも必ず大きくなってしまいます、2.21GBや2.41GBだったり等 コーデックの設定から圧縮選択等を変えても結果が同じです AMV3の可逆圧縮S2でやっと1.3GBくらいになるのですが、それでもサイズが増えます 調べると、半分とはいえ圧縮されると記述するサイトもあれば 単に容量が増える(変わりに劣化しない中間ファイルができる)としてるサイトもあります コーデックの説明でもサイズが増えるとあるので容量が増える事自体は理解してるのですが どの設定をしても容量が減らせない、というのが分かりません これは元動画が可逆圧縮に適していないという事でしょうか 例え1MBでも非劣化で容量を下げる事ができると思って導入を試みたのですが困ってます できたらご指導お願いします
348 :10/05/26 圧縮と可逆の話混同してない?
349 :10/05/26 >>347 Fraps(非可逆) → デコード → 可逆 これで容量が増えない方がおかしい
350 :10/07/18 マルチスレッドでyuv4mpegエンコ出来るの無い?
351 :10/09/29 可逆と学習
352 :10/09/29 はっふゅーぶい
353 :10/09/30 MLC Codec ttp://www.linek.sk/mlc/ Size: 89727576/1750118400 ( 5.1%, 19.50) Encode time: 444643.329949ms/1899f = 234.146040ms/f Decode time: 47360.779505ms/1899f = 24.939852ms/f Random access time: 2424.806946ms/f UTvideo YUV422デコード優先 Size: 249828464/1750118400 (14.3%, 7.01) Encode time: 2874.146849ms/1899f = 1.513505ms/f Decode time: 2847.453798ms/1899f = 1.499449ms/f Random access time: 1.499449ms/f マルチスレッド対応でエンコード遅いけど圧縮率はいいロスレスコーデック。 個人的には遅すぎて使えないけどサイズ減らしたい人用かな。
354 :10/10/01 あのデスクトップキャプチャ向け激重超圧縮コーデックかと思ったらアレはMSUだった
355 :10/10/03 >>353 できれば同じソースでLagarithとMSUでもテストした結果が知りたいけど 自分でやれと言われたらすんません面倒ですとしか言えない。 俺は何を言っているんだ。
356 :10/10/03 MSU Lossless Video Codec 40分経過しても終わらなかったので中止。1/3は終わってたようだ。ロスレス・圧縮重視設定 MSU Screen Capture Lossless Codec Size: 136332964/1750118400 ( 7.8%, 12.84) Encode time: 36285.694228ms/1899f = 19.107791ms/f Decode time: 53880.412119ms/1899f = 28.373045ms/f Random access time: 221.875139ms/f Lagarith YUY x64 Size: 112147106/1750118400 ( 6.4%, 15.61) Encode time: 9903.315504ms/1899f = 5.215016ms/f Decode time: 10609.780675ms/1899f = 5.587036ms/f Random access time: 5.587036ms/f Lagarith YUY x86 Size: 108665659/1750118400 ( 6.2%, 16.11) Encode time: 7455.594997ms/1899f = 3.926064ms/f Decode time: 11552.247863ms/1899f = 6.083332ms/f Random access time: 6.083332ms/f Lagarith RGB x86 Size: 160564192/1750118400 ( 9.2%, 10.90) Encode time: 9062.881992ms/1899f = 4.772450ms/f Decode time: 13700.682196ms/1899f = 7.214683ms/f Random access time: 7.214683ms/f MLC Codec 速度重視 Size: 149956346/1750118400 ( 8.6%, 11.67) Encode time: 14484.359144ms/1899f = 7.627361ms/f Decode time: 20227.331265ms/1899f = 10.651570ms/f Random access time: 274.937664ms/f 暇だし興味あったんで試した。 元の動画は2Dゲームです。core2duoなんでi7とかAMDだとx64の結果は違うかもしれないけど Lagarith YUY x86がバランスよさそう?総合バランスはutがぶっちぎりだけど。
357 :10/10/03 MLCの速度重視はそんなに速いのか 色空間がRGBでそれならLagarithより良いんだが サイズだけで比較しようと実写ソースでやったら Lagarith YUV 89106968/526521016(16.9% 5.91) Utvideo YUV 圧縮重視 98148692/526521016(18.6% 5.38) MLC 最高圧縮 54381154/526521016(10.3% 9.71) こんなんなった 遅さもヤバイ
358 :10/10/03 実写だとかなり縮むね。短めのソースなら使えるかもしれないくらいかな。 こだわりなければMP4でいいから難しいところ・・・
359 :10/10/04 ソースは1.44GBのこれで、(1920x1080, 50 fps, 4:2:0) http://media.xiph.org/video/derf/y4m/1080p/park_joy_1080p.y4m FFV1(-g 200 -coder 1)とMLC 0.8(Maximum compression)を比較したけど、 実際に、FFV1の876MBに対して、MLC 794MBと、圧縮率は良かった。
360 :10/10/04 >>356 >>355 ですが、ありがとうございました。参考になりました。
361 :10/10/11 [UtVideo] バージョン 8.3.0 性能向上 * ULY2: デコード速度優先でエンコードされたものの YUY2 や UYVY へのデコードを高速化した。Core 2 で 12% ほど。 * ULY0: デコード速度優先でエンコードされたものの YV12 へのデコードを高速化した。Core 2 で 5% ほど。 その他 * ULY2: YVYU と VYUY での入出力のサポートを廃止した。 * ULY0: YVYU と VYUY での入出力のサポートを廃止した。
362 :10/10/21 Motion JPEG XRって可逆?
363 :10/10/22 >>362 Wikiのコーデックのとこだと可逆に入ってるが真偽は知らん。ググってもよーわからん。 ttp://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%87%E3%83%83%E3%82%AF JPEG XRは可逆もサポートしてるから、たぶんMotion JPEG XRも プロファイルによっては可逆もサポートすんじゃないのかね。 ISO/IEC 29199-3とやらを見ればわかるんだろうけど、金払ってまで読む気はしないし。 ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51610
364 :10/10/24 最終的にDVD規格とかに圧縮するなら中間はx264のcrf10前後で十分な気がしてきた
365 :10/10/24 ならそうしなさい
366 :10/11/02 [UtVideo] バージョン 8.5.0 性能向上 共通: x86 でのデコードを 10% ほど高速化した。 共通: x64 版をアセンブラ化し、おおむね x86 版と同程度の速度にした。
367 :10/11/18 Lagarithのインストーラーの方をダウンロードしたのですが AviutlでコーデックをLagarithにした動画を真空波動研でみると 使用したコーデックの名前が書かれるところに 不明lags と表示されてる のですがこれっておかしいですよね?(これといった不具合はありません) 再インストールしても同じでした。 OSは7で32bitです 分かる方がいましたらお願いします。
368 :10/11/18 真空波動研は最近の新しいcodecに対応してないという罠?
369 :10/11/18 もともと動画が自分が何のコーデックなのか提示するのに使われてるのは FourCCっていう4文字のアルファベットだけ 真空波動研はその識別文字が何のコーデックなのかというリスト(codecs.ini)を自前で用意してて 動画のFourCCがリストに記載されていたら、そこから正式な名称を持ってくる そしてリストになかった場合は不明としたうえでそのFourCCが何だったのか表示される そして今の真空波動研にはLagarithは登録されてない よって不明lagsというのは「正式名称は不明だけどそのFourCCはlagsだよ」という真空波動研からの回答になる 要するに>>368 なんだけど
370 :10/11/18 ただ真空波動研に登録されてないだけだったんですね。 これで安心してLagarithが使えます。ありがとうございます。
371 :10/11/19 Lagarithはやめとけ ろくなことがないから http://mod16.org/hurfdurf/?p=142
372 :10/11/19 日本語でおk
373 :10/11/19 UtVideoでええやん
374 :10/11/19 俺もUtVideoでいいと思うけど、しばらく残しておきたいようなファイルはLagarithにしてるな。 Lagarithは割と圧縮率がいいから。別に気になるような問題は起きてないし。 まあ圧縮率だけ見るなら他の選択肢もあるだろうけど、なんとなくLagarithにしてる。
375 :10/11/19 >>373 ドキュメント日本語だしな
376 :10/11/20 「デコード速くするためにCPU負荷下げて圧縮率抑えてるのにストレージ転送速度のせいで体感逆やんワロス」 って事らしいからLagarithと同じ手法で圧縮率上げる方向性になるとか http://umezawa.dyndns.info/wordpress/?p=2118
377 :10/11/20 YLCもなかなかバランス良いよ
378 :10/11/20 中間ファイルとしてならPフレームまでなら(音ずれの心配もないし)アリだと思うけどなぁ。。
379 :10/11/20 うちはffdshowに採用されてて、将来的な再生互換性がありそうなFFV1で 保存してる。けど再生時の負荷が高いんだよなあ…
380 :10/12/01 RGB24での可逆でAMV2MTより高圧縮のcodecって今の所無いよな つーか何でAMV2MTってこんなに圧縮率高くてエンコード速いんだ?
381 :10/12/01 >>380 AMV2MTは確かにエンコ速くてバランス良いんだろうけど、圧縮率はあまりよくないような。 あまラボ ビデオコーデック・ベンチマーク2009 http://amalabo.blog35.fc2.com/blog-entry-44.html バランスの良さはマルチスレッド対応なことと、可逆にしては珍しく(だよね?)、 フレーム間圧縮を使ってるってのが大きいのかな。
382 :10/12/01 圧縮率を優先するのなら、FFV1で良いだろう。 RGB32にも対応しているし、無料で使える。
383 :10/12/01 >>381-382 おー割とあるんですね、ありがとうございます 色々と試してみますね
384 :10/12/01 どこかのサイトで、各コーデックがロスレスであることを証明する為に、エンコした動画の MD5のハッシュ値をのせてたんだけど・・・どこだったかな。 アレは無圧縮AVIに再エンコしてからハッシュ採ってたんだろうか。 動画ファイル入力したらハッシュ値を出してくれるソフトがあったりしませんかね? x264ロスレスを扱う必要出てきて、ロスレスであること確認しつつパラメタを最適したく思い。
385 :10/12/02 ググったらいくらでも出てくる
386 :10/12/02 >>384 y4mで出力してハッシュを比較するとか。
387 :10/12/02 x264losslessはソースがYUV420ならロスレスだよ(昔、実際にハッシュの比較したことある) なんらかのエンバグでも起こってない限り大丈夫
388 :10/12/02 レスthx。 >>386 そう、なにか別コーデックにエンコし直ししかないっすかねぇ・・・ まるも氏のAviUtlのプラグインのy4mしか知らないんですが、これ早いのかな?コマンドライン版あれば 何度も比較するの簡単なんスが。 >>387 いちお、YUV444、YUV422(YUY2)、YUV420(YV12)、YUV411各々の色情報のサンプリング方法に ついては判ってるつもり。 Bフレ1枚入れても可逆なのか、それでavidemuxで分割できるのかとか、YouTubeにうpできるのかとか・・・ いろいろ実験もしてみたいのです。
389 :10/12/02 >>388 >コマンドライン版あれば ffmpegかMEncoderかavs2yuv >Bフレ1枚入れても可逆なのか そもそもx264losslessはBフレを使わない(使えない) >avidemuxで分割できるのか 出来るよ aviにいれてVirtualDub使ったほうがいいけど >YouTubeにうpできるのか 現在のところはできない なぜならつべの鯖が使ってるffmpegが、まだx264losslessのデコードに対応してない、やたら古いものだから
390 :10/12/02 そもそもH.264のロスレスは最上位のHigh444 Profileだからな。ずっとサポートされなくてもおかしくはない
391 :10/12/02 >>389 > ffmpegかMEncoderかavs2yuv 388書いた後avs2pipeを見つけまして、これ使ってみようかなと。まぁY4Mにこだわってる訳じゃ ないんですけど。 > そもそもx264losslessはBフレを使わない(使えない) 私は可逆はI(IDR)フレームだけで出来てるのかと思ってたんですが、ここ↓読むに ttp://agehatype0.blog50.fc2.com/blog-entry-239.html Bフレはおkなのか!?と思い、実験の目的の1つになってるんですよ。 > 出来るよ あ、書き足らずですみません。Bフレ3、4枚使った通常の(量子化した)mp4がGOP単位で分割 出来るのはやってるんです。ただ、コレじゃmp4boxと違いはないし・・・ 可逆なら1フレーム単位で分割位置を指定できるのか?と思いましてん。 > つべの鯖が使ってるffmpegが、まだx264losslessのデコードに対応してない えええぇぇぇ・・・_| ̄|○ 今回x264ロスレス使ってみようかと思った最大のモチベーションがYouTubeだったのに。 つーか、YouTubeってffmpegをまんまで使ってるのん?なんつーローテクな。ホントかょ・・・
392 :10/12/02 まんまじゃないと思うよ x264の名前とかエンコオプションとか消えてるから そんなことするなら更新しろよって話だが
393 :10/12/03 >>391 ffmpegがローテクって…じゃあ、ffmpegよりハイテクなのはいったいなによ? >Bフレはおkなのか!?と思い、実験の目的の1つになってるんですよ。 http://git.videolan.org/?p=x264.git;a=commit;h=6a4a9beae060d69bbeaeb8c1c3056fb6ae6765f6 2年位前に、完全に使えないように変更された とりあえずx264losslessはBフレは使わないがPフレは使うから、 クリップの先頭は必ずIDRフレームじゃなきゃ駄目だ 再エンコなしでやりたいなら、--keyint 1つけて全部IDRにしろ まあ、可逆なんだから単純に再エンコすればいいだけなんだけど あと可逆でつべに上げたいんだったらffvhuffかFFV1で音声PCMのaviにすればいい つべがffmpeg使ってる証拠に、ちゃんと対応してるぞ 最近は20GBあたりまで大丈夫らしいから、そこそこでかくて長いのもいけるだろ
394 :10/12/03 > ffmpegがローテク いえ、サーバのデコード環境に合わせてlibavcodecなんかをチューニングしてないのかなーと。 とくに悪気があったワケではないですごめんなさい。m(_ _)m > ffvhuffかFFV1 そっかffmpeg使ってデコードしてるんならffvhuffって方針もアリですね。FFV1使ったコトない けどhuffよりファイルサイズ小さくなるなら、こちらも良さそう。 いろいろアドバイスありがとうございました。 なんとか、できるだけ高画質なYouTubeをBRAVIAで視聴出来そうです。
395 :10/12/03 なんでチューニング=H.264 High444Profileに対応っていう考えになるんだ
396 :10/12/03 >>395 だれもそんなこと言ってないが(汗 このスレから外れると思って>>394 に書かなかったんだけど、チューニングとして薄っすら 思いついてたのは、負荷平準化やフォルトトレラントを狙って動作環境にマッチする様な カスタム化ってことで。ffmpegの構造まんまなモノリシックを止めて、より負荷を分散させ クラスタ/ファーム内にメッセージパッシングするってゆーよーな(Java RMアプリや OracleのParallel Serverぽい)。 ・・・たかが動画SNSにそんな高可用性求めてどーする!?ってツッコミあるとおもうけど、 妄想として、Googleも冷却コストの低い、ダウンタイムの短いシステム構築に変わりつつ ある今、YouTubeもそこに乗っかってアップ・エンコが確実に早く終わるようになれば・・・ と。だって最近15分モノのアップに2時間近く、8本に1本は途中で異常終了してる (たぶんエンコードの最終段階でハング)んで (´・ω・`)
397 :10/12/03 クスリでもやってるの?
398 :10/12/04 リタリンを少々
399 :11/02/12 ノータリン
400 :11/02/13 今時リタリン処方する医者いるのか?
401 :11/02/13 デパスを少々
402 :11/02/16 今時HuffyuvMT使ってる奴いる?
403 :11/02/16 HuffyuvMT使ってる奴がいたらどうなるんだ? お前が救われた気持ちになるのか
404 :11/02/16 俺がHuffyuvMT使わないことで、他の誰かが救われるなら 俺はよろこんでHuffyuvMTを使おう
405 :11/02/16 Lagarith v1.3.22きた バグフィックスがあるから使ってるなら更新した方が良いだろうけど 軽く計った限りでは性能面での相対的な立ち位置は大して変わってないみたい
406 :11/02/16 欝ビデオがあるからもう要らない
407 :11/02/16 圧縮率は良いけど欝との速度差はもうかなり広いからし 欝がRange Coder積んだらその点さえ負けそう
408 :11/02/16 utvideoの頼り劣っている面ってなにないでしょうか
409 :11/02/16 不可逆圧縮に比べると縮まないし、無圧縮より再生時負荷が高いね。
410 :11/02/16 つまり可逆圧縮としては他と比べて劣っていると言える部分は無いんだな?
411 :11/02/16 誰がそんなこと言ったの?
412 :11/02/17 聞こえても仕方がないよね
413 :11/02/17 バージョンは1.3.22 2011年2月15日にリリース ダウンサンプリングすることで修正されたバグは、ビデオの破損が発生していました。このバグを報告するためのカールプリチットに感謝します。 ビデオの破損の原因となったRGBAとマルチスレッドモードでYV12をビデオで修正いくつかのレース条件。これはまた、カールプリチットによって報告されました。 64ビットのバグを修正しましたRGB24ビデオをダウンサンプリングするときにクラッシュを引き起こしたことをビルドします。
414 :11/02/17 なにこの機械翻訳
415 :11/02/17 >>414 >>413 を適当に翻訳すると、 Ver.1.3.22 リリース日:2011/2/15 修正: ダウンサンプリング時に映像が破損するバグを修正(報告者:カールプリチット) マルチスレッド時にRGBA・YV12で映像が破損するバグを修正(同上) 64bitOS時にRGB24形式でダウンサンプリングするとクラックするバグを修正 あ、原本はもちろん見てない
416 :11/02/17 zip版がないぞー
417 :11/02/17 1.3.21のchangelogをちゃんと見ておいたほうがいいな。 ・スピード面は大体10〜30%くらい改善。 ・Reduced Resolution modeが無くなった。 その他もろもろ。 >>416 ほんとだ、リンク切れてるね。
418 :11/02/17 http://lags.leetcode.net/LagarithSetup_1322.exe
419 :11/02/18 zip版きてる
420 :11/02/18 拾ってきた
421 :11/02/19 すべてのバージョンコーデックは、しかし、下位互換性があります。 バージョンは1.3.22 2011年2月15日にリリース ダウンサンプリングすることで修正されたバグは、ビデオの破損が発生していました。このバグを報告するためのカールプリチットに感謝します。 ビデオの破損の原因となったRGBAとマルチスレッドモードでYV12をビデオで修正いくつかのレース条件。これはまた、カールプリチットによって報告されました。 64ビットのバグを修正しましたRGB24ビデオをダウンサンプリングするときにクラッシュを引き起こしたことをビルドします。 バージョンは1.3.21 2011年2月13日にリリース するバグを修正コーデックは特定の解像度をダウンサンプリングするときにクラッシュする原因となります。このバグを報告し、追跡するためのリチャードジョーンズのおかげで原因。 いくつかの速度の向上: - 統合のRLE復元ので、復号化の範囲デコーダにデータのみの1回のパスを取ります。 - 範囲デコーダハッシュテーブルのサイズを増やしました。 - 削除のRLEレベル2は、テストは、任意の本当の利点は、1または3つのレベルの詩提供していないことを示しています。 - RLE圧縮が並列にすべてのレベルをエンコードし、最適なものをではなく、実行推定を実行し、RLE実行を選択します。 - RLE圧縮がサポートSSEのプロセッサの高速化SSEのバージョンがあります。 - 追加の中央値予測と画像のレイアウトに関連するいくつかの機能のMMX/SSE/SSE2の最適化を、既存の改善された。 全体的に私は、通常、10?30%の速度についてを参照してください改善。 のRLEレベルが向上するように選択される方法を調整しました約1%圧縮。 仕事がで配布されてどのように調整しました CPU時間を無駄に減らすためにマルチスレッド。 それは些細な変更されて以来、わずかに速いにYUY2やUYVYもされているエンコーディングYV16ソースビデオのサポートが追加されました。 削減解像度モードを削除、私はそれが十分に正当化するために有用ではないと思う維持されます。
422 :11/03/07 1.3.23
423 :11/03/07 ふむふむ Version 1.3.23 released on 3-5-2011 Fixed a buffer overrun that caused crashes on certain resolutions when decoding RGB video. Thanks to Nick Hope for reporting this. Improved the performance of the SSE and SSE2 routines for decoding YUY2 slightly.
424 :11/03/09 バージョンは1.3.23 2011年3月5日にリリース 固定バッファは、RGBビデオをデコードする特定の解像度でクラッシュを引き起こしたことをオーバーラン。これを報告して、Nick希望に感謝します。 改善されたわずかにYUY2をデコードするためのSSEとSSE2ルーチンのパフォーマンスが向上します。
425 :11/03/29 huffyuvのinf弄ってWin7 64bitにインスコして昔huffyuvで撮った動画をaviutlで編集しているんですけど、 バックグラウンドでWMPやMPCHCでMP3とかを再生すると極端にデコード速度が落ちるんですが、 そういう仕様なんでしょうか? 一コマ送るだけでも1〜2秒掛るくらい遅くなります。
426 :11/03/29 >>425 編集中になんで音楽を・・・BGMのつもりか CPUも表記せずに「仕様(ry」とか言われても・・・
427 :11/03/29 余計な作業は別PCでやれってことだろ
428 :11/03/29 >>425 インテルCPUならそうなる事もある
429 :11/03/29 >>428 それってCPUの差とかあんのか?
430 :11/03/29 i7 950だけどXP(32bit)の時は全く問題ないけどWin7(64bit)だと同じような症状が出るな AviutlでHuffyuvからx264へエンコ中に動画とか音楽再生すると急にエンコ速度が下がる CPU使用率70%くらいだったのが10%辺りまで落ちるね WOW64が原因かもね
431 :11/03/29 今確認してみたけど重くなるのはHuffyuvで撮ったソースだけだな まぁ今更Huffyuv使う必要性もないし他の使えばいいんじゃね
432 :11/03/29 >>431 今やHuffyuvはソフト互換性が抜群なだけだしな >>430 メモリのために64bitをインストールしたのか・・・
433 :11/03/29 ttp://support.microsoft.com/kb/948066/ja?sid=013a5e9525e5597eee063f3e25812c34 可能性の一つとして。
434 :11/03/30 >>426 すみません、Core i7 970です。 BGM流しながら、ここのフレーズはどのシーン切り出そうかな〜とかやりません? >>430-431 検証ありがとうです。 やっぱりWin7 64bitだとそうなりますよね。 他のコーデックだと問題無いのに、huffyuvだけ異様に遅くなるので、気になってました。 これから撮る素材はいいとして、今まで撮ったhuffyuvの素材が少々面倒ですよね。
435 :11/04/13 >>384 いまでもここ見てるかどうか知らんが つべがx264losslessでもいけるようになったみたいだぞ http://forum.doom9.org/showthread.php?p=1491969#post1491969
436 :11/04/14 1.3.24
437 :11/04/14 utvideoの圧縮率優先にする方法が書かれている場所ないでしょうか いろいろな所に言っても書かれてないので教えてください
438 :11/04/14 >>437 コーデックの設定いじればいいだろ・・・
439 :11/04/14 デコードと圧縮の優先順位がある項目をクリックしても保持してくれない 確認するとデコード優先に戻ってしまうので困ってる
440 :11/04/14 http://umezawa.dyndns.info/wordpress/?p=1890
441 :11/04/15 バージョンは1.3.24 2011年4月10日にリリース 南南東&ビデオを破損している原因のRGBビデオMMX命令中央修復ルーチンのバグを修正しました。このバグを報告するためのウーヴェJahnさんに感謝します。 SSE命令は、いくつかのMMX命令中央修復ルーチンで使用されていたバグを修正、これはSSEをサポートしていないプロセッサ上でクラッシュを引き起こすでしょう。 オーバーホールは、揮発性のフラグではなく、イベントを使用して、ループを待つマルチスレッド。これは、マルチスレッドモードでパフォーマンスが若干改善し、より安定性を提供します。 中央修復MMX/SSE/SSE2ルーチンを改善、これはわずかにデコード速度を上げてください。 色空間をダウンサンプリングのSSE2ルーチンが追加されました。 SSE2をサポートするマシン上で色空間を変更するエンコーディングに時間が短縮されます。
442 :11/04/17 日本語変換のバグを(ry
443 :11/04/20 やっぱりutvideo優秀だな
444 :11/05/08 UtVideo 9.0.0出てた
445 :11/05/09 バグ処理マチかな
446 :11/05/09 結局Lagarith使っちゃうんだよな。
447 :11/05/10 今までも使ってないしこれからも使わない
448 :11/06/03 Huffyuvは相変わらず万能だな。 編集もしやすいし。 H.264 losslessで最後は出力するだけ。
449 :11/06/03 Lagarith使ってたけど、なんとなくUtVideoに切り替えていた まあHuffyuvの万能さは異常なので複数ソフトで使い回す際に使っている
450 :11/06/05 GaeBolgVideoCodecのがでてた前のzeroの後継だけど utより処理は遅くて少し縮む感じ。 Lagarithよりいいかとかvctestはやり方忘れたのかできないので興味ある方に。
451 :11/06/07 >>448 utがある中でHuffyuvが使えるってとこあるのでしょうか?
452 :11/06/07 >>451 可能でなく使役でか・・・ 汎用のGUIエンコーダ(MediaCoderとか)とかにデータ食わせる時とかかな?
453 :11/06/07 ふっふぃーより扱いやすいのあるか?
454 :11/06/13 HuffyuvはWin7 64bitで妙な処理落ちするからもう使ってないな。
455 :11/06/13 まだまだXPで粘ってるけどPCの足回りやらいろいろで、そろそろ限界だよなぁ
456 :11/06/18 7いいよぉ 一度使い始めると(もちろん相応のビデオカードなどとセットでだけど)XPには戻れん
457 :11/06/23 http://forum.doom9.org/showthread.php?p=1500141#post1500141 Lagarith 1.3.25 ぱねえ
458 :11/06/23 >>457 一見凄そうに見えるけど、UTはその1.5倍は速いんだよ しかも圧縮率も1080pの5000フレームでLagarith8.45GBに対してUt8.51GBとかだし
459 :11/06/23 LagarithSetup_1325 MT on Size: 453432237/1817856000 (24.9%, 4.01) Encode time: 5221.150420ms/2630f = 1.985228ms/f Decode time: 8218.659309ms/2630f = 3.124966ms/f Random access time: 3.124966ms/f utvideo-9.0.0-x86 RGB CPUにあわせる 圧縮優先 Size: 530720140/1817856000 (29.2%, 3.43) Encode time: 3353.778696ms/2630f = 1.275201ms/f Decode time: 5702.366726ms/2630f = 2.168200ms/f Random access time: 2.168200ms/f ソース ニコのアニメのPV vctestが落ちなかったRGB AMD Phenom II X4 B60 Processor 3.2G win7x64sp1 とりあえずのテスト結果
460 :11/06/24 個人でWin使ってる分にはUtVideoとか好きなの使えるけど WinとMac両方で使える可逆圧縮でいいのないもんかね QuickTimeのPNG圧縮はエンコードもデコードも遅すぎて辛い
461 :11/06/24 ffmpeg系使えるならhuffとかロスレスh264とか
462 :11/06/24 >>460 ffmpeg -vcodec ffv1
463 :11/07/05 このスレでいいのかわかりませんが、質問があります。 digaでBDに焼いて、AnyDVDHDでHDDに保存してますが m2tsだと1ファイル22GBとか巨大なので、可逆圧縮でエンコしたいと思ってます。 エンコ後、またm2tsに戻してBDに焼くことも考えています。 win7の64bit環境ですが、何か目的にあうようなソフトはありますか?
464 :11/07/05 BDは非可逆圧縮なので、それをデコードして可逆圧縮なんてするととんでもなくファイルサイズがでかくなる やめとけ
465 :11/07/05 テラいくか
466 :11/07/05 m2tsをじっぷで圧縮すれば… いやなんでもない…
467 :11/07/06 THcomp使えばどんな動画も1byteに圧縮できるのを知らないのかよ
468 :11/07/06 >>464 ありがとうございます。 そうなんですか… >>466 しょっちゅうみる動画じゃないし、最悪それでもいいかなと思い始めてます。 >>467 釣られんよw
469 :11/07/06 THcompとかおっさん過ぎだろw
470 :11/07/22 しwwwwwげwwwwwるwwwwwwwwwwwwwwwwwwwwwwwwww
471 :11/07/25 エイトマン エイトマン ハイハイハイハイハイ
472 :11/07/25 Xメディアプレーヤーで色々やってるけど容量が増えるばかり AVI〜をDLしても対応してないと失敗ばかり どうしたらいいのかわからない 誰かにこんなおいらを導いて(;_;)
473 :11/07/25 Yahoo知恵袋で聞け
474 :11/08/26 ログ復活
475 :11/09/12 [UtVideo] バージョン 10.0.1 不具合あったらしいから一応
476 :11/09/27 1.3.26
477 :11/09/27 なにかとおもったらLagarithか
478 :11/09/27 2011年9月25日にリリースされたバージョン1.3.26 アドビ製品とのクラッシュを引き起こしたデコーダでバッファオーバーランを修正しました。 このバグを報告されたすべての方々に感謝。壊れている可能性が1.3.20およびそれ以前のバージョンから特定のソリッドカラーのフレームの原因となったエラーを修正しました。 これを報告し、サンプルのビデオを提供するためのルークマッケイ - モリスに感謝します。
479 :11/10/09 YULSとMSUは恐ろしく縮むけどデコード時の負荷がすさまじいな h.264みたいにGPUでエンコード/デコードってできないもんなのかな?
480 :11/10/10 よほどメジャーにならなきゃGPU側に対応しようという動機が発生しない
481 :11/10/10 >>479 何それ?ウマイの?
482 :11/10/10 エンコードデコードともにマルチスレッド化が先だろうね H264の再生の444・422対応のほう進めてくれたほうがいいかな
483 :11/10/10 x264でlosslessで出力したらなんとも説明しがたい変な映像が出てくる MLCの標準よりかなり縮んでDXVAが使えるのにこれじゃ意味がない
484 :11/10/10 DXVAでロスレスは再生できなかったと思うが
485 :11/10/14 動きの激しいゲームの動画をMSUで圧縮したら(512*384,24fps)E5200だとまともに再生できない んだがi7 2600Kなら遅延なく再生できるのだろうか?
486 :11/10/14 無圧縮や可逆圧縮は再生向きのコーデックじゃなく編集などのためのものなんだから 遅延なく再生しようという考えがまず間違いなんじゃないだろうか。 できるのかどうかという点については興味はあるけど。
487 :11/10/14 >>485 うp
488 :11/10/15 今更だけどMSUとか試してみた。 ソースは秒速5センチメートルのWMV。1280x720 24fps 1092frame。 http://5cm.yahoo.co.jp/teaser/index.html AviUtl 0.99jで各コーデックのYUY2圧縮のチェックを外してRGBエンコード。 CeleronM423 1GHzという低スペックで「Absolutely lossless」「Max compression,slow decompr.」、 要するにRGBロスレスでの最高圧縮にしてエンコード開始したらほぼフリーズ状態になって、 数分待っても全くエンコードが進まないwww 出力中断メニューを出すのにすら苦労して、7フレーム目までいったところでやっと中止。 「Absolutely lossless」「Balanced」に変更してやりなおした。 あんまり厳密じゃないけど結果。エンコード時間はプロパティ見て作成日時と更新日時の差で見たもの。 全部同じPCM音声入りなので映像だけのサイズではありません。UtVideoとLagarithはちょい前のものっすね。 最初にHuffyuvでAVI出力して、それをソースにしてLagarithで出力して、残りはそのLagarithのをソースにして出力。 そのためLagarithのデコードの遅さがある程度影響してるかもしれない。 Huffyuv 2.1.1 サイズ922MB、エンコード時間不明(ファイル消しちまった) Lagarith 1.3.20 サイズ384MB、エンコード時間6分15秒 UtVideo9.0.3 ULRG(圧縮優先) サイズ569MB、エンコード時間5分24秒 MSU 0.6.0(Absolutely lossless、Balanced) サイズ222MB、エンコード時間20分35秒 ffdshow tryouts 3984のFFV1(RGB32、VLC、small、10) サイズ332MB、エンコード時間8分00秒 MSUは確かに縮むけど、俺は通常はUtVideo、サイズ優先で圧縮したい場合はLagarithでいいや・・・。
489 :11/10/15 AMV2MTを忘れてた。 AMV2MT 2.20h(R2標準可逆) サイズ778MB、エンコード時間4分37秒
490 :11/10/15 乙
491 :11/10/15 [vctest] ベンチ更新 & MSU Lossless は稀に化ける…? http://umezawa.dyndns.info/wordpress/?p=341 マルチスレッド対応してる他のはエンコード時間もっと短くなるから厳しいね
492 :11/10/15 あと、一応書いておくとMSUのデフォルト設定である 「Allow colorspace conversion」 は、公式サイトにも書いてあるとおり 「内部でYV12に変換して圧縮するモード」 なので、RGBやYUY2のロスレスにはならない。YV12変換が入ることで色が混ざる。 RGBやYUY2で可逆にしたい場合は必ず「Absolutely lossless」を選ぶ必要がある。
493 :11/10/15 >>491 うげ、「Absolutely lossless」でも化けることがあるのか・・・なおさら使えないな・・・。
494 :11/10/15 >>356 でそういや試してたなと
495 :11/10/15 Lagarithより縮む可逆コーデックってあるもんなんだな・・・ UtVideoの使い勝手良すぎてそれしか使ってないけど
496 :11/10/17 ttp://www.ffmpeg.org/trac/ffmpeg/ticket/534
497 :11/10/18 http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1de357d6da3c4e4c1c47c8be182efbb4d4d8d7b4 UtVideoがffmpegでデコードできるようになった
498 :11/10/18 肝心のffmpegの行方のほうががががががが
499 :11/10/18 キタ━━━━━━(゚∀゚)━━━━━━ !!
500 :11/10/18 http://lists.libav.org/pipermail/libav-devel/2011-October/012736.html 安心しろlibavにもパッチが来てる
501 :11/10/18 UtVideoの作者はFOURCCを変えたいみたいなこと言ってたけど、どうなったんだろう。 http://umezawa.dyndns.info/wordpress/?p=1522
502 :11/10/19 http://git.libav.org/?p=libav.git;a=commit;h=0d8506b8c52659c5bfff9535391d5e95ddcd45f1 libavにUtVideoのnative decoderコミット
503 :11/10/26 ffdshowに搭載まだかお
504 :11/10/29 MLCとかMSUとかYULS対応のハードウェアエンコーダが出たら1920*1080のゲーム動画を 簡単に無劣化でキャプチャーできてありがたいんだが・・・
505 :11/10/29 1080pネイティブ解像度のゲームなんて数える程しかなかろ
506 :11/10/29 http://blog-imgs-30-origin.fc2.com/a/m/a/amalabo/amd_rgb_fez.jpg 昔は圧縮率高いの要望してた頃もあったな・・・ 今はもうそんな需要減ってるだろうけど
507 :11/10/31 Huffyuv_mtのx64ネイティブ版ってないの?
508 :11/10/31 何に使うんだよ おとなしくUtVideo使っとけよ
509 :11/10/31 なぜかマルチコアに最適化されてないコーデックが多い・・・(YULS,MSU,MLC等) 最適化してくれー
510 :11/10/31 もう荒らし認定していいか?
511 :11/11/01 >>508 単に古いデータを引っ張り出してきて 64bitソフトに読ませたい時に欲しいなーと思っただけ 使えるコーデックに再変換すりゃいいんだけど その度に変換するのもなんだかなと
512 :11/11/01 Proxy Codec 64
513 :11/11/01 >>512 前に試したけど使ってるソフトと相性悪いんで・・・ FourCCを変更しちゃう方が早いかな テストした限りは読めるようだけど
514 :11/11/15 10bit対応のコーデックまだー
515 :11/11/17 x264のロスレスでいいじゃん
516 :11/11/23 h.265のロスレスがどれくらい縮むか気になる・・・
517 :11/12/01 てs
518 :11/12/16 1.3.27
519 :11/12/16 >>518 Lagarithか。なんでお前はいつもバージョンだけしか書かないんだよw
520 :11/12/22 知ってると思うがUtVideo更新されてるな 微更新だがな
521 :11/12/23 >>520 乙
522 :12/01/03 中国の偽造技術は笑えるほどのものも。 とあるPC偽物語。 ある日、NERVに「このハードディスクに鉄道動画を全部転送したにもかかわらず、最後の方が尻切れしてしまっている。」との 依頼が入り、問題のハードディスクが届いた。その外付けドライブのネジを外して開封すると…。思わぬ展開となった。 実は、重さ稼ぎのための鉄の錘と、256MB程度の超小型のUSBメモリが入っているだけであり、USBメモリには怪しげなマイクロチップが張り付いていた。 それをNERVのパソコンにつなげて、認識させると、ハードディスクドライブとして認識するものの、容量は500GBと誤認識していた。 実は、あのマイクロチップは、容量を偽装するためのプログラムが入ったマイクロチップであるのだ。 USBメモリの容量がいっぱいになると、後ろの方から削除していく。ファイルの状況を調べないと発覚しにくい、
523 :12/01/03 キモイのが涌いたな
524 :12/01/05 Ut Video Codec Suite8.5.0から新しく10.2.2をインストールしたのですが AviUtlで見てみると10.2.2が反映されていない状態です。 再起動もしてみましたが同じでした。 10.2.2はバイナリと書かれているところから落としました。 Windows7 32bitです。 よろしくお願いします。
525 :12/01/05 こちらこそ
526 :12/01/05 >>524 うちもそんな感じで8.5.0までは正常 8.5.1以降すべてのバージョンが使えない 環境はWIndows7 64bit
527 :12/01/05 10.2.1の記事では 「Windows では、必ず旧バージョンをアンインストールしてから新バージョンをインストールしてください。」 という注意書きがあるな。 或るプログラマの一生 ≫ [UtVideo] バージョン 10.2.1 http://umezawa.dyndns.info/wordpress/?p=2991
528 :12/01/05 毎回アンインストールしてからバージョンアップしたんですけどダメになってしまったんです 以前vclistで確認した時のメモだと 8.5.0ではエンコーダはVCM、DMO、DirectShow、デコーダはVCMが表示されていて 10.0.2ではエンコーダはDMO、DirectShow、デコーダはDMOが表示されてる x86版、x64版共に同じ状態です。
529 :12/01/06 RGB24 → YUV444へは劣化なしで変換は無理って考えで良いですよね?
530 :12/01/06 RGBが8bitでYUVが12bit程度なら劣化はないよ
531 :12/01/06 始めまして。困ってどうしていいのか分からず2ちゃんねるで質問させていただきます。 aviファイルをaviutlで編集して圧縮をかけようと思うのですが、 いつものDivXへの変換だと結合とかしているうちに劣化してしまいます。 そこでut video codecという可逆圧縮コーデックで圧縮しようと思ったら、 圧縮してのに元のaviファイルの10倍くらいの大きさのファイルが出来上がってしまいます。 これがaviの出力画面 http://www.uproda.net/down/uproda421432.jpg 圧縮の設定です。これはいろいろチェックして試しましたが変わりません。 http://www.uproda.net/down/uproda421433.jpg いくら検索してもこれ以外の設定方法が分かりません。 どうかどうかご教授のほどよろしくお願いします。
532 :12/01/06 劣化がどうこうと能書き垂れる前に、まずは可逆圧縮と非可逆圧縮の違いを理解してこい
533 :12/01/06 可逆はそういうもん コーデックによって多少違うが、だいたい5分=1GBくらいだと思っておけ
534 :12/01/06 >>527 旧バージョンをアンインストールして もう一度入れてみたら無事成功しました。 ありがとうございました!
535 :12/01/06 >>530 なるほど!参考になりましたありがとうございます。
536 :12/01/06 8bitのYCbCrがRGB24(約1670万色)のうちどれだけの色を表せるかというと、 Rec601(圧縮レンジのBT.601)の場合→約296万色 PC.709(フルレンジのBT.709)の場合→約440万色 となるらしい。(ソースはツイッター) もっと詳しく知りたいのだけど、Rec709やPC.601、それと10bitなどのHigh bit depthでどうなるのかとか、 そのへんがまとまってるサイトってないのかな。
537 :12/01/06 またスレ作ってそこでやれよ そこらじゅうでするな
538 :12/01/07 >>536 601と709の差ってそんなにあるの?
539 :12/01/07 ut ver上がってた
540 :12/01/08 >>536 の件、発言した方がわざわざ色数計算して記事作って下さったので貼っておきますね。 Ch's barn: ConvertToRGB ttp://csbarn.blogspot.com/2012/01/converttorgb.html BT.601 TVレンジ(伸張) 2,956,082色 BT.601 PCレンジ(ストレート) 4,261,687色 BT.709 TVレンジ(伸張) 3,048,157色 BT.709 PCレンジ(ストレート) 4,400,772色 だそうです。RGB24(念のためPCレンジと書いておこう)は、16,777,216色。
541 :12/01/17 キャプチャをHuffyuv_mtからUtVideoに変えたのですが なぜかUtVideoだとシークバーでのスキップが出来ない・・・ スキップすると必ず再生アプリが固まります。 WinMediaPlayer11使ってるのですけど何が問題でしょか?
542 :12/01/18 ニコ厨が作った糞コーデックなんかいらん Lagarithでええ
543 :12/01/18 お前が着てる服や食べてる食事にもニコ厨の手が入ってるかもしれないから 服を着るのも食事をするのもやめたほうがいいかもしれんぞ。 日本はニコ厨が吐いた空気があふれてるから呼吸もやめないとやばいかもな。 生きづらい世の中になったもんだ。
544 :12/01/18 そもそも2ちゃんの創始者はいまやニコ厨だったりしてな まあでもニコ厨抜きにしても普通に生活は出来る気がするな
545 :12/01/18 ffmpegとかで読み込めないってところが問題ではあるがLagarithはいけるのかね
546 :12/01/18 UtもLagarithもavcodecは対応済みだろが Lagarithは基本設計が糞なせいかイマイチみたいだけど
547 :12/01/19 Lagarithはスキップ出来ました。 Huffyuv_mtより良い様なのでしばらく試してみます。
548 :12/01/19 Lagarithはエンコードもデコードも遅いからキャプチャ向きじゃないという認識だったんだけど いまどきのPCの性能ならキャプチャ時に使っても問題ないもんなのかな。 解像度とかにもよるんだろうけど。
549 :12/01/19 Pen4 3.4Gマシン時にSD解像度のキャプに問題なく使ってたよLagarith
550 :12/01/22 解像度にもよるがLagarithは圧縮率が高い分ドライブのI/O帯域によるオーバーヘッドが少ないから今時のCPUならほぼドロップしない ~~~~~~~~~~~~~~~~~
551 :12/01/23 LagarithやUtVideoなどの圧縮率重視のコーデックだと HDサイズのまま30fpsとかで録るのは今時のCPUでも厳しい
552 :12/01/23 CPUよかHDDがボトルネック
553 :12/01/23 PenG620とキャプチャ専用に日立の1Tプラッタ環境ですが、ドロップもなくキャプチャできてます。 その後、他アプリで試してみるとUtVideoでもハコ箱、GOMならスキップが出来ました。 比較もしてみたので参考にどうぞ。 ソース 実写-無圧縮1080i 30秒(900フレーム) ↑を各コーデックでエンコ(デコード速度優先設定) huffyuv_mt 1.24GB ut video codec 1.07GB Lagarith 802MB ↑をx264+AACにエンコ+インタレ解除。 huffyuv_mt 1pass(143.3秒) 2pass(133.2秒) 総エンコ終了(282.8秒) ut video codec 1pass(127.2秒) 2pass(112.9秒) 総エンコ終了(245.7秒) Lagarith 1pass(137.2秒) 2pass(123.4秒) 総エンコ終了(265.9秒) キャプチャー時のCPU使用率(1080i) huffyuv_mt 最大約60% ut video codec 最大約52% Lagarith 最大約75%(シーンによってよく動く)
554 :12/01/24 UtVideoは1920x1200 60fpsで余裕でキャプできたよ。Lagarithは60fpsに届かない。 CPUは3960Xでテスト。
555 :12/01/24 >>554 それは圧縮率とHDDの転送速度がボトルネックっぽいな
556 :12/01/24 >>555 Lagarithのほうが縮むよw SSD複数使って糞速い環境なんで書き込みのボトルネックは無い。 つーか無圧縮で保存できる環境だぜ。
557 :12/01/24 キャプチャ用のドライブはクラスタサイズを32Kや64Kでフォーマットしてる
558 :12/01/24 その解像度、fpsでx264可逆キャプチャしてみようぜ
559 :12/01/24 キャプチャドライブのファイルシステムはexFATが適しているとMicrosoft自身が言ってる クラスタサイズ128KBだから断片化しにくい http://support.microsoft.com/?kbid=955704 >exFAT ファイル システム ドライバーには、パフォーマンスを向上させるために、次の高度な構造が組み込まれています。 > > クラスター ビットマップ高速の割り当て > ファイルあたりの連続した少し高速のファイルへのアクセス > 優れた連続したディスク上のレイアウト (便利映画を録画用)
560 :12/01/26 >>559 OSが落ちたらスキャンディスク実行しなきゃいけなくない? その分高速だろうけど
561 :12/01/26 http://karinto2.mine.nu/blog/kuni/2011/09/-monsterxx-2.html Ut Video+i7-860でCPU使用率30%、35~45MB/s らしいけど 同じ映像をキャプチャーするとしたら2700K+MSUとかYULSみたいな激重コーデックだと どれくらいのCPU使用率、ビットレートになるんだろうか
562 :12/01/26 とりあえずMSUは絶対無理だな
563 :12/01/26 x264vfwのlosslessでキャプチャーしたほうがマルチスレッド対応という意味で良い希ガス
564 :12/01/28 AMVってどうなの金払って使う価値あるの?
565 :12/01/28 >>564 ロゴが入るとはいえ無料で落とせるんだから自分で試してみればいいだろ。価値基準なんて人それぞれだ。
566 :12/01/29 output cspで4:2:0以外の色空間の指定出来るx264のコーデックってありせん? x264vfwで可逆キャプチャしてるのですがoutput cspのコマンドに対応してないらしくエラーになります(amarecoco系列とdxtoryは試した)
567 :12/03/19 UtVideoを問題なく使用できていたWindows7 x64に Microsoft Windows Media Video 9 VCM をインストールしたら それ以降UtVideoが正常にデコードできなくなった。 デコードしようとするとWindows全体がビジーになって アプリが応答なしになる。 動画の再生時間分だけの時間が経過したらもとに戻るけど。 Microsoft Windows Media Video 9 VCM をアンインストールしたら、UtVideoは元通り正常に使用できるようになった。 MS公式コーデックが悪さするってなんなの???
568 :12/03/19 他社を排除するMSのいつもの手じゃん
569 :12/03/19 >>567 最近はLAV FiltersにUtVideoのデコーダーが入ったりしてるけど、そういうコーデックパックとか入れたりしてない? あと、UtVideoは10.2.1からインストーラが変わって、 「Windows では、必ず旧バージョンをアンインストールしてから新バージョンをインストールしてください。」 と記載されてたけど、上書きインストールを続けておかしくなってるってことはない? それとUtVideoのバージョンや、使ったプレイヤーなんかも書いたほうがいいと思う。
570 :12/03/19 >最近はLAV FiltersにUtVideoのデコーダーが入ったりしてるけど、そういうコーデックパックとか入れたりしてない? してない もともとはUtVideo以外まったく何も追加コーデック入れてなかった んでそこにWMV9入れた途端におかしくなった >あと、UtVideoは10.2.1からインストーラが変わって、 問題なく動いてて不満がなかったので、9.8.?ぐらいのをずーっと使い続けてた その状態にWMV9入れたらおかしくされた WMV9アンインストールしても微妙にまだおかしいので、Windows7自体を再インストール せんといかんかもしれんな めんどっくさ
571 :12/03/19 >>567 Microsoft Windows Media Video 9 VCM は Windows7 では動作保障外 Microsoftはインストールするなと言っている
572 :12/03/19 Microsoft Windows Media Video 9 VCMって、日本語のダウンロードページ消えちゃったよね。 英語ページからはまだダウンロードできるみたいだけど。
573 :12/03/20 >>571 まじで? まったくそんな注意でてこなかったわ注意出て来なかったわ >>572 んー? MSトップから探さずにGoogleの検索窓にワード入れて出てきたリンクリンク クリックしたら普通の日本語ダウンロードページが出てきたからなんの疑い もなく入れちゃったわw
574 :12/03/20 >>573 Microsoft Windows Media Video 9 VCM の替わりに Microsoft Expression Encoder 3 をインストールしろってさ
575 :12/03/20 >>574 ありがとう でももう9 VCM入れてそのせいでWindows全体おかしくなっちゃったんで、 再インストールします…… そのあとで、もしWMV9コーデックを扱いたくなる時が出たらそちら入れますね 当面入れないと思う 今回必要になったのイレギュラーだし
576 :12/03/20 >>570 DirectShowは次々にコーデックをロードして目的のフォーマットを扱えるか 試す仕組みになってるから、動作しないコーデックがインストールされると 他のフォーマットも影響受ける可能性があるよ。 >WMV9アンインストールしても微妙にまだおかしいので、 アンインストールした後再起動してみた?
577 :12/03/24 ぼくちんずっとhuffyuv2.1.1 誰か今のトレンドおしえて
578 :12/03/24 huffyuvも普通にアリだとは思うけど、個人的にはUtVideoかな。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
【工夫披露】GV-MVP/RZシリーズ Part5【経験結集】 (229)
USB地デジチューナ DY-UD200 Drop26 (910)
x264 rev36 (176)
2011年10月、12年4月に始まる新BS準備情報スレ2 (449)
SKnet MonsterTV HDU/HDPシリーズおよびOEM製品総合 9 (249)
【BDAV】BDをRipして楽しむスレ Vol.48【AACS】 (134)
--log9.info------------------
全国どこからでも「@niftyアクセスナンバー」開始 (600)
NIFTY板正常化 自治ルール作成スレッド 2 (542)
「ココログ」あります part3 (441)
オフで好感もてたCBerの方 (100)
ニフ者以外ってどのくらい? (102)
迷惑なオフ参加者 (229)
もし2ちゃんねるフォーラムが出来たら (118)
こんにちは現役SYSOPです。 (333)
#8(スピリッツ)のあひるさんって・・・・・。 (490)
■警警警■メールを盗聴すると逮捕される (225)
バソ通初体験の思い出を語れ (118)
どの フォーラムが女を 喰いやすいのでしょうか? (106)
CR あさみん♪ マンセー!! (159)
CBシュミレータB1 (158)
機動戦士ガンダム めぐりあいBBS#8編 (309)
BBS#8 「お題・僕たちの失敗」 (309)
--log55.com------------------
演ドルから第二のあややを! 若手女性歌手応援スレ
【うなり節】都はるみ応援スレッド【はるみちゃん】
紅白出場者予想スレ 2
【ハスキー】青江三奈を語るスレ【ボイス】
団塊世代がいなくなる頃には演歌も終わる
=■☆●市川由紀乃さん復帰してほしい!●☆■=
紫艶スレ
【美熟女】石原詢子【48歳】