Intel confirms Meteor Lake has AV1 video encoding and decoding support（VideoCardz）
intel / media-driver/docs/media_features.md（GitHub）
IntelがGitHubに掲載されたMedia Driverの資料によると、“Meteor Lake”はAV-1のエンコード・デコードに対応する模様だ。
“Meteor Lake”では機能がTileと呼ばれるダイごとに分散されるが、その“Meteor Lake”はGraphicsや動画エンコード・デコードにおいてさらに柔軟性を高めたものとなるようだ。
“Meteor Lake”のGPUは“Tiger Lake”で採用されたXe-LPの後継となるXe-LPGである。
資料によると、“Meteor Lake”はAV1 8-bitおよび10-bitの動画エンコード・デコードに対応する。この機能はDG2―Arc Alchemistと同等である。
intel / media-driver/docs/media_features.md（GitHub）
IntelがGitHubに掲載されたMedia Driverの資料によると、“Meteor Lake”はAV-1のエンコード・デコードに対応する模様だ。
“Meteor Lake”では機能がTileと呼ばれるダイごとに分散されるが、その“Meteor Lake”はGraphicsや動画エンコード・デコードにおいてさらに柔軟性を高めたものとなるようだ。
“Meteor Lake”のGPUは“Tiger Lake”で採用されたXe-LPの後継となるXe-LPGである。
資料によると、“Meteor Lake”はAV1 8-bitおよび10-bitの動画エンコード・デコードに対応する。この機能はDG2―Arc Alchemistと同等である。
Low-power AV1 encodingへの対応は数ヶ月ほど前にIgor's Labsがそれを対応する旨を記載したスライドをリークしていた。
このところ悪い話が続いていた“Meteor Lake”であるが、今回のはささやかだが良いニュースである。
“Meteor Lake”で搭載されるiGPUはXe-LPGと呼ばれるものになり、メディア周りの機能がArc A seriesと同等のものになるようだ。その内容が今回のGitHubに掲載された資料にあり、中でもAV1形式のエンコード・デコードへの対応が注目されている。
現在AV1エンコードに対応している製品はNVIDIAの“Ada Lovalace”ことGeForce RTX 40 series、AMDのRDNA 3ことRadeon RX 7900 series、そしてIntelのArc A seriesとなる。AMDのRDNA 3についてはこれから下位モデルが出るとともに、“Zen 4”世代のAPU―“Phoenix Point”がRDNA 3世代のiGPUを搭載する見込みで、“Phoenix Point”での対応も期待される。
“Meteor Lake”もまたArc A seriesの派生アーキテクチャ（厳密にこの表現が正しいかどうかは自信がないが）に進化するため、Arc A seriesと同じようにAV1エンコードに対応することになった。
コメント欄でIntelのiGPUのメディア機能を活用している方を散見するので、これ自体は想定の範囲内であっただろうが良いニュースであろうとは思う。
残念なのはやはりデスクトップ向けに“Meteor Lake-S”が出ないという懸念がくすぶっていることだろうか。この懸念が大外れして出てくればうれしいが、出るかどうかはIntel 4の製造容量と“Arrow Lake-S”の進捗次第ということになるのだろうか？
この記事へのコメント
モバイルはPhoenix Pointが勝つ可能性出てきたけど
6000シリーズと同じく国内メーカーが採用せずに
ニッチな存在になりそうなのが残念すぎる
欲しいのはジェネリックSwitchやないねん
6000シリーズと同じく国内メーカーが採用せずに
ニッチな存在になりそうなのが残念すぎる
欲しいのはジェネリックSwitchやないねん
2022/12/27(Tue) 07:15 | URL | LGA774 #-[ 編集]
Xe-LPGってゲーミングのG？
かなり性能上がるんか？
かなり性能上がるんか？
2022/12/27(Tue) 10:21 | URL | LGA774 #-[ 編集]
神CPU来たな(´･ω･`)
2022/12/27(Tue) 15:16 | URL | aaaa #-[ 編集]
https://rigaya.github.io/vq_results/
これを見ていると intelのハードウエアエンコーダは出来は良いから期待大ですね。圧縮率はhevcとほとんど変わらないから一般用途ではhevcで十分かもしれないけど。
これを見ていると intelのハードウエアエンコーダは出来は良いから期待大ですね。圧縮率はhevcとほとんど変わらないから一般用途ではhevcで十分かもしれないけど。
2022/12/27(Tue) 16:14 | URL | LGA774 #-[ 編集]
今更削るのはあり得ないとはいえ、結局は自社のXe dGPU需要を殴るだけになりそう
2022/12/27(Tue) 19:04 | URL | LGA774 #-[ 編集]
前の記事でのコメントのソースを見たら更新されていた。
Intel7 （5工場） Fab 12🇺🇸, 22🇺🇸, 28🇮🇱, 32🇺🇸, 42🇺🇸
Intel4/3 （1工場） Fab 34🇮🇪
Intel20A/18A （4工場） Fab 27🇺🇸, 52🇺🇸, 62🇺🇸, 42🇺🇸(Intel7用から転換)
Intel20Aの工場が先に作られていて、Intel4の製造容量はかなり小さそう。
2023はIntel4でMeteor lakeをモバイル向けだけちょっと作って、
2024はクライアント向けは20AでArrow lake、サーバー向けはIntel3に改装してGranite RapidsとCierra Forrestという感じではなかろうか。
そもそも2020年頃はIntelはEUV露光装置の受注可能量をほとんどTSMCとSamsungに持ってかれてEUV露光装置自体をほとんど持っていないと言われる。
次世代EUV露光装置のTwinscan EXE:5200は初期顧客として大量発注したが、これの納品が2024年なので、20Aからしか生産キャパがないのだと思われる。
Intel7 （5工場） Fab 12🇺🇸, 22🇺🇸, 28🇮🇱, 32🇺🇸, 42🇺🇸
Intel4/3 （1工場） Fab 34🇮🇪
Intel20A/18A （4工場） Fab 27🇺🇸, 52🇺🇸, 62🇺🇸, 42🇺🇸(Intel7用から転換)
Intel20Aの工場が先に作られていて、Intel4の製造容量はかなり小さそう。
2023はIntel4でMeteor lakeをモバイル向けだけちょっと作って、
2024はクライアント向けは20AでArrow lake、サーバー向けはIntel3に改装してGranite RapidsとCierra Forrestという感じではなかろうか。
そもそも2020年頃はIntelはEUV露光装置の受注可能量をほとんどTSMCとSamsungに持ってかれてEUV露光装置自体をほとんど持っていないと言われる。
次世代EUV露光装置のTwinscan EXE:5200は初期顧客として大量発注したが、これの納品が2024年なので、20Aからしか生産キャパがないのだと思われる。
2022/12/27(Tue) 20:47 | URL | LGA774 #-[ 編集]
令和のi810かな？
2022/12/27(Tue) 21:26 | URL | LGA774 #-[ 編集]
ここ何年かHWエンコーダの性能は、Intel > Nvidia >>> AMD
同じGPUのA380のエンコーダ性能も最高レベルなのでMeteor Lakeも期待できるね。
というか、AMDのHWエンコーダだけがひどすぎる。
HWデコーダのサポートも減らしてたり、かつて動画が得意だったATI/AMDの見る影もない。
同じGPUのA380のエンコーダ性能も最高レベルなのでMeteor Lakeも期待できるね。
というか、AMDのHWエンコーダだけがひどすぎる。
HWデコーダのサポートも減らしてたり、かつて動画が得意だったATI/AMDの見る影もない。
2022/12/28(Wed) 00:07 | URL | LGA774 #-[ 編集]
AMDのHWエンコーダは再びBフレームを扱う様に更新されたので以前の様な大差は無くなったかな。
とはいえ、ファイルサイズを縮めながら画質維持するにはCPUエンコが良いのは変わらんので
CPU性能が跳ね上がったお陰で結局CPU使っちゃうけど。
安いCPUでつべ生配信するなら向いてるね。
とはいえ、ファイルサイズを縮めながら画質維持するにはCPUエンコが良いのは変わらんので
CPU性能が跳ね上がったお陰で結局CPU使っちゃうけど。
安いCPUでつべ生配信するなら向いてるね。
2022/12/28(Wed) 04:18 | URL | LGA774 #-[ 編集]
>>192800
動画の再生・録画やビデオ通話とかはエンコーダーやデコーダーの性能が重要になるからね
そこの性能が低いとどうしても学生やビジネスパーソン向けとしては売りが弱くなる
強力なGPUパワーが必要な用途となると結局はdGPUに頼ることになるし
ジェネリックSwitchとバカにする（？）人ともいるが
AMDのAPUは現状ではゲーミングUMPC用途が一番マッチしてるんだよな
動画の再生・録画やビデオ通話とかはエンコーダーやデコーダーの性能が重要になるからね
そこの性能が低いとどうしても学生やビジネスパーソン向けとしては売りが弱くなる
強力なGPUパワーが必要な用途となると結局はdGPUに頼ることになるし
ジェネリックSwitchとバカにする（？）人ともいるが
AMDのAPUは現状ではゲーミングUMPC用途が一番マッチしてるんだよな
2022/12/28(Wed) 07:40 | URL | LGA774 #wLMIWoss[ 編集]
AV-1エンコード/デコード対応はいいねー。
ただ、エンコード/デコードがボトルネックになってる人って少ない気がするのよね・・・
ただ、エンコード/デコードがボトルネックになってる人って少ない気がするのよね・・・
2022/12/28(Wed) 08:50 | URL | LGA774 #-[ 編集]
>>192813
Intel4/3って工場1つしかなかったのか…しかもアメリカ国内には工場なし
この世代は過渡期だな
Intel4/3って工場1つしかなかったのか…しかもアメリカ国内には工場なし
この世代は過渡期だな
2022/12/28(Wed) 09:47 | URL | LGA774 #-[ 編集]
問題はAppleがAV1に対し消極的なことで、視聴向けはHEVC
素材向け動画はむしろProResを使わせたいというのが見え隠れしている。
また各社AV1エンコーダの開発に成功したのはいいことなんだが、
結局10bit止まりなのも悩ましく最近のカメラの性能を考えるとやっぱり12bitは欲しい。
もっともHDRは再生側にもいろいろ難しい問題があり、
バンディングがなくなる明るい未来はいつやってくるのか…
ちなみに静止画に関してはAppleはHEIFだけでなくAVIFもサポートするので
おそらくJPEGの後継はこれに決まり(何度目だ)になるだろうね。
素材向け動画はむしろProResを使わせたいというのが見え隠れしている。
また各社AV1エンコーダの開発に成功したのはいいことなんだが、
結局10bit止まりなのも悩ましく最近のカメラの性能を考えるとやっぱり12bitは欲しい。
もっともHDRは再生側にもいろいろ難しい問題があり、
バンディングがなくなる明るい未来はいつやってくるのか…
ちなみに静止画に関してはAppleはHEIFだけでなくAVIFもサポートするので
おそらくJPEGの後継はこれに決まり(何度目だ)になるだろうね。
2022/12/28(Wed) 09:57 | URL | LGA774 #-[ 編集]
そもそもAV1にどのくらい需要があるのかがわからない
2022/12/28(Wed) 11:42 | URL | LGA774 #-[ 編集]
HTMLの「video」タグにH.264/AVC以外を入れようとすると、未だに何かしらの問題が出る
おかげで、職場のホームページに直接載せている動画は、全てH.264での掲載を余儀無くされている有様
H.264以外のコーデックを使った動画を複数用意し、確実とは言えないブラウザ判別をわざわざ使ってまで、H.264を回避するメリットをあまり感じない
そのH.264ですら、全てのブラウザがサポートしたのは「Firefox35(2015/01/14)」以降で、H.264が規格化されてから10年以上も経過している
Can I Use - video format
https://caniuse.com/?search=video%20format
これを見れば、現在の混沌としたブラウザサポート状況が分かるだろう
※IE、およびChromiumじゃない頃のEdge(18まで)は無視する
・AV1
Chrome 70以降
Firefox 67以降(Androidではフラグ有効化が必要)
Edge 79以降(Win10以降、かつ別途AV1コーデックインストールが必要)
Safari…対応する気ゼロ(iOS向けも同様)
・HEVC/H.265
Chrome 107以降(新し目のOS、かつハードウェアがデコードに対応していること)
Edge 79以降(Windows 10 1709以降、かつハードウェアがデコードに対応しており、かつ別途HEVCコーデックインストールが必要)
Edge 107以降(macOS 11.0以降、かつハードウェアがデコードに対応しており、かつ別途HEVCコーデックインストールが必要)
Safari 11以降(iOS向けも同様、macOSはHigh Sierra以降であること)
Firefox…対応する気ゼロ
・VP8/VP9
Chrome 25以降
Edge 79以降
Safari 14.1以降(macOS 11.3以降)
Safari 12.2以降(iOS12.2以降、VP8のみ)
Firefox 28以降
これを見ると、VP8なら何とか行けそうだが、それならH.264で良い
AV1もHEVCもVP9も、サポート環境が限られるため、必ず複数を採用し、環境毎に切替える必要が出てくるので、当面はH.264にせざるを得ない
高々そのためだけに余計な検証コストが発生するのは流石に勘弁してほしいところではある
AppleがHEVCゴリ押し・他コーデック排除でなければ、状況はもう少しマシだっただろうに…
おかげで、職場のホームページに直接載せている動画は、全てH.264での掲載を余儀無くされている有様
H.264以外のコーデックを使った動画を複数用意し、確実とは言えないブラウザ判別をわざわざ使ってまで、H.264を回避するメリットをあまり感じない
そのH.264ですら、全てのブラウザがサポートしたのは「Firefox35(2015/01/14)」以降で、H.264が規格化されてから10年以上も経過している
Can I Use - video format
https://caniuse.com/?search=video%20format
これを見れば、現在の混沌としたブラウザサポート状況が分かるだろう
※IE、およびChromiumじゃない頃のEdge(18まで)は無視する
・AV1
Chrome 70以降
Firefox 67以降(Androidではフラグ有効化が必要)
Edge 79以降(Win10以降、かつ別途AV1コーデックインストールが必要)
Safari…対応する気ゼロ(iOS向けも同様)
・HEVC/H.265
Chrome 107以降(新し目のOS、かつハードウェアがデコードに対応していること)
Edge 79以降(Windows 10 1709以降、かつハードウェアがデコードに対応しており、かつ別途HEVCコーデックインストールが必要)
Edge 107以降(macOS 11.0以降、かつハードウェアがデコードに対応しており、かつ別途HEVCコーデックインストールが必要)
Safari 11以降(iOS向けも同様、macOSはHigh Sierra以降であること)
Firefox…対応する気ゼロ
・VP8/VP9
Chrome 25以降
Edge 79以降
Safari 14.1以降(macOS 11.3以降)
Safari 12.2以降(iOS12.2以降、VP8のみ)
Firefox 28以降
これを見ると、VP8なら何とか行けそうだが、それならH.264で良い
AV1もHEVCもVP9も、サポート環境が限られるため、必ず複数を採用し、環境毎に切替える必要が出てくるので、当面はH.264にせざるを得ない
高々そのためだけに余計な検証コストが発生するのは流石に勘弁してほしいところではある
AppleがHEVCゴリ押し・他コーデック排除でなければ、状況はもう少しマシだっただろうに…
2022/12/29(Thu) 05:00 | URL | LGA774 #-[ 編集]
>>192832
いまは動画配信文化もあるし
昔に比べテレビやPCモニタの平均的な解像度も上がってるし
動画の超解像ソフトとかも一般向けに出てきてるしで
録画ファイルがいっぱいある人間にとっちゃ
容量抑えて動画を保存できる手段の需要は増してるんじゃない？
とはいえ何が何でもAV1じゃなきゃダメってことではないし
192827が言ってるような問題もあるみたいだけど
いずれにせよ対応してないことには試すこともできないからな
いまは動画配信文化もあるし
昔に比べテレビやPCモニタの平均的な解像度も上がってるし
動画の超解像ソフトとかも一般向けに出てきてるしで
録画ファイルがいっぱいある人間にとっちゃ
容量抑えて動画を保存できる手段の需要は増してるんじゃない？
とはいえ何が何でもAV1じゃなきゃダメってことではないし
192827が言ってるような問題もあるみたいだけど
いずれにせよ対応してないことには試すこともできないからな
2022/12/29(Thu) 07:49 | URL | LGA774 #wLMIWoss[ 編集]
Intel Arkの存在意義がまた一つ減りますね・・・
2022/12/29(Thu) 20:56 | URL | LGA774 #-[ 編集]
Youtubeやニコニコ動画などのサイトはアップロード後に各解像度用に再エンコードされてクソ画質化されるから、アップする時にAV1とかやってもほぼ意味が無い。
画質重視でロスレスにするならぶっちゃけAV1じゃなくて良い。
AV1じゃなくて良ければ最新のGPUエンコードである必要も無いので古い世代でもOK。
Youtubeに10GBとか20GBのロスレスでアップするのが一番綺麗。
配信はH.264じゃないと再生側の問題があるので仕方ない。
公開用：H264ロスレス(q0)でキャプチャ→Youtubeにアップ
保存用：H264ロスレス(q0)でキャプチャ→x265/libaom AV1分割エンコードで綺麗/コンパクトに変換
画質重視でロスレスにするならぶっちゃけAV1じゃなくて良い。
AV1じゃなくて良ければ最新のGPUエンコードである必要も無いので古い世代でもOK。
Youtubeに10GBとか20GBのロスレスでアップするのが一番綺麗。
配信はH.264じゃないと再生側の問題があるので仕方ない。
公開用：H264ロスレス(q0)でキャプチャ→Youtubeにアップ
保存用：H264ロスレス(q0)でキャプチャ→x265/libaom AV1分割エンコードで綺麗/コンパクトに変換
2022/12/29(Thu) 21:46 | URL | LGA774 #mQop/nM.[ 編集]
2030年代次世代地上デジタル放送では、VVC/H.266が確定みたいだけど。
AV1普及するかね？
AV1普及するかね？
2022/12/30(Fri) 10:56 | URL | LGA774 #-[ 編集]
つべ生配信と言っても、配信者が帯域を幾分小さくできる以外のメリットはないかな
通信コストと圧縮コスト、ストレージコストのバランスで結局今はオフラインで色々な規格の動画をストレージに置いておくのが主流だし
通信コストと圧縮コスト、ストレージコストのバランスで結局今はオフラインで色々な規格の動画をストレージに置いておくのが主流だし
2022/12/30(Fri) 11:44 | URL | LGA774 #-[ 編集]
>192812
>192848
でもMeteor Lakeってデスクトップじゃ販売されないんでしょ？発売されないならArc買わないと使う手段がない
モバイルの方はディープ・リンク・テクノロジーでCPU内蔵とArcを同時使用できるっいから、これはこれで有効活用できるんじゃないかな
>192848
でもMeteor Lakeってデスクトップじゃ販売されないんでしょ？発売されないならArc買わないと使う手段がない
モバイルの方はディープ・リンク・テクノロジーでCPU内蔵とArcを同時使用できるっいから、これはこれで有効活用できるんじゃないかな
2022/12/31(Sat) 11:50 | URL | LGA774 #-[ 編集]
本題から外れるけど、H.264はp=0設定で可逆圧縮とかマ？
2022/12/31(Sat) 13:00 | URL | LGA774 #-[ 編集]
今はH.264がようやくかつてのMPEG2の地位を獲得したといったところだと思う
次はAV1でしょうね、力の入れ具合からして
H.266が余程高性能でパテントも緩いならわかりませんが
次はAV1でしょうね、力の入れ具合からして
H.266が余程高性能でパテントも緩いならわかりませんが
2022/12/31(Sat) 13:24 | URL | LGA774 #-[ 編集]
x264なら
qp=0
qpstep=0
qpmin=0
qpmax=0
crf=0
qcomp=1
bframes=0
とかすれば、大体量子化が消えて、ロスレス化するはず
ついでに「keyint=1」にすれば、全フレームがイントラフレームになって、シークもしやすくなる
勿論、圧縮率を度外視するので、ファイルサイズは(非圧縮程ではないにせよ)異常なまでに肥大化するが…
ただ、量子化無しにすると、確か強制的にYUV444ロスレス扱い(H.264でロスレスの規格があるのが確かYUV444のみ)になり、非対応環境が出たり、サーバサイドエンコ後に動画が壊れたりするので、最終生成物の場合には、qp=1やcrf=1で若干の量子化を掛けておいた方が良かったような気もする
特に、サーバサイドエンコが掛かる場合には、基本的にはYUV420(というかNV12)化が必須と言っても過言ではないので
個人的には、NVMe全盛のこの御時世、動画編集中の中間ファイル管理は可能であればロスレスでやって欲しいところ
まぁ、ロスレスならそれ用に「UT Video Codec」とかあるので(原則外部コーデックに対応しない「Davinci Resolve」などを除き)そっち使った方が手軽だとは思うが…
場合によっては、サーバサイドエンコ側が「UT Video Codec」のようなロスレスコーデックに対応している場合もあるので、その場合はサーバサイドエンコ以外での量子化を原則避けられる
ただ、その場合であっても、YUV420での出力は忘れずに
qp=0
qpstep=0
qpmin=0
qpmax=0
crf=0
qcomp=1
bframes=0
とかすれば、大体量子化が消えて、ロスレス化するはず
ついでに「keyint=1」にすれば、全フレームがイントラフレームになって、シークもしやすくなる
勿論、圧縮率を度外視するので、ファイルサイズは(非圧縮程ではないにせよ)異常なまでに肥大化するが…
ただ、量子化無しにすると、確か強制的にYUV444ロスレス扱い(H.264でロスレスの規格があるのが確かYUV444のみ)になり、非対応環境が出たり、サーバサイドエンコ後に動画が壊れたりするので、最終生成物の場合には、qp=1やcrf=1で若干の量子化を掛けておいた方が良かったような気もする
特に、サーバサイドエンコが掛かる場合には、基本的にはYUV420(というかNV12)化が必須と言っても過言ではないので
個人的には、NVMe全盛のこの御時世、動画編集中の中間ファイル管理は可能であればロスレスでやって欲しいところ
まぁ、ロスレスならそれ用に「UT Video Codec」とかあるので(原則外部コーデックに対応しない「Davinci Resolve」などを除き)そっち使った方が手軽だとは思うが…
場合によっては、サーバサイドエンコ側が「UT Video Codec」のようなロスレスコーデックに対応している場合もあるので、その場合はサーバサイドエンコ以外での量子化を原則避けられる
ただ、その場合であっても、YUV420での出力は忘れずに
2022/12/31(Sat) 21:18 | URL | LGA774 #-[ 編集]
>192862
Hyper Encodeは11世代以降ならデスクトップでも対応しているらしいが
SoC側とdGPU側の双方のエンコーダーが対象のコーデックに対応している必要がある
目下のところHyper Encodeが最も威力を発揮しそうなのがHWエンコード必須ともいえるAV1だろうから
dGPUだけでなくSoCのほうもAV1エンコードに対応させるのは大きな意味があるだろうね
もともとIntelデスクトップの次世代は24年になるという話だったのに
23年にRaptorlake Refleshの噂が持ち上がったのもこのへんが関係してたりして？
だとすると仮にRaptorlake Rが本当に出るならエンコーダーもAV1対応になるか？
Hyper Encodeは11世代以降ならデスクトップでも対応しているらしいが
SoC側とdGPU側の双方のエンコーダーが対象のコーデックに対応している必要がある
目下のところHyper Encodeが最も威力を発揮しそうなのがHWエンコード必須ともいえるAV1だろうから
dGPUだけでなくSoCのほうもAV1エンコードに対応させるのは大きな意味があるだろうね
もともとIntelデスクトップの次世代は24年になるという話だったのに
23年にRaptorlake Refleshの噂が持ち上がったのもこのへんが関係してたりして？
だとすると仮にRaptorlake Rが本当に出るならエンコーダーもAV1対応になるか？
2023/01/02(Mon) 10:35 | URL | LGA774 #wLMIWoss[ 編集]
