次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
レス数が1000を超えています。これ以上書き込みはできません。
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が宣言してから立ててください。 IBMが量子コンピューターの販売始めたし、コンテンツインフラ提供してる巨大企業が
エンコードはがっつりやってくれるようになって、エンコード負荷軽減自体があまり
研究されなくなっていき、デコード効率重視になっていく近未来が見える気もする
5Gやそれを超えるような広帯域通信が普及すると、いま3DCGでレンダリングプールを
インターネット越しに企業が提供してるように、動画エンコードも素材データ送って
でかいサーバーに任せてしまうということが可能になってくるし
(超広帯域通信が普及しても4K8Kなどの高解像度化や高画質化の余地がたくさんあるから
圧縮技術のニーズがなくなる未来はまだ遠いと思う)
そうすると著作権破ってる奴らははねられてしまうから、自分でコンテンツ生み出してない奴らは
絶望することになってこのスレも過疎るんだろうな ハードウェア再生支援が対応してもソフトウェア側が充分に活用できていなかったり、ソフトウェアによっては初期設定のままだとハードウェア再生支援自体が無効だったりとか、対応がまちまちすぎて困る
例えば、Windows10標準の「映画と
テレビ」は、ハードウェア再生支援自体は使えるのだが、動きが微妙にではあるがなめらかでなくなる瞬間を見かける
高画質な再生をするのに使われるPotPlayerなんかだと、ハードウェア再生支援を使えばなめらかに再生はされるのだが、デフォルト設定は無効になっていて、しかも設定項目がどこにあるかがわかりにくい
(PotPlayerの場合、音声の設定がデフォルトで正規化処理を有効にしているのも問題ではあるが。
正規化処理を有効にしていると、再生するファイルによっては音声にプツプツというようなノイズが混じることがある。) 最新のCODECって、時間軸は何秒も深く圧縮してる?
つまりハードが出来て最適化されようとも、確実に数秒以上の遅延が起こる? MediaKind-HEVC-and-AV1-whitepaper_FINAL.pdf
https://www.mediakind.com/pdf/MediaKind-HEVC-and-AV1-whitepaper_FINAL.pdf 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) x265 3.0 がリリースされ、それに対応した x265guiEx 3.92 もリリースされた。
x265のリリースノートは現時点ではまだ2.9のままなので、3.0の内容については当面は2つ目のリンクから。
https://x265.readthedocs.io/en/default/releasenotes.html
https://bitbucket.org/multicoreware/x265/src/a6a12bc3ccf4b3138f1d62b2a81c9c40c3c88d62/doc/reST/releasenotes.rst
詳細は直接見てもらうとして、意識しとくべきなのは以下の3つあたりかな?
・--preset slowerのパラメータ変更があり、従来のveryslowと同じになった。
その上でveryslowにいくつかパラメータ変更が入った。
・--aq-modeのデフォルト値変更。 「1 : uniform AQ」 → 「2 : auto variance」
・--tune animationの追加
あとはDolbyVision対応とか、--hevc-aq (これが以前話に出てた新しいAQ?)の試験実装とかかな。
リリースノートに書かれてない新オプションとして、--[no-]-hrd-concat というのもある。 >>958
どういう影響が出るのだろう
>>960
… HDR対応に向けた実装開始って感じかと(仕上がるのはまだ先 x265って、いまのところHDRには対応していないんだっけ? HDR対応と言ってもエンコーダーであるx265のやることは、
・グレーディング済みのHDR映像データを受け取って
・適切にメタデータを付与してエンコードする
ということだけだと思う。
ざっくりとしか理解してないけど、
・単純なPQ方式やHLG方式なら --colormatrix や --transfer の指定だけでも済む。
・HDR10なら、--master-display とか --max-cll とかも使う。
・HDR10+なら、--dhdr10-info でダイナミックメタデータを渡す。
・Dolby Visionなら今回追加された --dolby-vision-profile や --dolby-vision-rpu を使う。
といった感じじゃないだろうか。間違ってたらすまん。
ちなみに、rigaya氏のx265バイナリだと、HDR10+用の --dhdr10-info や --dhdr10-opt が使えない模様。
ビルドする際にCmakeで ENABLE_HDR10_PLUS を有効にしていないものと思われる。
(個人でHDR10+やDolbyVisionのエンコをする人がいるのかどうかはわからんけど・・・) ・SDカードやUSBメモリを、テレビなどに直接つなげる4K対応メディアプレーヤー「400-MEDI023」
https://www.mdn.co.jp/di/newstopics/63539/
リモコンつきのこんなプレーヤーが普及すると、HEVCエンコードした動画を見るのが捗って助かる >>967
HDRは多分対応してないとして、
・10bitのファイル(HEVC/H.264/VP9あたり)が再生できるのか
・HEVCなら4K対応とあり、それとは別にHEVCなら60fps対応とあるけど4K60fpsも再生できるのか
(ちなみにVP9だと30fpsとなっている)
といった点がいまいち曖昧だね。
こういう機器ってそういうことが多いからいまいち手を出す気になれない。 http://rockchip.wikidot.com/rk3229
それSoCはRockchipのRK3229らしいから10bit60fpsにも対応してるかもしれん OEM元と思われる中国の奴はそうみたいだったけど
こっちのやつがそうなのかまではわからんけども androidSTBの10bit対応ってH.264の10bitのみ対応とか、H.265の10bitのみ対応とかいろいろあるよね。
FireTV4K(旧箱) + KODIでH.265の10bit再生環境用意したけど、FireTVのアップデートのせいでスムーズに再生しなくなったよ。TV3台あるからFireTV4K 3台用意したのに・・・
結局、未だにRPi3 + LibreELEC でH.264・・・ VVC陣営
http://www.mc-if.org/
ライセンス等の改善に取り組んでゆくらしい
公式twitter
mediacoding_if@mediacoding_if 消費者がテクノロジーに対して敬意と対価を払わなさ過ぎ
文句ばっか言いやがってちゃんと金を払えよ 無料で使えて当たり前ってスタンスの消費者の方が上から目線過ぎるだろ
仮に対価払っていたとしても消費者と技術提供者は対等な立場であるべき
いまの消費者側が技術提供者に対するリスペクトが無さ過ぎる現状は酷い コーデックに関してはコンテンツや再生機器購入時にライセンス料を間接的に払ってるし意味不明なんだが VVCはイントラ内予測も強化されるが、仮にこれを静止画フォーマットに使っても低ビットレートで綺麗になるだけでSSIM 0.95以上を目指す場合はJPEGと大してファイルサイズが変わらないというこれまで通りの流れになりそうな予感がする コーデック自体とは関係ないけど、いつかYCoCgが標準になれば良いのにな
互換のためにYCbCrを続ける事で更なるYCbCrコンテンツを日々生み出し続けて完全に負の連鎖になってる
コーデックの仕様的にサポートはされてるんだから放送業界かあるいはNetflix, YouTube, Hulu級の規模のどこかが使い始めないと永遠に普及しない やり方を変えるだけのメリットを見出してないんだろ、現状
数式みたいにカッチリ変換できないと使い物にならないというわけでもないし YCoCgって式が1/4単位になって計算コストが下がるだけかと思ってた
ロスレスでビット数増やせば無損失でRGBに変換できるのかな >>986
そう
>>985
YCbCrだと8ビットカラーの場合RGBとの変換だけで75%の色が失われて、400万色程度しか表現できない ビット数増やすのも計算途中だけで良い
入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる ワッチョイの付け方がわからん
誰か代わりにやってくれ メール欄に「watch-owyyy!!!」って書けば付くお 次スレ
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1548833021/
一応即落ち防止のため20レスまで保守っとく。
ちなみにこの板はワッチョイはデフォでつくので面倒な指定は不要。 >>984-988
> ビット数増やすのも計算途中だけで良い
> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる
色々調べてみたけど、「nビット深度のRGB」をYCoCgで【無損失】で表現するなら、
・「YCoCg」の場合
Y/Co/Cgともに(n+2)ビットの深度が必要。
Coだけは(n+1)ビットの深度でもいいけどCoだけ減らすようなことはしない。
・「YCoCg-R」の場合
Yはnビット、Co/Cgは(n+1)ビットの深度が必要。
という感じで、YCoCgの方が必要なビット数が多くなるのでは?
計算途中だけじゃないと思う。 今だ!!!1000get
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ (´´
∧∧ ) (´⌒(´
⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
 ̄ ̄ (´⌒(´⌒;;
ズザーーーーーッ このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 195日 5時間 43分 20秒 レス数が1000を超えています。これ以上書き込みはできません。