X
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠編集中 (ﾜｯﾁｮｲ e1e7-uJAn)
垢版 |
2019/01/30(水) 16:23:41.40ID:Amc+t7YI0
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が宣言してから立ててください。
0082名無しさん＠編集中 (ﾜｯﾁｮｲ dfe7-S1Ul)
垢版 |
2019/02/06(水) 19:52:42.18ID:iiG25dOv0
>>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"
0084名無しさん＠編集中 (ﾜｯﾁｮｲ dfe7-S1Ul)
垢版 |
2019/02/06(水) 21:53:37.56ID:iiG25dOv0
>>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;
0085名無しさん＠編集中 (ﾜｯﾁｮｲ 46e3-ZFeD)
垢版 |
2019/02/07(木) 22:13:08.59ID:iMx52KwE0
WEBPでPNGをロスレス変換したときのファイルサイズの減少率に感動して
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…

たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな
0086名無しさん＠編集中 (ﾜｯﾁｮｲW 024b-9ozn)
垢版 |
2019/02/07(木) 23:26:22.97ID:d8RmpIty0
他人エンコならAAC128でも気にしないけど自分エンコの320とWAVは異様に気になって識別しちゃうみたいな所あるよね。
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする
0088名無しさん＠編集中 (ﾜｯﾁｮｲ 02e3-ZFeD)
垢版 |
2019/02/08(金) 01:02:09.44ID:FaS5LOof0
>>87
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー

と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年〜2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う
009088 (ﾜｯﾁｮｲ 02e3-ZFeD)
垢版 |
2019/02/08(金) 12:31:27.20ID:XHOMvMPc0
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設定のまま保存されていたようだ
009388 (ﾜｯﾁｮｲ 86e3-ZFeD)
垢版 |
2019/02/08(金) 17:55:01.22ID:MBZGzkoC0
GIMPでHEIF/HEIC保存できるのを知って>>90の16777216色画像でlossless変換してみたけど
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな

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

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

数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな
0094名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MM52-9ozn)
垢版 |
2019/02/08(金) 18:21:05.40ID:UlRVwGWHM
それほど大量にPNGを扱っているなら場合によってはBMPにして7zとかzpaqなどのアーカイブに放り込む方が縮むかもしれない
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな…
0097名無しさん＠編集中 (ﾜｯﾁｮｲ 8de7-OF6d)
垢版 |
2019/02/09(土) 01:14:35.57ID:Lkg2e27Z0
MicrosoftのHEIF画像拡張機能を入れてテストしてみようとしたら
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀)
0100名無しさん＠編集中 (ﾜｯﾁｮｲW a9b0-KAwQ)
垢版 |
2019/02/09(土) 07:25:25.95ID:SX96QM+v0
メタデータまで含め非破壊で安全である事と、速度と圧縮効率のバランスの良さでpngcrushの標準(-bruteとか指定しないで普通に使う)は使い勝手が良い
0101名無しさん＠編集中 (ﾜｯﾁｮｲ 41e7-OF6d)
垢版 |
2019/02/09(土) 12:01:23.04ID:D1Bfgd9M0
HEIF画像拡張機能、なんかインストールできねえなと思ったら
　　Windows 10 バージョン 17763.0 以降 （October 2018 Update〜）
になっとるやないかい・・・。まだApril 2018なままのうちでは無理か・・・去年さっさといれとけばよかった。
0103名無しさん＠編集中 (ﾜｯﾁｮｲ 86e3-ZFeD)
垢版 |
2019/02/09(土) 14:05:05.01ID:d8jrAH5w0
> 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変換でも色情報間引かれたりしないんだろうか
0104名無しさん＠編集中 (ﾜｯﾁｮｲ 46e3-ZFeD)
垢版 |
2019/02/09(土) 16:33:15.07ID:C7mp2mR+0
>>103やってみたけどサイズがPNGより膨らむ上にirfanviewでも開けないしよくわかんないっすね…
jpeg2000より圧縮率高かったら置き換えられるかなと思ってたけど厳しそう
0105名無しさん＠編集中 (ﾜｯﾁｮｲ 41e7-OF6d)
垢版 |
2019/02/09(土) 19:50:32.09ID:D1Bfgd9M0
>>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をロスレス保存することはできない。

という感じだと思う。
0106名無しさん＠編集中 (ﾜｯﾁｮｲ 41e7-OF6d)
垢版 |
2019/02/09(土) 21:44:49.69ID:D1Bfgd9M0
■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付与：　　 無し
0107名無しさん＠編集中 (ﾜｯﾁｮｲ 41e7-OF6d)
垢版 |
2019/02/09(土) 21:45:56.53ID:D1Bfgd9M0
■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として扱えとでも言うのだろうか・・・
0110名無しさん＠編集中 (ﾜｯﾁｮｲWW 495f-zsj5)
垢版 |
2019/02/10(日) 00:05:13.79ID:c1Tihcf60
次世代ビデオコーデックのスレで画像コーデックの話何時までやるの？
話題ついでレベルなら全然かまわんと思うけど
ゴリゴリ続けられてもちょっとな
0112名無しさん＠編集中 (ﾜｯﾁｮｲ 46e3-ZFeD)
垢版 |
2019/02/10(日) 00:19:13.56ID:eskOjsHm0
HEIFやWEBPみたいに静止画と動画の変換コーデックに同じものが使われる傾向が続くと
将来的には「昔は静止画専用のコーデックがあってさ〜」みたいな話になるんだろうか
0116名無しさん＠編集中 (ﾜｯﾁｮｲ 9177-DOJB)
垢版 |
2019/02/10(日) 01:22:36.25ID:rS1Ref0Y0
低スペックマシン(Windows10/AMD E1-7010 APU/RAM4.0GB)でYouTubeを720p/AV1設定にして視聴したんだが感動を覚えた。
Dropped Frames 683/5960 11.5%位落ちてるけれどこんな低スペックPCでchromeブラウザのAV1デコーダー凄い軽さだなぁと。
0118名無しさん＠編集中 (ﾜｯﾁｮｲW 024b-9ozn)
垢版 |
2019/02/10(日) 02:47:17.59ID:wV54BB3g0
>>118のCPUってcine bench15 マルチコアで70しか出ないのかよ…ちなみに9900Kが2000ちょい
仮にスコア100でフルフレーム出るとすると4コアCPUでも4K画質のソフトウェアデコードギリギリ出来るな。
デコーダの並列度が高ければ。
0119名無しさん＠編集中 (ﾜｯﾁｮｲ 9177-DOJB)
垢版 |
2019/02/10(日) 10:35:49.01ID:rS1Ref0Y0
>>117
実際に落ちまくったのは最初の方やな。その後も落ちてたけど見られないほどひどくはない印象。
0121名無しさん＠編集中 (ﾜｯﾁｮｲWW 4690-Bwin)
垢版 |
2019/02/10(日) 13:56:38.44ID:UraLMarw0
つか、デコード負荷って結構あるんだね。今まで馬鹿にしてたわ。
2Kから4Kになれば負荷4倍なのは分かりやすいけど最近2Kの30fpsのmpeg2動画とh.264の動画をFireHD10でCPUで再生したらmpeg2こんな軽いんだね...
h.264だと再生ギリだわ。

最新コーデックってのはエンコ側ですげぇ頑張って、デコード側は大した変わらないのかなと盲目的に思ってたわ。
0123名無しさん＠編集中 (ﾜｯﾁｮｲWW 4690-Bwin)
垢版 |
2019/02/10(日) 14:45:02.12ID:UraLMarw0
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使用率
0124名無しさん＠編集中 (ﾜｯﾁｮｲ 9177-DOJB)
垢版 |
2019/02/10(日) 14:49:57.63ID:rS1Ref0Y0
スマホにAV1/HEVC配信をするのってバッテリー面で大丈夫なのだろうか。
0125名無しさん＠編集中 (ｽﾌｯ Sd22-ZIal)
垢版 |
2019/02/10(日) 16:11:58.54ID:DGz5wh45d
HEVCは新しい比較的SoCだとAndroidでもiOSでもHWデコードできなかったっけ？AV1は負荷がかかるからバッテリー持ち悪そうではある
0127名無しさん＠編集中 (ﾜｯﾁｮｲW 024b-9ozn)
垢版 |
2019/02/10(日) 17:57:13.49ID:wV54BB3g0
AV1でリアルタイムエンコ出来るわけ無いだろ…
0128名無しさん＠編集中 (ﾜｯﾁｮｲ 8de7-OF6d)
垢版 |
2019/02/10(日) 18:07:19.31ID:/y8PkD8C0
AV1はHWメーカーも入って検討してるんだし、HW実装さえされれば
ユーザ側は少なくともデコードについては特に心配せずに使えるんでないかい。

デコードはユーザーレベルまで普及するだろうけど、エンコードがどうなるかはまだわからんね。
0129名無しさん＠編集中 (ﾜｯﾁｮｲW 9177-Cocm)
垢版 |
2019/02/10(日) 18:17:42.72ID:rS1Ref0Y0
>>127
そこでH.264の出番!()
0130名無しさん＠編集中 (ﾜｯﾁｮｲ 82e3-ZFeD)
垢版 |
2019/02/10(日) 21:56:54.41ID:dLysR4Z60
AVCのデコードの重さはCore2Duo世代の年寄りにとっては当たり前の話みたいなもんだったけど
今の若い人には逆に新鮮なんだな

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

JPEG2000もそろそろパッと読み込まれるようになってもええんやで、と思ってググったら
FLIFとかいうロスレス規格も出てきてたんだなhttps://gigazine.net/news/20160308-flif/
完全に浦島太郎状態だわ
0134名無しさん＠編集中 (ﾜｯﾁｮｲ 92e3-ZFeD)
垢版 |
2019/02/10(日) 22:40:09.22ID:v/4sZexS0
動画の帯域問題はプロバイダやサーバー事業者（サービス提供者）にとっては死活問題だから
YouTube（Google）とNetflixとPrime（amazon）とHuluが主導してる時点で意地でも普及させてくると思う
0139名無しさん＠編集中 (ﾜｯﾁｮｲWW bd5f-m4CA)
垢版 |
2019/02/11(月) 14:37:09.21ID:xK0vAipo0
再エンコードとかなかった頃のニコニコ動画で再生負荷高くて再生できないなんてことがクソスペックであったからなぁ
逆に再生負荷あげられまくれるからベンチマークなんてのあったし
0140名無しさん＠編集中 (ﾜｯﾁｮｲW 9177-Cocm)
垢版 |
2019/02/11(月) 14:49:32.71ID:rdXGmVRF0
YouTubeの720p/AV1はそこそこ普通に見られるのにニコニコ動画のHTML5プレーヤーは止まりまくるの草
0144名無しさん＠編集中 (ﾜｯﾁｮｲ 41e7-OF6d)
垢版 |
2019/02/11(月) 19:28:21.76ID:ZzHY0EqP0
>>142-143
乙です。

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

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

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

ってところかな。そしてやっぱりAV1は重い。
0145名無しさん＠編集中 (ﾜｯﾁｮｲW 9177-Cocm)
垢版 |
2019/02/11(月) 20:09:41.51ID:rdXGmVRF0
AV1がすごい、HEVC/VVCがすごい以前に2つの参加企業見比べたらAV1がVVC潰しに掛かっているような構図にしか見えない。
0146名無しさん＠編集中 (ﾜｯﾁｮｲWW d154-irfR)
垢版 |
2019/02/11(月) 20:16:33.39ID:dJsgS1pL0
同じAV1でもlibaomとSVT-AV1、rav1eでは別物クラスの違いがあるね
libaomは低ビットレートでの改善具合がすごい
ただ、重いんだろうなぁw
問題は、高解像度映像でどの程度の改善があるのか
libaom使って4Kをエンコードした場合に、HEVCより3割以上縮むのならば、4K放送の当面の保存用に考えなくもないが…
（4Kは保存場所がどうしても消費してしまうし、画質落とした4Kを保存するくらいならば2Kでいいだろとすらなってしまうのがイタい）
0147名無しさん＠編集中 (ﾜｯﾁｮｲ 41e7-OF6d)
垢版 |
2019/02/11(月) 20:39:55.79ID:ZzHY0EqP0
>>145
「参加企業」つってもHEVCの参加企業と言ってるのはライセンスを保持する企業群のことだろうし、
AV1(AOM)の参加企業は「HEVCのライセンスは内容も複雑さもクソ」って企業が集まったってだけでしょ。
別にVVCを潰すなんて意図はないし、VVCでHEVCのクソライセンスの悲劇を繰り返さないためにMC-IFって組織も立ち上げられてる。
0149名無しさん＠編集中 (ﾜｯﾁｮｲW bd02-2nwz)
垢版 |
2019/02/12(火) 02:50:53.44ID:pAuFBqsE0
VVCはAV1を超えてくるだろうね
単純に後発なのもそうだしAV1はmpegが今まで積み上げてきた特許回避しなきゃならないから
それにライセンスも今回は慎重にいくみたいだし

まあAV1はmpeg帝国に対するけん制みたいな面もあるしあんまcodec戦争とか言われるようなもんじゃないのかもね
0151名無しさん＠編集中 (ﾜｯﾁｮｲW 024b-9ozn)
垢版 |
2019/02/12(火) 04:51:15.31ID:4fMEzpfv0
(お寿司アイコンの人なんだよなぁ…)
0153名無しさん＠編集中 (ﾜｯﾁｮｲ 8de7-OF6d)
垢版 |
2019/02/12(火) 17:06:28.01ID:aWs0QX+90
>>150
俺も別スレでグラフ出しただけでrigaya氏扱いされたことがあるけど、
匿名掲示板で名乗りもしてないレスに対して「〇〇さん乙です」みたいな人物特定するような書き込みをするのは
結構気色悪い行為だからやめたほうがいいと思うよ。的外れなら尚更。
0155名無しさん＠編集中 (ﾜｯﾁｮｲWW a99b-KbRv)
垢版 |
2019/02/12(火) 18:57:26.04ID:juPfdEn70
氏がこのスレかソース元サイトを見てるって事でしょ。
アンテナ張ってる先は同じなんだからさ。まずここ特定板じゃねえし、特定厨は邪魔だから帰って
0158名無しさん＠編集中 (ﾜｯﾁｮｲ 82d2-hHwN)
垢版 |
2019/02/12(火) 19:25:44.24ID:T7QlbUJk0
もしかしてグラフ作るのが技術的に物凄く難しくてrigaya氏みたいな人じゃないと出来ないと思ってる？
libreOfficeみたいなフリーのオフィスソフトでも簡単に作れるんだけどな
0159名無しさん＠編集中 (ﾜｯﾁｮｲWW d154-irfR)
垢版 |
2019/02/12(火) 20:41:37.81ID:rrOD0+rV0
ところで、libaomとはどうやって使うものなの？
あと、これを使ってエンコードしたものをまともに再生しようとした場合に、ハードウェア再生支援の存在しない現状で要求されるハードウェアスペックとはどの程度なのだろうか？
エンコードを時間かけてやってもまともに再生できないようではさすがにつらすぎるし
0161名無しさん＠編集中 (ﾜｯﾁｮｲW 9177-Cocm)
垢版 |
2019/02/12(火) 21:20:37.94ID:9Gwk3FUH0
Google Cloud Platformの仮想Windowsでエンコードから再生までやってる。音声と映像のラグが酷いけど。
0162名無しさん＠編集中 (ﾜｯﾁｮｲ 86e3-OF6d)
垢版 |
2019/02/12(火) 21:28:25.54ID:v0EqkMJx0
ffmpegとLAV Filtersでエンコードもデコードもできるんだから1:30くらいの動画を試しに変換してみればいいじゃん

と思って検索掛けてみたらAV1の画像フォーマットもAVIFも策定されてきてるんだな
https://people.xiph.org/~negge/AVIF2018.pdf
前に見つけたFLIFはJPEG2000よりさらに2倍近く読み込み時間が必要だったからwebpの後継として期待したい
0166名無しさん＠編集中 (ﾜｯﾁｮｲWW d154-irfR)
垢版 |
2019/02/13(水) 00:40:42.78ID:GtS0jeru0
>>164-165
やっぱりまだテスト目的止まりか
使い物になるのはいつ頃だろ？
4Kの容量削減のために、なるべく早く使いたいところ

話変わるけど、BS4K放送がリアルタイムハードウェアエンコードで33Mbpsで放送しているけれど、x265でslowくらいの設定で放送と同程度くらいのエンコードをした場合だと、
ビットレートはどのくらいまで落とせるものなのだろうか？
あまり変わらないかな？
0168名無しさん＠編集中 (ﾜｯﾁｮｲWW a99b-KbRv)
垢版 |
2019/02/13(水) 00:54:56.63ID:uVRm45c70
33Mbpsでも不足してる(画質維持には50Mbpsは欲しいところ)から何とも…
その上で考えると、放送画質相当なら20Mbpsくらいにまでなら落とせるかもしれない。
0169名無しさん＠編集中 (ｱｳｱｳｸｰ MM91-irfR)
垢版 |
2019/02/13(水) 01:18:01.32ID:qHNoLAniM
>>168
絶対的な画質で言ってしまえばビットレート不足か場面がないわけではないけど、放送としては開始間もない状況では充分なのではと個人的には思っているけれど
で、x265で積めて20Mbpsあたりか…
2年前くらいのNHK BSプレミアムと同程度の保存容量か
やはりAV1かVVCが来ないと保存場所の確保が大変になりそうだな
とりあえずAV1のハードウェア再生支援を早急に整備してほしい…
0171名無しさん＠編集中 (ﾜｯﾁｮｲW 0777-Aoz0)
垢版 |
2019/02/16(土) 16:46:44.53ID:CMtST+2l0
VVCって一番遅いエンコード設定にしたら10Mbpsで4K/24fps出来たりするのかね?
0172名無しさん＠編集中 (ﾜｯﾁｮｲW 5f4b-Fc2p)
垢版 |
2019/02/16(土) 17:18:16.96ID:bdhzcnJr0
何を基準に出来るというか分からないけど前評判ではAV1より縮むはず。
実際個人で試せる所まで来てみないと分からんだろう。
0173名無しさん＠編集中 (ﾜｯﾁｮｲ 87e3-cT+3)
垢版 |
2019/02/16(土) 17:41:33.60ID:lJi5rW/o0
低ビットレートなら半分くらいのビットレートで済むのは有るだろうけど
高画質目的なら H.264/AVC -> H.265/HEVC での圧縮率と同じ4/5程度だろうなと思ってる
0177名無しさん＠編集中 (ﾜｯﾁｮｲ 5fd2-07dM)
垢版 |
2019/02/16(土) 19:17:27.42ID:4sV2ot5Z0
下のをダウンロードして
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
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況