次世代ビデオコーデック総合スレ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が宣言してから立ててください。 それが出来ないから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コンテナ扱える奴なら仮対応的な実装じゃ無ければイケるんじゃないの？ 電子書籍とかの複数ファイル画像って
動画にしてフレーム間圧縮で容量減らせそうだけど
やってるとこないのかな >>695
フレーム間の違い大きすぎて圧縮のための予測がうまく出来なさそう >>696
文字とかで余白の多いすかすかの雑誌系は
ページ間で連続した空白多いから容量減りそうだけどどうだろ そもそも空白が多い画像はjpgなりpngなりでも大きくないと思う。
1フレームごとに文字が離散しているので毎フレームIフレームにするのと画質対容量のメリットがあまりない。
kindleなどの端末で処理するにはフレーム間予測などの処理はハードウェアデコーダ積んだりキャッシュしていくにしろ重いだろうし流行らないと思う。
そういうので1番効果があるのはエロゲとかdlsiteにあるような差分データ盛り盛りのCG集などに限定されると思う。 そこは昔のゲームみたいに口や目の変化部分だけ画像作って
差し替える方式でいい気がする。マップチップ的な
まぁ今のもの見ると画像1枚1枚用意しているのが多いから容量増え気味だよね スクリプトミスったら差分の目が背景の上に浮くじゃないですかー VimeoがAOMediaのPromotor memberに。
Vimeo Joins the Alliance for Open Media
https://press.vimeo.com/31386-vimeo-joins-the-alliance-for-open-media エロゲって画像形式何使ってるんだろ、やっぱり可逆PNGなのかな 吉里吉里ならエロゲ絵に特化したTLG型式ってのが使えるけど
実際に使われてるのかは知らない。 >>695
OCRしてテキスト化の圧縮率に到底勝てないからやる意味が無い >>695
面白いアイディアだな、言い出しっぺの法則で作ってみてくれ
ただ全ページがキーフレームになってしまうとかあり得るんじゃね 電子書籍は突飛なアイデアではなくて自分も数年前に検討済み
電子書籍には3タイプあって、698の言う通りで、連続差分画像以外に
ましてやテキストオンリーの書籍に動画コーデックの出る幕は無い
・画像のみ：コミック、写真集
・テキスト+画像レイアウト：雑誌やムック、写真集、美術書など
・テキスト：小説など
テキスト+画像レイアウトの場合、活躍するのは静止画フォーマットだけ。
残された画像のみの場合だが、すでにHEIFはイメージシーケンスが規格に組み込まれてるから
新たにやることは各電子書籍ベンダーがそれを利用するかどうかくらい。 漫画なら図形の輪郭とかとかスクリーントーンとかそういうのを符号化すれば…
って思ったけどpostscriptだな もう、基本の圧縮技術は画像にしろ動画にしろ、JPEGの時代に確立されちゃってるのか・・？？
それからあんま本質は変わってないのかね 500年後の未来から来たけど、今の圧縮技術はその概念自体が使われなくなるよ
究極のイメージ処理は、全データをベクター処理すること
ラスターイメージ処理は電子機器の能力が低い現代における
低レベルなお粗末な石器時代並みの技術だよ
量子コンピューターにより画像自動解析処理が高度に発達した未来では
2Dの平面データで記録再生するのは骨董品技術になる
わかりやすく現在の製品名で例えれば
Illustrator>>>超えられない距離>>>Photoshop
未来のカメラは撮像したデータを自動解析して、
3Dオブジェクト+テクスチャ判定+光源計算したデータとして保管
テクスチャも撮像データから得た2Dラスターデータではなく
全世界で共用管理している超大規模データセンターの膨大なデータから
何番目のテクスチャ、というID指定を記録するだけなので、データ量は軽い
再生時に3Dグラフィックでリアルタイムレンダリング処理を行う
圧縮という概念自体がなくなる
ただし、メロンパンは500年後の未来でもなくなっていません。あれは美味しいデス 電子書籍に関してはePubの規格がバージョンアップしてリフローとフィクスのハイブリッド型も作れるようになってるね
現状では雑誌の電子書籍版のインタビュー記事とかがテキストも含めて全部画像だったりするけど
今後は必要に応じてテキスト部分はテキストデータのページに置き換えるような措置をした方がファイルサイズを抑えるのとコンテンツの読みやすさを両立できて良いと思う >>708
JPEG 2000ではウェーブレット変換が使われていたけど、結局それ以降は使われていないよね
コサイン変換に比べて、あまり筋のいい技術ではなかったということなのかなぁ 某ネコさん曰く、16k以上の画素数だとwaveletが日の目を見るかもしれないらしい JPEG XSもwaveletだそうだけど、どんな感じの圧縮なんだろう。 >>713
おねえさんのお尻でぎゅーって押し潰される感じ♥ >>711
ビデオ規格だと、SnowやDiracもウェーブレット変換 DCTと違ってブロックノイズが発生しないのがDWTの利点だけど、
ブロック単位でする動き補償と相性が悪いので動画には不向き waveletで圧縮しまくったらどうなるんだろ
ぼやけるだけ？ 特性的にエッジ部分の情報量から削られていくから、そういう部分の階調表現の幅が狭まる（コントラスト低下）と解像度感が失われて眠い画になっていくと思う（俗に言う眠い絵作り
特性がある圧縮だから万能じゃ無いかと
あくまでwaveletを手段として使っていているだけで、これ自体が圧縮方式では無い事にも注意（使い方や実装で性能が変わる
画像データの周波数的な情報の分離に向いていて、分離したデータの内で画像の全体像を把握するには重要じゃ無い部分を削る事で「圧縮にも使えなくは無い」ってだけで、内容的にはMP3的な（実装によって差が出やすい）プライオリティの低い情報を削る感じ
文字や図表、線画のエッジ部分が多い画像の圧縮には向かないと思う >>619
MISIAの4Kというと、「名前のない空を見上げて」のことかと思うけど、これ確かにスマホで聴いたほうが音いいからおかしいなと思って調べた
すると、確かに4Kでアップされてはいるのだけれど、1080pと1440pをmp4ファイルとWebMファイルで比較すると、mp4ファイルのほうがファイルサイズが大きくなっていた
通常、画質と音質がともにいい場合は、4Kより下の解像度でもファイルサイズは
WebM＞mp4もしくはWebM≒mp4
のいずれかであるのだが、この曲は逆転していた
だからダウンロードするのであれば、この曲に関してはmp4ファイルのほうがいい
ただし、ここからがよくわからないのだが、PCにてChrome上で再生した場合、再生中に詳細情報を確認するとWebMにも関わらず音は悪くない
ここがわからないんだよなぁ
YouTubeは謎が多い 今の動画サイトは、映像と音声は別々に保存してて、
視聴者がページ開いたときにくっつけて配信してるんじゃなかったっけ。 よくわからないのに書くからこういうことになるんだね マジレスするとYoutubeの場合、 https://pastebin.com/YiAnRD0w のように、
Ａ．音声のみのファイル
Ｂ．映像のみのファイル
Ｃ．映像＋音声のファイル
が複数あって、基本的にはＡとＢを組み合わせて配信される。
プレーヤー右クリック→詳細統計情報→Codecsで組み合わせが見れる。
Win10のPCのChrome/FirefoxはVP9+Opusだが、IEはAVC+AACだし、EdgeはAVC+Opusになることもある。
Opusは基本的に251番(160kbps)が使われるが、映像が144pの場合は250番(70kbps)が使われる。
スマホも、機種やブラウザ等によって組み合わせは変わるだろう。
音声だけなら22番(AAC192kbps)か251番(Opus160kbps)がベスト。
元々は音声の話なので上記を踏まえて音声だけ比較すべきだと思うけど、
>>721はなぜか映像まで含めてWebM vs MP4という比較をしてるし色々的外れ。
「通常はWebMの方がサイズが大きい」と言ってるのもよくわからない。
基本的にはVP9(WebM)の方がAVC(MP4)より小さくて、稀に逆のものもあるという程度だと思うけど。
変なダウンローダを使ってるか勘違いしてしまってるんじゃないかと思う。 ついでに言うとYoutubeの場合、VP9は比較的ファイルサイズが小さくなってるとはいえ、
たまにブロックノイズやリンギングノイズ（モスキートノイズ？）で
映像崩壊レベルになってるフレームがあったりする。
普通に視聴する分には気にならないけど、比較するとAVCの方が安定した画質になってるような。
まあ1440pHFR以上は基本的にVP9だけしか無いけど。 EdgeはGPUにVP9デコーダが搭載されてればVP9、
無ければH.264で再生されるから賢いというか優しいというか
ChromeはGPUデコーダ無くてもVP9にするからCPUデコードになって重い
VP9デコーダ無いような古いPCでCPUデコードとか鬼だ
メモリも喰いまくるしオンボロPCで動かすんじゃねえってGoogleの方針なんだろう HEIFってOSではポツポツ対応しはじめてるけどフリーソフトではなかなか対応しないね >>732
おんぼろPC+Chromeにh264ify入れて使ってるぜ… ネタ切れでビデオコーデック以外のネタばっかりになってきたな
それはそれで良いけど H.264が動画界のJPEGみたいな感じになって終わりやろ
新フォーマット？なにそれおいしいの？みたいな ■ このスレッドは過去ログ倉庫に格納されています
