18/04/17 21:09:13.49 aZh6iL+w0.net
これcじゃなくてrustなん？
時代はrustなのか？
581:名無しさん＠編集中
18/04/17 21:13:46.15 0c2uycJlM.net
RustもC言語の派生の一種と言えなくもない
582:名無しさん＠編集中
18/04/19 22:57:58.69 hZLV04Fua.net
Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね
583:名無しさん＠編集中
18/04/20 02:37:09.78 zIebTadQ0.net
Mozilla�
584:ﾌDaalaで使ってたから親和性は折り紙付きだろう
585:名無しさん＠編集中
18/04/20 04:41:34.60 3IIJGeeBM.net
吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
代わりに習得がえらい難しいらしいけど
使用者に最も愛されている言語とか言うけど
愛が無ければやってられない習得難易度の裏返しだったり
586:名無しさん＠編集中
18/04/20 05:30:27.07 HD+81Fzka.net
>>554
Daala作ってたのはXiphだけどな
Xiphは半分Mozillaみたいなものだけど
587:名無しさん＠編集中
18/04/20 07:18:32.61 N1qeHIsf0.net
Daala作ってたのは誰あぁぁぁぁ
588:名無しさん＠編集中
18/04/21 12:52:16.94 tM5w7H6r0.net
xiphってflac作ったところなんだな
知らなかったわ
589:名無しさん＠編集中
18/04/21 13:21:10.75 Qy2Pbsrq0.net
ハイレゾは全く無意味とバッサリ切ったのが爽快だった
590:名無しさん＠編集中
18/04/21 19:19:53.26 BSwSpyS80.net
ハイレゾは無意味じゃないから間違ってるな
591:名無しさん＠編集中
18/04/21 20:42:38.58 mCJYRNDS0.net
URLﾘﾝｸ(people.xiph.org)
592:名無しさん＠編集中
18/04/21 23:18:19.11 6E+waUvMa.net
いや無意味だから
593:名無しさん＠編集中
18/04/21 23:40:10.60 vIk2JOlP0.net
そういうのはピュアAU板ってのがあるからそっちで存分にやればいいと思うよ。
ハイレゾの良さを追求するスレ ★1
ｽﾚﾘﾝｸ(pav板)
594:名無しさん＠編集中
18/04/21 23:54:04.88 BSwSpyS80.net
耳に聴こえなくても脳に影響してるんだよ
聴覚が全てではない
595:名無しさん＠編集中
18/04/22 00:05:32.14 qoqXsoAZa.net
悪影響かな
596:名無しさん＠編集中
18/04/22 00:30:07.28 dppkcbl/0.net
音痴なんだろ
597:名無しさん＠編集中
18/04/22 12:34:11.98 OUHz0R6x0.net
違いが分かる人と分からない人が
居るだけの話なのに
実際に目の前で見ないと信じられないのが人間
598:名無しさん＠編集中
18/04/22 15:46:11.93 MAIw05DH0.net
その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
ちゃんとマスタリングしてる物がほとんどだから20khz以上が切れてようがそうで無いものより綺麗っていうのはあるね
599:名無しさん＠編集中
18/04/22 18:57:13.36 17JCXUuud.net
URLﾘﾝｸ(encrypted-tbn3.gstatic.com)
600:名無しさん＠編集中
18/04/22 20:19:04.53 NF+KmVz0a.net
精神論は他板でやれ
601:名無しさん＠編集中
18/04/22 20:27:09.28 Itj5Wijm0.net
(´・ω・`)
602:名無しさん＠編集中
18/04/22 20:33:15.85 eWH2rYSA0.net
(´・ω・`)
603:名無しさん＠編集中
18/04/23 16:17:13.95 BRPMKJ720.net
自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
なにこれつべのVP9の4K十分綺麗じゃん
なんでこのVP9ってのはH.264やHx265以上に流行らないの？ 俺が事情を理解できてないだけだが理由がわからない
しかもつべの4K VP9ってビットレートたかだが12Mbps程度でこの画質なんでしょ？
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
604:名無しさん＠編集中
18/04/23 16:36:36.95 sukaORLRM.net
ググレカス
605:名無しさん＠編集中
18/04/23 17:45:49.03 2g6F1r+U0.net
>>573
x265@フルHDなら1～3Mbpsでそれなりに見れる画質になるんだから
4ｋで12Mbpsってのは少ないわけじゃない
606:名無しさん＠編集中
18/04/23 19:12:20.92 hFr3woIv0.net
h264とVP9を比べるなよ
607:名無しさん＠編集中
18/04/23 20:07:51.31 fgZBGlO6M.net
比べてん�
608:ﾌはH265とじゃねえの？
609:名無しさん＠編集中
18/04/23 20:20:41.65 sDC0ee320.net
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
610:名無しさん＠編集中
18/04/23 21:52:47.76 z48p7vFc0.net
YouTube推奨ビットレート
URLﾘﾝｸ(vook.vc)
611:名無しさん＠編集中
18/04/23 22:33:19.70 xaUnJI540.net
>>573
やってみれば分かる。264や265に比べて死ぬ程遅い
特にx265と比較するとビットレート比画質負けるのは勿論デフォ設定同士の比較で1桁以上、下手すれば2桁が見えてくるぐらい遅い
612:名無しさん＠編集中
18/04/23 23:00:31.33 qgLqyElT0.net
,．-─ ─-､─-､
, イ)ィ -─ ─- ､ﾐヽ
ノ ／,．-‐'"´ ｀ヾj ii / Λ
,ｲ／／ ^ヽj(二ﾌ'"´￣｀ヾ､ﾉｲ{
ノ/,／ミ三ﾆｦ´ ﾞ､ﾉi!
{V /ミ三二,ｲ , -─ Yｿ
ﾚ'/三二彡ｲ .:ィこﾗ ;:こﾗ j{
V;;;::. ;ｦヾ!V ｰ '′ i ｰ ' ｿ
Vﾆﾐ( 入 ､ r j ,′
ヾﾐ､｀ゝ ｀ ｰ--‐'ゞﾆ<‐-イ
ヽ ヽ -''ﾆﾆ‐ / ググレカス [ gugurecus ]
| ｀､ ⌒ ,/ （西暦一世紀前半～没年不明）
| ＞ ---- r‐'´
ヽ＿ |
ヽ ＿ ＿ 」
613:名無しさん＠編集中
18/04/23 23:29:52.22 2kQ4iN3t0.net
>>580
なんか>>361のリンク先読むとVP9の方がHEVCより縮むと読み取れるんだけど…、
x265ならVP9より縮むって事なんかね？
＞AOMediaのメンバー企業であるBitmovinの検証によれば、同じ画質で比較したさい、AV1はVP9比で22～27%、HEVC比で30～43%ほどビットレートを削減できるという。
614:名無しさん＠編集中
18/04/24 00:12:35.33 e84XDnmq0.net
計算量がね
615:名無しさん＠編集中
18/04/24 01:36:38.43 4wh5n1kV0.net
>>579
つべあげるのに4k60pは60Mbpsあったほうがええのか。。
616:名無しさん＠編集中
18/04/24 02:57:28.71 Cv2UDVgJa.net
vp系はバッファ少なくても縮むからストリーミングに向いてて良いわ
mpeg系は再生できるようになるまでが長い
617:名無しさん＠編集中
18/04/24 21:19:53.63 TErN/BXE0.net
Advanced Media Framework (AMF) SDK Version 1.4.7
URLﾘﾝｸ(github.com)
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の間違いだな。
618:名無しさん＠編集中
18/04/25 07:58:12.15 Dw16c1DhM.net
要はbuildコードが4/12って事でしょ
チェックか何かでゴタついたんでしょ
619:名無しさん＠編集中
18/04/25 20:34:00.59 vBxpOWXf0.net
URLﾘﾝｸ(code.facebook.com)
gop単位で分割してエンコードしてるみたいなこと書いてるな
>>111のYouTubeと一緒か
620:名無しさん＠編集中
18/04/25 21:10:56.23 +uyVIJ620.net
Facebook video adds AV1 support | Engineering Blog | Facebook Code | Facebook
URLﾘﾝｸ(code.facebook.com)
去年11月下旬時点のlibaomをChrome Canaryに盛り込
621:んで FacebookビデオでAV1のお試しサポートをしてみたよって話。 ブラウザ側で正式バージョンの実装がされたら、そっちに切り替えていくとのこと。
622:名無しさん＠編集中
18/04/26 03:03:05.56 cCy6wkiya.net
今canaryに来たってことはstableに来るのは4ヶ月後くらいかな
firefoxもchromeと同時期くらいには実装されるだろうか
一番の問題はスマホの対応だけどね
623:名無しさん＠編集中
18/04/26 03:53:50.73 jGFgkYoTM.net
静止画はまだ出てこないのかな
624:名無しさん＠編集中
18/04/26 04:37:58.48 gpsPqjL70.net
>>591
まだ仕様決まってないけど開発中らしい
AV1 Still Image File Format (AVIF)
URLﾘﾝｸ(aomediacodec.github.io)
実際の画像での比較
URLﾘﾝｸ(people.xiph.org)
SSIM Yでの比較
URLﾘﾝｸ(i.imgur.com)
625:名無しさん＠編集中
18/04/26 04:42:11.54 gpsPqjL70.net
ただし、性能いいけど最適化されてない今だと画像一枚変換するのに60秒くらい平気でかかる
626:名無しさん＠編集中
18/04/26 06:03:36.45 jGFgkYoTM.net
ありがと、これで電子書籍の容量減ってくれると助かるなあ
雑誌DLしたら500Mとか食ってるからはやく普及してほしい
627:名無しさん＠編集中
18/04/26 07:01:58.96 gpsPqjL70.net
そういえばハードウェアのエンコードって動画の場合ではソフトウェアよりかなり画質が落ちるけど静止画の場合だとどうなんだろう
628:名無しさん＠編集中
18/04/26 09:09:52.33 WbUdhyf6M.net
>>592
ssim0.985辺りで見てみるとjpegに対してのwebmに近い比率でwebmに対してのAVIFは縮むんやね
BPGはエンコードは兎も角デコード重過ぎ&対応ソフト少な過ぎで使い物にならなかったけどwebmの倍までのデコード速度と同程度の普及にはなって欲しいなぁ
629:名無しさん＠編集中
18/04/26 21:50:44.86 9dHHlQgGM.net
Appleは最近画像フォーマットにHEVCベースのHEIFを使ってるけど、
AVIF完成したらAVIFに移行するんかな。
もしそうなったらスマホ用サイトの画像フォーマットにAVIF普及しそう。
>>595
動画ほどソフトとハードでの画質の差は出ないと思うよ。
一枚絵の画像だとソフトとハードの差が出やすいフレーム間予測による圧縮がないので。
630:名無しさん＠編集中
18/04/27 08:29:46.56 1O42is100.net
ソフトとハードでどのくらい違うか気になったので>>592のグラフにx264とh264_qsvを追加(項目名クリックで表示切り替え可能)
URLﾘﾝｸ(plot.ly)
まあ少し落ちるけどこれくらいなら許容範囲かな
631:名無しさん＠編集中
18/04/27 14:06:31.54 9FN5TERTM.net
Next-Generation Image Compression (JPEG XL) Final Call for Proposals
URLﾘﾝｸ(jpeg.org)
これAV1じゃないの
632:名無しさん＠編集中
18/04/27 14:19:08.92 9FN5TERTM.net
JPEG-XL >60% over JPEG-1
MPEG-H(HEVC) >60% over MPEG-1
WebP2(≒AVIF) >15% over HEIC
633:名無しさん＠編集中
18/04/27 14:43:01.24 9FN5TERTM.net
姉妹規格のJPEG XSは来年完成らしい
ビジュアルロスレスというとDisplayPortのDSCコーデックみたいなやつだな
オープンフォーマットJPEG XS、画像符号化史上初のパラダイムシフト
URLﾘﾝｸ(this.kiji.is)
JPEG XS標準化プロセスの開始は、2016年のJPEG 71回目の会合にて承認された。JPEG XSは、超低遅延、電力、帯域幅の要件だけでなく、実装が簡単な
634:アルゴリズム、少ないメモリでも動作し、そして長いケーブルランをサポートすることを目的にしている。 コアコーディングシステムは2018年7月に完成予定で、リファレンスソフトウェアを含んだ全体の完成は、来年2019年4月に予定されている。
635:名無しさん＠編集中
18/04/27 15:00:41.15 9FN5TERTM.net
JPEG XSコーデックメモ
URLﾘﾝｸ(qiita.com)
JPEG XSコーデックは、低計算量・低レイテンシが要求されるアプリケーションにおいて、主に「Mezzanine(舞台下の)コーデック」としての利用が期待されている。
ライブ・プロダクション
放送・デジタルシネマ ワークフロー
プロ向け映像市場
KVM1アプリケーション
VRゲーム など
JPEG XSは、従来の(無印)JPEG, JPEG2000, JPEG XR, WebP, HEIFといった大量データ保存・WEB配信向けコーデックを 置き換える技術ではない。
636:名無しさん＠編集中
18/04/27 17:19:20.66 bi0qElbcM.net
HDMI2.1もVESAが規格化したDSCを採用するみたいだな。もうDPと統一しろよ
URLﾘﾝｸ(av.watch.impress.co.jp)
DSC(Display Stream Compression)はDPCM(Delta Pulse Code Modulation)とICH(Indexed Color History)をベースにしたリアルタイム性に優れた圧縮技術で、設定した圧縮率で安定した圧縮結果が得られる特徴を持つ。
ただし、圧縮したデータは元のデータには戻らない、いわゆるロッシーな(ある程度の劣化を許容した上で活用する)映像信号圧縮技術になる。
MPEG系のような、過去から現在の映像フレーム同士の相関関係を利用した圧縮技術は、元のデータに対して数百分の1にまで圧縮が可能だが、DSCは時間方向に伝送されててくる一次元データストリームの圧縮なのでたかだか数分の1程度の圧縮率に留まる。
その代わり、低遅延で高速リアルタイムに圧縮展開できる利点がある。
ちなみに、このDSCロジックのIPコアを開発したのは半導体IPメーカーのHardentだ。
637:名無しさん＠編集中
18/04/27 17:47:07.69 gEcmA/z6a.net
jpegの牙城はH.264より堅いだろうから新画像コーデックを広めるのは厳しいだろうな…
MSとAppleとGoogleが足並み揃えてゴリ押ししたらいけるかも？って感じ
638:名無しさん＠編集中
18/04/27 19:05:47.95 EWvTPi2GM.net
ありゃJPEG XLの技術公募締切が9月に延期されてる
公開目標時期は2019年10月か
AV1採用してくれ
639:名無しさん＠編集中
18/04/27 19:18:04.15 diV9ARYpM.net
>>604
そのメンバー全員Alliance for Open Mediaに加盟してるし、MozillaやFacebookやNetflixもいる。
Appleしか推してないHEIFやGoogleしか推してないWebP、Microsoftしか推してないJPEG-XR
とはかなり状況違うから今度は期待できそう。
640:名無しさん＠編集中
18/04/27 23:11:06.12 +UMyqfuU0.net
VP9は画質で判断するとたまにH264よりサイズでかくなるから困る。圧縮するなら相応の力を見せてくれないと
中途半端だ
641:名無しさん＠編集中
18/04/28 04:17:32.25 vQv5IYZY0.net
>>603
HDMIがロッシーになるのか
マウスカーソルの周りにブロックノイズとか出たら嫌だな
642:名無しさん＠編集中
18/04/28 04:45:52.04 iRXtwpm2a.net
8Kくらいまで解像度を上げない限りは非可逆にはならないと思うぞ
643:名無しさん＠編集中
18/04/28 10:49:22.34 rp64
644:VJ9F0.net
645:名無しさん＠編集中
18/04/28 10:51:51.61 rp64VJ9F0.net
>>606
基本的にアプリケーションの内部処理やサービスとセットで消費者側はデコード主体使う事になるだろうから、個人で生成する事は余り考えなくて良いと思う
646:名無しさん＠編集中
18/04/28 22:36:34.23 tYs2/UtdM.net
たしかtwitterはgifをアップロードするとmp4(h.264)に変換される仕様だったような
google photoもwebpに変換されてるんだっけ？
全モダンブラウザが対応するweb標準の次世代画像規格さえできたら
あらゆるサイトでjpeg/png/gifが変換されるようになるはず
運営側もユーザー側もトラフィック削減パケット節約でwin-win
647:名無しさん＠編集中
18/04/29 13:51:15.35 o99M7JsiMNIKU.net
AV1が一般人にストレスなく利用できるようになるのは、いつ頃だろうか？
音声の圧縮音声コーデックは、今後MPEG4-ALS（品質重視の用途）かOpus（可聴帯域のみを扱う一般的な用途とリアルタイム通話向き）に収束していくのだろうけど
ところで、音声コーデックの話をするスレ、どこかあるのかな？
648:名無しさん＠編集中
18/04/29 13:57:23.74 hhx87O280NIKU.net
ストレスなく利用っていうのが視聴の事なら1、2年で可能だろうけどエンコードの事なら一生来なさそう
649:名無しさん＠編集中
18/04/29 16:31:01.59 o99M7JsiMNIKU.net
>>614
アカンがな、それ…
となると、やはり映像はHEVCベースで運用しておくか
音声はフリーのくせにと言ったらおこられそうだが、日常使いではOpusでいいかなと最近は思っている
新しくYouTubeにアップされてる高解像度のものは、元からOpusでエンコードされているから聴き取りやすくていいし
音声メインの素材をアップする人は、積極的に高解像度（フレームレートは1fpsとかにできるのならば、それでいい）でアップしてもらいたい
650:名無しさん＠編集中
18/04/29 16:44:59.29 rFAS4HxrMNIKU.net
>>612
AVIFはアルファチャンネルやアニメーションにも対応するそうだし、
AVIFに使用されてるAV1は可逆圧縮にも対応してるから、
うまく行けばjpg/png/gif全部置き換えられそう。
651:名無しさん＠編集中
18/04/29 18:01:51.92 E3c9gHljMNIKU.net
>>613
ここかな
【Opus/Vorbis/FLAC】Ogg統合20【AV1/Theora】
ｽﾚﾘﾝｸ(software板)
652:名無しさん＠編集中
18/04/29 19:45:07.16 o99M7JsiMNIKU.net
>>617
ソフトウェア板にあったのか
DTM板かと思ってたよ
Thx.
653:名無しさん＠編集中
18/04/29 21:14:36.62 TSyBLkXS0NIKU.net
>>615
Opus気になって調べてみた
で、YouTubeに4K動画でMISIAの音源にいいのがあったので試してみた
確かにいい
ただし、手元のPCで再生するよりスマホのXperiaで再生したほうが高音質だった（泣
PCの音声環境見直すか・・・
654:名無しさん＠編集中
18/04/29 21:32:14.56 mEIjwYB6aNIKU.net
>>619
それわかるw
Opusをもっと試したかったらサカナクションの「多分、風」という曲もOpusの入ってるファイルで聴くといいと思う
655:名無しさん＠編集中
18/04/29 22:04:22.84 1hLNpWuo0NIKU.net
>>616
可逆圧縮をなめてはいけない。
可逆画像圧縮のアルゴリズムをを不可逆画像圧縮から流用するアプローチが
いくつかあるけど、普通にPNGより性能悪い。
WebPは可逆不可逆両対応だけど、それぞれ別のアルゴリズムを使ってる
656:。 可逆か不可逆かぱっと見で区別できないのも困るし、今までどおり別の型式のがいいと思う。 可逆画像圧縮はzstdのアルゴリズムベースのが出てきてくれたら嬉しいけどなぁ。
657:名無しさん＠編集中
18/04/29 23:37:02.55 RFC43lfy0NIKU.net
お前ら可逆不可逆って続けて何回言える？
俺は1回すら怪しいんだけど
658:名無しさん＠編集中
18/04/29 23:39:32.57 xjjdisQZ0NIKU.net
最初の3文字までは読めた
659:名無しさん＠編集中
18/04/30 00:03:24.95 8vT42dcVM.net
>>619
YouTube動画の音声サンプリング周波数は
AACが41.1kHzでOpusは48kHzだったような
だから例えばiPhoneシリーズなら6s以降スピーカーが48kHzしか対応していないらしいからAACだと多少音質変化するかも
逆に44.1kHzのみ対応のイヤホンとかもあったり
なんか深淵を覗いた心地に
660:名無しさん＠編集中
18/04/30 00:09:31.52 8vT42dcVM.net
>>621
そういやFLIFとかいうFLACの親戚みたいな名前の可逆圧縮画像規格あったけど最近は音沙汰無しだな
いつかリリースされる日は来るのだろうか
661:名無しさん＠編集中
18/04/30 00:34:28.89 8vT42dcVM.net
最近は写真や動画を撮ったらすぐにクラウドストレージに投げることが増えてきたから
元ファイルを(ビジュアル)ロスレス圧縮してアップロードした後、クラウド上で再エンコードする時代になったりしないかな
ロスレスHEVCかロスレスAV1かVESAのDSCかどれでもいいけど
662:名無しさん＠編集中
18/04/30 00:51:03.48 8vT42dcVM.net
FLACをアップロードできてOpusがストリーミング配信されているSoundCloudはすごいな
無料だし
663:名無しさん＠編集中
18/04/30 01:56:05.01 g5bwX14t0.net
>>627
SoundCloud、これいいね！
スマホにアプリ入れてGoogleのアカウントでサインインしてみたけど、操作が少し独特だけどいいよこれ
日本人の曲もあるし、音も素材が良ければいい感じだね
これはいいの教えてもらったよ
ありがとう！
664:名無しさん＠編集中
18/04/30 15:02:47.73 K2+Kaxf4M.net
PNGのほうがwebp可逆より縮む？
665:名無しさん＠編集中
18/04/30 23:11:45.40 1+hf/BtW0.net
>>629
WebP可逆は不可逆とは別のアルゴリズムだから殆どの画像でPNGより縮む
BPGの可逆圧縮を調べてみたけどやっぱり微妙だった
PNGが苦手な画像だとPNGより縮んだり縮まなかったり
PNGが得意な画像だとPNGに引き離される
AV1の可逆圧縮も似たようなもんになる気がする。
666:名無しさん＠編集中
18/05/01 02:14:16.26 HX1oXWc70.net
PNGは最適化を掛けるとかなり縮むけど、
マルチスレッドすら対応してない古いプログラムばかりで遅いのがな
その辺をちゃんと最適化してくれればPNGで十分そうな気がする
667:名無しさん＠編集中
18/05/01 02:25:48.52 vXYkO7J+0.net
とりあえずWindows 10の最新アップデートを適用すると、HEIFの表示のみOS標準で対応だとさ
※保存はダメ
668:名無しさん＠編集中
18/05/01 05:30:37.42 os57il8aa.net
結局OSの対応よりブラウザの対応のほうが大切なんだよね
669:名無しさん＠編集中
18/05/01 05:31:42.05 8wdpRSsu0.net
>>630
BPGの可逆圧縮はエンコーダーにx265を使うと縮まないけどjctvcなら結構縮む
jctvcは0.9.6以降は搭載されてないから試すなら0.9.5を使ってね
670:名無しさん＠編集中
18/05/01 12:32:13.70 8wdpRSsu0.net
AV1の可逆圧縮、相当無理矢理だけどこんな感じで出来た
ffmpeg -y -i "%~1" -
671: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"
672:名無しさん＠編集中
18/05/01 13:29:55.47 56CftVddM.net
>>635
AV1可逆の圧縮性能はPNGに比べてどうだった？
673:630
18/05/01 23:33:58.50 47AIvuLn0.net
>>634
jctvcを使ったら可逆ですげー縮んだ。勉強不足すぎてた。
これだと大方の画像ではPNGより小さくなりそう。
ただ、PNGが得意な画像で、差は縮まれど追いつけないままな物もまだあるから
PNGを全部置き換えるにはまだ不足してるって感想はそのままかな。
（一番手ごろなものだと、wikipediaのページのスクショ画像がそうなった）
674:名無しさん＠編集中
18/05/02 05:56:13.66 D0yOygKta.net
deflateという圧縮技術のデファクトスタンダードを使っているpngが置き換わることはそうそう無いと思うけどね
675:名無しさん＠編集中
18/05/02 06:31:48.11 cWA+EDYk0.net
>>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も上げておくので設定とか検証が適切に行われたかが気になる人は見て
URLﾘﾝｸ(www.dropbox.com)
676:名無しさん＠編集中
18/05/02 07:05:18.55 Ssad5kFU0.net
webp優秀やな
677:名無しさん＠編集中
18/05/02 08:22:59.93 /Hb8IfCSM.net
>>639
ありがとー
AV1縮んでないね、可逆だとwebpに劣るなんて
得意な？非可逆だとどうなるんだろ
678:名無しさん＠編集中
18/05/02 17:47:43.70 uSkAIMzQ0.net
>>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
URLﾘﾝｸ(news.itu.int)
MPEG 122 - San Diego | MPEG
URLﾘﾝｸ(mpeg.chiariglione.org)
MPEG 122 Meeting Report - Bitmovin
URLﾘﾝｸ(bitmovin.com)
679:名無しさん＠編集中
18/05/02 18:20:31.86 /KuL0s/FM.net
40％！
素晴らしい！素晴らしいですよ！
680:名無しさん＠編集中
18/05/02 20:01:38.55 q+VeS0Up0.net
>>639
AV1本当何やってもトロくて駄目なやつだな…
ここまで糞だと改善の見込みも無さそう <
681:br> AV1を今より遥かに速く改善できるなら他のコーデックなら更に改善できるだろ
682:名無しさん＠編集中
18/05/02 20:06:23.69 j0vNwcLd0.net
それが出来ないからVVC等の新しいコーデックが開発されてるんだろ
683:名無しさん＠編集中
18/05/02 20:18:05.23 EaTyxjPAM.net
Googleが画像フォーマット「WebP」向けライブラリ「libwebp 1.0.0」をリリース
URLﾘﾝｸ(mag.osdn.jp)
WebPはWeb向けの画像フォーマットで、ロスレスおよび不可逆圧縮の両方に対応する。
拡張子は「.webp」。不可逆圧縮では、VP8動画コーデックが動画のキーフレームを圧縮するのと同じ手法で、プレディクティブ（予測）コーディングを使って画像をエンコードする。
ロスレス圧縮ではPNGと比較して26％小さく、不可逆圧縮ではJPEGより25～34％小さいとしている。
WebPファイルはVP8とVP8L画像データ、RIFFベースのコンテナで構成される。
libwebpではWebP仕様のリファレンス実装で軽量のエンコード/デコードライブラリに加え、WebPフォーマットへの変換などを行えるコマンドラインツールcwebp/dwebp、WebPイメージの閲覧やmux、アニメーション作成のためのツールを備える。
本バージョンはこれまでのバージョンとバイナリ互換があるとのことで、フォーマットとAPIが安定していることから1.0として公開したという。不可逆圧縮などが強化されツールもアップデートされている。
684:名無しさん＠編集中
18/05/02 20:18:41.81 EaTyxjPAM.net
>>646
WebP
URLﾘﾝｸ(developers.google.com)
libwebp
URLﾘﾝｸ(github.com)
685:名無しさん＠編集中
18/05/02 21:34:36.25 Ssad5kFU0.net
webpはデコード早いから良い
686:名無しさん＠編集中
18/05/02 21:37:53.46 8dHE9Ib0M.net
これでwebpがもっと普及するといいなあ
687:名無しさん＠編集中
18/05/02 22:00:46.77 TPiWhDTo0.net
なおFirefox
688:名無しさん＠編集中
18/05/02 23:40:55.87 /Hb8IfCSM.net
>>650
ブラウザ識別して火狐には重いデータを送ってやろう
689:名無しさん＠編集中
18/05/03 00:20:58.06 ag9sCIyxM.net
ChromeがAPNG対応したんだから
FirefoxはWebP対応するのが🍣
690:名無しさん＠編集中
18/05/03 02:42:42.99 qLoEKbqla.net
firefoxはwebp対応してるだろ
safariと勘違いしてるのか？
691:名無しさん＠編集中
18/05/03 10:10:30.36 uRMPloV+M.net
>>653
URLﾘﾝｸ(caniuse.com)
😿
692:名無しさん＠編集中
18/05/04 06:39:59.54 lkzBO84x0.net
4K放送は265HEVC？
693:名無しさん＠編集中
18/05/07 10:46:58.51 lWAiBYbLM.net
>>655
新4K8K衛星放送開始に向けた取り組み - 総務省（PDF）
URLﾘﾝｸ(www.soumu.go.jp)
URLﾘﾝｸ(i.imgur.com)
新4K8KはH.265だね
H.265が特許料で揉めてるって最近知ったからあまり詳しくないんだけど
特許料の高さがBS契約料とかNHK受信料とかに（無駄に）上乗せされないといいんだがなぁ
かと言って機動力のない放送団体が状況に応じてコーデック入れ替えなんかできるとも思えないし
694:名無しさん＠編集中
18/05/07 12:20:32.32 QSFqJxGb0.net
何を今更…
695:名無しさん＠編集中
18/05/07 12:25:34.52 mN4HSZiPM.net
>>656
対応profileのオプションにもよるけど、TV1台当たりライセンス料300円しないぞ
696:名無しさん＠編集中
18/05/07 13:26:33.16 mN4HSZiPM.net
今年の2月に特許切れたMPEG2にもライセンス料掛かってたしな
録画の圧縮機能やMPEG4/AVCの再生機能持ってる機器なら、未だにMPEG4/AVCのライセンス料も掛かってるし
今まで金銭的にそれらの上乗せを負担と意識して無かった奴が、今更HEVCのライセンス料で騒いでるのも可笑しいんだけどね
実効でその程度のものだったり
697:名無しさん＠編集中
18/05/07 13:38:03.21 mN4HSZiPM.net
映像コンテンツなら殆ど2円未満、高くても3円にもならないとかだし、
パッケージの流通コストや小売り・事業者の粗利の方が遙かに影響デカくて、個人単位で年間ナンボよって感じなのよね
そんな額気にするなら、家電品の消費電力気にしていた方がマシだったりな
自販機で飲料買ったり、コンビニで買い物する方が遙かに無駄という
698:名無しさん＠編集中
18/05/07 16:43:37.96 2gi9rWInM.net
「GIMP 2.10」リリース
URLﾘﾝｸ(mag.osdn.jp)
WebPサポート
699:名無しさん＠編集中
18/05/07 18:11:36.96 jxsmP9bbM.net
寧ろ今まで対応してなかったのか
700:名無しさん＠編集中
18/05/07 18:16:47.63 CavlMB6C0.net
GIMPは亀の歩みだし……
対応してくれただけでも喜ぶべき
701:名無しさん＠編集中
18/05/07 20:38:05.43 ZtP2jiNr0.net
昔はPhotoshopの代わりにGIMPでも頑張れば行けるかもって時期があったけど、
今は完全に突き放されて背中すら見えなくなってしまったなあ
702:名無しさん＠編集中
18/05/07 21:56:46.76 CavlMB6C0.net
今のフォトショってそんなにすごいんか（時代遅れ）
703:名無しさん＠編集中
18/05/08 00:22:38.74 ZanT8rbB0.net
GIMPはリリース間隔が空きすぎて開発者のほとんどがKritaとかDarktableに行っちゃったから…
704:名無しさん＠編集中
18/05/08 00:35:32.05 7ccNxeIra.net
GIMPの前回のリリースって5年以上前だろう
webpその頃あったのかな
705:名無しさん＠編集中
18/05/08 16:29:53.58 vgWy5NipM.net
Kritaは3年前からWebPサポートしてたのか
URLﾘﾝｸ(krita.org)
706:名無しさん＠編集中
18/05/10 21:28:35.09 YxvK1ObZH.net
androidのゲームでwebp義務化すればかなり通信料減らせそう
707:名無しさん＠編集中
18/05/11 07:42:07.81 HL2toN7BM.net
結局webpが流行ることは無かったな
コーデックもVP8のままだし
708:名無しさん＠編集中
18/05/11 10:06:37.10 G39yR8Av0.net
よくわからんけどAndroidのゲームはETC1かETC2が主流じゃないの？
多分DXT同様固定の容量圧縮比の方がメモリ消費量の把握しやすいだろうし
709:名無しさん＠編集中
18/05/11 22:50:53.49 XObC1OA70.net
>>670
JPEGから移行するにはショボすぎた
HEIFでやっとって感じ
710:名無しさん＠編集中
18/05/12 01:19:03.53 k0/RMl7s0.net
流石にJPEGも古い規格よなぁ
圧縮率の高い次世代フォーマットでどれだけのストレージやリソースが削減できるか
実際は皆足並みが揃わない訳だけども
ストレージの進化が完全に頭打ち！大変だ！みたいなピンチにでもならなきゃ業界は腰を上げないよな
711:名無しさん＠編集中
18/05/12 01:46:18.60 +wN2NfcxM.net
ストレージは大した問題ではないだろう
問題なのは通信量よ
712:名無しさん＠編集中
18/05/12 01:50:00.39 W5jsDxqa0.net
その他にも処理速度とかそれをハードウェア処理するチップのコストだとかいろいろあるんだろうけど
ぶっちゃけいえばブラウザやOSが標準でサポートするか否かが一番でかいと思う
ってJPEG2000さんが草葉の陰でいってた
713:名無しさん＠編集中
18/05/12 03:02:41.15 /JzDRiyH0.net
近いうちにJPEG2000が主流になるからデジカメの買い替えをちょっと待とう…
とか思っていた遠い日の記憶が蘇ったw
714:名無しさん＠編集中
18/05/12 03:56:43.62 ltRK6gJw0.net
もうJPEGくらいに浸透してると
AppleみたいにHEIFをデフォルトで初心者に気づかせないうちに使わせて
広めるみたいなことしないと無理だろう
715:名無しさん＠編集中
716:sage
amazonとかの電子書籍を全てwebpにすれば普及する
717:名無しさん＠編集中
18/05/12 17:10:26.58 FWhsUTQe0.net
AV1ってまだ正式に仕様決まってないの？
doom9見てたらそういう感じの話してるような気がするけど機械翻訳で読んでるからよく分からない
URLﾘﾝｸ(forum.doom9.org)
718:名無しさん＠編集中
18/05/12 18:47:05.20 ERkX91bQ0.net
>>679
まだみたいだね。
URLﾘﾝｸ(github.com)
で作ってる仕様ドキュメントから“draft”が無くなった時が仕様確定かな。
参考： Jan Ozer氏が4月中旬にAOMediaの人から聞いた話
URLﾘﾝｸ(www.streamingmedia.com)
雑訳：
AOMでは「code first」というアプローチでAV1の開発を行っている。
リファレンス実装のコードの開発と、それによってもたらされるビットストリーム仕様の策定・作成は並行して行われている。
これらが終わって初めてAV1の仕様が確定したと言える。
仕様書は現在は「draft」とされており、リファレンス実装のビットストリームが正確に反映されるよう、
自動/手動でレビューを実施しているところであり、その作業には更に数週間かかるものと思われる。
それが終わった時点で「draft」のウォーターマークを外し、AV1の仕様が確定する。
719:名無しさん＠編集中
18/05/12 18:50:45.44 ERkX91bQ0.net
>>680のリンクはこうすべきだったかな。
URLﾘﾝｸ(www.streamingmedia.com)
720:名無しさん＠編集中
18/05/12 18:54:47.06 ltRK6gJw0.net
>>678
それだけじゃ絶対普及しない
リーダーはAmazonとかの電子書籍配布元が配布するとして
画像生成する機器やアプリケーションが標準でほぼ全対応しなきゃ
出版する側の人間がwebpへの変換ツールを使うだけに終わる
カメラなどのハードウェアが直接次世代フォーマットで
画像生成するようになって初めて普及する可能性が出てくる
その点、デフォルトでiPhoneでHEIFを吐き出させ始めたAppleが
一歩リードしてる
721:名無しさん＠編集中
18/05/12 19:36:39.91 FWhsUTQe0.net
>>680
サンクス
どうりでChromeがなかなか対応しないわけだ
722:名無しさん＠編集中
18/05/13 05:46:57.59 QMoN91bYa.net
chromeもfirefoxもAV1の一時的なな実装は完了しているから仕様確定したらすぐにでも導入できるはず
まあ安定版に降りてくるには半年近くかかるのだろうけど
723:名無しさん＠編集中
18/05/13 12:00:27.25 WgGYbyGwM.net
Kindleの中のデータってjpegなの？
724:名無しさん＠編集中
18/05/13 12:05:53.14 aA9jcx6MM.net
つべのVP9と264
容量が逆転してるのが多いな…
細かい動きが多いとダメなんかな？
725:名無しさん＠編集中
18/05/13 22:06:31.89 7jvfurv50.net
VP9はHEVCとAVCの中間あたりに位置すると個人的には考えてるから、得手不得手で旨味なくなりがちだよね
726:名無しさん＠編集中
18/05/13 22:53:00.53 d407Oae50.net
HEVCの技術とAV1の技術を全て結集したらさいきょうのコーデックが出来上がりそう（厨二的発想）
まぁ大人の事情でまず有り得ないけど
727:名無しさん＠編集中
18/05/14 02:57:59.84 n2LNOfSM0.net
>>688
大人の事情とか言ってる時点で…
ただエンコーダ・デコーダが優秀になればいいだけの話。特性云々はここで語る必要ないと思うが
728:名無しさん＠編集中
18/05/14 06:09:48.86 OgrikrUWa.net
VP系はMPEG系と比べて先読み�
729:Zくても圧縮率保てるからストリーミングにはVP9のほうがいいよ
730:名無しさん＠編集中
18/05/14 10:19:40.88 B2eqMGvp0.net
なら自炊用途では利点薄いな
731:名無しさん＠編集中
18/05/14 11:01:26.25 3yN5QwlIM.net
自炊用途は、長期的に安定して再生できる可能性の高いフォーマットを選ばないとあとで後悔するだけ
ただ、一つ気がかりなことがあるとすれば、動画ファイルに使える音声フォーマットの進展が遅れ気味なことか
特にOpusのようなVBRタイプのフォーマットを動画とMUXしたいとかなると、とたんに使えるツールが見当たらなくなる現状は如何ともし難い
動画と音声を自由自在にMUXできる自由度の高いツールがほしい
732:名無しさん＠編集中
18/05/14 13:30:49.72 wniTZ/UkM.net
ffmpegでできないんか？
733:名無しさん＠編集中
18/05/14 15:57:08.62 B2eqMGvp0.net
mkvコンテナ扱える奴なら仮対応的な実装じゃ無ければイケるんじゃないの？
734:名無しさん＠編集中
18/05/14 17:52:19.59 hi9NhhfiM.net
電子書籍とかの複数ファイル画像って
動画にしてフレーム間圧縮で容量減らせそうだけど
やってるとこないのかな
735:名無しさん＠編集中
18/05/14 18:53:07.42 dB9siKnnM.net
>>695
フレーム間の違い大きすぎて圧縮のための予測がうまく出来なさそう
736:名無しさん＠編集中
18/05/14 21:05:59.77 u8Q90uS+H.net
>>696
文字とかで余白の多いすかすかの雑誌系は
ページ間で連続した空白多いから容量減りそうだけどどうだろ
737:名無しさん＠編集中
18/05/15 10:48:03.02 L0wI7lRZM.net
そもそも空白が多い画像はjpgなりpngなりでも大きくないと思う。
1フレームごとに文字が離散しているので毎フレームIフレームにするのと画質対容量のメリットがあまりない。
kindleなどの端末で処理するにはフレーム間予測などの処理はハードウェアデコーダ積んだりキャッシュしていくにしろ重いだろうし流行らないと思う。
そういうので1番効果があるのはエロゲとかdlsiteにあるような差分データ盛り盛りのCG集などに限定されると思う。
738:名無しさん＠編集中
18/05/15 12:00:09.11 v78X55j30.net
そこは昔のゲームみたいに口や目の変化部分だけ画像作って
差し替える方式でいい気がする。マップチップ的な
まぁ今のもの見ると画像1枚1枚用意しているのが多いから容量増え気味だよね
739:名無しさん＠編集中
18/05/15 12:44:29.90 YP40ckAd0.net
スクリプトミスったら差分の目が背景の上に浮くじゃないですかー
740:名無しさん＠編集中
18/05/15 12:47:15.36 gru2+YPn0.net
VimeoがAOMediaのPromotor memberに。
Vimeo Joins the Alliance for Open Media
URLﾘﾝｸ(press.vimeo.com)
741:名無しさん＠編集中
18/05/15 17:37:21.94 l32k4eJ70.net
エロゲって画像形式何使ってるんだろ、やっぱり可逆PNGなのかな
742:名無しさん＠編集中
18/05/15 23:35:21.34 sO7921jZ0.net
吉里吉里ならエロゲ絵に特化したTLG型式ってのが使えるけど
実際に使われてるのかは知らない。
743:名無しさん＠編集中
18/05/16 13:04:48.09 ixE7+1Ga0.net
>>695
OCRしてテキスト化の圧縮率に到底勝てないからやる意味が無い
744:名無しさん＠編集中
18/05/16 16:20:14.44 RUCiJ5XHx.net
>>695
面白いアイディアだな、言い出しっぺの法則で作ってみてくれ
ただ全ページがキーフレームになってしまうとかあり得るんじゃね
745:名無しさん＠編集中
18/05/16 19:26:14.68 zSaLZ/zv0.net
電子書籍は突飛なアイデアではなくて自分も数年前に検討済み
電子書籍には3タイプあって、698の言う通りで、連続差分画像以外に
ましてやテキストオンリーの書籍に動画コーデックの出る幕は無い
・画像の�
746:ﾝ：コミック、写真集 ・テキスト+画像レイアウト：雑誌やムック、写真集、美術書など ・テキスト：小説など テキスト+画像レイアウトの場合、活躍するのは静止画フォーマットだけ。 残された画像のみの場合だが、すでにHEIFはイメージシーケンスが規格に組み込まれてるから 新たにやることは各電子書籍ベンダーがそれを利用するかどうかくらい。
747:名無しさん＠編集中
18/05/16 19:34:53.31 TRVkhnIz0.net
漫画なら図形の輪郭とかとかスクリーントーンとかそういうのを符号化すれば…
って思ったけどpostscriptだな
748:名無しさん＠編集中
18/05/17 18:58:01.00 aOY/Sh7+0.net
もう、基本の圧縮技術は画像にしろ動画にしろ、JPEGの時代に確立されちゃってるのか・・？？
それからあんま本質は変わってないのかね
749:名無しさん＠編集中
18/05/17 20:45:26.23 dtRc1mgp0.net
500年後の未来から来たけど、今の圧縮技術はその概念自体が使われなくなるよ
究極のイメージ処理は、全データをベクター処理すること
ラスターイメージ処理は電子機器の能力が低い現代における
低レベルなお粗末な石器時代並みの技術だよ
量子コンピューターにより画像自動解析処理が高度に発達した未来では
2Dの平面データで記録再生するのは骨董品技術になる
わかりやすく現在の製品名で例えれば
Illustrator>>>超えられない距離>>>Photoshop
未来のカメラは撮像したデータを自動解析して、
3Dオブジェクト+テクスチャ判定+光源計算したデータとして保管
テクスチャも撮像データから得た2Dラスターデータではなく
全世界で共用管理している超大規模データセンターの膨大なデータから
何番目のテクスチャ、というID指定を記録するだけなので、データ量は軽い
再生時に3Dグラフィックでリアルタイムレンダリング処理を行う
圧縮という概念自体がなくなる
ただし、メロンパンは500年後の未来でもなくなっていません。あれは美味しいデス
750:名無しさん＠編集中
18/05/17 22:15:23.81 Yn+eJUWU0.net
電子書籍に関してはePubの規格がバージョンアップしてリフローとフィクスのハイブリッド型も作れるようになってるね
現状では雑誌の電子書籍版のインタビュー記事とかがテキストも含めて全部画像だったりするけど
今後は必要に応じてテキスト部分はテキストデータのページに置き換えるような措置をした方がファイルサイズを抑えるのとコンテンツの読みやすさを両立できて良いと思う
751:名無しさん＠編集中
18/05/17 23:18:42.89 nu+LsDAr0.net
>>708
JPEG 2000ではウェーブレット変換が使われていたけど、結局それ以降は使われていないよね
コサイン変換に比べて、あまり筋のいい技術ではなかったということなのかなぁ
752:名無しさん＠編集中
18/05/17 23:25:51.55 qghkMzkD0.net
某ネコさん曰く、16k以上の画素数だとwaveletが日の目を見るかもしれないらしい
753:名無しさん＠編集中
18/05/18 09:59:24.63 ZPtxF8MK0.net
JPEG XSもwaveletだそうだけど、どんな感じの圧縮なんだろう。
754:名無しさん＠編集中
18/05/18 10:37:15.45 /renKBLaa.net
>>713
おねえさんのお尻でぎゅーって押し潰される感じ♥
755:名無しさん＠編集中
18/05/18 12:55:58.26 +GbTMFNU0.net
>>711
ビデオ規格だと、SnowやDiracもウェーブレット変換
756:名無しさん＠編集中
18/05/18 12:59:08.56 +GbTMFNU0.net
DCTと違ってブロックノイズが発生しないのがDWTの利点だけど、
ブロック単位で
757:する動き補償と相性が悪いので動画には不向き
758:名無しさん＠編集中
18/05/18 21:33:10.21 K0HNwhcn0.net
waveletで圧縮しまくったらどうなるんだろ
ぼやけるだけ？
759:名無しさん＠編集中
18/05/19 03:30:25.97 KyqEPYZE0.net
特性的にエッジ部分の情報量から削られていくから、そういう部分の階調表現の幅が狭まる（コントラスト低下）と解像度感が失われて眠い画になっていくと思う（俗に言う眠い絵作り
特性がある圧縮だから万能じゃ無いかと
あくまでwaveletを手段として使っていているだけで、これ自体が圧縮方式では無い事にも注意（使い方や実装で性能が変わる
画像データの周波数的な情報の分離に向いていて、分離したデータの内で画像の全体像を把握するには重要じゃ無い部分を削る事で「圧縮にも使えなくは無い」ってだけで、内容的にはMP3的な（実装によって差が出やすい）プライオリティの低い情報を削る感じ
文字や図表、線画のエッジ部分が多い画像の圧縮には向かないと思う
760:名無しさん＠編集中
18/05/19 11:48:56.33 g5W8fTyCa.net
画像データの周波数的情報って何？
761:名無しさん＠編集中
18/05/19 12:49:01.68 RKBOVkud0.net
「画像 周波数」でググればよいかと。
762:名無しさん＠編集中
18/05/21 01:31:50.61 1YvuKtaD0.net
>>619
MISIAの4Kというと、「名前のない空を見上げて」のことかと思うけど、これ確かにスマホで聴いたほうが音いいからおかしいなと思って調べた
すると、確かに4Kでアップされてはいるのだけれど、1080pと1440pをmp4ファイルとWebMファイルで比較すると、mp4ファイルのほうがファイルサイズが大きくなっていた
通常、画質と音質がともにいい場合は、4Kより下の解像度でもファイルサイズは
WebM＞mp4もしくはWebM≒mp4
のいずれかであるのだが、この曲は逆転していた
だからダウンロードするのであれば、この曲に関してはmp4ファイルのほうがいい
ただし、ここからがよくわからないのだが、PCにてChrome上で再生した場合、再生中に詳細情報を確認するとWebMにも関わらず音は悪くない
ここがわからないんだよなぁ
YouTubeは謎が多い
763:名無しさん＠編集中
18/05/21 09:49:00.46 ox2mzMHN0.net
今の動画サイトは、映像と音声は別々に保存してて、
視聴者がページ開いたときにくっつけて配信してるんじゃなかったっけ。
764:名無しさん＠編集中
18/05/21 12:37:02.14 ohVff/0r0.net
よくわからないのに書くからこういうことになるんだね
765:名無しさん＠編集中
18/05/21 13:32:07.83 1YvuKtaD0.net
ならば君が書けばいい
766:名無しさん＠編集中
18/05/21 15:12:56.00 ohVff/0r0.net
なぜ私がｗ
767:名無しさん＠編集中
18/05/21 15:19:31.47 llvcQqWjd.net
>>722
YouTubeはそうだったはすだよ
768:名無しさん＠編集中
18/05/21 15:19:45.16 llvcQqWjd.net
>>726
恥ず
769:名無しさん＠編集中
18/05/21 17:54:03.14 pXVYVIdD0.net
マジレスするとYoutubeの場合、 URLﾘﾝｸ(pastebin.com) のように、
Ａ．音声のみのファイル
Ｂ．映像のみのファイル
Ｃ．映像＋音声のファイル
が複数あって、基本的にはＡとＢを組み合わせて配信される。
プレーヤー右クリック→詳細統計情報→Codecsで組み合わせが見れる。
Win10のPCのChrome/FirefoxはVP9+Opusだが、IEはAVC+AACだし、EdgeはAVC+Opusになることもある。
Opusは基本的に251番(160kbps)が使われるが、映像が144pの場合は250番(70kbps)が使われる。
スマホも、機種やブラウザ等によって組み合わせは変わるだろう。
音声だけなら22番(AAC192kbps)か251番(Opus160kbps)がベスト。
元々は音声の話なので上記を踏まえて音声だけ比較すべきだと思うけど、
>>721はなぜか映像まで含めて
770:WebM vs MP4という比較をしてるし色々的外れ。 「通常はWebMの方がサイズが大きい」と言ってるのもよくわからない。 基本的にはVP9(WebM)の方がAVC(MP4)より小さくて、稀に逆のものもあるという程度だと思うけど。 変なダウンローダを使ってるか勘違いしてしまってるんじゃないかと思う。
771:名無しさん＠編集中
18/05/21 18:11:21.85 pXVYVIdD0.net
ついでに言うとYoutubeの場合、VP9は比較的ファイルサイズが小さくなってるとはいえ、
たまにブロックノイズやリンギングノイズ（モスキートノイズ？）で
映像崩壊レベルになってるフレームがあったりする。
普通に視聴する分には気にならないけど、比較するとAVCの方が安定した画質になってるような。
まあ1440pHFR以上は基本的にVP9だけしか無いけど。
772:名無しさん＠編集中
18/05/21 19:06:54.29 41ToqTwjM.net
理解不足にもほどがある
773:名無しさん＠編集中
18/05/21 19:41:25.11 vORAC5lE0.net
おっぱす音いいよね
774:名無しさん＠編集中
18/05/22 01:36:52.77 q/SFdsGY0.net
EdgeはGPUにVP9デコーダが搭載されてればVP9、
無ければH.264で再生されるから賢いというか優しいというか
ChromeはGPUデコーダ無くてもVP9にするからCPUデコードになって重い
VP9デコーダ無いような古いPCでCPUデコードとか鬼だ
メモリも喰いまくるしオンボロPCで動かすんじゃねえってGoogleの方針なんだろう
775:名無しさん＠編集中
18/05/22 04:11:37.33 VZpL9/6Ha.net
回線には優しいとも言える…
776:名無しさん＠編集中
18/05/22 12:23:15.14 3IwnndRVa.net
Google「絶対自社コーデック流行らせるマン」
777:名無しさん＠編集中
18/05/22 12:25:31.44 J9S5pwTqM.net
av1はどの程度のデコード負荷になるんだろうね
778:名無しさん＠編集中
18/05/22 12:59:59.57 hCnh500/M.net
HEIF形式イメージの読み書きをサポートした「GIMP」v2.10.2が公開
URLﾘﾝｸ(forest.watch.impress.co.jp)
779:名無しさん＠編集中
18/05/22 15:06:40.87 f7yYRC9xM.net
HEIFに自動変換してくれるアプリ早く出ないかな
780:名無しさん＠編集中
18/05/22 19:33:33.87 hkxnh+Qq0.net
HEIFってそんなにすごいのか？
781:名無しさん＠編集中
18/05/22 19:37:15.90 49Qgr65Qd.net
hevcに変換するアプリも無いというのに…
782:名無しさん＠編集中
18/05/22 20:13:12.99 f7yYRC9xM.net
xnconvがはやいところ対応してほしい
783:名無しさん＠編集中
18/05/23 11:55:09.56 HvhLW0tF0.net
HEIFってOSではポツポツ対応しはじめてるけどフリーソフトではなかなか対応しないね
784:名無しさん＠編集中
18/05/23 14:50:02.22 Zc10p1dw0.net
>>732
おんぼろPC+Chromeにh264ify入れて使ってるぜ…
785:名無しさん＠編集中
18/05/25 23:39:19.34 Yo07VXfMM.net
avifの音沙汰ないね
786:名無しさん＠編集中
18/05/26 11:07:51.18 GSqnw95HM.net
ネタ切れでビデオコーデック以外のネタばっかりになってきたな
それはそれで良いけど
787:名無しさん＠編集中
18/05/26 13:45:04.81 yfBRopuuM.net
H.264が動画界のJPEGみたいな感じになって終わりやろ
新フォーマット？なにそれおいしいの？みたいな
788:名無しさん＠編集中
18/05/26 13:53:41.45 P80ldEHd0.net
さすがにそれはない
789:名無しさん＠編集中
18/05/26 20:35:37.87 ckKQMTEV0.net
配信があるのでシビアだよ
俺も264で世は収まったと思ってたけど
ある日突然ツベの4Kがガクガクになって思い知ったよ…
790:名無しさん＠編集中
18/05/26 21:59:19.73 MnpZ35FCM.net
4Kに対応しようとすると古いPCは一気にアウトだからねぇ
4Kで思い出したがAV機器板のUHD-BDスレにて
・4か月弱ぶりのWHQL版「Radeon Software Adrenalin Edition 18.5.1」リリース。Ryzen 2000G公式対応を果たした統合型ドライバ
URLﾘﾝｸ(www.4gamer.net)
791:0524003/ 「なお，新世代APUへの対応以外では，ハードウェアレベルの4Kビデオ保護技術としてMicrosoftが推進する「PlayReady 3.0」に Radeon RX 500＆400シリーズで対応したことと，「Ancestors Legacy」への最適化がトピックとなっている。」 「PlayReady 3.0」の対応、つまり外付けGPUを利用してのUHD-BD再生の道が一歩開けたということか？ Intel SGXに頼る必要はなくなった？ とあった PCによる4K再生が少しでも身近になればいいのだが
792:名無しさん＠編集中
18/05/26 22:41:47.71 0LnMSXzY0.net
面倒すぎてRIPした方が早い気がしてくる
HDMI2.0は破られてるし縛る意味とは
H265が身近になるには、あと数年、スマホのハードウェアデコーダー搭載率が上がったらだね
載ってない世代でCPUデコードはほぼ無理だし
793:名無しさん＠編集中
18/05/27 01:54:44.50 bNrx3kLn0.net
スマホはもうH.265全部対応してるぞ
794:名無しさん＠編集中
18/05/27 08:55:10.14 bYRexonkH.net
アンドロイド定番の画像ビューワ、PerfectViewerがプラグインでHEIFに対応してた
これで画像一括変換ソフトがHEIF対応してくれればなあ
795:名無しさん＠編集中
18/05/27 09:27:31.96 RFBUFGHd0.net
ジャップ製の印刷機やデジタル家電、ソフトなどが対応進まないと無理じゃね
796:名無しさん＠編集中
18/05/27 11:20:32.94 NTcZ8PLk0.net
ちょっと戻っちゃうけど
画像の圧縮なら確かにPDFで「文字と背景を分ける」みたいな圧縮方式があるから、漫画の場合は画像一枚の中で背景レイヤーと文字・絵レイヤーを判別して、背景レイヤーを単色データにすればかなり圧縮できるはず
797:名無しさん＠編集中
18/05/27 12:02:49.06 PvbbGad70.net
それぞれのレイヤーで最適化しないと
単色データぶんだけデータが増えるだけに終わりそう
798:名無しさん＠編集中
18/05/28 02:36:51.96 z2/O+KlE0.net
>>753
これか
URLﾘﾝｸ(www.toshiba.co.jp)
799:名無しさん＠編集中
18/05/28 08:31:23.90 K4efXcEF0.net
Windows10 Insider Previewでheifの表示試してみたけど対応してるのはyuv420だけでyuv444は見れないな
あとx265のフルレンジフラグを読み取ってくれなくてリミテッド専用になってる
将来的には改善されるんだろうか？
今のままならBPGのほうが使いやすいんだが
800:名無しさん＠編集中
18/05/28 08:41:50.90 K4efXcEF0.net
ちなみにWIC(Windows Imaging Component)でのサポートもしているのでWIC対応のSusie Pluginを入れるとMassiGraなんかでも見れた
801:名無しさん＠編集中
18/05/28 09:55:11.67 K4efXcEF0.net
MSの実装だとYUVからRGBへの変換係数はbt709固定っぽいけどnokiaの実装だとsmpte170m固定っぽいから色がおかしくなる問題が続出しそう
どっちもx265のcolormatrixは読み込みにいってないし(heifのヘッダとかに指定するのかもしれないけどよく分からない)
この辺も整備されないと使いにくいな
802:名無しさん＠編集中
18/05/28 11:53:22.59 VHhEvktNa.net
WindowsはOS、画像ビューアともに伝統的にICCプロファイルをきちんと反映させようとしていない（一部の優良な画像ビューアは対応している）からな
803:名無しさん＠編集中
18/05/28 18:00:44.96 K4efXcEF0.net
いやごめん
MSの実装の方、フルレンジフラグを読み取ってくれないって書いたけどコマンドラインの記述が間違ってただけで修正したら読み取ってくれたわ
それにcolormatrixだけじゃなくてtransferとcolorprimも指定したら正しい色で表示してくれた
案外ちゃんとしてるな
こんな感じ
set
804: "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"
805:名無しさん＠編集中
18/06/01 19:20:59.50 kSeXDzjIM.net
ARMがスマホ向け新GPU「Mali-G76」＆新VPU「Mali-V76」を発表、スマホで8K・60fps再生に対応へ
URLﾘﾝｸ(gigazine.net)
URLﾘﾝｸ(i.gzn.jp)
Mali-V76は2コアから8コアが想定されており、8コア時には8K・60fpsのデコードと8K・30fpsのエンコードに対応。4K・120fpsのデコードにも対応します
ただし、Mali-V76にはGoogleなどが開発する次世代コーデック「AV1」はサポートリストに含まれていません
806:名無しさん＠編集中
18/06/01 19:38:22.92 msrxg0ukM.net
動画の再生支援に関しては、スマホに先越されてばかりだな
そのうちスマホをPCに接続して、動画再生支援用の外付けGPUみたいにして使う時代が来るのかね？
807:名無しさん＠編集中
18/06/01 20:07:36.34 U6b4eKsX0.net
新フォーマット→ハードウェア支援
っていたちごっこ
808:名無しさん＠編集中
18/06/01 20:37:04.23 uvakM5Y80.net
先越されていたっけ？
ARMのIP積んだモデル出回るのなんか1年先でしょ
それもPC並みの値段で
809:名無しさん＠編集中
18/06/01 20:49:35.36 uvakM5Y80.net
HEVC 10bit 8KならIntelならCore iならKabylake、Atom系ならApolloLake（デコードのみ、エンコはGeminiLake～）以降で対応
nvidiaならPascal世代で対応済みだから、ARMの方が2年近く遅い
810:名無しさん＠編集中
18/06/01 20:55:14.58 9DPbKfMc0.net
次世代スレなのに>>762が旧世代過ぎて吹いた
811:名無しさん＠編集中
18/06/01 22:20:39.42 msrxg0ukM.net
？
SnapdragonのHEVCハードウェア再生支援は、余年くらい前から対応してたはずたがな
記憶違いか？
812:名無しさん＠編集中
18/06/01 23:24:22.72 1SKPSPTs0.net
スマホ -> PC -> モニタ ってめんどくさくね
スマホ -> モニタ でええやんか
813:名無しさん＠編集中
18/06/02 03:11:43.20 tUT7qzfh0.net
>>767
8K対応してたん？
814:名無しさん＠編集中
18/06/02 03:12:45.62 hFj2Wb5N0.net
8Kの話なんぞ誰もしてねぇ
815:名無しさん＠編集中
18/06/02 07:54:52.37 ZfXg0V8T0.net
URLﾘﾝｸ(satch.tv)
816:名無しさん＠編集中
18/06/02 19:14:17.19 Ypf4BKGE0.net
久々にIntelの動画再生支援の対応可否をチェックしてみたが
・Intel HD, UHD and Iris Graphics（英語のサイト）
URLﾘﾝｸ(en.wikipedia.org)
■HEVC
・Haswellは、8bitのみ部分的な対応
・Broadwellは、8bitと10bitの部分的な対応
・Skylakeは、8bitは4Kまで対応
・Kaby LakeとCoffee Lakeは、8bitと10bitともに4Kまで対応
続く
817:名無しさん＠編集中
18/06/02 19:14:34.04 Ypf4BKGE0.net
■VP9（YouTubeなど）
・Haswellは、対応なし
・Broadwellは、部分的な対応
・Skylakeは、4K24Pの15Mbpsまで対応
・Kaby LakeとCoffee Lakeは、8bitのみ4K（60pかどうかは不明）まで対応
（BT.2020については将来的に対応予定）
※なお、下記サイトによると、AMDが「VegaベースのGPUコア＝Radeon RX Vega 64 L
818:iquid 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
819:名無しさん＠編集中
18/06/02 19:34:50.70 Ypf4BKGE0.net
追記
Snapdragon 820搭載のスマホにVP9でエンコードされた4K60Pの動画を入れて試したところ、
カクカクでした
4K60Pはやはり重い
820:名無しさん＠編集中
18/06/02 19:36:29.19 OSElj/9u0.net
ARMはデコードにもGPUの演算コアも使ったりするからな
PC向けGPUみたいにメディアエンジンのみで処理出来るのは世代重ねてからだぞ
ソフトウェアデコーダより消費電力は低いけど、PCで言うところのハードウェアデコーダと少し実装違う
まぁそれでも消費電力の設計母数小さいからまだ省電力と言えるだけで
それでも砂ドラの800や805とかでH265の再生なんぞやったら、FHDでも数十分もせず馬鹿みたい発熱しながらバッテリー消費していく
821:名無しさん＠編集中
18/06/03 16:10:10.50 D9URccfv0.net
windowsならタスクマネージャでCPU使用率さくっと分かるけど、androidってシステムていきょうのツールねぇのかよ。
とりあえずCPU statsというアプリで動画再生しながらCPU使用率確認してるけど
822:名無しさん＠編集中
18/06/03 16:15:21.03 c3tJcF3r0.net
俺もandroid8になって
CPU利用率見れなくなって不便してる
823:名無しさん＠編集中
18/06/03 17:25:49.90 VcUUsYyc0.net
セロテープ どーです
URLﾘﾝｸ(satch.tv)
824:名無しさん＠編集中
18/06/04 18:34:15.74 zpOHy/PYM.net
■Arm、モバイルで8K/60fps再生対応のVPU「Mali-V76」。VR/ゲーム向けGPUも
URLﾘﾝｸ(av.watch.impress.co.jp)
・8K60Pのハードウェア再生支援対応
・8K30Pのハードウェアエンコード対応（※これは現時点での話）
・4K60P動画の4本同時再生可能
・2K60P動画の16本同時再生可能
■ARM Announces Mali-V76 Video Processor: Planning For the 8K Video Future
URLﾘﾝｸ(www.anandtech.com)
・4K120Pも同時再生可能本数は不明ながら再生には対応
・H.264、HEVC、VP8、VP9のすべてにおいて、8bit及び10bitの動画をデコード及びエンコード可能
・AV1はデコード及びエンコードともに非対応
825:名無しさん＠編集中
18/06/04 23:26:47.05 6FcsBDSw0.net
デコードもGPUコアのクラスタ数に依存しているという事は、メディアプロセッサだけでは、PC向けGPUと違ってデコードも処理出来ていないって事なんだがな
826:名無しさん＠編集中
18/06/06 17:26:25.18 MdIonTii00606.net
クラウド上のFPGAを利⽤するAV1エンコーダーを実装
URLﾘﾝｸ(www.socionext.com)
[横浜発, 2018 年 6 月 6 日] 株式会社ソシオネクスト (Socionext Inc.) は、アマゾン ウェブ サービス (以下「AWS」) の「Amazon Elastic Compute Cloud (以下、Amazon EC2) F1 インスタンス」上に、
最先端の映像データ圧縮規格「AV1」のエンコード処理を⾏う機能を試作実装しました
F1 インスタンスの利⽤により、約 1.5 カ月という極めて短期間で開発を完了し、かつ高い性能を得ることができました
�
827:鮪ﾐは今回の成果をもとに、顧客がクラウドから半導体製品の機能を利⽤できる仕組みや、現在クラウド環境で広く利用されている大規模・高性能アプリケーションの処理能⼒を向上させる各種アクセラレーターの構築・運用など、 サービス提供を中心とした新しい製品の可能性を提案します F1 インスタンスの利用により、開発開始から 1.5 ヶ月という驚異的な短期間での開発が可能になっただけでなく、FPGA によるアクセラレーションで CPU 単体動作と比較して約 10 倍の処理速度を実現しました
828:名無しさん＠編集中
18/06/06 19:36:41.93 XMNfIyvrp0606.net
これはいいね。LSIを起こせないようなスタートアップ企業が競い合って早く技術が成熟するといいですな。
大学の研究室からのエントリも面白い。
829:名無しさん＠編集中
18/06/06 20:17:58.22 BmPMzdiGM0606.net
今年の第三四半期にAMDの新型スリッパが32コア64スレッドなCPUを投入するらしいが、そんな強烈なのが出たらHEVCのエンコードもサクサクかな？
830:名無しさん＠編集中
18/06/06 20:58:49.24 H+EDN/6z00606.net
単純に現世代スリッパの2倍弱の性能かと
831:名無しさん＠編集中
18/06/06 21:00:57.01 Us3T3EKQ00606.net
数が物を言うからサクサク
832:名無しさん＠編集中
18/06/06 22:48:09.02 pgE+EAbY0.net
性能倍なら同世代の16C32Tスリッパの倍以上の価格なんだろうけどね
833:名無しさん＠編集中
18/06/07 06:42:41.69 BUCDO0NW0.net
AV1のエンコーダーなかなか早くならないな
1080pの10フレームをエンコードするのに52分もかかった
834:名無しさん＠編集中
18/06/07 06:47:36.47 ZLo0l3oi0.net
>>787
Intelの5GHz×28コアCPU搭載した化物マシンが必要
835:787
18/06/07 07:21:29.36 cB42yIva0.net
いや、>>378ではi7 4702MQで10フレームエンコードするのに66分かかったって書いてるからちょっとは早くなってるかな
こちらのCPUはi7 3520M
836:名無しさん＠編集中
18/06/07 09:09:09.35 MAsn1r6+M.net
今年中に100倍程度速くなるなんて緩い予想はなかなか実現しそうに無いな
837:名無しさん＠編集中
18/06/07 09:12:18.34 lKIi0lgc0.net
1フレームエンコードするのに6分かかるのか
昔の3DCGみたい
838:787
18/06/07 10:23:58.45 pclL2Ig50.net
AV1のエンコーダー以外を終了させて厳密に計り直したら早くなってたわ
まだ全然実用的じゃないけど
バイナリはここの
URLﾘﾝｸ(www.mediafire.com)
2018/03/27 v0.1.0-8892-g10b745615
1時間38分45秒
2018/06/01 v0.1.0-9658-g265d15d46
40分13秒
839:名無しさん＠編集中
18/06/07 11:01:08.73 lBbrhKu90.net
2ヶ月で2.5倍早くなると仮定しても年内に100倍には届かないか
840:名無しさん＠編集中
18/06/07 12:50:47.06 T1MKciET0.net
そんな小学生が成人するまで同じペースで背が伸びて2m越えるみたいな計算通らんわな
841:名無しさん＠編集中
18/06/07 18:10:44.57 E2VuQZLL0.net
欠陥の無いダイがすげー安く作れるようになったらワンちゃんあるかも
842:名無しさん＠編集中
18/06/07 18:12:56.87 E2VuQZLL0.net
あ、スレ間違えてた失礼した。
843:名無しさん＠編集中
18/06/07 20:34:07.06 4TC5oIYZM.net
今のところマルチスレッドをあまり生かしてくれないのが遅い原因の一つ
--tile-columnsを指定すると横で分割してマルチスレッドでエンコードしてくれるんだけど、
分割数は2の冪乗で、分割した一列あたり256px以上という制限があるので、
1920x1080
844:の動画をエンコードしても4分割しかされず、 使ってくれるスレッドも4つぐらい
845:名無しさん＠編集中
18/06/07 22:19:03.47 Dm4DHeUZ0.net
2passエンコで１pass目でキーフレームの場所を確定させちゃって
2pass目では複数のGOPを同時並列にエンコとかできないのかね。
846:名無しさん＠編集中
18/06/08 03:05:32.24 t5SvlNiJd.net
ならGOP跨ぎでの参照処理出来ないよね
847:名無しさん＠編集中
18/06/12 14:33:27.03 pd4PE/9P0.net
URLﾘﾝｸ(gigazine.net)
ans?ってすごいの?
848:名無しさん＠編集中
18/06/12 20:21:10.83 2LDnx/QSM.net
>>800
いわゆる対抗特許だね
AV1陣営を特許侵害で訴えようとした企業にカウンターするための特許
849:名無しさん＠編集中
18/06/14 19:33:30.72 iJOXbjd1M.net
>>800
ANSは一時期AV1のエントロピー符号化手法の候補になってたけど、
Daalaのエントロピー符号化手法のほうがハードウェア実装しやすいことが分かったので、
採用されなかった。
850:名無しさん＠編集中
18/06/14 21:29:06.32 V+ozARZ/0.net
動画エンコードの探求に「終わり」はあるのか？
URLﾘﾝｸ(gigazine.net)
> 2015年にNetflixの技術者が初めてMPEG会議に参加して、将来の動画コーディングのための文書を発表しました。
> その際に、Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑性が高まるとしてもまったく問題にしない」というスタンスであることを伝えると、
> 議長から「では、どのくらいの複雑さを許容できますか？」と尋ねられたとのこと。
> 回答の準備が整っていなかったNetflixの技術者は「最悪のケースでは100倍まで」と答えると、100人はいたであろう動画コーディングの専門家たちからは大爆笑が起こったそうです。
> 議長は「心配しないで。彼らはみな『新しいこと』を試すことができると、幸せに感じているのです。たいていの人は『3倍まで』と答えるものだから」と話したそうです。
Netflixは100倍遅くても許容するのかー
やっぱりこれから先の動画圧縮技術はリソース有り余ってる大企業だけのものになるんじゃないだろうか
851:名無しさん＠編集中
18/06/14 21:45:53.28 3azMp+/KM.net
エンコードは1回しか行われないのに対してエンコードされた動画は何万回も再生されるから、
例えエンコードに従来の100倍の時間がかかるとしても、
それによって削減される帯域次第では動画配信やってる大手企業は喜んで採用するだろうね。
852:名無しさん＠編集中
18/06/14 21:57:17.85 Wy3gWiiZ0.net
まあh266（？）とAV1以降のエンコードは一般人が持ってるpcじゃなかなか難しそうだろうね、NetflixやYouTube規模の動画配信サービスになるとそれだけの価値があるんでしょ
実際、Netflix、YouTube、アマプラ、Huluが完全にAV1を採用すれば全体のデータトラフィック量はどれくらい少なくなるんだろう
853:名無しさん＠編集中
18/06/14 22:03:37.54 3pgPouao0.net
ハードエンコの品質が上がって画質にうるさいマニアも納得のハードエンコの時代がきたらまだワンチャンある。
というか今エンコにどれくらいのトランジスター割かれてるのか知らんが何十億って使えばもっと速くなるのかな??
854:名無しさん＠編集中
18/06/14 22:12:32.44 yHxY31ke0.net
>>804
なるほど
しかもyoutubeみたく数億人のユーザーがほぼ同時にアップするわけじゃないから
Netflixにとってのハードルは低そう
855:名無しさん＠編集中
18/06/15 05:00:47.70 GX
856:Pu4phC0.net
857:名無しさん＠編集中
18/06/15 05:10:11.86 GXPu4phC0.net
品質についてはVLCの連中がx264/x265の開発止めない限り、個人が無償で扱えるエンコード品質の上限的な基準になっちまうから
妥協無しに満足するなんか無理な話だし
HWエンコーダに無い処理の柔軟性で画質引き上げてる部分が大きいから、その溝は埋められない
cudaコアの物量に頼っていないNVDecであの品質だから、nvidiaがQSV並みの実装する気になってくれれば、QSV HEVC並みの品質でQSVの2～3倍速ってのは不可能では無さそうではあるんだけどな（GPUのグレードに左右されそうではあるけど
858:名無しさん＠編集中
18/06/15 05:11:02.91 GXPu4phC0.net
NVDecじゃないや、NVEncだ、すまん
859:名無しさん＠編集中
18/06/19 00:48:39.51 e172sEo5a.net
配信に使おうと思ってQSVとNVENC試してるんだけど同じビットレートだとNVENCのほうが画質良くなるみたいなんだよね
NVENCが何か改善されて良くなったのかな？
それともQSVがリアルタイムエンコに弱いのか
860:名無しさん＠編集中
18/06/19 01:08:22.25 Ud4iC9hu0.net
QSVのH264でFF使う場合でも無い限り、基本的にはQSVの方が綺麗になるよ
CBRやビットレートベースのVBR使うとQSVの方が画質容量比悪化しやすいってのもあるけど
861:名無しさん＠編集中
18/06/19 01:11:14.79 Ud4iC9hu0.net
あと、比較するQSVの世代にもよる
SnandyやIvy世代はHaswell以降よりCU規模の割に速度出やすい反面、画質向上処理はHaswell以降より劣る（処理が甘い分速くて画質に劣る
862:名無しさん＠編集中
18/06/19 01:33:27.20 Ud4iC9hu0.net
CUはRADEONか、QSVはEUだった、すまん
NVEncはエンコードエンジンの性能勝負で
QSVはGPGPU込みで画質が良い（GPGPU使う時間が取れないFFモードだと画質が駄々下がり
画質は
QSV（延滞問わず）＞NVEnc（元から低延滞）＞QSV FF（低延滞モード）
みたいな感じ
863:名無しさん＠編集中
18/06/19 10:08:37.95 uDXUEk/b0.net
dGPU化でAMD CPU使いでも使えるようになるといいんだけども＞QSV
864:名無しさん＠編集中
18/06/19 12:11:03.86 Dw8bee0Da.net
>>814
なんだレンタル屋の話か
865:名無しさん＠編集中
18/06/19 12:18:30.59 7QbBqShk0.net
延滞？遅延？
どっちが正しい？
866:名無しさん＠編集中
18/06/19 14:45:39.45 E9MLTUx7M.net
日本語きちんと身につけてから書き込め
867:名無しさん＠編集中
18/06/20 14:56:39.39 c8F+n/KJM.net
・「Windows 10 RS5」で“WebP”がサポート、「Microsoft Edge」などで表示可能に
URLﾘﾝｸ(forest.watch.impress.co.jp)
「WebP」をウェッピーと読むのか
ずっとウェブエムだと思ってた…
868:名無しさん＠編集中
18/06/20 15:02:05.22 VEkuRmOZ0.net
突っ込まないわよ
869:名無しさん＠編集中
18/06/20 15:39:44.03 c8F+n/KJM.net
突っ込めよ
わざと書いたのに
870:名無しさん＠編集中
18/06/20 15:47:51.48 K51XVOXH0.net
ウェッピーが正式な発音だと知ってるがウェブピーと読んでる
871:名無しさん＠編集中
18/06/20 15:48:52.74 IFHj6cRM0.net
やあぼくウェッピー！よろしくね
872:名無しさん＠編集中
18/06/20 18:04:20.09 n3A/kDrf0.net
敢えてウェップでしょ
873:名無しさん＠編集中
18/06/21 00:23:07.70 g7B91MzM0.net
ヽ
_,,.,､､,.ｨ-- ti- ､､､....,,,,_ ',
,,..､､ri':'ﾞ/~ ﾚ ' ﾞﾍ:l : : : :~,＞
_,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､�
874:A !l!;: r '" '''＜:::::::::::::;､r' `'' ‐-`.､ / -、 l::::::::::::l ＜"ﾞ'i;ｿ' ', ~.ヽ l:::::::::::l ~' '､ / .） .l::::::::::! '､ ヽ .l:!l:::::l ヽ '､ ＼ ' l! l::!l! ヽ ,' ﾞ ヾ ‐'" ,. r ﾞ そんなに何も見えてないんじゃ ｰ-‐i ,.r,,iilll鬚髯ｦ . l `''' ‐‐ ---t‐' 生きてても面白くないでしょう ￣￣￣￣￣￣~"''､' ‐ ､ ー‐ノ ', ヽ l
875:名無しさん＠編集中
18/06/21 20:30:39.69 SNiRmHlvM.net
・4K映像の低遅延配信に「CMAF」が有効、コーデックは「AV1」主流に? Akamaiが解説
URLﾘﾝｸ(av.watch.impress.co.jp)
AV1は、HEVCやVP9などよりも高い圧縮効率を実現し、開発者向けブラウザのFirefox NigtlyやChrome Canaryでは既に採用されているが、3月予定としていたコードフリーズには6月時点でまだ至っておらず、当初の予定より遅延。
現在はエンコードをソフトウェアで行なっているため多くの時間がかかり、時光氏は「ハードウェア対応は'19年後半にずれ込む恐れがある」としている。
まだコードフリーズすらしていないのか
876:名無しさん＠編集中
18/06/21 21:10:25.27 oS15Ul930.net
数ヶ月前にエンコードしたファイルが新しいバージョンだと出来なくなってるとかまだあるから全く使い物にならないよ
877:名無しさん＠編集中
18/06/21 21:18:04.31 oS15Ul930.net
新しいバージョンだと再生出来なくなってるに訂正
878:名無しさん＠編集中
18/06/21 22:59:51.39 8fdWiSrOM.net
URLﾘﾝｸ(github.com)
仕様のコミットログ見るとぼぼ毎日更新してる。
更新の規模は体裁を整えたりとか、仕様を明確化したりぐらいが多いけど。
URLﾘﾝｸ(people.xiph.org)
ハードウェア実装しやすいアルゴリズムかどうかはちゃんと考慮されてるみたい。
17ページ目に新しい機能は
ハードウェアチーム、知財チーム、ワーキンググループ全体
の順でレビューされると書かれてる。
879:名無しさん＠編集中
18/06/21 23:03:09.05 xej6B48ua.net
ま、あと2年程度は放置プレーでよさそだな
880:名無しさん＠編集中
18/06/21 23:03:18.05 xqqnzSI30.net
個々の要素がHW実装まで考慮に入れてるのはいいね
881:名無しさん＠編集中
18/06/22 16:24:24.15 L0GSH5Vma.net
youtubeとかで使われるようになってもほとんどの端末ではしばらくソフトウェアデコードになるだろうけど負荷はどれくらいになるのだろうか
スマホでも余裕なくらいじゃないとキツイぞ
882:名無しさん＠編集中
18/06/22 18:50:39.55 IFCKBMq30.net
HWデコーダが無い機種はH.264で観ればいいだけだからﾍｰｷﾍｰｷ
883:名無しさん＠編集中
18/06/22 19:52:13.05 nB77Vx1HM.net
すぐに変換されるのは4K以上の動画ぐらいでしょ、きっと
884:名無しさん＠編集中
18/06/22 23:13:41.12 677v3CKv0.net
AV1だろうがそもそもモバイルで4K解像度もってるデバイスほとんどみねぇし、2Kにちょっと毛がはえたぐらいの解像度なら現状出回ってる機種でも余裕じゃねぇのかな。
まぁモバイルはバッテリーの問題があるけどさ。
885:名無しさん＠編集中
18/06/22 23:26:01.34 677v3CKv0.net
と思ったけどH.264のフルHDをSWﾃﾞｺｰﾄﾞしてみたらFireHD10で結構CPU使用率いくな
886:名無しさん＠編集中
18/06/23 01:18:47.48 1leUgnj60.net
YouTubeはビットレートが足りないのと粗雑エンコで1080pは見れたものじゃないから、超高精細映像に構
887:うよりは1080p以下の映像に目線を向けるべきだと
888:名無しさん＠編集中
18/06/23 06:57:44.25 LsekVHN20.net
ネットの人ってどうして一つしか正解を許さない人が多いんだろ
889:名無しさん＠編集中
18/06/23 12:22:52.66 fQhGO9CZ0.net
頭が悪いんだろ
脳内が視野狭窄状態みたいになってる奴がいる
890:名無しさん＠編集中
18/06/26 05:38:09.05 R8Sel04R0.net
URLﾘﾝｸ(aomedia.googlesource.com)
タグがv0.1.0からv1.0.0になった
さすがにそろそろ仕様固まるかな
891:名無しさん＠編集中
18/06/26 16:10:37.06 DPq5oPAOa.net
ようやく仕様固まるのか
892:名無しさん＠編集中
18/06/26 17:28:11.74 rxpWNgp90.net
くだらねえ
893:名無しさん＠編集中
18/06/26 18:28:25.06 eXzvmFXU0.net
AV1の対応、ChromeとFirefoxは着々と進んでいるけどSafariとEdgeはほとんど聞かないね
894:名無しさん＠編集中
18/06/26 18:51:33.30 t7UcI0u80.net
>>843
EdgeはともかくSafari（Mac、iOS）は最後まで抵抗しそう
895:名無しさん＠編集中
18/06/26 20:42:27.35 jPY7pUjf0.net
Appleだって支援してるんだからそれはねえわ
HEICとか作ってまでh265推してたが今時サンクコストにしがみ付いたりはせんやろ
ただハードウェアエンコーダ/デコーダが実装されているという理由で少なくとも2、3年はOSデフォルトとはせんやろな
896:名無しさん＠編集中
18/06/26 20:49:18.64 Z8mnTHd/0.net
AppleもAOMediaの創設時メンバーなのだから、VP9みたいな事態にはならないと思っているがね
897:名無しさん＠編集中
18/06/26 21:26:45.77 yk3GZ3MSM.net
Appleが創設メンバー…？
898:名無しさん＠編集中
18/06/26 21:49:39.83 MeiPf2uT0.net
一応なんかAppleはAV1の創設メンバーとしてリストされてるんだよな、詳しく知らん
URLﾘﾝｸ(japan.cnet.com)
899:名無しさん＠編集中
18/06/26 23:34:16.48 H9Tli3nT0.net
USB Type-C規格策定に大きく関与したが採用せず
LightningケーブルのMFi免罪符で御布施を徴収するAppleのことだ
やすやすMPEG利権を手放すとは思えんな
900:名無しさん＠編集中
18/06/27 09:00:56.30 bc3cRXpq0.net
ムービーミドルウェア「CRI Sofdec2」が、高いデータ圧縮性能を有するビデオコーデック「VP9」に対応。まずはスマートフォン向けから
URLﾘﾝｸ(jp.automaton.am)
株式会社ＣＲＩ・ミドルウェアは6月26日、高画質・高機能ムービーミドルウェア「CRI Sofdec2」の機能を拡張し、
高いデータ圧縮性能を有するビデオコーデック「VP9」を搭載したと発表した。
同社は、ゲーム開発向けに音声・映像のミドルウェアブランドCRIWAREを展開しており、
その中で提供されているSofdec2は、クロスプラットフォーム対応の高画質・高機能のムービー再生システムで、
UnityやEnreal Engine 4といったゲームエンジンにも対応。
『二ノ国II レヴァナントキングダム』や『New ガンダムブレイカー』など、累計4,000タイトルを超えるゲームの開発に採用されている。
今回Sofdec2に搭載されたVP9は、Googleが開発した高い圧縮率と高画質を特徴とするビデオコーデック（動画の圧縮形式）で、
YouTubeのような映像配信サービスなどで幅広く採用されている。
901:名無しさん＠編集中
18/06/27 11:46:27.60 uba2bqEXd.net
>>849
MacBookで採用してるだろ視野狭すぎ
902:名無しさん＠編集中
18/06/27 13:34:13.58 4GNS9DaQM.net
macbookの周辺機器MagicKeyboard、MagicTrackpad2、MagicMouse2はLightningだぜ
全てUSB Type-C策定後に発売というね
903:名無しさん＠編集中
18/06/27 13:51:02.95 4GNS9DaQM.net
>>851
未だAppleがiPhoneやiPadでLightningに固執する理由って既得権益以外ないだろ
904:名無しさん＠編集中
18/06/27 14:21:27.37 WJtszjuNM.net
これだから糞林檎はYO！
905:名無しさん＠編集中
18/06/27 15:58:37.56 TrufeJFC0.net
AV1完成したっぽいから試しにエンコードし始めたけど丸一日経っても終わんねー
375フレームをエンコードするのに50時間くらいかかりそうだ
906:名無しさん＠編集中
18/06/27 16:02:48.32 RzhwDQdzM.net
相当ハードウェアエンコーダに実装し易く作ってるらしいしそのうち爆速エンコ出来るようになるでしょ…多分
907:名無しさん＠編集中
18/06/27 17:38:35.22 5L5AN4qu0.net
GPUの演算能力でゴリ押しできないのかね
効率的に分解できるアルゴリズムなら…
908:名無しさん＠編集中
18/06/27 17:48:42.10 Cu7RJFRq0.net
2年はかかる
909:名無しさん＠編集中
18/06/27 19:17:52.14 MCOmMTau0.net
>>853
LightningからUSB Type-Cに乗り換えるというウワサ話が丁度ネットを駆け巡っているが、はて本当か
910:名無しさん＠編集中
18/06/27 21:32:31.10 didZgUcUM.net
>>859
コネクタ全廃という噂もあるぞ
QiならMFi認証存続できるからな
ありえる
911:名無しさん＠編集中
18/06/27 23:49:32.59 qXlFQQfm0.net
Lightningに固執っていうけど、
速度と給電能力以外での重要な利点＝リバーシブルの利便性は先行して備わってたわけで
わざわざ変える必要もないと思うんだよね
特に>>852のBT接続な周辺機器の充電用途程度なら
912:名無しさん＠編集中
18/06/28 11:38:43.47 zedK7pcL0.net
圧縮率に伴って重いってのもあるけど
デコード側の負荷低減の為にデータの格納にも手間増やしてるからな
913:名無しさん＠編集中
18/06/29 20:56:47.39 kZLc7jCp0NIKU.net
Comparison of recent video coding technologies in MPEG and AOMedia
URLﾘﾝｸ(www.bbc.co.uk)
VVCやばいな、AV1より更に縮むのか
やっぱり特許に触れないように規格作っても性能ではMPEGに勝てないのかなあ
914:名無しさん＠編集中
18/06/29 21:03:49.86 q5uPlvEP0NIKU.net
AV1は重すぎて縮まなくてオワコンになったな
915:名無しさん＠編集中
18/06/29 22:01:57.82 O0LAEPNuMNIKU.net
死産か
916:名無しさん＠編集中
18/06/29 22:02:11.62 sYmf/fSp0NIKU.net
コーデックだから「オワコー」が正しい
917:名無しさん＠編集中
18/06/29 22:05:09.08 O0LAEPNuMNIKU.net
というか、グラフが正しいならばHEVCとAV1の比較をすると、ほとんど差がないから現時点ではHEVCで充分だな
918:名無しさん＠編集中
18/06/29 22:25:05.66 Bien472E0NIKU.net
最後は政治力やで！
919:名無しさん＠編集中
18/06/29 22:51:40.14 vhYyDIbv0NIKU.net
どうせ次世代JPEGと同じでAV1もH265も流行らない
みんなで足の引っ張り合いしてるんだもんなぁ～歩調合わせないと何やっても無理よ
920:名無しさん＠編集中
18/06/29 23:26:43.28 oKzo/8sx0NIKU.net
HEVCは放送での採用が決まっているから問題ない
921:名無しさん＠編集中
18/06/30 00:53:42.48 bhrpUYQo0.net
NetflixやHuluみたいなサイトはライセンス料不要なAV1を間違いなく採用する
ユーザーがアップロードできるサイトは知らん
922:名無しさん＠編集中
18/06/30 01:51:46.92 ZUkZsZo+0.net
早くても2年以上先の話
923: 今考える必要はない
924:名無しさん＠編集中
18/06/30 02:18:19.74 jOwRa4pn0.net
結局コンテンツあたりの視聴する客側に課せられるライセンス料なんぞ数円レベルで、
コンテンツ事業者はその分が無くなれば視聴料を数円単位で安くする訳も無く
ストリーミング配信業者ならそれすら無いんだからな
業者は年間の事業者ライセンス料+コンテンツ毎データ作成時のエンコードのライセンス料を払いたくないだけで、視聴する側は再生時の消費リソース増大（電気代）かHW再生支援環境の更新に出費させられるという
925:名無しさん＠編集中
18/06/30 18:37:48.18 pU26iPezM.net
>>869
次世代ipegはMSが対応するwebpになりそうだけど
926:名無しさん＠編集中
18/06/30 19:03:34.73 PbshjbRV0.net
とりあえず1つだけAV1エンコード出来た
死ぬほど時間かかったしせっかくなんでサンプル欲しい人はどうぞ
最近のFFmpegならデコード出来ると思うので適当に可逆圧縮したりして見て
URLﾘﾝｸ(www.dropbox.com)
927:名無しさん＠編集中
18/06/30 19:29:20.22 PbshjbRV0.net
書き忘れたけど比較のために置いてあるx265、x264はtune ssimでエンコードしてある
それとソースの映像は↓のpedestrian_areaってやつ
URLﾘﾝｸ(media.xiph.org)
928:名無しさん＠編集中
18/06/30 19:42:53.62 vwtkTQ8j0.net
HEVCもAVCもエンコーダー次第だからなぁ。
未だMPEG2のテレビ方法だと差は歴然だが…
低ビットレートだと画質悪いのは当然だし、低ビットレートだとHEVCもAVCよりマシって程度。だから十分なビットレートが確保できる場面が中心になる今後は、AV1よりHEVCで十分としか言いようがない。8KもHEVCで十分。
ビットレート確保できるような大容量回線の開発を進めた方が賢い
929:名無しさん＠編集中
18/06/30 20:02:41.30 PbshjbRV0.net
画像
ソース
URLﾘﾝｸ(i.imgur.com)
AV1
URLﾘﾝｸ(i.imgur.com)
x265 slower(tunessim)
URLﾘﾝｸ(i.imgur.com)
x264 slower(tunessim)
URLﾘﾝｸ(i.imgur.com)
VP9
URLﾘﾝｸ(i.imgur.com)
930:名無しさん＠編集中
18/06/30 21:40:48.81 hp1X2iG30.net
サンプルありがとう
ド素人の目で見た感じ
ディテールの表現
AV1＞x264＞x265≒VP9
動画として見て
AV1＞x265＞VP9＞x264
どうせ大したこと無いんだろうとか思ってたけど、かなり良くて驚いた
この性能でエンコード/デコード処理をどこまで軽くできるか…
931:名無しさん＠編集中
18/06/30 22:13:34.98 40ikmkEsM.net
外出先からなんで動画は見れてないのだが、これ相当ビットレート落としてないか？
HEVCでここまで悪化するのはよほどの場合だと思うのだが
932:名無しさん＠編集中
18/06/30 22:20:36.67 rAbV2HaN0.net
>>878
乙！
動きのある部分 x265
動きの無い部分 VP9
自分はx265がベストAV1はこれからな感じかなアニメとかにはいいかも
※個人の感想です
933:名無しさん＠編集中
18/07/01 01:30:59.95 GqIms1KK0.net
動画の再生はできないから、静止画のみでコメント
今のところAV1でなければというほどのメリットが見いだせるような画質ではないな
そもそも俺の使い方でFull HDを1000kbpsとか見たいな高圧縮自体使わないし
H.264⇒H.265みたいな画質的メリットがあれば見当もするのだが、それほどでもないし
934:名無しさん＠編集中
18/07/01 05:10:35.17 clLyaPjq0.net
1000kbpsで画質を比較するのは確かにアレだしもっと高いビットレートで比較したいというのはあるんだけど、
AV1の1000kbpsをエンコードするのに40時間もかかって更に高いビットレートだとエンコードに一週間くらいかかりそうな感じなので厳しいかも
935:名無しさん＠編集中
18/07/03 02:51:05.27 AnLVJYBH0.net
>>840 でコードにv1.0.0のタグが打たれたようだけど、
仕様の方も固まってたみたいだね。
URLﾘﾝｸ(aomediacodec.github.io)
やっと最適化が進むのかな
936:名無しさん＠編集中
18/07/03 10:10:30.99 usUG+8Wf0.net
光回線の普及で、日本ではH264のビットレートで十分。
AV1まで時間をかけて無理に圧縮する必要ない
937:名無しさん＠編集中
18/07/03 10:54:35.51 JbQyuDuIM.net
もっと鯖の気持ちを考えてあげて！
938:名無しさん＠編集中
18/07/03 10:58:38.68 WefNX0hR0.net
想像力の欠如ってやつだね
939:名無しさん＠編集中
18/07/03 18:09:15.86 L2WaVTHr0.net
何度か書いてきてるけどAV1は俺やお前らのために作られているコーデックではない
940:名無しさん＠編集中
18/07/03 18:15:45.71 83wcRnei0.net
配信事業者やらIT企業の都合で作り始めたコーデックだしなあ
941:名無しさん＠編集中
18/07/03 19:19:14.23 FBMZ3ZU1M.net
>>885
wimaxやmvnoなめてんのか
942:名無しさん＠編集中
18/07/03 19:52:11.99 IHqrS4uda.net
弱小MVNOなんか選んだ客が悪い
943:名無しさん＠編集中
18/07/03 20:05:49.41 XIcbrkpV0.net
でもさ
いくら優れたコーデックができても
オリジナルは取っておくよな
俺はHDD節約したいだけなのに
944:名無しさん＠編集中
18/07/03 22:12:22.97 i06F4Ude0.net
H264/H265でも構わんのに、企業の都合で対応デコーダ積んだ機器に買い換える出費はユーザー持ちという
945:名無しさん＠編集中
18/07/03 22:17:03.62 i06F4Ude0.net
>>892
不在時間中にGoogleフォトに上げさせておけば、各種解像度に勝手にエンコードして保管しといてくれるぞ
946:名無しさん＠編集中
18/07/03 23:44:27.35 L2WaVTHr0.net
>>893
新フォーマットに対応してないハードやOSならH.264やH.265でDLされるし
手元の機器が古くなって買い換える頃には勝手に対応ハードになってるだけの話だと思うが
新フォーマットが出たら即座に対応機器に買い換えないと気が済まない病気？
947:名無しさん＠編集中
18/07/04 00:15:04.02 9JZ53MSWa.net
圧縮動画をさらに別型式に再圧縮したら確実に劣化する
ようつべでもそうだし
948:名無しさん＠編集中
18/07/04 06:01:55.78 1aRc/ftm0.net
新しい動画規格なんて必要無い、古い規格で十分だ、って言ってる人はなんでこのスレを見てるのか分からん
949:名無しさん＠編集中
18/07/04 06:22:05.28 NTsfy1jA0.net
どうせアレだよ、PS2もPS3もPS4も出たら叩き、
ratinaなんて眼の識別能力超えてて無駄とのたまい、
DVDで十分、BDなにそれUHD-BDなんて普及しない
FullHDもいらん、4Kもいらんと言い、HDR何ぞゴミと
絶叫して、その後しれっと手のひら返しする人達のひとり
950:名無しさん＠編集中
18/07/04 07:25:08.73 ICKr52Ee0.net
レイトマジョリティってやつじゃないの
951:名無しさん＠編集中
18/07/04 08:36:17.35 fR6oqR/P0.net
新しい規格や新技術なんて必要なら普及するし、不必要なら普及しない。それだけでしょ
それを見守っていくのがこのスレなのに、必要ないわ旧規格で充分だの何だの言うのは意味不明
952:875
18/07/04 19:40:38.17 +ZHz+wtF0.net
AV1の2000kbpsを追加
途中までだけどグラフも作った
URLﾘﾝｸ(i.imgur.com)
少なくとも低ビットレートでは優秀な性能なのが分かる
953:名無しさん＠編集中
18/07/04 19:52:55.34 9jIoQc9vM.net
>>901
そのグラフの変化量から類推すると、3000kbpsで大差なしになりそうだな
そして画質を考えた場合�
954:A3000kbps以上は必要になるだろうことを踏まえると、 現時点で時間と電気代費やしてまで個人が手を出すメリットがないという結論になるかと
955:名無しさん＠編集中
18/07/04 21:29:56.39 C27N09B60.net
xvc2.0リリース AV1より低ビットレートで画質は同じ位らしい
URLﾘﾝｸ(www.releasewire.com)
956:名無しさん＠編集中
18/07/04 22:33:25.02 KjRUrpJDa.net
>>902
どう見ても3000kbpsでも大幅に上回りそうに見えるが…
957:名無しさん＠編集中
18/07/04 23:37:46.59 Z3IIY3490.net
グラフの比較検討方法を知らんのか…
958:名無しさん＠編集中
18/07/04 23:48:30.63 tAoenyjya.net
0.97位にはなるでしょ？
それが大幅と言うのは言い過ぎかもしれない
それにネットストリーミングだと1000～2000kbpsがターゲットでしょ
959:名無しさん＠編集中
18/07/05 01:02:44.55 8/5ltvOB0.net
いつからか知らんけど、H.265の v5 (Approved in 2018-02-13) の規格書が
TIES user以外でもダウンロードできるようになってた。
H.265?:?High efficiency video coding
URLﾘﾝｸ(www.itu.int)
960:名無しさん＠編集中
18/07/05 01:21:33.48 8/5ltvOB0.net
今更だけど、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
URLﾘﾝｸ(software.intel.com)
>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
961:名無しさん＠編集中
18/07/05 02:24:55.73 XDZsM6bE0.net
人の目で見て、って事でしょ。
それより、ストリーミングはもう3000kbpsは超える時代では？2Mbps程度が最適な環境のユーザーをターゲットにする意味無さそうだし、6Mbpsくらいで考える必要あると思うが。
極端な話、6Mbpsで2Kを配信するか、4K配信に耐えうるか、という
962:名無しさん＠編集中
18/07/05 03:22:20.00 8/5ltvOB0.net
そろそろ次スレの時期なので、テンプレ案を作ってみました。
スレタイにはVVCを追加。
追加・削除・変更案などがあればお願いします。
次世代ビデオコーデック総合スレPart2向けテンプレ案１
URLﾘﾝｸ(pastebin.com)
963:名無しさん＠編集中
18/07/05 07:59:26.10 +NvaBjbs0.net
>>908
VP9のエンコはKaby以降にあるじゃない
URLﾘﾝｸ(pc.watch.impress.co.jp)
URLﾘﾝｸ(github.com)
964:名無しさん＠編集中
18/07/05 10:50:13.05 1UfY3jXYa.net
>>909
mp4の頃は1080pの動画で5～8Mbpsが普通だったと思う
それがVP9になったら大体2～3Mbpsに収まっててビビったけどな
AV1の
965:目的はそれを1～2Mbpsまで落とすことでしょ
966:名無しさん＠編集中
18/07/05 10:59:38.12 +KchybRl0.net
>>912
フロッピーディスク１枚に
フルHDが5,6分入るのか
凄いな
967:名無しさん＠編集中
18/07/05 11:01:09.89 +KchybRl0.net
ごめん計算間違えた
968:名無しさん＠編集中
18/07/05 12:09:40.44 LOVtjgMHM.net
>>913
そんな夢規格があれば通信問題なんざ一気に解決だな！！！
969:名無しさん＠編集中
18/07/05 13:20:26.29 z5MGNdXa0.net
>>909
高いほうのスペックに統一しても割に合わないし
970:名無しさん＠編集中
18/07/05 14:01:31.81 u1ci+h+3M.net
1MbpsでフルHDとか、お花畑すぎるわな
971:名無しさん＠編集中
18/07/05 14:28:37.34 zvO2XrpYM.net
トラフィックいっぱいいっぱいで光回線ですら１Ｍ出ないこともあるのに
６Ｍターゲットとかどうなの
972:名無しさん＠編集中
18/07/05 14:42:34.86 LMro1e0V0.net
>>911
今のところKabyLakeでVP9エンコード機能を利用できるのはLinuxだけらしいんだけど、
CannonLakeからはWindowsでも使えるようになるかもねという話ね。
>>35と、>>910のテンプレ案の7のところを参照。
>>980まで残り少ないんで、>>910のテンプレ案へのご意見はお早めに。
973:名無しさん＠編集中
18/07/05 15:04:36.66 B9bh6rCrd.net
>>894
ハメ撮りとかクラウドに上げられないだろ
974:名無しさん＠編集中
18/07/05 15:20:05.19 u1ci+h+3M.net
>>918
回線業者がショボすぎるだけだろ
975:名無しさん＠編集中
18/07/05 15:45:53.84 6+G1s2KW0.net
うちはeo光100Mbps契約だが、混んでる時間でも15Mbpsを切ったことはないな
976:名無しさん＠編集中
18/07/05 16:15:21.43 z5MGNdXa0.net
自分の環境がそうだからってみんあそうとは限らないし
そもそもネット配信はスマホなどモバイルでの視聴がかなり多いのに6Mbps以下は切り捨てはマズい判断
977:名無しさん＠編集中
18/07/05 16:35:18.06 2wqk57+T0.net
VP9もそうだけど、コンテンツ配信側の意向則したロジックチューニングなのは分かった
978:名無しさん＠編集中
18/07/05 17:01:32.47 u1ci+h+3M.net
スマホなんて720pで充分
979:名無しさん＠編集中
18/07/05 19:20:39.01 JG9+8KmDa.net
ユーザーの回線環境なんて関係ないだろう
動画配信業者がトラフィック削減のためにやってるんだから
980:名無しさん＠編集中
18/07/05 20:31:03.07 yYJCBEpPM.net
そもそもユーザー側で動画をソフトウェアエンコードしたいという需要が今や少数派すぎる。
大多数は動画コンテンツを消費しかしないし、
保存のためにエンコードするにしてもレコーダーとかだからハードウェアエンコード。
981:名無しさん＠編集中
18/07/05 22:37:22.56 2wqk57+T0.net
「今や」とか過去に大勢居たかの様に言われましても
982:名無しさん＠編集中
18/07/05 23:24:38.71 UP4YHgHg0.net
日本のインフラと定額回線を基準に考えているやつは絶望的に想像力が欠如している
大手配信業者がサービス展開してるのは日本のような国ばかりじゃないんだぞ
983:名無しさん＠編集中
18/07/06 01:08:44.89 wB6j/Bzp0.net
>>912 YouTubeはH.264で3～4Mbpsくらいでエンコされてるぞ。VP9も同じくらい（動画によって圧縮できてたり逆にサイズでかくなってたり、差がある）。
個人的な話だけど、コーデックは得意不得意があるせいで、VP9の方が破綻少ない場面が多い反面、H264の方が精細に表現できる場面もあったりするから、圧縮効率よりそっちを重視してる。
984:名無しさん＠編集中
18/07/06 01:09:19.05 82pzHCNL0.net
というか日本も固定回線の品質はここ数年で悪化しているような…
985:名無しさん＠編集中
18/07/06 01:10:41.10 wB6j/Bzp0.net
スマホで映画やテレビ見るには720pでいいと思う
986:名無しさん＠編集中
18/07/06 08:41:57.71 dIWrZLr70.net
テンプレ以外の次世代コーデックはavs2とrmhdとxvcがある
987:名無しさん＠編集中
18/07/06 09:03:49.80 HwuE0scw0.net
>>933
あるっちゃあるけど
988:テンプレに入れるほどでもないかなーと・・・
989:名無しさん＠編集中
18/07/06 11:00:08.84 PAe1KCzn0.net
armのMali-Vシリーズは？
URLﾘﾝｸ(en.wikipedia.org)(GPU)#Mali_Video
990:名無しさん＠編集中
18/07/06 13:22:29.91 d/hR1gKLd.net
スマホでmpeg2やh264食わせたら、HEVCやVP9に出力してくれるようなアプリって言うあるの？
エンコーダーはカメラ入力しか使えないの？
991:名無しさん＠編集中
18/07/06 13:22:58.33 d/hR1gKLd.net
xって言う
oって
992:名無しさん＠編集中
18/07/06 13:26:19.42 KA2j/Rts0.net
iOSは知らんが、Androidだとffmpeg media encoderってアプリがある。スマホじゃ遅くて使い物にならんけどな
993:名無しさん＠編集中
18/07/06 13:38:55.12 s6ngyS3I0.net
将来AndroidのHWエンコーダ使ってくれるようになったら
PCの外部エンコーダーとして使えて便利かもね
何台もつなげて高速化
994:名無しさん＠編集中
18/07/06 14:20:16.16 cdcWZ8cz0.net
>>936
自分はiPhoneで有料だけど Compressor っての使ってる
URLﾘﾝｸ(itunes.apple.com)
バッチ処理したいなら同じ作者がバッチ用のアプリも作ってるんでそっちの方がいいかも。
SoCのHWを上手く使っているのかiOSが優秀なのかまあまあ使える速度。さすがに映画クラスの長さだと時間かかるけどな
995:名無しさん＠編集中
18/07/06 23:31:02.15 H1wvcCGn0.net
性能が良い保証無いけどな
996:名無しさん＠編集中
18/07/08 23:10:27.75 72KoFDYM0.net
お馴染みXiphのMontyによるAV1技術解説がMozillaのサイトに公開されてたよ
URLﾘﾝｸ(hacks.mozilla.org)
997:名無しさん＠編集中
18/07/09 00:56:46.59 ydMC3XII0.net
日経BPにAndroid Pについての記事があったよ。
URLﾘﾝｸ(tech.nikkeibp.co.jp)
新しいメディア形式とデコーダーのサポート
このほかの変更点としては、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で統一されるかな。