次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:23:41.40

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が宣言してから立ててください。

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:25:10.61

■各コーデックの参考リンク

●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

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:26:03.03

■各ビデオコーデックの概要や状況（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で採用されている。

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:27:01.29

●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/

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:27:49.39

■各ブラウザのコーデックサポート状況

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:28:41.48

■各社GPUでのハードウェアエンコード/デコードの参考リンク

●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

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:29:54.84

■各社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
　　未対応

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:33:31.04

■AV1のエンコーダ/デコーダ実装の例

●エンコーダ
　xiph/rav1e: The fastest and safest AV1 encoder.
　https://github.com/xiph/rav1e

●デコーダ
　VideoLAN / dav1d - GitLab
　https://code.videolan.org/videolan/dav1d

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:45:22.06

↑一応テンプレここまで。

テンプレの変更点は以下の通り。
　・各コーデックの参考リンクを>>2に移動
　・諸々の状況を2019年1月下旬時点にあわせて更新
　　　・VVCの説明にMC-IFのことを追記
　　　・HWエンコーダの説明で、SDKのバージョンを更新
　　　・HWエンコーダの説明で、TuringでのHEVC Bフレームサポートを追記
　・>>8にAV1のエンコーダ/デコーダ実装を追加

Youtubeの一部の動画でAV1がテスト採用されてるといったことも書いた方が良かった気もするし
他に書くべきこともあったかもしれないけど、スレ立てを急いだほうがよさそうだったのであまり変えてない。

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:46:55.39

即落ち防止に>>20まで保守

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:47:44.03

保守

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:48:34.22

ほしゅ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:49:27.68

ホシュ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:50:56.24

保守

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:52:01.83

ほしゅ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:53:27.80

ホシュ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 16:54:45.09

保守

2019/01/30(水) 16:59:14.89

イチモツ！

2019/01/30(水) 16:59:52.20

AV1 Video Extension (Beta) for Windows 10
https://www.microsoft.com/ja-jp/p/av1-video-extension-beta/9mvzqvxjbq9v

YouTube TestTube
https://www.youtube.com/testtube

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 17:00:23.12

(｀･ω･´)ゞ

**名無しさん＠編集中** (ﾜｯﾁｮｲ e1e7-uJAn) · 2019/01/30(水) 17:29:17.91

「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）

**名無しさん＠編集中** (ﾜｯﾁｮｲ 412c-ldh1) · 2019/01/30(水) 22:11:06.43

誰もMac mini 2018のHEVCエンコードのレポートしてくれないな
俺がやるしかないのか

2019/01/31(木) 01:48:45.71

あ、持ってるよ。低ビットレートだとやっぱx265のがずっと綺麗です。1080p60時に20Mbpsとか大盤振る舞いをするなら大して変わらないから便利です

例えばPS4のゲームをHDMI経由でキャプチャーしてソース動画がある場合なんかはx265で重めのプリセットで10Mbpsくらいでエンコしても劣化が目立つのでどのみち20Mbps程度は必須。このビットレート領域だとAppleのも悪くはないです

2019/01/31(木) 01:52:18.29

ちなみにFFmpegでもCompressorでも出来ることは殆ど一緒でカスタマイズ項目は少ない。2パスエンコは不可能

2019/01/31(木) 03:06:04.71

量子化係数のより高い状態でのエンコードで、如何に画質の劣化を軽減するか
それを如何に効率よく処理するかがエンコーダ性能の優劣だからな
高ビットレートを容認すればするほど前者が問われ無くなるから、そりゃ差は縮むわな

2019/01/31(木) 16:28:21.64

まー1080p60で10MbpsでもSSIM 0.01違いとかそんなもんです
Compressorから圧縮するとちゃんとBフレームも使う
13500フレームの動画でx265だとBフレームが9900程度、T2だと9500程度になった
リアルタイムエンコーダーとしてはそこそこ優秀だと思いますよ

2019/01/31(木) 16:41:57.91

フィルムグレイン多い実写だとx265でもダメダメだなあ
エンコ時間かかりまくるのに全然縮まない
アニメ専用かよ

2019/01/31(木) 16:54:38.71

グレインって再生時に追加するものだと思ってた

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5f2d-vS77) · 2019/01/31(木) 18:08:12.91

グレインとかCMOSの暗部ノイズはランダムノイズなので動き補償と相性悪すぎるからしょうがない
砂嵐をエンコードしてるようなもん

2019/02/01(金) 00:05:35.11

デジタルシネマは圧縮電送して、シネコン側で指定されたフイルムグレイン(KODAK何番とか)足して再生すると、何かで読んだけど

確かに圧縮効率を考えたら、ある程度フィルターでグレイン取って圧縮して、再生で足すのは考え方としてはアリか

**名無しさん＠編集中** (ｽﾌﾟﾌﾟ Sd9f-Wh9i) · 2019/02/01(金) 03:44:31.20

「8K」の普及促進や規格化を担う団体「8K Association」が発足。
ttps://www.4gamer.net/games/999/G999902/20190130060/

Chinock氏は，8Kエコシステムを回す追い風として，「HDMIやDisplayPortなどの映像インタフェースは，8Kへの対応が完了していること」と，
「同品質の映像を，H.265の半分のビットレートで圧縮可能な次世代コーデック『H.266』の開発が進行中であること」などを挙げていた。

2019/02/01(金) 09:18:33.02

>>30
シーンごとカットごとでの指定はできるんかね？

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/01(金) 15:58:01.11

AV1には「Film grain synthesis」って機能があるみたいだね。
「デノイズしてエンコードした映像」と「モデル化されたグレイン情報」に分けておいて、デコーダー側で合成するらしい。

　https://en.wikipedia.org/wiki/AV1#Filters
　https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/

2019/02/01(金) 16:12:11.59

映画制作側は「俺の創った映像と違う」とか言って拒みそうな機能だな
24p→60pも否定的だったし

2019/02/02(土) 02:07:06.05

Vorbis , Theora
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

2019/02/02(土) 02:12:10.37

>>34
トム・クルーズが「勝手にコマ数増やすな」と、テレビやと視聴者に文句言ってるのなw

2019/02/02(土) 02:14:35.64

>>32
メタデータで指定してるんじゃないかな

>>33
あ、AV1か
ありがとう

2019/02/02(土) 02:20:23.33

>>35
デバイス製造元からの HEVC ビデオ拡張機能
https://www.microsoft.com/ja-jp/store/p/hevc-video-extension/9n4wgh0z6vhq
ハードウェアデコーダ用HEVC（無料）

2019/02/02(土) 02:25:26.82

>>38
インストールさえできればHW非対応の構成でも再生できるんだよなぁ

2019/02/02(土) 09:14:23.45

コーデックもそうだけど、動画まわりのAPIもどうにかしてほしい。もっと洗練されたクロスプラットホームなやつを..

2019/02/02(土) 09:20:32.11

windowsにしたって>>35は古いDirect ShowフィルタじゃなくてMedia Foundation用のコーデックだろ。MS純正のアプリはMedia Foundationに移行してると思うが、サードパーティーでMedia Foundation使ってるるプレイヤーってそんなにあるのか?

2019/02/02(土) 10:20:10.48

>>41
MS純正のアプリ使わないならLAV Filtersで事足りるからなあ・・・
MediaFoundationを意識するプレーヤーなんてQonohaくらいしか知らん・・・

2019/02/02(土) 14:10:34.69

動画APIがクロスプラットホームである必然性なんて微塵もない
何をやってもHDTVとPCのガンマを同一と見做して変換してくれない糞プレイヤーが多いままなのは永久に変わらない

2019/02/02(土) 14:44:40.78

動画がらみのAPIがクロスプラットフォームじゃなかったら、ffmpegがanroidかwindowsかどちらかでしか動かないくなるんだけど。
vlcやらも大変。
ffmpegのlibavやらlibavformatやらがクロスプラットだから、後はUIのがわをだけ作ればいいように楽できるんだけど。
libavとかカオスだし、gstreamerはまだましっぽいけど。

2019/02/02(土) 16:53:26.63

Direct Showは、いずれ廃止になるんだから、さっさと移行しろよとは思うが、動画の世界は古い技術にしがみつきたがるやつが少なからずいるのが癌ではある

2019/02/02(土) 17:45:38.98

AV1拡張入れてもWin10のWMPでAV1動画が再生できなかったからMFとはまた別かと思ってた

2019/02/02(土) 18:07:44.87

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は後者を使ってるのかな？

2019/02/02(土) 19:58:30.95

>>46
今は拡張でAV1をWMPで再生出来るよ

2019/02/03(日) 18:57:43.50

宮廷ドラマ「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!

2019/02/03(日) 19:41:54.96

こういう利権とかうるさいのって日本だけかと思ってたけど、やっぱ世界でも似たようなもんなんだなって思う

2019/02/03(日) 19:48:22.00

利権じゃなくて権利でしょ

2019/02/03(日) 19:54:37.87

すまぬ、普通にミスった

2019/02/03(日) 22:08:33.63

Intel Publishes Open-Source AV1 Video Encoder "SVT-AV1"
https://www.phoronix.com/scan.php?page=news_item&;px=Intel-Open-Source-SVT-AV1
https://github.com/OpenVisualCloud/SVT-AV1

2019/02/04(月) 00:33:40.50

ライブ配信向けのエンコーダか
1080pで最低16GB必要とはなかなか重いね

**名無しさん＠編集中** (JPWW 0H03-CVwB) · 2019/02/04(月) 02:21:19.78

AVIFはどうなってるのかな
なんかwebpより画質悪いみたいだけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7ff7-O2h2) · 2019/02/04(月) 09:28:21.48

>>55
webpより画質悪いってどこの情報？

2019/02/04(月) 10:42:54.67

画質を気にするならJPEG 2000にしとけば？
HEIFもだけど動画のイントラ系は高画質寄りだとあまりメリットない

2019/02/04(月) 14:00:27.36

HEIFって4:4:4無いの?あるなら互換性を除けば非可逆で最もベターに思えるけど

2019/02/04(月) 18:10:16.48

画質保ちたいならpng使うもんな
ほとんどの人はそれなりの画質で高圧縮を求めている

2019/02/04(月) 18:13:52.22

J2Kボケボケやん

2019/02/04(月) 20:49:39.69

>>55
VP8ベースのwebpよりVP9後継のAV1使ったAVIFが画質悪いの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfb0-kU5+) · 2019/02/04(月) 20:57:35.55

>>58
iOSで4:4:4 HEIFで保存するサードパーティアプリあるので、出来るといえば出来る
OSデフォルトのカメラは4:2:0だけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfb0-kU5+) · 2019/02/04(月) 21:01:20.04

何よりもクソなのはmacOS MojaveだとHEIF Losslessが追加されたのに実際は何かロスる。
たぶん4:2:0に変換された物がロスレスでコーディングされてるw

2019/02/04(月) 21:23:33.84

4:4:4でもYUVだとロスりそうな気が
ロスレスならGBRでしょ

**名無しさん＠編集中** (ﾜｯﾁｮｲ df01-vS77) · 2019/02/04(月) 21:56:36.06

>>64
10bit12bit使えるはずなのでそれら使えばロスらない
でもこの辺ちゃんと対応してるのかね

2019/02/04(月) 22:22:30.61

>>62
そのアプリ名おせーて

2019/02/04(月) 23:50:25.37

>>66
デュアルレンズiPhone専用で高額レンズのシミュレーションを行うFocosっていうアプリ
この手のアプリでは圧倒的なクオリティで専用ハードを使うLight L16より綺麗

2019/02/04(月) 23:57:07.24

>>65
ロスレスで深度深くしたらRGBのままより圧縮効率落ちる。つまり、ただのzip圧縮と変わらないPNGに負ける

ロスレス最高効率のFLIFは8bit深度のままロスレスYCoCg変換しててこれが正解。HEVCだってYCoCgに対応してるのにやらない所がクソなんですよ

2019/02/05(火) 00:00:31.06

まだ言ってんのかよ

2019/02/05(火) 00:12:50.73

>>63
422から420って、色の2が0にロスってるけどw
それロスレスって言っていいのか

2019/02/05(火) 00:16:21.96

>>68
なるほどぉー
これは勉強になった
RGBよりdeep色向けな最適化軸が
YCoCgなのかな？
ぐぐって勉強してみよう

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/05(火) 21:39:18.83

>>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」。

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/05(火) 21:40:34.38

>>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

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/05(火) 21:43:47.70

>>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限定なら有用かもしれない。

（続く）

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/05(火) 21:44:40.11

>>68
（続き）

　　・じゃあ可逆性を重視して「10bitのYCoCg」を使うぜ！

　　　　　→でも8bitRGBをエンコするために10bitYCoCgを使っても
　　　　　　圧縮効率の向上はあまり期待できないらしい？
　　　　　→「8bitのRGB」をそのままエンコードした方が圧縮効率が良いのでは？
　　　　　→「10bitのYCbCr」も8bitRGBと可逆性があるはずだし、そっちでもいいのでは？
　　　　　→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
　　　　　→4:4:4限定なら有用かもしれない。

という感じで、現状実用できる範囲ではあまりメリットが無さそうな感じ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/05(火) 21:46:56.32

>>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について調べたことをまとめて連投してみたのだけど、
理解が正しいかよくわからんとこもあるので、指摘があればよろしくたのんます。

2019/02/05(火) 22:34:47.41

他所でやれ

**名無しさん＠編集中** (ﾜｯﾁｮｲ df52-S1Ul) · 2019/02/05(火) 22:47:19.89

いま他所でやるスレあるの？
立てるしかない感じ？

2019/02/05(火) 22:48:50.52

DTVなんでも雑談スレが必要やな

2019/02/05(火) 23:42:04.96

いいよ。ここでやればいい。興味なければスルーするだけだし。

2019/02/06(水) 03:03:43.65

libvpxアップデート来てるやん
エンコードが速くなったらしい
テストはしてないけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/06(水) 19:52:42.18

>>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"

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7fd2-O2h2) · 2019/02/06(水) 19:55:49.59

--auto-alt-ref=0が無効で1が有効だと思っていた。
6ってどういう意味だろう？

**名無しさん＠編集中** (ﾜｯﾁｮｲ dfe7-S1Ul) · 2019/02/06(水) 21:53:37.56

>>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;

**名無しさん＠編集中** (ﾜｯﾁｮｲ 46e3-ZFeD) · 2019/02/07(木) 22:13:08.59

WEBPでPNGをロスレス変換したときのファイルサイズの減少率に感動して
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…

たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな

2019/02/07(木) 23:26:22.97

他人エンコならAAC128でも気にしないけど自分エンコの320とWAVは異様に気になって識別しちゃうみたいな所あるよね。
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする

**名無しさん＠編集中** (ﾌﾞｰｲﾓ MMcd-JPGI) · 2019/02/07(木) 23:42:57.87

>>85
WebPのロスレス、実はロスレスじゃないという話があるけどどうなんだろう

**名無しさん＠編集中** (ﾜｯﾁｮｲ 02e3-ZFeD) · 2019/02/08(金) 01:02:09.44

>>87
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー

と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年～2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う

**名無しさん＠編集中** (ﾜｯﾁｮｲ cdb2-FtKs) · 2019/02/08(金) 10:35:48.98

こっちのirfanviewとXnViewではちゃんとロスレスだった

88 (ﾜｯﾁｮｲ 02e3-ZFeD) · 2019/02/08(金) 12:31:27.20

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設定のまま保存されていたようだ

**名無しさん＠編集中** (JPWW 0Hcd-kcXV) · 2019/02/08(金) 14:10:24.35

windowsの仕業だったのか
Macだとどうなるんだろ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8216-OF6d) · 2019/02/08(金) 15:46:20.12

なぜに管理者・・と思ったけど
圧縮率の情報をレジストリにでも書き込む仕様なんだろうか？

88 (ﾜｯﾁｮｲ 86e3-ZFeD) · 2019/02/08(金) 17:55:01.22

GIMPでHEIF/HEIC保存できるのを知って>>90の16777216色画像でlossless変換してみたけど
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな

ファイルサイズもWEBPの181kB->12.7kBに対して12MBまで膨れ上がってたし
少なくとも現時点のバージョンでlossless厨の自分がHEIF/HEICのお世話になることはなさそうだ

このスレ見といて本当によかった詳しい人ありがとうございます

数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな

2019/02/08(金) 18:21:05.40

それほど大量にPNGを扱っているなら場合によってはBMPにして7zとかzpaqなどのアーカイブに放り込む方が縮むかもしれない
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな…

**名無しさん＠編集中** (ﾜｯﾁｮｲ a12c-U9Au) · 2019/02/08(金) 19:22:01.90

最新のAcrobat Pro DCでHEIC開けなかったわ
PDFってまだHEIF埋め込める仕様になってないん?(´･ω･`)

2019/02/08(金) 22:12:26.58

pngcrushで事足りてるな...
(もっと効率良いPNG再圧縮プログラムもあるけど、デフォルトでメタデータが保持されない物が多いのでpngcrushが安全

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8de7-OF6d) · 2019/02/09(土) 01:14:35.57

MicrosoftのHEIF画像拡張機能を入れてテストしてみようとしたら
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀)

2019/02/09(土) 01:54:14.48

PNG最適化ならzopflipngが今のところ一番縮むはず

2019/02/09(土) 07:21:06.37

zopflipngのコマンドラインは残すチャンクを手動指定しないとメタデータを軒並み消される

2019/02/09(土) 07:25:25.95

メタデータまで含め非破壊で安全である事と、速度と圧縮効率のバランスの良さでpngcrushの標準(-bruteとか指定しないで普通に使う)は使い勝手が良い

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/09(土) 12:01:23.04

HEIF画像拡張機能、なんかインストールできねえなと思ったら
　　Windows 10 バージョン 17763.0 以降（October 2018 Update～）
になっとるやないかい・・・。まだApril 2018なままのうちでは無理か・・・去年さっさといれとけばよかった。

2019/02/09(土) 12:33:43.35

>>98
ECTやpingoのほうが縮むぞ
圧縮速度も何倍も速いしメタデータも残る

**名無しさん＠編集中** (ﾜｯﾁｮｲ 86e3-ZFeD) · 2019/02/09(土) 14:05:05.01

> converted through FFmpeg v3.4.1’s use of the open source x265 HEVC encoder (MulticoreWare Inc., 2018) to a mathematically lossless bitstream with the following command:
>
> > ffmpeg -i reference.tif -preset veryslow -c:v libx265 \
> > -x265-params lossless=1 lossless_bitstream.265
>
> The x265 encoder’s lossless option disables rate control along with all quality metrics and bypasses both discrete cosine transforms (DCT) and quantization (MulticoreWare Inc., 2014). Additionally,
> it employs HEVC’s RExt Main 4:4:4 profile, Level-8.5 (Main tier).
https://journal.code4lib.org/articles/13746

https://pwiki.awm.jp/~yoya/?2018-01-25/HEIFでYUV444なら劣化しないみたいなこと書いてあったからぐぐってみたんだけど
たぶんオープンソースのFFmpegでRExt Main 4:4:4 profile, Level-8.5でlossless圧縮したら数学上で損失のない信号情報に変換されたよ～
って書いてあると思うんだけど、YUV444ならlossless変換でも色情報間引かれたりしないんだろうか

**名無しさん＠編集中** (ﾜｯﾁｮｲ 46e3-ZFeD) · 2019/02/09(土) 16:33:15.07

>>103やってみたけどサイズがPNGより膨らむ上にirfanviewでも開けないしよくわかんないっすね…
jpeg2000より圧縮率高かったら置き換えられるかなと思ってたけど厳しそう

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/09(土) 19:50:32.09

>>103
> https://pwiki.awm.jp/~yoya/?2018-01-25/HEIFでYUV444なら劣化しないみたいなこと書いてあった

　> ・ロスレス(劣化しない圧縮)と透明度に対応してるので PNG の代わりになり得る。
>　　　ただし、YUV444 対応しないと RGB=>YUV変換で微妙に劣化する

これは、もうちょっと細かく書くと、

　・ロスレス(劣化しない圧縮)と透明度に対応してるので PNG の代わりになり得る。

　　　・ただし、8bitRGBをロスレス保存するには、
　　　　　　　　・Main4:4:4で8bitRGBを、「フルレンジ」「4:4:4」「--colormatrix gbr」で保存。
　　　　　　　　・fullrangeフラグやcolormatrixを見て適切な色変換を行う。
　　　　　　　　・Main4:4:4は、heixブランドなのでその対応が必要。
　　　　　という条件を満たす必要がある。

　　　　・でも現時点での実装のほとんどは、heicブランド（MainおよびMain Still Pictureのみ）にしか対応していない。
　　　　　これは8bitYUV4:2:0限定なので、8bitRGBをロスレス保存することはできない。

という感じだと思う。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/09(土) 21:44:49.69

■iPhoneのHEIFサンプル

　・形式
　　　プロファイル：　　　　　Main Still Picture(8bit YUV4:2:0)
　　　YUVレンジ：　　　　　　フル
　　　　fullrangeフラグ付与：あり
　　　RGB->YUV変換係数：　　　不明
　　　　colormatrix付与：　　無し
　　　備考：
　　　　・画像は48枚の512x512のタイルに分割されて格納されており、
　　　　　そのタイルを横8枚、縦6枚で並べた4096x3072の絵を
　　　　　更にクロップして4032x3024にして1枚の画像を構成する仕組み。
　　　　・320x240のサムネイルと、Exif情報もあり。

■NOKIAのHEIFサンプル

　・形式
　　　プロファイル：　　　　　Main(8bit YUV4:2:0)
　　　YUVレンジ：　　　　　　リミテッド
　　　　fullrangeフラグ付与：なし
　　　RGB->YUV変換係数：　　　不明
　　　　colormatrix付与：　　無し

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/09(土) 21:45:56.53

■GIMP v2.10.8のHEIF対応状況

　・対応しているのはheicブランド(MainまたはMain Still Picture)のみ。
　　Main4:4:4やMain10等はheixブランドなので非対応。

　・書き出し
　　　プロファイル：　　　　　Main (8bit YUV4:2:0)
　　　YUVレンジ：　　　　　　フル
　　　　fullrangeフラグ付与：無し　←★酷い
　　　RGB->YUV変換係数：　　　BT.601
　　　　colormatrix付与：　　無し

　・読み出し
　　　問答無用でフルレンジBT.601だとして変換する。　←★酷い
　　　　fullrangeフラグ読み取り：　無し
　　　　colormatrix読み取り：　　　無し

　・備考
　　　・アルファチャンネルにも対応している。
　　　・NOKIAのHEIFサンプルはリミテッドレンジなので、
　　　　GIMPで読み込むとコントラストが低下した状態で読み込まれてしまう。
　
　
どいつもこいつもcolormatrixつけやしねえ・・・
デフォはBT.601として扱えとでも言うのだろうか・・・

2019/02/09(土) 21:47:59.23

画像系のソフトって色域の管理できてないのが多いからねぇ
というか、そもそも色域管理の術を知らないんじゃないのかとさえ思う

2019/02/09(土) 21:54:40.43

率直な質問だけどHEIXなHEIFって拡張子は.heixになるの？それとも.heif？

2019/02/10(日) 00:05:13.79

次世代ビデオコーデックのスレで画像コーデックの話何時までやるの？
話題ついでレベルなら全然かまわんと思うけど
ゴリゴリ続けられてもちょっとな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 49e6-OF6d) · 2019/02/10(日) 00:07:20.73

次世代画像コーデックスレが必要になってきた感じですかね

**名無しさん＠編集中** (ﾜｯﾁｮｲ 46e3-ZFeD) · 2019/02/10(日) 00:19:13.56

HEIFやWEBPみたいに静止画と動画の変換コーデックに同じものが使われる傾向が続くと
将来的には「昔は静止画専用のコーデックがあってさ～」みたいな話になるんだろうか

2019/02/10(日) 00:19:54.07

どんどん続けてOK。俺はどうでもいいかスルーするけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/10(日) 00:46:56.11

>>109
.heic

　HEIF Technical Information - High Efficiency Image File Format
　https://nokiatech.github.io/heif/technical.html

2019/02/10(日) 00:52:48.44

>>114
heixでも.heicなのか
サンクス

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9177-DOJB) · 2019/02/10(日) 01:22:36.25

低スペックマシン(Windows10/AMD E1-7010 APU/RAM4.0GB)でYouTubeを720p/AV1設定にして視聴したんだが感動を覚えた。
Dropped Frames 683/5960 11.5%位落ちてるけれどこんな低スペックPCでchromeブラウザのAV1デコーダー凄い軽さだなぁと。

2019/02/10(日) 02:25:30.99

11.5%も落ちてたらダメだろ

2019/02/10(日) 02:47:17.59

>>118のCPUってcine bench15 マルチコアで70しか出ないのかよ…ちなみに9900Kが2000ちょい
仮にスコア100でフルフレーム出るとすると4コアCPUでも4K画質のソフトウェアデコードギリギリ出来るな。
デコーダの並列度が高ければ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9177-DOJB) · 2019/02/10(日) 10:35:49.01

>>117
実際に落ちまくったのは最初の方やな。その後も落ちてたけど見られないほどひどくはない印象。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 02b2-FtKs) · 2019/02/10(日) 10:46:48.45

シーンによって再生負荷が変動してる気がするんだが
再生負荷が高そうな動画だとどうなるんだろう

2019/02/10(日) 13:56:38.44

つか、デコード負荷って結構あるんだね。今まで馬鹿にしてたわ。
2Kから4Kになれば負荷4倍なのは分かりやすいけど最近2Kの30fpsのmpeg2動画とh.264の動画をFireHD10でCPUで再生したらmpeg2こんな軽いんだね...
h.264だと再生ギリだわ。

最新コーデックってのはエンコ側ですげぇ頑張って、デコード側は大した変わらないのかなと盲目的に思ってたわ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2d23-OF6d) · 2019/02/10(日) 14:00:53.85

GPU支援とかの機能があったりするのはそういうのが有効な程度には負荷があるってことだしね

2019/02/10(日) 14:45:02.12

2Kの30fpsのmpeg2
HW L40% L40%
SW L50% L50% B50%
2Kの30fpsのAVC
HW L40% L40%
SW L60% L60% B70% B70%
2Kの30fpsのHEVC
HW L40% L40%
SW L90% L90% B100% B100%(かくかく)
android版VLC FireHD10 MT8173
LとかBはlittleコア、bigコアでアバウトなCPU使用率

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9177-DOJB) · 2019/02/10(日) 14:49:57.63

スマホにAV1/HEVC配信をするのってバッテリー面で大丈夫なのだろうか。

**名無しさん＠編集中** (ｽﾌｯ Sd22-ZIal) · 2019/02/10(日) 16:11:58.54

HEVCは新しい比較的SoCだとAndroidでもiOSでもHWデコードできなかったっけ？AV1は負荷がかかるからバッテリー持ち悪そうではある

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2d23-OF6d) · 2019/02/10(日) 17:11:24.75

なぁに糞重いゲームとかと比べると屁みたいなもんよ
まあ電気食わないに越したことはないんだけどさ

2019/02/10(日) 17:57:13.49

AV1でリアルタイムエンコ出来るわけ無いだろ…

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8de7-OF6d) · 2019/02/10(日) 18:07:19.31

AV1はHWメーカーも入って検討してるんだし、HW実装さえされれば
ユーザ側は少なくともデコードについては特に心配せずに使えるんでないかい。

デコードはユーザーレベルまで普及するだろうけど、エンコードがどうなるかはまだわからんね。

2019/02/10(日) 18:17:42.72

>>127
そこでH.264の出番!()

**名無しさん＠編集中** (ﾜｯﾁｮｲ 82e3-ZFeD) · 2019/02/10(日) 21:56:54.41

AVCのデコードの重さはCore2Duo世代の年寄りにとっては当たり前の話みたいなもんだったけど
今の若い人には逆に新鮮なんだな

当時はSD画質でも体感負荷が倍くらいあったけど
今はマルチコアの並列化がこなれてきてるのかMPEG2で50%負荷→AVCで70%負荷程度しか変わらんのな

JPEG2000もそろそろパッと読み込まれるようになってもええんやで、と思ってググったら
FLIFとかいうロスレス規格も出てきてたんだなhttps://gigazine.net/news/20160308-flif/
完全に浦島太郎状態だわ

2019/02/10(日) 22:11:41.46

普及する見込みのないコーデック覚えても意味ないから知らなくていいよ

2019/02/10(日) 22:21:26.62

J2Kは回路コストが高すぎるとかで普及しなかったらしいけどAV1はどうなんだろう

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9177-DOJB) · 2019/02/10(日) 22:30:34.47

テレビ局のエンコーダーでお馴染みのソシオネクスト君がやってはいるんだけどね。
https://www.socionext.com/jp/pr/sn_pr20180606_01j.pdf

**名無しさん＠編集中** (ﾜｯﾁｮｲ 92e3-ZFeD) · 2019/02/10(日) 22:40:09.22

動画の帯域問題はプロバイダやサーバー事業者（サービス提供者）にとっては死活問題だから
YouTube（Google）とNetflixとPrime（amazon）とHuluが主導してる時点で意地でも普及させてくると思う

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2d61-QeCQ) · 2019/02/10(日) 22:59:30.12

Ubuntu創業者Mark Shuttleworth自らキターーーッ
https://code.videolan.org/videolan/dav1d/merge_requests/577/commits

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2d61-QeCQ) · 2019/02/10(日) 23:31:02.97

Mark Shuttleworthこっちにも来てたw
https://github.com/OpenVisualCloud/SVT-AV1/pull/38
インストール、アップデートがめちゃらくになる

2019/02/11(月) 05:29:56.58

大御所が来るとワクワクするなぁ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 022c-tTYk) · 2019/02/11(月) 12:18:12.82

>>130
DVD見るためにセレロン300AをOCしていた思い出・・・

2019/02/11(月) 14:37:09.21

再エンコードとかなかった頃のニコニコ動画で再生負荷高くて再生できないなんてことがクソスペックであったからなぁ
逆に再生負荷あげられまくれるからベンチマークなんてのあったし

2019/02/11(月) 14:49:32.71

YouTubeの720p/AV1はそこそこ普通に見られるのにニコニコ動画のHTML5プレーヤーは止まりまくるの草

2019/02/11(月) 15:13:57.25

>>138
パソコンでDVD 見たいなら再生支援チップが載ったグラボ買った方が良いよ！な時代やな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 82d2-hHwN) · 2019/02/11(月) 19:00:02.67

https://pbs.twimg.com/media/DzHM_vaUUAApdg_.png
https://pbs.twimg.com/media/DzHNAzcUcAAPhvF.png
https://pbs.twimg.com/media/DzHNBr9UwAAE0om.png
https://pbs.twimg.com/media/DzHNC3iUUAEWCUt.png
4枚目に記述してあるfpsはpedestrian_area_1080p25をエンコードした時の数値。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 82d2-hHwN) · 2019/02/11(月) 19:10:49.97

CPUなに使ってるか書いてなかった
Ryzen 5 2400Gです

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/11(月) 19:28:21.76

>>142-143
乙です。

　・SVT-AV1、libaom、rav1e、libvpx VP9、x265、x264のVMAFでの比較評価。（重い設定での比較）

　・全体的にlibaomが良好、その次にx265とlibvpx VP9。

　・SVT-AV1はその次くらいで、rav1eと同等かそれ以上。

ってところかな。そしてやっぱりAV1は重い。

2019/02/11(月) 20:09:41.51

AV1がすごい、HEVC/VVCがすごい以前に2つの参加企業見比べたらAV1がVVC潰しに掛かっているような構図にしか見えない。

2019/02/11(月) 20:16:33.39

同じAV1でもlibaomとSVT-AV1、rav1eでは別物クラスの違いがあるね
libaomは低ビットレートでの改善具合がすごい
ただ、重いんだろうなぁw
問題は、高解像度映像でどの程度の改善があるのか
libaom使って4Kをエンコードした場合に、HEVCより3割以上縮むのならば、4K放送の当面の保存用に考えなくもないが…
（4Kは保存場所がどうしても消費してしまうし、画質落とした4Kを保存するくらいならば2Kでいいだろとすらなってしまうのがイタい）

**名無しさん＠編集中** (ﾜｯﾁｮｲ 41e7-OF6d) · 2019/02/11(月) 20:39:55.79

>>145
「参加企業」つってもHEVCの参加企業と言ってるのはライセンスを保持する企業群のことだろうし、
AV1(AOM)の参加企業は「HEVCのライセンスは内容も複雑さもクソ」って企業が集まったってだけでしょ。
別にVVCを潰すなんて意図はないし、VVCでHEVCのクソライセンスの悲劇を繰り返さないためにMC-IFって組織も立ち上げられてる。

2019/02/12(火) 01:07:16.82

VVCがAV1より良い出来で、ライセンスが分かりやすくなったらそっちに鞍替えする企業も出てくるのだろうか

2019/02/12(火) 02:50:53.44

VVCはAV1を超えてくるだろうね
単純に後発なのもそうだしAV1はmpegが今まで積み上げてきた特許回避しなきゃならないから
それにライセンスも今回は慎重にいくみたいだし

まあAV1はmpeg帝国に対するけん制みたいな面もあるしあんまcodec戦争とか言われるようなもんじゃないのかもね

2019/02/12(火) 03:26:21.89

>>142
rigaya氏いつも乙です

2019/02/12(火) 04:51:15.31

(お寿司アイコンの人なんだよなぁ…)

2019/02/12(火) 11:56:45.50

libaom凄いな
3000kbpsでもうほぼソース画質に近くなるのか
そりゃ動画配信企業はお熱になりますわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8de7-OF6d) · 2019/02/12(火) 17:06:28.01

>>150
俺も別スレでグラフ出しただけでrigaya氏扱いされたことがあるけど、
匿名掲示板で名乗りもしてないレスに対して「〇〇さん乙です」みたいな人物特定するような書き込みをするのは
結構気色悪い行為だからやめたほうがいいと思うよ。的外れなら尚更。

2019/02/12(火) 18:55:57.73

>>153
その後同じグラフをブログに掲載すんだからバレバレじゃん

2019/02/12(火) 18:57:26.04

氏がこのスレかソース元サイトを見てるって事でしょ。
アンテナ張ってる先は同じなんだからさ。まずここ特定板じゃねえし、特定厨は邪魔だから帰って

2019/02/12(火) 18:58:20.40

気色悪いっていうより性格悪いだけ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8de7-OF6d) · 2019/02/12(火) 19:07:51.99

ネトゲで「お前同じクラスの〇〇だろ！キャラの顔があいつに似てる！」と叫んでる人を見てる気分。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 82d2-hHwN) · 2019/02/12(火) 19:25:44.24

もしかしてグラフ作るのが技術的に物凄く難しくてrigaya氏みたいな人じゃないと出来ないと思ってる？
libreOfficeみたいなフリーのオフィスソフトでも簡単に作れるんだけどな

2019/02/12(火) 20:41:37.81

ところで、libaomとはどうやって使うものなの？
あと、これを使ってエンコードしたものをまともに再生しようとした場合に、ハードウェア再生支援の存在しない現状で要求されるハードウェアスペックとはどの程度なのだろうか？
エンコードを時間かけてやってもまともに再生できないようではさすがにつらすぎるし

**名無しさん＠編集中** (ﾜｯﾁｮｲ fe2d-feI+) · 2019/02/12(火) 20:47:52.42

個人でまともに再生したいならx265使えばいい

2019/02/12(火) 21:20:37.94

Google Cloud Platformの仮想Windowsでエンコードから再生までやってる。音声と映像のラグが酷いけど。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 86e3-OF6d) · 2019/02/12(火) 21:28:25.54

ffmpegとLAV Filtersでエンコードもデコードもできるんだから1:30くらいの動画を試しに変換してみればいいじゃん

と思って検索掛けてみたらAV1の画像フォーマットもAVIFも策定されてきてるんだな
https://people.xiph.org/~negge/AVIF2018.pdf
前に見つけたFLIFはJPEG2000よりさらに2倍近く読み込み時間が必要だったからwebpの後継として期待したい

2019/02/12(火) 23:21:14.98

>>162
FFMpegでエンコードするときの使い方をわかりやすく解説した資料とかないかな？

2019/02/12(火) 23:27:06.40

GUI公開されてるの幾つかあるけど、やっぱ個人で実用的に使うのはまだ先になりそうだねー
設定項目多すぎるよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ cde3-OF6d) · 2019/02/12(火) 23:53:40.25

>>163
基本的なのはffmpegのページに載ってる
現状での再生スペック測る程度なら充分かと
https://trac.ffmpeg.org/wiki/Encode/AV1

2019/02/13(水) 00:40:42.78

>>164-165
やっぱりまだテスト目的止まりか
使い物になるのはいつ頃だろ？
4Kの容量削減のために、なるべく早く使いたいところ

話変わるけど、BS4K放送がリアルタイムハードウェアエンコードで33Mbpsで放送しているけれど、x265でslowくらいの設定で放送と同程度くらいのエンコードをした場合だと、
ビットレートはどのくらいまで落とせるものなのだろうか？
あまり変わらないかな？

2019/02/13(水) 00:53:49.27

むしろlibaomのパラメータ少ないと思ったが…

2019/02/13(水) 00:54:56.63

33Mbpsでも不足してる(画質維持には50Mbpsは欲しいところ)から何とも…
その上で考えると、放送画質相当なら20Mbpsくらいにまでなら落とせるかもしれない。

2019/02/13(水) 01:18:01.32

>>168
絶対的な画質で言ってしまえばビットレート不足か場面がないわけではないけど、放送としては開始間もない状況では充分なのではと個人的には思っているけれど
で、x265で積めて20Mbpsあたりか…
2年前くらいのNHK BSプレミアムと同程度の保存容量か
やはりAV1かVVCが来ないと保存場所の確保が大変になりそうだな
とりあえずAV1のハードウェア再生支援を早急に整備してほしい…

2019/02/13(水) 01:36:54.76

>>149
HEVCやAV1で拡張扱いの機能が標準で取り込まれてたりするからね

2019/02/16(土) 16:46:44.53

VVCって一番遅いエンコード設定にしたら10Mbpsで4K/24fps出来たりするのかね?

2019/02/16(土) 17:18:16.96

何を基準に出来るというか分からないけど前評判ではAV1より縮むはず。
実際個人で試せる所まで来てみないと分からんだろう。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 87e3-cT+3) · 2019/02/16(土) 17:41:33.60

低ビットレートなら半分くらいのビットレートで済むのは有るだろうけど
高画質目的なら H.264/AVC -> H.265/HEVC での圧縮率と同じ4/5程度だろうなと思ってる

**名無しさん＠編集中** (ﾜｯﾁｮｲ 87e7-cT+3) · 2019/02/16(土) 18:34:35.71

>>172
VVC Test Model (VTM) なら一応個人でも試せる。

　Versatile Video Coding (VVC) | JVET
　https://vvc.hhi.fraunhofer.de/

　jvet / VVCSoftware_VTM ・ GitLab
　https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fd2-07dM) · 2019/02/16(土) 18:37:58.26

doom9にビルド済みバイナリもあるね

https://forum.doom9.org/showthread.php?p=1865448#post1865448

**名無しさん＠編集中** (ﾜｯﾁｮｲ a761-5nnY) · 2019/02/16(土) 19:11:52.60

https://www.reddit.com/r/VVC/

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fd2-07dM) · 2019/02/16(土) 19:17:27.42

下のをダウンロードして
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/blob/master/cfg/encoder_randomaccess_vtm.cfg

こんな感じでエンコード出来た

ffmpeg.exe -y -i "%~1" -an -pix_fmt yuv420p -f rawvideo input.yuv
EncoderApp.exe -c cfg_encoder_randomaccess_vtm.cfg --InputBitDepth=8 --OutputBitDepth=8 -q 25 -fr 24 -wdt 1280 -hgt 720 -f 10 -i input.yuv -o output.yuv -b output.bin
ffmpeg.exe -y -f rawvideo -s 1280x720 -r 24/1 yuv420p -i output.yuv -vcodec utvideo -an output.avi

**名無しさん＠編集中** (ﾜｯﾁｮｲ 87e7-cT+3) · 2019/02/16(土) 19:31:03.26

.yuvの入出力がパイプ渡しでできれば便利なんだけどねえ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fd2-07dM) · 2019/02/16(土) 19:35:33.47

>>177
誤 ffmpeg.exe -y -f rawvideo -s 1280x720 -r 24/1 yuv420p -i output.yuv -vcodec utvideo -an output.avi
正 ffmpeg.exe -y -f rawvideo -s 1280x720 -r 24/1 -pix_fmt yuv420p -i output.yuv -vcodec utvideo -an output.avi

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7fa7-dCfb) · 2019/02/17(日) 05:07:51.50

東京五輪後に地デジ４Ｋ開始で、映像圧縮はH266!

2019年2月12日(火)―2月8日発行　第64巻第15376号
地デジ以上の一大Ｐ・東京・名古屋実験公開
技術的焦点はＨ．２６６活用とＳＦＮ目途
総務省来年度予算８０億・最多額投入し具現へ
地上波４Ｋ、愈々検討本格化・五輪以降開始方針

2019/02/17(日) 05:33:48.73

>>180
まーた無茶してノイズ/モアレだらけの偽高解像度放送やるんか

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fb2-8zyB) · 2019/02/17(日) 10:46:19.22

今の地デジ放送って1つのチャンネルに複数のフォーマットを混在させることってできるのだろうか
ゴールデンタイムとかは現行の地デジのまま、深夜に４K８K放送流して
視聴者はそれを録画して見るとか

2019/02/17(日) 10:56:29.98

関テレが研究してたのってそういうのじゃやかった？4Kの電波を現放送に乗せる的な
違ったっけ

**名無しさん＠編集中** (ﾜｯﾁｮｲ a7e7-cT+3) · 2019/02/17(日) 17:03:38.99

>>180
決まってもいないことを決まったかのように書いてる１行目は自分で書いたのか。
スポーツ新聞や転載まとめサイトじゃあるまいし、やめたほうがいいと思うよ。

　マスコミ研究会 > 日刊合同通信 > バックナンバー
　http://www.godotsushin.com/backnumber_nikkan/2019/2019_02html.htm

「東京・名古屋実験」って、どういう団体がどういう実験をした（する？）んだろな。
「五輪以降」ってのは「何年後とは言ってない」ってレベルの話であって何のメドにもなってないし、
検討がまだ進んでない状況なんだから、やるとしても東京五輪以降ってのは当たり前の話でもあるし、
そもそもVVC(H.266？)の標準化予定が2020年10月（東京五輪より後）。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 275f-cT+3) · 2019/02/17(日) 17:58:55.52

>>184
実験はいつも通りNHKがやるんだよ
http://www.soumu.go.jp/main_content/000539299.pdf

2019/02/18(月) 00:26:23.57

もう遅いだろうが五輪4K諦めてH.266出てから実験始めろ

2019/02/18(月) 01:06:00.37

>>182
H.264のワンセグと普通のMPEG-2が一緒に配信出来てるからTSならできるでしょう。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5f2c-xv4H) · 2019/02/18(月) 01:16:47.65

>>187
1Chあたりの容量は変わらんから両方とも相当悲惨な絵になりそう

2019/02/18(月) 06:07:30.18

AVX512が使えるとSVT-VP9がすごい
AVX512有無だけでここまで変わるものなのか
https://www.phoronix.com/scan.php?page=news_item&;px=SVT-VP9-Open-Source

2019/02/18(月) 11:26:22.45

10Mbps超でH266で4Kならそこそこ綺麗そうだけどな

2019/02/18(月) 18:36:33.75

Chrome/Firefox「Flashはセキュリティ面の問題もあるし、何よりWebはオープンであるべき!」
Chrome「せや!動画もH.264/H.265排除したろ!」
Apple「駄目です。」
Chrome「ぐぬぬ・・・」←いまここ

将来的にChromeがVVC排除する危険性は0じゃないし、Webに載せるのは慎重になってしまう。

2019/02/18(月) 18:50:00.26

かと言ってAV1が普及するかと言えば、再生すら糞重たい現状ではかなり難しい
（CPUデコードで4K再生とか8コアクラス以上のCPUじゃないと無理だろ）

2019/02/18(月) 18:52:34.76

i7-2600程度だと720pですらコマ落ちしまくるからなぁ

**名無しさん＠編集中** (ﾜｯﾁｮｲ a7e7-cT+3) · 2019/02/18(月) 19:24:56.77

>>189
記事内のリンクで気づいたけど、2/15にSVT-AV1のベンチマーク記事も出てたんだね。
2/3版に比べて、2/15版はかなり速くなってるとのこと。
（まあそれでも i9-7980XEで1080pが8.5fpsくらいだけど・・・。）

　SVT-AV1 Already Seeing Nice Performance Improvements Since Open-Sourcing - Phoronix
　https://www.phoronix.com/scan.php?page=news_item&;px=SVT-AV1-Speed-Progress

**名無しさん＠編集中** (ﾜｯﾁｮｲ a7e7-cT+3) · 2019/02/18(月) 19:27:07.56

>>192-193
参考までにPhoronix Test Suiteのdav1dのベンチマーク。1080pと4Kのデコード速度。

　dav1d Test Profile
　https://openbenchmarking.org/test/pts/dav1d

　グラフ
　dav1d Performance Showdown, Automated Performance Comparison
　https://openbenchmarking.org/showdown/pts/dav1d

**名無しさん＠編集中** (ﾜｯﾁｮｲ a7e7-cT+3) · 2019/02/18(月) 19:34:14.50

2019/02/18(月) 20:54:14.05

>>195
掲載しているCPUに偏りがありすぎて資料としての価値が…
そもそも物理コアが2コア、4コア、6コア、8コアでそれぞれ何fps程度までコマ落ちなしで再生できるのかみたいな比較じゃないとわかりにくいし

あと、今年中に登場予定のIntelの新型CPUがかなり気合い入ってるらしいので、そいつに期待するか

2018年あたりからThunderbolt3端子搭載ノートPCが増えてきているから、Thunderbolt3接続タイプのAV1ハードウェア再生支援回路とかが出れば普及させやすいかもしれんが

**名無しさん＠編集中** (ﾜｯﾁｮｲ 87ad-2NBu) · 2019/02/19(火) 11:19:45.35

https://satch.tv/forums/forum/satella2_first?mref=115

**名無しさん＠編集中** (ﾜｯﾁｮｲ bfe3-cT+3) · 2019/02/19(火) 11:38:42.25

ffmpeg+QSVでH.264とHEVC両方使ってみたけど
意外とCPU負荷もあるんだな

GPUに全部お任せできるくらいに思ってたわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7fa7-dCfb) · 2019/02/19(火) 11:38:44.66

H.265の寿命は短かったなあ。4K8Kのコンテンツもコーデックもオワコン。