次世代ビデオコーデック総合スレPart6 【HEVC/VP9/AV1/VVC等】
レス数が1000を超えています。これ以上書き込みはできません。
!extend:checked:vvvvv
!extend:checked:vvvvv
!extend:checked:vvvvv
H.264/AVCの後の様々なビデオコーデック全般について語るスレです。
■対象となる主なビデオコーデック
・H.265/HEVC
・VP9
・AV1(AOMedia Video 1)
・VVC(Versatile Video Coding)
次スレは>>980が宣言してから立ててください。
■前スレ
次世代ビデオコーデック総合スレPart5 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1581244349/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>1
前スレ見れば分かると思うけど、DTV板はデフォルト設定が強制ワッチョイなので
ワッチョイ付ける時はextendコマンドの記述は不要ですよ そうなんだ
どうりでどこのスレ見てもコマンドなかったわけだ
念のためつけといた
ためになった
ありがとう ■各ビデオコーデックの概要や状況（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】ハードウェアエンコーダーを語るスレ4【QSV】
https://mevius.5ch.net/test/read.cgi/avi/1577416553/
↑テンプレここまで 20レスありゃ良いんだっけ
前スレからまんま引っ張ったけど>>19のとこは今は色々変わってるね >>23
スレが立ってから1時間以内に、12に達していれば即死しない もうビデオコーデックはカオスすぎる
どうしてこんなことに… >>25
資本主義を潰せばいいんよ
競争とか頭おかしいと思うマジで
全世界で協力して全ての技術開発やればいいんよ
ただそれだけの話
あ、世界征服してみよっかな? 資本主義でいいけどやりすぎてるから問題なんだろ
ほどほどになるように制限かければいい
貿易の自由化やEUの難民政策とかだってやりすぎるから、反発くらってカオスになっていく 資本主義は金持ちに金が集まるシステムだからなぁ
そりゃ貧富の差は開くだろ >>25
av1は元々vp10だったらしいしvvcも今あるやつの後継だから古いのが消えればすっきりよ そんなにカオスですかね？
むしろ乱立していた時代が終わり、主要ないくつかの勢力に整理されてきた感じだが 動きが今までより早すぎての乱立感はあるよ
今までだとxvidとかdivxの完成が極まったころに次の規格のx264
x264の進化が終わったころに次のhevcだったけど
x265はまだ完成途上 (不安定なところが散見される)なのに次の世代の規格だから xvidやdivxなんて、元から亜流に過ぎなかっただろ >>32
低ビットレートav1は優秀なんだけど、エンコーダーの改良が続いている時点でまだちょっと保存用に使うにはばらつきが気になるな
x265の頃は1クール逐次エンコしてると同じ設定でも進化して、ん？ってなる事が多かったから、再放送待ってやり直したことがあるくらい
サイズで見てるんだろうけど、でも、ｘ265のcrf26はちょっという気はする…
見て捨てじゃないならせめてcrf24は欲しいぉ
まぁx265はサイズ的にはfastestの方が小さいことも多いから何とも言えんが
新しいPC組むタイミング逃してうらやましいだけだったり… >>35
れっきとしたh.263のエンコーダーだぞ
h.264とx264の関係と同じ 263,264,265,266とあるから262もあるの？
と思ったらMPEG-2か、思い出した H.264にもAVCの他にSVC, MVC, MVCDがある
乱立というより用途に応じて様々な種類があるだけ 文字通り乱立してるって言ってるわけじゃないんだけどね >>36
比較する場合、crfを小さくして画質を上げると違いが分からなくなる。(保存用と設定が違う)
画質の差がほぼ無くてファイルサイズも同じぐらいなら、後はエンコード速度勝負になる。
この場合だと処理時間はAV1が1230秒、x265が1708秒で画質とファイルサイズは同じぐらいかな。
半年ぐらい前は同じ設定でAV1はだいぶ遅かったんだけどね。
https://i.imgur.com/PrU5KtN.png
https://i.imgur.com/IQf4sWh.png 開発が停滞気味のx265ぶち抜いて
高速/高画質なav1エンコーダーが爆誕したら面白いな
ネトフリやgoogleが採用してるからvc-1みたいなマイナーで終わらないだろうし YouTubeで使われているだけでメジャーなのでは？
仮にニコニコだけでしか使われていない世界ならマイナーだけど 世界のトラフィックの1割程度のサイトの4K動画のほとんどでしか使われてないからマイナー twitchも1440p120fpsのテストでav1使ってたね
ゲーム向けのとこだから4kよりフレームレート重視 google一社が使ってるだけでメジャーは言い過ぎでは Switchゲーのムービーも標準だとVP9だっけか？
でもそれくらいだな お前らはエロ動画のコーデックが何か理解して見てんのかよw お前はタイトル見て書き込んでるのかとｗ
エロは巨大派閥だったSilverlightが終わってWMV9を卒業できるんだしVC-1飛び越せてよかったじゃないか >>45
>>49
それ面白いと思ってんのお前だけだよ VRの4K-6Kの60-90fpsあたりはH.264まで来てるし、あとは”お客様”のハード&ソフト対応次第だな >>55
コロナの影響が心配だったけどここまでオンスケでこれてるね
一番の問題は標準化の後かもしれんけど ファイナル ドラフト インターナショナル スタンダードの略か ネット配信はAV1に移行したがってる感はあるな
H.265とVP9は結局一部で終わりそう そりゃ誰だってパテントフリーの方がいいに決まってる パテントで稼ぐっていうか
ＨＷで稼ぐついでにパテントが入るじゃないか? パテントは持ってるけど製品やサービスは持ってない企業の方が世の中には多いのだ https://www.reddit.com/r/VVC/
redditにVVCのページができてた
雰囲気的にav1のほうが活気ありそう VVCはもうライセンスがどうなるのか決まっているのか？ VVCは2大パテントプールが悪魔合体してる最中だからそれが終わってからじゃね h.264みたいにストリーミングからは取らなくなったんじゃなかった?
それと書き忘れてたけどVVCのエンコーダーができたみたい
https://github.com/fraunhoferhhi/vvenc ブルーレイのライブディスク（1時間30分程）AV1でエンコードしてみた。24時間やったけど、終わる気配ないからやめた。ライゼン2600です。めっちゃ重かった。 zen1はAVX2が少し遅いからな
zen2か11月に出る3にしないとキツイだろ zen3で試してみたいなあ
自分が買えるのは5800Xまでだけど 8コアでだめならzen3化しても大差なさそう
せめて5900xでギリギリ？ 68だけど、3950xでもやってみたけど、10分くらい監視してあとで見に行ったら電源落ちてました。普段はコアの半分くらい遊んでるのに全コア100％で温度は70度ちょい。最終的には何度で落ちたかは分からないけど、ヤバいと思って中止したよ。そのあと、2600でという流れでした。 av1はメモリ食うってのがね
もう下がらないだろうと16GB (8GB x2)買っちゃたから
もっと控えめになってくれたらいいんだけど intelかnvidiaのハードエンコーダーを待つしかないな まぁハードだとx265並みの圧縮率に収まるだろうけど 10年後くらいには可能なのでは？
x264使ってた次期出始めのx265使ったら悲鳴上げた記憶ある。
x265ある時期から軽くなったから一概に言えんけど。 遅くとも再来年にはAV1のハードウェアエンコーダー載るでしょ
Intelは劣勢だから必死
NVIDIAは改良熱心だから載る可能性高い
AMDは載ってもクオリティ期待出来ず AV1のHWエンコーダって用途が分からない
HWだからどうせクオリティは低いし
無駄に計算量が多いのに低品質なエンコードにしかならなそう hwエンコはリアルタイムエンコードが主な用途だろうし
zooma会議とかで使えそう x265とav1たいして画質に差が無いのが一番問題だわ
時間かけるほどのメリットが無い。 AOMメンバーからしたら無料で使えるhevcでも十分美味しい
最終的にはVVC以上を達成できないとお釣りはこないが 正直殆ど画質メリット無いのに負荷だけは何倍にもなるとかユーザからしたらアホらしいことこの上ないよな
パテントトロールは死んでくれ かかる時間はもうエンコード技術の限界なんじゃないの
VVCも負荷すごいよね >>82
パテントフリーか否かの差は比べ物にならないくらいに大きい テストしづらくなるなぁ…
・GitHub、YouTube動画をダウンロードする「youtube-dl」プロジェクトを削除
https://japan.cnet.com/article/35161461/ ええええええ？？？？！！！！
めっちゃ使ってるのに！ 流石にこれは物議を醸して撤回されるだろ
このまま押し通したら流石にMSゴミすぎるわ さっそく動きが
・「GitHubに削除されたYouTube動画ダウンローダーは著作権侵害用ツールではない」とオープンソース団体やジャーナリストが反発
https://gigazine.net/news/20201027-youtube-dl-journalist-tool/ https://yt-dl.org/
https://youtube-dl.org/
一応DLできそうなミラーはあるが本物かは、安全かは知らんから自己責任で
GitLabにソースがミラーされてるから、心配ならここから自ビルドした方がいいかも
https://gitlab.com/ytdl-org/youtube-dl よくよく考えたら、GitHubから消えただけだし、
既に本体持ってる人は`youtube-dl -U`コマンドで本体を直接アップデートして使い続ければ良いだけか。
あと>>90が貼ってくれたGitLabのREADMEに、バイナリダウンロード用のURL書いてあった。
ttps://yt-dl.org/latest/youtube-dl.exe
youtube-dlはpythonで書かれてるから`pip install`でも良いな。
ttps://pypi.org/project/youtube_dl/ 安価ミスった
〇 >>92
× >>90
すまんこ ヘタに本物か分からないミラーから落とすよりpipで入れる方が安全かもな
あっちは前からずっと本家 Intel、デスクトップ向け第11世代Core「Rocket Lake-S」の詳細を発表
https://pc.watch.impress.co.jp/docs/news/1286191.html
簡易的だがAV1ハードエンコできるのかな？ > 4K60 10bit 4:2:0 AV1
ええやん AV1に新しく対応しているって書き方がなんとも曖昧だな。ハードウェアエンコできるのか出来ないのか… じゃあこれでついにAV1がHWエンコで出来るようになるのか。もっと先になると思ってたから驚いた
問題は速度と圧縮率だけどね 既に技術はできてるけど戦略上搭載を見送ったのか
単にタイプミスで載っただけか
前者ならdgpuでの販売狙い？ 順当に考えると実装できてないと考えたほうが自然かと intel焦りすぎだろ
5カ月先の製品ちら見せなのに確認すらしてないのか 資料作るのは営業部みたいなとこだから、意思の疎通が出来てないとよく食い違う AV1HWエンコードできるってまじかよ！やったぜ
Intel「うっそでーす」
あまりにも酷い流れでわらたｗ だいたいいつもデコードが先で翌年のでエンコードできるようになるパターンがほとんどじゃない？ Xeonで可能な話を載せてしまって削ったとかいうオチじゃないのか？ SkylakeだつたかKabyだったか忘れたけど
VP9のエンコできますって言っててフタをあけてみたらXeonしかできなかった、なんてのもあった気がする
持ってたわけじゃないから、はっきり覚えてないけど A's Video Converter
https://bluesky-soft.com/AsVideoConv.html
Version 7.14.0 (2020/10/31)
Intel Hybrid AV1 Encoderを利用したAV1エンコードに対応
AMD Fluid Motion Videoを利用した25p->62.5p変換に対応
AMD Fluid Motion Video設定に「レート変換」を追加
「全てのオーディオストリームを変換する」設定を追加
細かな変更と修正
Intel Hybrid AV1 Encoderってコメットちゃんでもできるの？ VP8世代と変わらない使い方ならHWがなければソフトでやるっていう…それがハイブリッド >>123
av1ソフトエンコに対応したフリーソフトがチラホラ出てきてるのね まぁ多コアcpuでないとおっそいだろうけど普及が進むといいな >>124
なるほど、現状ではソフトエンコなのね。
>>125
rigaya氏はAviutlプラグイン作っていますね。 libaom-av1だと12コアの3900XじゃあまりCPU使ってくれないから、
分割エンコードやらないと100%貼り付きにならない。
はたして普通に多コア100%使い切れるようになる日は来るのだろうか・・・
https://i.imgur.com/k7yUWID.png 今更だけど無料のデバイス製造元からのhevcビデオ拡張って購入できなくなったね SVT-AV1を使ってRyzen 9 3950Xでエンコしてみたけど、3700Xの時のようにフルコア使いまくりにはならなかった。
x264やx265でもそうだから仕方ないや。 https://openbenchmarking.org/
Phoronixが運営してるベンチマーク結果共有コミニティに
Zen3のAV1エンコーダー系の結果もあるよ >>130
今年の6月ぐらいにはストア検索で出てこなかったけど
直リン探して飛んだらインストールできたよ 元々それ確かSurface用かなんかだったし
ユーザー以外が使えてた状況がおかしかったわけで サーフェス用と言ってもサーフェスだって中身は普通のPCなわけで >>136
元々有料のとSurface用のと両方あったんだよ
Surfaceのが非Surfaceユーザーがアクセスできた状況自体がおかしかったんだから、それが本来の姿に戻っただけ
購入はできるよ
https://www.microsoft.com/ja-jp/p/hevc-ビデオ拡張機能/9nmzlz57r3t7 スマホの専ブラで見ると変なところで改行入ってるかもしれないが、1行で H.265コーデック以降、インターレース解除をどうするかが懸案のままであるが、
ようやく一条の光が差すのだろうか？
・ブラックマジックデザイン、HDRグレーディングやAIベースのMagic Maskなど300種類以上の新機能搭載「DaVinci Resolve 17」を発表
https://www.pronews.jp/news/202011100930172850.html
「インターレースのタイムラインのネイティブ処理がサポートされたことで、同方式の納品用ファイルにおいて、より高品質の合成およびタイトル作成が可能になった。
高品質のDaVinci Neural Engineデインターレース機能は、フィールド間の動きを分析し、プログレッシブ方式のフレームを再構築する。リアルタイムの3:2プルダウン除去も可能としている。」
続く 上記の機能は、従来下記のTeranex Standards Convertersに搭載の「PixelMotionデインターレースアルゴリズム」で使える技術だったものと同等のものか？
これがソフトウェアだけで利用できるようになるのであれば、インターレース解除のためだけにTeranex Standards Convertersを購入する必要はなくなるのか？
・Teranex Standards Converters
https://www.blackmagicdesign.com/jp/products/teranex/conversions
果たして実力や如何に？ めっちゃ重そうだけどfpsどのくらいになるんだろ？ https://www.phoronix.com/scan.php?page=news_item&;px=Google-Experimental-WebP2
WebP2だってさ
これでAVIFが普及する可能性は無くなったな >>143
拡張子どうなるんだ？単純に.webp2？ また世迷言を…
いまさら静止画の新しいフォーマットなんていらねぇだろ 動画に比べたら大したことないけどやっぱ通信量減らしたいんじゃない JPEGみたいに30年近く使われるフォーマットが作られるのはいつになるやら… >>143
>>圧縮効率の改善に重点を置いています。目標は、元のWebP設計よりも約30％良くなることですが、AVIFよりも約20％悪くなります。
AVIFよりも約20％悪くなります。
AVIFよりも約20％悪くなります。
AVIFよりも約20％悪くなります。
AVIFよりも約20％悪くなります。 現状のAVIFは圧縮率はかなりのものなんだけど設定頑張っても結構潰れてのっぺりするんだよな
せめてJPEGと同等の画質はほしい 画像なんてそんなに圧縮率変わらんのだし
まぁまぁ効率よくて圧縮速度/負荷とデコード速度/負荷が低いのが流行ってくれ >>152
hevcとか使うと分かるけど
荒隠しはしょせん荒隠しなんだよな のっぺりを解決するには機械学習でディティール復元するしかないのだろうか 圧縮する以上、情報量は減るのだから、のっぺりするのはやむを得ないだろう
超解像的な復元を前提にした、超解像処理用の参照情報みたいなのを埋め込んで
復元の手助けをするような処理を圧縮時にしておくしかないのでは AVIFの画質を見るとその動画版たる（成り立ちとしては逆だが）AV1の画質がいまいち振るわないというのも
よくわかる気がする
そして激重
まだまだ先は長そう フォト有料化で無圧縮から高画質に再エンコするのって
新規格になるまでギリギリまで待ったほうがいいの？ >>159
新規格とかエンコード遅すぎて一般人には扱えんよ
H.265で十分 再生できるデバイスが限られるコーデックは、使い勝手が悪くなりがち いやグーグルフォトの再圧縮はサーバー側でやるやつだよ 誰かapple armチップでAV1動画を再生できるか試してきてくれ
再生できるのかな？ jpegは10bit,12bitにHDR対応さえしてくれたらあとは今のままでもいいんだけどな その辺対応したのがjpeg xlじゃないかな
Google関わってるみたいだしwebp2作るよりそっち流行らせて欲しいんだけどなあ >>164
デコードだけならソフトウェアでも問題なくできる JPEG XLなんだかすごそうやな
エンコード、デコード速度がJPEG並みとか >>170
それデコード速度の比較じゃなくて何バイトダウンロードしたら表示出来るかの比較だな
他の画像形式はダウンロードしながら適宜表示出来るけどAVIFは全部読み込まないと表示出来ないっぽい まずchromiumとFirefoxに対応してもらわんとな 画像の新規格って色々出たけど結局Webではjpgとgifなんだよな pngぇ…
フレーム間圧縮のないアニメーションgifはあまりにも非効率なのにね
再圧縮しようにも256色に落とされててディザリングが邪魔をするという XLはアニメーション対応してるらしいしその辺と入れ替わってくれたら良いな 何でもかんでも馬鹿みたいにjpegにしてるサイトも結構ある
ソースによってはpngのほうが縮む上に可逆だからキレイなのに >>175
普通の動画には全く向かないけど、PC画面をスクリーンキャストする時とか、マウスカーソルだけ動いてる時はその部分しか画像データが無かったりするし、動いてない部分を抜きにして圧縮されやすくするとかしている Jpegは今でも更新されてる
ソース
https://ijg.org/ JPEG XLが普及したらインターネット名物の転載され過ぎてガビガビに劣化した画像文化が途絶えてしまうな 同人誌をwebpにしてるのにjpeg XLの方がいいのか？
流石にキレそう >>182
性能いいけどまだ出たばっかだからそんなすぐには切り替えなくていいと思うよ 現状のwebp使うならmozjpegでもいいんだよな Apple M1ってVP9のハードウェアデコード対応してるのかな VP9はもう開発終わっているし
その辺はもうソフトデコードで良いのでは。 デコードだけならGPU支援なんて基本不要でしょ
8KのAV1なら支援ないとガックガクまねと モバイルならCPU再生とGPU再生じゃバッテリーにかかわるからデコードでもあるに越したことはない
mpeg2くらい軽いならどうでもいいが >>186
どういうこと？
開発終わるなんてことあるのか まず開発が終わったって言ってる意味が分からんな
libvpxの開発の事を言っているのか？ ・西川和久の不定期コラム
M1版Mac mini購入記。驚愕のパフォーマンスと、CrossOver 20で秀丸の動作も確認
https://pc.watch.impress.co.jp/docs/column/nishikawa/1290745.html
CrossOver 20を使って、M1チップ搭載のMacでAviUtlとかx265を動かしたりもできるのだろうか？ aviutlはともかくx265はネイティブでビルドできないか？ amdの5nm阻止がなければzen3と並んだくらいだと思うが、スレ違いだな x265じゃなくて別のH.265エンコーダーだけど別にそんなに速くない
https://www.phoronix.com/scan.php?page=article&;item=apple-mac-m1&num=4 エンコの最後は物量がモノをいう
BullのXOPもエンコに効果的と言われてたけど効果は微少だったしな ブルドーザーさんはゲームするとZenシリーズ相手に余裕の周回遅れだけどエンコだけ見ると
影すら踏めないまでも周回遅れにはならないくらいのパフォーマンスは出るイメージ https://i.imgur.com/XxtbDE7.jpg
６年ぶりにPC買い替えたいけどAV1かH266に対応してるGPUを買えばええんかのう >>199
今は時期が悪い。CPUはrocketが出るかzen3が値下がりするまで待て。グラボはRTX3000かRX6000が出揃うまで待て。
by時期が悪いおじさん Radeonを待つ意味は無いだろ
VCE使い物にならんし >>202
確かにゲームじゃなくて動画用だったら待つ意味は薄いな。 As Video Encoderで使えるMicrisoft H.265 Encoderってハードウェアエンコーダーなんだな
ソフトウェアエンコーダーだと思ってエンコード開始したら114fpsも出るので
CPUエンコじゃそんな速さでエンコード出来るわけないから面食らった MacBookPRO 2018の QuickTimeで興味本位でHEVC書き出しやったんだけど
アホみたいに早くてびっくりしたわ。
ビットレートとか調整出来ないからあまり実用的では無いんだけど
T2がハードエンコーダーも入ってると知らんかった。 SVT-AV1 v0.8.6来てるぞ
https://github.com/AOMediaCodec/SVT-AV1/releases/tag/v0.8.6
>Encoder
> Further quality-speed tradeoffs tuning for VOD use cases
> Improved TPL support within 1-pass and 2-pass CRF moode
> Continued non-optimized support for 2pass VBR and CRF
> Align kernel nomenclature to prefix svt_aom for kernels brough from libaom to avoid symbol conflicts Apple、iOS 14/macOS 11 Big Surのデフォルトブラウザ「Safari 14」がWebPフォーマットをサポートしたことで、App Storeのスクリーンショットを「WebP」に変更。
https://applech2.com/archives/20201129-apple-adopt-webp-in-app-store.html はよwebpでもHEIFでも何でもいいからデジカメに実装してくれ α7SIIIとかEOS R5、R6、1DXMarkIIIなんかはHEIFに対応してる HEIF, AVIFは動画エンコード回路を使い回せるのが利点？ >>216
そうかな
androidのheifの保存処理の実装コード見たら、おもいっきり動画のエンコーダ利用してた デジカメの連写を考えると、一定の時間で圧縮出来るJPEGになってしまう
その牙城を崩すのは容易じゃない
そう考えると、JPEGから再圧縮が出来るJPEG XLが本命か Google純正スマホ Pixel + 標準添付カメラアプリ
保存ファイル形式
静止画 JPEG, RAW
動画 H.264/AVC, H265/HEVC Snapdragon888にAV1デコード入らなかったね
MediaTekと違ってQualcommはまだやる気ないらしい YouTubeですら一部の人気動画？をAV1化している程度だし
そもそも配信で普及しているのかな。 モバイルSoCメーカーは殆どHEVCのパテントホルダーだからな
AppleはMPEG LA
QualcommはVelos media
Samsung,HuaweiはHEVC Advance
MediaTekが一縷の希望 VP9はHEVCに負けた感あるけど(使っている人ごめん、争うつもりは無い)
次世代こそAV1にならないのかね。流石に配信側が参加しているから今度こそという感じではあるけど。
OGM信者とか今何を思うのだろう。もう死んでるかな。 vp9は規格作る側がごたごたしてて出遅れた感があったからね
今回は同時というかリードしてる感があるけど、配信業者特化なのが吉とでるか凶と出るか HEVCは現時点ではバランス的にも最強クラスだと思うんだがなんでこんなことに
そりゃまあ儲けたいでござるって気持ちはよく分かるんだけどさ >>225
スレタイにVP9が残ってる間はむきになる人はいそうだ
消したら消したで騒ぎそうだが、hevcも次世代というほど大きく変わるほどの期待はもうないしな AV2とかH.267とかもう構想始まってたりするんだろうか 将来的には動画サイトはav1で個人用途とかテレビはVVCってなるんだろか VVCをエンコードできるx266がいつ頃、実用になるのかが気になるところ
対してAV1はフリーで利用できるエンコーダーを継続して出し続けてくれるのかどうか自体がよくわからん
どちらにせよ、ハードウェアエンコーダーが出てこないと普及しづらいのは確か HEVCはなぁ・・・
今後ブラウザで採用されて一般動画配信サイトのデファクトスタンダードになる・・・
という将来が全く見えない・・・ ハードウェアエンコーダーは時間かかりそうだけど次のnvidiaのGPUには載ってるといいなあ、hopperだっけ
>>232
av2は始まってるって噂はあった記憶 av2もh.267もドロドロにうごめいているだろう
採用されて後出しで発動できるパテント爆弾仕込むのに >>232
H.267はAIを使った処理が検討されている模様 AIは画像処理が得意分野だからコーデックに上手く組み込めたらかなり良さそう 元が像ではなくなるけど、デコーダーに入れたら８Kとか力任せに圧縮しなくていい時代が来るのかも
AIというとこういう技術しか思いつかない素人だが、実用化されてる技術って事で
https://topazlabs.com/video-enhance-ai/ 元々映像の圧縮って少ないヒントで元画像に近い予測画像を作って、そこから元画像との差分を出来る限り元に戻すって手順だから、
予測画像作るところにAI使うのは従来の延長であって問題ないのでは
同じ入力に対して必ず同じ結果になることだけ保証されてれば オーディオコーデックで悪いが
MPEG4-ALSって開発止まってる？ AIが画像を生成しても、相手にも同じAIがないと少ないデータをやり取りすることは出来ないけど、そこまで一般的になるとは思えない
今のAIの使い方は、動き補償を高速に行ったり精度を上げる事に使われてると思う
結果的に圧縮率は上がるだろう >>243
10年ぶりくらいににきいたけど何に使うの
CDのリッピング？
多分とっくに終わっているかと。 >>244
いや今のコーデックが数値演算を厳密に定義しているように、
演算精度やニューラルネットの構造、学習結果の提供方法(規格に含むか、ストリームに含むか)などを決めて、
必要なのは演算能力だけというようにするだろう >>245
32bit floatのwavをエンコするのに
次世代放送で注目されているコーデックなのに開発が止まって、エンコーダーが一つしかないのも勿体ない >>243
BS4K放送のオプション規格に盛り込まれて入るが、NHKは今のところ使う気がない
来年3月から始まるWOWOWが音楽番組などの一部で導入予定
FLACが扱えない32bit音源も扱えるので、FLACの置き換えで普及してほしいと個人的には思う
ただし、コーデックそのものが何か進化しているかは不明 ffmpegでALSのエンコードができないのは何故？
仕様やソースコードが完全に公開されていない(一部非公開)から？
それともライセンスの問題？ 音声に32bitも使っても違いが分かる男がどれだけ居ることやら… 音声の32bit floatはリスナーが楽しんだり聴き比べるための高品位フォーマットとは違う
原音の情報を可能な限り保持したままクリエイティブ作業をするためのもの
画像で考えるとわかりやすい
ある図形を数回にわたり変形・拡大縮小・回転する作業を経て元の図形に戻るような操作をしても
拡大して細部を比較すると元の図形と完全に一致するデータは得られない
数値の僅かな誤差を丸める処理が積み重なり情報が損失してデータの不一致が発生している
画像が十分に細密であれば一連の操作のプロセスを経ても情報の欠落は少なく精度が保たれる
言うなれば32bit floatは従来よりも膨大な情報量を受け入れる空間を拡張したフォーマット
音楽の制作やその他のサウンド編集でも様々な演算が施されるから
大きなデータ量で精度を担保できれば加工に伴う望ましくない情報の欠損を抑えることができる
普通に聴くだけならもっと経済性に優れたフォーマットで十分 じゃあなんでWOWOWはそんな無意味な事をするんだ WOWOWは別に32bit floatが必要なんじゃなくてISOで規格化された可逆圧縮フォーマットが欲しいだけでは じゃあ64bit double doubleとかも出てくるのかな？ 話把握せず書くけど
可逆にするためには32bit精度が必要だったんでは 32bit floatは、映像編集に使うRAWみたいな存在だよ
直接視聴する目的で使うフォーマットではないよ
32bit floatで収録しておけば、編集時に弄くり倒しても劣化が気にならない >>248
>>253
NHKはともかくWOWOWがやるって事は
4K対応のレコーダーでダビングした4K BDAVにもMPEG-4 ALSのまま収録されるのかな？
BDAVのディスクの規格がMPEG-4 ALSに対応してるなら4Kディスクの自作の可能性が広がるし
人柱になる価値あるかな >>258
Panasonicは対応してる
SONYとSHARPは非対応
このことに気づいてる人はPanasonicしか買わない 昨日までAVIF画像ファイルをWIN10標準のペイントソフトでJPG画像に変えることができたのに
今日になったら出来なくなってる・・なんで？ >>262
違う。普通のペイント
ホント昨日までなんの問題もなく出来てたんだけど今朝になったらできなくなって
しかもこの方法（ペイントで.avifをjpgに変える）を紹介してたブログも消えた。 そもそもavifの画像ファイルをJPGに変換するという簡単なことを
オンラインでしか出来ないのがおかしい PhotoshopのCSシリーズでも使えるプラグイン開発してほしい… >>266
Windows版のImageMagickで変換できるのでは
>magick image.avif image.jpg
とか avif流行るのかね
すぐにjpeg XLが来るから微妙な時期だと思うが jpeg png gif で一般向け画像フォーマットはもう終わりかと思ったのに。webpはよく食い込んだよ。
後続フォーマットも同じく茨の道を進むのか、webpの舗装した道を使って結構早く普及するのか、どっちなんだろ 回線費用を減らしたかったんだろう
あとChromeブラウザの影響力 jpeg→jpeg XL
と、すんなり移行すればよいのだが
正直、そろそろ静止画については次期デファクトスタンダードフォーマットを、そろそろ絞り込んでいい頃合いではあるし、
逆に一度絞り込んだら、10年は変えないくらいのつもりで規格策定をしてもらいたい 必要とされる解像度と最低ラインの端末性能が今後どうなってくか分からんし
状況に応じた選択ができる余地も欲しいな
いきなり内部分裂はじめてhevcするのも怖いし jpeg xlはリファレンス実装はできあがってるのかも知れんが､
目標通りの性能が出てるかが問題。そうでなければjpegと互換性あろうが使いたくないな
負荷がjpeg並みに軽い
jpegより圧縮率よくてavifより悪い(バンディングが出にくい)
だっけ？ >>272
今後20年30年くらいの考えだと思うよ性能的に
ぶっちゃけ個人利用だけならjpegでいいやって人多そうだから完成したらブラウザとか色んなとこが対応して多少強引にでも流行らせて欲しいなあ 現状のWebPだってお互いに容量を削りまくったらようやっとmozjpegを上回れる程度で
ある程度容量振れる状況だとmozjpegに画質で負けるからな
そして重さでは比べるべくもないという
正直JpegXLが流行る前により練り込まれたJpeg変換が出てきちゃいそうな可能性すら
そしてJpeg2000さんの元へ逝ってしまうのだ・・・ jpeg2000は一般に広まらなかったけど医療で生き残れたからまだマシな方 jpeg2000はキチガイが普及の邪魔をしてたからな >>281
VVCとAV1、結構いい勝負に見えなくもないが、低ビットレート時の対応はVVCが一歩リードか VVCがどれだけ優秀でもライセンスがゴミなら流行らん >>281
VVCはエンコードもデコードもAV1より重いのかよ
チューニングが進んでないだけかもしれないが、地デジには向かないんじゃないか？ >>282
デフォで10bit深度だからそのへんが好影響なのかも
逆にav1はなぜ8bitなんだろって思わなくもない そういやmozjpegはまだメンテ続いてるっぽいけどGuetzliはどうなったんだろうか
懸賞サイトによっちゃGuetzliのが良いとか言ってるとこ結構あった気がするけど >>289
どっちもJPEGを最適化(圧縮)するためのエンコーダだと思ってたけど違うの？ Guetzliの開発者はJPEG XLの元になったPikを開発してる(た)はず 開発者曰くguetzliは実用的なツールではなく、概念実証として設計されたものらしい は、はやくクソゴミ回線でも高画質な画像が見れる時代に… クソゴミ回線使うような奴はクソゴミスペックのマシンだろうからデコード出来ないだろ 今時の通信機器で画像を見るのに苦労するってどうなってんだよw XnConvert使ってるんだけどいつになったらmozjpeg対応してくれるんだろう 対応しないでしょ
mozjpegなくてもjpg出力できるんだから いやAV1はもう出てるぞ。エンコ速度が遅いから相当ハイスペPC持ってないと実用には耐えないが
んでVVCとAV1のどっちが優秀かってのはまだいまいち分からん Intelが春頃に出す新しいCPUがAV1のハードウェアエンコードに対応しているので楽しみだね >>305
世代が違うから比較対象にならない
>>306
結局誤報じゃなかったっけ? いつもデコードのみ最初に実装して
次の世代でエンコード実装のパターンが多いから誤報でしょ
そのうちVVCとか載ったりすんのかな >>306
>>100,103,105でスライドのミスだと判明してる VVC載ってもまともな画質になるのは数年後になると予想 nvidiaがhopperあたりでav1かvvcのハードエンコ対応してほしいけど2年で出来るかな googleとかav1の金余り組が
HWエンコのIPも整備して無償提供すれば、一般での大勢は一気に決まりそうな予感 Extreme compression of Video with VP9 and AV1 (webm) using ffmpeg
https://www.draketo.de/software/ffmpeg-compression-vp9-av1.html ExtremeなCompressionは結構なんだけど
10コア4GHzのPCフル稼働させて
1分エンコするのに1日ってどうなのw そう思うと、幾らじゃぶじゃぶとは言えネトフリのAV1対応ってすごいよな ソシオネクストがAWSのFPGAインスタンスでAV1のリアルタイムエンコードやったぐらいなんだし
ネトフリだって同じようなことしてるでしょ libaomのマルチスレッド処理が改善される日は来るのだろうか ・見るに堪えない。Arm版Windowsのx64エミュレーション速度
https://smhn.info/202012-windows-on-arm-x64
記事の中でM1 MacでHandbrakeを使ったエンコードテストを行っているが、M1 Macでも事実上、x265を利用できるわけか 世界初 最新の映像符号化方式H.266|VVC対応のリアルタイムコーデックを用いた4Kライブ伝送の実証実験に成功
https://www.kddi-research.jp/newsrelease/2020/122301.html 30MbpsというとH.264でのFHDがそのぐらいだっけ？ 4Kで30Mも使うなら266は期待したほどでは無かったのかな 30MbpsっていうのはBS4KのHEVCでの話に読めるが >>324
「例えば2018年から開始されている高度BSでの新4K/8K衛星放送では国際標準符号化方式であるH.265|HEVCが利用されており、もともと約7.5Gbps（Gigabit per second）必要とされる4K映像を30Mbps程度にまで圧縮して伝送しています。」
あ、ほんとだ、すまん DeepMind、ルールを教えなくても「パックマン」などでハイスコアを出せるAIシステム「MuZero」
https://www.itmedia.co.jp/news/articles/2012/24/news090.html
>DeepMindの主任研究科学者、デビッド・シルバー博士は英BBCに対し、MuZeroを新たな動画圧縮技術の開発に応用していると語った。
>「ネット上のデータトラフィックの多くを占める動画を効果的に圧縮できれば、大幅なコスト削減が可能だ」と同氏は語り、
>来年（YouTubeを傘下に持つ）Googleが具体的な発表をすると予告した。 うむ気になる
動き検索とかならx265とかにも移植されるといいな GoogleってことはAV1エンコーダに搭載するだろうな オープンソースだから移植できると思ってたけど特許問題は別か >>334
ネット全体の15%で動画ストリーミングの範囲だと26.6%くらいのネトフリから計算したらネット全体での動画の割合は56%くらい？ やっぱ動画の占める割合すごいんだなぁ
情報ありがとう 昔はtorrentが30%も占めていたんだけどね
ストリーミングの時代になって変わったな You Tubeで1080の動画は4〜5Mbpsだからな
そんなもんを何億ファイルもストリーミングするんだから回線圧迫するわな やっぱり動画は電波で放送するのが最も効率的だしギガも減らない >>341
ニコ生とYoutube LiveとTwitchを全部地上波にぶち込めば完璧 live系をインターネット経由で視聴するとかホント馬鹿げてる
頭の良い奴が何かうまい方法を考えるべきだな なによりも向いてるように思えるが・・
むしろ電波放送で双方向データ通信とか不向きすぎ みんな同じ動画を見るなら放送が最強
それぞれが別々の動画を見るなら個別配信出来るインターネットが最強 ニコニコはコメント流す機能で特許取ってるから他の動画サイトでは使えないって話だったが
もう15年経ってるし失効してると思うんだがな
You Tubeが実装してくれんかな マルチキャストという技術が有ったが、使われてる気がしない
プライバシー的な問題が有るとか言ってたが良く分からん
マルチキャストが使われれば、live系の動画の帯域は激減させられるだろうが AkamaiなどののCDNサービスが世界中のISP内に設置した
中継サーバーで帯域を節約してるよ 特許は出願から20年だろう。医薬品業界は50年くらい延ばしたいみたいだな。 >>353
いやなら切ればええよ
選択肢は多い方がええ >>352
マジかよ
ちゃんと使われてるなら良かった なるほと…特に大きなアップデートやらはないか
しばらく待つか ついにモバイル環境でMediaTekの後に続くところが出たのか 音声コーデックのほうだが、未だに旧アプリのほうが高機能って、MSのやる気のなさには呆れるしかないな
・「Windows Media Player」がFLAC/ALACに対応していたって知ってました？
再生だけでなく、エンコードもサポート
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1300/006/amp.index.html?__twitter_impression=true こんなもんWindows 10が出た当初からサポートされてたぞ
最近Windows使い始めたライターが書いてんのかな >>365
この人は2010年の記事があったしそれはない 少し話題が違うけど
画像はwebpの勝利！
主要ブラウザは対応した
https://caniuse.com/webp
avifも時間の問題
実際JPGより半分かそれ以下に収まるのはすごい
https://squoosh.app/ ちなみにGoogleはwebpの後継webp2(wp2)を開発してるみたいだけど、avifとの関係に詳しい人いたら教えて
なんでwebp2？意味分かんない >>368
Googleの敵はGoogleなんだよな
Googleは競合することに何もペナルティーが無いようだ
色んな分野で競合している 静止画像はJPEG XLが本命だと思うけどまだわからんな 現状のAVIFは確かにめっちゃ縮むけどめっちゃのっぺりしちゃうんだよな
重さも桁違いだし少なくとも今の性能じゃすべての画像フォーマットを置き換えるのは無理そう
そこでwebp2なんだろうけど現状のwebpもかなり高圧縮設定にならないとjpegに対して重さに比して
大きな優位があるわけでもないんだよな ちなみにJPEG XLの基礎技術もGoogle製だ
やっぱりJPEG XLがデファクトスタンダードになって欲しい avifってサムネイルくらいしか使いみちなさそう
データ量減るけど画質落ちますって言われても、
そりゃ画質落としていいならいくらでも減らせるでしょうよとしか思えない そうかね？
jpegなんかはある程度までいくといくら画質を下げてもデータサイズ減らなくなる avif、同じくらいの圧縮率なら画質は上がるんではないの？画質が悪くなりすぎるのは圧縮率の設定なのでは、、、 JPEG XLの基礎技術がGoogle製やからいうたところで
所詮はGoogle PIKにCloudinary FUIFを組み合わせとるだけやからね
目標軸を見るにWEBP2がデファクトになると思うよ
それが何年先のことかは知らんけども jpegから移行しやすくてデコード速度も変わらないからjpeg xlでさっさとまとめて欲しいんだけどなあ プログレッシブ画像を頭から数%だけロードして、
サムネや中サイズ画像として機能させられるブラウザ機能なりJSなりがあれば
Webサイトはサムネ・中サイズ画像を用意する必要がなくなるから
プログレッシブ対応のJPEG XLが一気に普及すると思うんだけどな
というかそういう機能ってないの？俺ごときが思いつけるんだから
Webの根幹に関わるプログラマーも当然思いつける機能だと思うんだけど それが所謂レスポンシブウェブデザインだろ
https://jpeg.org/jpegxl/
>Overview of new JPEG XL image standard - designed with responsive web design in mind, so that content renders well on a wide range of devices >>378
20年前ならともかく今1MB以下のデータ量なんて味噌っかすだから需要ない >>378
jpeg内にサムネイル格納できるでしょ
ブラウザ側がそれを使わないって事は意味ないんだよ avifは個人用途の使い所少なそうだけど
avifsはgifとwebmに取って代わることを期待してる >>382
端末側か事業者側かで話は変わると思うけど
数GBの動画配信に比べたら空気みたいなもんでしょ 君の持論は分かったよ。水かけになってるからその辺で。 Chromeのフラグ眺めてたらEnable AVIF image formatがあった
デフォはEnableなのかDisableなのかよーわからんけど >>387
Chrome 85以降はデフォルトでAVIFサポート有効だよ JPEG XLはwikipediaに
> The file format (bitstream) is frozen on December 25, 2020, meaning that the format is now guaranteed to be decodable by future releases.
だってさ
フォーマットが決まったなら、リリースしたも同然か？ 現状のJPEG2000、JPEG XR、WEBPみたいなもんで
JPEG XLがリリースされたところで誰が使うんだろうねって疑問しかない
WEBP2はGoogleが自社サービスに使ってさらなるトラフィック削減を目指すって目標があるわけで
フォーマットを策定しただけでは意味ないよね webpは普通に使われてるが
主要ブラウザが対応したら利用はすぐ広がる >>391
jpeg xlの目標はjpegとgifとpngの代わり jpeg xlはエンコードがjpeg並みに軽いから期待
CPUエンコード余裕ってことで
で、画質はよくて、バンディングとかいうの出にくいらしい スマホカメラやデジカメのデフォルト保存形式になったら、自然に普及する
軽いなら期待できる デジカメは普及したものを使うだけでしょ
スマホも同じ スマホ単体でどうというよりクラウド・サービス側が使えば自然と割合は増えそう
だけど画像を保存じゃなくスクショで保存という使われ方してるから意味なしかも 普通の人はわざわざ再変換なんてしない
スマホで撮ったままアップするからJPEGが無くならない ＞主要ブラウザが採用したら利用はすぐ広がる
＞スマホカメラやデジカメのデフォルト保存形式になったら、自然に普及する
JPEG2000やJPEG XRでも同じ事を聞いたけど、さぞかし利用が広まって自然に普及してるんだろうなぁ
ISOで標準化されたものが普及するわけではないし
Googleが自社サービスで採用した独自規格がデファクトスタンダードになることもある
JPEG XLに夢を見すぎなんだよ
>>393
JPEGとGIFとPNGの代わりなんだね、凄いね
それでどこで使われるの？ jpeg XLはjpeg2000、XRと同じ ってことが言いたかったのかな XLは特許関係クリアなの？
無料なら普及するかもしれないけど JPEG 2000とJPEG XRはISO/IECの国際標準規格だし、JPEG XLもISO/IEC 18181で国際標準になるけど
ISO/IECの国際標準規格＝事実上の標準ではないんだよ
前々からJPEG XLを推してる人がいるけど、そのJPEG XLがどこで求められてる規格のか答えられてないじゃん
主要ブラウザが対応したら利用はすぐ広がるだとか、スマホカメラやデジカメのデフォルト保存形式になれば自然に普及するだとか願望しか見かけないんだよね
結局はJPEG 2000、JPEG XRではなくWEBPが主要ブラウザで事実上の標準となったのを繰り返してるだけ JPEG XLはWebPみたいに配信側は使うだろうけど
ユーザー側で使われることは殆ど無いと思う > スマホカメラやデジカメのデフォルト保存形式になれば自然に普及する
これを否定する理由は、デフォルト保存形式になるはずが無いなのか、デフォルト保存形式になっても普及しない、のどっちなんだ？ スマホで他の形式が採用されないのは、JPEGエンコーダをハードウェア実装すると、画像に依らず一定の時間で保存できて連写速度が毎秒何枚と言えるから
他の形式はそもそも重いし、一定の時間では保存できないでしょ
ただ、JPEG XLはJPEG並みに軽いようだからそこは今までと違うと思われる スクショ画像保存形式もJPEG XLになると助かる https://chromium.googlesource.com/codecs/libwebp2/
>WebP2は現在、部分的にしか最適化されておらず、非可逆圧縮の場合、WebPよりもおよそ5倍遅くなっています。 それでもAVIFより2倍速く圧縮しますが、解凍には3倍の時間がかかります。
圧縮率
AVIF>WebP2>JXL
エンコード速度
JXL>WebP2>AVIF
デコード速度
JXL>AVIF>WebP2
っぽいな >>404
標準化どうかじゃなくてロイヤリティフリーで性能いいから流行ってくれってだけ なんか1人で喧嘩腰で熱くなってるヤツがいるけどなんなんだ >>404
それいったらおまえのwebp2がデファクトになるとかも願望だろ
アホかこいつ >WEBPが主要ブラウザで事実上の標準となった
確かに主要ブラウザでサポートされたしそれ系のとこでは勝利宣言みたいなのもみるけど
標準となったと言えるほど実際に使われてるのだろうか
まだまだjpegとpingで占められているという印象なんだが apple、Google、MSが組んでスマホやPCで保存する形式が標準でjpeg以外のコーデックにすればいい
もしくは拡張子はjpgだけど別形式を内包させて事実上別コーデックでエンコードさせるか >>414
（話の流れは分かってないけど）
特許問題も含めたらかれっかれのjpegが安牌なんだろうな>HW屋にとっては >>415
アホという言葉で片付ける君とは話したくない
>>411
WEBP2はWEBPよりトラフィック削除が出来れば流行ったと言えるけど
JPEG XLはどう利用されれれば流行ってると言えるのか漠然としすぎてて難しい
>>406
Facebookは将来の正式サポートのためにAVIFのテストをしている
WEBP2はWEBPの後継として更なるトラフィック削除を目的としてる
こういう具体的な展望ならともかくとして
スマホカメラやデジカメに採用されれば普及するとだけ言われても、それは展望じゃなくて願望だよねとしか >>416
君と俺でWEBPの標準化とは何か、その認識に違いがあるんだろうけど
WEBPってJPEG等の置き換えを本来の目的としていなくて
Googleの検索/画像検索のトラフィック削除による収益構造の改善を本来の目的としてる
だからWEBサイトがjpgで占められてようが、スマホで撮影した画像がheicだろうが関係ない
Google検索/画像検索の結果がwebpで表示される環境が大事なわけ
EDGE、Firefox、Opera、SafariがWEBPを正式サポートしてまんまとGoogleのトラフィック削除に協力しとる現状が事実上の標準と化してんのよ safariがwebpに対応したのが去年だからなあ
それで最近人気のwebフレームワークがデフォルトでwebpを使うように変更してきている
新しいwebサイトでかなり広く使われるようになるだろう https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs
ここ見ると、JPEG XLはjpeg-turboよりエンコードもデコードも速いし、画質もWebPより良い
既存のコーデックと次元が違うのは間違いない それを可能にしてるのはXYBという色空間を使ってるかららしい
既存のコーデックはYCbCr使ってて、アナログカラーTV時代の色空間とディスられてるw >>420
単純に今jpeg使ってるとこがXLに入れ替わったら流行ってるって言えるんじゃない、気の長い話になるけど リンゴがVVCのheifに執着しないで
jpegXL側に回れば
グーグルの勝利なんだけどね >>428
AppleがJPEG XLを採用すればGoogleの勝利と君が考える根拠をどうぞ
ちなみにJPEG XLにはGoogle PIKの技術が採用されてるけど
イコールGoogleがJPEG XL陣営とかそういうのじゃないからね >>424
動画コーデックにも応用できないのかね
XYZ >>430
XYBだなw
もちろん応用出来るだろうね
XYB色空間を調べてみたくなった パテント料で揉めるHEVCとVVCの技術が画像形式で使われるのが
グーグルにとって目障りだからね https://youtu.be/qc2DvJpXh-A
こういうわかりやすい技術的優位性をみちゃうとやっぱりJPEG XLが本命だと感じるな
やっぱり動画由来は微妙だよ ちょっと興味出てきたな。活発に開発されてるOSSなライブラリってある？ >>433
そもそもjpegxlとavifの目的も違えばエンコーダのデフォルト設定も違う
画像情報をできるだけ保持しようとするjpegxlと
人の目で違いに気が付かない程度に削減しようとするavif jpeg XLだって人に知覚されないようにデータ削ってるが >>436
非可逆圧縮ってそういうもんだからね
むしろそうではないのはなんなんだ？ 何世代も重ねて劣化が積み重なるかってのは単なる一つの指標だからなぁ
それが優劣の全てではない
1世代の劣化（変化）が見た目的に許容できる範囲なら
多少変わる部分があっても視覚的に大事なポイントに重点的に情報量を割くという戦略もあるしなんとも ・improved lossless compression
・full 10bit architecture (HDR10)
・strong focus on software implementation, fully multi-threaded
俺はWEBP2が実験軸に挙げてる上のリストが採用されるならJPEG XLでもWEBP2でもどっちでもいいんだけどね
個人的にはロスレスで使いやすいものがありがたいから あと話題になってなかったけど
Firefox86でAVIFをサポートするみたいだな AVIFライ
三 =:;",',",,",',,",,'';: JPEG XLの仕様を日本語で解説してるわかりやすいまとめサイトが見つからん
繰り返しの編集にも強そうなので期待はしているのだけれど 繰り返し編集するならRAW+編集情報(XMPとか)でやった方がいいのでは。 webpはロッシー圧縮したものとロスレス圧縮したものが判別できなくて不便だった。MediaInfoで見てもわからないし
拡張子変えてくれればよかったのにと思う
次世代の形式ではそのへん配慮してほしい ロスレスwebpなんて使われてるの見たことないけどね pngの最高圧縮率より縮むので俺的には結構使うのよ >>447
WEBPのLossless optionが必要な人って確かに限られているけど
俺の例だと1.5GBあるPNGを一括してWEBPに置き換えたら20%ほど減らせて大助かりしてるわ
必要な人だけ使ってる感じだな Adobe系アプリが標準対応しないデータ形式は日陰者扱いされる風潮 Adobe系アプリが標準対応しないデータ形式をどこで誰が日陰者扱いしているのかまで言わないとなんとも
規格なんてのは使う人がいてナンボなわけで、その規格が日陰者かどうかなんて立場によるとしか言えないし
例えばSEO対策でWebPの導入を進めたい人からすれば今や日陰者でもなんでもないけど
一般ユーズからすれば未だにJPEGよりも扱いにくい日陰者だし
今の時代にAdobeがサポートしてるかどうかの1点だけで日陰者かどうかなんて評価は出来ないわ .EXRはハイエンド界隈では標準になりつつあるが、WEBP2が入り込む余地あるのかな。
せいぜい圧縮率高めてインターネット用を謳うしかないんだが、その前にブラウザでまともに表示できるようにしなきゃだな。だ exrは目的が違いすぎるから他のweb系フォーマットで代替できないでしょ
一つの画像に複数のレイヤーとか当たり前のように使うし
exrはProResみたいにコンポジットに便利な中間フォーマットから方針を変えないでしょ
web系の会社がいくら頑張ってwebpをexrに寄せたところで、ハリウッドの会社の方がコンポに必要な機能を理解し尽くしてるからな Windows10も最近はHDR対応モニターも一般的になってて動画はオフラインでもHDR再生するのは容易になってきただけど、静止画HDR（32bit）を表示するとなると選択肢の少なさに驚くね。 Photoshopとか持ってない一般ユーザーだととりあえず見れる程度のシンプルなビューワーぐらいしかないし、そもそも静止画でHDRというと露出を組み合わせ作る特殊効果を指す場合もあってややこしい。
キャプチャしたら大抵SDRになっちゃってるし。 静止画はHDRIじゃなかろうか
HDRでも同じ意味になるんか？ >>453
WEBPもWEBP2もGoogleが自社サービスのトラフィックを削減したいって目的で開発してるんだよ
その意味も理解できないのに次世代ビデオコーデックスレにアホみたいなレスしてるのはどうかと思う OpenEXRとか実際触らないで耳学問で知った気になってるからWebPと争うものだと勘違いしてしまうのだと思うけど、
大抵、プロ用のフォーマットってのは、プロ用だから普及してるやつより良い、ってことはなくて、
プロの特殊なニーズに答えることは出来るけど普及してるやつより使いにくくて容量もデカいってことが多い。
映画の配信をRAWでするのがベストなのか？って言ったら絶対そんな訳ないのと一緒で、
プロ用フォーマットは、ディスクサイズと取り回しの悪さを我慢して、素材としての素直さや多種多様なソフトウェアでの互換性を重視してるに過ぎない。
そう思わないならスマホのカメラを使うのをやめて普段からARRI Alexaでも使うといいよ。 OpenEXRはBlenderでマルチパス出してFusionでコンポジするからよく使う。
Photoshop用の便利なプラグイン出てるけど、Windows10のエクスプローラーでサムネ表示してくれないのが一番不便だ。 Googleはどんどんコーデックなり開発すりゃいいけど、拡張子は3文字でたのまい。
もう組み合わせ的に被るのが避けれないのかもしれんが。 Intel、グラフィックスカード「DG1」発表 約20年ぶりの再参入
https://www.itmedia.co.jp/news/spv/2101/27/news129.html
＞動画フォーマット「AV1」のハードウェアエンコード・デコードや、AI開発にも対応する。
AV1エンコードに対応、OEM向けのみか ＞hardware video decode and encode acceleration, including AV1 decode support
鵜呑みにする前におかしいと思ってリリース読むくらいしなよ その記事のリンク元見ると、おれにはAV1のデコードを含むっていう意味にしか取れないけど、高卒レベルには難しいな
hardware video decode and encode acceleration, including AV1 decode support;
https://newsroom.intel.com/articles/intel-releases-iris-xe-desktop-graphics-cards/#gs.rbm4os https://www.intel.com/content/www/us/en/products/discrete-gpus/iris-xe-aic.html
>AV1 codec support
>HEVC, AVC, VP9, and SCC transcode
宣伝文句にはデキルしか書かないのよね
デキナイを読み取るスキルはいくらあっても足りない Potplayer、昨日のアプデでAV1のGPUデコード再生に対応したので最新グラボ持ってる人は体感できるのかな。 CPUデコードでも負荷はほとんど無いでしょ
8Kとかやるなら知らんが >>471
コスト次第では安物のゲーミングノート辺りに載るとか？知らんけど 消費電力30WみたいだからGT1030なんかと同じカテゴリだな ANDROID TV DEVICES MAY REQUIRE AV1 CODEC IN ORDER TO OPERATE BEGINNING IN MARCH
https://chromeunboxed.com/av1-codec-android-tv-requirement-march-2021 >>462
av1とavifはそのまま、jpeg xlはjxl
webp2は何になったんだろ Chrome Beta for AndroidがAVIFをサポートしてた Ut Video Codecって可逆圧縮の中では優秀と思ってたけど、プロの業界では全然知られてないのな
Apple Proressがほぼ独占状態で、Windows環境だとオープンソースのGoPro CineFormがよく使われてるぐらい。
何が劣っていたんだろ。 使う側は稟議書が通るような後ろに見えるネームバリューとサポート連絡先
組み込む側は特許や利権回りの透明性と継続性、市場的にはハード組み込みの実用性と信頼性
金持ってるところが採用してハード開発も行って販売すればそれなりにユーザーは増えるしすぐに廃れて無駄な勉強と投資のリスクが低い
解説書を作って本を売るくらいの御金集めが好きな人がいないとなかなか広まらない
映像関係者はプログラマでもないしビルドがしたいわけじゃないので、そのあたりの使い勝手も技術屋にありがちなちょっとマニアックだった
Appleの「ゆずらない」仕様書安定感の前では多少の利点なんて道端の石ころように無視される >>479
フロントエンド不足
編集ソフトお抱えのコーデックが確実・便利だからやっぱり強いよ >>479
VLC Media Playerではいまだに再生コーデックに含まれてないのが歯がゆい > Ut Video Codec >>479
ちなみにさすがというかffmpegではネイティブで対応してたりする > Ut Video Codec コーデック入れないと開けないファイルを人には渡せないからね 「映像関係者はプログラマはない」ってのは同意
例えば、AV1に変換してみたいと思っても「git clone」、「cmake」、ビルド、リポジトリ、FFmpeg？パイプ？ナニソレイミワカラナイ
そんなとこから勉強しなきゃならないし >>479
中間コーデックは編集時に軽い、って特色があるから Ut Video CodecはDaVinci Resolveで読み込めないのが痛い。
Cineformのほうが軽いし容量も抑えれるね。（厳密にはロスレスじゃないが。） JPEG XLはMSがPhotoshopで読み込める用のPluginをかなり前に作ったものの、そのまま放置していて、最新のPhotoshopCCじゃ表示できないっていうね。 もうMS自体がやる気なさそう。 >>492
ごめん、ごっちゃになってたｗ すまん
まぁJXLもPhotoshopで開けないのは同じだけど。 まだ標準化されてないってレス見えてたら2行目要らないなあ… WebPがHDR対応してたらほとんどの問題解決してたんじゃね？ VP8がベースなんだから対応させようと思っても無理なのよ 地上デジタル放送方式高度化に関わる適用技術検討作業 中間報告／第一部：VVC 規格の主観評価実験（計画案）https://www.soumu.go.jp/main_content/000733118.pdf >>497
まいど思うんだが既存の方式との共存はどうすんだろな？
リセットしていちから仕切り直し？ >>500
垂直偏波使ったりコンポジット信号みたいな多重変調使ったりトリッキーな方法で実現するのねｗ
いっそのこと4kはネット配信にしちゃえばいいのに ネットだとYesマンの老人達がTV買い替えてくれないだろ
犬HKの集金マンの報酬が出せないし、利権様は収入が減ってお怒りなのです マルチキャストしまくればインターネットでも効率よく配信できるのかね ネットのマルチキャストは真剣に模索されてもいい
それだけでトラフィックは大幅に減らせる フレッツな回線ならマルチキャストぐらいできそうだと思うけど、実際どうなんだろ >>501
テレビをネット配信ってなんかメリットあるっけ >>509
テレビ持ってない人もテレビ見られるようになる 20年くらい見てないそうだから永久に見られなくても大丈夫だろう TV持ってない人からでも視聴料を搾取することができる TV見てない人はTV局が作るコンテンツが嫌なのか、TVを置くという物理的な行為が嫌なのか、どっちなんだ？ 4k60pHDRを20、30Mbpsで？と思うけどVVCなら結構いけるのかな 4K(2880x2160、インターレース)みたいなコレジャナイ要素が絶対につく 都内で車いらないだけなのに車が嫌いなのか駐車場代が嫌なのか訊かれてる感じ 壁の薄い6畳一間でブラウン管50インチTVで床が抜けそうとか100インチプロジェクターとかとか、
アパートが揺れるサラウンドホームシアターとかヲタ自慢の寒い世代を見て育ってるからな・・・ TV見てなくてもネット動画を見てるから必要ないってなら、TV局のコンテンツに興味無いと同じだろう
どのみちしょうもない映像をダラダラ見てることには違いないからなw ちなみに、TV見なくても大画面で映画ばっかり見てる人も沢山居る >>518
BS4KみたいにSDRの映像をHDR扱いで放送するから色がおかしくなる
も追加で 4Kって集合住宅のアンテナが非対応だから観たことないけど色が変なのか？ YoutubeはHDR動画を投稿すれば自動的にSDRも生成してくれるから強すぎる やっと見えてきた２K(B-CAS)の終了への布石だな
2030年代半ばの切り替え終了が実現すれば2038問題は気にしなくていいという感じか casカードのなんかが2038年分までしか記載できないんじゃなかったっけ 全部カード内で処理してて2038年過ぎたらカウンターの原点を読み替える処理をすればいいだけだから問題無いだろうといわれてる >>530
有効期限のカウンター設定がリセットされてしまう問題(桁が足りない2000年問題と同レベルの仕様の問題)
2038年4月22日を基準として日付を計算し直す修正を全B-CASシステムに導入しないといけない
アップデートをすり抜けると過去に契約した有効期限切れの契約が有効になってしまう
古いカードを・・・その頃俺は死んでるから関係ないな
VVCのテレビを買うかどうかも怪しいが、PCでは触れる機会がありそうだ https://mevius.5ch.net/test/read.cgi/avi/1612945065/46
・2038年4月22日を過ぎたら使えなくなると勘違いしているバカ
実際は、規定で2100年2月28日まで使える仕様になっている。
詳しくは>>4を参照。 自分も含めみんながみんなcasの仕様に興味あるわけじゃないからしょうがない
まぁ、情報の訂正乙だけどな 地デジは2000年問題が騒がれた後に始まったサービスだしな x266っていつ公開されるんだろうか
数カ月後に公開って言ってからもうそのくらい経ったような気がするが さすがに266の方が上だろう
エンコ負荷も上だろうけど デフォ10bitらしいからVVCのほうが素行はいい HuaweiがAlliancefor OpenMediaに参加してんのな
そんでIBMがいなくなってる気がする MPEG LAはライセンサーが大量離脱し半壊状態
現在は昨年末にGoogleがライセンサー参加したHEVC Advanceが必須特許の約8割を掌握しているらしい AppleやMSに遅れること1〜2年ぐらい?
案外遅かったね >>542
今の所エンコの負荷は266＝AV1、AV1は規格策定の時点でエンコを軽くするという目標が存在してないので改善の余地はない お役所がVVCっていう模索始めてしまったらもう根回しは終わってるよ
多少の性能差なんてごり押し ユーザー無視したAV1は死ぬだろうけど、ユーザーにメリットしかないAVIFは標準になってほしいわな
画像変換だからCPUパワーも特に使わんし劇的に容量を減らせるのは凄い 圧縮性能重視であれば
静止画：JPEG XL
動画：VVC（H.266）
に収束するのかもね JPEGXLよりAVIFのが同じ画質で容量減るけど味方が弱いのが難点
>>554
AV1は特許回避目的のみで作られてるので推進してる側が画質・エンコード速度の両立に興味がない、今はスマホで人類一人一人が動画制作できるような時代だからコーデックはエンコード速度>容量>規格の順できまる
今エンコの負荷が266＝AV1で画質も容量も規格の上限値も完全に負けてる、265を仮想敵にしてる間に一世代遅れてしまった
大体265が4団体になったのもアメリカとEUが特許云々でごねたからやし、GAFAも米国内の利権団体を潰してまとめてからからやれよと思う AV1は特許料を払いたくない配信サイトが使うだろうけど
個人でエンコードして云々という使い方はほとんど無いだろうな AV1対応してるYoutubeとNetflixだけで
インターネットの動画トラフィックの半分くらいになるぞ 統計会社のサンドバインによると
北米はモバイルの65%は動画(2020)
モバイル含む全体は2019のしかないけど
6割弱ぐらいが動画
ネトフリはそのうち26%(2019)
つべは23%
ここのトラフィックがAV1になって縮小されたら影響は大きいだろうね(半分とは言わないまでも) シェア競争で勝つのはAV1は確定済みだけど
別にシェア競争に振り回される必要が無い地上波は好きなコーデック選べばいいと思うよ >>556
av1は265を仮想敵にしてたことはないと思われ 仮想的というか出発点はタダで使える265を作ろうだったろうな >>564
それ対抗はvp9の役割だったのでは?
av1第一の理由は特許かと >>281を見るとデコードもエンコードもVVCよりAV1の方が軽い
AV1のエンコードは一時期の絶望的に重い状況から滅茶苦茶最適化が進んでる GoogleはChromeやAndroidでVVCサポートする予定とかあるの？ >>565
個人で使う場合、今はエンコ速度・画質の点からH265 10bitで保存するのがベターかなと思うんだが、
ネットで他人に見せようとすると不都合が多くて、やっぱりH264のほうが利便性は高いね。 >>567
それにav1はベースが8bit色深度だから
データ処理量自体が少なめになるのが大きい >>570
vvcencには-c yuv420と指定されてるからVVCも8bitだ
10bitにするにはyuv420_10とする必要がある >>571
なんとな
8bit色空間自体がノンサポートなのかと思ってた >>560
サンドバインはネットワーク機器会社だよ ライセンス次第では
AVCと同じライセンスならサポートする可能性はあるかもね
まあ無いだろうけど >>568
AndroidはHEVCサポートしてるし、する可能性低くないのではないか？ VVCがAV1に比べて圧倒的に圧縮できるとかよほどのことごない限りサポートしなさそう
GoogleだけじゃなくてQualcommもサポートしてくれないとねえ(QはSD888でAV1サポートしてないし) HW作ってるところはVVCじゃないとライセンス料が入らないからかな?
googleは配信側だからav1推し、HW側からのコミットでvvcと両方対応するとは思うけど 公式で3kbpsなら実用上は30kbpsあれば聞くに耐えるってことかな >>579
Lyra 3kbpsでもノイズなしのトークだけならばそれなりに視聴に耐える品質になっているけど、環境ノイズがある場合はさすがに無理があるね
とは言え、radikoのクソコーデックを置き換えで、15〜20kbps程度を割当てもいいのならば、音楽含めて耐えられるかもね
そろそろradikoは本気だせ Gigazineって二次ソースなのにやたらスレ立ったり
リンクはられるから中の人の仕業なんじゃ無いかと疑いたくなる。 それは考えすぎだろ
PPV少なそうな個人blogならともかく >>579
詳しい事は知らんけど、声の特徴を取り出して出力先で音声合成してるらしい >>588
HE-AACも似た感じだったな
やっぱりAI使ったコーデックが増えてくのかな 元を忠実に再現したい圧縮型のコーデックは厳しくなっていくだろうね毎回半分のサイズになるようなブレイクスルーは起きないだろうし
末端で見るだけの使用範囲ならAI補間を使った違和感の少ない圧縮・伸長でもいいんじゃね？というデータ削減を押し付けたい企業が今は金を出してるわけだし
スマホのカメラだってAI補完しまくりの方が受けてるし、中の仕組みに興味がない層からしたらデータ量少ない方でって言われそう AIを使うと一言で言っても、デコード時に補完をするのとか、AIで最適なエンコードアルゴリズムを学習するのとか、色んなやり方があるんやで >>588
> 詳しい事は知らんけど、声の特徴を取り出して出力先で音声合成してるらしい
最終的には音楽は楽譜のデータ送信で完結しそうだな 究極的には画面に写ってるのが本人かAIか見分けがつかなくなるまで行くだろうな
嫌な世の中だ… 第3次AIブームも終わりでしょ
いつも通り期待ハズレの時期尚早 メンバー同士が仲良い前提で作ったフォーマットがビジネスですら仲良くできない欅坂とコンセプトが合わなかった
ファンもそれを求めてる層は早々に見切り付けたし櫻坂でまた同じことやっても痛々しいだけ
どの企画であってもやってんなーの影がチラつく x265スレが落ちてしまっている為、こちらで質問させて下さい
[1] https://xgf.nu/mt4B (ソース)
[2] https://xgf.nu/N6Yq (x265 --preset slow --crf 26)
[3] https://xgf.nu/aTWJ (NVENC -c hevc --preset quality --vbrhq 0 --vbr-quality 33 他)
[4] https://i.imgur.com/bpRCCeL.jpeg
上記[1]の様な、静止してる背景＋動く被写体の映像をx265でエンコードすると、
動体につられて背景[4]の周辺がピクピクとブレる異様な挙動に悩まされています。→[2]
HEVCの特性なのかとも考えたのですが、NVEnc(HEVC)などのGPUエンコーダーでは上手く誤魔化せている様です。→[3]
crf値を上げたり--preset Mediumにすると悪化し、--qcomp 1.0や--crf 20辺りまで変更すれば改善されますが、この方法はサイズ面のデメリットが大きく実用的ではありません
主にオンライン講義やニュース番組ソースなどで僅かに動く人物の頭部周辺に顕著にみられるのですが、
出来れば--crf 28〜30 --qcomp 0.6で上記の問題をピンポイントに解決するにはどの様なオプションを指定すれば良いでしょうか？ --rskip 2 かな
ついでに --hevc-aq --psy-rd 1.0 --no-early-skip も付けてみて
デフォと同じファイルサイズになるようにcrf値調整してみてはどうだろう >>605
レスありがとうございます
ソース[1]を--preset slow --crf 26 --rskip 2 --hevc-aq --psy-rd 1.0 --no-early-skipオプションにてエンコしてみましたが、背景がピク付いてしまう症状は治まりませんでした
また[2]同様、容量削減目的で--crf値のみ28まで上げ(下げ？)ると更に悪化してしまう様です
>--rskip <mode> Set mode for early exit from recursion. Mode 2: exit using CU edge density.
とあるので、--rskip-edge-thresholdとCUsizeなどの調整も必要なのでしょうか、う〜む…。もう何パターンか試す必要がありそうですね
>>604に記述漏れがあったので追記
試行したx265のバージョンは2.9+8〜3.4+28、[2]は3.4+28 やっぱqcomp上げ無しでは効果なしか（自分はそれが気になったから0.85とか高い値を設定してる）
--no-cutreeで原因の元をカットするのも一興だけど
圧縮率は悪くなるから一興以上のものではないし・・
うん、私はお手上げ 配信が乗ったらAV1が成功で乗らなかったからHEVCが失敗っていうその辺のネット記事鵜呑みにしてるやつが定期的に表れるけど
配信:AV1
放送:HEVC
ディスクメディア:HEVC
カメラ(スマホ含む民生用):HEVC
カメラ(業務用):HEVC
ハードウェア対応:HEVC(策定2〜3年でモバイルまでエンコーダー対応したHEVCとデコーダのみのAV1)
ソフトウェア対応:ブラウザはAV1 他はHEVC
って状況でなんでHEVCを失敗扱いにできんの？
仮に先に挙げたのが今後AV1を採用してもそれは以降したんであってHEVCが失敗だった訳じゃなくない？
H.264…はまだ現役だから違うけど昔のMPEG-2やMPEG-4 Part2を失敗だったって言うの？ >>608
印象操作する奴もそれを真に受ける奴もうざいわな AV1はパタントフリーを歌ってるけど、google photosみたいに、無料で使わせるって言っておいて普及してからやっぱり有料にします、とかされる可能性はあると思っている。 それはないよ
それやって一番金払うのは当のGoogleなど参画者なんだから 後からルール変えたらルール変える前のエンコーダーが使い続けられるだけだろう VP8で問題が起きたときは全てGoogleが支払うで解決したけどな dav1d 0.8.2とlibavif 0.9.0を使用して、AVIF Susieプラグインをv1.1.1に更新しました。 https://github.com/uyjulian/ifavif/releases/tag/v1.1.1 >>614
あれはパテントフリーを謳ってたから買収して商用利用しだしたら
もろmpegのパテント踏んでたやつだろ
av1とは比較できない事例だと思うぞ VP9の出来が思いの外良いのだろうね
実際YouTubeで初めてVP9の映像を見たときに、MP4に比べてエッジがクッキリしてるのにビットレートは半減してるのにビビったもんだ >>606
すっかり忘れてたけど--rskip 2 と --rd 5 を組み合わせると画質はむっちゃよくなる
アホみたいに重くなるけど Windows10にてHDRディスプレイ使用時の、SDR動画の取扱が改善されるのだろうか？
・Windows 10プレビュー、自動HDRなど新機能をテスト、大型アップデート再開へ
https://news.mynavi.jp/article/20210318-1814011/ >>620
レス頂けていたのに気付かず、お礼が遅くなってしまいすみません
あれから>605をヒントにctu値を減らしたところ、動いてしまう背景の部分をかなり小さくする事が出来ました
根本的な解決ではなく、また若干の圧縮率低下もありますが妥協出来る範囲かなと
最終的には--preset slow --ctu 16を基本に速度面などを考えて変更を加える形に収まっています
ありがとうございました。 Shotcutでav1エンコードが出来るようになってる！やったぜ
品質のデフォルトがcrf=45だけど高くない？
vp9だとcrf=28がデフォルト値で、そのまま使ってたんだけど……やってみないとわかんないかな
めっちゃ時間かかるゥ… >>624
> 品質のデフォルトがcrf=45だけど高くない？
自信の証 >>624
情報どうも、早速使ってみた
が、確かに遅い
5分のFHD動画に2時間半かかった ワイの扱ってる動画はHD720です。crf=30、36、45で試して見た。
画質の違いはあんまわからんかった。ファイルサイズは相当違う。凄いや。
画質そこそこでいいワイの用途なら、これでいいと思ったよ。
少なくとも、vp9エンコードのcrf=40台ぐらいで極端に圧縮した時に見られる、明るさとシャープネスを極端にかけたようなチカチカする動画の出来上がりでは無かった。 元がH.264でファイルサイズが1/6くらいに縮んでたけど画質には違和感無かった
少なくともパット見で分かるような差は無い
設定にもよるだろうけどHEVCと比べても2/3のサイズになったし遅さ以外はかなりいいと思うよ Win10でもAndroidでも再生には苦労しないのがいいね av1はわりと再生環境整ってきてる
ハードウェアデコードはまだ時間かかるけど エンコードの間違いでなくて？
先日ロケット出たし、これで主要3社(A I N)はAV1のデコード対応したんじゃなかったっけ
普及するまでには時間かかるだろうけど ハードウェアエンコいつ来るんだろね
次のnvidiaのグラボで出来たら嬉しい >>631
まあエンコードはGoogle謹製のNASA-PCがやるって前提のコーデックだから VVC関係の動きが遅いな
x266がなかなか公開されないしFFmpeg用のデコーダーもまだ来ない
活発に更新してるのはFraunhoferのエンコーダーくらいだけどあれはパイプ入力対応してないから使い勝手が悪いし VVCってどこで使われる予定なんだろうか
テレビやブルーレイではHEVCで進んでいるようだし 地デジとかじゃね？「2025年を想定したVVC技術で画質評価」とかやってるし HDRとかパノラマ映像とかサポートしてるから、動画配信系に強そう
圧縮率に対してエンコードデコード負荷高過ぎるから単純な置き換えには向かなさそう HWエンコに決まってるじゃん
av1は目標高すぎて笑われたぐらいだし
HWエンコーダーの作りやすさはVVCのほうが上だと思う docomoが5Gで16KのVR映像をライブ配信したってニュースがあったけど、16KってことはこれはVVCが使われてるんかね？ 2018年上旬に出たAV1と2020年中旬に出たVVC比較して動きが遅いな、といいましても、、、。 >>644
AV1は規格完成してから半年後くらいにはエンコーダー、デコーダーやら結構盛り上がってた気がするけどなあ
まあ放送系のコーデックとweb系のコーデックじゃOSSに対する親和性が違うって事なのかもしれんが 利権や帯域圧迫でVP9やh.265の替わりが緊急で欲しかったという事情もあるし、AV1はVP10が統合されて開発リソースが流れ込んだというか加速したというかGoogleが急いでたっていう感じだった
今はAV1があるからVVCを急いでどうこうとお金をかける巨人がいないだけじゃなかな
AV1デコーダーのハード実装が始まったし、GPU開発も末端ユーザーもAV1エンコーダーが載った後の話題というかお楽しみ的な AV1にはx264やx265みたいな鉄板エンコーダもうあるの？ >>648
去年の終わりぐらいに数か月後に公開しますっていってから音沙汰ないんだよね rav1eとSVT-AV1のどちらかだろう
libaomもまだ継続的に開発続いていて最近高速化もされてるし それぞれが切磋琢磨してるから進歩していく
開発者同士仲が悪い訳じゃないし、お互いに参考にしてるでしょ ＞それぞれが切磋琢磨してるから進歩していく
単純に技術的な事やスポーツなんかはそうかもだけど、
政治にその論理は当てはまらない >>655
いや政治じゃないしw
特許でがんじがらめになってるコーデックと一緒すんな >>652
設計思想が違うのに合流しても意味ないだろ
SVT-AV1とかメモリ要求10GB以上とか普通に行くからな 規格の範囲内でやれることが色々あって速度と品質の一番良いポイントがまだ手探り状態だから決定版のエンコーダは難しいね
rav1e→見通しのしやすいコードに汎用的なアーキテクチャ対応、マルチプロセスの最適化率は低め
SVT-AV1→新しいプロセッサの最新拡張をバリバリ使うリッチな環境向け、品質より速度重視
libaom→実験的な高速化手法を試したり規格自体の整合性を試すためのリファレンス実装
他にも商用エンコーダは色々出てるしNetflixあたりは内製で作ってそう https://github.com/google/lyra
Googleのボイス用コーデックLyraオープンソース化したらしい Oracleの著作権侵害裁判が優位になってやる気出したか HWで金儲けしないなら囲い込むうまみがないだけっしょ 開発者が退職したとかじゃないの？
Googleは作った奴がいなくなるとすぐ投げ捨てるからな 低速1Mbps時代になったから、これで十分な画質で見られるようにしてくれ JPEG XL面白い技術使ってるよね
この技術を動画コーデックに持ってこれないだろうか JPEG XLの肝はXYB色空間だけど、それを使った動画コーデックは当然有り得るだろうね
ただ欠点が有るのか無いのかもよく分からんから、JPEG XLがリリースすれば色々分かるのかも JPEG XLが気になってちょっと試してみるかと思ったがGCCではビルドできないようだ
残念 rigayaのSVT-AV1お試ししてみたけどマルチコアを目一杯使ってくれてエンコード時間が短いのが良い
(それでも実時間の数十倍かかるけど)
画質も圧縮率も普通で他と変わりない そーいやwavelet使ったsnowってのが有ったよーな 途中で送っちゃった
snowというかwevelet系は消えてしもうたんかな ThorかDaalaってwavelet系じゃなかった？ wikipedia先生によれば、thorもdaalaもlapped transformなる謎技術を利用したものらしい
GoPro Cineformはwavelet系らしい
https://gopro.github.io/cineform-sdk/
waveletは特許周りで乗っかりにくいのか、長い物には巻かれた方が良いのか・・・ 全部イントラフレームの編集用ならともかく、ブロック単位の動き補償とウェーブレットはアカンやろう >>679
BBCが開発したDiracもWavelet使ってる ・ロジテック、UHD BD再生に対応したポータブルブルーレイドライブを発売
https://www.mdn.co.jp/di/newstopics/79097/
UHD-BDの再生要件を見ると、Intel SGX対応との記述があるわけだが、例のIntel脆弱性祭りのときに突破されたIntel SGXを
未だに必要としているのか？ 相変わらず必要かなのは変わってない
もう最新世代のCPUにはSGX付いてない
XEONには今後も積むらしいけど
ま、ほとんど使われてないと判断したから削ったんだろうな xeonでないとPCでは再生できないディスクメディアか… 一応デスクトップ向けのi3以下はCometから更新されてないからSGXまだ対応してるんだけど
ただでさえ限定された視聴環境がさらに狭くなったのは事実 SGXあったとしてもPCでは再生がとんでもなく面倒だからねUHDBD
どうしても使いたいなら再生機器買ったほうがいいよ >>679
Cineformは映像屋の間では結構流行ってきてるけどな
Windows環境での中間ファイルスタンダードになりつつあるんじゃないか
ProResよりサイズがコンパクトになるのがいい。まぁ厳密には可逆圧縮じゃないが。 可逆圧縮な動画コーデックなんてほとんど使われてないけどね 滅多にないね
不可逆でもビットレート上げれば肉眼で違いはわからないし
どうせテレビやレコーダーがフィルタ掛けるから気を使ってもあまり意味がなくなってきてる
日常的に使ってるのは大手の映画スタジオくらいじゃないの？ 中間コーデックでよく使われてるProresもDNxHDもcineformも基本的には非可逆圧縮よ
可逆圧縮にする設定もあるけどね 安定版に来たchrome 90でav1のエンコードに対応(webrtc向け)
ただしエンコーダはlibaom(デコーダはdav1d)
https://phoronix.com/scan.php?page=news_item&;px=Chrome-90-Beta 中間コーデックでよく使われるProRes 4:4 RGBとYCbCrは可逆圧縮だよ てかCineformはもうちょっと入手方法をシンプルにしてほしいな。
今は変わってるのかもしれないが、GoProの編集ツールをインストールしないと駄目でコーデック単体での入手方法はわからなかった。 cineformは数年前にオープンソース化されていてffmpegにエンコーダが実装済みなので使うのは簡単だと思うよ >>695
Proresに可逆圧縮なんてないだろう chrome90でWEBRTCでAV1が使えるようになったとか聞いたけど、詳しい人どんな感じなのか教えて！
そもそも対応しているサービスがあるのかさえしらんけど 音声の話になるが、radikoというからじる★らじると言ったほうがいいのか、NHK-FMのみ、エンコーダーか何かを改善したのか、久々に視聴すると音質が向上したように感じられる
気のせいかな？ 全然詳しく無い奴の疑問なんだけどディスクメディアってあとからコーデック変えられるのかな
UHDのブルーレイが後からVVCも使うようになったりする？ >>700
ビットレートは48kbpsから変化無いはず
エンコーダーが改善したら音質は良くなるだろうけど、幾らなんでももう少しビットレートを向上して欲しい…
128kbps欲しい >>701
DVDFabってちょっとお高いよね。
UHD Friendly ドライブが必要だし。 >>705
ビットレートは変化ないね
多分エンコーダーが変わったかな
ただし、どうも聴き比べると、NHK-FMの内、東京局から送信している分だけ変わったっぽい気がする
大阪など他の地域の局の分は変わりないようにも感じられる BDとUHD BDみたいにコーデック変わったら媒体同じでも変わる YouTubeが動画変換のために独自開発したチップ「Argos」とは？
https://gigazine.net/news/20210423-video-codec-argos-youtube/
やっぱYoutubeクラスになると独自のハードウェアエンコーダー作ってるんだな やってる事はCell Broadband Engineをベースにした、SpursEngine（スパーズエンジン）と変わりないけどな
みんなSuperEngineとか書いててニヤニヤしたなつかひぃ思い出 Googleともなると、FPGAじゃなくてASICでエンコーダーを作成してんだろうね
とはいえ、YouTubeのAV1の動画はエッジがボヤけてるような気がして好きになれない
VP9がやたらくっきりしてるのと対照的だな AVIFもめっちゃ縮むけど設定頑張っても現状のっぺりするしAV1ものっぺり病からは逃れられないんじゃないかな
逆に言うとAV1がシャープかつ縮むようになればAVIFも期待できる？ PxVC1100まだもってるけど
オク出しても誰も買ってくれないだろなぁ ・YouTubeのエンコード用カスタムチップArgosが第2世代へ移行中でAV1対応が加速する？
https://www.youtube.com/watch?v=6JOQSY5WRE8
Argosチップが第2世代に移行することによって、今後AV1のエンコード品質が
向上したりするのかね？ >>715
CPUで4Kリアルタイムエンコードが出来ちゃうからね ニコニコは特許見る限りコーデックじゃなくてAIによる補完に舵切ってたんだな
そりゃAV1の情報が止まるわけだ
【課題】 動画像コンテンツをサーバ2-2から視聴者端末11へ配信するシステム1において、配信容量を小さくして伝送路への負荷を削減するとともに、視聴する画像品質を向上させた構成を提供する。
https://chizai-watch.com/p/2021052414
https://i.imgur.com/0kqF8TQ.jpg 深層学習でリアルタイムに動画を処理するなら
再生にとんでもないマシンパワーか専用回路必要そう NvidiaのDLSSみたいなやつ？
学習コスト高過ぎ。 オリジナルと違っていても違和感ない画像にする補完だけで
再生時に結果を蓄積するような学習するわけではないと思うが AV1への対応も並行してやるでしょ普通。でもまぁ、ニコニコだしなぁ…… build も diff も関連スレで覚えた。ツール開発もほぼ完結状態だから忘れかかっているww ・英MQA社の符号化技術「Deblur Filtering」を導入
ミュージックバード、世界初「MQAデブラー放送」6/1開始。デジタル音声の時間軸歪み除去で高音質化
https://www.phileweb.com/news/d-av/202105/17/52724.html
圧縮音声ベースでも、まだまだやれることはあるみたいだな >>731
糞耳でもわかるほど劇的に変わるらしいね＞ＭＱＡ >>731
> なお「MQAデブラー放送」では、MQAのもう一つの特徴である「折り紙」圧縮技術を使用していないため、従来のチューナーでそのまま楽しめる。
いや、そんなんで音質が良くなるのか？
HDオーディオを圧縮しているMQAじゃないのに、音質が良くなるとか言ってるのは、もはや宗教だろと言いたい これあれでしょ、対応した機器では高音質になるけど、非対応の機器では寧ろ劣化するHE-AACみたいなやつでしょ… MQAはアナログ時代のドルビーみたいだなw
昔のレコード会社が販売してたカセットテープは、みんなドルビーでエンコードされてた気がするけど、大多数の一般人が持ってた未対応機器でどれだけ効果が有ったか謎だな よう分からんけど、波形が変わるんなら音も変わるんやろな
ワイ氏の邸宅では分からんやろが >クラシックチャンネル「KLASSE（117ch）」と同じ内容をMQAデブラー放送にて「THE AUDIO」チャンネルで放送する。
>これにより、チャンネルを変えながら、新・高音質放送と従来放送との違いを体験できる。
HDRのイメージ画像みたいに従来放送側を劣化させて放送とかしないだろうな・・・
>異次元の高音質体験が得られます。
ヨイショ記事は大体大げさなもんだけどこれもより現実に近づいたというだけで別に次元の壁を超越して
現実以上のものを得られるわけでもないんだよな
より現実に近づくということだけで大きな価値があるのにそれがなんか薄まっていくような 高音質、劇的とは言っているが良くなるともオリジナルに近いとも一切ないもんな そりゃ圧縮した時点で失われたデータは復元しようがないからな
圧縮後を解析して「たぶんこうだったんじゃない？」ってするんだから
オリジナルに近いとか言ったら詐欺になる MQAって二つの大黒柱があって
・高音域の折り返し圧縮
・時間軸応答（インパルス応答）の最適化
両者は全くの別物
前者はハイレゾ録音を再生時間を縮めること無く同じＣＤ1枚に納めるための後方互換技術であって
音質に関してはあまり画期的では無い（容量に制限が無ければ普通にDSDハイレゾ録音を聞いてればいいだけの話）
最も革新的なのは後者の技術であって時間軸のレスポンスを正確に再現することで
素人でもはっきり分かるほど音質を改善させることに成功した
既存の録音（過去の資産）をフィルターを通すことで時間軸応答の正確さを再現することもできるし
新規に録音する場合は専用機材を用いてMQAのフォーマットに従って録音することで
時間軸応答に対して正確に録音することができるようになる
って、ここビデオコーデックスレだったね
まぁオーディオの話はこのあたりで MQA対応のエンコーダーを有料でいいから手軽に購入できるようにしてくれ
あと、既にデジタル収録済の音声を時間軸応答補正できるアプリも出してくれ
そうすれば、過去の音源（特に圧縮音源）をリマスタリングすることもできるようになる > 素人でもはっきり分かるほど音質を改善させることに成功した
本当かな〜 日本人って本当に馬鹿なのか？
テレビや新聞がカラスは白いと言ったら信じるのか？ オーディオスレじゃないから音は別スレでやってほしい、、、が、過疎化が加速するから寂しさもある firefoxがnightlyでjpeg XLをサポート 意外と早いな
chromeも開発版ではサポートしているらしいし
avifはすでに要らない子かもしれん どうなるかね
JPEG XLのほうがavifより明らかに優れているけど優れている方が広まるとは限らないのがコーデックの恐ろしいところよ webpも保存できなくて鬱陶しいから消えてほしいよ…
しばらくは残るだろうけど 名前が悪すぎる…呼び方は
ジェイペグエックスエル
エックスエル
とかになるのだろうか？
JPEG2とかの方が一般人には分かりやすいだろうな jpeg2は2000と被るからできないんだろうね
chrome edge firefoxはやる気あるっぽいけどsafariは対応いつになるやら >>750
たぶんジェイエックスエル
拡張子が.jxlなので .webpとか.avifとかもあるから三文字縛りってわけではないんじゃない
俗称としてjxlをjixelって読むかもって海外のスレッドで見た記憶、片仮名ならジクセル？ ゆくゆくは組込機器にも普及させたいなら拡張子3文字縛りで決めといたほうが安全だろ。未だに8.3形式しかダメな組込機器とか一杯ある。
.unity3dとかはまともなファイルシステムのあるPCでしか使わないファイルだし。 とりあえず公式っぽいクソダサロゴマークはJXLになってるね
http://jpegxl.info/
講演会とかの呼び方だとジェイペグエックスエルだったと思う、自動文字起こしがJPEGExcelになってた記憶あるし まぁシンプルなほうがいいに決まってるよ。流行らすのならね。
俺は3文字縛りなんて無いと反論しただけ。 ちなみにFileTypeMan使って自分のPCで一番長い拡張子調べたら.ms-lockscreencomponent-primaryだった。
てか.JXLってよく空いてたな。三文字ってもう被りやすくて難しくなってきてるが 読み方はジクセルになりそうだけど、ジェクセルとか言う日本人もいそうだ
gifもなぜかギフでなくジフだしな どうでもいいけどビデオコーデックは大抵V入るからそういう読み方生まれづらいね まぁ日本語発音に答えはあってないようなもの。ちょっと前までASUSをみんな読めなかったんだ・・・インプレスの記者でさえ あれでしょ、長いと読めない障害とかそういうのでしょ >>773
ワッチョイ消して自演w
自演するために5ちゃんに金を払う馬鹿w ELF-VC: Efficient Learned Flexible-Rate Video Coding
https://www.wave.one/elf >>776
すごいけどデコードの負荷が大きすぎるな
せめて1080p30fpsがしょぼいPCでも再生できるくらいに抑えてほしい >>777
>It clocks at 39 FPS to decode an HD 720p video, and 18 FPS for HD1080p (all on an NVIDIA Titan V GPU).
Titan V使っても1080pで18fpsしか出ないのは重すぎだろ… >>779
ビデオカードは進化するからヘーキヘーキ ハードウェア再生支援必須になりそうだが、エンコードした動画の品質を見てみたいな https://arxiv.org/abs/2104.14335
デコードが18fpsしか出ないんじゃエンコードはどんな事になってるんだと思ったら10fpsでるのか 画像コーデックは新しいのでもそんな遅くならないけど動画はやっぱ難しいんだろなあ
CPUとかGPUの進歩も一緒に頑張ってもらうしかないか 問題は、>>776のコーデックはメジャーになりうる要素はあるのかということ
出ては消えする数多くの泡沫コーデックになりはしないのか？ x264も出たばかりの頃は重い使えねーとたたかれたものだ
マイナス要素を超える需要があれば改良されていくだろう
おま環特定ソースじゃなくて汎用的にあの性能が出るなら需要はかなりあると思うけどねぇ
とりまライセンス料の壁は消えないんじゃね？ 普及する前のものは出た当初はいらないモノ扱いされるからね
なにがあるかわからない 少し上で話題にされていた件
・世界初「MQAデブラー放送」で音質はどう変わる？ ミュージックバードで新旧比較番組がスタート
https://www.phileweb.com/sp/review/column/202106/02/1302.html
ミュージックバードさぁ、ネット配信しろよ >>790
> MQAは「時間軸を精確に再現するデブラーフィルター技術」と「小さな容量でも伝送できる折り紙技術」の2つから
> 構成されます。ミュージックバードの「MQAデブラー放送」は、デブラーフィルターのみで、折り紙は使いません。
よくわかってらっしゃる
折り紙機能が必要なのはCDみたいな容量に制限のあるメディアに落とし込むとき
配信じゃ容量に制限なんて無いからそもそも折り紙機能は不要 Windows10がついに改めてWindows11として世代交代するとかいう噂
AV1 Video Extension ももう標準装備かね なんだよ
Macみたいに10のままアプデしていくんじゃないのかよー もう次はないって言ってたのにmsの嘘つき
32bit切るためとかかな まぁでもMacとWindowsで数字合ってた方がわかりやすくていいんじゃね
ついでにAndroidも合わせてほしい >>796
macOSは1年に1つずつバージョン番号を増やしていく方針に変わったよ
今秋にmacOS 12ことMontereyがリリース予定 つまりあと88年くらいはその方式で行けるってことか ちょっと前からYouTube LiveのVP9の品質が良くなってる
以前は酷いものだったのに 寝る前に仕掛けたx265のエンコが終わってないから一旦中止して、設定も何も変えず単純にやり直してみたらいつも通りの速度が出た。
タスクマネージャーで見てもCPU使用率が上がってなくて、FPSで5倍差。ログに吐かれてる設定内容も全く同じ。なんだったんだろう。 xHE-AACがサポートしてるOS
macOS Big Sur
iOS 13
Android OS 9
Fire OS 7
WindowsはxHE-AACをいつサポートするんだろ？
xHE-AACのエンコーダーはexhaleが使えるみたい >AV1については2018年のv 1.0.0が用いられている
分科会の性質的にわざとじゃなくて良い資料がなかっただけだと思うけどさぁ 2021年に性能比較調査するのに2019年の資料を参考にしてるせいだろうね
他人が3年前に作った資料じゃなく自分らで作ればいいのにな Android TV BOXでもAV1ハードウェアデコーダー増えてきたね
VVCのハードウェアデコーダーも増えて欲しいな特にグラボに採用して欲しい >>805
まぁぶっちゃけx264以降画質はそんなに変わらんよ コーデックの話してるのに何でエンコーダーの話してんのこいつ エンコーダーとデコーダーを合わせて「コーデック」って言うんだからまったく問題ない VVCで思い出したけどブルーレイの後継のHVDは元気してんのかなー
ホログラフィックバーサタイルディスクみたいなやつ 動画で60FPSと30FPSってなんか違いあるんですか？
エンドユーザー的には見分けつかないんですよね？ >>815
記事内の画像だと映像系の文字ないけど業務用だけなのかな これまでの光メディアは始めは
業務用のデータ用途からスタートしたんだぜ
業務用のCDドライブとか50万円もしたからな 一般向けの光メディアはBD（UHD-BD含む）が最後でしょ
メカニカルな要素の強いものは消えていく運命
今後はメモリーカードのコストダウンを進めて、ディスクを買い足す感覚で買える環境を作る方向でしょ NANDメモリは一定期間電力供給が無いと
自然放電してデータ消失するぞ使い物にならん
数万する円盤が3年前後でゴミと化すんだぞ >>819
Optical Disc Archive
第1世代機 2012年
ドライブ (ODS-D55U) 価格 67万円
メディア (1.5TB) 価格 2万5千円
https://av.watch.impress.co.jp/docs/news/558210.html
最新世代機 2020年
ドライブ(ODS-D380U)市価 130万円
メディア (5.5TB) 市価 3万円
https://www.sony.jp/oda/products/ODS-D380U/
ソニー＆パナ 共同開発プレスリリース 2013年
「民生展開の予定は無い」
https://av.watch.impress.co.jp/docs/news/609495.html >>823
現在は両面で500GB今後は1TBに拡張予定らしいな
設計上は更に多層化してまだまだ容量増やせるらしい
これ民生機に移行できるのかな 民生展開の予定無いままっぽいね
4k地上波きてもUHD BDで頑張ってく感じか 磁気テープでええやん
FUJIFILMの最先端のやつとか12TBも有るぞ
直接録画するのはHDDにすれば、こんな最強の組み合わせは無いだろう トラッキングズレして読めなくなるんですね、わかります 〜とかでいいじゃん、ていう人大抵自分はやってない説 5.5TBで長期保存可能なら3万でもありかな？とちょっと考えるけど、ドライブ130万は高すぎる 磁気テープのドライブも、量産すれば一般人も買える値段になるのは間違いないけど、今時磁気テープかよ！っていう固定観念で普及することは無いだろうな、残念 磁気テープでしかパリティの計算ができない仮想通貨を開発すればいいんじゃね？ カードID (先頭8桁)：3231-5167
カード識別：T000
カードリーダー：SCR3310V2.0
ドライバーバージョン：WUDF 10.0.18362.1
CPU：Intel(R) Xeox(R) CPU X3439 @ 2.4GHz
M/B or PC：Dell Power Edge T110
OS：Windows 10 Pro Ver.1909 x64
miniB-CAS to B-CAS変換アダプター：none
scバージョン：[APP] sc172j改2+
オプション：-va
解析時間： 03:47:17
速くならんなぁ。コンピュータ買い換えたからいちお-vaで様子みてた。
消しても大して変わらんだろ。 833です。ご迷惑をおかけしましたってちゃんと謝ってるので833のことは
許してやってください。 10bitって色の階調の事じゃないんですかね
元々8bitの旧コーデック動画を変換するときに10bitにしても意味ないような ソースが8bitでも10bitでエンコードしたほうが（同ビットレードで）画質がいい傾向がある それ何でやろな
2bit増えてんのに
常々不思議に思うとる 簡単に説明すると。
8bit(ディザリング) -> 10ビットに変換(画質変らず) -> 10ビットでエンコード(ディザリング部分が高周波信号になる) -> 10bit(ディザリングなしだけど、高周波成分が2ビット分に残る)
つまりエンコード作業中に元々なかった周波数成分が出てくる。 なるほど(わからん)
阿呆な儂に解説してくれてありがとうよ・・・ 理屈はわからないけど10bitでエンコードしたほうがサイズが小さくなったりもする 情報を端折るときにある程度量子化の刻みが細かいほうがなめらかな変化を保存できるとかそういうのがあるんだろう
10ビットでは10.75→10.25→9.75みたいな変化を表せるけど
それが8ビットになったら11→10→10みたいに荒い変化になって
それにより発生するノイズを補正するのに前後フレームや周りのピクセルにむしろ多めの情報量を割かなきゃいけなくなるとか 10bitエンコで意味があるのはバンディング除去処理をした時だけ
バンディングノイズが消えとても綺麗なグラデーションになる
他は特に意味無い ソース無加工でも劣化がある以上8bit→8bitで同じ値を再現できないからソース以上にバンディングが出ることが多い
もちろん潤沢にビットレートがある場合はその限りではない
10bitだとそれが軽減できて低ビットレートでもバンディングが出にくい とりあえずAV1でエンコードしてみようとNotEnoughAV1Encodes 1.9てのDLしたんだけども、解説サイトがまだないんだね
エンコーダーが7つあるけどsvt-av1選んでおけば無難なのかな >>848
良いソースが見つからなかったけど、NotEnoughAV1EncodesとAv1anでaomを力技の分割マルチスレッドするなら
品質高くてエンコ早い順に並べると aom>svt-av1>rav1eになる
だからそのへんのツール使う人はaomでエンコしてる印象
ただ力技だとaomはメモリがそれなりの量必要になる >>849
詳しい情報サンクス
印象としてav1は業者向け？ぽい気がする AV1てPCでマトモな速度でエンコできるようになったの？
ちょっと前は1日かけて0.何フレームとかだった気がw x265でHTコア以外をthread poolに割り当てる方法あったら教えて下さい
今は全コアの利用率がほぼ同じで余裕がある状態なのでそれが可能であればもう少しエンコ速度上がる気がする x264のように実スレッド数以上を振ることはできません
pmode,pmeを試すframe-threads,lookahead-slicesを増やすCTUサイズを減らす等を試してみましょう
https://x265.readthedocs.io/en/master/threading.html そういう話ではなく使われるスレッドを高速なコアに置きたいだけなんだけど
無理に並列化しても画質落ちるだけだし すげー低レベルの質問で申し訳ないけど動画コーデックって時間経てばエンコーダーデコーダーの処理速度とかは上がったりするけど圧縮効率自体も改善されることってある？ ピンキリだよ
画質が上がる調整・機能追加がされることもあれば
速度を上げるために画質が落とされることもある >>854
それってx265がやることではないだろう
OSの仕事だよ 動画の圧縮というのは、膨大な圧縮機能の組み合わせの中からより良いパターンを探すというのを延々やっているので、この探すのが上手くなれば同じ機能の中でも効率は上がる
例えば動きベクトルの探索だけでも、全探索はまず無理だからね
特にハードウェアエンコーダの場合は実装の都合からやり方に制約がついていることが多く、改善の余地は色々ある >>854
poolsを実コア数にしてx265.exeのアフィニティマスクを設定すればいいんじゃないすかね チップベンダーがAV1乗り気じゃないのにVVC乗り気な理由って お金になるからじゃね
チップベンダーがなんのことか知らないけど AV1ってもう個人趣味でやる人は減る気がする
あと2,3年でx265ぐらいの速さまで行くとは思えんし、
地球環境にも悪いし・・・ AV1とVVCはHWエンコが開発されるのを待ってる HWデコーダーが載ったAV1はそのうち出そうだが、問題は付加価値をつけなくても儲けが出てるうちは競争に拍車がかからないからなぁ
POS導入でETHが掘れなくなるまでは、去勢LHR版のGPUでも儲けが出るしな(今から投資分の回収ができるかどうかは別として) 5年ぐらい前に買ったパソコンと先日買ったパソコンでav1エンコード時間があまり変わらなくてションボリ(´・ω・｀)
10分弱の動画で2時間半ぐらいだった もう個人がエンコードする時代は終わりかけている
勝手に動画サイトがエンコードしてくれる時代だし
昔の限られた制約の中で高画質を追求するのは楽しかったのう（老害） 見たいのが常時必ず動画サイトにラインナップされてるわけじゃないから
結局自分で持っとくしかないのよ >>872
おじいさん、GooglePhotoが無料だった時代は終わりましたよ？ h.264なんて窓から投げ捨てたいけど、h.265だとFireTVStickで再生きびしいんだよなあ
FireTVStick（4K）ならh.265の10bitにも対応って書いてるけど、うちの環境じゃなぜか音ズレするし >>877
Fire TV StickのCPUでH265 10bit 4Kをデコードなんてスペック不足で無理だろ
H264 4Kならいけるかもだが >>881
使ってるのがFire TV Stick 4Kで、動画自体は1280x720なんや
てか今見たらh.265の8bitも音ズレしてたからWifiの帯域不足とかかもしれん… >>881
対応してるって書いてあったら対応してるだろw
>>882
そう。ハードデコ Fire TV Stick 4K - 第1世代（2018）のデバイス仕様
H.265（HEVC）。ハードウェアによる高速化：最大3840x2160p（4K）@60fps、35Mbps、
Main 10プロファイルレベル5.1、HDR10/HDR10+/HLG入力対応、色空間8ビットおよび10ビット表示に対応
結構なロジック積んでるな(笑)Wi-Fiも802.11acでつながってれば問題ないと思うが、あとは距離＆壁だな 全然関係ないがガラケーが壊れたからまたガラケーに乗り換えたら今のガラケーってAndroidなのな
それでH.264再生したら激重でまともに再生出来なかった
多分ハードウェア再生支援機能すら省かれてんだろうな
んでVP9再生したらめっちゃなめらかに再生された
H.264の再生支援機能がなくてVP9の再生支援機能があるってちょっとよくわからんが
以上日記でした ラズパイみたいに特許料を払いたくないからH264のハードウェアサポートを無効にしてるんだろうと予想 業者に頼んだら、1時間のアナログ素材が約100GBのmovで納品
された。さすがにこれは重い。
どのくらいに変換したら、編集時の素材として使えるかな？ うん、さすがにも少し小さくした方が扱いやすい気がして >>891
CineFormにでも変換すれば？
MacユーザならProResでもいいけど 100GBくらいで編集できなくなるか？全部メモリに置くわけでもないんだし >>895
1時間で100GBだとビットレートは約222Mbps
640x480 30fps 24bitカラー 非圧縮だと
640✕480✕24✕30＝221,184,000≒221Mbps
で大体それぐらいになる まさかの非圧縮
本当は依頼時に圧縮形式選べたってオチありそう 今時640*480だと低解像度すぎてどんな素材なんだ? >>899
素材がSDだと4:3の映像だし、そういう圧縮率になる気がする もともとは16mmの素材をU-maticにまとめてあったもの。
せめてDVとかにコピーしておいてくれたら楽だったのに。
指定はなかったなぁ、いきなりクラウド経由で送ってきて
DL開始して寝る感じでｗ たった1.2倍で5%向上ならむしろ効率は良い方なのでは まぁ個人向けじゃないから
配信で帯域5%減らせたら偉い額になるんじゃね 予定してる機能積んだらどうなるか見るための実験版の時点で現行の完成品より良くなるなら幸先いい 今のコーデックってハードウェアデコード前提だろうし、
あまり矢継ぎ早にメジャーアップデートされてもハードの対応が追い付かないような(スマホはまだしも) すでに映像の圧縮は限界まで達しつつあるからね
さらに前に進みたかったらブラックホールの重力波使って圧縮するくらいしないとならない シリコンも限界限界と言われて壁にぶつかるころにはブレイクスルーが起きてるからねぇ
解像度下げて転送して表示するときに高解像度化する技術も採用が増えてるし、アーカイブと切り分ければ転送量はまだまだ減らせるだろうね
未開発の専用ロジック普及よりも今のAI支援ロジックで十分だしねぇ
ネトフリはもちろんアップル、ディズニー、ルーカス、ワーナー、BBCとか採用例も増えてるしなぁ
非可逆圧縮してるなら再現性はある程度犠牲にしてもかまわんという分野に限るだろうけど。
特に字幕読んでる層は「高精細感」があれば通り過ぎる車のようにどんどん脳内保管されて違和感感じないうちに忘れていくしな >>908
スマホはっていうけどQちゃんはAV1やる気ないじゃん
895からは本気出すのかな AIとかで驚異的な圧縮ができるかも
但し、デーコードで大外れもあるというｗ 再生側の機器に大量の学習データを持っておいて、それが有ること前提でAIで圧縮すれば、驚異的な圧縮率を実現出来そう
ただ、学習データがアップデートされると巨大なデータを落とす必要があるとか、課題は有るだろう もう1つのやり方は、デコードしながら学習していって、後の方のエンコードは学習データが蓄積されてる事前提で圧縮するとか
これは事前に学習データが要らないけど、デコード時に余計な負荷が掛かるという問題があるな 今の映像圧縮は、ざっくりいうと過去の画像や周りの画像の状況からこうだろうという予測画像を作って、それとの差分をZIPみたく圧縮するという方式をとってるから、
予測画像をAIで精度よく作れるとブレイクスルーになる可能性はあるな
ほんでエンコードのときに使うAIとデコードのときに使うAIが一致してれば別に問題なく復号できる
AIアクセラレータが規格化されてる必要はあるな そういう用語なんだわ
Predictionと呼ぶ
んで差分をRemain、日本語で残差と呼ぶ アニメは白地に黒の線画＋着色指定のデータにしたらおもいっきり縮まるだろうな >>922
最近のアニメは3Dモデルを使ってるから、そのデータとモーションデータ、カメラのモーションデータ、ポストエフェクトのデータが有れば再現出来るだろうな
っていうか、ゲームのリアルタイムムービーシーンとかそれだけどね まぁ光を電気信号へ変え符号化、演算処理すること自体も
映像そのものとは違う世界だろ。 昔FLASHというものがあってな
まあコーデックの仕事ではないな >>921
差分はresidueとかresidual そうだな、変なあおりのレスの方がいらんな
こういうのがあると投稿されなくなって害悪だわ svtAV1guiExもあって試すのもすぐに出来るのに
何ヶ月も話題にならないとは、どれだけ見向きもされてないのか
かわいそうなAV1 リリースの度にSVT-AV1試してはいるけどまだまだ画質がx265の足元にも及ばない
超低容量でも何とか画質を維持したいという用途なら使えないこともないという感じ 画質で比較したいならlibaomのほうじゃね
SVTはintelの多コアで高速化する実装だからNVENCみたいなもんだし
エンコード速度的に試してらんないとかありそうだけど VMAFスコアが高くても一概に高画質とは言えんのよ
VMAFは最善の画質メトリクスだけど人間の主観評価とはまだまだ異なる >>939
正確にはソース次第なんじゃないかと
少なくともSVT-AV1はx265と比べると暗部、グラデーションの保持が全然駄目 x265の半分のビットレートで同等画質になる明るい未来は来ないの？もう保管はhdd容量に頼るしかないの？ 超低レート領域ならレート半分で同等の(糞ガビガビ)画質にできるかもしれん
前世代比で半分なんていうのは全部そういう話だ
古いcodecのRD曲線が急角度で落ちていく領域で比べてる
画質を気にするような奴はそんなところ使わないけどな 今の次世代コーデックのターゲットは4k8k以上だからフルハイビジョンあたりで比較しても宣伝ほどの違いは出ない 歴代コーデックもそんな感じだよね
ここいらでFHDサイズで画質と圧縮率が最適になるようなコーデックが欲しい 元素材がちゃんと色差信号も情報残ってるなら、時間かければ画質保って圧縮強く出来るけど
ノイズまみれな素材は、頑張るだけムダなところ、あるからねえ >>942
VVC待ったら
まともに使えるのだいぶ先だろうけど FLACでも容量気にしなくて良くなったようにHDDの超進化で可逆圧縮で保存すればいい時代はいつになるのか VVCは未だに再生環境すら無いのがね
HEVCの時ここまでソフトの対応遅かったっけ？ VVCはもうPCで見る機会がほとんどないだろうからな
webでは使われないだろうし >>950
hevcは4k/8kっていう新しい需要があったのに比べ
VVCには新規の目的がない HEVCからライセンス周りを整理するという重大な使命がある
まあそれならAV1でいいと思うけど VVCは今んとこは次世代の地上波で使うかもしれないってくらいかな 次世代地上波はVVC+MPEG-H 3D Audioで行く予定なんだっけ 次世代の放送始めるに当たって、実装できる最新の規格にするのは当たり前かと。問題は4Kのデコーダチップの開発にかかる時間と放送開始の時期。 次世代地上波ってVVCの4Kなのかな？それとも8K？
8Kならまたビットレート不足でブロックノイズだらけになりそう 4kの60/30/24fpsって見た記憶
8kはまた10何年後くらいじゃないかな 総務省はVVCにするつもりだよ
すぐにやるかは知らんけど8Kまで見越した方式策定になってるからHEVCでは性能が足らんだろうね 実際に地デジ4Kが始まるのは2030年とかそこらかね 4kと8kの違いとか、何インチのテレビが有れば分かるんだ？って思うよ SDRの4KよりHDRのFullHDのほうが綺麗だし解像度そんなにいらないと思ってきた そういう環境もあるとは理解できるが、コンシューマーレベルでもそれがすべてではないと俺は思う いいとこ取りして次世代地上波は4K HDRになったらいいね
環境ないからわからないんだけどSDRとHDRで容量どんくらい変わるんだろ 音楽でも、思い切りコンプレッサーかけて狭いダイナミックレンジにマスタリングされた、mp3オーディオ聞いてるように、
映像もHDRは目が疲れるから、普段はSDRをバックライト絞って視聴してるんだけど
普段から1000nit以上のギラギラ明るいハイダイナミックレンジな映像って、見てられる？ >>965
27から32インチあると、4KとHDの違いはハッキリわかるし、43インチ以上になると圧倒的な差になる
一般的な視力1.0くらいでね
4Kと8Kは、65インチ以上になってこないと難しくて、120インチ以上なら圧倒的に差がつく サイズは圧縮率次第だからどうとでもっていう感じだね。地上波は4K HDRに統一してくれたら一番いいなぁと俺も思う
MPEG2-TS導入時と一緒で編集環境やら時報遅延でまたもめるんだろうけど
TS抜きができない現状では、末端利用は円盤抜きかスマホやハンディカムで撮影した素材がソースになるんだろうし
4Kキャプチャは・・・まぁ勝手に頑張ってくれという感じで(笑) 確かにいつかの段階で、地上波もMPEG2の1080iを卒業しなきゃならなくなるよな
日本中のENC/DEC変える必要があるけど
4K VVCってのは決定事項？ 開発コスト抑えるためにHEVCという選択肢もあるらしい >>970
画面サイズより視野の何パーセントを占めるかの方が相関高いと思うよ。
テレビより10-15インチ程度のタブレットの方が分かりやすいと思うの。 8Kは視野を覆うくらいの距離で視聴することが推奨されてるからね
今までと同じ感じで見てもあんまり意味ないのは皆分かってるんだろうね >>972
テレビのほうも縦1080以上になったら文句ないんだけどな
2万ぐらいの安いやつは十年後も720程度のまま変わってなさそう 今更だけどスレタイに入ってるVP9とHEVCはもう次世代ビデオコーデックではなくない？ >>1
>>980
※ DTV板はデフォルト設定が強制ワッチョイなので、ワッチョイを付ける時は、extend コマンドの記述は不要です
（つまり、逆にワッチョイを付けない時は、!extend::checked:: の記述が必要になります）
※ DTV板は即死判定があり、即死を回避するためには、スレを立ててから1時間以内に最低12コメントが必要です
（これ以降は、30日間書き込みがないと強制的にdat落ちします） >>974
HEVCじゃMPGE2の二の舞いになる 高度化されて地上波はフルサイズじゃなくて、2880x2160や5760x4320で放送したりしてw
>>979-980
個人的には、コーデックなんて定期的に新しいの出てくるからスレタイに入れる必要あるのかな…と思う たてました、数字入ってるコーデックが後ろだと勝手に数字変わったから位置ずらした
【VP9/AV1】次世代ビデオコーデック総合スレPart7【HEVC/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1630582269/ >>984
スレ立て乙
専ブラの次スレ作成機能は便利だけどそういう欠点もあるんだね… 地上波新しくなったらDVD・BDの次のディスクメディアとか出るのかなあ
BDでも4K観れるから無いかもしれないけど もうメディア溜め込みたくないから
マトモな画質、音質のストリーミングでいいよ
買い切りで >>989
AV1もあるしストリーミング路線が1番伸びそうか
自分も買い切りが理想だけど今サブスク流行ってるしあんま期待できんよね… 昔はビデオテープ溜めてたけど、全部捨てたからwってのはあるな SwitchのゲームはマスクROMだけど、1つで幾らのコストなのか一切表に出てこないんだよな
ただ、16GBならば普通にゲームが使ってるから大したコストでない気がする
その内マスクROMの方が安くなる時が来るはず
microSD ROMとか 8kってどこに需要があるの？最低でも80インチはないと何も意味ない気がするが… ほんの10年前まで、4K65インチなんてものを、一般家庭がポンポン買う世の中は、信じられなかったけどな
HD解像度なんていらない！って言ってる奴も20年前は多かったよ なるほど・・・。80インチが1人暮らしの人でも普通に手ごろに買える価格になってるのか。
都心のワンルームなんて20平方メートル以下の物件も普通にあるからなぁ。
テレビも薄型化してるし、壁に貼り付けれるようになったり、
LGのようにせり上がってくるテレビの進化型が普通になる時代か。 テレビしか考えてられない時点でヤバい
例えばVRでは8Kでは足りず
16Kレベルが求められてるのに
他にも業務用でいくらでも需要あるだろ
医療とかな 今どきな25平米ワンルームでも4K55-65インチ普通に置けるからねw
置くかどうかは別として、薄くて軽いから
家電やにたまには行ってみると、わかるよ 自分が言ってるのは地デジ/BS での8kな？
それとも未来では、VRでテレビを視聴するのが当たり前なのか？
2025年から H266/VVC で試験開始ぐらいしか決まってなかった気がするが。
(526 の書き込み)
あと25平米は、今後の建物はワンルーム規制でそうなるかもしれんが、
自分が前に住んでた物件なんて、恵比寿でワンルーム14.5平米で 7.5万だった。
テレビも持ってなったが置けても40〜50インチが限界だったと思う。
4kで60インチ〜、8kで80インチ〜はないと、ppi が小さすぎて人間の認識範囲を超えて意味がない このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 324日 15時間 17分 21秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
