15/12/31 13:25:56.61 1x/a9izS.net
ほうlimit-refsをデフォで使うようになった感じ？
720p mediumならリアルタイムでエンコできる環境が増えそうだ
689:名無しさん＠編集中
15/12/31 18:06:45.58 wSkFl2OB.net
グラフ見る限りは魅力的だけど、新プリセットはどこにあるのかな
git見てもそんなのまだなさそうだが
690:名無しさん＠編集中
15/12/31 18:35:10.47 xsxqdEld.net
>>671
既存のプリセットの設定を調整したという話だと思うんだが・・・
691:名無しさん＠編集中
15/12/31 19:04:36.81 pgio0AKr.net
これめちゃ速いな。
--input-csp i420 --preset slow --crf 21 --aq-mode 3 --aq-strength 0.9 --psy-rd 0.5 --psy-rdoq 8 --scenecut 42 --keyint 240
--tu-intra-depth 2 --tu-inter-depth 2 --max-merge 5 --weightb --frames 34096 --input-res 1920x1080 --fps 24000/1001
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 5
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 42
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 4 / 1 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=0.50 rdoq=2 psy-rdoq=8.00
x265 [info]: tools: signhide tmvp strong-intra-smoothing lslices=4 deblock sao
こんな感じで
encoded 34096 frames in 1504.14s (22.67 fps), 1137.26 kb/s, Avg QP:26.29
auo [info]: CPU使用率: Aviutl: 5.82% / x265: 76.88%
全く同じオプションで--pmode付けると
encoded 34096 frames in 2293.68s (14.87 fps), 1122.80 kb/s, Avg QP:26.29
auo [info]: CPU使用率: Aviutl: 3.69% / x265: 87.79%
画質はまだチェックしてないけど、問題無ければ、slowでも余裕でも余裕だな。
(10bitは使う予定無いので、未検証）
692:名無しさん＠編集中
16/01/01 02:18:30.24 WmQnDSNu.net
エラいスピードアップだな。
画質にダメージとかないんかね？
693:名無しさん＠編集中
16/01/01 03:09:19.16 RD6MTGrq.net
1.8+188で適応されてるの？
694:名無しさん＠編集中
16/01/01 05:20:46.74 O3DrfO55.net
SSIMの話してたら公式がグラフに使っててワラタ
695:名無しさん＠編集中
16/01/01 07:49:50.36 jXigYVvB.net
あーpresetの件、�
696:ｽ分、１２月２２日に導入されたこの変更のことだろうな https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce 各プリセットのパラメータを微調整したうえに、最近導入されたlimit-refs、limit-modesも加えたと。 最新ソースを使ってビルドしてるなら、もう１周間前に導入されてたということね。
697:名無しさん＠編集中
16/01/01 09:45:09.31 0amdltZA.net
12/23のx265guiEx 3.66v2でプリセット変更への対処が入ってたしな。
1.8+2と1.8+188とで、手元のソースをプリセット指定だけでエンコした結果を比べてみたら
・エンコード速度は全体的に向上。
・ultrafast～fasterでは従来よりSSIM値が小さくなり、ビットレートも大幅に低くなった。
・fast～slowerではSSIM値は従来と同じくらいだが、ビットレートがやや高くなった。
という結果になった。veryslowとplaceboは時間がかかるので試していない。
詳細→ URLﾘﾝｸ(pastebin.com)
698:名無しさん＠編集中
16/01/01 11:14:31.16 xC692RGG.net
すいません、質問です。
x265のソースコードを自分でビルドして使用しているのですが
バイナリのバージョンが不明なんです。これってコード追記しないといけないのでしょうか？
変な質問だったらスルーしてください。
699:名無しさん＠編集中
16/01/01 15:09:29.20 jXigYVvB.net
x265.exe --version
とコマンド打てば表示されるよ
700:名無しさん＠編集中
16/01/01 15:29:05.52 xC692RGG.net
>>680
Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.
C:\Windows\system32>x265.exe --version
x265 [info]: HEVC encoder version unknown
x265 [info]: build info [Windows][MSVC 1800][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
こんな感じです。
701:名無しさん＠編集中
16/01/01 15:29:40.58 nwqCpAdi.net
>>679
ソース下のbuild/README.txtにも書かれてる事(「= Version number considerations =」を参照)だけど、
X265_VERSION はcmake実行時にMercurial(hgコマンド)を使用して設定、ないと"unknown"になる。
Mercurial(hg)のパスを環境変数PATHに追加してからcmakeを実行する。
702:名無しさん＠編集中
16/01/01 15:39:01.12 xC692RGG.net
>>682
ありがとうございます。
703:名無しさん＠編集中
16/01/01 17:27:43.84 jXigYVvB.net
Rigayaさんのとこのx265エンコ速度測定記事、プリセット変更直前に書かれてるのがおしい
704:名無しさん＠編集中
16/01/01 17:32:56.40 xC692RGG.net
なんでおかしいの？
rigaya氏が変更を事前に知っていて、わざと記事にしたとでもいうの？
705:名無しさん＠編集中
16/01/01 17:34:04.38 k8j4Ysr1.net
>>685
落ち着いて>>684を読み直してみろ
706:名無しさん＠編集中
16/01/01 17:39:27.38 jXigYVvB.net
>>685
うん。君はおかしい
はい次の人ー
707:名無しさん＠編集中
16/01/01 17:43:45.36 xC692RGG.net
m(__)m
708:名無しさん＠編集中
16/01/01 20:28:21.76 FNsjlYzw.net
ところでさ、現時点のx265はUltra HD BDの規格に準拠した形でのエンコードはできるんだろうか？
それともまだ何か未対応のオプションがあったりして、規格準拠とまではいかないのだろうか？
x265の進捗状況がよくわからないんだけど。
709:名無しさん＠編集中
16/01/02 21:42:43.73 uM4JuYJD.net
どうしても暗部保持ができなくてバンディングになっちゃう
おもいっきりビットレート上げればなんとかなるけど
一話23分半のアニメで3Gくらいの容量になるからさすがに割りに合わない
710:名無しさん＠編集中
16/01/03 06:14:00.23 TB5sGS/t.net
バンディング消す方法なんていくらでもあるでしょー
基本は10bitエンコだし、
バンディング低減
711:するフィルタだって複数あるよ x264よりも遥かにバンディング出ないx265で悩んでる人はじめて見た
712:名無しさん＠編集中
16/01/03 09:29:55.61 +7iHH5QT.net
バンディングて色調整するとワラワラ出てくることあるね
713:名無しさん＠編集中
16/01/03 12:06:06.62 KftKtXND.net
>>691
x264の10bitの方が明らかにバンディング出ないから悩んでるんだけど
エンコ速度的には十分だと思うし、その問題さえ解消するようならx265に移行するのもいいかなって思ってるけど
>485の頃からまだこういうところは調整されてないのかな？
714:名無しさん＠編集中
16/01/03 12:17:20.68 aIpwUsLj.net
どちらかというとAQで暗部は削られるものだと思うけど・・
715:名無しさん＠編集中
16/01/03 13:57:04.40 CBJBsL1D.net
糞なのはx265のPsyだろうねぇ
716:名無しさん＠編集中
16/01/03 22:11:59.73 V82V0kUc.net
下手くそ
717:名無しさん＠編集中
16/01/05 23:20:08.23 wK8tZoI/.net
ん？またプリセット変わったか
718:名無しさん＠編集中
16/01/06 21:50:42.37 /8vK25uX.net
URLﾘﾝｸ(bitbucket.org)
Merge with default, prep for 1.9
もうすぐ1.9が来そう
719:名無しさん＠編集中
16/01/10 08:23:42.64 Hd4RBeuI.net
x265 1.8+205 -d94f6c2b45f8
URLﾘﾝｸ(www1.axfc.net)
720:名無しさん＠編集中
16/01/10 14:30:01.33 m9YtAxYc.net
x64じゃないのかな
721:名無しさん＠編集中
16/01/10 14:32:48.05 m9YtAxYc.net
なんかエラーで落ちる
722:名無しさん＠編集中
16/01/10 14:47:46.35 Hd4RBeuI.net
>>701
マジすか？
ちょっと調べてみます。
>>700
64bit専用です。
723:名無しさん＠編集中
16/01/10 14:59:37.89 m9YtAxYc.net
普段ここの使ってるんだけど
URLﾘﾝｸ(builds.x265.eu)
ここのも1/8のものからエラーで落ちるようになってる
1/7の1.8+201のものはエラー出ない
自分の環境かもしれないし何が何だか分かってないけど
問題解決されると嬉しい
724:名無しさん＠編集中
16/01/10 15:10:43.28 Hd4RBeuI.net
これはどうでしょうか？
URLﾘﾝｸ(www1.axfc.net)
725:名無しさん＠編集中
16/01/10 15:42:21.06 m9YtAxYc.net
ありがとう
でも同じだった
イベントビューアにはこんな感じで上がってる
障害が発生しているアプリケーション名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
障害が発生しているモジュール名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
例外コード: 0xc0000005
障害オフセット: 0x0000000000790522
726:名無しさん＠編集中
16/01/10 16:05:38.87 Hd4RBeuI.net
うーん・・・
コマンドラインオプション無しでもエラー出ますか？
727:名無しさん＠編集中
16/01/10 16:09:39.28 m9YtAxYc.net
それだと出ないね
俺のオプションがダメっぽいのか…
どのオプションだろ
削りながら試してみるよ
ありがと
728:名無しさん＠編集中
16/01/10 16:12:07.50 Hd4RBeuI.net
メモリーアクセス違反か。
自分の環境では出ないんですよね。
OSはなんですか？
729:名無しさん＠編集中
16/01/10 16:15:17.26 Hd4RBeuI.net
AVX、AVX2、FMA3を潰してみるとか。
730:名無しさん＠編集中
16/01/10 16:16:06.57 m9YtAxYc.net
--no-deblock
このオプション抜いたらエラー出なくなった
これは自分の環境が悪いとかじゃないよね…
731:名無しさん＠編集中
16/01/10 16:23:36.91 Hd4RBeuI.net
ありがとうございます。
そちらの問題ではなく、コードに問題有りかもです。
732:名無しさん＠編集中
16/01/10 16:53:54.29 V/aHiJAl.net
斧に上がったバイナリなんてよく実行できるな・・・
733:名無しさん＠編集中
16/01/10 17:47:40.97 m9YtAxYc.net
どうやってバグの情報としてあげればいいのか分からないや
早く気付いて欲しいなぁ
734:名無しさん＠編集中
16/01/10 20:26:32.56 PlpsG+IN.net
>>713
bitbucketの課題にでも投げれば良いんじゃないの？
URLﾘﾝｸ(bitbucket.org)
735:名無しさん＠編集中
16/01/11 04:08:04.43 NFAme+dx.net
205で更にエンコ速度上がってるな
736:名無しさん＠編集中
16/01/11 18:42:34.02 8MzzuCE7.net
今は209だぜー
737:名無しさん＠編集中
16/01/11 22:48:39.09 iLbQXuHs.net
ここ最近開発が活発化してる
いいねえ
738:名無しさん＠編集中
16/01/12 03:22:31.26 ay8VbQDJ.net
x265-1.8+210_19cfada71621
URLﾘﾝｸ(www1.axfc.net)
739:名無しさん＠編集中
16/01/12 06:40:40.41 FuFhTotB.net
久々にビルドしてみたけど
デフォ設定で1.4と比べたら2倍くらいエンコ速くなってんな
740:名無しさん＠編集中
16/01/12 07:22:48.18 UGxx9q6x.net
密かにpsy-rdのデフォ値も変わったで
741:名無しさん＠編集中
16/01/12 08:45:59.11 FuFhTotB.net
ホントだ
1.0から0.6になっとるな
ちょこちょこ設定変えてんだな
742:名無しさん＠編集中
16/01/12 09:56:13.90 ZF6tU8kF.net
なかなか1.9にならんな
743:名無しさん＠編集中
16/01/12 10:09:53.76 xb1b+Mb+.net
>>721
旧： 値範囲0～2.0 デフォルト値0.3
新： 値範囲0～5.0 デフォルト値2.0
じゃね。
744:名無しさん＠編集中
16/01/12 11:20:34.90 FuFhTotB.net
strengthだった
745:名無しさん＠編集中
16/01/12 14:33:21.76 ckdTaHsh.net
H265 codecs comparison from MSU
URLﾘﾝｸ(x265.ru)
746:名無しさん＠編集中
16/01/12 14:48:48.67 J/v6lK/H.net
URLが怪しすぎる…
747:名無しさん＠編集中
16/01/12 15:14:52.56 UGxx9q6x.net
そこは、ちょっと前までx265バイナリの配布定番サイトだったんだけど、
multicorewareとトラブって配布禁じられたサイト
748:名無しさん＠編集中
16/01/12 15:33:28.98 xb1b+Mb+.net
>>727
トラブったという話の情報源はどこ？
本当ならテンプレからも外さないといかんよね。
749:名無しさん＠編集中
16/01/12 16:02:11.85 ay8VbQDJ.net
multicoreware-x265-6ccd503a4c3a
URLﾘﾝｸ(www1.axfc.net)
750:名無しさん＠編集中
16/01/12 16:07:54.77 ZF6tU8kF.net
ウィルスとかの問題じゃないから問題なし
x264は良かったとか書くあたりライセンスとかそのへんの理由
751:名無しさん＠編集中
16/01/12 21:07:29.03 UGxx9q6x.net
>>728
multicorewareがある日突然、他サイトでのバイナリ配布を禁じたんだよ
URLﾘﾝｸ(x265.ru)はバイナリ配布の最大手だったけど、一夜にして配布停止に追い込まれた
752:名無しさん＠編集中
16/01/12 22:21:22.09 vk6wUU7N.net
>>710
URLﾘﾝｸ(bitbucket.org)
微妙に症状は違うっぽいけど、--no-deblock付けてエラーになる事が解決されてるから、
多分、直ったっぽいよ。
753:名無しさん＠編集中
16/01/13 00:04:51.69 i5ptavi1.net
717のバイナリはバグっているので使わないほうがいい。
728は今のところ大丈夫。
754:名無しさん＠編集中
16/01/13 00:35:17.31 7rxsXKJd.net
そもそも他人ビルドで署名が無い物なんて使うわけ無いですし
755:名無しさん＠編集中
16/01/13 14:58:50.31 wOrVT6++.net
そうですか
756:名無しさん＠編集中
16/01/14 16:51:17.94 AaOlEqVU.net
>>732
1.8+211で試してみたけどまだ直ってないみたい…orz
でも気長に待ってみる
757:名無しさん＠編集中
16/01/15 06:50:52.92 psKZUe1A.net
x265-792f6ead9c50
URLﾘﾝｸ(www1.axfc.net)
758:名無しさん＠編集中
16/01/17 10:34:19.47 M6mbumiP.net
H.265はH.264の半分のビットレートで同等画質を実現するのが実証される - GIGAZINE
URLﾘﾝｸ(gigazine.net)
759:名無しさん＠編集中
16/01/17 10:49:26.43 D60EYyZP.net
>>738
これx264とx265でPSNR調べてもここまで差が出ないんだけど使ってるエンコーダーが違うのかね
760:名無しさん＠編集中
16/01/17 12:09:44.29 Pifl9Opi.net
JVとかいうリファレンスのコーデックでの比較なんじゃね
761:名無しさん＠編集中
16/01/17 12:11:58.73 D60EYyZP.net
JMとHMって書いてあったわ
762:名無しさん＠編集中
16/01/17 13:48:03.23 XmqoO05B.net
>>738
ADSL回線でピアキャスとかで配信するときに重宝する＞H.265
763:名無しさん＠編集中
16/01/17 23:50:56.36 Tbz8Tr7+.net
ADSLはプランによっては1000kbps上限だからねぇ
764:名無しさん＠編集中
16/01/29 2
765:1:07:28.93 ID:DKTs/nc/.net
766:名無しさん＠編集中
16/01/30 01:25:28.25 Wakff49R.net
1.9来たね！
767:名無しさん＠編集中
16/01/30 01:26:18.86 +Hb0depP.net
始まる前から終わってるx265
768:名無しさん＠編集中
16/01/30 01:28:24.65 pHFV68mi.net
今ビルドちゅう
769:名無しさん＠編集中
16/01/31 00:22:07.01 oQyeXKXJ.net
適当にベンチ 詳細はテキストに
ソース URLﾘﾝｸ(media.xiph.org)
faster
1.8 encoded 313 frames in 14.69s (21.31 fps), 744.68 kb/s, Avg QP:29.82, SSIM Mean Y: 0.9345886 (11.843dB)
1.9 encoded 313 frames in 13.67s (22.90 fps), 728.73 kb/s, Avg QP:33.03, SSIM Mean Y: 0.9343822 (11.830dB)
fast
1.8 encoded 313 frames in 24.91s (12.57 fps), 733.66 kb/s, Avg QP:33.71, SSIM Mean Y: 0.9383575 (12.101dB)
1.9 encoded 313 frames in 26.91s (11.63 fps), 727.01 kb/s, Avg QP:33.73, SSIM Mean Y: 0.9384505 (12.108dB)
medium
1.8 encoded 313 frames in 32.16s (9.73 fps), 734.23 kb/s, Avg QP:33.80, SSIM Mean Y: 0.9399273 (12.213 dB)
1.9 encoded 313 frames in 29.66s (10.55 fps), 727.66 kb/s, Avg QP:33.77, SSIM Mean Y: 0.9395933 (12.189dB)
slow
1.8 encoded 313 frames in 117.56s (2.66 fps), 730.36 kb/s, Avg QP:33.21, SSIM Mean Y: 0.9423414 (12.391dB)
1.9 encoded 313 frames in 69.20s (4.52 fps), 720.24 kb/s, Avg QP:33.22, SSIM Mean Y: 0.9419035 (12.359 dB)
slower
1.8 encoded 313 frames in 239.98s (1.30 fps), 734.70 kb/s, Avg QP:34.08, SSIM Mean Y: 0.9430790 (12.447dB)
1.9 encoded 313 frames in 119.09s (2.63 fps), 703.49 kb/s, Avg QP:34.26, SSIM Mean Y: 0.9408265 (12.279dB)
x264 core:148 r2643 5c65704
veryslow
encoded 313 frames, 16.12 fps, 801.52 kb/s, SIM Mean Y:0.9335760 (11.777db)
URLﾘﾝｸ(www.dotup.org)
770:名無しさん＠編集中
16/01/31 01:35:17.36 cgqklV4a.net
>>748
slow slowerの高速化がすごい
771:名無しさん＠編集中
16/01/31 02:31:21.15 UHx+fRoe.net
ああ、俺もベンチするスクリプトを Ruby で書いてみたりしてたけど
最近やってなかったな。。。で久々にやってみたたら比較対象が 1.6 の medium しかなかったｗ
URLﾘﾝｸ(i.imgur.com)
772:名無しさん＠編集中
16/01/31 13:41:59.34 txIOJs0s.net
>>748
slowerがビットレート下がりすぎてSSIMもそれに引き摺られちゃってるね
でも倍も速度でてる
773:名無しさん＠編集中
16/01/31 16:07:20.48 cFXQSVbu.net
プリセット内容が変わったんじゃなかった？
774:名無しさん＠編集中
16/01/31 18:33:49.97 tisPGxzA.net
>>752
たしかあったな…
775:名無しさん＠編集中
16/01/31 18:53:54.26 TP98Z0n+.net
たしかにプリセット変更で旧プリセットと同じビットレートでのSSIM落ちたけどちょっとしか落ちてないしその分早くなってるからいいや
あとveryfastなんかだと速度も上がってSSIMも上がってたりする。
776:名無しさん＠編集中
16/01/31 20:01:42.34 FzlptxAC.net
x265は今後もCPUのみの演算で貫くのかね？
GPUのメモリーがHBMやHBM2の導入でかなり速くなるし、バス速度や演算能力そのものも上がろうとしているわけだが、
相変わらず一部だけでもGPUに振り分けるよりCPUのみのほうがいいのかね？
777:名無しさん＠編集中
16/01/31 20:07:08.49 cFXQSVbu.net
x265の開発元が新しいコンパイラHCCの開発をするみたいだから
ヘテロジニアス対応は案外、早いかもしれない
778:名無しさん＠編集中
16/01/31 20:24:55.92 o77Jhxsk.net
>>755
P
779:CIeの遅さが何とかなれば、じゃないかな NVIDIAのNVLinkは一般PC環境では期待できないみたいだし AMDもなんか高速バスかなんかやっているみたいだけど普及するかわからない
780:754
16/02/02 13:26:49.31 NCVy8Op8.net
>>756-757
HBM2がメインストリームのCPUやAPUに採用される日
URLﾘﾝｸ(pc.watch.impress.co.jp)
この記事によるとHBM2がコストダウンすれば一般向けのPC環境でも利用できるようになる可能性はあるようだから、あとはコストとバス速度の問題がなんとかなればいいのかも。
いつまでもCPUオンリーって時代でもないだろうし。
781:名無しさん＠編集中
16/02/02 14:53:24.44 oWE9M/3S.net
>>758
HBMは容量と帯域ばかりの記事が多かったけどレイテンシも低いんだな
じゃないとグラボ向けに積まれないか
782:名無しさん＠編集中
16/02/02 19:03:54.47 NCVy8Op8.net
GPUって大抵2スロット専有するんだから、PCI-Exスロットも2スロット挿しにして2倍速いってなわけにはいかないのかなと妄想。
783:名無しさん＠編集中
16/02/03 15:02:46.32 juHubKYm.net
>>760
っ [SLI]
784:名無しさん＠編集中
16/02/03 17:41:33.40 +OWBi5Bj.net
Android版とかiOS版のx265なんて出ないものなのかね？
785:名無しさん＠編集中
16/02/03 18:20:21.38 63ziqI0j.net
バッテリで動く端末との相性は最悪だろ
786:名無しさん＠編集中
16/02/03 18:34:18.04 +OWBi5Bj.net
>>763
なんで？
ちょこっとしたビデオクリップを編集後にエンコードまで出来たら、外出先で重宝しそうなものだが。
USB給電がこれだけ普及し、iPad proみたいなのまで出てくると、エンコードくらい多少時間がかかってもモバイル機器でできたほうが消費電力的にもうれしいわけだが。
787:名無しさん＠編集中
16/02/03 18:36:25.29 xdk3hERs.net
ちょっと何言ってるか分かんない
788:名無しさん＠編集中
16/02/03 18:38:36.07 iehiN48C.net
x265はともかくカメラの画像をエンコードしてるチップにデータ送ってエンコードできたらなどと思うことはあるw
789:名無しさん＠編集中
16/02/03 20:06:23.57 stWNn/Ef.net
最近リリースされたx265どう？
良ければコンパイルし直そうかと思ってる
790:名無しさん＠編集中
16/02/03 20:30:41.98 3wA6RKbD.net
たかがビルドで人に聞かないと動けないって・・・
791:名無しさん＠編集中
16/02/03 21:05:22.98 yXDm8y7+.net
rigaya 氏の multilib ビルドバッチでビルドは楽させて頂いているｗｗ
ありゃ楽だ
792:名無しさん＠編集中
16/02/04 09:38:26.30 T7nDHZT/.net
>>764
その時間かかるって何日かかるんだ
モバイル用の非力CPUでのソフトエンコで
専用チップのエンコードならともかく
793:名無しさん＠編集中
16/02/04 11:37:30.45 +3HectuX.net
朝鮮人に句点は難しい。
794:名無しさん＠編集中
16/02/04 14:41:30.65 J/9ovht0.net
実際どのくらい差あるのかな？
i5 6600とsnapdragon801で50倍差くらい？
795:名無しさん＠編集中
16/02/04 14:50:52.72 +3HectuX.net
一部でもハードウェアの支援機能が使えればだいぶと話は変わるだろうね。
こんな記事もあるわけだし。
・ iPad Proは本当に4Kビデオ編集に使えるのか!? ガチ検証
URLﾘﾝｸ(av.watch.impress.co.jp)
796:名無しさん＠編集中
16/02/04 22:37:23.84 M4vC7LHq.net
ffmpegでx265のハードウェアエンコードってもうサポートされてる？
QSVでできるとありがたい＞IvyBridge使いとしては
797:名無しさん＠編集中
16/02/04 22:57:03.08 T7nDHZT/.net
？
798:名無しさん＠編集中
16/02/05 07:51:11.13 NlSCducd.net
x265はソフトエンコのためのソフトだ
ハードウェアエンコなどサポートされるわけがない
h.265(規格名 HEVC)とx265(ソフト名)の区別がついてないんだろうけど
QSVは固定回路
後からHEVC対応などできん
QSVでHEVC対応したのはSkylakeから
QSVでHEVC使いたいならSkylakeに買い換え
799:名無しさん＠編集中
16/02/05 12:12:20.92 35jGb+Wd.net
QSVは完全固定じゃないけどな。
800:名無しさん＠編集中
16/02/05 13:03:43.84 LD2LJSnr.net
コマンドラインからQSV使いたいんだろう。
まあH.265のスレに行くといい。
801:名無しさん＠編集中
16/02/05 13:40:15.88 nrq1jwhr.net
さらにソフトが対応しなきゃならんし
無知のドヤ顔知ったかはほんとどうにもならんといつも思う
802:名無しさん＠編集中
16/02/05 22:18:13.16 cHw5jbd1.net
>>776
Oh。。。そういうことなのね
しらんかったわ
H.264のハードウェアエンコで悦ってくるわﾉｼ
803:名無しさん＠編集中
16/02/17 00:08:44.49 q2blbE92.net
↓こちらの動画配信解説サイトを参考に
URLﾘﾝｸ(pecardy.vanu.jp)
ffmpeg.exe -re -rtbufsize 256MB -flags +global_header -r 30 -s 1708x960
-f dshow -i video="SCFF DirectShow Filter":audio="ライン入力 (Realtek High Definition "
-threads 0 -r 30 -s 854x480 -vcodec libx265 -tune zerolatency -preset fast -b:v 318k
-af aresample=async=1 -acodec libfdk_aac -ar 48000 -b:a 32k -ac 2 -vol 450
-profile:a aac_he_v2 -f matroska
というエンコードをしていますがどうも画質がx264よりも若干劣る気がして仕方がありません。
本来ならx265はx264の半分のビットレートで同等の画質を実現できるはずなのですが・・・
オプションの指定方法とかで改善すべき箇所とかありますか？
ちなみにPCスペックにはまだ余裕があるのでもう少し負荷がかかる
オプションでも問題無いと思います。
ちなみにx264は以下の様なオプションでエンコードしていました：
ffmpeg.exe -rtbufsize 256MB -r 30 -s 1708x960 -f dshow
-i video="SCFF DirectShow Filter":audio="ライン入力 (Realtek High Definition "
-threads 0 -r 30 -s 854x480 -sws_flags lanczos -pix_fmt yuv420p -vf "unsharp=3:3:0.5"
-b:v 636k -maxrate 636k -bufsize 636k -vcodec libx264 -preset veryslow -profile:v high
-x264opts "me=umh:ref=5:bframes=3:trellis=1:subme=8:keyint=250:qpmin=0:qpmax=69:rc-lookahead=50:min-keyint=25"
-async 100 -acodec libfdk_aac -profile:a aac_he -signaling implicit -afterburner 1
-ar 48000 -ab 64k -ac 2 -vol 450 -f flv
804:名無しさん＠編集中
16/02/17 00:24:39.26 ctq6s7UU.net
ffmpeg も HandBrake もそうだけど、libx265 使うとそういう傾向になるみたいだね。
このスレの話しに紐付けるなら x265 で HEVC エンコしてみたらどうだろう。
ffmpeg で demux して動画部分を x265、音声部分を neroaac なりかまして
最後 remuxer 通すなり mp4box で mux すれば良い。
805:名無しさん＠編集中
16/02/17 00:52:00.93 LHOUYy6V.net
>>781
x265のfastとx264のveryslowだしなあ…
もう大分前のデータだしプリセット変更入ったからそこまで参考にはならないけど、
この辺のグラフ見れば必ずしもビットレート半分で同等の画質にはならないのが分かるはず。
>>302
>>365
>>381
>>406
807:名無しさん＠編集中
16/02/17 13:59:46.42 SngcRS/c.net
>>781
-tune zerolatency これやめたらどう？
808:名無しさん＠編集中
16/02/17 14:39:11.08 UvZou3Zff
ビットレート半分で同等の画質っていう謳い文句はx265のエンコード時間を度外視してx264と比較した場合の話でしょ
x265は複雑でx264で出来なかったような処理をする分時間が掛かるけどビットレートは少なくて済むってだけの話
x265の処理を簡単にしてx264と同じような速度でエンコードさせたら縮まないのは当然だと思う
809:名無しさん＠編集中
16/02/17 20:30:34.56 5I7ClG3n.net
>>781
主観だと画質が分かりにくいのでSSIMとPSNRを参考にしてオプションを弄れば良い
やり方はテスト動画を用意してそれをx264とx265でエンコする
エンコ前の動画とエンコ後の動画を比較してSSIMとPSNRを出力する
そのデータを参考にしてffmpegのオプションを組み立てていく
SSIMとPSNRを出力するffmpegのコマンドはこんな感じ
ffmpeg -i エンコ前の動画 -i エンコ後の動画 -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
810:780
16/02/18 00:12:09.35 EKbwhu+3.net
皆さんアドバイスありがとうございますm(_ _)m
presetのfast/veryslowとか結構違いが効いてきそうですね。
slowにしてみたところ画質がだいぶ向上した気がします。
ただ負荷が高いのかエンコ配信中は画面がカクカクしてしまいましたが。
mediumくらいで折り合いを付けようかと思います。
> -tune zerolatency
このオプションは音ずれ防止用に入れました。
画質となにか関係ありますか？
> 主観だと画質が分かりにくいのでSSIMとPSNRを参考にしてオプションを弄れば良い
SSIM・PSNRは始めて聞きました。
x265から加わったオプションでしょうか。
画質に影響するオプションの用なのでちょっと調べてみようと思います。
あと>>781のx265オプションで配信テストをしていたところ、Windows10付属のWMPでは
画面が灰色になって再生できなかったけどVLC Media Playerでは正常に再生できたという
報告がありました。
811:名無しさん＠編集中
16/02/18 00:21:20.69 bnH8mLRR.net
言っておくけどSSIMやPSNRはあくまで「数字の上での正確性」だから、それだけを鵜呑みにしないように
個人的にはオプションよりビットレートをもっと盛るのを最初にするべきかと
-b:v 518kぐらいでやってみては？
（もっともx264ので画質・容量的に満足できるならx264でいいと思うけど）
812:名無しさん＠編集中
16/02/18 01:05:06.98 hHEKfc2c.net
>>787
>> -tune zerolatency
>このオプションは音ずれ防止用に入れました。
音ズレ防止にはならない。配信のラグを軽減するだけ
>画質となにか関係ありますか？
zerolatency no lookahead, no B frames, no cutree
( URLﾘﾝｸ(x265.readthedocs.org) )
私はすごく関係あると思うんですが。
813:名無しさん＠編集中
16/02/18 09:11:42.49 Z9lL4Edt.net
やっぱ配信用設定はBフレーム削っちゃうんだね
NVENCのHEVCみたいだ
814:名無しさん＠編集中
16/02/18 11:06:46.21 nlO5v3H8L
>>787
配信中カクカクするのは当然
お察しの通り負荷が高いから
要するにそれは配信する映像のフレームレートにエンコードのスピードが追いついていない
例えば30fpsの映像を配信しようとしてもエンコードできる速度が10フレーム/秒とかだったら20フレーム足りないわけで当然止まる(それかどんどん遅れていく)
PSNRもSSIMもx264の時代からある
ようするにエンコード前の元動画と比較してどれくらい差が出たかっていうのを数値化して表現するもの(テストの採点みたいな感じ)
しかし機械的に判断した上での数値だから実際の目で見たときに数値ほど綺麗 or 綺麗じゃないということも起こりうる
Bフレーム由来の音ズレ(確か数フレーム音が遅れる)現象はx264の時代からあるはずだけどぶっちゃけ見てて気になるほどではないはず
しかもBフレームを使わないとなると圧縮率は結構下がるから必要なビットレートは多くなってしまう
長くなったけど正直配信用途なら大人しくx264使って配信したほうが良いと思う
現状x264と比較してx265は遅すぎる上に視聴者側にコーデックの導入してもらわないとそもそも見えない場合もある
x264並みに速くしてしまったら結局x265の旨みである「低ビットレートでも高画質」ってのは実現しにくくなると思う
815:名無しさん＠編集中
16/02/18 17:44:58.53 xYEflaB1.net
>>787
テスト用の動画を用意してinput.mp4ってファイル名にして下のコマンドをbatファイルに入れて実行してみ
ffmpeg -i input.mp4 -c:v libx265 -b:v 1000k -preset fast -an -f matroska output.mkv
ffmpeg -i input.mp4 -i output.mkv -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
pause
ffmpeg -i input.mp4 -c:v libx265 -b:v 1000k -preset fast -tune zerolatency -an -f matroska output.mkv
ffmpeg -i input.mp4 -i output.mkv -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
pause
pauseの所で止まるからSSIMとPSNRを確認できる
-tune zerolatency無しのコマンドのSSIMとPSNR
[Parsed_ssim_0 @ 056f7ee0] SSIM Y:0.973342 (15.741661) U:0.987857 (19.156803) V:0.987214 (18.932536) All:0.978073 (16.590190)
[Parsed_psnr_1 @ 050a8dc0] PSNR y:36.989533 u:46.248371 v:45.899587 average:38.421691 min:24.789515 max:inf
-tune zerolatency有りのコマンドのSSIMとPSNR
[Parsed_ssim_0 @ 05947f40] SSIM Y:0.971439 (15.442303) U:0.987953 (19.191359) V:0.987271 (18.951983) All:0.976830 (16.350782)
[Parsed_psnr_1 @ 052f7d80] PSNR y:36.171702 u:46.200393 v:45.728706 average:37.641917 min:22.273266 max:inf
SSIMもPSNRも数値が大きい方が画質が良いので
-tune zerolatencyは付けない方が画質が良いという事がSSIMとPSNRを使えば簡単に分かるわけだ
816:名無しさん＠編集中
16/02/18 18:13:49.28 xYEflaB1.net
ちなみにどの数値を見れば良いのかと言うとSSIMはAllの数値、PSNRはaverageの数値を見て比較してくれ
あとテスト用の動画はmp4じゃなくてもmkvでもtsでも何でも良い
817:名無しさん＠編集中
16/02/19 18:44:02.46 4YDtVCyu.net
mac用multibitビルド
自分用メモ
TARGET="/sw"
CMPL="/Volumes/Ramdisk/compile"
mkdir -p ${TARGET}
mkdir -p ${CMPL}
#x264 8bit 10bit 12bit混合バイナリーbuild
cd ${CMPL}
mkdir -p 8bit
mkdir -p 10bit
mkdir -p 12bit
#12bit build
cd ${CMPL}/12bit
hg clone URLﾘﾝｸ(bitbucket.org)
cd x265
cd source
cmake -DHIGH_BIT_DEPTH=ON -DMAIN12=ON -DEXPORT_C_API=OFF -DENABLE_CLI=OFF -DENABLE_SHARED=OFF && make -j 8
#10bit build
cd ${CMPL}/10bit
hg clone URLﾘﾝｸ(bitbucket.org)
cd x265
cd source
cmake -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_CLI=OFF -DENABLE_SHARED=OFF && make -j 8
#8bit build
cd ${CMPL}/8bit
hg clone URLﾘﾝｸ(bitbucket.org)
cd x265
cd source
#12bit 10bit staticを8bitで読めるように移動
mv ${CMPL}/12bit/x265/source/libx265.a ${CMPL}/8bit/x265/source/libx265_main12.a
mv ${CMPL}/10bit/x265/source/libx265.a ${CMPL}/8bit/x265/source/libx265_main10.a
cmake -DCMAKE_INSTALL_PREFIX:PATH=${TARGET} -DHIGH_BIT_DEPTH=OFF -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON -DENABLE_SHARED=OFF && make -j 8
mv libx265.a libx265_main.a
#12bit 10bit 8bitstaticを混合
libtool -static -o libx265.a libx265_main.a libx265_main10.a libx265_main12.a 2>/dev/null
make install
818:名無しさん＠編集中
16/02/19 18:46:36.53 4YDtVCyu.net
書き忘れ
ffmpegで使うときは、output-depthじゃなく
-pix_fmt yuv420p10le
-pix_fmt yuv420p12le
で指定
819:780
16/02/19 22:23:59.21 pxdW5hFs.net
>>792
ありがとうございます。
早速SSIM/PSNRの数値を調べてみました。
たしかに皆さんがおっしゃるとおりzerolatencyを付けない方が
SSIM/PSNRの数値は上でした。
しかし今まで画質の善し悪しは主観的に判断するしか無いと思っていましたが
こうやって数値で確認する事もできるんですね。
いろいろパラメーターを変えつつSSIM/PSNRの数値を見て最適なポイントを
探してみようと思いますm(_ _)m
820:名無しさん＠編集中
16/02/19 23:27:22.99 9715NWZX.net
指標は便宜上使われてるだけで基本は主観で判断だと思うよ
コンピューターが許容できる違いと人間が許容できる違いは同じではないからね
821:名無しさん＠編集中
16/02/19 23:40:15.58 qSH2klIW.net
あと多分-tune ssim付けて比較しないと意味ない
822:名無しさん＠編集中
16/02/20 10:10:44.80 YhMIaURA.net
主観で判断なんてほぼ無理だろう
これができるならそれで飯が食べられる
まぁ、どこで妥協するかだろう
823:名無しさん＠編集中
16/02/20 11:04:23.50 K6y5yssU.net
あくまで指標
数値で画質が決まるならx264（例として）でpsnrやssimなんてtune作る必要がないからね
824:名無しさん＠編集中
16/02/20 11:37:36.59 k+agU2Eu.net
主観で判断出来ないなんて可哀想な人
825:名無しさん＠編集中
16/02/20 11:49:29.89 YhMIaURA.net
よっぽど悔しかったのかな
公式でも使われて、急にダンマリしちゃった人がいたな
826:名無しさん＠編集中
16/02/20 11:54:48.37 sO+hYrhk.net
自分の場合は最初に目で見て、これビットレート半分で画質同等って大げさじゃね？と思ってSSIM調べたらその通りだったって話だから順序逆なんだよな
827:名無しさん＠編集中
16/02/20 12:06:07.01 SpT3cwNh.net
極端な話見ている人にバレなければ元と全然別物でも問題無い
828:名無しさん＠編集中
16/02/20 12:22:21.53 K6y5yssU.net
基本は、「見てる人=自分だから」好きなようにとしか言いようがない
だけどわざわざ--tune psnrやらssim使って本番エンコする奇特な人もいるんだなと不思議に思ってる
829:名無しさん＠編集中
16/02/20 13:55:57.50 EIhIWuJR.net
本番エンコで使うなんて誰も言ってないような・・・
830:名無しさん＠編集中
16/02/20 14:49:46.80 K6y5yssU.net
たしかに・・
「最後は主観」を否定する人かと思って短絡的に書いたは
831:名無しさん＠編集中
16/02/20 16:02:15.78 BHDZ19yf.net
-tune psnrとssimは心理視覚を向上させるオプションを無効になり主観的な画質が悪くなるので使わない方が良いみたい
心理視覚と言うのは例えば人間の目で見て画質の違いが分かりにくい部分の画質を悪くして違いが分かりやすい部分の画質を良くすることで
同じビットレートでも主観的な画質が良くなるみたい。だけどSSIMとかPSNRは画質の違いが分かるので数値が低くなるようだ。
832:名無しさん＠編集中
16/02/26 10:29:06.48 i7aFZYs7.net
ssimでだいたい当たりを付けて、psy関連で仕上げじゃないのか？
x264もx265もかなり練り上げられてるから、俺にはssim無しの判断は無理だわ
ssimの0.001の違いなんて目で区別できん
シーンごとに同一フレーム拡大確認なんてなおさら
最後は主観で判断と言うより、好み次第じゃない？
833:名無しさん＠編集中
16/02/26 10:59:27.59 iu0kmo+a.net
それを主観で判断すると言うんじゃ
834:名無しさん＠編集中
16/02/26 12:24:00.84 ykLbS11Bg
自分の場合SSIMは0.98あたりにもなると主観で元の動画との区別が付かない画質になるからそれを基準にしてる
835:名無しさん＠編集中
16/02/26 16:24:08.79 i7aFZYs7.net
そうなのか
なら、語る余地無しだな
てっきりssimに頼らず目視でエンコ精度を判断してるのかと思った
12bitの効果はどう？
836:名無しさん＠編集中
16/02/26 16:35:14.80 bHaTV8wK.net
普段10bitでやっとるけど12bitにしてみたところで違いが分からなかったよ。
837:名無しさん＠編集中
16/02/26 17:41:29.90 m+0FG1+N.net
ID:i7aFZYs7
主観の意味分かってないの？
838:名無しさん＠編集中
16/03/09 17:54:53.68 imJr87Pl.net
x265vfwも出てるやん
URLﾘﾝｸ(sourceforge.net)
l
839:名無しさん＠編集中
16/03/09 18:23:15.11 qNQxWU8R.net
今時vfwなんてメリットあんのかね？
エンコ詳しくないニコ厨でもwiki見て簡単にmp4エンコできるのに
840:名無しさん＠編集中
16/03/09 18:29:23.70 9Y8nZSW1.net
関わるな
841:名無しさん＠編集中
16/03/13 09:20:31.95 weseHvkQ.net
rc-grainの効果はどう？
あまり効果を実感できない
842:名無しさん＠編集中
16/03/20 08:39:40.31 7J9mixui.net
最近完走しなくなった。
皆さんどうです？
OS入れ直して駄目ですので、x265疑ってるんですが。
どこのビルドも1.9は駄目な感じです。
843:名無しさん＠編集中
16/03/20 10:04:28.56 KHVZBQe4.net
エスパーさん出番ですよ
844:名無しさん＠編集中
16/03/20 11:38:36.85 dlNvEFCk.net
>>819
ちゃんと完走してるよ
muxerを最新のに変えてみるとか
845:名無しさん＠編集中
16/03/20 15:51:11.82 16IrSqAm.net
>>819
avisynthでMT使ってるとエスパーしてみる
846:名無しさん＠編集中
16/03/20 20:06:27.41 nKj/TuoV.net
MUXではなくエンコード自体が完了しないのです。
avisynthはMT使わずソース読ますだけの最小構成です。
皆さん問題ないんですね。
とりあえず自分の構成をもっと疑ってみます。
止まるのが規則性があったり無かったり意味不明なんですよね。
同じソースで3%数回続いた後、70%で止まったりorz
847:名無しさん＠編集中
16/03/20 20:40:06.24 Fu5UyCAR.net
短いソースで試してみたら
848:名無しさん＠編集中
16/03/20 22:59:05.03 oLphnsNe.net
そういう時はmemtest
自分の環境よりソフトの方を疑うというのが理解できない
849:名無しさん＠編集中
16/03/20 23:51:09.20 mbWz3Yxf.net
aviでエンコードしてからx265でエンコードは？
850:名無しさん＠編集中
16/03/21 09:44:15.65 PdR6lJIR.net
メモリテストはwin付属ので問題なかったのと、
OS入れ直し、avisynth入れ直しくらいはしました。
ソースも変えてます。
30分位のソースだとごくまれに完走します。
11月くらいまで動いてたのでハードはそこまで疑いたくないのですが。
851:名無しさん＠編集中
16/03/21 10:48:22.93 W3zX88FD.net
>>827
そうやって821が言うような定石を守らないから
切り分けができないんだと思うよ
まぁ仮にmemtestで落ちても
原因はメモリとは限らないんだけどね
852:名無しさん＠編集中
16/03/21 10:58:42.48 EJTslGgf.net
完走する事もあるならソースかハードの問題でしょ
頭おかしい
853:名無しさん＠編集中
16/03/21 11:15:49.32 IwyEIcSu.net
フルボッコで可哀想だからレスするけど
aviutl + x265guiでやってみたら？
854:名無しさん＠編集中
16/03/21 15:07:19.74 +Ik+xhI4.net
1.9で中途ファイルが出来たというのはうちでもあったな
以前の構成から変わったのってそこぐらいだから1.9の所為なんだろうなとは思った（リトライしたら通ったけど）
855:名無しさん＠編集中
16/03/21 17:40:19.97 U+Xdgxb4.net
同じ条件で上手くいく時といかない時があるって、ハード側が不安定なだけじゃね？
ソフト側の問題なら再現性はもっと高いと思うが
856:名無しさん＠編集中
16/03/21 18:39:37.32 +Ik+xhI4.net
ログ見たらフレームの入力に失敗してるっぽいな
avs側でYV12に変換してやると多分解決する
857:名無しさん＠編集中
16/03/21 20:18:58.92 3MEwZrZM.net
今は完走しないことについての話なのになんで入力の話してるんだよ
途中で色空間が変わってるとしたら
858:完全にスクリプトの問題じゃねーか
859:名無しさん＠編集中
16/03/21 20:41:01.66 Y85ZQ3tt.net
>>827
handbrakeかffmpegで試してみれ
860:823
16/03/21 21:38:39.05 vZIwSY4R.net
とりあえず、OS再インストールしてみた。
AVISYNTH+にしてみてもおちたorz
memtestは明日出勤の間してみる。
ここらで構成とログ（一部)さらし
Win10 1511
CPU i7 5820k 定格3.3Ghz
MEM DDR4 32gb 定格2133mhz
以下で止まる。
avs [info]: AviSynth+ 0.1 (r1576, x86)
avs [info]: Video colorspace: YV12
yuv [info]: 1920x1080 fps 24000/1001 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.9+73-6d06de58c3163c19
x265 [info]: build info [Windows][MSVC 1800][64 bit] 10bit
x265 [info]: Compiling by KG7x [x265.ru]
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 12 threads
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)+pmode+pme
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut : 23 / 300 / 40
x265 [info]: Lookahead / bframes / badapt : 30 / 3 / 2
x265 [info]: b-pyramid / weightp / weightb : 0 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / 0 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.50
x265 [info]: VBV/HRD buffer / max-rate / init : 8000 / 7770 / 0.900
x265 [info]: tools: rect limit-modes rd=4 rdoq=2 signhide tmvp
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
[1.0%] 1873/187296 frames, 5.52 fps, 1540.73 kb/s, eta 9:19:48
861:823
16/03/21 21:45:05.55 vZIwSY4R.net
>>835
ソース読みをavisynth使わず読み込みをってことですか？
862:名無しさん＠編集中
16/03/21 21:58:07.85 IwyEIcSu.net
>>836
とりあえずビルドに使われてるVisual Studio 2013のランタイム入れてみたら？
配布元に↓とも書かれてるし（意味わからんけど）
Turbo on Monday February 10th, 2014 at 06:16 PM said:
Сборки сделаны на Visual C++ 2013. Для корректной работы может потребоваться библиотека Visual C++ Redistributable Packages for Visual Studio 2013:
863:名無しさん＠編集中
16/03/21 23:05:25.98 diV0PO6C.net
pmode,pmeを無効にしてみるといいよ
同じような症状出てたけど、無効にしたら落ちなくなった
864:823
16/03/21 23:23:35.03 vZIwSY4R.net
とりあえず、>>838のランタイム入れてやってみてます。
>>839はその後改善がなかったら試してみます。
865:823
16/03/22 07:06:01.47 1A+V4fFh.net
>>838
ありがとうございます。
いきなり長時間物完走しました。
�
866:ｽ回か違うソースで試してみます。
867:823
16/03/31 22:20:13.67 OoJQ2UyX.net
10ソースくらい試してみましたが、
無事完走するようになりました。
皆様ありがとうございました。
868:名無しさん＠編集中
16/04/01 14:07:26.74 vYfELI/A.net
てかどこのビルドも駄目だと書いてるのにMSVCが原因だなんて普通思わねえよ
869:名無しさん＠編集中
16/04/01 16:49:59.34 dTL/+QgY.net
トラブルシューティングとしてビルドに使われたVCランタイムを入れるぐらいはしてもばちは当たらない
870:名無しさん＠編集中
16/04/02 09:22:23.23 CqXSpfM9.net
>>844
お前がはじめにそういえばよかった。
834だったらすまん。
871:名無しさん＠編集中
16/04/02 09:55:23.23 1E+gnV9U.net
>844も>838も同じ人物で私だけど
態度変えすぎだろう
872:名無しさん＠編集中
16/04/04 08:51:12.73 PHD6aaQD.net
YUV420ソースをYUV444にしてエンコするメリットはありますか？
873:名無しさん＠編集中
16/04/04 08:53:20.36 nVqmW/e9.net
どうして無いと思うわけ
874:名無しさん＠編集中
16/04/04 14:52:19.93 Gj1hPCli.net
どうしてあると思うわけ
875:名無しさん＠編集中
16/04/04 19:46:56.63 PHD6aaQD.net
>>848
有るとも無いとも言ってないですよ。
ぜひ、YUV420ソースのYUV444へのエンコを解説してください。
876:名無しさん＠編集中
16/04/04 20:08:35.41 GIgTDtel.net
自分で試せないの？
877:名無しさん＠編集中
16/04/04 20:14:10.84 aOfeiP7X.net
ファイル作って動画を見て、よくなっていたら採用、変わらないor悪くなっていたらやらない、でいいじゃない
エンコの目的なんて、自分が見るための保存用がほとんどだろうし
878:名無しさん＠編集中
16/04/05 02:19:50.59 /L9IqKot.net
目が肥えて後になって後悔するかもしれない
という発想がどうしてないのだろう・・・
879:名無しさん＠編集中
16/04/05 03:10:52.86 VRuHp+46.net
なんでこの流れでそんなズレた発想が出てくるんだろう・・・
880:名無しさん＠編集中
16/04/05 07:24:52.25 23Tspq3D.net
元ファイル(生TS?)も保存しておけばいいんじゃね？
881:名無しさん＠編集中
16/04/05 07:39:04.16 /18GblFb.net
エンコするために勉強する時間よりその時間で稼いでHDD買ったほうがいい
オリジナルのまま保存しとけば将来目が肥えても安心
882:名無しさん＠編集中
16/04/05 08:02:56.95 PkW1ygDm.net
趣味を否定してやるなよ
883:名無しさん＠編集中
16/04/05 15:04:07.31 9JEcOI0a.net
話をそらして質問者の否定ばかりで、誰も解説できない
おまら情けないな
まぁ、俺もだけどな
884:名無しさん＠編集中
16/04/05 15:54:06.00 oIluhigo.net
ソースが8ビットなんだから10ビットでエンコしても無意味って口？
885:名無しさん＠編集中
16/04/05 16:14:30.97 bXKjBZbc.net
>>850
> YUV420ソースのYUV444へのエンコ
・環境やプレーヤーによっては再生できなくなる。再生支援も効かない。
・データ量が増える。
・やるにしてもYUV420→YUV444変換で色差補間をどうすんのかとかちゃんと考えないといかんね。
やるだけアホらしいと思うけど。普通はYUV420のまま再生時にレンダラで補間させるし。
・つうことでメリットなんか無いだろ。
>>858
自演乙
>>859
そんな話は誰もしてねーと思うぜ。
886:名無しさん＠編集中
16/04/05 16:26:50.63 oIluhigo.net
同じこと
887:名無しさん＠編集中
16/04/05 20:35:58.64 9JEcOI0a.net
>>860
妄想乙
888:名無しさん＠編集中
16/04/05 20:44:23.74 +zekPSej.net
>>856
勉強ったってオプション弄ってできたものを評価していくだけじゃん
889:名無しさん＠編集中
16/04/05 22:25:10.00 DXAVhdGx.net
12bit エンコすんのはいいんだけど、どういう環境で見れば軽いとか綺麗とかってだれか試してるんかな
つか、みんなどのプレイヤーで見てんの？
890:名無しさん＠編集中
16/04/06 00:21:04.15 gavek0iz.net
>>864
12bitの
891:HEVCデコードに対応してるデコーダなんてLAVくらいじゃね。 デコーダからP016でレンダラに渡すことを考えるとmadVRかMPDNあたりが必要。 LAVで12bitYUV→RGB24変換してRGBでEVR等のレンダラに渡す方法もあるけど この場合色差補間とかがどうなるのかは知らん。 12bitは再生支援も対応しないだろうし、一般的な1667万色なPC環境では10bitで事足りるはずだし 10bitに比べてなにかメリットはあるのかね？
892:名無しさん＠編集中
16/04/06 06:58:25.58 BZiOzY8Z.net
的はずれな事ばかり
まず試してみなよ
感動するぞ
893:名無しさん＠編集中
16/04/06 09:34:00.56 oAh+1FS4.net
x264では444円個のほうがssimはよかった
なんでかはしらんけど、x265ではそうとは言えなかった
12bitは保存用に使ってるな
894:名無しさん＠編集中
16/04/06 19:13:30.16 LlUg6G6o.net
>>866
もしかして12bitエンコ自体やったことないか、プラシーボで喜んじゃうタイプ？
895:名無しさん＠編集中
16/04/06 20:01:05.75 cKZ87zcu.net
8bitと10itでは結構、良くなるから
10bitから12bitも多少は良くなるんじゃね
896:名無しさん＠編集中
16/04/06 21:36:40.18 TIHK3iW4.net
--aq-strength, --psy-rd, --psy-rdoqは調整次第で
大幅な容量orエンコ時間の増大なしで見た目をよくできると思うんだけど
それぞれ値を増やすとどういったところに変化が表れやすいか
教えてくれないかい
URLﾘﾝｸ(x265.readthedocs.org)
を読んだがpsyは読んでもよくわからんかった
897:名無しさん＠編集中
16/04/06 21:42:52.17 CpSN4L84.net
ソース： 1280x720、3501frames、8bitソースをAvisynthのf3kdbで16bitYV12化したもの
x265(1.9+88 x64)で2パスビットレート指定エンコ
--input-csp i420 --input-depth 16 --input-res 1280x720 --frames 3501 --fps 30/1
--preset medium --tune ssim --ssim --output-depth xx --pass x --bitrate xxx
300kbps
8bit： 300.77 kb/s, SSIM Mean Y: 0.9570205 (13.667 dB)
10bit： 300.30 kb/s, SSIM Mean Y: 0.9585213 (13.822 dB)
12bit： 299.67 kb/s, SSIM Mean Y: 0.9569896 (13.664 dB)
600kbps
8bit： 598.95 kb/s, SSIM Mean Y: 0.9736639 (15.794 dB)
10bit： 598.72 kb/s, SSIM Mean Y: 0.9751736 (16.051 dB)
12bit： 599.01 kb/s, SSIM Mean Y: 0.9747219 (15.973 dB)
1000kbps
8bit： 995.32 kb/s, SSIM Mean Y: 0.9803979 (17.077 dB)
10bit： 994.48 kb/s, SSIM Mean Y: 0.9815939 (17.350 dB)
12bit： 995.49 kb/s, SSIM Mean Y: 0.9818127 (17.402 dB)
2000kbps
8bit： 1982.79 kb/s, SSIM Mean Y: 0.9854730 (18.378 dB)
10bit： 1985.28 kb/s, SSIM Mean Y: 0.9870154 (18.866 dB)
12bit： 1984.48 kb/s, SSIM Mean Y: 0.9870380 (18.873 dB)
3000kps
8bit： 2974.32 kb/s, SSIM Mean Y: 0.9874125 (19.001 dB)
10bit： 2970.46 kb/s, SSIM Mean Y: 0.9888551 (19.529 dB)
12bit： 2972.63 kb/s, SSIM Mean Y: 0.9889059 (19.549 dB)
SSIMで見る限りでは、12bitは低ビットレートでは10bitに劣り、高ビットレートでも10bitと大差ないな。
898:名無しさん＠編集中
16/04/06 22:26:08.63 BZiOzY8Z.net
めくら
いや無能ってとこかな
899:名無しさん＠編集中
16/04/06 22:38:06.12 cKZ87zcu.net
>>870
自分はx265では圧縮率を求めて割とどうでもいいソースにしか使ってないからザルなテストしかしてないけど
x264ほど素直に画質に反映されず分かりづらい（まあ、それだけ優秀になってるってことなんだろうけど）
ベースになってるであろうx264の感じでは
AQ 人の肌などのアラ隠しに有用
psy-rd 動くエッジとか高周波部分が削られる
qcomp 何気に重要。大きくするとグレンから動く対象の再現性など画の完成度がとにかく高まる
だからAQはデフォ、psy系は低め、qcompは心なし上げて0.65で使ってる
最初に書いたけど画質は求めてないから期待しないで
900:名無しさん＠編集中
16/04/07 19:37:26.46 5GOclDJK.net
>>873
thx!
自分はqcompを0.75で使ってた
自分でも適当なソースで簡単な比較はしたけど、
AQ：上げると画質は向上したけど容量も増えた（x264ではそれほど増えた印象無）
psy-rd：上げると容量が少しだけ増えた（x264のほうが増加量が大きい印象）
psy-rdoq：上げるとソース由来の細かい部分が残るようになった
くらいしかわからんかった
2passでビットレート固定すると、SSIMは（見る意味があるかは置いといて）
AQとrdoqは極大値があったけど、rdは上げると下がる一方
よくわからんです
901:名無しさん＠編集中
16/04/07 20:14:01.22 xaya07W/.net
G11bitB10bitR11bitなら良いのにね。
902:869
16/04/07 21:37:16.65 kTK9FIEO.net
>>874
「だからAQは～」の行はx265での設定ね
ほぼ固定された動画だと面白いように縮むから使ってるけど
画質評価は本当に難しくなってるよね
903:名無しさん＠編集中
16/04/08 10:10:35.33 Rwrntj3b.net
littlepoxがプリセットを作ってくれてる
実写
slowerベース
URLﾘﾝｸ(forum.doom9.org)
veryslowベース
URLﾘﾝｸ(forum.doom9.org)
アニメ
URLﾘﾝｸ(forum.doom9.org)
904:名無しさん＠編集中
16/04/08 13:54:08.07 uoC7bHcg.net
キチガイ臭がするそいつ
905:名無しさん＠編集中
16/04/09 10:01:22.54 Q4UbIrNX.net
fhd以上、x265の汎用設定詰めることができる時点で普通ではない
時間と手間がハンパじゃない
906:名無しさん＠編集中
16/04/11 21:49:12.30 xwAKbqwo.net
>>877
一応アニメのを試してみた結果、普段使っている設定と同ビットレートで
比較してみたところ、見た目でもSSIMでも大きく画質が下がった
ノイズがひどい
907:名無しさん＠編集中
16/04/11 21:55:16.14 I6vlHsjj.net
「普段使っている設定」を書かずに報告しても意味ないような・・・
908:名無しさん＠編集中
16/04/11 22:25:47.80 xwAKbqwo.net
>>881
スマン
--input-depth 16 --output-depth 10 --crf 16 --qcomp 0.75 --rc-lookahead 250
--aq-mode 3 --aq-strength 0.75 --psy-rd 1 --psy-rdoq 1.1 --rdoq-level 2
--keyint 240 --min-keyint 1 --bframes 8 --tu-intra-depth 4 --tu-inter-depth 4
--me star --subme 7 --merange 64 --rect --amp --ref 6 --max-merge 5 --weightb
--rd 4 --colormatrix auto --colorprim auto --transfer auto --qg-size 64
--lookahead-slices 0 --sao-non-deblock --no-fast-intra
比較の時はビットレート固定
909:名無しさん＠編集中
16/04/12 14:22:43.11 f5lHfaTk.net
画像サイズとビットレートも必要だよ
910:名無しさん＠編集中
16/04/12 18:33:03.38 BUSmDDzJ.net
>>883
1280x720, 2100 kbps（←深い意味はない）
911:名無しさん＠編集中
16/04/12 19:03:31.00 f5lHfaTk.net
ソースによるけど2Mbps程度ならdeblock 0:0にしてsaoも有効化
aq/psy系も下げたほうがいい結果になりそう＞873のプリセット
あくまでx264での知見も基にした当てずっぽうだけど
912:名無しさん＠編集中
16/04/12 19:29:21.87 BUSmDDzJ.net
同感
>>877で十分な画質（←人によるが）を得るためにはどれくらい高いbitrate
が必要になるのか
高いbitrateならデフォルトに近い設定でも十分な画質が得られるような気がする…
913:名無しさん＠編集中
16/04/12 19:34:16.49 1ATzc72f.net
>>882
・>>877の設定で出力する時にも--output-depth 10は付けたの？
・SSIMはどうやって測ったの？
・>>877のアニメというのは--tune animationを考えてみたという設定だから
refとかbframesとかmeとかその他もろもろは特に指定されてないけど、そのへんはどう設定したの？
そのへんがデフォ値のままなら>>882と比較しても意味がない気がする。
・>>882の設定ってveryslowより重そうな気もするし、--rc-lookahead 250とかになってるけど、
本当に普段この設定で使ってるの？
914:名無しさん＠編集中
16/04/12 19:56:15.84 IeZ3td+Lx
x265ってkeyintの値よりrc-lookaheadの値を大きくできるんだ
x264はkeyintの値までしか設定できなかったからそういうもんだと思ってた
915:名無しさん＠編集中
16/04/12 19:58:52.51 f5lHfaTk.net
与えるビットレートが違えばマッチするオプションも変わるだけじゃないの
916:名無しさん＠編集中
16/04/12 20:08:09.35 BUSmDDzJ.net
>>887
・--output-depth 10は付けた
・--ssim
・書いていないところは>>882と同様
・本当に使っている
1280x720で4fps程度の速さ（仕事から帰ってくるまでに終わればいい）
2600K@4.4GHzでエンコ
917:名無しさん＠編集中
16/04/12 22:07:20.02 1ATzc72f.net
>>890
なるほど。ただ、--ssimについては、psy系を0にせずに使うと
x265 [warning]: --ssim used with psy on: results will be invalid!
x265 [warning]: --tune ssim should be used if attempting to benchmark ssim!
という警告が出るので、適切な計測結果にはなってないと思う。
918:名無しさん＠編集中
16/04/12 22:50:43.37 bnbtd3T9.net
つか、ほぼplacebo状態だな。
現状rd4の意味無いし（Currently same as 3 要するにデフォと一緒）、
rd上げるなら5。
で、そうするぐらいならpreset placeboで良いんじゃねーかと（笑
919:名無しさん＠編集中
16/04/13 19:12:35.06 L8JMc4g/.net
手元のソースで試してみたらこんな結果だった。
ソース：1280x720@23.976fps、2152フレームのアニメOPをf3kdb(デフォ設定)で16bit化したもの
x265 1.9+88、10bit出力で2パス2000kbpsエンコ
・medium（1行目は2パス目のログ、2行目はffmpegで求めたSSIM）
encoded 2152 frames in 102.34s (21.03 fps), 2005.55 kb/s, Avg QP:22.04
SSIM Y:0.987640 U:0.986022 V:0.986031 All:0.987102 (18.894759)
・slow
encoded 2152 frames in 286.04s (7.52 fps), 2004.33 kb/s, Avg QP:22.20
SSIM Y:0.988205 U:0.985980 V:0.985995 All:0.987466 (19.019040)
・slower
encoded 2152 frames in 904.10s (2.38 fps), 2010.01 kb/s, Avg QP:22.20
SSIM Y:0.988307 U:0.986136 V:0.986171 All:0.987590 (19.062166)
・veryslow
encoded 2152 frames in 1348.27s (1.60 fps), 2006.79 kb/s, Avg QP:22.52
SSIM Y:0.988313 U:0.986247 V:0.986282 All:0.987630 (19.076316)
・>>882
encoded 2152 frames in 721.53s (2.98 fps), 2005.88 kb/s, Avg QP:22.44
SSIM Y:0.988380 U:0.986515 V:0.986619 All:0.987776 (19.127808)
・>>882に>>877のアニメ設定を上書き
encoded 2152 frames in 953.88s (2.26 fps), 2006.71 kb/s, Avg QP:23.01
SSIM Y:0.986061 U:0.984168 V:0.984164 All:0.985429 (18.365247)
920:名無しさん＠編集中
16/04/14 06:23:31.29 SmTLnnP5.net
検証乙
SSIMを見る限り、>>882はveryslowより画質が良くslowerより早い
>>877を適�
921:pすることでmediumより画質が悪くslowerより遅くなる という認識でいいのかな？
922:名無しさん＠編集中
16/04/14 08:54:23.53 TL0trVBZ.net
ビットレート盛ったら（crf 20以下？）綺麗になると思う
923:名無しさん＠編集中
16/04/14 10:36:09.43 uaVnCBhc.net
ffmpegのssimの0.0001台の違いて見た目どんな違いなんだろう？
誰か解説頼みます。
924:名無しさん＠編集中
16/04/14 23:43:40.37 NwnHdn04.net
気にしたらハゲ
925:名無しさん＠編集中
16/04/14 23:47:05.40 i5ZA7JyZ.net
自分が良いと思ったセッティングでいいじゃない。
アニメなんかは誰に見せるわけでも無いんだし。
926:名無しさん＠編集中
16/04/15 00:44:21.13 +Fs+OHLX.net
--rc-lookahead 250 って怖ろしくメモリ食うんじゃないか？ｗ
40から80に上げただけでも1.4Gから2.4Gに跳ね上がってたのに
927:名無しさん＠編集中
16/04/15 01:48:34.93 KWIKv7Io.net
解像度などにもよるけどかなり食う
928:名無しさん＠編集中
16/04/15 01:58:08.47 Vj0XVi1o.net
ちょっと試してみたけど、>>893のサンプルだと
slower（-rc-lookahead 30） → 600MB
>>882（-rc-lookahead 250） → 2.6GB
だな。
929:名無しさん＠編集中
16/04/15 01:59:21.15 pgwZJlOQ.net
そういえば初期のx265ってメモリバカ食いしてたよね
930:名無しさん＠編集中
16/04/15 03:49:21.78 G5Tu0V3Z.net
メモリ食うだけで画質が上がるんなら数字上げてもいいんじゃないかな
メモリ足りないなら仕方ないけどね
931:名無しさん＠編集中
16/04/15 14:54:39.12 i2BOyiEg.net
>>893
リンク先のスレ読むとcffで使えと書いてあるぞ
932:名無しさん＠編集中
16/04/15 15:51:38.35 R0iR/RQZ.net
>>904
cffってなに？crfのこと？
リンク先というのは>>877のことだと思うけど、crfで使え（biｔrate指定じゃ駄目）なんて書いてないと思う。
933:名無しさん＠編集中
16/04/15 21:13:40.04 v5i5tBse.net
今時CBRなんてナンセンス
934:名無しさん＠編集中
16/04/15 23:16:50.52 xWoGZXDA.net
流れも読まない上にCBRってお前・・・
935:名無しさん＠編集中
16/04/15 23:31:22.66 WL/mTNMT.net
ﾈﾀﾆﾏｼﾞﾚｽ(・∀・)ｶｺﾜﾙｲ!!
936:名無しさん＠編集中
16/04/16 22:50:58.36 FapX/LQs.net
画質/負荷の効率が良いオプションって各preset間で
値が変わったり追加されたりするやつでいいのかな
ただし重いpresetに行くほど変化しているオプションの効率が悪くなるとかあるのかな
937:名無しさん＠編集中
16/04/16 23:15:07.78 RIWYlU/O.net
動き検索の重要度はsubme ＜ meだって猫さんが書いてたから
x265もそうだと思う
それとBフレやrefの枚数も3～4ぐらいでセーブしとくのもエンコ負荷の低減に役立つと思う
938:名無しさん＠編集中
16/04/17 16:13:38.77 E1zy7U5k.net
>>905
過去レスよく読め
939:名無しさん＠編集中
16/04/17 16:34:11.64 SQT/cZ/R.net
>>911
お前さんが>>906と同一人物で「いまどきbitrate指定エンコなんてやる奴いねーよ」とでも思ってるなら
>>893が「同一ビットレートでのSSIM比較」という目的で行われたことを全く理解してないことになるが・・・。
940:名無しさん＠編集中
16/04/18 13:09:32.53 4454Srxg.net
必死感漂ってるな
残念だけど、>>906じゃないし、用途によってはcbrを使う人がいるのは誰でもわかっていること
littleはvbrの設定を晒してるんだから、cbrでssim比較しても無意味
まぁ、妄想と決めつけが激しく頭が悪くても、がんばって行きろ
941:名無しさん＠編集中
16/04/18 14:53:46.23 xvx3IXAG.net
お前ら優位に立とうとする言葉選び好きだよな
942:名無しさん＠編集中
16/04/18 15:38:14.70 ZiaZImZR.net
>>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味」
の根拠はなに？
・>>877の上２つのリンクには--crfも含まれてるけど、>>893で使った３つ目のリンクは
--tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
・「CBRの幻想」とかx265のhelpの--bitrateの説明とか読んだほうがいいような気がする。
943:名無しさん＠編集中
16/04/18 16:55:07.97 4454Srxg.net
>>915
>>>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味じゃない」
の根拠はなに？
> --tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
思うのは自由だよ。でも、littleの一連のレス読んでから判断してね。
>・「CBRの幻想」とか
そんなこと言ってないよ。しっかり妄想と現実の区別してね。
まずは丁寧に文を理解することを習得しようね。短い文だから難しくないよ。
ｶﾞﾝｶﾞﾚ
944:名無しさん＠編集中
16/04/18 17:09:18.40 ZiaZImZR.net
ああ、やっぱり説明も話もまともに出来ない人だったか・・・お疲れさまでした。
945:名無しさん＠編集中
16/04/18 17:35:42.08 no/AiHFv.net
>>914
お前らと言うけど2レスだけだよ
946:名無しさん＠編集中
16/04/18 18:51:38.96 Sn6HnjyG.net
>>913
cbr≠abr であり、>>893はabrだと思う
abrはvbrで出来上がるものの平均ビットレートを指定してエンコじゃないのかな。。
ちなみにcbrの用途って何があるの？放送局？
947:名無しさん＠編集中
16/04/18 19:06:32.01 ZiaZImZR.net
割と知られてるページだと思ってたからタイトルしか書かなかったけど
>>916には通じなかったみたいだし、「"CBRの幻想"でググれ」と書くべきだったとちょっと反省。
948:名無しさん＠編集中
16/04/19 09:54:12.07 YZY7DcaM.net
>>920
？俺はcbrの善し悪しには何も触れてないぞ。話しのすり替えは止めようね。
短い文なんだからきちんと理解できるようになろうね。
自分の落ち度を認めず他の内容を無視するのも止めようね。
949:名無しさん＠編集中
16/04/19 11:48:28.42 7vkH9RtK.net
好きに使ったら良いのに、自分が良く使う設定に固執しすぎなんだよね。
950:名無しさん＠編集中
16/04/19 11:53:32.50 CfB8B13z.net
近代的なビデオコーデックで真のCBRなんて不可能っていう「CBRの幻想」って解説記事があるの
つまり1パスビットレート指定でも動作はVBRだと揚げ足を取られてるわけ
個人的にはcrf指定でも指定値が大きければ画質は悪くなり
ビットレート指定でもビットレートを大きく盛れば画質は良くなるわけだから
あまり意義のある言い争いじゃないと思う
951:名無しさん＠編集中
16/04/19 16:02:39.82 filiPvCp.net
もう何年前に読んだか忘れたけど、圧縮前に圧縮後予定ファイルサイズから逆算して
正確な圧縮品質を指定することは不可能かつ正確にファイルサイズを合わせることも不可能だから
って奴だよな
952:名無しさん＠編集中
16/04/19 17:28:26.53 YZY7DcaM.net
>>919
cbr≠abrなのはしってるよ
同一ビットレートで、ときてたからcbrといっただけですう
だから、handbrakeはサイズ指定のサポート止めたしね
907=910=918?
953:名無しさん＠編集中
16/04/19 17:40:38.84 ILdf6rCX.net
一応言っておくと俺はSSIMの計測結果を貼っただけであって、>>877や>>882とは別人。
CBRの件は別に揚げ足じゃなくて、helpでもABRという表現が使われてるし、
「CBRの幻想」の記事も踏まえて「CBR」という表現はあまり使わないほうがいいと思っただけ。
>>921にはまったく伝わらなかったみたいだし、なんか変な言い訳してるけど・・・。
よく見ると>>916は
「cbrでのSSIM比較が無意味ではないと主張する根拠はなに？」
と逆に問い返してるんだね。コピペミスかと思ったわ・・・。
俺は単に>>913の
・>>877はvbr（--crf）用の設定だ
・だからcbr（--bitrate）でSSIM比較しても無意味
という２つの主張の根拠がわからなくて知りたかっただけ。
これまで特に気にせずに２パスエンコも利用してSSIMを調べたり貼ったりしてたんだけど、
--bitrateだとうまく働かないオプションとかあるんだっけ・・・？
>>925はこれ以上相手にしても徒労に終わりそうだし、もし誰かわかるなら教えてほしい。
954:名無しさん＠編集中
16/04/19 17:44:29.70 ILdf6rCX.net
ついでに参考までに>>893と同じソースでの--crfでのSSIM計測結果
medium(--crf 20)
encoded 2152 frames in 110.22s (19.53 fps), 1547.26 kb/s, Avg QP:24.17
SSIM Y:0.986408 U:0.984554 V:0.984501 All:0.985781 (18.471442)
>>877(
955:Doom9)のアニメ設定(--crf 20) encoded 2152 frames in 389.29s (5.53 fps), 2371.26 kb/s, Avg QP:21.66 SSIM Y:0.986468 U:0.984746 V:0.984787 All:0.985901 (18.508171) >>882(--crf 20) encoded 2152 frames in 791.84s (2.72 fps), 1989.61 kb/s, Avg QP:22.51 SSIM Y:0.988334 U:0.986457 V:0.986566 All:0.987727 (19.110332) >>882に>>877のアニメ設定を上書き(--crf 20) encoded 2152 frames in 1106.11s (1.95 fps), 2281.76 kb/s, Avg QP:21.80 SSIM Y:0.986605 U:0.984842 V:0.984886 All:0.986025 (18.546500) --- medium(--crf 27) encoded 2152 frames in 96.01s (22.42 fps), 705.81 kb/s, Avg QP:31.89 SSIM Y:0.978727 U:0.976208 V:0.975609 All:0.977788 (16.534075) >>877(Doom9)のアニメ設定(--crf 28) encoded 2152 frames in 248.13s (8.67 fps), 857.42 kb/s, Avg QP:30.47 SSIM Y:0.978540 U:0.975270 V:0.974700 All:0.977355 (16.450309) medium(--crf 28) encoded 2152 frames in 98.21s (21.91 fps), 636.98 kb/s, Avg QP:32.96 SSIM Y:0.976924 U:0.974559 V:0.973803 All:0.976010 (16.199657)
956:名無しさん＠編集中
16/04/19 17:58:21.32 CfB8B13z.net
微妙に着眼点と主張がかみ合ってないからお互いにスルーするが吉
957:878
16/04/19 18:00:28.75 0e3x1/oL.net
>>927
rdを4→6にするだけで画質が格段に良くなった。
だけどかなり重くなったので>>882と同等のエンコ速度を維持できるよう
画質/負荷の悪いものを削ってったら結果的にpreset slowerに近くなった。（下記はslowerで書き直し）
もしまたエンコする機会があったら下記への変更をよろしくです。
--input-depth 16 --output-depth 10 --preset slower --crf 16 --qcomp 0.75
--rc-lookahead 250 --aq-mode 3 --aq-strength 0.75 --psy-rd 1
--psy-rdoq 1.1 --keyint 240 --min-keyint 1 --no-amp --colormatrix auto
--colorprim auto --transfer auto --qg-size 64 --lookahead-slices 0
--sao-non-deblock --limit-refs 3
958:名無しさん＠編集中
16/04/19 18:56:00.56 ILdf6rCX.net
>>929
・>>893と同条件（2pass2000kbps）
encoded 2152 frames in 844.63s (2.55 fps), 2005.71 kb/s, Avg QP:21.93
SSIM Y:0.988783 U:0.986883 V:0.986995 All:0.988168 (19.269524)
・>>927と同条件（--crf 20）
encoded 2152 frames in 865.28s (2.49 fps), 1945.21 kb/s, Avg QP:22.13
SSIM Y:0.988679 U:0.986731 V:0.986839 All:0.988048 (19.225614)
959:名無しさん＠編集中
16/04/19 19:20:19.87 0e3x1/oL.net
>>930
早速のエンコありがとう。
ちょっと重くなってしまったみたいだね。スマン
でも、画質はそれなりに改善したように見えるね。
960:名無しさん＠編集中
16/04/19 21:31:48.09 CfB8B13z.net
今のx265の場合、デフォのcrf値が大きすぎるんだよな
プリセット作るにしても決めきられない感じ
961:名無しさん＠編集中
16/04/20 10:32:47.35 /W4Johvo.net
プリセットなんてmedium(デフォルト)な時点でx264超えてるんだからどうでもいいよ
後は好きなcrf値を設定すればOK
なんか色んな設定やパラメータいじくり回すx264時代の因習に囚われてる人いるようだけどｗ
962:名無しさん＠編集中
16/04/20 10:52:36.60 O3XwBTuO.net
4K60Pがリファレンスなのにね
963:名無しさん＠編集中
16/04/20 14:21:23.87 9swemZrS.net
プリセットじゃなくプロファイルだった
964:名無しさん＠編集中
16/04/20 19:29:17.58 klJmlwQn.net
>>933
x264でも重ための設定でAQやpsy-rdなどを調整したらx265の
単純なmediumになら画質で勝るよ。
つまり、設定次第だと思う。
965:名無しさん＠編集中
16/04/20 20:09:39.34 GUTooAcL.net
さわらないほうが良いタイプだと思うよ
966:名無しさん＠編集中
16/04/20 21:34:42.31 /W4Johvo.net
>>936
x265のプリセットを１段階上げればいいだけでしょｗ
967:名無しさん＠編集中
16/04/21 01:14:11.61 GimnWLrM.net
レベルを上げて物理で殴ればいい
968:名無しさん＠編集中
16/04/21 03:00:03.58 LQaBaBJx.net
レベルといえばお前らレベル指定とかしないん？
969:名無しさん＠編集中
16/04/21 08:48:25.19 s5ZQAH1b.net
携帯視聴やゲーム機家電視聴などを弾きたい時に
970:名無しさん＠編集中
16/04/21 22:30:46.71 43CTREQW.net
最大ビットレートは規格に合わせて指定してる
他のオプションまでは把握してないか
971:らデフォのまま
972:名無しさん＠編集中
16/04/23 19:00:20.96 p08WM9kP.net
ABRのSSIMを貼った人は何が言いたかったのだろう
973:名無しさん＠編集中
16/04/23 19:41:54.17 GVwq/FMD.net
結論を言うと荒れるから何も言わないのかな
数字だけで判断するなとか言うやつが出てくるかもしれないし
974:名無しさん＠編集中
16/04/23 20:22:56.70 1ED72ZaJ.net
>>943
ただの参考値として貼っただけだよ。
>>926でも書いたけど、なんで「ABR（2pass --bitrate）のSSIMは無意味」だと思うの？
ちゃんとした根拠があるなら知りたいんだけど。
975:名無しさん＠編集中
16/04/23 20:50:47.52 VX0ubDbv.net
少なくとも俺は --cfr でサクッとやってしまうから abs でビットレート固定されても参考にはしないかな。
逆に abs でエンコしてる人になら参考になると思う。
要は自分で取捨選択を適切にしていればいいだけであって、人に文句を言うのはお門違いだと思うよ。
976:名無しさん＠編集中
16/04/23 21:03:52.97 GVwq/FMD.net
cfrやabsはネタかな
オプション検討しているときにcrfを使うとビットレートが
大幅に変わってしまい、オプションの良し悪しが分からなくなる。
最終的にcrfでエンコするにしてもオプション検討においては
ABRでの比較は十分に参考になると個人的には思う。
977:名無しさん＠編集中
16/04/24 12:02:05.68 ou5067T+.net
>>945
「ABR（2pass --bitrate）のSSIMは無意味じゃない」ちゃんとした根拠があるなら知りたいんだけど。
978:名無しさん＠編集中
16/04/24 12:06:44.59 h82NYOq7.net
指定ビットレートが低すぎなのはあると思う
979:名無しさん＠編集中
16/04/24 12:25:41.70 szqA3nvc.net
指定ビットレートの適正値はソース、解像度、好みによって変わりそう
980:名無しさん＠編集中
16/04/25 16:45:47.07 OGPz4ITg.net
ABRの人、doomのレスを理解できてないと思った
ここのレスの理解も怪しい
オプションの理解も
981:名無しさん＠編集中
16/04/25 19:28:56.39 nvGgjPd+.net
>>951
ABRでのSSIM計測が無意味だと言ってる人にその言葉をほぼそのまま返したい。
こっちはABRでのSSIM計測が無意味と言われた根拠が全くわからないから
教えてくれと質問してるのに、返ってくるのは山彦質問返しや根拠不明でかみ合わない主張や嘲弄だけ。
「お前は理解してないお前は理解してない」と念仏みたいにブツブツ呟き続けられても気味が悪いだけで
こっちは何が理解できてないのかさっぱりわからないし、進展がなくてスレにとっても迷惑だと思うよ。
スルーできてない俺も迷惑だろうけど。
・SSIMは画質（というかソースとの類似度）指標数値の１つだがあくまでも参考値であり
最終的には自分の目で見て決めたほうがよいというのは大前提。
・ABR（2pass --bitrate）でSSIMを計測するのは設定の違いによる
圧縮効率（画質・容量比）や速度を比較するため。
（数値的には、同一ビットレートでSSIMが大きいほうが圧縮効率が高いと評価できる）
・VBR(--crf)でSSIM計測してもいいけど、ビットレートもSSIMもばらけるので
パッと見てどちらが良いのか評価するのが難しい。
ビットレートやSSIMが同じくらいになるcrf値を探すのは面倒。
・720pで試したのは単にあまり時間をかけたくなかったから。
・2000kbpsで計測したのは、元ファイルが重め設定のx264 --crf20で約2500kbpsだったから。
ビットレート高めだと差がわかりにくくなるので、やや低めのビットレートで比較して
差をわかりやすくすることを意識した。
・>>893や>>927の結果だけ見ると、Doom9の設定（>>877のアニメ）は有効性が感じられない。
・ABRでのSSIM計測が無意味だという主張の根拠は全くわからないので教えてほしい。
・Doom9の設定が--crf向けだという主張の根拠も全くわからないので教えてほしい。
・Doom9のレスを理解できてないという主張の根拠も全くわからないので教えてほしい。
・俺個人のオプションに関する理解が浅いのは事実だから解説があると喜ぶよ。
これがこちらの現状なので、理解がおかしいというなら具体的な指摘を頼む。
スルーできてなくてごめん。> スレ住�
982:l 具体的な説明がされない限り、以後スルーするね。
983:名無しさん＠編集中
16/04/25 20:44:32.37 cQiwXoCT.net
>>951
私も>>952と同程度の理解なので、何がどう理解できていないのかを教えてほしい。
根拠を示すことができず否定するだけの無知な人ではないことを祈りつつ。
984:名無しさん＠編集中
16/04/25 20:59:50.91 QMvVZfm8.net
過去には、crfでSSIM比較するなビットレート指定しろ、って人もいたしどうしろと
985:名無しさん＠編集中
16/04/25 21:01:33.14 QZda0fQA.net
否定だけってのは反応に困るよね
品質指定だと瞬間的なビットレートはかなり高くなるから品質にはかなり有利
自分の経験でXvid ビットレート指定で350MBと、品質指定の250MBのファイルで後者の方が綺麗（前者は動きの激しい箇所でブロックノイズ多発）で
品質指定はそれぐらい画質に有利だと思う
でx264でも画質を求めたらcrf下げてデブロックフィルタも弱めてpsyを強めたりして（自分は）
そのcrf値が小さいとき用のオプションをcrfが大きいときに使うとやっぱりアラが出る
なので高画質向けオプションを評価するときは、コーデックの性能をもっと引き出せる好条件でやって欲しいなとは思う
（ネタだと思われそうだけど自分も教えて欲しいな>>951）
986:名無しさん＠編集中
16/04/25 21:08:01.55 mYE/Sg/n.net
一人で何やってんスか
987:名無しさん＠編集中
16/04/25 23:17:22.98 xf7dz0xUo
は？
988:名無しさん＠編集中
16/04/26 00:17:01.11 yVx5x6Ll.net
いまだに勘違いがはびこってるようだけど
2passってのは一回エンコしてみてその結果から目標ビットレートに近づくように自動でcrfを調整してもう一度エンコしてるだけのことだろ
最終的なビットレートが同じなら手動でcrfを指定しようが2passでやろうが画質に違いは出ないよ
989:名無しさん＠編集中
16/04/26 03:30:54.19 P6dH9VcC.net
CRFならlevelが許す限りの範囲でビットレートを変動できる
ビットレートを指定するが故の過剰品質も抑制できる、って理解だが
どっちにしろVBVでレート制御が入るからそっちの設定だけ詰めればCRFで良いような気がする
990:名無しさん＠編集中
16/04/26 18:29:14.73 H6GEQXQr.net
>>958
HEVCではそうなのか？
書いてないけど>955の「Xvid ビットレート指定で350MB」は「Xvid ビットレート指定2Passで350MB」
991:名無しさん＠編集中
16/04/26 20:45:29.80 xOye6Bx8.net
ABRの人、自演がんばれ
992:名無しさん＠編集中
16/04/27 01:45:52.17 ccoJ1QZy.net
Xvidとか古すぎて話についていけないわ
Xvidとx26Xとじゃレートコントロールの方式が違うんだよ
993:名無しさん＠編集中
16/04/27 06:21:06.02 SeExodLv.net
x265の更新がピタっと止まっているんだけど、何かあったのかな
994:名無しさん＠編集中
16/04/27 08:04:29.24 rBBpLPal.net
春休みは終わったんだよ、ヒキコモリ君
995:名無しさん＠編集中
16/04/27 09:32:20.93 7jGMhriN.net
x265の更新していたのは、日本の学生だったか…
996:名無しさん＠編集中
16/04/27 09:34:20.09 4Bx6XeNC.net
また一気に更新くるんじゃないの
997:名無しさん＠編集中
16/04/27 12:17:51.54 q1CqmRwh.net
>>952
>具体的な説明がされない限り、以後スルーするね。
実行しろ
わかってないことがわかってないのにわかった気になってゴリ押しする奴に誰が説明するかよ
他人が自分のために1から10まで手取り足取り説明してくれるのが当然という発想かよ、ゆとりか？
自覚のないうぬぼれの激しいばか
レス見てるだけでイライラした，蹴り入れたくなる
もう、ここに来るな
998:名無しさん＠編集中
16/04/27 12:56:15.58 ccoJ1QZy.net
こっそり教えてあげるけどお前の方が迷惑だよ
999:名無しさん＠編集中
16/04/27 18:04:47.37 9yLxz2J0.net
>>967
邪魔だからもう来ない
1000:で
1001:名無しさん＠編集中
16/04/27 19:33:10.69 MXOYRBVo.net
一部の動画の最初の数秒だけノイズだらけになるのって、エンコするときの設定で回避できますか？
1002:名無しさん＠編集中
16/04/27 20:11:42.22 U6riuRT4M
キーフレームでカットせずに編集された動画とか？
1003:名無しさん＠編集中
16/04/27 19:59:53.45 O1aRnOt/.net
一部動画って何を差すのか知らないけど最初だけならそこをカットすりゃいいんでないかい
1004:名無しさん＠編集中
16/04/27 20:47:20.64 vYGeTekE.net
>>970
それはx265は関係なく、元動画がおかしいか、エンコード前のデコード処理に問題があるか、
エンコード後の再生に使うデコーダに問題があるだけじゃね？
1005:名無しさん＠編集中
16/04/28 11:56:00.94 VAWFmSIl.net
>具体的な説明がされない限り、以後スルーするね。
実行できないね
やっぱり、みんなが思ったであろう口先番長
1006:名無しさん＠編集中
16/04/29 22:22:26.51 Qjv/odTt.net
x264 r2692(8/10bit)、x265 1.9+138(8/10/12bit)で各プリセットの計測テストしたので置いとく。
プリセットのみ（一部のデータは--tune等の調整つき）
・エンコード時間： URLﾘﾝｸ(2sen.dip.jp)
・SSIM/bitrate相関図： URLﾘﾝｸ(2sen.dip.jp)
・SSIM/bitrate相関図(medium以上)： URLﾘﾝｸ(2sen.dip.jp)
--tune ssim付き
・エンコード時間： URLﾘﾝｸ(2sen.dip.jp)
・SSIM/bitrate相関図： URLﾘﾝｸ(2sen.dip.jp)
1007:名無しさん＠編集中
16/04/29 23:06:35.59 hM8i6t7l.net
>>975
乙乙
x265の8bitと10bitの差って凄いのね
1008:名無しさん＠編集中
16/04/30 03:24:21.10 icRfs4QB.net
力作ですごいけど相関図が見づらい・・・
1009:名無しさん＠編集中
16/04/30 08:19:14.01 iwbiPODt.net
tab使いは頭悪いから
1010:名無しさん＠編集中
16/04/30 10:36:27.87 /y9WItAV.net
わがまま言えば実写が欲しかった
1011:名無しさん＠編集中
16/04/30 14:19:43.42 JnFxQH0Q.net
>>958
前にTSからcrfでエンコして結果、２０００kbsくらいで仕上がったんだけど
その後に同じTSを２passで２０００kbsでエンコしたら残り１分くらいから最後までブロックノイズが乗ったんだ
たまたまかと思ってもう一回２passでやったらやっぱり同じようにブロックノイズが乗った
なんでやろう？
それ以来２passは信用してないんだけど
1012:名無しさん＠編集中
16/05/01 01:06:55.28 OwT/pRKY.net
>>980
crf エンコして 2,000kbps ってそれ平均じゃないかな? vbr だからシーンによってビットレートは変わるよ。
2pass 2,000kbps でノイズでるんならそれ、ビットレート足りなかったんだろ。
1013:名無しさん＠編集中
16/05/02 13:48:49.91 3M7zOLf9.net
>>981
2passが>>958の主張する挙動の通りなら>>980の現象は説明つかない
ってことを言いたいんじゃないの
1014:名無しさん＠編集中
16/05/02 17:17:48.15 IVu6sEQK.net
>>958は基本的には正しいから可能性は4つだな
① x265のコードにミスがある／あった
② >>980の比較方法にミスがあった
③ x265の2nd-passの自動crf調整アルゴリズムの性質上、実際にそういったことが稀に起こり得る
④ >>980の話は嘘か誇張である
でも決め手となる詳細な情報が何一つないからあんまリアクションできないわな
1015:名無しさん＠編集中
16/05/02 17:20:24.76 NFZmJHH5.net
１パス目の解析ファイルが正常に作れてなかったとか？
1016:973
16/05/02 20:19:49.45 GTGVqrYC.net
>>983
冷静な分析だと思います
嘘か誇張は絶対ないです
1パス目の解析ファイルの作り方がまずかったのか？
x264と同じやり方で2passでやってたんだけど・・・
元のTSはインターレースのなかにPV映像の30pが混じった映像で
1017: それをQTGMCで60pにしてました ブロックノイズはその30pの部分に載ってました（微妙じゃなくて明らかなやつです）
1018:名無しさん＠編集中
16/05/02 20:43:03.56 MFklek4b.net
自分の言ったことくらい実行しろ
1019:名無しさん＠編集中
16/05/02 23:18:21.04 3M7zOLf9.net
bitrateを指定する以上2passもCBR≒ABRの発展型でしかないと思うんだがな
crfオプションを指定しない以上エンコーダは品質目標を知りえないわけで
アグレッシブに圧縮できるシーンに出くわしたときCRFほどの働きはできないだろう
1020:名無しさん＠編集中
16/05/03 11:08:09.34 IEaoSNtT.net
なんだ？この自演臭い2pass議論モドキ
1021:名無しさん＠編集中
16/05/03 16:25:11.30 Vh9buT2E.net
BitrateViewerで違いを見てみようかと思ったら、H.265には対応してないんだった。
古いソフトだから当たり前だけど、H.265に対応してる同様のソフトってないのかな。
1022:名無しさん＠編集中
16/05/03 17:53:45.39 fYHQmMJu.net
MPC-hcｆｒで代用できるんじゃないか？
1023:名無しさん＠編集中
16/05/03 19:04:14.23 Vh9buT2E.net
>>990
ググってみたけどなんのことかわからなかった
1024:名無しさん＠編集中
16/05/03 19:07:46.37 Vh9buT2E.net
とりあえず980過ぎてるので次スレ立ててくる
1025:名無しさん＠編集中
16/05/03 19:11:22.18 Vh9buT2E.net
次スレ
x265 rev3
ｽﾚﾘﾝｸ(avi板)
1026:名無しさん＠編集中
16/05/03 19:40:13.42 fYHQmMJu.net
>>991
ごめん
mpc-hcって書こうとしてたんだけど変になってた
>>993
乙
1027:名無しさん＠編集中
16/05/03 20:06:53.73 IGe9RuRo.net
>>993
おつ
1028:名無しさん＠編集中
16/05/03 20:11:50.14 fYHQmMJu.net
昼にエンコードしたものをmpc-hcで比較（左の数字は平均/現在）
ソースはavisynthで"FreezeFrame(9000,30000,9000)"で作った静止動画11分と、
トリムだけした1分の動画をaviutlで連結読みしてguiEXでエンコード
frozenは頭だし状態で再生開始20秒目
moveは11m50sから10秒間再生した12:00地点
crf 23
frozen 119/20
move 1203/1435
230kbps 2pass
frozen 160/21
move 897/1047
結果は、frozenでは平均に近づいて2passのほうが高め、moveでも平均に近づき低め
12m過ぎたあたり（スクロールしてる）のビットレートは、crfモードでは1400kbpsを出すこともあるのにたいし
2passでは1100kbpsを超えることは無かった
1029:名無しさん＠編集中
16/05/03 23:36:26.14 umRZY+Hf.net
だってファイルサイズが違うんでしょ？
1030:名無しさん＠編集中
16/05/04 00:07:59.51 2HnXwOPY.net
四捨五入してオマケしたから同じではないが
crf23が32.4MB
2passのが36.6MB
1031:名無しさん＠編集中
16/05/04 00:26:46.45 2HnXwOPY.net
ちなみにちゃんとcrf23でエンコ後プロパティでビットレート調べて
2passエンコ登録時にそのビットレートでエンコしてる
1032:名無しさん＠編集中
16/05/04 01:38:01.15 I2MMBFA3.net
実際問題サイズをぜんぜん揃えられてない状態で「ちゃんと」と言われましても・・・
とりあえず言えるのは、実際の平均ビットレートはx265出力(GUI)Exのログで調べるようにした方がいいってことと
ABRには多かれ少なかれ仕上がりサイズのズレは付き物なんだから、ズレたなら--bitrateの値を微調整してってこと
1033:名無しさん＠編集中
16/05/04 05:47:44.59 JEe8vmea.net
>>993
乙
1034:名無しさん＠編集中
16/05/04 09:30:32.92 RFD4/mYP.net
>>996
そういう結果になるのはみんなわかってることだけど・・・
>>998
1割以上サイズが違うもの比較しても意味ない
自覚の無いバカ、張り切ったバカほど迷惑邪魔なものは無いとは良く言ったものだ
1035:989
16/05/04 10:14:48.56 2HnXwOPY.net
言っとくけど自分は2passが自動crf調整だと言った人ではない
実
1036:験結果から何が分かるかぐらい言われなくても分かるだろうに・・
1037:名無しさん＠編集中
16/05/04 14:09:38.05 I2MMBFA3.net
うむ、俺も似たような実験をしてある程度は現象を再現できた
>>1002
そういう結果とは具体的にどういう結果のこと？それが起きるのはなんでなのか教えて
1038:名無しさん＠編集中
16/05/04 16:12:16.98 2HnXwOPY.net
ビットレート指定はcrfよりビットレートのふり幅が小さく
HEVCの2Passも既存コーデックの2passと同じ動作だった
1039:名無しさん＠編集中
16/05/04 16:41:13.54 pfZ/a3PA.net
エンコードログに出る平均ビットレートの遷移をグラフ化するとこんな感じになった。
静止画＋動画： URLﾘﾝｸ(2sen.dip.jp)
動画： URLﾘﾝｸ(2sen.dip.jp)
やっぱり>>958は間違いで、crfと2passのレートコントロール手法は別物なのでは。
1040:名無しさん＠編集中
16/05/04 17:11:10.81 RFD4/mYP.net
マジレスすると、答えはこのレスに出てるのにそれすらわからず騒いでるだけ
こんなの誰が相手にする？
明らかに初歩的なことすらわかってないのにわかった気になって
わかりきってることを謎解きをやってるだけ
次スレでは、もうその話しは止めろ
1041:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 510日 9時間 14分 46秒
1042:1002
Over 1000 Thread.net
２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
──────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
──────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
URLﾘﾝｸ(premium.2ch.net)
URLﾘﾝｸ(pink-chan-store.myshopify.com)
1043:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています