次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
■ このスレッドは過去ログ倉庫に格納されています
H.264/AVCの後の様々なビデオコーデック全般について語るスレです。
■主な次世代ビデオコーデック
・H.265/HEVC
・VP9
・AV1(AOMedia Video 1)
・VVC(Versatile Video Coding)
■前スレ
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1532001049/
次スレは>>980が宣言してから立ててください。 ■各ビデオコーデックの概要や状況（2019年1月下旬時点）
●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で採用されている。 ●AV1(AOMedia Video 1)
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/ ■各社GPUのHWエンコーダでのH.265/HEVCおよびVP9のサポート状況(2019年1月下旬時点)
●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
未対応 ■AV1のエンコーダ/デコーダ実装の例
●エンコーダ
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がテスト採用されてるといったことも書いた方が良かった気もするし
他に書くべきこともあったかもしれないけど、スレ立てを急いだほうがよさそうだったのであまり変えてない。 「Firefox 65」が正式公開 〜トラッキング保護を改善、WebP/AV1をサポート - 窓の杜
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） 誰もMac mini 2018のHEVCエンコードのレポートしてくれないな
俺がやるしかないのか あ、持ってるよ。低ビットレートだとやっぱx265のがずっと綺麗です。1080p60時に20Mbpsとか大盤振る舞いをするなら大して変わらないから便利です
例えばPS4のゲームをHDMI経由でキャプチャーしてソース動画がある場合なんかはx265で重めのプリセットで10Mbpsくらいでエンコしても劣化が目立つのでどのみち20Mbps程度は必須。このビットレート領域だとAppleのも悪くはないです ちなみにFFmpegでもCompressorでも出来ることは殆ど一緒でカスタマイズ項目は少ない。2パスエンコは不可能 量子化係数のより高い状態でのエンコードで、如何に画質の劣化を軽減するか
それを如何に効率よく処理するかがエンコーダ性能の優劣だからな
高ビットレートを容認すればするほど前者が問われ無くなるから、そりゃ差は縮むわな まー1080p60で10MbpsでもSSIM 0.01違いとかそんなもんです
Compressorから圧縮するとちゃんとBフレームも使う
13500フレームの動画でx265だとBフレームが9900程度、T2だと9500程度になった
リアルタイムエンコーダーとしてはそこそこ優秀だと思いますよ フィルムグレイン多い実写だとx265でもダメダメだなあ
エンコ時間かかりまくるのに全然縮まない
アニメ専用かよ グレインとかCMOSの暗部ノイズはランダムノイズなので動き補償と相性悪すぎるからしょうがない
砂嵐をエンコードしてるようなもん デジタルシネマは圧縮電送して、シネコン側で指定されたフイルムグレイン(KODAK何番とか)足して再生すると、何かで読んだけど
確かに圧縮効率を考えたら、ある程度フィルターでグレイン取って圧縮して、再生で足すのは考え方としてはアリか 「8K」の普及促進や規格化を担う団体「8K Association」が発足。
ttps://www.4gamer.net/games/999/G999902/20190130060/
Chinock氏は，8Kエコシステムを回す追い風として，「HDMIやDisplayPortなどの映像インタフェースは，8Kへの対応が完了していること」と，
「同品質の映像を，H.265の半分のビットレートで圧縮可能な次世代コーデック『H.266』の開発が進行中であること」などを挙げていた。 >>30
シーンごとカットごとでの指定はできるんかね？ 映画制作側は「俺の創った映像と違う」とか言って拒みそうな機能だな
24p→60pも否定的だったし >>34
トム・クルーズが「勝手にコマ数増やすな」と、テレビやと視聴者に文句言ってるのなw >>32
メタデータで指定してるんじゃないかな
>>33
あ、AV1か
ありがとう >>38
インストールさえできればHW非対応の構成でも再生できるんだよなぁ コーデックもそうだけど、動画まわりのAPIもどうにかしてほしい。もっと洗練されたクロスプラットホームなやつを.. windowsにしたって>>35は古いDirect ShowフィルタじゃなくてMedia Foundation用のコーデックだろ。MS純正のアプリはMedia Foundationに移行してると思うが、サードパーティーでMedia Foundation使ってるるプレイヤーってそんなにあるのか? >>41
MS純正のアプリ使わないならLAV Filtersで事足りるからなあ・・・
MediaFoundationを意識するプレーヤーなんてQonohaくらいしか知らん・・・ 動画APIがクロスプラットホームである必然性なんて微塵もない
何をやってもHDTVとPCのガンマを同一と見做して変換してくれない糞プレイヤーが多いままなのは永久に変わらない 動画がらみのAPIがクロスプラットフォームじゃなかったら、ffmpegがanroidかwindowsかどちらかでしか動かないくなるんだけど。
vlcやらも大変。
ffmpegのlibavやらlibavformatやらがクロスプラットだから、後はUIのがわをだけ作ればいいように楽できるんだけど。
libavとかカオスだし、gstreamerはまだましっぽいけど。 Direct Showは、いずれ廃止になるんだから、さっさと移行しろよとは思うが、動画の世界は古い技術にしがみつきたがるやつが少なからずいるのが癌ではある AV1拡張入れてもWin10のWMPでAV1動画が再生できなかったからMFとはまた別かと思ってた BlueskysさんのDSF/MFT Viewer（DXVACheckerにも内蔵）を使うと
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は後者を使ってるのかな？ 宮廷ドラマ「H.265/HEVC華麗なる軌跡」
2014年、MPEG-LAがパテントプールのライセンスを発表
2015年、パテントプール分裂、HEVC Advanceが爆誕
2016年、Technicolor社がHEVC Advanceを脱退
2017年、第3のパテントプールVelos Mediaが爆誕
2018年、Technicolor社がパテントトロールInterDigital社に特許権売却
2019年、パテントトロールのBlackBerry社がVelos Mediaに参加←New! こういう利権とかうるさいのって日本だけかと思ってたけど、やっぱ世界でも似たようなもんなんだなって思う ライブ配信向けのエンコーダか
1080pで最低16GB必要とはなかなか重いね AVIFはどうなってるのかな
なんかwebpより画質悪いみたいだけど 画質を気にするならJPEG 2000にしとけば？
HEIFもだけど動画のイントラ系は高画質寄りだとあまりメリットない HEIFって4:4:4無いの?あるなら互換性を除けば非可逆で最もベターに思えるけど 画質保ちたいならpng使うもんな
ほとんどの人はそれなりの画質で高圧縮を求めている >>55
VP8ベースのwebpよりVP9後継のAV1使ったAVIFが画質悪いの？ >>58
iOSで4:4:4 HEIFで保存するサードパーティアプリあるので、出来るといえば出来る
OSデフォルトのカメラは4:2:0だけど 何よりもクソなのはmacOS MojaveだとHEIF Losslessが追加されたのに実際は何かロスる。
たぶん4:2:0に変換された物がロスレスでコーディングされてるw 4:4:4でもYUVだとロスりそうな気が
ロスレスならGBRでしょ >>64
10bit12bit使えるはずなのでそれら使えばロスらない
でもこの辺ちゃんと対応してるのかね >>66
デュアルレンズiPhone専用で高額レンズのシミュレーションを行うFocosっていうアプリ
この手のアプリでは圧倒的なクオリティで専用ハードを使うLight L16より綺麗 >>65
ロスレスで深度深くしたらRGBのままより圧縮効率落ちる。つまり、ただのzip圧縮と変わらないPNGに負ける
ロスレス最高効率のFLIFは8bit深度のままロスレスYCoCg変換しててこれが正解。HEVCだってYCoCgに対応してるのにやらない所がクソなんですよ >>63
422から420って、色の2が0にロスってるけどw
それロスレスって言っていいのか >>68
なるほどぉー
これは勉強になった
RGBよりdeep色向けな最適化軸が
YCoCgなのかな？
ぐぐって勉強してみよう >>68
> 8bit深度のままロスレスYCoCg変換しててこれが正解
微妙な表現だけど、前スレ938での
> ビット数増やすのも計算途中だけで良い
> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる
といった書き込み内容も踏まえると、
「8bitのRGB」と「8bitのYCoCg」は相互に可逆変換できる
と考えてるように見えるけど、それは違う。
前スレが終わる直前
https://mevius.5ch.net/test/read.cgi/avi/1532001049/996
に書いたから見てないかもしれないけど、「8bitのRGB」を可逆変換するなら
YCoCg側は「10bitのYCoCg」か「Y8C9bitのYCoCg-R」が必要になる。
一般的に有用なのは後者の「Y8C9bitのYCoCg-R」。 >>68
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 >>68
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限定なら有用かもしれない。
（続く） >>68
（続き）
・じゃあ可逆性を重視して「10bitのYCoCg」を使うぜ！
→でも8bitRGBをエンコするために10bitYCoCgを使っても
圧縮効率の向上はあまり期待できないらしい？
→「8bitのRGB」をそのままエンコードした方が圧縮効率が良いのでは？
→「10bitのYCbCr」も8bitRGBと可逆性があるはずだし、そっちでもいいのでは？
→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
→4:4:4限定なら有用かもしれない。
という感じで、現状実用できる範囲ではあまりメリットが無さそうな感じ。 >>68
更に、仮に今後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について調べたことをまとめて連投してみたのだけど、
理解が正しいかよくわからんとこもあるので、指摘があればよろしくたのんます。 いいよ。ここでやればいい。興味なければスルーするだけだし。 libvpxアップデート来てるやん
エンコードが速くなったらしい
テストはしてないけど >>81
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" --auto-alt-ref=0が無効で1が有効だと思っていた。
6ってどういう意味だろう？ >>83
自分もそう思って少しソースを調べてみたんだけど、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; WEBPでPNGをロスレス変換したときのファイルサイズの減少率に感動して
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…
たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな 他人エンコならAAC128でも気にしないけど自分エンコの320とWAVは異様に気になって識別しちゃうみたいな所あるよね。
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする >>85
WebPのロスレス、実はロスレスじゃないという話があるけどどうなんだろう >>87
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー
と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年〜2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う こっちのirfanviewとXnViewではちゃんとロスレスだった https://github.com/imagemin/cwebp-bin/releases
を使ってコマンドライン（-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設定のまま保存されていたようだ windowsの仕業だったのか
Macだとどうなるんだろ なぜに管理者・・と思ったけど
圧縮率の情報をレジストリにでも書き込む仕様なんだろうか？ GIMPでHEIF/HEIC保存できるのを知って>>90の16777216色画像でlossless変換してみたけど
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな
ファイルサイズもWEBPの181kB->12.7kBに対して12MBまで膨れ上がってたし
少なくとも現時点のバージョンでlossless厨の自分がHEIF/HEICのお世話になることはなさそうだ
このスレ見といて本当によかった 詳しい人ありがとうございます
数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな それほど大量にPNGを扱っているなら場合によってはBMPにして7zとかzpaqなどのアーカイブに放り込む方が縮むかもしれない
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな… 最新のAcrobat Pro DCでHEIC開けなかったわ
PDFってまだHEIF埋め込める仕様になってないん?(´･ω･`) pngcrushで事足りてるな...
(もっと効率良いPNG再圧縮プログラムもあるけど、デフォルトでメタデータが保持されない物が多いのでpngcrushが安全 MicrosoftのHEIF画像拡張機能を入れてテストしてみようとしたら
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀) PNG最適化ならzopflipngが今のところ一番縮むはず zopflipngのコマンドラインは残すチャンクを手動指定しないとメタデータを軒並み消される メタデータまで含め非破壊で安全である事と、速度と圧縮効率のバランスの良さでpngcrushの標準(-bruteとか指定しないで普通に使う)は使い勝手が良い ■ このスレッドは過去ログ倉庫に格納されています
