次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
■主な次世代ビデオコーデック
・H.265/HEVC
・VP9
・AV1(AOMedia Video 1)
・VVC(Versatile Video Coding)
■前スレ
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
https://mevius.2ch.sc/test/read.cgi/avi/1532001049/
次スレは>>980が宣言してから立ててください。
●H.265/HEVC
・https://www.itu.int/rec/T-REC-H.265
・https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jctvc.aspx
・https://mpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding
・https://hevc.hhi.fraunhofer.de/
・https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
●VP9
・https://www.webmproject.org/vp9/
・https://en.wikipedia.org/wiki/VP9
●AV1
・http://aomedia.org/
・https://aomedia.googlesource.com/aom/
・https://github.com/AOMediaCodec/av1-spec
・https://en.wikipedia.org/wiki/AV1
●VVC
・https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jvet.aspx
・https://mpeg.chiariglione.org/standards/mpeg-i/versatilevideo-coding
・https://jvet.hhi.fraunhofer.de/
・https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Versatile_Video_Coding
●H.265/HEVC
H.264/AVCの後継規格。放送やUltra HD Blu-ray等で採用が進んでいるが
３つのライセンスプールが並立するなどライセンス面での問題も抱えている。
H.265/HEVC特許暗黒時代
https://qiita.com/yohhoy/items/c2579097a507b1fbdddb
HW再生支援のサポートは進んだものの、FirefoxやChromeでの対応が進んでおらず、
ネット配信では使いづらい状況が続いている。(スマートTV向けの配信等は除く)
AppleがHLS(HTTP Live Streaming)やiOS 11やmacOS High Sierraで採用したり、
2018年3月にライセンスプールの１つであるHEVC Advanceが
コンテンツへのライセンス課金を取りやめたりといった好材料も出てきてはいる。
●VP9
Googleによって開発されたロイヤリティフリーのコーデック。
ブラウザ(Safariを除く)やHW再生支援のサポートも進み、主にYoutubeで採用されている。
Amazon/Cisco/Google/Intel/Microsoft/Mozilla/Netflix等が中心となって立ち上げた
Alliance for Open Mediaによって開発されたロイヤリティフリーのコーデック。
VP10/Daala/Thorの技術を受け継いでいる。
2018年3月末にリリースされたが、v1.0.0の仕様確定は2018年6月末にずれこんだ。
HW再生支援のサポート等も含めた本格的な普及は2020年頃になる見込み。
コンテンツ配信/ハードウェア/ブラウザ系などの主要企業がサポートを表明しており、
ネット配信を中心として広く普及することが期待されている。
●VVC(Versatile Video Coding)
H.265/HEVCの後継規格。2020年10月の標準化を目指して
JVET(Joint Video Experts Team)で検討が進められている。
また、H.265/HEVCのようなライセンス問題を繰り返さないため、
MC-IF(Media Coding Industry Forum)という業界団体が立ち上がっている。
http://www.mc-if.org/
https://en.wikipedia.org/wiki/HTML5_video#Browser_support
●H.265/HEVC
・https://html5test.com/compare/feature/video.codecs.mp4.h265.html
・https://caniuse.com/#feat=hevc
●VP9
・https://html5test.com/compare/feature/video.codecs.webm.vp9.html
・https://caniuse.com/#feat=webm
●AV1
・https://caniuse.com/#feat=av1
●Intel
・https://software.intel.com/en-us/media-sdk
・https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
●NVIDIA
・https://developer.nvidia.com/nvidia-video-codec-sdk
・エンコード： https://en.wikipedia.org/wiki/Nvidia_NVENC
・デコード： https://en.wikipedia.org/wiki/Nvidia_PureVideo
●AMD
・https://github.com/GPUOpen-LibrariesAndSDKs/AMF
・エンコード： https://en.wikipedia.org/wiki/Video_Coding_Engine
・デコード： https://en.wikipedia.org/wiki/Unified_Video_Decoder
●Intel QSV (Kaby Lake/Coffee Lake＋Intel Media SDK 2018 R2)
〇HEVC
mainおよびmain10。Bフレーム使用可。
〇VP9
・LinuxでVA-APIを使えばKaby Lakeで利用可能らしい。
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
・Intel Media SDK for Windows 2018 R1で、Cannon Lake向けの
プレビュー機能としてVP9エンコーダ関連のAPIが追加されたので
Cannon LakeからはWindowsでも使えるようになるかもしれない。
●Nvidia NVEnc (Turing＋NVIDIA Video Codec SDK 8.2)
〇HEVC
mainおよびmain10。TuringでBフレームに対応。
〇VP9
未対応
●AMD VCE (Polaris＋AMF 1.4.9)
〇HEVC
mainのみ。main10は不可。Bフレーム使用不可。
〇VP9
未対応
●エンコーダ
xiph/rav1e: The fastest and safest AV1 encoder.
https://github.com/xiph/rav1e
●デコーダ
VideoLAN / dav1d - GitLab
https://code.videolan.org/videolan/dav1d
テンプレの変更点は以下の通り。
・各コーデックの参考リンクを>>2に移動
・諸々の状況を2019年1月下旬時点にあわせて更新
・VVCの説明にMC-IFのことを追記
・HWエンコーダの説明で、SDKのバージョンを更新
・HWエンコーダの説明で、TuringでのHEVC Bフレームサポートを追記
・>>8にAV1のエンコーダ/デコーダ実装を追加
Youtubeの一部の動画でAV1がテスト採用されてるといったことも書いた方が良かった気もするし
他に書くべきこともあったかもしれないけど、スレ立てを急いだほうがよさそうだったのであまり変えてない。
https://www.microsoft.com/ja-jp/p/av1-video-extension-beta/9mvzqvxjbq9v
YouTube TestTube
https://www.youtube.com/testtube
https://forest.watch.impress.co.jp/docs/news/1167182.html
・WebPのサポート（image.webp.enabled＝true）
・AV1がデフォルトで有効になった。（media.av1.enabled＝true）
・dav1dデコードはデフォルトだと無効っぽい。（media.av1.use-dav1d＝false）
俺がやるしかないのか
例えばPS4のゲームをHDMI経由でキャプチャーしてソース動画がある場合なんかはx265で重めのプリセットで10Mbpsくらいでエンコしても劣化が目立つのでどのみち20Mbps程度は必須。このビットレート領域だとAppleのも悪くはないです
それを如何に効率よく処理するかがエンコーダ性能の優劣だからな
高ビットレートを容認すればするほど前者が問われ無くなるから、そりゃ差は縮むわな
Compressorから圧縮するとちゃんとBフレームも使う
13500フレームの動画でx265だとBフレームが9900程度、T2だと9500程度になった
リアルタイムエンコーダーとしてはそこそこ優秀だと思いますよ
エンコ時間かかりまくるのに全然縮まない
アニメ専用かよ
砂嵐をエンコードしてるようなもん
確かに圧縮効率を考えたら、ある程度フィルターでグレイン取って圧縮して、再生で足すのは考え方としてはアリか
ttps://www.4gamer.net/games/999/G999902/20190130060/
Chinock氏は，8Kエコシステムを回す追い風として，「HDMIやDisplayPortなどの映像インタフェースは，8Kへの対応が完了していること」と，
「同品質の映像を，H.265の半分のビットレートで圧縮可能な次世代コーデック『H.266』の開発が進行中であること」などを挙げていた。
シーンごとカットごとでの指定はできるんかね？
「デノイズしてエンコードした映像」と「モデル化されたグレイン情報」に分けておいて、デコーダー側で合成するらしい。
https://en.wikipedia.org/wiki/AV1#Filters
https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/
24p→60pも否定的だったし
https://www.microsoft.com/ja-jp/p/web-media-extensions/9n5tdp8vcmhs
MPEG-2
https://www.microsoft.com/ja-jp/p/mpeg-2-video-extension/9n95q1zzpmh4
HEIF
https://www.microsoft.com/ja-jp/p/heif-image-extensions/9pmmsr1cgpwg
HEVC
https://www.microsoft.com/ja-jp/p/hevc-video-extensions/9nmzlz57r3t7
VP9
https://www.microsoft.com/ja-jp/p/vp9-video-extensions/9n4d0msmp0pt
AV1
https://www.microsoft.com/ja-jp/p/av1-video-extension-beta/9mvzqvxjbq9v
トム・クルーズが「勝手にコマ数増やすな」と、テレビやと視聴者に文句言ってるのなw
メタデータで指定してるんじゃないかな
>>33
あ、AV1か
ありがとう
デバイス製造元からの HEVC ビデオ拡張機能
https://www.microsoft.com/ja-jp/store/p/hevc-video-extension/9n4wgh0z6vhq
ハードウェアデコーダ用HEVC（無料）
インストールさえできればHW非対応の構成でも再生できるんだよなぁ
MS純正のアプリ使わないならLAV Filtersで事足りるからなあ・・・
MediaFoundationを意識するプレーヤーなんてQonohaくらいしか知らん・・・
何をやってもHDTVとPCのガンマを同一と見做して変換してくれない糞プレイヤーが多いままなのは永久に変わらない
vlcやらも大変。
ffmpegのlibavやらlibavformatやらがクロスプラットだから、後はUIのがわをだけ作ればいいように楽できるんだけど。
libavとかカオスだし、gstreamerはまだましっぽいけど。
DSF(Direct Show Filter)やMFT(Media Foundation Transform)の一覧が見れるから見てみるといいかも。
https://bluesky23.yukishigure.com/DsfMftViewer.html
https://bluesky23.yukishigure.com/DXVAChecker.html
うちは>>38くらいしか入ってないけど、Media Foundationの方に
HEVCVideoExtension(デコーダ)
HEVCVideoExtensionEncoder(エンコーダ)
がある。
A's Video Converterで選べるMicrosoft H.265 Encoderは後者を使ってるのかな？
今は拡張でAV1をWMPで再生出来るよ
2014年、MPEG-LAがパテントプールのライセンスを発表
2015年、パテントプール分裂、HEVC Advanceが爆誕
2016年、Technicolor社がHEVC Advanceを脱退
2017年、第3のパテントプールVelos Mediaが爆誕
2018年、Technicolor社がパテントトロールInterDigital社に特許権売却
2019年、パテントトロールのBlackBerry社がVelos Mediaに参加←New!
https://www.phoronix.com/scan.php?page=news_item&px=Intel-Open-Source-SVT-AV1
https://github.com/OpenVisualCloud/SVT-AV1
1080pで最低16GB必要とはなかなか重いね
なんかwebpより画質悪いみたいだけど
webpより画質悪いってどこの情報？
HEIFもだけど動画のイントラ系は高画質寄りだとあまりメリットない
ほとんどの人はそれなりの画質で高圧縮を求めている
VP8ベースのwebpよりVP9後継のAV1使ったAVIFが画質悪いの？
iOSで4:4:4 HEIFで保存するサードパーティアプリあるので、出来るといえば出来る
OSデフォルトのカメラは4:2:0だけど
たぶん4:2:0に変換された物がロスレスでコーディングされてるw
ロスレスならGBRでしょ
10bit12bit使えるはずなのでそれら使えばロスらない
でもこの辺ちゃんと対応してるのかね
そのアプリ名おせーて
デュアルレンズiPhone専用で高額レンズのシミュレーションを行うFocosっていうアプリ
この手のアプリでは圧倒的なクオリティで専用ハードを使うLight L16より綺麗
ロスレスで深度深くしたらRGBのままより圧縮効率落ちる。つまり、ただのzip圧縮と変わらないPNGに負ける
ロスレス最高効率のFLIFは8bit深度のままロスレスYCoCg変換しててこれが正解。HEVCだってYCoCgに対応してるのにやらない所がクソなんですよ
422から420って、色の2が0にロスってるけどw
それロスレスって言っていいのか
なるほどぉー
これは勉強になった
RGBよりdeep色向けな最適化軸が
YCoCgなのかな？
ぐぐって勉強してみよう
> 8bit深度のままロスレスYCoCg変換しててこれが正解
微妙な表現だけど、前スレ938での
> ビット数増やすのも計算途中だけで良い
> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる
といった書き込み内容も踏まえると、
「8bitのRGB」と「8bitのYCoCg」は相互に可逆変換できる
と考えてるように見えるけど、それは違う。
前スレが終わる直前
https://mevius.2ch.sc/test/read.cgi/avi/1532001049/996
に書いたから見てないかもしれないけど、「8bitのRGB」を可逆変換するなら
YCoCg側は「10bitのYCoCg」か「Y8C9bitのYCoCg-R」が必要になる。
一般的に有用なのは後者の「Y8C9bitのYCoCg-R」。
YCoCgには、基本として「YCoCg」と「YCoCg-R」の2種類があって、FLIFが使ってるのは「YCoCg-R」。
元が「8bitのRGB」の場合は、「Yが8ビット、Co/Cgが9ビットのYCoCg-R」に変換して、それを圧縮している。
（「YCoCg-R」は、Co/Cgが1ビットずつ増えるけど、可逆性を持ち、かつ圧縮効率が良い）
YCoCg(-R)を入出力に使うH.264/H.265と違って、
FLIFは入出力はRGBで、内部計算でYCoCg-Rを使ってるだけかな。
符号なし整数にするんじゃなく、符号つき整数として扱ってるようで、
8bitRGBの場合、R/G/B/Y：0〜255、Co/Cg：-255〜255という値範囲で扱われてる模様。
https://flif.info/spec.html
H.264/H.265は「YCoCg」も「YCoCg-R」も規定されてるけど、
・x264/x265では
色差の深度 = 輝度の深度 + 1
というエンコード処理ができないはずなので、
YCoCgの本命である「Y8C9bitのYCoCg-R」は使えない。
対応しているエンコーダ/デコーダがあるかも不明。
・じゃあ非可逆になってしまうけど圧縮効率向上に期待して「8bitのYCoCg」を使うぜ！
→他のYCbCrと同様に、400万色くらいしか表現できないよ。
→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
→4:4:4限定なら有用かもしれない。
（続く）
（続き）
・じゃあ可逆性を重視して「10bitのYCoCg」を使うぜ！
→でも8bitRGBをエンコするために10bitYCoCgを使っても
圧縮効率の向上はあまり期待できないらしい？
→「8bitのRGB」をそのままエンコードした方が圧縮効率が良いのでは？
→「10bitのYCbCr」も8bitRGBと可逆性があるはずだし、そっちでもいいのでは？
→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
→4:4:4限定なら有用かもしれない。
という感じで、現状実用できる範囲ではあまりメリットが無さそうな感じ。
更に、仮に今後x264/x265で「Y8C9bitのYCoCg-R」が使えるようになったとしても、
H.264/H.265の規格では
・「YCoCg-R」が使えるのは4:4:4だけ。
と規定されている。
・4:4:4の可逆性確保および圧縮率向上
というメリットは得られるので、4:4:4のHEVCやHEIFの圧縮率の向上には有用かもしれないが、
4:2:2/4:2:0では使えないため、4:4:4動画が一般的にでもならない限り、
「YCoCg-R」が一般的に使われることもなさそう。
階調的には10bit/12bitのYCbCrで十分だし、視覚特性を踏まえたICtCpってのもあるみたいだし、
そのあたりを考えると、x264/x265等のエンコーダやデコーダが
わざわざ「YCoCg-R」に対応する可能性も低そうな気がする。
という感じでYCoCgについて調べたことをまとめて連投してみたのだけど、
理解が正しいかよくわからんとこもあるので、指摘があればよろしくたのんます。
立てるしかない感じ？
エンコードが速くなったらしい
テストはしてないけど
https://github.com/webmproject/libvpx/blob/master/CHANGELOG
2019-01-31 v1.8.0 "Northern Shoveler Duck"
・リアルタイムエンコやVOD用途のエンコードパフォーマンス改善を頑張ったよ。
・VP9の制御機能の追加・改善をしたよ。主に SVC (Scalable Video Coding) 関連。
・VP9の2パスエンコの品質が改善されたよ。--auto-alt-ref=1 で 4〜5% くらい。
（--auto-alt-ref=6 だと 5〜10% らしいけど、--auto-alt-ref=6 ってのはSVC関連だろうか？）
・リアルタイムエンコードについて
・speed 7 が 5〜10% くらい改善されたよ。（速度なのか品質なのかよくわからんが多分速度？）
・スクリーンシェアリング用途で、シーンチェンジやスクロール時のエンコが改善されたよ。
・モバイルデバイス用に、新たに speed 9 が追加されたよ。speed 8 より 10-20% くらい速いよ。
・その他のバグ修正もしたよ。
---
1.7.0 はもう1年以上前なのか。
2018-01-04 v1.7.0 "Mandarin Duck"
6ってどういう意味だろう？
自分もそう思って少しソースを調べてみたんだけど、VP8では確かにそうだった。
VP9だと、--auto-alt-ref に指定できる値の範囲が 0〜MAX_ARF_LAYERS(6) に変わって、
2以上を指定した場合は multi_layer_arf というコードが有効になるらしい。
マルチレイヤーAltRefFrameってことなんだろうけど、それがなんなのかはよくわからない。
レイヤーって概念はSVC関連のものかと思ったのだけど、コード見るとSVCでは機能しないとなってるし・・・。
vp9\encoder\vp9_encoder.c
// Is multi-arf enabled.
// Note that at the moment multi_arf is only configured for 2 pass VBR and
// will not work properly with svc.
// Enable the Jingning's new "multi_layer_arf" code if "enable_auto_arf"
// is greater than or equal to 2.
if ((oxcf->pass == 2) && !cpi->use_svc && (cpi->oxcf.enable_auto_arf >= 2))
cpi->multi_layer_arf = 1;
else
cpi->multi_layer_arf = 0;
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…
たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする
WebPのロスレス、実はロスレスじゃないという話があるけどどうなんだろう
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー
と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年〜2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う
を使ってコマンドライン（-lossless -z 9 -m 6 -mt -q 100 -o）でupload.wikimedia.org/wikipedia/commons/e/e9/16777216colors.pngをlossless変換したところ
2.0.5から5.0.0まで全部同じ16777216色だった
コマンドラインでは Lossless-ARGB compressed size: ***** bytes と表示されているから
おそらくRGB32色空間での圧縮と思われる
>>89
もしやと思って管理者権限での起動でirfanview使って変換したら色数変わらずlosslessだった
windows10の変な機能で保存時に設定変えてもlossy75設定のまま保存されていたようだ
Macだとどうなるんだろ
圧縮率の情報をレジストリにでも書き込む仕様なんだろうか？
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな
ファイルサイズもWEBPの181kB->12.7kBに対して12MBまで膨れ上がってたし
少なくとも現時点のバージョンでlossless厨の自分がHEIF/HEICのお世話になることはなさそうだ
このスレ見といて本当によかった 詳しい人ありがとうございます
数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな…
PDFってまだHEIF埋め込める仕様になってないん?(´･ω･`)
(もっと効率良いPNG再圧縮プログラムもあるけど、デフォルトでメタデータが保持されない物が多いのでpngcrushが安全
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀)
100〜のスレッドの続きを読む