【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
だから、言葉の問題になるが、
もしこんな感じのシステムなら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エンコードには使えない気がするけど、よくわかってない。 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 >>514
初期のh264 HWエンコはひどかった。
HDでh264エンコするよりも、SDでMPEG2エンコしたほうが画質も良くて、
ファイルサイズも小さいんだもん。 h264も熟成に10年かかった
h265もあと5年はかかる、RYZEN効果でやっとCPUが追い付いて来たしな リアルタイムに間に合えば質は問わない、というのが基本スタンスだからな
保存用に使うのが間違い できるだけ高速でエンコさせたいんだけど、下の機材でなんとかできないかな？
・Sandy i5のデスクトップ。
・ivy i5のノート
・iPad Pro
能力的にはiPad Proが最強なんだけど、エンコ用には使えないよね？ それでiPad選ぶって、単にiPadでエンコしたいだけでしょ？
iMovieでやればいいんじゃない 処理能力的にもiPadProが文字通り桁違いで劣ってるよ
提灯ベンチマーク記事を真に受けてない？ HWエンコードならiPad Proが最速になれるぞ
Sandy/Ivyにはエンコーダが無いからな
SWエンコードは…無理させんなとしか HEVCはskylake以降でないとQSVできない >>530
H.264ならQSV使える
が、このスレは「次世代ビデオコーデックのスレ」なんだよな
次世代コーデックが特に絡まない話題なら別の所でやろうぜってなる それは偏にHEVCスレでHEVC未対応のQSVの話を持ち出そうとする人が現れることを想定していなかった私の落ち度です
ごめんね CPUを高速なのにする度に全部買い換える人は自動的にOSも変わるけど、
自作の人は必要なとこしか買えないからOSの乗り換えは遅くなる 7からWIN10に変えてから長いけど、久々に友達のWIN7機を触ったらOSが使いやすいのな！ 久々に7見るとエアログラスがいいなって思うことはある。8以降の四角いデザインは未だに好きになれないな スレチだが俺も8以降の見た目が嫌いだなぁ。
win10は7で主要ソフトが動かなくなってからで良いわ。 7も意図的にドライバを切り捨てる儲け思想が気に入らないけど、
SSDにちゃんと対応してるのが7以降だから仕方ない
XPだって技術的には対応できるけど、そこは商売として受け入れる ７まではUIも滑らかなデザインで美しいし
機能へのアクセスもいい 7のスタートだけはゴミだと思うけどな
社畜SE専用だろ、あれ だいぶ前に開発関係でNTTかどっかの中の人がＨ264とかＨ265についてはっちゃけて解りやすく書いてたodfかんか貼ってあったんだけど知らない？ http://home.catv.ne.jp/dd/pub/cod/coding.html
これは分かりやすいと思ってブクマしてたけど・・
あと、もう一つあったはずだけどブクマに埋もれて見つからず >>540
窓たくさんすこしずつずらして開いてると、タイトルバーとかメニューバーがフラットだとどこが窓枠なのかわかりにくいよね。 xpのlunaが美的センス最低だが視認性は最高
7のUIはリボン推しとその他旧式などなど操作系がチグハグでそんなに褒めるほどのもんでもないな…10もだが
エアログラスはかっこいい
てかwin8もβの最初は7の丸みだけ取れたような見た目だったのにな AV1てやっぱりエンコードの計算力凄まじそうだな
NetflixとかYouTubeみたいな大規模な配信じゃないと利用するメリットないんじゃないか？ AV1はHEVCよ20%効率的、計算量は3〜5倍
2017年12月31日にビットストリームが決定、数日以内にChromeとFirefoxで利用可能に
YoutubeとNetflixで使われるまで出荷しない。問題があれば開発継続
こんな感じか >>計算量は3〜5倍
まじで？？
HEVCですらアップアップなのにその3-5倍とか・・ この20パーセントてのは、元動画をhevcが30パーセント圧縮できるときにav1は50パーセント圧縮できるてのと、元動画をhevcが30パーセント圧縮できるときにav1は36パーセント圧縮できるのどっち？ その計算だと、80%圧縮できる時に100%圧縮できちゃうな 同じビットレートで比較してSSIMが20%良くなったか、80%のビットレートで同じSSIMのどちらかではないか いや、100/120=83.3%のビットレートで同じSSIMなのではないか >>549の概要
●AV1のビットストリーム仕様の確定は2017/12/31までを目標としている
●ただ、YoutubeやNetflixといった主要メンバーが納得するレベルにならないとリリースされない。
●Netflixの担当者は「HEVCより20%効率的で、計算量は3〜5倍」というレベルを目安としている。
Youtubeの考えは不明。
●これまでの評価は
Netflix「AV1はVP9より20%効率が良い」
Google「AV1はVP9より30〜35%効率が良い」
とされているが、4月のBitmovin AV1での検証ではそこまで良いものではなかった。
当時77あった実験的コーディングツールのうち8つしか使ってなかったので
改善の余地は大いにあるが、これらの機能の統合や最適化は難しい作業になるだろう。
●ビットストリーム仕様確定後の見通しは以下の通り。
・ChromeやFirefoxは数日中に再生をサポート
・チップの開発に12〜18か月、更にそれを利用したHWリリースに6か月。 (>>559の続き)
●4月のNABでのBitmovinの実験では1080p24のリアルタイムエンコードに最大200コア程度が
必要だったが、そう遠くないうちに8-32コアでできるようになるだろうというコメントもあった。
http://www.streamingmedia.com/Articles/Articles/Editorial/Featured-Articles/Bitmovin-Pushes-AV1-Forward-Joins-Alliance-for-Open-Media-117634.aspx
■参考：>>262の記事にある4月時点のAV1のエンコード速度
https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/
・LenovoのT540pノート(i7-4800MQ, 8GB RAM, Ubuntu 14.04)で
1080p24の40秒クリップをエンコードするのに8時間42分かかる。
つまりエンコード速度は0.032fps。
・デコードは上記環境でも問題ない。 >>560
完全に出たてのh.264やh.265と同じじゃないか
俺らがまともに使える様にあるには5〜10年かかるだろ それでもav1の開発を進めなきゃならないほどhevcの権利関係が鬱陶しいんだろうか >>563
>>339によると特許プールが3つか4つに分裂しているらしい
＞H.265/HEVCコーデックでは合意形成に失敗しており特許行使者の利害関係調整が失敗することが起こりえる
つまり私利私欲に走りライセンス料を吊り上げる企業が出てきてもおかしくないのか
これMicrosoft良い立ち位置にいるよなー
H.265とAV1どっちが普及してもおいしい >>559,560
翻訳ｔｈｘ
>>564
VC-1の時のゴタゴタと比べると凄い進歩
こういうマイナーっぽい新規事業に日本企業の腰が重いのが残念
技術力自体は悪くないのに 日本企業だカスタムチップで実績のあるソシオネクストが参加している
http://aomedia.org/about-us/
NHKとサイバーエージェントもはよ NHKなんてH.265のライセンシーなんだから無理無理
H.265のライセンスプールについて調べれば分かるけど参加企業のうち約20%が日本企業
日本はH.265のライセンスを囲い込む側
AV1のようなプロジェクトに日本企業が積極的に参加するなんてことは期待しない方がいい 何がかんだ言ってもネームバリューがモノを言う
H.265は世界的に広まってるから狙うなら語呂が悪いH.266の代わりを目指さないと H.264/AVC
H.265/HEVC
H.266/???? >>566
日本企業もいたのか（言われて探したけど企業ロゴ薄すぎ）
>>567
念のために書いとくと、日本企業が加わることでホルホルしたいんじゃなく
AV1の完成度が高まってほしいってのが大きい しかし、そうやって日本企業が絡むとまた権利関係面倒臭くなりそう
少なくともnhkは絡まないでくれ
あと受信料下げてくれ >>569
H.264/AVC
H.265/HEVC
H.266/AV1
になったりしてw ■ このスレッドは過去ログ倉庫に格納されています
