■ このスレッドは過去ログ倉庫に格納されています
x265 rev2
- 1 ：名無しさん＠編集中：2014/12/11(木) 07:56:24.27 ID:03HuUp8B.net
- AviUtlやx265guiExなどの話はスレ違いなのでそれぞれの専用スレへどうぞ。
[本家]
http://x265.org/index.html
https://bitbucket.org/multicoreware/x265/wiki/Home
[ソース]
https://bitbucket.org/multicoreware/x265/src
https://github.com/videolan/x265
[バイナリ]
http://x265.ru/en/builds
http://rigaya34589.blog135.fc2.com (右側のメニューの"ビルドしたものとか")
[ビルド方法(MSVC)]
http://rigaya34589.blog135.fc2.com/blog-entry-402.html
http://rigaya34589.blog135.fc2.com/blog-entry-540.html
[ドキュメント]
http://x265.readthedocs.org/en/default/index.html
[諸注意]
x265のrevはMercurial(Bitbuket)とGit(Github)では算出方法が違います。
当スレではMercurial準拠で示すようにして下さい。
次スレは>>980が建てること。
[前スレ]
x265 rev1
http://peace.2ch.net/test/read.cgi/avi/1390566606
- 2 ：名無しさん＠編集中：2014/12/11(木) 07:57:21.85 ID:03HuUp8B.net
- [関連スレ]
・H265/HEVC全般の話はこちらへ
【2016】 H.265/HEVC Part4 【7680x4320】
http://peace.2ch.net/test/read.cgi/avi/1405488395/
・AviUtlの出力プラグインであるx265guiExについての話題はこちらへ
x264vfw GUI専用スレ Part9
http://peace.2ch.net/test/read.cgi/avi/1351856057/
- 3 ：名無しさん＠編集中：2014/12/11(木) 07:59:50.66 ID:03HuUp8B.net
- >>1 すまん一行目が抜けてた
H.265/HEVCのコマンドラインエンコーダーであるx265について語るスレです。
AviUtlやx265guiExなどの話はスレ違いなのでそれぞれの専用スレへどうぞ。
[本家]
http://x265.org/index.html
https://bitbucket.org/multicoreware/x265/wiki/Home
[ソース]
https://bitbucket.org/multicoreware/x265/src
https://github.com/videolan/x265
[バイナリ]
http://x265.ru/en/builds
http://rigaya34589.blog135.fc2.com (右側のメニューの"ビルドしたものとか")
[ビルド方法(MSVC)]
http://rigaya34589.blog135.fc2.com/blog-entry-402.html
http://rigaya34589.blog135.fc2.com/blog-entry-540.html
[ドキュメント]
http://x265.readthedocs.org/en/default/index.html
[諸注意]
x265のrevはMercurial(Bitbuket)とGit(Github)では算出方法が違います。
当スレではMercurial準拠で示すようにして下さい。
次スレは>>980が建てること。
[前スレ]
x265 rev1
http://peace.2ch.net/test/read.cgi/avi/1390566606
- 4 ：名無しさん＠編集中：2014/12/11(木) 11:10:57.70 ID:tD/+CwCm.net
- ☆☆☆☆☆
/ ／ ／ | ＼ ヽ
/ ／ ／ / / || | i ヽ i
i / / / / / / || || |│ |ﾉｽ
|// / /___, -一ｧ| /! |ﾄ、|│ | | く」
|,-‐￢ ￣---┘'７ |! ﾊ! |,､-┼十|! | | |
, -‐ ''" し' '´_ ／,ィ二l |ﾄ、/!ヽﾄ､＼_ヽ!|!l | ﾊ |
,r／ __ ,イ|ﾘ ヾハ! ヽ! ,ィ⌒ヾﾐﾘﾉ!/ﾘ | ☆ 自民党、グッジョブですわ。 ☆
／ ||ヽ -' ／￣ )｀ __ |ヒﾉ:} '` ,ｲ/ | | http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
,r ' ヾ､ ,-､＿___ , イ￣,r=＝- ==-' ﾚ' /| |
／ ヽ `ーｿ ' | |ﾄ､,ﾍ ′"" "" / / || | ☆ 日本国民の皆様、１２月１４日（日）の
. ／ ＼_ ／ | ﾊ ヽ｀ﾞ'ﾍ ' '__. ィ ／ / | | | 『衆議院議員総選挙』に必ず投票にいきましょう。 ☆
／ / / | ヽ 川＼ ヾ三ﾆ‐'′／/! | | | |
/ / / 八 ＼川| |`ト- .. __ , イ‐ｧﾍ | | || |!
／ / / / ＼ ＼ 「`ー- ､ ／ .〉 ト､| ヽ、
,イ ／-─＝￢ﾆヘ､_ ＼ 厂＼ 厂ヽ /!| | `ｰ＝ﾍ
-‐ ￣ /─ ' ￣ ├- ヽ＼ ＼ﾉ＼ ＼ 人 ﾊ!ヽ || |-┤ ヽ
/ ／!‐-- | |＼ ﾄ､_｀ヽ oヽ ﾄ､! || |‐┤- ヽ
／/ 〉 __ ／ ├‐- || | 川-‐ | | 厂7! ﾊ! ├:┤ ￣ヽ
／ / ｰ ─ ￣ ├‐- ﾘ || ﾊ!ﾍ | | ト┤|/′ ヾ,┤ ﾞi_
‐ ' 〉‐- | / /＼ .|o | /ヽ/（′ ∨ ＼
‐--─ ──-r､___-､ /ー_ {( '´＞､! /ヽ/ |＼ ＼
- 5 ：名無しさん＠編集中：2014/12/11(木) 12:47:43.48 ID:jwZYMuCI.net
- おつ
- 6 ：名無しさん＠編集中：2014/12/11(木) 15:15:07.90 ID:59yj8Jm1.net
- motion: chroma ME [CHANGES OUTPUTS]
https://bitbucket.org/multicoreware/x265/commits/afd5620c77a4729f4c599f9ad69000082693a32e
include chroma distortion in satd decisions when --subme > 2 and chroma blocks
are multiples of 4x4
This required making the MotionEstimate class more aware of PicYuv and its
indexing scheme so that it could find the correct chroma pixels to interpolate.
This allowed me to merge the setSourcePlane() method into the lookahead's
version of setSourcePU.
This requires further work. The Reference class needs to generate weighted
chroma planes if subpel refine will use chroma residual cost. Until this is
fixed, the chroma subpel steps will use unweighted reference pixels.
- 7 ：名無しさん＠編集中：2014/12/11(木) 20:36:37.17 ID:ji4ruXr2.net
- 今のところMuxはmp4box rev4868で快調だけど
Demuxは駄目みたい
一度Demuxすると再Muxが失敗する
- 8 ：名無しさん＠編集中：2014/12/11(木) 22:24:57.10 ID:59yj8Jm1.net
- mkmergeでmkvコンテナに入れてる
- 9 ：名無しさん＠編集中：2014/12/13(土) 06:30:47.97 ID:FtrhP+bJ.net
- 画質に大きな影響を与えそうなAQのデフォ値が変わったからお前ら注意な(´・ω・｀)
ttps://bitbucket.org/multicoreware/x265/commits/cbf5cad2e12b0a81d9ab1ecb8c4c325ae7b41eb3
- 10 ：名無しさん＠編集中：2014/12/13(土) 06:48:11.40 ID:a2Sd5mXd.net
- >>9
aq-modeのデフォルトが2から1に変更されたと。
自分でビルドしてないヘタレですまんのだけど、この変更のrevっていくつなんだろ。
revの調べ方がよくわからんでござるよ。
- 11 ：名無しさん＠編集中：2014/12/13(土) 07:08:29.79 ID:FtrhP+bJ.net
- 1.4+203かな・・・
間違ってたらスマン
でもヘルプ見て、AQのデフォ値確認すればいいよ
- 12 ：名無しさん＠編集中：2014/12/13(土) 07:38:41.81 ID:a2Sd5mXd.net
- >>11
ありがとう。気をつけておきます。
- 13 ：名無しさん＠編集中：2014/12/13(土) 07:46:50.94 ID:FtrhP+bJ.net
- >>9
そういえばver○+△-×からハッシュ取り出す方法知らないな
いつもビルドに使うバッチには現在のver○+△-×を取得するようにしてるけど、ver○+△-×からハッシュ取り出す方法は調べないとわからん
力になれんでスマンな
- 14 ：名無しさん＠編集中：2014/12/13(土) 07:48:29.86 ID:FtrhP+bJ.net
- ミス×からver○+△を取得する方法がわからんってことで
- 15 ：名無しさん＠編集中：2014/12/13(土) 08:02:07.54 ID:FtrhP+bJ.net
- ttp://imgur.com/vQI2LFC.jpg
ttp://pastebin.com/dUgFScFV
hgコマンドが使える前提だけど取り敢えず書いてみたバッチ
もっとスマートな方法があると思うけど・・・許して(´・ω・｀)
てか教えて
- 16 ：名無しさん＠編集中：2014/12/13(土) 11:01:12.58 ID:HSZETuQo.net
- AQ初期値の変更、強烈だな
同じプロファイル同じcrf値でも、凄いサイズが小さくなった
またcrf値見直しやｗ
- 17 ：名無しさん＠編集中：2014/12/13(土) 11:21:06.57 ID:RNorRQ7W.net
- --aq-mode 2
少し前からこれを付けるようにしていたから、何も気付かずに居た俺。
- 18 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 18:03:45.29 ID:e0igk0Fe.net
- 前スレ最後の方の10bitエンコ話を見て、10bitエンコの恩恵を受けるのに10bit対応のグラボやモニタが必須と
勘違いしてる人がまだいる気がしたので、なんとなく8bitエンコと10bitエンコの見え方の違いサンプルを作ってみた。
元画像 GIMPで作った線形の緑グラデーション 1024x576 右上（0,127,0）左下(0,0,0)
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3117.png
8bitエンコ： RGB→8bitYUV420→x265_8bpp 再生：MPC-HC1.7.7(LAV0.63)→（NV12）→EVR、madVR 0.87.10
EVR： ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3118.png
madVR： ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3120.png
10bitエンコ： RGB→16bitYUV420→x265_16bpp 再生：MPC-HC1.7.7(LAV0.63)→（P010）→madVR 0.87.10
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3119.png
madVRは多分デフォルト設定。「reduce banding artifacts」のチェックはオフ。
今の段階から10bitエンコを勧めるとかそういう話ではなくそんな気もないけど、
前スレの972と983の内容はちゃんと理解しておいたほうがいいという話ね。
---
972 名前：名無しさん＠編集中 転載ダメ©2ch.net[sageteyon] 投稿日：2014/12/08(月) 22:59:20.77 ID:p9uFkdO0
>>963
途中で8bitのNV12等にせず、madVRの様にP010 -> RGB32とやれば普通のディスプレイでも恩恵を受けられる
983 名前：名無しさん＠編集中 転載ダメ©2ch.net[sageteyon] 投稿日：2014/12/10(水) 13:02:48.78 ID:gwpRPADG [1/2]
色空間が内部のYUVと、実際表示されるRGBとでは違うから別に特別な機材は必要ない
http://csbarn.blogspot.jp/2012/01/converttorgb.html
---
- 19 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 18:22:12.54 ID:rv/2Wise.net
- >>18
乙
これ未だに分かってないのにトンチンカンな10bit批判する奴がいるから困る
- 20 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 19:28:30.12 ID:rd0EWYJ6.net
- > 今の段階から10bitエンコを勧めるとかそういう話ではなくそんな気もないけど
結局はこれ
- 21 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 19:31:11.05 ID:FD4LHR20.net
- 今の段階から10bitエンコはおすすめだし、8bitエンコ選ぶ理由は1個しかない
それは、エンコ速度を稼ぎたいとき。
- 22 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 19:33:11.19 ID:JwNYVLzm.net
- >>21
ヒント：HW再生支援
- 23 ：名無しさん＠編集中：2014/12/14(日) 21:11:03.76 ID:TvZ2HMfZ.net
- >>18
8bit接続でソフトキャリしてるとかモニタのLUTが少ない劣悪環境だと
8bitとか10bitエンコ以前に諧調性が劣るので、10bitエンコでの改善度が正しく比較できないんだよ
その点は理解してる？
- 24 ：名無しさん＠編集中：2014/12/14(日) 21:15:46.22 ID:COfx4ydN.net
- 君のモニターがそうなの？
- 25 ：名無しさん＠編集中：2014/12/14(日) 23:26:26.90 ID:1gc5CslR.net
- >>23
もう屁理屈レベルじゃねーかw
- 26 ：名無しさん＠編集中：2014/12/14(日) 23:34:14.69 ID:e0igk0Fe.net
- >>23
モニタやキャリブレーション回りは正確な知識がないのであらためて勉強中だけど、
厳密に「正しい比較」ができるかどうかはともかくとして、基本的にはYUV⇔RGBの話であって、
少なくとも>>18については「劣悪環境」でも「改善されてる」ということは十分にわかると思うんだけど、違うのかな？
madVRで表示されるデバイス名でググったら、今年買ったうちのLavieノートちゃんのパネルは
Display Colors : 262K (6-bit)
で、PCの仕様を見なおすと
内蔵ディスプレイ 最大1677万色
（※1677万色表示は、グラフィックアクセラレータのディザリング機能により実現します。）
というイマイチ環境らしいけど、10bitエンコのほうが綺麗なのはハッキリとわかるし・・・（震え声）
あと、１つよくわからなくなった点があるので教えてほしいのだけど、10bit出力対応のグラボとモニタを使ったとして、
動画再生ソフトはどうすればその10bit出力環境をフルに活用できるんだろ？というか活用できるもんなの？
madVRとかEVR-CPとか10bit出力環境でのレンダリング回りの処理がよくわからなくなってきてしまって混乱中。
- 27 ：名無しさん＠編集中：2014/12/14(日) 23:35:26.56 ID:pj87ePTU.net
- エンコした時点でバンディング低減効果があるって言ってるのにハードの話をしつこく持ち出す基地外
- 28 ：名無しさん＠編集中：2014/12/14(日) 23:50:14.28 ID:RB7cRxzf.net
- >>18
元が8bitの場合はどうなる？
RGB→8bitYUV420→x265_16bppの場合
- 29 ：名無しさん＠編集中：2014/12/15(月) 00:10:23.84 ID:MFiyUfv0.net
- >>28
8bitソースを16bppでエンコ： RGB→8bitYUV420→x265_16bpp 再生：MPC-HC1.7.7(LAV0.63)→（P010）→madVR 0.87.10
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3123.png
一応書いておくと、RGBからAvisynthのConvertToYV24()で8bitYUVにして、
エンコせずにそのままRGBに戻すだけでもこうなる。（AvsPmodでのプレビュー）
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3122.png
>>18の記事でもわかるけど、RGB24で表せる1677万色のうち、
リミテッドレンジの8bitYUVで表せるのは270万色前後にすぎないらしいから。
ttp://goldenhige.cocolog-nifty.com/blog/2012/03/16777216avisynt.html
ttp://goldenhige.cocolog-nifty.com/blog/2012/03/yuv8bit10bit-97.html
- 30 ：名無しさん＠編集中：2014/12/15(月) 00:18:04.59 ID:imP1Zk2W.net
- つか、実際にエンコしてみりゃ8bitソースでも10bitでエンコするだけで
バンディング消えるのになんで試さないんだろう？
安いTN液晶だとダメなの？持ってないから知らないけど。
- 31 ：名無しさん＠編集中：2014/12/15(月) 00:28:08.40 ID:FJraarRB.net
- >>29
madVRが凄く優秀というのは分かった。
EVRだとどう？
- 32 ：名無しさん＠編集中：2014/12/15(月) 00:28:51.39 ID:+j7WK84r.net
- >>24-26
俺はバンディング低減効果については異論ないぞ
8bitでいいって言ってる奴がいなかったっけ？
違いが気にならないのは環境による影響もありうるってこと
8bitエンコードをデコードして出力する場合、一般的なPCスケールでは16-235を0-255にするけど、
mpc-hcとかの10bit出力ではレンダラのバックバッファは16bitになってて、これを10bitに丸めて出力できるから
リニアリティが悪化しにくい
モニタのLUTが8bitだと、LCDのガンマ特性をCRTの2.2に変換する時に値のスキップや重複が
でやすく、諧調が減ってしまう
8bit LUTのモニタだとRGBや色温度・コントラスト等の設定を微調整しても結構大きく変化したりしてしまう
動画ではカラマネはあまりしないだろうけど、ソフトキャリも諧調が減る原因になる
こういったことがあるから、環境によってはバンディング低減効果が今一つに感じられる可能性があるってこと
- 33 ：名無しさん＠編集中：2014/12/15(月) 00:31:18.52 ID:LaxHUpB3.net
- 君のモニターがそうなの？
- 34 ：名無しさん＠編集中：2014/12/15(月) 00:36:49.02 ID:MFiyUfv0.net
- >>31
自分で試してみるのが一番やで。
>>18,>>29に追加
8bitソースを16bppでエンコしてEVR表示： RGB→8bitYUV420→x265_16bpp 再生：MPC-HC1.7.7(LAV0.63)→（NV12）→EVR
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3124.png
- 35 ：名無しさん＠編集中：2014/12/15(月) 01:06:13.15 ID:+j7WK84r.net
- >>33
以前6bit+FRCのモニタを使ってたけど>>18の一番目みたいなグラデーションで
バンディング状のムラを感じたから各色10bitで接続できるモニタに買い替えたよ
新しいモニタではムラはほぼわからなくなったよ
- 36 ：名無しさん＠編集中：2014/12/15(月) 01:49:48.48 ID:+j7WK84r.net
- >>29
8bitソースを16bppでエンコ： RGB→8bitYUV420→x265_16bpp 再生：MPC-HC1.7.7(LAV0.63)→（P010）→madVR 0.87.10
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3123.png
RGBからAvisynthのConvertToYV24()で8bitYUVにして、 エンコせずにそのままRGBに戻すだけでもこうなる。（AvsPmodでのプレビュー）
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3122.png
この2つを比較すると上の方が若干滑らかな気がしたんでレベルを2倍して
ヒストグラムを調べてみたら上の方がバンドの間隔が狭くなってて使われてる値も多かった
そのヒストグラム
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1132.png
- 37 ：名無しさん＠編集中：2014/12/15(月) 01:56:28.27 ID:l5Yqc8Zh.net
- 結構差が出るもんだなあ
おつかれ
- 38 ：名無しさん＠編集中：2014/12/15(月) 02:29:50.78 ID:+j7WK84r.net
- アップされた他の画像も含めたヒストグラム一覧を作ってみました
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1133.png
こうしてみると、>>29のエンコせずに戻したのが質が低いのはEVRのせいみたいだね
ちなみに、Firefoxで表示すると元のグラデーションでも微妙なバンディングが見えてる
画像をダウンロードして他のビューアで表示すると気にならないから
Firefoxってカラマネ対応でも精度が低いのかね
- 39 ：名無しさん＠編集中：2014/12/15(月) 14:43:31.54 ID:gq8MlEdb.net
- PCで見るだけなら問題ないんだろうけど
他機器なりハードデコード仕様次第だろうなぁ
対応表明してるインテルがどうなるかが気にはなる
- 40 ：名無しさん＠編集中：2014/12/15(月) 15:19:14.67 ID:DG4VBbuz.net
- >>39
タブレットをテレビ出力して映画見る時代らしいし
対応するしないで結構差が出るかもな。
- 41 ：名無しさん＠編集中：2014/12/15(月) 15:29:11.47 ID:yzAxGcs0.net
- H.265とかすごい規格がでてきても
結局、見るのはアニメなんでしょ？？
- 42 ：名無しさん＠編集中：2014/12/15(月) 15:33:18.16 ID:s82t9pDF.net
- それの何が問題なんだ
- 43 ：名無しさん＠編集中：2014/12/15(月) 15:35:26.89 ID:l+BH8HCm.net
- >>41
火垂るの墓ですが、何か？
- 44 ：名無しさん＠編集中：2014/12/15(月) 15:40:40.99 ID:jMBR6dmA.net
- >>42
アニメくらい別にDVDで十分やん
せっかくの4k 60fpsとか宝の持ち腐れやん
- 45 ：名無しさん＠編集中：2014/12/15(月) 15:47:51.26 ID:s82t9pDF.net
- 俺はアニメ見ないけど、
どうしてそう自分の価値観を押し付けるようなことをするのか不思議だ
それを決めるのは本人たちで、他人じゃないだろう
こうやって技術が向上して世間一般にも広まるのであれば、
それがどういった形態がきっかけになろうが構わないと思うんだが
- 46 ：名無しさん＠編集中：2014/12/15(月) 15:59:52.62 ID:DG4VBbuz.net
- アナ雪がこんだけ売れてるんだから、一般人ふくめてアニメが主流でしょうな
- 47 ：名無しさん＠編集中：2014/12/15(月) 16:23:58.91 ID:OVipwb+G.net
- >>45
それはそうだけど
アニメって子供の見る物じゃない
H265とか最新のコーデックを使って
大人がアニメ見ているとか
信じられないんだけど
もっと研究用途とか、なら分かるだけど
- 48 ：名無しさん＠編集中：2014/12/15(月) 16:28:01.60 ID:imP1Zk2W.net
- 映画とかは時間かかりすぎるしな
長さ的にも圧縮素材としてもアニメが一番適してる
- 49 ：名無しさん＠編集中：2014/12/15(月) 16:34:41.82 ID:l+BH8HCm.net
- >>47
子どもと一緒に大人がアニメ見ることは多々あるわけだが？
お前が信じられない世界が今目の前の現実だ
お前は今までもこれからも現実逃避しながら生きて下さい
- 50 ：名無しさん＠編集中：2014/12/15(月) 16:35:31.25 ID:s82t9pDF.net
- 実際、いい年した大人でもそうやってアニメ見てるの知ってて、
信じられないって言うのはおかしくないか
だって、見てるというそれは言わずもがな事実じゃないの
だから俺は、何が契機になろうが関係ないと言っているのに、
それはそうと肯定しつつ、また否定するお前は何が言いたいんだ
- 51 ：名無しさん＠編集中：2014/12/15(月) 16:36:57.20 ID:+jpyBKVa.net
- h.264とh.265の性能を比較した時アニメと実写だったら実写の方が差が出たような気もする。
アニメだと思ったより差がないと感じたな。
- 52 ：名無しさん＠編集中：2014/12/15(月) 16:55:19.54 ID:2oj9umlW.net
- 自分の信念以外を全否定したいだけで、コミュニケーションを取る気もさらさら無いようだし
相手するだけ無駄。
ソースは何でも良いし正直そこは個々の自由だからどうでも良い所。
否定するにしても相応の根拠なり示せば良いと思うんだけどね。
アニメ否定しているけど、肝心な本人はどう言う使い方をしているかなんて一切書いてないからね。
- 53 ：名無しさん＠編集中：2014/12/15(月) 17:09:56.86 ID:KcF2TLlx.net
- >>52
俺は子供じゃないから
アダルトな使い方に決まっているだろ
ハメ撮りとかだよ
- 54 ：名無しさん＠編集中：2014/12/15(月) 17:39:59.46 ID:6gJ7lEUS.net
- 10bitはじめてやってみたけど実写だと静止画にして目を凝らさないと分からん
エンコ時間が延びてHW支援が効かなくて費用対効果はいまいち
10bitを推奨してる人はアニメヲタでOK？
- 55 ：名無しさん＠編集中：2014/12/15(月) 17:45:00.59 ID:zIqlgBIW.net
- もういいよキチガイ
- 56 ：名無しさん＠編集中：2014/12/15(月) 17:49:46.01 ID:/sp8I/Xr.net
- 正直どうでもいい。
そろそろ別スレでも勝手に作って余所でやってくれってレベル。
- 57 ：名無しさん＠編集中：2014/12/15(月) 17:53:54.31 ID:DX3sgkDL.net
- 8bitｶﾞｰ10bitｶﾞｰはこのスレで語るべきことだろうけど、アニメがなんたらって話は完全にスレチだな
- 58 ：名無しさん＠編集中：2014/12/15(月) 18:09:22.58 ID:Kk2VNxtw.net
- ていうかアニメって見て面白い？？
大人になってからじっとしてアニメとか見れないんだけど
だってアニメの登場人物とか覚えても何の役にも立たないだけど
それなら資格のひとつでも勉強した方が役に立つじゃない
映画ならまだ話題作りに繋がるけど
アニメとか人に言えない趣味だし
- 59 ：名無しさん＠編集中：2014/12/15(月) 18:15:26.07 ID:FJraarRB.net
- そういう冷めちゃった系なら
ムリして2chしなくてもいいと思うよ
- 60 ：名無しさん＠編集中：2014/12/15(月) 18:23:18.07 ID:/sp8I/Xr.net
- >>57
いや、悪いけど8bitｶﾞｰ10bitｶﾞｰも余所いけって思ってる。
x265の8bitが今どんな具合で、10bitがどんな具合って話するなら分かるけど、
ここ最近はもう「8bit vs 10bit」の話ばかりしてる。
それx265スレでやらなくちゃいけない理由あるか？
まだ発展途上のx265でやる正当な理由があったら教えて欲しい。
なんかx264スレの方にも飛び火してるし、もういい加減にしたら？ とも思う。
それでも続けたいっていうなら、色空間スレみたくなんか専用スレ作ってやってくれ。
- 61 ：名無しさん＠編集中：2014/12/15(月) 18:48:28.19 ID:3+5D9RMi.net
- 隔離ができるならx264スレだってもちっとマシな歩みをしてるわ
- 62 ：名無しさん＠編集中：2014/12/15(月) 18:52:44.38 ID:Sz0nVlW2.net
- 仕組みとかを粛々と話すだけならいいんだが、宗教を押しつけるキチガイやそれをスルーできないキチガイ、
多様性を認められないキチガイなどが降臨するとどんな話題でも荒れるってだけだな。
- 63 ：名無しさん＠編集中：2014/12/15(月) 20:20:18.25 ID:pj6pS+Td.net
- そして毎回作られては落ちる色空間スレ
- 64 ：名無しさん＠編集中：2014/12/15(月) 21:28:24.07 ID:R/V8Q7f5.net
- そんなことより、
TMPGEnc Video Mastering Works 6
本日より体験版を先行公開!
ダウンロード版の発売開始は2014年12月19日を予定しております。
*パッケージ版の発売は2015年2月中を予定しております。
H.265/HEVC による8K映像出力にも対応した映像エンコーダーの最高峰。
4Kそして8K時代の新フォーマット HEVC 出力への対応やH264/AVCの 10bit 4:2:2/4:4:4出力対応。
※本製品は32ビット版OSには対応しておりませんのでご注意ください。
エンコーダーには、オープンソースとして今現在も進化を続け、既に世界中で高い評価を得ているx265を採用しました。
x265のプリセットならびに詳細なオプション設定ももちろん利用可能となっています。
*一部オリジナルと異なります。あらかじめご了承ください。
*入力は4:2:2までとなります。
- 65 ：名無しさん＠編集中：2014/12/15(月) 21:55:25.87 ID:avFb3ztU.net
- 売れないからってこんなところで宣伝っすか？
- 66 ：名無しさん＠編集中：2014/12/15(月) 22:25:30.68 ID:wtZ3Tjb16
- >>64
体験版でH.265エンコしてみたら糞画質だった・・・。
現在・将来の再生互換性を考えると実質使い物にならないし
画質も糞すぎるのでパス
- 67 ：名無しさん＠編集中：2014/12/16(火) 02:15:52.14 ID:o81G4ywL.net
- 実はデコード後に8bitに丸めるときにディザリングしているため、バンディングが消えたように見えているんだけなんだけどね
けど、10bitエンコは8bitエンコと比較してバンディングを小さくできるし、圧縮の効率も高いから
- 68 ：名無しさん＠編集中：2014/12/16(火) 06:34:11.02 ID:MNrkUU+c.net
- gimpはグラデーションをディザリングしている
mad-VRもディザリングをしていた
EVRはしていない
- 69 ：名無しさん＠編集中：2014/12/16(火) 12:05:54.43 ID:6Zc/Sstx.net
- >>64
8k出力とかってあるけど
まだ5k 4kのモニターしかないのに
何に使うのさ
- 70 ：名無しさん＠編集中：2014/12/16(火) 13:37:45.67 ID:o4iGWfkO.net
- 作るツールがなきゃ始まらない
- 71 ：名無しさん＠編集中：2014/12/16(火) 14:41:59.83 ID:vBdFrhWa.net
- >>67-68
レンダラの違いをなくすためLAV Video DecoderでYUV→RGBしてEVRに統一したり、
Avisynthでデコード時のディザリングを排除してみたサンプル。
０．元画像（>>18） GIMPで作った線形の緑グラデーション 1024x576 右上（0,127,0）左下(0,0,0)
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3117.png
・LAV Video DecoderでYUV→RGB32変換させてEVR表示。LAVのDithering ModeはRandom Dithering。
１．8bit420→x265_8bpp→LAV（NV12→RGB32）→EVR
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3127.png
２．8bit420→x265_16bpp→LAV（P010→RGB32）→EVR
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3126.png
３．16bit420→x265_16bpp→LAV（P010→RGB32）→EVR
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3125.png
・Avisynth＋LSMASHSourceで16bit読み込みしてDitherでディザリング無しでRGB24化してAvsPmodでプレビュー
４．8bit420→x265_8bpp→LSMASHSource(YUV420P8)→Dither(ディザ無しYUV420P8→RGB24)→AvsPmodプレビュー
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3128.png
５．8bit420→x265_16bpp→LSMASHSource(YUV420P16)→Dither(ディザ無しYUV420P16→RGB24)→AvsPmodプレビュー
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3129.png
６．16bit420→x265_16bpp→LSMASHSource(YUV420P16)→Dither(ディザ無しYUV420P16→RGB24)→AvsPmodプレビュー
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3130.png
・GIMPの明度のヒストグラムまとめ（左から０、３、６、２、５、１、４）
ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3131.png
8bitソースについて、デコード時のディザリング無しの場合でも絵的に 16bpp（５） ＞ 8bpp（４） になるのは、
16bppの場合はx265_16bpp内部で
8bit入力→16bitへのアップサンプリング→（ディザリング）→10bitへのダウンサンプリング→エンコ
という流れでディザリングが入る（？）のと、内部での丸め誤差等の減少が影響してるという理解であってるかな？
- 72 ：名無しさん＠編集中：2014/12/16(火) 14:48:05.95 ID:vBdFrhWa.net
- 一応>>71の「ディザリング無しでのRGB24化」に使ったavsファイルの内容。間違ってなきゃいいけど。
# Avisynth2.6MT20130928 、 LSMASHSource rev728、masktools-v2.0b1、dither-1.26.5
# mode=?1 : no dither, round to the closest value
file="D:\8bitYV12_x265_8bpp.mp4"
in8enc8=LSMASHVideoSource(file).Dither_convert_yuv_to_rgb(matrix="601",lsb_in=false,output="RGB24",mode=-1)
file="D:\8bitYV12_x265_16bpp.mp4"
in8enc16=LSMASHVideoSource(file,stacked=true,format="YUV420P16").Dither_convert_yuv_to_rgb(matrix="601",lsb_in=true,output="RGB24",mode=-1)
file="D:\16bitYV12_x265_16bpp.mp4"
in16enc16=LSMASHVideoSource(file,stacked=true,format="YUV420P16").Dither_convert_yuv_to_rgb(matrix="601",lsb_in=true,output="RGB24",mode=-1)
#in8enc8
#in8enc16
in16enc16
- 73 ：名無しさん＠編集中：2014/12/16(火) 17:18:24.49 ID:n3NfDKr4.net
- どうでもいいけど
＞LAV Video DecoderでYUV→RGBしてEVRに統一したり、
面倒だからLAVの設定そのままにDirectShowSource使えばいいんじゃないの？
詳しくないけどレンダラを排除できるんじゃない？
- 74 ：名無しさん＠編集中：2014/12/16(火) 19:12:24.34 ID:vBdFrhWa.net
- >>73
DirectShowSourceの存在を忘れかけてた。
Lentoid HEVC Decoderとかも入れてるのでめんどいし、EVRでの見え方がわかれば十分かと。
- 75 ：名無しさん＠編集中：2014/12/16(火) 23:31:39.56 ID:o81G4ywL.net
- >>74
乙
>>8bitソースについて、デコード時のディザリング無しの場合でも絵的に 16bpp（５） ＞ 8bpp（４） になるのは、
ビットレートがわからないので優位な差があるのかどうか分からないけど
一般的にはRGB変換の精度向上と圧縮率の改善した分だけバンディングはましになる
x265ってエンコーダのポスト処理でディザリングされるの？
ちなみに、多階調化のことをアップサンプリングとは言わない
- 76 ：名無しさん＠編集中：2014/12/17(水) 00:03:08.74 ID:VSsHutZU.net
- アニメでよく発生するバンディングを完全に消したいのであれば、
ディザリングライクな処理をポスト処理で強めにかけましょう
圧縮率の効率を無視すれば、8bitエンコでも10bitエンコでもどちらでもいい
- 77 ：名無しさん＠編集中：2014/12/17(水) 01:08:47.33 ID:5/RYhWSW.net
- 最近出たBPGって画像圧縮にHEVCエンコーダが使われてるらしいね
x265だと早くなるのかな
- 78 ：名無しさん＠編集中：2014/12/17(水) 16:05:38.33 ID:dRkqHgIH.net
- avidemuxでh265コーデックを使う方法ってありませんか？
外部エンコーダーを読み込めませんよね
- 79 ：名無しさん＠編集中：2014/12/17(水) 16:08:54.73 ID:B0Y+x53n.net
- Handbrakeでも使ってろ
- 80 ：名無しさん＠編集中：2014/12/17(水) 16:47:21.54 ID:I6NMkah+.net
- >>77
x265有効化したのだと10倍くらい速かった
- 81 ：名無しさん＠編集中：2014/12/17(水) 17:23:16.76 ID:be+zgkRL.net
- x265有効化ってどうやるの？
-eコマンドにx265指定しても入ってないって言われるから、ビルドからやらんといけないのかな
- 82 ：名無しさん＠編集中：2014/12/17(水) 17:40:58.86 ID:I6NMkah+.net
- >>81
ビルドするの面倒だからバイナリうｐするわ
http://kie.nu/2lNt
- 83 ：名無しさん＠編集中：2014/12/17(水) 19:17:27.36 ID:be+zgkRL.net
- >>82
ありがとうー
確かに速いね。デフォのとの画質の違いは俺の目ではわからない。
しかしx265ではモノクロ非対応なのね。
- 84 ：77：2014/12/17(水) 21:48:31.58 ID:fkAgz2vh.net
- H.265が使えて
画像フィルターが使えるソフトってありませんか？
- 85 ：名無しさん＠編集中：2014/12/17(水) 21:51:03.36 ID:dI6k0GlV.net
- >>84
TMPGEnc Video Mastering Works ６
- 86 ：名無しさん＠編集中：2014/12/17(水) 22:01:33.73 ID:be+zgkRL.net
- ffmpeg、handbrake
- 87 ：77：2014/12/18(木) 11:59:09.29 ID:FZe+ecKd.net
- >>85-86
RGBの色補正とかガンマ補正ができてH265ではけるソフトが必要なのですが
handbreakだとできないことないですか？
ffmpegだとGUIがないのでいちいちエンコードしないと
できあがりを確かめられないのではないですか？
TMPGEncは試していないのですが
リアルタイムで色補正を確かめられますか？
- 88 ：名無しさん＠編集中：2014/12/18(木) 12:02:18.71 ID:WNWaTERT.net
- >>87
AviUtl+x265guiEx
- 89 ：名無しさん＠編集中：2014/12/18(木) 12:08:15.69 ID:Kfr5IPNo.net
- >>85 よくわからんが色補正みたいな機能とカット編集みたいな機能とエンコーダとしての機能はグローバルには別々の扱いで
それぞれに優れたソフトがあるものを一緒くたに語ろうとするから、そういうどれも大したことのないのに高いソフトが候補に上がってしまうんじゃね？
- 90 ：名無しさん＠編集中：2014/12/18(木) 14:14:50.92 ID:HuXrXYl4.net
- AvsP系みたいに265でもプレビューしながらフィルター掛けられるソフトがあれば良いよなー。
- 91 ：名無しさん＠編集中：2014/12/18(木) 14:56:46.07 ID:DTu+L3H7.net
- Aviutl
- 92 ：名無しさん＠編集中：2014/12/18(木) 14:57:30.73 ID:RGlKMY/8.net
- 映像フィルタをリアルタイムで掛けたいなら ffpaly で再生すればいい
- 93 ：名無しさん＠編集中：2014/12/24(水) 12:57:36.41 ID:3BsI1+rV.net
- GIGAZINEにx265と開発中の最新版Daalaの比較が行われているけど、暗い部分以外はかなり健闘しているようだな。
ただ、だからと言ってDaalaに乗り換える意味はなさそうだが。
- 94 ：名無しさん＠編集中：2014/12/24(水) 13:25:00.83 ID:Yt/si4kR.net
- オーバーラップして変換するDaalaは、普通のDCTの規格と同じ解像度で比較したらおそらくすごく遅い
- 95 ：名無しさん＠編集中：2014/12/28(日) 14:57:55.82 ID:sPKWU8if.net
- ここのstockholmみたいなザラザラした映像をのっぺりさせずにエンコードするのはどうしたらいいのん？
http://media.xiph.org/video/derf/
- 96 ：名無しさん＠編集中：2014/12/28(日) 15:12:59.98 ID:/eGeT+6u.net
- x265スレで言うことじゃないけど、そういう用途ならx264勧めるな
x265は--tune grain使ってものっぺりする気がするけど、x264はデフォルト設定でもそれなりに残る気がするんだよね
- 97 ：名無しさん＠編集中：2014/12/28(日) 15:14:44.69 ID:/eGeT+6u.net
- >>96は>>95宛
- 98 ：名無しさん＠編集中：2014/12/28(日) 15:21:53.81 ID:ogQbur7N.net
- >>96
気がするってみみっちぃビットレでpsy-rdoq 30は無理だぞ
- 99 ：名無しさん＠編集中：2014/12/28(日) 15:29:19.40 ID:sPKWU8if.net
- >>96
うん現状ではx264でエンコードしてる
- 100 ：名無しさん＠編集中：2014/12/28(日) 17:28:48.54 ID:1c9d8C2/.net
- 簡単に検証してみた
x264の過度な話題はスレチと思うけど、現状の他のエンコーダーとの比較として
Crfだからビットレート揃ってないけど許して
元ソース
画像: ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3133.png
Histogram("Luma"): ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3134.png
x264 CRF16 (35.89 fps, 38027.15 kb/s, 45.7 MiB)
画像: ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3135.png
Histogram("Luma"): ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3136.png
x264 CRF18 --tune grain (28.25 fps, 62455.92 kb/s、75.0 MiB)
画像: ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3137.png
Histogram("Luma"): ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3138.png
x265 CRF 18 --tune grain --rd 4 (6.04 fps, 41868.29 kb/s, 50.3 MiB)
画像: ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3139.png
Histogram("Luma"): ttp://2sen.dip.jp/cgi-bin/upgun/up2/source/up3140.png
サイズはMediaInfo読み
x264はr2525、x265は1.4+222
x265のグレインや細部を保持しようとして色々パラメーター弄ったけど現状では無理と判断したな
当然のことだけど弄れば弄るほど遅くなっていくしね
自分としてもグレインや細部を綺麗に保持してくれるパラメーターがあるのなら教えて欲しい
- 101 ：名無しさん＠編集中：2014/12/28(日) 18:47:14.26 ID:RCbmgmcp.net
- グレインや細部を保持しようとしないから非可逆で高圧縮率なんじゃないの
それを気にしだしたら究極的には可逆になるんだから
- 102 ：名無しさん＠編集中：2014/12/28(日) 20:04:05.65 ID:RCbmgmcp.net
- >>100のx265のlumaを見ると、グレインに関する情報がごっそりと欠落しているようにも見えるけど
時間不変に近い建物や川面のディテールはしっかりと保持されてるともいえるので
高圧縮のコーデックとしては優れているといえるんじゃないでしょうか
- 103 ：名無しさん＠編集中：2014/12/28(日) 21:46:27.58 ID:l+WsMTqk.net
- >>100みたいな検証する人がPSNRとかSSIM使わない理由って何なの
- 104 ：名無しさん＠編集中：2014/12/28(日) 22:06:45.71 ID:2lk6lmSU.net
- みみっちぃビットレとは言うが
x264では細部を残せるビットレートでもx265だとぼかされるのはなぁ……
何にビットレートを割いてるんだよって思う
- 105 ：名無しさん＠編集中：2014/12/28(日) 22:11:00.46 ID:YN13mRZr.net
- だよなぁ
本当細部残したい派にはHEVCは詐欺だわ
正体見たりなんとかだわ
- 106 ：名無しさん＠編集中：2014/12/28(日) 23:39:08.17 ID:RlOS5F2B.net
- x264は出来てから、10年経つんだぜ？
さすがに生まれたてのx265と比べるのは、可哀想ってもんだ。
H.264だって出来た当初はHigh Profileは無くて、MPEG-2と比べて
HDじゃ画質悪いし使えねーって言われてたんだぜ。
そのせいで、初期のBDはみんなMPEG-2使ってた訳で。
High ProfileのBDが市場に出たのは2006年頃だっけ？
H.264の規格が出来たのが2003年。
一朝一夕には出来んよ、もっと長い目で見なきゃ。
さすがに、今のタイミングで詐欺はねーだろ、詐欺は。
5年経ってダメなら、それは詐欺だろうけどさ。
- 107 ：名無しさん＠編集中：2014/12/28(日) 23:42:45.30 ID:YN13mRZr.net
- 既にh264がある世界なのに可哀想って何言ってるんだろ
- 108 ：名無しさん＠編集中：2014/12/28(日) 23:53:54.52 ID:hTve/fif.net
- だからx264が生まれた頃はすでにMPEG2のある世界だったんだよ
同じことだ
- 109 ：名無しさん＠編集中：2014/12/28(日) 23:58:24.37 ID:YN13mRZr.net
- じゃぁ商品化レベルにはまだ2年もかかるんだ
- 110 ：名無しさん＠編集中：2014/12/29(月) 00:11:05.01 ID:sXZ5Om57.net
- そんなもんだろうな
- 111 ：名無しさん＠編集中：2014/12/30(火) 12:02:41.25 ID:3s50KZrJ.net
- clよりgccのほうが速いな
- 112 ：名無しさん＠編集中：2015/01/01(木) 16:31:02.99 ID:aQ8V+r+g.net
- SSE4向けに高速化コードが導入されてってるけど
うちのCPUにはSSE4が無いンゴ
- 113 ：名無しさん＠編集中：2015/01/01(木) 17:04:21.92 ID:NjPLC9SC.net
- >>112
そんなCPU投げ捨てろ
- 114 ：名無しさん＠編集中：2015/01/01(木) 17:22:13.39 ID:aQ8V+r+g.net
- 今年出るはずの新APUを狙ってるンゴ
- 115 ：名無しさん＠編集中：2015/01/02(金) 16:59:42.67 ID:It94o4Tw.net
- すいません。編集初心者です。
30分の動画編集で出力時
ｘ264 で10分
ｘ265 で1時間
も違いが有ります。 ｘ265での編集を途中でやめた場合
265 STATS CUTREE というわけの分からない物ができ動画になりません。
すいませんが何が間違っているか宜しくお願いいたします。
ついでにｘ265のほうが優れているんですよね？
- 116 ：名無しさん＠編集中：2015/01/02(金) 17:01:30.17 ID:pAvkytfb.net
- 100％純粋にスレが違う
- 117 ：名無しさん＠編集中：2015/01/02(金) 17:05:03.37 ID:rQy/BXWa.net
- 時間がかかるのはそんなもん。
出力を途中でやめた場合も.265をL-SMASHでmuxすればmp4に出来る。
- 118 ：名無しさん＠編集中：2015/01/02(金) 17:49:41.70 ID:YfBKdX/c.net
- >>115
>>105
らしい
肌のこまかいシミや毛穴にこだわるなら使わないほうがいいかも
- 119 ：名無しさん＠編集中：2015/01/02(金) 18:34:45.13 ID:It94o4Tw.net
- >>117
そうですか時間はしょうがないのですね。
mp4できました、ありがとうございました。
- 120 ：名無しさん＠編集中：2015/01/10(土) 11:19:23.60 ID:vZn5UKjV.net
- >>118
細部残したいなら264はやめた方が良いよ
- 121 ：名無しさん＠編集中：2015/01/10(土) 12:04:29.44 ID:lqmIyQYD.net
- 逆だろ
- 122 ：名無しさん＠編集中：2015/01/11(日) 00:56:15.69 ID:9Qo5kiNK.net
- >>121
265も264も細部保持には向いていないって意味だろｗ
- 123 ：名無しさん＠編集中：2015/01/11(日) 21:11:00.39 ID:6lAcQWy5.net
- http://x265.readthedocs.org/en/default/cli.html#cmdoption--interlaceMode
1.4+263だとまだ警告出るし、helpにもオプションが書かれてないけど、
ドキュメントのほうではいつのまにかインタレのEXPERIMENTALって取れてるのか。
ドキュメントで
--interlaceMode
になってしまってるのは間違いだね。使ってみたらエラーが出た。
どこで変わったのかは知らんけど、実際には--interlace。
- 124 ：名無しさん＠編集中：2015/01/11(日) 21:43:57.24 ID:64y+nl04.net
- 1.4+285 だと特にエラーでないけどhelpに出ない
- 125 ：名無しさん＠編集中：2015/01/12(月) 14:50:25.27 ID:vSpS7rUl.net
- x265(1.4+285)のcrf23とx264(r2491)のcrf26をmediumで比較してみた
(どちらも3Mbpsくらいになるようにcrfを調整)
このスレじゃx265は細部保持に向かないって評価だけど
広いグラデーション部は細部(グレイン)を保持しなくて
ある程度にわたって構造のある部分は保持する
という挙動でモスキートノイズも少ないし、輪郭周りの荒れも少ないから
ぱっと見の印象は悪く無いと思った
ただx265が15.7fpsでx264が53.5fpsで3倍以上
速度差があったからもう少し速くなってほしい
CPUは3930k@4.1GHz
試しに速度もビットレートも同じくらいになるように
x264をcrf25でslower(18.6fps)にしてみたらx264も
輪郭周りの荒れは改善したけどx265ほどではなかった
モスキートノイズ嫌いな自分にはx265はかなり魅力的
- 126 ：名無しさん＠編集中：2015/01/12(月) 14:56:36.36 ID:IFQJ7rSI.net
- 必死だなｗ
- 127 ：名無しさん＠編集中：2015/01/12(月) 15:06:48.41 ID:3LGRY5Wd.net
- 「必死だな」というセリフに「ｲｯﾃﾖｼ」並の化石臭を感じる
- 128 ：名無しさん＠編集中：2015/01/12(月) 15:10:08.37 ID:t2lxEDhn.net
- >>125
そのグレンノイズの再現性を求める人もいるのが難しいところ。
- 129 ：名無しさん＠編集中：2015/01/13(火) 00:39:01.31 ID:2T6Ewg6F.net
- >>128
そうね、自分の望む進化の方向に進まないのは残念だろうね
分野は違うけど自分もそういうのあるし
でもx265はまだ変化する可能性があるだろうから
希望はあるよね
- 130 ：名無しさん＠編集中：2015/01/13(火) 00:39:43.21 ID:rFCd3Ndy.net
- >>125
265は輪郭周りがきれいだから滑らかできれいに見えるね。
ノイズリダクションするならx265のほうがいいと思う。
ただ暗闇で黒いものが動くシュチュエーションで、動く黒い物体が破綻しやすいのが気になるかな。
ビットレート盛っても8bitだと厳しい。
と言ってもそういう場面はたまにしかないし、10bitならなんとかなるけど。
- 131 ：名無しさん＠編集中：2015/01/21(水) 11:53:27.80 ID:Cp3EnOdw.net
- ffmpegでH.265で出力したいのですが
mkvとかmp4ではけますか？
どういうコマンドライン使えば良いですか？
黎明期なのかあまり情報がかからないので教えてください
- 132 ：名無しさん＠編集中：2015/01/21(水) 14:44:46.92 ID:r3fprR1P.net
- >>131
ttps://trac.ffmpeg.org/wiki/Encode/H.265
- 133 ：名無しさん＠編集中：2015/01/21(水) 23:34:22.58 ID:EQhzo9pq.net
- >>132
ありがとうございます。
早速試してみたのですが
もとはビデオカメラで撮影したH.264動画なのですが
屋内で撮影しているため、かなりノイジーな動画だったのですが
H.265にするとそのノイズがなくなってしまったのですが
これは一体どういうことでしょうか？
H.264再圧縮だとこういうことはないのですが
- 134 ：名無しさん＠編集中：2015/01/21(水) 23:42:04.03 ID:EQhzo9pq.net
- 145MBの3分の動画が9.6MBになってしまいました
でもクオリティーは下がるどころか
なぜかノイズが消えてむしろ上がっています。
エンコード速度はH.264と大差ありません。
こんなもんなのでしょうか？
- 135 ：名無しさん＠編集中：2015/01/21(水) 23:43:54.25 ID:vMaKaQ18.net
- そんなもんだからさっさと消えろ
- 136 ：名無しさん＠編集中：2015/01/22(木) 00:48:59.11 ID:ZX9UMpSA.net
- Death-gar!!!!!!!!!
- 137 ：名無しさん＠編集中：2015/01/22(木) 00:52:21.92 ID:gtM3L5gV.net
- revがとうとう400超えたぜ
- 138 ：名無しさん＠編集中：2015/01/22(木) 01:08:23.86 ID:bpV1XziQ.net
- revってーかdistance・・・
- 139 ：名無しさん＠編集中：2015/01/22(木) 11:09:28.88 ID:AuP513EH.net
- >In 1.4 there also appeared an incomplete analysis re-use feature.
>This will be completed and further improved in the coming weeks.
とはなんだったのか
- 140 ：名無しさん＠編集中：2015/01/22(木) 11:15:00.53 ID:T/wflB7B.net
- Added 10bit support to ssse3 dct16 and dct32 intrinsics
WARNING:My system is old and limited to sse3 so this is untested!
I will be happy to fix any errors found by anyone else.
- 141 ：名無しさん＠編集中：2015/01/23(金) 11:54:09.02 ID:AOiwwBn2.net
- 誰かまともなマシンを買い与えてあげるべき
- 142 ：名無しさん＠編集中：2015/01/24(土) 09:51:40.47 ID:OEiKYB+j.net
- AMDだったらK10以前、IntelだったらPrescott以前か
さすがに買い換えモードだな
- 143 ：名無しさん＠編集中：2015/01/24(土) 14:32:58.74 ID:Lh8ZUPOG.net
- 総合セキュリティ対策ソフトの常駐と各種ソフトのアップデート確認だけで起動で苦しむPCだろうな
- 144 ：名無しさん＠編集中：2015/01/24(土) 14:50:27.89 ID:blyWxHOz.net
- SSSE3未対応とか、そんな化石捨てちまえ。
- 145 ：名無しさん＠編集中：2015/01/24(土) 14:59:09.33 ID:j4L2pf4I.net
- k10はまだまだ現役
- 146 ：名無しさん＠編集中：2015/01/24(土) 23:48:07.58 ID:BbzsC8sU.net
- 実際、SSE2でも十分な関数も多いし、そっちの最適化を頑張ってくれたらいいんじゃないか
- 147 ：名無しさん＠編集中：2015/01/30(金) 11:37:18.94 ID:EvYIqFIp.net
- Baka Encoder
ttp://x265.ru/en/baka-encoder/
- 148 ：名無しさん＠編集中：2015/01/30(金) 13:37:14.12 ID:kAWUe4X9.net
- チルノ？
- 149 ：名無しさん＠編集中：2015/01/30(金) 14:42:28.20 ID:Z/2fDDwV.net
- 日本語がやや面白い
- 150 ：名無しさん＠編集中：2015/01/31(土) 11:46:09.61 ID:9lXzgTIj.net
- 1.5はpsy-rdデフォルトになるみたいね
- 151 ：名無しさん＠編集中：2015/02/03(火) 17:34:10.64 ID:4iNHYEod.net
- x265でインタレ保持するときってAvisynthでフィールド分離して渡すやり方であってる？
なんかすげー変な作り方しないとまともに作れないんだが。
- 152 ：名無しさん＠編集中：2015/02/03(火) 17:54:20.98 ID:Ps3AvF+y.net
- そのまま渡せばいいと覆う。
- 153 ：名無しさん＠編集中：2015/02/04(水) 21:19:21.26 ID:uAmcWd69.net
- 今のx265ってインタレ保持できるの？
ドキュメントは古いオプション（--interlaceMode）のまま放置されてるし、ヘルプにも--interlaceは出てこないけど。
- 154 ：名無しさん＠編集中：2015/02/04(水) 21:58:42.31 ID:oofwkzVJ.net
- x265 --log-level full --help
- 155 ：名無しさん＠編集中：2015/02/04(水) 22:07:21.96 ID:uAmcWd69.net
- >>154
うあああ、--log-levelって--helpにも作用するのか・・・知らなかった。ありがとう。
- 156 ：名無しさん＠編集中：2015/02/05(木) 06:34:57.37 ID:+Bw05sGC.net
- ただ、やってみるとわかるけど、インタレ保持エンコしても再生時に変になるよ
- 157 ：名無しさん＠編集中：2015/02/05(木) 07:21:17.33 ID:/BrmvEQ5.net
- H.265にはMBAFFも無いし、インターレースに関してはH.264より退化していると思う
- 158 ：150：2015/02/05(木) 09:11:08.58 ID:5VEVdr6W.net
- >>156
再生時変にならないように作ったら150の方法になったんだけどこれって正しいの？って事です。
- 159 ：名無しさん＠編集中：2015/02/05(木) 12:22:47.66 ID:+E7p0hZr.net
- 60iの実写アイドルDVDとかインタレ解除エンコしてみたけど、お肌の質感が失われてのっぺり画質になってもた
- 160 ：名無しさん＠編集中：2015/02/05(木) 12:41:15.90 ID:cQB/YdWZ.net
- 265は細部保持には向かない
素直に264使え！
- 161 ：名無しさん＠編集中：2015/02/05(木) 16:07:32.65 ID:V8sJ0U6T.net
- >>158
ドキュメントの説明には
> HEVC encodes interlaced content as fields. Fields must be provided to the encoder
> in the correct temporal order. The source dimensions must be field dimensions
> and the FPS must be in units of fields per second.
> The decoder must re-combine the fields in their correct orientation for display.
とあるからフィールド分離して渡せってことだとは思うんだけど、
前に色々試したら結局うまくいかず、エンコード方法が悪いのか
デコーダが悪いのかもよくわからず終わった覚えがある。
- 162 ：名無しさん＠編集中：2015/02/05(木) 17:03:33.70 ID:mkffcGFU.net
- 今ん所デコーダが悪い
H265のインターレスソースをちゃんと表示してくれるデコーダがない
- 163 ：名無しさん＠編集中：2015/02/06(金) 13:36:36.35 ID:/UDbQqKz.net
- 実写はx264
アニメはx265って感じやね
- 164 ：名無しさん＠編集中：2015/02/06(金) 13:47:53.28 ID:98YNx0Ak.net
- 何言ってんだこいつ？
- 165 ：名無しさん＠編集中：2015/02/06(金) 13:57:18.34 ID:HIZ8stWn.net
- 俺設定が１つしかないんじゃね？
>163 にはソースに合わせて設定変えるっていう発想が抜け落ちてんだよ
- 166 ：名無しさん＠編集中：2015/02/06(金) 22:37:01.09 ID:q8KZcoyr.net
- 実写はxvid
- 167 ：名無しさん＠編集中：2015/02/06(金) 23:14:14.68 ID:qPtmmmLB.net
- 「SDなら」なら同意
- 168 ：名無しさん＠編集中：2015/02/07(土) 10:53:23.69 ID:LeZNucG0.net
- 実写はエンコしないが最強、異論は
- 169 ：名無しさん＠編集中：2015/02/07(土) 10:54:20.56 ID:sHPnGPqt.net
- 全部ソースが最強だろ
エンコなんて無駄
- 170 ：名無しさん＠編集中：2015/02/07(土) 11:44:17.68 ID:jbmGyT0y.net
- お薬多めに出しときますね。
- 171 ：名無しさん＠編集中：2015/02/07(土) 11:52:34.95 ID:SOkkXwvX.net
- おお…
- 172 ：名無しさん＠編集中：2015/02/07(土) 11:54:20.79 ID:UPuytnzV.net
- 「つける薬」が見つかったのだろうか・・・
- 173 ：名無しさん＠編集中：2015/02/07(土) 15:08:12.51 ID:v1bAhlEV.net
- ソースもエンコされているんですがそれは・・・
- 174 ：名無しさん＠編集中：2015/02/07(土) 19:23:33.73 ID:cuf9ri6x.net
- そーっすね(∀｀*ゞ)ﾃﾍｯ
- 175 ：名無しさん＠編集中：2015/02/08(日) 18:57:56.18 ID:iqawigcu.net
- またavsは読めないん？
- 176 ：名無しさん＠編集中：2015/02/08(日) 22:23:35.72 ID:KLrqCftn.net
- avs4x265 を使えばフィルタかましたのをx265に渡してくれる
- 177 ：名無しさん＠編集中：2015/02/08(日) 23:20:42.07 ID:B9iQImsh.net
- avs2pipemod使えばいいだけやん。
- 178 ：名無しさん＠編集中：2015/02/12(木) 07:10:50.14 ID:8Q1fndck.net
- 1.5リリースおめ
- 179 ：名無しさん＠編集中：2015/02/12(木) 11:46:28.36 ID:D7fglN+V.net
- ttp://forum.doom9.org/showpost.php?p=1709208&postcount=1700
>We're pleased to announce that x265 has reached another milestone! The v1.5 release of x265 has major improvements in Main10 compression efficiency and performance over the 1.4 release, general improvements in Main performance.
>Psycho-visual optimizations are now enabled by default in the presets which can support it (medium, slow, slower, veryslow and placebo).
- 180 ：名無しさん＠編集中：2015/02/12(木) 13:11:54.91 ID:+IYTLA1r.net
- >>179
もう本格的に移行してもいいレベルですな
- 181 ：名無しさん＠編集中：2015/02/12(木) 15:12:28.66 ID:OFRAfQbR.net
- ボケボケ克服したら起こしてくれ
- 182 ：名無しさん＠編集中：2015/02/12(木) 16:54:29.34 ID:8Q1fndck.net
- じゃ、今じゃん
- 183 ：名無しさん＠編集中：2015/02/12(木) 21:47:31.95 ID:sSGVvYqP.net
- UMS+Androidのストリーム再生が、トラスコ無しで出来る事が分かったので、
SDサイズの物は、x265を試験的に使い始めた。
SDサイズなら、slowベースのプリセットでも、
50～60fsp位出るんで、まぁ常用範囲。
720p以上になるとそれなりに時間かかるし、
今の画質見ると、まだ当分264かも。
- 184 ：名無しさん＠編集中：2015/02/13(金) 00:58:54.97 ID:i7lnbc45.net
- 16bppと8bppとは違いは何でしょうか？
- 185 ：名無しさん＠編集中：2015/02/13(金) 01:15:12.59 ID:aMe6kvlc.net
- >>184
10bitのH.265 Main 10 Profileで出力するのが前者で、8bitのMain Profileが後者
- 186 ：名無しさん＠編集中：2015/02/13(金) 01:20:04.65 ID:i7lnbc45.net
- >>185
お早い返答感謝いたします
- 187 ：名無しさん＠編集中：2015/02/13(金) 12:15:28.31 ID:B5RkqH22.net
- x265 の進化具合が気になったので x265 1.3～1.5 でエンコしてみた。
ソースはアニメのOPだけTrimしてエンコ。音声もAACのままMuxしてMP4に格納。
x265は16bppを使って引数には
--crf 20 --preset medium --tune ssim --ssim --aq-mode 2 --aq-strength 0.6 --csv logfile.csv
を与えた。
16bppは1.4中盤くらいまではビットレートの割り当てに不具合あったから無駄に盛られていたせいもあって
ファイルが大きめだったけど、それ以降はすっきり。エンコ速度も最適化を繰り返して速くなったわなー
っておもった。まる。
FPS, Bitrate, SSIM, Filesize, x265 version
9.8 4728.14 0.991417 56,661,323 1.3+212-54ad38a84a69
9.19 4671.59 0.991204 56,018,591 1.4+5-eebb372eec89
12.54 3628.91 0.989977 44,168,160 1.5+11-9ab104096834
- 188 ：名無しさん＠編集中：2015/02/13(金) 19:22:33.30 ID:vsAtZGWM.net
- cpu何つかってんの？
- 189 ：名無しさん＠編集中：2015/02/13(金) 20:03:39.71 ID:i7lnbc45.net
- うちは全然遅くてまだまだ厳しいわ
- 190 ：名無しさん＠編集中：2015/02/13(金) 20:14:59.11 ID:n2IAIEvl.net
- ver1.5現在、Haswell世代でAVX2の有無でどれだけ差が出るか知りたいな
手元にHaswellコア無くて辛い
- 191 ：186：2015/02/13(金) 20:38:53.20 ID:B5RkqH22.net
- CPU書き忘れた!
FX-8350をOCして4.3Gにしてます。
AVX2が無いからその分遅いハズorz
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
- 192 ：名無しさん＠編集中：2015/02/13(金) 20:51:36.18 ID:MUDSvsev.net
- G1820だと再生すら厳しいわ
- 193 ：名無しさん＠編集中：2015/02/13(金) 22:38:24.40 ID:fvCHBunA.net
- 適当にベンチ 詳細はテキストに
ソースhttps://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
medium
1.4 encoded 313 frames in 21.51s (14.55 fps), 566.57 kb/s, SSIM Mean Y: 0.9284311 (11.453 dB)
1.5 encoded 313 frames in 23.31s (13.43 fps), 567.09 kb/s, SSIM Mean Y: 0.9284593 (11.454 dB)
slow
1.4 encoded 313 frames in 58.33s (5.37 fps), 562.37 kb/s, SSIM Mean Y: 0.9320865 (11.680 dB)
1.5 encoded 313 frames in 78.56s (3.98 fps), 563.25 kb/s, SSIM Mean Y: 0.9319049 (11.669 dB)
slower
1.4 encoded 313 frames in 169.04s (1.85 fps), 560.95 kb/s, SSIM Mean Y: 0.9336557 (11.782 dB)
1.5 encoded 313 frames in 190.41s (1.64 fps), 561.85 kb/s, SSIM Mean Y: 0.9336306 (11.780 dB)
x264 core:142 r2495 6a301b6
veryslow
x264 [info]: SSIM Mean Y:0.9145891 (10.685db)
encoded 313 frames, 28.14 fps, 583.28 kb/s
http://www.dotup.org/uploda/www.dotup.org5392489.txt
- 194 ：名無しさん＠編集中：2015/02/13(金) 22:42:23.94 ID:fvCHBunA.net
- >>193
×http://www.dotup.org/uploda/www.dotup.org5392489.txt
○http://www.dotup.org/uploda/www.dotup.org163738.txt
- 195 ：名無しさん＠編集中：2015/02/14(土) 10:20:59.71 ID:1Tpw1Sp4.net
- >>193
乙
slow一つでいいからx264のも貼ってほしいな。
やはりx264との比べたほうが速度の感じが分かって嬉しい
- 196 ：名無しさん＠編集中：2015/02/14(土) 12:21:27.59 ID:CWyUdjYK.net
- mediumの時点でx264のSSIMを超えるので、x264との速度比較データとしては既に十分でしょ
- 197 ：名無しさん＠編集中：2015/02/15(日) 13:32:55.83 ID:OA7l1aGg.net
- テキストのほうにはちゃんと書かれてたのね。
確認不足でしたは。
- 198 ：名無しさん＠編集中：2015/02/15(日) 17:33:18.79 ID:OA7l1aGg.net
- 192で興味がわいたからやってみたけど、かなり早いし底力があるね。
（実写ソース）1400x1080をx264の720p crf24と同じぐらいのサイズになるようにcrfを調整してやってみたけど
結構いいぐあいにエンコできた（preset：faster）。
SIMM値とかは全然見てないけどかなり凄い。
- 199 ：名無しさん＠編集中：2015/02/16(月) 00:06:07.13 ID:LiWPNN++.net
- ボケボケ直ったら起こして
- 200 ：名無しさん＠編集中：2015/02/16(月) 00:26:52.65 ID:lNcwkNQM.net
- 底力？結構いいぐあい？かなり凄い？
おまえ何言いたいねん
- 201 ：名無しさん＠編集中：2015/02/16(月) 00:31:21.57 ID:wVYKwn3E.net
- 俺もやってみたけど
ボケるね
- 202 ：名無しさん＠編集中：2015/02/16(月) 17:14:31.68 ID:JoV9ue0h.net
- fasterのオプションを確認したら
動き検索がhexとかb-adaptが無効とか
使い始めたころのx264を連想した。
- 203 ：名無しさん＠編集中：2015/02/16(月) 17:16:25.45 ID:wVYKwn3E.net
- まだまだ実用には遠いなあ
- 204 ：名無しさん＠編集中：2015/02/16(月) 17:52:46.29 ID:8JAUyssJ.net
- 「ボケる」「細部が保持できない」って言ってる人は、具体的にどれくらいのことを気にしてるんだろうな。
>>100みたいな例はわかるけど、「これが俺の気にするx265のボケだ！」っつう
具体的なサンプルを出してみてほしいとこだ。
- 205 ：名無しさん＠編集中：2015/02/16(月) 18:03:23.69 ID:QLeVi08p.net
- 頭大丈夫か？
- 206 ：名無しさん＠編集中：2015/02/16(月) 19:19:38.83 ID:uSx59Joy.net
- x264も2コアとか1コアの時は少しプリセット詰めるとやってられなかったし
これも実用ならHBMや6コア～待ちかなぁ
- 207 ：名無しさん＠編集中：2015/02/16(月) 19:36:16.63 ID:MEeM/RzH.net
- >>204
SD解像度の昔のアニメみたいなグレインが多くて
かつ、背景が細かく書き込まれた作品だと背景がボケちゃうってことかと。
1.5で試した感じだと問題ないし、実際見比べても元のTSに近いのはHEVCだと思うけど。
- 208 ：名無しさん＠編集中：2015/02/16(月) 20:00:25.35 ID:MJ0CvoIq.net
- >>204
今のHDアニメでも背景の模様がボケるし、実写でも背景の陰影？みたいな色の濃淡がボケる
x264と同じぐらいビットレート盛るとパッと見同じぐらいの画質になるけど>>100の空のような平坦な面では四角くくりぬかれたようにツルツルの部分がある
x265はただでさえ遅いのにx264と同じぐらいビットレート盛っても平坦な面ではx264が画質が上、平坦な面以外ではx264と同等以上、総合的にみてx264が上って判断になる
それに全く縮まないなら使うメリットを見いだせない
x264と同等画質で6～7割のビットレートになるなら使う意味を見いだせるけど
以上、あくまでも個人の意見だから人によって差があると思う
- 209 ：名無しさん＠編集中：2015/02/16(月) 20:03:29.51 ID:MJ0CvoIq.net
- 書き忘れたけど
ver1.4と比べてver1.5は若干画質が良くなってる気がする
psy-rdがデフォルトで有効化された影響かどうかは知らないけど
- 210 ：名無しさん＠編集中：2015/02/16(月) 20:09:57.98 ID:MJ0CvoIq.net
- 今自分のレス見返したけど陰影って影のことだよな・・・
影じゃなくて壁のシミ等の細かい模様と読み替えてくれ
- 211 ：名無しさん＠編集中：2015/02/16(月) 21:10:35.29 ID:wVYKwn3E.net
- ビットレート盛ってエンコしても細部が潰れるだけじゃなく全体がボケる
背景の潰れ具合とかを見てみるとノイズフィルタかけた時のような丸まりがある
- 212 ：名無しさん＠編集中：2015/02/16(月) 21:17:33.45 ID:JoV9ue0h.net
- デブロッキング・フィルタの調整とかしても？
- 213 ：名無しさん＠編集中：2015/02/16(月) 21:18:48.66 ID:wVYKwn3E.net
- そもそも0:0でいじってない
- 214 ：名無しさん＠編集中：2015/02/16(月) 21:25:57.59 ID:JoV9ue0h.net
- いや、いじれよｗ
- 215 ：名無しさん＠編集中：2015/02/16(月) 21:27:58.42 ID:wVYKwn3E.net
- 何でデフォで0:0なのにいじる必要があるのか
意味が分からん0がデフォって普通に考えたら一番影響の少ない値って考えそうなものだろ
- 216 ：名無しさん＠編集中：2015/02/16(月) 22:01:47.08 ID:BlfcXmgm.net
- そう考えるのはいいけど、事実問題でるなら弄るべきじゃないの。
デフォ値はあくまで標準的に今現在は差し障りの無い数値であって、絶対的な保証をしている物でも無いし。
とは言っても「だからこそ」まだ実用では無いとも言えるのかもしれないけどなｗ
- 217 ：名無しさん＠編集中：2015/02/16(月) 22:07:25.08 ID:aFAqruLf.net
- そこ弄ったらボカされなくなるの？
- 218 ：名無しさん＠編集中：2015/02/16(月) 22:17:26.62 ID:wVYKwn3E.net
- >>216
確かに
また機会があればやってみます
- 219 ：名無しさん＠編集中：2015/02/16(月) 22:33:13.75 ID:Rk1rrNiy.net
- New 1.5 version of x265
ttp://x265.ru/en/%D1%80%D0%B5%D0%BB%D0%B8%D0%B7-x265-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8-1-5/
- 220 ：名無しさん＠編集中：2015/02/16(月) 22:35:14.68 ID:JoV9ue0h.net
- >>216
けどまぁ、完成度が高いと言われているx264ですらそこまで賢くはないから
それを求めるのは酷な気がする。
- 221 ：名無しさん＠編集中：2015/02/24(火) 10:38:04.36 ID:oSz6LwXq.net
- 多数ノードに関する大変更が入ったね
- 222 ：名無しさん＠編集中：2015/02/24(火) 12:08:34.41 ID:VrvV/5EL.net
- >>221
それはどんな変化をもたらすの？
- 223 ：名無しさん＠編集中：2015/02/24(火) 15:42:11.18 ID:GhyaPTXl.net
- ボケボケ直ってるね
- 224 ：名無しさん＠編集中：2015/02/24(火) 23:28:29.84 ID:X8HQdh5w.net
- ところでこの板ないしスレの移行先の話って出てきてるの？
- 225 ：名無しさん＠編集中：2015/02/25(水) 01:10:36.52 ID:NdnOYylp.net
- >>223
最近手を出してなかったがどのあたりのrevからボケてて,いつ治ったんだい？
自分で検証する時間がなくて。
良ければ教えて下さい
- 226 ：名無しさん＠編集中：2015/02/25(水) 13:39:21.69 ID:gzIAb+QO.net
- ボケボケ言ってるのはAVCでもかたくなに8x8dct使わなかったのかな
- 227 ：名無しさん＠編集中：2015/02/26(木) 12:00:48.34 ID:2WUDoVq9.net
- 改めて見てみたけど、1080pとか4kクラスの高解像度だとほぼ問題ないけど
480pとか、低解像度だとやっぱ背景の細かいところ（壁のシミとか、木の筋とか）が明らかに潰れるかな
- 228 ：名無しさん＠編集中：2015/02/26(木) 12:12:07.83 ID:LFQcYuya.net
- >>227 ・・・いや、まさかと思うけど
それ480の実サイズ（再生ソフトの画面サイズを480）で見てるんだよな？
- 229 ：名無しさん＠編集中：2015/02/26(木) 12:30:21.52 ID:2WUDoVq9.net
- >>228
ドットバイドットと全画面両方でx264とx265 720x480（par10:11 654x480表示)を24p変換で見比べ
x264はcrf19からcrf22 subme9からsubme11
x265はcrf19から22 subme3からsubme7
crf22以下で圧縮重視ならx265でいいと思うけど、
より忠実に圧縮するような目的だと、x264 subme9以上の方が明らかに元動画に近く見える。
まあ元の素材によりけりなのかもね
- 230 ：名無しさん＠編集中：2015/02/26(木) 12:45:14.75 ID:2WUDoVq9.net
- まあ壁のシミなんて見ないから気にはならんけどねw
ノイズが減って見やすくはなるし、どっちでもいいとは思うけど。
- 231 ：名無しさん＠編集中：2015/02/26(木) 14:31:39.82 ID:XenVGcYW.net
- バカだコイツ
- 232 ：名無しさん＠編集中：2015/02/26(木) 15:55:37.64 ID:v5fmOFKG.net
- MPEG2→H264のときも最初は十分なビットレートではMPEG2のほうが画質がいいとか言われてきたし、
これからのエンコーダーの進化に期待ですな
- 233 ：名無しさん＠編集中：2015/02/26(木) 17:11:22.30 ID:j7a/v8Ed.net
- >>229
またcrf君かよ、、、
何度論破されてもしつこいな、この馬鹿は
- 234 ：名無しさん＠編集中：2015/02/26(木) 17:14:34.46 ID:RhHk9IyB.net
- >>233
画質比較するときのレギュレーション作ってくれるとありがたいな。
- 235 ：名無しさん＠編集中：2015/02/26(木) 19:40:03.56 ID:J4al8Vpo.net
- >>233
x264スレでもかつて似た流れがあったけど、基準と実例を上げてくれないと誰も賛同しないと思う
俺としてはエンコーダーが全く違うんだし必ずしもビットレートを揃える必要は無いと思ってる
特に個人的なx265のメリットはx264と比べて縮むってことだからcrfだけ合わせておいて調べるのもアリだと思う
例えばx264比で7割のサイズになれば十分って考えるなら10:7のビットレートでエンコして見比べたりSSIM見たりするのはアリだと思う
- 236 ：名無しさん＠編集中：2015/02/26(木) 22:31:22.03 ID:j7a/v8Ed.net
- >>235
エンコーダーが違うからこそビットレート揃えて比較するんですけど・・・
小学校理科レベルの話だぞこれ。
「crf値を同じにすればいいや」と発想した時点で、小学校理科からやり直せと
それと、「x265のメリットはx264と比べて縮む」ことをメリットとするためには
画質を同じにして両者を比較しなければならないでしょ？
でも画質を定量的定性的に同一とすることは困難なわけ。
ならば、同じ課題を和文和訳して、
「x265とx264でのエンコ後ファイルサイズを同じにして、両者の画質の優劣を肉眼で比較」すればいい。
ファイルサイズを(ほぼ)同一にすることは簡単に出来る。
- 237 ：名無しさん＠編集中：2015/02/26(木) 22:39:45.47 ID:sqS8ZRO0.net
- そもそもcrfてx264とx265の基準は違うよね？
x265でもrev変わる度にコロコロ基準が変わってたんだから
素人考えだけと2passでビットレート揃えて比較した方がいいと思うわ
- 238 ：名無しさん＠編集中：2015/02/26(木) 22:44:03.65 ID:V4C8fjYf.net
- crf君って誰の事？
- 239 ：名無しさん＠編集中：2015/02/26(木) 23:56:16.68 ID:2WUDoVq9.net
- >>236
いやサイズ合わせて比較はしたけど、売りは半分のサイズで同一の画質だから
そういう比較ってあんま意味ないと思ったんだわ。
それにcrfの値も17から22の複数の範囲で比較してるから、同じにして比較しただけってわけじゃない。
まあ同サイズでも差は縮まれど、若干ボケてるのに変わりはないけど。
いずれにせよ今のところ>>229のとおりの感想で変わりはないかな。
- 240 ：名無しさん＠編集中：2015/02/27(金) 12:01:51.96 ID:hrTT3BWv.net
- 一気にAVX2最適化が入った
- 241 ：名無しさん＠編集中：2015/02/28(土) 23:30:53.25 ID:3H8+CmKI.net
- まだまだいろいろな面で実用的では無いのは間違いない
あと数年して使い物になるようになったらノコノコやってくることにする
MPEG-2→Xvidが2007年
Xvid→H.264が2009年
H.264→H.265が2017年ぐらいに使い物にやるといいね
- 242 ：名無しさん＠編集中：2015/02/28(土) 23:45:26.32 ID:uyDHWEaA.net
- 使いこなせないとかすげー滑稽烏骨鶏
- 243 ：名無しさん＠編集中：2015/02/28(土) 23:52:18.74 ID:N49SIjdN.net
- 登場時の完成度でいえば異次元（良い）だけども＞x265
- 244 ：名無しさん＠編集中：2015/03/01(日) 07:06:20.30 ID:B+Xic6VD.net
- 画質気にしなければサイズ縮むし良いけどなx265
- 245 ：名無しさん＠編集中：2015/03/02(月) 12:02:57.79 ID:GiPvcYxI.net
- バカばっか
- 246 ：名無しさん＠編集中：2015/03/03(火) 21:38:09.04 ID:Ct3mc1Pb.net
- CPU： i7-4702MQ（using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2）
ツール： AviUtl 1.00＋x264guiEx2.25＋x265guiEx3.53
ソース： 1920x1080 2018frames
オプション：--preset slow --tune ssim --ssim
x265 （--crf 20）
1.4+542
8bpp 15:59.29（2.10 fps） 4956.11kb/s SSIM: 0.9930834 (21.601 dB)
16bpp 32:13.27（1.04 fps） 5047.93kb/s SSIM: 0.9945075 (22.602 dB)
1.5+12
8bpp 16:05.72（2.09 fps） 4956.11kb/s SSIM: 0.9930834 (21.601 dB)
16bpp 31:39.65（1.06 fps） 5047.93kb/s SSIM: 0.9945075 (22.602 dB)
1.5+128
8bpp 15:57.30（2.11 fps） 4997.25kb/s SSIM: 0.9931251 (21.627 dB)
16bpp 31:20.33（1.07 fps） 5085.05kb/s SSIM: 0.9945372 (22.626 dB)
1.5+128 （--asm avx,fma3,lzcnt,bmi2）←AVX2だけ外してみた
8bpp 17:18.11（1.94 fps） 4997.25kb/s SSIM: 0.9931251 (21.627 dB)
16bpp 32:29.70（1.04 fps） 5085.05kb/s SSIM: 0.9945372 (22.626 dB)
x264 r2525kMod （--crf 23）
8bit 02:51.39（11.77 fps） 4206.91kb/s SSIM:0.9937000 (22.007db)
10bit 04:31.57（7.43 fps） 4126.43kb/s SSIM:0.9945697 (22.652db)
軽めの作業しながらの一発勝負。presetは両方ともslowにしてみた。
x264の方はSSIMが同じくらいになるcrfを選んだけど、x264の方がかなり縮んでるな・・・。
- 247 ：名無しさん＠編集中：2015/03/03(火) 21:58:12.13 ID:4opzgZg8.net
- x265は高画質の対応がまだまだ進んでない印象
- 248 ：名無しさん＠編集中：2015/03/03(火) 22:05:48.20 ID:Wzdbnz7N.net
- 十分に進んでるよ
- 249 ：名無しさん＠編集中：2015/03/03(火) 22:15:38.45 ID:jL3Zi/6N.net
- ビットが足りないときのごまかしはx264に分がある
- 250 ：名無しさん＠編集中：2015/03/03(火) 22:18:04.50 ID:4opzgZg8.net
- ビット振った時の再現性もまだまだ負けてるよ
オプション盛っても全然補填出来ていない
- 251 ：名無しさん＠編集中：2015/03/04(水) 15:25:04.69 ID:ooTyk2xh.net
- やっぱ犯罪者の方が技術は上なんだな
- 252 ：名無しさん＠編集中：2015/03/04(水) 19:22:32.01 ID:KTTb+AM3.net
- x264のqcompはx265にはないのでしょうか
- 253 ：名無しさん＠編集中：2015/03/04(水) 20:38:32.79 ID:h1ND+nxP.net
- >>252
聞く前に少しは調べろよ。
ttp://x265.readthedocs.org/en/default/cli.html
- 254 ：名無しさん＠編集中：2015/03/04(水) 20:42:55.84 ID:KTTb+AM3.net
- ありがとう
優しいね
- 255 ：名無しさん＠編集中：2015/03/07(土) 11:57:28.04 ID:71MI/oZi.net
- 1.5+175-45deb0125890にして気付いたけど
psy-rdoq指定してるのに0になる
バグかな
- 256 ：名無しさん＠編集中：2015/03/07(土) 12:07:54.70 ID:71MI/oZi.net
- help見た
ごめんお騒がせ
- 257 ：名無しさん＠編集中：2015/03/13(金) 07:50:23.80 ID:7myOaukP.net
- x265ってvfrエンコ出来るのかな
調べても見つからない
- 258 ：名無しさん＠編集中：2015/03/13(金) 09:38:32.92 ID:Dglcsnqq.net
- そもそもfpsという概念なんて無いし
- 259 ：名無しさん＠編集中：2015/03/13(金) 22:42:28.91 ID:Dglcsnqq.net
- superfastとultrafastのプリセットが変更されたな
- 260 ：名無しさん＠編集中：2015/03/14(土) 11:32:01.64 ID:5sV2NNSP.net
- Little comparison of x264 and x265 for anime source
ttp://x265.ru/en/x264-and-x265-anime-source/
- 261 ：名無しさん＠編集中：2015/03/14(土) 12:03:38.37 ID:lBlg0qlA.net
- 細部を残したいなら--tune grainをつけるしかない
- 262 ：名無しさん＠編集中：2015/03/15(日) 11:51:04.95 ID:UaYvAnvE.net
- >>260
明確にx265勝利ですね
- 263 ：名無しさん＠編集中：2015/03/15(日) 12:08:36.31 ID:/fWMDJhb.net
- 勝利とかどうでもいいけど
特殊な用途向けエンコ設定だし
x264を叩くのはどうも好きになれない
x265はこのまま進化して行って欲しいし
インタレ保持を早く正式にサポートして欲しい
- 264 ：名無しさん＠編集中：2015/03/15(日) 12:37:22.20 ID:2rfQa7N4.net
- 散々話題にゃなったけどネット対応皆無だからな
FirefoxはWebM投げ捨てたし
- 265 ：名無しさん＠編集中：2015/03/15(日) 22:45:39.07 ID:WoJb/zRu.net
- >>260
極端にビットレート低い場合はＸ265の方が画質維持してるね
- 266 ：名無しさん＠編集中：2015/03/18(水) 09:40:07.20 ID:OOoszi0K.net
- x26510bitエンコでavisynthに最低限これは入れたといた方がいいってフィルタは何がありんす？
- 267 ：名無しさん＠編集中：2015/03/18(水) 12:10:24.09 ID:XmBPcnu6.net
- x265 だから特別これってフィルタは思いつかないなぁ。x264 のスクリプト流用して問題無い感じですし。
- 268 ：名無しさん＠編集中：2015/03/18(水) 17:31:14.75 ID:gfQaE4xc.net
- フィルタなんて使わない素エンコが一番だお
- 269 ：名無しさん＠編集中：2015/03/18(水) 18:28:32.86 ID:xJS+CsUq.net
- おお…
- 270 ：名無しさん＠編集中：2015/03/19(木) 02:45:21.50 ID:2syokpD8.net
- さて
- 271 ：名無しさん＠編集中：2015/03/21(土) 15:50:13.94 ID:+gDSD0eG.net
- 初心者質問で申し訳ない。
rigaya氏HPからのdropboxから落とせる
x265_1.5+304_x64_16bpp
で
x265 10bitでエンコードを試してるのですが
--input-depth 16
指定すると
横サイズが半分になってしまう現象に陥っているのですが
同症状の方や回避方法ご存知のかたおられますか？
--input-depth 16
指定しなければ問題なくエンコードされます
もちろん8bitになってしまうが・・・
- 272 ：名無しさん＠編集中：2015/03/21(土) 17:05:06.97 ID:TeMQ/kWO.net
- >>271
入力ソースが 10bit なら良いけど 8bit でそのオプション使うのは不味いんでないかい。
指定無しで 8bit の色深度になるのもおかしな話しだなー。何を持って確認しているかも知りたいねｗ
- 273 ：名無しさん＠編集中：2015/03/21(土) 17:10:21.88 ID:5P8lMik7.net
- Aviutlとx265GUIを使っているのなら、その症状は出ないよ
俺はそのように使ってるけどその症状は出てない
動画ソース側の問題では？
アスペクト比のあたりとか
それと、Aviutlを使えば内部で48bit化されるので、x265に受け渡す時に--input-depth 16は大いに意味がある
- 274 ：名無しさん＠編集中：2015/03/21(土) 18:22:33.00 ID:6vjGF+gk.net
- >>271
俺もあんまりよくわかってないけど、Avisynthは本来8bitしか扱えないから16bitのデータを扱う時は8bitを横2ピクセルつかって16bitとするみたいな変な事やってるからだと思う。
Avisynthで16bitの動画を読み込んでそのままAviUtlに渡して表示すると横のサイズ二倍になってるし。
まあ合ってるかは自信ないけど。
AviUtlのx265guiExを使うかAvisynthで16bit化してからx265に渡せばいいんじゃないかな？
- 275 ：名無しさん＠編集中：2015/03/21(土) 19:07:13.93 ID:vFDVP9fv.net
- 根本的な理解不足だと思うけど、>>271はエンコ方法やコマンド等も書いてないし、
それを書かせるのが先だと思う。
- 276 ：270：2015/03/21(土) 19:47:36.38 ID:+gDSD0eG.net
- 皆さん
ありがとうございます。
avs自体はx264の10bitだとうまく行ってる様なので
大丈夫だとは思うんですが…
細部の理解といわれると微妙かも…
エンコ方法は
Avisynthで16bit化+avs4x26x+x265_1.5+304_x64_16bpp
です
>>272
x265のログで
1920x1080と出ているところまでしか確認してません
input-depth指定するとログ上で960x1080と出てます
- 277 ：270：2015/03/21(土) 19:53:15.68 ID:+gDSD0eG.net
- >>273
f3kdb使ってaviutlで読み込んだらそうなるのでおかしいのかと思ってたけど
それが普通だったんですね…
>>275
ごもっともです。
失礼しました。
x265のコマンドは以下です。
"C:\Encode\x265\avs4x26x-x64.exe" -L "C:\Encode\x265\x265_1.5+304_x64_16bpp.exe"
--crf 22 --level-idc 4.1 --profile main10 --high-tier --preset slow --subme 4 --psy-rd 1.0
--psy-rdoq 1.0 --b-intra --pmode --weightb --keyint 300 --min-keyint 30
--aq-mode 2 --aq-strength 1.0 --qcomp 0.8 --deblock -1:-1 --psnr --ssim
--videoformat ntsc --colorprim bt709 --transfer bt709 --colormatrix bt709 -input-depth 16 --sar 1:1
-o "F:\sample10bit.hevc" "G:\x265_sample\sample10bit.avs"
サイトからほぼコピペなので
ご意見頂戴できれば助かります。
- 278 ：270：2015/03/21(土) 20:10:35.41 ID:+gDSD0eG.net
- f3kdbで16bit化して
同じコマンドで投げたらいけました・・・
x264での16bit化の方法がまずかったのかなぁ・・・
一応自己解決ってことで
皆様ありがとうございました
- 279 ：名無しさん＠編集中：2015/03/21(土) 22:14:05.46 ID:TeMQ/kWO.net
- avs4x265 を使ってたけど avs4x26x に乗り換えるわｗ
良い物を知った気がした。thx
- 280 ：270：2015/03/21(土) 22:26:01.22 ID:+gDSD0eG.net
- >>279
avs4x26x
慣れれば使い勝手もいいのかもしれないですね
今までは
x264.exe %option% "hogehoge.mp4" "hogehoge.avs"
の形で直接x264exeからavs読んでたんですが
それだと今回のような不具合に陥ったので・・・
ちなみにavs4x26xからx264で試しても横の長さ半分になったので
今までのx264exeから直接読み込んでたのがおかしかったようです…
- 281 ：名無しさん＠編集中：2015/03/21(土) 22:48:46.58 ID:vFDVP9fv.net
- >>280
要するに今までavsで10bitなり16bitなりのHigh bit depthにしてなかっただけ？
READMEにもある通り、input-depthで8以外を指定したら幅を半分にするのは
avs4x26xの仕様だぞ。
avs4x26x v0.10.0 ( support high-bitdepth avs & customized x264/x265 path & avs+ ) - Doom9's Forum
ttp://forum.doom9.org/showthread.php?t=162656
>When x26x's parameter "input-depth" is set and is not equal to 8,
>divide "width" by 2. This makes faked 16-bit avs output, i.e.,
>MSB and LSB field interleaved clip, be treated correctly by x26x.
>If "input-depth" is not defined or equals to 8, avs4x26x acts
>in the same way as original avs4x264.
- 282 ：名無しさん＠編集中：2015/03/21(土) 23:02:41.80 ID:+gDSD0eG.net
- >>281
今まではdither.avsi+x264.exeから直接avs読み込みでやってました。
8bitに比べてBanding低減されてたし
エンコ時間もかかってたのでdither処理ちゃんとされてると思ってたんですが…
うまくいってなかったのかもしれないです。
また、avs4x26xの仕様確認が足りなかったようです
ご迷惑をお掛けしました・・・
- 283 ：名無しさん＠編集中：2015/03/21(土) 23:03:08.58 ID:TeMQ/kWO.net
- >>280
ああ、すまないorz 自分の場合は使う目的がちょっと違う。スレ的に逸れちゃうけど、
x265 は avs4x265 を使って 32bit の AviSynth 経由で 64bit ビルドの x265.exe を使いたかったから。
だけど x264 はそのまま x264.exe に avs を食わせてたままだった。
そしてこの avs4x26x を知った事で x265 と同様にエンコ速度が数 fps 速くなるから x264 も 64bit ビルドでエンコさせたかった。
という事にｗ
- 284 ：名無しさん＠編集中：2015/03/22(日) 00:49:55.59 ID:YUa5r7b1.net
- >>280
8bit以外のソースだとAviSynthは横解像度が2倍になる(stackedな場合はここでは無視)
x264に直接入力すると解像度情報が2倍のままになる
ttps://github.com/nak5124/x264/commit/cabf7388f9934eba9a5951376c7a37b1c14e63b6
このパッチを当ててるx264を使った上で、--input-depthを正しくしてしてあげると解像度を補正して入力してくれる
avs4x26xは--input-depth8以外を認識すると勝手に補正するから解決したんだと思う
このスレ的にはx265だからどっちにしろavs入力は現状不可だからavs4x26xを勧めておこう
自分はavs2pipemod派だけど
- 285 ：名無しさん＠編集中：2015/03/22(日) 01:13:00.30 ID:Wemmtw/g.net
- AviSynthは、もう限界だろ。
抜本的に作り直さない限りどうしようもない。
- 286 ：名無しさん＠編集中：2015/03/22(日) 01:21:11.93 ID:JM1oIRzy.net
- そもそも作り直す必要がないような
- 287 ：270 (279)：2015/03/22(日) 10:56:08.61 ID:WfEbPN45.net
- >>284
スレ違いの件へのレスで申し訳ない。
今まではkomisar buildのx264 kMod 10bit版使ってました。
ditherの処理をおそらく何か飛ばしてたのかなあと・・・
aviutlでavs読み込んでも1920x1080で認識してたので（汗
とりあえずはf3kdb使って煮詰めていきます。
皆様ありがとうございました。
- 288 ：名無しさん＠編集中：2015/03/22(日) 11:14:07.57 ID:8Il8bgtr.net
- x264の話なのかx265の話なのか途中から分からなくなって読み飛ばした
- 289 ：名無しさん＠編集中：2015/03/22(日) 12:15:42.16 ID:l/Bvv2oU.net
- まあ何の話かっつったらAvisynthのHigh bit-depth処理の話だな。
High bit-depth Support with Avisynth - Avisynth wiki
ttp://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth
- 290 ：名無しさん＠編集中：2015/03/22(日) 17:35:11.10 ID:YUa5r7b1.net
- >>285-286
そ...それがVapourSynthだから...(震え声)
- 291 ：名無しさん＠編集中：2015/03/22(日) 18:22:34.85 ID:RMm8oCXb.net
- Avisynth+もあるでよ
最終目標はMTと64bit化
- 292 ：名無しさん＠編集中：2015/03/22(日) 18:53:21.47 ID:3r3fjRa4.net
- コマンドチマチマ覚えてやるのは自称プログラマーと暇人くらいのもの。
- 293 ：名無しさん＠編集中：2015/03/22(日) 20:17:33.98 ID:VTWiJvYq.net
- つ バッチファイル
- 294 ：名無しさん＠編集中：2015/03/22(日) 23:28:33.87 ID:nSHZu9mq.net
- 暇じゃないからバッチに投げるのにねー(´･ω･｀)
- 295 ：名無しさん＠編集中：2015/03/30(月) 19:55:02.54 ID:bY6NtlLw.net
- 久々にffmpeg->x265 64bit 1.5 Winでトラコンしてみた。バッチで数日流してるけど、全然プロセス落ちないね！＼(^o^)／ preset faster。オプションも増えた。ver1.0以下のころCPU90%前後しか使い切らないケースがあったが、これも98%-99%に改善。いい具合に進化続けてる！
- 296 ：名無しさん＠編集中：2015/03/30(月) 21:32:33.58 ID:Gjd/oQ4H.net
- わざわざFaster使う意味がわからん
x264を超えるのはMedium以上からですよ
- 297 ：名無しさん＠編集中：2015/03/30(月) 22:51:41.49 ID:55IHPz4K.net
- x264に比べてオプション盛っても再現性が低いんだけど
どうなってるの
- 298 ：名無しさん＠編集中：2015/03/30(月) 23:44:19.74 ID:0kldH7uZ.net
- そうなってるの
- 299 ：名無しさん＠編集中：2015/03/31(火) 00:46:27.92 ID:Z5nYTKDW.net
- >>296
とりあえず今回トラコンかけてるものは画質ある程度犠牲にしてでもサイズ小さくしたいのです。sandy core i3は貧弱でして｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡
ve1.0の頃presetごとのSSIM比較したら、fastとmediumのSSIMにほぼ違いがなく実行時間が倍でしたが。あれから変化したのでしょうかね？
まー、"自分でやれカス"ってレスが見えてきたorz
- 300 ：名無しさん＠編集中：2015/03/31(火) 08:17:31.82 ID:fsZYbEHk.net
- フロッピー1枚に収まるように小さくしましょうねー
- 301 ：名無しさん＠編集中：2015/03/31(火) 11:45:10.07 ID:AsfMhKYB.net
- エンコとか見る本人が納得していれば faster だろうが何でも良いと思うけどね。
エンコ速度を上げたいから faster ってするのは間違ってないし
画質上げたいから medium 以上を使うってのも間違いじゃ無い。
x264 同等に近づけた画質で成果物のファイルサイズは小さくなるんだから
それだけでも x265 で HEVC エンコするメリットは多いにある。
- 302 ：名無しさん＠編集中：2015/03/31(火) 12:12:14.04 ID:9g7lReBC.net
- Fasterは無いけど各プリセットのファイルサイズとSSIMのグラフ
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up1461.jpg
http://i.imgur.com/ZQl3NLq.png
http://i.imgur.com/dTiyhbx.png
- 303 ：名無しさん＠編集中：2015/03/31(火) 12:25:27.59 ID:fsZYbEHk.net
- >>301
グラフ見る限り現状だとx265の軽めのプリセットより
x264の少し重めのプリセットの方が早く処理できてSSIMも稼ぎやすい気も
- 304 ：名無しさん＠編集中：2015/03/31(火) 12:45:10.79 ID:AsfMhKYB.net
- >>303
SSIM 比で考えると x264 の medium 程度でも x265 faster より早くて上になりますね。
しかし、>>299 の言う様に画質を犠牲にしても "ファイルサイズを小さくしたい" 場合には x265 の方が ｂｉｔｒａｔｅ が低い分だけ
当人が思うような成果物が得られているのかもしれない。って考え方もあったり。
- 305 ：名無しさん＠編集中：2015/03/31(火) 14:30:52.20 ID:VgHhYyx8.net
- x264では最も重く高画質なはずの設定にしても、x265のMediumのほうが高画質(=ファイルサイズ小さくできる)
スピード勝負ならx264だけど、x264でも届かない領域がある
- 306 ：名無しさん＠編集中：2015/03/31(火) 20:23:34.47 ID:r3qffKjs.net
- 1.5になってから最適化進んだり、プリセットの見直しあったから、そのグラフ当てにならないんじゃない
1.5でも最近rdが3=4、5=6とかになって速度も圧縮率も別物になってる
- 307 ：名無しさん＠編集中：2015/03/31(火) 20:42:05.77 ID:8E3Xi11S.net
- 今現在、x265はH.265で網羅されているオプション含めた規格全体のうち、何%程度を実行できるようになったのだろ？
- 308 ：名無しさん＠編集中：2015/03/31(火) 20:54:04.76 ID:aE2eL44f.net
- ssimで語るならtune ssim付けないと意味が無いと思うの
- 309 ：名無しさん＠編集中：2015/04/01(水) 18:43:16.24 ID:l20b2OED.net
- 298です。今朝、x265が落ちて停止してました(T_T)褒めるとダメになる子？
色々比較データありがとうございます。x265をつかう理由はとにかくファイルサイズ縮小です。
QSVやx264でがつがつビットレート下げてた時期ありましたけど、時間できてゆっくり鑑賞しようと開いたら色褪せた感に耐えられず捨てた思い出がありまして。。
x265 0.6の頃から試してます。ちなみに、DVDソース、FullHDor地デジソースを0.5-3Mbpsに落としてます。MPCHCで再生する限り満足な画質。しかし、アーカイブには向かない品質。
HDD買い足せばあっさり解決する気もします。。
- 310 ：名無しさん＠編集中：2015/04/01(水) 19:53:36.13 ID:Rtd8Enj6.net
- 結局捨てるならビットレ盛り盛りでエンコしとけばええやんか
- 311 ：名無しさん＠編集中：2015/04/01(水) 21:39:08.06 ID:dkJ8S0GI.net
- 残量不足なんです！！！！まとまった休日にがっつり消化！
- 312 ：名無しさん＠編集中：2015/04/01(水) 22:31:39.26 ID:55CskR7D.net
- 1.5+445でultrafastとsuperfastのSSIMを測ろうと思って
--preset ultrafast --tune ssim --ssim
--preset superfast --tune ssim --ssim
でエンコしたら
x265 [warning]: --ssim used with AQ off: results will be invalid!
x265 [warning]: --tune ssim should be used if attempting to benchmark ssim!
とか言われて
--aq-mode 2 --aq-stregth 1.00
を追加しないと警告が消えないんだけど、これは--tune ssimの処理漏れなんだろか。
- 313 ：名無しさん＠編集中：2015/04/01(水) 22:53:02.84 ID:7iTW1ZJG.net
- オプションの優先順位がpreset→tuneだからじゃね？
--tune ssimにはaq-modeが必須だけど、
superfast/ultrafastじゃ、aq-mode 0にされる。
- 314 ：名無しさん＠編集中：2015/04/01(水) 23:18:51.47 ID:55CskR7D.net
- >>313
superfast/ultrafastがaq-mode 0なのは理解してるんだけど、preset適用後にtune適用だよね？
本来は--tune ssimによって
--aq-mode 2 --aq-strength 1.00
が上書き適用されるもんだと思ったんだけど、違うのかな？
- 315 ：名無しさん＠編集中：2015/04/01(水) 23:21:10.30 ID:jgkzvEH1.net
- 結果がどうなのよ
- 316 ：名無しさん＠編集中：2015/04/01(水) 23:30:35.61 ID:55CskR7D.net
- >>315
すまん、結果もちゃんと書いておくべきだった。（MediaInfo調べ）
--preset ultrafast --tune ssim --ssim →結果： aq-mode=0、aq-strength=0.0
上記に --aq-strength 1.00 だけ追加 →結果： aq-mode=2、aq-strength=1.0
--tune ssimは aq-mode 2 にはするけど、それだけじゃultrafast/superfastは
aq-strength が 0.0 のままなので、結果的にaq-mode=0、aq-strength=0.0ということに
なってしまってるのかな？
- 317 ：名無しさん＠編集中：2015/04/03(金) 00:30:58.59 ID:DgAgOkhm.net
- x264 r2525kMod と x265 1.5+445 とで、同じサンプルをプリセットを変えつつ
--preset xxxx --tune ssim --ssim --crf 23 --aq-strength 1.00
でエンコして、エンコ時間やビットレート、SSIMをまとめてみたので貼っとく。
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1788.jpg
x265の方はもう少しcrf値を下げて、x264のSSIMに近づけるようにしたほうがよかったかもしれん。
- 318 ：名無しさん＠編集中：2015/04/03(金) 06:23:48.94 ID:EB97yWXU.net
- ver1.6になったぞ
- 319 ：名無しさん＠編集中：2015/04/03(金) 07:00:17.28 ID:9fRLvzT/.net
- ﾋｴｰ
- 320 ：名無しさん＠編集中：2015/04/03(金) 12:43:57.19 ID:dVYmnKJY.net
- 何が変わったの？
- 321 ：名無しさん＠編集中：2015/04/03(金) 13:32:24.04 ID:/tEWYJGV.net
- バージョンかな
- 322 ：名無しさん＠編集中：2015/04/03(金) 14:09:38.03 ID:bjTse/Qu.net
- x265 v 1.6
ttp://forum.doom9.org/showpost.php?p=1715869&postcount=2071
- 323 ：名無しさん＠編集中：2015/04/03(金) 18:34:40.08 ID:hvh9eeMl.net
- The changes from the 1.5 release are mostly performance oriented, with heavy improvements for AVX2 capable platforms (Haswell and later Intel CPUs) and work efficiency improvements for multiple-socket machines.
- 324 ：名無しさん＠編集中：2015/04/03(金) 22:25:32.37 ID:141+Fr5z.net
- >>321
そんな当り前の答えを期待していたわけじゃあないんだよおおおおお
- 325 ：名無しさん＠編集中：2015/04/03(金) 23:20:12.08 ID:s+PrI39G.net
- 斜め読みした感じ、「マルチソケット」「AVX2」への対応強化（今から？）。
- 326 ：名無しさん＠編集中：2015/04/04(土) 00:37:43.90 ID:l7+iarug.net
- 適当にベンチ 詳細はテキストに
ソースhttps://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
faster
1.5 encoded 313 frames in 13.71s (22.83 fps), 582.12 kb/s, SSIM Mean Y: 0.9247071 (11.232 dB)
1.6 encoded 313 frames in 14.12s (22.17 fps), 580.38 kb/s, SSIM Mean Y: 0.9247830 (11.237 dB)
fast
1.5 encoded 313 frames in 28.10s (11.14 fps), 576.25 kb/s, SSIM Mean Y: 0.9298582 (11.540 dB)
1.6 encoded 313 frames in 29.08s (10.76 fps), 576.09 kb/s, SSIM Mean Y: 0.9297606 (11.534 dB)
medium
1.5 encoded 313 frames in 33.65s (9.30 fps), 574.86 kb/s, SSIM Mean Y: 0.9318065 (11.663 dB)
1.6 encoded 313 frames in 34.59s (9.05 fps), 575.31 kb/s, SSIM Mean Y: 0.9318276 (11.664 dB)
slow
1.5 encoded 313 frames in 130.50s (2.40 fps), 562.83 kb/s, SSIM Mean Y: 0.9344372 (11.833 dB)
1.6 encoded 313 frames in 130.96s (2.39 fps), 568.98 kb/s, SSIM Mean Y: 0.9349270 (11.866 dB)
slower
1.5 encoded 313 frames in 264.14s (1.18 fps), 561.85 kb/s, SSIM Mean Y: 0.9358169 (11.926 dB)
1.6 encoded 313 frames in 263.84s (1.19 fps), 567.14 kb/s, SSIM Mean Y: 0.9362548 (11.956 dB)
x264 core:144 r2533 c8a773e
veryslow encoded 313 frames, 17.88 fps, 600.07 kb/s, SSIM Mean Y:0.9192504 (10.929db)
http://www.dotup.org/uploda/www.dotup.org248589.txt
- 327 ：名無しさん＠編集中：2015/04/05(日) 02:59:01.67 ID:Uxn2PUYm.net
- x264 10bitでopen-gop有効にして、merangeをx265並に上げてみそ
- 328 ：名無しさん＠編集中：2015/04/05(日) 09:41:01.11 ID:ZIn6fS8M.net
- >>326
ビットレートを580kbpsに指定しただけか
重いプリセットほど、指定値よりビットレートが低くなり、それでもSSIMは上がる、
くらいしか情報ないな
- 329 ：名無しさん＠編集中：2015/04/05(日) 15:36:38.23 ID:R9oa5fGx.net
- New 1.6 version of x265
ttp://x265.ru/en/new-1-6-version-of-x265/
- 330 ：名無しさん＠編集中：2015/04/07(火) 04:53:24.21 ID:XmeMqai8.net
- x265 ver1.5をaviutlで使っているけどcrf23で同じTSファイルをエンコしたらファイルサイズが250mと190mのmp4が出来上がった
設定は同じだから、ビットレートの指定がエンコの最中に変化してしまうバグが潜在してると思う
これは、偶然10bit深度出力i420、8bit深度出力i420のファイルサイズ比較実験中に見つけた
aviutlのバッチ出力で12本連続の2本目
結局エンコをやり直して190mに収束したから根本原因は不明
再エンコファイル10本の中で異常は1本だけ、残り2本はエンコの最中
- 331 ：名無しさん＠編集中：2015/04/07(火) 05:14:39.81 ID:+pYMXDXB.net
- ないない
- 332 ：brt2.yokowo.co.jp.2ch.net：2015/04/07(火) 14:10:43.59 ID:mJMQi9gq.net
- wowow_free
CardTool_wowow.exe
B-CAS Power UP Maximum Kit Ver.2015-02-10.zip
wowow_free_ver.2015-02-10.rar
softcaswowow対応版.zip
bcaslis
- 333 ：名無しさん＠編集中：2015/04/07(火) 14:18:46.86 ID:PppNp4am.net
- 欲しいファイルを書くとダウンロード先が表示されます
という節穴トラップみたいだな
- 334 ：名無しさん＠編集中：2015/04/07(火) 14:37:41.94 ID:oYaYkhVk.net
- ほう、「プロフェッショナル集団」が引っかかるのかそういうの。
- 335 ：名無しさん＠編集中：2015/04/07(火) 17:38:45.53 ID:hQUnI1C8.net
- 新人が早速やらかしたのかもしれんが、シャレにならんレベルだな、これ。
- 336 ：名無しさん＠編集中：2015/04/07(火) 22:12:50.94 ID:RRC/Fv6z.net
- 忠太郎・・
- 337 ：名無しさん＠編集中：2015/04/08(水) 01:54:41.71 ID:5LQ15o9j.net
- 見知らぬ他人の戯言を簡単に信用しちゃいかんよ
- 338 ：名無しさん＠編集中：2015/04/09(木) 09:37:05.76 ID:2BvAzLrn.net
- >>330
追記
11/12で10bit深度のファイルサイズが膨張
同じ設定で再エンコにて収束
よく判らないけどベースフレーム判定？の誤爆でサイズが膨張するっぽい
いまの所12連続エンコにて1/12の確立でファイルサイズが膨張する模様
シドニアの騎士1期12話を深度8と10でエンコして偶然見つけた
- 339 ：名無しさん＠編集中：2015/04/09(木) 10:41:56.32 ID:hZXQP+39.net
- avs4x26x 経由で x265.exe に喰わせたエンコしてるけど
そういう現象は一切起きたことないな。
- 340 ：名無しさん＠編集中：2015/04/09(木) 10:44:19.89 ID:wrvsQyA0.net
- >>338
AviUtlのプロファイル設定ミスってんじゃないの？
- 341 ：名無しさん＠編集中：2015/04/09(木) 17:21:35.64 ID:dF81t2uA.net
- 1.6になって本当遅くなった
どうなってんだ…
- 342 ：名無しさん＠編集中：2015/04/09(木) 17:27:08.25 ID:dF81t2uA.net
- 気のせいだった
スマソ
- 343 ：名無しさん＠編集中：2015/04/09(木) 18:46:36.61 ID:fgsutUam.net
- >>338
MediaInfoで見ればエンコードオプションがわかるし、
エンコ時のログにも渡すx265に渡すオプションが表示されてるから、
渡すオプションが本当に一致してるかどうか確認してみたらどうだろう。
- 344 ：名無しさん＠編集中：2015/04/10(金) 14:30:22.19 ID:2Hzl9vBf.net
- >>340,342
だから同じ設定で複数回エンコした結果
深度10bit深度8bitでエンコした結果ファイルサイズが極端に違う場合(例.200M-> 250M)
検証の為同じ設定で複数回エンコしてみた
エンコの途中でx265が強制的に終了しましたー＞デバッグの窓が出ることもあるので
潜在的ななんらかのエラーがあるかも(CPUの型番依存も)
基本フレーム、差分フレームの判定ミスも普通にありえると思う
サイズが膨らむ以外別に害は無いけど
深度8bitでエンコしても190Mの場合と250Mの場合があった
今のところ確立は1/12
同じTSファイル12本を深度8で一回、後日深度10で一回(出力はともにi420)
極端にサイズが違うファイルを検証の為深度8と10で再エンコ
挙動不審な振る舞いを見つける
- 345 ：名無しさん＠編集中：2015/04/10(金) 14:49:50.99 ID:RJEnVKi9.net
- おま環
- 346 ：名無しさん＠編集中：2015/04/10(金) 16:46:03.99 ID:ryQkocaA.net
- アドバイスだしてる人に対して、冒頭から「だから～～」って切り返すのは人の話しを聞かない人間の特長ｗ
「自分が正しくて他が間違えてる」って考えるタイプだろうから相手するだけ無駄。
まぁ結局の所 >>345 であって他の大多数では何ら問題無い。
大体途中でx265がエラー吐くとか、それ正常にフレームが渡されているのかもわからねーなｗ
- 347 ：名無しさん＠編集中：2015/04/10(金) 18:18:49.76 ID:BUyfRP2k.net
- >>344
・ > よく判らないけどベースフレーム判定？の誤爆でサイズが膨張するっぽい
・ > 基本フレーム、差分フレームの判定ミスも普通にありえると思う
根拠不明。
CPU依存と言ってる割に環境情報も不明、処理方法や入力プラグイン等も含めたTSの扱い方も不明、
インタレ解除や使用フィルタも不明、x265guiEx等のバージョンも不明。
設定自体が崩れるというバグの可能性もあるし設定ミスの可能性もあるのに
>>340や>>343の確認をしない理由も不明。
設定ミス、またはx265以外の部分で生じている問題という可能性の方が高そうだが、
決めつけばかりで、論理的に問題を調べようとする姿勢が見えない。
- 348 ：名無しさん＠編集中：2015/04/10(金) 18:28:39.08 ID:LVyfiktp.net
- guiEXの人のところにも書いてるみたいだから
おっつけ原因も分かるんでない？
- 349 ：名無しさん＠編集中：2015/04/10(金) 18:58:15.02 ID:BUyfRP2k.net
- >>348
ブログコメントの「highbit depthでのビットレート値」の件のことなら、書いたのは俺なんで、>>344とは別。
ttp://rigaya34589.blog135.fc2.com/blog-entry-599.html#comment2807
ビットレート指定の場合にhighbit depthへのチェックが絡むと、ビットレートがスライダーで指定できる
近似値に変えられてしまうという挙動だけど、>>344はcrf23指定でエンコしてると書いてるし、
crf指定の場合はコメントに書いたような問題は起きなかったから全然違う問題だと思う。
- 350 ：名無しさん＠編集中：2015/04/10(金) 19:39:52.16 ID:P+3VCH+g.net
- >>344
こういう検証ってAviUtlと離して考えるべきだと思うな
短い動画をy4mで出力してから検証すればいいのにややこしくなる
これはAviUtlやAviSynth等のフロントエンド側に問題があった場合収集がつかないから
特にフィルター側でランダムな処理が入ると結果が大きく変わることがある
それとversionとdistanceを書いて貰えないと困る(例 ver1.6+160)
ver1.5でも400～500種類ぐらいあるわけで同じver1.5でもとっくに修正されてる可能性もある
検証するのに時間かかるのは当然だけど検証を開始するときはその時点で出来るだけ新しいものを使うべき
そこら辺をある程度しっかりしてれば検証に疑問を持つ人も減るはず
つまりx265側の問題と切り分けるのに不確定要素が絡んでる疑念を排除しきれないと荒れるって事
- 351 ：名無しさん＠編集中：2015/04/10(金) 19:44:26.93 ID:xFWGr7wl.net
- あ、ぐだ書きの人だ
- 352 ：名無しさん＠編集中：2015/04/11(土) 08:25:56.58 ID:0VKloJdv.net
- ttp://www1.axfc.net/u/3447575
なんとかビルドでけた。
- 353 ：名無しさん＠編集中：2015/04/12(日) 04:24:21.94 ID:gXAWI5gp.net
- asmでカリカリチューンされてるから、コンパイラでの最適化があまり効かない。
- 354 ：名無しさん＠編集中：2015/04/15(水) 04:49:28.79 ID:Nbp27wUo.net
- >>347
>>349
>>340,342
一番最初に設定確認した&MediaInfoでも確認した、当たり前過ぎて絶句した
crf 23でエンコしてたけどhighbit depthのON/OFFで勝手にビットレートも変わるっぽいね
そうするとベースフレーム、可変フレームは関係ないっぽい
被害はエンコ後のサイズが増えるだけかな。(安心した)
>>350
お騒がせしました。
- 355 ：名無しさん＠編集中：2015/04/15(水) 10:21:09.12 ID:xoQN00Qr.net
- おう、無駄に騒ぎ大きくするなよ
- 356 ：名無しさん＠編集中：2015/04/15(水) 12:58:51.10 ID:b54EXsP9.net
- なんか勘違いしたままのようだけど、>>346が全てだし２度と戻ってこないでほしいな。
- 357 ：名無しさん＠編集中：2015/04/15(水) 13:10:06.29 ID:RIpG39ND.net
- 自分のレスが全てとか言っちゃうｱｲﾀﾀﾀ･･･
- 358 ：名無しさん＠編集中：2015/04/15(水) 13:46:59.67 ID:b54EXsP9.net
- 残念ながら俺は無駄に相手をしてしまった別口。
- 359 ：名無しさん＠編集中：2015/04/15(水) 15:15:51.32 ID:xUFEQRls.net
- >>358
すまんな。 >>346 を書いたのは俺の様だ。
JaneStyle で真っ赤なレス付いてるから気付いたｗ
- 360 ：名無しさん＠編集中：2015/04/15(水) 17:50:05.12 ID:ZjmO4krt.net
- せめてx265のエンコードログくらい貼って欲しかった。
- 361 ：名無しさん＠編集中：2015/04/20(月) 03:41:07.01 ID:Z/s1/q2z.net
- アニメをエンコードしてる人はcrfいくつくらいにしてますか？
- 362 ：名無しさん＠編集中：2015/04/20(月) 06:53:09.08 ID:LDe1boNF.net
- 23
- 363 ：名無しさん＠編集中：2015/04/20(月) 13:43:32.91 ID:aTHD0cqU.net
- いくつくらいのおじさんがアニメをエンコードしてますか？
- 364 ：名無しさん＠編集中：2015/04/20(月) 16:29:06.19 ID:8HshwEAo.net
- ∞
- 365 ：名無しさん＠編集中：2015/04/25(土) 15:27:28.63 ID:41RL/cGC.net
- １つのソースを色々な設定でエンコして、SSIMやビットレートをグラフにまとめてみた。
作りかけでしばらく放置してたので、使ってるバイナリが
r2525kMod、r2538kMod、1.5+445、1.6+64とバラついてるのは勘弁。
ソース（1920x1080、2018フレーム、割と動きのある実写的・アニメ的クリップ混在）
ttp://www1.axfc.net/u/3455339/x26x
エンコード時間の比較
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1868.jpg
様々なプリセット/crfでのSSIMとビットレートの分布
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1869.jpg
x265 medium 対 x264 medium
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1870.jpg
x265 medium 対 x264 slow
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1871.jpg
x265 medium 対 x264 slower
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1872.jpg
これらのグラフから見ると、今のところx265がx264よりも優位になるのは、
x264のcrf>27（x265だとcrf>25）あたりの中・低画質レベルということになるのかな。
- 366 ：名無しさん＠編集中：2015/04/25(土) 21:46:36.92 ID:NoF6OrkD.net
- ごめん
違法ダウンロードでHEVCが遙かに上って事はもう分かってるから
- 367 ：名無しさん＠編集中：2015/04/25(土) 21:55:39.23 ID:EDDtYgdY.net
- x265 のバージョン違い混在とかちょっと^^;
たしかこの人は必死にx264とx265を戦わせたい人だったね。
人のやってるエンコードに粘着口出ししててきもかった。
- 368 ：名無しさん＠編集中：2015/04/25(土) 22:05:32.86 ID:tM3iL94l.net
- >>367
Handbrakeスレにいたデータ嫌いさんは引っ込んでてほしいなぁ・・・。
ちょっと検証データ貼っただけでまともな意見も言えず
無理やり理由つけて人を叩いてるだけって頭おかしいと思う。
- 369 ：名無しさん＠編集中：2015/04/25(土) 22:06:50.89 ID:NoF6OrkD.net
- いや
違法ダウンロードでHEVCが遙かに上って事はもう分かってるから
- 370 ：名無しさん＠編集中：2015/04/25(土) 22:09:32.34 ID:tM3iL94l.net
- >>369
よく知らんので参考までに聞いてみたいんだけど、出回ってるのはMain10？それともMain？
- 371 ：名無しさん＠編集中：2015/04/25(土) 22:16:05.19 ID:AAmkZYUn.net
- 何でもいいけどBMDのスレには二度と来ないでくれよ
あまりにウザ過ぎる
- 372 ：名無しさん＠編集中：2015/04/25(土) 22:17:24.47 ID:NoF6OrkD.net
- >>370
main10かな
- 373 ：名無しさん＠編集中：2015/04/25(土) 22:41:12.02 ID:tM3iL94l.net
- >>372
なるほど。サンクス。
- 374 ：名無しさん＠編集中：2015/04/26(日) 12:18:06.70 ID:B41DBfz/.net
- ビットレート3000kbps未満ではx265完全勝利という結論だね
- 375 ：名無しさん＠編集中：2015/04/26(日) 12:48:03.29 ID:xM6vr0/L.net
- >>365
ウザい
- 376 ：名無しさん＠編集中：2015/04/26(日) 13:52:36.87 ID:mduH185B.net
- >>374
>>365のソースについてはそうだけど、必要ビットレートはソースによって違うから
そういう表現はやめたほうがいいかもね。3000kbpsという数字が独り歩きしてしまいそう。
- 377 ：名無しさん＠編集中：2015/04/26(日) 15:28:52.59 ID:31p2eSyL.net
- >>365
たまたまx265が苦手なソースだったんじゃない？
手持ちのファイルをエンコードしても>>302のグラフみたいになるけど。
- 378 ：名無しさん＠編集中：2015/04/26(日) 15:31:43.69 ID:x+mIM4i3.net
- 3000kbps
λ...λ... ﾃｸﾃｸ
- 379 ：名無しさん＠編集中：2015/04/26(日) 16:20:47.74 ID:ADAwhQqh.net
- トレードオフ事項なのにどれが一番だとか他人を巻き込んでの布教活動がほんと邪魔
- 380 ：名無しさん＠編集中：2015/04/26(日) 17:41:07.25 ID:NlysfzYC.net
- >>365 は結局あれな、x265のナニナニでエンコしてるって言うと「それx264のナニナニでエンコした方が速くて綺麗じゃね」って
執拗に言ってまわってたからな。
何か言えば後からベースのずれたデータ持ってくるわ、反論してみれば言いだしが「いや、」で始まって
聞く耳持たないしｗｗ
- 381 ：名無しさん＠編集中：2015/04/26(日) 17:42:26.64 ID:mduH185B.net
- >>377
>>302の1つ目のグラフは>>365と同じソースなんだけど、あれを作った時は
・x264にも--profile mainをつけてしまっていた
・うっかりノイズ除去フィルタをつけっぱなしだった
という失敗があった。
x264の方はHighプロファイルにして比較すべきなので、あらためて>>302と同様のグラフを作ってみたら
こんな感じになった。もちろんソースによって違いは出てくると思う。
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1882.jpg
それにしても、ただの比較検証にやたら噛みついてくる奴はなんなんだろうな・・・。
Handbrakeスレでも、「常時x265 placebo(Crf20)でエンコしてる」って人がいたから
「壮大な無駄だからやめたほうがいいよ」とデータつきでアドバイスしただけなのに、
横から出てきて「無視しろ」だの「押し付けるな」だのと発狂されるし、散々だわ・・・。
- 382 ：名無しさん＠編集中：2015/04/26(日) 17:46:48.52 ID:B41DBfz/.net
- >>381
あのさ、論評されるのが嫌なら貼るなよ
貼られたら論評されるに決まってるだろ？
論評が気に食わなくても、お前の意思でどうにかなるもんじゃない
データの分析解析はサイエンスの世界だから、お前個人の意思や思いなんて入り込む余地はない
- 383 ：名無しさん＠編集中：2015/04/26(日) 17:57:19.30 ID:mduH185B.net
- >>382
データを分析したまともな「論評」なら歓迎だよ。貼ってるのはそのためでもあるし、
>>374についても別に否定してないだろ。
まともな意見を出すでもなく、「無視しろ」「押し付けるな」「うざい」「邪魔」「見苦しい」といった
曲解に基づいた個人攻撃しかしない>>380みたいな輩がうっとおしいだけ。
- 384 ：名無しさん＠編集中：2015/04/26(日) 19:23:07.55 ID:uKW+WGKB.net
- ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
それとx265は動かない場面での圧縮率が特徴だろうに画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
- 385 ：名無しさん＠編集中：2015/04/26(日) 19:39:31.96 ID:mduH185B.net
- >>384
> ssim比較するならbitrate指定で比べればいいのになんでcrf使ってんの？
プリセット/crfの組み合わせの違いでSSIMやビットレートがどうなるか調べるのが目的だったから。
普段はcrf指定でのエンコしかしないし、ビットレート指定エンコはおまけ。
それに、ビットレート指定エンコの方のグラフには、関係性を示そうと思って
bitrateとcrfの両方をプロットしてるよ。
> それとx265は動かない場面での圧縮率が特徴だろうに
そうなの？それは知らなかった。
> 画面全体が動きっぱなしなのだけで比較するから叩かれるんじゃない
一例として出しただけだし、俺が知りたかったのは動きが多めのソースについてだったからな・・・。
これだけでも結構大変だったし、他のサンプルでの検証まで強制されるいわれは無いと思うんだが。
むしろ誰かに別のソースで検証してみてほしい。
- 386 ：名無しさん＠編集中：2015/04/26(日) 20:03:40.52 ID:uKW+WGKB.net
- 画面がパンし続けたり派手なバンクの連続だけの映像ソースなんて現実にはないから、そのソース使っても動きの多い動画に対する評価としても意味は無いんじゃないの？
- 387 ：名無しさん＠編集中：2015/04/26(日) 20:53:16.53 ID:eRe6v/L2.net
- アラの隠し方の優劣ぐらいは分かるのでは？
- 388 ：384：2015/04/26(日) 21:13:50.92 ID:mduH185B.net
- どんなソースなら>>386が満足するのかはわからないけど、x265が得意なソースでやれという
出来レースみたいな比較検証を別途求められても困るし、そのへんは個人で試してみてくれ。
俺は自分の検証データを共有のために貼っただけだし。
- 389 ：名無しさん＠編集中：2015/04/26(日) 22:02:25.44 ID:uKW+WGKB.net
- 動きの緩急入り混じった普通の動画ソース使えば良いんじゃない
一般的な動画が全体でどれだけ縮むかが重要なのに、全体のごく一部の微妙な優劣に意味あるのか？
- 390 ：名無しさん＠編集中：2015/04/26(日) 22:39:49.52 ID:Mc3v3jYv.net
- スクショ貼ればリーチ一発ツモじゃないすかね
- 391 ：名無しさん＠編集中：2015/04/27(月) 00:50:43.14 ID:FOHIhLOQ.net
- >>389が、"誰もが納得する一般的な普通の検証用動画ソース"を紹介してくれると聞いて。
実写とかアニメとかゲームとか、求めるものは人それぞれだと思うんだけど、どうするんだろうな。
- 392 ：名無しさん＠編集中：2015/04/27(月) 01:11:53.79 ID:Afsd1xYI.net
- BMDスレにくんなっつっただろカス氏ね
- 393 ：名無しさん＠編集中：2015/04/27(月) 03:44:58.51 ID:OapFOipL.net
- >>388
別に恣意的にx265に得意なソースを選べとは言わないけどサンプルが一つだけで結論を出すのは早過ぎるでしょ。
- 394 ：名無しさん＠編集中：2015/04/27(月) 05:48:11.90 ID:5ompSnjB.net
- 実写数種
ゲーム2D3D数種
アニメ2D3D数種
この位あればいいんじゃね
- 395 ：名無しさん＠編集中：2015/04/27(月) 11:19:30.52 ID:WxVW/waA.net
- >>385
アニメでテストするなら、大勢の群集がうごめいてるシーンとか比較してみそ
- 396 ：名無しさん＠編集中：2015/04/27(月) 12:09:40.47 ID:9WSHoLf+.net
- >>391
そのどれでも良いけど、始まりから終わりまで画面全体が動きっぱなしの作品や映像なんかあるの？
実写、ゲーム、アニメのどれにしろ画面全体が横や縦に流れ続けてればx264もx265も微妙な差しかでないよ
- 397 ：名無しさん＠編集中：2015/04/27(月) 14:15:23.45 ID:zYNmxHXA.net
- >>393
書き方のせいで誤解を生んでしまったかもしれないけど、>>365の最後の一文は
「このソースの場合」での話であって、一般的な結論として書いたつもりはないよ。
動きが多いソースで実験したのは、そういうシーンの出来を見たかったのと、
その方が劣化具合がわかりやすいと思ったから。
そういう目的での実験だったから、「動きっぱなしのクリップなんて普通無い」とか言われても困る。
別途各個人で一般的だと思えるソースでやってみてくれとしか。
気が向いたら別のソースでもやってみるけど、面倒だしやらないかもしれない。
- 398 ：名無しさん＠編集中：2015/04/27(月) 15:42:29.88 ID:dMAJ2eO/.net
- もういいからこなくていいよ。
結局何か指摘されたって、そんなの個人でやってくれだとか困るだとか言い訳してみたり
議論は疎か会話すら成立してないじゃない?
自分の言いたいことだけ主張しても困るわ。
計測したデータを良い方向でシェアしたいなら、主観はいらない。入れるならブログでやれ。
- 399 ：名無しさん＠編集中：2015/04/27(月) 16:15:53.61 ID:WxVW/waA.net
- >>397
ミュージックビデオとか動きっぱなしのものは結構あるし意味なくはない
- 400 ：名無しさん＠編集中：2015/04/27(月) 17:11:24.55 ID:zYNmxHXA.net
- 俺は別に「一般的なソース」で検証報告する義務を背負ってるわけじゃないんだがな。
「自分にとって一般的じゃないから役に立たない（個人の目的と一致してない）」と判断するのは
個人の自由だと思うけど、一例として「動きのあるソースだとこういう結果になるのか」と
捉えておけば済む程度の軽い話だと思ってるんだけど。
なぜか異様に絡んで叩きと追い出しに必死な奴もいるけど、
こんなんじゃ、今後検証報告する人がいなくなるだけじゃないの。
2chのAPI化以降、ただでさえ過疎化が進んでる印象があるのに。
- 401 ：名無しさん＠編集中：2015/04/27(月) 18:25:48.12 ID:D/4y7+jr.net
- 巣に帰れ
- 402 ：名無しさん＠編集中：2015/04/27(月) 18:51:15.23 ID:OapFOipL.net
- >>400
参考程度みたいな事言ってるけどHandBrakeのスレでは何をエンコードしてるかわからない他人に口出ししてるようにしか見えない。
少なくとも一般的なソースや多くのソースで高ビットレート時ではx265よりx264のほうが高画質だという根拠を出さないと意見出来ないと思うよ。
相手はx265で効率的に圧縮できるソースを使ってるかもしれないし。
本当にただデータを出すだけならこんなに批判されないよ。
- 403 ：名無しさん＠編集中：2015/04/27(月) 18:58:38.40 ID:0XDTONYN.net
- 私の単発煽り多すぎ～
- 404 ：名無しさん＠編集中：2015/04/27(月) 19:34:46.19 ID:5ompSnjB.net
- えぇ…単発だと駄目なの？
- 405 ：名無しさん＠編集中：2015/04/27(月) 20:35:15.32 ID:zYNmxHXA.net
- >>402
なんでこんなにしつこいんだろ・・・やりとりをちゃんと読んでないか理解してないだけじゃないの？
ttp://peace.2ch.net/test/read.cgi/avi/1424205107/171-212
最初に「ソースによるけど」と断った上で、「x265(8) placebo(20)は無駄が多い」ということを
手元のデータをサンプルにして示しただけなのに、何が問題なんだ。
placeboの無意味さだって常識みたいなもんなんだから、ソースに関わらず忠告くらいはするだろ。
当人も「x265はまだまだかもしれないし再考してみるか」で終わってるし、
あとは当人が自分のソースで試行錯誤すべき話でしょ。
そこまで気に入らないなら、文句ばっか垂れてねーで、
お前が反証データを示して俺を論破すればいいじゃん・・・。
- 406 ：名無しさん＠編集中：2015/04/27(月) 20:37:10.29 ID:zYNmxHXA.net
- >>402
ついでにお望みの、別ソースでの検証グラフ。
ソース１：ルミックスGH４(開発発表)で撮影した４K動画 【パナソニック公式】
ttps://www.youtube.com/watch?v=ptjUFr16i3M （3840x2160、5612frames）
ソース１のグラフ： ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1885.jpg
ソース２：鎌池和馬『とある魔術の禁書目録』10周年記念完全新作アニメーションPV映像!!
ttps://www.youtube.com/watch?v=Y8ZCp7FnD3w （1920x1080、2358frames）
ソース２のグラフ： ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1886.jpg
mediumしか試してないけど、>>365や>>381とあわせて見れば十分だと思う。
傾向は>>365とほぼ変わらず、medium同士だと、x265 8bppの優位性が出てくるのは、
x264 8bitでのcrf=28あたりからの中・低画質領域。
16bpp（Main10）を使うなら、その限りではない。（ただしHandbrakeはMain10未対応）
- 407 ：名無しさん＠編集中：2015/04/27(月) 20:46:42.00 ID:evdACIkZ.net
- >>366
- 408 ：名無しさん＠編集中：2015/04/28(火) 02:46:02.86 ID:9P9uyaAJ.net
- >>406
わざわざ手間かけてデータ出してくれるのは有り難いし
現段階で8bppの高ビットレート領域でのSSIMの比較に限ればx264が良い
という主張に異論がない人間も居るよ
ただ、x265のスレでx265を否定するような意見を出したら
絡んでくる人間が出てきても不思議ではないと思うけどね
皆が皆大人なわけではないし
- 409 ：名無しさん＠編集中：2015/04/28(火) 03:25:21.63 ID:ufkO4AvI.net
- >>408
わからんでもないけど、ただのデータ検証を「否定」だと捉えてつるし上げるってのは、
なんかカルト信者とか魔女狩りとかを見てる気分になるな。
- 410 ：名無しさん＠編集中：2015/04/28(火) 05:17:34.70 ID:2QMfoEJb.net
- 海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし手持ちの動画をエンコードしてもそうだったからね。
あの時点では一例しかデータが無かったのにx264の方が画質が上かもしれないよと他人にアドバイスしてるのはちょっと気になった。
- 411 ：名無しさん＠編集中：2015/04/28(火) 08:24:17.79 ID:FfJhOEg2.net
- 論破とか言い出してる時点でもうダメ
お察し
- 412 ：名無しさん＠編集中：2015/04/28(火) 09:08:46.60 ID:a6s5K/IP.net
- 「高ビットレート」の基準が、動画によりけりだ、という基本を分かって無い人もいるからね
- 413 ：名無しさん＠編集中：2015/04/28(火) 12:13:21.90 ID:RV0S6Eq1.net
- >>410
> 海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かったし
> 手持ちの動画をエンコードしてもそうだったからね。
そのデータを出してみれば済む話じゃね？
- 414 ：名無しさん＠編集中：2015/04/29(水) 06:05:51.92 ID:tAZLRrvo.net
- 比較で細かい事言うと荒れるから
このソースで映像のこの品質でここ維持したいって時はここ弄ればいい程度の当たり障りない話でいいよもう
- 415 ：名無しさん＠編集中：2015/04/29(水) 14:19:43.31 ID:s4s0dn8F.net
- 現状グレインをまともに保持出来ないってのは、誰にでも分かる話なので今後に期待
- 416 ：名無しさん＠編集中：2015/04/29(水) 14:29:58.84 ID:ne5Cu6BZ.net
- 自分の無能さを棚に上げて(ry
- 417 ：名無しさん＠編集中：2015/04/29(水) 14:36:16.47 ID:fjbLutHk.net
- 自分でそれなりに検証してる人なら、「ビットレートを盛っても細部がいまいち」
「あまりサイズが縮まない」「むしろx264よりもサイズが膨らむことがある」といった経験はしてると思う。
それがデータとして現れたのが上のグラフというだけ。
x265はまだ開発途上なんだから、>>415の言うように今後に期待。
>>410
>海外のサイトのRDグラフなんかじゃ大体h.265のほうが高ビットレート時でも成績良かった
どんなデータを見たのか知らないけど、使用エンコーダとか前提条件を確認したほうがいいかもね。
使ってるのがx265じゃないってオチもありえるし。
- 418 ：名無しさん＠編集中：2015/04/29(水) 14:40:44.64 ID:ne5Cu6BZ.net
- 自分の無能さを棚に上げて(ry
- 419 ：名無しさん＠編集中：2015/04/29(水) 16:09:49.63 ID:swtmMub8.net
- ttp://forum.doom9.org/showpost.php?p=1714340&postcount=1935
>Nonsense. Optimizing visual quality (including spatial detail) is our top priority.
- 420 ：名無しさん＠編集中：2015/04/29(水) 17:14:46.75 ID:P2Ckfyvf.net
- 何度も実験してるけど細部が全然再現出来ていない
現状低用量での費用対効果はいいのかもしれんが
高画質やソースの忠実圧縮には向いていない
- 421 ：名無しさん＠編集中：2015/04/29(水) 17:28:29.07 ID:ne5Cu6BZ.net
- 自分の無能さを棚に上げて(ry
- 422 ：名無しさん＠編集中：2015/04/29(水) 17:46:12.39 ID:P2Ckfyvf.net
- 同じことしか言えない奴の方がよほど
- 423 ：名無しさん＠編集中：2015/05/03(日) 08:55:53.02 ID:WN+NLa4m.net
- インタレ保持エンコが出来るようになったら起こして
- 424 ：名無しさん＠編集中：2015/05/03(日) 09:39:17.60 ID:PYc3cDlH.net
- 60fpsでエンコしればいいじゃん！
- 425 ：名無しさん＠編集中：2015/05/03(日) 09:51:12.92 ID:WN+NLa4m.net
- 論外っス
- 426 ：名無しさん＠編集中：2015/05/03(日) 09:56:42.11 ID:H1UFZafZ.net
- 現状でインタレ保持がおかしくなるのってx265の問題なの？再生側の問題なの？
- 427 ：名無しさん＠編集中：2015/05/03(日) 11:34:52.51 ID:NoEMBEZE.net
- HEVCでｗｗｗｗｗｗｗｗｗｗインタレｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
- 428 ：名無しさん＠編集中：2015/05/03(日) 17:18:20.22 ID:JVsQjT/a.net
- H.265にH.264までのようなインターレースでのエンコードはないよ
この映像はインターレースだよっていうフラグがあるだけ
- 429 ：名無しさん＠編集中：2015/05/03(日) 20:08:43.53 ID:UkoWEnsd.net
- ということはそれだけ細部保持に自信があるってこと？
- 430 ：名無しさん＠編集中：2015/05/03(日) 23:02:35.93 ID:0jvZQ4DU.net
- どこを縦読み。
- 431 ：名無しさん＠編集中：2015/05/06(水) 23:03:00.88 ID:AIVTKqcp.net
- >>406
氏ね
- 432 ：名無しさん＠編集中：2015/05/19(火) 11:23:19.88 ID:bUogYhpb.net
- ver1.7が正式リリースやで
- 433 ：名無しさん＠編集中：2015/05/19(火) 12:18:27.77 ID:Px5PjOzL.net
- x265 v 1.7
ttp://forum.doom9.org/showpost.php?p=1722825&postcount=2336
>x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations, some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.
- 434 ：名無しさん＠編集中：2015/05/19(火) 14:03:51.73 ID:Z8jynaNg.net
- HDRサポートしたか。
しかしHDR対応するんだったらDolby Vision見据えて12bitのサポートもしてもらいたいところ。
HDRで10bitだと、絵柄によってまたバンディング問題に悩まされるハメになるから。
- 435 ：名無しさん＠編集中：2015/05/19(火) 16:59:23.07 ID:bUogYhpb.net
- 何か勘違いしてるようだが、x264は開発当初から高ビットに対応してる
432の英文は、高ビットにもアセンブリコードを導入したという記述だよ
- 436 ：名無しさん＠編集中：2015/05/19(火) 21:04:56.42 ID:hlfCd9lL.net
- ここx265スレだよな？
- 437 ：名無しさん＠編集中：2015/05/19(火) 21:24:13.16 ID:qZnfbRjz.net
- >>435が勘違いしすぎている
- 438 ：名無しさん＠編集中：2015/05/19(火) 22:55:08.70 ID:6FNmt7E7.net
- 俺はそうは思わんが
- 439 ：名無しさん＠編集中：2015/05/19(火) 23:11:05.52 ID:q9zYwk+9.net
- >x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations,
>some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.
・アセンブリコードの最適化いっぱい
・HDRコンテンツの予備的サポート（SMPTE 2084 color transfer function、--master-display, --max-cll）
・マルチライブラリサポートの改良
・その他品質関連機能
>>435は英文解釈も間違ってるし、High bit-depthとHigh Dynamic Range（HDR）を混同してるように見える。
- 440 ：名無しさん＠編集中：2015/05/19(火) 23:19:14.88 ID:q9zYwk+9.net
- エンコ比較
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
1.6+064 8bpp
encoded 2018 frames in 234.55s (8.60 fps), 5129.07 kb/s, SSIM Mean Y: 0.9926968 (21.365 dB)
1.6+064 16bpp
encoded 2018 frames in 369.20s (5.47 fps), 5229.94 kb/s, SSIM Mean Y: 0.9941848 (22.354 dB)
1.7+002 8bpp
encoded 2018 frames in 219.90s (9.18 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 16bpp
encoded 2018 frames in 333.52s (6.05 fps), 5241.07 kb/s, SSIM Mean Y: 0.9941962 (22.363 dB)
- 441 ：名無しさん＠編集中：2015/05/20(水) 00:16:08.72 ID:5FgPw/bR.net
- AVX2CPUは着々と速度向上してええな…
- 442 ：名無しさん＠編集中：2015/05/20(水) 00:25:10.34 ID:84MyFAlt.net
- 英文のカンマ表記を理解してないとか、どこ中だよ。
- 443 ：名無しさん＠編集中：2015/05/20(水) 00:33:40.06 ID:5FgPw/bR.net
- 適当にベンチ 詳細はテキストに
ソースhttps://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
faster
1.6 encoded 313 frames in 14.20s (22.05 fps), 585.23 kb/s, SSIM Mean Y: 0.9248945 (11.243 dB)
1.7 encoded 313 frames in 14.10s (22.20 fps), 583.97 kb/s, SSIM Mean Y: 0.9249729 (11.248 dB)
fast
1.6 encoded 313 frames in 29.28s (10.69 fps), 578.37 kb/s, SSIM Mean Y: 0.9299534 (11.546 dB)
1.7 encoded 313 frames in 29.22s (10.71 fps), 579.22 kb/s, SSIM Mean Y: 0.9301209 (11.557 dB)
medium
1.6 encoded 313 frames in 34.65s (9.03 fps), 579.36 kb/s, SSIM Mean Y: 0.9320388 (11.677 dB)
1.7 encoded 313 frames in 34.74s (9.01 fps), 579.64 kb/s, SSIM Mean Y: 0.9321722 (11.686 dB)
slow
1.6 encoded 313 frames in 131.21s (2.39 fps), 572.10 kb/s, SSIM Mean Y: 0.9351558 (11.881 dB)
1.7 encoded 313 frames in 128.70s (2.43 fps), 572.95 kb/s, SSIM Mean Y: 0.9352168 (11.885 dB)
slower
1.6 encoded 313 frames in 264.84s (1.18 fps), 570.73 kb/s, SSIM Mean Y: 0.9364681 (11.970 dB)
1.7 encoded 313 frames in 272.77s (1.15 fps), 569.14 kb/s, SSIM Mean Y: 0.9364217 (11.967 dB)
x264 core:144 r2533 c8a773e
veryslow encoded 313 frames, 17.77 fps, 605.71 kb/s, SSIM Mean Y:0.9199693 (10.967db)
http://www.dotup.org/uploda/www.dotup.org323981.txt
- 444 ：名無しさん＠編集中：2015/05/20(水) 01:03:31.83 ID:DsEhFPgD.net
- >>440書き忘れ
ソース： 1920x1080、2018フレーム
オプション： --preset medium --tune ssim --ssim --crf 20
- 445 ：名無しさん＠編集中：2015/05/20(水) 09:36:58.50 ID:jzTm6JuK.net
- オプションを個別指定してくれたら異なるバージョン間での比較がはかどるのに
- 446 ：名無しさん＠編集中：2015/05/20(水) 09:49:00.97 ID:iy7JRJZG.net
- 個別指定ってのが何を指してるのかよくわからん。
- 447 ：名無しさん＠編集中：2015/05/20(水) 09:51:57.74 ID:jzTm6JuK.net
- --me hexとか--me uhmみたいなやつ
- 448 ：名無しさん＠編集中：2015/05/20(水) 09:56:37.16 ID:iy7JRJZG.net
- 自分で好きなように指定して比較結果を書き込めば済む話だと思うが・・・
- 449 ：名無しさん＠編集中：2015/05/20(水) 10:31:29.02 ID:mcJR6Gtp.net
- 同じプリセットでも、新しいオプションが追加されたり、パラメータが変更になったりはするけれど
同じプリセットでの比較ってことで十分な気が
- 450 ：名無しさん＠編集中：2015/05/20(水) 10:45:31.71 ID:aOeCRpzC.net
- AVX2の有無でどれ程変わるのん？
- 451 ：名無しさん＠編集中：2015/05/20(水) 10:56:07.53 ID:iy7JRJZG.net
- >>450
>>440 >>444と同ソースで--asmをつけた結果。
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 2018 frames in 269.97s (7.47 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
encoded 2018 frames in 244.33s (8.26 fps), 5128.50 kb/s, SSIM Mean Y: 0.9926489 (21.336 dB)
1.7+002 16bpp --preset medium --tune ssim --ssim --crf 20 --asm avx
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 2018 frames in 395.72s (5.10 fps), 5241.37 kb/s, SSIM Mean Y: 0.9941964 (22.363 dB)
1.7+002 8bpp --preset medium --tune ssim --ssim --crf 20 --asm avx2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
encoded 2018 frames in 345.11s (5.85 fps), 5241.50 kb/s, SSIM Mean Y: 0.9941963 (22.363 dB)
- 452 ：名無しさん＠編集中：2015/05/20(水) 11:14:09.91 ID:aOeCRpzC.net
- 1割以上の効果があるのか～
ありがとう
- 453 ：名無しさん＠編集中：2015/05/20(水) 12:35:24.34 ID:Llc+DgAh.net
- x264だとあんだけAVX2使いまくっても
--asm avxと--asm avx2の差が2～3％しかなかったけど
x265だとAVX2がAVX2かなり効くんだな
- 454 ：名無しさん＠編集中：2015/05/20(水) 16:49:52.78 ID:HZ4G4I1G.net
- 高速化と高画質化が着々と進行してていい感じ
- 455 ：名無しさん＠編集中：2015/06/10(水) 21:18:02.20 ID:GuuQXTMl.net
- 10bitのexeでも8bit使えるようになったって見たんだけど--output-depth指定しても
x265 [warning]: falling back to default bit-depth
と表示されてエンコ結果も10bitになってるみたいだけどどうすればできる？
rigaya氏ビルド使ってる
- 456 ：名無しさん＠編集中：2015/06/11(木) 08:51:36.31 ID:vrkDIN1Y.net
- できますん
- 457 ：名無しさん＠編集中：2015/06/11(木) 09:29:13.15 ID:3al9+NHx.net
- できなくないですん
- 458 ：名無しさん＠編集中：2015/06/14(日) 02:10:18.80 ID:f36+6P8e.net
- 1.7+166着てるのか
- 459 ：名無しさん＠編集中：2015/06/16(火) 21:50:19.22 ID:v2G8PG9Y.net
- 一時期 --tune cbr ってのがあったみたいだけど、いつのまにか無くなったの？
- 460 ：名無しさん＠編集中：2015/06/17(水) 02:19:02.50 ID:Mr2FqQCj.net
- かなり実用的になってきてると思うんだけどなんでここまで過疎なんだ・・・
- 461 ：名無しさん＠編集中：2015/06/17(水) 02:27:39.59 ID:8xiHEtt7.net
- まだ道半ばも来ていない。
- 462 ：名無しさん＠編集中：2015/06/17(水) 03:07:35.82 ID:Mr2FqQCj.net
- まぁx264に比べちゃうとね・・・
- 463 ：名無しさん＠編集中：2015/06/17(水) 03:12:47.37 ID:ePVFJmB4.net
- デコーダが整備されてない
日本語のオプション解説サイトがない
再現性に問題有と散々言われている
流行るわけがない
- 464 ：名無しさん＠編集中：2015/06/17(水) 08:10:28.32 ID:Z8Vl6PNb.net
- 間違いなく置き換わるし
- 465 ：名無しさん＠編集中：2015/06/17(水) 11:34:03.77 ID:RYyTK5fP.net
- 今ビルドすると途中で終了するバイナリができちゃうね
- 466 ：名無しさん＠編集中：2015/06/17(水) 23:25:47.73 ID:Mr2FqQCj.net
- 俺はもうガンガン活用してるけどな、通勤中とかスマホで見るときとか
容量減らせるから途切れにくいしパケ代浮くしでかなりいいと思うけどな
最近のスマホはHWデコーダー載ってるわけだしな
- 467 ：名無しさん＠編集中：2015/06/18(木) 01:48:33.03 ID:izQm9FfU.net
- 熱でバッテリー爆発してもよいのなら
- 468 ：名無しさん＠編集中：2015/06/18(木) 02:40:11.51 ID:BnkVaq++.net
- 801だから無縁なんだよなぁ・・・
- 469 ：名無しさん＠編集中：2015/06/18(木) 10:28:07.57 ID:t/GL2YUT.net
- やだホモよ、ホモがいるわ
- 470 ：名無しさん＠編集中：2015/06/18(木) 13:10:13.95 ID:IPboZsre.net
- やおいとかそら無縁だろうなぁ・・・
- 471 ：名無しさん＠編集中：2015/06/18(木) 13:12:38.15 ID:t9a4HHhd.net
- x801って書くと何か卑猥・・・
- 472 ：名無しさん＠編集中：2015/06/24(水) 09:27:57.10 ID:DIAOr5JF.net
- 今の所、x265って暗部でのバンディングやブロックノイズの発生がCQの数値低めに設定しても防げなくない？
x264ならCQ21くらいで暗部もそこそこ満足できる画質になるんだけど
x265だとCQ21じゃあ全然解消されない
黒色の再現度が高いモニタで見るとそこまで気にならないんだけど、白っぽく映る安物液晶だと暗部が崩壊してるのがすぐ分かる
数ヶ月ほど、家族で自分しか見ない(DLNA使わない)動画はH.265にエンコしてたんだけど、今はH.264に戻しちゃった
- 473 ：名無しさん＠編集中：2015/06/24(水) 12:51:40.71 ID:M5sreByR.net
- >>472
x265は、実用するには早すぎる。
IntelがSkylakeにHEVCエンコーダーを積む予定だから、x265が本気出すのもその後あたりかと。
オープンソースはライバルがいないとダレやすいから。
- 474 ：名無しさん＠編集中：2015/06/24(水) 13:52:50.47 ID:DIAOr5JF.net
- >>473
なるほどなあ
x265と264比較してるような個人サイト、
大抵アニメの見栄えの良い明るい画面使って比較してるから
凄そうに見えたのに
実際にエンコやって見ると実写の濃い色の服の質感とか完全に殺されたりして
散々でしたわ
- 475 ：名無しさん＠編集中：2015/06/24(水) 14:21:12.79 ID:sKT7VGD8.net
- 現状の結論
264も265も再現性をより高めるにはビットレートを振るしかない
なので発展途上の265を選択するメリットはない
- 476 ：名無しさん＠編集中：2015/06/24(水) 15:11:25.80 ID:5qLer+EY.net
- x264だとqcompを上げるのが一つの処方箋だった気がする。
ほかに暗部にビットを回すor削られないようにするオプションってんあんかあったっけ？
- 477 ：名無しさん＠編集中：2015/06/24(水) 15:16:11.35 ID:5qLer+EY.net
- AQを思いっきり下げるとか。
x265自体、画質の向上がまだ最優先課題ってレベルだから"高画質"を求めるのは時期早々かもね。
- 478 ：名無しさん＠編集中：2015/06/24(水) 15:21:53.52 ID:60xXmepu.net
- 暗部を気にするならMain10でエンコすればいいんじゃないの？
Main10でもアカンの？
- 479 ：名無しさん＠編集中：2015/06/24(水) 15:37:24.14 ID:jNQuIAS+.net
- x264だって、暗部の問題が解決したのは開発後期にAQ関連の仕組みが導入されてからでしょ
x265はまだ全機能実装さえ済んでない状態
AQなどの派生技術を導入する時期じゃない
- 480 ：名無しさん＠編集中：2015/06/24(水) 18:57:14.27 ID:Rs4u+3+Q.net
- 海外で落としたエロがHEVCだったのでMPCに突っ込んだら観れなかった
VLCは観れたけどHEVCって言ってもいろいろあるのね
- 481 ：名無しさん＠編集中：2015/06/24(水) 19:12:25.43 ID:60xXmepu.net
- コンテナとかコーデックとかちゃんと理解したほうがいいと思うよ・・・
- 482 ：名無しさん＠編集中：2015/06/24(水) 21:37:00.42 ID:DIAOr5JF.net
- >>478
- 483 ：名無しさん＠編集中：2015/06/24(水) 21:38:02.19 ID:DIAOr5JF.net
- >>478
途中で書き込んでしまった
10bitでもダメでちたわ
- 484 ：名無しさん＠編集中：2015/06/26(金) 12:13:57.59 ID:EMEyWpzc.net
- qcomp オプションはどうでした？
80ぐらいで違いを確かめてもらいたいな。
- 485 ：名無しさん＠編集中：2015/06/26(金) 14:39:28.80 ID:21J4TSkU.net
- x264で言うところのAQに類する仕組みがまだx265には入ってない
だから当然、暗部や細部はx264より苦手
- 486 ：名無しさん＠編集中：2015/06/26(金) 14:57:05.22 ID:3w9RCHVj.net
- 今後の開発スケジュールとか決まってないのかな？
- 487 ：名無しさん＠編集中：2015/06/26(金) 15:17:26.28 ID:EMEyWpzc.net
- >>485
AQ自体は入ってるよ
内部的な動作は把握してないけどオプションはある。
画質自体はまだまだってこのスレに張られてた（と思うけど。
- 488 ：名無しさん＠編集中：2015/06/26(金) 16:45:52.58 ID:WapMSTrr.net
- 赤色はマシになったの
- 489 ：名無しさん＠編集中：2015/06/26(金) 18:25:57.01 ID:LIoEONiV.net
- なんだよ
x265ってまだ時期早漏かよ
- 490 ：名無しさん＠編集中：2015/06/26(金) 19:01:06.27 ID:vnoa8Ytk.net
- >>489
早漏はおまえだ。
- 491 ：名無しさん＠編集中：2015/06/27(土) 01:19:30.87 ID:oS5xVwj1.net
- おお…
- 492 ：名無しさん＠編集中：2015/06/27(土) 08:31:16.67 ID:Wz4orqrw.net
- 8it出力版と10bit出力版を合体させたやつが、batファイル一発で生成される！
これは便利！
ただ、msys版はshファイルに誤記があって途中で止まるｗ
VC12版は問題なくビルド出来た
- 493 ：名無しさん＠編集中：2015/06/27(土) 13:28:53.83 ID:l6Oe5HEN.net
- Win7環境にMSYS環境を構築し、Cmakeとhgを導入して以下のサイトを参考にx265のコンパイルを試みてみました。
http://xanadu62.blogspot.jp/2013/10/ffmpeg.html
hg clone https://bitbucket.org/multicoreware/x265
cd x265/build/msys
cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
-DENABLE_TESTS=ON -DENABLE_SHARED=OFF ..\..\source\
すると以下の様なエラーが返されコンパイルに失敗しました。何が原因でコンパイルに失敗したのでしょうか？
-- cmake version 3.2.1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_C_COMPILER:
x86_64-w64-mingw32-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_CXX_COMPILER:
x86_64-w64-mingw32-g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
- 494 ：名無しさん＠編集中：2015/06/27(土) 14:39:38.88 ID:UsG4h7yl.net
- PATH が通ってない
- 495 ：492：2015/06/27(土) 15:41:02.64 ID:l6Oe5HEN.net
- >>494
Cmakeを置いてある場所
D:\MSYS\cmake\bin
を環境変数のPATHに登録してみましたがやはりエラー内容は変わりませんでした。
うーん、何が原因でしょうか・・・
半年くらい前にx265をコンパイルしたときは特に問題無く通ったはずなんですが・・・
- 496 ：名無しさん＠編集中：2015/06/27(土) 15:46:02.47 ID:Wz4orqrw.net
- hg clone https://bitbucket.org/multicoreware/x265
cd x265/build/msys
ここにあるmultilib.shの中に
-DEXTRA_LIB=x265_main10.a
という記述があるけど、これは間違いじゃない？
- 497 ：名無しさん＠編集中：2015/06/27(土) 17:06:47.93 ID:sEawlLsz.net
- >>495
cd x265/build/msys
./make-Makefiles.sh
make
これじゃダメ？
- 498 ：492：2015/06/27(土) 21:37:46.86 ID:l6Oe5HEN.net
- >>496
すみません、込み入ったことは分かりません(´；ω；｀)
>>497
やってみましたがダメでした(´･ω･｀)
$ ./make-Makefiles.sh
-- cmake version 3.2.1
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_C_COMPILER:
x86_64-w64-mingw32-gcc
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
CMake Error at CMakeLists.txt:19 (project):
The CMAKE_CXX_COMPILER:
x86_64-w64-mingw32-g++
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
- 499 ： ◆tsGpSwX8mo ：2015/06/27(土) 22:03:18.49 ID:WqnHBzoK.net
- >>498
まずはPATH(gcc)の確認
- 500 ：名無しさん＠編集中：2015/06/27(土) 22:36:46.62 ID:07ob81ds.net
- >>493
はて、斜め読みだから的はずれなこと書いてたらごめんなさい。
>> cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
>> -DENABLE_TESTS=ON -DENABLE_SHARED=OFF ..\..\source\
>>CMake Error at CMakeLists.txt:19 (project):
>>The CMAKE_C_COMPILER:
>>x86_64-w64-mingw32-gcc
>>is not a full path and was not found in the PATH.
PERFIXでi686-w64-mingw32 (32bit用だっけ？)って書いてるのに
エラーメッセージで
x86_64-w64-mingw32-gccが無いって怒られてるよね・・・。
ここらへんじゃない？
- 501 ：名無しさん＠編集中：2015/06/27(土) 22:50:23.25 ID:07ob81ds.net
- ごめん、ものすごく的はずれなこと書いてたらしい。
忘れて。
- 502 ：492：2015/06/28(日) 04:27:18.91 ID:kJVbfWHG.net
- >>499
生きます(´；ω；｀)！
> まずはPATH(gcc)の確認
>>500
> x86_64-w64-mingw32-gccが無いって怒られてるよね・・・。
ハッ！今気付きました・・・。MSYS環境でコンパイルするときは単純にコマンドプロンプトを立ち上げるのでは無く
msys.batを実行してシェルを起動しなければならないということに・・・。というわけでmsys.batを実行してシェルを立ち上げ
そこであらためてx265のコンパイルを試みてみました。
結果は・・・また違ったエラーが返されました(´･ω･｀)
$ cmake.exe -DCMAKE_INSTALL_PREFIX=/mingw/i686-w64-mingw32 -DWINXP_SUPPORT=ON
-DENABLE_TESTS=ON -DENABLE_SHARED=OFF ../../source/
-- cmake version 3.2.1
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe -- broken
CMake Error at D:/MSYS/cmake/share/cmake-3.2/Modules/CMakeTestCCompiler.cmake:61
(message):
The C compiler "D:/MSYS/mingw/bin/x86_64-w64-mingw32-gcc.exe" is not able
to compile a simple test program.
It fails with the following output:
Change Dir: D:/MSYS/x265/build/msys/CMakeFiles/CMakeTmp
(続く）
- 503 ：492：2015/06/28(日) 04:28:36.90 ID:kJVbfWHG.net
- (続き)
Run Build Command:"C:/cygwin/bin/make.exe"
"cmTryCompileExec2492638483/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec2492638483.dir/build.make
CMakeFiles/cmTryCompileExec2492638483.dir/build
make[1]: Entering directory
'/cygdrive/d/MSYS/x265/build/msys/CMakeFiles/CMakeTmp'
/D/MSYS/cmake/bin/cmake.exe -E cmake_progress_report
/D/MSYS/x265/build/msys/CMakeFiles/CMakeTmp/CMakeFiles 1
make[1]: /D/MSYS/cmake/bin/cmake.exe: Command not found
CMakeFiles/cmTryCompileExec2492638483.dir/build.make:57: recipe for target
'CMakeFiles/cmTryCompileExec2492638483.dir/testCCompiler.c.obj' failed
make[1]: ***
[CMakeFiles/cmTryCompileExec2492638483.dir/testCCompiler.c.obj] Error 127
make[1]: Leaving directory
'/cygdrive/d/MSYS/x265/build/msys/CMakeFiles/CMakeTmp'
Makefile:117: recipe for target 'cmTryCompileExec2492638483/fast' failed
make: *** [cmTryCompileExec2492638483/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:19 (project)
-- Configuring incomplete, errors occurred!
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/MSYS/x265/build/msys/CMakeFiles/CMakeError.log".
コンパイラーが壊れてるってどういうことでしょうか？MSYSを再インストールしろってことでしょうか？
- 504 ： ◆tsGpSwX8mo ：2015/06/28(日) 06:17:57.29 ID:7ma/nKKp.net
- >>503
CygwinをPATHから外すとどうなる(cygwinディレクトリをリネームでもおｋ)？
- 505 ：名無しさん＠編集中：2015/06/28(日) 07:25:10.29 ID:hIou2o11.net
- なんで コンパイラのエラーも読めないヤツが
コンパイルしようとしてんの？
- 506 ：名無しさん＠編集中：2015/06/28(日) 08:08:48.17 ID:kZOLiJyl.net
- というか、普通に環境づくりが失敗してるだけでしょ
全自動で環境作ってくれるスクリプトとか配布してるところあるんだから
そういうの使って１発全自動で環境つくれよ
それで解決だよ
- 507 ：名無しさん＠編集中：2015/06/28(日) 09:59:08.61 ID:fYmTl1Mq.net
- そもそもmake-Makefiles.shがあるのに何でcmakeのコマンドを直接叩いてるんだろうという疑問が・・・
cmake -G "MSYS Makefiles" ../../source
としてMSYS Makefilesを明示しないとcmakeが勝手にコンパイラを選択したはず
いちいち面倒くさいことせず、MSVCでやる方法が一番簡単だと思うな
- 508 ：名無しさん＠編集中：2015/07/04(土) 00:45:41.40 ID:YGz1q9Lu.net
- 12bit意外と早く来そうだな
- 509 ：名無しさん＠編集中：2015/07/04(土) 06:45:29.92 ID:AzJNmnE3.net
- Multibitええね
何がいいって、ビルドするときに1コマンドでいいのがｗ
exeはちょっとでかくなるけど気にしない
- 510 ：名無しさん＠編集中：2015/07/04(土) 11:26:38.48 ID:LaJ5nNJQ.net
- そんなに使い分けてるの？
- 511 ：名無しさん＠編集中：2015/07/04(土) 12:51:35.76 ID:AzJNmnE3.net
- 使い分けてない
いつも使ってるのは10bit
ただ、最近導入されたmultilib.batがクソ楽ちんなんで絶賛してるだけ
- 512 ：名無しさん＠編集中：2015/07/14(火) 18:47:52.37 ID:idZm8Phr.net
- XP対応でビルドされたやつは配布されていないの？
- 513 ：名無しさん＠編集中：2015/07/14(火) 19:36:02.32 ID:idZm8Phr.net
- とりあえず探してみた結果
XPで作動するやつ
作動可能
x265_0.7+289_x86.exe
x265_0.8+3_x86.exe
作動可能だが、やや作動が怪しい
x265_0.8+61_x86.exe
x265_0.8+149_x86.exe
作動不可
x265_0.8+190_x86.exe
作動不可の原因はVista以降に使われている関数、
SleepConditionVariableCSが原因です
- 514 ：名無しさん＠編集中：2015/07/14(火) 19:39:39.31 ID:idZm8Phr.net
- こののやつのバイナリは最新版もXPで作動するね
http://x265.ru/en/builds
- 515 ：名無しさん＠編集中：2015/07/14(火) 19:57:17.95 ID:idZm8Phr.net
- >>513のは
ttp://rigaya34589.blog135.fc2.com/
ttps://www.dropbox.com/sh/lolsllkm6zxvsn2/AADSh5bFuZnN1Nq78vmDhu1ga/old?dl=0
- 516 ：名無しさん＠編集中：2015/07/14(火) 21:43:14.97 ID:0sHf5gOl.net
- 自分でどうこう出来ないならXP使うなよｗｗ
- 517 ：名無しさん＠編集中：2015/07/15(水) 14:46:48.25 ID:Dln1hXUc.net
- 自分でXP対応でビルドすればいいと言ってみる
- 518 ：名無しさん＠編集中：2015/07/15(水) 15:42:54.53 ID:ENlb271m.net
- XPはマルチコア時の性能が低い
貧乏人ならLinux使った方がマシ
- 519 ：名無しさん＠編集中：2015/07/15(水) 18:18:06.19 ID:DXiTqnAr.net
- XP使ってる貧乏人なんだからシングルコアの可能性もあるだろ
- 520 ：名無しさん＠編集中：2015/07/15(水) 19:54:44.34 ID:F6Dht5ea.net
- いやさすがにそれは・・・
- 521 ：名無しさん＠編集中：2015/07/16(木) 00:14:28.25 ID:ZRyn4IRA.net
- intel HTT(Hyper Threading Technology)じゃ駄目か？
- 522 ：名無しさん＠編集中：2015/07/16(木) 08:16:36.84 ID:f1hZBsh9.net
- 今1.7だよね
何故0.8とかなの？
- 523 ：名無しさん＠編集中：2015/07/18(土) 14:55:18.41 ID:68ZYLSDZ.net
- 情弱からの改竄職人 とーる君
メールアドレス：sjfosfoasfo@yahoo.co.jp
携帯番号：08066192913
37o0d5M
- 524 ：08066192913：2015/07/18(土) 19:12:25.80 ID:bBMzk35F.net
- 情弱からの改竄職人 とーる君
- 525 ：08066192913：2015/07/18(土) 19:13:04.85 ID:bBMzk35F.net
- メールアドレス：sjfosfoasfo@yahoo.co.jp
- 526 ：08066192913：2015/07/18(土) 20:16:30.92 ID:IE1b+ET3.net
- あ
- 527 ：08066192913：2015/07/18(土) 20:17:13.58 ID:SoskPJ+N.net
- い
- 528 ：08066192913：2015/07/19(日) 13:05:04.98 ID:RJp4FHa5.net
- 情弱からの改竄職人 とーる君
88XzdAMl
- 529 ：08066192913：2015/07/19(日) 18:12:32.22 ID:EX1fxnmk.net
- 02T9Qhq0
- 530 ：08066192913：2015/07/19(日) 18:12:54.11 ID:EX1fxnmk.net
- 34KV3VQ8
- 531 ：名無しさん＠編集中：2015/07/19(日) 21:40:33.40 ID:1gnsFKQG.net
- avi：映像制作［レス削除］
http://qb5.2ch.net/test/read.cgi/saku/1310326982/43-
- 532 ：08066192913：2015/07/20(月) 03:36:57.20 ID:NeURmLNR.net
- bt742CY7
- 533 ：08066192913：2015/07/20(月) 10:27:00.48 ID:d4VaFPJ9.net
- 1zzlNflJ
- 534 ：08066192913：2015/07/20(月) 10:29:46.33 ID:vWDQMbiN.net
- 情弱からの改竄職人 とーる君
1zzlNflJ
- 535 ：名無しさん＠編集中：2015/07/24(金) 02:22:33.01 ID:qIPjjeFO.net
- Windows2000でH.265をエンコードしてみる
http://www.nico video.jp/watch/sm26774171
- 536 ：名無しさん＠編集中：2015/07/26(日) 17:42:48.79 ID:lSABQG3J.net
- 12bitのFourCCってないの？
- 537 ：名無しさん＠編集中：2015/07/26(日) 19:10:11.69 ID:bAcAj12A.net
- そんなAVIの遺物をいつまでも引きずるな
- 538 ：名無しさん＠編集中：2015/07/27(月) 14:01:50.09 ID:WXFY+U6V.net
- 12bitエンコ出来るようになったのはいいけど、デコーダーがまだ無いな
- 539 ：名無しさん＠編集中：2015/07/27(月) 14:17:11.84 ID:zmqr9Jt6.net
- えっ
- 540 ：名無しさん＠編集中：2015/07/27(月) 15:06:33.32 ID:RYhN1uKU.net
- >>539
12bitをちゃんとデコードできるデコーダーがあるなら挙げてみ？
- 541 ：名無しさん＠編集中：2015/07/27(月) 18:17:58.85 ID:MoB8fNT9.net
- デコーダのないエンコーダって意味あるんですかねそれ
- 542 ：名無しさん＠編集中：2015/07/27(月) 18:22:12.79 ID:RYhN1uKU.net
- experimentalな段階で意味つってもな。
x265 [warning]: Main12 is HIGHLY experimental, do not use!
- 543 ：名無しさん＠編集中：2015/07/27(月) 18:25:34.41 ID:AhU7j0d9.net
- 12bitって画質とサイズの費用対効果で言うとどうなん？
10bitだと8bitより効率いいみたいだけど。
- 544 ：名無しさん＠編集中：2015/07/27(月) 18:44:46.44 ID:XMdjkvfw.net
- 先にインタレサポートして欲しいよ
- 545 ：名無しさん＠編集中：2015/07/27(月) 18:46:31.30 ID:X6RbocHm.net
- 12bitはBT.2020環境下でバンディングノイズを出さないようにすることを前提としたものであって、現時点で一般ユーザーが使わなければならないようなものじゃない。
- 546 ：名無しさん＠編集中：2015/07/27(月) 19:20:47.97 ID:4GogWDeS.net
- 自分用に使うに決まってんじゃん
- 547 ：名無しさん＠編集中：2015/07/27(月) 19:50:36.98 ID:X6RbocHm.net
- 豚に真珠
- 548 ：名無しさん＠編集中：2015/07/27(月) 20:40:45.21 ID:RYhN1uKU.net
- >>543
デコードできないからとりあえずcrf20でSSIMだけでも調べてみようと思ったらこんな結果になった。
experimentalすぎて何もできない段階かな。
x265 [info]: HEVC encoder version 1.7+373-db59e6d9b85b
--tune ssim --ssim --crf 20
8bit
encoded 2018 frames in 278.43s (7.25 fps), 4988.06 kb/s, SSIM Mean Y: 0.9928450 (21.454 dB)
10bit
encoded 2018 frames in 368.82s (5.47 fps), 4875.11 kb/s, SSIM Mean Y: 0.9941356 (22.318 dB)
12bit
encoded 2018 frames in 676.06s (2.98 fps), 13733.34 kb/s, SSIM Mean Y: 0.6725987 ( 4.849 dB)
- 549 ：名無しさん＠編集中：2015/07/27(月) 20:57:29.12 ID:Ep+Jd60L.net
- そのようで・・
- 550 ：名無しさん＠編集中：2015/07/27(月) 20:59:25.49 ID:AhU7j0d9.net
- >>548
おお、調べてくれてありがと
- 551 ：名無しさん＠編集中：2015/07/27(月) 21:37:26.63 ID:zmqr9Jt6.net
- >>540
ちゃんとって今のデコーダは完全ではないってこと？この動画は表示できてるけど
ttp://forum.doom9.org/showthread.php?p=1731344#post1731344
LSMASHVideoSource(stacked = true, format = "YUV420P16")
Dither_convert_yuv_to_rgb(matrix = "709", lsb_in = true, output = "rgb24", ampn = 0)
8bit
http://i.imgur.com/eung4u9.png
10bit
http://i.imgur.com/0Ucr1NP.png
12bit
http://i.imgur.com/EGc887U.png
- 552 ：名無しさん＠編集中：2015/07/27(月) 23:31:34.84 ID:RYhN1uKU.net
- >>551
それはちゃんと見れるね・・・。デコードできないというのはどうもこちらの勘違いだった模様。まじごめん。
rigayaさんのとこのx265_1.7+373_x64を使って12bitエンコして
MPC-HC1.7.9(内蔵LAV0.65)やL-SMASH Worksでデコードすると、
ttp://www.dotup.org/uploda/www.dotup.org436826.jpg.html
のようにおかしくなるんで、12bitはまだ正常にデコードできないものだと思い込んでしまった。
>>548もそのバイナリを使った結果なので、参考にしないほうがいい。
試しに>>551のリンク先にあるx265_1.7+371-24c1ee516d13.GCC492の
Win64\x265_ml.exeで12bitエンコしてみたら普通に見れた。
つうことで、12bitも普通にデコードできるってことでいいのかな・・・。
- 553 ：名無しさん＠編集中：2015/07/28(火) 00:22:42.61 ID:xs+H8iag.net
- 許さん。二度と来るな。消えろ。氏ね。
- 554 ：名無しさん＠編集中：2015/07/28(火) 16:25:43.22 ID:W4i+wzm1.net
- ファーｗ
- 555 ：名無しさん＠編集中：2015/07/30(木) 12:48:57.21 ID:4Dgns5PX.net
- 12bit出力試してみたけど
TSとかのYV12ソースをDitherで１6bit主力i420での12bitはうまくできたけど
ゲームとか録画したRGBソースを
YUV24化してi444の12bit出力がなんか緑がかった画面になってうまくいかんかった。
Outputdepthを10bitはうまくできたんだけども。
ようわかりません。
- 556 ：名無しさん＠編集中：2015/07/30(木) 12:51:49.53 ID:4Dgns5PX.net
- YUV24じゃなｋったYV24だった。すみません。
Dither_convert_rgb_to_yuv(matrix="601",tv_range=true,lsb=true,mode=-1,output="YV24")
- 557 ：名無しさん＠編集中：2015/07/30(木) 15:57:29.21 ID:RtKKrWDv.net
- >>555-556
1.7+380で12bit i444出力して試してみた。
1. MPC-BE1.4.5でMPC Video Decoder＋EVRの場合は、RGB32出力されて正常に再生される。
2. MPC-HC1.7.9（LAV Filters 0.65）＋EVRの場合は、RGB32出力されて緑になってしまう。
3. MPC-HC1.7.9（LAV Filters 0.65）＋madVRの場合は、Y416出力されて正常に再生される。
そっちの再生環境が書かれてないので2.で再生したのかどうかは知らんけど、
もし2..なのだとしたらLAV Video Decoderの12bitYUV4:4:4→RGB32変換がおかしいんだと思う。
- 558 ：名無しさん＠編集中：2015/07/30(木) 16:30:29.67 ID:4Dgns5PX.net
- >>557
LAV Filters 0.65使ってます。
まさに２の状態でした。
検証いただきありがとうございました。
- 559 ：名無しさん＠編集中：2015/09/02(水) 10:27:01.07 ID:17+7uTqX.net
- tst
- 560 ：名無しさん＠編集中：2015/09/08(火) 19:34:59.32 ID:6BnL2XmX.net
- なんか、今ビルドしたexe使うと、マルチスレッドが全く効いてないようなんだが、
変な変更入った？
- 561 ：名無しさん＠編集中：2015/09/08(火) 20:14:56.68 ID:IIsd4ht2.net
- 自前でビルドするなら、コミットログ位自分で確認しろよ。
https://bitbucket.org/multicoreware/x265/commits/e1adac00dce8e5641cbe9aec3d50a72261c308d9
- 562 ：名無しさん＠編集中：2015/09/08(火) 20:21:29.94 ID:fH222Kze.net
- ﾏﾝﾄﾞｸｾ('A`)･･･
- 563 ：名無しさん＠編集中：2015/09/08(火) 22:17:30.18 ID:6BnL2XmX.net
- >>561
いや、それが機能してないんじゃないか？という指摘なんだが、
ただ読んでるだけのお前より、実際に使ってる人の実体験のほうが重要だろ
- 564 ：名無しさん＠編集中：2015/09/09(水) 00:25:49.62 ID:ucrN+mFp.net
- 何の具体的な情報も出さずに、実体験の方が重要だろって言っちゃうって、すごいな。
俺はUFOを見たんだ。実際にこの目で見たんだ。
って言われてもなぁ・・・。
- 565 ：名無しさん＠編集中：2015/09/09(水) 00:54:51.47 ID:lhJuTuku.net
- どうせおま環だろ
- 566 ：名無しさん＠編集中：2015/09/09(水) 13:49:23.15 ID:16H1IFVw.net
- >>563
実体験がなんだ？
スクロールすら出来ない奴がブツブツほざくなよ、雑魚が。
ビルドどころか、PC使うの辞めたほうが良いレベル、
それが世の為人の為。
- 567 ：名無しさん＠編集中：2015/09/09(水) 14:06:01.69 ID:16H1IFVw.net
- ちなみに、ID:IIsd4htは俺だ。
イライラしてて、書き方が乱暴になった。
>>560に対して、>>561で対象の変更と、
そこですでに開発者にバグ報告されて、
開発者も内容理解して、翌日fixすると
やりとりまでされた情報出したにも関わらず、
なんで>>563で、俺が文句言われなきゃならん訳？
お前が質問だけして、出された情報を全く理解出来ない奴って事だけは分かった。
人の話聞く気が無いなら、質問なんてするなよ、低能。
- 568 ：名無しさん＠編集中：2015/09/09(水) 14:07:33.68 ID:16H1IFVw.net
- ID:IIsd4ht2
IDまで書きミスったじゃねーかよ、ボケ。
- 569 ：名無しさん＠編集中：2015/09/09(水) 16:55:08.06 ID:rTRAxpt2.net
- 以上、低脳劇場でした。(完)
- 570 ：名無しさん＠編集中：2015/09/09(水) 17:03:55.87 ID:7U0Uqkc8.net
- 1.7+478-365f7ed4d896 これで Fix されたね。
- 571 ：名無しさん＠編集中：2015/09/10(木) 06:24:59.07 ID:IzPmuN2L.net
- >>566>>567
実体験は超重要
- 572 ：名無しさん＠編集中：2015/09/10(木) 08:17:05.65 ID:1Cb4E+Y/.net
- 質がある程度保証されるフォーラムとかならともかく、
ほとんどが「こちらの勘違いでした」で終わるような掲示板で語られる実体験は微妙じゃないかい？
たまに当たりがあるのは否定しないけれど
- 573 ：名無しさん＠編集中：2015/09/10(木) 08:35:43.13 ID:YOKNJnul.net
- 結局誰も試してないっぽいしおま環かも実際にそうなのかもわからんわｗ
- 574 ：名無しさん＠編集中：2015/09/10(木) 08:40:39.32 ID:WsVHyNvR.net
- ちょっと何言ってるか分かんない
- 575 ：名無しさん＠編集中：2015/09/10(木) 22:32:37.33 ID:KJ0kRu7c.net
- なんか良さげな更新があってスレ進んだのかなと思って見に来たのに
なんじゃこりゃ
- 576 ：名無しさん＠編集中：2015/09/12(土) 00:18:42.15 ID:XaHNf2Ma.net
- prepareになってから一か月経ってんのか…
- 577 ：名無しさん＠編集中：2015/09/17(木) 07:35:56.04 ID:Vin772sA.net
- 突然x265の開発が停滞しだしたけど、何かあったの？
- 578 ：名無しさん＠編集中：2015/10/08(木) 21:13:37.20 ID:6W1l538e.net
- >>x265 version 1.8 has been released.
>>This release supports 12bit input depths, a large amount of AVX2 optimizations, entropy coding optimizations, as well as new quality features.
- 579 ：名無しさん＠編集中：2015/10/08(木) 22:51:27.95 ID:uYI8xAvc.net
- するの？それともされたの？
- 580 ：名無しさん＠編集中：2015/10/09(金) 00:50:54.95 ID:exeJoz3M.net
- >>579
has been
- 581 ：名無しさん＠編集中：2015/10/09(金) 01:18:40.45 ID:u8RFIes1.net
- 適当にベンチ 詳細はテキストに
ソース https://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
faster
1.7 encoded 313 frames in 14.20s (22.05 fps), 600.65 kb/s, SSIM Mean Y: 0.9259115 (11.302 dB)
1.8 encoded 313 frames in 13.99s (22.37 fps), 598.68 kb/s, SSIM Mean Y: 0.9264626 (11.335dB)
fast
1.7 encoded 313 frames in 29.44s (10.63 fps), 593.51 kb/s, SSIM Mean Y: 0.9310887 (11.617 dB)
1.8 encoded 313 frames in 23.90s (13.10 fps), 591.59 kb/s, SSIM Mean Y: 0.9307948 (11.599dB)
medium
1.7 encoded 313 frames in 34.93s (8.96 fps), 592.51 kb/s, SSIM Mean Y: 0.9329568 (11.736 dB)
1.8 encoded 313 frames in 30.54s (10.25 fps), 585.75 kb/s, SSIM Mean Y: 0.9326935 (11.719dB)
slow
1.7 encoded 313 frames in 129.29s (2.42 fps), 587.25 kb/s, SSIM Mean Y: 0.9359766 (11.937 dB)
1.8 encoded 313 frames in 115.54s (2.71 fps), 584.54 kb/s, SSIM Mean Y: 0.9358390 (11.927dB)
slower
1.7 encoded 313 frames in 276.12s (1.13 fps), 584.50 kb/s, SSIM Mean Y: 0.9372324 (12.023 dB)
1.8 encoded 313 frames in 222.83s (1.40 fps), 582.14 kb/s, SSIM Mean Y: 0.9366779 (11.984dB)
x264 core:146 r2555 0c21480
veryslow
encoded 313 frames, 17.80 fps, 622.27 kb/s, SSIM Mean Y:0.9211507 (11.032db)
http://www.dotup.org/uploda/www.dotup.org551550.txt
- 582 ：名無しさん＠編集中：2015/10/09(金) 07:27:39.06 ID:Q96PdMlI.net
- あれま1.8ってあったのね
- 583 ：名無しさん＠編集中：2015/10/09(金) 09:10:50.86 ID:GV+ZIqNz.net
- >>580,580
ｔｈｘ！
- 584 ：名無しさん＠編集中：2015/10/09(金) 10:18:28.60 ID:FcOiDfHW.net
- >>581
CPU何使ってるの？
- 585 ：名無しさん＠編集中：2015/10/09(金) 23:37:12.17 ID:u8RFIes1.net
- AMDのFX-8300定格です
- 586 ：名無しさん＠編集中：2015/10/10(土) 00:08:51.18 ID:TUv/1SN/.net
- さすがエンコ向けなだけあるな
- 587 ：名無しさん＠編集中：2015/10/11(日) 22:52:22.59 ID:sQ9XJT0L.net
- AVX2無しでも結構変わるのかなこりゃ
fastとslowerの伸び率凄いな
- 588 ：名無しさん＠編集中：2015/10/11(日) 23:35:19.31 ID:1iAxDOqX.net
- rigayaさんは今年も年末辺りにx265の速度比較してくれるのかな
- 589 ：名無しさん＠編集中：2015/10/12(月) 00:46:55.70 ID:WVekvBHO.net
- 自前ビルドなんでVerがちょっと新しいけど>>581とHEVCだけ同じ事やってみた
x265 [info]: HEVC encoder version 1.8+30-030744551098
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
faster
encoded 313 frames in 4.68s (66.84 fps), 598.41 kb/s, Avg QP:31.37, SSIM Mean Y: 0.9264005 (11.331 dB)
fast
encoded 313 frames in 6.63s (47.25 fps), 588.29 kb/s, Avg QP:35.56, SSIM Mean Y: 0.9305941 (11.586 dB)
medium
encoded 313 frames in 8.02s (39.01 fps), 585.12 kb/s, Avg QP:35.54, SSIM Mean Y: 0.9326401 (11.716 dB)
slow
encoded 313 frames in 28.55s (10.96 fps), 581.17 kb/s, Avg QP:34.81, SSIM Mean Y: 0.9355421 (11.907 dB)
slower
encoded 313 frames in 60.20s (5.20 fps), 579.85 kb/s, Avg QP:35.67, SSIM Mean Y: 0.9365124 (11.973 dB)
CPUは5960X 4.2GHz、
4コアのi7辺りでテスト出来れば、もうちょっと比較になるけど、
AVX2持っててすぐにテスト出来るのがこれだけだったから。
- 590 ：名無しさん＠編集中：2015/10/12(月) 01:21:47.76 ID:7qlqVooM.net
- >>589
おおお！
すごい速度が出てるなあ
5960X恐るべし
- 591 ：名無しさん＠編集中：2015/10/19(月) 09:30:21.53 ID:yFiWBold.net
- midium、SD解像度ならSandy i5でもそこそこ実用的な速度だなぁ
- 592 ：名無しさん＠編集中：2015/10/19(月) 17:08:24.78 ID:3+3B3ynS.net
- ここ数日、ビルド出来なくなってるな
- 593 ：名無しさん＠編集中：2015/10/20(火) 02:26:43.01 ID:4gF8GZ9l.net
- Intra refreshってなんだ
- 594 ：名無しさん＠編集中：2015/10/21(水) 12:52:02.41 ID:wDWh+p6H.net
- ブロードキャスト用でしょ
- 595 ：名無しさん＠編集中：2015/10/23(金) 10:02:07.23 ID:tigdGsjm.net
- ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
- 596 ：名無しさん＠編集中：2015/10/27(火) 21:58:53.54 ID:HfJdvsW+.net
- 8,10,12bitを出力出来るmultilibなx265.exeのビルドは
Rigaya氏を参考にVS2013で成功、
http://mylabo.webcrow.jp/ さんの環境とスクリプトを応用してGCC5.2で成功しました
しかし、ffmpegにMultilbなx265を組み込むのがうまくできません
どこか参考になるサイトなどあったら教えてください
- 597 ：名無しさん＠編集中：2015/10/28(水) 17:36:55.29 ID:APLDwghM.net
- 同じavisynthからの入力で8bitでエンコしたものと
10bitでエンコしたものではアウトプットの色が若干違ってしまいます
オプションは8bitのものをそのまま使ってますが
10bit用に何か設定しないといけないものがあるのでしょうか
ちなみに8bitでエンコしたものは入力と同じ色で出力されています
- 598 ：名無しさん＠編集中：2015/10/28(水) 19:01:55.48 ID:8El7diMy.net
- >>597
特に必要な設定は無いと思うけど、
・使用したx265のバイナリのURLやリビジョン
・エンコードに使ったツールやコマンドライン、x265のエンコードオプション、エンコードログなど
・avsの内容
・色の違いの確認に使ったツールや設定等（再生プレーヤー、デコーダー等）
・色の違いというのが具体的にわかる比較用スクリーンショット
と言った情報をちゃんと出せば答えてくれる人がいるかもね。
- 599 ：名無しさん＠編集中：2015/10/28(水) 19:16:21.95 ID:+oncCKMQ.net
- 質問させてください
コマンドプロンプト画面でx264のように
エンコードの終わり予想タイムは出ないのですか
だいたいの目安になるのでもし表示させる方法があったらお願いします
- 600 ：名無しさん＠編集中：2015/10/28(水) 19:27:19.30 ID:2TscTojl.net
- >>599
avs4x26x使ってるけど出てる気がする
- 601 ：名無しさん＠編集中：2015/10/28(水) 20:08:55.37 ID:s5f82YBj.net
- >>596
https://github.com/jb-alvarado/media-autobuild_suite
これ使えば全自動
- 602 ：名無しさん＠編集中：2015/10/28(水) 20:13:55.37 ID:+oncCKMQ.net
- >>600
avs2pipemodでは出ないです
avs4x26xを試してみます
ありがとう
- 603 ：名無しさん＠編集中：2015/10/29(木) 08:57:26.76 ID:2tL2U4Zq.net
- >>597
x64のLavだとおかしくなる
x86だと正常に出力される
何だろね
- 604 ：595：2015/10/29(木) 14:38:45.78 ID:hokEF0fR.net
- >>601
うわ！なんか凄いのがあるんですね
色々試してみます
- 605 ：名無しさん＠編集中：2015/10/29(木) 17:52:52.35 ID:hokEF0fR.net
- >>601
早速試してみたところ、最初のfreepypeのビルドであっさりエラーで停止
全自動とは程遠いｗ
スクリプトのx265のところを覗いて見ましたが、
普通にx265のソースをgit cloneした時のMSYSのところにあるmultilib.shと同じことをしているようだけど、、、
12bit版のlibx265.aをビルドし、libx265_main12.aにリネームし、8bit用のフォルダにコピー
10bit版のlibx265.aをビルドし、libx265_main10.aにリネームし、8bit用のフォルダにコピー
8bit版のlibx265.aをビルドし、libx265_main.aにリネームし、
arコマンドを使って上記３個を結合し、libx265.aとする
ここまではmultilib.shと全く同じ
問題は、この後make installをどうやるか。
普通にmake installするとエラーが出て出来ない。そのせいでffmpegに組み込めない。。。
- 606 ：名無しさん＠編集中：2015/10/29(木) 18:47:45.30 ID:KEjOdrQp.net
- rigaya氏のバッチで充分。
- 607 ：名無しさん＠編集中：2015/10/29(木) 18:49:22.39 ID:hokEF0fR.net
- それはexeを作る場合だね
その話はしてないので。
- 608 ：名無しさん＠編集中：2015/10/29(木) 19:08:17.76 ID:KEjOdrQp.net
- ぶっちゃけ流れ読んでかなったからごめんよ!
- 609 ：名無しさん＠編集中：2015/10/29(木) 19:21:33.49 ID:hokEF0fR.net
- うーん、libx265を除いておけばビルド成功する状態なのに、
--enable-libx265を入れると成功しない
「ERROR: x265 not found using pkg-config」
というメッセージが出る
もちろん、multilibではない普通のlibx265を組み込むのは成功してます
- 610 ：名無しさん＠編集中：2015/10/29(木) 19:50:40.90 ID:GqQK4kTk.net
- 今ゼロからやってみたがfreetypeは普通にビルドできるな
もう１回やってみたら
- 611 ：名無しさん＠編集中：2015/11/04(水) 19:24:15.28 ID:bY3Gmjjh.net
- ロシアのバイナリを使っているんですけど
GCCとかICCとかVISUA C++とか違いはコンパイルツール？だそうですけど
どれがお勧めなんですか
- 612 ：名無しさん＠編集中：2015/11/04(水) 19:36:10.00 ID:aZP/zq43.net
- どれでも大差なし
- 613 ：名無しさん＠編集中：2015/11/04(水) 19:51:13.54 ID:bY3Gmjjh.net
- そうなんですか
ICC使っときます
ありがとう
- 614 ：名無しさん＠編集中：2015/11/04(水) 23:15:59.75 ID:e9GNmcr1.net
- あえて言えばVSがWinでは速い？のかな
- 615 ：名無しさん＠編集中：2015/11/05(木) 08:18:36.25 ID:zXSftKub.net
- 早いところVS2015に対応てほしい
- 616 ：名無しさん＠編集中：2015/11/05(木) 17:48:42.31 ID:nPPKDmWy.net
- sln少し書き換えれば2015でビルド出来るよ
- 617 ：名無しさん＠編集中：2015/11/05(木) 23:39:10.13 ID:A8+5sKPz.net
- 対応・・・？
ビルドする人なら対応なんぞ特にいらんだろ
- 618 ：名無しさん＠編集中：2015/11/06(金) 11:09:19.93 ID:fy2s3Lcb.net
- >>616
ん？ソリューションファイルなんて、弄る必要有ったっけ？
cmakeのtargetをVS2015にするだけで良かった気がするけど。
- 619 ：名無しさん＠編集中：2015/11/06(金) 13:10:44.19 ID:ysZ3FpZt.net
- >>618
あ、ごめんそっちだったｗｗ
make-solutions.bat のやつを次の行のようにするだけだな。
cmake -G "Visual Studio 14 Win64" ..\..\source && cmake-gui ..\..\source
- 620 ：名無しさん＠編集中：2015/11/08(日) 19:01:12.75 ID:LWtfbo8L.net
- さっきまで1.8+93（MSCV2013で自ビルド）テストしてたけど、ロシアサイトのインテルコンパイラ版（古いバージョン）
より速くなってた。
着実に進化してますな。
- 621 ：名無しさん＠編集中：2015/11/28(土) 06:26:26.50 ID:xnQKeIKd.net
- しっかし、進展ないと過疎すぎるな・・・
- 622 ：名無しさん＠編集中：2015/11/28(土) 10:08:11.74 ID:jmEC8E0s.net
- いつからの進展なのか知らないが
確実に進歩してるぞ
- 623 ：名無しさん＠編集中：2015/11/30(月) 23:21:51.00 ID:Dp01uuLv.net
- いつの間にかすごい速くなってますね
- 624 ：名無しさん＠編集中：2015/11/30(月) 23:30:39.00 ID:/6tzZX36.net
- 日本語でおｋ
- 625 ：名無しさん＠編集中：2015/12/05(土) 11:39:48.52 ID:HP9A4Irs.net
- インドの大雨のせいで今開発が滞っているらしい
エンジニアの大半はインドにいるんだとか
- 626 ：名無しさん＠編集中：2015/12/05(土) 13:24:08.05 ID:j/JKm4pn.net
- 道理でカレーとタンドリーチキン動画のエンコだけは早いわけだ
- 627 ：名無しさん＠編集中：2015/12/05(土) 14:32:20.10 ID:rfE+JCrx.net
- _,._
( ﾟДﾟ) ・・・
- 628 ：名無しさん＠編集中：2015/12/05(土) 22:04:26.39 ID:8cfk2vXJ.net
- 大雨でインドア中か
- 629 ：名無しさん＠編集中：2015/12/05(土) 22:22:32.22 ID:OGp3Rmbu.net
- 自宅が水で浸かってるのにインドアってなんじゃい
- 630 ：名無しさん＠編集中：2015/12/05(土) 22:30:08.64 ID:1ig9YDeb.net
- インド人もびっくり
- 631 ：名無しさん＠編集中：2015/12/06(日) 11:19:00.57 ID:0gVCYaZ3.net
- >>609
それ、もしかすると本家でも問題になってるかもしれない
x265_config.h に「include <stdbool.h>」を書き足したら動くかも。
media-autobuild_suiteを使うならbuild/patchesにパッチを置いてmedia-suite_compile.shを編集してdo_patchする必要がありそう
https://bitbucket.org/multicoreware/x265/issues/125/x265-not-found-using-pkg-config#comment-23734777
- 632 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 12:27:21.04 ID:nlnTVFDP.net
- rigayaさんのところのx265のverが一気に進んでるけど
開発者は無事に帰れたの？
- 633 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 15:52:12.96 ID:vodPq1d5.net
- え？
Rigayaさんはただ自分でビルドしたものを公開してるだけで、
Rigayaさんがx265開発してるわけじゃないんだけど。
x265は時々、しばらく更新停止した後に突然何十個ものアップデートが公開される時がある
- 634 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 16:01:44.81 ID:nlnTVFDP.net
- 更新が無かったから更新されてなかったのかな、と
- 635 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 16:15:03.73 ID:BMjI76th.net
- >>634
リポジトリを確認するようにしたほうがいい。
https://bitbucket.org/multicoreware/x265/commits/all
- 636 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 17:33:04.26 ID:nlnTVFDP.net
- >>635
ｔｈｘ
（自分でビルドしないけど）ブクマしといた
- 637 ：名無しさん＠編集中：2015/12/26(土) 18:10:11.04 ID:PC8RPPww.net
- 自分用メモ
sandyで、昨日自ビルドしたx265とx264の初エンコテスト比較
x265とx264ともに8bit --preset slower --aq-mode 3 --no-psyで30分の720*480エロ動画
ffmpegでssimの計測
x265
13.38 fps, 263.65 kb/s
SSIM Y:0.885624 (9.416659) U:0.972000 (15.528396) V:0.963594 (14.388307) All:0.913015 (10.605566)
x264
70.87 fps, 604.44 kb/s
SSIM Y:0.979789 (16.944222) U:0.983586 (17.847748) V:0.978977 (16.773040) All:0.980287 (17.052421)
bitbucket見ると最初のコミットが2013-03-07だからがんばってるてことか
Yの落ち込みが大きいからYへのunsharpで多少は補正できそう
- 638 ：名無しさん＠編集中：2015/12/27(日) 16:03:00.15 ID:QPUC82p+.net
- また、「同じオプション指定で比較」するバカが住んでるのか。。。
- 639 ：名無しさん＠編集中：2015/12/27(日) 16:48:07.26 ID:AP5rfsnS.net
- サンプルが小さすぎるのもありそう
SDならxvidのq3ぐらいのほうが綺麗
- 640 ：名無しさん＠編集中：2015/12/27(日) 18:55:24.77 ID:1UDAOmVw.net
- ソースは640x480、41985フレームのアニメ、SSIMはffmpeg調べ。
Xvid q3
エンコ時間3分、1070kbps、SSIM Y:0.986353
x264 r2638kMod --crf 23
エンコ時間3分、532kbps、SSIM Y:0.985826
x264 r2638kMod --crf 21
エンコ時間3分25秒、719kbps、SSIM Y:0.988074
x265 1.8+188 --crf 21
エンコ時間14分23秒、411kbps、SSIM Y:0.985115
>>639
手元のソース１つで試した結果にすぎないし、SSIMだけで画質を語るつもりもないけど、
「SDならXvidの方が綺麗」と主張し続けてる人がどういう基準で「綺麗」だと言ってるのかよくわからん。
- 641 ：名無しさん＠編集中：2015/12/27(日) 19:38:15.28 ID:JuHwvd0v.net
- xvidが綺麗と思えばxvidを使えばいいんじゃない
- 642 ：名無しさん＠編集中：2015/12/27(日) 21:12:50.41 ID:AP5rfsnS.net
- >>640
たびたび書いてるのは自分だけどq値決め打ちじゃなく
画質に満足いくまでq値を下げるのが前提（画質を追求するなら結局q2.6ぐらいまで下げることになる
綺麗の定義は「グレンの潰れなさ具合」
たぶんでブロッキングフィルタとかディテールつぶしが無い分
素直にディテールが綺麗に残るんじゃないかと思ってる
（最後の行を書いてて思いましたけど実写での経験則）
早い話がビットをより多く使うから綺麗ってオチなわけだけど
グレンノイズの少ないソースじゃ違いは分からないかもね
- 643 ：名無しさん＠編集中：2015/12/28(月) 15:03:35.77 ID:AuSc0FjL.net
- ソース、640x480、3分、エロ動画
SSIMはffmpegで測定
x264 デフォ＋no-psy+aq-mode 3
SSIM Y:0.928542 (11.459472) U:0.985500 (18.386333) V:0.981752 (17.387954) All:0.946903 (12.749319)
encoded 5401 frames, 99.91 fps, 1097.19 kb/s
x265 デフォ＋no-psy+aq-mode 3+crf 28
SSIM Y:0.804027 (7.078027) U:0.973071 (15.697855) V:0.959527 (13.928366) All:0.858117 (8.480711)
encoded 5401 frames in 245.51s (22.00 fps), 255.90 kb/s, Avg QP:33.79
x265 デフォ＋no-psy+aq-mode 3+crf 27
SSIM Y:0.803084 (7.057188) U:0.973849 (15.825170) V:0.960736 (14.060104) All:0.857820 (8.471623)
encoded 5401 frames in 248.81s (21.71 fps), 374.87 kb/s, Avg QP:31.58
x265 デフォ＋no-psy+aq-mode 3+crf 26
SSIM Y:0.802878 (7.052659) U:0.974114 (15.869358) V:0.961091 (14.099513) All:0.857787 (8.470593)
encoded 5401 frames in 253.15s (21.34 fps), 433.19 kb/s, Avg QP:30.47
x265 デフォ＋no-psy+aq-mode 3+crf 25
SSIM Y:0.822244 (7.501752) U:0.976616 (16.310877) V:0.965200 (14.584195) All:0.871799 (8.921072)
encoded 5401 frames in 255.54s (21.14 fps), 503.93 kb/s, Avg QP:29.35
x265 デフォ＋no-psy+aq-mode 3+crf 24
SSIM Y:0.821997 (7.495718) U:0.976931 (16.369759) V:0.965568 (14.630388) All:0.871748 (8.919347)
encoded 5401 frames in 258.54s (20.89 fps), 589.12 kb/s, Avg QP:28.23
- 644 ：名無しさん＠編集中：2015/12/28(月) 15:04:48.96 ID:AuSc0FjL.net
- x265 デフォ＋no-psy+aq-mode 3+crf 23
SSIM Y:0.821710 (7.488735) U:0.977138 (16.408933) V:0.965787 (14.658129) All:0.871628 (8.915289)
encoded 5401 frames in 261.84s (20.63 fps), 693.45 kb/s, Avg QP:27.10
x265 デフォ＋no-psy+aq-mode 3+crf 22
SSIM Y:0.821424 (7.481768) U:0.977380 (16.454981) V:0.966083 (14.695766) All:0.871526 (8.911859)
encoded 5401 frames in 264.99s (20.38 fps), 819.56 kb/s, Avg QP:25.95
x265 デフォ＋no-psy+aq-mode 3+crf 21
SSIM Y:0.821099 (7.473879) U:0.977621 (16.501670) V:0.966309 (14.724900) All:0.871388 (8.907184)
encoded 5401 frames in 268.56s (20.11 fps), 972.80 kb/s, Avg QP:24.81
x265 デフォ＋no-psy+aq-mode 3+crf 20
SSIM Y:0.820743 (7.465236) U:0.977812 (16.538787) V:0.966536 (14.754276) All:0.871220 (8.901516)
encoded 5401 frames in 272.35s (19.83 fps), 1158.67 kb/s, Avg QP:23.67
x265 デフォ＋no-psy+aq-mode 3+crf 19
SSIM Y:0.820388 (7.456652) U:0.977981 (16.572001) V:0.966702 (14.775778) All:0.871039 (8.895425)
encoded 5401 frames in 276.62s (19.52 fps), 1380.33 kb/s, Avg QP:22.54
x265 デフォ＋no-psy+aq-mode 3+crf 18
SSIM Y:0.850120 (8.242556) U:0.981450 (17.316653) V:0.972696 (15.637714) All:0.892438 (9.683394)
encoded 5401 frames in 281.16s (19.21 fps), 1648.32 kb/s, Avg QP:21.43
- 645 ：名無しさん＠編集中：2015/12/28(月) 17:19:14.07 ID:AuSc0FjL.net
- 書き忘れ
636, 642, 643にはtune ssimをつけてある
書き忘れテスト, 2passは動かなかったから1pass
ソースは>>643, 643と同じ
x264 no-psy aq-mode 3 bitrate 300
SSIM Y:0.913324 (10.621006) U:0.980374 (17.071684) V:0.974576 (15.947585) All:0.934708 (11.851377)
encoded 5401 frames, 181.90 fps, 305.19 kb/s
x265 no-psy aq-mode 3 medium bitrate 300
SSIM Y:0.804045 (7.078432) U:0.973717 (15.803202) V:0.960709 (14.057068) All:0.858434 (8.490416)
encoded 5401 frames in 248.80s (21.71 fps), 294.75 kb/s, Avg QP:33.58
x265 no-psy aq-mode 3 slow bitrate 300
SSIM Y:0.804188 (7.081599) U:0.973960 (15.843551) V:0.960968 (14.085785) All:0.858613 (8.495908)
encoded 5401 frames in 381.43s (14.16 fps), 294.42 kb/s, Avg QP:33.35
x265 no-psy aq-mode 3 slower bitrate 300
SSIM Y:0.804009 (7.077635) U:0.974380 (15.914158) V:0.961492 (14.144482) All:0.858651 (8.497078)
encoded 5401 frames in 878.83s (6.15 fps), 293.76 kb/s, Avg QP:33.24
x265 no-psy aq-mode 3 veryslow bitrate 300
SSIM Y:0.804055 (7.078661) U:0.974246 (15.891494) V:0.961360 (14.129654) All:0.858638 (8.496666)
encoded 5401 frames in 1402.14s (3.85 fps), 293.52 kb/s, Avg QP:33.36
- 646 ：名無しさん＠編集中：2015/12/28(月) 17:53:58.02 ID:lN2S38Mz.net
- つまり今のところ
x264＞x265
ってこと？
- 647 ：名無しさん＠編集中：2015/12/28(月) 18:59:54.42 ID:dW745Ccp.net
- >>643-645
x265のSSIM:Yの数値が低すぎる。x265のSSIMを正しく測れてないと思うよ。
*.265のままソースと比較すると正しく測れないので、mp4にmuxしてから測る必要がある。
XvidのAVIもそのままだと正しく計測できないようだったので、
AVISource()で読み込んだavsを作ってそれをソースと比較した。
なんでうまく測れないのかはよくわかってないけど。
- 648 ：名無しさん＠編集中：2015/12/28(月) 19:36:33.28 ID:AuSc0FjL.net
- マジかよ
スクリプト書き直しか
たいした労力じゃないけど
- 649 ：名無しさん＠編集中：2015/12/28(月) 22:03:14.78 ID:Yj61mlND.net
- 数値による比較じゃなく実際に目で見て判断しないと・・
それとエロvdvぐらいならx264のcfr22ぐらいでやれば十分でしょ
- 650 ：名無しさん＠編集中：2015/12/28(月) 23:46:54.12 ID:UvY7E994.net
- ffmpegのSSIMフィルタはソースのfpsとエンコしたもののfpsがかなり正確に合ってないと正しく算出出来なかったと思う。
あと確かVP9なんかもAltRefフレーム使ってる関係上か知らないけど普通に読み込むとおかしくなるからAvisynth経由で読み込んでAssumeFPSとかしないと駄目。
- 651 ：649：2015/12/29(火) 00:37:10.31 ID:8IWJ8AGX.net
- VP9云々のやつ今試してみたらAvisynth経由しなくても普通に出来た。
ffmpegのバージョンが上がって修正されたのかも（？）よく分からないけど。
- 652 ：名無しさん＠編集中：2015/12/29(火) 09:35:31.46 ID:9A7QFVez.net
- 647
ホントだ
muxしたらssimが上がってた
muxによってはpts、 DTS、timestampで怒られた
ffmpegから直接265をいじるのが一番無難だった
ffmpegはlibのオプションをオバーライドすることあるから、やりたくなかったんだけど
>>649
まぁ、お遊びってことで
- 653 ：名無しさん＠編集中：2015/12/29(火) 17:30:38.12 ID:9A7QFVez.net
- あと、fmpegから直接265をいじったとき
265のpreset mediumだとfps40でた
y4mを直接265に読ませるとfps20
なんで？
- 654 ：名無しさん＠編集中：2015/12/29(火) 18:41:26.53 ID:wmua3h70.net
- 所詮ffmpeg、その程度ってことだろ。
- 655 ：名無しさん＠編集中：2015/12/29(火) 19:40:09.08 ID:hecsvuwY.net
- 目で見て判断とか
どれだけ自分の目に自信があったら言えるんだ
- 656 ：名無しさん＠編集中：2015/12/29(火) 19:48:01.97 ID:9A7QFVez.net
- >>654
ffmpegのほうが速いんですよ
年末にはまっちまた
- 657 ：名無しさん＠編集中：2015/12/29(火) 20:01:58.91 ID:wm1Lq+lC.net
- 目で見ずにどうやって画質評価するのか疑問
- 658 ：名無しさん＠編集中：2015/12/29(火) 20:40:58.71 ID:R7bcCv7T.net
- SSIMだって人間の感覚から乖離してるのにね
画質オタって自分の感覚に自信が持てないからか絶対的に見える数値評価を過信するよな
- 659 ：名無しさん＠編集中：2015/12/29(火) 21:04:13.88 ID:5PhTB4UX.net
- HEVC の利点って心理的効果も含めて、画質が「良く」見える事じゃないの?
SSIM はあくまでソースとの乖離性を数値化した物だから人間の目が判断する画質とは異なる。
最終的な判断は自分の目で見ることに違いないだろ
- 660 ：名無しさん＠編集中：2015/12/29(火) 21:10:09.82 ID:kA6WO2Bz.net
- 一番マシな数値指標がSSIMってだけで、参考程度にはするけど過信してる奴は別にいないだろ。
- 661 ：名無しさん＠編集中：2015/12/29(火) 21:26:30.90 ID:TzjPmFls.net
- 目も目で主観入ることもあるし数値化もある程度指標にはなるっしょ
散々そこらで書かれている通り過信しなきゃいいだけ
- 662 ：名無しさん＠編集中：2015/12/30(水) 00:57:27.86 ID:vwvyTCw8.net
- SSIMはいちいち画像貼らずに画質の比較が出来るから著作権的に安心なのがいいと思うのよな
あとグラフ書いたりも出来るし
- 663 ：名無しさん＠編集中：2015/12/30(水) 02:50:29.16 ID:0tUCtX9N.net
- エンコーダの性能を語る場において主観的な評価を用いることに意味があるのか？
画質の良さなんて人それぞれなんだから
そりゃどんな設定で使うかは自分で好きにすればいいけどさ
>>645みたいなレビューで主観的に語られてもちっとも参考にならないだろ
- 664 ：名無しさん＠編集中：2015/12/30(水) 09:18:02.01 ID:rUpbP8pC.net
- >>663
支離滅裂
大丈夫か？
- 665 ：名無しさん＠編集中：2015/12/30(水) 10:05:33.84 ID:0j3mn2aP.net
- >>663
頭悪いと大変だな…
- 666 ：名無しさん＠編集中：2015/12/30(水) 10:41:31.01 ID:iKvrKZHw.net
- 俺も>>663はいまいちよくわからない文章だと思ったが、
「>>645みたいな比較を行う場合は主観的評価（"これが綺麗な気がする"とか）じゃ
わけわからねーからSSIM使うしかないだろ」
と言いたいのかなと思った。
- 667 ：名無しさん＠編集中：2015/12/30(水) 10:48:13.38 ID:IZ86kZ2w.net
- 綺麗な気がするとかは意味ないしSSIM比較にも賛成なんだが、
どういう感じに画質劣化するとかレビューはあれば読みたい。
ソースの傾向とも関連するだろうし。
- 668 ：名無しさん＠編集中：2015/12/30(水) 12:23:46.55 ID:0tUCtX9N.net
- >>666
その通りだよ
文章を理解しようとしない人ばかりじゃなくて安心した
ここの人たちはとりあえず批判しておきたいんだろうね
ただ俺も伝わりにくい書き方をしたことは詫びておくよ
- 669 ：名無しさん＠編集中：2015/12/31(木) 11:52:46.61 ID:jlLBbrcv.net
- Performance Presets
http://x265.org/performance-presets/
- 670 ：名無しさん＠編集中：2015/12/31(木) 13:25:56.61 ID:1x/a9izS.net
- ほうlimit-refsをデフォで使うようになった感じ？
720p mediumならリアルタイムでエンコできる環境が増えそうだ
- 671 ：名無しさん＠編集中：2015/12/31(木) 18:06:45.58 ID:wSkFl2OB.net
- グラフ見る限りは魅力的だけど、新プリセットはどこにあるのかな
git見てもそんなのまだなさそうだが
- 672 ：名無しさん＠編集中：2015/12/31(木) 18:35:10.47 ID:xsxqdEld.net
- >>671
既存のプリセットの設定を調整したという話だと思うんだが・・・
- 673 ：名無しさん＠編集中：2015/12/31(木) 19:04:36.81 ID: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は使う予定無いので、未検証）
- 674 ：名無しさん＠編集中：2016/01/01(金) 02:18:30.24 ID:WmQnDSNu.net
- エラいスピードアップだな。
画質にダメージとかないんかね？
- 675 ：名無しさん＠編集中：2016/01/01(金) 03:09:19.16 ID:RD6MTGrq.net
- 1.8+188で適応されてるの？
- 676 ：名無しさん＠編集中：2016/01/01(金) 05:20:46.74 ID:O3DrfO55.net
- SSIMの話してたら公式がグラフに使っててワラタ
- 677 ：名無しさん＠編集中：2016/01/01(金) 07:49:50.36 ID:jXigYVvB.net
- あーpresetの件、多分、１２月２２日に導入されたこの変更のことだろうな
https://bitbucket.org/multicoreware/x265/commits/da48f2690076bc1bc72b1cbf62347e40e30debce
各プリセットのパラメータを微調整したうえに、最近導入されたlimit-refs、limit-modesも加えたと。
最新ソースを使ってビルドしてるなら、もう１周間前に導入されてたということね。
- 678 ：名無しさん＠編集中：2016/01/01(金) 09:45:09.31 ID:0amdltZA.net
- 12/23のx265guiEx 3.66v2でプリセット変更への対処が入ってたしな。
1.8+2と1.8+188とで、手元のソースをプリセット指定だけでエンコした結果を比べてみたら
・エンコード速度は全体的に向上。
・ultrafast～fasterでは従来よりSSIM値が小さくなり、ビットレートも大幅に低くなった。
・fast～slowerではSSIM値は従来と同じくらいだが、ビットレートがやや高くなった。
という結果になった。veryslowとplaceboは時間がかかるので試していない。
詳細→ http://pastebin.com/qTfmuANu
- 679 ：名無しさん＠編集中：2016/01/01(金) 11:14:31.16 ID:xC692RGG.net
- すいません、質問です。
x265のソースコードを自分でビルドして使用しているのですが
バイナリのバージョンが不明なんです。これってコード追記しないといけないのでしょうか？
変な質問だったらスルーしてください。
- 680 ：名無しさん＠編集中：2016/01/01(金) 15:09:29.20 ID:jXigYVvB.net
- x265.exe --version
とコマンド打てば表示されるよ
- 681 ：名無しさん＠編集中：2016/01/01(金) 15:29:05.52 ID: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
こんな感じです。
- 682 ：名無しさん＠編集中：2016/01/01(金) 15:29:40.58 ID:nwqCpAdi.net
- >>679
ソース下のbuild/README.txtにも書かれてる事(「= Version number considerations =」を参照)だけど、
X265_VERSION はcmake実行時にMercurial(hgコマンド)を使用して設定、ないと"unknown"になる。
Mercurial(hg)のパスを環境変数PATHに追加してからcmakeを実行する。
- 683 ：名無しさん＠編集中：2016/01/01(金) 15:39:01.12 ID:xC692RGG.net
- >>682
ありがとうございます。
- 684 ：名無しさん＠編集中：2016/01/01(金) 17:27:43.84 ID:jXigYVvB.net
- Rigayaさんのとこのx265エンコ速度測定記事、プリセット変更直前に書かれてるのがおしい
- 685 ：名無しさん＠編集中：2016/01/01(金) 17:32:56.40 ID:xC692RGG.net
- なんでおかしいの？
rigaya氏が変更を事前に知っていて、わざと記事にしたとでもいうの？
- 686 ：名無しさん＠編集中：2016/01/01(金) 17:34:04.38 ID:k8j4Ysr1.net
- >>685
落ち着いて>>684を読み直してみろ
- 687 ：名無しさん＠編集中：2016/01/01(金) 17:39:27.38 ID:jXigYVvB.net
- >>685
うん。君はおかしい
はい次の人ー
- 688 ：名無しさん＠編集中：2016/01/01(金) 17:43:45.36 ID:xC692RGG.net
- m(__)m
- 689 ：名無しさん＠編集中：2016/01/01(金) 20:28:21.76 ID:FNsjlYzw.net
- ところでさ、現時点のx265はUltra HD BDの規格に準拠した形でのエンコードはできるんだろうか？
それともまだ何か未対応のオプションがあったりして、規格準拠とまではいかないのだろうか？
x265の進捗状況がよくわからないんだけど。
- 690 ：名無しさん＠編集中：2016/01/02(土) 21:42:43.73 ID:uM4JuYJD.net
- どうしても暗部保持ができなくてバンディングになっちゃう
おもいっきりビットレート上げればなんとかなるけど
一話23分半のアニメで3Gくらいの容量になるからさすがに割りに合わない
- 691 ：名無しさん＠編集中：2016/01/03(日) 06:14:00.23 ID:TB5sGS/t.net
- バンディング消す方法なんていくらでもあるでしょー
基本は10bitエンコだし、
バンディング低減するフィルタだって複数あるよ
x264よりも遥かにバンディング出ないx265で悩んでる人はじめて見た
- 692 ：名無しさん＠編集中：2016/01/03(日) 09:29:55.61 ID:+7iHH5QT.net
- バンディングて色調整するとワラワラ出てくることあるね
- 693 ：名無しさん＠編集中：2016/01/03(日) 12:06:06.62 ID:KftKtXND.net
- >>691
x264の10bitの方が明らかにバンディング出ないから悩んでるんだけど
エンコ速度的には十分だと思うし、その問題さえ解消するようならx265に移行するのもいいかなって思ってるけど
>485の頃からまだこういうところは調整されてないのかな？
- 694 ：名無しさん＠編集中：2016/01/03(日) 12:17:20.68 ID:aIpwUsLj.net
- どちらかというとAQで暗部は削られるものだと思うけど・・
- 695 ：名無しさん＠編集中：2016/01/03(日) 13:57:04.40 ID:CBJBsL1D.net
- 糞なのはx265のPsyだろうねぇ
- 696 ：名無しさん＠編集中：2016/01/03(日) 22:11:59.73 ID:V82V0kUc.net
- 下手くそ
- 697 ：名無しさん＠編集中：2016/01/05(火) 23:20:08.23 ID:wK8tZoI/.net
- ん？またプリセット変わったか
- 698 ：名無しさん＠編集中：2016/01/06(水) 21:50:42.37 ID:/8vK25uX.net
- https://bitbucket.org/multicoreware/x265/commits/a6577bee0b71768fcd5c3262b597411d17037afc
Merge with default, prep for 1.9
もうすぐ1.9が来そう
- 699 ：名無しさん＠編集中：2016/01/10(日) 08:23:42.64 ID:Hd4RBeuI.net
- x265 1.8+205 -d94f6c2b45f8
ttp://www1.axfc.net/u/3597706
- 700 ：名無しさん＠編集中：2016/01/10(日) 14:30:01.33 ID:m9YtAxYc.net
- x64じゃないのかな
- 701 ：名無しさん＠編集中：2016/01/10(日) 14:32:48.05 ID:m9YtAxYc.net
- なんかエラーで落ちる
- 702 ：名無しさん＠編集中：2016/01/10(日) 14:47:46.35 ID:Hd4RBeuI.net
- >>701
マジすか？
ちょっと調べてみます。
>>700
64bit専用です。
- 703 ：名無しさん＠編集中：2016/01/10(日) 14:59:37.89 ID:m9YtAxYc.net
- 普段ここの使ってるんだけど
https://builds.x265.eu/
ここのも1/8のものからエラーで落ちるようになってる
1/7の1.8+201のものはエラー出ない
自分の環境かもしれないし何が何だか分かってないけど
問題解決されると嬉しい
- 704 ：名無しさん＠編集中：2016/01/10(日) 15:10:43.28 ID:Hd4RBeuI.net
- これはどうでしょうか？
ttp://www1.axfc.net/u/3597860
- 705 ：名無しさん＠編集中：2016/01/10(日) 15:42:21.06 ID:m9YtAxYc.net
- ありがとう
でも同じだった
イベントビューアにはこんな感じで上がってる
障害が発生しているアプリケーション名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
障害が発生しているモジュール名: x265.exe、バージョン: 0.0.0.0、タイム スタンプ: 0x56919c0b
例外コード: 0xc0000005
障害オフセット: 0x0000000000790522
- 706 ：名無しさん＠編集中：2016/01/10(日) 16:05:38.87 ID:Hd4RBeuI.net
- うーん・・・
コマンドラインオプション無しでもエラー出ますか？
- 707 ：名無しさん＠編集中：2016/01/10(日) 16:09:39.28 ID:m9YtAxYc.net
- それだと出ないね
俺のオプションがダメっぽいのか…
どのオプションだろ
削りながら試してみるよ
ありがと
- 708 ：名無しさん＠編集中：2016/01/10(日) 16:12:07.50 ID:Hd4RBeuI.net
- メモリーアクセス違反か。
自分の環境では出ないんですよね。
OSはなんですか？
- 709 ：名無しさん＠編集中：2016/01/10(日) 16:15:17.26 ID:Hd4RBeuI.net
- AVX、AVX2、FMA3を潰してみるとか。
- 710 ：名無しさん＠編集中：2016/01/10(日) 16:16:06.57 ID:m9YtAxYc.net
- --no-deblock
このオプション抜いたらエラー出なくなった
これは自分の環境が悪いとかじゃないよね…
- 711 ：名無しさん＠編集中：2016/01/10(日) 16:23:36.91 ID:Hd4RBeuI.net
- ありがとうございます。
そちらの問題ではなく、コードに問題有りかもです。
- 712 ：名無しさん＠編集中：2016/01/10(日) 16:53:54.29 ID:V/aHiJAl.net
- 斧に上がったバイナリなんてよく実行できるな・・・
- 713 ：名無しさん＠編集中：2016/01/10(日) 17:47:40.97 ID:m9YtAxYc.net
- どうやってバグの情報としてあげればいいのか分からないや
早く気付いて欲しいなぁ
- 714 ：名無しさん＠編集中：2016/01/10(日) 20:26:32.56 ID:PlpsG+IN.net
- >>713
bitbucketの課題にでも投げれば良いんじゃないの？
https://bitbucket.org/multicoreware/x265/issues
- 715 ：名無しさん＠編集中：2016/01/11(月) 04:08:04.43 ID:NFAme+dx.net
- 205で更にエンコ速度上がってるな
- 716 ：名無しさん＠編集中：2016/01/11(月) 18:42:34.02 ID:8MzzuCE7.net
- 今は209だぜー
- 717 ：名無しさん＠編集中：2016/01/11(月) 22:48:39.09 ID:iLbQXuHs.net
- ここ最近開発が活発化してる
いいねえ
- 718 ：名無しさん＠編集中：2016/01/12(火) 03:22:31.26 ID:ay8VbQDJ.net
- x265-1.8+210_19cfada71621
ttp://www1.axfc.net/u/3599204
- 719 ：名無しさん＠編集中：2016/01/12(火) 06:40:40.41 ID:FuFhTotB.net
- 久々にビルドしてみたけど
デフォ設定で1.4と比べたら2倍くらいエンコ速くなってんな
- 720 ：名無しさん＠編集中：2016/01/12(火) 07:22:48.18 ID:UGxx9q6x.net
- 密かにpsy-rdのデフォ値も変わったで
- 721 ：名無しさん＠編集中：2016/01/12(火) 08:45:59.11 ID:FuFhTotB.net
- ホントだ
1.0から0.6になっとるな
ちょこちょこ設定変えてんだな
- 722 ：名無しさん＠編集中：2016/01/12(火) 09:56:13.90 ID:ZF6tU8kF.net
- なかなか1.9にならんな
- 723 ：名無しさん＠編集中：2016/01/12(火) 10:09:53.76 ID:xb1b+Mb+.net
- >>721
旧： 値範囲0～2.0 デフォルト値0.3
新： 値範囲0～5.0 デフォルト値2.0
じゃね。
- 724 ：名無しさん＠編集中：2016/01/12(火) 11:20:34.90 ID:FuFhTotB.net
- strengthだった
- 725 ：名無しさん＠編集中：2016/01/12(火) 14:33:21.76 ID:ckdTaHsh.net
- H265 codecs comparison from MSU
http://x265.ru/en/bolshoe-sravnenie-kodekov-h265-ot-mgu/
- 726 ：名無しさん＠編集中：2016/01/12(火) 14:48:48.67 ID:J/v6lK/H.net
- URLが怪しすぎる…
- 727 ：名無しさん＠編集中：2016/01/12(火) 15:14:52.56 ID:UGxx9q6x.net
- そこは、ちょっと前までx265バイナリの配布定番サイトだったんだけど、
multicorewareとトラブって配布禁じられたサイト
- 728 ：名無しさん＠編集中：2016/01/12(火) 15:33:28.98 ID:xb1b+Mb+.net
- >>727
トラブったという話の情報源はどこ？
本当ならテンプレからも外さないといかんよね。
- 729 ：名無しさん＠編集中：2016/01/12(火) 16:02:11.85 ID:ay8VbQDJ.net
- multicoreware-x265-6ccd503a4c3a
ttp://www1.axfc.net/u/3599390
- 730 ：名無しさん＠編集中：2016/01/12(火) 16:07:54.77 ID:ZF6tU8kF.net
- ウィルスとかの問題じゃないから問題なし
x264は良かったとか書くあたりライセンスとかそのへんの理由
- 731 ：名無しさん＠編集中：2016/01/12(火) 21:07:29.03 ID:UGxx9q6x.net
- >>728
multicorewareがある日突然、他サイトでのバイナリ配布を禁じたんだよ
http://x265.ru/enはバイナリ配布の最大手だったけど、一夜にして配布停止に追い込まれた
- 732 ：名無しさん＠編集中：2016/01/12(火) 22:21:22.09 ID:vk6wUU7N.net
- >>710
https://bitbucket.org/multicoreware/x265/issues/225/outputs-are-inconsistent-with-sao-caused
微妙に症状は違うっぽいけど、--no-deblock付けてエラーになる事が解決されてるから、
多分、直ったっぽいよ。
- 733 ：名無しさん＠編集中：2016/01/13(水) 00:04:51.69 ID:i5ptavi1.net
- 717のバイナリはバグっているので使わないほうがいい。
728は今のところ大丈夫。
- 734 ：名無しさん＠編集中：2016/01/13(水) 00:35:17.31 ID:7rxsXKJd.net
- そもそも他人ビルドで署名が無い物なんて使うわけ無いですし
- 735 ：名無しさん＠編集中：2016/01/13(水) 14:58:50.31 ID:wOrVT6++.net
- そうですか
- 736 ：名無しさん＠編集中：2016/01/14(木) 16:51:17.94 ID:AaOlEqVU.net
- >>732
1.8+211で試してみたけどまだ直ってないみたい…orz
でも気長に待ってみる
- 737 ：名無しさん＠編集中：2016/01/15(金) 06:50:52.92 ID:psKZUe1A.net
- x265-792f6ead9c50
ttp://www1.axfc.net/u/3601075
- 738 ：名無しさん＠編集中：2016/01/17(日) 10:34:19.47 ID:M6mbumiP.net
- H.265はH.264の半分のビットレートで同等画質を実現するのが実証される - GIGAZINE
http://gigazine.net/news/20160117-h265-quality-testing/
- 739 ：名無しさん＠編集中：2016/01/17(日) 10:49:26.43 ID:D60EYyZP.net
- >>738
これx264とx265でPSNR調べてもここまで差が出ないんだけど使ってるエンコーダーが違うのかね
- 740 ：名無しさん＠編集中：2016/01/17(日) 12:09:44.29 ID:Pifl9Opi.net
- JVとかいうリファレンスのコーデックでの比較なんじゃね
- 741 ：名無しさん＠編集中：2016/01/17(日) 12:11:58.73 ID:D60EYyZP.net
- JMとHMって書いてあったわ
- 742 ：名無しさん＠編集中：2016/01/17(日) 13:48:03.23 ID:XmqoO05B.net
- >>738
ADSL回線でピアキャスとかで配信するときに重宝する＞H.265
- 743 ：名無しさん＠編集中：2016/01/17(日) 23:50:56.36 ID:Tbz8Tr7+.net
- ADSLはプランによっては1000kbps上限だからねぇ
- 744 ：名無しさん＠編集中：2016/01/29(金) 21:07:28.93 ID:DKTs/nc/.net
- New 1.9 version of x265
http://x265.ru/en/x265-v-1-9/
x265 version 1.9 has now been released.
This release supports many new features as well as additional assembly optimizations for Main12, intra prediction and SAO.
Recently added features lookahead-slices, limit-refs and limit-modes have been enabled by default in the supported presets.
- 745 ：名無しさん＠編集中：2016/01/30(土) 01:25:28.25 ID:Wakff49R.net
- 1.9来たね！
- 746 ：名無しさん＠編集中：2016/01/30(土) 01:26:18.86 ID:+Hb0depP.net
- 始まる前から終わってるx265
- 747 ：名無しさん＠編集中：2016/01/30(土) 01:28:24.65 ID:pHFV68mi.net
- 今ビルドちゅう
- 748 ：名無しさん＠編集中：2016/01/31(日) 00:22:07.01 ID:oQyeXKXJ.net
- 適当にベンチ 詳細はテキストに
ソース https://media.xiph.org/video/derf/y4m/station2_1080p25.y4m
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)
http://www.dotup.org/uploda/www.dotup.org718947.txt
- 749 ：名無しさん＠編集中：2016/01/31(日) 01:35:17.36 ID:cgqklV4a.net
- >>748
slow slowerの高速化がすごい
- 750 ：名無しさん＠編集中：2016/01/31(日) 02:31:21.15 ID:UHx+fRoe.net
- ああ、俺もベンチするスクリプトを Ruby で書いてみたりしてたけど
最近やってなかったな。。。で久々にやってみたたら比較対象が 1.6 の medium しかなかったｗ
http://i.imgur.com/WiicPsw.png
- 751 ：名無しさん＠編集中：2016/01/31(日) 13:41:59.34 ID:txIOJs0s.net
- >>748
slowerがビットレート下がりすぎてSSIMもそれに引き摺られちゃってるね
でも倍も速度でてる
- 752 ：名無しさん＠編集中：2016/01/31(日) 16:07:20.48 ID:cFXQSVbu.net
- プリセット内容が変わったんじゃなかった？
- 753 ：名無しさん＠編集中：2016/01/31(日) 18:33:49.97 ID:tisPGxzA.net
- >>752
たしかあったな…
- 754 ：名無しさん＠編集中：2016/01/31(日) 18:53:54.26 ID:TP98Z0n+.net
- たしかにプリセット変更で旧プリセットと同じビットレートでのSSIM落ちたけどちょっとしか落ちてないしその分早くなってるからいいや
あとveryfastなんかだと速度も上がってSSIMも上がってたりする。
- 755 ：名無しさん＠編集中：2016/01/31(日) 20:01:42.34 ID:FzlptxAC.net
- x265は今後もCPUのみの演算で貫くのかね？
GPUのメモリーがHBMやHBM2の導入でかなり速くなるし、バス速度や演算能力そのものも上がろうとしているわけだが、
相変わらず一部だけでもGPUに振り分けるよりCPUのみのほうがいいのかね？
- 756 ：名無しさん＠編集中：2016/01/31(日) 20:07:08.49 ID:cFXQSVbu.net
- x265の開発元が新しいコンパイラHCCの開発をするみたいだから
ヘテロジニアス対応は案外、早いかもしれない
- 757 ：名無しさん＠編集中：2016/01/31(日) 20:24:55.92 ID:o77Jhxsk.net
- >>755
PCIeの遅さが何とかなれば、じゃないかな
NVIDIAのNVLinkは一般PC環境では期待できないみたいだし
AMDもなんか高速バスかなんかやっているみたいだけど普及するかわからない
- 758 ：754：2016/02/02(火) 13:26:49.31 ID:NCVy8Op8.net
- >>756-757
HBM2がメインストリームのCPUやAPUに採用される日
http://pc.watch.impress.co.jp/docs/column/kaigai/20160202_741748.html
この記事によるとHBM2がコストダウンすれば一般向けのPC環境でも利用できるようになる可能性はあるようだから、あとはコストとバス速度の問題がなんとかなればいいのかも。
いつまでもCPUオンリーって時代でもないだろうし。
- 759 ：名無しさん＠編集中：2016/02/02(火) 14:53:24.44 ID:oWE9M/3S.net
- >>758
HBMは容量と帯域ばかりの記事が多かったけどレイテンシも低いんだな
じゃないとグラボ向けに積まれないか
- 760 ：名無しさん＠編集中：2016/02/02(火) 19:03:54.47 ID:NCVy8Op8.net
- GPUって大抵2スロット専有するんだから、PCI-Exスロットも2スロット挿しにして2倍速いってなわけにはいかないのかなと妄想。
- 761 ：名無しさん＠編集中：2016/02/03(水) 15:02:46.32 ID:juHubKYm.net
- >>760
っ [SLI]
- 762 ：名無しさん＠編集中：2016/02/03(水) 17:41:33.40 ID:+OWBi5Bj.net
- Android版とかiOS版のx265なんて出ないものなのかね？
- 763 ：名無しさん＠編集中：2016/02/03(水) 18:20:21.38 ID:63ziqI0j.net
- バッテリで動く端末との相性は最悪だろ
- 764 ：名無しさん＠編集中：2016/02/03(水) 18:34:18.04 ID:+OWBi5Bj.net
- >>763
なんで？
ちょこっとしたビデオクリップを編集後にエンコードまで出来たら、外出先で重宝しそうなものだが。
USB給電がこれだけ普及し、iPad proみたいなのまで出てくると、エンコードくらい多少時間がかかってもモバイル機器でできたほうが消費電力的にもうれしいわけだが。
- 765 ：名無しさん＠編集中：2016/02/03(水) 18:36:25.29 ID:xdk3hERs.net
- ちょっと何言ってるか分かんない
- 766 ：名無しさん＠編集中：2016/02/03(水) 18:38:36.07 ID:iehiN48C.net
- x265はともかくカメラの画像をエンコードしてるチップにデータ送ってエンコードできたらなどと思うことはあるw
- 767 ：名無しさん＠編集中：2016/02/03(水) 20:06:23.57 ID:stWNn/Ef.net
- 最近リリースされたx265どう？
良ければコンパイルし直そうかと思ってる
- 768 ：名無しさん＠編集中：2016/02/03(水) 20:30:41.98 ID:3wA6RKbD.net
- たかがビルドで人に聞かないと動けないって・・・
- 769 ：名無しさん＠編集中：2016/02/03(水) 21:05:22.98 ID:yXDm8y7+.net
- rigaya 氏の multilib ビルドバッチでビルドは楽させて頂いているｗｗ
ありゃ楽だ
- 770 ：名無しさん＠編集中：2016/02/04(木) 09:38:26.30 ID:T7nDHZT/.net
- >>764
その時間かかるって何日かかるんだ
モバイル用の非力CPUでのソフトエンコで
専用チップのエンコードならともかく
- 771 ：名無しさん＠編集中：2016/02/04(木) 11:37:30.45 ID:+3HectuX.net
- 朝鮮人に句点は難しい。
- 772 ：名無しさん＠編集中：2016/02/04(木) 14:41:30.65 ID:J/9ovht0.net
- 実際どのくらい差あるのかな？
i5 6600とsnapdragon801で50倍差くらい？
- 773 ：名無しさん＠編集中：2016/02/04(木) 14:50:52.72 ID:+3HectuX.net
- 一部でもハードウェアの支援機能が使えればだいぶと話は変わるだろうね。
こんな記事もあるわけだし。
・ iPad Proは本当に4Kビデオ編集に使えるのか!? ガチ検証
http://av.watch.impress.co.jp/docs/series/zooma/20160203_741889.html
- 774 ：名無しさん＠編集中：2016/02/04(木) 22:37:23.84 ID:M4vC7LHq.net
- ffmpegでx265のハードウェアエンコードってもうサポートされてる？
QSVでできるとありがたい＞IvyBridge使いとしては
- 775 ：名無しさん＠編集中：2016/02/04(木) 22:57:03.08 ID:T7nDHZT/.net
- ？
- 776 ：名無しさん＠編集中：2016/02/05(金) 07:51:11.13 ID:NlSCducd.net
- x265はソフトエンコのためのソフトだ
ハードウェアエンコなどサポートされるわけがない
h.265(規格名 HEVC)とx265(ソフト名)の区別がついてないんだろうけど
QSVは固定回路
後からHEVC対応などできん
QSVでHEVC対応したのはSkylakeから
QSVでHEVC使いたいならSkylakeに買い換え
- 777 ：名無しさん＠編集中：2016/02/05(金) 12:12:20.92 ID:35jGb+Wd.net
- QSVは完全固定じゃないけどな。
- 778 ：名無しさん＠編集中：2016/02/05(金) 13:03:43.84 ID:LD2LJSnr.net
- コマンドラインからQSV使いたいんだろう。
まあH.265のスレに行くといい。
- 779 ：名無しさん＠編集中：2016/02/05(金) 13:40:15.88 ID:nrq1jwhr.net
- さらにソフトが対応しなきゃならんし
無知のドヤ顔知ったかはほんとどうにもならんといつも思う
- 780 ：名無しさん＠編集中：2016/02/05(金) 22:18:13.16 ID:cHw5jbd1.net
- >>776
Oh。。。そういうことなのね
しらんかったわ
H.264のハードウェアエンコで悦ってくるわﾉｼ
- 781 ：名無しさん＠編集中：2016/02/17(水) 00:08:44.49 ID:q2blbE92.net
- ↓こちらの動画配信解説サイトを参考に
http://pecardy.vanu.jp/?%C0%DF%C4%EA%2FMKV%C7%DB%BF%AE
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
- 782 ：名無しさん＠編集中：2016/02/17(水) 00:24:39.26 ID:ctq6s7UU.net
- ffmpeg も HandBrake もそうだけど、libx265 使うとそういう傾向になるみたいだね。
このスレの話しに紐付けるなら x265 で HEVC エンコしてみたらどうだろう。
ffmpeg で demux して動画部分を x265、音声部分を neroaac なりかまして
最後 remuxer 通すなり mp4box で mux すれば良い。
- 783 ：名無しさん＠編集中：2016/02/17(水) 00:52:00.93 ID:LHOUYy6V.net
- >>781
x265のfastとx264のveryslowだしなあ…
もう大分前のデータだしプリセット変更入ったからそこまで参考にはならないけど、
この辺のグラフ見れば必ずしもビットレート半分で同等の画質にはならないのが分かるはず。
>>302
>>365
>>381
>>406
- 784 ：名無しさん＠編集中：2016/02/17(水) 13:59:46.42 ID:SngcRS/c.net
- >>781
-tune zerolatency これやめたらどう？
- 785 ：名無しさん＠編集中：2016/02/17(水) 14:39:11.08 ID:UvZou3Zff
- ビットレート半分で同等の画質っていう謳い文句はx265のエンコード時間を度外視してx264と比較した場合の話でしょ
x265は複雑でx264で出来なかったような処理をする分時間が掛かるけどビットレートは少なくて済むってだけの話
x265の処理を簡単にしてx264と同じような速度でエンコードさせたら縮まないのは当然だと思う
- 786 ：名無しさん＠編集中：2016/02/17(水) 20:30:34.56 ID: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 -
- 787 ：780：2016/02/18(木) 00:12:09.35 ID:EKbwhu+3.net
- 皆さんアドバイスありがとうございますm(_ _)m
presetのfast/veryslowとか結構違いが効いてきそうですね。
slowにしてみたところ画質がだいぶ向上した気がします。
ただ負荷が高いのかエンコ配信中は画面がカクカクしてしまいましたが。
mediumくらいで折り合いを付けようかと思います。
> -tune zerolatency
このオプションは音ずれ防止用に入れました。
画質となにか関係ありますか？
> 主観だと画質が分かりにくいのでSSIMとPSNRを参考にしてオプションを弄れば良い
SSIM・PSNRは始めて聞きました。
x265から加わったオプションでしょうか。
画質に影響するオプションの用なのでちょっと調べてみようと思います。
あと>>781のx265オプションで配信テストをしていたところ、Windows10付属のWMPでは
画面が灰色になって再生できなかったけどVLC Media Playerでは正常に再生できたという
報告がありました。
- 788 ：名無しさん＠編集中：2016/02/18(木) 00:21:20.69 ID:bnH8mLRR.net
- 言っておくけどSSIMやPSNRはあくまで「数字の上での正確性」だから、それだけを鵜呑みにしないように
個人的にはオプションよりビットレートをもっと盛るのを最初にするべきかと
-b:v 518kぐらいでやってみては？
（もっともx264ので画質・容量的に満足できるならx264でいいと思うけど）
- 789 ：名無しさん＠編集中：2016/02/18(木) 01:05:06.98 ID:hHEKfc2c.net
- >>787
>> -tune zerolatency
>このオプションは音ずれ防止用に入れました。
音ズレ防止にはならない。配信のラグを軽減するだけ
>画質となにか関係ありますか？
zerolatency no lookahead, no B frames, no cutree
( http://x265.readthedocs.org/en/default/presets.html )
私はすごく関係あると思うんですが。
- 790 ：名無しさん＠編集中：2016/02/18(木) 09:11:42.49 ID:Z9lL4Edt.net
- やっぱ配信用設定はBフレーム削っちゃうんだね
NVENCのHEVCみたいだ
- 791 ：名無しさん＠編集中：2016/02/18(木) 11:06:46.21 ID:nlO5v3H8L
- >>787
配信中カクカクするのは当然
お察しの通り負荷が高いから
要するにそれは配信する映像のフレームレートにエンコードのスピードが追いついていない
例えば30fpsの映像を配信しようとしてもエンコードできる速度が10フレーム/秒とかだったら20フレーム足りないわけで当然止まる(それかどんどん遅れていく)
PSNRもSSIMもx264の時代からある
ようするにエンコード前の元動画と比較してどれくらい差が出たかっていうのを数値化して表現するもの(テストの採点みたいな感じ)
しかし機械的に判断した上での数値だから実際の目で見たときに数値ほど綺麗 or 綺麗じゃないということも起こりうる
Bフレーム由来の音ズレ(確か数フレーム音が遅れる)現象はx264の時代からあるはずだけどぶっちゃけ見てて気になるほどではないはず
しかもBフレームを使わないとなると圧縮率は結構下がるから必要なビットレートは多くなってしまう
長くなったけど正直配信用途なら大人しくx264使って配信したほうが良いと思う
現状x264と比較してx265は遅すぎる上に視聴者側にコーデックの導入してもらわないとそもそも見えない場合もある
x264並みに速くしてしまったら結局x265の旨みである「低ビットレートでも高画質」ってのは実現しにくくなると思う
- 792 ：名無しさん＠編集中：2016/02/18(木) 17:44:58.53 ID: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を使えば簡単に分かるわけだ
- 793 ：名無しさん＠編集中：2016/02/18(木) 18:13:49.28 ID:xYEflaB1.net
- ちなみにどの数値を見れば良いのかと言うとSSIMはAllの数値、PSNRはaverageの数値を見て比較してくれ
あとテスト用の動画はmp4じゃなくてもmkvでもtsでも何でも良い
- 794 ：名無しさん＠編集中：2016/02/19(金) 18:44:02.46 ID: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 https://bitbucket.org/multicoreware/x265
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 https://bitbucket.org/multicoreware/x265
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 https://bitbucket.org/multicoreware/x265
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
- 795 ：名無しさん＠編集中：2016/02/19(金) 18:46:36.53 ID:4YDtVCyu.net
- 書き忘れ
ffmpegで使うときは、output-depthじゃなく
-pix_fmt yuv420p10le
-pix_fmt yuv420p12le
で指定
- 796 ：780：2016/02/19(金) 22:23:59.21 ID:pxdW5hFs.net
- >>792
ありがとうございます。
早速SSIM/PSNRの数値を調べてみました。
たしかに皆さんがおっしゃるとおりzerolatencyを付けない方が
SSIM/PSNRの数値は上でした。
しかし今まで画質の善し悪しは主観的に判断するしか無いと思っていましたが
こうやって数値で確認する事もできるんですね。
いろいろパラメーターを変えつつSSIM/PSNRの数値を見て最適なポイントを
探してみようと思いますm(_ _)m
- 797 ：名無しさん＠編集中：2016/02/19(金) 23:27:22.99 ID:9715NWZX.net
- 指標は便宜上使われてるだけで基本は主観で判断だと思うよ
コンピューターが許容できる違いと人間が許容できる違いは同じではないからね
- 798 ：名無しさん＠編集中：2016/02/19(金) 23:40:15.58 ID:qSH2klIW.net
- あと多分-tune ssim付けて比較しないと意味ない
- 799 ：名無しさん＠編集中：2016/02/20(土) 10:10:44.80 ID:YhMIaURA.net
- 主観で判断なんてほぼ無理だろう
これができるならそれで飯が食べられる
まぁ、どこで妥協するかだろう
- 800 ：名無しさん＠編集中：2016/02/20(土) 11:04:23.50 ID:K6y5yssU.net
- あくまで指標
数値で画質が決まるならx264（例として）でpsnrやssimなんてtune作る必要がないからね
- 801 ：名無しさん＠編集中：2016/02/20(土) 11:37:36.59 ID:k+agU2Eu.net
- 主観で判断出来ないなんて可哀想な人
- 802 ：名無しさん＠編集中：2016/02/20(土) 11:49:29.89 ID:YhMIaURA.net
- よっぽど悔しかったのかな
公式でも使われて、急にダンマリしちゃった人がいたな
- 803 ：名無しさん＠編集中：2016/02/20(土) 11:54:48.37 ID:sO+hYrhk.net
- 自分の場合は最初に目で見て、これビットレート半分で画質同等って大げさじゃね？と思ってSSIM調べたらその通りだったって話だから順序逆なんだよな
- 804 ：名無しさん＠編集中：2016/02/20(土) 12:06:07.01 ID:SpT3cwNh.net
- 極端な話見ている人にバレなければ元と全然別物でも問題無い
- 805 ：名無しさん＠編集中：2016/02/20(土) 12:22:21.53 ID:K6y5yssU.net
- 基本は、「見てる人=自分だから」好きなようにとしか言いようがない
だけどわざわざ--tune psnrやらssim使って本番エンコする奇特な人もいるんだなと不思議に思ってる
- 806 ：名無しさん＠編集中：2016/02/20(土) 13:55:57.50 ID:EIhIWuJR.net
- 本番エンコで使うなんて誰も言ってないような・・・
- 807 ：名無しさん＠編集中：2016/02/20(土) 14:49:46.80 ID:K6y5yssU.net
- たしかに・・
「最後は主観」を否定する人かと思って短絡的に書いたは
- 808 ：名無しさん＠編集中：2016/02/20(土) 16:02:15.78 ID:BHDZ19yf.net
- -tune psnrとssimは心理視覚を向上させるオプションを無効になり主観的な画質が悪くなるので使わない方が良いみたい
心理視覚と言うのは例えば人間の目で見て画質の違いが分かりにくい部分の画質を悪くして違いが分かりやすい部分の画質を良くすることで
同じビットレートでも主観的な画質が良くなるみたい。だけどSSIMとかPSNRは画質の違いが分かるので数値が低くなるようだ。
- 809 ：名無しさん＠編集中：2016/02/26(金) 10:29:06.48 ID:i7aFZYs7.net
- ssimでだいたい当たりを付けて、psy関連で仕上げじゃないのか？
x264もx265もかなり練り上げられてるから、俺にはssim無しの判断は無理だわ
ssimの0.001の違いなんて目で区別できん
シーンごとに同一フレーム拡大確認なんてなおさら
最後は主観で判断と言うより、好み次第じゃない？
- 810 ：名無しさん＠編集中：2016/02/26(金) 10:59:27.59 ID:iu0kmo+a.net
- それを主観で判断すると言うんじゃ
- 811 ：名無しさん＠編集中：2016/02/26(金) 12:24:00.84 ID:ykLbS11Bg
- 自分の場合SSIMは0.98あたりにもなると主観で元の動画との区別が付かない画質になるからそれを基準にしてる
- 812 ：名無しさん＠編集中：2016/02/26(金) 16:24:08.79 ID:i7aFZYs7.net
- そうなのか
なら、語る余地無しだな
てっきりssimに頼らず目視でエンコ精度を判断してるのかと思った
12bitの効果はどう？
- 813 ：名無しさん＠編集中：2016/02/26(金) 16:35:14.80 ID:bHaTV8wK.net
- 普段10bitでやっとるけど12bitにしてみたところで違いが分からなかったよ。
- 814 ：名無しさん＠編集中：2016/02/26(金) 17:41:29.90 ID:m+0FG1+N.net
- ID:i7aFZYs7
主観の意味分かってないの？
- 815 ：名無しさん＠編集中：2016/03/09(水) 17:54:53.68 ID:imJr87Pl.net
- x265vfwも出てるやん
https://sourceforge.net/p/x264vfw/discussion/770224/thread/3e07f7b5/
l
- 816 ：名無しさん＠編集中：2016/03/09(水) 18:23:15.11 ID:qNQxWU8R.net
- 今時vfwなんてメリットあんのかね？
エンコ詳しくないニコ厨でもwiki見て簡単にmp4エンコできるのに
- 817 ：名無しさん＠編集中：2016/03/09(水) 18:29:23.70 ID:9Y8nZSW1.net
- 関わるな
- 818 ：名無しさん＠編集中：2016/03/13(日) 09:20:31.95 ID:weseHvkQ.net
- rc-grainの効果はどう？
あまり効果を実感できない
- 819 ：名無しさん＠編集中：2016/03/20(日) 08:39:40.31 ID:7J9mixui.net
- 最近完走しなくなった。
皆さんどうです？
OS入れ直して駄目ですので、x265疑ってるんですが。
どこのビルドも1.9は駄目な感じです。
- 820 ：名無しさん＠編集中：2016/03/20(日) 10:04:28.56 ID:KHVZBQe4.net
- エスパーさん出番ですよ
- 821 ：名無しさん＠編集中：2016/03/20(日) 11:38:36.85 ID:dlNvEFCk.net
- >>819
ちゃんと完走してるよ
muxerを最新のに変えてみるとか
- 822 ：名無しさん＠編集中：2016/03/20(日) 15:51:11.82 ID:16IrSqAm.net
- >>819
avisynthでMT使ってるとエスパーしてみる
- 823 ：名無しさん＠編集中：2016/03/20(日) 20:06:27.41 ID:nKj/TuoV.net
- MUXではなくエンコード自体が完了しないのです。
avisynthはMT使わずソース読ますだけの最小構成です。
皆さん問題ないんですね。
とりあえず自分の構成をもっと疑ってみます。
止まるのが規則性があったり無かったり意味不明なんですよね。
同じソースで3%数回続いた後、70%で止まったりorz
- 824 ：名無しさん＠編集中：2016/03/20(日) 20:40:06.24 ID:Fu5UyCAR.net
- 短いソースで試してみたら
- 825 ：名無しさん＠編集中：2016/03/20(日) 22:59:05.03 ID:oLphnsNe.net
- そういう時はmemtest
自分の環境よりソフトの方を疑うというのが理解できない
- 826 ：名無しさん＠編集中：2016/03/20(日) 23:51:09.20 ID:mbWz3Yxf.net
- aviでエンコードしてからx265でエンコードは？
- 827 ：名無しさん＠編集中：2016/03/21(月) 09:44:15.65 ID:PdR6lJIR.net
- メモリテストはwin付属ので問題なかったのと、
OS入れ直し、avisynth入れ直しくらいはしました。
ソースも変えてます。
30分位のソースだとごくまれに完走します。
11月くらいまで動いてたのでハードはそこまで疑いたくないのですが。
- 828 ：名無しさん＠編集中：2016/03/21(月) 10:48:22.93 ID:W3zX88FD.net
- >>827
そうやって821が言うような定石を守らないから
切り分けができないんだと思うよ
まぁ仮にmemtestで落ちても
原因はメモリとは限らないんだけどね
- 829 ：名無しさん＠編集中：2016/03/21(月) 10:58:42.48 ID:EJTslGgf.net
- 完走する事もあるならソースかハードの問題でしょ
頭おかしい
- 830 ：名無しさん＠編集中：2016/03/21(月) 11:15:49.32 ID:IwyEIcSu.net
- フルボッコで可哀想だからレスするけど
aviutl + x265guiでやってみたら？
- 831 ：名無しさん＠編集中：2016/03/21(月) 15:07:19.74 ID:+Ik+xhI4.net
- 1.9で中途ファイルが出来たというのはうちでもあったな
以前の構成から変わったのってそこぐらいだから1.9の所為なんだろうなとは思った（リトライしたら通ったけど）
- 832 ：名無しさん＠編集中：2016/03/21(月) 17:40:19.97 ID:U+Xdgxb4.net
- 同じ条件で上手くいく時といかない時があるって、ハード側が不安定なだけじゃね？
ソフト側の問題なら再現性はもっと高いと思うが
- 833 ：名無しさん＠編集中：2016/03/21(月) 18:39:37.32 ID:+Ik+xhI4.net
- ログ見たらフレームの入力に失敗してるっぽいな
avs側でYV12に変換してやると多分解決する
- 834 ：名無しさん＠編集中：2016/03/21(月) 20:18:58.92 ID:3MEwZrZM.net
- 今は完走しないことについての話なのになんで入力の話してるんだよ
途中で色空間が変わってるとしたら完全にスクリプトの問題じゃねーか
- 835 ：名無しさん＠編集中：2016/03/21(月) 20:41:01.66 ID:Y85ZQ3tt.net
- >>827
handbrakeかffmpegで試してみれ
- 836 ：823：2016/03/21(月) 21:38:39.05 ID: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
- 837 ：823：2016/03/21(月) 21:45:05.55 ID:vZIwSY4R.net
- >>835
ソース読みをavisynth使わず読み込みをってことですか？
- 838 ：名無しさん＠編集中：2016/03/21(月) 21:58:07.85 ID: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:
- 839 ：名無しさん＠編集中：2016/03/21(月) 23:05:25.98 ID:diV0PO6C.net
- pmode,pmeを無効にしてみるといいよ
同じような症状出てたけど、無効にしたら落ちなくなった
- 840 ：823：2016/03/21(月) 23:23:35.03 ID:vZIwSY4R.net
- とりあえず、>>838のランタイム入れてやってみてます。
>>839はその後改善がなかったら試してみます。
- 841 ：823：2016/03/22(火) 07:06:01.47 ID:1A+V4fFh.net
- >>838
ありがとうございます。
いきなり長時間物完走しました。
何回か違うソースで試してみます。
- 842 ：823：2016/03/31(木) 22:20:13.67 ID:OoJQ2UyX.net
- 10ソースくらい試してみましたが、
無事完走するようになりました。
皆様ありがとうございました。
- 843 ：名無しさん＠編集中：2016/04/01(金) 14:07:26.74 ID:vYfELI/A.net
- てかどこのビルドも駄目だと書いてるのにMSVCが原因だなんて普通思わねえよ
- 844 ：名無しさん＠編集中：2016/04/01(金) 16:49:59.34 ID:dTL/+QgY.net
- トラブルシューティングとしてビルドに使われたVCランタイムを入れるぐらいはしてもばちは当たらない
- 845 ：名無しさん＠編集中：2016/04/02(土) 09:22:23.23 ID:CqXSpfM9.net
- >>844
お前がはじめにそういえばよかった。
834だったらすまん。
- 846 ：名無しさん＠編集中：2016/04/02(土) 09:55:23.23 ID:1E+gnV9U.net
- >844も>838も同じ人物で私だけど
態度変えすぎだろう
- 847 ：名無しさん＠編集中：2016/04/04(月) 08:51:12.73 ID:PHD6aaQD.net
- YUV420ソースをYUV444にしてエンコするメリットはありますか？
- 848 ：名無しさん＠編集中：2016/04/04(月) 08:53:20.36 ID:nVqmW/e9.net
- どうして無いと思うわけ
- 849 ：名無しさん＠編集中：2016/04/04(月) 14:52:19.93 ID:Gj1hPCli.net
- どうしてあると思うわけ
- 850 ：名無しさん＠編集中：2016/04/04(月) 19:46:56.63 ID:PHD6aaQD.net
- >>848
有るとも無いとも言ってないですよ。
ぜひ、YUV420ソースのYUV444へのエンコを解説してください。
- 851 ：名無しさん＠編集中：2016/04/04(月) 20:08:35.41 ID:GIgTDtel.net
- 自分で試せないの？
- 852 ：名無しさん＠編集中：2016/04/04(月) 20:14:10.84 ID:aOfeiP7X.net
- ファイル作って動画を見て、よくなっていたら採用、変わらないor悪くなっていたらやらない、でいいじゃない
エンコの目的なんて、自分が見るための保存用がほとんどだろうし
- 853 ：名無しさん＠編集中：2016/04/05(火) 02:19:50.59 ID:/L9IqKot.net
- 目が肥えて後になって後悔するかもしれない
という発想がどうしてないのだろう・・・
- 854 ：名無しさん＠編集中：2016/04/05(火) 03:10:52.86 ID:VRuHp+46.net
- なんでこの流れでそんなズレた発想が出てくるんだろう・・・
- 855 ：名無しさん＠編集中：2016/04/05(火) 07:24:52.25 ID:23Tspq3D.net
- 元ファイル(生TS?)も保存しておけばいいんじゃね？
- 856 ：名無しさん＠編集中：2016/04/05(火) 07:39:04.16 ID:/18GblFb.net
- エンコするために勉強する時間よりその時間で稼いでHDD買ったほうがいい
オリジナルのまま保存しとけば将来目が肥えても安心
- 857 ：名無しさん＠編集中：2016/04/05(火) 08:02:56.95 ID:PkW1ygDm.net
- 趣味を否定してやるなよ
- 858 ：名無しさん＠編集中：2016/04/05(火) 15:04:07.31 ID:9JEcOI0a.net
- 話をそらして質問者の否定ばかりで、誰も解説できない
おまら情けないな
まぁ、俺もだけどな
- 859 ：名無しさん＠編集中：2016/04/05(火) 15:54:06.00 ID:oIluhigo.net
- ソースが8ビットなんだから10ビットでエンコしても無意味って口？
- 860 ：名無しさん＠編集中：2016/04/05(火) 16:14:30.97 ID:bXKjBZbc.net
- >>850
> YUV420ソースのYUV444へのエンコ
・環境やプレーヤーによっては再生できなくなる。再生支援も効かない。
・データ量が増える。
・やるにしてもYUV420→YUV444変換で色差補間をどうすんのかとかちゃんと考えないといかんね。
やるだけアホらしいと思うけど。普通はYUV420のまま再生時にレンダラで補間させるし。
・つうことでメリットなんか無いだろ。
>>858
自演乙
>>859
そんな話は誰もしてねーと思うぜ。
- 861 ：名無しさん＠編集中：2016/04/05(火) 16:26:50.63 ID:oIluhigo.net
- 同じこと
- 862 ：名無しさん＠編集中：2016/04/05(火) 20:35:58.64 ID:9JEcOI0a.net
- >>860
妄想乙
- 863 ：名無しさん＠編集中：2016/04/05(火) 20:44:23.74 ID:+zekPSej.net
- >>856
勉強ったってオプション弄ってできたものを評価していくだけじゃん
- 864 ：名無しさん＠編集中：2016/04/05(火) 22:25:10.00 ID:DXAVhdGx.net
- 12bit エンコすんのはいいんだけど、どういう環境で見れば軽いとか綺麗とかってだれか試してるんかな
つか、みんなどのプレイヤーで見てんの？
- 865 ：名無しさん＠編集中：2016/04/06(水) 00:21:04.15 ID:gavek0iz.net
- >>864
12bitのHEVCデコードに対応してるデコーダなんてLAVくらいじゃね。
デコーダからP016でレンダラに渡すことを考えるとmadVRかMPDNあたりが必要。
LAVで12bitYUV→RGB24変換してRGBでEVR等のレンダラに渡す方法もあるけど
この場合色差補間とかがどうなるのかは知らん。
12bitは再生支援も対応しないだろうし、一般的な1667万色なPC環境では10bitで事足りるはずだし
10bitに比べてなにかメリットはあるのかね？
- 866 ：名無しさん＠編集中：2016/04/06(水) 06:58:25.58 ID:BZiOzY8Z.net
- 的はずれな事ばかり
まず試してみなよ
感動するぞ
- 867 ：名無しさん＠編集中：2016/04/06(水) 09:34:00.56 ID:oAh+1FS4.net
- x264では444円個のほうがssimはよかった
なんでかはしらんけど、x265ではそうとは言えなかった
12bitは保存用に使ってるな
- 868 ：名無しさん＠編集中：2016/04/06(水) 19:13:30.16 ID:LlUg6G6o.net
- >>866
もしかして12bitエンコ自体やったことないか、プラシーボで喜んじゃうタイプ？
- 869 ：名無しさん＠編集中：2016/04/06(水) 20:01:05.75 ID:cKZ87zcu.net
- 8bitと10itでは結構、良くなるから
10bitから12bitも多少は良くなるんじゃね
- 870 ：名無しさん＠編集中：2016/04/06(水) 21:36:40.18 ID:TIHK3iW4.net
- --aq-strength, --psy-rd, --psy-rdoqは調整次第で
大幅な容量orエンコ時間の増大なしで見た目をよくできると思うんだけど
それぞれ値を増やすとどういったところに変化が表れやすいか
教えてくれないかい
http://x265.readthedocs.org/en/default/cli.html
を読んだがpsyは読んでもよくわからんかった
- 871 ：名無しさん＠編集中：2016/04/06(水) 21:42:52.17 ID: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と大差ないな。
- 872 ：名無しさん＠編集中：2016/04/06(水) 22:26:08.63 ID:BZiOzY8Z.net
- めくら
いや無能ってとこかな
- 873 ：名無しさん＠編集中：2016/04/06(水) 22:38:06.12 ID:cKZ87zcu.net
- >>870
自分はx265では圧縮率を求めて割とどうでもいいソースにしか使ってないからザルなテストしかしてないけど
x264ほど素直に画質に反映されず分かりづらい（まあ、それだけ優秀になってるってことなんだろうけど）
ベースになってるであろうx264の感じでは
AQ 人の肌などのアラ隠しに有用
psy-rd 動くエッジとか高周波部分が削られる
qcomp 何気に重要。大きくするとグレンから動く対象の再現性など画の完成度がとにかく高まる
だからAQはデフォ、psy系は低め、qcompは心なし上げて0.65で使ってる
最初に書いたけど画質は求めてないから期待しないで
- 874 ：名無しさん＠編集中：2016/04/07(木) 19:37:26.46 ID:5GOclDJK.net
- >>873
thx!
自分はqcompを0.75で使ってた
自分でも適当なソースで簡単な比較はしたけど、
AQ：上げると画質は向上したけど容量も増えた（x264ではそれほど増えた印象無）
psy-rd：上げると容量が少しだけ増えた（x264のほうが増加量が大きい印象）
psy-rdoq：上げるとソース由来の細かい部分が残るようになった
くらいしかわからんかった
2passでビットレート固定すると、SSIMは（見る意味があるかは置いといて）
AQとrdoqは極大値があったけど、rdは上げると下がる一方
よくわからんです
- 875 ：名無しさん＠編集中：2016/04/07(木) 20:14:01.22 ID:xaya07W/.net
- G11bitB10bitR11bitなら良いのにね。
- 876 ：869：2016/04/07(木) 21:37:16.65 ID:kTK9FIEO.net
- >>874
「だからAQは～」の行はx265での設定ね
ほぼ固定された動画だと面白いように縮むから使ってるけど
画質評価は本当に難しくなってるよね
- 877 ：名無しさん＠編集中：2016/04/08(金) 10:10:35.33 ID:Rwrntj3b.net
- littlepoxがプリセットを作ってくれてる
実写
slowerベース
http://forum.doom9.org/showpost.php?p=1760309&postcount=3402
veryslowベース
http://forum.doom9.org/showpost.php?p=1760344&postcount=3406
アニメ
http://forum.doom9.org/showpost.php?p=1760708&postcount=3442
- 878 ：名無しさん＠編集中：2016/04/08(金) 13:54:08.07 ID:uoC7bHcg.net
- キチガイ臭がするそいつ
- 879 ：名無しさん＠編集中：2016/04/09(土) 10:01:22.54 ID:Q4UbIrNX.net
- fhd以上、x265の汎用設定詰めることができる時点で普通ではない
時間と手間がハンパじゃない
- 880 ：名無しさん＠編集中：2016/04/11(月) 21:49:12.30 ID:xwAKbqwo.net
- >>877
一応アニメのを試してみた結果、普段使っている設定と同ビットレートで
比較してみたところ、見た目でもSSIMでも大きく画質が下がった
ノイズがひどい
- 881 ：名無しさん＠編集中：2016/04/11(月) 21:55:16.14 ID:I6vlHsjj.net
- 「普段使っている設定」を書かずに報告しても意味ないような・・・
- 882 ：名無しさん＠編集中：2016/04/11(月) 22:25:47.80 ID: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
比較の時はビットレート固定
- 883 ：名無しさん＠編集中：2016/04/12(火) 14:22:43.11 ID:f5lHfaTk.net
- 画像サイズとビットレートも必要だよ
- 884 ：名無しさん＠編集中：2016/04/12(火) 18:33:03.38 ID:BUSmDDzJ.net
- >>883
1280x720, 2100 kbps（←深い意味はない）
- 885 ：名無しさん＠編集中：2016/04/12(火) 19:03:31.00 ID:f5lHfaTk.net
- ソースによるけど2Mbps程度ならdeblock 0:0にしてsaoも有効化
aq/psy系も下げたほうがいい結果になりそう＞873のプリセット
あくまでx264での知見も基にした当てずっぽうだけど
- 886 ：名無しさん＠編集中：2016/04/12(火) 19:29:21.87 ID:BUSmDDzJ.net
- 同感
>>877で十分な画質（←人によるが）を得るためにはどれくらい高いbitrate
が必要になるのか
高いbitrateならデフォルトに近い設定でも十分な画質が得られるような気がする…
- 887 ：名無しさん＠編集中：2016/04/12(火) 19:34:16.49 ID:1ATzc72f.net
- >>882
・>>877の設定で出力する時にも--output-depth 10は付けたの？
・SSIMはどうやって測ったの？
・>>877のアニメというのは--tune animationを考えてみたという設定だから
refとかbframesとかmeとかその他もろもろは特に指定されてないけど、そのへんはどう設定したの？
そのへんがデフォ値のままなら>>882と比較しても意味がない気がする。
・>>882の設定ってveryslowより重そうな気もするし、--rc-lookahead 250とかになってるけど、
本当に普段この設定で使ってるの？
- 888 ：名無しさん＠編集中：2016/04/12(火) 19:56:15.84 ID:IeZ3td+Lx
- x265ってkeyintの値よりrc-lookaheadの値を大きくできるんだ
x264はkeyintの値までしか設定できなかったからそういうもんだと思ってた
- 889 ：名無しさん＠編集中：2016/04/12(火) 19:58:52.51 ID:f5lHfaTk.net
- 与えるビットレートが違えばマッチするオプションも変わるだけじゃないの
- 890 ：名無しさん＠編集中：2016/04/12(火) 20:08:09.35 ID:BUSmDDzJ.net
- >>887
・--output-depth 10は付けた
・--ssim
・書いていないところは>>882と同様
・本当に使っている
1280x720で4fps程度の速さ（仕事から帰ってくるまでに終わればいい）
2600K@4.4GHzでエンコ
- 891 ：名無しさん＠編集中：2016/04/12(火) 22:07:20.02 ID: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!
という警告が出るので、適切な計測結果にはなってないと思う。
- 892 ：名無しさん＠編集中：2016/04/12(火) 22:50:43.37 ID:bnbtd3T9.net
- つか、ほぼplacebo状態だな。
現状rd4の意味無いし（Currently same as 3 要するにデフォと一緒）、
rd上げるなら5。
で、そうするぐらいならpreset placeboで良いんじゃねーかと（笑
- 893 ：名無しさん＠編集中：2016/04/13(水) 19:12:35.06 ID: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)
- 894 ：名無しさん＠編集中：2016/04/14(木) 06:23:31.29 ID:SmTLnnP5.net
- 検証乙
SSIMを見る限り、>>882はveryslowより画質が良くslowerより早い
>>877を適用することでmediumより画質が悪くslowerより遅くなる
という認識でいいのかな？
- 895 ：名無しさん＠編集中：2016/04/14(木) 08:54:23.53 ID:TL0trVBZ.net
- ビットレート盛ったら（crf 20以下？）綺麗になると思う
- 896 ：名無しさん＠編集中：2016/04/14(木) 10:36:09.43 ID:uaVnCBhc.net
- ffmpegのssimの0.0001台の違いて見た目どんな違いなんだろう？
誰か解説頼みます。
- 897 ：名無しさん＠編集中：2016/04/14(木) 23:43:40.37 ID:NwnHdn04.net
- 気にしたらハゲ
- 898 ：名無しさん＠編集中：2016/04/14(木) 23:47:05.40 ID:i5ZA7JyZ.net
- 自分が良いと思ったセッティングでいいじゃない。
アニメなんかは誰に見せるわけでも無いんだし。
- 899 ：名無しさん＠編集中：2016/04/15(金) 00:44:21.13 ID:+Fs+OHLX.net
- --rc-lookahead 250 って怖ろしくメモリ食うんじゃないか？ｗ
40から80に上げただけでも1.4Gから2.4Gに跳ね上がってたのに
- 900 ：名無しさん＠編集中：2016/04/15(金) 01:48:34.93 ID:KWIKv7Io.net
- 解像度などにもよるけどかなり食う
- 901 ：名無しさん＠編集中：2016/04/15(金) 01:58:08.47 ID:Vj0XVi1o.net
- ちょっと試してみたけど、>>893のサンプルだと
slower（-rc-lookahead 30） → 600MB
>>882（-rc-lookahead 250） → 2.6GB
だな。
- 902 ：名無しさん＠編集中：2016/04/15(金) 01:59:21.15 ID:pgwZJlOQ.net
- そういえば初期のx265ってメモリバカ食いしてたよね
- 903 ：名無しさん＠編集中：2016/04/15(金) 03:49:21.78 ID:G5Tu0V3Z.net
- メモリ食うだけで画質が上がるんなら数字上げてもいいんじゃないかな
メモリ足りないなら仕方ないけどね
- 904 ：名無しさん＠編集中：2016/04/15(金) 14:54:39.12 ID:i2BOyiEg.net
- >>893
リンク先のスレ読むとcffで使えと書いてあるぞ
- 905 ：名無しさん＠編集中：2016/04/15(金) 15:51:38.35 ID:R0iR/RQZ.net
- >>904
cffってなに？crfのこと？
リンク先というのは>>877のことだと思うけど、crfで使え（biｔrate指定じゃ駄目）なんて書いてないと思う。
- 906 ：名無しさん＠編集中：2016/04/15(金) 21:13:40.04 ID:v5i5tBse.net
- 今時CBRなんてナンセンス
- 907 ：名無しさん＠編集中：2016/04/15(金) 23:16:50.52 ID:xWoGZXDA.net
- 流れも読まない上にCBRってお前・・・
- 908 ：名無しさん＠編集中：2016/04/15(金) 23:31:22.66 ID:WL/mTNMT.net
- ﾈﾀﾆﾏｼﾞﾚｽ(・∀・)ｶｺﾜﾙｲ!!
- 909 ：名無しさん＠編集中：2016/04/16(土) 22:50:58.36 ID:FapX/LQs.net
- 画質/負荷の効率が良いオプションって各preset間で
値が変わったり追加されたりするやつでいいのかな
ただし重いpresetに行くほど変化しているオプションの効率が悪くなるとかあるのかな
- 910 ：名無しさん＠編集中：2016/04/16(土) 23:15:07.78 ID:RIWYlU/O.net
- 動き検索の重要度はsubme ＜ meだって猫さんが書いてたから
x265もそうだと思う
それとBフレやrefの枚数も3～4ぐらいでセーブしとくのもエンコ負荷の低減に役立つと思う
- 911 ：名無しさん＠編集中：2016/04/17(日) 16:13:38.77 ID:E1zy7U5k.net
- >>905
過去レスよく読め
- 912 ：名無しさん＠編集中：2016/04/17(日) 16:34:11.64 ID:SQT/cZ/R.net
- >>911
お前さんが>>906と同一人物で「いまどきbitrate指定エンコなんてやる奴いねーよ」とでも思ってるなら
>>893が「同一ビットレートでのSSIM比較」という目的で行われたことを全く理解してないことになるが・・・。
- 913 ：名無しさん＠編集中：2016/04/18(月) 13:09:32.53 ID:4454Srxg.net
- 必死感漂ってるな
残念だけど、>>906じゃないし、用途によってはcbrを使う人がいるのは誰でもわかっていること
littleはvbrの設定を晒してるんだから、cbrでssim比較しても無意味
まぁ、妄想と決めつけが激しく頭が悪くても、がんばって行きろ
- 914 ：名無しさん＠編集中：2016/04/18(月) 14:53:46.23 ID:xvx3IXAG.net
- お前ら優位に立とうとする言葉選び好きだよな
- 915 ：名無しさん＠編集中：2016/04/18(月) 15:38:14.70 ID:ZiaZImZR.net
- >>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味」
の根拠はなに？
・>>877の上２つのリンクには--crfも含まれてるけど、>>893で使った３つ目のリンクは
--tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
・「CBRの幻想」とかx265のhelpの--bitrateの説明とか読んだほうがいいような気がする。
- 916 ：名無しさん＠編集中：2016/04/18(月) 16:55:07.97 ID:4454Srxg.net
- >>915
>>>913
・素朴な疑問なんだけど
「vbrの設定を晒してるんだから、cbrでssim比較しても無意味じゃない」
の根拠はなに？
> --tune animationの案だから--crfは含まれてないし、crf向けともなんとも書いてないと思うんだけど。
思うのは自由だよ。でも、littleの一連のレス読んでから判断してね。
>・「CBRの幻想」とか
そんなこと言ってないよ。しっかり妄想と現実の区別してね。
まずは丁寧に文を理解することを習得しようね。短い文だから難しくないよ。
ｶﾞﾝｶﾞﾚ
- 917 ：名無しさん＠編集中：2016/04/18(月) 17:09:18.40 ID:ZiaZImZR.net
- ああ、やっぱり説明も話もまともに出来ない人だったか・・・お疲れさまでした。
- 918 ：名無しさん＠編集中：2016/04/18(月) 17:35:42.08 ID:no/AiHFv.net
- >>914
お前らと言うけど2レスだけだよ
- 919 ：名無しさん＠編集中：2016/04/18(月) 18:51:38.96 ID:Sn6HnjyG.net
- >>913
cbr≠abr であり、>>893はabrだと思う
abrはvbrで出来上がるものの平均ビットレートを指定してエンコじゃないのかな。。
ちなみにcbrの用途って何があるの？放送局？
- 920 ：名無しさん＠編集中：2016/04/18(月) 19:06:32.01 ID:ZiaZImZR.net
- 割と知られてるページだと思ってたからタイトルしか書かなかったけど
>>916には通じなかったみたいだし、「"CBRの幻想"でググれ」と書くべきだったとちょっと反省。
- 921 ：名無しさん＠編集中：2016/04/19(火) 09:54:12.07 ID:YZY7DcaM.net
- >>920
？俺はcbrの善し悪しには何も触れてないぞ。話しのすり替えは止めようね。
短い文なんだからきちんと理解できるようになろうね。
自分の落ち度を認めず他の内容を無視するのも止めようね。
- 922 ：名無しさん＠編集中：2016/04/19(火) 11:48:28.42 ID:7vkH9RtK.net
- 好きに使ったら良いのに、自分が良く使う設定に固執しすぎなんだよね。
- 923 ：名無しさん＠編集中：2016/04/19(火) 11:53:32.50 ID:CfB8B13z.net
- 近代的なビデオコーデックで真のCBRなんて不可能っていう「CBRの幻想」って解説記事があるの
つまり1パスビットレート指定でも動作はVBRだと揚げ足を取られてるわけ
個人的にはcrf指定でも指定値が大きければ画質は悪くなり
ビットレート指定でもビットレートを大きく盛れば画質は良くなるわけだから
あまり意義のある言い争いじゃないと思う
- 924 ：名無しさん＠編集中：2016/04/19(火) 16:02:39.82 ID:filiPvCp.net
- もう何年前に読んだか忘れたけど、圧縮前に圧縮後予定ファイルサイズから逆算して
正確な圧縮品質を指定することは不可能かつ正確にファイルサイズを合わせることも不可能だから
って奴だよな
- 925 ：名無しさん＠編集中：2016/04/19(火) 17:28:26.53 ID:YZY7DcaM.net
- >>919
cbr≠abrなのはしってるよ
同一ビットレートで、ときてたからcbrといっただけですう
だから、handbrakeはサイズ指定のサポート止めたしね
907=910=918?
- 926 ：名無しさん＠編集中：2016/04/19(火) 17:40:38.84 ID:ILdf6rCX.net
- 一応言っておくと俺はSSIMの計測結果を貼っただけであって、>>877や>>882とは別人。
CBRの件は別に揚げ足じゃなくて、helpでもABRという表現が使われてるし、
「CBRの幻想」の記事も踏まえて「CBR」という表現はあまり使わないほうがいいと思っただけ。
>>921にはまったく伝わらなかったみたいだし、なんか変な言い訳してるけど・・・。
よく見ると>>916は
「cbrでのSSIM比較が無意味ではないと主張する根拠はなに？」
と逆に問い返してるんだね。コピペミスかと思ったわ・・・。
俺は単に>>913の
・>>877はvbr（--crf）用の設定だ
・だからcbr（--bitrate）でSSIM比較しても無意味
という２つの主張の根拠がわからなくて知りたかっただけ。
これまで特に気にせずに２パスエンコも利用してSSIMを調べたり貼ったりしてたんだけど、
--bitrateだとうまく働かないオプションとかあるんだっけ・・・？
>>925はこれ以上相手にしても徒労に終わりそうだし、もし誰かわかるなら教えてほしい。
- 927 ：名無しさん＠編集中：2016/04/19(火) 17:44:29.70 ID: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(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)
- 928 ：名無しさん＠編集中：2016/04/19(火) 17:58:21.32 ID:CfB8B13z.net
- 微妙に着眼点と主張がかみ合ってないからお互いにスルーするが吉
- 929 ：878：2016/04/19(火) 18:00:28.75 ID: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
- 930 ：名無しさん＠編集中：2016/04/19(火) 18:56:00.56 ID: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)
- 931 ：名無しさん＠編集中：2016/04/19(火) 19:20:19.87 ID:0e3x1/oL.net
- >>930
早速のエンコありがとう。
ちょっと重くなってしまったみたいだね。スマン
でも、画質はそれなりに改善したように見えるね。
- 932 ：名無しさん＠編集中：2016/04/19(火) 21:31:48.09 ID:CfB8B13z.net
- 今のx265の場合、デフォのcrf値が大きすぎるんだよな
プリセット作るにしても決めきられない感じ
- 933 ：名無しさん＠編集中：2016/04/20(水) 10:32:47.35 ID:/W4Johvo.net
- プリセットなんてmedium(デフォルト)な時点でx264超えてるんだからどうでもいいよ
後は好きなcrf値を設定すればOK
なんか色んな設定やパラメータいじくり回すx264時代の因習に囚われてる人いるようだけどｗ
- 934 ：名無しさん＠編集中：2016/04/20(水) 10:52:36.60 ID:O3XwBTuO.net
- 4K60Pがリファレンスなのにね
- 935 ：名無しさん＠編集中：2016/04/20(水) 14:21:23.87 ID:9swemZrS.net
- プリセットじゃなくプロファイルだった
- 936 ：名無しさん＠編集中：2016/04/20(水) 19:29:17.58 ID:klJmlwQn.net
- >>933
x264でも重ための設定でAQやpsy-rdなどを調整したらx265の
単純なmediumになら画質で勝るよ。
つまり、設定次第だと思う。
- 937 ：名無しさん＠編集中：2016/04/20(水) 20:09:39.34 ID:GUTooAcL.net
- さわらないほうが良いタイプだと思うよ
- 938 ：名無しさん＠編集中：2016/04/20(水) 21:34:42.31 ID:/W4Johvo.net
- >>936
x265のプリセットを１段階上げればいいだけでしょｗ
- 939 ：名無しさん＠編集中：2016/04/21(木) 01:14:11.61 ID:GimnWLrM.net
- レベルを上げて物理で殴ればいい
- 940 ：名無しさん＠編集中：2016/04/21(木) 03:00:03.58 ID:LQaBaBJx.net
- レベルといえばお前らレベル指定とかしないん？
- 941 ：名無しさん＠編集中：2016/04/21(木) 08:48:25.19 ID:s5ZQAH1b.net
- 携帯視聴やゲーム機家電視聴などを弾きたい時に
- 942 ：名無しさん＠編集中：2016/04/21(木) 22:30:46.71 ID:43CTREQW.net
- 最大ビットレートは規格に合わせて指定してる
他のオプションまでは把握してないからデフォのまま
- 943 ：名無しさん＠編集中：2016/04/23(土) 19:00:20.96 ID:p08WM9kP.net
- ABRのSSIMを貼った人は何が言いたかったのだろう
- 944 ：名無しさん＠編集中：2016/04/23(土) 19:41:54.17 ID:GVwq/FMD.net
- 結論を言うと荒れるから何も言わないのかな
数字だけで判断するなとか言うやつが出てくるかもしれないし
- 945 ：名無しさん＠編集中：2016/04/23(土) 20:22:56.70 ID:1ED72ZaJ.net
- >>943
ただの参考値として貼っただけだよ。
>>926でも書いたけど、なんで「ABR（2pass --bitrate）のSSIMは無意味」だと思うの？
ちゃんとした根拠があるなら知りたいんだけど。
- 946 ：名無しさん＠編集中：2016/04/23(土) 20:50:47.52 ID:VX0ubDbv.net
- 少なくとも俺は --cfr でサクッとやってしまうから abs でビットレート固定されても参考にはしないかな。
逆に abs でエンコしてる人になら参考になると思う。
要は自分で取捨選択を適切にしていればいいだけであって、人に文句を言うのはお門違いだと思うよ。
- 947 ：名無しさん＠編集中：2016/04/23(土) 21:03:52.97 ID:GVwq/FMD.net
- cfrやabsはネタかな
オプション検討しているときにcrfを使うとビットレートが
大幅に変わってしまい、オプションの良し悪しが分からなくなる。
最終的にcrfでエンコするにしてもオプション検討においては
ABRでの比較は十分に参考になると個人的には思う。
- 948 ：名無しさん＠編集中：2016/04/24(日) 12:02:05.68 ID:ou5067T+.net
- >>945
「ABR（2pass --bitrate）のSSIMは無意味じゃない」ちゃんとした根拠があるなら知りたいんだけど。
- 949 ：名無しさん＠編集中：2016/04/24(日) 12:06:44.59 ID:h82NYOq7.net
- 指定ビットレートが低すぎなのはあると思う
- 950 ：名無しさん＠編集中：2016/04/24(日) 12:25:41.70 ID:szqA3nvc.net
- 指定ビットレートの適正値はソース、解像度、好みによって変わりそう
- 951 ：名無しさん＠編集中：2016/04/25(月) 16:45:47.07 ID:OGPz4ITg.net
- ABRの人、doomのレスを理解できてないと思った
ここのレスの理解も怪しい
オプションの理解も
- 952 ：名無しさん＠編集中：2016/04/25(月) 19:28:56.39 ID: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のレスを理解できてないという主張の根拠も全くわからないので教えてほしい。
・俺個人のオプションに関する理解が浅いのは事実だから解説があると喜ぶよ。
これがこちらの現状なので、理解がおかしいというなら具体的な指摘を頼む。
スルーできてなくてごめん。> スレ住人
具体的な説明がされない限り、以後スルーするね。
- 953 ：名無しさん＠編集中：2016/04/25(月) 20:44:32.37 ID:cQiwXoCT.net
- >>951
私も>>952と同程度の理解なので、何がどう理解できていないのかを教えてほしい。
根拠を示すことができず否定するだけの無知な人ではないことを祈りつつ。
- 954 ：名無しさん＠編集中：2016/04/25(月) 20:59:50.91 ID:QMvVZfm8.net
- 過去には、crfでSSIM比較するなビットレート指定しろ、って人もいたしどうしろと
- 955 ：名無しさん＠編集中：2016/04/25(月) 21:01:33.14 ID:QZda0fQA.net
- 否定だけってのは反応に困るよね
品質指定だと瞬間的なビットレートはかなり高くなるから品質にはかなり有利
自分の経験でXvid ビットレート指定で350MBと、品質指定の250MBのファイルで後者の方が綺麗（前者は動きの激しい箇所でブロックノイズ多発）で
品質指定はそれぐらい画質に有利だと思う
でx264でも画質を求めたらcrf下げてデブロックフィルタも弱めてpsyを強めたりして（自分は）
そのcrf値が小さいとき用のオプションをcrfが大きいときに使うとやっぱりアラが出る
なので高画質向けオプションを評価するときは、コーデックの性能をもっと引き出せる好条件でやって欲しいなとは思う
（ネタだと思われそうだけど自分も教えて欲しいな>>951）
- 956 ：名無しさん＠編集中：2016/04/25(月) 21:08:01.55 ID:mYE/Sg/n.net
- 一人で何やってんスか
- 957 ：名無しさん＠編集中：2016/04/25(月) 23:17:22.98 ID:xf7dz0xUo
- は？
- 958 ：名無しさん＠編集中：2016/04/26(火) 00:17:01.11 ID:yVx5x6Ll.net
- いまだに勘違いがはびこってるようだけど
2passってのは一回エンコしてみてその結果から目標ビットレートに近づくように自動でcrfを調整してもう一度エンコしてるだけのことだろ
最終的なビットレートが同じなら手動でcrfを指定しようが2passでやろうが画質に違いは出ないよ
- 959 ：名無しさん＠編集中：2016/04/26(火) 03:30:54.19 ID:P6dH9VcC.net
- CRFならlevelが許す限りの範囲でビットレートを変動できる
ビットレートを指定するが故の過剰品質も抑制できる、って理解だが
どっちにしろVBVでレート制御が入るからそっちの設定だけ詰めればCRFで良いような気がする
- 960 ：名無しさん＠編集中：2016/04/26(火) 18:29:14.73 ID:H6GEQXQr.net
- >>958
HEVCではそうなのか？
書いてないけど>955の「Xvid ビットレート指定で350MB」は「Xvid ビットレート指定2Passで350MB」
- 961 ：名無しさん＠編集中：2016/04/26(火) 20:45:29.80 ID:xOye6Bx8.net
- ABRの人、自演がんばれ
- 962 ：名無しさん＠編集中：2016/04/27(水) 01:45:52.17 ID:ccoJ1QZy.net
- Xvidとか古すぎて話についていけないわ
Xvidとx26Xとじゃレートコントロールの方式が違うんだよ
- 963 ：名無しさん＠編集中：2016/04/27(水) 06:21:06.02 ID:SeExodLv.net
- x265の更新がピタっと止まっているんだけど、何かあったのかな
- 964 ：名無しさん＠編集中：2016/04/27(水) 08:04:29.24 ID:rBBpLPal.net
- 春休みは終わったんだよ、ヒキコモリ君
- 965 ：名無しさん＠編集中：2016/04/27(水) 09:32:20.93 ID:7jGMhriN.net
- x265の更新していたのは、日本の学生だったか…
- 966 ：名無しさん＠編集中：2016/04/27(水) 09:34:20.09 ID:4Bx6XeNC.net
- また一気に更新くるんじゃないの
- 967 ：名無しさん＠編集中：2016/04/27(水) 12:17:51.54 ID:q1CqmRwh.net
- >>952
>具体的な説明がされない限り、以後スルーするね。
実行しろ
わかってないことがわかってないのにわかった気になってゴリ押しする奴に誰が説明するかよ
他人が自分のために1から10まで手取り足取り説明してくれるのが当然という発想かよ、ゆとりか？
自覚のないうぬぼれの激しいばか
レス見てるだけでイライラした，蹴り入れたくなる
もう、ここに来るな
- 968 ：名無しさん＠編集中：2016/04/27(水) 12:56:15.58 ID:ccoJ1QZy.net
- こっそり教えてあげるけどお前の方が迷惑だよ
- 969 ：名無しさん＠編集中：2016/04/27(水) 18:04:47.37 ID:9yLxz2J0.net
- >>967
邪魔だからもう来ないで
- 970 ：名無しさん＠編集中：2016/04/27(水) 19:33:10.69 ID:MXOYRBVo.net
- 一部の動画の最初の数秒だけノイズだらけになるのって、エンコするときの設定で回避できますか？
- 971 ：名無しさん＠編集中：2016/04/27(水) 20:11:42.22 ID:U6riuRT4M
- キーフレームでカットせずに編集された動画とか？
- 972 ：名無しさん＠編集中：2016/04/27(水) 19:59:53.45 ID:O1aRnOt/.net
- 一部動画って何を差すのか知らないけど最初だけならそこをカットすりゃいいんでないかい
- 973 ：名無しさん＠編集中：2016/04/27(水) 20:47:20.64 ID:vYGeTekE.net
- >>970
それはx265は関係なく、元動画がおかしいか、エンコード前のデコード処理に問題があるか、
エンコード後の再生に使うデコーダに問題があるだけじゃね？
- 974 ：名無しさん＠編集中：2016/04/28(木) 11:56:00.94 ID:VAWFmSIl.net
- >具体的な説明がされない限り、以後スルーするね。
実行できないね
やっぱり、みんなが思ったであろう口先番長
- 975 ：名無しさん＠編集中：2016/04/29(金) 22:22:26.51 ID:Qjv/odTt.net
- x264 r2692(8/10bit)、x265 1.9+138(8/10/12bit)で各プリセットの計測テストしたので置いとく。
プリセットのみ（一部のデータは--tune等の調整つき）
・エンコード時間： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3305.jpg
・SSIM/bitrate相関図： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3306.jpg
・SSIM/bitrate相関図(medium以上)： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3307.jpg
--tune ssim付き
・エンコード時間： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3308.jpg
・SSIM/bitrate相関図： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3309.jpg
- 976 ：名無しさん＠編集中：2016/04/29(金) 23:06:35.59 ID:hM8i6t7l.net
- >>975
乙乙
x265の8bitと10bitの差って凄いのね
- 977 ：名無しさん＠編集中：2016/04/30(土) 03:24:21.10 ID:icRfs4QB.net
- 力作ですごいけど相関図が見づらい・・・
- 978 ：名無しさん＠編集中：2016/04/30(土) 08:19:14.01 ID:iwbiPODt.net
- tab使いは頭悪いから
- 979 ：名無しさん＠編集中：2016/04/30(土) 10:36:27.87 ID:/y9WItAV.net
- わがまま言えば実写が欲しかった
- 980 ：名無しさん＠編集中：2016/04/30(土) 14:19:43.42 ID:JnFxQH0Q.net
- >>958
前にTSからcrfでエンコして結果、２０００kbsくらいで仕上がったんだけど
その後に同じTSを２passで２０００kbsでエンコしたら残り１分くらいから最後までブロックノイズが乗ったんだ
たまたまかと思ってもう一回２passでやったらやっぱり同じようにブロックノイズが乗った
なんでやろう？
それ以来２passは信用してないんだけど
- 981 ：名無しさん＠編集中：2016/05/01(日) 01:06:55.28 ID:OwT/pRKY.net
- >>980
crf エンコして 2,000kbps ってそれ平均じゃないかな? vbr だからシーンによってビットレートは変わるよ。
2pass 2,000kbps でノイズでるんならそれ、ビットレート足りなかったんだろ。
- 982 ：名無しさん＠編集中：2016/05/02(月) 13:48:49.91 ID:3M7zOLf9.net
- >>981
2passが>>958の主張する挙動の通りなら>>980の現象は説明つかない
ってことを言いたいんじゃないの
- 983 ：名無しさん＠編集中：2016/05/02(月) 17:17:48.15 ID:IVu6sEQK.net
- >>958は基本的には正しいから可能性は4つだな
① x265のコードにミスがある／あった
② >>980の比較方法にミスがあった
③ x265の2nd-passの自動crf調整アルゴリズムの性質上、実際にそういったことが稀に起こり得る
④ >>980の話は嘘か誇張である
でも決め手となる詳細な情報が何一つないからあんまリアクションできないわな
- 984 ：名無しさん＠編集中：2016/05/02(月) 17:20:24.76 ID:NFZmJHH5.net
- １パス目の解析ファイルが正常に作れてなかったとか？
- 985 ：973：2016/05/02(月) 20:19:49.45 ID:GTGVqrYC.net
- >>983
冷静な分析だと思います
嘘か誇張は絶対ないです
1パス目の解析ファイルの作り方がまずかったのか？
x264と同じやり方で2passでやってたんだけど・・・
元のTSはインターレースのなかにPV映像の30pが混じった映像で
それをQTGMCで60pにしてました
ブロックノイズはその30pの部分に載ってました（微妙じゃなくて明らかなやつです）
- 986 ：名無しさん＠編集中：2016/05/02(月) 20:43:03.56 ID:MFklek4b.net
- 自分の言ったことくらい実行しろ
- 987 ：名無しさん＠編集中：2016/05/02(月) 23:18:21.04 ID:3M7zOLf9.net
- bitrateを指定する以上2passもCBR≒ABRの発展型でしかないと思うんだがな
crfオプションを指定しない以上エンコーダは品質目標を知りえないわけで
アグレッシブに圧縮できるシーンに出くわしたときCRFほどの働きはできないだろう
- 988 ：名無しさん＠編集中：2016/05/03(火) 11:08:09.34 ID:IEaoSNtT.net
- なんだ？この自演臭い2pass議論モドキ
- 989 ：名無しさん＠編集中：2016/05/03(火) 16:25:11.30 ID:Vh9buT2E.net
- BitrateViewerで違いを見てみようかと思ったら、H.265には対応してないんだった。
古いソフトだから当たり前だけど、H.265に対応してる同様のソフトってないのかな。
- 990 ：名無しさん＠編集中：2016/05/03(火) 17:53:45.39 ID:fYHQmMJu.net
- MPC-hcｆｒで代用できるんじゃないか？
- 991 ：名無しさん＠編集中：2016/05/03(火) 19:04:14.23 ID:Vh9buT2E.net
- >>990
ググってみたけどなんのことかわからなかった
- 992 ：名無しさん＠編集中：2016/05/03(火) 19:07:46.37 ID:Vh9buT2E.net
- とりあえず980過ぎてるので次スレ立ててくる
- 993 ：名無しさん＠編集中：2016/05/03(火) 19:11:22.18 ID:Vh9buT2E.net
- 次スレ
x265 rev3
http://echo.2ch.net/test/read.cgi/avi/1462270195/
- 994 ：名無しさん＠編集中：2016/05/03(火) 19:40:13.42 ID:fYHQmMJu.net
- >>991
ごめん
mpc-hcって書こうとしてたんだけど変になってた
>>993
乙
- 995 ：名無しさん＠編集中：2016/05/03(火) 20:06:53.73 ID:IGe9RuRo.net
- >>993
おつ
- 996 ：名無しさん＠編集中：2016/05/03(火) 20:11:50.14 ID: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を超えることは無かった
- 997 ：名無しさん＠編集中：2016/05/03(火) 23:36:26.14 ID:umRZY+Hf.net
- だってファイルサイズが違うんでしょ？
- 998 ：名無しさん＠編集中：2016/05/04(水) 00:07:59.51 ID:2HnXwOPY.net
- 四捨五入してオマケしたから同じではないが
crf23が32.4MB
2passのが36.6MB
- 999 ：名無しさん＠編集中：2016/05/04(水) 00:26:46.45 ID:2HnXwOPY.net
- ちなみにちゃんとcrf23でエンコ後プロパティでビットレート調べて
2passエンコ登録時にそのビットレートでエンコしてる
- 1000 ：名無しさん＠編集中：2016/05/04(水) 01:38:01.15 ID:I2MMBFA3.net
- 実際問題サイズをぜんぜん揃えられてない状態で「ちゃんと」と言われましても・・・
とりあえず言えるのは、実際の平均ビットレートはx265出力(GUI)Exのログで調べるようにした方がいいってことと
ABRには多かれ少なかれ仕上がりサイズのズレは付き物なんだから、ズレたなら--bitrateの値を微調整してってこと
- 1001 ：名無しさん＠編集中：2016/05/04(水) 05:47:44.59 ID:JEe8vmea.net
- >>993
乙
- 1002 ：名無しさん＠編集中：2016/05/04(水) 09:30:32.92 ID:RFD4/mYP.net
- >>996
そういう結果になるのはみんなわかってることだけど・・・
>>998
1割以上サイズが違うもの比較しても意味ない
自覚の無いバカ、張り切ったバカほど迷惑邪魔なものは無いとは良く言ったものだ
- 1003 ：989：2016/05/04(水) 10:14:48.56 ID:2HnXwOPY.net
- 言っとくけど自分は2passが自動crf調整だと言った人ではない
実験結果から何が分かるかぐらい言われなくても分かるだろうに・・
- 1004 ：名無しさん＠編集中：2016/05/04(水) 14:09:38.05 ID:I2MMBFA3.net
- うむ、俺も似たような実験をしてある程度は現象を再現できた
>>1002
そういう結果とは具体的にどういう結果のこと？それが起きるのはなんでなのか教えて
- 1005 ：名無しさん＠編集中：2016/05/04(水) 16:12:16.98 ID:2HnXwOPY.net
- ビットレート指定はcrfよりビットレートのふり幅が小さく
HEVCの2Passも既存コーデックの2passと同じ動作だった
- 1006 ：名無しさん＠編集中：2016/05/04(水) 16:41:13.54 ID:pfZ/a3PA.net
- エンコードログに出る平均ビットレートの遷移をグラフ化するとこんな感じになった。
静止画＋動画： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3313.png
動画： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3314.png
やっぱり>>958は間違いで、crfと2passのレートコントロール手法は別物なのでは。
- 1007 ：名無しさん＠編集中：2016/05/04(水) 17:11:10.81 ID:RFD4/mYP.net
- マジレスすると、答えはこのレスに出てるのにそれすらわからず騒いでるだけ
こんなの誰が相手にする？
明らかに初歩的なことすらわかってないのにわかった気になって
わかりきってることを謎解きをやってるだけ
次スレでは、もうその話しは止めろ
- 1008 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
- 1009 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1009
274 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200