【Intel】 Quick Sync Video Part.7 【QSV】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
前スレ 【Intel】 Quick Sync Video Part.6 【QSV】 [無断転載禁止]©2ch.net http://echo.2ch.net/test/read.cgi/avi/1453245696/ i7とCeleronじゃ元々倍くらい差があるから、それが普通 てか、キャッシュも最低限なCeleronに期待しすぎ 重要なのはキャッシュとメモリか!ちょっとキャッシュが小さすぎたか まぁ4000円のCPUだからなw --check-features-html でデコーダの機能が表示されない たしかにテキスト形式だとうまく出るけどHTMLだとうまくいかないね。 SkyLake G3900マシン買ったからせっかくだからとffmpegのQSVエンコードを使って ハードウェアHEVCエンコードを試してみたんだけどフルHD動画でせいぜい倍速なんだね つまり60分動画をハードウェアHEVCエンコードしようとしたら30分はかかるということ ハードウェアエンコードだからもっと爆速かと思ってたけどそんなものなのか HEVCは未だ人類には早すぎる技術 ムーアの法則が死亡してるので楽々扱えるのがいつになるかは知らん ソフトウェアエンコならソースの3倍以上かかるんだから倍速変換なら爆速だろう お、おう・・・ あ、ありがたくエンコードさせてもらうわ(`ω´;)・・・ 速度が欲しいならNVEncがいいよ。フルHDで200fps超える というかG3900じゃ遅いよ。いいCPUならその倍出る >>268 あいにくRadeonなんだわ(´・ω・`) >>269 内蔵GPUに関してはG3900はほぼ最新作と遜色ない出来だった気が・・・ 試しにrigaya氏のQSVBenchmarkでrun_benchmark.batの3行目と4行目の末尾に 「 -c hevc」を追加して、avqsv入力でのHEVCエンコードのベンチマーク取ってみてほしい。 >>271 間違えた・・・ ×3行目と4行目の末尾 〇4行目と5行目の末尾 "%QSVENCC_PATH%" --avqsv --benchmark result_mpg.txt -i sample_movie_1080p.mpg -c hevc "%QSVENCC_PATH%" --avqsv --benchmark result_h264.txt -i sample_movie_1080p_h264.mp4 -c hevc >>270 内蔵GPUはHD510だからコア数はHD530の半分 GPUコア数がエンコ速度に影響するかは分からんけど、CPUキャッシュが2MBしかないのが致命的 キャッシュやメモリの速度が重要だからね 参考までに、俺の持ってるG3930は6700の半分くらいの速度しか出ないよ >>271 いいね。俺の持ってるG4500でも測ってこようかな >>263 そもそもQSVのHEVCは使う意味ないよ >>155 に出てるけどハードエンコで一番ビットレートあたりの画質が良いのはAVC(H.264)のLA-ICQだから つまりHEVC使った方が遅い上に画質劣るわけ HEVCはx265を使って亀のような速度でエンコしないと威力を発揮できない >>275 おお、ありがと。HEVCのベンチ結果ってあまり見かけないので気になってた。 余力があればG3930のHEVC main10のベンチ結果も是非。(-c hevc --profile main10) 細かい点だけど、i7-6700が<Kabylake>と判定されてしまってるのが、ちょっと気になるところ。 HEVCて「へぶし」って読むの? そういや最近i3-5010UとかいうCPUのノート買ったんだけどQSVどんなもんかな? >>274 > >>155 に出てるけどハードエンコで一番ビットレートあたりの画質が良いのはAVC(H.264)のLA-ICQだから > つまりHEVC使った方が遅い上に画質劣るわけ これは知らなかった・・・ AVC もしばらくはアレだったけど HEVC コーシーあるいはそれ以降まで待たんとダメなのかね >>274 rigayaは測り方おかしいから レートが「だいたい同じ」になるように恣意的にオプション弄って 「1枚切り出して目視で評価」、アホかと 普通にRDグラフ描いたらHEVCの方が断然良いから x264に迫るぐらいのビット効率になる >>276 このバージョンのQSVEncだとi7-6700がKabylakeになるんだよw >>280 rigayaは所詮プログラマーなんだよな 将棋ソフト開発者が実は将棋のド素人ってのと一緒 >>280 俺もその自信の源であるRDグラフというのを見てみたいな。 多分>>158 、>>161 、>>164 と同じ人だと思うんだけど、その時も言われてたとおり、 rigaya氏は全てわかった上でブログで見せるためのサンプルとしてフレーム比較してるだけだと思うよ。 >>282-283 重ね重ねありがとう。同じ設定だと10bitはビットレートが5倍くらいになるのね。 仕上がりの質も違ってるのだろうけど、x264みたいに10bitだとQP値の指定範囲とか変わったりするんだろうか? i7-6700の誤判定については、v2.70で直ってるんならいいんだけど、 そうじゃないなら一応報告がてらここで上げておいたほうがいいと思っただけっす。 結局RDグラフは出す気無いのかな ソフトエンコなら自分で試せるんだけどハードエンコは持ってないと試せないから根拠があるなら出して欲しいんだけどな あ、そうだ QSV-H264とQSV-HEVCだったらどっちの方が画質は綺麗? >>287 >>274 だけじゃなく、その話の中で出てる>>155 やそのリンク先の記事とかも読めばいいんじゃねえの・・・ そっか QSVだとまだまだ画質はH.264 > H.265なのか・・・ また逃亡かよ 文句言ってる奴のデータが一切出てこないな QSVを使いたい人って、画質そこそこでいいから速度重視なんじゃないの? HEVCなんて7700Kでも遅くて話にならないし。 誰がどんな検証してようと関係ないような。 結局は、H264って時点でQSV-LAICQ一択なわけだし。 nvencだとH.265 >>> H.264 なんだが… >>292 普通そうだよな qsvでもH.265>>>H.264だと思うんだがな 少なくとも俺のところでは同じビットレートならH.265>>>H.264に見える あるいはqsvではなくqsvencが抱えてる問題じゃないかな? >>294 同じビットレートと言ってもソースや設定によっても結果が変わるし、 そのあたりの条件を明示せんとなんとも言えんだろ。 あとHEVCじゃLA-ICQが使えないらしいし。 HandBrakeCLI にあるオーディオ コピーのフォールバックエンコーダー指定 QSVEncC でもできますか? rigaya氏のQSVBenchmark(20170108)のmpgファイルをソースにして、 QSV H.264/x264(8/10bit)/x265(8/10bit)/VP9(8bit)でエンコードを行い、 SSIM/ビットレート図を作成してみました。 http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3424.jpg この図にQSV HEVCのmain/main10の結果も重ねてみたいのですが、 当方はHaswellノート環境なので、QSV HEVCには未対応です。 そこで、QSV HEVCのmain/main10で1度に7パターンのMP4ファイルと ログを作成するバッチファイルを作りました。 内容物をQSVBenchmarkフォルダに置いてバッチを実行するだけです。 QSVEncC v2.70とffmpegのバイナリを同梱していますが、 不安な方は公式サイトのものを使うようにして下さい。 https://www.axfc.net/u/3820061.zip Kabylake環境をお持ちの方にお願いなのですが、ログ7種を取得していただき、 アップしていただけないでしょうか。時間もそれほどかからないと思います。 ログをいただけたらエンコード時間等も加えて画像を更新しようと思っています。 >>298 いつもありがとうございます。 いただいたHEVC main/main10の情報を>>297 の画像に追加しました。 速度の追加については今はちょっと時間がとれないので・・・。 QSV_HEVCを追加したSSIM_Bitrate図 http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3425.jpg どうせならNVEncやVCEEncも重ねてみたいとこですね。 VBR指定で5000/10000/15000あたりを測るバッチ作って依頼投げればいいのかな。 ゴガギーン ドッカン m ドッカン =====) )) ☆ ∧_∧ | | / / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ( )| |_____ ∧_∧ < おらっ!出てこい>>280 >>158 「 ⌒ ̄ | | || (´Д` ) \___________ | /  ̄ | |/ 「 \ | | | | || || /\\ | | | | | へ//| | | | | | | ロ|ロ |/,へ \| | | | | ∧ | | | |/ \ / ( ) | | | |〈 | | | | / / / / | / | 〈| | | / / / / | | || | | / / / / =-----=-------- | | rigayaさんの目視の結果と変わらないってことでいいのかな? >>301 当たり前じゃん >>300 は主観で物見ろって言ってんのにrigayaも>>297 も客観で語ってんだから お互いに話通じる訳ねーよ >>302 ? ちょっと意味がわからない 主観評価って目視のことじゃないの? >>302 よくわからないが、とりあえずアンカの付け方がおかしくないか。 お前さんは>>158 と>>280 と同じ人で、 × >>300 は主観で物見ろって言ってんのに ○ >>158 と>>280 は主観で物見ろって言ってんのに ということであってる? 「RDグラフ描いたらHEVCの方が断然良いからx264に迫るぐらいのビット効率になる」って そもそもどういうものを「RDグラフ」と呼んでるのかもよくわからないが。 >>304 ごめん、同じ人じゃないけど、確かに書き方の変だったわ 「>>300 が挙げた奴らは〜」だな >>303 こいつらが言う目視って直で動画見ろって事なんだろ? 動画直で見て、H264 ICQ=26 と HEVC main ICQ=26 比べてみたけど、あまり変わらないね 細かい所よく見るとH264の方がきれいな気がする この動画実写だから、アニメだと変わるかもね >>308 実写は複雑で情報量も多いし、その組み合わせだとSSIMでもあまり差が無いから目視では色々きついと思う。 誰もが問題なく入手できて少なくともYoutubeよりも高画質なFHDアニメサンプルでもあれば、試してみたいところ。 >>297 、>>299 の続きとして、NVEncとVCEEncのSSIMログ取得用バッチも作成しました。 環境が無いのでオプション指定で失敗していなければいいのですが。 ■NVEnc 3.13用(要Pascal環境) → https://www.axfc.net/u/3820325.zip ・基本オプション(--aq、--aq-temporal(H.264のみ)付きも含め計21パターン) --avcuvid -c *** --profile *** --vbrhq *** --ref 3 --bframes 3 --lookahead 10 --output-depth ** ■VCEEnc 3.06用(要Polaris環境) → https://www.axfc.net/u/3820330.zip ・基本オプション(--vbaq、--pre-analysis付きも含め計18パターン) --avvce -c *** --profile *** --vbr *** --ref 3 --bframes 3 --b-pyramid 同梱バイナリだと不安な方は公式から個別にダウンロードを。 Nortonが同梱DLLを検疫してたので、検疫によるDLL欠けなどにもご注意下さい。 Pascal、Polaris環境持ちの方にお願いなのですが、ログを取得して上げていただけないでしょうか。 結果を>>299 の図に反映したいと思っています。 3DCGアニメならクリエイティブコモンズの物がいくつかあるけど日本式のアニメでそういうのは見当たらないからエンコードの試験評価は難しいよね いや今回の件だとエンコードの成果物は上げなくてもいいから著作権は気にしなくていいか >>310 https://www.axfc.net/u/3820359.zip VCEEncエラー出てたからコマンドプロンプトに出てたログも一緒に入れておいた ちゃんと出力はされてたから大丈夫かな いや、VCEEncのHEVC出力はサイズがめちゃくちゃ小さかったわ。2MBとかw >>313-314 ありがとうございます。 VCEEncのエラーですが、ログを見ると環境がAMF1.3となっているので、それが原因ではないかと思います。 AMF1.4で実装されたオプションも使っているため、ドライバの更新が必要になるのではないかと。 ログからはそちらのドライババージョンはわかりませんでしたが、 AMD Radeon Software Crimson 17.1.1 以降が必要とのことです。 Windows10なんだけど外部GPUとQSVの併用って出来なくなった? QSVEnc使おうとしても下記のエラー吐くんだけど qsv [error]: D3D9Device: Failed CreateDeviceEx: -2005530516. qsv [error]: Failed to initialize HW Device. : null pointer. qsv [error]: Failed to CreateHWDevice. : null pointer. auo [error]: null pointer. 2.39の米欄と同じだな 最悪DP問題みたいにiGPUとdGPUで同じモニタに出力するといいかも >>319 重ね重ねありがとうございます。 VCEEncのH.264エンコードのログを見ると、H.264のエンコードなのに Bframes is not supported with HEVC encoding, disabled. というメッセージが出てBフレーム無効にされていたので、一応rigaya氏のブログに報告しておきました。 >>299 の画像への追加はなるべく早く行おうと思います。 アニメでも測ってみた。使ったのはビビオペOP(テロなし) 1080p 24fps AVC 42Mbps https://www.axfc.net/u/3820427.zip 全体的に低めに出てるのは元動画にディザがたくさんあるからかな なんかSSIM低いと思ったら、ffmpegの引数の入力ファイル指定の順番入れ替えたらSSIM変わったw バグってるなww >>322 うーん・・・なんだろう、ソース由来だろうか。 以前直接ファイル指定するとSSIMの値が低くなってしまうケースがあって、 よくわからないので仕方なく入力を全部avs経由にしたことがあったような・・・。 あと、グラフ化はまだ作業中なんですが、>>321 のVCEのログで Found NALU with forbidden_bit set, bit error? というメッセージが出てたのが気になりました。(デコード警告?) >>323 逆にすると高めのSSIMが出て、このm2tsをavs経由で入力すると同じ値になるから、この高めの値が本物っぽい 測り直してくるわ この警告なんだろうね。ソースのストリームがおかしいか、デコーダがおかしいか、 だけど、ソースは自分で作ったわけじゃないし、おかしいわけないんだよな ごめん、どうやらVisual Studio 2015のx86版をインスコしてなかったのが原因だったみたい ただ、QSVEnc 2.70だとやっぱエラーでエンコ出来ないや・・・ 2.69だと問題ないんだけどね >>317 >>325 QSVEnc 2.71 ・2.70でdGPU付きの環境だと正常に動作しないことがあったのを修正。 ・2.70で起動が遅くなっていたのを修正。 ・la/la-hrdでビットレートが表示されていなかったのを修正。 >>320 ブログでrigaya氏からの回答があったので概要を貼り。 ・メッセージをHEVCと誤表示してしまっているだけで、Bフレームがサポートされてないというのは正しい。 ・Polaris(RX 4xx系)のH.264エンコードはBフレームに対応していない。 ・以前所持していたRX 3xx系でもBフレームありにしたほうが画質が悪かったと思う。 >>299 に>>319 のデータやエンコード速度を追加しました。 http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3426.jpg ◎>>310 のオプションについて ・NVEncの--aq-temporalはほぼ変わらず。 ・NVEncの--aqは少し良くなった。 ・VCEEncの--pre-analysisは結果に変化無し。 →参考: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/66 ・VCEEncの--vbaqは、H.264だと結果に変化無し。HEVCだと少し良くなった。 ◎感想 ・QSVとNVのH.264はなかなか ・QSVとNVのHEVC-mainも、H.264には劣るもののそこそこ ・QSVやNVのHEVC-main10のSSIMは正しいのだろうか? x264/x265の10bitも8bitに対する優位性が見えない。 10bitのSSIMは8bitのものと同じ測り方でいいのだろうか? ソースが8bitだということも関係するのだろうか?よくわからない。 ・VCEの幸の薄さがやばい >>321 を測り直した https://www.axfc.net/u/3820881.zip 高めの値になってるけどアニメだとこんなもんなのかな >>327 おぉ、ありがとう QSVとNVあまり変わらないね。NVの方が速いし >>328 ありがとうございます。グラフ化しました。NVのaqとVCEのvbaqは、こちらではいまいち。 http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3427.jpg ただ、HEVC-main10がやけに良いなと思って少し試していたら、 A: ffmpeg.exe -i src8bit -i out10bit -lavfi "ssim;[0:v][1:v]psnr" -f null B: ffmpeg.exe -i out10bit -i src8bit -lavfi "ssim;[0:v][1:v]psnr" -f null とでは結果が異なり、Bの方が良い数値になるということに気づきました・・・。(>>327 はA、328はBでの計測) 最初に入力した方のフォーマットにあわせて計算してるのかな。 8bitソースで8/10bit出力を公平に評価するなら、全てソースを10bit化した上でエンコードさせて C: ffmpeg.exe -i src10bit -i out8/10bit -lavfi "ssim;[0:v][1:v]psnr" -f null で10bit基準のSSIM値(?)で比較したほうがいいんだろうか? それともソースが8bitなんだからAで比較してしまっていいのだろうか? 諸々踏まえてバッチの更新も考えてみます。 もう何がしたいんだかわかんねーな エンコ後の結果が全てなんじゃねーの? >>330 オマエが馬鹿なだけ。ていうかエンコに関心無いなら見るなよw >>329 こっちまでやってくれるとは思ってなかった。ありがとう! まとめると↓こんな感じかな 実写 NV,H264 = QSV,H264 > NV,HEVC = QSV,HEVC > VCE アニメ NV,HEVC = QSV,H264 > NV,H264 = QSV,HEVC > VCE 10bit基準か8bit基準かは、10bit基準の方がいいのかな 10bitを使う理由は、暗いところやバンディングがあるから、 10bitでエンコしたのをバンディングの出る8bitに落として 比較するのは、利点を潰した土俵で比較してるように思う まぁ、ffmpegが8bitと10bitを入力したとき一体何を計算してるのか よく分からないところがあるがw エンコしたやつ見ても、これくらいの差だと、エンコで出たノイズに関しては 両者あまり変わらないように見えて、暗いところやグラデーションは 10bitの利点はちゃんと出てたから、俺的には10bitの方がいいと思った >>332 いくつか実験してみたところ、 ffmpeg.exe -i out8/10bit -i in8bit -lavfi "ssim;[0:v][1:v]psnr" -f null という入力順で計測させて、10bit出力の場合は10bit基準のSSIM値になるようにすれば 公平な比較になりそうだという結論になりました。 つまり、>>329 でNVのHEVC(main10)が良い結果になってるのは公平な結果なのだと思います。 逆に、>>327 ではHEVC(main10)のSSIMが8bit基準の値になっており、少し不利な結果になっていると思います。 一応、>>327 のQSV/NVのHEVC(main10)だけやりなおすバッチと、>>329 にx264の結果を足すためのバッチを作ってみました。 https://www.axfc.net/u/3821112.zip もし気が向きましたら、よろしくお願いいたします。 >>333 https://www.axfc.net/u/3821172.zip x265の結果も追加した。x264/x265はCore i7 6700のPCで実行した結果 >>334 ありがとうございます。こちらでもx26x 10bitのSSIMを測りなおし、 >>327 、>>329 の図を更新しました。 ■実写(sample_movie_1080p.mpg) → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3428.jpg ・NV-HEVCで、main10がmainより悪いのが少し気になる ■アニメ(ビビオペOP1080p) → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3429.jpg ・NV-HEVC、特にmain10がかなり優秀 ・QSV-HEVC(main10)が高ビットレート領域で伸びそう ・QSV-HEVC(main)の伸びが少し悪いのが気になる 基本的にはNVとQSVのH.264が安定していて、アニメなど圧縮しやすいものでは NV-HEVC(main,main10)やQSV-HEVC(main10)が力を発揮しそうという感じでしょうか。 何度も協力していただき、ありがとうございました。 ちょっと時間が必要ですが、計測用バッチはもう少しちゃんとした形に整理して公開しようと思っています。 >>335 です。 測定パターンを選んでから動画ファイルかavsファイルをD&Dするとエンコード&SSIM測定を行い CSVファイルにまとめて出力するという形ができつつあります。 出力する環境情報をQSVEncC.exe --check-environment等で調べたいのですが、 例によって当方はHaswellノートのため、それ以外の環境での出力結果がどうなるのかわかりません。 テスト用バッチを作りましたので、ログ収集にご協力いただけないでしょうか。 最新のQSVEnc v2.71、NVEnc v3.14、VCEEnc v3.06を想定しています。 ■dGPUのある環境の方 ■AMDのCPU(Ryzen等)環境の方 Test_QSVEnc.bat https://pastebin.com/zdkmxMTn ■NVEnc対応環境の方 Test_NVEnc.bat https://pastebin.com/3FpwAREC ■VCEEnc対応環境の方 Test_VCEEnc.bat https://pastebin.com/LwmjtBWr ***EncCのx64フォルダ内にバッチを置いて実行していただくと、Log_***Enc.txtというファイルが出来ますので それをどこかにアップしていただければ幸いです。よろしくお願いいたします。 >>337 NVEncのログありがとうございます。参考にさせていただきます。 --check-features と --check-environment で GPU: Unknown (error on OpenCL clGetDeviceInfo) となってるのがちょっと気になりますね。 --check-deviceの方で出ているのでそちらを見ればよいだけではありますが。 x264ベンチマークスレで、 「CPU-Zでシステム情報を収集してそれをテキスト化し、x264/x265ベンチマーク結果とあわせて出力するバッチセット」 を作っています。 http://egg.2ch.net/test/read.cgi/jisaku/1460032466/827 このセットにサンプルとしてQSV等でのHWエンコードのベンチマークバッチも付けているのですが、 Kabylake環境の方で、以下のURLに書かれている動作検証とICQ値調査に 協力していただける方がおられましたら、よろしくお願いいたします。 http://egg.2ch.net/test/read.cgi/jisaku/1460032466/835 以下の2つのバッチファイルで --icq 20 としている部分を書き換えてダブルクリックするだけで結果が取れるはずです。 「_HwQ02__QSVEncC_HEVC_main_avqsv_ICQのベンチマークだけ実行.bat」 「_HwQ03__QSVEncC_HEVC_main10_avqsv_ICQのベンチマークだけ実行.bat」 バイナリは一応同梱してありますが、心配なようなら差し替えて下さい。よろしくお願いします。 ffmpeg使ってh264_qsvエンコードしてる できれば最大ビットレートをある値以上にならないようエンコードさせようと思って -maxrate ***k みたいなオプションを指定してるんだけどどうも***kビャbトレートに必bクしも 抑bヲきれてない場緒鰍烽るっぽい=B-maxrateオプャVョンだけじゃ麹ナ大ビットレーャgって 指鋳閧ナきなかったb閧キる? ちなみにコマンドラインはこんな感じ ffmpeg.exe -rtbufsize 256MB -r 30 -i input.mp4 -c:v h264_qsv -r 30 -s 640x480 -sws_flags accurate_rnd+lanczos -pix_fmt yuv420p -vf "hqdn3d=15" -b:v 500k -maxrate 500k -bufsize 500k -preset veryslow -profile:v main output.mp4 Autoconvertでqsvenc使ってるんだけど、アニメと映画だと90fpsくらいでエンコできるのにバラエティとかだと20fps以下になってしまう。 原因がわからない 元動画フレームレートが違うのかな... 解像度同じ、mediainfoで見たフレームレートも同じ。 原因わからないなぁ >>341 、>>343 AutoConvertは使ったことないからわからないけど、遅くなる原因はエンコ前の処理なんじゃないの? そこまで遅くなるなら、そっちの可能性が高いから、QSVは無関係だと思う。 まずは原因の切り分けだね。 A's converter使ったら200fpsでたわwww 乗り換えるしかないかな お、おぅ・・・そりゃ面倒なことをあまりしないトランスコードなら速くて当たり前っちゃ当たり前だが・・・ んー、なんかバラエティとアニメのエンコ後ファイル見たらビットレートが12.7Mbps、3726Kbpsになってたわ。 ビットレート指定とかできるのかなぁ アニメ映画は止まってる部分は完全に止まるしキャラの動きもほぼ3コマ打ちで3コマに1度しか動かないから エンコーダーにとって好条件ではある 加えて制作フレームレートは24P バラエティはカメラもよく動くしカット数も多いしそこにどかどかテロップも入って 制作フレームレートは60i より厳しい条件になる 動画圧縮は基本的にじわじわ動くのをターゲットにしとる バラエティのQSVエンコ中にgpu-zでクロック確認したら全く上がってなかった。使用率も低いし。 アニメのWSVだと最高クロックに張り付いてるのに。。。 Autoconvertはavisynthて言うの使ってるみたいなんだけどこれ原因の可能性あるかな? 自己解決しました。 Avisynthのスクリプトを書き換えてマルチスレッド処理させるようにしたら処理が5倍速になりました。 QSVの問題ではなかったようです。 VAIOのF23というノートを買ったんだけど、QSVがつかえなかった。 まさかノートにビデオカードが搭載されてるとは・・・ スレもあったんだけど、さすがに年月が経ってるので人がいない。 QSV使う時だけ切り替える技は無いかな? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる