次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
レス数が1000を超えています。これ以上書き込みはできません。
>>120
DXVAChecker4.0.0の記事でAMDのVP9デコード支援について色々書かれてた。
http://bluesky23.blog.shinobi.jp/entry/20180210
調べてみたけど、間違いがあれば教えてほしい。
・AMDはCrimsom ReLiveでVP9のデコード支援に対応。
DXVA方式に加え、Chrome用の独自方式（AMD MFT VP9 Sync Decoder利用）もある。
ただしどちらもデフォでは無効。レジストリや起動オプションで有効化できる。
・2017/10/23のReLive 17.10.2で、VP9のDXVAデコードができなくなった。
・2017/12/12のAdrenalin 17.12.1で、amdoclvp9lib64.dllが消えた。
・現状でAMDのVP9デコード支援が効くのはChromeだけ（？）。DXVA方式は効かない。
・FirefoxでAMDのVP9デコード支援を使うとGPUクロックが上限に張り付くという問題がある（？）
FirefoxはChrome方式なのかな？よくわからなかった。
・最新のAdrenalin 18.2.1でもそのまま（？）で、
VP9のDXVAが効かなくなったことについてAMD公式からの発表は一切無い（？） たぶんあってるはず
自作PC板でも同じ報告があった これは機能は実装したけど致命的なバグがあって使い物にならない代物だったということかな?
いくらなんでも時間的にもう無理な頃合いだよね そういえば>>112-113の VLC 3.0.0 でのExperimentalなAV1デコードの話は、
liaomをビルドした上でVLCを--enable-aom付きでビルドすればできるよというだけらしい。
公式ビルドは対応してないようで、av1.webmを再生しようとすると以下のエラーになった。
コーデックがサポートされていません。:
VLCは形式 "av01" (AOMedia's AV1 Video) をデコードできませんでした。 xvc codec
https://xvc.io/
Royalty based next-generation video codec.
Compression performance beyond HEVC. >>126
面白そう。
・サイトが全体的にシンプルにまとまっていて説明もわかりやすい。
・オープンソースでビルドも使い方も簡単そうなエンコーダ／デコーダがGitHubで公開されている。
https://github.com/divideon/xvc
・FAQによるとHEVC比で5〜20%のビットレートを削減できるらしい。
・120kbpsでのH.264との比較デモを見る限りでは割と綺麗。
https://www.divideon.com/products-and-services/mobile-video-streaming-with-xvc/
・「HEVCのライセンスプールが複雑でうざい？色々なとこの特許を侵害するのが心配？
うちからxvcのライセンスを買えば、後はうちがやるから特許侵害とか一切気にしなくていいぜ！」
という、攻めてるライセンス形態が、いろんな意味でドキドキ感に溢れている。 >>129
Jonatan Samuelsson@JonatanDivideon
元々EricssonでHEVCをやってた人みたい。そこを飛び出して新たに始めるとかハッカーっぽくて好き。 ついにMPEG2の特許が消滅
https://gigazine.net/news/20180215-mpeg2-patent-expired/
2018年2月13日にアメリカで残っていた最後のMPEG2に関する特許が期限切れを迎えました。
MPEG-2 Patent List
http://www.mpegla.com/main/programs/M2/Pages/PatentList.aspx
MPEG2はMoving Picture Experts Group(MPEG)によって策定されたビデオフォーマットで、テレビ放送やDVDなどのメディアなどに広く利用される、最も一般的なビデオ標準規格です。
MPEG2の特許を管理するパテントプールのMPEG LAがMPEG-2の特許リストを更新し、2018年2月13日にアメリカ国内で残っていた最後の特許が期限切れを迎えたことを明らかにしました。
（ ＾ω＾） AV1は別にHEVC超えなくて同じくらい狙えばよかったんじゃないの？？
同じくらいだとパンチ弱くてすでに普及が進んでるHEVCがあるから、
AV1の普及進まないとみてHEVC越えねらったのかな？ あれか、AV1がHEVCと同じくらいだとひょっとして世代的にVP9と同じになちゃうのかな？・・ つーかDLすると264もVP9も大差無いんだが
どうなってるんだｗ >>136
Youtubeの話かな？「大差ない」と言うのは何を基準にして言ってる？
確かにモノによってはVP9もH.264もファイルサイズ(ビットレート)が同じくらいだったり
むしろVP9の方がでかくなってることもあるし、結局VP9も割とビットレートでゴリ押ししてる感はあるけど、
画質とビットレートのバランスを考慮して比較しないと意味ないぞ。
それに今のYoutubeは1440pより上は一部を除いてVP9だけになってるから高解像度での比較はできないし。 4320p60fpsの動画つべに上げてみたがローカルh264の半分強の負荷で再生出来たのはその為か
再生支援か元々のデコーダが素晴らしいのか知らんけどVP9悪く無いなぁ 2018/2/7 (昨年9月の資料)
Performance comparison of AV1, JEM, VP9, and HEVC encoders (Conference Presentation)
https://www.researchgate.net/publication/319925128_Performance_comparison_of_AV1_JEM_VP9_and_HEVC_encoders_Conference_Presentation
・Fraunhoferによる比較評価。
・AV1やVP9は、HMやJEMに比べると明らかに圧縮率が低い。
・固定QP時
・AV1はHM比で+47.7%、JEM比で+111.8%のビットレートになる。
しかもエンコード速度はJEMがAV1の3倍、HMはAV1の20倍速い。
・HMはVP9と比べるとエンコード速度は3.4倍だがビットレートを46.6%削減できる。
・VP9はAV1比でのビットレートは+21%だが、エンコード速度はAV1の114倍速い。
・マルチパス時
・AV1はJEM比で+55%、VP9はJEM比で+92.2%のビットレートになる(ただしJEMは1pass固定QP)
・AV1はHM比で+9.5%、VP9はHM比で+37.9%のビットレートになる
※HMはH.265のリファレンスモデル。JEMはFVCのリファレンスモデル。 2018/2/9
ITU, ISO Prepare for Next-Gen Video Codec | TvTechnology
http://www.tvtechnology.com/news/0002/itu-iso-prepare-for-nextgen-video-codec/282724
・Fraunhoferの人へのインタビュー。
・JVETでのFVC(JEM)の開発状況やHEVCについてなど。
2018/2/15
Race on to bring AV1 open source codec to market, as code freezes | Videonet
http://www.v-net.tv/2018/02/15/race-on-to-bring-av1-open-source-codec-to-market-as-code-freezes/
・Bitmovinの人いわく、AV1はあと数週間で仕様が固まるらしいけどエンコードの計算コストがめっちゃ高くて大変。
仕様決定したら今度は死ぬ気で効率を上げる努力をしていかなきゃなんねえ。 >>140訂正
× HMはVP9と比べるとエンコード速度は3.4倍だが
〇 HMはVP9と比べるとエンコード速度は3.4倍遅いが 映像業界に潜伏してるエロイ人に質問です
静止画の画質って色調チェックにはカラーバーとか
解像度チェックのいっぱい直線や曲線が引かれたチャートがあるけど
動画の動きの画質比較用で風景とか人物とかじゃなく
幾何学的な映像で業界標準的なものってあるの? >>139
GTX1080のEVGAのFTW？だからちょいOCモデルかな
と一応CPUは5960Xの4.3Ghz
CPU負荷7〜8割から4割程度まで下がった 【2018】 H.265/HEVC Part8 【7680x4320】 スレから誘導させてもらいました
現在NVEncCでHEVCエンコードを行っているのですが
x264の--crf 20に相当するNVEncCの--cqpの値はどの程度のものなのでしょうか？ 規格もエンコーダーも違うから答えられる人間は存在しない >>145
前にSSIMで比較してみた人がいるからそれを参考にするとか
http://mevius.5ch.net/test/read.cgi/avi/1486130737/335
まあ数字をちょっとずつ調整していって目視で確認するのが一番だろうけど >>147
レスありがとうございます
ざっくりですが x264の3/5くらいのビットレートを目標に--cqpの値を変化させてみます H.265 (V5) が2/13に承認され、近日中に発行予定。
ITU-T Work Programme H.265 (V5)
https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=13324
H.265?:?High efficiency video coding
https://www.itu.int/rec/T-REC-H.265 ドイツでは2018年4月25日から地上波がMPEG2からHEVCになるって。知らんかった。
DVB-T2 HD 1080p50 HEVC
http://www.dvb-t2hd.de/ ARD（アーアールデー）やZDF（ツェットデーエフ）、RTL（アールテーエル）など大手含めて完全にMPEG2からHEVCへ切り替えか
日本はアナログ→デジタルの混乱で総務省も大変だったのに、ドイツは二度目の切り替えとかよくやるな 最初からHEVCへの移行も視野に入れた規格にしてただけでは
>>149
なにか変わるんですか？ >>152 >>149
>>56のリンク先PDFより
>2.2 ビデオ符号化
> 本会合では2つの作業項目が完了した。1つは、2017年10月にエミー賞を受賞したH.265の改訂版であり、
> 新たにモノクローム10と、メイン10静止画の2つのプロファイルを追加した。
> これは、色空間のアスペクトの修正と、補助的な拡張情報メッセージを追加するものである。
> 補助的な拡張メッセージには、コンテンツの色ボリューム、正距円筒図法とキューブマップによる
> 全方位360度投影、リージョンに関するパッキング、球面ローテーション、全天球視点、
> 領域の入れ子及び動き中心のタイルセット抽出情報集合と関連するそれらの入れ子が含まれる。
> .・・・ >>150
そのサイトやWikipediaの情報を見ると、ドイツでのDVB-T2 HDへの移行自体は2017/3/29から開始されてるみたいだよ。
2018/4/25は移行のPhase 2bってことで、地域が拡大されるということらしい。
2018年秋、2019年春にも地域拡大が予定されていて、それでようやく移行完了らしい。
DVB-T2 HD
https://de.wikipedia.org/wiki/DVB-T2_HD
音声はHE-AACって書いてるね。 HDで提供されてる360°映像は画質クソすぎて見れたもんじゃないから、8Kで提供されるようになれば有り難いね
HEVCにその規格がこれまで盛り込まれてなかったのはビックリだが Youtubeは既に8K 360度 3Dってのもあるね。
Youtubeの8K60pのVP9って、どれくらいのスペックなら再生できるんだろ。 >>159
Intel KabyLake以降、NVIDIA Pascal以降で対応してる>>139
AMDはRavenRidge（Vega 11）が遂にDXVAで4K対応したけど8Kはまだ >>160
4Kでは？
8kデコードに対応したGPUあんの？ ttps://en.wikipedia.org/wiki/Nvidia_PureVideo
Feature Set H[edit]
Feature Set H are capable of hardware-accelerated decoding of 8192x8192 (8k resolution) H.265/HEVC video streams.[19] つべのフォーマット272(8K60pのVP9)はGTX1070がギリッギリデコードが追いつく程度
Pascalならデコードはできるデコードは >>160
再生支援の対応状況としてはそうなんだけど、レンダリングの負荷とかもあるので
どこまで実用再生できるのかなーと。
>>164
ということはレンダリングまで含めると厳しい感じなのかな？
気が向いたら最新のDXVACheckerでデコードパフォーマンスや再生パフォーマンスを計測してみてくれると嬉しい。 テスト対象：https://www.youtube.com/watch?v=Ya4Z-obAkWA
DXVA Checker 4.0.1
LAV Video Decoder 0.71.0をDXVA2 (native)で運用
スケーリングはオリジナルサイズでの再生パフォーマンスの結果
CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
GPU: NVIDIA GeForce GTX 1070
Decoder: LAV Video Decoder
Decoder Device: VP9_VLD_Profile0
Processor Device: DXVA2VideoProcessor
Frames: 11941
FPS: 65.396
CPU Usage: 4 [2-8] %
GPU 3D Engine Usage: 15 [7-17] %
GPU VideoDecode Engine Usage: 97 [82-100] %
デコードパフォーマンスもほぼ同じフレームレート >>166
ありがとうございます。やはり8K60pともなるとかなりギリギリなんですね。 固定機能だけど、GT1030はNVEncが省かれたりしてるので違うかも？単に無効にしてるだけで同じかも？ デコード回路の規模はPureVideoHDのバージョンで同じ気がするけど
GPU VideoDecode Engine Usageはクロック(P-State)で処理能力が変わるので、ピーク性能が同じとは思えない
コア、メモリクロックと違う何かがあるのかもしれんが、わからん CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
GPU: Intel(R) UHD Graphics 630
Decoder: Microsoft WebM MF VP8 Decoder Transform
Decoder Device: VP9_VLD_Profile0
Frames: 11941
DVXA2
FPS: 79.138
CPU Usage: 0 [0-0] %
GPU VideoDecode Engine Usage: 93 [81-99] %
D3D11
FPS: 83.994
CPU Usage: 0 [0-1] %
GPU VideoDecode Engine Usage: 97 [55-99] %
Edgeで実際に再生しながらGPUエンジン使用率
3D: 20 [-25] %
VideoDecode: 78 [-87] % 圧縮は出来ても速度が尋常じゃなく遅いのが現状なんだっけ？
特許回避しながらどこまで早く出来るのかねえ、技術的な話は分からんが頑張ってもらうしかない 50代後半の人が定年になるまでは安泰だろ。
来年度以降もミルビューや旧コネクテッドの事業をそのまま続投してもしばらくは大丈夫じゃないかなぁ。 youtubeとnetflixが採用するの決めてるし エンコは企業に任せるとしてハードウェアデコードできないと厳しいかね？ Cool New Video Tools: Five Encoding Advancements Coming in AV1 - Bitmovin
https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/
AV1の技術解説。
・Film grain synthesis
・Constrained Directional Enhancement Filter
・Warped motion and global motion compensation
・Increased coding unit size (up to 128×128)
・Non-binary arithmetic coding > ・Warped motion and global motion compensation
MPEG-4で負荷に見合った効率を得られないと不評だった機能だが大丈夫なのか そりゃあハードウェアエンコだろ、それこそニューラルネットワークがーって革新無いと無理だろうねコレ 次の次くらいのコーデックはニューラルネットを使ったものになりそうだな >>183
解像度も高く高品質になってるし
MB-Treeみたいな高度な入れ子処理も行うようになってるから
また違う結論に至ったのかもよ 対抗馬のhevcを引き合いにMB-Treeって書いたけど
AV1にあるのかは知らない HEVC採用、mpeg陣営の最新静止画規格が一番乗りか
webpは中身vp9になって対抗しないのかな AV1のサンプル動画見ると、MB-tree的な機能を効かせまくってるように感じる。 乾いた雑巾を更に絞るようなもんだしな
ムーアの法則が死亡してるから果たして実用的な時間でエンコ出来るようになるか疑問だわ >>194
Polaris/VegaのVP9はブラウザ向けの再生支援しかできないようだけど、
RavenRidgeではちゃんとVP9のDXVAにも対応したみたいだよ。 HEVC Advanceがコンテンツ配信著作権使用料廃止、特定の著作権料金と上限を減額
https://japan.cnet.com/release/30237475/
> 独立系ライセンス供与管理企業のHEVC Advanceは14日、HEVC Advance Patent Licenseから
> 「サブスクリプション」と「タイトルごと」のコンテンツ配信を廃止し、HEVCの普及を加速し、
> ストリーミング、ケーブル、オーバー・ジ・エア・ブロードキャスト、衛星配信をサポートして、
> 最高のビデオ体験を消費者に提供する。今回の発表によって、HEVC Advanceは、
> インターネット・ストリーミング、ケーブル、オーバー・ジ・エア・ブロードキャスト、
> 衛星を含む非物理的なHEVCコンテンツ配信にライセンスを供与しないし、著作権使用料を求めない。 HEVC Advanceの新旧ロイヤリティ概要
旧： https://web.archive.org/web/20170717022617/http://www.hevcadvance.com/pdfnew/RoyaltyRatesSummary.pdf
新： https://web.archive.org/web/20180314065526/http://www.hevcadvance.com/pdfnew/RoyaltyRatesSummary.pdf >>198の訂正
>>198の旧の方は20170717時点のもの(webarchiveではこれが最新だった)なんだけど、
2017/10/24
HEVC Advanceが低価格機器の特許使用料見直しを発表
https://japan.cnet.com/release/30214763/
にあるようにHEVC Advanceは昨年10/24にもライセンスの見直しを行っていた模様。
つまり>>198の旧PDFはその変更前のものとなるので注意。 >>199
美味い方に乗っかるから負ける事は無いぞ。
何処まで適用されるのかよく分からんなぁ しかしあれだな・・・。>>196のStreamingMediaの記事でも
「はぁ？現時点ではロイヤリティの情報を公開するつもりがない？バカなの死ぬの？」
みたいにこきおろされてるVELOS media（HEVCのライセンスプールの１つ）に
SONY、Panasonic、、SHARPといった企業名が並んでるのを見ると、
「やる気がないならHEVC普及の足をひっぱってないで、さっさとMPEG-LAにでも合流しちまえよ」って言いたくなるな。
ちなみにVELOS mediaのHPに行ってみたら無駄に動いてちょっとうざかった・・・。
http://velosmedia.com/ ストリーミングで金がかからなくなるのか
youtubeがどう動くかな でも、徴収をやめるのはHEVC Advanceだけで、他にもパテントあるんでしょ？ >>206
そんな方針は発表されてないと思うけど、何を根拠に言ってる？
コンテンツ配信へのH.265/HEVCのライセンス課金についての現状は以下のような感じだと思うけど。
●MPEG LA
無し。
●HEVC Advance
今回の変更で無しになった。
●Velos media
立ち上げからそろそろ１年経つのにライセンス条項を一切発表していない。
FAQに
As it relates to content, we will take our time to fully understand the dynamics of the ecosystem
and ensure that our model best supports the advancement and adoption of HEVC technology.
とあるだけ。少なくとも「コンテンツ配信には課金しない」とは明言されていない。
●Technicolor
無しと明言されている。
「コンテンツプロバイダに課金したらHEVCの普及を阻害するだろ」っつってHEVC Advanceを抜けたという経緯もある。
●その他
知らん。 mukenさんがHEVC Advanceは四天王の中で最弱っていうネタ投稿してたけど
配信側からの徴収は行ってないパテントプールが多いのね ブラウザはどうなるんだろうね。H.264の時もFirefoxやChromeは対応を渋ってたけど。
現状のブラウザとH.264のライセンスの関係ってどうなってんだろ？
Win10だとIE/Edge/FirefoxはOSが持ってるMediaFoudationのH.264デコーダを呼び出してるみたいだからライセンスは関係無し？
ChromeはMediaFoudationのH.264デコーダを無効にしてもデコードできるみたいだから独自デコーダ持ってるのかな？
ライセンス料はどうなってるんだろ？
H.265についてはWin10 FCUからH.265デコーダが外されて別途ストアからHEVC Video Extensionを入れないと
デコードできなくなったみたいだし、それもハードがH.265再生支援をサポートしてないとダメっぽいから
そこからなんとかしないとどうしようもなさそうだけど、よくわからない。 まあAV1のこともあるし、バラバラで複雑になってるH.265のパテントホルダーに圧力をかけるためにも、
FirefoxやChromeでのH.265対応はすぐには進まないかもね。 おいおい、iPhoneで撮ったHEVC動画はどうなるんだよ
能力を存分に発揮できねえじゃねえか ffmpegはGoogle Summer of Code 2018でHEIF/HEICの読み込みを実装する予定らしい。
SponsoringPrograms/GSoC/2018 - FFmpeg
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018
HEIF support
・FFmpeg currently does not support reading HEIF/HEIC files although this is a format with increasing usage in mobile devices. >>210
H.264はOpenH264を使えばCISCOがライセンス料を負担してくれているからね
firefoxはそれを使っているよ
プラグインの欄を見てみればわかると思うけど >>216
じゃあOpenh.265作れば解決だね なんでCISCOが肩代わりして支払ってるんだろ？
何か弱みでも握られてるのか？ >>216
OpenH264はWebRTCで使われてるけど、動画再生には使われていないと思う。
>>210で書いたように、OSのデコーダを無効にしただけで再生できなくなっちゃうし。 HEIFってBPGみたいに全然使われないかと思ったけど案外採用されてるね
ただ今のところYUV420しかデコード出来ないらしいのが痛いが 圧縮画像は基本420だから、それほど危惧する必要はないんじゃないの？ YUV420は赤の崩れみたいな問題もあるし、RGBかYUV444/YUV444P10があった方がいいという話では。 420と444とRGB(可逆)で拡張子か何か変えて1発で判断出来るようにしてくれよ >>228
これ。
HEI0,HEI2,HEI4,HEIRとかなら分かりやすいのに。 高圧縮なコーデックが流行るのはいい事だと思うけどheifはライセンスどうなってるんだ？ もう旬は過ぎた感じだけど、今更本の自炊を始めよう思ってるんでHEIFが普及してくれるのはありがたい
EPUBやPDFもHEIF対応してくれないかなぁ >>230
HEIFの規格自体は対応してても、OSやソフト等がどこまで対応するかは不明だからねえ。
最低でもyuv420p8の heic / hevc ブランドには対応するとして、
heix / hevx への対応が広がるかどうかは、まだわからないのでは。
現時点で何がどこまで対応してるのかはよく知らないけども。
HEIF Technical Information - High Efficiency Image File Format
https://nokiatech.github.io/heif/technical.html
Brand CodingFormat
heic HEVC (Main or Main Still Picture profile)
heix HEVC (Main 10 or format range extensions profile)
hevc HEVC (Main or Main Still Picture profile)
hevx HEVC (Main 10 or format range extensions profile) 日テレ系SOC、HEVC 60i 1920x540というかなり特殊な設定使ってるのね >>235
HEVCの規格上どうしてもそうなるという可能性が
x265でインタレ保持するときもフィールド分離してやらないといけないし VLCは3/13のコミットからHEIFに対応しつつあるらしい。
193f466c4a [Tue Mar 13 18:51:32 2018 +0100] [demux: add support for HEIF]
Nightlyで試せるはずだけど、試してはいないので現時点での出来は不明。
https://nightlies.videolan.org/ >>238
結局よくわからん…
関係なさそうだから、突っ込まないでおこう >>240
俺もよく知らんけど、中継車と放送局を結ぶ衛星中継で飛んでるデータのことでは。
>>235
それってどうやって調べたの？どこかの記事？
それとも何らかの方法で受信して解析できるのかな？ >>233
MacだとHEVCデコーダが対応してるのはハード処理、
対応していないのはソフト処理になるようだけど、
Win10のHEVCデコーダはハード処理専用みたいだし、
どうなるのかわからなんなあ Win10のHEVCデコーダ→HEVCコーデック
https://www.microsoft.com/ja-jp/store/p/hevc-video-extension/9n4wgh0z6vhq
よく見たらWin10のHEVCコーデックもハード処理とソフト処理対応してた
ってことはHEIFも同じ仕様になるかな
Win10のHEVCデコーダ >>235
LSIチップのSoCじゃないのね。
紛らわしいわwww >>236
HEVCのインタレってそんな仕様なんだ
インタレソースだとh.264に対してそんなにメリット無いのかな？ HEVCは本来インタレをサポートしない前提だったんじゃなかったっけ？
今実装されてるのもインタレもどきというか、独自実装のような感じを強く受けるのだが そもそもいつまでインターレース使う気なんだ。
1000年代の代物だぞ。 1440x540のデータ量でフルHD60fpsと言い張れる >>249
一切ないな。ブラウン管テレビが無くなった今では負の遺産。 H.265にもインタレの規定はあるみたいだし、以前x265スレ
https://mevius.5ch.net/test/read.cgi/avi/1462270195/173-189
で「HMならインタレもデコードできるらしい」と言われてたので試してみたが
うまくいってるように見える。（やり方が間違ってなければだが）
ffmpegやLAV等ではH.265のインタレへの対応が進んでないのかな？
640x360-60i.avs
#-----------------------
# 30fpsのプログレッシブ動画を読み込む
AVISource(360p30.avi)
# -> 640x360 30000/1001fps
#
# TFFとしてフィールド分離
AssumeTFF()
SeparateFields()
# -> 640x180 60000/1001fps
#----------------------- # x265でインタレースエンコード
# http://x265.readthedocs.io/en/default/cli.html#cmdoption-interlace
# HEVC encodes interlaced content as fields.
# Fields must be provided to the encoder in the correct temporal order.
# The source dimensions must be field dimensions
# and the FPS must be in units of fields per second.
ffmpeg.exe -i 640x360-60i.avs -strict -1 -pix_fmt yuv420p -f yuv4mpegpipe - | x265_2.7+14_x64.exe --y4m - --lossless --interlace tff -o interlace.265
# interlace.265は、ffplayやMPC(LAV)では 640x180 60000/1001fps として再生されてしまう
# HM(HEVC Test Model)のデコーダでyuvファイルに。
# HM software: Decoder Version [16.18] (including RExt)[Windows][VS 1900][64 bit]
TAppDecoder.exe -b interlace.265 -o decoded.yuv
# yuvファイルを再生 → 640x360 30000/1001fps として正常に見える
%ffplay% -f rawvideo -pixel_format yuv420p -video_size 640x360 -framerate 30000/1001 decoded.yuv フィールド周波数高い60Hzだから、倍速120Hzが効きやすくなる
IP変換でかなり正確にブログレッシブ化出来る
データ量が半減する
実は今時のデジタル技術によって逆に見直されてるのがインターレース >>255
プログレッシブの60Hzも余裕でどんどんプログレッシブ化が進んでるのが実際のとこだと思うんだけど
どういう現場のどんな人達がそういう見直し方をしてるの？ インターレースお払い箱批判が酷くなったのは
まともにI/P変換出来ない安物LCDモニターが売られ始めてから
それよりも葬り去るべきはプログレでも低フレームレートのガクガク映像
あれを有難がってガンガン垂れ流してる人の視覚ってどうなってんだろう 個人的にはフレームレートや解像度を多少下げても
ノイズの少ない映像を流してくれって思う
ビットレートが高いはずの某有料BSチャンネルですらノイズまみれ >>258
最近、BSが1920から地デジと同じ1440になって、ビットレートも地デジ並みに下げられたからな
HDでも圧縮率の低い高ビットレートなら、相当きれいなもんだが >>257
ちょっといいテレビなら問題なくても、安いテレビだと見られたものじゃなくなるな
30pが増えてるのは、4K60pの撮影編集がXAVC class300だと600Mbpsになり、HD60iの50Mbpsの12倍になるから、記録保存も編集も大変過ぎ
てことで、4K30pの300Mbpsでお茶を濁すから 瞬間的に入る紙吹雪パターンに遭遇したら
ビットレート爆上げするなりブロック格子細かくしたり
そういうのに特化して研究してる優秀なヒト誰も居ないのだろうか
もう記録映像より3Dリアルタイムレンダリングコンテンツが
家庭用に作られるようになる方が先かも知れないけど…
それはそれで三船敏郎と越後製菓がチャンバラする新作とか楽しみだけど かのDVDフォーラム vs DVD+RWアライアンスみたいな構図やなｗ 60pと比べたら60iの方が良いけど、
確かに30pと比べたら60iの方が遥かに良いな
時代はiPadですらリフレッシュレート120Hzなのに30pはガクガク過ぎる 60pと比べたら60iの方が良いけど、
↓
60pと60i比べたら60pの方が良いけど、 >>262
つ crf（品質基準）モード
>>264
動きの滑らかさはそうかもしれないけど
画質自体はプログレのほうが断然優れてるから30pのほうがいい
ま、自分でエンコードしない人にはインタレ放送の画質の悪さなんて気づかないだろうけど >>266
60iは60pの半分の帯域で済むし、普通のテレビのI-P変換でそこそこいい1枚映像の画質が得られるし、効率がいいんだよ
XAVCならHDだと50Mbpsの60iと比較して、4K60pとなると600Mbpsになるから、12倍の帯域とストレージ容量を食い潰すしな >>267
なんで>>261と同じ内容を２度繰り返したのかよくわからんが、HDだの12倍だのは本筋とは全く関係なくて、
・4K60pはXAVCだと600Mbpsになって大変。
・4K60pがきつい場合は4K60iか4K30pにしてレートを半分にして誤魔化そう。（それでも300Mbpsだが）
・滑らかさ重視の60iにするか、１枚絵重視の30pにするかは人それぞれだよね。本当は60pが一番いいけど。
ということで、4K過渡期の次善手段として4K60iが選択肢に入ってるというだけでは・・・。
仕方なく使ってるというだけなのを「インタレースが見直されてる」と表現するのは違和感があるな。
4K30pを「お茶を濁す」と表現するなら、4K60iも「お茶を濁してる」ことに変わりはないと思う。
4K放送は60pなんだし。 意外と収録のみの現場ではPsFが活用されてたりするのだ あー、コストや状況等を踏まえてフォーマットを選択するのは当たり前だろうから、
現場でインタレースを使うのが悪いと言ってるわけじゃないよ。
ただ、そういうフォーマット選択って昔からやられてきたことであって、
別に「インタレースが見直されてる」ってわけじゃないんじゃないかなあというか
そのへんの表現で少しモヤっとしただけというか、それだけです。 HEVCでインタレとか何考えてんだ…マジで放送にしか需要無いから ここはPS4proが擬似4Kのために使ってる市松模様方式で…。 西田宗千佳のトレンドノート：iPhoneなどで採用されてる新画像フォーマット「HEIF」とは？
http://u-note.me/note/47508170 綺麗にデインターレースできる映像は
プログレッシブにしても動画サイズはあまり変わらない気がする Multi-Codec DASH Dataset: An Evaluation of AV1, AVC, HEVC and VP9 - Bitmovin
https://bitmovin.com/av1-multi-codec-dash-dataset/
> This scientific evaluation puts AV1 to the test against industry standard codecs
> and shows that AV1 is able to outperform VP9 and even HEVC by up to 40% >>277
ついでにネタ元の１つ前のレスからMediaInfoのAV1対応の件。
https://mediaarea.net/MediaInfo/ChangeLog
MediaInfo change log:
Version 18.03, 2018-03-19
--------------
+ AV1: support of AOmedia AV1 based on latest specifications draft, raw (OBU) and in MKV だったらFirefoxとChromeとEdgeはHEVCに対応してくれるかな？ どうだろうねえ。
今みたいにOSが用意するHEVCデコーダを呼び出すといった実装は可能になるんだろうけど、H.264 vs WebM の時のように
HEVC vs AV1
HEIF vs AVIF ( https://github.com/AOMediaCodec/av1-avif )
という対決構図を作って、最低でもHEVCのライセンス面での更なる譲歩を引き出すためにゴネる気もする。
まあAV1がどこまで使えるかにもよるけど。主に速度面が心配だ。 仕様が固まったということじゃなくて
規格（開発の）凍結なの？ 3000倍の時間かけてまでエンコードするほどの価値あるコーデックではないということ >>283
仕様凍結(freeze)=仕様確定だな ハードウェアエンコーダーが出ない限り、AV1に実用性はない IntelとAMDとNVIDIAの名前があるんだし、HWエンコーダーは出てくると思うぞ >>281
H.264のSiscoみたく特許料を肩代わりしてくれるところが現れない限り難しいと思うな
拡張機能(有料)で対応とかならあるかもしれんが
https://m.srad.jp/story/18/03/19/1052226
＞現状、HEVC/HEIFはエンコード・デコードに特許使用料を少なくともMPEG LAと HEVC Advance に支払わなければ
ならない
Apple は iPhone の中に特許使用料を織り込める。
Android P は端末メーカーが使用料を支払えば良い。
Microsoft は
どうやらHEIFのデコードにはユーザに 120円を Windows Store で
支払わさせることで解決するみたい >>277
＞現在の計画によると、コーデックの仕様は今年の7月にインターネット標準として採用される予定です。
漸くか >>293
ああ、>>280は「AV1が諦めた」と勘違いしてたのか・・・。意味を取り違えた。
>>282はブラウザのHEVC/HEIF対応可能性について書いただけであって
別にAV1の「凍結」を開発中止だと勘違いしたわけじゃないんだけど、
確かに流れだけ見ると勘違いしたように見えてしまうな・・・。
>>281
書き忘れたけど、Edgeは既にWin10FCUで
「デバイス製造元からのHEVCビデオ拡張機能」(HEVC Video Extension)
が入ってればHEVC動画の再生ができるよ。 民生機でも実用的な時間でエンコードもできるコーデックと
少しでも画質容量比を良くするためにエンコに死ぬほど時間がかかるけど
莫大な帯域を消費する配信業者用の業務用コーデックかという話で
どっちが勝ったり諦めたりという話ではないと思うぞ
どのみちAV1は俺らが気軽に扱えるものにはならんだろ これまでAviUtlやAvisynthのプラグインの開発者ですら
もうTSやBD,DVDのソースをカットしてフィルタ掛けてエンコードしてって作業に飽きてほとんどエンコードしなくなったと言ってるからねぇ...
ストレージが大容量化したからTSのままでもスマホやタブレットに転送して視聴した方が楽になったんだと
HEVCはQSVのHWエンコーダがそれなりの速度でまあまあの品質だしAppleのお陰で再生環境も揃ってきたし
コンシューマはHEVCを選んでおけばいい気がする BDはさすがに30G超えてくるからエンコ必至だろ。
インタレソースなら解除が面倒だしなぁ…
とりあえずインタレは早く廃れろ インタレ解除は例のHWインタレ解除フィルター使うか、レコーダーからのキャプチャーならばレコーダーで解除 MX150搭載なら安いのはLenovoのideapadあたりか
それでも9万コースだけど
そもそもモバイルで単価の低いCPU積んでるモデルな時点でdGPUなんぞ積まないから、dGPU積んでる時点それなりにするんだよな
そのうえHWデコーダと違ってGPUブン回すから綺麗に処理出来てもバッテリ保たないだろうなぁ 動画エンコードを10万円以下で考えている人はクオリティーなんぞ求めるべきではない avisynth+対応プレイヤーでリアルタイムフィルタ処理すればいいという話だぞ >>307
なんでボカしてるのか知らんけど、例のフィルタってnekopanda氏のD3DVPだよね？
https://github.com/nekopanda/D3DVP
これは「GPUでインタレ解除してプログレッシブでエンコードしたい場合」に使うもの。
インタレソースを再生する場合は普通にレンダラがGPUを使ってインタレ解除するんだから、
再生時にわざわざAvisynth+使ってリアルタイムフィルタ処理なんてする必要ないと思うんだけど。
インタレ解除したものをBlueskyFRCに渡してフレーム補間したいとかなら別だが・・・。
というかインタレ解除とかの話はAvisynthスレとかTSスレとかでやった方がいいと思うよ。 動画の世界は常に流動的だという意識が充分ではないようだな
時代は今後、インターレースからプログレッシブへと潮流が変わっていくことになる
そうすると、やがて再生時にインタレ解除しようにもクオリティーの高いインタレ解除技術が使えなくなっている可能性が高くなってくる
それならばインタレ解除技術が充実している今のうちに解除してからエンコードしておけば、後々インタレ解除のクオリティー問題に悩まされなくて済む
それに再生時にインタレ解除する前提では、再生する環境に依存することになるから、古いPCや安物のプレーヤーを使って再生する必要が出た場合にも、
満足いく再生ができない問題に悩むハメになる そんな大袈裟な意識持ってるなら、現存する手法よりも
高度なインタレ解除技術が登場する可能性も考慮したほうがいいのでは。 https://twitter.com/bitmovin/status/978153380311805952
> Hi! Indeed, we have no information that the codec is finalized.
> Bitmovin codec engineers have been working with AV1 for over a year
Bitmovin社は「AV1の仕様が確定したなんて話は聞いてねーぞ」っつってるな。 >TSのままでもスマホやタブレットに転送して視聴した方が楽になった
君ってすぐ騙されそうだね >>310
確かに
エンコードした後でより優れたインタレ解除が出てきたら後悔しそう
つーか放送がインタレな以上、当分インタレはなくならないでしょ
4K放送は一般に普及するとは思えないし インタレ解除については、これ以上の進化は期待しにくい
あるとしても時間をかけて演算するディープラーニング系にわずかに可能性はあるが、再生時のリアルタイム処理に使うには不向き >>308
D3DVPはavisynth+じゃなくても動くことを考えると
KTGMCのことをいってるのでは >>312
どう考えても実際にやったことない奴だな
一応TSのままハードウェアデコード＆ハードウェアデインタレースで再生できるけど、
60pじゃなくて30pになるのでカクカクで使い物にならん（Android＆Snapdragonの場合、iPhoneは知らん）
だいたいWiFiなんて11acでも有線GbEより遥かに遅いし時間掛かって面倒
それこそQSVとかでハードウェアデインタレース＆エンコードしといた方が楽 最近の流行りはサーバ側でのリアルタイムエンコードでタブレット等での視聴
つまりネットワーク負荷は依然高いからエンコードが使われるわけで BDは気に入ったのしか取ってないからm2tsのまま取ってるけど、ゲームの録画は可逆だから編集後にエンコしてるわ。
でないと1時間で500GBとかになるし 16K無圧縮の帯域を実質スループットで通せるくらいネットの帯域が拡大するまでは廃れないんじゃね？ >>323
アホですか
どんなコーデックでも成り立つよそれ 物理的に無理やろな
データをテレポートで遅れるくらいにならないと サイトがリニューアル AV1のロゴマークが出来てる！
https://aomedia.org/ もう開発者は開発を始められるんだな、俺は無理だが
エンコード速度はどんなもんなんかね HEVCだってリファレンス実装のHMとx265では数百倍は速度が違うのでAV1もこれから多少は最適化されていくと思いたいが でもそもそもの計算の複雑さがHEVCの10倍とかあるんでしょ?
特許に引っ掛かるので仕方ないといっても流石に酷いように思う AV1始動アナウンス来たみたいだ。
https://twitter.com/a4omedia/status/978981295106781184
We’re excited to announce the launch of #AV1!
#AOMedia is ushering in the royalty-free, UHD web video era.
22:05 - 2018年3月28日
The Alliance for Open Media Kickstarts Video Innovation Era with “AV1” Release ? Alliance for Open Media
https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/ なんかロゴが折り紙のように見える
もしかして折り紙的な技術が使われてるとか？ 放送に採用されないコーデックは、どこまでいっても中途半端
ライセンス逃れを開発理由の一つにしている時点で、自ずと限界は来る aomのコードはまだリリースタグはついてないのか。 標準品質で同じ動画を変換するとx264よりx265はどんだけ遅いんだ？ ストリーミング時代に放送がどこまで生き残れるかっていう問題が >>342
そんなんソースや設定とかによるからなあ。
とりあえずベンチマークスレで色々な環境での結果を見てくるといいんじゃないだろうか。
【x264/x265】実用エンコベンチ Part6
http://egg.5ch.net/test/read.cgi/jisaku/1507728392/ 俺のRyzen3 2200GだとフルHDの30fpsの動画でx264で20fps、x265だと5fpsくらいしか出なかった記憶がある。まあ普段はHWエンコードしてるんだけど もう、昔より半導体の微細化のペースとか遅いんだから、
解像度上げるペースとか新しいコーデック開発するペースも遅くしろよ。 >>342
同等の量子化係数でブン回しても6倍以上は重くて、売り文句みたいに2倍も縮むのは希で2/3ぐらい >>336
Appleからの歓迎コメントがない・・・ >>347
自分環境かつ自分がよくエンコするソースでベンチ取った時
x264のslow?slower?よりx265のfastの方が1.3倍速くて1.6倍程度ビットレート比で綺麗だったから重用してる。
ソース次第やね >>348
Founding Membersの中ではIBMのコメントも無いね。
Appleは入ったのが今年１月だし、まだ様子見ってのもあるのかもね。 https://twitter.com/tmvn/status/979038621746413568
> Also, @JonatanDivideon made a mistake on his chart, and everyone keeps reprinting it.
> The Fraunhofer HEVC patents were purchased by GE Licensing. They're in the HEVC Advance pool.
>>340の記事でも引用されてるHEVCのパテントライセンス図に Tom Vaughan 氏がコメントしてた。
FraunhoferのパテントはHEVC Advanceに参加してるGE Licensingに買収されてるそうだ。 >>349
そりゃプロファイル変えていればね
プリセットを変えればH265のコア部以外の「x265やx264が実装している工夫の部分」で重さが大きく変わる >>352
プロファイルじゃないや、プリセットだね x265については、プリセットから速い方から2つめのsuperfastと3目のveryfastの間で、3割ぐらいと大きく画質容量比が悪化するので、
有る程度処理の速さを求める場合でもultrafast〜superfastは止めて、veryfast以上、出来ればfaster以上を設定ベースにするといいと思う
crfベースでx264とx265のSSIMを比較した場合、crf 23あたりからSSIMの開きが広がる
画質劣化が知覚できるとされるSSIM 0.985を割り込まなず直近上位になるcrfは、x264はcrf 26、x265ならcrf 28になる
x264でcrf 25、x265でcrf 27の場合だと双方ともギリギリでSSIM 0.985を下回るぐらいになるので
放送波ソースで画質保持ならcrfの設定はここらへんが妥協の境界になりそう QSVの場合だと、SSIMの0.985挟むcrf（ICQ）がH264でICQ 20〜21、HEVCでICQ 22〜23あたり
もちろんソースの動きや画の内容で左右される部分は有るけど、うちのところで基準にしてるソースでSSIM拾った感じはこんな感じになってる >>354
こういう理論的なものと経験則が合致してたらちょった嬉しい
ちなみにx265は --rect --limit-modes を付けたときの画質向上率が凄いと思う ようやくAV1が表に出てきたと聞いて飛んできました
自分の使い方だと265は264比で大体エンコ時間3倍強でサイズ3割減ぐらいかなぁ
コーデック乗り換えって労力大きいから、ここから乗り換えるとなると
AV1には相当頑張ってもらわないとならない >>356
rectはブロックサイズのパターン増えるから捜査処理増えるるけど縮むよね
個人的にはrect入れるならampも入れちまう様にしてる（更に遅くなるけど
※両方とも初期値で無効、ampはrect有効時のみ使用可
あとは--limit-modesはplaceboプリセットじゃないと有効になっていないはずなんで記述する必要は無いかも
比較測定値的なSSIMは下がるけど、人間の知覚的判別しづらいところで圧縮稼ぐpsy系オプションも面白い
psy-rd（デフォルト0.3）とか、表示環境のパネルサイズや解像度に合わせてとかで上げてやると量子化が捗る >>358
aviutlのGuiEXだとslowプリセットでlimit-modesも有効になる
揚げ足をとるみたいだけど今の--psy-rd のデフォは2.0のはずだよ
x264と同じくx265も、ギリギリのSIMM値を狙うなら半分ぐらいでちょどいい（--psy-rd） HEVC/H.265対抗の動画コーデック「AV1」が正式リリース
〜ロイヤリティフリーで利用可能、HEIF対抗も登場か
https://pc.watch.impress.co.jp/docs/news/1114268.html >>343
いまどき同軸ケーブルだの分波器だの時代錯誤だわな
B-CASカードの次はACASチップ内蔵で利権ウマウマ ACAS＋HEVC＋ACASで海外家電メーカーの参入妨害
利権大国日本 >>360
なるほど、支障が無い限り更新していないから自分バイナリはプリセットが古いのかもしれない、thx
psy-rdは処理的にピクセル単位の径なんで1.0以下が良いね
動きに対する対応考えればそこから1/2なり1/3するイメージで、逆に動きが無ければバイピクセルな1.0にという感じかと
…とここらへんにしとくか 将来、「放送」で生き残るのはＮＨＫだけかな
民放は系列がだんだん減っていくね。
特に危ないのは、フジ系とテレ朝系 HM比でMH並みの標準実装・最適化で1.3倍の圧縮効率なんだろうし
H264比で約2倍を謳っていたH265/HEVCが、実効ではアベレージ1.6倍程度な事考えると
エンコーダがより重くなるのは確かだし、実質ライセンス料の影響が殆ど無い、個人運用の自炊エンコ用途で何処まで期待して良いものか
x265水準で作り込まれたとしは重くなりそう
上の方で有るみたいに、x264で重いプリセット使うよりはx265で軽めのプリセット使う方が軽くて縮むみたい範囲で使える範囲なら良いけどな 逆に同じビットレートなら、x264よりx265の方が高画質になる？
その時もやっぱりx265の方が、1.4倍くらい時間かかるかな？ 個人的にはx265から1割削れて時間5割り増しぐらいに収まれば御の字だと思って居る 符号化性能うんぬんより、特許料ってそんなに重かったのね。新興のコーデックIP会社が中国、アメリカからたくさん出てきて、技術的に枯れるといいなぁー。 圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
と、最近ファイル圧縮のZstandard型式ってのを知って思った
いや、ハードウェアエンコードすりゃいいってなるけどそれじゃつまんないし…
設定次第で早さか圧縮率かを上下幅広く調節できるようなのが見てみたい >圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
それだと旧規格のh.264で十分ってなる
2018/03/29時点のAV1エンコーダー/デコーダー(aomenc.exe/aomdec.exe)のヘルプ
https://pastebin.com/SsJtwwhX AV1でね・・・1920x1080の10フレームだけをi7-4702MQでエンコードしてみたんです。
全然結果が返ってこなかったのでそのまま寝て翌日確認するとそこには・・・
気になる結果は以下のリンクをクリック！
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3482.jpg
-cpu-usedを0〜8に変えてみたけど、
エンコード速度は0.00253〜0.06101(fps)という結果に。
本領を発揮するのは -cpu-used 0 or 1 だと思うけど、
-cpu-used 0 だと、10フレームエンコードするだけで66分。
1分半のソースをエンコードしようとすると10日かかる計算になった・・・。 非現実的すぎる処理時間に見合う価値は今のところ存在しないな スピードは結局改善しないままリリースしたんだな、HWエンコでどこまで早くなるかにもよるけどかなり厳しいだろこれ
YouTubeとか、これから新規にアップされる動画のエンコとか出来るのか？さらに既存の動画をエンコするのとか不可能に近いのでは 動画エンコードは、GPUとかの超並列化の恩恵受けられないんですかね >>383
ハードウェアエンコードもGPGPU（シェーダ）ではなくて動画処理専用固定回路でやってるから、
GPGPUだとやりにくいんじゃないの 中身的にはSIMD頼みの力押しでマルチスレッド化が進んでない感じ
デコーダも同様というか、H265以上に設計レベルで再生に掛かる演算負荷軽減する気無さそう
最初っからハード屋抱き込んだアライアンスになる訳だわこりゃ x264 mediumくらい縮んでx264 mediumより速くて使用料タダ
のが欲しい x264でもopenCL使えるやん
SIMD使うより速いぞ GPGPUの話は前スレでバトルあったのでそれ参照。
結論としては、
x264やx265の開発に実際に関わってる人の話を聞ければ信憑性高いが、
現状このスレにいる人の知識では何を信じていいのかわからんってことにww AV1のエンコってwaifu2Xくらいかかんのか…いやニューラルエンジンがある今はAV1の方が… 各エンコーダのプリセット毎に、VMAFスコア、SSIM、エンコード速度を計測して図にしたので置いときますね。
対象はQSVEnc(H.264)、x264、x265、VP9。速度のとこだけAV1も。
VMAFやSSIMはただの指標なので、最終的に信じるべきなのは自分の目と感覚だということを忘れずに。
VMAFスコア/ビットレート図
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3483.png
SSIM/ビットレート図
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3484.png
エンコード速度と設定等
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3485.png 適したスレが無さそうなのでここで聞くけど
BRAVIAで再生する時、XAVC S 30p 100Mbpsと60p 150Mbpsってどちらが高画質だと思う？
モーションフローで30pも60p化されて再生されるとして
30pは60pの半分しかフレーム数/秒がないけど、ビットレートは2/3あるから1フレーム当たりの情報量は30pの方が33%多い
パッと見モーションフローは、かなりきれいに中割りコマ生成してる、時々破綻してるけどw 画質なら30のほうが良いだろうよ
24にすればもっと画質は良くなるぞ 昨日今日規格が固まって普及はこれから、ってのが次世代じゃなきゃどんなのが次世代なんだ
規格が決まった瞬間あらゆるデバイスやサービスに浸透するわけじゃ無いんだぜ？ ああXAVCの話か
HEVCもこのスレの対象なんで仲間にいれてあげてもいいんじゃない？ >>393
解像度が書かれてないと思うけど
フルHDならHEVC, h.264ともに10Mbpsあれば十分なことを考えると
両者ともに高画質だと思う HEVC専用スレの方ももうちょっと活用されてもいいのにとは思う >>393
でも60pの方がフレーム間の差が小さいから、圧縮効率良さそうじゃない？ こんなスレで業務用途のコーデックの話なんか聴いても、まともに答えられるやつなんかほとんどいないだろ
このスレにいる奴の大半はアニメのエンコードばかりしているようなのばかりだ 単純に考えて、100Mbpsで30pなら60pの場合は200Mbpsで同等画質じゃないのか？そんな簡単な話でもないんかね？ GOP的な圧縮は画像シーケンスと違って差が小さければ圧縮効率良くなるなら60pはその分圧縮率上がるのでは？
190Mbpsになるのか150Mbpsになるかは知らんが。 30→60だとフレーム間予測が効いて、順当には必要ビットレートは増えないと思うけど
ビデオカメラのリアルタイムエンコードだと、そうでもないのかもしれない 元ソースが30pとして、単に補完フレームの破綻防止に同じ画の繰り返しでもフレームレート有った方が良いのなら意義はあるのだろうけど
データ容量的に1.5倍の価値が有るかの判断は視覚評価だし、基準は当人であって他人じゃ無いしな
再生するデータの動き内容とか、そのTVの性能に依存するものだし、そもそも他人が容易に判断付くものじゃない
こんな事他人に頼る個人が生成出来るソース規模でも無いし、著作権的にアレな4Kデータとかじゃねーの？
スルーで良いと思う 確かに30pより60pの方が差分が小さくて、処理も軽くなりGOP圧縮効率上がる
QFHD150Mbps 60pってのは、LongGOPならなかなかいい線かも？
30p 1/60シャッター、24p 1/48シャッターでパラパラ撮ってるものがほとんどで、TVのように再生側ハードで倍速や4倍速120pなんてのも普通にある現状
圧縮効率とコマ数とビットレートと3つの相関を知り尽くしてる人なんて、メーカー技術者の上位数人くらいか >>393
正直コーデック関係ないし、モノによる。
カメラスレかHTPCあたりで聞いた上で自分の目で判断すればいいんじゃないの。
【4K30P】ビデオカメラに60Pは必要か？【FHD60P】
http://matsuri.5ch.net/test/read.cgi/vcamera/1464428710/
【HTPC】動画を高画質に再生しよう Part10
http://egg.5ch.net/test/read.cgi/software/1436198643/ >>408
半というか完全に民生向けじゃないの？
でも4K 60p 150Mbps で撮影できるカメラって民生用であったっけ？
ハンディカムやαシリーズでも4K 30p 100Mbpsまでしか対応してなかったような >>411
そう民生向けだけど、FDR-AX1だとXAVC SでQFHD 60p 150Mbps XQDに撮れるから、この構成や性能は業務機
https://www.sony.jp/handycam/products/FDR-AX1/feature_1.html AV1 Is Finally Here, but Intellectual Property Questions Remain
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=124134
> According to the AOM representatives, at NAB several members will show
> 30-40% better quality for UHD 4K videos than VP9/HEVC.
> Encoding times are currently about 100X slower than VP9, which they feel will drop to 5X by the end of the year.
> For decode, AOM is currently about 5X slower then VP9 on the x86 platform,
> which should drop to 2X by the end of 2018.
・AV1ではUHD 4Kの品質(圧縮効率)がVP9/HEVCと比べて30-40%向上する。
・エンコード速度は現状ではVP9の100倍遅いが、2018年末には5倍くらいにまで下がると思われる。
・デコード速度はx86環境だとVP9の5倍遅いくらいだが、こちらも2018年末には2倍程度に下がると思われる。
その他、特許面の話なども含む良記事。 4KをQFHDと呼ぶのが主流なの？
それはさておき、そもそも補完される画は完璧じゃない(当然破綻もある)から、それ考えると60pの方がいいとは思う。
破綻しないような簡単な映像なら30pも60pも差は出ないだろうし。複雑で破綻するような映像ならば60p一択だろ。
蛇足だが、フレーム補完は無視して、フレームレートは30pでいいというなら、単純に考えて画質は30pの方がいい。 100by遅い→使いものにならないと自白
年末まで待て。それでもかったるい結果が予想される x265もリリースしたての時は全然速度出なかったろ
いきなり最適化されたものが出てくるわけない ハードエンコの有無っぽい数字だな
VP9はある程度立ち上がって
誰でも効果を確認出来るし…
決まったかな？ 30%程度の効率改善程度では、コーデックを切り替えるほどの意味はない
せめて平均で50%の改善がないとな >>413の記事から更に抜粋。
> According our conversations, AOM expects AV1 decode in several browsers
> and some content from member companies over the next few months.
> This will be followed by hardware implementations in about 12 months
> that can be integrated into devices that will ship in early to mid-2020.
>
> Given the AOM membership, AV1's success in the streaming marketplace seems almost assured,
> particularly given that HEVC has made little progress to date in markets other than streaming to Smart TVs.
数か月以内に複数のブラウザでAV1のデコードがサポートされ、対応コンテンツが出てくることが期待される。
その後約12か月でHW実装され2020年半ばまでには製品が登場するだろう。
HEVCは(主にクソライセンスのせいで)ストリーミング市場ではスマートTVへの配信に使われてる程度で
それ以外はプゲラッチョだし、AOMの参加メンツは豪華すぎてやべーので、
AV1のストリーミング市場での成功は約束されたようなものだ。 UHD-BDだけならともかく、放送にも採用されたHEVCをプゲラッチョとか、頭悪いにもほどがある いや、ストリーミング市場限定の話として書いてあることくらいわかるだろ・・・ 記事の紹介や和訳には感謝だけど、個人の主観混ぜ込むのは誘導にも似た効果も含むから控えた方が良いと思う そもそも、ライセンス料払いたくないストリーミング業者向け作った規格だから >>423
原文は示してあるし特に主観ってわけでもないんだけど、ややふざけすぎた感はあるので気を付けます。 >>426
気にすんな。全然OK。このくらいがむしろ好ましい
細かいことに突っ込んでくる神経質なやつは必ずいるものだからな 個人運用の範囲じゃライセンス問題の影響極小だし
コンテンツ提供側は金儲けに直結してる分ライセンス料取られるから必死だけどね
HEVCはコンテンツ当たりにのライセンスフィーはディスク1枚当たり$0.0225、データで1タイトル当たりなら更に半額で、ストリーム配信なら無料
ハードウェアもライセンスが一番高い4Kテレビで1台で$2以下、モバイル端末は$1しない
安価なセットトッブボックスで価格の〜1.6%程度
大抵は対応プロファイルの範囲が限られるのでもっと安くなる
消費者の立場として、コンテンツの消費に掛かる額は数円とか、再生機器でも4Kテレビや高価な機器でも2百数十円で、消費意欲を左右するレベルじゃ無い
代理店や問屋の流通での中抜きの方が遙かに影響が大きい
扱い量が大きい事業者側はそれなりに纏まった額になるから、払わないで済むなら払いたくないから、単価の具体額示さず「ライセンスガー」と後押しを求める方向の風潮を作りたがる
事業者は最低$25000/年取られるが、$4000万/年の支払額上限もあるうえ
更に多くの場合は現地の源泉税の控除分が適応した分の実質支払いで済んでたりもする でも、そもそもパテントのことをぎゃーぎゃいうなら最初からvp9でよくね?仕切り直して新しいコーデック作りゃなんとかなると思ってんのか。googleは孤軍奮闘で今まで頑張ってたが。他の配信企業なんなんよ。 VP9は悪くはないが4K8K時代に使うには圧縮効率が物足りないし、
Googleが孤軍奮闘してるだけじゃ普及も進まないからアライアンス組んで新規開発したんだと思うけど。 4K8K放送のcodecって決まってるんだっけ？
今年12月だからあと8ヶ月か Netflixとかはやっぱオリジナルコンテンツだけでも全部4kで配信したい！って考えてるんじゃないかな、そうなるとVP9やHEVCでは足りないのかもね。日本の平均ネット速度は17Mbpsらしいけど世界平均は6Mbpsらしいし >>430
ネットを主軸に活動してる主要企業が集まることのほうが重要なんでは 放送波のTSを4:2:0の無圧縮720p化したものをソースにして、AV1のサンプルエンコーダ（自前ビルド）とx265比較してみたが
VBR 2Mbps（ピーク4Mbps）でエンコした結果でSSIMの差がどれほどになるか拾ったらこんな感じになった
AV1 VBR 2Mbps 2pass SSIM : 0.994955
x265 VBR 2Mbps 2pass medium SSIM : 0.995126
x265 VBR 2Mbps 1pass medium SSIM : 0.994888
x265 VBR 2Mbps 2pass fast SSIM : 0.993843
今のところAV1の2passはx265 mediumプリセットの1passと2passの中間の品質にしかならんかった（あくまでSSIM基準でだけど
ただしエンコーダのソース読んでる訳じゃないので、もしかすると画質のわりにSSIMが下がりやすくなる視覚的圧縮みたいなものが有効になっている可能性があるのと
VBRでの比較なんでビットレート配分のロジック出来とか、方式的にHEVC同様ブロック配置の決定ロジックとかの作り込み具合にも大きく左右されたりもするんで
あくまで現状でのサンプルエンコーダでの参考値として留意しておいて欲しい
やっぱx265が変態過ぎるんだな まぁそれでもUltraFast〜FastプリセットよりSSIMが上にはなってることは確かだから、素のHEVCだけよりは高画質なのは確かなんだろうけどね
x265相手でコレなら、x264にすらオプション巧く使われたら追いつかれるかもしれない
OpenSourceのプロジェクト化されて、x264やx265の開発やってる連中がソフトエンコーダ開発に参画してくれば化けるかもだけど、x265でも手が回ってない部分も有るし難しいかなぁ >>437
ネット主軸の事業者は、貧乏なところが多いし、事業自体が短命に終わっているケースが多いから、数を集めることに意味はない >>440
Google, NetFlix, Amazonが貧乏で短命とな まあ意味の取り違えとかには気を付けるとして．．．
H.265/HEVC特許暗黒時代 - Qiita
https://qiita.com/yohhoy/items/c2579097a507b1fbdddb
Twitterによると、FAQとかが更新されたそうだ。
・・・そして３月頭にTechnicolorがInterDigitalっていうパテントトロールっぽいところに
特許を売り飛ばしたそうで、HEVCの特許問題の状況は更に悪化したそうだ・・・。
Technicolor Agrees to Sell to InterDigital its Patent Licensing Business | Technicolor
https://www.technicolor.com/news/technicolor-agrees-sell-interdigital-its-patent-licensing-business
【トロール動向ウォッチ】 トップ11社提訴件数推移｜知財情報｜日本技術貿易株式会社
http://www.ngb.co.jp/ip_articles/detail/965.html
開発企業が特許で利益を得ようとするのは当然のことで仕方ないとは思うんだけど、なんともなあ・・・。 売って開発企業が利益を上げたところでトロールだけ制裁加えれば問題無い トロールなんかに金払う必要ないわ
とっくに消尽されてる特許に値札なんかつかない パテントの一次受けが決まっているんだから、それを飛び越してライセンシーに請求しても、HEVC Advanceと契約してパテント料支払っているんだから、HEVC Advanceに請求しろとなる
トロールの連中が勝手に関連特許のライセンス条項変えても、それを監視して対応するのはHEVC Advanceだからな
ライセンサーのHEVC Advanceには請求通るかもだが、関連特許保有者がHEVCライセンシーへの直接請求を通すのは難しい >>438
激遅な上に画質も大したことない
完全な死に規格だな… HEVC Advance、更に新規ライセンサー、ライセンシーを加え、その推進力を強調
https://kyodonewsprwire.jp/release/201804042642
一部抜粋
> 独立系ライセンス アドミニストレータであるHEVC Advanceは、増大するライセンサー及びライセンシーリストに
> さらに新規企業が加わったことを発表した。AcTi、EverFocus Electronics、Fraunhofer、GoPro、日立工機、
> Humax、KAIST、Korean Aerospace University、Korean Broadcast System、TechniSat、
> Telestar及びWestern Digital社が含まれている。この発表は、HEVC Advanceの最近の決定である、
> インターネットストリーミング、ケーブル、無線通信放送や衛星を介した、非物理的HEVCコンテンツ配信に対して
> ライセンス及び実施料の徴取を行わないという同社の決定に対する市場からの好意的な反応の中行われた。 え？ HEVC>VP9だろ？
世代的にもVP9の方が一つ遅いって認識なんだが…
VP9→HEVC→AV1なのでは… 早い遅いはコードの差も有るから、コーデック自体の比較では何とも言えないでは？
画質容量比的なものなら、H264＜VP9≦HEVC≦AV1 ぐらいで、あとはエンコーダ実装次第で前後するだろうけど >>378ですが、現在のffmpegのlibaom-av1は、-tile-columnsに未対応だったので、
それが使えるaomenc.exeも使って測りなおしました。
ソース： 1920x1080 10フレームだけ。-cpu-used毎に計測。
●自ビルドしたaomenc.exe で --tile-columns=3 をつけてタイル分割エンコードした場合
エンコーダ： aomenc.exe-20180401-0.1.0-9011-g0ec805145
結果： 0.0054〜0.1046fps
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3488.jpg
●自ビルドしたffmpegでエンコードした場合 （現時点では-tile-columns指定不可）
エンコーダ： ffmpeg x64 20180403-N-90590-g197a4e8fee (libaom 0.1.0-9028-geeda6d2de)
結果： 0.0029〜0.0597fps
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3487.jpg
●Zeranoe ffmpegでエンコードした場合 （現時点では-tile-columns指定不可）
エンコーダ： ffmpeg x64 20180402-N-90578-g02ae52db87 (libaom 0.1.0-9012-ge83c6624f)
結果： 0.0004〜0.0275fps
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3486.jpg >>453まとめ
●--tile-columns=3をつけることでエンコード速度は2倍くらいになる。
ただ、無しの場合に12%程度だったCPU使用率が100%くらいになるのに2倍程度にしかならないとも言える。
●Zeranoe版ffmpegのエンコード速度がやけに遅い。MABSで57.5分だったのがZeranoeだと378.2分。
libaomのビルドをミスってる可能性があるので連絡済み。反応待ち。
ちなみに自ビルドにはmedia-autobuild_suiteを利用。
ffmpegは--enable-libvmafにしたので自動的に--disable-w32threadsに。
jb-alvarado/media-autobuild_suite
https://github.com/jb-alvarado/media-autobuild_suite
実行して質問に答えるだけでMSYS2/MINGW-w64/GCCのビルド環境を構築して、
最新のffmpeg/aomenc/x264/x265などを自動ビルドしてくれるのでありがたい。
L-SMASH（-Works）の自ビルドにも流用できる。 再度の検証お疲れ様
気になる点
何で一般的なGOP長に満たないフレーム数を使用しているのか
一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
あと、SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない >>455
> 何で一般的なGOP長に満たないフレーム数を使用しているのか。
> 一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
そうなんだけど、見てわかるとおり、今のAV1エンコードは死ぬほど時間がかかるから。
とりあえずFHDのエンコード時間の目安を知りたかったというのが今回の一番の目的。
VMAFやSSIM等はついでに測っただけ。
次は長めのサンプルも試したいが・・・時間かかるのを覚悟でFHDに挑むべきか、妥協して解像度を下げるべきか・・・。
> SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
x264やx265の--ssimで出力されるのが SSIM Mean Y なのでなんとなく。Allを拾った方がいいかな？ 適当なスレというか板がないのでお知らせ程度に
・ロスレス圧縮技術MPEG-4ALSを用いたコンサートホール演奏の
ハイレゾライブ配信サービス商用化に向けた説明会について
http://ottava.jp/news/2018_0404.html
HEVCと同じく次世代放送にて採用決定済みのMPEG-4 ALSを使ったライブ配信に関する話題 場所が無いにしても、不可逆それも画質容量比と効率が主題の次世代ビデオコーデックのスレでも板違い
情報提供で投下スレ無いならニュース行きか、ピュアAUかAV機器で捨てスレ起こせ
ハイフレームレート4Kライブ伝送を実現するHEVCコーデック。NTTが開発
https://av.watch.impress.co.jp/docs/news/1115550.html
>>457
ffmpegでやってるよ。
>>453補足
aomenc.exeの設定はffmpegとあわせたつもりだったんだけど、aomenc.exeで--tile-colunmnsを外してみたら
自ビルドffmpegの1.5倍くらいの時間がかかったので、何か見逃してる設定があるのかもしれない。 https://developer.nvidia.com/nvidia-video-codec-sdk
What's New in Video Codec SDK 8.1
・Completely re-designed modular sample applications for easier integration into target applications
・New feature enabling the use of B-frames as reference frames to improve overall encoding quality for H.264
・Added support for real-time HEVC 4K@60fps with recommended drivers
・New API to specify region-of-interest for applications having prior knowledge of video frame.
This feature works well in conjunction with image area classification feature (part of Capture SDK 7.0) >>461
ビデオコーデックSDK 8.1の新機能
完全に再設計されたモジュール式サンプルアプリケーションにより、対象アプリケーションへの実装が容易になりました
H.264のエンコード品質を全体的に向上させる新機能として、Bフレームを参照フレームとして使用できる様になりました
（効果としてフレームの差分データ量がより節約出来るので、画質容量比が向上すると思われる）
推奨ドライバでリアルタイムHEVC 4K@60fpsのサポートが追加されました
アプリケーションから、先行取得されたビデオフレームにおいてマクロブロックに品質指定を行う新しいAPIを実装しました
この機能はイメージ領域の分類機能（Capture SDK 7.0の一部）と連携して使用出来ます
（マクロブロック単位の可変品質エンコードを可能にする実装っぽい、手間が増えるがCBRやVBR、固定品質で画質容量比の改善が望める） 最後については、手法的には前からある（x264とかには既に有る）実装
AV1対応の過程でAV1の標準エンコーダに有る機能で既存コーデックに使える機能は、出来た分は先に出したよ感がｗ Bフレームの参照の方は、Bフレームが続く場合にPフレームからの差分では無くBフレームからの差分参照出来る様になるんで、動きが少ないとか、ブロック単位でズレるだけみたいな場面でより縮む様になる
Bフレーム使う話なんで、Bフレームが使えないNVEncのHEVCには関係無し（ぉ このSDKを使うのはNLEやエンコーダ各社？
NVEncはBフレーム使えないのは、このSDK過去版が使えなかったからではなくて？
>>464 >>465
NVEncではH264なら元からBフレームも使えていて
HEVCだとマクロブロック捜査の方に手間食われて低レイテンシ維持出来ないから、HEVC対応したNVEnc積んだGefoce出た時からずっとBフレーム無しで、それが仕様とされてきてる（それでも当社比でH264より縮むんだけどね）
NVEncのHEVCでBフレームも有効になっていたら、SDKとしてデカいトピックすぎて書かない訳がないぐらいのネタだし、関連設定に関わる資料が追加されてるはず >>463
> 最後については、手法的には前からある（x264とかには既に有る）実装
AV1のROI Mapや今回のNVEncのEmphasis Mapはフレーム内の領域を直接指定して
そこの品質を調整する機能だと理解してるのだけど、x264にそれに該当する機能ってあるっけ？
--zonesや--cqmとは違うし、それ以外にそれっぽい機能が見当たらない気が。
あとドキュメント読んだら、Emphasis Mapはレート制御後にターゲット領域の品質調整を行うから
VBV違反のリスクがあるって書いてあった。
>>466
> HEVCだとマクロブロック捜査の方に手間食われて低レイテンシ維持出来ないから、
> HEVC対応したNVEnc積んだGefoce出た時からずっとBフレーム無しで、それが仕様とされてきてる
その説明ってどこでされてたんだろ？情報源あれば教えてほしい。
遅延が問題なら低遅延が求められる時だけBフレームを切ればいいだけだと思うんだけど・・・。
2015年のロードマップだとHEVCのBフレーム対応も予定されてたみたいだけどどうなったんだろね。
http://nico-lab.net/nvidia_gpu_encoder/ 要するにハードウェア的にはBフレームに対応してるんだけど、それを動かすソフトウェアの開発部隊がカスしかいなかったんだろ
で、やっとまともに扱える奴が入ってきたから、まずH.264で使えるようにしたと
この流れならばいずれHEVCもやるでしょ
あとは画質次第
いくらオプション対応しても画質が伴わなければ意味はないから
もっとも、NVIDIAを語れるような目利きがいた試しはないが 最後、「NVIDIAに画質を語れるような目利きがいた試しはないが」に訂正 >>468
>>466も言ってるけど、NVEncではH.264なら元からBフレーム自体は使えていたよ。
HEVCの場合だけ「最大Bフレーム数はゼロだよー」と返してくるので使えなかったというだけのはず。
今回のSDK8.1での変更は、「（H.264で）Bフレームを参照フレームとして扱えるようになった」というもの。
H.264ではBフレームは元から使えてたけど、更に機能追加したよという話。 >>464
Bフレームを参照フレームとしてというのはいわゆるb-pyramidのことでは
>>467
（下段について）
たぶんASICとかの作りこみを省いてるんだと思う
機能的には充実してるAMDより断然早かったし
h.264対応済みハードをできる限りいじらずに実装したのが今のNVEncだと思う >>472
> 機能的には充実してるAMD
AMDのVCEEnc(AMF)は
・HEVC main10に非対応 (QSVとNVEncは対応済み)
・Polarisでは何故かH.264でもBフレームが使えなくなった
・QSVスレで行ったSSIM/ビットレート図による比較では最下位
http://mevius.5ch.net/test/read.cgi/avi/1486130737/335
と、一番酷い状態のような・・・。
>>122で書いたようにVP9のHWデコードも迷走してたし、大丈夫なんだろうかって感じがする。
RavenRidgeはちゃんとVP9のDXVAデコードができるらしいけど。 >>471
だからそれ、ソフトウェア開発部隊が使えるはずの機能を使えない状態にして放置してたからだろ
結局、カスであったことに変わりはない >>473
だから「機能的には」って「には」を付けたんだな >>477
なるほど。（ただ、エンコード機能的に何か充実してるんだっけ？という素朴な疑問はある。エンコード以外の機能込み？） >>478
2Pass（おそらく先読み）によるレート制御とかBフレーム使える（Polarisでは無効化されてる？）とか機能的には充実してると言ってもいいのでは
それらを実装してるから高画質とは限らないだけで・・
ま、EU（GPUコア）使って柔軟に進化してるQSVは別格として
nvidia、AMDともにゲームの配信とかゲーム画面のキャプチャ向けの高ビットレート録画って割り切ってる感はある http://egg.5ch.net/test/read.cgi/software/1487682297/568-571
Zeranoe版ffmpegでlibaomのビルドミスがあったので、
AV1の検証をするなら20180405-e54679b以降のバージョンか、自ビルドのffmpegやaomenc.exeで。
libaomの方も頻繁に更新されてて、原因はよくわからないけど同じ設定で前より遅くなったりもしてる。
aom 0.1.0-9082-gab1e1db19のaomenc.exeでクラッシュするケースもあったし、安定するのはまだまだ先かな。 xiphmont | next generation video: Introducing AV1, part1: Chroma from Luma
https://xiphmont.dreamwidth.org/91643.html
next generation video: Introducing AV1
https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml >>482
画質は上々そうやね
x264のデフォルトの1万倍近く遅いみたいに見えるけど。
英語はよく分からないので100倍であって欲しい。 >>483
x264のデフォルト(--preset medium)ではなく、--preset veryslowと比較して、
AV1は品質指定モードで平均5869.9倍、ビットレート指定モードで平均8139.2倍のエンコード時間だね。
ただし、
●テスト環境のスペックが書かれていない。
●x264はスレッドを活用してるけど、AV1は --tile-columns 0 なので
タイル分割エンコーディングを行っておらず、スレッドをほぼ活用できていない。
●当然ながらAV1のリファレンスエンコーダであるaomencはまだ最適化もされてない。
といった点には留意する必要があるかな。
VP9の方も同じ --tile-columns 0 でやってるので、品質指定モードでVP9の658.5倍、
ビットレート指定モードでVP9の667.1倍のエンコード時間という方が目安としてはいいかも。
まあ普段自分でVP9エンコードしてる人ってほぼいないだろうからわかりにくいけど・・・。 >>484
veryslowと比較してなのか…スレッド数で1桁速度が変わったとして現状x264 midiumとの比較で2000倍程度速度差があるという認識でいいのかな
x264やx265は発表から数年で速度はもとより画質も素晴らしく伸びたように思うので少なくとも今年の終わりまで気絶してから評価した方が良さそうですね AOMのソースのところに書いてあるのと同じサンプルだね
https://media.xiph.org/video/derf/
解像度は各種あるけど、ニュース番組並に情報量低いのばっかりで、マクロブロックサイズのサイズデカいコーデックがそりゃ縮むわなという感じのばっかりなんだよな
x265との比較しないのが謎だし、AOMの中の人なんじゃないかと思ってしまう >>486
記事をちゃんと読んだ方がいいよ。
>>482のFacebookの実験ではderfのサンプル群は使っていない。
Facebookでよく見られてるトップ400のビデオを使っていて、
それらに関する説明（スマホで撮影したSD/HDが多いとか）も書いてる。
x265との比較が無いのは俺も残念。なんでだろね。
HEVCのライセンス料って、調査研究目的であっても請求されたりするもんなんだっけ？
あとFacebookはAOMのFounding memberだよ。
x264も0.148-snapshot-20161114-2245って書いてるけど日付からするとr2727かな。
ちょっと古いけど、まあこれはあまり影響なさそうか。
snapshotの末尾の数字ってずっと前から2245みたいだけど、何を表してるんだろ。 エンコードにH.264の10000倍かかったとしてもエンコした動画を1回しか見ないような俺らに対して
1回エンコするだけで100万再生スタートという次元の配信業者からすれば
俺らより環境にもネットの帯域にも優しいお釣りが出るほどのリターンがあるということ >>489
意味が分からない。10000倍では釣り合いが取れないだろ
ネット帯域が主要命題だったのは10年〜20年前だし x264やx265みたいな魔改造エンコーダがまだ無いからな
対応ハード出るまで1年有るし、配信事業者側が使い始めるのも2年は先だろう
nvidiaがNVEncとCUDAの連携追加し始めていてAV1にも使えそうな実装をSDKでして来てるし
AV1の方がHEVCより物量的処理での圧縮してるから、NVEnc+CUDAの実装で何かしら出してくるかもな
有る程度纏まった形にしてるのはDGX-2みたいなTeslaを使ったコンポーネントとセットで事業者用
GeforceとかはNVEncのみでは最小限で、あとはSDK使って手前らで巧く纏めなさいよとかだろうなぁ NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような画質水準には達していない）しか作れないみたいだから、アテにならんと思うがねぇ NETFLIXなど大手の配信業者も多く絡んでるし可能な限りハードウェア処理し易い設計になってる可能性はまたあるとは思う >>492
リアルタイム配信向けの実装なだけでしょ
短時間に出来る範囲でしかやっていない
同様の事をQSVでやらせると、H264でしか出来ないうえ、NVEncのH264より汚いって知ってた？ >>494
そんな話していないし、したいとも思わん NVEnc自体は、nvidiaのGRIDみたいなクラウドや、LAN内でのゲームのリモート操作のためのもので
それ自体はH264なりHEVCだから、GPUのバッファから生成する以外にも、デコーダからGPUに映像与えてやれば、任意の映像データもトランスコードしてファイルとして保存できるってだけ
ただ要望もあるから、あとからSDK7.x世代以降にCUDA使ってGPGPU的に拡張出来る様になってる
もちろんSDKでのAPI実装やサンプルに頼らず独自でやっても良いんだけど
CUDAエンコーダの頃から独自に拡張する人が殆ど現れない
エンコーダの拡張自体が糞難易度高くて、数学者的な人が実装サンプルや設計組んで、コーディングに特化した連中が最適化を進めるパターンが多い
そういう方々は既にx264やx265の方に集中しちまってる >>489
趣旨はともかく、さすがに10000倍のままってことはないでしょｗ
>>490
>ネット帯域が主要命題だったのは10年〜20年前だし
そんなことないよ。流れるデータ量も激増してるし、世界にはまだまだ帯域不足のところもあるし、
配信業者にとってデータ量の削減は今も昔も極めて重要な課題。 >>492
> NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような
> 画質水準には達していない）しか作れないみたいだから
それを言うなら
・GPUのHWエンコーダはどれも高圧縮/高画質を求める人には向いていない（特に実写等）
・QSVとNVEncは圧縮/画質面では同程度(QSVの方がやや上？)。
エンコード速度はNVEncが圧倒。
・AMFはQSVやNVEncと比較すると一段下のレベル。
AMDのエンコード/デコード機能の出遅れはちょっと心配になるレベルでもある・・・。
という感じだと思うけどな。（根拠は>>473とか）
IntelもNVIDIAもAOMのFounding Memberだし、それなりに期待はできると思う。
AMDはPromotor Memberだけど、エンコード/デコード部門は頑張れるのだろうか・・・。 画質重視でもYoutubeに上げる為にロスレスで圧縮するときはNVEnc使ってる NVEncのロスレスって4:4:4だと聞いたけど、Youtubeはそれも受け付けてくれるのか。
なんとなく弾かれるもんだと思ってた。 そういえばx265のCUSA版があったな
https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder
長いこと更新されてないみたいだから
非主流アーキテクチャ向けの設計は広がらないみたいね
H.265の v5 (Approved in 2018-02-13) の規格書が発行された。
現時点ではダウンロードできるのはTIES userのみ。
H.265?:?High efficiency video coding
https://www.itu.int/rec/T-REC-H.265 詳しくは知らないというか知る由もないんだけど、NetflixとかYoutube（Google）みたいな資本力のあるところでもHWエンコしてるのか？ああいうところって一般人じゃ到底手に入らないようなスペックのコンピューターでSWエンコしてると思ってたんだが >>501
全てがGPGPUでCPUより効率良く処理出来る訳じゃない
x264やx265が高画質化するため手法の極一部だけなんで
大半を処理するCPUが結局ボトルネックになる
それでも僅かにCPUの負担が減るから、その分は微妙に早くはなるけど何割も早くはならない >>503
ああいう規模だからこそ逆に専用のASICボードとか用意してガリガリやるんじゃねーの？ >>503
SWでの高画質エンコードがされるなら
○○向け高画質エンコード（配信サイトで再エンコードされない）設定なんてのに意味がないから
ASICもしくはx264 --tune very fastレベルの高速SWエンコだと思う >>509
> ○○向け高画質エンコード（配信サイトで再エンコードされない）設定
これが何のことを指してるのかよくわからない。Youtubeでそんなことできるんだっけ？
あとつっこんでおくと --preset veryfastじゃね。 GoogleのサービスでH.264トランスコードはx264だっけか 配信サイトで再エンコードされない設定って言うのはよく聞く誤解だね
YouTubeだとどんな動画を上げても再エンコードされる
アップロードしたあと手元の動画とSSIMなりで比較してみたら分かる 昔の実装そのまま今でも一緒だと思っていたり
ニコニコの体の良いシステム負荷軽減手法と同じだと思っているんじゃないかな そりゃyoutubeへのアップロードに関する話題とか昔の流行だもの よくわからんがYoutubeで再エンコードされないようにする設定があると勘違いしてたってことか。 Youtubeは1回エンコされるのは確実として多重エンコにならないようにロスレスで上げるのが基本じゃないの？ >>517
基本ではないでしょ。可逆はサイズもでかくなって面倒だし、
「可逆で上げた場合」と「十分高画質な非可逆で上げた場合」とで
生成された動画に目立った違いは出ないと思うし、後者で上げる人がほとんどだと思うよ。 自分はx264 crf12ぐらいで上げてるな 16と程度と比較するどちらが綺麗かは分かるレベルだったし意味なくは無いと思う。
生成後の動画比較すると画質毎に設定やビットレート多少違うかもね 低いcrfほどエンコーダの差が画質に出てこなくなるから、QSVやNVEncでササッと処理済ませてアップロードし始めた方が手早いかも
放置で下準備させておく時間があるならx264だけど 1080pの335フレームでAV1をテストしてみた。
ソースは進撃の巨人１期OPのサビの立体機動シーン〜大砲発射まで。
結果： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3489.jpg
--cpu-used 3 でx265のveryslowと同程度の品質で、かかる時間は17倍。
--cpu-used 2 だとそれ以上の品質で、かかる時間は100倍。
--cpu-used 1 だと更にそれ以上の品質で、かかる時間は170倍。
(ただしどれも--tile-columns未使用。使えばこの半分くらいにはなるかも。)
--cpu-used 1 だと、x264 veryslowで7Mbps、
x265veryslowで5Mbpsくらいかかるのを、4Mbps弱にするくらいの圧縮効率。
VMAF/SSIMに基づいた評価としてはこんな感じになった。 >>521
これを維持してどんだけ高速化できるかだなぁ libaomはリファレンスみたいなもんだし、まだ最適化もされてないから
今のlibaomのエンコード速度/時間を見てAV1の実用度を判断してはダメだよ。
libaom自体はどこまで最適化されてどれくらい速くできるのかわからんけど、
商用ではベンダーが開発したエンコーダ(SW/HW)が使われるんだろうし。
ちなみに>>521のサンプルでは-cpu-used 3 -crf20で335フレームのエンコードが約3時間4分だったけど、
crowd_run(1920x1080、500frames)は同じ設定で6時間30分かけて100フレームしか進まなかったので中止した・・・。 very slowの17倍って今の段階なら悪く無いじゃんって思ったけどx264ならmidiumの数倍程度だけどx265だと凄いんやね 話題が無いので間潰しにNVEncネタ
NVEncでの同時エンコードは基本的に2つまでと言われているが、実はQuadro 2000番以上とTeslaは制限が無い
あとNVEncエンジンの搭載数にも違いがあり
GK世代、GM107やGM206、GP107〜106 は1基
GM204〜GM200、GP104〜102 は2基、GP100やGV100は3基搭載されていて
搭載エンジン数分までは同時処理をしても処理速度が殆ど落ちない様になっている
例外的なのがGTXGTX1070で、GP104自体は2基搭載だがエンジンが1つ無効化されている
GTX1070TiについてはGTX1080と同じく2基とも有効
なので同じ世代ならNVEnc自体の処理性能自体に大差は無いけど、
エンジンの搭載数によって同時処理（多くの場合は2ウェイ処理）時の処理速度低下具合が変わってくる NVEncの処理速度的については、固定量子化でブン回す場合には、FHDでの出力ならピーク値でH264で600〜650fps、HEVCで400fps前後ぐらい（NVEncのHEVCはBフレーム省略仕様なので速度低下が少ない）
NVDecのデコードはFHDで600〜650fpsぐらいがピーク値になる
あと実行環境（NVEncを呼び出すアプリ）によってピーク値近くで動作させられるかが変わってくるので留意
例えばTVMW6だと、エンコードの前段がボトルネックで2つ同時のバッチエンコにしないとエンジンを回しきれない
お陰でエンジン2基環境の場合はどちらも回し切ることが出来ない はぁ、1080並の値段でELSAの1070なんてかわなければよかったｗ 捕捉
上の速度はPascal世代の速度で、1つ前のMaxwell第2世代だとH264なら2/3、HEVCなら1/2ぐらいの性能になる
Pascal世代でのNVEncのトピックは、HEVC速度低下が少なくなっている事なんだけど、公式なトピックに記述は無いけど、Pascalで動作クロック自体が大きく向上しているので、結果的にH264も含めた全体的なパフォーマンスも相当上がってる
Pascal世代のHEVCについては、性能低下緩和も含めてマクロブロックの捜査ロジックの改善もされている様で、Maxwell第2世代のHEVCより地味に画質が向上されている
NVEncの速度はデフォルトの動作クロックに依存（ツールによるソフトウェアでのOCはCUDAコア側のクロックが上がる仕様）なので、NVEnc目的でグラボ購入する場合には、製品の公称クロック基準で購入した方が良い
ファームウェア操作ツールでクロック上げた場合はそのまま性能に反映される NVEncの性能で考えれば、リファレンスクロックが高く、エンジン2基のGTX1080が最良
次点で僅かにクロックが低いGTX1070Ti
GTX1070はリファレンスクロックはGTX1070Tiと同じだけど前記の通りエンジン1基なので、NVEnc狙いではお勧め出来ない
GTX1080Tiはエンジン2基だけど、動作クロックがGTX1050並なのでEVEncの性能は落ちるし単価が高い
エンジンの単価で考えれば、GTX1050無印が安価
CUDAコア数が少ない分、GTX1050Tiよりクロックで性能稼いでいるので、
動作クロックも高めになっているが、クロックは1つ上のGTX1060より1割落ちる
高いクロックでエンジンを含むGPUコア部（否CUDAコア）を回せるかは、TSMC16nmFF製造かSAMSUNG14nmFF製造（16nmより回らない）か、グラボの電源部の影響が大きい
（それでもGTX1050をファーム改造でGTX1080のリファレンス並ぐらい回す事は不可能じゃ無い GK208はNVEnc乗ってるのにGP108がなぁ こういうGeForceの型番ごとにおける機能の制限/無効化ってどこかにドキュメントとしてまとまってるの？
QuadroとTeslaはHTML上に一覧表が出来てるけど nvidiaのdeveloperにあるみたいな一覧は無いね
海外フォーラムでは日本よりNVEncについて掘り下げてスレが意外にあって
エンジン数についても話題に上がる
GTX1070Tiなんかも、リリース後エンジン数についてスレ立ってた
対応SDKから実機確認すれば解るんで、同時処理数も同様やね そういう情報出さないで売ってるの、なんだかなって思うわ NVIDIAにとっては、エンコーダーの価値はその程度にしか見ていないということ なんでAMDは動画最弱になっちゃったんだろ
動画ならRadeonなんて時代もあったのにね というか、実用面からすると
・NVEncを保存用エンコードに使う人はあまりいない
・NVEncで並列エンコードをする人もあまりいない
・全体的に十分以上に高速なので、高速域での速度差を気にする人もあまりいない
ということで、一般ユーザー的にはエンジン数やエンコード速度の差を重要視する人は少ないのでは。
（「実際に使うわけじゃないけど最高の機能が載っててほしい」という気持ちはよくわかるけど） 公表されてる範囲の機能的なスペックはエンジン1基有れば実現出来るからね NVDec/NVEncのSDKもnvidia的にはターゲットはTeslaやQuadroで、Geforceでも一応使えるという感じだからね
Geforceだからと全モデル1基とかにされなかっただけでも良かったとする鹿
GTX1070の1基のみ有効になってる事ネタにして、nvidiaに纏まった数の直訴なんかしたら、あの会社なら次世代からGeforceグレードは統一仕様として一律1基にしてとかやりかねんｗ >>539
ip変換の質とエフェクトが充実してたって話でデコードエンジン自体はずっとnvidiaの一周遅れだよ アムドの寝言はVP9有効にして
公約果たしてからにしてほしいなw xiphがRustで作ってるav1のエンコーダって話題出てる？
リファレンスより速いって書いてあるけど これか
https://github.com/xiph/rav1e
国内で話題にしてる人は少なさそう、自分も今知ったわ
libaomのコードをベースに入れてるのかな？
他方の資料で
libaomのアセンブラ化で4倍は速くなる、多分100倍速く出来そうだけど、アルゴリズムの書き換えが膨大すぎるわい！
みたいな事書いてあった >>545 >>546
>>122でも書いたけどPolaris/VegaはVP9のDXVAデコードに対応していない。
当初は隠し機能として存在していたそうだが、それも後になって消された。
ただしDXVAとは別にOpenCLによる再生支援が利用できるMFTフィルタがあり、
ChromeやFirefoxはそれを使ってVP9再生支援を利用することができる、という状況らしい。
なおRavenRidgeはVP9のDXVAに対応している。
>>547-548
>>89で出てるね。限定的な実装みたいだし、試したことはない。 ビルドして試そうかと思ったけどビルドできなくて放置してた これcじゃなくてrustなん？
時代はrustなのか？ Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね MozillaのDaalaで使ってたから親和性は折り紙付きだろう 吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
代わりに習得がえらい難しいらしいけど
使用者に最も愛されている言語とか言うけど
愛が無ければやってられない習得難易度の裏返しだったり >>554
Daala作ってたのはXiphだけどな
Xiphは半分Mozillaみたいなものだけど xiphってflac作ったところなんだな
知らなかったわ ハイレゾは全く無意味とバッサリ切ったのが爽快だった https://people.xiph.org/~xiphmont/demo/neil-young.html 耳に聴こえなくても脳に影響してるんだよ
聴覚が全てではない 違いが分かる人と分からない人が
居るだけの話なのに
実際に目の前で見ないと信じられないのが人間 その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
ちゃんとマスタリングしてる物がほとんどだから20khz以上が切れてようがそうで無いものより綺麗っていうのはあるね 自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
なにこれつべのVP9の4K十分綺麗じゃん
なんでこのVP9ってのはH.264やHx265以上に流行らないの？ 俺が事情を理解できてないだけだが理由がわからない
しかもつべの4K VP9ってビットレートたかだが12Mbps程度でこの画質なんでしょ？
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが >>573
x265@フルHDなら1〜3Mbpsでそれなりに見れる画質になるんだから
4ｋで12Mbpsってのは少ないわけじゃない つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが >>573
やってみれば分かる。264や265に比べて死ぬ程遅い
特にx265と比較するとビットレート比画質負けるのは勿論デフォ設定同士の比較で1桁以上、下手すれば2桁が見えてくるぐらい遅い ,．-─ ─-､─-､
, イ)ィ -─ ──- ､ﾐヽ
ノ ／,．-‐'"´ ｀ヾj ii / Λ
,ｲ／／ ^ヽj(二ﾌ'"´￣｀ヾ､ﾉｲ{
ノ/,／ミ三ﾆｦ´ ﾞ､ﾉi!
{V /ミ三二,ｲ , -─ Yｿ
ﾚ'/三二彡ｲ .:ィこﾗ ;:こﾗ j{
V;;;::. ;ｦヾ!V ｰ '′ i ｰ ' ｿ
Vﾆﾐ( 入 ､ r j ,′
ヾﾐ､｀ゝ ｀ ｰ--‐'ゞﾆ<‐-イ
ヽ ヽ -''ﾆﾆ‐ / ググレカス [ gugurecus ]
| ｀､ ⌒ ,/ （西暦一世紀前半〜没年不明）
| ＞ ---- r‐'´
ヽ＿ |
ヽ ＿ ＿ 」 >>580
なんか>>361のリンク先読むとVP9の方がHEVCより縮むと読み取れるんだけど…、
x265ならVP9より縮むって事なんかね？
＞AOMediaのメンバー企業であるBitmovinの検証によれば、同じ画質で比較したさい、AV1はVP9比で22〜27%、HEVC比で30〜43%ほどビットレートを削減できるという。 >>579
つべあげるのに4k60pは60Mbpsあったほうがええのか。。 vp系はバッファ少なくても縮むからストリーミングに向いてて良いわ
mpeg系は再生できるようになるまでが長い Advanced Media Framework (AMF) SDK Version 1.4.7
https://github.com/GPUOpen-LibrariesAndSDKs/AMF
Version 1.4.7: AMD Radeon Software Adrenalin Edition 18.3.4 (17.50.33) or newer
New features are available in
Driver: Radeon Software Adrenalin Edition 18.3.4 Software: 17.50 and later
1.4.7.0 (04.12.2018) version
--------------------------
- 360 video stitch sample
4/12って書いてるのは4/24の間違いだな。 要はbuildコードが4/12って事でしょ
チェックか何かでゴタついたんでしょ Facebook video adds AV1 support | Engineering Blog | Facebook Code | Facebook
https://code.facebook.com/posts/612340875779169/facebook-video-adds-av1-support/
去年11月下旬時点のlibaomをChrome Canaryに盛り込んで
FacebookビデオでAV1のお試しサポートをしてみたよって話。
ブラウザ側で正式バージョンの実装がされたら、そっちに切り替えていくとのこと。 今canaryに来たってことはstableに来るのは4ヶ月後くらいかな
firefoxもchromeと同時期くらいには実装されるだろうか
一番の問題はスマホの対応だけどね >>591
まだ仕様決まってないけど開発中らしい
AV1 Still Image File Format (AVIF)
https://aomediacodec.github.io/av1-avif/
実際の画像での比較
https://people.xiph.org/~tdaede/av1stilldemo/
SSIM Yでの比較
http://i.imgur.com/qw22KHF.png ただし、性能いいけど最適化されてない今だと画像一枚変換するのに60秒くらい平気でかかる ありがと、これで電子書籍の容量減ってくれると助かるなあ
雑誌DLしたら500Mとか食ってるからはやく普及してほしい そういえばハードウェアのエンコードって動画の場合ではソフトウェアよりかなり画質が落ちるけど静止画の場合だとどうなんだろう >>592
ssim0.985辺りで見てみるとjpegに対してのwebmに近い比率でwebmに対してのAVIFは縮むんやね
BPGはエンコードは兎も角デコード重過ぎ&対応ソフト少な過ぎで使い物にならなかったけどwebmの倍までのデコード速度と同程度の普及にはなって欲しいなぁ Appleは最近画像フォーマットにHEVCベースのHEIFを使ってるけど、
AVIF完成したらAVIFに移行するんかな。
もしそうなったらスマホ用サイトの画像フォーマットにAVIF普及しそう。
>>595
動画ほどソフトとハードでの画質の差は出ないと思うよ。
一枚絵の画像だとソフトとハードの差が出やすいフレーム間予測による圧縮がないので。 ソフトとハードでどのくらい違うか気になったので>>592のグラフにx264とh264_qsvを追加(項目名クリックで表示切り替え可能)
https://plot.ly/~fg1189467/33/
まあ少し落ちるけどこれくらいなら許容範囲かな Next-Generation Image Compression (JPEG XL) Final Call for Proposals
https://jpeg.org/items/20180423_cfp_jpeg_xl.html
これAV1じゃないの JPEG-XL >60% over JPEG-1
MPEG-H(HEVC) >60% over MPEG-1
WebP2(≒AVIF) >15% over HEIC 姉妹規格のJPEG XSは来年完成らしい
ビジュアルロスレスというとDisplayPortのDSCコーデックみたいなやつだな
オープンフォーマットJPEG XS、画像符号化史上初のパラダイムシフト
https://this.kiji.is/361078960999941217/amp
JPEG XS標準化プロセスの開始は、2016年のJPEG 71回目の会合にて承認された。JPEG XSは、超低遅延、電力、帯域幅の要件だけでなく、実装が簡単なアルゴリズム、少ないメモリでも動作し、そして長いケーブルランをサポートすることを目的にしている。
コアコーディングシステムは2018年7月に完成予定で、リファレンスソフトウェアを含んだ全体の完成は、来年2019年4月に予定されている。 JPEG XSコーデックメモ
https://qiita.com/yohhoy/items/897a543cde9123e6e461
JPEG XSコーデックは、低計算量・低レイテンシが要求されるアプリケーションにおいて、主に「Mezzanine(舞台下の)コーデック」としての利用が期待されている。
ライブ・プロダクション
放送・デジタルシネマ ワークフロー
プロ向け映像市場
KVM1アプリケーション
VRゲーム など
JPEG XSは、従来の(無印)JPEG, JPEG2000, JPEG XR, WebP, HEIFといった大量データ保存・WEB配信向けコーデックを 置き換える技術ではない。 HDMI2.1もVESAが規格化したDSCを採用するみたいだな。もうDPと統一しろよ
https://av.watch.impress.co.jp/docs/series/dg/1100970.html
DSC(Display Stream Compression)はDPCM(Delta Pulse Code Modulation)とICH(Indexed Color History)をベースにしたリアルタイム性に優れた圧縮技術で、設定した圧縮率で安定した圧縮結果が得られる特徴を持つ。
ただし、圧縮したデータは元のデータには戻らない、いわゆるロッシーな(ある程度の劣化を許容した上で活用する)映像信号圧縮技術になる。
MPEG系のような、過去から現在の映像フレーム同士の相関関係を利用した圧縮技術は、元のデータに対して数百分の1にまで圧縮が可能だが、DSCは時間方向に伝送されててくる一次元データストリームの圧縮なのでたかだか数分の1程度の圧縮率に留まる。
その代わり、低遅延で高速リアルタイムに圧縮展開できる利点がある。
ちなみに、このDSCロジックのIPコアを開発したのは半導体IPメーカーのHardentだ。 jpegの牙城はH.264より堅いだろうから新画像コーデックを広めるのは厳しいだろうな…
MSとAppleとGoogleが足並み揃えてゴリ押ししたらいけるかも？って感じ ありゃJPEG XLの技術公募締切が9月に延期されてる
公開目標時期は2019年10月か
AV1採用してくれ >>604
そのメンバー全員Alliance for Open Mediaに加盟してるし、MozillaやFacebookやNetflixもいる。
Appleしか推してないHEIFやGoogleしか推してないWebP、Microsoftしか推してないJPEG-XR
とはかなり状況違うから今度は期待できそう。 VP9は画質で判断するとたまにH264よりサイズでかくなるから困る。圧縮するなら相応の力を見せてくれないと
中途半端だ >>603
HDMIがロッシーになるのか
マウスカーソルの周りにブロックノイズとか出たら嫌だな 8Kくらいまで解像度を上げない限りは非可逆にはならないと思うぞ >>608
そこまで圧縮しないから大丈夫だと思う
問題は低延滞だが延滞は有るというあたりと、表示機器側でデコーダ積まなきゃならないから、対応すると素で単価が上がる >>606
基本的にアプリケーションの内部処理やサービスとセットで消費者側はデコード主体使う事になるだろうから、個人で生成する事は余り考えなくて良いと思う たしかtwitterはgifをアップロードするとmp4(h.264)に変換される仕様だったような
google photoもwebpに変換されてるんだっけ？
全モダンブラウザが対応するweb標準の次世代画像規格さえできたら
あらゆるサイトでjpeg/png/gifが変換されるようになるはず
運営側もユーザー側もトラフィック削減パケット節約でwin-win AV1が一般人にストレスなく利用できるようになるのは、いつ頃だろうか？
音声の圧縮音声コーデックは、今後MPEG4-ALS（品質重視の用途）かOpus（可聴帯域のみを扱う一般的な用途とリアルタイム通話向き）に収束していくのだろうけど
ところで、音声コーデックの話をするスレ、どこかあるのかな？ ストレスなく利用っていうのが視聴の事なら1、2年で可能だろうけどエンコードの事なら一生来なさそう >>614
アカンがな、それ…
となると、やはり映像はHEVCベースで運用しておくか
音声はフリーのくせにと言ったらおこられそうだが、日常使いではOpusでいいかなと最近は思っている
新しくYouTubeにアップされてる高解像度のものは、元からOpusでエンコードされているから聴き取りやすくていいし
音声メインの素材をアップする人は、積極的に高解像度（フレームレートは1fpsとかにできるのならば、それでいい）でアップしてもらいたい >>612
AVIFはアルファチャンネルやアニメーションにも対応するそうだし、
AVIFに使用されてるAV1は可逆圧縮にも対応してるから、
うまく行けばjpg/png/gif全部置き換えられそう。 >>617
ソフトウェア板にあったのか
DTM板かと思ってたよ
Thx. >>615
Opus気になって調べてみた
で、YouTubeに4K動画でMISIAの音源にいいのがあったので試してみた
確かにいい
ただし、手元のPCで再生するよりスマホのXperiaで再生したほうが高音質だった（泣
PCの音声環境見直すか・・・ >>619
それわかるw
Opusをもっと試したかったらサカナクションの「多分、風」という曲もOpusの入ってるファイルで聴くといいと思う >>616
可逆圧縮をなめてはいけない。
可逆画像圧縮のアルゴリズムをを不可逆画像圧縮から流用するアプローチが
いくつかあるけど、普通にPNGより性能悪い。
WebPは可逆不可逆両対応だけど、それぞれ別のアルゴリズムを使ってる。
可逆か不可逆かぱっと見で区別できないのも困るし、今までどおり別の型式のがいいと思う。
可逆画像圧縮はzstdのアルゴリズムベースのが出てきてくれたら嬉しいけどなぁ。 お前ら可逆不可逆って続けて何回言える？
俺は1回すら怪しいんだけど >>619
YouTube動画の音声サンプリング周波数は
AACが41.1kHzでOpusは48kHzだったような
だから例えばiPhoneシリーズなら6s以降スピーカーが48kHzしか対応していないらしいからAACだと多少音質変化するかも
逆に44.1kHzのみ対応のイヤホンとかもあったり
なんか深淵を覗いた心地に >>621
そういやFLIFとかいうFLACの親戚みたいな名前の可逆圧縮画像規格あったけど最近は音沙汰無しだな
いつかリリースされる日は来るのだろうか 最近は写真や動画を撮ったらすぐにクラウドストレージに投げることが増えてきたから
元ファイルを(ビジュアル)ロスレス圧縮してアップロードした後、クラウド上で再エンコードする時代になったりしないかな
ロスレスHEVCかロスレスAV1かVESAのDSCかどれでもいいけど FLACをアップロードできてOpusがストリーミング配信されているSoundCloudはすごいな
無料だし >>627
SoundCloud、これいいね！
スマホにアプリ入れてGoogleのアカウントでサインインしてみたけど、操作が少し独特だけどいいよこれ
日本人の曲もあるし、音も素材が良ければいい感じだね
これはいいの教えてもらったよ
ありがとう！ >>629
WebP可逆は不可逆とは別のアルゴリズムだから殆どの画像でPNGより縮む
BPGの可逆圧縮を調べてみたけどやっぱり微妙だった
PNGが苦手な画像だとPNGより縮んだり縮まなかったり
PNGが得意な画像だとPNGに引き離される
AV1の可逆圧縮も似たようなもんになる気がする。 PNGは最適化を掛けるとかなり縮むけど、
マルチスレッドすら対応してない古いプログラムばかりで遅いのがな
その辺をちゃんと最適化してくれればPNGで十分そうな気がする とりあえずWindows 10の最新アップデートを適用すると、HEIFの表示のみOS標準で対応だとさ
※保存はダメ 結局OSの対応よりブラウザの対応のほうが大切なんだよね >>630
BPGの可逆圧縮はエンコーダーにx265を使うと縮まないけどjctvcなら結構縮む
jctvcは0.9.6以降は搭載されてないから試すなら0.9.5を使ってね AV1の可逆圧縮、相当無理矢理だけどこんな感じで出来た
ffmpeg -y -i "%~1" -filter_complex "extractplanes=r+g+b[r][g][b],[r][g][b]mergeplanes=0x001020:yuv444p" -strict -1 -f yuv4mpegpipe - | aomenc.exe --passes=1 --i444 --lossless=1 -o "%~dpn1_av1_lossless.webm" -
ffmpeg -y -i "%~dpn1_av1_lossless.webm" -filter_complex "extractplanes=y+u+v[r][g][b],[g][b][r]mergeplanes=0x001020:gbrp" "%~dpn1_av1_lossless.png" >>635
AV1可逆の圧縮性能はPNGに比べてどうだった？ >>634
jctvcを使ったら可逆ですげー縮んだ。勉強不足すぎてた。
これだと大方の画像ではPNGより小さくなりそう。
ただ、PNGが得意な画像で、差は縮まれど追いつけないままな物もまだあるから
PNGを全部置き換えるにはまだ不足してるって感想はそのままかな。
（一番手ごろなものだと、wikipediaのページのスクショ画像がそうなった） deflateという圧縮技術のデファクトスタンダードを使っているpngが置き換わることはそうそう無いと思うけどね >>636
ほい、調べた
AV1はかなり変なやり方で変換しているので効率が悪くなっている可能性もある
画像はpixivデイリーランキングから100枚
pngと比べて何パーセント縮んだか
BPG x265 4.23%
AV1 12.3%
webp 24.16%
BPG jctvc 26.72%
FLIF 31.45%
平均処理時間
BPG x265 1.449秒
PNG 2.439秒
webp 3.353秒
FLIF 7.301秒
BPG jctvc 13.9324秒
AV1 93.8216秒
ベンチマークに使用したbatも上げておくので設定とか検証が適切に行われたかが気になる人は見て
https://www.dropbox.com/s/kc7njid1gz12vs0/lossless_bench.zip?dl=0 >>639
ありがとー
AV1縮んでないね、可逆だとwebpに劣るなんて
得意な？非可逆だとどうなるんだろ >>5の情報更新
●JVETで検討が進められていた、HEVCの後継コーデックは、FVCではなく
VVC （Versatile Video Coding）
という名前になった模様。
●先月のMPEGミーティングで報告された、360度ビデオやHDRも含めた主観評価のテスト結果では
HEVC比で40%以上の改善が見られ、特にUHDで効果があった。
●参考リンク
Beyond HEVC: Versatile Video Coding project starts strongly in Joint Video Experts Team
http://news.itu.int/versatile-video-coding-project-starts-strongly/
MPEG 122 - San Diego | MPEG
https://mpeg.chiariglione.org/meetings/122
MPEG 122 Meeting Report - Bitmovin
https://bitmovin.com/mpeg-122-meeting-report/ >>639
AV1本当何やってもトロくて駄目なやつだな…
ここまで糞だと改善の見込みも無さそう
AV1を今より遥かに速く改善できるなら他のコーデックなら更に改善できるだろ それが出来ないからVVC等の新しいコーデックが開発されてるんだろ Googleが画像フォーマット「WebP」向けライブラリ「libwebp 1.0.0」をリリース
https://mag.osdn.jp/18/05/02/163000
WebPはWeb向けの画像フォーマットで、ロスレスおよび不可逆圧縮の両方に対応する。
拡張子は「.webp」。不可逆圧縮では、VP8動画コーデックが動画のキーフレームを圧縮するのと同じ手法で、プレディクティブ（予測）コーディングを使って画像をエンコードする。
ロスレス圧縮ではPNGと比較して26％小さく、不可逆圧縮ではJPEGより25〜34％小さいとしている。
WebPファイルはVP8とVP8L画像データ、RIFFベースのコンテナで構成される。
libwebpではWebP仕様のリファレンス実装で軽量のエンコード/デコードライブラリに加え、WebPフォーマットへの変換などを行えるコマンドラインツールcwebp/dwebp、WebPイメージの閲覧やmux、アニメーション作成のためのツールを備える。
本バージョンはこれまでのバージョンとバイナリ互換があるとのことで、フォーマットとAPIが安定していることから1.0として公開したという。不可逆圧縮などが強化されツールもアップデートされている。 >>650
ブラウザ識別して火狐には重いデータを送ってやろう ChromeがAPNG対応したんだから
FirefoxはWebP対応するのが🍣 firefoxはwebp対応してるだろ
safariと勘違いしてるのか？ >>655
新4K8K衛星放送開始に向けた取り組み - 総務省（PDF）
http://www.soumu.go.jp/main_content/000533786.pdf
https://i.imgur.com/vmMBLzQ.png
新4K8KはH.265だね
H.265が特許料で揉めてるって最近知ったからあまり詳しくないんだけど
特許料の高さがBS契約料とかNHK受信料とかに（無駄に）上乗せされないといいんだがなぁ
かと言って機動力のない放送団体が状況に応じてコーデック入れ替えなんかできるとも思えないし >>656
対応profileのオプションにもよるけど、TV1台当たりライセンス料300円しないぞ 今年の2月に特許切れたMPEG2にもライセンス料掛かってたしな
録画の圧縮機能やMPEG4/AVCの再生機能持ってる機器なら、未だにMPEG4/AVCのライセンス料も掛かってるし
今まで金銭的にそれらの上乗せを負担と意識して無かった奴が、今更HEVCのライセンス料で騒いでるのも可笑しいんだけどね
実効でその程度のものだったり 映像コンテンツなら殆ど2円未満、高くても3円にもならないとかだし、
パッケージの流通コストや小売り・事業者の粗利の方が遙かに影響デカくて、個人単位で年間ナンボよって感じなのよね
そんな額気にするなら、家電品の消費電力気にしていた方がマシだったりな
自販機で飲料買ったり、コンビニで買い物する方が遙かに無駄という GIMPは亀の歩みだし……
対応してくれただけでも喜ぶべき 昔はPhotoshopの代わりにGIMPでも頑張れば行けるかもって時期があったけど、
今は完全に突き放されて背中すら見えなくなってしまったなあ GIMPはリリース間隔が空きすぎて開発者のほとんどがKritaとかDarktableに行っちゃったから… GIMPの前回のリリースって5年以上前だろう
webpその頃あったのかな androidのゲームでwebp義務化すればかなり通信料減らせそう 結局webpが流行ることは無かったな
コーデックもVP8のままだし よくわからんけどAndroidのゲームはETC1かETC2が主流じゃないの？
多分DXT同様固定の容量圧縮比の方がメモリ消費量の把握しやすいだろうし >>670
JPEGから移行するにはショボすぎた
HEIFでやっとって感じ 流石にJPEGも古い規格よなぁ
圧縮率の高い次世代フォーマットでどれだけのストレージやリソースが削減できるか
実際は皆足並みが揃わない訳だけども
ストレージの進化が完全に頭打ち！大変だ！みたいなピンチにでもならなきゃ業界は腰を上げないよな ストレージは大した問題ではないだろう
問題なのは通信量よ その他にも処理速度とかそれをハードウェア処理するチップのコストだとかいろいろあるんだろうけど
ぶっちゃけいえばブラウザやOSが標準でサポートするか否かが一番でかいと思う
ってJPEG2000さんが草葉の陰でいってた 近いうちにJPEG2000が主流になるからデジカメの買い替えをちょっと待とう…
とか思っていた遠い日の記憶が蘇ったw もうJPEGくらいに浸透してると
AppleみたいにHEIFをデフォルトで初心者に気づかせないうちに使わせて
広めるみたいなことしないと無理だろう amazonとかの電子書籍を全てwebpにすれば普及する AV1ってまだ正式に仕様決まってないの？
doom9見てたらそういう感じの話してるような気がするけど機械翻訳で読んでるからよく分からない
https://forum.doom9.org/showthread.php?t=172550&;page=34 >>679
まだみたいだね。
https://github.com/AOMediaCodec/av1-spec
で作ってる仕様ドキュメントから“draft”が無くなった時が仕様確定かな。
参考： Jan Ozer氏が4月中旬にAOMediaの人から聞いた話
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=124455&;fb_comment_id=2018670391537585_2021817181222906#f16f50065d9c3e4
雑訳：
AOMでは「code first」というアプローチでAV1の開発を行っている。
リファレンス実装のコードの開発と、それによってもたらされるビットストリーム仕様の策定・作成は並行して行われている。
これらが終わって初めてAV1の仕様が確定したと言える。
仕様書は現在は「draft」とされており、リファレンス実装のビットストリームが正確に反映されるよう、
自動/手動でレビューを実施しているところであり、その作業には更に数週間かかるものと思われる。
それが終わった時点で「draft」のウォーターマークを外し、AV1の仕様が確定する。
>>678
それだけじゃ絶対普及しない
リーダーはAmazonとかの電子書籍配布元が配布するとして
画像生成する機器やアプリケーションが標準でほぼ全対応しなきゃ
出版する側の人間がwebpへの変換ツールを使うだけに終わる
カメラなどのハードウェアが直接次世代フォーマットで
画像生成するようになって初めて普及する可能性が出てくる
その点、デフォルトでiPhoneでHEIFを吐き出させ始めたAppleが
一歩リードしてる >>680
サンクス
どうりでChromeがなかなか対応しないわけだ chromeもfirefoxもAV1の一時的なな実装は完了しているから仕様確定したらすぐにでも導入できるはず
まあ安定版に降りてくるには半年近くかかるのだろうけど つべのVP9と264
容量が逆転してるのが多いな…
細かい動きが多いとダメなんかな？ VP9はHEVCとAVCの中間あたりに位置すると個人的には考えてるから、得手不得手で旨味なくなりがちだよね HEVCの技術とAV1の技術を全て結集したらさいきょうのコーデックが出来上がりそう（厨二的発想）
まぁ大人の事情でまず有り得ないけど >>688
大人の事情とか言ってる時点で…
ただエンコーダ・デコーダが優秀になればいいだけの話。特性云々はここで語る必要ないと思うが VP系はMPEG系と比べて先読み短くても圧縮率保てるからストリーミングにはVP9のほうがいいよ 自炊用途は、長期的に安定して再生できる可能性の高いフォーマットを選ばないとあとで後悔するだけ
ただ、一つ気がかりなことがあるとすれば、動画ファイルに使える音声フォーマットの進展が遅れ気味なことか
特にOpusのようなVBRタイプのフォーマットを動画とMUXしたいとかなると、とたんに使えるツールが見当たらなくなる現状は如何ともし難い
動画と音声を自由自在にMUXできる自由度の高いツールがほしい mkvコンテナ扱える奴なら仮対応的な実装じゃ無ければイケるんじゃないの？ 電子書籍とかの複数ファイル画像って
動画にしてフレーム間圧縮で容量減らせそうだけど
やってるとこないのかな >>695
フレーム間の違い大きすぎて圧縮のための予測がうまく出来なさそう >>696
文字とかで余白の多いすかすかの雑誌系は
ページ間で連続した空白多いから容量減りそうだけどどうだろ そもそも空白が多い画像はjpgなりpngなりでも大きくないと思う。
1フレームごとに文字が離散しているので毎フレームIフレームにするのと画質対容量のメリットがあまりない。
kindleなどの端末で処理するにはフレーム間予測などの処理はハードウェアデコーダ積んだりキャッシュしていくにしろ重いだろうし流行らないと思う。
そういうので1番効果があるのはエロゲとかdlsiteにあるような差分データ盛り盛りのCG集などに限定されると思う。 そこは昔のゲームみたいに口や目の変化部分だけ画像作って
差し替える方式でいい気がする。マップチップ的な
まぁ今のもの見ると画像1枚1枚用意しているのが多いから容量増え気味だよね スクリプトミスったら差分の目が背景の上に浮くじゃないですかー VimeoがAOMediaのPromotor memberに。
Vimeo Joins the Alliance for Open Media
https://press.vimeo.com/31386-vimeo-joins-the-alliance-for-open-media エロゲって画像形式何使ってるんだろ、やっぱり可逆PNGなのかな 吉里吉里ならエロゲ絵に特化したTLG型式ってのが使えるけど
実際に使われてるのかは知らない。 >>695
OCRしてテキスト化の圧縮率に到底勝てないからやる意味が無い >>695
面白いアイディアだな、言い出しっぺの法則で作ってみてくれ
ただ全ページがキーフレームになってしまうとかあり得るんじゃね 電子書籍は突飛なアイデアではなくて自分も数年前に検討済み
電子書籍には3タイプあって、698の言う通りで、連続差分画像以外に
ましてやテキストオンリーの書籍に動画コーデックの出る幕は無い
・画像のみ：コミック、写真集
・テキスト+画像レイアウト：雑誌やムック、写真集、美術書など
・テキスト：小説など
テキスト+画像レイアウトの場合、活躍するのは静止画フォーマットだけ。
残された画像のみの場合だが、すでにHEIFはイメージシーケンスが規格に組み込まれてるから
新たにやることは各電子書籍ベンダーがそれを利用するかどうかくらい。 漫画なら図形の輪郭とかとかスクリーントーンとかそういうのを符号化すれば…
って思ったけどpostscriptだな もう、基本の圧縮技術は画像にしろ動画にしろ、JPEGの時代に確立されちゃってるのか・・？？
それからあんま本質は変わってないのかね 500年後の未来から来たけど、今の圧縮技術はその概念自体が使われなくなるよ
究極のイメージ処理は、全データをベクター処理すること
ラスターイメージ処理は電子機器の能力が低い現代における
低レベルなお粗末な石器時代並みの技術だよ
量子コンピューターにより画像自動解析処理が高度に発達した未来では
2Dの平面データで記録再生するのは骨董品技術になる
わかりやすく現在の製品名で例えれば
Illustrator>>>超えられない距離>>>Photoshop
未来のカメラは撮像したデータを自動解析して、
3Dオブジェクト+テクスチャ判定+光源計算したデータとして保管
テクスチャも撮像データから得た2Dラスターデータではなく
全世界で共用管理している超大規模データセンターの膨大なデータから
何番目のテクスチャ、というID指定を記録するだけなので、データ量は軽い
再生時に3Dグラフィックでリアルタイムレンダリング処理を行う
圧縮という概念自体がなくなる
ただし、メロンパンは500年後の未来でもなくなっていません。あれは美味しいデス 電子書籍に関してはePubの規格がバージョンアップしてリフローとフィクスのハイブリッド型も作れるようになってるね
現状では雑誌の電子書籍版のインタビュー記事とかがテキストも含めて全部画像だったりするけど
今後は必要に応じてテキスト部分はテキストデータのページに置き換えるような措置をした方がファイルサイズを抑えるのとコンテンツの読みやすさを両立できて良いと思う >>708
JPEG 2000ではウェーブレット変換が使われていたけど、結局それ以降は使われていないよね
コサイン変換に比べて、あまり筋のいい技術ではなかったということなのかなぁ 某ネコさん曰く、16k以上の画素数だとwaveletが日の目を見るかもしれないらしい JPEG XSもwaveletだそうだけど、どんな感じの圧縮なんだろう。 >>713
おねえさんのお尻でぎゅーって押し潰される感じ♥ >>711
ビデオ規格だと、SnowやDiracもウェーブレット変換 DCTと違ってブロックノイズが発生しないのがDWTの利点だけど、
ブロック単位でする動き補償と相性が悪いので動画には不向き waveletで圧縮しまくったらどうなるんだろ
ぼやけるだけ？ 特性的にエッジ部分の情報量から削られていくから、そういう部分の階調表現の幅が狭まる（コントラスト低下）と解像度感が失われて眠い画になっていくと思う（俗に言う眠い絵作り
特性がある圧縮だから万能じゃ無いかと
あくまでwaveletを手段として使っていているだけで、これ自体が圧縮方式では無い事にも注意（使い方や実装で性能が変わる
画像データの周波数的な情報の分離に向いていて、分離したデータの内で画像の全体像を把握するには重要じゃ無い部分を削る事で「圧縮にも使えなくは無い」ってだけで、内容的にはMP3的な（実装によって差が出やすい）プライオリティの低い情報を削る感じ
文字や図表、線画のエッジ部分が多い画像の圧縮には向かないと思う >>619
MISIAの4Kというと、「名前のない空を見上げて」のことかと思うけど、これ確かにスマホで聴いたほうが音いいからおかしいなと思って調べた
すると、確かに4Kでアップされてはいるのだけれど、1080pと1440pをmp4ファイルとWebMファイルで比較すると、mp4ファイルのほうがファイルサイズが大きくなっていた
通常、画質と音質がともにいい場合は、4Kより下の解像度でもファイルサイズは
WebM＞mp4もしくはWebM≒mp4
のいずれかであるのだが、この曲は逆転していた
だからダウンロードするのであれば、この曲に関してはmp4ファイルのほうがいい
ただし、ここからがよくわからないのだが、PCにてChrome上で再生した場合、再生中に詳細情報を確認するとWebMにも関わらず音は悪くない
ここがわからないんだよなぁ
YouTubeは謎が多い 今の動画サイトは、映像と音声は別々に保存してて、
視聴者がページ開いたときにくっつけて配信してるんじゃなかったっけ。 よくわからないのに書くからこういうことになるんだね マジレスするとYoutubeの場合、 https://pastebin.com/YiAnRD0w のように、
Ａ．音声のみのファイル
Ｂ．映像のみのファイル
Ｃ．映像＋音声のファイル
が複数あって、基本的にはＡとＢを組み合わせて配信される。
プレーヤー右クリック→詳細統計情報→Codecsで組み合わせが見れる。
Win10のPCのChrome/FirefoxはVP9+Opusだが、IEはAVC+AACだし、EdgeはAVC+Opusになることもある。
Opusは基本的に251番(160kbps)が使われるが、映像が144pの場合は250番(70kbps)が使われる。
スマホも、機種やブラウザ等によって組み合わせは変わるだろう。
音声だけなら22番(AAC192kbps)か251番(Opus160kbps)がベスト。
元々は音声の話なので上記を踏まえて音声だけ比較すべきだと思うけど、
>>721はなぜか映像まで含めてWebM vs MP4という比較をしてるし色々的外れ。
「通常はWebMの方がサイズが大きい」と言ってるのもよくわからない。
基本的にはVP9(WebM)の方がAVC(MP4)より小さくて、稀に逆のものもあるという程度だと思うけど。
変なダウンローダを使ってるか勘違いしてしまってるんじゃないかと思う。 ついでに言うとYoutubeの場合、VP9は比較的ファイルサイズが小さくなってるとはいえ、
たまにブロックノイズやリンギングノイズ（モスキートノイズ？）で
映像崩壊レベルになってるフレームがあったりする。
普通に視聴する分には気にならないけど、比較するとAVCの方が安定した画質になってるような。
まあ1440pHFR以上は基本的にVP9だけしか無いけど。 EdgeはGPUにVP9デコーダが搭載されてればVP9、
無ければH.264で再生されるから賢いというか優しいというか
ChromeはGPUデコーダ無くてもVP9にするからCPUデコードになって重い
VP9デコーダ無いような古いPCでCPUデコードとか鬼だ
メモリも喰いまくるしオンボロPCで動かすんじゃねえってGoogleの方針なんだろう HEIFってOSではポツポツ対応しはじめてるけどフリーソフトではなかなか対応しないね >>732
おんぼろPC+Chromeにh264ify入れて使ってるぜ… ネタ切れでビデオコーデック以外のネタばっかりになってきたな
それはそれで良いけど H.264が動画界のJPEGみたいな感じになって終わりやろ
新フォーマット？なにそれおいしいの？みたいな 配信があるのでシビアだよ
俺も264で世は収まったと思ってたけど
ある日突然ツベの4Kがガクガクになって思い知ったよ… 4Kに対応しようとすると古いPCは一気にアウトだからねぇ
4Kで思い出したがAV機器板のUHD-BDスレにて
・4か月弱ぶりのWHQL版「Radeon Software Adrenalin Edition 18.5.1」リリース。Ryzen 2000G公式対応を果たした統合型ドライバ
http://www.4gamer.net/games/022/G002212/20180524003/
「なお，新世代APUへの対応以外では，ハードウェアレベルの4Kビデオ保護技術としてMicrosoftが推進する「PlayReady 3.0」に
Radeon RX 500＆400シリーズで対応したことと，「Ancestors Legacy」への最適化がトピックとなっている。」
「PlayReady 3.0」の対応、つまり外付けGPUを利用してのUHD-BD再生の道が一歩開けたということか？
Intel SGXに頼る必要はなくなった？
とあった
PCによる4K再生が少しでも身近になればいいのだが 面倒すぎてRIPした方が早い気がしてくる
HDMI2.0は破られてるし縛る意味とは
H265が身近になるには、あと数年、スマホのハードウェアデコーダー搭載率が上がったらだね
載ってない世代でCPUデコードはほぼ無理だし アンドロイド定番の画像ビューワ、PerfectViewerがプラグインでHEIFに対応してた
これで画像一括変換ソフトがHEIF対応してくれればなあ ジャップ製の印刷機やデジタル家電、ソフトなどが対応進まないと無理じゃね ちょっと戻っちゃうけど
画像の圧縮なら確かにPDFで「文字と背景を分ける」みたいな圧縮方式があるから、漫画の場合は画像一枚の中で背景レイヤーと文字・絵レイヤーを判別して、背景レイヤーを単色データにすればかなり圧縮できるはず それぞれのレイヤーで最適化しないと
単色データぶんだけデータが増えるだけに終わりそう Windows10 Insider Previewでheifの表示試してみたけど対応してるのはyuv420だけでyuv444は見れないな
あとx265のフルレンジフラグを読み取ってくれなくてリミテッド専用になってる
将来的には改善されるんだろうか？
今のままならBPGのほうが使いやすいんだが ちなみにWIC(Windows Imaging Component)でのサポートもしているのでWIC対応のSusie Pluginを入れるとMassiGraなんかでも見れた MSの実装だとYUVからRGBへの変換係数はbt709固定っぽいけどnokiaの実装だとsmpte170m固定っぽいから色がおかしくなる問題が続出しそう
どっちもx265のcolormatrixは読み込みにいってないし(heifのヘッダとかに指定するのかもしれないけどよく分からない)
この辺も整備されないと使いにくいな WindowsはOS、画像ビューアともに伝統的にICCプロファイルをきちんと反映させようとしていない（一部の優良な画像ビューアは対応している）からな いやごめん
MSの実装の方、フルレンジフラグを読み取ってくれないって書いたけどコマンドラインの記述が間違ってただけで修正したら読み取ってくれたわ
それにcolormatrixだけじゃなくてtransferとcolorprimも指定したら正しい色で表示してくれた
案外ちゃんとしてるな
こんな感じ
set "x265_option=-crf 23 -preset slower -x265-params colormatrix=smpte170m:transfer=smpte170m:colorprim=smpte170m:range=full"
ffmpeg -y -framerate 1 -i "%~1" -pix_fmt yuv420p -vf scale=out_color_matrix=smpte170m:out_range=pc:flags=+accurate_rnd %x265_option% -f hevc "%~dpn1.h265"
MP4Box -add-image "%~dpn1.h265":primary -ab heic -new "%~dpn1.heic"&&del "%~dpn1.h265" ARMがスマホ向け新GPU「Mali-G76」＆新VPU「Mali-V76」を発表、スマホで8K・60fps再生に対応へ
https://gigazine.net/amp/20180601-arm-mali-g76-v76
https://i.gzn.jp/img/2018/06/01/arm-mali-g76-v76/b07.png
Mali-V76は2コアから8コアが想定されており、8コア時には8K・60fpsのデコードと8K・30fpsのエンコードに対応。4K・120fpsのデコードにも対応します
ただし、Mali-V76にはGoogleなどが開発する次世代コーデック「AV1」はサポートリストに含まれていません 動画の再生支援に関しては、スマホに先越されてばかりだな
そのうちスマホをPCに接続して、動画再生支援用の外付けGPUみたいにして使う時代が来るのかね？ 新フォーマット→ハードウェア支援
っていたちごっこ 先越されていたっけ？
ARMのIP積んだモデル出回るのなんか1年先でしょ
それもPC並みの値段で HEVC 10bit 8KならIntelならCore iならKabylake、Atom系ならApolloLake（デコードのみ、エンコはGeminiLake〜）以降で対応
nvidiaならPascal世代で対応済みだから、ARMの方が2年近く遅い ？
SnapdragonのHEVCハードウェア再生支援は、余年くらい前から対応してたはずたがな
記憶違いか？ スマホ -> PC -> モニタ ってめんどくさくね
スマホ -> モニタ でええやんか 久々にIntelの動画再生支援の対応可否をチェックしてみたが
・Intel HD, UHD and Iris Graphics（英語のサイト）
https://en.wikipedia.org/wiki/Intel_HD,_UHD_and_Iris_Graphics
■HEVC
・Haswellは、8bitのみ部分的な対応
・Broadwellは、8bitと10bitの部分的な対応
・Skylakeは、8bitは4Kまで対応
・Kaby LakeとCoffee Lakeは、8bitと10bitともに4Kまで対応
続く ■VP9（YouTubeなど）
・Haswellは、対応なし
・Broadwellは、部分的な対応
・Skylakeは、4K24Pの15Mbpsまで対応
・Kaby LakeとCoffee Lakeは、8bitのみ4K（60pかどうかは不明）まで対応
（BT.2020については将来的に対応予定）
※なお、下記サイトによると、AMDが「VegaベースのGPUコア＝Radeon RX Vega 64 Liquid Cooled, Radeon RX Vega64, Radeon RX Vega56」
において、VP9の再生支援に対応していないとの記述があるが、これは本当なのか？
http://www.leoplanet.co.jp/entertainment/doga-saisei-shien.html
一方スマホは、Snapdragonの場合（最大対応解像度などの詳細は不明）
■Snapdragon 800⇒HEVC対応
■Snapdragon 805⇒HEVC対応
■Snapdragon 810⇒HEVC対応
■Snapdragon 820⇒HEVC、VP9ともに対応
■Snapdragon 821⇒HEVC、VP9ともに対応
■Snapdragon 835⇒HEVC、VP9ともに対応（これは、ARM版Windows 10でも有効）
※参考
https://en.wikipedia.org/wiki/VP9 追記
Snapdragon 820搭載のスマホにVP9でエンコードされた4K60Pの動画を入れて試したところ、
カクカクでした
4K60Pはやはり重い ARMはデコードにもGPUの演算コアも使ったりするからな
PC向けGPUみたいにメディアエンジンのみで処理出来るのは世代重ねてからだぞ
ソフトウェアデコーダより消費電力は低いけど、PCで言うところのハードウェアデコーダと少し実装違う
まぁそれでも消費電力の設計母数小さいからまだ省電力と言えるだけで
それでも砂ドラの800や805とかでH265の再生なんぞやったら、FHDでも数十分もせず馬鹿みたい発熱しながらバッテリー消費していく windowsならタスクマネージャでCPU使用率さくっと分かるけど、androidってシステムていきょうのツールねぇのかよ。
とりあえずCPU statsというアプリで動画再生しながらCPU使用率確認してるけど 俺もandroid8になって
CPU利用率見れなくなって不便してる ■Arm、モバイルで8K/60fps再生対応のVPU「Mali-V76」。VR/ゲーム向けGPUも
https://av.watch.impress.co.jp/docs/news/1125575.html
・8K60Pのハードウェア再生支援対応
・8K30Pのハードウェアエンコード対応（※これは現時点での話）
・4K60P動画の4本同時再生可能
・2K60P動画の16本同時再生可能
■ARM Announces Mali-V76 Video Processor: Planning For the 8K Video Future
https://www.anandtech.com/show/12835/arm-announces-maliv76-video-processor-planning-for-the-8k-video-future
・4K120Pも同時再生可能本数は不明ながら再生には対応
・H.264、HEVC、VP8、VP9のすべてにおいて、8bit及び10bitの動画をデコード及びエンコード可能
・AV1はデコード及びエンコードともに非対応 デコードもGPUコアのクラスタ数に依存しているという事は、メディアプロセッサだけでは、PC向けGPUと違ってデコードも処理出来ていないって事なんだがな クラウド上のFPGAを利⽤するAV1エンコーダーを実装
https://www.socionext.com/jp/pr/sn_pr20180606_01j.pdf
[横浜発, 2018 年 6 月 6 日] 株式会社ソシオネクスト (Socionext Inc.) は、アマゾン ウェブ サービス (以下「AWS」) の「Amazon Elastic Compute Cloud (以下、Amazon EC2) F1 インスタンス」上に、
最先端の映像データ圧縮規格「AV1」のエンコード処理を⾏う機能を試作実装しました
F1 インスタンスの利⽤により、約 1.5 カ月という極めて短期間で開発を完了し、かつ高い性能を得ることができました
当社は今回の成果をもとに、顧客がクラウドから半導体製品の機能を利⽤できる仕組みや、現在クラウド環境で広く利用されている大規模・高性能アプリケーションの処理能⼒を向上させる各種アクセラレーターの構築・運用など、
サービス提供を中心とした新しい製品の可能性を提案します
F1 インスタンスの利用により、開発開始から 1.5 ヶ月という驚異的な短期間での開発が可能になっただけでなく、FPGA によるアクセラレーションで CPU 単体動作と比較して約 10 倍の処理速度を実現しました これはいいね。LSIを起こせないようなスタートアップ企業が競い合って早く技術が成熟するといいですな。
大学の研究室からのエントリも面白い。 今年の第三四半期にAMDの新型スリッパが32コア64スレッドなCPUを投入するらしいが、そんな強烈なのが出たらHEVCのエンコードもサクサクかな？ 性能倍なら同世代の16C32Tスリッパの倍以上の価格なんだろうけどね AV1のエンコーダーなかなか早くならないな
1080pの10フレームをエンコードするのに52分もかかった >>787
Intelの5GHz×28コアCPU搭載した化物マシンが必要 いや、>>378ではi7 4702MQで10フレームエンコードするのに66分かかったって書いてるからちょっとは早くなってるかな
こちらのCPUはi7 3520M 今年中に100倍程度速くなるなんて緩い予想はなかなか実現しそうに無いな 1フレームエンコードするのに6分かかるのか
昔の3DCGみたい AV1のエンコーダー以外を終了させて厳密に計り直したら早くなってたわ
まだ全然実用的じゃないけど
バイナリはここの
https://www.mediafire.com/?21254ingvippg
2018/03/27 v0.1.0-8892-g10b745615
1時間38分45秒
2018/06/01 v0.1.0-9658-g265d15d46
40分13秒 2ヶ月で2.5倍早くなると仮定しても年内に100倍には届かないか そんな小学生が成人するまで同じペースで背が伸びて2m越えるみたいな計算通らんわな 欠陥の無いダイがすげー安く作れるようになったらワンちゃんあるかも 今のところマルチスレッドをあまり生かしてくれないのが遅い原因の一つ
--tile-columnsを指定すると横で分割してマルチスレッドでエンコードしてくれるんだけど、
分割数は2の冪乗で、分割した一列あたり256px以上という制限があるので、
1920x1080の動画をエンコードしても4分割しかされず、
使ってくれるスレッドも4つぐらい 2passエンコで１pass目でキーフレームの場所を確定させちゃって
2pass目では複数のGOPを同時並列にエンコとかできないのかね。 >>800
いわゆる対抗特許だね
AV1陣営を特許侵害で訴えようとした企業にカウンターするための特許 >>800
ANSは一時期AV1のエントロピー符号化手法の候補になってたけど、
Daalaのエントロピー符号化手法のほうがハードウェア実装しやすいことが分かったので、
採用されなかった。 動画エンコードの探求に「終わり」はあるのか？
https://gigazine.net/news/20180614-end-of-video-coding/
> 2015年にNetflixの技術者が初めてMPEG会議に参加して、将来の動画コーディングのための文書を発表しました。
> その際に、Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑性が高まるとしてもまったく問題にしない」というスタンスであることを伝えると、
> 議長から「では、どのくらいの複雑さを許容できますか？」と尋ねられたとのこと。
> 回答の準備が整っていなかったNetflixの技術者は「最悪のケースでは100倍まで」と答えると、100人はいたであろう動画コーディングの専門家たちからは大爆笑が起こったそうです。
> 議長は「心配しないで。彼らはみな『新しいこと』を試すことができると、幸せに感じているのです。たいていの人は『3倍まで』と答えるものだから」と話したそうです。
Netflixは100倍遅くても許容するのかー
やっぱりこれから先の動画圧縮技術はリソース有り余ってる大企業だけのものになるんじゃないだろうか エンコードは1回しか行われないのに対してエンコードされた動画は何万回も再生されるから、
例えエンコードに従来の100倍の時間がかかるとしても、
それによって削減される帯域次第では動画配信やってる大手企業は喜んで採用するだろうね。 まあh266（？）とAV1以降のエンコードは一般人が持ってるpcじゃなかなか難しそうだろうね、NetflixやYouTube規模の動画配信サービスになるとそれだけの価値があるんでしょ
実際、Netflix、YouTube、アマプラ、Huluが完全にAV1を採用すれば全体のデータトラフィック量はどれくらい少なくなるんだろう ハードエンコの品質が上がって画質にうるさいマニアも納得のハードエンコの時代がきたらまだワンチャンある。
というか今エンコにどれくらいのトランジスター割かれてるのか知らんが何十億って使えばもっと速くなるのかな?? >>804
なるほど
しかもyoutubeみたく数億人のユーザーがほぼ同時にアップするわけじゃないから
Netflixにとってのハードルは低そう 限度知らずに高解像度を無茶な低帯域で保存しようとしなけりゃ、現状のHWエンコでも十分まで行かなくても、そこそこ使えるレベルだと思うけどな 品質についてはVLCの連中がx264/x265の開発止めない限り、個人が無償で扱えるエンコード品質の上限的な基準になっちまうから
妥協無しに満足するなんか無理な話だし
HWエンコーダに無い処理の柔軟性で画質引き上げてる部分が大きいから、その溝は埋められない
cudaコアの物量に頼っていないNVDecであの品質だから、nvidiaがQSV並みの実装する気になってくれれば、QSV HEVC並みの品質でQSVの2〜3倍速ってのは不可能では無さそうではあるんだけどな（GPUのグレードに左右されそうではあるけど 配信に使おうと思ってQSVとNVENC試してるんだけど同じビットレートだとNVENCのほうが画質良くなるみたいなんだよね
NVENCが何か改善されて良くなったのかな？
それともQSVがリアルタイムエンコに弱いのか QSVのH264でFF使う場合でも無い限り、基本的にはQSVの方が綺麗になるよ
CBRやビットレートベースのVBR使うとQSVの方が画質容量比悪化しやすいってのもあるけど あと、比較するQSVの世代にもよる
SnandyやIvy世代はHaswell以降よりCU規模の割に速度出やすい反面、画質向上処理はHaswell以降より劣る（処理が甘い分速くて画質に劣る CUはRADEONか、QSVはEUだった、すまん
NVEncはエンコードエンジンの性能勝負で
QSVはGPGPU込みで画質が良い（GPGPU使う時間が取れないFFモードだと画質が駄々下がり
画質は
QSV（延滞問わず）＞NVEnc（元から低延滞）＞QSV FF（低延滞モード）
みたいな感じ dGPU化でAMD CPU使いでも使えるようになるといいんだけども＞QSV ・「Windows 10 RS5」で“WebP”がサポート、「Microsoft Edge」などで表示可能に
https://forest.watch.impress.co.jp/docs/news/1128464.html
「WebP」をウェッピーと読むのか
ずっとウェブエムだと思ってた… ウェッピーが正式な発音だと知ってるがウェブピーと読んでる ヽ
_,,.,､､,.ｨ-- ti- ､､､....,,,,_ ',
,,..､､ri':'ﾞ/~ ﾚ ' ﾞﾍ:l : : : :~,＞
_,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、 !l!;: r '"
'''＜:::::::::::::;､r' `'' ‐-`.､ /
-、 l::::::::::::l ＜"ﾞ'i;ｿ' ',
~.ヽ l:::::::::::l ~' '､
/ .） .l::::::::::! '､
ヽ .l:!l:::::l ヽ '､
＼ ' l! l::!l! ヽ ,'
ﾞ ヾ ‐'" ,. r ﾞ そんなに何も見えてないんじゃ
ｰ-‐i ,.r,,iilll鬚髯ｦ
. l `''' ‐‐ ---t‐' 生きてても面白くないでしょう
￣￣￣￣￣￣~"''､' ‐ ､ ー‐ノ
', ヽ l ・4K映像の低遅延配信に「CMAF」が有効、コーデックは「AV1」主流に? Akamaiが解説
https://av.watch.impress.co.jp/docs/news/1128920.html
AV1は、HEVCやVP9などよりも高い圧縮効率を実現し、開発者向けブラウザのFirefox NigtlyやChrome Canaryでは既に採用されているが、3月予定としていたコードフリーズには6月時点でまだ至っておらず、当初の予定より遅延。
現在はエンコードをソフトウェアで行なっているため多くの時間がかかり、時光氏は「ハードウェア対応は'19年後半にずれ込む恐れがある」としている。
まだコードフリーズすらしていないのか 数ヶ月前にエンコードしたファイルが新しいバージョンだと出来なくなってるとかまだあるから全く使い物にならないよ ttps://github.com/AOMediaCodec/av1-spec/commits/master
仕様のコミットログ見るとぼぼ毎日更新してる。
更新の規模は体裁を整えたりとか、仕様を明確化したりぐらいが多いけど。
ttps://people.xiph.org/~tterribe/pubs/lca2017/aom.pdf
ハードウェア実装しやすいアルゴリズムかどうかはちゃんと考慮されてるみたい。
17ページ目に新しい機能は
ハードウェアチーム、知財チーム、ワーキンググループ全体
の順でレビューされると書かれてる。 youtubeとかで使われるようになってもほとんどの端末ではしばらくソフトウェアデコードになるだろうけど負荷はどれくらいになるのだろうか
スマホでも余裕なくらいじゃないとキツイぞ HWデコーダが無い機種はH.264で観ればいいだけだからﾍｰｷﾍｰｷ すぐに変換されるのは4K以上の動画ぐらいでしょ、きっと AV1だろうがそもそもモバイルで4K解像度もってるデバイスほとんどみねぇし、2Kにちょっと毛がはえたぐらいの解像度なら現状出回ってる機種でも余裕じゃねぇのかな。
まぁモバイルはバッテリーの問題があるけどさ。 と思ったけどH.264のフルHDをSWﾃﾞｺｰﾄﾞしてみたらFireHD10で結構CPU使用率いくな YouTubeはビットレートが足りないのと粗雑エンコで1080pは見れたものじゃないから、超高精細映像に構うよりは1080p以下の映像に目線を向けるべきだと ネットの人ってどうして一つしか正解を許さない人が多いんだろ 頭が悪いんだろ
脳内が視野狭窄状態みたいになってる奴がいる https://aomedia.googlesource.com/aom/
タグがv0.1.0からv1.0.0になった
さすがにそろそろ仕様固まるかな AV1の対応、ChromeとFirefoxは着々と進んでいるけどSafariとEdgeはほとんど聞かないね >>843
EdgeはともかくSafari（Mac、iOS）は最後まで抵抗しそう Appleだって支援してるんだからそれはねえわ
HEICとか作ってまでh265推してたが今時サンクコストにしがみ付いたりはせんやろ
ただハードウェアエンコーダ/デコーダが実装されているという理由で少なくとも2、3年はOSデフォルトとはせんやろな AppleもAOMediaの創設時メンバーなのだから、VP9みたいな事態にはならないと思っているがね 一応なんかAppleはAV1の創設メンバーとしてリストされてるんだよな、詳しく知らん
https://japan.cnet.com/article/35112777/ USB Type-C規格策定に大きく関与したが採用せず
LightningケーブルのMFi免罪符で御布施を徴収するAppleのことだ
やすやすMPEG利権を手放すとは思えんな ムービーミドルウェア「CRI Sofdec2」が、高いデータ圧縮性能を有するビデオコーデック「VP9」に対応。まずはスマートフォン向けから
http://jp.automaton.am/articles/newsjp/20180626-70947/
株式会社ＣＲＩ・ミドルウェアは6月26日、高画質・高機能ムービーミドルウェア「CRI Sofdec2」の機能を拡張し、
高いデータ圧縮性能を有するビデオコーデック「VP9」を搭載したと発表した。
同社は、ゲーム開発向けに音声・映像のミドルウェアブランドCRIWAREを展開しており、
その中で提供されているSofdec2は、クロスプラットフォーム対応の高画質・高機能のムービー再生システムで、
UnityやEnreal Engine 4といったゲームエンジンにも対応。
『二ノ国II レヴァナントキングダム』や『New ガンダムブレイカー』など、累計4,000タイトルを超えるゲームの開発に採用されている。
今回Sofdec2に搭載されたVP9は、Googleが開発した高い圧縮率と高画質を特徴とするビデオコーデック（動画の圧縮形式）で、
YouTubeのような映像配信サービスなどで幅広く採用されている。 >>849
MacBookで採用してるだろ視野狭すぎ macbookの周辺機器MagicKeyboard、MagicTrackpad2、MagicMouse2はLightningだぜ
全てUSB Type-C策定後に発売というね >>851
未だAppleがiPhoneやiPadでLightningに固執する理由って既得権益以外ないだろ AV1完成したっぽいから試しにエンコードし始めたけど丸一日経っても終わんねー
375フレームをエンコードするのに50時間くらいかかりそうだ 相当ハードウェアエンコーダに実装し易く作ってるらしいしそのうち爆速エンコ出来るようになるでしょ…多分 GPUの演算能力でゴリ押しできないのかね
効率的に分解できるアルゴリズムなら… >>853
LightningからUSB Type-Cに乗り換えるというウワサ話が丁度ネットを駆け巡っているが、はて本当か >>859
コネクタ全廃という噂もあるぞ
QiならMFi認証存続できるからな
ありえる Lightningに固執っていうけど、
速度と給電能力以外での重要な利点＝リバーシブルの利便性は先行して備わってたわけで
わざわざ変える必要もないと思うんだよね
特に>>852のBT接続な周辺機器の充電用途程度なら 圧縮率に伴って重いってのもあるけど
デコード側の負荷低減の為にデータの格納にも手間増やしてるからな Comparison of recent video coding technologies in MPEG and AOMedia
https://www.bbc.co.uk/rd/blog/2018-06-comparison-of-recent-video-coding-technologies-in-mpeg-and-aomedia
VVCやばいな、AV1より更に縮むのか
やっぱり特許に触れないように規格作っても性能ではMPEGに勝てないのかなあ というか、グラフが正しいならばHEVCとAV1の比較をすると、ほとんど差がないから現時点ではHEVCで充分だな どうせ次世代JPEGと同じでAV1もH265も流行らない
みんなで足の引っ張り合いしてるんだもんなぁ〜歩調合わせないと何やっても無理よ NetflixやHuluみたいなサイトはライセンス料不要なAV1を間違いなく採用する
ユーザーがアップロードできるサイトは知らん 結局コンテンツあたりの視聴する客側に課せられるライセンス料なんぞ数円レベルで、
コンテンツ事業者はその分が無くなれば視聴料を数円単位で安くする訳も無く
ストリーミング配信業者ならそれすら無いんだからな
業者は年間の事業者ライセンス料+コンテンツ毎データ作成時のエンコードのライセンス料を払いたくないだけで、視聴する側は再生時の消費リソース増大（電気代）かHW再生支援環境の更新に出費させられるという >>869
次世代ipegはMSが対応するwebpになりそうだけど とりあえず1つだけAV1エンコード出来た
死ぬほど時間かかったしせっかくなんでサンプル欲しい人はどうぞ
最近のFFmpegならデコード出来ると思うので適当に可逆圧縮したりして見て
https://www.dropbox.com/sh/m00enufidjiccn0/AAAlHT953Bxm5xDS2UON6mfGa?dl=0&;lst= 書き忘れたけど比較のために置いてあるx265、x264はtune ssimでエンコードしてある
それとソースの映像は↓のpedestrian_areaってやつ
https://media.xiph.org/video/derf/ HEVCもAVCもエンコーダー次第だからなぁ。
未だMPEG2のテレビ方法だと差は歴然だが…
低ビットレートだと画質悪いのは当然だし、低ビットレートだとHEVCもAVCよりマシって程度。だから十分なビットレートが確保できる場面が中心になる今後は、AV1よりHEVCで十分としか言いようがない。8KもHEVCで十分。
ビットレート確保できるような大容量回線の開発を進めた方が賢い サンプルありがとう
ド素人の目で見た感じ
ディテールの表現
AV1＞x264＞x265≒VP9
動画として見て
AV1＞x265＞VP9＞x264
どうせ大したこと無いんだろうとか思ってたけど、かなり良くて驚いた
この性能でエンコード/デコード処理をどこまで軽くできるか… 外出先からなんで動画は見れてないのだが、これ相当ビットレート落としてないか？
HEVCでここまで悪化するのはよほどの場合だと思うのだが >>878
乙！
動きのある部分 x265
動きの無い部分 VP9
自分はx265がベストAV1はこれからな感じかなアニメとかにはいいかも
※個人の感想です 動画の再生はできないから、静止画のみでコメント
今のところAV1でなければというほどのメリットが見いだせるような画質ではないな
そもそも俺の使い方でFull HDを1000kbpsとか見たいな高圧縮自体使わないし
H.264⇒H.265みたいな画質的メリットがあれば見当もするのだが、それほどでもないし 1000kbpsで画質を比較するのは確かにアレだしもっと高いビットレートで比較したいというのはあるんだけど、
AV1の1000kbpsをエンコードするのに40時間もかかって更に高いビットレートだとエンコードに一週間くらいかかりそうな感じなので厳しいかも >>840 でコードにv1.0.0のタグが打たれたようだけど、
仕様の方も固まってたみたいだね。
ttps://aomediacodec.github.io/av1-spec/av1-spec.pdf
やっと最適化が進むのかな 光回線の普及で、日本ではH264のビットレートで十分。
AV1まで時間をかけて無理に圧縮する必要ない 何度か書いてきてるけどAV1は俺やお前らのために作られているコーデックではない 配信事業者やらIT企業の都合で作り始めたコーデックだしなあ でもさ
いくら優れたコーデックができても
オリジナルは取っておくよな
俺はHDD節約したいだけなのに H264/H265でも構わんのに、企業の都合で対応デコーダ積んだ機器に買い換える出費はユーザー持ちという >>892
不在時間中にGoogleフォトに上げさせておけば、各種解像度に勝手にエンコードして保管しといてくれるぞ >>893
新フォーマットに対応してないハードやOSならH.264やH.265でDLされるし
手元の機器が古くなって買い換える頃には勝手に対応ハードになってるだけの話だと思うが
新フォーマットが出たら即座に対応機器に買い換えないと気が済まない病気？ 圧縮動画をさらに別型式に再圧縮したら確実に劣化する
ようつべでもそうだし 新しい動画規格なんて必要無い、古い規格で十分だ、って言ってる人はなんでこのスレを見てるのか分からん どうせアレだよ、PS2もPS3もPS4も出たら叩き、
ratinaなんて眼の識別能力超えてて無駄とのたまい、
DVDで十分、BDなにそれUHD-BDなんて普及しない
FullHDもいらん、4Kもいらんと言い、HDR何ぞゴミと
絶叫して、その後しれっと手のひら返しする人達のひとり 新しい規格や新技術なんて必要なら普及するし、不必要なら普及しない。それだけでしょ
それを見守っていくのがこのスレなのに、必要ないわ旧規格で充分だの何だの言うのは意味不明 AV1の2000kbpsを追加
途中までだけどグラフも作った
http://i.imgur.com/9uA0WZD.png
少なくとも低ビットレートでは優秀な性能なのが分かる >>901
そのグラフの変化量から類推すると、3000kbpsで大差なしになりそうだな
そして画質を考えた場合、3000kbps以上は必要になるだろうことを踏まえると、
現時点で時間と電気代費やしてまで個人が手を出すメリットがないという結論になるかと >>902
どう見ても3000kbpsでも大幅に上回りそうに見えるが… 0.97位にはなるでしょ？
それが大幅と言うのは言い過ぎかもしれない
それにネットストリーミングだと1000〜2000kbpsがターゲットでしょ いつからか知らんけど、H.265の v5 (Approved in 2018-02-13) の規格書が
TIES user以外でもダウンロードできるようになってた。
H.265?:?High efficiency video coding
https://www.itu.int/rec/T-REC-H.265 今更だけど、4/9にリリースされたIntel Media SDK for Windows 2018 R1 (API v1.26)で、
Cannon Lake向けのプレビュー機能としてVP9エンコード関連のAPIが追加されてたので、
Cannon LakeからはWindowsでもVP9エンコード機能が利用できるようになるのかも。
What's New in Intel Media SDK for Windows 2018 R1 | Intel Software
https://software.intel.com/en-us/blogs/2018/03/07/whats-new-in-intel-media-sdk-2018-r1
>Preview features for Cannon Lake
>
> ・Improved HEVC encode video quality:Enabled Sample Adaptive Offset (SAO) controls,
> multiple Largest Coding Unit (LCU) Size to choose the luma LCU size, and Transform Skipping.
>
> ・NEW VP9 encoder features: Enabled Segmentation controls and Temporal Layer configuration,
> and added external VP9 parameter controls 人の目で見て、って事でしょ。
それより、ストリーミングはもう3000kbpsは超える時代では？2Mbps程度が最適な環境のユーザーをターゲットにする意味無さそうだし、6Mbpsくらいで考える必要あると思うが。
極端な話、6Mbpsで2Kを配信するか、4K配信に耐えうるか、という
そろそろ次スレの時期なので、テンプレ案を作ってみました。
スレタイにはVVCを追加。
追加・削除・変更案などがあればお願いします。
次世代ビデオコーデック総合スレPart2向けテンプレ案１
https://pastebin.com/91jVdNDp >>909
mp4の頃は1080pの動画で5〜8Mbpsが普通だったと思う
それがVP9になったら大体2〜3Mbpsに収まっててビビったけどな
AV1の目的はそれを1〜2Mbpsまで落とすことでしょ >>912
フロッピーディスク１枚に
フルHDが5,6分入るのか
凄いな >>913
そんな夢規格があれば通信問題なんざ一気に解決だな！！！ >>909
高いほうのスペックに統一しても割に合わないし トラフィックいっぱいいっぱいで光回線ですら１Ｍ出ないこともあるのに
６Ｍターゲットとかどうなの >>911
今のところKabyLakeでVP9エンコード機能を利用できるのはLinuxだけらしいんだけど、
CannonLakeからはWindowsでも使えるようになるかもねという話ね。
>>35と、>>910のテンプレ案の7のところを参照。
>>980まで残り少ないんで、>>910のテンプレ案へのご意見はお早めに。 >>894
ハメ撮りとかクラウドに上げられないだろ うちはeo光100Mbps契約だが、混んでる時間でも15Mbpsを切ったことはないな 自分の環境がそうだからってみんあそうとは限らないし
そもそもネット配信はスマホなどモバイルでの視聴がかなり多いのに6Mbps以下は切り捨てはマズい判断 VP9もそうだけど、コンテンツ配信側の意向則したロジックチューニングなのは分かった ユーザーの回線環境なんて関係ないだろう
動画配信業者がトラフィック削減のためにやってるんだから そもそもユーザー側で動画をソフトウェアエンコードしたいという需要が今や少数派すぎる。
大多数は動画コンテンツを消費しかしないし、
保存のためにエンコードするにしてもレコーダーとかだからハードウェアエンコード。 日本のインフラと定額回線を基準に考えているやつは絶望的に想像力が欠如している
大手配信業者がサービス展開してるのは日本のような国ばかりじゃないんだぞ >>912 YouTubeはH.264で3〜4Mbpsくらいでエンコされてるぞ。VP9も同じくらい（動画によって圧縮できてたり逆にサイズでかくなってたり、差がある）。
個人的な話だけど、コーデックは得意不得意があるせいで、VP9の方が破綻少ない場面が多い反面、H264の方が精細に表現できる場面もあったりするから、圧縮効率よりそっちを重視してる。 というか日本も固定回線の品質はここ数年で悪化しているような… テンプレ以外の次世代コーデックはavs2とrmhdとxvcがある >>933
あるっちゃあるけどテンプレに入れるほどでもないかなーと・・・ スマホでmpeg2やh264食わせたら、HEVCやVP9に出力してくれるようなアプリって言うあるの？
エンコーダーはカメラ入力しか使えないの？ iOSは知らんが、Androidだとffmpeg media encoderってアプリがある。スマホじゃ遅くて使い物にならんけどな 将来AndroidのHWエンコーダ使ってくれるようになったら
PCの外部エンコーダーとして使えて便利かもね
何台もつなげて高速化 >>936
自分はiPhoneで有料だけど Compressor っての使ってる
https://itunes.apple.com/jp/app/hevc-h-264-video-compressor/id1300463334?platform=iphone&;preserveScrollPosition=true#platform/iphone
バッチ処理したいなら同じ作者がバッチ用のアプリも作ってるんでそっちの方がいいかも。
SoCのHWを上手く使っているのかiOSが優秀なのかまあまあ使える速度。さすがに映画クラスの長さだと時間かかるけどな お馴染みXiphのMontyによるAV1技術解説がMozillaのサイトに公開されてたよ
ttps://hacks.mozilla.org/2018/06/av1-next-generation-video-the-constrained-directional-enhancement-filter/ 日経BPにAndroid Pについての記事があったよ。
ttp://tech.nikkeibp.co.jp/it/atclact/active/15/070800078/062900084/
新しいメディア形式とデコーダーのサポート
このほかの変更点としては、MPEGの画像フォーマット形式「HEIF（High Efficiency Image File Format）」や
HDR対応「VP9」形式への対応があります。
HEIFは、ビデオ圧縮方式であるH.265（HEVC：High Efficiency Video Codingとも呼ばれる）を利用した
画像の格納形式で、
複数の静止画や動画などを1ファイルにまとめられるファイル形式です。
利用分野としては、高速で連続撮影した静止画（バースト撮影）を
1つにまとめるなどの用途があります。
VP9は、グーグルが開発した動画データ形式です。
Android Pでは、HDR（High Dynamic Range）に対応した「VP9 Profile2」に対応します。
既にYouTubeでは、同形式がHDR動画用のフォーマットとして使われています。
これでスマホの画像形式はHEIFで統一されるかな。 iPhone
Mac
Windows
Android
全部HEIFで統一か
WebP… HEIFの作成までサポートするんだろうか。
iOSとの互換性のためにデコードサポートするのは分かるが。 AV1の画像フォーマットも参戦するだろうけど、それほど力入れてなさそう
画像はユーザーが頻繁にエンコードするから遅いのは嫌われるし勝算は無さそう >>949
すっっっごくどうでもいいことだけど
README-ja みたいに「xxx-ja」って表記見ると
愉快な爺さんが「りーどみー、じゃっ☆」ってお茶目に話しかけてる様が思い浮かんでしまうのは自分だけか
むしろ自分だけだと言ってくれ 電書の配信で容量大幅に削減できるんだから静止画も変わっていくだろ
ieでwebp対応するし 早くPDFにHEIFのまま入れられるようにしてくれ
（PDF生成側でHEIFを受け付けてJPEGに再圧縮して…じゃなく
データとしてHEIFのままPDF内にデータを保持する意味で） >>980も近づいてきたし、>>910のテンプレ案に意見があればお早めに。
次世代ビデオコーデック総合スレPart2向けテンプレ案１
https://pastebin.com/91jVdNDp 静止画HEIＦにするのいいけど、使用料徴収しないのはストリーミングで、ダウンロードする電子書籍とか料金取られないの？ コンテナにはロイヤリティも糞も無い
HEIFでターゲットにしている主要画像圧縮コーデックのHEVC Imageにロイヤリティが掛かる（場合がある）けど
コンテナだから別のコーデックでも構わんのよ
ロイヤリティの有無はコンテナじゃ無くて中身で、mkvでもHEVCの映像入れて商用で使えばストリーミング（データ原本丸ごと渡さない）ならロイヤリティ掛からないし
ファイル本体ダウンロードさせたり、メディアに入れて配布すればロイヤリティ対象になる >>956
よく纏まってると思うし、これでいいと思います JPEGに比べてややこしいのな
同じHEIFなのにこの環境では開けないぞおォン？？？とか喚く情弱が増えそう じゃ、コンテナだけ変わっても中身jpegじゃ、意味ねぇ なんでHEIFの拡張子.heicなんだよ
わけわかんねえ 思い込みで文句言うな
HEIF形式データが入ってりゃの拡張子は.heifでもいいというか、本来の拡張子は.heifで可用性のための別称的な拡張子の方が.heic
画像用のイメージコンテナフォーマット（Image Container Format）なんで
High Efficiency Image Container (format)の意
拡張子が.heifだと、それこそHEIF使っていないと語弊があるんで、必ずしも映像データがHEIFではない可能性も含めて潰しが効く拡張子として.heicがある
入れようと思えば何でも入るが、High Efficiencyと銘打ってるコンテナに入れるのが従来形式データだとなおさら語弊があるから、現状だと実施HEIFぐらいしか無いってだけ
AV1系のAVIFが熟れてくれば候補にはなるのだろうけども >>963
思い込みでデタラメ書いちゃあかんだろ。
・HEIFはISOBMFFベースのファイルフォーマット規格。
・画像のコーディングにはHEVCだけでなくAVCも使える。
・画像のコーディングを明示しない場合は、拡張子は.heifとする。
・画像のコーディングをHEVCで行っている場合、拡張子は.heicとする。
・画像のコーディングをAVCで行っている場合、拡張子は.avciとする。
・一般的にはHEVCでコーディングするし、それを明示するために、拡張子.heicが使われている。
参考： https://nokiatech.github.io/heif/technical.html
一部表現が微妙かもしれないが、こんな感じだと思うけど。
あと heic が High Efficiency Image Container の略だという根拠ってある？
ググるとそう説明してるサイトもあるようだけど、まっとうな根拠が見つからないんだよね。
ISO/IEC 23008-12にもそういう記述は無いみたいだし。 HEVCがHigh Efficiency Video Codingだから、heicはHigh Efficiency Image Codingとしか思えない
正式に定義された用語では無いだろうけど H えっちな
E エロス
I イクイクッ！
F ファッキン！！！ Return of the Codec Wars: A New Hope—a Streaming Summer Sequel
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=126339&;PageNum=1 youtubeで使われてるVP9 は、MP4とかH.265より軽いのですか？ まずコンテナフォーマットとビデオフォーマットをだな…
x264,265と仮定してエンコードはそのどちらと比べてもどうしようもないぐらい重い。264のデフォ設定と比べれば2桁ぐらい重い。
デコードはハードウェアデコーダの対応具合による。
4k以上の高解像度ならh264よりもVP9/webpの方が軽い場合もある。 一般ユーザーは、古い環境で使わないのであればHEVC（H.265）でエンコードしときゃいいのよ 誰でも気軽に使えるHEVCエンコーダがあればいいんだけどね インテルがもう少しQSV-VP9に力入れてくれたらいいのに VP9も結局サービス提供企業側向けだからな
個人ならH264でもHEVCでも良いんだし、HWデコード環境もVP9より困らない ワープロの扱いにすら苦慮してるジジババでもかんたんにできちゃうレベルってことじゃね？（適当） 今でも適当なbatファイルとffmpegで、投げるだけで出来るでしょ 適当な書き込みで踏みましたが
>>910 に則って次スレ立てます >>982
１時間に20レスつかないと落ちるという仕様（？）で落ちたっぽいので、新たに立てにいってみます。 次スレ
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1532001049/
テンプレは貼り終わりましたので、20レスつくまで保守カキコ継続。ご協力願います。 >>985の次スレはおかげさまにて無事即死回避できた模様なので、こちらはあとは適宜埋めで。 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 189日 18時間 59分 55秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
