映像可逆圧縮総合スレ Part3

1 ：名無しさん＠編集中：2009/07/10(金) 23:30:30 ID:fN2fpFAc.net

映像可逆圧縮関連総合スレです

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/

688 ：名無しさん＠編集中：2012/10/28(日) 14:36:57.02 ID:7DW0yYJK.net

x264使っとけよ

689 ：名無しさん＠編集中：2012/10/28(日) 18:32:17.54 ID:TNb/13Hp.net

UTVideoの特徴は編集しやすいって事でしょ
そのためにはH264ではだめなんだよ

690 ：名無しさん＠編集中：2012/10/28(日) 18:50:42.70 ID:AHg08j50.net

編集段階なのに不可逆圧縮使うの？アホの子なの？

691 ：名無しさん＠編集中：2012/10/28(日) 19:04:29.09 ID:RgklqyrI.net

MJPEGとかじゃダメなんか

692 ：名無しさん＠編集中：2012/10/28(日) 19:33:56.43 ID:eEQ3IqSB.net

編集しにくいのはP/Bフレーム使ってるからでしょ
AVC-IntraみたいにIDRだけにすればシークもサクサクだし
無劣化切り貼りも楽勝だよ

693 ：名無しさん＠編集中：2012/10/28(日) 21:43:24.13 ID:9bLpTjhF.net

Iフレームだけのエンコはどうやるの？

694 ：名無しさん＠編集中：2012/10/28(日) 23:37:51.29 ID:eEQ3IqSB.net

--keyint 1

695 ：名無しさん＠編集中：2012/11/24(土) 23:01:42.57 ID:gSRU6CNB.net

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/.net

amvかutvideo使っとけ この2つに比べるとhuffyuvは遅いし縮まらん

697 ：名無しさん＠編集中：2012/11/24(土) 23:29:34.59 ID:gSRU6CNB.net

>>696
レス�d

ut videoはいいとして、AMVに可逆圧縮なんてあったっけ？
あ、あった気がするな・・・
なにげにhuffyuvより優秀だったのね・・・

698 ：名無しさん＠編集中：2012/11/25(日) 01:59:55.96 ID:HUqX/NcV.net

いやamvは可逆の圧縮効率的にも速度的にもここ何年もの間ずっと最強(圧縮効率はx264が圧倒的だけど異常なまでのデコード速度とエンコード時の重さ的にキャプチャではほぼ使われないあとlibxじゃ420しかだせないぽい)
問題はamvはロゴ無しなら有料ってこと。ストレージがデカイならutでいい
ただRGBで撮るならamvでもほぼ完璧なロゴ透過が出来るので(ry

699 ：名無しさん＠編集中：2012/12/25(火) 22:32:22.60 ID:4+Xi4jS+.net

ここの人ならカメラ板よりも詳しそうなので、質問します。
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.net

AVCHDは28Mbpsが上限じゃなかったっけ？
まあ60iでも28Mbasじゃ全く足りないんだけどねｗ

701 ：名無しさん＠編集中：2012/12/26(水) 02:53:52.12 ID:UX1UTdmF.net

可逆のスレで非可逆の話持ってくんなクズ

702 ：名無しさん＠編集中：2012/12/26(水) 05:04:27.92 ID:TkCeVOu7.net

くーずくーず

703 ：名無しさん＠編集中：2013/01/04(金) 22:42:11.67 ID:WISoC4Ry.net

UtVideo使ってるんだけど、メディアプレイヤーで再生すると
bt709で再生されてるみたいなんだけど
もとはbt601みたいだから、色空間の情報が入ってないのかな？

704 ：名無しさん＠編集中：2013/01/07(月) 14:17:47.92 ID:JzLQnXQQ.net

それはお前がBt.601のソースをBt.709に色空間変換してエンコしたからだろ。

705 ：名無しさん＠編集中：2013/01/08(火) 00:00:51.61 ID:GxO/Bz8A.net

ソースはRGBだな
自分とこの環境では、色空間未指定だとbt709で再生されるようだ

706 ：名無しさん＠編集中：2013/01/08(火) 09:53:18.00 ID:Ja32Rxsv.net

だからｗｗｗお前はｗｗｗ

707 ：名無しさん＠編集中：2013/01/21(月) 02:04:11.78 ID:lan2Ido8.net

TSを中間ファイルとして圧縮するとき可逆圧縮ならLagarithかhuffyuv使ってれば色空間考えなくていいよね？
あと、40分の動画を処理するのに40分かかるのに4本同時でも計1時間というのはどういうこっちゃい。
ディスクIOもCPU使用率も全然飽和してない。

708 ：名無しさん＠編集中：2013/01/21(月) 06:41:51.76 ID:2HD4a5p8.net

>>707
YV12で圧縮できたらなんでもいいけど、huffyuvはどうだろう。

709 ：名無しさん＠編集中：2013/01/21(月) 13:25:35.93 ID:t/9KH83+.net

>>707
ts→Lagarithかhuffyuv　の時にどのようなソフト使ってるの？

710 ：名無しさん＠編集中：2013/01/21(月) 15:37:01.70 ID:k5qCC194.net

どちらも色空間考えずに使えば設定ミスでRGBに変換されてもおかしくない

711 ：名無しさん＠編集中：2013/01/21(月) 17:06:00.08 ID:noOkv13K.net

>>707
Vista/7でWMV9をインスコしてしまうとそうなる。
確かアンインストでも戻らなかった気がする。

712 ：名無しさん＠編集中：2013/01/21(月) 17:08:14.41 ID:noOkv13K.net

ごめん7だけだわ。
ついでにWMVじゃなくてWMEだわ。

713 ：名無しさん＠編集中：2013/01/21(月) 17:24:49.70 ID:6rg9h042.net

UtVideo最強伝説

714 ：名無しさん＠編集中：2013/01/21(月) 19:52:04.46 ID:lan2Ido8.net

>>709
TMPGEnc Video Mastering Works 5使ってる。

715 ：707：2013/01/21(月) 20:19:19.39 ID:lan2Ido8.net

>>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.net

そもそもTMPGEnc Video Mastering Works 5は全部一度RGBに変換しちゃうみたいだ。
これ使ってる限り二回色変換入るから。。。ｵﾜﾀ
カット編集の使い勝手がものすごくいいのに使えないじゃんか！

717 ：名無しさん＠編集中：2013/01/22(火) 09:12:53.14 ID:uIUeTUNH.net

>>716
avs + VirtualDub(Fast recompress)等を使えば変換を回避できる。

718 ：名無しさん＠編集中：2013/01/22(火) 12:20:29.41 ID:JKP7TFmm.net

Utでbt709出力できるようになるといいな

719 ：名無しさん＠編集中：2013/01/22(火) 12:39:17.02 ID:8/opT7Kg.net

Utの作者はレスポンス早いから
要望出せば対応してくれるでしょ

720 ：名無しさん＠編集中：2013/01/22(火) 12:51:43.46 ID:qxQcHZLx.net

>>718
可逆圧縮＝入力されたものを無劣化で出力するってことだから
色空間の変換はフロントエンドの仕事でしょ

721 ：名無しさん＠編集中：2013/01/22(火) 16:06:10.69 ID:isDmieSh.net

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.net

Zip Motion Blocks Videoすげえ縮むんだが

723 ：名無しさん＠編集中：2013/03/25(月) 17:55:19.62 ID:j37ZXLrG.net

500MBくらいのULY2で圧縮した動画を何の編集もせずに
再圧縮無しで出力したら3KBくらい減ってるんだけどこれ何の差なの？
一応スレ出てる色空間だのなんだのはちゃんとしてる筈なんだけど

724 ：名無しさん＠編集中：2013/03/25(月) 21:21:13.46 ID:++/lE1eG.net

チャンクのアライメントの違いかもしれない？

725 ：名無しさん＠編集中：2013/03/27(水) 17:59:45.92 ID:Tgeur7RJ.net

元の動画はアマレコTV+ULY2（デコード速度優先）で書きだしたファイルなんだけど
AviUtl（再圧縮無し）を通す事によってアライメントが変わってごく僅かにサイズが減ったって事？
動画の可逆性は維持されてると考えて良いのかな？500MB対して3KBしか変わってないし

726 ：名無しさん＠編集中：2013/03/28(木) 20:34:57.16 ID:QADHkfR8.net

>>725
VirtualDubのHexeditorか何かを使ってビデオチャンクのサイズに差が無いのを確認すればいいんじゃない？
サイズが変わってなければアプリによってオーディオのチャンクサイズやアライメント・パディング等が異なってるのかも

727 ：名無しさん＠編集中：2013/03/28(木) 23:01:41.13 ID:rG5g5EfM.net

初めて使ったから見方がよくわからんけど
指摘の通り
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.net

映像は[00dc: 数字]の数字部分（dcやdbが映像を指してる）が一致してるなら再圧縮無しで処理できてると思うよ。
音声（[01wb: 数字]など）はPCMだったら再圧縮無しでもアプリによってチャンクのサイズが
変わったりするんじゃないかな。
音声の合計は映像の長さに合わせて無音データとか付け加えてるかも。

729 ：名無しさん＠編集中：2013/04/02(火) 21:07:18.05 ID:/2myLRrR.net

分離させたwavのwaveformdataって部分のサイズが違ってるのはなんか弄られてるんだよね？
だとするとやっぱり音声が可逆になってない気がする
aviutlだけじゃなくてffmpegとかVirtualDubも試したけど
Hexeditorで調べた元の動画の音声部分（01wb）と
分離したwav（waveformdata）のサイズが一致するのは
ffmpegで分離したwavだけで
aviutlとVirtualDubで分離したwavはサイズが減ってるんだけど

730 ：名無しさん＠編集中：2013/04/02(火) 21:54:05.78 ID:TtvHn58P.net

PCMだったら気にしなくても大丈夫だと思うよ。
映像と音声の長さが異なると結合した時にずれるから長さを整えてるだけじゃないのかな。

731 ：名無しさん＠編集中：2013/04/02(火) 22:01:11.26 ID:FCo9vYJP.net

音声でPCMなら可逆どころか無圧縮じゃないですか

732 ：名無しさん＠編集中：2013/04/02(火) 23:30:57.94 ID:BWn/yxyH.net

音声のキャプチャ16bit44.1KHzが限界なのどうにかなんないかな

733 ：名無しさん＠編集中：2013/04/02(火) 23:50:08.31 ID:/2myLRrR.net

正確に分離できてると思われるffmpegの出力したwavファイルを
バイナリエディタで中覗いて比較したけど
やっぱり極々僅かな末尾の部分（無音部分かどうかはわからんがヘッダじゃない正味の音声部分）を削ってるみたい
>>723の最初に試したファイルだと
動画全体475MB、内音声2134KB、削られた部分4B
本番用の180GBのファイルでも試してみたが
動画全体180GB、内音声1.30GB、削られた部分1.36KB
って感じ
末尾は元々編集でカットする部分だし
どの部分に差異があるのかわからん気持ち悪さは解消されたので
これで納得しときます。お騒がせしてすいませんでした

734 ：名無しさん＠編集中：2013/04/03(水) 01:59:00.49 ID:PKcW6h+I.net

むしろffmpegが無理矢理長さ合わせる為に無音部分付け足してる可能性

735 ：名無しさん＠編集中：2013/04/03(水) 02:39:45.90 ID:G5fSHqNv.net

いやそれはないと思う
>>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.net

比較したいならコンテナに入れずrawデータで出力しろ
ファイルサイズが違おうが最終出力が一致すればそれは可逆だ

737 ：名無しさん＠編集中：2013/05/27(月) 17:04:12.77 ID:f39LhD3Q.net

Ut Videoで一番画質がきれいかつ、データ量を多く圧縮できる設定が
分かる方はいらっしゃいますか？

738 ：名無しさん＠編集中：2013/05/27(月) 17:12:11.10 ID:f39LhD3Q.net

通常は、「Ut video codec YUV42 (ULY0)VCM x86」というものを選んで
設定をデフォルトのままで書き出しをしています。

739 ：名無しさん＠編集中：2013/05/27(月) 18:06:03.11 ID:BNsyyHO0.net

"可"逆圧縮だから色空間さえ間違えなければ劣化なし

740 ：名無しさん＠編集中：2013/05/27(月) 23:22:22.76 ID:vFpPH1/S.net

これらのコーデックを使用してゲームを作った場合
プレイヤーもこのコーデックを入れないとプレイできませんか？

741 ：名無しさん＠編集中：2013/05/27(月) 23:28:32.81 ID:jxvLHhlO.net

コーデックってそういうもんだ
同梱すればいいんでないの
ライセンス的にどうなのかは知らんが、リンクしなければ単なる再配布になるんじゃないのかね
知らんからちゃんと確認してくれよ

742 ：名無しさん＠編集中：2013/05/27(月) 23:39:27.42 ID:BNsyyHO0.net

>>740
どんなゲームかしらんけど普通は不可逆圧縮のデータを使うものでは？(容量も無駄にでかいし)
25GBのBDをムービーで埋め尽くしたいならアリだろうけど

743 ：名無しさん＠編集中：2013/05/28(火) 00:02:13.97 ID:EMzB99hO.net

ゲームのムービーに可逆圧縮使うとか正気かよ

744 ：名無しさん＠編集中：2013/05/28(火) 00:12:10.40 ID:EwiwJMI+.net

>>740
記憶媒体にアクセスするコストはタダじゃあないんだぜ……？

745 ：740：2013/05/28(火) 14:08:41.82 ID:87iAP3Hv.net

え！？そうなんですか？
AVIの圧縮は可逆がいいと聞きまして
それで全部レンダリングしてしまいました(´；ω；`)ｳｩｩ
不可逆ならXvidやh264とかですかね？　
どれがいいのかわからず当初はh264でやってました…
不可逆ならコーデックをそれぞれインストールする必要はないんですかね？
スレチなので申し訳ないのですが、それだけ教えていただけるとありがたいです…

746 ：名無しさん＠編集中：2013/05/28(火) 14:44:51.02 ID:EMzB99hO.net

>>745
この板でスレ探して質問しろ

ゲ製作技術
http://toro.2ch.net/gamedev/

747 ：名無しさん＠編集中：2013/05/28(火) 15:40:02.13 ID:LJtzEdEo.net

わざわざゲームの映像に可逆を使うってのもスゲーな。
縮むにしても限度があるだろうし、無駄にデカくなるだけだろ。

748 ：名無しさん＠編集中：2013/05/28(火) 23:20:55.74 ID:EwiwJMI+.net

>>745
まあ確かに、映像編集する際の中間形式には可逆形式が最適(というか一択)だ
ただ、どうしてもファイルサイズが大きくなる都合上、HDDの容量も食うし、読み込みも遅い
だから、狭いディスクに収めなきゃならない時(例：DVD)とか、
狭いネット回線に流さなきゃならない時(例：動画投稿サイト)とかには向いていないのは分かるな？
で、ゲームでの話だが、ネット回線程ではないにせよ、ぶっちゃけHDDからの読み込みは遅い
(不等号で書けば、CD・DVD＞＞HDD＞＞メインメモリ＞キャッシュメモリの順で読み込み時間が掛かる)
つまり、ゲームのムービーを全部可逆でやってたらロード時間が鬱陶しい上、プレイヤー側としては
高画質の有り難みは分かりづらいことに……(MPEGはなかなか優秀な圧縮形式だもんね、仕方ないね)

749 ：名無しさん＠編集中：2013/06/01(土) 16:50:09.77 ID:d9QERt2K.net

配布して他人に見せる用途ならデフォルトで必ず再生出来るWMVでいんじゃねえの　これならXP使ってる奴でもデフォで見れる
想像以上に情弱が多いからH264でエンコして手渡すと大抵「映像が映らなかった」で終わる

750 ：名無しさん＠編集中：2013/06/02(日) 00:31:52.16 ID:zasIXNfo.net

そうそう、WMVは未だに根強い需要があるんだよなぁ。
俺も自作動画販売してるんだけど、動画形式はホント頭の痛い問題なんだよ。
コーデック？なにそれ？ってのが普通に居るんで、XPでデフォで再生出来るってのはスゲー大事。
ただMSがもうやる気ねーからなぁ。

751 ：名無しさん＠編集中：2013/06/02(日) 00:39:28.44 ID:uOAr7OTc.net

WMVは相手がMacだと迷惑かける
今はmp4が一番ではないかな

752 ：名無しさん＠編集中：2013/06/02(日) 10:49:43.16 ID:vwYJ+jJ7.net

UtVideo地味に更新されてるから確認してみれ

753 ：名無しさん＠編集中：2013/06/05(水) 08:18:00.70 ID:ENPqz4jj.net

>>751
ゲーム用途と書いてあるのだから，狙ったＯＳ以外の事は考えなくていいのでは．

754 ：名無しさん＠編集中：2013/06/05(水) 10:33:48.47 ID:uDe9lRYg.net

ゲーム用途の話はもう終わってるだろ？

755 ：名無しさん＠編集中：2013/06/10(月) 21:39:05.66 ID:E9p7Vq6p.net

utvideoのULY0とULH0の違いってコーデックIDだけで中の映像データは同じって理解でいいのかしら？

756 ：名無しさん＠編集中：2013/06/10(月) 21:42:42.45 ID:IHlRJJ7s.net

色空間が違うよ
まぁ動画オタじゃなきゃ説明なしでわけわからんよな

757 ：名無しさん＠編集中：2013/06/10(月) 21:49:25.37 ID:E9p7Vq6p.net

その色空間の違いが映像データの違いとして出てくるのかよくわからんのよね
ULY0とULH0で出してみてx264でエンコしたら全く同じデータになったから

758 ：名無しさん＠編集中：2013/06/11(火) 12:03:07.74 ID:/8SBH9LO.net

>>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.net

圧縮時で言うと、例えば
　　「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.net

>>759
えくせれんと！

761 ：名無しさん＠編集中：2013/07/07(日) NY:AN:NY.AN ID:QgJSoOQb.net

>>759
今までそれが対応せずutvideo使われた動画は劣化している
ってことになるから作られた動画には完全性が削がれちゃってるね

762 ：名無しさん＠編集中：2013/07/07(日) NY:AN:NY.AN ID:7zPCmcCu.net

>>761
最終的にはYV12とかでエンコするんだし
気にしなくておｋ

763 ：名無しさん＠編集中：2013/07/08(月) NY:AN:NY.AN ID:85d3HWRW.net

よくわからんからBT.601はSDで、それ以上はBT.709って適当に覚えたけど
4k8kとかにもBT.709でいいんだろうか
と未来の自分を心配してみる

764 ：名無しさん＠編集中：2013/07/08(月) NY:AN:NY.AN ID:IrvABD48.net

4k8kはBT.1361だから、まあBT.709と同じようなもんだな
ただし最低10bitだけど

765 ：名無しさん＠編集中：2013/07/08(月) NY:AN:NY.AN ID:J9NQ/QmY.net

>>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.net

YUV4:2:0を4:4:4と効率良く書き換える方法ってないのかな

767 ：名無しさん＠編集中：2013/07/11(木) NY:AN:NY.AN ID:IUqhyKLE.net

Lagarith使用中のCPU負荷が１０％くらいにしかなりません
マルチスレッド使用にチェックを入れてエンコしてるのですがこんなものなのでしょうか？

768 ：名無しさん＠編集中：2013/07/13(土) NY:AN:NY.AN ID:fIGBWDUM.net

>>766
なにがしたいのかよくわからんのだが。

769 ：名無しさん＠編集中：2013/12/02(月) 15:46:47.31 ID:Azw/fWRW.net

圧縮率と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.net

avs2aviでUtVideo Codecのavi出力すると120GBくらいのところで処理が中断されちゃうんだけど…
これはUtVideoの問題かな？
それともavs2aviかAvisynth側の問題？
それかうちの環境に問題があるっておちだろうか

771 ：名無しさん＠編集中：2014/03/30(日) 15:27:38.22 ID:oxC05eNP.net

>>770
自分が "その事について行った思考" 等には一切触れないところからすると
処理が完了しなかったという時点で原因究明については即決他人に振ったわけだな。

そういうお前の根性に問題がある.

772 ：名無しさん＠編集中：2014/05/18(日) 16:59:09.86 ID:X8I1eEh7.net

保守

773 ：名無しさん＠編集中：2014/06/24(火) 10:02:57.07 ID:G4PLHdBp.net

結構使わせてもらっているUt Videoがいつの間にかv210に対応してたんだなぁ
うちのキャプチャデバイスに最適だ

774 ：名無しさん＠編集中：2014/06/24(火) 13:14:04.85 ID:eCs0BBvg.net

>>773
v210は何かいいことあるの？
というよりそもそも違いがよくわからないのだが。

775 ：名無しさん＠編集中：2014/06/29(日) 00:33:40.21 ID:NOLTPzIL.net

>>773
いまいち10bitでの処理のイメージが湧かないんだけど、
どういう環境(ボード・キャプチャソフト等)で、どういう風にUQY2を使ってるのだろう？

>>774
以前からあったULY2は8bit深度のYUV4:2:2だが、UQY2は10bit深度のYUV4:2:2。
YUVは輝度と色差の組み合わせで色を表すが、例えば8bitだと
輝度が0-255の256段階で表されるのに対し、10bitでは0-1023の1024段階で表される。
要するに10bitのほうが精密に色情報を保持できることになる。
ただ、元ソースから出力過程までをトータルで考えないと、10bitの精密さが生かせないこともある。

776 ：名無しさん＠編集中：2014/06/29(日) 00:42:21.73 ID:NOLTPzIL.net

つうかUtVideoのUQY2ってどういう風にしたら試せるんだろ？
入出力がv210だけみたいだからAviUtlでは使えないけど、
Avisynthとかをうまく使えばUQY2のAVIを作ったりできるん？
キャプチャでUQY2を使おうとしてる>>773はどうやって使ってるん？
10bitの実用って、まだよくわかっとらんねん（´・ω・｀）

777 ：名無しさん＠編集中：2014/06/29(日) 01:04:05.43 ID:OgDsyoiN.net

8bit、4:2:2の素材をデバンディングしてから10bit、4:2:2に格納して編集→エンコード
とかかな？
俺もよくわからん。
編集とかでクロマキーとかが入るんなら4:4:4一択だろうし。
編集時にどの程度のクオリティを求める場合なんだろ？

778 ：名無しさん＠編集中：2014/06/29(日) 02:31:52.25 ID:NOLTPzIL.net

UQY2の使い方を調べてたら、AMV4がリリースされてたことに気付いた。

　　インテル製CPUの“AVX2”に対応した高速動画コーデック「AMV4ビデオコーデック」
　　http://www.forest.impress.co.jp/docs/news/20140627_655554.html

作者のブログにベンチマークとか説明とかが色々書かれてるけど、
QSVよりCPU負荷が低いとか、何それ怖い的な性能向上がなされてる模様。

　　http://amalabo.blog35.fc2.com/

有償とはいえ面白そう。

あ、UQY2の使い方はまだよくわからないんで引き続き情報募集中。
キャプチャ環境もないんでフリーソフトでやれるやり方があれば教えてくれくれ。

779 ：名無しさん＠編集中：2014/06/29(日) 21:29:06.53 ID:4FiydeQo.net

>>776,>>778ですが、UtVideoの作者さんのブログでVirtualDubでv210入出力ができることを知り、
試してみたところ、[Video→Color Depth] で[4:2:2 YCbCr 10-bit (v210)]を選ぶことで
とりあえずUQY2での書き出し、読み込みができました。あまり意味はありませんがご報告。

v210での展開のみしかサポートしていないせいだと思うけど、AviUtlに読み込ませるとエラー吐いて落ちる。
PremiereProなんかは無圧縮v210の入出力ができるっぽいけど、UQY2の読み込みはできるんだろうか。
書き出し時はコーデックに渡されるのがRGBだからダメっぽいと作者ブログにあったけど・・・。
やっぱりキャプチャソフトや編集ソフトでの10bit入出力対応状況がよくわからないや。

780 ：名無しさん＠編集中：2014/06/30(月) 01:06:55.56 ID:wU+GT1lW.net

キャプチャデバイスならUSB3.0版のIntensityが10bitキャプチャに対応してたと思う
ゲーム映像ソース等なら8bitの422よりは色の再現性良いんじゃないかな

でも現状の編集ソフトでの利便性考えると録画変換の時点で444にした方が楽な部分多いか

781 ：名無しさん＠編集中：2014/07/07(月) 12:23:11.41 ID:zm/1emx0.net

AMV4ぱねえｗｗｗｗｗｗｗｗｗ
Frapsで録画した動画をエンコしたら1/8になった
しかも軽い

782 ：名無しさん＠編集中：2014/07/07(月) 19:32:41.11 ID:cNnnzFOX.net

>>781
よく知らんけどFrapsのコーデックって非可逆じゃなかったっけ？そんなに縮むものか？
RGB可逆でも録画できるみたいだから、そっちで録画してたやつかな？

AMV4は不具合があってv4.0.2で修正されてるので、一度アンインストールしてから
インストールしなおしたほうがいいみたいだよ。
　　ttp://amalabo.blog35.fc2.com/blog-entry-275.html

783 ：名無しさん＠編集中：2014/07/07(月) 23:29:42.88 ID:XvheWVIt.net

AMV4作者がやってる可逆圧縮コーデック比較ベンチ見たら
UtVideoの8スレッド動作も無料にしてはかなりいい性能叩きだすじゃん

784 ：名無しさん＠編集中：2014/07/08(火) 09:57:58.86 ID:7/8LlU2w.net

>>782
知らんけど時間軸でも圧縮すれば縮むんじゃね？
今のところ可逆は編集用途でしか使ってないからそんなのだったら俺には不要だが

785 ：名無しさん＠編集中：2014/07/08(火) 20:12:55.82 ID:TxE+0d77.net

あまラボ AMV2MTとAMV4の違い まとめ
ttp://amalabo.blog35.fc2.com/blog-entry-271.html

シングルスレッドで性能ぶっちぎってるのか・・・

AVX2.0対応じゃないけどそれでもデコード負荷はamv3やutと比較して低いね半分以下だ

786 ：名無しさん＠編集中：2014/07/08(火) 23:17:30.65 ID:uWcQ3C3a.net

frapsはエンコーダ選べれば良いのにねぇ
RGB可逆モード付けたのは良かったけど

787 ：名無しさん＠編集中：2014/07/12(土) 09:13:21.10 ID:DFtOLGUZ.net

FrapsはRGBYUV問わず可逆だクズ

788 ：名無しさん＠編集中：2014/07/12(土) 09:52:10.94 ID:ELqfjeLZ.net

いきなりキレてどしたー？