【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
つまり、並列化ができれば速いができない筈という予想な訳だ 画像処理は並列化は普通に大得意だと思う 一向にGPGPUを使った爆速エンコーダーが出てこないとこみると、 GPGPUは条件分岐が苦手で、エンコーダーが苦手なアルゴリズムが 含まれてるんだろうと予想はしてる 画像処理は並列化が得意とか、そんな一般的な話をしてるんじゃなくて 動き探索は並列化が難しいって話をしてるんだけど・・・ いや、Bフレームが無くていいなら、現状で爆速エンコーダはある なんでBフレームを付けてくれなかったかというと、 それが難しいからというのもあるだろうけど、 サイズを縮めることはグラフィックボードの本懐ではないから とにかく速く、リアルタイムで、ということを追求してるので、 既に帯域が足りてるところに遅くなるだけの処理を増やしたりはしない やればできる子なのにやらないので、GPGPUにやらせようと あの大量に積んだGPUが穴掘りじゃなくエンコードに有効だったらよかったのに CUDAを使ったエンコーダーは実際に映像編集ソフトなどで既にあるんだが 確かにエンコードスピードは早くなるが一番良くて数倍程度で 併せてCPUの稼働もフルに近くなる 数千コアも使ってるにしては期待はずれな結果なんだが 何故こうなるかと言うとメモリが関係してくる グラフィックカードの搭載メモリ量は多くて数Gバイトだが これを何千もあるCUDAコアに割り当てると1コア当りでは1MBレベルになってしまう エンコード作業に使うバッファとしては全く足りず頻繁にスワップが発生して速度低下し、 数千コア分のスワップを処理するCPUもパンク状態になってしまう 結局のところ、数千のコアが充分に動作出来るのは1コアが使うのが1MB程度の処理に限られ それ以上の事をさせるにはコア以外の部分でスパコン並に大掛かりなシステムが必要になってしまうわけだ GPUが大の苦手なのは、条件分岐だってバッバが言ってた。 そしてソフトウェアエンコは条件分岐の塊だってジッジが言ってた。 全部自分でやるか全部任せるかの二択である必要はなくて これ計算しといて、と切り分ける部分は先輩がやって、 新入りは意味も判らずひたすら計算、という図式が効率的 まだx265は開発中だしのんびり行きましょう ちょうど10年前のx264も言うほど賞賛されていたわけじゃなかったし 今後メインストリーム帯のCPUコアが増えていくだろうからエンコの負担が減ることに期待してる >>432 先輩後輩間でコミュニケーション爆発が起きて低速化するというオチ GPUの並列計算はCPUのそれとは違って、似た事しかさせられんのよ 例えば(1,5,25,8,-3,0)といった入力値全てに対して2をかけろ というようなことね 分岐が苦手なのもこれが原因 CPUに比べて沢山コアがある代わりに1つ1つの計算は遅い、なんて理解は間違い ほんと色んなとこにいるけど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は今から10年以上前に仕様提起され標準化されたものでエンコードに使う演算装置がシングルコアで進化していく、 クロック数が右肩に上がっていくものと想定して難しいエンコード方法を採用して標準化されたんだとさ HEVCは既存技術に魔法のような新技術を加えて劇的な圧縮率向上をはかるのではなく 既存技術を今主流のマルチコアCPU、GPU、並列処理への最適化と処理の簡略化、この10年での改善をはかるみたい 最後のエントロピー符号化は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 素人の妄想に付き合っていただきありがとうございます。 なるほど。英語はさっぱり分からんので早々に拝見するのはリタイアしましたw AMDだと7nm世代でHBM2搭載APUが出てくれる可能性にかけるしかないのかな。 GPUの雄NVIDAもARMコアライセンス取得してるからそっちの方にも期待はしたいけど、 あっちはしばらく自動運転とかGPGPU性能を高める方向に行くようだから、 やはり2〜3年後のAMDに期待しておこう。AMDファンだしw できるできないで言えばできそう けどバッファとI/Oが絶対的に足りなくてパフォーマンスは全然出ないと想像してみる 持って帰って一人でこつこつやれる仕事じゃないと駄目なんだよな いちいち質問しないと進まないなら事務所に来てやれということになる 外部接続するcpuてわけじゃないから無理じゃないかな これ使うくらいならnvencとかでいいんじゃない ディープラーニング系のものは、明確な数値計算で成り立ってる HEVCエンコードには使えない気がするけど、よくわかってない。 ttp://news.mynavi.jp/articles/2014/09/05/hotchips26_myraid2/ 画像認識に特化してるようだから、数値計算なら何でもってわけじゃないんじゃないかな ttps://www.kickstarter.com/projects/1235889177/mustang-200-affordable-scalable-adv-computing-acce/rewards これが実現して、安く出回るようになれば面白いよね >>504 何だこのPCI-ex4にノートPC付けちゃいましたみたいのは!? すげぇ欲しい CPUをコプロ代わりに使ってるのか。 学術計算用でこの手の高価な物は昔からあったけど、あとは値段次第だな。 差すだけで速くなるなら凄いけど、専用のプログラムを自分で書くんだろ? 現実的な問題として、本当にそういう外部HWを使ってまでエンコしたいのかって話がな・・・ 古いaviとかをH.265に縮めるプロジェクト進行中 もう2ヶ月くらいPC動きっぱなしなのにまだ終わらない これが数日で終わるなら有り難いけど、その数日のレンタルで構わないな 日常的にはエンコードしたい量は大したことない 紫10TBって電力結構要求するの? 玄人志向のKURO-DACHIっていう2ベイお立ち台系ケースなんだけど 2台挿すとスピンアップ繰り返し続けて起動しなくて1台だといける KURO-DACHIは初代と新しいのと2世代あるがどちらもダメだった ソフトウェアエンコなら、ryzen 7 1700でも買ってエンコしろ スロットに差すとエンコードが速くなるようなデバイスが発売されればいいのに 今更だけどMP4BoxでもHEIF作れるみたい jsonとか用意しなくていいし、ビルドする必要も無いので>>351 の方法より簡単だと思う GPAC support for HEIF | GPAC https://gpac.wp.imt.fr/2017/06/09/gpac-support-for-heif/ あとFFmpegでも対応予定っぽい? #6521 (HEIF support) – FFmpeg https://trac.ffmpeg.org/ticket/6521 >>513 h264の時はあったのにHEVCは出ないな podcastがopus採用するらしい これに続いてネットラジオ各位はopus導入してくれ A hands-on introduction to video technology: image, video, codec (av1, vp9, h265) and more (ffmpeg encoding). https://github.com/leandromoreira/digital_video_introduction ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる