17/04/06 00:43:55.02 bAvUs9zs0.net
>>583
>>585
ありがとう！参考になります。
601:名無しさん＠編集中 (ﾜｯﾁｮｲ 21e1-8Vmj)
17/04/10 23:25:17.97 UU+GTowc0.net
aq-mode 3 いいな
aq-strength 0.6ぐらいならそう太らずに
--aq-mode 1 --aq-strength 0.8 （や0.6）より画質が向上した
602:名無しさん＠編集中 (ﾜｯﾁｮｲ 21c8-D6lx)
17/04/11 02:34:46.50 VAqkqS/00.net
aq-motionてのがいつの間にか追加されてたけど
コレどういう振る舞いするんだ？
ドキュメント見てもよく分からんし
603:名無しさん＠編集中 (ﾜｯﾁｮｲ a220-dxaC)
17/04/11 09:24:13.83 WD1vb8Mu0.net
フレームの中で突出して動きが大きいブロックがあればそれのQPをちょっと上げる感じかと
604:名無しさん＠編集中 (ﾜｯﾁｮｲ 1195-8Vmj)
17/04/11 09:52:44.00 7fgBiZzO0.net
QPを下げるんじゃなくて上げるんだ
ノイズ出そうだね
605:名無しさん＠編集中 (ﾜｯﾁｮｲWW 9db7-6Mp1)
17/04/11 11:49:07.13 FRRNE1SC0.net
昔は色々設定してたけど、もはや面倒になってmediumのq18しかしてねーわ
606:名無しさん＠編集中 (ﾜｯﾁｮｲ 21e1-3+1Y)
17/04/12 18:02:57.47 g7lIHR9p0.net
>>590
ノイズは出ないけど上がった瞬間との落差が気になった
--aq-motion-strengthみたいなオプションが欲しいところ
607:名無しさん＠編集中 (ﾜｯﾁｮｲ c7c8-HE/W)
17/04/14 15:21:40.47 FgfIhRSK0.net
>>589
なんかqcompと役割の違いがよく分からんね、aq-motion
608:名無しさん＠編集中 (ﾜｯﾁｮｲ 4795-V7Gz)
17/04/14 18:04:44.47 rcI+IZyA0.net
qcompはmbtreeの強弱じゃなかった？
609:名無しさん＠編集中 (ﾜｯﾁｮｲ c7e1-RZRQ)
17/04/14 18:14:58.82 F04ClANU0.net
mbtreeだけじゃないよ
qcomp 1.0で完全な品質基準って話はずっと昔からあるし
610:名無しさん＠編集中 (ﾜｯﾁｮｲ 5f20-0/8P)
17/04/15 19:49:08.45 hJ8A7N5/0.net
aq-motionはcutreeの粗悪な代用品としての利用価値ぐらいしかなさそう
cutreeを使ってるならaq-motionを使う理由なんて無いけど何らかの理由でcutreeを使えない場合にはaq-motionが活躍する場面があるかも
611:名無しさん＠編集中 (ﾜｯﾁｮｲ c7e1-RZRQ)
17/04/15 21:19:48.38 eAFMSi9o0.net
というかあまり動いていない箇所のクォリティ上昇はなかなかな感じだったよ
612:名無しさん＠編集中 (ﾜｯﾁｮｲ 4795-V7Gz)
17/04/15 23:42:03.20 AUhsEFPX0.net
動きの少ないソースには有効っていうことかー
613:名無しさん＠編集中 (ﾜｯﾁｮｲ c7c8-HE/W)
17/04/16 00:02:39.79 rhdCa1wT0.net
動く箇所で下げた分のクオリティを割り振ってるんかな？
614:名無しさん＠編集中 (ﾜｯﾁｮｲ c7e1-RZRQ)
17/04/16 13:34:25.98 2p7kZr4R0.net
サイズが23MB → 20MBに減ってたから
文字通り動きの量によって緩急つける感じかと
615:名無しさん＠編集中 (ｽｯﾌﾟ Sdff-S5B2)
17/04/16 16:43:26.25 uqp9e6Tod.net
動きの激しい部分の品質は下げるけど、それ以外の部分の品質はaq-motion自体では弄らない
616:名無しさん＠編集中 (ﾜｯﾁｮｲ c7e1-RZRQ)
17/04/16 23:43:45.89 2p7kZr4R0.net
そう？
自分がテストしたときは視覚的には変わってたよ
多少は動いてたが・・
（ということはゆっくり動く箇所は割り当て増やすとか？・・当てずっぽうの素人考察だけど）
617:名無しさん＠編集中 (ﾜｯﾁｮｲ 4795-V7Gz)
17/04/17 02:17:10.63 81QYYL4M0.net
meの範囲内のフレーム内で「動きが大きい」と機械的に判断されたブロックのQPを上げるっていう感じなのかな
まぁデフォルトでは無効だしいい塩梅になるまでは使わなくていいか
URLﾘﾝｸ(x265.readthedocs.io)
Adjust the AQ offsets based on the relative motion of each block with respect to the motion of the frame.
The more the relative motion of the block, the more quantization is used.
Default disabled. Experimental Feature
以下Google翻訳
フレームの動きに対する各ブロックの相対的な動きに基づいてAQオフセットを調整します。 ブロックの相対的な動きが多いほど、より多くの量子化が使用されます。
デフォルトは無効です。 実験的な特徴
618:名無しさん＠編集中 (ﾜｯﾁｮｲ 6ae6-+vjJ)
17/04/20 22:53:52.71 tdIypNJ90.net
x265自体はタイムコード適用できないけどソースのfpsでエンコード結果が変わるんだよ。
タイムコード自体はエンコード後timelineeditorで適用するとして、x265エンコード時どうしてる？
例えば、60fpsと24fps混合ソースなら主となるfpsに仮でそろえてエンコードするしかないのかな。
619:名無しさん＠編集中 (ﾜｯﾁｮｲ 5de1-m8Mb)
17/04/21 10:58:34.98 r2pPSZfN0.net
> ソースのfpsでエンコード結果が変わる
x265もそうなの？
620:名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM2e-TzKg)
17/04/21 11:08:00.26 Q4ypiX6hM.net
UHDブルーレイに無劣化でオーサリング出来るための、詳細なパラメーターの制限って明らかになってる？
例えばbフレームは何枚までとか、解像度やフレームレートの制限とか
H.265が使えるから従来の地デジやBSCS収録でもH.264より高画質にできるだろうなぁ
しかも将来的にブルレイプレイヤーで再生できる汎用性の高い動画ファイルになりうる
621:名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM2e-TzKg)
17/04/21 11:27:28.42 Q4ypiX6hM.net
調べてここまで出てきたんだが、これだけじゃ足りない
1440x1080が本当に不可なのか、プロファイルはいくつにすればいいのか、最大GOPはいくつなのか、そういう最低限規格を満たすために必要な情報どこかにない？
◆Ultra HD Blu-ray◆
容量 ： 50GB（2層） 66GB（2層） 100GB（3層）
解像度 ： 4K/UHD(3840x2160) 2K/HD(1920x1080)
最大転送ﾚｰﾄ ： 82Mbps（50Gdisc） 108Mbps-128Mbps（66G&100Gdisc）
映像圧縮 ： HEVC(H.265) *最大ﾋﾞﾃﾞｵﾋﾞｯﾄﾚｰﾄは100Mbps程度
ﾌﾚｰﾑﾚｰﾄ 23.976p 24p 25p 50p 59.94p 60p *48pと120pは非対応
色深度 ： 10bit
色解像度 ： 4:2:0
色空間 ： BT.2020 BT.709(SDR)
輝度ﾚﾝｼﾞ ： HDR SDR *HDRの最大輝度は10000nit程度
3D映像 ： 非対応
音声 ： LPCM Atmos TrueHD D-Digital DTS:X HDMA HDHR DTS.. *BDと同
622:名無しさん＠編集中(ﾜｯﾁｮｲ a6d4-9aAf)
17/04/21 18:04:57.96 EQabZArh0.net
>>605
cutreeがそうじゃないか
623:名無しさん＠編集中
17/04/23 11:56:12.95 ezEyDZxY0.net
>> x265 version 2.4 has been released. This release incorporates support for the new HDR10+ standard, and revised lambda tables for main, main10, and main12 profiles that significantly improve visual quality!
624:名無しさん＠編集中
17/04/23 13:41:24.97 lkpqHD2u0.net
>>607
規格書に載ってる
URLﾘﾝｸ(www.blu-raydisc.com)
625:名無しさん＠編集中
17/04/23 15:09:39.40 x1VIpcDT0.net
>>608
CUTreeは関係なくね？ってか効率の話だったり？
自分はx264のようなフレームレートによる品質基準の基準が変わるやつのことかとおっえレスした
626:名無しさん＠編集中
17/04/24 18:58:09.29 mnPn8ws50.net
>>609
lambdaテーブルの影響を知りたくてv2.4をmain10でちょっとテストしてみたけど、
v2.3と比べて
・同等のサイズで仕上げるにはcrfを+0.7する必要があった
・ほんの僅かだけどシャープさが劣る。画質が良くなったという印象は特にない
・エンコスピードは誤差レベルで後退
って感じだった
素材やオプションが違えば結果も違ってくるかもしれないので参考までに
627:名無しさん＠編集中
17/04/24 20:15:58.25 uRf5u1Ba0.net
>>611
何えづいとんねん
628:名無しさん＠編集中
17/04/24 23:28:40.49 xtaDIZz60.net
なに言うとんねん、と思ったらえづいとったは
「思って」の打ち間違いね
>>612
良くなる分にはいいやって放置してたけど
意外と大きな数字(0.7)相当なのね
629:名無しさん＠編集中
17/04/25 20:44:41.71 DQ89QlU40.net
crowd_run_1080p50.y4m(1920x1080,50fps,500frames)
URLﾘﾝｸ(media.xiph.org)
--preset medium --crf 20
2.3+6
encoded 500 frames in 68.46s (7.30 fps), 30985.48 kb/s, Avg QP:29.64
SSIM Y:0.935221 (11.885634) U:0.904760 (10.211822) V:0.912758 (10.592727) All:0.926400 (11.331230)
2.4+2
encoded 500 frames in 66.10s (7.56 fps), 32299.09 kb/s, Avg QP:29.64
SSIM Y:0.936270 (11.956582) U:0.907440 (10.335748) V:0.915005 (10.706081) All:0.927921 (11.421915)
--preset slower --crf 20
2.3+6
encoded 500 frames in 712.86s (0.70 fps), 30333.66 kb/s, Avg QP:29.96
SSIM Y:0.939937 (12.213930) U:0.905197 (10.231793) V:0.913237 (10.616633) All:0.929697 (11.530262)
2.4+2
encoded 500 frames in 721.24s (0.69 fps), 34428.35 kb/s, Avg QP:29.83
SSIM Y:0.943036 (12.444004) U:0.912494 (10.579609) V:0.919911 (10.964289) All:0.934092 (11.810594)
630:名無しさん＠編集中
17/04/25 20:53:10.15 DQ89QlU40.net
sakura_op.mpg(1280x720,30fps,3501frames)
URLﾘﾝｸ(www.makura-soft.com)
--preset medium --crf 20
2.3+6
encoded 3501 frames in 126.10s (27.76 fps), 1782.43 kb/s, Avg QP:23.87
SSIM Y:0.990159 (20.069493) U:0.991007 (20.460985) V:0.989847 (19.934137) All:0.990248 (20.109166)
2.4+2
encoded 3501 frames in 129.07s (27.13 fps), 1912.48 kb/s, Avg QP:23.77
SSIM Y:0.990531 (20.237025) U:0.991356 (20.632727) V:0.990239 (20.105259) All:0.990620 (20.277969)
--preset slower --crf 20
2.3+6
encoded 3501 frames in 1023.84s (3.42 fps), 1725.53 kb/s, Avg QP:24.17
SSIM Y:0.991222 (20.565903) U:0.991414 (20.661999) V:0.990188 (20.082495) All:0.991082 (20.497082)
2.4+2
encoded 3501 frames in 1025.45s (3.41 fps), 1973.57 kb/s, Avg QP:24.03
SSIM Y:0.991787 (20.855093) U:0.992109 (21.028787) V:0.991031 (20.472708) All:0.991715 (20.817032)
概ね>>612の通り
631:名無しさん＠編集中
17/04/25 21:08:52.05 LhEHw4Hr0.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
faster
2.3 encoded 313 frames in 13.13s (23.85 fps), 775.53 kb/s, Avg QP:32.80, SSIM Mean Y: 0.9367258 (11.988 dB)
2.4 encoded 313 frames in 13.30s (23.52 fps), 772.42 kb/s, Avg QP:33.36, SSIM Mean Y: 0.9375284 (12.043 dB)
fast
2.3 encoded 313 frames in 24.77s (12.63 fps), 772.97 kb/s, Avg QP:33.36, SSIM Mean Y: 0.9418876 (12.357 dB)
2.4 encoded 313 frames in 24.74s (12.65 fps), 774.19 kb/s, Avg QP:33.90, SSIM Mean Y: 0.9419057 (12.359 dB)
medium
2.3 encoded 313 frames in 28.04s (11.16 fps), 777.35 kb/s, Avg QP:33.27, SSIM Mean Y: 0.9443598 (12.546 dB)
2.4 encoded 313 frames in 28.14s (11.12 fps), 776.67 kb/s, Avg QP:33.97, SSIM Mean Y: 0.9443138 (12.543 dB)
632:名無しさん＠編集中
17/04/25 21:10:09.27 LhEHw4Hr0.net
slow
2.3 encoded 313 frames in 64.79s (4.83 fps), 778.09 kb/s, Avg QP:32.65, SSIM Mean Y: 0.9469703 (12.755 dB)
2.4 encoded 313 frames in 64.01s (4.89 fps), 780.38 kb/s, Avg QP:33.59, SSIM Mean Y: 0.9468699 (12.747 dB)
slower
2.3 encoded 313 frames in 152.43s (2.05 fps), 775.05 kb/s, Avg QP:33.70, SSIM Mean Y: 0.9466241 (12.727 dB)
2.4 encoded 313 frames in 145.62s (2.15 fps), 774.25 kb/s, Avg QP:34.60, SSIM Mean Y: 0.9465784 (12.723 dB)
x264 core:148 r2748 97eaef2
veryslow
encoded 313 frames, 14.30 fps, 805.58 kb/s, SSIM Mean Y:0.9355751 (11.909db)
URLﾘﾝｸ(www.dotup.org)
633:名無しさん＠編集中
17/04/25 21:46:27.49 jTXqj/9G0.net
>610
それをx265のオプションに落としこんでくださいよ。
634:名無しさん＠編集中
17/04/25 22:19:07.45 hUQMLn860.net
昨日、今日と公式doc覗いてるけど、色々なオプションが追加されてるのね
エンコーダーのオプション見るの久しぶりでなんか楽しい
635:名無しさん＠編集中
17/04/26 02:49:05.93 DMcYoB+GM.net
今のx264+Ryzenのように、1920x1080でオプション積みまくっても実時間の倍程度でエンコード出来るようになるには、後何年掛かるかな？
636:名無しさん＠編集中
17/04/26 14:36:48.76 t8ghLcit0.net
レート節約効果が1%もないのにやたら重いようなオプションはどんどん外していくべきなんだよ
637:名無しさん＠編集中
17/04/26 14:52:37.81 t8ghLcit0.net
>>618
新lambdaテーブルは主観的品質の向上がいまいちだったからSSIMが良くなる方向に振ったチューニングなのかなって思ったけど
この結果を見るとそうでもないみたいだね
638:名無しさん＠編集中
17/04/26 20:44:04.74 ZA2kqK9D0.net
言葉では難しいところだけど
疑色というか画質の不安定さがなくなったような感じた
aqもpsy-rd系も新lamba2テーブルを前提に再調整が必要みたいだし
前ver.で十分画質を追い込んだ人にはしばし冬の時代かもね
639:名無しさん＠編集中
17/04/27 09:44:39.46 FDbzMsjYM.net
>>619
IPBごとのスライス数指定とかあるから現行のx265じゃ無理
640:名無しさん＠編集中
17/04/27 22:50:22.40 hRc2Bh+T0.net
slowerからveryslowに変えて試したらかなり遅くなるのに999MBが994MBになっただけだた
もちろんソースにもよるんだろうけどもうveryslowは使わない・・・
641:名無しさん＠編集中
17/04/28 05:25:15.61 ctPW4boSM.net
x264でもそれぐらいの違いしかなかった記憶が
642:名無しさん＠編集中
17/04/28 05:37:44.43 0ZzdB8tta.net
「非現実的なスピード」だっけ
643:名無しさん＠編集中
17/04/28 13:33:56.59 0iC5Qfnw0.net
x265のデフォルトと重いオプション積みまくってx265デフォルトと同じエンコード速度になったx264だとどっちが縮むかな
x265はまだ発展途上だから似たようなレートになる予感
644:名無しさん＠編集中
17/04/28 19:49:42.31 e2srgm7N0.net
人の顔が数人写るカットで偽色？っていうの
なんか目立つ
x264はすっきりしてるのに
645:名無しさん＠編集中
17/04/28 21:20:12.91 eUzMgdEP0.net
>>629
x265のデフォルト(medium)って大して重くないと思うんだが・・・。x264のslowerより速い。
参考：
x264 r2744とx265 v2.4+2のエンコード速度とSSIM/bitrate （crowd_run_1080p50.y4m）
URLﾘﾝｸ(2sen.dip.jp)
646:名無しさん＠編集中
17/04/28 22:03:10.16 6yBAbqmW0.net
x265のslowとslowerだけに注目したらSSIM/bitrateで差は無いってこと…？
647:名無しさん＠編集中
17/04/28 23:26:59.96 eUzMgdEP0.net
>>632
一応>>631のグラフにx265 veryslowも追加してみたけど、
SSIM/bitrateグラフでのラインとしてはslow,slowerと大して変わりない感じだね。
URLﾘﾝｸ(2sen.dip.jp)
648:名無しさん＠編集中
17/04/29 06:46:40.71 mJB4Zjya0.net
まだx265は未完成なんだろうなぁ
追加オプションがちゃんと機能してないからほとんど変わってないと思われる
649:名無しさん＠編集中
17/04/29 13:01:31.31 5p3huezy0NIKU.net
12月末にビルドしたバイナリより画質悪くなってるなぁ・・・
650:名無しさん＠編集中
17/04/29 13:06:21.29 dxaAtgLy0NIKU.net
x264より画質上げるのは至難の業だろうね
mpeg4系は圧縮のアラを隠ぺいする方向に進化してるから
シンプルな旧世代コーデックで高画質にできてるならそれ以上は無理
651:名無しさん＠編集中
17/04/29 13:37:34.15 CfE7T/6AMNIKU.net
>>663
同等エンコ速度でx264に比べて10%しか画質向上してないのかよ
veryslow同士でも20%しか向上してない
なにが半分のレートで済むだよ騙されるところだった
今後はx264に戻るわ
652:名無しさん＠編集中
17/04/29 13:50:19.89 waHaI7dF0NIKU.net
速度を求めるならそりゃx264のほうが良いだろうね現状は
そもそもH265は「同じ速度で半分のレートで済む」のではなくて「半分のレートで同等の品質を実現する」ってのが謳い文句なわけで
653:名無しさん＠編集中
17/04/29 14:28:56.05 CfE7T/6AMNIKU.net
その「半分のレートで同等の品質」すらx265は実現できてないじゃん
レート削減効果50%程度になりUHDブルーレイ規格に準拠できるようにオプション追加されたら起こしてくれ
それまでは汎用性重視でx264使う
654:名無しさん＠編集中
17/04/29 14:43:09.49 dxaAtgLy0NIKU.net
「すら」の使い方間違ってるで
655:名無しさん＠編集中
17/04/29 15:23:47.60 7YaV6zKaaNIKU.net
ちなみにX264とX265使って実際にビットレート半分で大差無いか実験した人いるの？
656:名無しさん＠編集中
17/04/29 16:18:28.03 waHaI7dF0NIKU.net
>>641
URLﾘﾝｸ(gigazine.net)
結局のところ見る人や再生する環境にもよる
現状半分まで行かなくてもH.264の6割から7割くらいのデータ量でほぼ同じ品質にはなるんじゃないかな
それも見る人、再生する環境、どういうソースをどういうオプションでエンコしたかとかによる
657:名無しさん＠編集中
17/04/29 23:30:39.55 dvKINc090NIKU.net
>>641
目視では無いけどSSIMとかPSNRでの比較なら過去スレで行われたな
658:名無しさん＠編集中
17/04/29 23:34:25.30 dxaAtgLy0NIKU.net
>>641
アニメなら結構頑張れる
その画質で満足できるかは別問題だけど
659:名無しさん＠編集中
17/04/30 07:48:13.80 48guLabb0.net
アニオタは実写に比べて圧倒的に色数やグラデーション低いのに、無駄に画質にこだわるわな
660:名無しさん＠編集中
17/04/30 08:13:50.20 Ii4RBPus0.net
画面が単純なほど粗が目立ちやすくなるからでしょ
661:名無しさん＠編集中
17/04/30 11:57:03.61 jEPKJ4r80.net
12bitのほうがサイズが小さくなったり、謎が多い
662:名無しさん＠編集中
17/04/30 12:04:52.53 usOzIqXsa.net
今ちょっとx264とx265を使って色々試してみたけど半分のビットレートで同等の画質はやっぱ今のところ無理っぽいね
業務用の高価なハードウェアエンコーダーとかなら出来るんだろうけど
663:名無しさん＠編集中
17/04/30 12:37:20.05 S8IaheQZ0.net
h264に対するh.265のアドバンテージが最も発揮されやすいのは、映像が圧縮向きの内容で、なおかつ比較するレートが低い場合だよ
例えば>>633とかは使ってるテスト素材が圧縮に不向きなこれだし高めのレートでの比較だからアドバンテージが表れにくい
URLﾘﾝｸ(i.ytimg.com)
664:名無しさん＠編集中
17/04/30 12:37:41.41 jEPKJ4r80.net
クリアな画質の実写がすごく得意。だから洋画には向いてると思う
665:名無しさん＠編集中
17/04/30 12:53:49.87 usOzIqXsa.net
>>649
うーん
そういう圧縮に向いてない絵柄をもっと小さく出来てこそアドバンテージになると思うんだけど違うのかな
666:名無しさん＠編集中
17/04/30 13:16:36.03 xXAmTovGa.net
不向きな素材でもx264より縮むんだからアドバンテージになるでしょ
667:名無しさん＠編集中
17/04/30 13:19:01.07 S8IaheQZ0.net
大雑把に言うとコーデックの性能差は映像の中の圧縮可能な特徴・成分をいかに取りこぼさず効率的に圧縮できるかで決まるものだから
そもそも圧縮可能じゃない特徴で満ちてる映像だとどんなコーデックでも大差ない仕事しかできなくなるんだよ
668:名無しさん＠編集中
17/04/30 13:19:28.26 usOzIqXsa.net
でも>>649によるとアドバンテージが表れにくいって話だよ
669:名無しさん＠編集中
17/04/30 13:21:33.50 usOzIqXsa.net
>>653
なるほどねえ
尺を通じてトータルで見ればデータはかなり圧縮される筈で
圧縮しにくいカットだけ抜き出して比較しても無意味って事か
670:名無しさん＠編集中
17/04/30 13:57:24.01 48guLabb0.net
民生用でマトモなH.265エンコーダーはこれしかないんだから、今後の改良に期待するしかない
MPEGが264ほど細かい仕様を公表してないっぽいから厳しいだろうけど
671:名無しさん＠編集中
17/04/30 14:04:48.94 bED0LQ1n0.net
実写ってさ、X264の場合粒子系の画質だと圧縮されにくいし
明るい日本のバラエティ系、ドキメンタリー系も圧縮されにくい
それはｘ265でも変わらないって事か
やっぱりさ、圧縮がいくら効率よくてもさ粒子質の画質にビットレートを抑えると
暗部はブロックノイズになるのも抑えられないって事になるのかな
単純な画像がより圧縮されるだけってことになる？
672:名無しさん＠編集中
17/04/30 14:05:05.01 T3TX6aDP0.net
>>648
業務用の高価なHWでも同じだと思う
だいたいのビデオコーデックの「半分のレートで～」ってのは解像度が一回り大きくなってるのを前提にしてると思う
673:名無しさん＠編集中
17/05/01 01:53:41.72 yJgdhctZa.net
>>657
粒子を荒くした映像って時間軸上も平面上もランダムだから圧縮には最も不向きだよね
ブロックノイズにはならないようある程度考慮はしてあるみたいだけど
ビットレートが上がるか粒子を潰したのっぺりしたグラデーションになるかしか�
674:ｳいような気がする
675:名無しさん＠編集中
17/05/01 08:03:48.97 ZU6/Rrwu0.net
演出上の意図でグレインノイズを載せたやつって一番厄介だな
676:名無しさん＠編集中
17/05/01 09:44:16.92 rHzATc4T0.net
>>641
圧縮具合はものによるがx264で画質に不満が無くなるとされるcrf19以下の品質を
x265で半分のビットレートで表現出来るかというと無理な話
低解像度、低ビットレートの条件なら謳い文句通りになると思う
トラフィックの削減を目指している事もあり、h265はモバイル向けなんだよ
677:名無しさん＠編集中
17/05/03 19:29:12.62 aonBlG3Y0.net
今の地上デジタル放送のビットレート（約14Mbps）で4K放送実現できるってのがH.265の謳い文句じゃない？
678:名無しさん＠編集中
17/05/03 19:34:23.87 oVIawGqt0.net
そんなことどこで言ってるんだ？
679:名無しさん＠編集中
17/05/03 20:00:17.19 slM11u540.net
4k/8kをBDに、ってのが最大のうたい文句
680:名無しさん＠編集中
17/05/03 21:04:29.60 XcGDD2x1M.net
地デジのビットレートとBDのレートは数倍違うが
681:名無しさん＠編集中
17/05/04 09:30:04.71 r2WWJZtz0.net
4k8k放送は、HWエンコーダーが高性能になっても放送用の速度維持する為にかなり低負荷な仕様になると思うのだが
本来の性能発揮できるのかね。下手するとMPEG2よりひどくなりそうな予感しかしない
試験放送の画質ってどんな感じなんでしょう
682:名無しさん＠編集中
17/05/05 16:36:48.23 pA0AuifG00505.net
伸びてると思ったら
また、知ったかがイキってるのか
683:名無しさん＠編集中
17/05/05 16:52:03.26 7L1WkNvu00505.net
知ったかの誰もが黙る完璧なレスを期待してみよう。
684:名無しさん＠編集中
17/05/08 11:47:41.13 fN8ySGc20.net
>>631
いまさらだけどｔｈｘ
どんどん見やすくなってるね
685:名無しさん＠編集中
17/05/09 01:02:59.86 HpXVkdwd0.net
下記オプションで変えた方がいい点などはありますでしょうか？
ソースはアニメのTSです
--crf 23 --vbv-bufsize 12000 --vbv-maxrate 12000 --aq-mode 2 --psy-rd 1 --psy-rdoq 1 --keyint 0 --me umh --subme 7 --sar 1:1
686:名無しさん＠編集中
17/05/09 20:12:34.46 qOc4G1FT0.net
subme森杉？
5以上は非現実的かと・・
687:名無しさん＠編集中
17/05/09 23:45:01.17 4B6cqW170.net
新しいの、また速くなってる・・・
688:名無しさん＠編集中
17/05/09 23:58:57.05 aulyagCI0.net
アニメのTSをAvisynthで960x720にリサイズしてSAR 4:3でエンコしてる異端だけど速度稼げてなかなか良い。
689:名無しさん＠編集中
17/05/10 00:04:22.10 KruT9Evd0.net
AvisynthでCPUをほぼフルに酷使する方法が何となくわかったし、
24分アニメを15分でhevc-720pでエンコできるようになった
もっといいCPU欲しくなってきたな
690:名無しさん＠編集中
17/05/10 09:37:05.08 bEaPVUCw0.net
>>673
1344x896でやってる俺からしたら王道以外の何物でもないな
691:名無しさん＠編集中
17/05/11 00:51:47.54 bhjNCYSh0.net
俺の環境じゃRyzen買ったらエンコ時間半分になるらしいから悩むｗ
692:名無しさん＠編集中
17/05/11 05:22:50.94 G+ZVXWa50.net
俺環だけどi5-6500からRyzen1700にしたけどエンコ時間は
4時間半くらい→3時間半くらい
だったよ…。
693:名無しさん＠編集中
17/05/11 20:41:44.92 Ga7luA0AM.net
アニメは解像度落とさない派
694:名無しさん＠編集中
17/05/11 21:02:50.19 fuulcAsGF.net
実写も解像度落とさない派
695:670
17/05/11 21:27:46.96 zRKYhiEq0.net
>>671
ありがとうございます。
psy-rdを減らすか迷っているのですが、おすすめありますでしょうか？
696:名無しさん＠編集中
17/05/12 00:02:37.69 U8fvP1vm0.net
>>680
自分は0.5でやってる
アニメにグレンは無いしrdoqは無効にしてる（付加されてたら諦めてる
んでAQ-modeは3で強さは0.6がマイブーム
・・ってここまで書いたら私的すぎて役に立たんか
697:名無しさん＠編集中
17/05/12 00:10:07.87 lJM8G7xR0.net
人に見せるわけでもないし自分さえよければそれでいいｗ
でもそれを参考にして自分もパラメータ気に入れば楽しいよね。
698:名無しさん＠編集中
17/05/12 00:53:01.59 EXwmMiWF0.net
しかし、迷うと全てエンコし直したくなる諸刃の剣
699:名無しさん＠編集中
17/05/12 04:56:38.33 UJVJ7S250.net
>>681
俺もAQ-mode 3は使うな
x264の頃から使ってたし
目で見てはっきり違いがわかるものは使う
700:名無しさん＠編集中
17/05/12 10:40:58.85 gtnUa06O0.net
>>677だけどRyzen1700のメモリを2133から2400に変えてみたらCPU使用率が100%に近づいて
エンコ速度上がったわ。
ソース(アニメの話数)が違ってるのであくまで参考程度のデータ。
1.95fps (i5-6500)
2.49fps (Ryzen1700定格 メモリ2133)
3.31fps (Ryzen1700定格 メモリ2400)
安定性重視なんで自分はOCしないけど、CPUメモリOCしたらかなりのエンコ速度になりそうだ。
701:名無しさん＠編集中
17/05/12 16:37:30.30 tfdWSZ5/0.net
さがっとるやないかーい（何か書き間違えてるんだろうけど）
702:名無しさん＠編集中
17/05/12 16:48:26.63 t6nB1T3eM.net
いやそれは1 2 3という順所ではないと思うが
あまりにもきれいに並んでいるから見間違えるが
703:名無しさん＠編集中
17/05/12 16:52:11.49 tfdWSZ5/0.net
>>687
ボケてた俺の勘違いを即座に理解して指摘してくれてありがとう・・・本当にありがとう・・・腹筋してくるわ・・・
704:名無しさん＠編集中
17/05/12 16:55:03.94 O9wwnZLm0.net
>>687
おー、よくわかったね
705:名無しさん＠編集中
17/05/12 20:04:58.86 U8fvP1vm0.net
>>685
ああ・・やっぱり
薄々感じてはいたけどメモリ帯域も影響するのか
706:670
17/05/12 22:23:40.02 PqFGzIh20.net
>>681
>>684
ありがとうございます。大変参考になりました。
707:名無しさん＠編集中
17/05/14 02:33:51.07 2H6mt4/K0.net
アニメで--no-rdoq-levelってどうだろう？
708:名無しさん＠編集中
17/05/14 14:05:04.00 uUJ9cNnK0.net
そこまで無効にする必要はないんじゃないの
709:名無しさん＠編集中
17/05/15 14:53:47.21 2frEPm5C0.net
>>685
アニメで3.31fps なんて、
どんな重い処理かけてるんだよ・・・
プラシーボレベルだろ
710:名無しさん＠編集中
17/05/15 16:55:48.41 APxSp9En0.net
>>694
x265_2.3+40_x64で1920x1080をslowerだよ。
オプションは ―crf 21 ―qpfile hoge.txt ―output-depth 10 で、
avsでフィルタはロゴ消しとインタレ解除だけ。
711:名無しさん＠編集中
17/05/15 17:02:30.21 vDSpvxyLd.net
x265で10bitならそうなるわな
712:名無しさん＠編集中
17/05/15 18:22:53.70 bj8Ua5EV0.net
slowなら10fpsぐらい出るけどね
713:名無しさん＠編集中
17/05/16 01:08:17.27 suUZApBF0.net
今最新のコミット確認したら AVX2 を使ったアセンブラレベルのコードに置き換えられた部分があるぽい。
うちの FX-8350 は AVX2 が無いからなんか悔しい感じだ。早く Ryzen にしてーわｗ
714:名無しさん＠編集中
17/05/16 05:27:59.56 J1UBdiv20.net
>>698
最近、Avisynthとかでもマルチスレッド対応フィルタが多いからね
Ryzen8コアにするとx265含めて軽く倍以上のスピードになったりする
アニメだったら 720p/エンコ速度40fps ぐらい出るエンコしても
かなり高画質のまま
715:名無しさん＠編集中
17/05/16 15:46:32.65 Wy6G+qvk0.net
>>698
Ryzenの場合AVX2を切った方が微妙にエンコ速くなるってベンチスレで書かれてたような。
716:名無しさん＠編集中
17/05/16 16:02:47.40 CN3vjyuk0.net
元がCで、そこからAVX2化で7倍速と書かれてるから
普通に恩恵にあずかれると思う
rigayaさんのコメント欄によればfmaを使わなければ目立ったペナルティーはないらしい
717:名無しさん＠編集中
17/05/18 16:09:41.38 J//hbtSe0.net
Ryzenはたしかに速いけどFXと比べてそんなに体感できるほど速いものなんだろうか？
エンコだけならFXも十分速いよね？ 持ってないから知らんけど
718:名無しさん＠編集中
17/05/18 17:06:05.44 liTjT1V1d.net
なんでも声に出しちゃうアホっているよな
719:名無しさん＠編集中
17/05/18 21:23:46.03 OQSARe0P0.net
>>698 >>701
コミットの文章的に、--me seaで差が出るのかと思って、Haswell環境（AVX2あり）で
rigaya氏ビルドの2.4+2と2.4+22（ともにx64版）で --crf 20 --me seaで
crowd_runをエンコして速度を比較してみたけど、ほぼ差は出なかった。
部分的な変更なので全体のエンコ速度に差が出るほどじゃないのかな。
720:名無しさん＠編集中
17/05/19 00:06:29.20 XSq/RbM90.net
--me sea --no-deblock --no-sao
ぱっと見ただけだけどこれらが必要だと思うよ
721:名無しさん＠編集中
17/05/19 00:17:50.69 XSq/RbM90.net
--wpp も必要だけどこれはデフォルトで使ってるから指定しなくてもいいかな
>>705の３つを明示すればたぶん>>698の効果が出ると思う
あとは、すべてのフレームで高速化するわけではなく被参照フレームに限られるぐらいかな
722:名無しさん＠編集中
17/05/19 15:23:05.73 MmsXEbU70.net
なんだそういう条件が必要だったのね
どうりで速度がほとんど変わらなかったはずだ
723:名無しさん＠編集中
17/05/19 16:05:15.27 BfUmY3M/0.net
>>705-706
>>704＋その条件で試したけど、やっぱり差は出なかった。
724:名無しさん＠編集中
17/05/19 17:32:15.16 ji/YSPqA0.net
ごめん、めっちゃねぼけてた
--me sea --no-wpp だ
--no-deblock --no-sao は必要なかった
725:名無しさん＠編集中
17/05/19 18:23:01.72 MmsXEbU70.net
wpp使えないって
よっぽどの画質狂ででもないと恩恵得られなさそう
726:名無しさん＠編集中
17/05/19 19:07:20.57 BfUmY3M/0.net
>>709
それでも特に差は出ないっぽい。全体に与える影響が小さいんじゃないかと思う。
727:名無しさん＠編集中
17/05/21 21:14:59.62 H9t65OYr0.net
品質指定で上限ビットレートを指定すると
未設定時から総ビットレートが減るのはわかるが逆に増えてしまうことも多いのが気になる
SSIM見るとIフレームのビットが削られてその分P,Bの画質がちょこっと上がってる傾向みたいだが挙動が謎
728:名無しさん＠編集中
17/05/21 22:08:01.45 6CJFiaUN0.net
制限なしよりIフレの画質が相対的に落ちるから
そのIからの画質低下を和らげるためにPとBにビットレを盛ってるんじゃないの
729:名無しさん＠編集中
17/05/29 23:56:22.27 kX0KfHXl0NIKU.net
ひ、卑猥とな？
730:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/05 01:24:27.96 liRH7buv0.net
auo [error]: x265が予期せず途中終了しました。x265に不正なパラメータ(オプション)が渡された可能性があります。
OCしたRyzenでエンコ中にこんなエラー吐き出されて止まるんだが、
これOCが原因なんかな。x265以外の動作は問題ないんだけど
止まるタイミングもエンコ開始から約5分～5時間でまちまち
5時間で止まったときはこんな状態↓
■CPU ： Ryzen7 1700
■動作クロック / 3.750Ghz Vcore ： 1.31250V
■コア温度 ： 約70℃
■メモリクロック 2400 CL15
■温度計測方法 ：HWMonitor
731:名無しさん＠編集中 (ﾜｯﾁｮｲ fd44-GFnO)
17/06/05 02:19:28.24 pT9pn26D0.net
>>715
試しにOCやめてみたらいいのでは。
732:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/05 09:09:41.65 Yb0OI5uO0.net
>>715
電圧低すぎ
1700Xは3.4GHz/1.3500Vだから
733:名無しさん＠編集中 (ﾜｯﾁｮｲ 0911-rLqX)
17/06/05 10:42:45.15 IL3qxMnz0.net
定格で動かして同じエラーが出たら初めて相談するもんだろう。そういう問題って。
734:名無しさん＠編集中 (ｽｯﾌﾟ Sdea-ujBP)
17/06/05 11:07:08.21 8leySFvXd.net
OCが当たり前みたいな風潮だからな
OCは不安定なのが常だとは考えもしないくなっちまったんだろう
735:名無しさん＠編集中 (ﾜｯﾁｮｲ 5e1f-k7rq)
17/06/05 19:49:53.90 OgwTP3Gz0.net
OCによるメリットとデメリットが考えるとアホと思うわ
736:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/06 00:10:11.08 qbv3/zqx0.net
>>717
なんで定格なのに電圧盛ってるん？
737:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/06 00:20:41.61 iCITU6I/0.net
>>721
k17tkのデフォ値が1.3500Vだったという話
738:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/06 01:32:51.46 qbv3/zqx0.net
そうなのか、ちょっと調べてみたけど
1700Xは定格電圧高いね、1800Xと同じ
rigaya氏は1.3750Vで3.85GHz安定させてたし
他の人の報告見ても1.3500Vなら3.8GHz位いけそうだけど
そろそろスレチだから引っ込む
739:名無しさん＠編集中 (ﾃﾄﾘｽ Sa52-pSAu)
17/06/06 08:28:52.54 h1bzwWyFa0606.net
インテル環境とAMD環境の引越し時に編集ソフトとX265(GUI-EX?)を
1から再インストールして(環境設定もやり直し)すると、その不正なパラメータ渡し
エラーが消えて通常エンコ終了出来るって、FX9370を低電圧化して使ってる婆ちゃが言ってた。
740:名無しさん＠編集中 (ﾃﾄﾘｽ 95dd-8/NL)
17/06/06 11:50:19.37 gVOU1y4J00606.net
--pme付けてるとかじゃないの
今はもうx264に戻したから詳しい事は忘れたがこのオプション付けてると途中で落ちる事があった
741:名無しさん＠編集中 (ﾃﾄﾘｽ Sdea-ujBP)
17/06/06 12:30:37.24 GpwQkBZEd0606.net
オプションあるけど、使えないってのたくさんあるみたいだしな
742:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/07 01:15:39.60 IxJ2ZmVQ0.net
>>723
1700の定格ってどこかで見れますかね？
就寝時用にクロック落すから参考にしたい
743:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/07 01:18:18.15 IxJ2ZmVQ0.net
>>725
そうそう俺も落ちまくった
ハードを疑ってたけど違ったのね
744:名無しさん＠編集中 (ﾜｯﾁｮｲ bd23-rLqX)
17/06/07 04:10:02.45 tohYPFhw0.net
>>727
BIOSでOCせずRyzenMaster起動すれば分かるよ
たしか1.18V位だったと思うけどうろ覚え
>>725
pmeは付けてない。pmodeは付けてるけど付ける前も落ちてた
745:名無しさん＠編集中 (ﾜｯﾁｮｲ dd17-rLqX)
17/06/07 17:00:33.24 IxJ2ZmVQ0.net
>>729
自分>722の1700X利用者でっせ
746:名無しさん＠編集中 (ﾜｯﾁｮｲ d517-yTT2)
17/06/09 14:44:25.57 /2rWhqYD0.net
10bitエンコードって凄いのな
8bitエンコードのまま下手にパラメータいじるより目に見えて効果があった
747:名無しさん＠編集中 (ﾜｯﾁｮｲ 23ea-OlK+)
17/06/09 16:21:24.51 ZdlOYqrc0.net
x264もそうだったね
748:名無しさん＠編集中 (ﾜｯﾁｮｲ 1523-yTT2)
17/06/11 08:47:14.02 93Xf1T3r0.net
>>730
アイドル状態は常時電圧変動してたわ
ただ利用率100%で張り付いてる時は
3.2GHzで1.11250V固定
749:名無しさん＠編集中 (ﾜｯﾁｮｲ d517-yTT2)
17/06/14 00:18:02.66 yMJcJmdk0.net
今ビルドして手に入るx265のSAOって前テストした時より良くなってる気がする
数か月ぶりにプリセット見直してこんな感じになった（ちなみにアニメ向け）
--preset slow --crf 21 --input-depth 8 --output-depth 10 --deblock -1:-1 --qcomp 0.7 --vbv-bufsize 10000 --vbv-maxrate 9000
--aq-mode 3 --aq-strength 0.6 --psy-rd 0.5 --psy-rdoq 0 --rdoq-level 2 --max-merge 5 --bframes 4 --ref 3 --weightb
--no-opt-qp-pps --no-opt-ref-list-length-pps --asm AVX2
rdoq-level はx264のtrellisほど効果は分からなかったから
本腰用batでは2、それ以外のは0で
前書いたやつ（一部オプションの感想）が転載されてたので一応、新しいのを全部を書いておく
>>733
うちもそんな感じ
3GHzだと0.984Vぐらいで動いてる
750:名無しさん＠編集中 (ﾜｯﾁｮｲ d517-yTT2)
17/06/14 00:26:42.28 yMJcJmdk0.net
なお一番画質に影響したのは↓output-depth 8はゴミと言ってもいいレベル
--input-depth 8 --output-depth 10
751:名無しさん＠編集中 (ﾜｯﾁｮｲWW 854b-sCoW)
17/06/14 22:52:18.78 qF3SGDPB0.net
アニメのcrfってどれくらいがいいのかな？
今は20でやってる
752:名無しさん＠編集中 (ﾜｯﾁｮｲ b317-yC+1)
17/06/15 00:00:19.64 RBCPNwe00.net
低ければ低いほどいいと思うけど
元が放送波ならソースのアラを相当うまく補正しないと
下げても有意な差はない（元ソースのアラの再現性・保存性が良くなるだけだと思ってる
ぶっちゃけcrf22でも大して差はわからない
753:名無しさん＠編集中 (ﾜｯﾁｮｲ e3b1-yC+1)
17/06/15 01:31:05.08 2mkwJ42x0.net
低さにも限度がある
低すぎればソースよりサイズ膨らむだろうし
754:名無しさん＠編集中 (ﾜｯﾁｮｲWW 8b4b-oWh/)
17/06/15 13:08:23.61 h6jgR1Rw0.net
>>737,738
ありがとうございます。
ノイズ除去等はしないつもりなので、crf22にしてみようと思います。
755:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 12:21:10.34 Vm+ma6rU0.net
L-SMASHのmuxer.exeって、なんで入力ファイルが見つからないだけでクラッシュするんだろう・・・
756:名無しさん＠編集中 (ﾜｯﾁｮｲ 6dd1-CicO)
17/07/05 20:41:35.32 t3li/Qf+0.net
入力ファイルが見つからない＝無いのと同じ
エンコーダ「エンコードしなければいけないソースが無いのに何をエンコすればいいの？」
っていうことじゃないの？ｗ
757:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 20:49:26.19 Vm+ma6rU0.net
いや、エラーメッセージ出して終了すればいいだけだろ。
なんで「プログラムは動作を停止しました」だかのダイアログを見せられなあかんねんと。
758:名無しさん＠編集中 (ﾜｯﾁｮｲ 6dd1-CicO)
17/07/05 21:54:52.97 t3li/Qf+0.net
そんなの単純じゃん
エラーメッセージなんか�
759:ﾜるで見ない（そもそもログすらまともに見ないでエラーのダイアログだけが無駄に気になっちゃうガイジが多いからだろ うざいなら自分で修正すりゃ良いじゃん ソースも公開されてんだし
760:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 22:03:04.45 Vm+ma6rU0.net
なんだか変な人を呼び出してしまったようだ・・・すまぬ。
761:名無しさん＠編集中 (ﾜｯﾁｮｲ 6dd1-CicO)
17/07/05 22:06:50.03 t3li/Qf+0.net
あーダイアログはOSの問題だもんな
OSを修正すりゃ良いんじゃねｗ
762:名無しさん＠編集中 (ﾜｯﾁｮｲ c2ea-POtP)
17/07/05 22:13:06.39 Sreov/SH0.net
だいぶ前に報告されたバグだけどまだ直ってないの？
VFRmaniac Vのまにまに x264gui
ｽﾚﾘﾝｸ(avi板)
558 名前：名無しさん＠編集中[sage] 投稿日：2016/11/15(火) 19:10:12.99 ID:/BSskAhd
x265スレから。既に見てるような気もしますが、当人含めて誰もこっちに貼りに来ないので一応。
r1417で試したら確かにクラッシュしますね。
---
267 名無しさん＠編集中 sage 2016/11/11(金) 17:10:10.87 ID:i1JaPs2C
上にl-smashのmuxerの話が出てたからスレチなんだけど書かせて
muxerで指定したファイルがないと異常終了するの修正して欲しい
remuxerはエラー表示するだけ
結構前からのバグでバッチで流すのに面倒というか初歩の初歩かと
---
559 名前：名無しさん＠編集中[sage] 投稿日：2016/11/15(火) 22:07:37.16 ID:onzLsuks
>>558とは別人だけど
URLﾘﾝｸ(github.com)
ココのif文コメントアウトしたらうちでは正常にエラーメッセージが起こってクラッシュせずに終了するな
763:名無しさん＠編集中 (ﾜｯﾁｮｲ 0144-Qvj1)
17/07/05 22:30:09.63 Vm+ma6rU0.net
>>746
rigaya氏ビルドのL-SMASH rev1450でクラッシュするから、まだ直ってないっぽい。
764:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fea-URZV)
17/07/06 01:12:16.18 0jVJ3apV0.net
>>746のとこコメントアウトしたら今度は正常にmuxした後にクラッシュするなあ
レジストリいじってエラーダイアログ自体を非表示にした方がいいかもしれないね
他のソフトのエラーダイアログも出なくなるけど
ｘｘｘEXEは動作を停止しました メッセージを表示させない｜きりんの雑記
URLﾘﾝｸ(ameblo.jp)
765:名無しさん＠編集中 (ﾜｯﾁｮｲ d739-zXdO)
17/07/06 12:58:37.37 n3ig2wPi0.net
>>748
その書き込みより後にたくさんcommitはいってるからその書き込みの情報は信用できないと思う
SEGVだからmuken氏に見てもらうしか無いな
766:名無しさん＠編集中 (ﾜｯﾁｮｲ 9717-rvkC)
17/07/06 17:52:34.28 tQGoojMa0.net
rawファイルさえあればエラーがでないんだから問題なくね？
767:名無しさん＠編集中 (ﾜｯﾁｮｲ 9fea-URZV)
17/07/06 18:07:39.90 0jVJ3apV0.net
多分、batに不備があって途中で処理が止まっちゃうだろうね
768:名無しさん＠編集中 (ﾜｯﾁｮｲ d739-zXdO)
17/07/06 22:16:24.61 n3ig2wPi0.net
入力ファイルのチェックをバッチやシェル側でやれば良いんじゃない？
769:名無しさん＠編集中 (ﾜｯﾁｮｲ f744-rfzC)
17/07/06 22:21:59.29 vuDg0qe30.net
運用で対処すればいいじゃんと言われれば確かにその通りではあるけど、
>>746にもあるようにプログラムとしては明らかなバグだから直してもらえると嬉しいねという話ね。
770:名無しさん＠編集中 (ﾜｯﾁｮｲ 2144-A9YL)
17/07/14 00:53:49.06 J1C4bm5a0.net
Version 2.5
Release date - 13th July, 2017.
URLﾘﾝｸ(x265.readthedocs.io)
771:名無しさん＠編集中 (ﾜｯﾁｮｲ 1611-S4qQ)
17/07/14 01:08:56.41 GeLosK/E0.net
を、2.5 きたか!!
ちょっくらビルドしてこよう。
772:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/14 01:19:26.08 Ljds1+Tg0.net
x265ってVFRのレートコントロールには対応してないよね
24pと60pの混合なVFRをビットレート指定でエンコしたいときって
どうするのが一番いい？
773:名無しさん＠編集中 (ﾜｯﾁｮｲ 354f-PDtw)
17/07/14 12:10:48.70 CTXwjp490.net
x264
774:名無しさん＠編集中 (ﾜｯﾁｮｲ 0117-S4qQ)
17/07/14 12:58:34.64 ZmGhVoRc0.net
低いほうに合わせればいい
775:名無しさん＠編集中 (ﾜｯﾁｮｲ 1611-S4qQ)
17/07/14 14:09:47.56 GeLosK/E0.net
気合いの120fps
776:名無しさん＠編集中 (ﾜｯﾁｮｲWW 634b-I8+U)
17/07/14 14:41:53.92 fEBkwWTr0.net
>>756
無知で申し訳無いのですがレートコントロールとはどのような物なのでしょうか？
777:名無しさん＠編集中 (ﾜｯﾁｮｲ ae9b-JuSQ)
17/07/14 17:58:34.09 eZ+cvx1f0.net
2行目にかいてあることじゃない
知らんけど
778:名無しさん＠編集中 (ﾜｯﾁｮｲ 0117-S4qQ)
17/07/14 18:18:33.22 ZmGhVoRc0.net
>>760
最大ビットレートとかバッファサイズとかが規格から逸脱しないようにすること
779:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-z+eH)
17/07/14 23:07:39.62 4WOGuhaz0.net
質問者
「今のx264やx265だと2Kや4Kエンコでも新しい多コアCPU(16C/32T等)を
100%使い切れないんだけど、なんとかならない？」
RipBot264作者
「RipBot264を使えば１つ（または複数）のマシンで分散エンコーディングできるから
100%使い切れるぜ！」
x265開発陣
「RipBot264ってオープンソースになってないよね？
x264やx265を呼び出してるんだからGPLv2に従ってソース公開しないと駄目だよ？」
RipBot264作者
「(ﾟДﾟ )ヤベッ！(寄付を募ったりもしてるや・・・)」
x265 HEVC Encoder
URLﾘﾝｸ(forum.doom9.org)
RipBot264って古くからあるみたいだけど初めて知った。分散エンコード機能なんてあるんだね。
x264だとmuken氏が
「規格に準じて結合するなら--stitchableをつけたり諸々注意が必要」
みたいなツイートをしてたけど、RipBot264はそのへん考慮して結合してるんだろうか。
あとx265でバラバラにエンコして結合する時の注意って何かあるんだろうか？
780:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/14 23:30:07.69 Ljds1+Tg0.net
zonesで指定すればいいみたいだね
>>762
どっちかというと俺が気にしてるのはバッファアンダーフローとかじゃなくて、
何も考えずにやると60pの部分に24pの60/24=2.5倍のビットレートが割り当てられちゃうこと
CBRにするわけじゃないからきっかり2.5倍ってわけじゃないだろうけど
x265はフレームレートが違うって分からないからちゃんとビットレート計算できないだろうし
781:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/14 23:55:06.73 Ljds1+Tg0.net
>>759
同じフレーム重複して入れたら、ちゃんとそれを認識して特別な処理してくれればいいんだけど、
現状のx265はそんなに賢くないっぽくて、エンコ時間長くなるし、圧縮後のデータ量も増えるんだよね
>>760
URLﾘﾝｸ(slhck.info)
> What is “rate control”? It’s what a video encoder does when it decides how many bits to spend for a given frame.
与えられたフレームにどれだけのビットを割り当てるか決めること
1パスとか2パスとか、CBRとかVBRとか、CFRとか
エンコでは基本的なことだよ
782:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 01:21:14.10 3m6njqCx0.net
それにしてもレートコントロールが何かを知らないとは
細かいオプションがどうこう言ってるけど、基本がなってないな
1パスとか2パスとか、何か知らないで使ってたのか
783:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-A9YL)
17/07/15 02:00:41.29 0O
784:Yp2Ppe0.net
785:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 02:10:30.42 3m6njqCx0.net
>>760-762
ここらへんの方たちは初心者だったか。それはすまぬ。勘違いだ
786:名無しさん＠編集中 (ﾜｯﾁｮｲ 4644-A9YL)
17/07/15 02:34:10.54 0OYp2Ppe0.net
>>768
俺も言葉の厳密な定義を正しく理解してるか自信はあまりないけど、
>>762が書いてる内容はレート制御の範疇に入るだろうから外していいんじゃないか。
787:名無しさん＠編集中 (ﾜｯﾁｮｲ 35db-MRQN)
17/07/15 17:58:35.45 3m6njqCx0.net
>>763
x264やx265のexeを起動してるだけなら、GPLを要求するのは難しいよ
ライブラリバージョン使ってるならGPLにしないとダメだけど
GPL原理主義みたいな人たちは宗教的なとこあるから、GPLを要求したいのは分かるけど
788:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 16:21:37.18 HpejTqPk0.net
2.5のリリースノートに
1. Improved grain handling with --tune grain option by throttling VBV operations to limit QP jumps.
とあったので2.4+2と2.5+3（ともにrigaya氏ビルド）で比較してみたら、
ビットレートもSSIMも完全一致するという結果になったんだけど、なんでだろう？
MediaInfoで見る限り、
URLﾘﾝｸ(bitbucket.org)
にある --const-vbv は有効にされてる模様。
SSIM/ビットレート図 → URLﾘﾝｸ(2sen.dip.jp)
789:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 16:22:28.34 HpejTqPk0.net
Histogram("luma")
オリジナル → URLﾘﾝｸ(2sen.dip.jp)
x264 r2833 medium18 → URLﾘﾝｸ(2sen.dip.jp)
x264 r2833 slower grain24 → URLﾘﾝｸ(2sen.dip.jp)
x265 2.5+3 medium16 → URLﾘﾝｸ(2sen.dip.jp)
x265 2.5+3 slow grain22 → URLﾘﾝｸ(2sen.dip.jp)
x265 2.4+2 slow grain22 → URLﾘﾝｸ(2sen.dip.jp)
790:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 19:42:00.27 HpejTqPk0.net
ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
ｽﾚﾘﾝｸ(jisaku板:796-797番)
791:名無しさん＠編集中(ﾜｯﾁｮｲ 354f-PDtw)
17/07/16 20:14:47.61 lE/bCIkh0.net
VBV設定してないってオチ？
792:名無しさん＠編集中 (ﾜｯﾁｮｲ f644-A9YL)
17/07/16 21:36:13.64 HpejTqPk0.net
>>774
よくわかってないのだけど、単に --tune grain を指定しただけでは駄目なのかな？
793:名無しさん＠編集中 (ｽﾌﾟｯｯ Sd7f-RYCd)
17/07/24 11:04:19.38 DAPBP2DDd.net
>>763
これって分散エンコでググっても全く出てこないのな
x265にも対応してるみたいで最近も更新してる様だけど、分散エンコに関するブログ紹介は2012以降ぱたりと無くなる
日本語化で機能しなくなる？のが原因なんだろうか
794:名無しさん＠編集中
17/08/01 21:18:57.52 kTrSsjB50.net
URLﾘﾝｸ(pc.watch.impress.co.jp)
＞Vegaアーキテクチャでは、パックドの8-bit整数演算もサポートされた。
＞しかし、8-bit整数演算は、SAD(Sum of Absolute Difference:差の絶対値和)
＞演算のみサポートとなっている。動画などイメージ処理向けであり、
＞マシンラーニング向けの実装ではない。
x265のエンコに使えると良いな
795:名無しさん＠編集中
17/08/03 15:23:27.98 NWKbjdAs0.net
おすすめのオプションある？
ソースは解像度が720x480のアニメTS
796:名無しさん＠編集中
17/08/03 20:38:03.33 M9rDlJ6g0.net
デフォでOK。エンコ設定より前処理の方が何倍も重要
797:名無しさん＠編集中
17/08/04 23:35:07.10 ZTZ+gYb+0.net
しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
やっぱaq-mode1 aq-strength 1.2のほうが良かった
素行自体は良さそうだったんだけどな＞aq-mode3
798:名無しさん＠編集中
17/08/05 00:39:17.43 9YOKH1fA0.net
aq-mode 1がオールマイティなのかな
アニメを10bitエンコードするとcrf 20～22でも暗部の輪郭(エッジ)が汚れやすくて少し気になる
なんとかできないものか
799:名無しさん＠編集中
17/08/05 01:26:48.87 YCAHTRys0.net
x264でエンコする
800:名無しさん＠編集中
17/08/05 01:37:12.34 FHp3bZ4Q0.net
エッジを保護したいならaq使わなければいい
当然のっぺりした部分がその分劣化するわけだが
801:名無しさん＠編集中
17/08/05 10:06:55.90 jnUNU58K0.net
>>781
aq-mode3のaq-strength 0.4ぐらいでやればいいじゃ？
802:名無しさん＠編集中
17/08/05 16:43:26.59 YCAHTRys0.net
strength値0.4くらいだとaq3使う利点あまりないからaq on/offどっちでも良いと思うよ
803:名無しさん＠編集中
17/08/05 21:01:05.73 jnUNU58K0.net
そうでもなかった気がする
実写には不向きだったけど
804:名無しさん＠編集中
17/08/12 21:18:45.62 4YeA1asg0.net
新しいオプション --refine-intra と --refine-inter が追加されたらしいから試してみたけど
Analyze level 10が必要って言われた
これって2passのみってこと？
805:名無しさん＠編集中
17/08/16 00:27:26.44 ubdOdQwr0.net
>>787
rigaya氏のx2.5+8 x64で試してみたけど、2パス目に入ってすぐにクラッシュしてしまい、うまく動かなかった。
そもそもこの指定方法であってるのかよくわからんけど・・・。
%avs2pipemod% -y4mp "%~1" | %x265% --y4m - --preset medium --bitrate 1000 --no-cutree --analysis-reuse-mode save --analysis-reuse-level 10 -o test.mp4
%avs2pipemod% -y4mp "%~1" | %x265% --y4m - --preset medium --bitrate 1000 --no-cutree --analysis-reuse-mode load --analysis-reuse-level 10 --scale-factor 2 --refine-intra 1 --refine-inter 1 -o test.mp4
806:名無しさん＠編集中
17/08/16 11:03:56.00 duFXfDfk0.net
>>788
解析ファイルを指定するオプションがあったはず
807:名無しさん＠編集中
17/08/16 14:35:46.41 y9oCilvW0.net
>>789
--analysis-reuse-fileのことだと思うけど、指定しなければx265_analysis.datになるし、指定しても駄目だった。
808:名無しさん＠編集中
17/08/23 11:31:49.09 osg+kKft0.net
x265 HEVC OpenCL or CUDA Encoder
URLﾘﾝｸ(bitbucket.org)
809:名無しさん＠編集中
17/08/23 17:22:10.57 eg+3M5BL0.net
夏休みの自由研究かな
810:名無しさん＠編集中
17/08/23 18:03:50.40 iIBnv5OG0.net
どのくらいパフォーマンス向上するのかな
811:名無しさん＠編集中
17/08/23 18:58:09.00 eg+3M5BL0.net
CPUの半分も出ればいいほうだな
812:名無しさん＠編集中
17/08/23 20:03:47.01 nxBulyrM0.net
>>791 を適当にビルドだけしてエンコしてみたけど別に速くなるとかなんもなかったな。
各ソースのコメントに openacc と付いてる部分で GPU 使ってるんだとは思うが。
813:名無しさん＠編集中
17/08/23 20:29:12.72 iIBnv5OG0.net
オリジナルのx265もopenaccが入って来てる
openacc有効にしてビルドすれば、それなりに高速化するらしい
814:名無しさん＠編集中
17/08/23 21:49:34.43 eg+3M5BL0.net
>>796
妄想が激しいなｗ
815:名無しさん＠編集中
17/09/01 19:12:31.73 ArSPPgcm0.net
>>788-790がそのままだったので、あらためてreuse,refine系を試した結果を連投。
■--analysis-reuse-levelのテスト１（640x360@24、1092frames）
●オプション
・--preset slower --pass 1 --bitrate 500 --no-cutree --analysis-reuse-mode save --analysis-reuse-level %reuseLevel%
・--preset slower --pass 2 --bitrate 500 --no-cutree --analysis-reuse-mode load --analysis-reuse-level %reuseLevel%
●1pass目の結果は省略（8.81～9.03fps）
●reuse無し
125.05s (8.73 fps), 499.16 kb/s, Avg QP:20.38
●reuseLevel=1、reuseファイルのサイズ：123KB
125.87s (8.68 fps), 499.35 kb/s, Avg QP:20.40
●reuseLevel=2、reuseファイルのサイズ：569MB
112.51s (9.71 fps), 498.51 kb/s, Avg QP:20.47
●reuseLevel=5、reuseファイルのサイズ：571MB
109.80s (9.95 fps), 498.51 kb/s, Avg QP:20.46
●reuseLevel=10、reuseファイルのサイズ：28.9MB
4.29s (254.72 fps), 493.20 kb/s, Avg QP:20.52
816:名無しさん＠編集中
17/09/01 19:13:31.68 ArSPPgcm0.net
■--analysis-reuse-levelのテスト２（1920x1080@23.976、2157frames）
●オプション
・テスト１と同様。ビットレート指定のみ9000に。
●1pass目の結果は省略（0.81～0.87fps）
●reuseLevel=1、reuseファイルのサイズ：234KB
2449.91s (0.88 fps), 8953.61 kb/s, Avg QP:18.21
●reuseLevel=2、reuseファイルのサイズ：8.81GB
2177.31s (0.99 fps), 8953.84 kb/s, Avg QP:18.24
●reuseLevel=5、reuseファイルのサイズ：8.85GB
2182.34s (0.99 fps), 8953.38 kb/s, Avg QP:18.23
●reuseLevel=10、reuseファイルのサイズ：595MB
89.42s (24.12 fps), 8921.43 kb/s, Avg QP:18.44
817:名無しさん＠編集中
17/09/01 19:14:31.78 ArSPPgcm0.net
■--refine-intra、--refine-interのテスト（640x360@24,1092frames）
●オプション
・--preset slower --pass 1 --bitrate 500 --no-cutree --analysis-reuse-mode save --analysis-reuse-level 10 --ctu %maxCU1% --min-cu-size %minCU1%
・--preset slower --pass 2 --bitrate 500 --no-cutree --analysis-reuse-mode load --analysis-reuse-level 10 --ctu %maxCU2% --min-cu-size %minCU2% --refine-intra %refine% --refine-inter %refine% --scale-factor 2
●--scale-factorの説明を元に--ctuと--min-cu-sizeを指定。いくつかのソースで試した限りでは
以下の４パターンの組み合わせのみ2pass目がクラッシュせずに動いた。
表記は「CTU-%maxCU1%-%minCU1%-%maxCU2%-%minCU2%」
●CTU-32-32-64-32
p1：29.30s (37.27 fps), 418.33 kb/s, Avg QP:22.78、reuseファイルのサイズ：20.7MB
p2(refine=1)：25.05s (43.60 fps), 540.76 kb/s, Avg QP:29.83
p2(refine=2)：19.11s (57.16 fps), 506.54 kb/s, Avg QP:24.69
p2(refine=3)：40.76s (26.79 fps), 507.85 kb/s, Avg QP:24.13
818:名無しさん＠編集中
17/09/01 19:15:21.46 ArSPPgcm0.net
●CTU-32-16-64-32
p1：49.65s (21.99 fps), 483.44 kb/s, Avg QP:21.72、reuseファイルのサイズ：26.3MB
p2(refine=1)：26.14s (41.78 fps), 521.65 kb/s, Avg QP:28.72
p2(refine=2)：19.01s (57.45 fps), 505.24 kb/s, Avg QP:23.90
p2(refine=3)：45.51s (24.00 fps), 506.25 kb/s, Avg QP:23.32
●CTU-16-16-32-16
p1：32.75s (33.34 fps), 482.39 kb/s, Avg QP:22.39、reuseファイルのサイズ：31.7MB
p2(refine=1)：28.34s (38.53 fps), 527.16 kb/s, Avg QP:28.71
p2(refine=2)：17.68s (61.78 fps), 507.18 kb/s, Avg QP:23.36
p2(refine=3)：51.62s (21.16 fps), 509.31 kb/s, Avg QP:22.73
●CTU-16-8-32-16
p1：81.67s (13.37 fps), 486.43 kb/s, Avg QP:22.25、reuseファイルのサイズ：40.2MB
p2(refine=1)：30.03s (36.36 fps), 524.99 kb/s, Avg QP:27.88
p2(refine=2)：18.08s (60.41 fps), 509.86 kb/s, Avg QP:23.36
p2(refine=3)：52.24s (20.91 fps), 510.78 kb/s, Avg QP:22.68
819:名無しさん＠編集中
17/09/01 19:16:26.42 ArSPPgcm0.net
■参考
1920x1080、2157framesでCTUサイズを指定した場合のreuseファイルのサイズ（ログ取り忘れ）
CTU-32-32-64-32→357MB、CTU-16-8-32-16→760MB
■コメント
１．reuse-levelの5がrectとampの情報を保存するようなので両者が有効になるslowerを使用。
２．reuse-levelの2と5はreuseファイルのサイズが極端にでかくなるが、
より多くの情報を保存するはずの10はなぜか比較的サイズが小さかった。(それでもでかいけど)
３．CTUサイズの指定については「2pass目がクラッシュしない組み合わせ」を総当たりで探しただけ。
４．x265guiEx v3.79で reuse、refine系の設定欄が追加されたが、
--scale-factor と --min-cu-size の設定欄が無いので、これらは追加コマンド欄で指定する必要がある。
また --refine-mv の設定欄も無い模様。
820:名無しさん＠編集中
17/09/01 19:17:41.13 ArSPPgcm0.net
■最後に
--analysis-reuse系のオプションの使いどころやメリットがよくわからないと思って
調べていたら、x265開発陣が以下のようなコメントをしていた。
URLﾘﾝｸ(forum.doom9.org)
概要
> ライバルもいるから詳細はあまり説明したくないんだけど、基本的には
> (UHDkitで)ライブエンコード時の速度アップや、オフラインエンコード時の
> 計算効率アップのソリューションを提供するための仕組み。
> x265を単体で使っている人には特にメリットもないし、高品質になるわけでもない。
なお上のコメントはreuse系オプションのことなので、refine系についてはまた別。
refine系の効果までは検証していないので、オプションの説明以上のことは不明。
821:名無しさん＠編集中
17/09/07 19:56:07.66 HahZrfhH0.net
qpmin=0はコマンドもない気がするけど何か入れないとでてこないタイプですか？
822:名無しさん＠編集中
17/09/07 20:37:21.32 lQ8OTYTC0.net
>>804
x265.exe --help
> Use --log-level full --help for a full listing
823:名無しさん＠編集中
17/09/07 20:59:50.49 HahZrfhH0.net
>>804
ありがとうございます
824:名無しさん＠編集中
17/09/08 18:14:05.76 I9BkB4D70.net
>>806
× >804
○ >805
825:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています