次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
■ このスレッドは過去ログ倉庫に格納されています
H.264/AVCの後の様々なビデオコーデック全般について語るスレです。
■主な次世代ビデオコーデック
・H.265/HEVC
・VP9
・AV1(AOMedia Video 1)
・VVC(Versatile Video Coding)
■前スレ
次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
https://mevius.5ch.net/test/read.cgi/avi/1515759816/
次スレは>>980が宣言してから立ててください。 なんだこの最高に頭悪い記事は・・・
Apple T2チップHEVCエンコードの利点と限界 - ITmedia NEWS
http://www.itmedia.co.jp/news/articles/1812/12/news063.html dav1d 0.1.0 "Gazelle" をリリースしたよという記事。(>>531の続き)
First release of dav1d, the AV1 decoder - Yet another blog for JBKempf
http://www.jbkempf.com/blog/post/2018/First-release-of-dav1d >>フォーマット変換のみ行っているようです
どういうことだ… >>713
> ファイルサイズがあまり小さくならないことから、フォーマット変換のみ行っているようです。
うーん…有象無象のニコ厨の方がまだマシな記事書きそう こういう奴のために、ボタン一つで変換できるソフトが喜ばれるはずなのに…
知識ない人間がいきがるなと コンテナだけ変えたって言ってるのかと思ったけど
> 時間はかかるが、丁寧にエンコードしてビットレートを下げてるようだ。
って書いてるとこ見ると「丁寧にエンコード」してないことを端折って書いた感じか
誤解を招く書き方というかなんというか Demuxedというイベントで行われたVVC(Versatile Video Coding)に関するプレゼンの記事。
VVC video codec - the next-next generation codec
https://bitmovin.com/vvc-video-codec/ 簡便なフィルタも無い単純なトランスコーダって事だろう >>722
おお、Windows insider previewで早速対応するのか タイトル通りだけど、各種ツールでのAV1サポート状況や使い方など。
How to use AV1 with open source tools
http://www.jbkempf.com/blog/post/2018/AV1-open-source-tools はやくXnやPerfectViewerがavifに対応してくれないかなー えーぶいあい
えふえるぶい
おーおーじー
まとりょーしか え?
じゃぁMPEG2をMoving Picture Experts Group 2とか言ってるの?
すげぇウザいぞそれ AVIF RI(Reduction Image)えびふらい H.264 | AVCは全部足してのばすとこう?
International Telecommunication Union Telecommunication Standardization Sector Rec. H.264 | International Organization for Standardization/International Electrotechnical Commission 14496-10 Moving Picture Experts Group 4 Part 10 Advanced Video Coding 揚げ足取りはNG
あげあしとり…揚げ脚鶏…
今晩はフライドチキンにしよう >>727
>>728
エイヴィフがしっくりときた AVC アダルト ビデオ コンテンツ
HEVC エッチ エロ ビデオ コンテンツ
VP9 ビデオ ポルノ 9
MPEG マゾヒスト ペンペン エロ ギンギン
HEIF エッチ エロ インサート フィニッシュ
AVIF アンアン
(ここで何くだらねー事まとめてんだと我に返る エイヴィフ(AVIF)
エイハブ(AHAB)
…字にしてみるとあまり似てないな、うん >>722にAVIFの作り方書いてるけど誰か試した? libvpxのvp9デコーダがマルチスレッドに最適化されて速くなるらしい
ffmpegのvp9デコーダであるffvp9が以前からlibvpxより数倍速かったからほとんどのソフトには関係ない事だけど
chromiumがバイナリサイズが増えるからとかいうクソみたいな理由で頑なにffvp9を拒み続けてるからchromium系のブラウザ使ってる人には将来的に恩恵あるだろうね
ちなみにffvp9とdav1dの作者は同じ人
chromiumはAV1になっても同じような対応をする可能性が高いのでおそらくchromiumでdav1dは使われないだろう
https://www.phoronix.com/scan.php?page=news_item&px=Libvpx-Tile-SB-Row-MT-Decode マジかよ知らんかった
youtubeでVP9再生する時にchromeよりfirefoxのほうが軽いと思ってたけどちゃんと理由があったんだな いつものAppleって感じだけどAOMのFOUNDING MEMBERSなのにサポートしないってどうなのよ >>748
Apple、64-bit環境への移行に伴い
macOS Mojave後のmacOSでネイティブサポートされなくなる
レガシィメディアのファイルフォーマットをFCPXやiMovieユーザー向けに公開。
2018年12月にメディアエディタ向けに案内されたメーリングリストによると、
AppleはmacOS Mojave後のmacOSにて64-bitテクノロジへの完全な移行を行う目的で、
QuickTime 7フレームワークとの互換性のあった以下のメディアフォーマットやコーデックをレガシィフォーマットとし、
macOSでネイティブサポートしなくなると発表しています。
3ivx MPEG-4
AV1 / VP9
AVC0 Media AVA0 Media
BitJazz SheerVideo
(以下略)
_人人人人人人人_
> AV1 / VP9 <
 ̄Y^Y^Y^Y^Y^Y^Y ̄
レガシーとは一体…… 百歩譲ってVP9はレガシー扱いで許したとしても、
AV1がレガシーとは一体… こうやって足を引っ張り合う訳ですよ
人類って本っ当にバ〜〜〜〜〜〜〜〜〜化だな〜〜〜〜〜〜〜〜〜〜〜〜〜wwwwww
いや本当にこれH.264が動画界のJPEGポジションで居続ける将来しか見えないんだけど 人類というかAppleってやっぱり馬鹿だなって思うわ https://support.apple.com/ja-jp/HT209000
記事読む暇がないヒト向けに書いておくと、自社製ソフトウェア上における
「ネイティブ編集対応をやめる」のであって、直接扱おうとしたらまず
ProResにトランスコードが始まるようになる。それから編集ってこと
※変換されんの嫌なら他社製ソフトウェアで編集してねってことで
わざわざWindowsマシン使って変換とかが必須になるわけではない スマブラSPでVP9使われたみたいね
コンシューマーゲーム機で次世代コーデックは何気に初めてか スマブラのムービーってh265じゃなくて、vp9なの? >>761
諸々の事情で>>1にあるように「H.264/AVCの後」のコーデックを次世代と位置づけてスレを立てただけなので
そこはあまり気にしなくてOK。 >>748 >>750 >>756
Final Cut Pro X のレガシーメディアについて - Apple サポート
https://support.apple.com/ja-jp/HT209000
macOS 用 iMovie のレガシーメディアについて - Apple サポート
https://support.apple.com/ja-jp/HT209029
Macのことはよく知らないけど、そもそもこれまで Final Cut Pro X や iMovie で
VP9やAV1を読み込むことはできたのかな?そういう話題を見かけたことが無いような・・・。
レガシーと言ってるのは、コーデック自体のことというより、QuickTime 7 フレームワークを利用しているものを
レガシーだと称しているだけみたいだね。
> 2019 年前半にリリース予定の Final Cut Pro のアップデートに、QuickTime 7 フレームワークを使う
> レガシーメディアを探し、変換する機能が盛り込まれる予定です。
読み方によっては、この時にAV1やVP9の変換読み込みをサポートすると解釈できないこともないけど・・・さて。 レガシーフォーマットだから、フレームワーク提供しないよー
他社アプリは勝手に拡張して対応してくれるかもねー
ってAOMに参加したばかりの大企業とは思えない決定だな 「影響を受けるメディアフォーマットの例」の中に「AV1/VP9」が入ってるから
そこだけ見て誤解してる人が多いようだけど、主題は
「QuickTime 7 フレームワークの利用停止」
なので、やってることはごく真っ当な進化だと思うよ。
そもそもこれまでもAV1/VP9の読み込みなんてサポートしてなかったみたいだし。
サードパーティの読み込みプラグインがあるのかと思って探してみたけど見つからなかった。
だいたい現状で動画編集ソフトでAV1/VP9素材を扱う需要なんてほぼ無いだろうし、
動画編集ソフトでAV1をネイティブにサポートする時期なんて、HWデコーダ/エンコーダが
それなりに出だすであろう時期(1年後くらい?)になってもまったく問題ない。
そんなことよりSafariとかでのAV1/VP9再生をさっさと実装しろよと思うけど、
AV1はともかく、VP9はサポートしないまま終わりそうではある。 >>766
AV1がネイティブサポートされない、つまりAVFoundationで対応する予定が無いんだと思うよ
そうすると動画編集ソフト云々では無く、Safariでの再生対応も無いんじゃないかな ここにも裏切り者が
HEVC Encoder for Servers
https://developer.qualcomm.com/software/hevc-encoder-servers
>The HEVC video encoder software is designed to:
>Outperform VP9 and AV1 裏切りもなにもQualcommはAOMに入っていないような・・・ >>769
・・・入ってなかった。
HEIF/HEVC HWアクセラレータが載ってるSD855楽しみに待ってます裏切り者扱いしてごめんね。 裏切り者も何も、VP9やAV1が異端なだけだからねぇ VP9を個人でエンコする需要がない
個人ならライセンス関係ないからHEVCの方が全面的に優れてるし
AV1も今のところ遅すぎるから微妙だし
再生だけ対応してくれればいい スマホはAV1エンコードに対応する必要ないよな
デコードだけで良いよ スマホこそエンコードできたほうがいいでしょ
外出してビデオ撮影したファイルサイズを小さくできたり
ビデオ通話で画質が良くなったり
ひきこもりぼっちだからどれも関係ないしやっぱいらねーわ モバイルSoCにまともな性能で実装させたらlittleコア数個分の面積食いかねないけどな av1をモバイルでエンコードできるのは10年くらい掛かりそう
デコードを頑張ってほしいが、林檎とかいう天の邪鬼がいるからどうなるやら HEVCでいい気が…
8K普及したとしてもROM容量が増えてるだろうし大丈夫大丈夫 HEVCは企業側が採用したがらないからもし動きがあるとすれば次のVVCじゃないかな… 撮影用コーデックは撮影者が扱えてナンボだから、扱いづらいコンテンツ提供向けのライセンスフリーの高圧縮コーデックの方を優先するなんて普通に考えればありえないと思うけどな、スマホ用なら尚更だし 静止画にしろ動画にしろ、オフィス系ソフトと年賀状作成ソフトで手間なく開けるようにならない限り日本では普及しないだろうなあって思う >>783
法人市場ではそうかもしれんが
個人向けでオフィスや年賀状ソフトに依存しきってる奴が何%いると思ってるんだ
具体的な割合は知らんがそう多くは無いだろう QualcommがHEVC陣営だとしたらAV1はかなり不利なのでは PCや動画関連は法人需要がベース
個人需要なんてオマケ
個人需要ベースでモノ考えてたら動向を読み間違える元 MPEGと真っ向に対立してるのってweb系だけだろ
ハードウェアやOSやってるところは対立させるメリットが無い Google主導で開発してきたフォーマットで主流になれたやつあったっけ? フォーマットとは少し違うかもしれないけどhttp2.0とhttp3.0はGoogleが作ったプロトコルがベースだな
あとはbrotliとか https://drive.google.com/open?id=1vs9oqpXJt91FhkfNtYHFB3fO2OiN98C3
画像をAVIFに変換するbat書いた
Windows 10 Insider Preview Build 18305.1003で表示出来るファイルになるのを一応確認済み
まだ仕様が決まってないから画質確認して遊ぶ用だけど、AVIFと同サイズくらいのjpgを出力する機能もあるから興味ある人は試して jpg品質85の時
Y-SSIM 0.971384916666667
bpp 1.82670423719618
avif
Y-SSIM 0.972543208333333
bpp 1.07366349962023
jpg品質95の時
Y-SSIM 0.988786333333333
bpp 3.28187476264106
avif
Y-SSIM 0.988429625
bpp 1.92569732666016
bppは24枚の画像で(ファイルサイズ*8)/(横幅*縦幅)を計算した平均値 AACとかでも人間の耳じゃ違い分からんとか言われてたけど
実際聞くと違い分かるものだからあてにならん JPG85と95っておおよその人が一見して分かる差だと思うけど 実写というか写真だとオリジナルと見比べないならあまり気にならないけどCG、イラスト、アニメ絵とかだと
結構わかる差だよな
なんというかもともとソースが不自然にきれいすぎるもの相手だとどうしても目につく感じ >>798
(1.92569732666016/3.28187476264106)*100=58.6767462482
半分までは行かないけどjpgに対して58%くらいの大きさやね 85と95なら許容範囲の差だと思うけど。
80下回ったら画質悪いなと感じる 95未満だとキラーサンプルがあるとだれでも劣化が分かる
現実的には85で4:4:4なら結構いい感じ。
※クオリティ値はバニラcjpegと標準量子化テーブルでの話
JPEGって4:2:0がウェブの実質的標準なので性質悪いんだよな
カメラのJPEG保存ならセンサーが元々ベイヤー配列だし4:2:0も悪くないけど、
公開時にサーバー側処理で1/4未満の解像度にリサイズされた時点で各ピクセルは4:4:4相当の情報持つからね >>803
HiDPIが標準になれば420でも良いとは思うけど普及がまだまだだからなあ 高DPIになればそうだね。
ちなみに有名どころのサービスで再エンコでしっかり4:4:4 JPEGを吐くのはPixivしか知らない。
もしかしたらGoogle Photosもサムネイル表示だけ444だったかも※大きい解像度は420 ただしGoogle系はWebP対応ブラウザだと、フォーマットの制限で全部420
Webpは再エンコに極度に弱い
https://www.youtube.com/watch?v=ujBp5B35el4
大きいマクロブロックを使える最新のフォーマットの方が8x8のJPEGより色滲みの範囲が広くなるため再エンコ時の世代劣化が酷くなりがちなんだけど、WebPのエンコーダーは根本的に設計ミスしてるとしか思えない
ローパス効きすぎてるんじゃねえのかな 一応擁護するとGoogleは真にJPEGを置き換える目的のPIKというフォーマットを開発中。進展聞こえて来ないけど。
今度はブロックも敢えて8x8にしてJPEG並の再圧縮耐性がある模様 >>806
破綻を最小限にする為にボカシまくってるのかな?
さらに最新コーデックにありがちな油絵現象で追い打ちが
https://youtu.be/gJJachY651c ■ このスレッドは過去ログ倉庫に格納されています