ビデオカードで動画のインターレース出力は可能か

普通のビデオカードでテレビへインターレース出力(60フレーム)は可能なのでしょうか。

H+スレの241さんの意見を検証するスレッドです。
関係ないスレを荒らしてうざいのでここでやって下さい。

参考スレ
http://cheese.2ch.net/test/read.cgi?bbs=avi&key=984442222
http://cheese.2ch.net/test/read.cgi?bbs=avi&key=996118424

誰か実験してやれよ。適当にテストパターンの動画作ってキャプれば
終わりだろ。
ついでに、セットアップIREが0か7.5かも実験してくれ。

WinTVのファイル以外でお願いします。

俺的には「動画のインターレース出力は可能」という方向で
話が進むことを期待したい。できるとしたらG400だけなのか
それとも汎用的な手法があるのか。

いいだしっぺのひとはH+もG400も持っていないそうです(藁

>>3
なんで？

>>3
WinTV PVRに限らず、キャプチャして作ったファイルなんか信用
するなよ。
Windowsのペイントかなんかでテストパターンを2枚描いて、
2枚が交互に入れ替わるAVIにして、
TMPEGencでソフトエンコして、
ちゃんとしたデータになってることを確認して、
HW+とG4x0で出力、
キャプチャ。
これで終わりだ。

Weaveはインターレースをそのまま出力するのではなくて
れっきとしたデインターレースの手法の一つです。>勘違いしている人たち

そもそもビデオカードのメモリ構造自体が飛び越し走査(インターレース)とは
無縁な構造なのでインターレースのままデータを受け付けることは不可能です。
メモリに格納された時点でいったん情報は失われているので
テレビに出す時点でそれを復活させることも当然不可能です。

ただし、ビデオエンコードチップときちんと連携する専用ソフトなら可能でしょう。
今後はテレビへのインターレース出力が可能なことをセールスポイントにする
ビデオカードも出てくるのではないでしょうか。

>>8
何の関係があるの

>>7
>ちゃんとしたデータになってることを確認して、
>HW+とG4x0で出力、
>キャプチャ。
キャプチャ信用出来ないんなら何でキャプチャするのさ？

>>10
HW+とG4x0の両方を持ってない奴に、証拠として見せるため。
自分で確かめるだけなら、モニタで見てわかるテストパターンを
描けばよし。

この板オモロイなあ。「男の板」って感じ。
カオスな雰囲気がとっても良い。ウソがないよね。

心おきなく検証するはずのH+スレの241はいずこ？

“ビデオカードでテレビへインターレース出力”
うーん。言いたいことは判るけど、それが理想的にできたら
3000万円のスキャンコンバーターはなくなっちゃうでしょ。
馬力的にはかなりイイセン行ってるんだけどねー。
そういえば次世代デジタル放送規格の策定で、マイクロソフト＆
その他が提唱してた規格が通れば、違った意味で可能だったかも。

>>7
＞Windowsのペイントかなんかでテストパターンを2枚描いて、
＞2枚が交互に入れ替わるAVIにして、

2枚がまったく違う画像なら、
微妙な変化でないから、はっきりするな。

関係ないけど、ＭＴＶ用のＴＶ出力サブボードって出るの？

テストパターンどうぞ
http://www.geocities.co.jp/Hollywood/7150/test.mpg
前にGeforceMXとH+の出力を比較するために作ったやつがあったので

ちなみにこの結果は
H+はきちんとインターレースで出力してて、高い解像度感があったけど、
Geforceは縦方向の解像度が半分しか出てなかった（TopフィールドとBottomフィールドが合成された感じ）
これデスクトップの文字とかがちらつかないようにするためにやってるんだと思う
というわけで、Geforceの動画の出力は糞

G400の出力がどうなるか気になります

久々に面白いな。ココ

ちょっと質問して良い？

インターレースって何？

インターレースマンセー。
プログレッシブ逝ってよし。

http://www.google.com/search?q=%83C%83%93%83%5E%81%5B%83%8C%81%5B%83X&hl=ja&lr=

>>16
お約束ですが、Geforceの時はWEAVEにしてるよね？
念のために聞くけど。

テスト用のファイルは
縦480のMPEG1だからWEAVEとか関係無いべ
まあ、WEAVE状態のファイルだからいいかな

俺は普段MPEG2はつかってないからこれだったけど
MPEG2のほうがテスト用としては最適だったかな

>>22
WEAVEに設定しないと駄目だよ。
WEAVE状態のファイルである事は当然として、
出口でアウトです。

それと、うちではリピート再生が効かないけどなんでかな。

フリッカーフリーフィルタが有効になっているんじゃない？
このフィルタは上下方向にぼかすから、結果としてTopフィールドと
Bottomフィールドが混ざります。

あと動画がスケーリングされることなくテレビ出力されることが
必要かな。デスクトップがテレビの枠内に収まって表示されるように
調整出来る機能があるよね？これがインターレース出力では邪魔になります。

MPEG1もインターレースできるんだ。しらんかった。

Geforce2MXとTWCC(24のようにならないようにオーバースキャンしてテレビ表示するソフト)
ではやはりH+の方がかなりきれいに見えました。
当然といえば当然なんだけどね。

>>23
MPEG1にはWEAVEなんか関係ない。さらに>>8も見るべし。

>>22
それはインターレースじゃなくてコーミングの「絵」が入っている
29.97fpsのプログレッシブ映像でしょ？
MPEG1ではインターレースのムービーは作れないよ。
weave状態になってる＝インターレースではないので念のため。
やっぱりMPEG2でちゃんとインターレースにして圧縮しないと。

Weave=インターレースではないのだから
どうやってもインターレース出力できないと思うんだけど。
専用ソフト誰か作れば？

>>26
あんた、８を書いた人？
痛すぎる、どうにもならんよ。

＞MPEG1にはWEAVEなんか関係ない。
って言ったって、
あんたの作ったファイルは、縦480の規格外MPEG1でしょ。

あんたは理屈を理解できないんだから、
つべこべ言わずにちゃんとWEAVEで出てる事を確認してから出直して来い。

というかやっぱり、
あんたはHW+スレからのアホなHW+信者だから、もう来なくていいよ。

俺の見たところでは

GV-MPEG2/MEG-VC2 > HW+ > G400

G400は動きが引っかかる。HW+は画質がそれほど良くない。

結論としてはできないってこと？

>>30
環境や設定を書かないと。
特にソフトデコは。
そうしないと、このスレの存在価値もないよ。

持ってるのはMEG-VC2とHW+とG450でG400やI/Oのは持ってないからわからないけど、
画質だけならダントツでMEG-VC2が一番だよ。次HW+で、450は動きも発色もHW+より落ちる。
ちなみに全てVC2でTVをキャプチャしたファイルね。
CPUはAthlon1.1Gでソフト再生はPowerDVDとWinDVD。

んで便利さではG450がダントツで便利。DirectXのストリームを流せるから
専用ソフト以外にメディアプレイヤーなどでもTV出力できる。

HW+はG450ほどではないけどそこそこ便利。そしてちゃんと調節すればHW+との差は僅差。

MEG-VC2は動きも自然だし発色やシャープさもHW+以上で画質だけならダントツだけど、
HW+と違い細かい調節がまったくできないし、使いにくい専用ソフトからしかMPEG再生できない。

VC2は自分自身で撮ったMPEGしか再生できないしDVDも再生できないってことで録画時の確認専用。
キャプチャしたファイル見るときは細かく調節したHW+で、他はG450です。
どれかひとつにできなくて全部使ってます。

使いやすくて画質きれいなTV出力機能のあるボードがぜひともほしいですねぇ。
確かGV-MPEG2はVC2と同じチップ使ってるから、
もしGV-MPEG2が使いやすいのならHW+より良いかもしれません。

間違い。画質僅差はHW+とVC2

問題を摩り替えるのはやめてください。

>>35
俺に言ってるの？
俺はインターレースがどうだとかいうことはわからないので、
あとは他の人に任せます。実験だけならできるので必要なら
召集してください。それではあとはROMります。

>>33
＞ソフト再生はPowerDVDとWinDVD。

両ソフトとも、WEAVEになってる？
できれば、パソコンモニター上でも確認して欲しい。

>>26
＞縦480のMPEG1だからWEAVEとか関係無い。

”縦240”のMPEG1なら、26 の言うとおりWEAVEとかは関係無い。

しかし、サンプルは”縦480”のMPEG1。
うちのパソコンモニターでも変化があった。
WEAVEとBOBで。

関係無いかどうか一目瞭然だから、自分の目で確かめたら。

>>36
32 だけど、35 じゃないよ。

俺はWEAVEって何ってレベルなんですが、
G450の場合ゆっくりカメラがパンした場合などに
どうしても動きが引っかかります。初めはコマ落ちかと思ったんですが、
どうやっても直らないし、そもそもモニタの方ではきれいにスクロールしてるんですよ。
TV出力だけスクロールががたがたになる。
これ、直せるのでしたらHW+外せますので、まともにする方法教えてください。

>>40
WinDVDって、
WEAVEとかBOBとか設定できる場所ない？

とにかく、WEAVEに設定するとコーミング（くし型ノイズ）が発生します。
BOBにすると、コーミングがなくなりますが、インターレース情報が失われている為、
テレビモニタでは、滑らかな表示が出来なくなります。

もう出来ないってことでいいんじゃないの？
いつまでやってても時間の無駄。
だいたいウダウダ言っているけど出来たやついるの？

だからWEAVEで出力できたからってインターレースにはならないんだよ！！
本当にこの板バカばっかりだな。もうちと勉強してからいろいろ言えや！！

カノプのSSH-HDTV使ってプログレッシブで見ればいいじゃん
これだけこだわりのある連中なんだからプログレ対応TVくらいもってるだろ？

>>41
BOBとWEAVE切り替えてみましたが、
くし状のノイズが発生するだけで
スクロールのがたつきは変化なしです。

>>41
BOBとWEAVE切り替えてみましたが、
くし状のノイズが発生するだけで
スクロールのがたつきは変化なしです。

>>46
それは、PowerDVDとWinDVD、どちらを使いました？
PowerDVDは、スケーリングが変な気がするし、
ソフトの合性とかがあるかも知れません。

ここで、安定した環境で検証するのは難しい気がするし、
メディアクルーズでの成功例もあるから、
個人的には、検証はMTVスレで続けた方が良いような気がしています。

>>43
あんたなりの答えが出ているなら、
初めからこんなスレッド作るなよ。邪魔くさい。

あんたが居たら検証がやりづらいこと、このうえ無しだ。
こんな隔離スレッドで、あんたと戦うのは御免蒙る。

>>48
はいはい、自分の糞スレに帰ってね（ｗ

>>27
コーミングの入った絵でいいんですよ。
ビデオカードがTopフィールドとBottomフィールドが交互に入り混じったプログレッシブ映像を
2枚のフィールドに正しく分離させて出力してるかどうかを確かめるためには。

>>29
MPEG1のファイルを作ったのは俺だからね
16,22でしか書きこんでないです

>>38
WEAVEはデインターレースの手法なんだから
俺の作った動画（MPEG1だからプログレッシブ）には関係無いよ
変化があったってのはそのDVD再生ソフトがおかしな処理をしてるせい
メディアプレーヤーで再生してくれ

>>23
ややこしいからメディアプレーヤーで再生してﾖ
あと、うちでもリピート再生が効かないけど
ごみ箱の中から探してきたものだからだと思う（藁
他にもいろいろ作ったんだけどあれしか見つからなかった

>>50
デインターレースの手法という表現は微妙だな。

http://support.cli.co.jp/faq.asp?ID=124
この設定画面では、

＞ノンインターレース処理をしない（Weave）
となっているし。
（ノンインターレース＝デインターレースでしょ。）

とにかく、そんな表現方法にこだわらないで、
WEAVEはインターレース情報を残しているんだから、
元のインターレースに復元可能です。

縦480を正確に再現するには、Bobでは不可能だし、
MPEG1の縦480サンプルは、環境に左右されるので止めた方が良いと思うよ。

://www.flashbackj.com/EchoFire/index.html

ウチの環境ではMediaCruiseを使っても
映像がぶれたりスクロールがコマ落ちみたいになるよ。(G400DH Ver.5.51)
それからBobとWeaveは
http://ascii24.com/news/columns/10100/article/1998/12/10/621041-000.html
> NTSCなどインターレースのビデオをノンインターレースに変換する2つのメソッド
>（乱暴な言い方をすれば、Bobは1フィールドベースに補完でフレームを作り、
> Weaveは2フィールドを合成してフレームを作る）
なんだそうな。

G400のTV出力(DVDMAX)はDirectXのストリームを横取りすることで実現されているが
DirectXのムービー側がノンインター前提なので、
どうしてもインターレース→ノンインター→インターレースと変換が行われるのでは？
BobとWeaveはインターレース→ノンインター時の話でノンインター→インターレースは関係ないでしょ。
そもそもこういう変換が行われること自体が問題なんだし。

>>54
プログレ、オフにした？
パソコンでは、コーミング出てる？
それと、>>3のような事は無いよね？

>>56
人に疑いかける前に自分は出来てるのかよ？

>>57
というか、みんな環境書かないね。
こんなんで検証になんの？

>>55
正解。
そこがわからんから変な議論になってしまい話がかみ合わんのだ。

age

>DirectXのムービー側がノンインター前提なので、

つーことは、directXをインターレース可にすればいいってこと？
Microsoftに期待するしかない？

環境はAthlon 1GHz@FSB266 / KK266-R VIA KT133 / G400DH Ver.5.51

ファイルはMTV1000で録画した4.5-9.8Mbps VBRのMPEG2-PS。
何回かテストしてみたけどMediaCruiseを起動してからファイル指定をして再生すると
ブレやコマ落ちのような現象が出ない様だ。
ただしMediaCruiseを起動した直後に自動的に再生されると
ブレやコマ落ちのような現象が出る。
あとテレビがソースに関係なくDRCプログレッシブがかかる
テレビなんだがコレは関係ないんだろうか？

どのみち正しいインターレース表示ができないのは確かなので、
G400はMPEG4再生専用にしてDVD-8300かHW+買うつもりだが。

>>62
＞どのみち正しいインターレース表示ができないのは確かなので、

根拠は？


＞あとテレビがソースに関係なくDRCプログレッシブがかかる
＞テレビなんだがコレは関係ないんだろうか？

インターレースの実験だから、プログレはオフにしないと。

　インターレース、ノンインターレースはCRT走査方法の名称。
決してデータ形式を称するものではない。
　素材がインターレースであろうが、ノンインターレースであろうが、
MPEG2データはフレーム単位で扱うから、この議論の争点は、フレーム内
の両フィールドを明確に分離可能か否かじゃないのか？
　G400はBobでもWeaveでも補完してしまうから、分離不能。
得られた補完フィールドからNTSC出力することも可能ではあるが、
拡大してから縮小処理するようなものだから、余計な処理と言わざる
を得ない。

>>50
違うんだって。MPEG2のインターレースは、WEAVE状態の画像を記録してる
わけではないんだよ。
たとえば、720x480のインターレースMPEG2ファイルなら、720x240（奇数フィールド）
と720x240（偶数フィールド）という別々の画像を1フレームのセットとして
記録してるんだよ。だからH+みたいな専用のデコーダーで再生すれば、
きちんと両方のフィールドを完全なタイミングで出力できてるんだよ。
720x480のweave状態のMPEG1ファイルは、インターレース分離のプロセスが
行われないから、正確にはインターレース出力とはいえない。
もちろん出力信号そのものはインターレースになってるんだけども、
それはH+であろうがG450であろうが、一度weaveにした映像をぐちゃぐちゃな
タイミングでインターレース映像に再構成した映像にすぎない。
だから実験するなら絶対MPEG2でインターレースモードのファイルを
つくらなきゃだめ。
これは、情報量の問題ではなくて、ファイル形式の問題なんだよ。

つーか貧乏人は大変だね。
おれはプログレ出力をプロジェクターで楽しんでるよ。
アナログのインターレース素材はDScalerが大活躍。

>>64
＞　G400はBobでもWeaveでも補完してしまうから、分離不能。

その根拠を示してほしいです。

>>67
Bobのとき。
　片フィールドから１フレームをつくり、60fpsで表示。当然、縦240→480
にするときに補完処理が入る。フィールドに戻す際にはその補完を取り除か
なければならないが、それは画像を拡大して縮小をかけるようなもの。
余計な処理と表現したのはこのこと。

Weaveのとき。
　両フィールドを組み合わせて１フレームを生成。その際に補完が入って、
両フィールドを混ぜ合わせたようなフレームになる。それを強引に
フィールドに分けても、互いに２重化したようなフィールドになる
ので、分離不能と表現した。

Bob、Weaveはこちらを参照した。（一番下）
ttp://www.watch.impress.co.jp/pc/docs/article/20001109/key142.htm

>>68
＞Weaveのとき。
＞　両フィールドを組み合わせて１フレームを生成。その際に補完が入って、
＞両フィールドを混ぜ合わせたようなフレームになる。

りんく読んだけど、
Weaveのとき、補完が入るなんか書いてないやん。

>>69
　ふむ。以前どこかで読んだ資料には補完すると書いてあったんだが、
今調べて見るとそんな情報は出てこないな。

かわりにこんなのをみつけた。ただし、情報は古い。
ttp://www.zdnet.co.jp/magazine/pcmag/9709/t0917c.html
文中の白書
ttp://www.microsoft.com/hwdev/devdes/vpe.htm

　どうも、Bob、WeaveはM$が開発したアルゴリズムのように読めるのだが。
いずれにしろ、この時点ではWeaveで補完するとは一切書かれていない。
現在のWeaveはどうなのかは不明だが、少なくとも論拠は示せないので、
>>68のWeaveのくだりは撤回する。申し訳無い。

キチガイ一人を納得させるのにご苦労様です。

通りすがりのものだが。
BOBとかWEAVEとか、それ両方とも「インターレース記録素材→ノンインターレース表示デバイス」をキレイに見るための処理方法なんでしょ？
アナログ出力するのにそんなことしたらダメじゃん。
もしかしてG4x0ってそのまま出力できないの？

G4x0ってDirectShowストリームを横取りしてるんだよね？
Bobってのはフィールド分解して60fpsになってて、
Weaveってのはフィールドブレンドして30fpsになってるって事でいい？

じゃさ、推測だけどG4x0ではこうなるんじゃないの？
Bob＝「単なる補完プログレッシブ表示（情報量半分）」
Weave＝「ABフィールドが混ざった、上下にボケて動きが滑らかではない絵」
何も処理しない素の出力が出来れば何の問題もなく
インターレース表示が出来ると思うんだが、
漏れはもしかして大きな間違いを犯しとるか？

突っ込みきぼ〜ん。

>>73
あってると思う。
「素の出力」はやっぱり専用ソフトの登場待ちだね。

ビデオエンコードチップの直接制御＆MPEG2デコーダの自作となるとかなりハードルは高そうだけどな。

また見つけてしまった（しつこい？
ttp://www.microsoft.com/DIRECTX/dxm/help/ds/Gloss/gloss_F.htm

　これを見る限り、DirectShowフィルタのWeaveは、現在でも補完しない
モードのようだ。ただし、DVDプレーヤーがこのフィルタを使っている
とは限らないから注意されたし。

結論は専用ソフトでないと無理なんだよ。
G400のようにDirectX経由ではそのままは無理。
専用ソフト作ればいいんだろうけど、それならHW+で十分。

同様にGeForceのビデオ出力なんかも論外

>>73
＞Weave＝「ABフィールドが混ざった、上下にボケて動きが滑らかではない絵」

これは、おっしゃるように推測の範囲だね。
G4x0が実際に、どんな処理をしているのか解らないから、
実験してみるしかないでしょう。


>>77
＞G400のようにDirectX経由ではそのままは無理。

言い切るんなら、具体的に証明してよ。

説明強要バカは死ね

完全に
「往生際の悪い自作自演＝H+スレの241」
を囲む会になっちっまったな。

G400買え＞H+スレの241

>>80
言い切るだけの説明になってないと、指摘しておく。

>>71
このキチガイを連呼するヤツ、どうにかならんか？

自作自演皿仕上げ

>>65
＞MPEG2のインターレースは、WEAVE状態の画像を記録してる
＞わけではないんだよ。
知ってる

俺がテスト用ファイルで調べたかったのは一度weaveにした映像を、
正しいタイミングでインターレース映像に再構成できてるかって事ね
で、
＞それはH+であろうがG450であろうが、一度weaveにした映像をぐちゃぐちゃな
＞タイミングでインターレース映像に再構成した映像にすぎない。
これは違うね
H+で再生させてみると、正しいタイミングで出力できてるよ。（下に補足）
このH+がやっている、インターレース映像への再構成の方法（逆WEAVEとでも言おうかな）
で出力してくれるビデオカードがあれば、問題は解決するんだけどね。

＞これは、情報量の問題ではなくて、ファイル形式の問題なんだよ。
そんなことはない
ビデオカードがDirectShow経由で映像を受け取るときの形式が、縦480でWEAVE状の
プログレッシブ映像であればいいの。
これは、MPEG2のWEAVEでデインターレースしたものでも、縦480のMPEG1でも、AVIでもいいわけ。
ビデオカードがDirectShow経由で映像を受け取るときは、元のファイル形式なんて関係無いだろ。


補足
H+が俺の規格外のMPEG1を正しく逆WEAVEできるのは運が良かったと思うかもしれないけど
そうでなくて、単にMPEG2のプログレッシブ映像を逆WEAVEするときと同じ扱いをしただけでしょう

>>84 の口癖は、”キチガイ”と”自作自演” です。

ごめん。
今までのレスを総括すると、H+とG450ではどっちがTV出力上なの？
おれ、両方かっちゃった馬鹿なんだけど。
しかも両方さしてるし。
でも、どっちか売りたいんだよね。

>>87
もしかしなくてもかなりAHO？

>>88
お前がAHO。どっか逝け。

自作自演皿仕上げ

いやいや87=89がかなりきてますね。
たぶん盲目な方なんでしょう。

>>91
そうそう
当然G450にｷﾏｯﾃﾙﾀﾞﾛ!!!

Bobを縦240,60FPSで受け取った場合完全なフィールドをもらってる
事にならない？それをそのまま時間順にNTSCに出せば良いのでは？
ポイントは60FPSで出力したときに、片方のフィールドを2回出す
などという処理をしない、という点にかかるが。
このへんDirectXのバージョンとかで違ったりしそうだなー。

Weaveが変な補完をしないのであれば、縦480,30FPSで
受け取った場合は奇数ライン/偶数ライン毎に
出すと完全なフィールドを送出する事になるけど、
時間的順序がわからなくなるので動きがおかしくなるのは
同意(フィールドオーダー情報が欠落するので)。

便利さではG400が上だけど画質（動きの滑らかさ）ではHW+が上

終了

で？

ビデオカードで動画のインターレース出力は可能か ■▲▼
1 名前：名無しさん＠お腹いっぱい。 投稿日：2001/08/03(金) 17:33
普通のビデオカードでテレビへインターレース出力(60フレーム)は可能なのでしょうか。

可能なの？

「普通のビデオカード」では無理っぽいということで終了。

相手にしない方がいいと思うんだけどなあ？理由を説明して
も理解できずに、ほとぼりが醒めたらまた「私の質問に答え
てください」と言うに決まってるし。

たとえG400の基板に27MHzの水晶載ってても、NTSC信号が発生
できてもさ、FrameBufferへの書き込みが完全に1/60秒に同期
していない限りは、見掛け上のフレームレートは変動するっ
てことを理解してよ。

で、OSタイマーでそんなシビアなタイミングを規則正しく生
成することは最初から不可能なの。これは構造上不可避なの。
だからWindowsみたいなヘタレOSで、正確にNTSCの
BlackBurst発生できる訳ない！。リアルタイムOSじゃあるまいし。

つまり、既存のOSとアプリケーションがデコードして、絵と
してFrameBufferに書き込みを行っている限りはさ、必ずコマ
落ちや同じ絵が出て、つじつま合わせが生じているのだ。ま、
それが自然に見えるかどうかは、見た人の目の腐り具合によ
るだけ。ソフトからインターレース信号を渡す？なんて
キティガイな発言もあったけど、基準クロックがないのに
どうやって渡すのさー。

そんなんできれば苦労しないよ。

>相手にしない方がいいと思うんだけどなあ？理由を説明して
>も理解できずに、ほとぼりが醒めたらまた「私の質問に答え
>てください」と言うに決まってるし。

だからとことん相手してあげる隔離スレでしょ？
H+スレの241は弱虫だから専用スレができたとたんに
ほとんどコテハンでは書き込まなくなったが
どうみても名無しで茶々入れてるのがわかる。

現状のなんにも特別な対処がされていないビデオカードで
インターレースが出きるとは思わないけど
今後は専用ソフトでいいからそういうことが可能な製品が
出てきてくれればいいね。

数年後もHW+使い続けてるDTV環境を考えると鬱になる。

>>99
あーそれいいね。

今は普通のTVの60フィールドですらまともには生成できない
けど、これからもリニアにパソコンとネットワーク帯域が
上がっていくとすれば、HDTV以上の表示も夢じゃない。

DOOM(例え古いか)とかのゲームでもフレームレート上がると
臨場感が全然違うじゃん。TV放送規格に縛られない
ブロードバンドストリーミングなんてできたらワクワクするな。

インターレースなんてケチくさいこと言わず、120フレーム
のプログレッシブ放送なら、なんの変哲もないジェットコー
スターのムービーだってすごいスペクタルかもしれない。

ここまできたらTV出力なんてけち臭いこと考えないで
直接RGBでプロジェクターに出せよ。

ビデオカードがMPEG2出力のことを考慮したハードを搭載し、
DVDプレイヤーがそれぞれのハードに対応していく。
CD-Rドライブと焼きソフトのような関係ができあがって欲しいです。
これならメディアプレイヤーで操作できるし。

ｶｺｲｲテストパターン欲しいよん
ITE

H+使ってるからどーでも良いのだけど、
>>97
Bobとかからいきなりwindowsのタイマーか。
Windowsは良くしらんけど、この手の処理はダブルバッファを
VSYNC割りこみで切り替えて割りこみ処理内で
非表示面にデコード済みデータをDMA転送する、という感じに
なるかと思うけど、Windowsの割りこみ処理機構はダメだから
負荷の少ない状況でもVSYNC割りこみを
1/60以内に受け取れなかったり割りこみが入らなかったりする事が
ある=更新されない絵が表示され得る、という理解で良いのかな？

※NTSC信号自体はハードで作るわけだからBlackBurst云々は蛇足ですよね？

>>100
640x480プログレッシブで60フレーム/秒のMPEG1はTMPGEncで作れるし、
MediaPlayerで再生できるよ。なかなかいい感じ。
問題はその条件のビデオソースがないこと。
CGか、フィールドを補間するしかない。

>>101
映画なんかはもともと24fpsの情報量しかないわけだから、
RGBでプロジェクタに出したり、大画面モニタに出すほうが
普通のテレビで見るよりきれいだろうね。

>>105
あーそうか。入力デバイスないよね。
ハイスピードカメラ？高そうだ.....
まだフィルムを高速撮影して、テレシネして
ストリームに直した方が現実的かな。

DVコーデック周辺のチップってガチガチ27MHzに
固定だし、あれ以上の速度が出る余裕はなさそう
だよね。LSI作れよ＞松下とか

>>104
基本的にそういう理解で合っていると思う。
Windowsの標準的なプレイヤー(MediaPlayerすら)
TickCount()かSleep()で調整してるような感じ(^^;

あれだよ、ソフトHW+というかさ、出力だけ27MHz同期で
非圧縮の多段FrameBufferがあればいいんだよね。
PCIじゃバス幅が足りないかな....HyperTransportなら
大丈夫だろうか。

>>97
ちみの考えは古過ぎです
DirectShow、DirectDrawとかオーバーレイについて勉強してください

とはいえ、G400がやってるようなDirectShowのストリーム横取りでも
コマ落ちや同じ絵が出て、つじつま合わせが生じるだろうね

やっぱ専用ソフトが必要

正確にNTSCの信号を出すためには、NTSCのVSYNCに同期して割り込みを発生させ
そのタイミング内でフレーム画像を書き換えないとだめだろうよ。
しかし問題は、グラフィックボードのVSYNC割り込みはとれても、TV出力信号の
VSYNC割り込みを検出する手段がないところにあるんじゃないのか? G400の場合
グラフィック出力とTV出力とのVSYNCは同期してないからな。
グラフィック出力とTV出力のVSYNCを完全に同期させるか、またはTV出力のVSYNC
割り込みを別途検出できるようなAPIをMSに作ってもらわないと駄目なんじゃ
ないか?

そんな板orスレッドないです。





| おすすめ | 2chサーバ監視所 | BinboServer | Hikky.Zansu.com | 無料サービス |





さぶドメインシリーズ登場
　　　*****.syo-ten.com
　　　*****.gasuki.com
　　　*****.zansu.com
おすきな名前を無料で使えます。早い者勝ち。
工夫しだいで、楽しさ１００倍。
深夜でも快適なレンタルサーバサービス(n)
あの巨大なサイトも使っています。

>>108
>グラフィック出力とTV出力とのVSYNCは同期してないからな。
そうなんですか？
まるでダウンスキャンコンバータが入ったようなものなんですね。

http://avmaniahp.hypermart.net/main.html

age

G400のTV出力は使い物にならないってことで
終了

>>110
>そうなんですか？
だよ。だからグラフィック画面側をハイリフレッシュにした状態でも
TV出力できる。G400のウリの一つではあるんだが、反面TV出力の
VSYNCは取れない。というわけでTV出力のVSYNCに同期してフレーム
バッファを書き換えることは原理的に不可能。

よってTV出力は駄目、ってことだな

>>114
まーダメと言い切ってしまう必要もないんじゃない？？
画面モードが割と柔軟で「それなりに見られる」んだから。

画面モードが27MHz同期で要専用ソフトじゃあ不便だよ...
往年のX68000とかFM-TOWNSを思い出すな。もちろん
そのカードはG400の今の値段より高いよきっと。

ということでG400の仕様は妥当、H+スレの241はバカだから
クビ吊って死ねという結論でいいんじゃないの？

>>114
だから〜
フレームバッファで動画をやり取りしてるんじゃないよ
動画をストリームとしてビデオカードに渡してるの

ビデオカードがそのストリームをオーバーレイ領域内に合成して
モニターに出力してるわけ
ソフトがフレームバッファに書きこむなんて考えは古すぎ

で、そのストリームをTV出力用に使ってるから、DVDMaxみたいな機能ができるんだからさ

>>116 はわかったようなこといってるけど実はぜんぜんわかってない。
DVDMaxはあくまでもPCのモニタでは通常のOSの画面を表示させながら、
TVにはムービーを全画面表示するという機能。
これはフレームバッファを２分割して使うという機能だから、
TV出力機能にそのものに関しては特に目新しいところはない。

>>117
(ﾟдﾟ)ﾊｧ?
動画再生にはフレームバッファなんて関係無いって言ってんだろが。
そこんところまずを理解してもらわないと

きみたち、仲良くな。

フレームバッファ無しにモニター出力できるなんて非常に興味がある。
どうやっているのかぜひ解説してくれ。＞107

>>118
> 動画再生にはフレームバッファなんて関係無いって言ってんだろが。
あんた、暑さで頭やられたか？
フレームバッファを介在させずに直接アナログ信号が出力できるわけがなかろ。
リアルタイムでNTSCビデオ信号を合成しろとでもいうのか？

いいか？　DVDMaxって機能は本来であればPCのグラフィック画面上に合成される
べきオフスクリーンオーバーレイを、単にセカンダリから出すことができるよう
になったというだけの機能だ。オフスクリーン領域ってのは通常のグラフィック
表示用フレームバッファとは別のメモリ領域というだけであって、これがビデオ
出力用のフレームバッファになっているという点ではなんら変わりないんだぜ。
つまり>>117が言っているように,単にフレームバッファを2分割して使用している
だけで、ビデオ出力用のフレームバッファってのはちゃんと存在するんだよ。

>>98
久しぶりに来れた。（名無し含む）

どうでもよい事だけど、
このコテハンあまり好きでないです。

フレームバッファが無いとは言ってないよ。
関係無いって言ったの。ちょと語弊があったのかもしれないｹﾄﾞ。

ソフトがPCのグラフィック画面用のフレームバッファを書き換えて動画を表示してるって
勘違いしてる人がいるから、そのフレームバッファは関係無いよといったわけ
だからVSYNCに同期云々の問題は関係無いんだよといいたいわけです

107へ
>>118の発言は>>117を完全に否定しているもんだと受け取ったけど
それについてのコメントは何かないの

＞これはフレームバッファを２分割して使うという機能だから
って発言が、一連の流れからしてオーバーレイについて理解してない
感じだったので、否定したんですが
121とは意見の相違は無いと思うよ。俺のいいかたに語弊が合っただけで

スレの前半と後半で、論点が分かれているので整理してみました。


（前半）
インターレース情報は、DirectXのフィルターを通るので欠落する。
だから、インターレース表示は不可能。
↑
WEAVEにすることで情報欠落は無い。
↑
但し、WEAVE入力に対してG400がどういう反応するかは不明。
→私は、この部分が知りたかった。


（後半）
たとえ、出来たとしても、DirectShowにはタイミング的な精度がない為、コマ落ちする。


〜〜〜〜〜〜〜〜〜
答えは既に、>>62 で出ている気がする。

＞何回かテストしてみたけどMediaCruiseを起動してからファイル指定をして再生すると
＞ブレやコマ落ちのような現象が出ない様だ。

＞どのみち正しいインターレース表示ができないのは確かなので、
とされているけど、その理由は述べられていない。

「コマ落ち」が無いということだから、
恐らく、（後半）ではなく、Weaveでも補完が起こるのでは？という事を問題視していたと思われる。
しかし、それに付いては、
>>76 さんが、「Weaveは補完しない」事を確認され決着した。

「DRCプログレッシブ」がどんな挙動をするのか気になるけど、
スクロールでコマ落ちがないという事だから、
G400からインターレース出力がされていると見て、間違いないのではないだろうか？

>>125
おーけー。んじゃ、通常のグラフィック用のフレームバッファと、
オーバーレイサーフェス用のフレームバッファ、2種類のフレームバッファ
が使われているってことはわかったわけだね。
で、DVDMaxはこのうちオーバーレイサーフェス用のフレームバッファをそのまま
NTSCエンコードしてアナログ出力することで実現されることまではわかるだろう。

大事なのはこのときだ。オーバーレイサーフェス用のフレームバッファは
NTSCで出力されるので、正確に29.97fpsで更新される必要がある。つまり
NTSC出力時のVSYNC割り込みに同期させる必要があるんだぜ。
ところが、DirectXからではこの割り込みをとることができない。だから
オフスクリーンオーバーレイ用のフレームバッファは、NTSC出力とは
同期せずに更新されてしまう。これがG400で厳密なNTSC出力ができない
理由だ。

識者の熱い議論によってなぜ既存のソフトウェアで
まともにMPEG2が表示できないのかかなりわかったような気がする。
一人だけかな〜りポイントがずれてる人がいるのが難だが。

結局、正規のNTSC信号を崩さずに入出力するにはDVしかないということですか。

タイミングの問題となると専用ソフトでもかなり難しいんだろうね。

>>129
ハァ？

>>127
通常フレームの更新をやるさいには、書き換え状態が見えないように
VSYNC中に絵の書き換え(バッファの切り替え）などを行うわけだけど、
DirectX経由の再生ソフトがそれをやろうとするとPC用フレームの
VSYNCに合わせてしまいそうだね。
当然オフスクリーンオーバーレイの更新(メインRAMからの
デコード済みフィールドの補充)もPC用フレームの
VSYNCを単位とした間隔に、という事になりそうだ。

>>127
＞おーけー。んじゃ、通常のグラフィック用のフレームバッファと、
＞オーバーレイサーフェス用のフレームバッファ、2種類のフレームバッファ
＞が使われているってことはわかったわけだね。
いや、違う。やっぱり君とは考えが同じではなかったみたいだ（笑
通常のグラフィック用のフレームバッファと、ＴＶ出力用のフレームバッファ、
あと、オーバーレイ用のストリームのバッファがある

ソフトウェアはビデオカードに動画のストリームを渡し、ビデオカードがそのストリームをデコードして
グラフィック用のフレームバッファとＴＶ出力用のフレームバッファを書き換えているわけ

ソフトがビデオカードに渡しているオーバーレイ用のデータというのは、フレームではなく、
最終的な色空間変換のされてなかったりするような、ストリームなのよ。
（動き補償の機能があるビデオカードと動き補償に対応したソフトの組み合わせで再生すれば
そのストリームは動きベクトルも含む代物になるわけ）
で、もう一度言うと、ＴＶ出力用のフレームバッファを書き換えているのはビデオカードなの
だから、ビデオカードにその機能が完全にあれば、ＴＶ出力に同期させてフレームバッファを更新することは
不可能ではないのよ。

G400で厳密なNTSC出力ができないのは、ＰＣのクロックに基づく29.97fpsと
ビデオカードのNTSC出力用のクロックに基づく29.97fpsのズレの修正するために、
フィールドを間引くか水増しするときに、トップフィールドとボトムフィールドが
入れ替わってしまっているためだと思う。

G400でときどきトップフレームとボトムフレームが入れ替わってしまう不具合は
>>16のテスト用ファイルで確認できたよ。
あと、フリッカーフィルターの影響で、トップフレームとボトムフレームが微妙に
合成されてるのも確認できた。そのために少し解像度感が減少してるかもしれない。
画像はあとでウプする。眠いから

>>133
> 通常のグラフィック用のフレームバッファと、ＴＶ出力用のフレームバッファ、
> あと、オーバーレイ用のストリームのバッファがある
あんた、考え方がユニークだな。ついに3つめのストリームバッファなんてものを
もちだしてきたか。でも悪いけどそんなもんはないよ。
CPUがグラフィックチップに発行できるのは「描画コマンド」だけ。この描画コマンドは
グラフィックチップが持つ「FIFOコマンドバッファ」に発行される。オーバーレイ画面を
書き換える場合のようにイメージを転送するときには、このFIFOバッファと同時にCPUが
用意したイメージデータへのポインタを渡すことでグラフィックチップがmemory-to-AGPの
DMAを行うわけだ。で、このタイミングはTV出力時のVSYNCに同期して行われるわけでは
ないよ。

しかし、あんたが言う
> ソフトがビデオカードに渡しているオーバーレイ用のデータというのは、フレームではなく、
> 最終的な色空間変換のされてなかったりするような、ストリームなのよ。
> （動き補償の機能があるビデオカードと動き補償に対応したソフトの組み合わせで再生すれば
> そのストリームは動きベクトルも含む代物になるわけ）
色空間変換、スケーリング、iDCT、MCのことを言いたいわけだね。しかしこんなものは、普通の
グラフィックチップならもはやどんなものでも持っている簡単なビデオアクセラレーション機能
にすぎない。まぁG400/450はiDCTやMCはそもそも持ってないけどな（ｗ
色空間変換やスケーリングにはバックエンドとフロントエンドがあるが、バックエンドに
ついてはビデオ信号を生成する段階でリアルタイムに行われるわけで、こんなものにフレームバッファは
つかわれんよ。フロントエンドはさっきのDMAの段階で自動的に行われるしな。

>>134
> G400で厳密なNTSC出力ができないのは、ＰＣのクロックに基づく29.97fpsと
> ビデオカードのNTSC出力用のクロックに基づく29.97fpsのズレの修正するために、
> フィールドを間引くか水増しするときに、トップフィールドとボトムフィールドが
> 入れ替わってしまっているためだと思う。
なんだ。つまりG400のTV-OutのVSYNCはPC本体からみえていないことは認めるわけなんだな。
このスレでいう「正常なTV出力」ってのは、TV-OutのVSYNCとPCが想定する29.97fpsとが完全に同期
していないと実現できないわけで、あんたがいう「フィールドを間引くか水増しする」が発生した
段階でもはや「正常なTV出力」じゃないんだが

付け加えていえば、仮にこれがずれてもトップとボトムフィールドは入れ替わらないぜ。
トップフィールドとボトムフィールドってのはあくまで上から数えたラインが奇数番目か偶数番目か
できまるわけで、垂直方向に1ラインずれないとトップとボトムはいれかわらない。
あんたがいう「29.97fpsのずれ」で画面が乱れる現象は「ティアリング」だろ。
それくらいわかってくれるよな。

>>135
＞グラフィックチップが持つ「FIFOコマンドバッファ」に発行される。オーバーレイ画面を
＞書き換える場合のようにイメージを転送するときには、このFIFOバッファと同時にCPUが

オーバーレイ画面を書きかえるときにはイメージを転送してるんじゃないって、言ってるだろ。
命令やデータが混ざった、ストリームをビデオカードに渡してるんだからさ。
そのストリームからフレームに直すのはビデオカードの仕事なの。

＞で、このタイミングはTV出力時のVSYNCに同期して行われるわけではないよ。
この主張はもう繰り返さなくていいです
フレームバッファの書き換えのタイミングを取るものは
おまえはCPU(ソフト）と考えてて、俺はビデオカードって考えてるわけだよ
議論の焦点をもうこっちのほうに移してほしいんだけど

＞フロントエンドはさっきのDMAの段階で自動的に行われるしな。
おいおい。色空間変換ぐらいなら出来るだろうが、
iDCT、MCをDMAでメインメモリーにアクセスしながらやるなんてすごい考えだな。
ビデオカードのメモリーにDMAで転送してから、デコードするに決まってるだろ
さっきは、このビデオカードのメモリーの領域をストリームのバッファと表現したの

あんた、ビデオカードがデコードすることをあんま考えて無かっただろ？一番上の引用でも、
メインメモリーにすでにデコードされたイメージがある事を前提に書いてるしさ。

>>136時間軸　　　　１ .２ .３ .４ .５ .６ .７ .８ .９
　　　　　　　　TBTBTBTBTBTBTBTBTBTBTB
G400の出力 TBTBTBTBTBBTBTBTBTBTB
　　　　　　　　　　　　　　　　 ↑
　　　　　　　　　　　　　　　　ここでTフィールドを間引いたとする
これでなんとなくわかる？
1フィールドだけ間引く（水増しする）と
TフィールドにBフィールドの絵が、BフィールドにTフィールドの絵が出力されることになるの

実際にG400の出力をキャプチャすればわかるよ
で、これがデインターレースをWEAVEにしたときに、G400のTV出力がおかしい理由。

この問題のせいで、G400の出力でインターレースの映像を再現できないんであって
おまえの想像した問題なんてどこにも生じてないぜ

>あんたがいう「29.97fpsのずれ」で画面が乱れる現象は「ティアリング」だろ
フィールドを水増し、間引くことでずれを調整するなら、ティアリングなんて関係無い

やべ、ずれた
時間軸　　　　１ .２ .３ .４ .５ .６ .７ .８ .９
　　　　　　　　TBTBTBTBTBTBTBTBTBTBTB
G400の出力 TBTBTBTBTBBTBTBTBTBTB
　　　　　　　　　　　　　　　　 ↑
　　　　　　　　　　　　　　　　ここでTフィールドを間引いたとする

138の説明はちょっと間違ってる気がしてきた。
TフィールドとBフィールドが入れ替わるんじゃなくて
時間方向にフィールドが入れ替わるようにしてる気がする
眠いので明日書く

>>137,140
なんだ。ほんとに知らないんだな。よくわかったよ。
まず第一に、いま話題にしているG400,450には、iDCTもMCもどちらの機能も無いよ。これは両チップのスペックシートでも見ればわかるだろう？
ということであんたのいう主張であるビデオチップがデコードっていうのはそもそも実現できないと思うのだがどうよ。
あんたの頭の中にあるビデオチップのデコード機能ってものがどれくらいのものを指しているのかはわからんが、
他のビデオチップにあるiDCTやMC機能だって、いわゆる「デコード」みたいなものはできないんだぜ。
たとえばMCだってせいぜい指定したマクロブロックを指定方向に動かす機能があるだけ。つまりBitBltにちょっと毛が生えた
くらいのことしかできないんだぜ。まぁそもそもG400には、色空間変換とスケーリング、インターポーレーションしか
ビデオアクセラレーション機能はないけどな。これはいずれもビデオ信号の作成時にリアルタイムで行われている。

次にトップとボトムが入れ替わるという話だが、これも笑止千番だな。
そもそもフィールドが「間引かれる」ってなによ。ビデオ信号ってのはトップフィールドとボトムフィールドで信号の
タイミング自体が異なってるってのはわかるよな？　たまたま処理が間に合わなかったからって勝手にボトムフィールド
だけを２つ連続して出力するようなことはできないんだぜ。
だいたい、あんたがいうようにグラフィックチップに「デコード」機能があるなら、
処理が間に合わずにフィールドが間引かれることなんてありえないだろ。ソフトでやってるんじゃ
ないんだから。

ま、いずれにしろ俺もあんたも、G400のTV出力がおかしい、ということで一致している
みたいだから別にこんなことでもめる必要もないけどな。

>>141
逆にあんたの無知さがよくわかってきたよ
＞G400,450には、iDCTもMCもどちらの機能も無いよ。
んなわかりきったこと言わないでよろしい。他の人からの突っ込みが来るかと思って
注でも書いておこうかと思ったけど、まさかあんたから突っ込まれるとは思わなかった。

一般的なビデオカードのオーバーレイの際のデータの受け渡し方法について議論してるんだからさ、
おまえの説明するオーバーレイの方法では明らかに無理が出る例として、
iDCTやMC機能があるビデオカードの場合を出してきたんだけ。
オーバーレイの方法もビデオカードによっていろいろあるんだとか言い出さないでくださいね。
＞ということであんたのいう主張であるビデオチップがデコードっていうのはそもそも実現できないと思うのだがどうよ。
＞たとえばMCだってせいぜい指定したマクロブロックを指定方向に動かす機能があるだけ。つまりBitBltにちょっと毛が生えた
＞くらいのことしかできないんだぜ。
ほ〜。で、MCがたいしたことじゃかいから、これはビデオカードがDMAでメインメモリーアクセスしながらやっちゃっうなんて考えてるわけ？怖いよ
IDCTは？これがデコードじゃない？俺はデコードって言葉を広義的な風に使ってたんだけど、なんか狭義的に受けとってるみたいだけどさ
IDCTなんてもろに狭義的な、画像のデコードの方法じゃないか。

さらに例をあげると、MCに対応してるGeforce2MXでもG400と同じように、オーバーレイ部分をTVに出力できます。
おしまい。

＞次にトップとボトムが入れ替わるという話だが、これも笑止千番だな。
＞そもそもフィールドが「間引かれる」ってなによ。ビデオ信号ってのはトップフィールドとボトムフィールドで信号の
＞タイミング自体が異なってるってのはわかるよな？　たまたま処理が間に合わなかったからって勝手にボトムフィールド
＞だけを２つ連続して出力するようなことはできないんだぜ。
＞だいたい、あんたがいうようにグラフィックチップに「デコード」機能があるなら、
＞処理が間に合わずにフィールドが間引かれることなんてありえないだろ。ソフトでやってるんじゃ
＞ないんだから。
俺も前の書きこみはチョット理解してもらえる自信かったから、ごめんね
その上ボトムとトップがひっくり返るって言う間違えた結論を主張してしまった。
正しくは、時間方向の順番がおかしくなるでした。

で、誤解を解くための説明するけど、
間引かれると言うのはソースの話。60fpsで再生できる装置があるとして、
その装置での61fpsのソースのファイルを再生しようとすると、そのままでは再生できないから
その装置がソースから1フィールドだけ間引く処理をする、と言う風に考えてくれ。

その装置というのがＧ400のことで、入力と出力のｆｐｓに差が出てきてしまう要因として
Ｇ400のビデオカード上のＴＶ出力用のクロックに基づく29.97fps（ビデオカード上には
ＴＶ出力用の水晶振動子がある）と、ＰＣのクロックに基づく29.97fpsには微妙な差があるからね。

あんたは高級言語的な説明を嫌うみたいだけど、我慢して聞いてくれ。
イメージとしては、ＰＣ本体のソフトが送り出すストリームとビデオカードが処理して出すストリーム
（ＴＶ出力のこととしてくれ）には流速の差があるから、ストリームを水増す／間引くことで対処すること
が必要というわけ。

横から失礼しますが
ストリームに間に合わない場合は、１つ前のフレームから
フィールドを作り出力するというのが普通の考えではないでしょうか
つまり間引くのではなく、コピーフレームが出力される
またそれ以降ずっと間に合わなければ>>139の図のようになるでしょう
つまり、誰がフレームバッファに書くかが問題ではなく
フレームバッファに書き込むタイミングと
フレームバッファからNTSC信号を作り出すタイミングが
非同期なのが元凶である

全くの非同期ではなく、少なくとも１フィールドの書き換え中には出力しない
またフレームバッファはフィールド単位ではなくフレーム単位
だということは異論がないと思いますが。
もし新しいストリームが間に合わなければ、その所にコピーフィールド
が出力されてもそれ以降ずっとずれればそのつなぎ目のフレームだけの
問題となります。
フィールド順が反転することがあるとすれば
トップフィールド（又はボトムフィールド）の出力の場合のみ遅れる
（１フィールド毎に遅れるということ）ということで
これは純粋にNTSC信号発生部分（ボード内）の話で
データ転送には関係ない話だと思います。
（原因はファームまたはドライバソフトの問題かも知れませんが）

ちょっと間に入った人は待ってってね
書き中のがあるから

G400の出力をキャプチャーしたファイルを調べた結果と、121との議論の過程で考えが煮詰まってきました。
＞ま、いずれにしろ俺もあんたも、G400のTV出力がおかしい、ということで一致している
＞みたいだから別にこんなことでもめる必要もないけどな。
と言うわけで、意味は有ったよ。ありがとう

これ以降は特に121へ当てたメッセージじゃなくて、
WEAVEにしたときのG400の出力が正しくならない原因を説明するってかんじで。

で、調べた結果を分析してみると、どうやらWEAVEによるI→P変換とそれをTV出力時にフィールドに分解する
P→I変換は、完全に出来ているようです。ので、これからはWEAVEで再生させたときにはビデオカードには
インターレースのデータを完全に渡せていると言う前提で話を進めます
では、なぜインターレースの動画を再現できないのかというと、さっきにも言った、
フィールドを間引く／水増しするという問題があるためのようです。

間引く／水増しする、の場合にどうなるかの説明
昨日書いた図ではわかりにくいから、ほかの書き方をしてみた。

→時間軸
1 3 5 7 9 . . . . . .
2 4 6 8 . . . . . .

この図の見方　上の行がトップフィールド、下の行がボトムフィールドで、
これはテレビ出力時の位置関係。上の行にあるフィールドはTV出力時にトップフィールドとして出力されるわけ。
数字はフィールド1枚をあらわしていると考えてください
出力の順番は 1 2 3 4 5 6 7 8 9 ・・・って出力される

G400がソースから１フィールド間引くときにはどういうふうに間引くかというと下のようになるみたい。

→時間軸
1 3 5 7
2 6 8　……　←ソースから4を間引いた

このときの出力は 1 2 3 6 5 8 7・・・・・っていう順番になるわけ。
この出力だと、インターレースソースの場合、間引いたあとは2歩進んで1歩下がるような動きの動画になってしまう。
実際にG400でWEAVEにして再生すると、はじめは正常に表示されたが、
少しすると2歩進んで1歩下がるような動きの動画になったでしょ?

なんでこんなへんな間引き方をするのかって思うだろうが
実はソースがプログレッシブの場合に、問題無く出力するためです。
俺はG400がこう言う間引き方を事をすることがわかった時、
G400のDVDMaxってそれなりに練ってあるんだなあと思った。
プログレッシブなソースだと問題無いのを説明するために表所方法をチョット変える

プログレッシブなフレームをフィールドに分解すると、時間的には同じで、位置がトップフィールド
であるものとボトムフィールドであるものの2つのフィールドが出来ます。
時間的に同じなのをわかりやすくするために
下のように書いてみました。数字が同じものがソースとしては時間的に同時。
もちろん表示されるタイミングは1/60秒違うよ。

→時間軸
1T 2T .3T 4T 5T .6T
1B 2B 3B 4B 5B 6B

これをさっきの方法で1フィールド間引くと（3Bを間引いた）
→時間軸
1T 2T .3T 4T 5T 6T
1B 2B 4B 5B 6B


これを再生すると、1T 1B 2T 2B 3T 4B 4T 5B 5T・・・・となる
間引いた瞬間ではちょっとおかしいが、それ意外では完全にフレームを再現できている。
プログレッシブソースの場合TとBのフィールドには、時間的の同時だから、
どちらが先に表示されなくてはいけないと言う順番は無いので、T→Bの順でも、B→Tの順で表示しても
もかまわないからね。

というわけで、やはりインターレースで正しく出力するのは無理だけど、
DVD（映画とか）をTVに表示するのにG400は良いみたいだね。

あなたの論理では、さらにもう一度間引かれると
プログレッシブでもずれることになるね

>>148の説明を良く読んで見た
でも、どう考えても
＞実はソースがプログレッシブの場合に、問題無く出力するためです
とは読めない
プログレッシブで問題がないようなのは２フィールドで時間的ずれ
がないためで、そのようになるようにこんな仕様にしたとはとれない
言い換えると、原因と結果を取り違えていると思う
また、プログレッシブでも60fpsを取り扱えば同じ問題が出るよね

>>150
そうだよね。
抜けるのがボトムフィールド部分でなくトップフィールド部分なら
この説明でもプログレッシブでもズレるよね。
あ、こう言っちゃあいけないのかな
ボトムフィールドが間に合わなくて、ボトムフィールド部分が１フレーム前の絵が出る
といった方がいいかな
考えとしては、30fpsの場合のみでなく、
それより大きいfpsの場合、小さいfpsの場合も考慮してみれば
穴もふさがると思うよ

Video信号の垂直ブランキング期間にフレームバッファに書き込む
のと
書き込むデータ
の同期が取れないからですよね
（もちろんブランキング期間とはディスプレイのではなくてVideo信号のです）

また、ストリームデータといっているが、まさか
MPEGヘッダやフラグ、タイムコードつきのデータをそのままポンと
渡して、『さあ表示してみろ』とか言わないよね
マクロブロックのデータを用意して、ベクトル方向とかiDCTテーブル
とか渡して部分的に書いてもらうんだよね
（それをアプリがフレームバッファに書くと表現しても間違いじゃないと思う）

>>152
私もそう思うんだけどね。そもそも107がいうように「ストリームグラフィックチップに渡してデコード」できるという感じではない。
グラフィックチップが持つiCDTもMCもあくまで「iDCT支援」「MC支援」であって、すべてのステップを
グラフィックチップが実行するわけじゃないんだけどな。つーかグラフィックチップにこれができたら、ハードウェアMPEG2デコーダは
要らなくなる。

それよりもちょっと興味があるのは、107が言う「フィールドの間引き」ってのはいったい誰がやるんだ?
>>107は、この間引きをするのはグラフィックチップがやるといいたいのかもしれないが、そもそも107がいうように
CPUがグラフィックチップに「ストリーム」を渡すのであれば、グラフィックチップはそれを先頭から順に自分のタイミング
に従ってデコードしていけばいいだけじゃないか。なにもわざわざ自分とずれているCPUのタイミングと
整合性をとる必要はないだろ。CPUからグラフィックチップのBUSYフラグをみてコマンドを送るのを待つくらいは
普通のグラフィック描画でもやっていることだしな。

グラフィックチップが出力する29.97fpsとCPUが想定する29.97fpsとのタイミングにずれが生じるという
主張と、CPUはグラフィックチップにデコードすべきデータストリームを渡すという主張自体、互いに矛盾
していると思うんだがなあ。

私は全然わかっていなくて想像なんですが
ストリームデータとは、上記の細切れデータのリストを
１フレーム分並べたものを言っているんではないかと思います。

さらに、それを直接プライマリサーフェイスに書くのではなく
仮想サーフェイスに書いてもらい、
最後にアプリがタイミングを見計らってプライマリサーフェースに
転送（BitBLTみたいに)しているんじゃないでしょうか
（プライマリサーフェイスは例えでありオーバレイサーフェイスと言っても
いいです）

それとも
生のストリームに近いデータを渡して（例えばMPEG2表示関数とかに）
外部に必要な各処理ルーチンのエントリを別に登録するのかな
でも、表示タイミング（さっきはBitBLTみたいにといったが
サーフェイスからサーフェイスへの転送指示といったつもりです
データなしの単なるコマンドかもりれません）
はアプリが図っていると思います。

こんなことをかくとお前はバカかとか言われそうですが。

ちなみに
外部処理とかアプリとかは、MPEG2のDirectShowFilterも含めて
のことを指しています。

サーフェイス（又はフレームバッファ領域）は
複数枚(15枚？）いりますね
MPEG2データでのGOP(IBP)の並びは
Bフレームが時間軸でPフレームと逆転しているので
(IBPPB...)とあったら実際は(IPPBPP..)と並び変えないといけない

タイムコードと書いたので文句がきそう（例です）
フレームヘッダから始まるデータが所定枚数ならんでいることを
示しています（ドロップフレームとかもあります）

色々書いたが、どの場合でもアプリが最終データを生成するまで
表示できないわけですね（表示タイミングもVideoドライバが行っているとしても）

結局、アプリが書いているということになると思います。

だいたい結論が出つつあるので、私はシステム面から
せめて見ましょうか。

WriteタイミングとReadタイミングが異なるバッファは
何も制御しなければ必ずオーバー／アンダーフローが
生じます。ストリームの区切りがフレームだろうが
フィールドだろうが時間軸同期していなければ絶対に
起きます。

MPEGストリームでは、エンコーダー側でデコーダー側の
バッファ制御のための情報(VBV)を生成してやって
ストリーム内に埋め込んでいるから、デコーダーは
FIFOコントロールができるのです。双方ともハードウェアで
構成されていても、水晶精度レベルのズレは確実にある訳
ですから...。

それで、107の理論に出て来る「ストリーム」には、
VBVに相当するものが存在するのでしょうか？多分ないよね。

というわけで、必死にフィールド構成の話とかしなくても
この問題の本質は簡単に説明できるのです。

以上。

まず、言っておきたいんだが、フィールド云々については
実際にG400の出力をビデオにとって、キャプチャーしたものを元に解明して、
どのようなフレームの間引き方がされているかを説明しているんだからな。
別に推理をしているわけじゃない。

んで返事

>>149
>あなたの論理では、さらにもう一度間引かれると
>プログレッシブでもずれることになるね
キャプチャーしたファイルを調べたら
フレームの出力の順番がT→Bの順だったり、B→Tの順だったりと、ときどき入れ替わってました。
つまり、ボトムフィールドを間引いた次ぎは、トップフィールドを間引く、
という様に間引くフィールドを交互にして、ずれが2フレームにわたって酷くならないようにしてるみたいです。

>>150
＞>>148の説明を良く読んで見た
＞でも、どう考えても
＞＞実はソースがプログレッシブの場合に、問題無く出力するためです
＞とは読めない
＞プログレッシブで問題がないようなのは２フィールドで時間的ずれ
＞がないためで、そのようになるようにこんな仕様にしたとはとれない
＞言い換えると、原因と結果を取り違えていると思う
なるほど。偶然だって言うわけね。
でも、フィールドの順番入れ替えたたりと、偶然にしては面倒な処理をしてると思うよ。
わざわざ面倒な処理をするからには、目的があると考えるのが普通だと思うのだが?


>>151
＞抜けるのがボトムフィールド部分でなくトップフィールド部分なら
＞この説明でもプログレッシブでもズレるよね。
そうですね。でも、実際にずれてないところを見ると
はじめはボトムフィールドから間引くみたいだね。
ずれないようにするために。そんだけ。

>>152
＞Video信号の垂直ブランキング期間にフレームバッファに書き込む
んなことしてないよ。っていうか俺がいちいち説明するのもメンドイし
ちょっといいページが見つかったので、これでも読んで理解してね。
http://www.hinet.cs.ritsumei.ac.jp/~kukky/DirectX/ddex1.html

＞また、ストリームデータといっているが、まさか
＞MPEGヘッダやフラグ、タイムコードつきのデータをそのままポンと
＞渡して、『さあ表示してみろ』とか言わないよね
うん、そんなことは言ってない。
121の人が、ビデオカードに渡すデータをあまりにイメージデータとしてしか捕らえてないから、
そうではなくいということでストリームと言いだしたの。
＞マクロブロックのデータを用意して、ベクトル方向とかiDCTテーブル
＞とか渡して部分的に書いてもらうんだよね
うん。>>133でそういうことを言ってます。ベクトル方向とかiDCTテーブル
のデータを並べて、ビデオカードに順に処理をしてもらうので、
ストリームって感じでしょ？

>>153
ぼろが出過ぎだぞ。「iDCT支援」「MC支援」なんてなんだよ？
DVD再生支援の機能のIDCT、MCだ。

で、君が想像しているiDCT支援、MC支援というのはどういうものなんだ？どう考えてるんだ？
外部の演算装置みたいに考えているのかな？
説明希望。
前もって言っておくが、メインメモリー上にイメージデータがあると考えると、かなりぼろが出るよ

＞それよりもちょっと興味があるのは、107が言う「フィールドの間引き」ってのはいったい誰がやるんだ?
グラフィックスチップがビデオエンコーダーにデータ渡す間で、どちらかがやります。
まあ実際はグラフィックスチップがやってると思うけど。


なんか話の大まかなところをいまいち理解してもらえてないと思うので説明するけどさ、
俺とおまえらでは、水晶のズレによる問題が起きる場所の考えが違ってるんだよね。
わかる？

CPU、ビデオカード、ビデオエンコーダーの、三つのブロックに分けるすると
俺はCPUとビデオカードは同期してるのでデータ受け渡しには問題が生じてなくて、
ビデオカードとビデオエンコーダー間で同期の問題があるので、
間引いたりして対処するために、完全なTV出力になら無い、と言ってるの。

おまえらはビデオカードとビデオエンコーダーが同期していて、CPUとビデオカード間で同期してないために
問題が生じて、完全なTV出力になら無い、って考えてるわけだよ

この違い、わかって議論してる？
>>158に特に言いたい。
＞この問題の本質は簡単に説明できるのです。
なんてぬかしてるけどさ、お互いの考えでオーバー／アンダーフローが生じる場所違ってるから、
フィールド構成の話とかの話をもってきて、ビデオカードとビデオエンコーダー間で同期の問題がでてる
ことを言いたかったのよ。
話を簡単にまとめ過ぎんなよ

返事書くの疲れた・・

ビデオエンコーダとは、DirectShow Filterのことであって
これは紛れも無くアプリですよ

ビデオエンコーダがVideo信号発生器のことなら
これは、Videoチップとは無関係に
Video信号のタイミングでフレームバッファメモリから
出力データを発生します。

逆にVideoチップ側（本当はアプリですが）では
書き換え途中の絵が出力されないように
ブランキング期間に一斉に書き換えます

>>161
そのページをみてみた
まさにアプリケーションがやる内容が書かれているね
どこにもVideoチップがやる内容はない

なるほど、ダブルバッファとフリップは分かった
でも、ダブルバッファに書き込むのはやっぱりアプリで
アプリが間に合わなければ出力できないね

また、フィルムからのキャプチャがフィールド順が入れ替わって
いたとのことだが、
フィルムは、24fpsを30fpsにしたあと通常編集というもを
行います。（切り貼りですね）
無神経な編集だと、このときフィールド順におかまいなしです。
それでもテレビでみるには問題が全くないんですね
（テレビにはフィールド順の概念はありません）
アニメをキャプチャすると、途中でフィールド順が
入れ替わる番組も少しはあります。
（最近はキャプチャのことを考えてかマシになっています）

>>164,165
ビデオエンコーダってのはNTSCの出力チップのことです
こんな基礎の返事するのメンドイ
>>166,167
ソフトでもハードでもやることは同じ
メモリー空間的に別の領域に2つのフレームバッファを取るのが普通です

ダブルバッファからVideo出力用のバッファに転送（Videoチップがやる）
するのはやっぱりブランキング期間ですね
（ダブルバッファは縦横解像度や色深度その他、アクセスタイミングで
　そのままVideo出力用のバッファとはなりません）

だれと話をしてるのかわからないぞ
出来れば名無しはやめてください
もう寝る

Videoチップというよりドライバだよ

また、ダブルバッファの切り替えもアプリのお仕事。
（Video側には、何時そのフレームの書き込みが完了したのかは
　分からないんだよ）

そうなのか
だとすると、Videoチップ側で、Video出力用にダブルバッファを
用意すればいいのかな。
（でもいつそのバッファに転送したらいいのかわからないね）
また、さらに２つのバッファを用意して転送するなんて
すごいオーバヘッドだね

だからそのタイミングはフリップされている裏フレームから
常に転送されるんだよ。
要するに、アプリが書くタイミングに結局左右されるということ。
（従って、Video信号用にダブルバッファは無用の長物）

>>168
テレビにフィールド順が無いんならキャプチャしてどうして
逆転するの

>>174
直接ダブルバッファからビデオ信号を作ったらどうしていけないの

>>175
NTSC信号では、色の副搬送波が１ライン毎に周期が逆転していて
奇数個（525本)の走査線で１画面ができているわけだ。
つまり、キャプチャボードからすると、トップフィールドか
ボトムフィールドか判断できるわけ。
で、チップによってトップフィールドから開始するか
ボトムフィールドから開始するかが決まってるんだ。
しかも２フィールドを同時に１つのフレームとして取り込むので
フィールド順という問題ができたわけ。

ダブルバッファから直接変換すると、
さっき言ったように常に裏フレームから取り込むことになるけど
アプリはそんなこと気にしていないから、
Video出力中にフリップするかも知れないだろ。
そしたら、Video信号は何処のデータから作るんだよ。

でも、ビデオ用のバッファに転送中に切り替わったらどうするの。
ああ、フリップするのはビデオ側だから、転送がすむまで待たしたら
いいのか。
でも、それなら、直接ビデオ信号にしてもいいんじゃないかな。
でも、それなら結局フリップするタイミングに影響されるんですね。

やっぱり、Video信号用にもダブルバッファを用意して
２段構えの転送すればいいのに
でも、それでも結局フリップのタイミングに合っちゃうのか
難しいね。

ビデオチップができる処理って、iDCT支援、MC支援といっても
picture単位とか、slice単位でもなく、macroblockで
ルミとかクロマブロックを一緒に処理できるものかどうかもあやしいね。

ストリームはフロントエンドのアプリからDirectXにより各種フィルタに渡ります。
（この部分はシステムを介してアプリからアプリに渡ると理解してね）
各種フィルタでは、そのストリームを分解し、微細片のデータをビデオチップに
処理してもらうんです。
（ビデオチップからすると、動画データかどうかも意識しません）

あたかもビデオチップが画面を展開して独自のタイミングで書き出すなんて
主張は論外です。

最後に、ビデオチップからみると
わたされたデータは展開済のビットマップデータであり
BitBLTで渡されるものなんです。
（ダブルバッファでもここは変わりません）

ツッコミがくる前に、

もちろん、ダブルバッファに直接展開すればBitBLTは要りません。
でも、拡大縮小や重ね合わせなどで画像処理するので
作業用の仮想メモリサーフェイスで行うものです。
（画面表示用のフレームバッファは現在の画面とドットが１：１に
対応していないといけません。
でもMPEGデータは解像度が画面と異なります。）

オーバレイなんかではこのへんちょっとわからないんですが
もしかすると直接オーバレイサーフェイスで作業できるかも知れません

ボケていました。
フリップはオーバレイでないと意味がないですね。
また、各種フィルタは、元のアプリに展開済みのビットマップデータ
（AVI?)を戻すだけです。かってに表示したりはしません。
それをファイルにするか画面に出すかは元のアプリが行います。
もちろん、格納バッファとしてフレームバッファを指定することは
できると思いますが。

【強制ＩＤ表示】
あと１３４日！
http://corn.2ch.net/test/read.cgi?bbs=php&key=982591467&st=128&to=128&nofirst=true

>>182

また今度反論するからage。

　　　　　＼Ｖ／
　　　　（() ﾟДﾟ ） ＜ｼﾙｶﾖ!
　　　　（つ旦と）
　　　　と＿）＿）

>>185
スレの延命措置と考えてください。

みんな居なくなった？

また今度反論する

↑
こいつ本物のヴァカ？

遅レス失礼します
>>97
＞FrameBufferへの書き込みが完全に1/60秒に同期
＞していない限りは、見掛け上のフレームレートは変動するっ
＞てことを理解してよ。

FrameBufferへの書き込みは1/30秒で良いんです。
それをG400が奇数フィールドと偶数フィールドを別けてTV出力するのです。

それと、
OSタイマーでシビアなタイミングを規則正しく生成することが不可能というけど、
そんなこと言い出したらPCモニタ上でも正確にムービー再生できない事になります。
だからOSタイマーでそんなことする訳がありません。
VGAカードのクロックを使う筈です。

>>190
遅レスにも程があるぞ(w

誰か60fps動画に詳しい人、
↓に行って、60fpsの動画はありえないと言ってる人に何か言ってください。
おながいします。

ビデオテープに残ってる貴重な映像を…
ttp://tmp.2ch.net/test/read.cgi/download/1020096607/l50

>>192
あんたはそのスレの847？
ざーっと見たけどレベルが低すぎる。
ダウソ板の人間を説得なんかせずにこの板の適切なスレで聞き直したらどうか。
閑散としてるけど60fps専用のスレもあるぞ。

>>193
でも60fpsのMPEGは作れますよね？

>>194
MPEG1ならね。＝60p(480p)
MPEG2ではMP@MLの範囲では作れない。
30fpsのインターレース捜査。＝60i(480i)

捜査じゃなくて走査ね（ｗ

>>192
悔しい気持ちは分かるけど
ダウソするだけの馬鹿は放っときな。
私は60fpsのmpeg1はアリだと思ってますよん。
あの滑らかさはやめられんね。

#この板にも自分で確かめもしないでどうこう言う奴もいるもんなあ

>映画館のフィルムですら24fpsなのに、60fpsのﾊｲﾓｰｼｮﾝする意味が分からん。
>オリンピックでも録画するの？

激ﾜﾗﾀ

60fpsの動画を作る意味はある。
そんなものは見れば一目瞭然。
ただ、向こうの937が言うように
「元々無いモノを在るように見せてる」という面はある。
480iを480pに変換してるわけだからね。
個人的にはMPEG2の60iで保存して再生時にI-P変化してくれるカード
(RADEON8500とか)を使うのがいいね。もっといいのはテレビ出力。

それにしてもダウソ板のレベルって・・・・

I-P変化→I-P変換

よく考えたら320x240ならば別に480pじゃないし無駄な水増しもないな。
ダウソの連中は低画質賞賛の貧乏引き篭もり連中だから
情報削りまくってサイズが小さいだけで無条件に嬉しいんだろうな(ｷﾞｬﾊ

向こうのスレで欲されてるのは昔のバラエティ番組なんだね。
個人的にはそういうのに60pは無駄だと思う。
例えば歌番組にしても、ぁゃゃに60pは欲しいが
前川清を60pにしようと思わないでしょ。

ただ、60pを理解しないダウソの連中は馬鹿だね。

いやー今見てきたけど酷い状況だねまったく。
間違ったことをどーしてあーも自信満々で語るかね・・・
所詮はﾀﾞｳｿ専門だから仕方ないのか？