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)
開発企業が特許で利益を得ようとするのは当然のことで仕方ないとは思うんだけど、なんともなあ・・・。
465:名無しさん＠編集中
18/04/03 14:26:17.23 wCoYoMR7d.net
売って開発企業が利益を上げたところでトロールだけ制裁加えれば問題無い
466:名無しさん＠編集中
18/04/03 18:43:38.38 mSfnhtwEM.net
トロールなんかに金払う必要ないわ
とっくに消尽されてる特許に値札なんかつかない
467:名無しさん＠編集中
18/04/03 20:37:18.45 OgIkUsW5M.net
パテントの一次受けが決まっているんだから、それを飛び越してライセンシーに請求しても、HEVC Advanceと契約してパテント料支払っているんだから、HEVC Advanceに請求しろとなる
トロールの連中が勝手に関連特許のライセンス�
468:変えても、それを監視して対応するのはHEVC Advanceだからな ライセンサーのHEVC Advanceには請求通るかもだが、関連特許保有者がHEVCライセンシーへの直接請求を通すのは難しい
469:名無しさん＠編集中
18/04/03 20:53:07.75 g84DrQPB0.net
>>438
激遅な上に画質も大したことない
完全な死に規格だな…
470:名無しさん＠編集中
18/04/03 21:09:08.35 GqRPacca0.net
早漏かよ
471:名無しさん＠編集中
18/04/04 13:55:49.56 axCfnGfR00404.net
HEVC Advance、更に新規ライセンサー、ライセンシーを加え、その推進力を強調
URLﾘﾝｸ(kyodonewsprwire.jp)
一部抜粋
> 独立系ライセンス アドミニストレータであるHEVC Advanceは、増大するライセンサー及びライセンシーリストに
> さらに新規企業が加わったことを発表した。AcTi、EverFocus Electronics、Fraunhofer、GoPro、日立工機、
> Humax、KAIST、Korean Aerospace University、Korean Broadcast System、TechniSat、
> Telestar及びWestern Digital社が含まれている。この発表は、HEVC Advanceの最近の決定である、
> インターネットストリーミング、ケーブル、無線通信放送や衛星を介した、非物理的HEVCコンテンツ配信に対して
> ライセンス及び実施料の徴取を行わないという同社の決定に対する市場からの好意的な反応の中行われた。
472:名無しさん＠編集中
18/04/04 18:38:12.46 y23XsAPx00404.net
え？ HEVC>VP9だろ？
世代的にもVP9の方が一つ遅いって認識なんだが…
VP9→HEVC→AV1なのでは…
473:名無しさん＠編集中
18/04/04 20:49:00.02 GGoNjvcpM0404.net
早い遅いはコードの差も有るから、コーデック自体の比較では何とも言えないでは？
画質容量比的なものなら、H264＜VP9≦HEVC≦AV1 ぐらいで、あとはエンコーダ実装次第で前後するだろうけど
474:名無しさん＠編集中
18/04/05 00:36:47.46 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
URLﾘﾝｸ(2sen.dip.jp)
●自ビルドしたffmpegでエンコードした場合 （現時点では-tile-columns指定不可）
エンコーダ： ffmpeg x64 20180403-N-90590-g197a4e8fee (libaom 0.1.0-9028-geeda6d2de)
結果： 0.0029～0.0597fps
URLﾘﾝｸ(2sen.dip.jp)
●Zeranoe ffmpegでエンコードした場合 （現時点では-tile-columns指定不可）
エンコーダ： ffmpeg x64 20180402-N-90578-g02ae52db87 (libaom 0.1.0-9012-ge83c6624f)
結果： 0.0004～0.0275fps
URLﾘﾝｸ(2sen.dip.jp)
475:名無しさん＠編集中
18/04/05 00:39:31.08 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
URLﾘﾝｸ(github.com)
実行して質問に答えるだけでMSYS2/MINGW-w64/GCCのビルド環境を構築して、
最新のffmpeg/aomenc/x264/x265などを自動ビルドしてくれるのでありがたい。
L-SMASH（-Works）の自ビルドにも流用できる。
476:名無しさん＠編集中
18/04/05 01:56:11.81 VVbezlj2M.net
再度の検証お疲れ様
気になる点
何で一般的なGOP長に満たないフレーム数を使用しているのか
一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
あと、SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
477:名無しさん＠編集中
18/04/05 02:52:00.40 E/6Z4gwq0.net
>>455
> 何で一般的なGOP長に満たないフレーム数を使用しているのか。
> 一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
そうなんだけど、見てわかるとおり、今のAV1エンコードは死ぬほど時間がかかるから。
とりあえずFHDのエンコード時間の目安を知りたかったというのが今回の一番の目的。
VMAFやSSIM等はついでに測っただけ。
次は長めのサンプルも試したいが・・・時間かかるのを覚悟でFHDに挑むべきか、妥協して解像度を下げるべきか・・・。
> SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
x264やx265の--ssimで出力されるのが SSIM Mean Y なのでなんとなく。Allを拾った方がいいかな？
478:名無しさん＠編集中
18/04/05 03:59:11.36 sX2SJznGM.net
>>456
ffmpegでSSIM拾うとか
479:名無しさん＠編集中
18/04/05 15:58:43.97 ACap5gLC0.net
適当なスレというか板がないのでお知らせ程度に
・ロスレス圧縮技術MPEG-4ALSを用いたコンサートホール演奏の
ハイレゾライブ配信サービス商用化に向けた説明会について
URLﾘﾝｸ(ottava.jp)
HEVCと同じく次世代放送にて採用決定済みのMPEG-4 ALSを使ったライブ配信に関する話題
480:名無しさん＠編集中
18/04/05 16:37:44.71 QNV9ilhrM.net
場所が無いにしても、不可逆それも画質容量比と効率が主題の次世代ビデオコーデックのスレでも板違い
情報提供で投下スレ無いならニュース行きか、ピュアAUかAV機器で捨てスレ起こせ
481:名無しさん＠編集中
18/04/05 16:57:34.66 9t7ueEo80.net
ハイフレームレート4Kライブ伝送を実現するHEVCコーデック。NTTが開発
URLﾘﾝｸ(av.watch.impress.co.jp)
>>457
ffmpegでやってるよ。
>>453補足
aomenc.exeの設定はffmpegとあわせたつもりだったんだけど、aomenc.exeで--tile-colunmnsを外してみたら
自ビルドffmpegの1.5倍くらいの時間がかかったので、何か見逃してる設定があるのかもしれない。
482:名無しさん＠編集中
18/04/06 00:35:49.06 By9McdF70.net
URLﾘﾝｸ(developer.nvidia.com)
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)
483:名無しさん＠編集中
18/04/06 02:50:12.05 FCIj/N0QM.net
>>461 ビデオコーデックSDK 8.1の新機能 完全に再設計されたモジュール式サンプルアプリケーションにより、対象アプリケーションへの実装が容易になりました H.264のエンコード品質を全体的に向上させる新機能として、Bフレームを参照フレームとして使用できる様になりました （効果としてフレームの差分データ量がより節約出来るので、画質容量比が向上すると思われる） 推奨ドライバでリアルタイムHEVC 4K@60fpsのサポートが追加されました アプリケーションから、先行取得されたビデオフレームにおいてマクロブロックに品質指定を行う新しいAPIを実装しました この機能はイメージ領域の分類機能（Capture SDK 7.0の一部）と連携して使用出来ます （マクロブロック単位の可変品質エンコードを可能にする実装っぽい、手間が増えるがCBRやVBR、固定品質で画質容量比の改善が望める）
485:名無しさん＠編集中
18/04/06 02:57:02.11 +HIdoxMtM.net
最後については、手法的には前からある（x264とかには既に有る）実装
AV1対応の過程でAV1の標準エンコーダに有る機能で既存コーデックに使える機能は、出来た分は先に出したよ感がｗ
486:名無しさん＠編集中
18/04/06 03:08:35.18 f7T0X8b4M.net
Bフレームの参照の方は、Bフレームが続く場合にPフレームからの差分では無くBフレームからの差分参照出来る様になるんで、動きが少ないとか、ブロック単位でズレるだけみたいな場面でより縮む様になる
Bフレーム使う話なんで、Bフレームが使えないNVEncのHEVCには関係無し（ぉ
487:名無しさん＠編集中
18/04/06 10:05:41.45 cVa47tLH0.net
このSDKを使うのはNLEやエンコーダ各社？
NVEncはBフレーム使えないのは、このSDK過去版が使えなかったからではなくて？
>>464
488:名無しさん＠編集中
18/04/06 10:56:17.84 F4bKu/VH0.net
>>465
NVEncではH264なら元からBフレームも使えていて
HEVCだとマクロブロック捜査の方に手間食われて低レイテンシ維持出来ないから、HEVC対応したNVEnc積んだGefoce出た時からずっとBフレーム無しで、それが仕様とされてきてる（それでも当社比でH264より縮むんだけどね）
NVEncのHEVCでBフレームも有効になっていたら、SDKとしてデカいトピックすぎて書かない訳がないぐらいのネタだし、関連設定に関わる資料が追加されてるはず
489:名無しさん＠編集中
18/04/06 11:50:55.91 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フレーム対応も予定されてたみたいだけどどうなったんだろね。
URLﾘﾝｸ(nico-lab.net)
490:名無しさん＠編集中
18/04/06 11:58:40.99 0hBfnBa7M.net
要するにハードウェア的にはBフレームに対応してるんだけど、それを動かすソフトウェアの開発部隊がカスしかいなかったんだろ
で、やっとまともに扱える奴が入ってきたから、まずH.264で使えるようにしたと
この流れならばいず
491:れHEVCもやるでしょ あとは画質次第 いくらオプション対応しても画質が伴わなければ意味はないから もっとも、NVIDIAを語れるような目利きがいた試しはないが
492:名無しさん＠編集中
18/04/06 12:00:24.43 0hBfnBa7M.net
最後、「NVIDIAに画質を語れるような目利きがいた試しはないが」に訂正
493:名無しさん＠編集中
18/04/06 12:08:20.30 hl9eRboSM.net
>>466
勉強になった、ありがとう
494:名無しさん＠編集中
18/04/06 12:10:20.58 YeX5u0A00.net
>>468
>>466も言ってるけど、NVEncではH.264なら元からBフレーム自体は使えていたよ。
HEVCの場合だけ「最大Bフレーム数はゼロだよー」と返してくるので使えなかったというだけのはず。
今回のSDK8.1での変更は、「（H.264で）Bフレームを参照フレームとして扱えるようになった」というもの。
H.264ではBフレームは元から使えてたけど、更に機能追加したよという話。
495:名無しさん＠編集中
18/04/06 12:13:53.13 lHWnPzdj0.net
>>464
Bフレームを参照フレームとしてというのはいわゆるb-pyramidのことでは
>>467
（下段について）
たぶんASICとかの作りこみを省いてるんだと思う
機能的には充実してるAMDより断然早かったし
h.264対応済みハードをできる限りいじらずに実装したのが今のNVEncだと思う
496:名無しさん＠編集中
18/04/06 12:55:24.08 YeX5u0A00.net
>>472
> 機能的には充実してるAMD
AMDのVCEEnc(AMF)は
・HEVC main10に非対応 (QSVとNVEncは対応済み)
・Polarisでは何故かH.264でもBフレームが使えなくなった
・QSVスレで行ったSSIM/ビットレート図による比較では最下位
ｽﾚﾘﾝｸ(avi板:335番)
と、一番酷い状態のような・・・。
>>122で書いたようにVP9のHWデコードも迷走してたし、大丈夫なんだろうかって感じがする。
RavenRidgeはちゃんとVP9のDXVAデコードができるらしいけど。
497:名無しさん＠編集中
18/04/06 12:56:37.93 0hBfnBa7M.net
>>471
だからそれ、ソフトウェア開発部隊が使えるはずの機能を使えない状態にして放置してたからだろ
結局、カスであったことに変わりはない
498:名無しさん＠編集中
18/04/06 13:00:24.52 YeX5u0A00.net
>>474
勘違いしてたっぽいから指摘しただけ。
499:名無しさん＠編集中
18/04/06 13:19:52.27 0hBfnBa7M.net
おまえがな
500:名無しさん＠編集中
18/04/06 14:56:30.70 lHWnPzdj0.net
>>473
だから「機能的には」って「には」を付けたんだな
501:名無しさん＠編集中
18/04/06 15:11:30.34 YeX5u0A00.net
>>477
なるほど。（ただ、エンコード機能的に何か充実してるんだっけ？という素朴な疑問はある。エンコード以外の機能込み？）
502:名無しさん＠編集中
18/04/06 16:17:19.62 lHWnPzdj0.net
>>478
2Pass（おそらく先読み）によるレート制御とかBフレーム使える（Polarisでは無効化されてる？）とか機能的には充実してると言ってもいいのでは
それらを実装してるから高画質とは限らないだけで・・
ま、EU（GPUコア）使って柔軟に進化してるQSVは別格として
nvidia、AMDともにゲームの配信とかゲーム画面のキャプチャ向けの高ビットレート録画って割り切ってる感はある
503:名無しさん＠編集中
18/04/07 12:04:04.25 ZS0HPDpc0.net
ｽﾚﾘﾝｸ(software板:568番)-571
Zeranoe版ffmpegでlibaomのビルドミスがあったので、
AV1の検証をするなら20180405-e54679b以降のバージョンか、自ビルドのffmpegやaomenc.exeで。
libaomの方も頻繁に更新されてて、原因はよくわからないけど同じ設定で前より遅くなったりもしてる。
aom 0.1.0-9082-gab1e1db19のaomenc.exeでクラッシュするケースもあったし、安定するのはまだまだ先かな。
504:名無しさん＠編集中
18/04/10 13:29:00.05 mvAZrsZe0.net
xiphmont | next generation video: Introducing AV1, part1: Chroma from Luma
505: https://xiphmont.dreamwidth.org/91643.html next generation video: Introducing AV1 https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml
506:名無しさん＠編集中
18/04/11 16:49:17.77 VM1ZiLn00.net
facebookの人（？）によるAV1、x264、libvpx-vp9の比較
AV1 beats x264 and libvpx-vp9 in practical use case
URLﾘﾝｸ(code.facebook.com)
507:名無しさん＠編集中
18/04/11 16:56:10.44 7cYhFyubM.net
>>482
画質は上々そうやね
x264のデフォルトの1万倍近く遅いみたいに見えるけど。
英語はよく分からないので100倍であって欲しい。
508:名無しさん＠編集中
18/04/11 17:53:39.39 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エンコードしてる人ってほぼいないだろうからわかりにくいけど・・・。
509:名無しさん＠編集中
18/04/11 18:01:26.52 7cYhFyubM.net
>>484
veryslowと比較してなのか…スレッド数で1桁速度が変わったとして現状x264 midiumとの比較で2000倍程度速度差があるという認識でいいのかな
x264やx265は発表から数年で速度はもとより画質も素晴らしく伸びたように思うので少なくとも今年の終わりまで気絶してから評価した方が良さそうですね
510:名無しさん＠編集中
18/04/11 18:10:29.71 OUJRzihv0.net
AOMのソースのところに書いてあるのと同じサンプルだね
URLﾘﾝｸ(media.xiph.org)
解像度は各種あるけど、ニュース番組並に情報量低いのばっかりで、マクロブロックサイズのサイズデカいコーデックがそりゃ縮むわなという感じのばっかりなんだよな
x265との比較しないのが謎だし、AOMの中の人なんじゃないかと思ってしまう
511:名無しさん＠編集中
18/04/11 19:07:34.65 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みたいだけど、何を表してるんだろ。
512:名無しさん＠編集中
18/04/11 19:40:14.73 jzIik2pxM.net
8000倍とかw
513:名無しさん＠編集中
18/04/11 21:53:41.24 oBNaTspA0.net
エンコードにH.264の10000倍かかったとしてもエンコした動画を1回しか見ないような俺らに対して
1回エンコするだけで100万再生スタートという次元の配信業者からすれば
俺らより環境にもネットの帯域にも優しい�
514:ｨ釣りが出るほどのリターンがあるということ
515:名無しさん＠編集中
18/04/12 09:11:54.62 q5iqQV/z0.net
>>489
意味が分からない。10000倍では釣り合いが取れないだろ
ネット帯域が主要命題だったのは10年～20年前だし
516:名無しさん＠編集中
18/04/12 10:13:17.37 VfB7DrWl0.net
x264やx265みたいな魔改造エンコーダがまだ無いからな
対応ハード出るまで1年有るし、配信事業者側が使い始めるのも2年は先だろう
nvidiaがNVEncとCUDAの連携追加し始めていてAV1にも使えそうな実装をSDKでして来てるし
AV1の方がHEVCより物量的処理での圧縮してるから、NVEnc+CUDAの実装で何かしら出してくるかもな
有る程度纏まった形にしてるのはDGX-2みたいなTeslaを使ったコンポーネントとセットで事業者用
GeforceとかはNVEncのみでは最小限で、あとはSDK使って手前らで巧く纏めなさいよとかだろうなぁ
517:名無しさん＠編集中
18/04/12 10:45:25.96 WANQhGIfM.net
NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような画質水準には達していない）しか作れないみたいだから、アテにならんと思うがねぇ
518:名無しさん＠編集中
18/04/12 12:08:55.54 L/MKuORZM.net
NETFLIXなど大手の配信業者も多く絡んでるし可能な限りハードウェア処理し易い設計になってる可能性はまたあるとは思う
519:名無しさん＠編集中
18/04/12 12:54:15.28 VfB7DrWl0.net
>>492
リアルタイム配信向けの実装なだけでしょ
短時間に出来る範囲でしかやっていない
同様の事をQSVでやらせると、H264でしか出来ないうえ、NVEncのH264より汚いって知ってた？
520:名無しさん＠編集中
18/04/12 13:09:36.05 SxbRi3C8M.net
>>494
そんな話していないし、したいとも思わん
521:名無しさん＠編集中
18/04/12 13:20:02.82 VfB7DrWl0.net
NVEnc自体は、nvidiaのGRIDみたいなクラウドや、LAN内でのゲームのリモート操作のためのもので
それ自体はH264なりHEVCだから、GPUのバッファから生成する以外にも、デコーダからGPUに映像与えてやれば、任意の映像データもトランスコードしてファイルとして保存できるってだけ
ただ要望もあるから、あとからSDK7.x世代以降にCUDA使ってGPGPU的に拡張出来る様になってる
もちろんSDKでのAPI実装やサンプルに頼らず独自でやっても良いんだけど
CUDAエンコーダの頃から独自に拡張する人が殆ど現れない
エンコーダの拡張自体が糞難易度高くて、数学者的な人が実装サンプルや設計組んで、コーディングに特化した連中が最適化を進めるパターンが多い
そういう方々は既にx264やx265の方に集中しちまってる
522:名無しさん＠編集中
18/04/12 14:05:52.16 ZcyNWyhH0.net
>>489
趣旨はともかく、さすがに10000倍のままってことはないでしょｗ
>>490
>ネット帯域が主要命題だったのは10年～20年前だし
そんなことないよ。流れるデータ量も激増してるし、世界にはまだまだ帯域不足のところもあるし、
配信業者にとってデータ量の削減は今も昔も極めて重要な課題。
523:名無しさん＠編集中
18/04/12 14:19:48.64 ZcyNWyhH0.net
>>492
> NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような
> 画質水準には達していない）しか作れないみたいだから
それを言うなら
・GPUのHWエンコーダはどれも高圧縮/高画質を求める人には向いていない（特に実写等）
・QSVとNVEncは圧縮/画質面では同程度(QSVの方がやや上？)。
エンコード速度はNVEncが圧倒。
・AMFはQSVやNVEncと比較すると一段下のレベル。
AMDのエンコード/デコード機能の出遅れはちょっと心配になるレベルでもある・・・。
という感じだと思うけどな。（根拠は>>473
524:とか） IntelもNVIDIAもAOMのFounding Memberだし、それなりに期待はできると思う。 AMDはPromotor Memberだけど、エンコード/デコード部門は頑張れるのだろうか・・・。
525:名無しさん＠編集中
18/04/12 15:01:48.50 O/DjZzsid.net
画質重視でもYoutubeに上げる為にロスレスで圧縮するときはNVEnc使ってる
526:名無しさん＠編集中
18/04/12 15:19:04.50 ZcyNWyhH0.net
NVEncのロスレスって4:4:4だと聞いたけど、Youtubeはそれも受け付けてくれるのか。
なんとなく弾かれるもんだと思ってた。
527:名無しさん＠編集中
18/04/12 15:34:47.41 n+ScPlN90.net
そういえばx265のCUSA版があったな
URLﾘﾝｸ(bitbucket.org)
長いこと更新されてないみたいだから
非主流アーキテクチャ向けの設計は広がらないみたいね
528:名無しさん＠編集中
18/04/12 15:52:32.56 ZcyNWyhH0.net
H.265の v5 (Approved in 2018-02-13) の規格書が発行された。
現時点ではダウンロードできるのはTIES userのみ。
H.265?:?High efficiency video coding
URLﾘﾝｸ(www.itu.int)
529:名無しさん＠編集中
18/04/12 16:24:41.39 PMHfI71Jd.net
詳しくは知らないというか知る由もないんだけど、NetflixとかYoutube（Google）みたいな資本力のあるところでもHWエンコしてるのか？ああいうところって一般人じゃ到底手に入らないようなスペックのコンピューターでSWエンコしてると思ってたんだが
530:名無しさん＠編集中
18/04/12 19:00:41.89 VfB7DrWl0.net
>>501
全てがGPGPUでCPUより効率良く処理出来る訳じゃない
x264やx265が高画質化するため手法の極一部だけなんで
大半を処理するCPUが結局ボトルネックになる
それでも僅かにCPUの負担が減るから、その分は微妙に早くはなるけど何割も早くはならない