18/02/01 06:12:19.88 g6ukHWtd0.net
The fastest and worstest AV1 compressor.
URLﾘﾝｸ(github.com)
91:名無しさん＠編集中
18/02/01 09:22:07.45 ndVQlX4qM.net
libvp9より20%圧縮率が高く20%高速かつ
x265より10%圧縮率が高く25%高速なVP9エンコーダ
URLﾘﾝｸ(www.twoorioles.com)
92:名無しさん＠編集中
18/02/01 18:02:44.21 tMorYit7H.net
>>90
肝心の画質はどうなのかな？
画質が落ちるようなら今まで通りx265のソフトウェアエンコードを選ぶし。
93:名無しさん＠編集中
18/02/01 18:35:23.26 ZXxuK7hv0.net
>>82
ks265codecっていうの試してみようと思ったけどパイプ入力も出来ないから使い勝手悪いな
issue見てもkingsoftの許可が無いとパイプ入力実装出来ないみたいな事言ってるし使用制限版って感じやな
ちゃんとした製品版もあるんかな
94:名無しさん＠編集中
18/02/01 21:09:00.28 o44JhFKja.net
>>90
評価版もないやん
95:名無しさん＠編集中
18/02/02 20:28:12.47 PdRQXRFX00202.net
>>44にある、「UHDサンプルでのAV1、JEM、HEVCの主観評価」だけど、Twitterで部分的な情報を見る限りでは
JEM ＞ HEVC ＞ AV1
という結果になったっぽい？詳細な条件とかは不明だけど・・・。
ParkDancersサンプルでのMOS(Mean Opinion Score)グラフ
URLﾘﾝｸ(twitter.com)
BuildingHalllサンプルでのMOSグラフ
URLﾘﾝｸ(twitter.com)
96:9563394 > today at the EBU conference, results were publicly presenting > HEVC superior to AV1. ・・・ https://twitter.com/thierryfautier/status/958779824314638336 イベントのサイトに動画とスライドが置かれてるけど、残念ながら有料登録者しか見れないようだ。 https://tech.ebu.ch/pts2018
97:名無しさん＠編集中
18/02/04 13:41:51.60 2klfab9Z0.net
Firefoxは既にAV1をデコードできるらしいな
98:名無しさん＠編集中
18/02/04 16:29:32.28 XUqQD2miH.net
そういやそうだったな
なんか適当な小さめのAV1動画ある？
99:名無しさん＠編集中
18/02/04 21:00:01.16 oULuZG0G0.net
>>95-96
今のところAV1のデコードができるのはFirefox Nightlyのみ。
●2017/11/28のMozillaの記事
DASH playback of AV1 video in Firefox - Mozilla Hacks - the Web developer blog
URLﾘﾝｸ(hacks.mozilla.org)
●AV1 デモサイト
AV1 Demo by Mozilla and Bitmovin
URLﾘﾝｸ(demo.bitmovin.com)
・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"
100:名無しさん＠編集中
18/02/04 21:10:01.86 oULuZG0G0.net
2018/2/3～2018/2/4 FOSDEM 2018 - AV1 Codec Update
URLﾘﾝｸ(fosdem.org)
（★多分後日スライドのPDFとかが置かれると思う。
昨年の例→ URLﾘﾝｸ(archive.fosdem.org)）
動画：
AV1 Codec Update - YouTube
URLﾘﾝｸ(www.youtube.com)
概要
●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
●あとは技術的な説明
101:名無しさん＠編集中
18/02/06 13:04:20.30 146dcEH50.net
>>98のサイトにスライドのPDFが追加されてた。
av1update.pdf
URLﾘﾝｸ(fosdem.org)
102:名無しさん＠編集中
18/02/06 23:20:13.80 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
URLﾘﾝｸ(www.hikvision.com)
103:名無しさん＠編集中
18/02/07 00:02:51.66 yGFAIvr30.net
ほぼ動かないんだから、そりゃ縮まなきゃ困るわな
104:名無しさん＠編集中
18/02/07 12:33:26.38 0W93IvP+H.net
静止画規格だけでもはやくでてくれないかな
105:名無しさん＠編集中
18/02/08 17:12:22.15 ahLHH27w0.net
Appleも加わったオープンソース動画コーデック「AV1」は本当に業界スタンダードの座を奪えるのか？
URLﾘﾝｸ(gigazine.net)
106:名無しさん＠編集中
18/02/08 20:03:05.72 i8zx3TpAd.net
H.266は語呂悪いし、ワンチャンあるかもな
107:名無しさん＠編集中
18/02/08 20:57:05.60 VcL1Sni00.net
HEVCみたいな別名称がつくのでなかろうか
108:名無しさん＠編集中
18/02/08 21:16:35.59 JA459s+50.net
FVCっていうのはまだ仮称？
109:名無しさん＠編集中
18/02/09 09:12:25.64 tyWh3yoKM.net
>>103
最適化されてもHEVCの10倍複雑でエンコに時間がかかるっていうのはいわゆる全ての機能を使ったhighプロファイル的な状態なのかな?
機能制限してライブ配信等々を目的とした現行のx265並みの負荷で同等の動画出力ってのは構想にあるんだろうか?
OSSみたいだし誰かが勝手にフォークして本体に取り入れられたりみたいな流れになるんかな
110:名無しさん＠編集中
18/02/09 23:14:24.01 3L7c9fII0.net
>>104-106
標準化の仕組みをちゃんと理解してないけど、FVCは今の段階では識別名だったりプロジェクト名だったりで、
標準化が確定したら正式名称になるんじゃないかな。
Requirementの文章を見ると、FVCは新しい標準としてではなく、HEVCの拡張の１つとして標準化されることも
ありえると書いてるようだけど、順当に標準化が進んでいけばH.266/FVCになる可能性が高いんじゃないだろうか。
ITU的には標準化が確定するまでH.266という表現はできないので、H.FVCと呼ぶ感じかな。
111:名無しさん＠編集中
18/02/09 23:15:19.07 3L7c9fII0.net
>>108の参考リンク
H.FVC (ITU-T Work Programme)
URLﾘﾝｸ(www.itu.int)
JVET - Joint Video Experts Team
URLﾘﾝｸ(www.itu.int)
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.
---
112:名無しさん＠編集中
18/02/10 01:30:16.19 6hw14jOB0.net
VP9のエンコードも相当時間かかるのにYoutubeのあの量とあの解像度のVP9をあんなに短時間でどうやってエンコードしてんだろ
113:名無しさん＠編集中
18/02/10 03:03:20.61 5IskUt/U0.net
>>110
ｽﾚﾘﾝｸ(avi板: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
URLﾘﾝｸ(www.youtube.com)
分割処理っぽいね
114:名無しさん＠編集中
18/02/10 11:34:00.92 5Si4CN6e0.net
VLC 3.0.0 リリース
URLﾘﾝｸ(www.videolan.org)
HEVC hardware decoding
Experimental
115: AV1 video and Daala video decoders
116:名無しさん＠編集中
18/02/10 19:42:01.56 KDMWZm0i0.net
>>112
うーん、AV1はまだ仕様固まってないから、どのコミットが使われてるのか知りたいんだが
どこを見れば書いてあるんだろう・・・。
117:名無しさん＠編集中
18/02/11 09:56:37.86 /jeTz4cX0.net
Stand by for H.266 compression
URLﾘﾝｸ(advanced-television.com)
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
118:名無しさん＠編集中
18/02/11 15:45:14.98 fbl1P7Tq0.net
デコードのほうは
intel Kaby以降
NVIDIA 10x0以降
AMD 全滅
でいいのかい?
119:名無しさん＠編集中
18/02/11 16:09:15.55 C+fyqL0s0.net
AMDってAOMediaに加盟してるのにデコード出来ないのか？
120:名無しさん＠編集中
18/02/11 16:40:33.52 NeI0BMkJ0.net
シェーダーだけだからキツいね
Ryzen買えよってことかもw
121:名無しさん＠編集中
18/02/11 17:28:03.21 jAmtemHi0.net
GM206は対応してるGTX960,950
122:名無しさん＠編集中
18/02/11 18:19:24.41 14BIkobe0.net
>>115-118
多分H.265/HEVCの話なんだろうが、どのコーデックの話なのかちゃんと書かないと話が行き違うやろ。
■各社GPUでのハードウェアエンコード/デコードについて
※エンコードについては>>35も参照
●Intel
URLﾘﾝｸ(en.wikipedia.org)
●NVIDIA
URLﾘﾝｸ(developer.nvidia.com)
エンコード： URLﾘﾝｸ(en.wikipedia.org)
デコード： URLﾘﾝｸ(en.wikipedia.org)
●AMD
エンコード： URLﾘﾝｸ(en.wikipedia.org)
デコード： URLﾘﾝｸ(en.wikipedia.org)
123:名無しさん＠編集中
18/02/11 18:33:52.65 fbl1P7Tq0.net
YouTubeガクガクVP9でしょ
AMDが出来ると言って出来てない奴といえば、これが一番遭遇率が高い筈
124:名無しさん＠編集中
18/02/11 20:45:53.51 QWMUaHuD0.net
GPUを利用したソフトウェアデコードとかすれば、専用デコーダ積んでなくても早くなるとかならないもんかな
125:名無しさん＠編集中
18/02/11 22:21:56.05 14BIkobe0.net
>>120
DXVAChecker4.0.0の記事でAMDのVP9デコード支援について色々書かれてた。
URLﾘﾝｸ(bluesky23.blog.shinobi.jp)
調べてみたけど、間違いがあれば教えてほしい。
・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公式からの発表は一切無い（？）
126:名無しさん＠編集中
18/02/11 23:19:48.33 z7SnhiMV0.net
たぶんあってるはず
自作PC板でも同じ報告があった
127:名無しさん＠編集中
18/02/12 00:11:03.60 5x8wkHrd0.net
128:これは機能は実装したけど致命的なバグがあって使い物にならない代物だったということかな? いくらなんでも時間的にもう無理な頃合いだよね
129:名無しさん＠編集中
18/02/12 01:47:14.53 wdHXLY1i0.net
そういえば>>112-113の VLC 3.0.0 でのExperimentalなAV1デコードの話は、
liaomをビルドした上でVLCを--enable-aom付きでビルドすればできるよというだけらしい。
公式ビルドは対応してないようで、av1.webmを再生しようとすると以下のエラーになった。
コーデックがサポートされていません。:
VLCは形式 "av01" (AOMedia's AV1 Video) をデコードできませんでした。
130:名無しさん＠編集中
18/02/12 17:21:06.04 J1qpkTY80.net
xvc codec
URLﾘﾝｸ(xvc.io)
Royalty based next-generation video codec.
Compression performance beyond HEVC.
131:名無しさん＠編集中
18/02/12 19:40:39.87 eKhne4ga0.net
>>126
面白そう。
・サイトが全体的にシンプルにまとまっていて説明もわかりやすい。
・オープンソースでビルドも使い方も簡単そうなエンコーダ／デコーダがGitHubで公開されている。
URLﾘﾝｸ(github.com)
・FAQによるとHEVC比で5～20%のビットレートを削減できるらしい。
・120kbpsでのH.264との比較デモを見る限りでは割と綺麗。
URLﾘﾝｸ(www.divideon.com)
・「HEVCのライセンスプールが複雑でうざい？色々なとこの特許を侵害するのが心配？
うちからxvcのライセンスを買えば、後はうちがやるから特許侵害とか一切気にしなくていいぜ！」
という、攻めてるライセンス形態が、いろんな意味でドキドキ感に溢れている。
132:名無しさん＠編集中
18/02/12 19:57:01.01 XChgmp2Ka.net
潰されるのが目に見えている
133:名無しさん＠編集中
18/02/12 23:33:26.69 eKhne4ga0.net
>>126
いくつか記事があった。
Divideon Creates xvc, an HEVC Codec With Reasonable Pricing - Streaming Media Magazine
URLﾘﾝｸ(www.streamingmedia.com)
Call for Patents in xvc | Feb 8, 2018 - ReleaseWire
URLﾘﾝｸ(www.releasewire.com)
134:名無しさん＠編集中
18/02/13 13:35:49.99 MqWcVoGB0.net
>>129
Jonatan Samuelsson@JonatanDivideon
元々EricssonでHEVCをやってた人みたい。そこを飛び出して新たに始めるとかハッカーっぽくて好き。
135:名無しさん＠編集中
18/02/14 19:03:38.62 r7PseLFEMSt.V.net
mpeg-2特許切れ@米国
136:名無しさん＠編集中
18/02/15 03:04:33.73 0dI75nRxM.net
mp3とac3も最近特許切れになってたよね
137:名無しさん＠編集中
18/02/15 17:05:53.05 dWlqp1Yu0.net
ついにMPEG2の特許が消滅
URLﾘﾝｸ(gigazine.net)
2018年2月13日にアメリカで残っていた最後のMPEG2に関する特許が期限切れを迎えました。
MPEG-2 Patent List
URLﾘﾝｸ(www.mpegla.com)
MPEG2はMoving Picture Experts Group(MPEG)によって策定されたビデオフォーマットで、テレビ放送やDVDなどのメディアなどに広く利用される、最も一般的なビデオ標準規格です。
MPEG2の特許を管理するパテントプールのMPEG LAがMPEG-2の特許リストを更新し、2018年2月13日にアメリカ国内で残っていた最後の特許が期限切れを迎えたことを明らかにしました。
（ ＾ω＾）
138:名無しさん＠編集中
18/02/17 03:40:37.42 hqYzXLDq0.net
AV1は別にHEVC超えなくて同じくらい狙えばよかったんじゃないの？？
同じくらいだとパンチ弱くてすでに普及が進んでるHEVCがあるから、
AV1の普及進まないとみてHEVC越えねらったのかな？
139:名無しさん＠編集中
18/02/17 04:05:24.29 hqYzXLDq0.net
あれか、AV1がHEVCと同じくらいだとひょっとして世代的にVP9と同じになちゃうのかな？・・
140:名無しさん＠編集中
18/02/17 11:48:51.35 h/nUC7SG0.net
つーかDLすると264もVP9も大差無いんだが
どうなってるんだｗ
141:名無しさん＠編集中
18/02/17 16:12:26.51 LDzeOJ530.net
>>136
Youtubeの話かな？「大差ない」と言うのは何を基準にして言ってる？
確かにモノによってはVP9もH.264もファイルサイズ(ビットレート)が同じくらいだったり
むしろVP9の方がでかくなってることもあるし、結局VP9も割とビットレートでゴリ押ししてる感はあるけど、
画質とビットレートのバランスを考慮して比較しないと意味ないぞ。
それに今のYoutubeは1440pより上は一部を除いてVP9だけになってるから高解像度での比較はできないし。
142:名無しさん＠編集中
18/02/17 20:56:16.18 G3h+KrxD0.net
4320p60fpsの動画つべに上げてみたがローカルh264の半分強の負荷で再生出来たのはその為か
再生支援か元々のデコーダが素晴らしいのか知らんけどVP9悪く無いなぁ
143:名無しさん＠編集中
18/02/17 22:00:03.40 LDzeOJ530.net
>>138
使ってるGPUは？
H.264の再生支援は4Kまでだけど、HEVCやVP9はGPUによっては8Kもサポートしてるから、そのせいかもね。
DXVAChecker画像
Intel UHD 630 → URLﾘﾝｸ(forum.doom9.org)
GeForce GT1030 → URLﾘﾝｸ(forum.doom9.org)
144:名無しさん＠編集中
18/02/17 23:17:22.99 LDzeOJ530.net
2018/2/7 (昨年9月の資料)
Performance comparison of AV1, JEM, VP9, and HEVC encoders (Conference Presentation)
URLﾘﾝｸ(www.researchgate.net)
・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のリファレンスモデル。
145:名無しさん＠編集中
18/02/17 23:18:24.56 LDzeOJ530.net
2018/2/9
ITU, ISO Prepare for Next-Gen Video Codec | TvTechnology
URLﾘﾝｸ(www.tvtechnology.com)
・Fraunhoferの人へのインタビュー。
・JVETでのFVC(JEM)の開発状況やHEVCについてなど。
2018/2/15
Race on to bring AV1 open source codec to market, as code freezes | Videonet
URLﾘﾝｸ(www.v-net.tv)
・Bitmovinの人いわく、AV1はあと数週間で仕様が固まるらしいけどエンコードの計算コストがめっちゃ高くて大変。
仕様決定したら今度は死ぬ気で効率を上げる努力をしていかなきゃなんねえ。
146:名無しさん＠編集中
18/02/17 23:52:51.69 LDzeOJ530.net
>>140訂正
× HMはVP9と比べるとエンコード速度は3.4倍だが
〇 HMはVP9と比べるとエンコード速度は3.4倍遅いが
147:名無しさん＠編集中
18/02/18 16:02:09.17 TUo
148:wvH/t0.net
149:名無しさん＠編集中
18/02/18 17:46:31.09 SFAAnmQA0.net
>>139
GTX1080のEVGAのFTW？だからちょいOCモデルかな
と一応CPUは5960Xの4.3Ghz
CPU負荷7～8割から4割程度まで下がった
150:名無しさん＠編集中
18/02/19 06:28:27.03 FlX1XD9/0.net
【2018】 H.265/HEVC Part8 【7680x4320】 スレから誘導させてもらいました
現在NVEncCでHEVCエンコードを行っているのですが
x264の--crf 20に相当するNVEncCの--cqpの値はどの程度のものなのでしょうか？
151:名無しさん＠編集中
18/02/19 08:05:21.78 K9tuILFw0.net
規格もエンコーダーも違うから答えられる人間は存在しない
152:名無しさん＠編集中
18/02/19 10:55:10.75 f9LdXxV20.net
>>145
前にSSIMで比較してみた人がいるからそれを参考にするとか
ｽﾚﾘﾝｸ(avi板:335番)
まあ数字をちょっとずつ調整していって目視で確認するのが一番だろうけど
153:名無しさん＠編集中
18/02/19 11:30:24.02 FlX1XD9/0.net
>>147
レスありがとうございます
ざっくりですが x264の3/5くらいのビットレートを目標に--cqpの値を変化させてみます
154:名無しさん＠編集中
18/02/19 19:18:14.94 mdvnxdra0.net
H.265 (V5) が2/13に承認され、近日中に発行予定。
ITU-T Work Programme H.265 (V5)
URLﾘﾝｸ(www.itu.int)
H.265?:?High efficiency video coding
URLﾘﾝｸ(www.itu.int)
155:名無しさん＠編集中
18/02/20 07:42:36.96 0/pOXWUN0.net
ドイツでは2018年4月25日から地上波がMPEG2からHEVCになるって。知らんかった。
DVB-T2 HD 1080p50 HEVC
URLﾘﾝｸ(www.dvb-t2hd.de)
156:名無しさん＠編集中
18/02/20 11:18:40.74 As+EIqvZM.net
ARD（アーアールデー）やZDF（ツェットデーエフ）、RTL（アールテーエル）など大手含めて完全にMPEG2からHEVCへ切り替えか
日本はアナログ→デジタルの混乱で総務省も大変だったのに、ドイツは二度目の切り替えとかよくやるな
157:名無しさん＠編集中
18/02/20 13:33:19.34 eKCqeHoO0.net
最初からHEVCへの移行も視野に入れた規格にしてただけでは
>>149
なにか変わるんですか？
158:名無しさん＠編集中
18/02/20 13:42:30.85 Dz32tuw70.net
>>143
業界は知らないが、コーデックの開発にはここのサンプルが良く使われる
URLﾘﾝｸ(media.xiph.org)
159:名無しさん＠編集中
18/02/20 14:38:18.23 QLl07UrG0.net
>>152 >>149
>>56のリンク先PDFより
>2.2 ビデオ符号化
> 本会合では2つの作業項目が完了した。1つは、2017年10月にエミー賞を受賞したH.265の改訂版であり、
> 新たにモノクローム10と、メイン10静止画の2つのプロファイルを追加した。
> これは、色空間のアスペクトの修正と、補助的な拡張情報メッセージを追加するものである。
> 補助的な拡張メッセージには、コンテンツの色ボリューム、正距
160:円筒図法とキューブマップによる > 全方位360度投影、リージョンに関するパッキング、球面ローテーション、全天球視点、 > 領域の入れ子及び動き中心のタイルセット抽出情報集合と関連するそれらの入れ子が含まれる。 > .・・・
161:名無しさん＠編集中
18/02/20 14:39:51.28 v8c8RhG5a.net
オワコンジャップとはえらい差だなぁ…
162:名無しさん＠編集中
18/02/20 15:57:20.53 QLl07UrG0.net
>>150
そのサイトやWikipediaの情報を見ると、ドイツでのDVB-T2 HDへの移行自体は2017/3/29から開始されてるみたいだよ。
2018/4/25は移行のPhase 2bってことで、地域が拡大されるということらしい。
2018年秋、2019年春にも地域拡大が予定されていて、それでようやく移行完了らしい。
DVB-T2 HD
URLﾘﾝｸ(de.wikipedia.org)
音声はHE-AACって書いてるね。
163:名無しさん＠編集中
18/02/20 20:54:21.46 eKCqeHoO0.net
>>154
なるほど用途拡大みたいなものね
164:名無しさん＠編集中
18/02/21 18:53:48.88 Ma6ClYSK0.net
HDで提供されてる360°映像は画質クソすぎて見れたもんじゃないから、8Kで提供されるようになれば有り難いね
HEVCにその規格がこれまで盛り込まれてなかったのはビックリだが
165:名無しさん＠編集中
18/02/22 00:00:30.67 YUagvumb0.net
Youtubeは既に8K 360度 3Dってのもあるね。
Youtubeの8K60pのVP9って、どれくらいのスペックなら再生できるんだろ。
166:名無しさん＠編集中
18/02/22 01:37:11.72 9ZW2al3R0.net
>>159
Intel KabyLake以降、NVIDIA Pascal以降で対応してる>>139
AMDはRavenRidge（Vega 11）が遂にDXVAで4K対応したけど8Kはまだ
167:名無しさん＠編集中
18/02/22 07:10:10.70 527zvnld0.net
>>160
4Kでは？
8kデコードに対応したGPUあんの？
168:名無しさん＠編集中
18/02/22 07:12:26.56 Z1Y/m8920.net
URLﾘﾝｸ(en.wikipedia.org)
Feature Set H[edit]
Feature Set H are capable of hardware-accelerated decoding of 8192x8192 (8k resolution) H.265/HEVC video streams.[19]
169:名無しさん＠編集中
18/02/22 07:16:10.77 Z1Y/m8920.net
あぁ、ごめんVP9のことか
170:名無しさん＠編集中
18/02/22 11:45:12.90 FQJIj/Bk0.net
つべのフォーマット272(8K60pのVP9)はGTX1070がギリッギリデコードが追いつく程度
Pascalならデコードはできるデコードは
171:名無しさん＠編集中
18/02/22 16:58:20.95 OcZ5w+720.net
>>160
再生支援の対応状況としてはそうなんだけど、レンダリングの負荷とかもあるので
どこまで実用再生できるのかなーと。
>>164
ということはレンダリングまで含めると厳しい感じなのかな？
気が向いたら最新のDXVACheckerでデコードパフォーマンスや再生パフォーマンスを計測してみてくれると嬉しい。
172:名無しさん＠編集中
18/02/22 18:12:27.62 FQJIj/Bk0.net
テスト対象：URLﾘﾝｸ(www.youtube.com)
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-1
173:00] % デコードパフォーマンスもほぼ同じフレームレート
174:名無しさん＠編集中
18/02/22 21:34:56.88 OcZ5w+720.net
>>166
ありがとうございます。やはり8K60pともなるとかなりギリギリなんですね。
175:名無しさん＠編集中
18/02/23 00:57:20.12 UcFq47wN0.net
固定機能じゃないの?
176:名無しさん＠編集中
18/02/23 09:23:00.85 B6bO8Kex0.net
どういうこと？
177:名無しさん＠編集中
18/02/23 10:33:07.17 UcFq47wN0.net
クラスと動画再生能力が比例するのかどうか
178:名無しさん＠編集中
18/02/23 11:03:46.41 W2529USpM.net
固定機能だけど、GT1030はNVEncが省かれたりしてるので違うかも？単に無効にしてるだけで同じかも？
179:名無しさん＠編集中
18/02/23 11:18:44.90 B6bO8Kex0.net
デコード回路の規模はPureVideoHDのバージョンで同じ気がするけど
GPU VideoDecode Engine Usageはクロック(P-State)で処理能力が変わるので、ピーク性能が同じとは思えない
コア、メモリクロックと違う何かがあるのかもしれんが、わからん
180:名無しさん＠編集中
18/02/23 12:11:45.20 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] %
181:名無しさん＠編集中
18/02/23 12:20:43.65 t8xzXBir0.net
世代が同じであれば性能は同じ
コアクロック依存であるから僅かな差はつくけど
URLﾘﾝｸ(www.computerbase.de)
182:名無しさん＠編集中
18/03/03 17:09:33.22 QZi8vNBpa0303.net
AV1まだかね
どんだけ遅れるんや
183:名無しさん＠編集中
18/03/03 20:10:59.97 xEY45FVi00303.net
圧縮は出来ても速度が尋常じゃなく遅いのが現状なんだっけ？
特許回避しながらどこまで早く出来るのかねえ、技術的な話は分からんが頑張ってもらうしかない
184:名無しさん＠編集中
18/03/03 21:00:50.76 WFD8ngJA00303.net
50代後半の人が定年になるまでは安泰だろ。
来年度以降もミルビューや旧コネクテッドの事業をそのまま続投してもしばらくは大丈夫じゃないかなぁ。
185:名無しさん＠編集中
18/03/04 05:47:46.15 VP/9+pJaa.net
立ち上がりがダメなものはダメという考え
186:名無しさん＠編集中
18/03/04 11:05:35.25 JE86ooyK0.net
youtubeとnetflixが採用するの決めてるし
187:名無しさん＠編集中
18/03/04 11:30:50.78 LCgrZjek0.net
実際に載ってから考えようかｗ
188:名無しさん＠編集中
18/03/04 15:13:48.64 CGGuH8J/d.net
エンコは企業に任せるとしてハードウェアデコードできないと厳しいかね？
189:名無しさん＠編集中
18/03/04 18:01:08.26 tFu0TfNX0.net
Cool New Video Tools: Five Encoding Advancements Coming in AV1 - Bitmovin
URLﾘﾝｸ(bitmovin.com)
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
190:名無しさん＠編集中
18/03/04 20:00:08.11 oGkDec2T0.net
191:> ・Warped motion and global motion compensation MPEG-4で負荷に見合った効率を得られないと不評だった機能だが大丈夫なのか
192:名無しさん＠編集中
18/03/05 22:12:34.09 qgsUZYm70.net
そりゃあハードウェアエンコだろ、それこそニューラルネットワークがーって革新無いと無理だろうねコレ
193:名無しさん＠編集中
18/03/06 05:13:50.29 IFfxdwxma.net
次の次くらいのコーデックはニューラルネットを使ったものになりそうだな
194:名無しさん＠編集中
18/03/06 10:52:12.60 50y01q050.net
>>183
解像度も高く高品質になってるし
MB-Treeみたいな高度な入れ子処理も行うようになってるから
また違う結論に至ったのかもよ
195:名無しさん＠編集中
18/03/06 10:53:26.39 50y01q050.net
対抗馬のhevcを引き合いにMB-Treeって書いたけど
AV1にあるのかは知らない
196:名無しさん＠編集中
18/03/08 08:02:04.92 iSVPQkdJ0.net
Codec wars: The battle between HEVC and AV1
URLﾘﾝｸ(www.ibc.org)
Previewing Android P
URLﾘﾝｸ(android-developers.googleblog.com)
HDR VP9,HEIF,サポート
197:名無しさん＠編集中
18/03/09 02:36:40.39 Uw+UqCKlM.net
HEVC採用、mpeg陣営の最新静止画規格が一番乗りか
webpは中身vp9になって対抗しないのかな
198:名無しさん＠編集中
18/03/09 13:42:37.83 jOrnx8yd0.net
AV1のサンプル動画見ると、MB-tree的な機能を効かせまくってるように感じる。
199:名無しさん＠編集中
18/03/10 02:44:19.30 +NjEiXnyM.net
乾いた雑巾を更に絞るようなもんだしな
ムーアの法則が死亡してるから果たして実用的な時間でエンコ出来るようになるか疑問だわ
200:名無しさん＠編集中
18/03/10 12:34:29.08 XGmzG2gUM.net
20年後くらいかね、実用一歩手前になるのは
201:名無しさん＠編集中
18/03/10 15:55:41.17 GaKpzwKG0.net
つーかVP9でよくね？
202:名無しさん＠編集中
18/03/10 19:08:03.25 3IwdScz10.net
radeonが再生支援対応してくれないので嫌です
203:名無しさん＠編集中
18/03/10 23:40:35.60 EXZUGF6q0.net
>>194
Polaris/VegaのVP9はブラウザ向けの再生支援しかできないようだけど、
RavenRidgeではちゃんとVP9のDXVAにも対応したみたいだよ。
204:名無しさん＠編集中
18/03/14 16:01:23.76 bZRTgAyo0Pi.net
HEVC Advance、配信のロイヤリティ徴収やめるってよ。
HEVC Advance Eliminates Content Distribution Royalty Fees and Reduces Certain Royalty Rates and Caps
URLﾘﾝｸ(www.hevcadvance.com)
HEVC Advance Cuts Content Fees on Streaming
URLﾘﾝｸ(www.streamingmedia.com)
205:名無しさん＠編集中
18/03/14 16:02:35.79 bZRTgAyo0Pi.net
HEVC Advanceがコンテンツ配信著作権使用料廃止、特定の著作権料金と上限を減額
URLﾘﾝｸ(japan.cnet.com)
> 独立系ライセンス供与管理企業のHEVC Advanceは14日、HEVC Advance Patent Licenseから
> 「サブスクリプション」と「タイトルごと」のコンテンツ配信を廃止し、HEVCの普及を加速し、
> ストリーミング、ケーブル、オーバー・ジ・エア・ブロードキャスト、衛星配信をサポートして、
> 最高のビデオ体験を消費者に提供する。今回の発表によって、HEVC Advanceは、
> インターネット・ストリーミング、ケーブル、オーバー・ジ・エア・ブロードキャスト、
> 衛星を含む非物理的なHEVCコンテンツ配信にライセンスを供与しないし、著作権使用料を求めない。
206:名無しさん＠編集中
2018/0
207:3/14(水) 16:20:04.68 ID:bZRTgAyo0Pi.net
208:名無しさん＠編集中
18/03/14 16:39:30.73 K1Ig4i+B0Pi.net
AV1厨発狂
209:名無しさん＠編集中
18/03/14 17:10:19.66 bZRTgAyo0Pi.net
>>198の訂正
>>198の旧の方は20170717時点のもの(webarchiveではこれが最新だった)なんだけど、
2017/10/24
HEVC Advanceが低価格機器の特許使用料見直しを発表
URLﾘﾝｸ(japan.cnet.com)
にあるようにHEVC Advanceは昨年10/24にもライセンスの見直しを行っていた模様。
つまり>>198の旧PDFはその変更前のものとなるので注意。
210:名無しさん＠編集中
18/03/14 17:41:47.41 bRUD/wvZMPi.net
>>199
美味い方に乗っかるから負ける事は無いぞ。
何処まで適用されるのかよく分からんなぁ
211:名無しさん＠編集中
18/03/14 21:05:59.89 bZRTgAyo0Pi.net
しかしあれだな・・・。>>196のStreamingMediaの記事でも
「はぁ？現時点ではロイヤリティの情報を公開するつもりがない？バカなの死ぬの？」
みたいにこきおろされてるVELOS media（HEVCのライセンスプールの１つ）に
SONY、Panasonic、、SHARPといった企業名が並んでるのを見ると、
「やる気がないならHEVC普及の足をひっぱってないで、さっさとMPEG-LAにでも合流しちまえよ」って言いたくなるな。
ちなみにVELOS mediaのHPに行ってみたら無駄に動いてちょっとうざかった・・・。
URLﾘﾝｸ(velosmedia.com)
212:名無しさん＠編集中
18/03/15 00:06:56.39 Ht9rT5VJ0.net
AV1とはw
213:名無しさん＠編集中
18/03/15 03:34:19.14 2haHtVFIa.net
ストリーミングで金がかからなくなるのか
youtubeがどう動くかな
214:名無しさん＠編集中
18/03/15 03:41:00.81 zYh1EV920.net
でも、徴収をやめるのはHEVC Advanceだけで、他にもパテントあるんでしょ？
215:名無しさん＠編集中
18/03/15 09:11:42.62 kse97YDc0.net
Velosとか他の企業も追従する方針
216:名無しさん＠編集中
18/03/15 12:22:00.65 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を抜けたという経緯もある。
●その他
知らん。
217:名無しさん＠編集中
18/03/15 12:33:30.10 tRe8M41+0.net
ブラウザの対応は進むの？
218:名無しさん＠編集中
18/03/15 12:52:16.38 2Wj4FSUF0.net
mukenさんがHEVC Advanceは四天王の中で最弱っていうネタ投稿してたけど
配信側からの徴収は行ってないパテントプールが多いのね
219:名無しさん＠編集中
18/03/15 13:40:55.44 AUeFWL+M0.net
ブラウザはどうなるんだろうね。H.264の時もFirefoxやChromeは対応を渋ってたけど。
現状のブラウザとH.264のライセンスの関係ってどうなってんだろ？
Win10だと
220:IE/Edge/FirefoxはOSが持ってるMediaFoudationのH.264デコーダを呼び出してるみたいだからライセンスは関係無し？ ChromeはMediaFoudationのH.264デコーダを無効にしてもデコードできるみたいだから独自デコーダ持ってるのかな？ ライセンス料はどうなってるんだろ？ H.265についてはWin10 FCUからH.265デコーダが外されて別途ストアからHEVC Video Extensionを入れないと デコードできなくなったみたいだし、それもハードがH.265再生支援をサポートしてないとダメっぽいから そこからなんとかしないとどうしようもなさそうだけど、よくわからない。
221:名無しさん＠編集中
18/03/15 13:43:12.79 AUeFWL+M0.net
まあAV1のこともあるし、バラバラで複雑になってるH.265のパテントホルダーに圧力をかけるためにも、
FirefoxやChromeでのH.265対応はすぐには進まないかもね。
222:名無しさん＠編集中
18/03/16 12:57:23.94 U7HfZ+6s0.net
おいおい、iPhoneで撮ったHEVC動画はどうなるんだよ
能力を存分に発揮できねえじゃねえか
223:名無しさん＠編集中
18/03/16 12:59:03.00 /o7rBYvFM.net
？
224:名無しさん＠編集中
18/03/16 13:07:23.80 be0tsBA40.net
>>212
意味不明なことを言うな
225:名無しさん＠編集中
18/03/16 14:36:03.81 y5RZw7gD0.net
ffmpegはGoogle Summer of Code 2018でHEIF/HEICの読み込みを実装する予定らしい。
SponsoringPrograms/GSoC/2018 - FFmpeg
URLﾘﾝｸ(trac.ffmpeg.org)
HEIF support
・FFmpeg currently does not support reading HEIF/HEIC files although this is a format with increasing usage in mobile devices.
226:名無しさん＠編集中
18/03/17 05:58:04.33 U+G3LyDOa.net
>>210
H.264はOpenH264を使えばCISCOがライセンス料を負担してくれているからね
firefoxはそれを使っているよ
プラグインの欄を見てみればわかると思うけど
227:名無しさん＠編集中
18/03/17 10:04:22.25 4V5lIZ5ud.net
>>216
じゃあOpenh.265作れば解決だね
228:名無しさん＠編集中
18/03/17 10:12:06.24 c5WgWV6Kd.net
>>217
草
229:名無しさん＠編集中
18/03/17 10:17:18.98 MMu9nYqk0.net
なんでCISCOが肩代わりして支払ってるんだろ？
何か弱みでも握られてるのか？
230:名無しさん＠編集中
18/03/17 14:42:00.12 UvukF0qw0.net
>>216
OpenH264はWebRTCで使われてるけど、動画再生には使われていないと思う。
>>210で書いたように、OSのデコーダを無効にしただけで再生できなくなっちゃうし。
231:名無しさん＠編集中
18/03/19 04:03:46.68 C8xTW8Ei0.net
ＡＶ１は死亡確定？
232:名無しさん＠編集中
18/03/19 04:43:24.06 BcFVPvvt0.net
Windows10 Insider PreviewのBuild17623でHEIFがサポートされたみたいですね。
もっとも今回は表示だけで編集はできないそうです。
URLﾘﾝｸ(blogs.windows.com)
233:名無しさん＠編集中
18/03/19 08:47:44.89 UHHkqjkVd.net
編集なんかフォトショ使うから別によくね？
234:名無しさん＠編集中
18/03/19 08:58:13.83 VRLO15170.net
HEIFってBPGみたいに全然使われないかと思ったけど案外採用されてるね
ただ今のところYUV420しかデコード出来ないらしいのが痛いが
235:名無しさん＠編集中
18/03/19 14:22:51.34 2Qm2QmTL0.net
圧縮画像は基本420だから、それほど危惧する必要はないんじゃないの？
236:名無しさん＠編集中
18/03/19 15:57:00.68 TZqX1Vdx0.net
YUV420は赤の崩れみたいな問題もあるし、RGBかYUV444/YUV444P10があった方がいいという話では。
237:名無しさん＠編集中
18/03/19 17:55:52.09 2Qm2QmTL0.net
話飛躍しすぎだろ
238:名無しさん＠編集中
18/03/19 18:02:42.50 Anm1Go+PM.net
420と444とRGB(可逆)で拡張子か何か変えて1発で判断出来るようにしてくれよ
239:名無しさん＠編集中
18/03/19 19:21:39.08 UHHkqjkVd.net
>>228
これ。
HEI0,HEI2,HEI4,HEIRとかなら分かりやすいのに。
240:名無しさん＠編集中
18/03/19 21:23:31.38 CahkNlja0.net
つかHEIFはYUV444まで対応してるだろ
241:名無しさん＠編集中
18/03/19 21:50:09.33 D6I3EPyBa.net
高圧縮なコーデックが流行るのはいい事だと思うけどheifはライセンスどうなってるんだ？
242:名無しさん＠編集中
18/03/19 22:16:18.01 U17HoX680.net
もう旬は過ぎた感じだけど、今更本の自炊を始めよう思ってるんでHEIFが普及してくれるのはありがたい
EPUBやPDFもHEIF対応してくれないかなぁ
243:名無しさん＠編集中
18/03/19 22:38:24.65 TZqX1Vdx0.net
>>230
HEIFの規格自体は対応してても、OSやソフト等がどこまで対応するかは不明だからねえ。
最低でもyuv420p8の heic / hevc ブランドには対応するとして、
heix / hevx への対応が広がるかどうかは、まだわからないのでは。
現時点で何がどこまで対応してるのかはよく知らないけども。
HEIF Technical Information - High Efficiency Image File Format
URLﾘﾝｸ(nokiatech.github.io)
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)
244:名無しさん＠編集中
18/03/20 00:23:51.90 R8zn4cKBM.net
>>232
webpで圧縮しておけばok
245:名無しさん＠編集中
18/03/20 08:38:30.51 CKEX4d97M.net
日テレ系SOC、HEVC 60i 1920x540というかなり特殊な設定使ってるのね
246:名無しさん＠編集中
18/03/20 08:48:16.73 7x3mPA560.net
>>235
HEVCの規格上どうしてもそうなるという可能性が
x265でインタレ保持するときもフィールド分離してやらないといけないし
247:名無しさん＠編集中
18/03/20 12:44:22.64 srbxwjHvM.net
>>235
日テレ系SOCって何？
248:名無しさん＠編集中
18/03/20 13:54:44.32 CKEX4d97M.net
サテライトオペレーションセンター
SNGのこと
249:名無しさん＠編集中
18/03/20 14:30:00.01 kfU99cWY0.net
VLCは3/13のコミットからHEIFに対応しつつあるらしい。
193f466c4a [Tue Mar 13 18:51:32 2018 +0100] [demux: add support for HEIF]
Nightlyで試せるはずだけど、試してはいないので現時点での出来は不明。
URLﾘﾝｸ(nightlies.videolan.org)
250:名無しさん＠編集中
18/03/20 14:46:34.60 srbxwjHvM.net
>>238
結局よくわからん…
関係なさそうだから、突っ込まないでおこう
251:名無しさん＠編集中
18/03/20 15:14:50.28 kfU99cWY0.net
>>240
俺もよく知らんけど、中継車と放送局を結ぶ衛星中継で飛んでるデータのことでは。
>>235
それってどうやって調べたの？どこかの記事？
それとも何らかの方法で受信して解析できるのかな？
252:名無しさん＠編集中
18/03/20 16:26:43.55 VTNp5e8r0.net
>>233
MacだとHEVCデコーダが対応してるのはハード処理、
対応していないのはソフト処理になるようだけど、
Win10のHEVCデコーダはハード処理専用みたいだし、
どうなるのかわからなんなあ
253:名無しさん＠編集中
18/03/20 16:29:32.94 VTNp5e8r0.net
Win10のHEVCデコーダ→HEVCコーデック
URLﾘﾝｸ(www.microsoft.com)
よく見たらWin10のHEVCコーデックもハード処理とソフト処理対応してた
ってことはHEIFも同じ仕様になるかな
Win10のHEVCデコーダ
254:名無しさん＠編集中
18/03/20 17:13:07.49 QNKVjbmVd.net
>>235
LSIチップのSoCじゃないのね。
紛らわしいわwww
255:名無しさん＠編集中
18/03/20 17:49:19.45 T17xvZTR0.net
>>236
HEVCのインタレってそんな仕様なんだ
インタレソースだとh.264に対してそんなにメリット無いのかな？
256:名無しさん＠編集中
18/03/20 19:51:55.87 srbxwjHvM.net
HEVCは本来インタレをサポートしない前提だったんじゃなかったっけ？
今実装されてるのもインタレもどきというか、独自実装のような感じを強く受けるのだが
257:名無しさん＠編集中
18/03/20 22:47:52.30 7b4xVcuId.net
そもそもいつまでインターレース使う気なんだ。
1000年代の代物だぞ。
258:名無しさん＠編集中
18/03/20 23:09:24.05 vhDWXFdj0.net
クリスタルスカルもびっくりなオーパーツだな
259:名無しさん＠編集中
18/03/20 23:20:00.95 v1I/NHqy0.net
インターレースってデジタル時代でメリットあるの？
260:名無しさん＠編集中
18/03/20 23:24:29.53 rlG5VxC10.net
1440x540のデータ量でフルHD60fpsと言い張れる
261:名無しさん＠編集中
18/03/20 23:50:11.87 sl72jklj0.net
>>249
一切ないな。ブラウン管テレビが無くなった今では負の遺産。
262:名無しさん＠編集中
18/03/21 00:01:55.19 l3mF2m2w0.net
>>247
中世から続く歴史の重みだな
263:名無しさん＠編集中
18/03/21 00:02:39.61 9NK4Qowb0.net
H.265にもインタレの規定はあるみたいだし、以前x265スレ
ｽﾚﾘﾝｸ(avi板:173番)-189
で「HMならインタレもデコードできるらしい」と言われてたので試してみたが
うまくいってるように見える。（やり方が間違ってなければだが）
ffmpegやLAV等ではH.265のインタレへの対応が進んでないのかな？
640x360-60i.avs
#-----------------------
# 30fpsのプログレッシブ動画を読み込む
AVISource(360p30.avi)
# -> 640x360 30000/1001fps
#
# TFFとしてフィールド分離
AssumeTFF()
SeparateFields()
# -> 640x180 60000/1001fps
#-----------------------
264:名無しさん＠編集中
18/03/21 00:03:29.42 9NK4Qowb0.net
# x265でインタレースエンコード
# URLﾘﾝｸ(x265.readthedocs.io)
# 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
265:名無しさん＠編集中
18/03/21 00:10:00.67 mqwPxvtg0.net
フィールド周波数高い60Hzだから、倍速120Hzが効きやすくなる
IP変換でかなり正確にブログレッシブ化出来る
データ量が半減する
実は今時のデジタル技術によって逆に見直されてるのがインターレース
266:名無しさん＠編集中
18/03/21 00:51:20.48 Aq0oefQh0.net
>>255
プログレッシブの60Hzも余裕でどんどんプログレッシブ化が進んでるのが実際のとこだと思うんだけど
どういう現場のどんな人達がそういう見直し方をしてるの？
267:名無しさん＠編集中
18/03/21 04:02:23.07 pwvjtYjO
268:0.net
269:名無しさん＠編集中
18/03/21 04:09:27.66 VQ8P8Edj0.net
個人的にはフレームレートや解像度を多少下げても
ノイズの少ない映像を流してくれって思う
ビットレートが高いはずの某有料BSチャンネルですらノイズまみれ
270:名無しさん＠編集中
18/03/21 08:48:21.78 mqwPxvtg0.net
>>258
最近、BSが1920から地デジと同じ1440になって、ビットレートも地デジ並みに下げられたからな
HDでも圧縮率の低い高ビットレートなら、相当きれいなもんだが
271:名無しさん＠編集中
18/03/21 08:48:51.88 mqwPxvtg0.net
>>256
放送
272:名無しさん＠編集中
18/03/21 08:53:22.78 mqwPxvtg0.net
>>257
ちょっといいテレビなら問題なくても、安いテレビだと見られたものじゃなくなるな
30pが増えてるのは、4K60pの撮影編集がXAVC class300だと600Mbpsになり、HD60iの50Mbpsの12倍になるから、記録保存も編集も大変過ぎ
てことで、4K30pの300Mbpsでお茶を濁すから
273:名無しさん＠編集中
18/03/21 13:39:56.54 pwvjtYjO0.net
瞬間的に入る紙吹雪パターンに遭遇したら
ビットレート爆上げするなりブロック格子細かくしたり
そういうのに特化して研究してる優秀なヒト誰も居ないのだろうか
もう記録映像より3Dリアルタイムレンダリングコンテンツが
家庭用に作られるようになる方が先かも知れないけど…
それはそれで三船敏郎と越後製菓がチャンバラする新作とか楽しみだけど
274:名無しさん＠編集中
18/03/21 17:23:57.61 6pEPxKFk0.net
かのDVDフォーラム vs DVD+RWアライアンスみたいな構図やなｗ
275:名無しさん＠編集中
18/03/22 18:40:53.14 klIgLKNE0.net
60pと比べたら60iの方が良いけど、
確かに30pと比べたら60iの方が遥かに良いな
時代はiPadですらリフレッシュレート120Hzなのに30pはガクガク過ぎる
276:名無しさん＠編集中
18/03/22 18:41:33.85 klIgLKNE0.net
60pと比べたら60iの方が良いけど、
↓
60pと60i比べたら60pの方が良いけど、
277:名無しさん＠編集中
18/03/22 23:35:13.24 jISa2O100.net
>>262
つ crf（品質基準）モード
>>264
動きの滑らかさはそうかもしれないけど
画質自体はプログレのほうが断然優れてるから30pのほうがいい
ま、自分でエンコードしない人にはインタレ放送の画質の悪さなんて気づかないだろうけど
278:名無しさん＠編集中
18/03/22 23:41:43.50 rkE2sIcV0.net
>>266
60iは60pの半分の帯域で済むし、普通のテレビのI-P変換でそこそこいい1枚映像の画質が得られるし、効率がいいんだよ
XAVCならHDだと50Mbpsの60iと比較して、4K60pとなると600Mbpsになるから、12倍の帯域とストレージ容量を食い潰すしな
279:名無しさん＠編集中
18/03/23 00:53:11.37 5n0zraop0.net
>>267
なんで>>261と同じ内容を２度繰り返したのかよくわからんが、HDだの12倍だのは本筋とは全く関係なくて、
・4K60pはXAVCだと600Mbpsになって大変。
・4K60pがきつい場合は4K60iか4K30pにしてレートを半分にして誤魔化そう。（それでも300Mbpsだが）
・滑らかさ重視の60iにするか、１枚絵重視の30pにするかは人それぞれだよね。本当は60pが一番いいけど。
ということで、4K過渡期の次善手段として4K60iが選択肢に入ってるというだけでは・・・。
仕方なく使ってるというだけなのを「インタレースが見直されてる」と表現するのは違和感があるな。
4K30pを「お茶を濁す」と表現するなら、4K60iも「お茶を濁してる」ことに変わりはないと思う。
4K放送は60pなんだし。
280:名無しさん＠編集中
18/03/23 01:10:18.00 9jtovvO90.net
意外と収録のみの現場ではPsFが活用されてたりするのだ
281:名無しさん＠編集中
18/03/23 01:52:59.77 5n0zraop0.net
あー、コストや状況等を踏まえてフォーマットを選択するのは当たり前だろうから、
現場でインタレースを使うのが悪いと言ってるわけじゃないよ。
ただ、そういうフォーマット選択って昔からやられてきたことであって、
別に「インタレースが見直されてる」ってわけじゃないんじゃないかなあというか
そのへんの表現で少しモヤっとしただけというか、それだけです。
282:名無しさん＠編集中
18/03/23 03:59:30.27 HcAUFe0E0.net
HEVCでインタレとか何考えてんだ…マジで放送にしか需要無いから
283:名無しさん＠編集中
18/03/23 09:43:04.55 FSUrXQi9a.net
放送も4K以上はプログレッシブのみだよ
284:名無しさん＠編集中
18/03/23 13:22:22.38 pgVKJkyq0.net
ここはPS4proが擬似4Kのために使ってる市松模様方式で…。
285:名無しさん＠編集中
18/03/23 20:53:30.86 DxN2dByn0.net
西田宗千佳のトレンドノート：iPhoneなどで採用されてる新画像フォーマット「HEIF」とは？
URLﾘﾝｸ(u-note.me)
286:名無しさん＠編集中
18/03/23 21:27:12.76 P0t6uZ540.net
綺麗にデインターレースできる映像は
プログレッシブにしても動画サイズはあまり変わらない気がする
287:名無しさん＠編集中
18/03/23 21:56:14.46 DxN2dByn0.net
Multi-Codec DASH Dataset: An Evaluation of AV1, AVC, HEVC and VP9 - Bitmovin
URLﾘﾝｸ(bitmovin.com)
> 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%
288:名無しさん＠編集中
18/03/23 22:57:55.76 BS3JwG/x0.net
AV1 ist eingefroren und 30 Prozent besser als VP9
URLﾘﾝｸ(www.golem.de)
ドイツ語のニュースをgoogle翻訳
AV1の仕様が正式に凍結されていることを関係者が確認しています。
ネタ元
URLﾘﾝｸ(forum.doom9.org)
289:名無しさん＠編集中
18/03/23 23:38:02.32 DxN2dByn0.net
>>277
ついでにネタ元の１つ前のレスからMediaInfoのAV1対応の件。
URLﾘﾝｸ(mediaarea.net)
MediaInfo change log:
Version 18.03, 2018-03-19
--------------
+ AV1: support of AOmedia AV1 based on latest specifications draft, raw (OBU) and in MKV
290:名無しさん＠編集中
18/03/24 00:37:41.39 qRCTBx3V0.net
>>277
死亡確認
291:名無しさん＠編集中
18/03/24 00:58:36.83 L8KD4aVc0.net
HEVC免除化、HEIFの普及で諦めたか…
292:名無しさん＠編集中
18/03/24 01:18:43.26 7cdy0gnA0.net
だったらFirefoxとChromeとEdgeはHEVCに対応してくれるかな？
293:名無しさん＠編集中
18/03/24 02:02:33.48 QzLfB42f0.net
どうだろうねえ。
今みたいにOSが用意するHEVCデコーダを呼び出すといった実装は可能になるんだろうけど、H.264 vs WebM の時のように
HEVC vs AV1
HEIF vs AVIF ( URLﾘﾝｸ(github.com) )
という対決構図を作って、最低でもHEVCのライセンス面での更なる譲歩を引き出すためにゴネる気もする。
まあAV1がどこまで使えるかにもよるけど。主に速度面が心配だ。
294:名無しさん＠編集中
18/03/24 09:49:13.13 2qWnwRRv0.net
仕様が固まったということじゃなくて
規格（開発の）凍結なの？
295:名無しさん＠編集中
18/03/24 10:39:36.48 /8ZYH/E3M.net
3000倍の時間かけてまでエンコードするほどの価値あるコーデックではないということ
296:名無しさん＠編集中
18/03/24 11:11:28.09 mUuN0la/a.net
現状だとVP9のほうが実用的だよな
297:名無しさん＠編集中
18/03/24 11:22:59.48 OdYZP1X9M.net
>>283
仕様凍結(freeze)=仕様確定だな
298:名無しさん＠編集中
18/03/24 11:47:37.77 qcIvBeHn0.net
ハードウェアエンコーダーが出ない限り、AV1に実用性はない
299:名無しさん＠編集中
18/03/24 12:00:23.05 7cdy0gnA0.net
IntelとAMDとNVIDIAの名前があるんだし、HWエンコーダーは出てくると思うぞ
300:名無しさん＠編集中
18/03/24 12:17:23.09 OdYZP1X9M.net
>>281
H.264のSiscoみたく特許料を肩代わりしてくれるところが現れない限り難しいと思うな
拡張機能(有料)で対応とかならあるかもしれんが
URLﾘﾝｸ(m.srad.jp)
＞現状、HEVC/HEIFはエンコード・デコードに特許使用料を少なくともMPEG LAと HEVC Advance に支払わなければ
ならない
Apple は iPhone の中に特許使用料を織り込める。
Android P は端末メーカーが使用料を支払えば良い。
Microsoft は
どうやらHEIFのデコードにはユーザに 120円を Windows Store で
支払わさせることで解決するみたい
301:名無しさん＠編集中
18/03/24 13:51:59.58 /N519Zs3a.net
ciscoではないのか
302:名無しさん＠編集中
18/03/24 13:53:38.44 8WYg/StLa.net
ciscoさん今回もお願いしますよ
303:名無しさん＠編集中
18/03/24 13:58:34.42 OdYZP1X9M.net
>>277
＞現在の計画によると、コーデックの仕様は今年の7月にインターネット標準として採用される予定です。
漸くか
304:名無しさん＠編集中
18/03/24 14:02:43.19 YFnG0BBP0.net
>>279-282,284
うーんこの読解力
305:名無しさん＠編集中
18/03/24 14:08:06.22 OYcfkvl0d.net
120円くらいくれてやるわ。
306:282
18/03/24 14:52:35.93 bfTaA7mB0.net
>>293
ああ、>>280は「AV1が諦めた」と勘違いしてたのか・・・。意味を取り違えた。
>>282はブラウザのHEVC/HEIF対応可能性について書いただけであって
別にAV1の「凍結」を開発中止だと勘違いしたわけじゃないんだけど、
確かに流れだけ見ると勘違いしたように見えてしまうな・・・。
>>281
書き忘れたけど、Edgeは既にWin10FCUで
「デバイス製造元からのHEVCビデオ拡張機能」(HEVC Video Extension)
が入ってればHEVC動画の再生ができるよ。
307:名無しさん＠編集中
18/03/25 08:59:59.37 pJMHgoYV0.net
はようどっちか諦めてくれという願望
308:名無しさん＠編集中
18/03/25 20:49:43.42 1OGVIXi30.net
民生機でも実用的な時間でエンコードもできるコーデックと
少しでも画質容量比を良くするためにエンコに死ぬほど時間がかかるけど
莫大な帯域を消費する配信業者用の業務用コーデックかという話で
どっちが勝ったり諦めたりという話ではないと思うぞ
どのみちAV1は俺らが気軽に扱えるものにはならんだろ
309:名無しさん＠編集中
18/03/25 21:02:42.26 h38wJJ3yd.net
NVencで対応されればワンチャン
310:名無しさん＠編集中
18/03/25 21:10:24.67 Q2SZSXCu0.net
nvencのhevcってx264よりかなり汚いぞ
311:名無しさん＠編集中
18/03/25 21:52:36.65 jB6Kd02v0.net
これまでAviUtlやAvisynthのプラグインの開発者ですら
もうTSやBD,DVDのソースをカットしてフィ
312:ルタ掛けてエンコードしてって作業に飽きてほとんどエンコードしなくなったと言ってるからねぇ... ストレージが大容量化したからTSのままでもスマホやタブレットに転送して視聴した方が楽になったんだと HEVCはQSVのHWエンコーダがそれなりの速度でまあまあの品質だしAppleのお陰で再生環境も揃ってきたし コンシューマはHEVCを選んでおけばいい気がする
313:名無しさん＠編集中
18/03/25 21:54:31.20 FiSUDZO70.net
無駄なエンコは電気代の時間と人生を失う
314:名無しさん＠編集中
18/03/25 23:05:46.47 1AtfY0210.net
BDはさすがに30G超えてくるからエンコ必至だろ。
インタレソースなら解除が面倒だしなぁ…
とりあえずインタレは早く廃れろ
315:名無しさん＠編集中
18/03/26 00:06:49.50 +KFZYi8K0.net
インタレ解除は例のHWインタレ解除フィルター使うか、レコーダーからのキャプチャーならばレコーダーで解除
316:名無しさん＠編集中
18/03/26 02:31:28.27 RO86JFjT0.net
例のフィルタが動くゲフォ詰んだタブレット下さい
317:名無しさん＠編集中
18/03/26 02:59:51.13 Xhp5xuO0M.net
MX150搭載なら安いのはLenovoのideapadあたりか
それでも9万コースだけど
そもそもモバイルで単価の低いCPU積んでるモデルな時点でdGPUなんぞ積まないから、dGPU積んでる時点それなりにするんだよな
そのうえHWデコーダと違ってGPUブン回すから綺麗に処理出来てもバッテリ保たないだろうなぁ
318:名無しさん＠編集中
18/03/26 10:12:48.77 +KFZYi8K0.net
動画エンコードを10万円以下で考えている人はクオリティーなんぞ求めるべきではない
319:名無しさん＠編集中
18/03/26 16:31:27.23 RO86JFjT0.net
avisynth+対応プレイヤーでリアルタイムフィルタ処理すればいいという話だぞ
320:名無しさん＠編集中
18/03/26 17:26:11.15 KAWe9XE/0.net
>>307
なんでボカしてるのか知らんけど、例のフィルタってnekopanda氏のD3DVPだよね？
URLﾘﾝｸ(github.com)
これは「GPUでインタレ解除してプログレッシブでエンコードしたい場合」に使うもの。
インタレソースを再生する場合は普通にレンダラがGPUを使ってインタレ解除するんだから、
再生時にわざわざAvisynth+使ってリアルタイムフィルタ処理なんてする必要ないと思うんだけど。
インタレ解除したものをBlueskyFRCに渡してフレーム補間したいとかなら別だが・・・。
というかインタレ解除とかの話はAvisynthスレとかTSスレとかでやった方がいいと思うよ。
321:名無しさん＠編集中
18/03/26 20:10:25.15 +KFZYi8K0.net
動画の世界は常に流動的だという意識が充分ではないようだな
時代は今後、インターレースからプログレッシブへと潮流が変わっていくことになる
そうすると、やがて再生時にインタレ解除しようにもクオリティーの高いインタレ解除技術が使えなくなっている可能性が高くなってくる
それならばインタレ解除技術が充実している今のうちに解除してからエンコードしておけば、後々インタレ解除のクオリティー問題に悩まされなくて済む
それに再生時にインタレ解除する前提では、再生する環境に依存することになるから、古いPCや安物のプレーヤーを使って再生する必要が出た場合にも、
満足いく再生ができない問題に悩むハメになる
322:名無しさん＠編集中
18/03/26 20:56:20.81 KAWe9XE/0.net
そんな大袈裟な意識持ってるなら、現存する手法よりも
高度なインタレ解除技術が登場する可能性も考慮したほうがいいのでは。
323:名無しさん＠編集中
18/03/26 21:15:43.02 KAWe9XE/0.net
URLﾘﾝｸ(twitter.com)
> 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の仕様が確定し
324:たなんて話は聞いてねーぞ」っつってるな。
325:名無しさん＠編集中
18/03/26 21:19:55.92 8PaOdK0E0.net
>TSのままでもスマホやタブレットに転送して視聴した方が楽になった
君ってすぐ騙されそうだね
326:名無しさん＠編集中
18/03/26 21:56:25.29 DrJlZ7Ahp.net
>>310
確かに
エンコードした後でより優れたインタレ解除が出てきたら後悔しそう
つーか放送がインタレな以上、当分インタレはなくならないでしょ
4K放送は一般に普及するとは思えないし
327:名無しさん＠編集中
18/03/26 22:48:24.53 +KFZYi8K0.net
インタレ解除については、これ以上の進化は期待しにくい
あるとしても時間をかけて演算するディープラーニング系にわずかに可能性はあるが、再生時のリアルタイム処理に使うには不向き
328:名無しさん＠編集中
18/03/26 23:15:06.45 pRgZAAzX0.net
>>308
D3DVPはavisynth+じゃなくても動くことを考えると
KTGMCのことをいってるのでは
329:名無しさん＠編集中
18/03/26 23:26:42.80 XQOEJ7Z10.net
>>312
どう考えても実際にやったことない奴だな
一応TSのままハードウェアデコード＆ハードウェアデインタレースで再生できるけど、
60pじゃなくて30pになるのでカクカクで使い物にならん（Android＆Snapdragonの場合、iPhoneは知らん）
だいたいWiFiなんて11acでも有線GbEより遥かに遅いし時間掛かって面倒
それこそQSVとかでハードウェアデインタレース＆エンコードしといた方が楽
330:名無しさん＠編集中
18/03/27 00:28:21.15 NBCZX+Tg0.net
視野が狭いな
331:名無しさん＠編集中
18/03/27 09:12:37.70 kNxhuClM0.net
だな
332:名無しさん＠編集中
18/03/27 09:46:24.07 MMCQPcYI0.net
最近の流行りはサーバ側でのリアルタイムエンコードでタブレット等での視聴
つまりネットワーク負荷は依然高いからエンコードが使われるわけで
333:名無しさん＠編集中
18/03/27 09:54:51.65 ki8W3Hxg0.net
何がつまりなの？
334:名無しさん＠編集中
18/03/27 11:04:31.00 Y70u6mQ+0.net
エンコード需要は廃れていない
335:名無しさん＠編集中
18/03/27 12:23:48.20 RRMCKFfmd.net
BDは気に入ったのしか取ってないからm2tsのまま取ってるけど、ゲームの録画は可逆だから編集後にエンコしてるわ。
でないと1時間で500GBとかになるし
336:名無しさん＠編集中
18/03/27 14:42:50.91 N7lQDn3s0.net
>>321
廃れたらおしまい
337:名無しさん＠編集中
18/03/27 15:00:08.14 S9EHQTlVd.net
16K無圧縮の帯域を実質スループットで通せるくらいネットの帯域が拡大するまでは廃れないんじゃね？
338:名無しさん＠編集中
18/03/27 15:08:52.32 0YgDMbF30.net
>>323
アホですか
どんなコーデックでも成り立つよそれ
339:名無しさん＠編集中
18/03/28 02:15:40.96 cyNroVs8a.net
物理的に無理やろな
データをテレポートで遅れるくらいにならないと
340:名無しさん＠編集中
18/03/28 04:04:43.76 tfyUQf6yd.net
量子通信かよ
341:名無しさん＠編集中
18/03/28 09:19:05.36 ZttOb1ah0.net
サイトがリニューアル AV1のロゴマークが出来てる！
URLﾘﾝｸ(aomedia.org)
342:名無しさん＠編集中
18/03/28 11:04:46.62 cyNroVs8a.net
ロゴださい…
343:名無しさん＠編集中
18/03/28 12:23:06.23 UjfKVDvMr.net
ロゴええな
344:名無しさん＠編集中
18/03/28 12:24:33.02 ZisaNVK20.net
もう開発者は開発を始められるんだな、俺は無理だが
エンコード速度はどんなもんなんかね
345:名無しさん＠編集中
18/03/28 18:37:41.29 zdmfSnaWM.net
3000倍遅い
346:名無しさん＠編集中
18/03/28 21:08:21.07 3H5NZI/I0.net
HEVCだってリファレンス実装のHMとx265では数百倍は速度が違うのでAV1もこれから多少は最適化されていくと思いたいが
347:名無しさん＠編集中
18/03/28 21:19:11.47 JTuwsH9C0.net
でもそもそもの計算の複雑さがHEVCの10倍とかあるんでしょ?
特許に引っ掛かるので仕方ないといっても流石に酷いように思う
348:名無しさん＠編集中
18/03/28 2
349:2:40:00.04 ID:TX9eYU740.net
350:名無しさん＠編集中
18/03/28 22:45:45.37 DkDQClUJ0.net
AV1始動アナウンス来たみたいだ。
URLﾘﾝｸ(twitter.com)
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
URLﾘﾝｸ(aomedia.org)
351:名無しさん＠編集中
18/03/28 22:48:29.37 DkDQClUJ0.net
Introducing the Industry’s Next Video Codec: AV1
URLﾘﾝｸ(blogs.cisco.com)
352:名無しさん＠編集中
18/03/28 22:52:36.11 KWy8aHMRp.net
なんかロゴが折り紙のように見える
もしかして折り紙的な技術が使われてるとか？
353:名無しさん＠編集中
18/03/28 22:52:50.57 1p2enfpya.net
放送に採用されないコーデックは、どこまでいっても中途半端
ライセンス逃れを開発理由の一つにしている時点で、自ずと限界は来る
354:名無しさん＠編集中
18/03/28 22:54:26.95 DkDQClUJ0.net
Google, Microsoft, Amazon release AV1 compression technology for better streaming video - CNET
URLﾘﾝｸ(www.cnet.com)
355:名無しさん＠編集中
18/03/28 23:03:54.41 DkDQClUJ0.net
aomのコードはまだリリースタグはついてないのか。
356:名無しさん＠編集中
18/03/28 23:37:59.33 FSdNM0II0.net
標準品質で同じ動画を変換するとx264よりx265はどんだけ遅いんだ？
357:名無しさん＠編集中
18/03/28 23:54:01.29 tB8dFHAWd.net
ストリーミング時代に放送がどこまで生き残れるかっていう問題が
358:名無しさん＠編集中
18/03/28 23:57:41.47 DkDQClUJ0.net
>>342
そんなんソースや設定とかによるからなあ。
とりあえずベンチマークスレで色々な環境での結果を見てくるといいんじゃないだろうか。
【x264/x265】実用エンコベンチ Part6
ｽﾚﾘﾝｸ(jisaku板)
359:名無しさん＠編集中
18/03/29 00:40:49.60 wfTjtMTVd.net
俺のRyzen3 2200GだとフルHDの30fpsの動画でx264で20fps、x265だと5fpsくらいしか出なかった記憶がある。まあ普段はHWエンコードしてるんだけど
360:名無しさん＠編集中
18/03/29 01:31:18.21 yJcJr/Yv0.net
もう、昔より半導体の微細化のペースとか遅いんだから、
解像度上げるペースとか新しいコーデック開発するペースも遅くしろよ。
361:名無しさん＠編集中
18/03/29 01:40:01.16 3HDmcthRM.net
>>342
同等の量子化係数でブン回しても6倍以上は重くて、売り文句みたいに2倍も縮むのは希で2/3ぐらい
362:名無しさん＠編集中
18/03/29 08:11:10.11 aTEBv0AB0.net
>>336
Appleからの歓迎コメントがない・・・
363:名無しさん＠編集中
18/03/29 09:23:09.44 /JmJOkBAM.net
>>347
自分環境かつ自分がよくエンコするソースでベンチ取った時
x264のslow?slower?よりx265のfastの方が1.3倍速くて1.6倍程度ビットレート比で綺麗だったから重用してる。
ソース次第やね
364:名無しさん＠編集中
18/03/29 11:50:46.91 Sz3XH2/20.net
>>348
Founding Membersの中ではIBMのコメントも無いね。
Appleは入ったのが今年１月だし、まだ様子見ってのもあるのかもね。
365:名無しさん＠編集中
18/03/29 11:59:27.77 Sz3XH2/20.net
366: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に買収されてるそうだ。
367:名無しさん＠編集中
18/03/29 12:29:54.99 IEct+tAwMNIKU.net
>>349
そりゃプロファイル変えていればね
プリセットを変えればH265のコア部以外の「x265やx264が実装している工夫の部分」で重さが大きく変わる
368:名無しさん＠編集中
18/03/29 12:30:54.42 IEct+tAwMNIKU.net
>>352
プロファイルじゃないや、プリセットだね
369:名無しさん＠編集中
18/03/29 13:04:48.16 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の設定はここらへんが妥協の境界になりそう
370:名無しさん＠編集中
18/03/29 13:48:04.34 2l+rGyKqMNIKU.net
QSVの場合だと、SSIMの0.985挟むcrf（ICQ）がH264でICQ 20～21、HEVCでICQ 22～23あたり
もちろんソースの動きや画の内容で左右される部分は有るけど、うちのところで基準にしてるソースでSSIM拾った感じはこんな感じになってる
371:名無しさん＠編集中
18/03/29 14:14:56.73 F3GGU69n0NIKU.net
>>354
こういう理論的なものと経験則が合致してたらちょった嬉しい
ちなみにx265は --rect --limit-modes を付けたときの画質向上率が凄いと思う
372:名無しさん＠編集中
18/03/29 16:12:48.52 caRlMFDo0NIKU.net
ようやくAV1が表に出てきたと聞いて飛んできました
自分の使い方だと265は264比で大体エンコ時間3倍強でサイズ3割減ぐらいかなぁ
コーデック乗り換えって労力大きいから、ここから乗り換えるとなると
AV1には相当頑張ってもらわないとならない
373:名無しさん＠編集中
18/03/29 17:31:38.63 uSRvzlAxMNIKU.net
>>356
rectはブロックサイズのパターン増えるから捜査処理増えるるけど縮むよね
個人的にはrect入れるならampも入れちまう様にしてる（更に遅くなるけど
※両方とも初期値で無効、ampはrect有効時のみ使用可
あとは--limit-modesはplaceboプリセットじゃないと有効になっていないはずなんで記述する必要は無いかも
比較測定値的なSSIMは下がるけど、人間の知覚的判別しづらいところで圧縮稼ぐpsy系オプションも面白い
psy-rd（デフォルト0.3）とか、表示環境のパネルサイズや解像度に合わせてとかで上げてやると量子化が捗る
374:名無しさん＠編集中
18/03/29 18:06:51.46
375:F3GGU69n0NIKU.net
376:名無しさん＠編集中
18/03/29 18:41:24.30 Sz3XH2/20NIKU.net
>>358
--limit-modesはslow～veryslowで有効、それ以外はplaceboも含めて無効。
(というかここまで詳細な話はx265スレでやった方が良い気も)
URLﾘﾝｸ(x265.readthedocs.io)
URLﾘﾝｸ(bitbucket.org)
377:名無しさん＠編集中
18/03/29 19:20:41.29 0fgUeEol0NIKU.net
HEVC/H.265対抗の動画コーデック「AV1」が正式リリース
～ロイヤリティフリーで利用可能、HEIF対抗も登場か
URLﾘﾝｸ(pc.watch.impress.co.jp)
378:名無しさん＠編集中
18/03/29 21:55:48.46 r/53oFMMMNIKU.net
>>343
いまどき同軸ケーブルだの分波器だの時代錯誤だわな
B-CASカードの次はACASチップ内蔵で利権ウマウマ
379:名無しさん＠編集中
18/03/29 22:15:44.03 5siG2sKR0NIKU.net
バイナリ置いとくわ
URLﾘﾝｸ(www.axfc.net)
380:名無しさん＠編集中
18/03/29 22:21:41.76 Vw8NIuSYHNIKU.net
ACAS＋HEVC＋ACASで海外家電メーカーの参入妨害
利権大国日本
381:名無しさん＠編集中
18/03/29 22:28:23.96 zuIbo6KKMNIKU.net
>>360
なるほど、支障が無い限り更新していないから自分バイナリはプリセットが古いのかもしれない、thx
psy-rdは処理的にピクセル単位の径なんで1.0以下が良いね
動きに対する対応考えればそこから1/2なり1/3するイメージで、逆に動きが無ければバイピクセルな1.0にという感じかと
…とここらへんにしとくか
382:名無しさん＠編集中
18/03/30 00:08:19.72 KTEhNckb0.net
将来、「放送」で生き残るのはＮＨＫだけかな
民放は系列がだんだん減っていくね。
特に危ないのは、フジ系とテレ朝系
383:名無しさん＠編集中
18/03/30 00:43:07.92 mF7ijfowM.net
HM比でMH並みの標準実装・最適化で1.3倍の圧縮効率なんだろうし
H264比で約2倍を謳っていたH265/HEVCが、実効ではアベレージ1.6倍程度な事考えると
エンコーダがより重くなるのは確かだし、実質ライセンス料の影響が殆ど無い、個人運用の自炊エンコ用途で何処まで期待して良いものか
x265水準で作り込まれたとしは重くなりそう
上の方で有るみたいに、x264で重いプリセット使うよりはx265で軽めのプリセット使う方が軽くて縮むみたい範囲で使える範囲なら良いけどな
384:名無しさん＠編集中
18/03/30 01:03:24.41 +cp2612r0.net
逆に同じビットレートなら、x264よりx265の方が高画質になる？
その時もやっぱりx265の方が、1.4倍くらい時間かかるかな？
385:名無しさん＠編集中
18/03/30 03:44:46.29 wQ7yBQFy0.net
>>303
すまん、例のフィルタって何？
386:名無しさん＠編集中
18/03/30 03:47:04.23 wQ7yBQFy0.net
あ、>>308か
387:名無しさん＠編集中
18/03/30 06:40:08.64 jiYPersza.net
逆にってなんだよ
388:名無しさん＠編集中
18/03/30 09:56:17.54 8ShvYluz0.net
個人的にはx265から1割削れて時間5割り増しぐらいに収まれば御の字だと思って居る
389:名無しさん＠編集中
18/03/30 11:50:29.53 56xXezFGa.net
5割増なんかﾑﾘﾑﾘﾑﾘ、
390:ｶﾀﾂﾑﾘよ
391:名無しさん＠編集中
18/03/30 12:13:54.84 ns1V5Mltp.net
符号化性能うんぬんより、特許料ってそんなに重かったのね。新興のコーデックIP会社が中国、アメリカからたくさん出てきて、技術的に枯れるといいなぁー。
392:名無しさん＠編集中
18/03/30 12:19:52.31 HxLVTXPU0.net
圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
と、最近ファイル圧縮のZstandard型式ってのを知って思った
いや、ハードウェアエンコードすりゃいいってなるけどそれじゃつまんないし…
設定次第で早さか圧縮率かを上下幅広く調節できるようなのが見てみたい
393:名無しさん＠編集中
18/03/30 12:24:35.80 I+cSUfY10.net
>圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
それだと旧規格のh.264で十分ってなる
394:名無しさん＠編集中
18/03/30 14:56:53.02 5XG6WxmW0.net
2018/03/29時点のAV1エンコーダー/デコーダー(aomenc.exe/aomdec.exe)のヘルプ
URLﾘﾝｸ(pastebin.com)
395:名無しさん＠編集中
18/03/30 16:40:42.73 5XG6WxmW0.net
AV1でね・・・1920x1080の10フレームだけをi7-4702MQでエンコードしてみたんです。
全然結果が返ってこなかったのでそのまま寝て翌日確認するとそこには・・・
気になる結果は以下のリンクをクリック！
URLﾘﾝｸ(2sen.dip.jp)
-cpu-usedを0～8に変えてみたけど、
エンコード速度は0.00253～0.06101(fps)という結果に。
本領を発揮するのは -cpu-used 0 or 1 だと思うけど、
-cpu-used 0 だと、10フレームエンコードするだけで66分。
1分半のソースをエンコードしようとすると10日かかる計算になった・・・。
396:名無しさん＠編集中
18/03/30 17:45:06.52 56xXezFGa.net
非現実的すぎる処理時間に見合う価値は今のところ存在しないな
397:名無しさん＠編集中
18/03/30 18:17:44.92 lNA8QDqbd.net
スピードは結局改善しないままリリースしたんだな、HWエンコでどこまで早くなるかにもよるけどかなり厳しいだろこれ
YouTubeとか、これから新規にアップされる動画のエンコとか出来るのか？さらに既存の動画をエンコするのとか不可能に近いのでは
398:名無しさん＠編集中
18/03/30 18:26:36.87 M/tVUrz7a.net
ワロタ
何をそんなに計算しているのか
399:名無しさん＠編集中
18/03/30 18:54:53.75 B0XZfDV10.net
最適化やってないからまだ改善もクソもないよ
400:名無しさん＠編集中
18/03/30 19:17:06.49 KbyNBHD+0.net
動画エンコードは、GPUとかの超並列化の恩恵受けられないんですかね
401:名無しさん＠編集中
18/03/30 19:25:43.85 O43nmN/P0.net
>>383
ハードウェアエンコードもGPGPU（シェーダ）ではなくて動画処理専用固定回路でやってるから、
GPGPUだとやりにくいんじゃないの
402:名無しさん＠編集中
18/03/30 19:47:40.55 K8WvML30M.net
中身的にはSIMD頼みの力押しでマルチスレッド化が進んでない感じ
デコーダも同様というか、H265以上に設計レベルで再生に掛かる演算負荷軽減する気無さそう
最初っからハード屋抱き込んだアライアンスになる訳だわこりゃ
403:名無しさん＠編集中
18/03/30 19:54:46.49 /P9igK1z0.net
だから何としか
404:名無しさん＠編集中
18/03/30 22:49:19.58 m5K5pN7rH.net
x264 mediumくらい縮んでx264 mediumより速くて使用料タダ
のが欲しい
405:名無しさん＠編集中
18/03/30 23:26:32.20 Dpl0S177a.net
x264でもopenCL使えるやん
SIMD使うより速いぞ
406:名無しさん＠編集中
18/03/31 00:53:14.67 hznG5K140.net
AV1にライセンス疑惑あり
407:名無しさん＠編集中
18/03/31 00:56:57.23 It4c3/iy0.net
GPGPUの話は前スレでバトルあったのでそれ参照。
結論としては、
x264やx265の開発に実際に関わってる人の話を聞ければ信憑性高いが、
現状このスレにいる人の知識では何を信じていいのかわからんってことにww
408:名無しさん＠編集中
18/03/31 01:43:45.77 QxlbXBFG0.net
AV1のエンコってwaifu2Xくらいかかんのか…いやニューラルエンジンがある今はAV1の方が…
409:名無しさん＠編集中
18/03/31 02:03:48.32 odEcJpjT0.net
各エンコーダのプリセット毎に、VMAFスコア、SSIM、エンコード速度を計測して図にしたので置いときますね。
対象はQSVEnc(H.264)、x264、x265、VP9。速度のとこだけAV1も。
VMAFやSSIMはただの指標なので、最終的に信じるべきなのは自分の目と感覚だということを忘れずに。
VMAFスコア/ビットレート図
URLﾘﾝｸ(2sen.dip.jp)
SSIM/ビットレート図
URLﾘﾝｸ(2sen.dip.jp)
エンコード速度と設定等
URLﾘﾝｸ(2sen.dip.jp)
410:名無しさん＠編集中
18/03/31 03:56:08.25 7Lq4pL0rM.net
適したスレが無さそうなのでここで聞くけど
BRAVIAで再生する時、XAVC S 30p 100Mbpsと60p 150Mbpsってどちらが高画質だと思う？
モーションフローで30pも60p化されて再生されるとして
30pは60pの半分しかフレーム数/秒がないけど、ビットレートは2/3あるから1フレーム当たりの情報量は30pの方が33%多い
パッと見モーションフローは、かなりきれいに中割りコマ生成してる、時々破綻してるけどw
411:名無しさん＠編集中
18/03/31 06:04:46.28 gfuajWwSa.net
画質なら30のほうが良いだろうよ
24にすればもっと画質は良くなるぞ
412:名無しさん＠編集中
18/03/31 08:15:06.95 hdFdnZ7Ya.net
どこが次世代の話だよ
413:名無しさん＠編集中
18/03/31 08:20:23.08 28VsBo+5a.net
昨日今日規格が固まって普及はこれから、ってのが次世代じゃなきゃどんなのが次世代なんだ
規格が決まった瞬間あらゆるデバイスやサービスに浸透するわけじゃ無いんだぜ？
414:名無しさん＠編集中
18/03/31 08:24:17.82 28VsBo+5a.net
ああXAVCの話か
HEVCもこのスレの対象なんで仲間にいれてあげてもいいんじゃない？
415:名無しさん＠編集中
18/03/31 08:30:57.34 ZmwRNZhu0.net
>>393
解像度が書かれてないと思うけど
フルHDならHEVC, h.264ともに10Mbpsあれば十分なことを考えると
両者ともに高画質だと思う
416:名無しさん＠編集中
18/03/31 08:32:22.51 GgHgjFx90.net
HEVC専用スレの方ももうちょっと活用されてもいいのにとは思う
417:名無しさん＠編集中
18/03/31 08:50:46.11 vFJMFRqxM.net
>>393
ソースが30pかどうかにもよる
418:名無しさん＠編集中
18/03/31 10:03:57.04 70L+3RS5p.net
>>393
でも60pの方がフレーム間の差が小さいから、圧縮効率良さそうじゃない？
419:名無しさん＠編集中
18/03/31 10:18:31.32 hznG5K140.net
こんなスレで業務用途のコーデックの話なんか聴いても、まともに答えられるやつなんかほとんどいないだろ
このスレにいる奴の大半はアニメのエンコードばかりしているようなのばかりだ
420:名無しさん＠編集中
18/03/31 10:20:54.96 8ECVPH3aM.net
いきなり自己紹介されても
421:名無しさん＠編集中
18/03/31 10:30:15.52 isuj0kQw0.net
単純に考えて、100Mbpsで30pなら60pの場合は200Mbpsで同等画質じゃないのか？そんな簡単な話でもないんかね？
422:名無しさん＠編集中
18/03/31 11:13:30.34 K2NT3dmHd.net
GOP的な圧縮は画像シーケンスと違って差が小さければ圧縮効率良くなるなら60pはその分圧縮率上がるのでは？
190Mbpsになるのか150Mbpsになるかは知らんが。
423:名無しさん＠編集中
18/03/31 11:36:50.39 RvXB0Q6+0.net
30→60だとフレーム間予測が効いて、順当には必要ビットレートは増えないと思うけど
ビデオカメラのリアルタイムエンコードだと、そうでもないのかもしれない
424:名無しさん＠編集中
18/03/31 11:42:39.82 ykF7JQcmM.net
元ソースが30pとして、単に補完フレームの破綻防止に同じ画の繰り返しでもフレームレート有った方が良いのなら意義はあるのだろうけど
データ容量的に1.5倍の価値が有るかの判断は視覚評価だし、基準は当人であって他人じゃ無いしな
再生するデータの動き内容とか、そのTVの性能に依存するものだし、そもそも他人が容易に判断付くものじゃない
こんな事他人に頼る個人が生成出来るソース規模でも無いし、著作権的にアレな4Kデータとかじゃねーの？
スルーで良いと思う
425:名無しさん＠編集中
18/03/31 11:53:37.40 s8TNa5OjM.net
XAVC Sって半民生向けよね
426:名無しさん＠編集中
18/03/31 12:01:54.84 YdOGGYyO0.net
確かに30pより60pの方が差分が小さくて、処理も軽くなりGOP圧縮効率上がる
QFHD150Mbps 60pってのは、LongGOPならなかなかいい線かも？
30p 1/60シャッター、24p 1/48シャッターでパラパラ撮ってるものがほとんどで、TVのように再生側ハードで倍速や4倍速120pなんてのも普通にある現状
圧縮効率とコマ数とビットレートと3つの相関を知り尽くしてる人なんて、メーカー技術者の上位数人くらいか
427:名無しさん＠編集中
18/03/31 12:11:37.95 jy+pD5jF0.net
>>393
正直コーデック関係ないし、モノによる。
カメラスレかHTPCあたりで聞いた上で自分の目で判断すればいいんじゃないの。
【4K30P】ビデオカメラに60Pは必要か？【FHD60P】
ｽﾚﾘﾝｸ(vcamera板)
【HTPC】動画を高画質に再生しよう Part10
ｽﾚﾘﾝｸ(software板)
428:名無しさん＠編集中
18/03/31 12:30:19.71 70L+3RS5p.net
>>408
半というか完全に民生向けじゃないの？
でも4K 60p 150Mbps で撮影できるカメラって民生用であったっけ？
ハンディカムやαシリーズでも4K 30p 100Mbpsまでしか対応してなかったような
429:名無しさん＠編集中
18/03/31 17:15:06.54 YdOGGYyO0.net
>>411
そう民生向けだけど、FDR-AX1だとXAVC SでQFHD 60p 150Mbps XQDに撮れるから、この構成や性能は業務機
URLﾘﾝｸ(www.sony.jp)
430:名無しさん＠編集中
18/04/02 17:13:28.56 oPPos9Iy0.net
AV1 Is Finally Here, but Intellectual Property Questions Remain
URLﾘﾝｸ(www.streamingmedia.com)
> 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倍程度に下がると思われる。
その他、特許面の話なども含む良記事。
431:名無しさん＠編集中
18/04/02 17:13:37.45 9gr2nxn90.net
4KをQFHDと呼ぶのが主流なの？
それはさておき、そもそも補完される画は完璧じゃない(当然破綻もある)から、それ考えると60pの方がいいとは思う。
破綻しないような簡単な映
432:像なら30pも60pも差は出ないだろうし。複雑で破綻するような映像ならば60p一択だろ。 蛇足だが、フレーム補完は無視して、フレームレートは30pでいいというなら、単純に考えて画質は30pの方がいい。
433:名無しさん＠編集中
18/04/02 17:21:35.97 ZeLxJCDAa.net
VP9の100倍ワロタ
434:名無しさん＠編集中
18/04/02 18:47:58.74 osbzaKkp0.net
100by遅い→使いものにならないと自白
年末まで待て。それでもかったるい結果が予想される
435:名無しさん＠編集中
18/04/02 18:54:52.32 Sc8XCrCD0.net
x265もリリースしたての時は全然速度出なかったろ
いきなり最適化されたものが出てくるわけない
436:名無しさん＠編集中
18/04/02 19:16:00.41 1iHpNus20.net
ハードエンコの有無っぽい数字だな
VP9はある程度立ち上がって
誰でも効果を確認出来るし…
決まったかな？
437:名無しさん＠編集中
18/04/02 21:10:47.61 ggAtiSao0.net
30%程度の効率改善程度では、コーデックを切り替えるほどの意味はない
せめて平均で50%の改善がないとな
438:名無しさん＠編集中
18/04/02 21:56:53.59 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のストリーミング市場での成功は約束されたようなものだ。
439:名無しさん＠編集中
18/04/02 22:05:12.36 ggAtiSao0.net
UHD-BDだけならともかく、放送にも採用されたHEVCをプゲラッチョとか、頭悪いにもほどがある
440:名無しさん＠編集中
18/04/02 22:29:51.94 oPPos9Iy0.net
いや、ストリーミング市場限定の話として書いてあることくらいわかるだろ・・・
441:名無しさん＠編集中
18/04/02 23:09:39.49 EF/PBVqKM.net
記事の紹介や和訳には感謝だけど、個人の主観混ぜ込むのは誘導にも似た効果も含むから控えた方が良いと思う
442:名無しさん＠編集中
18/04/02 23:26:26.38 w08Zt+n5a.net
結局、延々と264が続くことになる
まで読んだ
443:名無しさん＠編集中
18/04/02 23:31:33.78 /LEGdCOu0.net
そもそも、ライセンス料払いたくないストリーミング業者向け作った規格だから
444:名無しさん＠編集中
18/04/02 23:36:23.24 oPPos9Iy0.net
>>423
原文は示してあるし特に主観ってわけでもないんだけど、ややふざけすぎた感はあるので気を付けます。
445:名無しさん＠編集中
18/04/02 23:57:19.16 osbzaKkp0.net
>>426
気にすんな。全然OK。このくらい�
446:ｪむしろ好ましい 細かいことに突っ込んでくる神経質なやつは必ずいるものだからな
447:名無しさん＠編集中
18/04/03 00:25:03.29 72Pkn5C60.net
VP9で充分やん
448:名無しさん＠編集中
18/04/03 00:37:22.30 2F/e5DdnM.net
個人運用の範囲じゃライセンス問題の影響極小だし
コンテンツ提供側は金儲けに直結してる分ライセンス料取られるから必死だけどね
HEVCはコンテンツ当たりにのライセンスフィーはディスク1枚当たり$0.0225、データで1タイトル当たりなら更に半額で、ストリーム配信なら無料
ハードウェアもライセンスが一番高い4Kテレビで1台で$2以下、モバイル端末は$1しない
安価なセットトッブボックスで価格の～1.6%程度
大抵は対応プロファイルの範囲が限られるのでもっと安くなる
消費者の立場として、コンテンツの消費に掛かる額は数円とか、再生機器でも4Kテレビや高価な機器でも2百数十円で、消費意欲を左右するレベルじゃ無い
代理店や問屋の流通での中抜きの方が遙かに影響が大きい
扱い量が大きい事業者側はそれなりに纏まった額になるから、払わないで済むなら払いたくないから、単価の具体額示さず「ライセンスガー」と後押しを求める方向の風潮を作りたがる
事業者は最低$25000/年取られるが、$4000万/年の支払額上限もあるうえ
更に多くの場合は現地の源泉税の控除分が適応した分の実質支払いで済んでたりもする
449:名無しさん＠編集中
18/04/03 00:53:24.91 +IqN0nMh0.net
でも、そもそもパテントのことをぎゃーぎゃいうなら最初からvp9でよくね?仕切り直して新しいコーデック作りゃなんとかなると思ってんのか。googleは孤軍奮闘で今まで頑張ってたが。他の配信企業なんなんよ。
450:名無しさん＠編集中
18/04/03 01:22:44.42 vkTvpMzh0.net
VP9は悪くはないが4K8K時代に使うには圧縮効率が物足りないし、
Googleが孤軍奮闘してるだけじゃ普及も進まないからアライアンス組んで新規開発したんだと思うけど。
451:名無しさん＠編集中
18/04/03 01:32:14.06 gUqfHQrn0.net
4K8K放送のcodecって決まってるんだっけ？
今年12月だからあと8ヶ月か
452:名無しさん＠編集中
18/04/03 03:44:39.98 Ausww4X10.net
>>432
放送ならHEVCに決まってる
453:名無しさん＠編集中
18/04/03 03:46:14.32 ryppP+Nj0.net
あと8ヶ月で決まってないとかありえないだろｗ
454:名無しさん＠編集中
18/04/03 06:19:37.35 D/KfabLY0.net
Software Infrastructure Global Viewpoint – March 2018
Assessing HEVC Versus AV1: Round 1
URLﾘﾝｸ(www.thebroadcastbridge.com)
455:名無しさん＠編集中
18/04/03 09:03:12.78 L7yuzpKm0.net
Netflixとかはやっぱオリジナルコンテンツだけでも全部4kで配信したい！って考えてるんじゃないかな、そうなるとVP9やHEVCでは足りないのかもね。日本の平均ネット速度は17Mbpsらしいけど世界平均は6Mbpsらしいし
456:名無しさん＠編集中
18/04/03 09:19:42.50 j00SyjWW0.net
>>430
ネットを主軸に活動してる主要企業が集まることのほうが重要なんでは
457:名無しさん＠編集中
18/04/03 09:26:18.94 WshddpOhM.net
放送波のTSを4:2:0の無圧縮720p化したものをソースにして、AV1のサンプルエンコーダ（自前ビルド）とx265
458:比較してみたが 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が変態過ぎるんだな
459:名無しさん＠編集中
18/04/03 09:52:27.94 WshddpOhM.net
まぁそれでもUltraFast～FastプリセットよりSSIMが上にはなってることは確かだから、素のHEVCだけよりは高画質なのは確かなんだろうけどね
x265相手でコレなら、x264にすらオプション巧く使われたら追いつかれるかもしれない
OpenSourceのプロジェクト化されて、x264やx265の開発やってる連中がソフトエンコーダ開発に参画してくれば化けるかもだけど、x265でも手が回ってない部分も有るし難しいかなぁ
460:名無しさん＠編集中
18/04/03 11:01:39.67 hboypAjzM.net
>>437
ネット主軸の事業者は、貧乏なところが多いし、事業自体が短命に終わっているケースが多いから、数を集めることに意味はない
461:名無しさん＠編集中
18/04/03 12:25:45.97 j00SyjWW0.net
>>440
Google, NetFlix, Amazonが貧乏で短命とな
462:名無しさん＠編集中
18/04/03 13:15:40.31 uy28RzoC0.net
日本語の読解力なんとかしなよ…
463:名無しさん＠編集中
18/04/03 13:43:01.90 RUFJesKM0.net
主要の2文字を見ていないとすれば話は通る
464:名無しさん＠編集中
18/04/03 14:00:17.99 5gh3/G+j0.net
まあ意味の取り違えとかには気を付けるとして．．．
H.265/HEVC特許暗黒時代 - Qiita
URLﾘﾝｸ(qiita.com)
Twitterによると、FAQとかが更新されたそうだ。
・・・そして３月頭にTechnicolorがInterDigitalっていうパテントトロールっぽいところに
特許を売り飛ばしたそうで、HEVCの特許問題の状況は更に悪化したそうだ・・・。
Technicolor Agrees to Sell to InterDigital its Patent Licensing Business | Technicolor
URLﾘﾝｸ(www.technicolor.com)
【トロール動向ウォッチ】 トップ11社提訴件数推移｜知財情報｜日本技術貿易株式会社
URLﾘﾝｸ(www.ngb.co.jp)
開発企業が特許で利益を得ようとするのは当然のことで仕方ないとは思うんだけど、なんともなあ・・・。