x265 rev1

ここはx265のスレです

・コマンドラインを使用している事を前提とします
・AviUtlやx265GUIExなどの話は専用スレへどうぞ

[本家]
http://x265.org/index.html
https://bitbucket.org/multicoreware/x265/wiki/Home

[バイナリ]
https://x265.cc/

素敵なテンプレ草案募集

x265GUI専用スレだれか作って

>>1乙パイ
　　　 　 　 　 　 　 　 　. ===.､＿＿___...　i　　　　　　 　 　 .ト､___　　　..-‐‐
　　　　　　　　　　　 ／: : : ／: : : : / : : __}　　　　　　　　 　 7: : : :７´: : : : :
　　　 　 　 　 　 　 /: : :i／: : : : :／｀￣ .ﾉ　　　 　 　 　 　 .ｨ: : : :./: : : :..:,: :
　　　　　　　　　　 ; : : /:..:___: :./.　｀ヽ　 　 　 　 _..　-‐　　/: : : : i{: : : : :.{: :
　　　　　　　　　　/: :./:／: : |/　　　　｀　　　　´　　　　　/: : : : : |:i: : : : :|: :
　　　 　 　 　 　 / : .ｨ´i: :..／　　　　 　 　 　 　 　 　 　 /: : : : : : |: : : : : |: :
　　　　　　　　　i: : : :i: _／　　　　　　　　　　　　　　　　ト.､ : : : : |: : : : :..|: :
　　　　　　　 　 fi＞　´　　　　　　　 　 　 　 　 　 　 　 ﾍ: : ＼: :..|: :;: : : : : :
　　　　　　　　 ´　　　　　　　　　　　　 ／　　　　　　　　 ＼: :.｀¨: :..i: : :,: : :
　　　　 rｯ:.:.;　　　　　　　　　　　　　,　　　　　　　　 　 　 　 ヽ: : : :..{: :..|: : :
　　 　 .i.:.:.ノ　　　　　　　　　　　　 /　　　　　　　　　　　　　　 ∨: : ∨ |: : :
　　 　 .{　　　　　　　　 　 　 　 　 ;　　　　　　　,..:.:.:.:.:.:、　 　 　 ',: :..∧: : : : :
　　　　　　　　 　 　 　 　 　 　 　 i　　　　　　　:.:.:ゞﾂ:.:.:　　　 　 .}:.:.__∧: : : :
　　　 .ri　　　　　　　　　　　　　　{　　　　　　　ヽ:.:.:.:.:.ノ　　　__　i:.（__ .＼: : :
　　　 i´∨　　　　　　　　 　 　 　 ',　　　　　　　　　　　　 __/　 ｀ヽ..」ヽ　 .Ｙ: :
　　 ./　.iﾍ　　　　　　　　　　　　　　　　　　　　 　 　 　 Ｙ　 ＼　　　￣｀　 ∨
　　∧ ./ ./＼　　　　　　　　　　　　 ､　　　　　　 　 　 i´＼ 　 ＼　　　　　 .}:
　　i. У /　 /　７ーｒ=､´　　　　　 　 .ヽ　　　　　　　　＞､. ＼　　　　　　　 i:
　　i:.ヽ 　　 {　 /:.:.:/ ./　 　 .;　　　　　　｀　ー ‐--‐..┤ }._ヽ　　　　　　　 , : :
　　ヽ:.:.＼. 　　´￣ ／＼ 　 .i　　　　　　　 ，＜: : : : :.ﾍ..＿__　　　　 　 ／: : : :
　　　.＼:.:.｀ー--.:ｲ: : : :..:ヽ　　　　　　 ＜: : : : : : : : : : :.,: : : :￣¨¨¨f≦: : :

【2016】 H.265/HEVC Part3 【7680x4320】
http://toro.2ch.net/test/read.cgi/avi/1380198926/

速度面の最適化ってまだなんだろうか

まだだよ

AviUtl + 自動フィールドシフト + x265 利用時の設定私的メモ
自動フィールドシフトが何なのかまったく不明かつ利用方法が不明
自動フィールドシフト 高速化版+12 ttp://rigaya34589.blog135.fc2.com/blog-entry-432.html を使用中

自動フィールドシフト(afs)には出力プラグインが同(afs)に対応している場合に使用可能なプラグイン(afs.auf)と
注．忘れずに出力プラグインの設定タブにてasfを使用するにチェックを入れること
出力プラグインが同(afs)に未対応な場合24fps固定などに利用するビデオフィルター版(afsvf.auf)の2種類があります。
注．ビデオフィルター版(afsvf.auf)利用時、素通しフィルター(trans.auf)が編集時に必須な模様(元の自動フィールドシフトファイルから取り出して来る事)

今回はx265+x265guiExベータ版でafsの利用が可能なので自動フィールドシフト 高速化版(afs.auf)のみをAviUtlのフォルダーに入れてあります

自動フィールドシフトの設定は ttp://www.geocities.jp/aji_0/afs.html を参考にすると混乱しました
120fps出力なるものは存在しません
したがって設定は、フレームレートの変更．．．なし、インターレース解除．．．自動フィールドシフト
出力プラグインx265guiExベータ．．．asfを使用するをチェック、以上。

同設定でのエンコサンプルMediaInfo情報(フレームレートに注目！！)
全般
完全名称 : D:\エンコワーク\ガリレイドンナ＜ノイタミナ＞\ガリレイドンナ＜ノイタミナ＞　#05 13年11月15日_HD7.afs.na.mp4
フォーマット : MPEG-4
プロファイル : Base Media / Version 2
コーデック ID : mp42
サイズ : 121 MiB
ながさ : 23分 0秒
OBR モード : VBR モード
オーバルビットレート : 736 Kbps
エンコード日 : UTC 2014-01-24 21:04:46
タグ付け日 : UTC 2014-01-24 21:04:46

ビデオ
ID : 1
フォーマット : HEVC
フォーマット/情報 : High Efficiency Video Coding
コーデック ID : hvc1
コーデック ID/情報 : High Efficiency Video Coding
ながさ : 23分 0秒
ビットレート : 588 Kbps
幅 : 1 440 ピクセル
高さ : 810 ピクセル
解像度 : 16:9
モード : VFR モード
フレームレート : 24.544 fps
最小 : 14.985 fps
最大 : 29.970 fps
ビット/(ピクセル*フレーム) : 0.021
ストリームサイズ : 96.8 MiB (80%)
エンコード日 : UTC 2014-01-24 21:04:46
タグ付け日 : UTC 2014-01-24 21:04:46

同ログ(mux-remux省略)crf 23
----------------------------------------------------------------------------------------------
[D:\エンコワーク\ガリレイドンナ＜ノイタミナ＞\ガリレイドンナ＜ノイタミナ＞　#05 13年11月15日_HD7.afs.na.mp4]
----------------------------------------------------------------------------------------------
auo [info]: NeroAacEnc で音声エンコードを行います。 Q-Based AAC 160~kbps
auo [info]: converting YUY2 -> i420p, using SSE2 AVX
auo [info]: x265 options...
--input-csp i420 --crf 23 --keyint 300 --input-res 1440x810 --fps 30 -o
"D:\エンコワーク\ガリレイドンナ＜ノイタミナ＞\ガリレイドンナ＜ノイタミナ＞　#05 13年11月15日_HD7.afs.na.265" "-"
yuv [info]: 1440x810 30Hz C420, unknown frame count
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: HEVC encoder version 0.6+322-7cd3a3195598
x265 [info]: build info [Windows][MSVC 1800][64 bit] 8bpp
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames : 13 / 4 / 2
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 60 / 2 / 2
x265 [info]: Keyframe min / max : 300 / 300
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-23.0 / 1.0 / 1
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / refs : 1 / 1 / 3
x265 [info]: tools: rect amp rd=3 lft sao-lcu sign-hide
x265 [info]: frame I: 465 kb/s: 8545.91
x265 [info]: frame P: 33404 kb/s: 609.02
x265 [info]: frame B: 2 kb/s: 911.52
x265 [info]: global : 33871 kb/s: 718.00
x265 [info]: 1230 of 33404 (3.68%) P frames weighted
encoded 33871 frames in 5027.94s (6.74 fps), 718.00 kb/s
auo [info]: drop 7488 / 41359 frames

auo [info]: x265エンコード時間 : 1時間23分48.1秒

参考、ほぼ同じ設定でx264でエンコ(再生時画像ドロップ発生)
全般
完全名称 : D:\エンコワーク\ガリレイドンナ＜ノイタミナ＞\ガリレイドンナ＜ノイタミナ＞　#05 13年11月15日_HD_x264_crf23_afs.na.mp4
フォーマット : MPEG-4
プロファイル : Base Media / Version 2
コーデック ID : mp42
サイズ : 210 MiB
ながさ : 23分 0秒
OBR モード : VBR モード
オーバルビットレート : 1 277 Kbps
エンコード日 : UTC 2014-01-24 21:43:35
タグ付け日 : UTC 2014-01-24 21:43:35
ビデオ
ID : 1
フォーマット : AVC
フォーマット/情報 : Advanced Video Codec
プロファイル : [email protected]
CABAC : はい
RefFrames : 4 フレーム
コーデック ID : avc1
コーデック ID/情報 : Advanced Video Coding
ながさ : 23分 0秒
ビットレート : 1 128 Kbps
最大 : 6 626 Kbps
幅 : 1 440 ピクセル
高さ : 810 ピクセル
解像度 : 16:9
モード : VFR モード
フレームレート : 24.544 fps
オリジナル : 29.970 fps
最小 : 14.985 fps
最大 : 29.970 fps

ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 ビット
スキャンの種類 : プログレシッブ(PPF)
ビット/(ピクセル*フレーム) : 0.039
ストリームサイズ : 186 MiB (88%)
使用したライブラリ : x264 core 140 r2377M+r794[x64] release2
エンコードライブラリの設定 : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / fade_compensate=0.00
/ psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6
/ lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=1
/ b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0
/ qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

エンコード日 : UTC 2014-01-24 21:43:35
タグ付け日 : UTC 2014-01-24 21:43:35
matrix_coefficients : BT.709

------------------------------------------------------------------------------------------------------------------------------
[D:\エンコワーク\ガリレイドンナ＜ノイタミナ＞\ガリレイドンナ＜ノイタミナ＞　#05 13年11月15日_HD_x264_crf23_afs.na.mp4]
------------------------------------------------------------------------------------------------------------------------------
auo [info]: NeroAacEnc で音声エンコードを行います。 Q-Based AAC 160~kbps
auo [info]: converting YUY2 -> nv12p, using SSE2 AVX
auo [info]: x264 version: core:140 r2377M+r794[x86-64] release2 --bit-depth=8 --chroma-format=all
auo [info]: x264 options...
--crf 23 --input-res 1440x810 --input-csp nv12 --fps 30000/1001 -o
"D:\エンコワーク\ガリレイドンナ＜ノイタミナ＞\ガリレイドンナ＜ノイタミナ＞　#05 13年11月15日_HD_x264_crf23_afs.na.mp4" "-"
raw [info]: 1440x810p 0:0 @ 30000/1001 fps (cfr)
mp4 [info]: audio muxing feature is disabled.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 3.2
x264 [info]: frame I:434 Avg QP:20.20 size: 59498
x264 [info]: frame P:12325 Avg QP:22.83 size: 10712
x264 [info]: frame B:21112 Avg QP:24.39 size: 1741
x264 [info]: consecutive B-frames: 10.0% 17.1% 11.0% 61.9%
x264 [info]: mb I I16..4: 23.4% 63.3% 13.4%
x264 [info]: mb P I16..4: 3.7% 5.6% 0.6% P16..4: 32.9% 5.6% 4.1% 0.0% 0.0% skip:47.5%
x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 20.4% 0.6% 0.1% direct: 0.4% skip:78.2% L0:37.9% L1:61.1% BI: 1.1%
x264 [info]: 8x8 transform intra:58.1% inter:84.2%

x264 [info]: coded y,uvDC,uvAC intra: 37.2% 60.1% 18.7% inter: 5.4% 10.6% 0.2%
x264 [info]: i16 v,h,dc,p: 28% 27% 9% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 24% 20% 30% 4% 4% 4% 5% 4% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 19% 17% 5% 7% 8% 6% 6% 4%
x264 [info]: i8c dc,h,v,p: 52% 21% 21% 6%
x264 [info]: Weighted P-Frames: Y:6.4% UV:4.0%
x264 [info]: ref P L0: 64.2% 10.2% 17.6% 7.4% 0.6%
x264 [info]: ref B L0: 85.6% 12.1% 2.3%
x264 [info]: ref B L1: 94.6% 5.4%
x264 [info]: kb/s:1377.52

remux [100.00%], 190429/190429 KiB, 1088170 KiB/s, total elapsed 0:00:00

encoded 33871 frames, 38.85 fps, 1377.52 kb/s
auo [info]: drop 7488 / 41359 frames
auo [info]: x264エンコード時間 : 0時間14分32.0秒
auo [info]: timeline editor でmuxを行います。映像: on, 音声:off, tc: on, 拡張モード:なし
auo [info]: L-SMASH remuxer でmuxを行います。映像: on, 音声: on, tc:off, 拡張モード:なし
auo [info]: 総エンコード時間 : 0時間15分 0.5秒

コマンドライン専用か、間違えた。ｗｗ

ブログでやれ

長い上に無意味な上にスレチとは

ワザとやってるんだろうな、ただのキチガイだよ

このすれ腐ってやがる、まだ早すぎたんだ

pdfのGuideでは--input-depthは10or16ってあるけど
実際16で読み込もうとすると10 or 12って警告されてしまう
16では読み込めないのかな？

ここなら流石に次世代地上デジタル放送についての妄想を延々と垂れ流すのは来ないよな

たとえば?

NGワード：4k,bd,dsd,地上,dsd

あれは専門板のキチガイのテンプレに完全準拠してたな
今頃なにしてるんだろうか。ピュアAUで長文コピペでも貼り付けてるんだろうか

他はともかく4ｋをNGだと弊害が酷そうなもんだが

ＮＧ信者なバカはほっといてやれ。そいつが話題に参戦しないだけでスレが正常運行するんだし

連日のようにrevが上がっていくのが面白い

720P
http://trailers.divx.com/hevc/TearsOfSteel_720p_24fps_27qp_831kbps_720p_GPSNR_41.65_HM11_2aud_7subs.mkv

1080P
http://trailers.divx.com/hevc/TearsOfSteel_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11_2aud_7subs.mkv

4K
http://trailers.divx.com/hevc/TearsOfSteel_4K_24fps_9500kbps_2aud_9subs.mkv


H.265でエンコしてあるんだがこれすごいぞ、フリーソフトのBlenderで作った奴

いきなり変なの沸いててワロタ

>>28
ブラウザで開いてもMPC-BEで開いても音声しか流れてこないんだがどうなってんの?
新手のマルウェア?

>>30
普通にHEVCなDivX動画でしょ
そんなのはURL見ればわかるし、そもそもここH265スレだし。

だから音声しか流れないんだつて。

音声しか流れないとマルウェア扱いなの？
再生環境を疑ったりしないわけ？

前はNightly Buildsで再生できたけど今は正式版でもOK

>>32
うん。100％お前が悪い。

アホには再生できないアホウェア

(アホには真似できないsage)

VLCで再生できるよ

つかブラウザで再生できない時点でゴミじゃん。

お前の脳みそがゴミなんでしょ

まさかブラウザで再生してるとは思わなかったわ
馬鹿すぎる

再生環境を制限される動画ファイルはゴミ確定。
これは4K8K放送が始まっても絶対に流行らない。

世に出た当初、専用再生ボードがなければ重くて再生できなかったMpeg2はゴミですね
世に出た当初、ブラウザで全く再生できなかったH264はゴミですね。
ID:f4/hifUK、ID:Z3SaDVKUもついでにゴミですね

じゃあゴミ確定でいいからお前は使うなよ
スレから消えればお前も皆も幸せ

つーかスレが立ってそろそろ1週間でまだ45ﾚｽとか勢いなさすぎｗ
早々にDAT落ちしたりしてな。

56 名前：名無しさん＠編集中[sage] 投稿日：2013/09/10(火) 13:18:19.37 ID:xHNp2/yQ
56

x265の開発のほうは凄い勢いだけどね

今日の更新で、今までオプション設定より明らかに低品質になってしまっていた
10bitエンコが、ちゃんと綺麗にエンコされるようになった

10bitエンコってどうすれば出来るの？

色空間が10bitな動画を用意して
x265のオプションに -input-depth 10を付記する

ま、一番楽チンなのは、Aviutlとx265GUI使うこと

モバイルで大半のメーカーがVP9ハードデコードサポート決定
Youtubeは既にサポート済み
chromeと近いうちにfirefoxがサポート
なんとも微妙な25%の削減でしかない

家電以外無理じゃねーかとは思う

画質とファイルサイズに感動している
糞遅いけど消すか残すか微妙なアニメが綺麗な映像で小さくまとまって大満足
ビルドによって色々あるみたいだけど

そこまでして残したいアニメとは一体。

そんなの人によって違うんだから

>>52
ファイルサイズを小さくできるから、
残すか残さないか微妙なアニメも残しておけるんだよ

エンコ時間かかるのは結構どうでもいい
2ndPCで放置エンコしとけばいいだけだから。

エンコにも金がかかる

>>49
初心者でスマンがAviutlって10bitの映像をそのまま読み込めるの？
てっきり8bitに戻して読み込まれるのかと思ってた・・・何も8bitに変換して読み込みますってソースみたわけじゃないけど

Aviutlは動画を読み込むと内部で48bit化して、
48bitの状態で各種のフィルタを掛ける仕様なんだよ
そして出力する直前に出力フィルタに応じて減色する。

x265GUIには10bitへ減色する機能がついてるから、x265.exeに10bit動画を渡せるんだ

各バージョンの画質向上の推移を具体的に表にしてくれよ
誰か

おおかた同じソース同じエンコ設定でEXEバイナリだけ変えてPSNRとSSIMで比較するとかじゃね。

今のところ、

本気モードのエンコ→X264 10bit+16vbitDitherAvitynth
残すかどうか微妙な作品→X265 8bit

に落ち着いてる

>>57
解説ありがとん。またひとつ勉強になったわ

Aviutlで死ぬほどエンコしたけど(設定方法がわからないほかで)
我が家のPCが腐っていない前提だけど
長時間エンコするとmux-remuxが出来ないとか
PC再立ち上げで出来たりとか不安定
アニメ3本エンコしたら基本PC再立ち上げな感じ
Aviutlのオートフィールドシフトにお任せするといい感じに
15~30フレームに間引きしてくれる
ファイルも小さくなる
24フレーム固定よりスムースな映像な気もする
crf23でエンコしてるけどx264と比べて映像のザラツキ感が少ないかも

aviutlは色々で来て面白いが音声が生WAVか偽装WAVでしか読めないってのが不便すぎる。

お前らテンプレ読めないのかよｗｗ

>>63
音声無劣化編集に拘りあるの？
今は入力プラグインにL-SMASH-Worksを使えば、ほぼどんな動画も音声も読み込めるけど。

>>64
スレたてした人とテンプレを考えた人以外誰も読んでないと思われ。

aviutl+x265guiexスレを建てれば万事解決だってはっきり分かるんだね

avs2pipemod -rawvideo "hoge.avs" | x265 - --input-depth 10 --input-res 1920x1080 --input-csp i420 --fps 23.976 -o "hoge.265" -i 240 --crf 18 --aq-strength 0.6
これでエンコードが90フレームぐらいで止まってたんだけど何が足りない？

avsの中身を見せずに何を言っているのだろう。

>>66
x265GUIEx使ってるけど、コマンドラインモードなら別にいいんじゃねと思ってる

フロントエンドで操作しているからバグの切り分けしないといけないからダメだろ
x264スレだってGUI専用スレあるんだから

GUIスレが出来たのは組み込み型のx264GUI（aviutl）だったりvfw版x264も存在してたからじゃ？

そもそもH265(HEVC)スレが元々あって、そこでx265の話すると
原理主義のバカどもがスレ違いとか言い出すからこのスレが出来たんでしょ

H265とx265の大きな違いは、フリーで実際に手にできて使えること。
このスレで実用面の話が出るのは当然だし、そうじゃなかったらこのスレ出来た意味さえない。

>>1が勝手にコマンドライン限定にしてスレ立てたけど、
そこまで限定して需要下げても意味ないだろｗ

純粋にテンプレ読まないで勘違いな投稿したならスレチだけで通じるんだが
それから意地になって居座る奴らが問題

>原理主義のバカどもがスレ違いとか言い出すからこのスレが出来たんでしょ
当然じゃね？そもそもそのバカどもが立てたスレにお前もいるわけだがｗ

>H265とx265の大きな違いは、フリーで実際に手にできて使えること。
お前、動画規格とエンコードツールの意味理解してないだろ、知ったかもほどほどにｗ

>1のルールに不満があるなら別スレ立ててそこでやればいいじゃない
それかこのスレのルール改訂を>1にお願いするか

>>75
H.265スレにおいて、そのエンコーダであるx265の話題を出すことが
スレ違いになるだろうかと思っていたのだが、
おそらく一方が動画規格で一方がエンコーダと
区別がついてない人が、H.265スレではx265はスレ違い
と言い出したんじゃないかと思う。

x265スレなのだが

無毛な奴らによる不毛な争い

スキンヘッドな変態紳士 vs パイパン男子の争いか。

x265 rev1 これが悪い
【コマンドライン専用】とか入れるべき
コマンドライン専用だとCMカットの方法知らない
って言うか素直にスレ立てればいいのだけど現状過疎るの必定だからな
CMカットエンコも無事４シリーズ目に突入だぜ

早いとこ、インタレ保持とアス比のオプション実装されないかなあ

TODOリストにのってはいるけど、他の未実装項目山盛りだからなぁ

timecodeの読み込みはよしてほしい

AVX512に対応したら5%くらい高速化したりするのだろうか

>>85
AVX2もあれだし、どうやら8bit整数を扱うには128bitのSSEで十分らしい。

ボランティアじゃない営利目的の企業が開発しているOSSにはずれが無い

0.7になったのにEvaluators Guideなかなか更新しないな

なんか急にrev進んだけど、ビルド出来ないな。エラーが出てしまう。

buildbotも0.6+343-eb3713ab0641で止まってるな

x265の非公式バイナリ配布サイト終わった
今後は何処で落とせばいいのか

お、自分でビルドしたら0.7+17がビルド出来た。

自分でビルドしたいけど
なにがなんだかわけわからないｗｗ

ぇ？
x265のbuildってVSとcmakeだけじゃん
build環境としてはこれ以上無いくらい簡単だぞ

え？
まだビルドしたことないんだけどgccないのかよ

あるよ

>>93
RigayaさんのBlogにx265のビルド法が一から丁寧に書かれてるから
その通りにするだけで誰でもビルドできるよ

今ビルドすると、ver0.7-r21かな。

バイナリ配布ってダメなの？ダメならダメでx265専用のクリック一発でx265.exeを作るソフトがでてきそうだが

vcなんかのインストールさえすればクリック一発に近い。
某testスレみたいにビルドに関する質問で溢れたりしてな

そうなったときは初心者スレたてる

VirtualDubとかHandbrakeとかAvidemuxのHEVC対応版がどうなるのか凄い気になる
海外のファイル置き場からHEVC対応済みのインストーラーを拾ってくるのが普通になるのか、全自動ビルドのソフトが出回るのか
はたまたVP9・Daalaの開発が猛烈な勢いで進むのか

>>97
かみさまありがとう

>>101
世の中開発者は有限なので、x265の開発が活発になっている今、
DaalaやVP9へは開発者はまわらないよ

そもそも今まで盛んに開発されていたx264から人材がx265に移動してて
当然のようにx264は停滞してる。

>>101
x265を内蔵するだけなんじゃないの？
ffmpegだってビルド時にリンク（？）すればx264が使えるし

x265.cc　のを使えばいいじゃん

そのx265.ccが消滅したんだよ
サイト行ってみ

Since Mr. Vaughan (x265 marketing manager) don't like buildbots,
this project have been deceased. You also should consider to use
x265, since its definitely NOT this community related, like
the great x264 project.

VP9/Daala+Vorbis/Opus＋WebM　をGoogle辺りがゴリ押ししてくれたらこんな面倒なことにはならない気もするが
肝心のGoogleからやる気が全く感じられないから困る

msやgoogleは他人が開発したモノを接収するのに長けてるだけ
そのくせまるで自分が最初に発明したかのような口きくけど

一時的に繋がらないんじゃなくて潰されたのか

>>103
x264の連中でx265に関わってるのはJason氏だけ、それもアセンブリのレビュー
だけ。コミットログを見れば分かると思うが、開発してるのはMCW社の社員だ、
唯一なぜかパッチを送り続けている外部らしき人物はoki.comの日本人らしき
名前の持ち主だ。

最初からああなるんじゃないかって思ってた人はいたけど、確実にx265の
コミュニティとの接続は切れ始めている。元々名前のためだけにJason氏と交渉
などしてたしねぇ。一応OSS系のHEVCエンコーダーで一番進んでいるプロジェクト
ではあるが。

まぁ、言いたい事は「x264から人材がx265に移動した」という事は全くの嘘である
という事だ。x265はアレだし、未だにどの現世代・または次世代の形式の実装や
開発に加わってない人も多いんです。Googleの連中はVPx系やってるし、
XiphやMozillaの連中はDaala（仮）という形式の開発に励んでる。

２ちゃんねるはウソで満ち溢れている。ウソをウソと見抜かなければ云々。だよな。

それで既にx264を遥かに凌駕しているとは
H.265/HEVCのポテンシャルは凄まじいな
さすが次世代の画像圧縮技術

420 8bitなx265なんてまったく興味がわかない。

MSYS&Mingwで64bitのx265を作ってみたんだが、libgcc_s_sjlj-1.dllとlibstdc++-6.dllがないと動かないヘンテコバイナリが出来てしまった・・・
-static-libgccとか-static-libstdc++をつければいいって書いてあったけど、どの段階でつければいいか分からない・・・

どの段階でつければいいの？VS2013でビルド出来たんだがMSYSでしてみたくなって・・・

>>115
自己解決
cloneしてbuild/msysにあるmake-Makefiles.shを実行したら出てくるCMAKEの設定項目のCMAKE_CXX_FLAGS_RELEASEに-static-libgcc -static-libstdc++ -staticと記述してからmakeする
http://saorinpikachu.wordpress.com/2013/12/19/x265-windows%E3%83%93%E3%83%AB%E3%83%89%E3%83%A1%E3%83%A2-static/
このページに普通に書いてあったわ
スレ汚しごめんなさい・・・

>>113
形式のポテンシャルと関係なく、残念ながら今のところの実用向けの
実装（企業的なものを含めて）はどっちもx264にはまだ至らない。
PSNRでは一応少々x264を超えている数値を出してるエンコーダーが既に
あるけど、結局エンコードで人が見ているのは数値ではなく、映像。
SSIMなら数値的にどっちも負けてない状態になっている。

そして去年の4月からHEVCはもう次世代じゃなくて、現世代です。

>>114
1月18日にDIS投票が終了したRange Extensionsにご期待ください。
残っているのはFDIS投票のみ。

x265.ccがつぶされた（？）のはバックに営利企業がついてる以上、仕方ない気もする。
ところで新しいHEVCエンコーダーのプロジェクトが立ち上がったみたいだけどどんな感じ？

はぁ？
その名称もURLも出さないでどう会話しろと

http://x265.ru/en
コレじゃなくて？

そこ、ただビルドしてバイナリ配布してるだけでしょ
しかもペース遅い

github.com/ultravideo/kvazaar
ここ

cygwinでビルドさせてやろうと思ったら
シェルスクリプトの中身とか色々細工しないとダメらしいね
さすがにちょっとめんどくさすぎる。

既存のcygwinでどうにか出来るから
新規にMSVSいれる手間よりはマシだけど
俺個人のモチベが続くのか疑問だｗ

>>118
営利企業と言ってもx264 LLCも一応営利企業ではある。コミュニティとの態度の
違いって奴かな。x265.ccがどうなろうとは個人的にどうでもいいが、MCW社は
全面的に企業ライセンスをゴリ押ししながらコミュニティとの接触を最低限にしてる。
そういうプロジェクトがもしこれからメジャーになれば・・・と少々心配になる。
元々公式でGPLの説明をかなりアレな感じにしてた会社だしなぁ・・・

ちなみに、MCW社で開発を担当してるSteve氏は別に悪くない人とは思う。単に
会社の上司がアレで、今の流れはある意味仕方ないとは思っている。

>>122
KvazaarならCで書かれている実装です。若くてmain()でエンコーダーの中身の
初期化とかしてるし、綺麗さはコード面でもまだ高くはない。入力・出力・
エンコーダーのコンテナ化も完成してエンコーダーのAPIさえ少しまともになれば
色々不満は解消すると思うけどね。Makefileのビルドシステムも多分今のは
一時的な物で、これからx264のようにシェルスクリプト化するか、Autoconf辺り
が使用されると思ふ。

あとはまぁ、表向きなところしか読んでないが、x265より入りやすいコードベース
だと個人的には思う。単にC++に慣れてないからそう感じるかもしれないけどネ。

そして何よりもMCW社と逆にIRCで連絡しやすいし、パッチも簡単にレビューされる。

今一番進んでる実装＝x265　、期待の新人（？）＝kvazaar
こんな感じかな？

>>125
詳しくありが�d

HEVC encoder version 0.7+24-aab88ed13364で確認。
--preset faster〜slowerまででCfr20と22でエンコ

するとfast〜slowerで絵が大きく破綻。
rigaya氏のBlogを見ると「AQ + CUTreeがオンになるため」って書いてある。

ココらへんの調整に問題があるのかな？
それともおま環？
avs2pipemodでpipeして出力。x264では問題なし

>>127に追記
fastのcrf20とfasterのcrf20じゃビットレートが2倍以上違う。

0.7+35にすれば破綻は直るで

>>129
情報ありが�d
早速・・・と言うか、この情報を知る前に0.7+41かな？それを使ったら治ったのを確認した。
でも粗さは残ってる気がする。

早く画質を一定にして欲しいなとお星様にお願いしておく

>>125
Kvazaarはフィンランド製と言う事だけど、カタカナで字訳するとどうなるの?

次の検索結果を表示しています: kvazar
元の検索キーワード: kvazaar

ググったらこんなんなった

なんかスレの勢いが急に弱くなったな

バイナリを自動公開してたサイトが潰れちゃったからね。
自分でビルドする人はやはり圧倒的に少ないし。

しかし、x265の更新ペースが明らかに上がってるな

gccでやったらヘルプも出ないヘンテコなバイナリができて投げたよ

ソースコードの中身も確認せずにmakeするからそうなる。

普通は確認せずにmakeするだろ
まあ問題が起きたらその後でソースコード見るが

んなこたない。中身を見てもチンプンカンプンなら仕方ないがｗ

必要なライブラリ関係を揃えるためにREADMEやINSTALLは最初に読むが
ソースコードなんていきなり見ないだろ普通
ビルドできなかったりバイナリおかしかったらその時点でソースコード見始めるが

Aviutlがユーザーが自力でとってきたneroaacenc.exeを利用するように
Handbrakeとかもユーザーが自力でとってきたx265.exeを利用するようになるんだろうか

ま、今ん所VS12で簡単にビルド出来てるから問題無いけどね

久々にx265を更新してみたけど
0.5+243　→　0.7+63で速度1.5倍くらい速くなっててワロス
まだ　preset fast と軽いフィルタで1080i→720pにして12〜13fpsってとこだから常用は厳しいけど革新的にエンコ速度上がってんな

結局自分でビルドしない、出来ないx265.cc使ってた連中はどこ行けばいいの？

ビルドすりゃいいじゃん
こんなに詳しく書いてあるんだし
ttp://rigaya34589.blog135.fc2.com/blog-entry-402.html

ただこの方法だと10bit対応版が作れないんだよね

>>145
make-solutions.bat の cmake のオプションに、
-DHIGH_BIT_DEPTH:BOOL=ON
を追加。

STATIC_LINK_CRTをONにって説明してる画面にHIGH_BIT_DEPTHってのがあるから、
それもONにするだけでいいよ

>>145
よく見ると >>146 をやらなくても、>>144 の 8. のところの画像にある
HIGH_BIT_DEPTH のチェック・ボックスをクリックしてオンにすれば
10bit 対応版になると思う。

おぁ〜、そんな簡単な方法で出来るのか
感謝感謝

しかし今はweightp周辺にバグ？ビルド完遂せず

>>47の10bitでの修正って本当なの？
0.7+63でcrf23試してみたけど明らかに8bitのcrf23より汚いんだけど…
crf18でやっと画質もビットレートも同じくらい

>>150
まだ調整がされてないんでしょ？
バージョンは忘れたけど、綺麗にエンコできてたバージョンから新しいバージョンに乗り換えた時汚くなった。
いずれ、再調整されて出てくるんじゃないかな

現状16bppの方は、とんでもなくcrfを下げる必要があるよ。
アニメなら15以下

crfの値はバージョンごとに別物になる、って感じだな

VBV制限すればいいだけじゃね?

画質を基準にエンコするはずのCrfで画質が大幅にブレるとどうやって画質を調整すればいいかわからないよね
下手に他のバージョンに変えられないって感じ。

保存用にエンコしてんの？可哀想に

あ、はい

インターネット上にうｐする犯罪者とは違うからな

10bitエンコするときは8bitの時のcrf値を半分にすると同じくらいかなぁ

x265が使えるHandbrakeが出るのを口をあけて待っている

　　　　　　　∧__∧
　　　　　　（´∀｀　）　かもーん！
　　　　　　 （⊃⌒*⌒⊂)
　　　　　 　　/__ノωヽ__）

BT.2020を扱えるフロントエンドってもうあるの？
BT.709のH.264レベルの映像をH.265でエンコしても将来Playerが対応して
くれる保証が・・・

圧縮率高くても、あと数年は実用できるような環境じゃないな

ハード再生ならわかるがソフト再生でそんなこと気にするのはナンセンスじゃ

GPU支援が対応してくれなきゃあ話にならない
特にHEVCなんて再生時のデコード負荷とか掛かりすぎだろう
PCは家電みたいにデコード＆トランスコーダ用に専用チップを搭載するわけでもないしな

はぁ？
HEVCのデコード負荷はH264とほぼ同じ
今のプロセッシングパワーのもとでは再生負荷など問題になりませんが

もうちょっと頭使ったほうがいいよ

ヘッドバット最強

>>165
いまのDXVA2ですら正式に対応できてないだろ

28の4KサンプルですらVLCで再生させるとCPUクーラーが轟音を上げる始末だしな

それがどうした
そんな話してないし

俺はそういう話をしているわけだが。
おまえがしつこく噛みついてくるから反応してあげるわけだ。有難く思えよ

あ、はい

バイナリ

http://x265.ru/en
http://builds.x265.eu/

http://x265.ru/en
↑
これ、ビルドペースが遅いなと思ったらナイトリービルドへのリンクもあるね
これはいい

>>165
4Kサイズだと6コアCPUでも一部カクカク再生なのだが・・・

デコードもエンコードも現段階では実用レベルではないし、
PC以外での再生可能プロファイルが未知すぎてエンコすることそのものが実験の域を出ない。

>>174
もしかして、レンダラにMadvrとか使ってる？
うちもカクカクしてたけど、調べるとグラボが限界だったみたい。
Madvrを使ってないMPC-BE x64+LAV Filters x64の組み合わせで再生余裕

うちの環境は[email protected] + GTX670@OCね
デコードはまぁ重たすぎるね。普及するにはPCだけでなくモバイル機器まで幅広く使えるようにならないとダメだから、専用のチップとか出るまでは難しいだろうね

デコードが軽いとかいう奴はＧセレ＋オンボＶＧＡで
H265の4Kを快適再生できるか試してみればいいんじゃね。

何そのPC

４Kの魅力が活きるディスプレイあるの？

探せばあるんじゃね
っつかこの先出ないとでも

>>178
このあたりなら行けんじゃね。
dellの方は2台以上並べないと物足りないかもしれないが
http://japanese.engadget.com/2013/12/18/lg-105-21-9/
http://www.pasonisan.com/dell-monitor/u2913wm.html

前者はまあこうなるよなって思った

また4k厨来てるけどここx265のスレだから

x265の再生負荷が高いんじゃなくって、ただ単に4Kだから負荷高いんだろ？
x264の4K動画だってCPUパンパンになるだろ

普通のSDサイズだったらCPUクーラーが轟音上げることもない

>>183
x264の４K？

H.264の4K/8KはQ9650でも余裕。
Youtubeのブラウザ再生の4Kも余裕

それは再生支援が効いてるからかな

GCCを使ってビルドする方法
http://blog.k-tai-douga.com/article/87146386.html

Youtubeの4K動画って、ビットレートクソ低いやん
基本的にYoutubeはどの解像度でもビットレート低くて再生負荷も低い

昔はGCC大好きだったけど、最近のパフォーマンスはどうなんだろ

GCC>MS>ICC
海外じゃ普通に検証してるんだがな

>>187
この記事ってわざわざ難しくしてるような気がするんだけど。

GCC、Cmake、Mercurial(TortoiseHgでもOK)をインスコ
↓
msys起動してコマンドラインから
　hg clone https://bitbucket.org/multicoreware/x265
　cd x265/build/msys
　make-makefiles.sh
　適宜チェックボックス入れてconfig→generateの順でボタン押す
　make

これでいいはず

Full Auto x265.exe Maker
You Dont have to run the CommandLine anymore!What you need to do is just execute the FAxM.exe and you'll get the latest x265.exe!
x265 + Nero GUI
You Dont have to run the CommandLine anymore!You Dont have to use the libfaac which have really awful quality anymore!
Just choose the source file and you'll get the latest x265+HE-AAC movie file!

x265を使うのに端末が必須だったら、こんな感じのソフトが出てきそう
俺含めて世の中の99%の人は「では、コマンドプロンプトを開いて云々」の一文が出てきた時点で投げる

pdfやっと更新したか

なんか最近高速化してきたな

>>186
むしろグラボの再生支援がある方が問題が多い
CPU処理のみの方が軽い(DXVA必須だけど)

DXVAがグラボの支援なんだけどな(´・ω・｀)

最近のはデコード処理全部やってるから
支援だったのはもう昔の話

>>196
DXVAはDirectXの処理
グラボの再生支援機能は別（nVidiaの場合（AMDは使ったこと無いので知らん））

とんち？一休さん気取りですか?

DXVAがDirectx Video アクセラレーター（英語綴り略）なのは正解。
各社、再生支援機能に違う名前を付けてるのも正解（UVDだとかPureなんちゃら）
うん、トンチにもなってないな

例えば、CoreAVC（2.5以降かな？）はDXVAとCUDA処理を明示的に別物で扱ってる。
グラボよりCPUの方が高速な場合、再生支援をON/OFF切り替えすれば
このあたりはよく分かる。（[email protected] 1920*1080 60pの動画で試せば分かるはず）

そもそもDirectXを理解してない人に言っても無駄か・・・。

ｘ265にDXVA関係あるのか?

そもそも
バカ「H265は再生が糞重いんだよ！。CPUパワー全然足りない。普及するわけがない」
↓
他の人「え？H264と同程度だけど？今のCPUパワーで再生出来てるよ？」
↓
バカ「4KのH265糞重いじゃん！」
↓
他の人「H264だって4Kだと糞重いけど？GPUの再生支援の有無の話？」
↓
バカ「DXVAがーCUDAがー(ﾌｧﾋﾞｮ」

まとめ乙

釣られた奴らが荒らしに参加しただけなんだろ。いちいち荒らしの誘導に釣られるなよ

解像度高いとh264も再生支援効かなくなるけどな
いってもrefとか盛らなきゃ普通に再生出来るレベル

きっと4K再生中に再生支援が切れたらCPUやVRMが火を噴くぜｗ

>>172
どうもありがとう

4K4Kつってるけど55V型以上の液晶テレビが家にないし

>>172
http://builds.x265.eu/
の方から落とした
http://builds.x265.eu/x265-64bit-2014-02-18.exe
がエンコードする時にノートンによるウィルス反応出て自動削除されるんだがｗ

Index of /x265_builds/
http://chromashift.org/x265_builds/


ここのは大丈夫だな

ロシア系ビルド。MSVC13版 normal&high-bit、GCC4.8.2版 Normal&high-bit。ビルドペース遅し
http://x265.ru/en/%D0%BD%D0%B0%D1%88%D0%B8-%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8/
MSVC13 normal,high-bit両方。rev更新毎に細かくビルド
http://machine-doll.ru/vc12/0.7/64bit/
Yukikazeビルド。GCC4.6.3 notmal-bit版のみ。で1日1ビルド
http://builds.x265.eu/
ICC1.4,MSVC12ビルド high-bit版の。１日１ビルド
http://chromashift.org/x265_builds/

自前でいけるように説明されてんのに張るなよ
あれだけ前はキチ暴れてたのになんで今回は暴れないんだ？
ダブスタすぎるわクズども

ん？当然貼りますよ。
君の意思など無関係に。

ついこないだまで定番だったx265.ccが消滅しちゃったんだから
他サイト探してる人はいるし、どのビルドも一長一短で決定版が無いんだから
なおさら複数貼るべきでしょう

「自前でいけるように説明」だの
「前はキチがあばれていた」だの
「ダブスタすぎる」だの
どこの幻聴なのか知らんけど。

もし仮にそうだったとしても人間は楽な方へ行くよ

どうにもmux弾かれるんだが

>216
L-SMASH rev785を使うといいよ

10bitエンコがまたまた激しく狂ってきてる
どんな開発してんだろ

mp4box rev4868とかでも結合できると報告

せやな
俺もmp4box r4868でh265muxしてるわ

216です
無作法なつぶやきに対し、皆様情報有難うございます
無事muxが可能となりました

0.7+259の16bppの挙動まともになってる？
久しぶりに16bpp使ったけど、何か前と違って残念画質じゃなくなってる。
16bpp使ってみようと思ったのはバイナリのサイズが急に増えた気がしたから。

最近は、16bpp関連の項目ばっかりが更新されてるから、治ってきてるのかも

>>187
>>191
ビルドしてみたが
libgcc_s_dw2-1.dll
libstdc++-6.dll
も入れないと動かない、なんかミスってるのかな？

>>224
>>116を見るといい。

>>225
ありがとう、できました。

kvazaar
https://github.com/ultravideo/kvazaar

オープンソースのHEVCエンコーダ

なんで今更宣伝してんだ　超既出

Handbrakeのナイトリービルドにx265が導入されてる
http://handbrake.fr/nightly.php

ハードデコード付opencl対応将来的にはHSA対応予定か。最強だな

HandBrakeはx265の前にAVS読めるようにしてくれよ

ってかTrimにさえ対応してくれたら

ロゴ除去出来ないと

やっとcrf値のバグ修正が入った
https://bitbucket.org/multicoreware/x265/commits/2fb85daef8af16015f876745e8379d2a9f5fbcd6
ratecontrol: fix bitrate issue in 10-bit CRF mode

実際に10bitエンコしてみたけど、ちゃんと機能してること確認

バージョン0.8出ました

x264/x265のパラメータとかいろいろいじくってて気づいたんだが
パラメータやマトリクス類を全く弄らずに標準プロファイルを変えただけだと
avsでプレビューしているときの画質と、x264/x265でエンコした後の画質に違いがあるんだな。
違いというかブロックノイズやモヤモヤっとしたような劣化が見られる。これはなぜなんだ。

プレビュー時は無劣化だからじゃないの？

その無劣化の意味が分からんが、avsを編集してMPC-HCでプレビューした時の画質と
x264/x265でそのavsを読み込んでエンコした後の画質に違いがあるのが妙に納得いってない。
ソースはアニメのDVD､crfは20 エンコ後のSSIMは平均で21.0db越えだから
良い画質になってると思うんだけど実際は劣化が目立っててしまいガッカリする。
もしcrfを12ぐらいにすればうーんとマシになるのかなっていうかそういう問題？

>>238
納得いってないのはお前の頭が悪いからだよ。
誰の責任でもない、お前の人生が悪い。

非可逆なんだから劣化するのは当たり前やんか

>>239
エンコごときに人生とか関係ないだろ。
とりあえずx264/x265が見せる。SSIM値が画質を示す値じゃないのはよくわかった。
やはりあれだな実際に試してみないとブログや２ちゃんの記事だけじゃアテにならんよな。

そりゃ人の感想だから主観が入るのは当然、
他人の意見は参考にしてこだわりたきゃ最後は自分の目で見て判断するしかない

Skylakeまで2500Kで待つか今4771をかうか迷う

>>241
>エンコごときに人生とか関係ないだろ。

おもいっきり関係あります。
あなたの頭が悪いのはあなただけが悪い。

なんか頭悪そうなのが二人いるな

CLI版のx265はx264のパラメータをそのまま引き継げないんだね。
なんか色々と面倒。画質が向上するわけでも圧縮率が向上するわけでもないのに
HEVCにするメリットって結局何？4K/8Kの試験放送がそれに対応するかもっていうぐらい?

趣味で楽しむのにメリットもデメリットもねーよ

ｽﾌﾟﾘﾝｸﾞ　ﾊﾞｹｰｼｮｰﾝ

＞ 画質が向上するわけでも圧縮率が向上するわけでもないのにHEVCにするメリットって結局何？

ギャグで言っているのか？

煽って答えを引き出す手法

flashとiosが対応したら本格的に移るわ

大昔のATiはグラフィックボードに再生支援入れてたよ
3D RAGE Pro Turboとか

ここはx265の利用者層の程度の低さに驚かされるな。

お、おう

>CLI版のx265はx264のパラメータをそのまま引き継げないんだね

ハイレベル(笑

程度の低いギャグセンスの持ち主に言われたくないよね

ここは揚げ足を楽しむバカが反応を見て暇つぶしするためのスレなんだな。
つまりx265の話題なんてまったく興味がないというわけか。

こんなことで心折れるなよ
社会に出ればつらい事だらけだぞ

そんな時はチンコアタック

みんながポカーンてなるような話をいきなり始めて
「x265の話題なんてまったく興味がないというわけか」
とかどういう頭の構造してるのか知りたい

>>1
> ここはx265のスレです
>
> ・コマンドラインを使用している事を前提とします
> ・AviUtlやx265GUIExなどの話は専用スレへどうぞ

まずはこれを順守するべきだろう。

俺の振った話題にレスくれなきゃイヤイヤってか？
いきなりとんちんかんな書き込みした挙句逆切れとか
そんなキチガイ誰もまともに相手せんわな

そもそもこのスレは隔離スレだしまともな住民が殆どいない件

いつからここが隔離スレになったんだ？
じゃぁx265の本スレどこだよｗ

>>264
>>4

は？
そこはx265と全く関係ないだろｗ
まさかまだエンコードツールと動画規格の区別がつかないやつがいたのか

規格であるH.265のスレで、ツールであるx265の話をしてた住民を隔離するために
後から出来たのが、このx265スレ
という経緯からすれば、隔離スレと言えなくもない
が、別物なのはその通りなので

何言ってんだ？

このスレのルールに文句があるなら自分で別スレ立てるかルール変更提案して多数の賛同得ればいい
スレのルールは立てた奴が決めるんだから>1がこのスレのルールなんだよ
それを覆せるのは2chの運営しかいない

何言ってんだこいつ

あいかわらずx265に全く無関係な雑談ばかりだな。
どうせビルドも他人任せで誰かがアップするのを待つだけで
x265のエンコも殆どやってないんだろ。

全て憶測

ちゃんと言い返せない時点で図星だと認めているようなものだろう。

(ドヤ顔)

やってるよAVIUTL使って
3日かけて買ってきたBDBOX14話エンコした
かなり縮んだので大満足
ただ、2本エンコするたびにPC再起動しないとエラーでるから面倒
今度でるv8はアスペクト指定が入りそうだから地デジの1440x1080のまま
アスペクトだけ16:9でエンコできたら便利で良いのになって所

ここCLIなんで…
GUIはスレチなんで…

アスペクト・・・ああ、アス比の事ね
そういう書き方する人最近見ないから一瞬戸惑ったよ。

2本エンコのたびに再起動しないとエラーが出るのは
aviutl側の問題かエンコ環境側の問題じゃないかい?

1440ｘ1080のものは、YambでPixels Aspect RatioをCostom[4:3]に設定してたわ
あれじゃダメなのかい？

同じこと言ってるかもしれないがコンテナ側でアス比を設定してソース側はリサイズなしでエンコさせてもいいんじゃね
ただし放送ソースは各種デノイズはかけないとボロ画質のままじゃエンコしても縮まないけどな

videolanのとこって更新止まった？
bitbucketのやつが長いこと反映されてないんだけど

Videolanはx265.ccの閉鎖とほぼ同時に更新停止
ただのミラーだったからどうでもいいんだけどね

>>278
MP4BOXでmuxか良いこと聞いた
昔映像＋音声で2G超えのファイルが上手にmux出来なかったので放置してた
そのやり方で正しいと思う

HEVC encoder version 0.8+131-ed48f84e541bだけど
--rect入れたら破綻するなぁ
うまくいってる人いるかな

x265guiEx_3.23βとか上手く動かん。
mp4ならmuxで止まるし、mkvなら映像が25fpsになってしまうし。

x265guiExはスレチ

>>1
>・コマンドラインを使用している事を前提とします
>・AviUtlやx265GUIExなどの話は専用スレへどうぞ

>>284

>>216

x265guiEx　3.23βきてたか

あぁ、報告さんきゅ
落としてくるわ

動きまくりソースだとslow q23で264と比較したら一割しかサイズ差ないでやんの
使い分けしたほうがいいのかもねぇ

そんな無意味な比較されても。

x264とx265のQ値は当然意味が異なる

>>246に通じる、同じニオイを感じる

x265とx264を比較したいのなら、CBRで同ビットレートにして画質比較や、
crfモードで同ファイルサイズになるようにエンコして画質比較するしかないよ。
もちろん、どのプリセット選ぶかで全然違ってくるのだけど。

そうだよな。x264とx265とじゃパラメータの互換性はだいぶ失われているし同じようにエンコしようったって無理がある。

アルゴリズムも作ってる人も違うのに互換性も糞もあるか

でもこいつら言い訳だけで検証しようとしないんだよなぁ

検証なんてしてもメリットが思いつかないからな。
せいぜい自己満足になるだけだろ？

じゃあ最低その言い分のパラメーターで画質差くらい検証しろよ
的外れの可能性高いのはそっちだろうが

メリットが思いつかないのにその画質差を調べて何になるんだ?
おまえの暇つぶし＆ストレス発散のためだけに検証とかほんとウザ過ぎるわ。

妄想よりマシだよw

マシの意味が分からん。

何が何でも自分の言い分が正しくないと気が済まないんだろ
なんかこいつら〜とか言って横から口挟むような雰囲気醸し出してるが
マジで>>246 = >>289 = >>295なんじゃねーのか　的外れなのはおまえだろ

レッテル張りキターw残念ながら別人ではある
264と比較してメリットがどっちにしろなさすぎるってことだわな
エンコ速度低下とオプションに関わらずサイズ減らなさすぎるのは変わりない

>レッテル張りキターw残念ながら別人ではある

いえ、同一人物です。
もう皆でそう決めましたから。

アンチ意見同一人物扱いするのはあまりよくないぞ
ぶっちゃけると自分はHandbrakeのほうしかいじってないしな
8k4kもまったく興味がない

実際比較した人ならすでにいるけどあれをみてx265いいんじゃね？
って思う人は相当な変人だろうなと。

http://rigaya34589.blog135.fc2.com/blog-entry-403.html
http://rigaya34589.blog135.fc2.com/blog-category-16.html

海外の比較グラフは当然見てそこも見てはいるからなー

GUIはスレ違いだとほざきつつGUI作者の検証結果に頼らざるを得ないお前ら最高

検証結果に頼る？何いってんだコイツ
検証結果に頼るのはエンコできない奴だろ
エンコできるならそんなもの頼る必要ない

エンコ出来ないとかありえん。いったいどんな糞環境だよ。Pen3S+815Eか?

そもそもGUIがなんだろうが、使ってるのは.exeなんだからｗ

しかも、その記事は今となってはX265のrevが古すぎて参考にならんし

それと、Rigaya氏のx265記事は、x264より画質が優れているという結論なのだが
馬鹿が読むとこの記事がx265否定記事に見えるんだから面白いｗ

面白がってるのはお前だけな。他の奴らはNGにいれて無視してるだろ。

AVIUTL x265gui最新にしたらmuxで反応しなくなった
ちとお手上げ

安定性にかけるエンコーダだから前のVerかｘ264guiに差し替えろ

Handbrake結構イイぞ
100本近くエンコしたが失敗無い
avs読めないけど

>>313
そのときにaviutlを強制終了させても、まだなんか走ってたな。

avs読めない時点で利用価値が消える。

batファイル作って
avsをD&DするだけだからGUIは使わないな

実験的にインタレエンコが導入されたな

そいつは俺得だ

CLIで
　--no-interlace
　--interlace=tff|bff|prog|false
オプションが追加された

今試験エンコしてるけど、エンコ速度はプログレの時の半分になった
終わるのまだ先なので画質云々はまたあとで

普通はインタレ保持する方のが時間かかるのにな。

ん？

>>322
速度半分と、時間半分の区別ついてる？

ん？ああ、エンコ速度か。じゃぁやはり時間は掛かってんだな。失言だったなすまん。

0.7からしばらく更新してなかったから
久々にビルドしてみたがまたエンコ速度上がってるな
720p フィルタ込みで
11fps→12fps　になったわ

エンコ速度は間違いなく上がってきてる

ffmpegがlibx265に対応したってね

すっごい前にね

Unit Testsってなに？

ビットレートを揃えてx264とx265でエンコしてみたけど
予想以上に差がなくてガッカリ
1280x720で1000kbpsっていうのがムリだったんだろうけど

>>331
そうだと思います。
ギガジンにあった800x600、1000kbpsの動画ですら
ギリギリ差があるかないかくらいでしたし

crf指定でエンコして、x264と目で見て同等の画質と判断したとある映像にて、動画容量がほぼ一緒だった。x265全然縮まないな。

速度度外視の設定でやれば現段階でも十分に縮む
しかしi7 4770程度の性能では全くお話しにならない
たかがHD解像度ですら使い物になる速度じゃない
けれど使用に耐えられる速度で妥協すると思ったより縮まないという始末
i7 4770の10倍くらいの性能で何とかやっと普段使えるかという按配なので
現在のCPU性能向上具合速度を考えると4ｋなんてもはや全くの問題外
4ｋ8ｋはCPUエンコの限界を超えてる
だがハードエンコは速度優先で糞画質が相場なのでお先真っ暗

>>334
10倍の演算力を使えばいい
つまり、GPUもであり、HSAだ。

残念ながらIntelにはソリューションが無い。

x264とx265の目視確認での同等の画質はほぼありえない
輪郭部分の標準的な扱い(処理の手法)が根本的に異なるため
主観だけど同等画質ならx264よりx265の方ががなりガッツリ縮むからx265を積極的に使っている
ただし、エンコが死ぬほど遅いのでお勧めはしない

Mac PROの出番か

>>335
つLarrabee

>>338
存在しない

>>339
Xeon Phiのことなんじゃね？

0.9になりました

x265かなり速くなってるけどhaswell-E出る頃日はveryfast並のビットレート比画質でフルHD等速エンコ出来るようにはなるんすかね

ならん

HSAでGPU演算力も活用して高速化するほうが先に実現するだろうな

ttp://x265.ru/en/
のx265 Buildsで0.9が来た

インタレエンコ試したけど、まだちょっと未完成っぽいな
再生すると妙に破綻してる

実験だからまだフィールドオーダーを正しく受け渡せない
しかしインターレース関連はx264も改善期待あったけど結局効率悪いままで
プログレでもインタレでもほとんど同効率(数%プログレッシブの方が良い)のエンコーダと比べると
数％どころか数十％の差とかなり圧縮率悪いままずっと放置されてる
まあプロが使うのと比較しても仕方ないけどx264のインタレエンコは非常に芳しくない
どうも外人はインターレース関連に弱いみたいだからx265が突然良くなるとは思えないのでおまけ程度の機能としておいた方がいい

インタレ関連に弱いというより関心・魅力がないだけじゃね？
そういう場合は347みたいに関心のある人が積極的に開発に参加して
インタレ改善部分の更新を引き継げばいいんだよ。
俺はインタレ保持とか興味ないからどうでもいいけどな

感心がないんじゃなくて、インタレに関する知識が足りてないんだろ

カキタレ

音声は引き続きAACですかね？

Opus

>>347
数十%も違うっけ？

実際自分でエンコしてみればわかるけど、
全く同じエンコードパラメータで、プログレ、インタレエンコを比較すると
後者のほうが20−30％はファイルサイズがでかい

どんなソースだよ

そりゃインタレはフィールド単位で別の映像が入ってるんだから大きくなって当然では？
プログレソースをインタレフラグ有効でエンコしてもほとんど変わらん

>>352
なるほど
勉強になります

>>355
あらゆるソース

10bitはまだあかんな

preset mediumでx264のveryslowぐらいまで早くなってるのね

そういやx264の時もｘ265のときも preset って一度も使ったことないわ。

x264はプリセットとaq,psy時々debrockだけ弄れば大体はok

お前はそれで十分なんだろうが

x264はプリセットとcrfのみでOK

presetは開発者の良心
presetは初心者質問除け
presetは甘え

甘えればいい
それでいい結果が出るんだから

甘えるな！というやつは切り捨てればいい
それで大勢が幸せになれる

甘えってw
単純にx264には圧縮率に関する設定項目と心理印象効果に関する設定項目があって
前者はプリセットに頼って端折ってもビットレート比の画質と速度は手動で設定した場合と比べて大したディスアドバンテージは生まれんやろ

全部自己満足だろ
だいたい他人がエンコした物を見ただけでパラメータが分かるのかよ

パラメータは判るだろ。
分からないのは使用したAVSやフィルタ類の中身だろ。

わからんパラメータは全部デフォにしとけばいいのよ、明記しなきゃデフォになるから
開発者だって馬鹿じゃないからデフォ値はそれなりに調整されてる

アニメはそんなに変わらないが実写は凄いな
2倍とは言わんが既にx264の1.6-1.8倍程度圧縮効率あるんじゃねえか?
暗部や輪郭の処理がうめえ

久しぶりにビルドしたけど開発速度がダウンしてるな・・・

videolanのは止まってるよ
いまはこっちttp://bitbucket.org/multicoreware/x265/overview

えっ？開発速度のダウンとビルドって関係あるの？

>>374
ビルドするためにサイト開く→更新履歴から開発速度を悟る
ってことじゃねーの？

>>373
そっちはずっと前に止まったみたいだね
bitbuketからソース貰ってるから俺には関係ないと思ってる
>>374
数日に1回ぐらいの頻度でビルドしてたんだけど、少し色々あってサボり気味に・・・
で、久しぶりににビルドしたら思ったよりrevが変わってなかったってこと
わかりにくくてスマン

>>375
そういうこと。
俺の分かりにくい文章から意味を汲み取ってくれて有難う

追記。俺は372ね

祝1.0

初めて自分でビルドしてみた1.0-4だった

dアニメストアとdビデオが「HEVC」対応へ。dビデオはHDも
http://av.watch.impress.co.jp/docs/news/20140514_648308.html

ああ、いいっすねー
そろそろx265でエンコードしようかな

俺はflashが対応するかappleがハードウェアデコーダ載せ出したら切り替えるかな

Xvid 1.3.3ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
https://www.xvid.com/

x265が出て一気に使い易くなったね。周回遅れながら試してみたけど
crf29↑の低ビットレート帯での再現力が半端ねーな… ＠実写エンコ--Preset Medium

ただ、高ビットレート帯では4倍以上遅い癖に264とあんま大差ない感じ？設定詰めれば改善されるかな

>>383
高ビットレートでのうまみがあまりないですよね
低ビットレート専用のコーデックとかｗｗｗ

4K試験放送のラグビーも
結構ノイズがのってる
同じビットレートのx264やMPEG2を
比較したらマシなのかもしれないけどさ

各プリセットのデフォルト値がまた変わったな
RD値が変わったから、同crf値でのエンコ後のファイルサイズが大きくアップ。

それと、ロスレス圧縮も実装された
オプションに --losslessと入れるだけ

1.1

aviutlのGUIを使うとmuxでエラーがでるんだけど
>>217
のL-SMASH rev785がいいらしいとかで探したらいつものところがサーバー故障なんだ
ほかに知りませんか？

rigaya氏のところにあるよ
http://1drv.ms/1gd23XF

0.8 +190 から久々に更新したら滅茶苦茶速度上がってんな…ｗ

0.8+190 8.68fps

1.1+5　　20.69fps

i7の一番新しいのでそのぐらいの速度になるのなら
i7のそれ程新しくないものだとまだまだ実用外の速度しか出なさそうだな。

>>391
2600k
win7 64bitや

負荷はq値を下げるだけでかなり大きくなって
デフォの1/3以下になるよ（速度ね）

>>389
遅くなりました
ありがとうございました

>>392
自分のと同じ2600kでそんなに出るとは
0.5以降を試していなかったので
ちなみに設定は何でやりましたか？

どうせSDアプコンとかじゃないのか?

>>396
そういえば解像度を書いていませんね
私のイメージ的に1280x720なんですが

>>395
今気付いた

720p
presetイジらずに crf23

x265をAVIUTLでエンコしてmp4ファイルを作ると結構頻繁にmux時にエラーで失敗してたけど
どうやらmuxerの作者がx265をmp4で使う時途中でmuxが止まるバグがあり、
mp4コンテナでx265使用時の正式な規格が6月末公開
正式な規格に合わせたmuxerはもう少し先ってことで色々対処された(現状ではmp4でx265を使うのは止めてって事)
取りあえず.mkvコンテナファイル作成に必要なmkvmerge.exeを入れたので
Wカップサッカー録画して片っ端からx265でエンコしまくる予定
1440x1080 --sar 14 -crf 23 でエンコすると2500Kで1試合7時間コースっぽいのが怖い所
サイズは1試合3G程度の予定 (crf 28設定ではファイルサイズ半分)
出力ファイルの拡張子を.mkvにするとちゃんとmkvコンテナでエンコしてくれる
ついでにチャプター編集プラグインも探して入れた、良い感じでチャプター設定できる
.mkv .mkv

mux時エラーで死に捲ったので個人的にはお勧めできなかったけど.mkvで安定するならお勧めかなって思ってる

>>399
最初から、まだβ版だから遊ぶだけにしてくれって書いてたでしょ…

>>399
得意げに書きこんだけどmkvコンテナも格納規格が未確定でした。(すみません)

librtが無いとか言われてkvazaarビルド出来ないよぅ

kvazaarってx265とくらべていい点があるのかな

>>389
rev785がなくなってる？

>>404
ttp://rigaya34589.blog135.fc2.com/blog-entry-411.html
ここにmuken氏が理由を書いてるよ
自分でビルドするという手も・・・・それかMP4BoxでもMux出来たはずだからそれですればいいと思う

>>405
そっか、来月以降には正式規格のmuxerが登場する可能性が高いのね。
それまで待つか。

mp4boxでもmuxしてみたけどDivX Playerで開けなかったんだよね。
lsmashも試してみようと思って。

rev785が無くなったからなんだってのか
今のL-SMASHのrevは900番台ですよ

>>407
過去レス読めば分かると思うが、HEVCをmp4コンテナに格納出来るL-SMASHは、
rev785あたりのバージョンだけなんだよ。
ただ規格完成前の試験的な実装かつmuxer自体にバグありで、使用は完全に自己責任だが。

デフォルトのmerange 57って数字はどうやって決まったの

親父の…歳です…

各パラメータのデフォ数値は頻繁に変更されるので、意味はそんな無いと思うよ

今現在、完成度は何%くらいなんだろうね？

ここ3ヶ月で60％速くなった
今年に入ってからで言うと200％速度向上した
それでもまだ25％くらい

i422、i444はまだ使えないのかな

普通に使えるけど

>>413
まだ25%か。
あとの75%ほどは何が欠けてるの？

>>416
https://bitbucket.org/multicoreware/x265/wiki/RoadMap
https://bitbucket.org/multicoreware/x265/wiki/TODO

>>417
CABACもまだ問題ありなのか？
使うのはもう少し待ったほうがいいのかね。

>>415
使えないよ

420で入力してるってことはねーよな

ないよ
なんかワーニング出てるしYV12に戻されてるメッセージ出てる

hi444pで出力するのに最低限必要なオプション教えてー

既に422や444対応してるって言ってる奴いるけどやり方聞くと誰も答えないっていう不思議ｗ

x265のエンコーダーをDLしに行けば判るよ

--help見る限り、
inputに関してはi420, i444 or i422,とも受け付けてるが、outputに関しては特にそういうオプションが無いので
422や444ソースをエンコしてみて出力が420なら対応していない。

分からないのなら試せばいいじゃん・・・

#420.avs
version.ConvertToYV12(matrix="Rec601", interlaced=false)
return last

#422.avs
version.ConvertToYV16(matrix="Rec601", interlaced=false)
return last

#444.avs
version.ConvertToYV24(matrix="Rec601", interlaced=false)
return last

コマンドライン
avs2pipemod.exe -y4mp 4xx.avs | x265.exe --y4m - -o 4xx.hevc

結果、MediaInfoで見るとそれぞれYUV4:2:0、4:2:2、4:4:4になってる。ただし4:2:2と4:4:4は警告が出た。
MediaInfo上では4：2：0が[email protected]なのに対し、残りの2つはL2.0のみの表記だった。
再生も4:2:0のみ可能で、残りは出来なかった。これはデコーダーの問題かな？

muxerはrev966を使用、デコーダーはLAVfiltersの0.62.0。

すまん書き忘れ。
x265は8bitな1.1+218-38da32f28481だとさ。

Rec601ってSD素材でも使ってるのか？

version…

>>428
特に意味はない
AVSPmodの入力支援にまかせて自動入力した値がそれだったんだ

>>429
スマソ(´Д｀)
BlankClipじゃ真っ黒だしこっちの方がいいかな〜と思っただけだ

hi

作る時にワーニング出てるのに再生側の問題とは思えない

>>432
だよな
まぁどっちにしろ現状無理ってことで良いよね？

いい

>>427
丁寧にバイナリをDLしに行けば判るよって書き込んでいるのに
諦めが肝心だよ

どこのことかも言ってないのに丁寧にって・・・バイナリ配布場所は一つじゃないのにさー

だからDL先云々じゃなくて>>429
が適切に突っ込みいれてるじゃないか
予想すると仮にエンコが旨く出来たとして今度は再生出来ないって騒ぎ出すんだろ？
少しサイトを見にいったり調べれば判ることを
教えてくれないって騒ぐ事自体が異常
調べて判らない場合はエンコするときの基礎知識言葉の意味概念が理解できていないって事なので
説明的会話が不能って事
おさわり禁止って判断されたから誰も丁寧なレスをしない

【速報】YoutubeのWebMの中身がVP9になっとる

youtubeからvp9動画ダウンロードしたいのによくわからんな

1.2

ここ数時間に怒涛の更新があってrev1.2になった

ひさしぶりにhoursとyesterdayで埋め尽くされてるのを見た

ここんとこずっと月一でバージョン更新してて数字に意味が無くなってるような

またまた怒涛の更新きたぁｗ

♪うえしたで〜

♪前から後ろから〜

どうぞ〜

同等の更新が来てもエンコ速度が２・３倍ぐらい早くなったりしない件。
せめてx264の最新リビジョンぐらいまでにはエンコ速度が追いつけばいいのに
そしたら皆x265の方に乗り換えるんじゃね。avsとの相性もあるから全部とは言えないが

>>448
それはない
エンコ速度が追いつくって・・計算量自体が膨大に増えてるのに？
x264 rev2431並の速度になればx264も更に速度が上がったrevが出来るだけ。
デフォ値で1920x1080のソースが13~16fpsでエンコしてくれるだけかなりマシだよ。

初期の頃はHDサイズでさえ2fps出てなかったんじゃなかろうかと

avsの相性は分からん・・・
このエンコーダーはおｋでこれはダメで・・・とかは聞いたことない。
メモリの食い方じゃないかな？SetMemoryMaxで頑張るしか・・・・・

書き忘れたけど世の中には可搬性を重視してる人もいる
だからモバイル機器での再生支援のないHEVCはまだダメだと思う人も多いはず
いずれ解消されるはずだけど・・・・

計算量自体が膨大に増えてるのにボケボケ

今年に入ってから猛烈に高速化進んでるんだけど、全く自覚してない人いるのか

x264比だからね。
そもそもx264は速度キチで有名だしCPUパワーだけで並ぶのはまだまず無理。
新世代コーデックらしくGPGPUとかAVX512をうまく組み込めればあるいは・・

>>453
>AVX512
Xeonぐらいしか対応してないんですがそれは……
x264の方が先に対応しそうな予感
(と言うよりx264にはOpenCL版が（ｒｙ)

次の次あたりで降りてこなかった？
x264だって登場から4年ぐらいかかって実用レベルになったんだから
x265も2、3年経てば大きくかわるんじゃないかな

DivXの265のほうも数倍早くなった言ってたし
今はそこそこ早くなっては来てるんじゃなかったっけ

>>453
64bitや128bit精度が必要な計算とかならともかく、8bit、16bit整数が主のx264やx265はAVX512を持てあましそう

x264と比べるにしても10年かけて成熟させたx265と作られて1,2年のx265じゃ勝負にならない気がする。

>>458
>10年かけて成熟させたx265
10年かけて成熟させたx264に修正
未来の話してた

いや、x264での成果の一部はx265に流用出来るから
x265の高速化はハイペースで進んでる

デュアルコアすらなかった時代から比べれば
今はチートレベルな環境だよな

そのかわり昔はマルチプロセッサという手段があったけどな

>>461
昔（2006年）に買った一体型PCに付いてたCeleronM(1.6GHz)と4790Kで
x264のエンコ勝負させたら30倍以上差がついたことがあったな……
よくあんなのでDVD編集とかしてたもんだｗ
>>462
今でもあるじゃん（Xeon感）
よく知らんがマルチプロセッサなんかしたら高く付いたんでしょ？

マルチプロセッサで動かしても2コアとか4コアだよ。
マルチ構成に出来る（正式対応じゃない）Athlon XPとかが話題になったりした

H265のエンコードアルゴリズムって並列処理向きなん？

糞がつくほど並列処理向き

>>464
産業向けを含めていいなら
何があっても止まらないnonStopシリーズなんてのもあるけどな。
予算次第で最大4080プロセッサ(16,320コア)なんてのも組めるぞ。
お値段は一番安いものでせいぜい1000万円程度だがｗ

http://h50146.www5.hp.com/products/servers/nonstop/
http://h50146.www5.hp.com/products/servers/nonstop/hardware/nb56000c/specs.html

こんなサーバでエンコさせたらきっと持て余すだろうな。

>>465
SIMDは並列化しやすいらしい

>>468
そもそもSIMDは並列化の一種だろｗ

>>469
エンコード・アルゴリズムを理解してるわけじゃないから予防線を張った

>>470
SIMDはsingle instruction multiple dataの略で、訳せば
「一回の計算で複数のデータを処理する」ってことだよ
画像処理だとそういった機会は多いから、定番中の定番だと言える

>>466
メモリバスとかの競合考えなければスレッド数に応じてスケールしやすいわけね

Xeon、Xeon PhiやGPGPU向けの最適化が楽しみだな

>>473
Xeonどうせ買わないし....
(買えないなんて言ってないよ...本当だからね？)

H.264は整数演算だと聞いたことがありますが、H.265 も整数演算なんです？

ちなうんです

>>475
みたいよ
さらにGPGPUみたいなヘテロジニアスに適した仕組みも含んだ（とか含んでないとか）

>>477
どっちやねん！

これかな？
肝心のリンク先は確認してないけど

185 ：名無しさん＠編集中：2012/06/27(水) 18:04:30.54 ID:oc8wehwn圧縮率は「H.264」の2倍、超高精細やスマホを視野　動画圧縮技術の次世代国際標準「HEVC」
鈴木 輝彦 氏ソニー システム＆ソフトウェアテクノロジープラットフォーム 共通要素技術部門 信号処理技術1部 主任技師
http://techon.nikkeibp.co.jp/article/HONSHI/20120412/212513/
http://techon.nikkeibp.co.jp/article/NED/20120409/211909/

189 ：名無しさん＠編集中：2012/06/28(木) 00:20:19.54 ID:0L60umA2読んだけど一部要約すると
AVCは今から１０年以上前に仕様提起され標準化されたものでエンコードに使う演算装置がシングルコアで進化していく、
クロック数が右肩に上がっていくものと想定して難しいエンコード方法を採用して標準化されたんだとさ
HEVCは既存技術に魔法のような新技術を加えて劇的な圧縮率向上をはかるのではなく
既存技術を今主流のマルチコアCPU、GPU、並列処理への最適化と処理の簡略化、この１０年での改善をはかるみたい
最後のエントロピー符号化はCAVLCは廃止、進化したCABACへ一本化
その他新技術ももちろんある

HEVCスレが落ちてるからこちらに書いとこう
エロ業界が4kHEVCに対応し始めたぞｗ

http://www.knights-visual.com/main/category/item/%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA%E3%83%BC%E5%88%A5/4k/
Format : HEVC
Codec ID : V_MPEGH/ISO/HEVC
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps

エロ業界って最もHD化が遅い業界じゃないか
4k？どうでもいいわ

*皺がくっきり鮮明に！

各業界も4kよりカラーフォーマット何とかしてくれよ
いつまで8bit,420で押し通す気なんだと

>>483
具体的にどの業界のことを指してるのか知らないし自分もよく知らないけど、
既に映像制作現場とかじゃ10bit4:2:2とかが使われてるんじゃないの？

4Kはデフォで10bitだぞ
420だけどなｗ

表示の時点でこっそり8bitに落とされたとしても気付く人は少ないような気もする。

10bitなだけでもマシか…

赤の発色をいいかげんに何とかして欲しいな
アナログ時代が懐かしいぜ

基本的にブルーレイが8bit収録だからなー
MGVCが浸透するとは思えないしな

>>448
x264自体、エンコは糞遅いが画質がいいっていうエンコーダだったじゃん
エンコが高速化したのは、x264の最適化が進んだからじゃなく、CPU等PCが高速化したからだね

おそらく、x265も、速度より画質重視でいくだろうし、
エンコの高速化はCPUパワーが上がるのを待つしか無いんじゃ？

新スレ立てました

【2016】 H.265/HEVC Part4 【7680x4320】
http://peace.2ch.net/test/read.cgi/avi/1405488395/

>>490
x264自体2倍どころじゃ無いぐらい高速化したけどな
昔のデフォルト設定より今のsuperfastの方が画質が良い事を考慮して昔のデフォルトと今のsuperfastを比べるならば10倍近く速いな

>>492
そうなの？
今のオススメ設定方法教えて

>>493
１行目と２行目に何の関連性もないな

>>493
自分で設定できないのならデフォで良くね？と横から言ってみる

>>492
全盛期なんて○○が数%高速化って感じの更新がほぼ日刊で来てたよな

>>495
サンクス
最近更新してないので何処まで良くなってるか確かめてみるか

>>496
懐かしいな
でめちゃくちゃ高速化されたけどバグありでした〜というのもある意味楽しかった

>>493
--preset veryfast
midium比10%-20%圧縮率が落ちるが速度2-3倍ぐらい
速さと画質のバランスならここらが素晴らしいと思う

psyrdが使えるslowerがまともな速度になれば

DivX 10.2.2
http://www.divx.com/ja

更新履歴はまだ10.2.1までなんだな。速やかに更新してもらいたいもんだ。

>rc: add cli options for multi-pass rate control
来たな

それって重要なん？
ただのマルチパスじゃないの？

重要かどうかはさておき、指定サイズ or 指定ビットレートに合わせる時は必須になるし比較するときも2passでビットレートが揃えられるとメリットだと思うけど？
普段はCrfだけでいいと思うよ

そういや画質比較するときは2passがいいんだっけ

x264と画質比較する時に不自由だったからな