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

■ このスレッドは過去ログ倉庫に格納されています

YC伸張する？しない？総合ｽﾚｯﾄﾞ

1 ：slave：03/04/14 14:53: YC伸張はどんなとき必要か？
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://vmaker.tripod.co.jp/huffyuvs/convlist.html
566 ：名無しさん＠編集中：03/06/24 01:04: DirectX 8.1 YUV Color Space Fix
567 ：名無しさん＠編集中：03/06/26 23:22: >>566
どこの情報？
つーかなんの？？
568 ：名無しさん＠編集中：03/06/26 23:32: msyuv.dll
569 ：名無しさん＠編集中：03/06/26 23:37: fixということはそれ以前は伸張しないか俺スケールかだったのか・・・
570 ：名無しさん＠編集中：03/06/26 23:46: つまりはAviUtlでTV→PCスケール補正で最終保存するとまずいって事？

ノーチェックで保存が当たり前？
571 ：名無しさん＠編集中：03/06/27 00:33: だから、ソースによるって言ってるだろ。あほんだら
572 ：名無しさん＠編集中：03/06/27 01:37: >>569
DirectX8のmsyuv.dllは YUV→RGBをRGB16に変換する。
いわゆる msyuvの減色バグと言われてたやつだ。それのfix。
573 ：名無しさん＠編集中：03/06/27 13:05: >>571
TV→S端子経由→玄人志向SAA-7130→MJPEG
このｿｰｽの場合は？
574 ：名無しさん＠編集中：03/06/27 14:39: >>573
キャプチャする時、どの様に輝度等を調整してるか分からない。
取り込み方がRGB24かYUY2か分からない。
どのMJPEG codecを使ってるのか分からない。
AviutlのMJPEGのcodec設定がRGB24かYUY2か分からない。
575 ：名無しさん＠編集中：03/06/27 21:25: 自作板の自作HTPCスレでBT.601厨が火種をまいてますね。
576 ：名無しさん＠編集中：03/06/27 21:31: >>575
論破されたバカ?
577 ：名無しさん＠編集中：03/06/27 21:40: huffyuvで圧縮されたファイルが、yuvで記録されてるか、rgbで記録されてるか、
判別する方法無いですかね。
あとで、エンコードしようとして放置してたら、どんな設定で圧縮したか分からなく
なってしまいまして。
578 ：名無しさん＠編集中：03/06/27 22:03: AviUtl(0.86d)で読み込んで[その他]->[ファイルの情報]->ビデオ展開形式
でどを?
579 ：名無しさん＠編集中：03/06/27 22:04: ああそういうことあるね
でもhuffyuvならYUV→RGB時には伸張するから区別できるんじゃ？
580 ：名無しさん＠編集中：03/06/27 22:05: 0.86dって何だよヽ(`Д´)ﾉ　0.98dだよ
581 ：名無しさん＠編集中：03/06/27 22:36: >>579
伸張するから同じ画になって区別つかないんじゃ？
伸張しなけりゃぱっと見た目で区別できるよ。
582 ：名無しさん＠編集中：03/06/27 22:45: >>581
？
ストレート変換したものと見た目に違いがあるならYUVってそういう意味だったんだけど。
違わないならRGB
583 ：名無しさん＠編集中：03/06/27 22:55: >>566
ttp://www.doom9.org/Soft21/SupportUtils/dx81-yuv-fix.exe
これでそ？
584 ：名無しさん＠編集中：03/06/28 00:05: >>582
ストレート変換って？

Huffyuvでは、YUVとRGBで見た目に違いは無い(BT.601伸張変換されるから同じに見えて当然）
（レンジオーバーしてればサチュレートされるから違いは出るけどそれが見てわかるかどうか？）
>>578の言うようにAviUtlかAvisynthでチェックするか
585 ：名無しさん＠編集中：03/06/28 00:18: >>584
RGBはストレート展開じゃないの？
586 ：名無しさん＠編集中：03/06/28 00:30: >>585
試してみな。見て分かるか？

>>577
Huffyuvの設定ダイアログの一番下のチェックボックス "Enable console-window logging [use debugging]"
にチェックして、一旦終了。
再度起動して、問題のAVIを読み込めば、コンソールウィンドウが現れて、
　"DecompressQuery: input = HFYU, 16 bits, method 2, output = (null)"
みたいなのが表示される。
この場合は、入力 = Huffyuv 16bit(YUV) method=predict medianを示す。
RGBだったら、24bitになるはず。
587 ：名無しさん＠編集中：03/06/28 00:43: >>586
試してみたよ。見て分かったよ。
たぶん俺の言いたいことがちゃんと伝わってないだけ

１．動画編集ソフト（たとえばTMPGEnc）にそのままそのAVIを読み込ませてみる
２．そのAVIをConvTo.dllでストレートRGB展開するようにしたAVSを読み込ませてみる
３．１と２を見比べてみて変化があればYUV、なければRGB
588 ：名無しさん＠編集中：03/06/28 00:51: >>587
あほ。
それじゃAvisynth使えって言ってるじゃんか。
Avisynth使うなら、そんなことしなくたって簡単に判別つくわい。
Dubでavs読み込んで、file information見たって良いし、
ColorYUY2でdebug=3,5で見たって、YUY2のみしか使えないフィルタを追加したって分かる。
方法なんて他にもまだまだ幾つもあるぞ。
589 ：名無しさん＠編集中：03/06/28 01:03: あほって言われてもなあ
Avisynth使うなって言われてないし
一番簡単な判別の仕方を教えろとか言われてないし…
普段やってることだから全然手間じゃないんだよな俺の場合
TMPG使うから必ずストレート変換するのよ
590 ：名無しさん＠編集中：03/06/28 20:24: 教えてください。現在、LDからDVD-VIDEOへの変換を行っているのですが、
CANOPUS DigitalVideoRecorder+ふぬああにて、

UYVY&huffyuvS->Aviutl(YUY2展開無)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮無)->huffyuvS(ConvertYUY2)->CCEと、してるんですが、これで
あってるでしょうか。
591 ：名無しさん＠編集中：03/06/28 20:38: >>590
ふぬああの設定が不明
まぁUYVYならレンジは普通のYUVにしていると考えればあってることはあってる
勿論CCEはYUY2読み込みでしょ？
でもhuffyuv(S)キャプでCCEならAvisynthのほうが利口だよ
592 ：590：03/06/29 06:28: ふぬああでのレンジ設定って、UYVY以外にいじるところって有りますか？
色調整項目は、MTV系なので、基本的に自動で放置してますです。
あと、CCEはYUY2読み込みさせてます。

以前は、UYVY&huffyuvS->Aviutl(YUY2展開有)->Aviutl(スケール変換無、ノイズリダクション等)
->Aviutl(YUY2圧縮有)->huffyuvS(YUY2圧縮?)->CCE(YUY2読込?)と、していましたが、
こちらのスレでAviutlで展開圧縮すると、0-15,236-255が切り捨てられるってな話をみて、
590のやり方に変えてみました。
593 ：名無しさん＠編集中：03/06/29 07:46: せっかくAVIキャプ時は手動で調整できるんだから
できるなら手動で調整したほうがいいと思うけど
594 ：名無しさん＠編集中：03/06/29 11:39: >>590
このスレをくまなく見れば,そのやりかたではYUV->RGB->YUV処理が入ることがわかるはず
そしてYUV->RGB->YUVには色変換誤差が生じることも・・・
Avisynthにしなはれ
595 ：名無しさん＠編集中：03/06/29 14:31: >>592
LDからの取り込みで、ノイズリダクションって必要なの？
596 ：名無しさん＠編集中：03/06/29 15:04: >>595
ｱﾅﾛｸﾞなんだから当然かけてもいいでしょ
597 ：名無しさん＠編集中：03/06/29 15:42: アナログだからって意味分かんね
598 ：名無しさん＠編集中：03/06/29 15:53: >>597
どんなに設備・環境を整えてもｱﾅﾛｸﾞ波には必ずS/Nの問題が生じる
ﾉｲｽﾞからけっして逃げられないんだよ
599 ：名無しさん＠編集中：03/06/29 15:58: デジタルならいらないのか？
ああアニメの話か
600 ：いんやﾓｰｦﾀ：03/06/29 16:53: >>599
ﾃﾞｼﾞﾀﾙならば最終出力形式と好みの問題もあるが

ﾃﾞｼﾞﾀﾙｽﾄﾘｰﾑ記録の場合ｿｰｽにあるﾉｲｽﾞは送信側に既に存在するﾉｲｽﾞ
ｿｰｽ至上主義ならばﾃﾞｼﾞﾀﾙ記録はﾉｲｽﾞﾚｽということになる
つまりﾉｲｽﾞﾘﾀﾞｸｼｮﾝはいらない
最終出力時にﾃﾞｰﾀを圧縮しやすくするための画像処理はﾉｲｽﾞﾘﾀﾞｸｼｮﾝではなくﾌｨﾙﾀﾘﾝｸﾞでしょ
601 ：名無しさん＠編集中：03/06/29 17:21: >>600
ｿｰｽ至上主義ならばアナログでもLDからじゃﾉｲｽﾞﾘﾀﾞｸｼｮﾝするべきじゃないと思うが
602 ：名無しさん＠編集中：03/06/29 17:26: スレ違い。
603 ：名無しさん＠編集中：03/06/29 17:52: >>601
LDがないならVHSﾃﾞｯｷでもいいから同じｿｰｽを何度もｷｬﾌﾟってみればわかる
ﾄﾞｯﾄ妨害の出現ﾊﾟﾀｰﾝは毎回かわる
>>602
無理やりｽﾚの趣旨に近くしようとしてみるﾃｽﾄ
LDｷｬﾌﾟﾁｬｰ（正確にはｱﾅﾛｸﾞｷｬﾌﾟﾁｬｰ全般）時に載るﾉｲｽﾞをﾘﾀﾞｸｼｮﾝする一番いい方法は
何度もｷｬﾌﾟﾁｬｰし、それぞれをﾌﾞﾚﾝﾄﾞし、逆鼠算的にﾌﾞﾚﾝﾄﾞを繰り返すこと
この、内容は同一だがﾉｲｽﾞの出現ﾊﾟﾀｰﾝの異なる動画のﾌﾞﾚﾝﾄﾞを繰り返すというﾌｨﾙﾀは
Vmakerが作ってて公開してたんだがな
当人もLD->DVD時に有効と書いてたが、
いい加減ｻﾗっとﾌｶｰﾂしねーかな
Huffyuvsはどーでもいいから<ｽﾚ違い
604 ：名無しさん＠編集中：03/06/29 18:25: 毎回かわるから何
605 ：名無しさん＠編集中：03/06/29 18:58: 馬鹿はレスしなくていいよ。
606 ：名無しさん＠編集中：03/06/29 19:03: >>603
slave乙
607 ：slave：03/06/29 19:04: >>606
どういたしまして
608 ：名無しさん＠編集中：03/06/29 19:26: 何か語り口調が見たことあると思ったら、slaveってあの師匠だったのね
609 ：名無しさん＠編集中：03/06/29 21:25: >>603
2.52標準のMergeChroma / MergeLumaがその用途のためにある。
610 ：名無しさん＠編集中：03/06/29 23:20: >>609
お、ｸｽｺ！
611 ：名無しさん＠編集中：03/06/29 23:20: >>601
同じ意見。正直、ノイズリダクションしたら、映像が元ソースと
ちがってしまうのは嫌だ。
綺麗なソースがあるならそのままやったほうがいい。
安いＬＤプレイヤーなら仕方ないかもしれないけど。
612 ：AV機器ヲタ：03/06/29 23:29: >>611
綺麗なソースの定義は人それぞれ。
好きなようにやればよし。
画像も見ずに「LDソースだから綺麗」というのはおかしい。
それにLDプレイヤー（DVDも準ずる）は高ければソースにピュアなわけでもなく。
勿論安いLDプレイヤーがピュアなわけでもなし。
画像なしでは判断できないが、ひとついえることは、
LDプレイヤーのYC分離は総じて糞であり、
それどころかその多くはコンポジット出力しかもたない。
LDソースが綺麗なソースだとはとても思えない。
画像を見なければわからないけどね。
スレ違いなんでsage。
613 ：名無しさん＠編集中：03/06/30 02:50: >>609
他の使い道

mergechroma(c,blur(c,1.3))
mergechroma(c,fluxsmooth(c,7,7))
614 ：名無しさん＠編集中：03/06/30 11:59: >>612
LDプレイヤーがコンポジット出力しか持たないのが多いのはその機器の特性上別に問題でもなんでもない。
LDソースが綺麗だと思わないとは・・・・貴公はどんなソースが綺麗だと思うんだ？
あくまで、一般家庭の話ですよ。
615 ：名無しさん＠編集中：03/06/30 15:58: LD って、ｺﾝﾎﾟｼﾞｯﾄ信号（Y/C混合）で記録されているって
当然知ってて書いてるんだよねぇ？ちみたちは。

>>612
ｿｰｽにﾋﾟｭｱって話するなら、ｺﾝﾎﾟｼﾞｯﾄ出力だと思うが？
616 ：名無しさん＠編集中：03/06/30 18:51: LDPによってはコンポジット出力がY/C分離したあと再混合した信号を出力
していたりするけどな。
617 ：名無しさん＠編集中：03/06/30 19:45: >>615
すまん、ＬＤにＳ出力があるんだとばかり思ってた。
ごめんなさい。
618 ：名無しさん＠編集中：03/07/02 04:31: 何かどんどんスレ違いに・・。>590に一つ助言すると、LDプレイヤーの
S-端子は確かにあんま性能が良くないことが多い。これは>612の言っている
通りだ。だから、コンポジット出力をS-VIDEOデッキの３次元Y/C分離を
通してS出力すると綺麗になる場合もある。ただしこれは、>616の言う機能を
有したLDプレイヤーの場合、効果は薄い。
619 ：名無しさん＠編集中：03/07/02 11:49: >>592
Avisynth使えって言ってるだろが　ヽ(`Д´)ﾉ

LDをキャプチャーするスレ
http://pc.2ch.net/test/read.cgi/avi/1051885045/

こちらもよろしく
620 ：590：03/07/02 20:19: どうも皆さん助言を頂きありがとうございました。
えと、うちのプレイヤーですが、コンポジット出力は再混合したものが出力される
タイプなんで、Ｓ端子で繋いでいます。

で、16-235 <-> 0-255間違ってたら、あからさまなんで確認したかった訳なんですが、
0-15,236-255のためにAvisynthに乗り替えるのもめんどいんで、Aviutlでまったりと
逝きます。
621 ：名無しさん＠編集中：03/07/02 23:04: 本当に、Aviutlもいい加減サチュレートしないバージョンださないかなぁ
Avisynth使うの面倒くさくなってきた
622 ：名無しさん＠編集中：03/07/03 01:02: つーかこのスレに来たのってAvisynth使うの面倒だからだったんだけど
今やこっちの方がメンドイな
623 ：名無しさん＠編集中：03/07/03 06:55: AviUtlを貶しているけど、
AviUtlがRGBだったころ(0.97まで)、または、0.98でサチュレートしていることを
知る前までならみんな文句言わずに使ってたよな。
高画質で綺麗綺麗と言って。
サチュレートしているって聞いたとたん、AviUtl使うのは問題だよな、
っていうのはどういうものなのか。
624 ：名無しさん＠編集中：03/07/03 08:51: そうですね。痛いﾊｲｴﾝﾄﾞｵｰﾃﾞｨｵに現を抜かしてるﾔｼみたいで
ｱﾌｫくさいですよね。洩れは綺麗に見えるように自分が納得した
設定にしています。それに、苦労して何時間もかけてｴﾝｺｰﾄﾞした
ﾌｧｲﾙって、HDD の肥やしにしかなってないのが現状だしね～。
625 ：名無しさん＠編集中：03/07/03 08:53: 後で鑑賞するのが目的なはずなのに、いかに理論に沿って
ｿｰｽに忠実にｴﾝｺｰﾄﾞするかが目的になっちゃってる自分に
ふと気付くと、本当に無駄な時間の過ごし方してる。
626 ：名無しさん＠編集中：03/07/03 11:38: エンコードそのものに試行錯誤することが快感になってることに早く気付けよ
この板にはそんな人間がいくらでもいるから安心しろって
627 ：名無しさん＠編集中：03/07/03 12:06: 自己満足ｵﾅﾇｨ板（;´Д`）ﾊｧﾊｧ…
628 ：名無しさん＠編集中：03/07/03 18:29: >>624-625
slaveうぜえ
629 ：名無しさん＠編集中：03/07/03 20:56: Aviutlの98以降がｻﾁｭﾚｰﾄするのは本家BBSでもここのAviutlｽﾚでも
98発表当時問題になってる
「TVｽｹｰﾙとPCｽｹｰﾙつけるからいいでしょ」ってな返答をKENがして
「ちげーよ、色がｸﾛｯﾌﾟされるって言ってるんだよ」って突っ込まれてたんだが
「ﾊｧ?BT.601だとこれが正規ですよ、と。おまいの環境のｷｬﾘﾌﾞﾚｰﾄがｵｶｼｲｶﾓﾅｰ」
みてーな返答でｽﾙｰされておった。
意地でも直さないだろうな・・・KEN。
630 ：名無しさん＠編集中：03/07/03 23:02: >>629
slaveは恐ろしい釣り氏だな。

「そこまでAviutlをおとしめたいのか？」

と思ってAviutlスレ3から6まで読んじゃったじゃねーか。
完全に釣られました。
そんな話はでてきておりません。
途中音ずれの話題でレスが埋め尽くされてたのはワラタが,
あの頃は結構まともに機能してたんだな　＞Aviutlスレ。
631 ：名無しさん＠編集中：03/07/04 00:57: 似たようなので、YUY2入力するとスケール伸張されるって騒いでたな。
そしたら内部は12bit有効なので伸張されてもクロップされないってマルモがしゃしゃり出たんじゃなかったっけ？
632 ：名無しさん＠編集中：03/07/04 01:29: aviutlは途中でクリップされないのがいいとこなんだがな
YCCは各12ビット表現だけど出力フレームが確定するまでは16ビットフルに有効だから
（プラグイン作者が想定してるのは13ビット以内のデータだけだろうけど）
YUY2読みしてもYゲインを下げれば範囲外の階調もちゃんと残ってることに気付くよ

avisynthの場合、データは8ビットでしか扱えないから
何かのフィルタで一度飽和させてしまうともう元に戻せないしね
まぁ速いし、YUY2読みしたものをそのままCCEに渡せるから愛用してるけど。。
633 ：名無しさん＠編集中：03/07/04 01:52: >>632
飽和させるフィルターって何？
ちょっとそれは考えられないけどな。縮小されるフィルターばっかし。
もちろん、色補正関係のフィルターを除いての話。
634 ：名無しさん＠編集中：03/07/04 03:07: >>632
m2v.vfpでYC伸長してAviUtlに渡すよりm2v.auiでYUY読み込みしたほうが
AviUtlでYUY2のソースをYUY2で展開してYUY2で圧縮する設定なら
RGBのヒストグラムを0-255まで使ってYUY2に圧縮するときに
BT.601の範囲内に収まるYUY2データを残せて良いと理解していいですか?
635 ：名無しさん＠編集中：03/07/04 05:33: >>634
小一時間悩んだが、俺はお前の言いたいことが理解できない。
日本語勉強しなおしてくれ。

”m2v.auiでYUY読み込みしたほう”
　　　　　　　と
”YUY2のソースをYUY2で展開して”
は同じ意味。
どっちも
"YUY2読み込み”
m2v.vfpだと”RGB読み込み”だからな。

”RGBのヒストグラムを0-255まで使ってYUY2に圧縮するとき”
微妙に意味が通らない。
YUV->RGB変換がストレートだろうが伸張だろうが
”RGBの”のデータは”0-255”。

m2v.auiはMPEGソースを”YUY2展開”する手段。
.d2vやm2v.vfpでは”YUY2展開”できない。
できないということはYUV->RGB変換がはいる。
つまりm2v.auiの利点は
「YUV->RGB変換しないこと」
であり、
m2v.vfpの欠点は
「YUV->RGB変換すること」

YUV->RGB変換の欠点・利点は↑のほうでガヤガヤやっとるんで、
ログ参照。
636 ：名無しさん＠編集中：03/07/04 22:57: radeonは規格準拠なのがはっきりしたわけだが

> ちなみにRADEONはDTVについてのPDFで
> >RADEON supports any of the color spaces defined by the MPEG-2 standard,
> としている。
> http://mirror.ati.com/developer/atirdv.pdf
637 ：名無しさん＠編集中：03/07/04 23:12: >>636
はっきりしてないわけだがw
638 ：名無しさん＠編集中：03/07/05 12:51: こういう言い方はあいまいにするための常套手段だねｗ。
つか、準拠という言葉自体が。。。
639 ：名無しさん＠編集中：03/07/05 21:27: MPEG2規格のいかなる色空間もサポートするよ、と。
それはYV12,YUY2,IYU2をサポートするよ、と言ってるだけだろ。
大体このスレで誰も突っ込みが入らないのが不思議なんだが、
BT.601規格にはストレート変換も入っているのだよ。
”BT.601準拠=伸張変換”みたいなレスが多いが
それは間違い。
640 ：名無しさん＠編集中：03/07/05 22:32: >>639
IYU2ってなに？
641 ：名無しさん＠編集中：03/07/05 23:44: >>640
24bitYUV4:4:4
ｸﾞｸﾞﾚよ、これくらい
642 ：名無しさん＠編集中：03/07/06 00:21: >>639
そんなにムキになるなよ。
ここにいる奴はまるものページぐらいは読んでるって。
BT.601とストレートで十分に通じるぞ。
643 ：名無しさん＠編集中：03/07/06 00:34: ここって常駐者しかいないのに
新情報なんてﾛｸにないから
初心者がくだらないｶｷｺしないとﾚｽが進まないね
まぁその初心者も常駐はしないだろうし
644 ：名無しさん＠編集中：03/07/06 00:45: >>643
slave氏ね
645 ：名無しさん＠編集中：03/07/06 14:31: >>633
実際にはゴーストリダクション系くらいだろうな。
設定値によってはシャープ系でも飽和させれるけど、
そんな設定値使わないだろうし。
646 ：名無しさん＠編集中：03/07/11 01:19: 90さんの書いてることが真実なんだろ。悩むことないよな。

YUV形式の動画　→　RGB形式の動画　YC伸張する
RGB形式の動画　→　YUV形式の動画　YC圧縮する

で良いんだろ？

あとは使うソフトによって精度が変わるくらいで大した問題じゃないな。
647 ：名無しさん＠編集中：03/07/11 05:56: >>646
残念ながら>>90に書いてあることは真実ではない
でも、二重伸張や二重圧縮に比べたら
YUV<->RGB変換誤差やサチュレートなんてたいした問題ではない
648 ：名無しさん＠編集中：03/07/11 10:31: >>647
> 残念ながら>>90に書いてあることは真実ではない

真実ではないのはどういう点なんだい？

俺がひとつ疑問かなぁと思ったのはキャプチャーで出来るMPEGはTVスケール
（16-235）で間違いないと思うんだけど、hunuaaなんかでhuffyuv圧縮（yuv形式）
で取り込んだAVIもTVスケール（16-235）なのかなぁっていう点。個人的には
RGBをYC圧縮なしにRGB>YUV変換してるような気がするのでPCスケール（0-255）
のような気がする。

とすれば、90さんの言うYUV系：TVスケールっていうのもあながちそうでもない
ということになる。
649 ：名無しさん＠編集中：03/07/11 10:54: お前ら、どっちでもいいんだよ。綺麗に見える方。これ最強。理屈などいらぬ！
650 ：名無しさん＠編集中：03/07/11 10:55: またあふぉがきた
651 ：名無しさん＠編集中：03/07/11 11:33: TVスケールとかPCスケールとかいう言葉に納得がいかない
652 ：名無しさん＠編集中：03/07/11 11:36: >>650
DTV なんか究極の自己満足じゃねーかよ。
自分が良ければ、それでOKだろう。
653 ：名無しさん＠編集中：03/07/11 12:32: 650は648へのレス
654 ：名無しさん＠編集中：03/07/11 13:10: >>653
了解
655 ：名無しさん＠編集中：03/07/11 16:27: 結局あれだろ？各動画フォーマットが

full-range RGB [0,255]
compressed-range RGB [16,235]
full-range YUV [0,255]
compressed-range YUV [16,235]

のうちどれを使ってるか把握出来てれば問題ないんだろ？あとは些細な精度の問題で。
656 ：名無しさん＠編集中：03/07/11 20:49: >>655
動画フォーマットがどっちのスケールを使うかということより
動画系アプリがどういう設定のときどっちのスケールを使うか？が問題。
それによって出力された動画のスケールが決定されるから。
657 ：名無しさん＠編集中：03/07/11 20:54: わけわからん
658 ：名無しさん＠編集中：03/07/11 21:09: >>655
>>317が正解
ただYUV<->RGB変換誤差が些細な問題かどうかは
>>381を御覧あれ
659 ：名無しさん＠編集中：03/07/11 21:43: そもそもMSがちゃんと動画フォーマットの仕様決めないからこんなことに
なるんだな。

WIN上で扱うRGBはすべてfull rangeに汁！YUVはすべてcompressed rangeに汁！
Video Cardはオーバーレイ使う時はHWでYC伸張汁！ってすれば無問題なのにな。
660 ：名無しさん＠編集中：03/07/11 21:48: >>659
基本的にはそうなっているっしょ。問題はそれを無視する腐れアプリ・codec・
グラフィックカードがあるってこと。
661 ：名無しさん＠編集中：03/07/11 21:52: >>658
まぁね。些細な問題じゃない人もいるわな。そのへんは個人の価値観ってことで。
俺はYC伸張や圧縮を二重にかけたりしさえしなけりゃそれでOKって思える人間
だからなぁ。

ノイズやアルゴリズムの計算上の誤差なんてのはこだわりだしたらきりがない
からな。それこそ最終的にはソース見せろや、ごるぁってところまでいかないと
ほんとの信用なんて出来ない訳だしな。ｗ
662 ：名無しさん＠編集中：03/07/11 21:55: >>660
腐れグラフィックカード；ゲフォ

腐れアプリと腐れCodecって何がある？
663 ：名無しさん＠編集中：03/07/11 22:04: 腐れアプリ：Avisynth厨が言うところのAviUtl
664 ：名無しさん＠編集中：03/07/11 22:36: 腐れCodec：HuffyuvS厨が言うところのHuffyuv
665 ：名無しさん＠編集中：03/07/11 22:38: 腐れアプリ:内部RGBのTMPGEnc
腐れコーデック:いわずもがなのHuffyuvSとHuffyuvのconv->yuy2
腐れ仕様:VFAPI
666 ：名無しさん＠編集中：03/07/11 22:45: >>661がどうやってるのかは知らない
ただよくやる以下の手法は
正直どう見ても色がかわる
DVD2AVI->.d2vでAviutl->Huffyuv(YUY2)中間ﾌｧｲﾙ->TMPGEnc
↑こんなことしといて
「エンコードって色が変わるねぇ」
いわれてもさぁ・・・
いや、エンコードによる色変わりは当然あるけど
それ以上の問題があるだろ？
まぁ手順の問題というか
目の問題というか
667 ：名無しさん＠編集中：03/07/11 22:49: 腐れcodec:WMV9のインターレース
668 ：661：03/07/12 01:07: >>666

俺の手順は

hunuaa（huffyuvキャプ、YUY2）→AVIUTLで編集(フィルタ類は一切使わず、
カット＆ペーストのみで再圧縮なしで保存）→WME9でインタレエンコ

VGAはG450、AVIUTLも再圧縮なしだと高速だし、TV出力してもモニタで見ても
同じように見えるし、俺的には画質も無問題。
669 ：名無しさん＠編集中：03/07/12 02:08: >>668
ある意味理想かも知れないね。
キャプチャ時の設定がジャストミートしてればさ。
でもNRぐらい掛けたら？（インタレを壊さないNRってことだけど）
670 ：名無しさん＠編集中：03/07/12 02:10: インタレを壊すNRって何？
671 ：名無しさん＠編集中：03/07/12 02:30: >>669

時間以外はそれなりに満足してるんだけどね。いろいろ試行錯誤して結局
こうなったんだよな。

２２０GBほどHD用意してるけど３時間ちょっとしかキャプ出来ないんで
録りだめは出来ないね。ｗ
672 ：名無しさん＠編集中：03/07/12 02:36: こっちでももめてる
http://pc.2ch.net/test/read.cgi/avi/1044370473/909-
673 ：名無しさん＠編集中：03/07/12 02:40: >>670
上下に隣接している点を考慮するNRはインタレ構造を壊すことが分からんか？
たとえば、P(x,y)=( P(x,y) + P(x,y-1) + P(x,y+1) + P(x-1,y) + P(x+1,y) ) / 5
なんてのなら、ライン間でブレンドされるだろが。
674 ：名無しさん＠編集中：03/07/12 02:44: >>672
RGBで253ってのはまあ妥当じゃないの？
べつにこんなのじゃもめないよ。
675 ：名無しさん＠編集中：03/07/12 09:32: >>659
PCで完結してもダメなのよ
676 ：名無しさん＠編集中：03/07/12 11:59: またアフォが一人現れたな　＞675
677 ：名無しさん＠編集中：03/07/12 12:04: やっと理解できた。みなさんありがとう。
678 ：名無しさん＠編集中：03/07/12 12:26: >>675
この人言ってる意味不明、恐らく何も分かってないと思われ。

659で触れてる規格はむしろ映像業界のフォーマットに後発のPC側が
合わせた結果であって別にPCで完結しようとしてる訳ではない。
679 ：名無しさん＠編集中：03/07/12 13:45: 678必死だな（藁
680 ：名無しさん＠編集中：03/07/12 13:52: 679 名前：名無しさん＠編集中[sage] 投稿日：03/07/12 13:45
678必死だな（藁
681 ：名無しさん＠編集中：03/07/12 16:02: ◆◇◆◇　海外サイトだから安心無修正　◇◆◇◆
http://upbbs.s2.x-beat.com/linkvp/linkvp.html

　↑　
ココは丸見え！　今ならまだ消されてないよ。たぶん・・・
682 ：名無しさん＠編集中：03/07/13 20:52: 242 ：名無しさん＠編集中：03/07/13 16:52
>>240
本当は可逆圧縮より圧縮しないで良いならそのほうが良いが、
ＭＰＥＧからなら普通Huffyuv を使うという事。
元の情報よりHuffyuvにした時点で少し劣化する。

243 ：名無しさん＠編集中：03/07/13 17:21
>>242
若干わかりにくい文章かも。

244 ：名無しさん＠編集中：03/07/13 17:30
>>242
Huffyuvってハフマン符号化だけじゃないの？だとしたら劣化しないはずだけど。
683 ：名無しさん＠編集中：03/07/13 20:52: 245 ：名無しさん＠編集中：03/07/13 17:36
>>242
中間ファイルなんだろ？
”圧縮しないで”ってなんだ？
MPEGソースなら非圧縮YUY2か？
MPEGソースの非圧縮YUY2とHuffyuv(YUY2)は同等だよ。
MPEGソースを非圧縮RGBにしたりHuffyuv(RGB)にしたら
どっちも劣化するけどな。

246 ：名無しさん＠編集中：03/07/13 17:52
可逆圧縮の意味もわからんヤシが回答するのか

（回答者も）初心者質問スレッド 27　だな

247 ：名無しさん＠編集中：03/07/13 18:03
わからんやつや246を見習って傍観

248 ：名無しさん＠編集中：03/07/13 18:08
そのソースMPEGがYUV4:4:4の場合にかぎり
何選んでもHuffyuv化するときに少し劣化する。
でもYUV4:4:4のMPEGって仕様書にはあるけど、
作れないし見たこともない。

249 ：名無しさん＠編集中：03/07/13 18:31
MPEGソースは非圧縮じゃない。
684 ：名無しさん＠編集中：03/07/13 20:53: 251 ：名無しさん＠編集中：03/07/13 18:40
ＡＶＩ(YUY2)を編集後に中間ファイルを出して
その後DIVX化する場合にHuffyuv(YUY2)でやると
元のＡＶＩ(YUY2)よりサイズが小さくて明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。

252 ：名無しさん＠編集中：03/07/13 18:47
？？？

253 ：251 ：03/07/13 18:48
修正。AVI(UYVY)
685 ：名無しさん＠編集中：03/07/13 20:54: 255 ：名無しさん＠編集中：03/07/13 19:35
>>251
カラーフォーマットの変換による色(色差)情報の劣化と、圧縮形式による情報の欠落を
ごっちゃになっているような。
通常、圧縮による劣化の有無は、カラーフォーマットの変換を含めないで話した方が
いいんじゃないだろうか？

256 ：名無しさん＠編集中：03/07/13 19:40
>>251
もとのAVI(UYVY)はどうやって生成した？
その編集とやらはVirtualDub系のFastRecompresなのか？

257 ：名無しさん＠編集中：03/07/13 19:42
>>255
同意。
ハフマン符号化して劣化するなら、世のプログラムは圧縮した段階で
正常に動作しなくなりなります。
686 ：名無しさん＠編集中：03/07/13 20:54: 259 ：名無しさん＠編集中：03/07/13 19:44
釣りだろ
”元のＡＶＩ(YUY2)よりサイズが小さくて明らかに劣化がわかる”
とかほざいてるし
”.zipは元の.exeよりサイズが小さくて明らかに情報欠落がわかる”
と言ってるようなものだ

260 ：名無しさん＠編集中：03/07/13 19:51
UYVYであってもAvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。
Huffyuvに渡される以前で変換誤差がでるようなやり方をしてると勿論ダメ。
DUBのFullやAviutl,TMPGEncのAVI出力などは
Huffyuvに渡される前に情報劣化がおきる。

261 ：名無しさん＠編集中：03/07/13 20:02
環境が不明だが、
>>251のやり方では以下のような減少がおこる

ＡＶＩ(UYVY)を編集後に中間ファイルを出して
その後DIVX化する場合にＡＶＩ(UYVY)でやると明らかに劣化がわかる。
編集するとさらに悪くなる。そのままだと何度やっても劣化は少ない。
687 ：名無しさん＠編集中：03/07/14 20:13: また、やってる・・・
688 ：名無しさん＠編集中：03/07/14 20:26: 358 ：名無しさん＠編集中：03/07/14 19:32
>>261
ＡＶＩ(UYVY)で撮ったならhufにしないほうが結果はいい。
自分の環境ではＡＶＩ(YUY2)でも撮れるが、その場合はhufにしても劣化はない。
要するにYUY2よりUYVYのほうがはっきりわかるほど綺麗なんですよ。UYVYで
プレミア編集後無圧縮で書き出してdubでＤＩＶＸ化するのでhufにする必要はない。

364 ：名無しさん＠編集中：03/07/14 20:08
>>358
YUY2とUYVYﾃﾞｰﾀ順列以外の違いはない
ただしｷｬﾌﾟﾁｬｰﾎﾞｰﾄﾞ上のﾁｯﾌﾟや編集ｿﾌﾄなどがﾈｲﾃｨﾌﾞUYVYの場合
YUY2ｷｬﾌﾟﾁｬｰやYUY2吐き出しを行うとｿﾌﾄｳｪｱ処理による
UYUV->RGB->YUY2変換が行われる
結果的にYUV<->RGB変換誤差がおこる

似たような現象にYUY2ﾈｲﾃｨﾌﾞｷｬﾌﾟﾁｬｰﾎﾞｰﾄﾞによるRGBｷｬﾌﾟﾁｬｰがある
大概ふぬああ+Huffyuv(RGB)でおこなうことになるが
これはｷｬﾌﾟﾎﾞがYUY2でｷｬﾌﾟﾁｬｰし、ｿﾌﾄｳｪｱでYUY2->Huffyuv(RGB)にﾘｱﾙﾀｲﾑでしてるだけ
RGBﾈｲﾃｨﾌﾞｷｬﾌﾟﾁｬｰとは画質が全然異なるばかりか
そのｷｬﾌﾟﾎﾞのﾈｲﾃｨﾌﾞYUY2より劣化したRGBになる

ｷｬﾌﾟﾁｬｰﾎﾞｰﾄﾞ、編集ｿﾌﾄ、ｴﾝｺｰﾀﾞ、ﾌﾛﾝﾄｴﾝﾄﾞ、codecなどの
ﾈｲﾃｨﾌﾞ色空間を把握しておくことが大切である

365 ：名無しさん＠編集中：03/07/14 20:23
>>358 >>364
ウザい。↓でやれ。

YC伸張する？しない？総合ｽﾚｯﾄﾞ
http://pc.2ch.net/test/read.cgi/avi/1050299614/
689 ：251：03/07/14 20:44: ﾈｲﾃｨﾌﾞUYVYです。
690 ：名無しさん＠編集中：03/07/14 20:46: >>689
omaedareda?
691 ：名無しさん＠編集中：03/07/14 20:50: ﾈｲﾃｨﾌﾞUYVYだからRGB変換誤差がおこるだから
hufにしない。で間違ってないじゃん。
692 ：x：03/07/14 20:52: ◎無修正画像をご覧下さい◎２日間無料です◎
★http://yahooo.s2.x-beat.com/linkvp/linkvp.html★
693 ：名無しさん＠編集中：03/07/14 21:14: >>691
ﾈｲﾃｨﾌﾞUYVYでも
”UYVYであってもAvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化して
DUBのFASTでHuffyuv(YUY2)にすれば劣化はしない。”
ってのはどうよ。
つーか
”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”
ってなんじゃ？
694 ：山崎渉：03/07/15 11:08: 　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
695 ：名無しさん＠編集中：03/07/15 18:36: Huffyuvの対応色空間
YUY2、UYVY、RGB24、RGB32(RGBA)

UYVYもそのまま圧縮可能だよ。
696 ：名無しさん＠編集中：03/07/15 19:50: >>695
じゃぁAvisynthがUYVYに対応しないってことか？
697 ：名無しさん＠編集中：03/07/15 20:12: >>696
AvisynthはYV12かYUY2かRGB32にしか対応しとらんやん
698 ：名無しさん＠編集中：03/07/15 20:35: >>697
それはフィルタの話でしょ？
I420でもswapUVでYUY2にできるわけだから。
でも”AvisynthでﾏｸﾛﾋﾟｸｾﾙﾊﾟｯｸをYUY2に正常化”は不可能？
Directshowで読めるならYUY2に変更して展開するんかな？
UYVYの動画がないんでよくわからないんだが。
699 ：名無しさん＠編集中：03/07/15 21:30: >>698
それは見た目がYUY2だからだろ。Avisynthは基本的にコーデックがYUY2に展開して
くれないと話にならん。
700 ：名無しさん＠編集中：03/07/15 21:46: Avisynth2.52でUYVY試してみた。
無圧縮UYVYの場合、RGB32にdecompressされた。(vidc.UYVY=msyuv.dll、huffyuv.dllとも）
Huffyuv(UYVY)の場合、YUY2にdecompressされた。
どうやら、Huffyuv(msyuvも同様）は、UYVYでdecompressQueryすると、RGB32/24を返すようだ。
701 ：名無しさん＠編集中：03/07/15 21:51: >>699
UYUVの見た目はYUY2なんだが
702 ：名無しさん＠編集中：03/07/15 22:03: >>700
おお！クスコ。
703 ：700：03/07/15 23:34: Huffyuvのソースをちょっくら覗いてみた。
DecompressQueryで、
intype=-1(HFYU)の場合、outtype=1(YUY2),3(RGB24),4(RGB32)の時、ICERR_OKを返す。
intype=-2(RGB24),1(YUY2),2(UYVY)の場合、outtype=3(RGB24),4(RGB32)の時、ICERR_OKを返す。
intype=-3(RGB32)の場合、outtype=4(RGB32)の時、ICERR_OKを返す。
それ以外はICERR_BADFORMATを返す。

つまり、UYVYはHuffyuv圧縮すると、-1(HFYU)になり、decompressはYUY2、RGB24,RGB32のいずれかのみ。
UYVUが何時YUY2になるのかみると、既にcompress時にswapされてYUY2となってHuffyuv圧縮されちゃってるよ。
Avisynthは、DecompressQueryを、YV12,YUY2,RGB32,RGB24と発行してOKが帰ってきた色空間でDecompressBeginを発行している。

以上のことから、Huffyuv(UYVY)はHuffyuv(YUY2)と同じと思って良い。
無圧縮UYVYは、この色空間を取り扱えるソフトが無く、RGB24/32に変換されるので使用しない方が良い。
ということになる。
704 ：700：03/07/15 23:37: 間違い訂正
intype=-2(RGB24) -> intype=-2(HFYU(RGB24))
intype=-3(RGB32) -> intype=-3(HFYU(RGB32))
705 ：名無しさん＠編集中：03/07/16 23:19: >>703
VirtualDubでもﾀﾞﾒかな？
Dubに非圧縮UYVY読ましてFastでHuffyuvにしちゃえば
あとはやりたい砲台なのでは？
706 ：名無しさん＠編集中：03/07/17 20:59: 落ちるには惜しいスレ
707 ：名無しさん＠編集中：03/07/17 21:37: VirtualDubで非圧縮UYVY読ましてからDivxにしてる。
間にHuffyuv入れる事はない。というかVirtualDubで
取り扱えるんじゃないの。自分はHuffyuvにすると
容量３パーセントほど減って重くなるし、コーデックHuffyuvのＡＶＩで
撮ってもそう。
708 ：名無しさん＠編集中：03/07/17 21:44: UYVYを展開するのはmsyuv.dllじゃないの？
709 ：名無しさん＠編集中：03/07/17 21:45: VirtualDubはfast recompressでもYUY2/RGBじゃないと入力できないはずだけど。
710 ：名無しさん＠編集中：03/07/17 22:11: YUY2で撮るとさらに汚いけど…
711 ：名無しさん＠編集中：03/07/17 22:34: >>710
>>688
712 ：名無しさん＠編集中：03/07/18 00:43: >>710
http://pc.2ch.net/test/read.cgi/avi/1050299614/566-
713 ：名無しさん＠編集中：03/07/19 03:06: ｹﾞﾌｫ厨発見

622 ：名無しさん＠編集中：03/07/17 03:59
>>619
PCのモニタで見てない？
TVに出力すればちゃんとしたメリハリの効いた画になってるはず。
PCモニタでTVと同じ画を表示しようってのは絶対無理。
714 ：名無しさん＠編集中：03/07/19 03:40: >>713
いやあ、どんなビデオボードでだってTVと同じには表示できんよ。
TVとPC画面を２つ並べて見比べてごらんよ。
715 ：名無しさん＠編集中：03/07/19 10:23: 蛍光体の違いはあるからTVと同じように表示するのは難しいことは確か。
でも、蛍光体の違い以前にTVのキャリブレーションがまったくされていない
ため、見栄えが違ってくる場合がほとんど。TVはRed Pushしたりガンマ補正
したりと、原信号を思いっきり歪めて表示していることが非常に多い。
716 ：名無しさん＠編集中：03/07/19 10:35: 民生用TVで動画見てるやつは知障
717 ：名無しさん＠編集中：03/07/20 21:39: スレ読んでたら混乱してきたのでちょっと質問。
canopus DV codecのソースを最終的にDVD化するという話です。

1. キャプってcanopus DV codecのソースを用意する。
2. Aviutlで「YU2展開」のチェックボックスを外して開く。
3. 波形表示フィルタで16-235の範囲になるように色・輝度調整。
4. ノイズ除去とかしたかったら各フィルタ設定。
5. 「YUV2圧縮」のチェックボックスを外した状態でcanopsu　DV codecで中間ファイルを作る。
6. Avisynth挟んでColorYUY2でinterpolationtion使って4:2:2補完してCCEに渡す。
7. CCEは16-235でMPEG2ファイルを作る。後、オーサリング＆焼き

こういう手順で良いのですかね？　
近々カノプDVを使ったキャプに乗り換える予定なのです。
何か間違いがあれば指摘してください。
718 ：名無しさん＠編集中：03/07/20 22:51: なんか難しいことやってるなぁ。

YUY2で展開/圧縮をオフるとRGBになっちゃうからオンの方がいいと思うぞ。
それから、YC伸張プラグインを使ってAviUtl上でyuv411>422補完、とか
Avisynth上でフィールド別処理のcolorYUY2で411>422補完→avsinp.auiを使ってAviUtlにわたす、とか
すれば処理が少なくてすむかな。
あとは中間吐くなりVFAPI Reader CodecつかうなりでCCEに渡すと。
最後までyuvでいきたいなら中間つくった方がいいのかな。
中間出力するならDVよりHuffyuvかLCLのほうがいいよ。

俺もあんまり詳しくないんで間違ってるかもしれんけど。
719 ：名無しさん＠編集中：03/07/20 23:11: >>717
ちょっとその方法はひどすぎ
大体ソフトウェアでCanopusDv化しようとすると9分くらいしかできないよ
参照CanopusDvCodecはハード専用
それ以上にフィルタ＞DVcodecっじゃひっでぇ画になる

オレもDV厨だが
1,canopus dv codecのソース用意
2,AviutlでYUY2読み込み
3,YC伸長フィルタで補完
4,各種フィルタ
5,Aviutlでは出力しない
6,ソースをAvisynth+VirtualDubで読み込み
7,Convert411to422使用
8,AviutlFilterPluginで4,の結果をスクリプト化
9,VirtualDub（Fast）にてHuffyuv(YUY2)出力
10,CCEにyuy2読み込みさせてエンコード

まどろっこしいけど
色調をフローさせず
なおかつ自分好みの色合いにして
しかもYUV<->RGB変換せずに
Aviutlのフィルタを使う方法です。
720 ：名無しさん＠編集中：03/07/20 23:20: >>718
なるほど、今YC伸張フィルタ落としてきたところです。
中間ファイル作るのもいいけど、HDDに余裕あるわけでもないので、
最後だけVFAPI経由でCCEに渡して16-235でエンコすることにします。

何にしても、波形表示フィルタでヒストグラム見ながら、
おかしなことにならないように確認していこうと思います。
ありがとうございました。
721 ：名無しさん＠編集中：03/07/20 23:31: >>720
Avisynth2,0系なら.avsそのままCCEにもってけるよ
VFAPIになんぞせんでもよろしい
722 ：名無しさん＠編集中：03/07/21 00:13: >>719
YC伸張フィルタを使用したのに、Avisynthでも伸張？補完？するのは何故ですか？
あと、AVIUTLからAvisynthへの持っていき方がわからないです。ソースを読み込むとか....

というか、Avisynth使ったことないのでさっぱりな自分があかんのですけど。
もうすこし解かりやすい説明をして頂けないでしょうか。
723 ：名無しさん＠編集中：03/07/21 00:47: >>722
AvisynthのAviutlFilterPluginは
Avisynth上でAviutlのフィルタを使うプラグインなんだけど
なんせスクリプトだから数値を変化させても動的に画質をチェックしにくい
だからAviutl上でいっかいフィルタの各設定値を煮詰めておいて
その数値をAvisynthのスクリプトに書き写してるんだよ
だから”5,Aviutlでは出力しない”
Aviutlは設定を決めるために使ってるだけ
724 ：名無しさん＠編集中：03/07/21 00:47: >>722
説明求めるまえに自分で調べるようにしろよ…。そんなんじゃ、いつまでたっても
厨のまんまだぞ。
725 ：名無しさん＠編集中：03/07/21 00:48: >>722
とりあえずAvisynthスレからにーやんのページにいってみな
くれぐれもAvisynthスレでそんな質問せんほうがいいぞ
726 ：名無しさん＠編集中：03/07/21 00:51: いや、すんません。頑張ってきます。
727 ：名無しさん＠編集中：03/07/21 01:03: >>723
具体的にどのフィルターをAviutlFilterPluginで読み込んでる?
できればAvisynthだけで完結したいんだけどwavelet系が弱いからまだAviUtlフィルター手放せないんだよなぁ。
728 ：名無しさん＠編集中：03/07/21 01:18: >>727
WaveletTYPEG,3DNR2,リンギング低減,視聴覚感度ぼかし
あとはAvisynthのフィルタを使ってる
てか、スレ違いでない？
729 ：名無しさん＠編集中：03/07/21 19:17: >>717
430見れ
730 ：名無しさん＠編集中：03/07/28 23:51: 1から読んだけど全然わからん。

結論を書いては貰えませんか？
普通にキャプって、普通にエンコする場合どうすればいいんです？
ふぬああとかHuffyuvとかややこしい物は使いません。
731 ：名無しさん＠編集中：03/07/29 01:16: >>730
結論？
自分の環境と目的と同じ物を探せばいいだろうが
732 ：名無しさん＠編集中：03/07/29 05:55: >>730
お前がキャプしてる方法が世界標準とでも思ってるの？
何だよ普通にキャプって・・・。
733 ：名無しさん＠編集中：03/07/29 07:37: そもそもふぬああやHuffyuvを使わない普通じゃない方法ってあるのか？
思いつくのはDVDレコやDVやD-VHS使う方法くらいだが。
何も考えずMPEG2→MPEG1みたいなことじゃないのか？
734 ：名無しさん＠編集中：03/07/29 08:58: 何も考えないにしてもどーゆー手順でどーゆーソフト使ったか
わからんとどーにもならないわけで
735 ：名無しさん＠編集中：03/07/29 15:20: 730じゃないですけど、松下のDMR-E80Hで録画したものを、
DVD2AVIとTMPGEncでVCD・MPEG2・Divx等にエンコードする時はどうすればいいんでしょう？
736 ：名無しさん＠編集中：03/07/29 15:41: >>735
ｴﾝｺの仕方勉強して出直してこい
737 ：名無しさん＠編集中：03/07/29 17:25: MPEG2-TS → DVD2AVI → Avisynth → CCE → DVD
この場合ですが、AvisynthにColorYUY2(levels="709->601")と入れておくと良いんでしょうか？

DVD2AVI1.77.3、Avisynth2.52、MPEG2Dec3を使ってます。
738 ：735：03/07/29 21:12: >>736
あ、エンコの仕方は知ってます。
YC伸張のことです。
739 ：名無しさん＠編集中：03/07/29 21:28: 色が薄いと思ったら伸張すれ
ちょうどいいと思ったらしない
それだけだ
740 ：名無しさん＠編集中：03/07/30 00:00: イジワル
741 ：名無しさん＠編集中：03/07/30 05:02: >>737
MPEG2-TSだからといって、必ずしもBT.709とは限らないよ。SDならBT.601だし。
742 ：名無しさん＠編集中：03/07/30 12:33: >>741
HDの時だけですか？
743 ：名無しさん＠編集中：03/07/30 14:25: HDってプログレだけだっけ？
744 ：名無しさん＠編集中：03/07/30 20:50: DOS/V magazine で動画の表示比較記事があったが
nVIDIAはGeforceFXになっても、ATIやMatroxやS3とは明らかにスケールの取り方が違うことが分かったよ。
745 ：名無しさん＠編集中：03/07/30 20:57: nVIDIAもうだめぽ
746 ：名無しさん＠編集中：03/07/30 20:57: >>742
そ。

>>743
普通1080iだからインターレース。
747 ：名無しさん＠編集中：03/07/30 23:35: >>746
じゃYV12の色空間だったら
ColorYUY2(levels="709->601",interlaced=true)
が良いのだろうな。
748 ：名無しさん＠編集中：03/07/31 00:01: マジで？？
749 ：名無しさん＠編集中：03/07/31 09:20: 720p
750 ：名無しさん＠編集中：03/07/31 14:56: 720pの時にfalseなんでつね
751 ：名無しさん＠編集中：03/07/31 15:27: Interlaced指定は、YUY2なら気にしなくてよいぞ。
752 ：名無しさん＠編集中：03/07/31 15:59: 720pってBS朝日で1回放送しただけなんだっけ。以前、地上デジタルでは720pなんて
話があったけど、結局1080iになったみたいだし。
753 ：ぼるじょあ ◆yBEncckFOU ：03/08/02 05:04: 　　　　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　・３・） (　　＾＾）＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ
754 ：名無しさん＠編集中：03/08/03 22:43: これで見たらSDのおね２はBT.709だったが。
TS>PS変換しただけなら変わらないよね？
http://www.sakurachan.org/soft/mediatools/index.html
755 ：名無しさん＠編集中：03/08/03 22:45: 直リンしてしまった。ごめんなさい。
756 ：名無しさん＠編集中：03/08/03 23:36: >>754
webでも情報が錯綜していてよくわからないんだよ
BSDハイビジョン(1080i)はBT.709は確定なんだが
他の解像度についてはﾏﾁﾏﾁで
757 ：名無しさん＠編集中：03/08/04 06:19: 美少女コスプレイヤーのパンチラと
パイパンおまんこが見れるサイトを発見でつ！！！
http://plaza16.mbn.or.jp/~satchel/idolno_omanko/

パイパンおま○こは本当に美しい…　(*´∀`*)ハァハァ
758 ：_：03/08/04 06:30: http://homepage.mac.com/hiroyuki44/
759 ：名無しさん＠編集中：03/08/05 06:32: NHKに問い合わせりゃいいじゃん。
760 ：名無しさん＠編集中：03/08/05 10:33: >>759
そんなことしたらデジタルコピーしてることがバレるじゃんか。
犯罪者は犯罪を犯しているという自覚を持ってないとボロがでるぞ。
761 ：名無しさん＠編集中：03/08/05 12:50: おかしな知障が何か言っております
762 ：名無しさん＠編集中：03/08/05 13:23: 高ビットレートMPEG2からDVDサイズのMPEG2への変換における
カラースケールの設定について詳しく、しかしなるべく簡単に
説明をお願いします。
過去ログ嫁とかはなしで。
次からテンプレにできますしね。
763 ：名無しさん＠編集中：03/08/05 13:27: おかしな知障が何か言っております
764 ：名無しさん＠編集中：03/08/05 13:49: 夏真っ盛り
765 ：名無しさん＠編集中：03/08/05 14:04: >>762
1から嫁
答えはすぐそこにある
766 ：名無しさん＠編集中：03/08/05 15:05: >>765
自分でレスしてるんだから気付けよ。

テンプレ化しないから、
>>762　→　>>765　のようなやり取りが繰り返されることになる。
(テンプレ化しても質問するアホはたまにいるけど)
767 ：名無しさん＠編集中：03/08/05 15:12: 　　　　 ///////
　　　　///////＿＿＿＿＿＿＿＿＿＿＿_
　　　 /////// ￣￣￣￣￣￣￣￣￣|￣￣
　　　///////　　　　　　　　　　　　　 (~)　ﾁﾘﾝﾁﾘﾝ
　　 ///////　　　　　　　　　　　　　　ﾉ,,
　　///////　　　　 ∧＿∧　　　　　　　　／￣￣￣￣￣￣
　 ///////　　　　（　´∀｀）（厨） )）　＜　　夏だなあ～
　/////// 　　　　（つ　へへつ　　　　　＼＿＿＿＿＿＿
///////　　　//△ ヽλ　）　）　旦
//////　　l￣￣￣￣￣￣￣￣￣￣￣l
/////　　　￣| .|￣￣￣￣￣￣￣| .|￣
////　　　　　^＾^　　　　　　　　　 ^＾^

　　　　　　　　　2chの夏。厨房の夏。
768 ：名無しさん＠編集中：03/08/05 15:26: >>766
じゃおまえがやれば
769 ：名無しさん＠編集中：03/08/05 19:18: というわけで最強のテンプレ案↓
770 ：master：03/08/05 19:31: YC伸張はどんなとき必要か？
多数のｱﾌﾟﾘを経由したときのｽｹｰﾙはどうなるか？
などなど
codecどころかVGAﾁｯﾌﾟまでもがYC伸張する昨今
混乱を極めたｽｹｰﾙ変換についての総合ｽﾚです
参考資料
↓
http://www.studiomilk.com/ichigomilk/diary/orenatsu2opdemo.swf
771 ：名無しさん＠編集中：03/08/05 19:43: >>770
お前、楽しい?
772 ：名無しさん＠編集中：03/08/05 20:29: >>762
すべてYUVで処理する。
そうすればカラースケールなど無関係。
君もAvisynth+CCEの世界にきなさい
773 ：名無しさん＠編集中：03/08/05 23:50: slaveがスネちゃったからテンプレ化は無理だろうな
774 ：名無しさん＠編集中：03/08/06 03:53: ビデオカードでGEフォースを使ってるのですが、
そのためにWMPで再生したときオーバーレイを切らないと
暗くなってしまいます。
オーバーレイを切らずに暗くしない方法ってありますか？

あと、今、WIN2ｋを使ってるのでわからないのですが、
将来WINXPで60fps再生したとき、オーバーレイを有効にしないと
できないと思うのですが、そのときも暗くなってしまうのでしょうか？
775 ：名無しさん＠編集中：03/08/06 04:29: >>774
http://www.canopus.co.jp/press/2001/mtv1000_review.htm

これ読んでモニタとデスクトップガンマを調整する、か
ffdshowをRAW ModeにしてLevalsで調節するか、か
Radeonを買うか。
776 ：775：03/08/06 05:24: Levelsね
777 ：slave：03/08/06 05:41: HTTPの知識もないし
自分が使わないﾊﾟﾀｰｿはよくわからないし
大体あの実験をやる気が・・・
Vmaker氏のﾍﾟｰｼﾞをﾌｧｲﾙ化しとくべきでしたね
誰か保存してないんでしょうか？
778 ：名無しさん＠編集中：03/08/06 11:55: ttp://www.archive.org/にもなかったな。。。
779 ：名無しさん＠編集中：03/08/06 12:01: 持ってるけど、どうしよう。いる？
780 ：名無しさん＠編集中：03/08/06 14:15: >>779
おながいします
781 ：名無しさん＠編集中：03/08/06 16:54: >>779
頼む
782 ：名無しさん＠編集中：03/08/06 18:25: >>779
よきにはからえ
783 ：名無しさん＠編集中：03/08/06 18:38: >>779
BlendClips (Avisynth plugin)
CutOff (Avisynth plugin)
もありますか？
784 ：名無しさん＠編集中：03/08/06 19:20: >>779
兄貴って呼んで良いですか？
785 ：slave：03/08/06 21:21: >>779
是非！是非！！
786 ：779：03/08/06 21:46: すいません、しばらくＰＣの前から離れてたもんで、、、

ていうか、本当にconvlist.htmlでいいんですよね？
なんかとんでもないボケをかましているような気がしてきました。。。

>>783 残念ながら見あたりません。
自分が持っているのは、ブラウザの履歴によると、2003年4月28日にアクセスしたときの
もののようです。チョット古い？
787 ：slave：03/08/06 22:07: >>786
個人的にはconvlist.htmlだけで結構です
788 ：名無しさん＠編集中：03/08/06 22:08: できればwakamelist.htmlもお願いしたいのだが。
789 ：名無しさん＠編集中：03/08/06 22:12: convlist.htmlはすぐにでもうpします。

>>788
探してみます。履歴にはアクセスした形跡があるんだけど、ものが見つからない。。
790 ：名無しさん＠編集中：03/08/06 22:17: 勝手にうｐしてもいいの？
791 ：名無しさん＠編集中：03/08/06 22:24: うｐしました。

http://up.isp.2ch.net/up/921f8fd5d0ef.zip

２ｃｈうｐろーだなのでお早めに。。
792 ：slave：03/08/06 22:36: >>791
いただきました
ありがとうございました
793 ：名無しさん＠編集中：03/08/06 22:41: >>788

ブラウザはネットスケープを使っているのですが、
ブラウザがクラッシュした時に、キャッシュも吹っ飛んでしまったみたいです。
保存しておけばよかった。。すいません（ＴＴ）
794 ：名無しさん＠編集中：03/08/06 22:43: >>793
すいません。
コンブとワカメをかけた、ただのダジャレで
そんなファイル自体存在するかどうかすら知りませんでした。
本当にあったのかな…？
なかったなら…申し訳ない…
795 ：名無しさん＠編集中：03/08/06 22:46: >>794
もちろん無いですｗ
お気になさらずにｗ

ただ、ホントに探していたgraphedit.htmlはネタじゃなくありません。。。
796 ：名無しさん＠編集中：03/08/06 23:08: 著作権を侵してる奴らがいるな
797 ：名無しさん＠編集中：03/08/07 20:17: >>796
この板の多くの連中がそうだな。
798 ：名無しさん＠編集中：03/08/11 18:14: 伸張されてるかどうかを見分ける方法ってないですか？
見ても色が濃いのか薄いのかわからんのです。
799 ：名無しさん＠編集中：03/08/11 18:25: モニタじゃなくてTVで見ればいいんだよ
800 ：名無しさん＠編集中：03/08/12 22:21: >>799
釣れますか?
801 ：名無しさん＠編集中：03/08/12 22:56: さっぱり食いつかないな。
スレてない奴いないかな？
802 ：名無しさん＠編集中：03/08/13 04:47: パクッ
803 ：名無しさん＠編集中：03/08/13 11:22: ネタじゃなくてマジなんですけど。
だって素人がYC伸張の話なんかわかるわけねーよ。
･ﾟ･(ﾉД`)･ﾟ･｡
804 ：名無しさん＠編集中：03/08/13 12:18: >>803
なら、このスレ最初から読んで出直してね。
805 ：名無しさん＠編集中：03/08/13 12:24: 素人がエンコなんてしなくていい
806 ：名無しさん＠編集中：03/08/13 15:02: 素人はウンコはしてもいい
807 ：名無しさん＠編集中：03/08/13 22:36: >>804
みんなそればっか言うんだよ。
読んでわからないから聞いてるのに。
そんな意地悪しないで下さいよ。マジで。
808 ：名無しさん＠編集中：03/08/13 22:39: ↑読んでわからないっていうのは、意味がわからないんじゃなくて、どのレスが正しいのかがわからないってこと。
だからテンプレ化して欲しいんです。
809 ：名無しさん＠編集中：03/08/14 00:24: >>808
ぢんさんが簡潔明瞭にまとめてくださってます。
http://www.pegasys-inc.co.jp/bbscgi/bbs/board.cgi?board=tmpgenc#topic11964
810 ：名無しさん＠編集中：03/08/14 05:18: >>807
それは意味がわかっていないんじゃないか。思考能力あるのか?
811 ：名無しさん＠編集中：03/08/14 22:08: >>807
このスレはYC伸張に関する知識を深めるためだけでなく
迷えるトーシロを導くスレでもある
自分のキャプ・エソコ手順を示せば誰かが答えてくれるよ
環境が変わったらまた訊きに来ればいい
オレはアク禁巻き添えでもう、レスできないだろうけど
（今回はラウンジクラシック経由）
812 ：名無しさん＠編集中：03/08/14 22:38: >>807
ヒストグラム見て画像を見ながら色補正するなら、BT601で出力するのが安全。
元が色については完全で補正がまったく必要なければ、ストレート使え。
（ただし編集ソフトの画面で見た目にはダメダメになるからね）
でもAvisynthでYUVで全て取り扱うのが良いだろうな
813 ：名無しさん＠編集中：03/08/15 00:39: >>812
BT601の意味がわからず、ググってみましたが、余計わかりません。

ITU-R BT.601 について
ttp://www.marumo.ne.jp/bt601/

伸張せずに出力するということでしょうか？
気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。

DVD2AVIの色に関する設定の組み合わせは

カラースペース＝RGB　と　RGB→YUV＝PCスケール
カラースペース＝RGB　と　RGB→YUV＝TVスケール
カラースペース＝YUV　と　RGB→YUV＝PCスケール
カラースペース＝YUV　と　RGB→YUV＝TVスケール

の4つがありますが、どれが正しいのかわからないんです。
目的は、DVDレコーダーで録画したものを編集して、VRF・SVCD・VCDなどのテレビ用のMPEGにすることです。
自分の目で見ればいいだろ、と言われそうですが、その自分の目があてにならないので。

それと、PCで見ると色がうすいですが、PCだからなのかYC伸張しないからなのかもわかりません。
814 ：名無しさん＠編集中：03/08/15 00:47: というか、このページ、

ttp://www.marumo.ne.jp/bt601/

>PC 上では YC 伸張・圧縮を行う方法が正しいものです。

なんて書いてありますが、このスレのどこかには「PCかテレビかは関係ない」みたいなことが書いてあります。
もうどっちを信じたらいいのか…。
815 ：名無しさん＠編集中：03/08/15 01:04: >>813
> 気になってるのは、DVD2AVIの動作と、そのプロジェクトファイルをTMPGEncに読み込ませたときどう扱われるのかということなんです。
それなら・・・

> カラースペース＝YUV　と　RGB→YUV＝PCスケール
> カラースペース＝YUV　と　RGB→YUV＝TVスケール
の２つは関係ない。
816 ：名無しさん＠編集中：03/08/15 01:15: ＞的は、DVDレコーダーで録画したものを編集して、VRF・SVCD・VCDなどのテレビ用のMPEGにすることです。

このケースはすでに例が出てるんじゃないの？
817 ：名無しさん＠編集中：03/08/15 01:24: ビデオチップがBT.601から伸張するものなら
データをBT.601準拠で作れば
「PC 上では YC 伸張・圧縮を行う方法が正しい」と
「PCかテレビかは関係ない」は両立する！

鑑賞用にPC用とテレビ用にスケールを違えてデータを作るのはｹﾞﾌｫ厨のやるこった。
818 ：名無しさん＠編集中：03/08/15 01:58: 難しく考えすぎ。
色はRGBで0～255の値で表される。
0～255を目いっぱい使って表現された画像を、さらに伸張したら-30～280とかになって
0～255を超えた部分が0とか255とかに変化してしまう。
これにさえ気をつけていれば問題はまあ起きないわけ。
（RGBストレート変換ってのは、0～255じゃなくて、基本は16～235の範囲でしか色を使いませんよって人向け）
819 ：名無しさん＠編集中：03/08/15 09:20: >>813
1,DVDﾚｺ(YUV記録)->DVD2AVI(PCｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無ﾁｪｯｸ)
2,DVDﾚｺ(YUV記録)->DVD2AVI(TVｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にﾁｪｯｸ)
どっちかでやれ
現状のDVDﾚｺはYV12しかないので内部YUV記録
DVD2AVIのﾌﾟﾛｼﾞｪｸﾄﾌｧｲﾙ経由でTMPGEncに食わすということはVFAPI経由
VFAPI経由はすべてRGBで処理される
（そのためDVD2AVIのカラースペースは意味を持たない）
ここでYUV->RGB変換がおきる
1,はｽﾄﾚｰﾄ変換　2,は伸張変換
どっちを使ってもｿｰｽの色空間はある程度保持される
（ｴﾝｺｰﾄﾞするかぎり完全に色空間を保持することはできない）
どっちも正しい
820 ：819：03/08/15 17:25: ｽﾏｿ
1,伸張変換 2,はｽﾄﾚｰﾄ変換
821 ：820：03/08/15 19:35: 伸張変換よりストレート変換の方が誤差が小さいというのは本当でしょうか？
822 ：821：03/08/15 19:43: あら、821の名前欄は間違いです。820さんごめんなさい。
823 ：名無しさん＠編集中：03/08/15 20:01: うーん…。
DVDレコ(16-235)→伸張変換(0-255)→CCIR601ではなく…に無ﾁｪｯｸ(16-235)
ということでしょうか？
最終的に(16-235)になるようにして、再生時に(0-255)に伸張されるような状態でいいんですか？
DVDレコーダーでの再生は勝手に(0-255)に伸張されるんですよね？
質問ばかりですいませんが。
824 ：名無しさん＠編集中：03/08/15 20:07: それと、VideoStudio4.0でエンコした場合、AVI→AVIとAVI→MPEGでは違う明るさでエンコードされてしまいます。
何故なんでしょう？
(AVI→MPEGだと元より明るくなってしまう)
825 ：名無しさん＠編集中：03/08/15 20:46: >>823
YUVで(16-235)という認識は間違い
まず、現状において目で見るためにはRGBにしなければならない＜重要
ﾃﾚﾋﾞだろうがPCﾓﾆﾀだろうが最終的にRGB光線になっている
ところが多くのﾃﾞｼﾞﾀﾙﾌｫｰﾏｯﾄはYUVで格納されている
そのためYUVを目で見るためのRGBにしたときのYUV->RGB変換公式の規定がいろいろある
DVDﾚｺにおいてはその規格はBT.601に準拠する
BT.601において再生時（目で見るための）のYUV->RGB変換公式はｽﾄﾚｰﾄ変換
このときRGBは(0-255)の値をとるが有効値は(16-235)
なぜならNTSC民生用ﾃﾚﾋﾞにおいて漆黒は16純白は235であるから
ところがPCﾓﾆﾀは漆黒は0純白は255であるため色あせてしまう
そこでYUV->RGB変換後に本来16になる数値を0に、235になる数値を255にしてしまう計算式がつくられた
これが伸張変換
どちらにしてもYUVが(16-235)というわけではない

でだ、最終的にMPEG変換するということはYUVに戻すということだ
ということは経過は兎も角ｿｰｽYUVと同じ色に出力YUVになればいい
厳密に言えばすべての過程でYUV処理すれば色変換誤差はcodecによるもの以外起きない
しかしTMPGEncは内部RGBだし、VFAPIはRGB入出力のみなので変換はさけられない

YUV->RGBだけを見ればどっちの式が誤差が少ないかはわからない
だってRGBにした後くらべてもどっちがｿｰｽに近いかわからないでしょ？
YUVそのままは見れないんだから
問題はYUV->RGB->YUVにしたときにどっちが・・・ってことだが
繰り返すなら兎も角一回くらいならたいしてかわらない
826 ：名無しさん＠編集中：03/08/15 22:53: >>825
なるほど。
とりあえず、

>1,DVDﾚｺ(YUV記録)->DVD2AVI(PCｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…に無ﾁｪｯｸ)

>2,DVDﾚｺ(YUV記録)->DVD2AVI(TVｽｹｰﾙ)->VFAPI経由->TMPGEnc(YUVデータをCCIR601ではなく…にﾁｪｯｸ)

この組み合わせさえ間違えなければOKですね。
ありがとうございました。
827 ：山崎渉：03/08/15 23:15: 　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
828 ：slave：03/08/17 00:23: ついにﾉﾝｻﾁｭﾚｰﾄAviutl完成
HuffyuvSよ安らかに・・・
829 ：名無しさん＠編集中：03/08/17 01:25: YUY2への変換時にYを16～235、UVを16～240の範囲に飽和させるかの設定を追加。
830 ：名無しさん＠編集中：03/08/17 01:59: slave さんは >>629 で次のように書きました。

＞意地でも直さないだろうな・・・KEN。
831 ：名無しさん＠編集中：03/08/17 02:09: このスレがKENクンの意地をやわらげたんじゃないの？
あきらかにおかしいものはおかしいから
832 ：slave：03/08/17 02:11: あの・・・それよりどうすればｻﾁｭﾚｰﾄできるんでしょう？
できないんですけど
833 ：名無しさん＠編集中：03/08/17 02:13: >>832
したいのかよ(w
834 ：名無しさん＠編集中：03/08/17 16:02: 217 名前：Socket774 ：03/08/17 15:45 ID:qrmB2F9/
nVidiaのビデオオーバーレイって、デフォルト画質が変ですよ（当方、FX5600 , 45.23 , AnalogRGB）
少なくとも、ドライバデフォルトでコントラスト９０％、彩度１１４％になっている時点でおかしい。
また、Yレベル16～235をRGBレベル0～251として表示しているので、少し暗め。

仕様通りのYUY2オーバーレイを行いたい方は
　明るさ120%、コントラスト・色相・彩度100%
に設定すると良いですよ。これでほぼ仕様通りの色になります。

こんな好き勝手な仕様を組み込んで、業界標準と言っているのだから・・・鬱。

218 名前：217 ：03/08/17 15:50 ID:qrmB2F9/
これを、普通の人にわかりやすく言うなら、
　「標準では黒く締まった色調が映える画質になっている」
とでも言えるのかしら？（藁　　メーカの宣伝文句的に良く書いたけど、映像屋さんとしては失格です。
勝手にイコライジングしないで欲しい。

219 名前：217 ：03/08/17 15:51 ID:qrmB2F9/
>>217
　すみません。入力ミス。以下を訂正
誤：また、Yレベル16～235をRGBレベル0～251として表示しているので、少し暗め。
正：また、Yレベル16～235をRGBレベル0～219として表示しているので、少し暗め。
835 ：nVidiaスレ217：03/08/17 17:48: あ・・・さっそく貼られてしもた（汗
836 ：nVidiaスレ217：03/08/17 17:52: ちなみに明るさ120%というのはわかりやすい値を選んだので、極める方は微調整よろしく。
837 ：名無しさん＠編集中：03/08/17 18:24: 私信御免
420いるぅ～？
書いといたよ。欠点スレおいで～
838 ：名無しさん＠編集中：03/08/19 22:41: 457 ：名無しさん＠編集中：03/08/19 22:05
>>448
>>451
>>456
Re: Ver.99バグレポート　流れ者 - 2003/08/19(Tue) 22:04 No.4252

上記検証で使用したcodecはHuffyuvではなくHuffyuvSでした。
Huffyuvでやり直したところ問題ありませんでした。
どうやらHuffyuvS側の問題のようです。
お騒がせしてたいへん申し訳ありませんでした。
839 ：名無しさん＠編集中：03/08/19 22:45: >>838
ついにslave(Vmaker)の息の根がとまったな(w。
HuffyuvスレでもSをほしがるヤシは金輪際いないだろうに。
840 ：名無しさん＠編集中：03/08/19 22:47: HuffyuvSが残していったもの、それは（ry
841 ：名無しさん＠編集中：03/08/19 23:13: 卵スレはネトラン者だらけだから信用できんな
842 ：名無しさん＠編集中：03/08/20 00:05: >>841
卯スレだよ
843 ：名無しさん＠編集中：03/08/20 00:11: 烏
844 ：名無しさん＠編集中：03/08/21 00:00: 途中まで読んだけど何がなんだかさっぱり稚内ヨ！
とりえあずエンコした動画をaviutlで読み込んでヒストグラムを表示したら
両端がカットされてなかったので下手に弄るのはやめときます・・・。

【コーデック】huffyuvS　Conbert to YUY2
　他の設定はデフォルト（Enable full size output-bufferのみonになっているます）
【エンコーダ】Aviutl 0.99
　設定はデフォルト
　「YUY2変換時に････飽和」off
　「YUY2フィルタモード」off

（脱兎
845 ：名無しさん＠編集中：03/08/21 04:16: slave=流れ者≠vmakerだろ
846 ：名無しさん＠編集中：03/08/21 05:29: >>844
99だろ？んじゃ
HuffyuvS捨てろ
Huffyuvにせい
Convert to YUY2やめれ
YUY2展開・圧縮にチェキ
847 ：名無しさん＠編集中：03/08/21 05:40: Aviutlスレからきました。
向こうで「YUV->RGB->YUVストレート変換は諧調がシュリンクされる」
って力説するヤシがいるんだけど、ホント？
RGB->YUVならわかるけど
YUV->RGB->YUVなら元のYUVがYUV色空間に収まるデータしか持たないんだから
シュリンクされない、と思うんだけど？
848 ：名無しさん＠編集中：03/08/21 13:13: スレ違いだがAviUtl99は、もう大丈夫なんでつか？
849 ：名無しさん＠編集中：03/08/21 13:24: 大丈夫でつぅ
850 ：名無しさん＠編集中：03/08/21 20:23: >[TMPGEnc Plus 更新履歴]
>2003.7.16/ Ver. 2.520
>MPEGデコーダに「CRI Sofdec」(TM)を搭載しました。こちらの機能により標準状態でのMPEG-2ファイルの入力が可能になります。
>搭載されたデコーダーでは、パソコン上でTVでの見た目に近い明るさ・色で表示しますので編集作業が容易になります。
>※CRI Sofdec Decoder 利用時は「設定」→「量子化行列」→「YUVデータを CCIR601 ではなく、Basic YCbCr で出力する」のチェックは外してください。

TMPGEnc内蔵のデコーダーは強制YC伸張
851 ：名無しさん＠編集中：03/08/21 20:27: TMPGEnc終わったな…
852 ：名無しさん＠編集中：03/08/21 21:54: っていうか、YUV入力できない時点で終っているでしょ。
853 ：844：03/08/21 22:04: >>846
御意に。それでやってみます。
854 ：名無しさん＠編集中：03/08/21 22:21: PremireがYUV処理をProで実装
Aviutlはついにサチュレートしなくなった
ネイティブYUY2であるCCE,Avisynthは当然問題なし
Dub系にはFastcompressがある

ホントTMPGEncとVFAPIがなぁ
どっちも堀やんけ
なんとかシル！！
855 ：名無しさん＠編集中：03/08/21 22:31: TMPGの3が開発中なんじゃなかったっけ？
きっとYUVに対応するでしょ
856 ：名無しさん＠編集中：03/08/21 23:16: 堀だからわからんよ
857 ：名無しさん＠編集中：03/08/21 23:43: TMPGEncServerもなかったことになってるしね
858 ：名無しさん＠編集中：03/08/22 00:39: 処理速度とYUV

せめてどっちかは対応して欲しいとこだが
最近のカノプ的な面白機能を目玉にしてくる可能性も
859 ：名無しさん＠編集中：03/08/22 22:09: >>858
多段パスがほしい・・・
860 ：名無しさん＠編集中：03/08/22 23:11: 名前：名無しさん＠編集中[sage] 投稿日：03/08/22 21:38
>>540
YC伸張スレ
キャプチャーボード上のチップはネイティブYUV処理のものが多い。
WindowsのCodecはサイズ圧縮を旨とするためYUV系が多い。
ところが動画処理系のフリーウェアにはRGB入出力系しか持たないものも多い。
そのためYUV->RGB->YUVが必要になるが
その際↑にあるように”ストレート変換”と”伸張変換”の二つの変換公式があり
RGB入力を持つアプリはどちらの変換公式を用いたRGBかを指定するオプションがあるのが普通。
ただし、そのアプリによって表現形式が異なるため初心者は非常に混乱しやすい。
それを説明したり情報交換しあったりするスレ。
の筈だが現在はストレート派と伸張派の戦場。
861 ：860：03/08/22 23:17: 戦場らしいから戦うか
BSDiLinkキャプしてM2v.aui(BT.709)にしてAviutlに読み込みノンサチュレートでHuffyuvYUY2
それをVirtualDubModで.avs colorYUY2(true)
有効領域外のデータあるじゃん
MPEGエンコードでレンジオーバーするのか？
レンジが狭まるならわかるが・・・
コンポーネントマスターに有効領域外データはないってホントかよ
862 ：名無しさん＠編集中：03/08/24 02:04: 不浄
863 ：名無しさん＠編集中：03/08/24 23:36: http://www.geocities.co.jp/SiliconValley-SantaClara/1673/

自作板のnVidiaスレでがんがってる人がいるんですが、
考え方は合っているのでしょうか？

上記サイトの推奨設定だと
BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
合っているとは思うのですが

詳しい人の意見も伺いたいです
864 ：名無しさん＠編集中：03/08/24 23:45: Aviutl v0.99+CCE Basicを使って、DVD-VIDEOを作る場合、

キャプチャ(YUY2) huffyuv+cce patch(YUY2) ->
->Aviutlで、YUY2読み込み,出力にチェック、飽和をオフ -> 編集 ->
->huffyuv+cce patch(YUY2圧縮)
->CCE (YUY2読み込みを試みる)

でいいですか？　Aviutlとhuffyuvの関係が複雑化してきて、さっぱりですよ・・
865 ：名無しさん＠編集中：03/08/24 23:48: >>863
MSの想定するYUVオーバーレイを基準にすればそれであってる。
ただし単純に
>BSplayerでもオーバーレイ有り／無しで色合いや明るさが同じになるので
>合っている
とはならない
非圧縮YUVで比較しないとCODEC、再生アプリ側の色彩調整の影響があるからね。
866 ：名無しさん＠編集中：03/08/24 23:50: >>864
ソース色空間および適用範囲を保持したいなら正解
867 ：名無しさん＠編集中：03/08/25 00:01: >>861
撮影した素材そのまま持ってきたとしても、
カメラの輪郭補正とか、例えばDVの圧縮ノイズ、
ついでに編集かましたときにカラコレしたりで、
範囲外に出ることは多々ある。
あからさまに潜ってたり飛ぶようなことは無いけど。
868 ：名無しさん＠編集中：03/08/25 00:26: >>865
thx!!

MSの想定（DirectDrowでYUV オーバレイ） = ITU-R BT.601

なんですよね？
869 ：名無しさん＠編集中：03/08/25 00:30: YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
各ビデオボードごとに表示が違ってくる。
870 ：名無しさん＠編集中：03/08/25 00:34: >>869
BSplayer等でオーバーレイを無効にした場合について書いたつもりだったのですが
どうでしょうか？
871 ：名無しさん＠編集中：03/08/25 01:44: オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
ソフトウェアでYUV→RGB変換することになる。
872 ：名無しさん＠編集中：03/08/25 05:59: >YUVオーバーレイはDirectDrowの機能だが、H/Wに任せたよ、ヨロシコ、って機能なので
>各ビデオボードごとに表示が違ってくる。

が

>オーバーレイを無効にした場合はDirectShowのカラースペースコンバータが
>ソフトウェアでYUV→RGB変換することになる。

なので
MSが期待するYUV>RGB変換は伸張変換

このスレは独自用語で議論が進みがちなのでわかりにくいが

>MSの想定（DirectDrowでYUV オーバレイ） = ITU-R BT.601

ではない。BT.601はストレート変換。伸張変換はMS・IBM・Appleの想定する変換。

なお、ハードウェアオーバーレイ=GDIに完全に一致するのはまずない。
”ちかくなる”だけ
理由は>>869
873 ：名無しさん＠編集中：03/08/25 06:03: また,”伸張変換はMS・IBM・Appleの想定する変換。 ”
なのでアメリカの規格にのっとっている。
NTSC-JにのっとればYUV-RGBへの伸張は

(16-235)->(0-255)ではなく

(16-254)->(0-254)になる

235以上が有効範囲外になるのはアメリカの話であって、
日本では254まで有効範囲。
874 ：名無しさん＠編集中：03/08/25 06:04: 訂正
(16-254)->(0-254)になる
↓
(16-254)->(1-254)になる
875 ：名無しさん＠編集中：03/08/25 06:38: じゃあ、これはウソですか？

IRE Setup +7.5
【あいあーるいー・せっとあっぷ・ぷらす・ななてんご】
輝度信号の黒レベルにセットアップレベル+7.5が付加されていること。
アメリカのNTSC機器では、黒レベルが0IREではなく、7.5IREに設定されている。
日本では輝度レベルを拡張する意味で、黒レベルは0IREになっている。
白レベルの基準はどちらも100IREのため、日本のNTSCのほうが輝度の範囲が広い(日本＝0～100、アメリカ＝7.5～100)。
アメリカのビデオテープを日本の機器で再生させると、全体的に黒が浮いて見える（白っぽくみえる）のはこの違いによる。
この違いを区別する為、ハイエンド向けキャプチャカードや編集ソフトには同じNTSCでも”NTSC（US)”と
”NTSC-JAPAN（又はNHK）”といった別々の表記がある。
876 ：名無しさん＠編集中：03/08/25 07:14: >>873
チューナーの設定をNTSC-MからNTSC-Jに変えると
明るさがアップするけど、この理由は何？
877 ：名無しさん＠編集中：03/08/25 07:24: >>876
>>875
878 ：名無しさん＠編集中：03/08/25 08:01: http://pc.2ch.net/test/read.cgi/avi/993130983/555n
879 ：名無しさん＠編集中：03/08/25 10:00: 結局

アナログ輝度（IRE）　米DTV規格　日本DTV規格　米PC規格　日本PC規格

　　　　0　　　　　　　　33　　　　　16　　　　　0　　　　　0

　　　100　　　　　　　 235　　　　 235　　　　255　　　　235？
　　　109　　　　　　　 ×　　　　　254　　　　 ×　　　　 255？

ということでしょ。日本のPC事情をどうするかが問題だな。
それとハリウッド映画を日本のDVDで見る場合、
33,235→16,254という伸長も必要なんじゃない？
それぞれのスケーリングに正式な名称をつけて、
どんな変換なのかが一発で分かるようにしてホスイ。
880 ：名無しさん＠編集中：03/08/25 10:19: +120IRE程度まではあるって聞いたけど？
ちなみにデータハンドリングには関係ないけど、下はSYNC LEVELまでで-40IRE (Color Burst信号は、-20IRE～20IRE)
それに、RGBで、1～254って聞いたことない。
(PCでは0-255フルに扱えるのが普通。1-254しか扱えないって専門の編集機器か何か？）

また、Y:16-254 -> 1-254にする場合、Y:16-235 -> 0-235にする場合、
UV(IQでも良いけど)はどのくらい伸張するの？
881 ：名無しさん＠編集中：03/08/25 11:29: >>880
ん？？何番が対象の発言？
＋120というのはアナログの場合かコンポジットの場合でしょ。
民生用のアナログカメラは、120IREとか平気で出すインチキっぽいのがあって、
顰蹙かってたなぁ。
コンポジットの場合は色振幅の最高は理論上～160IREくらい、日本の映像～133IRE、
米or古い機器など～120IREってのはあるけど。
何の話だろ・・・・？
882 ：名無しさん＠編集中：03/08/25 18:18: ＞また、Y:16-254 -> 1-254にする場合、Y:16-235 -> 0-235にする場合、
＞UV(IQでも良いけど)はどのくらい伸張するの？
この部分には俺も興味あるな？
計算式はどうなるの？
883 ：名無しさん＠編集中：03/08/25 20:21: >>882
デジタルメディア上での計算式なんてないんでは？
ヘタに計算式作っても誤差がでるだけでしょ
どうせYUVはRGBの色空間と1:1じゃないんだから
YUV>RGBはストレートにして
YUVにせよRGBにせよ15以下はサチュレート（16で飽和）
再生環境のキャリブレートは
YUV16が漆黒
YUV255が純白
でいいんでは？
884 ：名無しさん＠編集中：03/08/25 22:13: また難しい方向へいってしまうんですね。
885 ：名無しさん＠編集中：03/08/25 22:38: 16-245 -> 0-255はおかしい。16-235 -> 0-235 にせよとプロの方は言っていますが？
886 ：名無しさん＠編集中：03/08/25 23:03: 16-235->0-255を16-235->0-245だね。
でもプロの扱うどのソフトならそんな妙な変換を備えたものがあるんだろうか？
887 ：名無しさん＠編集中：03/08/25 23:16: >>872
返事が遅れましたがthx

話しは変わるのですが、
DOS/V magazine 03/18/15
にオーバーレイ画質とテレビ出力機能について特集が組まれており
*SMPTEカラーバー RGB(0,0,0)～RGB(255,255,255)をオーバーレイ表示して測定器で計測
というのがありました。

同じnVidia製品でも（ドライバのオーバーレイ設定が同じだとして）
NTSCエンコーダによってテレビ出力のセットアップレベルが全く違うようなので
ＴＶ出力を厳密に「NTSC-J」に合わせるのは難しそう（というか不可能）だと感じました。
888 ：名無しさん＠編集中：03/08/25 23:36: >>886
プロはストレート変換しか使わないよ。
889 ：名無しさん＠編集中：03/08/25 23:45: >>887
民生テレビ自体を完全キャリブレートすることすら困難だよ。
890 ：名無しさん＠編集中：03/08/26 00:05: >>889
891 ：名無しさん＠編集中：03/08/26 00:07: >>889
失敗・・・２重投稿ｽﾏｿ

でもせめて出力側だけでも規格に合わせたいです
892 ：名無しさん＠編集中：03/08/26 00:12: >>888
＞878 ：名無しさん＠編集中：03/08/25 08:01
＞http://pc.2ch.net/test/read.cgi/avi/993130983/555n

これプロの意見じゃないの？
893 ：名無しさん＠編集中：03/08/26 00:34: >>879
米 DTV 規格が違う

IRE　　米 DTV 規格
　7.5　　16
100　　 235
109　　 242

NTSC エンコーダーが、NTSC (US) か NTSC-J かの設定で IRE
レベル差を吸収するのが普通

もっとも、規格を読んだだけでの書き込みで、実際に US 向け
業務用機器を触ったり、作ったりしたわけじゃないけど
894 ：名無しさん＠編集中：03/08/26 02:04: >>893
109IREが242に対応するってところが分からん。
7.5IRE→16、100IRE→235の割りでいくと、
109IREは259とかに対応になるんだけど、
235を超えると線形性は崩れるの？
895 ：名無しさん＠編集中：03/08/26 03:10: IRE
http://dtv.myplanet.ne.jp/mototaka/DTV-gloss/dtv-i.htm
映像の、輝度レベルの単位。
日本では通常、0IRE＝黒、100IRE＝白のレベルを表すが、実際には、「白よりも白い」白が存在し、
120IRE位までを取り扱う。YUVの"Y"に相当する。

Vp-pの底(SYNC LEVEL)=-40IRE、BLACK LEVEL=0IRE、WHITE LEVEL=100IREとする単位で
1IRE = 7.14mVになる。

http://www.deetc.isel.ipl.pt/sistemastele/STd/arquivo/video/NTSC-PAL-SECAM.pdf
896 ：名無しさん＠編集中：03/08/26 03:22: NTSCビデオ信号タイミング規格(RS-170A)概要
http://elm-chan.org/docs/rs170a/spec_j.html

Final Cut Proでは、スーパーホワイトって名前で、109IREまで取り扱う。
897 ：名無しさん＠編集中：03/08/26 03:23: ●NTSC/YCテスト信号

カラー・バー ― SMPTEカラー・バー。
コンバーゼンス ― 14ライン／垂直、17ライン／水平。
レッド・フィールド ― ルミナンス・ぺデスタル：201.74mV。クロミナンス振幅：626.66mVp-p。
グーリン・フィールド ― ルミナンス・ぺデスタル：344.45mV。クロミナンス振幅：585.28mVp-p。
ブルー・フィールド ― ルミナンス・ぺデスタル：110.06mV。クロミナンス振幅：443.76mVp-p。
マルチバースト ― ホワイト・リファレンス・バー振幅：70 IRE。パケット振幅：60 IRE。ペデスタル：40 IRE。バースト周波数：0.5、1.0、2.0、3.0、3.58、4.2MHz。
ライン・スイープ ― 振幅：714.3mVp-p。周波数：500kHz～5MHz。
マーカ：1.0、2.0、3.0、4.0MHz。
ウィンドウ付パルス＆バー ― 2TパルスHAD：250±25nS。ホワイト・バー振幅：100 IRE。フィールド・チルト：0.5%以下。ライン・チルト：0.5%以下。リンギング：1%ピーク以下。
5ステップ階段波 ― 振幅：100 IRE。リニアリティ・エラー：1%以下。
ランプ／変調ランプ ― ルミナンス振幅：100 IRE。クロミナンス振幅：40 IRE。微分利得（DG）：0.3%（最大）。微分位相（DP）：0.3°（最大）。
クロミナンス・ノイズ ― ルミナンス・ペデスタル：50 IRE。クロミナンス振幅：100 IRE。クロマ位相：レッド。
クロミナンス応答 ― 50 IREぺデスタル上の2.58MHz～4.58MHzまで60 IREスイープ。
NTC7コンポジット― 100 IREバー、2Tパルス＆12.5T変調パルス、振幅40 IREのサブキャリアが重畳した90 IRE5ステップ階段波を組合せた複合信号。
フラット・フィールド ― 0、50、100 IRE。
マトリクス ― マルチバースト、クロマ応答、50 IREフラット・フィールド、クロマ・ノイズ、カラー・バー、NTC7コンポジットで構成されたマトリクス信号。
バウンス ― 振幅：0または100 IREフラット・フィールド、レート：1秒ハイ、1秒ロー。
898 ：名無しさん＠編集中：03/08/26 03:54: Menu window - NTSC Safe Colors
http://www.mediachance.com/dvdlab/Help/ntsc.htm
ここでは、safe areaを-20% ～ +20%で、-20IRE～120IREとなっている。

CAMCODERだと、50IREとか、80/85/90/95/100 IREとか、最高でも102IREぐらい？
around 110IREとか書いてる奴もあった。
899 ：888：03/08/26 05:37: >>892
再生環境のキャリブレートと中間処理のYUV>RGBは分けて考えるべき
大体、伸張変換公式だって本来は再生用（ただしアメリカ基準）
中間処理はストレートに決まってる(BT.601)
リンク先の”プロ”はプロ過ぎて”NTSC-J対応伸張公式”を実装したアプリがないことを
知らないんでしょ
900 ：名無しさん＠編集中：03/08/26 08:10: >>899
あの”プロ”はあのスレで一番エバってるね。
なんか徹夜明けのハイテンション状態で一気呵成に書き込んでるような．．．
プロなんだから、もっと余裕をもった気持ちで書き込んでほしいものだな。
901 ：名無しさん＠編集中：03/08/26 09:08: >>899
ピナクルのシステムは16-254のDV映像を、16-235で変換するよ。
これは235以上をクリップすると言うことではなく、
全体を圧縮する方式。したがって235の白は218になる。
ストレート変換だけじゃないよ。
でもって895～898はなに？新手の荒らし？
902 ：名無しさん＠編集中：03/08/26 09:31: >>901
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
903 ：893：03/08/26 09:32: >>894
109IRE の 242 ってのは計算ミス。指摘ありがとう。
108IRE が 254 だった。
904 ：名無しさん＠編集中：03/08/26 10:11: プロの書き込みにはイチイチ頷かされるんだが
実際問題我々下賎なキャプ厨には役にたたない
905 ：名無しさん＠編集中：03/08/26 10:32: >>901
それって複数回通すとどんどん暗くなっていくような気がするけど大丈夫なの？
906 ：名無しさん＠編集中：03/08/26 16:56: 最初の１回のみ縮退。でもその後はストレート変換で処理。
だからどんどん～ってことはないよ。
ストレート変換を基本にしながらも、
初回のレンダリング時は
メーカー独自の領域に丸めてしまうものが多いね。

でさぁ、902ってなに？なんか失礼なやつだなぁ！
907 ：名無しさん＠編集中：03/08/26 18:46: 自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
908 ：名無しさん＠編集中：03/08/26 20:21: なんかシッタカが闊歩しておるな。
909 ：名無しさん＠編集中：03/08/26 22:09: >>901=>>906
＞でもって895～898はなに？新手の荒らし？
これは>>894の「235を超えると線形性は崩れるの？」に対するレスだろ？
俺にとっては、895-898は非常に有益な情報だったよ。
もしこれが間違ってる／的外れってんなら、プロならプロらしくきちんと説明しろよ。
俺には、荒らし扱いする理由が全く見えないので、（895-898が全く意味無いと判断した）その理由が
非常に気に掛かる。
895-898への訂正意見とか反論とか、知識の出し惜しみせずに本当頼むよ。
（まさかレスする価値も無いスパムだとは言わないよね？）
910 ：名無しさん＠編集中：03/08/27 01:32: ノウホワイは後回しにしてノウハウの伝授をーーーーーっ！
911 ：名無しさん＠編集中：03/08/27 14:32: >>909って>>897とか>>907とか書いたやつだろうけど、
言語障害か何かだよな。まともなことばで返せない・・・
912 ：名無しさん＠編集中：03/08/27 14:39: >>907
１行でやめときゃいいのに
913 ：名無しさん＠編集中：03/08/27 14:44: >>901
>>906
>>911
┐(´～｀)┌
914 ：名無しさん＠編集中：03/08/27 14:55: おれにはチンプンカンプンだよ、って？
ごめんね、難しすぎて。
915 ：名無しさん＠編集中：03/08/27 15:05: なんか>>907 ＝ >>913が糞スレに仕向けてるぞ。
916 ：名無しさん＠編集中：03/08/27 15:19: >>901
>>906
>>911
>>915
┐(´～｀)┌
917 ：名無しさん＠編集中：03/08/27 15:29: >>913や>>916も　┐(´～｀)┌
918 ：名無しさん＠編集中：03/08/27 16:01: ┐(´～｀)┌ な病気が流行ってます。気をつけましょう！！
919 ：名無しさん＠編集中：03/08/27 16:03: >>913
>>916
>>917
>>918
┐(´～｀)┌
920 ：名無しさん＠編集中：03/08/27 16:57: でさ、ここの住人の人、↑こういうヴァカ放置しとくわけ？
結構キチガイだね。それとも外人さんかな？（藁
921 ：名無しさん＠編集中：03/08/27 20:40: 煽りは無視しろよ。それで良い事だろ。
俺もだんだん、
自分でも、プロにあるまじき、卑しいカキコだと思わんか？少し自省してみてはどうかね？
と思えてきたよ。

＞911 ：名無しさん＠編集中：03/08/27 14:32
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・

少なくとも、>>909はまじめな質問だろが、答える義務があると思わんのか？
922 ：893：03/08/27 21:30: むー 901 でも 906 でも無いんだが、あんまりなので。

>895-898 が非常に有益な情報だったと豪語する 909 にとって

>「235を超えると線形性は崩れるの？」に対する

自分なりに考えてみた結論はどっちなんだろう。有益だったのだから
結論が出せたはずだろうと思ってるのだけど。

私にとって 895-898 は「IRE100 を超える信号が放送局のマスターの
段階で存在する」という情報と、レベルとは殆ど関係の無い NTSC の
同期タイミングに対する情報が書かれてるだけにしか見えないんだ。

で、IRE100 を超える情報が放送局のマスターレベルで存在するって
のは既出だし、それを否定してる人はそんなに居ないように思えるわ
けね。

・既出の情報
・無関係な情報

を延々書き連ねてるようにしか見えないんで、895-898 はスパム扱い
されても仕方が無いんじゃないかな。

あと、-20 ～ 120 IRE ってのは色信号を重畳した後の、NTSC 信号で
の許容範囲であって、輝度のみで 120 まで使い切るのが正しいこと
だとか誤解しない方が良い。
923 ：名無しさん＠編集中：03/08/27 22:06: >IRE100 を超える情報が放送局のマスターレベルで存在するって
>のは既出

え？そう？？
ガイシュツはMPEG2-TSしかないんでは？
924 ：名無しさん＠編集中：03/08/28 00:02: 自分にとって既出だったら価値が無いってわけか。プロって観点がやっぱ違うな。
それでスパム扱いするわけ？
925 ：名無しさん＠編集中：03/08/28 00:05: 言葉足らずだった。
俺は、スパム扱いするくらいだから、待ちかっとるよキミ。
ただしくはこうだ。とか説明があるもんだと思ってたよ。
>>895のpdfや>>896のリンクはスゲー良かったよ。
926 ：名無しさん＠編集中：03/08/28 00:07: 895-898も、もうちょっとまとめて書けば荒らし扱いされなかっただけの話だ。
以上。
927 ：名無しさん＠編集中：03/08/28 00:09: >>897だって、俺には各色が何Vp-p(IRE)なのか判ってうれしい情報だったが？
928 ：名無しさん＠編集中：03/08/28 00:14: 素人が調べた情報を貶すより、玄人からきちんと情報だすのがプロの態度だと思う。
もうスパムだどうだって話はいいから、実際の話をだしてくれよ。
例えば、局に納品するものは、レベルをどの範囲で作っているのかとか。
（109IREとか出してるけど、こんなレベル許されないだろ？）
929 ：名無しさん＠編集中：03/08/28 00:23: あと、カメラ撮りから編集時のレベル調整じゃなくて、
（歪み補正とか色々あるだろうから、ガンマやニーポイント、ショルダーポイントで複雑に補正するんだろうけど）
俺たち、キャプチャユーザーにとっては、補正後の完成された画像を取り扱うわけよ。
その場合、俺たちはなるべくレベルはオリジナルに近づけたいと思ってるわけ。
そういう観点からも、レクチャしてくれよ。
930 ：909：03/08/28 00:37: ＞911 ：名無しさん＠編集中：03/08/27 14:32
＞>>909って>>897とか>>907とか書いたやつだろうけど、
＞言語障害か何かだよな。まともなことばで返せない・・・

俺が909を書いたけど、897や907は書いてない。いったい何処の部分で一緒にされたんだ？
俺の書き方が言語障害だってのはどの部分？
あなたがまともなプロの方だったら、内容はともかく、言語障害と断定したことに
納得できる説明または謝罪を要求する。
931 ：名無しさん＠編集中：03/08/28 00:55: だめだろう、あのプロは。
932 ：893：03/08/28 01:04: つーか私はプロじゃないのだがなぁ（少なくとも編集側の人間じゃない）
聞いた話レベルのことしかいえないけど、それでもいいわけ？

許容される輝度レベル：
・16 以下は絶対不可
・235-254 まではどこまで使っても OK

実際の輝度レベル：
・使ってる機材と使う人でピンキリ

というわけで、明確な基準はない。

あと、プロに過大な幻想を抱くのはどうかと思うぞ。ほんの１年前まで
当たり前のようにコンポジットマスターで DVD を作ってて、今なお HD
を D2 アプコンで放送してるような連中なんだから。
933 ：名無しさん＠編集中：03/08/28 03:59: そういや、プロと自称しているヤシが NTSC-J (0IRE) と NTSC (7.5IRE) の違いが
デジタル段階でも現れると思いこんでいたりするのにはちと驚愕するね。
934 ：名無しさん＠編集中：03/08/28 05:59: 自分が舌足らずなのに相手の読解力のせいにするスレはここですか？
935 ：名無しさん＠編集中：03/08/28 09:42: お前ら、そろそろ次ｽﾚのﾃﾝﾌﾟﾚとFAQを、まとめれ。
936 ：名無しさん＠編集中：03/08/28 10:46: アプリごとの特性
codecごとの特性
ビデオカードごとの特性
フィルターごとの特性

誰か纏めてﾃﾝﾌﾟﾗにしてくらはい
937 ：名無しさん＠編集中：03/08/28 12:13: ＞納得できる説明または謝罪を要求する。

２ちゃんでそれを求めてもなぁ・・・・・・
909がマジで謝罪もとめてるとしたら、けっこうバカかも。
それとも「プロ」煽ってんのかな？
おーい、プロよー、出てこーい！
938 ：名無しさん＠編集中：03/08/28 13:55: >>937
＞あなたがまともなプロの方だったら
と但し書きがあるので、出てきたら幸いだという思いがこもってると見た。
939 ：名無しさん＠編集中：03/08/28 13:58: >>933
そういや、NTSC-Jだから0IRE=0なんて主張していたのもいたな。
940 ：名無しさん＠編集中：03/08/28 14:27: 出て来ないからまともじゃない、って釣ってもねぇ・・・・・
なんせ２ちゃんだから・・・・
941 ：名無しさん＠編集中：03/08/28 14:38: 要するにこのスレでボスを気取っていた907の前に
ある日突然プロを名乗るツワモノが現れ、
危機を感じた907が追い出そうと必死、ということでいいでつか？
942 ：名無しさん＠編集中：03/08/28 15:01: >>941
ここのボスって誰？
907ってただの煽りじゃん。
釣り？
943 ：名無しさん＠編集中：03/08/28 15:03: >>941
このスレ的には、プロ大歓迎だろ。
ただ、プロなら傍若無人な態度をとっても良いってことにはならいだけ。
944 ：名無しさん＠編集中：03/08/28 15:57: >>939
NTSC-Jでは0IRE=16で、普通のNTSCでは7.5IRE=16ってこと?
945 ：名無しさん＠編集中：03/08/28 16:34: AviutlのYC伸長の始点ってどうやって選べばいいのか分からない
readmeにはデッキ等の機種によりけりって書いてあるけど
自分のがどうなのかを調べる方法が・・・
946 ：名無しさん＠編集中：03/08/28 17:01: >>945
ヒストグラム
947 ：名無しさん＠編集中：03/08/28 17:15: >>944
そ。あくまでアナログ段階の黒レベルの問題であって、ITU-R BT.601に従って
デジタル化した場合は黒レベルはNTSC-JだろうがNTSC-USだろうがPALだろうが16。
948 ：名無しさん＠編集中：03/08/28 17:20: 匿名板には自称プロが多数生息しています。
949 ：名無しさん＠編集中：03/08/28 20:25: >>932
許容される輝度レベル：
・16 以下は絶対不可(局によっては3IRE以上だったりする)
・235-254 はオーバーシュートしたパルス部分が出てる分には許容。
　全体的に飛ぶと局に納品断られる。
これにクロマが絡んでくるとまた厄介なんだけど。

あと、BSデジタルは制作費があまりもらえないので、
全てのコンテンツをHDでやれないのね。
地上派デジタルになったって、
しばらくはSDのアプコン主流で行くし。
950 ：名無しさん＠編集中：03/08/28 20:46: なんだ結局キャプ厨的にはＹ（１６－２３５）を基準にすれば十分ってことじゃない。
951 ：名無しさん＠編集中：03/08/28 21:29: ＞・16 以下は絶対不可(局によっては3IRE以上だったりする)
＞・235-254 はオーバーシュートしたパルス部分が出てる分には許容。

普通にTV番組では使われてる領域だよ
映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ
市販DVDでも余裕で使われてるしね
まぁ実写の話なんでアニメだと透過光くらいなのかもね
952 ：名無しさん＠編集中：03/08/28 21:41: >>951
そりゃ規格を知らん自称プロによる腐れオーサリングなソフトがあるってだけだ罠。
953 ：名無しさん＠編集中：03/08/28 21:46: >>952
いや、クライアントが納得して報酬を支払ってるなら立派なプロだろう。
954 ：名無しさん＠編集中：03/08/28 21:47: >>952
>>939ってことか。0IRE=0なんてオーサリングしてたら、そりゃ当然そういう
事態になるね。
955 ：名無しさん＠編集中：03/08/28 21:48: 15以下236以上の輝度レベルのピクセルこだわっていたslaveらアンチBT601派は
受信機によって歪まされた輝度レベルを「マスターに近い状態」と信じて有難がっていたわけだな。
956 ：名無しさん＠編集中：03/08/28 21:49: >>953
そだね。規格を知っている/知らないのとプロ/アマかは無関係。
957 ：名無しさん＠編集中：03/08/28 21:59: nyで落として焼いてヤフオクで捌いてるのもプロ
958 ：名無しさん＠編集中：03/08/28 22:11: >>955
HEY!X3のスタジオライブはHDD収録なんだがiLinkキャプすると
範囲外とか言ってる236以上に諧調が存在する。
iLinkキャプは送信されたストリームを記録してるだけだよ。
MPEGエンコーダのせいにするのか？
MPEG圧縮でレンジが拡大するというのか？

そもそもマスターに近い状態って理解してるのか？
iLinkならまだしも民生レベルで地上波の16以下235以上をマスター同等のレンジでキャプできるのか？
おまいが16だって信じてるものがマスターの16である保障はないよ。
959 ：名無しさん＠編集中：03/08/28 22:15: >>958
結局そうじゃない保障もない･･･という表現もヘンな気がするから
一般視聴者レベルでそんな保障を得る事は不可能に近いから
面白画質にならない範囲で好きなように補正すりゃいいって事じゃね？
960 ：名無しさん＠編集中：03/08/28 22:38: >>958
マジレスすると
フジ、特にHEYは異常にYが高い
961 ：名無しさん＠編集中：03/08/28 22:40: >>959
だよな。
iLINKキャプやDVDリップですら範囲外もへったくれもないんだから
規格そのものが現実にそってないんだよな。
それにしてもテレトのハロモニはなんとかして欲しいんだが。
範囲外とか色づけとか演出とかキャプ環境とか、
そういう問題じゃないくらい面白すぎる(泣
962 ：名無しさん＠編集中：03/08/28 22:43: >>960
日テレはYどころか全部高い。
テレ朝もひどいし。
NHKに合わせてテレビをキャリブレートすると
Mステは目が痛い。
これが現実なのね。
963 ：名無しさん＠編集中：03/08/28 22:48: >>961
ハロモニは輝度が高いとかそういう問題じゃないからな
どんなに輝度を低めにキャプしても飛んでる色は最初から飛んでる
放送する前から白飛びしてるってアホくさすぎ
964 ：名無しさん＠編集中：03/08/28 22:50: で、再圧縮するときは（そういう人も少なくないでしょ？）
送り出し側を尊重して面白いままにしておくの？
965 ：名無しさん＠編集中：03/08/28 22:54: >>964
>>963
白とびに関してはどーにもならないよ。
全体に薄暗くしたって意味ないし、
コントラスト下げれば不足気味の諧調が余計消えるし、
面白い物は面白いままなんだよ。
966 ：名無しさん＠編集中：03/08/28 22:58: タイミングが悪かった。
ハロモニじゃなくてHEYみたいなものの話。
967 ：名無しさん＠編集中：03/08/28 23:00: >>966
iLINK前提ならY値だけ下げれば諧調が破壊され
サチュレートすればソースが破壊される。
でもビットレート稼ぎたいからサチュレートしちゃうけどな。
968 ：名無しさん＠編集中：03/08/28 23:36: ハロモニの白飛びに悩まされてるモヲタは多い
969 ：名無しさん＠編集中：03/08/28 23:39: 白飛びはモヲタ対策なんだよ。
970 ：名無しさん＠編集中：03/08/28 23:42: ハロモニはたまにやたらと粒子の粗い？カメラがあって
肌が無茶苦茶汚く映るので萎える
971 ：名無しさん＠編集中：03/08/28 23:44: >>961
規格が現実に沿っていないのではなく、プロでも規格をしらないバカが多いってこと
なんだけどね…
972 ：名無しさん＠編集中：03/08/29 00:21: モーヲタ氏ねよ
973 ：プュロフォッショナル：03/08/29 00:34: 次スレッド立てようぜ
974 ：名無しさん＠編集中：03/08/29 00:58: >>946
ヒストグラムでどう判断するのか分からない・・・
975 ：名無しさん＠編集中：03/08/29 01:04: そりゃ、きちんとカラーバー入れないと判断つかない罠。
976 ：名無しさん＠編集中：03/08/29 05:20: >>951
DVDで白飛んで黒潜ってるとか言っとりますが、
マスターに入ってるカラーバーで校正した結果なら仕方ない。
そういうのは、マスター作ってきた制作会社が悪い。
漏れは客に判断仰ぐけどね。
おかしいカットだけカラコレかけられるけど、
そこはうちの責任じゃないので修正しない。

まあ、まともな作品で0IRE以下になることは無いけど。
977 ：名無しさん＠編集中：03/08/29 07:05: >>951
ちょっと待てや。

＞普通にTV番組では使われてる領域だよ
＞映画なんかだと0-15が見えないと真っ暗闇な場面とかあるよ

0-15が普通にTV番組では使われてる・・・と読めるのだが、
使ってるわけねぇだろ。おまえはちゃんと波形モニで監視してるのか？
0は同期ワードで使用絶対NGだから存在しているわけないし、
1-15はカラリメトリでクリップされるから送出されるわけがない。
どこからこんないい加減な話が出てくるのか疑問。
あんたどの局？どの時点で監視してるの？
サブキャリアの話とか言うオチはなしにしてくれよ。
978 ：名無しさん＠編集中：03/08/29 07:16: >>976-977
それは
>>201のコピペ
979 ：名無しさん＠編集中：03/08/29 07:34: 976や977のような話が201の後に出てこなかったことが、ちとカナスィ・・・
980 ：名無しさん＠編集中：03/08/29 09:05: >>976
プロとしてなっちょらん
981 ：名無しさん＠編集中：03/08/29 10:07: AviUtlサポート掲示板のYC伸張スレ
http://ruriruri.zone.ne.jp/aviutl/bbs/yybbs.cgi?mode=res&no=4339
982 ：名無しさん＠編集中：03/08/29 13:51: 誰かいい感じのスレタイで次スレ立ててくれ
これは初心者が行き詰まったり気付かないで放置しちゃってる問題だから
誘導しやすいように最初のほうで（できればテンプレで）まとめてくれ
俺はよくわかってないから無理なんだが・・・
983 ：名無しさん＠編集中：03/08/29 13:56: ここで熱心に虚しい議論してる連中、
脳内空回り的発言多すぎだぞ。
とりあえずハケモニは買ってくれ。
何事も目で確認するのが一番！
984 ：名無しさん＠編集中：03/08/29 15:28: カラーバーとかキャプチャすると普通に0-15を使ってたりせんか？
985 ：名無しさん＠編集中：03/08/29 15:36: セットアップバーの-4IREが使ってるだけ。
986 ：名無しさん＠編集中：03/08/29 16:54: >>984
まず、キャプチャ時にゲインが正しく設定できているか確認したほうがいい。
あと、カラーバーは確かに16以下を使っているけど、それは-4IREの部分だけ
なので0-5は使っていないはずだぞ。
987 ：名無しさん＠編集中：03/08/29 16:58: あ、いや全く無いみたいな話が上であったからさ
15以下が放送されることは普通にあると思うんだが違うの？
988 ：きっぱり：03/08/29 17:23: テスト信号以外、　な　　い　　。
989 ：名無しさん＠編集中：03/08/29 17:27: >>987
サブキャリとか言うオチは、なしにしてくれよ。
990 ：名無しさん＠編集中：03/08/29 17:28: 映像製作時にあった場合は放送時に切られるってこと？
「カラリメトリでクリップ」の意味が分からなくて困ってるんだけど
991 ：名無しさん＠編集中：03/08/29 17:33: >>990よ、
映像製作ではなく、映像制作だ。
プロに叱られるぞ
992 ：名無しさん＠編集中：03/08/29 17:40: MPEG2を再生するときに、明るい部分が黒く再生されてしまうんですが、
これって伸張に間違いがあるということでしょうか？
993 ：名無しさん＠編集中：03/08/29 17:42: ＞明るい部分が黒く再生
それはネガポジ反転が掛かっているからです
994 ：名無しさん＠編集中：03/08/29 17:44: >>987
アナログ信号だからデコード -> キャプチャしたときにリンギング等の影響で
0IRE以下の信号が出てくる場合はある。けど、これはあくまで受信環境の問題。
995 ：名無しさん＠編集中：03/08/29 17:45: >>987
お前のキャプチャボードの設定を確認しろ。
996 ：名無しさん＠編集中：03/08/29 17:48: >>993
馬鹿にしてますね。
それなら逆に暗い部分が明るく再生されるじゃないですか。
明るい部分が黒くなるだけです。
997 ：987=990：03/08/29 17:49: ないということは分かったのでできれば990に答えてもらえますか？
ただの確認なんですが
998 ：名無しさん＠編集中：03/08/29 17:49: >>993
この板に常駐している連中って、皆、不親切だし、独り善がりだし、偉ぶってるし、ドケチだし、ひねくれてるし・・・
なんか実社会において著しく他人とのコミュニケーション能力に欠けてる社会生活不適応者の典型の集まりって感じがする
嫌われ者で笑い者で引き篭もり（若しくは、それに相当する）のヲタばっかなんだろうな、ｷﾓｯ!
999 ：名無しさん＠編集中：03/08/29 17:51: ＞馬鹿にしてますね。
うん。よくわかったね。
＞明るい部分が黒く（＝0IRE）なるだけです。
そりゃ故障だ。
1000 ：名無しさん＠編集中：03/08/29 17:52: やったあああああああああああああ！！！！！
1001 ：１００１：Over 1000 Thread: このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

276 KB

★スマホ版★ 掲示板に戻る全部前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)