【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/ >>562
たしかになんか変だね。うちでさくっと試した感じだと以下のような感じ。Win10FCUのi7-4702MQ/HD4600。
・ソースがH264.mp4だと、うまくいく。
・ソースがH265.mp4だと、ログはコマンドが表示されたところで止まり、
エンコードはされているようだが、「出力を中断」しないと結果が戻ってこない。
・ソースがMPEG2.tsだと、H265.mp4の時と同様でうまくいかない。
・出力の中断を行った後もQSVEncCのプロセスが残ったままになることもある。 3.01にしたらQSVでリサイズとかインタレ解除とかされなくなってしまった(´・ω・`) >>565
インタレ解除の際、--interlace tffは指定してる?
うちだと
・インタレ解除は効く (--interlace tff --vpp-deinterlace normal)
・AviUtlからだとリサイズ(--output-res 1280x720)の設定がQSVEncCに渡らない。
(AviUtlからではなくQSVEncCで直接指定すればちゃんと効く。)
という感じだった。後者はバグかな。
あと一応環境だけでも書いておいたほうがいいと思う。
QSVEncC (x64) 3.01 (r1416) by rigaya, Apr 21 2018 21:45:16 (VC 1900/Win/avx2)
OS Windows 10 x64 (16299)
CPU Info Intel Core i7-4702MQ @ 2.20GHz [TB: 2.90GHz] (4C/8T) <Haswell>
GPU Info Intel HD Graphics 4600 (20EU) 200-1150MHz [37W] (20.19.15.4835)
Media SDK QuickSyncVideo (hardware encoder) PG, 1st GPU, API v1.20 プロファイルでオプションが
-c h264 --output-res 1280x720 --icq 21 -b 2 --gop-len 15 --sar 1:1 --videoformat ntsc --profile High --vpp-deinterlace normal
と設定されてるんだけど
aviutlからのエンコード中の画面を見るとうちもリサイズが抜けてた
https://i.imgur.com/IBRG56W.png >>566
AviUtlからの話でした(`・ω・´)
環境書こうと思ったら3.02がアップされていたので
こちらで試してみて何かあれば報告しようと思います
ありがとうございましたm(_ _)m コーヒーにしたけどやっぱりH.265は激遅やな
H.264はアホみたいに速いけど なにからコーヒーの何に変えてH.264どれくらい早くなってるの? QSVEncC で he-aac 音声使いたかったので fdk-aac 有効で ffmpeg shared ビルドした。
残念 ffmpeg のオプション受け付かない
LC で libfdk-aac 使えたのでまあいいか 24EUのGT2でならSkylake世代で少し速くなってる
現状でのQSV最速はi7 6770HQの72EU+eDRAM128MBなGT4e
ただし相応なSO-DIMMのOCメモリが無いとメモリがボトルネックに、
次いでBroadwellデスクトップのGT3がOC出来るお陰で速いが相応なDDR3のOCメモリが無いと以下同文 GT2でHEVCだとLA-ICQで40fpsちょいぐらい?
H264だと速度出る分設定で前後するけど180〜240fpsって感じかね
高速で処理するH264の方がメモリ性能の影響を受けやすい傾向 注意点としては、i7 6770HQのEU規模になるとQSVのエンジン側の処理ペースに対してEUが過多みたいで、軽くてブン回るH264だと72EUを持て余し気味になっている様で、処理速度は少し伸び悩む
お陰でH264の場合はBroadwellのOCしたGT3eよりは速いんだけど、差はさほど大きくは無いので、HEVCの方がメインじゃ無いと利点は薄いかも
それでもHEVCのFHDを倍速処理まで行けるか微妙なんで、型落ちでも導入単価高くてコスパは相当に悪い
それなら電気食うけど8コアRyzenでx264をfasterで処理した方がQSVのHEVCより縮むし速いし再生環境で困らないという(スレに造反するけど 4790Kから8700だけど
x265とスピードたいして変わらんのよねw うん、だから数倍の消費電力厭わなければ、上位モデルのCPU使ってる人だと、QSVのHEVCはH264からの速度低下激しすぎて、立ち位置微妙になってきちゃう 自分のCPUでHEVCソフトエンコすると4fpsくらいだから
QSVの40fpsは快速ですわw はやいQSV(H.264)のCPU教えろください。 現時点ではIris Plus 640,650搭載CPUかな sandyの2700kだけど
ソースがUt VideoだとQSV(H.264)で最初300fpsで後半100fps出てる aviutlだとx264のソフトエンコードと
x265のQSVエンコードだとそれほど時間は変わらない x265になんかオプションつけたら
処理全部QSVに丸投げとかになったのかw >>590
なるほど・・・ちゃんと読んでなかったわ、すまん。 QSV厨『QSVの40fpsは快速ですわw』
↓
NVの俺『平均で200fpsだが…』
↓
QSV厨『ぱよぱよ…ち〜ん…』 NVは最低が1050になった時点でふざけんなって感じだが
710でできた時代は良かったんだな nvenc使えない1030とか何に使うねん
ただ映すだけならもっと安いのでいいし 前モデルのGM208でもNVEnc積んでないから、GP108に積んでないのに文句言っても今更だしな
NVEnc初期世代のGK108が使えてたってだけだし GT1030でもCUDAは使えるから、軽度のCUDAフィルタ使う環境下なら、その分CPU負担は削れるぐらいだな
現行品としてならTDP30Wで済むうえ、Lowprofileの1スロのも有るんで、今のところRyzenのエンコ機に入れてるけども Ryzenグラフィックス無しは不便だよな
IntelのGT1くらいを付けてくれるのが一番使いやすい
(GT2は微妙な性能で要らんが) Intel HD Graphicsドライバ 24.20.100.6094
対応CPU Skylake、Kaby Lake、Coffee Lake、Apollo Lake、Gemini Lake
対応OS Windows 10 64bit
【新機能】
Handbrake、VLC、およびその他特定のアプリケーションにおける
ビデオエンコード/デコード性能の向上 qsv-h264で変換しているけど、bs11だけ5倍ぐらい時間かかる。なんでかわかる人いますか? >>600
24.xxxって自分でDLしないと、ずっと15.xxxが最新って出るんだね 使っているエンコーダも比較対象元も書かず
他のエンコーダを試して言っているのかも解らんよ
そんなんじゃ、一番疑わしいのはそんな把握状態で運用している奴の性って事ぐらいしか言えない 詳細書かなくてすいません
エンコーダーはqsvenc2.5(x64)を使ってる
地上波とbsフジとかは10分ぐらいで終わるけど、bs11だけ50分ぐらい毎回かかる
ついでにHandbrakeだとbs11が20分ぐらいで終わる
とりあえず最新バージョンにあげてみるか。。。 オプション統一していなくて、オート判定頼みでエンコしてるからじゃないの?
地デジやBSに大半は今回の再編の影響も含めて1440x1080の16:9引き伸ばしだし
BS11や一部のチャンネルだけ1920x1080
後者の方は出力ピクセル量やマクロブロック捜査だけでも3割増だし、先読みさせていたら輪を掛けて処理手間増える
出力解像度統一するなり、audioはcopyで済ますなりしてみた方がいい QSVのインターレース解除ってウンコ画質なんだが…
SandyからSkylakeに乗り換えたら綺麗になるのか?? >>606
インタレ解除はRadeon>Intel>GeForceらしいね >>608
それ、再生支援の時の話ね
HWエンコは基本、プログレソースを想定してるからインタレソースはほぼウンコ画質なのよ >>610
>>606-608はインタレ解除の話をしてるのに、なぜインタレ保持エンコードの話を持ち出すのか。 Win10でも使えるVirtuみたいのありませんか?
またはグラボ付けててQSV使える方法とか。
ええ、Z68ですわ。 >>611
してねーよ、>>608の話がよく出るのはインタレ保持エンコ時の話で、インタレ解除エンコ時は全部ウンコと言ってんの >>613
俺の理解不足かもしれないけど、GPUのインタレ解除機能の利用には
1.QSVEnc/NVEncの --vpp-deinterlace
2.AvisynthのD3DVPフィルタ
3.LAV Video DecoderのCUVID/QuickSyncのGPU Deinterlacing
4.再生時に必要に応じてレンダラで行われるインタレ解除
といった方法があって、>>606が言ってるのは1か2の話だと思うし、
「1、2」と「3、4」の違いは「エンコ前に解除する」か「再生時に解除する」かの違いだけであって
結果自体は(多分)同じだから、>>608は1〜4全てで成り立つんじゃないの?(まあAMDは1と3は使えないけど)
613の書き方だと、
「608が成り立つのは3と4だけで、1や2は全部ウンコ」
と言ってるように見えるんだけど、その理由がよくわからない。 >>612
単にマザーで内部GPU有効にしてるだけで何も小細工しなくても使えるよ >>614
横からスマンが、Radeonのハードウェアインターレース解除機能をAviUtlやAviSynthから呼び出して、インターレース解除してからエンコードすることは可能だよ
ただ、根本的な話を1つしておくと、「PCでできるインターレース解除」という前提条件付きならばRadeonのインターレース解除機能を使うのが1番良いけど、
レコーダーやプレーヤーも含めていいのであれば、インターレース解除の品質はRadeonよりいいものもあるから、レコーダーでインターレース解除してから
HDMIキャプチャーするという手もある インタレ解除エンコしたらその時点で画質確定してしまうが
インタレ保持して再生時に解除すれば高性能なGPUが出る度に
画質改善していくからその方がいいと考えてるんだけどこれって間違ってる? >>617
でも実際のところGPUのインタレ解除機能の進化状況ってどうなってるんだろうね。
昔と比べてそんなに変わってるもんなのか、それなりにちゃんと進化してるもんなのかもよく知らない。
>>608の「Radeon>Intel>GeForce」って評価も、かなり昔からそういう風に言われてるだけな気もするし、
純粋にインタレ解除機能を比較したんじゃなく、他の画質補正も含めた評価だった可能性もあるかもしれない。
今の最新モデルでちゃんと比較してみたら、また違った評価になるかもしれないね。 >>617
Polaris以降ベクター適応やモスキートノイズ除去等の動画周りの機能が大幅に削られているRadeonの現状見ても
インタレ解除なんて今後退化する一方かと >>621
それはユーザーがイジる必要なくなっただけ >>615
内部GPU ONでも実際にケーブルつないでモニターに映してないと
インテルのメディアコントロールすら立ち上がりません。
BIOSで内部GPU優先にするとモニター1つではBIOSのPOSTが見えなくなるので
いざという時困ります。
モニター2つ使いたくない場合はダミーコネクター使うしかないんでしょうかね?
Z77ではなくZ68+2600Kです。QSV+外部GPUが使える一番古いやつです。
VirtuはVirtu/Universal/MVP使ってみましたがダメでした。 画面出力してないとインテルのコンパネ出ないというのは現行世代でもそうだから
QSV使いたいだけならQSVEncなんかで使えるかチェックしてみたら >>623
ウチもasrockのz68マザー+2600kで、radeon7770でモニター出力していて、マザー側の出力は何も繋げてないけど、QSVenccは使える。Win7ではVirtuに登録する必要があったけど、Win10では特に何も設定しなくても使えてる。 >>623
ASUSのM4EZ+2700kでVirtu無くても使えてるよ うん、なんかできないからつけれないと思ってたHDMIを内蔵からモニターのセカンド端子に
挿してなんとなくQSV使えてるからこれで我慢するよ。 EU数って速度に関係ありますか?
例えばG4400 HD510 とG4500 HD530ならどうでしょうか。
関係ないって記事も見てどっちなのか分からないです… >>633
ありがとうございます。
速度差がある場合があるのなら、価格差も少ないのでEUが多い方にします。 一応、QSV的には関係ないとおもうよ
計算一般については多い方が可能性は広がるよ 大は小を兼ねるんだから、迷ってんなら多い方が良いでしょ >>634
EU数×動作クロック≒処理速度
あとメモリの速度が低いと、H264とか処理速度が出るエンコードほど足枷になる
逆に重いHEVCだと殆ど差が出ない x264で、2400と3400で比較しても2-3%UPぐらいだよ 2015年にNetflixの技術者が初めてMPEG会議に参加して、将来の動画コーディングのための文書を発表しました。
その際に、Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑性が高まるとしてもまったく問題にしない」というスタンスであることを伝えると、議長から「では、どのくらいの複雑さを許容できますか?」と尋ねられたとのこと。
回答の準備が整っていなかったNetflixの技術者は「最悪のケースでは100倍まで」と答えると、100人はいたであろう動画コーディングの専門家たちからは大爆笑が起こったそうです。
議長は「心配しないで。彼らはみな『新しいこと』を試すことができると、幸せに感じているのです。たいていの人は『3倍まで』と答えるものだから」と話したそうです。
実際に100倍の複雑性をもった動画コーディングが実現可能か、実現できたとしてエンコーディングや再生の環境が整うのかは大問題ですが、
テクノロジーの問題は時間が解決してくれるという楽観的な考えがあります。
全文はソースで
https://gigazine.net/news/20180614-end-of-video-coding/ 例えば Microsoft Video 1 と AV1 でどんだけ違うんだ
Indeo 激重とか言ってたあの頃w QSVなんてやるだけ無駄
ただ汚くなったファイルが返ってくるだけ H265にして初めて本領発揮だろ?
つまりSkylake以下はゴミw そんなこと言い出したらコーヒーしか買えなくなるだろ いやH265/HEVCの方がQSVエンコは速度低下激しくて逆に旨味が無いと思うぞ
x264が変態過ぎてQSVのHEVCより画質容量比良い結果出せるから、
40fps程度のエンコード速度なら4コア以上のCore iやRyzenでx264使った方が速くて綺麗で再生環境の敷居が低いという aac_coderへのプロファイル指定とか、ffmpegんところの解説のままaac_mainとかやるとダメで、mainと記事しないと通らなかったり 先の悪天候時の録画の処理していて
ドロップやエラー載ってるTSのVideoデコードだと、ffmpeg由来のQSVやDXVA2デコードより
QSVのCUVIDデコードが一番画像に荒れが出ないのな
速度面は二の次で、QSVEncでも使える様になってくれると、この手のTSをスポット的にピックアップするのが捗るんだが うぉ、消し違いや抜けてた
×QSVのCUVID
○LAVでのQSVとかCUVID handbrakeで720pの動画をhevcにqsvで変換してるんだけど、最初だけ500fps超えてて10分後くらいには100fpsくらいにまで低下するんだけど、これって普通? 設定どうしてるか解らんから憶測だが
処理開始と測定開始は必ずしも一致しないのと
入出力のバッファも有るから、メモリに先行投入されたフレーム分+出力バッファに貯まっていた分だけ最初に一気に出力されてフレームレート瞬間的に伸びてるだけなんじゃないの?
コンスタントに入出力が続いていけば処理フレームレートなんか変純化した値だから、本来の処理レートの近似値あたりで落ち着くようになるさ ivy使っている現状で、qsvのために今更だけどコヒーCPUを買おうと思っているんだけど、
チップセットの違いでエンコ速度って、有意な違いでるもんなのかな? 下位チップセットのマザーだとOCメモリ使えない分遅くなるのはあるんじゃね インテルはあんまメモリでパフォーマンス大きくないよな
結論的にCPUOCしないならH370だの310でも変わらんのちゃうか キャッシュ性能が良い分、特定コードぶん回すCPUベンチで差が出にくい
QSVみたいな断続的にフレームデータ出し入れし続ける場合には効いてくるけど
24EUのGT2なら、HEVCみたいに重くて処理フレームレートが40fpsとかまでに落ちるとメモリ帯域負荷が緩和されて、メモリクロックの影響が低くなる
H264の軽めの設定でぶん回すならOCメモリ欲しいところだけど、HEVCやH264でもLA-ICQで先読みフレーム数大きく取るならDDR4-2666のデュアルチャンネルとかでも構わないと思うよ
6770HQとかなら別だけど ■ このスレッドは過去ログ倉庫に格納されています