x265 rev2 [転載禁止]©2ch.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

[関連スレ]

・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/

>>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

☆☆☆☆☆
　　　　　　　　　　　　　　 /　　／　　　　　／　　　|　 　 　 ＼ ヽ
　　　　　　　　　　　　 　 /　／　 ／　　 / /　　　 ||　 |　　i　 ヽ i
　　　　　　　　　　　　　 i　/　　/　/　　/ / /　 　 ||　 ||　　|│ |ﾉｽ
　　　　　　　　　　 　 　 |//　 /　/___, -一ｧ|　　/! |ﾄ、|│　|　|　く」
　　　　　　　 　 　 　 　 |,-‐¬ ￣---┘'７ |!　 ﾊ! |,､-┼十|!　|　| |
　　　　　　　　　 , -‐ ''"　　し' '´_ ／,ィ二l |ﾄ、/!ヽﾄ､＼_ヽ!|!l　| ﾊ |
　　　　　　　,r／　　　　　　__　　 ,イ|ﾘ ヾハ! ヽ!　 ,ィ⌒ヾﾐﾘﾉ!/ﾘ　 |　☆ 自民党、グッジョブですわ。 ☆　　
　　　　　 ／ ||ヽ　　-'　　 　 ／￣ )｀　__　　　　　　|ヒﾉ:} '` ,ｲ/ |　 | 　http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
　　　 ,r '　　 ヾ､　　,-､＿___ , イ￣,r=＝-　　　　　　==-'　 ﾚ' /|　 | 　
　　／　ヽ　　　 `ーｿ　 '　|　|ﾄ､,ﾍ ′""　　　　　　　 　 "" / / ||　|　☆ 日本国民の皆様、１２月１４日（日）の
. ／　　　 ＼_　　／　　|　ﾊ　ヽ｀ﾞ'ﾍ　　　　　　 ' '__. ィ　　／ / | |　 | 　　　　『衆議院議員総選挙』に必ず投票にいきましょう。 ☆　　
　　 　 　 　 　 ／　　 /　/ |　 ヽ 川＼　 　 ヾ三ﾆ‐'′／/! |　 | |　 | 　　
　　　　　　　 /　　　 /　/ 八　 ＼川| |`ト-　..　 __ , イ‐ｧﾍ |　 | ||　 |!
　　　　　　／　　　 /　/ /　 ＼　 ＼ 「`ー- ､　　　　／ 　.〉　 ト､|　 ヽ、
　　　　 ,イ　　　 ／-─＝¬ﾆヘ､_　 ＼ 　 厂＼　厂ヽ　/!| 　 |　`ｰ＝ﾍ
　-‐ ￣ /─　' ￣　　　　　├-　ヽ＼　 ＼ﾉ＼　＼　人 ﾊ!ヽ　||　　|-┤ ヽ
　 　 　 /　　　　　　　　　 ／!‐--　| |＼ 　 ﾄ､_｀ヽ oヽ　　ﾄ､!　 ||　　|‐┤- ヽ
　　／/ 〉　　　　　　__ ／　 ├‐-　 ||　 | 川-‐　　|　|　　厂7! ﾊ!　 ├:┤　￣ヽ
　　／ / ｰ ─ 　 ￣ 　 　 　 ├‐-　ﾘ　 || ﾊ!ﾍ　　 |　|　　ト┤|/′　ヾ,┤　　　ﾞi_
　　‐ '　　　　　　　　　　　　　 〉‐-　　　 | /　/＼ .|o |　/ヽ/（′　 　 ∨　　　　 ＼
‐--─　──-r､___-､　　　　/ー_　　 　 {(　　　'´＞､! /ヽ/　　　　　　 |＼ 　 　 　 ＼

おつ

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.

今のところMuxはmp4box rev4868で快調だけど
Demuxは駄目みたい
一度Demuxすると再Muxが失敗する

mkmergeでmkvコンテナに入れてる

画質に大きな影響を与えそうなAQのデフォ値が変わったからお前ら注意な(´・ω・｀)
ttps://bitbucket.org/multicoreware/x265/commits/cbf5cad2e12b0a81d9ab1ecb8c4c325ae7b41eb3

>>9
aq-modeのデフォルトが2から1に変更されたと。
自分でビルドしてないヘタレですまんのだけど、この変更のrevっていくつなんだろ。
revの調べ方がよくわからんでござるよ。

1.4+203かな・・・
間違ってたらスマン
でもヘルプ見て、AQのデフォ値確認すればいいよ

>>11
ありがとう。気をつけておきます。

>>9
そういえばver○+△-×からハッシュ取り出す方法知らないな
いつもビルドに使うバッチには現在のver○+△-×を取得するようにしてるけど、ver○+△-×からハッシュ取り出す方法は調べないとわからん
力になれんでスマンな

ミス×からver○+△を取得する方法がわからんってことで

ttp://imgur.com/vQI2LFC.jpg
ttp://pastebin.com/dUgFScFV

hgコマンドが使える前提だけど取り敢えず書いてみたバッチ
もっとスマートな方法があると思うけど・・・許して(´・ω・｀)
てか教えて

AQ初期値の変更、強烈だな
同じプロファイル同じcrf値でも、凄いサイズが小さくなった
またcrf値見直しやｗ

--aq-mode 2
少し前からこれを付けるようにしていたから、何も気付かずに居た俺。

前スレ最後の方の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
---

>>18
乙
これ未だに分かってないのにトンチンカンな10bit批判する奴がいるから困る

> 今の段階から10bitエンコを勧めるとかそういう話ではなくそんな気もないけど
結局はこれ

今の段階から10bitエンコはおすすめだし、8bitエンコ選ぶ理由は1個しかない
それは、エンコ速度を稼ぎたいとき。

>>21
ヒント：HW再生支援

>>18
8bit接続でソフトキャリしてるとかモニタのLUTが少ない劣悪環境だと
8bitとか10bitエンコ以前に諧調性が劣るので、10bitエンコでの改善度が正しく比較できないんだよ
その点は理解してる？

君のモニターがそうなの？

>>23
もう屁理屈レベルじゃねーかw

>>23
モニタやキャリブレーション回りは正確な知識がないのであらためて勉強中だけど、
厳密に「正しい比較」ができるかどうかはともかくとして、基本的にはYUV⇔RGBの話であって、
少なくとも>>18については「劣悪環境」でも「改善されてる」ということは十分にわかると思うんだけど、違うのかな？

madVRで表示されるデバイス名でググったら、今年買ったうちのLavieノートちゃんのパネルは
　　Display Colors : 262K (6-bit)
で、PCの仕様を見なおすと
　　内蔵ディスプレイ　最大1677万色
　　（※1677万色表示は、グラフィックアクセラレータのディザリング機能により実現します。）
というイマイチ環境らしいけど、10bitエンコのほうが綺麗なのはハッキリとわかるし・・・（震え声）

あと、１つよくわからなくなった点があるので教えてほしいのだけど、10bit出力対応のグラボとモニタを使ったとして、
動画再生ソフトはどうすればその10bit出力環境をフルに活用できるんだろ？というか活用できるもんなの？
madVRとかEVR-CPとか10bit出力環境でのレンダリング回りの処理がよくわからなくなってきてしまって混乱中。

エンコした時点でバンディング低減効果があるって言ってるのにハードの話をしつこく持ち出す基地外

>>18
元が8bitの場合はどうなる？
RGB→8bitYUV420→x265_16bppの場合

>>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

つか、実際にエンコしてみりゃ8bitソースでも10bitでエンコするだけで
バンディング消えるのになんで試さないんだろう？
安いTN液晶だとダメなの？持ってないから知らないけど。

>>29
madVRが凄く優秀というのは分かった。
EVRだとどう？

>>24-26
俺はバンディング低減効果については異論ないぞ
8bitでいいって言ってる奴がいなかったっけ？
違いが気にならないのは環境による影響もありうるってこと

8bitエンコードをデコードして出力する場合、一般的なPCスケールでは16-235を0-255にするけど、
mpc-hcとかの10bit出力ではレンダラのバックバッファは16bitになってて、これを10bitに丸めて出力できるから
リニアリティが悪化しにくい
モニタのLUTが8bitだと、LCDのガンマ特性をCRTの2.2に変換する時に値のスキップや重複が
でやすく、諧調が減ってしまう
8bit LUTのモニタだとRGBや色温度・コントラスト等の設定を微調整しても結構大きく変化したりしてしまう
動画ではカラマネはあまりしないだろうけど、ソフトキャリも諧調が減る原因になる

こういったことがあるから、環境によってはバンディング低減効果が今一つに感じられる可能性があるってこと

君のモニターがそうなの？

>>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

>>33
以前6bit+FRCのモニタを使ってたけど>>18の一番目みたいなグラデーションで
バンディング状のムラを感じたから各色10bitで接続できるモニタに買い替えたよ
新しいモニタではムラはほぼわからなくなったよ

>>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

結構差が出るもんだなあ
おつかれ

アップされた他の画像も含めたヒストグラム一覧を作ってみました
ttp://2sen.dip.jp/cgi-bin/upgun/up1/source/up1133.png

こうしてみると、>>29のエンコせずに戻したのが質が低いのはEVRのせいみたいだね

ちなみに、Firefoxで表示すると元のグラデーションでも微妙なバンディングが見えてる
画像をダウンロードして他のビューアで表示すると気にならないから
Firefoxってカラマネ対応でも精度が低いのかね

PCで見るだけなら問題ないんだろうけど
他機器なりハードデコード仕様次第だろうなぁ
対応表明してるインテルがどうなるかが気にはなる

>>39
タブレットをテレビ出力して映画見る時代らしいし
対応するしないで結構差が出るかもな。

H.265とかすごい規格がでてきても
結局、見るのはアニメなんでしょ？？
　

それの何が問題なんだ

>>41
火垂るの墓ですが、何か？

>>42
アニメくらい別にDVDで十分やん

せっかくの4k 60fpsとか宝の持ち腐れやん
　

俺はアニメ見ないけど、
どうしてそう自分の価値観を押し付けるようなことをするのか不思議だ
それを決めるのは本人たちで、他人じゃないだろう

こうやって技術が向上して世間一般にも広まるのであれば、
それがどういった形態がきっかけになろうが構わないと思うんだが

アナ雪がこんだけ売れてるんだから、一般人ふくめてアニメが主流でしょうな

>>45
それはそうだけど
アニメって子供の見る物じゃない

H265とか最新のコーデックを使って
大人がアニメ見ているとか
信じられないんだけど

もっと研究用途とか、なら分かるだけど
　

映画とかは時間かかりすぎるしな
長さ的にも圧縮素材としてもアニメが一番適してる

>>47
子どもと一緒に大人がアニメ見ることは多々あるわけだが？

お前が信じられない世界が今目の前の現実だ
お前は今までもこれからも現実逃避しながら生きて下さい

実際、いい年した大人でもそうやってアニメ見てるの知ってて、
信じられないって言うのはおかしくないか
だって、見てるというそれは言わずもがな事実じゃないの

だから俺は、何が契機になろうが関係ないと言っているのに、
それはそうと肯定しつつ、また否定するお前は何が言いたいんだ

h.264とh.265の性能を比較した時アニメと実写だったら実写の方が差が出たような気もする。
アニメだと思ったより差がないと感じたな。

自分の信念以外を全否定したいだけで、コミュニケーションを取る気もさらさら無いようだし
相手するだけ無駄。
ソースは何でも良いし正直そこは個々の自由だからどうでも良い所。

否定するにしても相応の根拠なり示せば良いと思うんだけどね。
アニメ否定しているけど、肝心な本人はどう言う使い方をしているかなんて一切書いてないからね。

>>52
俺は子供じゃないから
アダルトな使い方に決まっているだろ

ハメ撮りとかだよ

10bitはじめてやってみたけど実写だと静止画にして目を凝らさないと分からん
エンコ時間が延びてHW支援が効かなくて費用対効果はいまいち
10bitを推奨してる人はアニメヲタでOK？

もういいよキチガイ

正直どうでもいい。
そろそろ別スレでも勝手に作って余所でやってくれってレベル。

8bitｶﾞｰ10bitｶﾞｰはこのスレで語るべきことだろうけど、アニメがなんたらって話は完全にスレチだな

ていうかアニメって見て面白い？？
大人になってからじっとしてアニメとか見れないんだけど

だってアニメの登場人物とか覚えても何の役にも立たないだけど
それなら資格のひとつでも勉強した方が役に立つじゃない
　
映画ならまだ話題作りに繋がるけど
アニメとか人に言えない趣味だし
　

そういう冷めちゃった系なら
ムリして2chしなくてもいいと思うよ

>>57
いや、悪いけど8bitｶﾞｰ10bitｶﾞｰも余所いけって思ってる。
x265の8bitが今どんな具合で、10bitがどんな具合って話するなら分かるけど、
ここ最近はもう「8bit vs 10bit」の話ばかりしてる。

それx265スレでやらなくちゃいけない理由あるか？
まだ発展途上のx265でやる正当な理由があったら教えて欲しい。
なんかx264スレの方にも飛び火してるし、もういい加減にしたら？ とも思う。
それでも続けたいっていうなら、色空間スレみたくなんか専用スレ作ってやってくれ。

隔離ができるならx264スレだってもちっとマシな歩みをしてるわ

仕組みとかを粛々と話すだけならいいんだが、宗教を押しつけるキチガイやそれをスルーできないキチガイ、
多様性を認められないキチガイなどが降臨するとどんな話題でも荒れるってだけだな。

そして毎回作られては落ちる色空間スレ

そんなことより、
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までとなります。

売れないからってこんなところで宣伝っすか？

実はデコード後に8bitに丸めるときにディザリングしているため、バンディングが消えたように見えているんだけなんだけどね
けど、10bitエンコは8bitエンコと比較してバンディングを小さくできるし、圧縮の効率も高いから

gimpはグラデーションをディザリングしている
mad-VRもディザリングをしていた
EVRはしていない

>>64
8k出力とかってあるけど
まだ5k 4kのモニターしかないのに
何に使うのさ

　

作るツールがなきゃ始まらない

>>66-67
レンダラの違いをなくすため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へのダウンサンプリング→エンコ
という流れでディザリングが入る（？）のと、内部での丸め誤差等の減少が影響してるという理解であってるかな？

一応>>70の「ディザリング無しでの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

どうでもいいけど
＞LAV Video DecoderでYUV→RGBしてEVRに統一したり、
面倒だからLAVの設定そのままにDirectShowSource使えばいいんじゃないの？
詳しくないけどレンダラを排除できるんじゃない？

>>72
DirectShowSourceの存在を忘れかけてた。
Lentoid HEVC Decoderとかも入れてるのでめんどいし、EVRでの見え方がわかれば十分かと。

>>73
乙

>>8bitソースについて、デコード時のディザリング無しの場合でも絵的に 16bpp（５） ＞ 8bpp（４） になるのは、
ビットレートがわからないので優位な差があるのかどうか分からないけど
一般的にはRGB変換の精度向上と圧縮率の改善した分だけバンディングはましになる

x265ってエンコーダのポスト処理でディザリングされるの？

ちなみに、多階調化のことをアップサンプリングとは言わない

アニメでよく発生するバンディングを完全に消したいのであれば、
ディザリングライクな処理をポスト処理で強めにかけましょう
圧縮率の効率を無視すれば、8bitエンコでも10bitエンコでもどちらでもいい

最近出たBPGって画像圧縮にHEVCエンコーダが使われてるらしいね
x265だと早くなるのかな

avidemuxでh265コーデックを使う方法ってありませんか？

外部エンコーダーを読み込めませんよね
　

Handbrakeでも使ってろ

>>76
x265有効化したのだと10倍くらい速かった

x265有効化ってどうやるの？
-eコマンドにx265指定しても入ってないって言われるから、ビルドからやらんといけないのかな

>>80
ビルドするの面倒だからバイナリうｐするわ
http://kie.nu/2lNt

>>81
ありがとうー
確かに速いね。デフォのとの画質の違いは俺の目ではわからない。
しかしx265ではモノクロ非対応なのね。

H.265が使えて
画像フィルターが使えるソフトってありませんか？
　

>>83
TMPGEnc Video Mastering Works ６

ffmpeg、handbrake

>>84-85
RGBの色補正とかガンマ補正ができてH265ではけるソフトが必要なのですが
handbreakだとできないことないですか？
ffmpegだとGUIがないのでいちいちエンコードしないと
できあがりを確かめられないのではないですか？
TMPGEncは試していないのですが
リアルタイムで色補正を確かめられますか？
　

>>86
AviUtl+x265guiEx

>>84 よくわからんが色補正みたいな機能とカット編集みたいな機能とエンコーダとしての機能はグローバルには別々の扱いで
それぞれに優れたソフトがあるものを一緒くたに語ろうとするから、そういうどれも大したことのないのに高いソフトが候補に上がってしまうんじゃね？

AvsP系みたいに265でもプレビューしながらフィルター掛けられるソフトがあれば良いよなー。

Aviutl

映像フィルタをリアルタイムで掛けたいなら ffpaly で再生すればいい

GIGAZINEにx265と開発中の最新版Daalaの比較が行われているけど、暗い部分以外はかなり健闘しているようだな。
ただ、だからと言ってDaalaに乗り換える意味はなさそうだが。

オーバーラップして変換するDaalaは、普通のDCTの規格と同じ解像度で比較したらおそらくすごく遅い

ここのstockholmみたいなザラザラした映像をのっぺりさせずにエンコードするのはどうしたらいいのん？
http://media.xiph.org/video/derf/

x265スレで言うことじゃないけど、そういう用途ならx264勧めるな
x265は--tune grain使ってものっぺりする気がするけど、x264はデフォルト設定でもそれなりに残る気がするんだよね

>>95は>>94宛

>>95
気がするってみみっちぃビットレでpsy-rdoq 30は無理だぞ

>>95
うん現状ではx264でエンコードしてる

簡単に検証してみた
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のグレインや細部を保持しようとして色々パラメーター弄ったけど現状では無理と判断したな
当然のことだけど弄れば弄るほど遅くなっていくしね

自分としてもグレインや細部を綺麗に保持してくれるパラメーターがあるのなら教えて欲しい

グレインや細部を保持しようとしないから非可逆で高圧縮率なんじゃないの
それを気にしだしたら究極的には可逆になるんだから

>>99のx265のlumaを見ると、グレインに関する情報がごっそりと欠落しているようにも見えるけど
時間不変に近い建物や川面のディテールはしっかりと保持されてるともいえるので
高圧縮のコーデックとしては優れているといえるんじゃないでしょうか

>>99みたいな検証する人がPSNRとかSSIM使わない理由って何なの

みみっちぃビットレとは言うが
x264では細部を残せるビットレートでもx265だとぼかされるのはなぁ……
何にビットレートを割いてるんだよって思う

だよなぁ
本当細部残したい派にはHEVCは詐欺だわ
正体見たりなんとかだわ

x264は出来てから、10年経つんだぜ？
さすがに生まれたてのx265と比べるのは、可哀想ってもんだ。

H.264だって出来た当初はHigh Profileは無くて、MPEG-2と比べて
HDじゃ画質悪いし使えねーって言われてたんだぜ。
そのせいで、初期のBDはみんなMPEG-2使ってた訳で。
High ProfileのBDが市場に出たのは2006年頃だっけ？
H.264の規格が出来たのが2003年。

一朝一夕には出来んよ、もっと長い目で見なきゃ。
さすがに、今のタイミングで詐欺はねーだろ、詐欺は。
5年経ってダメなら、それは詐欺だろうけどさ。

既にh264がある世界なのに可哀想って何言ってるんだろ

だからx264が生まれた頃はすでにMPEG2のある世界だったんだよ
同じことだ

じゃぁ商品化レベルにはまだ2年もかかるんだ

そんなもんだろうな

clよりgccのほうが速いな

SSE4向けに高速化コードが導入されてってるけど
うちのCPUにはSSE4が無いンゴ

>>111
そんなCPU投げ捨てろ

今年出るはずの新APUを狙ってるンゴ

すいません。編集初心者です。
30分の動画編集で出力時
ｘ264　で10分
ｘ265　で1時間
も違いが有ります。　ｘ265での編集を途中でやめた場合
265　STATS　CUTREE　というわけの分からない物ができ動画になりません。
すいませんが何が間違っているか宜しくお願いいたします。
ついでにｘ265のほうが優れているんですよね？

100％純粋にスレが違う

時間がかかるのはそんなもん。
出力を途中でやめた場合も.265をL-SMASHでmuxすればmp4に出来る。

>>114
>>104
らしい
肌のこまかいシミや毛穴にこだわるなら使わないほうがいいかも

>>116
そうですか時間はしょうがないのですね。
mp4できました、ありがとうございました。

>>117
細部残したいなら264はやめた方が良いよ

逆だろ

>>120
265も264も細部保持には向いていないって意味だろｗ

http://x265.readthedocs.org/en/default/cli.html#cmdoption--interlaceMode

1.4+263だとまだ警告出るし、helpにもオプションが書かれてないけど、
ドキュメントのほうではいつのまにかインタレのEXPERIMENTALって取れてるのか。
ドキュメントで
--interlaceMode
になってしまってるのは間違いだね。使ってみたらエラーが出た。
どこで変わったのかは知らんけど、実際には--interlace。

1.4+285 だと特にエラーでないけどhelpに出ない

x265(1.4+285)のcrf23とx264(r2491)のcrf26をmediumで比較してみた
(どちらも3Mbpsくらいになるようにcrfを調整)

このスレじゃx265は細部保持に向かないって評価だけど
広いグラデーション部は細部(グレイン)を保持しなくて
ある程度にわたって構造のある部分は保持する
という挙動でモスキートノイズも少ないし、輪郭周りの荒れも少ないから
ぱっと見の印象は悪く無いと思った

ただx265が15.7fpsでx264が53.5fpsで3倍以上
速度差があったからもう少し速くなってほしい
CPUは[email protected]

試しに速度もビットレートも同じくらいになるように
x264をcrf25でslower(18.6fps)にしてみたらx264も
輪郭周りの荒れは改善したけどx265ほどではなかった

モスキートノイズ嫌いな自分にはx265はかなり魅力的

必死だなｗ

「必死だな」というセリフに「ｲｯﾃﾖｼ」並の化石臭を感じる

>>124
そのグレンノイズの再現性を求める人もいるのが難しいところ。

>>127
そうね、自分の望む進化の方向に進まないのは残念だろうね
分野は違うけど自分もそういうのあるし
でもx265はまだ変化する可能性があるだろうから
希望はあるよね

>>124
265は輪郭周りがきれいだから滑らかできれいに見えるね。
ノイズリダクションするならx265のほうがいいと思う。
ただ暗闇で黒いものが動くシュチュエーションで、動く黒い物体が破綻しやすいのが気になるかな。
ビットレート盛っても8bitだと厳しい。
と言ってもそういう場面はたまにしかないし、10bitならなんとかなるけど。

ffmpegでH.265で出力したいのですが
mkvとかmp4ではけますか？
どういうコマンドライン使えば良いですか？
黎明期なのかあまり情報がかからないので教えてください
　

>>130
ttps://trac.ffmpeg.org/wiki/Encode/H.265

>>131
ありがとうございます。
早速試してみたのですが
もとはビデオカメラで撮影したH.264動画なのですが
屋内で撮影しているため、かなりノイジーな動画だったのですが
H.265にするとそのノイズがなくなってしまったのですが
これは一体どういうことでしょうか？
H.264再圧縮だとこういうことはないのですが
　

145MBの3分の動画が9.6MBになってしまいました
でもクオリティーは下がるどころか
なぜかノイズが消えてむしろ上がっています。

エンコード速度はH.264と大差ありません。

こんなもんなのでしょうか？
　

そんなもんだからさっさと消えろ

Death-gar!!!!!!!!!

revがとうとう400超えたぜ

revってーかdistance・・・

>In 1.4 there also appeared an incomplete analysis re-use feature.
>This will be completed and further improved in the coming weeks.
とはなんだったのか

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.

誰かまともなマシンを買い与えてあげるべき

AMDだったらK10以前、IntelだったらPrescott以前か
さすがに買い換えモードだな

総合セキュリティ対策ソフトの常駐と各種ソフトのアップデート確認だけで起動で苦しむPCだろうな

SSSE3未対応とか、そんな化石捨てちまえ。

k10はまだまだ現役

実際、SSE2でも十分な関数も多いし、そっちの最適化を頑張ってくれたらいいんじゃないか

Baka Encoder
ttp://x265.ru/en/baka-encoder/

チルノ？

日本語がやや面白い

1.5はpsy-rdデフォルトになるみたいね

x265でインタレ保持するときってAvisynthでフィールド分離して渡すやり方であってる？
なんかすげー変な作り方しないとまともに作れないんだが。

そのまま渡せばいいと覆う。

今のx265ってインタレ保持できるの？
ドキュメントは古いオプション（--interlaceMode）のまま放置されてるし、ヘルプにも--interlaceは出てこないけど。

x265 --log-level full --help

>>153
うあああ、--log-levelって--helpにも作用するのか・・・知らなかった。ありがとう。

ただ、やってみるとわかるけど、インタレ保持エンコしても再生時に変になるよ

H.265にはMBAFFも無いし、インターレースに関してはH.264より退化していると思う

>>155
再生時変にならないように作ったら150の方法になったんだけどこれって正しいの？って事です。

60iの実写アイドルDVDとかインタレ解除エンコしてみたけど、お肌の質感が失われてのっぺり画質になってもた

265は細部保持には向かない
素直に264使え！

>>157
ドキュメントの説明には
　　> 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.
とあるからフィールド分離して渡せってことだとは思うんだけど、
前に色々試したら結局うまくいかず、エンコード方法が悪いのか
デコーダが悪いのかもよくわからず終わった覚えがある。

今ん所デコーダが悪い
H265のインターレスソースをちゃんと表示してくれるデコーダがない

実写はx264
アニメはx265って感じやね

何言ってんだこいつ？

俺設定が１つしかないんじゃね？
>162 にはソースに合わせて設定変えるっていう発想が抜け落ちてんだよ

実写はxvid

「SDなら」なら同意

実写はエンコしないが最強、異論は

全部ソースが最強だろ
エンコなんて無駄

お薬多めに出しときますね。

おお…

「つける薬」が見つかったのだろうか・・・

ソースもエンコされているんですがそれは・・・

そーっすね(∀｀*ゞ)ﾃﾍｯ

またavsは読めないん？

avs4x265 を使えばフィルタかましたのをx265に渡してくれる

avs2pipemod使えばいいだけやん。

1.5リリースおめ

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).

>>178
もう本格的に移行してもいいレベルですな

ボケボケ克服したら起こしてくれ

じゃ、今じゃん

UMS+Androidのストリーム再生が、トラスコ無しで出来る事が分かったので、
SDサイズの物は、x265を試験的に使い始めた。

SDサイズなら、slowベースのプリセットでも、
50〜60fsp位出るんで、まぁ常用範囲。
720p以上になるとそれなりに時間かかるし、
今の画質見ると、まだ当分264かも。

16bppと8bppとは違いは何でしょうか？

>>183
10bitのH.265 Main 10 Profileで出力するのが前者で、8bitのMain Profileが後者

>>184
お早い返答感謝いたします

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

cpu何つかってんの？

うちは全然遅くてまだまだ厳しいわ

ver1.5現在、Haswell世代でAVX2の有無でどれだけ差が出るか知りたいな
手元にHaswellコア無くて辛い

CPU書き忘れた!
FX-8350をOCして4.3Gにしてます。
AVX2が無いからその分遅いハズorz

x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1

G1820だと再生すら厳しいわ

適当にベンチ 詳細はテキストに
ソース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

>>192
×http://www.dotup.org/uploda/www.dotup.org5392489.txt
○http://www.dotup.org/uploda/www.dotup.org163738.txt

>>192
乙
slow一つでいいからx264のも貼ってほしいな。
やはりx264との比べたほうが速度の感じが分かって嬉しい

mediumの時点でx264のSSIMを超えるので、x264との速度比較データとしては既に十分でしょ

テキストのほうにはちゃんと書かれてたのね。
確認不足でしたは。

192で興味がわいたからやってみたけど、かなり早いし底力があるね。
（実写ソース）1400x1080をx264の720p crf24と同じぐらいのサイズになるようにcrfを調整してやってみたけど
結構いいぐあいにエンコできた（preset：faster）。
SIMM値とかは全然見てないけどかなり凄い。

ボケボケ直ったら起こして

底力？結構いいぐあい？かなり凄い？

おまえ何言いたいねん

俺もやってみたけど
ボケるね

fasterのオプションを確認したら
動き検索がhexとかb-adaptが無効とか
使い始めたころのx264を連想した。

まだまだ実用には遠いなあ

「ボケる」「細部が保持できない」って言ってる人は、具体的にどれくらいのことを気にしてるんだろうな。
>>99みたいな例はわかるけど、「これが俺の気にするx265のボケだ！」っつう
具体的なサンプルを出してみてほしいとこだ。

頭大丈夫か？

x264も2コアとか1コアの時は少しプリセット詰めるとやってられなかったし
これも実用ならHBMや6コア〜待ちかなぁ

>>203
SD解像度の昔のアニメみたいなグレインが多くて
かつ、背景が細かく書き込まれた作品だと背景がボケちゃうってことかと。
1.5で試した感じだと問題ないし、実際見比べても元のTSに近いのはHEVCだと思うけど。

>>203
今のHDアニメでも背景の模様がボケるし、実写でも背景の陰影？みたいな色の濃淡がボケる

x264と同じぐらいビットレート盛るとパッと見同じぐらいの画質になるけど>>99の空のような平坦な面では四角くくりぬかれたようにツルツルの部分がある

x265はただでさえ遅いのにx264と同じぐらいビットレート盛っても平坦な面ではx264が画質が上、平坦な面以外ではx264と同等以上、総合的にみてx264が上って判断になる

それに全く縮まないなら使うメリットを見いだせない
x264と同等画質で6〜7割のビットレートになるなら使う意味を見いだせるけど

以上、あくまでも個人の意見だから人によって差があると思う

書き忘れたけど
ver1.4と比べてver1.5は若干画質が良くなってる気がする
psy-rdがデフォルトで有効化された影響かどうかは知らないけど

今自分のレス見返したけど陰影って影のことだよな・・・
影じゃなくて壁のシミ等の細かい模様と読み替えてくれ

ビットレート盛ってエンコしても細部が潰れるだけじゃなく全体がボケる
背景の潰れ具合とかを見てみるとノイズフィルタかけた時のような丸まりがある

デブロッキング・フィルタの調整とかしても？

そもそも0:0でいじってない

いや、いじれよｗ

何でデフォで0:0なのにいじる必要があるのか
意味が分からん0がデフォって普通に考えたら一番影響の少ない値って考えそうなものだろ

そう考えるのはいいけど、事実問題でるなら弄るべきじゃないの。
デフォ値はあくまで標準的に今現在は差し障りの無い数値であって、絶対的な保証をしている物でも無いし。

とは言っても「だからこそ」まだ実用では無いとも言えるのかもしれないけどなｗ

そこ弄ったらボカされなくなるの？

>>215
確かに
また機会があればやってみます

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/

>>215
けどまぁ、完成度が高いと言われているx264ですらそこまで賢くはないから
それを求めるのは酷な気がする。

多数ノードに関する大変更が入ったね

>>220
それはどんな変化をもたらすの？

ボケボケ直ってるね

ところでこの板ないしスレの移行先の話って出てきてるの？

>>222
最近手を出してなかったがどのあたりのrevからボケてて,いつ治ったんだい？
自分で検証する時間がなくて。
良ければ教えて下さい

ボケボケ言ってるのはAVCでもかたくなに8x8dct使わなかったのかな

改めて見てみたけど、1080pとか4kクラスの高解像度だとほぼ問題ないけど
480pとか、低解像度だとやっぱ背景の細かいところ（壁のシミとか、木の筋とか）が明らかに潰れるかな

>>226 ・・・いや、まさかと思うけど
それ480の実サイズ（再生ソフトの画面サイズを480）で見てるんだよな？

>>227
ドットバイドットと全画面両方でx264とx265 720x480（par10:11　654x480表示)を24p変換で見比べ

x264はcrf19からcrf22 subme9からsubme11
x265はcrf19から22 subme3からsubme7

crf22以下で圧縮重視ならx265でいいと思うけど、
より忠実に圧縮するような目的だと、x264 subme9以上の方が明らかに元動画に近く見える。
まあ元の素材によりけりなのかもね

まあ壁のシミなんて見ないから気にはならんけどねw
ノイズが減って見やすくはなるし、どっちでもいいとは思うけど。

バカだコイツ

MPEG2→H264のときも最初は十分なビットレートではMPEG2のほうが画質がいいとか言われてきたし、
これからのエンコーダーの進化に期待ですな

>>228
またcrf君かよ、、、
何度論破されてもしつこいな、この馬鹿は

>>232
画質比較するときのレギュレーション作ってくれるとありがたいな。

>>232
x264スレでもかつて似た流れがあったけど、基準と実例を上げてくれないと誰も賛同しないと思う

俺としてはエンコーダーが全く違うんだし必ずしもビットレートを揃える必要は無いと思ってる
特に個人的なx265のメリットはx264と比べて縮むってことだからcrfだけ合わせておいて調べるのもアリだと思う

例えばx264比で7割のサイズになれば十分って考えるなら10:7のビットレートでエンコして見比べたりSSIM見たりするのはアリだと思う

>>234
エンコーダーが違うからこそビットレート揃えて比較するんですけど・・・
小学校理科レベルの話だぞこれ。
「crf値を同じにすればいいや」と発想した時点で、小学校理科からやり直せと

それと、「x265のメリットはx264と比べて縮む」ことをメリットとするためには
画質を同じにして両者を比較しなければならないでしょ？
でも画質を定量的定性的に同一とすることは困難なわけ。

ならば、同じ課題を和文和訳して、
「x265とx264でのエンコ後ファイルサイズを同じにして、両者の画質の優劣を肉眼で比較」すればいい。
ファイルサイズを(ほぼ)同一にすることは簡単に出来る。

そもそもcrfてx264とx265の基準は違うよね？
x265でもrev変わる度にコロコロ基準が変わってたんだから
素人考えだけと2passでビットレート揃えて比較した方がいいと思うわ

crf君って誰の事？

>>235
いやサイズ合わせて比較はしたけど、売りは半分のサイズで同一の画質だから
そういう比較ってあんま意味ないと思ったんだわ。
それにcrfの値も17から22の複数の範囲で比較してるから、同じにして比較しただけってわけじゃない。
まあ同サイズでも差は縮まれど、若干ボケてるのに変わりはないけど。

いずれにせよ今のところ>>228のとおりの感想で変わりはないかな。

一気にAVX2最適化が入った

まだまだいろいろな面で実用的では無いのは間違いない

あと数年して使い物になるようになったらノコノコやってくることにする
MPEG-2→Xvidが2007年
Xvid→H.264が2009年
H.264→H.265が2017年ぐらいに使い物にやるといいね

使いこなせないとかすげー滑稽烏骨鶏

登場時の完成度でいえば異次元（良い）だけども＞x265

画質気にしなければサイズ縮むし良いけどなx265

バカばっか

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の方がかなり縮んでるな・・・。

x265は高画質の対応がまだまだ進んでない印象

十分に進んでるよ

ビットが足りないときのごまかしはx264に分がある

ビット振った時の再現性もまだまだ負けてるよ
オプション盛っても全然補填出来ていない

やっぱ犯罪者の方が技術は上なんだな

x264のqcompはx265にはないのでしょうか

>>251
聞く前に少しは調べろよ。
　　ttp://x265.readthedocs.org/en/default/cli.html

ありがとう
優しいね

1.5+175-45deb0125890にして気付いたけど
psy-rdoq指定してるのに0になる
バグかな

help見た
ごめんお騒がせ

x265ってvfrエンコ出来るのかな
調べても見つからない

そもそもfpsという概念なんて無いし