次世代ビデオコーデック総合スレ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が宣言してから立ててください。 そういえばハードウェアのエンコードって動画の場合ではソフトウェアよりかなり画質が落ちるけど静止画の場合だとどうなんだろう >>592
ssim0.985辺りで見てみるとjpegに対してのwebmに近い比率でwebmに対してのAVIFは縮むんやね
BPGはエンコードは兎も角デコード重過ぎ&対応ソフト少な過ぎで使い物にならなかったけどwebmの倍までのデコード速度と同程度の普及にはなって欲しいなぁ Appleは最近画像フォーマットにHEVCベースのHEIFを使ってるけど、
AVIF完成したらAVIFに移行するんかな。
もしそうなったらスマホ用サイトの画像フォーマットにAVIF普及しそう。
>>595
動画ほどソフトとハードでの画質の差は出ないと思うよ。
一枚絵の画像だとソフトとハードの差が出やすいフレーム間予測による圧縮がないので。 ソフトとハードでどのくらい違うか気になったので>>592のグラフにx264とh264_qsvを追加(項目名クリックで表示切り替え可能)
https://plot.ly/~fg1189467/33/
まあ少し落ちるけどこれくらいなら許容範囲かな Next-Generation Image Compression (JPEG XL) Final Call for Proposals
https://jpeg.org/items/20180423_cfp_jpeg_xl.html
これAV1じゃないの JPEG-XL >60% over JPEG-1
MPEG-H(HEVC) >60% over MPEG-1
WebP2(≒AVIF) >15% over HEIC 姉妹規格のJPEG XSは来年完成らしい
ビジュアルロスレスというとDisplayPortのDSCコーデックみたいなやつだな
オープンフォーマットJPEG XS、画像符号化史上初のパラダイムシフト
https://this.kiji.is/361078960999941217/amp
JPEG XS標準化プロセスの開始は、2016年のJPEG 71回目の会合にて承認された。JPEG XSは、超低遅延、電力、帯域幅の要件だけでなく、実装が簡単なアルゴリズム、少ないメモリでも動作し、そして長いケーブルランをサポートすることを目的にしている。
コアコーディングシステムは2018年7月に完成予定で、リファレンスソフトウェアを含んだ全体の完成は、来年2019年4月に予定されている。 JPEG XSコーデックメモ
https://qiita.com/yohhoy/items/897a543cde9123e6e461
JPEG XSコーデックは、低計算量・低レイテンシが要求されるアプリケーションにおいて、主に「Mezzanine(舞台下の)コーデック」としての利用が期待されている。
ライブ・プロダクション
放送・デジタルシネマ ワークフロー
プロ向け映像市場
KVM1アプリケーション
VRゲーム など
JPEG XSは、従来の(無印)JPEG, JPEG2000, JPEG XR, WebP, HEIFといった大量データ保存・WEB配信向けコーデックを 置き換える技術ではない。 HDMI2.1もVESAが規格化したDSCを採用するみたいだな。もうDPと統一しろよ
https://av.watch.impress.co.jp/docs/series/dg/1100970.html
DSC(Display Stream Compression)はDPCM(Delta Pulse Code Modulation)とICH(Indexed Color History)をベースにしたリアルタイム性に優れた圧縮技術で、設定した圧縮率で安定した圧縮結果が得られる特徴を持つ。
ただし、圧縮したデータは元のデータには戻らない、いわゆるロッシーな(ある程度の劣化を許容した上で活用する)映像信号圧縮技術になる。
MPEG系のような、過去から現在の映像フレーム同士の相関関係を利用した圧縮技術は、元のデータに対して数百分の1にまで圧縮が可能だが、DSCは時間方向に伝送されててくる一次元データストリームの圧縮なのでたかだか数分の1程度の圧縮率に留まる。
その代わり、低遅延で高速リアルタイムに圧縮展開できる利点がある。
ちなみに、このDSCロジックのIPコアを開発したのは半導体IPメーカーのHardentだ。 jpegの牙城はH.264より堅いだろうから新画像コーデックを広めるのは厳しいだろうな…
MSとAppleとGoogleが足並み揃えてゴリ押ししたらいけるかも？って感じ ありゃJPEG XLの技術公募締切が9月に延期されてる
公開目標時期は2019年10月か
AV1採用してくれ >>604
そのメンバー全員Alliance for Open Mediaに加盟してるし、MozillaやFacebookやNetflixもいる。
Appleしか推してないHEIFやGoogleしか推してないWebP、Microsoftしか推してないJPEG-XR
とはかなり状況違うから今度は期待できそう。 VP9は画質で判断するとたまにH264よりサイズでかくなるから困る。圧縮するなら相応の力を見せてくれないと
中途半端だ >>603
HDMIがロッシーになるのか
マウスカーソルの周りにブロックノイズとか出たら嫌だな 8Kくらいまで解像度を上げない限りは非可逆にはならないと思うぞ >>608
そこまで圧縮しないから大丈夫だと思う
問題は低延滞だが延滞は有るというあたりと、表示機器側でデコーダ積まなきゃならないから、対応すると素で単価が上がる >>606
基本的にアプリケーションの内部処理やサービスとセットで消費者側はデコード主体使う事になるだろうから、個人で生成する事は余り考えなくて良いと思う たしかtwitterはgifをアップロードするとmp4(h.264)に変換される仕様だったような
google photoもwebpに変換されてるんだっけ？
全モダンブラウザが対応するweb標準の次世代画像規格さえできたら
あらゆるサイトでjpeg/png/gifが変換されるようになるはず
運営側もユーザー側もトラフィック削減パケット節約でwin-win AV1が一般人にストレスなく利用できるようになるのは、いつ頃だろうか？
音声の圧縮音声コーデックは、今後MPEG4-ALS（品質重視の用途）かOpus（可聴帯域のみを扱う一般的な用途とリアルタイム通話向き）に収束していくのだろうけど
ところで、音声コーデックの話をするスレ、どこかあるのかな？ ストレスなく利用っていうのが視聴の事なら1、2年で可能だろうけどエンコードの事なら一生来なさそう >>614
アカンがな、それ…
となると、やはり映像はHEVCベースで運用しておくか
音声はフリーのくせにと言ったらおこられそうだが、日常使いではOpusでいいかなと最近は思っている
新しくYouTubeにアップされてる高解像度のものは、元からOpusでエンコードされているから聴き取りやすくていいし
音声メインの素材をアップする人は、積極的に高解像度（フレームレートは1fpsとかにできるのならば、それでいい）でアップしてもらいたい >>612
AVIFはアルファチャンネルやアニメーションにも対応するそうだし、
AVIFに使用されてるAV1は可逆圧縮にも対応してるから、
うまく行けばjpg/png/gif全部置き換えられそう。 >>617
ソフトウェア板にあったのか
DTM板かと思ってたよ
Thx. >>615
Opus気になって調べてみた
で、YouTubeに4K動画でMISIAの音源にいいのがあったので試してみた
確かにいい
ただし、手元のPCで再生するよりスマホのXperiaで再生したほうが高音質だった（泣
PCの音声環境見直すか・・・ >>619
それわかるw
Opusをもっと試したかったらサカナクションの「多分、風」という曲もOpusの入ってるファイルで聴くといいと思う >>616
可逆圧縮をなめてはいけない。
可逆画像圧縮のアルゴリズムをを不可逆画像圧縮から流用するアプローチが
いくつかあるけど、普通にPNGより性能悪い。
WebPは可逆不可逆両対応だけど、それぞれ別のアルゴリズムを使ってる。
可逆か不可逆かぱっと見で区別できないのも困るし、今までどおり別の型式のがいいと思う。
可逆画像圧縮はzstdのアルゴリズムベースのが出てきてくれたら嬉しいけどなぁ。 お前ら可逆不可逆って続けて何回言える？
俺は1回すら怪しいんだけど >>619
YouTube動画の音声サンプリング周波数は
AACが41.1kHzでOpusは48kHzだったような
だから例えばiPhoneシリーズなら6s以降スピーカーが48kHzしか対応していないらしいからAACだと多少音質変化するかも
逆に44.1kHzのみ対応のイヤホンとかもあったり
なんか深淵を覗いた心地に >>621
そういやFLIFとかいうFLACの親戚みたいな名前の可逆圧縮画像規格あったけど最近は音沙汰無しだな
いつかリリースされる日は来るのだろうか 最近は写真や動画を撮ったらすぐにクラウドストレージに投げることが増えてきたから
元ファイルを(ビジュアル)ロスレス圧縮してアップロードした後、クラウド上で再エンコードする時代になったりしないかな
ロスレスHEVCかロスレスAV1かVESAのDSCかどれでもいいけど FLACをアップロードできてOpusがストリーミング配信されているSoundCloudはすごいな
無料だし >>627
SoundCloud、これいいね！
スマホにアプリ入れてGoogleのアカウントでサインインしてみたけど、操作が少し独特だけどいいよこれ
日本人の曲もあるし、音も素材が良ければいい感じだね
これはいいの教えてもらったよ
ありがとう！ >>629
WebP可逆は不可逆とは別のアルゴリズムだから殆どの画像でPNGより縮む
BPGの可逆圧縮を調べてみたけどやっぱり微妙だった
PNGが苦手な画像だとPNGより縮んだり縮まなかったり
PNGが得意な画像だとPNGに引き離される
AV1の可逆圧縮も似たようなもんになる気がする。 PNGは最適化を掛けるとかなり縮むけど、
マルチスレッドすら対応してない古いプログラムばかりで遅いのがな
その辺をちゃんと最適化してくれればPNGで十分そうな気がする とりあえずWindows 10の最新アップデートを適用すると、HEIFの表示のみOS標準で対応だとさ
※保存はダメ 結局OSの対応よりブラウザの対応のほうが大切なんだよね >>630
BPGの可逆圧縮はエンコーダーにx265を使うと縮まないけどjctvcなら結構縮む
jctvcは0.9.6以降は搭載されてないから試すなら0.9.5を使ってね AV1の可逆圧縮、相当無理矢理だけどこんな感じで出来た
ffmpeg -y -i "%~1" -filter_complex "extractplanes=r+g+b[r][g][b],[r][g][b]mergeplanes=0x001020:yuv444p" -strict -1 -f yuv4mpegpipe - | aomenc.exe --passes=1 --i444 --lossless=1 -o "%~dpn1_av1_lossless.webm" -
ffmpeg -y -i "%~dpn1_av1_lossless.webm" -filter_complex "extractplanes=y+u+v[r][g][b],[g][b][r]mergeplanes=0x001020:gbrp" "%~dpn1_av1_lossless.png" >>635
AV1可逆の圧縮性能はPNGに比べてどうだった？ >>634
jctvcを使ったら可逆ですげー縮んだ。勉強不足すぎてた。
これだと大方の画像ではPNGより小さくなりそう。
ただ、PNGが得意な画像で、差は縮まれど追いつけないままな物もまだあるから
PNGを全部置き換えるにはまだ不足してるって感想はそのままかな。
（一番手ごろなものだと、wikipediaのページのスクショ画像がそうなった） deflateという圧縮技術のデファクトスタンダードを使っているpngが置き換わることはそうそう無いと思うけどね >>636
ほい、調べた
AV1はかなり変なやり方で変換しているので効率が悪くなっている可能性もある
画像はpixivデイリーランキングから100枚
pngと比べて何パーセント縮んだか
BPG x265 4.23%
AV1 12.3%
webp 24.16%
BPG jctvc 26.72%
FLIF 31.45%
平均処理時間
BPG x265 1.449秒
PNG 2.439秒
webp 3.353秒
FLIF 7.301秒
BPG jctvc 13.9324秒
AV1 93.8216秒
ベンチマークに使用したbatも上げておくので設定とか検証が適切に行われたかが気になる人は見て
https://www.dropbox.com/s/kc7njid1gz12vs0/lossless_bench.zip?dl=0 >>639
ありがとー
AV1縮んでないね、可逆だとwebpに劣るなんて
得意な？非可逆だとどうなるんだろ >>5の情報更新
●JVETで検討が進められていた、HEVCの後継コーデックは、FVCではなく
VVC （Versatile Video Coding）
という名前になった模様。
●先月のMPEGミーティングで報告された、360度ビデオやHDRも含めた主観評価のテスト結果では
HEVC比で40%以上の改善が見られ、特にUHDで効果があった。
●参考リンク
Beyond HEVC: Versatile Video Coding project starts strongly in Joint Video Experts Team
http://news.itu.int/versatile-video-coding-project-starts-strongly/
MPEG 122 - San Diego | MPEG
https://mpeg.chiariglione.org/meetings/122
MPEG 122 Meeting Report - Bitmovin
https://bitmovin.com/mpeg-122-meeting-report/ >>639
AV1本当何やってもトロくて駄目なやつだな…
ここまで糞だと改善の見込みも無さそう
AV1を今より遥かに速く改善できるなら他のコーデックなら更に改善できるだろ それが出来ないからVVC等の新しいコーデックが開発されてるんだろ Googleが画像フォーマット「WebP」向けライブラリ「libwebp 1.0.0」をリリース
https://mag.osdn.jp/18/05/02/163000
WebPはWeb向けの画像フォーマットで、ロスレスおよび不可逆圧縮の両方に対応する。
拡張子は「.webp」。不可逆圧縮では、VP8動画コーデックが動画のキーフレームを圧縮するのと同じ手法で、プレディクティブ（予測）コーディングを使って画像をエンコードする。
ロスレス圧縮ではPNGと比較して26％小さく、不可逆圧縮ではJPEGより25〜34％小さいとしている。
WebPファイルはVP8とVP8L画像データ、RIFFベースのコンテナで構成される。
libwebpではWebP仕様のリファレンス実装で軽量のエンコード/デコードライブラリに加え、WebPフォーマットへの変換などを行えるコマンドラインツールcwebp/dwebp、WebPイメージの閲覧やmux、アニメーション作成のためのツールを備える。
本バージョンはこれまでのバージョンとバイナリ互換があるとのことで、フォーマットとAPIが安定していることから1.0として公開したという。不可逆圧縮などが強化されツールもアップデートされている。 >>650
ブラウザ識別して火狐には重いデータを送ってやろう ChromeがAPNG対応したんだから
FirefoxはWebP対応するのが🍣 firefoxはwebp対応してるだろ
safariと勘違いしてるのか？ >>655
新4K8K衛星放送開始に向けた取り組み - 総務省（PDF）
http://www.soumu.go.jp/main_content/000533786.pdf
https://i.imgur.com/vmMBLzQ.png
新4K8KはH.265だね
H.265が特許料で揉めてるって最近知ったからあまり詳しくないんだけど
特許料の高さがBS契約料とかNHK受信料とかに（無駄に）上乗せされないといいんだがなぁ
かと言って機動力のない放送団体が状況に応じてコーデック入れ替えなんかできるとも思えないし >>656
対応profileのオプションにもよるけど、TV1台当たりライセンス料300円しないぞ 今年の2月に特許切れたMPEG2にもライセンス料掛かってたしな
録画の圧縮機能やMPEG4/AVCの再生機能持ってる機器なら、未だにMPEG4/AVCのライセンス料も掛かってるし
今まで金銭的にそれらの上乗せを負担と意識して無かった奴が、今更HEVCのライセンス料で騒いでるのも可笑しいんだけどね
実効でその程度のものだったり 映像コンテンツなら殆ど2円未満、高くても3円にもならないとかだし、
パッケージの流通コストや小売り・事業者の粗利の方が遙かに影響デカくて、個人単位で年間ナンボよって感じなのよね
そんな額気にするなら、家電品の消費電力気にしていた方がマシだったりな
自販機で飲料買ったり、コンビニで買い物する方が遙かに無駄という GIMPは亀の歩みだし……
対応してくれただけでも喜ぶべき 昔はPhotoshopの代わりにGIMPでも頑張れば行けるかもって時期があったけど、
今は完全に突き放されて背中すら見えなくなってしまったなあ GIMPはリリース間隔が空きすぎて開発者のほとんどがKritaとかDarktableに行っちゃったから… GIMPの前回のリリースって5年以上前だろう
webpその頃あったのかな androidのゲームでwebp義務化すればかなり通信料減らせそう 結局webpが流行ることは無かったな
コーデックもVP8のままだし よくわからんけどAndroidのゲームはETC1かETC2が主流じゃないの？
多分DXT同様固定の容量圧縮比の方がメモリ消費量の把握しやすいだろうし >>670
JPEGから移行するにはショボすぎた
HEIFでやっとって感じ 流石にJPEGも古い規格よなぁ
圧縮率の高い次世代フォーマットでどれだけのストレージやリソースが削減できるか
実際は皆足並みが揃わない訳だけども
ストレージの進化が完全に頭打ち！大変だ！みたいなピンチにでもならなきゃ業界は腰を上げないよな ストレージは大した問題ではないだろう
問題なのは通信量よ その他にも処理速度とかそれをハードウェア処理するチップのコストだとかいろいろあるんだろうけど
ぶっちゃけいえばブラウザやOSが標準でサポートするか否かが一番でかいと思う
ってJPEG2000さんが草葉の陰でいってた 近いうちにJPEG2000が主流になるからデジカメの買い替えをちょっと待とう…
とか思っていた遠い日の記憶が蘇ったw もうJPEGくらいに浸透してると
AppleみたいにHEIFをデフォルトで初心者に気づかせないうちに使わせて
広めるみたいなことしないと無理だろう amazonとかの電子書籍を全てwebpにすれば普及する AV1ってまだ正式に仕様決まってないの？
doom9見てたらそういう感じの話してるような気がするけど機械翻訳で読んでるからよく分からない
https://forum.doom9.org/showthread.php?t=172550&;page=34 >>679
まだみたいだね。
https://github.com/AOMediaCodec/av1-spec
で作ってる仕様ドキュメントから“draft”が無くなった時が仕様確定かな。
参考： Jan Ozer氏が4月中旬にAOMediaの人から聞いた話
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=124455&;fb_comment_id=2018670391537585_2021817181222906#f16f50065d9c3e4
雑訳：
AOMでは「code first」というアプローチでAV1の開発を行っている。
リファレンス実装のコードの開発と、それによってもたらされるビットストリーム仕様の策定・作成は並行して行われている。
これらが終わって初めてAV1の仕様が確定したと言える。
仕様書は現在は「draft」とされており、リファレンス実装のビットストリームが正確に反映されるよう、
自動/手動でレビューを実施しているところであり、その作業には更に数週間かかるものと思われる。
それが終わった時点で「draft」のウォーターマークを外し、AV1の仕様が確定する。
>>678
それだけじゃ絶対普及しない
リーダーはAmazonとかの電子書籍配布元が配布するとして
画像生成する機器やアプリケーションが標準でほぼ全対応しなきゃ
出版する側の人間がwebpへの変換ツールを使うだけに終わる
カメラなどのハードウェアが直接次世代フォーマットで
画像生成するようになって初めて普及する可能性が出てくる
その点、デフォルトでiPhoneでHEIFを吐き出させ始めたAppleが
一歩リードしてる >>680
サンクス
どうりでChromeがなかなか対応しないわけだ chromeもfirefoxもAV1の一時的なな実装は完了しているから仕様確定したらすぐにでも導入できるはず
まあ安定版に降りてくるには半年近くかかるのだろうけど つべのVP9と264
容量が逆転してるのが多いな…
細かい動きが多いとダメなんかな？ VP9はHEVCとAVCの中間あたりに位置すると個人的には考えてるから、得手不得手で旨味なくなりがちだよね HEVCの技術とAV1の技術を全て結集したらさいきょうのコーデックが出来上がりそう（厨二的発想）
まぁ大人の事情でまず有り得ないけど >>688
大人の事情とか言ってる時点で…
ただエンコーダ・デコーダが優秀になればいいだけの話。特性云々はここで語る必要ないと思うが VP系はMPEG系と比べて先読み短くても圧縮率保てるからストリーミングにはVP9のほうがいいよ 自炊用途は、長期的に安定して再生できる可能性の高いフォーマットを選ばないとあとで後悔するだけ
ただ、一つ気がかりなことがあるとすれば、動画ファイルに使える音声フォーマットの進展が遅れ気味なことか
特にOpusのようなVBRタイプのフォーマットを動画とMUXしたいとかなると、とたんに使えるツールが見当たらなくなる現状は如何ともし難い
動画と音声を自由自在にMUXできる自由度の高いツールがほしい mkvコンテナ扱える奴なら仮対応的な実装じゃ無ければイケるんじゃないの？ 電子書籍とかの複数ファイル画像って
動画にしてフレーム間圧縮で容量減らせそうだけど
やってるとこないのかな ■ このスレッドは過去ログ倉庫に格納されています
