次世代ビデオコーデック総合スレ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が宣言してから立ててください。 配信があるのでシビアだよ
俺も264で世は収まったと思ってたけど
ある日突然ツベの4Kがガクガクになって思い知ったよ… 4Kに対応しようとすると古いPCは一気にアウトだからねぇ
4Kで思い出したがAV機器板のUHD-BDスレにて
・4か月弱ぶりのWHQL版「Radeon Software Adrenalin Edition 18.5.1」リリース。Ryzen 2000G公式対応を果たした統合型ドライバ
http://www.4gamer.net/games/022/G002212/20180524003/
「なお,新世代APUへの対応以外では,ハードウェアレベルの4Kビデオ保護技術としてMicrosoftが推進する「PlayReady 3.0」に
Radeon RX 500&400シリーズで対応したことと,「Ancestors Legacy」への最適化がトピックとなっている。」
「PlayReady 3.0」の対応、つまり外付けGPUを利用してのUHD-BD再生の道が一歩開けたということか?
Intel SGXに頼る必要はなくなった?
とあった
PCによる4K再生が少しでも身近になればいいのだが 面倒すぎてRIPした方が早い気がしてくる
HDMI2.0は破られてるし縛る意味とは
H265が身近になるには、あと数年、スマホのハードウェアデコーダー搭載率が上がったらだね
載ってない世代でCPUデコードはほぼ無理だし アンドロイド定番の画像ビューワ、PerfectViewerがプラグインでHEIFに対応してた
これで画像一括変換ソフトがHEIF対応してくれればなあ ジャップ製の印刷機やデジタル家電、ソフトなどが対応進まないと無理じゃね ちょっと戻っちゃうけど
画像の圧縮なら確かにPDFで「文字と背景を分ける」みたいな圧縮方式があるから、漫画の場合は画像一枚の中で背景レイヤーと文字・絵レイヤーを判別して、背景レイヤーを単色データにすればかなり圧縮できるはず それぞれのレイヤーで最適化しないと
単色データぶんだけデータが増えるだけに終わりそう Windows10 Insider Previewでheifの表示試してみたけど対応してるのはyuv420だけでyuv444は見れないな
あとx265のフルレンジフラグを読み取ってくれなくてリミテッド専用になってる
将来的には改善されるんだろうか?
今のままならBPGのほうが使いやすいんだが ちなみにWIC(Windows Imaging Component)でのサポートもしているのでWIC対応のSusie Pluginを入れるとMassiGraなんかでも見れた MSの実装だとYUVからRGBへの変換係数はbt709固定っぽいけどnokiaの実装だとsmpte170m固定っぽいから色がおかしくなる問題が続出しそう
どっちもx265のcolormatrixは読み込みにいってないし(heifのヘッダとかに指定するのかもしれないけどよく分からない)
この辺も整備されないと使いにくいな WindowsはOS、画像ビューアともに伝統的にICCプロファイルをきちんと反映させようとしていない(一部の優良な画像ビューアは対応している)からな いやごめん
MSの実装の方、フルレンジフラグを読み取ってくれないって書いたけどコマンドラインの記述が間違ってただけで修正したら読み取ってくれたわ
それにcolormatrixだけじゃなくてtransferとcolorprimも指定したら正しい色で表示してくれた
案外ちゃんとしてるな
こんな感じ
set "x265_option=-crf 23 -preset slower -x265-params colormatrix=smpte170m:transfer=smpte170m:colorprim=smpte170m:range=full"
ffmpeg -y -framerate 1 -i "%~1" -pix_fmt yuv420p -vf scale=out_color_matrix=smpte170m:out_range=pc:flags=+accurate_rnd %x265_option% -f hevc "%~dpn1.h265"
MP4Box -add-image "%~dpn1.h265":primary -ab heic -new "%~dpn1.heic"&&del "%~dpn1.h265" ARMがスマホ向け新GPU「Mali-G76」&新VPU「Mali-V76」を発表、スマホで8K・60fps再生に対応へ
https://gigazine.net/amp/20180601-arm-mali-g76-v76
https://i.gzn.jp/img/2018/06/01/arm-mali-g76-v76/b07.png
Mali-V76は2コアから8コアが想定されており、8コア時には8K・60fpsのデコードと8K・30fpsのエンコードに対応。4K・120fpsのデコードにも対応します
ただし、Mali-V76にはGoogleなどが開発する次世代コーデック「AV1」はサポートリストに含まれていません 動画の再生支援に関しては、スマホに先越されてばかりだな
そのうちスマホをPCに接続して、動画再生支援用の外付けGPUみたいにして使う時代が来るのかね? 新フォーマット→ハードウェア支援
っていたちごっこ 先越されていたっけ?
ARMのIP積んだモデル出回るのなんか1年先でしょ
それもPC並みの値段で HEVC 10bit 8KならIntelならCore iならKabylake、Atom系ならApolloLake(デコードのみ、エンコはGeminiLake〜)以降で対応
nvidiaならPascal世代で対応済みだから、ARMの方が2年近く遅い ?
SnapdragonのHEVCハードウェア再生支援は、余年くらい前から対応してたはずたがな
記憶違いか? スマホ -> PC -> モニタ ってめんどくさくね
スマホ -> モニタ でええやんか 久々にIntelの動画再生支援の対応可否をチェックしてみたが
・Intel HD, UHD and Iris Graphics(英語のサイト)
https://en.wikipedia.org/wiki/Intel_HD,_UHD_and_Iris_Graphics
■HEVC
・Haswellは、8bitのみ部分的な対応
・Broadwellは、8bitと10bitの部分的な対応
・Skylakeは、8bitは4Kまで対応
・Kaby LakeとCoffee Lakeは、8bitと10bitともに4Kまで対応
続く ■VP9(YouTubeなど)
・Haswellは、対応なし
・Broadwellは、部分的な対応
・Skylakeは、4K24Pの15Mbpsまで対応
・Kaby LakeとCoffee Lakeは、8bitのみ4K(60pかどうかは不明)まで対応
(BT.2020については将来的に対応予定)
※なお、下記サイトによると、AMDが「VegaベースのGPUコア=Radeon RX Vega 64 Liquid Cooled, Radeon RX Vega64, Radeon RX Vega56」
において、VP9の再生支援に対応していないとの記述があるが、これは本当なのか?
http://www.leoplanet.co.jp/entertainment/doga-saisei-shien.html
一方スマホは、Snapdragonの場合(最大対応解像度などの詳細は不明)
■Snapdragon 800⇒HEVC対応
■Snapdragon 805⇒HEVC対応
■Snapdragon 810⇒HEVC対応
■Snapdragon 820⇒HEVC、VP9ともに対応
■Snapdragon 821⇒HEVC、VP9ともに対応
■Snapdragon 835⇒HEVC、VP9ともに対応(これは、ARM版Windows 10でも有効)
※参考
https://en.wikipedia.org/wiki/VP9 追記
Snapdragon 820搭載のスマホにVP9でエンコードされた4K60Pの動画を入れて試したところ、
カクカクでした
4K60Pはやはり重い ARMはデコードにもGPUの演算コアも使ったりするからな
PC向けGPUみたいにメディアエンジンのみで処理出来るのは世代重ねてからだぞ
ソフトウェアデコーダより消費電力は低いけど、PCで言うところのハードウェアデコーダと少し実装違う
まぁそれでも消費電力の設計母数小さいからまだ省電力と言えるだけで
それでも砂ドラの800や805とかでH265の再生なんぞやったら、FHDでも数十分もせず馬鹿みたい発熱しながらバッテリー消費していく windowsならタスクマネージャでCPU使用率さくっと分かるけど、androidってシステムていきょうのツールねぇのかよ。
とりあえずCPU statsというアプリで動画再生しながらCPU使用率確認してるけど 俺もandroid8になって
CPU利用率見れなくなって不便してる ■Arm、モバイルで8K/60fps再生対応のVPU「Mali-V76」。VR/ゲーム向けGPUも
https://av.watch.impress.co.jp/docs/news/1125575.html
・8K60Pのハードウェア再生支援対応
・8K30Pのハードウェアエンコード対応(※これは現時点での話)
・4K60P動画の4本同時再生可能
・2K60P動画の16本同時再生可能
■ARM Announces Mali-V76 Video Processor: Planning For the 8K Video Future
https://www.anandtech.com/show/12835/arm-announces-maliv76-video-processor-planning-for-the-8k-video-future
・4K120Pも同時再生可能本数は不明ながら再生には対応
・H.264、HEVC、VP8、VP9のすべてにおいて、8bit及び10bitの動画をデコード及びエンコード可能
・AV1はデコード及びエンコードともに非対応 デコードもGPUコアのクラスタ数に依存しているという事は、メディアプロセッサだけでは、PC向けGPUと違ってデコードも処理出来ていないって事なんだがな クラウド上のFPGAを利⽤するAV1エンコーダーを実装
https://www.socionext.com/jp/pr/sn_pr20180606_01j.pdf
[横浜発, 2018 年 6 月 6 日] 株式会社ソシオネクスト (Socionext Inc.) は、アマゾン ウェブ サービス (以下「AWS」) の「Amazon Elastic Compute Cloud (以下、Amazon EC2) F1 インスタンス」上に、
最先端の映像データ圧縮規格「AV1」のエンコード処理を⾏う機能を試作実装しました
F1 インスタンスの利⽤により、約 1.5 カ月という極めて短期間で開発を完了し、かつ高い性能を得ることができました
当社は今回の成果をもとに、顧客がクラウドから半導体製品の機能を利⽤できる仕組みや、現在クラウド環境で広く利用されている大規模・高性能アプリケーションの処理能⼒を向上させる各種アクセラレーターの構築・運用など、
サービス提供を中心とした新しい製品の可能性を提案します
F1 インスタンスの利用により、開発開始から 1.5 ヶ月という驚異的な短期間での開発が可能になっただけでなく、FPGA によるアクセラレーションで CPU 単体動作と比較して約 10 倍の処理速度を実現しました これはいいね。LSIを起こせないようなスタートアップ企業が競い合って早く技術が成熟するといいですな。
大学の研究室からのエントリも面白い。 今年の第三四半期にAMDの新型スリッパが32コア64スレッドなCPUを投入するらしいが、そんな強烈なのが出たらHEVCのエンコードもサクサクかな? 性能倍なら同世代の16C32Tスリッパの倍以上の価格なんだろうけどね AV1のエンコーダーなかなか早くならないな
1080pの10フレームをエンコードするのに52分もかかった >>787
Intelの5GHz×28コアCPU搭載した化物マシンが必要 いや、>>378ではi7 4702MQで10フレームエンコードするのに66分かかったって書いてるからちょっとは早くなってるかな
こちらのCPUはi7 3520M 今年中に100倍程度速くなるなんて緩い予想はなかなか実現しそうに無いな 1フレームエンコードするのに6分かかるのか
昔の3DCGみたい AV1のエンコーダー以外を終了させて厳密に計り直したら早くなってたわ
まだ全然実用的じゃないけど
バイナリはここの
https://www.mediafire.com/?21254ingvippg
2018/03/27 v0.1.0-8892-g10b745615
1時間38分45秒
2018/06/01 v0.1.0-9658-g265d15d46
40分13秒 2ヶ月で2.5倍早くなると仮定しても年内に100倍には届かないか そんな小学生が成人するまで同じペースで背が伸びて2m越えるみたいな計算通らんわな 欠陥の無いダイがすげー安く作れるようになったらワンちゃんあるかも 今のところマルチスレッドをあまり生かしてくれないのが遅い原因の一つ
--tile-columnsを指定すると横で分割してマルチスレッドでエンコードしてくれるんだけど、
分割数は2の冪乗で、分割した一列あたり256px以上という制限があるので、
1920x1080の動画をエンコードしても4分割しかされず、
使ってくれるスレッドも4つぐらい 2passエンコで1pass目でキーフレームの場所を確定させちゃって
2pass目では複数のGOPを同時並列にエンコとかできないのかね。 >>800
いわゆる対抗特許だね
AV1陣営を特許侵害で訴えようとした企業にカウンターするための特許 >>800
ANSは一時期AV1のエントロピー符号化手法の候補になってたけど、
Daalaのエントロピー符号化手法のほうがハードウェア実装しやすいことが分かったので、
採用されなかった。 動画エンコードの探求に「終わり」はあるのか?
https://gigazine.net/news/20180614-end-of-video-coding/
> 2015年にNetflixの技術者が初めてMPEG会議に参加して、将来の動画コーディングのための文書を発表しました。
> その際に、Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑性が高まるとしてもまったく問題にしない」というスタンスであることを伝えると、
> 議長から「では、どのくらいの複雑さを許容できますか?」と尋ねられたとのこと。
> 回答の準備が整っていなかったNetflixの技術者は「最悪のケースでは100倍まで」と答えると、100人はいたであろう動画コーディングの専門家たちからは大爆笑が起こったそうです。
> 議長は「心配しないで。彼らはみな『新しいこと』を試すことができると、幸せに感じているのです。たいていの人は『3倍まで』と答えるものだから」と話したそうです。
Netflixは100倍遅くても許容するのかー
やっぱりこれから先の動画圧縮技術はリソース有り余ってる大企業だけのものになるんじゃないだろうか エンコードは1回しか行われないのに対してエンコードされた動画は何万回も再生されるから、
例えエンコードに従来の100倍の時間がかかるとしても、
それによって削減される帯域次第では動画配信やってる大手企業は喜んで採用するだろうね。 まあh266(?)とAV1以降のエンコードは一般人が持ってるpcじゃなかなか難しそうだろうね、NetflixやYouTube規模の動画配信サービスになるとそれだけの価値があるんでしょ
実際、Netflix、YouTube、アマプラ、Huluが完全にAV1を採用すれば全体のデータトラフィック量はどれくらい少なくなるんだろう ハードエンコの品質が上がって画質にうるさいマニアも納得のハードエンコの時代がきたらまだワンチャンある。
というか今エンコにどれくらいのトランジスター割かれてるのか知らんが何十億って使えばもっと速くなるのかな?? >>804
なるほど
しかもyoutubeみたく数億人のユーザーがほぼ同時にアップするわけじゃないから
Netflixにとってのハードルは低そう 限度知らずに高解像度を無茶な低帯域で保存しようとしなけりゃ、現状のHWエンコでも十分まで行かなくても、そこそこ使えるレベルだと思うけどな 品質についてはVLCの連中がx264/x265の開発止めない限り、個人が無償で扱えるエンコード品質の上限的な基準になっちまうから
妥協無しに満足するなんか無理な話だし
HWエンコーダに無い処理の柔軟性で画質引き上げてる部分が大きいから、その溝は埋められない
cudaコアの物量に頼っていないNVDecであの品質だから、nvidiaがQSV並みの実装する気になってくれれば、QSV HEVC並みの品質でQSVの2〜3倍速ってのは不可能では無さそうではあるんだけどな(GPUのグレードに左右されそうではあるけど 配信に使おうと思ってQSVとNVENC試してるんだけど同じビットレートだとNVENCのほうが画質良くなるみたいなんだよね
NVENCが何か改善されて良くなったのかな?
それともQSVがリアルタイムエンコに弱いのか QSVのH264でFF使う場合でも無い限り、基本的にはQSVの方が綺麗になるよ
CBRやビットレートベースのVBR使うとQSVの方が画質容量比悪化しやすいってのもあるけど あと、比較するQSVの世代にもよる
SnandyやIvy世代はHaswell以降よりCU規模の割に速度出やすい反面、画質向上処理はHaswell以降より劣る(処理が甘い分速くて画質に劣る CUはRADEONか、QSVはEUだった、すまん
NVEncはエンコードエンジンの性能勝負で
QSVはGPGPU込みで画質が良い(GPGPU使う時間が取れないFFモードだと画質が駄々下がり
画質は
QSV(延滞問わず)>NVEnc(元から低延滞)>QSV FF(低延滞モード)
みたいな感じ dGPU化でAMD CPU使いでも使えるようになるといいんだけども>QSV ・「Windows 10 RS5」で“WebP”がサポート、「Microsoft Edge」などで表示可能に
https://forest.watch.impress.co.jp/docs/news/1128464.html
「WebP」をウェッピーと読むのか
ずっとウェブエムだと思ってた… ウェッピーが正式な発音だと知ってるがウェブピーと読んでる ヽ
_,,.,、、,.ィ-- ti- 、、、....,,,,_ ',
,,..、、ri':'゙/~ レ ' ゙ヘ:l : : : :~,>
_,...r:::''"::/ l/ .l:/-=ニ二,'_ー- 、、 !l!;: r '"
'''<:::::::::::::;、r' `'' ‐-`.、 /
-、 l::::::::::::l <"゙'i;ソ' ',
~.ヽ l:::::::::::l ~' '、
/ .) .l::::::::::! '、
ヽ .l:!l:::::l ヽ '、
\ ' l! l::!l! ヽ ,'
゙ ヾ ‐'" ,. r ゙ そんなに何も見えてないんじゃ
ー-‐i ,.r,,iilll鬚髯ヲ
. l `''' ‐‐ ---t‐' 生きてても面白くないでしょう
 ̄ ̄ ̄ ̄ ̄ ̄~"''、' ‐ 、 ー‐ノ
', ヽ l ・4K映像の低遅延配信に「CMAF」が有効、コーデックは「AV1」主流に? Akamaiが解説
https://av.watch.impress.co.jp/docs/news/1128920.html
AV1は、HEVCやVP9などよりも高い圧縮効率を実現し、開発者向けブラウザのFirefox NigtlyやChrome Canaryでは既に採用されているが、3月予定としていたコードフリーズには6月時点でまだ至っておらず、当初の予定より遅延。
現在はエンコードをソフトウェアで行なっているため多くの時間がかかり、時光氏は「ハードウェア対応は'19年後半にずれ込む恐れがある」としている。
まだコードフリーズすらしていないのか 数ヶ月前にエンコードしたファイルが新しいバージョンだと出来なくなってるとかまだあるから全く使い物にならないよ ttps://github.com/AOMediaCodec/av1-spec/commits/master
仕様のコミットログ見るとぼぼ毎日更新してる。
更新の規模は体裁を整えたりとか、仕様を明確化したりぐらいが多いけど。
ttps://people.xiph.org/~tterribe/pubs/lca2017/aom.pdf
ハードウェア実装しやすいアルゴリズムかどうかはちゃんと考慮されてるみたい。
17ページ目に新しい機能は
ハードウェアチーム、知財チーム、ワーキンググループ全体
の順でレビューされると書かれてる。 youtubeとかで使われるようになってもほとんどの端末ではしばらくソフトウェアデコードになるだろうけど負荷はどれくらいになるのだろうか
スマホでも余裕なくらいじゃないとキツイぞ HWデコーダが無い機種はH.264で観ればいいだけだからヘーキヘーキ すぐに変換されるのは4K以上の動画ぐらいでしょ、きっと AV1だろうがそもそもモバイルで4K解像度もってるデバイスほとんどみねぇし、2Kにちょっと毛がはえたぐらいの解像度なら現状出回ってる機種でも余裕じゃねぇのかな。
まぁモバイルはバッテリーの問題があるけどさ。 と思ったけどH.264のフルHDをSWデコードしてみたらFireHD10で結構CPU使用率いくな YouTubeはビットレートが足りないのと粗雑エンコで1080pは見れたものじゃないから、超高精細映像に構うよりは1080p以下の映像に目線を向けるべきだと ネットの人ってどうして一つしか正解を許さない人が多いんだろ 頭が悪いんだろ
脳内が視野狭窄状態みたいになってる奴がいる https://aomedia.googlesource.com/aom/
タグがv0.1.0からv1.0.0になった
さすがにそろそろ仕様固まるかな AV1の対応、ChromeとFirefoxは着々と進んでいるけどSafariとEdgeはほとんど聞かないね >>843
EdgeはともかくSafari(Mac、iOS)は最後まで抵抗しそう Appleだって支援してるんだからそれはねえわ
HEICとか作ってまでh265推してたが今時サンクコストにしがみ付いたりはせんやろ
ただハードウェアエンコーダ/デコーダが実装されているという理由で少なくとも2、3年はOSデフォルトとはせんやろな AppleもAOMediaの創設時メンバーなのだから、VP9みたいな事態にはならないと思っているがね ■ このスレッドは過去ログ倉庫に格納されています