X

x264 rev43©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
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チャンネル）
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/
2017/01/28(土) 12:14:48.59ID:5vCHjYRZM
保守
2017/01/28(土) 12:15:22.27ID:5vCHjYRZM
保守
2017/01/28(土) 12:15:45.86ID:5vCHjYRZM
保守
2017/01/28(土) 12:16:02.64ID:5vCHjYRZM
保守
2017/01/28(土) 12:16:22.18ID:5vCHjYRZM
保守
2017/01/28(土) 12:16:40.44ID:5vCHjYRZM
保守
2017/01/28(土) 12:16:56.24ID:5vCHjYRZM
保守
2017/01/28(土) 12:17:15.40ID:5vCHjYRZM
保守
2017/01/28(土) 12:17:30.48ID:5vCHjYRZM
保守
2017/01/28(土) 12:17:47.10ID:5vCHjYRZM
保守
2017/01/28(土) 12:18:06.12ID:5vCHjYRZM
保守
2017/01/28(土) 12:18:23.46ID:5vCHjYRZM
保守
2017/01/28(土) 12:18:41.26ID:5vCHjYRZM
保守
2017/01/28(土) 12:19:15.29ID:5vCHjYRZM
保守
2017/01/28(土) 12:19:32.64ID:5vCHjYRZM
保守
2017/01/28(土) 12:19:49.04ID:5vCHjYRZM
保守
2017/01/28(土) 12:20:05.78ID:5vCHjYRZM
保守
2017/01/28(土) 12:20:21.42ID:5vCHjYRZM
保守
2017/01/29(日) 05:06:35.59ID:rZUkYjIyM
保
22名無しさん＠編集中 (ﾜｯﾁｮｲ 9a17-Ve17)
垢版 |
2017/01/29(日) 11:58:23.73ID:HRXKy2910
CLIで使用できる文字数って上限有りますか？

--zonesで出来ることが増えたからいろいろ試したいんですが、
既に--zonesで1500文字以上消費してるので、不安です
2017/01/30(月) 01:55:48.47ID:FYD+LKAF0
保守
2017/01/30(月) 07:09:43.17ID:bq+tM8dk0
ググったらvista 以降は32000字と出てきた
25名無しさん＠編集中 (ﾜｯﾁｮｲ 9a17-Ve17)
垢版 |
2017/01/30(月) 18:54:18.65ID:0ep9ofwb0
>>24
ありがとうございます
2017/02/01(水) 22:01:43.34ID:NLeHcyku0
・echo コマンドで、8192 文字目以降の引数が切り捨てられる。
・Cmd.ex e から、子プロセスを起動する際、渡される引数の一部に抜けが生じる。

https://support.microsoft.com/ja-jp/help/2823587
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
http://blog-imgs-69.fc2.com/j/a/p/japan2014/201409111428494ff.jpg
29名無しさん＠編集中
垢版 |
2017/02/05(日) 01:48:30.10
http://blog-imgs-69.fc2.com/j/a/p/japan2014/201409111428494ff.jpg
30名無しさん＠編集中 (ﾜｯﾁｮｲ f953-TVOI)
垢版 |
2017/02/08(水) 17:06:31.20ID:Hb1bXVZs0
作業用に一時的にHi10PなイントラでCBRエンコしようしてるけど流石に早いな。
2017/02/08(水) 21:58:33.98ID:UXGxZlhJ0
komisar氏のr2762こないな
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=
2017/02/09(木) 17:24:58.14ID:cYvlgny90
残っていたMMX部分SSE2にしたっぽいが速度上がるかな？
2017/02/10(金) 19:45:44.72ID:y31+GkOw0
2762、若干速くはなっているけど、微々たる物だな
i7辺りだと気にならないレベル、PhenomⅡやCore2でエンコしている人は其れなりに大きいって感じか
2017/02/10(金) 20:12:09.84ID:sMazUFU/0
Ryzenどうなるかなー
コア数多くてもAVX系弱そう
2017/02/10(金) 22:47:30.72ID:knMGpv420
x264の実行時間の半分はSIMD以外の計算と言う話だから、AVX2が128bitでも、コアが増えるのは有効だろう
2017/02/10(金) 22:52:31.51ID:q3hMw7op0
現行FXより速くなるだろうから、それだけでもかなり良いと思う。エンコだけなら無難な速度だしてくれるからねｗ
2017/02/11(土) 21:07:09.42ID:tjFEHFwy0
ジャップランドからだと落とせないのかｗ
ココでも『日本氏ね!!』だなｗｗ
2017/02/12(日) 13:55:54.37ID:3HO66Hm+0
2762駄目じゃね？、少なくともx86版
tmodしか使っていないからtmodが悪いのかもだけど
2台のPCでエンコしていて、両方ほぼ同じ位置で止まった。
タスクマネージャー覗いたらx264 .exeが原因、ハングアップじゃなくループし続けたりするときと同じような状態
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が違うと別物のファイルを吐くんだな
2017/02/14(火) 16:48:41.04ID:MMAaxHxI0St.V
Iフレームでディザが消えててフレームを進めるとディザが復活してきて
次のIフレームではまたディザが消えるのって何が原因？
設定はcrf20でpresetがMedium
2017/02/17(金) 13:43:42.85ID:zOolMlCC0
level6て
2017/02/20(月) 08:22:01.82ID:we6mEaoWd
>>42
ちょっとでも動きの激しいGOPの部分でよく見るわ
fgo=1にしてもほぼ改善しなくてバンディングが発生するから私も悩んでる
2017/02/20(月) 08:28:59.06ID:we6mEaoWd
その部分だけをTrimしてエンコするとfgo=0でもディザはきれいに残るから何が悪いのかわからない
2017/02/20(月) 09:54:07.82ID:Mj9I5Lxk0
元からあるとかいう話じゃなくて？
x264のオプションならipratioのBフレーム版なオプションがあった（今もある？）はずだから探してみては
2017/02/20(月) 14:43:33.63ID:2FqcQwDpd
pbratioかな？
でもこれってIフレームには影響しないんじゃない？
2017/02/20(月) 14:54:31.48ID:y6mXnjGo0
名前の通りPとBだね
Pフレームの品質に対してBフレームの品質をどうするか
みたいなコマンドだったはず
2017/02/20(月) 18:09:28.11ID:cF3iu/KMd
Crfエンコでのビットレートで2passのエンコをすると、そっちではディザが保持された
かといって、ソース毎に必要なビットレートが違うから、一度Crfでエンコして必要なビットレートを取得して2passでエンコし直すというのも手間だしどうしたらいいんだろう
2017/02/20(月) 18:44:26.33ID:Mj9I5Lxk0
ごめん
さらっと読んで階調割れのことかと早ガッテンした
細かいものを残したいならデブロッキングフィルタを下げてみるとかpsy-rdの調整ぐらいしか思い浮かばないけど
今使ってるpresetや個別に指定してるオプションなどを書いてくれたらなんか思いつくかも
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
2017/02/20(月) 19:32:29.04ID:bp1Dvjt0d
psy-rdを1.35:0.4に変更して、fgo=1を追加してもあまり改善はみられなかった
それで>>51の設定で2passエンコをしたらディザが保持できていた
2017/02/20(月) 20:46:19.40ID:Mj9I5Lxk0
もう画質とかあまり考えずにx265へ移行したから的外れ（記憶違い）かもしれないけおｄ
動きのあるシーンならとりあえずqcomp=80を試してみてるぐらいかな
あとはオプション弄る前にsubme上げるとか（プリセットを）上げる方が先決な気がする

（個人的にはcrf18ならdeblockは-2:-2:にしても大丈夫だと思うけど大した効果はないかな）
2017/02/20(月) 20:58:18.33ID:bp1Dvjt0d
me=umh, subme=9, merange=32, qcomp=0.8, deblock=-2:-2
試してみたけどほとんど変わらないかな
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 オプションがほしい
2017/02/22(水) 21:29:35.98ID:IwsRK/Qtd
いろいろ試してみたけどやっぱりディザが残らない
qpfileでIフレームのqpを0に設定してもフレームの上端のマクロブロック一列しかほとんどディザが残らない
2017/02/22(水) 23:25:33.38ID:WN4yLsjU0
そういえばpsy-rd使うとなんとかｑｐ-offsetがマイナスになった気がするからpsy-rdを0：0（効果を分かりやすくするため）でやってみたら？
さらにtune grainでやって残らないならmuken氏にでも聞くしかないと思うな・・
とういうかなんかIで消えてP/Bで残るってなんか出てきそうで出てこないんだよね
2017/02/22(水) 23:49:57.04ID:acFLLeSrd
マイナスになるのはchromaじゃなかったかな？
次はtune grainも試してみる
なんでcrfだと消えて、2passだとバンディングが発生しない程度には保持できるのか謎
2017/02/23(木) 04:23:16.41ID:x/XdQJoH0
そもそも無理だからバンディング低減フィルタが生まれたのではないのか
2017/02/23(木) 11:07:57.88ID:vN+wtlpW0
なんで糞忙しそうなmuken氏に聞こうとするんですかね・・・
かつて野良ビルドしてた人だけどx264devじゃないでしょ

>>58
取り敢えず画像上げてみたら？ソースとcrfエンコ後、2passエンコ後の3種類
2017/02/27(月) 07:17:53.84ID:XLbpq8sD0
>>34
>PhenomⅡや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が大きく落ちる傾向にある)
それも考慮に入れて見ては
2017/02/28(火) 17:36:14.00ID:PHbqDs1E0
>>r2345以降のx264でエンコさせると平均で6～8fps前後遅くなるし。
2346以降、2345最期に削った命令はOSが7以降と言う条件付き
XP(改)や2kexの場合は元々機能しない命令なので最新版の方が速いと蛇足付けておきます
2017/02/28(火) 19:19:49.54ID:YVuNCVGh0
そもそもx264でエンコする人がいまだにWin7未満を使い続けてるとは到底考えられないんだが。
Win7未満を使い続けてる層はx264よりくっそ軽いXVIDやDIVXを愛用してんじゃないか。
2017/02/28(火) 21:04:36.71ID:nWED9X2x0
煽り失敗！
2017/03/01(水) 00:04:40.77ID:3MlnXzcL0
OSとCPUの区別がついてないんだな
2017/03/01(水) 14:25:06.58ID:MUatPPG40
test
2017/03/02(木) 00:04:11.79ID:znb1goci0
komisarが403なの俺だけ？
2017/03/02(木) 00:08:33.38ID:6vPQ95ES0
>>70
日本からのアクセス遮断されてる
2017/03/02(木) 00:40:05.09ID:YFE/7OfW0
マジか
何があったんだ
2017/03/02(木) 00:45:17.49ID:x8Wr5mB9M
ライゼンってSSEが十倍の性能らしいからコア数とあいまってエンコはかどるかな？
2017/03/02(木) 00:46:10.10ID:V8vD73Fb0
理由は不明
予想するとすればAviUtlのx264GUIExが自動ダウンロードするx264がkomisar氏のもので
それでアクセス数が急増して日本からの接続を拒否ったとかそういうところじゃないのかな？
2017/03/02(木) 01:47:39.10ID:EpvM0pt80
急増するほど最近の話か？　それ
2017/03/02(木) 07:10:53.26ID:zo1ua/sp0
自動インストーラってAviUtlに必要なん？
README見て必要なものを集めてくんじゃないの？ｗ
>>75
急増騒きは少し前だと思うよ
その時期にYoutubeに手順動画が流れてにわかユーザーが増えたからじゃないかな
理解しないで適当インストールを繰り返してアクセスが増えたのは確かかな
今も増えてるようだけど、安易に変なインストーラ作らないで欲しいと思うよ
2017/03/02(木) 07:20:14.76ID:xEj84IP10
Readmeを見て自分でファイルを集めてこれない人向けだから…
2017/03/02(木) 10:39:30.20ID:xiBnsCVc0
久々に来てみたがネ実のクズ共の荒らし行為って沈静化したん？
2017/03/02(木) 15:19:05.46ID:r5tKudVv0
自動ダウンロードに拒否がどうのって話デジャヴ
2017/03/02(木) 16:47:40.61ID:NAYKX2H20
>>74
それで良いと思うよ
ツール使ってダウンロードしないでくれって書いてあるし
よっぽど行儀の悪いアクセスしていたか、数が半端じゃなかったんだろうよ
2017/03/02(木) 21:16:20.34ID:lBCkdqF50
>73
自分は今すぐには買えないので、レポ待ちでワクワクしている
2017/03/02(木) 21:52:10.99ID:OQofB6vk0
よかったな 速いぞ
http://cdn.wccftech.com/wp-content/uploads/2017/03/AMD-Ryzen-7-1800X-Review_CPU-Benchmarks.png
2017/03/03(金) 01:25:00.72ID:SoL/p3Zu0
エンコ用途なら買いだな
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
http://pc.watch.impress.co.jp/img/pcw/docs/1047/474/l04.png
AVX2オフにするとパフォーマンス上がる
2017/03/03(金) 10:44:24.67ID:o2enDWaz00303
コアあたりの性能はIntelとほぼ同等まで追いついて価格が驚異的に安い
Ryzenコスパやばいな
2017/03/03(金) 11:23:50.13ID:mkOg2Z+q00303
まさかx264エンコードでも上行くとは
動画エンコードでIntel上回ったのなんて初じゃね
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版/ｋMod版）
　　※2016年11月より日本からアクセスできなくなっているのでWebArchiveで。
　　http://web.archive.org/web/*/http://komisar.gin.by/
2017/03/05(日) 19:06:24.58ID:9iE97utn0
エンコなら1800X買うしかないねぇ
2017/03/06(月) 02:26:58.54ID:2jXgFqW50
1700で十分だな
1800X/1700Xの差別化ポイントであるXFRはたった
1コアを100MHzだけOCするガッカリ機能だと判明して
結局は手動で倍率設定するしかない
自作PC板では倍率フリーの1700をクロック上げれば1800Xとほとんど変わらんじゃん
て流れになってる
2017/03/08(水) 21:45:18.31ID:5f3zjIK/0
2ソケットできるNaplesだと1800Xよりさらに上か・・・
買う人は買うだろうなあ
2017/03/08(水) 22:14:26.50ID:8NMXBv1WM
おいくら万円になるんだか
2017/03/08(水) 22:17:12.49ID:uSeTgtzR0
Naples x 2だと合計128スレッドで、現時点でのx264の--threadsの限界に達するな
2017/03/11(土) 01:16:36.51ID:xcdpSSTj0
確かスレッド増えるとファイルサイズも僅かに大きくなるよね
128スレッドだと、気になるぐらいファイルでかくなるんだろうか
2017/03/11(土) 01:36:00.94ID:thFGa3uF0
--threads 12で--threads 1よりビットレートが1%ぐらい大きくなってた気がするけど
128/12=10.67%も大きくなる…のかなぁ
2017/03/11(土) 08:55:13.25ID:r7DCAib9a
ccx内で完結するように2本流して速度稼ぐのが良いのでは？

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

L3キャッシュはccxを跨ぐと効率が落ちるからこの辺りの実装を気にした実装が理想だろうね。
2017/03/12(日) 06:59:44.38ID:ev1URYZR0
実際にはx264はRyzenが非常に得意な分野だから
コアの割り当て問題は当然のこととしてL3が8MB + 8MB
にパーティショニングされてる問題もほとんど影響ないんだろ
2017/03/12(日) 09:35:06.27ID:HPWsohqC0
SIMD命令にキャッシュはあまり関係ないそうだよ
2017/03/12(日) 14:10:09.08ID:gTBFYAG80
AthlonⅡX4はいい塩梅だった
2017/03/12(日) 20:22:19.29ID:3TierDBr0
誰か雷禅でエンコして
2017/03/12(日) 20:30:17.56ID:It3queHc0
>>99
このスレじゃいかんの？

【x264+Avisynth】実用エンコベンチ Part5.1 [無断転載禁止]©2ch.net
http://potato.2ch.net/test/read.cgi/jisaku/1460032466/
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です。
2017/03/17(金) 23:59:30.84ID:6/5IqK3Y0
--qcompを盛ってみる 0.8とか
--qpstepを盛ってみる 8～16とか あんまり大きくしすぎても良くはならない気がする
--bframesを減らしてみる デフォルトの3とか
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の中身らしいから、これを軸にいじってみればいいんじゃない
2017/03/18(土) 14:39:38.21ID:PgHHxzGe0
質問スレとかなくなっちゃったんだね

みんなって、最新のリビジョン使って本番エンコしてる？
さすがに最近はやらかしとかないよね
2017/03/19(日) 21:14:44.14ID:3yF2GRg50
posix versionsって何？
Linux用？
2017/03/20(月) 15:27:25.32ID:BpP4DLbv0
わからないなら気にするな
ggrks
2017/03/20(月) 17:19:36.45ID:g6ulSQjE0
x264で盛り過ぎると再生(デコード)時にやたら負荷のかかるパラメータってなんだっけ？
前にx264でエンコした動画をスマホのVLCで見ようとしたらコマ落ちが酷くてだいぶ厳しかった。
2017/03/20(月) 17:20:46.10ID:mCakdv6o0
refとかbframesとか
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

ちなみにこんな設定。
2017/03/20(月) 17:52:48.16ID:vVotdsrL0
refもbframesもスマホ向きじゃないぐらい大きいね
2017/03/20(月) 17:54:11.45ID:IPbCXG2RM
解像度によってはref16はかなりのハイレベルになるよ
2017/03/20(月) 17:55:19.32ID:mCakdv6o0
8bitエンコにするなりrefを3~4にするなりbframesを減らしてみるなり手はあると思うんだ
2017/03/20(月) 18:01:04.11ID:g6ulSQjE0
エンコ環境やノートPCでは何の不都合もなく再生できていたから
スマホでも行けると思って再生してみたら、ほんとやらかした感に満たされた。

画質を選ぶか負荷低減を選ぶか、どこで線引きするか悩むところだね。
2017/03/20(月) 18:07:44.17ID:mCakdv6o0
少なくともbframesは盛ったところで縮みはするけど画質が上がるとは限らないと思う
refはどうなんだろうな以前盛ったり減らしたりしたけど特段盛りまくってもエンコ速度とSSIMを比べると効率が悪くなる気がして4ぐらいまでしか使ってないな
2017/03/20(月) 18:11:42.13ID:YxhIh3YN0
素人で再生互換性とかよくわからないからほぼデフォルトプリセットしか使ってない
2017/03/20(月) 18:12:42.05ID:g0tid5gi0
Bフレ8枚って容量節約モードですか
2017/03/20(月) 18:57:06.45ID:dyE1cGoC0
費用対効果的に
ref 4
bframes 3
以上は微差しかないな
2017/03/20(月) 18:59:35.37ID:K9LZysiQ0
まあBフレ増やして節約した容量分、crf下げれば
画質は良くなるけど再生負荷は高いよね
2017/03/20(月) 19:15:29.81ID:DaNUKjFo0
veryslowベースの設定なのかもしれんが、「crf=15.5」ってのも結構やばいのでは・・・
Hi10pな上に、ここまでcrf値を下げる人ってあまりいないんじゃないか？
2017/03/20(月) 20:02:59.60ID:OH0D6gB50
他のコマンドにもよるだろうけど、crf16あたりからが人間の眼では劣化が分からなくなるんじゃなかったっけ？
2017/03/20(月) 20:35:50.01ID:myC1EGEA0
どこが悪いというか、スマホで動かすには悪いところ多すぎてわらたｗ
2017/03/21(火) 10:20:59.28ID:kHNquja20
スマフォならHWデコードだから大して差は無いと思うが、そもそも10bitデコードに対応してる機種なの？
2017/03/21(火) 12:39:29.68ID:7w2jOxdHd
ハードウェアデコードとはいえ、無制限ではないからな。
想定はBDの規格内と思ってたほうが良いと思うぞ。
2017/03/21(火) 14:53:32.41ID:aS02+pTx0
>>122-123
H.264の10bitのHWデコードに対応してるものなんて無いだろ。10bitはSWデコードのみ。
2017/03/21(火) 17:39:54.26ID:ZWjxBEYu0
ちゃんとVBVを設定してHigh@4.1までならどのハードでも安心
2017/03/21(火) 18:53:41.96ID:kHNquja20
>>123
その制限がプロファイルとレベルだと思うんだが範囲内ならドロップしたことは無いかなぁ

>>124
俺も見たこと無いんだが、スマフォでSWデコードはキツくねって言いたかった
2017/03/21(火) 20:42:13.86ID:gt0UGiJv0
>>126
そうでもない
円盤はランダムシークに弱いからBフレも参照距離も3程度がベター
もっとも16とか指定しても使わなければ問題ないわけ（HWデコード全般で）だけど
万が一に備えると厳しめになる
2017/03/22(水) 23:19:05.92ID:vOb72tqI0
はあ？
2017/03/29(水) 14:34:57.70ID:lSlTuvuQ0NIKU
--crf *を指定しなくてもエンコ出来たんですが--crf 23とサイズが同じでした
crf指定無しだと--crf 23と同じ扱いになるんですか？
2017/03/29(水) 14:39:19.24ID:sWlpArUZ0NIKU
そもそもデフォルト設定が--crf 23
2017/03/29(水) 23:57:08.08ID:lSlTuvuQ0NIKU
>>130
なるほどありがとうございます
2017/03/30(木) 14:43:09.54ID:foKOUbX30
>>127
なんか、突っ込む気力が失せるくらい色々痛いな
2017/03/30(木) 15:14:27.49ID:dO0HQ95e0
>>132
つ鏡
2017/04/02(日) 15:33:06.82ID:JfirpmU20
RFFフラグを使ったソフトテレシネ素材をx264でエンコしたいのですが、
ソフトテレシネのままエンコする方法はありますか？

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

60i混在ソースなので、全部24p化するというのはできなくて
今の所フレーム水増しして60iにしてエンコしてるのですが、
ソフトテレシネのままの方が画質が良くなると思うんです
そんなに気にする必要ありませんかね
2017/04/02(日) 15:35:31.23ID:zlbvKLjL0
--pulldown 32のオプションがあった気もするがこれがソフトテレシネであるかは忘れた
2017/04/02(日) 15:42:07.65ID:JfirpmU20
>>135
それはソフトテレシネなのですが、フレームごとに指定することができない（する方法が分からない）ので、
60i混在ソースだと使えないんです
2017/04/02(日) 15:50:20.30ID:zlbvKLjL0
zoneはきっと使えないから--stitchableと--sps-idを使って分割エンコして最後に結合すればなんとかなるんじゃない？
糞めんどくさいしややこしいから60iに統一してやったほうがいいしそこまで画質に差は出ないと思う
2017/04/02(日) 16:06:58.66ID:JfirpmU20
なるほど・・・そこまでやるんだったらx264cliを改造したほうが簡単かもしれないですね。ソース読んでみます
2017/04/02(日) 16:15:01.80ID:UgoQM92X0
x264はMBAFFインタレだからインタレ保持にしてもPAFFインタレよりは符号化効率高いよな
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を呼ぶ必要があって
なんか危なそうだし、やめておいたほうがいいかな
2017/04/02(日) 23:23:41.04ID:zlbvKLjL0
>>140
うーんどうだろうH.264やmp4(ISOBMFF)の規格に詳しくないから分からない
もう全体的に60iとしてエンコしてしまったほうがいいんじゃないかな x264はインタレェでもそれなりに圧縮率いいし
--stitchableと--sps-idを使って最後に結合する方法は規格上問題ないとは聞いた

muken氏とかH.264とISOBMFFの両方に精通してる人に聞かないと正しい実装に出来ないんじゃないかな
2017/04/03(月) 07:37:09.54ID:TctSlTlK0
mukenさんが答えてくれてるね
https://twitter.com/OumaeKumikoBot/status/848558806728458240
https://twitter.com/OumaeKumikoBot/status/848559597505748992
https://twitter.com/OumaeKumikoBot/status/848560263280205824
2017/04/03(月) 09:31:10.42ID:fUoHoWI80
感激！そうかmuxでずれるのはタイムスタンプいれてやればいいのか。夜試してみるわ
2017/04/03(月) 11:16:11.92ID:VSUvqQUi0
すごく内容に興味あるんだけど、うまくいったらこの--pdfile-inの書き方を教えてくれないかな？
2017/04/03(月) 14:27:48.23ID:35NLofYn0
muken氏語ってるね
残業なくてもイエスマンが出世するようになってるからダメでしょ
そんな人に勉強の成果や能力の良し悪しの判断なんて土台無理な話
で、また、イエスマンが出世する
これじゃ、中卒か高卒で公務員になって趣味に生きるのが最もコスパの人生だからね
シャープ、東芝、かつての日産見ても学習できないんだからどうにもならん
すれちすまん
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ファイル側に問題があるのか、分からん
2017/04/04(火) 02:00:24.39ID:htZBUXUD0
家電系は放送の変態ストリームに耐性があるけど、PC系は違うんだわな
pulldownして全部iで出すデコーダと、p部分はpのまま出すデコーダがあったりして
後者の場合にi/pの変わり目で挙動が乱れるレンダラがあったりする
2017/04/04(火) 02:19:44.54ID:NM8tqATA0
すまん、カクカクだったのは俺のタイムコード生成プログラムのバグだったわ
直したらmpc-hc、Xperia Z4 Tabletともにカクカクはなくなった
これでXperia Z4 Tablet、PS3では全く問題無く再生できるようになった

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

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

>>144
今作ってるフロントエンドのプログラムそのうち公開するから待って
2017/04/04(火) 02:31:19.30ID:n3r5tOrx0
mpc-hcというかLAVはどうもインタレ、プログレ混在は苦手っぽい
PAFFインタレだと60i部分が30p再生されたりとか
2017/04/06(木) 19:27:08.09ID:01K8kK0t0
ffmpegだとフラッグのみbobすればよかったような
2017/04/08(土) 00:55:21.46ID:yDtOaJW8d
参照しているフレームの情報を利用したいんだけど、どうすればいいかな？
x264_adaptive_quant_frameのところを利用できるのが理想です。
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
2017/04/15(土) 19:27:23.01ID:eAFMSi9o0
>>152
なんか本当に形になるとは思ってなかった
ありがたくウォッチさせてもらうは
2017/04/15(土) 23:49:50.26ID:EpfRbE3V0
>>152
おつかれ
覗いてくるわ
2017/04/16(日) 08:46:32.41ID:nhrM+GHT0
win専用なのか
残念
2017/04/19(水) 23:12:51.43ID:SeBvsYch0
5.1ch用に前処理しなくていいのが楽だなあ
2017/05/01(月) 23:07:01.47ID:42uPSlD30
あげ
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スレッド環境を無駄にした気がしてならない。
2017/05/05(金) 03:22:17.02ID:PxrPz4xg0
>>158
AviSynth+のMT版に以降して、Prefetch(16)を試してみたら
2017/05/05(金) 03:24:02.13ID:qcN7u1qj0
x264GUIはややスレチだけど、メニーコアなCPUだとCPUを完全に使い切れないことは多い
2017/05/05(金) 07:53:47.99ID:YZ3yL0J800505
2つ並列にエンコすれば100%行くよ
2017/05/05(金) 08:01:00.68ID:YZ3yL0J800505
Ryzen7ならL3キャッシュが4コアずつに分かれてるから
タスクマネージャーの関係の設定でAviUtlの使用コアを若い方8個と後ろの方8個に分ければいいと思う
2017/05/05(金) 09:24:19.06ID:nc8W/xjM00505
>>158
aviutlスレにも書いたけど1本のエンコードで100%は無理
それでもAviutlと合わせて80%越えてたら十分でしょ
2017/05/05(金) 09:30:26.82ID:+B6luGJ/00505
x264に限らずフィルターもマルチコアに最適化されないとどうにもならないんだから
80%近く出てるなら十分だと思うけどな
avisynthで複合型のフィルターなんか使うと20%以下もざらにあるぞ
2017/05/05(金) 13:19:52.74ID:FdjoRNe600505
まじか。今のx264だとまだ性能出しきれるほど最適化されてないのか。
x264のチューニング入るまでは開いたCPUでBONIACでも回しておくか。
2017/05/05(金) 13:45:24.01ID:3AEMG+VU00505
最適化はもう限界に近いでしょ
アルゴリズム的に並列作業が増やせないものは仕方ないよ
今でも使用率上がってても大半の計算結果は途中で捨ててるくらいだし
2017/05/05(金) 14:10:53.60ID:+B6luGJ/00505
x264だけなら100%近く出せると思うけど実際にそれだけという人はいないから
結局の所は使うフィルター次第という話になってくる
avisynth+にフィルターをMTに対応させる機能もあるけど不具合と限界があるから1本の処理に拘るんじゃなくて
2本3本と処理する本数を増やした方が悩まなくて済むとおもうぞ
2017/05/05(金) 14:17:45.17ID:3AEMG+VU00505
5960X環境だけどUt_videoのavi食わせてるだけなのに100％なんていかないよ
80%くらいをうろつく
2017/05/05(金) 14:22:07.27ID:I4yKE2ol00505
ベンチスレ見てても多コアなやつは100%までいってなかったような
2017/05/05(金) 15:14:52.02ID:3QEgKuQF00505
実際4コアで十分
それよりも動作クロック
2017/05/05(金) 16:51:23.07ID:7L1WkNvu00505
CPUが100%に張り付けばいいってもんじゃないと開発者が言ってたと思うよ。
エンコ速度に注視しろって事も付け加えられていたようん。
2017/05/05(金) 18:42:52.11ID:/ft2Zb9F00505
マルチプロセスでスレッド数を減らすことを意識したほうがいい
2017/05/05(金) 19:47:46.78ID:IyQHVJhz00505
>>168
それぐらいが丁度いいんじゃないの？
80~90%ぐらいが
2017/05/06(土) 10:17:17.95ID:e0PV2k/30
いままで8bitエンコしかして来なかったけどhighDepthオプションつけて10bitエンコにしようかと思うんだが
TS抜きした映像ソースを10bitでエンコする意味ってあるのかな？
TS自体が8bitだった気が・・・
2017/05/06(土) 10:24:24.11ID:D2u31DZA0
なんで10bitエンコがいいのかぐぐればすぐわかること
2017/05/06(土) 10:42:00.24ID:oUC6MMIta
>>174
tsそのままだとあまり意味無いね
なんらかの技術で10bit精度に補間したものを改めて10bitで収録し直すみたいな形ならともかく
2017/05/06(土) 11:14:13.52ID:39bf1dhz0
>>174
なかなか面白い理論だ
2017/05/06(土) 11:42:04.09ID:e0PV2k/30
>>175-177
あっ、なんか意図が伝わってなくてスマソ。アスペなもんで。
8bit深度に大してH.265で採用されている10bit深度の画質的メリットはもちろん理解
しているんですが、ソースが8bit深度の映像を10bitで出力したところで画質向上には
ならないんじゃないかなと思いまして。
いろいろ調べてもTSソースを10bit補間してエンコしたみたいな話は見かけないから
そもそも10bitエンコ自体普及してないのかなぁ・・・
最近閉鎖で騒がれているnyaaとかには10bit精度でエンコされた動画でわざわざ
アップしている職人もいたと聞くが。
2017/05/06(土) 11:43:14.34ID:BycummCk0
hevcかどっちか忘れたけど素のまま10bitエンコするだけでも
多少の良い効果は得られるらしい
だからデメリットはHWデコードが対応してないと重くなるぐらいかな？
2017/05/06(土) 11:49:35.72ID:BycummCk0
onedriveにアドレス残ってた
http://peace.2ch.net/test/read.cgi/avi/1418252184/

ここの70番あたりを読むと8bitソースを10bitなモードでエンコードしても効果あるということらしい
2017/05/06(土) 11:51:14.45ID:oUC6MMIta
>>179
それ言う人がいるけど勘違いしてると思うよ
D-A変換されたものがそのまままた10bitにA-D変換されて記録されるだけの事だから
同じD-A変換のアルゴリズムを使ってる限り8bitエンコードも10bitエンコードも変わらないよ
2017/05/06(土) 11:56:52.66ID:BycummCk0
デコードしてもアナログ信号にはならないんじゃ？
2017/05/06(土) 11:58:20.20ID:zOt9cvyd0
jpegをjpegで圧縮するような状態だったのを
jpegをpngで圧縮する程度の効果はあるってことではないの
2017/05/06(土) 12:01:33.55ID:s7pzBEcM0
主にアニメとかでバンディングを軽減するため10bitでエンコするんだよ
なので、バンディングが気にならない人は、やる必要はあまりないかと

理屈はともかくいろんな人が検証した結果効果があると認められてる
まあ、自分で試してみればいい
2017/05/06(土) 12:09:35.26ID:oUC6MMIta
色深度の話は圧縮とは別で
たとえ可逆圧縮だったとして8bitを10bitで記録しても8bitの深度にしかならないよ
>>180で展開されてるのはデコード時のディザの話で
これはつまりデコード時にディザを付加してるのだからデコーダーの補間の話になる
このデコーダーで8bit映像をデコードするのとそれを10bitで縁jコードした映像は変わらない
つまりこのデコーダーを使う限り8bitのソースで充分という事になる
2017/05/06(土) 12:18:26.14ID:oUC6MMIta
>>184
8bitの元ソースを8bitでエンコードしてバンディングが出るのはビットレートが低すぎるからだろう
近似値の平滑化の度が過ぎて目で見て分かるほど差が出てしまったという事だ
10bitでエンコードするよりその分8bitでビットレートを高くした方が良いと思うがな
2017/05/06(土) 12:33:19.85ID:s7pzBEcM0
まあ、そう思うのは自由
188名無しさん＠編集中 (ﾜｯﾁｮｲ 9272-37K/)
垢版 |
2017/05/06(土) 13:57:53.04ID:mHEFOYoh0
flash3kyuuDeband()
dfttest()
smoothgrad()
GradFun3()
このあたり使えば、補間してくれるよ
2017/05/06(土) 14:05:41.78ID:e0PV2k/30
>>188
()がつくということは失笑するレベルなのか。
2017/05/06(土) 14:10:47.29ID:PeTSKErj0
ミーム汚染だ
2017/05/06(土) 14:17:17.40ID:QiKKyfSe0
>>189
マジで言ってるのかAviSynth知らないのか判断に迷う
192名無しさん＠編集中 (ﾜｯﾁｮｲ 9272-37K/)
垢版 |
2017/05/06(土) 14:18:00.36ID:mHEFOYoh0
>>188
関数だからやぞ
avisynthの
2017/05/06(土) 14:19:14.61ID:2p+oHv330
おお…
2017/05/06(土) 14:22:31.95ID:QiKKyfSe0
生tsが
2017/05/06(土) 15:43:21.65ID:BycummCk0
な、懐かしい流れ
数年ぶりな気がする
2017/05/07(日) 17:36:52.55ID:IeCbXKOD0
失笑って発想はなかったわw
2017/05/08(月) 07:50:55.40ID:6610UigA0
>>184
lavつかって再生すると、結局あんまりでないんだよなぁ
2017/05/08(月) 08:34:16.75ID:gNgcHkdkM
バンディングはmadVRでもかなり抑えられるしな
2017/05/08(月) 21:16:52.82ID:6/2ByMXh0
>>186
8bitでバンディングを出なくするにはディザを残す必要があるからBD並みのビットレートが必要
少なくともフルHDで10Mbps以上。x264だとcrf=12程度が限界
だからTSを圧縮するには実質的に使えない
2017/05/08(月) 23:25:36.38ID:fN8ySGc20
ジョーク乙
2017/05/22(月) 11:29:16.71ID:GZMyMciJ0
ｒ2829
x86のAVX-512がらみが多くて殆ど関係ないかな
2017/05/22(月) 17:20:32.96ID:U7KhlFgq0
Xeon Phi用？
2017/05/22(月) 18:26:30.18ID:+CZlsLvY0
commitの内容くらい読んだら
2017/05/22(月) 23:59:56.47ID:U7KhlFgq0
そうだったら面白そうだったのに違うのか。発売まであと1ヶ月ちょっと
2017/05/23(火) 09:39:19.86ID:Mmk8+JSl0
なんかAVX512にもいろいろなバージョンがあるらしい
2017/05/23(火) 11:16:16.33ID:7zgCm2Fx0
AVX-512に対応しても、256bitを2クロックで実行だったらあまり意味がなさそう
2017/05/23(火) 12:39:38.16ID:GV0woxuQa
>>205
今のところ2種類だよね
Phiと、これから出るSkylake(Kabylake)-X
違ったら訂正よろ
2017/05/26(金) 14:50:30.90ID:Mh7fDvUt0
>>174
テレビは8bit
ブルーレイは10bit

これが基本
2017/05/26(金) 20:40:12.96ID:MHU9y7Qv0
メガドライブは16bit
2017/05/26(金) 22:07:25.45ID:unoKqH810
>>208
ブルーレイも8bitだろ
2017/05/26(金) 23:34:59.38ID:IXEtfAo30
一応12bitできるお

http://www.phileweb.com/sp/news/d-av/201304/10/32810.html
2017/05/27(土) 00:28:02.17ID:KXKBbCuQ0
>>211
マジかw よく見たら俺の持ってるUB90も対応してたわwww
これをデコードできるソフトがあるのか知らんけど
2017/05/27(土) 01:49:30.71ID:sgij9sLk0
ジブリとか
2017/05/27(土) 02:22:49.77ID:KXKBbCuQ0
そういう意味じゃなくて、MGVCのtsをx264でエンコするために12bitデコードできるPC用のプログラムが手に入るのかって話
2017/05/27(土) 02:28:51.98ID:yOi/kiCt0
＞MGVCのサブストリームデータには特別な暗号化が施されており、これをデコードするためには、ハードウェア側にカギを仕込む必要がある。
と書かれているがPCでできるのかな
2017/05/27(土) 02:57:54.84ID:KXKBbCuQ0
まぁパナの一部の機種しかデコードできないようなオレオレコーデックに対応しても旨味がなさすぎるし無理だろう
今ならUHD BDがあるからこんなコーデック使う必要ないし
2017/05/27(土) 03:54:56.54ID:WaAf4/ND0
r2833kMod来てるで
2017/05/27(土) 04:03:02.41ID:WaAf4/ND0
って日本アク禁解除してくれたのね
2017/05/27(土) 07:31:37.05ID:JFb4SnYO0
ほんまや
2017/05/29(月) 01:49:30.77ID:a0uJfekx0
ここで聞くのがいいのか分からんけど、x264の8bitで俺的アニメ最適設定とか実写最適設定的なのを参考までに教えてくれる人いないですか...
2017/05/29(月) 02:13:44.22ID:2fXE0oZU0
わからないならデフォで
2017/05/29(月) 09:32:10.21ID:t/pwYFLr0
>>220
とりあえずプリセットとプロファイルを指定して
そこれプラス --b 3 --ref3 でBフレームとrefの制限だけしとけばおｋ
あとおまじないで --aud --nal-hrd も追加しとけばいい
2017/05/31(水) 10:34:57.77ID:8JeQCHhC0
x264guiEx_2.51v2
2017/06/28(水) 22:42:51.76ID:RVxNfKli0
R2851きてんな
2017/07/03(月) 17:23:55.63ID:EoHdrbIh0
各ビルドも来ましたな
2017/07/03(月) 22:21:40.62ID:oRGsh6jC0
そういうのは今期入る前にしてくれｗ
2017/07/03(月) 22:25:29.32ID:7K3B3cxp0
今ならまだやり直せるぞ
2017/07/04(火) 02:01:36.14ID:Zsfek4ze0
まあたしかにそうだわ
2017/07/04(火) 09:47:04.81ID:kbRsHYbA0
画質的に向上する余地なんてないんだから
気にしなくてもよくね？
2017/07/04(火) 12:08:01.34ID:Zsfek4ze0
AVX-512関係ばっかりだし
確かに気にしなくて良いんだけどね

日記になってしまうが、
たまたま、今期はバージョンあげようかなとか迷ってたんだよ
ただそれだけさ
2017/07/08(土) 18:00:56.36ID:a+acXXxz0
x265に乗り換えてからx264の最新ビルドに対する興味が薄くなった。
2017/07/08(土) 19:47:46.47ID:6acSBIHO0
>>231
嘘つき乙
2017/07/09(日) 13:46:24.52ID:Dm7e95yZ0
赤潰れやハイライト削りすぎは改善れれる余地はあるの？
2017/07/09(日) 16:10:15.77ID:orURU0+Q0
赤色が劣化してるように見えるのは色空間の問題が大きいからなぁ・・・
x264だと--chroma-qp-offsetを弄ってみて改善するかどうかじゃないかな

ハイライト削り過ぎってのは分からないけどcrfやaqやpsy-rdの調整でどうにかならない？
2017/07/11(火) 10:30:45.47ID:dCODISON0
>>234
赤色の劣化の原因は色空間なの？元画はなんともないのに？
赤の認識は国や地域で大きく違うから、それが反映されて無視されてるのかと思ってた
ハイライト削ると、バンディングもどきが現れたり
2017/07/11(火) 12:04:04.12ID:IJasOprA0
ダウンサンプリングのお話
ttp://shinshu.fm/MHz/14.30/archives/0000304718.html
ttp://shinshu.fm/MHz/14.30/archives/0000403906.html
ttp://shinshu.fm/MHz/14.30/archives/0000456837.html
2017/07/11(火) 22:11:53.59ID:Y5S24hR30
元画も420だと思うが違うのか？
2017/07/15(土) 11:33:03.36ID:QOPZli+L0
--chroma-qp-offsetは効果がなかったですね
赤が強いと鮮やかに感じるからx264は低ビットにしても綺麗に見えるんだろうなと勝手に解釈
赤のライト一色のシーンの破綻はきついものがある

元画がフルレンジのケースのことだったの？
jpegだと確かにYUVでもフルレンジ使うけど
2017/07/15(土) 12:01:33.59ID:3m6njqCx0
サンプルの画像でも貼ってくれないと何のこと言ってるのか分からない
2017/07/15(土) 12:09:12.71ID:D4kjNe6l0
有名な話ではあるけど8bit ビデオコーデックの限界でなかろうか
量子化のやつを改変するしかないんじゃね（すごい昔に流行ってた気がする
2017/07/15(土) 12:09:31.23ID:2zI05HpD0
>>238
・元画と言ってるのは、どういうソフト（やカメラなど）でどのように作った映像なのか。RGBなのかYUVなのか。
　>>237が言ってるように元画がYUV4:2:0の映像なら元画の時点で赤の劣化が起きてると思うのだが。
・「ハイライトを削る」とは具体的にどのような処理を行っているのか。

このあたり、ちゃんと詳しく書いた方がいいと思うよ。
あとフルレンジかどうかは今回の件についてはあまり関係ない。
2017/07/15(土) 13:41:12.57ID:3m6njqCx0
> ハイライト削ると、バンディングもどきが現れたり
読み直したら結局バンディングのことか
エンコしたらディザが消えてバンディングが出てくるから10bitでエンコするっていういつものやつ
2017/07/15(土) 13:56:32.08ID:3m6njqCx0
バンディングのディザによる解決は害悪だよね
10bit、12bitにすれば解決する問題をビットレート特盛りにして力技で解決
エンコしたら劣化が目立つから初心者にはエンコーダのせいにされてしまう
もっと早くから放送もBDも10bit化すべきだったな
2017/07/15(土) 14:45:47.73ID:QOPZli+L0
つくづく、地デジもBDも10bith264と思いきればよかったのにと思う。
家電開発者のインタビュー見てると、高画質をうたってるテレビはほぼ10bit対応と言ってるしね。
2017/07/15(土) 19:56:53.20ID:82DwIzbfM
BSで新しい衛星を立ち上げて地上波のサイマルをH264使ってやればいいのにな
で、地上波の帯域をスマホとか移動体通信に使う
2017/07/15(土) 20:03:20.59ID:iDHnQGIE0
>>245
もし出来たとしても結局版権問題でBSジャパン（テレ東と同時にBSで放送する予定だった）と同じルート辿りそう
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
死ね！キモブサ川高志!!
2017/07/16(日) 19:40:58.06ID:HpejTqPk0
ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
　http://egg.2ch.net/test/read.cgi/jisaku/1460032466/796-797
2017/07/17(月) 20:48:45.94ID:8laiMmMa0
エンコの時にハイライトを捨ててるんだろう
ハイライト自体がわからんなら説明のしようがない
2017/07/17(月) 20:58:05.21ID:RzYBtVR60
>>251
「だろう」って、「ハイライト削りすぎ」という表現を持ち出したのはお前さんなのに、なぜ他人事・・・。
個人的にはカラーグレーディングで高輝度部分をちょっと下げたみたいなことを連想してたけど
「エンコの時にハイライトを捨ててる」ってのが何を指してるのかさっぱりわからん。
2017/07/17(月) 23:07:12.77ID:koURX1Uq0
自分の世界しか見えてないから他人に説明できないんだよ。きっと
2017/07/19(水) 11:46:55.18ID:TJhHh62l0
ハイライトは最も明るく目立つ部分だから白付近をごっそりクリップしたんじゃないの
俺にはその処理にデメリットしか感じないけどそいつなりに意味があるんだろうし好きにすればいいよ
255名無しさん＠編集中 (ﾜｯﾁｮｲ 66ea-qt4g)
垢版 |
2017/07/19(水) 17:32:07.21ID:EfL8exLW0
> 白付近をごっそりクリップ
ごっそりクリップってなんや・・・
2017/07/19(水) 18:38:31.40ID:82aWZrRs0
自演じゃあるまいし
大したことないネタに反応しなさんな
2017/07/19(水) 20:21:16.53ID:oXVd+d990
目玉のおやじの白い部分をごっそりクリップするとグロ映像になるよな
258名無しさん＠編集中 (ﾜｯﾁｮｲ 66ea-qt4g)
垢版 |
2017/07/19(水) 20:44:28.35ID:EfL8exLW0
>>257
もともとグロ説

目立つところをおかしくするのって、psy-rdを負側にかけるとかそういうトリッキーなオプションじゃないと出来ないのではなかろうか
2017/07/19(水) 22:00:05.01ID:WJsftwZt0
mp4boxで複数音声をmuxする場合、lang=jpnで指定してるんだけど、
複数音声が同じ言語の場合ってどうすればいいかな？
langで同じコードを設定するとPS3でうまく言語が切り替わらなくなる。
オーディオトラック1は英語、2は日本語とか、違うコードでは問題ない。
2017/07/19(水) 22:07:40.23ID:6NjQsSJPa
違う言語で割り当てちゃえばいいよ
あれは1番2番と割り振ってるのと同じでただのフラグでしか無い
2017/07/23(日) 01:42:18.96ID:xY7oCU1a0
もの凄いボケボケのブロックノイズ塗れになった
と思ったら--crf 210 とかなってたよ(´･ω･｀)
2017/07/23(日) 11:09:40.44ID:6n3bIMM40
210ｗ
2017/07/23(日) 12:15:26.24ID:CMOEbANca
crf 210って出来たのか…
2017/07/23(日) 12:17:01.42ID:keAstF8G0
確か51以上を指定すると51に丸め込まれたはず
2017/07/23(日) 15:31:22.86ID:R4sZ2XaX0
crfmaxパラメータあたりで上限変えれんじゃね。ゴミ画質に劣化するだけだから誰も触れないけどw
2017/07/23(日) 17:06:06.84ID:kCVUaSmw0
>>265
-crf_maxも--crf-maxもCRF+VBVの時にRF値を制限するためのオプションであって
--crfで指定できるRF値の上限を変えるもんじゃないだろとマジレス。

>>264が言ってるように、--crfは51以上を指定しても51にされるだけだね。
2017/07/23(日) 17:10:17.75ID:6n3bIMM40
rc-lookaheadを300にしてるとか言ってる奴も昔どっかで見たけど250に丸め込まれるよね
2017/07/23(日) 18:51:08.05ID:y76xDWj10
丸め込むwww
2017/07/23(日) 19:57:08.39ID:6n3bIMM40
響きが良いよな
2017/07/23(日) 23:25:51.62ID:qmXIkSVi0
丸込め味噌
2017/07/24(月) 01:02:59.95ID:5TMClw7W0
マルメコムX
2017/07/24(月) 07:34:49.14ID:R5b7QqQjM
クリッピングの意味で丸め込むってウチでも使うけど、そんなに変か？
2017/07/24(月) 08:10:53.46ID:iWTL2Muga
いｙｓ，別におかしくは無い
2017/07/24(月) 09:55:51.70ID:j+q0aY7l0
草はやされるほどおかしいとは思わないが
クリッピング（切り捨て）を丸め込むとは言わないかな（自分なら
2017/07/24(月) 10:00:00.79ID:6pYv2j8E0
どちらかと言うとroundingの感じ
2017/07/24(月) 17:08:27.73ID:sOZIAhU50
このスレもどんどん丸め込んでいこうぜ
2017/07/24(月) 18:29:42.17ID:snuqTaT40
>>267
これ本当？
2017/07/24(月) 18:47:51.52ID:0kMaYgwF0
>>277
試してログ見れば本当だってすぐにわかるだろ。疑うくらいならさくっと試しなよ・・・。
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に丸め込まれちゃうはず。

間違えてたらごめンゴ
2017/07/24(月) 21:06:26.15ID:snuqTaT40
さくっと試したら>>267、>>279の言う通りだった
どうもです
2017/07/25(火) 21:52:32.18ID:v9eI6NJr0
x264 sandboxによるとx264が大きく変わるようだ
1つのバイナリで8bit/10bitを切り替えて出力できるらしい
切り替えには--output-depthを使うようだ

この変更でソースの構造が大きく変わってx264 mod版に充てられてるパッチが殆ど使えなくなるんで
mod版ビルダーの更新が遅れるかもしれない
2017/07/26(水) 14:20:37.34ID:WcuuDM2d0
そういう動画はプレイヤーによっては再生できなくなるんじゃね。
たとえばスマホとかゲーム機とか
2017/07/26(水) 14:23:24.71ID:EsczvBkX0
エンコ時間ヤバそう
2017/07/26(水) 14:28:30.91ID:WcuuDM2d0
スマホやゲーム機は10bit/12bitの動画とかHWデコーダが対応してないからSW再生しかできないんだよな
特にスマホはCPUの性能がカスだから、コマ落ち＆音ズレ＆ブロックノイズだらけで悲惨なことにw
2017/07/26(水) 17:22:46.73ID:DLRRNfaO0
H.265 Main 10に対応したハードウェアデコーダーは増えてきているけど、H.264 High 10に対応する物は一向に増えないな
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でやっても同じ
2017/07/27(木) 10:40:31.42ID:8W60h2thd
ないわ、それ元から単色でピンク色なのか？
2017/07/27(木) 12:03:39.98ID:nXagFz4P0
RGB -> YUVへの減食ミスとかじゃね
自分はそっち方面に詳しくないから的外れ化もしれないけど
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

こんな感じ

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

ピンクかと思ったら拡大したら群青とオレンジだった
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の色変換のほうの話だったとは
ここら自分もあまり詳しくないもんで
2017/07/27(木) 18:24:43.14ID:ApvsFLE00
Aviutlって普通にエンコしても黄色っぽくなるんじゃないの
それ調整する為にいつもＹＣ伸張で0-245-13-8補間なしで適当に調整してるわ
フィルターとか使い方よくわかってないから参考にならないだろうけど
これでTSファイルなら元とエンコと色ほぼ同じノイズとか他の要素でじっくり見たら多少違うこともあるだろうけど
比較しても色あせ感はないように思う
他の設定が間違っててこんな調整が必要なのかもしれないけどｗ
最初色調整とかしてたけどそれだとfpsが負荷おおきいからこれにでやってる
スレチでした　すみません
なんかオレンジよりみどりが違う気がしたから自分も最初色の違いでみどりとか黒系がちがう気がして
これにしてる
2017/07/27(木) 18:56:12.32ID:nXagFz4P0
>>295
aqもpsyも0.2ぐらいまで下げてもいいはず
2017/07/27(木) 20:29:50.61ID:o8yj8BJid
俺も色調整は再生時にする様にしたわ
2017/07/28(金) 01:13:43.98ID:whDN0SiA0
読んでると色変換設定ミスの可能性高いな
詳しく知りたきゃaviutlスレ訪ねたほうがいい
2017/07/28(金) 02:01:37.70ID:w5umuGab0
>>295 >>299
なんとなく解説画像作ってみた。
FrapsのFPS1コーデックは変に古いものを使ってでもいない限りRGB形式らしい。
AviUtlはRGB→(YC48)→YUY2変換時に左側の色差だけ取るので
RGBソースの場合はUVダウンサンプリングとかで平均色差をとった方がいいよという話。

　RGBソースをAviUtlでエンコする場合はUVダウンサンプリングで平均色差とった方がいいよというお話
　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3437.png

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

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

それは無い。どこかしらで何か変なことをしてるだけと思われ。
2017/07/28(金) 02:08:12.93ID:69plILf20
自分は分ってる風だけのスレなんて無駄じゃないか
どうせ書くならヒントくらい書くべき
エンコってそもそも圧縮するときに色も変わる(元から劣化）それをかわすのにフィルター使うじゃん
2017/07/28(金) 02:12:25.95ID:8K0HBSqoa
スレェ…
2017/07/28(金) 02:16:05.63ID:mesdGCzp0
何もフィルターかけてないのに色が変わるんだったら可逆圧縮なんて成り立たないでしょうに
colormatrixの設定が間違っているとかじゃないの？
2017/07/28(金) 04:12:38.43ID:NMMi0SW90
ゲームのエンコの時は「拡張色調補正」の「TV -> PC スケール補正」をONにする必要があったと記憶している

それより横に少しだけ引き伸ばしてるのが最高に気持ち悪い
2017/07/28(金) 05:13:52.64ID:whDN0SiA0
PCスケール補正ONとかそんな地雷情報誰が流布しているんだろうな
RGB->YUVをストレート変換しているのと同義でたぶん>>292のencoded.bmpみたいに明るさや色が変わる
色変わろうがそれでいいってんなら俺がとやかく言うことじゃないけど

てかスレチすぎる
2017/07/28(金) 08:38:39.66ID:KZhqFr090
そもそもORIG.bmpが正しいやり方でキャプったのかっていう問題がある
適当なプレイヤーのキャプ機能だとレンダラの影響を受けておかしくなることがある
やけに色褪せて見えるのが怪しい
2017/07/28(金) 10:47:57.86ID:RS92JaZKd
もう終わった話を広げるな
2017/07/28(金) 12:46:07.10ID:tEyRGlbz0
>>300
黄色かどうか忘れたけど変わるよ
元ソースと比べないと分からないレベルだけど

>>304
Y/C伸長がいるのはリミテッドな色空間で出力したゲーム動画をRGBで録画したときだけで
PCゲームの内部キャプチャ、フルレンジ出力したものをRBGで録画したときは不要
2017/07/28(金) 14:16:49.16ID:grmRJ39fa
うーん、h264はYUV420でエンコードするのが殆どだから>>292みたいな元画との差異の追求の話をするには
RGBに比べてYUVは色情報での解像度が低くなるとかの知識は共通認識で持っていた方が良いと思うので
テンプレに追加した方が良いのでは無いか
2017/07/28(金) 15:47:50.94ID:/FJ+xJQY0
>>308
> 黄色かどうか忘れたけど変わるよ

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

>>309
さすがにテンプレにはいらないと思う。昔は色空間スレってのがあってそのログも色々参考にさせてもらったけど、
過疎スレだったし今更立てても需要は無いだろうし。
2017/07/28(金) 16:51:41.77ID:69plILf20
>>310
ミスじゃないでしょ　だからただん劣化の比喩表現
自動という素人でもできるエンコでどうやって間違えるんだ
同じモニター同じデコードで比べても色は劣化してるだし
劣化という表現を色がおかしいという言葉で言うのが問題なら訂正する
でもわかりそうなもんだけどな
2017/07/28(金) 18:19:52.44ID:/FJ+xJQY0
>>311
何を言いたいのかよくわからない。「自動という素人でもできるエンコ」というのが
「特に何も考えずにAviUtlに放り込んでエンコ」ってことなら、それこそが問題であって、
「使い方がよくわかってなくて設定が間違ってるかもしれない」という初心者（素人）が
間違えることがある要素が>>310に書いた内容。

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

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

ということで、結論としては一連の設定や確認の中のどこかでミスしてるだけだと思うよ。
AviUtlに問題があるわけじゃない。
2017/07/28(金) 18:24:49.11ID:RS92JaZKd
こういう切りない無駄な言い争いになるから辞めろって言ったんだ
2017/07/28(金) 18:26:57.66ID:xtqHRxYB0
何にせよもう終わった話だしAviUtlはスレチだからこれで終わり
2017/07/28(金) 18:43:20.71ID:/FJ+xJQY0
そだね。何かあればAviUtlスレの方でテンプレの情報出して質問してくれればなるべく対応しま。
2017/07/28(金) 18:55:44.95ID:69plILf20
うざ
2017/07/28(金) 20:23:33.33ID:hRx+DSbV0
>>316
お前の脳味噌が劣化、というか頭がおかしい
2017/07/28(金) 20:25:43.70ID:0Ig3GpzJ0
構っちゃだめよー
2017/07/29(土) 00:52:28.71ID:3sBlT6oY0
無知蒙昧を相手にするのは疲れる
2017/08/04(金) 03:23:17.34ID:S1K7a/XdM
将来的にTMPGEncあたりがUltra-HD Blu-rayオーサリングに対応しそうだから規格準拠した10bitx265でつくっておきたい
けど、規格書とx265のコマンドライン見比べたらまだ対応してないっぽい

規格書には1080pのH.264も使えるって書いてあるから、ビット深度以外全部従来のBlu-ray準拠設定のx264で多分行けると思うけど
2017/08/04(金) 23:34:32.29ID:ZTZ+gYb+0
しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1　aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな＞aq-mode3
2017/08/04(金) 23:34:54.75ID:ZTZ+gYb+0
x265と間違えました
2017/08/04(金) 23:54:02.49ID:qrQ5Qflc0
>>320
録画規格ないのに対応するとは思えん
2017/08/09(水) 15:58:13.85ID:K4o/tiYa0
BDRIPの動画を8bitでエンコするやつの気が知れない。
2017/08/09(水) 16:02:33.01ID:cIIO/eWe0
BDなんかわざわざRIPしてエンコする馬鹿の気が知れない。
2017/08/09(水) 16:03:33.06ID:B4PTzTTuM
ソースが8bitだから再エンコはバンディング低減効果しかない、というかそれが目的でしょ
最初から10bitまで対応でブルレイ規格作っとけばこういうことにはならんかったけども

まあ、どーせBDMV準拠で流さないんだから10bitでエンコして流せとは思う
2017/08/09(水) 16:05:38.31ID:2AJnt09p0
いちいちBDをケースから引っ張り出すの嫌だから
エンコしてHDDに入れてるわ
2017/08/18(金) 03:37:46.14ID:u9qCreim0
x264で解像度の違う２つの動画をエンコして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で再生してみたけど問題なかった
2017/08/19(土) 18:17:22.65ID:YzeVzrl00
うっさい！ハゲ
2017/08/19(土) 21:27:33.98ID:VsDsEh6v0
"問題が無かった"という証明が出来ない
2017/08/19(土) 23:44:49.40ID:R/l9dL2C0
muken氏か聞いたら発狂しそうではある
2017/08/19(土) 23:55:11.53ID:JW4EweBA0
盛大に音がズレそうな構文だなw
2017/08/20(日) 21:20:22.86ID:iNj0lnL80
問題なかったって言うのはウソだった

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

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

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

L-SMASHは途中でSPSやPPSが変わるのは対応してるけど
画面サイズが変わるのには対応してないってことかな
2017/08/20(日) 22:22:34.58ID:vpjeEVa50
>>333
無茶苦茶なことやるなあ
muken氏が血を吹いて死ぬぞ
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はどれも再生できなかったが・・・

で、それができるんなら、画面サイズやエンコ設定が違くても、できるんじゃねって思ってやってみた
2017/08/21(月) 20:03:22.75ID:8aQPMi1C0
つーか、MP4ｺﾝﾃﾅにこだわる意味ってあんの？
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
書き込みテスト
2017/08/27(日) 17:53:07.05ID:5ula7e/yM
CPU能力有り余っててsubme=11を常用してたけど、10に変更したら主観的に画質レートエンコ速度が良くなった
11ってまだ実験的レベルなのかね
2017/08/27(日) 20:20:15.47ID:c4MX+NAU0
画質レート速度ってなに？
2017/08/27(日) 20:31:15.94ID:a38KtlYJM
>>340
画質(、ビット)レートって意味ね
2017/08/28(月) 11:02:53.88ID:pvNM6gxN0
俺も意味不明
エスパーすると同じcrfだと、画質が良くなり、エンコ速度も速いてことか？
doomで散々議論されてる
2017/08/28(月) 11:11:13.36ID:SOh7kOB8d
限界まで圧縮高めればノイズも出易い
サイズが縮まるのと画質が良くなるのはイコールじゃないって事
2017/08/28(月) 13:16:42.94ID:Ub5w0giJ0
submeを「限界まで圧縮高める」ものだと思ってるのか
2017/08/28(月) 15:38:17.72ID:SOh7kOB8d
>>344
サブピクセルに対して動き予測を行う精度が高い→圧縮率を高める可能性がある→高圧縮

無能で理解できてない癖に揚げ足取ってる俺カッケーってかwww
2017/08/28(月) 16:28:10.48ID:qwDzXc8E0
それは副次的効果ではなくて？
2017/08/28(月) 16:36:11.28ID:bWNdGo2i0
どうやらsubme上げると圧縮高まってノイズが出やすいらしい
新説だなｗｗ
2017/08/28(月) 16:43:47.58ID:DgDXaiGa0
けど実際にガッツリ削れてブロックノイズが出たた気がする
2017/08/29(火) 19:16:36.73ID:u78OskKI0NIKU
submeなんて「ソースによる」としか・・・。
別に11だけに限らず、「7より8にしたほうがエンコ速度が速くなった」とか過去に自分もあったし・・・。
2017/08/29(火) 22:59:28.55ID:OU+HHEG/0NIKU
自分の目にはsubmeは9が一番画質いいように見える
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
ごめんなさい
よく読んでなかったです・・・
2017/08/30(水) 21:11:52.23ID:0I7zrm7A0
疲れてるんだなきっと
2017/09/01(金) 11:28:46.66ID:6GYB47wg0
昨日久々にaviutl一から環境作り直したけど
エンコした動画重い設定じゃないのにシークがクッソ重くて参った、なんでや！
2017/09/01(金) 12:28:10.60ID:p0ViNu5b0
keyintのデフォ値はなんであんなキチガイみたいな値なんだろうな
2017/09/01(金) 12:43:57.42ID:BcnMjwRed
ゴミCPU使ってなきゃGOP300でも気にならんがなぁ
2017/09/01(金) 15:07:10.75ID:98rXXRkg0
デフォだとHEXの7って時点で白けるけどな
2017/09/01(金) 16:48:57.53ID:PPZk2VfG0
>>356
palだかの25fpsの10秒分で250って話らしいね
デフォルトとしては確かに自分も微妙な値だと思うｗ
2017/09/01(金) 16:58:46.84ID:ArSPPgcm0
シークの重さなんて、設定とか環境とか使ってる再生ソフト次第でもあるし、それらを明示しないとなあ。
2017/09/01(金) 18:31:37.76ID:1RZ6jwk90
keyintはBDだと1秒分のフレーム数だし、私もそれに合わせている
2017/09/01(金) 18:34:08.57ID:u27Ubveq0
BDってOpenGOPなんじゃなかったっけ？
2017/09/01(金) 18:39:12.41ID:1RZ6jwk90
そうだね。以前はOpenGOPがMP4で定義されていなかったりしたけど、今は特にデメリットを思いつかない
2017/09/01(金) 19:25:35.51ID:PPZk2VfG0
動画配信とかの用途ではopengopを使うと不具合が起きるみたいだね
ローカル保存のエンコードなら基本的にopengopでいいだろうねー
2017/09/01(金) 20:50:29.66ID:44WtHh6mM
BDだと最大キーフレームは最大2秒でしょ
60p除く
2017/09/02(土) 00:55:46.68ID:+gf3sPsb0
設定値はfps非依存であるべきだと思う
2017/09/02(土) 12:09:42.42ID:XINNvlDB0
釣りか？
2017/09/04(月) 02:11:30.20ID:DviGTLEu0
keyintは最大GOPサイズの指定であって、それ以下でも必要と判断したら勝手にIフレームにするから
ほとんど動かないシーンが長時間続いた場合にどこまでシークしやすくするかを制御するものだろう

>>367
確かに全てがfps非依存であるべきというのは言い過ぎだった(refとかbframesとか)
けどkeyint/min-keyintの用途からいってfps依存にする必要ある？って思うわけよ
2017/09/04(月) 10:16:11.18ID:r1tNr/2q0
単に最大間隔を広げるだけだと思ってる奴が多いが
実際には「必要と判断する」部分で「直前のkeyからの距離のkeyintに対する比」を使うので
keyintをでかくすると必要な部分にも入りづらくなる
2017/09/04(月) 11:31:51.78ID:lpHpIfZE0
というかその必要な部分の判別はどうやってやるの？
それとも思い込み？
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狭くした方がいいのかな
2017/09/04(月) 16:16:47.61ID:5HbHCOKD0
>>372
どっちがどっちなのよ
あとx264にわたってるfpsは同じなの？
x264は入力fpsでcrfの品質基準が変わるから注意
2017/09/04(月) 16:53:24.96ID:U39geqKR0
>>369
えっ？
2017/09/04(月) 17:03:06.54ID:zbSjoI0T0
x264ってタイムコード入力できるからfpsって必要ないんじゃないの？
それともタイムコードはレート制御に使われないの？
376名無しさん＠編集中 (ﾜｯﾁｮｲ ffea-wn1X)
垢版 |
2017/09/05(火) 01:27:08.59ID:f5v5/jXG0
>>373
フレーム数を見ていただければ分かるように、上がフレームを削ったもの、下がループしたものです
2017/09/05(火) 09:48:18.47ID:2RbzhNwm0
>>375
どこまでインテリジェントに対応してくれるんだろう・・
入力されたファイルのfpsが30fpsだった場合、不明・24fpsの場合と比べて
crfの数字に0.2～0.3ほど内部で増やされるんだけど、その適応もしてくるれるんだろうか
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は説明していたのだと思う。
2017/09/05(火) 19:47:38.56ID:+QVQZVSVM
そのIDRフレームってのは、H.264はIフレームでも前後フレームと関連つけてあるから、関連性をリセットするIフレームってことでしょ？
2017/09/05(火) 20:21:42.67ID:PONwnECO0
OpenGOPだとIDRフレームは生成されないよ
GOPはあるし、シークできるけどね
2017/09/05(火) 21:19:57.24ID:9b8xFzve0
IDRフレームでしかシークできないわけではないし、OpenGOPは「GOPが無い」わけではないからね。
382名無しさん＠編集中 (ﾜｯﾁｮｲ 3396-X0kF)
垢版 |
2017/09/06(水) 23:29:09.06ID:KzhpnQIy0
誤爆
2017/09/07(木) 00:00:38.11ID:qIIhwnZ40
何でyou等はx265を使わないのかne？
384名無しさん＠編集中 (ﾜｯﾁｮｲ db96-QyhX)
垢版 |
2017/09/07(木) 00:33:21.37ID:YqTr/s540
ほっといてくれ
2017/09/07(木) 01:40:32.76ID:imulDhe8M
BDMV互換重視してるから
UHD-BDにオーサリング出来るようになってx265がUHD-BDのフォーマットに完全互換出来たら乗り換えるわ
まあ、UHD-BDはインターレースをサポート外したから、インタレ素材は実質アプコンしないといけないからH.265にする意味があんまりなさそう
2017/09/07(木) 01:55:19.43ID:nZ6H3iVe0
単純に再生側でh.265が観れないから
2017/09/07(木) 07:09:58.72ID:kv1lC+de0
>>383
使ってるよ
別にこのスレに書いてるからと言ってx265を使っていないことにはならない
2017/09/07(木) 09:54:51.39ID:+wXPEBFj0
youtubeのことかと思ったらyou達（たち）だったのね
2017/09/08(金) 07:40:32.11ID:ghAOL8080
何年も前から使えるなら移行する気満々で環境だけは整えてるけど
使い物にならん、使える環境が激狭いまんまなんでどうにもならん
2017/09/08(金) 07:42:49.16ID:7Btg921qM
できるならH265にしてるだろうけど、エンコードも再生もそこそこ性能が必要だから現状厳しい
2017/09/08(金) 08:17:45.88ID:zQgPsbEjM
一番の問題はx265の完成度が低すぎる所
規格上はH.264の二倍近い圧縮効率と謳ってるが、
x264とx265で似たようなSSIMになるようにエンコしても、
速度倍かかるのに対して容量3割程度しか削減出来てない
2017/09/08(金) 09:08:45.48ID:jziT9JUy0
H.265が「H.264の2倍の圧縮率」てのを発表したのはSSIMではなくてPSNRでの評価。
んで、そういう機械評価ではなくて、実際の主観的な評価（眼で見た時）はどうなのかと、圧縮率をH.264の倍にしてテストも、92.5%はテストクリア（半分にしても違いが分からない）という結果が出ている。
ttp://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
2017/09/08(金) 10:35:25.34ID:YVfOYICF0
>>390
8bitでエンコしてあればx265のエンコ動画はスマホでも余裕で再生できるけど？
2017/09/08(金) 13:10:52.31ID:DRBMiemRa
スマホの世代によるんじゃ
2017/09/08(金) 14:57:11.66ID:6zk3EGtm0
馬鹿でも出来るという言葉があるが馬鹿の程度にもよるしな
2017/09/08(金) 19:02:26.67ID:K42HeHEk0
x264vfwの最新版が7月で64bit版は15年で止まってるんですが
もう作らないという事でしょうか？自分がよく使っているソフトは64bitなので
最新版は使えないっぽいですが
2017/09/08(金) 19:17:53.60ID:EqCEryle0
>>396
統合されたので、最新版を入れれば32bitと64bitの両方が入るよ。
2017/09/08(金) 19:37:50.44ID:K42HeHEk0
あ、そうなんだ㌧クス　翻訳サイトで読んだけどちょっとよく分かりませんでした
2017/09/09(土) 09:15:24.46ID:h/Y+Lz1o00909
x264guiEx_2.52
2017/09/12(火) 07:10:49.74ID:AdArdet+M
>>392
規格作った所の公式テストの話じゃなくて、x264に比べてx265の最適化が発展途上って話なんだが
2017/09/16(土) 13:32:24.14ID:zNLVYvN4x
>>392
どうせ比較したH.264エンコーダーが糞なんだろうな
x264はmp3でいうLAMEみたいに規格内で極限まで最適化を志向するエンコーダー
2017/09/22(金) 16:10:49.36ID:cJDJKSFu0
規格とエンコーダの違いがわかってなくて規格(机上の空論)だけで比較した気になってる人でしょう
2017/09/27(水) 19:54:24.64ID:p7Ac+Lfb0
　1passVBRのcrf指定でエンコする場合、presetはどれに設定しても
crfが同じなら容量は変わっても画質はほぼ同じになるの？
2017/09/27(水) 21:29:43.81ID:2daxdhqd0
>>403
画質という表現だとちょっとあれだが、前にSSIMを調べた時には
fasterより早いプリセットは他に比べて明らかに値が低くなってしまっていた気がする。
2017/09/27(水) 22:14:16.87ID:Urbs+S3H0
>>403
機能的にはそのはずだけど画質はfasterとslowではそれなりに差が出る
使える機能を絞ってるわけだから当然なのかなと思ってる
2017/09/28(木) 05:25:03.14ID:V45lbue30
　ありがとう。MicroSDも随分大容量になった昨今、エコ的には容量に
振った方が良いのかな、と思ったんだけど微妙だね。
2017/09/30(土) 16:37:33.34ID:0Ufo816+M
ハズレ石の6700Kで夏場は水冷でも熱暴走しまくって、OCを4400MHzに抑えてたが、
ようやく涼しくなって常用最大の4600MHzまでやっても落ちなくなったわ
2017/10/01(日) 22:59:15.48ID:q0pgAPRH0
電源をずしんと重いやつに変えれば夏でも安定すんじゃね？
2017/10/01(日) 23:01:30.73ID:kwhdiWHuM
>>408
オンボ環境で1000Wの電源積んでる(将来のグラボ追加のための皮算用)んですがね
2017/10/09(月) 02:38:46.73ID:o0wuNtkj0
x265スレが落ちたようだな…
2017/10/09(月) 04:47:35.68ID:jZhige/X0
ヤツは四天王の中でも
2017/10/09(月) 07:59:57.87ID:LaKQeeR70
最強
2017/10/09(月) 10:51:18.58ID:yu/ITypTM
漬け
2017/10/11(水) 00:26:25.49ID:Q7nPMdd60
おお･･･
2017/10/11(水) 00:40:05.42ID:nHom/Jmt0
勇者よ…
2017/10/11(水) 08:59:51.54ID:98Hacveca
死んでしまうとはなさけない
2017/10/11(水) 13:25:53.15ID:qw5XZR0a0
死んでしまうとはふがいない
2017/10/11(水) 17:26:15.90ID:i0NOrkcf0
勇者「うるせー！文句あんなら自分でやれや糞がっ」
2017/10/11(水) 18:01:28.04ID:p3huYvL50
女神様「ぷーくすくすー」
2017/10/11(水) 20:41:15.01ID:xq6B2EZpx
ライゼンはええわ
1700@3.6GHzで地デジソースがveryslow＆お気に入りフィルタの重めの設定でリアルタイムfps出てるわ
6700K@4.6GHzだと実時間の倍掛かるのに
2017/10/11(水) 21:28:00.33ID:M7bFbdy2M
流石にその比較で2倍違うのはおかしい
もちろん実時間の倍かかるというのが1.6倍とかのことなら分かるが
2017/10/11(水) 21:34:32.23ID:LMrA0Z5Xd
無理なOCでコケてるんじゃね
2017/10/13(金) 13:45:16.21ID:yFIiDpYE0
こんな人間いるのかな？って突如疑問に思ったんで質問してみる

BDにはいってるAVCをx264で再エンコしてる人
こんな人いる？　
これってもうガッツリと容量削減だけが目的？
2017/10/13(金) 14:12:59.68ID:klQgg49hM
BDのH.264ってとりあえず最高ビットレートで入れとけって感じだから、再エンコでも結構縮む
そもそも深度8bitの時点で知れてるし
2017/10/13(金) 15:01:37.09ID:yFIiDpYE0
>>424
ああ　そういう感覚なのか
容量あるから考えなしにビットレート高くしとけっていう事ね
ありがとすっきりした
2017/10/13(金) 20:56:47.91ID:KJdAkpzt0
720p付近で作ってるアニメなら容赦なく720pにしちゃう
2017/10/13(金) 22:51:02.86ID:zkNYkqBK0
>>423
BD-BOXをエンコしてBD-R SL1枚にまとめれたら最高じゃね？
あとは特典だけ手元に残してBD-BOXをオクに流せばいいだけ。
2017/10/13(金) 23:02:17.93ID:/9liIQr8d
>>427
それならH.265にするわ
2017/10/13(金) 23:08:15.02ID:c69msVZM0
一度HDDにエンコして入れとけば見たい時にサクッと見られるからな
毎回blu-rayディスク引っ張り出してディスクセットがめんどい
2017/10/13(金) 23:08:32.23ID:XO65u8DFa
BDを再エンコするのはノートPCでいつでも気軽に見られる様に入れておきたいって用途しか無いなあ
だから容量削るのに720Pにしちゃうし画質はそこそこで早さ優先にしてる
2017/10/13(金) 23:11:13.45ID:zkNYkqBK0
何でエンコするかは各自の自由な。
俺もエンコはx265(アニメならpreset 8+12bit+crf16)の一択になってしまったが。
BDソースだとavsフィルタとか無理に加える必要もないしエンコもだいぶ省略できる。
2017/10/13(金) 23:26:06.30ID:zkNYkqBK0
x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。
24分アニメあたり800～1.3GB前後で収まれば御の字だし
2017/10/14(土) 01:04:33.83ID:+Cbq7FOAM
俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ
自分でやるの時間の無駄だし面倒だから
2017/10/14(土) 01:26:53.21ID:kVkjCh4N0
地デジソースとかエンコ職人がアップしたやつを見たこと有るけど
60iテロ処理とか雑に処理しててドン引きした。
2017/10/14(土) 01:46:27.00ID:p1EsgrIG0
テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな
静止シーンでコピペして潰せるとかならともかく
2017/10/14(土) 14:10:21.52ID:kVkjCh4N0
いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。
2017/10/14(土) 16:16:50.16ID:Q0J2c64D0
だから地デジはゴミって言ってんだろう
2017/10/14(土) 20:09:42.00ID:p1EsgrIG0
補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ
存在してるだけでイラつくゴミが、これ見よがしにヌルヌル動いてたら余計腹立つわ
きったねー縞々で何書いてあるかわからないぐらいの方がざまあみろって感じでいいんだよ
2017/10/14(土) 20:13:49.84ID:Q0J2c64D0
ちょっと理解できない
2017/10/14(土) 20:17:20.64ID:wt/1RTiS0
>>438
テロップに惨敗して負け惜しみ言ってるようにしか見えない
2017/10/14(土) 21:08:10.51ID:AcLLCDR50
AUTOVFRで手抜きしてるわ
2017/10/14(土) 21:50:24.73ID:qxT45PQV0
何度も見る事やないんやけんある程度見れてたらそれでええわ
2017/10/15(日) 01:30:31.64ID:uf2+tVfwx
そんなに気になるならインタレ保持でやれよと
2017/10/15(日) 01:53:30.55ID:kSF3tACb0
横にテロが動くときに妙にぎこちなかったり、カックンカックンしたりするとアニメ本編に集中できずにイラつくだろ？
あとエンコ職人はウォーターマーク消しと提供のテロップ消しを一切しないのもイラつく。
2017/10/15(日) 02:00:59.89ID:uf2+tVfwx
どこの局のソースかが大事だからな
糞低ビットレートのMXじゃないよアピール
2017/10/15(日) 10:31:33.53ID:yslYpxl4a
>>444
そこがそれほどイラつくなら素直にBDを買うか借りるかした方が幸せになれそうだ
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より再現度良好
2017/10/19(木) 20:15:18.80ID:3Nrwplnu0
定期的に現れるけど、単に8bitでエンコしてるだけでは？
2017/10/19(木) 20:35:27.12ID:RCE2B7Sj0
仮にそうだとしても、ソースも8ビットなわけで、
x264にできてx265にできないならその条件ではx265が劣るというだけのこと
2017/10/19(木) 20:41:02.03ID:cp4WsA9J0
aq-mode 3 使えよ
2017/10/19(木) 20:45:39.24ID:3Nrwplnu0
「その条件」ならそうかもしれんが、>>447はその条件にこだわってないだろ
バンディング対策をしたくない理由とは？
2017/10/19(木) 20:49:53.98ID:cp4WsA9J0
暗部といったら aq-mode 3 だろ
なんで 1 使ってんだよ
意味わかんねーよ
2017/10/19(木) 21:08:09.16ID:BSHlOoYOF
詰めてないんじゃなく詰め方を知らないんだろ
2017/10/19(木) 21:11:09.82ID:RCE2B7Sj0
>>451
で、その>>447の対策（バンディングと暗部のディテールは違うと思うが）がx265ではなくx264を使うということだったのでは？
バンディングでいうと、ソースが8ビットならばいくらエンコの設定工夫しても無駄
逆にいえば少なくともx264ならエンコの設定ちゃんとすればスクリーンキャプチャしてソースと差分取ってもほぼ0にはできる
2017/10/19(木) 21:14:46.32ID:RCE2B7Sj0
ソースが10ビットなら知らんが、
アニメで（エンコードできるDRM無しの）10ビットのソースなんでまずないだろうに
8ビットのソースを10ビットでエンコードするのはただのアホ
2017/10/19(木) 21:16:18.23ID:WeGA2ymkM
暗部保護ならaq-mode 3とno-mbtree両方設定しとくべき？
後者いらない？
BSプレミアムで放送された大曲花火大会中継を今さらエンコしようと思うんだ
2017/10/19(木) 21:18:04.70ID:P8zWZmTR0
入力が 8bit でも Avisynth やらでフィルター噛ませば出力 10bit でも多少効果でるもんじゃないん?
バンディング軽減やらで
2017/10/19(木) 21:19:04.81ID:WeGA2ymkM
aviutlでノイズフィルタ使ってるなら色深度変わってくるから10bitがいいんでないの？
avisynthなんかでYUV420のまま処理したなら要らんだろうけど
2017/10/19(木) 21:21:03.54ID:cp4WsA9J0
デバンドは意味あると思うが10bit化は無駄多すぎ
アニメには必要ない
それより x265 にも aq-mode 3 はあるから
2017/10/19(木) 21:22:31.59ID:RCE2B7Sj0
ソースを加工するならたしかにまあ
普段自分はしないからその発想は抜けてた
2017/10/19(木) 21:32:18.18ID:3Nrwplnu0
8ビット高ビットレートでバンディング低減されてるソース（放送もブルーレイもそう）を
低ビットレートにエンコするんだったら、デバンドした上で10bit化は必須だよ
2017/10/19(木) 21:37:16.82ID:3Nrwplnu0
まぁ、あまりいいディスプレイじゃなければ分からないかもしれないけど、
少なくとも俺の使ってる4Kブラビアじゃ、チラチラしすぎて集中できない
463名無しさん＠編集中 (ﾜｯﾁｮｲ 5585-0GSP)
垢版 |
2017/10/19(木) 21:38:05.60ID:9FIiI0A00
アニメで10bit化が必要ないとかマジかよ
2017/10/19(木) 21:54:45.70ID:WeGA2ymkM
ブルレイ互換でエンコが基本の自分としては10bitはそもそも選択肢に入らないけどなぁ
ウルトラHDブルレイなら10bit以外の設定は既存のブルレイに合わせとけば問題ないっぽいけど、
そもそも個人向けオーサリングソフトがない
2017/10/19(木) 21:59:03.66ID:AVcz4dXd0
447だが
単にx265とずっと格闘しててx264は浦島気味だから
とりあえずデフォルトに近い所から挙動見てみるかくらいの気持ちだったんだけど…
怒らせてしまったなら申し訳ない

ちなみにどちらも10bitでx265はAQ1～3、Psy-rd、rdoqをあらかた上下させまくったけど
暗部の輪郭保持でx264のポン付けに及ばなかったのはガチだよ
スレチになりそうなんで、要求されない限り細かい記述は避けるけど
2017/10/19(木) 22:39:10.16ID:FFa/XIlI0
8bitソース素通しでも10bitでエンコードする理由はあるよ
同じソース・同じavs・同じX265設定（output-dephthだけ変更）を見比べたら
明らかに10bitが優れている
ま、crf20以下じゃ大した差じゃないかもしれないがエンコーダーとしては10bitのほうが優れているのは変わらない
ちなみにx264のほうが処理がシンプルな分、情報量が多くなることは多い
2017/10/19(木) 22:40:19.49ID:Gaf9oyCF0
バンディングだけは目に見えて効果あるよな10bit化
PCでしか再生しないし一択だわ
2017/10/19(木) 23:57:53.42ID:VgKoLcU30
>>465
ソースくれ、その部分だけでいいから
できれば静止画でなく動画で
2017/10/20(金) 00:20:43.45ID:qjJPv/bA0
>>466
x265は知らんが、x264なら素通しなら8ビットでソースと寸分違わないレベルの画は出るんだよ
劣化するにしても動きやディテール部分が溶けるだけで、バンディングなんでひどくもならない
そうならないとしたら設定がおかしいか（画質が目に見えて劣化する低レートは知らん）、素通しのつもりがそうなってないパターン
2017/10/20(金) 00:31:01.56ID:1vtnnLQF0
>>469
君が劣化しているところに気づいてないだけだと思うよ
BDでさえバンディングは問題になっているのに、その5分の1以下のビットレートで
問題にならないってありえないだろ
2017/10/20(金) 00:42:37.61ID:qjJPv/bA0
1/5程度のレートなら余裕余裕
アニメのBDなんて無駄に（というかほぼCBRに近い）レート食いまくってるんだから、
動かない静止画に近いところで適切に圧縮するだけでその程度には簡単になる。
もっと低いレート（1/10以下）のこと話してるのかと思ったらそんなレベルのなのか。
～なわけがないとか想定で話してないで、実際に試してみてから話してくれ
2017/10/20(金) 00:45:01.85ID:qjJPv/bA0
アニメのBDはマーケティングの都合で1枚に2話とかしか入ってなくてレート減らすインセンティブ皆無だからな
ほぼ規格上限ぎりぎりのCBRよ
2017/10/20(金) 00:51:27.88ID:meA5JVSG0
crfが適切で、aq-mode 3 使って、デバンドかけてれば
8bitでそんな気になるほど見分けつかんよ・・・
10bit使わにゃいかんほどだと、違うパラメータが変なんだよ
2017/10/20(金) 02:12:58.94ID:1vtnnLQF0
ソース
https://i.imgur.com/GWNr9Ru.png

フィルタなし 8bit --crf 20 --aq-mode 3 --tff
https://i.imgur.com/ezLaNm5.png
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
https://i.imgur.com/SjCSAiu.png
デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff
https://i.imgur.com/ofiKhB3.png

デバンドありの圧縮前
https://i.imgur.com/Z3tRpYN.png

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

これで8bitがきれいに見えるならいいんじゃないか。そういう環境ならね・・・
2017/10/20(金) 05:31:39.81ID:meA5JVSG0
おれ環では aq-strength を調整すれば 8bit + デバンド でいいや・・・
2017/10/20(金) 07:45:09.76ID:Bsl5IeCi0
デバンドするしないでも選択肢変わるだろうし
QP値どれだけ盛るかにもよるけど手軽にやりたいなら10bitのほうが楽っちゃ楽
8bitソースにデバンドも何もしないなら10bit使うだけほぼ無駄ってのはそのとおり
2017/10/20(金) 08:33:39.54ID:ljIvdMqUM
なんでアニオタばかりなの？
グクってもみんなアニメかゲームのエンコの話ばかり
実写メインの人っていないの？

自分は実写メインで、地デジソースならデノイズかけてインタレ保持のcrf25ぐらいで5Mbps前後にしてる
SSIMが大体0.978ぐらいになるから糞ソースの地デジならあんまり変わらん気がする
2017/10/20(金) 08:35:38.93ID:ljIvdMqUM
デノイズはNL-Means使ってる
アニメ向きとも言われるが、弱くかければ実写でも10%ぐらい小さくなる
2017/10/20(金) 08:55:47.92ID:CGJgWOmW0
実写メインの人ってHDD録画かBD-Rにムーブして終わりじゃね
容量にも拘りなさそうだしエンコ自体してなさそう
2017/10/20(金) 10:10:35.50ID:qjJPv/bA0
>>474
＞ソース
＞https://i.imgur.com/GWNr9Ru.png
と、
＞フィルタなし 8bit --crf 20 --aq-mode 3 --tff
＞https://i.imgur.com/ezLaNm5.png
はほぼ寸分違わないよな。
ということを言ってるんだよ。

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

デバンド等でぱっと見は綺麗になったように見えるんだけど、
一方で細部の意図したざわざわなディテールも消失するし（地デジなんかのソースにはそもそもそんな情報ほぼ残ってないだろうが）、
いいことばかりの魔法のフィルターは無いのだ。その辺は好みだね。
あくまでもソース寸分違わないかどうかという観点では10bitエンコードは無駄という話。
481名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/20(金) 10:17:59.88ID:qjJPv/bA0
んでもって、x264は
＞8bit --crf 20 --aq-mode 3 --tff
みたいなほぼプリセットそのままな設定でソースほぼそのままの忠実なエンコードができるんだが、

>>466のような話は散々出てくるし、
x265は依然としてそのレベルに達してないのだろうか
2017/10/20(金) 10:39:22.89ID:ljIvdMqUM
10bitで書き出すならデバンド要らなくない？
あくまで内部処理が8bitを越えるデノイズやらリサイズフィルター通したのを8bitで出すための処理じゃないの？
2017/10/20(金) 10:55:30.54ID:l1+4vpOY0
>>481
x265はビットレートをつぎ込んでの高画質はまだx264に負ける
っていうかx265は4k向けの高圧縮コーデックだから2kで負けるのは仕方ない
2017/10/20(金) 11:55:38.66ID:ljIvdMqUM
まだx265が開発途上なだけでしょ
H.264と同じく低解像度から満遍なく圧縮率上げる規格だからx265の改良の余地はある
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のほうがきれいだとか言われていたが、
それは単に当時のコーデックの実装が未熟だっただけで、今どきそんな戯言を言うやつはいないのでそれと同じことだろう
2017/10/20(金) 14:00:38.72ID:l1+4vpOY0
>>485
その水増しってのが認識を間違ってる証拠だと思う
なにも水増しはしてないんだから

>>486
なるのかな
h.264がHD画質でmpeg2より高画質になったのは必然だけど・・
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　出来上がりのファイルサイズめっちゃデカくなりそうだけど
2017/10/20(金) 20:58:55.70ID:4az+If+XM
アニメならそうでもない
さらにフレームレートと解像度によってcrf同じでも品質違ってくる
2017/10/20(金) 21:38:45.04ID:1vtnnLQF0
ソースを忠実に再現って言うと聞こえはいいかもしれないけど、
MPEG2圧縮でできたノイズやアーティファクトまで再現しようとしなくていい

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

デノイズしてから圧縮したほうが綺麗なることも多いし、
テレビは「高画質化エンジン」で加工しまくって表示してる
そもそも圧縮で情報量落ちる分、ある意味「加工」されちゃう
2017/10/20(金) 22:05:29.43ID:o4Nz9FwSM
まあTVはソースがボロボロだからねぇ
2017/10/20(金) 22:06:27.54ID:l1+4vpOY0
>>488
細分化であって水増しじゃないでしょ
494名無しさん＠編集中 (ﾜｯﾁｮｲ 5585-0GSP)
垢版 |
2017/10/20(金) 23:42:25.14ID:HASgMWlT0
8bitきったねぇわろたｗｗｗｗｗｗｗ
こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ

「ソースに忠実」とか意味分からないことに拘るめくらは編集もエンコもしないでTSで保存しとけｗｗｗｗｗｗｗｗｗｗｗｗ
2017/10/21(土) 00:06:33.17ID:GU2WsWjF0
>>480
この違いがわからないなんてよっぽどひどいモニタ使ってるんだね
2017/10/21(土) 01:08:20.59ID:150/70DS0
>>495
「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく
趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。
2017/10/21(土) 01:36:45.74ID:SivVBkBJ0
>>494
デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ
緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう
特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方

というか元から保存用はもちろんTSだわ
スレ違いになるのでそれについては深入りはしないが
MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする
2017/10/21(土) 01:42:00.04ID:SivVBkBJ0
>>493
意味が分からない
じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、
もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う
2017/10/21(土) 01:49:58.38ID:SivVBkBJ0
話がややこしくなってきたので改めて整理すると
>>466
に対する反論として、
8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば
ということを俺言ってるだけ
8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない

んでもってその観点でいうならば、
>>474にはデバンド無し10bitの結果が無いのでその比較にはなっていない
ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが
2017/10/21(土) 02:00:41.89ID:SivVBkBJ0
>>494のようなめくらには副作用があるって言っても
具体的な例を示してやらないとわからないだろうから言っておくと、
たとえばデバンドかけたほうは（圧縮前の時点で）右上の絵画（？）の色の境界ソフトになってるよな
BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ

そういう部分に目が行かず、
＞8bitきったねぇわろたｗｗｗｗｗｗｗ
＞こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
みたいに草生やしてるだけだからお前はめくらなんだよ
2017/10/21(土) 02:48:21.65ID:GOmLStnF0
地デジはともかくブルーレイだと>>474のデバンドあり圧縮前のような
色の階調部分のディザを保っているからな～
少し試してみようか
2017/10/21(土) 03:06:40.59ID:GOmLStnF0
これが>>474デバンドあり圧縮前をcrf0で8bit化したavc（の静止画）
https://dotup.org/uploda/dotup.org1367941.png

------------------------
これがそのavcをcrf20 8bitエンコしたもの
https://i.imgur.com/HkBnse4.png
QP:19.37 size: 31899byte

------------------------
こっちはcrf20 10bitエンコ
https://i.imgur.com/1QptJMb.png
QP:31.10 size: 29806byte


QPがとても上がってるせいかサイズは10bitの方が少ない
画質の評価は見た人に任せるよｗ
2017/10/21(土) 03:22:40.83ID:+8CAoyQn0
>>500
そう、これ使えねーなと思ってさ、直したんだよ

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

対象と判定されたピクセルを表示してみた結果↓
判定表示（改造前）
https://i.imgur.com/JWaCj0O.png
判定表示（改造後）
https://i.imgur.com/ISi0Xnv.png

デバンドありの圧縮前（改造後）
https://i.imgur.com/OBQeZKO.png

オレオレバンディング低減
https://i.imgur.com/dloXldb.png

どうよこれ
2017/10/21(土) 04:09:58.65ID:GOmLStnF0
>>503
素直に欲しいレベル
2017/10/21(土) 06:22:51.12ID:GF3n0jE/M
素通しで8bitソースを10bitにエンコするときにバンディング減ったように見えるのはdeblockが効いてるからだと予想
506名無しさん＠編集中 (ﾜｯﾁｮｲ 5585-0GSP)
垢版 |
2017/10/21(土) 09:21:07.43ID:3Js2SGA+0
別に絵画の精細度なんてどうでも良いんだがｗｗｗ
少なくともこのソースで明らかに目につくのはバンディングだしｗｗｗｗｗｗｗｗｗｗ
まじめくらやべぇわｗｗｗｗｗｗｗｗｗｗｗｗ
2017/10/21(土) 09:28:46.77ID:wM+aM70x0
老眼が進むとどうでもいい
2017/10/21(土) 10:08:27.63ID:/zKw8/Pi0
　　　　　　　　　　　　　＿人人人人人人人人人＿
　　J( 'ｰ`)し　　　　　＞　草刈り中のトラブル　＜
　　○=｛=｝〇,　　　　　￣Y^Y^ Y^Y ^Y^Y Y^Y^Y￣
　 　|:::::::::＼, ', ´ﾁｭｲｰﾝ
.ｗｗし ｗ`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗ
　　　　　彡 ⌒ ミ
　　　　　(´・ω・｀)
2017/10/21(土) 10:30:00.87ID:4zl1vzp40
>>498
1,000円札を100円玉 x10に換金することをお金の水増しというのなら
「水増し」という言葉使いで正しいと思う

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

8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね＞大元は
2017/10/21(土) 10:39:24.59ID:NJkYLvTf0
>>502を見るとどう考えても10bit＞8bitじゃんｗ
ファイルサイズ8bitの方が小さいならまだ分かるけど
大きくてこれとかイイとこなしｗ
2017/10/21(土) 10:48:03.01ID:GLwKHK4T0
静止画だから分かりづらいけど
動画で見たらさらに目立つからなバンディングは
512名無しさん＠編集中 (ﾜｯﾁｮｲ fad2-yWqP)
垢版 |
2017/10/21(土) 10:50:48.21ID:WCEoAZaz0
>>511
うにょんうにょん動いて気持ち悪いよね
2017/10/21(土) 16:10:41.83ID:s2dz+3eBa
うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで
ビット数より圧縮アルゴリズムから来る話で圧縮率の問題だと思うがな
各色8ビットの静止画でバンディングを感じるなんて事はまず無いわけでさ
（モニタのガンマカーブの話はまたややこしいのでカット）
デバンドは近接画素間を圧縮に都合のいい様に加工するから圧縮率高くてもバンディングが解消されるって話でしょ
つまり同容量で8ビット圧縮より10ビット圧縮の方が画質が優れているとしたら「8ビットより10ビットが綺麗」では無く
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」って話だと思うんだが
2017/10/21(土) 16:54:30.19ID:SivVBkBJ0
>>513
＞8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出る

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

x265はほぼ使ったこと無いので知らん
現状のx265なら
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」
ということもあるのかもね
2017/10/21(土) 17:26:01.84ID:SivVBkBJ0
>>502
と
>>474
で全部色が変わってしまっていて何かがおかしい
＞デバンドあり圧縮前をcrf0で8bit化したavc
っていう中間形式の作り方の詳細がよく分からないので何とも言えないけど、
色が変わってしまっているってことはどこかの段階で色空間かレンジの変換がかかってるということはないすか？

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

>>474
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
https://i.imgur.com/SjCSAiu.png

と

>>502
これがそのavcをcrf20 8bitエンコしたもの
https://i.imgur.com/HkBnse4.png
QP:19.37 size: 31899byte

で色が変わってしまうということは起こらないはず
516名無しさん＠編集中 (ﾜｯﾁｮｲ fad2-yWqP)
垢版 |
2017/10/21(土) 17:53:32.26ID:WCEoAZaz0
黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、
暗いところはよく見えんから適当でええやろーみたいな風潮はやめてほしい
no-mbtree指定しても、まだなんかやってんだろって気がする
2017/10/21(土) 17:57:18.23ID:/ssX+XV10
よく見えんところをはしょってごまかすのが圧縮の本質だからなあ
518名無しさん＠編集中 (ﾜｯﾁｮｲ 818a-gcVe)
垢版 |
2017/10/21(土) 18:01:35.48ID:SivVBkBJ0
>>517
バランスの問題もあるな
明るいところとかもっと削ってもばれねーよってときに暗いところ端折りまくるのがね
x264ならその方面のことは設定でなんとかなる柔軟性はあると思う
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
バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよｗｗ
2017/10/21(土) 20:00:51.36ID:s2dz+3eBa
別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ
理屈の検証をしてるんであってどちらの言い分が勝ちなんて勝負をしてる気はみんな無いでしょ
無劣化圧縮の筈なのに色が変わってたらそれは理屈としておかしいから何らかの処理で
色が変わってると考えるのが理論的思考として妥当でしょ
2017/10/21(土) 20:00:58.25ID:SivVBkBJ0
>>519
動きのない完全静止の動画でよければ良ければやってみるよ

>>520
完全素通しっていう前提で主張してるのに、色が変わった（のが分からない人はさすがにいないよな）ならもうそれはカバーできない条件だわ
2017/10/21(土) 20:07:55.46ID:+8CAoyQn0
>>514
ソースにディザが残ってるのを圧縮してディザを消しちゃうとバンディングが出る

デバンドあり 8bit --bitrate 20000 --aq-mode 3 --tff
https://i.imgur.com/fA43LEJ.png

↑8bitだけどビットレート高いからディザが残っててバンディングが出てない
ブルーレイとかはこんな感じ
2017/10/21(土) 20:13:15.41ID:4zl1vzp40
>>514
チューニング次第では？
基本的な技術は同じで違うのは色深度だけなんだから
2017/10/21(土) 20:43:34.22ID:+m1gFY6w0
>>522
それでいいよ
2017/10/21(土) 21:14:07.19ID:SivVBkBJ0
やってみた。
結論から言うと、ソースのディテールを十分再現できる程度（以下の実験ではcrf20）のビットレートがあれば8bitと10bitで差は無いが、
ソースのディテールが再現できずブロックノイズが目に余る領域（以下の実験ではcrf35）になると確かに8bitと10bitに差は出る、
そしてたしかに10bitのほうがブロックノイズのバンディングという面ではマシな結果になる。

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

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

（続く）
2017/10/21(土) 21:16:19.44ID:SivVBkBJ0
実験結果

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

[enc1_crf20_8] 8bit crf20 199KB
https://i.imgur.com/UCaT1tA.png

[enc1_crf20_10] 10bit crf20 178KB
https://i.imgur.com/ezvIeKW.png

[enc1_crf35_8] 8bit crf35 47.9KB
https://i.imgur.com/gil6CHK.png

[enc1_crf35_10] 10bit crf35 48.4KB
https://i.imgur.com/6oLeO8V.jpg


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

[enc2_crf20_8] 8bit crf20 275KB
https://i.imgur.com/mfzemcd.png

[enc2_crf20_10] 10bit crf20 245KB
https://i.imgur.com/B6IT06k.png

[enc2_crf35_8] 8bit crf35 47.5KB
https://i.imgur.com/BCUfJB5.png

[enc2_crf35_10] 10bit crf35 48.2KB
https://i.imgur.com/IKlVQcS.png
2017/10/21(土) 21:18:34.53ID:SivVBkBJ0
なるべく途中で変な処理が入らない用意全部コマンドラインでエンコードした
一連のコマンドは禁止ワードに引っかかったのでpastebinに貼っておいた

https://pastebin.com/b5fBXuRy
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
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から見ても特にこちらの主張が成り立たなくなるほどの劣化は無いと思う

コマンドは示したので、興味があれば手元で追試することもできるのでそこで確認してくれ
2017/10/21(土) 22:17:40.81ID:+8CAoyQn0
>>527
> 10bitだと概ね2割増しのデータを保存しないといけない

この認識は間違ってる

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

H264の場合、QP値が6増えると量子化ステップが2倍になるから、
>>502見てもだいたい12増えてデータ量は同じくらいになってるでしょ
2017/10/21(土) 22:43:24.18ID:SivVBkBJ0
>>533
単純計算して2割増しになるってのはおっしゃる通り、
QPを増やさない（＝一切副作用無く画面全体に8bit→10bitの恩恵を受ける）場合のこと
単純にそうはならないしても、同じファイルサイズで考えたとき
どこかで10bit分の量子化の恩恵を受ける分8bitよりデータが増え、
他のどこかがそれの割を食わないとファイルサイズが8bitと同じにならない

のっぺりした部分に8bitのときよりも細かい量子化を行う（つまりQPが12ほどは増えない）分、
そのほかの部分でQPを12以上増やさないとファイルサイズは同じにならないでしょ
（これも量子化の後にエントロピー圧縮を行うので単純にそうはならないかもしれないが、話を簡単にするために）
実際ファイルサイズがほぼ同じになるcrf35で比較して、のっぺりした部分の再現性は10bitのほうが上だけど、輪郭は8bitのほうが若干よく見える
2017/10/21(土) 22:46:21.80ID:+m1gFY6w0
>>531>>532
いあ正にその色に問題出てるのよ
jpgはYUV420だがpngは24bit

IrfanViewだと目視じゃ違いが見当たらないが
Firefoxや古めの画像ビューアでみた時、pngだけ色が違う
ちゃんと正解の画像見れてるのかモヤっとする
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だったので、
手際が悪くなって申し訳ない
2017/10/21(土) 23:08:19.15ID:+8CAoyQn0
>>534
のっぺりした部分に8bitよりも多くデータ量割かないと
10bitの恩恵が受けられないってのは確かにそう

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

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

↓こんな感じ

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

画質
(8bitでディザを残す) ≒ (のっぺりした10bit) >>> (のっぺりした8bit)
2017/10/21(土) 23:21:08.68ID:SivVBkBJ0
実験結果

バンディングがある8bitソース(source1 10秒)
https://light.dotup.org/uploda/light.dotup.org487830.png

生成元
https://i.imgur.com/GWNr9Ru.png
と色も含めほぼ変わらないのを確認※


[enc1_crf20_8] 8bit crf20 185KB
https://light.dotup.org/uploda/light.dotup.org487831.png

[enc1_crf20_10] 10bit crf20 166KB
https://light.dotup.org/uploda/light.dotup.org487832.png

[enc1_crf35_8] 8bit crf35 47.9KB
https://light.dotup.org/uploda/light.dotup.org487833.png

[enc1_crf35_10] 10bit crf35 48.2KB
https://light.dotup.org/uploda/light.dotup.org487834.png

（続く）
2017/10/21(土) 23:21:35.33ID:SivVBkBJ0
ディザでバンディングを軽減した8bitソース(source2 10秒)
https://light.dotup.org/uploda/light.dotup.org487838.png

生成元
https://i.imgur.com/fA43LEJ.png
と色も含めほぼ変わらないのを確認※

[enc2_crf20_8] 8bit crf20 264KB
https://light.dotup.org/uploda/light.dotup.org487835.png

[enc2_crf20_10] 10bit crf20 234KB
https://dotup.org/uploda/dotup.org1368691.png

[enc2_crf35_8] 8bit crf35 47.6KB
https://light.dotup.org/uploda/light.dotup.org487836.png

[enc2_crf35_10] 10bit crf35 47.1KB
https://light.dotup.org/uploda/light.dotup.org487837.png

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

結論としては特に変わらず
2017/10/21(土) 23:22:47.11ID:SivVBkBJ0
コマンドライン
https://pastebin.com/BFCdRUWL
2017/10/21(土) 23:36:03.65ID:+8CAoyQn0
>>539
8bit crf20だとディザが残ってるね。静止画だからビット数多く割けたのかな
動画だと>>474にあるようにディザは消えちゃうんだよ
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、ただし画質の劣化の方向性が違うのでトレードオフ要素あり

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

まあ、上の例でいえばABとCDの中間の状態になるわけで、
ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、
っていうときは10bitにも利点はあると思う
ある意味フィルターをかけてるとの同じことになるわけで
2017/10/21(土) 23:57:00.97ID:+8CAoyQn0
>>542
> のっぺりする＝ソースのディテールを再現できないほどの低レート

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

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

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

8bitだとディザが消えてのっぺりしちゃったら、もうそれまで
8bit→8bitでディザを付加したりはしないからバンディングはそのまま
2017/10/21(土) 23:59:12.57ID:+8CAoyQn0
>>543
動画でディザが残せるのは相当高ビットレートだよ
>>523は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから
20MbpsってCRFだと相当低い
ブルーレイ並のビットレートがないとディザは残せない（8bitでも10bitでも）
2017/10/22(日) 00:04:05.35ID:TL71NAj40
さらに言うと、データ量減らすためにエンコしてるんだから、
ディザを残すのにデータ量食われるくらいなら
のっぺりした10bitにして、きれいなグラデーションのままデータ量減らしたほうがいい
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並みのレートになるので、
ソースを加工してでもバンディングは消す！という場合はひどいレートになってしまうのかもしれんが
2017/10/22(日) 00:30:26.86ID:TL71NAj40
>>547
なるほど、BDだとソースが良いから状況がいいんだと思う

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

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

時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、
副作用があったりで難しいんだよ
2017/10/22(日) 00:34:12.01ID:TL71NAj40
BDだとこの「うにょんうにょん」が出ないんだろうね
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
そのうにょんうにょんってのが何なのか分からんのだが、
それはソースで出てるやつなの？
それともソースにはないのにエンコードすると出るって話？
後者だとしたらさすがになんかどこかに齟齬がある気がする
2017/10/22(日) 00:59:06.47ID:TL71NAj40
>>551
ソースでは細かくパタパタしてるだけなんだけど、
エンコするとそのパタパタの周期が落ちて目立つようになってくる
ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる

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

crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない
2017/10/22(日) 01:14:01.45ID:vZIrSnTK0
>>552
なんかその現象はこちらはピンと来ないんだよな。
関係あるか分からないけどインターレースに起因するアーティファクトってことはないすか？
＞エンコするとそのパタパタの周期が落ちて目立つようになってくる
っていう時点でエンコかける時点で避けられない劣化みたいに言ってるように見えるので。

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

まあでもこれはこちらが60p化で止めてるものを24pに落とせばいいだけで、
むしろデータ量が多少減らせる（60pでもほぼ差分の無いフレームなので大差はない）ぐらいで
悪いことは特に起こらないと思うけど。
2017/10/22(日) 01:16:13.79ID:vZIrSnTK0
ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。
これならばtsを再生するよりもむしろきれいなソースが得られますぜ（所詮再生するためにはリアルタイムのI/P変換である必要があるから）。
ただしエンコードは（I/P変換が律速になるので）2～5fpsを上回るのは無理。
まあここまで行かないにしてもTDeintとか使えば10fps～20fpsぐらいの許容できるfpsでまず間違いない品質になると思うけど。
2017/10/22(日) 01:38:35.79ID:vZIrSnTK0
あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを
無理やり24Hzに落とし込むから比較的低周波のうなりになってしまって目立つという話なのかも

それなら60Hzソースを24Hzにすることに無理があって、
やるならばきれいに60p化したうえで時間軸のNRをしなさいということなのかも
（時間軸のNRをするのだから24Hzにしたあとやるのは論外）
2017/10/22(日) 01:42:18.29ID:TL71NAj40
>>553
ごめん、もう説明するの疲れたわ

QTGMCはBob化ベースだから細かい文字とか潰れるんだよね
だから、QTGMC掛けた後にソースから細かい文字だけマージするフィルタ作ったわ
SouceMatchやLossless使うよりも効果があって、処理も軽いよ！
https://i.imgur.com/bhoxmSQ.png

どうよこれ

あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて
2017/10/22(日) 02:16:24.06ID:TL71NAj40
やっぱ60p化が失敗とかなくていいよね
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
2017/10/22(日) 10:09:56.80ID:gaqeh3U00VOTE
>>556
githubのページで公開よろ
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でもレンダラ選べる再生ソフトに変えたらいいと思うぞ
2017/10/22(日) 15:20:42.26ID:OuXW9nEl0VOTE
>>556
KTGMC、試すアル

>>559
もうあったぞ
2017/10/22(日) 15:42:09.87ID:TL71NAj40VOTE
>>558
これ実装したときはあまり効果がなかったなと思って、
改めて見てみたら、デフォルトのしきい値15は高すぎるんだった
8bitYUVの差1はだいたい5に相当するから、6～10が適正値だね

>>474はしきい値が高すぎてかなり強く掛かってるから副作用出まくり
普通に使えばこんな副作用でない
しきい値6～8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ
2017/10/22(日) 15:47:02.38ID:iDXae9fs0VOTE
>>560
単にタブレットやスマホはコントラスト低いから目立たないだけじゃね
Windowsって言っても動画再生はGPUに依存する
Intelの内蔵GPUはクソ画質
2017/10/22(日) 16:11:54.86ID:TL71NAj40VOTE
>>558
期待させてすまん
2017/10/22(日) 17:35:45.57ID:vPHZ1rdJMVOTE
>>565
判定表示機能も欲しいので下さい
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でディザリングするような使い方をしてる人はあまりいないのでは・・・？
2017/10/22(日) 20:15:07.70ID:TL71NAj40
>>567
8bit出力でも効果があるっていう原理を説明しただけ
ほとんどデフォのままでも10bitならきれいになる
モニタまで10bitで出力できるような環境ならそれでいいんじゃない
2017/10/22(日) 20:40:18.12ID:vZIrSnTK0
>>556
QTGMC(EdiMode="TDeint")
で、TDeintと同じように輪郭はボケなくなる
結局TDeintと動作原理は同じなのかもしれないけど、
QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる

まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、
コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然
60iで失われてるところをもっとも自然に補完するとこうなるんだと思う
2017/10/22(日) 20:45:30.50ID:vZIrSnTK0
>>568
というかYUVの8bitとRGBの8bitが1:1に対応してないから
最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、
RGBにディザをかけるかけないは全く不要だと思う
正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで
2017/10/22(日) 21:07:13.27ID:huQNYVlR0
>>568
>モニタまで10bitで出力できるような環境ならそれでいいんじゃない

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

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

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

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

一応

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

という方法もあると言えばあるけども、LAVの出力をRGBに絞る必要があるし、使ってる人はほぼいないと思う。
2017/10/22(日) 21:18:42.71ID:B85gEeQj0
で、x2648bitだけでデバンドはどうすりゃいいの？
2017/10/22(日) 21:47:50.35ID:TL71NAj40
>>569
そういう方法もあるのね
QTGMC(EdiMode="TDeint")だとQTGMCのベースの絵にTDeint使うけど、
>>556はQTGMCの後に補間するから原理はちょっと違う

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

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

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

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

>>571
そうなんだ
素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの？
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化されてしまうので無意味だったと思う。
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とか使ってる人は「ほぼいない」のか
ちょっと認識にずれがあるようだ・・・
2017/10/22(日) 23:29:03.38ID:huQNYVlR0
>>575
なんかうまく伝わってないようなので書いとくけど、

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

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

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

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

３の方式にこだわる理由って何かあるの？
2017/10/22(日) 23:35:46.02ID:TL71NAj40
>>576
そういうことね
>>568にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる

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

世の中一般的な人の手を煩わせないこと
2017/10/23(月) 01:29:13.55ID:CCGuLeMv0
>>577
>世の中一般的な人の手を煩わせないこと

LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。
2017/10/23(月) 02:12:14.47ID:PdPTQ2n50
>>578
分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね

拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの？
2017/10/23(月) 02:28:08.64ID:PdPTQ2n50
あと

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

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

別に統計調査したわけじゃないけども
2017/10/23(月) 03:22:20.83ID:GGoO9AOU0
265だが、12bitでエンコする人もいる。
582名無しさん＠編集中 (ﾜｯﾁｮｲ a550-0GSP)
垢版 |
2017/10/23(月) 07:14:50.53ID:VYJgHsTz0
デバンド10bitがファイナルアンサーってことでおｋ？
めくらとめんどくさがりはデバンド無し8bitってことだよな？
2017/10/23(月) 09:52:34.86ID:GWH8jZaN0
>>582
１人で空騒ぎを続けてる姿はなんか見てて可哀相になるんだけど、戻れるならそろそろ正気に戻った方がいいんじゃ・・・
2017/10/23(月) 10:52:56.78ID:ArbVx6vZM
無理です。こういうのは治りません
2017/10/23(月) 12:22:06.79ID:GWH8jZaN0
>>579-580

> デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとでどれくらい差があるの？

暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。
2017/10/23(月) 12:24:02.28ID:GWH8jZaN0
>>579-580

>>574の後半は少し間違ってたかも。

　１．以前はEVR/EVR-CPにP010を渡してもうまく動かなかった。
　２．なので以前のLAVではEVR系にはP010ではなくNV12で渡すようにしていた。
　３．Win10CUからEVR系にP010を渡しても大丈夫になったので、LAV 0.70.0からは、
　　　Win10CU環境ではEVR系にもP010を渡すようになった。
　４．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でも綺麗に見えたというのは釈然としないけど俺が何か勘違いしてるんだろか。
2017/10/23(月) 14:01:50.39ID:C3fk7LFm0
バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなｗ
折角低減されたバンディングが少し再発しててワロタｗ
2017/10/23(月) 14:03:38.98ID:GGoO9AOU0
最小限、VLCでまともに見れれば問題ないんじゃね？っていう。
MPCはコーデックとかデコーダに依存しすぎるから少しでも環境が変わると
画質や動作にまで影響をお呼びしかねない。グラボのドライバを更新したとか
OSを大規模更新させたとかetc
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で表示したときの画像
https://i.imgur.com/FDzP7Hu.png

これがバンディング出てるように見える？

>>474はAviUtlで読み込んでキャプチャしたから、
ディザリングなしで8bitRGBへの変換が行われてバンディングが出てるけど、
ちゃんとディザリングすれば8bitYUVへの変換でもバンディングは出ない

何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない
2017/10/23(月) 18:01:02.87ID:PdPTQ2n50
MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
ボビングしてる。インタレ解除が下手なのかな

madVRはH264のノイズがそのまま出てて汚い

少なくともPascal世代のGeForce積んでるマシンなら、
WindowsデフォのEVRが画質は安定してる印象

なんか俺間違えてる？
2017/10/23(月) 19:37:23.86ID:QlGXZ1na0
情報錯綜系LAVコメ
2017/10/24(火) 02:20:01.25ID:n9jE2wGA0
>>590これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど
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のインタレ解除対応とかについてはよくわからない。
2017/10/25(水) 03:12:22.43ID:czTfBjnQ0
>>593
おーお疲れ。うちの環境でも表示のされ方はだいたい同じだったよ
なるほど、YUVでディザリングはしてるけど、YUV→RGB変換が1対1に対応しないから、
値を飛び越えちゃうところで色の違いが出てるのかなぁ
いろいろな影響があって難しいね
2017/10/25(水) 10:09:56.42ID:8tRowaog0
>>593
ところで8bitで再生って具体的にどうやるんだ？

プレイヤーとかデコーダにそんな細かな設定項目はないだろ？
2017/10/25(水) 12:33:28.30ID:9O9mFGbAd
>>595
無知な上にスレチな話題を無駄に広げるんじゃねーよ
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ソースを生かせる
2017/10/25(水) 15:12:24.15ID:tWKQzPChM
そんなに気にするならソースのまま残せばいいじゃん
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でエンコされたものをソースと言ってるように読める
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
うにょんうにょんの話から始まってたのか
色々しらべてくれてありがとう
2017/10/26(木) 00:08:06.54ID:ly9F1jYY0
>>601
じゃあ、もう少し乗っかってみる
>>594で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた

環境はGTX1060でWindows10。全部MPC-BEでEVR-CPレンダラ

LAV→(NV12)→EVR(8bitサーフェス→8bitRGBディスプレイ）
https://i.imgur.com/JUXbiHR.png
>>593とちょっと色の出方が違うけど、バンディングは同じようにも見える

LAV→(P010)→EVR(8bitサーフェス→8bitRGBディスプレイ）
https://i.imgur.com/kL0gCho.png
>>593のmadVR-P010-ditherONと同じような表示になった

LAV→(NV12)→EVR(10bitサーフェス→8bitRGBディスプレイ）
https://i.imgur.com/BqmypsW.png
>>593のmadVR-NV12-ditherONと同じような表示になった
2017/10/26(木) 00:10:27.95ID:ly9F1jYY0
Intelグラはディザリングしないんだね
うちのPascalだとレンダラで10bit→8bit変換するときはデフォでディザリングされるっぽい
2017/10/26(木) 00:19:52.85ID:ly9F1jYY0
画質にこだわるならグラボ導入をお勧めする
2017/10/26(木) 01:44:20.96ID:83kz963X0
理由を論理的に教えて
2017/10/26(木) 11:37:44.52ID:Lqu4m2pKM
UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
単純に再生時のフィルター処理やらせるかどうかの違いだろ
オンボサウンドが音質悪いからって、サウンドカード挿すぐらい滑稽(どっちもマザボ由来のノイズは乗る)
2017/10/26(木) 12:05:51.59ID:koiMQ39k0
>>603
うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1：GTX660→DVI接続→IPSパネル
モニタ2：4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える

GPUなのかモニタ原因なのか接続方法なのか…オモシロｗ
2017/10/26(木) 12:10:12.06ID:h1bMYZBgM
比較するなら何故接続方法とディスプレイを同じにしないのかなぁ
一円にもならない雑音でしかないぞ
2017/10/26(木) 13:52:56.00ID:FitUuNIK0
>>603
どうせ比較するならカラーバーにしてほしかった。
何故黒背景なんだ？違いがわかりにくすぎるわ。
2017/10/26(木) 17:37:30.49ID:bZqhxTl+0
>>603
うーん・・・うちでそれらの画像を>>593（うちのIntel環境の結果）と比べると以下のように全然違って見えるけど・・・。

１番目（NV12+EVR）
　少しバンディングの出方が異なるが、「EVRCP-NV12」とほぼ同じくらい。

２番目（P010+EVR）
　P010出力なのに、３つの中で画質が最も酷い。細めの汚れたバンディングがはっきり見える。
　「madVR-P010-ditherOff」で生じているバンディングを更に悪化させたような感じ。
　「EVRCP-P010」や「madVR-P010-ditherON」の方がはるかに綺麗。

３番目（NV12+EVR(10bitサーフェス)）
　「madVR-NV12-ditherON」と似てはいるが、ざわつきが酷く画質としては劣る。
　バンディングがほぼ気にならないレベルになってるのは
　10bitサーフェスをデスクトップ(8bitRGB)に統合する時に、もう一度ディザリングしているのかな？
　結果的にバンディングが目立たなくなっているとはいえ、無駄な処理をしているとも言えるような。

うちはノートPCでモニタも6bit+FRCなTNというショボ環境だから、他の人の結果や意見も聞いてみたいところ。
2017/10/26(木) 17:45:49.30ID:bZqhxTl+0
>>603
２番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも？

>>604-605
> Intelグラはディザリングしないんだね

ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」（LAVがレンダラに渡しているデータ）と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。

>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー？
2017/10/26(木) 17:58:50.33ID:bZqhxTl+0
まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。
2017/10/26(木) 19:59:26.61ID:cJclLwoB0
スケーラー的には
カスタムEVRのほうが比較対象になりえるかと
2017/10/26(木) 22:29:15.67ID:ly9F1jYY0
>>611
こちらは4Kブラビア（KJ-49X8300D）にAVアンプ（AVR-X2100W）経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
2017/10/26(木) 23:26:47.90ID:ly9F1jYY0
>>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ
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スレへ。
2017/10/27(金) 00:52:10.89ID:XMw2Db120
>>617
> EVR-CPのP010処理が何か変

おかしくはないよ
うちの環境で「BE-白050-線-EVRCP-P010」を写してカメラで撮ってみた

>>593の画像
https://i.imgur.com/xPCZlun.jpg

>>603の画像
https://i.imgur.com/A5KuEHh.jpg
2017/10/27(金) 01:02:44.22ID:XMw2Db120
一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる

ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない
2017/10/27(金) 09:54:55.94ID:s36iLAYK0
>>617
EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず

だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも
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の模様。
2017/10/27(金) 23:21:04.83ID:s36iLAYK0
>>621
プルダウンで簡単に使えるのが利点っちゃ利点＞EVRカスタム
2017/10/28(土) 12:50:01.41ID:MkHSDZTa0
>>621
白111-P010-EVRCP(8bitサーフェス)
https://i.imgur.com/ZL3n0Ai.png
2017/10/28(土) 12:51:23.89ID:MkHSDZTa0
ID変わってた
2017/10/28(土) 14:34:52.13ID:FG5EURDq0
サンプルは>>516が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw
2017/10/28(土) 16:07:06.26ID:aZTaLCEhM
バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな？
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの？
2017/10/28(土) 22:29:00.96ID:hchLrIBF0
>>623
ありがとうございます。参考にさせてもらいます。

>>626
そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。
2017/10/28(土) 23:31:24.66ID:k7D3xxA+0
>>626
基本的にソースにあるバンディングを消すものだよ
けど、ソースを少なからず弄るものだから
冒頭の極端なものは無視するが吉
2017/10/29(日) 09:40:11.40ID:dhWMtRCq0
MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか？
2017/10/29(日) 09:43:54.16ID:BrtN7tba0
no-info パラメータって x264 にはないんだっけ？
2017/10/29(日) 09:45:36.07ID:BrtN7tba0
>>630
あったとしても、エンコード日付までは消せないか
ソースいじって自ビルド使うしかなさそう
2017/10/29(日) 10:25:41.22ID:KYvLeTqdd
エンコード日とかって
muxし直したら新しく書き換えられるから
x264とはまた別じゃないかな？
2017/10/29(日) 12:30:57.98ID:NansAZRP0NIKU
>>632が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから
Muxだけやり直せば上書きされるはず。
2017/10/30(月) 09:36:19.37ID:uLnu7qaJ0
muxプログラムを改変する
2017/10/30(月) 15:01:11.04ID:720xvp1Sx
わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな
2017/10/30(月) 15:02:21.57ID:uLnu7qaJ0
P2Pなんでまだあんのか？
2017/10/30(月) 15:49:28.52ID:3lz3qnqA0
違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。
2017/10/30(月) 16:38:40.79ID:rJwJGDaI0
ボクが一番早くエンコしたんだッ！
2017/10/30(月) 20:41:33.46ID:cDns2kcE0
ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。
2017/10/31(火) 11:38:38.08ID:TbmUAHOn0
>>635
デカ過ぎるcrf値にしていたり、ダイエットし過ぎたbitrate値にしているのをバレたくないとかじゃね？
2017/10/31(火) 11:45:43.27ID:TbmUAHOn0
あとはme dia にしてるのをバレたくないとかw
2017/10/31(火) 12:28:54.81ID:jvMJnAPgM
>>639
それなら単純にファイラーで作成日時いじればいいだけなのは明らかにわかる
火消し必死な自称エンコ職人の違法アップロード野郎
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 にしてるわ
2017/11/05(日) 19:56:26.63ID:PcnMP+Wd0
x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか?
2017/11/05(日) 22:57:38.08ID:w1/54n9e0
悩む必要ないだろ
2017/11/06(月) 09:49:57.89ID:fjXKV0Z6M
>>645
両方ともグリスバーガーだから、オーバークロック前提ならRyzenスレッドリッパー1950Xだろ
殻割りで壊すリスク冒すなら7920Xでもいいが
2017/11/06(月) 12:20:23.32ID:nWEh0PuI0
オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか?
2017/11/06(月) 12:45:07.90ID:PJNEo3fvd
スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば？
それでもコア数多い7920Xの方が速いだろうけど
2017/11/06(月) 13:05:09.71ID:AhYKSv2j0
threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。

Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。
2017/11/06(月) 13:12:22.24ID:oJ3dfrAb0
4～8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた
2017/11/06(月) 16:34:37.78ID:X8UDX3Yv0
貴重なご意見いろいろと感謝でごわす。
2017/11/07(火) 09:07:41.08ID:qqxdUWwBa
並列でエンコードすればよいのでは？
2017/11/07(火) 09:14:27.30ID:JI9elUeS0
良いプラグインを選んだり自分で最適化ビルドして
うまいことavsを書けばコア数の多さを
純粋に速度upに繋げることはできる
2017/11/08(水) 15:50:54.81ID:b8akNCrvd
x264のソースで、
参照しているマクロブロックについて
書かれているところが分かる人いないかな？
2017/11/08(水) 21:48:17.18ID:QomPI2yH0
CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね

intel vtune買えるほど、こずかいあったら解析してみたいなー
2017/11/08(水) 21:53:09.78ID:2xU4/lpbM
メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない
2017/11/09(木) 03:55:05.26ID:2lLHGB5mx
x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
対応してたとしても、例えばHuffyuvのデコードは4スレッドまでしか対応してないし
あとは、ドライブの転送速度が追い付いてないとか
2017/11/09(木) 12:08:59.88ID:dAkiAuRl0
>>656
h.264の基本設計が古いのが原因
2017/11/09(木) 21:23:04.94ID:4E6+DEQl0
>>659
は？
2017/11/09(木) 23:26:26.85ID:8skGIZpd0
>>648
6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな
2017/11/10(金) 01:06:53.06ID:6Gf3GwUMd
>>661
Doomで中の人が言っていたから本当
だが、それはSDサイズの話だろう
SDで6950Xだと70%くらいしか使わないんじゃないか？
2017/11/14(火) 22:36:13.81ID:QgQDG7qe0
x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる？

公式より、ちょこっと高速かも。
2017/11/14(火) 23:31:21.00ID:Y7L7Tzex0
バイナリよりもソースコードが欲しい
2017/11/14(火) 23:54:34.74ID:OmCERatJ0
最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
あれが対応しないと微量(6-8fps前後)だがエンコ速度に差が発生するから損した気分になる。
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の内部

関数内の処理時間順
ttp://iup.2ch-library.com/i/i1868333-1510835655.png
呼び出し回数順
ttp://iup.2ch-library.com/i/i1868332-1510835582.png
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とか調べてないから、動かなかったら教えて。


自分でビルドしたい人は、ｍｓｙｓのlinkerをmvしたりしないと通らないから要注意
2017/12/03(日) 22:51:56.93ID:MUdUJt2U0
>>667
その画像、jane styleでdecode errorになるのだが・・・つかえねぇなほんと。
画像うpするなら自分で消さなきゃなかなか消えない、imgurを使えよ。
2017/12/03(日) 23:17:58.10ID:N46X2NJO0
俺のjane styleではちゃんと表示できてるぞ
むしろimgurのがdat入れたりせにゃあかん
2017/12/03(日) 23:48:24.68ID:EBQZzVDS0
今、ブラウザでアクセスしたけどリンク切れだったよ
専ブラのキャッシュに残ってるのでは？
2017/12/03(日) 23:55:28.12ID:MUdUJt2U0
結局janeのビューアが改善すればいいだけの話か。
susieプラグインとか2004年頃から更新されてないもんな・・・
2017/12/23(土) 15:27:24.06ID:a6JnGRMU0
r2345
誰か持って無いですか？VLCのはx264guiExに怒られるし
kmodはアーカイブ辿ってもないし
2017/12/23(土) 21:21:11.03ID:VSoAQ8Gh0
>>673
怒られるっつっても
　　指定されたx264.exeはmp4出力に対応していません。
　　出力拡張子を".264"に変更して出力を行うため、muxが余分に発生し、時間がかかる可能性があります。
　　mp4出力に対応したx264.exeを使用することを推奨します。
と出るだけだから、何か試す程度ならVideoLANのバイナリでいいと思うが・・・。

muxがどれくらい遅くなるのかは知らないけど、わざわざr2345を常用したい理由でもあるの？
x264guiExも最新のバイナリにあわせて更新されてるから、
古いバイナリを使ったら設定値が思うように反映されなかったりすることもあるけど。
2017/12/24(日) 13:25:40.34ID:3pc8lJGL0EVE
自ビルドすればいい
たいして、手間はかからないだろ
何をしたいのか理解できないけど
2017/12/24(日) 13:47:04.26ID:PblLLtX90EVE
ソースもみつからないんだろうよ
2017/12/25(月) 00:09:20.14ID:3pbDkQUJ0XMAS
>>673
つ ttps://www.solidfiles.com/v/XGnzXKeZQ8kWp
2017/12/25(月) 00:12:41.45ID:3pbDkQUJ0XMAS
基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ
でないともれなくウザいジャンクマルウェアがブラウザをフリーズさせようとするからw
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でのみ使用され、その利得は非常に小さい。
2017/12/25(月) 12:34:34.96ID:64mfmyLL0XMAS
ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから
買い換えるという選択肢がないかもしれないけどRyzenはマジで優秀だからな
それなりにエンコする機会があるなら買って損はないと思う
性能がそこそこ優秀な割に異常に安価な1500Xあたりで組めばそれなりの価格で収まるし電気代も優しい
2017/12/25(月) 16:35:53.17ID:YUlv4pKh0XMAS
>>677
ありがとうございます。理由は>>679氏の指摘です
本当に助かりました
2017/12/25(月) 17:43:40.36ID:hZyUPP7q0XMAS
たしかそれ以降にもAMD向けのはガッツリ削られたんだっけ？＞XOPとか
2017/12/25(月) 18:01:10.84ID:leIDQpx9xXMAS
>>680
ryzenAPU(GPU内蔵)が来年頭に出るらしいから、コンシューマ向けだとそれで完全に事足りるわな
ただし4コアしか出さないらしい
2017/12/25(月) 19:28:13.40ID:3pbDkQUJ0XMAS
余談だが、ブル世代のAPUとFXもMisaligned SSEが使えるわけだけど、それも無効にされている。
APUはVCEでハードエンコできるからまだいいが、FXは限界までOCしてゴリ押しするしか無いんだよな。
2017/12/26(火) 11:10:32.20ID:MqszZ9OX0
r2893
2017/12/27(水) 21:16:05.28ID:zQsT06DJ0
暖房用にx264を全力で走らせてるんだが中々部屋が暖まらない寒いよー
冬季向けりヴぃじょんとかありますか？
2017/12/27(水) 21:32:58.33ID:A7c/BO+S0
フィルタ処理をGPUにやらせて、PC台数も増やせば結構暖まるよ
2017/12/27(水) 23:48:27.66ID:7YvG+X4m0
PCの排熱を使用した暖房機器で電気代タダってのが外国でやってなかったっけ
2017/12/28(木) 01:23:11.91ID:Hdam5um00
マイニング
2017/12/28(木) 01:42:45.33ID:AFh2AJRd0
副次的に温まるのは仕方がないが暖房に使おうという発想はおかしい
2017/12/28(木) 02:17:54.51ID:gCKZ0KCj0
電熱による暖房は効率が悪いからな
電気暖房で効率重視なら現状ヒートポンプ一択
とはいえコスト度外視ならハイエンドPCを2台もフル回転させれば多分ちょっとしたセラミックヒーターくらいの発熱はあるはず
ただ熱を垂れ流すしか能がないヒーターよりは何らかの仕事をさせられる分だけ建設的なのかも知れん
2017/12/28(木) 02:31:54.29ID:O4ji26IE0
いや～ん
2017/12/28(木) 13:39:09.46ID:afSjZm/R0
なんとなくr2893メモ

・8bitと10bitのバイナリを統合
　→１つのバイナリで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統合対応が地味に面倒そうではある。
2017/12/28(木) 14:26:10.04ID:k6Qd+NbI0
10bitでエンコしてると8bitでエンコする機会なんて格段に減ると思うのだが。
2017/12/28(木) 14:28:57.26ID:oE/hHUIQx
放送物はBDMV準拠で保存してるから、逆に10bitでエンコする機会がない
2017/12/28(木) 15:30:50.89ID:7aUzwO6o0
自分の好きなようにしたらエエ。
俺は PC で再生するだけだから 10bit 派。
そのくせ BlueskyFRC を挟んでFluid Motion してるから余り意味が無いという。
2017/12/28(木) 16:45:46.07ID:k6Qd+NbI0
x264.exeにフィルタ機能とかリサイズ機能とか正直いらないんだよな。
そういうのはAVSでやらせりゃいいんだし。
2017/12/28(木) 17:58:21.58ID:PElpFoJXM
linuxでもWindowsでも同じようにフィルタかけられて便利
2017/12/29(金) 21:05:04.38ID:dM0UDBZS0NIKU
x264guiEx 2.53、r2893バイナリ対応
700名無しさん＠編集中 (ﾜｯﾁｮｲ 67fa-MiNv)
垢版 |
2017/12/31(日) 11:38:00.81ID:90rtTOjH0
誰でも自分ＰＣで稼げる方法など
参考までに、
⇒　『政道のゴウイウセレイイ』 というＨＰで見ることができます。

グーグルで検索⇒『政道のゴウイウセレイイ』

A6L4JIAVLJ
2017/12/31(日) 12:00:58.03ID:u4+XlIJ20
Komiser更新されないなあ
2017/12/31(日) 13:19:58.29ID:dk79hbO30
× Komiser
〇 Komisar

tmodもまだだね。
2018/01/01(月) 14:51:32.47ID:RHbXXe2Q0
今回modは判別ルーチン入れる必要あるしテストも含めて時間掛かるんじゃ
2018/01/01(月) 21:35:23.29ID:dlGBebkV0
10bit版のパッチがなかったら移植の手間がかかるのでは
2018/01/05(金) 12:33:57.79ID:Pcgh0yt50
tmodのr2893が来てた。
パッチとの互換性を考えてffmpegは2.8.xのままとか、新しいブランチ作ったとかのWARNINGあり。https://github.com/jpsdr/x264/releases

kmodはまだ来てない。
2018/01/07(日) 00:59:09.06ID:mh9JPq/j0
help見るとr2867になってるね
2018/01/07(日) 04:48:21.14ID:8MeYYXbe0
>>706
ホントだ
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。
2018/01/07(日) 19:43:34.12ID:WmxR42qr0
3行で頼む
2018/01/07(日) 19:48:26.48ID:8MeYYXbe0
>>708
説明お疲れ様です

>>709
公式とは別物
コアな機能改善が省かれてるかどうかはわからない
.
2018/01/08(月) 00:29:53.77ID:nnJbUV+b0
個人的に分割してくれたほうがいい気がする(1つに集約＝その分重くなる？)
x265.exeでも感じたけど･･･
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
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
2018/01/09(火) 00:08:32.01ID:JJKYVbAG0
普通に考えて8bitか10bitか毎フレーム判断するわけないわな
2018/01/09(火) 00:54:02.42ID:Hfl6BYFl0
Komisar何やっとるんだ？
2018/01/09(火) 01:05:42.16ID:R6ucHgby0
別に仕事でやってるわけじゃないんやで
2018/01/09(火) 02:00:22.72ID:qOe0KmCS0
60000/1001で同じようにエンコしてどのぐらい出るか知りたい。
動きの多いアニメや殆どの実写映像も60fpsでエンコさせるとヌルヌル動いて気持ちいいし
2018/01/09(火) 05:08:35.40ID:88bv/YTOx
crf20でそんなに縮むのはアニメだからだな
実写でcrf20なんてやったら12Mbpsなんて軽く越える
2018/01/09(火) 12:12:39.70ID:dbYDA8uS0
>>717
アニメで60fpsとかよそで言うと恥ずかしいから気をつけろよ
2018/01/09(火) 12:51:44.97ID:qOe0KmCS0
何がだよ。SAOの映画とか60fpsでエンコしてみろ、動きがヌルヌル過ぎてすげー気持ちいいから
2018/01/09(火) 13:04:15.79ID:BobtuyPM0
映像自体が60のアニメもまったく無いわけではないがごく一部だけだな
2018/01/09(火) 13:12:14.00ID:qOe0KmCS0
特にエンディングのスタッフロールとかは60fpsでエンコすると
テロップ類の動きがヌルヌル過ぎてすげー気持ちいい。
RPGとかのエンディングみたいに最後まで飛ばさず見よう！って気になるw
2018/01/09(火) 16:24:41.33ID:cLDLIUCj0
>>717 >>722
フレーム補間という手法を覚えたばかりではしゃぎたくなるのはわかるけど、スレ違いなので他でやっとくれ。
何を使ってフレーム補間してるのか知らないけど、逆テレシネしてないアニメをソースにしたり
いまどきMBlockFPS()を使ってるなんてオチがなければいいけど。

>60000/1001で同じようにエンコしてどのぐらい出るか知りたい

エンコード速度(fps)は毎秒どれだけのフレームを処理できるかを表すので、元動画のフレームレートは関係ない。
フレーム数が増えれば必要時間は増えるし、フレーム補間してるならその負荷がかかるけど
それはx264とは別の話なのでこのスレでは関係ない。


>>718
>>712-713のtest-1080p.mkvは、x264/x265ベンチマークスレで使ってる実写映画の予告動画だよ。
2018/01/10(水) 02:37:24.51ID:OxVNvmBN0
病院行け
2018/01/10(水) 09:21:00.19ID:CFbPtkjP0
>>722
このスレでも無知を晒し続けるのマジで恥ずかしいからそれ以上やめろ
俺の共感性羞恥に効く
2018/01/10(水) 09:25:38.85ID:OIe9TqRjM
一時期あった30/24混合のアニメは面倒だからインタレ保持でやってる
2018/01/10(水) 11:21:20.18ID:7k1pcodv0
>>724
なんの病名だよエンコード病とかか？w
728名無しさん＠編集中 (ﾜｯﾁｮｲ 9fd2-Gfid)
垢版 |
2018/01/10(水) 12:55:19.73ID:lXjmbGhD0
むしろ動いてないところは削りまくってタイムコードで引き伸ばしてるわ
2018/01/10(水) 15:08:45.13ID:W8NHXz/H0
60iを60pにしたというオチじゃないよな
テレビ放送をテレビで見ると60fpsで見てることすら知らなさそう

こんなことで喜べるんだから、無知っていいな
羨ましすぎる
2018/01/10(水) 16:45:54.81ID:AJNxVRak0
昔からドラマのOPをヌルヌル綺麗にエンコしたいとか散々見たような
2018/01/10(水) 20:59:31.15ID:7k1pcodv0
>>729
上から目線で他人のエンコ趣味をコケにしてそんなに楽しいかね？
2018/01/10(水) 22:06:14.43ID:gCKQuqGL0
フレーム補間の60fps化だろ
実はわざわざエンコ時じゃなくて再生時にできるって知ったら発狂しそう
2018/01/10(水) 22:15:29.99ID:U2nTnab9d
エンコ時にフレーム補間出来るツールがあるのか？
2018/01/10(水) 22:19:27.15ID:7eoFLGYg0
>>733
A's Video Encoder なら Fluid Motion でフレーム補完したエンコがでける。
2018/01/10(水) 23:03:33.31ID:kE+0C3NMM
インタレ解除だって再生時に出来るしな
2018/01/11(木) 03:55:38.37ID:1cbDHyJ90
俺のブラビアで再生すれば240fpsで超ヌルヌルだぜ
2018/01/11(木) 07:50:46.84ID:cPxsWcsS0
毎回、再生環境を選ぶようなエンコとかめんどくさ。
2018/01/11(木) 11:27:28.15ID:xHT3Dywqx
男は黙ってBDMV準拠
2018/01/12(金) 18:26:26.13ID:zF3Z/D7L0
エンコ日が動画埋め込まれるのを消したり変更したりはできないの？
2018/01/12(金) 18:27:02.12ID:zF3Z/D7L0
すまぬ、訂正

エンコ日が動画に埋め込まれるのを消したり変更したりはできないの？
2018/01/12(金) 18:39:36.95ID:ecpKvVhK0
>>740
>>629-633
742名無しさん＠編集中 (ﾜｯﾁｮｲ 6ad2-JQPx)
垢版 |
2018/01/12(金) 18:40:29.51ID:64eEZn7/0
>>739-740
>>629あたりからの流れを見てね
2018/01/12(金) 19:26:29.27ID:zF3Z/D7L0
>>741-742
ありがとう
参考にしたいと思います

ちと使ったことのないソフトを使うようで俺には難しいかな
2018/01/14(日) 20:53:17.63ID:VO/9yTd80
>>731
すまんね
ドヤ顔でキリッの相手は、幼稚園の先生かママにお願いしてください
2018/01/15(月) 12:25:23.13ID:aaz1ubzE0
エンコ日やmux日を偽装や隠蔽して一体なにがしたいのやら。
2018/01/15(月) 16:22:32.60ID:7iqz1FsLM
違法アップロードのエンコでこんなに低いcrfなのに低ビットレートってスゲー、って思われたいんだろ
2018/01/15(月) 16:24:08.26ID:wQe3Tfq50
それにエンコ日やmux日が関係あるの？
2018/01/15(月) 17:40:39.06ID:aaz1ubzE0
旧作アニメのエンコをして、当時の放送日時に合わせて日付を設定しちゃおう！っていうのなら
まぁわからなくもないが、それはさすがに深読みし過ぎかw
2018/01/15(月) 18:18:31.54ID:AsEH1LJl0
検察が証拠ファイルを書き換えて事件のあった日に
2018/01/15(月) 19:06:47.18ID:1aBtJVCr0
エンコ日時フィールドにエンコ日時以外を入れたいとは思わないな
さっきエンコしたものを放送当時にエンコしたかのように装うなんて気持ち悪いわ
起源捏造民族じゃあるまいし
2018/01/15(月) 19:19:05.16ID:aaz1ubzE0
俺のエンコは、mkvでmuxするときにTSから拝借したEIT情報を埋め込むぐらいだな。
キャストとか諸情報とか放送当時のデータをそのまま残せてコレクション冥利に尽きるという感じ。
2018/01/15(月) 20:22:15.47ID:lxTvgHNw0
エンコ日を偽装したいとは思わんが、
隠蔽したいと思うことはあるかな。

unixタイム0（1970/01/01,00:00:00）にすることになるだろうけど。
2018/01/16(火) 01:36:32.03ID:6W/mSrv50
https://i.imgur.com/eQTcsUg.png

グループポリシーで自動更新関連を全て無効、サービスでも自動更新関連を無効にしているにもかかわらず
動画エンコード開始して寝て起きたら、なんと1時間ごとに再起動されていた
当然ファイルは破損していた

もうやだこのゴミOS

Windows10　16299.192
2018/01/16(火) 10:06:44.86ID:H8ZVNNZc0
気がついたら同じような動画を何回も拾ってる
そんなとき、拾い重複エロ動画整理のために、エンコ日やmux日はよく使うな

ファイルが壊れてるときなんか、remux時にエンコ日はそのままにしたいと思うけど
そこまでやるのはめんどくさい
2018/01/16(火) 11:02:02.43ID:Q83gu4jz0
>>753
WindowsUpdateサービスを無効にすれば解決するぞ。ただし、長期間そのままにしてあると
定期的なライセンス認証の確認作業に不具合が生じてバルーンヘルプが出始めるかもしれないが
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
寝ている時間をアクティブ時間にすればいいのでは？
１度も勝手に再起動された事はないな。
2018/02/03(土) 22:27:02.72ID:iiAEegYF0
>>753
RS2までロールバックしてみたら？
Win10は一度ロールバックするかクローンHDDから復旧させてCBBのWU確認期限を１年間にしておけば
重要なアップデートが見つかっても検知されないまま放置される。
2018/02/23(金) 17:46:51.10ID:bNdCDf+U0
x264guiExで実写を品質基準VBR (crf)でエンコしてるのですが
この品質基準とは何を基準にしているとかあるのでしょうか？

エンコ結果をSIMM0.985に付近にしたいと思い
複数ソースを同じcrfでエンコしているのですが
SIMMの結果がまちまちで疑問に思った次第です。

また希望するSSIMになるような指標などあるのでしょうか？
2018/02/23(金) 18:17:05.20ID:pufaCppw0
ソースによって変わるからソースにあわせてcrf値を調整するしかない。
2018/02/23(金) 21:59:48.11ID:+xd/hbhx0
>>759
-tune ssim
2018/02/24(土) 00:27:53.06ID:IJ/q997/0
内容的に --tune ssim は関係ないやろ。
2018/02/24(土) 07:11:27.09ID:YQ1clbGi0
>>760
やっぱそういう感じなんですね。
ありがとうございます。
2018/02/24(土) 07:16:05.16ID:EpoY8uasr
ちなみに、その0.985っていう値はどこから出てきたの？
2018/02/24(土) 13:50:41.80ID:uGOS9fa+0
x264はデフォで表示されなかったっけ？
2018/02/24(土) 18:26:20.89ID:9nHgYv4k0
SSIMの表示には --ssim が必要だけど、>>764が言いたいのは値の取得方法ではなく

　・SSIM=0.985を基準にしてるのはなぜ？（なんでその数値を選んだの？）

　・そもそもSSIMを基準にしたエンコードをしたいという理由は何？
　　（ただのテストならいいけど、実用なら主観での品質を大事にしたほうがいいよ？）

とかそういうことじゃないだろうか。
2018/02/24(土) 22:21:49.99ID:EpoY8uasr
そういうこと
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
2018/02/26(月) 14:19:18.80ID:LKAw40ZUM
psy入れてたらSSIMも糞もないだろうな
lameで言う心理音響みたいなもんだから機械的指標だとうんこになる
2018/03/08(木) 17:21:34.62ID:ncjlH8cj0
地デジ、実写、爆発シーンがあるアクション映画がソースで
爆発シーンはすでにノイズが出ているような場合
qcompをデフォの0.6から0.7に上げても
ノイズを一生懸命再現しようとビットレートを割り振ってしまって
上げる意味はないのかね？
2018/03/10(土) 20:59:39.09ID:5Kkuf6wr0
crfで綺麗にエンコできる設定だからって
2passでビットレートを制限した場合でも
綺麗になるかってと、そうでもないんだな。
2018/03/10(土) 23:18:51.35ID:IzcCyuvd0
crfこそがきれいにエンコオードできる設定だからね
2018/03/11(日) 00:57:08.76ID:5VWGzzVFx
>>770
上限ビットレートを12Mbpsぐらいにしとけばいいんじゃね？
2018/03/11(日) 09:59:37.31ID:jHzQQm8J0
上限じゃなく平均レートに6~10Mbpsを指定する必要がある
2018/03/11(日) 11:55:25.12ID:wjpTvoIe0
いや無駄な再現なら上限を設ければってことだろJK
2018/03/11(日) 12:37:47.82ID:vOQxZ3fe0
ノイズかどうかって人間の目ならだいたいわかるんだから
いずれAIが進化したら再エンコ専用のエンコーダで
ノイズ部分無視とか補完とかやってくれるようにならんかな
2018/03/11(日) 12:44:41.34ID:H0CinTr9a
googleがビッグデータを使ってディテールを予測して補完するエンコーダーの研究してるよな
2018/03/11(日) 13:43:34.74ID:jHzQQm8J0
>>775
めんご
>771からの話かと思った
2018/03/11(日) 14:28:13.12ID:SslWpV+I0
771からの話だとして、なぜ平均レート6～10Mbpsと言い出したのかよくわからんのだが・・・
2018/03/11(日) 19:05:37.90ID:jHzQQm8J0
crfやめて2passで高画質を狙うなら
高い平均ビットレートを指定する必要があるってこと
2018/03/12(月) 01:58:27.24ID:dFyvws7u0
crfとか2passとか設定出さずに爆破シーンのエンコとか
言って混乱させてしまってすまん。
爆破シーンのは2passでエンコしました。

また疑問でvbv-maxrateでビットレートを指定すると、
指定した値を極端には超えないファイルが出来上がるて
認識なんだけど合ってるよね。

あとｘ264出力(GUI)Exでエンコしてんだけどマルチパスとか
サイズ確認付き品質基準の「上限ファイルビットレート」項目の
設定もビットレートのピークを制限するものだよね？

初心者とかguiスレがなくてココにこんなこと書き込んですまん。
2018/03/12(月) 02:24:58.51ID:8qoNk2AH0
>>781
> あとｘ264出力(GUI)Exでエンコしてんだけどマルチパスとか
> サイズ確認付き品質基準の「上限ファイルビットレート」項目の
> 設定もビットレートのピークを制限するものだよね？

全然違う。
あれはできあがったファイルサイズ(ビット単位)を秒数で割った数値がそれ以下になるようにするというもの。
昔のニコ動のエコノミー回避や一般会員のビットレート制限のために作られた。
ニコ動の仕様が変わったので、もう使われることはないだろう・・・多分。
2018/03/12(月) 02:57:46.67ID:M0RpU/HJ0
意味もわからず2pass使うバカが多いよな
2018/03/12(月) 03:41:09.56ID:dFyvws7u0
>>782
ありがとう。
品質基準の「上限ファイルビットレート」は
目的が全く違うんだね。

>>783
いるよなｗ
CCEの影響か
2018/03/12(月) 06:06:48.95ID:ijK6n5Xa0
マルチパスは画質を捨てて、エンコ後のデータ量を揃えたい人限定じゃね？
2018/03/12(月) 15:20:07.23ID:1e6aJ3tW0
crf使ってるのに何度もエンコしてファイルサイズ揃えようとする馬鹿も笑えるよな
2018/03/12(月) 15:45:56.62ID:4KK2qyCVM
psy入れてるのに毎回ログでSSIM解析値残してる俺
無駄だとわかってるけど何となくね
2018/03/13(火) 07:25:55.28ID:pSIurGuv0
>>786
VBVでビットレ制限すればcrfでもデータ量を揃えることは可能だが
アニメ以外だと高いSSIM値になっていても糞画質な映像に仕上がってることが多い。
2018/03/13(火) 22:09:04.65ID:NrXyemjW0
それはcrfというよりcbrになってるだろ
2018/03/17(土) 20:33:57.41ID:41kAdC9fx
ロスレスは劣化が無いと信じて使ってたけど
なんか線が細ってるなーと思って減算して元画像と重ねたら
見事に淵のピクセルが飛んでた
このスレ読んでやっと真実が分かった
2018/03/17(土) 20:43:54.27ID:UvukF0qw0
RGBソースをYUV4:2:0の可逆で保存してたってことかな。
そのあたりをちゃんと理解してない初心者は結構いると思う。
2018/03/18(日) 18:52:37.64ID:lqrsXf4E0
フチっつーからエンコーダがサイズ間違えたとか？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。