次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
レス数が1000を超えています。これ以上書き込みはできません。
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が宣言してから立ててください。 ■各ビデオコーデックの概要や状況（2019年1月下旬時点）
●H.265/HEVC
H.264/AVCの後継規格。放送やUltra HD Blu-ray等で採用が進んでいるが
３つのライセンスプールが並立するなどライセンス面での問題も抱えている。
H.265/HEVC特許暗黒時代
https://qiita.com/yohhoy/items/c2579097a507b1fbdddb
HW再生支援のサポートは進んだものの、FirefoxやChromeでの対応が進んでおらず、
ネット配信では使いづらい状況が続いている。(スマートTV向けの配信等は除く)
AppleがHLS(HTTP Live Streaming)やiOS 11やmacOS High Sierraで採用したり、
2018年3月にライセンスプールの１つであるHEVC Advanceが
コンテンツへのライセンス課金を取りやめたりといった好材料も出てきてはいる。
●VP9
Googleによって開発されたロイヤリティフリーのコーデック。
ブラウザ(Safariを除く)やHW再生支援のサポートも進み、主にYoutubeで採用されている。 ●AV1(AOMedia Video 1)
Amazon/Cisco/Google/Intel/Microsoft/Mozilla/Netflix等が中心となって立ち上げた
Alliance for Open Mediaによって開発されたロイヤリティフリーのコーデック。
VP10/Daala/Thorの技術を受け継いでいる。
2018年3月末にリリースされたが、v1.0.0の仕様確定は2018年6月末にずれこんだ。
HW再生支援のサポート等も含めた本格的な普及は2020年頃になる見込み。
コンテンツ配信/ハードウェア/ブラウザ系などの主要企業がサポートを表明しており、
ネット配信を中心として広く普及することが期待されている。
●VVC(Versatile Video Coding)
H.265/HEVCの後継規格。2020年10月の標準化を目指して
JVET(Joint Video Experts Team)で検討が進められている。
また、H.265/HEVCのようなライセンス問題を繰り返さないため、
MC-IF(Media Coding Industry Forum)という業界団体が立ち上がっている。
http://www.mc-if.org/ ■各社GPUのHWエンコーダでのH.265/HEVCおよびVP9のサポート状況(2019年1月下旬時点)
●Intel QSV (Kaby Lake/Coffee Lake＋Intel Media SDK 2018 R2)
〇HEVC
mainおよびmain10。Bフレーム使用可。
〇VP9
・LinuxでVA-APIを使えばKaby Lakeで利用可能らしい。
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
・Intel Media SDK for Windows 2018 R1で、Cannon Lake向けの
プレビュー機能としてVP9エンコーダ関連のAPIが追加されたので
Cannon LakeからはWindowsでも使えるようになるかもしれない。
●Nvidia NVEnc (Turing＋NVIDIA Video Codec SDK 8.2)
〇HEVC
mainおよびmain10。TuringでBフレームに対応。
〇VP9
未対応
●AMD VCE (Polaris＋AMF 1.4.9)
〇HEVC
mainのみ。main10は不可。Bフレーム使用不可。
〇VP9
未対応 ■AV1のエンコーダ/デコーダ実装の例
●エンコーダ
xiph/rav1e: The fastest and safest AV1 encoder.
https://github.com/xiph/rav1e
●デコーダ
VideoLAN / dav1d - GitLab
https://code.videolan.org/videolan/dav1d ↑一応テンプレここまで。
テンプレの変更点は以下の通り。
・各コーデックの参考リンクを>>2に移動
・諸々の状況を2019年1月下旬時点にあわせて更新
・VVCの説明にMC-IFのことを追記
・HWエンコーダの説明で、SDKのバージョンを更新
・HWエンコーダの説明で、TuringでのHEVC Bフレームサポートを追記
・>>8にAV1のエンコーダ/デコーダ実装を追加
Youtubeの一部の動画でAV1がテスト採用されてるといったことも書いた方が良かった気もするし
他に書くべきこともあったかもしれないけど、スレ立てを急いだほうがよさそうだったのであまり変えてない。 「Firefox 65」が正式公開 ～トラッキング保護を改善、WebP/AV1をサポート - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1167182.html
・WebPのサポート（image.webp.enabled＝true）
・AV1がデフォルトで有効になった。（media.av1.enabled＝true）
・dav1dデコードはデフォルトだと無効っぽい。（media.av1.use-dav1d＝false） 誰もMac mini 2018のHEVCエンコードのレポートしてくれないな
俺がやるしかないのか あ、持ってるよ。低ビットレートだとやっぱx265のがずっと綺麗です。1080p60時に20Mbpsとか大盤振る舞いをするなら大して変わらないから便利です
例えばPS4のゲームをHDMI経由でキャプチャーしてソース動画がある場合なんかはx265で重めのプリセットで10Mbpsくらいでエンコしても劣化が目立つのでどのみち20Mbps程度は必須。このビットレート領域だとAppleのも悪くはないです ちなみにFFmpegでもCompressorでも出来ることは殆ど一緒でカスタマイズ項目は少ない。2パスエンコは不可能 量子化係数のより高い状態でのエンコードで、如何に画質の劣化を軽減するか
それを如何に効率よく処理するかがエンコーダ性能の優劣だからな
高ビットレートを容認すればするほど前者が問われ無くなるから、そりゃ差は縮むわな まー1080p60で10MbpsでもSSIM 0.01違いとかそんなもんです
Compressorから圧縮するとちゃんとBフレームも使う
13500フレームの動画でx265だとBフレームが9900程度、T2だと9500程度になった
リアルタイムエンコーダーとしてはそこそこ優秀だと思いますよ フィルムグレイン多い実写だとx265でもダメダメだなあ
エンコ時間かかりまくるのに全然縮まない
アニメ専用かよ グレインとかCMOSの暗部ノイズはランダムノイズなので動き補償と相性悪すぎるからしょうがない
砂嵐をエンコードしてるようなもん デジタルシネマは圧縮電送して、シネコン側で指定されたフイルムグレイン(KODAK何番とか)足して再生すると、何かで読んだけど
確かに圧縮効率を考えたら、ある程度フィルターでグレイン取って圧縮して、再生で足すのは考え方としてはアリか 「8K」の普及促進や規格化を担う団体「8K Association」が発足。
ttps://www.4gamer.net/games/999/G999902/20190130060/
Chinock氏は，8Kエコシステムを回す追い風として，「HDMIやDisplayPortなどの映像インタフェースは，8Kへの対応が完了していること」と，
「同品質の映像を，H.265の半分のビットレートで圧縮可能な次世代コーデック『H.266』の開発が進行中であること」などを挙げていた。 >>30
シーンごとカットごとでの指定はできるんかね？ 映画制作側は「俺の創った映像と違う」とか言って拒みそうな機能だな
24p→60pも否定的だったし >>34
トム・クルーズが「勝手にコマ数増やすな」と、テレビやと視聴者に文句言ってるのなw >>32
メタデータで指定してるんじゃないかな
>>33
あ、AV1か
ありがとう >>38
インストールさえできればHW非対応の構成でも再生できるんだよなぁ コーデックもそうだけど、動画まわりのAPIもどうにかしてほしい。もっと洗練されたクロスプラットホームなやつを.. windowsにしたって>>35は古いDirect ShowフィルタじゃなくてMedia Foundation用のコーデックだろ。MS純正のアプリはMedia Foundationに移行してると思うが、サードパーティーでMedia Foundation使ってるるプレイヤーってそんなにあるのか? >>41
MS純正のアプリ使わないならLAV Filtersで事足りるからなあ・・・
MediaFoundationを意識するプレーヤーなんてQonohaくらいしか知らん・・・ 動画APIがクロスプラットホームである必然性なんて微塵もない
何をやってもHDTVとPCのガンマを同一と見做して変換してくれない糞プレイヤーが多いままなのは永久に変わらない 動画がらみのAPIがクロスプラットフォームじゃなかったら、ffmpegがanroidかwindowsかどちらかでしか動かないくなるんだけど。
vlcやらも大変。
ffmpegのlibavやらlibavformatやらがクロスプラットだから、後はUIのがわをだけ作ればいいように楽できるんだけど。
libavとかカオスだし、gstreamerはまだましっぽいけど。 Direct Showは、いずれ廃止になるんだから、さっさと移行しろよとは思うが、動画の世界は古い技術にしがみつきたがるやつが少なからずいるのが癌ではある AV1拡張入れてもWin10のWMPでAV1動画が再生できなかったからMFとはまた別かと思ってた BlueskysさんのDSF/MFT Viewer（DXVACheckerにも内蔵）を使うと
DSF(Direct Show Filter)やMFT(Media Foundation Transform)の一覧が見れるから見てみるといいかも。
https://bluesky23.yukishigure.com/DsfMftViewer.html
https://bluesky23.yukishigure.com/DXVAChecker.html
うちは>>38くらいしか入ってないけど、Media Foundationの方に
HEVCVideoExtension(デコーダ)
HEVCVideoExtensionEncoder(エンコーダ)
がある。
A's Video Converterで選べるMicrosoft H.265 Encoderは後者を使ってるのかな？ 宮廷ドラマ「H.265/HEVC華麗なる軌跡」
2014年、MPEG-LAがパテントプールのライセンスを発表
2015年、パテントプール分裂、HEVC Advanceが爆誕
2016年、Technicolor社がHEVC Advanceを脱退
2017年、第3のパテントプールVelos Mediaが爆誕
2018年、Technicolor社がパテントトロールInterDigital社に特許権売却
2019年、パテントトロールのBlackBerry社がVelos Mediaに参加←New! こういう利権とかうるさいのって日本だけかと思ってたけど、やっぱ世界でも似たようなもんなんだなって思う ライブ配信向けのエンコーダか
1080pで最低16GB必要とはなかなか重いね AVIFはどうなってるのかな
なんかwebpより画質悪いみたいだけど 画質を気にするならJPEG 2000にしとけば？
HEIFもだけど動画のイントラ系は高画質寄りだとあまりメリットない HEIFって4:4:4無いの?あるなら互換性を除けば非可逆で最もベターに思えるけど 画質保ちたいならpng使うもんな
ほとんどの人はそれなりの画質で高圧縮を求めている >>55
VP8ベースのwebpよりVP9後継のAV1使ったAVIFが画質悪いの？ >>58
iOSで4:4:4 HEIFで保存するサードパーティアプリあるので、出来るといえば出来る
OSデフォルトのカメラは4:2:0だけど 何よりもクソなのはmacOS MojaveだとHEIF Losslessが追加されたのに実際は何かロスる。
たぶん4:2:0に変換された物がロスレスでコーディングされてるw 4:4:4でもYUVだとロスりそうな気が
ロスレスならGBRでしょ >>64
10bit12bit使えるはずなのでそれら使えばロスらない
でもこの辺ちゃんと対応してるのかね >>66
デュアルレンズiPhone専用で高額レンズのシミュレーションを行うFocosっていうアプリ
この手のアプリでは圧倒的なクオリティで専用ハードを使うLight L16より綺麗 >>65
ロスレスで深度深くしたらRGBのままより圧縮効率落ちる。つまり、ただのzip圧縮と変わらないPNGに負ける
ロスレス最高効率のFLIFは8bit深度のままロスレスYCoCg変換しててこれが正解。HEVCだってYCoCgに対応してるのにやらない所がクソなんですよ >>63
422から420って、色の2が0にロスってるけどw
それロスレスって言っていいのか >>68
なるほどぉー
これは勉強になった
RGBよりdeep色向けな最適化軸が
YCoCgなのかな？
ぐぐって勉強してみよう >>68
> 8bit深度のままロスレスYCoCg変換しててこれが正解
微妙な表現だけど、前スレ938での
> ビット数増やすのも計算途中だけで良い
> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる
といった書き込み内容も踏まえると、
「8bitのRGB」と「8bitのYCoCg」は相互に可逆変換できる
と考えてるように見えるけど、それは違う。
前スレが終わる直前
https://mevius.5ch.net/test/read.cgi/avi/1532001049/996
に書いたから見てないかもしれないけど、「8bitのRGB」を可逆変換するなら
YCoCg側は「10bitのYCoCg」か「Y8C9bitのYCoCg-R」が必要になる。
一般的に有用なのは後者の「Y8C9bitのYCoCg-R」。 >>68
YCoCgには、基本として「YCoCg」と「YCoCg-R」の2種類があって、FLIFが使ってるのは「YCoCg-R」。
元が「8bitのRGB」の場合は、「Yが8ビット、Co/Cgが9ビットのYCoCg-R」に変換して、それを圧縮している。
（「YCoCg-R」は、Co/Cgが1ビットずつ増えるけど、可逆性を持ち、かつ圧縮効率が良い）
YCoCg(-R)を入出力に使うH.264/H.265と違って、
FLIFは入出力はRGBで、内部計算でYCoCg-Rを使ってるだけかな。
符号なし整数にするんじゃなく、符号つき整数として扱ってるようで、
8bitRGBの場合、R/G/B/Y：0～255、Co/Cg：-255～255という値範囲で扱われてる模様。
https://flif.info/spec.html >>68
H.264/H.265は「YCoCg」も「YCoCg-R」も規定されてるけど、
・x264/x265では
色差の深度 = 輝度の深度 + 1
というエンコード処理ができないはずなので、
YCoCgの本命である「Y8C9bitのYCoCg-R」は使えない。
対応しているエンコーダ/デコーダがあるかも不明。
・じゃあ非可逆になってしまうけど圧縮効率向上に期待して「8bitのYCoCg」を使うぜ！
→他のYCbCrと同様に、400万色くらいしか表現できないよ。
→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
→4:4:4限定なら有用かもしれない。
（続く） >>68
（続き）
・じゃあ可逆性を重視して「10bitのYCoCg」を使うぜ！
→でも8bitRGBをエンコするために10bitYCoCgを使っても
圧縮効率の向上はあまり期待できないらしい？
→「8bitのRGB」をそのままエンコードした方が圧縮効率が良いのでは？
→「10bitのYCbCr」も8bitRGBと可逆性があるはずだし、そっちでもいいのでは？
→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
→4:4:4限定なら有用かもしれない。
という感じで、現状実用できる範囲ではあまりメリットが無さそうな感じ。 >>68
更に、仮に今後x264/x265で「Y8C9bitのYCoCg-R」が使えるようになったとしても、
H.264/H.265の規格では
・「YCoCg-R」が使えるのは4:4:4だけ。
と規定されている。
・4:4:4の可逆性確保および圧縮率向上
というメリットは得られるので、4:4:4のHEVCやHEIFの圧縮率の向上には有用かもしれないが、
4:2:2/4:2:0では使えないため、4:4:4動画が一般的にでもならない限り、
「YCoCg-R」が一般的に使われることもなさそう。
階調的には10bit/12bitのYCbCrで十分だし、視覚特性を踏まえたICtCpってのもあるみたいだし、
そのあたりを考えると、x264/x265等のエンコーダやデコーダが
わざわざ「YCoCg-R」に対応する可能性も低そうな気がする。
という感じでYCoCgについて調べたことをまとめて連投してみたのだけど、
理解が正しいかよくわからんとこもあるので、指摘があればよろしくたのんます。 いいよ。ここでやればいい。興味なければスルーするだけだし。 libvpxアップデート来てるやん
エンコードが速くなったらしい
テストはしてないけど >>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" --auto-alt-ref=0が無効で1が有効だと思っていた。
6ってどういう意味だろう？ >>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; WEBPでPNGをロスレス変換したときのファイルサイズの減少率に感動して
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…
たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな 他人エンコならAAC128でも気にしないけど自分エンコの320とWAVは異様に気になって識別しちゃうみたいな所あるよね。
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする >>85
WebPのロスレス、実はロスレスじゃないという話があるけどどうなんだろう >>87
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー
と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年～2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う こっちのirfanviewとXnViewではちゃんとロスレスだった 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設定のまま保存されていたようだ windowsの仕業だったのか
Macだとどうなるんだろ なぜに管理者・・と思ったけど
圧縮率の情報をレジストリにでも書き込む仕様なんだろうか？ GIMPでHEIF/HEIC保存できるのを知って>>90の16777216色画像でlossless変換してみたけど
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな
ファイルサイズもWEBPの181kB->12.7kBに対して12MBまで膨れ上がってたし
少なくとも現時点のバージョンでlossless厨の自分がHEIF/HEICのお世話になることはなさそうだ
このスレ見といて本当によかった 詳しい人ありがとうございます
数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな それほど大量にPNGを扱っているなら場合によってはBMPにして7zとかzpaqなどのアーカイブに放り込む方が縮むかもしれない
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな… 最新のAcrobat Pro DCでHEIC開けなかったわ
PDFってまだHEIF埋め込める仕様になってないん?(´･ω･`) pngcrushで事足りてるな...
(もっと効率良いPNG再圧縮プログラムもあるけど、デフォルトでメタデータが保持されない物が多いのでpngcrushが安全 MicrosoftのHEIF画像拡張機能を入れてテストしてみようとしたら
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀) PNG最適化ならzopflipngが今のところ一番縮むはず zopflipngのコマンドラインは残すチャンクを手動指定しないとメタデータを軒並み消される メタデータまで含め非破壊で安全である事と、速度と圧縮効率のバランスの良さでpngcrushの標準(-bruteとか指定しないで普通に使う)は使い勝手が良い HEIF画像拡張機能、なんかインストールできねえなと思ったら
Windows 10 バージョン 17763.0 以降 （October 2018 Update～）
になっとるやないかい・・・。まだApril 2018なままのうちでは無理か・・・去年さっさといれとけばよかった。 >>98
ECTやpingoのほうが縮むぞ
圧縮速度も何倍も速いしメタデータも残る > 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変換でも色情報間引かれたりしないんだろうか >>103やってみたけどサイズがPNGより膨らむ上にirfanviewでも開けないしよくわかんないっすね…
jpeg2000より圧縮率高かったら置き換えられるかなと思ってたけど厳しそう >>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をロスレス保存することはできない。
という感じだと思う。 ■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付与： 無し ■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として扱えとでも言うのだろうか・・・ 画像系のソフトって色域の管理できてないのが多いからねぇ
というか、そもそも色域管理の術を知らないんじゃないのかとさえ思う 率直な質問だけどHEIXなHEIFって拡張子は.heixになるの？それとも.heif？ 次世代ビデオコーデックのスレで画像コーデックの話何時までやるの？
話題ついでレベルなら全然かまわんと思うけど
ゴリゴリ続けられてもちょっとな 次世代画像コーデックスレが必要になってきた感じですかね HEIFやWEBPみたいに静止画と動画の変換コーデックに同じものが使われる傾向が続くと
将来的には「昔は静止画専用のコーデックがあってさ～」みたいな話になるんだろうか どんどん続けてOK。俺はどうでもいいかスルーするけど >>109
.heic
HEIF Technical Information - High Efficiency Image File Format
https://nokiatech.github.io/heif/technical.html >>114
heixでも.heicなのか
サンクス 低スペックマシン(Windows10/AMD E1-7010 APU/RAM4.0GB)でYouTubeを720p/AV1設定にして視聴したんだが感動を覚えた。
Dropped Frames 683/5960 11.5%位落ちてるけれどこんな低スペックPCでchromeブラウザのAV1デコーダー凄い軽さだなぁと。 >>118のCPUってcine bench15 マルチコアで70しか出ないのかよ…ちなみに9900Kが2000ちょい
仮にスコア100でフルフレーム出るとすると4コアCPUでも4K画質のソフトウェアデコードギリギリ出来るな。
デコーダの並列度が高ければ。 >>117
実際に落ちまくったのは最初の方やな。その後も落ちてたけど見られないほどひどくはない印象。 シーンによって再生負荷が変動してる気がするんだが
再生負荷が高そうな動画だとどうなるんだろう つか、デコード負荷って結構あるんだね。今まで馬鹿にしてたわ。
2Kから4Kになれば負荷4倍なのは分かりやすいけど最近2Kの30fpsのmpeg2動画とh.264の動画をFireHD10でCPUで再生したらmpeg2こんな軽いんだね...
h.264だと再生ギリだわ。
最新コーデックってのはエンコ側ですげぇ頑張って、デコード側は大した変わらないのかなと盲目的に思ってたわ。 GPU支援とかの機能があったりするのはそういうのが有効な程度には負荷があるってことだしね 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使用率 スマホにAV1/HEVC配信をするのってバッテリー面で大丈夫なのだろうか。 HEVCは新しい比較的SoCだとAndroidでもiOSでもHWデコードできなかったっけ？AV1は負荷がかかるからバッテリー持ち悪そうではある なぁに糞重いゲームとかと比べると屁みたいなもんよ
まあ電気食わないに越したことはないんだけどさ AV1はHWメーカーも入って検討してるんだし、HW実装さえされれば
ユーザ側は少なくともデコードについては特に心配せずに使えるんでないかい。
デコードはユーザーレベルまで普及するだろうけど、エンコードがどうなるかはまだわからんね。 AVCのデコードの重さはCore2Duo世代の年寄りにとっては当たり前の話みたいなもんだったけど
今の若い人には逆に新鮮なんだな
当時はSD画質でも体感負荷が倍くらいあったけど
今はマルチコアの並列化がこなれてきてるのかMPEG2で50%負荷→AVCで70%負荷程度しか変わらんのな
JPEG2000もそろそろパッと読み込まれるようになってもええんやで、と思ってググったら
FLIFとかいうロスレス規格も出てきてたんだなhttps://gigazine.net/news/20160308-flif/
完全に浦島太郎状態だわ 普及する見込みのないコーデック覚えても意味ないから知らなくていいよ J2Kは回路コストが高すぎるとかで普及しなかったらしいけどAV1はどうなんだろう 動画の帯域問題はプロバイダやサーバー事業者（サービス提供者）にとっては死活問題だから
YouTube（Google）とNetflixとPrime（amazon）とHuluが主導してる時点で意地でも普及させてくると思う Mark Shuttleworthこっちにも来てたw
https://github.com/OpenVisualCloud/SVT-AV1/pull/38
インストール、アップデートがめちゃらくになる >>130
DVD見るためにセレロン300AをOCしていた思い出・・・ 再エンコードとかなかった頃のニコニコ動画で再生負荷高くて再生できないなんてことがクソスペックであったからなぁ
逆に再生負荷あげられまくれるからベンチマークなんてのあったし YouTubeの720p/AV1はそこそこ普通に見られるのにニコニコ動画のHTML5プレーヤーは止まりまくるの草 >>138
パソコンでDVD 見たいなら再生支援チップが載ったグラボ買った方が良いよ！な時代やな CPUなに使ってるか書いてなかった
Ryzen 5 2400Gです >>142-143
乙です。
・SVT-AV1、libaom、rav1e、libvpx VP9、x265、x264のVMAFでの比較評価。（重い設定での比較）
・全体的にlibaomが良好、その次にx265とlibvpx VP9。
・SVT-AV1はその次くらいで、rav1eと同等かそれ以上。
ってところかな。そしてやっぱりAV1は重い。 AV1がすごい、HEVC/VVCがすごい以前に2つの参加企業見比べたらAV1がVVC潰しに掛かっているような構図にしか見えない。 同じAV1でもlibaomとSVT-AV1、rav1eでは別物クラスの違いがあるね
libaomは低ビットレートでの改善具合がすごい
ただ、重いんだろうなぁw
問題は、高解像度映像でどの程度の改善があるのか
libaom使って4Kをエンコードした場合に、HEVCより3割以上縮むのならば、4K放送の当面の保存用に考えなくもないが…
（4Kは保存場所がどうしても消費してしまうし、画質落とした4Kを保存するくらいならば2Kでいいだろとすらなってしまうのがイタい） >>145
「参加企業」つってもHEVCの参加企業と言ってるのはライセンスを保持する企業群のことだろうし、
AV1(AOM)の参加企業は「HEVCのライセンスは内容も複雑さもクソ」って企業が集まったってだけでしょ。
別にVVCを潰すなんて意図はないし、VVCでHEVCのクソライセンスの悲劇を繰り返さないためにMC-IFって組織も立ち上げられてる。 VVCがAV1より良い出来で、ライセンスが分かりやすくなったらそっちに鞍替えする企業も出てくるのだろうか VVCはAV1を超えてくるだろうね
単純に後発なのもそうだしAV1はmpegが今まで積み上げてきた特許回避しなきゃならないから
それにライセンスも今回は慎重にいくみたいだし
まあAV1はmpeg帝国に対するけん制みたいな面もあるしあんまcodec戦争とか言われるようなもんじゃないのかもね libaom凄いな
3000kbpsでもうほぼソース画質に近くなるのか
そりゃ動画配信企業はお熱になりますわ >>150
俺も別スレでグラフ出しただけでrigaya氏扱いされたことがあるけど、
匿名掲示板で名乗りもしてないレスに対して「〇〇さん乙です」みたいな人物特定するような書き込みをするのは
結構気色悪い行為だからやめたほうがいいと思うよ。的外れなら尚更。 >>153
その後同じグラフをブログに掲載すんだからバレバレじゃん 氏がこのスレかソース元サイトを見てるって事でしょ。
アンテナ張ってる先は同じなんだからさ。まずここ特定板じゃねえし、特定厨は邪魔だから帰って ネトゲで「お前同じクラスの〇〇だろ！キャラの顔があいつに似てる！」と叫んでる人を見てる気分。 もしかしてグラフ作るのが技術的に物凄く難しくてrigaya氏みたいな人じゃないと出来ないと思ってる？
libreOfficeみたいなフリーのオフィスソフトでも簡単に作れるんだけどな ところで、libaomとはどうやって使うものなの？
あと、これを使ってエンコードしたものをまともに再生しようとした場合に、ハードウェア再生支援の存在しない現状で要求されるハードウェアスペックとはどの程度なのだろうか？
エンコードを時間かけてやってもまともに再生できないようではさすがにつらすぎるし Google Cloud Platformの仮想Windowsでエンコードから再生までやってる。音声と映像のラグが酷いけど。 ffmpegとLAV Filtersでエンコードもデコードもできるんだから1:30くらいの動画を試しに変換してみればいいじゃん
と思って検索掛けてみたらAV1の画像フォーマットもAVIFも策定されてきてるんだな
https://people.xiph.org/~negge/AVIF2018.pdf
前に見つけたFLIFはJPEG2000よりさらに2倍近く読み込み時間が必要だったからwebpの後継として期待したい >>162
FFMpegでエンコードするときの使い方をわかりやすく解説した資料とかないかな？ GUI公開されてるの幾つかあるけど、やっぱ個人で実用的に使うのはまだ先になりそうだねー
設定項目多すぎるよ >>163
基本的なのはffmpegのページに載ってる
現状での再生スペック測る程度なら充分かと
https://trac.ffmpeg.org/wiki/Encode/AV1 >>164-165
やっぱりまだテスト目的止まりか
使い物になるのはいつ頃だろ？
4Kの容量削減のために、なるべく早く使いたいところ
話変わるけど、BS4K放送がリアルタイムハードウェアエンコードで33Mbpsで放送しているけれど、x265でslowくらいの設定で放送と同程度くらいのエンコードをした場合だと、
ビットレートはどのくらいまで落とせるものなのだろうか？
あまり変わらないかな？ 33Mbpsでも不足してる(画質維持には50Mbpsは欲しいところ)から何とも…
その上で考えると、放送画質相当なら20Mbpsくらいにまでなら落とせるかもしれない。 >>168
絶対的な画質で言ってしまえばビットレート不足か場面がないわけではないけど、放送としては開始間もない状況では充分なのではと個人的には思っているけれど
で、x265で積めて20Mbpsあたりか…
2年前くらいのNHK BSプレミアムと同程度の保存容量か
やはりAV1かVVCが来ないと保存場所の確保が大変になりそうだな
とりあえずAV1のハードウェア再生支援を早急に整備してほしい… >>149
HEVCやAV1で拡張扱いの機能が標準で取り込まれてたりするからね VVCって一番遅いエンコード設定にしたら10Mbpsで4K/24fps出来たりするのかね? 何を基準に出来るというか分からないけど前評判ではAV1より縮むはず。
実際個人で試せる所まで来てみないと分からんだろう。 低ビットレートなら半分くらいのビットレートで済むのは有るだろうけど
高画質目的なら H.264/AVC -> H.265/HEVC での圧縮率と同じ4/5程度だろうなと思ってる >>172
VVC Test Model (VTM) なら一応個人でも試せる。
Versatile Video Coding (VVC) | JVET
https://vvc.hhi.fraunhofer.de/
jvet / VVCSoftware_VTM ・ GitLab
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM 下のをダウンロードして
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 .yuvの入出力がパイプ渡しでできれば便利なんだけどねえ。 >>177
誤 ffmpeg.exe -y -f rawvideo -s 1280x720 -r 24/1 yuv420p -i output.yuv -vcodec utvideo -an output.avi
正 ffmpeg.exe -y -f rawvideo -s 1280x720 -r 24/1 -pix_fmt yuv420p -i output.yuv -vcodec utvideo -an output.avi 東京五輪後に地デジ４Ｋ開始で、映像圧縮はH266!
2019年2月12日(火)―2月8日発行 第64巻 第15376号
地デジ以上の一大Ｐ・東京・名古屋実験公開
技術的焦点はＨ．２６６活用とＳＦＮ目途
総務省来年度予算８０億・最多額投入し具現へ
地上波４Ｋ、愈々検討本格化・五輪以降開始方針 >>180
まーた無茶してノイズ/モアレだらけの偽高解像度放送やるんか 今の地デジ放送って1つのチャンネルに複数のフォーマットを混在させることってできるのだろうか
ゴールデンタイムとかは現行の地デジのまま、深夜に４K８K放送流して
視聴者はそれを録画して見るとか 関テレが研究してたのってそういうのじゃやかった？4Kの電波を現放送に乗せる的な
違ったっけ >>180
決まってもいないことを決まったかのように書いてる１行目は自分で書いたのか。
スポーツ新聞や転載まとめサイトじゃあるまいし、やめたほうがいいと思うよ。
マスコミ研究会 > 日刊合同通信 > バックナンバー
http://www.godotsushin.com/backnumber_nikkan/2019/2019_02html.htm
「東京・名古屋実験」って、どういう団体がどういう実験をした（する？）んだろな。
「五輪以降」ってのは「何年後とは言ってない」ってレベルの話であって何のメドにもなってないし、
検討がまだ進んでない状況なんだから、やるとしても東京五輪以降ってのは当たり前の話でもあるし、
そもそもVVC(H.266？)の標準化予定が2020年10月（東京五輪より後）。 もう遅いだろうが五輪4K諦めてH.266出てから実験始めろ >>182
H.264のワンセグと普通のMPEG-2が一緒に配信出来てるからTSならできるでしょう。 >>187
1Chあたりの容量は変わらんから両方とも相当悲惨な絵になりそう AVX512が使えるとSVT-VP9がすごい
AVX512有無だけでここまで変わるものなのか
https://www.phoronix.com/scan.php?page=news_item&;px=SVT-VP9-Open-Source 10Mbps超でH266で4Kならそこそこ綺麗そうだけどな Chrome/Firefox「Flashはセキュリティ面の問題もあるし、何よりWebはオープンであるべき!」
Chrome「せや!動画もH.264/H.265排除したろ!」
Apple「駄目です。」
Chrome「ぐぬぬ・・・」←いまここ
将来的にChromeがVVC排除する危険性は0じゃないし、Webに載せるのは慎重になってしまう。 かと言ってAV1が普及するかと言えば、再生すら糞重たい現状ではかなり難しい
（CPUデコードで4K再生とか8コアクラス以上のCPUじゃないと無理だろ） i7-2600程度だと720pですらコマ落ちしまくるからなぁ >>189
記事内のリンクで気づいたけど、2/15にSVT-AV1のベンチマーク記事も出てたんだね。
2/3版に比べて、2/15版はかなり速くなってるとのこと。
（まあそれでも i9-7980XEで1080pが8.5fpsくらいだけど・・・。）
SVT-AV1 Already Seeing Nice Performance Improvements Since Open-Sourcing - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=SVT-AV1-Speed-Progress >>192-193
参考までにPhoronix Test Suiteのdav1dのベンチマーク。1080pと4Kのデコード速度。
dav1d Test Profile
https://openbenchmarking.org/test/pts/dav1d
グラフ
dav1d Performance Showdown, Automated Performance Comparison
https://openbenchmarking.org/showdown/pts/dav1d >>195
掲載しているCPUに偏りがありすぎて資料としての価値が…
そもそも物理コアが2コア、4コア、6コア、8コアでそれぞれ何fps程度までコマ落ちなしで再生できるのかみたいな比較じゃないとわかりにくいし
あと、今年中に登場予定のIntelの新型CPUがかなり気合い入ってるらしいので、そいつに期待するか
2018年あたりからThunderbolt3端子搭載ノートPCが増えてきているから、Thunderbolt3接続タイプのAV1ハードウェア再生支援回路とかが出れば普及させやすいかもしれんが ffmpeg+QSVでH.264とHEVC両方使ってみたけど
意外とCPU負荷もあるんだな
GPUに全部お任せできるくらいに思ってたわ H.265の寿命は短かったなあ。4K8Kのコンテンツもコーデックもオワコン。 H.266よりもAV1だろ
AV1のハードウェアエンコードはいつになったらできるのか >>191
H.264はともかくH.265は元からChrome/Firefoxには無いだろ >>203
終わったやん。本格的に。
まぁ、でもAV1リアルタイムエンコード厳しいし...厳しいし... >>204
は？何いってんだ、H.265が採用すらされないのは権利問題だろ
そもそもSafariにはH.265あるのか？ 個人使用でモダンなコーデックの中で圧倒的に実用的なhevcが終わったっていうのは有り得ない。
一般的には始まっても無いが少なくとも終わったという表現はおかしい。 ノートでバリバリHEVCエンコしてるよ
i7-8750H、2時間映画8時間近くかかるから寝る前にセットだ 固定回線でも「ギガ不足」におびえる時代が到来か、トラフィック急増により現場で起きている悲劇とは (1/2)
「従量課金に移行しないと、このままではとても立ち行かない」
ある固定回線系プロバイダーの幹部が悲痛な面持ちで筆者に訴えた。 「ここ数年の爆発的なトラフィックの伸びに設備投資が追い付かず、ユーザーからのクレームが増加している」
それは、プロバイダーだけの問題ではなく、NTT東日本・西日本（NTT東西）のフレッツ光にもいえることらしい。
この資料の中で注目してほしいのは4ページ目の「1契約当たりのトラヒック」（図版2）だ。これを見ると、2015年辺りから毎年3～4割のダウンロードトラフィック増を記録している（赤のグラフ）。
動画サービスの台頭やWindows Updateの存在がトラフィック増の原因か
https://www.atmarkit.co.jp/ait/articles/1902/19/news013.html iPhoneの動画撮影と写真がHEVCになって2年以上経つし普及はしまくってる
既に使用してないiMac 2010でもHEVC 1080pは余裕で再生できた YouTubeの1080p60を1.5倍速で再生できないうちのパソコンに未来はありますか…？ 進歩しないといけないとはいえ
やっぱ光の速度に限界がある以上
限界は近い 1080pじゃないな。iPhoneで4K60fpsで撮ったのが2010 iMacで問題なく再生できてるの間違いだわ。ハードにHEVCの再生支援なんてないから、GPUのシェーダーコアとかCPUのSSEとかで頑張ってるんだろうけど(AVXもないマシンなので >>216
さすがに2010年のiMacのスペックで4K60fps（H.264でもHEVCでも）を問題なく再生するのは無理では？
https://ja.wikipedia.org/wiki/IMac_(%E3%82%A4%E3%83%B3%E3%83%86%E3%83%AB%E3%83%99%E3%83%BC%E3%82%B9)#iMac_(Mid_2010)
再生してる動画のプロパティをもう一度確認したほうが良い気がする。 >>217
ダブルチェックした。
未編集ビデオ書き出してQuickTimeで再生。
HEVC 3840x2160 59.99fps
データレート 51.41Mbps
ふつーにヌルッヌルに再生できる。
2.93GHz Core i7
8GB 1333MHz DDR3
Radeon HD 5750 1024MB
解像度 2560x1440 俺のivybridgのCorei5 で4k 60fpsのVP9再生してみたけど60%ぐらいやな。だからいけそうな気がするな。 60%ってのはタスクマネージャーで確認したCPU使用率 負荷は4コア400%中295%程度
100%基準にすると75%程度だから妥当かと 固定回線が従量制になったりしたらネットインフラが完全に崩壊しそう。ゲームのDL版なんか買えなくなる >>222
最大の危機はWindowsUpdateって話も・・・ 従量制だと良識派ユーザーならかえって安くなりそうだな YouTube VP9/1080p60fpsでDropped Frames 9912/14280のワイ無事死亡。
FUJITSU AH30/Xもう本当に許さねぇからな。お前。 >>226
逆恨みはほどほどにな
・ AMD デュアルコア E1-7010 APU + AMD Radeon™ R2 グラフィックス
→Unified Video Decoder 4.2
VP9の再生支援には対応していない
Celeronの最下位モデルと同クラスのCPUに期待しすぎだ ブラウザ変えてみるとvp9のデコーダの性能が違うから見れるかも
chromeはlibvpx
firefoxはffvp9
edgeはvp9 extension
でデコードされる edgeはmediafoundation全面押しだから軽い ジッジが同じような富士通の機種使ってるとこ見たとき
プレインストールの常駐ソフトだけでメモリ4Gほとんど使い切って
スワップしてたからそこも気をつけてほしい ah77/cだけど>>226にはギリギリ勝ってて腐ってもi7なんだなって思った >>229
その通りなんよ。今度から自分で買うことにする。悪いのは家電量販店と富士通やし。
タスクマネージャー見たらエクスプローラー開こうとしただけで100%行きやがる。 >>234
こういう奴仕事できなさそう
自分が無能なのを棚に上げてさ >>224
各プロバイダーがWSUS設置すりゃいいw >>226
つべを見たいだけならh264ifyとかでVP9使わないようにすれば… >>238
Edgeで見たら凄い軽かったからそれで行こうと思う。
ChromeがVP9のハードウェアデコードしてなかったらしい。
Edge今までChromeインストール用と馬鹿にしてごめんなさい...。 >>239
EdgeさんはVP9ハードウェアデコーダ積んでない場合H.264にするとかやってなかったっけ？
右クリで詳細統計情報のコーデック見るんだ >>239
> ChromeがVP9のハードウェアデコードしてなかった
Chromeのせいみたいに書いてるが、>>226のPCはVP9のハードウェアデコード機能持ってないんだから当たり前だろう・・・。
まさかEdgeがハードウェアデコードしてくれてるとでも思ってるんじゃないだろうな・・・？ win7だとdirectXの新しいのが入れられないのでスペックは十二分にあるのにモダンなコーデックはハードウェアデコード出来なくてHEVC4Kがギリギリで辛い
どうしてもダメな理由があるので変えられん
今思い付いたけどvirtualboxとかにwin10インストールしたら支援受けられる? iPhoneのGPU使ってHEVCエンコしたいんだけど、そういうアプリ無いかな… >>242
仮想化ソフトで動かしてもGPUを直接叩けるわけじゃないから無理 >>243
ある。Siri Shortcutsでワークフロー作ろう。
共有メニューからパイプみたいに流し込んでエンコできるようにしとくと便利 >>244
ふぇ…VRとか6Kとかの動画多くて辛ひ >>242
グラボのpciをvirtualboxでパススルーすれば仮想マシンから直接触れるようなことは聞いたことあるけど
やったことはないから自信ない 今どきのハードウェアデコーダは6Kとか対応してるのか？ >>240
ほんまや。OpusとAVCと組み合わせなんて初めて見た。
てかReadonっていつの間にVP9非対応になってしまったんや。 >>249
> Readonっていつの間にVP9非対応になってしまったんや
いや、君がVP9サポート前のPC使ってるだけだから・・・。
ついでに言うとRadeonはVP9の対応が遅れてて、VP9のHWデコードやDXVAに対応できてるのはAPU（RavenRidge）のみ。
それ以外のPolarisとかVegaはハイブリッドデコードでDXVA非対応。 稀に動画は再生支援を使うから低スペックPCで省電力がいいとか言ってる連中がいるが、
省電力PCは不可かかったときにフレーム落ちしやすいし、音声にリサンプリング処理とかを高精度に適用するだけでもブツブツといった
ノイズが混入しやすくなるから、省電力PCは全くオススメしない >>242
virtualboxのGPU仮想化はホストがLinux限定じゃなかったっけ
VMWareだと結構お高い拡張パック必須 どのみち仮想化するならハード一個持ってかれるからホストとグラボ共有とかは無理なはず。
もう一個グラボ刺したら？ 余命一年のOSで踏ん張らないといけない理由が何さ
宗教的な問題？ >>256
windows7じゃないと動かないソフトがたくさんあるんじゃない？ そういう用途ならデュアルブートにするのが良さそうね
何を言っているのかヨクわからねーかもしれないが、x265 で SVT-HEVC を使えるようになっていた。
x265 and SVT-HEVC in the same house
http://x265.org/x265-svt-hevc-house/
SVT-HEVC (ビルド方法やオプションの使い方など)
https://x265.readthedocs.io/en/latest/svthevc.html >>256
マジレスすると反応速度が重要な少し古めのゲーム、というかSTGだな。配信もしてる
モニタや入力機器、ドライバも拘って遅延抑えてるのにwin10にするだけで1-2F程度遅延が発生する
自分は当該ゲームだと1F遅延はABテスト100%だから絶対変えられないし知り合いも2環境作ってる人が多い
多分反応速度0.13台だから異常に遅延を感じやすい
デュアルブートはOS切り替え面倒臭いから多少不便があっても使ってる… >>251
RX580使ってるけどChromeでもFFでもEdgeでもハードデコードできないよ
昔は出来たみたいだけど >>261
自分もそれを書こうかと思ってたところ
>>266
なんかSVT-HEVCを利用して
x265の高速化を図るのではないかという予想もあるみたい >>268
doom9の一般人の予想だからなんとも・・
ま、あっても2pass時のみとか微妙な感じになりそう SVTをx265が使えるログファイルを吐くように改造するのと
x265にSVTの一部コードを移植するのと
どっちが現実的なんだろうね >>269
>>261の公式ブログ記事曰く
---
In the long term, we plan to leverage this integration to further improve x265’s ability
to handle real-time and low turn-around scenarios in pure software;
this is the space that SVT-HEVC was focused on. In parallel,
we will continue to innovate on our flagship presets that are used in offline encoding where x265 dominates.
長期的には、この統合を活用して、純粋なソフトウェアで
x265のリアルタイムおよび低ターンアラウンドシナリオを処理する能力をさらに向上させる予定です。
これはSVT-HEVCが焦点を当てたスペースです。
並行して、私たちは、x265が優位を占めるオフラインエンコーディングで使用される当社の主力プリセットを革新し続けます。 >>263
render aheadフレーム数の強制設定のことかな
VulkanやDX12には意味ないから、OpenGLやDX11以前の旧ソフト向けのバッドノウハウ化しそうだな SVTはリアルタイムエンコに特化してるからx265と直接は比べる意味無いと思う
動画に使うならx265のほうが良いし配信に使うならSVTのほうが良い https://github.com/intel/SVT-HEVC/blob/master/README.md
メモリ足りてればBroadwell以降のCPUで動くらしいけど、恩恵を受けられるのはサーバーらしいね
どの層を狙った統合なんですかね リモコン番号
(関東地方チャンネルプラン)
１ ２ ３
４ ５ ６
７ 韓 ９
101112
押すわけないわな、日本人なら。 ネトウヨとか言っちゃうのキモすぎ
荒れるからどちっちもそういうのやめろよな >>270
SVTのライセンスがBSD+Patentなんで、
x265をSVTが使えるログファイルを吐くように改造する
の一択でねえの SVT関連は配信する人向けの対応みたいだね
別件だが、Windows10用にMSが公開しているAV1用のデコーダー（mediafoundation仕様）、何か改善されたのかな？
「映画&TV」でAV1動画の重たいものを再生すると、以前より滑らかになったような気がする
「映画&TV」はリピートの設定を記憶してくれないからあまり使ってなかったのだが、前にテストしたときよりも
AV1以外を含めて全体的にカクつかなくなったようにも感じられるし、しばらく「映画&TV」を使い倒してみるかな… >>283
WMPで再生すると重すぎてまともに再生すらできてないけどなぁ 「映画&TV」は音声chが複数ある時に、ビットレートが高い方のchを選択して再生する
っていう謎の挙動があったな。
普通は音声chの順番とか言語とか見て選択するよな、、、 >>285
ビットレート優先だからそこまで謎って訳でもないでしょ
言語とかを見てほしいのには同意だが >>282
うちは入れてないからわからんのだけど、とりあえずバージョンやDLLの日付を見て更新があったのかどうかを確認してみてはどうだろう。
全体のバージョンはアプリのとこで見れるはずだし、個々のDLLについてはDXVACheckerからDSF/MFT Viewerを起動して
MediaFoundationの一覧からたどるとわかりやすいと思う。 >>286
主音声と副音声を同じパラメーターで圧縮してたら、データによって主が再生されたり副が再生されたりして？？？になってた。
今は主音声と副音声でパラメーターを変えて、明確にビットレートに差がでるようにしてる。
WMPやMPCではこんな変な挙動は無いんだけどね。 デュアルモノでLRそれぞれに違う言語入れてる音声多重・二カ国語放送ソースなら、エンコード時にLRをモノラルに分離してから
主音声・副音声の順にID振って、言語種別のメタデータ追加して個別オーディオストリームに格納するのが本来じゃ無いの？
日本語音声しか使わないのなら副音声カットするなり、副音声側のレベル下げてmixして音声ストリームを1本にすりゃ良いし
ビットレートに差をつけるとかは、再生環境側が主音声の判断材料が無いから「ビットレート高い音声が主だろう」という挙動とっているだけでは？ >>289
まさにそんな感じで、デュアルモノをLRで分割して、IDを振って言語も「日本語/英語」で付けたんだけど、
ビットレートで選ばれちゃうもんだから謎だなって思ったわけです。 遥かむかーしに聞いたことなる仕様だ
ソフト名までは覚えてないけど 既出かもしれんが遂にVP9がPCゲームで使用されてた
https://assassinscreed.ubisoft.com/game/ja-jp/home
ゲーム中のCGか動画かは中止しないと見分けがつかないレベルだった Switchのムービー使ってるゲームはほぼ全部VP9と思われる
権利表記に必ずVP9が書いてある ・Windows 10で「AV1」動画を再生可能にするメディア拡張機能「AV1 Video Extension」
ベータテスト中。「Windows 10 バージョン 1903」ではエクスプローラーでのプレビューも
https://forest.watch.impress.co.jp/docs/review/1171984.html >>298
MSの実装、性能悪いんだよな
dav1d使えばいいのに
各社バラバラにSIMD最適化するのって効率悪く思えるよ >>299
同一じゃないの
ARMとx86（x86_64）みたいな大枠での話のような気がする 思ったよりAVIF来るの早かったな
とりあえずIrfanviewが対応してくれるの待ち ついにきたのか、静止画用としてはwebpより品質低いのが事実かどうか気になるところ v1.0.0だけどまだdraft段階で正式に承認されてないから注意ね
これからまたerrataとか出すかもしれない >>298のはAVIF(海老フ)にも対応してるんだよね
Windowsに載ると普及早いかもね
HEIFはすでに対応してた気がする ライブラリとコマンドラインツールくれよう。オレオレ画像ビューアに組み込むからさ エビフでもヒフでもどっちでもいいけど、画像ビューアーがどれだけ対応するか
未だに色域の処理すらままならんクソ匕が履いて捨てるほどにあるのが、どうにも信じられん
何故静止画のソフトウェア開発者は無脳が多いのか HEIFもAVIFもbt601とbt709どっち使うのか明確に決まってないしレンジもリミテッドなのかフルなのかもよく分からんしな
作成側のソフトも表示側のソフトもガバガバだから正しい色で表示出来ないトラブルが頻発しそうやね
というかこの辺BPGのほうがよっぽどまともだったな >>312
たすかる
>>313
まだ出てねーよ死ね dav1d.exe -v すると0.2.1って表示されるのは確か >>315
リリース後はとりあえずバージョン表記も仮バージョンという形で上げておこうという運用みたいだね。
0.1.0 リリース
↓
仮バージョン 0.1.1 として開発続行
↓
0..2.0 リリース
↓
仮バージョン 0.2.1 として開発続行 ← now
なので、「v0.2.1がリリースされた」というのとはちょっと違う。 dav1d v.0.2 の関連記事と概要
DAV1D v0.2 AV1 Video Decoder Released With SSSE3 & NEON Optimizations - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=DAV1D-0.2.0-Released
dav1d 0.2.0: Covering all PC’s, including mobile ? Ewout ter Hoeven ? Medium
https://medium.com/@ewoutterhoeven/dav1d-0-2-0-covering-all-pcs-including-mobile-eac3e43868c2
・SSSE3に対応したよ。Steamの2019年2月のハードウェア調査によると、AVX2はユーザーの3分の2くらいしか対応してないけど
SSSE3ならユーザーの97.23%をカバーしてるから、大抵の環境で軽快なAV1再生が楽しめることになるね。
・ARM向けのNEONアセンブリにも対応したよ。
・dav1dは今のところ8bitコンテンツしか対応してない。10/12bitは今後の課題だね。
・VLCはv0.2に近日対応予定。
・Firefoxも作業中。
・ffmpegは既に開発ブランチを利用してる。
・Handbrakeも近日中に対応する予定。
27 CPUs Benchmarked With AOM AV1, Intel SVT VP9/AV1/HEVC Video Encoders - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=27-CPUs-AV1-SVT-Video-Encode
27種類のCPUでのエンコードベンチマーク。>>196のリンクも参照。
dav1d v0.2がもう少し早く出てればそのデコードベンチマークもしてたんだろうけど、タイミングが悪かったようだ。 >>320
SVT-HEVCはデフォルトのencMode 9だとVMAFはx265のsuperfastとかultrafast相当だから
medium相当のencMode 4だと相応に遅くなる >>320
それよりもSVT-VP9がAVX512対応してて早いのがびっくり SVTはIntelがxeonで動かすために作ってるエンコーダだから
マルチコアやSIMDに特化してる IntelのSDKだとQSV使えなければソフトウェア動作もする造りだからな
それをXeon E3/D以外の多スレッド＆SIMD向けに速度寄りのチューニングした様なもの（画質性能はVLC一派には敵わない AVX2にも最適化してくれんかなぁ
動画配信で未だにゾンビの如く使われるx264をリプレースして欲しい
x264veryslow以上でx265veryfast程度の画質はあるよね…? それはわかる
色々とコーデックはあるけどh264にしか対応していない環境は多い 配信者がh265でエンコードしても配信サイトのほうでh264に再エンコードされるんじゃないの
配信したことないから予想で言ってるけど 配信者がエンコしたものがそのまま配信される(P2P or サーバー側で再配信)形と再エンコされて配信される形があるかな。
後者は3-10秒程度遅延があるものが多い。
自分はどちらも使うからクライアント側もサーバー側も両方更新して欲しい。
あと>>326の1個目はx264→h264だ恥ずかしい。 >>329
>後者は3-10秒程度遅延があるものが多い。
リアルタイムで変換してその都度捨ててるの？そんなわけないでしょ 配信した瞬間から視聴者へ届くまでの遅延ね。タイムラグと言った方がいいかもしれない。
サーバーサイドで再エンコされない場合、zero latencyとか指定しておけば1秒以下になる場合もあるから。 配信やってないからあまり知らないけど、YoutubeLiveもTwitchもニコニコ生放送も
配信者がエンコードして送り出した動画をサーバー側で再エンコードして、それを視聴者に届けてるよね？
配信者がエンコードしたものをそのまま視聴者に送ってる配信サイトってどういうのがあるんだろ？ あんまり詳しい事覚えていないけどMicrosoftのMixerは遅延対策にWebRTC使っているし、再エンコードしてないのでは? 総務省資料より抜粋
VVCの1080pで4MbpsってDivX/WMV時代だとSD画質程度じゃねーか
そんなに進化するのか >>334
情報出してくれて感謝だけど、そういうのは一部を切り出した画像だけじゃなく元資料のリンクとかも貼ってもらえるとありがたい。
総務省｜放送用周波数の活用方策に関する検討分科会｜放送用周波数の活用方策に関する検討分科会（第4回）配布資料
http://www.soumu.go.jp/main_sosiki/kenkyu/housou_kadai/02ryutsu08_04000339.html
資料4－4 VHF-High帯の利用提案について【シャープ株式会社提出資料】
http://www.soumu.go.jp/main_content/000604314.pdf
>>335
>>334のページ全体の画像→ http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3530.jpg
「性能を倍と仮定して算出」だってさ。
---
注）
・HEVCの性能はAVCの倍、VVCの性能はHEVCの倍と仮定して算出
--- でも実際はMPEG2で20Mbps必要なところを、FHDを6割の解像度に落としてネジ混む暴挙でたのが現場
帯域設計的にも地デジは本来AVCでやるべきだったのを、地デジ賛同を人質に早くから試験運用開始してTV売ろうとした業界の上層部の守銭奴のお陰でデコーダの調達面や、数年後の本格移行に入ってから録画機能にAVC使う算段からMPEG2になっちまった
開始2年遅らせられたら放送波AVC使えたのにな おまけで、地デジの帯域管理の構想で元々13セグの分割も12セグ+1セグなんて物じゃ無く
10セグ+3セグでFHD AVCでプログレッシブ放送＋エラー補正付き縦横入れ替えたハーフD1解像度（480x360を引き延ばし）放送で、14Mbps＋7.2Mbpsという、表中の14Mbpsで綺麗に分割出来る設計なのよ
デジタル信号で受信不良地域が出た際の対応も当初3セグの役目だった
そこに無理なMPEG2化で3セグが帯域奪われワンセグ化
文字情報も読みとり困難になって320x180で動態受信用途と役割縮小
元から帯域ギリなうえ更に削られてAVCは外せず
16.8Mbps確保してもMPEG2だとインタレで20Mbps必要でまだ帯域足りないので1440x1080引き延ばしまで加えて画質は更に下がる
地デジでインターレース放送の理由がイマイチ根拠が舌噛みそうなのと
プロファイルが低くて良いとはいえワンセグはAVCだったりと変なダブルスタンダードと、歪な状態なのはここらへんなのよね
ただ画質が下がって、当時テレビの売れ行きが伸び悩んでた家電メーカーだけに利があったのが今の地デジ 可能であればVVCでしょ。
総計算量がAV1の1/3程度でそれよりも縮むといわれてるし。 >>339
アナログ放送に比べたら画質は格段に良くなったぞ テレビならエンコードのコストなんか無視できるだろう >>336
avc->hevc->vvcで伝送容量をただavcから半分にしてるだけでワラタw
さすがにやばいかもって気持ちが端数の切り上げに表れててさらに笑うw >>336
VVCはまだ想定の話でもいいけど、H.265は実際にエンコーダーが沢山あるんだからちゃんと検証すりゃいいのに
効率がH.264の倍とかってどんぶり勘定もいいとこだな 自サイトでVP9(Webm)をGIFアニメの代わりに使いまくってる僕 放送波でVVCはエンコする放送事業者側、特に地方局で悲鳴が上がるけどな
BS4K/8Kに絡んでるキー局ならまだしも、リアルタイム処理の敷居上がるし編集機材も総入れ替えだから、地方局じゃ見通しも出せんだろう
その提案は技術面だけでの案でタイムスケジュール的な現実性が全然無いのよね
手前らはデコード環境揃えられりゃ良いんだろうけど 機材の変更なんか要らないって話
放送時に変換すればいいだけでしょ ぱそこんで1日一本作ればいいYouTuberくらいしか想像できない視聴者は
黙ってればいいよ リアルタイムエンコーダが1台あれば済むテレビ局、
大量の動画を複数解像度でエンコードする動画サイト、
というわけだな リアルタイムエンコに限定すれば評価も変わりそうだな
複雑すぎるアルゴリズムだと間に合わないから意味無いし
実はH.264位が丁度いいかもしれない 帯域や変調方式まで変わるとなると、伝送系や送信局の設備更改やらで
かなり面倒な事になりそうだな。 AV1リアルタイムエンコードが実現するのに残りどれほど時間がかかるのか。ぼくには 地デジは最初レイテンシーが3秒以上あったが、エンコーダーの進化で画質も向上しつつレイテンシーも1秒になった
実はMPEG2もリアルタイムエンコに限れば悪くないのかもしれない そうは言っても3秒程度のレイテンシーってそんなに大事なのか？そのへんのことはよく分からんが… 年越しカウントダウンがずれるだろ
とはいえ、日本の年越し行事はことごとくダウンタウンに破壊されたが テレビ局の自力によって用意できるエンコーダーに差がでて各局毎に12時がバラバラとかになるのか 高速化ではあるんだろうけど
ブラシーボでx265回した方がまだ速いという HEVCにしてもAV1にしても確かに同じ絵が連続するようなアニメだと縮むんだけれど
テレビ放送で大半を占めるであろう実写に対しては焼け石に水なんだよね
SHARPが丼勘定で数字出してしまうのもなんとなくわかる気がする
忖度か手抜きかわからんけど ◆ドイツの地デジはHEVCに移行、ＨＤ４０チャンネルへ
ドイツの公共・商業放送事業者は5月31日，DVB-T2方式による地上HD放送を全国18の都市圏で開始した。
6月10日からフランスで開催されるサッカーUEFA欧州選手権にタイミングを合わせた形だ。
当面は試験放送の扱いで，従来のDVB-T方式によるSD放送と並行して，
公共放送のARD第1テレビとZDF，商業放送のRTL，ProSieben，Sat.1，Voxの計6チャンネルをHD放送する。2017年3月29日に，
公共・商業放送合わせて約40のHDチャンネルからなる本放送を都市部で開始し，2019年半ばまでに全国で完全移行する。
動画圧縮規格にH.265/HEVCを採用したため，視聴者は受信機の買い替えが必要となる。
また商業放送は，本放送開始と同時に有料放送に移行する計画。
(ソース)http://www.nhk.or.jp/bunken/book/monthly/europe/201607.html
ドイツの地デジの新方式
# 帯域幅８MHz、26.37Mbps (64QAM, FEC2/3)を、HD6チャンネルに分割。
# 映像圧縮 HEVC 平均2.6～3.5Mbps、最大6Mbps
# 音声圧縮 E-AC-3かAAC
各チャンネル詳細 ⇒ http://i.imgur.com/ZNnciLl.jpg >>368 今から変えるならAV1のほうが良かったんじゃないの？って思ったり ドイツの男は、基本的に衛星放送かＣＡＴＶ(放送画質はＨＤ/H.264)で、
欧州５大リーグやチャンピンズリーグを主に見ている。
ドイツの有料多チャンネル普及率90%で日本よりはるかに高い普及率。
アメリカはNetflixなどの躍進で、衛星＋ＣＡＴＶの普及率が急激に低下中で、
地デジのみ＋配信のパターンが増えている。 >>372
【参考】欧州の最大の衛星放送 SKYグループ加入者数
サービスエリア 加入者数(2018年6月)
個人 法人など
英国 + アイルランド 1299.6 万 334.5 万
ドイツ+オーストリア 519.1 16.0
イタリア 482.3
==
合計 2301 350.5 総計 2651万
※加入者数のソース；ＳＫＹグループの"Annual Report 2018"。ttps://www.skygroup.sky/corporate/investors/annual-reports
日本のように、まだネット配信に自国サッカーリーグ放映権を奪取されておらず、加入者の減少は見られない >>371
地デジはそうだよ。ＮTSCのSDよりは高画質だけど。
ドイツは人口が多く、貧困層（主に不法移民）も多いから、
受信機買い替えが必要な地デジの規格変更は慎重だった。
当初の計画はH.264だったけど、長い議論の末に伝送規格DVB-T2、映像圧縮H.265になった。
詳細はDVBの過去NEWS参照
（携帯電話の帯域を増やしてくれということで、地デジ不要論まであった）
https://www.dvb.org/ >>374
なるほど
H265で帯域を可能な限り圧縮してるのね で、ドイツをキチガイ呼ばわりしている理由はなんだ？ 日本も後２～３年遅らせればh264でFHDにはなったと思うんだよなぁ >>377
あれじゃね?規格変更をテレビ売りたいがためだと信じてる人たち 【SHVC】アメリカの地デジ４Ｋ規格 ATSC3.0 で採用
ATSC 3.0 映像圧縮SHVC (HEVC Scalability Extension)
SHVCは画像を階層的に符号化する階層符号化技術で、
映像ビットストリームを品質と解像度レイヤーを映像信号に追加するサブセットに分割し、
ネットワークのデータストリーム情報を画像に変換する仕組み。
・・・ ttp://zakkamekka.com/industry_news/2014/10/141020_a.html)
現行のATSCとは互換性はないので、"受信機の買い替えが必要"
次世代通信規格５Ｇや、ネット配信の影響で、いまさら感のATSC 3.0は懐疑的な見方もある。 >>378
遅れて開始したワンセグはH.264だからね スカパープレミアムは1440x1080だから地デジでH.264採用しててもフルHDではなかった？
ビットレートの問題かな だいぶ前からだがアクトビラに対応してるテレビはH.264のデコーダーを載せてる
余程古いテレビ以外はH.264をデコード出来るからもったいないことをした >>368
># 映像圧縮 HEVC 平均2.6～3.5Mbps、最大6Mbps
いくらHEVCといえど、HDでこのビットレートは苦しくないか？ >>384
電波帯域の再編成とか面倒な事極力避けてるからな
近年のドイツ政府らしい結構な手抜きとゴリ押しだよ
お陰で軍隊の劣化マッハすぎて笑えない 平均3Mbpsしか割り当てられないってのが、そもそもどうかしているし、どうしてもそれしかできないならば、おとなしくVVCまで待てよとしか言いようがない 一方mpeg2/1440 30fを無理やり1920に引き伸ばしてるの日本 >>384
x265の品質基準で結果的に1.3MBps前後なエンコードしてるけど
画質的にはギリセーフな感じだから、2.6MBｐｓもあれば十分「綺麗」な放送ができると思う ハードウェアエンコードの放送をソフトウェアエンコードのビットレートで比較してどうすんだよ x265mediumで1440x1080の実写だと4MbpsはOK、
3Mbpsだと地デジ通常局よりノッペリしてて汚いって感じ
アニメの縮みは何だったのかと思うほど実写はレート必要だね
まあ今までSDならそれよりは圧倒的にマシだから良いのでは 放送事業者が使ってるシステムも、実際の中身がXeonのシステムにDSPや映像入出力系のボード載せた専用システムってのも少なくないからな
ハードウェアエンコーダと言って良いかは疑問 まぁ、実写で視覚評価の悪化をどうにかする為にrd系オプションが有ったりする訳だけども
SSIMでの画質評価基準からは外れるから、自分で画質評価出来なきゃならんので、落としどころ見つけるのが糞難しい >>384
俺がエンコした感じ、、1920x1080/60pは4Mbpsでかなり見られる画質になった。
確かYouTubeは1080/30pのH.264を4Mbpsくらいでエンコしてるから、それ基準に考えたら分かりやすいかもしんない >>390
放送で使われてるHWエンコーダーは優秀だと思うぞ >>394
YouTubeみたいなせいぜい20インチ程度の小さな画面を前提の設定とテレビを同列で語られましても…
>>395
期待しすぎ >>396
テレビはYoutubeより劣化したレートにせざるを得ない >>397
関連性があんまり分かってないけど
ドイツのは最大6MBｐｓまで対応なんだから
必要十分な画質は達成できるでしょ >>396
いや、YouTubeのビットレートとAVCについて理解してたら通じると思うんだが。なぜなら見る媒体じゃなくコーデックの話だから。
同列で語る事に違和感あるなら、一度エンコすれば分かると思うよ。 なら国がどうとか企業がどうとか政治の話はしなくていいんじゃね
技術とは全然違う話だから ソニーは8Kに対応したH.265ベースの新コーデック「XEVC」を開発中
https://dclife.jp/camera_news/article/sony/2018/1218_01.html
↑こんなことして特許問題とか大丈夫なんですか？ また日本の不必要な囲い込み規格か
AVCHDとかもそうだったが
メーカー囲い込みのためだけに外殻だけ変えたもん作るのやめろよ 独自規格とかふざけんな
AV1でいいだろAV1の何が悪い 既存の物を組み合わせただけに見えるから言うほど独自でもないような 業務用カメラや規格を知らない無知なただの動画オタ一般人は
あまり汚い言葉で書き込まないでほしい。見てて恥ずかしい カメラ向けのプロファイルとして提言すりゃ良いものを、独自拡張でやってりゃ同じだよ 放送局用などプロ向け機器は、SONYが唯一高シャアの商品だからね。 俺がルールだと言うことだな。
曖昧にされるよりは良いかな。 放送品質はある程度高くしとかないと大画面テレビが売れなくなって、家電メーカが困るだろう。
まぁNHKのネット配信とやらがどんな形式のどんな帯域でやるのか楽しみだ。 H.265/HEVCのライセンスが緩くなった今、
VP9ってYoutubeがAppleと喧嘩して一人で意地張ってただけで
誰も幸せにしてないな >>420
逆でしょ。Appleが無駄に意地を張ってVP9に対応しないせいで
SafariでYoutubeの1080pより上が見られないというマヌケな状況が続いてるってだけ。
AppleがVP9に対応しない理由が何なのかは知らんけど。
H.265のライセンスが緩くなったつっても、VP9やAV1に対する危機感でコンテンツ課金が無くなったくらいであって
無駄に複雑でリスクもある状況は今でも全く変わってないはずだし
主要ブラウザでの対応予定が無い状況ではweb界隈での利用も限定的になり広く使用される可能性は低い。
そうこうしてるうちにAV1のHWサポートや普及が進んでいくだろうから、
H.265はweb界隈（ブラウザベース）に限っては大した幸せをもたらさずに終わりそう。 AV1作ってるAlliance for Open Mediaのメンバーに日本企業が無いように見えるんだけど、俺の見間違いだよね？
https://ja.wikipedia.org/wiki/Alliance_for_Open_Media
SVT-AV1 Performance Continues Speeding Ahead, Xeon/EPYC Video Encode Benchmarks - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=SVT-AV1-Xeon-EPYC
SVT-AV1が速くなってるとのこと。
2 x Intel Xeon Gold 6138
2/3 3.10fps → 2/15 8.41fps → 3/7 18.35fps
ただ、3/5に
Live Encode - Updated Presets [0 to 7] (#136)
https://github.com/OpenVisualCloud/SVT-AV1/commit/8d75aadc3a3c55d36240cceb152f903f8792a3ea
という、0-3(デフォ3)だったプリセットを0-7(デフォ7)にするコミットが入ったりしてるので、
単純に一部の処理が省略されたせいで速くなっただけという可能性も高そう。(詳しくは見てない)
ベンチマークのコマンドもプリセットは指定せずデフォルトを使ってるし。 SVT-AV1の各プリセットのエンコード速度とVMAF調べたいんだけど出力する動画がたまに壊れるバグがあるみたいで調べられないんよね
issueに報告しようかと思ったけどQ値とかキーフレームの間隔を変えるだけで正常になったり異常になったりして再現条件がわからないからどう報告したらいいのか 条件特定しなくても、事象をそのまま書いてなんか怪しいよって報告したらいいのでは >>424-425
ってことはパナソニックのデジカメがAV1で記録できるかもしれないのか！
ソニーの関連企業は入ってないの？ >>429
いや日本企業が入ってるからって日本企業がそれを採用するかなんて分からんし、なんでいきなりパナソニックが出てきたのか意味不明
そもそも、まだHWエンコも出来ないAV1がデジカメに乗るのなんかいつになることやら >>430
富士通とパナソニックのシステムLSI統合会社がソシオネクストだったから・・・
でも、↓を見たらカメラはあと１０年くらいh264で記録するような気がしてきた。
Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑
性が高まるとしてもまったく問題にしない」というスタンスであることを伝え
ると、議長から「では、どのくらいの複雑さを許容できますか？」と尋ねられ
たとのこと。回答の準備が整っていなかったNetflixの技術者は「最悪のケース
では100倍まで」と答えると、100人はいたであろう動画コーディングの専門
家たちからは大爆笑が起こったそうです。議長は「心配しないで。彼らはみな
『新しいこと』を試すことができると、幸せに感じているのです。たいていの
人は『3倍まで』と答えるものだから」と話したそうです。 >>430
【福田昭のセミコン業界最前線】富士通とパナソニックのシステムLSI統合会社「ソシオネクスト」 - PC Watch
https://pc.watch.impress.co.jp/docs/column/semicon/692816.html
まあだからといってパナソニックデジカメがAV1を採用するかどうかなんてわからんが。 >>418
AVC、1280x720@30p
だろうねー、60fpsは絶対必要だと俺は思うけどAbemaTVが頑なに30p続けてるからなぁ エンコードだけ60fpsにしても大抵の映像は30fps以下で制作されているんだから無駄なだけだろう >>436
そうなん?vp9意外とデコード処理早いんかね?3480円の端末のcpuでも動くわけだから。 てっきりandroid版chromeはosのデコーダー使っていると思っていたワイであった。 chromeはvp9再生できるって言われてるのに端末によって再生できないことになったらweb開発者泣くよ ブラウザでVP9に対応してるって事と
CPU(GPU)がVP9のデコードに耐えられるって事は
話が別なんで vp9のデコードすらできないcpuではブラウザ動かすのも無理だと思うのだけど つまりは将来的にAndroid端末側がAV1に対応して無くても、Chrome上でならAV1を再生出来るようになる可能性が高いという認識でおｋ? >>443 えぇ...
なぜ二重に載せたし...
と思ったけど4.4以下でも再生出来るようにするためなのか?
するとYouTubeアプリにもVP9デコーダー載ってたりして。 Firefoxも似たような事やってるから一々気にする人間はモダンブラウザ使わない方がいいよ
ELinksでも使っとけ 個人情報ｶﾞｰとかいうやつ大抵ニート説だから大した情報そもそもない説 ソニーは糞規格を連発して世界中のユーザーを混乱させた重い罪がある
もう信用無いんだから止めろよ
規格を作る才能が無いんだから https://android-developers.googleblog.com/2019/03/introducing-android-q-beta.html
Android Q introduces support for the open source video codec AV1. This allows media providers to stream high quality video content to Android devices using less bandwidth.
In addition, Android Q supports audio encoding using Opus - a codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it. ついにスマホでもAV1が…？
ハードウェアのデコード対応はいつ頃スマホに来るんだろ カメラの自社独自規格に文句言うのは筋違い
他社や団体の規格策定や改変に合わせてハードウェアやファームウェアの開発を
毎回ジャストインタイムで開発調整するなんて困難だし負担が大きすぎる
自社規格なら迅速に新製品出せるし先行するタイムスケジュールも明確
ぱそこんでアニメエンコしてるだけのお子様は黙れ ついでにOpusもAndroid自体でサポートになるのな
OSでサポートは大きいね >>454
Opusのデコードは5.0以上で必須や 次期「Android Q」がベータ提供開始。Pixelで利用可
https://pc.watch.impress.co.jp/docs/news/1174599.html
・onResumeとonPause、resizeableActivity関数の変更により、折りたたみ画面とマルチウィンドウの親和性を向上
・オープンソースビデオコーデック「AV1」、および「Opus」を使ったオーディオエンコード、HDR10+のコンテンツのサポート
・Vulkan上で動くOpenGLドライバを開発し、ゲーム開発の一貫性を向上
・ANGLEを実験的にサポートし、OpenGL ESを使用する多くのゲームがVulkanの性能向上の恩恵を受けられるようになる
・64bitのAndroidデバイスでVulkanサポートを必須に。32bitでは推奨扱い vulkan上にopenGLESマッピングしてるのすげえな >>449
ブラウザの閲覧情報の話だよ
>>445
送信する設定変えればいいよ >>434
大抵の映像が30fps以下で制作されている…？？？ Android QのAV1対応はデコードだけなのか？ 現状の性能でAV1エンコーダ載せて意味あるのか定期 あれは標準搭載させるソフトウェアのエンコーダ/デコーダの意味でしょ。
ハードウェアエンコーダを追加するかは後はベンダーの自由だし。
現状のSoC性能で標準でAV1のソフトウェアエンコーダ追加しても... >>460
> Android Q introduces support for the open source video codec AV1.
> This allows media providers to stream high quality video content to Android devices using less bandwidth.
→ Android QはオープンソースビデオコーデックのAV1をサポートします。
これによりメディアプロバイダーは、高品質な映像を低ビットレートでAndroidに流すことができます。
文脈的にはデコーダーだけサポートするようにも見える。 >>459
AbemaTV見てるとインターレースの横シマも出てないし、たぶん60iでは撮ってないんじゃないかなぁ。1920x1080/30pで撮ってんのかなぁ… ソシオネクストってGopro HERO7のHEVCエンコーダ作ってたところじゃん。
技術的には期待できそうだ。 >>453
完璧に受け入れられない
独善的な日本メーカーらしい発想でしかない
すなわちそれは井の中の蛙な発想とイコールであり、日本企業が惨敗を喫することになった要因でもある
おまえは視野が狭い野郎だ
自覚が無いなら重症だな SONYの独自規格が成功した試しあるか?情弱相手の囲い込みばっかじゃん
ライセンスが面倒臭そうなHEVCの亜種の権利をSONYが一括で面倒見てくれるっていうなら需要は結構あると思うが。 日本独自規格の失敗例はおサイフケータイのNFCもそうだな。使われているのは日本と台湾くらい。
そんな事はどうでも良いけど、iOSにAV1デコーダ載るのはやはりHWデコーダを開発してからか? 独自規格云々は世界でも変わらんしこれで日本ガーはちょっと違うわ
目立つところだとappleなんか独自規格の塊みたいなもんだし
A/V関連ならドルビーとか対立規格つくりまくりだぞ >>469
XAVCは放送業界じゃかなり広く使われてる規格だぞ
俺ら一般ユーザーに馴染みがないからってイコールで失敗してるわけじゃない そういえば x264 が去年XAVC絡みのコミット入れてたなーと思って久しぶりにgitを見に行ったら
3月に入ってからそこそこ更新が入ってて、3/14 に r2970 まで進んでた。
（ただしrigaya氏のバイナリは今のところ3/12のr2945まで）
めぼしい更新内容としては
・ultrafastで --trellis 0 にするの忘れてたので直した。（8/10bit統合時にバグったらしい）
・Progressive High, Constrained High, and Progressive High 10 のためのフラグ処理をすることにした。
といったくらいかな？ >>471
今のAppleは独自規格少ないイメージ いつからこのスレはProResを知らない素人さんばっかりになったの? このスレに政治の話持ち込んでもしょうがないと思うんだけどな 次世代のコーデックが技術的優位性だけではなく政治的要因も絡む以上
趨勢を見定めて何を使うかを考える上で政治要素は避けられないと思う 次世代コーデック絡む話ならまだいいかもだけど、上の話なんてもう関係ない規格のことだし testtubeで常にAV1を使う設定にしてるとしょっちゅうSD画質になってしまう
SDだけAV1にしても意味ねーと思うけど、GoogleをもってしてもAV1のエンコードは厳しいのか？
エンコード負荷が高すぎて使えねーとかならなきゃいいが >>481
常時AV1設定だと720p以上の画質が現れない
480p止まりになってしまう 名前出して良いのか分からないけどAV1でも720pで見られる動画はある。 >>482
違うよ。
「常にAV1を使う」は、「AV1で再エンコードされたファイルがある場合はそれだけしか一覧に出ない」というだけ。そんでもって
・AV1で再エンコードされたファイルがあるかどうか
・どの解像度までAV1で再エンコードされているか
は動画によって異なる。（再生数等の情報をもとにYoutubeが判断している）
つまり
・AV1が無い場合は普通にVP9等で見れる解像度一覧が出る。
・AV1が480pまでしか無いなら480pまでしか一覧に出ないし、720pまでしか無いなら720pまでしか一覧に出ない。
というだけの話。
そこそこ再生数のある動画でもAV1は無いか480pまでというのが結構多い。
720pまでというのもそこそこあるけど、1080pは割とレア。という感じ。
下の一覧から見れば、AV1で1080p等も選べるのがわかる。
AV1 Beta Launch Playlist - YouTube
https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS >>484
AV1でも1080pで見られる動画あるんだ…
ありがとう 2160p60のAV1は9700Kでもコマ落ちするな Googleの始めるクラウドゲームサービスに
おめーらの大好きなAV1やVP9が使われるって本当？ VP9は使われる気がする
AV1はまだ厳しいんじゃない？ ゲームサービスだと圧縮率より遅延が少ない方が良さげな気がするけど、
符号化/復号化の遅延的には次世代コーデックってどうなんけ？ コントローラがコンソール介さずWi-Fiで直接サーバと通信
ものっそいデータセンターでサーバ側の処理リソースは潤沢
あとはクライアントデコード環境を気にするだけでいい
それもChromecast Ultraで問題ないのでは 固定回線でもギガを買う時代が来るな
来るというか、帰ってくるか・・・ ギガって平成最も恥ずかしい用法だよな
世界に対して恥ずかしい バカの間でだけ流行ってる言葉だと思ってたらマスコミも使い始めて、通信キャリアがCMで使い始めてもうだめだと思った 早速AVIFのコマンドライン変換ソフトが出てきた。
https://github.com/Kagami/go-avif
Windows用バイナリもあるからすぐ試せる。 ギガって恥ずかしい
だがキャリアが使ったしまう国というほうがもっと恥ずかしい ギガって良いと思うけどな
月極の通信制限容量という意味合いはよく使われるのにそれを端的に表す言葉が無い。
漢字文化なら情報通信へんなんてのが出来ても良いものだと思うが文字コードなんかの関係か知らん作られる事は無いし
言語としてはコミュニケーションを取る上で悪くない進化だと思うよ。 昔はパケット数で計算されてたのにな
直感的じゃないからGBに移行したのは分かるけどそこからバイトが消されてギガが残るとは… 牛丼のメガ盛り、みたいなノリなんでしょ（投げやり） そういうのにすぐ飛びついてCMで使いまくるキャリアやMVNO業者があるからな >>496
進化じゃないね。退化でもないが。筋違いって感じだ
決して正当進化ではない
馴れ合ってるに過ぎないよ >>500
日本語なんて語彙が少な過ぎて多くの国から輸入しまくってるのに今更だわ。
概念そのものに対応する言葉が無いなら作るのがそもそもの筋だわ。 >>501
でも「ギガ」を使うのは完全に文法的に間違いだから許せんわ
牛丼は盛りをメガにするから意味が通ってるが、ギガは修飾相手の単語がないから
『「大量の」を消費する』『「大きい」を消費する』みたいで違和感がある
CMプランナーは、あえてネタ的に広告打ったが、情弱がネタとしてではなく
そのまま本気で外国人に対して使って日本全体が馬鹿にされそうで怖い スレチな話題をだらだら続ける人がいると日本全体が馬鹿にされそうで怖い 和製英語や日本語で使われてる意味が違う言葉なんていくらでもあるじゃん
マンションとか
エンコードをエンコとか略してるのも他所から見たら変かもしれないし 類似ジャンルの用途違いと省略を引き合いに出すなよ
品詞の誤用はレベルが違うだろ レベルが違うかどうかはともかく日本全体が馬鹿にされそうで怖い 海外だと通信量を表す際にギガという表現を使うのでそれが遅れて輸入されただけ
基本的にトップアップ圏の言葉だな 4Kなんかスマホどころかテレビの大画面でもほとんどの人には
違いが分からないんだからビットレートをケチっても良いよね...? >>512
そんな奴はおらんやろ
1.5Hで見て違い分からないなら近眼 50型サイズぐらいじゃないと分からないんじゃないのかな。 PCとTVだと見るときの基準が違うんだけどな
PCの場合は画素感が認知出来るギリギリのあたりで、使用用途で前後するけど
TVの場合は画素感が全く感じられなくて、可能な限り視野範囲を広く占有するのが適してるとされるし 何を言っているのか意味がわからない
PCとTVとか書いてるけど何の違いを言いたいの?
この次世代ビデオコーデックスレで発言している限り4K映像に関する話じゃないの?
「PCの場合」を作業UIについて言ってるとしたらスレ違いじゃないの? PCとTVじゃまず色レンジが違うじゃん
次世代コーデックが4KTVのみで扱われると思ってるならちょっとおかしい人だね >>519
>>518は視聴距離の話じゃないの。
4Kテレビの最適視聴距離は>>514にあるように画面の高さの1.5倍とか言われることがあるけど
実用面を考えるとPCの場合とかTVの場合とかで色々違いがあるよねっていう。
まあ元の話の>>512については、何と比べて違いがわからないと言ってるのかよくわからんし、
何を目的としたエンコードなのか知らんけど、ビットレートなんて自分で見て判断して決めればいいんじゃねで済む話では。 http://jp.gamesindustry.biz/article/1903/19032201/
「2018年の晩秋に行ったProject Streamテストでは，1080p，60fpsを得るためにゲーマーに要求した推奨帯域幅は25Mbpsでした」と氏は語る。
「実際には，私たちはそれよりはるかに少ない基準を使用しました ― 20Mbps程度です。
今年のローンチに向けて，我々はストリーマ，コーデック，ハードウェアおよびソフトウェアサービスを大幅に改善しました。
すなわち，約30Mbpsで4K 60fpsに達することができます。30Mbpsというのは，人口の大部分を除外するようなものではありません。
そのようなパフォーマンスであれば，我々は世界中のかなりの部分に到達できると考えています。ギガバイトのダウンストリームではないのです」 >>523の記事のタイトル
Phil Harrison：Stadiaはゲーム機からの「避けられない一方通行の変革」を始める
http://jp.gamesindustry.biz/article/1903/19032201/
モノによるとはいえゲーム中ずっと30Mbps占有とかやべえな。 Wi-Fiだとアベレージでは帯域確保出来ていても瞬間的に通信止まってたり遅延するから、結局バッファ確保したらそれなりのレイテンシになりそう >>512
一発で違うが分かる
さてはおまえ4Kを持ってないな 受け取ったパケットだけで画面を作って、ロストしたらしたぶん画質が低下するだけで動画の停滞は滅多にしないようなコーデックは無いものか。。
昔のアナログ放送みたいな >>528
表示までの遅延許容すればデコーダ側の造りで対応出来る
ただCPUとメモリ無駄食いしまくるからやらないのだと思うよ コーデック側で SVC (Scalable Video Coding) みたいな仕組みに対応していても
ベースレイヤーがロストしたらどうしようもないだろうしなあ。 動画はみんなTCPで転送してるからパケットが全部揃わないと遅延が発生する
デコーダーやコーデックが頑張ってもどうにもならんと思う HTTP3になったQUICでしょ？
これでデコーダーの方でキーフレーム以前のデータが遅れた場合にバッサリカット出来るかもしれない
ただLiveならそれで良いかも知れないけど映画とかは表示されないフレームがあって良いものか微妙だな QUICはTCP+TLSの代替だから基本的にデータを全部揃えるよ
多少のパケットロスはRAID5みたいに前後のパケットから補完できる
データのロストを許容する仕様も検討されているみたいだが まぁエラー訂正やるなら通信側でやるだろうけどな
どっちにしろデータ伝送効率とトレードオフ（帯域が減る） クライアント側でロストした部分をAIで瞬時に計算して
補完する未来がやってくるんだろうな ドワンゴのAV1リアルタイムハードウェアエンコーダのスライド
https://www.slideshare.net/RooTakatori/av1-138429446
libaom、SVT-AV1、x264と比較したグラフもある SVTとほぼ同じ画質で720p30fpsできるのはすげえな
SVTは30万円以上するxeonを2つ繋げて15fps超えるのがやっとなのに 四月一日に伝説のクソアニメがスペシャルで帰ってくる…だと？! >>538,540
ニコ動が使ってるFPGAってどれくらいのもんなんかな？ >>538,546
後日、会社のブログでより詳細な内容を公開予定だそう
ttps://twitter.com/yue_roo/status/1110921189818425344
https://twitter.com/5chan_nel (5ch newer account) まあでもニコ動はAV1採用まで生き抜くことができるかどうか・・・
VP9とAV1のライセンスプールかぁ・・・。
Sisvel Launches Patent Pools for VP9 and AV1
https://www.streamingmedia.com/Articles/News/Online-Video-News/Sisvel-Launches-Patent-Pools-for-VP9-and-AV1-130840.aspx
ビデオ符号化特許ライセンスプラットフォームを開始
https://www.businesswire.com/news/home/20190327005305/ja/
---
シズベルインターナショナルS.A.は本日、ビデオ符号化特許ライセンスプラットフォームの開始を発表しました。
このライセンスプラットフォームでは新たに、VP9規格関連特許に関する共同特許ライセンスと
AV1規格関連特許に関するプールライセンスの二つのプログラムが個別に提供されます。
当ライセンスプラットフォームのもと、株式会社JVCケンウッド, 日本電信電話株式会社, Orange, Philips,
東芝IPRソリューション株式会社を含む複数の革新的企業が所有もしくは管理する特許ポートフォリオのライセンスが開始されます。
--- そりゃAV1として使う分にはタダだけど、使用している技術特許が転用し放題な訳じゃ無いからな 典型的な特許ゴロだな…
AV1じゃなくてVP9も含めてるところが今更かよと思うし潜水艦もいいとこだ AV1がオワコンになってくれればもっと計算負荷が低くて圧縮率の高いVVCに削げ変わってくれる可能性があるから。
VP9/AV1/HEVC/VVC全部採用されずにAVCが残る可能性もあるか… > Opus is subject to the royalty-free patent licenses which are
> specified at:
> Xiph.Org Foundation:
> https://datatracker.ietf.org/ipr/1524/
> Microsoft Corporation:
> https://datatracker.ietf.org/ipr/1914/
> Broadcom Corporation:
> https://datatracker.ietf.org/ipr/1526/
Opusにも特許を保持する団体が存在するけどOpusそのものは自由に使えるで ただ、>>549は開発元では無い団体が勝手にライセンス料の徴収を主張するのが違うな >>553
PCにデコーダーバンドルしたら製品価格に含まれるかもしれない
あとはMSがストアで配布してるようなデコーダーが有料になったりとかあり得る(現状無料)
>>554
mp3やmpeg audioに関する特許関連もやってたみたいだから、昨日今日の組織じゃないね
>>558
そのページ読むと東芝やらNTTやら名前連ねてるじゃない
特許の管理をこの会社に委託してるんじゃね
別におかしなことではないと思う 8Kはまだ難しいと思ってたけど、BS8KがRTXで普通に再生できて拍子抜けした
もうそういう時代になったのか・・・ >>560
再生した時は、ディスプレイ解像度も8Kで滑らかに表示できた？ >>561
8Kのディスプレイは持ってないから分からん。4Kに表示した >>560
どうやってBS8kのデータをゲットしたの？ >>565
firefoxでdav1d有効化して試してみたら >>565
AVIFは多分まだブラウザで正式サポートされてないから表示させるにはこういうの使う必要がある
https://kagami.github.io/avif.js/
https://cconcolato.github.io/wasm-av1/
ivfファイルは確かコンテナに入ってない生の映像データだったと思う
x264でいう.h264ファイルみたいなもんか？ >>567
なるほどねー、最先端過ぎて、ブラウザすら対応できてないのか。
最新技術をいち早く投入するブラウザが追い付いてないんじゃ、一般のフリーソフトなんか半年は待たないと無理じゃん。
自分の検索が甘いのかと思ってたがスッキリした。情報どうも。 >>569
一応、Windowsのinsider previewなら表示に対応してる。
WICにも対応してるから↓みたいなWIC用のSusieプラグイン入れればをMassiGraでも読み込める。
http://toro.d.dooo.jp/slplugin.html#iftwic
あと今試したらIrfanViewでも読み込めた。
ただ現時点ではMSのデコードの出来がまだイマイチで画像のサイズによってはデコード結果が乱れたりする。
https://i.imgur.com/kuGGqe5.png
MSがやる気出してくれるなら結構色んなソフトでAVIFを扱えるようになると思うんだけどね。 AVIFはどこかのWebサイトで見れたけど、1フレームのAV1の動画が表示されてたな >>560
8KなんてGT1030やKabyLakeオンボですら再生できるぞ
無理なのはAMDだけ 8Kあたりは結構フツーに見れるイメージあった。オンボとか使ったこと無いからかな。MX420 GTS250 GTX570 GTX660Ti GTX970 RTX 2070だけど mx420(2002年)の時点でHDも完璧に見れてたしなぁ >>572
フレームレートを問わなけれ再生できるが、60fpsで再生できるのはRTXだけだよ
Pascal世代のGPUだと50fpsが限界、IntelのUHD Graphicsは4k60pまでだから15fpsが限界
どっちもBS8K(8k60p)を再生するとカクカク NHKが8K/120Hz対応コーデックなどNAB出展。88型の8K有機ELで上映も
https://av.watch.impress.co.jp/docs/news/1177302.html
8K/120Hzの映像をリアルタイム処理できるエンコーダーとデコーダーを紹介する。
映像符号化方式にはH.265/HEVCを採用し、Main10プロファイル(4:2:0/10bit)まで対応。ビットレートは最大480Mbps。
https://av.watch.impress.co.jp/img/avw/docs/1177/302/8k03_o.jpg 【悲報】新元号対応GPUはGM206以降のみ
ｳｿﾃﾞｽ ・スマートフォンを接続するだけでフルHD液晶＆フルキーボードが使えるようになる「NexDock 2」
https://gigazine.net/news/20190403-nexdock-2/
最近はスマホは新しいのを買うけどPCは古いままな人が多いから、こういうのが普及すれば最新の動画再生支援機能を利用して、
古いPCで動画を視聴するよりも快適に視聴できるようになるかもしれないな
（画面のクオリティー次第だけど） 韓国企業のSamsungはAOM陣営についたのに日本企業は旧体制としてAOM陣営と対立するとか悲しくなるな 製造業として、自社製品消費してくれる企業の多い側に付いてるだけだけどな
そういやDRAMとNANDの余剰在庫は夏前に整理付きそうなんで、関連製品の購入時期に注意
市場に安い次期の製品在庫があっても、小売フランチャイズ元等でストックにして値を戻してから商戦向け商材・特価品のふりして放出とかしやがるんで留意 それは商売の基本では。
価格が上がらないまま売れ筋が大容量品に移ると大変。 安く買うタイミングはこういう転換期に集中して情報入れておいて
平時に無駄な労力割かないのがベスト
今回は容量や方式的な世代交代も関係ないしな もはや存在価値が…
当面はHEVCいずれはVVCで流れは決まった なんかロイヤリティフリーなコーデックをやたら毛嫌いする人が居るんだなぁ… >JPEG XL is based on a combination of FUIF and Google's Pik. FUIF uses the same entropy coder (MANIAC) as FLIF, but does progressive and lossy better.
いまいち進展がわからんJPEG-XLだがGoogleのPikとロスレス最強FLIFの融合だと判明
どっちも2,3年前に少し話題に上がってから音沙汰無しだったけど生きてたのか
これもJPEG-XTを闇に葬ったシズベルにAV1共々沈められ兼ねんな なんでシズベルを敵視しているんだ
原因はそこじゃないだろう ここ最近の消費と経済の構造ってすごく歪んで来てるよね
ガチャゲーみたいにその作品の価値以上に対価を得てる人たちは
規制や処罰されてしかるべきだと思うし
頑張って映像や画像の技術研究成果出して貢献している人たちには
ちゃんと対価が行き渡って欲しいと思う 今回ばかりはサブマリン特許でパテントトロール行為紛いのことやってるからな
折角HEVC/AV1はTV放送/ネット配信で棲み分けできてんのにお互い足引っ張りあって停滞するとか馬鹿じゃねーのとしか思わん 特許に問題があるならAV1策定中にでも指摘すればいいのにこれから普及していくぞってタイミングで主張しだすのってどうなの 何で権利者側が仕様策定中のものに対してわざわざ調査しにいかなきゃならんの？馬鹿なの？ >>595
AV1だけじゃくてVP9に対しても主張してるんだから早い段階でわかってたことでしょ 面白いことになってきた。
JVC KENWOOD、NTT、東芝か。
当然の権利とも言えるから三社が悪いわけでもないけど。
NAB Showに合わせてきたのかなぁ。 ロイヤリティフリーのコーデックったって特許の塊だからな
単にその権利を行使しないというだけで
ロイヤリティフリーじゃないものは苦労したぶん正当な対価を得る権利が有るみたいに言うけどさ
何処で利益を得るかの違いだけなんだよな 別な見方すれば、技術系・映像音響関連の著名企業が保有している特許のチェックですら出来てなかったのにパテントフリー騙っていたって事だからな
特許保有側も具体的な実装が出来てこなくちゃ何処まで侵害されてるかも解らんし
特許というもの自体が抵触したくない側が躱すべきもの アルゴリズム特許を事前にすべて精査するなんて不可能だろ だから特許保有側は把握している保有特許への抵触範囲を提示して訴えもせずにいてくれている
ステルスとか言っている馬鹿がいるけど、見落としているのはコーデックのプロジェクト側の責で、パテントフリーを謳い文句にしていて、それが出来ていない方が問題だと思うが
特許保有している側が隠している訳でも無い（だからこその特許制度でもある
訴えもせずに見落としている側に特許保有側が手間して明示化してるのにステルスも糞も無い罠
出方待ってくれてる時点で、ここらへんの対応が甘すぎると言われる日本企業らしいと言えば、日本企業らしいけどな 特許ってどうしようもなくしょうもないものまで千差万別だぞ
そういうのに限って文面がどうにでも解釈できるように物凄い曖昧に書いてたりするからな
特にアルゴリズムに関連するものはそんなんばっか
だから後だしするには都合が良い ・高いコントラストと豊かな階調再現を実現した「ピュア W プリント」
自然光＋透過光で奥深い色を表現
https://dc.watch.impress.co.jp/docs/news/1178580.html
印刷物もHDRみたいな状態になってきたようだ
今後は、静止画動画問わずSDR→高精度HDR変換に需要が見込めそうだな JVC/NTT/東芝 ←必死に抵抗
vs Apple←勝ち組
Google/Intel/Amazon ←優勢 MPEGの特許ってパナソニックがかなり多かったと思うのだけどそこは何も言ってこないのね 抵抗も糞も筋通せてないのにドヤ顔していたVP9/AV1勢の失態ってだけ
志高けりゃ権利侵害してもいいって訳じゃ無いからな mpeg2の特許って切れ始めてるんじゃなかったっけ？ 筋通せて無いのはTOSHIBAの方だろw
今頃特許主張して恥ずかしくないのかよw 失態と言えるほどのことかどうかはまだわからない。
開発段階で特許の精査はやってたけど、完璧にやるのは難しいだろうし、
AoMediaでは特許訴訟が起きることを見越して防衛基金を用意したりもしている。
今回シズベルに集約されてる特許群が本当にAV1/VP9に適用できるものなのかも不透明だし
適用できたとしてどれくらいの影響を及ぼすものかもまだわからない。
今後の交渉なり法廷闘争なりの行方次第だから、それを注視していくしかない。
現時点で失態ダーとか権利侵害ダーとか騒いでも無意味。 >>608
ガキなのか、そういう道理が理解できてない社会人かは知らんけど
見落としする方の責なんだから仕方ない罠
そういう法律やし 特許の文面を一度でも見たこと有れば精査することがどれだけ大変かわかるよ
ま、今後どうなるか見ものだな H.265/HEVC特許暗黒時代 - Qiita
https://qiita.com/yohhoy/items/c2579097a507b1fbdddb
更新されてた。MPEGがEVCというコーデックを開発してるそうな。
> 異なる方向性のアプローチとして、ライセンス・フレンドリ(licensing-friendly)を掲げた
> MPEG-5 EVC(Essential Video Coding)の開発も始まりました。
> 20年以上経過して枯れた要素技術のみで構成しつつ、現行H.265/HEVC程度のデータ圧縮性能を目指しています。
> 2018年10月のRequirements公開から2020年1月の最終ドラフト(FDIS)に向けて、
> 映像コーデック研究開発としては異例のスピード目標となっています。
今年1月中旬に行われたMPEG 125のミーティングでは
> The target coding efficiency for the call for proposals was to be at least as efficient as HEVC.
> This target was exceeded by approximately 24% in the responses to the call for proposals, which were evaluated at this meeting.
ということで、最大でHEVCより24%くらい効率的になりえると評価されたらしい。 参考URL等
■EVC (Essential Video Coding)
・Essential Video Coding
https://mpeg.chiariglione.org/standards/mpeg-5
・MPEG 124 - Macao
https://mpeg.chiariglione.org/meetings/124
(MPEG issues Call for Proposals for a New Video Coding Standard expected to have licensing terms timely available)
・MPEG 125 - Marrakesh
https://mpeg.chiariglione.org/meetings/125
(MPEG starts work on MPEG-5 Essential Video Coding)
・EVC - Essential Video Coding / MPEG-5
https://forum.doom9.org/showthread.php?t=176055 よく分からないんだけど
EVCは古い技術を使ってHEVCと同等の圧縮率を目指し、特許料を安く、分かりやすくする
VVCはいわゆるH.266に相当して、最新技術を盛り込み、より高い圧縮率を目指すよ
ってことかな？わざわざEVCなるものを作るということは、VVCも特許地獄の可能性が高そう EVCはVVCの掌握に失敗した某企業が立ち上げたやつ
ライセンスフレンドリーとはフリーでも安いでもなく、単に彼らと対立する立場の企業を締め出して仲良しだけで作る=ライセンス条件について合意しやすいという意味でしかない
VVCと違って参加企業は非常に少なく、実質的に彼らの持ち込みコーデックにそのままスタンプ押すだけの状態
ちなみにその24%というのは輝度だけの性能で、VVCに彼らが持ってきた提案と同じで、故意に色差分のビットを輝度に回す最適化をしてる EVCってロイヤリティフリーのことかと勘違いしてたけどそういう意味か こんな感じなのかな？
■EVC (Essential Video Coding)
●baseline profile
・「特許切れの技術」および「ロイヤリティフリーにできる技術」のみが使われる。
・現時点の評価では、AVCと比べて30%程度の圧縮率向上。
●main profile
・baselineに加えて、いくつかの(ライセンスが必要な)符号化技術が使われる。
・符号化技術ごとに独立した実装が行われ、それぞれを容易に有効化/無効化できるようにする。
仕様確定後に適切なライセンス合意が行われなかった場合はその技術だけ切り離すこともできるようにしておく。
・現時点の評価では、HEVCと比べて24%程度の圧縮率向上。 24%程度の改善じゃ、箸にも棒にもかかりませんよ
しかもこんな中途半端なコーデック、ハードウェア再生支援に組み込まれる可能性も低い
GPUメーカーはボランティアで再生支援してるんじゃないのだから 開催中のNAB Showで、IntelとNetflixがSVT-AV1の発表をしたとのこと。
4Kp60/10-bitのライブ配信も可能って書いてるな。
Intel Finally Announces SVT-AV1, To Be Used By Netflix - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=Intel-SVT-AV1-Announced
Intel, Netflix to Deliver AV1 Scalable Codec to Power Next-Gen Compression Tech for Visual Workloads | Intel Newsroom
https://newsroom.intel.com/news/intel-netflix-deliver-av1-scalable-codec-power-next-gen-compression-tech-visual-workloads/
> This codec makes it possible for services ranging from video on demand
> to live broadcast of 4Kp60/10-bit content on IntelR XeonR Scalable processors,
> including the recently launched 2nd-Generation Intel Xeon Scalable processor. そのうえ、出来たデータは数万じゃ効かないぐらい再生されるからな
事業者のエンコード時の消費リソースやコスト感覚が別次元だし
そのうえあのNetflixだし
動画エンコードの探求に「終わり」はあるのか？
https://gigazine.net/news/20180614-end-of-video-coding/
2015年にNetflixの技術者が初めてMPEG会議に参加して、将来の動画コーディングのための文書を発表しました。
その際に、Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑性が高まるとしてもまったく問題にしない」というスタンスであることを伝えると、議長から「では、どのくらいの複雑さを許容できますか？」と尋ねられたとのこと。
回答の準備が整っていなかったNetflixの技術者は「最悪のケースでは100倍まで」と答えると、100人はいたであろう動画コーディングの専門家たちからは大爆笑が起こったそうです。
議長は「心配しないで。彼らはみな『新しいこと』を試すことができると、幸せに感じているのです。たいていの人は『3倍まで』と答えるものだから」と話したそうです。 Netflixなら1つの動画あたりの再生数が多いだろうから
エンコード負荷より回線帯域のほうが重要だろうね x265もそれなりに仕上がっていた3年半前の時点でコレだからな
そこで非公式ながら100倍まで容認するってんだから、Xeon SPの力押しも厭わないだろうさ
基本的に処理比率的に絶対量は多くは無いにしろ、複雑化した際にボトルネックになりやすいベクター演算関係でのパフォーマンス考えるなら今のところはIntel系の方が正解だし AV1の特許の件についての声明が出てた
The Alliance for Open Media Statement - Alliance for Open Media
https://aomedia.org/the-alliance-for-open-media-statement/ 英語よくわからんけどSisvelの発表で業界とか投資家あたりに不安な動きが広がったから、ちゃんと対応は考えてるから心配するなっていう声明をとりあえず出したって感じだと受け取ってる 要約「以前から掲げているライセンスで扱えるよう対応するから心配するな」 ・AOMedia参加メンバー間では合意が取れてるよ
・開発時にコーデック、法律の専門家とともに特許の精査は完了してるよ
・特許に関する防御のための仕組みもあるよ
って感じ
まあ心配せんでも大丈夫やで、ぐらいの内容で>>631の言う通りとりあえず感が強いですね
つか具体的な特許リストがまだ出てきてないから対応のしようがないですし ChromeでAV1再生するとGPUの3Dの%が異様に上がる割にCPU負荷が上がらないんだが、GPGPU使ってたりするのかな?気のせい? Chromium EdgeくんAV1再生時に拡張機能不要にしてくれるのかね? Presentation: Latest Technical and Business Progress with AV1
https://people.xiph.org/~negge/NAB2019.pdf Introducing SVT-AV1: a scalable open-source AV1 framework
https://medium.com/netflix-techblog/introducing-svt-av1-a-scalable-open-source-av1-framework-c726cce3103a
SVT-AV1 is currently work in progress since it is still missing the implementation of some coding tools and therefore has an average gap of about 14% in PSNR BD-rate with the libaom encoder in a 1-pass mode.
The following features are planned to be added and will decrease the BD-rate gap:
Multi-reference pictures
ALTREF pictures
Eighth-pel motion compensation (1/8-pel)
Global motion compensation
OBMC
Wedge prediction
TMVP
Palette prediction
Adaptive transform block sizes
Trellis Quantized Coefficient Optimization
Segmentation
4:2:2 support
Rate control (ABR, CBR, CBR)
2-pass encoding mode Allegro DVT Introduces the Industry First Real-Time AV1 Video Encoder Hardware IP for 4K/UHD Video Encoding Applications
https://www.design-reuse.com/news/45981/allegro-dvt-real-time-av1-video-encoder-hardware-ip-4k-uhd-video.html ・GoogleとAmazonが和解。Fire TVでYouTube、ChromecastでAmazonプライムビデオ視聴が可能に
http://www.phileweb.com/news/d-av/201904/18/47157.html
Appleだけ孤立する構造になりそうだな >>641
SVT-AV1のスコアが悪いのは
-enc-mode 3でエンコードしてるから(>>142は-enc-mode 0)
GOPの間隔が24と他のエンコーダーより短く設定してある
>>637に書いてある通りまだ実装してない符号化ツールが多いため
なのでもう少し上がる余地があると思う >>643
Fire OSでGoogle Playも使わせろや >>636でAV1のエンコードはHEVCの2倍程度の遅さまで高速化されて、画質はHEVCを上回ったという報告になってる
ロイヤリティフリーだからみんなしてエンコーダーの開発に凌ぎを削ってるのが良い結果になっていると思われる >>646
使えるよ。実際使ってる
apkを4つくらいインストールする必要があるが AndroidベースのカスタムOSだから、Googleのアプリは動くがプリイン出来ない
Amazonの独断で機能削って軽くしたり使用状況のモニタしとるからな
音声も抜いてくるAlexaもFire HDタブにぶっ込んできてるし、尚更無理 >>650
apkでアプリも追加できない奴を基準にすればな ､wミミミﾐ主彡彡ﾐゞ,
ミミｼ"~~_,,.,__~"'ヾ乍t
ﾐﾐ' ' ´_,.,_！_,,..,,_ ヾﾐ
'ミ ｨ彡'"`'＂'"~`'ミ 'ﾐ
ﾐ ィtｯｧ 〉 （ ttｯｧ､ }｝
}} "´ ,.. / "ヽ 丶、 {{
（} /`^ｰ^ﾍ、 `'{）
、 ノ :.:.:_J_:.:.ヽ ,!
＿ヽ /"二ﾞ二`ヽ ,ｲ
´:::::::::::>､ '⌒ ノ 〉`ー-
::::::::／ 〉 ` ﾆﾆﾆ´ /:::::::::::: スレチだけど知らない間にYouTubeの詳細統計情報にDebugInfoという謎の欄が追加されてる。
AV1も自動設定(TestTubeの方)で取得される環境増えてるっぽい?今までワイの環境で自動だとVP9だったし。 ちゃんと環境（OS、ブラウザ名、バージョン、AV1絡みのconfig等を変更しているかどうか等）を書かないと意味なくね。
というかTesttubeの「自動」ってどういう挙動だったっけ・・・？ Windows10 Pro Ver1809 Build17763.437 64bit
Intel(R) Core(TM) i5=8250U CPU @ 16.0GHz 1.80GHz
8.00 GB DDR4 (7.86GB使用可能)
Firefox Developer Edition 67.0b12(64bit) UpdateCh:aurora
AV1に関する設定は特にいじっていない。 >>656
Win10 Home 1803 Build 17134.706 64bit、i7-4702MQ
Firefox 66.0.3
・TestTube「自動」だとav01は使われない。
試しに media.av1.use-dav1d （デフォfalse） を true に変えてみたが、やはりav01は使われない。
Chrome 73.0.3683.103
・TestTube「自動」だと、720p60まではav01になる。1080p60はvp09になる。
>>636のPDFによると
Firefox 67 （2019/05/07予定）
Chromium 74 (2019/04/23週予定)
でdav1dがデフォルトになるらしい。
そっちのFirefox67がTestTube「自動」でav01を利用するようになってるのは、そのへんが関係してるのかもね。 今動画確認してみたらさらりとvp9に戻ってた。設定ミスか? 今は2160p60のAV1が生成されてる動画もあるんだな。
COSTA RICA IN 4K 60fps HDR (ULTRA HD) - YouTube
https://www.youtube.com/watch?v=LXb3EKWsInQ
昨年11月末時点ではこの動画もAV1は720p60までだったんだが。
8K(4320p)のAV1もあったりするんだろうか。 あ、8K(4320p30)のAV1もさくっと見つかったわ・・・。
PATAGONIA 8K - YouTube
https://www.youtube.com/watch?v=ChOhcHD8fBA
Go Central Japan in 8K HDR Hyperlapse - 中央日本 - YouTube
https://www.youtube.com/watch?v=XsVGYfsb3sI とある案件を調べている最中に偶然引っかかったのだが、SVT-HEVCというのはx265の親戚みたいなものなのか？
いまいちよくわからん Intelの開発したソフトウエアHEVCエンコーダー
何らかの政治的力でx265でも使えるようになった 傍目にはよく分からんけど、システム要件がXeonとなってるから
Xeonを使うような大規模システム向けにx265を拡張・チューニングする手間が省けてラクみたいな感じじゃね 何故コーデックかの様にx265やx264を扱うのか >>668
直近のやりとりでは普通にエンコーダとして扱ってると思うが、何に対して言ってるんだ？ >>670
渾身のボケに14秒差で割り込んでしまってごめんな・・・ >>654 だけど
また720pまでだけど自動でAV1で取得されるようになった。わけわかめ... >>665
AVX512アピールするためのものじゃない？
AMDは当分実装しないだろうから ､wミミミﾐ主彡彡ﾐゞ,
ミミｼ"~~_,,.,__~"'ヾ乍t
ﾐﾐ' ' ´_,.,_！_,,..,,_ ヾﾐ
'ミ ｨ彡'"`'＂'"~`'ミ 'ﾐ
ﾐ ィtｯｧ 〉 （ ttｯｧ､ }｝
}} "´ ,.. / "ヽ 丶、 {{
（} /`^ｰ^ﾍ、 `'{）
、 ノ :.:.:_J_:.:.ヽ ,!
＿ヽ /"二ﾞ二`ヽ ,ｲ
´:::::::::::>､ '⌒ ノ 〉`ー-
::::::::／ 〉 ` ﾆﾆﾆ´ /:::::::::::: NAB 2019: Twitch Talks VP9, AV1 and its Five-Year Encoding Roadmap
https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/NAB-2019-Twitch-Talks-VP9-AV1-and-its-Five-Year-Encoding-Roadmap-131163.aspx
Twitchの担当者へのインタビュー抜粋
・来月、人気コンテンツ向けにFPGAを使ったVP9配信を開始する。
x264比で25%ほどのビットレート削減になるが、35%減という目標もある。
・人気コンテンツでのAV1の採用は2022～2023年頃と見込んでいる。
・（人気コンテンツ以外も含めた）AV1への完全切替は2024～2025年頃と見込んでいる。 Liveでvp9使うようになるのか
YouTubeより進んでるな ところでAVS2とAVS3って何？
中華コーデック？ ブラウザはChromeとFirefox(Microsoft,Apple)
動画配信はYouTubeとNetflixさらにHulu(Amazon)
半導体メーカーはIntelとnVIDIAさらにARM
逆にどう考えたら普及しないと思えるのか教えてほしい。 特許自体開示情報で潜るも糞も無く、解釈の拡大適用でも無くて
AV1出来てから買った特許でも無いのにサブマリンも糞も無いのだけれどな
ライセンスフリーが売りなのに詰めが甘かっただけだ罠 NTTのいちゃもんだと思うんだけどなぁ。オープン化が好大きなWeb業界でAOMediaに勝てないと考えて潰そうとしたんでしょ。
実際VVCも搭載されるブラウザなんてSafariくらいやろ。てかSafariも搭載してくれるか怪しい。 そもそもの話、PCやスマホの場合、デコーダーはOS側で対応して、ブラウザーはOSが対応しているデコーダーを利用して呼び出して再生するだけでいいんじゃないのかと思ったりしなくもない
わざわざブラウザーがデコーダーまで抱える必然性は低いように思えてならない オープンなのは良い事だけど、それを傘に権利侵害を問題と考えなかったり、
調査の不備棚に上げて権利者悪者みたく扱うのは全然別だと思うが >>688
> 解釈の拡大適用でも無くて
> AV1出来てから買った特許でも無い
・どの特許が対象になってるか把握してるの？
・「拡大適用でもない」というのは何を根拠に言っているの？ >>693
煽って誘ったのは悪いが、そっちも解ってるんじゃん
そういう当該特許が何かや特許詳細わからんだろ？
詳細や抵触箇所が不透明なのだから、サブマリン特許とか潰そうとしているとか一方的に非難も出来んのだよ
成否の判断が第三者からは難しい
なのに非難している方にも同様のレス付けないのは何故なんだい？ >>694
根拠もないのに確定情報であるかのような書き方をするのはやめるべきだと思うんだよね。
詳細もはっきりしないのにサブマリン特許だーとかAV1潰しだーとか騒ぐのもどうかと思うけど、
「特許侵害は確定だー、AV1陣営の不備だー失態だー」という書き方をするのも
同様によくないだろっていうのは>>609でも書いたとおり。 世の中の特許は全て革新的な技術で取られてると思ってるおめでたいやつがいるんだな
完全に俺の感覚だけど95%は糞みたいな特許だぞ
そういうのに限ってどうとでもとれるような曖昧な書き方になってる
だから後出ししてくる
NTTだからそんなことないと思ってるかもしれないけど、大企業ほどそういう特許が多い そんか曖昧な書き方してたら当たり前に特許自体が通らんよ
ウチみたいな技術系の中小企業でも数十は保有してるし、申請出すだけでも偉い手間も金も掛かる（特許の有効化に手数料と書類作成でだけでも数十万軽く飛ぶ
申請時はそれを仕事にしている専門家に審査されるから糞厳しいのよ
曖昧な主張が通るのは申請時より係争時で、特許無効や不該当にしたがってる連中の方が、本質が全然別な代物の特許や既製品の実装例使って、表面的な類似性だけで専門家では無い裁判官に勘違いさせるようってのが多い
裁判官も上告されてミスジャッジが後から露呈するの嫌がって、下手に判断行わず大抵は示談調定持っていく事に一生懸命になるのが多いけどな 内情知ってるNTT社員の駆付擁護かと思ってたら真相は門外漢のエスパーがイキってただけで草不可避 >完全に俺の感覚だけど95%は糞みたいな特許だぞ
あー、はい。そうですか… 映像の圧縮技術で特許を完全に回避なんかできるわけがない。 黎明期ならいざ知らず、ここまで高度化した現在においてフリーとか乞食の夢物語にすぎない でも、mpeg2失効したしそれから基本的な技術変わってないんじゃないの？パラメーター変えただけのくそ特許がいっぱいあるってこと？ 実行コストが低くて効果が大きい圧縮法から採用されてるからな
あとは処理性能や作業記憶領域の確保量的な、時間経過でコスト評価が軽くなる部分も食い潰して
新たな発明・発見的なものが無い限り、高コストで採用を先延ばしてたものをどう折り合い付けて実装していくかという状態やし 特許に抵触してるかなんて有能な弁護士を沢山雇って調査しないと分からんだろ
AOMedia連合に加入してる企業は腐るほど金があるから、金に物言わしてその辺の事情に最も精通してるに違いない
だからロイヤリティフリーと言えるんだよ
基本的にド素人がなに言っても無意味なんだよな それはお互いの企業どちらも同じでしょ
そして両方に「正しいに違いない」とか言うん？
結局雇い主優位にするための雇われ集団だからな
事の正否関係なく、クライアントにとってより黒に近いものを裁判で白に出来る奴ほど有能という業界だし アメリカトップのIT企業様集団に勝てるわけがないんだよなぁ。 VP9、youtube以外じゃ見かけた事が無いな
泥スマホではカメラアプリに使われてたりするん？ >>708
ゲーム機に使われてるんやと >>296 最近のゲームのムービーでWebM形式は割とよく見るぞ
あとふたば これからAV1が標準になる思って良い？
Amazon、Facebook、Google、Intel、NVIDIA、Microsoft、Adobeなどが関わってるとなると広まるとしか思えないけど まだ油断は禁物だってJpeg2000さんが草葉の陰で言ってた 広まるというか、連中が一緒にゴリ押しし始めると移行せざるをえなくなる NTTドコモの配信サービスは利用してないからどうでもいいが
ドコモ端末でYouTubeやPrimeVideoが利用不可になれば乗換不可避だわ
あのAmazonとGoogleさえも和解する程の痛手 >>718
いくらなんでもそんなことするわけないだろ、docomoもそこまで馬鹿じゃない。そもそもAndroidがAV1デコードにも対応するだろうし、docomoが意図的にその機能を省くほどのメリットはない AOM AV1コーデックと特許管理
https://qiita.com/yohhoy/items/0f6aec829a05b6292316
これ読むとAOMに訴訟した企業、団体は防御的解除によってAV1の利用権を失うみたいに読めるけど Sisvelの主張だとデバイスメーカーに課金するようだけど、その直後にサムスンがAOMediaに加入したのは偶然じゃないだろう
サムスンにアップルと二大端末メーカーを敵に回してまで特許侵害を主張する意味があるとは思えない >>722
docomoが売っているスマートフォンには流石にAV1デコーダ搭載されるんちゃう?
dアニメストアとかdTVとかはどうなるか予想できないけど。
dav1d 0.3.0 Sailfish: ARMed to the teeth ? Ewout ter Hoeven ? Medium
https://medium.com/@ewoutterhoeven/dav1d-0-3-0-sailfish-armed-to-the-teeth-af5bbf845a16
> dav1d 0.3.0 decodes AV1 video’s 24% faster on SSSE3, 26% on SSE4.1
> and 4% on AVX2 (all PC), and 12% faster on Arm64 (mobile).
・Chrome74やFirefox67でdav1dがデフォルト有効に。
・ffmpeg4.2が出たらHandbrakeもdav1dを組み込む予定らしい
・Youtubeはいくつかの4K/8K動画をAV1でエンコードしている
AV1 4K & 8K - YouTube
https://www.youtube.com/playlist?list=PLvndfuQ5JldKMffLOhQ6pLdO0euZfq_40 >>714
jpeg2000なら医療や映画、衛星の中で活躍してますよ >>728
知らない人多いけどデジタルシネマはjpeg2000だからね デジカメやらスマホやらがjpegのままな限り他が普及する事は一生無い だからこそAppleがHEIFを世界標準にしてくれることを期待したんだがな Intel's SVT-AV1 Video Encoder Saw Yet Another Performance Boost In April - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=SVT-AV1-Ending-April-High
>SVT-AV1 bef6750を適当にベンチマーク
>主にencmode8の性能を測りたかったので比較対象はx264、x265のmedium
https://twitter.com/fg118942/status/1123009783496228864
https://twitter.com/5chan_nel (5ch newer account) ＜技術者を苦しめるフレームレート＞
なぜ、NTSCカラーは29.97fpsなのか ・・・ http://i.imgur.com/UHsHBQW.jpg いやNHKがアナログハイビジョンで60FPSにしたんだが、
NTSC陣営が猛反発してデジタルでは59.94FPSのままになってしまったんだよ
60FPSにしとけば色々と楽だったのになあ 企業の利権の影響が消費者の利便性を損ねちゃうのは悪しき伝統だよな
直ちに問題はない
大きな問題はない
・・・ rav1eの新しいのは何かバグってるっぽいな、Quantizerが奇数だと不安定。
以下適当に20MBぐらいで比較、CPU100%使えないやつは並列化。
rav1e 1.0.2293 / rav1e GUI v1.12
Setting : Speed=10 Thread=16 Quantizer=156
Progress : 0:16:03 (963s/3.214fps/1280x720/3096frames/20.0MB)
https://imgur.com/X4fIQBO.jpg
https://imgur.com/igQIPRv.jpg
https://imgur.com/jWylYvN.jpg
https://imgur.com/9OdQetk.jpg
libaom-av1 1.0.0-1629-gd224f625e (FFmpeg N-93634-geeca67e023)
Setting : -pix_fmt yuv420p -c:v libaom-av1 -threads 8 -tile-columns 4 -cpu-used 8 -crf 44 -b:v 0 -aq-mode 3 -strict experimental
[x10] Progress : 0:9:41 (581.46s/5.328fps/1280x720/3096frames/19.8MB)
https://imgur.com/XrM1as9.jpg
https://imgur.com/MykKQyW.jpg
https://imgur.com/WwGNr0B.jpg
https://imgur.com/RB3uTbL.jpg >>737
乙
rav1eってまだver 0.1.0だし全然安定してないよね AV1とx265の質感の差が大きいので設定を変更してやり直し。
x265は割とごっそり高周波成分を削っていく感じで代わりにエッジ部分の品質が高い。
AV1の方は高周波成分を残した分そっちにレート食われて輪郭部の品質が落ちてる感じで、
デフォで実写向きのチューニングになってるっぽい。
libaom-av1 : -pix_fmt yuv420p -c:v libaom-av1 -threads 8 -tile-columns 4 -cpu-used 8 -crf 44 -b:v 0 -strict experimental
[x10] Progress : 0:9:3 (543.78s/5.701fps/19.2MB)
https://imgur.com/2GOIIiP.jpg
https://imgur.com/B4UDRNy.jpg
https://imgur.com/uNKfLtP.jpg
https://imgur.com/ciYqeBP.jpg
x265 (10bit) : --preset=slower --crf 28
[x4] Progress : 0:9:49 (589.95s/5.256fps/19.3MB)
https://imgur.com/2peuotJ.jpg
https://imgur.com/aLJ95h3.jpg
https://imgur.com/xahR1tY.jpg
https://imgur.com/r8wFhjb.jpg
ちなみにlibaom-av1を並列化せずに[x1]でエンコードした場合はCPU7-16%で0.976fpsぐらいだった。
https://imgur.com/bVDX8mU.jpg 圧縮ロジックの優劣見るならアニメ絵使わない方が良くないか？ ガチで比較するならソース自体にアーティファクトがあるものより無圧縮の素材がおすすめやで
https://media.xiph.org/video/derf/ アニメ素材での性能がどうなのか？ ってのを気にする人も少なからずいると思うしこれはこれでいいと思う
アニメは無圧縮のソースが入手しにくいけどな アニメでもBDソースならまだいいけど
TV録画なんて元から汚い物で比較されてもな BDだと誰でも簡単にソースを入手出来るわけじゃないから追試がしにくいのがね
>>743のとこに日本のアニメスタイルの動画があればいいんだけど >>747
エンコ系スレにいるのはほぼアニメマニアだろうし 実写は動き検索大変で遅い、縮まない、縮めるとすぐノッペリでエンコする意味ないからな エンコーダーの性能テストにはアニメが好んで使われてるってどこかで読んだぞ >>747
AV1の標準データセットっぽいobjective-1-fastは実写映像だけで構成されてるわけじゃなくてゲームの映像も入ってるわけだしそれならアニメだってちょっとくらいいいじゃん
Twitchとかあの辺の影響で入ったんだろうけど、日本のアニメだってNetflixやらCrunchyrollでそれなりの数をエンコードしてるだろうし でもこのスレの場合、アニメでしかエンコしない、他のソースは徹底的に拒否するってなると
>747みたいなこと言いたい気持ちもわからんでもない >>752
× このスレの場合、アニメでしかエンコしない、他のソースは徹底的に拒否する
〇 このスレの場合、
・アニメソースでテストして結果を書き込んでくれる人はそこそこいる。
・実写ソースでそれをしてくれる人はあまりいない。
・自分ではやらないのに他力本願で自分好みのテスト結果を求めるだけの人はそこそこいる。 アニメと比べて実写はソースごとの差異が大きすぎて比較しにくいってのもある
風景を垂れ流すだけのヒーリングビデオとか動きの激しいスポーツ中継とか人が入り乱れる大作映画とか
それぞれコーデックによって結構傾向も変わってくるしな
誰かが何かで検証したとしても外野がそれじゃ不十分あれとこれとそれもやれそこまでできないのかつかえねーな
くらい言われたり・・・ なんでもいいから、実写での比較画像プリーズ
でないと、アニメではAV1は全然使えねーって評価で終わる JPEGの圧縮ノイズに見えてしまうからPNGで見たかった… >>737
そういえばこれって2passでエンコードしてる？
AV1はcrfでエンコードするときも2passじゃないと効率悪いんだけど アニメとかいいから実写とか3DCGとかピクサーでもええからはよ 日本アニメは単色塗りつぶし域が大きいので特殊なソース
そこに最適化はしてくれないだろう。。 最適化というか、フレーム情報の周波数域の分布解りやすくて
ロジック煮詰め無くてもマクロブロックの配置難易度が低いから最適化自体必要ないだろと
HWエンコーダで極端にアニメ絵の方が縮むのもそこらへんだからなぁ
一部のanimeオプションも周波数成分の扱いとビットレートの再分配の必要性低いから余計な処理しないで処理リソース他に回す方向のもので、
アニメへの最適化というより単純化の宣言みたいなもんだからな とりあえず余計なもの外して必要な機能だけにしたバッチ書いたので試してみたい人はどうぞ。
VP9/x265/AV1(libaom-av1)を10並列でゴリゴリ動かすバッチを入れておいた。
AV1だと720pならメモリ12～16GB推奨、フルHDは32GBぐらい必要だと思う。
Multi_FFEncoder.7z
https://1.bitsend.jp/download/5ab2492b8dd50328fe72217593c5e92a.html >>762
乙
メモリ8GBしか積んでないからキツイなｗ
並列数の指定が出来るといいんだけど
あとmp4boxの動作に必要なdllが足りなくてmux出来ないっぽい >>765
じゃあ自分で書いたbatも公開してみる
>>735のグラフもこれで描いた
https://github.com/f11894/video_benchmark
あと、並列数を弄ろうと思って>>762のbatを覗いて見たけど複雑過ぎて理解出来なかった
並列数10でハードコードされてて弄れなさそう？ Multi_FFEncoder_v0.01.7z : [x5]のバッチを追加
https://1.bitsend.jp/download/756a9928e33a0840cf74de78aa19f5d0.html
>>764
DLLはこの辺落として入れてみて。
JS.dll / libcryptoMD.dll / libsslMD.dll ＞ GPACK x64
カスタムインストールでMP4BOXとVC2015 Rutimeの2つをインストールするか
インストーラのEXEを7zipで解凍してDLL3つを bin\MP4BOXフォルダにコピー
https://gpac.wp.imt.fr/downloads/gpac-nightly-builds/
VCRUNTIME140.dll ＞ Visual Studio 2015 Visual C++ Runtime（vc_redist.x64.exe）
https://www.microsoft.com/ja-jp/download/details.aspx?id=48145
MSVCR100.dll ＞ Microsoft Visual C++ 2010 Runtime (vcredist_x64.exe)
https://www.microsoft.com/ja-jp/download/details.aspx?id=14632
エンコードしたAV1が再生出来ない時は、MPC-HCなら最新版のLAVFilterを入れて外部フィルタを使うように設定
https://i.imgur.com/3alfIQO.png >>769
わざわざありがとう
x5ならうちのPCでも使えそう ここは可逆圧縮コーデックの話題もしてええの？不可逆系のみ？ 映像編集用のコーデックは編集ソフトのスレで聞いた方がいいと思うよ なつかしいな。最後のスレは例のDTV板壊滅で落ちるまで7年半かかってたが・・・
映像可逆圧縮総合スレ Part3 （過去ログ）
https://echo.5ch.net/test/read.cgi/avi/1247236230 俺も最新の可逆コーデック知りたいぞ。どこ行けばいいんだ?
まだバランス的にamv4一択だとかならいいです。 じゃあ自分が使ってる可逆コーデックでも紹介しとくわ
Lagarith Lossless Video Codec 速い割に圧縮率高め
https://lags.leetcode.net/codec.html
MLC Codec 遅めで圧縮率重視
http://www.linek.sk/mlc/
MSU Lossless Video Codec 2Dゲーム動画の圧縮用途に置いては最強の圧縮率
http://www.compression.ru/video/ls-codec/index_en.html
Ut Video Codec Suite 有名どころ
http://umezawa.dyndns.info/wordpress/
---------ここから下は有料----------------
MagicYUV 一番新しい可逆コーデック 4Kサポート 無料版はあるが古いバージョンを使わされる
https://www.magicyuv.com/
AMV4 軽い割に圧縮率高め
http://www.amarectv.com/buy.htm
Huffyuvは時代遅れで今や速度も遅いし圧縮率も低いので省いた すまん間違えた
2Dゲーム動画の圧縮用途に置いては最強の圧縮率なのはこっちMSU Screen Captureの方
MSU Screen Capture Lossless Codec
http://www.compression.ru/video/ls-codec/screen_capture_codec_en.html 昔は一時ファイルにLagarith使ってたけど、長らく更新されないのもあってUTに乗り換えたな
他におすすめあったら知りたい 可逆は普通にUtVideoでいいと思うよ。
無料だし、今でもこつこつ改良されてるし、フォーマット毎に分かれててわかりやすいし、
高速なT2シリーズ（UM**）も追加されてるし、ffmpegでも入出力できるし。
AMV4も良い性能みたいだけど、有料だし、「YUVで入力したらYUVでしかデコードできない」という欠陥仕様があるので
使い方によっては動画編集ソフトに読み込めないことがあるので注意が必要。（その場合でもAvisynthを経由すれば読めるかもしれんけど）
>>780-781はMLCやMSUを挙げてるけど、いまどきこれらを実用してる人なんているんだろうか・・・。 ひとつ忘れてた
Zip Motion Blocks Video 2Dゲーム動画の圧縮用途でMSU Screen Capture Lossless Codecと同じくらいの圧縮率だがそれより軽い
http://www.dosbox.com/
Dosboxに付属してるのでコーデック単体の提供はない
>いまどきこれらを実用してる人なんているんだろうか
まあ挙げたのは保存用途だからキャプチャ用途にはUtVideoでいいんじゃね >>780
ありがとう。MSU、magicYUVての興味あるなぁ 汎用性と圧縮率の高さでH.264 losslessが使いやすそうだな Memory optimizations for all resolutions (#242)
https://github.com/OpenVisualCloud/SVT-AV1/commit/430c2a6fd2889c2f1b4a3351b146ad6dfc94c4a7
SVT-AV1のメモリ消費量めっちゃ減った。
今まで1080pで5GBくらい食ってたけど半分になった。 編集前提の可逆や低圧縮の非可逆系コーデックだと、一般的にはAppleやBlackmagicDesignのコーデック使うことが多いような気がする
Ediusが最新版からAppleのコーデックにも対応するようだから、今後動画の編集もWindowsに一本化される可能性が高くなるだろうし
（AppleはiPhoneを重視しすぎてMacがすっかり手抜き状態になり果ててしまっているようだし） おぉBlackmagicDesignの話題が出るとは
Blackmagic Motion JPEGで撮りためてる素材があるんだけど
スマートレンダリングで編集する方法がないかずっと探してる
どのスレで聞けばいいんだろうこれは >>791
AviUtlでAVI/AVI2 File Reader使って「開く」から読み込んで、書き出したい対象範囲を選択後に右クリから「選択範囲の切り出し」して「AVI出力」で無劣化出力は出来ると思う
連結はファイルからAVIファイルの操作→AVIファイルの連結 >>794
ただの「トリム＆再エンコ無し出力」ならそれでもいいだろうけど、「スマートレンダリング」と言った場合、
一般的には「要変更部分の再エンコード」も含むだろうからAviUtlでは無理だと思う。 >>795
スマートレンダリングが目的では無く、劣化の最小限化が目的じゃ無いの？
MotionJPEG自体はフレーム内で圧縮は完結していて、mpeg系みたいにフレーム間参照していないから再エンコード不要な訳なんだが
だから不可逆圧縮のJPEGだとしても再圧縮せずに編集できるのが売りな訳でなんだし
音声トラック側の処理に問題無ければ目的を果たせるのでは？
スマートレンダリングはフレーム間参照しているコーデックでカット発生部分の寸断されたGOPのみをエンコードして劣化を最小限にする為の処理を賢く適用する機能の俗称で、無劣化処理出来るのにスマートレンダリング使う必要有るの？ ああ、でもMJPEGなら A、B、C に分けてAとCは無劣化出力、Bは編集して再エンコ出力して
後から連結でA+B+Cにしてスマートエンコードもどきみたいなこともできるのかな？
やったことないからわからんけど。 >>797
× スマートエンコード
〇 スマートレンダリング
まあ>>791が考えてる「スマートレンダリング」がどこまでの機能を指してるか次第だろうね。
あとはDavinciスレあたりにでも行ってみればいいんじゃないだろうか。
【Blackmagic Design】 DaVinci Resolve Studio Part2 【カラーグレーディング】
https://mevius.5ch.net/test/read.cgi/avi/1555764417/ >>792,798
面白そうなんで調べてみたが、なんとな、できない希ガス。
スマートレンダーキャッシュって機能があって、そればっかりヒットする。
Resolveは元々カラーグレーディングが強力で発展してきて、編集機能とか強化されたは最近。
なんで無調整の切り貼りみたいな編集はあんまり想定してない気がする上に、ユーザー層も
マシンパワーでゴリゴリってノリが強い感じ。
最近編集やら色々強化されて使いやすくなったけど、開発スピード早いんで油断してるとハマったw >>800
「Resolve スマートレンダリング」でググれば、
Resolve16で「Bypass re-encode when possible」が実装されたって記事がさくっと出てくるけど・・・ >>796
> スマートレンダリングはフレーム間参照しているコーデックでカット発生部分の寸断されたGOPのみをエンコードして
> 劣化を最小限にする為の処理を賢く適用する機能の俗称で、無劣化処理出来るのにスマートレンダリング使う必要有るの？
TMSRだとそんな感じだけど、動画編集ソフトだとエフェクト入れたりした部分だけ再エンコードして
それ以外は無劣化コピー出力するという機能をスマートレンダリングと呼んでたりするからね。
SVRT - Wikipedia
https://ja.wikipedia.org/wiki/SVRT >>802
スマート云々のスマートが何所までの機能を網羅すべきなんか定義は無いからね
ただ対象がMotionJPEGの素材であって、素材の切り分け的な作業に止まらず、加工までするなら元の書き込み内容から乖離ありすぎると思うけども >>803
無料版で使えるかどうかとかMotionJPEGが対象になるか等は知らんから気を付けてな～。
試してうまくいったかどうかを後でDavinciスレに報告しておいてもらえると助かる。
>>804
元の書き込みは>>791の
> Blackmagic Motion JPEGで撮りためてる素材があるんだけど
> スマートレンダリングで編集する方法がないかずっと探してる
で、別にカット編集に限定してはいないから、特に乖離してはいないと思う。
まあ最初からスレチな話題ではあるけどｗ BMPCC 4K買ったからDavinci使い始めたけど、RGBのままHEVCにしようするとVFW使えなくて無圧縮か中間経由必須なのが残念だよね
>>787
h.264はロスレスでもデコード負荷が高いみたいでHWデコードできるソフトじゃないと編集激重になるっぽい?
録画に使ったらVegasで編集にならなくてTMPGencでカット&Utに再エンコするはめになった
1素材だけだったからなんとかなったけど
>>786
Magicはultimate買ったけど
14bitまであるのがメリットだけどHDR素材とかエフェクトかけまくる訳でもなければ10bitまでのUtで充分だと思った というかH.264のロスレスってデコード対応してるHWあるの？
ロスレスなら4:4:4だろうしビットレートも非可逆より高いだろうし 今見たらnvdecでh.264書いてないな
encはMaxwellから対応してるし(つべうpにnvencロスレスで上げてた)、TMPGencではプレビューヌルヌルだったから勝手にそう思ってたけど
うろ覚えだけど圧縮率は他の可逆とそんな変わらなくて微妙だった記憶
Vegasはプレビューがgeforceと相性悪かったかでHW切ってたんだよね
環境は7900X+1080ti >>807
> ロスレスなら4:4:4だろうし
H.264のロスレスは、クロマサンプリングが4:4:4限定になるわけじゃなく、
4:2:0も4:2:2:も4:4:4も全て「High 4:4:4 Predictive Profile」になるってだけだよ。
HWデコード対応してないから重いというより、フレーム間の依存関係とかもあるので
根本的にデコードが重くて編集作業向きじゃないってだけ。
ロスレスで保存したくて、なおかつファイルサイズを抑えたいという場合くらいしか出番がない。
編集作業ではシークや逆再生時の軽さなども求められるから、デコードの軽いイントラ系コーデックが主に求められると聞く。 スレチの話題に優しく議論してくださった皆様すみません
dvシーケンスみたいに無劣化で切り貼りできるだけで十分で
ID:acvacarG0 さんの回答姿勢に間違いはないですありがとう
AdobeがDVも含め「スマートレンダリング」を使ってたので
言いやすいし最近はその語法でまとめていいのかなと思って
接続部分の再エンコードとかを深く求めたわけでもないです
切り貼り以外の加工を心配してくれた人たちもありがとう Firefox67でAV1再生にdav1dが使われるようになったけど、自分の環境だとVP9とデコード負荷は変わらないレベルになったと思う AVX512には対応してるの？（AVX512言いたいだけ でもAVX512処理に特化したコード書くと4chでもメモリ帯域足りるかどうかだからな
足回りや剛性無視して馬力と価格だけで車の優劣語るようなもん まあ16コアやAVX512はDDR5待ちだね
DDR4じゃ宝の持ち腐れ x265はAVX512の有無でかなり速度違うけど、それでもまだ全然本気じゃないってことか ほんの10%程度を「かなり」と言っていいものか・・ 10速くなってもAVX使うとオフセットでクロック10%くらい下がるからプラマイ0？ x265に手を出してみたがx264に比べてエンコードオプション多すぎて
どれか一個でも有効にするとエンコード速度が更に遅くなりそうでどれを有効にしようか選べなくてワラタ H.265がやっとソース以下で変換出来る様になってきたと思ったら… そんな事より、30fps, 60fpsに統一しろぃ 「NHK技研公開 2019」はフルスペック8KとAR、VR、インテグラル3Dと未来の放送技術満載だ
https://kakakumag.com/av-kaden/?id=13895&;lid=k_topics_article_13895
ついに8K/120Hz駆動のフルスペックに到達した8K放送 8KでBT2100になれば俺にはそれ以上は分からないと思ってるけど240hzモニタ持ってる身からするとfpsだけ他に比べて低い気がするんだよね 英国ＢＢＣは300fpsが理想だって言っていたな。
列車が通り過ぎるデモで違和感なく見れるのが300fpsだった。
記事のソースはリンク切れ 60fps以上だったかで人間の脈拍が上昇するというのは昔の話か 脳のクロック数は脈拍数と比例関係にあるからな
象とネズミでは時間の感じ方が違う
人間の眼に小動物が早送り映像のように素早く動くように映るのは
我々人間の心拍が彼らよりものろまで処理クロック数が低いから
彼らネズミには加速装置が生まれながらに装備されている >>832
50と60の公倍数だから50Hzソースを持ってるBBCとしては300Hzが欲しいんだろ 訓練されていない人の視覚分解能は、時間軸方向で能力高くて50ms程度だから、一般人向けで300Hzは相当オーバースペックだと思うが そんで知覚分解能的には多少の超過は見込んだ方良いんで
ゲーマー向けモニタの240Hzってのは落とし所的に2割マージン載せで良い数字だったりするんだが
デジタル表示機的に考えればコンテンツリフレッシュレートの24Hzや30Hz、モニタ標準リフレッシュレートの60Hzとも公倍数取れるしな
これからの規格で何世代も古い走査線処理方式のに足引っ張られても意味ないし
PALはあくまで処理方式で50Hzとは限らず、欧州で「PALで50Hz」が普及したってだけで、PALで60Hzも出来てたりする ホールドボケ解消だと900fpsくらいいるけどね
これは過去に論文も出てる カメラのファインダーも60じゃ話にならんけど120だと随分追っかけやすくなる。240くらいで落ち着きそうな予感。 >>824
>>822の記事ではスーパーハイビジョンとしか書いてないから
地デジは４K飛び越して８Kになるんじゃね
VVCの実用化にしても相当先になるだろうし 地デジ４Ｋ開始にあたって、現行の12セグHDを7セグHDに画質を落とす予定。
全局ＭＸテレビ並みと考えていい。 放送局は画質画質というわりに
画質を落とす決断を平然と行うから
どういう思考回路してるのか理解に苦しむわ ワンセグってまだ使ってる奴いるのかね
いるとしてもどこかのチャンネル1つ（13セグメント=ワンセグ13チャンネル分）をワンセグ専用に確保して、
フルセグ用の帯域を使わないようにしてもらいたい 放送局は制作機材のアップデートが必要になるからテレビの高画質化には消極的な印象 普通にビットレート盛れば良いだけ
撮影・制作機材以前にビットレートが足りないせいで
ブロックノイズやモスキートノイズ多すぎ あーそういう話ね。画質と聞いてピクセル数の話かと勝手に思ってた。 svt-hevcでエンコしている人はいないか？
svt-hevcの速度、画質が気になる
あと、対応しているcpuは？ スマホ普及でワンセグ受信機が激減しているからな。
５Ｇ時代には、完全に無くなるね。 >>850
別にXeonじゃなくてもRyzenとかでも対応してるよ
画質は詳しく試してないから分からんけど >>853
LDMは韓国規格だね。反日のＴＢＳらしいわ。 歳を取って視力が低下したから、
高解像度にされても意味ないわ。
fpsを上げてくれた方がまだ恩恵がある。 >>853
つうか地デジのエンコーダーがまだ画質を向上させる余地が有ることにビックリだわ
画質向上させて全局1920x1080iにしてくれれば地デジはもうそれでいいよ 地デジ４Ｋに割り振るために低レート化する話をごまかして書いてるだけだろ
より圧縮すんだから画質はむしろ下がんじゃね
「現行放送の画質をできるだけ維持」って画質が下がることを否定はしてない >>862
一般の評価だと大体劣化なしだが、お前らがみたら重箱の隅とか見えちゃうから一目でgdgdなんだろうなw 素人か？
円盤も買ってテレビも録るんだよ
同じじゃないからな ■画質比較 蒼き鋼のアルペジオCadenza
＜メンタルモデル/ナチの瞳＞
（１）Blu-ray ⇒ http://i.imgur.com/gJMFJFt.png
（２）BS11 ⇒ http://i.imgur.com/El93aKM.png
Blu-ray版は、BS11より小さい赤い文字がくっきりしているね。
＜戦闘シーン＞
（１）Blu-ray ⇒ http://i.imgur.com/JHIz0OG.png
（２）BS11 ⇒ http://i.imgur.com/aUj6hOK.png でも平気で好きなコンテンツの著作権画像キャプチャすると
BDもリッピングでAACS解除してやがるし
単なる御都合主義の犯罪者じゃん imgurに上げると圧縮されて味見変わるから圧縮されないアップローダーにあげてくれ 法律を厳密に遵守してたらアニオタの活動なんてほぼ成り立たないよ
知らぬふり見てみぬふりのズブズブな関係で成り立ってる危ういものだ 成り立たないから平然と犯しますってんなら大間違いだけどな
それも自主的な主張の書き込みの為だってんだから利己的でしかない罠
自認自重してるのならまだしも、自ら晒してくるスタイルなら手に負えんよ 研究、検証目的の引用だと言われたらそれまでだけどな 画質比較のためアニメのキャプチャをサンプルにしますってのは
著作権法上の引用に該当する余地は100%無いがな
そのアニメの作品自体に関わる評論で、キャプチャを持ち出す必然性があってはじめて引用に該当する
画質についてあれこれ言ってるときに円盤買えだのキャプチャ貼るのはアニメオタクとしてどうなのかとかいらんチャチャ入れてくるやつも入れてくるやつだが、
法律は多少破ったとしても、ちゃんと理解しとけ >>880
問題は引用じゃないと100%立証できるか否か
画質の比較、となると無理だな、勝てない。 引用だと認められるためのハードルは結構高いからね（引用以外の著作権の制限事項も）
法を厳密に適用していけばネットの画像投稿のかなりの割合がアウトだけど、
それをいちいち食って掛かって誰の得になるんだっていうね
あからさまに悪質だったり権利者自身が困ってる場合はもちろん別だが 比較を個人で確認するならともかく
キャプチャ映像全体を個別で不特定多数に観られるようにアップロードする必要無いもの
品質差が確認出来る箇所のアップとかで良いのに、わざわざやるんだから
検証映像は良いとしてもキャプチャ画像単品は素でアウト >>873
（左上の）青い光線の周辺に出てるブロックノイズは分かりやすい >>882
問題は100%勝てるのか？という話
もっと言えば採算合うのか、ということになるが。
まぁ画質比較の資料としてキャプチャとなるととてもじゃ無いが無理だな >>874-875
なんぞ？pngのiccプロファイルでも書き換えられるのけ？ コーデックに関係ない法律解釈はスレチだから他所でやってくれないか うちも録画したのPCで編集してエンコして保存してるからわかるわ。
本当BS11ですら結構辛いよ。BDがどれだけ画質良いかよく分かる BS11は1920の割にレート低いからね
地デジ1440の方がまだ画質は良いよ エンコするならAmatsukazeは必須だよな
MXの糞画質でもだいぶマシになる
Amatsukaze使わないと見るに堪えない svt-hevcのバイナリが欲しい
どこかにない？ >>894
rigayaさんのバイナリなら使えるんじゃ？
GUIのほうにSVT-HEVCのチェックボックスあったはずだし 早速実験しようとしたけどエラーが・・・
x265.exe --svt --svt-preset-tuner 6 test-1080p.mkv -o test-1080p.mp4
x265 [warning]: svt-preset-tuner should be used only with ultrafast preset; Ignoring it
x265 [error]: yuv: width, height, and FPS must be specified
x265 [error]: unable to open input file <test-1080p.mkv> >>898
当たり前だからまずはヘルプや公式サイトのドキュメントを見て使い方くらい把握しろ。
原因まで書いてあるエラーメッセージを貼って何がしたいんだお前は。 バイナリ以前に、そもそも当人がスタートラインに立てて無いんじゃねーか よく見たらこいつAvisynthスレでビルドについてだらだらつぶやき続けてる奴じゃん・・・ >>893
俺はプロ用ソフトで直してる
まぁそこまでやるのはよほどのやつだけだが ffmpeg入れてこんな感じのコマンドにしたらいけたんだけど、設定が悪いのか物凄く縮み過ぎてしまった
ffmpeg -i test-1080p.mkv -strict -1 -f yuv4mpegpipe - | x265 --y4m - --svt -o test-1080p.hevc x265 [warning]: svt-preset-tuner should be used only with ultrafast preset; Ignoring it
これ回避する方法ない？
どうやらultrafastに固定されちゃっているみたい x265のcrf 18はqpに換算するとどんな値になる？
教えて欲しいんだけど ソースによる
一概に換算できるなら別モードになっちゃいねぇ罠 >>908
そっか・・・
選択が結構シビアなんだな >>909
極端な話だと、画面一杯単一色のフレームは量子化係数上げても画質は維持できるけど
情報量の多いゴチャゴチャした画のフレームが同じ量子化係数で画質が維持できる訳が無い訳やね
フレームの情報量によって画質に対する好適な量子化係数なんぞ一定じゃ無いのよ 何でqsvやnvenc、svtはcrfでエンコできないんだろうか・・・ svtエンコって難しいな
ffmpeg -i test-1080p.mkv -strict -1 -f yuv4mpegpipe - | x265 --svt --profile main10 - --y4m -o test-1080p.265
↑のコマンドでやったら、
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
が出たよ
ちなみに--profile mainでは問題なし >>914
ffmpegのオプションに-pix_fmt yuv420p10leが足りないせいとかかな >>913
qsvとnvencは品質固定モードがあるだろ。できないのはsvtだけだよ。だからsvtは使い物にならない >>917
だからsvtでエンコする人が少ない訳だ そりゃ個人用途ならsvt使うメリットは微塵もないわな 保存用エンコとかストリーミングの大本みたいな
10Mbpsぐらい食わせてのエンコードを想定してるんじゃね SVTはリアルタイムエンコード用だろう
保存用にはx265使えばいいわ コーデックというわけではないが、Windows 10のバージョン1903からMKVファイルのサムネイル表示がサポートされたみたいだね 何も考えずに昔インストールしたICAROSで未だにサムネイル表示させてるけどもう要らないんだろうか >>922
MKVなんて1507(Windows 10の最初のバージョン)からサポートしてたよ >>925
何自分の投稿に誘導してんだよ屑
意図的に他人みたいな素振りしてる分マルチポストより悪質じゃねーか 【NVENC/VCE】ハードウェアエンコーダーを語るスレ2【QSV】
858 ：名無しさん＠編集中 (ﾜｯﾁｮｲ 2d01-6I5X)[]：2019/06/09(日) 08:45:45.31 ID:TcuoKwh70
NVENCのnonrefp、aq、aq-temporal、bref-modeって有効にした方が良いのかな？
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
925 ：名無しさん＠編集中 (ﾜｯﾁｮｲWW 2d01-vJIE)[]：2019/06/09(日) 20:45:25.52 ID:TcuoKwh70
誰かこの質問に答えてやってくれ
https://mevius.5ch.net/test/read.cgi/avi/1551446228/858
【NVENC/VCE】ハードウェアエンコーダーを語るスレ2【QSV】
863 ：名無しさん＠編集中 (ﾜｯﾁｮｲWW 2d01-vJIE)[]：2019/06/09(日) 21:11:56.34 ID:TcuoKwh70
>>862
死ねカス
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
927 ：名無しさん＠編集中 (ﾜｯﾁｮｲWW 2d01-vJIE)[]：2019/06/09(日) 21:12:30.09 ID:TcuoKwh70
>>926
死ねカス 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) Ryzen 9 3950Xで、エンコードが捗りそうだな >>932の記事に貼られてる参考記事リンク
Firefox brings you smooth video playback with the world's fastest AV1 decoder - Mozilla Hacks - the Web developer blog
https://hacks.mozilla.org/2019/05/firefox-brings-you-smooth-video-playback-with-the-worlds-fastest-av1-decoder/
AV1 Ecosystem Update: May 2019
https://www.singhkays.com/blog/av1-ecosystem-update-may-2019/
後者ではVisionularって会社がAuroraっていうAIを利用したAV1エンコーダーを開発したということも書いてる。
x265 veryslowよりエンコード速度が32.2%も速くて圧縮効率も上と書いてるけど本当なのかな。
https://www.visionular.com/ 動き予測なんかはAI使ってもいいんじゃないかと思ってるが たぶん右、たぶん左、メンドクセ―から一括skipってことになるのか AIにも向き不向きあるからな
処理を速くする為にブロック捜査と参照関係の評価を手抜きするのに、それで精度落ちる精度（圧縮率の悪化）をAIでカバーして影響を最小限にってのには使えるけど
絶対的な圧縮率向上にはAIの効果は殆ど無いのよね
基本的に絶対的精度を求めないで、及第点以上な結果を素早く出すのには向いているから、ロジック処理で精度が出せなかったり、意図的に出さなかったりするケースの補完用途向き
aqの強度調整やフレーム内・フレーム間適用先の自動判定には効果はありそうではある 低ビットレートの古いコーデックの低画質画像の推測補完復号にAIは活躍しそう 圧縮率だけで見ればそうだろうけどエンコ時間…
注) HM=HEVC,VTM=VVC
https://i.imgur.com/UX30fGl.png この分野に限った話じゃないけど最近AIの定義ガバガバすぎない？
各種フレーム間予測にAI使って圧縮率向上します
ってそれAIつーかそれ用に最適化したプログラムってだけじゃん
チューリングテスト完全突破したのだけをAIと呼んでほしい 活用側は学習結果の反映・活用出来れば良いんだし、学習部分は必要が無い訳なんだからロジック実装の一部化する罠 強化学習だとオブジェクト判別が例に出されること多いけど、1pass目でオブジェクト判別みたいなことできれば圧縮にも好影響あったりするのかね 好適な量子化計数の予測精度は向上するから1passVBRの成果は向上するだろうけど、2passだと推測要素が殆ど廃されるから差は僅差になるだろうな Firefox 67には次世代コーデック「AV1」の世界最速デコーダーが採用されている
https://gigazine.net/news/20190612-firefox-67-av1-supported/
Firefox 67 Betaの使用統計データによると、Firefox 67 Beta上で再生されたムービーのうちでAV1コーデックのものだった割合は2019年2月は0.85％、同年3月は3％、
そして2019年4月には11.8％となっていて、AV1コーデックの普及がインターネット上で加速していることが示されています。
「高性能なハードウェアデコーダーが市場に投入されるであろう2020年頃まで、AV1は新しすぎて採用されないだろう」と予測する専門家もいたそうですが、
GoogleやNetflixが開発を主導していることもあり、インターネット上では急速に次世代コーデックへの対応が進んでいるというわけです。 Chromium以外YouTube最適化されてないし一般人はAVIFが現行のwebp(gif)代替になるとかしないと恩恵受けられなさそう。
結局2020年代になるやろ Firefox67でtesttubeで常にAV1に設定してYouTubeでAV1 betaのプレイリストの動画再生し
統計情報見てもcodecがav01にならずvp09のままだな ハードウェア条件とかあるのだろうか 単純にYouTubeがfirefoxにAV1を流さないだけだろ ・メモリやCPU使用量を制限できる“ゲーミングブラウザ”「Opera GX」
https://pc.watch.impress.co.jp/docs/news/1190163.html
ハードウェア再生支援の効かないクソ重たい動画を再生中にブラウザーを開いている場合にも良さそうだな >>949
そんなバカなと思って試してみたけど、うちも Firefox 67.0.2 / Chrome 75.0.3770.80 でAV1にならずVP9になってた。
以前は普通にAV1になってたんだが、なんでだろね。 >>949
今あらためて試してみたけど、Firefox 67.0.2 / Chrome 75.0.3770.90 で問題なくAV1になった。
ちなみにTestTube「自動」での挙動は以下のとおり。（4月の挙動は>>657参照）
Win10 Home 1803 Build 17134.829 64bit、i7-4702MQ
Firefox 67.0.2
・TestTube「自動」だと、720p60まではav01になる。1080pはvp09になる。
Chrome 75.0.3770.90
・TestTube「自動」だと、720p60まではav01になる。1080pはvp09になる。 真偽は分からんけどredditにYouTubeのエンジニアを名乗る人が現れて内部的な問題で一時的にAV1が使用不能になってたって言ってる
AV1 on YouTube paused for boring procedural reason
https://www.reddit.com/r/AV1/comments/c0c7e9/av1_on_youtube_paused_for_boring_procedural_reason/ ttps://www.realtek.com/en/press-room/news-releases/item/realtek-launches-worldwide-first-4k-uhd-set-top-box-soc-rtd1311-integrating-av1-video-decoder-and-multiple-cas-functions
RealtekからAV1ハードウェアデコーダ搭載のセットトップボックス向けSoC登場 >>317
手元に
Xeon 5080 Dual Processor
Phenom 9750
みたいな(X64+SSE3)
環境が残ってるから微妙な気分になったわ
あ、K8 Athlon64X2(AM2)はSIMD遅いから部妙だQUADFXならいけるかもだが >>958
調査対象がSteamユーザだから一般のPCユーザよりは高めの結果が出てるかと。 SSSE3すら対応してないCPU使ってるカスが快適なAV1再生なんか求めないから大丈夫 あんまり関係ないけど、YouTubeの左の三メニューの「新機能を試す」がTestTubeに飛ばなくなった。URL直打ちならTestTube行けるんだけど。 eve-vp9も強いな
商用ライセンスだから個人には関係ないけど USB 3.0初搭載の「Raspberry Pi 4 model B」が登場 - PC Watch
https://pc.watch.impress.co.jp/docs/news/1192218.html
GPUはVideoCore VIで4K/60p H.265のデコードをサポートとな
ベッドサイド動画ザッピング専用クライアントマシンでも作ろかな https://i.imgur.com/6gpFsU9.png
https://i.imgur.com/JthQcLb.png
Eve-AV1凄まじいな
libaomのcpu-used=1と同程度のエンコード時間で大幅にVMAFスコアが高い
ぜひ使ってみたい AV1、普及させるにはハードウェア再生支援を実装したGPUをさっさと出さんとな TMPGEnc辺りが採用してくれれば個人にも恩恵はありそうだけど 9900Kがゴミのようだ
Zen2のH.265/HEVCエンコ結果リーク
ttps://i.imgur.com/ExuYYof.png このスレにx265をソースコードからコンパイルしている人っていたりする？ >>971
32コアもあるのに遅いスリッパがゴミだった >>973
たまにやってるけどrigayaさんのほうが早いから
全然つかってない >>976
コンパイラー何使ってる？
VisualStudio？ >>971
画質求めるならやっぱソフトエンコになるん >>977
環境変えたらMSのは動かなくなったからmsys使う方にした
大本はrigayaさんの公開＆解説してくれてるもの >>979
俺もMSYS2でx265のエンコードを試みたんだけど
どうしてもcmakeで失敗するんだよね・・・
cmake -G "MSYS Makefiles" ../../source -DWINXP_SUPPORT="ON" -DCMAKE_INSTALL_PREFIX="
/mingw32/i686-w64-mingw32" -DENABLE_TESTS="ON" -DENABLE_SHARED="OFF"
-DCMAKE_BUILD_TYPE="Release" -DCMAKE_CXX_FLAGS_RELEASE:STRING="-O3
-DNDEBUG -march=native -static-libgcc -static-libstdc++ -static"
-DCMAKE_CXX_COMPILER="i686-w64-mingw32-g++" >>980
今、やってみたけどビルドできたよ
「rigaya x265 ビルド」で検索したら出てくる
rigayaさんのHPを参考に1からやり直してみては >>983
ありがとう！わざわざ試してくれたんだ(´･ω･`)
HP見ながらもう一度やり直してみるよ・・・ >>983
rigayaさんのHPからMSYS2、CMAKE, HGをインストール・整備したあと
配布している ./build_x265.sh をダウンロード・実行してみた。
だけど結果はエラー。
そのときのログが↓
https://www.dropbox.com/s/68whl5elyfvyrk6/x265_log.txt?dl=0
うーん、Windows7で実行してるのがまずいかな？ MSYS2なんだしWindowsのバージョンは関係ないと思う。実際にwin10の俺でもエラーが出てるし 自分がやった失敗は265.shへのリンクを右クリ保存してた
クリックしてリンク先にジャンプ→テキストのみを保存ってやってる？ ともったけどファイルは正常みたいね
SVT-HEVCの文字が見えるから、それに対応する前の↓でやってみては
https://1drv.ms/u/s!AuTrC8hUJOKhgpogvzIw-QgJp4NDBw >>985
最初につまづいてるのはここだよねﾏｽﾞｺﾚｦ(´･ω･`)ｸﾘｱｽﾚﾊﾞ
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Source/App/CMakeFiles/SvtHevcEncApp.dir/build.make:262: ../../../Bin/Release/SvtHevcEncApp.exe] エラー 1
make[1]: *** [CMakeFiles/Makefile2:453: Source/App/CMakeFiles/SvtHevcEncApp.dir/all] エラー 2
make: *** [Makefile:128: all] エラー 2 https://www.phoronix.com/scan.php?page=article&;item=ryzen-3700x-3900x-linux&num=4
Ryzen 9 3900Xはえーな FPGAと3900Xでエンコードするのとでどっちが値段安いのかね
FPGAリアルタイムエンコーダーの開発費用は含まないものとしてボードだけの値段
素人にはさっぱり相場がわからない 相場も糞も開発費含まなきゃ製造原価やん
業務用だとボード単体で個人が入手出来るかも怪しい代物で、システム1式なら新車買えるレベルのがごろごろしてる >>988
ありがとう
そのシェルスクリプトを走らせてみた
でも結果はやっぱりエラーが・・・
↓
https://www.dropbox.com/s/z0wpyzn8pcmi5a8/x265_log2.txt?dl=0
一番最初に表示されるエラー；
CMake Error at CMakeLists.txt:602 (list):
list GET given empty list
CMake Error at CMakeLists.txt:603 (list):
list GET given empty list
これが何かを示唆している気も・・・ >>993
バージョンを判定する部分がうまく動いてない("-- x265 version +-"のところ)
気になるところはCMakeが古いのとmsys2のMercurialが使われてるところかなぁ
Pathが通ってるか、そもそもwindows側にインストールされてるか確認するといいかも? >>994
MSSY2のMercurialをアンインストールし、
改めてWindows版のMercurialをダウンロードしてきてインストールし直してみた。
加えてCMakeもポータブル版ではなくインストール版を改めてインストールし直してみた。
その上で再度x265ビルドスクリプトを動かしてみたんだけど・・・
https://www.dropbox.com/s/e0raz1sarltzo9y/x265_log3.txt?dl=0
さらにあっさり失敗するようになってしまった
むむむ・・・ >>995
今試したら"Mercurial 5.0.2 Inno Setup installer - x64 Windows"だとそのエラーが出た
MSI installerの方は大丈夫みたいなのでそっちで試してみて このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 161日 5時間 11分 42秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
