テンプレ化するかどうかはともかく、保守ついでにいくつか。
559名無しさん＠編集中 (ﾜｯﾁｮｲ 6344-O4z1)2017/09/05(火) 20:16:48.61ID:ObU8b+GC0
■AV1コーデックの基本的な試し方 https://aomedia.googlesource.com/aom/ 今のDTV板の仕様だと、1時間に20レスつかないとすぐ落ちるんだっけ？？？
言い出しっぺだから保守
スレ立て人以外のレスも混ざらないとダメなんだっけ？よくわからん。
>>21 >>1 乙 >>25 >>27 ソシオネクストはパナソニックのブルーレイレコーダーとかやテレビにも使われてるはず
凄いじゃん
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3 http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/HEVC-in-HLS-10-Key-Questions-for-Streaming-Video-Developers-122637.aspx >>38 次世代ってんだから別に何も入れない方が総合っぽいけどな
>>5 と>>42 の補足メモ。なおビルドは試していない。 https://jvet.hhi.fraunhofer.de/ https://tech.ebu.ch/news/2018/01/ebu-compares-av1-jem-and-hevc JPEG XLの技術公募締め切りが今年4月までなんだが
補足 >>48 は>>46 の記事で紹介されてるリンクで、複数の画像について AV1/x265/JPEG/Original の比較が可能。 久々にAV1ビルドしようと思ったらcmakeとnasmが必要になってたのね
うちでcmakeを実行するとaom/build/cmakefiles/cmaketmp/の下に出来る実行ファイルを
静止画でjpegより高画質な物はもう売るほどあるけど全く流行らん不思議
>>57 イラストなんかだと5分の1くらいまで圧縮出来るようなケースも結構あるけど写真だと良くて2〜3割くらいしか縮まないし
AppleがHEIF
https://news.mynavi.jp/article/jpeg-2/ heifってコンテナだったのか
結局、次世代規格はどれが一番良いんだ…
当然、HEVCだよ
AV1は再生は軽いの？
アップルがAOMに入ったことでブラウザベンダー全てがAOMメンバーになったからウェブではAV1が確実に広まるだろうな
>>68 >>75 これだけ世界中のITと半導体の大手が集まってもなかなか完成しないもんなんだな
>>80 >>80 https://github.com/ksvc/ks265codec 2500〜3000倍か…時間がかかりすぎるどころの話じゃないな…
ストリーミング動画の流れによって曲がり角を迎えるMPEGについて「MPEGの父」は何を思うのか？ http://gigazine.net/n ;ews/20180130-leonardo-chiariglione-mpeg-crisis/ >>81 エンコードが激重でも有意に縮めば適当な所でgoサイン出るかもね
HEVCもリファレンス実装の時はエンコード遅くてx265が最適化しまくって早くなったけどAV1はどのくらい高速化する余地があるんだろ
>>90 >>82 Firefoxは既にAV1をデコードできるらしいな
そういやそうだったな
>>95-96 https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/ https://demo.bitmovin.com/public/firefox/av1/ >>103 >>104-106 VP9のエンコードも相当時間かかるのにYoutubeのあの量とあの解像度のVP9をあんなに短時間でどうやってエンコードしてんだろ
>>110 http://2chb.net/r/avi/1485191956/223-224 >>223 VIDEO >>112 Stand by for H.266 compression https://advanced-television.com/2018/02/01/stand-by-for-h-266-compression/ デコードのほうは
AMDってAOMediaに加盟してるのにデコード出来ないのか？
シェーダーだけだからキツいね
YouTubeガクガクVP9でしょ
GPUを利用したソフトウェアデコードとかすれば、専用デコーダ積んでなくても早くなるとかならないもんかな
>>120 http://bluesky23.blog.shinobi.jp/entry/20180210 たぶんあってるはず
これは機能は実装したけど致命的なバグがあって使い物にならない代物だったということかな?
そういえば>>112-113 の VLC 3.0.0 でのExperimentalなAV1デコードの話は、 xvc codec https://xvc.io/ >>129 AV1は別にHEVC超えなくて同じくらい狙えばよかったんじゃないの？？
あれか、AV1がHEVCと同じくらいだとひょっとして世代的にVP9と同じになちゃうのかな？・・
つーかDLすると264もVP9も大差無いんだが
>>136 4320p60fpsの動画つべに上げてみたがローカルh264の半分強の負荷で再生出来たのはその為か
>>140 訂正 映像業界に潜伏してるエロイ人に質問です
>>139 【2018】 H.265/HEVC Part8 【7680x4320】 スレから誘導させてもらいました
規格もエンコーダーも違うから答えられる人間は存在しない
>>147 ARD（アーアールデー）やZDF（ツェットデーエフ）、RTL（アールテーエル）など大手含めて完全にMPEG2からHEVCへ切り替えか
最初からHEVCへの移行も視野に入れた規格にしてただけでは >>149 >>152 >>149 >>56 のリンク先PDFより >>150 https://de.wikipedia.org/wiki/DVB-T2_HD HDで提供されてる360°映像は画質クソすぎて見れたもんじゃないから、8Kで提供されるようになれば有り難いね
Youtubeは既に8K 360度 3Dってのもあるね。
>>159 >>139 >>160 つべのフォーマット272(8K60pのVP9)はGTX1070がギリッギリデコードが追いつく程度
>>160 >>164 テスト対象：VIDEO >>166 固定機能だけど、GT1030はNVEncが省かれたりしてるので違うかも？単に無効にしてるだけで同じかも？
デコード回路の規模はPureVideoHDのバージョンで同じ気がするけど
CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
圧縮は出来ても速度が尋常じゃなく遅いのが現状なんだっけ？
50代後半の人が定年になるまでは安泰だろ。
youtubeとnetflixが採用するの決めてるし
エンコは企業に任せるとしてハードウェアデコードできないと厳しいかね？
> ・Warped motion and global motion compensation
そりゃあハードウェアエンコだろ、それこそニューラルネットワークがーって革新無いと無理だろうねコレ
次の次くらいのコーデックはニューラルネットを使ったものになりそうだな
>>183 対抗馬のhevcを引き合いにMB-Treeって書いたけど
HEVC採用、mpeg陣営の最新静止画規格が一番乗りか
AV1のサンプル動画見ると、MB-tree的な機能を効かせまくってるように感じる。
乾いた雑巾を更に絞るようなもんだしな
>>194 HEVC Advanceがコンテンツ配信著作権使用料廃止、特定の著作権料金と上限を減額 https://japan.cnet.com/release/30237475/ >>199 しかしあれだな・・・。>>196 のStreamingMediaの記事でも http://velosmedia.com/ ストリーミングで金がかからなくなるのか
でも、徴収をやめるのはHEVC Advanceだけで、他にもパテントあるんでしょ？
>>206 mukenさんがHEVC Advanceは四天王の中で最弱っていうネタ投稿してたけど
ブラウザはどうなるんだろうね。H.264の時もFirefoxやChromeは対応を渋ってたけど。
まあAV1のこともあるし、バラバラで複雑になってるH.265のパテントホルダーに圧力をかけるためにも、
おいおい、iPhoneで撮ったHEVC動画はどうなるんだよ
ffmpegはGoogle Summer of Code 2018でHEIF/HEICの読み込みを実装する予定らしい。 https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2018 >>210 >>216 なんでCISCOが肩代わりして支払ってるんだろ？
>>216 >>210 で書いたように、OSのデコーダを無効にしただけで再生できなくなっちゃうし。 HEIFってBPGみたいに全然使われないかと思ったけど案外採用されてるね
圧縮画像は基本420だから、それほど危惧する必要はないんじゃないの？
YUV420は赤の崩れみたいな問題もあるし、RGBかYUV444/YUV444P10があった方がいいという話では。
420と444とRGB(可逆)で拡張子か何か変えて1発で判断出来るようにしてくれよ
>>228 高圧縮なコーデックが流行るのはいい事だと思うけどheifはライセンスどうなってるんだ？
もう旬は過ぎた感じだけど、今更本の自炊を始めよう思ってるんでHEIFが普及してくれるのはありがたい
>>230 https://nokiatech.github.io/heif/technical.html 日テレ系SOC、HEVC 60i 1920x540というかなり特殊な設定使ってるのね
>>235 VLCは3/13のコミットからHEIFに対応しつつあるらしい。 https://nightlies.videolan.org/ >>238 >>240 >>235 >>233 >>235 >>236 HEVCは本来インタレをサポートしない前提だったんじゃなかったっけ？
そもそもいつまでインターレース使う気なんだ。
1440x540のデータ量でフルHD60fpsと言い張れる
>>249 H.265にもインタレの規定はあるみたいだし、以前x265スレ http://2chb.net/r/avi/1462270195/173-189 # x265でインタレースエンコード http://x265.readthedocs.io/en/default/cli.html#cmdoption-interlace フィールド周波数高い60Hzだから、倍速120Hzが効きやすくなる
>>255 インターレースお払い箱批判が酷くなったのは
個人的にはフレームレートや解像度を多少下げても
>>258 >>257 瞬間的に入る紙吹雪パターンに遭遇したら
かのDVDフォーラム vs DVD+RWアライアンスみたいな構図やなｗ
60pと比べたら60iの方が良いけど、
60pと比べたら60iの方が良いけど、
>>262 >>264 >>266 >>267 >>261 と同じ内容を２度繰り返したのかよくわからんが、HDだの12倍だのは本筋とは全く関係なくて、 意外と収録のみの現場ではPsFが活用されてたりするのだ
あー、コストや状況等を踏まえてフォーマットを選択するのは当たり前だろうから、
HEVCでインタレとか何考えてんだ…マジで放送にしか需要無いから
ここはPS4proが擬似4Kのために使ってる市松模様方式で…。
綺麗にデインターレースできる映像は
Multi-Codec DASH Dataset: An Evaluation of AV1, AVC, HEVC and VP9 - Bitmovin https://bitmovin.com/av1-multi-codec-dash-dataset/ >>277 https://mediaarea.net/MediaInfo/ChangeLog だったらFirefoxとChromeとEdgeはHEVCに対応してくれるかな？
どうだろうねえ。 https://github.com/AOMediaCodec/av1-avif ) 仕様が固まったということじゃなくて
3000倍の時間かけてまでエンコードするほどの価値あるコーデックではないということ
>>283 ハードウェアエンコーダーが出ない限り、AV1に実用性はない
IntelとAMDとNVIDIAの名前があるんだし、HWエンコーダーは出てくると思うぞ
>>281 https://m.srad.jp/story/18/03/19/1052226 >>277 >>293 >>280 は「AV1が諦めた」と勘違いしてたのか・・・。意味を取り違えた。 >>282 はブラウザのHEVC/HEIF対応可能性について書いただけであって >>281 民生機でも実用的な時間でエンコードもできるコーデックと
これまでAviUtlやAvisynthのプラグインの開発者ですら
BDはさすがに30G超えてくるからエンコ必至だろ。
インタレ解除は例のHWインタレ解除フィルター使うか、レコーダーからのキャプチャーならばレコーダーで解除
MX150搭載なら安いのはLenovoのideapadあたりか
動画エンコードを10万円以下で考えている人はクオリティーなんぞ求めるべきではない
avisynth+対応プレイヤーでリアルタイムフィルタ処理すればいいという話だぞ
>>307 https://github.com/nekopanda/D3DVP 動画の世界は常に流動的だという意識が充分ではないようだな
そんな大袈裟な意識持ってるなら、現存する手法よりも
>TSのままでもスマホやタブレットに転送して視聴した方が楽になった
>>310 インタレ解除については、これ以上の進化は期待しにくい
>>308 >>312 最近の流行りはサーバ側でのリアルタイムエンコードでタブレット等での視聴
BDは気に入ったのしか取ってないからm2tsのまま取ってるけど、ゲームの録画は可逆だから編集後にエンコしてるわ。
16K無圧縮の帯域を実質スループットで通せるくらいネットの帯域が拡大するまでは廃れないんじゃね？
>>323 物理的に無理やろな
もう開発者は開発を始められるんだな、俺は無理だが
HEVCだってリファレンス実装のHMとx265では数百倍は速度が違うのでAV1もこれから多少は最適化されていくと思いたいが
でもそもそもの計算の複雑さがHEVCの10倍とかあるんでしょ?
なんかロゴが折り紙のように見える
放送に採用されないコーデックは、どこまでいっても中途半端
aomのコードはまだリリースタグはついてないのか。
標準品質で同じ動画を変換するとx264よりx265はどんだけ遅いんだ？
ストリーミング時代に放送がどこまで生き残れるかっていう問題が
俺のRyzen3 2200GだとフルHDの30fpsの動画でx264で20fps、x265だと5fpsくらいしか出なかった記憶がある。まあ普段はHWエンコードしてるんだけど
もう、昔より半導体の微細化のペースとか遅いんだから、
>>342 >>336 >>347 >>348 https://twitter.com/tmvn/status/979038621746413568 >>340 の記事でも引用されてるHEVCのパテントライセンス図に Tom Vaughan 氏がコメントしてた。 >>349 >>352 x265については、プリセットから速い方から2つめのsuperfastと3目のveryfastの間で、3割ぐらいと大きく画質容量比が悪化するので、
QSVの場合だと、SSIMの0.985挟むcrf（ICQ）がH264でICQ 20〜21、HEVCでICQ 22〜23あたり
>>354 ようやくAV1が表に出てきたと聞いて飛んできました
>>356 >>358 >>343 ACAS＋HEVC＋ACASで海外家電メーカーの参入妨害
>>360 将来、「放送」で生き残るのはＮＨＫだけかな
HM比でMH並みの標準実装・最適化で1.3倍の圧縮効率なんだろうし
逆に同じビットレートなら、x264よりx265の方が高画質になる？
個人的にはx265から1割削れて時間5割り増しぐらいに収まれば御の字だと思って居る
符号化性能うんぬんより、特許料ってそんなに重かったのね。新興のコーデックIP会社が中国、アメリカからたくさん出てきて、技術的に枯れるといいなぁー。
圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
>圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
AV1でね・・・1920x1080の10フレームだけをi7-4702MQでエンコードしてみたんです。 非現実的すぎる処理時間に見合う価値は今のところ存在しないな
スピードは結局改善しないままリリースしたんだな、HWエンコでどこまで早くなるかにもよるけどかなり厳しいだろこれ
動画エンコードは、GPUとかの超並列化の恩恵受けられないんですかね
>>383 中身的にはSIMD頼みの力押しでマルチスレッド化が進んでない感じ
x264 mediumくらい縮んでx264 mediumより速くて使用料タダ
x264でもopenCL使えるやん
GPGPUの話は前スレでバトルあったのでそれ参照。
AV1のエンコってwaifu2Xくらいかかんのか…いやニューラルエンジンがある今はAV1の方が…
各エンコーダのプリセット毎に、VMAFスコア、SSIM、エンコード速度を計測して図にしたので置いときますね。 適したスレが無さそうなのでここで聞くけど
画質なら30のほうが良いだろうよ
昨日今日規格が固まって普及はこれから、ってのが次世代じゃなきゃどんなのが次世代なんだ
ああXAVCの話か
>>393 HEVC専用スレの方ももうちょっと活用されてもいいのにとは思う
>>393 こんなスレで業務用途のコーデックの話なんか聴いても、まともに答えられるやつなんかほとんどいないだろ
単純に考えて、100Mbpsで30pなら60pの場合は200Mbpsで同等画質じゃないのか？そんな簡単な話でもないんかね？
GOP的な圧縮は画像シーケンスと違って差が小さければ圧縮効率良くなるなら60pはその分圧縮率上がるのでは？
30→60だとフレーム間予測が効いて、順当には必要ビットレートは増えないと思うけど
元ソースが30pとして、単に補完フレームの破綻防止に同じ画の繰り返しでもフレームレート有った方が良いのなら意義はあるのだろうけど
確かに30pより60pの方が差分が小さくて、処理も軽くなりGOP圧縮効率上がる
>>408 AV1 Is Finally Here, but Intellectual Property Questions Remain http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=124134 4KをQFHDと呼ぶのが主流なの？
100by遅い→使いものにならないと自白
x265もリリースしたての時は全然速度出なかったろ
ハードエンコの有無っぽい数字だな
30%程度の効率改善程度では、コーデックを切り替えるほどの意味はない
>>413 の記事から更に抜粋。 UHD-BDだけならともかく、放送にも採用されたHEVCをプゲラッチョとか、頭悪いにもほどがある
いや、ストリーミング市場限定の話として書いてあることくらいわかるだろ・・・
記事の紹介や和訳には感謝だけど、個人の主観混ぜ込むのは誘導にも似た効果も含むから控えた方が良いと思う
そもそも、ライセンス料払いたくないストリーミング業者向け作った規格だから
>>423 >>426 個人運用の範囲じゃライセンス問題の影響極小だし
でも、そもそもパテントのことをぎゃーぎゃいうなら最初からvp9でよくね?仕切り直して新しいコーデック作りゃなんとかなると思ってんのか。googleは孤軍奮闘で今まで頑張ってたが。他の配信企業なんなんよ。
VP9は悪くはないが4K8K時代に使うには圧縮効率が物足りないし、
4K8K放送のcodecって決まってるんだっけ？
Netflixとかはやっぱオリジナルコンテンツだけでも全部4kで配信したい！って考えてるんじゃないかな、そうなるとVP9やHEVCでは足りないのかもね。日本の平均ネット速度は17Mbpsらしいけど世界平均は6Mbpsらしいし
>>430 放送波のTSを4:2:0の無圧縮720p化したものをソースにして、AV1のサンプルエンコーダ（自前ビルド）とx265比較してみたが
まぁそれでもUltraFast〜FastプリセットよりSSIMが上にはなってることは確かだから、素のHEVCだけよりは高画質なのは確かなんだろうけどね
>>437 >>440 売って開発企業が利益を上げたところでトロールだけ制裁加えれば問題無い
トロールなんかに金払う必要ないわ
パテントの一次受けが決まっているんだから、それを飛び越してライセンシーに請求しても、HEVC Advanceと契約してパテント料支払っているんだから、HEVC Advanceに請求しろとなる
>>438 HEVC Advance、更に新規ライセンサー、ライセンシーを加え、その推進力を強調 https://kyodonewsprwire.jp/release/201804042642 え？ HEVC>VP9だろ？
早い遅いはコードの差も有るから、コーデック自体の比較では何とも言えないでは？
>>378 ですが、現在のffmpegのlibaom-av1は、-tile-columnsに未対応だったので、 >>453 まとめ https://github.com/jb-alvarado/media-autobuild_suite 再度の検証お疲れ様
>>455 場所が無いにしても、不可逆それも画質容量比と効率が主題の次世代ビデオコーデックのスレでも板違い
https://developer.nvidia.com/nvidia-video-codec-sdk >>461 最後については、手法的には前からある（x264とかには既に有る）実装
Bフレームの参照の方は、Bフレームが続く場合にPフレームからの差分では無くBフレームからの差分参照出来る様になるんで、動きが少ないとか、ブロック単位でズレるだけみたいな場面でより縮む様になる
このSDKを使うのはNLEやエンコーダ各社？ >>464 >>465 >>463 >>466 http://nico-lab.net/nvidia_gpu_encoder/ 要するにハードウェア的にはBフレームに対応してるんだけど、それを動かすソフトウェアの開発部隊がカスしかいなかったんだろ
最後、「NVIDIAに画質を語れるような目利きがいた試しはないが」に訂正
>>468 >>466 も言ってるけど、NVEncではH.264なら元からBフレーム自体は使えていたよ。 >>464 >>467 >>472 http://2chb.net/r/avi/1486130737/335 >>122 で書いたようにVP9のHWデコードも迷走してたし、大丈夫なんだろうかって感じがする。 >>471 >>473 >>477 >>478 http://2chb.net/r/software/1487682297/568-571 >>482 >>483 >>484 AOMのソースのところに書いてあるのと同じサンプルだね https://media.xiph.org/video/derf/ >>486 >>482 のFacebookの実験ではderfのサンプル群は使っていない。 エンコードにH.264の10000倍かかったとしてもエンコした動画を1回しか見ないような俺らに対して
>>489 x264やx265みたいな魔改造エンコーダがまだ無いからな
NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような画質水準には達していない）しか作れないみたいだから、アテにならんと思うがねぇ
NETFLIXなど大手の配信業者も多く絡んでるし可能な限りハードウェア処理し易い設計になってる可能性はまたあるとは思う
>>492 >>494 NVEnc自体は、nvidiaのGRIDみたいなクラウドや、LAN内でのゲームのリモート操作のためのもので
>>489 >>490 >>492 >>473 とか） 画質重視でもYoutubeに上げる為にロスレスで圧縮するときはNVEnc使ってる
NVEncのロスレスって4:4:4だと聞いたけど、Youtubeはそれも受け付けてくれるのか。
詳しくは知らないというか知る由もないんだけど、NetflixとかYoutube（Google）みたいな資本力のあるところでもHWエンコしてるのか？ああいうところって一般人じゃ到底手に入らないようなスペックのコンピューターでSWエンコしてると思ってたんだが
>>501 >>503 >>503 >>509 GoogleのサービスでH.264トランスコードはx264だっけか
配信サイトで再エンコードされない設定って言うのはよく聞く誤解だね
昔の実装そのまま今でも一緒だと思っていたり
そりゃyoutubeへのアップロードに関する話題とか昔の流行だもの
よくわからんがYoutubeで再エンコードされないようにする設定があると勘違いしてたってことか。
Youtubeは1回エンコされるのは確実として多重エンコにならないようにロスレスで上げるのが基本じゃないの？
>>517 自分はx264 crf12ぐらいで上げてるな 16と程度と比較するどちらが綺麗かは分かるレベルだったし意味なくは無いと思う。
低いcrfほどエンコーダの差が画質に出てこなくなるから、QSVやNVEncでササッと処理済ませてアップロードし始めた方が手早いかも
1080pの335フレームでAV1をテストしてみた。 >>521 libaomはリファレンスみたいなもんだし、まだ最適化もされてないから >>521 のサンプルでは-cpu-used 3 -crf20で335フレームのエンコードが約3時間4分だったけど、 very slowの17倍って今の段階なら悪く無いじゃんって思ったけどx264ならmidiumの数倍程度だけどx265だと凄いんやね
話題が無いので間潰しにNVEncネタ
NVEncの処理速度的については、固定量子化でブン回す場合には、FHDでの出力ならピーク値でH264で600〜650fps、HEVCで400fps前後ぐらい（NVEncのHEVCはBフレーム省略仕様なので速度低下が少ない）
はぁ、1080並の値段でELSAの1070なんてかわなければよかったｗ
捕捉
NVEncの性能で考えれば、リファレンスクロックが高く、エンジン2基のGTX1080が最良
GK208はNVEnc乗ってるのにGP108がなぁ
こういうGeForceの型番ごとにおける機能の制限/無効化ってどこかにドキュメントとしてまとまってるの？
nvidiaのdeveloperにあるみたいな一覧は無いね
そういう情報出さないで売ってるの、なんだかなって思うわ
NVIDIAにとっては、エンコーダーの価値はその程度にしか見ていないということ
なんでAMDは動画最弱になっちゃったんだろ
というか、実用面からすると
公表されてる範囲の機能的なスペックはエンジン1基有れば実現出来るからね
NVDec/NVEncのSDKもnvidia的にはターゲットはTeslaやQuadroで、Geforceでも一応使えるという感じだからね
>>539 アムドの寝言はVP9有効にして
xiphがRustで作ってるav1のエンコーダって話題出てる？
これか https://github.com/xiph/rav1e >>545 >>546 >>122 でも書いたけどPolaris/VegaはVP9のDXVAデコードに対応していない。 >>547-548 >>89 で出てるね。限定的な実装みたいだし、試したことはない。 ビルドして試そうかと思ったけどビルドできなくて放置してた
これcじゃなくてrustなん？
Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね
MozillaのDaalaで使ってたから親和性は折り紙付きだろう
吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
>>554 xiphってflac作ったところなんだな
ハイレゾは全く無意味とバッサリ切ったのが爽快だった
耳に聴こえなくても脳に影響してるんだよ
違いが分かる人と分からない人が
その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
>>573 つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
>>573 ,．-─ ─-､─-､
>>580 >>361 のリンク先読むとVP9の方がHEVCより縮むと読み取れるんだけど…、 >>579 vp系はバッファ少なくても縮むからストリーミングに向いてて良いわ
Advanced Media Framework (AMF) SDK Version 1.4.7 https://github.com/GPUOpen-LibrariesAndSDKs/AMF 要はbuildコードが4/12って事でしょ
今canaryに来たってことはstableに来るのは4ヶ月後くらいかな
ただし、性能いいけど最適化されてない今だと画像一枚変換するのに60秒くらい平気でかかる
ありがと、これで電子書籍の容量減ってくれると助かるなあ
そういえばハードウェアのエンコードって動画の場合ではソフトウェアよりかなり画質が落ちるけど静止画の場合だとどうなんだろう
>>592 Appleは最近画像フォーマットにHEVCベースのHEIFを使ってるけど、 >>595 ソフトとハードでどのくらい違うか気になったので>>592 のグラフにx264とh264_qsvを追加(項目名クリックで表示切り替え可能) https://plot.ly/ ~fg1189467/33/ JPEG-XL >60% over JPEG-1
姉妹規格のJPEG XSは来年完成らしい https://this.kiji.is/361078960999941217/amp JPEG XSコーデックメモ https://qiita.com/yohhoy/items/897a543cde9123e6e461 HDMI2.1もVESAが規格化したDSCを採用するみたいだな。もうDPと統一しろよ https://av.watch.impress.co.jp/docs/series/dg/1100970.html jpegの牙城はH.264より堅いだろうから新画像コーデックを広めるのは厳しいだろうな…
ありゃJPEG XLの技術公募締切が9月に延期されてる
>>604 VP9は画質で判断するとたまにH264よりサイズでかくなるから困る。圧縮するなら相応の力を見せてくれないと
>>603 8Kくらいまで解像度を上げない限りは非可逆にはならないと思うぞ
>>608 >>606 たしかtwitterはgifをアップロードするとmp4(h.264)に変換される仕様だったような
AV1が一般人にストレスなく利用できるようになるのは、いつ頃だろうか？
ストレスなく利用っていうのが視聴の事なら1、2年で可能だろうけどエンコードの事なら一生来なさそう
>>614 >>612 >>617 >>615 >>619 >>616 お前ら可逆不可逆って続けて何回言える？
>>619 >>621 最近は写真や動画を撮ったらすぐにクラウドストレージに投げることが増えてきたから
FLACをアップロードできてOpusがストリーミング配信されているSoundCloudはすごいな
>>627 >>629 PNGは最適化を掛けるとかなり縮むけど、
とりあえずWindows 10の最新アップデートを適用すると、HEIFの表示のみOS標準で対応だとさ
結局OSの対応よりブラウザの対応のほうが大切なんだよね
>>630 AV1の可逆圧縮、相当無理矢理だけどこんな感じで出来た
>>635 >>634 deflateという圧縮技術のデファクトスタンダードを使っているpngが置き換わることはそうそう無いと思うけどね
>>636 https://www.dropbox.com/s/kc7njid1gz12vs0/lossless_bench.zip?dl=0 >>639 >>639 それが出来ないからVVC等の新しいコーデックが開発されてるんだろ
Googleが画像フォーマット「WebP」向けライブラリ「libwebp 1.0.0」をリリース https://mag.osdn.jp/18/05/02/163000 >>650 ChromeがAPNG対応したんだから
firefoxはwebp対応してるだろ
>>656 今年の2月に特許切れたMPEG2にもライセンス料掛かってたしな
映像コンテンツなら殆ど2円未満、高くても3円にもならないとかだし、
GIMPは亀の歩みだし……
昔はPhotoshopの代わりにGIMPでも頑張れば行けるかもって時期があったけど、
GIMPはリリース間隔が空きすぎて開発者のほとんどがKritaとかDarktableに行っちゃったから…
GIMPの前回のリリースって5年以上前だろう
androidのゲームでwebp義務化すればかなり通信料減らせそう
結局webpが流行ることは無かったな
よくわからんけどAndroidのゲームはETC1かETC2が主流じゃないの？
>>670 流石にJPEGも古い規格よなぁ
ストレージは大した問題ではないだろう
その他にも処理速度とかそれをハードウェア処理するチップのコストだとかいろいろあるんだろうけど
近いうちにJPEG2000が主流になるからデジカメの買い替えをちょっと待とう…
もうJPEGくらいに浸透してると
amazonとかの電子書籍を全てwebpにすれば普及する
>>678 >>680 chromeもfirefoxもAV1の一時的なな実装は完了しているから仕様確定したらすぐにでも導入できるはず
つべのVP9と264
VP9はHEVCとAVCの中間あたりに位置すると個人的には考えてるから、得手不得手で旨味なくなりがちだよね
HEVCの技術とAV1の技術を全て結集したらさいきょうのコーデックが出来上がりそう（厨二的発想）
>>688 VP系はMPEG系と比べて先読み短くても圧縮率保てるからストリーミングにはVP9のほうがいいよ
自炊用途は、長期的に安定して再生できる可能性の高いフォーマットを選ばないとあとで後悔するだけ
mkvコンテナ扱える奴なら仮対応的な実装じゃ無ければイケるんじゃないの？
電子書籍とかの複数ファイル画像って
>>695 >>696 そもそも空白が多い画像はjpgなりpngなりでも大きくないと思う。
そこは昔のゲームみたいに口や目の変化部分だけ画像作って
スクリプトミスったら差分の目が背景の上に浮くじゃないですかー
エロゲって画像形式何使ってるんだろ、やっぱり可逆PNGなのかな
吉里吉里ならエロゲ絵に特化したTLG型式ってのが使えるけど
>>695 >>695 電子書籍は突飛なアイデアではなくて自分も数年前に検討済み
漫画なら図形の輪郭とかとかスクリーントーンとかそういうのを符号化すれば…
もう、基本の圧縮技術は画像にしろ動画にしろ、JPEGの時代に確立されちゃってるのか・・？？
500年後の未来から来たけど、今の圧縮技術はその概念自体が使われなくなるよ
電子書籍に関してはePubの規格がバージョンアップしてリフローとフィクスのハイブリッド型も作れるようになってるね
>>708 某ネコさん曰く、16k以上の画素数だとwaveletが日の目を見るかもしれないらしい
JPEG XSもwaveletだそうだけど、どんな感じの圧縮なんだろう。
>>713 >>711 DCTと違ってブロックノイズが発生しないのがDWTの利点だけど、
waveletで圧縮しまくったらどうなるんだろ
特性的にエッジ部分の情報量から削られていくから、そういう部分の階調表現の幅が狭まる（コントラスト低下）と解像度感が失われて眠い画になっていくと思う（俗に言う眠い絵作り
>>619 今の動画サイトは、映像と音声は別々に保存してて、
よくわからないのに書くからこういうことになるんだね
マジレスするとYoutubeの場合、 https://pastebin.com/YiAnRD0w のように、 >>721 はなぜか映像まで含めてWebM vs MP4という比較をしてるし色々的外れ。 ついでに言うとYoutubeの場合、VP9は比較的ファイルサイズが小さくなってるとはいえ、
EdgeはGPUにVP9デコーダが搭載されてればVP9、
HEIFってOSではポツポツ対応しはじめてるけどフリーソフトではなかなか対応しないね
>>732 ネタ切れでビデオコーデック以外のネタばっかりになってきたな
H.264が動画界のJPEGみたいな感じになって終わりやろ
配信があるのでシビアだよ
4Kに対応しようとすると古いPCは一気にアウトだからねぇ http://www.4gamer.net/games/022/G002212/20180524003/ 面倒すぎてRIPした方が早い気がしてくる
アンドロイド定番の画像ビューワ、PerfectViewerがプラグインでHEIFに対応してた
ジャップ製の印刷機やデジタル家電、ソフトなどが対応進まないと無理じゃね
ちょっと戻っちゃうけど
それぞれのレイヤーで最適化しないと
Windows10 Insider Previewでheifの表示試してみたけど対応してるのはyuv420だけでyuv444は見れないな
ちなみにWIC(Windows Imaging Component)でのサポートもしているのでWIC対応のSusie Pluginを入れるとMassiGraなんかでも見れた
MSの実装だとYUVからRGBへの変換係数はbt709固定っぽいけどnokiaの実装だとsmpte170m固定っぽいから色がおかしくなる問題が続出しそう
WindowsはOS、画像ビューアともに伝統的にICCプロファイルをきちんと反映させようとしていない（一部の優良な画像ビューアは対応している）からな
いやごめん
ARMがスマホ向け新GPU「Mali-G76」＆新VPU「Mali-V76」を発表、スマホで8K・60fps再生に対応へ https://gigazine.net/amp/20180601-arm-mali-g76-v76 動画の再生支援に関しては、スマホに先越されてばかりだな
新フォーマット→ハードウェア支援
先越されていたっけ？
HEVC 10bit 8KならIntelならCore iならKabylake、Atom系ならApolloLake（デコードのみ、エンコはGeminiLake〜）以降で対応
？
スマホ -> PC -> モニタ ってめんどくさくね
■VP9（YouTubeなど） http://www.leoplanet.co.jp/entertainment/doga-saisei-shien.html https://en.wikipedia.org/wiki/VP9 追記
ARMはデコードにもGPUの演算コアも使ったりするからな
windowsならタスクマネージャでCPU使用率さくっと分かるけど、androidってシステムていきょうのツールねぇのかよ。
俺もandroid8になって
デコードもGPUコアのクラスタ数に依存しているという事は、メディアプロセッサだけでは、PC向けGPUと違ってデコードも処理出来ていないって事なんだがな
クラウド上のFPGAを利⽤するAV1エンコーダーを実装 https://www.socionext.com/jp/pr/sn_pr20180606_01j.pdf これはいいね。LSIを起こせないようなスタートアップ企業が競い合って早く技術が成熟するといいですな。
今年の第三四半期にAMDの新型スリッパが32コア64スレッドなCPUを投入するらしいが、そんな強烈なのが出たらHEVCのエンコードもサクサクかな？
性能倍なら同世代の16C32Tスリッパの倍以上の価格なんだろうけどね
AV1のエンコーダーなかなか早くならないな
>>787 いや、>>378 ではi7 4702MQで10フレームエンコードするのに66分かかったって書いてるからちょっとは早くなってるかな 今年中に100倍程度速くなるなんて緩い予想はなかなか実現しそうに無いな
1フレームエンコードするのに6分かかるのか
2ヶ月で2.5倍早くなると仮定しても年内に100倍には届かないか
そんな小学生が成人するまで同じペースで背が伸びて2m越えるみたいな計算通らんわな
欠陥の無いダイがすげー安く作れるようになったらワンちゃんあるかも
今のところマルチスレッドをあまり生かしてくれないのが遅い原因の一つ
2passエンコで１pass目でキーフレームの場所を確定させちゃって
>>800 >>800 動画エンコードの探求に「終わり」はあるのか？ https://gigazine.net/news/20180614-end-of-video-coding/ エンコードは1回しか行われないのに対してエンコードされた動画は何万回も再生されるから、
まあh266（？）とAV1以降のエンコードは一般人が持ってるpcじゃなかなか難しそうだろうね、NetflixやYouTube規模の動画配信サービスになるとそれだけの価値があるんでしょ
ハードエンコの品質が上がって画質にうるさいマニアも納得のハードエンコの時代がきたらまだワンチャンある。
>>804 限度知らずに高解像度を無茶な低帯域で保存しようとしなけりゃ、現状のHWエンコでも十分まで行かなくても、そこそこ使えるレベルだと思うけどな
品質についてはVLCの連中がx264/x265の開発止めない限り、個人が無償で扱えるエンコード品質の上限的な基準になっちまうから
配信に使おうと思ってQSVとNVENC試してるんだけど同じビットレートだとNVENCのほうが画質良くなるみたいなんだよね
QSVのH264でFF使う場合でも無い限り、基本的にはQSVの方が綺麗になるよ
あと、比較するQSVの世代にもよる
CUはRADEONか、QSVはEUだった、すまん
dGPU化でAMD CPU使いでも使えるようになるといいんだけども＞QSV
ウェッピーが正式な発音だと知ってるがウェブピーと読んでる
ヽ
・4K映像の低遅延配信に「CMAF」が有効、コーデックは「AV1」主流に? Akamaiが解説 https://av.watch.impress.co.jp/docs/news/1128920.html 数ヶ月前にエンコードしたファイルが新しいバージョンだと出来なくなってるとかまだあるから全く使い物にならないよ
youtubeとかで使われるようになってもほとんどの端末ではしばらくソフトウェアデコードになるだろうけど負荷はどれくらいになるのだろうか
HWデコーダが無い機種はH.264で観ればいいだけだからﾍｰｷﾍｰｷ
すぐに変換されるのは4K以上の動画ぐらいでしょ、きっと
AV1だろうがそもそもモバイルで4K解像度もってるデバイスほとんどみねぇし、2Kにちょっと毛がはえたぐらいの解像度なら現状出回ってる機種でも余裕じゃねぇのかな。
と思ったけどH.264のフルHDをSWﾃﾞｺｰﾄﾞしてみたらFireHD10で結構CPU使用率いくな
YouTubeはビットレートが足りないのと粗雑エンコで1080pは見れたものじゃないから、超高精細映像に構うよりは1080p以下の映像に目線を向けるべきだと
ネットの人ってどうして一つしか正解を許さない人が多いんだろ
頭が悪いんだろ
AV1の対応、ChromeとFirefoxは着々と進んでいるけどSafariとEdgeはほとんど聞かないね
>>843 Appleだって支援してるんだからそれはねえわ
AppleもAOMediaの創設時メンバーなのだから、VP9みたいな事態にはならないと思っているがね
USB Type-C規格策定に大きく関与したが採用せず
ムービーミドルウェア「CRI Sofdec2」が、高いデータ圧縮性能を有するビデオコーデック「VP9」に対応。まずはスマートフォン向けから http://jp.automaton.am/articles/newsjp/20180626-70947/ >>849 macbookの周辺機器MagicKeyboard、MagicTrackpad2、MagicMouse2はLightningだぜ
>>851 AV1完成したっぽいから試しにエンコードし始めたけど丸一日経っても終わんねー
相当ハードウェアエンコーダに実装し易く作ってるらしいしそのうち爆速エンコ出来るようになるでしょ…多分
GPUの演算能力でゴリ押しできないのかね
>>853 >>859 Lightningに固執っていうけど、 >>852 のBT接続な周辺機器の充電用途程度なら 圧縮率に伴って重いってのもあるけど
というか、グラフが正しいならばHEVCとAV1の比較をすると、ほとんど差がないから現時点ではHEVCで充分だな
どうせ次世代JPEGと同じでAV1もH265も流行らない
NetflixやHuluみたいなサイトはライセンス料不要なAV1を間違いなく採用する
結局コンテンツあたりの視聴する客側に課せられるライセンス料なんぞ数円レベルで、
>>869 HEVCもAVCもエンコーダー次第だからなぁ。
画像 サンプルありがとう
外出先からなんで動画は見れてないのだが、これ相当ビットレート落としてないか？
>>878 動画の再生はできないから、静止画のみでコメント
1000kbpsで画質を比較するのは確かにアレだしもっと高いビットレートで比較したいというのはあるんだけど、
光回線の普及で、日本ではH264のビットレートで十分。
何度か書いてきてるけどAV1は俺やお前らのために作られているコーデックではない
配信事業者やらIT企業の都合で作り始めたコーデックだしなあ
でもさ
H264/H265でも構わんのに、企業の都合で対応デコーダ積んだ機器に買い換える出費はユーザー持ちという
>>892 >>893 圧縮動画をさらに別型式に再圧縮したら確実に劣化する
新しい動画規格なんて必要無い、古い規格で十分だ、って言ってる人はなんでこのスレを見てるのか分からん
どうせアレだよ、PS2もPS3もPS4も出たら叩き、
新しい規格や新技術なんて必要なら普及するし、不必要なら普及しない。それだけでしょ
AV1の2000kbpsを追加 >>901 >>902 0.97位にはなるでしょ？
今更だけど、4/9にリリースされたIntel Media SDK for Windows 2018 R1 (API v1.26)で、 https://software.intel.com/en-us/blogs/2018/03/07/whats-new-in-intel-media-sdk-2018-r1 人の目で見て、って事でしょ。
>>909 >>912 >>913 >>909 トラフィックいっぱいいっぱいで光回線ですら１Ｍ出ないこともあるのに
>>911 >>35 と、>>910 のテンプレ案の7のところを参照。 >>980 まで残り少ないんで、>>910 のテンプレ案へのご意見はお早めに。 >>894 うちはeo光100Mbps契約だが、混んでる時間でも15Mbpsを切ったことはないな
自分の環境がそうだからってみんあそうとは限らないし
VP9もそうだけど、コンテンツ配信側の意向則したロジックチューニングなのは分かった
ユーザーの回線環境なんて関係ないだろう
そもそもユーザー側で動画をソフトウェアエンコードしたいという需要が今や少数派すぎる。
日本のインフラと定額回線を基準に考えているやつは絶望的に想像力が欠如している
>>912 YouTubeはH.264で3〜4Mbpsくらいでエンコされてるぞ。VP9も同じくらい（動画によって圧縮できてたり逆にサイズでかくなってたり、差がある）。 というか日本も固定回線の品質はここ数年で悪化しているような…
テンプレ以外の次世代コーデックはavs2とrmhdとxvcがある
>>933 スマホでmpeg2やh264食わせたら、HEVCやVP9に出力してくれるようなアプリって言うあるの？
iOSは知らんが、Androidだとffmpeg media encoderってアプリがある。スマホじゃ遅くて使い物にならんけどな
将来AndroidのHWエンコーダ使ってくれるようになったら
日経BPにAndroid Pについての記事があったよ。 http://tech.nikkeibp.co.jp/it/atclact/active/15/070800078/062900084/ iPhone
HEIFの作成までサポートするんだろうか。
AV1の画像フォーマットも参戦するだろうけど、それほど力入れてなさそう
>>949 電書の配信で容量大幅に削減できるんだから静止画も変わっていくだろ
早くPDFにHEIFのまま入れられるようにしてくれ
静止画HEIＦにするのいいけど、使用料徴収しないのはストリーミングで、ダウンロードする電子書籍とか料金取られないの？
コンテナにはロイヤリティも糞も無い
>>956 JPEGに比べてややこしいのな
じゃ、コンテナだけ変わっても中身jpegじゃ、意味ねぇ
なんでHEIFの拡張子.heicなんだよ
思い込みで文句言うな
>>963 https://nokiatech.github.io/heif/technical.html HEVCがHigh Efficiency Video Codingだから、heicはHigh Efficiency Image Codingとしか思えない
H えっちな
youtubeで使われてるVP9 は、MP4とかH.265より軽いのですか？
まずコンテナフォーマットとビデオフォーマットをだな…
一般ユーザーは、古い環境で使わないのであればHEVC（H.265）でエンコードしときゃいいのよ
誰でも気軽に使えるHEVCエンコーダがあればいいんだけどね
インテルがもう少しQSV-VP9に力入れてくれたらいいのに
VP9も結局サービス提供企業側向けだからな
ワープロの扱いにすら苦慮してるジジババでもかんたんにできちゃうレベルってことじゃね？（適当）
今でも適当なbatファイルとffmpegで、投げるだけで出来るでしょ
適当な書き込みで踏みましたが >>910 に則って次スレ立てます >>982 >>985 の次スレはおかげさまにて無事即死回避できた模様なので、こちらはあとは適宜埋めで。 lud20220915075159ca
このスレへの固定リンク： http://5chb.net/r/avi/1515759816/ ヒント： 5chスレのurlに
http ://xxxx.5ch
b .net/xxxx のように
b を入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】 YouTube動画>3本 ->画像>19枚 」 を見た人も見ています：・次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】 【AV1】次世代ビデオコーデック総合スレ Part8【VVC】 【BW/BW2】第5世代総合 Part4【ブラック/ホワイト】 氷河期世代公務員試験総合スレ Part74 【FCV】 次世代自動車 総合スレ ☆21 【EV】 【高精細】次世代VR総合スレ２【広視野角】 [最新世代]NVIDIA GeForce RTX40XX総合 Part45 [最新世代]NVIDIA GeForce RTX40XX総合 Part13 【バースト】ベイブレード 総合スレ 第92世代 【バースト】ベイブレード 総合スレ 第97世代 【バースト】ベイブレード 総合スレ 第106世代 【内藤吉橋】新日総合スレッド1914【同世代決戦】 クラシックギター総合スレPart96 クラシックギター総合スレPart105 【ETS2】 トラックゲー総合スレ Part40 【感想】東京オリンピック総合スレ part11 【BOOK・OFF】 ブックオフ総合スレ PART.59 ● 全店対象 ビックカメラ Part.14 総合スレ● ベイブレード 総合スレ 第143世代 ベイブレード 総合スレ 第193世代 ベイブレード 総合スレ 第171世代 ベイブレード 総合スレ 第169世代 ベイブレード 総合スレ 第158世代 Netflix/ネットフリックス 洋画総合スレッド Part 31 オリックス ドラフト&ファーム総合スレ part37 オリックス ドラフト&ファーム総合スレ part35 Netflix/ネットフリックス 洋画総合スレッド Part 23 オリックス ドラフト&ファーム総合スレ part42 【佐藤】森内羽生世代総合スレッド【郷田】 【オープンレック】高田健志総合スレpart134【YouTube】 【オープンレック】高田健志総合スレpart242【ツイッチ】 【オープンレック】高田健志総合スレID蟻part290【人狼】 【オープンレック】高田健志総合スレpart193【ツイッチ】 【オープンレック】高田健志総合スレpart249【ツイッチ】 【オープンレック】高田健志総合スレpart261【ツイッチ】 【オープンレック】高田健志総合スレpart59【ゲーム実況】 【オープンレック】高田健志総合スレpart50【ゲーム実況】 【オープンレック】高田健志総合スレpart104【ゲーム実況】 Netflix/ネットフリックス 海外ドラマ総合スレッド Part.12 【バースト】ベイブレード総合スレ 第47世代 【OPENREC】オープンレック総合スレPart2【オプレク・プンレク】 旭川市総合スレ Part51 ■ デノン オーディオ 総合スレッド Part9 ■ R2受験生総合スレ Part 1 東宝総合スレッド PART131 【神ゲー】FF15総合スレ part398【エピソードアーデン3月26日発売】 私立歯学部総合スレpart1 英語の発音総合スレ Part41 PeerCast総合スレ Part31 警察剣道総合スレ part.1 WACK総合スレッド Part701 Jr.総合ファンスレPart1691 Jr.総合ファンスレPart1351 Jr.総合ファンスレPart 1511 五嶋みどり・五嶋龍総合スレ part1 Burson Audio 総合スレ Part1 愛知県春日井市総合スレ part41 青森県サッカー総合スレpart11 レコード・CD総合スレッドPART1 Sony Mobile 次世代Xperia 総合251 Sony Mobile 次世代Xperia 総合149 Sony Mobile 次世代Xperia 総合156 ヘルメット総合スレッド Part291 ★沖縄県中学高校受験総合スレ★Part1
18:57:41 up 45 days, 20:01, 0 users, load average: 7.29, 7.09, 8.81
in 0.90960001945496 sec
@0.90960001945496@0b7 on 022808
