次世代ビデオコーデック総合スレ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が宣言してから立ててください。 フィールド周波数高い60Hzだから、倍速120Hzが効きやすくなる
IP変換でかなり正確にブログレッシブ化出来る
データ量が半減する
実は今時のデジタル技術によって逆に見直されてるのがインターレース >>255
プログレッシブの60Hzも余裕でどんどんプログレッシブ化が進んでるのが実際のとこだと思うんだけど
どういう現場のどんな人達がそういう見直し方をしてるの？ インターレースお払い箱批判が酷くなったのは
まともにI/P変換出来ない安物LCDモニターが売られ始めてから
それよりも葬り去るべきはプログレでも低フレームレートのガクガク映像
あれを有難がってガンガン垂れ流してる人の視覚ってどうなってんだろう 個人的にはフレームレートや解像度を多少下げても
ノイズの少ない映像を流してくれって思う
ビットレートが高いはずの某有料BSチャンネルですらノイズまみれ >>258
最近、BSが1920から地デジと同じ1440になって、ビットレートも地デジ並みに下げられたからな
HDでも圧縮率の低い高ビットレートなら、相当きれいなもんだが >>257
ちょっといいテレビなら問題なくても、安いテレビだと見られたものじゃなくなるな
30pが増えてるのは、4K60pの撮影編集がXAVC class300だと600Mbpsになり、HD60iの50Mbpsの12倍になるから、記録保存も編集も大変過ぎ
てことで、4K30pの300Mbpsでお茶を濁すから 瞬間的に入る紙吹雪パターンに遭遇したら
ビットレート爆上げするなりブロック格子細かくしたり
そういうのに特化して研究してる優秀なヒト誰も居ないのだろうか
もう記録映像より3Dリアルタイムレンダリングコンテンツが
家庭用に作られるようになる方が先かも知れないけど…
それはそれで三船敏郎と越後製菓がチャンバラする新作とか楽しみだけど かのDVDフォーラム vs DVD+RWアライアンスみたいな構図やなｗ 60pと比べたら60iの方が良いけど、
確かに30pと比べたら60iの方が遥かに良いな
時代はiPadですらリフレッシュレート120Hzなのに30pはガクガク過ぎる 60pと比べたら60iの方が良いけど、
↓
60pと60i比べたら60pの方が良いけど、 >>262
つ crf（品質基準）モード
>>264
動きの滑らかさはそうかもしれないけど
画質自体はプログレのほうが断然優れてるから30pのほうがいい
ま、自分でエンコードしない人にはインタレ放送の画質の悪さなんて気づかないだろうけど >>266
60iは60pの半分の帯域で済むし、普通のテレビのI-P変換でそこそこいい1枚映像の画質が得られるし、効率がいいんだよ
XAVCならHDだと50Mbpsの60iと比較して、4K60pとなると600Mbpsになるから、12倍の帯域とストレージ容量を食い潰すしな >>267
なんで>>261と同じ内容を２度繰り返したのかよくわからんが、HDだの12倍だのは本筋とは全く関係なくて、
・4K60pはXAVCだと600Mbpsになって大変。
・4K60pがきつい場合は4K60iか4K30pにしてレートを半分にして誤魔化そう。（それでも300Mbpsだが）
・滑らかさ重視の60iにするか、１枚絵重視の30pにするかは人それぞれだよね。本当は60pが一番いいけど。
ということで、4K過渡期の次善手段として4K60iが選択肢に入ってるというだけでは・・・。
仕方なく使ってるというだけなのを「インタレースが見直されてる」と表現するのは違和感があるな。
4K30pを「お茶を濁す」と表現するなら、4K60iも「お茶を濁してる」ことに変わりはないと思う。
4K放送は60pなんだし。 意外と収録のみの現場ではPsFが活用されてたりするのだ あー、コストや状況等を踏まえてフォーマットを選択するのは当たり前だろうから、
現場でインタレースを使うのが悪いと言ってるわけじゃないよ。
ただ、そういうフォーマット選択って昔からやられてきたことであって、
別に「インタレースが見直されてる」ってわけじゃないんじゃないかなあというか
そのへんの表現で少しモヤっとしただけというか、それだけです。 HEVCでインタレとか何考えてんだ…マジで放送にしか需要無いから ここはPS4proが擬似4Kのために使ってる市松模様方式で…。 西田宗千佳のトレンドノート：iPhoneなどで採用されてる新画像フォーマット「HEIF」とは？
http://u-note.me/note/47508170 綺麗にデインターレースできる映像は
プログレッシブにしても動画サイズはあまり変わらない気がする Multi-Codec DASH Dataset: An Evaluation of AV1, AVC, HEVC and VP9 - Bitmovin
https://bitmovin.com/av1-multi-codec-dash-dataset/
> This scientific evaluation puts AV1 to the test against industry standard codecs
> and shows that AV1 is able to outperform VP9 and even HEVC by up to 40% >>277
ついでにネタ元の１つ前のレスからMediaInfoのAV1対応の件。
https://mediaarea.net/MediaInfo/ChangeLog
MediaInfo change log:
Version 18.03, 2018-03-19
--------------
+ AV1: support of AOmedia AV1 based on latest specifications draft, raw (OBU) and in MKV だったらFirefoxとChromeとEdgeはHEVCに対応してくれるかな？ どうだろうねえ。
今みたいにOSが用意するHEVCデコーダを呼び出すといった実装は可能になるんだろうけど、H.264 vs WebM の時のように
HEVC vs AV1
HEIF vs AVIF ( https://github.com/AOMediaCodec/av1-avif )
という対決構図を作って、最低でもHEVCのライセンス面での更なる譲歩を引き出すためにゴネる気もする。
まあAV1がどこまで使えるかにもよるけど。主に速度面が心配だ。 仕様が固まったということじゃなくて
規格（開発の）凍結なの？ 3000倍の時間かけてまでエンコードするほどの価値あるコーデックではないということ >>283
仕様凍結(freeze)=仕様確定だな ハードウェアエンコーダーが出ない限り、AV1に実用性はない IntelとAMDとNVIDIAの名前があるんだし、HWエンコーダーは出てくると思うぞ >>281
H.264のSiscoみたく特許料を肩代わりしてくれるところが現れない限り難しいと思うな
拡張機能(有料)で対応とかならあるかもしれんが
https://m.srad.jp/story/18/03/19/1052226
＞現状、HEVC/HEIFはエンコード・デコードに特許使用料を少なくともMPEG LAと HEVC Advance に支払わなければ
ならない
Apple は iPhone の中に特許使用料を織り込める。
Android P は端末メーカーが使用料を支払えば良い。
Microsoft は
どうやらHEIFのデコードにはユーザに 120円を Windows Store で
支払わさせることで解決するみたい >>277
＞現在の計画によると、コーデックの仕様は今年の7月にインターネット標準として採用される予定です。
漸くか >>293
ああ、>>280は「AV1が諦めた」と勘違いしてたのか・・・。意味を取り違えた。
>>282はブラウザのHEVC/HEIF対応可能性について書いただけであって
別にAV1の「凍結」を開発中止だと勘違いしたわけじゃないんだけど、
確かに流れだけ見ると勘違いしたように見えてしまうな・・・。
>>281
書き忘れたけど、Edgeは既にWin10FCUで
「デバイス製造元からのHEVCビデオ拡張機能」(HEVC Video Extension)
が入ってればHEVC動画の再生ができるよ。 民生機でも実用的な時間でエンコードもできるコーデックと
少しでも画質容量比を良くするためにエンコに死ぬほど時間がかかるけど
莫大な帯域を消費する配信業者用の業務用コーデックかという話で
どっちが勝ったり諦めたりという話ではないと思うぞ
どのみちAV1は俺らが気軽に扱えるものにはならんだろ これまでAviUtlやAvisynthのプラグインの開発者ですら
もうTSやBD,DVDのソースをカットしてフィルタ掛けてエンコードしてって作業に飽きてほとんどエンコードしなくなったと言ってるからねぇ...
ストレージが大容量化したからTSのままでもスマホやタブレットに転送して視聴した方が楽になったんだと
HEVCはQSVのHWエンコーダがそれなりの速度でまあまあの品質だしAppleのお陰で再生環境も揃ってきたし
コンシューマはHEVCを選んでおけばいい気がする BDはさすがに30G超えてくるからエンコ必至だろ。
インタレソースなら解除が面倒だしなぁ…
とりあえずインタレは早く廃れろ インタレ解除は例のHWインタレ解除フィルター使うか、レコーダーからのキャプチャーならばレコーダーで解除 MX150搭載なら安いのはLenovoのideapadあたりか
それでも9万コースだけど
そもそもモバイルで単価の低いCPU積んでるモデルな時点でdGPUなんぞ積まないから、dGPU積んでる時点それなりにするんだよな
そのうえHWデコーダと違ってGPUブン回すから綺麗に処理出来てもバッテリ保たないだろうなぁ 動画エンコードを10万円以下で考えている人はクオリティーなんぞ求めるべきではない avisynth+対応プレイヤーでリアルタイムフィルタ処理すればいいという話だぞ >>307
なんでボカしてるのか知らんけど、例のフィルタってnekopanda氏のD3DVPだよね？
https://github.com/nekopanda/D3DVP
これは「GPUでインタレ解除してプログレッシブでエンコードしたい場合」に使うもの。
インタレソースを再生する場合は普通にレンダラがGPUを使ってインタレ解除するんだから、
再生時にわざわざAvisynth+使ってリアルタイムフィルタ処理なんてする必要ないと思うんだけど。
インタレ解除したものをBlueskyFRCに渡してフレーム補間したいとかなら別だが・・・。
というかインタレ解除とかの話はAvisynthスレとかTSスレとかでやった方がいいと思うよ。 動画の世界は常に流動的だという意識が充分ではないようだな
時代は今後、インターレースからプログレッシブへと潮流が変わっていくことになる
そうすると、やがて再生時にインタレ解除しようにもクオリティーの高いインタレ解除技術が使えなくなっている可能性が高くなってくる
それならばインタレ解除技術が充実している今のうちに解除してからエンコードしておけば、後々インタレ解除のクオリティー問題に悩まされなくて済む
それに再生時にインタレ解除する前提では、再生する環境に依存することになるから、古いPCや安物のプレーヤーを使って再生する必要が出た場合にも、
満足いく再生ができない問題に悩むハメになる そんな大袈裟な意識持ってるなら、現存する手法よりも
高度なインタレ解除技術が登場する可能性も考慮したほうがいいのでは。 https://twitter.com/bitmovin/status/978153380311805952
> Hi! Indeed, we have no information that the codec is finalized.
> Bitmovin codec engineers have been working with AV1 for over a year
Bitmovin社は「AV1の仕様が確定したなんて話は聞いてねーぞ」っつってるな。 >TSのままでもスマホやタブレットに転送して視聴した方が楽になった
君ってすぐ騙されそうだね >>310
確かに
エンコードした後でより優れたインタレ解除が出てきたら後悔しそう
つーか放送がインタレな以上、当分インタレはなくならないでしょ
4K放送は一般に普及するとは思えないし インタレ解除については、これ以上の進化は期待しにくい
あるとしても時間をかけて演算するディープラーニング系にわずかに可能性はあるが、再生時のリアルタイム処理に使うには不向き >>308
D3DVPはavisynth+じゃなくても動くことを考えると
KTGMCのことをいってるのでは >>312
どう考えても実際にやったことない奴だな
一応TSのままハードウェアデコード＆ハードウェアデインタレースで再生できるけど、
60pじゃなくて30pになるのでカクカクで使い物にならん（Android＆Snapdragonの場合、iPhoneは知らん）
だいたいWiFiなんて11acでも有線GbEより遥かに遅いし時間掛かって面倒
それこそQSVとかでハードウェアデインタレース＆エンコードしといた方が楽 最近の流行りはサーバ側でのリアルタイムエンコードでタブレット等での視聴
つまりネットワーク負荷は依然高いからエンコードが使われるわけで BDは気に入ったのしか取ってないからm2tsのまま取ってるけど、ゲームの録画は可逆だから編集後にエンコしてるわ。
でないと1時間で500GBとかになるし 16K無圧縮の帯域を実質スループットで通せるくらいネットの帯域が拡大するまでは廃れないんじゃね？ >>323
アホですか
どんなコーデックでも成り立つよそれ 物理的に無理やろな
データをテレポートで遅れるくらいにならないと サイトがリニューアル AV1のロゴマークが出来てる！
https://aomedia.org/ もう開発者は開発を始められるんだな、俺は無理だが
エンコード速度はどんなもんなんかね HEVCだってリファレンス実装のHMとx265では数百倍は速度が違うのでAV1もこれから多少は最適化されていくと思いたいが でもそもそもの計算の複雑さがHEVCの10倍とかあるんでしょ?
特許に引っ掛かるので仕方ないといっても流石に酷いように思う AV1始動アナウンス来たみたいだ。
https://twitter.com/a4omedia/status/978981295106781184
We’re excited to announce the launch of #AV1!
#AOMedia is ushering in the royalty-free, UHD web video era.
22:05 - 2018年3月28日
The Alliance for Open Media Kickstarts Video Innovation Era with “AV1” Release ? Alliance for Open Media
https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/ なんかロゴが折り紙のように見える
もしかして折り紙的な技術が使われてるとか？ 放送に採用されないコーデックは、どこまでいっても中途半端
ライセンス逃れを開発理由の一つにしている時点で、自ずと限界は来る aomのコードはまだリリースタグはついてないのか。 標準品質で同じ動画を変換するとx264よりx265はどんだけ遅いんだ？ ストリーミング時代に放送がどこまで生き残れるかっていう問題が >>342
そんなんソースや設定とかによるからなあ。
とりあえずベンチマークスレで色々な環境での結果を見てくるといいんじゃないだろうか。
【x264/x265】実用エンコベンチ Part6
http://egg.5ch.net/test/read.cgi/jisaku/1507728392/ 俺のRyzen3 2200GだとフルHDの30fpsの動画でx264で20fps、x265だと5fpsくらいしか出なかった記憶がある。まあ普段はHWエンコードしてるんだけど もう、昔より半導体の微細化のペースとか遅いんだから、
解像度上げるペースとか新しいコーデック開発するペースも遅くしろよ。 >>342
同等の量子化係数でブン回しても6倍以上は重くて、売り文句みたいに2倍も縮むのは希で2/3ぐらい >>336
Appleからの歓迎コメントがない・・・ >>347
自分環境かつ自分がよくエンコするソースでベンチ取った時
x264のslow?slower?よりx265のfastの方が1.3倍速くて1.6倍程度ビットレート比で綺麗だったから重用してる。
ソース次第やね >>348
Founding Membersの中ではIBMのコメントも無いね。
Appleは入ったのが今年１月だし、まだ様子見ってのもあるのかもね。 https://twitter.com/tmvn/status/979038621746413568
> Also, @JonatanDivideon made a mistake on his chart, and everyone keeps reprinting it.
> The Fraunhofer HEVC patents were purchased by GE Licensing. They're in the HEVC Advance pool.
>>340の記事でも引用されてるHEVCのパテントライセンス図に Tom Vaughan 氏がコメントしてた。
FraunhoferのパテントはHEVC Advanceに参加してるGE Licensingに買収されてるそうだ。 >>349
そりゃプロファイル変えていればね
プリセットを変えればH265のコア部以外の「x265やx264が実装している工夫の部分」で重さが大きく変わる >>352
プロファイルじゃないや、プリセットだね x265については、プリセットから速い方から2つめのsuperfastと3目のveryfastの間で、3割ぐらいと大きく画質容量比が悪化するので、
有る程度処理の速さを求める場合でもultrafast〜superfastは止めて、veryfast以上、出来ればfaster以上を設定ベースにするといいと思う
crfベースでx264とx265のSSIMを比較した場合、crf 23あたりからSSIMの開きが広がる
画質劣化が知覚できるとされるSSIM 0.985を割り込まなず直近上位になるcrfは、x264はcrf 26、x265ならcrf 28になる
x264でcrf 25、x265でcrf 27の場合だと双方ともギリギリでSSIM 0.985を下回るぐらいになるので
放送波ソースで画質保持ならcrfの設定はここらへんが妥協の境界になりそう ■ このスレッドは過去ログ倉庫に格納されています
