【VP9/AV1】次世代ビデオコーデック総合スレPart7【HEVC/VVC等】
レス数が1000を超えています。これ以上書き込みはできません。
H.264/AVCの後の様々なビデオコーデック全般について語るスレです。
■対象となる主なビデオコーデック
・H.265/HEVC
・VP9
・AV1(AOMedia Video 1)
・VVC(Versatile Video Coding)
次スレは>>980が宣言してから立ててください。
■前スレ
次世代ビデオコーデック総合スレPart6 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1602779979/ ■各ビデオコーデックの概要や状況（2020年2月上旬時点）
●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が採用されるなど、ブラウザの対応も進みつつある。
●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でのハードウェアエンコード/デコード対応状況については下記関連スレを参照。
【NVENC/VCE】ハードウェアエンコーダーを語るスレ8【QSV】
https://mevius.5ch.net/test/read.cgi/avi/1620231885/
↑テンプレここまで 言い出しっぺとしては最初に書いてくれた人に変えて欲しいけど去年2月だし厳しいよね YouTubeの動画のAV1バージョンを落とす方法ってある？ >>15
よく見たら2020年を未来として書いてあるなｗ MAXがAV1のHWデコーダー対応ですってよ奥さん >>23
音声、Opusコーデックが対応してないじゃないか!! >>24
Amazon「次のMEGA MAXで対応しますんで」 opusなんて後からソフトウェアでどうとでもなるだろ opus低ビットレートでもとても品質いいけどカットオフ周波数がAACどころかmp3あたりと比べても低いから24khz辺りまでに拡張したコーデック欲しいよなぁとは思ってる
精神衛生上の問題だけどさ あらゆるファイル形式を高効率でデコードできる「ユニバーサルデコーダー」をMITが開発 - GIGAZINE
↓
あらゆる種類の誤り検出訂正に対応する「ユニバーサルデコーダー」をMITが開発 - GIGAZINE
タイトル修正されててワロタ まぁ、新聞社のサイトでさえサイレント修正はよくあることだし… >>36
仕事柄いろんなディスプレイ見るけど、8K70インチくらいが画素密度的には最適な気がするけど、4Kで37インチは小さすぎる気がする。
リビングに置くサイズ感考えると、4K50インチ、8K65インチくらいが理想な気がする。 >>37
視聴距離を語らずにppiだけ語っても意味無い 革命的なアイデア思いついちゃったんだけど特許取ってきていいか？
オートエンコーダで動画の次元圧縮して特徴量だけ保存するような圧縮技術作れたら圧縮効率の壁超えないか？ >>39
ちょっと調べただけで文献めちゃくちゃ出てくるから特許取るの至難の技 hevcのprofileの詳しい解説（auto, main, main10, main444で何が違うのか等）が日本語で書いてあるサイトってないの？
使おうにも中身がわからんちん 自分でエンコードしてみてmain, main10, main444の違いが判らないなら、mainでいいよ
hevc関係なく後ろに「10」や「444」がついてるのは、それぞれ表現できるデータ量・精度の保持方法が違うから個別でググると色々出てくるよ
HDRや高精度なものはソース・フィルタ・モニタ入れての再生環境、もちろんエンコーダー・デコーダーそれぞれが対応してないとどこかで丸め込まれてしまうけど >>42
親切にありがトン。
実は初心者でprofileで指定するのと、x265のとpresetで指定するのの違いもようわからんレベルでして・・・
もちっと勉強します。 エンコードの入門書誰か書いて…
パラメータとかわけがわからないのおお！
体系的にまとまってるサイトとかあるのかなぁ 量子化配列とか弄るわけじゃないからその辺のブログ読み漁ればわかるっしょ >>44
「x264 marumo」で調べたらちょい古の情報ならでてくる
ところでどのコーデックの何が分からないんだ? エンコード設定凝りだすとPCでは再生できるけど特定の端末で再生がおかしくなったりする場合があるから、結局デフォ最強や 動作原理を知りたいんじゃないの
動き検索のdiaとhexの違いみたいな エンコード品質、時間、ビットレートを天秤にかけると個人利用ではx265(10bit)のveryfast～slowにopusなmkvが現状最適解感がある。
互換性考えるとh265(8bit)/AACなmp4だろうけど。
また頒布前提ならh264+AAC/mp4かせいぜいVP9+AAC/mp4になるのが辛いな 加工転売拡散再エンコ低能旧式ロースペック層にはVP9すらクレームが来るよ 同人で使ったらボロクソに粘着されて叩かれたよ、mp4も入ってたのに何かに触れたんだろうな
ほんと客の振りしたきちがいは怖い 今のWindowsってデフォでHEVCのmp4再生できないんだっけ？ >>54
デフォルトでは無理。
「HEVC ビデオ拡張機能」ってのがMicrosoft公式でMicrosoft Store上にあるけど。 いい加減、動画ユーザーの使用するCPUはKaby Lake以降の世代（=VP9のハードウェア再生支援対応）にしてもらわんと、いつまでたってもH.264の呪縛から解き放てないな スレタイにも入ってるけどまだまだ「次世代」って事なんだろうな
いつまで待てばいいんだろうか……
俺も配布用だとまだ h264 の mp4 って考えだわ 現代のIEことSafariが対応するまでは移行できんな
WebPの時みたいに10年くらいかかるとしたらVP9は2023年あたり そんなにVP9使いたいか？
再生互換性を抜きにしても積極的に選ぶ理由がとくに見当たらないんだが
googleが使ってる理由もライセンス料払いたくないってだけだろ >>60
確かに、4k配信したいだけならh264でアホみたいな通信帯域用意するか
h265でアホみたいなライセンス問題解決すればいいだけの話だもんね VP9の再生（デコード）普通に軽くね？
設定で動画再生支援機能無効にしたブラウザ（FirefoxとChrome）で1080pのVP9がコマ落ちせずに再生出来てるが
CPUは型落ちでRyzenの中でも一番クロックが低い1700 今時の重い軽いて省電力cpu基準なんじゃないだろうか
desktop cpuでデコード間に合わないなんて遥か遠い昔の話のような気がする デコードはHEVCよりVP9のほうが軽い
VP9の方がデコーダーの開発が進んでいるから
HEVCはソフトウェアデコードされることが少ないから開発が進んでいないのかもしれないかもしれないが 最近Youtube LiveでVP9になってることあるけどあれってどうやってるん？エンコーダーを使った配信だとRTMPとHLSしか使えないからVP9配信できないよね？まさかのブラウザから配信？ >>66
いや、そのページは知ってるけど、YoutubeLiveでエンコーダー配信を選択したときに出てくるプロトコルがRTMPSとHLSしかないから、それ以外のはどこからやってるのか？っていう疑問
カメラソースに出力を指定してそれをウェブカメラ配信でブロードキャストしてるってことでいいのか？ >>68
なるほど、そうなるのか
大規模な配信とかなら分かるけど意外と小規模な配信でも見かけたからもっと手軽にできるのかと思ったけど、小規模な配信でも結構こだわってたりするんだな >>69
こんなめんどくさそうなことをしてない人の配信でもVP9になってるのを見たことあるし
視聴者数とかサーバー側のあれこれでH.264とVP9の両方がある場合もあるみたい jpeg xlの技術使ってCPUで余裕でエンコード可能な動画コーデック作ってくれよ
mpeg2以上h.264未満の圧縮率でいいから YouTube Liveは視聴者数の多いチャンネルだけVP9を使っているみたいだ
全てVP9にしたらコストが合わないのかな？ >>71
MPEG 2以上H.264以下の圧縮率でいいならXviDとかみたいなAVCじゃないMPEG 4で十分でしょ >>72
vp9一本だけってわけにはいかないからね
それに次期コーデックの本命はav1 JPEG XLは視覚的可逆圧縮(数学的には非可逆圧縮)に対応しているそうなので、Motion JPEG XLができたら完パケ保存用にちょうどよさそう 放送局同士でやり取りするデータって、ほぼ未圧縮だけど、ちょっとだけ圧縮されてんだよね確か
そういうことを言ってんだろう ただの非可逆を可逆圧縮っぽい名前にしてるだけだろって話でそ
通信データの圧縮って表現なら多分伸張処理で元のデータに戻るかと Apple ProResは非可逆圧縮ではあるけど可逆圧縮と同じような使い方をされているね GoPro CineFormやAvid DNxHDも同じく 再エンコ繰り返しても劣化少ないんでしょ
音声で言うとなんなんだろね？
aacとかmp3は再エンコで即劣化するし エンコーダーが変わりそうなタイミングのRTX4000シリーズは1年も先だしな
H.266/VVCの4Kリアルタイムエンコーダー自体は去年の9月には開発されてるし(一般向けじゃないけど)
あとは需要を待って導入だろう。順番でいえばその前にAV1のエンコーダーが先にきそうだね
改善されてきたとはいえ、HEVCの軽く10倍のエンコード負荷とか言われたらソフトエンコはちょっと手が出ないわなぁ あ、ごめん。今見直したら、去年の9月の話はソフトウェアベースだった・・・勘違いしてた。 どうせ最初はBフレーム使えないとかだろうし次の次のエンコーダまで待てそう Windows11でもxHE-AACに対応してないな ちょっと質問なのだけど、VP9+opusの動画でMKVコンテナに収容しているファイルを、コンテナの形式だけMP4に変換（映像と音声の再エンコードはしない）をしたいのだけど、
GUI環境で使える手軽なソフトはないかな？
音声がopusなのでHandbrakeを使うと音声だけ再エンコードされてしまうので困ってる
何かいいのがないかな？ それくらいだったら自分で書けばいいじゃない
ffmpegのフロントエンドを 多分ググったら1行のコマンドが出てくると思うから、それをbatなりvbsなりで実行する方法とドラッグ&ドロップのパスを取得して代入する方法調べれば動くよ 動画製作者はH.264で高ビットレートにして上げればいいし今の時代コーデック気にしてるの配信業やってる会社くらいだよなぁ ここにきている君が配信業やってる会社の技術スタッフならそうなんじゃないかな いや流石に4K超えてくると264と新しめのコーデックじゃサイズ違い過ぎるしx265ぐらいは使いたくなるでしょ 今後は配信はAV1、放送とかパッケージはH.266になるのかな？ 配信全般かどうかはわからんけど、Google（YouTube）やNetflixはAV1にシフトしたいんだろうね
AppleもAV1には参加したから、再生可能な環境がある程度普及しだしたら一気に流れるかもね
YouTubeに関しては、今年の夏以降、8K動画はHDR、SDRともにAV1がメインになりだしているようだし。
ちなみにYouTubeのAV1の設定だが、以前はVP9のちょうど半分のファイルサイズみたいな極端な設定だったのだが、
最近はVP9の2/3程度に緩和しているようで、画質的にも無理がないように配慮し始めているように感じる。 補足で書いとくけど、従来は用意されていなかった2K動画でのAV1も、視聴者数の多いチャンネルなどでAV1も用意されているケースが増えてきているので、
Googleとしてもやはり移行したいようだね
（コロナ以降、アクセス数が激増して、サーバーの負荷が上がっているのは間違いないようなので） 有名な曲のmvとか再生数めっちゃ多い動画は解像度関係なくAV1になってたりするね Pixel6がAV1のハードウェアデコード対応したらしい >>110-111
来たかぁ
Snapdragonが888+ですら対応してないから、他社もGoogleからTensorチップ買ったほうがいいかもね あるいはMediatekのDimensity 1000以降か
この前発表された、Xiomiの11TがDimensity 1200搭載で値段もほどほどなんだが、FeliCa非対応が唯一の弱点か 普及の準備が整ったという感じはするね
日本というかお役人は「標準化」って言葉に弱いからどっちつかずの状態が続くんだろうけど スマホで思い出したが、iPhoneがiPhone 12からAV1に対応したからめでたいなんて思っていたら、iPhone 11以降のデュアルSIM対応のiPhoneが技適不適合という話が出てきているようで、
スマホの世界もまだまだ混沌としているようだな >>114
h.266などのmpeg系なら国内企業にもお金が落ちるから順当ではある
問題はコンテナや音声なども含めた放送規格自体の出来が微妙なこと
22.2chサラウンドとか無駄すぎる MPEG-H 3Daudioだっけ
あれ凄そうだけど採用すんのかな ソニーの360 Reality Audioも中身MPEG-H 3D Audioなんだけどね コーデックはオブジェクトベースにしといて出口だけ22.2とかでいいんじゃない？とか思ってる 婆さんや早く地上波の放送をネイティブ4Kにしておくれ
と思ったけど4Kになる前にもうテレビで見ること自体俺ほとんどしないから関係なかったわ… 地上波を4Kにするには使う周波数を広げる必要があるだろうけどテレビの視聴者が減り続けている中で公共資源である電波を地上波に割かれる可能性は低そうだ それが割くんだなぁ、利権だから
自分的には縦1080のままVVCで帯域減らすか
同じビットレートぶっこんで画質上げるかしてほしいけど ここの住人は1080pのままVVCに変えて画質アップって理屈は分かるけど、一般層に「地デジの画質が良くなりました！4Kじゃないけど今のTVじゃ視聴出来ないから買い替えてね！」とアピールするのは無理でしょ。4Kじゃないのに買い換える必要あるの？って思われる 地上波ってもういらなくない？
ニュースも動画もネットでいいし、テレビ放送もネットでするみたいだし ネットニュースのほとんどはテレビの内容だし、放送法変えて同時配信できるようになるまではとりあえず意味がある
謝罪広告で儲けを出すような炎上商法蔓延してるところとは線を引いてお金かけて謝罪したり建前上平等な政権公約流したりする為にも公共電波の使い道としてはあっている感じだな
広告媒体として安定した需要がある限り消えないよ。国産パネルがない現状でも韓国産パネル輸入して売ってる商売もあるし、でかい画面にあこがれる層は絶えないしね
でかい画面と高画質への欲求がある限りAV1とVVCの先もまたるのだろう リアルタイムの放送をインターネット経由にする程、無駄なことはない
電波に乗ると害悪なのか？
電波に乗ろうが、IPパケットに乗ろうが何も変わらない
電波に乗る映像はリアルタイムで楽しむのもの
その程度の違いしかない 電波オークションが実現したら画質犠牲にしてチャンネル増える未来が見える… 1440*1080で始めるぐらいならせめてMPEG4が出るまで待てなかったのか、とは思う 地デジの検討が開始された1997年当時はMPEG2が出て1年しか経ってない最新規格だぞ
MPEG4って言ってもAVCが出る前のMPEG4はMPEG2に毛が生えたレベルなわけで待つ意味はなかった インターレースもあるし実質1440x540なのでは
というのと色でいえば720×270画素分程度の情報しか持ってないものをよくフルハイビジョンって言えるよねって mpeg2のインターレース時の色の扱いってどんなんだっけ?
どっかで読んだ気もするが思い出せない 放送大学は1920x1080iで放送してると聞いたことあるけど、本当なんだろうか？
前に見た感じ確かに少し精細な感じがしたけど、気のせいかもしれないw
ちなみに、関東は少し前に放送大学見れなくなった、残念 >>134
そうそれ
インターレース時はどうするんだろうって ほんと地デジが後x年遅くてH.264だったならな.. 4,5年程度遅くても一度決まった策定委員会の利権を含んだ意見はひっくり返らないのがお役所仕事というもの
策定しているメンバーが大儲けするのはコロナの専門家会議見てれば、あぁまたかと思うだけ ワンセグがH.264だったっけ？
解像度もビットレートも糞低いけど Wikipediaによるとこうらしい
動画規格：H.264/MPEG-4 AVC Baseline Profile 1.2
解像度：320×240（最大）
動画ビットレート：128kbps（16KB/s） （例）
フレームレート（コマ数）：15fps（1秒あたり15枚）
音声規格：MPEG-2 AAC（SBR技術の適用は放送局による）
音声仕様：モノラル、ステレオ、デュアルモノ
音声ビットレート：64kbps（8KB/s） （例）
データ放送記述規格：BML（Broadcast Markup Language） Cプロファイル
データ放送ビットレート：約60kbps（約7.5KB/s）（例） 流れ切ってすみません。向こうは誰もいないみたいなのでこちらで質問させてください。
GIFタイプの動画像WebPはブラウザでしか再生できない、それはWebPDemuxerなるものを活用しても変わらない。で合っていますでしょうか？
いちど連番画像に解体してでもいいからmp4などの扱いやすい形式にしたいと思っていたのですが、ブラウザ上で再生されているものをキャプチャする位しか方法はなさそうでしょうか >>135
インターレース時はどうするんだろうってそういやそうだな
トップフィールドとボトムフィールドで色差が同じって輝度が速く変化したらどうなるんだろ
色差と輝度が大きく食い違って圧縮が素直にいかなそう >>140
ffmpegにAWebPをばらしてWebPへRemuxできるようにするパッチが来てるけど、まだマージされていないね
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210908184931.3620755-1-yakoyoku@gmail.com/
今のところ、ブラウザで再生されているものをキャプチャーするしかないんじゃないかな >>142
ありがとうございます
ffmpegもピンポイントで感謝です！
ご迷惑お掛け致しました H.264採用してれば民放でもサブチャン使ってたかなぁ
NHKくらいしか使ってないけど >>141
本物のインターレースの映像を見たことない？時間軸方向にも色が滲むよ。VHSみたいな感じ。 色の指定間違ってたんじゃね
デジタル時代のmpegで目視できるような滲みはみたことないぞ 「mpeg インターレース 色情報」でググって
1ページ目一番下の「改訂版デジタル放送教科書(上)」に説明があるんだけど
図を理解することができない
誰か解説してくれない? >>148
だいぶ分かりやすいな
でもインターレース云々より4:2:2と4:2:0の違いが大きいことに驚いた
ｔｈｘ すいません
ここに貼られていたwebmに自動分割並列エンコードするバッチファイル？諸々あったと思うんですけど
いつの間にか消えていたので作者の方居ましたらお手数ですが再度アップロードお願いできますでしょうか？ Avisynthでシーンチェンジ検出してxargsでエンコードプロセスを割るってやつだっけ
それならダウンロードしたんだけど、わるいが俺はもう持ってないな このスレに分割並列エンコードするバッチはいくつかアップされたけどそれだったら用意出来る
確かたまに動画の最後が少し欠落するバグがあったと思うから修正してアップする これはシーンチェンジ検出とは違うけど面白いよ
自動でチャンク毎に品質チェックして最適なパラメータでエンコードするやつ
https://github.com/master-of-zen/Av1an Netflixはどのエンコーダー使ってるんだろうね？
intelと共同でSVT-AV1開発してるからそれ使ってんのかなとも思うけどアレはまだ動作不安定でlibaomのほうが完成度高い気もするし 元ブログ見た感じだと自前エンコーダーのような気がする 10bitのAV1か
ただし現時点ではSDRのみ
HDRは後日対応予定 去年の夏に決まってたような気がしないでもない・・・wikiでは↓
「Versatile Video Coding (VVC) (MPEG-I Part 3)は、Joint Video Experts Team (JVET)によって2020年7月に発表された動画圧縮標準規格である。
Latest version： 2020年8月29日」
https://ja.wikipedia.org/wiki/Versatile_Video_Coding ・「4nmプロセス」「Armv9」など最新技術てんこ盛りなスマホ向けSoC「Dimensity 9000」をMediaTekが発表
https://gigazine.net/news/20211122-mediatek-dimensity-9000/
●メディア性能
→エンコード：8K30fps、4K120FPS
→デコード：8K60fps
MediaTekもついに8Kまで対応するようになったか
いままでは4K止まりだったのがネックだったが、これで上の書き込みのAV1、VVCのハードウェアデコード対応と読み合わせると、現時点で発表されているチップの中では最強のチップと言えよう >>167
最初はひとまとめにしようとしたけど最終的に２つくらいになってた記憶 一般人が利用できるVVCのエンコーダーってあるの？ Fraunhoferがソース公開してるから自分でビルドすればテストはできる MediaTek、フラッグシップ 8K 120Hz TV 向けの Pentonic スマートTVファミリー Pentonic 2000 を発表
https://corp.mediatek.jp/news-events/press-releases/mediatek-announces-new-pentonic-smart-tv-family-with-new-pentonic-2000-for-flagship-8k-120hz-tvs
Pentonic 2000 は、Versatile Video Coding（VVC）H.266 メディアに対応した初の商用 8K TV チップであり、
今日のストリーミング時代に不可欠な圧縮効率向上を実現しています。
Pentonic 2000 は、Dolby の最新のイメージング技術とオーディオ技術に対応しており、
Dolby Vision と Dolby Atmos 技術で極上のシネマティックエクスペリエンスを提供します。
さらに、ストリーミングサービス用の AV1 と、
最新の ATSC 3.0 を含むグローバルのテレビ放送規格をサポートしています。 実際MediaTekの技術の進化スピード凄いわ。安かろう悪かろうから一気にスナドラの対抗馬だし
まだ製品に搭載され始めたわけじゃないから様子見する必要はあるけど AV1対応でコスパ最高のFireTV Stick 4K MaxもMediaTek HEVC→VVCでファイルサイズが2/3から1/2程度になればいいが、そううまくいくのか？ 米中のもめてる(フリ)間にシェア拡大したもんな
当局の言うこと聞かないファーウェイつぶしはカナダも一緒になってうまく行った感じだしね
台湾に集中してるのがものすごくきな臭いが、生きてる間に併呑・武力行使は見たくないな >>178
それは出来ると思うけどその分の負荷がやっぱ気になるなあ >>178
https://www.soumu.go.jp/main_content/000772674.pdf
長々書いてるけど、HDだと5Mbsp、4Kだと22Mbps程度で十分だと。
2/3から1/2ってのはちょうど妥当な線なのかも。 横軸がエンコード速度(左に行くほど速い)
縦軸が画質(下に行くほど効率がいい)
https://i.imgur.com/woIFFVM.png >>182
SVT-AV1こんなにいいのかよしばらくはHEVC1本で行こうと思ってたが検討するわ
右下にintelとあるし実はAVX512の高額Xeon向け最適化があってそれぇ1桁変わるよとかならあーってなるが >>182
x265のfastとmediumのデータが面白いなぁ >>182
これを見る限りではAV1とVVCは圧縮率的にはほぼ同等かな
どちらでもいいから速くハードウェアエンコーダーを出してくれ vvencってまだ最適化そんなに進んでなさそうだけど
もうちょい速くなるでしょ Shionさんに騙されるところだったが
x266が数か月内にリリースされるってニュースは去年のものだった
redditも死に体だしカネにならないから水子扱いなんだろうか AV1はコンシューマ向けにオプション最適化とかする気あるの？
今のままだとどう頑張っても個人はHEVCしか選択肢ないじゃん >>188
VVCのSubredditが過疎ってるのはVVCのほうで話すべきことをAV1のほうでやってるからというのもある >>182
SVT-AV1のM1とlibaomのcpu0がほぼ同じ品質なのすごい
M0は速くてしかも画質超えちゃってるし．．． >>192
使える
それに、SVT-AV1のページ読むとIntel製CPUじゃないと速くないように読めるが実際はamdの方が早い場合も多々ある SVT-AV1 0.8.8-rc1が出たぞ
>183のグラフにあるプリセットのM9-12が追加されたらしい これだけ速度出るならブロードキャストで使いたいな。
今でもx264のveryfast推奨みたいなのばっかでしょ ソフトウェア板に書き込めないから、ここに書いとく
・無料の動画編集ソフト「AviUtl」を爆速にして快適化するプラグインが公開中
https://gigazine.net/news/20211203-bakusoku-aviutl-plugin/ ギフハブは危ないサイトってASKAも言ってるからね（適当） >>182
twitchもAV1やる気見せてたしそのうち個人配信もAV1になるのかなあ >>182
これよく見ると横軸が時間じゃなくてCPU timeか
待ち時間が同程度なら速さと言ってもいいのだろうけどどんなものなんだろうね windows media foundationあるのに何がしたいんだろう ゲームにゲーム録画機能をシームレスに統合できるとか? ゲームのリアルタイム配信って、GPUメーカー毎にかなり違ってたんじゃないの？
統一されれば配信アプリ側が嬉しいと思われる エンコーダープラグインとか作るときでも
MS側でAPI用意してくれてる方が個別に作るより楽そう ■ようつべのAV1の最近の状況（2021/12現在の個人的見解）
・アクセス数の多い動画は、かなり前にアップロードされたものも含めて、AV1でエンコードされたものが増えてきている。
・最大解像度がHD以下のものも含めて対処になっている。
・VP9と比べるとAV1は幾分品質重視の設定になっているのか、ごく一部の動画では、動画の状態によってはVP9よりもファイル容量が大きなものが存在することも確認済み。
（品質重視をしてくれるのはありがたい）
・AV1の動画を視聴すると、VP9に比べて暗部の見通しがよくなっており、全体的に見やすくなっているように感じる。
・フルHDくらいまでであれば、パソコンの場合、CPUによるソフトウェアデコードでも問題なく再生可。
（4KはさすがにCPUによってはコマ落ちあり）
続く ・AV1のファイル容量について、AV1導入当初はVP9の約半分になるような極端な設定のものを複数確認していたが、
本格的に導入するようになってからは、VP9と比較して約2/3あたりを目標にしている感じだが、
品質重視に降っているためか実際にはVP9と比べてそれほど大きくファイル容量が低下していないものも複数確認済み。
H.264→VP9→AV1と切り替えていくに従い、品質重視になっているためか、ファイル容量的にはあまり大きなメリットが出ていないような気もするが、
テレビなどの大画面で視聴するユーザーが増えていることを考えるとこれはやむを得ないところか。
（むしろ品質重視にしたにも関わらずファイル容量は微減とするならば上々との判断か）
既にダウンロード済の動画も、AV1のものが追加提供開始になったならば、改めてダウンロードしておいたほうが良さげ。
（再生環境が伴えばだが）
・2022年にはMediaTek製の8Kまで対応のAV1デコード対応チップ搭載メディアプレーヤーが発売されるだろうから、エンコード環境もそろそろ整ってほしいところ。 Youtubeで1080pの動画ダウンロードしてプロパティ見てみたらAV1コーデックで、普通に見れる画質なのに約1Mbpsでビックリ 島国根性というか日本人コンシューマーレベルじゃの感覚じゃ想像もできないマシンリソースとエンコード能力だもんな
高性能のゼロ戦手に入れて俺つえーしてるうちに物量と世代交代であっという間に過去のものにされた歴史は繰り返される VP9 VS AV1の画質比較で比較的わかりやすそうなのが一つあった。
Apple Eventの2021年9月14日の動画の冒頭の砂漠シーン。
VP9だと全体的にざわつきやすいのだが、AV1だと情報量は維持しつつ見やすい。 >>211
>>212
はえー今は容量そこまで重視してないんだな 画質や容量でなく経済性から逆算すると同じようなところに落ち着くってことじゃね まず、倍々ゲームにしすぎ
4Kの次は6Kあたりにおさえておけよ 整数倍にしないと面倒くさいし、アップスケールでボヤけるんでね
知らんけど
エミュとかでわざわざ整数倍にするオプションとかあるし >>216
なわけねーだろ
どれだけトラフィックを節約できるかが重要なんだろうが
帯域は無限じゃないんだぞ 新卒1年目のエンジニアが動画の品質可視化ツールを作るまで
https://inside.dmm.com/entry/2021/02/04/video-quality-board
このツール、公開してくれないかな。
CRFの設定詰めるのがめちゃくちゃ楽になりそうだ。 ここまでするならいくらかのIDRフレームごとにぶつ切りにしてそれぞれ最適な設定をして最後に無劣化結合するようなスクリプト作ったら相当改善するんじゃねって SquooshでJPEGXLに変換できるけど
凄いのかコレ >>228
エンコーダが開発途上だからかMozJPEGあたりと比べるとあんまりだけど
Qualityを80以上にすると容量の割に元画像と差が少なく見えるから、最適化進んだら期待できそう
XLの国際標準が今月承認されたから来年あたり盛り上がるといいな MozJPEGを越えるのは、MozJPEGXLなのだろうね
ノウハウは生かせるだろう、期待したい 来年のCPUまでは乗らないんじゃ？
いつも最初にデコードできるようになって
次世代でエンコできるようになるパターンじゃない？ スマホで4kを12Mbpsで見る技術よりも
fhdを1Mbpsとか500kで見れるようにしてくれ デカい方がベクトル方向の圧縮などが効くんだから無理に決まってるだろ。
264時代の話だけど画素数4倍で同程度の品質なら3倍程度のビットレートになるよと例の東方厨がいってた覚えがある、今はもっと顕著だと思う。 >>234
そう思うとCSで音声付き6MbpsのMPEG2-TSって無茶してるよな・・・ MPEG-2で6Mbpsって480iでも無理ないか ffmpegを使用しています。
VP9にエンコードしているのですが、くそ遅いです。
速くなるコマンドあったら教えてください。
使っているコマンド
-speed 2 -row-mt 1 -tile-columns 5 -threads 16 -deadline realtime -speed 8 -row-mt 1 -tile-columns 5 -threads 16 >>242
realtimeオプション有効にしなくてもこんなに速度出るんだな >>241
ありがとうございます。
6fpsです。
CPU遊びまくりです。AV1の勉強します。 libvpxのVP9は解像度高くないとマルチスレッド効かないんだよな >>245
ホントだ。4Kにしたら、33fpsでた。
そうゆうことだったのか。 >>246
これ読むといいよ
256px毎で列分割できることが書いてある
つまり1080pは8スレッドまで
2160pは16スレッドまで使える
https://developers.google.com/media/vp9/settings/vod/ >>242
AV1万能かよ
エンコードパラメーターの設定は随分奥が深いな
理解するのは容易でないだろうけど >>237-239
>>236の書いてるのは多分スカパー！プレミアムサービスの事なんじゃないかと youtubeのakiraがAV1で見られるようになってるな >>238
BSのスカパーはマジでそれくらいのビットレートだよ
1440×1080でそれだからかなり汚い SVT-AV1ってベンチマークの成績はいいみたいだけど実際のエンコードで使ってる人いる？ M6からM8ぐらいなら良さそうだが、回線は速いしHDDは安いし電気代は高いしインターレース保持が不安だからなあ ffmpegのナイトリービルドで簡単に使えるから、聞くより試すほうが早いと思う
結局、自分の用途にあうかどうかだから 今のSVT-AV1のP8はx265 midiumの速度でslow程度の品質みたいな感じだけど正直目視ではそれほど違いが分からない…
あとあまり追ってなかったけどメモリ消費はかなり減ったのかな? 自分はそれほど目が良くないので目視の場合の画質が知りたいのよね
誰かエンコード経験豊富な詳しい人が調べてくれないだろうか
>>259
目視では違いがわからないというのは何と何を比べた場合の話？ 自分で判断できないらssim値を使うのはどう？
"ffmpeg ssim"で検索すれば使い方はすぐわかるよ 暗部、グラデーションの保持が全然駄目ですな、x265との比較だと 2kかつビットレート潤沢ならx264が一番だとおもう
D_S氏などの執念が詰まってるから2kならまだまだ現役 利権がらみの大人の事情が問題になるだけで、基本的後継のほうが規格としては優秀なんだけどな
はっきりしない後から請求される金が絡んだせいで普及しないから汎用性がいまいちで、そうこうしてるうちにh.265の後継が出てきてしまって今後の勢力図がどうなるやら
配信用に開発が進んでる低ビットレート向けコーデックに、具体的な数字出さずにビットレート盛ればっていう条件つけるのもどうかと思うが
(元ファイルよりエンコード劣化してファイルサイズ大きくなる場合もあるだろ？草生えそうだが、みんなやったことはあるだろう)
条件書かない人に、特定用途個別でとか言い出したらきりがないわな >>260
SVT-AV1、x265の各プロファイルをファイルサイズを大体合わせて出力したけど
そもそもビットレート1割程度の画質差であれば余程低ビットレートでもない限り、注意して1枚絵を眺めてノイズを探していくような気の所為レベルの差になるよなぁと実感した話
もう少し熟せばAV1メインにしてもいいかなとは思ったけどね STV-AV1だけど、主観的には色々あるけど、客観的数値は良好みたいね。 >>267
FullHDを小さくするぐらいの使い方だと客観的数値もx265未満
パラメーターを煮詰めたら変わるんだろうけど
今のところはx265かaomのAV1かな レート潤沢な264でも元動画にないノイズがわさわさ乗ってないか 全然関係ないけどたこわさって店によって全然味が違う
うまい店はとことんうまいしまずい店は糞まずい 本当に「ネイティブ超え」をしたのか？ 新ツール「ICAT」で検証するNVIDIAの最新超解像技術の実力
https://www.itmedia.co.jp/pcuser/articles/2112/30/news022.html
＞ICATは、最大4つのビデオ（動画）を開いて、それらを作業ウインドウ内に自由に分割配置して、
＞同時再生できる。各動画は任意のシーンの任意の箇所を拡大することができるようになっているので、
＞ユーザーは、入力した最大4つの動画の画質を、自身の目視で比較できる SVT-AV1でエンコしてみたんだけど、短いソースはいいんだけど、
長いソースをエンコしていると、処理速度が徐々に低下して行く。
あまりに時間がかかるので途中でやめた。
プリセットは5。その他はデフォルト。
SVT-AV1は、最新を自ビルド。RC2も同じ。
ソースは長さは90分程度のH.265で740ｐ。60ｆｐｓ。
ＣＰＵは 5950X
MEM 128GB >>277
処理能力が低下時は60度程度を行ったり来たり。CPU使用率25パーセントから45パーセント。
短いソースを処理した場合、85パーセント以上になる。温度は70度を超える。 まだv1.0.0にも行ってないからね
不安定なところは山ほどあるんだろう プリセット8で、ロングなソースでも処理能力低下は起きませんでした。90fpsを維持。
ただ、短いソースと違い、フルパワーでエンコしてくれませんでした。
SVT-AV1の入ったFFMPEGも使ってみましたが、同じ傾向でした。
また色々試してみます。 何年も開発してるけどいつになったら完成するんだろうな
数値はどんどん良くなってきてはいるが TMPEGシリーズに採用される頃には安定したと考えていいのかもね
もっとも、AV1の再生環境がどの程度普及するのかは未知数だが AV1のHWデコードなら一昨年のNVIDIAGPUやINTELCPUで対応してるもんな av1のハードエンコーダーか
hevcのよりキレイなハードエンコーダーこいやぁ Netflix、テレビ向けにAV1ストリーミングを開始
https://av.watch.impress.co.jp/docs/news/1365497.html
AV1は再生負荷が低い設計だから配信サービス主流になってるのがデカいわな
H.265/HEVCがこの10年近くでUltra HD Blu-ray含めほとんど普及しなかったのも
非HWデコーダー環境だと4k以上の動画を再生できる環境が近年発売のCPUでも一部に限られるというのも大きかったし 会社でCisco WebExっていうウェブ会議ソフト使ってたらAV1のロゴが表示されてびっくりした。
特定条件下でコーデックとして使われるみたい。（普通はH.264） 等速エンコは低解像度が限界って感じかな
ハードエンコーダーがさっさと開発されてほしいが エンコーダーの話になるけど自分が3千番台のグラボ買い換え躊躇してるのも
VVCがYOUTUBE配信とかで使える可能性が０じゃないのもあり得るからなんだよね
HEVCなんかは最近発売のモデルまでBフレ未対応だったりしたし
HWエンコーダーとデコーダーの開発完了と実装は何年頃になるんだろう そこまで耐えられるなら待てばいいけど流石に今考えるのは現実問題でナンセンス VVCのHWデコーダは実装する流れあるのか？
SWデコードですら普及してないのに H.265/HEVCの策定が2013年
NVencでHEVCエンコードに対応したkelper世代のGTX970が発売したのが2014年だから、
2020年策定のH.266/VVCも次世代がその次で対応してくる可能性はあるかもしれない。
ただBフレ対応でHWエンコが実用的になるまでは
2018年9月発売のTuring世代まで6年近くもかかっているから
過度な期待は止めておいた方がいいとは思う。 hevcはライバル不在ととりあえず生きてたBD (4k)が普及の足掛かりになったけど
今のVVCにはライバルはいるしBDは死んでるしで永遠に対応しなさそう HEVCですら未だに殆どのブラウザで再生出来ないしな…
VVCもブラウザでの再生は出来ないままだろうし、Blu-rayは死にたいだし
地デジ4K放送用に使われるくらいじゃないか？ VCCもAV1も仲良く「利用するコンテンツがそれでエンコードされててデバイスがデコードに対応してるからいつの間にか使ってる」っていうVP9ポジになるだけでは？
libaom・SVT-AV1・rav1eとx265/qsv/NVENCを比較するならともかく
YouTubeとネトフリがAV1採用したからAV1大勝利っていう人はネット配信の盛り上がりを考えればその考え自体は間違ってないとは思うけど
DTV板で何してんだっていう vvcは特許問題さえなければh264ポジやろ
ただav1が上手く行かないと危機感なくなってhevcの二の舞いになるって
mpegのエロかった人が言ってた vvcでエンコードされたソースが広がらないとh.264ポジは無理
av1はnetflixやyoutubeなどを抑えてるから
普及のきっかけとしては十分 AV1はすでにHW実装広がってるし
すでに成功していると言っても過言ではない ネット配信はAV1有利？だからVVCは放送とかお役所が採用してくれるか、なのか？ 放送にVVCという動きはあるのかもしれないが
民放にVVCに投資する余裕なんてあるのか？ 犬HKがやるといえば金魚のふんはやるしかない。ただTVやレコ作ってるメーカーがやる気がないのがな
前回の10年にわたる予定だった買い替え需要喚起は、小泉のあほエコポイント政策で半年で中韓にシェア奪われただけだしな
結果的に家電もシリコンも国内生産断念リーマンショック前に内側から崩壊してたもんな
日本は地デジがある限りMPEG2が底辺で残り続けるだろうし、FAXもCDもDVDも卒業できない民族らしくズルズルいきそう
まぁ中からは変わらんわな。外圧に頼ろう。あぁコーデックスレか。VP9→AV1（VP10）、H264→H266(が、全部の以降は10年以上先でも無理だろう？) 早口で自分の話したいことだけ話すタイプのコミュ障きたな お前の悪口言ってないし喧嘩売る必要あるのか?
お前は心にゆとりなさすぎだろ
かわいそうに 日本で地上波を4Kにする余力はNHK以外残ってないだろうね
ネット同時配信だって始められるか怪しい位なのに地デジリニューアルなんて夢のまた夢、何より視聴者がついてこないだろうしVVCも日本じゃ絵に描いた餅扱いされるんじゃないかな
万が一将来ネット同時配信が始まったとしてもAV1のほうが採用される可能性高そうだし 地デジはこのままあと何年続くんだろうな、終わり方にも色々あるから今使ってるUHF帯を明け渡すとして まーたｲﾄｼﾝが電波文飛ばしてんのか
違法リッピングを堂々とやってる奴がTV局を批判するとは笑わせるｗ 何年かぶりにスレ来たけど、libsvtav1というエンコーダが出ていたんだね。
SVT-AV1は 24GB必要と聞いていたけど、ウチの古い PCでもエンコード出来たので嬉しい。
メモリも、3GBしか消費しなかった。
ただ、これまで libx265 -preset veryfastを使用して、同時エンコードできる点が重宝していた。
（寝る前に 50～80本の動画を同時エンコードして放置）
しかし、libsvtav1だと動画1本のエンコードでも重い。
それでも、ファイル容量を減らしたく、設定を変えてみた。
まず、libsvtav1で従来 (libx265 veryfast) の品質を目指す場合、
-qpを最大値 50より下げて（品質を上げて）いくと、
ファイル容量が従来よりも大きくなってしまう。
そこで、-qp 50固定で -preset値を最大値 13から順に下げて（品質を上げて）いくと、
5のときに VMAF品質比較で従来と近いスコアとなった。
（libx265 veryfastは VMAF score: 90.6、libsvtav1 -preset 5で 90.68）
（続く） ただ、もう少し処理を早めたいと思い、6を試したところ 90.26に。
処理速度は従来と比べて 4倍かかるものの、
libx265 veryfastと比べて、ファイル容量が 23.3％減った。
VMAFは 93点が目標だったけど、夢のまた夢。あと数年は無理かな。
とりあえず、従来のエンコード品質を維持してファイル容量を減らしたい場合、
俺の結論は「libsvtav1 -preset 6」。
昨日覚えたての知識なので、無保証だｗ ツッコミ大歓迎！
（ffmpeg version 2022-01-13-git-c936c319bd、Core i7 4770K を使用） >>314
実用的でいい検証だと思う
svt-av1の新バージョン来たら再検証して欲しい
https://www.phoronix.com/scan.php?page=article&;item=intel-svt-088&num=1
最新の拡張命令が使えないとあんまり効果ないかもしれないけど、AVX2がないsandyおじさんでもない限り速くなりそう なんかVMAFスコアが低すぎるような
公称でも自分のテストでもpreset 8でx265 mediumと同程度かスコア良いはずなんだけど
あとqpよりcrf使った方がいいんじゃないかな 実装が甘いドライブのせいでデータ抜かれてるんだしもう自由にさせてやれ 画面キャプチャされたら
どうせコピーされるんだろ？
もう気にするなって >>318
＞Intel SGXには多数の脆弱性が存在し、多くの攻撃に利用されてきたとのこと。
＞Bleeping Computerは「IntelはIntel SGXをサポートしないことで、
＞セキュリティ上の利益を得られます。 ハードウェアではなくソフトウェアで実装してはいけないという規約でもあるの？ 特許料収益に釣られたんだろうけれど
よりにもよって脆弱性まみれなintelの独自拡張を選んでしまうあたりがH.265関連企業だなあ… >>321
そういうアンレギュラーな方法を取らないと再生できない規格が悪いだろ
>>322
暗号化が外れた状態でメモリに展開してはいけないみたいな仕様があったはず AMDが同じような機能実装してたからそちらに期待だな さっきのリンクではうまくダウンロードできないので、他のアップローダーに上げ直しました
https://www.axfc.net/u/4048758.zip >>324
つまり暗号化されたままデコードしてHDMI (HDCP) に流すってこと？ aomenc, rav1e, svt-av1,vpxencのGUIエンコツールの野良言語リソースファイル
このファイルに差し替えてビルドすると表示が日本語になる
最近ロシア語と中国語の多言語対応したから日本語表示を試したのが作った経緯、訳は適当
分 あとは分後のほうがよかったな ここじゃなくてgithubにプルリクしてあげればいいのに メインノートが9世代Intel6コア+RTX 2000世代でAV1 HWデコード対応非対応でクソがって思ってたけど、Twitchの1440p120をヌルヌル再生できたっぽいんだけど、ソフトウェアでもデコードはそんなに重くないのかな？ >>328
たんにデコードしてるかどうかにかかわらずIntel SGX機能で暗号化するってことじゃね 5800Xと2080TiだけどAV1 FHD 60pはNVDEC無しでヌルヌル再生できた
4Kは流石にガクガクだったけど >>327
Githubでプルリクエスト出せばいいのに >>334
逆。ディスクから読んでSGXの中でデコード、そのままCPUの中のiGPU使って
CPUの外に出さない状態でデコードしてたんだけど
脆弱性のせいでデコードしたものを取り出されるからSGX諦めた
Xeonには引き続きSGX載せるようだが
あれなら再生できるんかねぇ SGXで暗号化キー解除→CPU内蔵のGPUへデータ転送（バス経由で転送）
ではなくて、
GPUの中に暗号化キー解除機能を内蔵させて、バスを通さないようにするしかないだろうな。
逆にそれができれば、dGPUでも再生できるようになるだろうし。
※ただし、いずれの方法であっても、ソフトウェアで独自の画質処理を加えることはできなくなるけれど SVTAV1これかなりでかいアップデートだな
高速プリセットかなり使いやすいぞ コンシューマに必要なのはプリセットではない
詳細なオプションなのだよ明智君 「処理が最適化されて高速になった」のか「プリセットの中身が軽いのに変更された」のか分かんないと判断できんのでは… 圧縮率とのトレードオフがあったとしても軽めのプリセットが使い物になる速さになるのは必要だと思うわ、サービスに組み込むかって時に8コア以下無駄目ですとか個人向けにとても使え無いし。
あと確か重めのプリセットはそれを必要とする人向けにより品種重視になったんでしょ? >>346
記事に書いてあるけどな
画質は変わってないよ XMedia RecodeでAV1エンコードできるようになってたから720pのアニメで試したらわしのクソスペックPCでも5fps/秒出たわ そういやMPEG-5 EVCはどうなったんだろうか
全然話聞かなくなったけども EVCは無料版でAV1に負けて有料版でもVVCに負けてるから使い道無いのでは >>315
PCのクロックアップに励み過ぎてしまい、返信が遅れてしまいました。
結果は、速度 3.163％向上、VMAFスコアは前回比ほぼ同じでした。
使用PC
intel Corei7 4770K OC 3.9GHz、32GB
エンコードオプション
-CRF50(初期値) -preset6
今回
ffmpeg version 2022-01-24-git-0a83ecbf48-full_build-www.gyan.dev
SVT-AV1 Encoder Lib v0.9.0
エンコード消費メモリ 1.4GB程度
前回
ffmpeg version 2022-01-13-git-c936c319bd-full_build-www.gyan.dev
SVT-AV1 Encoder Lib v0.8.7-360-g6508db1d
エンコード消費メモリ 3GB程度（未記録につき記憶より） >>316
オプションのrcとenable-tpl-laは未設定でエンコードしたため、初期値はそれぞれ、0と1。
つまり、qpを設定しても、CRFモードでエンコードされます。
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/svt-av1_encoder_user_guide.md
念のため、ご指摘の設定(crf=xxオプション)でも再検証しましたが、同じ結果となりました。（VMAFスコア完全一致） 完全スレチだけど過去に5960X@4.5Ghzで高負荷 連続稼働安定してたからOCして3.9はいくらなんでも低すぎるのでは感が OBSの最新ベータ版にAOM AV1とSTV-AV1のエンコーダーが搭載されてたわ
ただ配信は受け付けるところがないから録画用エンコーダーだけども そのうち、OBSでファイルエンコードのみ行うとかもできるようになるんかね？ SVT-AV1メモリ使用量も減って実用的になったね
すでにx265を完全に超えたか >>356
悲しいことに、うちのは39倍を超えると、エンコード時にブルスクが出てしまって・・・
電圧を上げるとベンチスコアが下がるので、諦めています。 >>354
ん、そりゃ失礼
オプションの事ちゃんと理解してなかった
あとは--keyintがデフォルトでは短めになっている事くらいしか思い浮かばないな シズベル「VVCを使うときには俺にも特許料払えよ！料金は要相談な」 Access Advanceなど知らんのでMPEG LAに金払えです
MPEG LA Introduces Patent Pool License for VVC Compression
https://www.tvtechnology.com/news/mpeg-la-introduces-patent-pool-license-for-vvc-compression シズベル「関連特許は1000件な」
(これだけあれば諦めるだろw) えぇ……VVCもいきなり拗れてるってわけ？
それじゃいよいよAV1の一人勝ちだ 使うほうも織り込み済みだろうけど、どこかの馬鹿な財布のひもの緩いというか金銭感覚のない大手団体が採用内定でもしたんだろうな AV1だって他の多数の特許のどれかに触れてないという保証もないしな
押し黙っておいて広まってから騒ぎ立てられるパターンだとたまらん 既に世界のトラフィックの8割が動画という状況なのに優れたビデオコーデックがいつまでも普及できない状態なんてとんだエネルギーの無駄遣いで不毛な環境破壊だよなぁ 8割もあるのか
10%でも減らせたらかなりの影響があるな >>373
AV1の場合、誰かが文句言ってきた場合はそいつはAV1使えないようにする仕組みになってるから
むしろAV1が一度広まったら勝ち確になる
映像系の商売まったくできなくなる恐れを犯してでも訴訟する企業はいないから後はパテントトロールの相手だけすればいい NetflixとYouTubeだけで5割はあるらしいからな SVT-AV1の性能が向上するのはいい話だろうけどYouTubeとネトフリがAV1だから何かあるの？アップロードや納品でAV1使う訳じゃあるまいし 新しい物に変わった時のメリットが分かりづらい場合、古い物に戻った時のデメリットを逆にしてみればいい
つまり、もしもYoutubeがMPEG2とかになったらどんなデメリットがあるか、を逆にすればいい エロサイトとか自前でエンコーダー作る技術力も無いだろうからSVT-AV1とか使う気がする
AV1のエロ動画があるのか知らんけど ニコニコ動画はh264のFPGA実装だったと思うけどAV1に切り替えたりするのかな
スーパーマンしかできないだろうけど… Shotcutのav1エンコードが、アップデートで半分ぐらいのエンコード時間になった
仕組みは詳しくないので知らないが捗ってたすかる Final Fantasy VII Remake PC版のムービーデータがVP9だった
もうメジャーなゲームでも普通に使われとるな
ただビットレートが16Mbpsとやたら高かったのでVP9である利点があまりない ゲームはoggとかxvid…は見たことないけどOn2とかマイナーコーデックがよく使われてるイメージ >商業用ソフトで使用した場合、そのソフトのソースを公開する義務が生じるため、一部の例外を除けばほとんど使用されていない。アクアプラス発売のパソコンゲーム（『アルルゥとあそぼ!!』、『Tears to Tiara』、『鎖 -クサリ-』、『ToHeart2』）ではその義務を知らずにライブラリを使用していたことが判明したため、ゲームのソースコードを公開することが発売元より発表となった[1]。
こんなことになるなら避けるわな >>386
On2のTrue Motion（VPxの先祖）はセガサターンでの定番コーデックの一つだった。
初代PSはJPEGデコーダが載ってたのでモーションJPEGが使えたけど、
セガサターンはそうではなかったので。 PSも全画面15fpsか上下黒帯の30fpsが大半だった気がする
なので動画性能は末期でサターンが追い付いたか、もしかしたら抜いたかもしれないな
まぁ時既に遅しだがw PSは動画ファイル渡して勝手に再生するだけで、ほとんどいじれない、裏読みもできないひどい仕様だった
解像度変更や切り替わりノイズが入るバグもずっとライブラリに残ってたし、まぁライブラリが未成熟でまともに使えないのが初代PSの最大のバグ FF7で度肝を抜かれたが、背景がムービーの様に動きながらポリゴンが動いていたのは、ハードウェアデコーダーを使ってなかったって事か？ rigayaさんのQSVEnc 6.08でVP9のハードウェアエンコに対応
VP9をエンコするにはAlderlakeかIcelakeが必要らしい VP9は暗部の再現性が今一なので、暗部の再現性が向上しているAV1のエンコードに、さっさと対応してもらいたいな >>392
FF8は動画の上を3Dモデルが動いてなかったっけ？ 動画をテクスチャに使うデモがプレイステーション公式SDK(PSYQ)にあるな
https://youtu.be/eZ9jmrbB9SY
ビルボードに貼って>>396みたいに動画の上を3Dモデルが動くみたいなことができたんじゃないか >>392
公式ライブラリが提供するSTR動画ファイルはディスクの帯域使い切る仕様だった。素直に裏読みできないな。
ゲーム内の背景とかはインメモリだったんじゃないの。
STR動画の仕様 - https://github.com/m35/jpsxdec/blob/readme/jpsxdec/PlayStation1_STR_format.txt パクリ企画ばかり出すゲームデザイナが新機軸！って背景で動画再生という企画があったけど
没って他の開発に移って実現させた輩がいたよ。アイデアはともかくゲームとして内容があれだったけど・・・
懐かしゲーム開発スレかと思った(笑) FF7のオープニングで既にムービーとポリゴンの合成をしてるけど、今見るとポリゴンの方がやたらガクガクしてるw
多分人間が見た目でポリゴンの位置合わせしてたのだろう
8からはちゃんとムービーの座標を使うようになったから綺麗に合成してるのだと思われる AIで画像の複雑さを評価して設定を弄るってことかね 品質基準の設定をより動的に変更できるようにでもするのかね？
再生時の互換性が低下しなければいいが YouTubeは結構細かいチャンクに分けてエンコードしてるから わからないのでここで質問させて下さい。
元ファイルが5分５秒の640*360（H.264/AAC）（拡張子flv）
のファイルをav1でエンコすると音ズレします。
使っているのが ttps://github.com/AOMediaCodec/SVT-AV1
でビルドしたSvtAv1EncApp.exeです。
※ffmpeg内蔵のSVTAV1だと音声はズレませんが画質が好みの綺麗さに
ならないので今回は視野に入れないでください。
手順を箇条書き
①元ファイルを音声と映像に無劣化分離する(ffmpegを使用）
②映像の部分だけ ttps://qiita.com/takehirokj/items/969029942040a63b63ca
を参考にしてエンコ。
③②でできた映像ファイルと①でできた音声ファイルを結合する
ttps://qiita.com/niusounds/items/f69a4438f52fbf81f0bdを参考にした。
④確認すると音ズレが発生してる。 続き（一回で投稿できなかったので）
そもそもSvtAv1EncApp.exeの使い方が間違っているのでしょうか？
SvtAv1EncApp.exeで音声付動画をエンコすると映像のみになってしまっています。
分離や結合時に使用したffmpegはビルド版4.4.1と最新の5.0です両方とも試しましたがズレます。
かれこれ３時間近くやっていますがお手上げ状態です。 yuvファイルにした時点でfpsの情報が消えるからSVT-AV1のコマンドラインオプションでfpsを指定する必要がある(--fps-numと--fps-denom)
yuvではなくy4mを渡してエンコードするとfpsの情報が残っているのでそちらを使った方がいいかも ライブ配信ソフト「OBS Studio 27.2」が公開／AOM AV1エンコーダーを実験的に搭載、「Photoshop」のようなブレンドモードも
https://forest.watch.impress.co.jp/docs/news/1388429.html 405ですが具体的な記述がわかりません。
ffmpeg -i test.mp4 -nostdin -f rawvideo -pix_fmt yuv420p test.yuv
↓
ffmpeg -i test.mp4 -nostdin -f rawvideo -pix_fmt yuv420p test.y4m←で合ってます？
指定してとのことでしたが
SvtAv1EncApp.exe -i test.yuv -n (※1 test.yuv時に作成で見えてる数字、今の場合だと 9150） -w 1920 -h 1080 -b test.ivf
※1 frame= 9150 fps=0.0 q=-0.0 Lsize= 3088125kB time=00:05:05.00 bitrate=82944.0kbits/s dup=117 drop=162 speed= 323x
video:3088125kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% SvtAv1EncApp.exe -i test.yuv -n 9150 --fps-num 30 --fps-denom 9150 -w 640 -h 360 -b test.yuv
Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v0.9.0-31-g9f2da20a
Svt[info]: SVT [build] : Visual Studio 2019 64 bit
Svt[info]: LIB Build date: Feb 13 2022 20:33:47
Svt[info]: -------------------------------------------
Svt[error]: Instance 1: The frame rate should be greater than 0 fps
SvtMalloc[info]: you have no memory leak
と出て完走しません。ご教示くださると助かります。 訂正 411の下から３行目
- w 1920 -h 1080 ⇒ -w 640 -h 360 追記 --fps-num 30 --fps-denom 9150 の部分を削ると作成できますが
結合時、音ズレします。 元の動画のfpsが30000/1001の場合、例えばこんな感じ
yuvでエンコードする場合
ffmpeg -i test.mp4 -nostdin -f rawvideo -pix_fmt yuv420p - | SvtAv1EncApp.exe -i stdin -fps-num 30000 -fps-denom 1001 -n 300 -w 1920 -h 1080 -b test.ivf
y4mでエンコードする場合
ffmpeg -i test.mp4 -nostdin -f yuv4mpegpipe -pix_fmt yuv420p - | SvtAv1EncApp.exe -i stdin -n 300 -b test.ivf
yuvファイルやy4mファイルはpipeで渡せばいちいち保存する必要は無い 訂正 412の１行目、最後のところyuv⇒ivf です。
それとこれでやってみましたがズレました。
ffmpeg -i test.mp4 -nostdin -f rawvideo -pix_fmt yuv420p test.y4m 415さんありがとうございます
今からやってみます。 あとffmpeg内蔵のSVT-AV1でエンコードする場合でも設定を合わせればSvtAv1EncApp.exeと同じ出力結果になると思うけど多分 元の動画のfpsが30000/1001の場合
とありますがffmpeg -i test.mp4でやってもそれらしき
情報が出てきません。どうやって調べるのでしょうか？
すみません聞いてばかりで。 >>419
ffmpeg.exe -loglevel 48でエンコードすればframe_rateの情報が出てくるはず
というかy4m使えばfpsも横幅も縦幅も調べなくていいのだから生のyuvなんて使うメリット無いよ
エンコーダーがy4mに対応してない時にやむを得なく使うだけ 415さんありがとうございました。無事成功しました！
（長い戦いであった） >>410
「OBS Studio 27.2」は「Chromium Embedded Framework」（CEF）がM75からM95へアップグレードされたほか、AJA Video Systems社製品のサポート、AOM AV1とSVT-AV1エンコーダーの追加、ホットキー対応の改善などが行われた。
そのうち、AviUTLみたいなフロントエンドとしての役割も担いそうだな 全く報道されないし、おかしいでしょ、せめて報道くらいして欲しい。
://twitter.com/someone5963/status/1420151187098136577?s=20
「コロナで亡くなった場合は繰り返し報道されますが、ワクチン死の場合はなぜかほとんど報道されません。」
://twitter.com/KDystopia/status/1444670342408990721?s=20
大規模薬害が発生していると疑われる徴候がこれだけ出てるのにすべてデマ扱いのNHK
://twitter.com/Yuta64745343/status/1425525922220756992?s=20
『厚労省さん。多すぎる超過死亡の原因を隠蔽ですか？』
://twitter.com/akahiguma/status/1469462333986861059?s=20
こういう大事なのを公表しないで、感染何人だーとか、病床がーとか、💉止めろよ!!
://twitter.com/2001Kayu/status/1488145997595230208?s=20&t=idsdQFt1H_KhLruikoAa7w
ワクチン後の長期副反応、後遺症に対しても対策してくれませんか？
健康被害が出ても分からないから国は何もしないよーって。ほんと詐欺にあった気分
https://twitter.com/chaosvice/status/1487153626527059968?s=20&;t=KHfaWKvYQEdPmth49GP9Kg
https://twitter.com/5chan_nel (5ch newer account) すでに新型コロナによる肺炎死亡者数は、通常のコロナ他の肺炎を下回っているし
インフルエンザや薬品依存、潔癖症の重症化の方が問題
それはさておき、OBSはRTX2060以降のGPUに完全にシフトした感じだな。いろいろすっきりしてありがたい。 >>424
完全にスレ違いだけど、現在流行のオミクロンは肺炎の重症度こそデルタ等と比べて極めて低いが
そもそも新型コロナウィルスは肺炎の他に血管に炎症を起こす事で受けるダメージが致命となる病気なので、持病がある場合の合併症で死ぬ割合はオリジナルやデルタと然程変わってない。
また、血管は全身に通っているので、1度感染すると体中どこでも不可逆なダメージを残す可能性が有る。
大元発表を信じるのもいいけどそのまま受け取るよりも幾つかデータは調べた方が良いかもしれないよ… VVCというAV1より良いとされてるコーデックを使ってみたいのですが
ttps://qiita.com/yuusukemiyazaki/items/b64a64a253be596de07a
を見てどうにかコンパイルまで成功したのですが。
書いてある通りにやってもコマンドがないよとエラーが出て
うまくいきません。記述の仕方わかる方いませんか？
URLに出ているサンプル動画(aspenという名前)は約2.3GBあります >>426
コマンドがないっていうのはどのコマンドを実行した時に出るの？ >>426
Windowsのコマンドプロンプトで./って打ってるとか？ hage@DESKTOP-9BL61IJ:~$ dir
VVCSoftware_VTM-VTM-15.2 VVCSoftware_VTM-VTM-15.2.tar.gz aspen_1920x1080.yuv ffmpeg-windows-build-helpers test.flv
hage@DESKTOP-9BL61IJ:~$ cd VVCSoftware_VTM-VTM-15.2/
hage@DESKTOP-9BL61IJ:~/VVCSoftware_VTM-VTM-15.2$ cd bin
hage@DESKTOP-9BL61IJ:~/VVCSoftware_VTM-VTM-15.2/bin$ dir
BitstreamExtractorAppStatic DecoderAppStatic SEIFilmGrainAppStatic StreamMergeAppStatic parcatStatic
DecoderAnalyserAppStatic EncoderAppStatic SEIRemovalAppStatic SubpicMergeAppStatic umake
hage@DESKTOP-9BL61IJ:~/VVCSoftware_VTM-VTM-15.2/bin$ EncoderAppStatic -h
EncoderAppStatic: command not found
hage@DESKTOP-9BL61IJ:~/VVCSoftware_VTM-VTM-15.2/bin$ EncoderAppStatic --h
EncoderAppStatic: command not found
hage@DESKTOP-9BL61IJ:~/VVCSoftware_VTM-VTM-15.2/bin$ EncoderAppStatic /h
EncoderAppStatic: command not found
こういう感じになりましてusageが見られないんです。そもそも見てるところが違うのかもしれませんが。 >>427
./EncoderAppStatic -i aspen_1920x1080.yuv -c ../cfg/encoder_randomaccess_vtm.cfg -fr 29.97 -f 32 -wdt 1920 -hgt 1080 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 -b ./aspen.bin
URL先にある（手順）このコマンドですね。エラー出て動きません。 すみません自己解決しました。どうやら実行ファイルの位置にテスト用の動画ファイルを置いてなかったのが原因だったようです。
でもUsageの見方が未だにわかりません。 ソフトの使い方というよりCLIを理解していない人？ CLIはIT従事者とかよく触る人ならこれほどわかりやすいものはないと感じるけど、素人からしたら摩訶不思議なものだからなぁ 今帰宅したところです
hage@DESKTOP-9BL61IJ:~/VVCSoftware_VTM-VTM-15.2/bin$ EncoderAppStatic --help
EncoderAppStatic: command not found
出てこないですね、仕事でPGとかITとか無縁の人なので
CLIについて深く理解はしてないです。初歩程度も怪しいところです。 >>438
EncoderAppStaticだけだとパス通してないと実行出来ないかも
./EncoderAppStaticなら多分実行出来る
あとWSLは使い慣れてないだろうからWindows用のバイナリ使ったらどうだろうか いけましたありがとうございます。そのウィンドウズ用のバイナリが手に入らなくて仕方なく
WSL上のubuntuで動くやつ使っています。 何故VisualStudioなりMinGWではなくWSL上のLinuxを選んだのか…
茨の道を突き進むならそのままubuntuにMinGW-w64をインストールして
Windowsバイナリをクロスコンパイルするべし >>441
答えは簡単で検索掛けて出て来たページの手順に従っただけ
（上にも出ているけど一応これね ttps://qiita.com/yuusukemiyazaki/items/b64a64a253be596de07a ）
クロスコンパイルするのはいいけど手順がわからないって話です。
ffmpegのwindowsのビルド版があるけど、それはクロスコンパイル用のファイルが
あったのとツイッターフレから教わりつつコンパイルに成功したってだけで
深いところまで理解してないです。それが素人です、手順書が全てです。
でもその手順書が違っていたので書いてあるとおりにならないってことですね。 教えてもらえるのが当たり前とは思っていませんが
だからといって独学で学ぶのは窓と比べてハードルが高いですね
もちろんそれを乗り越えて行く人が居る事も知っています。
自分には無理でしたのでここで質問させてもらいました。
答えてくださった方には本当に感謝しています。 ちょっと挑戦してみます
URLありがとうございます。 >>443
少し躓きましたが無事成功しました！URLありがとうございました。 VVC 結論から申し上げますと実用レベルには程遠いので削除しました。
FHD 30fps 19秒の見本動画をエンコードするのに25分経過しても終わらなかった為。
。
でもいい経験になりました手伝って下さった方ありがとうございます。 VVCはAV1よりエンコード重いという報告が有った
それをリアルタイムでエンコードする地デジに使うとか本気か？と思うけどね
軽くエンコードすればそれなりで、時間を掛ければ凄く縮むようなスケーラビリティが有ればいいんだけど ./EncoderAppStatic -i aspen_1920x1080.yuv -c ../cfg/encoder_randomaccess_vtm.cfg -fr 29.97 -f 32 -wdt 1920 -hgt 1080 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 -b ./aspen.bin
↑エンコードコマンド 素材 ttps://media.xiph.org/video/derf/y4m/aspen_1080p.y4m
Computer: ASUS
CPU: AMD Ryzen 9 5900X (Vermeer, VMR-B0)
3700 MHz (37.00x100.0) @ 4857 MHz (49.00x99.1)
Motherboard: ASUS ROG STRIX B550-F GAMING
BIOS: 2423, 08/10/2021
Chipset: AMD B550 (Promontory PROM19 C)
Memory: 32768 MBytes @ 1585 MHz, 22-22-22-53
- 16384 MB PC28800 DDR4 SDRAM - G.Skill F4-3600C16-16GTZNC
- 16384 MB PC28800 DDR4 SDRAM - G.Skill F4-3600C16-16GTZNC Graphics: ASUS TUF RTX 3080 Ti GAMING OC
NVIDIA GeForce RTX 3080 Ti, 12288 MB GDDR6X SDRAM
Drive: WDC WD30EZRZ-00GXCB0, 2930.3 GB, Serial ATA 6Gb/s @ 6Gb/s
Drive: TOSHIBA THNSNJ256GCSU, 250.1 GB, Serial ATA 6Gb/s @ 6Gb/s
Drive: WDC WDS100T2B0C-00PXH0, 976.8 GB, NVMe
Drive: PIONEER BD-RW BDR-208, BD-RE
Sound: NVIDIA GA102 - High Definition Audio Controller
Sound: AMD Family 17h/19h - HD Audio Controller
Network: Intel I225-V Ethernet Controller
OS: Microsoft Windows 10 Home (x64) Build 19044.1526 (21H2) >>450
これでそのスピードだと個人が使えるようなもんじゃないな AV1の出だしもゼロコンマ幾つか分からないfpsだったしVVCもSVT AV1の高速プリセットほどは行かなくとも最適化が進めばそれなりの速度出るでしょう 最適化が進んでないからってのもあるけど、FHD画質ならHEVCもVVCも画質変わらんからVVCを使う意味は無い気がする 本当に画質が変わらないなら帯域が30～50％減るのでVVCを使う価値がすごく高い
という結論になるはずでは...？
VTMでVVCエンコードテストしようとしてもあれは本当にくっそ激烈に遅いので研究用途ぐらいにしかならんよ
研究用途でもサーバークラスターで並列エンコしてあとでできたストリームくっつけてなんとかするレベル
VVenCはまだ現実的な時間でエンコードできる。実時間数十倍ぐらいのオーダー x266の開発ってどうなってるのかね？クローズドで開発はガンガン進んでるのかな？
doom9のほうでも少しレス付いてるけど、クローズドになってて一般人は試せないくらいしか情報無いね 現代の動画規格が複雑になりすぎてエンコーダーの開発も難航してる感じある
SVT-AV1の開発も当初の予定より遅れてそうだし 表に出せないようなコード使ってるに違いない( ｰ`дｰ´)ｷﾘｯ VVCはエンコーダーよりデコーダーの実装が全く広がっていないのが気になる
ほんとにこの規格広まるのか？って感じ 規格決まってからまだ新しいGPUというか新デコーダー実装されてないからな
スマホはもちろんだがPCでも「広がった」」と思うのは、やっぱHWベースのサポートが始まってからだと思う VVCのハードウェアデコードは>>168に書いたMediaTekのスマホ用チップが対応表明済 >MediaTekのスマホ用チップが対応表明済
一次ソースpls 今のでも回線に余裕があるなら
新しいものの開発は進まないだろうね
半導体も不足して再生環境もそう簡単には
新しくならないだろうし av1が普及してそのまま終わりそう Qualcommの対応予定も出たし それはテレビ用
スマホ用チップのVVC対応プレスリリースpls VVCはハードウェアどころかソフトウェアデコーダーも広まってなくないか
VVC再生できる動画プレイヤーあるのかね？ テレビ以外での再生はターゲットじゃないからそんなの誰も作らないでしょ テレビのためにチップ起こそうって会社がそんなにあるのかね？ >>473
タイトルに分かりやすい利点を書かないといけないのに参考記事で丁度いい部分が「動画再生時間」しかないせいでひどいことになってる
高圧縮な動画コーデック「AV1」搭載の噂 とかにできないあたりエンガジェット日本版が終わるのも納得 >>473
＞現在広く利用されている動画コーデック「H.265（HEVC）」
残念、スマホでは殆ど使われてません！ >>473
疑問形で書くならアチアチスマホにならないかも？ とかにしようよ おう、これ記事にしとけ
って資料を上司からぶん投げられた素人さんが資料だけ見てテキトーにまとめた記事なんだろうな どいつもこいつもバカだからさ
閉鎖されて当然なんだよこんなクソメディア
遅いぐらいだよもっと前に閉鎖されるべきだった 日本版engadgetは本国に切られたくらいだからしょうがない >>484
丸ポチマーカーにカーソルを合わせるとポップアップが出るのね
一番遅い hevc 10bit つかっててもx5950で全然実用できてて、
画質もまぁ良いので、次世代普及はまだ先の気がしてくるな あまりデータ量（通信量）が小さくなられても
困る圧力もあるのだろし >>476
広く利用されている動画コーデックでは無いのは確かだけど
スマホ自体はほとんど対応してる上にiPhoneのカメラはデフォだとカHEVC/HEIFだし「スマホでは殆ど使われてません」じゃなくスマホ/PCに限らず「動画配信では殆ど使われてません」だろ SVT-AV1
劇的に速くなってないか
朝起きたら終わってて驚いた SVT-AV1
低ビットレートには強いけど、高ビットレートには弱いな 久しぶりにノートpcでstvav1変換したら1080p30が等倍速で動いたんだけど…どゆこと 11400@5C10Tでffmpeg libsvtav1 -preset12動かしたら1080pで240fpsくらい出たけど
画質はうーん…低ビットレートなら輝けるのか？
H.265から移行するにはまだ厳しいというのが正直なところ >>496
preset 12なんてx265だとsuperfast並の汚さを自ら選んでんだから当たり前だろ
せめてpreset 9～7あたりで比較しろよ、その安CPUでも7くらいまでなら現実的な速度出そうだし >>494
苦手なタイプな動画だった可能性もある
x264とx265でもx265が高ビットレート域でスコア伸びないことがある
なので色んな種類の動画でテストして平均しないとよくわからない SVT-AV1
同じ動画で0.8fpsから14fpsになったぞ
速度上がりすぎだろ
でも仕上がりファイルは大きくなってる
プリセットもビットレートも同じなのにな
色々変わってそう ちなみにRyzen 9 3900で
1080pの動画をエンコードね rigaya氏の最新ブログ記事より
★8bitのアニメ素材においては
・svt-av1 p7はx265 mediumの品質を上回り、p8では同程度か若干下回る
・p7でmediumと同速、p8で1.5倍速程
・p10はx264 mediumとhevc_nvenc qualityの品質を上回り、p11では高ビットレートで下回る
・p10でx264 mediumの0.8-1.0倍速・hevc qualityの1.4-1.5倍速、p11ではp10の1.2倍速程度。
・p11でも品質はh264_nvencには基本負けず、p12の高ビットレートで不利になるくらい。
もうav1でよくね？ AV1はSSIMとか見るといい感じなんだけど目で見るとなんとなくのっぺり感を感じるんだが気のせいなんだろうか x264・x265はデフォだと心理画質っていう
人間目線で見た目の画質を向上させるが代わりにSSIMは落ちるっていうオプションがデフォでオンになってる
(デフォ値だと多少落ちる程度)
SVT-AV1にはそれがないから、x264・x265のSSIMスコアは多少割り引かれてるようなものだと念頭に入れといたほうが良い そのへんはネット配信事業者が旗振ってるせいか割り切りはあるよね
DBだとほぼ無劣化レベルの高画質を暗に求めるに比べて
ネット配信は劣化上等、10Mbps以下で画質破綻しなければ十分みたいな >>501のリリースノートに「--tune 主観的に最適化されたエンコーディングモードの新しいサポート」って書いてあるからこれから徐々に調整されていくと思うけどね svt-av1の0.9でエンコードしたファイルの画像が1回だけ一部破綻してたことがあるから
ちょっとまだ信用できないかなあという個人的な感想
それまでは問題なかったから試しにつけてみた--film-grainオプションとソースの相性が悪かったのかもしれないけど 試しに同一のソースで--film-grain付けずにエンコしてみたら問題なかったのでそれが原因だったっぽい SVT-AV1が0.9.1出たという事で早速試して見たのですが
途中で止まってしまいます。（数回試しました同じところでエラーです）
スクショ→ttps://dotup.org/uploda/dotup.org2733110.jpg.html
0.9.0に戻してやってみると何事も無かったかのように無事エンコードが終わります。
使ったコマンドは
ffmpeg -i test.mp4 -nostdin -f yuv4mpegpipe -pix_fmt yuv420p - | SvtAv1EncApp.exe -i stdin -n 81032 -b test.ivf
です。-nの総フレーム数はAviutlから取得しました。（TMPGEnc Video Mastering Works 7で見ると81033）
どちらを信用したら良いのかわからないけどとりあえず前者を採用。
何かコマンドが違うのでしょうか？それとも実行ファイルの不具合なのでしょうか？
それとも他に原因があるのでしょうか？0.9.2出るまで待った方が無難なのかなぁ？？？
どなたか解決策わかる方居ませんか？ >>509
バグだろうね
issuesのページにもフリーズするという報告が2件ある >>510
情報ありがとうございます
次ヴァージョン出るまで気長に待つことにします。 人間の目ってエッジの効き具合で画質の良し悪しを決めてる気がする
何しろ自分がそうだからなw
YouTubeのVP9はびっくりするぐらいエッジがシャープだから未だに使われてんだろう
AV1はどうにもエッジがボヤけてて泣きたくなる ・【藤本健のDigital Audio Laboratory】MP3より高音質! YouTube/Discord採用の「Opus」コーデックを試した
https://av.watch.impress.co.jp/docs/series/dal/1391385.html いやでもwavとmp3/AACは320kbpsあたりでもABテストしたらかなりの確率で当てられたけどopusは128kbpsどころか場合によっては96kbpsあたりからこれ同じやんってなるから実際すごく優秀だと思う。
いい音源だと音が痩せて聞こえるから聴き慣れてる曲ならそこで分かる
逆に初めて聴くならmp3でも192kbpsあれば絶対分からん 普段はx265+Opus128kでエンコードしてる、コーデックパックのおかげで動画再生に苦労したことはないけど
音楽プレイヤーは未だにアドオン入れないとデフォではOpus再生できなかったりしてちょっとびっくりする
まあ現代の音楽ファイル事情は可逆がスタンダードだから今更音楽プレイヤーがOpusに対応しなければならない理由も薄いんだけど あと数年でav1のハードデコーダ・エンコーダが一般に普及したらav1+opusのmp4が主流になるだろうからその頃には対応結構増えると思うけどね av1ってmp4コンテナにおさまる？
L-SMASHだと無理みたいだけど あとopusってaacみたく音声ディレイの問題ない？ mp4は使ってないからわからんけど
mkvなら収まってる 個人的にはOpusの方がmp4に入るのかが疑問だった >>521
3年前にはAV1のmp4コンテナ対応してるぞ
L-SMASHがカスなだけ 映像部分がVP9のwebmをアニメ板に貼ったら「iphoneじゃwebm見れないからやめろ」と言われたんだがiphoneってそんな貧弱なん? iOSの最新バージョンでは対応しているはずだが
対応したのはつい最近ではある >>522
Opusって低遅延が売りだよ
それでいて品質も優れてるから、こんなに使われるようになったと思うけどね >>531
AppleのAAC-LCだと2112sampleの遅延だけどOpusはどのくらい？ >>533
2112サンプルの遅延ってどうやってそんなに正確に調べたの？ >>533
22.5msだから1080sampleかな Opusの最小フレームサイズは2.5msじゃなかったか
もちろん相応に音質は下がるが >>534
調べるも何も仕様だし実際そのサンプル数分ずらして動画とmuxするとaac圧縮前のwavの動画同期波形とピタリ一致する
音声単体で聞くなら何も問題ないけど、チャプターポイントとか境目で前のシーンぎりぎりまで音声が入り込んでいる場合、遅延で次のシーンにわずかに音声が入り込んでしまう場合がある
ディレイ対策するか可逆圧縮音声ならこのような問題は生じない エンコーダーを通すと遅延する話と、フレームサイズの話をごっちゃにしてる。
どちらも遅延の原因だけど、メカニズムが違う。
前者は挿入した無音も再生することが原因。
後者はフレームを受信し終わらないとデコード始められないことが原因。
エンコーダーを通すと遅延する話について。
エンコーダーは音声圧縮の都合で、データの冒頭(と末尾)に必ず無音を挿入してる。
そして再生時に飛ばしてる。これはOpusもAACも同じ。
（ffprobe -show_frames -select_streams a:0 -i inputした最初（と最後）のフレームのサンプルの数を見てほしい。）
ただOpusははじめから無音の位置の記録を仕様に盛り込んでいたのに対し、AACは後付だった。
だからAACの無音区間をカットしないソフトがある、Audacityのように。 ffmpegのsvt-av1で試しにエンコしてみたが、早くなってるけどもう少し早くなって欲しいわね。
preset5くらいで、保管用の動画を再エンコしようと思ってたけど、早さを見るにpreset8～10くらいにしたい感じになってきている。
みんなはpresetいくらくらいでエンコしてます？参考までに教えていただけると助かります 保存用ならビットレート盛るだろうしx265でよくない?
svt av1は今のところ低ビットレートは強いけど高ビットレートだと圧縮率x265に負けるし
現実的な速度のsvt av1 P5 10bitでもx265 midium 10bitにssim0.987超えたあたりでビットレート比の画質抜かれてる ソース貼りたかったけどなんかNGワード出たので
rigaya 画質比較 (2022.02) 実写編 とかでググって下さい。
アニメ編は対象ビットレート低過ぎて当てにならないかと 自分はssimは0.98あれば満足するのでav1の6か7が一番いいかなって
ちなみに8bitソースね このデータ見るとほとんどの動画で高ビットレート帯でもSVT-AV1の方が成績良いからrigaya氏の使った動画がたまたま相性悪い可能性もある
https://beta.arewecompressedyet.com/?job=test_5qualities%402022-02-01T01%3A15%3A39.081Z&;job=x265_medium_3.4%402021-12-01T23%3A45%3A05.630Z#
↑Reportのところクリックしてね hevcよりav1のほうがブラウザでも再生できるから使い勝手が良いんだよな AV1だとSOCで再生支援効かないからまともに4Kとか再生出来んのよ
PCならデコーダが優秀だからソフトウェアで全く問題ないけどさ スマホやテレビ向けのチップでも大抵AV1対応してるだろ スマホって言ってもAndroidはDimensityとExynosはもうぼちぼち対応してるし、Snapdragonも次から対応開始するから今からなら別にav1で問題ない
iPhoneのことを言ってるならそれはHEVCでいいだろ、Safariも対応してるし >AndroidはDimensityとExynosはもうぼちぼち対応してるし、Snapdragonも次から対応開始
この程度の普及率で「大抵」といえるのかってツッコミでしょ ・【藤本健のDigital Audio Laboratory】「Opus」と「AAC」どっちが高音質? 周波数分析でコーデック比較した
https://av.watch.impress.co.jp/docs/series/dal/1393179.html >>552
今世代次世代で対応してないチップの方が少ないんだから大抵って言っていいでしょ 「大抵」が文脈上どの母集団にかかってくるかによるだろそんなの
「これからの製品群」なのか「現用されている製品群」なのかで全く正反対になる 重箱の隅つついても詮無いで
現代日本で未来志向ポジティブ思考なのは上等や
お後がよろしいようで AV1のソフトウェアデコーダーも改善されてきてるから4Kでも余裕で再生できるぞ 自己責任で使うのはいいがまだ安定してない技術を人にすすめるのは良くない
AVIFのライブラリlibavifも去年古い規格を切り捨てたからな
あれで今まで開けてた画像が開けなくなってしまった 自分でエンコしてSSIM見てニヤニヤしてる奴はいいけど他人のデータ見てさらに他人に薦める奴の気がよく分からん
このスレでも何人か報告してるけどSVT-AV1は暗部のグラデーションがあんまりよろしくないから全編明るいシーンしかないアニメならともかくそうじゃないなら10 bitのx265から乗り換える理由は今のところ無い(SSIMが欲しいならx265で-tune ssimつけてpsy-rd切ればいい)
俺はブラウザでしか再生しないしスマホもテレビもカメラもAV1対応機器を最速で買いそろえるからHEVCは使わねぇだお前らもそうだろってなら好きにしたらいいけど… >>560
その程度で「気が分からん」になる奴の方が気が分からんわｗ
お前5ch初めてか？力抜けよ
お前みたく安定・現実志向の奴もいれば、新技術に期待してて早く使いたい奴もいて当然なんだよ
もっと言うとx265だってx264より遅いから使わんって奴さえいる
「ブラウザでしか再生しない」なんて貶してるが用途次第ではブラウザも必要な、立派な再生環境だから再生できるに越したことはないのは事実
x(H.)265もまだまだ否定されてもしょうがない側だぞ
(SVT-)AV1だと暗部やエッジが怪しいのも事実だが、2018年のAV1公開から丸3年以上経ってようやく現実的な速度・負荷のエンコーダになってきた訳だし、用途次第では実用したい奴がいてもおかしくはない
何を使うも使わんもすすめるも人の勝手、わざわざスレなんか見に来て過信するのも自己責任なんだから、自分なりの使わん理由だけ述べたらほっとけばいいんだよ >>560
自分のデータは参考にしていいけど他人のデータは駄目っていうのがわからん。
データを公表して議論出来ないのなら定量的な評価指標の意味無いじゃん。 元々「ネトフリとYouTubeが採用してるかAV1大勝利！H.265はクソ！」っていうどういう経緯でDTV板に居るのか不明な連中ばっかりなんだししょうがない
どこかしらのサイトでSSIM比較見て(特に用途を指定せず)もうAV1でいいとか言ってる奴がこのスレに居るのは事実なのに>>561みたいに用途によってはだろ！人の勝手だろ！って発狂する奴も居るし >>562
その「定量的な評価指標」のデータが視覚心理最適化でx264/5側は下がってるから本来比較するならそれをoffにする(俺がこうしろって決めつけてるんじゃなくx264/5側がそう言ってる)か
onにした上でやや下がっている事を理解した上で「議論」してればいいけどssimだけ見てav1が優秀ってる人はしてないじゃん(例えば>>502や545) >>560
スレタイ的にはVP9/H.265は比較対象で、技術的には次世代ってわけでもないからな
最新のものを評価するっていう議論は大いに結構だとは思うが・・・
薦められたららホイホイ鵜呑みにするのはネットニュースの記者くらいしか来てないだろ
どうでもいい他人の為に、気にすると禿げるぞ 次世代ビデオコーデック「総合スレ」なんだからその範疇を超えない分何を語ろうが問題無いわ
他人の褌で品評会も大歓迎 コーデック知識がほとんどないにわかなんだけど動画コーデックの知識ってみんなどこで勉強してきたの？
俺はよくわからんからH.264/AVC教科書ってやつ読んで参考にはなったけどスレタイの通りのAV1とかH266とかの参考になる情報どこにあるんだ 知識も大事だけど経験も結構大事
実戦はやっぱり理屈通りにいかないことだらけだから スレ眺めて気になる技術のwikiなりコマンドなり探して試して、分からないとこググれば楽しいよ。
昔映像処理技術の無料の教科書的なPDFが確かこのスレに確か貼ってあったけど、ああいうので色空間なり情報の圧縮の基礎学んでおけばもっと楽しめるかもね。
何も覚えてないけどきっと偉い人が貼ってくれる… >>574
ありがたし…
なんか総務省ってコーデック関連の調査のpdfが結構検索結果にヒットしますよね
総務省の役割なんだ…と思いながら見てる まるもさんのx264やxvid/mpegの解説記事や
猫科研究所のx264チェンジログ翻訳や解説もローカルだけど面白いと思う 今の最新動画コーデックって、いまだにどれもYUVの4:2:0がベースなの？
とすると、意図的に4:4:4を指定しない限り、どのコーデックも真っ赤な物体や真っ青な物体は劣化しまくり？ x264やx265だとそこのビットレート割り当てを増やすオプションがあるから
必要だと判断されたら用意されるんじゃね 赤劣化なんてFlashPlayerで動画再生してた時代の話やん やっと社場に出てきたんでしょっていう・・・
見た目でわかる組み合わせを書いてもらいたいな、気が付かないだけでいつの間にか使ってるかもしれんし 家に転がってる使ってないPCでAV1変換してみようと思ってやってみたが、なかなか時間かかるね。
一応、参考としてfps書いとく ※低性能CPUでごめん
Celeron N4100：1.5fps
Ryzen 3400G（35W）：6.5fps
Ryzen 3400G（65W）：8fps
（SVT-AV1 p5で1080*720、30fpsのH264→AV1の変換）
省電力PCで24時間まわしっぱにしたいけどx0.3くらいのスピードだと厳しいと思うので、
エンコーダがもう少しこなれるまで待つか、プリセットをもう少し調整してみる感じかな？ ちな、PC全体のワット数は
Celeron N4100(HeroBox)：7W
Ryzen 3400G 35W(DeskminiA300)：15W
Ryzen 3400G 65W(DeskminiA300)：25W
くらいだった。一応。 rigaya氏の使ってみたけど
VBRの2passでビットレート指定だと速度指定が働かないのかな？
プリセット5でも6でも速度は同じで1passの8くらいの爆速でエンコしてしまう
CRFのほうはちゃんと指定通りに速度が変わる 2passの件はrigaya氏のコメ欄にも書かれてたな 20年前のH.264を取り巻く環境がそうだったように
20年後は現在のH.264のように動画時間を上回る速度でエンコードが可能になるだろう 20年後にはもっと高解像度高圧縮になるからいたちごっこだろうよ 解像度が16kになるとはとても思えない
なので8kで頭打ちだろう 8Kまでいけばさすがに十分だと思うわ。
人の目で見れる限界付近だろ。 ヘッドセットの解像度って、今んとこ2k2枚ぐらいだっけ？ 8K以上のVRはエロ以外でも流行って欲しいな
ライブや演劇みたいなステージを見るタイプのコンテンツが臨場感あって良いんだけど
4Kくらいだとガビガビになっちゃうから、早くAV1とかで妥当なデータ量の配信ができるようになってほしい >>592
性能いいのだとそのくらいだけど、必要なサイズは画面より遥かに大きいからつらい
VR動画は左右の目で独立した映像が必要だから4K=2K+2Kになるのと
のぞき穴から一部だけ拡大して見るようなものだから綺麗に見せるには必要なサイズが大きくなるのと
球形の映像を世界地図みたいに広げて記録するからロスが大きい 現状の性能いいやつは4Kパネルx2でレンダリング解像度としては10000x5000とかですよ
リアルタイムレンダリングと違って重要度の低い周辺視野だけ解像度下げるとか出来ないのが動画の辛い所
今より低遅延なエンコーダーとネットワークが普及したら元の16K動画をサーバー側でレンダリングして必要な部分だけ送るとかできるかもしれないけど 8Kは2Dなのに立体感を感じられる。
8K>>>>>>>>越えられない壁>>>>>>>>4K
別件だが、この前発表されたMac StudioでAV1のエンコードをしたら、どのくらいの速さでエンコードできるのかが気になる > 8Kは2Dなのに立体感を感じられる
奥と手前でキャッチボールしている映像を観てみたい。そうすれば実際の3D映像と比べられる
まあ絶対に立体感は得られないな 驚異の立体感！8K解像度5インチスマホにご期待ください 8Kはともかくタブレットはそろそろハイエンドぐらいは4Kになってほしい。
視界の占有率スマホよりずっと高いんだから画素数の影響モロあるだろうにDPI7-8年前から変わってないしOLED採用してサブピクセル減らしたりなんだかなぁ感がある。 2Kと4Kじゃ単純に増やしたら面積が4倍あるんだぜ、その分消費電力も発熱増える
業務用はタッチパネル的使い方が多いから細かくなってもな・・・
大手は採算にこだわるからどこかが成功するまでは手を出さないよ。作れないわけではないからね >>600
業務用の話なんてしてない。今のタブレットは高DPIモデルでもドットが余裕で見えて気持ち悪いのよ。
SOCの負荷が増えても結局消費電力はライトの負荷がなによりも重いから問題はパネルコスト
また今のタブレットのバランス的にUX改善にはパネルの高画質化が追加コスト払わすのに最も効果的だと思ってる(カメラ高画質化にそんなに金払いたいか?)
最近のフレームレートを増やす流れににおいては消費電力の増加との折衷案として可変フレームレートが一般的になってるし、同じようにバッテリーやFPSに振りたい時に解像度落とす選択肢が与えられれば全員winwinやん この冬、変換放置のPCの熱で暖をとってきたがもう少しで暖かくなるし環境考えなきゃか svt-av1の変換速度は速くなったってのは聞くけど、libaomはまだ絶望的な速度なんか？
svt-av1のほうが実用的な速度になってきた分、libaomは眼中にない感じ？ みんな、コーデックって何使ってる？
ワイは再生環境の準備しやすさ重視でav1とh264使ってるけど、個人環境だとまだまだh264onlyだったりするのかな？ 同じくほぼH.265しか使わない。
基本的には同じビットレートならH.264より高画質、同じ程度の画質なら容量を小さくできるので。
エンコードにかかる時間は長くなるが、フルHDなら60fps前後、4Kでも30fps近くで変換できてるので我慢できる程度かと思う。 ほぼ静止画に近い動画圧縮したらどこまで縮むか試そうと、NHK将棋録画したんだが、
大して暑くも無いくせにやたら扇子バタバタさせて圧縮率下げようとしてくる奴なんなの？
煽ってんのか？ ほんま動かないでほしいよな
自然の木々とかも揺れるな！ 駒をどういう手順で動かしたかの情報だけ記録すればいいんじゃね >>623
VIEW JETSON ORIN NX MODULE SPECIFICATIONSのとこ 確かにAV1のエンコードだけじゃなくてエンコードの対応もスペック表に書いてるね
https://i.imgur.com/wrG3PZC.png Intelみたいに記載ミスで後から消すとか、HWとは言っていないとか何かありそうな気はするけど
今更Ampereをいじるかどうか疑問が残るところだな AmpareにHWエンコーダ追加ってのは流石に記載ミス臭い気がするな Jetson AGX Orin Developer Kitの方はH.265としか書いてないから記載ミスっぽい感じはする 表記ミスかー
確かに>>625も片方はDecodeと書くべきなのに両方ともEncodeになってたりちょっと変だしな いやこのpdf見たらやっぱりAV1エンコード対応って書いてあるな
>NVENC enables full hardware acceleration for various encoding standards including H.265, H.264, and AV1.
https://www.nvidia.com/content/dam/en-zz/Solutions/gtcf21/jetson-orin/nvidia-jetson-agx-orin-technical-brief.pdf 400ドルなら手が出る範囲だな、よし。
あとは、どのくらいの速度と品質かが気になるけど、どうなんだろ。 400ドルの製品も日本に入ってきたら7-8万だろうな Xavierの開発者キットすら96800だったんだから
少なくともそんぐらいはすると思うぞ ハードウェアエンコードでAV1対応すると一般ユーザになにがメリットなん？ >>641が聞きたいことってつまり
「ハードウェアエンコーダって一般ユーザになにがメリットなん？」
になるよな
H.264や265のHWエンコも無くてもいいけどなぜか世には溢れてる >>642
いや、すでにH.264やH.265に対応していて、動画配信やYoutubeなどへのアップロード、スマホやVR機器などへのストリーミングなどにも支障がないと思うが、AV1に対応するとこれまでできなかった用途に使えたりするのか？ってこと。 ビデオ通話とか画面共有とかが高品質低電力でできる
HWエンコードの普及なしでコロナに突入してたらリモートワークとかリモート授業が少し大変だった av1コーデックで1080pオンライン会議する時代が…？ HWエンコードの恩恵を享受するのはAVIFとか
使われるかどうかは別として >>646
さすがに720pで250kbpsはh.264じゃむりだな
hevcでならいけそうな気はするが有料じゃあな >>645
chromeのwebrtcでav1使える >>647
,.、,、,..,、、.,、,、、..,_,,_ ／i
;'｀;、、:、. .:、:, :,.: ::｀゛:.::'':,'.´ -‐i
'、;: ...: ,:. :.、... :.、.:: _;... .;;.‐'゛￣ ￣
ヽ(´･ω･)ﾉ
| /
U U AVIFか...
やっとPhotoshopがWebP対応したとこだししばらく使うことはなさそう https://aomedia.org/membership/members/
adobeの名前もあるしそのうちやる気はあるんじゃないの
AV1とかAVIFのサポート AVIFは後釜にエンコード/デコード負荷を考えて作られたWEBP2が控えてるし、流行るとしても一瞬なのでは感が有る。 一般的に使えないWeb向け画像形式にわざわざ対応する必要もないし
10年後にsafariがavifとjpegxl対応したらやる気になるんじゃね 今はpictureタグ使えばブラウザの対応状況別に画像を出し分けできるから
Safariとかが対応するまで待つ必要ないよ。
ちなみにJPEG XLにはJPEGへの無劣化変換が可能モードが存在するので、
サーバ上ではJPEG XLで保存しておいて
JPEGしか対応しないブラウザにはJPEG XLから変換して出力することも可能。
https://cloudinary.com/blog/legacy_and_transition_creating_a_new_universal_image_codec M1チップ搭載MacでソフトウェアエンコードできるAV1エンコーダーってあるのかな？ >>658
例えばAVIFとJPEGでブラウザの対応状況ごとに出し分けしようとすると、
容量を無駄に食うけどサーバにAVIFとJPEGの両方を保管するか、AVIFからJPEGに劣化ありの変換をするしかないのだけど、
JPEG XLならサーバにはJPEG XLをおいておくだけでJPEGのみ対応のブラウザには無劣化変換したJPEGを送れるので、
サーバの容量を節約しつつJPEG XL対応ブラウザについては通信量も節約できる。 あれ、「JPEG XLから無劣化でJPEGに変換」じゃなくて「JPEGから無劣化でJPEG XLに変換」じゃなかったっけ SVT-AV1はx86向けの最適化しか入ってないみたいだからM1 Macじゃ遅いだろうな >>663
SVTはIntelが音頭とってるからARM向け最適化は入らなさそう >>664
なるほど、つまりJPEGへの変換に対応したモードのJPEG XLで画像を保管しておけば必要な時にJPEGに変換して送れるわけか
"Better quality" -> "Same quality"の場合は無劣化ではなさそうだけど Intel、ARC AシリーズGPUを発表 - Mobile向けDiscrete GPU、なんとAV1エンコーダ搭載
https://news.mynavi.jp/article/20220331-2307863/
ついに来たぞ 4コアCPUでストレスマキシマムなエンコードしてたんで、
いい加減8コア以上のCPUに買い替えるかと思ってたけど、
AV1エンコードできるGPU出るのか。
どうしよう…。 >>673
サイズ大きくしたくない
でも画質落としたくない
AV1の普通の用途だろ QSVでNVencを上回る画質なら、ちょっと期待しちゃう
でもモバイル用なのとエンコード環境がちょっとパワーダウンするのがな・・・
自分はCUDAがあるからNVIDIAのGPUを使ってる
avisynth neoやdgdecnvが魅力的だから
でもintelにしちゃうとそれが使えなくなっちゃう・・・ >>674
ビットレートの平均値を決める可変ビットレートで容量を最適化するための2パスだが、今時ディスクメディアとかの決まった容量に抑えることもほとんどないので、品質ベースでよくない？ 歌ものだと品質ベースだととんでもない高いレートになる
チカチカ照明にカメラや被写体が動き回るから
なので長年の経験でこのくらいのビットレートだろって2パスを使うことが多い でもそれって結局品質落としてるわけだから品質の値落とすのと何か違うの？ エンコーダーによって2passの役割が違うからなんとも SVT-AV1の1.0出たから0.9.0と比較してみたけどSSIM的には誤差の範囲（両方とも95台）
しかしこの1.0エンコード速度がやたら遅いので結局また0.9.0を使う事にした。
150秒程度の動画エンコの比較なので、そんなに差がつかないのかもしれないが
速度が0.9.0は1.12倍 1.0.0RC1は0.44倍って・・・。 libaomやlibvpxは品質指定であっても2pass推奨じゃなかったっけ
av1anもデフォルトだとその二つは2passになってる >>681
多少速度が前後するのは想定してたけど、半分以下って…。
得意分野とかが変わったのかな？ >>681
デフォルトpresetが変更になったみたいだけどそういうのは考慮してる？ 今帰宅して確認したところ>>684さんの仰る通りでした。
presetを12くらいにすると0.9.0時のエンコード速度になりました。
（SSIMは未確認）
その変更点が書いてあるURL見てみたいので宜しければ教えて頂けませんか？ >>685
Update the default preset to M10 (c4cd06b9) ・ Commits ・ Alliance for Open Media / SVT-AV1 ・ GitLab
https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/c4cd06b9b7aecef041f02dd2f8acc375a3968dd7
デフォ(M12)なんて汚い設定で使う奴が居たの驚きだが、AV1使う意味殆どないじゃん >>686 >>687
URLありがとうございます。
12から10へデフォルト設定変更ということですかね？
そりゃ～時間や電気代を気にせず使えるなら品質に拘るかもしれませんけど
仮にPC2台あっても電気代やPCへの負荷を考えるとやっぱり躊躇すると思います
なにせ貧乏性なので笑
持論ですが等倍切る速度だと実用レベルではないと思っていますので
基本的には等倍程度でエンコしてます。
フィルターやらその他の引数追加していくと0.1くらいの速度まで落ちるので
（今の場合だと0.44倍ですけどせっかちなので待てない）
元ファイルの10倍じゃないですか、自分はとてもじゃないが待てませんので。
23分程度の動画（ゲームキャプチャー）をようつべにUPしてるだけなので
例えば保存用に月１程度の頻度ならそれくらいかけてもいいかなと思いますが
そういう使い方はしていないので。 まあ別に高速presetを使うポリシーがあってもいいんだけど速度比較するなら同じpreset同士でやるとかじゃないと意味は無いよ
あとSSIM見る時もビットレート加味しないと 実は指定してない場合デフォルト値でエンコしてるの今知りました。
いつも-qp 44~46の指定はしてましたけど。
fmpeg -i inputfilename.mp4 -nostdin -f yuv4mpegpipe -pix_fmt yuv420p - | SvtAv1EncApp.exe -i stdin --qp 45 -n 9027 -b test.ivf
毎回こんな感じです、SSIMで調べることもありますが
基本的に動画を実際見て、ブロックノイズだけ見て多ければ-qpの値０方向に上げていく感じですかねぇ
他の方はどうやってるのか知りません。 preset10でそんな異常に重い？速くなったから8でやってる
4くらいまで上げるとさすがに遅くてきついかなって思うけど 元ファイルがShadowPlayの遡り録画でFHD 60fps です。
で上記のコマンドラインでエンコすると0.44倍の速度でした。
CPUは5900X使っていますPB0も設定してるのでクロックは4500-4800MHz
>>691
因みにpreset8で速度はどの程度出ているんですか？遅い速いの数字を教えてもらえたらなと。 ごめんなさいごっちゃになりました。
150秒のファイル（FHD 60fps)をエンコした時の速度です→0.44倍
一行目はいつもエンコしてるファイルのことでまだv1.0.0-RC1ではやってません。 ついでにもうひとつ
このSVT-AV1、エンコード時間に比例して速度が落ちていくんですけど
自分だけですかね？最初は勢いよく行くんですけど最後の方は等倍くらいまで
毎回落ちます。まだ６０分９０分１２０分とかのエンコード試してないけど
等倍切るのではないかと思っています。 >>694
自分はあんまり長いファイルをエンコードしないからわからんけどv1.0.0-rc1で既知のデッドロックを全て直したと書いてあるから改善されてるかもしれん >>694
5時間ぐらいの動画をエンコードしたときに
最初は数時間で終わる計算だったのに徐々に速度が落ちて
最終的に30時間以上かかったことがあった >>692
preset8でFHD動画エンコすると15fps程度、
CPUは5950x、クロックは4.5GHzに手動で固定オーバークロックしてる >>697
15fpsって元動画が30fpsなら速度0.5だし60fpsなら速度0.25しか
出ない事になるけど、よくそんなので耐えられるね俺には無理（苦笑 >>696
貴重な情報ありがとう、やっぱりそうだったのか。 でもデフォの8bitでエンコしてるのさしひいても遅いと思うけどね
10bitでエンコがデフォだと思ってるし フィルタかまさずpreset8の素で8bitエンコしてみたけど80fps程度か あ、ちなみにファイルサイズの容量どうなってます？
２１～２３分間60fpsFHDで約10GBちょい、エンコは
-qp 45の時 1.5～1.7GBくらい -qp 44 で 2GB～2.2GBくらい
SSIMで見ると76%くらいの品質でファイル容量は1/6～1/5程度まで圧縮。
ブロックノイズは多少気になる程度でようつべUPと保存兼ねてる。
知りたいのはものすごく時間かけて綺麗になるのはいいけど容量は元の何割に落ち着いてるのかと >>688
エンコ速度ほしい需要も勿論わかる
でもそれならSVT-AV1でなくとも、視覚的にこなれてるx264 fast～veryfastやNVENCでよくね？と思うのよ
特にNVENC H.265は最新世代(RTX20xxやGTX1650SUPER以降)だとだいぶ画質稼ぎやすくなったから
ウチの環境だと扱うソースの都合上1280x720 8bitばっかエンコしてるせいもあるけど
x264 veryslowやx265 medium～slowくらいの速度なら満足するから、SVT-AV1はpreset 7で使ってる
ソースにもよるけど720p 8bitだと
SVT-AV1 preset 7とx264 veryslowが約90fps(1.5x)
SVT-AV1 preset 6とx265 slowが約45～48fps(0.75x～0.8x)
くらいになる事が多いかな、3900Xで
SVT-AV1 preset 12は600fps(10x)とか出てたまげたｗここまで速くなくてもいいわ 最初にお断り
これ同一人物です(ﾜｯﾁｮｲ a901-UE6D)(ﾜｯﾁｮｲ e501-wq0K)
常にブラウザ４つほど立ち上げていまして間違えて違うブラウザから書き込みました。
GPUエンコのHEVCもやりました。
2Pass 所要時間 ８分ぐらい
（command→ffmpeg.exe -i zzzz.mp4 -vf bwdif=mode=0 -vcodec hevc_nvenc -b:v 9500000 -pass 1 -an -f null - && ffmpeg.exe -i zzzz.mp4 -vf bwdif=mode=0 -vcodec hevc_nvenc -b:v 9500000 -pass 2 zzzz1.mp4）
frame=85932 fps=600 q=-0.0 Lsize=N/A time=00:23:52.20 bitrate=N/A speed= 10x
video:37595kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_ssim_0 @ 00000223d011b340] SSIM Y:0.949046 (12.928180) U:0.968891 (15.071148) V:0.971455 (15.444681) All:0.956088 (13.574171) 自分の場合ようつべにUPするのが主な目的なんですこれでUPすると
汚く見えるんです。それと反映されるまでものすごく時間かかるんです（正確な時間測定してないけど多分20分ぐらい）
それでそのコマンドにブロックノイズ除去とシャープネス（先鋭化）するとちょうど良くなるんですが
それだと時間がものすごくかかるんですそれでSVT-AV1 1Pass -qp 45でやるようになったんです
合計時間と映像の質を見ると後者選ぶほうが早いんです。そういう経緯がありまして今に至ります。 あともうひとつSSIMのような比較ツールは半分くらいしか信用していません。
もう眠いので端折って書きますがffmpegの本をだされているロベルトさんとのやりとりでそう感じたからです。
（俺がだれかわかっちゃうけどいいや）
ってわけでもう寝ますおやすみなさい。 資料だけを見るとマジで優秀に見える
実際に使ったわけではないが youtubeにアップするのが主な目的ならそもそもav1使う必要ないんじゃない？ >>708
プロが使えるレベルのソフトウェアエンコーダーは、ありがたい。
M1 Macでも使えるようにしてくれ プロ向けってなるとWindowsになるからなあ
YouTubeに投稿するくらいならMacでもいいけど ffmpegダウンロードしてsvt-av1のバージョン見たけど、まだ0.9.1だった。
1.0.0当たってるのってどこかにある感じ？ ちょうどstvAV1guiがバージョンアップしたばかり >>710
てかユーザーによるアップロードはサポートしとらんと思ってたけど
AV1はYouTube側で変換してるだけで 昔のニコ動と違って強制再エンコだからわざわざAV1にする必要もないってことじゃない？ 最高の状態でyoutubeに上げるのはH265の10bitのビットレートモリモリでするのが一番お手軽でいい感じ？
どちらにしても再エンコードされるけど アップロードサイズ気にしないならYoutubeが受け付けるファイルで一番ビットレートを盛るProRes 4444 XQじゃないの 試して見ればわかると思うけどH.265でUPすると見られるようになるまで
AV1と比べて時間かかる。
おま環なのか知らんけど上りの速度いくらあってもようつべは
１MB/sちょいでしか受け付けない。
昔再エンコかかっても品質上げるにはどうするか？みたいな話が出た時に
8Kに変換してUPすればかなり綺麗に見られるということでやってみたら変換
に時間かかり過ぎて、これも現実的ではなかった。
ffmpeg -i input.mp4 -c:a copy -vf scale=7680:4320:sws_flags=neighbor,fps=60
-c:v hevc_nvenc -preset:v slow -profile:v main out.mp4 （GPUハードウェアエンコでやって見た。
参考サイト ttps://nyanshiba.com/blog/obs-studio
ttps://youtu.be/JtZrRTdP85I ProRes 4444と4444 XQは可逆じゃないし
「最高の状態」といわれたらUt Videoやx264ロスレスとか可逆のみだぞ、この辺はYouTubeも受け付けるはず 単に汚い画像より
きれいな画像がいいってだけじゃない？ SVT-AV1の1.0.0試した人いる？
0.9版みたいに劇的に速度改善とかしてる感じじゃなくて、
全体的なパフォーマンス改善と調整みたいな感じかな？ >>723
それでわざわざ最高の状態なんて言う？
まあ動画サイトに上げるのに意味不明な拘りだとは思うけど >>724
画質は大幅に改善してると思った。
速度は10bitだとそれほど、8bitは知らん >>706
なんでupするものをav1エンコしてるんだ？
自分もゲーム実況をうpしてるけど、無劣化編集して
そのままHEVCでどかーんとアップロードしてるよ。
twitterに上げてるクリップはtwitter側の制約に合わせてエンコ必要だけど、NVEncでぱぱっとやってる。どうせtwitter側で更にクソエンコされるし。 動画投稿サイトに上げるのは>>727と同意見。どうせ再エンコされるし、視聴者側の帯域にっわせて画質落ちるし、そもそもそこまできれいである必要も・・・。 盲目が上２人いるな理由書いてあるだろうが？理解できないのか？ 727と728はもうちょっと理解してから書き込んでくれ、うぜーわ >>729
NVENCのパラメータもろくに詰められないガイジが何か言ってるな
自ら情報求めといてその態度普通に頭おかしいから病院行った方がいいよ 文章もろくに読めない池沼がよくいうよ
少なくともおまえにパラメータ云々なんて聞いてないが？？
あほなん？タヒれよ糞老害 そもそも品質品質いうならAV1なんて使わず
元ファイルを容量の大きな６TBのHDDにでも放り込んでおけやって感じなのだが
そうすりゃSSIMで１００％じゃねーか
それとも可逆圧縮かけて汎用性でも高めてる苦行僧か？
時間かける意味がよくわからんわ0.25とか0.5の速度なんて実用的じゃないし
そんなもの人に勧めるのはおかしいって話だわ なぁ教えてくれ706に理由書いてあるのに
なんでわざわざ聞いちゃったの？おじちゃん
めがわるいのかな？いや違うな頭が悪いんだな、うんうん ｱｳｱｳｳｰ Sae9-NaBR
こいつか巷で噂の池沼は、みんないうとるわ、なっとく svt-av1の1.0.0-rc1が使えるffmpegのビルドがきたんで試してみたけど、
0.9.1と同じ設定ならSSIM値同じで時間は早くファイルサイズは小さくなってるな
暗部の潰れも改善した感じ 録画はNVENC HEVC使ってるわ
アップロードする際は適当にビットレート盛ったH.264 >>739
おお、順調に進歩してる感じか。
ビルドしてあるffmpeg来てるなら、週末とかに試してみるかな。
所感、サンクス ビルド環境ってどうしてる？
近頃何もかんも自分でビルドせんといかんみたいで svt-av1盛り上がってるなぁ・・。x266来るのずっと待ってるんだけど、いつまで待っても来そうにないね・・
圧縮率はAV1がHEVC比約30%改善、VVCが約40%改善だっけ？
圧縮率的にはVVCの方がいいみたいだけど、わずかな差だし、x266は望み持てそうにないから、AV1に一本化しようかな SVT-AV1入りのffpmegのビルドはどこに転がってるんだい？ 1.0.0の場合は自分でビルドしろ
0.9.1で良いならgitから拾ってきてビルドしてるところなら入ってるはず
ffmpegのバイナリに-encodersのコマンドラインオプション投げてみれば入ってるかどうか確認はできる 5.01だとまだ-svtav1-paramsに未対応だったような気がするから
そこらへん使いたいなら自分でビルドした方がよい 本家のhelpと比べるとffmpeg内蔵のやつはコマンド少なくないか？
それともUsageに書かれてないだけで機能はしてるのかな？
その辺さっぱりわからん。
特殊な事情がない限り
ffmpegをパイプさせて本家使った方がいいと思うんだけど
（やり方は>>415参照)
本家のほうはビルド時間も５分程度で終わる。（CPUによるだろうけど）
更新頻度も高いし、そろそろRC2も来るみたいだし
毎回ffmpegに内蔵ビルドするのだるくないか？
（ダメとはいわんけど） Windows版だと、ffmpeg公式にリンクのある定期ビルドに入ってる >>751
SVT-AV1単体ならrigaya氏がビルドしてるから自分でビルドする必要は無いんじゃないかな
最適化もPGOとLTOが有効になってるから普通にビルドしたものより10%くらい速いはずだし >>747
Windowsならgyan氏のgit masterビルドが1.0.0rc1だよ
ffmpeg 5.0.1ビルドも中身は1.0.0rc1だけど、5.0当時になかったcrfやsvtav1-paramsに対応してないからgit masterビルドの方がいい
ちなみにBtbN氏のビルドはどれも0.9.1まで 本当だ>>755 fdk_aacが不要ならこれ最強だな crfついてるね
libsvtav1 AVOptions:
～中略
-preset <int> E..V....... Encoding preset (from -1 to 13) (default -1)
-crf <int> E..V....... Constant Rate Factor value (from 0 to 63) (default 0)
-qp <int> E..V....... Initial Quantizer level value (from 0 to 63) (default 0)
-sc_detection <boolean> E..V......P Scene change detection (Deprecated, use svtav1-params) (default false)
-tile_columns <int> E..V......P Log2 of number of tile columns to use (Deprecated, use svtav1-params) (from 0 to 4) (default 0)
-tile_rows <int> E..V......P Log2 of number of tile rows to use (Deprecated, use svtav1-params) (from 0 to 6) (default 0)
-svtav1-params <dictionary> E..V....... Set the SVT-AV1 configuration using a :-separated list of key=value parameters keyintって指定するとビットレート1.5～3倍になるのな・・・想像以上でビビる
10秒単位でシークとか辛いんだが ちゃんとオプションの説明読んで使いなさいよ…
Iフレーム挿入頻度の設定なんだから下げたら圧縮率が下がるのは当たり前だし恒例的にフレームレートの10倍程度が適正値と言われてるが、普通のプレイヤーであればそれでも1秒単位で指定した位置から再生出来る。
前のIフレームからそこまでのフレームを全て読み込むので負荷は掛かるが、プレイヤー変更などでなんとかなりそうな範囲ならkeyint120～300ぐらいにはしてもよいのでは サーチする際にIフレームしか再生できないプレーヤーならともかく、Pフレームまで使えるプレーヤーが増えてる現在においては、keyintの値を無駄に小さくする必要性はなくなったように思う。
もちろん、Pフレームの枚数が少なすぎるとサーチがぎこちなくなって内容の把握がしづらくはなるけど。 >>758
MPCで300とかきついわな。ほかのプレイヤーでもいいんじゃない？慣れるまできついだろうけど めっちゃためになります。
MPC以外も試したけど、起動～再生、シーク中もっさりしてて、結局MPCに出戻りしてる
関係ないけどRePlayerってやつチャプタ作るのに便利ですよ みんなIフレームでシークががたつくってどういう使い方してるんだ? 気にならない人はスルーでいいネタだから気にしないで。話題に入れなくても問題ないよ 長年追い求めていた史料動画の復旧について
過去、VLC2.2.8まで再生可能だったものが、3.0以降に途絶えました
VLC17.4の更新を機に思い出し、何度目かの試行錯誤をしています
動画コーデックは「avc high 4:4:4 predictive l5 cabac 4 ref frames」Hi444p
HD-DVDのように捨てられた規格とのことで、Hi444pの再生を諦めていたのが現状です
そして今回ネット検索するとMpegやAVCの単語を含む掲示板スレまでが2005-6年程度
こちらの過去スレを辿っても2013年がせいぜいでした H.264、Mpeg、AVCはもはや論外級の遺物なのでしょうか？
mp4拡張子はyoutube等でも幅広く残り続けている様子ですが
試しにyoutube関連を調べるとその動画コーデックは「avc main l3.1cabac 3 ref frames」とのこと
Hi444pがDQNだった→もう手持ちの価値ある史料を破棄するしかありませんかね・・・orz
『ソフトが更新されれば・・・ひょっとすると・・・』と3.0.0（2018.2）から願い続けたものの、この数年で復活どころか更に過去へ取り残されている印象です
他のソフトも今まで散々試しましたが、VLCで不採用の技術に対応しているはずもなく FFmpegで好きなコーディックにエンコすればいいんじゃね 再生可能だったVLC2.2.8で変換してもいいかも？ なんか大昔x264の可逆圧縮RGB作ったらその後正常にデコード出来なくなったことあるけど同じやつかな VLC自ビルドして使ってる人いるの？
気軽に使う気しない・・・ 動画コーデックって基本YUVだと思ってたけど444なら別にGBRでもいいのか >>772
mp4はただのコンテナ形式だよ、中に入っているコーデックとは直接の関係ない
youtubeだってツールによってはmkvで保存してくれる
ただこのご時世なのでマトリョーシカにちなんでるということもあって避けられる傾向はある
そして非可逆な再エンコードはさらに劣化する作業になるから、勧めてるところはまずないと思う
利用形式の問題でコンバートすることはあるだろうけど >>771 >>772さんへ
よーわからんけど自PCで再生だけならffmpeg同梱のffplayでダメっすか？
ちょっと使い勝手悪いけど慣れるといい感じになるかも 後考えつくのはffmpegのビルド版の同梱のffplayでの再生と
AviutlとかTMPGEnc Video Mastering Works 7での再生なんかはダメなのかな？
最近だとDaVinci Resolveとか。とりあえず見ることが出来ればOKなんでしょ？ VLCのold verならここにありますが？
ttp://download.videolan.org/pub/videolan/vlc/ あとはコーデックパックをどこからか拾ってきたりとか
X Codec Pack（お目当ての物が入っているかわかりませんが）
多分、ここのスレッドにたどり着いて質問しているってことは
全部試しているとは思いますが・・・。 もしffmpegで行けるならffdshowかLAVあたりも行けそうだけど https://www.videolan.org/vlc/releases/3.0.0.html
> VLC 3.0 activates hardware decoding by default, to get 4K and 8K playback!
もしかしてハードウェアデコードしようとして失敗してるのか？
HWデコーダーがpredictiveとやらに対応してないとか https://kurohane.net/seisanbutu.html
直リンク
ttps://kurohane.net/archive/sinkuhadouken_220101.zip
真空波動研 220101 調べる動画を再生→表示→詳細のコピー→テキストに貼り付け
VLCで再生
調べる動画を再生→ツール→メディア情報→コーデック→表示されてる情報を手打ちでテキストへ打つ
動画のコーデック情報を調べるのにようつべが云々という
くだりを見てちょっと不思議に思ったので、調べるにはこういう方法もあるよということで
あ、肝心なこと書くの忘れた
ツールで調べたその情報（コーデック）をここにコピペしたら
良い回答がもらえるかも ttp://www-ise2.ist.osaka-u.ac.jp/~katou/video/x264.html
hi444pで検索かけたら一番最初にここにたどり着いた。
手元にその動画がないのでなんともいえないけど、でもまぁこれも試してるんだろうな・・・。
（独り言 皆さん多くの指摘を有難うございます
この板は地デジ内蔵チューナーを使用していた古い時期、よく利用していました
地上波の存在価値も5chの仕様も様変わりした昨今、久しぶりの投稿・利用です
※録り直しについて
あらゆる理由で画質の劣化を招くため、なかなか厳しい選択になります
技術革新により関連ソフトは高品質かつ種類も増えましたが、開発者の高齢化や中華圏の詐欺が横行する現状、まともなソフトの更新及び入手に限りがある印象です
かつて、ストリーミング系のサイトへ一度アップロードし、再ダウンロードすることで規格の最適化を図ってみては？という方法も見つけました
しかしアップロード行為への忌避と数段落ちるであろう画質の観点から完全除外 ※2.2.8
3.0.0以降の中頃より、音や映像に直接的な不備が見られ、一部史料のためにソフトの運用全体を犠牲にすることが憚られました
2.2.8の設定を後続へ転用したり、設定項目を吟味したり、当時はよく試したものです
抜け落ちがあったのかな？とFFmpeg項目にあるハードウェアデコードの4種全てをON/OFFさせたものの、変わらず
可能ならば、UI関係を除く詳細設定はデフォルト状態で運用するのが望ましいですしね
こうなったら再生可能状態である2.2.8の全設定をSSし、3.17.4のデフォ設定と一項目ずつ比較してみたいと思います
何とかそのための時間を作りませんとorz
※コーデックパックや中華系とGOM以外の他再生ソフトについて
天下のX Codec Pack先生は勿論のこと、更新のある再生ソフトは評判の良い順にほぼ試しています
2018年から常にとはいきませんでしたが、基本はVLCが業界内最上位に位置していますので、他もそれに倣っている様子でした
業界が産廃扱いにした＆するであろうDQN規格を史料製作者は見通せなかった
そしてそんなに酷い規格を未だに必要としている私の立ち位置がそもそもの間抜けでしたね ※史料における使用中コーデック
最新のMediaInfoで確認したコーデック表記が先の内容でした
Predictiveも「High 4:4:4 Predictive Profile」のPredictiveをそのまま示しているのではないでしょうか
過去、2.2.8→3.x.0 3.x.0→2.2.8双方の設定ファイル使い回しで2.2.8による正常動作が確認されています
3.x.0によるデフォ設定で2.2.8には無い項目が新たに追加＋自動有効状態にあり、さらにそれを私がこれまでの間に見逃していることを期待し、洗い出しをしてみたいと思いますorz 訂正があります
私が愛用していたコーデックの筆頭はK-Lite Codec pack先生でした
xも試していたと思いますが、そもそものVLC同梱コーデックを優秀とする意見がネット上で目立ちます
VLC一本で完結する手段があったらなあと甘く考える、そんな自分もいます・いました アップロードして大丈夫なやつならアップしてみたら？
ここの住人が調べてくれるかもよ FFmpegで適当なコーディックでロスレスエンコするのは駄目なん？ もしかして携帯の話だろうか
携帯では俺も動画ファイル再生はVLC使ってる >>800
そう考えると
ロシア製のMPCBEは優しいかな・・・
韓国はスパイ大好きだね >>796
ffmpegは万能ではないよ、デコーダー内包されてないと読み込みエラーでエンコできない。 MPCBEはガチ露ですよ！？っと自身でもお気づきでしたか
ゲームやユーティリティソフト他、露産は軍需製品以外でマシなものがありませんよ
私がMPCBEを検証したとき、ネット上のステマとは裏腹に使えたものではなく、さらに設定のほぼ全てをレジストリへ保存するという90年代の構造で論外に思います
どうしても共産圏は、ネットでの誇大広告と、実よりテレメトリ抽出に偏重する国柄があらゆる要素で散見する
ガチ支那とチョンは勿論のこと、シンガポールやロシアもほぼほぼ同じ畑です
島国日本を除いたユーラシア大陸の東側は文化そのものが強盗と拷問と人肉食に何かしら結びついている恐怖の世界史実ですしね
強盗・拷問・食人が忌避するものではなく、良しとされるゴブリン文化ですから
露産に触れるのはオフライン型ゲームくらいに止めておくのが一番ですよ ロシアも軍部と支配層と庶民と居る
MPCBEは庶民のもんだろ
ソースコードに怪しさは感じない youtubeに4K動画アップするとき、vp9でアップすれば短時間で4k再生できるみたいだけど、自端末ローカルでのvp9エンコード自体が激おそ。
できるだけ速くエンコードする最適な方法って何だろ？ >>803
OSSにどこ製だから怪しいとかねぇよ
本当に叩きたきゃソースコード読んで該当部分提示してみろよ、無能のお前じゃ無理だろうけど 仕事中の休憩時間なのに声出して笑っちまったよ。
OSSなんだから開発者出身国の侵略と争いの歴史調べ漁るより、
その労力使ってソースコード読んだ方がいいってまじで。 >>806
まずvp9に拘る意味がわからん
まあ何使おうが当人の勝手だが 技術革新は大いに結構ですが、主流の横に膨大な量の傍系や産廃が石炭鉱山のボタ山レベルで打ち捨てられ続けてきた現代史は、悩ましいものがありますね
Hi444pもその片鱗ですし
研究・開発と民間投下・商品化の間に一定の品質審査機関を設けてほしいです
アーリーアクセス、プレリリース、開発者向け、試験版、そうした名目で局所的には実現していますが、規模や範囲を少しでも拡張するとソフト・ハード双方で無法地帯になってしまうから残念
まあ、既に民間へ降り始めている量子が、完全に安価となって普及する頃には既存のあらゆるソフト・ハードの価値をリセットしているでしょうけど インテルのHWエンコーダーだと64.7MbpsのH.264と44.9MbpsのAV1が同程度の画質だとか
https://www.youtube.com/watch?v=UlutItCCC5M まあHWエンコーダーは何世代かかけて成熟させていくものみたいなので初物でこれなら十分かなという気もする >>808
やっぱQSVかぁ。当方AMDなんで、エンコード用にIntelで1台組むか、期待のArc出るまで様子見か。
>>811
h264や265だと、4k動画をyoutubeにアップロードしたときにvp9に再エンコードかかって視聴できるまでにえらい時間かかるからですよ。
最初からvp9でアップすればすぐ4k視聴できるみたいなんで。 av1anがlibvp9にも対応してなかったっけ
どの程度早くなるか（そもそもはやくなるのか）は知らないけど 4/25付のffmpegバイナリも、
SVT-AV1 Encoder Lib v1.0.0
になったわ。 h.264を265にソフトエンコで圧縮してるけどav1のハードエンコで264比70％程度なら電気代考えたらまあまあ悪くないな
夏までに間に合ってほしいが An open-source VVC encoder based on Kvazaar
https://github.com/ultravideo/uvg266 Kvazaarのhevcエンコーダーは
crf未実装でtsエンコでは使い物にならなかったけど
VVCはどう進化するんだろうな 先ほど、やっと時間が出来たので2.2.8を検証しました
設定ファイル3.0.16→2.2.8をするとクラッシュレポートが起ち上がるもののUI関連のリセットのみで余裕の映像表示
しかしそこから2.2.8→3.0.17.4へ流用すると駄目でした
必死こいてレ点の増減を試しましたが、大半は自動化で、自動指定を旧項目に差し戻しても変わらず
各種項目に新設された若干存在するレ点済み項目をオフにしたりしても駄目
そしてコーデック周りは別物が大幅に追加され、そのわりに旧版を引き継いでいる部分は設定コピーなので値も同一
横には広がっているけど物そのものの入れ替えは無さそうな感触です ・・・もう、Hi444pは諦めろということですな、きっとユーザーがテコ入れ出来ない部分で淘汰されたのでしょう
神はおりませんでしたorz
不具合てんこ盛りな記憶だったはずの2.2.8は軽く＆短時間なら余裕で動作確認出来ましたので、いっそのことVLCのみ4年前？の2.2.8環境に置き換えるのも有りかな？と錯覚
いやいやいや少数の史料のために4年前仕様の混入は歪みが生じるだろう、と自問自答や葛藤の連続です
プラグインやら、追加要素が多分に見られる設定なので、そういう要素で構わないからHi444再生の余地を残してほしかった
ウルトラがっかりですわー まぁここでごねても開発者には伝わらないことだけはわかる
VLCのフォーラムとか見て回ったら解決法とかあるかもね
切り捨てられたのか後回しになったのかわかるだけでも今後の対応が決まるというもの ffmpegでエンコできないならVLCだけの問題ではないかもしれない（ffmpegのデコーダはVLCで使われてる）し
ffmpegでエンコ試すなりffplayで再生試すなりしてみれば？
>>803みたいな事言ってしまうような、OSSに無理解なオツムだと難しいかもしれないが
ところでMPC-BEロシア製だから怪しいって根拠
ソースコードのどこが怪しいか早く示してほしいんだけど？ FFmepgでエンコできないファイルって見たことない 壊れたファイルの話を持ち出してどうする・・・
まぁエンコード界隈ではAviutlでDivXやXvidの規格外＆音ズレファイル量産していた時代があるから
正常ファイルで読めないことがあってもおかしくはないが >>771の件も多分大昔のx264が規格外のファイルを出力してて再生側もそれに合わせてたけどどこかのタイミングで修正して古いファイルは再生出来なくなっちゃったんだろうな frapsという主にゲームのキャプチャで使われていたコーデックで
一部のゲームの録画だけffmpegじゃ上手くエンコできなかったことはある Ut Videoの新しい圧縮モード（fsemedian）とかffmpegじゃまだ読めない（エンコできない）と思うよ 2.2.8では何ら問題なく再生されるものの、3以降では史料解説用の第二音声・記録読み上げが適用され、映像はボヤけて黄緑やピンクなどの色の乱画像となるんですよね・・・
今思えば同じ設定なのに収録したオーディオが反転されて再生されることも理解し難い話ですわ
そのくせオーディオ品質は一切問題なく、第一も第二も変更可能で、双方ともに乱画像なまま
ブロックノイズを拡大した感じですな
せめて破損mp4なら音もビープ音になったりすれば諦められるんですけど・・・2.2.8じゃ余裕というのが悔しい・・・orz まぁこっちでは検証のしようもないからわからん！
頑張ってくれ！ エンコしてみればって言ってんのに無視するし解決する気もなさそう
愚痴りたければよそでやってろ、邪魔 r "
・・・・・！！！！！ ＼ ＿
r-''ニl::::/,ﾆ二 ｰｰ-- __
.,／: :// o l !/ /o ｌ.}: : : : : : :｀:ヽ 、
／:,.-ｰl { ﾞ-"ﾉﾉl ｌ. ﾞ ‐ﾞﾉﾉ,,,_: : : : : : : : : :ヽ、
ゝ､,,ヽ /;;;;;;;;;;ﾘﾞ‐'ｰ＝" ＿゛ =､: : : : : : : :ヽ、
/ ＿________｀ﾞ ｀'-- ヾ_____--⌒ `-: : : : : : : :
...-''"│ ∧ .ヽ. ＿_______ / ____ ---‐‐‐ｰｰ ＼: : : : :
! / .ヽ ﾞ,ゝ､ / ____＿___rｰ''"￣''ｰ､ `､: : :
.ｌ.／ V ｀'''ｰ-、__/__r-‐''"゛ ￣￣ ＼ ﾞl: : :
ｌ .,.. -､、 _ ‐''''''''-、 ｌ !: :
｜ ／ .| .! ｀'､ | l: : ｌ | .ｌ,,ﾉ ｜ ! !: :
/ 'ﾞ‐'''''ヽ、 .,,,.. -''''''''^^'''-、/ l !: :
r―- ..__ｌ＿__ ｀´ ｌ / /: :
＼ ｀ﾞ^''''''―- ..___＿＿＿/_／ /: : : エンコーダーはパラメータ細かく設定したくなるけど
出力が規格外もしくは再生側が規格外になったりするから
シンプルな方がいいのかもしれない・・・ >>838
変なAA貼ってないでFFmpegでエンコードしてみなよ それだけのために全部エンコードやりなおすなんて面倒だし馬鹿みたいじゃん 適当にバッチファイル作ってそこにD&Dすればいいんじゃない？
もっといい方法あるだろうけど ↑にも書かれてるけど、その問題のファイルどこかにUPしてみればいいんじゃね？
物好きなやつが解析してくれるんじゃないか？
別に愚痴るのはいいけど堂々巡りするのはさすがに見えるに堪えない。
前に進んだらどうかね？ Hi444pのなんてローカルで適当に作ればいいだけじゃ 同じやつなのかわからんが普通に再生できるんだが？
（High 4:4:4 Predictive@L3←因みに作り方は簡単でBandicamでキャプれば作れるよ。）
いやだから問題のファイルどこかに上げるほうが早くねーか？
何かあれか見られたらまずいものなのか？ 何度エンコードしても、動画の時間が1秒になっちゃう。
のだが、
エンコードに時間指定のコマンドなんかありましたっけ？
おしえてー >>849
なんのソフト使ってるかくらい書かないと何もわからない >>850
ソフトはVVCSoftware_VTMです。
>>431
のかたと同様に「./EncoderAppStatic -i aspen_1920x1080.yuv -c ../cfg/encoder_randomaccess_vtm.cfg -fr 29.97 -f 32 -wdt 1920 -hgt 1080 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 -b ./aspen.bin」
のコマンドを実行しました。
変換前のファイルは17秒なのですが、変換すると最初の1秒のみしか、保存されていませんでした。
動画全体をエンコードする方法はありますか？ >>852
もしかして、フレームレートの指定が間違っていると指定したフレーム数しか変換されない? >>852
-f 32が指定されてるから32フレームしかエンコードされてない
全フレームエンコードしたいなら0を指定するってマニュアルに書いてある >>848
「ハードウェアデコードしようとして失敗」「HWデコーダーがpredictiveとやらに対応してない」
その事象について散々調べましたが未熟な自分には解決の兆しさえ見えず
"VLC 3.0 activates hardware decoding by default, to get 4K and 8K playback"
という公式見解に対して、具体的な処置、設定変更例など、ありましたらアドバイスいただけませんか？
該当する項目を直訳すると「初期設定でハードウェアデコードを有効にしている」としか言っておらず、設定にもその項目があるものの単なるレ点ON/OFFのみで、
そこから派生するであろう問題がmp4再生の可否に繋がるのか自身には理解しかねます
ソフトで処理しているものをハードでやります！って理屈ですし、手段の違いですよね？これ
スイッチのON/OFF切り替えの際に何らかの内部的不具合を招く、というのであればユーザー側には手の施しようがありません
逆に、コーデックなどの素材不足による不具合やソフト処理とハード処理の切り替えに起因するものであれば、そこを足したり直すだけで問題ないはず
この解釈は間違っているのでしょうか >>855
ハードウェアデコードは固定機能のハードウェアでデコードしてるから
一般的な設定の動画しか対応してなくて
多少変わった設定でエンコードされたファイルは再生できないことが多いんだよ
とりあえず詳細設定のハードウェアデコーディングを無効にして
再生できるか試してから結果を報告してよ
https://i.imgur.com/54foPdK.png ご指摘ありがとうございます
やはり内容として、私の理解に不足はなかった様子
それらは3.0発足時、このスレでハードウェアという文言が出る都度、さらに855を投稿する時点でも試行しており、1mmも改善傾向へ移っておりません
過去、私の投稿で幾度となくそれらについて述べたことがあった気もします
レ点のON/OFF以外に何かしら設定すべき項目などがあるのかと期待しましたが、初期の段階に揺り戻った指摘内容ですね
それしかユーザー側には採れるものがない、という事実の表れやもしれません
2.2.8では再生できるのに・・・悔しいですなあ・・・ そろそろスパッとあきらめてもいい潮時かと
振られた女にしがみついても未来はない 諦めが悪いのがこじらせオタクの良いところでもあり悪いところでもある >>857
>>856
それとFFmpegでのエンコードも試してね❤ AV1のエンコードが遅すぎて困った。
PCを買い換えだけで解決するのだろうか？
使用環境は、i7-4770K 3.50GHz、メモリ 32GB、SSD
使用ソフトは、ffmpeg（SVT-AV1 Encoder Lib v1.0.0）。
これでエンコードspeed=0.19xくらい。(平均)
ffmpegで使っているオプションは
-movflags faststart
-vsync cfr
-c:v libsvtav1
-c:a copy
-bsf:a aac_adtstoasc
-crf 50
-preset 6
h265では寝ているときに50ファイルくらい同時エンコードできて、しかも翌朝には終わっていたんだけど、
AV1にしたら1エンコードでも丸1日かかる。(泣)
エンコード後の容量が少ないのでh265からAV1に切り替えたけど、そろそろツラくなってきた・・・ ストレージ増やしたほうがいいんじゃないですかね（適当） >>862
OSと作業用tmpドライブは、それぞれ別のSSDを割り当てていますが、
どちらも空き容量は数百GBは空いています。
過去ログを見ても、他の皆さんはもっと早いようなので、CPUが遅いのかなぁ・・・ >>861
ソースの解像度や動きの激しさにもよるけど、CPU蓮でpreset 6ならそんなモンでは
いくらSVT-AV1も前よりは速くなったとはいえ、preset 6以下常用したいなら5950Xクラス必要じゃない？ AV1試してみたけど寝る前残り8時間だったのが今見たら10時間になってて草
5600Xには荷が重すぎたか？ >>861 >>863
>CPUが遅いのかなぁ・・・
って昔からソフトエンコはCPU依存だよ。
エンコード初心者の人？？？因みにINTEL-CPUの左側の数字がそのまま世代になる
今12世代、貴方のCPUは4世代（1世代＝1年として約8年前のCPU）
今過渡期だからPC買うにしても自作PC買うにしても慎重に。
価格コムのCPU（ほしい又は高性能CPU）のクチコミ掲示板の欄見てるとわかる。
（今年の10月にはnvidiaの4000シリーズ、AMDの7000シリーズのグラボが出るって噂。
なんでもAV1のエンコードチップが乗るとか乗らないとか）
ちなみに
https://openbenchmarking.org/test/pts/svt-av1&eval=c0455879164e2a95a31a66ef59bd22ec92c118a9#metrics
ここを見ると現状12900Kが一番だけど環境整えるの大変そう（部屋にエアコン、水冷化、DDR5の品不足＆高騰） 今の相場なら下手にHWエンコード試みるより5950X積んどきゃいいと思う >>861
HDD買ってx265でいいじゃん
保存用なら瓦で問題無いし6TB 1万程度だからたかだか1本数百MBの削減の為にPC組み替えて今の高い電気代を追加で払い続けるは賢いとは思えん
1本200MBの削減なら30000本弱エンコしてやっと6TBだぞ tileを変えてみては？エラーが出るときは数を減らしてみて
-c:v libaom-av1 -crf 50 -cpu-used 6 -b:v 0 -aom-params tile-rows=2:tile-columns=2:row-mt=1
それかrealtimeモードにしてみるか
-c:v libaom-av1 -crf 50 -cpu-used 8 -usage realtime -b:v 0 -aom-params tile-rows=2:tile-columns=2:row-mt=1 >>870
そんなこと書いてると734と735が沸くぞ笑
という冗談はさておき、0.19倍という速度しか出なくて糞ほど時間かけて
完成されたファイルのSSIMの値ってどのくらいなん？気になるな。 我が家にある他のPCを見て回ったけど、i7とは言え、どれもコア4つのPCだった。
>>870の言う通り、h265に戻して、同時50～80エンコードでぶん回すのが無難かな・・・
余談だけど、>>864に従って、早朝から Windowsメモリ診断ツール回したけど、まだ54%なのでやめたｗ
違うアプリで再検査するわ。 ・CyberLink、動画再生ソフトの最新バージョン「PowerDVD 22」を発売
https://ascii.jp/elem/000/004/091/4091356/
UHD-BDの再生、どうなるんかね？ >CPU
>Ultra HD Blu-ray: Intel 第7世代から、Intel Software Guard Extensions（Intel SGX）技術を搭載した Intel 第10世代のCore iプロセッサまで。
https://jp.cyberlink.com/products/powerdvd-ultra/spec_ja_JP.html エッジ用プロセッサだからな
それだけ速度出るなら十分以上 すごいな、リアルタイムエンコーダ時の遅延が、たった0.2秒か。
（エンコ遅延というよりも、伝送に要する時間が遅延となっているような気がする） バッファ蓄積やデコード遅延の裏で気が付かないレベルだな
ゲームや動きの速い配信用途以外の個人用なら十分需要カバーできるが・・・ 低遅延が売りのソフトに組み込む検証っぽいからあれだけど
ハードは60fpsも対応してるっぽいし試してるとこ見たいね ffmpegも昨日、
SVT-AV1 Encoder Lib v1.1.0-10-g98aba736
になったね と思ったけど、気のせいだった。
それほど変わっていない。 VVCSoftware_VTMでエンコードしたのですが、
フレームレートの指定は「-fr」ですよね。
指定する数を変更しても結果の違いが全然ないので… >>887
ビットレートとフレームレートを勘違いしてました。
ビットレートを変更する場合は、エンコードするときに使用するファイルを変更しなければビットレートは変更できませんよね。
「/EncoderAppStatic -i aspen_1920x1080.yuv -c ../cfg/encoder_randomaccess_vtm.cfg (以下略)」
というコマンドでエンコードを実行しているのですが、「-c」はコンフィグレーションファイルを指定していると。。。
このコンフィグレーションファイルの中に以下の項目があったので、この値を変更すればビットレートを変更できる感じですかね？
「TargetBitrate : 1000000 # Rate control: target bitrate, in bps」 >>30 198 317 889
全部スレ違いなの徹底してんな >>891
-cfgファイルを直接いじらなくても-qオプションを追加して品質を指定したらビットレートは変えられる iPhone7以降で撮影した動画を全てH.265でエンコードさせるAppleもなかなか急進的だと思ったが
最近はGoogleがAppleみたいになってきている
オープンソースのはずのAndroid TVなのに、AV1デコーダーが載ってない製品にはAndroid TVを載せませんとか言い始めている
https://9to5google.com/2021/01/16/google-android-tv-av1-codec-requirement/
このまま行くと次は「AndroidスマホにAV1デコーダー必須」その次は「AndroidスマホにAV1エンコーダー必須」
最終的にはiPhoneみたいに「Androidスマホで撮影した動画は全てAV1でエンコードされる」とかになっていくのではないか
コーデック戦争って結局はAppleとGoogleの意地の張り合いなのか よくある話だよな最初はただで使わせておいて
信者が増えてきたら商売に変えるってのは
例えばこういうのとかspybotanti-beacon
よかったんだけどねぇ、調子に乗りやがって有料化したからな
ちなみに世界の武器商人と同じ手法
簡単にいうと反政府勢力にタダで武器を配っておいて
劣勢になった政府側に料金上乗せして武器を売りつけるってやつね >>896
よくある話ではあるけどこの場合は少しズレてる androidTVが乗るようなテレビはハイスペックになるだろうから要件高くても良いんじゃないかな
YouTubeアプリはしょぼいテレビでも動くだろう >>897
それを押し付ける理由がないから
サポートするコーデック数を（将来的に）削りたいんでしょ 削りたいのは帯域で、それ以外はおまけでしかないよ
日本の大手通信会社だって夜間の帯域圧迫して遅延までしてるから大歓迎だろうし
TVのMPEG2くらいだろ老害が居座って動けないのは >>900
Google側も通信費払ってるという観点が抜けている気がする Googleは海底ケーブル敷設に参加してるし帯域幅については自社でなんとかできるでしょ >>903
そんなことするより新しいコーデック作った方が楽じゃね？ >>902
今のyoutubeのav1はavcとビットレートに大した差はなくね? Googleのサーバーや回線は余裕だろうけど各国のプロバイダは年々増えていく帯域にヒイヒイ言ってるからな >>895 に付け加えて
GoogleはYouTubeもChromeも圧倒的シェアを持っていてインターネット上のメディアの方向性を決定することができる
（Chromeの対抗馬であるはずのEDGEはChromeと同じレンダリングエンジン共有してしまい、対抗馬として機能しなくなった）
今後5年くらいの間に「YouTubeでH.264配信終了」「ChromeでH.264再生不可」などの強行策を行う事が可能
10年くらいのスパンで見るとVP9さえ切り捨ててAV1やAV2に誘導することが可能
VVC陣営の希望としては、世界中のテレビ局が地デジの第二世代目に移行してくれる事
（ブラジルなんかではVVCを採用した次世代放送の計画が進んでいるらしい）
AppleがH.265の時のようにGoogleとガチンコで戦ってくれる事 AppleはAOMedia入ってるから戦うのはこれからもずっとSisvelだろうな
たとえVVCの普及がイマイチに終わってもAV1みたいに特許料を継続的にSisvel経由で受け取れるなら損はないのでは？ appleにとってそんな特許料ゴミみたいなもんじゃねぇかな 自由で高圧縮率で使いやすくてエンコーダも充実してるコーデックが普及すればそれでええねん。その点AV1は理想形。途中でライセンス改悪するよとかじゃない限りああいうのでええんや 昔BDに焼いた動画の整理とかしようとしていて、
iso(DB) ⇒ mp4（AV1）にしようとxmediarecordeで処理をしているんだが、途中で落ちて完走できず困っています。
※イベントビューアーでは「ffmpeg.dll」のエラーと出ていました。
ひとまず安定版過去バージョンとか、色々試してみたけど解決しなかったのでxmediarecordeはぶん投げるとして、
isoからAV1に変換可能なソフト（有料でもOK）でおすすめってありますか？
スレチかもですが、何かいいソフトあったら教えていただけると助かります。 staxripでいけると思うaom, rav1, svt, ffpg 4種類のAV1エンコーダーある 数年前にいきなりmp4にav1もopusも入れられるようになったんだよな
そんな簡単に追加できるのかと思ったわ このストリーミングが入ってますっていうだけのコンテナだしな
その共通概念がそれまではなかったから作られたわけで
aviやwmv全盛期は環境ごとに再生してみないと音ズレもろくに確認できなかったしな 初めてAV1（svtav1_1.1.0-13)でエンコードしたがx265_3.5+36より速くてワラタ（双方ともデフォルトの設定） >>921
俺らは画質と時間と容量(と互換性)のトレードオフで生きている、いいね。
これは例えばx264がultra fastがデフォ設定なら圧倒的に最強となるわけで、議論のためには少なくとも2つ以上の情報が無いと意味がない訳だ。 今のSvtAv1EncAppのデフォルトはpreset 10だから速度重視の設定といえるかな エンコード時間とファイルサイズとSSIMの兼ね合いならx265と同等以上のデータがいくつかあるな
主観画質の調整があまりされていないのと動作の安定性がまだイマイチなのがネックだが 暗部、グラデーション保持性能がまだx265に少し劣るといったところか、目視では
そこさえ安定すればもうx265なんていらんくなるわ 物理メディアに採用されない結局一般人には認知されないマイナーな逸般人用自己満コーデックで終わるんだ
Divxとかプレーヤーまで存在したのに普通の人からは何それで消え 一般人はコーデックなんて知らない。そんな一般人が知らんうちにネットでゴリゴリ相互にやり取りするコーデックになるならそれで十分大成功じゃないか。
死んだ物理メディアや縮小する一方のTV界隈の一方的なたれ流しデータの扱いにくい中身よりずっとマシだよ 年代問わず一般人はもう物理メディアなんて使ってないぞ 今じゃ物理メディアに採用されるかよりメジャーなブラウザがサポートしてるかでは 皆さんのアドバイスをもとに、h.265に戻る予定でした・・・が、
AV1を諦めきれず品質を落としてでも使い続けることにしました。
従来： 速度0.19x CRF46 preset 6 VMAFスコア 約90.26
今後： 速度4.10x CRF50 preset 13 VMAFスコア 約84.53
h.265は大量に同時エンコードできて便利でしたが、
これで様子を見て、これでもダメに感じたら今度こそh.265に戻ります。 実写とか500円ハゲみたいに肌の質感が消えるから速攻265に戻ったわ
ええ加減卒業したい H.265がデファクトスタンダードになってるのはUHDブルーレイで使われてるのも大きいんじゃないか >>929
とは言え、映像業界のプロは最終的にH.265でBS放送されたりUHDブルーレイになったりすることを想定して撮影、編集して映像作るわけだろ
プロ向けの機材やソフトも真っ先にH.265に対応する
色んな知識やノウハウや習慣がH.265をベースにして積み上げられる
セミプロはプロ向けの機材やソフトを手に入れプロの知識やノウハウや習慣の真似をしようとするし
いずれエンコしてるだけのマニア層も似たような機材やソフトを使い始めセミプロが発信してる情報を参考にする
なんというか、ピラミッドの上層を先に掴んでしまうと普及しやすいみたいな状況がある
この先、H.266での物理メディアや放送があるのかないのかは非常に大きい差が生まれるだろう 試してみたがsvtav1はプリセット5、品質35以下はディテール省略されて老人俳優が若返った様に見えたりする
映像に霧がかかってるようにも見える。同じ設定でも解像度でかなり品質にばらつきある >>934
それでも放送局以外の最終出力はAV1になるでしょ。なぜなら視聴者はネットで見るから。
UHDBDの体たらくからして、次の物理ディスクは限りなくマニア向け市場だし あほなバラマキエコポイントで日本のテレビ産業崩壊させるくらい移行が加速されたけど
お役所は10年あれば古い機器の買い替えが進むだろうっていうのが主流かな
このまま今のVVCテストがうまくいったとしても、4K資産と併用するのか全部統合するのかまだ議論の余地はあるし
ってことで、きょう発表されても今のシステムは10年は続く(打切りはあるかもしれないけど)
VVCも４Kと同じくBカスのように破られるまでは、末端ユーザーは放送方式なんて気にするところではないな
さらにARIBのように日本独自のオリジナルだ！って何かを付けたくてうずうずしている犬HKがいるわけだし すみません。
-preset13は、上げ過ぎだったようです。
早い動きだと、対象物の周りにブロックノイズが現れました。
また、テロップなどの文字色が、ノイズまみれとなる場合がありました。
-preset値を下げて、試行錯誤してみます。
（初期値の10で落ち着きそうな予感） ffmpeg組み込みのsvtav1のVer1.1.0って何か不具合抱えてるのかな？
Svt[error]: Mode decision candidate count exceededSvt[error]:
と出るんだけど。エンコ後のファイル見ると普通に再生できるけど
なんかモヤる。 因みに使用コマンドは
ffmpeg -i input.mp4 -vcodec libsvtav1 -vf bwdif=mode=0 -qp 43 -preset 8 -acodec libfdk_aac out.mkv
です。 何度もすみません。エンコード時間が７分超えた辺りで毎回上記の表示が出ます。 >>941
そうですかそれならしょうがないですね
どうもありがとうございました！ IntelのハードウェアエンコーダーでAV1エンコードした場合の品質が気になる SVTAV1とその他のAV1でプリセット揃えても奇麗さがずいぶん違う
速度が違うから仕方ないと思うが >>948を見ると実験機としてはリアルタイムVVCデコーダーがあるみたいだね
ホームゲートウェイを検討しているのも面白い 今までの2kだけ見たい人でも何らかの変換装置は必要そうだ TVerの同時配信問題もひと段落したし、地デジのVVCテスト遅れを隠せるネタがなくなってきたな ベースはPCだろうけどFPGAとか使ってるかもしれんし写真だけじゃ何とも 光学ドライブ何使っているか気になるな
フレンドリードライブだったりしてな
NHKはしれっとPT2使っていた事もあるしな だいぶ前にシャープが8KのリアルタイムVVCデコードソフトウェア出してるでしょ ワンセグとかマルチチャンネルとか諦めたか。アホだな。 >>952
MPEG-H 3D Audioはhuttle製のパソコンだな
XH410GかXH4100GかXH310Rのどちらかだな
汎用性の高いPCを使うって事はまさに試験機って感じ
https://shuttle-japan.jp/wp-content/uploads/2021/01/slick_xh410g_05.jpg
製品化したら専用チップ使った小型機になるんだろうなあ
VVCデコーダーとホームゲートウェイと一緒に総合しそう
最新グラボのリーク見てもVVCデコーダーはまだ無いっぽいな デコードくらい既存のPCでできなきゃ話にならんよね VVCってもうPCで使われることは無いんじゃないかな 例のx265チームはAV1スルーしてVVC開発しているぞ
既に公開しているが今は重すぎて実用的では無かったはず
ZEN5が出る頃には使える様になっていると良いな x266はまだまだやること多いから完成には時間掛かるだろうな
高画質や高速化の追求と大量のバグ潰し x265もやりっぱなし感があるから
x266にはあんまり期待してない 永遠に完成しない塔みたいなものだからな、x26シリーズは。 x265は3.4で終わったと思ってる、完成という意味で x265は昔に比べてすげえ速くなったぞ
x266もいつかは使える様になる x265、パラメータはいっぱいあるけど
一番速くなりそうなやつで十分見れるし
一旦完成って感じだ その点VP9はエンコーダが駄目だった。AV1は克服してて偉い パラメーターをオプションとしていかに露出させるかってところのノウハウが無かったんだろうな
>>964
x264は別格すぎる
x265は開発者レベルでは不評ではあるみたいだけど
エンコーダーとしては確かに高い水準ではある Financial Analyst DayでAMDのロードマップが公開されたな
ZEN5ではアーキテクチャが一新されて別物になるらしい
じゃあZENって名前変えねえの？とは思うけど AV1はX265より暗部に弱いね…同じCRFでサイズに対して画質は良いと思うんだけど
X264の時は品質そのままにAQS1 2だか暗部対策っぽい数値を0.50くらい上げればよかったけど 当初はx265もx264より暗部弱かったな、途中から逆転したけど 半分の容量で同等の画質 とか謳ってた頃は数値上は良くても実際は微妙だったりしたよな
AV1もそんな感じなんだろう
一般に広まることができて無茶な性能アピールをしなくなった頃からまともになっていくんだろうさ インターレース保持エンコ出来るようにしてくれ
x264から離れられない AV1でbob化した方がサイズ小さくなるな
x264より明らかにきれい。ただ暗所、ボヤケ、デフォでデノイズかかる仕様だから細かなエッジや質感とか消え去る。
高画質保存用はx265がいい。わりとどうでもよい動画は全てAV1にすると思う。 AV1はブラウザで再生しやすいのがいいね
再生だけならすでにHEVCより手軽になってる ちゃんとインターレースに配慮したコーデックってH.264が最後じゃないのかな
HEVCは追加の規格で一応あるにはあるが、H.264でいうところのPAFF的なやり方にメタデータをくっつけたような感じで、
まともに対応しているデコーダも見たことがない 高画質はh265でかなり完成されてる感ある
av1はやっぱりyoutubeのGoogleの意向か低ビットレートでの効率を優先してる感じ >978
SvtAv1EncApp なら
--film-grain-denoise 0
にしてみては SVT-AV1はデフォだと--film-grainオフだから当然--film-grain-denoiseは無効だよ Apply denoising when film grain is ON, default is 1
たしかにfilm-grainオフなら--film-grain-denoise 0になりそう >>976
次世代地デジも30000/1001フレームのインタレとかいやだろ卒業しようぜ(笑) インターレースは分かるけどYUV420は絶対無くならないだろう
解像度が高くなれば高くなるほど422と420の違いが分からなくなってくるし 中途半端なfps(24000/1001とか30000/1001とか60000/1001)も廃止にしてくれ
できないのは互換性の問題？ 720p@4:4:4と1080p@4:2:0が1割ぐらいしかデータ量変わらないしそりゃ一般人にスペックで売るなら4:2:0だよなって
しかし地デジとかFHDと言いながら4:2:0でsar4:3でインターレースとかいう地獄みたいな規格だったよな。 なんで地デジがまるで過去存在みたいな感じになってんだよw
有力なエンコ元ソースとして今現在進行形でインターレースで大量に量産されてるんですけど 地デジの技術検討しはじめたのが1996年で決まったのが1999年だぞ
その当時のこと考えればインターレースも妥当でしょ DVDだってインタレ収録だったしね
プログレ収録だってできるのにさ インターレースも30fpsの映像なら簡単にプログレッシブ化出来るわけだし、あの当時は妥当な選択だったのだろう
けど今の地デジはそれに60fpsや24fpsの映像を載せててカオスな状況だけど、テレビ側の優秀なIP変換のお陰で誰も違和感は感じてないだろう 24映像のDVDとかテレシネ化して逆テレシネ プルダウンフラグ入れてるよな
狂気としか思えないわ 次の地デジはスペック盛り盛りだといいなあ
4:4:4とか4k60pとか >>997
久しぶりに読んだけど
こんな唐突に終わってたっけ? このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 285日 8時間 7分 57秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
