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の負担が減るから、その分は微妙に早くはなるけど何割も早くはならない
531:名無しさん＠編集中
18/04/12 22:23:26.00 pGR5LOdp0.net
>>503
ああいう規模だからこそ逆に専用のASICボードとか用意してガリガリやるんじゃねーの？
532:名無しさん＠編集中
18/04/13 00:01:29.18 ciNufoQ0a.net
お前ら何学部卒？
533:名無しさん＠編集中
18/04/13 03:54:06.59 d42zSzX20.net
人に聞くなら自分から
534:名無しさん＠編集中
18/04/13 04:26:47.71 5+mGH86Kd.net
医学部
だからGPGPUとかチンプンカンプン
535:名無しさん＠編集中
18/04/13 09:43:04.68 Iy839CtQ0.net
>>503
SWでの高画質エンコードがされるなら
○○向け高画質エンコード（配信サイトで再エンコードされない）設定なんてのに意味がないから
ASICもしくはx264 --tune very fastレベルの高速SWエンコだと思う
536:名無しさん＠編集中
18/04/13 11:45:08.54 +CW60tiR0.net
>>509
> ○○向け高画質エンコード（配信サイトで再エンコードされない）設定
これが何のことを指してるのかよくわからない。Youtubeでそんなことできるんだっけ？
あとつっこんでおくと --preset veryfastじゃね。
537:名無しさん＠編集中
18/04/13 12:18:13.13 Sg2lKLiA0.net
GoogleのサービスでH.264トランスコードはx264だっけか
538:名無しさん＠編集中
18/04/13 12:38:58.40 6eRFP0ta0.net
配信サイトで再エンコードされない設定って言うのはよく聞く誤解だね
YouTubeだとどんな動画を上げても再エンコードされる
アップロードしたあと手元の動画とSSIMなりで比較してみたら分かる
539:名無しさん＠編集中
18/04/13 13:23:15.76 Sg2lKLiA0.net
昔の実装そのまま今でも一緒だと思っていたり
ニコニコの体の良いシステム負荷軽減手法と同じだと思っているんじゃないかな
540:名無しさん＠編集中
18/04/13 17:18:55.93 Iy839CtQ0.net
そりゃyoutubeへのアップロードに関する話題とか昔の流行だもの
541:名無しさん＠編集中
18/04/13 18:12:08.90 qCymtqNK0.net
よくわからんがYoutubeで再エンコードされないようにする設定があると勘違いしてたってことか。
542:名無しさん＠編集中
18/04/14 14:03:51.15 89UFyH020.net
16Kまだ？
543:名無しさん＠編集中
18/04/14 15:38:58.48 JUsY
544:ulE3d.net
545:名無しさん＠編集中
18/04/14 16:34:42.61 yQp2n2100.net
>>517
基本ではないでしょ。可逆はサイズもでかくなって面倒だし、
「可逆で上げた場合」と「十分高画質な非可逆で上げた場合」とで
生成された動画に目立った違いは出ないと思うし、後者で上げる人がほとんどだと思うよ。
546:名無しさん＠編集中
18/04/14 16:48:12.43 W4h1IMs60.net
自分はx264 crf12ぐらいで上げてるな 16と程度と比較するどちらが綺麗かは分かるレベルだったし意味なくは無いと思う。
生成後の動画比較すると画質毎に設定やビットレート多少違うかもね
547:名無しさん＠編集中
18/04/14 17:48:50.77 EMVmu1/I0.net
低いcrfほどエンコーダの差が画質に出てこなくなるから、QSVやNVEncでササッと処理済ませてアップロードし始めた方が手早いかも
放置で下準備させておく時間があるならx264だけど
548:名無しさん＠編集中
18/04/14 20:01:48.20 yQp2n2100.net
1080pの335フレームでAV1をテストしてみた。
ソースは進撃の巨人１期OPのサビの立体機動シーン～大砲発射まで。
結果： URLﾘﾝｸ(2sen.dip.jp)
--cpu-used 3 でx265のveryslowと同程度の品質で、かかる時間は17倍。
--cpu-used 2 だとそれ以上の品質で、かかる時間は100倍。
--cpu-used 1 だと更にそれ以上の品質で、かかる時間は170倍。
(ただしどれも--tile-columns未使用。使えばこの半分くらいにはなるかも。)
--cpu-used 1 だと、x264 veryslowで7Mbps、
x265veryslowで5Mbpsくらいかかるのを、4Mbps弱にするくらいの圧縮効率。
VMAF/SSIMに基づいた評価としてはこんな感じになった。
549:名無しさん＠編集中
18/04/14 20:14:36.49 NsXr+PVe0.net
>>521
乙乙
参考になる
550:名無しさん＠編集中
18/04/14 22:12:23.37 +/qR7O9Z0.net
>>521
これを維持してどんだけ高速化できるかだなぁ
551:名無しさん＠編集中
18/04/14 23:21:16.52 5o34rogK0.net
実用になる時間じゃないね
552:名無しさん＠編集中
18/04/15 02:31:59.29 3zo9kCKG0.net
libaomはリファレンスみたいなもんだし、まだ最適化もされてないから
今のlibaomのエンコード速度/時間を見てAV1の実用度を判断してはダメだよ。
libaom自体はどこまで最適化されてどれくらい速くできるのかわからんけど、
商用ではベンダーが開発したエンコーダ(SW/HW)が使われるんだろうし。
ちなみに>>521のサンプルでは-cpu-used 3 -crf20で335フレームのエンコードが約3時間4分だったけど、
crowd_run(1920x1080、500frames)は同じ設定で6時間30分かけて100フレームしか進まなかったので中止した・・・。
553:名無しさん＠編集中
18/04/15 21:39:15.37 wDrk/oMp0.net
very slowの17倍って今の段階なら悪く無いじゃんって思ったけどx264ならmidiumの数倍程度だけどx265だと凄いんやね
554:名無しさん＠編集中
18/04/17 08:58:23.81 G8gaxn+mM.net
話題が無いので間潰しにNVEncネタ
NVEncでの同時エンコードは基本的に2つまでと言われているが、実はQuadro 2000番以上とTeslaは制限が無い
あとNVEncエンジンの搭載数にも違いがあり
GK世代、GM107やGM206、GP107～106 は1基
GM204～GM200、GP104～102 は2基、GP100やGV100は3基搭載されていて
搭載エンジン数分までは同時処理をしても処理速度が殆ど落ちない様になっている
例外的なのがGTXGTX1070で、GP104自体は2基搭載だがエンジンが1つ無効化されている
GTX1070TiについてはGTX1080と同じく2基とも有効
なので同じ世代ならNVEnc自体の処理性能自体に大差は無いけど、
エンジンの搭載数によって同時処理（多くの場合は2ウェイ処理）時
555:の処理速度低下具合が変わってくる
556:名無しさん＠編集中
18/04/17 09:06:44.92 7Ja6+jKC0.net
それ知ってたら1080買ってたわ
557:名無しさん＠編集中
18/04/17 09:25:46.28 G8gaxn+mM.net
NVEncの処理速度的については、固定量子化でブン回す場合には、FHDでの出力ならピーク値でH264で600～650fps、HEVCで400fps前後ぐらい（NVEncのHEVCはBフレーム省略仕様なので速度低下が少ない）
NVDecのデコードはFHDで600～650fpsぐらいがピーク値になる
あと実行環境（NVEncを呼び出すアプリ）によってピーク値近くで動作させられるかが変わってくるので留意
例えばTVMW6だと、エンコードの前段がボトルネックで2つ同時のバッチエンコにしないとエンジンを回しきれない
お陰でエンジン2基環境の場合はどちらも回し切ることが出来ない
558:名無しさん＠編集中
18/04/17 09:50:40.44 UuaDiTHp0.net
はぁ、1080並の値段でELSAの1070なんてかわなければよかったｗ
559:名無しさん＠編集中
18/04/17 10:28:31.86 G8gaxn+mM.net
捕捉
上の速度はPascal世代の速度で、1つ前のMaxwell第2世代だとH264なら2/3、HEVCなら1/2ぐらいの性能になる
Pascal世代でのNVEncのトピックは、HEVC速度低下が少なくなっている事なんだけど、公式なトピックに記述は無いけど、Pascalで動作クロック自体が大きく向上しているので、結果的にH264も含めた全体的なパフォーマンスも相当上がってる
Pascal世代のHEVCについては、性能低下緩和も含めてマクロブロックの捜査ロジックの改善もされている様で、Maxwell第2世代のHEVCより地味に画質が向上されている
NVEncの速度はデフォルトの動作クロックに依存（ツールによるソフトウェアでのOCはCUDAコア側のクロックが上がる仕様）なので、NVEnc目的でグラボ購入する場合には、製品の公称クロック基準で購入した方が良い
ファームウェア操作ツールでクロック上げた場合はそのまま性能に反映される
560:名無しさん＠編集中
18/04/17 11:01:56.07 G8gaxn+mM.net
NVEncの性能で考えれば、リファレンスクロックが高く、エンジン2基のGTX1080が最良
次点で僅かにクロックが低いGTX1070Ti
GTX1070はリファレンスクロックはGTX1070Tiと同じだけど前記の通りエンジン1基なので、NVEnc狙いではお勧め出来ない
GTX1080Tiはエンジン2基だけど、動作クロックがGTX1050並なのでEVEncの性能は落ちるし単価が高い
エンジンの単価で考えれば、GTX1050無印が安価
CUDAコア数が少ない分、GTX1050Tiよりクロックで性能稼いでいるので、
動作クロックも高めになっているが、クロックは1つ上のGTX1060より1割落ちる
高いクロックでエンジンを含むGPUコア部（否CUDAコア）を回せるかは、TSMC16nmFF製造かSAMSUNG14nmFF製造（16nmより回らない）か、グラボの電源部の影響が大きい
（それでもGTX1050をファーム改造でGTX1080のリファレンス並ぐらい回す事は不可能じゃ無い
561:名無しさん＠編集中
18/04/17 11:41:12.03 ipT4+ZwS0.net
GK208はNVEnc乗ってるのにGP108がなぁ
562:名無しさん＠編集中
18/04/17 13:13:22.45 l5bingFq0.net
こういうGeForceの型番ごとにおける機能の制限/無効化ってどこかにドキュメントとしてまとまってるの？
QuadroとTeslaはHTML上に一覧表が出来てるけど
563:名無しさん＠編集中
18/04/17 13:37:31.07 G8gaxn+mM.net
nvidiaのdeveloperにあるみたいな一覧は無いね
海外フォーラムでは日本よりNVEncについて掘り下げてスレが意外にあって
エンジン数についても話題に上がる
GTX1070Tiなんかも、リリース後エンジン数についてスレ立ってた
対応SDKから実機確認すれば解るんで、同時処理数も同様やね
564:名無しさん＠編集中
18/04/17 13:38:28.10 7Ja6+jKC0.net
そういう情報出さないで売ってるの、なんだかなって思うわ
565:名無しさん＠編集中
18/04/17 14:03:08.33 tPz+M+Wh0.net
NVIDIAにとっては、エンコーダーの価値はその程度にしか見ていないということ
566:名無しさん＠編集中
18/04/17 15:04:10.48
567:g34xNThwa.net
568:名無しさん＠編集中
18/04/17 15:07:05.87 Ev+v4bJ00.net
なんでAMDは動画最弱になっちゃったんだろ
動画ならRadeonなんて時代もあったのにね
569:名無しさん＠編集中
18/04/17 15:11:14.83 GjWzJu8g0.net
というか、実用面からすると
・NVEncを保存用エンコードに使う人はあまりいない
・NVEncで並列エンコードをする人もあまりいない
・全体的に十分以上に高速なので、高速域での速度差を気にする人もあまりいない
ということで、一般ユーザー的にはエンジン数やエンコード速度の差を重要視する人は少ないのでは。
（「実際に使うわけじゃないけど最高の機能が載っててほしい」という気持ちはよくわかるけど）
570:名無しさん＠編集中
18/04/17 15:18:43.64 G8gaxn+mM.net
公表されてる範囲の機能的なスペックはエンジン1基有れば実現出来るからね
571:名無しさん＠編集中
18/04/17 15:37:01.40 G8gaxn+mM.net
NVDec/NVEncのSDKもnvidia的にはターゲットはTeslaやQuadroで、Geforceでも一応使えるという感じだからね
Geforceだからと全モデル1基とかにされなかっただけでも良かったとする鹿
GTX1070の1基のみ有効になってる事ネタにして、nvidiaに纏まった数の直訴なんかしたら、あの会社なら次世代からGeforceグレードは統一仕様として一律1基にしてとかやりかねんｗ
572:名無しさん＠編集中
18/04/17 15:44:43.10 ipT4+ZwS0.net
>>539
ip変換の質とエフェクトが充実してたって話でデコードエンジン自体はずっとnvidiaの一周遅れだよ
573:名無しさん＠編集中
18/04/17 15:51:52.91 m7y6f3bl0.net
Netflix: AV1 is our primary next-gen codec
URLﾘﾝｸ(www.csimagazine.com)
574:名無しさん＠編集中
18/04/17 16:11:49.90 YX1SzvXBM.net
アムドの寝言はVP9有効にして
公約果たしてからにしてほしいなw
575:名無しさん＠編集中
18/04/17 16:40:17.77 G8gaxn+mM.net
デコーダはVega世代で載ってなかったっけ？
576:名無しさん＠編集中
18/04/17 17:56:50.23 kpSfcMeTa.net
xiphがRustで作ってるav1のエンコーダって話題出てる？
リファレンスより速いって書いてあるけど
577:名無しさん＠編集中
18/04/17 19:02:38.88 G8gaxn+mM.net
これか
URLﾘﾝｸ(github.com)
国内で話題にしてる人は少なさそう、自分も今知ったわ
libaomのコードをベースに入れてるのかな？
他方の資料で
libaomのアセンブラ化で4倍は速くなる、多分100倍速く出来そうだけど、アルゴリズムの書き換えが膨大すぎるわい！
みたいな事書いてあった
578:名無しさん＠編集中
18/04/17 19:41:01.17 QtBc3OjV0.net
>>545 >>546
>>122でも書いたけどPolaris/VegaはVP9のDXVAデコードに対応していない。
当初は隠し機能として存在していたそうだが、それも後になって消された。
ただしDXVAとは別にOpenCLによる再生支援が利用できるMFTフィルタがあり、
ChromeやFirefoxはそれを使ってVP9再生支援を利用することができる、という状況らしい。
なおRavenRidgeはVP9のDXVAに対応している。
>>547-548
>>89で出てるね。限定的な実装みたいだし、試したことはない。
579:名無しさん＠編集中
18/04/17 19:59:42.94 AV9r83+30.net
ビルドして試そうかと思ったけどビルドできなくて放置してた
580:名無しさん＠編集中
18/04/17 21:09:13.49 aZh6iL+w0.net
これcじゃなくてrustなん？
時代はrustなのか？
581:名無しさん＠編集中
18/04/17 21:13:46.15 0c2uycJlM.net
RustもC言語の派生の一種と言えなくもない
582:名無しさん＠編集中
18/04/19 22:57:58.69 hZLV04Fua.net
Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね
583:名無しさん＠編集中
18/04/20 02:37:09.78 zIebTadQ0.net
Mozilla�
584:ﾌDaalaで使ってたから親和性は折り紙付きだろう
585:名無しさん＠編集中
18/04/20 04:41:34.60 3IIJGeeBM.net
吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
代わりに習得がえらい難しいらしいけど
使用者に最も愛されている言語とか言うけど
愛が無ければやってられない習得難易度の裏返しだったり
586:名無しさん＠編集中
18/04/20 05:30:27.07 HD+81Fzka.net
>>554
Daala作ってたのはXiphだけどな
Xiphは半分Mozillaみたいなものだけど
587:名無しさん＠編集中
18/04/20 07:18:32.61 N1qeHIsf0.net
Daala作ってたのは誰あぁぁぁぁ
588:名無しさん＠編集中
18/04/21 12:52:16.94 tM5w7H6r0.net
xiphってflac作ったところなんだな
知らなかったわ
589:名無しさん＠編集中
18/04/21 13:21:10.75 Qy2Pbsrq0.net
ハイレゾは全く無意味とバッサリ切ったのが爽快だった
590:名無しさん＠編集中
18/04/21 19:19:53.26 BSwSpyS80.net
ハイレゾは無意味じゃないから間違ってるな
591:名無しさん＠編集中
18/04/21 20:42:38.58 mCJYRNDS0.net
URLﾘﾝｸ(people.xiph.org)
592:名無しさん＠編集中
18/04/21 23:18:19.11 6E+waUvMa.net
いや無意味だから
593:名無しさん＠編集中
18/04/21 23:40:10.60 vIk2JOlP0.net
そういうのはピュアAU板ってのがあるからそっちで存分にやればいいと思うよ。
ハイレゾの良さを追求するスレ ★1
ｽﾚﾘﾝｸ(pav板)
594:名無しさん＠編集中
18/04/21 23:54:04.88 BSwSpyS80.net
耳に聴こえなくても脳に影響してるんだよ
聴覚が全てではない
595:名無しさん＠編集中
18/04/22 00:05:32.14 qoqXsoAZa.net
悪影響かな
596:名無しさん＠編集中
18/04/22 00:30:07.28 dppkcbl/0.net
音痴なんだろ
597:名無しさん＠編集中
18/04/22 12:34:11.98 OUHz0R6x0.net
違いが分かる人と分からない人が
居るだけの話なのに
実際に目の前で見ないと信じられないのが人間
598:名無しさん＠編集中
18/04/22 15:46:11.93 MAIw05DH0.net
その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
ちゃんとマスタリングしてる物がほとんどだから20khz以上が切れてようがそうで無いものより綺麗っていうのはあるね
599:名無しさん＠編集中
18/04/22 18:57:13.36 17JCXUuud.net
URLﾘﾝｸ(encrypted-tbn3.gstatic.com)
600:名無しさん＠編集中
18/04/22 20:19:04.53 NF+KmVz0a.net
精神論は他板でやれ
601:名無しさん＠編集中
18/04/22 20:27:09.28 Itj5Wijm0.net
(´・ω・`)
602:名無しさん＠編集中
18/04/22 20:33:15.85 eWH2rYSA0.net
(´・ω・`)
603:名無しさん＠編集中
18/04/23 16:17:13.95 BRPMKJ720.net
自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
なにこれつべのVP9の4K十分綺麗じゃん
なんでこのVP9ってのはH.264やHx265以上に流行らないの？ 俺が事情を理解できてないだけだが理由がわからない
しかもつべの4K VP9ってビットレートたかだが12Mbps程度でこの画質なんでしょ？
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
604:名無しさん＠編集中
18/04/23 16:36:36.95 sukaORLRM.net
ググレカス
605:名無しさん＠編集中
18/04/23 17:45:49.03 2g6F1r+U0.net
>>573
x265@フルHDなら1～3Mbpsでそれなりに見れる画質になるんだから
4ｋで12Mbpsってのは少ないわけじゃない
606:名無しさん＠編集中
18/04/23 19:12:20.92 hFr3woIv0.net
h264とVP9を比べるなよ
607:名無しさん＠編集中
18/04/23 20:07:51.31 fgZBGlO6M.net
比べてん�
608:ﾌはH265とじゃねえの？
609:名無しさん＠編集中
18/04/23 20:20:41.65 sDC0ee320.net
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
610:名無しさん＠編集中
18/04/23 21:52:47.76 z48p7vFc0.net
YouTube推奨ビットレート
URLﾘﾝｸ(vook.vc)
611:名無しさん＠編集中
18/04/23 22:33:19.70 xaUnJI540.net
>>573
やってみれば分かる。264や265に比べて死ぬ程遅い
特にx265と比較するとビットレート比画質負けるのは勿論デフォ設定同士の比較で1桁以上、下手すれば2桁が見えてくるぐらい遅い
612:名無しさん＠編集中
18/04/23 23:00:31.33 qgLqyElT0.net
,．-─ ─-､─-､
, イ)ィ -─ ─- ､ﾐヽ
ノ ／,．-‐'"´ ｀ヾj ii / Λ
,ｲ／／ ^ヽj(二ﾌ'"´￣｀ヾ､ﾉｲ{
ノ/,／ミ三ﾆｦ´ ﾞ､ﾉi!
{V /ミ三二,ｲ , -─ Yｿ
ﾚ'/三二彡ｲ .:ィこﾗ ;:こﾗ j{
V;;;::. ;ｦヾ!V ｰ '′ i ｰ ' ｿ
Vﾆﾐ( 入 ､ r j ,′
ヾﾐ､｀ゝ ｀ ｰ--‐'ゞﾆ<‐-イ
ヽ ヽ -''ﾆﾆ‐ / ググレカス [ gugurecus ]
| ｀､ ⌒ ,/ （西暦一世紀前半～没年不明）
| ＞ ---- r‐'´
ヽ＿ |
ヽ ＿ ＿ 」
613:名無しさん＠編集中
18/04/23 23:29:52.22 2kQ4iN3t0.net
>>580
なんか>>361のリンク先読むとVP9の方がHEVCより縮むと読み取れるんだけど…、
x265ならVP9より縮むって事なんかね？
＞AOMediaのメンバー企業であるBitmovinの検証によれば、同じ画質で比較したさい、AV1はVP9比で22～27%、HEVC比で30～43%ほどビットレートを削減できるという。
614:名無しさん＠編集中
18/04/24 00:12:35.33 e84XDnmq0.net
計算量がね
615:名無しさん＠編集中
18/04/24 01:36:38.43 4wh5n1kV0.net
>>579
つべあげるのに4k60pは60Mbpsあったほうがええのか。。
616:名無しさん＠編集中
18/04/24 02:57:28.71 Cv2UDVgJa.net
vp系はバッファ少なくても縮むからストリーミングに向いてて良いわ
mpeg系は再生できるようになるまでが長い
617:名無しさん＠編集中
18/04/24 21:19:53.63 TErN/BXE0.net
Advanced Media Framework (AMF) SDK Version 1.4.7
URLﾘﾝｸ(github.com)
Version 1.4.7: AMD Radeon Software Adrenalin Edition 18.3.4 (17.50.33) or newer
New features are available in
Driver: Radeon Software Adrenalin Edition 18.3.4 Software: 17.50 and later
1.4.7.0 (04.12.2018) version
--------------------------
- 360 video stitch sample
4/12って書いてるのは4/24の間違いだな。