5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

映像可逆圧縮総合スレ Part3

1 :名無しさん@編集中:2009/07/10(金) 23:30:30 ID:fN2fpFAc
映像可逆圧縮関連総合スレです

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 :名無しさん@編集中:2009/07/10(金) 23:31:57 ID:fN2fpFAc
代表的なコーデック

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 :名無しさん@編集中:2009/07/10(金) 23:39:42 ID:bNoGr+fc
これはポニーテールがどうのこうの乙

4 :名無しさん@編集中:2009/07/10(金) 23:55:01 ID: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 :名無しさん@編集中:2009/07/11(土) 02:38:34 ID:pFoS72j8
姉妹スレ
音声可逆変換ソフト総合スレ  
http://pc12.2ch.net/test/read.cgi/software/1219683003/

6 :名無しさん@編集中:2009/07/11(土) 12:00:54 ID:ZxM3rHxN
いちおつ

7 :名無しさん@編集中:2009/07/12(日) 17:54:59 ID:liD92ixO
いちおつ


8 :名無しさん@編集中:2009/07/13(月) 21:59:32 ID:vKALAP3e
1乙

ところで、みんなは、どのコーデックを利用しているの?




9 :名無しさん@編集中:2009/07/13(月) 22:42:29 ID:b8+h8Hrb
UtVideo だけど、AMV3を買ってみようかと思ってる。
AMV3早そうだし。

10 :名無しさん@編集中:2009/07/13(月) 23:15:53 ID:lqncRqXI
俺1ペタあるから使わないよ

11 :名無しさん@編集中:2009/07/14(火) 00:11:38 ID:EQiGyFdV
>9

どっちが高速化教えてくれい。

UtVideoはインタレ使えないのがネックだな・・・。

12 :名無しさん@編集中:2009/07/14(火) 00:42:37 ID:KljUSiE6
>>11
アマレココのページに計測データが載せられている。
自分で測るとしたら……どうすりゃいいんだ?

13 :名無しさん@編集中:2009/07/14(火) 01:50:18 ID:6zuJPRSn
Utおいてるとこにある速度計測器でも使ってみたら?

14 :名無しさん@編集中:2009/07/15(水) 20:34:18 ID:koqEFiNP
http://xrowcc.blog.shinobi.jp/Entry/388/
俺は試すのめんどい

15 :名無しさん@編集中:2009/07/15(水) 23:38:56 ID:BPTRTu3m
[UtVideo] バージョン 5.3.0
機能追加
ULY0: エンコード時に YUY2 で入力できるようにした。とりあえず作っただけなので、YUY2 入力時のエンコードは遅い。
ULY0: デコード時に YUY2 で出力できるようにした。とりあえず作っただけなので、YUY2 出力時のデコードは遅い。

16 :名無しさん@編集中:2009/07/16(木) 00:27:56 ID:CRacHsO+
作者が報告してくれてるの?
それとも誰かが瞬時に発見してるの?

17 :名無しさん@編集中:2009/07/16(木) 01:54:11 ID:3r6OoiT2
RSSでチェックしてるとか。>>14は変更点も書いてないから試す気も起こらないな・・・

18 :名無しさん@編集中:2009/07/16(木) 22:36:54 ID:jE1TH4Nj
[UtVideo] バージョン 5.3.1
バグ修正
ULY0: フレーム分割の方法が間違っていた。

19 :名無しさん@編集中:2009/07/17(金) 06:08:32 ID:W/lH9T6n
絶対宣伝誌に来ると思ってたが案の定宣伝に来たなw
死ねクズ

20 :名無しさん@編集中:2009/07/17(金) 09:28:17 ID:Mc0/KUnU
>19

バカいってんじゃねーよ。
せっかく報告してくれてんだよ。おまえがどけ

21 :名無しさん@編集中:2009/07/17(金) 15:33:32 ID:gpWFfHtG
>>18
報告たすかる
重大なバグがあったのかな?

22 :名無しさん@編集中:2009/07/17(金) 16:00:53 ID:EQKFczPl
自分でもアンテナ登録してるからなくても困らないけど報告はありがたいね。

23 :名無しさん@編集中:2009/07/18(土) 04:56:27 ID:KSAgM6f+
酷い自演

24 :名無しさん@編集中:2009/07/20(月) 13:54:28 ID:tIV1kpEO
自分でちょっと試したらエンコデコともにAMV3よりUtの方が早かったな。
Athlon X2, ULY0とAMV3可逆標準で。

25 :名無しさん@編集中:2009/07/20(月) 19:52:16 ID:3TQze3re
アマレコ使う場合はAMV3使わないとコマ落ち増える
AMV3はアマレコキャプ専用

26 :名無しさん@編集中:2009/08/08(土) 20:39:45 ID:Xk0rsFc/
やたらと最近(キャプチャ開始してから十分前後で)コマ落ちする。
UtvideoからHuffyuvMTに一回戻してみたけど、状況変わらず。
HDDの空き容量が影響しているのかと、CMカット編集済みの動画を消しても同じ。

くすのきの再生フレームレートが30フレーム近くからじりじり(22フレームくらいまで)
下がっていくので、HDD周りのデバイスドライバを調べなおしたら、
なんか認識されているデバイスドライバが足りてなかった。

いったん削除して、完全に電源を落として再起動して認識させ直したら、
nForceのRAIDドライバがプライマリとセカンダリも認識されなおしたので、再度キャプチャ中。
再生フレームレートは27フレーム前後で特に変化無し。

たぶん問題解決しました。

27 :26:2009/08/08(土) 20:43:02 ID:Xk0rsFc/
あと、5.3.1まであげて、圧縮率優先→デコード速度優先もやりました。おかげで動画サイズが
2割くらい膨れ上がって、HuffyuvMTと変わらなくなってしまった。

28 :名無しさん@編集中:2009/08/08(土) 20:56:35 ID:cv/UFt48
日記はチラ裏にどうぞ

29 :名無しさん@編集中:2009/08/09(日) 11:01:58 ID:LDw9MPm8
つうかコーデックと全然関係無い話じゃん

30 :名無しさん@編集中:2009/08/09(日) 17:09:33 ID:Zptsww4i
[FFmpeg-devel] [PATCH][RFC] Lagarith Decoder.
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073903.html

31 :名無しさん@編集中:2009/08/10(月) 15:49:47 ID:xfd/aHgY
外国の厨が出したパッチ自体より、それにつけられたコメントの方が読むと面白い。

32 :名無しさん@編集中:2009/08/10(月) 20:38:36 ID:/ajxPb3p
正規のVFW Codecがあるのにわざわざffmpegに組み込む必要性ってなに?

33 :名無しさん@編集中:2009/08/10(月) 20:47:18 ID:oeD7oq/t
ffmpegやMPlayer/MEncoderでそのまま扱えるようになるだろ
あそこらへんは現状ではffvhufかffv1しか可逆の選択肢がない
menc2vfw使わないですむなら、それにこしたこともない

34 :名無しさん@編集中:2009/08/10(月) 23:25:33 ID:/ajxPb3p
>33
menc2vfwってなに?
ググっても出てこない。コマンドラインからVFW codecでエンコ出来るのかな?

35 :名無しさん@編集中:2009/08/11(火) 00:11:32 ID:swlvLeeq
>>34
ああ、ごめん、vfw2mencだった
できることはその通り
本来win用のvfwコーデックをLinux上で使うためのもの
そもそもVirtualDubやAviSynthがネイティブで動くwindowsではたいして意味はない

36 :名無しさん@編集中:2009/08/19(水) 00:54:34 ID:4ycnQf3l
インターレースの映像を、インターレースを保持したまま可逆圧縮できるコーデックは、
Huffyuvくらいなものなんでしょうか。
Ut Videoは、YUV420でのインターレースは非対応らしいですが、
YV12でのインターレースは、どうなんでしょう?
Lagarithはググってみたら、海外の掲示板では、どうも対応してないようなことが書いてありましたが、
最新版の1.3.20でも非対応で合ってますか?

37 :名無しさん@編集中:2009/08/19(水) 01:58:44 ID:Jj3NpY1w
基本的に同じフォーマットで圧縮・展開すればいいよ

RGB←→YUY2 変換ロス発生
RGB,YUY2←→YV12 変換ロス、インタレ変換の影響

huffyuvのインターレース対応はmethod gradient,medianで1つ上のラインを参照するから
横幅を2倍とみなして偶数・奇数ライン同士を参照するようにして圧縮率を上げている


38 :37:2009/08/19(水) 02:21:40 ID:Jj3NpY1w
補足
コーデックの圧縮前の内部フォーマットと異なるフォーマットで入出力すると変換ロスが発生するので
内部フォーマットと同じフォーマットで入出力すればいいよってこと


39 :名無しさん@編集中:2009/08/19(水) 03:22:49 ID:le/T8EuZ
AMV2MT/AMV3がYV12に対応していたと思う。

40 :名無しさん@編集中:2009/08/19(水) 06:59:06 ID:XPfwaRax
>>36
YV12に対応している物なら、FFV1, Lagarith, UT Video等、何でも良い。

41 :名無しさん@編集中:2009/08/19(水) 07:05:56 ID:XPfwaRax
ただ、AviUtl等を使って、YUY2->YV12をやると、縞が崩れてしまうから、
VirtualDubのFast recompressやavs2aviを使う必要は有る。

42 :名無しさん@編集中:2009/08/19(水) 20:18:26 ID:aHU8eYju
インターレースYV12をリサンプリングせずにそのまま可逆圧縮するだけなら
インターレースの対応可否は関係ないよ。

43 :名無しさん@編集中:2009/08/20(木) 04:06:41 ID:mwrVmBoK
フィルタかけるとつぶれるけどな。

44 :名無しさん@編集中:2009/08/20(木) 11:38:05 ID:xdEasAih
フィルタかけるのはリサンプリングに相当するぞ>>43

45 :名無しさん@編集中:2009/08/31(月) 19:53:59 ID:R2HQP1/H
UtVideo6ってバグ?

46 :名無しさん@編集中:2009/09/01(火) 03:55:31 ID:yq1sIvN4
Visual C++のランタイム絡みらしい。6.0.0のコメント欄に報告がある。

47 :名無しさん@編集中:2009/09/07(月) 23:53:25 ID:mNGHLuXA
[UtVideo] バージョン 6.0.0
 共通: インターレース映像に対する特別な処理を追加した。
 ※インストール関連のバグあり

[UtVideo] バージョン 6.0.2
 ダイナミックリンクからスタティックリンクに変更した。
 ※インストール関連のバグ解消(と思う

48 :名無しさん@編集中:2009/09/11(金) 11:26:04 ID:TA3md0y2
エンコード作業をオールx64化したいのですが
現状でx64ネイティブなマルチスレッドな可逆圧縮コーデックって何がありますか

49 :名無しさん@編集中:2009/09/11(金) 11:34:47 ID:zUQPI7it
>>48
Lagarith

50 :名無しさん@編集中:2009/09/11(金) 14:56:39 ID:utqU+W3s
動画エンコ的にはx64のメリットはほとんどないよね・・・

51 :名無しさん@編集中:2009/09/11(金) 15:36:49 ID:MLOD8Eeh
そうでもない
たとえば複数のエンコを同時進行する場合は、メモリ4GB超の恩恵はある
この前同時に3本のavsを中間出力(フィルタの都合上、MTなし)したが、メモリ使用量5GBで楽勝でした
そのほかにも32ビットに比べてインターフェース周りとかは強化されてるから、32ビットのアプリでも、
そのもののスピード自体は多少遅くなるが、結果的には変わらないか若干速くなったりすることもある。
言ってみれば車速自体は遅くなったけど、道が走りやすくなったんで、タイムは縮んだみたいなかんじ

52 :名無しさん@編集中:2009/09/11(金) 15:57:58 ID:NDkHkDKt
x264なら64bit版で32bitより1割以上早くなるよ

53 :名無しさん@編集中:2009/09/11(金) 16:02:24 ID:MM1QHSKc
32bitでもRAMDISKにスワップ置けばトータルメモリ量は増やせるけど、
1アプリ2GB(拡張して3GB)の制限有るから、
フルHDサイズとかでフレーム参照系のオプション増やしてるなら64bitの方が良いな

54 :48:2009/09/11(金) 16:33:31 ID:TA3md0y2
>>48
早速ありがとうございます
Lagarith Codec (v1.3.20)
Lagarith_1315dev_SSE2.7z
Lagarith_1315dev_SSE2_719.7z
を試しました
しかし、こいつ重たいですね ^^;
Phenom9600ではドロップでまくりでD3キャプチャーできませんでした
改めてhuffyuv_mtの軽さを思い知りました
もう少しあがいてみます

55 :名無しさん@編集中:2009/09/11(金) 17:34:13 ID:utqU+W3s
x64は対応してるのは本家のだけだと思うけど。x64でキャプできるものもあるのかな。
他の64bitもの
ttp://members.optusnet.com.au/squid_80/

56 :名無しさん@編集中:2009/09/11(金) 22:13:05 ID:x4gklbuc
avisynthのフィルター類って32bitだとおもったけど
avsを64bitのx264でそのままエンコってできるの?

57 :名無しさん@編集中:2009/09/11(金) 22:16:11 ID:4PboHS/L
>>56
http://forum.doom9.org/showthread.php?p=1234822

58 :名無しさん@編集中:2009/09/11(金) 22:40:37 ID:x4gklbuc
Thanks!

59 :48:2009/09/12(土) 00:02:09 ID:XDggAEB5
>>55-56

書き方が足りませんでした
キャプはx86で行います
で、先ほどのLagarithはx86でのキャプチャー時の負荷です
>>57のツールではなくx64 avisynth の使用を前提で考えていたので
x64側のネイティブなデコーダーも必要と考えました
とりあえず、huffyuv-2.1.11のシングルスレッドでギリギリでキャプチャーできるようですので
それでしばらくは対応したいと思います。
ご回答くださいました方々ありがとうございました

60 :名無しさん@編集中:2009/09/12(土) 01:47:49 ID:lzAc4G8X
CUDA使って圧縮するコーデックって出れくれないかな。

61 :名無しさん@編集中:2009/09/17(木) 01:34:55 ID:YVdBLtKa
完全に中間圧縮専用だな。

ところでUtも64bit対応目指すらしいな。
いつだかこのスレで騒いでたやつを思い出しちゃったよ。
彼の人にAMD64bit機を送りつけたらAMDの最適化もやってくれたりするんかな。

62 :名無しさん@編集中:2009/09/17(木) 15:13:01 ID:z4nn4nb7
win7発売と同時か。後はキャプチャーソフトと編集ソフトが対応増えるのを期待かな。

63 :名無しさん@編集中:2009/09/22(火) 02:02:47 ID:N22kbizu
Huffyuv_mt_712を導入する際はhuffyuvは一度アンストしたほうがいいんですか?

64 :名無しさん@編集中:2009/09/22(火) 03:05:53 ID:RYQswv0a
別物だからそのままでいい

65 :名無しさん@編集中:2009/09/22(火) 19:02:21 ID:tbDl/Bm0
>>63のHuffyuv_mtならFourCCがHYMTに変更されてるから共存できる。
ちなみにLagarith1315のMT改造版はFourCCがオリジナルと同じなので共存できない。


66 :名無しさん@編集中:2009/09/23(水) 01:13:07 ID:+NUZWci6
huffyuvのアンストの仕方わからない俺涙目。ぐぐる先生にもそれっぽいのないし

67 :名無しさん@編集中:2009/09/23(水) 01:26:57 ID:NJYeobWO
>>66
これで上書きできれば、アンインストールできるかも。

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

68 :名無しさん@編集中:2009/09/23(水) 12:29:32 ID:C3X3eKtK
そんな不具合があったのか・・・。
「アプリケーションの追加と削除」から削除できそうだけど、失敗するのか・・・?

69 :名無しさん@編集中:2009/09/28(月) 02:24:58 ID:YkLnYQn6
IgCodec v1.0.0
ttp://xrowcc.blog.shinobi.jp/Entry/434/
使うメリットはないけど一応報告


70 :名無しさん@編集中:2009/09/28(月) 04:45:45 ID:pQWbgXJF
>>69
LZ系か。ならQuickLZ使うべきだったろうにjk
そこの作者は情報に疎いな何時も

71 :名無しさん@編集中:2009/09/28(月) 12:11:04 ID:rGlIueIL
>>70
QuickLZはGPLだからじゃない?

72 :名無しさん@編集中:2009/09/29(火) 12:12:35 ID:ZgHXZEtw
>>69
試しに使ってみたけど、
・・・うん、なんだ、UtVideoのままでいいや。

73 :名無しさん@編集中:2009/09/29(火) 18:54:25 ID:ekIvIRmS
-------------------------
 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 :名無しさん@編集中:2009/09/29(火) 18:56:05 ID:ekIvIRmS
■結果

  ※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 :名無しさん@編集中:2009/09/29(火) 18:56:48 ID:ekIvIRmS
■その他

 ※多分バグだと思うけど、うちの環境だとファイルを選択すると
   Explorerが落ちる。どうもサムネイル作成で落ちてるっぽい。
   ただ、1秒くらいの動画をエンコした場合は問題なかったので、
   何かしらの発生条件があるのかも。

 ※上にも書いたが今のところ内部形式がYUV4:2:2(UYVY)なので、
   RGBソースの場合はRGB→YUV変換による劣化が発生する。

76 :名無しさん@編集中:2009/09/29(火) 19:18:45 ID:Ieor7Wy0
utもx64対応になったらvctestもx64対応になるかな。

77 :名無しさん@編集中:2009/09/29(火) 19:19:09 ID:0h0Jhy//
データを複数台のPCに移動しながら作業したいんだが、
・圧縮率をなにより優先
・RGB色で出力可能(YUVはダメ)
・速度も……悲惨じゃないよ

って条件に合うCODECを調べてくれる変態な人いませんか?
変態じゃなくても構いません

78 :名無しさん@編集中:2009/09/29(火) 19:21:05 ID:kzMvJ+7y
>>77
FFV1

"ffmpeg -vcodec ffv1"とするか、ffdshowのVfWから使う。

79 :名無しさん@編集中:2009/09/29(火) 19:29:13 ID:Ieor7Wy0
こことか参考に
ttp://amalabo.blog35.fc2.com/blog-entry-44.html
RGBだとどうだったかな・・・

80 :名無しさん@編集中:2009/09/29(火) 19:35:28 ID:ekIvIRmS
〜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 :名無しさん@編集中:2009/09/29(火) 20:06:48 ID:lKaknEdC
>>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 :名無しさん@編集中:2009/09/29(火) 20:15:20 ID: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 :名無しさん@編集中:2009/09/29(火) 20:22:49 ID:lKaknEdC
ふむ。UTはRGB特殊扱いが無いし、ハフマンだしでFFV1に圧縮率で勝る点は無い。
強いて言えばpredictionが二種あることだが、これがどう影響しているかは分からね。

84 :名無しさん@編集中:2009/09/29(火) 20:34:43 ID: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 :名無しさん@編集中:2009/09/29(火) 20:57:34 ID:kzMvJ+7y
http://compression.ru/video/codec_comparison/pdf/msu_lossless_codecs_comparison_2007_eng.pdf
少し古いが、これはとても参考になる。

キャプチャー等で速度優先ならUT Video、保存に使うならFFV1が良いと私は思う。

86 :名無しさん@編集中:2009/09/29(火) 20:58:23 ID:0h0Jhy//
ご意見ありがとうございます。

色々考えた結果、
UT出力→7z圧縮で移動→出先で解凍
が一番効率がよさそうでした。


7zの繰り返しデータ圧縮効率は異常

87 :名無しさん@編集中:2009/09/29(火) 21:00:43 ID: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 :名無しさん@編集中:2009/09/29(火) 21:27:48 ID:lKaknEdC
謎っていうか16bit処理(-0xffから0xff)してるだけか。
確かに8bitで処理するより圧縮率は高くなるな。

89 :名無しさん@編集中:2009/09/29(火) 21:59:49 ID:lKaknEdC
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 :名無しさん@編集中:2009/09/29(火) 22:18:47 ID:kzMvJ+7y
H.264のmatrix_coefficientsが8になっていたら、YCgCo
どの実装が、これのエンコード/デコードに対応しているのかは知らない。

91 :名無しさん@編集中:2009/09/29(火) 22:20:03 ID:kzMvJ+7y
YCgCo-> YCoCg

x264のヘルプを見ながら書いていたら間違えた。

92 :名無しさん@編集中:2009/09/29(火) 22:24:20 ID:kzMvJ+7y
再度訂正

T-REC-H.264-200711-I!!PDF-E.pdfにもYCgCoとあるから、間違いではなかった。

93 :名無しさん@編集中:2009/09/29(火) 22:26:26 ID:sZT/EUiQ
>>80
調査乙です。

Igの人のブログ見ると改良していくつもりでもなさそうな感じだし、
Utから乗り換えする必要ないっぽいかなぁ。

>>89
YCoCg…YCbCrとYPbPrの違いもよく分かってないのに他にもあるのか…。

94 :名無しさん@編集中:2009/09/29(火) 22:44:48 ID:1EoSCOp3
igCodecがVistaUltimate(x86)でインスコできないんだが解決策わかる人いる?

95 :名無しさん@編集中:2009/09/29(火) 22:46:51 ID:1EoSCOp3
ごめん。XP専用だったのね。公式読んでなかった
ちょっと死んでくる

96 :名無しさん@編集中:2009/09/29(火) 23:07:48 ID:Z/jyKhJv
YCoCgはRGBと無劣化に相互変換できるフォーマットでYUVと同じように
輝度信号と色差信号で記録される。H.264のHigh444 Profileの対応色空間として
利用できる。

97 :名無しさん@編集中:2009/09/30(水) 13:26:01 ID:BHN0iqo3
後発ならどこか一部でも利点のあるもの出さなきゃ

98 :名無しさん@編集中:2009/09/30(水) 20:13:55 ID:2BxbpfIO
商用利用可能

99 :名無しさん@編集中:2009/09/30(水) 23:32:14 ID:fAtGr6DR
別に商用利用はGPLのHuffyuvやFFV1やUtでも可能だろ
ただ金払うやつがいないってだけで

100 :名無しさん@編集中:2009/10/01(木) 16:35:16 ID:XI2cN2lf
FFV1はLGPLでも使えるな。

101 :名無しさん@編集中:2009/10/03(土) 03:48:13 ID: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ファイルをバイナリエディタで開き、最初のほうにある2箇所のFOURCCを、
実際には存在しない「PGRW」に書き変えてみたのですが、
それも何故かAVI Decompressorが呼び出され、デコードしようとしてました。


>>75で書いた「サムネ表示で落ちる」という問題も、他では聞きませんし、作者さんの環境でも再現しないそうです。
IgCodecの問題ではなく、うちの環境がおかしいか、インストールに失敗しただけなのかもしれません。
考えてみればインストール直後は特に問題を感じてなかったし、途中で何か変になったのかなあ・・・。

当たり前ですがアンインストールすれば上記の現象は発生しなくなりましたが、
別の環境だとどうなのかなというのが気になりまして。

102 :名無しさん@編集中:2009/10/03(土) 03:50:22 ID:BdY8uk7N
ちなみにアンインストールする前にPCの再起動を試したのですが、それでもダメでした。

103 :名無しさん@編集中:2009/10/03(土) 11:02:39 ID:z8/v/gVI
>>101
ICDecompressQueryで拒否されれば別のフォーマットのデータで再生しようとはしないはず。
コーデックのチェックが甘いんじゃないの?

試しにUtVideoのソースいじってICDecompressQueryでICERR_OKを返すようにしたら
mplayerが落ちるのを確認できたよ。元に戻すと落ちない。
ただ、設定によっては再現しない時があったけど。



104 :101-102:2009/10/03(土) 22:58:14 ID:DN2WbC/Y
>>103
うおぅ、なんか実装レベルな詳細ktkr。
ググってもよくわからんかったのですが、「これをデコードできる?」って問い合わせに対して、
IGC1がなんでもかんでも「できるよー」って答えてるということでしょうか。
GraphEditで見てみましたが、とにかくビシバシAVI Decompressorが呼び出されてました。
とりあえず再インストールしても発生したので、環境依存の可能性も含めて報告だけしてみます。

あと別スレで出てましたが、上下反転したり、RGB圧縮してYUY2展開すると崩壊が起きるというバグがあるようです。
うちでも再現しました。

105 :名無しさん@編集中:2009/10/03(土) 23:44:41 ID:iriEy1HH
>>104
AVIDecompressorはレンダラからのDirectShowの動的フォーマット変更の要求を受けるよ。
旧レンダラだとYUVのデコードが出来ない古いビデオカードのために、最初はRGBで表示して
途中からYUY2に変えたりする。
BI_BITFIELDなんかも渡されるし、負のHeightも意味がわからなければとりあえず拒否すればいいよ。


106 :104:2009/10/04(日) 01:00:09 ID:V8/7yfvT
>>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 :名無しさん@編集中:2009/10/04(日) 08:05:16 ID:5wypKd+0
>VP62でエンコードしたAVIが
これはyuvの負数Heightの問題よりvp6とvp6fの問題な可能性が高そうな。

108 :名無しさん@編集中:2009/10/04(日) 17:44:05 ID: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 :名無しさん@編集中:2009/10/04(日) 22:03:41 ID:0dUriZIT
>>106
AVI File Reader(Video For Windows)ではRGBで読み込まれて
AVI/AVI2 File ReaderではYUY2で読み込まれてない?
その場合はAviutilのコーデックの設定でYUY2の展開のチェックを外してみて。



110 :名無しさん@編集中:2009/10/05(月) 00:47:11 ID: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 :名無しさん@編集中:2009/10/05(月) 01:02:46 ID:73HmhB9t
FFVideoSource("VP62.avi") とすれば良い。

112 :名無しさん@編集中:2009/10/05(月) 03:54:53 ID:J7D85f9c
>>110
ええと。vp6fというのはflashに使われるvp6コーデックの"ffmpegでの"呼び名ね(fourccではない)。flashに使われるvp6は普通のvp6と上下が反対という仕様になってる。
普通のvp6のfourccはVP60, VP61, VP62。
この辺の処理をちゃんとしてなかったり、間違ってたり、強引にやってたりすると上下反対のができる。

113 :名無しさん@編集中:2009/10/05(月) 04:15:34 ID:J7D85f9c
って勘違いかも? ffmpegのriff.cにあるからfourccだねぇ>VP6F
on2のデコーダは対応してなかった記憶があるが、その辺の経緯忘れた。

114 :名無しさん@編集中:2009/10/05(月) 04:22:15 ID:aD/0mvDP
VP6の話になったらもうスレ違いだよなあ

115 :名無しさん@編集中:2009/10/05(月) 23:24:18 ID:sJ9QMwh6
最強可逆コーデック MSU Screen Capture Lossless Codec
http://replaymugen.seesaa.net/article/93730113.html

わかりやすかった


116 :名無しさん@編集中:2009/10/05(月) 23:56:01 ID:cYQUrplO
>>110
普通のユーザーは覚えなくても全く問題ないよ。

入力のFourCCについては、ff_vfwが有効になっているフォーマットを全て登録しなくても
再生可能な仕組みでもあるので、チェックが必要。

コーデックに負の高さが渡されるのは、通常はレンダラが用意したDirectXの
サーフェイスであることを示す目印で、RGBでもYUVでも「トップダウン」なので、
コーデックが入力フォーマットの幅と高さを使って処理しているとRGBが反転してしまい、
また、上下反転の意味と捉えるとYUVが反転してしまうというわけ。

VP6がどうだったのかは知らないけど、登場した頃の主な編集ソフトがYUV対応
していなかったりすると、YUVの向きに混乱があっても特に問題ならなかったんだと思う。。

ってことで、Aviutilのコーデック設定でVP6のYUY2圧縮を外してエンコードしたらどうなるの?
反転しなければフォーマットの問題ではなく、on2のコーデック自体の仕様で、VP6Fはon2の
仕様に合わせたものってことでは?


117 :名無しさん@編集中:2009/10/07(水) 02:02:55 ID: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 :名無しさん@編集中:2009/10/07(水) 02:38:14 ID:nCX90d4i
いや、VP6FはflipされたVP6だよ。

flvコンテナではvp6だけが何故かflipされてる。
それでflvからaviへの無変換詰め替えのときに困るってんで、'VP6F'というfourccが生まれた。
ffmpegが対応する前の話。

119 :名無しさん@編集中:2009/10/07(水) 08:08:54 ID:Dm53UpbC
>>118
ffmpegが作ったんじゃないなら、VP6Fってのはどこが決めたFOURCCなんだろ?

120 :名無しさん@編集中:2009/10/09(金) 22:36:33 ID:pLFH6L7x
IgCodecの圧縮どんなもんか試してみたらサムネ作成らしきタイミングでExplorerが落ちるんでググってやってきました
>>101によると作者環境でも再現せず他の報告もないそうなので諦めて帰ります
XPSP3/C2Q9300@400x6.0/RAM3G+RAMDisk3G
編集・圧縮に使ったソフト:VirtualDubMod 1.5.10.2

121 :名無しさん@編集中:2009/10/19(月) 08:03:36 ID:2bV4/Fnc
あまラボで64bitアプリから32bitコーデックを扱えるようにするプロキシコーデックを公開予定になってる。
ほかの32bitコーデックも64bitアプリで使えるらしい。aviutl出力プラグインのmm_srvみたいなものなのかな。
他のコーデックで使うメリットはあんまりないのかなーと思うけどどんな感じだろうね。

122 :名無しさん@編集中:2009/10/19(月) 14:06:16 ID:sqrOs7Z+
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 :名無しさん@編集中:2009/10/19(月) 17:24:23 ID:zOAGhtLu
64bitで動くエンコードソフトって、VirtualDubのx64版以外だと何があるだろう?

124 :名無しさん@編集中:2009/10/19(月) 17:55:01 ID:Ki8xBX4/
x264 64bit版
32bit版より1割以上速くなるよ

125 :名無しさん@編集中:2009/10/19(月) 18:13:59 ID:sqrOs7Z+
avidemuxも64bitで動くよ。但しwindows向けの64bitビルドはまだ無いようだけど。

126 :名無しさん@編集中:2009/10/19(月) 18:31:19 ID:x0S6Hz/t
肝腎のAviSynthの64bit化が進まないとどうにもねぇ
2.6で64bitバージョンも正式リリース&32bitは開発終了とかやってもらわんと

127 :名無しさん@編集中:2009/10/19(月) 20:16:43 ID:UknK+UXf
可逆じゃなくてスマヌ

>>121
有り難う、昔matroxのftpで拾ったDVC-PRO50が使い続けらるなら嬉しい話だ
今のマシンパワーなら可逆圧縮で良いんだけど、昔の取り溜めして放置している素材なんかが・・・

MainConceptだと\80kとかするんよね(他のcodecも入ってだけど)

128 :名無しさん@編集中:2009/10/19(月) 20:58:46 ID:sqrOs7Z+
ffmpeg系のプログラムは対応してるはず>DVC-PRO50
ってことでx64版のffdshowじゃ駄目なん?

129 :名無しさん@編集中:2009/10/20(火) 01:14:02 ID:bcPzNODS
鬱ビデオCLIで出ないかなぁ

130 :名無しさん@編集中:2009/10/20(火) 01:24:26 ID:czJOgAFl
>>126
32bitのavisynthで64bitのx264使う方法はあるよ。

131 :名無しさん@編集中:2009/10/20(火) 01:39:19 ID:4En/TOZa
>>130
avs2yuvもモルダーさんのツールも知ってるよ
俺が言いたいのはAviSynthそのものを64bitにしないと、たいした高速化は望めそうもないんじゃないかってこと
x264がいくら速くなってても、synthが足を引っ張ってるのが現状でしょ

132 :名無しさん@編集中:2009/10/20(火) 15:09:30 ID:Tv7Jz6o3
>>131
何か勘違いしているようだけどavisynthを64bit化することの利点は速度ではなく使用可能なメモリーサイズが増えることにある
速度は高度な最適化が進まんとたいして速くならんのでフィルター類が64bit化されても速度はたぶん今と変わらないよ

133 :名無しさん@編集中:2009/10/20(火) 16:43:42 ID:vY04tZq8
ttp://pc11.2ch.net/test/read.cgi/avi/1254106514/87
Help Me!

134 :名無しさん@編集中:2009/10/20(火) 21:18:04 ID:R2G2bmkn
>>128
をぉ、重ね重ね有り難う
7のアップグレード頼んであるんで届いたら試してみます

135 :名無しさん@編集中:2009/10/21(水) 04:21:10 ID:cN1jTIQU
>>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 :名無しさん@編集中:2009/10/21(水) 06:01:37 ID:911ZR/Fr
別にTVキャプなら通常RGBなんて介在しませんからhuffyuvでなんら問題はない

137 :名無しさん@編集中:2009/10/21(水) 06:27:43 ID:cN1jTIQU
>>136
TMPGEncはRGBだったと思う...

138 :名無しさん@編集中:2009/10/21(水) 06:48:39 ID:kPqsOhG8
ていうか、>>133のツッコミどころは
  >huffyuvsとhuffyuvとマルチスレッドのhuffyuvを右クリックでインストールしたんだが。
のとこだよね。

マルチスレッド版はFOURCCが違うから共存できるとして、
FOURCCが同じHuffyuvsとHuffyuvを同時インストールするとどういう挙動になるんだろう。
しかも両方ともアンインストールがうまくいかないバグがあるようだし。

139 :名無しさん@編集中:2009/10/21(水) 07:46:00 ID:kPqsOhG8
ごめんFOURCCが同じとか大嘘だった。いや〜ん、こっぱずかすぃ。。。・゚・(ノ∀`)・゚・。

  Huffyuv   HFYU
  HuffyuvS  SHYU
  Huffyuv_mt HYMT

自分でもなんでかわからないけど物凄い変な思い込みがあったようだ・・・・orz

・・・・・・あれ?じゃあなんでデコードのミスマッチだの画面が乱れるだの騒いでるんだ???

140 :名無しさん@編集中:2009/10/21(水) 08:08:34 ID:cN1jTIQU
FourCCがSHYU(HuffyuvS)なのは確認したけど、やっぱ画が乱れる。
>>139は正常に再生できてるの?

141 :名無しさん@編集中:2009/10/21(水) 08:40:21 ID:kPqsOhG8
>>140
うちはHuffyuvSは入れてないんだ。
すまんけど、ちょっと今はコーデックまわりをいじりたくないので検証はできそうにない。

142 :140(巻添え規制中シベリアより):2009/10/21(水) 15:34:33 ID:KOD/IOCv
>>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 :140(巻添え規制中シベリアより):2009/10/21(水) 15:35:45 ID: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 :名無しさん@編集中:2009/10/22(木) 18:59:20 ID:IxmMTt03

・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 :名無しさん@編集中:2009/10/23(金) 03:09:50 ID:GBKkev93
俺にとっての問題は64bitOSを使っても用いてるキャプチャソフトも編集ソフトも32bit版しかないということだ

146 :名無しさん@編集中:2009/10/23(金) 16:25:55 ID:8ehsYAY0
Linuxだとほぼ全てのアプリケーションにamd64版があるようだけど、Windowsで64bit版が少ないのって何で?

147 :名無しさん@編集中:2009/10/23(金) 19:34:16 ID:6VAqc4Ca
作るコスト>得られる利益 だから。

148 :名無しさん@編集中:2009/10/24(土) 00:07:06 ID:bwlt5OW7
UtVideo Codecはファイルは規定の位置にインストールされてるけどvctest・Veedub64では選択できなかった。
Lagarithはx86のほうが早くてProxy Codec64かましたx86が若干x64よりも早かった・・・

149 :名無しさん@編集中:2009/10/28(水) 22:29:06 ID:wyXGbleM
>>135
色空間スレでまるもさんが実験したけど
伸張圧縮しないHyffyuvsはRGB<>YUV変換誤差がでかいよ
RGB化したときに切り捨てられる15以下235以上を保持することがメリットってだけ
元はAviutlの伸張圧縮に問題がある次期にそれように作られたもの
ノバックの書き方がおかしいんだが
”キチンと輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう”
んじゃなくて
”伸張圧縮しない環境で輝度調整を行っている人はhuffyuvsを使用しないと、輝度が二重に調整されてしまう”

>>137
それは2.5PLUS時代まで
ExpressシリーズはYUY2だよ

150 :名無しさん@編集中:2009/10/30(金) 03:46:03 ID:7qgY3kVS
huffyuvsを64bitのOSにインストするにはどこを書き換えたらいいか
誰か分かる人いますか?huffyuvのインスト方法を参考にやっているのですが、
どうも上手くいきません。

151 :名無しさん@編集中:2009/10/30(金) 04:11:47 ID:2U1ICUyD
べつにhuffyuvでいいじゃん
ccespパッチあたってれば問題もないんだし

152 :名無しさん@編集中:2009/11/02(月) 20:14:14 ID:CP/HHgSf
Avidemuxの64ビット版ってどこにあるの?

153 :名無しさん@編集中:2009/11/03(火) 13:42:41 ID:aMKLOss+
doom9。
でも正直使い物にならない。

154 :名無しさん@編集中:2009/11/03(火) 17:31:29 ID:aMKLOss+
>153
ごめん。間違えた。

155 :名無しさん@編集中:2009/11/04(水) 21:36:11 ID:0KOYq+w7
誘導されました

元の画質からほぼ無劣化で出力できるコーディックないでしょうか?
Huffyuv211を使ってたのですが最近これで出力すると再生する時に変になります。
220にバージョンアップすると出力99%のとこでVS12が強制終了してしまいます。
どうすれば良いでしょう?何か高画質のままほぼ無劣化で出力できるコーディック教えて下さい

156 :名無しさん@編集中:2009/11/04(水) 22:07:04 ID:Gawi44ah
UtVideoでしょ。はやいし。

157 :名無しさん@編集中:2009/11/04(水) 22:09:58 ID:eyZ/kLm+
>>155
バカタレ
おれがここに誘導したのは質問しろってことじゃねーよ
読めってことだよ
なぜなら>>2に答えがあるからだ

158 :名無しさん@編集中:2009/11/04(水) 23:32:31 ID:0KOYq+w7
>>157
なるほど
では>2の中だとどれが一番オススメでしょう?

159 :名無しさん@編集中:2009/11/05(木) 00:28:02 ID:hksH6wCk
すでに2回UtVideo薦められといて、さらにそれを聞くのか

ところで7.0.1が来てるな

160 :名無しさん@編集中:2009/11/05(木) 14:07:22 ID:guEmtvx+
UtVideoをインストールすると4つ選べるようになります
どれが一番良いんですか?

161 :名無しさん@編集中:2009/11/05(木) 14:22:51 ID:hksH6wCk
さあねえ、あれは状況に応じて使い分けるものだから、どれがいいかなんて考えたこともないな

162 :名無しさん@編集中:2009/11/05(木) 23:15:34 ID:krxCtlOv
>>160
ULY2が一番軽い。

163 :名無しさん@編集中:2009/11/05(木) 23:38:10 ID:Ef6RJI9A
>>162
お前そういう教え方はイジメだろ・・・w

>>160
色空間がわからないならULRGでも使っとけ。

164 :名無しさん@編集中:2009/11/05(木) 23:44:34 ID:hksH6wCk
単純に軽いってんならULY0のほうが軽いだろ
色差の情報量はULY2の半分しかないんだから

165 :名無しさん@編集中:2009/11/06(金) 04:53:14 ID:BzYkDogP
>>160

YUVフォーマット及び YUVとRGBの変換
http://vision.kuee.kyoto-u.ac.jp/~hiroaki/firewire/yuv.html

カラーフォーマットのナゾ
http://www.nnet.ne.jp/~hi6/lab/pixel/


これらのページの熟読推奨

166 :名無しさん@編集中:2009/11/06(金) 21:30:13 ID:8Q5ZJdps
なんだかんだ言っても優しいやつらだな (;_;

167 :名無しさん@編集中:2009/11/06(金) 23:05:24 ID:mNqPq/k/
>>165
>>160 じゃないけど、こういうの待ってた!!
でも読んだけど、いろんなデータの取り方があるのは解るけど、
どういうときどれ使えばいいのかは結局わからん・・・

そもそも、YUV422 が 16bit/pixel で、それが RGB24 (24bit/pixel でしょ?)
と可逆変換できるのが意味わからん・・・
ましてや YUV420 の出番がいつなのか、まったくもってわからん・・・

168 :名無しさん@編集中:2009/11/06(金) 23:31:01 ID:mNqPq/k/
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 :名無しさん@編集中:2009/11/07(土) 00:39:49 ID:hRywxXVv
UtVideoに非可逆モードが付くのはいつなんだろうか?
再エンコするので画質そこそこ容量小さめ転送量も少なくHDDに優しい
非可逆モードが欲しい。転送量は10MB/sくらいで。

170 :名無しさん@編集中:2009/11/07(土) 01:20:18 ID:nFr82N34
再エンコするから可逆なんだろ?なに言ってるの?

171 :名無しさん@編集中:2009/11/07(土) 03:24:56 ID:N7piNmn9
AMVでも使ってろ

172 :名無しさん@編集中:2009/11/07(土) 04:42:38 ID:nd0J9vRN
非可逆ならくさるほどあるだろーに。

173 :名無しさん@編集中:2009/11/08(日) 14:10:51 ID:91TdnYpi
DV Type2は可逆圧縮できますか?

もしできるとしたら、おおよそ何割くらい小さくできますか?

174 :名無しさん@編集中:2009/11/08(日) 14:52:08 ID:ewRe+iAf
>>173
それ質問になってない

175 :165:2009/11/09(月) 04:58:58 ID:D746S24I
>>167-168
・入力か最終出力が、MPEG-2とかMP4(H.264)とかFLVとかなら、YUV420系を使っておくほうがいい
 (インターレース動画の場合はYUV422系がいいかも)
 ・編集等でアルファチャンネルが必要な段階ではRGBA一択

雑に書くとこんな感じかと。

176 :167:2009/11/09(月) 06:59:23 ID:o3NoXhw+
>>175
補足ありがと。2つめは当然だね。

1つめの理由は自分で調べるとして、ガイドラインとしては十分ですわ。ありがとー。

177 :名無しさん@編集中:2009/11/09(月) 09:28:58 ID:HjrlqfFM
>>173
DV Type2は可逆圧縮ですか?
という質問なら答えられる人がいると思う。

> おおよそ何割くらい小さくできますか?
実際にやってみろよ。


178 :173:2009/11/15(日) 17:50:53 ID:FvCQHsUT
質問かえますね。

DV Type2をバックアップしたいんですけど、容量を考慮してできるだけ小さいファイルサイズ
にしたいです。

このスレでいう可逆圧縮とはちょっとニュアンスが違うのかもしれませんけど、例えば7-zipや
cab等でも可逆圧縮できますが、データの性質上ほとんど小さくなりません。

圧縮した状態で再生できるかどうかは問いません。存在するかどうかわかりませんが、もし
DV Type2のデータを可逆圧縮でそれなりに小さくするものをご存じでしたらお教えください。

179 :名無しさん@編集中:2009/11/15(日) 18:31:09 ID:b+lovGqj
とりあえず世界最強はKGBらしいが
http://www.dryout.info/product/kgbarchiver/

これで縮むかどうかは知らん

180 :名無しさん@編集中:2009/11/15(日) 19:24:33 ID:kj+Idcew
DVつーとYUV4:1:1だよなあ。4:1:1に対応したコーデックなんてあんのか?
そういう意味での1次劣化をよしとするならx264のqp=0ならかなり縮むんじゃなかろうか。


181 :名無しさん@編集中:2009/12/12(土) 06:52:32 ID:YlVhckni
>>179
推奨システム
CPU: Intel Core™ または AMD Athlon™ 64 と互換性のあるCPU
RAM: 1GB

どんだけメモリ喰うんだw

182 :名無しさん@編集中:2010/01/01(金) 21:42:40 ID:CckcAv6F
止まってしまったな。

183 :名無しさん@編集中:2010/01/19(火) 03:15:35 ID:bz5jALeR
RGBで圧縮したAvi動画がなぜか再生できない。
MedioInfoで確認したところ、情報すら記載されてなかった。
環境はWindows 7 64bitでデコード速度を優先しているんだけど、原因は何だと思われます?

184 :名無しさん@編集中:2010/01/19(火) 04:04:46 ID:bz5jALeR
>>183
自己解決した
サイズが2GB上回ってたわ
でも、AVI2.0だと思ってんだが

185 :名無しさん@編集中:2010/01/19(火) 04:09:18 ID:u6TWCvkW
>>183
>RGBで圧縮したAvi動画がなぜか再生できない。
UtVideoのULRGのことだと推測するが、コーデック名くらいしっかり書けよ。

>MedioInfoで確認したところ、情報すら記載されてなかった。
何の情報だよ。何が言いたいのかさっぱりわからんわ。

>環境はWindows 7 64bitでデコード速度を優先しているんだけど、原因は何だと思われます?
とりあえずいったんアンインストールして最新版を入れなおしてみれば?

186 :名無しさん@編集中:2010/01/19(火) 04:10:27 ID:u6TWCvkW
ぐお、更新してなかった・・・。

>>184
思ってるとかじゃなくちゃんと調べなよ。

187 :名無しさん@編集中:2010/01/19(火) 10:51:01 ID:0aKouGO/
>>186
乙かれー

188 :名無しさん@編集中:2010/01/19(火) 15:20:12 ID:bz5jALeR
>>185
スマン
コーデックはUtVideoです。Lagarithも同じ現象だった
Mediainfoで記載してなかったって言うのは、ようはコーデックが何に使われてるだとか、
ビットレートの情報が書かれてなかった
最新版には入れなおしても変わりなかった

ただ、AVIを2G以内に収めれば再生もできたし、Mediainfoで情報も記載されてあった
AVI2.0では2G以上でも再生されると思ってたんだが、 エンコードツール・コーデック自体AVI2.0には対応してなかったみたい

189 :名無しさん@編集中:2010/01/19(火) 16:36:44 ID:1zJ02p8S
>>188
>AVI2.0では2G以上でも再生されると思ってたんだが、
>エンコードツール・コーデック自体AVI2.0には対応してなかったみたい

コーデックは無関係。エンコードツールがAVI 1.0しか吐き出せなかっただけだな。
どんなツール使ってるのか知らんけど、プラグインとかでAVI 2.0に対応してる可能性もあるとは思うが・・・。
あと、こういう場合は質問時にエンコードツールの名前も書いとくと回答がもらいやすいかもね。

190 :名無しさん@編集中:2010/01/22(金) 02:47:20 ID:nRuUFSLl
すみません、可逆圧縮コーデックに限った話ではないのですが、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 :名無しさん@編集中:2010/01/22(金) 02:50:11 ID:tOQIZQeQ
readmeとかヘルプとか作者のHPとか見るのが良いんじゃないな。

192 :名無しさん@編集中:2010/01/22(金) 03:07:06 ID:nRuUFSLl
>>191
う、それは確かにそうなのですが、何か他にツール的なアプローチは無いものかな〜と思いまして。

193 :名無しさん@編集中:2010/01/22(金) 03:29:47 ID:7vvChrvK
>>192
AviSynthで読み込み
info() で表示
後はお好きなように・・・

194 :名無しさん@編集中:2010/01/22(金) 04:13:41 ID:nRuUFSLl
>>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 :名無しさん@編集中:2010/01/22(金) 23:38:21 ID:FhgZ336g
UtVideoの作者さんから調査への協力依頼だそうな
http://umezawa.dyndns.info/wordpress/?p=1468&cpage=1#comment-21142

196 :名無しさん@編集中:2010/01/23(土) 00:25:49 ID:prxWNPEW
可逆圧縮でもビットレートってあるけど、映像にはまったく影響がないと思っていいの?
何か、レートが100Mbps以上だけどUtVideoのデコード優先と圧縮優先じゃ、30Mbps以上も差があるんだけど

197 :名無しさん@編集中:2010/01/23(土) 01:36:00 ID:2sM0IA61
>>196
可逆圧縮なんだから、色空間さえ間違えずに扱えば映像にはまったく影響はない。
一般的には

  デコード優先→データ圧縮率は低め=圧縮後のデータ量は多め→圧縮後のビットレートは高め

  圧縮率優先→データ圧縮率は高め=圧縮後のデータ量は少なめ→圧縮後のビットレートは低め

と考えればいいだけだと思う。
ソースやコーデックへの渡し方によっては結果が違ってくるだろうけど。

198 :名無しさん@編集中:2010/01/23(土) 06:39:24 ID:prxWNPEW
あー、なるほど
てことはソースが4k2kとかだったらまた違うのかな?
4k2kとかそれ以上の解像度って高画質であれば100Mbps以上必要でしょ?



199 :名無しさん@編集中:2010/01/23(土) 15:39:03 ID:s9Hpd9w6
そりゃソースによるじゃん。極端な話黒1色の静止画なら1kbpsでだって無劣化で圧縮できるし(アルゴリズムによるけど)

200 :名無しさん@編集中:2010/01/23(土) 17:53:52 ID:prxWNPEW
可逆圧縮ってまた元に戻せるから可逆って言うんだよね
だったら、可逆圧縮したAVIファイルをカットなんかした後に再度エンコするとき、
可逆圧縮にしたらどうなるの?
可逆→可逆


201 :名無しさん@編集中:2010/01/23(土) 18:25:45 ID:mrh65ujR
色空間変換を挟まなければ劣化はない

202 :名無しさん@編集中:2010/01/23(土) 19:18:41 ID:gl6qXM43
>>195
Windows7の120日評価版にソースからビルドした7.0.1のx64msiはインストール失敗したので
ICInstallSelfの部分を以前のバージョンに戻してOrcaでmsiにパッチを当てたらインストール
出来ました。


203 :名無しさん@編集中:2010/01/23(土) 21:49:49 ID:60QhRN/+
ちょうど資料作りをしてたので、
  「可逆圧縮コーデックといえども、途中で色空間の変換が入ると可逆じゃなくなるよ」
っていう件についてのサンプル画像をアップしてみます。

 ■サンプル画像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 :名無しさん@編集中:2010/01/25(月) 04:01:48 ID:QG59TvId
>>203
ええっ
つまり、BT709で出力したら可逆じゃなくなるのか?!
Aviutlの設定じゃ入力はAutoだけど、出力はBT709になってるぞ

お、おれの可逆動画フォルダすべてが水の泡・・・

205 :名無しさん@編集中:2010/01/25(月) 04:08:53 ID:m5Tt1G8v
Aviutlの色空間変換ってデータそのものを変換してる?
動画ファイルの扱いだけが変わってるんじゃないかと思うんだけど
どうなんだろ?

実際Aviutl上で入出力切り替えても見た目ぜんぜん変わらんし・・

206 :名無しさん@編集中:2010/01/25(月) 07:35:41 ID:5I8ZVLm6
>>205

RGB出力なら可逆でなくなる
YUVなら変わらない

207 :名無しさん@編集中:2010/01/25(月) 14:51:56 ID:PJ+MA5jy
>>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 :名無しさん@編集中:2010/01/25(月) 15:02:07 ID:PJ+MA5jy
あ、あとはYUVのTVスケールとフルスケールというのもあるっけ・・・。
このあたりは主に上の3あたりに含まれるということで・・・。
>>135-149あたりを見ると、5−7、11−13あたりも絡んでくるのかな。

209 :名無しさん@編集中:2010/01/25(月) 15:32:41 ID:d0QTl4m7
>>207
色変換プラグインというのもあるよ。
プラグインを公開している人は少ないが
8〜10の部分をプラグインでいじれる。

210 :名無しさん@編集中:2010/01/25(月) 18:53:28 ID:5I8ZVLm6
>>207

>>205の質問の趣旨から外れてるだろ
そりゃフィルター入れりゃ可逆でなくなるのは当たり前
あくまでaviutlでカット編集した時だけの話だろ

211 :名無しさん@編集中:2010/01/25(月) 19:36:00 ID:QG59TvId
つまり、aviutlで可逆ファイルを読み込む場合、
色変換の設定の入力・出力は自動で、AVI出力する時、再圧縮なしの可逆のままで出せば問題なし?
可逆読み込み→可逆出力(再圧縮なし)でおk?

今まで未圧縮に再圧縮してたけど・・・

212 :名無しさん@編集中:2010/01/25(月) 20:00:43 ID:JV3pQzr9
未圧縮ってのはRGB24だから、もろに色が変わるだろ

213 :名無しさん@編集中:2010/01/25(月) 20:03:05 ID:9pLRGCPe
入力/出力の設定はBT.601にすれば従来通り。自動は縦解像度720以上でBT.709と認識するから
709 > 601変換が入る。つーてもカットだけならAviutlは12bit処理なのでマトリクス変換での劣化はない。
まあ再圧縮なしで出力するのが一番いいと思う。未圧縮はRGBだから一番ダメだろ

214 :名無しさん@編集中:2010/01/25(月) 20:51:05 ID:m5Tt1G8v
でも601>709と入出力を切り替えたりしてもAviutl上は
何も変わらんってのはなんでなんだろ?今の見え方を
該当色空間に当てはめてるって事?内部の色の数値は
変わってますよ、って事なんかね?

215 :名無しさん@編集中:2010/01/25(月) 21:58:07 ID:QG59TvId
可逆でエンコした動画を再度可逆なら問題なしなの?
今、フォルダから未圧縮すべて消してやり直ししてる
こりゃ、1日以上かかるなorz


216 :名無しさん@編集中:2010/01/25(月) 21:59:36 ID:QG59TvId
>>213
いや、可逆したファイルはみんな解像度は1280x720だから、出力をBT709にしてもよかったのか
これは安心した

217 :名無しさん@編集中:2010/01/25(月) 22:30:27 ID:QG59TvId
ちょっと待て、再圧縮なしにすると
可逆設定でRGBに設定したから、出力したファイルがRGBになってるぞ
これ正常?
だったら、未圧縮でもRGB何だから変わらないんじゃ?

218 :名無しさん@編集中:2010/01/25(月) 22:35:46 ID:9pLRGCPe
>>214
出力は変えてもプレビューには関係ないよ。入力はYUVで読んでればちゃんと変わるが
RGBで読んでたら当たり前だが入力の設定は関係ないぞ。

>>215-216
可逆と非圧縮であることとYUVとRGBであることは全く関係がないぞ。
なんかごっちゃになってないか?言ってることが良く解らん

219 :名無しさん@編集中:2010/01/25(月) 23:07:23 ID:QG59TvId
>>218
すまん、えーっと俺の方が勘違いしてるのか?
可逆圧縮コーデックのLagarithやUt VideoでRGB(もしくはRGBA)の設定できると思うが、
これと未圧縮で出力されたRGBと何が違うんだ?

Lagarithでエンコした動画を再圧縮なしにして出力すると、
未圧縮ファイル(RGB)になるんだが、この未圧縮は正常?

220 :名無しさん@編集中:2010/01/25(月) 23:09:56 ID:JV3pQzr9
お前、DirectShowで読み込んでないか?

221 :名無しさん@編集中:2010/01/25(月) 23:15:16 ID:sYz+wKd2
まず用語を整理しないと混乱する気がする。

  再圧縮無し・・・ソースの映像を、形式を変換せずにそのまま出力すること。
           出力時にコーデック選択欄の右にある「再圧縮なし」にチェックを入れるとこれになる。
           Lagarithで圧縮されたソースを再圧縮なしで出力したらコーデックはLagarithのままだし
           ULY2で圧縮されたソースを再圧縮なしで出力したらコーデックはULY2のまま。

           ※ただし「再圧縮なし」にするとフィルタ等は効かない。

           ※キーフレーム以外の部分でカット編集した場合は「再圧縮なし」にすることはできず、
             必ずなんらかのコーデックで再圧縮(未圧縮も含む)を行なう必要がある。

  未圧縮・・・未圧縮RGB、つまりなんの圧縮もされていないRGB映像のこと。
         出力時にコーデックの選択で「未圧縮」を選ぶとこれになる。

222 :名無しさん@編集中:2010/01/25(月) 23:20:49 ID:QG59TvId
Lagarithで圧縮した可逆ファイルを読み込んだ後、
再圧縮なしにチェック入れるとコーデックには未圧縮になるんだが・・・
バグなのか?


223 :名無しさん@編集中:2010/01/25(月) 23:22:44 ID:QG59TvId
>>220
directshow file readerは入ってるが、もしかしてこれのせい?

224 :名無しさん@編集中:2010/01/25(月) 23:27:56 ID:sYz+wKd2
>>222-223
とりあえずLagarithで圧縮したファイルを読み込んだら、メニューの「その他→ファイルの情報」を見て、
  ・ビデオ圧縮
  ・ファイル制御
  ・ビデオ展開形式
がどうなってるか確認するんだ。


225 :名無しさん@編集中:2010/01/25(月) 23:33:25 ID:QG59TvId
ビデオ圧縮:未圧縮
ファイル制御:DirectShow File Reader
ビデオ展開形式:RGB

になってたよorz
Mediainfoで見ると、ちゃんとLagarithになってるんだけど
どうすればいい・・・?

226 :名無しさん@編集中:2010/01/25(月) 23:40:08 ID:JV3pQzr9
AVI/AVI2 File Readerの優先度を一番上にすればいい

227 :名無しさん@編集中:2010/01/25(月) 23:46:28 ID:QG59TvId
>>226
マジ、dクス
何でDirectShowなんか糞プラグイン入れたんだろ・・・
可逆しなおすため1日費やすかorz


228 :名無しさん@編集中:2010/01/25(月) 23:50:36 ID:JV3pQzr9
ds_input.auiは使い方さえ間違えなければとても優秀なプラグイン
糞呼ばわりするようなオマエが糞なんだよ

229 :名無しさん@編集中:2010/01/25(月) 23:52:31 ID:QG59TvId
>>228
そうだな、確かにそうかも知れん
とりあえずは感謝する
でも、マジでやり直すの面倒だorz

230 :名無しさん@編集中:2010/01/26(火) 00:04:33 ID:M+i4gELY
Lagarithと一口に言っても、「RGB24, RGB32, RGBA, YUY2, YV12」と、内部形式が色々あったりするよね。
圧縮方法と展開方法の組み合わせを間違えるとそこでも色空間変換が・・・。

231 :名無しさん@編集中:2010/01/26(火) 00:47:30 ID:L31xexlo
>>230
いや、それは気をつけてるつもり
Lagarithの設定はRGBがデフォで、それをAviutlに読み込ませて
カットした後、再圧縮なしにすればおkじゃない?
Ut Videoも同じ感じで・・・

232 :名無しさん@編集中:2010/01/26(火) 02:55:03 ID:jhlWXWIs
やっぱりRGBがサイキョーかぁ〜〜

233 :名無しさん@編集中:2010/01/26(火) 03:20:22 ID:M+i4gELY
ID:QG59TvId = ID:L31xexlo だと思うけど、そもそも何をやりたいのかよくわからない。
BT.709で出力してると言ってるから、なんらかのYUY2ソースを
LagarithのYUY2で圧縮してるのかと思ったらLagarithはRGBで使おうとしてるようだし。

>>231では「Lagarithで圧縮したファイルを読み込んでカットして再圧縮無しで出力」と言ってるから、
別ソフトでRGBで編集した映像データをLagarithのRGBで圧縮して、それをAviutlに読み込んで
不要部分をカットして再圧縮無しで出力したいということなんだろうか?
でもそれならずっとRGBで扱うわけだから、Aviutlの入出力の色空間は関係ないはずだし、
そもそもそんなカット編集だけをAviutlでやる意味がよくわからないというか・・・。

作業する前にそのへんをちゃんと整理して理解しないと、作業が無駄になる気がする。

234 :名無しさん@編集中:2010/01/26(火) 03:46:13 ID:L31xexlo
すまん、はっきり言うと
ゲーム動画をlagatithで録画し、aviutlに読み込ませカットした後、
色空間とか触れず、そのままの状態で元に戻したかっだけ
つまりカットと編集をしたかったんだ
BT709で出力はやめて自動にしたけども、ゲーム解像度が1280x720だから大丈夫な気がした

7個目の作業中だよ、今orz

235 :名無しさん@編集中:2010/01/26(火) 15:06:57 ID:NRku1dVF
そもそもキャプチャの色空間ってYUVじゃないの?

236 :名無しさん@編集中:2010/01/26(火) 15:39:42 ID:jhlWXWIs
キャプチャボードとか使ってないんじゃない?
自画面キャプチャならRGBのが普通なんじゃないの?
わざわざYUVに変える意味は無いと思うし

237 :名無しさん@編集中:2010/01/26(火) 15:56:42 ID:Fdwd/7YX
つうかLagarithって圧縮率は高いけどエンコード速度は遅いから
リアルタイムでキャプチャと同時に圧縮していく場合に使うのには向かないんじゃないっけ。
RGBでキャプチャするにしてもHuffyuvとかULRG使ったほうが早いみたいだし。
録画中は無圧縮で中間出力して録画終了時にまとめて圧縮するタイプのソフトなら
Lagarithでもいいかもしれないけど。

  あまラボ ビデオコーデック・ベンチマーク2009
  http://amalabo.blog35.fc2.com/blog-entry-44.html

238 :名無しさん@編集中:2010/01/26(火) 16:33:07 ID:VYAktjG8
ていうか誰も触れてないけどAviutlならコーデックの設定でYUY2で圧縮のチェック外さないと
RGBで出力できないでしょ。試せばわかるけどYUY2のチェックはいってるとLagarithでRGB指定しても
YUY2でやったときと同一になるから。

239 :名無しさん@編集中:2010/01/26(火) 16:42:53 ID:NRku1dVF
>236
ああそっか。PSとかXBOXの取り込みだと思い込んでた。

240 :名無しさん@編集中:2010/01/26(火) 17:13:36 ID:Fdwd/7YX
>>238
今色々試してるけど、Lagarithってそのへんわかりにくいね。
UtVideoならRGBとYUV422とYUV420が明確に分かれてるからわかりやすいけど・・・。

241 :名無しさん@編集中:2010/01/26(火) 17:33:38 ID:/pJ51WOH
じゃあRGB動画でも[YUY2で展開する]のチェック外さないと
X264GUIに渡す時

RGB>YUY2が
RGB>YC48>YUY2になって劣化するの?

242 :名無しさん@編集中:2010/01/26(火) 18:02:46 ID:Fdwd/7YX
>>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 :名無しさん@編集中:2010/01/26(火) 18:13:56 ID:/pJ51WOH
>>242
ありがとう

なるほど理解できました

244 :名無しさん@編集中:2010/01/27(水) 00:58:58 ID:k8i3Cm4Q
x264で一生懸命設定煮詰めたエンコで赤いスカートの縁が
ギザギザになって悩んだっけ・・・

上とは関係ないけど色々ググッたらutのRGB&RGBAの展開の設定を
YUY2で展開するにしてた・・これって展開時に劣化してたって事だよね?

245 :名無しさん@編集中:2010/01/27(水) 01:35:02 ID:U5LC0AeY
いやYUY2で展開する設定だったらRGBのものはRGBで展開される。
逆に出力時はRGBで圧縮(YUY2で圧縮のチェック外す)じゃないとRGBで出力されない。


246 :名無しさん@編集中:2010/01/27(水) 01:45:34 ID:k8i3Cm4Q
>>245
YUY2で展開する、なのにしてないって事?RGBで展開してるなら問題ないって事だから良いのか・・・
YUY2で展開する、のチェックはずしたらまずいのかな?

出力はグレーアウトしてるからたぶん強制的にRGBになる物なんだと思う

247 :名無しさん@編集中:2010/01/27(水) 02:32:25 ID:U5LC0AeY
ああごめんutをutlって読んでたわ。動画読み込んだ際にビデオ展開形式がRGBになってたら大丈夫でしょう、多分。
utはテストしてないから気になるならハッシュでも比較してみてください・・・

248 :名無しさん@編集中:2010/01/27(水) 03:26:26 ID:k8i3Cm4Q
>>247
とん、随分Aviutl使ってたけどファイルの情報って知らなかった・・・

249 :名無しさん@編集中:2010/01/27(水) 04:27:03 ID:CZaIPNtC
UtVideoのULRGとULRAは、YUY2での出力(デコード)はできないようになってるから
「YUY2で展開する」にチェックを入れても、
  「YUY2で出力して渡すのは無理だよー」
ということでRGBで読み込まれる。
「YUY2で圧縮する」のチェックがグレーアウトしてるのは、
YUY2での入力ができないようになっているから。

UtVideoの各コーデックが対応している入出力形式については
公式のreadmeとか>>190のリンク先とかを参照かな。

なんにせよ、読み込んだら「その他→ファイルの情報」を見て、
どのプラグインでどの形式で読み込んだのかをしっかり確認したほうが良いですな。

250 :名無しさん@編集中:2010/01/28(木) 12:19:55 ID:hsgeh8rl
ふう、やっと変換作業終わった
1日以上費やしてしまった
これで問題何ひとつないよね

キャプチャボートは使ってない。 DxtoryでLagarithに設定して録画した動画だから
元がLagarithだから、それを無劣化で色空間とか触れずにカットだけするつもりだった

・・・ってコーデックの設定のLagatirh見たら
YUY2で展開する、YUY2で圧縮する、圧縮の設定を保持する全部にチェック入ってるじゃないか!
誰か助けてorz

251 :名無しさん@編集中:2010/01/28(木) 12:40:36 ID:5VSRrvw8
もう一度始めから変換するしかない
ガンガレ!

252 :名無しさん@編集中:2010/01/28(木) 13:36:29 ID:hsgeh8rl
>>251
おぃ・・orz それ言うなw
マジなのか?
失敗したのか?
やり直しなのか?

253 :名無しさん@編集中:2010/01/28(木) 13:52:52 ID:5VSRrvw8
>>252
最近の流の中で勉強した限りでは君がやりたいことをやるためには
少なくとも「YUY2で圧縮する」のチェックを外す必要があると理解した
俺の理解が間違っていたらやり直す必要ないかも
知識のある方のレスを待つましょう (-人-)

254 :名無しさん@編集中:2010/01/28(木) 14:47:51 ID:Y57l26L+
別にYUYだから見れたもんじゃないとかそういう事は無いだろう

でもやっぱRGBがサイキョーだな
422とか420とか、端折ってる訳だし

255 :名無しさん@編集中:2010/01/28(木) 15:28:35 ID:X2+pqjxH
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 :名無しさん@編集中:2010/01/28(木) 17:11:37 ID:cUDCXf4m
どうせ最終的にYV12で保存することになるんだからこまけぇことはいいじゃねえか

257 :名無しさん@編集中:2010/01/28(木) 17:33:24 ID:EmlfWJrf
aviutlでエンコするのに
RGBで録画してUVダウンサンプリングフィルタ通してx264guiに渡すのと
YV12で録画してx264guiに渡すんじゃ
出来あがった動画に顕著な差が出るんだろうか?
決定的な差でもなければ下の方が録画時の負荷も低いし
HDD容量もあんまり食わないからそうしたいんだけど

258 :名無しさん@編集中:2010/01/28(木) 20:07:38 ID:Y57l26L+
細部重視でシャープとか掛けるならRGBのまま処理した方が良いと思う
Aviutlのビデオフィルタはやっぱ綺麗だと思う・・たぶん

259 :名無しさん@編集中:2010/01/28(木) 20:39:42 ID:hsgeh8rl
>>256
いや、それを再度ゲームフォルダに戻す予定
一応、プリレンダリングムービーだから

つまり、それらを可逆で録画後、いらんところカットして
再度、フォルダに戻す

だから、変な劣化は駄目なのです
無劣化として残したいのでorz

260 :名無しさん@編集中:2010/01/28(木) 20:42:50 ID:RGDN9yOC
自力で解決する気がないならもう編集とか一切するな
ここはお前のためのサポートスレじゃない

261 :名無しさん@編集中:2010/01/28(木) 21:36:05 ID:cIlqKp8k
>>259
>>253であってると思うよ。つまりやり直し。
念のためDxtory+Lagarithで録画したファイルを読み込んだときに>>224をチェックして、
ちゃんとRGBで読み込まれてるか確認しといたほうがいいだろうね。

すでに>>233とか>>238で忠告されてるし情報も色々出てるんだから、
これを機会に色空間をしっかり理解したほうがいいと思うよ。
Lagarith使うならなおさら。

262 :名無しさん@編集中:2010/01/28(木) 22:05:41 ID:5VSRrvw8
えーと…
ご愁傷様です (-人-)ナーム >>252

263 :名無しさん@編集中:2010/01/28(木) 22:30:08 ID:ATbKQfML
細かいこといいから

劣化しないベストな方法教えろ

264 :名無しさん@編集中:2010/01/28(木) 22:37:24 ID:cIlqKp8k
>>263
色空間を理解し、ツール等の使い方を完璧に把握する。

265 :名無しさん@編集中:2010/01/28(木) 23:32:33 ID:hsgeh8rl
>>261
すまん、dクスです
Ut Videoなら大丈夫なのかね?
一部、Ut Videoで変換したやつがあって、それはAviutlで読み込んでファイル情報見たらRGBと記述してあった
カットした後も、再圧縮なしで変換したので多分問題ないかな?
Lagarithはやり直しです、頑張りますorz


266 :名無しさん@編集中:2010/01/29(金) 01:33:11 ID:2rIRd2Wa
色空間って601とか709とかsRGBとかNTSCとかを言うんじゃないのん?

個人的にデータフォーマットとごっちゃにしてるのって良くないんじゃないかって
思ってたんだよね、YUVとかRGBは色フォーマットと言うべきなんじゃなかろうか

色空間wikiでもビデオフォーマットって言ってるし
まあMpeg2とかh264と誤解しそうなんで色フォーマットとかピクセルフォーマットと
言うのがいい気がする

267 :名無しさん@編集中:2010/01/29(金) 01:59:59 ID:BmzV5IIl
National Television System Committeeがどうやったら色空間になるんだ?
RGB color spaceとかCMKY color spaceとか普通に言うだろ
まあ、color formatって言う人もいるだろうけど

268 :名無しさん@編集中:2010/01/29(金) 02:16:43 ID:U/pAiuBJ
>>266
厳密には色空間てのはRGBとかYUVとかCMYKといった表色系全体を指す。
BT.601とかBT.709ってのはRGBとの相互変換をする際の行列(カラーマトリクス)を規定したもの(だけじゃないが)で
こいつは本来は色空間とは言わない。sRGBとかNTSCはカラープロファイルじゃないかな?
カラーフォーマットはとかUYVYとかYV12とかRGB32とかいうデータの並び方の違いをいう(この場合必然的に
色空間も限定されるけど)

おれもよくわかんねーんだわ

269 :名無しさん@編集中:2010/01/29(金) 04:01:20 ID:0JbFeJXq
つまりUt Videoは気にすることなくエンコできるってことか
反対に、LagarithだとYUY2関連のチェック外さなきゃ駄目なのか

なんとめんどい

270 :名無しさん@編集中:2010/01/29(金) 21:13:49 ID:ZkiI53/e
FRAPSはデフォルトでYUY2
3系からRGBも選択できるようになった

271 :名無しさん@編集中:2010/01/29(金) 22:20:35 ID:0JbFeJXq
>>270
知ってるけど、たまにRGBにチェック入れても聞かない時あるな
RGBで録画して、チェック外して、再度チェック入れると聞かなくなる

272 :名無しさん@編集中:2010/01/30(土) 06:38:01 ID:zRlrCG0U
>>268
なんか勉強になった、トン

273 :名無しさん@編集中:2010/01/31(日) 12:32:05 ID:mPY1Iyai
>>269
Aviutlの場合、例えUt Videoが優先でも、デフォでYUY2出力なってなかったっけ
Ut Videoが出力しなくても、チェック外さなきゃ駄目じゃね


274 :名無しさん@編集中:2010/01/31(日) 18:12:29 ID:/Rwcq8gP
チェックボックスがグレーアウトしていてYUY2出力が出来ない。

275 :名無しさん@編集中:2010/01/31(日) 18:33:28 ID:c+Kqhz80
>>274
RGB限定フォーマットの読み込みはそうなる
AviutlはRGB<>YUY2変換しない
してるのはコーデックだから
コーデックに「RGBで保持してるけど出力はYUY2にもできる」機能・オプションがなければできない

276 :名無しさん@編集中:2010/01/31(日) 18:59:04 ID:Vkej2WRq
>>275
>>274>>273への回答であって、別に悩んでるわけじゃないと思うんだ・・・。
ついでに出力と入力がごっちゃになってないかw


あとUtVideoの中の人、入出力形式の情報ありがとうございます。

  或るプログラマの一生 ≫ [UtVideo] 対応入出力フォーマット
  http://umezawa.dyndns.info/wordpress/?p=1482

277 :名無しさん@編集中:2010/02/08(月) 08:21:22 ID:i4qIo0tv
可逆で圧縮したファイルを
カットやら字幕とか付けて編集して、また可逆圧縮するってのは
論理的に劣化してないという考えでいいの?

278 :名無しさん@編集中:2010/02/08(月) 11:02:00 ID:nReGv62u
>>277
>>200,201

279 :名無しさん@編集中:2010/02/08(月) 19:29:19 ID:GxpWbI7d
話題にも上がらんlgcodecとzerocodecは圧縮率とか速度どうなん
公式見ると「インストールできません」レベルの厨だけしかコメント書いてないが

280 :名無しさん@編集中:2010/02/08(月) 20:15:52 ID:ExxjyaCE
自分で試しもせず、このスレのログすら読まないやつが厨とか言っても失笑ものだとしか・・・

281 :名無しさん@編集中:2010/02/08(月) 20:16:26 ID:nReGv62u
光るものがあれば話題にのぼるだろ

282 :画質は不明。:2010/02/11(木) 16:52:05 ID:ifQ9htre
いらっしゃいましぇい、デルでょう。
デル デジタルハイエンドシリーズ U2711 27インチ ワイドTFT液晶モニタ
2560 x 1440 WQHD の高解像度、6 ミリ秒の応答速度 (GTG、標準)
横電解スイッチングテクノロジー (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 :名無しさん@編集中:2010/02/14(日) 15:01:41 ID:rW1Hly9a
Windowsムービーメーカーで無圧縮出力したファイル(yuv420p)を可逆圧縮したいのですが、

ffmpeg -vcodec libx264 -cqp 0 -coder 1 -g 30

で可逆圧縮になってるものでしょうか?
見た目では全然分からないのですが、1/6にもなるので本当かなあと・・・

284 :名無しさん@編集中:2010/02/14(日) 15:05:37 ID:9Iq59OV5
>>283
x264の可逆よりも、-vcodec ffv1 とした方が良い。

285 :名無しさん@編集中:2010/02/14(日) 16:23:50 ID:rW1Hly9a
>>284
レスありがとうございます。
一応、長期保存用なので、汎用的なものの方が良いかと思いまして。

10年位前にLCLでエンコードした動画の再生が今となっては不便で・・・


ffv1でも同程度圧縮されたので、今時はそれくらい圧縮されるのですね。
Huffyuvより数割減るくらいに思っていたので正直驚きました・・・

286 :名無しさん@編集中:2010/02/14(日) 16:38:17 ID:rzJoiTDQ
>LCLでエンコードした動画の再生が今となっては不便
LCLはFFmpeg (libavcodec)が独自デコーダを持ってるから、他のコーデックよりは対応プレーヤ多いよ。
仕様も(REされたものだろうけど)公開されているし。
http://wiki.multimedia.cx/index.php?title=Lossless_Codec_Libraries

287 :名無しさん@編集中:2010/02/16(火) 21:31:54 ID: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 :名無しさん@編集中:2010/02/17(水) 17:24:32 ID:R2+8AroY
YV12->YUY2は劣化する。アプコンだが。

289 :名無しさん@編集中:2010/02/17(水) 21:54:23 ID:LV1DseM3
>>288
ご指摘ありがとうございます。
FFV1は、実際はYV12でした。DirectShowSourceで見てしまってYUY2と勘違いしてしまいました。

しかし、YV12->YUY2は、単純に同じ値をコピーするだけではないのですね・・・


290 :名無しさん@編集中:2010/02/17(水) 22:02:51 ID:XADv7UWK
結局、色差だけを縦に2倍の拡大をすると言うことだからね。

AviSynth 2.6なら、chromaresampleに自分の好きな補間を選ぶ事ができる。
http://avisynth.org/mediawiki/Convert

291 :名無しさん@編集中:2010/02/17(水) 22:13:43 ID:nGRhhz5c
>>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 :名無しさん@編集中:2010/02/17(水) 22:18:02 ID:nGRhhz5c
うお、リロードしてなかった。
>>290に書いてあることは知らなかったよ・・・。>>290ありがとう。

293 :名無しさん@編集中:2010/02/18(木) 02:35:25 ID:9db/yS1o
>>290-291
教えて下さってありがとうございます。

単純にffmpeg(r18607) -vcodec ffv1とすると、
YV12、YUY2、RGB、何れの入力でもYV12でエンコードするみたいです。

それをAVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換のようです。多分・・・

294 :名無しさん@編集中:2010/02/18(木) 04:26:03 ID:mAfxKDB9
>>293
>AVISourceで読み込めばYV12のまま、DirectShowSourceで読み込むとYUY2に変換
それはお前のffdshowのデコード設定次第ではないのか?

295 :名無しさん@編集中:2010/02/18(木) 05:55:52 ID: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 :名無しさん@編集中:2010/02/18(木) 06:16:54 ID:mAfxKDB9
>>295
http://img502.imageshack.us/img502/4433/ffdshow.jpg
これのこと

297 :名無しさん@編集中:2010/02/18(木) 07:14:53 ID:2aTmhnRp
>>296
あっ・・・!そうか、ありがとう。
なんか「FFV1単体の設定」っていう思い込みに縛られてしまっていたようだ。orz

298 :名無しさん@編集中:2010/02/18(木) 22:26:02 ID:9db/yS1o
>>295
>デコードを試みるから、単にYV12でのデコードに成功したってだけでは。
>DirectShowSource()の場合はフィルタの関係上YUY2でしかデコードできなかったとかそんな感じかと。 

ffdshowがYV12に変換してAviSynthに渡していたのですね・・・、間違えてばかりですみません。

299 :名無しさん@編集中:2010/02/19(金) 20:00:02 ID:XV58ntT/
aviutlを可逆圧縮で読み込む時、みんな何プラグイン使ってる?
自分のはなぜかDirectShowになってしまって、ファイルの情報のビデオ圧縮が未圧縮になってしまうんだけど・・・
これで問題ないの?

300 :名無しさん@編集中:2010/02/19(金) 20:07:05 ID:9oagF+cu
標準のAVI/AVI2入力で普通に読めるだろ
DirectshowFileReaderの入力優先度を一番下にするってのは常識

301 :名無しさん@編集中:2010/02/19(金) 20:17:40 ID:XV58ntT/
>>300
DirectShowは一番下にしたけど、AVI File Readerになるんだが?
そうなると、ビデオ圧縮がMicrosoft Video 1になってしまう

もしかして、Ut Videoは可逆圧縮なのにAVI/AVI2では読み込めないのか?

302 :名無しさん@編集中:2010/02/19(金) 20:21:37 ID:emyC7Klv
そりゃAVI File ReaderをAVI/AVI2の上に置いてるからだろ

303 :名無しさん@編集中:2010/02/19(金) 20:22:06 ID:9oagF+cu
普通に読めるって言ってるだろうに…
AVI/AVI2を一番上にしろ

304 :名無しさん@編集中:2010/02/19(金) 21:07:05 ID:C6zNoPr0
>>301
可逆圧縮は一切関係ない。お前がAviutlの使い方をわかってないだけ。
スレ違いだからうせろ。

305 :名無しさん@編集中:2010/02/19(金) 21:51:36 ID:XV58ntT/
>>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 :名無しさん@編集中:2010/02/19(金) 23:32:20 ID:C6zNoPr0
>>305
何をどう調べたらそこまでめちゃくちゃな俺様理論が出来上がるのか興味があるわ

307 :名無しさん@編集中:2010/02/20(土) 02:17:49 ID:+Sk9lgbZ
>>306
PCゲームの.bikファイルをRAD Toolを使って
可逆AVIに変換してみれば分かる
ビデオストリームはULRGでも、aviutlで読み込むとAVI/AVI2では読み込まれないから

RADToolで読み込んでいない、他の可逆ファイルはAVI/AVI2になってたよ
何が俺様理論だよ・・・まじめに答えてるのに

308 :名無しさん@編集中:2010/02/20(土) 04:20:20 ID: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 :名無しさん@編集中:2010/02/20(土) 04:23:08 ID:0Yy+LBu3
FourCCが変なんだったら、バイナリエディタなりNic's FourCC Changerなりで
書き換えればいいんでないの?

310 :名無しさん@編集中:2010/02/20(土) 04:26:00 ID:QIBzS5Ln
あ、ちなみに出力したAVIを真空波動研に読ませようとするとフリーズするっぽいので気をつけて。

311 :名無しさん@編集中:2010/02/20(土) 04:38:24 ID:QIBzS5Ln
>>309
とりあえずバイナリエディタでfccHandler部を書き換えたらちゃんとAVI/AVI2 File Readerで
読めるようになったから、このツールを使わざるをえないなら当面はその対処がいいかもね。
他にも問題抱えてないか心配ではあるけど。

312 :名無しさん@編集中:2010/02/20(土) 05:43:01 ID:7fAmbFUz
情報後出ししといてキレるとかゆとりもいいとこだな

313 :名無しさん@編集中:2010/02/20(土) 07:32:03 ID:derdaAnj
bikを変換するならFFmpegに以下のパッチを当てて使うのが良いと思う。
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083512.html
まだレビュー中ではあるけど。
# dark shikari氏がレビューしているのにちょっと驚き。

314 :名無しさん@編集中:2010/02/20(土) 11:40:29 ID:+Sk9lgbZ
>>311
ありがとう、おかげさまでAVI/AVI2で読み込めるようになった
ただ、これは色空間挟むと同じようにfccHandler部を書き換えると画質劣化は起きるの?
もしそうなら今後、RADTool使うのはためらうんだけども

>>313
RADToolって使用してなかったはずだけど、是非使わせていただきます

315 :名無しさん@編集中:2010/02/20(土) 12:18:57 ID:0Yy+LBu3
>>314
>fccHandler部を書き換えると画質劣化は起きるの?
起きるかどうかはデコーダーの性能と設定次第

316 :名無しさん@編集中:2010/02/22(月) 23:24:01 ID:tI1yECHP
>>313のパッチが本線に入った。ってことで新しいFFmpeg使えばbikを直接変換できる。
http://multimedia.cx/eggs/bink-video-in-ffmpeg/

それと、Ut VideoがFFmpegにポートされるかも。FFmpegのGoogle SoCタスクとして。

317 :名無しさん@編集中:2010/02/22(月) 23:47:40 ID:ixhqKiZY
FFmpegがUT Videoに対応すれば、Windows以外の環境でもhuffyuvは使われなくなるだろうな。

318 :名無しさん@編集中:2010/02/27(土) 09:27:31 ID:at1K1Qv2
vista64でUTVIDEO7.0.2なんだけど
after effectsの出力ダイアログだとx86しか出てこないんだけど
これは32bitアプリだとx64は使えないって事でいいんですか?
公式のチェックツールでは両方大丈夫でした

319 :名無しさん@編集中:2010/02/27(土) 09:34:45 ID:9jaUPenN
>>318
そう。例えば、64bit版のVirtualDubだと、64bit版のUTが使える。

http://virtualdub.sourceforge.net/

320 :名無しさん@編集中:2010/02/27(土) 16:16:58 ID:at1K1Qv2
>>319
なるほどありがとうございました

321 :名無しさん@編集中:2010/02/28(日) 15:15:04 ID:QndcmVYy
> いつもどおり可逆圧縮スレを眺めていたら、
> 「Ut Video が FFmpeg に移植されるかも」という書き込みが。えっ、マジ?
ワwwwwロwwwwwwタwwwwwwwwww

とは言え実現するかはまだわからんのね

322 :名無しさん@編集中:2010/02/28(日) 18:57:04 ID:ny3Syl1S
フレーム分割数って何?
ググってもよくわからないんだけど、誰かkwsk教えて

323 :名無しさん@編集中:2010/02/28(日) 19:32:45 ID:/e+KM8qW
"フレーム分割数"の検索結果 50 件中 1 - 50 件目

したがってそれを使った人にどういうつもりで定義してるか訊くべし

324 :名無しさん@編集中:2010/02/28(日) 19:38:32 ID:/e+KM8qW
あほ相手してたら、実が持たんぞ マニュケ

325 :名無しさん@編集中:2010/03/04(木) 21:32:38 ID:mUh2apLG
デル デジタルハイエンドシリーズ 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 :名無しさん@編集中:2010/03/06(土) 14:09:50 ID:odhZb/Sc
>>325
そんなゴミ誰が買うのかねぇ

http://kakaku.com/prdsearch/prdcompare.asp?PrdKey=K0000033135.00850812704.00851112657.00852512596.K0000049736

327 :名無しさん@編集中:2010/03/06(土) 14:43:27 ID:ZA2Bi+RH
>>326
スレ違いだが液晶パネルの種類とか色々調べてみるといいよ。あまりこだわらないなら安いので十分。

328 :名無しさん@編集中:2010/03/06(土) 16:44:15 ID:gdshmqlN
>>326
TNで26インチ以上とかゴミすぎ…

329 :名無しさん@編集中:2010/03/06(土) 18:44:52 ID:XC4ICG/g
24IPSでその価格ってところがイイネ。
IPSもピンキリなんだろうけどTNよりゃ万倍マシだろ。

330 :名無しさん@編集中:2010/03/08(月) 06:00:29 ID:ivdOL/7W
>>326
> そんなゴミ誰が買うのかねぇ

331 :名無しさん@編集中:2010/03/09(火) 13:59:48 ID:if26rtdE
可逆圧縮にこだわる人が韓国製TNパネルのクソ液晶って・・・

332 :名無しさん@編集中:2010/03/14(日) 16:53:45 ID:pQuA7OQ9
(スレ違いだが)
「TN,PVA、IPSは、液晶そのものの方式」
「TFT、TFDは、電気の方式」
ってあったけど、>>325>>326もTNじゃないの?


333 :名無しさん@編集中:2010/03/14(日) 17:05:58 ID:Zlf4jfbq
>>325はIPS
リンク先に書いてあるでしょ

334 :名無しさん@編集中:2010/03/15(月) 15:18:57 ID:qrZEFawe
TFDなんて久しぶりに聞いた

335 :名無しさん@編集中:2010/04/13(火) 15:35:17 ID:EgsppNEh
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 :名無しさん@編集中:2010/04/13(火) 15:36:05 ID:EgsppNEh
 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 :名無しさん@編集中:2010/04/13(火) 15:37:13 ID:EgsppNEh

質問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 :名無しさん@編集中:2010/04/13(火) 15:41:37 ID:EgsppNEh
いちおうググりまくったつもりなのですが、CCESPパッチについて詳細に書かれたページが見つからなかったので、
参考になるページなどありましたら、そちらも教えていただければ助かります。
何卒よろしくお願いいたします。

339 :名無しさん@編集中:2010/04/16(金) 09:40:49 ID:Kxee9VMs
ソースの差分見るのが一番はやいんじゃないかな

340 :名無しさん@編集中:2010/04/17(土) 21:05:59 ID:tN0omrFC
>>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 :名無しさん@編集中:2010/04/17(土) 21:09:34 ID:tN0omrFC
あと、
  "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 :名無しさん@編集中:2010/05/25(火) 20:35:35 ID:nttHaDRH
可逆圧縮について質問したいのですが
動画を非可逆圧縮する際は、余程高スペPCでない限りは別作業はしないべきですが
可逆圧縮は元データを消さず劣化させない、という事は
別作業などして負荷をかけても映像は劣化せず、作業結果も同じ(時間や数MB程度の差は出たとしても)
という事でしょうか?
それとも何かしら影響はでますか?

343 :名無しさん@編集中:2010/05/25(火) 20:52:59 ID:zmkVfhdM
釣りだと思うけど一応マジレスしとくと
可逆圧縮は劣化しないから可逆(=元に戻せる)圧縮であって、
可逆でも非可逆でもエンコード中に他の作業をしても画質もサイズも変わらない

344 :名無しさん@編集中:2010/05/25(火) 21:42:00 ID:nttHaDRH
まじかー、ちょっとググッたら時間は延びても画質は変わらないというのが殆どのようだ
昔そういう記事がよくあってそんな感じの知識がついた覚えがあったんだけどなぁ
いつも気にしてたのは無駄だったということかw

という事はゲームプレイや動画見たりなどのグラボ使うようなものも処理には影響なく
処理落ちやコマ落ちなども起きないって事ですね(時間は延びるけど
エラー発生する事が多少あるかもしれない、程度なのかな

345 :名無しさん@編集中:2010/05/25(火) 23:38:36 ID:49J5Z3qU
>>343
圧縮と展開の間が可逆であって圧縮前に非可逆で劣化になることしてるのもあるんだけどね

346 :名無しさん@編集中:2010/05/26(水) 01:04:12 ID:fhrexuM1
動画エンコード中にわざわざエラーの原因作るような作業をする神経が理解できん。


347 :名無しさん@編集中:2010/05/26(水) 08:45:18 ID:+Co2HJ8Z
fpsゲームのfraps撮影動画ファイルを中間ファイルにするため
Huffyuv、UtVideoを使ってaviutl、VirtualDubで試したのですが
どれも元ファイル1.12GBよりも必ず大きくなってしまいます、2.21GBや2.41GBだったり等
コーデックの設定から圧縮選択等を変えても結果が同じです
AMV3の可逆圧縮S2でやっと1.3GBくらいになるのですが、それでもサイズが増えます

調べると、半分とはいえ圧縮されると記述するサイトもあれば
単に容量が増える(変わりに劣化しない中間ファイルができる)としてるサイトもあります
コーデックの説明でもサイズが増えるとあるので容量が増える事自体は理解してるのですが
どの設定をしても容量が減らせない、というのが分かりません

これは元動画が可逆圧縮に適していないという事でしょうか
例え1MBでも非劣化で容量を下げる事ができると思って導入を試みたのですが困ってます
できたらご指導お願いします

348 :名無しさん@編集中:2010/05/26(水) 09:24:45 ID:ZjA24ofn
圧縮と可逆の話混同してない?

349 :名無しさん@編集中:2010/05/26(水) 10:26:55 ID:NfHHf10y
>>347
Fraps(非可逆) → デコード → 可逆
これで容量が増えない方がおかしい

350 :名無しさん@編集中:2010/07/18(日) 14:33:15 ID:Ynk42C8f
マルチスレッドでyuv4mpegエンコ出来るの無い?

351 :名無しさん@編集中:2010/09/29(水) 09:44:59 ID:X30F78Cr
可逆と学習

352 :名無しさん@編集中:2010/09/29(水) 13:57:57 ID:AFc8U8ie
はっふゅーぶい

353 :名無しさん@編集中:2010/09/30(木) 00:35:49 ID:+JL6N/Oc
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 :名無しさん@編集中:2010/10/01(金) 04:26:38 ID:G/8YVDz6
あのデスクトップキャプチャ向け激重超圧縮コーデックかと思ったらアレはMSUだった

355 :名無しさん@編集中:2010/10/03(日) 08:45:14 ID:2vRziSyt
>>353
できれば同じソースでLagarithとMSUでもテストした結果が知りたいけど
自分でやれと言われたらすんません面倒ですとしか言えない。
俺は何を言っているんだ。

356 :名無しさん@編集中:2010/10/03(日) 14:46:41 ID:L+oSyrNC
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 :名無しさん@編集中:2010/10/03(日) 15:10:18 ID:Um+jqucO
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 :名無しさん@編集中:2010/10/03(日) 15:28:06 ID:L+oSyrNC
実写だとかなり縮むね。短めのソースなら使えるかもしれないくらいかな。
こだわりなければMP4でいいから難しいところ・・・

359 :名無しさん@編集中:2010/10/04(月) 11:13:49 ID:6N4ftIot
ソースは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 :名無しさん@編集中:2010/10/04(月) 21:30:28 ID:94byga0d
>>356
>>355ですが、ありがとうございました。参考になりました。

361 :名無しさん@編集中:2010/10/11(月) 21:33:45 ID:JGPnU45K
[UtVideo] バージョン 8.3.0
性能向上
* ULY2: デコード速度優先でエンコードされたものの YUY2 や UYVY へのデコードを高速化した。Core 2 で 12% ほど。
* ULY0: デコード速度優先でエンコードされたものの YV12 へのデコードを高速化した。Core 2 で 5% ほど。
その他
* ULY2: YVYU と VYUY での入出力のサポートを廃止した。
* ULY0: YVYU と VYUY での入出力のサポートを廃止した。



362 :名無しさん@編集中:2010/10/21(木) 16:24:58 ID:D1IyOzNB
Motion JPEG XRって可逆?

363 :名無しさん@編集中:2010/10/22(金) 00:12:15 ID:Fn3OIn+0
>>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 :名無しさん@編集中:2010/10/24(日) 20:37:01 ID:Yy0eYJiI
最終的にDVD規格とかに圧縮するなら中間はx264のcrf10前後で十分な気がしてきた

365 :名無しさん@編集中:2010/10/24(日) 20:42:26 ID:mknDroLy
ならそうしなさい

366 :名無しさん@編集中:2010/11/02(火) 22:46:04 ID:LOO+3AvT
[UtVideo] バージョン 8.5.0
性能向上
共通: x86 でのデコードを 10% ほど高速化した。
共通: x64 版をアセンブラ化し、おおむね x86 版と同程度の速度にした。



367 :名無しさん@編集中:2010/11/18(木) 16:18:39 ID:F9omFO+/
Lagarithのインストーラーの方をダウンロードしたのですが
AviutlでコーデックをLagarithにした動画を真空波動研でみると
使用したコーデックの名前が書かれるところに 不明lags と表示されてる
のですがこれっておかしいですよね?(これといった不具合はありません)
再インストールしても同じでした。

OSは7で32bitです
分かる方がいましたらお願いします。

368 :名無しさん@編集中:2010/11/18(木) 17:22:50 ID:YgD/6AdT
真空波動研は最近の新しいcodecに対応してないという罠?

369 :名無しさん@編集中:2010/11/18(木) 18:30:22 ID:JFZXDDtL
もともと動画が自分が何のコーデックなのか提示するのに使われてるのは
FourCCっていう4文字のアルファベットだけ

真空波動研はその識別文字が何のコーデックなのかというリスト(codecs.ini)を自前で用意してて
動画のFourCCがリストに記載されていたら、そこから正式な名称を持ってくる
そしてリストになかった場合は不明としたうえでそのFourCCが何だったのか表示される
そして今の真空波動研にはLagarithは登録されてない

よって不明lagsというのは「正式名称は不明だけどそのFourCCはlagsだよ」という真空波動研からの回答になる

要するに>>368なんだけど

370 :367:2010/11/18(木) 19:25:40 ID:F9omFO+/
ただ真空波動研に登録されてないだけだったんですね。
これで安心してLagarithが使えます。ありがとうございます。


371 :名無しさん@編集中:2010/11/19(金) 04:01:54 ID:tf8TtVIa
Lagarithはやめとけ
ろくなことがないから
http://mod16.org/hurfdurf/?p=142

372 :名無しさん@編集中:2010/11/19(金) 11:01:39 ID:xGP3k2xQ
日本語でおk

373 :名無しさん@編集中:2010/11/19(金) 23:25:23 ID:1B9oYO3e
UtVideoでええやん

374 :名無しさん@編集中:2010/11/19(金) 23:48:29 ID:DHwbc4lV
俺もUtVideoでいいと思うけど、しばらく残しておきたいようなファイルはLagarithにしてるな。
Lagarithは割と圧縮率がいいから。別に気になるような問題は起きてないし。
まあ圧縮率だけ見るなら他の選択肢もあるだろうけど、なんとなくLagarithにしてる。

375 :名無しさん@編集中:2010/11/19(金) 23:48:40 ID:JmesIe0s
>>373
ドキュメント日本語だしな

376 :名無しさん@編集中:2010/11/20(土) 00:02:15 ID:3SqO1Ild
「デコード速くするためにCPU負荷下げて圧縮率抑えてるのにストレージ転送速度のせいで体感逆やんワロス」
って事らしいからLagarithと同じ手法で圧縮率上げる方向性になるとか

http://umezawa.dyndns.info/wordpress/?p=2118

377 :名無しさん@編集中:2010/11/20(土) 01:10:29 ID:GyIQ5jkS
YLCもなかなかバランス良いよ

378 :名無しさん@編集中:2010/11/20(土) 10:30:47 ID:hBis6+8c
中間ファイルとしてならPフレームまでなら(音ずれの心配もないし)アリだと思うけどなぁ。。

379 :名無しさん@編集中:2010/11/20(土) 10:36:07 ID:3Ow+hu2/
うちはffdshowに採用されてて、将来的な再生互換性がありそうなFFV1で
保存してる。けど再生時の負荷が高いんだよなあ…

380 :名無しさん@編集中:2010/12/01(水) 12:01:17 ID:vIA3KF4h
RGB24での可逆でAMV2MTより高圧縮のcodecって今の所無いよな
つーか何でAMV2MTってこんなに圧縮率高くてエンコード速いんだ?

381 :名無しさん@編集中:2010/12/01(水) 16:29:55 ID:BI6Wau2a
>>380
AMV2MTは確かにエンコ速くてバランス良いんだろうけど、圧縮率はあまりよくないような。
  あまラボ ビデオコーデック・ベンチマーク2009
  http://amalabo.blog35.fc2.com/blog-entry-44.html

バランスの良さはマルチスレッド対応なことと、可逆にしては珍しく(だよね?)、
フレーム間圧縮を使ってるってのが大きいのかな。

382 :名無しさん@編集中:2010/12/01(水) 16:39:12 ID:6QBhF6Dj
圧縮率を優先するのなら、FFV1で良いだろう。
RGB32にも対応しているし、無料で使える。

383 :名無しさん@編集中:2010/12/01(水) 17:27:47 ID:vIA3KF4h
>>381-382
おー割とあるんですね、ありがとうございます
色々と試してみますね

384 :名無しさん@編集中:2010/12/01(水) 20:31:38 ID:l+77uT+S
どこかのサイトで、各コーデックがロスレスであることを証明する為に、エンコした動画の
MD5のハッシュ値をのせてたんだけど・・・どこだったかな。
アレは無圧縮AVIに再エンコしてからハッシュ採ってたんだろうか。
動画ファイル入力したらハッシュ値を出してくれるソフトがあったりしませんかね?

x264ロスレスを扱う必要出てきて、ロスレスであること確認しつつパラメタを最適したく思い。

385 :名無しさん@編集中:2010/12/02(木) 00:17:57 ID:SIzy19jk
ググったらいくらでも出てくる

386 :名無しさん@編集中:2010/12/02(木) 00:46:21 ID:NA89ValL
>>384
y4mで出力してハッシュを比較するとか。

387 :名無しさん@編集中:2010/12/02(木) 06:57:16 ID:gbUDhhSB
x264losslessはソースがYUV420ならロスレスだよ(昔、実際にハッシュの比較したことある)
なんらかのエンバグでも起こってない限り大丈夫

388 :名無しさん@編集中:2010/12/02(木) 08:25:33 ID:BFuMw4BS
レスthx。

>>386
そう、なにか別コーデックにエンコし直ししかないっすかねぇ・・・
まるも氏のAviUtlのプラグインのy4mしか知らないんですが、これ早いのかな?コマンドライン版あれば
何度も比較するの簡単なんスが。

>>387
いちお、YUV444、YUV422(YUY2)、YUV420(YV12)、YUV411各々の色情報のサンプリング方法に
ついては判ってるつもり。

Bフレ1枚入れても可逆なのか、それでavidemuxで分割できるのかとか、YouTubeにうpできるのかとか・・・
いろいろ実験もしてみたいのです。

389 :名無しさん@編集中:2010/12/02(木) 09:10:38 ID:gbUDhhSB
>>388
>コマンドライン版あれば
ffmpegかMEncoderかavs2yuv

>Bフレ1枚入れても可逆なのか
そもそもx264losslessはBフレを使わない(使えない)

>avidemuxで分割できるのか
出来るよ
aviにいれてVirtualDub使ったほうがいいけど

>YouTubeにうpできるのか
現在のところはできない
なぜならつべの鯖が使ってるffmpegが、まだx264losslessのデコードに対応してない、やたら古いものだから

390 :名無しさん@編集中:2010/12/02(木) 14:19:02 ID:XfjN6TL0
そもそもH.264のロスレスは最上位のHigh444 Profileだからな。ずっとサポートされなくてもおかしくはない

391 :名無しさん@編集中:2010/12/02(木) 22:33:43 ID:BFuMw4BS
>>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 :名無しさん@編集中:2010/12/02(木) 22:49:13 ID:HoeB64pC
まんまじゃないと思うよ
x264の名前とかエンコオプションとか消えてるから
そんなことするなら更新しろよって話だが

393 :名無しさん@編集中:2010/12/03(金) 00:00:35 ID:gbUDhhSB
>>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 :名無しさん@編集中:2010/12/03(金) 01:12:17 ID:vDDUuH8G
> ffmpegがローテク
いえ、サーバのデコード環境に合わせてlibavcodecなんかをチューニングしてないのかなーと。
とくに悪気があったワケではないですごめんなさい。m(_ _)m

> ffvhuffかFFV1
そっかffmpeg使ってデコードしてるんならffvhuffって方針もアリですね。FFV1使ったコトない
けどhuffよりファイルサイズ小さくなるなら、こちらも良さそう。

いろいろアドバイスありがとうございました。
なんとか、できるだけ高画質なYouTubeをBRAVIAで視聴出来そうです。

395 :名無しさん@編集中:2010/12/03(金) 02:44:24 ID:cTCCCwNu
なんでチューニング=H.264 High444Profileに対応っていう考えになるんだ

396 :名無しさん@編集中:2010/12/03(金) 07:43:34 ID:vDDUuH8G
>>395
だれもそんなこと言ってないが(汗

このスレから外れると思って>>394に書かなかったんだけど、チューニングとして薄っすら
思いついてたのは、負荷平準化やフォルトトレラントを狙って動作環境にマッチする様な
カスタム化ってことで。ffmpegの構造まんまなモノリシックを止めて、より負荷を分散させ
クラスタ/ファーム内にメッセージパッシングするってゆーよーな(Java RMアプリや
OracleのParallel Serverぽい)。
・・・たかが動画SNSにそんな高可用性求めてどーする!?ってツッコミあるとおもうけど、
妄想として、Googleも冷却コストの低い、ダウンタイムの短いシステム構築に変わりつつ
ある今、YouTubeもそこに乗っかってアップ・エンコが確実に早く終わるようになれば・・・
と。だって最近15分モノのアップに2時間近く、8本に1本は途中で異常終了してる
(たぶんエンコードの最終段階でハング)んで (´・ω・`)

397 :名無しさん@編集中:2010/12/03(金) 23:39:56 ID:cM3Kyqk/
クスリでもやってるの?

398 :名無しさん@編集中:2010/12/04(土) 20:59:06 ID:bAF801fN
リタリンを少々

399 :名無しさん@編集中:2011/02/12(土) 14:02:12 ID:DnZhvj9+
ノータリン


400 :名無しさん@編集中:2011/02/13(日) 20:36:20 ID:2d/4lDdJ
今時リタリン処方する医者いるのか?

401 :名無しさん@編集中:2011/02/13(日) 21:22:09 ID:EeNprgcP
デパスを少々

402 :名無しさん@編集中:2011/02/16(水) 14:07:48 ID:R2zrdEIU
今時HuffyuvMT使ってる奴いる?

403 :名無しさん@編集中:2011/02/16(水) 19:46:34 ID:4ha0m+ls
HuffyuvMT使ってる奴がいたらどうなるんだ?
お前が救われた気持ちになるのか

404 :名無しさん@編集中:2011/02/16(水) 19:55:51 ID:kAVmfmGO
俺がHuffyuvMT使わないことで、他の誰かが救われるなら
俺はよろこんでHuffyuvMTを使おう

405 :名無しさん@編集中:2011/02/16(水) 20:00:59 ID:ylEwuTEZ
Lagarith v1.3.22きた

バグフィックスがあるから使ってるなら更新した方が良いだろうけど
軽く計った限りでは性能面での相対的な立ち位置は大して変わってないみたい

406 :名無しさん@編集中:2011/02/16(水) 20:10:09 ID:P3dr0QLH
欝ビデオがあるからもう要らない

407 :名無しさん@編集中:2011/02/16(水) 21:12:43 ID:ylEwuTEZ
圧縮率は良いけど欝との速度差はもうかなり広いからし
欝がRange Coder積んだらその点さえ負けそう

408 :名無しさん@編集中:2011/02/16(水) 22:09:21 ID:0Eemkvw5
utvideoの頼り劣っている面ってなにないでしょうか

409 :名無しさん@編集中:2011/02/16(水) 22:59:17 ID:h3IX/nWp
不可逆圧縮に比べると縮まないし、無圧縮より再生時負荷が高いね。

410 :名無しさん@編集中:2011/02/16(水) 23:01:49 ID:XEjnxR1Q
つまり可逆圧縮としては他と比べて劣っていると言える部分は無いんだな?

411 :名無しさん@編集中:2011/02/16(水) 23:27:55 ID:h3IX/nWp
誰がそんなこと言ったの?

412 :名無しさん@編集中:2011/02/17(木) 00:32:31 ID:RLFHyDeu
聞こえても仕方がないよね

413 :名無しさん@編集中:2011/02/17(木) 07:06:05 ID:eyhQH2JN
バージョンは1.3.22 2011年2月15日にリリース
ダウンサンプリングすることで修正されたバグは、ビデオの破損が発生していました。このバグを報告するためのカールプリチットに感謝します。
ビデオの破損の原因となったRGBAとマルチスレッドモードでYV12をビデオで修正いくつかのレース条件。これはまた、カールプリチットによって報告されました。
64ビットのバグを修正しましたRGB24ビデオをダウンサンプリングするときにクラッシュを引き起こしたことをビルドします。

414 :名無しさん@編集中:2011/02/17(木) 08:07:04 ID:ePx6y9dE
なにこの機械翻訳

415 :名無しさん@編集中:2011/02/17(木) 17:45:10 ID:9cWwFTnG
>>414
>>413を適当に翻訳すると、
Ver.1.3.22
リリース日:2011/2/15
修正:
ダウンサンプリング時に映像が破損するバグを修正(報告者:カールプリチット)
マルチスレッド時にRGBA・YV12で映像が破損するバグを修正(同上)
64bitOS時にRGB24形式でダウンサンプリングするとクラックするバグを修正

あ、原本はもちろん見てない

416 :名無しさん@編集中:2011/02/17(木) 18:27:46 ID:RcaG5m+X
zip版がないぞー

417 :名無しさん@編集中:2011/02/17(木) 19:05:55 ID:YwJpAfVb
1.3.21のchangelogをちゃんと見ておいたほうがいいな。

・スピード面は大体10〜30%くらい改善。
・Reduced Resolution modeが無くなった。

その他もろもろ。

>>416
ほんとだ、リンク切れてるね。

418 :名無しさん@編集中:2011/02/17(木) 21:54:25 ID:eyhQH2JN
http://lags.leetcode.net/LagarithSetup_1322.exe

419 :名無しさん@編集中:2011/02/18(金) 13:30:44 ID:ZfUyJb7J
zip版きてる

420 :名無しさん@編集中:2011/02/18(金) 18:18:42 ID:Kp7hs+Xw
拾ってきた

421 :名無しさん@編集中:2011/02/19(土) 02:36:46 ID:0Z7Tm2xF
すべてのバージョンコーデックは、しかし、下位互換性があります。

バージョンは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 :名無しさん@編集中:2011/03/07(月) 16:00:17.67 ID:ZSK9KfD8
1.3.23

423 :名無しさん@編集中:2011/03/07(月) 22:37:41.72 ID:5295zh1X
ふむふむ

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 :名無しさん@編集中:2011/03/09(水) 22:40:59.66 ID:rbapAWLl
バージョンは1.3.23 2011年3月5日にリリース
固定バッファは、RGBビデオをデコードする特定の解像度でクラッシュを引き起こしたことをオーバーラン。これを報告して、Nick希望に感謝します。
改善されたわずかにYUY2をデコードするためのSSEとSSE2ルーチンのパフォーマンスが向上します。

425 :名無しさん@編集中:2011/03/29(火) 17:57:43.06 ID:Xy8n4e5A
huffyuvのinf弄ってWin7 64bitにインスコして昔huffyuvで撮った動画をaviutlで編集しているんですけど、
バックグラウンドでWMPやMPCHCでMP3とかを再生すると極端にデコード速度が落ちるんですが、
そういう仕様なんでしょうか?
一コマ送るだけでも1〜2秒掛るくらい遅くなります。

426 :名無しさん@編集中:2011/03/29(火) 18:25:28.46 ID:4jUF++qi
>>425
編集中になんで音楽を・・・BGMのつもりか
CPUも表記せずに「仕様(ry」とか言われても・・・

427 :名無しさん@編集中:2011/03/29(火) 18:32:06.34 ID:3Oafb7I7
余計な作業は別PCでやれってことだろ

428 :名無しさん@編集中:2011/03/29(火) 19:04:16.90 ID:94IqEMSH
>>425
インテルCPUならそうなる事もある

429 :名無しさん@編集中:2011/03/29(火) 19:14:17.50 ID:4jUF++qi
>>428
それってCPUの差とかあんのか?

430 :名無しさん@編集中:2011/03/29(火) 21:59:55.58 ID:uq0ih+i9
i7 950だけどXP(32bit)の時は全く問題ないけどWin7(64bit)だと同じような症状が出るな
AviutlでHuffyuvからx264へエンコ中に動画とか音楽再生すると急にエンコ速度が下がる
CPU使用率70%くらいだったのが10%辺りまで落ちるね
WOW64が原因かもね

431 :名無しさん@編集中:2011/03/29(火) 22:54:46.04 ID:uq0ih+i9
今確認してみたけど重くなるのはHuffyuvで撮ったソースだけだな
まぁ今更Huffyuv使う必要性もないし他の使えばいいんじゃね

432 :名無しさん@編集中:2011/03/29(火) 22:57:09.90 ID:4jUF++qi
>>431
今やHuffyuvはソフト互換性が抜群なだけだしな
>>430
メモリのために64bitをインストールしたのか・・・

433 :名無しさん@編集中:2011/03/29(火) 23:23:46.35 ID:Wg19T5hX
ttp://support.microsoft.com/kb/948066/ja?sid=013a5e9525e5597eee063f3e25812c34
可能性の一つとして。

434 :名無しさん@編集中:2011/03/30(水) 19:14:09.87 ID:dcMJf6XY
>>426
すみません、Core i7 970です。
BGM流しながら、ここのフレーズはどのシーン切り出そうかな〜とかやりません?

>>430-431
検証ありがとうです。
やっぱりWin7 64bitだとそうなりますよね。
他のコーデックだと問題無いのに、huffyuvだけ異様に遅くなるので、気になってました。
これから撮る素材はいいとして、今まで撮ったhuffyuvの素材が少々面倒ですよね。

435 :名無しさん@編集中:2011/04/13(水) 04:27:29.36 ID:l6/a6OON
>>384
いまでもここ見てるかどうか知らんが
つべがx264losslessでもいけるようになったみたいだぞ
http://forum.doom9.org/showthread.php?p=1491969#post1491969

436 :名無しさん@編集中:2011/04/14(木) 15:07:01.36 ID:W49rWrsX
1.3.24

437 :名無しさん@編集中:2011/04/14(木) 20:16:08.67 ID:zJbyhWjB
utvideoの圧縮率優先にする方法が書かれている場所ないでしょうか
いろいろな所に言っても書かれてないので教えてください

438 :名無しさん@編集中:2011/04/14(木) 20:34:22.00 ID:DixiBcgy
>>437
コーデックの設定いじればいいだろ・・・

439 :名無しさん@編集中:2011/04/14(木) 20:47:46.05 ID:zJbyhWjB
デコードと圧縮の優先順位がある項目をクリックしても保持してくれない
確認するとデコード優先に戻ってしまうので困ってる

440 :名無しさん@編集中:2011/04/14(木) 21:38:16.06 ID:cNRsyt+9
http://umezawa.dyndns.info/wordpress/?p=1890

441 :名無しさん@編集中:2011/04/15(金) 05:49:55.09 ID:y3ZlBa2O
バージョンは1.3.24 2011年4月10日にリリース
南南東&ビデオを破損している原因のRGBビデオMMX命令中央修復ルーチンのバグを修正しました。このバグを報告するためのウーヴェJahnさんに感謝します。
SSE命令は、いくつかのMMX命令中央修復ルーチンで使用されていたバグを修正、これはSSEをサポートしていないプロセッサ上でクラッシュを引き起こすでしょう。
オーバーホールは、揮発性のフラグではなく、イベントを使用して、ループを待つマルチスレッド。これは、マルチスレッドモードでパフォーマンスが若干改善し、より安定性を提供します。
中央修復MMX/SSE/SSE2ルーチンを改善、これはわずかにデコード速度を上げてください。
色空間をダウンサンプリングのSSE2ルーチンが追加されました。 SSE2をサポートするマシン上で色空間を変更するエンコーディングに時間が短縮されます。

442 :名無しさん@編集中:2011/04/17(日) 14:14:12.50 ID:xV0nLUMK
日本語変換のバグを(ry

443 :名無しさん@編集中:2011/04/20(水) 02:23:31.22 ID:KneMNm8J
やっぱりutvideo優秀だな

444 :名無しさん@編集中:2011/05/08(日) 14:53:48.59 ID:YSb8xL1t
UtVideo 9.0.0出てた

445 :名無しさん@編集中:2011/05/09(月) 00:04:30.10 ID:zJfGyxAk
バグ処理マチかな


446 :名無しさん@編集中:2011/05/09(月) 17:45:00.50 ID:7QvxvUeg
結局Lagarith使っちゃうんだよな。

447 :名無しさん@編集中:2011/05/10(火) 01:53:48.03 ID:4js3lE6D
今までも使ってないしこれからも使わない

448 :名無しさん@編集中:2011/06/03(金) 00:29:10.31 ID:P2fjDclH
Huffyuvは相変わらず万能だな。
編集もしやすいし。
H.264 losslessで最後は出力するだけ。

449 :名無しさん@編集中:2011/06/03(金) 19:50:12.13 ID:TDguYA4X
Lagarith使ってたけど、なんとなくUtVideoに切り替えていた
まあHuffyuvの万能さは異常なので複数ソフトで使い回す際に使っている

450 :名無しさん@編集中:2011/06/05(日) 01:11:55.76 ID:vFEy8e2o
GaeBolgVideoCodecのがでてた前のzeroの後継だけど
utより処理は遅くて少し縮む感じ。
Lagarithよりいいかとかvctestはやり方忘れたのかできないので興味ある方に。


451 :名無しさん@編集中:2011/06/07(火) 13:12:48.99 ID:/soAdY+0
>>448
utがある中でHuffyuvが使えるってとこあるのでしょうか?

452 :名無しさん@編集中:2011/06/07(火) 16:24:17.02 ID:/0WmlFFl
>>451
可能でなく使役でか・・・
汎用のGUIエンコーダ(MediaCoderとか)とかにデータ食わせる時とかかな?

453 :名無しさん@編集中:2011/06/07(火) 22:01:55.18 ID:LTfw2/IX
ふっふぃーより扱いやすいのあるか?

454 :名無しさん@編集中:2011/06/13(月) 18:21:01.32 ID:t/x/k1dY
HuffyuvはWin7 64bitで妙な処理落ちするからもう使ってないな。

455 :名無しさん@編集中:2011/06/13(月) 19:35:33.44 ID:h56hxMjx
まだまだXPで粘ってるけどPCの足回りやらいろいろで、そろそろ限界だよなぁ

456 :名無しさん@編集中:2011/06/18(土) 00:15:44.67 ID:U/J2pNTz
7いいよぉ
一度使い始めると(もちろん相応のビデオカードなどとセットでだけど)XPには戻れん

457 :名無しさん@編集中:2011/06/23(木) 09:48:17.39 ID:KcZLZuZR
http://forum.doom9.org/showthread.php?p=1500141#post1500141

Lagarith 1.3.25 ぱねえ

458 :名無しさん@編集中:2011/06/23(木) 10:35:56.74 ID:4Hw9PGNc
>>457
一見凄そうに見えるけど、UTはその1.5倍は速いんだよ
しかも圧縮率も1080pの5000フレームでLagarith8.45GBに対してUt8.51GBとかだし

459 :名無しさん@編集中:2011/06/23(木) 17:55:27.96 ID:aeTMQb04
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 :名無しさん@編集中:2011/06/24(金) 06:51:24.73 ID:A0Eom7o3
個人でWin使ってる分にはUtVideoとか好きなの使えるけど
WinとMac両方で使える可逆圧縮でいいのないもんかね
QuickTimeのPNG圧縮はエンコードもデコードも遅すぎて辛い

461 :名無しさん@編集中:2011/06/24(金) 07:18:11.80 ID:2RxUnHL9
ffmpeg系使えるならhuffとかロスレスh264とか

462 :名無しさん@編集中:2011/06/24(金) 17:07:07.79 ID:kEIsivGS
>>460
ffmpeg -vcodec ffv1

463 :名無しさん@編集中:2011/07/05(火) 15:53:24.40 ID:96NYE2hQ
このスレでいいのかわかりませんが、質問があります。
digaでBDに焼いて、AnyDVDHDでHDDに保存してますが
m2tsだと1ファイル22GBとか巨大なので、可逆圧縮でエンコしたいと思ってます。
エンコ後、またm2tsに戻してBDに焼くことも考えています。
win7の64bit環境ですが、何か目的にあうようなソフトはありますか?

464 :名無しさん@編集中:2011/07/05(火) 16:10:32.21 ID:ABArcJpq
BDは非可逆圧縮なので、それをデコードして可逆圧縮なんてするととんでもなくファイルサイズがでかくなる
やめとけ

465 :名無しさん@編集中:2011/07/05(火) 17:56:05.00 ID:1eWKsqeC
テラいくか

466 :名無しさん@編集中:2011/07/05(火) 23:02:30.57 ID:w8aDM4Gm
m2tsをじっぷで圧縮すれば… いやなんでもない…

467 :名無しさん@編集中:2011/07/06(水) 08:02:08.42 ID:dye6pgB6
THcomp使えばどんな動画も1byteに圧縮できるのを知らないのかよ

468 :名無しさん@編集中:2011/07/06(水) 15:36:55.89 ID:QQ5trXav
>>464
ありがとうございます。
そうなんですか…
>>466
しょっちゅうみる動画じゃないし、最悪それでもいいかなと思い始めてます。
>>467
釣られんよw

469 :名無しさん@編集中:2011/07/06(水) 15:45:48.93 ID:q1q8gUbF
THcompとかおっさん過ぎだろw

470 :朝食にひじきの煮つけを食べようと思ったら松崎しげるだった:2011/07/22(金) 05:48:00.86 ID:upLaRVOf
しwwwwwげwwwwwるwwwwwwwwwwwwwwwwwwwwwwwwww

471 :名無しさん@編集中:2011/07/25(月) 14:08:55.35 ID:oecJcBtM
エイトマン エイトマン ハイハイハイハイハイ

472 :名無しさん@編集中:2011/07/25(月) 21:42:39.30 ID:34eewnQ9
Xメディアプレーヤーで色々やってるけど容量が増えるばかり
AVI〜をDLしても対応してないと失敗ばかり
どうしたらいいのかわからない

誰かにこんなおいらを導いて(;_;)

473 :名無しさん@編集中:2011/07/25(月) 21:49:55.18 ID:WQgcSKxx
Yahoo知恵袋で聞け

474 :名無しさん@編集中:2011/08/26(金) 14:19:52.39 ID:PM52VG/U
ログ復活

475 :名無しさん@編集中:2011/09/12(月) 22:41:47.79 ID:Qt3bVul8
[UtVideo] バージョン 10.0.1
不具合あったらしいから一応

476 :名無しさん@編集中:2011/09/27(火) 02:46:56.89 ID:JRgyVHYK
1.3.26

477 :名無しさん@編集中:2011/09/27(火) 03:10:57.44 ID:YOJGzyZq
なにかとおもったらLagarithか

478 :名無しさん@編集中:2011/09/27(火) 03:57:27.04 ID:HczLwb1z
2011年9月25日にリリースされたバージョン1.3.26
アドビ製品とのクラッシュを引き起こしたデコーダでバッファオーバーランを修正しました。
このバグを報告されたすべての方々に感謝。壊れている可能性が1.3.20およびそれ以前のバージョンから特定のソリッドカラーのフレームの原因となったエラーを修正しました。
これを報告し、サンプルのビデオを提供するためのルークマッケイ - モリスに感謝します。

479 :名無しさん@編集中:2011/10/09(日) 21:42:18.67 ID:npKzUt+i
YULSとMSUは恐ろしく縮むけどデコード時の負荷がすさまじいな
h.264みたいにGPUでエンコード/デコードってできないもんなのかな?

480 :名無しさん@編集中:2011/10/10(月) 04:12:40.22 ID:oJ44kTPo
よほどメジャーにならなきゃGPU側に対応しようという動機が発生しない

481 :名無しさん@編集中:2011/10/10(月) 12:07:30.85 ID:aHwafZO2
>>479
何それ?ウマイの?

482 :名無しさん@編集中:2011/10/10(月) 13:42:29.38 ID:fkfIJBmM
エンコードデコードともにマルチスレッド化が先だろうね
H264の再生の444・422対応のほう進めてくれたほうがいいかな

483 :名無しさん@編集中:2011/10/10(月) 19:30:38.08 ID:5YoO9x21
x264でlosslessで出力したらなんとも説明しがたい変な映像が出てくる
MLCの標準よりかなり縮んでDXVAが使えるのにこれじゃ意味がない

484 :名無しさん@編集中:2011/10/10(月) 19:39:13.30 ID:cn/gLKIK
DXVAでロスレスは再生できなかったと思うが

485 :名無しさん@編集中:2011/10/14(金) 17:09:12.30 ID:Z4r9fstf
動きの激しいゲームの動画をMSUで圧縮したら(512*384,24fps)E5200だとまともに再生できない
んだがi7 2600Kなら遅延なく再生できるのだろうか?

486 :名無しさん@編集中:2011/10/14(金) 18:26:53.45 ID:PMVfUDuK
無圧縮や可逆圧縮は再生向きのコーデックじゃなく編集などのためのものなんだから
遅延なく再生しようという考えがまず間違いなんじゃないだろうか。

できるのかどうかという点については興味はあるけど。

487 :名無しさん@編集中:2011/10/14(金) 18:28:58.32 ID:PWXCNBnX
>>485
うp

488 :名無しさん@編集中:2011/10/15(土) 18:45:33.45 ID:zPhORwRC
今更だけど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 :名無しさん@編集中:2011/10/15(土) 19:03:45.47 ID:zPhORwRC
AMV2MTを忘れてた。

AMV2MT 2.20h(R2標準可逆) サイズ778MB、エンコード時間4分37秒

490 :名無しさん@編集中:2011/10/15(土) 19:12:48.47 ID:GeB6NdQN


491 :名無しさん@編集中:2011/10/15(土) 20:03:13.75 ID:UMMqN8T+
[vctest] ベンチ更新 & MSU Lossless は稀に化ける…?
http://umezawa.dyndns.info/wordpress/?p=341
マルチスレッド対応してる他のはエンコード時間もっと短くなるから厳しいね

492 :名無しさん@編集中:2011/10/15(土) 20:09:37.32 ID:zPhORwRC
あと、一応書いておくとMSUのデフォルト設定である
  「Allow colorspace conversion」
は、公式サイトにも書いてあるとおり
  「内部でYV12に変換して圧縮するモード」
なので、RGBやYUY2のロスレスにはならない。YV12変換が入ることで色が混ざる。
RGBやYUY2で可逆にしたい場合は必ず「Absolutely lossless」を選ぶ必要がある。

493 :名無しさん@編集中:2011/10/15(土) 20:11:43.06 ID:zPhORwRC
>>491
うげ、「Absolutely lossless」でも化けることがあるのか・・・なおさら使えないな・・・。

494 :名無しさん@編集中:2011/10/15(土) 20:19:19.30 ID:UMMqN8T+
>>356でそういや試してたなと

495 :名無しさん@編集中:2011/10/15(土) 23:26:25.73 ID:N5jvpMjO
Lagarithより縮む可逆コーデックってあるもんなんだな・・・
UtVideoの使い勝手良すぎてそれしか使ってないけど

496 :名無しさん@編集中:2011/10/17(月) 01:17:42.40 ID:bBO9KNbx
ttp://www.ffmpeg.org/trac/ffmpeg/ticket/534

497 :名無しさん@編集中:2011/10/18(火) 09:56:44.68 ID:S9zIBTCk
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1de357d6da3c4e4c1c47c8be182efbb4d4d8d7b4
UtVideoがffmpegでデコードできるようになった

498 :名無しさん@編集中:2011/10/18(火) 11:12:50.78 ID:PBH9fy/K
肝心のffmpegの行方のほうががががががが

499 :名無しさん@編集中:2011/10/18(火) 12:29:58.72 ID:QtuAGLUt
キタ━━━━━━(゚∀゚)━━━━━━ !!

500 :名無しさん@編集中:2011/10/18(火) 13:28:09.33 ID:NqVDyPBi
http://lists.libav.org/pipermail/libav-devel/2011-October/012736.html
安心しろlibavにもパッチが来てる

501 :名無しさん@編集中:2011/10/18(火) 13:44:18.37 ID:ntv0mBze
UtVideoの作者はFOURCCを変えたいみたいなこと言ってたけど、どうなったんだろう。
  http://umezawa.dyndns.info/wordpress/?p=1522

502 :名無しさん@編集中:2011/10/19(水) 19:47:14.44 ID:+LJw2ClN
http://git.libav.org/?p=libav.git;a=commit;h=0d8506b8c52659c5bfff9535391d5e95ddcd45f1
libavにUtVideoのnative decoderコミット

503 :名無しさん@編集中:2011/10/26(水) 16:56:11.04 ID:oVgO/3aJ
ffdshowに搭載まだかお


504 :名無しさん@編集中:2011/10/29(土) 22:07:29.41 ID:d4NjNr+X
MLCとかMSUとかYULS対応のハードウェアエンコーダが出たら1920*1080のゲーム動画を
簡単に無劣化でキャプチャーできてありがたいんだが・・・

505 :名無しさん@編集中:2011/10/29(土) 22:32:21.82 ID:Ip0Lwjle
1080pネイティブ解像度のゲームなんて数える程しかなかろ

506 :名無しさん@編集中:2011/10/29(土) 22:43:31.39 ID:aIVtXAd7
http://blog-imgs-30-origin.fc2.com/a/m/a/amalabo/amd_rgb_fez.jpg
昔は圧縮率高いの要望してた頃もあったな・・・
今はもうそんな需要減ってるだろうけど

507 :名無しさん@編集中:2011/10/31(月) 01:00:37.85 ID:rn6A7VRP
Huffyuv_mtのx64ネイティブ版ってないの?

508 :名無しさん@編集中:2011/10/31(月) 01:30:52.72 ID:4tHqJt93
何に使うんだよ
おとなしくUtVideo使っとけよ

509 :名無しさん@編集中:2011/10/31(月) 17:16:47.87 ID:Pd+QtPdL
なぜかマルチコアに最適化されてないコーデックが多い・・・(YULS,MSU,MLC等)
最適化してくれー

510 :名無しさん@編集中:2011/10/31(月) 17:26:22.29 ID:VrOzl7aC
もう荒らし認定していいか?

511 :507:2011/11/01(火) 21:43:44.75 ID:HB+E7VUa
>>508
単に古いデータを引っ張り出してきて
64bitソフトに読ませたい時に欲しいなーと思っただけ
使えるコーデックに再変換すりゃいいんだけど
その度に変換するのもなんだかなと

512 :名無しさん@編集中:2011/11/01(火) 22:39:09.15 ID:XXnbf4nL
Proxy Codec 64

513 :名無しさん@編集中:2011/11/01(火) 23:02:20.32 ID:HB+E7VUa
>>512
前に試したけど使ってるソフトと相性悪いんで・・・
FourCCを変更しちゃう方が早いかな
テストした限りは読めるようだけど

514 :名無しさん@編集中:2011/11/15(火) 13:49:40.13 ID:bJMDPy80
10bit対応のコーデックまだー

515 :名無しさん@編集中:2011/11/17(木) 21:13:03.92 ID:dp1bBjEM
x264のロスレスでいいじゃん

516 :名無しさん@編集中:2011/11/23(水) 09:02:45.24 ID:Stcxfiie
h.265のロスレスがどれくらい縮むか気になる・・・

517 :名無しさん@編集中:2011/12/01(木) 20:27:27.42 ID:flqYdsAD
てs

518 :名無しさん@編集中:2011/12/16(金) 19:51:30.34 ID:FkRYFAXR
1.3.27

519 :名無しさん@編集中:2011/12/16(金) 20:09:21.13 ID:n6c8f+h8
>>518
Lagarithか。なんでお前はいつもバージョンだけしか書かないんだよw

520 :名無しさん@編集中:2011/12/22(木) 23:44:09.76 ID:tAC7YqUs
知ってると思うがUtVideo更新されてるな
微更新だがな


521 :名無しさん@編集中:2011/12/23(金) 12:17:35.71 ID:P4uECq3Y
>>520


522 :渚カヲルψ ◆.NERVpDWGM :2012/01/03(火) 07:09:22.97 ID:oY5d2e0f
中国の偽造技術は笑えるほどのものも。

とあるPC偽物語。

ある日、NERVに「このハードディスクに鉄道動画を全部転送したにもかかわらず、最後の方が尻切れしてしまっている。」との
依頼が入り、問題のハードディスクが届いた。その外付けドライブのネジを外して開封すると…。思わぬ展開となった。

実は、重さ稼ぎのための鉄の錘と、256MB程度の超小型のUSBメモリが入っているだけであり、USBメモリには怪しげなマイクロチップが張り付いていた。
それをNERVのパソコンにつなげて、認識させると、ハードディスクドライブとして認識するものの、容量は500GBと誤認識していた。

実は、あのマイクロチップは、容量を偽装するためのプログラムが入ったマイクロチップであるのだ。
USBメモリの容量がいっぱいになると、後ろの方から削除していく。ファイルの状況を調べないと発覚しにくい、

523 :名無しさん@編集中:2012/01/03(火) 18:22:25.65 ID:uffKxeGO
キモイのが涌いたな

524 :名無しさん@編集中:2012/01/05(木) 08:31:55.46 ID:VeCCeEFV
Ut Video Codec Suite8.5.0から新しく10.2.2をインストールしたのですが
AviUtlで見てみると10.2.2が反映されていない状態です。
再起動もしてみましたが同じでした。
10.2.2はバイナリと書かれているところから落としました。

Windows7 32bitです。
よろしくお願いします。

525 :名無しさん@編集中:2012/01/05(木) 13:15:19.80 ID:KaPpZTi+
こちらこそ

526 :名無しさん@編集中:2012/01/05(木) 19:25:28.82 ID:aWOF3iXu
>>524
うちもそんな感じで8.5.0までは正常
8.5.1以降すべてのバージョンが使えない

環境はWIndows7 64bit

527 :名無しさん@編集中:2012/01/05(木) 21:10:53.51 ID:mYBsoTwh
10.2.1の記事では
  「Windows では、必ず旧バージョンをアンインストールしてから新バージョンをインストールしてください。」
という注意書きがあるな。

或るプログラマの一生 ≫ [UtVideo] バージョン 10.2.1
http://umezawa.dyndns.info/wordpress/?p=2991

528 :名無しさん@編集中:2012/01/05(木) 21:48:56.14 ID:aWOF3iXu
毎回アンインストールしてからバージョンアップしたんですけどダメになってしまったんです
以前vclistで確認した時のメモだと
8.5.0ではエンコーダはVCM、DMO、DirectShow、デコーダはVCMが表示されていて
10.0.2ではエンコーダはDMO、DirectShow、デコーダはDMOが表示されてる
x86版、x64版共に同じ状態です。

529 :名無しさん@編集中:2012/01/06(金) 02:14:38.97 ID:/zKcGccN
RGB24 → YUV444へは劣化なしで変換は無理って考えで良いですよね?

530 :名無しさん@編集中:2012/01/06(金) 03:35:20.00 ID:nxB1LuNv
RGBが8bitでYUVが12bit程度なら劣化はないよ

531 :名無しさん@編集中:2012/01/06(金) 04:28:04.30 ID:FAE//d9M
始めまして。困ってどうしていいのか分からず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 :名無しさん@編集中:2012/01/06(金) 05:42:15.31 ID:nxB1LuNv
劣化がどうこうと能書き垂れる前に、まずは可逆圧縮と非可逆圧縮の違いを理解してこい

533 :名無しさん@編集中:2012/01/06(金) 09:44:11.35 ID:SJbAnGou
可逆はそういうもん
コーデックによって多少違うが、だいたい5分=1GBくらいだと思っておけ

534 :524:2012/01/06(金) 15:00:26.37 ID:Brql+Xlk
>>527
旧バージョンをアンインストールして
もう一度入れてみたら無事成功しました。

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

535 :名無しさん@編集中:2012/01/06(金) 21:40:38.38 ID:/zKcGccN
>>530
なるほど!参考になりましたありがとうございます。

536 :名無しさん@編集中:2012/01/06(金) 22:46:17.30 ID:S8oFV5kG
8bitのYCbCrがRGB24(約1670万色)のうちどれだけの色を表せるかというと、

  Rec601(圧縮レンジのBT.601)の場合→約296万色
  PC.709(フルレンジのBT.709)の場合→約440万色

となるらしい。(ソースはツイッター)
もっと詳しく知りたいのだけど、Rec709やPC.601、それと10bitなどのHigh bit depthでどうなるのかとか、
そのへんがまとまってるサイトってないのかな。

537 :名無しさん@編集中:2012/01/06(金) 22:52:46.33 ID:sbz9eZc0
またスレ作ってそこでやれよ
そこらじゅうでするな

538 :名無しさん@編集中:2012/01/07(土) 22:35:56.31 ID:+EyTcx8n
>>536
601と709の差ってそんなにあるの?


539 :名無しさん@編集中:2012/01/07(土) 23:49:06.80 ID:jXd94D01
ut ver上がってた

540 :名無しさん@編集中:2012/01/08(日) 02:00:26.60 ID:Oc7ESjjV
>>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 :名無しさん@編集中:2012/01/17(火) 21:03:26.05 ID:IjLINVQY
キャプチャをHuffyuv_mtからUtVideoに変えたのですが
なぜかUtVideoだとシークバーでのスキップが出来ない・・・
スキップすると必ず再生アプリが固まります。
WinMediaPlayer11使ってるのですけど何が問題でしょか?

542 :名無しさん@編集中:2012/01/18(水) 10:14:58.60 ID:G3D+XmUs
ニコ厨が作った糞コーデックなんかいらん
Lagarithでええ

543 :名無しさん@編集中:2012/01/18(水) 10:39:26.15 ID:kbPrc2HT
お前が着てる服や食べてる食事にもニコ厨の手が入ってるかもしれないから
服を着るのも食事をするのもやめたほうがいいかもしれんぞ。
日本はニコ厨が吐いた空気があふれてるから呼吸もやめないとやばいかもな。
生きづらい世の中になったもんだ。

544 :名無しさん@編集中:2012/01/18(水) 11:42:05.71 ID:10V8Hp13
そもそも2ちゃんの創始者はいまやニコ厨だったりしてな
まあでもニコ厨抜きにしても普通に生活は出来る気がするな

545 :名無しさん@編集中:2012/01/18(水) 13:42:11.25 ID:+kecHnTw
ffmpegとかで読み込めないってところが問題ではあるがLagarithはいけるのかね

546 :名無しさん@編集中:2012/01/18(水) 18:04:31.17 ID:xZxX6q9j
UtもLagarithもavcodecは対応済みだろが
Lagarithは基本設計が糞なせいかイマイチみたいだけど

547 :名無しさん@編集中:2012/01/19(木) 19:26:09.35 ID:G0Pn2Bsr
Lagarithはスキップ出来ました。
Huffyuv_mtより良い様なのでしばらく試してみます。

548 :名無しさん@編集中:2012/01/19(木) 20:49:49.92 ID:GsUpLAoe
Lagarithはエンコードもデコードも遅いからキャプチャ向きじゃないという認識だったんだけど
いまどきのPCの性能ならキャプチャ時に使っても問題ないもんなのかな。
解像度とかにもよるんだろうけど。

549 :名無しさん@編集中:2012/01/19(木) 23:00:29.14 ID:xZJc1VOa
Pen4 3.4Gマシン時にSD解像度のキャプに問題なく使ってたよLagarith

550 :名無しさん@編集中:2012/01/22(日) 19:52:45.36 ID:SNY89T75
解像度にもよるがLagarithは圧縮率が高い分ドライブのI/O帯域によるオーバーヘッドが少ないから今時のCPUならほぼドロップしない
~~~~~~~~~~~~~~~~~

551 :名無しさん@編集中:2012/01/23(月) 17:32:18.94 ID:qsXS0uHZ
LagarithやUtVideoなどの圧縮率重視のコーデックだと
HDサイズのまま30fpsとかで録るのは今時のCPUでも厳しい

552 :名無しさん@編集中:2012/01/23(月) 19:00:00.70 ID:qym/b/n8
CPUよかHDDがボトルネック

553 :名無しさん@編集中:2012/01/23(月) 19:44:43.13 ID:d8E89iNz
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 :名無しさん@編集中:2012/01/24(火) 01:24:53.35 ID:n/3wh7Td
UtVideoは1920x1200 60fpsで余裕でキャプできたよ。Lagarithは60fpsに届かない。
CPUは3960Xでテスト。

555 :名無しさん@編集中:2012/01/24(火) 01:28:22.73 ID:/WyLlZET
>>554
それは圧縮率とHDDの転送速度がボトルネックっぽいな

556 :名無しさん@編集中:2012/01/24(火) 01:38:20.68 ID:n/3wh7Td
>>555
Lagarithのほうが縮むよw
SSD複数使って糞速い環境なんで書き込みのボトルネックは無い。
つーか無圧縮で保存できる環境だぜ。

557 :名無しさん@編集中:2012/01/24(火) 21:47:47.28 ID:l4BWd68R
キャプチャ用のドライブはクラスタサイズを32Kや64Kでフォーマットしてる

558 :名無しさん@編集中:2012/01/24(火) 21:53:21.03 ID:tyegT/ix
その解像度、fpsでx264可逆キャプチャしてみようぜ

559 :名無しさん@編集中:2012/01/24(火) 22:01:04.69 ID:rloPjRqt
キャプチャドライブのファイルシステムはexFATが適しているとMicrosoft自身が言ってる
クラスタサイズ128KBだから断片化しにくい
http://support.microsoft.com/?kbid=955704

>exFAT ファイル システム ドライバーには、パフォーマンスを向上させるために、次の高度な構造が組み込まれています。
>
> クラスター ビットマップ高速の割り当て
> ファイルあたりの連続した少し高速のファイルへのアクセス
> 優れた連続したディスク上のレイアウト (便利映画を録画用)


560 :名無しさん@編集中:2012/01/26(木) 00:58:15.70 ID:j/jGob8r
>>559
OSが落ちたらスキャンディスク実行しなきゃいけなくない?
その分高速だろうけど

561 :名無しさん@編集中:2012/01/26(木) 19:15:23.82 ID:/hhlDJW9
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 :名無しさん@編集中:2012/01/26(木) 21:45:55.53 ID:2OU9XvdS
とりあえずMSUは絶対無理だな

563 :名無しさん@編集中:2012/01/26(木) 23:11:34.28 ID:QqBdvRGA
x264vfwのlosslessでキャプチャーしたほうがマルチスレッド対応という意味で良い希ガス

564 :名無しさん@編集中:2012/01/28(土) 23:05:11.80 ID:6gmciLdn
AMVってどうなの金払って使う価値あるの?

565 :名無しさん@編集中:2012/01/28(土) 23:52:52.74 ID:sybfrf+e
>>564
ロゴが入るとはいえ無料で落とせるんだから自分で試してみればいいだろ。価値基準なんて人それぞれだ。

566 :名無しさん@編集中:2012/01/29(日) 04:01:59.87 ID:6nGO6jNb
output cspで4:2:0以外の色空間の指定出来るx264のコーデックってありせん?
x264vfwで可逆キャプチャしてるのですがoutput cspのコマンドに対応してないらしくエラーになります(amarecoco系列とdxtoryは試した)

567 :名無しさん@編集中:2012/03/19(月) 18:41:28.08 ID:+1maz4XF
UtVideoを問題なく使用できていたWindows7 x64に
Microsoft Windows Media Video 9 VCM
をインストールしたら
それ以降UtVideoが正常にデコードできなくなった。

デコードしようとするとWindows全体がビジーになって
アプリが応答なしになる。
動画の再生時間分だけの時間が経過したらもとに戻るけど。

Microsoft Windows Media Video 9 VCM
をアンインストールしたら、UtVideoは元通り正常に使用できるようになった。

MS公式コーデックが悪さするってなんなの???

568 :名無しさん@編集中:2012/03/19(月) 18:48:34.89 ID:pCyrw1yR
他社を排除するMSのいつもの手じゃん

569 :名無しさん@編集中:2012/03/19(月) 19:56:42.63 ID:yzbUsH7O
>>567
最近はLAV FiltersにUtVideoのデコーダーが入ったりしてるけど、そういうコーデックパックとか入れたりしてない?

あと、UtVideoは10.2.1からインストーラが変わって、
  「Windows では、必ず旧バージョンをアンインストールしてから新バージョンをインストールしてください。」
と記載されてたけど、上書きインストールを続けておかしくなってるってことはない?

それとUtVideoのバージョンや、使ったプレイヤーなんかも書いたほうがいいと思う。

570 :名無しさん@編集中:2012/03/19(月) 20:48:21.78 ID:+1maz4XF
>最近はLAV FiltersにUtVideoのデコーダーが入ったりしてるけど、そういうコーデックパックとか入れたりしてない?

してない
もともとはUtVideo以外まったく何も追加コーデック入れてなかった

んでそこにWMV9入れた途端におかしくなった

>あと、UtVideoは10.2.1からインストーラが変わって、

問題なく動いてて不満がなかったので、9.8.?ぐらいのをずーっと使い続けてた
その状態にWMV9入れたらおかしくされた

WMV9アンインストールしても微妙にまだおかしいので、Windows7自体を再インストール
せんといかんかもしれんな
めんどっくさ

571 :名無しさん@編集中:2012/03/19(月) 23:40:45.98 ID:3rpVqAUJ
>>567
Microsoft Windows Media Video 9 VCM は
Windows7 では動作保障外
Microsoftはインストールするなと言っている


572 :名無しさん@編集中:2012/03/19(月) 23:46:21.07 ID:yzbUsH7O
Microsoft Windows Media Video 9 VCMって、日本語のダウンロードページ消えちゃったよね。
英語ページからはまだダウンロードできるみたいだけど。

573 :名無しさん@編集中:2012/03/20(火) 01:07:24.35 ID:rE6SwJ9S
>>571
まじで?
まったくそんな注意でてこなかったわ注意出て来なかったわ

>>572
んー?
MSトップから探さずにGoogleの検索窓にワード入れて出てきたリンクリンク
クリックしたら普通の日本語ダウンロードページが出てきたからなんの疑い
もなく入れちゃったわw

574 :名無しさん@編集中:2012/03/20(火) 01:20:23.28 ID:tp+ypQHE
>>573
Microsoft Windows Media Video 9 VCM の替わりに
Microsoft Expression Encoder 3 をインストールしろってさ

575 :名無しさん@編集中:2012/03/20(火) 09:30:30.96 ID:rE6SwJ9S
>>574
ありがとう

でももう9 VCM入れてそのせいでWindows全体おかしくなっちゃったんで、
再インストールします……

そのあとで、もしWMV9コーデックを扱いたくなる時が出たらそちら入れますね
当面入れないと思う
今回必要になったのイレギュラーだし

576 :名無しさん@編集中:2012/03/20(火) 23:21:02.87 ID:N1TcD24Z
>>570
DirectShowは次々にコーデックをロードして目的のフォーマットを扱えるか
試す仕組みになってるから、動作しないコーデックがインストールされると
他のフォーマットも影響受ける可能性があるよ。

>WMV9アンインストールしても微妙にまだおかしいので、
アンインストールした後再起動してみた?

577 :名無しさん@編集中:2012/03/24(土) 00:46:32.19 ID:29iocYaU
ぼくちんずっとhuffyuv2.1.1
誰か今のトレンドおしえて

578 :名無しさん@編集中:2012/03/24(土) 10:05:41.25 ID:O0EGobhX
huffyuvも普通にアリだとは思うけど、個人的にはUtVideoかな。

579 :名無しさん@編集中:2012/05/12(土) 05:47:06.38 ID:CDJNlbnl
PackBit Codec
http://dxtory.com/PackBit.html
Compression ratio: MAX 13% AVERAGE 50%
Color Space: RGB24
Maximum Resolution: 16384 x 16384
Instruction set: SSE2 SSSE3 SSE4.1 AVX
Multithread: SUPPORTED

規制解除されたんで一応
amvと比較してサイズ的に魅力感じなかったんで詳しくは調べてない

580 :名無しさん@編集中:2012/05/12(土) 06:43:47.31 ID:Rkyr6PX0
RGB4:4:4やYUV4:20,4:2:2はよく見ますがYUV4:4:4で可逆キャプチャ出来るコーデックはありませんか?
x264vfwではコーデックの設定時にoutput cspコマンドが使用出来ません。

581 :名無しさん@編集中:2012/05/12(土) 16:50:30.68 ID:v97PbmkH
RGB24とYUV4:4:4(8bit-depth)は、共に24bit/pixelとなってデータ量としては同じだけど
RGB24が1677万色ちょい表現できるのに比べて、YUV4:4:4は300万色くらいしか表現できない。
おとなしくRGB24でキャプチャしたほうがいいと思うけど、わざわざYUVにするメリットって何かある?

582 :名無しさん@編集中:2012/05/12(土) 21:33:35.71 ID:Rkyr6PX0
RGB→YUV変換をして出力した動画はフラッシュプレイヤーで色がおかしくなる

583 :名無しさん@編集中:2012/05/12(土) 21:49:29.75 ID:QbZqJZUF
フラッシュプレイヤーで見るなら最初から4:2:0でいいんでないかい

584 :名無しさん@編集中:2012/05/13(日) 00:44:02.07 ID:pJ6uaCMH
エンコード時に色差情報を多く持っておきたい

585 :名無しさん@編集中:2012/05/13(日) 02:04:16.48 ID:aRknVWrK
>>582
何をどうしてるのかよくわからんけど、やり方がおかしいだけでしょ。

>>584
YUV4:4:4にする理由?
多く持ってても別に意味無いと思うけど・・・。
RGBソースからエンコードすればよいのでは?

586 :名無しさん@編集中:2012/05/13(日) 17:53:25.91 ID:CWpwdGsK
[UtVideo] バージョン 11.1.0
性能向上
Mac で、RGB から ULY2 へのエンコードをアセンブラ化して高速化した。
共通: デコードを少しだけ高速化した。
共通: x64 で、エンコードを 10% 程度高速化した。
その他
Mac で、中間圧縮用コーデックとしては不要なフラグを出力しないことによって、エンコード後のサイズをちょっとだけ小さくした。

久々にwin用でアップデートした気がする

587 :名無しさん@編集中:2012/05/27(日) 10:06:42.13 ID:4nCBmS9y
某厨動画サイト住人が作った糞コーデックなんかいらん
Lagarithでええ


588 :名無しさん@編集中:2012/05/27(日) 14:33:55.53 ID:n+y6AwW1
釣りですか

589 :名無しさん@編集中:2012/05/27(日) 14:37:34.58 ID:fKNx54Ua
作者がSir Lagsalotとか名乗ってるあたり、あっちのほうがよっぽど厨臭いんだが
AMV作るのが趣味だし

590 : [―{}@{}@{}-] 名無しさん@編集中:2012/06/08(金) 18:31:22.14 ID:SpEwWioW
Intensity Pro、くすのきTVでゲームキャプ
UtVideo、RGB、720pでキャプるとフレーム落ちする…
CPUは2600KのHDDはWD1002FAEX三発積みでWrite360MB/s
くらい出てるんだけど何が悪いんかのー
GPTフォーマットとか何か悪さするんだろうか

591 :名無しさん@編集中:2012/06/17(日) 09:51:28.96 ID:UHVnPWLz
utvideo、圧縮率優先とデコード速度優先、どっちが正解なんだろう?

大雑把な構成は
Opteron2.6GHzで4コア、メモリ4GB
保存先はSEAGATE ST2000DM001一基

デコード速度優先 YUV 4:2:2 xVCMでプレビューパタパタ、コマ落ちも頻繁が、

圧縮率優先 YUV 4:2:2 xDMOに変えたら、プレビューするする、今のところ、

コマ落ちもなしになった…。

592 :名無しさん@編集中:2012/06/17(日) 10:02:07.56 ID:NjudHtIp
ストレージが高速ではないなら圧縮率優先が正解。

593 :591:2012/06/17(日) 10:10:47.41 ID:UHVnPWLz
スムーズだったのは、単に動画の方をデコードしてないだけでした…。

検討しなおします…。

594 :591:2012/06/17(日) 11:19:59.78 ID:UHVnPWLz
当座の検討終了。

いったんutvideoアンインストールして、最新版を入れ直したら、キャプチャ中も
20フレーム弱くらいでプレビューされるようになり、フレーム落ちもおさまりました。

現状は圧縮率優先、YUV 4:2:2 xVCMで様子見てみます。

お騒がせしまた。


595 :名無しさん@編集中:2012/06/17(日) 23:34:13.95 ID:dDkHMdyF
utでコマ落ちするならamvオススメ。ut圧縮重視より縮む
さらにx264ならその3倍は縮む。負荷は3倍どころじゃないがw

596 :名無しさん@編集中:2012/06/18(月) 00:45:17.35 ID:yYGkXwgB
そりゃ殆ど止まってる場面のキャプならamvでも縮むわな

597 :名無しさん@編集中:2012/06/18(月) 04:12:40.06 ID:MsboKZ2t
いや比べてみれば分かるがut比amvは本当に縮むよ。utがデカすぎる気もするが

598 :名無しさん@編集中:2012/06/18(月) 04:13:59.33 ID:TqcZmjzH
どこ切って小さくしてんの?<amb

599 :名無しさん@編集中:2012/06/18(月) 05:15:04.38 ID:Fz17UL8c
>>595 >>597
>>488のようにUtで569MB、AMV2で778MBという例もあるし、ソースや設定を明示しないと駄目でしょ。
それだけじゃ正しく比較してるのかどうかも怪しい。UtVideoのRGBとAMV3(YUV420)を比較してるとか
AMVのほうは非可逆モードでしたなんて間違いも疑ってしまう。

600 :名無しさん@編集中:2012/06/18(月) 11:11:07.15 ID:+tWjquVO
リアルタイムキャプでx264を挙げる時点で触っちゃいけない人だと思うんだ。

601 :名無しさん@編集中:2012/06/20(水) 15:10:26.21 ID:nT+Rwd1a
UtVideoをインストールすると、utv_core.dl、lutv_dmo.dll、utv_vcm.dllと三つのdllファイルが
インストールされますが、このうちコーデックが実装されてるDLLはどれになるか教えてください。
または、UtVideo.dllのようなものが別途どこかに作られているのでしょうか。

602 :名無しさん@編集中:2012/06/20(水) 17:30:33.37 ID:oaWInmXZ
>>601
作者に聞け。

603 :名無しさん@編集中:2012/06/20(水) 18:47:29.98 ID:u+ToXrah
>>601
何がしたいのか意味不明すぎる。「コーデックが実装されてるDLLはどれになるか」と聞かれたら「全部」でしょ。
ラッパーだろうがなんだろうが「コーデックの実装」といわれれば全てあてはまる。
そもそもソースコードも公開されているんだから、DLLがどうとか気にするような人はそれを見ればいいと思うが・・・。

作者に聞きにいくならちゃんと何がしたくて何が知りたいのか明確に説明して質問しなよ?
情報をろくに提示せずに無駄なやりとりを繰り返して作者を困らせないように。

604 :名無しさん@編集中:2012/06/20(水) 19:58:10.35 ID:ssJwkBuo
>>601
utv_core.dll デコード、エンコード、色空間変換するライブラリ
utv_dmo.dll utv_core.dllをDirectShowFilterとして使うためのライブラリ
utv_vcm.dll utv_core.dllをVCM(VFWコーデック)として使うためのライブラリ

605 :名無しさん@編集中:2012/06/20(水) 21:17:19.21 ID:U9vIkCCj
>>604
ご丁寧にありがとうございました。

606 :名無しさん@編集中:2012/07/05(木) 00:29:43.57 ID:ua5VMMN6
2012/6/29にグラスバレー社から「Grass Valley Codec Option(無償版)」が公開されてる。

  ダウンロード Grass Valley Codec Option(無償版)
  ttp://pro.grassvalley.jp/download/gv_codec_option.htm

Win7であれば以下のコーデックでのエンコード/デコードが可能。
Vista/XPは以前から公開されていたデコーダーのみ。

  ・Canopus HQX Codec
  ・Canopus HQ Codec
  ・Canopus Lossless Codec
  ・Canopus DV Codec

Mac版もあるけど、HQ/HQXのエンコード/デコードのみなのかな?よくわからない。

このうち可逆なのは名前のとおりCanopus Lossless Codecだけかな。可逆じゃないけどHQ/HQXも面白そう。

  ttp://pro.grassvalley.jp/catalog/edius/edius_pro_65_hqx.htm
  ttp://pro.grassvalley.jp/catalog/hqcodec/hq_codec.htm
  ttp://pro.grassvalley.jp/catalog/edius/pdf/HQX_Whitepaper_J.pdf

うちはXPだからエンコードできねえけど・・・orz

607 :名無しさん@編集中:2012/07/11(水) 15:06:19.30 ID:wtJV5I/8
すいません、ちょっとお聞きしたいのですが、aviutlでhuffyuv_mtを使ってavi化したら
なぜか元のファイルの8倍ぐらいのサイズになってしまったのですがどなたか原因分かる方おられないでしょうか?

608 :名無しさん@編集中:2012/07/11(水) 15:06:49.34 ID:wtJV5I/8
age忘れ

609 :名無しさん@編集中:2012/07/11(水) 15:10:10.50 ID:wtJV5I/8
ミスorz

ちなみに現在試しにやってみた状態で、元動画読み込み→AVI出力→ビデオの圧縮でHuffyuv v2.1.1選択
→設定でとりあえずどちらになるか分からないので両方ともbestの物を、マルチスレッディングにだけチェック入れてOK

その状態で開始すると30分ちょいの物が20分ちょいで圧縮され、元データは3.3GB程度の物が25GB程度になってしまいます。

610 :名無しさん@編集中:2012/07/11(水) 15:30:49.08 ID:cUzFi1yz
そういう物だから。

611 :名無しさん@編集中:2012/07/11(水) 16:39:38.82 ID:vLmHeQf8
元動画のコーデックも書けない男の人って…

612 :名無しさん@編集中:2012/07/11(水) 16:48:56.17 ID:3+a9rhZK
wmvからmp4へのエンコで音ズレ(2時間で3秒くらい)するんだけど
検索してみたら
ttp://slickdeals.net/f/3836338-Converting-wmv-to-mp4-Audio-out-of-sync-using-VLC-Other-recomendations
でfreemakeというのを薦めててそれ入れてみたらたしかに音ズレはなくなった。
だけどaudioの設定が自由度低くて他に良いソフトがないか探してます。
tmpgencとavidemuxでは音ズレが生じてhandbrakeではエラーで途中終了してしまいます。

613 :名無しさん@編集中:2012/07/11(水) 18:11:42.78 ID:+69TWjTJ
>>612
頑張って探してくださいね。スレ違いにもほどがあります。さようなら。

614 :名無しさん@編集中:2012/07/21(土) 09:46:28.91 ID:BYmEeyUU
すみません、教えてください。

Ut Video Codecで録画した動画をWindows Media エンコーダで
WMVに変換したいんですが、入力メディア形式が無効です。
というエラーが表示されてしまいます。

なんとか変換する方法はないでしょうか。
よろしくお願いします。


615 :名無しさん@編集中:2012/07/21(土) 09:53:57.69 ID:RxU2D1oF
Windows Media エンコーダで読める形式に一度変換する

616 :名無しさん@編集中:2012/07/21(土) 18:13:08.66 ID:xDNtyE/Y
>>614
公式ブログのv11.1.0の記事のコメント欄にも同様の書き込みがあったので
うちでも試してみたけど、条件次第でULRGとULY2でエラーが出た。ULY0は問題なかった。
ULRGとULY2に何か問題があったりするんだろうか。WME側がおかしいのかもしれんけど。

■環境等
 ●OS: WinXP SP3
 ●UtVideoのバージョン: 11.1.0
 ●Windows Media エンコーダのバージョン: 9.00.00.3374
 ●ソースファイル
    AviUtl+拡張編集プラグインで
       320x240、30fps、3秒
       640x480、30fps、3秒
    の2種のファイルを作り、AVI出力で映像のみ各種コーデックで出力したもの。
 ●WMEでの手順: 新しいセッションでファイルの変換を選んで「ファイルへ保存→最高品質ビデオ(VBR 100)」
 ●エラーが起きるもの
    ・ULRGで出力したもの
    ・ULY2で、「YUY2圧縮オフ」で出力したもの。(YUY2圧縮オンなら問題なし)
 ●WMEで発生するエラー:
    入力メディア形式が無効です。(0xC00D0BB8)
 ●備考
   ・AMV2のR2,Y2設定やAMV3のS2設定、HuffyuvのRGB圧縮、あとLagarithも問題ありませんでした。
   ・当然ですがどのAVIファイルもWMPでの再生やAviUtlでの編集は問題なく行うことができます。
   ・ffdshowを使っておりLAV Filtersは入れていないのでUtVideoのデコーダーは公式のもののみです。
    GraphStudioで見てもUtVideoのDMO Decoderがデコードしています。
    (レンダラとの間にAVI Decompressorが入ってYUV→RGB32変換してますが)

一応作者さんのブログにも報告してみます。

617 :名無しさん@編集中:2012/07/22(日) 12:10:09.64 ID:PqyWeGZn
>>616
詳しく検証していただいてありがとうございます。
まったく同じ状況です。

一点付け加えさせていただけるなら、以前はエンコードができていました。
そのあと、OSの再インストールや、Ut Video Codec の再インストール(最新版などに更新したかもしれませんが記憶があいまいです。)
などにより、上記のエラーがでるようになってしまいました。

618 :名無しさん@編集中:2012/07/22(日) 12:26:55.92 ID:PqyWeGZn
>>616

連投すみません。

よかったら、ULY2で「YUY圧縮をオン」にする設定についておしえていただけないでしょうか。
現在の設定は以下のようになっています。
よろしくお願いします。

ttp://s1.gazo.cc/up/s1_30621.png


619 :名無しさん@編集中:2012/07/22(日) 12:42:18.07 ID:mj/F2joX
aviutilじゃね

620 :名無しさん@編集中:2012/07/22(日) 17:14:39.96 ID:bHK6rSo0
>>618
>>619さんが指摘しているように、UtVideoの設定ではなく、AviUtl側の設定です。
「環境設定→コーデックの設定」で、ULY2などを選択し、
「YUY2圧縮する」のチェックをONにするかOFFにするかを指定します。
例えばULY2の場合だと、
  チェックが入っている場合→AviUtlはYUY2でデータを出力し、そのYUY2データをULY2が圧縮する
  チェックが入っていない場合→AviUtlはRGBでデータを出力し、
                     ULY2は内部でRGB→YUV4:2:2の変換を行ったうえで圧縮する
という違いが出ます。

>>614には録画に使ったソフトや設定が書かれていないのでわかりませんが、
例えばアマレココの場合は、コーデックにRGBデータを渡すようになっているはずなので、後者の挙動になります。
アマレコTVの場合はデバイスからの入力フォーマット次第になるのかな、たぶん。

621 :名無しさん@編集中:2012/07/24(火) 00:11:33.27 ID:9Ynxk7mN
>>619
>>620

とても丁寧に細かく説明をいただきありがとうございました。
aviutlの環境設定の部分も確認させていただきました。

現在はアマレコTVを使っています。
以前は、アマレコTVで録画した動画をそのままWindows Media エンコーダで
変換できていましたので、>>620さんのおっしゃられているデバイスからの入力
フォーマット次第という部分についてもう少し調べてみたいと思います。

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

622 :名無しさん@編集中:2012/07/24(火) 23:58:46.90 ID:qNsLi6Yd
なんか、金曜深夜アニメの録画のキャプチャでくすのきagreとutvideoが決まった場所でフレーム落ちしよる。
RAIDドライブに保存先を変えてもダメ。
コーデックをhuffyuvマルチスレッドに換えたら大丈夫になったけど…。


623 :名無しさん@編集中:2012/07/26(木) 23:32:06.36 ID:nizQsTmJ
[UtVideo] バージョン 11.1.1
http://umezawa.dyndns.info/wordpress/?p=3309
バグ修正
Windows で、エンコード時およびデコード時に、出力イメージのサイズ(バイト数)が正しく設定されないことがある。

624 :名無しさん@編集中:2012/07/26(木) 23:53:38.01 ID:HvRXN1vf
>>623
>>614-621の件が修正されたみたいですね。作者さんありがとうございます。

625 :614:2012/07/28(土) 02:08:51.88 ID:mOO1vsxb
>>624様の詳細なご報告と作者様のご対応に感謝いたします。ありがとうございます。


626 :名無しさん@編集中:2012/07/28(土) 09:03:19.53 ID:rlbnUsJl
>>606
FFmpegにもCanopus Lossless decoderのパッチが来てるね (まだBGR24のみとのことだけど)

627 :名無しさん@編集中:2012/08/04(土) 22:21:05.10 ID:vVUojxSb
x265のロスレスに期待

628 :名無しさん@編集中:2012/08/12(日) 23:30:50.14 ID:84/2xtcr
あまラボ AMVビデオコーデックFAQ
ttp://amalabo.blog35.fc2.com/blog-entry-200.html
AMV3ビデオコーデックのS2設定とS3設定で録画した場合にS2の方がファイルサイズが小さくなる?
動きが少ない場合S1のほうが縮むそうだ

629 :名無しさん@編集中:2012/08/14(火) 20:41:42.38 ID:JxHtN6C2
UT Videoのカラーマトリクスはどうなっているのですか?

630 :名無しさん@編集中:2012/08/14(火) 21:24:17.85 ID:A/T0F+qW
>>629
カラーマトリクスという表現が適切かどうかはよくわからないが、
UtVideoの内部でのRGB⇔YUV変換で使われる係数のことを言ってるならBT.601相当。

念のため言っとくが、ULY2やULY0にBT.709のYUVデータを渡せば
ULY2、ULY0はそのYUVデータをそのまま圧縮する。
それをYUVではなくRGBでデコードするとUtVideo内部でYUV→RGB変換が起こり、
その計算はBT.601で計算されるので、元映像とは色が変わる。

どこでRGB⇔YUV変換が発生するのかを把握して扱うことが大事。

631 :名無しさん@編集中:2012/08/14(火) 21:39:57.99 ID:A/T0F+qW
というかコーデック内部でのRGB⇔YUV変換の係数にBT.601以外を使うものってあるんだろうか。

632 :名無しさん@編集中:2012/08/14(火) 23:40:14.85 ID:uXP/D5hi
HDYC(intensityのやつ)がそーじゃなかったっけ

633 :名無しさん@編集中:2012/08/23(木) 20:55:25.45 ID:3o5LpV1w
動画編集ソフトでHuffyuv で書き出したaviを
aviutlで色の調整後、また可逆圧縮で書き出しというのをためしているのですが
うまくいきません
サイズはほとんど変わらない?はずなのに24Gが10Gになっていて
がくがくになったり音がうまくならなかったりします
可逆圧縮を可逆圧縮する・・・というのはだめなのでしょうか?

634 :名無しさん@編集中:2012/08/23(木) 21:10:02.04 ID:Cf1r0QL5
編集時の中間ファイル作成として、それはごく当たり前に行われる行為
ダメなのはキミのツールの取り扱い方でしょ

635 :名無しさん@編集中:2012/08/23(木) 21:10:42.80 ID:Cf1r0QL5
行われる行為って頭痛が痛いと同じだなorz

636 :名無しさん@編集中:2012/08/23(木) 21:34:26.83 ID:i2rQqUkA
サイズが減ってるのは、編集ソフトでRGBで圧縮したものが、AviUtl出力時にはYUY2になってるんじゃないかね。
そもそも今はあえてHuffyuv使う必要なんてないし、色空間のことがよくわからないなら
UtVideoのULRGを使っておいたほうが無難。
そもそも可逆圧縮は再生には向いてないから、スペックや素材によっては
がくがくになったりするのは当たり前といえば当たり前。AviUtlに通す前のファイルだってがくがくなんじゃないの。
もしくはAviUtlで不必要なインターレース解除などをやってしまってるとか。

637 :名無しさん@編集中:2012/08/25(土) 18:55:02.55 ID:hqpdZTdt
Utvideo導入しました
そしてULRGでやってみたんだけど、同じ現象になるやはり・・・
videostudioで書き出す所までは大丈夫
まぁKMPlayerだと画面ばぐってるけど、
AVIUTLだと正常だから多分プレイヤーの問題として、これはいいとする

これを色だけ直してさらに可逆圧縮したいわけだけど・・・
出来上がった動画、サイズは少しだけ小さくてほとんど同じになったんだけど
最初の方だけ少し動いて、画面が固まる
その後ずっと止まったまま。
なんでこうなる・・・
設定は何もいじらずやってる。AVIUTLで書き出す時も
インターレースは偏光なしにしたんだけど。スペック不足かなぁ

638 :名無しさん@編集中:2012/08/25(土) 23:51:47.84 ID:VOx3EeGz
フィルタを全部オフでやってみた?

639 :名無しさん@編集中:2012/08/26(日) 01:45:42.15 ID:g5xOwZrf
拡張色補正のみオンにしました
ノイズ消しやシャープとか、そういうのはオフです。
短い動画で何回も試したけど、同じ結果
UTvideo(4種類)でもハーフィーでも、一回目の書き出しはうまくいく
でもそれを、utlで可逆圧縮(UでもHでも)で書き出すとだめ
最初の数秒は動くけど、その後ストップする
困った
もうMP4で書き出すしかないか・・・

640 :名無しさん@編集中:2012/08/26(日) 05:49:26.26 ID:iw09V0u9
> 拡張色補正のみオンにしました
最低1回はオフにして試せよ・・・

641 :名無しさん@編集中:2012/08/26(日) 07:18:40.48 ID:g5xOwZrf
今オールオフでやってみたけど同じことでした
音だけはなってるみたい
可逆で出した物は重いのでまともにさいせいできないので
ぶっぶっぶって幹事の音だけど。でも映像が止まった後も聞こえてる

何がいけないんだろうか・・・
ソニーのハンディカムCX590のm2tsというファイル
式空間とかが影響しているんだろうか?

今度ビデオ編集ソフトで書き出す所からの
設定画面とか全部キャプチャするので、確認お願いできますか?

今日はこれから海でBBQなので時間がありません
それではいってきます

642 :名無しさん@編集中:2012/08/26(日) 09:54:54.47 ID:iw09V0u9
>最初の数秒は動くけど、その後ストップする
>音だけはなってるみたい
>可逆で出した物は重いのでまともにさいせいできないので
>ぶっぶっぶって幹事の音だけど。でも映像が止まった後も聞こえてる

m2tsってことは動画の解像度が高いせいで可逆圧縮後も
ビットレートが高く、HDDの転送速度が追いついてないと思う。
リサイズフィルタで小さくしてもう一度試してみて。

643 :名無しさん@編集中:2012/08/26(日) 11:24:57.04 ID:6bFaPwdA
そんな感じがするけどmediainfoで情報ださせるのが先じゃね

644 :名無しさん@編集中:2012/08/26(日) 12:51:44.52 ID:MmXPjavj
必要な情報
 1.編集ソフトから出力したAVIファイルをMediaInfoというソフトで解析し、テキストモードの結果を貼る
 2.AviUtlにファイルを読み込んだ状態で、「その他→ファイルの情報」を開き、
   Ctrl+Cキーでウィンドウに表示されている情報をコピーしてそれを貼る
 3.AviUtlから出力したAVIファイルをMediaInfoというソフトで解析し、テキストモードの結果を貼る
 4.再生確認に使っているプレーヤーの名前

これくらいだろか。

ちょっと気になるのは「編集ソフトから出力したものはうまくいくのにAviUtlで出力するとダメ」という点かねえ。
解像度やフレームレートを変えずにULRGで出力してるなら違いが出るようなことはないと思うのだけど。

645 :名無しさん@編集中:2012/08/26(日) 18:30:23.22 ID:DXDJPr5d
graphedtでクロック使わずに再生

646 :名無しさん@編集中:2012/08/27(月) 01:46:59.53 ID:zHU6Tn+U
http://cdn.uploda.cc/img/img503a5162b1c5d.jpg
http://cdn.uploda.cc/img/img503a5174ab295.jpg

よろしくお願いします
上がvideostudioでハーフィーで書き出したものを
mediaとutlで表示させた物です。
下はそれをH264GUIで、MP4変換させようとした物なんだけど、
こちらも初めの数秒で映像が止まっていて、だめという・・・・
つまり可逆圧縮した物を可逆圧縮する場合だけでなく、
MP4にするのにも失敗するようになってしまった
以前のAVCHDLを可逆圧縮→MP4でやってたときは問題なくできていた
やはりスペックとしてE5200、9600GTとかでは無理があるのかなぁ

720x480でも同じようなことを試してみたけど
やっぱりそちらも数秒で映像が止まる現象になった
このサイズでも止まるって何かおかしい
一度目に可逆圧縮したものは、がくがくではあるけど止まらず再生できるんだが
それをエンコしようとすると最初の数秒で止まる感じ
原因がわからない。m2tsというまだ普及率の低い形式もネックになっている気がする・・・

647 :名無しさん@編集中:2012/08/29(水) 01:53:23.93 ID:Q0btWdAB
↑とりあえずスルーでけっこうです
またいろいろ試してダメだったらその時相談します

648 :名無しさん@編集中:2012/08/29(水) 03:18:28.09 ID:oaMlCTkv
>>646-647
とりあえずAVIをDirectShow File Readerで読み込んでるのがおかしい。
AviUtlの「ファイル→環境設定→入力プラグイン優先度の設定」で、
「DirectShow File Reader」を下にしたほうがいい。
少なくとも「AVI/AVI2 File Reader」や「AVI File Reader(Video For Windows)」よりも下にすること。

649 :名無しさん@編集中:2012/08/29(水) 21:10:28.96 ID:dCHN2uN6
ありがとう。それやったら、シークが凄くスムーズになった
で、肝心の可逆→可逆でやったんだけど、止まらないのができた
とりあえず今まで止まってたのが止まらない
ただサイズがやっぱり24から16くらいに落ちてるのが気になる
問題なくエンコできているかどうか、一度滑らかに再生できるMP4とかに
変換しないとわからないけど、時間かかるからまだ試せていない
出来てると助かるんだけどなぁ

650 :名無しさん@編集中:2012/08/29(水) 21:55:32.12 ID:BtQi1WWY
上でUtVideoのULRGを使うのが無難だと言われているのになぜHuffyuvを使い続けるのだろう。
Huffyuvは使い方によってRGBになったりYUY2になったりするから
そのへんを理解して使わないと可逆にはならない。
その点ULRGならRGBだけで処理されるから混乱しなくてよいというのに。

651 :名無しさん@編集中:2012/08/30(木) 00:52:55.66 ID:fZ4IT4zZ
自分も使いたいんだけど、ULRGで書き出すと
自分が使っているKMPlayerというソフトで再生すると
http://iup.2ch-library.com/r/i0730034-1346255404.jpg
こんな感じになってしまう。
多分設定の問題なんだろうけど、どれをいじれば直るもんやらわかったもんじゃなく・・・
他の再生ソフトだとちゃんと表示されるから、いいといえばいいんだけど
KMPが一番軽い。何せPCスペックがあれだからね・・・
後ULRGってx86ってのでいいんだよね?

652 :名無しさん@編集中:2012/08/30(木) 01:15:52.75 ID:VDvDN78Y
>>651
ああ、そういえばKMPlayer使ってるって書いてたっけか。あれは色々なデコーダーを内蔵してるタイプだと思ったけど、
UtVideoのデコーダーは入ってないだろうから再生できない。
ffmpegだかlibavだかにUtVideoが入ったのでいずれはKMPlayerでも再生できるようになるかもしれんけど。
MPC-HCやWMP等はシステムにインストールされたUtVideoのデコーダー使うから問題なく再生できる。

KMPlayerってあまりいい噂を聞かない気がするけど、使ったことないのでよく知らん。
まあどうせ最終的にMP4にするなら厳密に可逆である必要もないし、Huffyuvでもいいかも。
Huffyuvで作業した時にサイズが減ってる理由は、推測としては>>>636に書いたとおり。
フィルタをかけないなら、全工程をULRGでやればサイズが減ることはないと思うけど。

ULRGのx86と言ってるのはAviUtlでコーデック選ぶときの話かな。
AviUtlは32bitアプリだからx86のULRGしか出てこないので、それでいい。

653 :名無しさん@編集中:2012/08/30(木) 02:14:26.01 ID:fZ4IT4zZ
なるほど、現時点では再生に対応していないのか
内臓タイプか、システムのを使うのかの差なのね

インストールの時にあれこれ他のものインスコしそうになったりはしたw
ただこれ、上下左右反転が出来るのも自分として便利で。
今、短い動画でやったらサイズ変わらなかった
少し増えたくらい。
プレイヤーで対応してないだけなら問題ないわけだから
今度からULRGでやることにする

x86はその通り、選ぶときに出てる表示で。問題ないんだね

654 :名無しさん@編集中:2012/09/01(土) 22:56:26.19 ID:fBCRFp+L
あまラボ ビデオコーデック・ベンチマーク2012夏
http://amalabo.blog35.fc2.com/blog-entry-202.html

655 :名無しさん@編集中:2012/09/06(木) 02:14:58.02 ID:OKtM8Mrv
音声がぶつ・ぶつ・ぶつって感じでノイズが入るんだけど何でだろう・・・

656 :名無しさん@編集中:2012/09/06(木) 02:20:53.07 ID:XPNirp0/
スレ違い

657 :名無しさん@編集中:2012/09/06(木) 07:57:33.59 ID:OKtM8Mrv
いや、可逆圧縮でやったときの話なんだけど

658 :名無しさん@編集中:2012/09/06(木) 09:17:59.62 ID:oxp/bqOD
ウルトラスーパーエスパー募集

659 :名無しさん@編集中:2012/09/06(木) 09:40:00.38 ID:CYiSS2IO
玄人志向のNO-PCIいれてみ

660 :名無しさん@編集中:2012/09/08(土) 08:07:58.57 ID:ajDm/Xty
ありがと
動画編集ソフトで書き出すとそうなるっぽい
重いからかな
とりあえず音声ファイルだけ出力して、動画はミュート
で、最終エンコの時にだけ組み合わせるってのでなんとかなりそう
というか試行中・・・うまくいきますように

661 :名無しさん@編集中:2012/09/08(土) 10:27:00.05 ID:bmNPuBDj
冗談じゃなくて、うちはそれでスピーカーからのプチプチがなくなったよ。
大して役にも立たないなら、さっさと抜いて3-way SLIにするんだけど、効果があると感じただけにぬくにぬけないっていうね。
保存したファイルやエンコードしたファイルにM/Bのノイズが乗ったことが原因かどうかまでは分からないけど
空いてるスロットがあるならさしてみるのも悪くないとマジレスしておこう。

662 :名無しさん@編集中:2012/09/08(土) 14:52:32.10 ID:j9Jrbned
俺はコンデンサてんこ盛りに強化して使ってる
効果を実感できたことはない

663 :名無しさん@編集中:2012/09/08(土) 15:55:39.77 ID:yG9itJA6
環境依存の話だが、昔々ISAのSoundBlasterでディスクアクセスの度にプチノイズが出たな
音楽ファイルの保存先をSCSI HDD側にして回避出来たがコストが高くついたw

664 :名無しさん@編集中:2012/09/10(月) 17:14:32.90 ID:UadvmYKX
ただ単にリアルタイムで見ようとしてデコード負荷が高過ぎて音飛びしてるだけだろ。

665 :名無しさん@編集中:2012/09/12(水) 21:05:51.94 ID:RmBzuDhI
utvideoで書き出す時って、インターレースの解除はどうなってるんですか?
されずに残っていると思っていいですか?

666 :名無しさん@編集中:2012/09/12(水) 21:26:15.18 ID:ZOOp7Xam
インターレースの解除は、フロントエンドの仕事なので、UtVIdeoには解除機能はありません。
だけど維持に適したモードがあります。

667 :名無しさん@編集中:2012/09/12(水) 21:27:55.13 ID:RmBzuDhI
なるほど、ありがとうございます。
インターレース映像として残す?みたいな項目があるので
もしかして解除になってる?とか思ってました。
維持に適したモードですか。特別拘りがなければ気にしなくても大丈夫ですかね

668 :名無しさん@編集中:2012/09/12(水) 21:43:16.41 ID:n55Nrg08
>>667
某エンコスレにいた人だと思うけど、
  ・編集ソフトからインターレース映像として出力する場合
     →UtVideoの設定で「インターレース映像としてエンコード」のチェックを入れる
  ・編集ソフトからプログレッシブ映像として出力する場合
     →UtVideoの設定で「インターレース映像としてエンコード」のチェックを外す
というだけの話だよ。

669 :名無しさん@編集中:2012/09/12(水) 22:56:02.54 ID:RmBzuDhI
そうです。もしかするとわかる人にはわかってるかも都は思っていたけれどやはり。・・・お恥ずかしい限りです

チェックを入れれば、その時点でのインターレースの有り無しを変えられるわけですか。
じゃあ例えば忘れたりしないように、最終書き出しの段階で解除をするという決まりごとにしているなら
常にチェックは入れておく、、って感じでいいんですかね
例えば中間ファイルとして、utで解除して書き出した後、
aviutlでさらに解除を選んでしまったらどうなるんだろう。よくないのかな

670 :名無しさん@編集中:2012/09/12(水) 23:13:07.18 ID:ZOOp7Xam
>utで解除して書き出した後、

という表現が分からない
二重インタレ解除はしないに越したことはない

671 :名無しさん@編集中:2012/09/12(水) 23:20:36.98 ID:RmBzuDhI
UTvideoでプログレで書き出したとして、この時点で解除されてますよね
その後に、他のソフトでもう一度インタレ解除をしてしまったら・・ということでした
2回はしない方がいいんですね。
どこでやったか一度覚えておく必要がありますね

672 :名無しさん@編集中:2012/09/12(水) 23:20:57.33 ID:n55Nrg08
>>669
いや、えーとだな。上に書いてあるとおり、インタレ解除するのはフロントエンドというか
VideoStudioやらAviUtlやらAvisynthといったソフトの役割なわけだ。で、ソフトによって、
  ・インタレ解除をするのか(できるのか)
  ・出力時にインタレの維持・解除を選べるのか、それとも強制的に解除されてプログレッシブになるのか
といった点は異なるし、使う側が選択して動作を決めることもある。
UtVideoはソフトが出力したデータを受け取って圧縮するだけだが、ソフトがインタレース映像を出力する場合は
UtVideoの設定で「インターレース映像としてエンコード」をONにする。
インターレース解除はどこか一箇所でやればいいわけだから、
   ■ソフトでインタレ解除せずAVI出力→UtVideoインタレ設定ON→AVIが出来る→AviUtlに読み込んでインタレ解除をする
   ■ソフトでインタレ解除してAVI出力→UtVideoインタレ設定OFF→AVIが出来る→AviUtlに読み込んでインタレ解除はしない
のどちらかになるってこと。

673 :名無しさん@編集中:2012/09/12(水) 23:40:15.70 ID:NzxP//h0
HuffyuvやUtのインターレースとして云々ってのは、別にインタレを維持/解除するわけではなく
単にフィールドで圧縮するだけだぞ

こういう映像を
http://i47.tinypic.com/rasv37.jpg
こんな感じにしてから圧縮する
http://i48.tinypic.com/2ujiotl.png
なんでこんなことするかといえば、インタレの映像はそうしたほうが圧縮率が高くなりやすいから
逆にプログレな映像をこんな感じで圧縮すると、圧縮率は下がる

デコードするときには元のフレームの状態に戻すから、
どちらでやろうが映像自体は圧縮前とまったく同じものが得られる

674 :名無しさん@編集中:2012/09/13(木) 00:36:33.79 ID:2PEpB0UI
>>672
詳しくありがとう
難しいけれど、解除はあくまでソフトの仕事なのか
インタレをどうするかはソフトで決める、と。

ビデオスタジオでインターレース解除の設定をしないのならUTでもインタレを維持
逆ならインタレは解除であわせればいいのか
もし、この設定をあわせなかったり、逆にしてしまったらどうなるのかな?
ビデオスタジオでは解除をしているのに、UTの設定でインタレとしてエンコする、弐チェックを入れてしまったり。

ビデオスタジオがAVIで書き出す時に、インタレの解除をどうしているのかわからない・・・
フレームタイプ(下位、上位、ベース)とか関係あるのかな?
これを上位で選んだら解除されている、とかそういうことあるのかなぁ
そもそもソフトによるのなら、なぜUTでこのような設定項目があるのだろう?
ソフトでどうだろうと、UTのこのチェックボックスの設定で結局やってくれるというのならわかりやすいのに

>>673
ありがとう。
あのチェックボックスはそういう圧縮にするかどうかを決めるだけということか
そして圧縮率の問題だけ?
結局ソフトで解除するか、しないかを決めるのかな?
基本的にはビデオスタジオでAVIでコーデックをUTにしてかきだしても
解除はされていないと思った方がいいのだろうか?
それともされているのだろうか?
調べる方法とかないのかなぁ

675 :名無しさん@編集中:2012/09/13(木) 00:40:02.99 ID:31/96yI7
とりあえずあとは初心者質問スレとかVideoStudioスレでやったほうがいいと思う。
インターレースについて自分で色々調べて勉強したうえでね。

676 :名無しさん@編集中:2012/09/13(木) 00:48:02.59 ID:2PEpB0UI
そういわずにもう少しだけお付き合いお願いします・・・

677 :名無しさん@編集中:2012/09/13(木) 00:51:56.09 ID:2PEpB0UI
フレームタイプが、フレームベースだとインタレ解除ですかね?
上位か、下位だとインターレース映像ってことになるのですかね?

678 :名無しさん@編集中:2012/09/13(木) 00:57:01.48 ID:RsiJZEnQ
>>674
最後にアドバイス。UtVideoはインタレ維持のチェックを入れようが入れまいが
"可"逆圧縮だから絶対に劣化しません。

>>677
完全にスレチ。そのソフトのスレにGo!

679 :名無しさん@編集中:2012/09/13(木) 01:05:26.31 ID:31/96yI7
入出力の色空間と使うコーデックの種類をあわせないと劣化するけどね。
まあそのへんはスレ内を「色空間」で検索すりゃ出てくる。

680 :名無しさん@編集中:2012/09/13(木) 01:15:57.40 ID:2PEpB0UI
どうしよう・・・ここまで来たのに。
こんなのわかんない・・・(泣

681 :名無しさん@編集中:2012/09/13(木) 09:26:23.32 ID:pX8LSaal
めんどくせぇヤツだなw
とりあえずお前はUtVideoの設定を何も弄らず使っとけば何も問題ねぇよ。
インタレ解除も気にしなくていいよ。
どうせ最終的に出来上がった動画見ても何も違いなんてわかんねぇだろ?
どうしても勉強したけりゃ然るスレで手順全部書いた上で質問してこい。

682 :名無しさん@編集中:2012/09/13(木) 09:41:41.38 ID:Dda1VMZ+
>>681の優しさに濡れた

683 :名無しさん@編集中:2012/09/13(木) 20:36:07.48 ID:2PEpB0UI
ありがとうね
でもなんで答えをさくっと教えてくれなかったんだろう
ビデオスタジオでUTでaviで書き出す時に、
どの設定を見れば維持なるのか、それだけ知りたかっただけなのに・・・

684 :名無しさん@編集中:2012/09/13(木) 21:29:22.05 ID:o91xMrbI
だってインタレの維持/解除はVideoStudioの問題であってUt関係ないもの
強いて言うならUtはインタレは維持しかしない

685 :名無しさん@編集中:2012/09/13(木) 21:30:13.99 ID:Busn3vQJ
つか、やってみりゃ一発で分かる話じゃん

686 :名無しさん@編集中:2012/09/13(木) 21:33:34.81 ID:9Jv0uvup
>>681が皮肉だってことに気づいてないみたいだし、
既にVideoStdioスレに移動してるからこれ以上ここで触らないほうがいいと思う。

687 :名無しさん@編集中:2012/10/28(日) 14:32:18.20 ID:TNb/13Hp
ロッシーなUTVideoも出ないかな…
やつぱ可逆ってでかすぎるし

688 :名無しさん@編集中:2012/10/28(日) 14:36:57.02 ID:7DW0yYJK
x264使っとけよ

689 :名無しさん@編集中:2012/10/28(日) 18:32:17.54 ID:TNb/13Hp
UTVideoの特徴は編集しやすいって事でしょ
そのためにはH264ではだめなんだよ

690 :名無しさん@編集中:2012/10/28(日) 18:50:42.70 ID:AHg08j50
編集段階なのに不可逆圧縮使うの?アホの子なの?

691 :名無しさん@編集中:2012/10/28(日) 19:04:29.09 ID:RgklqyrI
MJPEGとかじゃダメなんか

692 :名無しさん@編集中:2012/10/28(日) 19:33:56.43 ID:eEQ3IqSB
編集しにくいのはP/Bフレーム使ってるからでしょ
AVC-IntraみたいにIDRだけにすればシークもサクサクだし
無劣化切り貼りも楽勝だよ

693 :名無しさん@編集中:2012/10/28(日) 21:43:24.13 ID:9bLpTjhF
Iフレームだけのエンコはどうやるの?

694 :名無しさん@編集中:2012/10/28(日) 23:37:51.29 ID:eEQ3IqSB
--keyint 1

695 :名無しさん@編集中:2012/11/24(土) 23:01:42.57 ID:gSRU6CNB
huffyuvのマルチスレッド版って

>>2
> Huffyuv_mt (マルチスレッド化)、Lagarith_1315dev_SSE2_719 (SSE2対応化ほか)
> http://www29.atwiki.jp/lossless/pages/11.html

の日本の有志が作ってくれたものと、

http://www.gigafree.net/media/codec/huffyuv.html

本家(?)が作ったものの2種類あるようだけど
それぞれどう使い分けたらいいと思う?

ちなみにOSはWindows7(x64)。
CPUはCore i7 3770k使ってまつノ

696 :名無しさん@編集中:2012/11/24(土) 23:23:35.66 ID:3UAGn7u/
amvかutvideo使っとけ この2つに比べるとhuffyuvは遅いし縮まらん

697 :名無しさん@編集中:2012/11/24(土) 23:29:34.59 ID:gSRU6CNB
>>696
レスd

ut videoはいいとして、AMVに可逆圧縮なんてあったっけ?
あ、あった気がするな・・・
なにげにhuffyuvより優秀だったのね・・・

698 :名無しさん@編集中:2012/11/25(日) 01:59:55.96 ID:HUqX/NcV
いやamvは可逆の圧縮効率的にも速度的にもここ何年もの間ずっと最強(圧縮効率はx264が圧倒的だけど異常なまでのデコード速度とエンコード時の重さ的にキャプチャではほぼ使われないあとlibxじゃ420しかだせないぽい)
問題はamvはロゴ無しなら有料ってこと。ストレージがデカイならutでいい
ただRGBで撮るならamvでもほぼ完璧なロゴ透過が出来るので(ry

699 :名無しさん@編集中:2012/12/25(火) 22:32:22.60 ID:4+Xi4jS+
ここの人ならカメラ板よりも詳しそうなので、質問します。
1920x1080(60P)の場合、28Mbpsだと足りないと思うんですけど、なんで28Mbpsなのでしょうか?
高画質モードだと、1920x1080(60i) 24Mbps
中画質モードだと、1920x1080(60i) 17Mbps
なので、単純計算しても60Pの高画質は48Mbps、中画質でも34Mbpsで充当だと思うんですが。
http://panasonic.jp/dc/g5/movie.html
http://www.sony.jp/ichigan/products/SLT-A99V/feature_4.html

700 :名無しさん@編集中:2012/12/25(火) 22:55:30.93 ID:jpvAnOTn
AVCHDは28Mbpsが上限じゃなかったっけ?
まあ60iでも28Mbasじゃ全く足りないんだけどねw

701 :名無しさん@編集中:2012/12/26(水) 02:53:52.12 ID:UX1UTdmF
可逆のスレで非可逆の話持ってくんなクズ

702 :名無しさん@編集中:2012/12/26(水) 05:04:27.92 ID:TkCeVOu7
くーずくーず

703 :名無しさん@編集中:2013/01/04(金) 22:42:11.67 ID:WISoC4Ry
UtVideo使ってるんだけど、メディアプレイヤーで再生すると
bt709で再生されてるみたいなんだけど
もとはbt601みたいだから、色空間の情報が入ってないのかな?

704 :名無しさん@編集中:2013/01/07(月) 14:17:47.92 ID:JzLQnXQQ
それはお前がBt.601のソースをBt.709に色空間変換してエンコしたからだろ。

705 :名無しさん@編集中:2013/01/08(火) 00:00:51.61 ID:GxO/Bz8A
ソースはRGBだな
自分とこの環境では、色空間未指定だとbt709で再生されるようだ

706 :名無しさん@編集中:2013/01/08(火) 09:53:18.00 ID:Ja32Rxsv
だからwwwお前はwww

707 :名無しさん@編集中:2013/01/21(月) 02:04:11.78 ID:lan2Ido8
TSを中間ファイルとして圧縮するとき可逆圧縮ならLagarithかhuffyuv使ってれば色空間考えなくていいよね?
あと、40分の動画を処理するのに40分かかるのに4本同時でも計1時間というのはどういうこっちゃい。
ディスクIOもCPU使用率も全然飽和してない。

708 :名無しさん@編集中:2013/01/21(月) 06:41:51.76 ID:2HD4a5p8
>>707
YV12で圧縮できたらなんでもいいけど、huffyuvはどうだろう。

709 :名無しさん@編集中:2013/01/21(月) 13:25:35.93 ID:t/9KH83+
>>707
ts→Lagarithかhuffyuv の時にどのようなソフト使ってるの?

710 :名無しさん@編集中:2013/01/21(月) 15:37:01.70 ID:k5qCC194
どちらも色空間考えずに使えば設定ミスでRGBに変換されてもおかしくない

711 :名無しさん@編集中:2013/01/21(月) 17:06:00.08 ID:noOkv13K
>>707
Vista/7でWMV9をインスコしてしまうとそうなる。
確かアンインストでも戻らなかった気がする。

712 :名無しさん@編集中:2013/01/21(月) 17:08:14.41 ID:noOkv13K
ごめん7だけだわ。
ついでにWMVじゃなくてWMEだわ。

713 :名無しさん@編集中:2013/01/21(月) 17:24:49.70 ID:6rg9h042
UtVideo最強伝説

714 :名無しさん@編集中:2013/01/21(月) 19:52:04.46 ID:lan2Ido8
>>709
TMPGEnc Video Mastering Works 5使ってる。

715 :707:2013/01/21(月) 20:19:19.39 ID:lan2Ido8
>>708
よく調べたらTSはYV12でhuffyuvは対応してなかった。
Lagarithでデフォルトモードならひとまず大丈夫みたい。
ttp://goldenhige.cocolog-nifty.com/blog/2010/02/lagarith-168a.html

716 :707:2013/01/22(火) 02:43:22.50 ID:kYLgj5p9
そもそもTMPGEnc Video Mastering Works 5は全部一度RGBに変換しちゃうみたいだ。
これ使ってる限り二回色変換入るから。。。オワタ
カット編集の使い勝手がものすごくいいのに使えないじゃんか!

717 :名無しさん@編集中:2013/01/22(火) 09:12:53.14 ID:uIUeTUNH
>>716
avs + VirtualDub(Fast recompress)等を使えば変換を回避できる。

718 :名無しさん@編集中:2013/01/22(火) 12:20:29.41 ID:JKP7TFmm
Utでbt709出力できるようになるといいな

719 :名無しさん@編集中:2013/01/22(火) 12:39:17.02 ID:8/opT7Kg
Utの作者はレスポンス早いから
要望出せば対応してくれるでしょ

720 :名無しさん@編集中:2013/01/22(火) 12:51:43.46 ID:qxQcHZLx
>>718
可逆圧縮=入力されたものを無劣化で出力するってことだから
色空間の変換はフロントエンドの仕事でしょ

721 :名無しさん@編集中:2013/01/22(火) 16:06:10.69 ID:isDmieSh
http://umezawa.dyndns.info/wordpress/?p=2507
そもそもこの変更がBT.709のためのものだからな

コーデック側でYUV<->RGBをBT.709で行えるようにするには、
YUV422とYUV420で新たに二つFourCCを追加しなくてはいけなくなるので、
代わりにDMOデコーダを作ることで変換をDirectShowFilterやレンダラーで
制御できるようになったんだよ

722 :名無しさん@編集中:2013/03/23(土) 06:31:10.99 ID:CePABXBE
Zip Motion Blocks Videoすげえ縮むんだが

723 :名無しさん@編集中:2013/03/25(月) 17:55:19.62 ID:j37ZXLrG
500MBくらいのULY2で圧縮した動画を何の編集もせずに
再圧縮無しで出力したら3KBくらい減ってるんだけどこれ何の差なの?
一応スレ出てる色空間だのなんだのはちゃんとしてる筈なんだけど

724 :名無しさん@編集中:2013/03/25(月) 21:21:13.46 ID:++/lE1eG
チャンクのアライメントの違いかもしれない?

725 :名無しさん@編集中:2013/03/27(水) 17:59:45.92 ID:Tgeur7RJ
元の動画はアマレコTV+ULY2(デコード速度優先)で書きだしたファイルなんだけど
AviUtl(再圧縮無し)を通す事によってアライメントが変わってごく僅かにサイズが減ったって事?
動画の可逆性は維持されてると考えて良いのかな?500MB対して3KBしか変わってないし

726 :名無しさん@編集中:2013/03/28(木) 20:34:57.16 ID:QADHkfR8
>>725
VirtualDubのHexeditorか何かを使ってビデオチャンクのサイズに差が無いのを確認すればいいんじゃない?
サイズが変わってなければアプリによってオーディオのチャンクサイズやアライメント・パディング等が異なってるのかも

727 :名無しさん@編集中:2013/03/28(木) 23:01:41.13 ID:rG5g5EfM
初めて使ったから見方がよくわからんけど
指摘の通り
Stream 0 : byte pos *******, chunk *
って部分(映像?)は完全に一致してる一方
Stream 1 : byte pos *******, chunk *
の方(音声?)はバラバラってか
AviUtlの方は映像、音声、映像、音声って規則正しく並んでるけど
元のファイルは映像6毎に音声1って感じになってる上
最終行の累計?(Stream 1 : byte pos *******)のサイズが違ってるような
AviUtlも方がちゃっと大きくなってるけどこれは音声の方が可逆になってないって事?

728 :名無しさん@編集中:2013/03/29(金) 21:26:11.39 ID:d3Obi59Q
映像は[00dc: 数字]の数字部分(dcやdbが映像を指してる)が一致してるなら再圧縮無しで処理できてると思うよ。
音声([01wb: 数字]など)はPCMだったら再圧縮無しでもアプリによってチャンクのサイズが
変わったりするんじゃないかな。
音声の合計は映像の長さに合わせて無音データとか付け加えてるかも。

729 :名無しさん@編集中:2013/04/02(火) 21:07:18.05 ID:/2myLRrR
分離させたwavのwaveformdataって部分のサイズが違ってるのはなんか弄られてるんだよね?
だとするとやっぱり音声が可逆になってない気がする
aviutlだけじゃなくてffmpegとかVirtualDubも試したけど
Hexeditorで調べた元の動画の音声部分(01wb)と
分離したwav(waveformdata)のサイズが一致するのは
ffmpegで分離したwavだけで
aviutlとVirtualDubで分離したwavはサイズが減ってるんだけど

730 :名無しさん@編集中:2013/04/02(火) 21:54:05.78 ID:TtvHn58P
PCMだったら気にしなくても大丈夫だと思うよ。
映像と音声の長さが異なると結合した時にずれるから長さを整えてるだけじゃないのかな。

731 :名無しさん@編集中:2013/04/02(火) 22:01:11.26 ID:FCo9vYJP
音声でPCMなら可逆どころか無圧縮じゃないですか

732 :名無しさん@編集中:2013/04/02(火) 23:30:57.94 ID:BWn/yxyH
音声のキャプチャ16bit44.1KHzが限界なのどうにかなんないかな

733 :名無しさん@編集中:2013/04/02(火) 23:50:08.31 ID:/2myLRrR
正確に分離できてると思われるffmpegの出力したwavファイルを
バイナリエディタで中覗いて比較したけど
やっぱり極々僅かな末尾の部分(無音部分かどうかはわからんがヘッダじゃない正味の音声部分)を削ってるみたい
>>723の最初に試したファイルだと
動画全体475MB、内音声2134KB、削られた部分4B
本番用の180GBのファイルでも試してみたが
動画全体180GB、内音声1.30GB、削られた部分1.36KB
って感じ
末尾は元々編集でカットする部分だし
どの部分に差異があるのかわからん気持ち悪さは解消されたので
これで納得しときます。お騒がせしてすいませんでした

734 :名無しさん@編集中:2013/04/03(水) 01:59:00.49 ID:PKcW6h+I
むしろffmpegが無理矢理長さ合わせる為に無音部分付け足してる可能性

735 :名無しさん@編集中:2013/04/03(水) 02:39:45.90 ID:G5fSHqNv
いやそれはないと思う
>>723 >>729でも書いたが
元動画はアマレコTVが書き出したファイルでffmpeg関係無いから
元動画と元動画からffmpegでwavだけ分離したファイルの音声の正味部分(Hexeditorで調べた)のサイズが一致して仮にこれをAとして
元動画からAviUtl、VirtualDubでwavだけ分離したファイル、AviUtlで再圧縮無しで書きだした動画の音声部分
AviUtlで再圧縮無しで書きだした動画からffmpeg、AviUtl、VirtualDubでwavだけ分離したファイルの音声の正味部分が全て一致してBとすると
AからBで明らかにサイズ減ってる>>733
つまりAviUtl、VirtualDubを通すと末尾の何かを削ってるのは間違いないと思う

736 :名無しさん@編集中:2013/04/03(水) 13:33:46.32 ID:QiLj2Z5m
比較したいならコンテナに入れずrawデータで出力しろ
ファイルサイズが違おうが最終出力が一致すればそれは可逆だ

737 :名無しさん@編集中:2013/05/27(月) 17:04:12.77 ID:f39LhD3Q
Ut Videoで一番画質がきれいかつ、データ量を多く圧縮できる設定が
分かる方はいらっしゃいますか?

738 :名無しさん@編集中:2013/05/27(月) 17:12:11.10 ID:f39LhD3Q
通常は、「Ut video codec YUV42 (ULY0)VCM x86」というものを選んで
設定をデフォルトのままで書き出しをしています。

739 :名無しさん@編集中:2013/05/27(月) 18:06:03.11 ID:BNsyyHO0
"可"逆圧縮だから色空間さえ間違えなければ劣化なし

740 :名無しさん@編集中:2013/05/27(月) 23:22:22.76 ID:vFpPH1/S
これらのコーデックを使用してゲームを作った場合
プレイヤーもこのコーデックを入れないとプレイできませんか?

741 :名無しさん@編集中:2013/05/27(月) 23:28:32.81 ID:jxvLHhlO
コーデックってそういうもんだ
同梱すればいいんでないの
ライセンス的にどうなのかは知らんが、リンクしなければ単なる再配布になるんじゃないのかね
知らんからちゃんと確認してくれよ

742 :名無しさん@編集中:2013/05/27(月) 23:39:27.42 ID:BNsyyHO0
>>740
どんなゲームかしらんけど普通は不可逆圧縮のデータを使うものでは?(容量も無駄にでかいし)
25GBのBDをムービーで埋め尽くしたいならアリだろうけど

743 :名無しさん@編集中:2013/05/28(火) 00:02:13.97 ID:EMzB99hO
ゲームのムービーに可逆圧縮使うとか正気かよ

744 :名無しさん@編集中:2013/05/28(火) 00:12:10.40 ID:EwiwJMI+
>>740
記憶媒体にアクセスするコストはタダじゃあないんだぜ……?

745 :740:2013/05/28(火) 14:08:41.82 ID:87iAP3Hv
え!?そうなんですか?
AVIの圧縮は可逆がいいと聞きまして
それで全部レンダリングしてしまいました(´;ω;`)ウゥゥ
不可逆ならXvidやh264とかですかね? 
どれがいいのかわからず当初はh264でやってました…
不可逆ならコーデックをそれぞれインストールする必要はないんですかね?
スレチなので申し訳ないのですが、それだけ教えていただけるとありがたいです…

746 :名無しさん@編集中:2013/05/28(火) 14:44:51.02 ID:EMzB99hO
>>745
この板でスレ探して質問しろ

ゲ製作技術
http://toro.2ch.net/gamedev/

747 :名無しさん@編集中:2013/05/28(火) 15:40:02.13 ID:LJtzEdEo
わざわざゲームの映像に可逆を使うってのもスゲーな。
縮むにしても限度があるだろうし、無駄にデカくなるだけだろ。

748 :名無しさん@編集中:2013/05/28(火) 23:20:55.74 ID:EwiwJMI+
>>745
まあ確かに、映像編集する際の中間形式には可逆形式が最適(というか一択)だ
ただ、どうしてもファイルサイズが大きくなる都合上、HDDの容量も食うし、読み込みも遅い
だから、狭いディスクに収めなきゃならない時(例:DVD)とか、
狭いネット回線に流さなきゃならない時(例:動画投稿サイト)とかには向いていないのは分かるな?
で、ゲームでの話だが、ネット回線程ではないにせよ、ぶっちゃけHDDからの読み込みは遅い
(不等号で書けば、CD・DVD>>HDD>>メインメモリ>キャッシュメモリの順で読み込み時間が掛かる)
つまり、ゲームのムービーを全部可逆でやってたらロード時間が鬱陶しい上、プレイヤー側としては
高画質の有り難みは分かりづらいことに……(MPEGはなかなか優秀な圧縮形式だもんね、仕方ないね)

749 :名無しさん@編集中:2013/06/01(土) 16:50:09.77 ID:d9QERt2K
配布して他人に見せる用途ならデフォルトで必ず再生出来るWMVでいんじゃねえの これならXP使ってる奴でもデフォで見れる
想像以上に情弱が多いからH264でエンコして手渡すと大抵「映像が映らなかった」で終わる

750 :名無しさん@編集中:2013/06/02(日) 00:31:52.16 ID:zasIXNfo
そうそう、WMVは未だに根強い需要があるんだよなぁ。
俺も自作動画販売してるんだけど、動画形式はホント頭の痛い問題なんだよ。
コーデック?なにそれ?ってのが普通に居るんで、XPでデフォで再生出来るってのはスゲー大事。
ただMSがもうやる気ねーからなぁ。

751 :名無しさん@編集中:2013/06/02(日) 00:39:28.44 ID:uOAr7OTc
WMVは相手がMacだと迷惑かける
今はmp4が一番ではないかな

752 :名無しさん@編集中:2013/06/02(日) 10:49:43.16 ID:vwYJ+jJ7
UtVideo地味に更新されてるから確認してみれ

753 :名無しさん@編集中:2013/06/05(水) 08:18:00.70 ID:ENPqz4jj
>>751
ゲーム用途と書いてあるのだから,狙ったOS以外の事は考えなくていいのでは.

754 :名無しさん@編集中:2013/06/05(水) 10:33:48.47 ID:uDe9lRYg
ゲーム用途の話はもう終わってるだろ?

755 :名無しさん@編集中:2013/06/10(月) 21:39:05.66 ID:E9p7Vq6p
utvideoのULY0とULH0の違いってコーデックIDだけで中の映像データは同じって理解でいいのかしら?

756 :名無しさん@編集中:2013/06/10(月) 21:42:42.45 ID:IHlRJJ7s
色空間が違うよ
まぁ動画オタじゃなきゃ説明なしでわけわからんよな

757 :名無しさん@編集中:2013/06/10(月) 21:49:25.37 ID:E9p7Vq6p
その色空間の違いが映像データの違いとして出てくるのかよくわからんのよね
ULY0とULH0で出してみてx264でエンコしたら全く同じデータになったから

758 :名無しさん@編集中:2013/06/11(火) 12:03:07.74 ID:/8SBH9LO
>>755-757
参考
  https://twitter.com/Paranoialmaniac/status/344080394062270466
  https://twitter.com/Paranoialmaniac/status/344082370812583937

ULY0もULH0も、データをYUV4:2:0形式で圧縮して保持する。
「YUV4:2:0データを渡して圧縮する」という場合は、保持されるデータはどちらも同じものになる。

違いが出てくるのは、
  「処理の途中でYUV⇔RGB変換が入ってくる場合」
となる。例えば編集ソフトに読み込んだ場合、UtVideoに対して
「RGBで渡してくれ」という処理を要求するものがあるとする。
この場合、
  ●ULY0は保持しているYUVデータをBT.601として扱い、UtVideo内部でYUV→RGB変換して渡す
  ●ULH0は保持しているYUVデータをBT.709として扱い、UtVideo内部でYUV→RGB変換して渡す
という処理になるので、同じデータを保持していた場合でも、ULY0とULH0とでは色が違って見えることになる。

759 :名無しさん@編集中:2013/06/11(火) 12:15:35.25 ID:/8SBH9LO
圧縮時で言うと、例えば
  「ULY0やULH0にRGBデータを渡して圧縮する場合」
は、
  ●ULY0は、受け取ったRGBデータを内部でBT.601の係数でRGB→YUV4:2:0変換し、圧縮保存する
  ●ULH0は、受け取ったRGBデータを内部でBT.709の係数でRGB→YUV4:2:0変換し、圧縮保存する
となるので、保存されるデータはそれぞれ異なるデータとなる。

要するに、映像元ソースとか編集ソフトの特徴なども含めて映像処理をトータルで見て
  ●YUV⇔RGB変換があるかどうか。また、それはどこで行われるか。
  ●YUV⇔RGB変換があるなら変換係数(BT.601orBT.709)は適切になるか。
ということを考えないといけないってことになる。
間違っていた場合、色が変わって見えることになる。

760 :299:2013/06/11(火) 14:00:39.94 ID:CwfWsYlw
>>759
えくせれんと!

761 :名無しさん@編集中:2013/07/07(日) NY:AN:NY.AN ID:QgJSoOQb
>>759
今までそれが対応せずutvideo使われた動画は劣化している
ってことになるから作られた動画には完全性が削がれちゃってるね

762 :名無しさん@編集中:2013/07/07(日) NY:AN:NY.AN ID:7zPCmcCu
>>761
最終的にはYV12とかでエンコするんだし
気にしなくておk

763 :名無しさん@編集中:2013/07/08(月) NY:AN:NY.AN ID:85d3HWRW
よくわからんからBT.601はSDで、それ以上はBT.709って適当に覚えたけど
4k8kとかにもBT.709でいいんだろうか
と未来の自分を心配してみる

764 :名無しさん@編集中:2013/07/08(月) NY:AN:NY.AN ID:IrvABD48
4k8kはBT.1361だから、まあBT.709と同じようなもんだな
ただし最低10bitだけど

765 :名無しさん@編集中:2013/07/08(月) NY:AN:NY.AN ID:J9NQ/QmY
>>761
>今までそれが対応せずutvideo使われた動画は劣化している
>ってことになるから作られた動画には完全性が削がれちゃってるね

間違ってる。ULH2、ULH0の追加と完全性云々は全く関係ない。

完全性を保ちたいのであれば、元素材や編集ソフトなどの色空間の扱いをしっかり把握して、
   アルファつきRGBならULRA
   RGBならULRG
   YUV4:2:2ならULY2 (またはULH2)
   YUV:4:2:0ならULY0 (またはULH0)
といった具合にしっかりコーデックを使い分けていれば、きちんと完全性は保たれる。
エンコード・デコード時に色空間をしっかり考えないといけないというのは元々の話であって、
ULH2、ULH0の追加は、選択肢が増えただけに過ぎないよ。

前にも書いたと思うんだが、「可逆圧縮」というのは、色空間をしっかり考えて、
編集手順やコーデックの選択などを適切に行わないと可逆にはならない。
RGBの素材をULY0で圧縮してしまえば、RGB→YUV4:2:0変換によって劣化が生じる。
そういうこと。

766 :名無しさん@編集中:2013/07/11(木) NY:AN:NY.AN ID:feTol9JD
YUV4:2:0を4:4:4と効率良く書き換える方法ってないのかな

767 :名無しさん@編集中:2013/07/11(木) NY:AN:NY.AN ID:IUqhyKLE
Lagarith使用中のCPU負荷が10%くらいにしかなりません
マルチスレッド使用にチェックを入れてエンコしてるのですがこんなものなのでしょうか?

768 :名無しさん@編集中:2013/07/13(土) NY:AN:NY.AN ID:fIGBWDUM
>>766
なにがしたいのかよくわからんのだが。

769 :名無しさん@編集中:2013/12/02(月) 15:46:47.31 ID:Azw/fWRW
圧縮率とfps比較

ttp://www.yuvsoft.com/wp-content/uploads/2011/08/lossless_codecs_comparison.png
ttp://www.yuvsoft.com/2d-technologies/lossless-video-codec/

770 :名無しさん@編集中:2014/01/15(水) 04:25:55.77 ID:L25nr9UC
avs2aviでUtVideo Codecのavi出力すると120GBくらいのところで処理が中断されちゃうんだけど…
これはUtVideoの問題かな?
それともavs2aviかAvisynth側の問題?
それかうちの環境に問題があるっておちだろうか

771 :名無しさん@編集中:2014/03/30(日) 15:27:38.22 ID:oxC05eNP
>>770
自分が "その事について行った思考" 等には一切触れないところからすると
処理が完了しなかったという時点で原因究明については即決他人に振ったわけだな。

そういうお前の根性に問題がある.

772 :名無しさん@編集中:2014/05/14(水) 20:31:50.17 ID:6oZq8Qfw
保守。X264可逆はどう?

773 :名無しさん@編集中:2014/05/18(日) 16:59:09.86 ID:X8I1eEh7
保守

774 :名無しさん@編集中:2014/06/24(火) 10:02:57.07 ID:G4PLHdBp
結構使わせてもらっているUt Videoがいつの間にかv210に対応してたんだなぁ
うちのキャプチャデバイスに最適だ

775 :名無しさん@編集中:2014/06/24(火) 13:14:04.85 ID:eCs0BBvg
>>774
v210は何かいいことあるの?
というよりそもそも違いがよくわからないのだが。

776 :名無しさん@編集中:2014/06/29(日) 00:33:40.21 ID:NOLTPzIL
>>774
いまいち10bitでの処理のイメージが湧かないんだけど、
どういう環境(ボード・キャプチャソフト等)で、どういう風にUQY2を使ってるのだろう?

>>775
以前からあったULY2は8bit深度のYUV4:2:2だが、UQY2は10bit深度のYUV4:2:2。
YUVは輝度と色差の組み合わせで色を表すが、例えば8bitだと
輝度が0-255の256段階で表されるのに対し、10bitでは0-1023の1024段階で表される。
要するに10bitのほうが精密に色情報を保持できることになる。
ただ、元ソースから出力過程までをトータルで考えないと、10bitの精密さが生かせないこともある。

777 :名無しさん@編集中:2014/06/29(日) 00:42:21.73 ID:NOLTPzIL
つうかUtVideoのUQY2ってどういう風にしたら試せるんだろ?
入出力がv210だけみたいだからAviUtlでは使えないけど、
Avisynthとかをうまく使えばUQY2のAVIを作ったりできるん?
キャプチャでUQY2を使おうとしてる>>774はどうやって使ってるん?
10bitの実用って、まだよくわかっとらんねん(´・ω・`)

778 :名無しさん@編集中:2014/06/29(日) 01:04:05.43 ID:OgDsyoiN
8bit、4:2:2の素材をデバンディングしてから10bit、4:2:2に格納して編集→エンコード
とかかな?
俺もよくわからん。
編集とかでクロマキーとかが入るんなら4:4:4一択だろうし。
編集時にどの程度のクオリティを求める場合なんだろ?

779 :名無しさん@編集中:2014/06/29(日) 02:31:52.25 ID:NOLTPzIL
UQY2の使い方を調べてたら、AMV4がリリースされてたことに気付いた。

  インテル製CPUの“AVX2”に対応した高速動画コーデック「AMV4ビデオコーデック」
  http://www.forest.impress.co.jp/docs/news/20140627_655554.html

作者のブログにベンチマークとか説明とかが色々書かれてるけど、
QSVよりCPU負荷が低いとか、何それ怖い的な性能向上がなされてる模様。

  http://amalabo.blog35.fc2.com/

有償とはいえ面白そう。

あ、UQY2の使い方はまだよくわからないんで引き続き情報募集中。
キャプチャ環境もないんでフリーソフトでやれるやり方があれば教えてくれくれ。

780 :名無しさん@編集中:2014/06/29(日) 21:29:06.53 ID:4FiydeQo
>>777,>>779ですが、UtVideoの作者さんのブログでVirtualDubでv210入出力ができることを知り、
試してみたところ、[Video→Color Depth] で[4:2:2 YCbCr 10-bit (v210)]を選ぶことで
とりあえずUQY2での書き出し、読み込みができました。あまり意味はありませんがご報告。

v210での展開のみしかサポートしていないせいだと思うけど、AviUtlに読み込ませるとエラー吐いて落ちる。
PremiereProなんかは無圧縮v210の入出力ができるっぽいけど、UQY2の読み込みはできるんだろうか。
書き出し時はコーデックに渡されるのがRGBだからダメっぽいと作者ブログにあったけど・・・。
やっぱりキャプチャソフトや編集ソフトでの10bit入出力対応状況がよくわからないや。

781 :名無しさん@編集中:2014/06/30(月) 01:06:55.56 ID:wU+GT1lW
キャプチャデバイスならUSB3.0版のIntensityが10bitキャプチャに対応してたと思う
ゲーム映像ソース等なら8bitの422よりは色の再現性良いんじゃないかな

でも現状の編集ソフトでの利便性考えると録画変換の時点で444にした方が楽な部分多いか

782 :名無しさん@編集中:2014/07/07(月) 12:23:11.41 ID:zm/1emx0
AMV4ぱねえwwwwwwwww
Frapsで録画した動画をエンコしたら1/8になった
しかも軽い

783 :名無しさん@編集中:2014/07/07(月) 19:32:41.11 ID:cNnnzFOX
>>782
よく知らんけどFrapsのコーデックって非可逆じゃなかったっけ?そんなに縮むものか?
RGB可逆でも録画できるみたいだから、そっちで録画してたやつかな?

AMV4は不具合があってv4.0.2で修正されてるので、一度アンインストールしてから
インストールしなおしたほうがいいみたいだよ。
  ttp://amalabo.blog35.fc2.com/blog-entry-275.html

784 :名無しさん@編集中:2014/07/07(月) 23:29:42.88 ID:XvheWVIt
AMV4作者がやってる可逆圧縮コーデック比較ベンチ見たら
UtVideoの8スレッド動作も無料にしてはかなりいい性能叩きだすじゃん

785 :名無しさん@編集中:2014/07/08(火) 09:57:58.86 ID:7/8LlU2w
>>783
知らんけど時間軸でも圧縮すれば縮むんじゃね?
今のところ可逆は編集用途でしか使ってないからそんなのだったら俺には不要だが

786 :名無しさん@編集中:2014/07/08(火) 20:12:55.82 ID:TxE+0d77
あまラボ AMV2MTとAMV4の違い まとめ
ttp://amalabo.blog35.fc2.com/blog-entry-271.html

シングルスレッドで性能ぶっちぎってるのか・・・

AVX2.0対応じゃないけどそれでもデコード負荷はamv3やutと比較して低いね半分以下だ

787 :名無しさん@編集中:2014/07/08(火) 23:17:30.65 ID:uWcQ3C3a
frapsはエンコーダ選べれば良いのにねぇ
RGB可逆モード付けたのは良かったけど

788 :名無しさん@編集中:2014/07/12(土) 09:13:21.10 ID:DFtOLGUZ
FrapsはRGBYUV問わず可逆だクズ

789 :名無しさん@編集中:2014/07/12(土) 09:52:10.94 ID:ELqfjeLZ
いきなりキレてどしたー?

790 :名無しさん@編集中:2014/07/18(金) 13:07:58.90 ID:3N09pHhr
x264vfwのbm(masternobody)版で、選択肢でlosslessを選んでも可逆になってないという
バグ(?)を見つけたのでx264vfwスレに書いてみました。
  http://peace.2ch.net/test/read.cgi/avi/1351856057/441-442

どうやらコマンドラインオプションに「--sliced-threads」をつけないと可逆にならないようです。
対象はx264vfw_38_2274bm_36885ですが、1つ前のx264vfw_37_2200bm_33968でも同様です。
それ以前のバージョンについては未検証。

見逃してる点もあるかもしれないので、追加検証や指摘などお待ちしております。

791 :名無しさん@編集中:2014/07/18(金) 15:45:59.51 ID:3N09pHhr
なんか自分の勘違いだったみたいなので>>790は忘れてください。
Zero Latencyにチェック入れればよかったんですね・・・。大恥かきました・・・。

792 :名無しさん@編集中:2014/07/20(日) 03:41:46.85 ID:DPDJBV9r
                           ヽ
              _,,.,、、,.ィ-- ti- 、、、....,,,,_   ',
         ,,..、、ri':'゙/~   レ     '  ゙ヘ:l : : : :~,>
   _,...r:::''"::/ l/ .l:/-=ニ二,'_ー- 、、   !l!;: r '"
'''<:::::::::::::;、r'          `'' ‐-`.、 /
-、 l::::::::::::l           <"゙'i;ソ'   ',
~.ヽ l:::::::::::l             ~'     '、
/ .) .l::::::::::!                    '、
 ヽ .l:!l:::::l ヽ                  '、
\ '  l! l::!l! ヽ                    ,'
  ゙    ヾ               ‐'" ,. r ゙  そんなに何も見えてないんじゃ
ー-‐i               ,.r,,iilll鬚髯ヲ   
.   l            `''' ‐‐ ---t‐'     生きてても面白くないでしょう
 ̄ ̄ ̄ ̄ ̄ ̄~"''、' ‐ 、       ー‐ノ
             ',  ヽ       l
               l   l       l
              l    l     ノ  

793 :名無しさん@編集中:2014/07/23(水) 17:27:26.34 ID:WKZDN2lI
huffyuvsって置いてあるところないんかな
デコードできなくて昔の動画がうまく開けないという

794 :名無しさん@編集中:2014/07/23(水) 18:28:12.06 ID:TDy8zWD8
>>793
ググればすぐに出てきますやん・・・。入れてもまともにアンインストールできないらしいけど。

795 :名無しさん@編集中:2014/07/23(水) 18:40:46.80 ID:jnrHk/i0
>>793
> うまく開けない

上手も下手もねぇだろ馬鹿

796 :名無しさん@編集中:2014/07/23(水) 18:50:58.84 ID:TDy8zWD8
HuffyuvS入れたとしても「うまく」開けるかどうかはわからんな。
開くことはできるだろうけど、過去ログやググって出てくる記事を見てもわかる通り、
HuffyuvSはちゃんと理解して使ってないと色が変わったり崩壊したりすっから。

797 :名無しさん@編集中:2014/07/23(水) 19:06:01.47 ID:WKZDN2lI
>>794,796
ググり方悪かったのか、webarchiveとか必死に探してたわ
アンインスコ難しいのなら取りあえず仮想環境にHuffyuvS入れて
動画ファイルを現行環境で弄りやすい別形式に変換する

>>795
揚げ足いらんて

798 :名無しさん@編集中:2014/07/23(水) 20:53:21.96 ID:jnrHk/i0
>>797
お前のそういうアバウトなところが…まぁいいか
コンピュータ相手に 1bit でも揚げ足取るなってのは無理だからな。

799 :名無しさん@編集中:2014/07/23(水) 21:00:31.99 ID:TDy8zWD8
>>798
コンピュータばかり相手にしすぎてると場の空気とか読めなくなるから気を付けようね。(´・ω・`)

800 :名無しさん@編集中:2014/07/23(水) 21:04:46.92 ID:jnrHk/i0
>>798
> 場の空気
馬鹿が数で押し切ろうとすんなよ

801 :名無しさん@編集中:2014/07/23(水) 21:11:40.02 ID:TDy8zWD8
上のやりとりやこのスレの空気とかじゃなく世間一般での話な。
こんなとこでキレてばかりじゃつまらんよ。

802 :名無しさん@編集中:2014/07/23(水) 21:16:53.67 ID:jnrHk/i0
>>801
キレてると言えば押し通せるの ?

803 :名無しさん@編集中:2014/07/24(木) 22:58:41.52 ID:mM1TimBn
(コイツ関わったらアカン奴やな)

804 :名無しさん@編集中:2014/07/25(金) 17:35:27.56 ID:g9CCdRbh
アシタカかな?

805 :名無しさん@編集中:2014/08/14(木) 16:37:27.52 ID:Bt9XvOw9
>>804 の頭はジブリでいっぱい

806 :名無しさん@編集中:2014/08/14(木) 20:00:34.82 ID:LQz3L4zQ
そりゃ押し通す連呼してたらねぇ・・・

807 :名無しさん@編集中:2014/08/14(木) 23:14:57.80 ID:py4fLx0F
押切もえ

808 :名無しさん@編集中:2014/10/14(火) 13:11:43.19 ID:V6XUzGLS
某動画サイトで「UtVideoとAMV4の画質比較」なる動画を見かけた・・・
ちゃんと理解して使おうぜ・・・

809 :名無しさん@編集中:2014/10/14(火) 19:04:18.73 ID:fYqK3abi
後でx264を使ってqp0に

810 :名無しさん@編集中:2014/10/23(木) 03:15:02.03 ID:/yr93t6L
Windows8.1を使っている方に伺いたいのですが、レジストリエディタ(regedit)で
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32
を見た場合、「vidc.yv12」という名前のエントリは存在しているでしょうか?
また、存在している場合、データはどのようになっているでしょうか?

MikuMikuDance v9.24で背景AVIを読み込む場合に、
  ・UtVideo14.2.1のULY0/ULH0だと真っ黒になってしまう
  ・Lagarith1.3.27のYV12も、Lagarithの設定で「Always Suggest RGB for Output」に
   チェックを入れておかないと真っ黒になってしまう。
  ・Xvid 1.3.3だと「AVIファイルを読み込めません」のエラーが出て読み込めない
という状況が発生しており、vidc.yv12の有無や値が関係しているのではないかと推測しています。
現状のうちの環境ではvidc.yv12は存在していないのですが、これまでに何度か各種コーデックの
導入・削除を繰り返してきましたので、デフォルトの状態を知りたいと思った次第です。

811 :名無しさん@編集中:2014/10/24(金) 02:48:34.59 ID:ezx2CJak
>>810
うちの環境にはyv12のエントリはないね
もしかしたらffdshow video decoderのコーデック設定で、raw videoの項目でYV12がサポートされる状態になってるとか?

812 :名無しさん@編集中:2014/10/24(金) 03:04:29.31 ID:ezx2CJak
raw videoフィルタは関係なさそうだったけど、
aviutlでYV12のファイルを読み込もうとしたらエラーになったんで、
8.1ではもう削除された機能ってことなのかな?

代わりにffdshow Video Decoderのコーデック設定のraw videoにYV12の
サポートを設定したら開けるようになったよ

813 :名無しさん@編集中:2014/10/24(金) 03:13:16.72 ID:ezx2CJak
aviutlはdirectshowソースプラグインがあるから開けるようになったけど、
ffdshowの設定してもMMDでは読めなかったね

814 :名無しさん@編集中:2014/10/24(金) 21:36:49.13 ID:iwkwQurY
>>811-813
ありがとうございます。やっぱりvidc.yv12はWin8.1ではデフォルトでは存在しないのですかね。
MMDの背景AVI読み込みはVFWのようなので、ffdshow rev4533を入れて、VFWの設定で
Raw videoを「全サポート形式」にしてみましたが、MMDでULY0が読めない状況は変わりませんでした。

これまでの流れをまとめて下さった方がいるので貼っておきます。

  一部のYUVなaviを、MikuMikuDanceが背景AVIとして正常に読み込めない問題
  ttp://togetter.com/li/736317

vidc.yv12に注目したのは、
  FAQ YV12 - Avisynth wiki
     ttp://avisynth.nl/index.php/FAQ_YV12
  VirtualDubModでYV12なavsファイルが読み込めない
     ttp://freesoft.tvbok.com/movie_encode/virtualdubmod/yv12avs.html
の記事を読んだからでした。記事にしたがってXvid1.3.3の入れ直しもしてみましたが駄目でした。
XP機を使っていた頃は確かDivX YV12 DecoderというのがVFWコーデックに入っていたような気がするのですが、
DivX10.2以降はDivXコーデックは外されてしまったので、古いのを探してきて入れないと駄目なようです。

しかしながら、vidc.yv12が無くてもULY0/ULH0が読み込めている人がいるので、
そこが本質というわけではなさそうです。なんだかややこしい。

815 :名無しさん@編集中:2014/10/24(金) 22:05:38.08 ID:iwkwQurY
とりあえず今までにやってみたことの流れを書いてみます。

1.MMD v9.24の背景AVI読み込みで、ULH2が真っ黒になり正常に読めないことに気づく。ULY2は読める。
  さらにULY0/ULH0を試してみたところ、この両者とも真っ黒になってしまうことが判明。
  MPC-HCでの再生やAviUtlへの読み込みなどは問題なく、MMDだけが駄目。
2.背景AVI読み込みでMMDが強制終了することもあったのでイベントビューアを見てみると、
  DxtoryCodec.dllで障害が発生していた。やむをえずDxtoryをアンインストール。(入れていたのはDxtory 2.0.128か126。)
3.MMDの強制終了は無くなったが、ULY0が読めないことに変わりなし。
4.UtVideo14.2.1をアンインストールして12.0を入れてみたがULY0が読めないことに変わりなし。14.2.1に戻す。
5.ふと気づいて、一時的にアンインストールしていたBlackmagicDesignのDesktopVideo10.2.2を
  再インストールしてみたところ、ULH2は正常に読みこめるようになった。
  HDYCのコーデック(Blackmagic HD 8 bit 4:2:2 Codec)が入ったことが影響しているのだろうか?
6.>>814のYV12系の記事を見て、Xvid 1.3.3を再インストールしてみたり、
  ffdshow rev4533を入れてVFWでRawVideoのYV12を有効にしてみたりしたが効果無し。
7.レジストリエディタで手動でvidc.yv12を作り、msyuv.dllやxvidvfw.dllを指定してみたが効果無し。

入れているVFWコーデック(に関係するもの):
  AMV2MT、AMV4、UtVideo14.2.1、Lagarith 1.3.27、x264vfw r2453bm、Xvid 1.3.3、
  ffshow rev4533、BlackmagicDesign DesktopVideo 10.2.2、GrassValley CodecOption 7.31-2939、
  MSI Afterburner 4.0.0-4604(RTV1というコーデックが入っている模様)

816 :名無しさん@編集中:2014/10/24(金) 22:23:01.59 ID:iwkwQurY
現時点での個人的な推測。VFWのデコードの挙動とかわかってませんので全然違うかもしれません。
正直なにがなんだかわからない。

1.MMDの背景AVI読み込みでは、コーデックに対して「形式指定無しのデコード要求」が出されるのではないか。

2.形式指定無しのデコード要求が来た場合、多くのコーデックでは内部保持形式と
  同じフォーマットでデコードデータを渡そうとする?
  ULY0/ULH0はYV12、ULY2はYUY2、ULH2はHDYC?

    1,2の参考:以下の記事のLagarithの「Always suggest RGB for Output」の説明
      ttp://goldenhige.cocolog-nifty.com/blog/2010/02/lagarith-168a.html

3.しかし、MMDの背景AVI読み込みは、VFWでRGB24しか読み込めない模様?
    参考:
      ttp://goldenhige.cocolog-nifty.com/blog/2010/01/mikumikudanceav.html

4.そのため、YV12等でそのまま渡されても理解できず、真っ黒になったりする?
  ただし、YV12等をRGB24に変換できるVFWコーデックが入っていた場合は、
  それが仲介役となってRGB24に変換してMMDに渡している?
  (なのでvidc.yv12やvidc.yuy2、vidc.hdyc等が必要だと思ったのですが、
   vidc.yv12無しでもULY0が読み込めている人がいるのでよくわからない)

MMD側の問題のような気がしますが、条件や挙動の理屈等が判明してすっきり解決できないものかと・・・。

817 :811:2014/10/25(土) 00:01:29.89 ID:PZfJz3hA
>>814あれからもう少し実験してみたんだけど、
vidc.yv12="msyuv.dll"にしてもyv12は再生できなかったから、
やはり8.1(OSが64bit版)のvfwではyv12はサポートされなくなったのかも

ff_vfwの設定をすれば「無圧縮のyv12」ならMMDでも再生できるようになったけど、
directshowみたいにフィルタの連結ができないvfwではlagalithとかの出力でyv12を
選ぶことは出来なくなってるみたい

818 :811:2014/10/25(土) 00:14:57.56 ID:PZfJz3hA
あと、virtualdubのcolor depthの設定でdecompression formatをyv12にした時は
lagalithのファイルもyv12として開くことが出来たから、やはりデコーダからレンダラ部分の
処理を自前で実装してないと開けなくなってるみたいだね
問題なく再生できる人はどんな環境なんだろ?

819 :811:2014/10/25(土) 00:38:34.84 ID:PZfJz3hA
>>816
普通はVCMの側からコーデックに最も都合の良いフォーマットを問い合わせて、
それが対応可能だったらそれを受け入れて、対応していなかったらコーデックに
RGB等で出力可能かどうかを問い合わせてみてOKならそのフォーマットでデコード出力する
という流れになってるはずだけど、この場合VCMがyv12に対応してないのに
コーデックの提案したyv12を受け入れてしまってるのが原因だと思う

本当はVCM側からRGB出力の問い合わせをすればRGBとして表示することが可能なはずだけど、
先にyv12で受け入れてしまうので、suggest RGBを設定した時だけ開けたんだと思う

yuy2は8.1のVCMでも対応しているみたいだからULY2とかは開けたんじゃないかな

820 :名無しさん@編集中:2014/10/26(日) 22:46:45.99 ID:gMc7tIdI
>>817-819
>>814-816です。ありがとうございます。色々試していてレスが遅れてしまいました。すみません。
ようやく整理できた気がしますが、まず、こちらで試してわかったことをいくつか。

●Xvid-1.3.3-20140407を入れていると、YV12のデコードが阻害されてしまう。
  (他のバージョンは確認していません)

>>817さんは
  >ff_vfwの設定をすれば「無圧縮のyv12」ならMMDでも再生できるようになった
とありましたが、うちではffdshowの「VFWの設定→Decoder→コーデック→Raw video」で
「YV12」「全YUV形式」「全サポート形式」を選んでも、YV12無圧縮のAVIをMMDの背景AVIに
正常に読み込めず、真っ黒になってしまっていました。
(なお、YV12無圧縮のAVIは、AvsPModでConvertToYV12()をしたavsを読み込み、
 「Tools→Script encoder(VFW)」で、「再圧縮なし」で出力したものです。)

この違いが不可解で色々試していたところ、VirtualDubModでYV12のAVIを開いて「File information」を見ると、
>>814にも書いた
  ttp://freesoft.tvbok.com/movie_encode/virtualdubmod/yv12avs.html
の記事のスクショにもあるように、「Xvid MPEG-4 Codec」がデコーダとして選ばれており、シークすると
  Error decompressing video frame 1: The source image format is not acceptable. (error code -2)
のようにデコードエラーを起こしていました。

そこで、Xvid 1.3.3をアンインストールしてみたところ、ffdshowのVFW設定が効くようになり、
「Raw video」で「YV12」「全YUV型」「全サポート形式」を選んでいれば、VirtualDubModでも
MMDの背景AVI読み込みでも、YV12無圧縮のAVIが正常に読み込めるようになりました。

つまり、Xvid 1.3.3が中途半端にしゃしゃりでてYV12をデコードしようとして失敗していたというわけですね・・・。

また、Xvid 1.3.3をアンインストールしたことでffdshowのYV12デコードが有効になったため、
ULY0、ULH0のAVIも、ffdshowをちゃんと設定すればMMDの背景AVIとして問題なく読み込めるようになりました。

821 :名無しさん@編集中:2014/10/26(日) 22:49:21.75 ID:gMc7tIdI
 
●DivXにも一応YV12 Decoderがついている(今更DivXを使う必要もないのであまり推奨しない)

DivXは10.2からDivXコーデックパックを外してしまいましたが、こちらの記事で最終版が配布されています。
  DivX 10.2: Removing Codec Pack | DivX Blog
  http://blog.divx.com/2014/04/23/codec-pack/
末尾にある2014/8/18追記のところの「〜download it 【here】」のところです。
bit.lyからの警告が出ますが、それを無視すればダウンロード可能。
インストール時にノートン先生が反応しますが、これは「RegClean Pro」という迷惑ソフトを入れようとするため。
途中で拒否できるので絶対に拒否する必要があります。うっかり入れないように。
インストールされるDivXコーデックは、
  DivX 6.9.2 Codec 06_09_02_00026_VfwCodec
  ビルト オン Feb 19 2010 @ 11:26:13
となっています。これには
  DivX 6.9.2 YV12 Decoder
が入っていますので、これでもYV12デコードができるようになります。(ffdshowより優先して使われます)
ただし32bit版だけですので、64bitアプリでのYV12デコードはできません。

●VirtualDubとVirtuaDubMod

 VirtalDubでは、「Internal DIB decoder」が内蔵されており、
 YV12などの各種非圧縮フォーマットを自前でデコードできるようになっています。
 入出力色空間なども>>818さんが言われているように色々設定でき、
 VCMのYV12デコーダーなどは必要としません。

 VirtualDubModの方は、入出力がRGBに限られているようです。
 そのため、YV12などを読み込むためには、別途対応するVCMのデコーダーが必要になります。
 試しにYV12無圧縮のAVIファイルを読み込ませてみると、YV12デコーダーの有無を判定できます。
 エラーが出ればYV12デコーダーが入っていないということ。
 エラーが出なかった場合は、「File→File Information」を開いて「Decompressor」を見れば、
 使われているYV12デコーダーがわかります。(ただしVirtualDubModは32bit版しかありません)

822 :名無しさん@編集中:2014/10/26(日) 22:58:16.13 ID:gMc7tIdI
MMDの背景AVIでULH2/ULY0/ULH0が真っ黒になることがある件の推測。

 1.MMDの背景AVI読み込みはVFWで、正常に扱えるのはRGB24のみ。

 2.普通はコーデックとネゴシエーションを行い、RGB24しか受け入れられないなら、
   コーデックからRGB24でデータをもらえばいい。
   しかし、MMDの背景AVI読み込みはこの部分の処理に問題があり、
   コーデック側が提示した形式を無条件で受け入れてしまう(?)。

 3.UtVideoの場合、入出力フォーマットはREADME参照。
     ttp://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.1-readme.ja.html
   ULY0はYUY2、ULH2はHDYC、ULY0/ULH0はYV12が最も優先度が高い。
   ネゴシエーションに問題のあるMMDの背景AVI読み込みでは、
   UtVideoはこれらのフォーマットで出力を行おうとする(?)。

 4.MMD側では、YUY2やHDYC、YV12はそのままでは読み込めない。
   だがYUY2やHDYC、YV12をRGB24にデコードできるVCMコーデックが入っていれば、
   それらがRGB24に変換し、正常に読み込むことができる(ようだ)。
   入っていなかった場合は正常に読み込めず、真っ黒になってしまう。

 5.YUY2はWindows標準のmsyuv.dllでサポートされているため、ULY2は問題ない。
   YV12やHDYCはWindows標準ではサポートされない(※注1)ため、対応するVCMコーデックが必要。
   YV12はffdshow(※注2)、HDYCはBlackmagic DesktopVideo。
   これらを入れれば、ULY0/ULH0/ULH2もMMDの背景AVIとして正常に読み込めるようになる。
   (ただ、MMDの背景AVI読み込みのためだけにこれらを入れる必要は無い。別のコーデックを使えばよいだけ。)

     ※注1: Windows8.1でサポートされていないのは確認。その他は不明。
     ※注2: ffdshowの場合「VFWの設定→Decoder→コーデック→Raw video」で「YV12」か「全YUV形式」「全サポート形式」を選択。
          DivXもYV12デコーダーを持つが、既に更新が停止されている上、32bit版しか無いのでx64版MMDでは役に立たない。
          Xvidは、Xvid-1.3.3-20140407を入れると正常にYV12デコードができず、ffdshowの邪魔をするだけとなるので使えない。

823 :名無しさん@編集中:2014/10/26(日) 23:52:32.20 ID:gMc7tIdI
追記:

Lagarithでも、YV12で圧縮したならYV12で出力しようとするので、>>822のULY0/ULH0と同様に
MMDの背景AVI読み込みでは、YV12デコーダーが入っていないと真っ黒になります。
Lagarithの設定の「Always Suggest RGB for Output」にチェックを入れておくと、
YV12で出力するのではなくRGBで出力するようになるので正常に読み込めるようです。

余談ですが、MMDv9.24のx64版でLagarithのYUY2で圧縮したAVIを読ませると、
lagarith.dllでエラーが起きてMMDごと強制終了となります。(うちの環境だけかもしれませんが)

824 :名無しさん@編集中:2014/10/26(日) 23:57:19.22 ID:gMc7tIdI
更に余談ですが、テストの過程で、
  「無圧縮のYUV系AVIをMediaFoundationで再生すると、解像度や色がおかしく見える」
ということに気づきました。
Windows8.1環境で、YUY2やYV12無圧縮のAVIをWindowsMediaPlayerで再生するか、
QonohaでMediaFoundationを優先する設定にして再生すると、以下の画像のようになってしまいます。
  ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up0838.png
なおtopoEditは以下のようになっています。
  http://2sen.dip.jp/cgi-bin/upgun/up1/source/up0839.jpg

何が起きているかはよくわからないのですが、豆知識的な情報として貼っておきます。

825 :名無しさん@編集中:2014/10/26(日) 23:59:44.54 ID:gMc7tIdI
よく見ると色は特に問題ないのかな・・・

826 :名無しさん@編集中:2014/10/27(月) 01:58:33.77 ID:MXSxCZf3
>>815で書いた

 >2.背景AVI読み込みでMMDが強制終了することもあったのでイベントビューアを見てみると、
 >  DxtoryCodec.dllで障害が発生していた。やむをえずDxtoryをアンインストール。
 >  (入れていたのはDxtory 2.0.128か126。)

についても、条件と原因を整理しました。発生するのは
  ・Dxtory(2.0.128で確認)をインストールしており、
  ・x64のYV12やHDYCのデコーダが存在しない場合に
  ・MMDのx64版で
  ・ULY0/ULH0/ULH2やLagarithのYV12など、YV12やHDYCを優先するコーデックのAVIを読ませた場合
です。

他にYV12やHDYCのデコーダーが無い場合に、なぜかDxtory Video Decoderが、
それらのデコードを行おうとして失敗するのが原因のようです。
試しにVirtualDubModでYV12のAVIを読ませてみると、DecompressorがDxtory Video Decoderになっており、
  VideoSourceAVI error: An unknown error occurred (may be corrupt data). (error code -100)
というデコードエラーが発生しています。
x86版MMDであれば真っ黒になるだけで済みますが、x64版MMDだと強制終了につながるようです。
なお、ffdshow(x64版)のVFW設定でYV12デコードを有効にしておけば、そちらが優先されるため、
x64版MMDでのDxtoryCodec.dllによる強制終了は発生しなくなります。
(ULH2はHDYCなのでBlackmagicDesign DesktopVideoを入れないと駄目ですが)

なおffdshow rev4533のx64版では、VFWコーデック(要注意警告あり)を有効にしてインストールしても
「VFWの設定」のショートカットが作られず、そのままではVFWの設定が開けないようです。
ただし、VirtualDubのx64版があれば、「Video→Compression→ffdshow Video Codec→Configure」で
x64版ffdshowのVFWの設定画面を開くことが可能です。
ただ、これでYV12デコードを有効にしても、x64版MMDではULY0/ULH0やLagarithYV12が正常に読めるようになるだけで、
YV12無圧縮のAVIは「AVIファイルを読み込めません」となるようです。
x86版の場合はYV12無圧縮のAVIも正常に読み込めるようになるのですが、x64版だとなぜか駄目です。

827 :名無しさん@編集中:2014/10/27(月) 02:47:03.25 ID:MXSxCZf3
なお、>>822のMMDの背景AVI問題についてですが、読めない理由が気になっているだけであり、
基本的には「MMDが普通に読めるコーデックで背景AVIを作って読ませればいいだけ」だとは思っています。

ただ、UtVideoにしてもLagarithにしても、RGBでの出力機能はもっているので、
MMD側の背景AVI読み込み処理を改善すれば、YV12やHDYCのデコーダーが無くても
普通に読めるようになるのではないかという推測はしています。
ただ、実装や仕組みの詳細は私にはわかりませんし、改善の余地がありそうというだけです。
VFWのプログラミング知識があればよかったのですが・・・orz

ここで書くのもあれですが、本件についてツイッターでご協力いただいた方も、ありがとうございました。
長々とすみません。

828 :名無しさん@編集中:2014/10/27(月) 03:06:26.48 ID:rSpOA+uE
>>827


Togetterも更新しておきました

私も、mp4をMMDの背景aviにそのまま使うためのバッチで、
RGBに変換するようにしているけど、それがが正しいのかどうかを
知りたかっただけなので

何にしても、RGBにしtておいたほうが無難そうですね

829 :811:2014/10/27(月) 06:50:57.59 ID:5C0mv7Ln
>>827
詳しいレポート乙です
なんかいろいろな要因が絡んでいて完全に原因を掴むのは無理っぽい感じですね
やはりデコードできないのにYV12フォーマットを受け付けるコーデックがありましたか

>>824の現象は
http://shinshu.fm/MHz/14.30/archives/0000238428.html
に近い物でしょうか
これもコーデックによってYV12からYUY2やRGBの変換方法の違いが関係してて面倒そうですな

830 :名無しさん@編集中:2014/10/29(水) 00:51:53.96 ID:RRTPEgTW
>>828
ほとんどの人は読めなければ別のコーデックやバッチを使ってみるでしょうし、実害はほぼ無さそうですね。

>>829
>>824について、もう少し調べてみました。

まず訂正ですが、YUY2の時におかしくなるというのは勘違いでした。
再生の冒頭でなぜか荒いフレームが表示されるため勘違いしてしまいました。すみません。
>>824の画像は間違った情報なので削除しました。

問題が起きるのはYV12の場合のみのようです。
で、YV12.aviのMediaFoundation再生で何が起きているかというと、どうやら
  「プログレッシブのフレームをBob化し、更にボトムフィールド分を捨てている」
という挙動になっているようです。
Avisynthで、
  AVISource("YV12.avi").Bob().SelectOdd()
とすると、MediaFoundationでの再生映像とほぼ一致します。
  ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up0854.png
デフォルトだとBFF扱いなので、SelectOdd()で取れるのはトップフィールド分。
ボトムフィールドを捨てて、トップフィールドだけから縦補間した映像になっているので、
画像のように、縦解像度が荒い映像になってしまっているようです。

なんでこんな再生の仕方になっているのかはわかりません・・・。

831 :名無しさん@編集中:2014/10/29(水) 18:56:06.65 ID:0qFed7SY
>>830
YV12のコーデックがffdshowだったら、出力の設定でインターレースフラグにチェック入れてない?

832 :名無しさん@編集中:2014/10/29(水) 21:06:22.93 ID:w9Gf5GvB
>>831
DirectShowではなくMediaFoundationなので、ffdshowは関与しないはずですね。
念のためYV12を無効にしてインタレースフラグのチェックも外してみましたが結果は変わりませんでした。
また、ffdshowの64bit版を入れていない状態で64bit版のWMP12やtopoEdit等で再生しても
>>830と同じ結果になります。MediaFoundationのバグか何かかもしれませんね。

833 :名無しさん@編集中:2014/10/30(木) 20:47:16.85 ID:4WIH+Ytl
 
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
http://www.apamanshop.com/membersite/27009206/images/kamo.jpg
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
 
このように現在まで6通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
 
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に11通のメールを頂戴しているか不明なところであります。
 
 http://s-at-e.net/scurl/BRS.html
 http://s-at-e.net/scurl/BAYONETTA.html
 http://s-at-e.net/scurl/JOURNEY.html
 
http://s-at-e.net/scurl/kabetokyojinto.html
 
 http://s-at-e.net/scurl/2012.html
 http://s-at-e.net/scurl/Prometheus.html
 http://s-at-e.net/scurl/Avatar.html
 
大阪府八尾市上之島町南 4-11 クリスタル通り2番館203
に入居の引きこもりニートから長期にわたる執拗な嫌がらせを受けています。
この入居者かその家族、親類などについてご存知の方はお知らせ下さい。
hnps203@gmail.com

834 :名無しさん@編集中:2015/01/04(日) 19:05:18.11 ID:fYrCCA/b
或るプログラマの一生 ≫ [UtVideo] バージョン 15.0.0
ttp://umezawa.dyndns.info/wordpress/?p=5281

835 :名無しさん@編集中:2015/01/11(日) 02:56:58.48 ID:AIehL1mK
Lagarith1.3.27に、バグらしき挙動があったので報告。

  「x64の場合だけ、YV12→RGB変換をBT.709で行ってしまう。(RGB→YV12変換はBT.601)」

という変な動きになってしまっているようです。
本来LagarithのYUV⇔RGB変換はBT.601のはずですが、何故かここだけBT.709に・・・。
そのため、VegasPro12やPremiereProCCなど、「RGBで読み込みを行う64bitアプリ」で、
「YV12設定でエンコしたLagarithのAVI」を読み込むと、色が変わってしまうことがあるので注意が必要。

ソースも少し見てみましたが、mmx_YUY2toRGB24(32)のbool rec709についての
コメントとかもおかしいように見えますし、なんでこんなことになってんだろ・・・。流用ミス?

836 :名無しさん@編集中:2015/04/03(金) 17:37:27.57 ID:jfcOhXgC
今更だけど2月末にMagicYUV1.1が出てLinuxやMacOSに対応してたようなのでなんとなく報告。
  ttp://magicyuv.com/index.php/news

837 :名無しさん@編集中:2015/08/27(木) 11:05:31.30 ID:fgpgkou0
8/24にMagicYUV 1.2が出てた。
サイトから落とせるTrial版はデコード時にロゴ付加。
フル版はgumroadでの販売になったけど、値付け自由なので0ドル入手可。
寄付歓迎ってやつだな。

838 :名無しさん@編集中:2015/09/08(火) 06:35:42.42 ID:TXV9Qrad
露骨な宣伝はやめてほしいんやなw

839 :名無しさん@編集中:2015/09/16(水) 13:28:19.04 ID:unICLC0F
UtVideoでインタレ解除せずにインタレ動画をエンコする際の事なんだけど、

「インターレース映像としてエンコード」をチェックつけた場合と付けない場合でファイルサイズも画質も全然違いがワカランのやけど、何が違うの?

840 :名無しさん@編集中:2015/09/16(水) 13:36:24.31 ID:unICLC0F
ごめんなさい事故解決しました。無視して下さい

841 :名無しさん@編集中:2015/09/16(水) 14:01:19.83 ID:KqwLuv+L
理由はなんだったの?

842 :名無しさん@編集中:2015/09/17(木) 08:49:21.61 ID:ZpMN+Thf
ffdshowで可逆圧縮コーデックを使えるようにする方法ってありますか??

843 :名無しさん@編集中:2015/09/17(木) 18:11:24.14 ID:iDrgptJS
FFV1とHuffyuvが可逆だけど、今更使う意味ないんでおとなしくUtVideoを使ったほうがいい。

844 :名無しさん@編集中:2015/09/19(土) 09:01:05.44 ID:baVkf3ig
>>843
ffdshowのVFWコーデックとして(?)ut videoコーデックとか他の可逆圧縮コーデックを追加する方法ってないの?

そういう事が出来るのか知りたいだけなんだけど(やりたいわけじゃない)

845 :名無しさん@編集中:2015/09/19(土) 09:17:26.49 ID:BqpOr9xu
無い

846 :名無しさん@編集中:2015/09/20(日) 18:28:23.19 ID:G9+P5njL
結局可逆圧縮の中で一番良いのってなんなん?

AMV4が攻守最強

次点でutvideo

圧縮最強はmlc

速度最強はAMV4

って感じで合ってる?

847 :名無しさん@編集中:2015/09/20(日) 23:36:14.53 ID:fDkCs4mC
>>846
あまラボ ビデオコーデック・ベンチマーク2014夏
ttp://amalabo.blog35.fc2.com/blog-entry-269.html

以下は個人的見解。

AMV4(キャプチャ向き)
  ×有料(税込2808円)
  ○速度・負荷の軽さ・圧縮率が良い
  ×YUY2入力でエンコードしたものは多くの動画編集ソフトで読み込めないという弱点あり

UtVideo(キャプチャ向き)
  ○無料
  △速度・負荷の軽さ・圧縮率はAMV4より劣る

Lagarith(中間素材保存向き)
  ○無料
  ○圧縮率は基本的にAMV4より優れている
  △速度・負荷の軽さはUtVideoより劣る

x264vfw(中間素材保存向き)
  ○無料
  ○圧縮率は基本的にAMV4より良く、更にLagarithより良くなることもある(mediumプリセットの場合)
  △速度・負荷の軽さはLagarithより劣る(mediumプリセットの場合)

その他
  バランス等を考えると使う気になるようなメリットが無いのでどうでもいい。

848 :名無しさん@編集中:2015/09/29(火) 19:23:25.02 ID:k5xzZWCt
UtVideoの自ビルドに挑戦してみました
ビルドオプションのasmなのですが
x86はintel、x64はamd
x86は32bit、x64は64bit
どちらになるのでしょうか?

849 :名無しさん@編集中:2015/09/30(水) 13:33:32.61 ID:ZWxyZawT
確かにわかりにくいね

850 :名無しさん@編集中:2015/10/01(木) 18:28:08.43 ID:OQwQt2mf
ffmpegのutvideoでマルチスレッド指定してエンコしてみたけど
>>847のリンク先みたいに速度が上がらない
どんなオプションつければいいの?

851 :名無しさん@編集中:2015/10/01(木) 19:58:51.68 ID:RYzAyVES
基本Lagarithでええと思うよ

852 :名無しさん@編集中:2015/10/02(金) 10:06:18.95 ID:y0SXsbh9
>>848
知らんけどアセンブラに話を限定しなければ下の使い方で上で使うことは無いと思うぞ

853 :名無しさん@編集中:2015/10/02(金) 15:58:47.08 ID:U5whg5tx
>>851
ffmpegでLagarithのエンコードはできるの?
こちらMac

854 :名無しさん@編集中:2015/10/02(金) 18:53:38.75 ID:WSJDZQ4R
bootcampで可能

855 :名無しさん@編集中:2015/10/02(金) 19:12:03.77 ID:U5whg5tx
ffmpegのソース見て使えそうなオプション試したけど速度に変化無しだった

試したオプション
-pred left, median, none
-threads 0 - 8
-slices 1 - 8
-coder vlc, ac, raw, rle, deflate

無理なのかなぁ

>>854
それは避けたい

856 :名無しさん@編集中:2015/10/03(土) 15:32:10.84 ID:T/JO4dGz
>>849
x86、x86_64にすればいいのにね
オレは自ビルドなんてできんけど

857 :名無しさん@編集中:2015/10/05(月) 16:52:44.05 ID:SZ7yUzKx
可逆圧縮コーデックって、AVI以外のコンテナだったら何がおすすめなの?

858 :名無しさん@編集中:2015/10/25(日) 23:28:33.78 ID:yz30y5Is
avs2aviのuvvideo出力で126〜128GBを超えた辺り?でエラーになる不具合ってどうなった?

859 : ◆Ww2pZaKGaW0T :2015/10/25(日) 23:51:47.16 ID:HCeCarUS
最初に無があった
無は有を生んだ
これが全ての真理

860 :名無しさん@編集中:2015/12/23(水) 10:45:28.96 ID:XJmynZAn
Zip Motion Blocks Videoってめっちゃ縮むな

861 :名無しさん@編集中:2015/12/23(水) 23:03:49.10 ID:LGzbI6J1
>>860
Mot kwsk

862 :名無しさん@編集中:2015/12/24(木) 13:53:12.99 ID:ZspE/jzI
デスクトップのキャプチャ向けで動きの多い動画は向いてなさそう
http://wiki.multimedia.cx/?titl=DosBox_Capture_Codec

863 :名無しさん@編集中:2016/01/09(土) 21:44:01.51 ID:U7UfUgSW
Lagarithで真ピンク(#FF00FF)の画像を圧縮すると、
圧縮後の動画の色が別の色(#FF00FE)になってる。
これって >>835 の現象が原因?

864 :名無しさん@編集中:2016/01/09(土) 22:31:53.32 ID:EogVPU/p
>>863
違う。RGBソースをYUVで圧縮したことによるただの誤差。
RGBで正確な色を残したいなら、RGBで入力してRGBで圧縮する必要がある。

ちなみに>>835が原因なら#FF00FFは#FF27FFくらいになるはず。

865 :名無しさん@編集中:2016/01/09(土) 23:07:31.43 ID:U7UfUgSW
>>864
Lagarithの設定でModeをRGBにしてるのになんで色変わるのかなぁって思った。
Aviutlの入力コーデックのところに別に設定あったんですね。
ありがとです。

866 :名無しさん@編集中:2016/01/29(金) 20:34:32.50 ID:gvLRo74a
可逆圧縮コーデックをMP4コンテナでエンコ出来るソフトってないんでしょうか?

867 :名無しさん@編集中:2016/01/29(金) 20:44:30.20 ID:z2YemZz2
x264を可逆設定で使えばいいだろ

868 :名無しさん@編集中:2016/02/12(金) 07:54:22.06 ID:RsWIrJ9r
AMV4でSSE4.1でゲーム実況動画やってみたけど抜群に軽い 
CPUはFX8350を4,7Ghz エンコはTMPGEnc6
圧縮は気にしないからDR2でやってる

869 :名無しさん@編集中:2016/02/28(日) 17:55:15.20 ID:NTlMxFBe
ffmegで可逆と言われているもののssimをffmpegで調べたら、1にならなかったんですけど、どうして?

870 :名無しさん@編集中:2016/02/28(日) 18:44:38.41 ID:nr93yGhh
>>869
何をどのようにエンコしたのか知らんけど、例えば
  「RGBソースをYUV4:2:0可逆コーデックで圧縮」
みたいなことをすればRGB->YUV変換が入るから可逆にはならんぞ。

871 :名無しさん@編集中:2016/02/28(日) 20:23:57.46 ID:NTlMxFBe
>>870
ソースはYUV4:2:0です。
ffmpegでutvideo、ffvhuff、x264、x265でエンコしてみました。

872 :名無しさん@編集中:2016/02/28(日) 21:45:22.06 ID:u6vYqPAQ
http://www29.atwiki.jp/lossless/pages/11.html
で紹介されている712のhuffyuvをWindows7(64bit)にインストールして
aviutlでエンコードしてみた。

シングルスレッド版とマルチスレッド版の二つエンコードしてみたんだけど
最新のVLC Mediaで再生できないファイルができあがった。

完全にはhuffyuvじゃないってこと?

873 :名無しさん@編集中:2016/02/28(日) 22:18:36.38 ID:nr93yGhh
>>871
普通にSSIM=1になったよ。
よくわからんけど音声トラックがあると1にならなかったので、
-anつけて映像だけエンコしてからSSIM比較したらうまくいった。

>>872
Huffyuv_mtはFOURCCも勝手に変えてるんだからVLCで再生できるわけがない。

874 :名無しさん@編集中:2016/02/28(日) 23:44:30.32 ID:u6vYqPAQ
>>873
> Huffyuv_mtはFOURCCも勝手に変えてるんだからVLCで再生できるわけがない。

そうだったのね
Windows7の64bit版にインストールするならどのhuffyuvがおすすめ?

875 :名無しさん@編集中:2016/02/28(日) 23:57:43.32 ID:nr93yGhh
>>874
Huffyuvは既に使う意味が無いので、UtVideoを使うといいよ。

876 :名無しさん@編集中:2016/02/29(月) 00:08:29.37 ID:+X96pHpW
>>874
俺もUtVIdeoを勧める
VLCで読めるかどうかは不明

877 :名無しさん@編集中:2016/02/29(月) 00:23:09.23 ID:Bjz0v8yc
Utはffmpegでのエンコードもデコードも可能だから
それ絡みのプレイヤーやエンコーダーなら問題なく扱えるはずだぞ

878 :名無しさん@編集中:2016/02/29(月) 00:45:16.34 ID:bzOAaO7b
VLC2.2.2で試してみたけど、ULH2とULH0は再生できなかった。
ULRG・ULY2・ULY0は再生できた。

879 :名無しさん@編集中:2016/02/29(月) 01:08:36.94 ID:Bjz0v8yc
>>878
VLC2.2.2で試してみたが確かに再生できないな
mpc-beやlavなら再生できるんだがなあ…うーん、何がダメなんだろう?

880 :名無しさん@編集中:2016/02/29(月) 11:31:43.65 ID:pIgUhdS+
>>873
d
あとffmpegでrawもしくはmkvに出力するとダメだった。-an付けても。
avi、mov、mp4は大丈夫だった。

881 :名無しさん@編集中:2016/02/29(月) 20:01:52.41 ID:Cnt3sqci
>>875
>>876
>>877
UtVideoコーデックってデフォ状態のffmpegで読み書きできるの?!
いつの間にそんな最強コーデックになってたんや・・・

882 :名無しさん@編集中:2016/02/29(月) 21:59:20.63 ID:+X96pHpW
かなり前からだよ
オープンソースだし不思議ではない

272 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)