【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
NVEncとかが役に立たないからCPUパワーに任せて、
Ryzenの8コアとかでエンコードしてるのが現状だしな
GPUが使えれば、たくさん載せて爆速にできるのに >>403
CPUエンコとGPUエンコじゃ目的が違うんだからずっと平行線、比べる意味がない
よって、>>402が希望する目的でGPUエンコ出来る日も、一生来ない CPUによるディープラーニングとGPUによるディープラーニングも平行線なのか? >>404
俺が言ってるのはNVencみたいなのじゃなくてGPUでやるソフトウェアエンコードだよ
CUDAやOpenCLでやるやつ >>405
流れ的にエンコだけの話、ディープラーニングは知らん
>>406
しかし、そんなのこそ絶望的じゃなかったか？
CPUと同じ計算をGPUでやりたいんだろ？
コア数が数千倍多いのに計算結果は100倍遅いんだぜ… どの程度用途が限定されてるのかはよく判らんけど、
今NVIDIAが世界的に注目されてるのは、ゲームだけが理由ではないのは確か 動画圧縮は動き探索がキモだけど、GPUだと難しいからね
抜本的な並列性の改善が必要だけど、実装する人がいるか 注目されてるのはディープラーニングでしょ。動画圧縮関係ないじゃん >>273のやつは動画分野でも研究してるっぽいよ
http://www.wave.one/icml2017
静止画と違って既存技術との比較がないからまだ成果は出てないようだけど、まあ後10年くらいで実用化されてもおかしくないんじゃね 動画圧縮はMPEGの時代から長いこと動き補償がメインだったからな
ディープラーニングっていうこれまでとは全く違う方法で動画圧縮に
ブレークスルーが起こればいいなって思うよ GPUの中身が、何か画像処理だけに特化されたような作りになってると思うのは幻想だ
ただの演算なんだから汎用的な計算のレベルまで分解できて、だからこそ
GPGPU（General-purpose computing on graphics processing units; GPU汎用計算)という
アイディアが生まれる
GPUがディープラーニングにしか使えないと思っちゃうのは、もう理解不能 アルゴリズムは複雑ではないが計算量が膨大で並列可能なものに、機械学習や画像処理、物理演算が当てはまるからその分野ではgpgpuが威力発揮するんじゃないの
cpuのようなこともgpuで出来るようになってるから注目浴びてるみたいなソースでもあるの？ >>413
ディープラーニングが流行ったおかげで脚光を浴びるようになったのは事実
NVIDIAが「謎のAI半導体メーカー」って言われちゃうくらいだからｗ
http://www.huffingtonpost.jp/2017/05/22/nvidia_n_16746954.html >>415
並列化できるかどうかが問題でしょ
CPUみたいなせいぜい数十スレッド規模じゃなくて、数千・数万スレッド規模で 画面全体をいきなり扱うみたいなホログラフなことをしてる訳じゃなくて、
小さいエリアに分解してるんだから並列処理の代表みたいなもんでしょ
そもそも、NVEncでやってることをGPGPUにするとできなくなる訳がない NVEncの品質でいいならGPGPUでできると思うよ
でもNVEncがあるんだからGPGPUでやる必要ないでしょ
俺が言っているのはx265の品質をGPGPUで実現するのが難しいってこと
動き探索は複雑なアルゴリズムで計算量減らしてるから
単純化して並列化してもCPUに勝てないんだよ なんでそう考え方がアナログ的になっちゃうんだ
CPUがやってる計算をそのままGPUに代行させれば、1bitも違わずに同じものができる
それがコンピュータ そりゃそうだが、その代わり全く速くならないどことか、10倍以上遅くなると思う
数百動画くらい並列にエンコすれば速くなるかもしれないね つまり、並列化ができれば速いができない筈という予想な訳だ
画像処理は並列化は普通に大得意だと思う 一向にGPGPUを使った爆速エンコーダーが出てこないとこみると、
GPGPUは条件分岐が苦手で、エンコーダーが苦手なアルゴリズムが
含まれてるんだろうと予想はしてる 画像処理は並列化が得意とか、そんな一般的な話をしてるんじゃなくて
動き探索は並列化が難しいって話をしてるんだけど・・・ いや、Bフレームが無くていいなら、現状で爆速エンコーダはある
なんでBフレームを付けてくれなかったかというと、
それが難しいからというのもあるだろうけど、
サイズを縮めることはグラフィックボードの本懐ではないから
とにかく速く、リアルタイムで、ということを追求してるので、
既に帯域が足りてるところに遅くなるだけの処理を増やしたりはしない
やればできる子なのにやらないので、GPGPUにやらせようと あの大量に積んだGPUが穴掘りじゃなくエンコードに有効だったらよかったのに CUDAを使ったエンコーダーは実際に映像編集ソフトなどで既にあるんだが
確かにエンコードスピードは早くなるが一番良くて数倍程度で
併せてCPUの稼働もフルに近くなる
数千コアも使ってるにしては期待はずれな結果なんだが
何故こうなるかと言うとメモリが関係してくる
グラフィックカードの搭載メモリ量は多くて数Gバイトだが
これを何千もあるCUDAコアに割り当てると1コア当りでは１MBレベルになってしまう
エンコード作業に使うバッファとしては全く足りず頻繁にスワップが発生して速度低下し、
数千コア分のスワップを処理するCPUもパンク状態になってしまう
結局のところ、数千のコアが充分に動作出来るのは1コアが使うのが1MB程度の処理に限られ
それ以上の事をさせるにはコア以外の部分でスパコン並に大掛かりなシステムが必要になってしまうわけだ GPUが大の苦手なのは、条件分岐だってバッバが言ってた。
そしてソフトウェアエンコは条件分岐の塊だってジッジが言ってた。 全部自分でやるか全部任せるかの二択である必要はなくて
これ計算しといて、と切り分ける部分は先輩がやって、
新入りは意味も判らずひたすら計算、という図式が効率的 まだx265は開発中だしのんびり行きましょう
ちょうど10年前のx264も言うほど賞賛されていたわけじゃなかったし
今後メインストリーム帯のCPUコアが増えていくだろうからエンコの負担が減ることに期待してる >>432
先輩後輩間でコミュニケーション爆発が起きて低速化するというオチ GPUの並列計算はCPUのそれとは違って、似た事しかさせられんのよ
例えば(1,5,25,8,-3,0)といった入力値全てに対して2をかけろ
というようなことね
分岐が苦手なのもこれが原因
CPUに比べて沢山コアがある代わりに１つ１つの計算は遅い、なんて理解は間違い ほんと色んなとこにいるけどGPUを銀の弾丸みたいに思ってる人多い いまだにGPUに積んであるハードウェアエンコーダによるエンコードと
GPGPUによるエンコードがごっちゃにされてるくらいだし どんな用途にも使えるとは思わないけど、
動画の圧縮用途には向いてる気がする 単に削るだけの処理ならGPUは速い。
どうやって劣化を抑えて削るか判断する処理がGPUじゃお話にならないって事。
そしてソフトエンコする層は2つめを特に重視するので
WinWinにはならんの、どうあがいても。 GPUが分岐が苦手というのは原理の話だが現状もうその欠点を補う技術が開発されたうえでの話なわけで
原理だけで絶対論のように言うのはちと語弊があるんじゃないか だから得意な処理で役割分担しようってのがヘテロジニアス・コンピューティング 感覚的だなあ
GPUのエンコードは速いし綺麗
既に実証されてる
但し、サイズは相対的に大きい
Bフレームが無いから
無いのは困難だからじゃなくて、設計思想と合わないから
GPUはリアルタイムのエンコード処理を想定してる訳で、
それはつまり今撮影した動画をそのまま配信、とかのケース
未来のフレームなんてまだない
そもそも、片方向のエンコードはできるのに、両方向にした途端に
分岐が複雑すぎて処理できなくなる訳がない
近いうちにBフレーム付きのH.265がNVEncにも出るから、
その時に恥じ入ってくれ 恥じ入る準備は万全だが、〜訳がないてのは感覚的じゃないのか もし、H.265でCPUより高速で綺麗なGPGPUエンコーダーが出るなら、
H.264で既に出てる。 つか、この話は本当に動画圧縮アルゴリズムに詳しい人いないと無理だろ。
俺は長年プログラミングやってるけど、動画圧縮のアルゴリズムの詳細は
さすがに知らんわ。
画像処理くらいならSIMD使って最適化したことあるし、
画像処理の畳み込み演算とかまさしくGPGPU得意なのはわかるが、
動画圧縮はぽかーん？だわ。 2時間映画を同じビットレートでエンコしても30?ぐらいしか変わらない気する H.265のNVEncとx265比較で >>430に書いたようにCUDAを使ったGPUエンコーダーは業務用途で既にあって
別にリアルタイムエンコードに限った用途なんて事は無いし、
またH264では出てないなんて事も無いんだが >>448
徒歩と自転車で同じ時速で移動したけど到達時間がほとんど変わらなかったって言ってるようなもの >>451
それって、Kepler以前にCUDAでGPUエンコしてた時のGPUアクセラレー卜機能の事言ってだろ？
違うならその業務用ソフト言ってみ >>442
>>397で
・QSVならHEVCでもBフレームが使える
・H.264ならQSVでもNVEncでもVCEEncでもBフレームが使える（ただし環境にもよる）
と書いたのに、なんで「（GPUエンコでは）Bフレームが無い」とか言ってるの？ NVENCがHEVCでBフレームなしだからでしょ
NVENCは専用HWでGPUコア使ってないからGPGPUじゃないんだけどな
>>451
俺もどういうのか知りたい。x264やx265のmediumより速いのか？ >>430
これはエンコードじゃなくてフィルタ処理をGPUでやってて
エンコード自体はCPUでやってたってオチじゃね 【2013】 H.265/HEVC 【7680x4320】
http://toro.2ch.net/test/read.cgi/avi/1317066231/
185
圧縮率は「H.264」の2倍、超高精細やスマホを視野 動画圧縮技術の次世代国際標準「HEVC」
鈴木 輝彦 氏ソニー システム＆ソフトウェアテクノロジープラットフォーム 共通要素技術部門 信号処理技術1部 主任技師
http://techon.nikkeibp.co.jp/article/HONSHI/20120412/212513/
http://techon.nikkeibp.co.jp/article/NED/20120409/211909/
189
読んだけど一部要約すると
AVCは今から１０年以上前に仕様提起され標準化されたものでエンコードに使う演算装置がシングルコアで進化していく、
クロック数が右肩に上がっていくものと想定して難しいエンコード方法を採用して標準化されたんだとさ
HEVCは既存技術に魔法のような新技術を加えて劇的な圧縮率向上をはかるのではなく
既存技術を今主流のマルチコアCPU、GPU、並列処理への最適化と処理の簡略化、この１０年での改善をはかるみたい
最後のエントロピー符号化はCAVLCは廃止、進化したCABACへ一本化
その他新技術ももちろんある >>457
今回はわりと豊作だった
さて次はなにが入るんだろうか >>451消えたな
>>453が図星で顔真っ赤なんだろう >>453
>>455
イマジカで組んだシステムでCUDAを使ったプログラムを独自に書き起こしたって話のものだが
しかしやけに喧嘩腰だな
民生用ソリューションの話だけしか知らずプログラ上の詳細を語れる知識があるわけでも無い人間が
原理的な話で自説を固辞するのはあまりに無理があるだろう
技術の話なんだから理論的に考えれば答が出るので喧嘩腰になる意味は無いんだが
いたずらに感情的になるタイプの人間は技術の事を考えるには不向きじゃないかね
いらぬ対抗意識を燃やす人間の相手をするのは正直面倒だしこちらに益も少なく
うんざりするのであまりやりたく無いんだが イマジカがcudaエンコーダ書き起こしたってソース見つからないんだけどリンク頂戴
長い割に中身皆無の書き込みよりソース持ってきたほうがお互いのためじゃない？ >>461
証拠だけ出せば良いものを感情的になってダラダラ長文書いてるアホはおまえ なんでもかんでも宣伝していて素人がネットで情報を読めると思っているのは世間知らずだろう
ちゃんとお金払って長年付き合わないと分からない世界があるって事は知っといた方がいいよ
ここまでCUDAをエンコードに使えないという理由をまともに説明している意見は無いが
単純に自分の知る範囲で見かけないから出来ないに違い無いとたかをくくってるようにしか見えないな
なんの理由があって専門でも無い事をそこまで言い張りたいのか分からないがとても真摯な姿勢とは思えない
ただ言いはりたいだけの喧嘩腰の分らずやにこっちがわざわざ理解をしてもらう努力をする理由は無いね
なんの得にもならない
出来ないと言うなら他人に資料求めて無いで、素人考えの一人合点で無くちゃんと勉強したプログラム上の理屈を提示しなさいな
その方が早いよ ｱｳｱｳｳｰT Sa08-svru
恥ずかしい勘違いで引っ込みつかなくなったアホ そんなにGPU使いたいならOpenCLオプション付けてエンコードすれば >>467
あなたの書き込みは蓮舫の会見と似てるんだよね
抽象的なことばかり長文で書き込んで、具体的には何も示さない 一応まともにつっこんでみたつもりだけどスルーされてるみたいだし、
横からつっこんでる人も無駄に相手しないでスルーしたほうがいいんじゃないかなって。 なんか中傷ばかりだねえ
業務用機器があると言っても信用せず一般販売の機器でも無いのにカタログを見せろと来る
かと言って出来ない理屈が説明出来るわけでも無し、それにしては出来ないと言い張る
自分からはソースは愚かなにも確かな説明もせず、ただ出来ない信じられないと言い張ってるだけだが
自分は何も説明する気も無く相手にばかり自分に理解出来る分かり易い説明ばかり求めるのは
全くフェアじゃ無いね
お客様のつもりなのか知らないがどうにも傲慢だ
改めて聞くがそこまで出来ないと信じる根拠はなんなのかね
それとも出来たらなにか都合の悪い事でもあるのかね
こっちにしてみればそちらの根拠の無い出来ないという信じ方の方がよほど宗教がかってて意味不明だ 俺はCUDAエンコーダーはあってもいいと思うが、それはあくまで
ハイブリッドで、みんなが期待してるような一番画質や圧縮率に関わり
一番時間かかる部分はどうせCPUだろってオチなんだろと思う。 だから、言葉の問題になるが、
もしこんな感じのシステムならCUDAエンコーダシステムとも呼んで問題ないが、
これじゃ、俺の中じゃGPGPUは今までどおりエンコードは苦手と言わざるを得ないな。 >>474
プログラムに強いと思い込みたい業界通気取りっぽいから何言っても無駄じゃない
「苦手」に反応するスクリプトみたいなもんだと思ってスルーした方がいいのかも つい先日、QSVスレで協力してもらって、x264/x265/VP9/QSVEnc/NVEnc/VCEEncの
SSIM/ビットレートグラフを作ったけど、アニメのような比較的圧縮しやすいソースでは
NVEncのHEVC(main10)が結構良い結果を出してたよ。
http://mevius.2ch.net/test/read.cgi/avi/1486130737/335
まあ、あくまでもトータルのSSIMを計算しただけのグラフにすぎないから、
諸々のシーンでの仕上がりとか最終的な画質は目視で確認しないとわからないけど。
実写のような複雑な映像だとやっぱり苦しいし、HEVCについてはどのHWエンコーダも
H.264に比べて調整不足な感じはする。
NVEncのHEVCでBフレームが使えるようになったり、各社で調整が進んでいくと、結構良いものになるかもね。
さすがにソフトウェアエンコーダを超えるほどにはならないと思うけど。
どうせ個人向けのGPGPU実装エンコーダ、しかも質の良いものなんて出てくる可能性はまず無いんだし、
既存のHWエンコーダの改善が進むことを期待してたほうがいいよねっていう。 >>461
そういう業務用ってことは、例えば2時間の映画を3日とか1週間とかかけてエンコするやつかな
それだったらCUDAで高速化も納得 >>474
先ずCUDAを使ったエンコーディングはCUDAが常にCPUから情報を貰いCPUからの命令で動く以上
構造的にハイブリッドでしか在り得ないよ
そしてCPUより苦手とされる部分はCPUの何千倍もあるコア数をぶん回す事によって
スケールメリットで克服するんだが、>>430で書いたようにいかんせん使えるメモリー量が少ない
結果ハウスメイドのシステムを作っても速度の上昇は数倍に留まってしまう
これはエンジニアから受けた説明だよ
業務で使うには数倍の速度向上でも充分有り難いが汎用品にするにはあまりにも無駄が多く
コストに見合わない（大量生産品としての流通が見込めない）事になり具体化の例も限られるだろうから
一般人がこれを無視するのは正しい
ただ、そういった詳細を知らないままなんとなくの憶測でGPU処理はCPUを超えないと断定してしまうのは正しい事では無いね >>478
かける時間は長くても実時間と同じから数倍という所かな
その間に何パス出来るかという感じだね
設定数値としては100パス以上設定出来るが
かけられる時間との見合いで何パスと決めるかは経験則によるところが大きい様だった >>479
もし分かればそのハウスメイドシステムの構成を教えていただきたい
CPUは何とか、GPUは何をいくつとか >>479
論点をズラしだしたから
クソ雑魚ナメクジなんだなと分かったので
もう結構ですよ multicoreware / x265 / wiki / RoadMap ? Bitbucket
https://bitbucket.org/multicoreware/x265/wiki/RoadMap
>4. OpenCL acceleration
>
>Because of the proprietary nature of the OpenCL target hardware, this last work will happen in a private fork.
>The fork will be opened as soon as the target hardware is available for sale, or when the fork is used commercially,
>whichever happens first (or perhaps sooner). Non-proprietary changes will be periodically posted to the mailing list for review and merge.
これだとGPUで多少早くなる事すら期待薄か… 少なくともこんなもんを知ってるというだけのことで変な優越感を持って
他人を見下すようなみっともない真似だけはしたくないものだな・・・ 誰かFPGAで簡単にHEVCエンコード並列処理できるようにしてくんないかな
超コスパ高そう。予算ある限り積み上げて性能高められるし
https://www.parallella.org ソフトの2つの例としてURLを2つ貼ったけど両者に関連性はないよたぶん 堂々とリッピングソフト売れるのってもう中国くらいでしょ
http://www.multipelife.com/sitemap
Telが国番号86になってる AMDがRaven Ridge辺りでCPUとGPU得意な部分を任せたBフレーム付きのエンコーダ出してくれないかなぁ、
とも思ったがIntelも出来てないしなぁ。両社ともソフトウェアはあまり得意じゃないイメージはあるが。
CPU内部バスがデータのやり取り時に飽和しちゃって遅くなるのかねぇ、とかいう思いつきばかりの素人考え。 内部バスとメモコンの細さはいつも問題と言われてるね
ヘテロジニアス・コンピューティングに最も近いところにいるAMDの（APUの）場合
ダイサイズの制約でミドル・ローのCPUとGPUとなってたのが痛い
GPGPUはあくまでCPUでの処理能力の底上げだから、その支えられるべきCPUの処理能力が足りなかったからね
だからRyzen APUでも問題の解決にはならず6/8コアCPU+iGPU+オンダイメモリ（HBM）になるまで現状のままだろうけど
一応、研究はしてるんだぜという動画↓
https://www.youtube.com/watch?v=A3_w5qWwYc8 >>496
素人の妄想に付き合っていただきありがとうございます。
なるほど。英語はさっぱり分からんので早々に拝見するのはリタイアしましたｗ
AMDだと7nm世代でHBM2搭載APUが出てくれる可能性にかけるしかないのかな。
GPUの雄NVIDAもARMコアライセンス取得してるからそっちの方にも期待はしたいけど、
あっちはしばらく自動運転とかGPGPU性能を高める方向に行くようだから、
やはり2〜3年後のAMDに期待しておこう。AMDファンだしｗ できるできないで言えばできそう
けどバッファとI/Oが絶対的に足りなくてパフォーマンスは全然出ないと想像してみる 持って帰って一人でこつこつやれる仕事じゃないと駄目なんだよな
いちいち質問しないと進まないなら事務所に来てやれということになる 外部接続するcpuてわけじゃないから無理じゃないかな
これ使うくらいならnvencとかでいいんじゃない ディープラーニング系のものは、明確な数値計算で成り立ってる
HEVCエンコードには使えない気がするけど、よくわかってない。 ■ このスレッドは過去ログ倉庫に格納されています
