次世代ビデオコーデック総合スレPart4 【HEVC/VP9/AV1/VVC等】
レス数が1000を超えています。これ以上書き込みはできません。
H.264/AVCの後の様々なビデオコーデック全般について語るスレです。
■主な次世代ビデオコーデック
・H.265/HEVC
・VP9
・AV1 (AOMedia Video 1)
・VVC (Versatile Video Coding)
■前スレ
次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1548833021/
次スレは>>980が宣言してから立ててください。 ■各ビデオコーデックの概要や状況（2019年7月上旬時点）
●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年頃になる見込み。
コンテンツ配信/ハードウェア/ブラウザ系などの主要企業がサポートを表明しており、
ネット配信を中心として広く普及することが期待されている。
YoutubeやVimeoでは既に一部の動画をAV1でも提供し始めており、
Chrome74/Firefox67で高速デコーダdav1dが採用されるなど、ブラウザの対応も進みつつある。
YouTube TestTube
https://www.youtube.com/testtube ●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年7月上旬時点)
●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 9.0)
〇HEVC
mainおよびmain10。TuringでBフレームに対応。
〇VP9
未対応
●AMD VCE (Polaris＋AMF 1.4.9)
〇HEVC
mainのみ。main10は不可。Bフレーム使用不可。
〇VP9
未対応 ↑
テンプレここまで
変更点
・説明日付の更新（2019年1月下旬時点→2019年7月上旬時点）
・AV1の状況に以下を追記
・YoutubeやVimeoでの一部採用
・TestTubeのURL
・Chrome74/Firefox67でのdav1d採用
・NVIDIA Video Codec SDK 8.2 → 9.0
・AV1のエンコーダ実装にSVT-AV1を追記。
・AV1のデコーダ実装にAV1 Video Extensionを追記。 即落ち仕様がどうなったかわからんのでとりあえず20まで保守 ひらがなで ほしゅ って書こうとしたら「ERROR: 本文が無いように見えますよね。」って言われた・・・なんぞこれ ということであとは前スレを消費してから。
テンプレに追記すべき点で、もれてるとこなどあれば指摘をよろしく。 これが次世代のスレか…さすがすごいスレだ…俺たちは未来に辿り着いた 前スレ>>996
> 今試したら"Mercurial 5.0.2 Inno Setup installer - x64 Windows"だとそのエラーが出た
> MSI installerの方は大丈夫みたいなのでそっちで試してみて
本当だ
MSIインストーラー版のMercurialインストールしたら問題無くビルドできた
Mercurialって単にhg.exe使うためだけに導入してるんだよね？
EXEインストール版はNGでMSIインストール版はokとか完全に訳分からん
ちなみにhg.exeはMSYS2のパッケージにもあったりする
（mercurialって名前のパッケージ）
これ使ってもビルドに失敗してたからまとめると、
・MSYS2版Mercurial： NG
・EXEインストーラー版Mercurial： NG
・MSIインストーラー版Mercurial： OK
こんな感じ。
プログラムのビルドって奥が深い・・・ さすがにちょっと気になったから調べてみた
MSIインストーラー版のMercurialと
MSYS2版のMercurial
hgでx265のソースを取得してフォルダ比較ツールにかけてみたところ
一つだけファイルの改行コードが違うって言われた
これが原因かなぁ？ いよいよ我々は核心に近づいていた
これが集合知の力だ
とはいえ私にはお茶を淹れることくらいしかできないが
ﾕｯｸﾘ (´･ω･`)つ旦 ｼﾃｲｷﾀﾏｴ >>29
それGoogle翻訳かけると「日本語→英語」なのに
「関 関」って結果になるのな(`･ω･´) >>30
適当に言語いくつか試してみたが英語以外も「関 関」になるな、中国語と韓国語は違う結果だが それはそうと自ビルドするよりrigayaさんのx265使ったほぐあ早いって前スレで言ったけど
xx.y4mファイルへのリンクをミスってpgoが働いてないせいだった
リンク修正したら一応はrigayaさんのよりちょびっと早くなった Google翻訳さんには本当にお世話になっております
https://i.imgur.com/cABBeeu.png
「thunder bird」が「しりのあな」と翻訳される問題は治ったんですね av1強いなぁ
GUI環境で簡単に使えるようになって、ハードウェア再生支援の道筋なども見えだしたら使ってみたいかも 次世代画像規格JPEG XLのドラフトがJPEG委員会によって承認された模様
8月5日にはISOで投票が行われ国際標準規格となる予定
https://pbs.twimg.com/media/D5ldn28XkAYJPxP.jpg
なおJPEG XLはPikとFUIFのハイブリッドでロイヤリティフリー規格とのこと
https://github.com/google/pik
https://github.com/cloudinary/fuif JPEG XL(Pik+FUIF)
JPEG XR
WebP
HEIF
AVIF
BPG >>41
画質比較データって主観的なやつ？
SSIMみたいな客観的な指標だとPikは低めだと思うよ
PikはGuetzliの考えを発展させて作った形式っぽいし VVCがDraft 6でCommittee Draftになった
Geneva（2019年 3 月）
Gothenburg（2019年 7 月）CD
Geneva（2019年10月）
Brussels（2020年 1 月）DIS
Alpbach（2020年 4 月 ）
Geneva（2020年 6 - 7 月 ）FDIS
Rennes （2020年10月）IS
こうなりそう MPEG-5 EVCもCommittee Draftになったな
個人的にはロイヤリティフリーのこっちが本命 JPEGXLって可逆圧縮のスコアはwebpと比較してどうなんだろう 動画コーデックの技術を転用した画像フォーマットならギリギリこのスレの範疇でもいいと思うけどそれ以外はスレ違いな気がする
画像に関しても最新の形式について語るスレが欲しいね FLIF/FUIFは算術符号(CABACのバリアント型)つかってるから
H.264/265の親戚として扱えよう Zen2の登場によって、AV1コーデックを使ったエンコードの速度は向上したのかな？ 音声になるが、YouTubeのOpus音声の音質を久しぶりにヒアリングテストしてみたところ、以前より聴きやすくなっている印象がある
いつから改善したのかはしらないが、古いラジオ番組をアップしてあるような素材だとわかりやすいかも
全部ダウンロードし直す…のか？ 根拠も無しに語られても困る
もし改善されていたとしても単純にopusのバージョンが上がっただけだろう ダウンロードし直す、とか書いてるってことは古いのはダウンロードしてあるんでしょ？
印象で語る前に、古い方と新しい方のハッシュ値なりファイルサイズなりビットレートなりを比較すればいいじゃない。
変わってるならダウンロードし直せば良いけど、変わって無かったら印象だけで全部ダウンロードしなおすとかバカみたいでしょ。 >>53
AV1はハードウェアエンコードがなきゃ話にならん(´･ω･｀) YouTube、8月2日から運用の変更があったようですね
【新】YouTubeのエンコード事情
https://aioilight.space/blog/youtube-re-encode/ ・オープンソースのマルチメディアフレームワーク「FFmpeg 4.2」が公開
VideoLANの「libdav1d」ライブラリを用いた「AV1」デコードをサポート
https://forest.watch.impress.co.jp/docs/news/1200665.html YouTubeで久しぶりにAV1動画をダウンロードしてみたが
COSTA RICA IN 4K 60fps HDR (ULTRA HD)
https://www.youtube.com/watch?v=LXb3EKWsInQ
"C:\User Program Files\youtube-dl\youtube-dl.exe" -f 401+251 "https://www.youtube.com/watch?v=LXb3EKWsInQ";
pause
で実行してAV1動画をダウンロードすると、508MBのファイル
"C:\User Program Files\youtube-dl\youtube-dl.exe" "https://www.youtube.com/watch?v=LXb3EKWsInQ";
pause
で実行してVP9動画をダウンロードすると、1.05GBのファイル
昨年テストしたときに比べ、AV1の方がかなり縮むようになっているようだ
着実に進歩しているようだね
1080pあたりまでだと、Core i5 6300U搭載のノートパソコン（dGPUなし）でもスムーズに再生できることも確認。
時代だぁ〜 AV1のエンコードがハードウェアでできるようになるのは、あと2〜3年後くらいかな？
そして現在のHEVC並にこなれたハードウェアとなるとさらに3年以上先か…
CPUでゴリゴリエンコードするか、
HEVCをハードウェアでエンコードするかは、動画の解像度次第かねぇ
フルHDまでならHEVCでいいとして、4KとかはAV1かVVCのどちらかにはしたいところか https://code.videolan.org/videolan/dav1d/-/tags/0.4.0
dav1d 0.4.0 'Cheetah' リリース
ARM64での速度が最大25%向上
メモリの使用量が場合により半分以上減少
他にはSSEとARMが少し改善 そういや当初に言っていた今頃出始めてる対応ハードって何処行った？
タイミング的にnaviで対応予定だったけど無理でしたって感じで知らん顔してるんかね >>63
4K放送や4K対応テレビが今後普及する前提で考えた場合だけれども、保存する際の解像度の問題については改めて検討すべき頃合いなのかもしれない
例えば、現行の1080i放送の場合、地上波や一般のBS放送は1440×1080iが一般化してしまったが、ビットレートも放送開始初期に比べて落とされている現状も考えると
実効的な画面解像度（実際に感じられる解像感・情報量といってもいい）は、もはや1280×720pと大差ないのではないかと思われる
さらに近年、画像のリサイズ（アップコンバート）技術が急速に改善されている現状を見ると、ますますその思いが強くなってきている
これは4K放送についても同様で、4K放送だからといってすべて4Kで保存しなればならないわけではなく、
・現行2K放送並でよい→720pあるいは1080p
・4Kの解像感をそこそこ残しつつ、保存ファイルのサイズも落としたい→1440p
・最高画質→2160p
という選択肢があってよいのだと思う
続く panasonicのDIGAのエンコーダーが低ビットレート時でも1080iにこだわりを見せたりなどの影響もあって、長らくオリジナル解像度での保存を尊ぶ傾向にあるのだけれど、
2Kまでならば情報量的にもそれほどの差がないので意味もなく解像度を落とす必要はなかったが、4K以上がデフォルトになってくると、2160pを1440pにするだけでもかなりの情報量削減にはなるので、
HEVC以降のプログレッシブ信号ベースでの運用が前提のコーデックで保存する際は、解像度を落とすことも積極的に考えてもいいのかもしれない
※ただし、テレビやモニター側でていねいなリサイズ（アップコンバート）が行える環境であることが前提にはなるけれど
>>65
何の話？ vulkanが動画のデコードエンコードのAPIを実装する予定らしい
上手くいったらクロスプラットフォームのソフトウェアで便利に使えそうだな https://www.phoronix.com/scan.php?page=news_item&;px=Vulkan-Video-Decode-H1-2020
上手くいったら良さげやな。ffmpeg,gstreamerみたいのを置き換えられたら VulkanのはVulkanドライバーさえ対応していれば、プラットホームに依存しないデコーダやエンコーダが書けるってことだね
ffmpegとかを置き換えるものと言うより、ゲーム制作者が嬉しいんじゃないかね >>54のYouTubeの音質の件、こちらでも過去にダウンロード済みのものと比較してみたが、
過去にダウンロードした際は、音声がAAC、Vorbis、Opusの3種類のどれかであったものが、
今回ダウンロードしてみるとAACかOpusのいずれかに変更されているようで、Vorbisでいまいちだった
ものがOpusに切り替わったものなどを視聴すると確かに聴きやすくなっている印象がある
近年にアップされているものは、ほとんどOpusに統一されているようだ APIの話だからgstreamerもあげてることだし、ffmpegで通用すると思ったけど違ったか??
ffmpegのAPIのことね。具体的にはlibavcodecとか。 アプリが単にムービーを流したいならffmpegのようなライブラリを使えば済むだろうけど、ムービーをテクスチャとして使おうとするとライブラリに依存したコードになるしプラットホームにも依存するかもしれない
それがVulkanAPIだけで完結するからシンプルになると思われる
あと高度なシェーダーを使ったフィルターが作りやすくなるのも間違いない >>72
ダウンロード時に何もオプションをつけないでダウンロードすると音声フォーマットがダウンロードするタイミングなどでコロコロ変わるのは相変わらずのようですが、
Vorbisが消えただけマシではありますね
個人的にはオプションでbestvideo+251を指定して、ファイルフォーマットはmkvを指定するようにしてますけど 動画圧縮コーデックをどうこうする前に、まず画質評価指標がより良くなってほしい
>>39で出てきたPIKはノイズが出やすい代わりにディティールが潰れにくいっぽい
画像ごとに得意不得意が出る感じがある
そこらへん上手くいいとこ取りできないものか その手の格安メディアプレーヤーって、大概10bit動画には非対応で死亡確認コースじゃなかったか？ 大量の画像を高圧縮して転送する「SmartFileUploader」を提供開始8Kを超える超高精細画像も十分の一以下に圧縮して転送時間を大幅に短縮 | 2019年度 | ニュース | NTTテクノクロス株式会社
https://www.ntt-tx.co.jp/whatsnew/2019/190819.html
>映像向け圧縮技術のHEVCを静止画向けとして採用するだけでなく、
>静止画に特化したチューニングを行うことで、
>JPEG方式で圧縮された画像データもしくはTIFF（非圧縮データ）を
>高い画質を保ったまま約十分の一以下のファイルサイズに圧縮可能となりました。
>また、圧縮による画質低下が気になるユーザーのために
>画質を完全に復元できる可逆圧縮機能も搭載しています。
>*3：可逆圧縮
>圧縮率は低下するものの、元の画像データを完全に復元できる圧縮方式。
>HEVCは可逆圧縮に対応。
知らなんだ(´･ω･`) AVCはCRF0でエンコードしたら可逆圧縮になっていたけどHEVCでも同じことができるのか？ 基本的には音声をOpus固定（251指定）でも問題ないだろうけど、稀にOpus音声が用意されていないものや、
サラウンド音声でアップされているものについては、サラウンドのみAACしか存在しないケースもあるので、
そのあたりを注意しながらの方がいいでしょうね アンカー抜けたけれど、>>90は>>75へのレスです >>86
x265にも、losslessというオプションがある
ちなみに試してみたけどx264より遅いのに縮まなくて使う意味が感じられなかった
H265の進歩した部分が可逆圧縮には役立たないものなのか、x265にまだ進歩の余地があるのか 使う意味、という観点で見るならx264やx265より可逆圧縮コーデック使ったほうが良い。
その方が縮むし速い場合が多いから。
汎用性という意味ではH.264が優れるかもしれないが、様々な環境での汎用性を考慮する必要があるならそもそも可逆圧縮なんてデカいものでやりとりするべきでない。 今どきそういうの気にするならdnxかproresしかないだろ 可逆圧縮コーデックのほうが縮むの？
x264とかのほうが遅い分フレーム間予測とか使ってデータ量削減できてると思ってた それと、dnxとかproresって可逆モードあったっけ？ >>93
HEVCのデコードに即してる形取ってるだけで、x264より可逆で縮むか云々は別な話だからな、一応出来る様になってるだけ
圧縮効率という最大のトレードオフ要素殺してるんだから複雑さ増してる分遅いし
より圧縮率が高いことで表面化し無かった副次的な記録情報の増加分があるから、相性の良いソースじゃなければ大抵デカくなるわな 規格から逸脱しない範囲でVLCの連中が新たな手法実装すれば多少改善もあるかもだけど
同じ手法がx264にも適用出来れば、あっちの可逆圧縮性能も上がるんだよね
そもそもが可逆圧縮の為に作られたコーデックでは無いから、HEVCである事に意義がある訳じゃ無いなら、自分で好適だと思う奴使っときゃいい 可逆圧縮の方が縮むとかそれは違う
wavファイルをgzipで圧縮しても全く縮まないどころかむしろ増える可能性がある
だけどflacとか使うと1/2〜1/3位になる >>100
flacて可逆圧縮じゃないの
>>94の言いたいのは可逆圧縮コーデックとして開発されたもの使うほうが汎用圧縮コーデックのロスレスモード使うより速いし縮むよって事かと >>101
言い方間違えた
汎用可逆圧縮の方が縮むってのは違うと言いたかった >>97
可逆とかそういうのを理解してないけど大丈夫か？
劣化の極めて無い状態で残すのが必要ならdnxかprores >>103
イミフ
なんでロスレス圧縮の話してんのに、
劣化が極めて少ないとかそんな話が出てくんの？ >>104
逆に俺からすれば後々の事考えて残す、というのにavcやhevc使うのが謎
黙ってdnxなproresだろ >>105
何度も言うけどロスレス圧縮の話してるので……
必要ならいくらでもdnxなりproresに変換すりゃーいいじゃん
ビットレートの無駄とか編集向きじゃないって話ならもちろんわかるけどね
ロスレス圧縮なんて効率考えればアホだもん >>106
まさにそういう話だし、逆にあとの編集考えるわけでもないならフルhdでhevcに3mbpsも当てれば十分じゃね >>107
だからなんでロスレス圧縮の話してんのにそーなるわけ？ 逆に後々カラコレやコンポジットしないならロスレス要らんだろ
ロスレスは高画質になるわけではないし中間コーデックも同じ。
ただ見た目で同じ、ではコンポジットやカラコレで粗が出るからわざわざ中間コーデック使うわけ。
カラコレしたらよくわかるよ イミフ
後々編集するにしてもロスレス圧縮で残しといて画質的なデメリットは無いだろう
それが効率的かはおいておいて >>110
それはやったことないからだね
まぁロスレスなんて一番使いみちがないし必要もない
hrやxqで全部残しておけるくらいストレージ用意するのも大変だが
実写だとbmやredのrawとかもあるけどそれはまた用途も意味も違うしな >>111
ゲームの録画（FHD）だけどロスレス圧縮で残してるよ
月数TB程度増えるけど今なら非現実的な容量じゃないしね
4Kは計算量的にもビットレート的にもまだ非現実的だと思うわ >>110
>>103 (ﾜｯﾁｮｲWW 2b02-O81Y)は、
TVMWスレを荒らしてるHDR君だから
何を言っても話が通じないよ。
編集用非可逆圧縮コーデックのProresが
極めて劣化が無いなんて無学な事を
言っているのは笑えるな。 多分ビジュアルロスレスか何かと勘違いしてんでしょう
見た目同じ、とか言ってんのが頓珍漢すぎて会話になってないｗ >>112
あとあとの編集やカラコレしないならフルhd hevc 3Mbpsでよくない？ >>115
3Mbpsとかなめてんのか？
エフェクトとかボロボロになるわ
それに、何度も言うが、ロスレス圧縮の話をしている >>116
見るだけならhevcなら問題ないね
後々のコンポジットや、特にカラコレ考えるならhrでもxqでも選べばいい
hevcに執着する理由がまったくない >>118
視力よりもやばいの見えるでしょ。NG入れて触っちゃダメ。 >>119
>>86, 93の流れで安価打ってるのに、何故不可逆との話が出てくる？ >>118
>>113
このスレも荒らされるから触らないように
キチガイだから >>123
めちゃくちゃたくさんファイルがあるが、一番容量のデカい1.3GBのやつでいいのか？ >>124
ファイルの説明 m49919_ISOBMFF sequences for experiments on movie fragments.docx をダウンロード。
ContentId>_<CPLId>_<FileId>_<Bitrate>_<FrameRate>_<Encrypted>.mp4
ContentId is either:
C for Chimera (23.976 fps, 24min50s),
CL for Cosmos Laundromat, 24fps, 12 min 10s).
M for Meridian (11 min 59s)
CPLId (Codec, Profile, Level):
V1: avc-baseline-L30
V2: avc-high-L22
V3: avc-high-L40
V4: av1-main-L30
V5: hevc-main10-L31
V6: hevc-main10-L50
A1: heaac
A2: xheaac >>125
それぞれのコーデックごとに、*.mp4と*_enc.mp4の2種類が存在するようだけど、
手元の環境で再生できたのは*.mp4のほうのみだな encはencryptedだから再生できないんじゃね HEVCにPCMとかの高音質コーデック合わせられるコンテナって
QuickTime以外ありませんか? そもそもmp4コンテナにPCM入れられない訳でも無いんだが
十分なメタデータ付与されているコンテナでそれぞれのストリームの再生に問題出るならデコード側の問題だし mkvですか(`･ω･´)調べて試してみます
持ってるソフトはmp4にPCMは全部ダメだったから
規格的に出来ないもんなのかと思ってました(´･ω･`) >>131
MPEG-TSもPCMを格納できるね。 手持ちのツールで旨く扱えもしない音声がPCMな動画ソース何処から持ってきたんだっていう
まぁ次は適切なスレで質問した方がいい >>138
怪しいデータではないよ(´･ω･`)
mp4にHEVC/PCM入れられるツールおせーてょ(`･ω･´)macだと嬉しい コンテナの問題で気になったことがあるのだが、映像と音声を分離・結合するMuxerについてだが、
昔はMP4BOXが主流で、その後L-SMASH remuxerとかが出たりしたかと思うのだが、今現在主流のMuxerってなんだろう？
AvidemuxかMKVToolNixあたりなのだろうか？ MKVとは用途が違うけどMP4ならL-SMASH一択 >>136
業務用だとSMPTE302MでMPEG2TSにLPCM入れてるな L-SMASHはAV1扱えないからこのスレ的にはNG >>147
そういえばAV1を扱えるMuxerって考えてなかった
何があるんだろう？ 一番いろんな方式のファイルを扱えるのはFFMPEGなわけで、AV1とか最新の方式も含めてならばFFMPEGで結合や分離をすればいいのでは？
CUIで毎回ファイル名書き換えてやるのも面倒だろうけど
あるいはFFMPEGをGUIで操作できるソフトウェアを併用するか >>143
>>148
MKVToolnixは昨年10月にリリースされた28.0.0からAV1対応してる。
ttps://www.bunkus.org/blog/2018/10/mkvtoolnix-v28-0-0-released/
mp4boxが含まれてるGPACは6月にリリースされた0.8.0でAV1対応した。
ttps://github.com/gpac/gpac/releases/tag/v0.8.0 >>146
1 追加コマンドなしで規格に準拠したMP4を作れるところ
2 バイナリの入手が簡単（MP4boxはインストーラーを実行する必要がある）
パッと思いつくのはこれ >>150
2つとも対応してるんだね
>>151
逆に言うと、他のソフトウェアは規格に準拠していないの？
昔だけでなくて今もならば大問題なんじゃないの、それ？ x264(265)guiExが吐くmp4とかMIMEタイプおかしいしな
昔の規格との互換性を重視してるらしいがmp4的には異常
まぁ何にせよffmpegでよくね >>152
今は知らないが、必ずしも規格に準拠したものがデファクトスタンダードになってるとは限らないから
実用面で困ることはない（muken氏曰く規格違反の動画でも互換性で困ったことはない）
>>153
具体的には? >>153-154
mp4は細かいところで何やら問題があるのかな？
とりあえずmkvなら問題ないならmkvにしといたほうが無難か？ いうほど問題はないと思うが
mkvで困らないのならmkvでいいんじゃないの
コンテナ形式で困っても、ばらしてMP4に再muxするだけだし 画像圧縮ツール「Optimage for Mac」がAV1を実験的にサポートし、JPEG/SVG圧縮やコマンドラインツールなどを改善。 | AAPL Ch.
https://applech2.com/archives/20190828-optimage-for-mac-support-av1.html Intel、中華codecもやるっぽい。
OpenVisualCloud/SVT-AVS3
https://github.com/OpenVisualCloud/SVT-AVS3
良記事があった。
新一代视频编码标准：VVC、AVS3 ※Google翻訳 新世代のビデオコーディング標準：VVC、AVS3
https://mp.weixin.qq.com/s/0gUL2h2wo31PigjyTxVF_Q 中国なら著作権完全無視した最強のコーデックを作ってしまうかもしれない
ちょっと見てみたい intel色々手掛けすぎでしょ
SVT-AV1もVP9も全然完成してないのに >>162
intelとひとくくりにしても、同じ開発者が複数のコーデックを開発してるとは限らないだろう。 Intelのハードウェア再生支援をNVIDIAのハードウェア再生支援と比べると、
・初対応したばかりのコーデックをハードウェア再生支援を使って再生した場合
ハードウェア再生支援を使ったほうがCPUの負荷は低減されるものの、安定した再生とは言い難い場合もある
（カクつきなどが見受けられる）
・2代目、もしくは3代目などで改善された場合に再生した場合
ハードウェア再生支援を使うことによって、安定した再生ができる
という傾向があるような気がする
続く 加えて、ノートPCの場合は、モニターの垂直同期周波数が60.00Hz固定になるケースが多いが、
Intelの場合、59.94Hzの動画を60.00Hzの再生環境にて再生すると、再生支援うんぬんとは別問題として
カクつきを感じやすい傾向にもある
（Intelはフレームレートの変換がヘタクソ）
※これは、dGPUと協調運転をするタイプのゲーミングノートPCでもおこる
IceLake世代からは、iGPUも可変フレームレート出力への対応が始まるので、フレームレート変換のヘタクソ問題にもメスが入っていればと思わなくもない
（もしくは、ノートPCが可変フレームレートの対応を標準化して、動きの激しくない状態のときにはフレームレートを落として
省電力化するような機能を当たり前に使えるようになれば、59.94Hzと60.00Hzの戦いにも終止符が打たれるのかもしれないが） >>164
先端技術は人頭いくらに比例して開発が進むというものではないだろう
役所や銀行のデータ管理ツール類を開発するのと
新技術を開拓するのでは開発といっても全く違うでしょ
要は人材の質の方が重要
他をやるからAV1に人手が足りないって推測に過ぎないし推測する意味もない 無料の範囲しか読んでないが、タイトルにAppleの名が入っているのは、Appleが採用する旨の何か通達でも出したのか？
Appleが採用したらデファクトスタンダードとして一気に採用する企業が増えるだろうけど sisvel連中との特許争いの続報ってなんかある？
7,8月あたりに特許リスト出して動き始めるとか言ってた気がするんだけど 特許関係はお互いが相手側の主張の中身精査しながら進めるから糞時間掛かるんで、初動でそんなポンポンとやりとりなんぞ進まないぞ それは知っとるけどロードマップ上だと7,8月ぐらいには動くみたいなこと書いてあったのにもう9月入っちゃったなあと
この程度はズレに入んないのかもしれんし実際特許リストやら出てきても俺らがなんかできるわけではないんだがなんか見逃してる情報あるのかなと思って HEVC終了してAV1が買ったってはてブなど各所でバズってるね 興味深い比較をしている記事があった
・H.264 vs H.265 vs VP8 vs VP9 vs AV1
https://chienomi.reasonset.net/archives/digi/software/1645
NVENCはビットレートケチりすぎのは、やはりよくないね…
VP9が思いのほか良いのは意外だった
（ただしQSVのVP9は死亡ですが）
AV1はAV1 並列 cpu-used=1だといい感じだけど、それ以外はﾋﾞﾐｮｳ…
IntelがIcelake世代からHEVCとVP9のエンコーダーを強化して2倍速くなるが
https://www.4gamer.net/games/449/G044964/20190801042/TN/008.jpg
万が一にもこれが革命級の改良が施されていて、VP9マンセーとかになったら、それはそれですごいことだけど、はてさて… >>173
目新しい情報何も書いてない記事なのにな Intelの予定
https://www.intel.co.jp/content/www/jp/ja/products/docs/processors/core/10th-gen-core-mobile-processors-brief.html
・FF デコード
2x 4k60 8bit 4:2:0 AVC / VP8
4K60 10bit 4:2:2 / 4:4:4 HEVC / VP9
8K30 10bit 4:2:0 HEVC / VP9
・FF エンコード(VDEnc)
2x 4K60 8bit 4:2:0 AVC
4K60 10bit 4:4:4 HEVC / VP9
8K30 10bit 4:2:0 HEVC / VP9
・プログラマブル・エンコード (PAK / VME)
4K60 8bit 4:2:0 AVC
4K60 10bit 4:2:0 HEVC
プログラマブルエンコードとは何でしょうね？ >>169
>Appleが採用したらデファクトスタンダードとして一気に採用する企業が増えるだろうけど
え…H…265ェ…(´･ω･`) >>177
参考程度ということで、いいんじゃないの？
最近の情勢を画像付きでまとめてくれてるところは少ないのだから 日本語圏の検証記事ってあんまり詳しくない人が書いて間違った情報拡散することもあるからなあ
その記事だってコメント欄で指摘されてなかったら完全にシングルスレッドでしか動かないというふうに思う人沢山いたと思うし
ちゃんとした知識で酷評するのは自由だけどいい加減な事は書かないでほしい まぁ所詮は個人だし…
企業というかメディアが杜撰だったら駄目だが ですよね
某watchみたいに「電波の減衰」を「電波の老衰」って書いちゃうのに比べたらなんということはないかとw >>176
下の方に
メディア、ディスプレイ、オーディオ
■エンドツーエンド 10bit サポート
電源最適化に対応した
・HEVC→10bitによるエンコード及びデコード対応
・VP9→10bitによるデコード対応、8bitによるエンコード及びデコード対応
HEVCとVP9で444フォーマット対応
10 ビット・ディスプレイ対応
（若干日本語的に書き直してみた）
VP9のみエンコードは8bitのみ対応で、10bitは非対応なのが少し残念か
ただし、HEVC、VP9ともにﾌｫｯﾌｫｯﾌｫｯに対応ということで、クロマキーなんかするときのﾌｫｯﾌｫｯﾌｫｯ素材再生時にもハードウェア再生支援が利くようになるのか？
（HEVCの可逆圧縮モードを利用できるのならばだけど） 今時のサーバ側でのエンコードって1本の動画を大量に細かく切ってばらまいて戻ってきたのをくっつける感じじゃないの？
でもって各ノードで何本もエンコードが走ってると考えたら丁寧なマルチスレッド対応なんて優先順位低いのでは
前にも似たようなこと書いたけどgoogleは俺たちご家庭のPCでエンコするのに使ってもらうことなんて眼中にないんだし H265もAV1も素人が見ただけじゃもはや見分けはつかん av1規格は個人というよりも企業の方が大きなメリットがあるからなぁ
個人はHEVCでもういいのでは…？ 今後コーデックを定着させるにはブラウザが対応しないと無理だろうな
VVCが良いものだったとしてもchromeとsafariとfirefoxがサポートしなかったら死んだコーデックになる >>184
アダプティブビットレートならおっしゃる通り 今後のコーデックやハードウェア再生支援に期待したいことがあるとすれば、新しいコーデックが登場した場合であっても、
部分的に既存のハードウェア再生支援の機能を利用できるような取り組みがほしい
現行のハードウェア再生支援は、対応コーデックか否かのみの2択状態で判断されているから、
機能的に使いまわしが効く部分も含めて新コーデックは、全てソフトウェア再生になるというのではもったいなさ過ぎる >>195
Haswellがそんな感じで後からGPGPUアシストでHEVCに対応したけど、
その後は省エネのために完全HWデコードに移行しちゃったからなあ
ディスクリートGPUならGPGPUアシストもありだと思うけどNVIDIAもAMDも全くやる気無い macでCompressorからHEVC作ってもエラー吐いてないのに
再生できないファイルが出来上がったりするんだが… 「MACも採用したしこれからはWMVの時代！」
そう確信して持ってる動画を全部WMVでエンコードしてきた俺としては
どのコーデックがデファクトスタンダードになろうともおいそれと手を出す気にはなれない・・・
水物だよ(´･ω･｀) BS4k8kがh265を使っている以上
もう消えたりすることは無いわけよ。 わからんよ
HEVCの特許問題は普及の足枷になりかねない要素ではあるし、VVCがNHKによって急速に鍛え上げられて、
なおかつ特許問題がHEVCのようなことにならなければ、「現行のBS4K・8Kはギャグ！ノーカウント!」とか言い出して、
「本命はVVC!!VVCで4Kは17Mbps、8Kは51Mbps。これでチャンネルを倍にできてバンザーイ!!」
とかわけわかんない流れができる可能性もありやなしや AV1でもsisvelの様な特許ゴロにいちゃもんつけられてるけどね
特許の有用性は分かるけど、sisvelの様な糞みたいな特許ゴロが発生するからロイヤリティフリーは重要だ rigaya氏が拡張 SVT-AV1 出力(GUI) Ex作り始めたな >>203
見つけるの早すぎでしょｗｗ
https://github.com/rigaya/svtAV1guiEx
これで誰でも簡単にSVT-AV1を試せるようになるな
まだ使い物にならないけど SVT-AV1ってAVX512に対応していないと真価発揮できないしほぼXeon専用だな >>203-204
早いなぁ
実用的な速度と画質が出せるようになるのは、まだまだ先だろうけど >>206
AVX512に対応してないと思われるEPYCがXeonより早いんだからXeon専用ってことは無いんじゃないの？
https://www.phoronix.com/scan.php?page=article&;item=amd-epyc-7502-7742&num=4 >>209
ほんとだね
AV1はかなり並列化が効くようなっているのかコア数の多さが速さに直結しているように見える
VP9とか全然並列化できなかったのに >>209
SVT-シリーズを比較すると
・Xeon Plutinum 8280 2CPU
VP9→364.52fps
HEVC→320fps
AV1→61.43fps
・EPYC 7742 1 CPU
VP9→221.34fps
HEVC→365fps（8280に勝利）
AV1→97.93fps（8280に圧勝）
・EPYC 7742 2 CPU
VP9→283.47fps
HEVC→337fps（8280に勝利）
AV1→101.90fps（8280に圧勝）
AV1→101.90fpsならば実時間の約半分の時間でエンコード終了だからいい感じではある
まだまだ伸びしろもあるだろうし
1CPUと2CPUの違いがAV1の場合、あまり出ないのはもったいない気もするけど ttps://www.singhkays.com/blog/av1-ecosystem-update-august-2019/
AV1 Ecosystem Update: August 2019 >>203
NVEncのようにcli版もそのうち出るんじゃね
需要さえあれば 承認欲求野郎うざい
そう、おまえのことだよ>>215 >>211
SVT-VP9だけEPYCがXeonに負けてるのはAVX512環境下でだけ最適化が効いててAVX2環境下だと最適化が有効化されてなかったのが原因だったぽい
多分今はEPYCが逆転してると思う
Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=Intel-SVT-VP9-3x-AVX2-Boost スマホでAV1利用できるようになるのはいつになるかな
OP1のchromebookでAV1普通に見れたから
スマホでも余裕で観られるだろうし
はやく採用して通信量減らして欲しい >>221
デコードはまだ救いがある
問題はエンコードの方 向こう3年ぐらい経たないと一般人がエンコできるオプションや環境が整わない気がする
意味なし AV1はカネに物言わせてコア数増やしまくる成金作戦が使えるだけマシという判断なのでしょうね
H.264なんかコア数増やしてもあまり効率が改善しないものだから、クロックを上げるしか手がないけど
上げられるクロックなんてたかが知れてるし、焼け石に水状態だし
物量作戦が使えるようになるでも進歩のうちか デコードさえ常識的なら、帯域を節約するためにも
さっさとモバイルにもってきてくれ
MVNOだとつべがきつい >>223
AV1対応ってことはAVIFにも対応してるのかな AV1の普及が進むのならVP9は始まる前に終わった…？ rigaya氏のところの拡張SVT-AV1プラグイン。
昔aomenc.exeで試した時はもう絶望感しか感じなかったが、実用範囲内に収まりそうな雰囲気は出てるのな >>228
AVIFって静止画用のやつか
特許問題で揉めないで済むなら、HEIFより普及はさせやすいかもしれんね
ただし、動画静止画問わず画質と圧縮率と使い勝手とハードウェアのサポート、
これらがバランス良く進まないとな >>229
人は昔それをVP10と呼んでいたのですよ
VP9の資産を生かした規格 YouTubeのVP9の動画は現状物凄い画質が良いような気がするけどね
何気にVP9はエンコード負荷とか考えれば最も効率が良いコーデックかもしれない iPhone11が発表されましたが、搭載されているA13 BionicチップにVP9やAV1のハードウェアデコーダーが搭載されている可能性はあるのだろうか？ >>234
AV1のハードウェアエンコードとデコードに対応してる
VP9は知らん A13 könnte sogar eine der ersten Chips sein, die Hardware zur Kodierung und Dekodierung des neuen AV1-Videocodecs enthält, einem lizenzfreien Videokompressionsstandard, der die heutigen Formate HEVC, AVC und VP9 ersetzen soll.
あとはそのままググれ >>239
これはライターの願望だな
早くても次かその次くらいだろうね av1て規格としてファイナライズしたの？
今後もバージョン上がるとしても >>243
ttps://aomedia.org/aomedia-members-demo-av1-at-ibc2019-demos-spotlight-av1s-royalty-free-ultra-high-definition-uhd-web-video-capabilities/
IBC2019、AV1関連企業も結構出るみたい。
日本からはソシオネクストが出てる。 >>242
ファイナライズされてる。
ttps://aomediacodec.github.io/av1-spec/av1-spec.pdf 今年の1月なのにA13に入ってるわきゃないな
設計なんて1年以上前に終わってるだろうから
A14も無理で
A15に間に合うかどうかといったところか
順調にいけば2021年のApple製品にはハードウェアデコーダー載る H.265はライセンス料の高さから動画の長さ（時間）が増えるにつれてライセンス料も増加するMPEG4-ASPみたいにポシャる デコーダーじゃなくてエンコーダーの方を出して欲しかった >>252
AV1、エンコード時間は問題なさそうだが、画質悪いなぁ
これが最適化されるにはまだ時間かかりそうだね SVT-AV1はシーンチェンジ検出を有効にしてエンコードしただけで壊れた動画作るしまだまだバグだらけで未完成 >>252
x265のSlowerだとcrf28の200kbpsでもこんな綺麗だったのか
自分の設定を見直したくなるな 1280x720だからそんなもんでしょ
動きも少なそうだし >>254
libaomとx265で画質比較するならともかく
速度重視というか簡易版のSVTとx265で画質比較するのはちょっと
https://i.imgur.com/wk01ltR.png 当たり前だけど速度を重視すれば画質が犠牲になる
AV1のフォーマットの形をしているだけの何かと比較しても意味ないってこったね >>259
そのグラフのSVT-AV1のバージョンはかなり古いので役に立たないデータだよ x265は特許でいつでも潰されるリスクがあるから
牽制という意味でも対立するコーデックが発展するのは巡り巡ってメリットが大きい
特に企業にとってはH.265は特許関係が面倒すぎて実用的じゃないからね two oriolesの創業者ってffvp9とdav1dの開発者だろ？
VP9の設計した人でもある ※注意！！基地外出没中！触れるべからず
名前…クレクレ乞食（通称：クレイ爺）
職業…5ちゃんの住人（ニート）
年齢…不詳（初老）
能力…低い、日本語が不自由
知能…猿並み
性格…悪い（糖質）
特技…連日連夜5ちゃんに張り付きクレクレ。たまにIDを変える
好きな芸能人…水樹奈々
夢…5ちゃんで命令出来る存在になりたい
好物…人糞（特に日本人のうんこ）
嫌いな物…グロ
特徴…タダ見の乞食の癖に自分が欲しい情報が手に入ると途端にスレを荒らしだす最低最悪の基地外
荒らしながら常にクレクレしているが誰も相手にしていない
常識人のグロ攻撃で糖質の症状が更に悪化している
クレイ爺の活動
http://hissi.org/read.php/avi/20190825/eXExU09neCs.html
http://hissi.org/read.php/avi/20190826/VjkyOHhsejc.html
本日のクレイ爺
http://hissi.org/read.php/avi/20190916/azBYeUJBaGk.html >>267
Ronald S. Bultje氏個人でやってたBlog 2017年を最後に更新が止まった。
https://blogs.gnome.org/rbultje/
>>268
そうそう。decoderはdav1d使えって言ってるね。 64コア Zen2 EPYCが世界で初めてリアルタイム8K HEVCエンコに成功する
64-Core AMD EPYC Rome Achieves World's First Real-Time 8K HEVC Encoding
https://www.tomshardware.com/news/amd-epyc-rome-8k-real-time-encoding,40400.html SVT-AV1(--cpu-used=5)とlibaom-av1(--cpu-used=8 10並列)を比較してみた。
SVTの方はcpu-usedを小さくして画質を上げようとするとブロックノイズだらけになるので、
同じエンコード時間での比較というのがそもそも無理だった。
https://imgur.com/eY36CZy.png
libaom-av1は3900Xで2並列時のCPU使用率は11%、10並列時のCPU使用率は60%ぐらいだった。(並列化無しだと5%前後)
並列化出来ない部分が足を引っ張っている感じがする。
https://imgur.com/wdxRbZa.png
https://imgur.com/32dmfkG.jpg >>274
乙
やはりlibaom-av1のほうが、画質いいね
ただし、エンコード時間がSVT-AV1と比べると4.5倍か…
（しかもSVT-AV1は、若干コントラストが低下しているようでもあるね）
でも、賞味の動画の再生時分を元にすれば実時間の約3倍なら健闘してるほうなんだろうね
（1280×720だけど）
フルHDとか4Kをエンコードしたら死ぬほど時間かかりそうだけど
やっぱりサーバー用の超マルチコアCPUがいるのかね… >>274
Multi_FFEncoder_v0.02のバッチって何処を探せば良いの？ >>275
8コアの2700Xだと10並列で100%近く負荷かかるけど、12コアの3900Xだと60%〜ぐらいだから、
もう少し並列度を上げれば早くなりそうな感じではある。
3900Xで2並列だとCPU10%〜で6時間ぐらい、
1並列(並列無し)だとCPU5%〜で0.7〜0.8fpsみたいだから10時間超えそうではある。
https://imgur.com/h6GFlnr.png
https://imgur.com/Za3JJpH.png
>>276
これは自分がテスト用に書いたバッチで人にはオススメ出来ない。
x265ならripbot264とかGUIで並列エンコード出来るソフトがある。
自分は4PCまでしか試した事無いけど、最大16台まで行けるらしい。
こいつがAV1に対応すれば良さそうではあるが。
https://imgur.com/5eQWruB.png >>278
ripbot264って今でも普通に対応してるのか
まともに使ってる人初めてみたかも
ぜひ、ブログ等に使用方法と結果を残して欲しい >>278
なるほど自前のスクリプトでしたか、テスト用って事で残念。。。
今後もcpuのコアは増え続けるだろうしバッチに組み込めたらすげぇ有用だと思うから、気が向いたらおねがいしゃす
ソフト紹介thx >>279
ripbot264はやや扱いづらい点はあるけど設定自体はそれほど難しくは無い。
・日本語環境だと文字化けするので英数ファイル名の必要が有る(フォルダ名に2バイト文字が入っているのもダメ)
・ソースファイルの拡張子が.mkvじゃないと並列エンコードでエラーが出ることがある
・ある程度長いファイルじゃないと並列数が少なくなってしまうことがある
簡単な使い方とフォーラムのリンク
https://i.imgur.com/9235xwr.png
https://forum.doom9.org/showthread.php?t=127611&;page=867 >>281
おぉ、とても解りやすいです
ありがとうございます！ AV1のエンコードは、AVX512命令対応CPUだと速くなるのかね？
AMDはAVX512非対応だから、Intelが復活するには、そこしか望みはないだろうと思われるが… 東方ほどエンコード殺しの映像もなかなか無いからベンチマークには良いのでは 東方が動き出したということは、H.264の後継として有望ですな あの人が参画してた場合は、だけどね
ところで名前なんだっけ? まぁ他の弾幕ゲーだったり大量の爆発スプライトやパーティクルが出るゲームなら何でもいいんだけど
アレ採用するのはリプレイ機能が楽だから録画が楽あたりなのかね
雨や雪のエフェクトや細かくて強めのラスタースクロールが背景全体に出るゲームのもなかなかエンコ殺しだったような ゲームのエンコしにくさ考えるとクライドゲーミングとか画質大丈夫なのかなって思う
4Kで35Mbpsらしいが細かい部分潰れちゃってせっかく4Kにした意味無くなりそう 動きが激しければ細かいところつぶれても気にならんだろうし、
動きがゆっくりならちゃんと画質出るんじゃね？ ああ、ちょっと上の東方みたいなエンコ殺し画像だと…どうなんだろうねｗ 実際に見ると動きが激しい所が潰れてたら目立つんだよなあ ヱヴァンゲリヲン新劇場版:破のBD観るといつも思うんだけど
第8使徒がブロックノイズも出さずに破綻なく精緻にエンコードされてて
どんな環境でエンコードしてるんだろうって考えるとぞわぞわする 序と一緒ならソニーPCLがエンコード作業してるはずだけども BDはビットレート盛り盛りのH264じゃん
まあそんなもんでしょ ピークビットレートを平均値の3倍以上に設定すればいい DVD時代もだけど、ビットレートキツいシーンは個々に量子化テーブル最適化したり、マクロブロックの配置にすら人為的手加えて破綻抑えたりしてる場合もある変態染みた調整入れられてる場合もあるよ x264って量子化テーブル全く活用できてないよね
活用できないままオワコンになってx265に移行しちゃった サッカーみたいな画面全体が動くスポーツ動画だとブロックノイズでまくり >>301
x265は一度は天下を取ったWMVと同じ運命の道を歩みつつあるから気をつけろん 正直、nvidia、AMD、Intelそれぞれが先に真面目に早く対応したら勝ち。
もちろん、エンコード・デコード両面で。
昔のようにボードを出してくれそうなところないしなぁ。
エンコード＋スマホ絡みならARMやらなんやら、それこそ華為？が >>306
hisiliconのkirin、samsungのexynosはMali gpuだからarm次第。あとはqualcommのadrenoとかpower vrとかかな... x264、x265ってエンコーダーのことを言ってんのかAVC、HEVCのことを言ってんのかややこしいな いやもちろんxは本来はエンコーダーの意味しかないのだが、コーデックの名称として言ってないかっていう x264とx265をコーデック名として使ってる人多いもんな。文脈で分かる場合はいいけど、わからないときは困る ただ理解してないだけだろ
普通はH.265とx265は使い分ける 10年後H.264やH.265が再生できなくなるわけじゃないので今最適だと思うものを使えばいい
WMVだってソースを取っておいてH.264でエンコすりゃ良かったなんて考えてる間抜けはいないだろ ・AVIF形式の画像をサポートした「paint.net」v4.2.2が正式版に
DirectX 10/11形式ファイルへの対応も強化
https://forest.watch.impress.co.jp/docs/news/1208655.html
AV1の系統も徐々に使える環境が増えてきているようだ youtube-dl.exe -F https://www.youtube.com/watch?v=LXb3EKWsInQ でlist-format見るとav01がmp4扱いなのでおかしいなと思い
mp4指定すると「av01+mp4」で500MBのmp4ファイルになった。畸形ファイルかなと思い「av1+opus」を指定するとmkvファイルで落ちてくる。
-fオプション無し(デフォルトでbest)だと1GBの「vp9+opus.webm」になる。
mp4コンテナのav1は畸形と思ってたが、「https://medium.com/shiguredo/mp4-%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA-1def9cb409f0」によると
av1もopusもvp9もmp4コンテナに正式対応してるらしいと分かった
mp4コンテナはサポートしないコーデックがいっぱい有ったので「MKVコンテナこそ神!」と思ってたのにいつの間に成長してて驚いた。
最強なmkvにするべきか、メジャーで無難なmp4にするか、みなさんの意見を聞かせて欲しい。 >>314
mp4指定すると「av01+m4a」で500MBのmp4ファイルになった
の間違いでした mp4がav1とopusに対応したのなんてだいぶ前の話だぞ >>316 >>317
昔、古いFLVをMP4に変換しようとしたら「Sorenson H.263」が入らなくて、最近もWebMのvorbisがダメだったんで
MP4=クッソ使えないコンテナのイメージが強かったんよ
さっきOpus試したらデフォルトで拒否られて、「-strict experimental」オプション付けて無理矢理ねじ込めたけど、クセが強すぎるから敬遠してたわけ
ところがここへ来て急に勝ち組の気配がしてきたからどうしようと迷ってるわけ
Youtubeの4kはVP9のWebMがデフォルトだけど、今後AV1のMP4に統一されたら2度手間だなとか、じゃあwebMはどうなんのとか状況が読めないんだよね >>318
MP4にしたいならMP4Box使ったほうがいいよ
AV1もVP9もOpusも正式対応してる
ttps://github.com/gpac/gpac/releases/tag/v0.8.0 MKVでいいでしょ
無料で使えるツールが充実しているから映像と音声の分離、結合を一番汎用的に使いやすい
MP4は分離、結合（特に結合）時に、特定のコーデックでなければ対応できないソフトが多いような印象があるからメインで使う気になれない もう一つ
L-SMASHとかいうふざけた名前の奴も気に入らないのも古い理由に残っている 俺もmkvありゃそれでいいわ
resolveで使えないけどその時は映像だけぬいてmovにするだけだし 単純にMKVの方がMP4コンテナよりシークが早いからMKV使ってる え？シークがmp4よりmkvの方が早い？
なんの冗談だ シークの速さってコンテナ関係あるんだ
コーデックのキーフレーム間隔だからコンテナとか関係ないのかと思ってたわ >>313
保存できないとかなら使えんのと一緒のような気が >>323
なんで・・・シークの速さがそんなに重要なんですかね・・・？ シークはエンコードのオプションでなんとでもなるだろ〜 古めのGeforceだとシーク後1秒近くコマ落ちするとかまぁ処理速度みたいなもんはあるけれど
コンテナでは変わらない気がする フレーム情報の復号じゃなくコンテナでシーク変わるて、元のmp4のmuxが悪いだけだろと
mkvに納めたのと同じソフトで再度mp4に納め直して比較とかしとらんだろ https://github.com/uyjulian/ifavif
AVIFのSusie plugin来てた
ただビルドしてみたけどビルド方法が悪いのか上手く動かなかった
9月にH.265(V6)とH.264(V13)の規格書が見れるようになってたことに今更気づいたので貼り。
■H.265 V6 (2019/06/29)
https://www.itu.int/rec/T-REC-H.265
> Rec. ITU-T H.265 | ISO/IEC 23008-2 version 6 (the current version) refers to
> the integrated text additionally containing additional SEI messages for SEI manifest
> and SEI prefix, along with some corrections to the existing specification text.
■H.264 V13 (2019/06/13)
https://www.itu.int/rec/T-REC-H.264
> This edition of Rec. ITU-T H.264, approved in 2019-05,
> specifies additional SEI messages for ambient viewing environment,
> content light level information, content colour volume, equirectangular projection,
> cubemap projection, sphere rotation, region-wise packing, omnidirectional viewport,
> SEI manifest, and SEI prefix, and miscellaneous minor corrections and clarifications.
x265のv3.2もリリースされてたのね。
https://x265.readthedocs.io/en/default/releasenotes.html#version-3-2
Version 3.2
Release date - 25th September, 2019.
New features
・3-level hierarchical motion estimation using --hme and --hme-search.
・New AQ mode (--aq-mode 4) with variance and edge information.
・selective-sao to selectively enable SAO at slice level.
Enhancements to existing features
・New implementation of --refine-mv with 3 refinement levels.
Encoder enhancements
・Improved quality in the frames following dark scenes in ABR mode.
（API changes、Bug fixes、Known issuesはリンク先参照） エッジ以外がとてもボケる＞aq4
hmeのほうが面白いと思う（重いけど） https://chromium.googlesource.com/codecs/libgav1/
> libgav1 is a profile 0 & 1 compliant AV1 decoder. More information on the AV1 video format can be found at aomedia.org.
https://chromium.googlesource.com/codecs/libgav1/+/19417bbfe819a6d39e02ac809524ca0725143072
> add core library + examples
>
> this initial version of the library focuses on decoding performance for
> the android platform. additional optimizations for other platforms and
> tests will follow. やっぱりchromeはdav1d使わないのかね
vp9でもffvp9使わなかったから予想はしていたけど
av1の再生にはfirefox使ったほうが良さそうだな >>341
Chrome 74 からdav1dがデフォルトのAV1デコーダーになってるはずだけど。
https://medium.com/@ewoutterhoeven/dav1d-0-3-0-sailfish-armed-to-the-teeth-af5bbf845a16
>>340のlibgav1は文面を見る限り、当面はAndroidでのパフォーマンス改善を目的にしたものだと思う。
将来的にその他のプラットフォームへの最適化もするみたいなことも書いてるけど、どうなるかはまだこれからでは。 Google Has Been Developing "libgav1" As New AV1 Decoder - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=Google-libgav1-AV1-Decode redditにAV1とVVC Test model Encoderでエンコードした動画上げてる人が
A AV1-VVC comparison
https://www.reddit.com/r/AV1/comments/dfdu9n/a_av1vvc_comparison/ MiracastもHEVCの時代に突入か
・8000円でフルHDをWi-Fi転送、HDMIスティック型Miracast端末「EZCast 2」
https://internet.watch.impress.co.jp/docs/news/1211989.html
「Miracastに対応し、Windows/macOS/Android/Chrome OSの端末から最大で1920×1080（60p）解像度の映像出力が可能。
映像コーデックにはH.265を採用している。」 >>348
doc/software-manual.pdfとかを読めばいいんでないかい。 dav1d 0.5.0 'Asiatic Cheetah'
https://code.videolan.org/videolan/dav1d/-/tags/0.5.0
> This is the fifth major release of dav1d, the fast and small AV1 decoder, codename 'Asiatic Cheetah'.
> It supports all the AV1 features and all bitdepths.
> 0.5.0 brings large improvements in speed on SSSE3 CPU (up to 40% speedup),
> new speed improvements on AVX-2 (for 4-7%) and ARM64 (up to 10%) and ARM32.
> It introduces some VSX, SSE2 and SSE4 optimizations.
> 0.5.0 fixes some minor issues, can export ITU T.35 metadata and improves the player example. もうエンコードは超多コア買う人むけになりそうだからどうでもいい雰囲気 ttps://medium.com/@ewoutterhoeven/av1-is-ready-for-prime-time-svt-av1-beats-x265-and-libvpx-in-quality-bitrate-and-speed-31c1960703db
SVT-AV1のmode 4ならx265のVery Slowと同じぐらいのエンコード速度でより高画質らしい。 x265のveryslowがすでに耐え難い
x264のveryslowぐらいが限界だよ でもAWCYのスコアでは優れていても肉眼で見ると画質悪いってredditでもdoom9でも指摘されてるな。
特定のベンチマークに最適化されてしまっているのかな？
シーンチェンジ検出が上手く働かないから複数のカットがある動画なんかでいい感じにエンコード出来ないせいとかもあるかも。
AWCYに使われてるデータセットobjective-1-fastは基本的に一つカットからなる動画ばかりだし。 クソ規制の影響で、リンクアドレスを貼り付けると書き込み規制を喰らうようなので貼れないが、
IceLakeの整数演算性能がかなり向上しているらしく、動作周波数が低いくせに性能は期待できそうとのこと
ソフトウェアエンコードにも役立てばよいが AVX2からAVX512に最適化が進むことより、よくなっているといいね >>359
アドレス貼れないならググれるようにタイトル貼ればいいじゃない IceLakeアーキテクチャの性能が高いのは既知かと思ってた Inside MPEG's Ambitious Plan to Launch 3 Video Codecs in 2020
https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134694
MPEGが2020年にリリースしようとしている
・Versatile Video Coding (VVC)
・Essential Video Coding (EVC)
・Low Complexity Enhancement Video Coding (LCEVC)
という３つのコーデックに関する、
・品質目標
・計算量
・ロイヤリティ
などについての話。
まあなんつうか・・・うまくいく未来が来るといいね（願望）的な感じ？ VVCは分かるけど
EVCとLCEVCは需要が分からない
こんなコーデックを求めている業界はどこにあるのか 監視カメラとか
ビデオ会議とか？
そこまで高圧縮高性能求めてないけど
そこそこの画質と圧縮率は欲しい的な？ アニメーションフィルム向けのコーデックだろ言わせんな恥ずかしい（適当） >>364
Sisvelの従業員のブログなんて貼るなよ そしてライセンスとロイヤリティでこけるいつものパターン >>364
EVCは完全にロイヤリティフリーになるのかと思いきや、
ロイヤリティフリーなのはBaselineで、Mainはロイヤリティ発生する機能も選べる、ってなんじゃそりゃ。 GTX1070でx265のNVENC初めて使って見たけどすごく速いんですね
画質悪いと言われてるようですけどそんなんに違うもんなの?(´･ω･`) 動画なのに静止画でマジマジ見る人達には違ってみえるらしい NVENCは余裕あるビットレートのエンコードなら他と致命的差異はなくて
>>174みたいに1M切りの限界ギリギリまで絞ったビットレートでは差がある
そんな感じに評価されているのかなぁと推測したんだけどどうかな(´･ω･`) >>375
データちゃんと当ててるならnvencで問題ないよ
むしろcpu使うのは時間の無駄 308 名前：名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MMa9-HeLa)[sage] 投稿日：2019/09/23(月) 12:06:12.79 ID:5UZOZM98M [1/2]
x264、x265ってエンコーダーのことを言ってんのかAVC、HEVCのことを言ってんのかややこしいな
309 名前：名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MMa9-HeLa)[sage] 投稿日：2019/09/23(月) 12:07:30.17 ID:5UZOZM98M [2/2]
いやもちろんxは本来はエンコーダーの意味しかないのだが、コーデックの名称として言ってないかっていう
310 名前：名無しさん＠編集中 (ﾜｯﾁｮｲWW 4d68-k+x8)[sage] 投稿日：2019/09/23(月) 12:44:06.34 ID:SmIRFkck0 (PC)
x264とx265をコーデック名として使ってる人多いもんな。文脈で分かる場合はいいけど、わからないときは困る
311 名前：名無しさん＠編集中 (ﾜｯﾁｮｲWW 1152-KhG6)[sage] 投稿日：2019/09/23(月) 13:24:42.71 ID:qJ1KSRvg0 (PC)
ただ理解してないだけだろ
普通はH.265とx265は使い分ける 某界隈ではwmvとflvってくくりで画質を語り始めるから謎 >>375
1MbpsのNVENCは綺麗だけど、768Kbpsだとノイズが目立つなあ、AVIdemux ウェブではもうav1が普通に使える状態になってるな
高解像度だと負荷がきついけど AV1の再生は問題ないから、早いとこコンテンツを供給してほしいな
tubeはさっさと対応してほしいよ >>382
>>4
一部の動画はすでにAV1にエンコされてるらしい PCでのAV1再生は二の次よ
問題はスマートフォンで再生できるかだ
最近のトラフィックはスマホユーザーが回線を圧迫してるだろうし セットトップボックス用(？)っぽいAV1ハードウェアデコーダーはチラホラ出てきたけどスマホ用はいつになるかね >>384
スマホ向け動画のビットレートっていくつくらいに設定するのがいいんだろうかね？ SVT-AV1が2パスエンコードに対応したけど引数が独特過ぎて使い方がわからんな AV1のデコードチップがスマホに載るようになるのは再来年くらいかな >>390
スマホはSnapdragonに載るまでハードウェアデコーダ載らないでしょ スナドラとAppleのSoCが対応すればスマホはほぼ対応できるからな、HuaweiのKirinは知らんが でも確かQualcommはAOMedia参加してないんだよね 10bit対応なのがポイントだな
8bitは編集許容悪すぎだし次世代JPEG系は普及しないし
画像はHEIFで決まりかね
webPは意味不明な制限で自爆したなあ ハイエンドのデジカメなら普通はRAWで保存するよな そういえば某画像ストレージがHEIFを本来の仕様通りに再圧縮してなかったって話があったな そりゃIntelやAMDの汎用と比べれば早くはなるんだが・・・ってやつで。 >>398
397じゃないから予想だが解像度(16383x16383まで)とか(非可逆WebPは)YUV4:2:0のみって事とか？ 商用AV1エンコーダー Visionular社『 AURORA』 機械学習を利用してるっぽいdav1dにも協力？
https://www.visionular.com/
機械学習の使い所の簡単な説明
Machine Learning for AOM/AV1 and its Application in RTC
https://www.agora.io/en/blog/machine-learning-for-aomav1-and-its-application-in-rtc/ dav1d 0.5.1
ttps://code.videolan.org/videolan/dav1d/-/tags/0.5.1
> This is a minor update of the 0.5.0 version of dav1d, the fast and small AV1 decoder, codename 'Asiatic Cheetah'.
> 0.5.1 brings improvements in speed for SSE2 CPUs (up to 50% speedup), and ARMv7 CPUs (up to 41% speedup).
> It also fixes minor issues and minor speed improvements for other architectures. 速度5割増とな？
VLCのナイトリーにも搭載されるのかね？ 古い世代のCPUへの最適化もいいけどそろそろ10bitの最適化も進めて欲しい ARMでも高速化したというのは大きな前進だ
はやいとこスマホでAV1配信できるようにして
トラフィックを減らしてくれー >>411
スマホでエンコードするわけないでしょ
スマホで低負荷でデコード、再生できるようにならないと スマホでAV1配信できるように って書くのが悪い
スマホにAV1配信できるように ならわかる >>412
SOCは大体H.264やHEVCのエンコーダーも積んでるぞ
1080pくらいまでってのも多いが ARMのSoCのは動画撮影時の圧縮用途が主だからな
帯域画質性能比もピーク処理速度もQSVどころがVCEにも及ばないだろ 最高処理fpsはqsv、nvencに劣る可能性は高いけど
帯域画質性能（ビットレート当たりの画質？）で劣る理由にはならない バッテリー持たないからスマホはハードデコードが普通 スマホで録画してアップロードしてる人も普通にいるわけだが・・・
話がかみ合ってないわなぁ >>417
画質が良いと見立てられる理由にもならんけどな
実装に割けるトランジスタ規模の差考えると比類する事すら遠そうだが スマホ向けの最先端プロセッサーはPC向けと同等のプロセスなんだから
使えるトランジスタ量に大した違いはないでしょ スマホで動画を撮影すると普通に16Mbit程度になる
スマホのエンコーダーは複雑な圧縮はしてないということだな >>422
PCはCPU＋GPU＋I/Fだけだが、
スマホSoCは他の回路が大量に必要なので、
映像回路に使えるトランジスタは相対的に減るのでは
でもまあPCは機能は少ないけどバス幅が広くてトランジスタ数使うので一概には言えないか
スマホでメモリ128bitとかPCIe24本とか要らないしな AOMedia Research Symposium 2019なるイベントが開催されてたらしい
ttps://aomedia.org/aomedia-research-symposium-2019/ そうだろな
AV1ではまだ低レイテンシにできないだろう Youtubeで「きゃりーぱみゅぱみゅ」のPV見てたらたまたまAV1なのに気付いた。
「きみがいいねくれたら watch?v=8DitMqeKSP0」「音ノ国 watch?v=-OhDQfzNstg」とか最近の限定だが
720p以下の普通の動画にも普及してきたっぽい。
アプリで調べたら1080pはVP9とAVCだったけど、YoutubeのAV1設定をONにしてると720pまでしか選べない。
ゲストだと1080p選べるけどWebmになる。
720pをダウンして比較したらサイズはWebmと同じ45MB位でAVCは65MBだった。
肝心の画質は、目がチカチカしてエンコ泣かせが想像できる「音ノ国」の静止画をキャプチャーして比べたが
AV1は明らかにノイジーで汚かった。意外にもAVCが一番奇麗だったがサイズが大きいので当然か。
同じサイズでVP9に負けてるので、結論から言うとAV1は言われてるほど大したことないかなという印象。
VP9は動きに強いと聞いてたので妥当だが、AV1は激しい動きは苦手なコーデックかもしれない。
まあたった一例で低解像度だからまだ何とも言えないかな。 YoutubeのAV1はまだテスト段階だからエンコードの設定もガバガバだぞ >>428
13年のフォーチュンクッキーでも720までAV1だった
再生1億超えてるとAV1対応率上がる気がする YouTubeのVP9は明らかに画質が良くなってる
エンコーダーが成熟してるからだろうけど、何気に最強のコーデックなのかもしれない
それでもGoogleはAV1を推すのか微妙な気がする エンコード品質はNetflixが一番良いと思う
エンコード時間が100倍になってでもサイズを減らしたいって言うだけのことはある そうそう
最近番組のネット配信多くなって、まぁ自分アニメだけど
保存してみるとスカスカな気分を味わえる ffmpegでQSVのVP9エンコがサポートされた VP9 encoder is only supported on Icelake platform
って書いてるからIcelakeからだね Lenovo IdeaPad S340 - プラチナグレー
製品番号： 81VV0013JP
がicelake最安かな？
￥44,770だし YouTubeはAV1ばかりになってるな
10万再生でもAV1だわ >>440
安いけど拡張性皆無でクロック低いね
ブースト時はそれなりだけど
有線LANもないし rav1e v0.1.0: Made in Tokyo
https://github.com/xiph/rav1e/releases/tag/0.1.0
First official release, published during the Video Dev Days 2019 in Tokyo. 録画のTSデータをエンコするんだけどまた新しいコーデックが出るかもしれないとか再生環境が変わるかもしれないと
いつまでもTSデータを消せないからエンコすればするほどHDDを圧迫して容量削減になっていない
今までH.264でエンコしたやつ全部削除してH.265でエンコし直しているところ・・・・
何やってるんだ俺・・・ >>444
地デジや放送ごとき、フルhdでもhevc3Mbpsありゃ十分なのに何いってんのって思うわ。
インタレ保持したいならavcだが。 大画面でなんて見ることなさそうだから個人の自由でいいんじゃね >>447
hevcなら問題ない。そもそも大画面じゃ地デジ自体キッツイが。 舌にせよ耳にせよ同じだけど目も肥えてくると大変だな
何事も程々が一番だと思うがこういうのは主義とか価値観の話だからそれでも突き進むしかないという人を
止める言葉がない ぶっこ抜いて圧縮して出来栄えに満足したらその動画は2度と再生しないとかあるよねｗ 遅レスですがWin環境のGTX1070のNVENC使って
TMPGEnc Video Mastering Works 7 で普通にできたから
HEVC/PCM24bitでエンコードすることにしました
色々教えてくれたみなさんありがとう(`･ω･´) >>451
sdrをhdr化しちゃうから一応見るよw エンコード技術はどこまで進歩するんだろう
将来的にはモバイル回線でも8k余裕とかの時代来るのかな 今ってモバイル回線速度の遅さとモバイルデバイスのストレージの
少なさをデータの圧縮で補おうとして躍起になってるじゃん
でもそれがモバイル回線速度が飛躍的に高速化して
モバイルデバイスに大容量ストレージが搭載された将来には
データの圧縮は必要なくなり、エンコード技術の開発目的は
もっぱらコンテンツの保存のためだけになるよね
膨大に増えてゆく高画質で大容量のコンテンツをサーブする企業や
将来に残すための公的アーカイブ事業のために研究されるだけになる
そもそも超高速回線さえ整えば、低負荷の非圧縮データを送ればいい
モバイルデバイス側には高速なキャッシュメモリさえあれば大容量の
ストレージは不要だし、逆に8K非圧縮送信が常識になったりしてね 非圧縮の映像ってとんでもないレートだけど
有線でもままならないよ >>455
超高速回線って言っても限度があるでしょ
CPUのクロック周波数だって300MHz、400MHzと伸びていたころは、将来は5GHz,10GHzなんて予想もあった
HDDの容量増加だって鈍化している
CD,DVD,BDに代わる大容量メディアも理論的にはいろいろ予想されてたけど実現できていない
5Gですら人体に影響が出ると言われている
通信速度もそろそろ頭打ちの時代がくる >>455
10年前まではFTTHがどんどん普及していって帯域なんて無尽蔵に使えるようになる、そう本気で思っていた
まさかスマホがここまで普及してモバイルフレンドリーなど低速回線も意識しないといけないようになるとかね・・・
> でもそれがモバイル回線速度が飛躍的に高速化して
も新たな低速デバイスが普及して邪魔してくることは大いに予想がつく
根源的な話をすれば人間の脳が処理できる情報処理能力の上限を考えれば
今のスマホの帯域くらいでも十分すぎるってことなんだろう なんでこんなに超高速モバイル回線を否定する意見ばかりかと考えてみたが
このスレの人間は次世代コーデックがどんどん開発されて圧縮に次ぐ圧縮、
そしてまた圧縮したくてたまらないからなんだろうね(´･ω･`)ﾋｽﾃﾘｯｸ
なんで今の無線技術ベースの発展しか想像できないんだろ
量子コンピューティングみたいな、別次元の技術が実用される可能性を考えて
こっちは語ってんのに
それに原稿技術のまま確信次世代技術が現れないとしても
アグリゲーションとかで複数回線束ねればいける可能性だってあるだろ
https://www.itmedia.co.jp/news/articles/1805/16/news096.html
https://www.ntt.co.jp/news2018/1805/180515a.html
多重化無しも研究されてる
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00682/
みんな見識が狭すぎ(´･ω･`)もっと夢を持とうよ 誤字に次ぐ誤字(´･ω･`)ｽﾏﾎ
>それに原稿技術のまま確信次世代技術が現れないとしても
それに現行技術のまま革新次世代技術が現れないとしても
>>456
有線ではすでに実証出来てる。
100Gbps超え8K非圧縮映像と音響環境の遠隔配信 〜札幌で撮影した8K映像を分割同期技術により、大阪にて再現〜｜奈良先端科学技術大学院大学
http://www.naist.jp/pressrelease/2017/02/003632.html
未来を語るこの会話で「そんなもの民間に安価で降りてくるの百年かかる」みたいな発言は禁止な 夢見すぎだろ
そんなの俺達が全員死んだあとの技術だ 技術的に可能かどうかってことと、
それが普及して普通に使えるようになるかってのは別の話だしなぁ みんなが回線束ねられるようになったらそれこそ低価格SIMが帯域食いつぶしてしまうわ 技術革新で超高速の帯域が可能になったとして
それが全世界に普及するのにどれだけの時間とコストがかかるのかって話よ
日本みたいな国だけを見てコーデックが開発されてるわけじゃないんだぞ >>465
そんな当たり前のこと言われても…(´･ω･`)
>>454の問いかけは
>エンコード技術はどこまで進歩するんだろう
>将来的にはモバイル回線でも8k余裕とかの時代来るのかな
そんな絶対実現確実な事だけ論じようって話題提供だったん?
普通の話ししても面白くないし、そもそも自分はこうなるぞ！じゃなくて
誰も言わなそうなありうる可能性の一つを提示しただけじゃん…(´･ω･`) 次世代コーデックの話題から逸脱しすぎ
通信技術の話がしたいなら他所行ってくれ 未来の技術革新を当てにするなら
HEVCの10倍の圧縮率で同程度のエンコードデコード負荷のコーデックが開発される方か
全世界のサーバーストレージや超トラフィックに耐えうるモバイル含めたインフラが普及しきる方かどっちが先になるのだろう
ネトフリは100倍のエンコードコストがかかるとしてもav1を推進したいと言っているみたいだが 自分は次世代コーデックの将来の話をしてるよ
通信の話を色々言ってるのは他の人たち(´･ω･`)
この非圧縮ストリーミングの仮定は1対1の話であって、
1対多を考えたらまた別の問題を解決しないといけない
ホスティング配信でいうと、放送のような一方的な通信じゃなく
YouTubeやNertflixみたいなリクエストオンデマンド配信を考えると
ホスト側からすれば1対多で8K非圧縮を大量にばら撒かなきゃならない
それを考えたらストレージ技術の革新はあまり最新技術でも見えてきてないし
やっぱり今みたいに圧縮映像を配る以外に現実的な解決策はあまり無さげ でもさ、個人の「ぱそこん」じゃエンコードできないくらい負荷がものっそい高い
強力なコーデックで、映像配信事業者が大量の圧縮映像をデータセンターに保持、
5chも使ってるCloudFlareみたいな大企業CDNがデコードと大量配信を担って
我々の元に超高速通信を使って8K非圧縮映像を届けるなんて図式もありうるかも
そうすると手元のスマホは超高速通信チップと超高速キャッシュメモリがあれば、
デコーダー搭載/非搭載を懸念しなくて済むようになるかもしれない
そんな将来が来ても、今と目的は違えどコーデック開発は進むだろうって話なんよ
万が一そういう時代が来ると、企業が出資して開発する次世代コーデックは
我々のぱそこんで扱えない重量級の次世代コーデックがトレンドになって
民衆が自分で扱えるようなのは有志のオープンソース開発だけになったりしてね >>471
あんた誰? なんで止めてんの?
私の極論が気に障ったんなら謝るし
私の極論にレスがつかなくて放置されるなら解る
でもなんで勝手に話題切ろうとしてんの?
気に入らなきゃスルーすればいいじゃん
高速通信インフラ非圧縮伝送の可能性については
もう言いたいこと言ったから続けないです
それにみんなの気に障ったなら謝ります
でも、いいテーマだから自分の極論以外に
将来の次世代コーデックについてどんな可能性があるか
面白い意見が出るかもしれないのに
勝手に収束させられるのはちょっと残念(´･ω･`) スレタイの【HEVC/VP9/AV1/VVC等】が見えない？
何の規格予定にもなってないから”等”にすら該当しないんだよ
平たく言うとスレチ 現在の技術について語るスレであって素人の妄想には興味ないんだよね 非圧縮映像とか言ってる時点でコーデックの話じゃないのだが データ化してるという広義のコーデック・・であってる? >>476
音声の非圧縮PCM（.wav）もコーデックの範疇なので合ってる コーデックを広い意味で言うと、アナログのレコードの記録方式とかカセットテープの記録方式も含まれる INTEL oneAPI 発表！
https://software.intel.com/en-us/oneapi
>Libraries for API-Based Programming
Powerful libraries—including deep learning, math, and
video and media processing—are preoptimized for
domain-specific functions and custom coded to
accelerate compute-intense workloads. そういえばゲーム内とかの動き情報を用いてエンコードする実装ってあるのかな >>481
ゲームソフトの実装に大きく依存するし、符号化効率的にもメリットを見いだせるか疑問… ゲームの動きったってゲームには予測不能な動きなのは変わらないし
キャラの動きなどを逐一追跡してフィードバックというのも重すぎて非現実的 ちょっと違うけどRDPが近いことやってるだろ
動画ではないけど映像を送っているのは同じ HWエンコーダの実装範囲外だから当たり前にCUDAコアで処理組む事になるし、処理のボトルネックが増えるだけな気がするけどな
あと描画オブジェクトの動作レベルよりマクロブロックの配置の方が遙かに粒度細かいし
ブロック配置の操作に有益な情報に再整形させる処理の方が糞重い気がするけども >>477
wavは汎用の入れ物で圧縮された中身もあるで AURORA AV1 Encoder デモがUPされて見比べられるよになってる
https://www.visionular.com/
http://35.185.250.137:8080/#
Tears_of_Steal-4k-1920-3min.mov-high-slow-out.mp4が855kb/s
Tears_of_Steal-4k-1920-3min.mov-low-veryslow-out.mp4が447kb/s >>487
よくこんなの見つけたなと思ったらUPされたの二ヶ月前か
まあ面白そうだから色々見比べてみよう >>490
つーかVP9も現行だし
>>1のテンプレは修正するべきかと だが現行スレはないんだよなあ
HEVCはかなり前に落ちて以来立ってない >>494
確かに。元の動画と比べると作り変えた感？が出てるね >>489-492
元々は、HEVCも含めて比較的新しいコーデック全般について語ろうという趣旨で作ったスレなんだよなあ。
（というかそういう話もHEVCスレで普通にやってたのに、HEVC以外の話をするなという連中が出てきたので新設した）
いっそのことスレタイの「次世代」を取り除くって手もいいかもね。
ただ取り除いただけだと勘違いして古いコーデックの質問が来たりする可能性もあるから、なんか適切な表現があるといいんだけど。
「最近のビデオコーデック総合スレ」でも別にいいんだけど、いまいち締まらない気が・・・。
スレタイそのままにするなら、>>1を以下のようにすればいいんかな。
---
H.264/AVCの後の比較的新しいビデオコーデック全般について語るスレです。
■最近の主なビデオコーデック
・H.265/HEVC
・VP9
・AV1 (AOMedia Video 1)
・VVC (Versatile Video Coding) 少しでも世間一般のデファクトスタンダードになり始めたコーデックは
「次世代」ってスレタイに過剰反応して文句言う奴が出てくる訳か
特定コーデックに基づかない「第何世代」みたいな
カテゴライズできる呼び方があると便利なのになぁ HEVCスレも7月に落ちたままだし
どうせ比較で現行コーデックは話題に上がるんだから現状のままでいい気がする >>497
■主な次世代ビデオコーデック
・AV1 (AOMedia Video 1)
・VVC (Versatile Video Coding)
■主な新しい現行コーデック
・H.265/HEVC
・VP9 >>498
でもそう厳格にするとVCCとかの話ができないジレンマ（一応、来年登場予定の準次世代コーデックだから） 強いて言うならモダンビデオコーデックとか
これもなんだか据わりが悪い気もするが
今のままでいいと思うけどね >>502
VVCの方が規格が厳密だけど、ライセンスプール乱立を防げるかどうか。
AV1はフリーだけあって規格の曖昧さが不安。
そのコンテナフォーマットのMatroskaとそのサブセットのWebMも規格が曖昧なので不安。 個人的にはにはVMAFが一番信頼できると思っているけどどうなんだろうか？
SSIMは数値と見た目が剥離してることがたまにあるんだよな PSNRでもSSIMでも、そこに最適化するとぼやけるってのは明らかになってるから
そこを解決した新しい指標が欲しい >>498
「最新ビデオコーデック総合スレ」でよくね？
次世代だとさすがにHEVCやVP9を扱っているのは奇妙だし。
最新なら新しい現行コーデックも将来的なものも扱える。 >>508
最先端以外は最新と認めない原理主義者が現るオチが待ってる 次スレのタイトルはこれでいこう
【最新？】次のスレタイを考えるスレPart5【次世代？】
コーデックの話とかスレチですよ！(>_<) スレの趣旨変えたい奴がいるならそいつが今すぐにでも新スレ立てればそれで終わりじゃね
スレ立てるのは誰でも自由にできるんだから 将来NVEncがAV1やVVCで実用レベルになってほしい >>504
コンテナに関してはMP4(ISO BMFF)への格納方法はきちんと規格化されてる
ttps://aomediacodec.github.io/av1-isobmff/ >>519
YouTubeだとmp4で配信してるしNetflixと>>487のサンプルもmp4
どう考えてもmp4が中心に使われてる AppleってWebMのサポートしてたっけ
してなきゃ中心にはなりえないと思う >>522
iTunesにはD&Dできない
Safariはどうだろう？
Chromeでなら開けるのかな・・・ GoogleはWebMにしたがっているみたいだけど
実際に普及するのかどうか まあAV1-in-MP4で決着だろ
MP4コンテナの祖先はAppleのMOV
AV1コーデックの祖先はOn2(Google)のVPx
二人は幸せな結合をして終了 >>525
そうなるとMatroskaとWebMは死亡 >>527
WebMを作ったのはGoogleなんですけど そういや3Dグラフィックスというかゲームだと低解像度でレンダリングして、
予めディープラーニングで算出したシーン毎の最適なパラメータでアップコンバートする手法があるけど、
（レンダリングは低解像度だから軽いのに出てくる画像は綺麗）
将来的にそういうコーデックも出てくるのかな
エンコードもデコードも負荷高そうだから微妙かな ごく僅かなデータからAIが映像を予測して描く方式は
いつか出てくるだろうな 円盤を弄ったりしないとmkvの編集ツールの出番なんてないと思うが・・ >>529
シンプルだからいいのさ
拡張性があるって言えば聞こえはいいかもだけど、それに対応しなきゃいけないってことでもあるからな
んな面倒なことやってられるかっての Tencent Multimedia Lab：ユーザーエクスペリエンスの向上を目的としたオーディオおよびビデオの品質評価システムを構築する ※google翻訳
https://cloud.tencent.com/developer/article/1535567 Socionext Breaks New Ground in Real-Time AV1 Encoding with AWS
ttps://aws.アマゾン.com/jp/blogs/media/socionext-breaks-new-ground-in-real-time-av1-encoding-with-aws/ コーデックの規格多すぎ
半導体メモリの容量が1000倍くらいになったら圧縮しなくていいのにな 高圧縮コーデックが必要なのは通信回線とストレージの問題でメモリ関係ない >>544
最近のストレージは半導体メモリですけど
確かに通信速度は問題
通信速度も1000倍速くなれば解決！ >>545
動画サービス事業のコストの大半が回線とストレージ。
半分に圧縮出来ればそのコストが半分になるんだよ。
だからコーデックの開発に必死なの。 >>546
単にメモリ(ストレージ)と通信速度が1000倍になったら圧縮いらないなという夢を語っただけなのに 8k無圧縮って容量はどんなもんなんだろう？1000倍あっても厳しそう
何を基準に1000倍と言っているのか知らんが 余裕が有ろうが無かろうが無駄は徹底的に省くのがコンピューティングの基本
無駄にエネルギーを使うのは地球の為にならない MediaTek、Cortex-A77採用で5Gモデム内蔵のスマホ向けSoC「Dimensity 1000」
https://pc.watch.impress.co.jp/docs/news/1220879.html
>モバイルSoCとしてははじめてAV1フォーマットをサポートし、4K/60fpsでデコード/エンコード可能。
>搭載製品は2020年第1四半期に登場予定。 >>551
公式サイト見たらデコードのみだったインプレスの記事は間違い。
モバイルSoCは競争激しいから早いねぇ。 これか
https://www.mediatek.com/products/smartphones/dimensity-1000
「Blur-busting displays, fast 4K multimedia & AV1 decoding」だから確かにデコードのみか
しかもAV1は4Kデコードとは限らないような？ TV用のSOCだって来年出るやつはAV1のデコード対応するぞ
VOD各社が要求仕様に入れてくるから載せないとどうもならなくなる もっとこう…次世代GPU/CPUにハードウェアエンコーダ/デコーダ搭載しましたとか
libaom奇跡の高速化！希望の未来へレディー・ゴー！とか
そういうニュースは無いんですか12コアでも数fpsは辛いよ 要求ばっかりしてないで
研究開発者にもっとお金が回るように行動起こしてよ… 行動って言われても…エンドユーザーでできるのでパッと思いつくのがVideoLANへのドネートぐらいしか思いつかんなぁ
Ciscoのルーター導入してネトフリアマプラ契約してスマホはPixelとiPhoneの両刃にして
Intel CPU+NVIDIA GPU+サムスン SSDなWindows 10のパソコンからFirefoxでFacebookにログインしてLoLのプレイにイイネでもすればいいのか？ エンドユーザーの立場じゃなく
もっとサービス提供側に食い込んで行動してほしい
パテントトロールの会社作って大企業脅すとか
ポルノサイトに仕込んだ偽の表示で金銭要求するとか
いろいろポジティブなやり方があると思う youtubeのライブ配信はずっとavc1だったけど
最近（？）vp09で配信されるのがちらほらでてきた マジ？
ついにVP9リアルタイムエンコード配信始めたの？ ライブのvp9ほんとにあるか？
アーカイブではなく？ >>564
さっきスプラの生配信で確認したらvp9とm4aだった YouTubeで一部の4Kの動画がAV1でエンコードされるようになった模様
https://youtu.be/U3rWIwVcNio VimeoのAV1配信
https://vimeo.com/channels/staffpicks/375749787
1998x1080 25fps
hls-akfire_interconnect_quic-4209 mp4 1998x1080 4209k , av01.0.31M.08.0.111.01.01.01.0, 25.0fps, mp4a.40.2
hls-fastly_skyfire-4209 mp4 1998x1080 4209k , av01.0.31M.08.0.111.01.01.01.0, 25.0fps, mp4a.40.2
hls-akfire_interconnect_quic-5241 mp4 1998x1080 5241k , avc1.640828, 25.0fps, mp4a.40.2
hls-fastly_skyfire-5241 mp4 1998x1080 5241k , avc1.640828, 25.0fps, mp4a.40.2 続き
ブラウザでAV1を有効にしていたら何も設定しなくてもAV1が再生されるね無効の場合はAVC。 結局、VP9はYOUTUBE以外であまり使われずに終了かねえ VPシリーズは賛同者集めができてなかったからねぇ
ただ、VP9も登場当初から比べると、画質的にはかなりの改善がなされたわけで、
正直ここまでくるとは思っていなかったが 普通にWebサイトで利用されてるで
MP4みたいにバッファ待たなくていいから読み込んだ瞬間から再生されるのがVP9(Webm)の利点 あと最近のアサシンズクリードシリーズやNintendo Switchのムービー部分に使われてる PS4のYouTubeがVP9対応した時にFHD/60pだとコマ落ちするとか言われてたけど、
スイッチでVP9再生できるの？ スイッチはVP9をハードウェア再生できるみたい、opusも >>575
サンクス
スイッチの方がGPU新しいからHW再生か、なるほど SwitchはROMなのでムービーのサイズがデカくなるのは致命的だから、検討を重ねてVP9に行き着いたのだろう
そんで、Switch版スマブラはopusにしてサウンドのデータ量が3分の1になったと喜んでたな
ちなみにSwitchのTegraX1はVP9をハードウェアデコード出来ると書いてある >>577
libvpxのソースコードが仕様書なのさ Yamaha e Sony lancam carro autonomo com TVs no lugar das janelas
https://www.youtube.com/watch?v=Hkqi0BefD4c
ヤマハとソニーの完全自立電気自動車、機能評価機 >>579
所詮、VP9がフリーコーデックってことだな。
寿命を終えつつあるのに仕様書が未だにV0.6ってアホかバカかと VP9開発＆役目は終わったんだよそっと眠ってもらえばいい
その後VP10があって今のAV1になってるんだから
意味もなく下手にバージョン上げたら、上げ足取るやつが沸くだけ AV1はしばらくはGoogle専用コーデックだよ
デコードはまだしもエンコードが重すぎる まぁ何にせよ、4Kを普及させるためにもAV1やVVCには頑張ってもらわんと
4K放送をそのまま録画すると1時間50分くらいでBD-R 25GBディスクが埋まってしまうから何らかの手段で再圧縮しないと…
最新のDIGAに再圧縮機能が搭載されたけど、圧縮率を高くするとかなりダメージあるし…
あと、今後のことを考えるとPanasonic方式の4K BD録画ディスクは、未だにリッピングの壁を突破していないようだから、
レコーダーからのHDMI出力を4Kのままキャプチャーする古典芸に頼る羽目になるが、
4K、10bitの場合、HDMI 2.0では4：4：4での出力はできないから、さっさとHDMI 2.1に登場してもらいたいところだが、
未だに市場に投入されないのは何とももどかしい
ま、HDMI 2.1対応のゴニョゴニョが出るのかという問題は残るのだが… AV1試してるとVP9を再評価してしまう
x265よりエンコード早くて同等のVMAFスコアだったりするから 速度ならH.265エンコはTuringのNVEnc一択 >>586
Bフレありのとなしので結構画質違うん?
自分1070しかもってない(´･ω･`) https://mightygadget.co.uk/qualcomm-snapdragon-865-vs-snapdragon-855-855-plus-compare/
Many people had wondered if the Snapdragon 865 will support AV1 codec for video decoding, unfortunately, it won't, and if you want this you will need the Dimensity 1000. Snapdragonがまだ当分AV1をサポートしそうにないっていうのは普及の妨げになって辛いな 誰にだって推しコーデックはあるはず
俺はHEVCたんペロペロ スナドラ865がAV1デコードに対応してないらしいが、所謂ハイブリッドデコードも無理なの?
既存のHEVCなどの回路ブロックでAV1で利用できる部分が全くないのか?
既存の特許を裂けるよう開発したからいたしかたないのか もうAppleがHEVCとHEICを業界標準にしちゃったので無理ぽ >>596
無理ってことはないでしょ
圧縮率はまだまだ改善を求めている人が多い イマドキのプロセッサなら余裕でエンコード・デコードできる上に現在の標準的な規格より遥かに高画質高圧縮なのに
全く顧みられないJPEG2000さんもいるんですよ
他にもいっぱい新しい規格が生まれてるはずなのにpngの下は一気にjpegなんだよな >>598
JPEG2000は圧縮負荷が高すぎて小さい電池で動作するデジカメには向いていなかった。 デジカメは新製品でHEIC採用する
JPEG2000は出番無しのまま終了 圧縮率も有るけど10bit使えるのがポイント＞HEIF
HEIF10bitならそのままでもある程度レタッチに耐えられるから
JPEGは8bitのみでレタッチしようとするとRAWになって面倒だった HEIF画像拡張機能じゃまだheixブランドに対応してないから
HEIF10bit表示できないのがなぁ
さっさとWICで見れるようにしてもらいたいもんだ HEIF10bitというかHEIFが面倒くさい権利金目当てのパテント関係を乗り越えてソフトに導入されるより
AVIFが正式採用される方が早そう rav1e応援してるけど現時点では実用的ではないね SVT-AV1が意外と頑張ってんな
まあ僕はlibaomちゃん使いますけど
https://i.imgur.com/y9RiqyY.png Appleの求人 2019年12月5日
Video Codec Algorithm Engineer
https://jobs.apple.com/en-us/details/200129202/video-codec-algorithm-engineer
>Expert knowledge in video compression standards, such as H.264, HEVC, VVC, VP9, AV1
噂のApple+関連かな >>610
libaom頑張ってるなぁ
来年の後半辺りには、AV1の規格を一通り満たしつつ、速度的にもどうにか使えるレベルになっているのかな？ >>610
こうしてみるとH.265とAV1でも極端な差はないんだよなあ
そろそろ動画コーデックの進化も落ち着くのかな？ 待て待て待て…
x265のveryslow設定の7000kbpsとlibaomの2pass設定の4200kbpsが同等品質ならば大きな違いだろ まぁしかし、同じlibaomのVP9の2pass設定が大差ないと言えば確かにないかもね…
というか、libaomが優秀すぎる
libaomのVP9エンコーダーをGUI環境で使えるソフトはないのか？ >>614
その辺はもう視覚適応というか線が寝てるところはあんまり比較してもしょうがないよ 最強のコーデックは何か！？
今現在、最強のコーデックは決まっていない 265は既にこれ以上ビット盛っても画質ほとんど上がらない感じだけど
aomはビット盛ればまだまだ画質上がっていきそうな傾きしてるところが良いですね！ H.264/AVC->2003年規格化
H.265/HEVC->2013年規格化
H.266/VVC->2020年規格化予定
CPUやGPUもそうだったけど
やっぱ競争があると性能が上がるのも早いな
x266はx265みたいにパテントでいつ潰されるかビクビクせずに使いたいわ >>622
こうしていろいろデータを見ると、libaomのVP9の良さがますます浮き彫りになっているようにも思える…
VP9ならば既にハードウェア再生支援も使えるわけだし
libaomのVP9は、どうやったら使えるの？ 実用範囲じゃなさすぎるな
x265でもまだまだなのに AviUtlとかでlibaom版VP9が簡単に使えるようになったら、フリーコーデック界のパワーバランスが変わるような気もしてきた… VP9なんてGoogleからするとオワコンだろうに
もはや広める気もないと思われる >>623
libaomじゃなくてlibvpxのVP9ね
AviUtlから使いたいならrigaya氏のFFmpeg出力プラグインを使えばいいんじゃないかな >>614
>待て待て待て…
>x265のveryslow設定の7000kbpsとlibaomの2pass設定の4200kbpsが同等品質ならば大きな違いだろ
その比較の仕方は意味なくね？
同じビットレートで比較しないと
1000kbpsのとき、H.265のvery slowはおそらくVMAF82%程度。
一方、libaomの2passは87.5％なので、劇的な差はないと言えなくもない。 保存用高画質エンコしたい勢と
配信用に画質保ちつつ容量削りたい勢で感じ方が違うと思われ >>626
AV1がスマホでスムーズに再生されるようになるまでのつなぎにはなるんじゃね？＞VP9 >>627
そんなのがあるんだ!
年末年始の休みにでも試してみるかな
そろそろ貯まってきた4K放送の録画番組を再圧縮してある程度のサイズに収めたいので >>622
AV1ってx265の32倍くらい時間掛かるイメージだったけど
veryslowでも6倍程度で済むのか
3950Xが届いたら試しに使ってみるか https://code.videolan.org/videolan/dav1d/-/tags/0.5.2
>dav1d 0.5.2 'Asiatic Cheetah', the fast and small AV1 decoder
>
>This is a minor update of the 0.5.x version of dav1d, the fast and small AV1 decoder,
>codename 'Asiatic Cheetah'.
>It supports all the AV1 features and all bitdepths.
>
>0.5.2 brings improvements in speed for ARMv7 CPUs (a few % speedup),
>on top of the already big speedups of 0.5.1. It should also improve the speed for large videos on all platforms.
>
>It also fixes minor issues, brings stability and introduces an OBU demuxer. >>633
「already big speedups of 0.5.1. 」
ホンマかいな… ここにいる人はコーデック好きみたいだけど何に使っているのですか？ 自分はYOUTUBEみているだけなので普段は気にしていないのよね webRTC周りの開発してるからそれに関連してコーデックも調べてるだけよ >>454
別に8k自体は余裕だろう
そこにどれほどの情報を詰め込めるか
8kのビットマップが出せようとそれが8kないと表現できない絵かは別
>>557
研究はすでに十分に行われてる
開発が致命的
画期的な新技術も研究だけされて良い成果が出ても論文ぽいっと投げ出されて終わり
それを誰も読まない
開発者はほとんどいないし、その僅かな開発者もすごい研究成果があったことには気づかずすでに知られた技術でつまらないものを作って終わり
>>599
PGFはどうなった？
>>601
PDFの画像を表示できることからも分かる通り、すでにブラウザにはJPEG 2000デコーダがある
https://github.com/mozilla/pdf.js/blob/master/src/core/jpx.js
JPEG 2000に対応しない今の理由は知らない >>639
ただあの管理人が次世代コーデックに興味がありAV1貼れるようにするか。
数十秒のジョークなりミーム動画には今でもVP9で十分だからな。 YouTubeがAV1採用するのって
綺麗にするためというより
ネットワーク帯域を節約するため
だからね >>639だけど
VP9の問題も修正してくれた L-SMASH Works をビルドしてくれていた方がいたので自己解決としてログ
普通に表示されてありがてえ…
https://twitter.com/fg118942/status/1195869440140660736
https://twitter.com/5chan_nel (5ch newer account) r1016が最新みたいだよ
右側の「寿司です。ビルドしたもの」からアクセスしたらあった 上のレスとは全く関係なくてすまんがブログやTwitterの発言と
このスレの話題がリンクしてるアカウント見つけると世間は広いようで狭いって感じる
フォロー、フォロワーまでみると輪みたいに繋がってたりなんかなあ Lスマはその人と顔アイコンの人のtwitter見てるな >>649
エンコがオワコンになってしまったからな
昔はエンコ系ブログとかもやたらあったのになあ SVTAV1がアップデートでSIMD周りに大きな変更があったみたい そいやSVT-AV1て2Passできたんだっけ
今見てきた、ひと月前にもう対応してた-enc-mode-2p EncoderMode2pとかあったわ>>388も気づかなかったよ
SVT-AV1 v0.8.0のAVX2最適化も気になるけど試せないわ月曜日の朝知るなんて https://www.phoronix.com/scan.php?page=news_item&;px=Intel-SVT-AV1-0.8-Benchmarks
enc mode8だとv0.7より遅くなってるね
その分SSIMやらが高くなってるのかもしれんが SVTシリーズってリアルタイムエンコード用途に作られてるのに2pass対応する意味あるんかね VP9とかAV1はcrfの場合でも2passでエンコードしないと品質出ないからじゃないかな 元ツイートに説明無いからわかりにくいかもしれないけど>>608で1passとか2passとか書いてあるのはビットレート指定での話じゃなくて品質指定での話
圧縮率が全然違うでしょ？AV1は2passでエンコードしないと真価を発揮できないよ SVT-AV1のエンコが終わる前にクリスマスが終わりそう… Testing AV1 and VVC - BBC R&D
https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-processing-hevc-vvc
この記事でAV1の2passモードの特徴について少し触れられてる
それと、この特徴のせいでライブブロードキャストではVVCのほうが有利だとも書いてるように見える 2Passの1Passを待ってからストリーミングするシーンはどんなときなんだ。
録画や再放送なら不要？1Pass分の時間もとい遅延は待てるけど画質と速度を稼ぎたいときって？ そんなケースは少ないから1Passで素直に速いVVCをお待ちなさいというBBCの思し召しなんだろうか。 YouTubeをはじめとした配信事業者ならマシンパワーを掛けても十分過ぎるほど利点があるのと
VVCが特許料金でゴネてるH.265/HEVCの二の舞になった場合には次回もネットで使いにくいコーデックになるから
パテント保有企業への牽制とGIFに対するPNGのような代替手段としては重要なんだろう こんなの素直に人様の成果にな金を払うというアタリマエのことすりゃ解決するのにな
特許の使用料渋るってゴミ行為がなきゃいいだけという根本的なことで >>666
現状ではx265を個人利用するのですら複数の特許保有企業に自分から連絡取って契約金支払わないと違法なんだけど
ちゃんとやってる？ >>667
アホか、特許は個人の私的利用や技術的研究では勝手に使えるよ VP9の開発者みたいにエンコーダで儲ければいいのに
コーデックで儲けようとするのがもう時代遅れ HEVCのパテントプールが分裂して使い辛い形になったのがAV1開発の発端になったんだからそこをなんとかしないと >>669
コーデックはエンコーダも含んでいるのですけど？ >>668
家庭内での利用を除いているだけで配信に使う場合は非営利でも特許使用料の支払い義務は発生するよ >>672
配信ならね
そしてそれはつべが払うもので文句あるならつべがクリエイターへの支払いから差し引くなりアップを有料にするなり視聴を有料にすれば良いだけのこと。 >>672
しかも自分でH.265/HEVC関連の特許持ってる企業調べて契約結ばないといけないとか
やってられんわな
>>667
対抗馬がなかったらGIFの時みたいに特許権振りかざしてフリーウェア潰しとか始めていただろうし
ここ10年のCPUやGPUの惨状を振り返れば独占は禄なもんじゃないってわかるからな… >>674
フリーウェアが出しにくくなるってのはあるもしれんがな、たしかに。
ただ映像に関してはgifと違ってああいう問題は用途上出にくいだろう。
自分のウェブサイトで直接動画公開するかというと否だし
やるなら基本はつべ。 SVT-AV1メッチャ重いな。
Ryzen5 3600じゃ無理だｗ >>666
コーデックで節約できる回線料金より特許料が高かったら
使う意味が全くない >>677
画質を保てないならその時点で配信として失格だからな
たとえ金払ってでも画質を保てる、なら金は払うのが当たり前。
それだけ素晴らしい技術だし AOMediaは別の素晴らしい技術の開発に金払ってると思うんですがなにがいけないんでしょうか？ >>679
それは開発側の勝手
技術自体はより優れたものに駆逐される。それが技術だし、より優れたものを出せない、優位性を示させないくらい優れた技術には黙って金払うが正義。
もっといいもの出せたなら、金よこせ、いやならゴミ使ってろ、そのせいでユーザー失え、とだけ言えばいいだけの話 いやだからAOMediaの人たちは技術者、特許開発者に金払ってるやん
大半は参加企業の研究室の人とかだろう
サラリーもあるだろうし買取なのか譲渡なのかどういう契約かはしらんがどちらにせよ技術提供者にはちゃんと金はいってるはず
パッケージとしてのAV1は金取らんって言ってるけど自分たちでAV1を採用することで浮く金や諸々をあてに投資されて最近の動きがある
結果既存の物より優れたものが出てきたしまさに優れた技術には黙って金払うをやってると思うんだが >>681
その割には文句多すぎだね
あるべきとすればだまってhevc採用、その他は形になってから、で良い。
実用化されて実際に導入に至ってるのはhevcとvp9くらいだし、vp9はつべくらいしかないから。 単純に金払うだけで済まないからH.265は配信用に普及しなかったんですが ｵｯﾍﾟｹ見てると去年会社に居た重度ASDの人思い出すわ
「こうあるべき」という自分の結論ありきでしか話さないから会話が通じないんだよな…
相手してあげてる人も日本語の場末の掲示板の荒らしの妄言が配信サイトの方針に影響を及ぼすことはないし
わざわざ構ってあげなくていいよ >>683
結局金の話にしかならんよ、ビジネスは。 >>684
特許やビジネスは結局金の話でしかないからねぇ。
ここを間違えるとルールを無視してウリ様ルールでファビョるだけのゴミになるだけ。
確かにライセンス関係面倒でややこしいが使えないわけではない。
円盤、放送、録画で普通に使ってるし。 話通じてないし何言いたいのかも分からん
MPEG系コーデック最強、AOMediaはフリーを謳って既存ビジネスを乱すなってことか？
話す内容からすると開発者ってこともないだろうしなんなんだ
関係ないユーザー同士でなんか争うゲハみたいなノリですか？
どうせエンドユーザーが触れるデバイス、ソフトウェアには両方実装されるし大変なのはその辺に関わる人たちだけなんだがなあ よくわかんないけど現行の民生CPU/GPUじゃロクにエンコードできないからしばらくH.265でいいれす 普通は趣味でしか使わないしね
実験したいわけじゃないし ところでみんな、hevcは心の中でなんて読んでる？
わたしはへぶくなんだが…
みんなの心の声を聞かせてくれ >>689-690
そんなに酷いのかと思って試してみたけど
Ryzen5 3600 でも1080pでも負荷ほとんどないし
最近は自分でエンコした動画よりも配信サイトで観る方が多くなったから画質上がってくれるのは有難いな
YouTubeのAV1のテスト配信を試す
https://qiita.com/tetsu_koba/items/809a4304d9cf5677bfa4 >>695
対抗馬がなかったらGIFの時みたいにx265やx264も潰されていたかもしれんし
競争で複数の選択肢が確保されているのは趣味のエンドユーザーにとってもありがたい 誰でもエンコーダーやデコーダーを書けることに意味がある
AV1は何種類も実装が有ってコードも公開されてて盛り上がっている
インターネットはオープンな場所だから、特許料が発生する技術は合わない
それだけの事だろ カーネルの実装が今は読めるようになったとか開発の伽藍とバザールとかメリット・デメリット・革新と功罪とか繰り返されてきた話 >>697
特許に金払うのは当たり前
それが嫌なら自分が覇権取れる技術作って世に出して、ノータリンにお前が搾取されてろ、としか言いようがない
ただし特許はそれを回避してより優れたものがあればそちらに流れていくのが常でもある、というだけ。 ﾆｸｸｴでﾜｯﾁｮｲ隠れてるのにｵｯﾍﾟｹだってわかるのもすごいな
英一郎もそうだったけど重度アスペの人って興奮してるとき読点増えるの面白い>>700
https://togetter.com/li/1361911?page=2 ふたばで興味深いスレが立っていたのでログを
５ちゃんもふたばみたいに動画貼れると設定なんかの情報交換が進みやすいのかもしれんね
http://www.ftbucket.info/may/cont/may.2chan.net_b_res_695994537/index.htm
https://web.archive.org/web/20191229123731/http://www.ftbucket.info/may/cont/may.2chan.net_b_res_695994537/index.htm >>699
▌H.265/HEVCでは有償ライセンス提供団体が乱立し、ライセンス契約の複雑化と特許料の増加が発生している。
この課題を克服するため、技術ではなく、特許ライセンスについて議論するMedia Coding Industry Forum (MC-IF)が発足
▌MC-IFには、H.265/HEVCの有償ライセンス提供団体とその参加企業だけでなく、Alliance for Open Mediaの参加企業も参加
いい傾向だな
やはり競争があるのはエンドユーザーにとってメリットしかない >>702
こんなに熱心にVP9のエンコードしてる人たち初めて見た >>700
AV1が特許ってないと思ってんのか？
特許を取ってそれをタダで使えるからAV1はロイヤリティフリーなんだよ >>706
2chはx264の設定の話で盛り上がってるところを見たことはあってもVP9の話をしてる人は見たことがない 706もx264時代のことを思い返してたんだと思うけど
２ちゃんも昔はパラメータ設定晒し合ったりして楽しかったな… >>707
当たり前の話をなぜするのか
"昔は"と書いてたら何を言いたいか分かると思うが >>708
カスタムマトリクスの話とかディープだった わざわざ「VP9の」って書いたのに何故x264の話になるのかわからん
マイナーコーデックの設定を真剣に議論してるところに関心したという話なのに 前提条件の認識と興味の違いが出ただけだから（VP9というコーデックに限った話なのか、エンコ全般として盛り上がっているサイトの話として捉えたかの違い）
否定し合わなくても大丈夫だと思う
基本的に人間同士のコミュニケーションは齟齬があって当然くらいの認識でいた方が楽やで 珍しくエンコの話題で盛り上がるふたばは楽しかったvpxencがどんどん使われていくのにはびっくりしたけど ふたばはまだAV1の投稿には対応してないみたいね
「対応しないフォーマットです。」って言われた >>715
0:0をVP9にしてAV1に強制再生フラグ立てれば貼れそうだけどサムネイルが作れませんと言われた
鯖のFFmpegが古いんだろうな imgurにしろTwitterにしろGooglePhotosにしろ
最近は再エンコされるのが当たり前な中で（昔のニコ動のエコノミー回避みたいに）そのまま反映されるから調整の話が盛り上がるんだろうな
個人的にシーンチェンジ検出頻発回避のために
ソースファイルを分割して複数同時にエンコ→最後にconcatで連結がすごい興味ある というかチュートリアル伝授してほしい
（たぶんYouTubeとかでも近い方法が採用されていると思う）
ビットレート配分の決め方の感覚とかも含めて もうエンコにこだわる時代じゃないからな
エクセルでパワーポイントみたいな作図するような無駄な努力 5Gのおかげでエンコードに無駄なエネルギーと労力をつぎ込むのは過去の物となる NetflixもGoogleも回線帯域削減のために
どれだけ時間がかかっても縮むコーデックを求めているから
少なくとも動画配信サイトが全滅しない限りは続いていくだろう >>720
5Gはスマホユーザーの帯域を快適にはするだろうけど
回線業者やプロバイダがデータ転送する労力は楽にならないので（むしろデータ量が増える分だげ増大する）
個人はともかく動画サイト運営会社が資金と労力を注ぎ込む傾向は変わらんだろうな データ上限がある限り転送速度がどんだけ上がろうが快適にはならないんじゃないか
むしろ高解像度化や高フレームレート化でエンコードの必要性は高まる一方だろ >>720
君は知らないかもしれないけど配信業者はインターネット定額使い放題じゃないんだ ようつべ見てると車載動画は劣化が目立ったけど、
マリオカートはほとんど完敗・全敗状態でワロタ
いくらコーデック頑張っても根本的にレートが足り手ない ttps://www.singhkays.com/blog/av1-ecosystem-update-november-2019/
AV1 Ecosystem Update: November 2019 Video Dev Days 2019なんてやってたの 今年はAV1を実用的に使えるようになったらいいね
4K放送をコンパクトに保存しようとすると、
HEVC（放送・ハードウェアエンコーダー）→HEVC（自前・ソフトウェアエンコーダー）による変換程度では大して縮まらないし >>702,717でソースファイルを分割してエンコードって話が出てて面白そうだからやってみたんだけど250フレームごとに分割して並列エンコードみたいなのなら一応簡単に出来た。
でもシーンチェンジとか全く考慮してないぶつ切りだからちょっと気になる。
なにかのソフトでシーンチェンジ検出して一定間隔ごとにフレーム番号を出力とか出来ないかな？
何かこの辺に知見ある人いたらアドバイス欲しい。
元ファイルのキーフレーム間隔をそのまま使用するっていうのも考えたけど元ソースが可逆圧縮だったりすると上手くいかないし。 書き込み吸われる上にbbx入れられるとかほんと勘弁してくれ…
>>735-736
ちょうどふたばで設定晒してくれてる人がいた
書き込み吸われまくるんで「やってることは」でページ内検索してくれ
疲れた…
web.archive.org/web/20200103125736/http://may.ftbucket.info/may/cont/may.2chan.net_b_res_697394219/index.htm
https://i.imgur.com/2AmLqB9.jpg >>737
設定晒してくれるのはありがたい
でもAviUtlでキーフレーム手打ちするのはちょっと面倒くさいな
職人技って感じだ
3MBの制限がキツイからしょうがないんだろうけど 15年近く前のニコ動のアニメのflvエンコからのアップでエンコの高速化にABパート分割結合とかやってた人居たなぁ >>737、>>739
やってることのVBRそれは誤字だ、VFR(可変フレームレート)のつもりだった．．．
コピペに補足と修正、remはコメント行
@setlocal enabledelayedexpansion
rem このバッチを実行するカレントフォルダにffmpeg.exe、vpxenc.exe、元動画.mkv、keyframelist.txtを置くか.exeはパスを通す
rem 中間ファイル元動画.mkvは全フレームキーフレームである必要がある。例えばUTvideoやrawvideo(YUV2)等にしておく。
set keyframelist=keyframelist.txt
set srcvideo=元動画.mkv
set cq-level=60
set aq-mode=2
set color-space=bt709
rem bt709 or bt601
rem 0,42,83,125…のようにキーフレームリストを1行に整形、変数%segmentframe%へ
@for /f "tokens=1 skip=1 delims= " %%i in (keyframelist.txt) do (
set keyframe=%%i
set /a keyframe-=1
set segmentframe=!segmentframe!,%%i
)
rem %segmentframe%の通りにsegmentフィルタで%srcvideo%を分割、out%%d.aviとして保存(out0.avi、out1.avi、out3.avi...と連番出力になる)
rem segmentlist.txtにセグメントリストを出力。出力動画を列挙したテキストファイル、out0.avi[改行]out1.avi[改行]out3.avi[改行]...
ffmpeg -y -i %srcvideo% -f segment -segment_list segmentlist.txt -segment_frames %segmentframe:~1% -reset_timestamps 1 -c copy out%%d.avi 連投になるな
rem セグメントリストを1行ずつ読み込み分割した動画をエンコード。For内の変数%%iはout0.avi、out1.avi、out3.avi...と
rem %%~niはout0、out1、out3...とファイル名のみに%%iが変数展開されている、バッチ 変数展開 ファイル名で調べて
rem ビットレート上限なし2パス品質指定エンコード、一応上限は--min-q=20になる
rem vpxencの--profile=2でyuv420p10le、色深度10bit指定vpxencはhighbitdepthビルドである必要がある
rem データ量が大きくなる弊害よりもバンディングノイズが消える効果が大きいので特にバンディングが目立つアニメは10bitおすすめ
@for /f "tokens=1 delims= " %%i in (segmentlist.txt) do (
rem 上書きする
ffmpeg -y -i %%i -pix_fmt yuv420p -f yuv4mpegpipe %%~ni.y4m
del %%i
vpxenc --profile=2 --threads=2 --end-usage=q --passes=2 --pass=1 --fpf=FirstPassStatisticsFile.fpf --best --target-level=40 --tile-columns=0 --tile-rows=1 --color-space=bt709 --bit-depth=10 --output=FirstPassStatisticsFile.fpf %%~ni.y4m
vpxenc --profile=2 --threads=2 --end-usage=q --passes=2 --pass=2 --min-q=20 --max-q=63 --cq-level=%cq-level% --aq-mode=%aq-mode% --fpf=FirstPassStatisticsFile.fpf --best --target-level=40 --tile-columns=0 --tile-rows=1 --color-space=%color-space% --bit-depth=10 --disable-kf --lag-in-frames=25 --auto-alt-ref=1 --arnr-maxframes=15 --arnr-strength=6 --output=%%~ni.webm %%~ni.y4m
del FirstPassStatisticsFile.fpf
del %%~ni.y4m
) つづき、START CALLでエンコードを並列化しても良いかもしれない
rem 1行目がffconcat version 1.0さっきのセグメントリストの行頭に"file "をつけ、拡張子をaviからwebmに変えsegmentlist.ffconcatとして保存
rem out0.avi[改行]out1.avi[改行]out3.avi[改行]...がfile out0.webm[改行]file out1.webm[改行]file out3.webm[改行]...になる
echo ffconcat version 1.0>segmentlist.ffconcat
@for /f "tokens=1 delims= " %%i in (segmentlist.txt) do (
echo file %%~ni.webm>>segmentlist.ffconcat
)
rem segmentlist.ffconcatを読み込み.webmを連結
ffmpeg.exe -y -f concat -i segmentlist.ffconcat -c copy concated.webm 5chはレス消せないの辛いわ
見返したら文がキモいけど直せねえ．．． >>739
なんとなくこのあたりを探している気がした
シーンチェンジ検出 for Avisynth v0.4
http://potatosub.blog.fc2.com/blog-ent ry-37.html
AVIUtlシーンチェンジ検出プラグイン Evo.0.1.0
https://aoikagami.wordpress.com/2011/12/18/scenechangeevo-0-1-1/
しかしほんとNGワードやらで情報書き込みにくいなここ…
とりあえずAviUtlの
・［設定］->現在のフレームをキーフレームに
・［ファイル］->エクスポート->キーフレームリスト
で手動で作れるところまでは理解できた 書き込み苦戦してたら提唱者の方がいらしてくださってた
ありがてえ… >>739
TMSR5に金払ってる理由がそこにある 741さんの上げてくれたバッチファイルをちょこちょこいじってやってみたけどかなり変わるな
https://f.easyuploader.app/eu-prd/upload/20200104094100_475345326a.webm
https://f.easyuploader.app/eu-prd/upload/20200104093814_5264383632.webm
https://pastebin.com/zSu5vyVS
ffmpegはtrimの時に
"%~dp0ffmpeg.exe" -i "%~dpn1.y4m" -vf trim=start_frame=0:end_frame=1,setpts=PTS-STARTPTS -an "%~dpn1_1frame.y4m"
みたいな感じで0から数えるらしい この書き込みは吸い込まれずに反映されるのか
Xenoで書き込めなくなるほどのペナルティ喰らった737との違いの基準が全く分からん… うげーx265の変換高速化のためにグラボ積んでるパソコン買ったけどグラボ使った変換だとcpu変換に比べて画質も圧縮率も劣るのか
初歩的だけど知らなかったわ >>750
ソフトウェアエンコでも
Avisynth-Neoを使えば
NVIDIAなら無駄にはならない 教えてもらってばかりじゃ悪いから自分も>>735で言ってたやつUPした
https://drive.google.com/drive/folders/1vCNjbE_KqwjrXxN35xq8TpPgJ7oOaiRB
>>745
最初はその「シーンチェンジ検出 for Avisynth v0.4」ってやつ使おうとしたけどリンク切れてた ソース分割エンコとか、ソースがむちゃくちゃ長くて
かつ、エンコマシンが２台使えるとかじゃなければ
やることはないなぁ
でもソースが長いと不具合起きる時があるから
やることはあるな >>748
アニメ向け設定のmax-intra-rate --bias-pct --undershoot-pct --overshoot-pctあたりまだ全然触ってなかった。ちょっと試してくる。
シーンチェンジ検出はx265を参考にしてる。閾値の設定で挿入頻度の調整も効くしそのうえシーンチェンジ検出がめっちゃ賢い。
平均的な画質は落ちていいからビットレートもといシーン毎の画質のばらつきを減らしたけどどうしたらいいんだろ。
うまくいくかわからないけどy4mとwebmのSSIMをとって劣化の激しいワーストシーンいくつかをcq-levelを下げて2周目とか考えてる。
あとvp9_highbitdepthを有効化してあるvpxencはこれ。
https://f.easyuploader.app/eu-prd/upload/20200104164240_786e7a7643.zip
Zeranoe氏のFFmpeg buildsもvp9_highbitdepthが有効になってないけどFFmpegのビルドは流石に大変そうで手を出せないなあ。 --max-q=下げればいいか．．．変なこと書きました また無意味なことをやってるな
今どき容量ケチらず高ビットレートnvenc hevcで良くね >>756
VVCは特許料のみかじめでみっともない醜態晒さずに
ブラウザに搭載してもらえるといいね >>757
配信業者でもないのに自宅保存用でvp9やav1必要か？ 話の発端はふたばちゃんねるって画像掲示板に3000KBまでの動画を投稿できて、その制限の中でいかに高画質なものをエンコード出来るかって事だから >>759
なるほど、実用性とかそういうのは一切関係ないわけだね >>758
ブラウザ表示すらできない特許料ゴロのH.265よりも
ネットで公開して観てもらうならVP9の方が利便性が高いねって話をしているのに
スレの日本語すら読めない池沼だったのか >>760
実用性の定義が難しいね
個人的には投稿した動画をネタにみんなで雑談して楽しむという使い方が出来るのも一種の実用性だと思うが >>761
落として見るなら関係ないしな。
ブラウザが全てじゃないし >>763
そんな奇特な人はいないから
4chanにしろふたばにしろVP9使ってる人が圧倒的なわけだしな AV1エンコーダーの速度と品質の比較 - (libaom) vs SVT-AV1
https://qiita.com/yanoshi/items/544a361baf76b8114067
AVX2が速くなったとかキャッシュのレイテンシが減ったとかzen2でだいぶ進化したと聞くけど
実際素直にベンチマークに結果が現れてるとRyzenも欲しくなるな
>エンコードが、すき！
配信基盤を作って飯食っててもエンコがすきってことがあるのか、やはりエンコードには娯楽性が．．． >>764
録画素材の整理とかだとavcかhevc
hdrならhevc一択だろうな >>764
今やTS録画でもGoogle driveに上げれば勝手に鯖側でエンコしてくれるし
そもそも配信があるからそっちで観ればいいしで
DTV板の過疎具合からしても個人でわざわざエンコする人ってもう掲示板で容量制限があるケースくらいになってるんだろうな >>767
配信はいつでも見れる訳でもないのが難点
あとこだわる割にグーグルのエンコでいいの？ってのもある。 >>748
17行目の%%iは正しくは!keyframe!
1フレームずれる
>>752
追っかけるだけで大変だった、timer64は処理時間を計ってる？バッチの書き方やり方とても参考になった．．． >>769
うん、そう
PowerShellで時間計測しようとしたけど実行ファイルとか動画ファイルのパスに空白が入っているとよくわからない挙動になったから自作のやつ入れた
最初はbatにバイナリ類を一切同梱せず配布しようと思ったけどtimerだけは必要になったのでもういいやと思って全部入れた libvpxはいつまで保守されるのだろうか？
AV1が普及したら保守されなくなるんだろうなあ libvpx今でも全然進歩していないからな
デコードもffvp9の数年遅れの実装だし VP9ってオワコン？
久々にFFMPEG使ってVP9エンコしたけど、クソ遅いし綺麗じゃない。
SVT-AV1はCPUちゃんと使い切ってくれるし期待大！ >>754
バッチのおかげでVP9の動き部分が綺麗になって感動してます
悩んでたんで本当にありがとうございます
前https://f.easyuploader.app/eu-prd/upload/20200106213828_5a53655969.webm
後https://f.easyuploader.app/eu-prd/upload/20200106213902_46556b544a.webm
前https://f.easyuploader.app/eu-prd/upload/20200106213912_366769656c.webm
後https://f.easyuploader.app/eu-prd/upload/20200106213918_6251483052.webm
最初は品質指定だとサイズぴったりに合わせられないのでは…？と思ってましたが
実際にやってみると差分の容量を画質上げたい場所にピンポイントで使えてむしろそこが醍醐味でした
https://i.imgur.com/iPoeCS7.png
画質のばらつきに関しては判らないままやってる部分が多いので
--min-q= --max-q= （--undershoot-pct --overshoot-pct より優先されているというか-qの範囲内で-pctの幅が調整されている気がします）を
--cq-level= の上下いくつ分にするとか
--bias-pct= の値を下げてcrfに近くする…くらいしか思いつかないです この書き込みも吸われないのか
先日の吸い込まれまくりからのxeno規制は何だったんだろう なんかptsが狂ってないか
cfrとして読むプレイヤーやAviUtlだと一見すると正常に見えるけど ああータイムスタンプが重複してる
"ffmpegでfpsの異なる動画を繋ぎ合わせてみる（VFR動画）"で検索して出てくる記事と同じ
>>775の20200106213918_6251483052.webmでいうと
18フレーム音と映像がズレてる（映像が18フレーム早く終わってる）
タイムコード保持を削除して初めて気づいた、記事の通り-rを付けるかmkvtoolnixでタイムコードを移すことで連結済みでも修正できる
急ぎで、本当に申し訳ない >>742
バンディング、10bitでかつ十分なビットレートを割り振っているなら
x265公式的には消える事になってるみたいだけど
自分は全然消えないなあ
（TSのソースも結構バンディングの縞模様出てるし気にしてもしゃあないのかも知らんが） H.265のバンディングは仕様として割り切ってる
偽色が出るのも含めておそらく色の扱いが正確ではない印象
>>779
おそらくFC2ブログのアドレスでエラーが出たと思うので申し訳ない…
https://i.imgur.com/oDc8z69.png
たしかにフレーム数ズレてますね
MPC-BEのCtrl+4でfps表示させるとすごい勢いで変動するのにびっくりしました（元ソースやy4mの時点で23.976fpsのCFRなのになんでだろう？）
timecode抽出の方法がわからなかったので応急処置としてMKVtoolnixで23.976指定してみたのですが
45秒あたりの監督名が出てくるシーンの位置が全然違いますね
https://f.easyuploader.app/eu-prd/upload/20200108063222_476e494777.webm
https://i.imgur.com/GRyju3W.png
空白フレームが挟まれてその分水増しされて遅くなってるんじゃなくて
むしろフレーム数が減ってるのか…動画関係は感覚的にすんなりイメージ理解できないことが多い >>780
ソースの時点で出てるならエンコードしても消えないよ
フィルタでバンディングを消さないとダメ Google Playが「HDR10＋」対応。次世代動画圧縮規格AV1にも実装可能に
https://av.watch.impress.co.jp/docs/news/1227879.html
>「AV1」においても、HDR10+の実装が行なえるようになったという。 >>782
ああ、書き方が悪かった
言いたかったのはこういう事
仮に平均SSIM9850以上を達成する程度にビットレートを盛っていたとしても
x265でエンコすることで暗部の画質はソースより劣化し、バンディングが容易に目視できるようになる
（ただ、元々TSの暗部は結構汚いし神経質になっても仕方がないのかもしれない） >>781
とりあえずvpxencで出力する形式をwebmからivfに変えてみたらどうだろうか
自分も最初webmで出力して結合したら音ズレしたけどivfにしたら直ったから
原因はよくわからないけど aq-mode 3で暗部に多めにビットレート割り振るようにしてエンコしても
これだけバンディングが出るんだよね
ttps://i.imgur.com/eMdGYti.jpg >>785
duration_timeがなぜか消えてるな
3フレーム目で分割
ffprobe src.avi -select_streams v:0 -hide_banner -show_entries frame=pkt_pts_time,pkt_duration_time -show_entries stream=r_frame_rate>src.txt
[FRAME]
pkt_pts_time=0.000000
pkt_duration_time=0.041708
[/FRAME]
[FRAME]
pkt_pts_time=0.041708
pkt_duration_time=0.041708
[/FRAME]
[FRAME]
pkt_pts_time=0.083417
pkt_duration_time=0.041708
[/FRAME]
[STREAM]
r_frame_rate=24000/1001
[/STREAM]
IVF
--ivf付加
[FRAME]
pkt_pts_time=0.000000
pkt_duration_time=0.041708
[/FRAME]
[FRAME]
pkt_pts_time=0.041708
pkt_duration_time=0.041708
[/FRAME]
[FRAME]
pkt_pts_time=0.083417
pkt_duration_time=0.041708
[/FRAME]
WebM
--timebase既定値1/1000から精度1ms小数点第4位以下切り捨て
[FRAME]
pkt_pts_time=0.000000
pkt_duration_time=N/A
[/FRAME]
[FRAME]
pkt_pts_time=0.041000
pkt_duration_time=N/A
[/FRAME]
[FRAME]
pkt_pts_time=0.042000
pkt_duration_time=N/A
[/FRAME]
>>781
mkvにしてmkvextract.exe src.mkv timestamps_v2 0:timecode.txtか
ffprobe video.avi -select_streams v:0 -hide_banner -show_entries frame=pkt_pts_time -of csv=p=0から x265はcrf同じでもプリセット重くすると画質が下がるんよな
x264は変わらんのに ビットレート決めるのみんなどうしてるの?
何パターンか作って比較しても、どれが自分にとって正解か
だんだんわかんなくなってくる(´･ω･`)
サンプル動画をいくつか見て自分がいいと思う画質をいくつか答えた後はもう
AIがビシッと「このコーデックならあなたには5Mbpsが最適です」とか
決めてくれないかな、ビシッと(`･ω･´) ソースによって必要なデータ量は違うんだからビットレートが決まるわけ無いじゃん
なんの為の品質基準だと思ってんだｗ
ビットレート決めるのは品質よりファイルサイズを優先する場合だっつーの >>790
自分の場合はOPだけ--tune ssim でエンコして
平均SSIM9850をギリギリ超えるCRFを見つけたら
それで本番エンコードしていた（本番時には--tune ssim付けない）
ただそれでもグラデーションの再現で不満は残るね
多分OPじゃなくグラデーションが目立つ箇所でテストするべきなんだろう >>789
4k/8kでの高圧縮向けって感じだよね
>>784
x265に渡す色深度がx265の指定より多い（x265 10bit-depthモードに12bitにアプサンしたのものを渡す）なら--ditherが必要
他に「 --fades 」「 --rdoq-level 2 」 「 --psy-rd 1.0 」はバンディングの出やすいフェードに有効（psy-rdは違ったかも） >>769
遅くなりましたが正確にフレーム区切りできるようになりました！
ご教示ありがとうございます！
>>788
検証までありがとうございます！
windowsでも以下のバッチ作ったらtimecode抽出できました！
https://f.easyuploader.app/eu-prd/upload/20200109030752_3355536773.webm
ギリギリで作ってたせいでtimecode分で3000KB越えたので先に出力してサイズ調整しないと詰みますね
@echo off
cd /d "%~dp0"
if "%~1" == "" goto error
if not exist "%~dpn1.avi" ffmpeg.exe -y -i "%~dpn1.y4m" -c copy "%~dpn1.avi"
if not exist "%~dpn1.mkv" "mkvmerge.exe" --output "%~dpn1.mkv" --language 0:und "%~dpn1.avi"
"mkvextract.exe" "%~dpn1.mkv" timestamps_v2 "0:%~dpn1_timecode.txt"
if exist "%~dpn1_timecode.txt" del "%~dpn1.mkv"
if exist "%~dpn1_timecode.txt" del "%~dpn1.avi" >>786
そもそもsdrだと黒側はバンディング避けられない 誰か個人でFPGAボードに組み込みやってる人いないんか >>800
ドワンゴが一部機能に限定して実装してやっとこさ大規模FPGAに載る規模だから、
個人で買えるようなチップに載せるのは無理だよ
https://dwango.github.io/articles/av1hwencoder/ SVT-AV1のソースコードが更新されたので、ビルドしたんだけどやたら遅い。
前コードの十倍かかる。大きな変更でもあったのかしら。 今年に入って派手にコードをクリーンアップしたのだけは確か おいらのビルド方法が間違っていた。ちゃんと速度出る。
すいませんでした。m(__)m >>793
Versatile Video Codingに対するVersatileというこのネーミングよ、特許ダイエットはうまくいくんだろうか
MPEG-H Part 2 / (HEVC) MPEG-I Part 3 / (VVC)ときてMPEG-5 Part 1 / (EVC)とMPEG-4以来のナンバリング復活になるのが不思議なところ EVCは絶対に流行らんでしょ
MPEGの迷走の象徴みたいなコーデック ちゃんとラップで感謝を表すべきだと思うYO！♪( ´▽｀) 符号化標準 ：導入された符号化技術
H.261 ：MC-DCT。2次元VLC、GOB、マクロブロック、mquant、CBP
JPEG ：DCTと量子化マトリクス、2次元(run-size)VLC
MPEG-1 ：MC-DCTに双方向予測、半画素予測、スライス
MPEG-2(H.262） ：フレーム/フィールド予測、DCTtype、Dual'予測と、スケーラビリティ(空間、SNRなど)
H.263 ：イントラDC-AC予測、3DVLC、枠制限無(unrestricted)MC、など多くの技術
JPEG2000 ：離散Wavelet変換(DWT)にEBCOT符号化、ビットプレーン、ROI符号化
MPEG-4 ：オブジェクトベース符号化(形と模様)、イントラDC-AC予測、1/4画素予測
MPEG-4 AVC ：マルチフレーム予測とイントラ予測、4x4 DCT(整数変換) 逆スキャン符号化、ループ内デブロック
HEVC ：4分木(quadtree) による画像分割、タイル、スキップ/動きマージ/AMVPの複数候補選択、SAO
JCT3V ：デプス画像を用いる3D多視点符号化
特許の使用を最小限にするっていうEVCが気になったついでに調べたけど時代が下るにつれ相応に技術も投入され続けているんだな
結局は計算複雑性とその時代のコンピューター性能のバランス次第になるんだろうな。ただまだ劇的に圧縮率が上がる技術の引き出しはあるのか気になる。
そういやマスモニの取説を読んでたら
https://www.sony.jp/products/catalog/FUN_WhitePaper_OLED_ColorMatching_V1_00.pdf
モニタの校正や色空間の変換で用いるXYZ色空間の標準CIE 1931の等色関数は間違ってるって、CRTで見たテープとキャプチャしてRec. 709で表示した色は実は色ずれてたってこと？ >>814
CRTや従来（sRGB）LCD同士なら1931でもズレは問題にならない
広色域LCDやOLEDは緑が短波長になってるので、
それだと1931が人間の眼と異なってるためズレが生じて問題になった chromium版のedgeでAV1再生できないのは何故だろう FireFoxというかGeckoでAVIF画像(AV1 Image File Format)がサポート
https://bugzilla.mozilla.org/show_bug.cgi?id=1443863
https://groups.google.com/forum/#!msg/mozilla.dev.platform/bIM8ZaFS-d8/VwbG7okoCwAJ
AVIFはSDRに加えてHDRに対応している。Web画像にJPEG XRが成し遂げられなかったHDRの世界がやってくるかもしれない。
https://aomediacodec.github.io/av1-avif/
>>816
Can I useではSupportedだけど再生できないね。AV1 Video Extensionの有無も関係ないみたい。
https://caniuse.com/#search=AV1
Microsoft Edge Platform Statusにも特に書いてない。
https://developer.microsoft.com/en-us/microsoft-edge/status/
chrome://flags/で有効化されてないのかもと見たらenable-av1-decoderがない、よくわからない。
>>815
>CRTや従来（sRGB）LCD同士なら1931でもズレは問題にならない
そうなんだ。 動画が長ければ長いほど(秒数)でライセンス料が増えていくことを課した結果、
流行らなかったMPEG4-ASPの失敗は二度と繰り返してはならない
繰り返してはならない・・・・！！ >>819
DivX 5やXvid等の有名な実装はあったけど今となってはレアな規格になったわな そういやavifとかwebpとか
動画の圧縮形式ベースの奴って
ハードウェアデコードできるの？ コンテナもツールも過渡期だったんだよ
失敗という名の経験さ 1フレームの動画としてデコードできるんじゃね？知らんけど webpってハードウェアデコードが必要なほど遅くないでしょ
デコードに関してはpngより早いとかじゃなかったか 重いと言っても1フレームくらいならしょぼいCPUでも余裕 googleの画像検索とか使うと、何も知らないうちにwebp使って表示されてたりするぞ。
Googleの至上命題は帯域の削減だから、どんどんデファクトではないWebpやVP9、AV1を使ってる。
jpegやH264より2-3割でもサイズ小さくできれば、
どんなにエンコ時間掛かっても、帯域節約効果のほうがメリット大きいからね。
そうやって自然に画像や動画の標準を侵食してくわけだ。
ところで、Fastestを名乗ってるRav1eのクソ遅さは何なんだろね。
しかもCPUフルパワーで使ってくれねーし。
やたら画面分割エンコしてようやくCPU負荷55%がいいところじゃないか。
それでも遅いしなぁ
CPUフルに使ってくれるSVTAV1の優秀さよ。 早くぼくの考えた最強のコーデック作って普及してくれー！ 1フレームでもCPUで全然余裕じゃねぇだろ。
現状のWEBPやPNGでさえ、大きい画像だとCortexA72などで3,4秒以上かかるのに 動画コーデックのIフレームを使う画像形式って動画用のチップを使い回せるのが利点なの？ IntelのDG1とかXeのハードウェアエンコーダ関係は何か情報出た? >>827
rav1eなんだけどこのスレで話題に出てたようにソース動画をシーンで分割して並列でエンコードしたほうがいいのかもしれない
rav1eの開発者の一人であるThomas Daede氏がまさにそういうPythonスクリプトにスター付けてる
master-of-zen/Av1an: Tools for streamline av1 encode
https://github.com/master-of-zen/Av1an 元来segmentフィルタはHLS、MPEG-DASHで使うのが主たる用途の様だし時分割エンコと組み合せるのは自然なんだろうな。 スマホゲーとかアホみたいに解像度も高いしデータ量も多いから
重い規格だとデータ展開にかかる時間がばかにならないだろうな CUDAのnvJPEGみたいにGPUで展開するデコーダーもあるけど
Tesla V100 vs. Skylake 6140@2.3GHzの条件で1.4x~1.8xの高速化ってどうなんだこれ 画像のデコードなんてCPUでも大して時間かからない
むしろGPUにデータを送ること自体が無駄になって遅くなることまである お前こそ作ったことないだろ
スマホアプリで画像の扱いなんてライブラリにおまかせだぞ >>838
まさしく経験不足アピール。こういうエアプログラマーが多いから>>826、836みたいなCPUのデコード、エンコード大したことないとかほざくやつ多すぎるんだろう。
glideやpicaso使うだけでまともに自分で1回も実装したことすらないんだろう。 自分で実装するほうがアホだろ
そういうのは車輪の再発明って言うんだ
あと描画に時間かかるような画像を表示するのはアプリ設計自体が間違ってる 誰も毎回自分で実装しろなんていってねぇぞ?
「1回すら」も自分で実装した経験すらないから
からCPUで余裕とか勘違いしてほざいてんだろ。
それに前はUniversal Image Loaderとかもあったが自前実装が普通だぞ。最近プログラマーになったばかりか? https://developer.android.com/topic/performance/graphics/
前からこのページが用意されてて前は自前実装当たり前だし、自分で最低限の非同期処理としのキャンセルとか組み込んでも100行未満だし。
経験不足アピールお疲れとしかいいようがない >>843
>ほとんどのケースでは、Glide ライブラリを使用してアプリのビットマップを取得、デコード、表示することをおすすめします。
>Glide を使用すると、Android におけるビットマップなどの画像の操作に関連するこうしたタスクの処理の複雑さをほとんど取り除くことができます。
そのページでもライブラリに任せろって書いてあるんですが… >>844
だから、最近はそうだけど前は違って自前実装当たり前だったっていってるんだが...
俺が最近作ったandroidアプリはglide使ったけど、でもflutterアプリの方は要件から自前実装だし。 今時はglideやpiccasoだの使うの否定してねぇよ。
ただ、お前みたいなライブラリしか使ったことねぇ経験不足が多いからCPUのデコード/エンコードが軽いと勘違いするやつが多いっていってるだけ。 >>846
モバイルだとまだまだ画像のCPUデコードにもある程度時間がかかると言いたいのはわかったし
くだらないマウンティングや昔語りについては他所でやってくれって感じでどうでもいいんだけど、
・モバイル環境で画像のGPUデコードができるのか
・GPUデコードした場合、CPUデコードと比べて速度はどうなるのか
という点に関する情報はないの？ >>827
侵食してくも何ももうwindows10も素でwebp扱えるし……
自分は長期保存する可逆圧縮画像はほぼwebpに置き換えたわ（raw画像などはそのまま） >>847
それは気になる
>>840
>経験不足
>まともに自分で1回も実装したことすらない
すまんな >>848
オレの中ではペイントが扱えるようになるまで
素で扱える扱いにはならないw Glideと聞くとVoodooの専用APIの方思い出すよね >>455
膨大な通信によるバッテリー消費+端末の冷却の問題、サーバー側が安定して供給できる事が前提だよね
そもそも外部出力するんでもなければ現状のdpiでも十分すぎると思うから8kあってもね…
普段使用するサービスで安定した通信量が確保できなかったら通信待ちとかブロックノイズまみれにもなるし
その時代の端末で冷却がボトルネックにならない程度の負荷に収まるなら圧縮されているに越した事はないと思う >>854
せっかくビルドしてくれるならzen1向けにAVX2切ったのくれ 歴史的に見れば、通信帯域は拡大していってるけれど、同時に、
データ圧縮技術も伸びていて、バイナリ、画像、音楽、動画、
どれをとっても、昔より高圧縮高品質になっている。
つまり、広帯域高速通信が普及すれば圧縮率は気にされなくなる、という意見には意味がない。
それは歴史が否定してる。 そうは言っても画像はなかなか置き換え進まなかったろ
jpeg2000とかw >>857
それは、デファクトスタンダードが決まらないと、皆が採用しにくいのに、
皆が採用しないからデファクトスタンダードが決まらないというジレンマがあったせい。
しかしそのジレンマも今や意味がなくなった。
なぜなら、IT大手が自社利益のためだけに勝手に開発し、勝手に使う世の中になったから。
mp3の次が決まらないなか、Appleは勝手にAAC使って、ipodで音楽業界を席巻した
映画ドラマ業界がH265が標準だ！と言ってる間に、
GoogleはOn2買収してVp9開発してYoutubeで勝手に使い始めた。
音も勝手にOpus採用し、皆何も意識せずにVP9とOpusを視聴してる。
今では知らない間にAV1が使われてるね。
画像も勝手にWebp作って画像検索で使ってる。誰も意識してない。
標準化作業とか、多数企業の合意とか、そういうの不要な世の中になっちゃったのよ。 >>859
それだよな。
コンピュータでやれるようになったからそのへん自由になった。
純粋に、且つわかりやすい。いいものが流行る。銭ゲバは淘汰される。
それだけ。 iTunesもyutubeもそれを決めた、待ってたのでなく
そういうデファクトスタンダードを自分らで作ったから
その上で自由に速く事を進められたということなのかな >>861
時代は変わって方向を決めるのは老害の勝手な都合やワガママではなく有能のやる気、になったんだよ。
そのほうがずっと健全だわな。
有能で新しいものいいものどんどん出すやつはその時点で重用するべき。なんでもだが。出し惜しみとか最悪だしな。
今のit大手があれだけ勝ってるのはそれを単純にやり切ってるから、というだけ。 AV1圧縮率がHEVCより30%〜って記事見かけるけど
2018夏ごろの比較だと、AV1は同じビットレートのHEVC、VP9より画質悪いんだけど・・・
画質も30%悪くなるものに、価値あります？ >>863
画質も圧縮率もAV1の方が高いけど
https://i.imgur.com/t0LBPfJ.png
HEVCは特許でゴネてるせいでブラウザで再生されないので価値としては論外かな ttps://www.singhkays.com/blog/av1-ecosystem-update-december-2019/
AV1 Ecosystem Update: December 2019 >>866 VMAF95で大体これくらい？
libaom_c1_2pass 1760kbps
libaom_c1_1pass 1960kbps
libvpx_vp9_c0_2pass 2060kbps
SVT-AV1_encmode1_1pass 2130kbps
x265_veryslow 2220kbps
rav1e_s1_1pass 2440kbps
x264_veryslow 2450kbps
x265比で約12％、2Passなら21％差か Eve-vp9がx265より少し遅い程度のエンコード時間でlibaomと同じくらい圧縮率高くできるんだよな
エンコーダがどれだけ大事かわかる
libvpxがそれだけ優秀だったらもっとvp9流行ると思うのにね H.265よりエンコードがちょっと遅いくらいで倍圧縮できる規格はよ 移動体通信100Gbps時代に求められる次世代コーデックとはどんなもんなんだろうね
ドコモ、5Gの次世代「6G」のコンセプト公開 「5Gの10倍」「複数要素の同時実現」「宇宙までのカバレッジ拡大」など - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2001/22/news096.html 惑星間通信を想定したtcp/ipについての記事を日経ネットワークか何かで20年くらい前に読んだことがあるが
いよいよ実現するのか 5G6Gは動画よりもVRに革新きそうでちょっと期待してる 量子コンピュータも勉強させられてから25年くらい経ってるし
頭の良くない人間としてはこんな役に立たないこと教えてほしくなかったな いい年してスレタイも理解でき・・・頭のよくないオッサンには無駄な事ばかりな世の中だろうけれど、
無駄なものを勉強しなくてもあんたの人生には大差ないさ EVE-VP9の関連記事読んでると、VP9にはまだまだ可能性あるなと感じるね。
画質、エンコ速度ともに、まだまだ伸びそう。
AV1も、SVT-AV1がマルチコアで結構まともな速度出してるし、
規格の問題ではなく、実装の問題だとわかったことは大きい。 >>881
量子コンピューターは、そもそも明確な定義がないし、今のところコプロセッサにしかなりようがない。 >>883
NHKの相撲中継や録画だとみんなのうたとか間違いなく昔の録画より画質が上がってるな。やっぱり大事なのは実装な感じ。
よく観察すると細かい被写体はボカされて輪郭がハッキリしてるとこにビットを割り振ってる気がする。MPEG2だし動きやビットレート不足のノイズが
特に目立つ紅白やサッカーはどうしようもないけど。サブスクリプションでEVEのエンコーダ使いたいわ。市場が小さすぎるしB2Bメインになるのは仕方ない気もするけど。 アナログ時代の素材を現在地デジで流している画質に関して言えば
そのほとんどが当時のアナログ構成の映像が上なので比較にならない
現在の地デジ向けにキャプチャ&エンコードする際に
恐ろしいまでの劣化が生じている
アナログリアルタイム視聴してた世代はわかると思う ブロックノイズや輪郭のモスキートノイズなどとは無縁だが
線ののボケや色のズレ、電波の反射で起こるゴーストなどなど
クソくらえと思う要素は多くあった
>>885
元のビットレートが減らされてるから得手不得手はある
私の地元のNHKは静的なシーンでビットレート落としすぎてブロックノイズ祭りになってる
それがgeforceを買ってamatsukazeに完全移行を決行した原因 放送段階でブロックノイズ出るならts抜きしても意味ない気が アナログが良かったという人、放送局のそばに住んでたとか立地が恵まれてる人だけじゃないかなあ あとは信号が弱すぎてアナログだと辛うじて見れてたのが見れなくなったとか？ >>889
デブロッキングフィルタという、ブロックノイズを消すフィルタがあるのだ
amatsukazeレベルの適応型の高精度デブロッキングフィルタは（DTV界隈で）他に類を見ない水準 そもそも放送ってその性質上
動画ファイルとは違って静的なシーンで極端にビットレート落とすことできないよな？ >>890
もしも>>886の書き込みを見て言ってるなら
ちゃんと読んでほしい
アナログ放送が良かったとかレコード厨みたいなことは全く言ってない
「アナログ時代の素材を現在地デジで流している画質」のこと
キャプチャとエンコードされた地デジしか見たことがない人は
それ本来の画質以下だよ、と言ってる >>890
もしも>>886の書き込みを見て言ってるなら
ちゃんと読んでほしい
アナログ放送が良かったとかレコード厨みたいなことは全く言ってない
「アナログ時代の素材を現在地デジで流している画質」のこと
キャプチャとエンコードされた地デジしか見たことがない人は
それ本来の画質以下だよ、と言ってる ならいいんだけどね
実際は「地デジ ビットレート グラフ」で出てくる録画人間さんを見ればわかるようにかなり乱高下してる >>895
よく理解できないんだけど、本来の画質とはなんぞ インターレース映像を完璧にアップスケールなんて無理じゃね、インターレース同士であっても また過去の栄光の話で重箱の隅突っつきあうのかよ
つい最近ものすごく似たどうでもいいやり取りを見た >>897
言葉がまだ足りなかった
「アナログ時代の素材を現在地デジで流している画質」のこと
「アナログ時代の映像を下手くそにキャプチャとエンコードされた映像で」
「地デジ放送で流されているのしか見たことがない人」は
「アナログのままアナログの機材で視聴している画質より」
「かなり落ちた画質ですよそれ」と「言いたい」
連投すまそ ソースと受信する容量と実際に視聴する画面を別にして話さないとアレな気が
ぶっちゃけアナログテレビが黄色くなるし不安定だから実質低画質
大概アナログ機器は高品質にしようとするとコストかかるし、デジタルで安定していてソースと比較してそれなりの画質ならそれでいいと思う オリジナルが上限として加工のステップを踏むたびに劣化していくのは避けられないからそこは仕方ないよな
ただデジタルリマスターとかで彩度やコントラストや色温度を上げるだけでトータルでは劣化してても一般消費者は満足したりするのも事実 >>900
もしかしてインターレース維持リサイズが対策しようとしたやつのこと?
テレシネ縞のままアプコンして劣化してるってやつ アニメでもよっぽどヒットした作品とかじゃないと編集済みのマスターテープが残っていれば御の字って感じみたいだからなあ
EVE-VP9の話向けに比較エンコしようとしていた矢先にwin10機がネットに繋がらなくなって話に乗り遅れたけど
741〜で教えてもらったキーフレーム任意分割エンコだけでも画質が結構上がるから
たぶん似たような手法で並列エンコさせてるんじゃないかと思う
https://f.easyuploader.app/eu-prd/upload/20200127223244_5244625a4c.webm
https://f.easyuploader.app/eu-prd/upload/20200127223304_614c683152.webm >>906
libvpxのAQ含むレートコントロールが下手なだけでVP9規格のポテン
シャルはEVE-VP9が示すようにHEVCに対して勝るとも劣らないんだろ
うなあ。分割＆オプション調整＆リトライってセミオートなやり方
かつCQにすると少しマシになるってのが面白い。
まーったく関係ないけどそのリンク先の２つのWEBM、再生時間(1:30.1380)
タイムコードは同じでもAviUtlの拡張編集で並べると再生時間が変わ
るの気持ち悪いね。
ffprobe video.webm -select_streams v:0 -show_streamsで見れるメ
タデータでもそうだしL-SMASH Worksはr_frame_rateからFPSを読むの
かも。タイムコードは正しいし再生は問題ないからいいけどさ。 >>907
よくよく考えるとH.265/HEVCで頻出するバンディングと偽色の問題が出ないなら
ある程度の適切なシーンチェンジ分割並列エンコしたVP9の10-bitが現状では一番保存目的としても優秀なのかもしれないな
Zen2で多コアが安くなってるし
AV1でも同じ傾向があるなら分割並列エンコは一定の需要が出るかもしれない >>908
現状だとフルHDのアニメ一本を適当にぶった切ってlibaom-av1 (cpu-used4)でエンコードして3時間前後、
ぶった切らずにやるとCPU使用率が悲しいことになって処理時間が酷いことになるので流石にきつい。
https://i.imgur.com/cmkO7hs.png
https://i.imgur.com/7ffKDf4.png
https://i.imgur.com/ScuQXGY.png よくある普通の24分物（35000/23.976/60=約24分） そういえば、libaom-av1もlibvpx-VP9も低解像度に弱いのは同じっぽいね。
タイル分割しやすい高解像度ほど生成出来るスレッド数が多いからCPU使ってくれるけど、
低解像度の動画だとタイル分割殆どしないみたいでCPUコア使い切れない感じになる。
x265もVP9程ではないけど似たような傾向。
https://i.imgur.com/QqA9nbi.png >>909
そういえばもうAV1は実用化してるのか
エンコの画質や圧縮率から言っても画面分割並列化よりシーン分割並列化の方が結果もいいだろうし
技術者の方々の間で流行ってノウハウを恵んでいただけるとエンドユーザーとしては有り難い
しかし最新のハイエンドCPUで3時間とかx264が出始めたあたりの時代を思い出してワクワクしてくるな YouTube LiveでVP9使われている配信見つけたからAVCと雑に比べてみたけどかなりビットレート抑えられてるな
avc240p < vp9 480p < avc360pくらい
ただ低解像度のVP9はビットレート抑えすぎてるのか動きのある場面だとブロックノイズが酷い
AVCは240pでもそれなりに見える画質 YouTube Liveのvp9コーデック使われる基準が分からなくて動画ファイルの取得ができんなあ
UAじゃないみたいだけど >>907
>>906の２つのwebmって、１つ目は23.976(24000/1001)fps、２つ目は23.809(500/21)fpsになってて、
それでも両方ともタイムスタンプはわずかな誤差程度の違いがあるとはいえ両方とも23.976fps相当みたいだけど、
２つ目のwebmがなんかおかしいってことなのかな。
説明がないからよくわからんけど、それぞれどうやって作ったもんなんだろね。
あと、そもそもフレームレートの値とタイムスタンプの値とで齟齬がある場合って、どういう挙動になるもんなんだろ？
再生に問題ないって言いきれるもんなのかがよくわからない。 >>919
LavVideoDecoderの詳細表示で元のy4mと比べてみて
自分が今まで上げてきた動画全部において「分割したエンコードの数だけフレーム数が減ってる」のに今更気付いた…
（おそらくフレーム数の減った結合動画に元のtimecodeを適用したせいでフレーム間隔が間延びしてfpsが下がってるんじゃないかと思う）
>>906の動画で言えば元のy4mのフレーム数が2161
下の分割エンコのフレーム数が2146で分割したエンコ分の25フレームがきっちり減ってる
上の通しエンコのフレーム数も2160で1フレーム減ってるんで自分が使ってるvpx.exeに問題があるのかもしれない 確かにあなたの上げた動画、「なんか数フレーム足りないな…」と
観てて感じていました 私も秒間1万フレームくらいなら完全に視認できるんでおかしいなと思って・・・なわきゃないが
>>921
ffprobe4.2.2.exe -select_streams v:0 -count_frames -show_streams 〜.webm で両方ともnb_read_framesは2161になるし、
HolyWu版の L-SMASH Works 20200118(r1021) で読み込んでもフレーム数は両方とも2161になるので、
実際にフレームが減ってるわけじゃないと思う。
LAV 0.74.1の環境でDirectShowSource()で読み込むと2つ目のwebmだけ2146フレーム扱いになるけどね。
なんにせよ分割エンコしたという2つ目のwebmが23.8095(500/21)fpsと判定されてる時点でおかしいから、
手順のどこかに何かしらの問題があるのだろう。 >>906
>>923
2161Framesに対して1533Framesなのか...？嘘だろ...どうして作られるんだこのファイル。 >>924は勘違い
映像と音声を同期させるためのOpusフレームサイズ60ms、0.06秒のPTS delayが考慮されていない？
2161frames / (90.138秒 + 0.06秒) = 23.8158...fps と計算は合う
求めてほしいのは
2161frames / 90.138秒 = 23.9743...fps ffmpeg（-concat）の仕様なのか
vpxencの仕様なのか…
分割数というよりは-concatで結合した23.976fpsの動画が23.809(500/21)fpsになるんじゃないか、という仮説が個人的にはしっくりくるんだけど ソフトによってフレーム番号を0から数えるのと1から数える場合があるから、
そこをミスってると分割位置で1フレづつ落としていったりするかもね。
フレーム番号書き込んだソースを用意しておくと良いと思う、以下AVIsynthの例
ShowFrameNumber(x=40, y=40, size=36, text_color=$ffffff, halo_color=$0000ff) ITUジャーナル 2020年2月号 | ITU-AJ
https://www.ituaj.jp/?itujournal=2020_02
ITU-T SG16（Multimedia）第５回会合 (PDF)
Digest of the 5th ITU-T SG16（Multimedia）meeting
https://www.ituaj.jp/?download=20905
昨年10月のSG16会合のダイジェスト報告。
・H.264 v14
・H.265 v7
・VVC
>H.265より高効率の次の符号化技術Versatile Video Coding（VVC）に関しては、
> MPEGとの共同ビデオ専門家チーム（Joint Video Expert Team：JVET）の中で検討が行われた。
> JVETの会議は10月1日から開始され、200名以上の参加者と1000件以上の入力寄書を集めた。
> 予定通り、2020年7月の第6回SG16会合で、2件の勧告草案H.VVCとH.SEIを承認予定である。
> H265まではAnnexにあった補足拡張情報（SEI）を今回は別勧告として分離する。
> 並行して、参照ソフトウェアと適合性試験用のストリーム作成の活動も行われている。
> プロファイルに関しては、Main 10、Main 4：4：4 10の2つが検討されている。 >>930
4:2:0 8bitには対応しないってことか？ >>933
対応しないんじゃなく、8bit 4:2:0も Main10プロファイルに含まれるんじゃないかな。
H.264のHi10Pも、H.265のMain10も、ビット深度は8bitから10bitまでという定義になってるみたいだし、それと同じ感じか。
JVET
https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jvet.aspx
→右側の「All meetings」
→Geneva, 1-11 October 2019 の Docs
→JVET-P0894
にプロファイル等に関する定義の草案がある。
VVCではわざわざ8bit用のプロファイルを独立して作る必要はないと判断したんじゃないだろうか。 人間には見えにくい色を予めバッサリ制限しようぜ！という発想があまり好きではない
それはエンコーダー側がTPOに応じて選択すべきじゃないのか >>935
エンコーダーだけ見たらそれでいいけどさ
デコーダーが広まらないと意味ないのよ
制限かけたほうが実装が楽になって広まりやすい >>935
でも理にはかなってるんだな
ビットレートの高低やエンコードモードによらず有益 >>941
botでやってんのかもしれないけど、こまかいコミットがあるたびにスレに貼りにくるのはやめて
ブログかなにかで継続的に公開したほうがいいんじゃないかな・・・。 >>940
Netflixさすが
Googleのlibgav1にAppleも協力してるみたいだし動画配信業者のAV1採用増えそう rigayaさんみたくGoogleドライブとかのフォルダで公開してくれたらいいんやで 日本語の文章
Netflix、高圧縮・高画質AV1ビデオでストリーミング、Androidアプリから
https://news.mynavi.jp/article/20200206-968590/ AV1使うのはいいけど高解像度だと負荷がヤバそうだな
スマホだと720pくらいが限界じゃないか AV1のハードウェアエンコーダーってadrenoもMaliもまだ搭載してないんだっけ https://powerpro.at.webry.info/202002/article_10.html
今まであまり興味なかったけど
av1自体がが2k程度の解像度の低ビットレート化を主眼に進化すれば
なかなか面白いことになりそう
上手くすればmpeg4がmpeg2に取って代わった過去の再現になるかも >>947
AV1がやばいのはエンコード
デコードはたいした負荷かからん >>952
いやFullHD60fpsはかなり重いぞ
YouTubeですぐに試せる
それなりのPCなら問題ないかもしれないが 試したいからリンク貼ってよ
後からそれじゃないだなんだって事になったら二度手間やん デコードの負荷はエンコードの設定にもよるからコーデックで一括にするのは微妙 webP嫌いの人間多すぎて萎えるわ
この老害どもが 動画ファイルとかでかくていいじゃん
回線しっかり強化しろよ >>960が1兆円くらい寄付すればいいんじゃないか NGN網は東日本だけで
作るのに780億円
維持費に毎年300億円かかってる NGNが優秀でも別のところがネックになって活かされないんですけどね この件か
1 サーバル ★2019/07/10(水) 13:06:37.32 ID:a3lIfiTt9
SoftEther社は、数多のISPを代表し唯一開示に協力し、国の会議のNTT東日本の『PPPoEは混雑などしていない』公式見解を弁護する証人となった。
他のISPは『混雑している』と口々に言うものの、なぜか誰も証拠データを公表しなかった。不服があれば皆公表するべきだったのだ。
12 名無しさん＠１周年 2019/07/10(水) 13:12:51.92 ID:o34di3nl0
実はその網終端装置は問題なくてプロバイダ側の設備の問題だったってこと
29 名無しさん＠１周年 2019/07/10(水) 13:22:13.06 ID:hMMtiaPY0
装置の減価償却期間が終わっても入れ替えないからな
機器代よりもサービスを止めずに機器入れ替えのpj (人件費)が高いからな
62 名無しさん＠１周年 2019/07/10(水) 13:34:50.93 ID:aEvux23V0
結局、何処がボトルネックになっているのかは公表したくないって意図がミエミエなんだよな。
コレ公表しちゃうと、あそこのプロバは混んでるから遅いって評価が付いてしまうからねwww 72 名無しさん＠１周年 2019/07/10(水) 13:43:40.02 ID:Ezwag1Qp0
ISPがやっている事は、完全にキャパオーバーでほとんど予約が取れないゴルフ場が更に会員を増やしているのと同じ
限りなく詐欺に近い
213 名無しさん＠１周年 2019/07/11(木) 01:04:56.51 ID:cFeVgJxb0
そもそも網終端装置のデータはNTT側がもっていて、そのデータの開示をISPが受けている格好になっている。
それを見てISP側は文句言ってたはず。
なんかおかしい。
217 名無しさん＠１周年 2019/07/11(木) 01:49:03.35 ID:DPVfkY4G0
実際はISP側の文句は事実無根で証拠データも出せないウソっぱちだったと言うことだろ
そして今回とうとう本当の実態を晒されるに至ったと。
【IPv4】PPPoE、実は混雑してなかった プロバイダの「網終端装置(NTE)・相互接続点(POI)が混雑している」は大嘘
https://asahi.5ch.net/test/read.cgi/newsplus/1562731597/ >>947
どうせスマホだと720p以上の違いよくわからんだろうし720pが限界でもいいんじゃないかという気がする >>968
720と1080だとスマホサイズでもだいぶ違うと思う。 Xperia 1みたいな4Kスマホだとやっぱり1080pと4K動画の違いは明確にわかるよ https://www.phoronix.com/scan.php?page=article&;item=3990x-threadripper-linux&num=2
3990X流石に早いな >>969
Switchはあの大きさの画面で720だが、動画視聴やゲームをやっても解像度の荒さは全く感じない
モバイルで1080は要らない それは視力が低かったりしない？
俺は6インチ程度のスマホでも1080pと720pは結構変わって見えるぞ スマホで720pはもう見たくない
かと言って4Kは過剰な気がする 4K対応スマホならわかると思う
実際手持ちのXperia 1は1080pと4K動画の違いは明確にわかる >>979
1080p vs 720p の話だよね?
1080p vs 720p と 1080p vs 4K は比較する意味が違うんじゃないかなぁ >>974
携帯モードでの話したがら視力関係無くない？
Switchの液晶画面が荒いみたいな意見は全然聞かないけどね
ちなみに1080の映像を縮小して720にしたり、1080に720の映像を表示したりするのとは訳が違う
リアル720の映像を720の液晶で見ないと良し悪しは分からない 文字をあんま表示しないゲーム機だとdpiはあんま気にならんとか 比較するなり注視したうえでの良し悪しの感覚と
通常時に解像度の低さを感じるかで会話にズレがあると思う 53 名前：Anonymous[sage] 投稿日：2020/01/27(月) 12:41:03.09 ID:rgzZZRbB
Chromeでの再生が以前より重いなと思ってたら映像コーデック変わってたのか
CPUの動画再生支援が全く効いてない
IE11は問題なし
https://play.jp/news/190913streaks/
＞Bitmovinについて
＞Bitmovinは、世界中のオンラインメディア企業に対して、ビデオインフラを提供するリーディング企業です。Bitmovinは次世代コーデックとして注目されるAV1の策定を行うAOMediaのプロモーターメンバーでもあり、オンラインビデオの主要な開発の最前線に立っていま
HuluもAV1採用に向かうみたい すまん、HuluもAV1が採用されて既に配信で使われてるみたいね
NetflixもAV1にするとか発表してたけど現状はまだHEVCのままなのかな >>973
確かに粗さは感じなくてもネイティブ同士で比較して違いが明確ならFHD欲しい...欲しくない?でもまあ個人の好みの問題な気もする... >>988
米と日本のHuluは別会社。日本のは日本テレビ系列グループ傘下 エンコしてカットする時にキーフレームが足りなくて細切れでカットできないとしたら
keyintを減らせばいいのかな？
HEVCの話で スマートレンダリング環境があれば別におかしくないと思うけど 次スレ立てチャレンジしてくる。
この後30分ほど音沙汰なかったら規制された可能性があるので誰か頼む。 もしくは>>994が何者かに消されたという可能性も微レ存 次スレ
次世代ビデオコーデック総合スレPart5 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1581244349/
今からテンプレ貼っていくけど、テンプレ案は下記においとくので途中で規制されたら頼むわ。
https://pastebin.com/wVf9gp4M
あとテンプレ張り終わったら保守協力頼む。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 217日 19時間 56分 42秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
