■ このスレッドは過去ログ倉庫に格納されています
次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
- 1 ：名無しさん＠編集中 ：2018/01/12(金) 21:23:36.27 ID:p2VANSXd0.net
- H.264/AVCの後の様々な次世代ビデオコーデック全般について語るスレです。
■主な次世代ビデオコーデック
●H.265/HEVC
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
●VP9
The WebM Project
https://www.webmproject.org/
●AV1(AOMedia Video 1)
Alliance for Open Media
http://aomedia.org/
■分岐前のスレ
【2016】 H.265/HEVC Part7 【7680x4320】
http://mevius.5ch.net/test/read.cgi/avi/1485191956/
次スレは>>980が宣言してから立ててください。
- 2 ：名無しさん＠編集中 ：2018/01/12(金) 21:26:57.27 ID:p2VANSXd0.net
- テンプレ化するかどうかはともかく、保守ついでにいくつか。
Ｑ．おおまかな現状はどうなってるの？（2018年1月中旬時点）
Ａ．H.265/HEVCはUltra HD Blu-rayなどで採用されているが、
複数のライセンスプールの存在により権利関係が複雑化し、
ブラウザ対応や配信での採用が進まない状況。
それに縛られないロイヤリティフリーのコーデック開発を目指して
主要各社がAlliance for Open Mediaを立ち上げ、
VP10/Daala/ThorなどをベースとしたAV1コーデックを開発中。
2018年1月頃にAV1の仕様を確定する予定だが、この予定は
これまでも度々延期されているので、あくまでも予定。
また、様々な特許が存在する中で、AV1が本当にロイヤリティフリーを
実現できるかどうかについては不透明な部分もある。
- 3 ：名無しさん＠編集中 ：2018/01/12(金) 21:27:46.44 ID:b6QPr80j0.net
- 乙
- 4 ：名無しさん＠編集中 ：2018/01/12(金) 21:29:18.38 ID:b6QPr80j0.net
- 保守
- 5 ：名無しさん＠編集中 ：2018/01/12(金) 21:29:40.61 ID:p2VANSXd0.net
- Ｑ．H.265/HEVCの次の規格の標準化ってどうなってるの？
Ａ．2020年の標準化を目指してJVET(Joint Video Experts Team)で検討が進められている。
FVC(Future Video Coding)という表現がされている模様。
参考リンク
JVET - Joint Video Experts Team
https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jvet.aspx
Future Video Coding | MPEG
https://mpeg.chiariglione.org/standards/exploration/future-video-coding
HEVCを超える映像符号化標準(PDF)
https://www.ituaj.jp/wp-content/uploads/2017/06/2017_06-07-Spot-HEVC.pdf
JVETが開発を進めているHEVC/H.265を超える次世代符号化技術とは？
https://4k8ktv.jp/2016/09/22/jvet/
次世代エンコード技術(H.266?)は、H.265/HEVCの半分のビットレートで同等の性能を実現？！
https://4k8ktv.jp/2016/03/20/next-generation-encode-h266/
- 6 ：名無しさん＠編集中 ：2018/01/12(金) 21:30:25.94 ID:b6QPr80j0.net
- 保守
- 7 ：名無しさん＠編集中 ：2018/01/12(金) 21:32:30.34 ID:b6QPr80j0.net
- テンプレ割り込んじゃったゴメン
- 8 ：名無しさん＠編集中 ：2018/01/12(金) 21:33:44.52 ID:xnJK8D2y0.net
- 乙
- 9 ：名無しさん＠編集中 ：2018/01/12(金) 21:34:59.24 ID:b6QPr80j0.net
- 保守
- 10 ：名無しさん＠編集中 ：2018/01/12(金) 21:37:07.47 ID:b6QPr80j0.net
- 保守
- 11 ：名無しさん＠編集中 ：2018/01/12(金) 21:39:04.57 ID:p2VANSXd0.net
- 549名無しさん＠編集中 (ﾜｯﾁｮｲ b369-tIp8)2017/09/05(火) 13:23:06.31ID:/vroGjCw0
AV1: A Status Update
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-Status-Update-120214.aspx
- 12 ：名無しさん＠編集中 ：2018/01/12(金) 21:39:34.96 ID:b6QPr80j0.net
- 保守
- 13 ：名無しさん＠編集中 ：2018/01/12(金) 21:39:45.38 ID:p2VANSXd0.net
- 559名無しさん＠編集中 (ﾜｯﾁｮｲ 6344-O4z1)2017/09/05(火) 20:16:48.61ID:ObU8b+GC0
549の概要
●AV1のビットストリーム仕様の確定は2017/12/31までを目標としている
●ただ、YoutubeやNetflixといった主要メンバーが納得するレベルにならないとリリースされない。
●Netflixの担当者は「HEVCより20%効率的で、計算量は3〜5倍」というレベルを目安としている。
Youtubeの考えは不明。
●これまでの評価は
Netflix「AV1はVP9より20%効率が良い」
Google「AV1はVP9より30〜35%効率が良い」
とされているが、4月のBitmovin AV1での検証ではそこまで良いものではなかった。
当時77あった実験的コーディングツールのうち8つしか使ってなかったので
改善の余地は大いにあるが、これらの機能の統合や最適化は難しい作業になるだろう。
●ビットストリーム仕様確定後の見通しは以下の通り。
・ChromeやFirefoxは数日中に再生をサポート
・チップの開発に12〜18か月、更にそれを利用したHWリリースに6か月。
- 14 ：名無しさん＠編集中 ：2018/01/12(金) 21:40:42.42 ID:p2VANSXd0.net
- 560名無しさん＠編集中 (ﾜｯﾁｮｲ 6344-O4z1)2017/09/05(火) 20:18:09.16ID:ObU8b+GC0>>561
(559の続き)
●4月のNABでのBitmovinの実験では1080p24のリアルタイムエンコードに最大200コア程度が
必要だったが、そう遠くないうちに8-32コアでできるようになるだろうというコメントもあった。
http://www.streamingmedia.com/Articles/Articles/Editorial/Featured-Articles/Bitmovin-Pushes-AV1-Forward-Joins-Alliance-for-Open-Media-117634.aspx
■参考：262の記事にある4月時点のAV1のエンコード速度
https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/
・LenovoのT540pノート(i7-4800MQ, 8GB RAM, Ubuntu 14.04)で
1080p24の40秒クリップをエンコードするのに8時間42分かかる。
つまりエンコード速度は0.032fps。
・デコードは上記環境でも問題ない。
- 15 ：名無しさん＠編集中 ：2018/01/12(金) 21:42:39.37 ID:p2VANSXd0.net
- ■AV1のベースとなったコーデック各種（これらとVP10）
●Daala
https://xiph.org/daala/
●Thor
https://github.com/cisco/thor
- 16 ：名無しさん＠編集中 ：2018/01/12(金) 21:49:14.72 ID:KWJYTJ4N0.net
- 保守
- 17 ：名無しさん＠編集中 ：2018/01/12(金) 21:49:43.43 ID:p2VANSXd0.net
- ■AV1コーデックの基本的な試し方
●以下からソースを落として自分でビルド（aomenc.exeがエンコーダ、aomdec.exeがデコーダ。）
https://aomedia.googlesource.com/aom/
●エンコード方法の一例
ffmpeg.exe -i source.avi -pix_fmt yuv420p -f yuv4mpegpipe - | aomenc.exe --cpu-used=8 --passes=1 -o av1.webm -
●再生方法の一例
aomdec.exe av1.webm | ffplay.exe -
- 18 ：名無しさん＠編集中 ：2018/01/12(金) 21:51:27.71 ID:p2VANSXd0.net
- 今のDTV板の仕様だと、1時間に20レスつかないとすぐ落ちるんだっけ？？？
- 19 ：名無しさん＠編集中 ：2018/01/12(金) 21:52:40.55 ID:KWJYTJ4N0.net
- >>18
そう
多分変わってないはず
- 20 ：名無しさん＠編集中 ：2018/01/12(金) 21:55:33.42 ID:66WKSsbI0.net
- 言い出しっぺだから保守
以後HEVC以外のコーデックの話題やAV1コーデック等とHEVCの比較の類はここでお願いします
- 21 ：名無しさん＠編集中 ：2018/01/12(金) 21:56:05.59 ID:p2VANSXd0.net
- スレ立て人以外のレスも混ざらないとダメなんだっけ？よくわからん。
とりあえず、念のため他の人にあと数レスしといてもらえれば確実かな？
俺は用事で離席しなきゃならないので、ここまで。あとはよろしくお願いします。
上で書き込んだ内容に変な点があればツッコミもよろしくです。急いでざっくり調べたものもあるので。
- 22 ：名無しさん＠編集中 ：2018/01/12(金) 21:58:24.93 ID:WXEDqbQd0.net
- >>21
いや自分のレスだけで20でもいいよ
初心者総合質問スレはそうした
- 23 ：名無しさん＠編集中 ：2018/01/12(金) 22:03:39.02 ID:8w6T7oTU0.net
- >>1
乙
- 24 ：名無しさん＠編集中 ：2018/01/12(金) 23:57:29.58 ID:8T9bzXwg0.net
- >>22
そうだったのか。なんにせよ無事落ちずに済んだようでなにより。ついでに最近のAV1関連記事。
1/5
アップル、動画圧縮技術の開発を目指すAlliance for Open Mediaに加盟 - CNET Japan
https://japan.cnet.com/article/35112777/
1/12
業界を取り巻くプロセッサの脆弱性問題とアップルの対策--Appleニュース一気読み - CNET Japan
https://japan.cnet.com/article/35113077/
・上の1/5の記事に触れてるだけだが「「AV1」は将来の動画圧縮技術のスタンダードとなるか」の項目あり。
- 25 ：名無しさん＠編集中 ：2018/01/13(土) 00:16:29.83 ID:csmv14ek0.net
- >>1乙
それはそうとH.265/HEVCスレの後継立てる人いるんかいな
- 26 ：名無しさん＠編集中 ：2018/01/13(土) 00:53:08.38 ID:exMofL5M0.net
- >>25
どうだろうね。
「H.265/HEVC以外の話はするな」という謎の原理主義者が突然出てきて暴徒化したから仕方なく分けたけど、
本来求められていたのは「H.265/HEVCも含めた次世代ビデオコーデック全般について話すスレ」だと思うから、
ほとんどの人は自由なこっちに来るんじゃないかと思う・・・というかそうなってほしい。
- 27 ：名無しさん＠編集中 ：2018/01/13(土) 05:13:59.27 ID:madZEqWK0.net
- 日本からはソシオネクスト参加してんだな
- 28 ：名無しさん＠編集中 ：2018/01/13(土) 10:21:13.93 ID:vVIw/NhpH.net
- AV1の静止画規格来るかな？
- 29 ：名無しさん＠編集中 ：2018/01/13(土) 11:06:41.53 ID:P10Ob9610.net
- AV1には是非とも普及してほしい
- 30 ：名無しさん＠編集中 ：2018/01/13(土) 11:39:23.23 ID:NjvBTz8CM.net
- AOM AV1, BPG, Daala, FLIF, JPEG XR, JPEG 2000, JPEG, WebPの画像フォーマット比較
https://wyohknott.github.io/image-formats-comparison/report.html
AV1エンコードはクソ遅いけどデコードはそこそこ速い
- 31 ：名無しさん＠編集中 ：2018/01/13(土) 13:43:01.92 ID:yXA4cdiZp.net
- >>27
GoPro HERO6 の4K HEVCエンコーダチップ作ってた会社か。
- 32 ：名無しさん＠編集中 ：2018/01/13(土) 14:23:50.27 ID:K2+nuff/a.net
- ソシオネクストはパナソニックのブルーレイレコーダーとかやテレビにも使われてるはず
- 33 ：名無しさん＠編集中 ：2018/01/13(土) 15:18:51.13 ID:madZEqWK0.net
- 富士通とパナの半導体部門がくっついたものだっけ
- 34 ：名無しさん＠編集中 ：2018/01/13(土) 18:01:35.93 ID:csmv14ek0.net
- 凄いじゃん
やっぱ大きな所から切り離されると
身動き自由になるね
- 35 ：名無しさん＠編集中 ：2018/01/13(土) 19:45:14.93 ID:SIeotRKk0.net
-
■各社GPU(HWエンコーダ)でのH.265/HEVCおよびVP9のサポート状況(2018年1月中旬時点)
●Intel QSV (Kabylake＋Intel Media SDK 2017 R1)
〇HEVC
mainおよびmain10。Bフレーム使用可。
〇VP9
機能自体は搭載されているがWindowsのIntel Media SDKが未対応。
LinuxでVA-APIを使えば利用可能らしい。
https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3
●Nvidia NVEnc (Pascal＋NVIDIA Video Codec SDK 8.0)
〇HEVC
mainおよびmain10。Bフレーム使用不可。
〇VP9
未対応
●AMD VCE (Polaris＋AMF 1.4.6)
〇HEVC
mainのみ。main10は不可。Bフレーム使用不可。
〇VP9
未対応
- 36 ：名無しさん＠編集中 ：2018/01/14(日) 23:26:29.52 ID:Gf9uHeM00.net
-
2018/1/14 6:30
アップルがオープンな動画規格に参加した３つの理由 ：日本経済新聞
https://www.nikkei.com/article/DGXMZO25570100R10C18A1000000/
元記事 January 4, 2018 2:18 PM
3 reasons Apple joined the Alliance for Open Media | VentureBeat
https://venturebeat.com/2018/01/04/3-reasons-apple-just-joined-the-alliance-for-open-media/
- 37 ：名無しさん＠編集中 ：2018/01/16(火) 17:27:53.56 ID:cchnX+3f0.net
-
HEVC in HLS: 10 Key Questions for Streaming Video Developers - Streaming Media Magazine
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/HEVC-in-HLS-10-Key-Questions-for-Streaming-Video-Developers-122637.aspx
1. Which Devices Support HEVC Playback in HLS?
2. What’s the Effect on Battery Life?
3. What Does Supporting HEVC Get Me?
4. What Does HEVC Support Cost?
5. What Are the Controlling Documents I Should Get to Know?
6. I Know How to Encode with H.264. What Else Do I Need to Know to Produce HEVC?
7. What Are the Requirements for HEVC?
8. Should I Use Apple’s Suggestions Verbatim?
9. What Are My Live Options?
10. What Does the Spec Say About High Dynamic Range (HDR)?
4でH.265/HEVCのパテントプールの図や概説もあり。
http://dzceab466r34n.cloudfront.net/StreamingMedia/ArticleImages/InlineImages/114412-HEVC-HLS-Fig-1-ORG.jpg
- 38 ：名無しさん＠編集中 ：2018/01/17(水) 11:08:20.79 ID:/WkoVPL80.net
- 何でスレタイにH.265入れなかったんや
- 39 ：名無しさん＠編集中 ：2018/01/17(水) 14:23:20.86 ID:CMZcpNWj0.net
- >>38
スレタイ後半でコーデックを列挙する時に
【H.265/HEVC/VP9/AV1】
にすると、なんかH.265とHEVCがダブってるようにも見えるから、HEVCだけでいいかなーと・・・。
次スレではFVCもスレタイに入れた方がいいかもしれないし、そのへんは今後の検討項目ですかね。
- 40 ：名無しさん＠編集中 ：2018/01/17(水) 15:08:03.52 ID:rmZtXVdVd.net
- 次世代ってんだから別に何も入れない方が総合っぽいけどな
分かる奴しか来ないわけだし
- 41 ：名無しさん＠編集中 ：2018/01/17(水) 18:14:16.91 ID:CMZcpNWj0.net
- ■HTML5 各ブラウザのH.265/HEVCおよびVP9のサポート状況
●H.265/HEVC → https://html5test.com/compare/feature/video.codecs.mp4.h265.html
●VP9 → https://html5test.com/compare/feature/video.codecs.webm.vp9.html
- 42 ：名無しさん＠編集中 ：2018/01/17(水) 18:59:04.15 ID:CMZcpNWj0.net
- >>5 に書き忘れたリンク
JVET JEM software (Fraunhofer Heinrich Hertz Institute)
https://jvet.hhi.fraunhofer.de/
- 43 ：名無しさん＠編集中 ：2018/01/18(木) 01:39:05.17 ID:COlz2Rab0.net
- >>5と>>42の補足メモ。なおビルドは試していない。
software-manual.pdfを見たけど2016年8月のJEM-3.1で
ちょろっと書き換えただけっぽいので間違いもあるかも。
■FVC(Future Video Coding)のリファレンスソフトウェアJEM(Joint Exploration Model)について
JVET JEM software (Fraunhofer Heinrich Hertz Institute)
https://jvet.hhi.fraunhofer.de/
・エンコーダ(TAppEncoder)とデコーダ(TAppDecoder)が含まれており、
その時点でのFVCの参考実装を試すことができる。
・Subversionでソースを落としてきてVisualStudio2015等でビルドする。
・H.265/HEVCのリファレンスソフトウェアであったHM(HEVC Test Model)の
HM-16.6(2015/06/18)をベースに開発されている。
・元になっているHMのバージョンが古いのは、VCEGが早い時期からHM KTAとして開発していたため。
HM → HM KTA → JEM という流れになっている。
(以下2018/01/17時点)
・JEMの最新はHM-16.6-JEM-7.1(2017/10/27)。
・ちなみにHMの最新はHM-16.17(2017/10/18)。
- 44 ：名無しさん＠編集中 ：2018/01/18(木) 01:51:46.43 ID:COlz2Rab0.net
-
2018/01/11
EBU Technology & Innovation - How do AV1, JEM and HEVC compare?
https://tech.ebu.ch/news/2018/01/ebu-compares-av1-jem-and-hevc
EBU(欧州放送連合)が、ドイツの大学に委託して、UHDテストシーケンスでの
AV1、JEM(FVC)、HEVCの比較を実施。1/31に行われるセミナーで結果を発表する予定。
[Comparison of HEVC, JEM, and AV1]
In this presentation, the subjective quality of the three video coding algorithms
HEVC (High Efficiency Video Coding), JEM (Joint Exploration Model),
and AV1 (Alliance for Open Media Video 1) is compared for Ultra High Definition (UHD) test sequences.
一般人にも結果がわかるような報道とか発表があればいいんだが・・・。
- 45 ：名無しさん＠編集中 ：2018/01/18(木) 03:49:11.01 ID:COlz2Rab0.net
-
x265 rev4
http://mevius.5ch.net/test/read.cgi/avi/1511263100/55-
x265プロジェクトのトップだったMulticoreWare社のTom Vaughan氏が、ライバル社のBeamrに転職するらしい？
- 46 ：名無しさん＠編集中 ：2018/01/20(土) 02:27:53.74 ID:OGZ2RUSbM.net
- Photo format from Google and Mozilla could leave JPEG in the dust
https://www.cnet.com/google-amp/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/
Apple's got one idea for next-gen photo technology, but a rival approach based on the new AV1 video compression tech could go a step further.
HEICより15%小さい写真フォーマット計画。名前はまだ無い。
- 47 ：名無しさん＠編集中 ：2018/01/20(土) 03:19:26.83 ID:OGZ2RUSbM.net
- JPEG XLの技術公募締め切りが今年4月までなんだが
それまでにAV1策定はよ
- 48 ：名無しさん＠編集中 ：2018/01/20(土) 05:24:05.79 ID:86TUcWy60.net
- av1 jpeg 比較
https://people.xiph.org/~tdaede/av1stilldemo/
- 49 ：名無しさん＠編集中 ：2018/01/20(土) 18:18:49.86 ID:XIH6s3g30.net
- 補足
>>48は>>46の記事で紹介されてるリンクで、複数の画像について AV1/x265/JPEG/Original の比較が可能。
- 50 ：名無しさん＠編集中 ：2018/01/20(土) 18:31:45.29 ID:XIH6s3g30.net
- Bitmovin社のAV1への取り組み
AV1 - Bitmovin
https://bitmovin.com/av1/
AV1 Datasheet - Bitmovin
https://bitmovin.com/av1-datasheet/
Bitmovin-AV1.pdf
https://bitmovin.com/whitepapers/Bitmovin-AV1.pdf
>>14で
「AV1の1080pのリアルタイムエンコードに200コア使ってたが8-32コアでできるようになるだろう」
とあったけど、上の資料や下の記事にあるように、その直後の2017/9/13-18のIBC2017で、
AV1/1080p30/1.5Mbpsのリアルタイム配信を32コアでやってた模様。
A Constantly Evolving Video Landscape on Display at IBC 2017 - Bitmovin
https://bitmovin.com/constantly-evolving-video-landscape-display-ibc-2017/
- 51 ：名無しさん＠編集中 ：2018/01/20(土) 23:01:56.35 ID:rS9bZFf+H.net
- AV1が新jpegになるかな
- 52 ：名無しさん＠編集中 ：2018/01/20(土) 23:16:01.06 ID:XIH6s3g30.net
- HEVCエンコーダ製品等を展開するBeamr社のブログより
2017/7/13
Comparing HEVC & VP9 Made Easy
http://blog.beamr.com/2017/07/13/comparing-hevc-vp9/
・VP9、HEVC、AVCを機能面から比較した、
下記タイトルのホワイトペーパー(PDF)をダウンロード可能。
「Choosing the Right Compression Technology ? Comparing VP9, AVC, and HEVC.」
2018/1/6
HEVC today. AV1 tomorrow?
http://blog.beamr.com/2018/01/06/hevc-today-av1-tomorrow/
・AppleのAOMedia参加を受けての記事。HEVCとAV1の比較や問題点等。
- 53 ：名無しさん＠編集中 ：2018/01/22(月) 08:41:50.60 ID:lSoEz2bj0.net
- 久々にAV1ビルドしようと思ったらcmakeとnasmが必要になってたのね
前はcwgwinだけで超簡単にビルド出来てたのに通らなくなってて焦ったわ
- 54 ：名無しさん＠編集中 ：2018/01/22(月) 18:30:14.50 ID:RJV+YfJ/0.net
- うちでcmakeを実行するとaom/build/cmakefiles/cmaketmp/の下に出来る実行ファイルを
Norton先生が遮断or削除するんだよなあ・・・。とりあえず一応ビルドは出来るので放置してるけど。
- 55 ：名無しさん＠編集中 ：2018/01/23(火) 00:55:18.65 ID:1u99Hw3q0.net
- ITUジャーナル | ITU-AJ
https://www.ituaj.jp/?post_type=itujournal
※次世代コーデックスレ的に関係ありそうな内容だけを抜粋。
※ITU-T SG16は、マルチメディア関連の標準化をしているグループ
ITU-T Study Group 16 - Multimedia coding, systems and applications
https://www.itu.int/en/ITU-T/about/groups/Pages/sg16.aspx
●ITU-T SG16 第1回会合の結果概要 (2017年5月号。会合は2017年1月)
https://www.ituaj.jp/wp-content/uploads/2017/05/2017_05-08-Kaigou-ITUTSG16.pdf
・H.264(V12)の合意
・HDR関連文書の承認
・FVC関連文書の承認
・JCT-VCとJVETの会合
・FVCは前回会合から2%程度の符号化効率改善。
今回4つの改善提案の採用で更に2〜3%の改善を期待。
- 56 ：名無しさん＠編集中 ：2018/01/23(火) 00:56:30.82 ID:1u99Hw3q0.net
- ●ITU-T SG16 第2回会合の結果概要 (2018年1月号。会合は2017年10月)
https://www.ituaj.jp/wp-content/uploads/2018/01/2018_01-09-Kaigou-ITUTSG16.pdf
・H.265(V5)の合意
（モノクローム10およびメイン10静止画プロファイルの追加など）
・HDR関連文書の承認
・JVETの下、H.265を越える次世代映像コーデック(FVC)に向け、
MPEGとの協力を正式に開始
(2015年10月に始まった共同検討の成功を受けたもの)
・JVETは現在、通常のカメラの映像だけでなく、
360度全方位カメラの映像や、高ダイナミックレンジのカメラの映像を
対象とする、共同の提案要求を出している。
・JCT-VCとJVETの会合
・H.265/HEVCが第69回Engineering Emmy Awards（技術・工学エミー賞）を受賞
https://www.emmys.com/news/awards-news/engineering-awards-170927
- 57 ：名無しさん＠編集中 ：2018/01/23(火) 06:44:09.33 ID:E8QTtu350.net
- 静止画でjpegより高画質な物はもう売るほどあるけど全く流行らん不思議
エンコード・デコードを安価な1チップで高速実行できるようにならないと無理？
- 58 ：名無しさん＠編集中 ：2018/01/23(火) 08:06:09.52 ID:aPpVUCAU0.net
- >>57
多少性能が上なくらいじゃ置き換えるまでは行かないだろうね
webpなんかも、いつも使ってる画像編集ソフトで開けないって大不評だったし
- 59 ：名無しさん＠編集中 ：2018/01/23(火) 08:14:11.75 ID:aPpVUCAU0.net
- イラストなんかだと5分の1くらいまで圧縮出来るようなケースも結構あるけど写真だと良くて2〜3割くらいしか縮まないし
- 60 ：名無しさん＠編集中 ：2018/01/23(火) 09:31:35.72 ID:Sc6kE1330.net
-
【ミニトピ】iOS 11の写真/動画形式「HEIF」と「HEVC」。従来とは何が違う? - AV Watch Watch
https://av.watch.impress.co.jp/docs/topic/minitopi/1098867.html
>HEIF自体はファイルフォーマット(コンテナ)であり、
>その画像の圧縮方式には複数の技術が規定されている。
>圧縮方式にHEVCの技術を使った場合、ファイルの拡張子は.heicになり、
>（中略）
>H.264を使えば.avci、その他の方式を使うと.heifになる。
このへんよく知らなかった。
- 61 ：名無しさん＠編集中 ：2018/01/23(火) 18:30:59.95 ID:PocNlfHu0.net
- >>60
これは参考になった
- 62 ：名無しさん＠編集中 ：2018/01/23(火) 19:51:56.87 ID:GoujBY/y0.net
- HEIFにAV1入れるフォーマットも草案中らしい
https://github.com/AOMediaCodec/av1-avif
- 63 ：名無しさん＠編集中 ：2018/01/23(火) 22:33:11.48 ID:JSzcjXLFM.net
- AppleがHEIF
GoogleがRIFF
MSがTIFF
コンテナ三国志
- 64 ：名無しさん＠編集中 ：2018/01/23(火) 22:44:50.68 ID:JSzcjXLFM.net
- JPEGが次世代規格に置き換わらなかった要因
https://news.mynavi.jp/article/jpeg-6/
JPEGとの互換性が鍵
- 65 ：名無しさん＠編集中 ：2018/01/23(火) 23:13:37.90 ID:JSzcjXLFM.net
- https://news.mynavi.jp/article/jpeg-2/
＞JPEGの兄弟のようなMPEGという動画の規格があるのですが、参加している企業の特許が入ると、その企業に規格の利用料が払い込まれます。ビデオやブルーレイなどの再生機器には規格の利用料が1台ごとにかかって、それが製品代に含まれています。
利用料を集めて各企業に再分配する組織(ライセンスプール)があるんです。そのため、MPEGは参加して決定することで利益があがるという方針なんです。
＞一方、JPEGは基本方式を使うことに関しては無料(ロイヤリティーフリー)です。無料であることによって広まり、対応する機器の台数が増える、すなわち市場が拡大することによって、自分たちの製品が売れるという考え方なんです。
デジカメでの成功例がまさにそうですね。もしJPEGが有料であったなら、また違った結果になったかもしれません。
標準化機構JPEG
利権団体MPEG
- 66 ：名無しさん＠編集中 ：2018/01/24(水) 18:47:01.61 ID:SgH0BEWCM.net
- heifってコンテナだったのか
bpgみたいなものだと思っていたわ
- 67 ：名無しさん＠編集中 ：2018/01/24(水) 21:04:43.12 ID:V85qcpcr0.net
- Survey: The Impact of Apple's HEVC Adoption
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Survey-The-Impact-of-Apples-HEVC-Adoption-122654.aspx
AppleがHLSにHEVCを追加した件の影響などについてのアンケート調査レポート。
記事にある内容だけを大雑把に言うと
・HEVCの配信採用は進みそうだが不明瞭なロイヤリティコストへの懸念があるのでなんとかしろ。
・AV1での配信も注目されているが品質・再生パフォーマンス・エンコード時間への懸念がある。
一方でAV1の潜在的な知的財産絡みの問題を懸念している人は比較的少ないようだ。
・HDRの配信も進みそうだ。
といったところかな？詳細PDFのダウンロードは要登録なのでそちらは見てない。
- 68 ：名無しさん＠編集中 ：2018/01/24(水) 23:11:18.83 ID:kZ76jG8Z0.net
- 結局、次世代規格はどれが一番良いんだ…
もちろん動画の種類にもよるだろうが、HEVC一本で管理し始めても大丈夫かね
- 69 ：名無しさん＠編集中 ：2018/01/24(水) 23:58:04.56 ID:bailDe6M0.net
- 当然、HEVCだよ
今更他の規格がいきなり標準になる事はないでしょ
- 70 ：名無しさん＠編集中 ：2018/01/25(木) 07:23:07.24 ID:X7EaTpdS0.net
- AV1は再生は軽いの？
そのうちインテルのQSVになったりしないかなー
- 71 ：名無しさん＠編集中 ：2018/01/25(木) 08:08:35.94 ID:B1Tlv2QT0.net
- お前大好きだもんなAV1
- 72 ：名無しさん＠編集中 ：2018/01/25(木) 09:06:57.23 ID:SRg0RvRUM.net
- アップルがAOMに入ったことでブラウザベンダー全てがAOMメンバーになったからウェブではAV1が確実に広まるだろうな
ウェブ以外だとHEVCのほうが強そう
- 73 ：名無しさん＠編集中 ：2018/01/25(木) 09:38:51.06 ID:LmGDgiSW0.net
- >>68
個人の使用用途ではHEVCがいいだろうね
VP9なんかでもそうだけどロイヤリティフリーなコーデックってエンコードが無茶苦茶遅いから演算コストかけてでも莫大な転送量と特許使用料を減らしたい企業にしかメリット無い
- 74 ：名無しさん＠編集中 ：2018/01/26(金) 21:23:54.36 ID:dPRLyDJW0.net
- https://twitter.com/yoya/status/956469309185732608
>pixiv社内でのHEIF画像ファイル調査結果を話して良いとの事なのでスライド資料を作りました。
>これの倍は書きたかったけど1時間でも足りなくなるので内容をかなり絞ってます
>(画質検証や派生ロールとか大事なのだけど今回は無しで)
HEIF解説 〜コンテナ構造の実際〜
https://speakerdeck.com/yoya/heif-kaisetsu
- 75 ：名無しさん＠編集中 ：2018/01/28(日) 13:12:05.74 ID:cspIlirf0.net
- AV1 Bitstream & Decoding Process Specification
Last modified: 2018-01-25 18:42:22 -0800
https://aomediacodec.github.io/av1-spec/
- 76 ：名無しさん＠編集中 ：2018/01/28(日) 14:42:38.32 ID:XZI76zH20.net
- >>75
仕様がFIXしたのかと思ったけど、そうじゃなくてドキュメントの更新があったってことかな。
- 77 ：名無しさん＠編集中 ：2018/01/29(月) 10:21:09.51 ID:1s1l1uzJH.net
- 一月もそろそろ終わるのにまだ完成しないのか
- 78 ：名無しさん＠編集中 ：2018/01/29(月) 16:34:46.10 ID:AFlt17RV0NIKU.net
- これだけ世界中のITと半導体の大手が集まってもなかなか完成しないもんなんだな
- 79 ：名無しさん＠編集中 ：2018/01/31(水) 13:16:03.21 ID:7Vo0SVq6a.net
- 特許回避がだるすぎるから仕方ないわ
- 80 ：名無しさん＠編集中 ：2018/01/31(水) 22:32:23.64 ID:rZJ4njBN0.net
- モスクワ大学(MSU)が1/22に「HEVC Video Codecs Comparison 2017」を更新。
VP9やAV1との比較を行った。記事では昨年12月の主観評価レポートにも触れている。
AV1 Beats VP9 and HEVC on Quality, if You've Got Time, says Moscow State
http://www.streamingmedia.com/Articles/News/Online-Video-News/AV1-Beats-VP9-and-HEVC-on-Quality-if-Youve-Got-Time-says-Moscow-State-122945.aspx
HEVC Video Codecs Comparison 2017
http://www.compression.ru/video/codec_comparison/hevc_2017/
- 81 ：名無しさん＠編集中 ：2018/01/31(水) 22:33:26.04 ID:rZJ4njBN0.net
- >>80
-------
その１
-------
■VP9やAV1との比較。主観評価じゃなくYUV-SSIMでの指標評価。
AV1 0.1.0(Rev. c8b38b0bfd36) ←2017年6月末頃
VP9 v1.6.1-433-g6af42f5 ←2017年4月頭頃
x264 r2833 df79067 ←2017年5月末頃
x265 1.9+169-e5b5bdc3c154 ←2016年7月末頃(妙に古い)
●品質：x264と同等の画質を何%のビットレートで得られるか
AV1： 55%
x265(3pass/placebo)： 67%
x265(2pass/placebo)： 69%
VP9： 72%
x265(2pass/veryslow)： 75%
●エンコード速度(他と比べて)
・x265の2or3pass/placeboは10〜15倍の時間がかかる(実用域ではない)
・AV1は2500〜3000倍の時間がかかる（実用どころじゃない）
●その他
・実用域だとVP9の方がHEVCよりいい感じ。
・AV1とVP9はレート制御甘すぎじゃね？(目標ビットレートとのズレ)
- 82 ：名無しさん＠編集中 ：2018/01/31(水) 22:39:03.58 ID:rZJ4njBN0.net
- >>80
-------
その２
-------
■Subjectify.usっていう主観評価のサービス作ったんで
それを踏まえて各種HEVCエンコーダを比較してみたよ。(昨年12/1のレポート)
●HEVCエンコーダの比較結果
・Kingsoft HEVC Encoder ってのがx265より良い結果になったらしい。
よくわからんけど、これのことだろうか？
https://github.com/ksvc/ks265codec
●Subjectify.usについて
・NetflixのVMAFよりうまくできてるぜ！(自画自賛)
●x264/x265の--tune ssimと主観評価
・x264/x265で --tune ssim にしたらpsy-rdとかがオフになるから
主観評価は下がると思ったんだけど、むしろ上がった。
・でも1080pで1〜4Mbpsという低めのビットレートなのが原因かも。
・x264の開発者によるとpsy-rdは高ビットレート域での改善に使うものらしい。
あと--tune ssimでは--aq-modeがデフォルトのVAQからAutoVAQに変わる。
AutoVAQはある程度自動調整されるのでそれが良い方向に働いたのかも。
VAQは調整次第でAutoVAQより良くなるけどソース毎の調整が必要。
- 83 ：名無しさん＠編集中 ：2018/01/31(水) 22:56:41.27 ID:eOZMmYYr0.net
- 3000倍w
- 84 ：名無しさん＠編集中 ：2018/01/31(水) 23:32:48.84 ID:cxYOVtKt0.net
- 2500〜3000倍か…時間がかかりすぎるどころの話じゃないな…
- 85 ：名無しさん＠編集中 ：2018/02/01(木) 01:22:12.74 ID:fOx/lWw20.net
- ストリーミング動画の流れによって曲がり角を迎えるMPEGについて「MPEGの父」は何を思うのか？
http://gigazine.net/news/20180130-leonardo-chiariglione-mpeg-crisis/
- 86 ：名無しさん＠編集中 ：2018/02/01(木) 03:11:38.39 ID:7cPD62CfH.net
- >>81
最新のAV1エンコーダは早くなってなかった?
- 87 ：名無しさん＠編集中 ：2018/02/01(木) 05:41:50.88 ID:ngIxmbWHM.net
- エンコードが激重でも有意に縮めば適当な所でgoサイン出るかもね
youtubeやnetflixみたいな大規模配信サイトならアクセス多い動画だけでも縮めばメリット大きい
デコーダーはアプリに組み込めばいいから対応も楽だし
- 88 ：名無しさん＠編集中 ：2018/02/01(木) 05:43:07.57 ID:rNS8DDep0.net
- HEVCもリファレンス実装の時はエンコード遅くてx265が最適化しまくって早くなったけどAV1はどのくらい高速化する余地があるんだろ
圧縮率から考えてHEVC以上の計算量は確実でそれ以上に早くなる事はないだろうけど
- 89 ：名無しさん＠編集中 ：2018/02/01(木) 06:12:19.88 ID:g6ukHWtd0.net
- The fastest and worstest AV1 compressor.
https://github.com/tdaede/rav1e
- 90 ：名無しさん＠編集中 ：2018/02/01(木) 09:22:07.45 ID:ndVQlX4qM.net
- libvp9より20%圧縮率が高く20%高速かつ
x265より10%圧縮率が高く25%高速なVP9エンコーダ
https://www.twoorioles.com/eve-for-vp9
- 91 ：名無しさん＠編集中 ：2018/02/01(木) 18:02:44.21 ID:tMorYit7H.net
- >>90
肝心の画質はどうなのかな？
画質が落ちるようなら今まで通りx265のソフトウェアエンコードを選ぶし。
- 92 ：名無しさん＠編集中 ：2018/02/01(木) 18:35:23.26 ID:ZXxuK7hv0.net
- >>82
ks265codecっていうの試してみようと思ったけどパイプ入力も出来ないから使い勝手悪いな
issue見てもkingsoftの許可が無いとパイプ入力実装出来ないみたいな事言ってるし使用制限版って感じやな
ちゃんとした製品版もあるんかな
- 93 ：名無しさん＠編集中 ：2018/02/01(木) 21:09:00.28 ID:o44JhFKja.net
- >>90
評価版もないやん
- 94 ：名無しさん＠編集中 ：2018/02/02(金) 20:28:12.47 ID:PdRQXRFX00202.net
- >>44にある、「UHDサンプルでのAV1、JEM、HEVCの主観評価」だけど、Twitterで部分的な情報を見る限りでは
JEM ＞ HEVC ＞ AV1
という結果になったっぽい？詳細な条件とかは不明だけど・・・。
ParkDancersサンプルでのMOS(Mean Opinion Score)グラフ
https://twitter.com/HoffmannHans/status/958677064013570048
BuildingHalllサンプルでのMOSグラフ
https://twitter.com/JYA_35/status/958678591029563394
> today at the EBU conference, results were publicly presenting
> HEVC superior to AV1. ・・・
https://twitter.com/thierryfautier/status/958779824314638336
イベントのサイトに動画とスライドが置かれてるけど、残念ながら有料登録者しか見れないようだ。
https://tech.ebu.ch/pts2018
- 95 ：名無しさん＠編集中 ：2018/02/04(日) 13:41:51.60 ID:2klfab9Z0.net
- Firefoxは既にAV1をデコードできるらしいな
- 96 ：名無しさん＠編集中 ：2018/02/04(日) 16:29:32.28 ID:XUqQD2miH.net
- そういやそうだったな
なんか適当な小さめのAV1動画ある？
- 97 ：名無しさん＠編集中 ：2018/02/04(日) 21:00:01.16 ID:oULuZG0G0.net
- >>95-96
今のところAV1のデコードができるのはFirefox Nightlyのみ。
●2017/11/28のMozillaの記事
DASH playback of AV1 video in Firefox - Mozilla Hacks - the Web developer blog
https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/
●AV1 デモサイト
AV1 Demo by Mozilla and Bitmovin
https://demo.bitmovin.com/public/firefox/av1/
・Firefox Quantum 58.0.1 では以下が表示されて視聴不可。
This browser does not seem to support (this version of) AV1, please try Firefox Nightly.
・Firefox Nightly 60.0a1 なら視聴可。以下は記事ページのwe can report:のところの判定。
This browser supports AV1! It recognized the media type(s):
video/webm; codecs="av1"
video/webm; codecs="av1.experimental.e87fb2378f01103d5d6e477a4ef6892dc714e614"
- 98 ：名無しさん＠編集中 ：2018/02/04(日) 21:10:01.86 ID:oULuZG0G0.net
- 2018/2/3〜2018/2/4 FOSDEM 2018 - AV1 Codec Update
https://fosdem.org/2018/schedule/event/om_av1/
（★多分後日スライドのPDFとかが置かれると思う。
昨年の例→ https://archive.fosdem.org/2017/schedule/event/om_av1/）
動画：
AV1 Codec Update - YouTube
https://www.youtube.com/watch?v=6UksCRCl_bI
概要
●2/2にビットストリーム仕様をFIXする予定だったけど、無理だったわｗ
●主な残課題
・Fix remaining problems with TXMG
・Final details of high-level syntax
・Last-minute changes to MV prediction
・Fix all of the bugs
・IPR analysis
●あとは技術的な説明
- 99 ：名無しさん＠編集中 ：2018/02/06(火) 13:04:20.30 ID:146dcEH50.net
- >>98のサイトにスライドのPDFが追加されてた。
av1update.pdf
https://fosdem.org/2018/schedule/event/om_av1/attachments/slides/2639/export/events/attachments/om_av1/slides/2639/av1update.pdf
- 100 ：名無しさん＠編集中 ：2018/02/06(火) 23:20:13.80 ID:fykcdiAe0.net
- ネットワークカメラのリリースニュースで「H.265+」という謎ワードが出てたから何だそれと思って調べてみたら、
HIKVISIONという会社が定点カメラ用（背景がほぼ変化しない）に最適化したものをそう呼んでるというだけだった。
H.264比で79.4〜82.5%のサイズ減、H.265比で64.5〜66.4%減だそうな。
H.265+ Takes Video Surveillance to the 4K Era
http://www.hikvision.com/en/Press-Release-details_74_i1496.html
- 101 ：名無しさん＠編集中 ：2018/02/07(水) 00:02:51.66 ID:yGFAIvr30.net
- ほぼ動かないんだから、そりゃ縮まなきゃ困るわな
- 102 ：名無しさん＠編集中 ：2018/02/07(水) 12:33:26.38 ID:0W93IvP+H.net
- 静止画規格だけでもはやくでてくれないかな
- 103 ：名無しさん＠編集中 ：2018/02/08(木) 17:12:22.15 ID:ahLHH27w0.net
- Appleも加わったオープンソース動画コーデック「AV1」は本当に業界スタンダードの座を奪えるのか？
http://gigazine.net/news/20180208-av1-near-future/
- 104 ：名無しさん＠編集中 ：2018/02/08(木) 20:03:05.72 ID:i8zx3TpAd.net
- H.266は語呂悪いし、ワンチャンあるかもな
- 105 ：名無しさん＠編集中 ：2018/02/08(木) 20:57:05.60 ID:VcL1Sni00.net
- HEVCみたいな別名称がつくのでなかろうか
- 106 ：名無しさん＠編集中 ：2018/02/08(木) 21:16:35.59 ID:JA459s+50.net
- FVCっていうのはまだ仮称？
- 107 ：名無しさん＠編集中 ：2018/02/09(金) 09:12:25.64 ID:tyWh3yoKM.net
- >>103
最適化されてもHEVCの10倍複雑でエンコに時間がかかるっていうのはいわゆる全ての機能を使ったhighプロファイル的な状態なのかな?
機能制限してライブ配信等々を目的とした現行のx265並みの負荷で同等の動画出力ってのは構想にあるんだろうか?
OSSみたいだし誰かが勝手にフォークして本体に取り入れられたりみたいな流れになるんかな
- 108 ：名無しさん＠編集中 ：2018/02/09(金) 23:14:24.01 ID:3L7c9fII0.net
- >>104-106
標準化の仕組みをちゃんと理解してないけど、FVCは今の段階では識別名だったりプロジェクト名だったりで、
標準化が確定したら正式名称になるんじゃないかな。
Requirementの文章を見ると、FVCは新しい標準としてではなく、HEVCの拡張の１つとして標準化されることも
ありえると書いてるようだけど、順当に標準化が進んでいけばH.266/FVCになる可能性が高いんじゃないだろうか。
ITU的には標準化が確定するまでH.266という表現はできないので、H.FVCと呼ぶ感じかな。
- 109 ：名無しさん＠編集中 ：2018/02/09(金) 23:15:19.07 ID:3L7c9fII0.net
- >>108の参考リンク
H.FVC (ITU-T Work Programme)
https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=13325
JVET - Joint Video Experts Team
https://www.itu.int/en/ITU-T/studygroups/2017-2020/16/Pages/video/jvet.aspx
Requirementsより
---
The following document contains requirements for the first phase of
a potential Future Video Coding ("FVC") video coding standardization project.
The "FVC" project will develop a new Recommendation | International Standard
(identified in the current Q6/16 work programme as “H.FVC”)
or an extension of HEVC (ITU-T Rec. H.265 | ISO/IEC 23008-2),
depending on which form of standardization is determined to be appropriate for the technology design.
---
- 110 ：名無しさん＠編集中 ：2018/02/10(土) 01:30:16.19 ID:6hw14jOB0.net
- VP9のエンコードも相当時間かかるのにYoutubeのあの量とあの解像度のVP9をあんなに短時間でどうやってエンコードしてんだろ
- 111 ：名無しさん＠編集中 ：2018/02/10(土) 03:03:20.61 ID:5IskUt/U0.net
- >>110
http://mevius.5ch.net/test/read.cgi/avi/1485191956/223-224
223名無しさん＠編集中 (ﾜｯﾁｮｲ 271f-RZRQ)2017/04/15(土) 00:02:00.70ID:HbkQRrYn0
VP9ってあんだけ時間かかるのにYoutubeで使われてるVP9はどうやってあんな膨大の量の動画をVP9でエンコしてんの？クラスタ？
224名無しさん＠編集中 (ﾜｯﾁｮｲ 5f72-pzmP)2017/04/15(土) 00:46:11.32ID:5LrEp1qT0
>>223
What Does YouTube Do To Your Video After You Upload It? - YouTube
https://www.youtube.com/watch?v=aFLU6T15seY
分割処理っぽいね
- 112 ：名無しさん＠編集中 ：2018/02/10(土) 11:34:00.92 ID:5Si4CN6e0.net
- VLC 3.0.0 リリース
https://www.videolan.org/vlc/releases/3.0.0.html
HEVC hardware decoding
Experimental AV1 video and Daala video decoders
- 113 ：名無しさん＠編集中 ：2018/02/10(土) 19:42:01.56 ID:KDMWZm0i0.net
- >>112
うーん、AV1はまだ仕様固まってないから、どのコミットが使われてるのか知りたいんだが
どこを見れば書いてあるんだろう・・・。
- 114 ：名無しさん＠編集中 ：2018/02/11(日) 09:56:37.86 ID:/jeTz4cX0.net
- Stand by for H.266 compression
https://advanced-television.com/2018/02/01/stand-by-for-h-266-compression/
FVC/H.266 Development Schedule
Standardisation process has started
Target >50 per cent over HEVC
Oct 2017, Call for Proposals
Feb 2018, Responses evaluation
Oct 2018, First test models due
Oct 2019, First versions of Standard
End 2020, Final Standard
June 2021, First hardware Codecs
- 115 ：名無しさん＠編集中 ：2018/02/11(日) 15:45:14.98 ID:fbl1P7Tq0.net
- デコードのほうは
intel Kaby以降
NVIDIA 10x0以降
AMD 全滅
でいいのかい?
- 116 ：名無しさん＠編集中 ：2018/02/11(日) 16:09:15.55 ID:C+fyqL0s0.net
- AMDってAOMediaに加盟してるのにデコード出来ないのか？
- 117 ：名無しさん＠編集中 ：2018/02/11(日) 16:40:33.52 ID:NeI0BMkJ0.net
- シェーダーだけだからキツいね
Ryzen買えよってことかもw
- 118 ：名無しさん＠編集中 ：2018/02/11(日) 17:28:03.21 ID:jAmtemHi0.net
- GM206は対応してるGTX960,950
- 119 ：名無しさん＠編集中 ：2018/02/11(日) 18:19:24.41 ID:14BIkobe0.net
- >>115-118
多分H.265/HEVCの話なんだろうが、どのコーデックの話なのかちゃんと書かないと話が行き違うやろ。
■各社GPUでのハードウェアエンコード/デコードについて
※エンコードについては>>35も参照
●Intel
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
●NVIDIA
https://developer.nvidia.com/nvidia-video-codec-sdk
エンコード： https://en.wikipedia.org/wiki/Nvidia_NVENC
デコード： https://en.wikipedia.org/wiki/Nvidia_PureVideo
●AMD
エンコード： https://en.wikipedia.org/wiki/Video_Coding_Engine
デコード： https://en.wikipedia.org/wiki/Unified_Video_Decoder
- 120 ：名無しさん＠編集中 ：2018/02/11(日) 18:33:52.65 ID:fbl1P7Tq0.net
- YouTubeガクガクVP9でしょ
AMDが出来ると言って出来てない奴といえば、これが一番遭遇率が高い筈
- 121 ：名無しさん＠編集中 ：2018/02/11(日) 20:45:53.51 ID:QWMUaHuD0.net
- GPUを利用したソフトウェアデコードとかすれば、専用デコーダ積んでなくても早くなるとかならないもんかな
- 122 ：名無しさん＠編集中 ：2018/02/11(日) 22:21:56.05 ID:14BIkobe0.net
- >>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公式からの発表は一切無い（？）
- 123 ：名無しさん＠編集中 ：2018/02/11(日) 23:19:48.33 ID:z7SnhiMV0.net
- たぶんあってるはず
自作PC板でも同じ報告があった
- 124 ：名無しさん＠編集中 ：2018/02/12(月) 00:11:03.60 ID:5x8wkHrd0.net
- これは機能は実装したけど致命的なバグがあって使い物にならない代物だったということかな?
いくらなんでも時間的にもう無理な頃合いだよね
- 125 ：名無しさん＠編集中 ：2018/02/12(月) 01:47:14.53 ID:wdHXLY1i0.net
- そういえば>>112-113の VLC 3.0.0 でのExperimentalなAV1デコードの話は、
liaomをビルドした上でVLCを--enable-aom付きでビルドすればできるよというだけらしい。
公式ビルドは対応してないようで、av1.webmを再生しようとすると以下のエラーになった。
コーデックがサポートされていません。:
VLCは形式 "av01" (AOMedia's AV1 Video) をデコードできませんでした。
- 126 ：名無しさん＠編集中 ：2018/02/12(月) 17:21:06.04 ID:J1qpkTY80.net
- xvc codec
https://xvc.io/
Royalty based next-generation video codec.
Compression performance beyond HEVC.
- 127 ：名無しさん＠編集中 ：2018/02/12(月) 19:40:39.87 ID:eKhne4ga0.net
- >>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のライセンスを買えば、後はうちがやるから特許侵害とか一切気にしなくていいぜ！」
という、攻めてるライセンス形態が、いろんな意味でドキドキ感に溢れている。
- 128 ：名無しさん＠編集中 ：2018/02/12(月) 19:57:01.01 ID:XChgmp2Ka.net
- 潰されるのが目に見えている
- 129 ：名無しさん＠編集中 ：2018/02/12(月) 23:33:26.69 ID:eKhne4ga0.net
- >>126
いくつか記事があった。
Divideon Creates xvc, an HEVC Codec With Reasonable Pricing - Streaming Media Magazine
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Divideon-Creates-xvc-an-HEVC-Codec-With-Reasonable-Pricing-122180.aspx
Call for Patents in xvc | Feb 8, 2018 - ReleaseWire
http://www.releasewire.com/press-releases/call-for-patents-in-xvc-929388.htm
- 130 ：名無しさん＠編集中 ：2018/02/13(火) 13:35:49.99 ID:MqWcVoGB0.net
- >>129
Jonatan Samuelsson@JonatanDivideon
元々EricssonでHEVCをやってた人みたい。そこを飛び出して新たに始めるとかハッカーっぽくて好き。
- 131 ：名無しさん＠編集中 ：2018/02/14(水) 19:03:38.62 ID:r7PseLFEMSt.V.net
- mpeg-2特許切れ@米国
- 132 ：名無しさん＠編集中 ：2018/02/15(木) 03:04:33.73 ID:0dI75nRxM.net
- mp3とac3も最近特許切れになってたよね
- 133 ：名無しさん＠編集中 ：2018/02/15(木) 17:05:53.05 ID:dWlqp1Yu0.net
- ついに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日にアメリカ国内で残っていた最後の特許が期限切れを迎えたことを明らかにしました。
（ ＾ω＾）
- 134 ：名無しさん＠編集中 ：2018/02/17(土) 03:40:37.42 ID:hqYzXLDq0.net
- AV1は別にHEVC超えなくて同じくらい狙えばよかったんじゃないの？？
同じくらいだとパンチ弱くてすでに普及が進んでるHEVCがあるから、
AV1の普及進まないとみてHEVC越えねらったのかな？
- 135 ：名無しさん＠編集中 ：2018/02/17(土) 04:05:24.29 ID:hqYzXLDq0.net
- あれか、AV1がHEVCと同じくらいだとひょっとして世代的にVP9と同じになちゃうのかな？・・
- 136 ：名無しさん＠編集中 ：2018/02/17(土) 11:48:51.35 ID:h/nUC7SG0.net
- つーかDLすると264もVP9も大差無いんだが
どうなってるんだｗ
- 137 ：名無しさん＠編集中 ：2018/02/17(土) 16:12:26.51 ID:LDzeOJ530.net
- >>136
Youtubeの話かな？「大差ない」と言うのは何を基準にして言ってる？
確かにモノによってはVP9もH.264もファイルサイズ(ビットレート)が同じくらいだったり
むしろVP9の方がでかくなってることもあるし、結局VP9も割とビットレートでゴリ押ししてる感はあるけど、
画質とビットレートのバランスを考慮して比較しないと意味ないぞ。
それに今のYoutubeは1440pより上は一部を除いてVP9だけになってるから高解像度での比較はできないし。
- 138 ：名無しさん＠編集中 ：2018/02/17(土) 20:56:16.18 ID:G3h+KrxD0.net
- 4320p60fpsの動画つべに上げてみたがローカルh264の半分強の負荷で再生出来たのはその為か
再生支援か元々のデコーダが素晴らしいのか知らんけどVP9悪く無いなぁ
- 139 ：名無しさん＠編集中 ：2018/02/17(土) 22:00:03.40 ID:LDzeOJ530.net
- >>138
使ってるGPUは？
H.264の再生支援は4Kまでだけど、HEVCやVP9はGPUによっては8Kもサポートしてるから、そのせいかもね。
DXVAChecker画像
Intel UHD 630 → https://forum.doom9.org/showthread.php?p=1822311#post1822311
GeForce GT1030 → https://forum.doom9.org/showthread.php?p=1810780#post1810780
- 140 ：名無しさん＠編集中 ：2018/02/17(土) 23:17:22.99 ID:LDzeOJ530.net
- 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のリファレンスモデル。
- 141 ：名無しさん＠編集中 ：2018/02/17(土) 23:18:24.56 ID:LDzeOJ530.net
- 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はあと数週間で仕様が固まるらしいけどエンコードの計算コストがめっちゃ高くて大変。
仕様決定したら今度は死ぬ気で効率を上げる努力をしていかなきゃなんねえ。
- 142 ：名無しさん＠編集中 ：2018/02/17(土) 23:52:51.69 ID:LDzeOJ530.net
- >>140訂正
× HMはVP9と比べるとエンコード速度は3.4倍だが
〇 HMはVP9と比べるとエンコード速度は3.4倍遅いが
- 143 ：名無しさん＠編集中 ：2018/02/18(日) 16:02:09.17 ID:TUowvH/t0.net
- 映像業界に潜伏してるエロイ人に質問です
静止画の画質って色調チェックにはカラーバーとか
解像度チェックのいっぱい直線や曲線が引かれたチャートがあるけど
動画の動きの画質比較用で風景とか人物とかじゃなく
幾何学的な映像で業界標準的なものってあるの?
- 144 ：名無しさん＠編集中 ：2018/02/18(日) 17:46:31.09 ID:SFAAnmQA0.net
- >>139
GTX1080のEVGAのFTW？だからちょいOCモデルかな
と一応CPUは5960Xの4.3Ghz
CPU負荷7〜8割から4割程度まで下がった
- 145 ：名無しさん＠編集中 ：2018/02/19(月) 06:28:27.03 ID:FlX1XD9/0.net
- 【2018】 H.265/HEVC Part8 【7680x4320】 スレから誘導させてもらいました
現在NVEncCでHEVCエンコードを行っているのですが
x264の--crf 20に相当するNVEncCの--cqpの値はどの程度のものなのでしょうか？
- 146 ：名無しさん＠編集中 ：2018/02/19(月) 08:05:21.78 ID:K9tuILFw0.net
- 規格もエンコーダーも違うから答えられる人間は存在しない
- 147 ：名無しさん＠編集中 ：2018/02/19(月) 10:55:10.75 ID:f9LdXxV20.net
- >>145
前にSSIMで比較してみた人がいるからそれを参考にするとか
http://mevius.5ch.net/test/read.cgi/avi/1486130737/335
まあ数字をちょっとずつ調整していって目視で確認するのが一番だろうけど
- 148 ：名無しさん＠編集中 ：2018/02/19(月) 11:30:24.02 ID:FlX1XD9/0.net
- >>147
レスありがとうございます
ざっくりですが x264の3/5くらいのビットレートを目標に--cqpの値を変化させてみます
- 149 ：名無しさん＠編集中 ：2018/02/19(月) 19:18:14.94 ID:mdvnxdra0.net
- 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
- 150 ：名無しさん＠編集中 ：2018/02/20(火) 07:42:36.96 ID:0/pOXWUN0.net
- ドイツでは2018年4月25日から地上波がMPEG2からHEVCになるって。知らんかった。
DVB-T2 HD 1080p50 HEVC
http://www.dvb-t2hd.de/
- 151 ：名無しさん＠編集中 ：2018/02/20(火) 11:18:40.74 ID:As+EIqvZM.net
- ARD（アーアールデー）やZDF（ツェットデーエフ）、RTL（アールテーエル）など大手含めて完全にMPEG2からHEVCへ切り替えか
日本はアナログ→デジタルの混乱で総務省も大変だったのに、ドイツは二度目の切り替えとかよくやるな
- 152 ：名無しさん＠編集中 ：2018/02/20(火) 13:33:19.34 ID:eKCqeHoO0.net
- 最初からHEVCへの移行も視野に入れた規格にしてただけでは
>>149
なにか変わるんですか？
- 153 ：名無しさん＠編集中 ：2018/02/20(火) 13:42:30.85 ID:Dz32tuw70.net
- >>143
業界は知らないが、コーデックの開発にはここのサンプルが良く使われる
https://media.xiph.org/video/derf/
- 154 ：名無しさん＠編集中 ：2018/02/20(火) 14:38:18.23 ID:QLl07UrG0.net
- >>152 >>149
>>56のリンク先PDFより
>2.2 ビデオ符号化
> 本会合では2つの作業項目が完了した。1つは、2017年10月にエミー賞を受賞したH.265の改訂版であり、
> 新たにモノクローム10と、メイン10静止画の2つのプロファイルを追加した。
> これは、色空間のアスペクトの修正と、補助的な拡張情報メッセージを追加するものである。
> 補助的な拡張メッセージには、コンテンツの色ボリューム、正距円筒図法とキューブマップによる
> 全方位360度投影、リージョンに関するパッキング、球面ローテーション、全天球視点、
> 領域の入れ子及び動き中心のタイルセット抽出情報集合と関連するそれらの入れ子が含まれる。
> .・・・
- 155 ：名無しさん＠編集中 ：2018/02/20(火) 14:39:51.28 ID:v8c8RhG5a.net
- オワコンジャップとはえらい差だなぁ…
- 156 ：名無しさん＠編集中 ：2018/02/20(火) 15:57:20.53 ID:QLl07UrG0.net
- >>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って書いてるね。
- 157 ：名無しさん＠編集中 ：2018/02/20(火) 20:54:21.46 ID:eKCqeHoO0.net
- >>154
なるほど用途拡大みたいなものね
- 158 ：名無しさん＠編集中 ：2018/02/21(水) 18:53:48.88 ID:Ma6ClYSK0.net
- HDで提供されてる360°映像は画質クソすぎて見れたもんじゃないから、8Kで提供されるようになれば有り難いね
HEVCにその規格がこれまで盛り込まれてなかったのはビックリだが
- 159 ：名無しさん＠編集中 ：2018/02/22(木) 00:00:30.67 ID:YUagvumb0.net
- Youtubeは既に8K 360度 3Dってのもあるね。
Youtubeの8K60pのVP9って、どれくらいのスペックなら再生できるんだろ。
- 160 ：名無しさん＠編集中 ：2018/02/22(木) 01:37:11.72 ID:9ZW2al3R0.net
- >>159
Intel KabyLake以降、NVIDIA Pascal以降で対応してる>>139
AMDはRavenRidge（Vega 11）が遂にDXVAで4K対応したけど8Kはまだ
- 161 ：名無しさん＠編集中 ：2018/02/22(木) 07:10:10.70 ID:527zvnld0.net
- >>160
4Kでは？
8kデコードに対応したGPUあんの？
- 162 ：名無しさん＠編集中 ：2018/02/22(木) 07:12:26.56 ID:Z1Y/m8920.net
- 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]
- 163 ：名無しさん＠編集中 ：2018/02/22(木) 07:16:10.77 ID:Z1Y/m8920.net
- あぁ、ごめんVP9のことか
- 164 ：名無しさん＠編集中 ：2018/02/22(木) 11:45:12.90 ID:FQJIj/Bk0.net
- つべのフォーマット272(8K60pのVP9)はGTX1070がギリッギリデコードが追いつく程度
Pascalならデコードはできるデコードは
- 165 ：名無しさん＠編集中 ：2018/02/22(木) 16:58:20.95 ID:OcZ5w+720.net
- >>160
再生支援の対応状況としてはそうなんだけど、レンダリングの負荷とかもあるので
どこまで実用再生できるのかなーと。
>>164
ということはレンダリングまで含めると厳しい感じなのかな？
気が向いたら最新のDXVACheckerでデコードパフォーマンスや再生パフォーマンスを計測してみてくれると嬉しい。
- 166 ：名無しさん＠編集中 ：2018/02/22(木) 18:12:27.62 ID:FQJIj/Bk0.net
- テスト対象：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] %
デコードパフォーマンスもほぼ同じフレームレート
- 167 ：名無しさん＠編集中 ：2018/02/22(木) 21:34:56.88 ID:OcZ5w+720.net
- >>166
ありがとうございます。やはり8K60pともなるとかなりギリギリなんですね。
- 168 ：名無しさん＠編集中 ：2018/02/23(金) 00:57:20.12 ID:UcFq47wN0.net
- 固定機能じゃないの?
- 169 ：名無しさん＠編集中 ：2018/02/23(金) 09:23:00.85 ID:B6bO8Kex0.net
- どういうこと？
- 170 ：名無しさん＠編集中 ：2018/02/23(金) 10:33:07.17 ID:UcFq47wN0.net
- クラスと動画再生能力が比例するのかどうか
- 171 ：名無しさん＠編集中 ：2018/02/23(金) 11:03:46.41 ID:W2529USpM.net
- 固定機能だけど、GT1030はNVEncが省かれたりしてるので違うかも？単に無効にしてるだけで同じかも？
- 172 ：名無しさん＠編集中 ：2018/02/23(金) 11:18:44.90 ID:B6bO8Kex0.net
- デコード回路の規模はPureVideoHDのバージョンで同じ気がするけど
GPU VideoDecode Engine Usageはクロック(P-State)で処理能力が変わるので、ピーク性能が同じとは思えない
コア、メモリクロックと違う何かがあるのかもしれんが、わからん
- 173 ：名無しさん＠編集中 ：2018/02/23(金) 12:11:45.20 ID:S4fgm/4B0.net
- 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] %
- 174 ：名無しさん＠編集中 ：2018/02/23(金) 12:20:43.65 ID:t8xzXBir0.net
- 世代が同じであれば性能は同じ
コアクロック依存であるから僅かな差はつくけど
https://www.computerbase.de/2016-07/geforce-gtx-1060-test/2/#diagramm-videos-abspielen-h265-codec-lav-filters
- 175 ：名無しさん＠編集中 ：2018/03/03(土) 17:09:33.22 ID:QZi8vNBpa0303.net
- AV1まだかね
どんだけ遅れるんや
- 176 ：名無しさん＠編集中 ：2018/03/03(土) 20:10:59.97 ID:xEY45FVi00303.net
- 圧縮は出来ても速度が尋常じゃなく遅いのが現状なんだっけ？
特許回避しながらどこまで早く出来るのかねえ、技術的な話は分からんが頑張ってもらうしかない
- 177 ：名無しさん＠編集中 ：2018/03/03(土) 21:00:50.76 ID:WFD8ngJA00303.net
- 50代後半の人が定年になるまでは安泰だろ。
来年度以降もミルビューや旧コネクテッドの事業をそのまま続投してもしばらくは大丈夫じゃないかなぁ。
- 178 ：名無しさん＠編集中 ：2018/03/04(日) 05:47:46.15 ID:VP/9+pJaa.net
- 立ち上がりがダメなものはダメという考え
- 179 ：名無しさん＠編集中 ：2018/03/04(日) 11:05:35.25 ID:JE86ooyK0.net
- youtubeとnetflixが採用するの決めてるし
- 180 ：名無しさん＠編集中 ：2018/03/04(日) 11:30:50.78 ID:LCgrZjek0.net
- 実際に載ってから考えようかｗ
- 181 ：名無しさん＠編集中 ：2018/03/04(日) 15:13:48.64 ID:CGGuH8J/d.net
- エンコは企業に任せるとしてハードウェアデコードできないと厳しいかね？
- 182 ：名無しさん＠編集中 ：2018/03/04(日) 18:01:08.26 ID:tFu0TfNX0.net
- 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
- 183 ：名無しさん＠編集中 ：2018/03/04(日) 20:00:08.11 ID:oGkDec2T0.net
- > ・Warped motion and global motion compensation
MPEG-4で負荷に見合った効率を得られないと不評だった機能だが大丈夫なのか
- 184 ：名無しさん＠編集中 ：2018/03/05(月) 22:12:34.09 ID:qgsUZYm70.net
- そりゃあハードウェアエンコだろ、それこそニューラルネットワークがーって革新無いと無理だろうねコレ
- 185 ：名無しさん＠編集中 ：2018/03/06(火) 05:13:50.29 ID:IFfxdwxma.net
- 次の次くらいのコーデックはニューラルネットを使ったものになりそうだな
- 186 ：名無しさん＠編集中 ：2018/03/06(火) 10:52:12.60 ID:50y01q050.net
- >>183
解像度も高く高品質になってるし
MB-Treeみたいな高度な入れ子処理も行うようになってるから
また違う結論に至ったのかもよ
- 187 ：名無しさん＠編集中 ：2018/03/06(火) 10:53:26.39 ID:50y01q050.net
- 対抗馬のhevcを引き合いにMB-Treeって書いたけど
AV1にあるのかは知らない
- 188 ：名無しさん＠編集中 ：2018/03/08(木) 08:02:04.92 ID:iSVPQkdJ0.net
- Codec wars: The battle between HEVC and AV1
https://www.ibc.org/delivery/codec-wars-the-battle-between-hevc-and-av1/2710.article
Previewing Android P
http://android-developers.googleblog.com/2018/03/previewing-android-p.html
HDR VP9,HEIF,サポート
- 189 ：名無しさん＠編集中 ：2018/03/09(金) 02:36:40.39 ID:Uw+UqCKlM.net
- HEVC採用、mpeg陣営の最新静止画規格が一番乗りか
webpは中身vp9になって対抗しないのかな
- 190 ：名無しさん＠編集中 ：2018/03/09(金) 13:42:37.83 ID:jOrnx8yd0.net
- AV1のサンプル動画見ると、MB-tree的な機能を効かせまくってるように感じる。
- 191 ：名無しさん＠編集中 ：2018/03/10(土) 02:44:19.30 ID:+NjEiXnyM.net
- 乾いた雑巾を更に絞るようなもんだしな
ムーアの法則が死亡してるから果たして実用的な時間でエンコ出来るようになるか疑問だわ
- 192 ：名無しさん＠編集中 ：2018/03/10(土) 12:34:29.08 ID:XGmzG2gUM.net
- 20年後くらいかね、実用一歩手前になるのは
- 193 ：名無しさん＠編集中 ：2018/03/10(土) 15:55:41.17 ID:GaKpzwKG0.net
- つーかVP9でよくね？
- 194 ：名無しさん＠編集中 ：2018/03/10(土) 19:08:03.25 ID:3IwdScz10.net
- radeonが再生支援対応してくれないので嫌です
- 195 ：名無しさん＠編集中 ：2018/03/10(土) 23:40:35.60 ID:EXZUGF6q0.net
- >>194
Polaris/VegaのVP9はブラウザ向けの再生支援しかできないようだけど、
RavenRidgeではちゃんとVP9のDXVAにも対応したみたいだよ。
- 196 ：名無しさん＠編集中 ：2018/03/14(水) 16:01:23.76 ID:bZRTgAyo0Pi.net
- HEVC Advance、配信のロイヤリティ徴収やめるってよ。
HEVC Advance Eliminates Content Distribution Royalty Fees and Reduces Certain Royalty Rates and Caps
https://www.hevcadvance.com/hevc-advance-eliminates-content-distribution-royalty-fees-and-reduces-certain-royalty-rates-and-caps/
HEVC Advance Cuts Content Fees on Streaming
http://www.streamingmedia.com/Articles/News/Online-Video-News/HEVC-Advance-Cuts-Content-Fees-on-Streaming-123828.aspx
- 197 ：名無しさん＠編集中 ：2018/03/14(水) 16:02:35.79 ID:bZRTgAyo0Pi.net
- HEVC Advanceがコンテンツ配信著作権使用料廃止、特定の著作権料金と上限を減額
https://japan.cnet.com/release/30237475/
> 独立系ライセンス供与管理企業のHEVC Advanceは14日、HEVC Advance Patent Licenseから
> 「サブスクリプション」と「タイトルごと」のコンテンツ配信を廃止し、HEVCの普及を加速し、
> ストリーミング、ケーブル、オーバー・ジ・エア・ブロードキャスト、衛星配信をサポートして、
> 最高のビデオ体験を消費者に提供する。今回の発表によって、HEVC Advanceは、
> インターネット・ストリーミング、ケーブル、オーバー・ジ・エア・ブロードキャスト、
> 衛星を含む非物理的なHEVCコンテンツ配信にライセンスを供与しないし、著作権使用料を求めない。
- 198 ：名無しさん＠編集中 ：2018/03/14(水) 16:20:04.68 ID:bZRTgAyo0Pi.net
- 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
- 199 ：名無しさん＠編集中 ：2018/03/14(水) 16:39:30.73 ID:K1Ig4i+B0Pi.net
- AV1厨発狂
- 200 ：名無しさん＠編集中 ：2018/03/14(水) 17:10:19.66 ID:bZRTgAyo0Pi.net
- >>198の訂正
>>198の旧の方は20170717時点のもの(webarchiveではこれが最新だった)なんだけど、
2017/10/24
HEVC Advanceが低価格機器の特許使用料見直しを発表
https://japan.cnet.com/release/30214763/
にあるようにHEVC Advanceは昨年10/24にもライセンスの見直しを行っていた模様。
つまり>>198の旧PDFはその変更前のものとなるので注意。
- 201 ：名無しさん＠編集中 ：2018/03/14(水) 17:41:47.41 ID:bRUD/wvZMPi.net
- >>199
美味い方に乗っかるから負ける事は無いぞ。
何処まで適用されるのかよく分からんなぁ
- 202 ：名無しさん＠編集中 ：2018/03/14(水) 21:05:59.89 ID:bZRTgAyo0Pi.net
- しかしあれだな・・・。>>196のStreamingMediaの記事でも
「はぁ？現時点ではロイヤリティの情報を公開するつもりがない？バカなの死ぬの？」
みたいにこきおろされてるVELOS media（HEVCのライセンスプールの１つ）に
SONY、Panasonic、、SHARPといった企業名が並んでるのを見ると、
「やる気がないならHEVC普及の足をひっぱってないで、さっさとMPEG-LAにでも合流しちまえよ」って言いたくなるな。
ちなみにVELOS mediaのHPに行ってみたら無駄に動いてちょっとうざかった・・・。
http://velosmedia.com/
- 203 ：名無しさん＠編集中 ：2018/03/15(木) 00:06:56.39 ID:Ht9rT5VJ0.net
- AV1とはw
- 204 ：名無しさん＠編集中 ：2018/03/15(木) 03:34:19.14 ID:2haHtVFIa.net
- ストリーミングで金がかからなくなるのか
youtubeがどう動くかな
- 205 ：名無しさん＠編集中 ：2018/03/15(木) 03:41:00.81 ID:zYh1EV920.net
- でも、徴収をやめるのはHEVC Advanceだけで、他にもパテントあるんでしょ？
- 206 ：名無しさん＠編集中 ：2018/03/15(木) 09:11:42.62 ID:kse97YDc0.net
- Velosとか他の企業も追従する方針
- 207 ：名無しさん＠編集中 ：2018/03/15(木) 12:22:00.65 ID:AUeFWL+M0.net
- >>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を抜けたという経緯もある。
●その他
知らん。
- 208 ：名無しさん＠編集中 ：2018/03/15(木) 12:33:30.10 ID:tRe8M41+0.net
- ブラウザの対応は進むの？
- 209 ：名無しさん＠編集中 ：2018/03/15(木) 12:52:16.38 ID:2Wj4FSUF0.net
- mukenさんがHEVC Advanceは四天王の中で最弱っていうネタ投稿してたけど
配信側からの徴収は行ってないパテントプールが多いのね
- 210 ：名無しさん＠編集中 ：2018/03/15(木) 13:40:55.44 ID:AUeFWL+M0.net
- ブラウザはどうなるんだろうね。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再生支援をサポートしてないとダメっぽいから
そこからなんとかしないとどうしようもなさそうだけど、よくわからない。
- 211 ：名無しさん＠編集中 ：2018/03/15(木) 13:43:12.79 ID:AUeFWL+M0.net
- まあAV1のこともあるし、バラバラで複雑になってるH.265のパテントホルダーに圧力をかけるためにも、
FirefoxやChromeでのH.265対応はすぐには進まないかもね。
- 212 ：名無しさん＠編集中 ：2018/03/16(金) 12:57:23.94 ID:U7HfZ+6s0.net
- おいおい、iPhoneで撮ったHEVC動画はどうなるんだよ
能力を存分に発揮できねえじゃねえか
- 213 ：名無しさん＠編集中 ：2018/03/16(金) 12:59:03.00 ID:/o7rBYvFM.net
- ？
- 214 ：名無しさん＠編集中 ：2018/03/16(金) 13:07:23.80 ID:be0tsBA40.net
- >>212
意味不明なことを言うな
- 215 ：名無しさん＠編集中 ：2018/03/16(金) 14:36:03.81 ID:y5RZw7gD0.net
- 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.
- 216 ：名無しさん＠編集中 ：2018/03/17(土) 05:58:04.33 ID:U+G3LyDOa.net
- >>210
H.264はOpenH264を使えばCISCOがライセンス料を負担してくれているからね
firefoxはそれを使っているよ
プラグインの欄を見てみればわかると思うけど
- 217 ：名無しさん＠編集中 ：2018/03/17(土) 10:04:22.25 ID:4V5lIZ5ud.net
- >>216
じゃあOpenh.265作れば解決だね
- 218 ：名無しさん＠編集中 ：2018/03/17(土) 10:12:06.24 ID:c5WgWV6Kd.net
- >>217
草
- 219 ：名無しさん＠編集中 ：2018/03/17(土) 10:17:18.98 ID:MMu9nYqk0.net
- なんでCISCOが肩代わりして支払ってるんだろ？
何か弱みでも握られてるのか？
- 220 ：名無しさん＠編集中 ：2018/03/17(土) 14:42:00.12 ID:UvukF0qw0.net
- >>216
OpenH264はWebRTCで使われてるけど、動画再生には使われていないと思う。
>>210で書いたように、OSのデコーダを無効にしただけで再生できなくなっちゃうし。
- 221 ：名無しさん＠編集中 ：2018/03/19(月) 04:03:46.68 ID:C8xTW8Ei0.net
- ＡＶ１は死亡確定？
- 222 ：名無しさん＠編集中 ：2018/03/19(月) 04:43:24.06 ID:BcFVPvvt0.net
- Windows10 Insider PreviewのBuild17623でHEIFがサポートされたみたいですね。
もっとも今回は表示だけで編集はできないそうです。
https://blogs.windows.com/windowsexperience/2018/03/16/announcing-windows-10-insider-preview-build-17623-for-skip-ahead/
- 223 ：名無しさん＠編集中 ：2018/03/19(月) 08:47:44.89 ID:UHHkqjkVd.net
- 編集なんかフォトショ使うから別によくね？
- 224 ：名無しさん＠編集中 ：2018/03/19(月) 08:58:13.83 ID:VRLO15170.net
- HEIFってBPGみたいに全然使われないかと思ったけど案外採用されてるね
ただ今のところYUV420しかデコード出来ないらしいのが痛いが
- 225 ：名無しさん＠編集中 ：2018/03/19(月) 14:22:51.34 ID:2Qm2QmTL0.net
- 圧縮画像は基本420だから、それほど危惧する必要はないんじゃないの？
- 226 ：名無しさん＠編集中 ：2018/03/19(月) 15:57:00.68 ID:TZqX1Vdx0.net
- YUV420は赤の崩れみたいな問題もあるし、RGBかYUV444/YUV444P10があった方がいいという話では。
- 227 ：名無しさん＠編集中 ：2018/03/19(月) 17:55:52.09 ID:2Qm2QmTL0.net
- 話飛躍しすぎだろ
- 228 ：名無しさん＠編集中 ：2018/03/19(月) 18:02:42.50 ID:Anm1Go+PM.net
- 420と444とRGB(可逆)で拡張子か何か変えて1発で判断出来るようにしてくれよ
- 229 ：名無しさん＠編集中 ：2018/03/19(月) 19:21:39.08 ID:UHHkqjkVd.net
- >>228
これ。
HEI0,HEI2,HEI4,HEIRとかなら分かりやすいのに。
- 230 ：名無しさん＠編集中 ：2018/03/19(月) 21:23:31.38 ID:CahkNlja0.net
- つかHEIFはYUV444まで対応してるだろ
- 231 ：名無しさん＠編集中 ：2018/03/19(月) 21:50:09.33 ID:D6I3EPyBa.net
- 高圧縮なコーデックが流行るのはいい事だと思うけどheifはライセンスどうなってるんだ？
- 232 ：名無しさん＠編集中 ：2018/03/19(月) 22:16:18.01 ID:U17HoX680.net
- もう旬は過ぎた感じだけど、今更本の自炊を始めよう思ってるんでHEIFが普及してくれるのはありがたい
EPUBやPDFもHEIF対応してくれないかなぁ
- 233 ：名無しさん＠編集中 ：2018/03/19(月) 22:38:24.65 ID:TZqX1Vdx0.net
- >>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)
- 234 ：名無しさん＠編集中 ：2018/03/20(火) 00:23:51.90 ID:R8zn4cKBM.net
- >>232
webpで圧縮しておけばok
- 235 ：名無しさん＠編集中 ：2018/03/20(火) 08:38:30.51 ID:CKEX4d97M.net
- 日テレ系SOC、HEVC 60i 1920x540というかなり特殊な設定使ってるのね
- 236 ：名無しさん＠編集中 ：2018/03/20(火) 08:48:16.73 ID:7x3mPA560.net
- >>235
HEVCの規格上どうしてもそうなるという可能性が
x265でインタレ保持するときもフィールド分離してやらないといけないし
- 237 ：名無しさん＠編集中 ：2018/03/20(火) 12:44:22.64 ID:srbxwjHvM.net
- >>235
日テレ系SOCって何？
- 238 ：名無しさん＠編集中 ：2018/03/20(火) 13:54:44.32 ID:CKEX4d97M.net
- サテライトオペレーションセンター
SNGのこと
- 239 ：名無しさん＠編集中 ：2018/03/20(火) 14:30:00.01 ID:kfU99cWY0.net
- VLCは3/13のコミットからHEIFに対応しつつあるらしい。
193f466c4a [Tue Mar 13 18:51:32 2018 +0100] [demux: add support for HEIF]
Nightlyで試せるはずだけど、試してはいないので現時点での出来は不明。
https://nightlies.videolan.org/
- 240 ：名無しさん＠編集中 ：2018/03/20(火) 14:46:34.60 ID:srbxwjHvM.net
- >>238
結局よくわからん…
関係なさそうだから、突っ込まないでおこう
- 241 ：名無しさん＠編集中 ：2018/03/20(火) 15:14:50.28 ID:kfU99cWY0.net
- >>240
俺もよく知らんけど、中継車と放送局を結ぶ衛星中継で飛んでるデータのことでは。
>>235
それってどうやって調べたの？どこかの記事？
それとも何らかの方法で受信して解析できるのかな？
- 242 ：名無しさん＠編集中 ：2018/03/20(火) 16:26:43.55 ID:VTNp5e8r0.net
- >>233
MacだとHEVCデコーダが対応してるのはハード処理、
対応していないのはソフト処理になるようだけど、
Win10のHEVCデコーダはハード処理専用みたいだし、
どうなるのかわからなんなあ
- 243 ：名無しさん＠編集中 ：2018/03/20(火) 16:29:32.94 ID:VTNp5e8r0.net
- Win10のHEVCデコーダ→HEVCコーデック
https://www.microsoft.com/ja-jp/store/p/hevc-video-extension/9n4wgh0z6vhq
よく見たらWin10のHEVCコーデックもハード処理とソフト処理対応してた
ってことはHEIFも同じ仕様になるかな
Win10のHEVCデコーダ
- 244 ：名無しさん＠編集中 ：2018/03/20(火) 17:13:07.49 ID:QNKVjbmVd.net
- >>235
LSIチップのSoCじゃないのね。
紛らわしいわwww
- 245 ：名無しさん＠編集中 ：2018/03/20(火) 17:49:19.45 ID:T17xvZTR0.net
- >>236
HEVCのインタレってそんな仕様なんだ
インタレソースだとh.264に対してそんなにメリット無いのかな？
- 246 ：名無しさん＠編集中 ：2018/03/20(火) 19:51:55.87 ID:srbxwjHvM.net
- HEVCは本来インタレをサポートしない前提だったんじゃなかったっけ？
今実装されてるのもインタレもどきというか、独自実装のような感じを強く受けるのだが
- 247 ：名無しさん＠編集中 ：2018/03/20(火) 22:47:52.30 ID:7b4xVcuId.net
- そもそもいつまでインターレース使う気なんだ。
1000年代の代物だぞ。
- 248 ：名無しさん＠編集中 ：2018/03/20(火) 23:09:24.05 ID:vhDWXFdj0.net
- クリスタルスカルもびっくりなオーパーツだな
- 249 ：名無しさん＠編集中 ：2018/03/20(火) 23:20:00.95 ID:v1I/NHqy0.net
- インターレースってデジタル時代でメリットあるの？
- 250 ：名無しさん＠編集中 ：2018/03/20(火) 23:24:29.53 ID:rlG5VxC10.net
- 1440x540のデータ量でフルHD60fpsと言い張れる
- 251 ：名無しさん＠編集中 ：2018/03/20(火) 23:50:11.87 ID:sl72jklj0.net
- >>249
一切ないな。ブラウン管テレビが無くなった今では負の遺産。
- 252 ：名無しさん＠編集中 ：2018/03/21(水) 00:01:55.19 ID:l3mF2m2w0.net
- >>247
中世から続く歴史の重みだな
- 253 ：名無しさん＠編集中 ：2018/03/21(水) 00:02:39.61 ID:9NK4Qowb0.net
- 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
#-----------------------
- 254 ：名無しさん＠編集中 ：2018/03/21(水) 00:03:29.42 ID:9NK4Qowb0.net
- # 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
- 255 ：名無しさん＠編集中 ：2018/03/21(水) 00:10:00.67 ID:mqwPxvtg0.net
- フィールド周波数高い60Hzだから、倍速120Hzが効きやすくなる
IP変換でかなり正確にブログレッシブ化出来る
データ量が半減する
実は今時のデジタル技術によって逆に見直されてるのがインターレース
- 256 ：名無しさん＠編集中 ：2018/03/21(水) 00:51:20.48 ID:Aq0oefQh0.net
- >>255
プログレッシブの60Hzも余裕でどんどんプログレッシブ化が進んでるのが実際のとこだと思うんだけど
どういう現場のどんな人達がそういう見直し方をしてるの？
- 257 ：名無しさん＠編集中 ：2018/03/21(水) 04:02:23.07 ID:pwvjtYjO0.net
- インターレースお払い箱批判が酷くなったのは
まともにI/P変換出来ない安物LCDモニターが売られ始めてから
それよりも葬り去るべきはプログレでも低フレームレートのガクガク映像
あれを有難がってガンガン垂れ流してる人の視覚ってどうなってんだろう
- 258 ：名無しさん＠編集中 ：2018/03/21(水) 04:09:27.66 ID:VQ8P8Edj0.net
- 個人的にはフレームレートや解像度を多少下げても
ノイズの少ない映像を流してくれって思う
ビットレートが高いはずの某有料BSチャンネルですらノイズまみれ
- 259 ：名無しさん＠編集中 ：2018/03/21(水) 08:48:21.78 ID:mqwPxvtg0.net
- >>258
最近、BSが1920から地デジと同じ1440になって、ビットレートも地デジ並みに下げられたからな
HDでも圧縮率の低い高ビットレートなら、相当きれいなもんだが
- 260 ：名無しさん＠編集中 ：2018/03/21(水) 08:48:51.88 ID:mqwPxvtg0.net
- >>256
放送
- 261 ：名無しさん＠編集中 ：2018/03/21(水) 08:53:22.78 ID:mqwPxvtg0.net
- >>257
ちょっといいテレビなら問題なくても、安いテレビだと見られたものじゃなくなるな
30pが増えてるのは、4K60pの撮影編集がXAVC class300だと600Mbpsになり、HD60iの50Mbpsの12倍になるから、記録保存も編集も大変過ぎ
てことで、4K30pの300Mbpsでお茶を濁すから
- 262 ：名無しさん＠編集中 ：2018/03/21(水) 13:39:56.54 ID:pwvjtYjO0.net
- 瞬間的に入る紙吹雪パターンに遭遇したら
ビットレート爆上げするなりブロック格子細かくしたり
そういうのに特化して研究してる優秀なヒト誰も居ないのだろうか
もう記録映像より3Dリアルタイムレンダリングコンテンツが
家庭用に作られるようになる方が先かも知れないけど…
それはそれで三船敏郎と越後製菓がチャンバラする新作とか楽しみだけど
- 263 ：名無しさん＠編集中 ：2018/03/21(水) 17:23:57.61 ID:6pEPxKFk0.net
- かのDVDフォーラム vs DVD+RWアライアンスみたいな構図やなｗ
- 264 ：名無しさん＠編集中 ：2018/03/22(木) 18:40:53.14 ID:klIgLKNE0.net
- 60pと比べたら60iの方が良いけど、
確かに30pと比べたら60iの方が遥かに良いな
時代はiPadですらリフレッシュレート120Hzなのに30pはガクガク過ぎる
- 265 ：名無しさん＠編集中 ：2018/03/22(木) 18:41:33.85 ID:klIgLKNE0.net
- 60pと比べたら60iの方が良いけど、
↓
60pと60i比べたら60pの方が良いけど、
- 266 ：名無しさん＠編集中 ：2018/03/22(木) 23:35:13.24 ID:jISa2O100.net
- >>262
つ crf（品質基準）モード
>>264
動きの滑らかさはそうかもしれないけど
画質自体はプログレのほうが断然優れてるから30pのほうがいい
ま、自分でエンコードしない人にはインタレ放送の画質の悪さなんて気づかないだろうけど
- 267 ：名無しさん＠編集中 ：2018/03/22(木) 23:41:43.50 ID:rkE2sIcV0.net
- >>266
60iは60pの半分の帯域で済むし、普通のテレビのI-P変換でそこそこいい1枚映像の画質が得られるし、効率がいいんだよ
XAVCならHDだと50Mbpsの60iと比較して、4K60pとなると600Mbpsになるから、12倍の帯域とストレージ容量を食い潰すしな
- 268 ：名無しさん＠編集中 ：2018/03/23(金) 00:53:11.37 ID:5n0zraop0.net
- >>267
なんで>>261と同じ内容を２度繰り返したのかよくわからんが、HDだの12倍だのは本筋とは全く関係なくて、
・4K60pはXAVCだと600Mbpsになって大変。
・4K60pがきつい場合は4K60iか4K30pにしてレートを半分にして誤魔化そう。（それでも300Mbpsだが）
・滑らかさ重視の60iにするか、１枚絵重視の30pにするかは人それぞれだよね。本当は60pが一番いいけど。
ということで、4K過渡期の次善手段として4K60iが選択肢に入ってるというだけでは・・・。
仕方なく使ってるというだけなのを「インタレースが見直されてる」と表現するのは違和感があるな。
4K30pを「お茶を濁す」と表現するなら、4K60iも「お茶を濁してる」ことに変わりはないと思う。
4K放送は60pなんだし。
- 269 ：名無しさん＠編集中 ：2018/03/23(金) 01:10:18.00 ID:9jtovvO90.net
- 意外と収録のみの現場ではPsFが活用されてたりするのだ
- 270 ：名無しさん＠編集中 ：2018/03/23(金) 01:52:59.77 ID:5n0zraop0.net
- あー、コストや状況等を踏まえてフォーマットを選択するのは当たり前だろうから、
現場でインタレースを使うのが悪いと言ってるわけじゃないよ。
ただ、そういうフォーマット選択って昔からやられてきたことであって、
別に「インタレースが見直されてる」ってわけじゃないんじゃないかなあというか
そのへんの表現で少しモヤっとしただけというか、それだけです。
- 271 ：名無しさん＠編集中 ：2018/03/23(金) 03:59:30.27 ID:HcAUFe0E0.net
- HEVCでインタレとか何考えてんだ…マジで放送にしか需要無いから
- 272 ：名無しさん＠編集中 ：2018/03/23(金) 09:43:04.55 ID:FSUrXQi9a.net
- 放送も4K以上はプログレッシブのみだよ
- 273 ：名無しさん＠編集中 ：2018/03/23(金) 13:22:22.38 ID:pgVKJkyq0.net
- ここはPS4proが擬似4Kのために使ってる市松模様方式で…。
- 274 ：名無しさん＠編集中 ：2018/03/23(金) 20:53:30.86 ID:DxN2dByn0.net
- 西田宗千佳のトレンドノート：iPhoneなどで採用されてる新画像フォーマット「HEIF」とは？
http://u-note.me/note/47508170
- 275 ：名無しさん＠編集中 ：2018/03/23(金) 21:27:12.76 ID:P0t6uZ540.net
- 綺麗にデインターレースできる映像は
プログレッシブにしても動画サイズはあまり変わらない気がする
- 276 ：名無しさん＠編集中 ：2018/03/23(金) 21:56:14.46 ID:DxN2dByn0.net
- 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 ：名無しさん＠編集中 ：2018/03/23(金) 22:57:55.76 ID:BS3JwG/x0.net
- AV1 ist eingefroren und 30 Prozent besser als VP9
https://www.golem.de/news/videocodec-av1-ist-eingefroren-und-30-prozent-besser-als-vp9-1803-133457.html
ドイツ語のニュースをgoogle翻訳
AV1の仕様が正式に凍結されていることを関係者が確認しています。
ネタ元
https://forum.doom9.org/showthread.php?p=1837199#post1837199
- 278 ：名無しさん＠編集中 ：2018/03/23(金) 23:38:02.32 ID:DxN2dByn0.net
- >>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
- 279 ：名無しさん＠編集中 ：2018/03/24(土) 00:37:41.39 ID:qRCTBx3V0.net
- >>277
死亡確認
- 280 ：名無しさん＠編集中 ：2018/03/24(土) 00:58:36.83 ID:L8KD4aVc0.net
- HEVC免除化、HEIFの普及で諦めたか…
- 281 ：名無しさん＠編集中 ：2018/03/24(土) 01:18:43.26 ID:7cdy0gnA0.net
- だったらFirefoxとChromeとEdgeはHEVCに対応してくれるかな？
- 282 ：名無しさん＠編集中 ：2018/03/24(土) 02:02:33.48 ID:QzLfB42f0.net
- どうだろうねえ。
今みたいにOSが用意するHEVCデコーダを呼び出すといった実装は可能になるんだろうけど、H.264 vs WebM の時のように
HEVC vs AV1
HEIF vs AVIF ( https://github.com/AOMediaCodec/av1-avif )
という対決構図を作って、最低でもHEVCのライセンス面での更なる譲歩を引き出すためにゴネる気もする。
まあAV1がどこまで使えるかにもよるけど。主に速度面が心配だ。
- 283 ：名無しさん＠編集中 ：2018/03/24(土) 09:49:13.13 ID:2qWnwRRv0.net
- 仕様が固まったということじゃなくて
規格（開発の）凍結なの？
- 284 ：名無しさん＠編集中 ：2018/03/24(土) 10:39:36.48 ID:/8ZYH/E3M.net
- 3000倍の時間かけてまでエンコードするほどの価値あるコーデックではないということ
- 285 ：名無しさん＠編集中 ：2018/03/24(土) 11:11:28.09 ID:mUuN0la/a.net
- 現状だとVP9のほうが実用的だよな
- 286 ：名無しさん＠編集中 ：2018/03/24(土) 11:22:59.48 ID:OdYZP1X9M.net
- >>283
仕様凍結(freeze)=仕様確定だな
- 287 ：名無しさん＠編集中 ：2018/03/24(土) 11:47:37.77 ID:qcIvBeHn0.net
- ハードウェアエンコーダーが出ない限り、AV1に実用性はない
- 288 ：名無しさん＠編集中 ：2018/03/24(土) 12:00:23.05 ID:7cdy0gnA0.net
- IntelとAMDとNVIDIAの名前があるんだし、HWエンコーダーは出てくると思うぞ
- 289 ：名無しさん＠編集中 ：2018/03/24(土) 12:17:23.09 ID:OdYZP1X9M.net
- >>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 で
支払わさせることで解決するみたい
- 290 ：名無しさん＠編集中 ：2018/03/24(土) 13:51:59.58 ID:/N519Zs3a.net
- ciscoではないのか
- 291 ：名無しさん＠編集中 ：2018/03/24(土) 13:53:38.44 ID:8WYg/StLa.net
- ciscoさん今回もお願いしますよ
- 292 ：名無しさん＠編集中 ：2018/03/24(土) 13:58:34.42 ID:OdYZP1X9M.net
- >>277
＞現在の計画によると、コーデックの仕様は今年の7月にインターネット標準として採用される予定です。
漸くか
- 293 ：名無しさん＠編集中 ：2018/03/24(土) 14:02:43.19 ID:YFnG0BBP0.net
- >>279-282,284
うーんこの読解力
- 294 ：名無しさん＠編集中 ：2018/03/24(土) 14:08:06.22 ID:OYcfkvl0d.net
- 120円くらいくれてやるわ。
- 295 ：282 ：2018/03/24(土) 14:52:35.93 ID:bfTaA7mB0.net
- >>293
ああ、>>280は「AV1が諦めた」と勘違いしてたのか・・・。意味を取り違えた。
>>282はブラウザのHEVC/HEIF対応可能性について書いただけであって
別にAV1の「凍結」を開発中止だと勘違いしたわけじゃないんだけど、
確かに流れだけ見ると勘違いしたように見えてしまうな・・・。
>>281
書き忘れたけど、Edgeは既にWin10FCUで
「デバイス製造元からのHEVCビデオ拡張機能」(HEVC Video Extension)
が入ってればHEVC動画の再生ができるよ。
- 296 ：名無しさん＠編集中 ：2018/03/25(日) 08:59:59.37 ID:pJMHgoYV0.net
- はようどっちか諦めてくれという願望
- 297 ：名無しさん＠編集中 ：2018/03/25(日) 20:49:43.42 ID:1OGVIXi30.net
- 民生機でも実用的な時間でエンコードもできるコーデックと
少しでも画質容量比を良くするためにエンコに死ぬほど時間がかかるけど
莫大な帯域を消費する配信業者用の業務用コーデックかという話で
どっちが勝ったり諦めたりという話ではないと思うぞ
どのみちAV1は俺らが気軽に扱えるものにはならんだろ
- 298 ：名無しさん＠編集中 ：2018/03/25(日) 21:02:42.26 ID:h38wJJ3yd.net
- NVencで対応されればワンチャン
- 299 ：名無しさん＠編集中 ：2018/03/25(日) 21:10:24.67 ID:Q2SZSXCu0.net
- nvencのhevcってx264よりかなり汚いぞ
- 300 ：名無しさん＠編集中 ：2018/03/25(日) 21:52:36.65 ID:jB6Kd02v0.net
- これまでAviUtlやAvisynthのプラグインの開発者ですら
もうTSやBD,DVDのソースをカットしてフィルタ掛けてエンコードしてって作業に飽きてほとんどエンコードしなくなったと言ってるからねぇ...
ストレージが大容量化したからTSのままでもスマホやタブレットに転送して視聴した方が楽になったんだと
HEVCはQSVのHWエンコーダがそれなりの速度でまあまあの品質だしAppleのお陰で再生環境も揃ってきたし
コンシューマはHEVCを選んでおけばいい気がする
- 301 ：名無しさん＠編集中 ：2018/03/25(日) 21:54:31.20 ID:FiSUDZO70.net
- 無駄なエンコは電気代の時間と人生を失う
- 302 ：名無しさん＠編集中 ：2018/03/25(日) 23:05:46.47 ID:1AtfY0210.net
- BDはさすがに30G超えてくるからエンコ必至だろ。
インタレソースなら解除が面倒だしなぁ…
とりあえずインタレは早く廃れろ
- 303 ：名無しさん＠編集中 ：2018/03/26(月) 00:06:49.50 ID:+KFZYi8K0.net
- インタレ解除は例のHWインタレ解除フィルター使うか、レコーダーからのキャプチャーならばレコーダーで解除
- 304 ：名無しさん＠編集中 ：2018/03/26(月) 02:31:28.27 ID:RO86JFjT0.net
- 例のフィルタが動くゲフォ詰んだタブレット下さい
- 305 ：名無しさん＠編集中 ：2018/03/26(月) 02:59:51.13 ID:Xhp5xuO0M.net
- MX150搭載なら安いのはLenovoのideapadあたりか
それでも9万コースだけど
そもそもモバイルで単価の低いCPU積んでるモデルな時点でdGPUなんぞ積まないから、dGPU積んでる時点それなりにするんだよな
そのうえHWデコーダと違ってGPUブン回すから綺麗に処理出来てもバッテリ保たないだろうなぁ
- 306 ：名無しさん＠編集中 ：2018/03/26(月) 10:12:48.77 ID:+KFZYi8K0.net
- 動画エンコードを10万円以下で考えている人はクオリティーなんぞ求めるべきではない
- 307 ：名無しさん＠編集中 ：2018/03/26(月) 16:31:27.23 ID:RO86JFjT0.net
- avisynth+対応プレイヤーでリアルタイムフィルタ処理すればいいという話だぞ
- 308 ：名無しさん＠編集中 ：2018/03/26(月) 17:26:11.15 ID:KAWe9XE/0.net
- >>307
なんでボカしてるのか知らんけど、例のフィルタってnekopanda氏のD3DVPだよね？
https://github.com/nekopanda/D3DVP
これは「GPUでインタレ解除してプログレッシブでエンコードしたい場合」に使うもの。
インタレソースを再生する場合は普通にレンダラがGPUを使ってインタレ解除するんだから、
再生時にわざわざAvisynth+使ってリアルタイムフィルタ処理なんてする必要ないと思うんだけど。
インタレ解除したものをBlueskyFRCに渡してフレーム補間したいとかなら別だが・・・。
というかインタレ解除とかの話はAvisynthスレとかTSスレとかでやった方がいいと思うよ。
- 309 ：名無しさん＠編集中 ：2018/03/26(月) 20:10:25.15 ID:+KFZYi8K0.net
- 動画の世界は常に流動的だという意識が充分ではないようだな
時代は今後、インターレースからプログレッシブへと潮流が変わっていくことになる
そうすると、やがて再生時にインタレ解除しようにもクオリティーの高いインタレ解除技術が使えなくなっている可能性が高くなってくる
それならばインタレ解除技術が充実している今のうちに解除してからエンコードしておけば、後々インタレ解除のクオリティー問題に悩まされなくて済む
それに再生時にインタレ解除する前提では、再生する環境に依存することになるから、古いPCや安物のプレーヤーを使って再生する必要が出た場合にも、
満足いく再生ができない問題に悩むハメになる
- 310 ：名無しさん＠編集中 ：2018/03/26(月) 20:56:20.81 ID:KAWe9XE/0.net
- そんな大袈裟な意識持ってるなら、現存する手法よりも
高度なインタレ解除技術が登場する可能性も考慮したほうがいいのでは。
- 311 ：名無しさん＠編集中 ：2018/03/26(月) 21:15:43.02 ID:KAWe9XE/0.net
- 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の仕様が確定したなんて話は聞いてねーぞ」っつってるな。
- 312 ：名無しさん＠編集中 ：2018/03/26(月) 21:19:55.92 ID:8PaOdK0E0.net
- >TSのままでもスマホやタブレットに転送して視聴した方が楽になった
君ってすぐ騙されそうだね
- 313 ：名無しさん＠編集中 ：2018/03/26(月) 21:56:25.29 ID:DrJlZ7Ahp.net
- >>310
確かに
エンコードした後でより優れたインタレ解除が出てきたら後悔しそう
つーか放送がインタレな以上、当分インタレはなくならないでしょ
4K放送は一般に普及するとは思えないし
- 314 ：名無しさん＠編集中 ：2018/03/26(月) 22:48:24.53 ID:+KFZYi8K0.net
- インタレ解除については、これ以上の進化は期待しにくい
あるとしても時間をかけて演算するディープラーニング系にわずかに可能性はあるが、再生時のリアルタイム処理に使うには不向き
- 315 ：名無しさん＠編集中 ：2018/03/26(月) 23:15:06.45 ID:pRgZAAzX0.net
- >>308
D3DVPはavisynth+じゃなくても動くことを考えると
KTGMCのことをいってるのでは
- 316 ：名無しさん＠編集中 ：2018/03/26(月) 23:26:42.80 ID:XQOEJ7Z10.net
- >>312
どう考えても実際にやったことない奴だな
一応TSのままハードウェアデコード＆ハードウェアデインタレースで再生できるけど、
60pじゃなくて30pになるのでカクカクで使い物にならん（Android＆Snapdragonの場合、iPhoneは知らん）
だいたいWiFiなんて11acでも有線GbEより遥かに遅いし時間掛かって面倒
それこそQSVとかでハードウェアデインタレース＆エンコードしといた方が楽
- 317 ：名無しさん＠編集中 ：2018/03/27(火) 00:28:21.15 ID:NBCZX+Tg0.net
- 視野が狭いな
- 318 ：名無しさん＠編集中 ：2018/03/27(火) 09:12:37.70 ID:kNxhuClM0.net
- だな
- 319 ：名無しさん＠編集中 ：2018/03/27(火) 09:46:24.07 ID:MMCQPcYI0.net
- 最近の流行りはサーバ側でのリアルタイムエンコードでタブレット等での視聴
つまりネットワーク負荷は依然高いからエンコードが使われるわけで
- 320 ：名無しさん＠編集中 ：2018/03/27(火) 09:54:51.65 ID:ki8W3Hxg0.net
- 何がつまりなの？
- 321 ：名無しさん＠編集中 ：2018/03/27(火) 11:04:31.00 ID:Y70u6mQ+0.net
- エンコード需要は廃れていない
- 322 ：名無しさん＠編集中 ：2018/03/27(火) 12:23:48.20 ID:RRMCKFfmd.net
- BDは気に入ったのしか取ってないからm2tsのまま取ってるけど、ゲームの録画は可逆だから編集後にエンコしてるわ。
でないと1時間で500GBとかになるし
- 323 ：名無しさん＠編集中 ：2018/03/27(火) 14:42:50.91 ID:N7lQDn3s0.net
- >>321
廃れたらおしまい
- 324 ：名無しさん＠編集中 ：2018/03/27(火) 15:00:08.14 ID:S9EHQTlVd.net
- 16K無圧縮の帯域を実質スループットで通せるくらいネットの帯域が拡大するまでは廃れないんじゃね？
- 325 ：名無しさん＠編集中 ：2018/03/27(火) 15:08:52.32 ID:0YgDMbF30.net
- >>323
アホですか
どんなコーデックでも成り立つよそれ
- 326 ：名無しさん＠編集中 ：2018/03/28(水) 02:15:40.96 ID:cyNroVs8a.net
- 物理的に無理やろな
データをテレポートで遅れるくらいにならないと
- 327 ：名無しさん＠編集中 ：2018/03/28(水) 04:04:43.76 ID:tfyUQf6yd.net
- 量子通信かよ
- 328 ：名無しさん＠編集中 ：2018/03/28(水) 09:19:05.36 ID:ZttOb1ah0.net
- サイトがリニューアル AV1のロゴマークが出来てる！
https://aomedia.org/
- 329 ：名無しさん＠編集中 ：2018/03/28(水) 11:04:46.62 ID:cyNroVs8a.net
- ロゴださい…
- 330 ：名無しさん＠編集中 ：2018/03/28(水) 12:23:06.23 ID:UjfKVDvMr.net
- ロゴええな
- 331 ：名無しさん＠編集中 ：2018/03/28(水) 12:24:33.02 ID:ZisaNVK20.net
- もう開発者は開発を始められるんだな、俺は無理だが
エンコード速度はどんなもんなんかね
- 332 ：名無しさん＠編集中 ：2018/03/28(水) 18:37:41.29 ID:zdmfSnaWM.net
- 3000倍遅い
- 333 ：名無しさん＠編集中 ：2018/03/28(水) 21:08:21.07 ID:3H5NZI/I0.net
- HEVCだってリファレンス実装のHMとx265では数百倍は速度が違うのでAV1もこれから多少は最適化されていくと思いたいが
- 334 ：名無しさん＠編集中 ：2018/03/28(水) 21:19:11.47 ID:JTuwsH9C0.net
- でもそもそもの計算の複雑さがHEVCの10倍とかあるんでしょ?
特許に引っ掛かるので仕方ないといっても流石に酷いように思う
- 335 ：名無しさん＠編集中 ：2018/03/28(水) 22:40:00.04 ID:TX9eYU740.net
- x265だってクッソ遅くてやってらんねーのに
- 336 ：名無しさん＠編集中 ：2018/03/28(水) 22:45:45.37 ID:DkDQClUJ0.net
- 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/
- 337 ：名無しさん＠編集中 ：2018/03/28(水) 22:48:29.37 ID:DkDQClUJ0.net
- Introducing the Industry’s Next Video Codec: AV1
https://blogs.cisco.com/collaboration/av1-video-codec
- 338 ：名無しさん＠編集中 ：2018/03/28(水) 22:52:36.11 ID:KWy8aHMRp.net
- なんかロゴが折り紙のように見える
もしかして折り紙的な技術が使われてるとか？
- 339 ：名無しさん＠編集中 ：2018/03/28(水) 22:52:50.57 ID:1p2enfpya.net
- 放送に採用されないコーデックは、どこまでいっても中途半端
ライセンス逃れを開発理由の一つにしている時点で、自ずと限界は来る
- 340 ：名無しさん＠編集中 ：2018/03/28(水) 22:54:26.95 ID:DkDQClUJ0.net
- Google, Microsoft, Amazon release AV1 compression technology for better streaming video - CNET
https://www.cnet.com/news/netflix-youtube-streaming-video-is-about-to-get-a-lot-faster-av1-compression/
- 341 ：名無しさん＠編集中 ：2018/03/28(水) 23:03:54.41 ID:DkDQClUJ0.net
- aomのコードはまだリリースタグはついてないのか。
- 342 ：名無しさん＠編集中 ：2018/03/28(水) 23:37:59.33 ID:FSdNM0II0.net
- 標準品質で同じ動画を変換するとx264よりx265はどんだけ遅いんだ？
- 343 ：名無しさん＠編集中 ：2018/03/28(水) 23:54:01.29 ID:tB8dFHAWd.net
- ストリーミング時代に放送がどこまで生き残れるかっていう問題が
- 344 ：名無しさん＠編集中 ：2018/03/28(水) 23:57:41.47 ID:DkDQClUJ0.net
- >>342
そんなんソースや設定とかによるからなあ。
とりあえずベンチマークスレで色々な環境での結果を見てくるといいんじゃないだろうか。
【x264/x265】実用エンコベンチ Part6
http://egg.5ch.net/test/read.cgi/jisaku/1507728392/
- 345 ：名無しさん＠編集中 ：2018/03/29(木) 00:40:49.60 ID:wfTjtMTVd.net
- 俺のRyzen3 2200GだとフルHDの30fpsの動画でx264で20fps、x265だと5fpsくらいしか出なかった記憶がある。まあ普段はHWエンコードしてるんだけど
- 346 ：名無しさん＠編集中 ：2018/03/29(木) 01:31:18.21 ID:yJcJr/Yv0.net
- もう、昔より半導体の微細化のペースとか遅いんだから、
解像度上げるペースとか新しいコーデック開発するペースも遅くしろよ。
- 347 ：名無しさん＠編集中 ：2018/03/29(木) 01:40:01.16 ID:3HDmcthRM.net
- >>342
同等の量子化係数でブン回しても6倍以上は重くて、売り文句みたいに2倍も縮むのは希で2/3ぐらい
- 348 ：名無しさん＠編集中 ：2018/03/29(木) 08:11:10.11 ID:aTEBv0AB0.net
- >>336
Appleからの歓迎コメントがない・・・
- 349 ：名無しさん＠編集中 ：2018/03/29(木) 09:23:09.44 ID:/JmJOkBAM.net
- >>347
自分環境かつ自分がよくエンコするソースでベンチ取った時
x264のslow?slower?よりx265のfastの方が1.3倍速くて1.6倍程度ビットレート比で綺麗だったから重用してる。
ソース次第やね
- 350 ：名無しさん＠編集中 ：2018/03/29(木) 11:50:46.91 ID:Sz3XH2/20.net
- >>348
Founding Membersの中ではIBMのコメントも無いね。
Appleは入ったのが今年１月だし、まだ様子見ってのもあるのかもね。
- 351 ：名無しさん＠編集中 ：2018/03/29(木) 11:59:27.77 ID:Sz3XH2/20.net
- 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に買収されてるそうだ。
- 352 ：名無しさん＠編集中 ：2018/03/29(木) 12:29:54.99 ID:IEct+tAwMNIKU.net
- >>349
そりゃプロファイル変えていればね
プリセットを変えればH265のコア部以外の「x265やx264が実装している工夫の部分」で重さが大きく変わる
- 353 ：名無しさん＠編集中 ：2018/03/29(木) 12:30:54.42 ID:IEct+tAwMNIKU.net
- >>352
プロファイルじゃないや、プリセットだね
- 354 ：名無しさん＠編集中 ：2018/03/29(木) 13:04:48.16 ID:51r+c9a8MNIKU.net
- 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の設定はここらへんが妥協の境界になりそう
- 355 ：名無しさん＠編集中 ：2018/03/29(木) 13:48:04.34 ID:2l+rGyKqMNIKU.net
- QSVの場合だと、SSIMの0.985挟むcrf（ICQ）がH264でICQ 20〜21、HEVCでICQ 22〜23あたり
もちろんソースの動きや画の内容で左右される部分は有るけど、うちのところで基準にしてるソースでSSIM拾った感じはこんな感じになってる
- 356 ：名無しさん＠編集中 ：2018/03/29(木) 14:14:56.73 ID:F3GGU69n0NIKU.net
- >>354
こういう理論的なものと経験則が合致してたらちょった嬉しい
ちなみにx265は --rect --limit-modes を付けたときの画質向上率が凄いと思う
- 357 ：名無しさん＠編集中 ：2018/03/29(木) 16:12:48.52 ID:caRlMFDo0NIKU.net
- ようやくAV1が表に出てきたと聞いて飛んできました
自分の使い方だと265は264比で大体エンコ時間3倍強でサイズ3割減ぐらいかなぁ
コーデック乗り換えって労力大きいから、ここから乗り換えるとなると
AV1には相当頑張ってもらわないとならない
- 358 ：名無しさん＠編集中 ：2018/03/29(木) 17:31:38.63 ID:uSRvzlAxMNIKU.net
- >>356
rectはブロックサイズのパターン増えるから捜査処理増えるるけど縮むよね
個人的にはrect入れるならampも入れちまう様にしてる（更に遅くなるけど
※両方とも初期値で無効、ampはrect有効時のみ使用可
あとは--limit-modesはplaceboプリセットじゃないと有効になっていないはずなんで記述する必要は無いかも
比較測定値的なSSIMは下がるけど、人間の知覚的判別しづらいところで圧縮稼ぐpsy系オプションも面白い
psy-rd（デフォルト0.3）とか、表示環境のパネルサイズや解像度に合わせてとかで上げてやると量子化が捗る
- 359 ：名無しさん＠編集中 ：2018/03/29(木) 18:06:51.46 ID:F3GGU69n0NIKU.net
- >>358
aviutlのGuiEXだとslowプリセットでlimit-modesも有効になる
揚げ足をとるみたいだけど今の--psy-rd のデフォは2.0のはずだよ
x264と同じくx265も、ギリギリのSIMM値を狙うなら半分ぐらいでちょどいい（--psy-rd）
- 360 ：名無しさん＠編集中 ：2018/03/29(木) 18:41:24.30 ID:Sz3XH2/20NIKU.net
- >>358
--limit-modesはslow〜veryslowで有効、それ以外はplaceboも含めて無効。
(というかここまで詳細な話はx265スレでやった方が良い気も)
http://x265.readthedocs.io/en/default/presets.html#presets
https://bitbucket.org/multicoreware/x265/src/1fafca24a3990106ecf203afc4e900fa0eddfbe1/source/common/param.cpp?at=default&fileviewer=file-view-default#param.cpp-393
- 361 ：名無しさん＠編集中 ：2018/03/29(木) 19:20:41.29 ID:0fgUeEol0NIKU.net
- HEVC/H.265対抗の動画コーデック「AV1」が正式リリース
〜ロイヤリティフリーで利用可能、HEIF対抗も登場か
https://pc.watch.impress.co.jp/docs/news/1114268.html
- 362 ：名無しさん＠編集中 ：2018/03/29(木) 21:55:48.46 ID:r/53oFMMMNIKU.net
- >>343
いまどき同軸ケーブルだの分波器だの時代錯誤だわな
B-CASカードの次はACASチップ内蔵で利権ウマウマ
- 363 ：名無しさん＠編集中 ：2018/03/29(木) 22:15:44.03 ID:5siG2sKR0NIKU.net
- バイナリ置いとくわ
https://www.axfc.net/u/3899330.7z
- 364 ：名無しさん＠編集中 ：2018/03/29(木) 22:21:41.76 ID:Vw8NIuSYHNIKU.net
- ACAS＋HEVC＋ACASで海外家電メーカーの参入妨害
利権大国日本
- 365 ：名無しさん＠編集中 ：2018/03/29(木) 22:28:23.96 ID:zuIbo6KKMNIKU.net
- >>360
なるほど、支障が無い限り更新していないから自分バイナリはプリセットが古いのかもしれない、thx
psy-rdは処理的にピクセル単位の径なんで1.0以下が良いね
動きに対する対応考えればそこから1/2なり1/3するイメージで、逆に動きが無ければバイピクセルな1.0にという感じかと
…とここらへんにしとくか
- 366 ：名無しさん＠編集中 ：2018/03/30(金) 00:08:19.72 ID:KTEhNckb0.net
- 将来、「放送」で生き残るのはＮＨＫだけかな
民放は系列がだんだん減っていくね。
特に危ないのは、フジ系とテレ朝系
- 367 ：名無しさん＠編集中 ：2018/03/30(金) 00:43:07.92 ID:mF7ijfowM.net
- HM比でMH並みの標準実装・最適化で1.3倍の圧縮効率なんだろうし
H264比で約2倍を謳っていたH265/HEVCが、実効ではアベレージ1.6倍程度な事考えると
エンコーダがより重くなるのは確かだし、実質ライセンス料の影響が殆ど無い、個人運用の自炊エンコ用途で何処まで期待して良いものか
x265水準で作り込まれたとしは重くなりそう
上の方で有るみたいに、x264で重いプリセット使うよりはx265で軽めのプリセット使う方が軽くて縮むみたい範囲で使える範囲なら良いけどな
- 368 ：名無しさん＠編集中 ：2018/03/30(金) 01:03:24.41 ID:+cp2612r0.net
- 逆に同じビットレートなら、x264よりx265の方が高画質になる？
その時もやっぱりx265の方が、1.4倍くらい時間かかるかな？
- 369 ：名無しさん＠編集中 ：2018/03/30(金) 03:44:46.29 ID:wQ7yBQFy0.net
- >>303
すまん、例のフィルタって何？
- 370 ：名無しさん＠編集中 ：2018/03/30(金) 03:47:04.23 ID:wQ7yBQFy0.net
- あ、>>308か
- 371 ：名無しさん＠編集中 ：2018/03/30(金) 06:40:08.64 ID:jiYPersza.net
- 逆にってなんだよ
- 372 ：名無しさん＠編集中 ：2018/03/30(金) 09:56:17.54 ID:8ShvYluz0.net
- 個人的にはx265から1割削れて時間5割り増しぐらいに収まれば御の字だと思って居る
- 373 ：名無しさん＠編集中 ：2018/03/30(金) 11:50:29.53 ID:56xXezFGa.net
- 5割増なんかﾑﾘﾑﾘﾑﾘ、ｶﾀﾂﾑﾘよ
- 374 ：名無しさん＠編集中 ：2018/03/30(金) 12:13:54.84 ID:ns1V5Mltp.net
- 符号化性能うんぬんより、特許料ってそんなに重かったのね。新興のコーデックIP会社が中国、アメリカからたくさん出てきて、技術的に枯れるといいなぁー。
- 375 ：名無しさん＠編集中 ：2018/03/30(金) 12:19:52.31 ID:HxLVTXPU0.net
- 圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
と、最近ファイル圧縮のZstandard型式ってのを知って思った
いや、ハードウェアエンコードすりゃいいってなるけどそれじゃつまんないし…
設定次第で早さか圧縮率かを上下幅広く調節できるようなのが見てみたい
- 376 ：名無しさん＠編集中 ：2018/03/30(金) 12:24:35.80 ID:I+cSUfY10.net
- >圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
それだと旧規格のh.264で十分ってなる
- 377 ：名無しさん＠編集中 ：2018/03/30(金) 14:56:53.02 ID:5XG6WxmW0.net
-
2018/03/29時点のAV1エンコーダー/デコーダー(aomenc.exe/aomdec.exe)のヘルプ
https://pastebin.com/SsJtwwhX
- 378 ：名無しさん＠編集中 ：2018/03/30(金) 16:40:42.73 ID:5XG6WxmW0.net
- 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日かかる計算になった・・・。
- 379 ：名無しさん＠編集中 ：2018/03/30(金) 17:45:06.52 ID:56xXezFGa.net
- 非現実的すぎる処理時間に見合う価値は今のところ存在しないな
- 380 ：名無しさん＠編集中 ：2018/03/30(金) 18:17:44.92 ID:lNA8QDqbd.net
- スピードは結局改善しないままリリースしたんだな、HWエンコでどこまで早くなるかにもよるけどかなり厳しいだろこれ
YouTubeとか、これから新規にアップされる動画のエンコとか出来るのか？さらに既存の動画をエンコするのとか不可能に近いのでは
- 381 ：名無しさん＠編集中 ：2018/03/30(金) 18:26:36.87 ID:M/tVUrz7a.net
- ワロタ
何をそんなに計算しているのか
- 382 ：名無しさん＠編集中 ：2018/03/30(金) 18:54:53.75 ID:B0XZfDV10.net
- 最適化やってないからまだ改善もクソもないよ
- 383 ：名無しさん＠編集中 ：2018/03/30(金) 19:17:06.49 ID:KbyNBHD+0.net
- 動画エンコードは、GPUとかの超並列化の恩恵受けられないんですかね
- 384 ：名無しさん＠編集中 ：2018/03/30(金) 19:25:43.85 ID:O43nmN/P0.net
- >>383
ハードウェアエンコードもGPGPU（シェーダ）ではなくて動画処理専用固定回路でやってるから、
GPGPUだとやりにくいんじゃないの
- 385 ：名無しさん＠編集中 ：2018/03/30(金) 19:47:40.55 ID:K8WvML30M.net
- 中身的にはSIMD頼みの力押しでマルチスレッド化が進んでない感じ
デコーダも同様というか、H265以上に設計レベルで再生に掛かる演算負荷軽減する気無さそう
最初っからハード屋抱き込んだアライアンスになる訳だわこりゃ
- 386 ：名無しさん＠編集中 ：2018/03/30(金) 19:54:46.49 ID:/P9igK1z0.net
- だから何としか
- 387 ：名無しさん＠編集中 ：2018/03/30(金) 22:49:19.58 ID:m5K5pN7rH.net
- x264 mediumくらい縮んでx264 mediumより速くて使用料タダ
のが欲しい
- 388 ：名無しさん＠編集中 ：2018/03/30(金) 23:26:32.20 ID:Dpl0S177a.net
- x264でもopenCL使えるやん
SIMD使うより速いぞ
- 389 ：名無しさん＠編集中 ：2018/03/31(土) 00:53:14.67 ID:hznG5K140.net
- AV1にライセンス疑惑あり
- 390 ：名無しさん＠編集中 ：2018/03/31(土) 00:56:57.23 ID:It4c3/iy0.net
- GPGPUの話は前スレでバトルあったのでそれ参照。
結論としては、
x264やx265の開発に実際に関わってる人の話を聞ければ信憑性高いが、
現状このスレにいる人の知識では何を信じていいのかわからんってことにww
- 391 ：名無しさん＠編集中 ：2018/03/31(土) 01:43:45.77 ID:QxlbXBFG0.net
- AV1のエンコってwaifu2Xくらいかかんのか…いやニューラルエンジンがある今はAV1の方が…
- 392 ：名無しさん＠編集中 ：2018/03/31(土) 02:03:48.32 ID:odEcJpjT0.net
- 各エンコーダのプリセット毎に、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
- 393 ：名無しさん＠編集中 ：2018/03/31(土) 03:56:08.25 ID:7Lq4pL0rM.net
- 適したスレが無さそうなのでここで聞くけど
BRAVIAで再生する時、XAVC S 30p 100Mbpsと60p 150Mbpsってどちらが高画質だと思う？
モーションフローで30pも60p化されて再生されるとして
30pは60pの半分しかフレーム数/秒がないけど、ビットレートは2/3あるから1フレーム当たりの情報量は30pの方が33%多い
パッと見モーションフローは、かなりきれいに中割りコマ生成してる、時々破綻してるけどw
- 394 ：名無しさん＠編集中 ：2018/03/31(土) 06:04:46.28 ID:gfuajWwSa.net
- 画質なら30のほうが良いだろうよ
24にすればもっと画質は良くなるぞ
- 395 ：名無しさん＠編集中 ：2018/03/31(土) 08:15:06.95 ID:hdFdnZ7Ya.net
- どこが次世代の話だよ
- 396 ：名無しさん＠編集中 ：2018/03/31(土) 08:20:23.08 ID:28VsBo+5a.net
- 昨日今日規格が固まって普及はこれから、ってのが次世代じゃなきゃどんなのが次世代なんだ
規格が決まった瞬間あらゆるデバイスやサービスに浸透するわけじゃ無いんだぜ？
- 397 ：名無しさん＠編集中 ：2018/03/31(土) 08:24:17.82 ID:28VsBo+5a.net
- ああXAVCの話か
HEVCもこのスレの対象なんで仲間にいれてあげてもいいんじゃない？
- 398 ：名無しさん＠編集中 ：2018/03/31(土) 08:30:57.34 ID:ZmwRNZhu0.net
- >>393
解像度が書かれてないと思うけど
フルHDならHEVC, h.264ともに10Mbpsあれば十分なことを考えると
両者ともに高画質だと思う
- 399 ：名無しさん＠編集中 ：2018/03/31(土) 08:32:22.51 ID:GgHgjFx90.net
- HEVC専用スレの方ももうちょっと活用されてもいいのにとは思う
- 400 ：名無しさん＠編集中 ：2018/03/31(土) 08:50:46.11 ID:vFJMFRqxM.net
- >>393
ソースが30pかどうかにもよる
- 401 ：名無しさん＠編集中 ：2018/03/31(土) 10:03:57.04 ID:70L+3RS5p.net
- >>393
でも60pの方がフレーム間の差が小さいから、圧縮効率良さそうじゃない？
- 402 ：名無しさん＠編集中 ：2018/03/31(土) 10:18:31.32 ID:hznG5K140.net
- こんなスレで業務用途のコーデックの話なんか聴いても、まともに答えられるやつなんかほとんどいないだろ
このスレにいる奴の大半はアニメのエンコードばかりしているようなのばかりだ
- 403 ：名無しさん＠編集中 ：2018/03/31(土) 10:20:54.96 ID:8ECVPH3aM.net
- いきなり自己紹介されても
- 404 ：名無しさん＠編集中 ：2018/03/31(土) 10:30:15.52 ID:isuj0kQw0.net
- 単純に考えて、100Mbpsで30pなら60pの場合は200Mbpsで同等画質じゃないのか？そんな簡単な話でもないんかね？
- 405 ：名無しさん＠編集中 ：2018/03/31(土) 11:13:30.34 ID:K2NT3dmHd.net
- GOP的な圧縮は画像シーケンスと違って差が小さければ圧縮効率良くなるなら60pはその分圧縮率上がるのでは？
190Mbpsになるのか150Mbpsになるかは知らんが。
- 406 ：名無しさん＠編集中 ：2018/03/31(土) 11:36:50.39 ID:RvXB0Q6+0.net
- 30→60だとフレーム間予測が効いて、順当には必要ビットレートは増えないと思うけど
ビデオカメラのリアルタイムエンコードだと、そうでもないのかもしれない
- 407 ：名無しさん＠編集中 ：2018/03/31(土) 11:42:39.82 ID:ykF7JQcmM.net
- 元ソースが30pとして、単に補完フレームの破綻防止に同じ画の繰り返しでもフレームレート有った方が良いのなら意義はあるのだろうけど
データ容量的に1.5倍の価値が有るかの判断は視覚評価だし、基準は当人であって他人じゃ無いしな
再生するデータの動き内容とか、そのTVの性能に依存するものだし、そもそも他人が容易に判断付くものじゃない
こんな事他人に頼る個人が生成出来るソース規模でも無いし、著作権的にアレな4Kデータとかじゃねーの？
スルーで良いと思う
- 408 ：名無しさん＠編集中 ：2018/03/31(土) 11:53:37.40 ID:s8TNa5OjM.net
- XAVC Sって半民生向けよね
- 409 ：名無しさん＠編集中 ：2018/03/31(土) 12:01:54.84 ID:YdOGGYyO0.net
- 確かに30pより60pの方が差分が小さくて、処理も軽くなりGOP圧縮効率上がる
QFHD150Mbps 60pってのは、LongGOPならなかなかいい線かも？
30p 1/60シャッター、24p 1/48シャッターでパラパラ撮ってるものがほとんどで、TVのように再生側ハードで倍速や4倍速120pなんてのも普通にある現状
圧縮効率とコマ数とビットレートと3つの相関を知り尽くしてる人なんて、メーカー技術者の上位数人くらいか
- 410 ：名無しさん＠編集中 ：2018/03/31(土) 12:11:37.95 ID:jy+pD5jF0.net
- >>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/
- 411 ：名無しさん＠編集中 ：2018/03/31(土) 12:30:19.71 ID:70L+3RS5p.net
- >>408
半というか完全に民生向けじゃないの？
でも4K 60p 150Mbps で撮影できるカメラって民生用であったっけ？
ハンディカムやαシリーズでも4K 30p 100Mbpsまでしか対応してなかったような
- 412 ：名無しさん＠編集中 ：2018/03/31(土) 17:15:06.54 ID:YdOGGYyO0.net
- >>411
そう民生向けだけど、FDR-AX1だとXAVC SでQFHD 60p 150Mbps XQDに撮れるから、この構成や性能は業務機
https://www.sony.jp/handycam/products/FDR-AX1/feature_1.html
- 413 ：名無しさん＠編集中 ：2018/04/02(月) 17:13:28.56 ID:oPPos9Iy0.net
- 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倍程度に下がると思われる。
その他、特許面の話なども含む良記事。
- 414 ：名無しさん＠編集中 ：2018/04/02(月) 17:13:37.45 ID:9gr2nxn90.net
- 4KをQFHDと呼ぶのが主流なの？
それはさておき、そもそも補完される画は完璧じゃない(当然破綻もある)から、それ考えると60pの方がいいとは思う。
破綻しないような簡単な映像なら30pも60pも差は出ないだろうし。複雑で破綻するような映像ならば60p一択だろ。
蛇足だが、フレーム補完は無視して、フレームレートは30pでいいというなら、単純に考えて画質は30pの方がいい。
- 415 ：名無しさん＠編集中 ：2018/04/02(月) 17:21:35.97 ID:ZeLxJCDAa.net
- VP9の100倍ワロタ
- 416 ：名無しさん＠編集中 ：2018/04/02(月) 18:47:58.74 ID:osbzaKkp0.net
- 100by遅い→使いものにならないと自白
年末まで待て。それでもかったるい結果が予想される
- 417 ：名無しさん＠編集中 ：2018/04/02(月) 18:54:52.32 ID:Sc8XCrCD0.net
- x265もリリースしたての時は全然速度出なかったろ
いきなり最適化されたものが出てくるわけない
- 418 ：名無しさん＠編集中 ：2018/04/02(月) 19:16:00.41 ID:1iHpNus20.net
- ハードエンコの有無っぽい数字だな
VP9はある程度立ち上がって
誰でも効果を確認出来るし…
決まったかな？
- 419 ：名無しさん＠編集中 ：2018/04/02(月) 21:10:47.61 ID:ggAtiSao0.net
- 30%程度の効率改善程度では、コーデックを切り替えるほどの意味はない
せめて平均で50%の改善がないとな
- 420 ：名無しさん＠編集中 ：2018/04/02(月) 21:56:53.59 ID:oPPos9Iy0.net
- >>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のストリーミング市場での成功は約束されたようなものだ。
- 421 ：名無しさん＠編集中 ：2018/04/02(月) 22:05:12.36 ID:ggAtiSao0.net
- UHD-BDだけならともかく、放送にも採用されたHEVCをプゲラッチョとか、頭悪いにもほどがある
- 422 ：名無しさん＠編集中 ：2018/04/02(月) 22:29:51.94 ID:oPPos9Iy0.net
- いや、ストリーミング市場限定の話として書いてあることくらいわかるだろ・・・
- 423 ：名無しさん＠編集中 ：2018/04/02(月) 23:09:39.49 ID:EF/PBVqKM.net
- 記事の紹介や和訳には感謝だけど、個人の主観混ぜ込むのは誘導にも似た効果も含むから控えた方が良いと思う
- 424 ：名無しさん＠編集中 ：2018/04/02(月) 23:26:26.38 ID:w08Zt+n5a.net
- 結局、延々と264が続くことになる
まで読んだ
- 425 ：名無しさん＠編集中 ：2018/04/02(月) 23:31:33.78 ID:/LEGdCOu0.net
- そもそも、ライセンス料払いたくないストリーミング業者向け作った規格だから
- 426 ：名無しさん＠編集中 ：2018/04/02(月) 23:36:23.24 ID:oPPos9Iy0.net
- >>423
原文は示してあるし特に主観ってわけでもないんだけど、ややふざけすぎた感はあるので気を付けます。
- 427 ：名無しさん＠編集中 ：2018/04/02(月) 23:57:19.16 ID:osbzaKkp0.net
- >>426
気にすんな。全然OK。このくらいがむしろ好ましい
細かいことに突っ込んでくる神経質なやつは必ずいるものだからな
- 428 ：名無しさん＠編集中 ：2018/04/03(火) 00:25:03.29 ID:72Pkn5C60.net
- VP9で充分やん
- 429 ：名無しさん＠編集中 ：2018/04/03(火) 00:37:22.30 ID:2F/e5DdnM.net
- 個人運用の範囲じゃライセンス問題の影響極小だし
コンテンツ提供側は金儲けに直結してる分ライセンス料取られるから必死だけどね
HEVCはコンテンツ当たりにのライセンスフィーはディスク1枚当たり$0.0225、データで1タイトル当たりなら更に半額で、ストリーム配信なら無料
ハードウェアもライセンスが一番高い4Kテレビで1台で$2以下、モバイル端末は$1しない
安価なセットトッブボックスで価格の〜1.6%程度
大抵は対応プロファイルの範囲が限られるのでもっと安くなる
消費者の立場として、コンテンツの消費に掛かる額は数円とか、再生機器でも4Kテレビや高価な機器でも2百数十円で、消費意欲を左右するレベルじゃ無い
代理店や問屋の流通での中抜きの方が遙かに影響が大きい
扱い量が大きい事業者側はそれなりに纏まった額になるから、払わないで済むなら払いたくないから、単価の具体額示さず「ライセンスガー」と後押しを求める方向の風潮を作りたがる
事業者は最低$25000/年取られるが、$4000万/年の支払額上限もあるうえ
更に多くの場合は現地の源泉税の控除分が適応した分の実質支払いで済んでたりもする
- 430 ：名無しさん＠編集中 ：2018/04/03(火) 00:53:24.91 ID:+IqN0nMh0.net
- でも、そもそもパテントのことをぎゃーぎゃいうなら最初からvp9でよくね?仕切り直して新しいコーデック作りゃなんとかなると思ってんのか。googleは孤軍奮闘で今まで頑張ってたが。他の配信企業なんなんよ。
- 431 ：名無しさん＠編集中 ：2018/04/03(火) 01:22:44.42 ID:vkTvpMzh0.net
- VP9は悪くはないが4K8K時代に使うには圧縮効率が物足りないし、
Googleが孤軍奮闘してるだけじゃ普及も進まないからアライアンス組んで新規開発したんだと思うけど。
- 432 ：名無しさん＠編集中 ：2018/04/03(火) 01:32:14.06 ID:gUqfHQrn0.net
- 4K8K放送のcodecって決まってるんだっけ？
今年12月だからあと8ヶ月か
- 433 ：名無しさん＠編集中 ：2018/04/03(火) 03:44:39.98 ID:Ausww4X10.net
- >>432
放送ならHEVCに決まってる
- 434 ：名無しさん＠編集中 ：2018/04/03(火) 03:46:14.32 ID:ryppP+Nj0.net
- あと8ヶ月で決まってないとかありえないだろｗ
- 435 ：名無しさん＠編集中 ：2018/04/03(火) 06:19:37.35 ID:D/KfabLY0.net
- Software Infrastructure Global Viewpoint – March 2018
Assessing HEVC Versus AV1: Round 1
https://www.thebroadcastbridge.com/home/category/software-infrastructure/entry/10718/assessing-hevc-versus-av1-round-1
- 436 ：名無しさん＠編集中 ：2018/04/03(火) 09:03:12.78 ID:L7yuzpKm0.net
- Netflixとかはやっぱオリジナルコンテンツだけでも全部4kで配信したい！って考えてるんじゃないかな、そうなるとVP9やHEVCでは足りないのかもね。日本の平均ネット速度は17Mbpsらしいけど世界平均は6Mbpsらしいし
- 437 ：名無しさん＠編集中 ：2018/04/03(火) 09:19:42.50 ID:j00SyjWW0.net
- >>430
ネットを主軸に活動してる主要企業が集まることのほうが重要なんでは
- 438 ：名無しさん＠編集中 ：2018/04/03(火) 09:26:18.94 ID:WshddpOhM.net
- 放送波の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が変態過ぎるんだな
- 439 ：名無しさん＠編集中 ：2018/04/03(火) 09:52:27.94 ID:WshddpOhM.net
- まぁそれでもUltraFast〜FastプリセットよりSSIMが上にはなってることは確かだから、素のHEVCだけよりは高画質なのは確かなんだろうけどね
x265相手でコレなら、x264にすらオプション巧く使われたら追いつかれるかもしれない
OpenSourceのプロジェクト化されて、x264やx265の開発やってる連中がソフトエンコーダ開発に参画してくれば化けるかもだけど、x265でも手が回ってない部分も有るし難しいかなぁ
- 440 ：名無しさん＠編集中 ：2018/04/03(火) 11:01:39.67 ID:hboypAjzM.net
- >>437
ネット主軸の事業者は、貧乏なところが多いし、事業自体が短命に終わっているケースが多いから、数を集めることに意味はない
- 441 ：名無しさん＠編集中 ：2018/04/03(火) 12:25:45.97 ID:j00SyjWW0.net
- >>440
Google, NetFlix, Amazonが貧乏で短命とな
- 442 ：名無しさん＠編集中 ：2018/04/03(火) 13:15:40.31 ID:uy28RzoC0.net
- 日本語の読解力なんとかしなよ…
- 443 ：名無しさん＠編集中 ：2018/04/03(火) 13:43:01.90 ID:RUFJesKM0.net
- 主要の2文字を見ていないとすれば話は通る
- 444 ：名無しさん＠編集中 ：2018/04/03(火) 14:00:17.99 ID:5gh3/G+j0.net
- まあ意味の取り違えとかには気を付けるとして．．．
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
開発企業が特許で利益を得ようとするのは当然のことで仕方ないとは思うんだけど、なんともなあ・・・。
- 445 ：名無しさん＠編集中 ：2018/04/03(火) 14:26:17.23 ID:wCoYoMR7d.net
- 売って開発企業が利益を上げたところでトロールだけ制裁加えれば問題無い
- 446 ：名無しさん＠編集中 ：2018/04/03(火) 18:43:38.38 ID:mSfnhtwEM.net
- トロールなんかに金払う必要ないわ
とっくに消尽されてる特許に値札なんかつかない
- 447 ：名無しさん＠編集中 ：2018/04/03(火) 20:37:18.45 ID:OgIkUsW5M.net
- パテントの一次受けが決まっているんだから、それを飛び越してライセンシーに請求しても、HEVC Advanceと契約してパテント料支払っているんだから、HEVC Advanceに請求しろとなる
トロールの連中が勝手に関連特許のライセンス条項変えても、それを監視して対応するのはHEVC Advanceだからな
ライセンサーのHEVC Advanceには請求通るかもだが、関連特許保有者がHEVCライセンシーへの直接請求を通すのは難しい
- 448 ：名無しさん＠編集中 ：2018/04/03(火) 20:53:07.75 ID:g84DrQPB0.net
- >>438
激遅な上に画質も大したことない
完全な死に規格だな…
- 449 ：名無しさん＠編集中 ：2018/04/03(火) 21:09:08.35 ID:GqRPacca0.net
- 早漏かよ
- 450 ：名無しさん＠編集中 ：2018/04/04(水) 13:55:49.56 ID:axCfnGfR00404.net
- 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コンテンツ配信に対して
> ライセンス及び実施料の徴取を行わないという同社の決定に対する市場からの好意的な反応の中行われた。
- 451 ：名無しさん＠編集中 ：2018/04/04(水) 18:38:12.46 ID:y23XsAPx00404.net
- え？ HEVC>VP9だろ？
世代的にもVP9の方が一つ遅いって認識なんだが…
VP9→HEVC→AV1なのでは…
- 452 ：名無しさん＠編集中 ：2018/04/04(水) 20:49:00.02 ID:GGoNjvcpM0404.net
- 早い遅いはコードの差も有るから、コーデック自体の比較では何とも言えないでは？
画質容量比的なものなら、H264＜VP9≦HEVC≦AV1 ぐらいで、あとはエンコーダ実装次第で前後するだろうけど
- 453 ：名無しさん＠編集中 ：2018/04/05(木) 00:36:47.46 ID:E/6Z4gwq0.net
- >>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
- 454 ：名無しさん＠編集中 ：2018/04/05(木) 00:39:31.08 ID:E/6Z4gwq0.net
- >>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）の自ビルドにも流用できる。
- 455 ：名無しさん＠編集中 ：2018/04/05(木) 01:56:11.81 ID:VVbezlj2M.net
- 再度の検証お疲れ様
気になる点
何で一般的なGOP長に満たないフレーム数を使用しているのか
一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
あと、SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
- 456 ：名無しさん＠編集中 ：2018/04/05(木) 02:52:00.40 ID:E/6Z4gwq0.net
- >>455
> 何で一般的なGOP長に満たないフレーム数を使用しているのか。
> 一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
そうなんだけど、見てわかるとおり、今のAV1エンコードは死ぬほど時間がかかるから。
とりあえずFHDのエンコード時間の目安を知りたかったというのが今回の一番の目的。
VMAFやSSIM等はついでに測っただけ。
次は長めのサンプルも試したいが・・・時間かかるのを覚悟でFHDに挑むべきか、妥協して解像度を下げるべきか・・・。
> SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
x264やx265の--ssimで出力されるのが SSIM Mean Y なのでなんとなく。Allを拾った方がいいかな？
- 457 ：名無しさん＠編集中 ：2018/04/05(木) 03:59:11.36 ID:sX2SJznGM.net
- >>456
ffmpegでSSIM拾うとか
- 458 ：名無しさん＠編集中 ：2018/04/05(木) 15:58:43.97 ID:ACap5gLC0.net
- 適当なスレというか板がないのでお知らせ程度に
・ロスレス圧縮技術MPEG-4ALSを用いたコンサートホール演奏の
ハイレゾライブ配信サービス商用化に向けた説明会について
http://ottava.jp/news/2018_0404.html
HEVCと同じく次世代放送にて採用決定済みのMPEG-4 ALSを使ったライブ配信に関する話題
- 459 ：名無しさん＠編集中 ：2018/04/05(木) 16:37:44.71 ID:QNV9ilhrM.net
- 場所が無いにしても、不可逆それも画質容量比と効率が主題の次世代ビデオコーデックのスレでも板違い
情報提供で投下スレ無いならニュース行きか、ピュアAUかAV機器で捨てスレ起こせ
- 460 ：名無しさん＠編集中 ：2018/04/05(木) 16:57:34.66 ID:9t7ueEo80.net
-
ハイフレームレート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倍くらいの時間がかかったので、何か見逃してる設定があるのかもしれない。
- 461 ：名無しさん＠編集中 ：2018/04/06(金) 00:35:49.06 ID:By9McdF70.net
- 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)
- 462 ：名無しさん＠編集中 ：2018/04/06(金) 02:50:12.05 ID:FCIj/N0QM.net
- >>461
ビデオコーデックSDK 8.1の新機能
完全に再設計されたモジュール式サンプルアプリケーションにより、対象アプリケーションへの実装が容易になりました
H.264のエンコード品質を全体的に向上させる新機能として、Bフレームを参照フレームとして使用できる様になりました
（効果としてフレームの差分データ量がより節約出来るので、画質容量比が向上すると思われる）
推奨ドライバでリアルタイムHEVC 4K@60fpsのサポートが追加されました
アプリケーションから、先行取得されたビデオフレームにおいてマクロブロックに品質指定を行う新しいAPIを実装しました
この機能はイメージ領域の分類機能（Capture SDK 7.0の一部）と連携して使用出来ます
（マクロブロック単位の可変品質エンコードを可能にする実装っぽい、手間が増えるがCBRやVBR、固定品質で画質容量比の改善が望める）
- 463 ：名無しさん＠編集中 ：2018/04/06(金) 02:57:02.11 ID:+HIdoxMtM.net
- 最後については、手法的には前からある（x264とかには既に有る）実装
AV1対応の過程でAV1の標準エンコーダに有る機能で既存コーデックに使える機能は、出来た分は先に出したよ感がｗ
- 464 ：名無しさん＠編集中 ：2018/04/06(金) 03:08:35.18 ID:f7T0X8b4M.net
- Bフレームの参照の方は、Bフレームが続く場合にPフレームからの差分では無くBフレームからの差分参照出来る様になるんで、動きが少ないとか、ブロック単位でズレるだけみたいな場面でより縮む様になる
Bフレーム使う話なんで、Bフレームが使えないNVEncのHEVCには関係無し（ぉ
- 465 ：名無しさん＠編集中 ：2018/04/06(金) 10:05:41.45 ID:cVa47tLH0.net
- このSDKを使うのはNLEやエンコーダ各社？
NVEncはBフレーム使えないのは、このSDK過去版が使えなかったからではなくて？
>>464
- 466 ：名無しさん＠編集中 ：2018/04/06(金) 10:56:17.84 ID:F4bKu/VH0.net
- >>465
NVEncではH264なら元からBフレームも使えていて
HEVCだとマクロブロック捜査の方に手間食われて低レイテンシ維持出来ないから、HEVC対応したNVEnc積んだGefoce出た時からずっとBフレーム無しで、それが仕様とされてきてる（それでも当社比でH264より縮むんだけどね）
NVEncのHEVCでBフレームも有効になっていたら、SDKとしてデカいトピックすぎて書かない訳がないぐらいのネタだし、関連設定に関わる資料が追加されてるはず
- 467 ：名無しさん＠編集中 ：2018/04/06(金) 11:50:55.91 ID:YeX5u0A00.net
- >>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/
- 468 ：名無しさん＠編集中 ：2018/04/06(金) 11:58:40.99 ID:0hBfnBa7M.net
- 要するにハードウェア的にはBフレームに対応してるんだけど、それを動かすソフトウェアの開発部隊がカスしかいなかったんだろ
で、やっとまともに扱える奴が入ってきたから、まずH.264で使えるようにしたと
この流れならばいずれHEVCもやるでしょ
あとは画質次第
いくらオプション対応しても画質が伴わなければ意味はないから
もっとも、NVIDIAを語れるような目利きがいた試しはないが
- 469 ：名無しさん＠編集中 ：2018/04/06(金) 12:00:24.43 ID:0hBfnBa7M.net
- 最後、「NVIDIAに画質を語れるような目利きがいた試しはないが」に訂正
- 470 ：名無しさん＠編集中 ：2018/04/06(金) 12:08:20.30 ID:hl9eRboSM.net
- >>466
勉強になった、ありがとう
- 471 ：名無しさん＠編集中 ：2018/04/06(金) 12:10:20.58 ID:YeX5u0A00.net
- >>468
>>466も言ってるけど、NVEncではH.264なら元からBフレーム自体は使えていたよ。
HEVCの場合だけ「最大Bフレーム数はゼロだよー」と返してくるので使えなかったというだけのはず。
今回のSDK8.1での変更は、「（H.264で）Bフレームを参照フレームとして扱えるようになった」というもの。
H.264ではBフレームは元から使えてたけど、更に機能追加したよという話。
- 472 ：名無しさん＠編集中 ：2018/04/06(金) 12:13:53.13 ID:lHWnPzdj0.net
- >>464
Bフレームを参照フレームとしてというのはいわゆるb-pyramidのことでは
>>467
（下段について）
たぶんASICとかの作りこみを省いてるんだと思う
機能的には充実してるAMDより断然早かったし
h.264対応済みハードをできる限りいじらずに実装したのが今のNVEncだと思う
- 473 ：名無しさん＠編集中 ：2018/04/06(金) 12:55:24.08 ID:YeX5u0A00.net
- >>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デコードができるらしいけど。
- 474 ：名無しさん＠編集中 ：2018/04/06(金) 12:56:37.93 ID:0hBfnBa7M.net
- >>471
だからそれ、ソフトウェア開発部隊が使えるはずの機能を使えない状態にして放置してたからだろ
結局、カスであったことに変わりはない
- 475 ：名無しさん＠編集中 ：2018/04/06(金) 13:00:24.52 ID:YeX5u0A00.net
- >>474
勘違いしてたっぽいから指摘しただけ。
- 476 ：名無しさん＠編集中 ：2018/04/06(金) 13:19:52.27 ID:0hBfnBa7M.net
- おまえがな
- 477 ：名無しさん＠編集中 ：2018/04/06(金) 14:56:30.70 ID:lHWnPzdj0.net
- >>473
だから「機能的には」って「には」を付けたんだな
- 478 ：名無しさん＠編集中 ：2018/04/06(金) 15:11:30.34 ID:YeX5u0A00.net
- >>477
なるほど。（ただ、エンコード機能的に何か充実してるんだっけ？という素朴な疑問はある。エンコード以外の機能込み？）
- 479 ：名無しさん＠編集中 ：2018/04/06(金) 16:17:19.62 ID:lHWnPzdj0.net
- >>478
2Pass（おそらく先読み）によるレート制御とかBフレーム使える（Polarisでは無効化されてる？）とか機能的には充実してると言ってもいいのでは
それらを実装してるから高画質とは限らないだけで・・
ま、EU（GPUコア）使って柔軟に進化してるQSVは別格として
nvidia、AMDともにゲームの配信とかゲーム画面のキャプチャ向けの高ビットレート録画って割り切ってる感はある
- 480 ：名無しさん＠編集中 ：2018/04/07(土) 12:04:04.25 ID:ZS0HPDpc0.net
- 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でクラッシュするケースもあったし、安定するのはまだまだ先かな。
- 481 ：名無しさん＠編集中 ：2018/04/10(火) 13:29:00.05 ID:mvAZrsZe0.net
- 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 ：名無しさん＠編集中 ：2018/04/11(水) 16:49:17.77 ID:VM1ZiLn00.net
- facebookの人（？）によるAV1、x264、libvpx-vp9の比較
AV1 beats x264 and libvpx-vp9 in practical use case
https://code.facebook.com/posts/253852078523394/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/
- 483 ：名無しさん＠編集中 ：2018/04/11(水) 16:56:10.44 ID:7cYhFyubM.net
- >>482
画質は上々そうやね
x264のデフォルトの1万倍近く遅いみたいに見えるけど。
英語はよく分からないので100倍であって欲しい。
- 484 ：名無しさん＠編集中 ：2018/04/11(水) 17:53:39.39 ID:eo9l3iNh0.net
- >>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エンコードしてる人ってほぼいないだろうからわかりにくいけど・・・。
- 485 ：名無しさん＠編集中 ：2018/04/11(水) 18:01:26.52 ID:7cYhFyubM.net
- >>484
veryslowと比較してなのか…スレッド数で1桁速度が変わったとして現状x264 midiumとの比較で2000倍程度速度差があるという認識でいいのかな
x264やx265は発表から数年で速度はもとより画質も素晴らしく伸びたように思うので少なくとも今年の終わりまで気絶してから評価した方が良さそうですね
- 486 ：名無しさん＠編集中 ：2018/04/11(水) 18:10:29.71 ID:OUJRzihv0.net
- AOMのソースのところに書いてあるのと同じサンプルだね
https://media.xiph.org/video/derf/
解像度は各種あるけど、ニュース番組並に情報量低いのばっかりで、マクロブロックサイズのサイズデカいコーデックがそりゃ縮むわなという感じのばっかりなんだよな
x265との比較しないのが謎だし、AOMの中の人なんじゃないかと思ってしまう
- 487 ：名無しさん＠編集中 ：2018/04/11(水) 19:07:34.65 ID:eo9l3iNh0.net
- >>486
記事をちゃんと読んだ方がいいよ。
>>482のFacebookの実験ではderfのサンプル群は使っていない。
Facebookでよく見られてるトップ400のビデオを使っていて、
それらに関する説明（スマホで撮影したSD/HDが多いとか）も書いてる。
x265との比較が無いのは俺も残念。なんでだろね。
HEVCのライセンス料って、調査研究目的であっても請求されたりするもんなんだっけ？
あとFacebookはAOMのFounding memberだよ。
x264も0.148-snapshot-20161114-2245って書いてるけど日付からするとr2727かな。
ちょっと古いけど、まあこれはあまり影響なさそうか。
snapshotの末尾の数字ってずっと前から2245みたいだけど、何を表してるんだろ。
- 488 ：名無しさん＠編集中 ：2018/04/11(水) 19:40:14.73 ID:jzIik2pxM.net
- 8000倍とかw
- 489 ：名無しさん＠編集中 ：2018/04/11(水) 21:53:41.24 ID:oBNaTspA0.net
- エンコードにH.264の10000倍かかったとしてもエンコした動画を1回しか見ないような俺らに対して
1回エンコするだけで100万再生スタートという次元の配信業者からすれば
俺らより環境にもネットの帯域にも優しいお釣りが出るほどのリターンがあるということ
- 490 ：名無しさん＠編集中 ：2018/04/12(木) 09:11:54.62 ID:q5iqQV/z0.net
- >>489
意味が分からない。10000倍では釣り合いが取れないだろ
ネット帯域が主要命題だったのは10年〜20年前だし
- 491 ：名無しさん＠編集中 ：2018/04/12(木) 10:13:17.37 ID:VfB7DrWl0.net
- x264やx265みたいな魔改造エンコーダがまだ無いからな
対応ハード出るまで1年有るし、配信事業者側が使い始めるのも2年は先だろう
nvidiaがNVEncとCUDAの連携追加し始めていてAV1にも使えそうな実装をSDKでして来てるし
AV1の方がHEVCより物量的処理での圧縮してるから、NVEnc+CUDAの実装で何かしら出してくるかもな
有る程度纏まった形にしてるのはDGX-2みたいなTeslaを使ったコンポーネントとセットで事業者用
GeforceとかはNVEncのみでは最小限で、あとはSDK使って手前らで巧く纏めなさいよとかだろうなぁ
- 492 ：名無しさん＠編集中 ：2018/04/12(木) 10:45:25.96 ID:WANQhGIfM.net
- NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような画質水準には達していない）しか作れないみたいだから、アテにならんと思うがねぇ
- 493 ：名無しさん＠編集中 ：2018/04/12(木) 12:08:55.54 ID:L/MKuORZM.net
- NETFLIXなど大手の配信業者も多く絡んでるし可能な限りハードウェア処理し易い設計になってる可能性はまたあるとは思う
- 494 ：名無しさん＠編集中 ：2018/04/12(木) 12:54:15.28 ID:VfB7DrWl0.net
- >>492
リアルタイム配信向けの実装なだけでしょ
短時間に出来る範囲でしかやっていない
同様の事をQSVでやらせると、H264でしか出来ないうえ、NVEncのH264より汚いって知ってた？
- 495 ：名無しさん＠編集中 ：2018/04/12(木) 13:09:36.05 ID:SxbRi3C8M.net
- >>494
そんな話していないし、したいとも思わん
- 496 ：名無しさん＠編集中 ：2018/04/12(木) 13:20:02.82 ID:VfB7DrWl0.net
- NVEnc自体は、nvidiaのGRIDみたいなクラウドや、LAN内でのゲームのリモート操作のためのもので
それ自体はH264なりHEVCだから、GPUのバッファから生成する以外にも、デコーダからGPUに映像与えてやれば、任意の映像データもトランスコードしてファイルとして保存できるってだけ
ただ要望もあるから、あとからSDK7.x世代以降にCUDA使ってGPGPU的に拡張出来る様になってる
もちろんSDKでのAPI実装やサンプルに頼らず独自でやっても良いんだけど
CUDAエンコーダの頃から独自に拡張する人が殆ど現れない
エンコーダの拡張自体が糞難易度高くて、数学者的な人が実装サンプルや設計組んで、コーディングに特化した連中が最適化を進めるパターンが多い
そういう方々は既にx264やx265の方に集中しちまってる
- 497 ：名無しさん＠編集中 ：2018/04/12(木) 14:05:52.16 ID:ZcyNWyhH0.net
- >>489
趣旨はともかく、さすがに10000倍のままってことはないでしょｗ
>>490
>ネット帯域が主要命題だったのは10年〜20年前だし
そんなことないよ。流れるデータ量も激増してるし、世界にはまだまだ帯域不足のところもあるし、
配信業者にとってデータ量の削減は今も昔も極めて重要な課題。
- 498 ：名無しさん＠編集中 ：2018/04/12(木) 14:19:48.64 ID:ZcyNWyhH0.net
- >>492
> NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような
> 画質水準には達していない）しか作れないみたいだから
それを言うなら
・GPUのHWエンコーダはどれも高圧縮/高画質を求める人には向いていない（特に実写等）
・QSVとNVEncは圧縮/画質面では同程度(QSVの方がやや上？)。
エンコード速度はNVEncが圧倒。
・AMFはQSVやNVEncと比較すると一段下のレベル。
AMDのエンコード/デコード機能の出遅れはちょっと心配になるレベルでもある・・・。
という感じだと思うけどな。（根拠は>>473とか）
IntelもNVIDIAもAOMのFounding Memberだし、それなりに期待はできると思う。
AMDはPromotor Memberだけど、エンコード/デコード部門は頑張れるのだろうか・・・。
- 499 ：名無しさん＠編集中 ：2018/04/12(木) 15:01:48.50 ID:O/DjZzsid.net
- 画質重視でもYoutubeに上げる為にロスレスで圧縮するときはNVEnc使ってる
- 500 ：名無しさん＠編集中 ：2018/04/12(木) 15:19:04.50 ID:ZcyNWyhH0.net
- NVEncのロスレスって4:4:4だと聞いたけど、Youtubeはそれも受け付けてくれるのか。
なんとなく弾かれるもんだと思ってた。
- 501 ：名無しさん＠編集中 ：2018/04/12(木) 15:34:47.41 ID:n+ScPlN90.net
- そういえばx265のCUSA版があったな
https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder
長いこと更新されてないみたいだから
非主流アーキテクチャ向けの設計は広がらないみたいね
- 502 ：名無しさん＠編集中 ：2018/04/12(木) 15:52:32.56 ID:ZcyNWyhH0.net
-
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
- 503 ：名無しさん＠編集中 ：2018/04/12(木) 16:24:41.39 ID:PMHfI71Jd.net
- 詳しくは知らないというか知る由もないんだけど、NetflixとかYoutube（Google）みたいな資本力のあるところでもHWエンコしてるのか？ああいうところって一般人じゃ到底手に入らないようなスペックのコンピューターでSWエンコしてると思ってたんだが
- 504 ：名無しさん＠編集中 ：2018/04/12(木) 19:00:41.89 ID:VfB7DrWl0.net
- >>501
全てがGPGPUでCPUより効率良く処理出来る訳じゃない
x264やx265が高画質化するため手法の極一部だけなんで
大半を処理するCPUが結局ボトルネックになる
それでも僅かにCPUの負担が減るから、その分は微妙に早くはなるけど何割も早くはならない
- 505 ：名無しさん＠編集中 ：2018/04/12(木) 22:23:26.00 ID:pGR5LOdp0.net
- >>503
ああいう規模だからこそ逆に専用のASICボードとか用意してガリガリやるんじゃねーの？
- 506 ：名無しさん＠編集中 ：2018/04/13(金) 00:01:29.18 ID:ciNufoQ0a.net
- お前ら何学部卒？
- 507 ：名無しさん＠編集中 ：2018/04/13(金) 03:54:06.59 ID:d42zSzX20.net
- 人に聞くなら自分から
- 508 ：名無しさん＠編集中 ：2018/04/13(金) 04:26:47.71 ID:5+mGH86Kd.net
- 医学部
だからGPGPUとかチンプンカンプン
- 509 ：名無しさん＠編集中 ：2018/04/13(金) 09:43:04.68 ID:Iy839CtQ0.net
- >>503
SWでの高画質エンコードがされるなら
○○向け高画質エンコード（配信サイトで再エンコードされない）設定なんてのに意味がないから
ASICもしくはx264 --tune very fastレベルの高速SWエンコだと思う
- 510 ：名無しさん＠編集中 ：2018/04/13(金) 11:45:08.54 ID:+CW60tiR0.net
- >>509
> ○○向け高画質エンコード（配信サイトで再エンコードされない）設定
これが何のことを指してるのかよくわからない。Youtubeでそんなことできるんだっけ？
あとつっこんでおくと --preset veryfastじゃね。
- 511 ：名無しさん＠編集中 ：2018/04/13(金) 12:18:13.13 ID:Sg2lKLiA0.net
- GoogleのサービスでH.264トランスコードはx264だっけか
- 512 ：名無しさん＠編集中 ：2018/04/13(金) 12:38:58.40 ID:6eRFP0ta0.net
- 配信サイトで再エンコードされない設定って言うのはよく聞く誤解だね
YouTubeだとどんな動画を上げても再エンコードされる
アップロードしたあと手元の動画とSSIMなりで比較してみたら分かる
- 513 ：名無しさん＠編集中 ：2018/04/13(金) 13:23:15.76 ID:Sg2lKLiA0.net
- 昔の実装そのまま今でも一緒だと思っていたり
ニコニコの体の良いシステム負荷軽減手法と同じだと思っているんじゃないかな
- 514 ：名無しさん＠編集中 ：2018/04/13(金) 17:18:55.93 ID:Iy839CtQ0.net
- そりゃyoutubeへのアップロードに関する話題とか昔の流行だもの
- 515 ：名無しさん＠編集中 ：2018/04/13(金) 18:12:08.90 ID:qCymtqNK0.net
- よくわからんがYoutubeで再エンコードされないようにする設定があると勘違いしてたってことか。
- 516 ：名無しさん＠編集中 ：2018/04/14(土) 14:03:51.15 ID:89UFyH020.net
- 16Kまだ？
- 517 ：名無しさん＠編集中 ：2018/04/14(土) 15:38:58.48 ID:JUsYulE3d.net
- Youtubeは1回エンコされるのは確実として多重エンコにならないようにロスレスで上げるのが基本じゃないの？
- 518 ：名無しさん＠編集中 ：2018/04/14(土) 16:34:42.61 ID:yQp2n2100.net
- >>517
基本ではないでしょ。可逆はサイズもでかくなって面倒だし、
「可逆で上げた場合」と「十分高画質な非可逆で上げた場合」とで
生成された動画に目立った違いは出ないと思うし、後者で上げる人がほとんどだと思うよ。
- 519 ：名無しさん＠編集中 ：2018/04/14(土) 16:48:12.43 ID:W4h1IMs60.net
- 自分はx264 crf12ぐらいで上げてるな 16と程度と比較するどちらが綺麗かは分かるレベルだったし意味なくは無いと思う。
生成後の動画比較すると画質毎に設定やビットレート多少違うかもね
- 520 ：名無しさん＠編集中 ：2018/04/14(土) 17:48:50.77 ID:EMVmu1/I0.net
- 低いcrfほどエンコーダの差が画質に出てこなくなるから、QSVやNVEncでササッと処理済ませてアップロードし始めた方が手早いかも
放置で下準備させておく時間があるならx264だけど
- 521 ：名無しさん＠編集中 ：2018/04/14(土) 20:01:48.20 ID:yQp2n2100.net
- 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に基づいた評価としてはこんな感じになった。
- 522 ：名無しさん＠編集中 ：2018/04/14(土) 20:14:36.49 ID:NsXr+PVe0.net
- >>521
乙乙
参考になる
- 523 ：名無しさん＠編集中 ：2018/04/14(土) 22:12:23.37 ID:+/qR7O9Z0.net
- >>521
これを維持してどんだけ高速化できるかだなぁ
- 524 ：名無しさん＠編集中 ：2018/04/14(土) 23:21:16.52 ID:5o34rogK0.net
- 実用になる時間じゃないね
- 525 ：名無しさん＠編集中 ：2018/04/15(日) 02:31:59.29 ID:3zo9kCKG0.net
- libaomはリファレンスみたいなもんだし、まだ最適化もされてないから
今のlibaomのエンコード速度/時間を見てAV1の実用度を判断してはダメだよ。
libaom自体はどこまで最適化されてどれくらい速くできるのかわからんけど、
商用ではベンダーが開発したエンコーダ(SW/HW)が使われるんだろうし。
ちなみに>>521のサンプルでは-cpu-used 3 -crf20で335フレームのエンコードが約3時間4分だったけど、
crowd_run(1920x1080、500frames)は同じ設定で6時間30分かけて100フレームしか進まなかったので中止した・・・。
- 526 ：名無しさん＠編集中 ：2018/04/15(日) 21:39:15.37 ID:wDrk/oMp0.net
- very slowの17倍って今の段階なら悪く無いじゃんって思ったけどx264ならmidiumの数倍程度だけどx265だと凄いんやね
- 527 ：名無しさん＠編集中 ：2018/04/17(火) 08:58:23.81 ID:G8gaxn+mM.net
- 話題が無いので間潰しに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ウェイ処理）時の処理速度低下具合が変わってくる
- 528 ：名無しさん＠編集中 ：2018/04/17(火) 09:06:44.92 ID:7Ja6+jKC0.net
- それ知ってたら1080買ってたわ
- 529 ：名無しさん＠編集中 ：2018/04/17(火) 09:25:46.28 ID:G8gaxn+mM.net
- NVEncの処理速度的については、固定量子化でブン回す場合には、FHDでの出力ならピーク値でH264で600〜650fps、HEVCで400fps前後ぐらい（NVEncのHEVCはBフレーム省略仕様なので速度低下が少ない）
NVDecのデコードはFHDで600〜650fpsぐらいがピーク値になる
あと実行環境（NVEncを呼び出すアプリ）によってピーク値近くで動作させられるかが変わってくるので留意
例えばTVMW6だと、エンコードの前段がボトルネックで2つ同時のバッチエンコにしないとエンジンを回しきれない
お陰でエンジン2基環境の場合はどちらも回し切ることが出来ない
- 530 ：名無しさん＠編集中 ：2018/04/17(火) 09:50:40.44 ID:UuaDiTHp0.net
- はぁ、1080並の値段でELSAの1070なんてかわなければよかったｗ
- 531 ：名無しさん＠編集中 ：2018/04/17(火) 10:28:31.86 ID:G8gaxn+mM.net
- 捕捉
上の速度はPascal世代の速度で、1つ前のMaxwell第2世代だとH264なら2/3、HEVCなら1/2ぐらいの性能になる
Pascal世代でのNVEncのトピックは、HEVC速度低下が少なくなっている事なんだけど、公式なトピックに記述は無いけど、Pascalで動作クロック自体が大きく向上しているので、結果的にH264も含めた全体的なパフォーマンスも相当上がってる
Pascal世代のHEVCについては、性能低下緩和も含めてマクロブロックの捜査ロジックの改善もされている様で、Maxwell第2世代のHEVCより地味に画質が向上されている
NVEncの速度はデフォルトの動作クロックに依存（ツールによるソフトウェアでのOCはCUDAコア側のクロックが上がる仕様）なので、NVEnc目的でグラボ購入する場合には、製品の公称クロック基準で購入した方が良い
ファームウェア操作ツールでクロック上げた場合はそのまま性能に反映される
- 532 ：名無しさん＠編集中 ：2018/04/17(火) 11:01:56.07 ID:G8gaxn+mM.net
- 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のリファレンス並ぐらい回す事は不可能じゃ無い
- 533 ：名無しさん＠編集中 ：2018/04/17(火) 11:41:12.03 ID:ipT4+ZwS0.net
- GK208はNVEnc乗ってるのにGP108がなぁ
- 534 ：名無しさん＠編集中 ：2018/04/17(火) 13:13:22.45 ID:l5bingFq0.net
- こういうGeForceの型番ごとにおける機能の制限/無効化ってどこかにドキュメントとしてまとまってるの？
QuadroとTeslaはHTML上に一覧表が出来てるけど
- 535 ：名無しさん＠編集中 ：2018/04/17(火) 13:37:31.07 ID:G8gaxn+mM.net
- nvidiaのdeveloperにあるみたいな一覧は無いね
海外フォーラムでは日本よりNVEncについて掘り下げてスレが意外にあって
エンジン数についても話題に上がる
GTX1070Tiなんかも、リリース後エンジン数についてスレ立ってた
対応SDKから実機確認すれば解るんで、同時処理数も同様やね
- 536 ：名無しさん＠編集中 ：2018/04/17(火) 13:38:28.10 ID:7Ja6+jKC0.net
- そういう情報出さないで売ってるの、なんだかなって思うわ
- 537 ：名無しさん＠編集中 ：2018/04/17(火) 14:03:08.33 ID:tPz+M+Wh0.net
- NVIDIAにとっては、エンコーダーの価値はその程度にしか見ていないということ
- 538 ：名無しさん＠編集中 ：2018/04/17(火) 15:04:10.48 ID:g34xNThwa.net
- アムドが生きていればなぁ…
- 539 ：名無しさん＠編集中 ：2018/04/17(火) 15:07:05.87 ID:Ev+v4bJ00.net
- なんでAMDは動画最弱になっちゃったんだろ
動画ならRadeonなんて時代もあったのにね
- 540 ：名無しさん＠編集中 ：2018/04/17(火) 15:11:14.83 ID:GjWzJu8g0.net
- というか、実用面からすると
・NVEncを保存用エンコードに使う人はあまりいない
・NVEncで並列エンコードをする人もあまりいない
・全体的に十分以上に高速なので、高速域での速度差を気にする人もあまりいない
ということで、一般ユーザー的にはエンジン数やエンコード速度の差を重要視する人は少ないのでは。
（「実際に使うわけじゃないけど最高の機能が載っててほしい」という気持ちはよくわかるけど）
- 541 ：名無しさん＠編集中 ：2018/04/17(火) 15:18:43.64 ID:G8gaxn+mM.net
- 公表されてる範囲の機能的なスペックはエンジン1基有れば実現出来るからね
- 542 ：名無しさん＠編集中 ：2018/04/17(火) 15:37:01.40 ID:G8gaxn+mM.net
- NVDec/NVEncのSDKもnvidia的にはターゲットはTeslaやQuadroで、Geforceでも一応使えるという感じだからね
Geforceだからと全モデル1基とかにされなかっただけでも良かったとする鹿
GTX1070の1基のみ有効になってる事ネタにして、nvidiaに纏まった数の直訴なんかしたら、あの会社なら次世代からGeforceグレードは統一仕様として一律1基にしてとかやりかねんｗ
- 543 ：名無しさん＠編集中 ：2018/04/17(火) 15:44:43.10 ID:ipT4+ZwS0.net
- >>539
ip変換の質とエフェクトが充実してたって話でデコードエンジン自体はずっとnvidiaの一周遅れだよ
- 544 ：名無しさん＠編集中 ：2018/04/17(火) 15:51:52.91 ID:m7y6f3bl0.net
- Netflix: AV1 is our primary next-gen codec
http://www.csimagazine.com/csi/Netflix-AV1-is-our-primary-next-gen-codec.php
- 545 ：名無しさん＠編集中 ：2018/04/17(火) 16:11:49.90 ID:YX1SzvXBM.net
- アムドの寝言はVP9有効にして
公約果たしてからにしてほしいなw
- 546 ：名無しさん＠編集中 ：2018/04/17(火) 16:40:17.77 ID:G8gaxn+mM.net
- デコーダはVega世代で載ってなかったっけ？
- 547 ：名無しさん＠編集中 ：2018/04/17(火) 17:56:50.23 ID:kpSfcMeTa.net
- xiphがRustで作ってるav1のエンコーダって話題出てる？
リファレンスより速いって書いてあるけど
- 548 ：名無しさん＠編集中 ：2018/04/17(火) 19:02:38.88 ID:G8gaxn+mM.net
- これか
https://github.com/xiph/rav1e
国内で話題にしてる人は少なさそう、自分も今知ったわ
libaomのコードをベースに入れてるのかな？
他方の資料で
libaomのアセンブラ化で4倍は速くなる、多分100倍速く出来そうだけど、アルゴリズムの書き換えが膨大すぎるわい！
みたいな事書いてあった
- 549 ：名無しさん＠編集中 ：2018/04/17(火) 19:41:01.17 ID:QtBc3OjV0.net
- >>545 >>546
>>122でも書いたけどPolaris/VegaはVP9のDXVAデコードに対応していない。
当初は隠し機能として存在していたそうだが、それも後になって消された。
ただしDXVAとは別にOpenCLによる再生支援が利用できるMFTフィルタがあり、
ChromeやFirefoxはそれを使ってVP9再生支援を利用することができる、という状況らしい。
なおRavenRidgeはVP9のDXVAに対応している。
>>547-548
>>89で出てるね。限定的な実装みたいだし、試したことはない。
- 550 ：名無しさん＠編集中 ：2018/04/17(火) 19:59:42.94 ID:AV9r83+30.net
- ビルドして試そうかと思ったけどビルドできなくて放置してた
- 551 ：名無しさん＠編集中 ：2018/04/17(火) 21:09:13.49 ID:aZh6iL+w0.net
- これcじゃなくてrustなん？
時代はrustなのか？
- 552 ：名無しさん＠編集中 ：2018/04/17(火) 21:13:46.15 ID:0c2uycJlM.net
- RustもC言語の派生の一種と言えなくもない
- 553 ：名無しさん＠編集中 ：2018/04/19(木) 22:57:58.69 ID:hZLV04Fua.net
- Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね
- 554 ：名無しさん＠編集中 ：2018/04/20(金) 02:37:09.78 ID:zIebTadQ0.net
- MozillaのDaalaで使ってたから親和性は折り紙付きだろう
- 555 ：名無しさん＠編集中 ：2018/04/20(金) 04:41:34.60 ID:3IIJGeeBM.net
- 吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
代わりに習得がえらい難しいらしいけど
使用者に最も愛されている言語とか言うけど
愛が無ければやってられない習得難易度の裏返しだったり
- 556 ：名無しさん＠編集中 ：2018/04/20(金) 05:30:27.07 ID:HD+81Fzka.net
- >>554
Daala作ってたのはXiphだけどな
Xiphは半分Mozillaみたいなものだけど
- 557 ：名無しさん＠編集中 ：2018/04/20(金) 07:18:32.61 ID:N1qeHIsf0.net
- Daala作ってたのは誰あぁぁぁぁ
- 558 ：名無しさん＠編集中 ：2018/04/21(土) 12:52:16.94 ID:tM5w7H6r0.net
- xiphってflac作ったところなんだな
知らなかったわ
- 559 ：名無しさん＠編集中 ：2018/04/21(土) 13:21:10.75 ID:Qy2Pbsrq0.net
- ハイレゾは全く無意味とバッサリ切ったのが爽快だった
- 560 ：名無しさん＠編集中 ：2018/04/21(土) 19:19:53.26 ID:BSwSpyS80.net
- ハイレゾは無意味じゃないから間違ってるな
- 561 ：名無しさん＠編集中 ：2018/04/21(土) 20:42:38.58 ID:mCJYRNDS0.net
- https://people.xiph.org/~xiphmont/demo/neil-young.html
- 562 ：名無しさん＠編集中 ：2018/04/21(土) 23:18:19.11 ID:6E+waUvMa.net
- いや無意味だから
- 563 ：名無しさん＠編集中 ：2018/04/21(土) 23:40:10.60 ID:vIk2JOlP0.net
- そういうのはピュアAU板ってのがあるからそっちで存分にやればいいと思うよ。
ハイレゾの良さを追求するスレ ★1
https://lavender.5ch.net/test/read.cgi/pav/1491489780/l50
- 564 ：名無しさん＠編集中 ：2018/04/21(土) 23:54:04.88 ID:BSwSpyS80.net
- 耳に聴こえなくても脳に影響してるんだよ
聴覚が全てではない
- 565 ：名無しさん＠編集中 ：2018/04/22(日) 00:05:32.14 ID:qoqXsoAZa.net
- 悪影響かな
- 566 ：名無しさん＠編集中 ：2018/04/22(日) 00:30:07.28 ID:dppkcbl/0.net
- 音痴なんだろ
- 567 ：名無しさん＠編集中 ：2018/04/22(日) 12:34:11.98 ID:OUHz0R6x0.net
- 違いが分かる人と分からない人が
居るだけの話なのに
実際に目の前で見ないと信じられないのが人間
- 568 ：名無しさん＠編集中 ：2018/04/22(日) 15:46:11.93 ID:MAIw05DH0.net
- その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
ちゃんとマスタリングしてる物がほとんどだから20khz以上が切れてようがそうで無いものより綺麗っていうのはあるね
- 569 ：名無しさん＠編集中 ：2018/04/22(日) 18:57:13.36 ID:17JCXUuud.net
- https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcQ5P0UhAqENFK1G-_JPBGYzqeq7BU5mtTFqk8xLxSGrmvRXLEm0rvMIkzoWeQ
- 570 ：名無しさん＠編集中 ：2018/04/22(日) 20:19:04.53 ID:NF+KmVz0a.net
- 精神論は他板でやれ
- 571 ：名無しさん＠編集中 ：2018/04/22(日) 20:27:09.28 ID:Itj5Wijm0.net
- (´・ω・`)
- 572 ：名無しさん＠編集中 ：2018/04/22(日) 20:33:15.85 ID:eWH2rYSA0.net
- (´・ω・`)
- 573 ：名無しさん＠編集中 ：2018/04/23(月) 16:17:13.95 ID:BRPMKJ720.net
- 自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
なにこれつべのVP9の4K十分綺麗じゃん
なんでこのVP9ってのはH.264やHx265以上に流行らないの？ 俺が事情を理解できてないだけだが理由がわからない
しかもつべの4K VP9ってビットレートたかだが12Mbps程度でこの画質なんでしょ？
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
- 574 ：名無しさん＠編集中 ：2018/04/23(月) 16:36:36.95 ID:sukaORLRM.net
- ググレカス
- 575 ：名無しさん＠編集中 ：2018/04/23(月) 17:45:49.03 ID:2g6F1r+U0.net
- >>573
x265@フルHDなら1〜3Mbpsでそれなりに見れる画質になるんだから
4ｋで12Mbpsってのは少ないわけじゃない
- 576 ：名無しさん＠編集中 ：2018/04/23(月) 19:12:20.92 ID:hFr3woIv0.net
- h264とVP9を比べるなよ
- 577 ：名無しさん＠編集中 ：2018/04/23(月) 20:07:51.31 ID:fgZBGlO6M.net
- 比べてんのはH265とじゃねえの？
- 578 ：名無しさん＠編集中 ：2018/04/23(月) 20:20:41.65 ID:sDC0ee320.net
- つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
- 579 ：名無しさん＠編集中 ：2018/04/23(月) 21:52:47.76 ID:z48p7vFc0.net
- YouTube推奨ビットレート
https://vook.vc/n/200
- 580 ：名無しさん＠編集中 ：2018/04/23(月) 22:33:19.70 ID:xaUnJI540.net
- >>573
やってみれば分かる。264や265に比べて死ぬ程遅い
特にx265と比較するとビットレート比画質負けるのは勿論デフォ設定同士の比較で1桁以上、下手すれば2桁が見えてくるぐらい遅い
- 581 ：名無しさん＠編集中 ：2018/04/23(月) 23:00:31.33 ID:qgLqyElT0.net
- ,．-─ ─-､─-､
, イ)ィ -─ ──- ､ﾐヽ
ノ ／,．-‐'"´ ｀ヾj ii / Λ
,ｲ／／ ^ヽj(二ﾌ'"´￣｀ヾ､ﾉｲ{
ノ/,／ミ三ﾆｦ´ ﾞ､ﾉi!
{V /ミ三二,ｲ , -─ Yｿ
ﾚ'/三二彡ｲ .:ィこﾗ ;:こﾗ j{
V;;;::. ;ｦヾ!V ｰ '′ i ｰ ' ｿ
Vﾆﾐ( 入 ､ r j ,′
ヾﾐ､｀ゝ ｀ ｰ--‐'ゞﾆ<‐-イ
ヽ ヽ -''ﾆﾆ‐ / ググレカス [ gugurecus ]
| ｀､ ⌒ ,/ （西暦一世紀前半〜没年不明）
| ＞ ---- r‐'´
ヽ＿ |
ヽ ＿ ＿ 」
- 582 ：名無しさん＠編集中 ：2018/04/23(月) 23:29:52.22 ID:2kQ4iN3t0.net
- >>580
なんか>>361のリンク先読むとVP9の方がHEVCより縮むと読み取れるんだけど…、
x265ならVP9より縮むって事なんかね？
＞AOMediaのメンバー企業であるBitmovinの検証によれば、同じ画質で比較したさい、AV1はVP9比で22〜27%、HEVC比で30〜43%ほどビットレートを削減できるという。
- 583 ：名無しさん＠編集中 ：2018/04/24(火) 00:12:35.33 ID:e84XDnmq0.net
- 計算量がね
- 584 ：名無しさん＠編集中 ：2018/04/24(火) 01:36:38.43 ID:4wh5n1kV0.net
- >>579
つべあげるのに4k60pは60Mbpsあったほうがええのか。。
- 585 ：名無しさん＠編集中 ：2018/04/24(火) 02:57:28.71 ID:Cv2UDVgJa.net
- vp系はバッファ少なくても縮むからストリーミングに向いてて良いわ
mpeg系は再生できるようになるまでが長い
- 586 ：名無しさん＠編集中 ：2018/04/24(火) 21:19:53.63 ID:TErN/BXE0.net
- 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の間違いだな。
- 587 ：名無しさん＠編集中 ：2018/04/25(水) 07:58:12.15 ID:Dw16c1DhM.net
- 要はbuildコードが4/12って事でしょ
チェックか何かでゴタついたんでしょ
- 588 ：名無しさん＠編集中 ：2018/04/25(水) 20:34:00.59 ID:vBxpOWXf0.net
- https://code.facebook.com/posts/612340875779169/facebook-video-adds-av1-support/
gop単位で分割してエンコードしてるみたいなこと書いてるな
>>111のYouTubeと一緒か
- 589 ：名無しさん＠編集中 ：2018/04/25(水) 21:10:56.23 ID:+uyVIJ620.net
- 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のお試しサポートをしてみたよって話。
ブラウザ側で正式バージョンの実装がされたら、そっちに切り替えていくとのこと。
- 590 ：名無しさん＠編集中 ：2018/04/26(木) 03:03:05.56 ID:cCy6wkiya.net
- 今canaryに来たってことはstableに来るのは4ヶ月後くらいかな
firefoxもchromeと同時期くらいには実装されるだろうか
一番の問題はスマホの対応だけどね
- 591 ：名無しさん＠編集中 ：2018/04/26(木) 03:53:50.73 ID:jGFgkYoTM.net
- 静止画はまだ出てこないのかな
- 592 ：名無しさん＠編集中 ：2018/04/26(木) 04:37:58.48 ID:gpsPqjL70.net
- >>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
- 593 ：名無しさん＠編集中 ：2018/04/26(木) 04:42:11.54 ID:gpsPqjL70.net
- ただし、性能いいけど最適化されてない今だと画像一枚変換するのに60秒くらい平気でかかる
- 594 ：名無しさん＠編集中 ：2018/04/26(木) 06:03:36.45 ID:jGFgkYoTM.net
- ありがと、これで電子書籍の容量減ってくれると助かるなあ
雑誌DLしたら500Mとか食ってるからはやく普及してほしい
- 595 ：名無しさん＠編集中 ：2018/04/26(木) 07:01:58.96 ID:gpsPqjL70.net
- そういえばハードウェアのエンコードって動画の場合ではソフトウェアよりかなり画質が落ちるけど静止画の場合だとどうなんだろう
- 596 ：名無しさん＠編集中 ：2018/04/26(木) 09:09:52.33 ID:WbUdhyf6M.net
- >>592
ssim0.985辺りで見てみるとjpegに対してのwebmに近い比率でwebmに対してのAVIFは縮むんやね
BPGはエンコードは兎も角デコード重過ぎ&対応ソフト少な過ぎで使い物にならなかったけどwebmの倍までのデコード速度と同程度の普及にはなって欲しいなぁ
- 597 ：名無しさん＠編集中 ：2018/04/26(木) 21:50:44.86 ID:9dHHlQgGM.net
- Appleは最近画像フォーマットにHEVCベースのHEIFを使ってるけど、
AVIF完成したらAVIFに移行するんかな。
もしそうなったらスマホ用サイトの画像フォーマットにAVIF普及しそう。
>>595
動画ほどソフトとハードでの画質の差は出ないと思うよ。
一枚絵の画像だとソフトとハードの差が出やすいフレーム間予測による圧縮がないので。
- 598 ：名無しさん＠編集中 ：2018/04/27(金) 08:29:46.56 ID:1O42is100.net
- ソフトとハードでどのくらい違うか気になったので>>592のグラフにx264とh264_qsvを追加(項目名クリックで表示切り替え可能)
https://plot.ly/~fg1189467/33/
まあ少し落ちるけどこれくらいなら許容範囲かな
- 599 ：名無しさん＠編集中 ：2018/04/27(金) 14:06:31.54 ID:9FN5TERTM.net
- Next-Generation Image Compression (JPEG XL) Final Call for Proposals
https://jpeg.org/items/20180423_cfp_jpeg_xl.html
これAV1じゃないの
- 600 ：名無しさん＠編集中 ：2018/04/27(金) 14:19:08.92 ID:9FN5TERTM.net
- JPEG-XL >60% over JPEG-1
MPEG-H(HEVC) >60% over MPEG-1
WebP2(≒AVIF) >15% over HEIC
- 601 ：名無しさん＠編集中 ：2018/04/27(金) 14:43:01.24 ID:9FN5TERTM.net
- 姉妹規格のJPEG XSは来年完成らしい
ビジュアルロスレスというとDisplayPortのDSCコーデックみたいなやつだな
オープンフォーマットJPEG XS、画像符号化史上初のパラダイムシフト
https://this.kiji.is/361078960999941217/amp
JPEG XS標準化プロセスの開始は、2016年のJPEG 71回目の会合にて承認された。JPEG XSは、超低遅延、電力、帯域幅の要件だけでなく、実装が簡単なアルゴリズム、少ないメモリでも動作し、そして長いケーブルランをサポートすることを目的にしている。
コアコーディングシステムは2018年7月に完成予定で、リファレンスソフトウェアを含んだ全体の完成は、来年2019年4月に予定されている。
- 602 ：名無しさん＠編集中 ：2018/04/27(金) 15:00:41.15 ID:9FN5TERTM.net
- JPEG XSコーデックメモ
https://qiita.com/yohhoy/items/897a543cde9123e6e461
JPEG XSコーデックは、低計算量・低レイテンシが要求されるアプリケーションにおいて、主に「Mezzanine(舞台下の)コーデック」としての利用が期待されている。
ライブ・プロダクション
放送・デジタルシネマ ワークフロー
プロ向け映像市場
KVM1アプリケーション
VRゲーム など
JPEG XSは、従来の(無印)JPEG, JPEG2000, JPEG XR, WebP, HEIFといった大量データ保存・WEB配信向けコーデックを 置き換える技術ではない。
- 603 ：名無しさん＠編集中 ：2018/04/27(金) 17:19:20.66 ID:bi0qElbcM.net
- 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だ。
- 604 ：名無しさん＠編集中 ：2018/04/27(金) 17:47:07.69 ID:gEcmA/z6a.net
- jpegの牙城はH.264より堅いだろうから新画像コーデックを広めるのは厳しいだろうな…
MSとAppleとGoogleが足並み揃えてゴリ押ししたらいけるかも？って感じ
- 605 ：名無しさん＠編集中 ：2018/04/27(金) 19:05:47.95 ID:EWvTPi2GM.net
- ありゃJPEG XLの技術公募締切が9月に延期されてる
公開目標時期は2019年10月か
AV1採用してくれ
- 606 ：名無しさん＠編集中 ：2018/04/27(金) 19:18:04.15 ID:diV9ARYpM.net
- >>604
そのメンバー全員Alliance for Open Mediaに加盟してるし、MozillaやFacebookやNetflixもいる。
Appleしか推してないHEIFやGoogleしか推してないWebP、Microsoftしか推してないJPEG-XR
とはかなり状況違うから今度は期待できそう。
- 607 ：名無しさん＠編集中 ：2018/04/27(金) 23:11:06.12 ID:+UMyqfuU0.net
- VP9は画質で判断するとたまにH264よりサイズでかくなるから困る。圧縮するなら相応の力を見せてくれないと
中途半端だ
- 608 ：名無しさん＠編集中 ：2018/04/28(土) 04:17:32.25 ID:vQv5IYZY0.net
- >>603
HDMIがロッシーになるのか
マウスカーソルの周りにブロックノイズとか出たら嫌だな
- 609 ：名無しさん＠編集中 ：2018/04/28(土) 04:45:52.04 ID:iRXtwpm2a.net
- 8Kくらいまで解像度を上げない限りは非可逆にはならないと思うぞ
- 610 ：名無しさん＠編集中 ：2018/04/28(土) 10:49:22.34 ID:rp64VJ9F0.net
- >>608
そこまで圧縮しないから大丈夫だと思う
問題は低延滞だが延滞は有るというあたりと、表示機器側でデコーダ積まなきゃならないから、対応すると素で単価が上がる
- 611 ：名無しさん＠編集中 ：2018/04/28(土) 10:51:51.61 ID:rp64VJ9F0.net
- >>606
基本的にアプリケーションの内部処理やサービスとセットで消費者側はデコード主体使う事になるだろうから、個人で生成する事は余り考えなくて良いと思う
- 612 ：名無しさん＠編集中 ：2018/04/28(土) 22:36:34.23 ID:tYs2/UtdM.net
- たしかtwitterはgifをアップロードするとmp4(h.264)に変換される仕様だったような
google photoもwebpに変換されてるんだっけ？
全モダンブラウザが対応するweb標準の次世代画像規格さえできたら
あらゆるサイトでjpeg/png/gifが変換されるようになるはず
運営側もユーザー側もトラフィック削減パケット節約でwin-win
- 613 ：名無しさん＠編集中 ：2018/04/29(日) 13:51:15.35 ID:o99M7JsiMNIKU.net
- AV1が一般人にストレスなく利用できるようになるのは、いつ頃だろうか？
音声の圧縮音声コーデックは、今後MPEG4-ALS（品質重視の用途）かOpus（可聴帯域のみを扱う一般的な用途とリアルタイム通話向き）に収束していくのだろうけど
ところで、音声コーデックの話をするスレ、どこかあるのかな？
- 614 ：名無しさん＠編集中 ：2018/04/29(日) 13:57:23.74 ID:hhx87O280NIKU.net
- ストレスなく利用っていうのが視聴の事なら1、2年で可能だろうけどエンコードの事なら一生来なさそう
- 615 ：名無しさん＠編集中 ：2018/04/29(日) 16:31:01.59 ID:o99M7JsiMNIKU.net
- >>614
アカンがな、それ…
となると、やはり映像はHEVCベースで運用しておくか
音声はフリーのくせにと言ったらおこられそうだが、日常使いではOpusでいいかなと最近は思っている
新しくYouTubeにアップされてる高解像度のものは、元からOpusでエンコードされているから聴き取りやすくていいし
音声メインの素材をアップする人は、積極的に高解像度（フレームレートは1fpsとかにできるのならば、それでいい）でアップしてもらいたい
- 616 ：名無しさん＠編集中 ：2018/04/29(日) 16:44:59.29 ID:rFAS4HxrMNIKU.net
- >>612
AVIFはアルファチャンネルやアニメーションにも対応するそうだし、
AVIFに使用されてるAV1は可逆圧縮にも対応してるから、
うまく行けばjpg/png/gif全部置き換えられそう。
- 617 ：名無しさん＠編集中 ：2018/04/29(日) 18:01:51.92 ID:E3c9gHljMNIKU.net
- >>613
ここかな
【Opus/Vorbis/FLAC】Ogg統合20【AV1/Theora】
http://egg.5ch.net/test/read.cgi/software/1517027557/
- 618 ：名無しさん＠編集中 ：2018/04/29(日) 19:45:07.16 ID:o99M7JsiMNIKU.net
- >>617
ソフトウェア板にあったのか
DTM板かと思ってたよ
Thx.
- 619 ：名無しさん＠編集中 ：2018/04/29(日) 21:14:36.62 ID:TSyBLkXS0NIKU.net
- >>615
Opus気になって調べてみた
で、YouTubeに4K動画でMISIAの音源にいいのがあったので試してみた
確かにいい
ただし、手元のPCで再生するよりスマホのXperiaで再生したほうが高音質だった（泣
PCの音声環境見直すか・・・
- 620 ：名無しさん＠編集中 ：2018/04/29(日) 21:32:14.56 ID:mEIjwYB6aNIKU.net
- >>619
それわかるw
Opusをもっと試したかったらサカナクションの「多分、風」という曲もOpusの入ってるファイルで聴くといいと思う
- 621 ：名無しさん＠編集中 ：2018/04/29(日) 22:04:22.84 ID:1hLNpWuo0NIKU.net
- >>616
可逆圧縮をなめてはいけない。
可逆画像圧縮のアルゴリズムをを不可逆画像圧縮から流用するアプローチが
いくつかあるけど、普通にPNGより性能悪い。
WebPは可逆不可逆両対応だけど、それぞれ別のアルゴリズムを使ってる。
可逆か不可逆かぱっと見で区別できないのも困るし、今までどおり別の型式のがいいと思う。
可逆画像圧縮はzstdのアルゴリズムベースのが出てきてくれたら嬉しいけどなぁ。
- 622 ：名無しさん＠編集中 ：2018/04/29(日) 23:37:02.55 ID:RFC43lfy0NIKU.net
- お前ら可逆不可逆って続けて何回言える？
俺は1回すら怪しいんだけど
- 623 ：名無しさん＠編集中 ：2018/04/29(日) 23:39:32.57 ID:xjjdisQZ0NIKU.net
- 最初の3文字までは読めた
- 624 ：名無しさん＠編集中 ：2018/04/30(月) 00:03:24.95 ID:8vT42dcVM.net
- >>619
YouTube動画の音声サンプリング周波数は
AACが41.1kHzでOpusは48kHzだったような
だから例えばiPhoneシリーズなら6s以降スピーカーが48kHzしか対応していないらしいからAACだと多少音質変化するかも
逆に44.1kHzのみ対応のイヤホンとかもあったり
なんか深淵を覗いた心地に
- 625 ：名無しさん＠編集中 ：2018/04/30(月) 00:09:31.52 ID:8vT42dcVM.net
- >>621
そういやFLIFとかいうFLACの親戚みたいな名前の可逆圧縮画像規格あったけど最近は音沙汰無しだな
いつかリリースされる日は来るのだろうか
- 626 ：名無しさん＠編集中 ：2018/04/30(月) 00:34:28.89 ID:8vT42dcVM.net
- 最近は写真や動画を撮ったらすぐにクラウドストレージに投げることが増えてきたから
元ファイルを(ビジュアル)ロスレス圧縮してアップロードした後、クラウド上で再エンコードする時代になったりしないかな
ロスレスHEVCかロスレスAV1かVESAのDSCかどれでもいいけど
- 627 ：名無しさん＠編集中 ：2018/04/30(月) 00:51:03.48 ID:8vT42dcVM.net
- FLACをアップロードできてOpusがストリーミング配信されているSoundCloudはすごいな
無料だし
- 628 ：名無しさん＠編集中 ：2018/04/30(月) 01:56:05.01 ID:g5bwX14t0.net
- >>627
SoundCloud、これいいね！
スマホにアプリ入れてGoogleのアカウントでサインインしてみたけど、操作が少し独特だけどいいよこれ
日本人の曲もあるし、音も素材が良ければいい感じだね
これはいいの教えてもらったよ
ありがとう！
- 629 ：名無しさん＠編集中 ：2018/04/30(月) 15:02:47.73 ID:K2+Kaxf4M.net
- PNGのほうがwebp可逆より縮む？
- 630 ：名無しさん＠編集中 ：2018/04/30(月) 23:11:45.40 ID:1+hf/BtW0.net
- >>629
WebP可逆は不可逆とは別のアルゴリズムだから殆どの画像でPNGより縮む
BPGの可逆圧縮を調べてみたけどやっぱり微妙だった
PNGが苦手な画像だとPNGより縮んだり縮まなかったり
PNGが得意な画像だとPNGに引き離される
AV1の可逆圧縮も似たようなもんになる気がする。
- 631 ：名無しさん＠編集中 ：2018/05/01(火) 02:14:16.26 ID:HX1oXWc70.net
- PNGは最適化を掛けるとかなり縮むけど、
マルチスレッドすら対応してない古いプログラムばかりで遅いのがな
その辺をちゃんと最適化してくれればPNGで十分そうな気がする
- 632 ：名無しさん＠編集中 ：2018/05/01(火) 02:25:48.52 ID:vXYkO7J+0.net
- とりあえずWindows 10の最新アップデートを適用すると、HEIFの表示のみOS標準で対応だとさ
※保存はダメ
- 633 ：名無しさん＠編集中 ：2018/05/01(火) 05:30:37.42 ID:os57il8aa.net
- 結局OSの対応よりブラウザの対応のほうが大切なんだよね
- 634 ：名無しさん＠編集中 ：2018/05/01(火) 05:31:42.05 ID:8wdpRSsu0.net
- >>630
BPGの可逆圧縮はエンコーダーにx265を使うと縮まないけどjctvcなら結構縮む
jctvcは0.9.6以降は搭載されてないから試すなら0.9.5を使ってね
- 635 ：名無しさん＠編集中 ：2018/05/01(火) 12:32:13.70 ID:8wdpRSsu0.net
- 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"
- 636 ：名無しさん＠編集中 ：2018/05/01(火) 13:29:55.47 ID:56CftVddM.net
- >>635
AV1可逆の圧縮性能はPNGに比べてどうだった？
- 637 ：630 ：2018/05/01(火) 23:33:58.50 ID:47AIvuLn0.net
- >>634
jctvcを使ったら可逆ですげー縮んだ。勉強不足すぎてた。
これだと大方の画像ではPNGより小さくなりそう。
ただ、PNGが得意な画像で、差は縮まれど追いつけないままな物もまだあるから
PNGを全部置き換えるにはまだ不足してるって感想はそのままかな。
（一番手ごろなものだと、wikipediaのページのスクショ画像がそうなった）
- 638 ：名無しさん＠編集中 ：2018/05/02(水) 05:56:13.66 ID:D0yOygKta.net
- deflateという圧縮技術のデファクトスタンダードを使っているpngが置き換わることはそうそう無いと思うけどね
- 639 ：名無しさん＠編集中 ：2018/05/02(水) 06:31:48.11 ID: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も上げておくので設定とか検証が適切に行われたかが気になる人は見て
https://www.dropbox.com/s/kc7njid1gz12vs0/lossless_bench.zip?dl=0
- 640 ：名無しさん＠編集中 ：2018/05/02(水) 07:05:18.55 ID:Ssad5kFU0.net
- webp優秀やな
- 641 ：名無しさん＠編集中 ：2018/05/02(水) 08:22:59.93 ID:/Hb8IfCSM.net
- >>639
ありがとー
AV1縮んでないね、可逆だとwebpに劣るなんて
得意な？非可逆だとどうなるんだろ
- 642 ：名無しさん＠編集中 ：2018/05/02(水) 17:47:43.70 ID: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
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/
- 643 ：名無しさん＠編集中 ：2018/05/02(水) 18:20:31.86 ID:/KuL0s/FM.net
- 40％！
素晴らしい！素晴らしいですよ！
- 644 ：名無しさん＠編集中 ：2018/05/02(水) 20:01:38.55 ID:q+VeS0Up0.net
- >>639
AV1本当何やってもトロくて駄目なやつだな…
ここまで糞だと改善の見込みも無さそう
AV1を今より遥かに速く改善できるなら他のコーデックなら更に改善できるだろ
- 645 ：名無しさん＠編集中 ：2018/05/02(水) 20:06:23.69 ID:j0vNwcLd0.net
- それが出来ないからVVC等の新しいコーデックが開発されてるんだろ
- 646 ：名無しさん＠編集中 ：2018/05/02(水) 20:18:05.23 ID:EaTyxjPAM.net
- 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として公開したという。不可逆圧縮などが強化されツールもアップデートされている。
- 647 ：名無しさん＠編集中 ：2018/05/02(水) 20:18:41.81 ID:EaTyxjPAM.net
- >>646
WebP
https://developers.google.com/speed/webp/
libwebp
https://github.com/webmproject/libwebp
- 648 ：名無しさん＠編集中 ：2018/05/02(水) 21:34:36.25 ID:Ssad5kFU0.net
- webpはデコード早いから良い
- 649 ：名無しさん＠編集中 ：2018/05/02(水) 21:37:53.46 ID:8dHE9Ib0M.net
- これでwebpがもっと普及するといいなあ
- 650 ：名無しさん＠編集中 ：2018/05/02(水) 22:00:46.77 ID:TPiWhDTo0.net
- なおFirefox
- 651 ：名無しさん＠編集中 ：2018/05/02(水) 23:40:55.87 ID:/Hb8IfCSM.net
- >>650
ブラウザ識別して火狐には重いデータを送ってやろう
- 652 ：名無しさん＠編集中 ：2018/05/03(木) 00:20:58.06 ID:ag9sCIyxM.net
- ChromeがAPNG対応したんだから
FirefoxはWebP対応するのが🍣
- 653 ：名無しさん＠編集中 ：2018/05/03(木) 02:42:42.99 ID:qLoEKbqla.net
- firefoxはwebp対応してるだろ
safariと勘違いしてるのか？
- 654 ：名無しさん＠編集中 ：2018/05/03(木) 10:10:30.36 ID:uRMPloV+M.net
- >>653
https://caniuse.com/#search=webp
😿
- 655 ：名無しさん＠編集中 ：2018/05/04(金) 06:39:59.54 ID:lkzBO84x0.net
- 4K放送は265HEVC？
- 656 ：名無しさん＠編集中 ：2018/05/07(月) 10:46:58.51 ID:lWAiBYbLM.net
- >>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受信料とかに（無駄に）上乗せされないといいんだがなぁ
かと言って機動力のない放送団体が状況に応じてコーデック入れ替えなんかできるとも思えないし
- 657 ：名無しさん＠編集中 ：2018/05/07(月) 12:20:32.32 ID:QSFqJxGb0.net
- 何を今更…
- 658 ：名無しさん＠編集中 ：2018/05/07(月) 12:25:34.52 ID:mN4HSZiPM.net
- >>656
対応profileのオプションにもよるけど、TV1台当たりライセンス料300円しないぞ
- 659 ：名無しさん＠編集中 ：2018/05/07(月) 13:26:33.16 ID:mN4HSZiPM.net
- 今年の2月に特許切れたMPEG2にもライセンス料掛かってたしな
録画の圧縮機能やMPEG4/AVCの再生機能持ってる機器なら、未だにMPEG4/AVCのライセンス料も掛かってるし
今まで金銭的にそれらの上乗せを負担と意識して無かった奴が、今更HEVCのライセンス料で騒いでるのも可笑しいんだけどね
実効でその程度のものだったり
- 660 ：名無しさん＠編集中 ：2018/05/07(月) 13:38:03.21 ID:mN4HSZiPM.net
- 映像コンテンツなら殆ど2円未満、高くても3円にもならないとかだし、
パッケージの流通コストや小売り・事業者の粗利の方が遙かに影響デカくて、個人単位で年間ナンボよって感じなのよね
そんな額気にするなら、家電品の消費電力気にしていた方がマシだったりな
自販機で飲料買ったり、コンビニで買い物する方が遙かに無駄という
- 661 ：名無しさん＠編集中 ：2018/05/07(月) 16:43:37.96 ID:2gi9rWInM.net
- 「GIMP 2.10」リリース
https://mag.osdn.jp/18/05/01/160000
WebPサポート
- 662 ：名無しさん＠編集中 ：2018/05/07(月) 18:11:36.96 ID:jxsmP9bbM.net
- 寧ろ今まで対応してなかったのか
- 663 ：名無しさん＠編集中 ：2018/05/07(月) 18:16:47.63 ID:CavlMB6C0.net
- GIMPは亀の歩みだし……
対応してくれただけでも喜ぶべき
- 664 ：名無しさん＠編集中 ：2018/05/07(月) 20:38:05.43 ID:ZtP2jiNr0.net
- 昔はPhotoshopの代わりにGIMPでも頑張れば行けるかもって時期があったけど、
今は完全に突き放されて背中すら見えなくなってしまったなあ
- 665 ：名無しさん＠編集中 ：2018/05/07(月) 21:56:46.76 ID:CavlMB6C0.net
- 今のフォトショってそんなにすごいんか（時代遅れ）
- 666 ：名無しさん＠編集中 ：2018/05/08(火) 00:22:38.74 ID:ZanT8rbB0.net
- GIMPはリリース間隔が空きすぎて開発者のほとんどがKritaとかDarktableに行っちゃったから…
- 667 ：名無しさん＠編集中 ：2018/05/08(火) 00:35:32.05 ID:7ccNxeIra.net
- GIMPの前回のリリースって5年以上前だろう
webpその頃あったのかな
- 668 ：名無しさん＠編集中 ：2018/05/08(火) 16:29:53.58 ID:vgWy5NipM.net
- Kritaは3年前からWebPサポートしてたのか
https://krita.org/jp/item/krita-2-9-5-released-jp/
- 669 ：名無しさん＠編集中 ：2018/05/10(木) 21:28:35.09 ID:YxvK1ObZH.net
- androidのゲームでwebp義務化すればかなり通信料減らせそう
- 670 ：名無しさん＠編集中 ：2018/05/11(金) 07:42:07.81 ID:HL2toN7BM.net
- 結局webpが流行ることは無かったな
コーデックもVP8のままだし
- 671 ：名無しさん＠編集中 ：2018/05/11(金) 10:06:37.10 ID:G39yR8Av0.net
- よくわからんけどAndroidのゲームはETC1かETC2が主流じゃないの？
多分DXT同様固定の容量圧縮比の方がメモリ消費量の把握しやすいだろうし
- 672 ：名無しさん＠編集中 ：2018/05/11(金) 22:50:53.49 ID:XObC1OA70.net
- >>670
JPEGから移行するにはショボすぎた
HEIFでやっとって感じ
- 673 ：名無しさん＠編集中 ：2018/05/12(土) 01:19:03.53 ID:k0/RMl7s0.net
- 流石にJPEGも古い規格よなぁ
圧縮率の高い次世代フォーマットでどれだけのストレージやリソースが削減できるか
実際は皆足並みが揃わない訳だけども
ストレージの進化が完全に頭打ち！大変だ！みたいなピンチにでもならなきゃ業界は腰を上げないよな
- 674 ：名無しさん＠編集中 ：2018/05/12(土) 01:46:18.60 ID:+wN2NfcxM.net
- ストレージは大した問題ではないだろう
問題なのは通信量よ
- 675 ：名無しさん＠編集中 ：2018/05/12(土) 01:50:00.39 ID:W5jsDxqa0.net
- その他にも処理速度とかそれをハードウェア処理するチップのコストだとかいろいろあるんだろうけど
ぶっちゃけいえばブラウザやOSが標準でサポートするか否かが一番でかいと思う
ってJPEG2000さんが草葉の陰でいってた
- 676 ：名無しさん＠編集中 ：2018/05/12(土) 03:02:41.15 ID:/JzDRiyH0.net
- 近いうちにJPEG2000が主流になるからデジカメの買い替えをちょっと待とう…
とか思っていた遠い日の記憶が蘇ったw
- 677 ：名無しさん＠編集中 ：2018/05/12(土) 03:56:43.62 ID:ltRK6gJw0.net
- もうJPEGくらいに浸透してると
AppleみたいにHEIFをデフォルトで初心者に気づかせないうちに使わせて
広めるみたいなことしないと無理だろう
- 678 ：名無しさん＠編集中 ：2018/05/12(土) 16:23:09.23 ID:DaJWusoLM.net
- amazonとかの電子書籍を全てwebpにすれば普及する
- 679 ：名無しさん＠編集中 ：2018/05/12(土) 17:10:26.58 ID:FWhsUTQe0.net
- AV1ってまだ正式に仕様決まってないの？
doom9見てたらそういう感じの話してるような気がするけど機械翻訳で読んでるからよく分からない
https://forum.doom9.org/showthread.php?t=172550&page=34
- 680 ：名無しさん＠編集中 ：2018/05/12(土) 18:47:05.20 ID:ERkX91bQ0.net
- >>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の仕様が確定する。
- 681 ：名無しさん＠編集中 ：2018/05/12(土) 18:50:45.44 ID:ERkX91bQ0.net
- >>680のリンクはこうすべきだったかな。
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=124455&fb_comment_id=2018670391537585_2021817181222906
- 682 ：名無しさん＠編集中 ：2018/05/12(土) 18:54:47.06 ID:ltRK6gJw0.net
- >>678
それだけじゃ絶対普及しない
リーダーはAmazonとかの電子書籍配布元が配布するとして
画像生成する機器やアプリケーションが標準でほぼ全対応しなきゃ
出版する側の人間がwebpへの変換ツールを使うだけに終わる
カメラなどのハードウェアが直接次世代フォーマットで
画像生成するようになって初めて普及する可能性が出てくる
その点、デフォルトでiPhoneでHEIFを吐き出させ始めたAppleが
一歩リードしてる
- 683 ：名無しさん＠編集中 ：2018/05/12(土) 19:36:39.91 ID:FWhsUTQe0.net
- >>680
サンクス
どうりでChromeがなかなか対応しないわけだ
- 684 ：名無しさん＠編集中 ：2018/05/13(日) 05:46:57.59 ID:QMoN91bYa.net
- chromeもfirefoxもAV1の一時的なな実装は完了しているから仕様確定したらすぐにでも導入できるはず
まあ安定版に降りてくるには半年近くかかるのだろうけど
- 685 ：名無しさん＠編集中 ：2018/05/13(日) 12:00:27.25 ID:WgGYbyGwM.net
- Kindleの中のデータってjpegなの？
- 686 ：名無しさん＠編集中 ：2018/05/13(日) 12:05:53.14 ID:aA9jcx6MM.net
- つべのVP9と264
容量が逆転してるのが多いな…
細かい動きが多いとダメなんかな？
- 687 ：名無しさん＠編集中 ：2018/05/13(日) 22:06:31.89 ID:7jvfurv50.net
- VP9はHEVCとAVCの中間あたりに位置すると個人的には考えてるから、得手不得手で旨味なくなりがちだよね
- 688 ：名無しさん＠編集中 ：2018/05/13(日) 22:53:00.53 ID:d407Oae50.net
- HEVCの技術とAV1の技術を全て結集したらさいきょうのコーデックが出来上がりそう（厨二的発想）
まぁ大人の事情でまず有り得ないけど
- 689 ：名無しさん＠編集中 ：2018/05/14(月) 02:57:59.84 ID:n2LNOfSM0.net
- >>688
大人の事情とか言ってる時点で…
ただエンコーダ・デコーダが優秀になればいいだけの話。特性云々はここで語る必要ないと思うが
- 690 ：名無しさん＠編集中 ：2018/05/14(月) 06:09:48.86 ID:OgrikrUWa.net
- VP系はMPEG系と比べて先読み短くても圧縮率保てるからストリーミングにはVP9のほうがいいよ
- 691 ：名無しさん＠編集中 ：2018/05/14(月) 10:19:40.88 ID:B2eqMGvp0.net
- なら自炊用途では利点薄いな
- 692 ：名無しさん＠編集中 ：2018/05/14(月) 11:01:26.25 ID:3yN5QwlIM.net
- 自炊用途は、長期的に安定して再生できる可能性の高いフォーマットを選ばないとあとで後悔するだけ
ただ、一つ気がかりなことがあるとすれば、動画ファイルに使える音声フォーマットの進展が遅れ気味なことか
特にOpusのようなVBRタイプのフォーマットを動画とMUXしたいとかなると、とたんに使えるツールが見当たらなくなる現状は如何ともし難い
動画と音声を自由自在にMUXできる自由度の高いツールがほしい
- 693 ：名無しさん＠編集中 ：2018/05/14(月) 13:30:49.72 ID:wniTZ/UkM.net
- ffmpegでできないんか？
- 694 ：名無しさん＠編集中 ：2018/05/14(月) 15:57:08.62 ID:B2eqMGvp0.net
- mkvコンテナ扱える奴なら仮対応的な実装じゃ無ければイケるんじゃないの？
- 695 ：名無しさん＠編集中 ：2018/05/14(月) 17:52:19.59 ID:hi9NhhfiM.net
- 電子書籍とかの複数ファイル画像って
動画にしてフレーム間圧縮で容量減らせそうだけど
やってるとこないのかな
- 696 ：名無しさん＠編集中 ：2018/05/14(月) 18:53:07.42 ID:dB9siKnnM.net
- >>695
フレーム間の違い大きすぎて圧縮のための予測がうまく出来なさそう
- 697 ：名無しさん＠編集中 ：2018/05/14(月) 21:05:59.77 ID:u8Q90uS+H.net
- >>696
文字とかで余白の多いすかすかの雑誌系は
ページ間で連続した空白多いから容量減りそうだけどどうだろ
- 698 ：名無しさん＠編集中 ：2018/05/15(火) 10:48:03.02 ID:L0wI7lRZM.net
- そもそも空白が多い画像はjpgなりpngなりでも大きくないと思う。
1フレームごとに文字が離散しているので毎フレームIフレームにするのと画質対容量のメリットがあまりない。
kindleなどの端末で処理するにはフレーム間予測などの処理はハードウェアデコーダ積んだりキャッシュしていくにしろ重いだろうし流行らないと思う。
そういうので1番効果があるのはエロゲとかdlsiteにあるような差分データ盛り盛りのCG集などに限定されると思う。
- 699 ：名無しさん＠編集中 ：2018/05/15(火) 12:00:09.11 ID:v78X55j30.net
- そこは昔のゲームみたいに口や目の変化部分だけ画像作って
差し替える方式でいい気がする。マップチップ的な
まぁ今のもの見ると画像1枚1枚用意しているのが多いから容量増え気味だよね
- 700 ：名無しさん＠編集中 ：2018/05/15(火) 12:44:29.90 ID:YP40ckAd0.net
- スクリプトミスったら差分の目が背景の上に浮くじゃないですかー
- 701 ：名無しさん＠編集中 ：2018/05/15(火) 12:47:15.36 ID:gru2+YPn0.net
- VimeoがAOMediaのPromotor memberに。
Vimeo Joins the Alliance for Open Media
https://press.vimeo.com/31386-vimeo-joins-the-alliance-for-open-media
- 702 ：名無しさん＠編集中 ：2018/05/15(火) 17:37:21.94 ID:l32k4eJ70.net
- エロゲって画像形式何使ってるんだろ、やっぱり可逆PNGなのかな
- 703 ：名無しさん＠編集中 ：2018/05/15(火) 23:35:21.34 ID:sO7921jZ0.net
- 吉里吉里ならエロゲ絵に特化したTLG型式ってのが使えるけど
実際に使われてるのかは知らない。
- 704 ：名無しさん＠編集中 ：2018/05/16(水) 13:04:48.09 ID:ixE7+1Ga0.net
- >>695
OCRしてテキスト化の圧縮率に到底勝てないからやる意味が無い
- 705 ：名無しさん＠編集中 ：2018/05/16(水) 16:20:14.44 ID:RUCiJ5XHx.net
- >>695
面白いアイディアだな、言い出しっぺの法則で作ってみてくれ
ただ全ページがキーフレームになってしまうとかあり得るんじゃね
- 706 ：名無しさん＠編集中 ：2018/05/16(水) 19:26:14.68 ID:zSaLZ/zv0.net
- 電子書籍は突飛なアイデアではなくて自分も数年前に検討済み
電子書籍には3タイプあって、698の言う通りで、連続差分画像以外に
ましてやテキストオンリーの書籍に動画コーデックの出る幕は無い
・画像のみ：コミック、写真集
・テキスト+画像レイアウト：雑誌やムック、写真集、美術書など
・テキスト：小説など
テキスト+画像レイアウトの場合、活躍するのは静止画フォーマットだけ。
残された画像のみの場合だが、すでにHEIFはイメージシーケンスが規格に組み込まれてるから
新たにやることは各電子書籍ベンダーがそれを利用するかどうかくらい。
- 707 ：名無しさん＠編集中 ：2018/05/16(水) 19:34:53.31 ID:TRVkhnIz0.net
- 漫画なら図形の輪郭とかとかスクリーントーンとかそういうのを符号化すれば…
って思ったけどpostscriptだな
- 708 ：名無しさん＠編集中 ：2018/05/17(木) 18:58:01.00 ID:aOY/Sh7+0.net
- もう、基本の圧縮技術は画像にしろ動画にしろ、JPEGの時代に確立されちゃってるのか・・？？
それからあんま本質は変わってないのかね
- 709 ：名無しさん＠編集中 ：2018/05/17(木) 20:45:26.23 ID:dtRc1mgp0.net
- 500年後の未来から来たけど、今の圧縮技術はその概念自体が使われなくなるよ
究極のイメージ処理は、全データをベクター処理すること
ラスターイメージ処理は電子機器の能力が低い現代における
低レベルなお粗末な石器時代並みの技術だよ
量子コンピューターにより画像自動解析処理が高度に発達した未来では
2Dの平面データで記録再生するのは骨董品技術になる
わかりやすく現在の製品名で例えれば
Illustrator>>>超えられない距離>>>Photoshop
未来のカメラは撮像したデータを自動解析して、
3Dオブジェクト+テクスチャ判定+光源計算したデータとして保管
テクスチャも撮像データから得た2Dラスターデータではなく
全世界で共用管理している超大規模データセンターの膨大なデータから
何番目のテクスチャ、というID指定を記録するだけなので、データ量は軽い
再生時に3Dグラフィックでリアルタイムレンダリング処理を行う
圧縮という概念自体がなくなる
ただし、メロンパンは500年後の未来でもなくなっていません。あれは美味しいデス
- 710 ：名無しさん＠編集中 ：2018/05/17(木) 22:15:23.81 ID:Yn+eJUWU0.net
- 電子書籍に関してはePubの規格がバージョンアップしてリフローとフィクスのハイブリッド型も作れるようになってるね
現状では雑誌の電子書籍版のインタビュー記事とかがテキストも含めて全部画像だったりするけど
今後は必要に応じてテキスト部分はテキストデータのページに置き換えるような措置をした方がファイルサイズを抑えるのとコンテンツの読みやすさを両立できて良いと思う
- 711 ：名無しさん＠編集中 ：2018/05/17(木) 23:18:42.89 ID:nu+LsDAr0.net
- >>708
JPEG 2000ではウェーブレット変換が使われていたけど、結局それ以降は使われていないよね
コサイン変換に比べて、あまり筋のいい技術ではなかったということなのかなぁ
- 712 ：名無しさん＠編集中 ：2018/05/17(木) 23:25:51.55 ID:qghkMzkD0.net
- 某ネコさん曰く、16k以上の画素数だとwaveletが日の目を見るかもしれないらしい
- 713 ：名無しさん＠編集中 ：2018/05/18(金) 09:59:24.63 ID:ZPtxF8MK0.net
- JPEG XSもwaveletだそうだけど、どんな感じの圧縮なんだろう。
- 714 ：名無しさん＠編集中 ：2018/05/18(金) 10:37:15.45 ID:/renKBLaa.net
- >>713
おねえさんのお尻でぎゅーって押し潰される感じ♥
- 715 ：名無しさん＠編集中 ：2018/05/18(金) 12:55:58.26 ID:+GbTMFNU0.net
- >>711
ビデオ規格だと、SnowやDiracもウェーブレット変換
- 716 ：名無しさん＠編集中 ：2018/05/18(金) 12:59:08.56 ID:+GbTMFNU0.net
- DCTと違ってブロックノイズが発生しないのがDWTの利点だけど、
ブロック単位でする動き補償と相性が悪いので動画には不向き
- 717 ：名無しさん＠編集中 ：2018/05/18(金) 21:33:10.21 ID:K0HNwhcn0.net
- waveletで圧縮しまくったらどうなるんだろ
ぼやけるだけ？
- 718 ：名無しさん＠編集中 ：2018/05/19(土) 03:30:25.97 ID:KyqEPYZE0.net
- 特性的にエッジ部分の情報量から削られていくから、そういう部分の階調表現の幅が狭まる（コントラスト低下）と解像度感が失われて眠い画になっていくと思う（俗に言う眠い絵作り
特性がある圧縮だから万能じゃ無いかと
あくまでwaveletを手段として使っていているだけで、これ自体が圧縮方式では無い事にも注意（使い方や実装で性能が変わる
画像データの周波数的な情報の分離に向いていて、分離したデータの内で画像の全体像を把握するには重要じゃ無い部分を削る事で「圧縮にも使えなくは無い」ってだけで、内容的にはMP3的な（実装によって差が出やすい）プライオリティの低い情報を削る感じ
文字や図表、線画のエッジ部分が多い画像の圧縮には向かないと思う
- 719 ：名無しさん＠編集中 ：2018/05/19(土) 11:48:56.33 ID:g5W8fTyCa.net
- 画像データの周波数的情報って何？
- 720 ：名無しさん＠編集中 ：2018/05/19(土) 12:49:01.68 ID:RKBOVkud0.net
- 「画像 周波数」でググればよいかと。
- 721 ：名無しさん＠編集中 ：2018/05/21(月) 01:31:50.61 ID:1YvuKtaD0.net
- >>619
MISIAの4Kというと、「名前のない空を見上げて」のことかと思うけど、これ確かにスマホで聴いたほうが音いいからおかしいなと思って調べた
すると、確かに4Kでアップされてはいるのだけれど、1080pと1440pをmp4ファイルとWebMファイルで比較すると、mp4ファイルのほうがファイルサイズが大きくなっていた
通常、画質と音質がともにいい場合は、4Kより下の解像度でもファイルサイズは
WebM＞mp4もしくはWebM≒mp4
のいずれかであるのだが、この曲は逆転していた
だからダウンロードするのであれば、この曲に関してはmp4ファイルのほうがいい
ただし、ここからがよくわからないのだが、PCにてChrome上で再生した場合、再生中に詳細情報を確認するとWebMにも関わらず音は悪くない
ここがわからないんだよなぁ
YouTubeは謎が多い
- 722 ：名無しさん＠編集中 ：2018/05/21(月) 09:49:00.46 ID:ox2mzMHN0.net
- 今の動画サイトは、映像と音声は別々に保存してて、
視聴者がページ開いたときにくっつけて配信してるんじゃなかったっけ。
- 723 ：名無しさん＠編集中 ：2018/05/21(月) 12:37:02.14 ID:ohVff/0r0.net
- よくわからないのに書くからこういうことになるんだね
- 724 ：名無しさん＠編集中 ：2018/05/21(月) 13:32:07.83 ID:1YvuKtaD0.net
- ならば君が書けばいい
- 725 ：名無しさん＠編集中 ：2018/05/21(月) 15:12:56.00 ID:ohVff/0r0.net
- なぜ私がｗ
- 726 ：名無しさん＠編集中 ：2018/05/21(月) 15:19:31.47 ID:llvcQqWjd.net
- >>722
YouTubeはそうだったはすだよ
- 727 ：名無しさん＠編集中 ：2018/05/21(月) 15:19:45.16 ID:llvcQqWjd.net
- >>726
恥ず
- 728 ：名無しさん＠編集中 ：2018/05/21(月) 17:54:03.14 ID:pXVYVIdD0.net
- マジレスすると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)より小さくて、稀に逆のものもあるという程度だと思うけど。
変なダウンローダを使ってるか勘違いしてしまってるんじゃないかと思う。
- 729 ：名無しさん＠編集中 ：2018/05/21(月) 18:11:21.85 ID:pXVYVIdD0.net
- ついでに言うとYoutubeの場合、VP9は比較的ファイルサイズが小さくなってるとはいえ、
たまにブロックノイズやリンギングノイズ（モスキートノイズ？）で
映像崩壊レベルになってるフレームがあったりする。
普通に視聴する分には気にならないけど、比較するとAVCの方が安定した画質になってるような。
まあ1440pHFR以上は基本的にVP9だけしか無いけど。
- 730 ：名無しさん＠編集中 ：2018/05/21(月) 19:06:54.29 ID:41ToqTwjM.net
- 理解不足にもほどがある
- 731 ：名無しさん＠編集中 ：2018/05/21(月) 19:41:25.11 ID:vORAC5lE0.net
- おっぱす音いいよね
- 732 ：名無しさん＠編集中 ：2018/05/22(火) 01:36:52.77 ID:q/SFdsGY0.net
- EdgeはGPUにVP9デコーダが搭載されてればVP9、
無ければH.264で再生されるから賢いというか優しいというか
ChromeはGPUデコーダ無くてもVP9にするからCPUデコードになって重い
VP9デコーダ無いような古いPCでCPUデコードとか鬼だ
メモリも喰いまくるしオンボロPCで動かすんじゃねえってGoogleの方針なんだろう
- 733 ：名無しさん＠編集中 ：2018/05/22(火) 04:11:37.33 ID:VZpL9/6Ha.net
- 回線には優しいとも言える…
- 734 ：名無しさん＠編集中 ：2018/05/22(火) 12:23:15.14 ID:3IwnndRVa.net
- Google「絶対自社コーデック流行らせるマン」
- 735 ：名無しさん＠編集中 ：2018/05/22(火) 12:25:31.44 ID:J9S5pwTqM.net
- av1はどの程度のデコード負荷になるんだろうね
- 736 ：名無しさん＠編集中 ：2018/05/22(火) 12:59:59.57 ID:hCnh500/M.net
- HEIF形式イメージの読み書きをサポートした「GIMP」v2.10.2が公開
https://forest.watch.impress.co.jp/docs/news/1122970.html
- 737 ：名無しさん＠編集中 ：2018/05/22(火) 15:06:40.87 ID:f7yYRC9xM.net
- HEIFに自動変換してくれるアプリ早く出ないかな
- 738 ：名無しさん＠編集中 ：2018/05/22(火) 19:33:33.87 ID:hkxnh+Qq0.net
- HEIFってそんなにすごいのか？
- 739 ：名無しさん＠編集中 ：2018/05/22(火) 19:37:15.90 ID:49Qgr65Qd.net
- hevcに変換するアプリも無いというのに…
- 740 ：名無しさん＠編集中 ：2018/05/22(火) 20:13:12.99 ID:f7yYRC9xM.net
- xnconvがはやいところ対応してほしい
- 741 ：名無しさん＠編集中 ：2018/05/23(水) 11:55:09.56 ID:HvhLW0tF0.net
- HEIFってOSではポツポツ対応しはじめてるけどフリーソフトではなかなか対応しないね
- 742 ：名無しさん＠編集中 ：2018/05/23(水) 14:50:02.22 ID:Zc10p1dw0.net
- >>732
おんぼろPC+Chromeにh264ify入れて使ってるぜ…
- 743 ：名無しさん＠編集中 ：2018/05/25(金) 23:39:19.34 ID:Yo07VXfMM.net
- avifの音沙汰ないね
- 744 ：名無しさん＠編集中 ：2018/05/26(土) 11:07:51.18 ID:GSqnw95HM.net
- ネタ切れでビデオコーデック以外のネタばっかりになってきたな
それはそれで良いけど
- 745 ：名無しさん＠編集中 ：2018/05/26(土) 13:45:04.81 ID:yfBRopuuM.net
- H.264が動画界のJPEGみたいな感じになって終わりやろ
新フォーマット？なにそれおいしいの？みたいな
- 746 ：名無しさん＠編集中 ：2018/05/26(土) 13:53:41.45 ID:P80ldEHd0.net
- さすがにそれはない
- 747 ：名無しさん＠編集中 ：2018/05/26(土) 20:35:37.87 ID:ckKQMTEV0.net
- 配信があるのでシビアだよ
俺も264で世は収まったと思ってたけど
ある日突然ツベの4Kがガクガクになって思い知ったよ…
- 748 ：名無しさん＠編集中 ：2018/05/26(土) 21:59:19.73 ID:MnpZ35FCM.net
- 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再生が少しでも身近になればいいのだが
- 749 ：名無しさん＠編集中 ：2018/05/26(土) 22:41:47.71 ID:0LnMSXzY0.net
- 面倒すぎてRIPした方が早い気がしてくる
HDMI2.0は破られてるし縛る意味とは
H265が身近になるには、あと数年、スマホのハードウェアデコーダー搭載率が上がったらだね
載ってない世代でCPUデコードはほぼ無理だし
- 750 ：名無しさん＠編集中 ：2018/05/27(日) 01:54:44.50 ID:bNrx3kLn0.net
- スマホはもうH.265全部対応してるぞ
- 751 ：名無しさん＠編集中 ：2018/05/27(日) 08:55:10.14 ID:bYRexonkH.net
- アンドロイド定番の画像ビューワ、PerfectViewerがプラグインでHEIFに対応してた
これで画像一括変換ソフトがHEIF対応してくれればなあ
- 752 ：名無しさん＠編集中 ：2018/05/27(日) 09:27:31.96 ID:RFBUFGHd0.net
- ジャップ製の印刷機やデジタル家電、ソフトなどが対応進まないと無理じゃね
- 753 ：名無しさん＠編集中 ：2018/05/27(日) 11:20:32.94 ID:NTcZ8PLk0.net
- ちょっと戻っちゃうけど
画像の圧縮なら確かにPDFで「文字と背景を分ける」みたいな圧縮方式があるから、漫画の場合は画像一枚の中で背景レイヤーと文字・絵レイヤーを判別して、背景レイヤーを単色データにすればかなり圧縮できるはず
- 754 ：名無しさん＠編集中 ：2018/05/27(日) 12:02:49.06 ID:PvbbGad70.net
- それぞれのレイヤーで最適化しないと
単色データぶんだけデータが増えるだけに終わりそう
- 755 ：名無しさん＠編集中 ：2018/05/28(月) 02:36:51.96 ID:z2/O+KlE0.net
- >>753
これか
https://www.toshiba.co.jp/tech/review/2007/12/62_12pdf/a07.pdf
- 756 ：名無しさん＠編集中 ：2018/05/28(月) 08:31:23.90 ID:K4efXcEF0.net
- Windows10 Insider Previewでheifの表示試してみたけど対応してるのはyuv420だけでyuv444は見れないな
あとx265のフルレンジフラグを読み取ってくれなくてリミテッド専用になってる
将来的には改善されるんだろうか？
今のままならBPGのほうが使いやすいんだが
- 757 ：名無しさん＠編集中 ：2018/05/28(月) 08:41:50.90 ID:K4efXcEF0.net
- ちなみにWIC(Windows Imaging Component)でのサポートもしているのでWIC対応のSusie Pluginを入れるとMassiGraなんかでも見れた
- 758 ：名無しさん＠編集中 ：2018/05/28(月) 09:55:11.67 ID:K4efXcEF0.net
- MSの実装だとYUVからRGBへの変換係数はbt709固定っぽいけどnokiaの実装だとsmpte170m固定っぽいから色がおかしくなる問題が続出しそう
どっちもx265のcolormatrixは読み込みにいってないし(heifのヘッダとかに指定するのかもしれないけどよく分からない)
この辺も整備されないと使いにくいな
- 759 ：名無しさん＠編集中 ：2018/05/28(月) 11:53:22.59 ID:VHhEvktNa.net
- WindowsはOS、画像ビューアともに伝統的にICCプロファイルをきちんと反映させようとしていない（一部の優良な画像ビューアは対応している）からな
- 760 ：名無しさん＠編集中 ：2018/05/28(月) 18:00:44.96 ID:K4efXcEF0.net
- いやごめん
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"
- 761 ：名無しさん＠編集中 ：2018/06/01(金) 19:20:59.50 ID:kSeXDzjIM.net
- 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」はサポートリストに含まれていません
- 762 ：名無しさん＠編集中 ：2018/06/01(金) 19:38:22.92 ID:msrxg0ukM.net
- 動画の再生支援に関しては、スマホに先越されてばかりだな
そのうちスマホをPCに接続して、動画再生支援用の外付けGPUみたいにして使う時代が来るのかね？
- 763 ：名無しさん＠編集中 ：2018/06/01(金) 20:07:36.34 ID:U6b4eKsX0.net
- 新フォーマット→ハードウェア支援
っていたちごっこ
- 764 ：名無しさん＠編集中 ：2018/06/01(金) 20:37:04.23 ID:uvakM5Y80.net
- 先越されていたっけ？
ARMのIP積んだモデル出回るのなんか1年先でしょ
それもPC並みの値段で
- 765 ：名無しさん＠編集中 ：2018/06/01(金) 20:49:35.36 ID:uvakM5Y80.net
- HEVC 10bit 8KならIntelならCore iならKabylake、Atom系ならApolloLake（デコードのみ、エンコはGeminiLake〜）以降で対応
nvidiaならPascal世代で対応済みだから、ARMの方が2年近く遅い
- 766 ：名無しさん＠編集中 ：2018/06/01(金) 20:55:14.58 ID:9DPbKfMc0.net
- 次世代スレなのに>>762が旧世代過ぎて吹いた
- 767 ：名無しさん＠編集中 ：2018/06/01(金) 22:20:39.42 ID:msrxg0ukM.net
- ？
SnapdragonのHEVCハードウェア再生支援は、余年くらい前から対応してたはずたがな
記憶違いか？
- 768 ：名無しさん＠編集中 ：2018/06/01(金) 23:24:22.72 ID:1SKPSPTs0.net
- スマホ -> PC -> モニタ ってめんどくさくね
スマホ -> モニタ でええやんか
- 769 ：名無しさん＠編集中 ：2018/06/02(土) 03:11:43.20 ID:tUT7qzfh0.net
- >>767
8K対応してたん？
- 770 ：名無しさん＠編集中 ：2018/06/02(土) 03:12:45.62 ID:hFj2Wb5N0.net
- 8Kの話なんぞ誰もしてねぇ
- 771 ：名無しさん＠編集中 ：2018/06/02(土) 07:54:52.37 ID:ZfXg0V8T0.net
- http://satch.tv/members/honeybee909/?mref=787
- 772 ：名無しさん＠編集中 ：2018/06/02(土) 19:14:17.19 ID:Ypf4BKGE0.net
- 久々に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まで対応
続く
- 773 ：名無しさん＠編集中 ：2018/06/02(土) 19:14:34.04 ID: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 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
- 774 ：名無しさん＠編集中 ：2018/06/02(土) 19:34:50.70 ID:Ypf4BKGE0.net
- 追記
Snapdragon 820搭載のスマホにVP9でエンコードされた4K60Pの動画を入れて試したところ、
カクカクでした
4K60Pはやはり重い
- 775 ：名無しさん＠編集中 ：2018/06/02(土) 19:36:29.19 ID:OSElj/9u0.net
- ARMはデコードにもGPUの演算コアも使ったりするからな
PC向けGPUみたいにメディアエンジンのみで処理出来るのは世代重ねてからだぞ
ソフトウェアデコーダより消費電力は低いけど、PCで言うところのハードウェアデコーダと少し実装違う
まぁそれでも消費電力の設計母数小さいからまだ省電力と言えるだけで
それでも砂ドラの800や805とかでH265の再生なんぞやったら、FHDでも数十分もせず馬鹿みたい発熱しながらバッテリー消費していく
- 776 ：名無しさん＠編集中 ：2018/06/03(日) 16:10:10.50 ID:D9URccfv0.net
- windowsならタスクマネージャでCPU使用率さくっと分かるけど、androidってシステムていきょうのツールねぇのかよ。
とりあえずCPU statsというアプリで動画再生しながらCPU使用率確認してるけど
- 777 ：名無しさん＠編集中 ：2018/06/03(日) 16:15:21.03 ID:c3tJcF3r0.net
- 俺もandroid8になって
CPU利用率見れなくなって不便してる
- 778 ：名無しさん＠編集中 ：2018/06/03(日) 17:25:49.90 ID:VcUUsYyc0.net
- セロテープ どーです
http://satch.tv/?mref=787
- 779 ：名無しさん＠編集中 ：2018/06/04(月) 18:34:15.74 ID:zpOHy/PYM.net
- ■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はデコード及びエンコードともに非対応
- 780 ：名無しさん＠編集中 ：2018/06/04(月) 23:26:47.05 ID:6FcsBDSw0.net
- デコードもGPUコアのクラスタ数に依存しているという事は、メディアプロセッサだけでは、PC向けGPUと違ってデコードも処理出来ていないって事なんだがな
- 781 ：名無しさん＠編集中 ：2018/06/06(水) 17:26:25.18 ID:MdIonTii00606.net
- クラウド上の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 倍の処理速度を実現しました
- 782 ：名無しさん＠編集中 ：2018/06/06(水) 19:36:41.93 ID:XMNfIyvrp0606.net
- これはいいね。LSIを起こせないようなスタートアップ企業が競い合って早く技術が成熟するといいですな。
大学の研究室からのエントリも面白い。
- 783 ：名無しさん＠編集中 ：2018/06/06(水) 20:17:58.22 ID:BmPMzdiGM0606.net
- 今年の第三四半期にAMDの新型スリッパが32コア64スレッドなCPUを投入するらしいが、そんな強烈なのが出たらHEVCのエンコードもサクサクかな？
- 784 ：名無しさん＠編集中 ：2018/06/06(水) 20:58:49.24 ID:H+EDN/6z00606.net
- 単純に現世代スリッパの2倍弱の性能かと
- 785 ：名無しさん＠編集中 ：2018/06/06(水) 21:00:57.01 ID:Us3T3EKQ00606.net
- 数が物を言うからサクサク
- 786 ：名無しさん＠編集中 ：2018/06/06(水) 22:48:09.02 ID:pgE+EAbY0.net
- 性能倍なら同世代の16C32Tスリッパの倍以上の価格なんだろうけどね
- 787 ：名無しさん＠編集中 ：2018/06/07(木) 06:42:41.69 ID:BUCDO0NW0.net
- AV1のエンコーダーなかなか早くならないな
1080pの10フレームをエンコードするのに52分もかかった
- 788 ：名無しさん＠編集中 ：2018/06/07(木) 06:47:36.47 ID:ZLo0l3oi0.net
- >>787
Intelの5GHz×28コアCPU搭載した化物マシンが必要
- 789 ：787 ：2018/06/07(木) 07:21:29.36 ID:cB42yIva0.net
- いや、>>378ではi7 4702MQで10フレームエンコードするのに66分かかったって書いてるからちょっとは早くなってるかな
こちらのCPUはi7 3520M
- 790 ：名無しさん＠編集中 ：2018/06/07(木) 09:09:09.35 ID:MAsn1r6+M.net
- 今年中に100倍程度速くなるなんて緩い予想はなかなか実現しそうに無いな
- 791 ：名無しさん＠編集中 ：2018/06/07(木) 09:12:18.34 ID:lKIi0lgc0.net
- 1フレームエンコードするのに6分かかるのか
昔の3DCGみたい
- 792 ：787 ：2018/06/07(木) 10:23:58.45 ID:pclL2Ig50.net
- 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秒
- 793 ：名無しさん＠編集中 ：2018/06/07(木) 11:01:08.73 ID:lBbrhKu90.net
- 2ヶ月で2.5倍早くなると仮定しても年内に100倍には届かないか
- 794 ：名無しさん＠編集中 ：2018/06/07(木) 12:50:47.06 ID:T1MKciET0.net
- そんな小学生が成人するまで同じペースで背が伸びて2m越えるみたいな計算通らんわな
- 795 ：名無しさん＠編集中 ：2018/06/07(木) 18:10:44.57 ID:E2VuQZLL0.net
- 欠陥の無いダイがすげー安く作れるようになったらワンちゃんあるかも
- 796 ：名無しさん＠編集中 ：2018/06/07(木) 18:12:56.87 ID:E2VuQZLL0.net
- あ、スレ間違えてた失礼した。
- 797 ：名無しさん＠編集中 ：2018/06/07(木) 20:34:07.06 ID:4TC5oIYZM.net
- 今のところマルチスレッドをあまり生かしてくれないのが遅い原因の一つ
--tile-columnsを指定すると横で分割してマルチスレッドでエンコードしてくれるんだけど、
分割数は2の冪乗で、分割した一列あたり256px以上という制限があるので、
1920x1080の動画をエンコードしても4分割しかされず、
使ってくれるスレッドも4つぐらい
- 798 ：名無しさん＠編集中 ：2018/06/07(木) 22:19:03.47 ID:Dm4DHeUZ0.net
- 2passエンコで１pass目でキーフレームの場所を確定させちゃって
2pass目では複数のGOPを同時並列にエンコとかできないのかね。
- 799 ：名無しさん＠編集中 ：2018/06/08(金) 03:05:32.24 ID:t5SvlNiJd.net
- ならGOP跨ぎでの参照処理出来ないよね
- 800 ：名無しさん＠編集中 ：2018/06/12(火) 14:33:27.03 ID:pd4PE/9P0.net
- https://gigazine.net/news/20180611-google-patenting-work-public-domain/
ans?ってすごいの?
- 801 ：名無しさん＠編集中 ：2018/06/12(火) 20:21:10.83 ID:2LDnx/QSM.net
- >>800
いわゆる対抗特許だね
AV1陣営を特許侵害で訴えようとした企業にカウンターするための特許
- 802 ：名無しさん＠編集中 ：2018/06/14(木) 19:33:30.72 ID:iJOXbjd1M.net
- >>800
ANSは一時期AV1のエントロピー符号化手法の候補になってたけど、
Daalaのエントロピー符号化手法のほうがハードウェア実装しやすいことが分かったので、
採用されなかった。
- 803 ：名無しさん＠編集中 ：2018/06/14(木) 21:29:06.32 ID:V+ozARZ/0.net
- 動画エンコードの探求に「終わり」はあるのか？
https://gigazine.net/news/20180614-end-of-video-coding/
> 2015年にNetflixの技術者が初めてMPEG会議に参加して、将来の動画コーディングのための文書を発表しました。
> その際に、Netflixとしては「大幅な圧縮率の改善が可能ならば、たとえエンコードの複雑性が高まるとしてもまったく問題にしない」というスタンスであることを伝えると、
> 議長から「では、どのくらいの複雑さを許容できますか？」と尋ねられたとのこと。
> 回答の準備が整っていなかったNetflixの技術者は「最悪のケースでは100倍まで」と答えると、100人はいたであろう動画コーディングの専門家たちからは大爆笑が起こったそうです。
> 議長は「心配しないで。彼らはみな『新しいこと』を試すことができると、幸せに感じているのです。たいていの人は『3倍まで』と答えるものだから」と話したそうです。
Netflixは100倍遅くても許容するのかー
やっぱりこれから先の動画圧縮技術はリソース有り余ってる大企業だけのものになるんじゃないだろうか
- 804 ：名無しさん＠編集中 ：2018/06/14(木) 21:45:53.28 ID:3azMp+/KM.net
- エンコードは1回しか行われないのに対してエンコードされた動画は何万回も再生されるから、
例えエンコードに従来の100倍の時間がかかるとしても、
それによって削減される帯域次第では動画配信やってる大手企業は喜んで採用するだろうね。
- 805 ：名無しさん＠編集中 ：2018/06/14(木) 21:57:17.85 ID:Wy3gWiiZ0.net
- まあh266（？）とAV1以降のエンコードは一般人が持ってるpcじゃなかなか難しそうだろうね、NetflixやYouTube規模の動画配信サービスになるとそれだけの価値があるんでしょ
実際、Netflix、YouTube、アマプラ、Huluが完全にAV1を採用すれば全体のデータトラフィック量はどれくらい少なくなるんだろう
- 806 ：名無しさん＠編集中 ：2018/06/14(木) 22:03:37.54 ID:3pgPouao0.net
- ハードエンコの品質が上がって画質にうるさいマニアも納得のハードエンコの時代がきたらまだワンチャンある。
というか今エンコにどれくらいのトランジスター割かれてるのか知らんが何十億って使えばもっと速くなるのかな??
- 807 ：名無しさん＠編集中 ：2018/06/14(木) 22:12:32.44 ID:yHxY31ke0.net
- >>804
なるほど
しかもyoutubeみたく数億人のユーザーがほぼ同時にアップするわけじゃないから
Netflixにとってのハードルは低そう
- 808 ：名無しさん＠編集中 ：2018/06/15(金) 05:00:47.70 ID:GXPu4phC0.net
- 限度知らずに高解像度を無茶な低帯域で保存しようとしなけりゃ、現状のHWエンコでも十分まで行かなくても、そこそこ使えるレベルだと思うけどな
- 809 ：名無しさん＠編集中 ：2018/06/15(金) 05:10:11.86 ID:GXPu4phC0.net
- 品質についてはVLCの連中がx264/x265の開発止めない限り、個人が無償で扱えるエンコード品質の上限的な基準になっちまうから
妥協無しに満足するなんか無理な話だし
HWエンコーダに無い処理の柔軟性で画質引き上げてる部分が大きいから、その溝は埋められない
cudaコアの物量に頼っていないNVDecであの品質だから、nvidiaがQSV並みの実装する気になってくれれば、QSV HEVC並みの品質でQSVの2〜3倍速ってのは不可能では無さそうではあるんだけどな（GPUのグレードに左右されそうではあるけど
- 810 ：名無しさん＠編集中 ：2018/06/15(金) 05:11:02.91 ID:GXPu4phC0.net
- NVDecじゃないや、NVEncだ、すまん
- 811 ：名無しさん＠編集中 ：2018/06/19(火) 00:48:39.51 ID:e172sEo5a.net
- 配信に使おうと思ってQSVとNVENC試してるんだけど同じビットレートだとNVENCのほうが画質良くなるみたいなんだよね
NVENCが何か改善されて良くなったのかな？
それともQSVがリアルタイムエンコに弱いのか
- 812 ：名無しさん＠編集中 ：2018/06/19(火) 01:08:22.25 ID:Ud4iC9hu0.net
- QSVのH264でFF使う場合でも無い限り、基本的にはQSVの方が綺麗になるよ
CBRやビットレートベースのVBR使うとQSVの方が画質容量比悪化しやすいってのもあるけど
- 813 ：名無しさん＠編集中 ：2018/06/19(火) 01:11:14.79 ID:Ud4iC9hu0.net
- あと、比較するQSVの世代にもよる
SnandyやIvy世代はHaswell以降よりCU規模の割に速度出やすい反面、画質向上処理はHaswell以降より劣る（処理が甘い分速くて画質に劣る
- 814 ：名無しさん＠編集中 ：2018/06/19(火) 01:33:27.20 ID:Ud4iC9hu0.net
- CUはRADEONか、QSVはEUだった、すまん
NVEncはエンコードエンジンの性能勝負で
QSVはGPGPU込みで画質が良い（GPGPU使う時間が取れないFFモードだと画質が駄々下がり
画質は
QSV（延滞問わず）＞NVEnc（元から低延滞）＞QSV FF（低延滞モード）
みたいな感じ
- 815 ：名無しさん＠編集中 ：2018/06/19(火) 10:08:37.95 ID:uDXUEk/b0.net
- dGPU化でAMD CPU使いでも使えるようになるといいんだけども＞QSV
- 816 ：名無しさん＠編集中 ：2018/06/19(火) 12:11:03.86 ID:Dw8bee0Da.net
- >>814
なんだレンタル屋の話か
- 817 ：名無しさん＠編集中 ：2018/06/19(火) 12:18:30.59 ID:7QbBqShk0.net
- 延滞？遅延？
どっちが正しい？
- 818 ：名無しさん＠編集中 ：2018/06/19(火) 14:45:39.45 ID:E9MLTUx7M.net
- 日本語きちんと身につけてから書き込め
- 819 ：名無しさん＠編集中 ：2018/06/20(水) 14:56:39.39 ID:c8F+n/KJM.net
- ・「Windows 10 RS5」で“WebP”がサポート、「Microsoft Edge」などで表示可能に
https://forest.watch.impress.co.jp/docs/news/1128464.html
「WebP」をウェッピーと読むのか
ずっとウェブエムだと思ってた…
- 820 ：名無しさん＠編集中 ：2018/06/20(水) 15:02:05.22 ID:VEkuRmOZ0.net
- 突っ込まないわよ
- 821 ：名無しさん＠編集中 ：2018/06/20(水) 15:39:44.03 ID:c8F+n/KJM.net
- 突っ込めよ
わざと書いたのに
- 822 ：名無しさん＠編集中 ：2018/06/20(水) 15:47:51.48 ID:K51XVOXH0.net
- ウェッピーが正式な発音だと知ってるがウェブピーと読んでる
- 823 ：名無しさん＠編集中 ：2018/06/20(水) 15:48:52.74 ID:IFHj6cRM0.net
- やあぼくウェッピー！よろしくね
- 824 ：名無しさん＠編集中 ：2018/06/20(水) 18:04:20.09 ID:n3A/kDrf0.net
- 敢えてウェップでしょ
- 825 ：名無しさん＠編集中 ：2018/06/21(木) 00:23:07.70 ID:g7B91MzM0.net
- ヽ
_,,.,､､,.ｨ-- 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
- 826 ：名無しさん＠編集中 ：2018/06/21(木) 20:30:39.69 ID:SNiRmHlvM.net
- ・4K映像の低遅延配信に「CMAF」が有効、コーデックは「AV1」主流に? Akamaiが解説
https://av.watch.impress.co.jp/docs/news/1128920.html
AV1は、HEVCやVP9などよりも高い圧縮効率を実現し、開発者向けブラウザのFirefox NigtlyやChrome Canaryでは既に採用されているが、3月予定としていたコードフリーズには6月時点でまだ至っておらず、当初の予定より遅延。
現在はエンコードをソフトウェアで行なっているため多くの時間がかかり、時光氏は「ハードウェア対応は'19年後半にずれ込む恐れがある」としている。
まだコードフリーズすらしていないのか
- 827 ：名無しさん＠編集中 ：2018/06/21(木) 21:10:25.27 ID:oS15Ul930.net
- 数ヶ月前にエンコードしたファイルが新しいバージョンだと出来なくなってるとかまだあるから全く使い物にならないよ
- 828 ：名無しさん＠編集中 ：2018/06/21(木) 21:18:04.31 ID:oS15Ul930.net
- 新しいバージョンだと再生出来なくなってるに訂正
- 829 ：名無しさん＠編集中 ：2018/06/21(木) 22:59:51.39 ID:8fdWiSrOM.net
- ttps://github.com/AOMediaCodec/av1-spec/commits/master
仕様のコミットログ見るとぼぼ毎日更新してる。
更新の規模は体裁を整えたりとか、仕様を明確化したりぐらいが多いけど。
ttps://people.xiph.org/~tterribe/pubs/lca2017/aom.pdf
ハードウェア実装しやすいアルゴリズムかどうかはちゃんと考慮されてるみたい。
17ページ目に新しい機能は
ハードウェアチーム、知財チーム、ワーキンググループ全体
の順でレビューされると書かれてる。
- 830 ：名無しさん＠編集中 ：2018/06/21(木) 23:03:09.05 ID:xej6B48ua.net
- ま、あと2年程度は放置プレーでよさそだな
- 831 ：名無しさん＠編集中 ：2018/06/21(木) 23:03:18.05 ID:xqqnzSI30.net
- 個々の要素がHW実装まで考慮に入れてるのはいいね
- 832 ：名無しさん＠編集中 ：2018/06/22(金) 16:24:24.15 ID:L0GSH5Vma.net
- youtubeとかで使われるようになってもほとんどの端末ではしばらくソフトウェアデコードになるだろうけど負荷はどれくらいになるのだろうか
スマホでも余裕なくらいじゃないとキツイぞ
- 833 ：名無しさん＠編集中 ：2018/06/22(金) 18:50:39.55 ID:IFCKBMq30.net
- HWデコーダが無い機種はH.264で観ればいいだけだからﾍｰｷﾍｰｷ
- 834 ：名無しさん＠編集中 ：2018/06/22(金) 19:52:13.05 ID:nB77Vx1HM.net
- すぐに変換されるのは4K以上の動画ぐらいでしょ、きっと
- 835 ：名無しさん＠編集中 ：2018/06/22(金) 23:13:41.12 ID:677v3CKv0.net
- AV1だろうがそもそもモバイルで4K解像度もってるデバイスほとんどみねぇし、2Kにちょっと毛がはえたぐらいの解像度なら現状出回ってる機種でも余裕じゃねぇのかな。
まぁモバイルはバッテリーの問題があるけどさ。
- 836 ：名無しさん＠編集中 ：2018/06/22(金) 23:26:01.34 ID:677v3CKv0.net
- と思ったけどH.264のフルHDをSWﾃﾞｺｰﾄﾞしてみたらFireHD10で結構CPU使用率いくな
- 837 ：名無しさん＠編集中 ：2018/06/23(土) 01:18:47.48 ID:1leUgnj60.net
- YouTubeはビットレートが足りないのと粗雑エンコで1080pは見れたものじゃないから、超高精細映像に構うよりは1080p以下の映像に目線を向けるべきだと
- 838 ：名無しさん＠編集中 ：2018/06/23(土) 06:57:44.25 ID:LsekVHN20.net
- ネットの人ってどうして一つしか正解を許さない人が多いんだろ
- 839 ：名無しさん＠編集中 ：2018/06/23(土) 12:22:52.66 ID:fQhGO9CZ0.net
- 頭が悪いんだろ
脳内が視野狭窄状態みたいになってる奴がいる
- 840 ：名無しさん＠編集中 ：2018/06/26(火) 05:38:09.05 ID:R8Sel04R0.net
- https://aomedia.googlesource.com/aom/
タグがv0.1.0からv1.0.0になった
さすがにそろそろ仕様固まるかな
- 841 ：名無しさん＠編集中 ：2018/06/26(火) 16:10:37.06 ID:DPq5oPAOa.net
- ようやく仕様固まるのか
- 842 ：名無しさん＠編集中 ：2018/06/26(火) 17:28:11.74 ID:rxpWNgp90.net
- くだらねえ
- 843 ：名無しさん＠編集中 ：2018/06/26(火) 18:28:25.06 ID:eXzvmFXU0.net
- AV1の対応、ChromeとFirefoxは着々と進んでいるけどSafariとEdgeはほとんど聞かないね
- 844 ：名無しさん＠編集中 ：2018/06/26(火) 18:51:33.30 ID:t7UcI0u80.net
- >>843
EdgeはともかくSafari（Mac、iOS）は最後まで抵抗しそう
- 845 ：名無しさん＠編集中 ：2018/06/26(火) 20:42:27.35 ID:jPY7pUjf0.net
- Appleだって支援してるんだからそれはねえわ
HEICとか作ってまでh265推してたが今時サンクコストにしがみ付いたりはせんやろ
ただハードウェアエンコーダ/デコーダが実装されているという理由で少なくとも2、3年はOSデフォルトとはせんやろな
- 846 ：名無しさん＠編集中 ：2018/06/26(火) 20:49:18.64 ID:Z8mnTHd/0.net
- AppleもAOMediaの創設時メンバーなのだから、VP9みたいな事態にはならないと思っているがね
- 847 ：名無しさん＠編集中 ：2018/06/26(火) 21:26:45.77 ID:yk3GZ3MSM.net
- Appleが創設メンバー…？
- 848 ：名無しさん＠編集中 ：2018/06/26(火) 21:49:39.83 ID:MeiPf2uT0.net
- 一応なんかAppleはAV1の創設メンバーとしてリストされてるんだよな、詳しく知らん
https://japan.cnet.com/article/35112777/
- 849 ：名無しさん＠編集中 ：2018/06/26(火) 23:34:16.48 ID:H9Tli3nT0.net
- USB Type-C規格策定に大きく関与したが採用せず
LightningケーブルのMFi免罪符で御布施を徴収するAppleのことだ
やすやすMPEG利権を手放すとは思えんな
- 850 ：名無しさん＠編集中 ：2018/06/27(水) 09:00:56.30 ID:bc3cRXpq0.net
- ムービーミドルウェア「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のような映像配信サービスなどで幅広く採用されている。
- 851 ：名無しさん＠編集中 ：2018/06/27(水) 11:46:27.60 ID:uba2bqEXd.net
- >>849
MacBookで採用してるだろ視野狭すぎ
- 852 ：名無しさん＠編集中 ：2018/06/27(水) 13:34:13.58 ID:4GNS9DaQM.net
- macbookの周辺機器MagicKeyboard、MagicTrackpad2、MagicMouse2はLightningだぜ
全てUSB Type-C策定後に発売というね
- 853 ：名無しさん＠編集中 ：2018/06/27(水) 13:51:02.95 ID:4GNS9DaQM.net
- >>851
未だAppleがiPhoneやiPadでLightningに固執する理由って既得権益以外ないだろ
- 854 ：名無しさん＠編集中 ：2018/06/27(水) 14:21:27.37 ID:WJtszjuNM.net
- これだから糞林檎はYO！
- 855 ：名無しさん＠編集中 ：2018/06/27(水) 15:58:37.56 ID:TrufeJFC0.net
- AV1完成したっぽいから試しにエンコードし始めたけど丸一日経っても終わんねー
375フレームをエンコードするのに50時間くらいかかりそうだ
- 856 ：名無しさん＠編集中 ：2018/06/27(水) 16:02:48.32 ID:RzhwDQdzM.net
- 相当ハードウェアエンコーダに実装し易く作ってるらしいしそのうち爆速エンコ出来るようになるでしょ…多分
- 857 ：名無しさん＠編集中 ：2018/06/27(水) 17:38:35.22 ID:5L5AN4qu0.net
- GPUの演算能力でゴリ押しできないのかね
効率的に分解できるアルゴリズムなら…
- 858 ：名無しさん＠編集中 ：2018/06/27(水) 17:48:42.10 ID:Cu7RJFRq0.net
- 2年はかかる
- 859 ：名無しさん＠編集中 ：2018/06/27(水) 19:17:52.14 ID:MCOmMTau0.net
- >>853
LightningからUSB Type-Cに乗り換えるというウワサ話が丁度ネットを駆け巡っているが、はて本当か
- 860 ：名無しさん＠編集中 ：2018/06/27(水) 21:32:31.10 ID:didZgUcUM.net
- >>859
コネクタ全廃という噂もあるぞ
QiならMFi認証存続できるからな
ありえる
- 861 ：名無しさん＠編集中 ：2018/06/27(水) 23:49:32.59 ID:qXlFQQfm0.net
- Lightningに固執っていうけど、
速度と給電能力以外での重要な利点＝リバーシブルの利便性は先行して備わってたわけで
わざわざ変える必要もないと思うんだよね
特に>>852のBT接続な周辺機器の充電用途程度なら
- 862 ：名無しさん＠編集中 ：2018/06/28(木) 11:38:43.47 ID:zedK7pcL0.net
- 圧縮率に伴って重いってのもあるけど
デコード側の負荷低減の為にデータの格納にも手間増やしてるからな
- 863 ：名無しさん＠編集中 ：2018/06/29(金) 20:56:47.39 ID:kZLc7jCp0NIKU.net
- 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に勝てないのかなあ
- 864 ：名無しさん＠編集中 ：2018/06/29(金) 21:03:49.86 ID:q5uPlvEP0NIKU.net
- AV1は重すぎて縮まなくてオワコンになったな
- 865 ：名無しさん＠編集中 ：2018/06/29(金) 22:01:57.82 ID:O0LAEPNuMNIKU.net
- 死産か
- 866 ：名無しさん＠編集中 ：2018/06/29(金) 22:02:11.62 ID:sYmf/fSp0NIKU.net
- コーデックだから「オワコー」が正しい
- 867 ：名無しさん＠編集中 ：2018/06/29(金) 22:05:09.08 ID:O0LAEPNuMNIKU.net
- というか、グラフが正しいならばHEVCとAV1の比較をすると、ほとんど差がないから現時点ではHEVCで充分だな
- 868 ：名無しさん＠編集中 ：2018/06/29(金) 22:25:05.66 ID:Bien472E0NIKU.net
- 最後は政治力やで！
- 869 ：名無しさん＠編集中 ：2018/06/29(金) 22:51:40.14 ID:vhYyDIbv0NIKU.net
- どうせ次世代JPEGと同じでAV1もH265も流行らない
みんなで足の引っ張り合いしてるんだもんなぁ〜歩調合わせないと何やっても無理よ
- 870 ：名無しさん＠編集中 ：2018/06/29(金) 23:26:43.28 ID:oKzo/8sx0NIKU.net
- HEVCは放送での採用が決まっているから問題ない
- 871 ：名無しさん＠編集中 ：2018/06/30(土) 00:53:42.48 ID:bhrpUYQo0.net
- NetflixやHuluみたいなサイトはライセンス料不要なAV1を間違いなく採用する
ユーザーがアップロードできるサイトは知らん
- 872 ：名無しさん＠編集中 ：2018/06/30(土) 01:51:46.92 ID:ZUkZsZo+0.net
- 早くても2年以上先の話
今考える必要はない
- 873 ：名無しさん＠編集中 ：2018/06/30(土) 02:18:19.74 ID:jOwRa4pn0.net
- 結局コンテンツあたりの視聴する客側に課せられるライセンス料なんぞ数円レベルで、
コンテンツ事業者はその分が無くなれば視聴料を数円単位で安くする訳も無く
ストリーミング配信業者ならそれすら無いんだからな
業者は年間の事業者ライセンス料+コンテンツ毎データ作成時のエンコードのライセンス料を払いたくないだけで、視聴する側は再生時の消費リソース増大（電気代）かHW再生支援環境の更新に出費させられるという
- 874 ：名無しさん＠編集中 ：2018/06/30(土) 18:37:48.18 ID:pU26iPezM.net
- >>869
次世代ipegはMSが対応するwebpになりそうだけど
- 875 ：名無しさん＠編集中 ：2018/06/30(土) 19:03:34.73 ID:PbshjbRV0.net
- とりあえず1つだけAV1エンコード出来た
死ぬほど時間かかったしせっかくなんでサンプル欲しい人はどうぞ
最近のFFmpegならデコード出来ると思うので適当に可逆圧縮したりして見て
https://www.dropbox.com/sh/m00enufidjiccn0/AAAlHT953Bxm5xDS2UON6mfGa?dl=0&lst=
- 876 ：名無しさん＠編集中 ：2018/06/30(土) 19:29:20.22 ID:PbshjbRV0.net
- 書き忘れたけど比較のために置いてあるx265、x264はtune ssimでエンコードしてある
それとソースの映像は↓のpedestrian_areaってやつ
https://media.xiph.org/video/derf/
- 877 ：名無しさん＠編集中 ：2018/06/30(土) 19:42:53.62 ID:vwtkTQ8j0.net
- HEVCもAVCもエンコーダー次第だからなぁ。
未だMPEG2のテレビ方法だと差は歴然だが…
低ビットレートだと画質悪いのは当然だし、低ビットレートだとHEVCもAVCよりマシって程度。だから十分なビットレートが確保できる場面が中心になる今後は、AV1よりHEVCで十分としか言いようがない。8KもHEVCで十分。
ビットレート確保できるような大容量回線の開発を進めた方が賢い
- 878 ：名無しさん＠編集中 ：2018/06/30(土) 20:02:41.30 ID:PbshjbRV0.net
- 画像
ソース
http://i.imgur.com/XkoObNC.png
AV1
http://i.imgur.com/4KirEu8.png
x265 slower(tunessim)
http://i.imgur.com/wjprQEu.png
x264 slower(tunessim)
http://i.imgur.com/swlwhoq.png
VP9
http://i.imgur.com/wh7EXNc.png
- 879 ：名無しさん＠編集中 ：2018/06/30(土) 21:40:48.81 ID:hp1X2iG30.net
- サンプルありがとう
ド素人の目で見た感じ
ディテールの表現
AV1＞x264＞x265≒VP9
動画として見て
AV1＞x265＞VP9＞x264
どうせ大したこと無いんだろうとか思ってたけど、かなり良くて驚いた
この性能でエンコード/デコード処理をどこまで軽くできるか…
- 880 ：名無しさん＠編集中 ：2018/06/30(土) 22:13:34.98 ID:40ikmkEsM.net
- 外出先からなんで動画は見れてないのだが、これ相当ビットレート落としてないか？
HEVCでここまで悪化するのはよほどの場合だと思うのだが
- 881 ：名無しさん＠編集中 ：2018/06/30(土) 22:20:36.67 ID:rAbV2HaN0.net
- >>878
乙！
動きのある部分 x265
動きの無い部分 VP9
自分はx265がベストAV1はこれからな感じかなアニメとかにはいいかも
※個人の感想です
- 882 ：名無しさん＠編集中 ：2018/07/01(日) 01:30:59.95 ID:GqIms1KK0.net
- 動画の再生はできないから、静止画のみでコメント
今のところAV1でなければというほどのメリットが見いだせるような画質ではないな
そもそも俺の使い方でFull HDを1000kbpsとか見たいな高圧縮自体使わないし
H.264⇒H.265みたいな画質的メリットがあれば見当もするのだが、それほどでもないし
- 883 ：名無しさん＠編集中 ：2018/07/01(日) 05:10:35.17 ID:clLyaPjq0.net
- 1000kbpsで画質を比較するのは確かにアレだしもっと高いビットレートで比較したいというのはあるんだけど、
AV1の1000kbpsをエンコードするのに40時間もかかって更に高いビットレートだとエンコードに一週間くらいかかりそうな感じなので厳しいかも
- 884 ：名無しさん＠編集中 ：2018/07/03(火) 02:51:05.27 ID:AnLVJYBH0.net
- >>840 でコードにv1.0.0のタグが打たれたようだけど、
仕様の方も固まってたみたいだね。
ttps://aomediacodec.github.io/av1-spec/av1-spec.pdf
やっと最適化が進むのかな
- 885 ：名無しさん＠編集中 ：2018/07/03(火) 10:10:30.99 ID:usUG+8Wf0.net
- 光回線の普及で、日本ではH264のビットレートで十分。
AV1まで時間をかけて無理に圧縮する必要ない
- 886 ：名無しさん＠編集中 ：2018/07/03(火) 10:54:35.51 ID:JbQyuDuIM.net
- もっと鯖の気持ちを考えてあげて！
- 887 ：名無しさん＠編集中 ：2018/07/03(火) 10:58:38.68 ID:WefNX0hR0.net
- 想像力の欠如ってやつだね
- 888 ：名無しさん＠編集中 ：2018/07/03(火) 18:09:15.86 ID:L2WaVTHr0.net
- 何度か書いてきてるけどAV1は俺やお前らのために作られているコーデックではない
- 889 ：名無しさん＠編集中 ：2018/07/03(火) 18:15:45.71 ID:83wcRnei0.net
- 配信事業者やらIT企業の都合で作り始めたコーデックだしなあ
- 890 ：名無しさん＠編集中 ：2018/07/03(火) 19:19:14.23 ID:FBMZ3ZU1M.net
- >>885
wimaxやmvnoなめてんのか
- 891 ：名無しさん＠編集中 ：2018/07/03(火) 19:52:11.99 ID:IHqrS4uda.net
- 弱小MVNOなんか選んだ客が悪い
- 892 ：名無しさん＠編集中 ：2018/07/03(火) 20:05:49.41 ID:XIcbrkpV0.net
- でもさ
いくら優れたコーデックができても
オリジナルは取っておくよな
俺はHDD節約したいだけなのに
- 893 ：名無しさん＠編集中 ：2018/07/03(火) 22:12:22.97 ID:i06F4Ude0.net
- H264/H265でも構わんのに、企業の都合で対応デコーダ積んだ機器に買い換える出費はユーザー持ちという
- 894 ：名無しさん＠編集中 ：2018/07/03(火) 22:17:03.62 ID:i06F4Ude0.net
- >>892
不在時間中にGoogleフォトに上げさせておけば、各種解像度に勝手にエンコードして保管しといてくれるぞ
- 895 ：名無しさん＠編集中 ：2018/07/03(火) 23:44:27.35 ID:L2WaVTHr0.net
- >>893
新フォーマットに対応してないハードやOSならH.264やH.265でDLされるし
手元の機器が古くなって買い換える頃には勝手に対応ハードになってるだけの話だと思うが
新フォーマットが出たら即座に対応機器に買い換えないと気が済まない病気？
- 896 ：名無しさん＠編集中 ：2018/07/04(水) 00:15:04.02 ID:9JZ53MSWa.net
- 圧縮動画をさらに別型式に再圧縮したら確実に劣化する
ようつべでもそうだし
- 897 ：名無しさん＠編集中 ：2018/07/04(水) 06:01:55.78 ID:1aRc/ftm0.net
- 新しい動画規格なんて必要無い、古い規格で十分だ、って言ってる人はなんでこのスレを見てるのか分からん
- 898 ：名無しさん＠編集中 ：2018/07/04(水) 06:22:05.28 ID:NTsfy1jA0.net
- どうせアレだよ、PS2もPS3もPS4も出たら叩き、
ratinaなんて眼の識別能力超えてて無駄とのたまい、
DVDで十分、BDなにそれUHD-BDなんて普及しない
FullHDもいらん、4Kもいらんと言い、HDR何ぞゴミと
絶叫して、その後しれっと手のひら返しする人達のひとり
- 899 ：名無しさん＠編集中 ：2018/07/04(水) 07:25:08.73 ID:ICKr52Ee0.net
- レイトマジョリティってやつじゃないの
- 900 ：名無しさん＠編集中 ：2018/07/04(水) 08:36:17.35 ID:fR6oqR/P0.net
- 新しい規格や新技術なんて必要なら普及するし、不必要なら普及しない。それだけでしょ
それを見守っていくのがこのスレなのに、必要ないわ旧規格で充分だの何だの言うのは意味不明
- 901 ：875 ：2018/07/04(水) 19:40:38.17 ID:+ZHz+wtF0.net
- AV1の2000kbpsを追加
途中までだけどグラフも作った
http://i.imgur.com/9uA0WZD.png
少なくとも低ビットレートでは優秀な性能なのが分かる
- 902 ：名無しさん＠編集中 ：2018/07/04(水) 19:52:55.34 ID:9jIoQc9vM.net
- >>901
そのグラフの変化量から類推すると、3000kbpsで大差なしになりそうだな
そして画質を考えた場合、3000kbps以上は必要になるだろうことを踏まえると、
現時点で時間と電気代費やしてまで個人が手を出すメリットがないという結論になるかと
- 903 ：名無しさん＠編集中 ：2018/07/04(水) 21:29:56.39 ID:C27N09B60.net
- xvc2.0リリース AV1より低ビットレートで画質は同じ位らしい
http://www.releasewire.com/press-releases/divideon-releases-xvc-20-an-open-source-video-codec-with-a-royalty-free-baseline-1005793.htm
- 904 ：名無しさん＠編集中 ：2018/07/04(水) 22:33:25.02 ID:KjRUrpJDa.net
- >>902
どう見ても3000kbpsでも大幅に上回りそうに見えるが…
- 905 ：名無しさん＠編集中 ：2018/07/04(水) 23:37:46.59 ID:Z3IIY3490.net
- グラフの比較検討方法を知らんのか…
- 906 ：名無しさん＠編集中 ：2018/07/04(水) 23:48:30.63 ID:tAoenyjya.net
- 0.97位にはなるでしょ？
それが大幅と言うのは言い過ぎかもしれない
それにネットストリーミングだと1000〜2000kbpsがターゲットでしょ
- 907 ：名無しさん＠編集中 ：2018/07/05(木) 01:02:44.55 ID:8/5ltvOB0.net
- いつからか知らんけど、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
- 908 ：名無しさん＠編集中 ：2018/07/05(木) 01:21:33.48 ID: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
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
- 909 ：名無しさん＠編集中 ：2018/07/05(木) 02:24:55.73 ID:XDZsM6bE0.net
- 人の目で見て、って事でしょ。
それより、ストリーミングはもう3000kbpsは超える時代では？2Mbps程度が最適な環境のユーザーをターゲットにする意味無さそうだし、6Mbpsくらいで考える必要あると思うが。
極端な話、6Mbpsで2Kを配信するか、4K配信に耐えうるか、という
- 910 ：名無しさん＠編集中 ：2018/07/05(木) 03:22:20.00 ID:8/5ltvOB0.net
-
そろそろ次スレの時期なので、テンプレ案を作ってみました。
スレタイにはVVCを追加。
追加・削除・変更案などがあればお願いします。
次世代ビデオコーデック総合スレPart2向けテンプレ案１
https://pastebin.com/91jVdNDp
- 911 ：名無しさん＠編集中 ：2018/07/05(木) 07:59:26.10 ID:+NvaBjbs0.net
- >>908
VP9のエンコはKaby以降にあるじゃない
https://pc.watch.impress.co.jp/img/pcw/docs/1017/921/html/9.jpg.html
https://github.com/intel/intel-vaapi-driver/blob/03a86fc527febd7a2f2d52d3b46fee2c5ccb641b/NEWS#L34
- 912 ：名無しさん＠編集中 ：2018/07/05(木) 10:50:13.05 ID:1UfY3jXYa.net
- >>909
mp4の頃は1080pの動画で5〜8Mbpsが普通だったと思う
それがVP9になったら大体2〜3Mbpsに収まっててビビったけどな
AV1の目的はそれを1〜2Mbpsまで落とすことでしょ
- 913 ：名無しさん＠編集中 ：2018/07/05(木) 10:59:38.12 ID:+KchybRl0.net
- >>912
フロッピーディスク１枚に
フルHDが5,6分入るのか
凄いな
- 914 ：名無しさん＠編集中 ：2018/07/05(木) 11:01:09.89 ID:+KchybRl0.net
- ごめん計算間違えた
- 915 ：名無しさん＠編集中 ：2018/07/05(木) 12:09:40.44 ID:LOVtjgMHM.net
- >>913
そんな夢規格があれば通信問題なんざ一気に解決だな！！！
- 916 ：名無しさん＠編集中 ：2018/07/05(木) 13:20:26.29 ID:z5MGNdXa0.net
- >>909
高いほうのスペックに統一しても割に合わないし
- 917 ：名無しさん＠編集中 ：2018/07/05(木) 14:01:31.81 ID:u1ci+h+3M.net
- 1MbpsでフルHDとか、お花畑すぎるわな
- 918 ：名無しさん＠編集中 ：2018/07/05(木) 14:28:37.34 ID:zvO2XrpYM.net
- トラフィックいっぱいいっぱいで光回線ですら１Ｍ出ないこともあるのに
６Ｍターゲットとかどうなの
- 919 ：名無しさん＠編集中 ：2018/07/05(木) 14:42:34.86 ID:LMro1e0V0.net
- >>911
今のところKabyLakeでVP9エンコード機能を利用できるのはLinuxだけらしいんだけど、
CannonLakeからはWindowsでも使えるようになるかもねという話ね。
>>35と、>>910のテンプレ案の7のところを参照。
>>980まで残り少ないんで、>>910のテンプレ案へのご意見はお早めに。
- 920 ：名無しさん＠編集中 ：2018/07/05(木) 15:04:36.66 ID:B9bh6rCrd.net
- >>894
ハメ撮りとかクラウドに上げられないだろ
- 921 ：名無しさん＠編集中 ：2018/07/05(木) 15:20:05.19 ID:u1ci+h+3M.net
- >>918
回線業者がショボすぎるだけだろ
- 922 ：名無しさん＠編集中 ：2018/07/05(木) 15:45:53.84 ID:6+G1s2KW0.net
- うちはeo光100Mbps契約だが、混んでる時間でも15Mbpsを切ったことはないな
- 923 ：名無しさん＠編集中 ：2018/07/05(木) 16:15:21.43 ID:z5MGNdXa0.net
- 自分の環境がそうだからってみんあそうとは限らないし
そもそもネット配信はスマホなどモバイルでの視聴がかなり多いのに6Mbps以下は切り捨てはマズい判断
- 924 ：名無しさん＠編集中 ：2018/07/05(木) 16:35:18.06 ID:2wqk57+T0.net
- VP9もそうだけど、コンテンツ配信側の意向則したロジックチューニングなのは分かった
- 925 ：名無しさん＠編集中 ：2018/07/05(木) 17:01:32.47 ID:u1ci+h+3M.net
- スマホなんて720pで充分
- 926 ：名無しさん＠編集中 ：2018/07/05(木) 19:20:39.01 ID:JG9+8KmDa.net
- ユーザーの回線環境なんて関係ないだろう
動画配信業者がトラフィック削減のためにやってるんだから
- 927 ：名無しさん＠編集中 ：2018/07/05(木) 20:31:03.07 ID:yYJCBEpPM.net
- そもそもユーザー側で動画をソフトウェアエンコードしたいという需要が今や少数派すぎる。
大多数は動画コンテンツを消費しかしないし、
保存のためにエンコードするにしてもレコーダーとかだからハードウェアエンコード。
- 928 ：名無しさん＠編集中 ：2018/07/05(木) 22:37:22.56 ID:2wqk57+T0.net
- 「今や」とか過去に大勢居たかの様に言われましても
- 929 ：名無しさん＠編集中 ：2018/07/05(木) 23:24:38.71 ID:UP4YHgHg0.net
- 日本のインフラと定額回線を基準に考えているやつは絶望的に想像力が欠如している
大手配信業者がサービス展開してるのは日本のような国ばかりじゃないんだぞ
- 930 ：名無しさん＠編集中 ：2018/07/06(金) 01:08:44.89 ID:wB6j/Bzp0.net
- >>912 YouTubeはH.264で3〜4Mbpsくらいでエンコされてるぞ。VP9も同じくらい（動画によって圧縮できてたり逆にサイズでかくなってたり、差がある）。
個人的な話だけど、コーデックは得意不得意があるせいで、VP9の方が破綻少ない場面が多い反面、H264の方が精細に表現できる場面もあったりするから、圧縮効率よりそっちを重視してる。
- 931 ：名無しさん＠編集中 ：2018/07/06(金) 01:09:19.05 ID:82pzHCNL0.net
- というか日本も固定回線の品質はここ数年で悪化しているような…
- 932 ：名無しさん＠編集中 ：2018/07/06(金) 01:10:41.10 ID:wB6j/Bzp0.net
- スマホで映画やテレビ見るには720pでいいと思う
- 933 ：名無しさん＠編集中 ：2018/07/06(金) 08:41:57.71 ID:dIWrZLr70.net
- テンプレ以外の次世代コーデックはavs2とrmhdとxvcがある
- 934 ：名無しさん＠編集中 ：2018/07/06(金) 09:03:49.80 ID:HwuE0scw0.net
- >>933
あるっちゃあるけどテンプレに入れるほどでもないかなーと・・・
- 935 ：名無しさん＠編集中 ：2018/07/06(金) 11:00:08.84 ID:PAe1KCzn0.net
- armのMali-Vシリーズは？
https://en.wikipedia.org/wiki/Mali_(GPU)#Mali_Video
- 936 ：名無しさん＠編集中 ：2018/07/06(金) 13:22:29.91 ID:d/hR1gKLd.net
- スマホでmpeg2やh264食わせたら、HEVCやVP9に出力してくれるようなアプリって言うあるの？
エンコーダーはカメラ入力しか使えないの？
- 937 ：名無しさん＠編集中 ：2018/07/06(金) 13:22:58.33 ID:d/hR1gKLd.net
- xって言う
oって
- 938 ：名無しさん＠編集中 ：2018/07/06(金) 13:26:19.42 ID:KA2j/Rts0.net
- iOSは知らんが、Androidだとffmpeg media encoderってアプリがある。スマホじゃ遅くて使い物にならんけどな
- 939 ：名無しさん＠編集中 ：2018/07/06(金) 13:38:55.12 ID:s6ngyS3I0.net
- 将来AndroidのHWエンコーダ使ってくれるようになったら
PCの外部エンコーダーとして使えて便利かもね
何台もつなげて高速化
- 940 ：名無しさん＠編集中 ：2018/07/06(金) 14:20:16.16 ID:cdcWZ8cz0.net
- >>936
自分はiPhoneで有料だけど Compressor っての使ってる
https://itunes.apple.com/jp/app/hevc-h-264-video-compressor/id1300463334?platform=iphone&preserveScrollPosition=true#platform/iphone
バッチ処理したいなら同じ作者がバッチ用のアプリも作ってるんでそっちの方がいいかも。
SoCのHWを上手く使っているのかiOSが優秀なのかまあまあ使える速度。さすがに映画クラスの長さだと時間かかるけどな
- 941 ：名無しさん＠編集中 ：2018/07/06(金) 23:31:02.15 ID:H1wvcCGn0.net
- 性能が良い保証無いけどな
- 942 ：名無しさん＠編集中 ：2018/07/08(日) 23:10:27.75 ID:72KoFDYM0.net
- お馴染みXiphのMontyによるAV1技術解説がMozillaのサイトに公開されてたよ
ttps://hacks.mozilla.org/2018/06/av1-next-generation-video-the-constrained-directional-enhancement-filter/
- 943 ：名無しさん＠編集中 ：2018/07/09(月) 00:56:46.59 ID:ydMC3XII0.net
- 日経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で統一されるかな。
- 944 ：名無しさん＠編集中 ：2018/07/09(月) 01:27:41.65 ID:LvywDMFm0.net
- iPhone
Mac
Windows
Android
全部HEIFで統一か
WebP…
- 945 ：名無しさん＠編集中 ：2018/07/09(月) 08:38:59.74 ID:g44dpfk8M.net
- HEIFの作成までサポートするんだろうか。
iOSとの互換性のためにデコードサポートするのは分かるが。
- 946 ：名無しさん＠編集中 ：2018/07/09(月) 10:09:18.81 ID:8vCCKNc1a.net
- なんでも良いからJPEG置き換えんかい！
- 947 ：名無しさん＠編集中 ：2018/07/09(月) 19:40:19.29 ID:yd3g/+Ic0.net
- JPEGの天下は長かったな
- 948 ：名無しさん＠編集中 ：2018/07/09(月) 23:32:09.74 ID:hAiV8Uxta.net
- AV1の画像フォーマットも参戦するだろうけど、それほど力入れてなさそう
画像はユーザーが頻繁にエンコードするから遅いのは嫌われるし勝算は無さそう
- 949 ：名無しさん＠編集中 ：2018/07/10(火) 16:07:49.71 ID:LpG7kyMf0.net
- 日本語訳ありがとう！！
https://github.com/leandromoreira/digital_video_introduction/blob/master/README-ja.md
- 950 ：名無しさん＠編集中 ：2018/07/10(火) 19:12:45.56 ID:NuBz9ymn0.net
- >>949
すっっっごくどうでもいいことだけど
README-ja みたいに「xxx-ja」って表記見ると
愉快な爺さんが「りーどみー、じゃっ☆」ってお茶目に話しかけてる様が思い浮かんでしまうのは自分だけか
むしろ自分だけだと言ってくれ
- 951 ：名無しさん＠編集中 ：2018/07/10(火) 19:45:42.92 ID:kcaWRtgbr.net
- 二度と書き込むなカス
- 952 ：名無しさん＠編集中 ：2018/07/10(火) 20:10:18.38 ID:0QoRwgZ+M.net
- 氏ねボケ
- 953 ：名無しさん＠編集中 ：2018/07/11(水) 20:05:29.28 ID:yFfw/A4u0.net
- 電書の配信で容量大幅に削減できるんだから静止画も変わっていくだろ
ieでwebp対応するし
- 954 ：名無しさん＠編集中 ：2018/07/11(水) 20:53:57.14 ID:Gfe9O3J30.net
- モヒカン族って言葉を思い出したｗ
- 955 ：名無しさん＠編集中 ：2018/07/11(水) 21:45:48.56 ID:rwUV0O350.net
- 早くPDFにHEIFのまま入れられるようにしてくれ
（PDF生成側でHEIFを受け付けてJPEGに再圧縮して…じゃなく
データとしてHEIFのままPDF内にデータを保持する意味で）
- 956 ：名無しさん＠編集中 ：2018/07/11(水) 22:04:12.45 ID:Fb7cjFEd0.net
- >>980も近づいてきたし、>>910のテンプレ案に意見があればお早めに。
次世代ビデオコーデック総合スレPart2向けテンプレ案１
https://pastebin.com/91jVdNDp
- 957 ：名無しさん＠編集中 ：2018/07/12(木) 04:51:27.03 ID:pqOqmAH1H.net
- 静止画HEIＦにするのいいけど、使用料徴収しないのはストリーミングで、ダウンロードする電子書籍とか料金取られないの？
- 958 ：名無しさん＠編集中 ：2018/07/12(木) 05:47:06.28 ID:ovr5gn0h0.net
- コンテナにはロイヤリティも糞も無い
HEIFでターゲットにしている主要画像圧縮コーデックのHEVC Imageにロイヤリティが掛かる（場合がある）けど
コンテナだから別のコーデックでも構わんのよ
ロイヤリティの有無はコンテナじゃ無くて中身で、mkvでもHEVCの映像入れて商用で使えばストリーミング（データ原本丸ごと渡さない）ならロイヤリティ掛からないし
ファイル本体ダウンロードさせたり、メディアに入れて配布すればロイヤリティ対象になる
- 959 ：名無しさん＠編集中 ：2018/07/12(木) 05:55:00.77 ID:m+2xlvvW0.net
- >>956
よく纏まってると思うし、これでいいと思います
- 960 ：名無しさん＠編集中 ：2018/07/12(木) 12:57:01.31 ID:4/QKp30ga.net
- JPEGに比べてややこしいのな
同じHEIFなのにこの環境では開けないぞおォン？？？とか喚く情弱が増えそう
- 961 ：名無しさん＠編集中 ：2018/07/12(木) 15:41:24.25 ID:us2UtKf50.net
- じゃ、コンテナだけ変わっても中身jpegじゃ、意味ねぇ
- 962 ：名無しさん＠編集中 ：2018/07/12(木) 17:40:22.04 ID:JV9dPx6Ea.net
- なんでHEIFの拡張子.heicなんだよ
わけわかんねえ
- 963 ：名無しさん＠編集中 ：2018/07/12(木) 22:35:55.27 ID:ovr5gn0h0.net
- 思い込みで文句言うな
HEIF形式データが入ってりゃの拡張子は.heifでもいいというか、本来の拡張子は.heifで可用性のための別称的な拡張子の方が.heic
画像用のイメージコンテナフォーマット（Image Container Format）なんで
High Efficiency Image Container (format)の意
拡張子が.heifだと、それこそHEIF使っていないと語弊があるんで、必ずしも映像データがHEIFではない可能性も含めて潰しが効く拡張子として.heicがある
入れようと思えば何でも入るが、High Efficiencyと銘打ってるコンテナに入れるのが従来形式データだとなおさら語弊があるから、現状だと実施HEIFぐらいしか無いってだけ
AV1系のAVIFが熟れてくれば候補にはなるのだろうけども
- 964 ：名無しさん＠編集中 ：2018/07/13(金) 02:59:33.26 ID:B1IN6yWN0.net
- >>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にもそういう記述は無いみたいだし。
- 965 ：名無しさん＠編集中 ：2018/07/13(金) 11:04:25.46 ID:FkNZQwXja.net
- HEVCがHigh Efficiency Video Codingだから、heicはHigh Efficiency Image Codingとしか思えない
正式に定義された用語では無いだろうけど
- 966 ：名無しさん＠編集中 ：2018/07/16(月) 04:49:15.58 ID:ODKrLg6K0.net
- H ハゲ
E えっち
I イク
F ファンタジー
- 967 ：名無しさん＠編集中 ：2018/07/16(月) 07:35:31.79 ID:ZGn42TFJa.net
- H えっちな
E エロス
I イクイクッ！
F ファッキン！！！
- 968 ：名無しさん＠編集中 ：2018/07/18(水) 08:10:34.96 ID:oi2flfrT0.net
- Return of the Codec Wars: A New Hope—a Streaming Summer Sequel
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=126339&PageNum=1
- 969 ：名無しさん＠編集中 ：2018/07/18(水) 09:17:26.48 ID:vmjOc4Gpa.net
- https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/
- 970 ：名無しさん＠編集中 ：2018/07/18(水) 11:25:56.30 ID:Suln2Piea.net
- youtubeで使われてるVP9 は、MP4とかH.265より軽いのですか？
- 971 ：名無しさん＠編集中 ：2018/07/18(水) 12:31:59.65 ID:tq6WQNtcM.net
- まずコンテナフォーマットとビデオフォーマットをだな…
x264,265と仮定してエンコードはそのどちらと比べてもどうしようもないぐらい重い。264のデフォ設定と比べれば2桁ぐらい重い。
デコードはハードウェアデコーダの対応具合による。
4k以上の高解像度ならh264よりもVP9/webpの方が軽い場合もある。
- 972 ：名無しさん＠編集中 ：2018/07/18(水) 13:33:16.48 ID:6OJWZgMla.net
- 一般ユーザーは、古い環境で使わないのであればHEVC（H.265）でエンコードしときゃいいのよ
- 973 ：名無しさん＠編集中 ：2018/07/18(水) 21:40:28.65 ID:QhV7PD++0.net
- 誰でも気軽に使えるHEVCエンコーダがあればいいんだけどね
- 974 ：名無しさん＠編集中 ：2018/07/18(水) 23:29:51.57 ID:ZRb7ULNK0.net
- ？
- 975 ：名無しさん＠編集中 ：2018/07/19(木) 01:03:12.14 ID:hL8xCBYE0.net
- もうあるでしょ
- 976 ：名無しさん＠編集中 ：2018/07/19(木) 15:16:43.36 ID:Nzr/Zq0vd.net
- インテルがもう少しQSV-VP9に力入れてくれたらいいのに
- 977 ：名無しさん＠編集中 ：2018/07/19(木) 15:58:19.20 ID:cLbHk/FM0.net
- VP9も結局サービス提供企業側向けだからな
個人ならH264でもHEVCでも良いんだし、HWデコード環境もVP9より困らない
- 978 ：名無しさん＠編集中 ：2018/07/19(木) 18:53:30.98 ID:QaV/T5Z90.net
- 「気軽に」の基準が分からん
- 979 ：名無しさん＠編集中 ：2018/07/19(木) 19:10:17.17 ID:VTuldMi70.net
- ワープロの扱いにすら苦慮してるジジババでもかんたんにできちゃうレベルってことじゃね？（適当）
- 980 ：名無しさん＠編集中 ：2018/07/19(木) 19:18:36.79 ID:VLyg5sPFd.net
- 今でも適当なbatファイルとffmpegで、投げるだけで出来るでしょ
- 981 ：名無しさん＠編集中 ：2018/07/19(木) 19:36:56.99 ID:VLyg5sPFd.net
- 適当な書き込みで踏みましたが
>>910 に則って次スレ立てます
- 982 ：名無しさん＠編集中 ：2018/07/19(木) 19:46:57.55 ID:VLyg5sPFd.net
- 次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
http://mevius.5ch.net/test/read.cgi/avi/1531996911/
- 983 ：名無しさん＠編集中 ：2018/07/19(木) 20:49:46.17 ID:7bo6qBOV0.net
- >>982
１時間に20レスつかないと落ちるという仕様（？）で落ちたっぽいので、新たに立てにいってみます。
- 984 ：名無しさん＠編集中 ：2018/07/19(木) 20:54:31.32 ID:E9rzduoo0.net
- >>983
おっしゃ任せた
- 985 ：名無しさん＠編集中 ：2018/07/19(木) 20:56:22.74 ID:7bo6qBOV0.net
- 次スレ
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1532001049/
テンプレは貼り終わりましたので、20レスつくまで保守カキコ継続。ご協力願います。
- 986 ：名無しさん＠編集中 ：2018/07/19(木) 22:05:14.00 ID:7bo6qBOV0.net
- >>985の次スレはおかげさまにて無事即死回避できた模様なので、こちらはあとは適宜埋めで。
- 987 ：名無しさん＠編集中 ：2018/07/21(土) 11:47:30.03 ID:VvGI6Ed+a.net
- こっちは埋めるか
- 988 ：名無しさん＠編集中 ：2018/07/21(土) 14:32:05.46 ID:XIyJJyuU0.net
- 埋め
- 989 ：名無しさん＠編集中 ：2018/07/21(土) 14:35:00.26 ID:RfzJLkga0.net
- 埋めますかね
- 990 ：名無しさん＠編集中 ：2018/07/21(土) 14:44:32.41 ID:RfzJLkga0.net
- 梅
- 991 ：名無しさん＠編集中 ：2018/07/21(土) 14:50:45.48 ID:RfzJLkga0.net
- 梅梅
- 992 ：名無しさん＠編集中 ：2018/07/21(土) 15:00:15.25 ID:RfzJLkga0.net
- 梅梅梅
- 993 ：名無しさん＠編集中 ：2018/07/21(土) 15:54:15.64 ID:JA0LQWE40.net
- 松
- 994 ：名無しさん＠編集中 ：2018/07/21(土) 15:54:24.29 ID:RfzJLkga0.net
- 梅梅梅梅
- 995 ：名無しさん＠編集中 ：2018/07/21(土) 16:01:19.58 ID:RfzJLkga0.net
- 梅梅梅梅梅
- 996 ：名無しさん＠編集中 ：2018/07/21(土) 16:12:46.33 ID:RfzJLkga0.net
- かゆ・・・梅・・・
- 997 ：名無しさん＠編集中 ：2018/07/21(土) 16:22:45.26 ID:TUh8GWMs0.net
- 次
- 998 ：名無しさん＠編集中 ：2018/07/21(土) 16:23:01.53 ID:TUh8GWMs0.net
- ス
- 999 ：名無しさん＠編集中 ：2018/07/21(土) 16:23:19.60 ID:TUh8GWMs0.net
- レ
- 1000 ：名無しさん＠編集中 ：2018/07/21(土) 16:23:31.04 ID:TUh8GWMs0.net
- 次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
http://mevius.5ch.net/test/read.cgi/avi/1532001049/
- 1001 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1001
285 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★