◎正当な理由による書き込みの削除について:
管理人の生島英之(福岡市西区)です、宜しくお願いします。

x264 rev43©2ch.net ->画像>97枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/avi/1485572817/
ヒント:2chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1名無しさん@編集中 転載ダメ©2ch.net (ドコグロ MM83-FuHd)2017/01/28(土) 12:06:57.70ID:rzZP243DM
Q ニコニコ用の動画を作りたい。
A 板違い。Youtube板の"FLV/MP4エンコードスレ"でどぞ。

Q 圧縮codecありませんか?AviUtlのx264guiEx.auoの使い方は?
A x264 VFW GUI専用スレでどうぞ。
   x264vfw GUI専用スレ Part9
   http://peace.2ch.net/test/read.cgi/avi/1351856057/

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ。
   x264 初心者質問スレ part6
   http://peace.2ch.net/test/read.cgi/avi/1347527423/

[本家]
http://www.videolan.org/developers/x264.html
http://git.videolan.org/?p=x264.git;a=summary (ソース/チェンジログ)
http://web.archive.org/web/20150419065724/http://x264dev.multimedia.cx/ (開発者ブログ跡地)
http://web.archive.org/web/20141203142708/http://doom10.org/index.php (公式フォーラム跡地)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル)
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル)

2名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:07:47.29ID:rzZP243DM
[バイナリ]
  ・...::: Komisar x264 builds :::... (changelog.txtもここを参照)
     http://komisar.gin.by/

前スレ
x264 rev42
http://echo.2ch.net/test/read.cgi/avi/1454050806/

3名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:14:48.59ID:5vCHjYRZM
保守

4名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:15:22.27ID:5vCHjYRZM
保守

5名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:15:45.86ID:5vCHjYRZM
保守

6名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:16:02.64ID:5vCHjYRZM
保守

7名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:16:22.18ID:5vCHjYRZM
保守

8名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:16:40.44ID:5vCHjYRZM
保守

9名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:16:56.24ID:5vCHjYRZM
保守

10名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:17:15.40ID:5vCHjYRZM
保守

11名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:17:30.48ID:5vCHjYRZM
保守

12名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:17:47.10ID:5vCHjYRZM
保守

13名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:18:06.12ID:5vCHjYRZM
保守

14名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:18:23.46ID:5vCHjYRZM
保守

15名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:18:41.26ID:5vCHjYRZM
保守

16名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:19:15.29ID:5vCHjYRZM
保守

17名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:19:32.64ID:5vCHjYRZM
保守

18名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:19:49.04ID:5vCHjYRZM
保守

19名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:20:05.78ID:5vCHjYRZM
保守

20名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/28(土) 12:20:21.42ID:5vCHjYRZM
保守

21名無しさん@編集中 (ドコグロ MM83-FuHd)2017/01/29(日) 05:06:35.59ID:rZUkYjIyM

22名無しさん@編集中 (ワッチョイ 9a17-Ve17)2017/01/29(日) 11:58:23.73ID:HRXKy2910
CLIで使用できる文字数って上限有りますか?

--zonesで出来ることが増えたからいろいろ試したいんですが、
既に--zonesで1500文字以上消費してるので、不安です

23名無しさん@編集中 (ワッチョイ e37b-AZYz)2017/01/30(月) 01:55:48.47ID:FYD+LKAF0
保守

24名無しさん@編集中 (ワッチョイW f65f-sefe)2017/01/30(月) 07:09:43.17ID:bq+tM8dk0
ググったらvista 以降は32000字と出てきた

25名無しさん@編集中 (ワッチョイ 9a17-Ve17)2017/01/30(月) 18:54:18.65ID:0ep9ofwb0
>>24
ありがとうございます

26名無しさん@編集中 (ワッチョイWW 0b3c-UcZG)2017/02/01(水) 22:01:43.34ID:NLeHcyku0
・echo コマンドで、8192 文字目以降の引数が切り捨てられる。
・Cmd.ex e から、子プロセスを起動する際、渡される引数の一部に抜けが生じる。

https://support.microsoft.com/ja-jp/help/2823587

27名無しさん@編集中 (アタマイタイー MM25-qPcE)2017/02/02(木) 21:45:36.29ID:/Vde4AArM0202
違法な無反応チューナーやB-CASの規約に違反するTS抜きに関するスレッドを皆で追い出しましょう。

【自治】DTV板自治スレ5©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1485486086/

28名無しさん@編集中2017/02/05(日) 01:48:22.91
x264 rev43©2ch.net	->画像>97枚

29名無しさん@編集中2017/02/05(日) 01:48:30.10
x264 rev43©2ch.net	->画像>97枚

30名無しさん@編集中 (ワッチョイ f953-TVOI)2017/02/08(水) 17:06:31.20ID:Hb1bXVZs0
作業用に一時的にHi10PなイントラでCBRエンコしようしてるけど流石に早いな。

31名無しさん@編集中 (ワッチョイ 9336-yene)2017/02/08(水) 21:58:33.98ID:UXGxZlhJ0
komisar氏のr2762こないな

32名無しさん@編集中 (ワッチョイ 8742-CIv3)2017/02/09(木) 17:17:36.57ID:xBCE3WXq0
https://translate.google.com/translate?sl=en&tl=ja&js=y&prev=_t&hl=ja&ie=UTF-8&u=http%3A%2F%2Fkomisar.gin.by%2F&edit-text=

33名無しさん@編集中 (ワッチョイ 8a0b-fh5Q)2017/02/09(木) 17:24:58.14ID:cYvlgny90
残っていたMMX部分SSE2にしたっぽいが速度上がるかな?

34名無しさん@編集中 (ワッチョイ 2f0b-fh5Q)2017/02/10(金) 19:45:44.72ID:y31+GkOw0
2762、若干速くはなっているけど、微々たる物だな
i7辺りだと気にならないレベル、PhenomUやCore2でエンコしている人は其れなりに大きいって感じか

35名無しさん@編集中 (ワッチョイW 2764-fPxg)2017/02/10(金) 20:12:09.84ID:sMazUFU/0
Ryzenどうなるかなー
コア数多くてもAVX系弱そう

36名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ fad4-jWyY)2017/02/10(金) 22:47:30.72ID:knMGpv420
x264の実行時間の半分はSIMD以外の計算と言う話だから、AVX2が128bitでも、コアが増えるのは有効だろう

37名無しさん@編集中 (ワッチョイ 9361-CIv3)2017/02/10(金) 22:52:31.51ID:q3hMw7op0
現行FXより速くなるだろうから、それだけでもかなり良いと思う。エンコだけなら無難な速度だしてくれるからねw

38名無しさん@編集中 (ワッチョイ 8a46-CIv3)2017/02/11(土) 21:07:09.42ID:tjFEHFwy0
ジャップランドからだと落とせないのかw
ココでも『日本氏ね!!』だなww

39名無しさん@編集中 (ワッチョイ 4621-fh5Q)2017/02/12(日) 13:55:54.37ID:3HO66Hm+0
2762駄目じゃね?、少なくともx86版
tmodしか使っていないからtmodが悪いのかもだけど
2台のPCでエンコしていて、両方ほぼ同じ位置で止まった。
タスクマネージャー覗いたらx264 .exeが原因、ハングアップじゃなくループし続けたりするときと同じような状態

40名無しさん@編集中 (ワッチョイ 0e79-ENO3)2017/02/12(日) 15:49:14.05ID:raHBEb1h0
なら何でmodビルドではないplainなビルドで試さないのさ
同じ場所で止まるならソースが悪い可能性はないの?AvisynthやAviutlのフィルタとか

41名無しさん@編集中 (中止 8a17-P6gz)2017/02/14(火) 10:32:36.95ID:Y06BVDvR0St.V
crf 0って量子化が可逆なだけで、refとかmeが違うと別物のファイルを吐くんだな

42名無しさん@編集中 (中止 8ad8-Tsp1)2017/02/14(火) 16:48:41.04ID:MMAaxHxI0St.V
Iフレームでディザが消えててフレームを進めるとディザが復活してきて
次のIフレームではまたディザが消えるのって何が原因?
設定はcrf20でpresetがMedium

43名無しさん@編集中 (ワッチョイ 753d-iRi1)2017/02/17(金) 13:43:42.85ID:zOolMlCC0
level6て

44名無しさん@編集中 (スップ Sd03-RX2g)2017/02/20(月) 08:22:01.82ID:we6mEaoWd
>>42
ちょっとでも動きの激しいGOPの部分でよく見るわ
fgo=1にしてもほぼ改善しなくてバンディングが発生するから私も悩んでる

45名無しさん@編集中 (スップ Sd03-RX2g)2017/02/20(月) 08:28:59.06ID:we6mEaoWd
その部分だけをTrimしてエンコするとfgo=0でもディザはきれいに残るから何が悪いのかわからない

46名無しさん@編集中 (ワッチョイ 8500-P9CU)2017/02/20(月) 09:54:07.82ID:Mj9I5Lxk0
元からあるとかいう話じゃなくて?
x264のオプションならipratioのBフレーム版なオプションがあった(今もある?)はずだから探してみては

47名無しさん@編集中 (スッップ Sd43-RX2g)2017/02/20(月) 14:43:33.63ID:2FqcQwDpd
pbratioかな?
でもこれってIフレームには影響しないんじゃない?

48名無しさん@編集中 (ワッチョイ a53c-P9CU)2017/02/20(月) 14:54:31.48ID:y6mXnjGo0
名前の通りPとBだね
Pフレームの品質に対してBフレームの品質をどうするか
みたいなコマンドだったはず

49名無しさん@編集中 (スッップ Sd43-RX2g)2017/02/20(月) 18:09:28.11ID:cF3iu/KMd
Crfエンコでのビットレートで2passのエンコをすると、そっちではディザが保持された
かといって、ソース毎に必要なビットレートが違うから、一度Crfでエンコして必要なビットレートを取得して2passでエンコし直すというのも手間だしどうしたらいいんだろう

50名無しさん@編集中 (ワッチョイ 8500-P9CU)2017/02/20(月) 18:44:26.33ID:Mj9I5Lxk0
ごめん
さらっと読んで階調割れのことかと早ガッテンした
細かいものを残したいならデブロッキングフィルタを下げてみるとかpsy-rdの調整ぐらいしか思い浮かばないけど
今使ってるpresetや個別に指定してるオプションなどを書いてくれたらなんか思いつくかも

51名無しさん@編集中 (スップ Sd03-RX2g)2017/02/20(月) 18:53:20.61ID:bp1Dvjt0d
階調割れを防ぐためのディザを残そうとしてる
設定してるのはcrf=18, deblock=-1:-1, psy-rd=1.0:0.2, aq-mode=1, aq-strength=0.9

52名無しさん@編集中 (スップ Sd03-RX2g)2017/02/20(月) 19:32:29.04ID:bp1Dvjt0d
psy-rdを1.35:0.4に変更して、fgo=1を追加してもあまり改善はみられなかった
それで>>51の設定で2passエンコをしたらディザが保持できていた

53名無しさん@編集中 (ワッチョイ 8500-P9CU)2017/02/20(月) 20:46:19.40ID:Mj9I5Lxk0
もう画質とかあまり考えずにx265へ移行したから的外れ(記憶違い)かもしれないけおd
動きのあるシーンならとりあえずqcomp=80を試してみてるぐらいかな
あとはオプション弄る前にsubme上げるとか(プリセットを)上げる方が先決な気がする

(個人的にはcrf18ならdeblockは-2:-2:にしても大丈夫だと思うけど大した効果はないかな)

54名無しさん@編集中 (スップ Sd03-RX2g)2017/02/20(月) 20:58:18.33ID:bp1Dvjt0d
me=umh, subme=9, merange=32, qcomp=0.8, deblock=-2:-2
試してみたけどほとんど変わらないかな

55名無しさん@編集中 (ワッチョイ 8500-P9CU)2017/02/20(月) 22:11:47.21ID:Mj9I5Lxk0
そうか残念・・今、あと思いつくのはsubme=11のno-mbtree だけ
そういえば、むか〜しmuken氏の私的エンコード設定晒しなコマンドラインをどっかに保存したはず・・と思って探してみたんだけどないんだよね
muken氏のオプション設定の優秀さを測れると思ったんだけど、それもちょっと残念

56名無しさん@編集中 (ワッチョイ 2317-QocU)2017/02/21(火) 00:14:40.64ID:d+R5c1Ke0
>>55
--no-mbtreeは効きそうですね
--pbratioが有効になるから、1付近に設定すればマシになりそう

57名無しさん@編集中 (ワッチョイ 2317-QocU)2017/02/21(火) 00:16:23.14ID:d+R5c1Ke0
--qpfile とか --cqmfile みたいに、 --zonesfile オプションがほしい

58名無しさん@編集中 (スプッッ Sd43-RX2g)2017/02/22(水) 21:29:35.98ID:IwsRK/Qtd
いろいろ試してみたけどやっぱりディザが残らない
qpfileでIフレームのqpを0に設定してもフレームの上端のマクロブロック一列しかほとんどディザが残らない

59名無しさん@編集中 (ワッチョイ 8500-P9CU)2017/02/22(水) 23:25:33.38ID:WN4yLsjU0
そういえばpsy-rd使うとなんとかqp-offsetがマイナスになった気がするからpsy-rdを0:0(効果を分かりやすくするため)でやってみたら?
さらにtune grainでやって残らないならmuken氏にでも聞くしかないと思うな・・
とういうかなんかIで消えてP/Bで残るってなんか出てきそうで出てこないんだよね

60名無しさん@編集中 (スプッッ Sd03-RX2g)2017/02/22(水) 23:49:57.04ID:acFLLeSrd
マイナスになるのはchromaじゃなかったかな?
次はtune grainも試してみる
なんでcrfだと消えて、2passだとバンディングが発生しない程度には保持できるのか謎

61名無しさん@編集中 (ワッチョイ 1a17-8Hz2)2017/02/23(木) 04:23:16.41ID:x/XdQJoH0
そもそも無理だからバンディング低減フィルタが生まれたのではないのか

62名無しさん@編集中 (ワッチョイ c679-HyQo)2017/02/23(木) 11:07:57.88ID:vN+wtlpW0
なんで糞忙しそうなmuken氏に聞こうとするんですかね・・・
かつて野良ビルドしてた人だけどx264devじゃないでしょ

>>58
取り敢えず画像上げてみたら?ソースとcrfエンコ後、2passエンコ後の3種類

63名無しさん@編集中 (ワッチョイ fd3b-M7EA)2017/02/27(月) 07:17:53.84ID:XLbpq8sD0
>>34
>PhenomUやCore2でエンコしている人は其れなりに大きいって感じか

FXまでのAMDプロセッサを使う場合は、r2345以降は思ったほど速度でないから。
r2345以降のx264でエンコさせると平均で6〜8fps前後遅くなるし。

64名無しさん@編集中 (ワッチョイ 75c1-F6/z)2017/02/27(月) 10:16:14.05ID:pSxAzVIJ0
>>60
ソース見ないと、対策できるものかどうかなんとも
思いつくのは、まずは詳細ログを取って該当箇所のフレームタイプとqp値を調べる事かな

自分なら実験として、10bitやb無しをためしてみる

yを少しいじるだけで、かなりブロックが出てくるソースて結構あって
それをエンコすると俺には階調に見えたりする事もあった
(ffmpgのssim見るとx264のエンコはyが大きく落ちる傾向にある)
それも考慮に入れて見ては

65名無しさん@編集中 (ワッチョイ ae59-zFUC)2017/02/28(火) 17:36:14.00ID:PHbqDs1E0
>>r2345以降のx264でエンコさせると平均で6〜8fps前後遅くなるし。
2346以降、2345最期に削った命令はOSが7以降と言う条件付き
XP(改)や2kexの場合は元々機能しない命令なので最新版の方が速いと蛇足付けておきます

66名無しさん@編集中 (ワッチョイ fd3b-M7EA)2017/02/28(火) 19:19:49.54ID:YVuNCVGh0
そもそもx264でエンコする人がいまだにWin7未満を使い続けてるとは到底考えられないんだが。
Win7未満を使い続けてる層はx264よりくっそ軽いXVIDやDIVXを愛用してんじゃないか。

67名無しさん@編集中 (ワッチョイ 5500-d4M5)2017/02/28(火) 21:04:36.71ID:nWED9X2x0
煽り失敗!

68名無しさん@編集中 (ワッチョイW 1a17-1OkV)2017/03/01(水) 00:04:40.77ID:3MlnXzcL0
OSとCPUの区別がついてないんだな

69名無しさん@編集中 (ワッチョイ 053c-d4M5)2017/03/01(水) 14:25:06.58ID:MUatPPG40
test

70名無しさん@編集中 (ワッチョイ fb76-rrQM)2017/03/02(木) 00:04:11.79ID:znb1goci0
komisarが403なの俺だけ?

71名無しさん@編集中 (ワッチョイ 1317-5Zjm)2017/03/02(木) 00:08:33.38ID:6vPQ95ES0
>>70
日本からのアクセス遮断されてる

72名無しさん@編集中 (ワッチョイ fb76-rrQM)2017/03/02(木) 00:40:05.09ID:YFE/7OfW0
マジか
何があったんだ

73名無しさん@編集中 (ワイエディ MM63-BJNc)2017/03/02(木) 00:45:17.49ID:x8Wr5mB9M
ライゼンってSSEが十倍の性能らしいからコア数とあいまってエンコはかどるかな?

74名無しさん@編集中 (ワッチョイ 2b79-2BvX)2017/03/02(木) 00:46:10.10ID:V8vD73Fb0
理由は不明
予想するとすればAviUtlのx264GUIExが自動ダウンロードするx264がkomisar氏のもので
それでアクセス数が急増して日本からの接続を拒否ったとかそういうところじゃないのかな?

75名無しさん@編集中 (ワッチョイ 2919-BJNc)2017/03/02(木) 01:47:39.10ID:EpvM0pt80
急増するほど最近の話か? それ

76名無しさん@編集中 (ワッチョイ 493c-da5B)2017/03/02(木) 07:10:53.26ID:zo1ua/sp0
自動インストーラってAviUtlに必要なん?
README見て必要なものを集めてくんじゃないの?w
>>75
急増騒きは少し前だと思うよ
その時期にYoutubeに手順動画が流れてにわかユーザーが増えたからじゃないかな
理解しないで適当インストールを繰り返してアクセスが増えたのは確かかな
今も増えてるようだけど、安易に変なインストーラ作らないで欲しいと思うよ

77名無しさん@編集中 (ワッチョイ 493c-FnJB)2017/03/02(木) 07:20:14.76ID:xEj84IP10
Readmeを見て自分でファイルを集めてこれない人向けだから…

78名無しさん@編集中 (ワッチョイ 2942-NqFr)2017/03/02(木) 10:39:30.20ID:xiBnsCVc0
久々に来てみたがネ実のクズ共の荒らし行為って沈静化したん?

79名無しさん@編集中 (ワッチョイ 13fd-9OG8)2017/03/02(木) 15:19:05.46ID:r5tKudVv0
自動ダウンロードに拒否がどうのって話デジャヴ

80名無しさん@編集中 (ワッチョイ 7b59-AHnh)2017/03/02(木) 16:47:40.61ID:NAYKX2H20
>>74
それで良いと思うよ
ツール使ってダウンロードしないでくれって書いてあるし
よっぽど行儀の悪いアクセスしていたか、数が半端じゃなかったんだろうよ

81名無しさん@編集中 (ワッチョイ 13a6-BJNc)2017/03/02(木) 21:16:20.34ID:lBCkdqF50
>73
自分は今すぐには買えないので、レポ待ちでワクワクしている

82名無しさん@編集中 (ワッチョイ 293b-TgS+)2017/03/02(木) 21:52:10.99ID:OQofB6vk0
よかったな 速いぞ
x264 rev43©2ch.net	->画像>97枚

83名無しさん@編集中 (ワッチョイWW 3117-RQw6)2017/03/03(金) 01:25:00.72ID:SoL/p3Zu0
エンコ用途なら買いだな

84名無しさん@編集中 (ヒッナー 293b-TgS+)2017/03/03(金) 07:52:13.49ID:JjDE7caL00303
Encodage video : x264 et x265 - AMD Ryzen 7 1800X en test, le retour d'AMD ? - HardWare.fr
http://www.hardware.fr/articles/956-13/encodage-video-x264-x265.html
x264 rev43©2ch.net	->画像>97枚
AVX2オフにするとパフォーマンス上がる

85名無しさん@編集中 (ヒッナー 4160-NqFr)2017/03/03(金) 10:44:24.67ID:o2enDWaz00303
コアあたりの性能はIntelとほぼ同等まで追いついて価格が驚異的に安い
Ryzenコスパやばいな

86名無しさん@編集中 (ヒッナー b15b-2BvX)2017/03/03(金) 11:23:50.13ID:mkOg2Z+q00303
まさかx264エンコードでも上行くとは
動画エンコードでIntel上回ったのなんて初じゃね

87名無しさん@編集中 (ヒッナー 493c-FnJB)2017/03/03(金) 11:39:33.65ID:rDE5c83b00303
611 名前:名無しさん@編集中[sage] 投稿日:2016/12/07(水) 21:57:43.12 ID:Ast4Hrma [3/3]
[バイナリ]
■rigayaの日記兼メモ帳 (右下の「x264」から)
  http://rigaya34589.blog135.fc2.com/
■jpsdr/x264 (t_mod版)
  https://github.com/jpsdr/x264/releases
■...::: Komisar x264 builds :::... (clear版/kMod版)
  ※2016年11月より日本からアクセスできなくなっているのでWebArchiveで。
  http://web.archive.org/web/*/http://komisar.gin.by/

88名無しさん@編集中 (ワッチョイ 0bfd-2BvX)2017/03/05(日) 19:06:24.58ID:9iE97utn0
エンコなら1800X買うしかないねぇ

89名無しさん@編集中 (ワッチョイ 294f-BJNc)2017/03/06(月) 02:26:58.54ID:2jXgFqW50
1700で十分だな
1800X/1700Xの差別化ポイントであるXFRはたった
1コアを100MHzだけOCするガッカリ機能だと判明して
結局は手動で倍率設定するしかない
自作PC板では倍率フリーの1700をクロック上げれば1800Xとほとんど変わらんじゃん
て流れになってる

90名無しさん@編集中 (ワッチョイ 8b5e-BJNc)2017/03/08(水) 21:45:18.31ID:5f3zjIK/0
2ソケットできるNaplesだと1800Xよりさらに上か・・・
買う人は買うだろうなあ

91名無しさん@編集中 (ブーイモ MM4d-NIfd)2017/03/08(水) 22:14:26.50ID:8NMXBv1WM
おいくら万円になるんだか

92名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ 0bd4-Mt2S)2017/03/08(水) 22:17:12.49ID:uSeTgtzR0
Naples x 2だと合計128スレッドで、現時点でのx264の--threadsの限界に達するな

93名無しさん@編集中 (ワッチョイ 7917-2hGO)2017/03/11(土) 01:16:36.51ID:xcdpSSTj0
確かスレッド増えるとファイルサイズも僅かに大きくなるよね
128スレッドだと、気になるぐらいファイルでかくなるんだろうか

94名無しさん@編集中 (ワッチョイ 5d3c-qe+Q)2017/03/11(土) 01:36:00.94ID:thFGa3uF0
--threads 12で--threads 1よりビットレートが1%ぐらい大きくなってた気がするけど
128/12=10.67%も大きくなる…のかなぁ

95名無しさん@編集中 (アウアウカー Sa5d-JT/Z)2017/03/11(土) 08:55:13.25ID:r7DCAib9a
ccx内で完結するように2本流して速度稼ぐのが良いのでは?

スレ数増やす設定で処理fps増やすのだから物理スレ数と設定スレ数が同一なのはメリットがイマイチな気がする。

L3キャッシュはccxを跨ぐと効率が落ちるからこの辺りの実装を気にした実装が理想だろうね。

96名無しさん@編集中 (ワッチョイ d64f-2hGO)2017/03/12(日) 06:59:44.38ID:ev1URYZR0
実際にはx264はRyzenが非常に得意な分野だから
コアの割り当て問題は当然のこととしてL3が8MB + 8MB
にパーティショニングされてる問題もほとんど影響ないんだろ

97名無しさん@編集中 (ワッチョイ 2500-csvI)2017/03/12(日) 09:35:06.27ID:HPWsohqC0
SIMD命令にキャッシュはあまり関係ないそうだよ

98名無しさん@編集中 (ワッチョイ cd3d-oGwt)2017/03/12(日) 14:10:09.08ID:gTBFYAG80
AthlonUX4はいい塩梅だった

99名無しさん@編集中 (ワッチョイ b1d6-T4Zw)2017/03/12(日) 20:22:19.29ID:3TierDBr0
誰か雷禅でエンコして

100名無しさん@編集中 (ワッチョイ fa17-KHUK)2017/03/12(日) 20:30:17.56ID:It3queHc0
>>99
このスレじゃいかんの?

【x264+Avisynth】実用エンコベンチ Part5.1 [無断転載禁止]©2ch.net
http://potato.2ch.net/test/read.cgi/jisaku/1460032466/

101名無しさん@編集中 (ワッチョイ 13d8-3AO9)2017/03/17(金) 23:55:59.76ID:x2MiC76Z0
アドバイスお願いします。
動きのあるシーンで動いた部分のディザーやグレインが保持できないのですが、どうすればよろしいでしょうか?
動きの少ない部分では保持できています。
パラメーターはcrf 18、umh、subme 10、psy-rd 1.0:0.3、aq 3:1.00、bframes 6、b_pyramid 2、b_adapt 2です。

102名無しさん@編集中 (ワッチョイ 0b79-12+v)2017/03/17(金) 23:59:30.84ID:6/5IqK3Y0
--qcompを盛ってみる 0.8とか
--qpstepを盛ってみる 8〜16とか あんまり大きくしすぎても良くはならない気がする
--bframesを減らしてみる デフォルトの3とか

103名無しさん@編集中 (ワッチョイ 59fe-tpgq)2017/03/18(土) 13:08:41.33ID:Mqc7uy8r0
deblock -2:-2, psy-rd <unset>:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8

tune grainの中身らしいから、これを軸にいじってみればいいんじゃない

104名無しさん@編集中 (ワッチョイ 1359-F0aS)2017/03/18(土) 14:39:38.21ID:PgHHxzGe0
質問スレとかなくなっちゃったんだね

みんなって、最新のリビジョン使って本番エンコしてる?
さすがに最近はやらかしとかないよね

105名無しさん@編集中 (ワッチョイ 9989-12+v)2017/03/19(日) 21:14:44.14ID:3yF2GRg50
posix versionsって何?
Linux用?

106名無しさん@編集中 (ワッチョイ 91c1-y/cv)2017/03/20(月) 15:27:25.32ID:BpP4DLbv0
わからないなら気にするな
ggrks

107名無しさん@編集中 (ワッチョイ 613b-WisJ)2017/03/20(月) 17:19:36.45ID:g6ulSQjE0
x264で盛り過ぎると再生(デコード)時にやたら負荷のかかるパラメータってなんだっけ?
前にx264でエンコした動画をスマホのVLCで見ようとしたらコマ落ちが酷くてだいぶ厳しかった。

108名無しさん@編集中 (ワッチョイ 0b79-u6wT)2017/03/20(月) 17:20:46.10ID:mCakdv6o0
refとかbframesとか

109名無しさん@編集中 (ワッチョイ 613b-WisJ)2017/03/20(月) 17:50:15.86ID:g6ulSQjE0
x264 core 148 r2744 b97ae06 High10 Lv5.1

Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10
psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1
cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2
sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0
bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0
weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60
rc=crf / mbtree=1 / crf=15.5 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

ちなみにこんな設定。

110名無しさん@編集中 (ワッチョイ 013c-fEWq)2017/03/20(月) 17:52:48.16ID:vVotdsrL0
refもbframesもスマホ向きじゃないぐらい大きいね

111名無しさん@編集中 (オイコラミネオ MMab-Gg+/)2017/03/20(月) 17:54:11.45ID:IPbCXG2RM
解像度によってはref16はかなりのハイレベルになるよ

112名無しさん@編集中 (ワッチョイ 0b79-u6wT)2017/03/20(月) 17:55:19.32ID:mCakdv6o0
8bitエンコにするなりrefを3~4にするなりbframesを減らしてみるなり手はあると思うんだ

113名無しさん@編集中 (ワッチョイ 613b-WisJ)2017/03/20(月) 18:01:04.11ID:g6ulSQjE0
エンコ環境やノートPCでは何の不都合もなく再生できていたから
スマホでも行けると思って再生してみたら、ほんとやらかした感に満たされた。

画質を選ぶか負荷低減を選ぶか、どこで線引きするか悩むところだね。

114名無しさん@編集中 (ワッチョイ 0b79-u6wT)2017/03/20(月) 18:07:44.17ID:mCakdv6o0
少なくともbframesは盛ったところで縮みはするけど画質が上がるとは限らないと思う
refはどうなんだろうな以前盛ったり減らしたりしたけど特段盛りまくってもエンコ速度とSSIMを比べると効率が悪くなる気がして4ぐらいまでしか使ってないな

115名無しさん@編集中 (ワッチョイ 1317-bHoN)2017/03/20(月) 18:11:42.13ID:YxhIh3YN0
素人で再生互換性とかよくわからないからほぼデフォルトプリセットしか使ってない

116名無しさん@編集中 (ワッチョイ 91d4-tpgq)2017/03/20(月) 18:12:42.05ID:g0tid5gi0
Bフレ8枚って容量節約モードですか

117名無しさん@編集中 (ワッチョイ 914f-tpgq)2017/03/20(月) 18:57:06.45ID:dyE1cGoC0
費用対効果的に
ref 4
bframes 3
以上は微差しかないな

118名無しさん@編集中 (ワッチョイ 0b5b-tpgq)2017/03/20(月) 18:59:35.37ID:K9LZysiQ0
まあBフレ増やして節約した容量分、crf下げれば
画質は良くなるけど再生負荷は高いよね

119名無しさん@編集中 (ワッチョイ 9153-ajdi)2017/03/20(月) 19:15:29.81ID:DaNUKjFo0
veryslowベースの設定なのかもしれんが、「crf=15.5」ってのも結構やばいのでは・・・
Hi10pな上に、ここまでcrf値を下げる人ってあまりいないんじゃないか?

120名無しさん@編集中 (ワッチョイ 313c-u6wT)2017/03/20(月) 20:02:59.60ID:OH0D6gB50
他のコマンドにもよるだろうけど、crf16あたりからが人間の眼では劣化が分からなくなるんじゃなかったっけ?

121名無しさん@編集中 (ワッチョイ 1359-idsh)2017/03/20(月) 20:35:50.01ID:myC1EGEA0
どこが悪いというか、スマホで動かすには悪いところ多すぎてわらたw

122名無しさん@編集中 (ワッチョイWW b18e-DTjG)2017/03/21(火) 10:20:59.28ID:kHNquja20
スマフォならHWデコードだから大して差は無いと思うが、そもそも10bitデコードに対応してる機種なの?

123名無しさん@編集中 (スプッッ Sd73-urfV)2017/03/21(火) 12:39:29.68ID:7w2jOxdHd
ハードウェアデコードとはいえ、無制限ではないからな。
想定はBDの規格内と思ってたほうが良いと思うぞ。

124名無しさん@編集中 (ワッチョイ 693e-ajdi)2017/03/21(火) 14:53:32.41ID:aS02+pTx0
>>122-123
H.264の10bitのHWデコードに対応してるものなんて無いだろ。10bitはSWデコードのみ。

125名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ 6bd4-M7md)2017/03/21(火) 17:39:54.26ID:ZWjxBEYu0
ちゃんとVBVを設定してHigh@4.1までならどのハードでも安心

126名無しさん@編集中 (ワッチョイWW b18e-DTjG)2017/03/21(火) 18:53:41.96ID:kHNquja20
>>123
その制限がプロファイルとレベルだと思うんだが範囲内ならドロップしたことは無いかなぁ

>>124
俺も見たこと無いんだが、スマフォでSWデコードはキツくねって言いたかった

127名無しさん@編集中 (ワッチョイ 51e1-u6wT)2017/03/21(火) 20:42:13.86ID:gt0UGiJv0
>>126
そうでもない
円盤はランダムシークに弱いからBフレも参照距離も3程度がベター
もっとも16とか指定しても使わなければ問題ないわけ(HWデコード全般で)だけど
万が一に備えると厳しめになる

128名無しさん@編集中 (ワッチョイW 51f3-vaS3)2017/03/22(水) 23:19:05.92ID:vOb72tqI0
はあ?

129名無しさん@編集中 (ニククエWW ddc8-/tPV)2017/03/29(水) 14:34:57.70ID:lSlTuvuQ0NIKU
--crf *を指定しなくてもエンコ出来たんですが--crf 23とサイズが同じでした
crf指定無しだと--crf 23と同じ扱いになるんですか?

130名無しさん@編集中 (ニククエ 3e79-5sBS)2017/03/29(水) 14:39:19.24ID:sWlpArUZ0NIKU
そもそもデフォルト設定が--crf 23

131名無しさん@編集中 (ニククエWW ddc8-/tPV)2017/03/29(水) 23:57:08.08ID:lSlTuvuQ0NIKU
>>130
なるほどありがとうございます

132名無しさん@編集中 (ワッチョイ 9fb6-Qc7F)2017/03/30(木) 14:43:09.54ID:foKOUbX30
>>127
なんか、突っ込む気力が失せるくらい色々痛いな

133名無しさん@編集中 (ワッチョイ 9fe1-jsM4)2017/03/30(木) 15:14:27.49ID:dO0HQ95e0
>>132
つ鏡

134名無しさん@編集中 (ワッチョイ ffa3-jsM4)2017/04/02(日) 15:33:06.82ID:JfirpmU20
RFFフラグを使ったソフトテレシネ素材をx264でエンコしたいのですが、
ソフトテレシネのままエンコする方法はありますか?

一応プログラムも書けるのですが、libx264は使いたくないのでx264.exe使って
タイムコードみたいに、RFFフラグをファイルから入力させることができればベストだと思ってます

60i混在ソースなので、全部24p化するというのはできなくて
今の所フレーム水増しして60iにしてエンコしてるのですが、
ソフトテレシネのままの方が画質が良くなると思うんです
そんなに気にする必要ありませんかね

135名無しさん@編集中 (ワッチョイ ff79-jsM4)2017/04/02(日) 15:35:31.23ID:zlbvKLjL0
--pulldown 32のオプションがあった気もするがこれがソフトテレシネであるかは忘れた

136名無しさん@編集中 (ワッチョイ ffa3-jsM4)2017/04/02(日) 15:42:07.65ID:JfirpmU20
>>135
それはソフトテレシネなのですが、フレームごとに指定することができない(する方法が分からない)ので、
60i混在ソースだと使えないんです

137名無しさん@編集中 (ワッチョイ ff79-jsM4)2017/04/02(日) 15:50:20.30ID:zlbvKLjL0
zoneはきっと使えないから--stitchableと--sps-idを使って分割エンコして最後に結合すればなんとかなるんじゃない?
糞めんどくさいしややこしいから60iに統一してやったほうがいいしそこまで画質に差は出ないと思う

138名無しさん@編集中 (ワッチョイ ffa3-jsM4)2017/04/02(日) 16:06:58.66ID:JfirpmU20
なるほど・・・そこまでやるんだったらx264cliを改造したほうが簡単かもしれないですね。ソース読んでみます

139名無しさん@編集中 (ワッチョイ 9fb9-agmj)2017/04/02(日) 16:15:01.80ID:UgoQM92X0
x264はMBAFFインタレだからインタレ保持にしてもPAFFインタレよりは符号化効率高いよな

140134 (ワッチョイ ffa3-jsM4)2017/04/02(日) 23:17:47.17ID:JfirpmU20
x264cli改造してRFFフラグをファイルから入力できるようにした
https://github.com/nekopanda/x264/commit/6d734de56d0bb7e1dc5c660634c9a2f4fb3bd02d

これでエンコしたやつ、H264のrawストリームはmpc-hcで再生してちゃんと再生されてるようにみえるんだけど
mp4にmuxするとおかしくなる。

L-SMASHだとfpsを引数で指定してるのになぜか出力がVFRになっちゃって
再生するとフレームレートが半分くらいになっちゃう

MP4boxだとpulldownしてるところがちゃんと認識されないのかL-SMASHとは逆に1.2倍速くらいに速くなっちゃう

エンコはできてもmuxできないというオチorz

x264だとソフトテレシネはプログレッシブでのエンコードになるから、60iとの混在ソースだと
エンコ途中でプログレッシブとインターレースを切り替えるためにx264_encoder_reconfigを呼ぶ必要があって
なんか危なそうだし、やめておいたほうがいいかな

141名無しさん@編集中 (ワッチョイ ff79-jsM4)2017/04/02(日) 23:23:41.04ID:zlbvKLjL0
>>140
うーんどうだろうH.264やmp4(ISOBMFF)の規格に詳しくないから分からない
もう全体的に60iとしてエンコしてしまったほうがいいんじゃないかな x264はインタレェでもそれなりに圧縮率いいし
--stitchableと--sps-idを使って最後に結合する方法は規格上問題ないとは聞いた

muken氏とかH.264とISOBMFFの両方に精通してる人に聞かないと正しい実装に出来ないんじゃないかな

142名無しさん@編集中 (ワッチョイ 9f95-jsM4)2017/04/03(月) 07:37:09.54ID:TctSlTlK0

143名無しさん@編集中 (ワッチョイ ffa3-jsM4)2017/04/03(月) 09:31:10.42ID:fUoHoWI80
感激!そうかmuxでずれるのはタイムスタンプいれてやればいいのか。夜試してみるわ

144名無しさん@編集中 (ワッチョイ ff79-jsM4)2017/04/03(月) 11:16:11.92ID:VSUvqQUi0
すごく内容に興味あるんだけど、うまくいったらこの--pdfile-inの書き方を教えてくれないかな?

145名無しさん@編集中 (ワッチョイ 9fb6-Qc7F)2017/04/03(月) 14:27:48.23ID:35NLofYn0
muken氏語ってるね
残業なくてもイエスマンが出世するようになってるからダメでしょ
そんな人に勉強の成果や能力の良し悪しの判断なんて土台無理な話
で、また、イエスマンが出世する
これじゃ、中卒か高卒で公務員になって趣味に生きるのが最もコスパの人生だからね
シャープ、東芝、かつての日産見ても学習できないんだからどうにもならん
すれちすまん

146134 (ワッチョイ ffa3-jsM4)2017/04/04(火) 01:08:20.88ID:NM8tqATA0
うぉぉーできたー!timelineeditorでタイムコード入れたらちゃんと再生できるようになった。
mukenさんありがとうございます!

ただちょっと問題が。

PC(mpc-hc)、Xperia Z4 Tablet、PS3でそれぞれ再生してみたら、
PS3だと何の問題もなく再生できたけど、
mpc-hcだとたまにインターレース縞が見えるのと、動きが若干カクカクする。
Xperia Z4 Tabletだと、インターレース縞は全く無いけど、mpc-hcと同じように若干カクカクする。

タブレットだと画面がそんなに大きくないから、カクカクって言っても、よーく見ないと分からない程度だけど、
mpc-hcでちゃんと再生されないのはなぜなのか・・・

PS3だと本当に何の問題もなく再生できて、ブラビアのモーションフロー効かせても問題ないんだよな
再生側の問題なのか、mp4ファイル側に問題があるのか、分からん

147名無しさん@編集中 (ワッチョイ 9fd4-YWlL)2017/04/04(火) 02:00:24.39ID:htZBUXUD0
家電系は放送の変態ストリームに耐性があるけど、PC系は違うんだわな
pulldownして全部iで出すデコーダと、p部分はpのまま出すデコーダがあったりして
後者の場合にi/pの変わり目で挙動が乱れるレンダラがあったりする

148名無しさん@編集中 (ワッチョイ ffa3-jsM4)2017/04/04(火) 02:19:44.54ID:NM8tqATA0
すまん、カクカクだったのは俺のタイムコード生成プログラムのバグだったわ
直したらmpc-hc、Xperia Z4 Tabletともにカクカクはなくなった
これでXperia Z4 Tablet、PS3では全く問題無く再生できるようになった

ただ、mpc-hcだと、プログレッシブとインターレースの切り替わりで問題があるっぽい
インターレース縞が残ったり、フレームが一瞬戻ったりする
>>147まさにそういう状況だわ
変態ストリームというかPC系がちゃんと実装してないだけなんだよな

mp4のファイル自体は問題なさそうだから、これでソフトテレシネと
60iインターレースの混在ソースをそのままエンコードできるようになった

>>144
今作ってるフロントエンドのプログラムそのうち公開するから待って

149名無しさん@編集中 (ワッチョイ ffb9-agmj)2017/04/04(火) 02:31:19.30ID:n3r5tOrx0
mpc-hcというかLAVはどうもインタレ、プログレ混在は苦手っぽい
PAFFインタレだと60i部分が30p再生されたりとか

150名無しさん@編集中 (ワッチョイ c1b6-ntn2)2017/04/06(木) 19:27:08.09ID:01K8kK0t0
ffmpegだとフラッグのみbobすればよかったような

151名無しさん@編集中 (スプッッ Sdc1-I/6S)2017/04/08(土) 00:55:21.46ID:yDtOaJW8d
参照しているフレームの情報を利用したいんだけど、どうすればいいかな?
x264_adaptive_quant_frameのところを利用できるのが理想です。

152134 (ワッチョイ 7fa3-V7Gz)2017/04/15(土) 18:54:30.25ID:+/NipqGl0
あれから出力されたストリーム詳しく見たりしてたけど、
reconfigじゃインタレとプログレの切り替えはできないことが判明して
プルダウンのときはdelta_poc_bottomがゼロになるように改めて修正した

mpc-hcでフレームが一瞬戻ったりってのもなくなったし、
FFmpegでデコードしてRFFフラグをちゃんと取得できるのを確認したから、
規格上も問題ないストリームになったかな

>>144
pdfile-inはこんな感じ↓
https://github.com/nekopanda/Amatsukaze/blob/master/Amatsukaze/TranscodeManager.hpp#L1126

153名無しさん@編集中 (ワッチョイ c7e1-RZRQ)2017/04/15(土) 19:27:23.01ID:eAFMSi9o0
>>152
なんか本当に形になるとは思ってなかった
ありがたくウォッチさせてもらうは

154名無しさん@編集中 (ワッチョイ ff79-V7Gz)2017/04/15(土) 23:49:50.26ID:EpfRbE3V0
>>152
おつかれ
覗いてくるわ

155名無しさん@編集中 (ワッチョイ c7b6-XBGH)2017/04/16(日) 08:46:32.41ID:nhrM+GHT0
win専用なのか
残念

156名無しさん@編集中 (ワッチョイW bfaa-ccID)2017/04/19(水) 23:12:51.43ID:SeBvsYch0
5.1ch用に前処理しなくていいのが楽だなあ

157名無しさん@編集中 (ワッチョイWW 1f8c-kvvf)2017/05/01(月) 23:07:01.47ID:42uPSlD30
あげ

158名無しさん@編集中 (ワッチョイ dec8-u2ln)2017/05/05(金) 03:04:58.69ID:FdjoRNe60
Ryzen 1700環境を手に入れたんだが、どんなに設定を弄ってもCPU使用率100%いかないんだが
同じような現象起きてる人いる?
AviUtl x264GUIからx264(2762)でエンコしてるんだが、どんなに重い設定にしても
aviUtl 8% x264 78%くらいのCPU使用率にしかならない。
aviUtl側はフィルタ全部外して、x264の軽い設定だとaviutl側で20%くらいCPUを使っているので
aviUtlがネックになっているわけでもなさそう。

なんかせっかくの16スレッド環境を無駄にした気がしてならない。

159名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ d6d4-6eBE)2017/05/05(金) 03:22:17.02ID:PxrPz4xg0
>>158
AviSynth+のMT版に以降して、Prefetch(16)を試してみたら

160名無しさん@編集中 (ワッチョイ de79-W+y+)2017/05/05(金) 03:24:02.13ID:qcN7u1qj0
x264GUIはややスレチだけど、メニーコアなCPUだとCPUを完全に使い切れないことは多い

161名無しさん@編集中 (コードモ 16a3-W+y+)2017/05/05(金) 07:53:47.99ID:YZ3yL0J800505
2つ並列にエンコすれば100%行くよ

162名無しさん@編集中 (コードモ 16a3-W+y+)2017/05/05(金) 08:01:00.68ID:YZ3yL0J800505
Ryzen7ならL3キャッシュが4コアずつに分かれてるから
タスクマネージャーの関係の設定でAviUtlの使用コアを若い方8個と後ろの方8個に分ければいいと思う

163名無しさん@編集中 (コードモ 7fe1-7zcB)2017/05/05(金) 09:24:19.06ID:nc8W/xjM00505
>>158
aviutlスレにも書いたけど1本のエンコードで100%は無理
それでもAviutlと合わせて80%越えてたら十分でしょ

164名無しさん@編集中 (コードモ 02d4-Ogwz)2017/05/05(金) 09:30:26.82ID:+B6luGJ/00505
x264に限らずフィルターもマルチコアに最適化されないとどうにもならないんだから
80%近く出てるなら十分だと思うけどな
avisynthで複合型のフィルターなんか使うと20%以下もざらにあるぞ

165名無しさん@編集中 (コードモ dec8-u2ln)2017/05/05(金) 13:19:52.74ID:FdjoRNe600505
まじか。今のx264だとまだ性能出しきれるほど最適化されてないのか。
x264のチューニング入るまでは開いたCPUでBONIACでも回しておくか。

166名無しさん@編集中 (コードモ b3c8-HG4F)2017/05/05(金) 13:45:24.01ID:3AEMG+VU00505
最適化はもう限界に近いでしょ
アルゴリズム的に並列作業が増やせないものは仕方ないよ
今でも使用率上がってても大半の計算結果は途中で捨ててるくらいだし

167名無しさん@編集中 (コードモ 02d4-Ogwz)2017/05/05(金) 14:10:53.60ID:+B6luGJ/00505
x264だけなら100%近く出せると思うけど実際にそれだけという人はいないから
結局の所は使うフィルター次第という話になってくる
avisynth+にフィルターをMTに対応させる機能もあるけど不具合と限界があるから1本の処理に拘るんじゃなくて
2本3本と処理する本数を増やした方が悩まなくて済むとおもうぞ

168名無しさん@編集中 (コードモ b3c8-HG4F)2017/05/05(金) 14:17:45.17ID:3AEMG+VU00505
5960X環境だけどUt_videoのavi食わせてるだけなのに100%なんていかないよ
80%くらいをうろつく

169名無しさん@編集中 (コードモ 9272-37K/)2017/05/05(金) 14:22:07.27ID:I4yKE2ol00505
ベンチスレ見てても多コアなやつは100%までいってなかったような

170名無しさん@編集中 (コードモ 12d4-Ogwz)2017/05/05(金) 15:14:52.02ID:3QEgKuQF00505
実際4コアで十分
それよりも動作クロック

171名無しさん@編集中 (コードモ 6b61-7zcB)2017/05/05(金) 16:51:23.07ID:7L1WkNvu00505
CPUが100%に張り付けばいいってもんじゃないと開発者が言ってたと思うよ。
エンコ速度に注視しろって事も付け加えられていたようん。

172名無しさん@編集中 (コードモ 4b94-pIlU)2017/05/05(金) 18:42:52.11ID:/ft2Zb9F00505
マルチプロセスでスレッド数を減らすことを意識したほうがいい

173名無しさん@編集中 (コードモ 16e2-B8vL)2017/05/05(金) 19:47:46.78ID:IyQHVJhz00505
>>168
それぐらいが丁度いいんじゃないの?
80~90%ぐらいが

174名無しさん@編集中 (ワッチョイ dec8-u2ln)2017/05/06(土) 10:17:17.95ID:e0PV2k/30
いままで8bitエンコしかして来なかったけどhighDepthオプションつけて10bitエンコにしようかと思うんだが
TS抜きした映像ソースを10bitでエンコする意味ってあるのかな?
TS自体が8bitだった気が・・・

175名無しさん@編集中 (ワッチョイ 12cd-Ogwz)2017/05/06(土) 10:24:24.11ID:D2u31DZA0
なんで10bitエンコがいいのかぐぐればすぐわかること

176名無しさん@編集中 (アウアウウーT Sa43-hyiT)2017/05/06(土) 10:42:00.24ID:oUC6MMIta
>>174
tsそのままだとあまり意味無いね
なんらかの技術で10bit精度に補間したものを改めて10bitで収録し直すみたいな形ならともかく

177名無しさん@編集中 (ワッチョイ 12d4-Ogwz)2017/05/06(土) 11:14:13.52ID:39bf1dhz0
>>174
なかなか面白い理論だ

178名無しさん@編集中 (ワッチョイ dec8-u2ln)2017/05/06(土) 11:42:04.09ID:e0PV2k/30
>>175-177
あっ、なんか意図が伝わってなくてスマソ。アスペなもんで。
8bit深度に大してH.265で採用されている10bit深度の画質的メリットはもちろん理解
しているんですが、ソースが8bit深度の映像を10bitで出力したところで画質向上には
ならないんじゃないかなと思いまして。
いろいろ調べてもTSソースを10bit補間してエンコしたみたいな話は見かけないから
そもそも10bitエンコ自体普及してないのかなぁ・・・
最近閉鎖で騒がれているnyaaとかには10bit精度でエンコされた動画でわざわざ
アップしている職人もいたと聞くが。

179名無しさん@編集中 (ワッチョイ 7fe1-7zcB)2017/05/06(土) 11:43:14.34ID:BycummCk0
hevcかどっちか忘れたけど素のまま10bitエンコするだけでも
多少の良い効果は得られるらしい
だからデメリットはHWデコードが対応してないと重くなるぐらいかな?

180名無しさん@編集中 (ワッチョイ 7fe1-7zcB)2017/05/06(土) 11:49:35.72ID:BycummCk0
onedriveにアドレス残ってた
http://peace.2ch.net/test/read.cgi/avi/1418252184/

ここの70番あたりを読むと8bitソースを10bitなモードでエンコードしても効果あるということらしい

181名無しさん@編集中 (アウアウウーT Sa43-hyiT)2017/05/06(土) 11:51:14.45ID:oUC6MMIta
>>179
それ言う人がいるけど勘違いしてると思うよ
D-A変換されたものがそのまままた10bitにA-D変換されて記録されるだけの事だから
同じD-A変換のアルゴリズムを使ってる限り8bitエンコードも10bitエンコードも変わらないよ

182名無しさん@編集中 (ワッチョイ 7fe1-7zcB)2017/05/06(土) 11:56:52.66ID:BycummCk0
デコードしてもアナログ信号にはならないんじゃ?

183名無しさん@編集中 (ワッチョイ 1272-VjVX)2017/05/06(土) 11:58:20.20ID:zOt9cvyd0
jpegをjpegで圧縮するような状態だったのを
jpegをpngで圧縮する程度の効果はあるってことではないの

184名無しさん@編集中 (ワッチョイ de7e-Ogwz)2017/05/06(土) 12:01:33.55ID:s7pzBEcM0
主にアニメとかでバンディングを軽減するため10bitでエンコするんだよ
なので、バンディングが気にならない人は、やる必要はあまりないかと

理屈はともかくいろんな人が検証した結果効果があると認められてる
まあ、自分で試してみればいい

185名無しさん@編集中 (アウアウウーT Sa43-hyiT)2017/05/06(土) 12:09:35.26ID:oUC6MMIta
色深度の話は圧縮とは別で
たとえ可逆圧縮だったとして8bitを10bitで記録しても8bitの深度にしかならないよ
>>180で展開されてるのはデコード時のディザの話で
これはつまりデコード時にディザを付加してるのだからデコーダーの補間の話になる
このデコーダーで8bit映像をデコードするのとそれを10bitで縁jコードした映像は変わらない
つまりこのデコーダーを使う限り8bitのソースで充分という事になる

186名無しさん@編集中 (アウアウウーT Sa43-hyiT)2017/05/06(土) 12:18:26.14ID:oUC6MMIta
>>184
8bitの元ソースを8bitでエンコードしてバンディングが出るのはビットレートが低すぎるからだろう
近似値の平滑化の度が過ぎて目で見て分かるほど差が出てしまったという事だ
10bitでエンコードするよりその分8bitでビットレートを高くした方が良いと思うがな

187名無しさん@編集中 (ワッチョイ de7e-Ogwz)2017/05/06(土) 12:33:19.85ID:s7pzBEcM0
まあ、そう思うのは自由

188名無しさん@編集中 (ワッチョイ 9272-37K/)2017/05/06(土) 13:57:53.04ID:mHEFOYoh0
flash3kyuuDeband()
dfttest()
smoothgrad()
GradFun3()
このあたり使えば、補間してくれるよ

189名無しさん@編集中 (ワッチョイ dec8-u2ln)2017/05/06(土) 14:05:41.78ID:e0PV2k/30
>>188
()がつくということは失笑するレベルなのか。

190名無しさん@編集中 (ワッチョイ 9272-37K/)2017/05/06(土) 14:10:47.29ID:PeTSKErj0
ミーム汚染だ

191名無しさん@編集中 (ワッチョイ de79-W+y+)2017/05/06(土) 14:17:17.40ID:QiKKyfSe0
>>189
マジで言ってるのかAviSynth知らないのか判断に迷う

192名無しさん@編集中 (ワッチョイ 9272-37K/)2017/05/06(土) 14:18:00.36ID:mHEFOYoh0
>>188
関数だからやぞ
avisynthの

193名無しさん@編集中 (ワッチョイ 4b94-pIlU)2017/05/06(土) 14:19:14.61ID:2p+oHv330
おお…

194名無しさん@編集中 (ワッチョイ de79-W+y+)2017/05/06(土) 14:22:31.95ID:QiKKyfSe0
生tsが

195名無しさん@編集中 (ワッチョイ 7fe1-7zcB)2017/05/06(土) 15:43:21.65ID:BycummCk0
な、懐かしい流れ
数年ぶりな気がする

196名無しさん@編集中 (ワッチョイ 16b9-Ogwz)2017/05/07(日) 17:36:52.55ID:IeCbXKOD0
失笑って発想はなかったわw

19732 (ワッチョイWW 16e2-zpXK)2017/05/08(月) 07:50:55.40ID:6610UigA0
>>184
lavつかって再生すると、結局あんまりでないんだよなぁ

198名無しさん@編集中 (ワンミングク MM42-WHOc)2017/05/08(月) 08:34:16.75ID:gNgcHkdkM
バンディングはmadVRでもかなり抑えられるしな

199名無しさん@編集中 (ワッチョイ 16a3-W+y+)2017/05/08(月) 21:16:52.82ID:6/2ByMXh0
>>186
8bitでバンディングを出なくするにはディザを残す必要があるからBD並みのビットレートが必要
少なくともフルHDで10Mbps以上。x264だとcrf=12程度が限界
だからTSを圧縮するには実質的に使えない

200名無しさん@編集中 (ワッチョイ 7fe1-7zcB)2017/05/08(月) 23:25:36.38ID:fN8ySGc20
ジョーク乙

201名無しさん@編集中 (ワッチョイ 07a4-kvD5)2017/05/22(月) 11:29:16.71ID:GZMyMciJ0
r2829
x86のAVX-512がらみが多くて殆ど関係ないかな

202名無しさん@編集中 (ワッチョイ dea3-cm4/)2017/05/22(月) 17:20:32.96ID:U7KhlFgq0
Xeon Phi用?

203名無しさん@編集中 (ワッチョイ 6794-kLyQ)2017/05/22(月) 18:26:30.18ID:+CZlsLvY0
commitの内容くらい読んだら

204名無しさん@編集中 (ワッチョイ dea3-cm4/)2017/05/22(月) 23:59:56.47ID:U7KhlFgq0
そうだったら面白そうだったのに違うのか。発売まであと1ヶ月ちょっと

205名無しさん@編集中 (ワッチョイ 6be1-bwHs)2017/05/23(火) 09:39:19.86ID:Mmk8+JSl0
なんかAVX512にもいろいろなバージョンがあるらしい

206名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ 3ad4-p4im)2017/05/23(火) 11:16:16.33ID:7zgCm2Fx0
AVX-512に対応しても、256bitを2クロックで実行だったらあまり意味がなさそう

207名無しさん@編集中 (アウアウカー Sacb-+Mvj)2017/05/23(火) 12:39:38.16ID:GV0woxuQa
>>205
今のところ2種類だよね
Phiと、これから出るSkylake(Kabylake)-X
違ったら訂正よろ

208名無しさん@編集中 (ワッチョイ 9fce-yauO)2017/05/26(金) 14:50:30.90ID:Mh7fDvUt0
>>174
テレビは8bit
ブルーレイは10bit

これが基本

209名無しさん@編集中 (ワッチョイ bb93-/6qz)2017/05/26(金) 20:40:12.96ID:MHU9y7Qv0
メガドライブは16bit

210名無しさん@編集中 (ワッチョイ 0fa3-/6qz)2017/05/26(金) 22:07:25.45ID:unoKqH810
>>208
ブルーレイも8bitだろ

211名無しさん@編集中 (ワッチョイW ef8b-Kfqe)2017/05/26(金) 23:34:59.38ID:IXEtfAo30

212名無しさん@編集中 (ワッチョイ 0fa3-/6qz)2017/05/27(土) 00:28:02.17ID:KXKBbCuQ0
>>211
マジかw よく見たら俺の持ってるUB90も対応してたわwww
これをデコードできるソフトがあるのか知らんけど

213名無しさん@編集中 (ワッチョイW ef8b-Kfqe)2017/05/27(土) 01:49:30.71ID:sgij9sLk0
ジブリとか

214名無しさん@編集中 (ワッチョイ 0fa3-/6qz)2017/05/27(土) 02:22:49.77ID:KXKBbCuQ0
そういう意味じゃなくて、MGVCのtsをx264でエンコするために12bitデコードできるPC用のプログラムが手に入るのかって話

215名無しさん@編集中 (ワッチョイ ef79-/6qz)2017/05/27(土) 02:28:51.98ID:yOi/kiCt0
>MGVCのサブストリームデータには特別な暗号化が施されており、これをデコードするためには、ハードウェア側にカギを仕込む必要がある。
と書かれているがPCでできるのかな

216名無しさん@編集中 (ワッチョイ 0fa3-/6qz)2017/05/27(土) 02:57:54.84ID:KXKBbCuQ0
まぁパナの一部の機種しかデコードできないようなオレオレコーデックに対応しても旨味がなさすぎるし無理だろう
今ならUHD BDがあるからこんなコーデック使う必要ないし

217名無しさん@編集中 (ワッチョイ fb48-yauO)2017/05/27(土) 03:54:56.54ID:WaAf4/ND0
r2833kMod来てるで

218名無しさん@編集中 (ワッチョイ fb48-yauO)2017/05/27(土) 04:03:02.41ID:WaAf4/ND0
って日本アク禁解除してくれたのね

219名無しさん@編集中 (ワッチョイ 9fcd-9J/J)2017/05/27(土) 07:31:37.05ID:JFb4SnYO0
ほんまや

220名無しさん@編集中 (ワッチョイWW 9fea-39Uf)2017/05/29(月) 01:49:30.77ID:a0uJfekx0
ここで聞くのがいいのか分からんけど、x264の8bitで俺的アニメ最適設定とか実写最適設定的なのを参考までに教えてくれる人いないですか...

221名無しさん@編集中 (ワッチョイ 9fd4-9J/J)2017/05/29(月) 02:13:44.22ID:2fXE0oZU0
わからないならデフォで

222名無しさん@編集中 (ワッチョイ 0be1-yauO)2017/05/29(月) 09:32:10.21ID:t/pwYFLr0
>>220
とりあえずプリセットとプロファイルを指定して
そこれプラス --b 3 --ref3 でBフレームとrefの制限だけしとけばおk
あとおまじないで --aud --nal-hrd も追加しとけばいい

223名無しさん@編集中 (ワッチョイ fb7c-X8Bi)2017/05/31(水) 10:34:57.77ID:8JeQCHhC0
x264guiEx_2.51v2

224名無しさん@編集中 (ワッチョイ bf32-gQJE)2017/06/28(水) 22:42:51.76ID:RVxNfKli0
R2851きてんな

225名無しさん@編集中 (ワッチョイ 4232-POtP)2017/07/03(月) 17:23:55.63ID:EoHdrbIh0
各ビルドも来ましたな

226名無しさん@編集中 (ワッチョイ 0632-wjSU)2017/07/03(月) 22:21:40.62ID:oRGsh6jC0
そういうのは今期入る前にしてくれw

227名無しさん@編集中 (ワッチョイ 0939-WwN4)2017/07/03(月) 22:25:29.32ID:7K3B3cxp0
今ならまだやり直せるぞ

228名無しさん@編集中 (ワッチョイ 0632-wjSU)2017/07/04(火) 02:01:36.14ID:Zsfek4ze0
まあたしかにそうだわ

229名無しさん@編集中 (ワッチョイ c117-CicO)2017/07/04(火) 09:47:04.81ID:kbRsHYbA0
画質的に向上する余地なんてないんだから
気にしなくてもよくね?

230名無しさん@編集中 (ワッチョイ 0632-wjSU)2017/07/04(火) 12:08:01.34ID:Zsfek4ze0
AVX-512関係ばっかりだし
確かに気にしなくて良いんだけどね

日記になってしまうが、
たまたま、今期はバージョンあげようかなとか迷ってたんだよ
ただそれだけさ

231名無しさん@編集中 (ワッチョイ d74f-8cuI)2017/07/08(土) 18:00:56.36ID:a+acXXxz0
x265に乗り換えてからx264の最新ビルドに対する興味が薄くなった。

232名無しさん@編集中 (ワッチョイ 9791-KuRC)2017/07/08(土) 19:47:46.47ID:6acSBIHO0
>>231
嘘つき乙

233名無しさん@編集中 (ワッチョイ f7d0-lfeO)2017/07/09(日) 13:46:24.52ID:Dm7e95yZ0
赤潰れやハイライト削りすぎは改善れれる余地はあるの?

234名無しさん@編集中 (ワッチョイ d739-zXdO)2017/07/09(日) 16:10:15.77ID:orURU0+Q0
赤色が劣化してるように見えるのは色空間の問題が大きいからなぁ・・・
x264だと--chroma-qp-offsetを弄ってみて改善するかどうかじゃないかな

ハイライト削り過ぎってのは分からないけどcrfやaqやpsy-rdの調整でどうにかならない?

235名無しさん@編集中 (ワッチョイ f7d0-lfeO)2017/07/11(火) 10:30:45.47ID:dCODISON0
>>234
赤色の劣化の原因は色空間なの?元画はなんともないのに?
赤の認識は国や地域で大きく違うから、それが反映されて無視されてるのかと思ってた
ハイライト削ると、バンディングもどきが現れたり

236名無しさん@編集中 (ワッチョイW 77ea-Gx3G)2017/07/11(火) 12:04:04.12ID:IJasOprA0

237名無しさん@編集中 (ワッチョイ b7db-zXdO)2017/07/11(火) 22:11:53.59ID:Y5S24hR30
元画も420だと思うが違うのか?

238名無しさん@編集中 (ワッチョイ 6bd0-w0es)2017/07/15(土) 11:33:03.36ID:QOPZli+L0
--chroma-qp-offsetは効果がなかったですね
赤が強いと鮮やかに感じるからx264は低ビットにしても綺麗に見えるんだろうなと勝手に解釈
赤のライト一色のシーンの破綻はきついものがある

元画がフルレンジのケースのことだったの?
jpegだと確かにYUVでもフルレンジ使うけど

239名無しさん@編集中 (ワッチョイ 35db-MRQN)2017/07/15(土) 12:01:33.59ID:3m6njqCx0
サンプルの画像でも貼ってくれないと何のこと言ってるのか分からない

240名無しさん@編集中 (ワッチョイ 0117-S4qQ)2017/07/15(土) 12:09:12.71ID:D4kjNe6l0
有名な話ではあるけど8bit ビデオコーデックの限界でなかろうか
量子化のやつを改変するしかないんじゃね(すごい昔に流行ってた気がする

241名無しさん@編集中 (ワッチョイ f644-A9YL)2017/07/15(土) 12:09:31.23ID:2zI05HpD0
>>238
・元画と言ってるのは、どういうソフト(やカメラなど)でどのように作った映像なのか。RGBなのかYUVなのか。
 >>237が言ってるように元画がYUV4:2:0の映像なら元画の時点で赤の劣化が起きてると思うのだが。
・「ハイライトを削る」とは具体的にどのような処理を行っているのか。

このあたり、ちゃんと詳しく書いた方がいいと思うよ。
あとフルレンジかどうかは今回の件についてはあまり関係ない。

242名無しさん@編集中 (ワッチョイ 35db-MRQN)2017/07/15(土) 13:41:12.57ID:3m6njqCx0
> ハイライト削ると、バンディングもどきが現れたり
読み直したら結局バンディングのことか
エンコしたらディザが消えてバンディングが出てくるから10bitでエンコするっていういつものやつ

243名無しさん@編集中 (ワッチョイ 35db-MRQN)2017/07/15(土) 13:56:32.08ID:3m6njqCx0
バンディングのディザによる解決は害悪だよね
10bit、12bitにすれば解決する問題をビットレート特盛りにして力技で解決
エンコしたら劣化が目立つから初心者にはエンコーダのせいにされてしまう
もっと早くから放送もBDも10bit化すべきだったな

244名無しさん@編集中 (ワッチョイ 6bd0-w0es)2017/07/15(土) 14:45:47.73ID:QOPZli+L0
つくづく、地デジもBDも10bith264と思いきればよかったのにと思う。
家電開発者のインタビュー見てると、高画質をうたってるテレビはほぼ10bit対応と言ってるしね。

245名無しさん@編集中 (ワイエディ MM0a-z+eH)2017/07/15(土) 19:56:53.20ID:82DwIzbfM
BSで新しい衛星を立ち上げて地上波のサイマルをH264使ってやればいいのにな
で、地上波の帯域をスマホとか移動体通信に使う

246名無しさん@編集中 (ワッチョイWW 3a94-kE75)2017/07/15(土) 20:03:20.59ID:iDHnQGIE0
>>245
もし出来たとしても結局版権問題でBSジャパン(テレ東と同時にBSで放送する予定だった)と同じルート辿りそう

247名無しさん@編集中 (ワッチョイ 35db-MRQN)2017/07/15(土) 20:09:49.68ID:3m6njqCx0
BSで4KをHEVCでやるんだから今更必要ないだろ
4Kは10bitだよ。8bitは規格にないからな

248名無しさん@編集中 (ワッチョイ 66ea-qt4g)2017/07/16(日) 05:48:40.57ID:oHYcqkkX0
ハイライトを削るって結局何だったのか

249名無しさん@編集中 (ワッチョイ 4611-k5cp)2017/07/16(日) 10:43:14.36ID:M3psfPBz0
16 : 宇野壽倫の告発2017/07/11(火) 19:22:00.17 ID:5/TEkUSo
皆さん十分にご注意ください
http://ameblo.jp/jcjk-now/entry-12148228389.html
17 : 宇野壽倫の告発2017/07/11(火) 19:22:46.64 ID:5/TEkUSo
死ね!キモブサ川高志!!

250名無しさん@編集中 (ワッチョイ f644-A9YL)2017/07/16(日) 19:40:58.06ID:HpejTqPk0
ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
 http://egg.2ch.net/test/read.cgi/jisaku/1460032466/796-797

251名無しさん@編集中 (ワッチョイ 6bd0-w0es)2017/07/17(月) 20:48:45.94ID:8laiMmMa0
エンコの時にハイライトを捨ててるんだろう
ハイライト自体がわからんなら説明のしようがない

252名無しさん@編集中 (ワッチョイ 4644-A9YL)2017/07/17(月) 20:58:05.21ID:RzYBtVR60
>>251
「だろう」って、「ハイライト削りすぎ」という表現を持ち出したのはお前さんなのに、なぜ他人事・・・。
個人的にはカラーグレーディングで高輝度部分をちょっと下げたみたいなことを連想してたけど
「エンコの時にハイライトを捨ててる」ってのが何を指してるのかさっぱりわからん。

253名無しさん@編集中 (ワッチョイ 35db-MRQN)2017/07/17(月) 23:07:12.77ID:koURX1Uq0
自分の世界しか見えてないから他人に説明できないんだよ。きっと

254名無しさん@編集中 (ワッチョイ 7e32-S4qQ)2017/07/19(水) 11:46:55.18ID:TJhHh62l0
ハイライトは最も明るく目立つ部分だから白付近をごっそりクリップしたんじゃないの
俺にはその処理にデメリットしか感じないけどそいつなりに意味があるんだろうし好きにすればいいよ

255名無しさん@編集中 (ワッチョイ 66ea-qt4g)2017/07/19(水) 17:32:07.21ID:EfL8exLW0
> 白付近をごっそりクリップ
ごっそりクリップってなんや・・・

256名無しさん@編集中 (ワッチョイ 0117-S4qQ)2017/07/19(水) 18:38:31.40ID:82aWZrRs0
自演じゃあるまいし
大したことないネタに反応しなさんな

257名無しさん@編集中 (ワッチョイ 6f4f-pmGF)2017/07/19(水) 20:21:16.53ID:oXVd+d990
目玉のおやじの白い部分をごっそりクリップするとグロ映像になるよな

258名無しさん@編集中 (ワッチョイ 66ea-qt4g)2017/07/19(水) 20:44:28.35ID:EfL8exLW0
>>257
もともとグロ説

目立つところをおかしくするのって、psy-rdを負側にかけるとかそういうトリッキーなオプションじゃないと出来ないのではなかろうか

259名無しさん@編集中 (ワッチョイ 4a06-z+eH)2017/07/19(水) 22:00:05.01ID:WJsftwZt0
mp4boxで複数音声をmuxする場合、lang=jpnで指定してるんだけど、
複数音声が同じ言語の場合ってどうすればいいかな?
langで同じコードを設定するとPS3でうまく言語が切り替わらなくなる。
オーディオトラック1は英語、2は日本語とか、違うコードでは問題ない。

260名無しさん@編集中 (アウアウウーT Sa08-svru)2017/07/19(水) 22:07:40.23ID:6NjQsSJPa
違う言語で割り当てちゃえばいいよ
あれは1番2番と割り振ってるのと同じでただのフラグでしか無い

261名無しさん@編集中 (ワッチョイ 5f91-E/h9)2017/07/23(日) 01:42:18.96ID:xY7oCU1a0
もの凄いボケボケのブロックノイズ塗れになった
と思ったら--crf 210 とかなってたよ(´・ω・`)

262名無しさん@編集中 (ワッチョイ 47d1-QK4i)2017/07/23(日) 11:09:40.44ID:6n3bIMM40
210w

263名無しさん@編集中 (アウアウカー Safb-RwsK)2017/07/23(日) 12:15:26.24ID:CMOEbANca
crf 210って出来たのか…

264名無しさん@編集中 (ワッチョイ 6739-dw5s)2017/07/23(日) 12:17:01.42ID:keAstF8G0
確か51以上を指定すると51に丸め込まれたはず

265名無しさん@編集中 (ワッチョイ dfef-3g0N)2017/07/23(日) 15:31:22.86ID:R4sZ2XaX0
crfmaxパラメータあたりで上限変えれんじゃね。ゴミ画質に劣化するだけだから誰も触れないけどw

266名無しさん@編集中 (ワッチョイ 4744-3EN1)2017/07/23(日) 17:06:06.84ID:kCVUaSmw0
>>265
-crf_maxも--crf-maxもCRF+VBVの時にRF値を制限するためのオプションであって
--crfで指定できるRF値の上限を変えるもんじゃないだろとマジレス。

>>264が言ってるように、--crfは51以上を指定しても51にされるだけだね。

267名無しさん@編集中 (ワッチョイ 47d1-QK4i)2017/07/23(日) 17:10:17.75ID:6n3bIMM40
rc-lookaheadを300にしてるとか言ってる奴も昔どっかで見たけど250に丸め込まれるよね

268名無しさん@編集中 (ワッチョイ a7db-RieY)2017/07/23(日) 18:51:08.05ID:y76xDWj10
丸め込むwww

269名無しさん@編集中 (ワッチョイ 47d1-QK4i)2017/07/23(日) 19:57:08.39ID:6n3bIMM40
響きが良いよな

270名無しさん@編集中 (ワッチョイ 7f9b-t6T/)2017/07/23(日) 23:25:51.62ID:qmXIkSVi0
丸込め味噌

271名無しさん@編集中 (ワッチョイ 7f91-CrqW)2017/07/24(月) 01:02:59.95ID:5TMClw7W0
マルメコムX

272名無しさん@編集中 (ブーイモ MM8b-oZ9i)2017/07/24(月) 07:34:49.14ID:R5b7QqQjM
クリッピングの意味で丸め込むってウチでも使うけど、そんなに変か?

273名無しさん@編集中 (アウアウウーT Sa6b-rqTR)2017/07/24(月) 08:10:53.46ID:iWTL2Muga
いys,別におかしくは無い

274名無しさん@編集中 (ワッチョイ a717-QK4i)2017/07/24(月) 09:55:51.70ID:j+q0aY7l0
草はやされるほどおかしいとは思わないが
クリッピング(切り捨て)を丸め込むとは言わないかな(自分なら

275名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ 7f91-dkZs)2017/07/24(月) 10:00:00.79ID:6pYv2j8E0
どちらかと言うとroundingの感じ

276名無しさん@編集中 (ワッチョイ 47d1-QK4i)2017/07/24(月) 17:08:27.73ID:sOZIAhU50
このスレもどんどん丸め込んでいこうぜ

277名無しさん@編集中 (ワッチョイ dfe2-/jiT)2017/07/24(月) 18:29:42.17ID:snuqTaT40
>>267
これ本当?

278名無しさん@編集中 (ワッチョイ 4744-3EN1)2017/07/24(月) 18:47:51.52ID:0kMaYgwF0
>>277
試してログ見れば本当だってすぐにわかるだろ。疑うくらいならさくっと試しなよ・・・。

279名無しさん@編集中 (ワッチョイ 47d1-QK4i)2017/07/24(月) 20:08:14.89ID:sOZIAhU50
>>277
rc-lookaheadはkeyintと同じ数値までか、250までだったと思うよ。
keyintが300だったとして、rc-lookaheadも300にしても250まで丸め込まれちゃうはず。
keyintが120なのにrc-lookaheadを250とかにしても「keyintまで」のはずだから、この場合もrc-lookaheadは120に丸め込まれちゃうはず。

間違えてたらごめンゴ

280名無しさん@編集中 (ワッチョイ dfe2-/jiT)2017/07/24(月) 21:06:26.15ID:snuqTaT40
さくっと試したら>>267>>279の言う通りだった
どうもです

281名無しさん@編集中 (ワッチョイ bf39-dw5s)2017/07/25(火) 21:52:32.18ID:v9eI6NJr0
x264 sandboxによるとx264が大きく変わるようだ
1つのバイナリで8bit/10bitを切り替えて出力できるらしい
切り替えには--output-depthを使うようだ

この変更でソースの構造が大きく変わってx264 mod版に充てられてるパッチが殆ど使えなくなるんで
mod版ビルダーの更新が遅れるかもしれない

282名無しさん@編集中 (ワッチョイ dfef-3g0N)2017/07/26(水) 14:20:37.34ID:WcuuDM2d0
そういう動画はプレイヤーによっては再生できなくなるんじゃね。
たとえばスマホとかゲーム機とか

283名無しさん@編集中 (ワッチョイWW 6700-RYCd)2017/07/26(水) 14:23:24.71ID:EsczvBkX0
エンコ時間ヤバそう

284名無しさん@編集中 (ワッチョイ dfef-3g0N)2017/07/26(水) 14:28:30.91ID:WcuuDM2d0
スマホやゲーム機は10bit/12bitの動画とかHWデコーダが対応してないからSW再生しかできないんだよな
特にスマホはCPUの性能がカスだから、コマ落ち&音ズレ&ブロックノイズだらけで悲惨なことにw

285名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ 7f91-dkZs)2017/07/26(水) 17:22:46.73ID:DLRRNfaO0
H.265 Main 10に対応したハードウェアデコーダーは増えてきているけど、H.264 High 10に対応する物は一向に増えないな

286名無しさん@編集中 (ワッチョイ 4744-3EN1)2017/07/26(水) 17:54:08.90ID:YGph3AEt0
>>285
増えるも何もH.264の10bitのHWデコードに対応してる物なんて無いんじゃ?DXVAの規定も無い。

287名無しさん@編集中 (アウアウウー Sa9f-/uhd)2017/07/27(木) 09:39:48.43ID:sjopS/xXa
ピンク色をエンコードすると

どんなにCRFが高くても色合いが変わって
ピンクの周辺にブラウン管時代の偽色みたいなもんが出るんだけど回避できない??

動画として見るとチラチラと色が変わって目によろしくない

288名無しさん@編集中 (アウアウウー Sa9f-/uhd)2017/07/27(木) 09:44:57.70ID:utTRrNsfa
低くても、か
12とか15でやってもピンク色が変になり
2でやっても同じ

289名無しさん@編集中 (スップ Sd2a-Lvg/)2017/07/27(木) 10:40:31.42ID:8W60h2thd
ないわ、それ元から単色でピンク色なのか?

290名無しさん@編集中 (ワッチョイ 7b17-ZO1u)2017/07/27(木) 12:03:39.98ID:nXagFz4P0
RGB -> YUVへの減食ミスとかじゃね
自分はそっち方面に詳しくないから的外れ化もしれないけど

291名無しさん@編集中 (ワッチョイWWWWWWW)2017/07/27(木) 12:17:07.60ID:LQj6bobK0
固定品質のQP0(可逆)でもそれがでるのかどうかを確認しよう
あとはYV12なのかYUY2なのかそれ以外なのか

292名無しさん@編集中 (アウアウウー Sa9f-/uhd)2017/07/27(木) 12:19:34.02ID:0OZcuULva
http://www.rupan.net/uploader/download/1501125272.zip
パスワード abcd

こんな感じ

尼子の文字の隣にある家紋色が違ってしまい
動くとチラチラして見える

ピンクかと思ったら拡大したら群青とオレンジだった

293名無しさん@編集中 (ワッチョイ eaea-AvKj)2017/07/27(木) 12:32:38.83ID:K7BmCOMY0
>>290やな

AviUtl使ってるならUVダウンサンプリングフィルタを使うとマシになるかもしれない

294名無しさん@編集中 (アウアウウー Sa9f-/uhd)2017/07/27(木) 12:36:17.13ID:ybI0Iwdva
ログを見るとYUY2 -> nv12pになってる

キャプチャソフトはfraps
これの内蔵CODECだと思うけど圧縮録画されているソース

QP 0 にしても違う色になりますな
なんかソースよりクッキリしてるのが妙なんやけども

295名無しさん@編集中 (アウアウウー Sa9f-/uhd)2017/07/27(木) 12:56:02.21ID:ybI0Iwdva
UVダウンサンプリングフィルタをやってみたところ、
群青色の部分がおかしいもののオレンジ色の部分は遥かにマシになりましたわ

どもどもみんなありがとう
x264でなくまさかaviutlの色変換のほうの話だったとは
ここら自分もあまり詳しくないもんで

296名無しさん@編集中 (ワッチョイ 2a11-VRLg)2017/07/27(木) 18:24:43.14ID:ApvsFLE00
Aviutlって普通にエンコしても黄色っぽくなるんじゃないの
それ調整する為にいつもYC伸張で0-245-13-8補間なしで適当に調整してるわ
フィルターとか使い方よくわかってないから参考にならないだろうけど
これでTSファイルなら元とエンコと色ほぼ同じノイズとか他の要素でじっくり見たら多少違うこともあるだろうけど
比較しても色あせ感はないように思う
他の設定が間違っててこんな調整が必要なのかもしれないけどw
最初色調整とかしてたけどそれだとfpsが負荷おおきいからこれにでやってる
スレチでした すみません
なんかオレンジよりみどりが違う気がしたから自分も最初色の違いでみどりとか黒系がちがう気がして
これにしてる

297名無しさん@編集中 (ワッチョイ 7b17-ZO1u)2017/07/27(木) 18:56:12.32ID:nXagFz4P0
>>295
aqもpsyも0.2ぐらいまで下げてもいいはず

298名無しさん@編集中 (スップ Sd2a-Lvg/)2017/07/27(木) 20:29:50.61ID:o8yj8BJid
俺も色調整は再生時にする様にしたわ

299名無しさん@編集中 (ワッチョイ ce32-ZO1u)2017/07/28(金) 01:13:43.98ID:whDN0SiA0
読んでると色変換設定ミスの可能性高いな
詳しく知りたきゃaviutlスレ訪ねたほうがいい

300名無しさん@編集中 (ワッチョイ 4f44-2AKC)2017/07/28(金) 02:01:37.70ID:w5umuGab0
>>295 >>299
なんとなく解説画像作ってみた。
FrapsのFPS1コーデックは変に古いものを使ってでもいない限りRGB形式らしい。
AviUtlはRGB→(YC48)→YUY2変換時に左側の色差だけ取るので
RGBソースの場合はUVダウンサンプリングとかで平均色差をとった方がいいよという話。

 RGBソースをAviUtlでエンコする場合はUVダウンサンプリングで平均色差とった方がいいよというお話
 x264 rev43©2ch.net	->画像>97枚

あと、>>292のencoded.bmpが変に明るくなってるのが気になった。
多分再生ソフトか何かで色補正が効いてる状態で撮ったもんだと思うけど、
サンプルとして出すには不適切なので、AviUtlに読み込んで撮ったものとかを出した方がいいと思う。

>>296
>Aviutlって普通にエンコしても黄色っぽくなるんじゃないの

それは無い。どこかしらで何か変なことをしてるだけと思われ。

301名無しさん@編集中 (ワッチョイ 2a11-VRLg)2017/07/28(金) 02:08:12.93ID:69plILf20
自分は分ってる風だけのスレなんて無駄じゃないか
どうせ書くならヒントくらい書くべき
エンコってそもそも圧縮するときに色も変わる(元から劣化)それをかわすのにフィルター使うじゃん

302名無しさん@編集中 (アウアウカー Safb-Kwif)2017/07/28(金) 02:12:25.95ID:8K0HBSqoa
スレェ…

303名無しさん@編集中 (ワッチョイ eaea-AvKj)2017/07/28(金) 02:16:05.63ID:mesdGCzp0
何もフィルターかけてないのに色が変わるんだったら可逆圧縮なんて成り立たないでしょうに
colormatrixの設定が間違っているとかじゃないの?

304名無しさん@編集中 (ワッチョイ 66ea-p5D+)2017/07/28(金) 04:12:38.43ID:NMMi0SW90
ゲームのエンコの時は「拡張色調補正」の「TV -> PC スケール補正」をONにする必要があったと記憶している

それより横に少しだけ引き伸ばしてるのが最高に気持ち悪い

305名無しさん@編集中 (ワッチョイ ce32-ZO1u)2017/07/28(金) 05:13:52.64ID:whDN0SiA0
PCスケール補正ONとかそんな地雷情報誰が流布しているんだろうな
RGB->YUVをストレート変換しているのと同義でたぶん>>292のencoded.bmpみたいに明るさや色が変わる
色変わろうがそれでいいってんなら俺がとやかく言うことじゃないけど

てかスレチすぎる

306名無しさん@編集中 (ワッチョイ 2aea-zURC)2017/07/28(金) 08:38:39.66ID:KZhqFr090
そもそもORIG.bmpが正しいやり方でキャプったのかっていう問題がある
適当なプレイヤーのキャプ機能だとレンダラの影響を受けておかしくなることがある
やけに色褪せて見えるのが怪しい

307名無しさん@編集中 (スップ Sd2a-Lvg/)2017/07/28(金) 10:47:57.86ID:RS92JaZKd
もう終わった話を広げるな

308名無しさん@編集中 (ワッチョイ 7b17-ZO1u)2017/07/28(金) 12:46:07.10ID:tEyRGlbz0
>>300
黄色かどうか忘れたけど変わるよ
元ソースと比べないと分からないレベルだけど

>>304
Y/C伸長がいるのはリミテッドな色空間で出力したゲーム動画をRGBで録画したときだけで
PCゲームの内部キャプチャ、フルレンジ出力したものをRBGで録画したときは不要

309名無しさん@編集中 (アウアウウーT Sa9f-Yg6j)2017/07/28(金) 14:16:49.16ID:grmRJ39fa
うーん、h264はYUV420でエンコードするのが殆どだから>>292みたいな元画との差異の追求の話をするには
RGBに比べてYUVは色情報での解像度が低くなるとかの知識は共通認識で持っていた方が良いと思うので
テンプレに追加した方が良いのでは無いか

310名無しさん@編集中 (ワッチョイ af44-2AKC)2017/07/28(金) 15:47:50.94ID:/FJ+xJQY0
>>308
> 黄色かどうか忘れたけど変わるよ

変わらんでしょ。そんな問題があるなら重要情報として広く知られてるはずだし、
 ・そもそもソースの確認の仕方がおかしい
 ・入力プラグインの設定がおかしい
 ・入出力色空間の設定がおかしい
 ・colormatrixとかの設定がおかしい
 ・再生環境がおかしい
といったミスをしてるか、過去にあった何かしらのバグの話と混同してるか、
>>300で書いたような色変換時に必然的に起こる変化のことを勘違いしてるといったところでは。

>>309
さすがにテンプレにはいらないと思う。昔は色空間スレってのがあってそのログも色々参考にさせてもらったけど、
過疎スレだったし今更立てても需要は無いだろうし。

311名無しさん@編集中 (ワッチョイ 2a11-VRLg)2017/07/28(金) 16:51:41.77ID:69plILf20
>>310
ミスじゃないでしょ だからただん劣化の比喩表現
自動という素人でもできるエンコでどうやって間違えるんだ
同じモニター同じデコードで比べても色は劣化してるだし
劣化という表現を色がおかしいという言葉で言うのが問題なら訂正する
でもわかりそうなもんだけどな

312名無しさん@編集中 (ワッチョイ af44-2AKC)2017/07/28(金) 18:19:52.44ID:/FJ+xJQY0
>>311
何を言いたいのかよくわからない。「自動という素人でもできるエンコ」というのが
「特に何も考えずにAviUtlに放り込んでエンコ」ってことなら、それこそが問題であって、
「使い方がよくわかってなくて設定が間違ってるかもしれない」という初心者(素人)が
間違えることがある要素が>>310に書いた内容。

劣化の比喩表現と言ってるのもよくわからない。x264のエンコードによって劣化が起きてボケたり
微妙な色変化が起きたりすることはあるだろうけど、それはAviUtlに問題があるからではない。

「同じモニター・同じデコードで比べても〜」と言ってるけど、colormatrixを間違えてれば
そこで変わるし、レンダラのバグやDXVA、GPUとの相性等で色が変わってしまうこともある。
そういった要素を極力排除して正しい条件で比較する必要がある。
AvsPmodやAviUtlで適切な入力プラグインで適切な設定で読み込んで比較するといった形が望ましい。

ということで、結論としては一連の設定や確認の中のどこかでミスしてるだけだと思うよ。
AviUtlに問題があるわけじゃない。

313名無しさん@編集中 (スップ Sd2a-Lvg/)2017/07/28(金) 18:24:49.11ID:RS92JaZKd
こういう切りない無駄な言い争いになるから辞めろって言ったんだ

314名無しさん@編集中 (ワッチョイ 2639-l5iw)2017/07/28(金) 18:26:57.66ID:xtqHRxYB0
何にせよもう終わった話だしAviUtlはスレチだからこれで終わり

315名無しさん@編集中 (ワッチョイ af44-2AKC)2017/07/28(金) 18:43:20.71ID:/FJ+xJQY0
そだね。何かあればAviUtlスレの方でテンプレの情報出して質問してくれればなるべく対応しま。

316名無しさん@編集中 (ワッチョイ 2a11-VRLg)2017/07/28(金) 18:55:44.95ID:69plILf20
うざ

317名無しさん@編集中 (ワッチョイ 2e91-V1Wy)2017/07/28(金) 20:23:33.33ID:hRx+DSbV0
>>316
お前の脳味噌が劣化、というか頭がおかしい

318名無しさん@編集中 (ワッチョイ)2017/07/28(金) 20:25:43.70ID:0Ig3GpzJ0
構っちゃだめよー

319名無しさん@編集中 (ワッチョイ 7b23-ZO1u)2017/07/29(土) 00:52:28.71ID:3sBlT6oY0
無知蒙昧を相手にするのは疲れる

320名無しさん@編集中 (オイコラミネオ MM4b-vqKT)2017/08/04(金) 03:23:17.34ID:S1K7a/XdM
将来的にTMPGEncあたりがUltra-HD Blu-rayオーサリングに対応しそうだから規格準拠した10bitx265でつくっておきたい
けど、規格書とx265のコマンドライン見比べたらまだ対応してないっぽい

規格書には1080pのH.264も使えるって書いてあるから、ビット深度以外全部従来のBlu-ray準拠設定のx264で多分行けると思うけど

321名無しさん@編集中 (ワッチョイ 0d17-/FH4)2017/08/04(金) 23:34:32.29ID:ZTZ+gYb+0
しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1 aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな>aq-mode3

322名無しさん@編集中 (ワッチョイ 0d17-/FH4)2017/08/04(金) 23:34:54.75ID:ZTZ+gYb+0
x265と間違えました

323名無しさん@編集中 (ワッチョイW db2e-4egz)2017/08/04(金) 23:54:02.49ID:qrQ5Qflc0
>>320
録画規格ないのに対応するとは思えん

324名無しさん@編集中 (ワッチョイ 814f-KmJS)2017/08/09(水) 15:58:13.85ID:K4o/tiYa0
BDRIPの動画を8bitでエンコするやつの気が知れない。

325名無しさん@編集中 (ワッチョイ 5791-dE0h)2017/08/09(水) 16:02:33.01ID:cIIO/eWe0
BDなんかわざわざRIPしてエンコする馬鹿の気が知れない。

326名無しさん@編集中 (オイコラミネオ MM4b-vqKT)2017/08/09(水) 16:03:33.06ID:B4PTzTTuM
ソースが8bitだから再エンコはバンディング低減効果しかない、というかそれが目的でしょ
最初から10bitまで対応でブルレイ規格作っとけばこういうことにはならんかったけども

まあ、どーせBDMV準拠で流さないんだから10bitでエンコして流せとは思う

327名無しさん@編集中 (ワッチョイ 3b39-/FH4)2017/08/09(水) 16:05:38.31ID:2AJnt09p0
いちいちBDをケースから引っ張り出すの嫌だから
エンコしてHDDに入れてるわ

328名無しさん@編集中 (ワッチョイ 09db-oL0b)2017/08/18(金) 03:37:46.14ID:u9qCreim0
x264で解像度の違う2つの動画をエンコしてa.264とb.264を得たとする
これをL-SMASHで連結したいんだけど以下の手順で合ってる?

copy /b a.264 + b264 c.264
muxer -i c.264 -i 音声ファイル -o out.mp4

これで作ったmp4をmpc-hcとps3で再生してみたけど問題なかった

329名無しさん@編集中 (ワッチョイ 391d-+7xG)2017/08/19(土) 18:17:22.65ID:YzeVzrl00
うっさい!ハゲ

330名無しさん@編集中 (ワッチョイ 5100-oL0b)2017/08/19(土) 21:27:33.98ID:VsDsEh6v0
"問題が無かった"という証明が出来ない

331名無しさん@編集中 (ワッチョイ 8117-oL0b)2017/08/19(土) 23:44:49.40ID:R/l9dL2C0
muken氏か聞いたら発狂しそうではある

332名無しさん@編集中 (ワッチョイ 114f-FUr6)2017/08/19(土) 23:55:11.53ID:JW4EweBA0
盛大に音がズレそうな構文だなw

333名無しさん@編集中 (ワッチョイ 09db-oL0b)2017/08/20(日) 21:20:22.86ID:iNj0lnL80
問題なかったって言うのはウソだった

ps3だと1440x1080と1920x1080の組み合わせなら大丈夫だったけど
1440x1080と1280x720だとダメだったわ
mpc-hcならどっちも大丈夫だった

で、オンラインのmp4parserでmp4ファイル見てみたけど、
Sample Description Boxにサンプルエントリが2つあるのは良いんだけど
どっちもwidhとheightが同じだったorz

AVCコンフィグレーションボックスの方はちゃんと違うデータになってたから、
SPSやPPSは合っててそれを読めばデコードはできるのかも

L-SMASHは途中でSPSやPPSが変わるのは対応してるけど
画面サイズが変わるのには対応してないってことかな

334名無しさん@編集中 (ワッチョイ 93ea-wwH0)2017/08/20(日) 22:22:34.58ID:vpjeEVa50
>>333
無茶苦茶なことやるなあ
muken氏が血を吹いて死ぬぞ

335名無しさん@編集中 (ワッチョイ 09db-oL0b)2017/08/20(日) 23:47:46.91ID:iNj0lnL80
ps3の限界を探ってみた結果、2つのストリームのlevelが同じなら
画面サイズやエンコ設定(mediumとslowerとか)が違くても再生できることが分かった

1440x1080と1280x720はlevel自動にしてたから結果違うlevelになって再生できなかったけど
4.1に統一したら再生できるようになったわ

L-SMASHだとサンプルエントリのwidth,heightがデタラメな値になるけど問題ないっぽい

>>334
発端は分割エンコで--stitchable付けなかったらどうなるんだろうっていうのを確かめたかったんだよね

同じ画面サイズ・エンコ設定でも分割ごとにPPSが変わるが、
L-SMASHは複数のサンプルエントリを置くのに対応してるから
規格上は問題ないMP4が生成されるはずで、
ちゃんと実装されてるプレーヤーなら問題ないっていうのが俺の中での結論

まぁ、win10デフォのプレーヤーだとサンプルエントリが2つ以上あるmp4はどれも再生できなかったが・・・

で、それができるんなら、画面サイズやエンコ設定が違くても、できるんじゃねって思ってやってみた

336名無しさん@編集中 (ワッチョイ 114f-FUr6)2017/08/21(月) 20:03:22.75ID:8aQPMi1C0
つーか、MP4コンテナにこだわる意味ってあんの?

337名無しさん@編集中 (ワッチョイ 09db-oL0b)2017/08/22(火) 00:16:45.60ID:kQJmpuZI0
>>336
他に何かある?
ちなみにmkvは試したけど↓こうなった

>mkvmerge.exe --append-to 1:0:0:0 -o out.mkv a.264 + b.264
mkvmerge v15.0.0 ('Duel with the Devil') 64-bit
'a.264': Using the demultiplexer for the format 'AVC/h.264'.
'b.264': Using the demultiplexer for the format 'AVC/h.264'.
'a.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
'b.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
Error: The track number 0 from the file 'b.264' cannot be appended to the track number 0 from the file 'a.264'. The width of the two tracks is different: 1440 and 1280

残念!

338名無しさん@編集中 (ワッチョイ ed96-oKtA)2017/08/27(日) 17:47:03.79ID:LHzl8Vgr0
書き込みテスト

339名無しさん@編集中 (オイコラミネオ MMce-3mYz)2017/08/27(日) 17:53:07.05ID:5ula7e/yM
CPU能力有り余っててsubme=11を常用してたけど、10に変更したら主観的に画質レートエンコ速度が良くなった
11ってまだ実験的レベルなのかね

340名無しさん@編集中 (ワッチョイ b500-2x4P)2017/08/27(日) 20:20:15.47ID:c4MX+NAU0
画質レート速度ってなに?

341名無しさん@編集中 (オイコラミネオ MMce-3mYz)2017/08/27(日) 20:31:15.94ID:a38KtlYJM
>>340
画質(、ビット)レートって意味ね

342名無しさん@編集中 (ワッチョイ 09d0-prRB)2017/08/28(月) 11:02:53.88ID:pvNM6gxN0
俺も意味不明
エスパーすると同じcrfだと、画質が良くなり、エンコ速度も速いてことか?
doomで散々議論されてる

343名無しさん@編集中 (スプッッ Sdca-iQNi)2017/08/28(月) 11:11:13.36ID:SOh7kOB8d
限界まで圧縮高めればノイズも出易い
サイズが縮まるのと画質が良くなるのはイコールじゃないって事

344名無しさん@編集中 (ワッチョイ c691-0DEe)2017/08/28(月) 13:16:42.94ID:Ub5w0giJ0
submeを「限界まで圧縮高める」ものだと思ってるのか

345名無しさん@編集中 (スプッッ Sdca-iQNi)2017/08/28(月) 15:38:17.72ID:SOh7kOB8d
>>344
サブピクセルに対して動き予測を行う精度が高い→圧縮率を高める可能性がある→高圧縮

無能で理解できてない癖に揚げ足取ってる俺カッケーってかwww

346名無しさん@編集中 (ワッチョイ ca91-vgeI)2017/08/28(月) 16:28:10.48ID:qwDzXc8E0
それは副次的効果ではなくて?

347名無しさん@編集中 (ワッチョイ ad23-2x4P)2017/08/28(月) 16:36:11.28ID:bWNdGo2i0
どうやらsubme上げると圧縮高まってノイズが出やすいらしい
新説だなww

348名無しさん@編集中 (ワッチョイ ad17-2x4P)2017/08/28(月) 16:43:47.58ID:DgDXaiGa0
けど実際にガッツリ削れてブロックノイズが出たた気がする

349名無しさん@編集中 (ニククエ b500-2x4P)2017/08/29(火) 19:16:36.73ID:u78OskKI0NIKU
submeなんて「ソースによる」としか・・・。
別に11だけに限らず、「7より8にしたほうがエンコ速度が速くなった」とか過去に自分もあったし・・・。

350名無しさん@編集中 (ニククエ 1a91-2x4P)2017/08/29(火) 22:59:28.55ID:OU+HHEG/0NIKU
自分の目にはsubmeは9が一番画質いいように見える

351名無しさん@編集中 (ニククエ ca91-vgeI)2017/08/29(火) 23:40:18.88ID:LXi6ZFDZ0NIKU
安定の9か

352名無しさん@編集中 (ワッチョイ 4aea-CSD/)2017/08/30(水) 21:00:30.31ID:UfARUKXj0
>>349
動き予測妥協してるんだから速度は早くなるだろ

353名無しさん@編集中 (ワッチョイ 4aea-CSD/)2017/08/30(水) 21:02:48.54ID:UfARUKXj0
ごめんなさい
よく読んでなかったです・・・

354名無しさん@編集中 (ワッチョイ b500-2x4P)2017/08/30(水) 21:11:52.23ID:0I7zrm7A0
疲れてるんだなきっと

355名無しさん@編集中 (ワッチョイ cf9b-X0kF)2017/09/01(金) 11:28:46.66ID:6GYB47wg0
昨日久々にaviutl一から環境作り直したけど
エンコした動画重い設定じゃないのにシークがクッソ重くて参った、なんでや!

356名無しさん@編集中 (ワッチョイ cf91-1tZ2)2017/09/01(金) 12:28:10.60ID:p0ViNu5b0
keyintのデフォ値はなんであんなキチガイみたいな値なんだろうな

357名無しさん@編集中 (スプッッ Sd1f-hmq1)2017/09/01(金) 12:43:57.42ID:BcnMjwRed
ゴミCPU使ってなきゃGOP300でも気にならんがなぁ

358名無しさん@編集中 (ワッチョイ 434f-YFg8)2017/09/01(金) 15:07:10.75ID:98rXXRkg0
デフォだとHEXの7って時点で白けるけどな

359名無しさん@編集中 (ワッチョイ c300-X0kF)2017/09/01(金) 16:48:57.53ID:PPZk2VfG0
>>356
palだかの25fpsの10秒分で250って話らしいね
デフォルトとしては確かに自分も微妙な値だと思うw

360名無しさん@編集中 (ワッチョイ 3344-O4z1)2017/09/01(金) 16:58:46.84ID:ArSPPgcm0
シークの重さなんて、設定とか環境とか使ってる再生ソフト次第でもあるし、それらを明示しないとなあ。

361名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ cf91-dgwg)2017/09/01(金) 18:31:37.76ID:1RZ6jwk90
keyintはBDだと1秒分のフレーム数だし、私もそれに合わせている

362名無しさん@編集中 (ワッチョイ 6317-X0kF)2017/09/01(金) 18:34:08.57ID:u27Ubveq0
BDってOpenGOPなんじゃなかったっけ?

363名無しさん@編集中 転載ダメ©2ch.net (ワッチョイ cf91-dgwg)2017/09/01(金) 18:39:12.41ID:1RZ6jwk90
そうだね。以前はOpenGOPがMP4で定義されていなかったりしたけど、今は特にデメリットを思いつかない

364名無しさん@編集中 (ワッチョイ c300-X0kF)2017/09/01(金) 19:25:35.51ID:PPZk2VfG0
動画配信とかの用途ではopengopを使うと不具合が起きるみたいだね
ローカル保存のエンコードなら基本的にopengopでいいだろうねー

365名無しさん@編集中 (オイコラミネオ MMff-Xtna)2017/09/01(金) 20:50:29.66ID:44WtHh6mM
BDだと最大キーフレームは最大2秒でしょ
60p除く

366名無しさん@編集中 (ワッチョイ 6fa9-uJLR)2017/09/02(土) 00:55:46.68ID:+gf3sPsb0
設定値はfps非依存であるべきだと思う

367名無しさん@編集中 (ワッチョイ b3d0-MmNF)2017/09/02(土) 12:09:42.42ID:XINNvlDB0
釣りか?

368名無しさん@編集中 (ワッチョイ 6fa9-uJLR)2017/09/04(月) 02:11:30.20ID:DviGTLEu0
keyintは最大GOPサイズの指定であって、それ以下でも必要と判断したら勝手にIフレームにするから
ほとんど動かないシーンが長時間続いた場合にどこまでシークしやすくするかを制御するものだろう

>>367
確かに全てがfps非依存であるべきというのは言い過ぎだった(refとかbframesとか)
けどkeyint/min-keyintの用途からいってfps依存にする必要ある?って思うわけよ

369名無しさん@編集中 (ワッチョイ cf91-OrAB)2017/09/04(月) 10:16:11.18ID:r1tNr/2q0
単に最大間隔を広げるだけだと思ってる奴が多いが
実際には「必要と判断する」部分で「直前のkeyからの距離のkeyintに対する比」を使うので
keyintをでかくすると必要な部分にも入りづらくなる

370名無しさん@編集中 (ワッチョイ 7fef-YFg8)2017/09/04(月) 11:31:51.78ID:lpHpIfZE0
というかその必要な部分の判別はどうやってやるの?
それとも思い込み?

371名無しさん@編集中 (ワッチョイ cfe3-70V0)2017/09/04(月) 14:08:59.27ID:ruHSz/Hl0
> それとも思い込み?
こういうことを平気で書く輩に対しては、何も答えたくないだろうな

372名無しさん@編集中 (ワッチョイ ffea-wn1X)2017/09/04(月) 15:24:27.40ID:aLxOvhc00
x264 [info]: frame I:31 Avg QP:31.14 size: 50769
x264 [info]: frame P:1337 Avg QP:33.32 size: 15607
x264 [info]: frame B:2813 Avg QP:33.49 size: 4962
x264 [info]: consecutive B-frames: 10.3% 13.1% 7.8% 25.2% 12.1% 16.2% 6.2% 4.4% 0.4% 1.4% 0.8% 0.6% 0.0% 0.3% 0.0% 0.8% 0.4%

x264 [info]: frame I:49 Avg QP:30.33 size: 48096
x264 [info]: frame P:1472 Avg QP:33.25 size: 14425
x264 [info]: frame B:4233 Avg QP:32.26 size: 3227
x264 [info]: consecutive B-frames: 7.5% 9.7% 5.7% 20.1% 9.4% 13.2% 5.6% 4.2% 1.1% 2.3% 2.3% 1.9% 0.5% 0.5% 1.8% 2.5% 11.8%
同一ソースを動いていないフレームをタイムコードで引き伸ばしたのと、ループして周波数合わせたやつを同パラでエンコしたのだが、
Keyint狭くした方がいいのかな

373名無しさん@編集中 (ワッチョイ 6317-X0kF)2017/09/04(月) 16:16:47.61ID:5HbHCOKD0
>>372
どっちがどっちなのよ
あとx264にわたってるfpsは同じなの?
x264は入力fpsでcrfの品質基準が変わるから注意

374名無しさん@編集中 (ワッチョイ b3d0-MmNF)2017/09/04(月) 16:53:24.96ID:U39geqKR0
>>369
えっ?

375名無しさん@編集中 (ワッチョイ 53db-X0kF)2017/09/04(月) 17:03:06.54ID:zbSjoI0T0
x264ってタイムコード入力できるからfpsって必要ないんじゃないの?
それともタイムコードはレート制御に使われないの?

376名無しさん@編集中 (ワッチョイ ffea-wn1X)2017/09/05(火) 01:27:08.59ID:f5v5/jXG0
>>373
フレーム数を見ていただければ分かるように、上がフレームを削ったもの、下がループしたものです

377名無しさん@編集中 (ワッチョイ 6317-X0kF)2017/09/05(火) 09:48:18.47ID:2RbzhNwm0
>>375
どこまでインテリジェントに対応してくれるんだろう・・
入力されたファイルのfpsが30fpsだった場合、不明・24fpsの場合と比べて
crfの数字に0.2〜0.3ほど内部で増やされるんだけど、その適応もしてくるれるんだろうか

378名無しさん@編集中 (ワッチョイ c300-X0kF)2017/09/05(火) 18:10:54.98ID:9b8xFzve0
>>370
IDRフレームが挿入されるタイミングは、
100 * (1 - (Pフレームのビットサイズ) / (Iフレームのビットサイズ) ) < scenecut * (直前のIDRフレームとの間隔) / keyint
の式で求まるらしい。

IDRフレームってのはH.264/AVCから追加されたフレームで、特定のフラグを持ったIフレームとしても機能するフレームの様だ。
IDRフレームとIフレームしっかり区別して解説しているWEBページは少ないようだ。
ちなみにH.264のGOPの境目はIDRフレームになっている。なのでこれがキーフレームなどと呼ばれる。

さっきの式を計算してもらえば分かると思うが、keyintを大きくすると「直前のIDRフレームとの間隔」が近づきにくくなるので、IDRフレームが挿入されにくくなる。
それを>>369は説明していたのだと思う。

379名無しさん@編集中 (オイコラミネオ MMff-ps44)2017/09/05(火) 19:47:38.56ID:+QVQZVSVM
そのIDRフレームってのは、H.264はIフレームでも前後フレームと関連つけてあるから、関連性をリセットするIフレームってことでしょ?

380名無しさん@編集中 (ワッチョイ 53db-X0kF)2017/09/05(火) 20:21:42.67ID:PONwnECO0
OpenGOPだとIDRフレームは生成されないよ
GOPはあるし、シークできるけどね

381名無しさん@編集中 (ワッチョイ c300-X0kF)2017/09/05(火) 21:19:57.24ID:9b8xFzve0
IDRフレームでしかシークできないわけではないし、OpenGOPは「GOPが無い」わけではないからね。

382名無しさん@編集中 (ワッチョイ 3396-X0kF)2017/09/06(水) 23:29:09.06ID:KzhpnQIy0
誤爆

383名無しさん@編集中 (ワッチョイ 9a11-ShIp)2017/09/07(木) 00:00:38.11ID:qIIhwnZ40
何でyou等はx265を使わないのかne?

384名無しさん@編集中 (ワッチョイ db96-QyhX)2017/09/07(木) 00:33:21.37ID:YqTr/s540
ほっといてくれ

385名無しさん@編集中 (オイコラミネオ MM06-bcz3)2017/09/07(木) 01:40:32.76ID:imulDhe8M
BDMV互換重視してるから
UHD-BDにオーサリング出来るようになってx265がUHD-BDのフォーマットに完全互換出来たら乗り換えるわ
まあ、UHD-BDはインターレースをサポート外したから、インタレ素材は実質アプコンしないといけないからH.265にする意味があんまりなさそう

386名無しさん@編集中 (ワッチョイWW 3b00-C4xf)2017/09/07(木) 01:55:19.43ID:nZ6H3iVe0
単純に再生側でh.265が観れないから

387名無しさん@編集中 (ワッチョイ 3b00-xkdj)2017/09/07(木) 07:09:58.72ID:kv1lC+de0
>>383
使ってるよ
別にこのスレに書いてるからと言ってx265を使っていないことにはならない

388名無しさん@編集中 (ワッチョイ 2317-xkdj)2017/09/07(木) 09:54:51.39ID:+wXPEBFj0
youtubeのことかと思ったらyou達(たち)だったのね

389名無しさん@編集中 (ワッチョイ f6cd-mgMB)2017/09/08(金) 07:40:32.11ID:ghAOL8080
何年も前から使えるなら移行する気満々で環境だけは整えてるけど
使い物にならん、使える環境が激狭いまんまなんでどうにもならん

390名無しさん@編集中 (ブーイモ MMff-VqnV)2017/09/08(金) 07:42:49.16ID:7Btg921qM
できるならH265にしてるだろうけど、エンコードも再生もそこそこ性能が必要だから現状厳しい

391名無しさん@編集中 (オイコラミネオ MM06-bcz3)2017/09/08(金) 08:17:45.88ID:zQgPsbEjM
一番の問題はx265の完成度が低すぎる所
規格上はH.264の二倍近い圧縮効率と謳ってるが、
x264とx265で似たようなSSIMになるようにエンコしても、
速度倍かかるのに対して容量3割程度しか削減出来てない

392名無しさん@編集中 (ワッチョイ 3b00-xkdj)2017/09/08(金) 09:08:45.48ID:jziT9JUy0
H.265が「H.264の2倍の圧縮率」てのを発表したのはSSIMではなくてPSNRでの評価。
んで、そういう機械評価ではなくて、実際の主観的な評価(眼で見た時)はどうなのかと、圧縮率をH.264の倍にしてテストも、92.5%はテストクリア(半分にしても違いが分からない)という結果が出ている。
http://www.bbc.co.uk/rd/blog/2016-01-h-dot-265-slash-hevc-vs-h-dot-264-slash-avc-50-percent-bit-rate-savings-verified

393名無しさん@編集中 (ワッチョイ 83e1-uK4n)2017/09/08(金) 10:35:25.34ID:YVfOYICF0
>>390
8bitでエンコしてあればx265のエンコ動画はスマホでも余裕で再生できるけど?

394名無しさん@編集中 (アウアウカー Sa43-b3wh)2017/09/08(金) 13:10:52.31ID:DRBMiemRa
スマホの世代によるんじゃ

395名無しさん@編集中 (ワッチョイ 8391-x/0H)2017/09/08(金) 14:57:11.66ID:6zk3EGtm0
馬鹿でも出来るという言葉があるが馬鹿の程度にもよるしな

396名無しさん@編集中 (ワッチョイ 9a11-ShIp)2017/09/08(金) 19:02:26.67ID:K42HeHEk0
x264vfwの最新版が7月で64bit版は15年で止まってるんですが
もう作らないという事でしょうか?自分がよく使っているソフトは64bitなので
最新版は使えないっぽいですが

397名無しさん@編集中 (ワッチョイ b744-152M)2017/09/08(金) 19:17:53.60ID:EqCEryle0
>>396
統合されたので、最新版を入れれば32bitと64bitの両方が入るよ。

398名無しさん@編集中 (ワッチョイ 9a11-ShIp)2017/09/08(金) 19:37:50.44ID:K42HeHEk0
あ、そうなんだdクス 翻訳サイトで読んだけどちょっとよく分かりませんでした

399名無しさん@編集中 (キュッキュ 1730-kPjP)2017/09/09(土) 09:15:24.46ID:h/Y+Lz1o00909
x264guiEx_2.52

400名無しさん@編集中 (オイコラミネオ MM06-bcz3)2017/09/12(火) 07:10:49.74ID:AdArdet+M
>>392
規格作った所の公式テストの話じゃなくて、x264に比べてx265の最適化が発展途上って話なんだが

401名無しさん@編集中 (アークセー Sx4d-YyFd)2017/09/16(土) 13:32:24.14ID:zNLVYvN4x
>>392
どうせ比較したH.264エンコーダーが糞なんだろうな
x264はmp3でいうLAMEみたいに規格内で極限まで最適化を志向するエンコーダー

402名無しさん@編集中 (ワッチョイ 86cd-Ll1/)2017/09/22(金) 16:10:49.36ID:cJDJKSFu0
規格とエンコーダの違いがわかってなくて規格(机上の空論)だけで比較した気になってる人でしょう

403名無しさん@編集中 (ワッチョイ 1e0d-hoCt)2017/09/27(水) 19:54:24.64ID:p7Ac+Lfb0
 1passVBRのcrf指定でエンコする場合、presetはどれに設定しても
crfが同じなら容量は変わっても画質はほぼ同じになるの?

404名無しさん@編集中 (ワッチョイ eb44-rRtX)2017/09/27(水) 21:29:43.81ID:2daxdhqd0
>>403
画質という表現だとちょっとあれだが、前にSSIMを調べた時には
fasterより早いプリセットは他に比べて明らかに値が低くなってしまっていた気がする。

405名無しさん@編集中 (ワッチョイ 2b17-Dc1X)2017/09/27(水) 22:14:16.87ID:Urbs+S3H0
>>403
機能的にはそのはずだけど画質はfasterとslowではそれなりに差が出る
使える機能を絞ってるわけだから当然なのかなと思ってる

406名無しさん@編集中 (ワッチョイ cb0d-asy+)2017/09/28(木) 05:25:03.14ID:V45lbue30
 ありがとう。MicroSDも随分大容量になった昨今、エコ的には容量に
振った方が良いのかな、と思ったんだけど微妙だね。

407名無しさん@編集中 (オイコラミネオ MM2b-jtbH)2017/09/30(土) 16:37:33.34ID:0Ufo816+M
ハズレ石の6700Kで夏場は水冷でも熱暴走しまくって、OCを4400MHzに抑えてたが、
ようやく涼しくなって常用最大の4600MHzまでやっても落ちなくなったわ

408名無しさん@編集中 (ワッチョイ b54f-Txnz)2017/10/01(日) 22:59:15.48ID:q0pgAPRH0
電源をずしんと重いやつに変えれば夏でも安定すんじゃね?

409名無しさん@編集中 (オイコラミネオ MM2b-jtbH)2017/10/01(日) 23:01:30.73ID:kwhdiWHuM
>>408
オンボ環境で1000Wの電源積んでる(将来のグラボ追加のための皮算用)んですがね

410名無しさん@編集中 (ワッチョイ 2ee7-l8I1)2017/10/09(月) 02:38:46.73ID:o0wuNtkj0
x265スレが落ちたようだな…

411名無しさん@編集中 (ワッチョイ 559f-XSap)2017/10/09(月) 04:47:35.68ID:jZhige/X0
ヤツは四天王の中でも

412名無しさん@編集中 (ワッチョイWW 769a-VAlr)2017/10/09(月) 07:59:57.87ID:LaKQeeR70
最強

413名無しさん@編集中 (ワイエディ MMc2-wbjw)2017/10/09(月) 10:51:18.58ID:yu/ITypTM
漬け

414名無しさん@編集中 (ワッチョイWW 76ab-tpYQ)2017/10/11(水) 00:26:25.49ID:Q7nPMdd60
おお・・・

415名無しさん@編集中 (ワッチョイWW 9d76-F4VE)2017/10/11(水) 00:40:05.42ID:nHom/Jmt0
勇者よ…

416名無しさん@編集中 (アウアウカー Sa4d-N4fM)2017/10/11(水) 08:59:51.54ID:98Hacveca
死んでしまうとはなさけない

417名無しさん@編集中 (ワッチョイ 75eb-wbjw)2017/10/11(水) 13:25:53.15ID:qw5XZR0a0
死んでしまうとはふがいない

418名無しさん@編集中 (ワッチョイ b6ed-nFVg)2017/10/11(水) 17:26:15.90ID:i0NOrkcf0
勇者「うるせー!文句あんなら自分でやれや糞がっ」

419名無しさん@編集中 (ワッチョイ 4116-4LW9)2017/10/11(水) 18:01:28.04ID:p3huYvL50
女神様「ぷーくすくすー」

420名無しさん@編集中 (アークセー Sx75-T51w)2017/10/11(水) 20:41:15.01ID:xq6B2EZpx
ライゼンはええわ
1700@3.6GHzで地デジソースがveryslow&お気に入りフィルタの重めの設定でリアルタイムfps出てるわ
6700K@4.6GHzだと実時間の倍掛かるのに

421名無しさん@編集中 (オイコラミネオ MM7e-SA1d)2017/10/11(水) 21:28:00.33ID:M7bFbdy2M
流石にその比較で2倍違うのはおかしい
もちろん実時間の倍かかるというのが1.6倍とかのことなら分かるが

422名無しさん@編集中 (スッップ Sdfa-F4VE)2017/10/11(水) 21:34:32.23ID:LMrA0Z5Xd
無理なOCでコケてるんじゃね

423名無しさん@編集中 (ワッチョイ 7b7f-tMcA)2017/10/13(金) 13:45:16.21ID:yFIiDpYE0
こんな人間いるのかな?って突如疑問に思ったんで質問してみる

BDにはいってるAVCをx264で再エンコしてる人
こんな人いる? 
これってもうガッツリと容量削減だけが目的?

424名無しさん@編集中 (オイコラミネオ MM8b-h0Xl)2017/10/13(金) 14:12:59.68ID:klQgg49hM
BDのH.264ってとりあえず最高ビットレートで入れとけって感じだから、再エンコでも結構縮む
そもそも深度8bitの時点で知れてるし

425名無しさん@編集中 (ワッチョイ 7b7f-tMcA)2017/10/13(金) 15:01:37.09ID:yFIiDpYE0
>>424
ああ そういう感覚なのか
容量あるから考えなしにビットレート高くしとけっていう事ね
ありがとすっきりした

426名無しさん@編集中 (ワッチョイ 7bc2-B6a6)2017/10/13(金) 20:56:47.91ID:KJdAkpzt0
720p付近で作ってるアニメなら容赦なく720pにしちゃう

427名無しさん@編集中 (ワッチョイ d360-kUpk)2017/10/13(金) 22:51:02.86ID:zkNYkqBK0
>>423
BD-BOXをエンコしてBD-R SL1枚にまとめれたら最高じゃね?
あとは特典だけ手元に残してBD-BOXをオクに流せばいいだけ。

428名無しさん@編集中 (スッップ Sd33-PUQR)2017/10/13(金) 23:02:17.93ID:/9liIQr8d
>>427
それならH.265にするわ

429名無しさん@編集中 (ワッチョイ 7bf7-BSx0)2017/10/13(金) 23:08:15.02ID:c69msVZM0
一度HDDにエンコして入れとけば見たい時にサクッと見られるからな
毎回blu-rayディスク引っ張り出してディスクセットがめんどい

430名無しさん@編集中 (アウアウウーT Sa1d-6M7B)2017/10/13(金) 23:08:32.23ID:XO65u8DFa
BDを再エンコするのはノートPCでいつでも気軽に見られる様に入れておきたいって用途しか無いなあ
だから容量削るのに720Pにしちゃうし画質はそこそこで早さ優先にしてる

431名無しさん@編集中 (ワッチョイ d360-kUpk)2017/10/13(金) 23:11:13.45ID:zkNYkqBK0
何でエンコするかは各自の自由な。
俺もエンコはx265(アニメならpreset 8+12bit+crf16)の一択になってしまったが。
BDソースだとavsフィルタとか無理に加える必要もないしエンコもだいぶ省略できる。

432名無しさん@編集中 (ワッチョイ d360-kUpk)2017/10/13(金) 23:26:06.30ID:zkNYkqBK0
x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。
24分アニメあたり800〜1.3GB前後で収まれば御の字だし

433名無しさん@編集中 (オイコラミネオ MM8b-h0Xl)2017/10/14(土) 01:04:33.83ID:+Cbq7FOAM
俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ
自分でやるの時間の無駄だし面倒だから

434名無しさん@編集中 (ワッチョイ d360-kUpk)2017/10/14(土) 01:26:53.21ID:kVkjCh4N0
地デジソースとかエンコ職人がアップしたやつを見たこと有るけど
60iテロ処理とか雑に処理しててドン引きした。

435名無しさん@編集中 (ワッチョイ 0beb-Dsb7)2017/10/14(土) 01:46:27.00ID:p1EsgrIG0
テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな
静止シーンでコピペして潰せるとかならともかく

436名無しさん@編集中 (ワッチョイ d360-kUpk)2017/10/14(土) 14:10:21.52ID:kVkjCh4N0
いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。

437名無しさん@編集中 (ワッチョイ 41a5-BSx0)2017/10/14(土) 16:16:50.16ID:Q0J2c64D0
だから地デジはゴミって言ってんだろう

438名無しさん@編集中 (ワッチョイ 0beb-Dsb7)2017/10/14(土) 20:09:42.00ID:p1EsgrIG0
補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ
存在してるだけでイラつくゴミが、これ見よがしにヌルヌル動いてたら余計腹立つわ
きったねー縞々で何書いてあるかわからないぐらいの方がざまあみろって感じでいいんだよ

439名無しさん@編集中 (ワッチョイ 41a5-BSx0)2017/10/14(土) 20:13:49.84ID:Q0J2c64D0
ちょっと理解できない

440名無しさん@編集中 (ワッチョイ 0b00-BSx0)2017/10/14(土) 20:17:20.64ID:wt/1RTiS0
>>438
テロップに惨敗して負け惜しみ言ってるようにしか見えない

441名無しさん@編集中 (ワッチョイW b3eb-uk6+)2017/10/14(土) 21:08:10.51ID:AcLLCDR50
AUTOVFRで手抜きしてるわ

442名無しさん@編集中 (ワッチョイWW 8bab-wUXQ)2017/10/14(土) 21:50:24.73ID:qxT45PQV0
何度も見る事やないんやけんある程度見れてたらそれでええわ

443名無しさん@編集中 (アークセー Sx45-h0Xl)2017/10/15(日) 01:30:31.64ID:uf2+tVfwx
そんなに気になるならインタレ保持でやれよと

444名無しさん@編集中 (ワッチョイ d360-kUpk)2017/10/15(日) 01:53:30.55ID:kSF3tACb0
横にテロが動くときに妙にぎこちなかったり、カックンカックンしたりするとアニメ本編に集中できずにイラつくだろ?
あとエンコ職人はウォーターマーク消しと提供のテロップ消しを一切しないのもイラつく。

445名無しさん@編集中 (アークセー Sx45-h0Xl)2017/10/15(日) 02:00:59.89ID:uf2+tVfwx
どこの局のソースかが大事だからな
糞低ビットレートのMXじゃないよアピール

446名無しさん@編集中 (アウアウウーT Sa1d-6M7B)2017/10/15(日) 10:31:33.53ID:yslYpxl4a
>>444
そこがそれほどイラつくなら素直にBDを買うか借りるかした方が幸せになれそうだ

447名無しさん@編集中 (バットンキン MM8a-upsE)2017/10/19(木) 19:52:10.44ID:vF0uxTaTM
x265でアニメエンコしてたけど
暗部の潰れや歪みがどうしても良くならないのでx264に戻ることになりそう

あまり詰めてないけど--crf 20 --qcomp 0.7 --aq-mode 1 --aq-strength 1.0 --psy-rd 0.65:0.20で同ビットレートの265より再現度良好

448名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/19(木) 20:15:18.80ID:3Nrwplnu0
定期的に現れるけど、単に8bitでエンコしてるだけでは?

449名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/19(木) 20:35:27.12ID:RCE2B7Sj0
仮にそうだとしても、ソースも8ビットなわけで、
x264にできてx265にできないならその条件ではx265が劣るというだけのこと

450名無しさん@編集中 (ワッチョイ d6e8-Doce)2017/10/19(木) 20:41:02.03ID:cp4WsA9J0
aq-mode 3 使えよ

451名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/19(木) 20:45:39.24ID:3Nrwplnu0
「その条件」ならそうかもしれんが、>>447はその条件にこだわってないだろ
バンディング対策をしたくない理由とは?

452名無しさん@編集中 (ワッチョイ d6e8-Doce)2017/10/19(木) 20:49:53.98ID:cp4WsA9J0
暗部といったら aq-mode 3 だろ
なんで 1 使ってんだよ
意味わかんねーよ

453名無しさん@編集中 (エムゾネWW FF9a-86sF)2017/10/19(木) 21:08:09.16ID:BSHlOoYOF
詰めてないんじゃなく詰め方を知らないんだろ

454名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/19(木) 21:11:09.82ID:RCE2B7Sj0
>>451
で、その>>447の対策(バンディングと暗部のディテールは違うと思うが)がx265ではなくx264を使うということだったのでは?
バンディングでいうと、ソースが8ビットならばいくらエンコの設定工夫しても無駄
逆にいえば少なくともx264ならエンコの設定ちゃんとすればスクリーンキャプチャしてソースと差分取ってもほぼ0にはできる

455名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/19(木) 21:14:46.32ID:RCE2B7Sj0
ソースが10ビットなら知らんが、
アニメで(エンコードできるDRM無しの)10ビットのソースなんでまずないだろうに
8ビットのソースを10ビットでエンコードするのはただのアホ

456名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/19(木) 21:16:18.23ID:WeGA2ymkM
暗部保護ならaq-mode 3とno-mbtree両方設定しとくべき?
後者いらない?
BSプレミアムで放送された大曲花火大会中継を今さらエンコしようと思うんだ

457名無しさん@編集中 (ワッチョイ 9d16-6XL8)2017/10/19(木) 21:18:04.70ID:P8zWZmTR0
入力が 8bit でも Avisynth やらでフィルター噛ませば出力 10bit でも多少効果でるもんじゃないん?
バンディング軽減やらで

458名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/19(木) 21:19:04.81ID:WeGA2ymkM
aviutlでノイズフィルタ使ってるなら色深度変わってくるから10bitがいいんでないの?
avisynthなんかでYUV420のまま処理したなら要らんだろうけど

459名無しさん@編集中 (ワッチョイ d6e8-Doce)2017/10/19(木) 21:21:03.54ID:cp4WsA9J0
デバンドは意味あると思うが10bit化は無駄多すぎ
アニメには必要ない
それより x265 にも aq-mode 3 はあるから

460名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/19(木) 21:22:31.59ID:RCE2B7Sj0
ソースを加工するならたしかにまあ
普段自分はしないからその発想は抜けてた

461名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/19(木) 21:32:18.18ID:3Nrwplnu0
8ビット高ビットレートでバンディング低減されてるソース(放送もブルーレイもそう)を
低ビットレートにエンコするんだったら、デバンドした上で10bit化は必須だよ

462名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/19(木) 21:37:16.82ID:3Nrwplnu0
まぁ、あまりいいディスプレイじゃなければ分からないかもしれないけど、
少なくとも俺の使ってる4Kブラビアじゃ、チラチラしすぎて集中できない

463名無しさん@編集中 (ワッチョイ 5585-0GSP)2017/10/19(木) 21:38:05.60ID:9FIiI0A00
アニメで10bit化が必要ないとかマジかよ

464名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/19(木) 21:54:45.70ID:WeGA2ymkM
ブルレイ互換でエンコが基本の自分としては10bitはそもそも選択肢に入らないけどなぁ
ウルトラHDブルレイなら10bit以外の設定は既存のブルレイに合わせとけば問題ないっぽいけど、
そもそも個人向けオーサリングソフトがない

465名無しさん@編集中 (ワッチョイWW fa62-upsE)2017/10/19(木) 21:59:03.66ID:AVcz4dXd0
447だが
単にx265とずっと格闘しててx264は浦島気味だから
とりあえずデフォルトに近い所から挙動見てみるかくらいの気持ちだったんだけど…
怒らせてしまったなら申し訳ない

ちなみにどちらも10bitでx265はAQ1〜3、Psy-rd、rdoqをあらかた上下させまくったけど
暗部の輪郭保持でx264のポン付けに及ばなかったのはガチだよ
スレチになりそうなんで、要求されない限り細かい記述は避けるけど

466名無しさん@編集中 (ワッチョイ a511-/wYC)2017/10/19(木) 22:39:10.16ID:FFa/XIlI0
8bitソース素通しでも10bitでエンコードする理由はあるよ
同じソース・同じavs・同じX265設定(output-dephthだけ変更)を見比べたら
明らかに10bitが優れている
ま、crf20以下じゃ大した差じゃないかもしれないがエンコーダーとしては10bitのほうが優れているのは変わらない
ちなみにx264のほうが処理がシンプルな分、情報量が多くなることは多い

467名無しさん@編集中 (ワッチョイ 8ef7-0GSP)2017/10/19(木) 22:40:19.49ID:Gaf9oyCF0
バンディングだけは目に見えて効果あるよな10bit化
PCでしか再生しないし一択だわ

468名無しさん@編集中 (ワッチョイ a59f-0GSP)2017/10/19(木) 23:57:53.42ID:VgKoLcU30
>>465
ソースくれ、その部分だけでいいから
できれば静止画でなく動画で

469名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/20(金) 00:20:43.45ID:qjJPv/bA0
>>466
x265は知らんが、x264なら素通しなら8ビットでソースと寸分違わないレベルの画は出るんだよ
劣化するにしても動きやディテール部分が溶けるだけで、バンディングなんでひどくもならない
そうならないとしたら設定がおかしいか(画質が目に見えて劣化する低レートは知らん)、素通しのつもりがそうなってないパターン

470名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/20(金) 00:31:01.56ID:1vtnnLQF0
>>469
君が劣化しているところに気づいてないだけだと思うよ
BDでさえバンディングは問題になっているのに、その5分の1以下のビットレートで
問題にならないってありえないだろ

471名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/20(金) 00:42:37.61ID:qjJPv/bA0
1/5程度のレートなら余裕余裕
アニメのBDなんて無駄に(というかほぼCBRに近い)レート食いまくってるんだから、
動かない静止画に近いところで適切に圧縮するだけでその程度には簡単になる。
もっと低いレート(1/10以下)のこと話してるのかと思ったらそんなレベルのなのか。
〜なわけがないとか想定で話してないで、実際に試してみてから話してくれ

472名無しさん@編集中 (ワッチョイWW 818a-5n8Z)2017/10/20(金) 00:45:01.85ID:qjJPv/bA0
アニメのBDはマーケティングの都合で1枚に2話とかしか入ってなくてレート減らすインセンティブ皆無だからな
ほぼ規格上限ぎりぎりのCBRよ

473名無しさん@編集中 (ワッチョイ d6e8-Doce)2017/10/20(金) 00:51:27.88ID:meA5JVSG0
crfが適切で、aq-mode 3 使って、デバンドかけてれば
8bitでそんな気になるほど見分けつかんよ・・・
10bit使わにゃいかんほどだと、違うパラメータが変なんだよ

474名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/20(金) 02:12:58.94ID:1vtnnLQF0
ソース
x264 rev43©2ch.net	->画像>97枚

フィルタなし 8bit --crf 20 --aq-mode 3 --tff
x264 rev43©2ch.net	->画像>97枚
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
x264 rev43©2ch.net	->画像>97枚
デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff
x264 rev43©2ch.net	->画像>97枚

デバンドありの圧縮前
x264 rev43©2ch.net	->画像>97枚

全部AviUtlでrigaya氏の拡張x264で出力
デバンドはrigaya氏のバンディング低減MT SIMD (25/15/15/15/0/0/1/0/off/off)

これで8bitがきれいに見えるならいいんじゃないか。そういう環境ならね・・・

475名無しさん@編集中 (ワッチョイ d6e8-Doce)2017/10/20(金) 05:31:39.81ID:meA5JVSG0
おれ環では aq-strength を調整すれば 8bit + デバンド でいいや・・・

476名無しさん@編集中 (ワッチョイ f97f-0GSP)2017/10/20(金) 07:45:09.76ID:Bsl5IeCi0
デバンドするしないでも選択肢変わるだろうし
QP値どれだけ盛るかにもよるけど手軽にやりたいなら10bitのほうが楽っちゃ楽
8bitソースにデバンドも何もしないなら10bit使うだけほぼ無駄ってのはそのとおり

477名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/20(金) 08:33:39.54ID:ljIvdMqUM
なんでアニオタばかりなの?
グクってもみんなアニメかゲームのエンコの話ばかり
実写メインの人っていないの?

自分は実写メインで、地デジソースならデノイズかけてインタレ保持のcrf25ぐらいで5Mbps前後にしてる
SSIMが大体0.978ぐらいになるから糞ソースの地デジならあんまり変わらん気がする

478名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/20(金) 08:35:38.93ID:ljIvdMqUM
デノイズはNL-Means使ってる
アニメ向きとも言われるが、弱くかければ実写でも10%ぐらい小さくなる

479名無しさん@編集中 (ワッチョイ 8ef7-0GSP)2017/10/20(金) 08:55:47.92ID:CGJgWOmW0
実写メインの人ってHDD録画かBD-Rにムーブして終わりじゃね
容量にも拘りなさそうだしエンコ自体してなさそう

480名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/20(金) 10:10:35.50ID:qjJPv/bA0
>>474
>ソース
x264 rev43©2ch.net	->画像>97枚
と、
>フィルタなし 8bit --crf 20 --aq-mode 3 --tff
x264 rev43©2ch.net	->画像>97枚
はほぼ寸分違わないよな。
ということを言ってるんだよ。

ソースを加工して情報を補完する場合はその限りではないと>>460で言ったとおり
あくまでもソースを忠実に再現するためのエンコードという観点でしか話してなかった

デバンド等でぱっと見は綺麗になったように見えるんだけど、
一方で細部の意図したざわざわなディテールも消失するし(地デジなんかのソースにはそもそもそんな情報ほぼ残ってないだろうが)、
いいことばかりの魔法のフィルターは無いのだ。その辺は好みだね。
あくまでもソース寸分違わないかどうかという観点では10bitエンコードは無駄という話。

481名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/20(金) 10:17:59.88ID:qjJPv/bA0
んでもって、x264は
>8bit --crf 20 --aq-mode 3 --tff
みたいなほぼプリセットそのままな設定でソースほぼそのままの忠実なエンコードができるんだが、

>>466のような話は散々出てくるし、
x265は依然としてそのレベルに達してないのだろうか

482名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/20(金) 10:39:22.89ID:ljIvdMqUM
10bitで書き出すならデバンド要らなくない?
あくまで内部処理が8bitを越えるデノイズやらリサイズフィルター通したのを8bitで出すための処理じゃないの?

483名無しさん@編集中 (ワッチョイ a511-/wYC)2017/10/20(金) 10:55:30.54ID:l1+4vpOY0
>>481
x265はビットレートをつぎ込んでの高画質はまだx264に負ける
っていうかx265は4k向けの高圧縮コーデックだから2kで負けるのは仕方ない

484名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/20(金) 11:55:38.66ID:ljIvdMqUM
まだx265が開発途上なだけでしょ
H.264と同じく低解像度から満遍なく圧縮率上げる規格だからx265の改良の余地はある

485名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/20(金) 12:57:27.10ID:qjJPv/bA0
>>482
そういうことでもない
デバンド(も含めソースの加工)をしないならソースと同じビット数でエンコードすればいいだけ
8bitのソースを8bitビットでエンコードして当たり前だがソースからほぼ劣化が無くできるのだから、
それを10bitでエンコードしてもデータを無駄に水増しして互換性を下げているだけ

たしかにフィルターをかけたら元の8bitでは表せない中間の値が出てきてしまうので、
それを10bitで表現するというのはありだし、実際効果はある(>>474
もちろん再び8bitに落としてもある程度フィルター効果は残ってはいるが完ぺきではない(>>474

486名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/20(金) 13:00:23.85ID:qjJPv/bA0
>>483
H264の普及初期段階もH264は低ビットレートでそれなりに見られるようにするコーデックで、
高解像度高ビットレートではMPEG2のほうがきれいだとか言われていたが、
それは単に当時のコーデックの実装が未熟だっただけで、今どきそんな戯言を言うやつはいないのでそれと同じことだろう

487名無しさん@編集中 (ワッチョイ a511-/wYC)2017/10/20(金) 14:00:38.72ID:l1+4vpOY0
>>485
その水増しってのが認識を間違ってる証拠だと思う
なにも水増しはしてないんだから

>>486
なるのかな
h.264がHD画質でmpeg2より高画質になったのは必然だけど・・

488名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/20(金) 16:47:06.45ID:qjJPv/bA0
>>487
8bit to 8bitでまさにソースそのままにエンコードできるのだから、
そういう場合に10bitでエンコードすることがどう
>なにも水増しはしてない
なのか詳しく

何度も言うがソースに何らかの加工を施す場合はこの限りではない

489名無しさん@編集中 (ワッチョイ fad2-yWqP)2017/10/20(金) 19:18:50.79ID:93DuW1x10
crf 20 出来上がりのファイルサイズめっちゃデカくなりそうだけど

490名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/20(金) 20:58:55.70ID:4az+If+XM
アニメならそうでもない
さらにフレームレートと解像度によってcrf同じでも品質違ってくる

491名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/20(金) 21:38:45.04ID:1vtnnLQF0
ソースを忠実に再現って言うと聞こえはいいかもしれないけど、
MPEG2圧縮でできたノイズやアーティファクトまで再現しようとしなくていい

しかも実際は再現できてなくて、バンディングは悪化してる(>>474
(圧縮で情報量が落ちる分仕方ないのだけれど)

デノイズしてから圧縮したほうが綺麗なることも多いし、
テレビは「高画質化エンジン」で加工しまくって表示してる
そもそも圧縮で情報量落ちる分、ある意味「加工」されちゃう

492名無しさん@編集中 (オイコラミネオ MM5e-5n8Z)2017/10/20(金) 22:05:29.43ID:o4Nz9FwSM
まあTVはソースがボロボロだからねぇ

493名無しさん@編集中 (ワッチョイ a511-/wYC)2017/10/20(金) 22:06:27.54ID:l1+4vpOY0
>>488
細分化であって水増しじゃないでしょ

494名無しさん@編集中 (ワッチョイ 5585-0GSP)2017/10/20(金) 23:42:25.14ID:HASgMWlT0
8bitきったねぇわろたwwwwwww
こんなんどう見てもデバンド+10bitだろwwwwwwww

「ソースに忠実」とか意味分からないことに拘るめくらは編集もエンコもしないでTSで保存しとけwwwwwwwwwwww

495名無しさん@編集中 (ワッチョイ 3a0e-0GSP)2017/10/21(土) 00:06:33.17ID:GU2WsWjF0
>>480
この違いがわからないなんてよっぽどひどいモニタ使ってるんだね

496名無しさん@編集中 (ワッチョイ 81ec-h3yZ)2017/10/21(土) 01:08:20.59ID:150/70DS0
>>495
「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく
趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。

497名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 01:36:45.74ID:SivVBkBJ0
>>494
デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ
緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう
特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方

というか元から保存用はもちろんTSだわ
スレ違いになるのでそれについては深入りはしないが
MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする

498名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 01:42:00.04ID:SivVBkBJ0
>>493
意味が分からない
じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、
もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う

499名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 01:49:58.38ID:SivVBkBJ0
話がややこしくなってきたので改めて整理すると
>>466
に対する反論として、
8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば
ということを俺言ってるだけ
8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない

んでもってその観点でいうならば、
>>474にはデバンド無し10bitの結果が無いのでその比較にはなっていない
ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが

500名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 02:00:41.89ID:SivVBkBJ0
>>494のようなめくらには副作用があるって言っても
具体的な例を示してやらないとわからないだろうから言っておくと、
たとえばデバンドかけたほうは(圧縮前の時点で)右上の絵画(?)の色の境界ソフトになってるよな
BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ

そういう部分に目が行かず、
>8bitきったねぇわろたwwwwwww
>こんなんどう見てもデバンド+10bitだろwwwwwwww
みたいに草生やしてるだけだからお前はめくらなんだよ

501名無しさん@編集中 (ワッチョイ a59f-0GSP)2017/10/21(土) 02:48:21.65ID:GOmLStnF0
地デジはともかくブルーレイだと>>474のデバンドあり圧縮前のような
色の階調部分のディザを保っているからな〜
少し試してみようか

502名無しさん@編集中 (ワッチョイ a59f-0GSP)2017/10/21(土) 03:06:40.59ID:GOmLStnF0
これが>>474デバンドあり圧縮前をcrf0で8bit化したavc(の静止画)
x264 rev43©2ch.net	->画像>97枚

------------------------
これがそのavcをcrf20 8bitエンコしたもの
x264 rev43©2ch.net	->画像>97枚
QP:19.37 size: 31899byte

------------------------
こっちはcrf20 10bitエンコ
x264 rev43©2ch.net	->画像>97枚
QP:31.10 size: 29806byte


QPがとても上がってるせいかサイズは10bitの方が少ない
画質の評価は見た人に任せるよw

503名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 03:22:40.83ID:+8CAoyQn0
>>500
そう、これ使えねーなと思ってさ、直したんだよ

バンディング低減MTは、Y,Cb,Crを色別に差を見てるんだけど、
そこ変更して、「全部の色がしきい値未満だったら」にした

対象と判定されたピクセルを表示してみた結果↓
判定表示(改造前)
x264 rev43©2ch.net	->画像>97枚
判定表示(改造後)
x264 rev43©2ch.net	->画像>97枚

デバンドありの圧縮前(改造後)
x264 rev43©2ch.net	->画像>97枚

オレオレバンディング低減
x264 rev43©2ch.net	->画像>97枚

どうよこれ

504名無しさん@編集中 (ワッチョイ a59f-0GSP)2017/10/21(土) 04:09:58.65ID:GOmLStnF0
>>503
素直に欲しいレベル

505名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/21(土) 06:22:51.12ID:GF3n0jE/M
素通しで8bitソースを10bitにエンコするときにバンディング減ったように見えるのはdeblockが効いてるからだと予想

506名無しさん@編集中 (ワッチョイ 5585-0GSP)2017/10/21(土) 09:21:07.43ID:3Js2SGA+0
別に絵画の精細度なんてどうでも良いんだがwww
少なくともこのソースで明らかに目につくのはバンディングだしwwwwwwwwww
まじめくらやべぇわwwwwwwwwwwww

507名無しさん@編集中 (ワッチョイ 51f2-hZQr)2017/10/21(土) 09:28:46.77ID:wM+aM70x0
老眼が進むとどうでもいい

508名無しさん@編集中 (ワッチョイ c5eb-bcII)2017/10/21(土) 10:08:27.63ID:/zKw8/Pi0
             _人人人人人人人人人_
  J( 'ー`)し     > 草刈り中のトラブル <
  ○={=}〇,      ̄Y^Y^ Y^Y ^Y^Y Y^Y^Y ̄
   |:::::::::\, ', ´チュイーン
.wwし w`(.@)wwwwwwwwwwww
     彡 ⌒ ミ
     (´・ω・`)

509名無しさん@編集中 (ワッチョイ a511-/wYC)2017/10/21(土) 10:30:00.87ID:4zl1vzp40
>>498
1,000円札を100円玉 x10に換金することをお金の水増しというのなら
「水増し」という言葉使いで正しいと思う

>>499
そうね
自分のエンコードの目的は「出力サイズを小さくする」ことだから
10bitでアラが目立たなくなるなら、そのぶんcrfを大きくしてサイズを小さくできる10bitってスゴイ優秀って先入観で書いちゃった

8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね>大元は

510名無しさん@編集中 (ワッチョイ 1a74-0GSP)2017/10/21(土) 10:39:24.59ID:NJkYLvTf0
>>502を見るとどう考えても10bit>8bitじゃんw
ファイルサイズ8bitの方が小さいならまだ分かるけど
大きくてこれとかイイとこなしw

511名無しさん@編集中 (ワッチョイ 8ef7-0GSP)2017/10/21(土) 10:48:03.01ID:GLwKHK4T0
静止画だから分かりづらいけど
動画で見たらさらに目立つからなバンディングは

512名無しさん@編集中 (ワッチョイ fad2-yWqP)2017/10/21(土) 10:50:48.21ID:WCEoAZaz0
>>511
うにょんうにょん動いて気持ち悪いよね

513名無しさん@編集中 (アウアウウーT Sa89-dU7J)2017/10/21(土) 16:10:41.83ID:s2dz+3eBa
うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで
ビット数より圧縮アルゴリズムから来る話で圧縮率の問題だと思うがな
各色8ビットの静止画でバンディングを感じるなんて事はまず無いわけでさ
(モニタのガンマカーブの話はまたややこしいのでカット)
デバンドは近接画素間を圧縮に都合のいい様に加工するから圧縮率高くてもバンディングが解消されるって話でしょ
つまり同容量で8ビット圧縮より10ビット圧縮の方が画質が優れているとしたら「8ビットより10ビットが綺麗」では無く
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」って話だと思うんだが

514名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 16:54:30.19ID:SivVBkBJ0
>>513
>8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出る

っていう分かりやすいサンプル(できれば追試できるようにソースも公開されてるとなおよいが難しいだろう)があればな
単に何らかのミスで素通しになってないか、エンコード設定がおかしいだけじゃないのって気がする
素通しでそんなことになったこと無いもの

x265はほぼ使ったこと無いので知らん
現状のx265なら
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」
ということもあるのかもね

515名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 17:26:01.84ID:SivVBkBJ0
>>502

>>474
で全部色が変わってしまっていて何かがおかしい
>デバンドあり圧縮前をcrf0で8bit化したavc
っていう中間形式の作り方の詳細がよく分からないので何とも言えないけど、
色が変わってしまっているってことはどこかの段階で色空間かレンジの変換がかかってるということはないすか?

ちゃんとやれば、crf0が厳密には可逆圧縮ではないけどほぼ無劣化でエンコードできて
中間形式を経由した影響はほぼないはずで、

>>474
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
x264 rev43©2ch.net	->画像>97枚



>>502
これがそのavcをcrf20 8bitエンコしたもの
x264 rev43©2ch.net	->画像>97枚
QP:19.37 size: 31899byte

で色が変わってしまうということは起こらないはず

516名無しさん@編集中 (ワッチョイ fad2-yWqP)2017/10/21(土) 17:53:32.26ID:WCEoAZaz0
黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、
暗いところはよく見えんから適当でええやろーみたいな風潮はやめてほしい
no-mbtree指定しても、まだなんかやってんだろって気がする

517名無しさん@編集中 (ワッチョイ 16eb-NpSu)2017/10/21(土) 17:57:18.23ID:/ssX+XV10
よく見えんところをはしょってごまかすのが圧縮の本質だからなあ

518名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 18:01:35.48ID:SivVBkBJ0
>>517
バランスの問題もあるな
明るいところとかもっと削ってもばれねーよってときに暗いところ端折りまくるのがね
x264ならその方面のことは設定でなんとかなる柔軟性はあると思う

519名無しさん@編集中 (ワッチョイ 1a74-0GSP)2017/10/21(土) 19:48:06.19ID:+m1gFY6w0
>>515
おかしいと思うなら自分でやってみたら
1枚の画像から1フレームの動画を作るくらいできるだろう

10bit主張する人は検証画像いろいろ上げてるの、
このスレやググったりして見かけるけど、
8bit主張する人で画像を上げた人が一人もいないんだよね
論より証拠なのに勘ぐってしまう

520名無しさん@編集中 (ワッチョイ 5585-0GSP)2017/10/21(土) 19:56:10.42ID:3Js2SGA+0
バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよww

521名無しさん@編集中 (アウアウウーT Sa89-dU7J)2017/10/21(土) 20:00:51.36ID:s2dz+3eBa
別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ
理屈の検証をしてるんであってどちらの言い分が勝ちなんて勝負をしてる気はみんな無いでしょ
無劣化圧縮の筈なのに色が変わってたらそれは理屈としておかしいから何らかの処理で
色が変わってると考えるのが理論的思考として妥当でしょ

522名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 20:00:58.25ID:SivVBkBJ0
>>519
動きのない完全静止の動画でよければ良ければやってみるよ

>>520
完全素通しっていう前提で主張してるのに、色が変わった(のが分からない人はさすがにいないよな)ならもうそれはカバーできない条件だわ

523名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 20:07:55.46ID:+8CAoyQn0
>>514
ソースにディザが残ってるのを圧縮してディザを消しちゃうとバンディングが出る

デバンドあり 8bit --bitrate 20000 --aq-mode 3 --tff
x264 rev43©2ch.net	->画像>97枚

↑8bitだけどビットレート高いからディザが残っててバンディングが出てない
ブルーレイとかはこんな感じ

524名無しさん@編集中 (ワッチョイ a511-/wYC)2017/10/21(土) 20:13:15.41ID:4zl1vzp40
>>514
チューニング次第では?
基本的な技術は同じで違うのは色深度だけなんだから

525名無しさん@編集中 (ワッチョイ 1a74-0GSP)2017/10/21(土) 20:43:34.22ID:+m1gFY6w0
>>522
それでいいよ

526名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 21:14:07.19ID:SivVBkBJ0
やってみた。
結論から言うと、ソースのディテールを十分再現できる程度(以下の実験ではcrf20)のビットレートがあれば8bitと10bitで差は無いが、
ソースのディテールが再現できずブロックノイズが目に余る領域(以下の実験ではcrf35)になると確かに8bitと10bitに差は出る、
そしてたしかに10bitのほうがブロックノイズのバンディングという面ではマシな結果になる。

(続く)

527名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 21:14:31.54ID:SivVBkBJ0
それについては、ブロックノイズが出まくる領域だとたしかに内部計算的には周辺の平均をとって、
きわめてDC成分に近い次元の成分だけが残り、10bitだとなめらかな中間値を表現できるということはあると思う。
ソースを忠実に再現できるレートでエンコードすることを中心に考えていた節があり、
低レートでそういう面があることを失念あるいは意図的に除外していたことは申し訳ない。

ただし、単純にそういう計算になるかは分からないが10bitだと概ね2割増しのデータを保存しないといけないのだから、
同じビットレートにしたときは(バンディングという側面は無視して)ブロックノイズの程度がひどくなる可能性が示唆される。
今回は静止動画なので分かりにくいが、若干文字や図形の輪郭をよく保っているのは8bitの側のような気がするし、
動きが入ればその印象がさらにどうなるか分からない。
また、何より再生の互換性が大きく低下するという重大な欠点はある。

(続く)

528名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 21:16:19.44ID:SivVBkBJ0
実験結果

バンディングがある8bitソース(GWNr9Ru.png 10秒)

[enc1_crf20_8] 8bit crf20 199KB
x264 rev43©2ch.net	->画像>97枚

[enc1_crf20_10] 10bit crf20 178KB
x264 rev43©2ch.net	->画像>97枚

[enc1_crf35_8] 8bit crf35 47.9KB
x264 rev43©2ch.net	->画像>97枚

[enc1_crf35_10] 10bit crf35 48.4KB
x264 rev43©2ch.net	->画像>97枚


ディザでバンディングを軽減した8bitソース(GWNr9Ru.png 10秒)

[enc2_crf20_8] 8bit crf20 275KB
x264 rev43©2ch.net	->画像>97枚

[enc2_crf20_10] 10bit crf20 245KB
x264 rev43©2ch.net	->画像>97枚

[enc2_crf35_8] 8bit crf35 47.5KB
x264 rev43©2ch.net	->画像>97枚

[enc2_crf35_10] 10bit crf35 48.2KB
x264 rev43©2ch.net	->画像>97枚

529名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 21:18:34.53ID:SivVBkBJ0
なるべく途中で変な処理が入らない用意全部コマンドラインでエンコードした
一連のコマンドは禁止ワードに引っかかったのでpastebinに貼っておいた

https://pastebin.com/b5fBXuRy

530名無しさん@編集中 (ワッチョイ 1a74-0GSP)2017/10/21(土) 22:04:06.64ID:+m1gFY6w0
imgur使うとある程度のサイズ超えるとjpgになってしまう
urlこそpngだけど↓の2つ以外はjpg変換されてる

[enc1_crf35_8] 8bit crf35 47.9KB
[enc2_crf35_8] 8bit crf35 47.5KB

531名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 22:06:27.05ID:SivVBkBJ0
ちなみに色に関しては解像度で自動的に認識してくれるかなーと思ったのと、
色空間の変換はソースのmp4を作るとき一度きりだから特に影響はないだろうと思って何も設定してなかったが、
どうやらちゃんとフラグを設定しないと再生ソフトのスクリーンキャプチャーでで色が変わるので、
そのへんもきっちりやりたければ、ffmpegには
-x264opts colorprim=bt709:transfer=bt709:colormatrix=smpte170m
x264には
--colorprim bt709 --transfer bt709 --colormatrix smpte170m
を付ければOK

まあファイルサイズ的には全く同じだし、これらのオプションはフラグを立てるだけでスクショの色が変わるだけで実験には影響ないと思う
実際そのオプションでもやってみたけど画質的には全く同じだし、ファイルサイズも完全に一致

まあ人に色がおかしいと疑いの目を向けた以上、こちらも正確性を期すために弁明を

532名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 22:08:38.92ID:SivVBkBJ0
>>530
そうなんだ、それは知らなんだ
まあURLから見ても特にこちらの主張が成り立たなくなるほどの劣化は無いと思う

コマンドは示したので、興味があれば手元で追試することもできるのでそこで確認してくれ

533名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 22:17:40.81ID:+8CAoyQn0
>>527
> 10bitだと概ね2割増しのデータを保存しないといけない

この認識は間違ってる

保存するのは量子化した後の値だから量子化ステップの幅(QP値から計算される)に依存する
8bitから10bitに2bit増えても、量子化ステップが4倍になれば理論的にデータ量は変わらない

H264の場合、QP値が6増えると量子化ステップが2倍になるから、
>>502見てもだいたい12増えてデータ量は同じくらいになってるでしょ

534名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 22:43:24.18ID:SivVBkBJ0
>>533
単純計算して2割増しになるってのはおっしゃる通り、
QPを増やさない(=一切副作用無く画面全体に8bit→10bitの恩恵を受ける)場合のこと
単純にそうはならないしても、同じファイルサイズで考えたとき
どこかで10bit分の量子化の恩恵を受ける分8bitよりデータが増え、
他のどこかがそれの割を食わないとファイルサイズが8bitと同じにならない

のっぺりした部分に8bitのときよりも細かい量子化を行う(つまりQPが12ほどは増えない)分、
そのほかの部分でQPを12以上増やさないとファイルサイズは同じにならないでしょ
(これも量子化の後にエントロピー圧縮を行うので単純にそうはならないかもしれないが、話を簡単にするために)
実際ファイルサイズがほぼ同じになるcrf35で比較して、のっぺりした部分の再現性は10bitのほうが上だけど、輪郭は8bitのほうが若干よく見える

535名無しさん@編集中 (ワッチョイ 1a74-0GSP)2017/10/21(土) 22:46:21.80ID:+m1gFY6w0
>>531>>532
いあ正にその色に問題出てるのよ
jpgはYUV420だがpngは24bit

IrfanViewだと目視じゃ違いが見当たらないが
Firefoxや古めの画像ビューアでみた時、pngだけ色が違う
ちゃんと正解の画像見れてるのかモヤっとする

536名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 22:57:43.40ID:SivVBkBJ0
>>535
ffmpegでRGB→YUV変換するときにちゃんとどういう色空間のYUVにするかちゃんと指定しないといけない
(何も指定しないとたぶんBT601になる?)
https://forum.videohelp.com/threads/380991-ffmpeg-x264-RGB-to-YUV
とかいうのもあったりするので、もうちょっとちゃんとオプションを精査したうえで追試してPNGのまま上げられるところ探して上げるわ

普段YUVのソースしかエンコードしないので、今回使えるソースがRGBのPNGだったので、
手際が悪くなって申し訳ない

537名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 23:08:19.15ID:+8CAoyQn0
>>534
のっぺりした部分に8bitよりも多くデータ量割かないと
10bitの恩恵が受けられないってのは確かにそう

で、バンディングに関して言うと、8bitでバンディングを回避するには
ディザを残さなくちゃいけないけど、
8bitでディザを保持するためのデータ量に比べれば
のっぺりした10bit分の色を保持するためのデータ量の方が
圧倒的に小さい

だから、バンディングに関しては10bitの方が圧倒的に有利

↓こんな感じ

データ量
(8bitでディザを残す) >>> (のっぺりした10bit) > (のっぺりした8bit)

画質
(8bitでディザを残す) ≒ (のっぺりした10bit) >>> (のっぺりした8bit)

538名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:21:08.68ID:SivVBkBJ0
実験結果

バンディングがある8bitソース(source1 10秒)
x264 rev43©2ch.net	->画像>97枚

生成元
x264 rev43©2ch.net	->画像>97枚
と色も含めほぼ変わらないのを確認※


[enc1_crf20_8] 8bit crf20 185KB
x264 rev43©2ch.net	->画像>97枚

[enc1_crf20_10] 10bit crf20 166KB
x264 rev43©2ch.net	->画像>97枚

[enc1_crf35_8] 8bit crf35 47.9KB
x264 rev43©2ch.net	->画像>97枚

[enc1_crf35_10] 10bit crf35 48.2KB
x264 rev43©2ch.net	->画像>97枚

(続く)

539名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:21:35.33ID:SivVBkBJ0
ディザでバンディングを軽減した8bitソース(source2 10秒)
x264 rev43©2ch.net	->画像>97枚

生成元
x264 rev43©2ch.net	->画像>97枚
と色も含めほぼ変わらないのを確認※

[enc2_crf20_8] 8bit crf20 264KB
x264 rev43©2ch.net	->画像>97枚

[enc2_crf20_10] 10bit crf20 234KB
x264 rev43©2ch.net	->画像>97枚

[enc2_crf35_8] 8bit crf35 47.6KB
x264 rev43©2ch.net	->画像>97枚

[enc2_crf35_10] 10bit crf35 47.1KB
x264 rev43©2ch.net	->画像>97枚

※一部の領域の色が違う(ディザのほうはちょっとだけバンディング出てる)のはおそらくRGB→YUB→RGBと戻ってきたときの誤差
こればかりはソースとして一度RGBになってしまったものを使う以上仕方ない

結論としては特に変わらず

540名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:22:47.11ID:SivVBkBJ0
コマンドライン
https://pastebin.com/BFCdRUWL

541名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 23:36:03.65ID:+8CAoyQn0
>>539
8bit crf20だとディザが残ってるね。静止画だからビット数多く割けたのかな
動画だと>>474にあるようにディザは消えちゃうんだよ

542名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:36:47.08ID:SivVBkBJ0
>>537
のっぺりする=ソースのディテールを再現できないほどの低レート、なんだから、
>画質
>(8bitでディザを残す) ≒ (のっぺりした10bit)
という等号はおかしい

のっぺり度とファイルサイズは無関係な量じゃなくて関数になってるんだからどちらかを固定しないと不等号として意味が無い
正しくは

データ量
A:(10bitでディザ(≒ディテール)を残す) ≒ B:(8bitでディザを残す) >>> C:(のっぺりした10bit) ≒ D:(のっぺりした8bit)

としたとき、

画質
A:(10bitでディザ(≒ディテール)を残す) ≧ B:(8bitでディザを残す) >>> C:(のっぺりした10bit) >> D:(のっぺりした8bit)

ではないの?
・AとBなら再生互換性があってとくにデメリットがないB
・CとDなら互換性は無視できればC、ただし画質の劣化の方向性が違うのでトレードオフ要素あり

じゃないの?

543名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/21(土) 23:54:34.41ID:SivVBkBJ0
>>541
そうなるってことはディザ部分に割り当てる情報量が不足しているということだと思う
単なるCRFの話じゃなくて(動画で単にCRFだけ上げると他の要素の情報量が過剰になる)、
psy-rdとかの出番だと思う、もちろんファイルサイズは(単にCRFを上げるほどではないにしても)増えるけど

まあ、上の例でいえばABとCDの中間の状態になるわけで、
ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、
っていうときは10bitにも利点はあると思う
ある意味フィルターをかけてるとの同じことになるわけで

544名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 23:57:00.97ID:+8CAoyQn0
>>542
> のっぺりする=ソースのディテールを再現できないほどの低レート

まず、想定しているのは>>539のcrf35ほどの低レートではなくて、
>>539のcrf20や>>523のようにディザが残るほどの高レートでもない
その中間
(試してるのが両極端すぎるw)

フルHDで2〜8Mbpsとかの一般的に使われるレートだよ
そのレートだと、ディザは消えるけど、他のほとんどの目立つディテールは残る

で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
MPC-HCとかオプションにディザのオプションとかあるでしょ
だから、出力される絵は8bitでディザが残ってるのと同じような絵になる

8bitだとディザが消えてのっぺりしちゃったら、もうそれまで
8bit→8bitでディザを付加したりはしないからバンディングはそのまま

545名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/21(土) 23:59:12.57ID:+8CAoyQn0
>>543
動画でディザが残せるのは相当高ビットレートだよ
>>523は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから
20MbpsってCRFだと相当低い
ブルーレイ並のビットレートがないとディザは残せない(8bitでも10bitでも)

546名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:04:05.35ID:TL71NAj40
さらに言うと、データ量減らすためにエンコしてるんだから、
ディザを残すのにデータ量食われるくらいなら
のっぺりした10bitにして、きれいなグラデーションのままデータ量減らしたほうがいい

547名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 00:14:47.36ID:vZIrSnTK0
うーん、なんかだいぶcrfに対する感覚が違うなぁ
基本アニメはcrf18〜20,qcomp 0.8,psy-rd1:0.5でかなり静動のメリハリ付けてザラザラする成分残すような設定でエンコしてるんだが、
基本ディザというかザラザラしたディテールは残るし、BDソースと並べてもまず見分けつかない画質保ったまま、
10Mbps弱(概ねBDの1/5)にはなるんだがなぁ
もちろんBD素通しなのでBDの時点でバンディングなのはそのまま、ディザを追加したりはしないのでそのせいかもしれんが

たしかに砂嵐みたいなシーンだと平気でBD並みのレートになるので、
ソースを加工してでもバンディングは消す!という場合はひどいレートになってしまうのかもしれんが

548名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:30:26.86ID:TL71NAj40
>>547
なるほど、BDだとソースが良いから状況がいいんだと思う

放送だとMPEG2だしビットレートそんなに高くないから、
ディザは残せなくて、それでもバンディングを目立たなくするために
時間軸方向に色をパタパタたさてるんだよ

それを普通に8bitでエンコすると>>512にあるように「うにょんうにょん」になる
時間軸方向にパタパタさせてるもんだから、ディザを追加してもエンコしたら消えちゃう

時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、
副作用があったりで難しいんだよ

549名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:34:12.01ID:TL71NAj40
BDだとこの「うにょんうにょん」が出ないんだろうね

550名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 00:40:12.87ID:vZIrSnTK0
>>548
地デジソースもたまにエンコードするけど、
ソースに加工しない(ソース時点で起こっているあらゆるアーティファクトはそのまま)という前提なら
crf20ぐらいでアニメならソースほぼそのままでサイズもいい線(半分程度)にはなるんだがな
さすがに地デジにドット単位の粒子は無いという前提で、psy-rdはいじらない
まあさすがに実写はこのcrfだとだめね、平気でソース並みのサイズになる

ソースを加工してでもバンディング消す(=8bitならディザを残して大幅にエントロピーを増やさざるをえない)かどうかが
この感覚の差なのかな?

551名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 00:41:15.17ID:vZIrSnTK0
そのうにょんうにょんってのが何なのか分からんのだが、
それはソースで出てるやつなの?
それともソースにはないのにエンコードすると出るって話?
後者だとしたらさすがになんかどこかに齟齬がある気がする

552名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 00:59:06.47ID:TL71NAj40
>>551
ソースでは細かくパタパタしてるだけなんだけど、
エンコするとそのパタパタの周期が落ちて目立つようになってくる
ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる

放送ソースだとx264との相性が悪いっぽくてビットレート低いと悲惨なことになる
QSVだとビットレート低くてもあまり動かないから目立たない(バンディングは残るけど)

crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない

553名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 01:14:01.45ID:vZIrSnTK0
>>552
なんかその現象はこちらはピンと来ないんだよな。
関係あるか分からないけどインターレースに起因するアーティファクトってことはないすか?
>エンコするとそのパタパタの周期が落ちて目立つようになってくる
っていう時点でエンコかける時点で避けられない劣化みたいに言ってるように見えるので。

まずこちらにやり方として、アニメのエンコとして異端なんだとは思うんだけど、
アニメだろうが何だろうが地デジソースは60iを60pに変換して24pは一切考慮しない。
なぜならばテロップは60iで動いてたりするし、一切誤爆のない60p→24p変換ってのもないと思うから。
そもそもエンコードの目的がtsの取り回しを良くするのと
リアルタイムI/P変換の品質が悪いのであらかじめ60p化しておきたいという目的だから。
60Hz以外のモニタ持ってないから60Hz系以外のフレームレートにしても意味ないし。

まあでもこれはこちらが60p化で止めてるものを24pに落とせばいいだけで、
むしろデータ量が多少減らせる(60pでもほぼ差分の無いフレームなので大差はない)ぐらいで
悪いことは特に起こらないと思うけど。

554名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 01:16:13.79ID:vZIrSnTK0
ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。
これならばtsを再生するよりもむしろきれいなソースが得られますぜ(所詮再生するためにはリアルタイムのI/P変換である必要があるから)。
ただしエンコードは(I/P変換が律速になるので)2〜5fpsを上回るのは無理。
まあここまで行かないにしてもTDeintとか使えば10fps〜20fpsぐらいの許容できるfpsでまず間違いない品質になると思うけど。

555名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 01:38:35.79ID:vZIrSnTK0
あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを
無理やり24Hzに落とし込むから比較的低周波のうなりになってしまって目立つという話なのかも

それなら60Hzソースを24Hzにすることに無理があって、
やるならばきれいに60p化したうえで時間軸のNRをしなさいということなのかも
(時間軸のNRをするのだから24Hzにしたあとやるのは論外)

556名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 01:42:18.29ID:TL71NAj40
>>553
ごめん、もう説明するの疲れたわ

QTGMCはBob化ベースだから細かい文字とか潰れるんだよね
だから、QTGMC掛けた後にソースから細かい文字だけマージするフィルタ作ったわ
SouceMatchやLossless使うよりも効果があって、処理も軽いよ!
x264 rev43©2ch.net	->画像>97枚

どうよこれ

あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて

557名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 02:16:24.06ID:TL71NAj40
やっぱ60p化が失敗とかなくていいよね

558名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? MM5e-CDhF)2017/10/22(日) 09:09:21.90ID:lDlFmsvMMVOTE
>>503
改造版のaufいただけませんか?
アド晒すので送ってください。

m y o k u 3 5 1 @ n e k o 2 . n e t

559名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? a511-/wYC)2017/10/22(日) 10:09:56.80ID:gaqeh3U00VOTE
>>556
githubのページで公開よろ

560名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? da60-FRG4)2017/10/22(日) 10:43:12.94ID:tb8EuU+Z0VOTE
普段からタブレットやスマホでx264でエンコした動画を再生しているのだが
PC(Windows)で再生するとバンディングだらけの動画でもタブレットやスマホで再生するとクリアに表示されるよな。
ほんとwindowsって動画再生の環境としては糞だよな。

561名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? fad2-yWqP)2017/10/22(日) 15:16:59.94ID:OGLUR6Q70VOTE
>>560
動画の出来をチェックするならバンディングとかちゃんと見えたほうがいいと思うのだが
きれいに見たいだけならWindowsでもレンダラ選べる再生ソフトに変えたらいいと思うぞ

562名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? d6e8-Doce)2017/10/22(日) 15:20:42.26ID:OuXW9nEl0VOTE
>>556
KTGMC、試すアル

>>559
もうあったぞ

563名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? 19a5-0GSP)2017/10/22(日) 15:42:09.87ID:TL71NAj40VOTE
>>558
これ実装したときはあまり効果がなかったなと思って、
改めて見てみたら、デフォルトのしきい値15は高すぎるんだった
8bitYUVの差1はだいたい5に相当するから、6〜10が適正値だね

>>474はしきい値が高すぎてかなり強く掛かってるから副作用出まくり
普通に使えばこんな副作用でない
しきい値6〜8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ

564名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? 1600-0GSP)2017/10/22(日) 15:47:02.38ID:iDXae9fs0VOTE
>>560
単にタブレットやスマホはコントラスト低いから目立たないだけじゃね
Windowsって言っても動画再生はGPUに依存する
Intelの内蔵GPUはクソ画質

565名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? 19a5-0GSP)2017/10/22(日) 16:11:54.86ID:TL71NAj40VOTE
>>558
期待させてすまん

566名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? MM5e-CDhF)2017/10/22(日) 17:35:45.57ID:vPHZ1rdJMVOTE
>>565
判定表示機能も欲しいので下さい

567名無しさん@そうだ選挙に行こう! Go to vote! (選挙行ったか? c5ec-h3yZ)2017/10/22(日) 19:36:05.24ID:huQNYVlR0VOTE
>>544
>で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
>で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
>MPC-HCとかオプションにディザのオプションとかあるでしょ
>だから、出力される絵は8bitでディザが残ってるのと同じような絵になる

LAV Video Decoderのディザリングのことかな?
10bit深度の動画を見るのにデコーダで8bit化して出力してる人なんているんだろうか?

10bit使うような人はmadVR使うとか、MPC-BEで内臓デコーダー+EVR-CPとかにして
10bitYUV4:2:0をそのままレンダラに渡すようにしてる人がほとんどだろうから、
LAVでディザリングするような使い方をしてる人はあまりいないのでは・・・?

568名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 20:15:07.70ID:TL71NAj40
>>567
8bit出力でも効果があるっていう原理を説明しただけ
ほとんどデフォのままでも10bitならきれいになる
モニタまで10bitで出力できるような環境ならそれでいいんじゃない

569名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 20:40:18.12ID:vZIrSnTK0
>>556
QTGMC(EdiMode="TDeint")
で、TDeintと同じように輪郭はボケなくなる
結局TDeintと動作原理は同じなのかもしれないけど、
QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる

まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、
コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然
60iで失われてるところをもっとも自然に補完するとこうなるんだと思う

570名無しさん@編集中 (ワッチョイ 818a-gcVe)2017/10/22(日) 20:45:30.50ID:vZIrSnTK0
>>568
というかYUVの8bitとRGBの8bitが1:1に対応してないから
最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、
RGBにディザをかけるかけないは全く不要だと思う
正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで

571名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/22(日) 21:07:13.27ID:huQNYVlR0
>>568
>モニタまで10bitで出力できるような環境ならそれでいいんじゃない

モニタが10bit対応かどうかは関係ないのでは。

1.モニタが10bit未対応
 (10bitYUV)→LAV→(10bitYUV)→レンダラが8or10bitRGBサーフェスに描画→(8bitRGB相当の出力)→モニタ

2.モニタが10bit対応
 (10bitYUV)→LAV→(10bitYUV)→レンダラが10bitRGBサーフェスに描画→(10bitRGB相当の出力)→モニタ

という違いが出るだけだし、10bitYUV→RGB変換はレンダラに任せるのが一般的だと思う。

一応

3.LAVでディザリングする場合
 (10bitYUV)→LAV(ディザリング)→(8or10bitRGB)→レンダラが8or10bitRGBサーフェスに描画
  →(8or10bitRGB相当の出力)→モニタ

という方法もあると言えばあるけども、LAVの出力をRGBに絞る必要があるし、使ってる人はほぼいないと思う。

572名無しさん@編集中 (ワッチョイ a198-iDVv)2017/10/22(日) 21:18:42.71ID:B85gEeQj0
で、x2648bitだけでデバンドはどうすりゃいいの?

573名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 21:47:50.35ID:TL71NAj40
>>569
そういう方法もあるのね
QTGMC(EdiMode="TDeint")だとQTGMCのベースの絵にTDeint使うけど、
>>556はQTGMCの後に補間するから原理はちょっと違う

確かにデフォルトのNNEDI3と比べてちょっとノイズっぽいのが増えるけど
動画で見ると分からないね

まぁ、ぶっちゃけコマ送りだと動いてるところはTDeint汚いけど
動画で見ると動いてるところは分からないから、TDeintだけでも十分なんだよなw

>>570
> RGBの8bitのバンディングなんて見えることはない

AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ

>>571
そうなんだ
素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの?

574名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/22(日) 22:12:53.38ID:huQNYVlR0
>>573
>AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ

試したことはないけど、高深度であっても、バンディングが発生するようなフィルタ処理をすれば
バンディングが発生するのは当然では・・・

>素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの?

10bitYUVを受け取ってくれる(渡して意味がある)レンダラは「madVR」と「MPC-BEのEVR-CP」かな。
MPDNあたりも大丈夫そうだと思うけど使ったことないのでわからん。
EVRやMPC-HCのEVR-CPではレンダラ内部のMixerでYUY2化されてしまうので無意味だったと思う。

575名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 23:05:21.80ID:TL71NAj40
>>574
> 10bitYUVを受け取ってくれる(渡して意味がある)レンダラは「madVR」と「MPC-BEのEVR-CP」かな。

なるほど、サンクス
レンダラが10bitに対応してなくても8bitRGBで渡せば問題ないよね
モニタまで10bitで出力したいって場合は別だけど

>>571
世の中の人は「madVR」か「MPC-BEのEVR-CP」を使うのが一般的なのか
mpc-hcとか使ってる人は「ほぼいない」のか
ちょっと認識にずれがあるようだ・・・

576名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/22(日) 23:29:03.38ID:huQNYVlR0
>>575
なんかうまく伝わってないようなので書いとくけど、

 ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。

 ・その場合、採用するのは>>571の1または2がほとんどであり、3(デコーダでRGB化)にしてる人はほぼいないだろう。

 ・1か2を採用する場合、madVR(多分ほとんどの人がこれかな)や、MPC-BEのEVR-CPを使うしかないだろう。

ということであって、世間一般という話はしてないよ。10bitユーザに関してはそういうものだろうという話。
まあ別に統計調査したわけじゃないけども。

3の方式にこだわる理由って何かあるの?

577名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/22(日) 23:35:46.02ID:TL71NAj40
>>576
そういうことね
>>568にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる

> 3の方式にこだわる理由って何かあるの?

世の中一般的な人の手を煩わせないこと

578名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 01:29:13.55ID:CCGuLeMv0
>>577
>世の中一般的な人の手を煩わせないこと

LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。

579名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 02:12:14.47ID:PdPTQ2n50
>>578
分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね

拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの?

580名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 02:28:08.64ID:PdPTQ2n50
あと

> ・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。

これは違うと思う
再生時は8bitでも、グラデーションがきれいになるから
10bitでエンコしてるって人は多いと思うよ

別に統計調査したわけじゃないけども

581名無しさん@編集中 (ワッチョイ da60-FRG4)2017/10/23(月) 03:22:20.83ID:GGoO9AOU0
265だが、12bitでエンコする人もいる。

582名無しさん@編集中 (ワッチョイ a550-0GSP)2017/10/23(月) 07:14:50.53ID:VYJgHsTz0
デバンド10bitがファイナルアンサーってことでおk?
めくらとめんどくさがりはデバンド無し8bitってことだよな?

583名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 09:52:34.86ID:GWH8jZaN0
>>582
1人で空騒ぎを続けてる姿はなんか見てて可哀相になるんだけど、戻れるならそろそろ正気に戻った方がいいんじゃ・・・

584名無しさん@編集中 (ブーイモ MM71-dNV6)2017/10/23(月) 10:52:56.78ID:ArbVx6vZM
無理です。こういうのは治りません

585名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 12:22:06.79ID:GWH8jZaN0
>>579-580

> デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとでどれくらい差があるの?

暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。

586名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/23(月) 12:24:02.28ID:GWH8jZaN0
>>579-580

>>574の後半は少し間違ってたかも。

 1.以前はEVR/EVR-CPにP010を渡してもうまく動かなかった。
 2.なので以前のLAVではEVR系にはP010ではなくNV12で渡すようにしていた。
 3.Win10CUからEVR系にP010を渡しても大丈夫になったので、LAV 0.70.0からは、
   Win10CU環境ではEVR系にもP010を渡すようになった。
 4.Win10CU環境でMPC-BEのEVR-CPにP010を渡してCtrl+Jを見るとMixerはA2R10G10B10になっているが、
   MPC-HCのEVR-CPだとMixerはYUY2になっている。
   そのため、EVR系で10bitを生かせるのはMPC-BEのEVR-CP(Mixer独自改良?)だけだと思っていた。

ということだったんだけど、昨夜うちのWin10CU環境でMPC-HCのEVR系を試してみたら
P010渡しならそれなりに綺麗に見えた。(寝ぼけてなければだが)

なので、Win10CU環境に限っては、MPC-HCをデフォで使ってもP010+EVR系で10bitをそれなりに生かせるのかも。

MixerがYUY2でも綺麗に見えたというのは釈然としないけど俺が何か勘違いしてるんだろか。

587名無しさん@編集中 (ワッチョイ 5568-6XL8)2017/10/23(月) 14:01:50.39ID:C3fk7LFm0
バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなw
折角低減されたバンディングが少し再発しててワロタw

588名無しさん@編集中 (ワッチョイ da60-FRG4)2017/10/23(月) 14:03:38.98ID:GGoO9AOU0
最小限、VLCでまともに見れれば問題ないんじゃね?っていう。
MPCはコーデックとかデコーダに依存しすぎるから少しでも環境が変わると
画質や動作にまで影響をお呼びしかねない。グラボのドライバを更新したとか
OSを大規模更新させたとかetc

589名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 17:00:31.81ID:PdPTQ2n50
>>585
> 暗めのグラデーションとかで試してみればわかると思うけど、
> デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。

これが違う。適切にディザリングされてればバンディングは発生しない

>>474の「デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff」を
LAVのデコーダで10bitYUV→8bitYUV変換してEVRで表示したときの画像
x264 rev43©2ch.net	->画像>97枚

これがバンディング出てるように見える?

>>474はAviUtlで読み込んでキャプチャしたから、
ディザリングなしで8bitRGBへの変換が行われてバンディングが出てるけど、
ちゃんとディザリングすれば8bitYUVへの変換でもバンディングは出ない

何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない

590名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/23(月) 18:01:02.87ID:PdPTQ2n50
MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
ボビングしてる。インタレ解除が下手なのかな

madVRはH264のノイズがそのまま出てて汚い

少なくともPascal世代のGeForce積んでるマシンなら、
WindowsデフォのEVRが画質は安定してる印象

なんか俺間違えてる?

591名無しさん@編集中 (ワッチョイW a161-rgn4)2017/10/23(月) 19:37:23.86ID:QlGXZ1na0
情報錯綜系LAVコメ

592名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/24(火) 02:20:01.25ID:n9jE2wGA0
>>590これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど

593名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/25(水) 01:53:37.49ID:63k5eUdT0
>>589-592
> 何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない

サンプルがあった方がいいだろうと思って10bitのグラデーション動画(プログレッシブ)を作成して
検証してまとめてみたけど、どうだろうか。

 10bitグラデーション映像の視聴時バンディング発生テスト
  まとめテキスト: https://pastebin.com/PjXMXesZ
  動画やスクショ等: https://www.axfc.net/u/3856752.zip

少なくともうちのIntelHD環境では、LAVでNV12にされたものをEVRで見ると、はっきりしたバンディングが発生する。
(madVRではディザリングでごまかしてそれなりに綺麗には見える)

もしこれがそちらの環境の「NV12→EVR」でバンディングが発生せず綺麗に見えるなら、
Pascalの映像補正処理によって、ごまかされて綺麗に見えているだけだと思う。

なんにせよ少なくともプログレッシブではP010で精細なデータをレンダラに渡す方が良いのは間違いないけど、
P010のインタレ解除対応とかについてはよくわからない。

594名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/25(水) 03:12:22.43ID:czTfBjnQ0
>>593
おーお疲れ。うちの環境でも表示のされ方はだいたい同じだったよ
なるほど、YUVでディザリングはしてるけど、YUV→RGB変換が1対1に対応しないから、
値を飛び越えちゃうところで色の違いが出てるのかなぁ
いろいろな影響があって難しいね

595名無しさん@編集中 (ワッチョイ da60-FRG4)2017/10/25(水) 10:09:56.42ID:8tRowaog0
>>593
ところで8bitで再生って具体的にどうやるんだ?

プレイヤーとかデコーダにそんな細かな設定項目はないだろ?

596名無しさん@編集中 (スップ Sd7a-86sF)2017/10/25(水) 12:33:28.30ID:9O9mFGbAd
>>595
無知な上にスレチな話題を無駄に広げるんじゃねーよ

597名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/25(水) 13:08:41.71ID:BioamKEC0
>>595
書いてあるとおり。NV12が8bitのYUV4:2:0。P010が10bitのYUV4:2:0。
以下のように、条件によってデコーダからレンダラへの出力が変わり、10bitを生かせるかどうかも変わるので、
LAV Video Decoderの設定でNV12とP010を切り替えて実験している。

●LAV Video Decoder+EVR

 ・Win10CU+LAV.70.0以上の場合
   (10bit4:2:0)→LAV→(P010)→EVR ⇒10bitソースを生かせる

 ・それ以外の場合
   (10bit4:2:0)→LAV→(NV12)→EVR ⇒10bitソースを生かせない

●MPC-BE(r2755)内臓デコーダ+EVR
  少なくともWin10CU環境では
    (10bit4:2:0)→MPC-BE(r2755)内臓デコーダ→(P010)→EVR ⇒10bitソースを生かせる
  となるが、OS条件などがあるかどうかは知らない。
  多分Win10CUあたりじゃないとうまくいかないんじゃないかと思う。

●LAV Video Decoder or MPC-BE(r2755)内臓デコーダ+madVR
  (10bit4:2:0)→デコーダ→(P010)→madVR ⇒10bitソースを生かせる

598名無しさん@編集中 (オイコラミネオ MM5e-CDhF)2017/10/25(水) 15:12:24.15ID:tWKQzPChM
そんなに気にするならソースのまま残せばいいじゃん

599名無しさん@編集中 (ワッチョイ 19a5-0GSP)2017/10/25(水) 17:42:00.74ID:czTfBjnQ0
>>597
俺が元々言ってたのは
「8bitソースを8bitでエンコして8bitで再生」するより
「8bitソースを10bitでエンコして8bitで再生」した方がきれいになるって話

「8bit or 10bitソースを10bitでエンコして10bit再生」した方がきれいだってのは
そりゃそうだけど、そんな話してなかったし、
「10bit動画をいかに綺麗に再生するか」って話はここだとちょっとスレチかも

600名無しさん@編集中 (ワッチョイ fad2-yWqP)2017/10/25(水) 18:05:21.56ID:jBdK3wWL0
エンコ前のソースではなく、デコーダに渡される10bitでエンコされたものをソースと言ってるように読める

601名無しさん@編集中 (ワッチョイ c5ec-h3yZ)2017/10/25(水) 18:24:39.81ID:BioamKEC0
>>599
そちらの話をきっかけに10bit動画の再生検証とまとめをしてみただけなのであまり気にしないでくれ。

>>600
あー、たしかに>>597の書き方は誤解を生んでしまうかも。
そちらの指摘どおり、「10bitソース」とあるのは「10bitエンコされた動画」のことです。

602名無しさん@編集中 (ワッチョイ fad2-yWqP)2017/10/25(水) 19:51:42.65ID:jBdK3wWL0
>>601
うにょんうにょんの話から始まってたのか
色々しらべてくれてありがとう

603名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 00:08:06.54ID:ly9F1jYY0
>>601
じゃあ、もう少し乗っかってみる
>>594で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた

環境はGTX1060でWindows10。全部MPC-BEでEVR-CPレンダラ

LAV→(NV12)→EVR(8bitサーフェス→8bitRGBディスプレイ)
x264 rev43©2ch.net	->画像>97枚
>>593とちょっと色の出方が違うけど、バンディングは同じようにも見える

LAV→(P010)→EVR(8bitサーフェス→8bitRGBディスプレイ)
x264 rev43©2ch.net	->画像>97枚
>>593のmadVR-P010-ditherONと同じような表示になった

LAV→(NV12)→EVR(10bitサーフェス→8bitRGBディスプレイ)
x264 rev43©2ch.net	->画像>97枚
>>593のmadVR-NV12-ditherONと同じような表示になった

604名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 00:10:27.95ID:ly9F1jYY0
Intelグラはディザリングしないんだね
うちのPascalだとレンダラで10bit→8bit変換するときはデフォでディザリングされるっぽい

605名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 00:19:52.85ID:ly9F1jYY0
画質にこだわるならグラボ導入をお勧めする

606名無しさん@編集中 (ワッチョイ 137f-UllU)2017/10/26(木) 01:44:20.96ID:83kz963X0
理由を論理的に教えて

607名無しさん@編集中 (オイコラミネオ MMab-7n1W)2017/10/26(木) 11:37:44.52ID:Lqu4m2pKM
UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
単純に再生時のフィルター処理やらせるかどうかの違いだろ
オンボサウンドが音質悪いからって、サウンドカード挿すぐらい滑稽(どっちもマザボ由来のノイズは乗る)

608名無しさん@編集中 (ワッチョイ 9390-w9fV)2017/10/26(木) 12:05:51.59ID:koiMQ39k0
>>603
うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1:GTX660→DVI接続→IPSパネル
モニタ2:4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える

GPUなのかモニタ原因なのか接続方法なのか…オモシロw

609名無しさん@編集中 (オイコラミネオ MMab-7n1W)2017/10/26(木) 12:10:12.06ID:h1bMYZBgM
比較するなら何故接続方法とディスプレイを同じにしないのかなぁ
一円にもならない雑音でしかないぞ

610名無しさん@編集中 (ワッチョイ d360-H4ak)2017/10/26(木) 13:52:56.00ID:FitUuNIK0
>>603
どうせ比較するならカラーバーにしてほしかった。
何故黒背景なんだ?違いがわかりにくすぎるわ。

611名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/26(木) 17:37:30.49ID:bZqhxTl+0
>>603
うーん・・・うちでそれらの画像を>>593(うちのIntel環境の結果)と比べると以下のように全然違って見えるけど・・・。

1番目(NV12+EVR)
 少しバンディングの出方が異なるが、「EVRCP-NV12」とほぼ同じくらい。

2番目(P010+EVR)
 P010出力なのに、3つの中で画質が最も酷い。細めの汚れたバンディングがはっきり見える。
 「madVR-P010-ditherOff」で生じているバンディングを更に悪化させたような感じ。
 「EVRCP-P010」や「madVR-P010-ditherON」の方がはるかに綺麗。

3番目(NV12+EVR(10bitサーフェス))
 「madVR-NV12-ditherON」と似てはいるが、ざわつきが酷く画質としては劣る。
 バンディングがほぼ気にならないレベルになってるのは
 10bitサーフェスをデスクトップ(8bitRGB)に統合する時に、もう一度ディザリングしているのかな?
 結果的にバンディングが目立たなくなっているとはいえ、無駄な処理をしているとも言えるような。

うちはノートPCでモニタも6bit+FRCなTNというショボ環境だから、他の人の結果や意見も聞いてみたいところ。

612名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/26(木) 17:45:49.30ID:bZqhxTl+0
>>603
2番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも?

>>604-605
> Intelグラはディザリングしないんだね

ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」(LAVがレンダラに渡しているデータ)と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。

>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー?

613名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/26(木) 17:58:50.33ID:bZqhxTl+0
まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。

614名無しさん@編集中 (ワッチョイ 9111-Akqv)2017/10/26(木) 19:59:26.61ID:cJclLwoB0
スケーラー的には
カスタムEVRのほうが比較対象になりえるかと

615名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 22:29:15.67ID:ly9F1jYY0
>>611
こちらは4Kブラビア(KJ-49X8300D)にAVアンプ(AVR-X2100W)経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う

616名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/26(木) 23:26:47.90ID:ly9F1jYY0
>>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ

617名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/27(金) 00:05:48.90ID:lbq/6KPv0
>>614
スケーラーってなんぞ?madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな?

>>615-616
8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・?
>>611に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060+そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。

618名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/27(金) 00:52:10.89ID:XMw2Db120
>>617
> EVR-CPのP010処理が何か変

おかしくはないよ
うちの環境で「BE-白050-線-EVRCP-P010」を写してカメラで撮ってみた

>>593の画像
x264 rev43©2ch.net	->画像>97枚

>>603の画像
x264 rev43©2ch.net	->画像>97枚

619名無しさん@編集中 (ワッチョイ d9a5-20SA)2017/10/27(金) 01:02:44.22ID:XMw2Db120
一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる

ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない

620名無しさん@編集中 (ワッチョイ 9111-Akqv)2017/10/27(金) 09:54:55.94ID:s36iLAYK0
>>617
EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず

だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも

621名無しさん@編集中 (ワッチョイ 13ec-DRuk)2017/10/27(金) 21:30:55.30ID:ZmaiasnV0
>>618-619
申し訳ない。こちらがボケてました。
 > 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。

もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。

>>620
拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。

622名無しさん@編集中 (ワッチョイ 9111-Akqv)2017/10/27(金) 23:21:04.83ID:s36iLAYK0
>>621
プルダウンで簡単に使えるのが利点っちゃ利点>EVRカスタム

623名無しさん@編集中 (ワッチョイ d9a5-Akqv)2017/10/28(土) 12:50:01.41ID:MkHSDZTa0
>>621
白111-P010-EVRCP(8bitサーフェス)
x264 rev43©2ch.net	->画像>97枚

624618 (ワッチョイ d9a5-Akqv)2017/10/28(土) 12:51:23.89ID:MkHSDZTa0
ID変わってた

625名無しさん@編集中 (ワッチョイW 1b1e-QeyJ)2017/10/28(土) 14:34:52.13ID:FG5EURDq0
サンプルは>>516が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw

626名無しさん@編集中 (オイコラミネオ MMab-PCft)2017/10/28(土) 16:07:06.26ID:aZTaLCEhM
バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな?
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの?

627名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/28(土) 22:29:00.96ID:hchLrIBF0
>>623
ありがとうございます。参考にさせてもらいます。

>>626
そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。

628名無しさん@編集中 (ワッチョイ 9111-9/99)2017/10/28(土) 23:31:24.66ID:k7D3xxA+0
>>626
基本的にソースにあるバンディングを消すものだよ
けど、ソースを少なからず弄るものだから
冒頭の極端なものは無視するが吉

629名無しさん@編集中 (ワッチョイ 1334-aAnL)2017/10/29(日) 09:40:11.40ID:dhWMtRCq0
MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか?

630名無しさん@編集中 (ワッチョイ ebe8-caiW)2017/10/29(日) 09:43:54.16ID:BrtN7tba0
no-info パラメータって x264 にはないんだっけ?

631名無しさん@編集中 (ワッチョイ ebe8-caiW)2017/10/29(日) 09:45:36.07ID:BrtN7tba0
>>630
あったとしても、エンコード日付までは消せないか
ソースいじって自ビルド使うしかなさそう

632名無しさん@編集中 (スプッッ Sd33-j0vi)2017/10/29(日) 10:25:41.22ID:KYvLeTqdd
エンコード日とかって
muxし直したら新しく書き換えられるから
x264とはまた別じゃないかな?

633名無しさん@編集中 (ニククエ 13ec-DRuk)2017/10/29(日) 12:30:57.98ID:NansAZRP0NIKU
>>632が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから
Muxだけやり直せば上書きされるはず。

634名無しさん@編集中 (ワッチョイ ebe8-T257)2017/10/30(月) 09:36:19.37ID:uLnu7qaJ0
muxプログラムを改変する

635名無しさん@編集中 (アークセー Sx9d-egjV)2017/10/30(月) 15:01:11.04ID:720xvp1Sx
わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな

636名無しさん@編集中 (ワッチョイ ebe8-T257)2017/10/30(月) 15:02:21.57ID:uLnu7qaJ0
P2Pなんでまだあんのか?

637名無しさん@編集中 (ワッチョイ d1ec-DRuk)2017/10/30(月) 15:49:28.52ID:3lz3qnqA0
違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。

638名無しさん@編集中 (ワッチョイ d1eb-ogJj)2017/10/30(月) 16:38:40.79ID:rJwJGDaI0
ボクが一番早くエンコしたんだッ!

639名無しさん@編集中 (ワッチョイ 1334-aAnL)2017/10/30(月) 20:41:33.46ID:cDns2kcE0
ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。

640名無しさん@編集中 (ワッチョイ d360-H4ak)2017/10/31(火) 11:38:38.08ID:TbmUAHOn0
>>635
デカ過ぎるcrf値にしていたり、ダイエットし過ぎたbitrate値にしているのをバレたくないとかじゃね?

641名無しさん@編集中 (ワッチョイ d360-H4ak)2017/10/31(火) 11:45:43.27ID:TbmUAHOn0
あとはme dia にしてるのをバレたくないとかw

642名無しさん@編集中 (オイコラミネオ MMab-PCft)2017/10/31(火) 12:28:54.81ID:jvMJnAPgM
>>639
それなら単純にファイラーで作成日時いじればいいだけなのは明らかにわかる
火消し必死な自称エンコ職人の違法アップロード野郎

643名無しさん@編集中 (ワッチョイ a9ec-DRuk)2017/10/31(火) 14:36:40.95ID:41mjP/K80
>>640-641
>>629が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。

>>642
「(ファイラーで)作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。

644名無しさん@編集中 (ワッチョイ 13d2-kgpv)2017/10/31(火) 18:31:40.36ID:IvmGk3l40
>>641
ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ

645名無しさん@編集中 (ワッチョイWW e15c-3RSi)2017/11/05(日) 19:56:26.63ID:PcnMP+Wd0
x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか?

646名無しさん@編集中 (ワッチョイWW 4968-2eRG)2017/11/05(日) 22:57:38.08ID:w1/54n9e0
悩む必要ないだろ

647名無しさん@編集中 (オイコラミネオ MMd6-arz0)2017/11/06(月) 09:49:57.89ID:fjXKV0Z6M
>>645
両方ともグリスバーガーだから、オーバークロック前提ならRyzenスレッドリッパー1950Xだろ
殻割りで壊すリスク冒すなら7920Xでもいいが

648名無しさん@編集中 (ワッチョイWW e15c-YD3/)2017/11/06(月) 12:20:23.32ID:nWEh0PuI0
オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか?

649名無しさん@編集中 (スッップ Sd62-2eRG)2017/11/06(月) 12:45:07.90ID:PJNEo3fvd
スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば?
それでもコア数多い7920Xの方が速いだろうけど

650名無しさん@編集中 (ワッチョイ 2260-apvC)2017/11/06(月) 13:05:09.71ID:AhYKSv2j0
threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。

Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。

651名無しさん@編集中 (ワッチョイ 92eb-Q/5A)2017/11/06(月) 13:12:22.24ID:oJ3dfrAb0
4〜8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた

652名無しさん@編集中 (ワッチョイWW e15c-6D9a)2017/11/06(月) 16:34:37.78ID:X8UDX3Yv0
貴重なご意見いろいろと感謝でごわす。

653名無しさん@編集中 (アウアウカー Sa69-eUv6)2017/11/07(火) 09:07:41.08ID:qqxdUWwBa
並列でエンコードすればよいのでは?

654名無しさん@編集中 (ワッチョイWW 2ee8-mNd+)2017/11/07(火) 09:14:27.30ID:JI9elUeS0
良いプラグインを選んだり自分で最適化ビルドして
うまいことavsを書けばコア数の多さを
純粋に速度upに繋げることはできる

655名無しさん@編集中 (スップ Sd62-NeHO)2017/11/08(水) 15:50:54.81ID:b8akNCrvd
x264のソースで、
参照しているマクロブロックについて
書かれているところが分かる人いないかな?

656名無しさん@編集中 (ワッチョイW e19f-43gl)2017/11/08(水) 21:48:17.18ID:QomPI2yH0
CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね

intel vtune買えるほど、こずかいあったら解析してみたいなー

657名無しさん@編集中 (オイコラミネオ MMd6-ngDX)2017/11/08(水) 21:53:09.78ID:2xU4/lpbM
メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない

658名無しさん@編集中 (アークセー Sx33-WtbZ)2017/11/09(木) 03:55:05.26ID:2lLHGB5mx
x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
対応してたとしても、例えばHuffyuvのデコードは4スレッドまでしか対応してないし
あとは、ドライブの転送速度が追い付いてないとか

659名無しさん@編集中 (ワッチョイ 5f11-02TF)2017/11/09(木) 12:08:59.88ID:dAkiAuRl0
>>656
h.264の基本設計が古いのが原因

660名無しさん@編集中 (ワッチョイW 5f2c-WxHz)2017/11/09(木) 21:23:04.94ID:4E6+DEQl0
>>659
は?

661名無しさん@編集中 (ワッチョイ 7feb-lB0v)2017/11/09(木) 23:26:26.85ID:8skGIZpd0
>>648
6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな

662名無しさん@編集中 (スッップ Sd9f-voEu)2017/11/10(金) 01:06:53.06ID:6Gf3GwUMd
>>661
Doomで中の人が言っていたから本当
だが、それはSDサイズの話だろう
SDで6950Xだと70%くらいしか使わないんじゃないか?

663名無しさん@編集中 (ワッチョイW 5f9f-4gwp)2017/11/14(火) 22:36:13.81ID:QgQDG7qe0
x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる?

公式より、ちょこっと高速かも。

664名無しさん@編集中 (ワッチョイ 7f8a-ySnM)2017/11/14(火) 23:31:21.00ID:Y7L7Tzex0
バイナリよりもソースコードが欲しい

665名無しさん@編集中 (ワッチョイ 5fc6-Ud84)2017/11/14(火) 23:54:34.74ID:OmCERatJ0
最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
あれが対応しないと微量(6-8fps前後)だがエンコ速度に差が発生するから損した気分になる。

666名無しさん@編集中 (ワッチョイW 419f-o34E)2017/11/16(木) 12:20:04.93ID:Lok3SOLr0
x264をvtuneで解析する方法

./configure ―extra-cflags=“-g3 -gdwarf-2”

667名無しさん@編集中 (ワッチョイ 419f-CT75)2017/11/16(木) 21:39:08.85ID:Lok3SOLr0
下手に触ったら、弄りすぎて壊れた…

x264の内部

関数内の処理時間順
x264 rev43©2ch.net	->画像>97枚
呼び出し回数順
x264 rev43©2ch.net	->画像>97枚

668名無しさん@編集中 (ワッチョイ 419f-CT75)2017/11/18(土) 15:36:47.29ID:mg/31u3f0
Intel C compilerで作った x264@0.152.2851
https://dotup.org/uploda/dotup.org1391216.zip.html
ソースは、弄ってないバージョン

バイナリの環境はSandybridge以降に依存
依存したDLLとか調べてないから、動かなかったら教えて。


自分でビルドしたい人は、msysのlinkerをmvしたりしないと通らないから要注意

669名無しさん@編集中 (ワッチョイ 25c6-bpph)2017/12/03(日) 22:51:56.93ID:MUdUJt2U0
>>667
その画像、jane styleでdecode errorになるのだが・・・つかえねぇなほんと。
画像うpするなら自分で消さなきゃなかなか消えない、imgurを使えよ。

670名無しさん@編集中 (ワッチョイ 3d9f-GQwd)2017/12/03(日) 23:17:58.10ID:N46X2NJO0
俺のjane styleではちゃんと表示できてるぞ
むしろimgurのがdat入れたりせにゃあかん

671名無しさん@編集中 (ワッチョイ 9e11-HgL3)2017/12/03(日) 23:48:24.68ID:EBQZzVDS0
今、ブラウザでアクセスしたけどリンク切れだったよ
専ブラのキャッシュに残ってるのでは?

672名無しさん@編集中 (ワッチョイ 25c6-bpph)2017/12/03(日) 23:55:28.12ID:MUdUJt2U0
結局janeのビューアが改善すればいいだけの話か。
susieプラグインとか2004年頃から更新されてないもんな・・・

673名無しさん@編集中 (ワッチョイ 937f-3E9j)2017/12/23(土) 15:27:24.06ID:a6JnGRMU0
r2345
誰か持って無いですか?VLCのはx264guiExに怒られるし
kmodはアーカイブ辿ってもないし

674名無しさん@編集中 (ワッチョイ a3ec-615/)2017/12/23(土) 21:21:11.03ID:VSoAQ8Gh0
>>673
怒られるっつっても
  指定されたx264.exeはmp4出力に対応していません。
  出力拡張子を".264"に変更して出力を行うため、muxが余分に発生し、時間がかかる可能性があります。
  mp4出力に対応したx264.exeを使用することを推奨します。
と出るだけだから、何か試す程度ならVideoLANのバイナリでいいと思うが・・・。

muxがどれくらい遅くなるのかは知らないけど、わざわざr2345を常用したい理由でもあるの?
x264guiExも最新のバイナリにあわせて更新されてるから、
古いバイナリを使ったら設定値が思うように反映されなかったりすることもあるけど。

675名無しさん@編集中 (中止 7398-GItX)2017/12/24(日) 13:25:40.34ID:3pc8lJGL0EVE
自ビルドすればいい
たいして、手間はかからないだろ
何をしたいのか理解できないけど

676名無しさん@編集中 (中止 cfe8-H9DT)2017/12/24(日) 13:47:04.26ID:PblLLtX90EVE
ソースもみつからないんだろうよ

677名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 00:09:20.14ID:3pbDkQUJ0XMAS

678名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 00:12:41.45ID:3pbDkQUJ0XMAS
基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ
でないともれなくウザいジャンクマルウェアがブラウザをフリーズさせようとするからw

679名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 00:40:15.29ID:3pbDkQUJ0XMAS
r2345にこだわる理由はおそらくこれじゃないか。
AMD環境でエンコするときは、r2345以降だと拡張命令が一つ無効にされるから
若干エンコが遅くなる。そこはryzenで改善されたけど

r2346
commit 0c738e30ec025f0effdb62802685fce40cf20057
Author: Henrik Gramner
Date: Fri Jul 5 21:15:43 2013 +0200

x86: Remove X264_CPU_SSE_MISALIGN functions
Prevents a crash if the misaligned exception mask bit is cleared for some reason.
Misaligned SSE functions are only used on AMD Phenom CPUs and the benefit is miniscule.

---
x86: X264_CPU_SSE_MISALIGN関数を削除。
何がしかの理由でmisaligned exception mask bitがクリアされていた場合のクラッシュを防ぐ。
Misaligned SSE関数はAMD Phenom CPUでのみ使用され、その利得は非常に小さい。

680名無しさん@編集中 (中止 73b5-buzn)2017/12/25(月) 12:34:34.96ID:64mfmyLL0XMAS
ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから
買い換えるという選択肢がないかもしれないけどRyzenはマジで優秀だからな
それなりにエンコする機会があるなら買って損はないと思う
性能がそこそこ優秀な割に異常に安価な1500Xあたりで組めばそれなりの価格で収まるし電気代も優しい

681名無しさん@編集中 (中止 237f-3E9j)2017/12/25(月) 16:35:53.17ID:YUlv4pKh0XMAS
>>677
ありがとうございます。理由は>>679氏の指摘です
本当に助かりました

682名無しさん@編集中 (中止 6f11-buzn)2017/12/25(月) 17:43:40.36ID:hZyUPP7q0XMAS
たしかそれ以降にもAMD向けのはガッツリ削られたんだっけ?>XOPとか

683名無しさん@編集中 (中止 Sx87-/Td7)2017/12/25(月) 18:01:10.84ID:leIDQpx9xXMAS
>>680
ryzenAPU(GPU内蔵)が来年頭に出るらしいから、コンシューマ向けだとそれで完全に事足りるわな
ただし4コアしか出さないらしい

684名無しさん@編集中 (中止 03c6-RBuR)2017/12/25(月) 19:28:13.40ID:3pbDkQUJ0XMAS
余談だが、ブル世代のAPUとFXもMisaligned SSEが使えるわけだけど、それも無効にされている。
APUはVCEでハードエンコできるからまだいいが、FXは限界までOCしてゴリ押しするしか無いんだよな。

685名無しさん@編集中 (ワッチョイ 638a-7LW1)2017/12/26(火) 11:10:32.20ID:MqszZ9OX0
r2893

686名無しさん@編集中 (ワッチョイ cf90-2X9o)2017/12/27(水) 21:16:05.28ID:zQsT06DJ0
暖房用にx264を全力で走らせてるんだが中々部屋が暖まらない寒いよー
冬季向けりヴぃじょんとかありますか?

687名無しさん@編集中 (ワッチョイ 13a5-buzn)2017/12/27(水) 21:32:58.33ID:A7c/BO+S0
フィルタ処理をGPUにやらせて、PC台数も増やせば結構暖まるよ

688名無しさん@編集中 (ワッチョイ f346-cSU3)2017/12/27(水) 23:48:27.66ID:7YvG+X4m0
PCの排熱を使用した暖房機器で電気代タダってのが外国でやってなかったっけ

689名無しさん@編集中 (ワッチョイ af17-M2I0)2017/12/28(木) 01:23:11.91ID:Hdam5um00
マイニング

690名無しさん@編集中 (ワッチョイ 3aeb-RYVm)2017/12/28(木) 01:42:45.33ID:AFh2AJRd0
副次的に温まるのは仕方がないが暖房に使おうという発想はおかしい

691名無しさん@編集中 (ワッチョイ ffb5-Auke)2017/12/28(木) 02:17:54.51ID:gCKZ0KCj0
電熱による暖房は効率が悪いからな
電気暖房で効率重視なら現状ヒートポンプ一択
とはいえコスト度外視ならハイエンドPCを2台もフル回転させれば多分ちょっとしたセラミックヒーターくらいの発熱はあるはず
ただ熱を垂れ流すしか能がないヒーターよりは何らかの仕事をさせられる分だけ建設的なのかも知れん

692名無しさん@編集中 (ワッチョイWW de9a-zsQs)2017/12/28(木) 02:31:54.29ID:O4ji26IE0
いや〜ん

693名無しさん@編集中 (ワッチョイ cbec-O50F)2017/12/28(木) 13:39:09.46ID:afSjZm/R0
なんとなくr2893メモ

・8bitと10bitのバイナリを統合
 →1つのバイナリで8bitも10bitも出力できる。
 →出力ビット深度は、追加された --output-depth で指定。デフォルトは8bit。

・--transferに arib-std-b67 を追加。(HLG:Hybrid Log Gamma)
・--colormatrixに chroma-derived-nc / chroma-derived-c / ICtCp を追加。
 →2017年4月のH.264規格書で追加されたもの。

・--alternative-transferを追加
 →2017年4月のH.264規格書で追加されたもの。

・その他の細かいコミットは割愛

・--fullhelpでのqpmaxのデフォルト値表示がおかしい。
  --qpmax <integer> Set max QP [2147483647]

・x264guiExの8/10bit統合対応が地味に面倒そうではある。

694名無しさん@編集中 (ワッチョイ 83c6-SYER)2017/12/28(木) 14:26:10.04ID:k6Qd+NbI0
10bitでエンコしてると8bitでエンコする機会なんて格段に減ると思うのだが。

695名無しさん@編集中 (アークセー Sx03-JsY/)2017/12/28(木) 14:28:57.26ID:oE/hHUIQx
放送物はBDMV準拠で保存してるから、逆に10bitでエンコする機会がない

696名無しさん@編集中 (ワッチョイ f316-Auke)2017/12/28(木) 15:30:50.89ID:7aUzwO6o0
自分の好きなようにしたらエエ。
俺は PC で再生するだけだから 10bit 派。
そのくせ BlueskyFRC を挟んでFluid Motion してるから余り意味が無いという。

697名無しさん@編集中 (ワッチョイ 83c6-SYER)2017/12/28(木) 16:45:46.07ID:k6Qd+NbI0
x264.exeにフィルタ機能とかリサイズ機能とか正直いらないんだよな。
そういうのはAVSでやらせりゃいいんだし。

698名無しさん@編集中 (オイコラミネオ MM56-UTV3)2017/12/28(木) 17:58:21.58ID:PElpFoJXM
linuxでもWindowsでも同じようにフィルタかけられて便利

699名無しさん@編集中 (ニククエ cbec-O50F)2017/12/29(金) 21:05:04.38ID:dM0UDBZS0NIKU
x264guiEx 2.53、r2893バイナリ対応

700名無しさん@編集中 (ワッチョイ 67fa-MiNv)2017/12/31(日) 11:38:00.81ID:90rtTOjH0
誰でも自分PCで稼げる方法など
参考までに、
⇒ 『政道のゴウイウセレイイ』 というHPで見ることができます。

グーグルで検索⇒『政道のゴウイウセレイイ』

A6L4JIAVLJ

701名無しさん@編集中 (ワッチョイ 0a0e-Auke)2017/12/31(日) 12:00:58.03ID:u4+XlIJ20
Komiser更新されないなあ

702名無しさん@編集中 (ワッチョイ cbec-O50F)2017/12/31(日) 13:19:58.29ID:dk79hbO30
× Komiser
〇 Komisar

tmodもまだだね。

703名無しさん@編集中 (ワッチョイ 077f-XPej)2018/01/01(月) 14:51:32.47ID:RHbXXe2Q0
今回modは判別ルーチン入れる必要あるしテストも含めて時間掛かるんじゃ

704名無しさん@編集中 (ワッチョイ c611-Auke)2018/01/01(月) 21:35:23.29ID:dlGBebkV0
10bit版のパッチがなかったら移植の手間がかかるのでは

705名無しさん@編集中 (ワッチョイ 9fec-BEZ7)2018/01/05(金) 12:33:57.79ID:Pcgh0yt50
tmodのr2893が来てた。
パッチとの互換性を考えてffmpegは2.8.xのままとか、新しいブランチ作ったとかのWARNINGあり。https://github.com/jpsdr/x264/releases

kmodはまだ来てない。

706名無しさん@編集中 (ワッチョイ 2bb3-dJp/)2018/01/07(日) 00:59:09.06ID:mh9JPq/j0
help見るとr2867になってるね

707名無しさん@編集中 (ワッチョイ 0fe8-Xk1J)2018/01/07(日) 04:48:21.14ID:8MeYYXbe0
>>706
ホントだ

708名無しさん@編集中 (ワッチョイ bbec-BEZ7)2018/01/07(日) 15:36:59.83ID:uxim0//O0
>>705-707
WARNINGに少し書かれてるけどjpsdr版tmodのr2893(実際にはr2867+74)について。

・バージョン表記→ x264 core:155 r2867+74 66b5600 t_mod_Custom_2

・tmod用の各種パッチの互換性確保を優先して公式コミットを省いたりしているので、
 公式のr2893とは大きく異なるものになっている。
 8/10bit統合もしておらず、別バイナリのまま。ffmpegも古いv2.8.13のまま。

・r2867までは公式masterと同じなのだが、その後はr2893までの26個のコミットのうち、
 8/10bit統合のr2868を始めとした13個の公式コミットが省かれている。
 (x264_Customブランチ。コミット数2880(2867+13)(2893-13))

・x264_Customブランチをベースに各種パッチを当てていった
 t_mod_Custom_2ブランチ(コミット数2941)を元にバイナリがリリースされている。
 r2867+公式13+パッチ61ということで、r2867+74。

709名無しさん@編集中 (ワッチョイWW 6b76-5Um6)2018/01/07(日) 19:43:34.12ID:WmxR42qr0
3行で頼む

710名無しさん@編集中 (ワッチョイ 0fe8-Xk1J)2018/01/07(日) 19:48:26.48ID:8MeYYXbe0
>>708
説明お疲れ様です

>>709
公式とは別物
コアな機能改善が省かれてるかどうかはわからない
.

711名無しさん@編集中 (ワッチョイ 2bb3-dJp/)2018/01/08(月) 00:29:53.77ID:nnJbUV+b0
個人的に分割してくれたほうがいい気がする(1つに集約=その分重くなる?)
x265.exeでも感じたけど・・・

712名無しさん@編集中 (ワッチョイ bbec-BEZ7)2018/01/08(月) 02:01:12.14ID:sREVb2Z30
うちでr2851kModとr2893(rigaya版)を一発比較した限りじゃ特に変わらんようだけど。

■8bit

【x264】x264 0.152.2851kMod ba24899 (8bit)
 【オプション】--crf 20
 【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
 【. Slower】 10.73 fps, 3954.37 kb/s, duration 0:01:45.11
 【   Slow】 21.50 fps, 4047.44 kb/s, duration 0:00:52.47
 【. Medium】 28.53 fps, 4094.00 kb/s, duration 0:00:39.54
 【Veryfast】 62.89 fps, 4100.91 kb/s, duration 0:00:17.93

【x264】x264 0.155.2893 b00bcaf
 【オプション】--crf 20
 【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
 【. Slower】 10.88 fps, 3954.36 kb/s
 【   Slow】 21.07 fps, 4047.44 kb/s
 【. Medium】 28.93 fps, 4094.00 kb/s
 【Veryfast】 62.15 fps, 4018.47 kb/s

713名無しさん@編集中 (ワッチョイ bbec-BEZ7)2018/01/08(月) 02:02:25.09ID:sREVb2Z30
■10bit

【x264】x264 0.152.2851kMod ba24899 (10bit)
 【オプション】--crf 20
 【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
 【. Slower】 6.77 fps, 3923.71 kb/s, duration 0:02:46.73
 【   Slow】 15.43 fps, 4072.16 kb/s, duration 0:01:13.09
 【. Medium】 20.43 fps, 4141.27 kb/s, duration 0:00:55.21
 【Veryfast】 40.21 fps, 4171.15 kb/s, duration 0:00:28.05

【x264】x264 0.155.2893 b00bcaf
 【オプション】--crf 20 --output-depth 10
 【入力ファイル情報】test-1080p.mkv 1920x1080p 1:1 @ 24000/1001 fps (cfr) 1128frames
 【. Slower】 6.59 fps, 3923.71 kb/s
 【   Slow】 14.98 fps, 4072.15 kb/s
 【. Medium】 20.74 fps, 4141.26 kb/s
 【Veryfast】 41.27 fps, 4115.07 kb/s

714名無しさん@編集中 (ワッチョイ efe7-SQYW)2018/01/09(火) 00:08:32.01ID:JJKYVbAG0
普通に考えて8bitか10bitか毎フレーム判断するわけないわな

715名無しさん@編集中 (ワッチョイ 9b7f-hL1C)2018/01/09(火) 00:54:02.42ID:Hfl6BYFl0
Komisar何やっとるんだ?

716名無しさん@編集中 (ワッチョイ ef7f-D1bd)2018/01/09(火) 01:05:42.16ID:R6ucHgby0
別に仕事でやってるわけじゃないんやで

717名無しさん@編集中 (ワッチョイ ebc6-+W2v)2018/01/09(火) 02:00:22.72ID:qOe0KmCS0
60000/1001で同じようにエンコしてどのぐらい出るか知りたい。
動きの多いアニメや殆どの実写映像も60fpsでエンコさせるとヌルヌル動いて気持ちいいし

718名無しさん@編集中 (アークセー Sxcf-ZvWl)2018/01/09(火) 05:08:35.40ID:88bv/YTOx
crf20でそんなに縮むのはアニメだからだな
実写でcrf20なんてやったら12Mbpsなんて軽く越える

719名無しさん@編集中 (ワッチョイ 0ffb-+W2v)2018/01/09(火) 12:12:39.70ID:dbYDA8uS0
>>717
アニメで60fpsとかよそで言うと恥ずかしいから気をつけろよ

720名無しさん@編集中 (ワッチョイ ebc6-+W2v)2018/01/09(火) 12:51:44.97ID:qOe0KmCS0
何がだよ。SAOの映画とか60fpsでエンコしてみろ、動きがヌルヌル過ぎてすげー気持ちいいから

721名無しさん@編集中 (ワッチョイ cbeb-Ogju)2018/01/09(火) 13:04:15.79ID:BobtuyPM0
映像自体が60のアニメもまったく無いわけではないがごく一部だけだな

722名無しさん@編集中 (ワッチョイ ebc6-+W2v)2018/01/09(火) 13:12:14.00ID:qOe0KmCS0
特にエンディングのスタッフロールとかは60fpsでエンコすると
テロップ類の動きがヌルヌル過ぎてすげー気持ちいい。
RPGとかのエンディングみたいに最後まで飛ばさず見よう!って気になるw

723名無しさん@編集中 (ワッチョイ bbec-BEZ7)2018/01/09(火) 16:24:41.33ID:cLDLIUCj0
>>717 >>722
フレーム補間という手法を覚えたばかりではしゃぎたくなるのはわかるけど、スレ違いなので他でやっとくれ。
何を使ってフレーム補間してるのか知らないけど、逆テレシネしてないアニメをソースにしたり
いまどきMBlockFPS()を使ってるなんてオチがなければいいけど。

>60000/1001で同じようにエンコしてどのぐらい出るか知りたい

エンコード速度(fps)は毎秒どれだけのフレームを処理できるかを表すので、元動画のフレームレートは関係ない。
フレーム数が増えれば必要時間は増えるし、フレーム補間してるならその負荷がかかるけど
それはx264とは別の話なのでこのスレでは関係ない。


>>718
>>712-713のtest-1080p.mkvは、x264/x265ベンチマークスレで使ってる実写映画の予告動画だよ。

724名無しさん@編集中 (ワッチョイ 0f81-hL1C)2018/01/10(水) 02:37:24.51ID:OxVNvmBN0
病院行け

725名無しさん@編集中 (ワッチョイ 0ffb-+W2v)2018/01/10(水) 09:21:00.19ID:CFbPtkjP0
>>722
このスレでも無知を晒し続けるのマジで恥ずかしいからそれ以上やめろ
俺の共感性羞恥に効く

726名無しさん@編集中 (オイコラミネオ MM7f-ZvWl)2018/01/10(水) 09:25:38.85ID:OIe9TqRjM
一時期あった30/24混合のアニメは面倒だからインタレ保持でやってる

727名無しさん@編集中 (ワッチョイ ebc6-+W2v)2018/01/10(水) 11:21:20.18ID:7k1pcodv0
>>724
なんの病名だよエンコード病とかか?w

728名無しさん@編集中 (ワッチョイ 9fd2-Gfid)2018/01/10(水) 12:55:19.73ID:lXjmbGhD0
むしろ動いてないところは削りまくってタイムコードで引き伸ばしてるわ

729名無しさん@編集中 (ワッチョイ 3b98-H65A)2018/01/10(水) 15:08:45.13ID:W8NHXz/H0
60iを60pにしたというオチじゃないよな
テレビ放送をテレビで見ると60fpsで見てることすら知らなさそう

こんなことで喜べるんだから、無知っていいな
羨ましすぎる

730名無しさん@編集中 (ワッチョイ 9fb3-+zXm)2018/01/10(水) 16:45:54.81ID:AJNxVRak0
昔からドラマのOPをヌルヌル綺麗にエンコしたいとか散々見たような

731名無しさん@編集中 (ワッチョイ ebc6-+W2v)2018/01/10(水) 20:59:31.15ID:7k1pcodv0
>>729
上から目線で他人のエンコ趣味をコケにしてそんなに楽しいかね?

732名無しさん@編集中 (ワッチョイ 4b9f-93ie)2018/01/10(水) 22:06:14.43ID:gCKQuqGL0
フレーム補間の60fps化だろ
実はわざわざエンコ時じゃなくて再生時にできるって知ったら発狂しそう

733名無しさん@編集中 (スッップ Sdbf-awjz)2018/01/10(水) 22:15:29.99ID:U2nTnab9d
エンコ時にフレーム補間出来るツールがあるのか?

734名無しさん@編集中 (ワッチョイ 2b16-hL1C)2018/01/10(水) 22:19:27.15ID:7eoFLGYg0
>>733
A's Video Encoder なら Fluid Motion でフレーム補完したエンコがでける。

735名無しさん@編集中 (オイコラミネオ MM7f-ZvWl)2018/01/10(水) 23:03:33.31ID:kE+0C3NMM
インタレ解除だって再生時に出来るしな

736名無しさん@編集中 (ワッチョイ 5e76-QpsD)2018/01/11(木) 03:55:38.37ID:1cbDHyJ90
俺のブラビアで再生すれば240fpsで超ヌルヌルだぜ

737名無しさん@編集中 (ワッチョイ 25c6-zHNy)2018/01/11(木) 07:50:46.84ID:cPxsWcsS0
毎回、再生環境を選ぶようなエンコとかめんどくさ。

738名無しさん@編集中 (アークセー Sxbd-qwZV)2018/01/11(木) 11:27:28.15ID:xHT3Dywqx
男は黙ってBDMV準拠

739名無しさん@編集中 (ワッチョイ 7dfa-53ns)2018/01/12(金) 18:26:26.13ID:zF3Z/D7L0
エンコ日が動画埋め込まれるのを消したり変更したりはできないの?

740名無しさん@編集中 (ワッチョイ 7dfa-53ns)2018/01/12(金) 18:27:02.12ID:zF3Z/D7L0
すまぬ、訂正

エンコ日が動画に埋め込まれるのを消したり変更したりはできないの?

741名無しさん@編集中 (ワッチョイ 39ec-IhuN)2018/01/12(金) 18:39:36.95ID:ecpKvVhK0

742名無しさん@編集中 (ワッチョイ 6ad2-JQPx)2018/01/12(金) 18:40:29.51ID:64eEZn7/0
>>739-740
>>629あたりからの流れを見てね

743名無しさん@編集中 (ワッチョイ 7dfa-53ns)2018/01/12(金) 19:26:29.27ID:zF3Z/D7L0
>>741-742
ありがとう
参考にしたいと思います

ちと使ったことのないソフトを使うようで俺には難しいかな

744名無しさん@編集中 (ワッチョイ 5998-0F6q)2018/01/14(日) 20:53:17.63ID:VO/9yTd80
>>731
すまんね
ドヤ顔でキリッの相手は、幼稚園の先生かママにお願いしてください

745名無しさん@編集中 (ワッチョイ 25c6-zHNy)2018/01/15(月) 12:25:23.13ID:aaz1ubzE0
エンコ日やmux日を偽装や隠蔽して一体なにがしたいのやら。

746名無しさん@編集中 (オイコラミネオ MM2e-qwZV)2018/01/15(月) 16:22:32.60ID:7iqz1FsLM
違法アップロードのエンコでこんなに低いcrfなのに低ビットレートってスゲー、って思われたいんだろ

747名無しさん@編集中 (ワッチョイ e5f7-zHNy)2018/01/15(月) 16:24:08.26ID:wQe3Tfq50
それにエンコ日やmux日が関係あるの?

748名無しさん@編集中 (ワッチョイ 25c6-zHNy)2018/01/15(月) 17:40:39.06ID:aaz1ubzE0
旧作アニメのエンコをして、当時の放送日時に合わせて日付を設定しちゃおう!っていうのなら
まぁわからなくもないが、それはさすがに深読みし過ぎかw

749名無しさん@編集中 (ワッチョイ a6ed-jusK)2018/01/15(月) 18:18:31.54ID:AsEH1LJl0
検察が証拠ファイルを書き換えて事件のあった日に

750名無しさん@編集中 (ワッチョイ eaeb-PGvU)2018/01/15(月) 19:06:47.18ID:1aBtJVCr0
エンコ日時フィールドにエンコ日時以外を入れたいとは思わないな
さっきエンコしたものを放送当時にエンコしたかのように装うなんて気持ち悪いわ
起源捏造民族じゃあるまいし

751名無しさん@編集中 (ワッチョイ 25c6-zHNy)2018/01/15(月) 19:19:05.16ID:aaz1ubzE0
俺のエンコは、mkvでmuxするときにTSから拝借したEIT情報を埋め込むぐらいだな。
キャストとか諸情報とか放送当時のデータをそのまま残せてコレクション冥利に尽きるという感じ。

752名無しさん@編集中 (ワッチョイ 6681-Y2Fx)2018/01/15(月) 20:22:15.47ID:lxTvgHNw0
エンコ日を偽装したいとは思わんが、
隠蔽したいと思うことはあるかな。

unixタイム0(1970/01/01,00:00:00)にすることになるだろうけど。

753名無しさん@編集中 (ワッチョイ 6681-QpsD)2018/01/16(火) 01:36:32.03ID:6W/mSrv50
x264 rev43©2ch.net	->画像>97枚

グループポリシーで自動更新関連を全て無効、サービスでも自動更新関連を無効にしているにもかかわらず
動画エンコード開始して寝て起きたら、なんと1時間ごとに再起動されていた
当然ファイルは破損していた

もうやだこのゴミOS

Windows10 16299.192

754名無しさん@編集中 (ワッチョイ 5998-0F6q)2018/01/16(火) 10:06:44.86ID:H8ZVNNZc0
気がついたら同じような動画を何回も拾ってる
そんなとき、拾い重複エロ動画整理のために、エンコ日やmux日はよく使うな

ファイルが壊れてるときなんか、remux時にエンコ日はそのままにしたいと思うけど
そこまでやるのはめんどくさい

755名無しさん@編集中 (ワッチョイ 25c6-zHNy)2018/01/16(火) 11:02:02.43ID:Q83gu4jz0
>>753
WindowsUpdateサービスを無効にすれば解決するぞ。ただし、長期間そのままにしてあると
定期的なライセンス認証の確認作業に不具合が生じてバルーンヘルプが出始めるかもしれないが

756名無しさん@編集中 (ワッチョイ c7ec-Tfxv)2018/01/31(水) 21:16:35.20ID:rZJ4njBN0
 
1/19 に r2901 が来てたのね。今まで気づかなかった・・・。

あとsandboxの方には 1/22 に 「4:0:0 (monochrome) encoding support」 が来てた。

なおKomisar氏は r2851 から動き無し。

757名無しさん@編集中 (ワッチョイ 9776-/IWG)2018/02/01(木) 13:24:21.57ID:AtL2er/I0
>>753
寝ている時間をアクティブ時間にすればいいのでは?
1度も勝手に再起動された事はないな。

758名無しさん@編集中 (ワッチョイ d7c6-HmOu)2018/02/03(土) 22:27:02.72ID:iiAEegYF0
>>753
RS2までロールバックしてみたら?
Win10は一度ロールバックするかクローンHDDから復旧させてCBBのWU確認期限を1年間にしておけば
重要なアップデートが見つかっても検知されないまま放置される。

759名無しさん@編集中 (ワッチョイ 96e8-fGf5)2018/02/23(金) 17:46:51.10ID:bNdCDf+U0
x264guiExで実写を品質基準VBR (crf)でエンコしてるのですが
この品質基準とは何を基準にしているとかあるのでしょうか?

エンコ結果をSIMM0.985に付近にしたいと思い
複数ソースを同じcrfでエンコしているのですが
SIMMの結果がまちまちで疑問に思った次第です。

また希望するSSIMになるような指標などあるのでしょうか?

760名無しさん@編集中 (ワッチョイ ecec-je3A)2018/02/23(金) 18:17:05.20ID:pufaCppw0
ソースによって変わるからソースにあわせてcrf値を調整するしかない。

761名無しさん@編集中 (ワッチョイ fae7-k8Zo)2018/02/23(金) 21:59:48.11ID:+xd/hbhx0
>>759
-tune ssim

762名無しさん@編集中 (ワッチョイ ecec-je3A)2018/02/24(土) 00:27:53.06ID:IJ/q997/0
内容的に --tune ssim は関係ないやろ。

763名無しさん@編集中 (ワッチョイ 96e8-fGf5)2018/02/24(土) 07:11:27.09ID:YQ1clbGi0
>>760
やっぱそういう感じなんですね。
ありがとうございます。

764名無しさん@編集中 (オッペケ Srea-4PVk)2018/02/24(土) 07:16:05.16ID:EpoY8uasr
ちなみに、その0.985っていう値はどこから出てきたの?

765名無しさん@編集中 (ワッチョイ 7011-x4Or)2018/02/24(土) 13:50:41.80ID:uGOS9fa+0
x264はデフォで表示されなかったっけ?

766名無しさん@編集中 (ワッチョイ 21ec-je3A)2018/02/24(土) 18:26:20.89ID:9nHgYv4k0
SSIMの表示には --ssim が必要だけど、>>764が言いたいのは値の取得方法ではなく

 ・SSIM=0.985を基準にしてるのはなぜ?(なんでその数値を選んだの?)

 ・そもそもSSIMを基準にしたエンコードをしたいという理由は何?
  (ただのテストならいいけど、実用なら主観での品質を大事にしたほうがいいよ?)

とかそういうことじゃないだろうか。

767名無しさん@編集中 (オッペケ Srea-4PVk)2018/02/24(土) 22:21:49.99ID:EpoY8uasr
そういうこと

768名無しさん@編集中 (ワッチョイ fae7-k8Zo)2018/02/25(日) 19:53:52.29ID:HN40liws0
0.985についてはここで言及があるね(ソース不明だけど)
https://bucci.bp7.org/archives/26839

他に「0.98以上」てのも
http://www.wikihouse.com/htumenc/index.php?SSIM

769名無しさん@編集中 (オイコラミネオ MM33-Bwms)2018/02/26(月) 14:19:18.80ID:LKAw40ZUM
psy入れてたらSSIMも糞もないだろうな
lameで言う心理音響みたいなもんだから機械的指標だとうんこになる

770名無しさん@編集中 (ワッチョイ bee8-s3ST)2018/03/08(木) 17:21:34.62ID:ncjlH8cj0
地デジ、実写、爆発シーンがあるアクション映画がソースで
爆発シーンはすでにノイズが出ているような場合
qcompをデフォの0.6から0.7に上げても
ノイズを一生懸命再現しようとビットレートを割り振ってしまって
上げる意味はないのかね?

771名無しさん@編集中 (ワッチョイ bee8-s3ST)2018/03/10(土) 20:59:39.09ID:5Kkuf6wr0
crfで綺麗にエンコできる設定だからって
2passでビットレートを制限した場合でも
綺麗になるかってと、そうでもないんだな。

772名無しさん@編集中 (ワッチョイ 5b11-uQtz)2018/03/10(土) 23:18:51.35ID:IzcCyuvd0
crfこそがきれいにエンコオードできる設定だからね

773名無しさん@編集中 (アークセー Sx33-fQch)2018/03/11(日) 00:57:08.76ID:5VWGzzVFx
>>770
上限ビットレートを12Mbpsぐらいにしとけばいいんじゃね?

774名無しさん@編集中 (ワッチョイ 5b11-uQtz)2018/03/11(日) 09:59:37.31ID:jHzQQm8J0
上限じゃなく平均レートに6~10Mbpsを指定する必要がある

775名無しさん@編集中 (ワッチョイ 6ab3-RZSe)2018/03/11(日) 11:55:25.12ID:wjpTvoIe0
いや無駄な再現なら上限を設ければってことだろJK

776名無しさん@編集中 (ワッチョイ e6c2-8ags)2018/03/11(日) 12:37:47.82ID:vOQxZ3fe0
ノイズかどうかって人間の目ならだいたいわかるんだから
いずれAIが進化したら再エンコ専用のエンコーダで
ノイズ部分無視とか補完とかやってくれるようにならんかな

777名無しさん@編集中 (アウアウオーT Sa22-hP+J)2018/03/11(日) 12:44:41.34ID:H0CinTr9a
googleがビッグデータを使ってディテールを予測して補完するエンコーダーの研究してるよな

778名無しさん@編集中 (ワッチョイ 5b11-uQtz)2018/03/11(日) 13:43:34.74ID:jHzQQm8J0
>>775
めんご
>771からの話かと思った

779名無しさん@編集中 (ワッチョイ bbec-Osi7)2018/03/11(日) 14:28:13.12ID:SslWpV+I0
771からの話だとして、なぜ平均レート6〜10Mbpsと言い出したのかよくわからんのだが・・・

780名無しさん@編集中 (ワッチョイ 5b11-uQtz)2018/03/11(日) 19:05:37.90ID:jHzQQm8J0
crfやめて2passで高画質を狙うなら
高い平均ビットレートを指定する必要があるってこと

781名無しさん@編集中 (ワッチョイ bee8-s3ST)2018/03/12(月) 01:58:27.24ID:dFyvws7u0
crfとか2passとか設定出さずに爆破シーンのエンコとか
言って混乱させてしまってすまん。
爆破シーンのは2passでエンコしました。

また疑問でvbv-maxrateでビットレートを指定すると、
指定した値を極端には超えないファイルが出来上がるて
認識なんだけど合ってるよね。

あとx264出力(GUI)Exでエンコしてんだけどマルチパスとか
サイズ確認付き品質基準の「上限ファイルビットレート」項目の
設定もビットレートのピークを制限するものだよね?

初心者とかguiスレがなくてココにこんなこと書き込んですまん。

782名無しさん@編集中 (ワッチョイ bbec-Osi7)2018/03/12(月) 02:24:58.51ID:8qoNk2AH0
>>781
> あとx264出力(GUI)Exでエンコしてんだけどマルチパスとか
> サイズ確認付き品質基準の「上限ファイルビットレート」項目の
> 設定もビットレートのピークを制限するものだよね?

全然違う。
あれはできあがったファイルサイズ(ビット単位)を秒数で割った数値がそれ以下になるようにするというもの。
昔のニコ動のエコノミー回避や一般会員のビットレート制限のために作られた。
ニコ動の仕様が変わったので、もう使われることはないだろう・・・多分。

783名無しさん@編集中 (ワッチョイ 6aeb-REXQ)2018/03/12(月) 02:57:46.67ID:M0RpU/HJ0
意味もわからず2pass使うバカが多いよな

784名無しさん@編集中 (ワッチョイ bee8-s3ST)2018/03/12(月) 03:41:09.56ID:dFyvws7u0
>>782
ありがとう。
品質基準の「上限ファイルビットレート」は
目的が全く違うんだね。

>>783
いるよなw
CCEの影響か

785名無しさん@編集中 (ワッチョイ f3c6-uQtz)2018/03/12(月) 06:06:48.95ID:ijK6n5Xa0
マルチパスは画質を捨てて、エンコ後のデータ量を揃えたい人限定じゃね?

786名無しさん@編集中 (ワッチョイ 5beb-++4j)2018/03/12(月) 15:20:07.23ID:1e6aJ3tW0
crf使ってるのに何度もエンコしてファイルサイズ揃えようとする馬鹿も笑えるよな

787名無しさん@編集中 (オイコラミネオ MMb6-fQch)2018/03/12(月) 15:45:56.62ID:4KK2qyCVM
psy入れてるのに毎回ログでSSIM解析値残してる俺
無駄だとわかってるけど何となくね

788名無しさん@編集中 (ワッチョイ f3c6-uQtz)2018/03/13(火) 07:25:55.28ID:pSIurGuv0
>>786
VBVでビットレ制限すればcrfでもデータ量を揃えることは可能だが
アニメ以外だと高いSSIM値になっていても糞画質な映像に仕上がってることが多い。

789名無しさん@編集中 (ワッチョイ 0bf2-uQtz)2018/03/13(火) 22:09:04.65ID:NrXyemjW0
それはcrfというよりcbrになってるだろ

790名無しさん@編集中 (アークセーT Sx25-MOYc)2018/03/17(土) 20:33:57.41ID:41kAdC9fx
ロスレスは劣化が無いと信じて使ってたけど
なんか線が細ってるなーと思って減算して元画像と重ねたら
見事に淵のピクセルが飛んでた
このスレ読んでやっと真実が分かった

791名無しさん@編集中 (ワッチョイ 0dec-Ue6H)2018/03/17(土) 20:43:54.27ID:UvukF0qw0
RGBソースをYUV4:2:0の可逆で保存してたってことかな。
そのあたりをちゃんと理解してない初心者は結構いると思う。

792名無しさん@編集中 (ワッチョイWW df9a-hSqf)2018/03/18(日) 18:52:37.64ID:lqrsXf4E0
フチっつーからエンコーダがサイズ間違えたとか?

mmp
lud20190925143629cこのスレへの固定リンク: http://5chb.net/r/avi/1485572817/
ヒント:2chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「x264 rev43©2ch.net ->画像>97枚 」を見た人も見ています:
x264 rev37
x264 rev42©2ch.net
x265 rev3©2ch.net
x265 rev4
x264 rev27
madVR Part6©2ch.net->画像>34枚
GEMFOREX ★7©2ch.net->画像>109枚
CHEMISTRY No.262 ->動画>4本->画像>197枚
H.265/HEVC Part9 縲7680x4320縲
車 しりとり Part XVII©2ch.net->動画>2本
x265 rev2
iPhone X Part61 ->動画>4本->画像>26枚
p2.2ch.net総合スレ Part96->画像>10枚
MOTHER4->動画>17本->画像>49枚
【2016】 H.265/HEVC Part6 【7680x4320】©2ch.net
XnView Thread その4
Foxage2ch part2->画像>8枚
CHVRCHES 3 ->動画>73本->画像>28枚
MPEG-4 AVC/H.264 総合スレ Part8
Sven Vath->動画>30本->画像>12枚
TOHOシネマズ Screen128 ->動画>2本->画像>13枚
iPhone XR Part25 ->動画>8本->画像>164枚
iPhone XR Part22 ->画像>16枚
Everything Part6 ->画像>26枚
【2018】 H.265/HEVC Part8 【7680x4320】
VapourSynth Part2©2ch.net
【2016】 H.265/HEVC Part2 【8192x4096】
【2016】 H.265/HEVC Part4 【7680x4320】
Irvine Part28->動画>33本->画像>12枚
toddlercon [無断転載禁止]©2ch.net->画像>279枚
MacでEvernote Part.2
a_watcher対策スレ ->画像>32枚
Hitachi Card NEXT
「MonsterHD 264」 SK-MHD264 スレ
NVENC/CUDA Part2 [無断転載禁止]©2ch.net
Monstercat
Tvtestをビルドするスレ Part10©2ch.net
Xoperations 27->動画>6本
Xcode part15 ->画像>10枚
technoなID -27-->動画>41本->画像>26枚
Nexus 9 Part19->動画>8本->画像>43枚
Mr.Children Over ->動画>8本->画像>12枚
Richie Hawtin Pt.3->動画>24本->画像>10枚
iPhone XR Part11 ->動画>10本->画像>114枚
XMedia Recode Part6©2ch.net
CHANEL(シャネル) Part84 ->画像>16枚
nightmare city->画像>8枚
iPhone X Part7 ->動画>6本->画像>54枚
PictRiver
event watching
TVTestについて語るスレ Part 84©2ch.net
【画像】2203 [無断転載禁止]©2ch.net->動画>15本->画像>76枚
【2016】 H.265/HEVC Part7 【7680x4320】 [無断転載禁止]©2ch.net
TvRockについて語るスレ 94©2ch.net
THUNDER 5 ->動画>16本
Amazon Echo part9 ->画像>12枚
HandBrake 総合スレッド 14 ©2ch.net
TOEICerスレ ->画像>14枚
Irvine Part33->動画>58本
TEC TM620 part2
PX-W3PE Part.27
iPhone X Part58 ->画像>20枚
JKのvineで抜く Part.4 ©bbspink.com
WesternDigital製海石HDD友の会 Vol.42

人気検索: 女子小学生和小学生 パンチラ 11豁ウ ロリあう洋ロリ 裸 泳 フルヌード 二次二次 スカート 芸柏lフェイクポルノ 繧ケ繧ッ繝シ繝ォ豌エ逹? けつ毛バーガーファンクラブ 解剖 11 Young nude girl?
04:39:42 up 4 days, 17:27, 3 users, load average: 5.88, 6.23, 6.36

in 0.69677305221558 sec @0.69677305221558@0.1 on 012404