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

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

【激安】玄人志向SAA7130-TVPCI【高画質】

1 :名無しさん@編集中:02/10/14 15:29
4000円以下で買える外部入力ナイスなキャプチャボードのスレ
http://www.kuroutoshikou.com/products/tvcuner/saa7130.html

玄人志向SAA7130-TVPCIとカノープスMTV2000のキャプチャ画像比較
セットアップ方法など有益な情報もあり必見
http://www.geocities.co.jp/Hollywood-Screen/4533/


87 :名無しさん@編集中:02/10/15 06:25
>58
>Cb、Crも本来は16-240の範囲なのに0-255になっているよ。

>あと、本来のデータとしてみたい場合、拡張色調補正でPC->TVスケールに
>チェックを入れるとみられる。

だから、それは自分がそう言う風(0-255のスケールで)に取りこむように
設定してるからでしょ?



88 :名無しさん@編集中:02/10/15 06:26
つーか、PCモニタはRGBしか受け付けないから、OSもRGBにしか表示は対応してない。
特殊用途だといろいろあるみたいなんだけど、、(32ビットRGBがあると聞いた。
人間が認識できないのが欠点らしいが。)

89 :58:02/10/15 06:43
>83
>これをaivutlで見ると、実際のデータは約16-235の範囲になっているのに
>aviutlでは勝手に伸張して0-255になっている。
これ、おかしいわ。

AvisynthのPlug-inやふぬああのヒストグラムはYUVの値を表示できるけど、
aviutlはYUVの値としてはみれないって事ね。

>87
一応、YUV 16-325で調整してあります。
YUV->RGB変換の時に、どう変換されるかってこと。
YUV 16-325がRGB0-255で変換されればYC伸張されているし、
YUV 16-325がRGB16-235に変換されればストレート変換されているって事。
で、aviutlはストレート変換ができないので、16-235のスケールで調整しても
無意味だといいたいわけです。

とりあえず、落ち。

90 :58:02/10/15 07:06
>YUV 16-325
YUV 16-235の間違いです。

91 :名無しさん@編集中:02/10/15 07:27
AVIUtlで0-255に伸張されたままプロジェクト保存して、それをTMPGEncで
読み込んでDVD用MPEG2に出力してるんだけど、これだと何かマズいかなぁ。

92 :名無しさん@編集中:02/10/15 07:29
>58
過去スレを良く読んでください。


93 :名無しさん@編集中:02/10/15 07:33
>91
PC上で見るなら問題ないと思う。
ただ、テレビで見ると黒潰れや、白飛びした映像になってる
可能性があるかもしれない・・・と思う。

あと、Aviutlは読みこんだ時点では伸張も圧縮もしていないと思う。



94 :名無しさん@編集中:02/10/15 07:34
>>89
あふぉ発見
ストレート変換できるよ

95 :名無しさん@編集中:02/10/15 07:42
58は新でくださいうざすぎです

96 :名無しさん@編集中:02/10/15 07:46
つーか、拡張色補正で良いじゃん。って結論じゃなかった?

多分過去ログで散々もめたの俺だけど。(規格引っ張り出した奴)

97 :名無しさん@編集中:02/10/15 07:58
>96
拡張色補正使ってるの?
Y/C伸張フィルタのほうが楽じゃない?

ちなみに、俺も過去ログで発言してたYO!

98 :名無しさん@編集中:02/10/15 07:58
>>93
伸張前に16-235、伸張済みで0-255に調整して>>91をやってるんだけど
白飛び黒潰れどころか、若干コントラストが足りない気もするし・・・
なんだかようわからん

99 :名無しさん@編集中:02/10/15 08:06
>97
漏れの発言じゃないけど、誰かが

NTSCの情報は16-235以外も来てることが多いので、規格通りのYC伸張だと
うまくいかないこともある。

と発言してたYO。
アナログ信号だから、地域や家庭(アンテナとか)でも違いが出そうだNE。

100 :名無しさん@編集中:02/10/15 08:09
>98
なにで見ているのかと、何を基準としてコントラストが足りないのかを
言わないと、反応付きにくいと思うYO。

101 :名無しさん@編集中:02/10/15 08:24
>>100
ごめん。
>>91の方法で焼いたDVDを民生用プレイヤーで再生してTVで見る場合ね。
0-255の色空間を使った場合だと、白飛び黒潰れが起きるハズなんだけど
むしろ全般的にコントラストが足りない感じで、黒部分のモスキートノイズが
目立つので、何か設定が間違ってるのかなぁ、と感じた次第。
TMPGEncの量子化行列タブで「YUVデータをCCIR601でなくBasicYCbCrで出力」の
チェックは外してあります。

102 :名無しさん@編集中:02/10/15 08:35
>101
自分もそう感じてるYO!
でも、テレビがどの値で白飛びOR黒潰れするかは
自分で確かめるしかないYO!

一応規格通りだから、たいていのテレビでは白飛び黒潰れが起きないと思うけど
誰かが、言ってたように、テレビの性能が良くて16-235以外でも
表示されてる気がするYO!



103 :名無しさん@編集中:02/10/15 08:39
>>102
にゃるほど、ありがとう。
もうちょっと色々試してみて、何かあったらまた書き込むYO!

104 :名無しさん@編集中:02/10/15 08:40
今時のBSデジタルいける奴だと黒とか余裕あるYO
SonyのWEGAとか根性あるYO。色温度も6500kだから、昔の9300kと比較すると
暖色系で淡く見えるYO。

105 :名無しさん@編集中:02/10/15 09:43
>>103
ちょっとテストしてみた。

(1) AVIUtlでカラーバーAVIを読み込み、16-235から0-255に伸張後、プロジェクト保存
(2) TMPGEncでDVD用プロファイルを使ってプロジェクトを読み込み、MPEG2に出力
(3) DVD2AVIで(2)のMPEG2を読み込みYUVのまま(伸張せずに)AVIに出力
(4) (3)のAVIを再びAVIUtlで読み込む

すると、(1)で0-255に伸張した筈なのに、(4)では(1)と全く同じ値になった。
逆に、(1)で拡張色調補正を使ってPC→TVスケールに補正をかけてプロジェクト保存すると、
(4)では16-235とはならず中央付近に圧縮された(コントラストの甘い)ヒストグラムとなった。

以上のことから、AVIUtlでは伸張後のデータをTMPGEncに渡すのがいいみたい。
また、伸張しないままの場合は、TMPGEncで「Basic YCbCrを使う」にチェックを入れると
(4)で正しいヒストグラムになるようです。

106 :名無しさん@編集中:02/10/15 09:52
>>105


(2) TMPGEncでDVD用プロファイルを使ってプロジェクトを読み込み、MPEG2に出力

この時点でAviutlに読み込ませるとデータはどうなってるか
の報告お願い。

107 :名無しさん@編集中:02/10/15 09:55
>>105
追加。
(1)を省いてAVIをそのままTMPGEncに渡しても、同様の結果になった。
AVIUtlは、読み込み時に伸張するコーデックは書き込み時に再圧縮かかるから
OKというわけかな?

108 :名無しさん@編集中:02/10/15 09:59
>>106
AVIUtlで保存したプロジェクトをそのまま読み込んでも同じことなので
AVIに出力してから再び読み込んでみた。
結果は伸張したまま出力してもAVI上は伸張されていない。(>>107が理由)
だから、伸張したものを拡張色調補正でTVスケールに圧縮してから出力すると、
二重に圧縮がかかることになってよろしくない、というわけらしい。

109 :名無しさん@編集中:02/10/15 10:02
>>106
あ、なるほど、TMPGEncでプロジェクト保存したものを再びAVIUtlに持ってくるとどうなるか、
ということだね。これでも正しいヒストグラムが表示されたよ。

110 :名無しさん@編集中:02/10/15 10:10
AviUtilは出力しないと、フィルタ後の画像は、プロジェクトに反映されないと
いう事?

一応昔からの問題(仕様)で「色に関しての補正は、フィルタ順に関わら
ず一番最後に実行される」というのと関係ありそうだね。

あと、Verいくつ?

111 :名無しさん@編集中:02/10/15 10:13
0-255に伸張してもMPEG圧縮の段で16-235に圧縮される。
で、デコードの際にデコーダーやビデオチップによって0-255に伸張される。
でもストレート変換で表示するビデオチップもあるので注意。

下は堀さんの書き込みから
-------------------------------------
「YUVデータをCCIR601ではなく、Basic YCbCrで出力する」のオプションは
RGB->YCbCr 変換するときの変換式を切り替えています。

ソースがCCIR601に準拠していない一般的なRGBデータの場合、
  チェックしない:RGB(0-255) を YCbCr(16-235) に変換する式が使われます。
  チェックする :RGB(0-255) を YCbCr(0-255) に変換する式が使われます。

ソースがCCIR601に準拠している場合、
  チェックしない:RGB(16-235) を YCbCr(30-218) に変換する式が使われます。
  チェックする :RGB(16-235) を YCbCr(16-235) に変換する式が使われます。

となります。

RGBデータをCCIR601準拠のYCbCrデータ(16-235)に変換する必要がありますので
Canopus DV Codec のようなソースの時点で既にCCIR601に準拠している場合は
チェックするのが正しいです。逆にCCIR601に準拠していないソースの場合、
チェックしないのが正しいです。
-------------------------------------



112 :名無しさん@編集中:02/10/15 10:30
111 神
Mpeg圧縮する時点で、TmpgEncだと
”YUVデータをCCIR601ではなく、Basic YCbCrで出力する”
チェックしない→ストレート変換
チェックする→伸張圧縮変換

って事か、、、
TV出力用をまとめると
・AviUtilで、TV用に16-235用に補正してあればTmpgEncでは”チェックしない”
・AviUtilで、TV用に16-235用に補正していなければ(RGBの0-255なら)Tmpg
 Encでは”チェックする”


113 :名無しさん@編集中:02/10/15 10:39
>>112
逆。

114 :名無しさん@編集中:02/10/15 10:41
>>112
違うだろ。
チェックしない→伸張圧縮変換
チェックする→ストレート変換

RGB(0-235)で作成していれば、チェックする。
RGB(0-255:通常)で作成していれば、チェックしない。

115 :112:02/10/15 10:41
>113

113の言う通り逆だね。スマソ。

116 :名無しさん@編集中:02/10/15 10:44
111の後半はテンプレ行きにしよう。

117 :名無しさん@編集中:02/10/15 10:45
>>110
>>111
Verは0.98dです。

もうちょっとテストしてみますた。
プロジェクト保存してTMPGEncに渡した場合は>>105の通りの結果になる。だけど、
一度AVIに書き出してからTMPGEncで読み込んだ場合には、これと違う結果になった。

具体的に言うと、>>111のチェックを外して出力すると、>>105の(4)で読み込んだときに
中央値に圧縮された(コントラストの甘い)画像になってしまう・・・。

結局、以下の方法でやると正しい結果が得られるみたい。

・AVIUtlからTMPGEncにプロジェクトを渡すときには0-255が渡されるので、>>111のチェックを外す。
・AVI経由で渡すときには、0-235に圧縮されているので>>111のチェックを入れる。

でもなんか不安なので、皆さん追試頼みます。

118 :名無しさん@編集中:02/10/15 10:49
というわけで>>107はテストミスなので無視してくらさいスンマセン

119 :名無しさん@編集中:02/10/15 10:52
>>117

>・AVI経由で渡すときには、0-235に圧縮されているので>>111のチェックを入れる。
0-235じゃなくて16-235だね。これもスンマセン

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

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