【AV1】次世代ビデオコーデック総合スレ9【VVC】
H.264/AVC、H.265/HEVC、VP9の後の様々なビデオコーデック全般について語るスレです。
■対象となる主なビデオコーデック
・AV1 (AOMedia Video 1)
・H.266/VVC (Versatile Video Coding)
※ DTV板はデフォルト設定が強制ワッチョイなので、ワッチョイを付ける時は extend コマンドの記述は不要です
（逆に、ワッチョイを付けない時は !extend::checked:: の記述が必要です）
※ DTV板は即死判定があり、即死を回避するためには、スレを立ててから1時間以内に最低12コメントが必要です
（即死回避以降は、30日間書き込みがないと強制的にdat落ちします）
次スレは >>980 が宣言してから立ててください。
■前スレ
【AV1】次世代ビデオコーデック総合スレ Part8【VVC】
https://mevius.5ch.net/test/read.cgi/avi/1655278046/ ■各ビデオコーデックの概要や状況（2023年8月時点）
●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が採用されるなど、ブラウザーの対応も進みつつある。 ●H.266/VVC (Versatile Video Coding)
H.265/HEVCの後継規格。2020年10月の標準化を目指して
JVET(Joint Video Experts Team)で検討が進められている。
また、H.265/HEVCのようなライセンス問題を繰り返さないため、
MC-IF(Media Coding Industry Forum)という業界団体が立ち上がっている。
https://www.mc-if.org/
次世代4K地デジに採用された。 ■各社GPUでのハードウェアエンコード/デコード対応状況については下記関連スレを参照。
【QSV/NVENC/VCE】ハードウェアエンコーダーについて語るスレ10
https://mevius.5ch.net/test/read.cgi/avi/1681288720/
テンプレはここまで 保守 (即死回避) 完了
以降は保守のための書き込みは不要 >>14
いやーほならね自分で保守しろって話でしょ？ >>15
あんたが主じゃねーのか
俺は誰も書いてないなら落ちても一向に構わんしどうでもいいが保守したい奴が複数いるなら尚更だろ？ 前スレが埋まってないときにネタ振りとか意味分からんな iPhone 15 Pro（MAX含む）に搭載のA17 ProチップにはAV1デコーダー搭載と発表されていたな そりゃHWデコードくらい出来なきゃ、これからまともにYoutubeすら見れねーじゃん やっとか
これでほとんどの新規に売られるスマホがAV1対応になったな 3nmなのにCPU10%、GPUに至ってはコア数を20%増やして性能も20%アップとか、
Appleマジで人材居なくなってそうだな 無印の15は未対応の模様…
話変わるけど、ABEMAやTVerで使ってるコーデックがいまだにAVC&AACという化石コンビのままな件、そろそろ進化してほしい… >>25
YouTube以外の配信は当分H.264だよ
未だにDVD作品が新発売されるのと同じ
ストリーミングなんて見れりゃいいってね >>24
熱とバッテリーからは逃れられん。
カメラみたいに動画も専用エンコデコード組んだほうがいろいろ節約できる時代がまたきた。 VVCの利用環境が広がらないからAppleも痺れ切らしてAV1の利用環境を整備し始めたのか、これに加えてAV1エンコーダーも積んできたらいよいよAV1が次のデファクトスタンダードになるかもね
ただし、くれぐれもエンコーダーの品質は手を抜かないでもらいたい VVCは4K8Kを想定してるからPCモニターが4Kデフォな未来が来るまで普及しない PCはともかくTVはもう4Kがデフォの時代にはなってる 地デジよりアマゾンビデオやNetflix用にTVを使っている人も多い時代 >>25
圧縮率がよくなったら、それだけビットレート下がって画質上がらないやつ
そして有料ユーザーのみ高ビットレート解禁ってパターン 最近、yt-dlpで字幕付き動画を落とすときに、うp主側にてあらかじめ字幕を用意してうpしてくれている場合に限り、ダウンロードした動画の字幕の選択肢にどの言語なのかの表示がされなくなっている
MKV Toolnixにて、muxされている字幕を削って、代わりに字幕を新たにmuxしなおすと正しく選択肢の表示がなされるのだが、これはyt-dlpとFFmpegのどちらかに不具合があるのだろうか？ そもそもAV1とか推してる動機がYouTubeやNetflixが払う回線コストがバカにならないから
少しでもビットレート落としたいってことだからサーバー側の事業者のためのもの
AV1にエンコードするコストよりもAV1でデータ送信するコストの方が低くなって初めて意味がある
YouTubeやNetflix以外の日本国内のサービスがそうではないならこれからもH.264だろうな 視聴者が画質より解像度重視だから、h264の低画質だろうが解像度がfhd以上なら満足しちゃうんだよね ネトフリ以外の動画ストリーミングはだいたい外部のCDN使ってるからAV1はCDNプロバイダの対応次第なところあるけど
主要なCDNでAOMメンバーになってるところなさそうだし温度感が分からん >>38
5M必要なところが3Mになればでかいよ。 CDNにコーデックは関係ないだろ
プロトコルの領域 >>41
単にファイル置くだけならそうなんだけど
DRMとかHLSの認証とかもやる包括的な動画配信向けCDNサービス使うとコーデック自由にできないところ多い ダウンロード販売の実写AVが4GBとか無駄にでかいので綺麗で圧縮率の高いAV1にエンコードしているワイ（AVだけに） 自分も導入しようか思案中でARC買ったけどAV1のブラーと映像均一化がきつ過ぎて質感消えるよな。SVT-AV1は均一化無効化出来るオプションで使い物になるけど遅い。 >>45 AV1とかVVCがあまりにも遅くて使い物にならないからLCEVC(ソフトウェアデコードは軽い)で縮小して処理を減らそう、って算段なのにyoutubeとかが採用しないのはアレだな >>45
質感消える時点で、まだ使い物になるCODECじゃない AV1はH.265と同等レベルなのに圧縮に期待し過ぎなんだよ 確かに画質だけなら同等レベルだな
AV1の方が容量大幅に削減できるってだけでさ >>49
ディテール殺してサイズ減らしてんじゃ意味が無い >>50
エンコードってそういうもんでしょ
可逆圧縮じゃないんだから
AV1は同程度の画質でより容量減らせるってだけでさ 今のとこAV1のＨＷエンコードってグレイン合成使えないんだっけ？
自分は実写の場合は使って質感フォローしてやることが多いけど そうか？Redditとか見ててもCRF（aomencならcq-level)上げると同時に
グレイン合成の数値も上げて欠落している粒状感フォローしてるような設定の人
ちょくちょく見かけるが グレイン付加と質感維持は違う前提で
どう誤魔化せるか？でしかない
最後人間の見た目評価基準で「あ、ディテールつぶれてる」と印象持たれたらアウト
まあ普通にビットレート低過ぎるだけ グレイ合成使うと主観的な品質を保持しながらビットレート削減できるというレポートがあるんよ
Netflix は、フィルム グレイン合成を使用してビットレートを 30% 節約できると想定しています
https://www.reddit.com/r/AV1/comments/zsi0km/netflix_assumes_30_bitrate_saving_using_film/
https://waveletbeam.com/index.php/news/48-netflix-film-grain-synthesis
※動画
個人的な経験では実写のドラマや映画に限れば主観品質を保持しながら20%ぐらいは削減できるんかな、という印象。
ただしエンコードは遅くなる
(jxl由来のphoton-noiseは軽いけどSVT-AV１では使えない。aomencやrav1eなら使える）
ただしあくまで主観品質なのでVMAFやssimulacra2といった品質評価メトリックスのスコアは低下するというのは間違いない 実写は以下に視聴距離を保つかが鍵
特にNetflixやアマプラなんかはモニターから1.5～3m離れて見るのを想定してるはず
だからこそ、グレインが効果ある ゲームみたいなのだとAV1でも全然縮まなくて画質悪いね
動きが激しすぎてイントラブロックだらけになるのかねえ
グレイン付加するのも無理だし大変だ ゲームコンテンツだとSVT-AV1の場合、--scm 1を明示的に指定した方がクオリティが上がる
って少し前にDiscordで話題になっていた気がする（ただしちょっとエンコが遅くなる）
自分はゲームやらないんで確認できないけどscm 2（デフォルト)はゴミだF〇ｃｋだとめっちゃ叩かれてた モニターからの距離なんてモニターのサイズによるものでしょ
1.5m〜3mてのは40インチ以上だろう >>60
TVモニターならサイズに関わらずそんなもんだろ？
PCモニターなら24～27インチでも90cm以上は離れるのが理想。
ちなみにNVIDIAのRTX-VSRも3mを推奨。 SVT-AV1の場合はオプション指定して--film-grain 1 --film-grain-denoise 0やればいいよ
これで質感は消えない、まあ遅くなるけどね
でもh265より総じて圧縮できる グラボ持ちの人はこのオプション出来るか試してほしい いまさら2年以上も前の資料引っ張り出してどうした？ 今月リリースされるsafari 17で正式にjpeg XLサポート
firefoxは実装はされてるけどまだデフォルト有効化されないな https://webkit.org/blog/14445/webkit-features-in-safari-17-0/
> Safari 17.0 adds support for AV1 video on devices with hardware decoding support, like iPhone 15 Pro and iPhone 15 Pro Max. キンキンするっダメじゃん
シャープネスの多重掛けでギンギンになる10年前の超解像度レベル vaapi 動かないどうやればいいんだろ？
Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scale_0'
[vf#0:0 @ 0000027b016d4480] Error reinitializing filters!
Failed to inject frame into filter network: Function not implemented
Error while filtering: Function not implemented
[out#0/mp4 @ 0000027b016cb040] Nothing was written into output file, because at least one of its streams received no packets. ffmpeg -i inputfile -vcodec av1_vaapi -acodec libfdk_aac output.mp4
で上記のエラー出る。記述の仕方が違うのかな？わかる人いませんか？ >>73
見たけどよくわからないや一番上のコマンド打ったところエラー出てダメだった。
今までのようなコーデックの使い方ではダメなんだとは思うんだけど。
/dev/dri/renderD128 これはいったいどこから出てきたんだろ？ モザイク外し？ 汚い画像をキレイな画像に修復手法、中国チームが発表 Stable Diffusionを利用
https://www.itmedia.co.jp/news/articles/2309/27/news046.html
MPEG-2で特に目につきやすい輪郭周りのノイズ対策にも使えそうだな DivXとかでエンコードしたブロックまみれの動画が再利用できるのか？ キヤノン、超高感度カメラのノイズをAIで低減する「映像鮮明化ソフトウエア Version 1.0」
https://dc.watch.impress.co.jp/docs/news/1536033.html
映画の世界が現実に ディープラーニングっでって書いてるけど
なんか余計なもの生成されそうでちょっと怖い
そんなことはなかろうけども AIって付いてると全部同じ技術だと思ってしまう人がいるんだよね >>84
ディープラーニングは正誤の判定しか出来ないから、"ノイズか否か"を正誤とした時は変なものは付け足さないよ
"人が見て自然な画像か否か"を正誤の指標にすれば変なものを付け足すけど
多分人力で数式作ってノイズ除去してた部分を、ディープラーニングでフィルタのパラメータを生成したって話だと思う AI超解像で古いビデオがキレイに復元できる「VLC media player 3.0.19」が公開、ゼロデイ脆弱性の修正も
AV1ビデオのハードウェアデコーディングも有効化
https://forest.watch.impress.co.jp/docs/news/1538728.html >>89
VLCもAI超解像対応か
アツいな
別件だが、YouTubeのコーデックについて、YouTubeプレミアム導入後の1080p解像度の場合のみ、画質的には
VP9 Premium用＞＞AV1＞VP9（通常用）
という状態で運用されているようだな
1440pや4K、8KではAV1が優位なのはこれまで通りなのだが、1080pのみダウンロード時は気をつけないとな
過去にアップロード済みの動画で最大1080pのコンテンツも少しづつVP9 Premium用が用意されていっているので、過去にダウンロード済みの動画も再チェックが必要になりそうだ >>89
VLCもAI超解像対応か
アツいな
別件だが、YouTubeのコーデックについて、YouTubeプレミアム導入後の1080p解像度の場合のみ、画質的には
VP9 Premium用＞＞AV1＞VP9（通常用）
という状態で運用されているようだな
1440pや4K、8KではAV1が優位なのはこれまで通りなのだが、1080pのみダウンロード時は気をつけないとな
過去にアップロード済みの動画で最大1080pのコンテンツも少しづつVP9 Premium用が用意されていっているので、過去にダウンロード済みの動画も再チェックが必要になりそうだ NVIDIAのAI超解像化機能「Video Super Resolution」、RTX 20シリーズでも利用可能に
https://news.mynavi.jp/article/20231018-2795558/ VVCにおける解像度の動的変更技術
https://www.nhk.or.jp/strl/publica/giken_dayori/223/4.html
VVCでは、解像度を下げて符号化する処理を常時ではなく一時的に適用することができる“動的解像度変更”（ARC：Adaptive Resolution Change）と呼ばれる新しい技術が導入されました。
実際にARCを行うためには、映像中の被写体の絵柄の細かさや動きの速さに応じて、適切な解像度を決定する必要があります。
しかし、VVCの規格＊2では解像度の決定手法は定められていません。
そこで当所では、解像度の縮小度合いを変えた複数の映像を同時に符号化して画質を比較することで、最適な解像度を決定する手法を開発しました（図1）。
例えば4K映像を符号化する場合、4Kだけでなく3K、2Kなどの複数の解像度に縮小した映像も並列に符号化処理を行います。
それぞれの解像度の符号化結果を比較し、より画質がよくなる解像度を時間に応じて選択することで、解像度を決定します。
この手法により、そのままの解像度で符号化する場合よりも、映像品質を向上することができました（図2）。
動的解像度変更（ARC）における解像度決定手法の例
https://i.imgur.com/UvrtbVi.jpg
ARCによる映像品質向上の例
https://i.imgur.com/69VE7rA.jpg 帯域に上限がある場合、縮小したものを引き伸ばしたほうが画質がいい可能性があるってこと？ 解像度を下げる事で、込み入ってない部分の画質が少し犠牲になって、その分込み入った所に振り向けられるからという理屈だろうね
その代わり全体的にボヤけた感じになりそうだが… デコード側も対応する必要あるから無理なんでね？
解像度も一定じゃなくてコンテナ化みたいなのして、「ここは縮小絵を拡大しろ」みたいな中身のフォーマットになるの？ 帯域不足すると低改造度化するのは、ニコニコがやってない？ AV1のSuper resolution modeは帯域減らしたいYoutube辺りで使われるかと思ったけど今のところ利用されてはいなさそうだ >>101
主に更新されているのはブランチのEndless_Mergingやね
gitで引っ張ってくるときには
git clone https://github.com/Clybius/aom-av1-lavish -b Endless_Merging
と指定 すまん見間違えてた
Endless_Mergingより新しいブランチかそれ >>95
言い方に語弊があるかも。
高解像度の方が画質は良いに決まっている。
しかし、シーンによってはゲームのDLSSと同じく解像度を犠牲にしてもデコード時にアップスケールした方がサイズも縮むし遜色無いって認識だと思う。 ビットレート上限のある放送で4Kのまま符号化すると動きの多い部分にビットレート不足でノイズが出る
ならノイズがのらない低解像度まで落として送り出し受像側で高解像化させた方が結果は良くなる
>>95の言い方で全く語弊はないと思うぞ あぁ、間違ったわ
解像度＝品質だわ
ま、いいわ、ごめんな、俺がめんどくさい奴だったわ 小さい玉が高速で移動するスポーツとか動きが激しいアクション映画みたいな映像だけ解像度減らしたりすると良いのかもね MUSE-Tみたいに動きが少ないと空間周波数帯域が上がる感じなの？
エンコーダーに突っ込む解像度を可変にするってことは量子化テーブルというか時間軸に対してAQするようなイメージだろうか 笠原一輝のユビキタス情報局
ライバル完封のSnapdragon X Elite、ベンチマークでその実力が明らかに
https://pc.watch.impress.co.jp/docs/column/ubiq/1543148.html
Windows on ARMにネイティブ対応したGUI操作可能なエンコーダーがあれば、並のintel CPUを超える速度でソフトウェアエンコードできるようになるのだろうか？
macもM3チップ発表したし、そろそろエンコード環境もARMネイティブになっていかないものかな？ ベンチ上はCorei9のなんちゃらを超えた！とか言いつつ
エンコーダー系で実際それぐらい速かった例をあまり見ないのはなんでだろうな
x86への最適化が鬼のように進んでるってことなのかね
svt-av1とかはARMのアセンブリが頻繁に追加されてるからいよいよエンコードもARMの時代が来ちゃう…？ キャッシュでおさまるピーク性能が強く出るベンチ選んでるだけなんじゃないだろうか ソフトエンコはx86の拡張命令使いまくるからarmでやると激重になる場合がある
M2でsvt-av1やると10年前のi3より遅いらしいし M2とかApple SoCの場合は素直に内蔵エンコーダ使うことが前提だろうし
自由度は低いだろうなぁ、と思う NetflixはHEVCのライセンスを払っていなかったということ？
それとも払っているのに訴状されたのだろうか VVCも似たような感じになるのかな
もうネット配信はオープンソースのAV1系しかないね ちょろまかしてたとか払ってないんだろな。
AV1は高画質適正ないけどね。まあネット配信は4KでもFHDブルーレイよりだいぶ汚いし
気にしないライト層が4Kで映像見れたらAV1でいいとおもう HEVC使用者はBroadcom始めパテントプール未所属の野良企業とも個別交渉しろって話だろ？
くそめんどくせぇな HEVCの特許管理団体がすべての特許を管理しきれていなかったということか？ 特許持ってる会社なら後からクロスライセンス提示して回避できるけど
ネトフリはなんで勝ち目なさそうなのに戦ってたんだろ パテントプール入ってないなら必須特許じゃないだろうしライセンス結ぶ必要なんかないだろ NetflixでもAV1はまだ実用段階じゃないのか 顧客のデバイスの都合もあるからAV1以外にH.264や265もサポートしてるんじゃないの 4K時代の動画コーデック「HEVC」「AV1」「VVC」を比較して評価するとこうなる、最も将来に期待できるコーデックはどれか？
https://gigazine.net/news/20230418-codec-hevc-av1-vvc/
この記事の下の方では
また、HEVCとVVCの間に生まれたAV1の最大の利点はライセンス料がかからないということで、商用利用をする上では非常に魅力的ですが、AV1はAOMediaが所有していない特許技術を回避するために非常に複雑な計算を行っており、それがエンコードに時間がかかってしまうことと電力効率が悪くなる原因となっているそうです。
また、完全オープンソースを名乗っているものの、知財管理企業のSisvelが特許リストを公開し、AOMediaが権利者団体の特許を侵害していると主張しており、将来的に「完全オープンソースでロイヤリティフリー」を維持できるかはわかりません。
と書かれてるしAV1も特許権利関係で面倒そうな気配が…完全オープンソースうたってるから問題出たらHEVCより面倒くさそう Sisvelのライセンシー数も順調に増えてるしオープンなコーデックって理想はもはや瓦解してるな AV1のフリーはAV1に対する訴訟をした瞬間失効することになってる
Sisvelは訴訟した瞬間AV1に対応するデバイスを使えなくなる
使おうとするとそこに付随する特許料金を払わなければならない
だから特許を侵害しているという主張しかしてない シスベルずっと騒いでるけど、騒いでるだけでなんの進展もないなｗ
AV1は最近配信でも使われ始めてるし順調に広がってるわ 特許の有効期限は20年なんだから、AOMediaが使いたい特許もいつかは切れるだろう
AV1のフォーマットを変えずにエンコを速く出来るのか、フォーマットの変更も必要なのか分からんけど、それが出来たらもう決まりだろう まともな企業はそんな危ない綱渡りせずに素直にSisvelやVectisみたいなパテントプールにお金払うんじゃないか もう特許関連はうんざりだから中身ブラックボックスのAIコーデックみたいなの流行らないかな
行列演算に特化したプロセッサが昨今は乗ってるし、エンコーダとデコーダのモデルをパブリックドメインにして終わり！
まあ処理能力だとか電力だとか乱立するだとか色々問題だらけだとは思うがw >>138
似たようなのはあるね
NVIDIA Neural Texture Compression
https://research.nvidia.com/labs/rtr/neural_texture_compression/
NTCはBC highと比較して容量が30%少ないにもかかわらず、
4倍高い解像度(16倍のテクセル)を提供する ひかげりさ死ねごみくず過保護ニーートクソババアどブス かないさだ死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ねボケカス
https://txxx.com/videos/8781013/wife-violation032/?promo=38843
かないさだ死ねぶっ殺すめったざしにされて死ねボケカスゴミクズ
生きてる価値ないから死ね
きめえ顔と声しやがってしねクソカス
地獄におちろゴミカスババア死ねじさつしろバーカクソ以下老害クズ野郎死ね虫ケラ
さっさと死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
こいつは性格人格ともにクソ野郎クズ野郎である溺死して死ね死ね死ね死ね死ね死ね死ね死ね
さっさと首へし折られてしね かないさだ死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ねボケカス
https://txxx.com/videos/8781013/wife-violation032/?promo=38843
かないさだ死ねぶっ殺すめったざしにされて死ねボケカスゴミクズ
生きてる価値ないから死ね
きめえ顔と声しやがってしねクソカス
地獄におちろゴミカスババア死ねじさつしろバーカクソ以下老害クズ野郎死ね虫ケラ
さっさと死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
こいつは性格人格ともにクソ野郎クズ野郎である溺死して死ね死ね死ね死ね死ね死ね死ね死ね
さっさと首へし折られてしね かないさだ死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ねボケカス
https://txxx.com/videos/8781013/wife-violation032/?promo=38843
かないさだ死ねぶっ殺すめったざしにされて死ねボケカスゴミクズ
生きてる価値ないから死ね
きめえ顔と声しやがってしねクソカス
地獄におちろゴミカスババア死ねじさつしろバーカクソ以下老害クズ野郎死ね虫ケラ
さっさと死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
こいつは性格人格ともにクソ野郎クズ野郎である溺死して死ね死ね死ね死ね死ね死ね死ね死ね
さっさと首へし折られてしね かないさだ死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ねボケカス
https://txxx.com/videos/8781013/wife-violation032/?promo=38843
かないさだ死ねぶっ殺すめったざしにされて死ねボケカスゴミクズ
生きてる価値ないから死ね
きめえ顔と声しやがってしねクソカス
地獄におちろゴミカスババア死ねじさつしろバーカクソ以下老害クズ野郎死ね虫ケラ
さっさと死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
こいつは性格人格ともにクソ野郎クズ野郎である溺死して死ね死ね死ね死ね死ね死ね死ね死ね
さっさと首へし折られてしね >>140
飛ばし飛ばししか読んでないですが、添付グラフや画像を見る限り思ったよりも期待出来そうですね。ありがとうございます。 >>149
「このGPU搭載により、DisplayPort 1.4の他にHDMI 2.1などの規格に対応すると共にAIを使ったスケーリング技術やハードウェアベースのVVC/H.266デコードにも対応しています。」
AIを使ったスケーリング技術が利用できるようになるということは、ゲームではない一般的な動画を超解像アップスケーリングして再生できるNVIDIAのGPUを搭載せずとも
低解像度の動画を滑らかに再生できるようになるわけだな（画質がどの程度かは実機がでないとわからないが）
VVCのハードウェアデコーダー搭載自体はありがたいことなんだけど、VVCのエンコーダーがソフトウェア含めていまだに不十分なだけに、これを活かせるようになるのがいつの話になるやら…
HEVCみたいに複数のパテント問題でまたややこしくなってたりしないんかね？ AIスケーリングがもっと幅広く実用的になってきたら高い解像度で配信することが減ったりするのかなあ 4Kは必要ないかもしれないが今の技術だとまだ超アンチエイリアス程度みたいなもんだからなあ AV1の超解像度モードがキーフレームとそれ以外のフレームでダウンスケールの設定を変えたり
キーフレームが指定した品質を下回った場合のみダウンスケールしたり出来て面白いんだけど使われてないな >>153
だから、それゲーム意外で超解像の品質が思ったより良くなかったからでしょ
所詮AIリアルタイム超解像はカクカクドット絵向きで動画には不向き AV1の場合はデコードのパフォーマンスが低下するからってのもあるかもね
ちょっと試した限りではエンコードは速くなることもあったけど
デコードはぎりぎり60fpsを再生できてたデバイスだとコマ落ちが発生した 結局高速化のためにアルゴリズムを割愛して実装しないといけないのなんかなぁ エンコードの負荷は高くなっても許容できるけどデコードの負荷が上がるのは困るんだよなあ 溜め込んだ動画、アップしてる奴は気をつけろ
デスクトップ版Googleドライブでおよそ6カ月分のファイルが突然消失したとの報告多数、Googleサポートが調査中
https://gigazine.net/news/20231128-google-drive-lost-data/ 今どき xvid にエンコ出来るソフトって
あるかな？
中古で買ったDVD プレーヤーのsd カードが
Xvid にしか対応してないみたいなんだ
Xvid converter はダメだった
Xmedia recoder も項目がないし
無理なのかな 今どき xvid にエンコ出来るソフトって
あるかな？
中古で買ったDVD プレーヤーのsd カードが
Xvid にしか対応してないみたいなんだ
Xvid converter はダメだった
Xmedia recoder も項目がないし
無理なのかな wikiに書いてあるエンコソフトなら出来るんじゃね
Xvidはまさかの2019年まで更新してたみたいだし >>161
何気にロイヤルティーフリー何だよな
BatchDOO!
で行けたわ
CORE 2 世代のソフトだから遅い この低コントラストシーンで視覚品質が下がっちゃうのlibvpxでもある傾向だな
バックポートしてほしい 「Opera」が動画の品質向上機能「Lucid Mode」を強化 〜適用前と適用後を比較可能に
https://forest.watch.impress.co.jp/docs/news/1552713.html
適用前と適用後の比較がうまく機能しないが、PCに保存している480p動画を再生してみたらなかなかに輪郭処理がきれいだぞ
専用プレーヤーの立場がｗ >>168
いや、対応するのWeb埋込みタイプだけじゃん 動画埋め込む必要あるならnode.jsとかでローカルファイル再生するだけのローカルサーバ建てればいいんじゃないすか。
多分HTMLの雛形にvideoタグだけ書いてコマンド1行打てば終わり。
埋め込みと言いつつブラウザ再生ならなんでもいいならブラウザにファイル投げ込むだけでいけると思う。 中華資本のブラウザよく使う気起きるな。
何仕込まれてるかわかったもんじゃない。 tplinkのネットワーク製品買う馬鹿な日本人多いからな
元から馬鹿だから救いようがないわ >>172
じゃあ同じ値段で同じ性能同じ機能の物を教えろよ
それが無いからTP-Link選んでるんだからさ ↓シナチョンは祖国に帰れ
(ﾜｯﾁｮｲ b6fc-yDrh) ID:ZCIpPYcr0
(ﾜｯﾁｮｲ d98c-GYsz) ID:hNkLi0WS0 NGID:ZCIpPYcr0
NGID:hNkLi0WS0 >>172も>>173もこんな所でヘイト書いちゃう辺り知能低そうw 国産かどうかって話はしてないよね
過去に騒動まであって中華ブラウザに成り下がったものはさすがに嫌だなって話 Operaの親玉が奇虎360
その奇虎360が出資している「麦芽地」がウィルスの「WireLucker」を作成し、奇虎360がウィルスパターンを世界で最初に作成するという自作自演をおこなったり
自社セキュリティソフトで百度などのサービスを有害サービスとしてブロックしたり、インストールされている他社のセキュリティソフトを勝手に削除していたりする
信頼性なんて皆無だろう。 低解像度ゲームなどのウィンドウをアップスケールして強制フルスクリーン化する方法
複数のスケーリングモードでゲームやアニメなど幅広く対応する「Magpie」
https://forest.watch.impress.co.jp/docs/review/1551934.html
動作に癖があるのと、dGPUなしだとAnime4Kモードが重たいなどはあるが、なかなか面白い AV1エンコードでの生配信できるスマホ・iPhoneってもうあるんす？
車載ドライブ・ツーリング配信とか電波状況で低ビットレートになりがちだからそういったときにも画質粘れそうなのがいいな それなりにスペックあればどんなスマホでもできるだろう >>182
スマホでAV1エンコード出来るものはまだ無い。
それどころか、需要なくて今後エンコードに関してはH.266採用になりそうだ。デコードなら最新スマホならほぼ出来る。 Googleのビデオ通話アプリがAV1採用してたけど photon-noise tableが使えるforkも1.8.0変更分の修正は入っている（ハズ）
https://github.com/BlueSwordM/SVT-AV1 なんかツベが低解像度でも文字が読みやすくなった気がする。
不思議だ。 本当にできたら革命だけど今後のコーデックはAIが主流になるのかな
Intel Ignite 2023で優勝！ AV1やH.266を超える圧縮率を実現するDeep Renderの「AIベースの動画圧縮技術」って何？
Deep Renderによると、現在の試作版ではH.264／H.265と同等画質なら5倍程度の圧縮率を達成しているという。これからも各部分のチューニングと改良を進めるとのことで、圧縮率を50倍にまで高められる見通しが立っていると豪語する。
https://www.itmedia.co.jp/pcuser/articles/2312/12/news064_2.html >>189
エンコードの話てんだろカス。
AV1で確実にHW出来るスマホ書いてみろよ無能が。 >>191
「ブースでは、2台のMacBookシリーズを用いて、互いのWebカメラで撮影した映像をリアルタイムにDeep Render形式でエンコード（圧縮）し、互いにデコードするというビデオ（Web）会議を模したデモンストレーションも行われた。
このデモでは、30fpsのフルHD（1920×1080ピクセル）映像を1Mbpsでエンコードして送り、同時に相手側から送られてきた同等品質の映像をデコードする、という実践さながらのものだった。
遅延（レイテンシ）は、0.1秒程度で十分に許容範囲だ。Deep Renderの説明によると、この遅延のうち0.04～0.05秒がコーデック処理によるもので、残りがデモ環境のWi-Fiネットワークによるものだという。
この際のプロセッサの消費電力は約13Wだった。エンコードとデコードを同時にソフトウェアで行って程度であれば、まずまずといったところか。」
続く 「ブースでは、2台のMacBookシリーズを用いて、互いのWebカメラで撮影した映像をリアルタイムにDeep Render形式でエンコード（圧縮）し、互いにデコードするというビデオ（Web）会議を模したデモンストレーションも行われた。
このデモでは、30fpsのフルHD（1920×1080ピクセル）映像を1Mbpsでエンコードして送り、同時に相手側から送られてきた同等品質の映像をデコードする、という実践さながらのものだった。
遅延（レイテンシ）は、0.1秒程度で十分に許容範囲だ。Deep Renderの説明によると、この遅延のうち0.04～0.05秒がコーデック処理によるもので、残りがデモ環境のWi-Fiネットワークによるものだという。
この際のプロセッサの消費電力は約13Wだった。エンコードとデコードを同時にソフトウェアで行って程度であれば、まずまずといったところか。」
これがマジならNPU搭載機でありさえすればどうにでもなるってことだな
すげぇな 貼りたかったところを間違えていた
「Deep Renderコーデックは、主にGeForce RTX 30／40シリーズを搭載するマシンで開発を進めてきたが、GPGPUとして活用できるGPUであれば、メーカーやモデル（アーキテクチャ）を問わず利用できるという。
また、スペックによって多少のパフォーマンス差は生じるものの、NPUを含む推論アクセラレーターを統合したCPUでも動くとのことだ。
先述の通り、今回はCore Ultraプロセッサを搭載するノートを使ったデモンストレーションも行われていたが、デコードとエンコードは主にNPUで処理しているとのことだった。
Deep Renderのユー氏は「もし事業が軌道に乗って、Deep Renderの採用事例が増えてくれば、現在はソフトウェアベースのエンコーダー／デコーダーがハードウェア化されて、今のH.264やH.265のように多くのSoC（のメディアエンジンなど）が対応するかもしれない」と、未来の展望を語っていた。」
今後はNVIDIAのCUDA専用で開発されていたものが、汎用のNPUで動かせるようになっていくのかもしれないな >>193
HWエンコードの話なんて誰もしてないぞ
そしてGoogleがSWエンコードで普通にAV1使ってる 有料ライセンス方式らしいけどどうなんかな
オープンソースが主流になりそうやけど結局特許で毎回荒れるし金払う方が意外と楽なのかもしれんと最近思う >>197
>>182の話でおまえスマホでAV1のSWエンコする気なの？
さすが無能のカスだなwww 勘違いして煽り始めたせいで引けに引けなくなってるやん… >>191
動き検索のAI置き換えかすごいな
ブロック単位で検索することのデメリットないしハマればすごいことになりそう >>191
究極のAIコーデックは
「猫型ロボットがダメ男を再教育する」
のテキストデータから30分のアニメ番組を再構築してくれるからな
圧縮率は半端ない スレ立ってたわ
動画圧縮のコーデック宗教論争、ついに終焉へ…H.265の50倍の圧縮が可能な技術が誕生！ [663344715]
https://greta.5ch.net/test/read.cgi/poverty/1702390000/ ファミコンの容量並みで8K解像度の動画できるオーバーテクノロジー早くしろ！ Iフレームみたいなシーク可能フレームはそんなに圧縮率上げられない気がするから1/50とか行く前に頭打ちすると思う。
ただ、動画配信業者なら通信料が下がればいいからIフレは最初だけで、シークされた場合のみ次フレームに繋ぐ事が可能なフレームを通常ファイルとは別に持っておくみたいな事はできそうだけど、HLSみたいな動画細切れにしてるプロトコルだとこういうのも難しそう。 そもそも圧縮技術が違うようだしIPB構造じゃないんじゃないか？
もし1/50に出来るなら全部Iフレームでも良いんだから。 h267とかそのくらいの規格なら機械学習取り入れてるだろうし、>>205自体は普及はしなさそう AV1おじさんだけど
aacのmp4つくってダブルクリックで観れているが、音声がパススルーされて無いから残念だ
パススルーで再生してくれる動画プレーヤーは無いかな？ aacに変換してるのにパススルーとかAV1ボケじいさんじゃん >>191
一般ユーザーとしては、これがいつ利用できるのかが最大の問題だな
1/50になるとかはともかくとしても、仮に1/4だったとしてもすごいわけで、
4K放送を1時間録画すると12GB弱になるけれど、これが3GBになると考えればすごいこと
単純にビットレートも1/4とはいかないにしても33.3Mbpsが9Mbps程度に落とせるようならば、
地デジの帯域でも【AIコーデックの4K + MPEG-2 720p】をひとつのチャンネルで同時放送できてしまえる
総務省が実現性の不透明な方法でVVCコーデックを使った地デジ4Kとか唱えているけど、あんなの必要なくなるぞ 最近のコーデックはデコード結果が環境によらず完全一致するのが規格で定まってるけど、
NPUは環境によって推論結果が微妙に違ったりするのをどうするつもりなのか気になる テレビの超解像もAI使ったものが主流になってるし、フルHDが綺麗に4kになったら、AIで1/4に圧縮されてるとも言える 実質1440×540(u,v成分はもっと低い)のデータを4Kにしてるなら更に倍率ドン…?? >>215
結果的に綺麗に見えていればいいわけで結果の一致などどうでも良い 環境によってデコード結果がバラバラだとデコーダーが正しく実装出来てるのか確認出来なくて面倒 >>218
1フレーム内でなら多少の差があってもまあ良いだろうけど、フレーム間予測をするからね
何も工夫をしないと誤差がどんどん拡大して時間が経つとまるで違う映像になってたということになりかねない
残差をどの程度真面目に処理すれば画質とビット量の効率が最大になるかの見積もりも難しくなる
GOPサイズを小さめにするという手はあるが、これは効率を低下させる方向になる 真面目に全部計算しなくても強制的にメッシュの網目で間引きしてやると、割と人間は騙されてくれるぞ。
みたいな技術はあるのでやってみるしかない。 >>216
某国の衛星放送の４K/8Kのデコーダーより、720p/FHDのNVIDIAのリアルタイムAI超解像度アプコンで十分だと最近思い始めたが
画質は比べると劣るし、GPUが頑張ってくれる分消費電力も比較にならんので、やっぱり保存用なら元の画素数は欲しい所だよ
必要のないニュースやyoutubeもなんでもかんでもみんな高画質にしてくれるのは有難迷惑だったりする…
数年後には使いやすくなってるんだろうけど YouTubeは2Kの画質が悪すぎるから、配信する立場としては4Kにしたくなるだろうことは理解できる
YouTube Premium用の2Kは若干改善されるが、正直イマイチ >>225
以前から -threads でマルチスレッド処理指定できてたろ >>226
こんなとこじゃなく公式にリプしてこいよｗ エンコードなどで使用する各ライブラリ内の処理は独自にマルチスレッド化されてスレッド数指定とかもあったけど
ライブラリを呼び出す処理はシングルスレッドだった
これをマルチスレッド化することで保守性向上と、ほんの少しだけスループットの向上が見込めるってことだと思う
あと複数の入出力で複数のコーデックとフィルタを通す処理が速くなるかも 変換時のスレッドの話じゃないからエンコード速度に変換無しだとさ Appleが鳴り物入りで発表した「MetalFX Upscaling」、実は「AMD FSR 2」ベースらしい
https://news.mynavi.jp/article/20231217-2843196/
超解像系も標準化が進みつつあるのかな？ Appleのゲーム周りって自社のブランド付けてる割にOSSのパクリばかりだよな
たしかsteamOSのもパクってた 時価総額世界一の会社とは到底思えないハリボテ企業だよAppleは AMDのFSR3もオープン化したので、自前チップ用の、さらにゲームエンジンじゃなくて動画用に書き直す気合があればいける。
news.mynavi.jp/article/20231215-2842151/ AMDってこういう所がな・・・（ハードも大して良く無いが
結局オープン化してユーザー丸投げしてサポート無しとかザラだから大して広がりもせんのよな Intelみたいに圧力掛けたり、nvidiaみたいにゲーム開発環境の囲い込み出来ない分シェア広げるにはオープンソース化するしか無いかと するならするで良いんだが、結局投げっぱなしで実になったことないやんｗ >>233
いや無理だよ
Zバッファーや速度ベクトルのバッファーとか使ってるからね
それを動画から生成できれば同じになると思うけど、結局それがAIの得意分野だろう オープンソースはLinux民みたいな民度があればいいけど…
CUDAやAI関連の遅れを取り戻すために後からテコ入れするAMDみたいなことになるだけ 年末大掃除で平成の遺物SkylakePCを発掘したんだが、AV1の4Kはカクカクなんだ
ゆとりおじさんの大好物のジャンボリミッキーを踊るちょっと厚化粧の4Kおねーさんとか無理だなと
年明けの金属回収に出すことにした。お疲れっした。ありがとうSkylake。君の事もSkylakeおじさんと呼ばれていたことも忘れない！ >>244
たぶんdolbyの代替を目指したコンテナだな >>245
マルチチャンネル音声って現状、一般人がフリーソフトとかで手軽に編集できないんだっけ？
YouTubeも昨年あたりからDolby Digital Plusに対応し始めたりしてはいるが、いまだに一般人が手軽にアップロードして使えるようにはなってないみたいだね
そろそろマルチチャンネル音声のコモディティ化を進めないと、いつまでたっても極一部の趣味人だけのもので終わってしまいかねない 今年もx266リリースされなそうだな
公式の予定だと2023年下半期になってたが [SVT-AV1-PSY] Add deltaq-mode=2 variance-boost feature by juliobbv
(large BD-rate increase and psy gains in hard scenes)
https://www.reddit.com/r/AV1/comments/190frvf/svtav1psy_add_deltaqmode2_varianceboost_feature/
>>164の最新パッチ(v5.1)適応版
オプションが2つ追加：
--variance-boost-strength
--new-variance-octile
アニメ素材ならデフォルト値よりboost4, octile7が良いかもしれないとパッチ作成者が言っているけど要テストのようだ 軽くグレインかけたいなら>249にあるforkはどちらもMRにある
film-grain: Implement film-grain-table option
が適応されていて高速なphotn-noiseが使えるのでお勧め DiscordのVVCコミュニティのやり取り見てると現在のvvencもグレインの保持はかなり苦手っぽいね
開発者がgitでVVCにもグレイン合成を実装する準備はできていると半年ほど前に言っているけど
https://github.com/fraunhoferhhi/vvenc/issues/278 https://aomedia.googlesource.com/aom/+/refs/tags/v3.8.1
libaom 3.8.1 release
2024-01-17 v3.8.1
This release includes several bug fixes. This release is ABI
compatible with the last release. See
https://aomedia.googlesource.com/aom/+log/v3.8.0..v3.8.1 for all the
commits in this release. >>254
うおまじか！これでやっとAVIFだけでwebサイト構築が出来るんだな！
今までどれだけMicrosoftのクソ仕様にクソクソ言って来たか ところがどっこい
AppleがついにChromeとFirefoxのフルバージョンをiPhone上で動かすことを許可
https://gigazine.net/news/20240126-ios-17-4-webkit-alternative-browser-engines/
｢2024年1月26日に発表されたiOS 17.4のベータ版では、Appleが史上初めてWebkit以外のエンジンの使用を許可していることがわかりました。
Appleによると、ブラウザアプリを開発する人、あるいはアプリ内ブラウザを開発する人は誰でも、希望すればWebkit以外のエンジンを使うことができるとのこと｣ >これはEUのデジタル市場法(DMA)施行を受けての対応で、EU圏のユーザーにのみ適用されます。 そのアップルもjxlには対応してるからなんか歪よなあ safariの良くないところは何年も前のバージョンで使われ続けるところね
現代のIEと言われる所以
chromeもedgeもfirefoxも1年以上前のバージョンで使われることはほとんど無いのに 海外フォーラムを見てると最近は8bitソースでも10bitでエンコするのがデフォになってきてるな
ようやく時代が俺に追いついてきたか Rigata氏の比較表を数年前に見てから知ってる人は10bitだと思うわ
RTX購入以降はNVEncC使ってh.265のBフレ&10bitってところだな
とあるところで世界がネトウヨにに隠れていた本気の日本に気づいたのかもしれん！ 映像比較をしなくなったrigayaのグラフ鵜呑みにしてるの信者だけだろ 最近ffmpegにvvc関連のコミット入りまくってるな 名作Flash『なつみSTEP!』のたけはらみのるが『スナックバス江』特別エンディングを”あのテイスト”で担当／たけはらみのる＆芦名みのる両監督インタビュー
https://getnews.jp/archives/3499927
Flash、ワレ生きとったんかい… FlashはRuffleアドオンを入れれば再生可能だ
Ruffleはアドオンなのでセキュリティーの懸念はない
Flashは復活したんだ！ wasm使ってjavaとかphpをブラウザで動かせるようになってるし
flashも余裕よな >>265
じゃあお前が代わりに主観画質評価したら？ スマホでAV1対応してるのってiPhone 15からでAndroidはスナドラ8gen2かMediatekのハイエンドsocだと搭載してるぐらいか
スマホだとYouTubeで8K再生可能なのかな 8K再生出来てもスマホの解像度が足りない。今のスマホでも4Kってないだろ。
8Kの1/4、1/8の解像度に縮小表示する事になるから、素の1440pで見るより劣化すると思うよ。 ハリウッドの映像制作の記事で読んだが、解像度の低い動画は一度4K動画にアップコンバートした後に2K動画へダウンコンバートすることで、解像度限界の最高画質の動画を作る事ができるらしい それはディテールが乏しいSD画質を4Kアプコンでディテールを作ってるから。単純縮小とは違う。 4:2:0の動画なら、半分の解像度に圧縮する事でピクセル辺り4:4:4分の情報使えるようになるんだから少なくとも2倍の解像度までは効果あるよ。
あとyoutubeの1080pはビットレート緩いからそんなん考えるまでもなく普通に画質良くになる。 >>275
Xperia 1 III以降が4K
Galaxyが4Kかと思ったら意外とQHDだった
他は知らん ビットレートの制限が緩いってことやろ
ニコ動とか1080pでもビットレート制限越えると480pにダウンコンバートされてたし クセ強めだけどそこまで上げ足とるような言い回しでもないだろ
と思ったけど281みたいに逆の意味にも取れちゃうか Snapdragon 8 gen2ベースのXR2 gen2を使ってるMeta Quest3はつべの8K再生出来るね
メタデータなしのVR180動画を標準ブラウザで再生するとちゃんと解像度高いなとなる >>274
近い将来、AV1かAVIFで記録される時代が来るのかね >>287
本当だ
使っているBDが凄くレアだったから必須とは思っていなかった スマホってせいぜい7インチ以下なのに、4K解像度あっても見える視力がないよ
10インチタブレットでも4K必要か？は、怪しい
Apple Vision ProのようなHMD向けならわかるが スマホはスケーリングちゃんとやってるからどれだけ解像度高くても問題ないだろ 解像度高いと処理が重くなりフレームレート下がるんだが
6インチクラスで4Kなんて、いい事はなにもない 有機ELのペンタイル配列だと解像度低いとギザギザに見えるから
液晶より高解像度にしてるとかいうのをどっかで読んだ記憶 >>288
持ってる動画は大体AV1でエンコードし直してるわ これ以上解像度上がっても綺麗さはさほど変わらないのに必要な性能は2倍4倍と増えるからな
高解像度化はコスパ悪い 大きさ的にHDで十分なのに、4Kにしたら処理、転送、メモリー読み書き、消費電力と全部4倍必要になる
アホかな？
カメラ撮影を4Kでしておくことと、画像処理してデバイス標示するのは、全く意味が異なる >>294
標示デバイスだけ4Kにして、元HD処理データを4K補完表示するのは効果的
それこそ今の4K世代SoCなら楽勝
だけど6インチスマホで、有機ELのHDがギザギザに見える視力が、普通にあるかな？ 前の液晶の機種は縦1920だったけど、今はAMOLEDの1520だけど全く荒さを感じない
6インチ以下なら1520で十分 ここは次世代ビデオコーデックのスレなんで、コーデックに関係あればスマホから映画館まで包含してるだろ つうか、突然頭弱いだの賢いだの言い出す奴はコンプレックスの塊だろw
お前に何が有ったんだw ちょっと待ってyoutubeの設定からav1が消えてるんだけど。。。
enhance h264でav1ブロックしても強制的にav1になる動画もあるしどういう基準でそうなってるんだろうか
使ってるgpuがav1非対応だからやめてクレメンス
どうにかしてブロックする方法ないかな。。。 >>274 androidなら2年位前のミドルでもAV1デコーダーついてる奴はあるね
3kで投げ売りされてたfirestick(ver2021)についてる位だからハイエンドどうのは特に関係なさそう。 >>303
format codeで弾いてる
AV1に追加のCode Valueが割り当てられたんだろ WEBMってコンテナは何になんの
mp4boxではエラーになるので、MP4には入らないようだが webmはコーデックではない
VP9やVP8がコーデック webmはどうしてろくにメタデータを保持できず
タイムスタンプもぶっ壊すmatroskaを採用してしまったのか フリーのリモートPCソフト「Verethragna 0.11.0」、独自の「YUV444」高画質モードを追加
https://forest.watch.impress.co.jp/docs/news/1574820.html
「Verethragna」はビデオコーデックとして「VP8」を採用しているが、「VP8」が扱えるのは仕様上「YUV420」のみで、「YUV444」は利用できない。
しかし、本バージョンでは独自技術により「VP8」で「YUV444」を扱えるようにしたとのこと。
厳密には「YUV444」ではなく、「YUV」と「RGB」のハイブリッドのような構造になっているとのことで、ノイズも色誤差も少なく、画質的には「YUV444」を上回る「超YUV444」になっているという。
スーパーサイヤ人みたいなものか？
動画にも応用できたらおもしろいかも（データ量と互換性的にメリットがあればだが） aviutlの内部表現のYC48みたいな感じなのかな(あれはデータ効率悪そうだったけど) この手の見出しは「YUV444」って言うから誤解が増える
外に互換性ないものが出回らないなら自由にしていいとは思うが 機材が発色できなきゃ意味ねえんだが、色空間もそろそろなんとかしろやと思う。 SVT-AV1はスピード7までは早いのに6から劇遅になるの草 ビルドスピード考えると結局H265なんだよな
現状だと https://github.com/Nevcairiel/LAVFilters/releases/tag/0.79
0.79.0 - 2024/03/25
LAV Splitter
NEW: Support for demuxing VVC video
Changed: Updated language lists to support all relevant language codes
Changed: Improved resilience of streaming HLS
Changed: Tweaked frame rate detection logic
LAV Video:
NEW: Support for decoding VVC video 「Microsoft Teams」の画面共有にAV1ビデオコーデックが採用 ～低速回線でも鮮明に
従来のH.264ビデオコーデックより63％のネットワーク帯域幅削減
https://forest.watch.impress.co.jp/docs/news/1579410.html
AV1が利用できるシーンが着々と増えているようだな av1の圧縮再生の負荷はかなり大きいから、
これが使えるかが鍵になってくるか。
変な特許問題持ち出してくるパテントトロールの餌食にならなきゃ
h.264と比べるのも時代的になんだかなと思うが一応あの世代のデファクトスタンダードだからね 音声コーデック何使ってるんだろ。
ついでにopus突っ込んであればすごいが。 TeamsはSatinコーデックじゃなかったっけ？ silkの改良型がopusで、その更にAIデコードありがsatinか。
サンクス。 映像のコーデックにAIが使われるのはいつになるかな
NPU搭載デバイスが増えたら実用的になりそうだが コーデックにＡＩは笑う。AIを何か万能なツールだと思ってるのか
ＡＩをよく知らん人が言いそうなことだな。もうそこまでの人の耳に入ってきてるってことか
実用が何か知らんけど、動画のアップスケールなら既にＡＩがやってるだろ
それか静止画や文章から動画生成するＡＩのこと言ってるのか
だとしてもそれはコーデックとは言い難い 330氏はAIMをコーデックに使うことに対して、どのような使い方を想定してるのかな まあCODECの圧縮アルゴリズムの開発検討させて、テストさせてもいいけど
画質評価という点で、AIの主観が役に立つかなあ なんでそんな噛みつき方してるのか知らんけどdeep renderとが少し前に話題になったばっかだろｗ AV1とかVVCにもちょっとだけAI由来の技術が使われてた気がする 普通に考えたら予測画像生成に使うんじゃねーかな
モードの一つということなら変な予測結果なら使わないだけだし
まあ細々とモード自体や動きベクトルの予測とかに使っても効果あるかもしれんけど AIの主観とは、まるでAIに人格があるかのように言うね AIは少ない情報で画像をでっち上げるのが得意だから、AIを固定してそれがでっち上げた画像との差分だけをエンコードすれば劇的にデータ量が減ると思うけどね
その辺の仕様を決めるのが、AIを使ったコーデックと言うんじゃないかね AIの画像生成はまだ過渡期だから、コーデックになるほど枯れてくるのはまだ先だろうな
オレオレAI使ったコーデックはこれから山ほど出てくると思うけど、万人が使えるような統一した規格はまだ全然先だと思われる >>325
クロームリモートデスクトップで動画再生時OPを
AV1にするとかなり軽くなるな
H264やVP8はかなり重い 最近はAI=生成AIみたくなってるせいでここでも的外れな事言ってるやつ多いなｗ
それより前に話題になった画像認識の方使ってフレームをブロックに分けずに類似度判定、時間軸でオブジェクト単位の移動量算出だぞ >>343
的はずれって…
的が外れてることを証明できるほど、お前はAIを知りつくしてんのか？ 既存のAI活用コーデックの説明見てくりゃいいじゃない 今一般的な文脈で使われるAIモデルは多次元行列のノード間(樹形図の枝)の移動にかかる係数を記録しているもので、つまり多次元行列を処理してAをBに変換する関数であり、AIの学習はA→Bをより尤もらしくする最適化の認識
プログラムで関数に引数渡して別の値を得るように、基本なんでも使えるはずだけど、得手不得手はかなり極端だと思う(動画圧縮は引数が多いし非常に得意そうだけど) SVT-AV1 2.0でエンコード時のメモリ消費量が3GBから1GBいかに減ったわ
たまげたなあ よくカメラとか放送の仕様で8kだと120fpsがセットで候補に入ってるの何でなん
高い解像度こそフレームレートも高くないとダメなの？ >>348
そんな事はないよ
4Kから上にインターレースはないから、必ず30P50P60P以上になるけど
8Kがカメラがそのメーカーのフラッグシップだから、現時点で可能な最高フレームレートまで盛り込んでるだけでは？
展示会とか手術とかのいくらでも金は出すって需要は、少ないけど一定数あるから >>349
なるほど単純にハイエンドだからセットにされがちってことか
次世代地上波の仕様の候補にも8kのとこだけ120pがあったからなんか事情があんのかと思ってたや >>350
シャープの8Kの安い880万のカメラは、60Pじゃなかったかな？
放送規格案はその時点で最高のを入れとかないと、後で色々文句つけられるから
現行地デジHDがMPEG2なのも、まだH.264が固まる前のタイミングで仕方なかったけど、相当あれこれ言われてたな 22.2chオーディオはさすがに過剰だと思うけどな… 規格なんだから過剰でいいだろう
別に使わなくても良いんだぞ そう、規格がその時点の最大限取り込むのは、当然
8Kでモノ番組が作れないわけじゃない
むしろ、例えば5.1chサラウンドで作るのに、制作判断でセリフ音声をセンターchだけでなくLRにもこぼすとか、規格の想定を超えてる作り込みで齟齬が起きるのは、解決が難しいね Googleが高品質なJPEG画像の圧縮率を35％向上させる新たなコーディングライブラリ「Jpegli」を発表
https://gigazine.net/news/20240404-google-introducing-jpegli-jpeg-coding-library/
次から次に、いろいろ出しすぎて何がいいんだかわからなくなってくる… 画像の評価システムも絡んでくるから、そんなに遠い話ではない。
画質を比べるならいまの技術では静止画なんじゃない？ 次世代のくくりに入るかは分からんけどもMotionJPEGはあるからな
Webカメラなんかでは現役 AVC UltraやXAVCとかのALL-Iは、Motion JPEGと大差ないよ
コンテナとしてTCとか16ch AUDIOとか入れ込んでるけど、ほぼそのままフレームレートの倍数で容量が決まる
静止画の圧縮効率は、そのまま動画圧縮効率になる フルハード実装とか電源切れるギリギリまで記録しろってのも需要あるのね。 >>355
これでまたJPEGが延命してしまうな…
JPEG XLの技術を使ったとあるけど、だったらJPEG XL使えよw
ChromeがJPEG XLを削除しなかったら、とっくに普及してたと思うね でも最近AVIFを使ってるサイトも出てきたから、AVIFに頑張ってもらいたい スレチのアホ共liが何か新しいものだと勘違いしてて草 元からJPEG XLのサブプロジェクトだからな
以前からあるしGoogleが作ったものでもない
ただブログで紹介しただけ >>364
海外サイトだとGoogleのJPEG XLチームが開発したって書いてある
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
> More recently, the JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg.
(翻訳) さらに最近、GoogleのJPEG XLチームが、mozjpegよりも高速で優れたJPEGエンコーダjpegliを開発しました。 >>360
放送用のレコーダーとかな
報道ヘリの機内映像録画とか、ロケ用カムコーダーとか
遅延最短で電源不安定でも、とにかく最後の1コマまで撮れてるのは、アナログVTRなら当然だったし https://www.mozilla.org/en-US/firefox/125.0.1/releasenotes/
2024 年 4 月 16 日
バージョン 125.0.1、2024 年 4 月 16 日にリリース チャネル ユーザーに初めて提供
Firefox は、Encrypted Media Extensions (EME) の AV1 コーデックをサポートするようになり、
ビデオ ストリーミング プロバイダーからのより高品質な再生が可能になります。
やったねたえちゃんNetflixやAmazon Prime VideoでAV1で楽しめるよ VVenC, the Fraunhofer Versatile Video Encoder
https://github.com/fraunhoferhhi/vvenc fraunhoferhhiといえば最近xpsnrをffmpeg7.0に対応させてたな
それまではffmpeg4.0か6.0に適応させたforkを使う必要があったけど
XPSNR Filter Plug-in for FFmpeg
https://github.com/fraunhoferhhi/xpsnr/releases/tag/v1.3 Dolby Visionって10bitになっただけ？ - New Features
* New codec control
* AV1E_SET_SVC_FRAME_DROP_MODE is added to configure the SVC encoder to
only drop spatial layers or the whole superframe.
* Active Map is fixed and tested for RTC.
* CONFIG_QUANT_MATRIX is added to disable quantization matrices when aom
decoder is disabled with CONFIG_AV1_DECODER. Reduces ~10% binary size when
both are disabled.
* libwebm is updated to libwebm-1.0.0.31-1-gaffd7f4.
- Compression Efficiency Improvements
* RTC encoding improvements
* 1-2% BD-rate gain for screen content with temporal layers; 5% BD-rate
gain on scrolling content.
- Perceptual Quality Improvements * For RTC screen content
* Reduced color artifacts for RTC screen content
* Visual quality improved for scene changes for SVC with quality layers.
* Removed visual artifacts for speed 11
- Speedups:
* RTC Speed 11: aggressive speedup setting added for video mode,
resolutions <= VGA: ~30% faster than speed 10.
* 5-9% speed up for high bit-depth encoding with good mode on Arm, half of
which comes from SVE/SVE2 optimizations.
- Other improvements
* Further improvements to global motion estimation.
* Documented minimum required SIMD support: SSE4.1 on x86, Neon on Arm.
* Remove unneeded SIMD functions, saving >100 KiB from binary size.
* Cleaned up and improved pattern_search.
* Added end-to-end c vs SIMD bit-exactness test.
* Added config flag to calc psnr using libvmaf peak: use a slightly
different peak value for PSNR (1020 and 2040 for 10- and 12-bit) twitchってまだav1使ってないのかな
結構前にテストしてたよね 
