次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
■ このスレッドは過去ログ倉庫に格納されています
H.264/AVCの後の様々な次世代ビデオコーデック全般について語るスレです。
■主な次世代ビデオコーデック
●H.265/HEVC
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
●VP9
The WebM Project
https://www.webmproject.org/
●AV1(AOMedia Video 1)
Alliance for Open Media
http://aomedia.org/
■分岐前のスレ
【2016】 H.265/HEVC Part7 【7680x4320】
http://mevius.5ch.net/test/read.cgi/avi/1485191956/
次スレは>>980が宣言してから立ててください。 >>471
だからそれ、ソフトウェア開発部隊が使えるはずの機能を使えない状態にして放置してたからだろ
結局、カスであったことに変わりはない >>473
だから「機能的には」って「には」を付けたんだな >>477
なるほど。（ただ、エンコード機能的に何か充実してるんだっけ？という素朴な疑問はある。エンコード以外の機能込み？） >>478
2Pass（おそらく先読み）によるレート制御とかBフレーム使える（Polarisでは無効化されてる？）とか機能的には充実してると言ってもいいのでは
それらを実装してるから高画質とは限らないだけで・・
ま、EU（GPUコア）使って柔軟に進化してるQSVは別格として
nvidia、AMDともにゲームの配信とかゲーム画面のキャプチャ向けの高ビットレート録画って割り切ってる感はある http://egg.5ch.net/test/read.cgi/software/1487682297/568-571
Zeranoe版ffmpegでlibaomのビルドミスがあったので、
AV1の検証をするなら20180405-e54679b以降のバージョンか、自ビルドのffmpegやaomenc.exeで。
libaomの方も頻繁に更新されてて、原因はよくわからないけど同じ設定で前より遅くなったりもしてる。
aom 0.1.0-9082-gab1e1db19のaomenc.exeでクラッシュするケースもあったし、安定するのはまだまだ先かな。 xiphmont | next generation video: Introducing AV1, part1: Chroma from Luma
https://xiphmont.dreamwidth.org/91643.html
next generation video: Introducing AV1
https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml >>482
画質は上々そうやね
x264のデフォルトの1万倍近く遅いみたいに見えるけど。
英語はよく分からないので100倍であって欲しい。 >>483
x264のデフォルト(--preset medium)ではなく、--preset veryslowと比較して、
AV1は品質指定モードで平均5869.9倍、ビットレート指定モードで平均8139.2倍のエンコード時間だね。
ただし、
●テスト環境のスペックが書かれていない。
●x264はスレッドを活用してるけど、AV1は --tile-columns 0 なので
タイル分割エンコーディングを行っておらず、スレッドをほぼ活用できていない。
●当然ながらAV1のリファレンスエンコーダであるaomencはまだ最適化もされてない。
といった点には留意する必要があるかな。
VP9の方も同じ --tile-columns 0 でやってるので、品質指定モードでVP9の658.5倍、
ビットレート指定モードでVP9の667.1倍のエンコード時間という方が目安としてはいいかも。
まあ普段自分でVP9エンコードしてる人ってほぼいないだろうからわかりにくいけど・・・。 >>484
veryslowと比較してなのか…スレッド数で1桁速度が変わったとして現状x264 midiumとの比較で2000倍程度速度差があるという認識でいいのかな
x264やx265は発表から数年で速度はもとより画質も素晴らしく伸びたように思うので少なくとも今年の終わりまで気絶してから評価した方が良さそうですね AOMのソースのところに書いてあるのと同じサンプルだね
https://media.xiph.org/video/derf/
解像度は各種あるけど、ニュース番組並に情報量低いのばっかりで、マクロブロックサイズのサイズデカいコーデックがそりゃ縮むわなという感じのばっかりなんだよな
x265との比較しないのが謎だし、AOMの中の人なんじゃないかと思ってしまう >>486
記事をちゃんと読んだ方がいいよ。
>>482のFacebookの実験ではderfのサンプル群は使っていない。
Facebookでよく見られてるトップ400のビデオを使っていて、
それらに関する説明（スマホで撮影したSD/HDが多いとか）も書いてる。
x265との比較が無いのは俺も残念。なんでだろね。
HEVCのライセンス料って、調査研究目的であっても請求されたりするもんなんだっけ？
あとFacebookはAOMのFounding memberだよ。
x264も0.148-snapshot-20161114-2245って書いてるけど日付からするとr2727かな。
ちょっと古いけど、まあこれはあまり影響なさそうか。
snapshotの末尾の数字ってずっと前から2245みたいだけど、何を表してるんだろ。 エンコードにH.264の10000倍かかったとしてもエンコした動画を1回しか見ないような俺らに対して
1回エンコするだけで100万再生スタートという次元の配信業者からすれば
俺らより環境にもネットの帯域にも優しいお釣りが出るほどのリターンがあるということ >>489
意味が分からない。10000倍では釣り合いが取れないだろ
ネット帯域が主要命題だったのは10年〜20年前だし x264やx265みたいな魔改造エンコーダがまだ無いからな
対応ハード出るまで1年有るし、配信事業者側が使い始めるのも2年は先だろう
nvidiaがNVEncとCUDAの連携追加し始めていてAV1にも使えそうな実装をSDKでして来てるし
AV1の方がHEVCより物量的処理での圧縮してるから、NVEnc+CUDAの実装で何かしら出してくるかもな
有る程度纏まった形にしてるのはDGX-2みたいなTeslaを使ったコンポーネントとセットで事業者用
GeforceとかはNVEncのみでは最小限で、あとはSDK使って手前らで巧く纏めなさいよとかだろうなぁ NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような画質水準には達していない）しか作れないみたいだから、アテにならんと思うがねぇ NETFLIXなど大手の配信業者も多く絡んでるし可能な限りハードウェア処理し易い設計になってる可能性はまたあるとは思う >>492
リアルタイム配信向けの実装なだけでしょ
短時間に出来る範囲でしかやっていない
同様の事をQSVでやらせると、H264でしか出来ないうえ、NVEncのH264より汚いって知ってた？ >>494
そんな話していないし、したいとも思わん NVEnc自体は、nvidiaのGRIDみたいなクラウドや、LAN内でのゲームのリモート操作のためのもので
それ自体はH264なりHEVCだから、GPUのバッファから生成する以外にも、デコーダからGPUに映像与えてやれば、任意の映像データもトランスコードしてファイルとして保存できるってだけ
ただ要望もあるから、あとからSDK7.x世代以降にCUDA使ってGPGPU的に拡張出来る様になってる
もちろんSDKでのAPI実装やサンプルに頼らず独自でやっても良いんだけど
CUDAエンコーダの頃から独自に拡張する人が殆ど現れない
エンコーダの拡張自体が糞難易度高くて、数学者的な人が実装サンプルや設計組んで、コーディングに特化した連中が最適化を進めるパターンが多い
そういう方々は既にx264やx265の方に集中しちまってる >>489
趣旨はともかく、さすがに10000倍のままってことはないでしょｗ
>>490
>ネット帯域が主要命題だったのは10年〜20年前だし
そんなことないよ。流れるデータ量も激増してるし、世界にはまだまだ帯域不足のところもあるし、
配信業者にとってデータ量の削減は今も昔も極めて重要な課題。 >>492
> NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような
> 画質水準には達していない）しか作れないみたいだから
それを言うなら
・GPUのHWエンコーダはどれも高圧縮/高画質を求める人には向いていない（特に実写等）
・QSVとNVEncは圧縮/画質面では同程度(QSVの方がやや上？)。
エンコード速度はNVEncが圧倒。
・AMFはQSVやNVEncと比較すると一段下のレベル。
AMDのエンコード/デコード機能の出遅れはちょっと心配になるレベルでもある・・・。
という感じだと思うけどな。（根拠は>>473とか）
IntelもNVIDIAもAOMのFounding Memberだし、それなりに期待はできると思う。
AMDはPromotor Memberだけど、エンコード/デコード部門は頑張れるのだろうか・・・。 画質重視でもYoutubeに上げる為にロスレスで圧縮するときはNVEnc使ってる NVEncのロスレスって4:4:4だと聞いたけど、Youtubeはそれも受け付けてくれるのか。
なんとなく弾かれるもんだと思ってた。 そういえばx265のCUSA版があったな
https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder
長いこと更新されてないみたいだから
非主流アーキテクチャ向けの設計は広がらないみたいね
H.265の v5 (Approved in 2018-02-13) の規格書が発行された。
現時点ではダウンロードできるのはTIES userのみ。
H.265?:?High efficiency video coding
https://www.itu.int/rec/T-REC-H.265 詳しくは知らないというか知る由もないんだけど、NetflixとかYoutube（Google）みたいな資本力のあるところでもHWエンコしてるのか？ああいうところって一般人じゃ到底手に入らないようなスペックのコンピューターでSWエンコしてると思ってたんだが >>501
全てがGPGPUでCPUより効率良く処理出来る訳じゃない
x264やx265が高画質化するため手法の極一部だけなんで
大半を処理するCPUが結局ボトルネックになる
それでも僅かにCPUの負担が減るから、その分は微妙に早くはなるけど何割も早くはならない >>503
ああいう規模だからこそ逆に専用のASICボードとか用意してガリガリやるんじゃねーの？ >>503
SWでの高画質エンコードがされるなら
○○向け高画質エンコード（配信サイトで再エンコードされない）設定なんてのに意味がないから
ASICもしくはx264 --tune very fastレベルの高速SWエンコだと思う >>509
> ○○向け高画質エンコード（配信サイトで再エンコードされない）設定
これが何のことを指してるのかよくわからない。Youtubeでそんなことできるんだっけ？
あとつっこんでおくと --preset veryfastじゃね。 GoogleのサービスでH.264トランスコードはx264だっけか 配信サイトで再エンコードされない設定って言うのはよく聞く誤解だね
YouTubeだとどんな動画を上げても再エンコードされる
アップロードしたあと手元の動画とSSIMなりで比較してみたら分かる 昔の実装そのまま今でも一緒だと思っていたり
ニコニコの体の良いシステム負荷軽減手法と同じだと思っているんじゃないかな そりゃyoutubeへのアップロードに関する話題とか昔の流行だもの よくわからんがYoutubeで再エンコードされないようにする設定があると勘違いしてたってことか。 Youtubeは1回エンコされるのは確実として多重エンコにならないようにロスレスで上げるのが基本じゃないの？ >>517
基本ではないでしょ。可逆はサイズもでかくなって面倒だし、
「可逆で上げた場合」と「十分高画質な非可逆で上げた場合」とで
生成された動画に目立った違いは出ないと思うし、後者で上げる人がほとんどだと思うよ。 自分はx264 crf12ぐらいで上げてるな 16と程度と比較するどちらが綺麗かは分かるレベルだったし意味なくは無いと思う。
生成後の動画比較すると画質毎に設定やビットレート多少違うかもね 低いcrfほどエンコーダの差が画質に出てこなくなるから、QSVやNVEncでササッと処理済ませてアップロードし始めた方が手早いかも
放置で下準備させておく時間があるならx264だけど 1080pの335フレームでAV1をテストしてみた。
ソースは進撃の巨人１期OPのサビの立体機動シーン〜大砲発射まで。
結果： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3489.jpg
--cpu-used 3 でx265のveryslowと同程度の品質で、かかる時間は17倍。
--cpu-used 2 だとそれ以上の品質で、かかる時間は100倍。
--cpu-used 1 だと更にそれ以上の品質で、かかる時間は170倍。
(ただしどれも--tile-columns未使用。使えばこの半分くらいにはなるかも。)
--cpu-used 1 だと、x264 veryslowで7Mbps、
x265veryslowで5Mbpsくらいかかるのを、4Mbps弱にするくらいの圧縮効率。
VMAF/SSIMに基づいた評価としてはこんな感じになった。 >>521
これを維持してどんだけ高速化できるかだなぁ libaomはリファレンスみたいなもんだし、まだ最適化もされてないから
今のlibaomのエンコード速度/時間を見てAV1の実用度を判断してはダメだよ。
libaom自体はどこまで最適化されてどれくらい速くできるのかわからんけど、
商用ではベンダーが開発したエンコーダ(SW/HW)が使われるんだろうし。
ちなみに>>521のサンプルでは-cpu-used 3 -crf20で335フレームのエンコードが約3時間4分だったけど、
crowd_run(1920x1080、500frames)は同じ設定で6時間30分かけて100フレームしか進まなかったので中止した・・・。 very slowの17倍って今の段階なら悪く無いじゃんって思ったけどx264ならmidiumの数倍程度だけどx265だと凄いんやね 話題が無いので間潰しにNVEncネタ
NVEncでの同時エンコードは基本的に2つまでと言われているが、実はQuadro 2000番以上とTeslaは制限が無い
あとNVEncエンジンの搭載数にも違いがあり
GK世代、GM107やGM206、GP107〜106 は1基
GM204〜GM200、GP104〜102 は2基、GP100やGV100は3基搭載されていて
搭載エンジン数分までは同時処理をしても処理速度が殆ど落ちない様になっている
例外的なのがGTXGTX1070で、GP104自体は2基搭載だがエンジンが1つ無効化されている
GTX1070TiについてはGTX1080と同じく2基とも有効
なので同じ世代ならNVEnc自体の処理性能自体に大差は無いけど、
エンジンの搭載数によって同時処理（多くの場合は2ウェイ処理）時の処理速度低下具合が変わってくる NVEncの処理速度的については、固定量子化でブン回す場合には、FHDでの出力ならピーク値でH264で600〜650fps、HEVCで400fps前後ぐらい（NVEncのHEVCはBフレーム省略仕様なので速度低下が少ない）
NVDecのデコードはFHDで600〜650fpsぐらいがピーク値になる
あと実行環境（NVEncを呼び出すアプリ）によってピーク値近くで動作させられるかが変わってくるので留意
例えばTVMW6だと、エンコードの前段がボトルネックで2つ同時のバッチエンコにしないとエンジンを回しきれない
お陰でエンジン2基環境の場合はどちらも回し切ることが出来ない はぁ、1080並の値段でELSAの1070なんてかわなければよかったｗ 捕捉
上の速度はPascal世代の速度で、1つ前のMaxwell第2世代だとH264なら2/3、HEVCなら1/2ぐらいの性能になる
Pascal世代でのNVEncのトピックは、HEVC速度低下が少なくなっている事なんだけど、公式なトピックに記述は無いけど、Pascalで動作クロック自体が大きく向上しているので、結果的にH264も含めた全体的なパフォーマンスも相当上がってる
Pascal世代のHEVCについては、性能低下緩和も含めてマクロブロックの捜査ロジックの改善もされている様で、Maxwell第2世代のHEVCより地味に画質が向上されている
NVEncの速度はデフォルトの動作クロックに依存（ツールによるソフトウェアでのOCはCUDAコア側のクロックが上がる仕様）なので、NVEnc目的でグラボ購入する場合には、製品の公称クロック基準で購入した方が良い
ファームウェア操作ツールでクロック上げた場合はそのまま性能に反映される NVEncの性能で考えれば、リファレンスクロックが高く、エンジン2基のGTX1080が最良
次点で僅かにクロックが低いGTX1070Ti
GTX1070はリファレンスクロックはGTX1070Tiと同じだけど前記の通りエンジン1基なので、NVEnc狙いではお勧め出来ない
GTX1080Tiはエンジン2基だけど、動作クロックがGTX1050並なのでEVEncの性能は落ちるし単価が高い
エンジンの単価で考えれば、GTX1050無印が安価
CUDAコア数が少ない分、GTX1050Tiよりクロックで性能稼いでいるので、
動作クロックも高めになっているが、クロックは1つ上のGTX1060より1割落ちる
高いクロックでエンジンを含むGPUコア部（否CUDAコア）を回せるかは、TSMC16nmFF製造かSAMSUNG14nmFF製造（16nmより回らない）か、グラボの電源部の影響が大きい
（それでもGTX1050をファーム改造でGTX1080のリファレンス並ぐらい回す事は不可能じゃ無い GK208はNVEnc乗ってるのにGP108がなぁ こういうGeForceの型番ごとにおける機能の制限/無効化ってどこかにドキュメントとしてまとまってるの？
QuadroとTeslaはHTML上に一覧表が出来てるけど nvidiaのdeveloperにあるみたいな一覧は無いね
海外フォーラムでは日本よりNVEncについて掘り下げてスレが意外にあって
エンジン数についても話題に上がる
GTX1070Tiなんかも、リリース後エンジン数についてスレ立ってた
対応SDKから実機確認すれば解るんで、同時処理数も同様やね そういう情報出さないで売ってるの、なんだかなって思うわ NVIDIAにとっては、エンコーダーの価値はその程度にしか見ていないということ なんでAMDは動画最弱になっちゃったんだろ
動画ならRadeonなんて時代もあったのにね というか、実用面からすると
・NVEncを保存用エンコードに使う人はあまりいない
・NVEncで並列エンコードをする人もあまりいない
・全体的に十分以上に高速なので、高速域での速度差を気にする人もあまりいない
ということで、一般ユーザー的にはエンジン数やエンコード速度の差を重要視する人は少ないのでは。
（「実際に使うわけじゃないけど最高の機能が載っててほしい」という気持ちはよくわかるけど） 公表されてる範囲の機能的なスペックはエンジン1基有れば実現出来るからね NVDec/NVEncのSDKもnvidia的にはターゲットはTeslaやQuadroで、Geforceでも一応使えるという感じだからね
Geforceだからと全モデル1基とかにされなかっただけでも良かったとする鹿
GTX1070の1基のみ有効になってる事ネタにして、nvidiaに纏まった数の直訴なんかしたら、あの会社なら次世代からGeforceグレードは統一仕様として一律1基にしてとかやりかねんｗ >>539
ip変換の質とエフェクトが充実してたって話でデコードエンジン自体はずっとnvidiaの一周遅れだよ アムドの寝言はVP9有効にして
公約果たしてからにしてほしいなw xiphがRustで作ってるav1のエンコーダって話題出てる？
リファレンスより速いって書いてあるけど これか
https://github.com/xiph/rav1e
国内で話題にしてる人は少なさそう、自分も今知ったわ
libaomのコードをベースに入れてるのかな？
他方の資料で
libaomのアセンブラ化で4倍は速くなる、多分100倍速く出来そうだけど、アルゴリズムの書き換えが膨大すぎるわい！
みたいな事書いてあった >>545 >>546
>>122でも書いたけどPolaris/VegaはVP9のDXVAデコードに対応していない。
当初は隠し機能として存在していたそうだが、それも後になって消された。
ただしDXVAとは別にOpenCLによる再生支援が利用できるMFTフィルタがあり、
ChromeやFirefoxはそれを使ってVP9再生支援を利用することができる、という状況らしい。
なおRavenRidgeはVP9のDXVAに対応している。
>>547-548
>>89で出てるね。限定的な実装みたいだし、試したことはない。 ビルドして試そうかと思ったけどビルドできなくて放置してた これcじゃなくてrustなん？
時代はrustなのか？ Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね MozillaのDaalaで使ってたから親和性は折り紙付きだろう 吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
代わりに習得がえらい難しいらしいけど
使用者に最も愛されている言語とか言うけど
愛が無ければやってられない習得難易度の裏返しだったり >>554
Daala作ってたのはXiphだけどな
Xiphは半分Mozillaみたいなものだけど xiphってflac作ったところなんだな
知らなかったわ ハイレゾは全く無意味とバッサリ切ったのが爽快だった https://people.xiph.org/~xiphmont/demo/neil-young.html 耳に聴こえなくても脳に影響してるんだよ
聴覚が全てではない 違いが分かる人と分からない人が
居るだけの話なのに
実際に目の前で見ないと信じられないのが人間 その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
ちゃんとマスタリングしてる物がほとんどだから20khz以上が切れてようがそうで無いものより綺麗っていうのはあるね 自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
なにこれつべのVP9の4K十分綺麗じゃん
なんでこのVP9ってのはH.264やHx265以上に流行らないの？ 俺が事情を理解できてないだけだが理由がわからない
しかもつべの4K VP9ってビットレートたかだが12Mbps程度でこの画質なんでしょ？
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが ■ このスレッドは過去ログ倉庫に格納されています
