x265 rev4
■ このスレッドは過去ログ倉庫に格納されています
0104名無しさん＠編集中 (ﾜｯﾁｮｲ 9aec-h0dl)
垢版 |
2018/03/26(月) 01:10:10.16ID:xaZyoL940
rigaya氏のブログの「x265ビルド VC2017版」の記事に、

　x265 2.7+17 と L-SMASH r1459 の組み合わせで、L-SMASHが固まる

というコメントがあった。試してみたら、うちでも再現した。
2.7+14なら大丈夫らしいが、どちらが原因かはっきりするまで様子を見た方がよいかも。
0105名無しさん＠編集中 (ﾜｯﾁｮｲ 03ec-h0dl)
垢版 |
2018/03/26(月) 19:29:12.01ID:KAWe9XE/0
>>104
追加で少し試したので取り急ぎ100%再現パターンを。

●ソース： sample.avs （ffmpegでy4m化してx265へ）
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)

●x265コマンド(今のところ2passでしか再現できてない)
--pass1 --bitrate 1000
--pass2 --bitrate 1000

●muxerコマンド
muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4

●結果
muxer.exeが固まる。たまにクラッシュすることもある。
0107名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-h0dl)
垢版 |
2018/03/27(火) 15:23:43.35ID:lGCQMxzy0
>>106
試しに最新のL-SMASH rev1466(50ee6cb)をビルドしてみたけど、
>>105でL-SMASHのmuxer.exeが固まるという現象は変わってなかった。

2.7+16(5be53f0)でSEIの書き込みのとこを変えたようなので、そこがおかしいのか、
それともL-SMASH側のバグなのか。

自分はコードやストリームの解析まではできないので、作者や詳しい人の参戦を祈ることしかできぬ・・・。
0108名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-h0dl)
垢版 |
2018/03/27(火) 15:28:23.56ID:lGCQMxzy0
ちなみに2.7+17でも、

　ffmpeg-3.4.2.exe -r 30000/1001 -i sample.265 -c:v copy sample.mp4

　MP4Box-0.7.2-rev442-g508d7817.exe -add sample.265 -new sample.mp4

ではmuxも再生も特に問題なさそう。コケるのはL-SMASH muxerのみ。
0111名無しさん＠編集中 (ﾜｯﾁｮｲ 9716-zkh5)
垢版 |
2018/03/27(火) 18:34:20.56ID:hAwfzym80
>>107
折角俺も L-SMASH 常用なんで x265 と L-SMASH 共にさっき pull してビルドしたやつで
エンコから Mux してみたけど異常無しですわ。

x265 2.7+18 (1fb5ee43be2f) x64
muxer rev1466 (50ee6cb)

muxer.exe -i hogehoge.26x?fps=24000/1001 -o hoge.mp4
MP4 muxing mode
[HEVC: Info]: IDR: 1, CRA: 57, BLA: 0, I: 17, P: 1321, B: 3494, Unknown: 0
Track 1: H.265 High Efficiency Video Coding
Muxing completed!

なんて書いておいてあれだが 2pass はしないで crf 使うタイプなんでそのせいかな。
0112名無しさん＠編集中 (ﾜｯﾁｮｲ 03ec-h0dl)
垢版 |
2018/03/27(火) 19:35:05.90ID:zm8guuOZ0
>>111
問題の発生原因がはっきりしてないので、まだなんとも言えないんだよねえ。

例えば>>105で書いた100%再現の2パスエンコでも、sample.avsの末尾に
　Spline36Resize(640,360)
をつけて360pにした場合は問題は再現しない。
720pのままでも、x265で --preset slow または --preset fast をつけると問題は起きない。

適当に試した限りでは--crfでは再現してないのだけど、
原因がはっきりするまでは、「crfなら安全」とは言い切れない。
いつコケるかわからないし、知らない間に「一応再生できるけど規格的に異常なファイル」が作られてしまう可能性もある。

とりあえずL-SMASHの方にもIssue出しておいた。

　muxer freeze(or crash) when using x265 2.7+17 - Issue #82 - l-smash/l-smash
　https://github.com/l-smash/l-smash/issues/82
0115名無しさん＠編集中 (ﾜｯﾁｮｲ 63ec-h0dl)
垢版 |
2018/03/28(水) 14:01:27.08ID:bOMavOh+0
>>113-114
おお、ありがとう。x265側の問題か〜。オプションとかを格納してるSEIuserDataUnregisteredで
バッファ領域を超えて書き込んでるっぽいのかな？

できればそちらでDoom9かx265のIssueに出してきてもらえるとありがたいのだけど、どうだろう？

そちらで無理なようなら、その画像を以下のような出川ばりの英語で
Doom9に貼ってきてもいいんだけど、どうしよう。

---

x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered)
Not only 2pass encoding.

Left side: 2pass encoding
Right side: 1pass encoding
【画像】
0124名無しさん＠編集中 (ﾜｯﾁｮｲ caec-vJpg)
垢版 |
2018/04/10(火) 12:59:16.94ID:mvAZrsZe0
MulticoreWare achieves 18% performance boost on the x265 video codec with Intel AVX-512 Instructions for high quality encoding of 4K HDR content
https://multicorewareinc.com/news/multicoreware-achieves-18-performance-boost-x265-video-codec-intel-avx-512-instructions-high-quality-encoding-4k-hdr-content/

AVX-512を使って4K HDRコンテンツのエンコードで最大18%のスピードアップに成功したよという発表。
0125名無しさん＠編集中 (ﾜｯﾁｮｲ caec-vJpg)
垢版 |
2018/04/10(火) 13:16:00.32ID:mvAZrsZe0
MulticoreWare Forms OpenX Media Advisory Board (OpenX -MAB) with Industry Experts to Guide Open-source Media Codec Development
https://multicorewareinc.com/news/multicoreware-forms-openx-media-advisory-board-openx-mab-industry-experts-guide-open-source-media-codec-development/

訳：
MulticoreWareがOpenX Media Advisory Board（OpenX -MAB）を設立。
業界の専門家と協力して、オープンソースのメディアコーデック開発を支援。

オープンソースHEVCエンコーダx265の作成者であるMulticoreWareが、
OpenX-Media Advisory Board（OpenX-MAB）の設立を発表しました。
OpenX-MABの焦点は、x265のような現在および将来のオープンソースのビデオエンコーダの
開発ロードマップを主導し、メディア業界における関連性や普及を確実にすることです。
OpenX-MABは当面はHEVCエンコーディングのためのx265のリーダーシップを継続することに
重点を置くが、将来は他のオープンソースコーデックを含むように拡張するかもしれない。
MulticoreWareはOpenX-MAB拡大のため業界のエキスパートに声をかけている。
0134名無しさん＠編集中 (ﾜｯﾁｮｲ 23ec-ycE0)
垢版 |
2018/04/13(金) 02:22:20.69ID:NWyIYo2t0
というか、もう3.0のリリース準備に入ってるのね。

VMAFスコアの計算機能も入った模様。
cmake時に ENABLE_LIBVMAF をつけて、libvmafをリンクする必要あり。

　Add VMAF suppport to report per frame and aggregate VMAF score
　https://bitbucket.org/multicoreware/x265/commits/8bc1289c7a4b176d77b48e74716aea30e42766e7

　参考：
　　新しい映像の品質評価 libvmaf
　　http://nico-lab.net/libvmaf_with_ffmpeg/
0138名無しさん＠編集中 (ﾜｯﾁｮｲ a3ec-ycE0)
垢版 |
2018/04/13(金) 11:58:14.00ID:+CW60tiR0
ああ、でも ENABLE_LIBVMAF は完全にデバッグ用かも・・・？
ソースを読み違えてなければだけど、ENABLE_LIBVMAFをつけてビルドしたら
--recon（でかいYUVファイルも出力する）をつけないとエンコードできなくなるような・・・？
VMAF用のモデルパスも/usr/local/share/model/vmaf_v0.6.1.pkl固定みたいだし。
おとなしくffmpegで計測したほうがよさそうだ。
0139名無しさん＠編集中 (ﾜｯﾁｮｲ ffec-ycE0)
垢版 |
2018/04/13(金) 18:45:37.92ID:qCymtqNK0
rigaya氏の2.7+336のバイナリ、gccでビルドしたものと書かれてるけど、
--versionで見ると
　x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit
とかじゃなく
　x265 [info]: build info [Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
になってるのは、MSVCからgccを使ったということなんだろか？
（ビルドに詳しいわけじゃないので、ちょっと気になっただけ。変なこと言ってたらすまぬ。）
0140名無しさん＠編集中 (ﾜｯﾁｮｲ 73ec-ycE0)
垢版 |
2018/04/15(日) 02:04:37.98ID:3zo9kCKG0
rigaya氏の2.7+336のバイナリが最適化されたものに更新された模様。

> 2018/4/14 19:43にx265 2.7+336をここで紹介するgccで
> プロファイルによる最適化を実施した実行ファイルに差し替えました。
0142名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 15:36:59.22ID:YRWrQNWv0
ちょっと質問。
2.7+336-07defe235cde で --asm avx 付けてるとエラーで速攻落ちちゃうんだけどこれおま環?
ログみると「障害が発生しているモジュール名: ucrtbase.dll」とかでちょる。
--asm avx を外せばエンコできたけど Ryzen なんでどうしたもんかなと。
0144名無しさん＠編集中 (ﾜｯﾁｮｲ 73ec-ycE0)
垢版 |
2018/04/18(水) 17:18:59.94ID:HTI1sHZw0
うちのHaswellもrigaya氏の差し替え版バイナリで特に問題ないな。
ちゃんとコマンド書いてないからコマンド依存で発生する事象ならわからんが。
どういうソースをどこのバイナリでどういう設定で実行したのかくらいは書いた方がいいと思う。
0145名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 17:52:15.27ID:YRWrQNWv0
x265.exe 自体はオフィシャルなリポジトリ https://bitbucket.org/multicoreware/x265/wiki/Home から
pull して make-solitions.bat から high_bit_depth を ON にして VC2017 から x64 の release ビルドをやった物です。
その後弄ってみたけど、どうも --asm と --no-asm 何れかを入れ込むとエラー落ちするぽいです。
他の人が問題無いなら当方の おま環 ということですね。
0147名無しさん＠編集中 (ﾜｯﾁｮｲ 7f16-ycE0)
垢版 |
2018/04/18(水) 18:15:27.44ID:YRWrQNWv0
試しに rigaya 氏ビルドの物に差し替えたら --asm avx を入れてもエラーが出ずにエンコできますた・・・
自分の単純なビルド方法で今までこう言った問題は起きたこと無かったんで咄嗟に書き込んでなんだか申し訳なくorz 失礼しました!
0148名無しさん＠編集中 (ｽｯﾌﾟ Sd5a-Jb0y)
垢版 |
2018/04/19(木) 12:02:15.65ID:CAIRBG+rd
>>145
VSでビルドすると壊れる問題は、今の所stableブランチにだけ、修正が入ってる。

stable持ってきてビルドすれば動くよ。
まぁ、そのうちdefaultにも入るだろうけど。
0154名無しさん＠編集中 (ﾜｯﾁｮｲ 57ec-9jjH)
垢版 |
2018/04/20(金) 17:32:44.04ID:PbP8t3sj0
「なんとなく速くなってると思いました。まる。」みたいなこと書かれても・・・。
必要なのは環境やバイナリのバージョンや設定やソース等の情報も含めた正確な比較条件だと思うよ。
0156名無しさん＠編集中 (ﾜｯﾁｮｲ 8311-9jjH)
垢版 |
2018/04/20(金) 18:47:30.17ID:+I7QsHZu0
別に伝わらなくていいと思ってる（ryzenに興味あって調べてるならベンチスレででも覗けばいいだけ）
カキコした私が誤差程度と判断したから情報としてまとめなかったけども
0158名無しさん＠編集中 (ﾜｯﾁｮｲW fae0-ZOBi)
垢版 |
2018/04/20(金) 20:18:13.59ID:5wKx8vum0
来年24コアryzen2TPが出たとしてx265の特に重いプリセットでは全然使い切れないだろうなぁ
0159名無しさん＠編集中 (ﾜｯﾁｮｲ b67f-GiJP)
垢版 |
2018/04/23(月) 11:28:44.66ID:BRPMKJ720
先週IntelからRyzenに変更したのですがエンコする際に--asm AVXをつけろ　とネットでみたのですが
その理由がわかりませんでした
これはどういう意味があるんでしょうか？
また実際につけた方がよいものなのでしょうか？
0160名無しさん＠編集中 (ﾜｯﾁｮｲ 4b16-9jjH)
垢版 |
2018/04/23(月) 12:19:03.19ID:p76LCKVz0
AVX2 を使うと逆にエンコード速度が落ちるからだよ〜
AVX までに制限してやることで数 fps ほど速度あがる。
実際に --asm avx の有無でエンコ比較してみると良いかも。
0163名無しさん＠編集中 (ﾜｯﾁｮｲ b7b5-9jjH)
垢版 |
2018/04/23(月) 15:47:10.80ID:QffvhQ240
AVX2必須、みたいなアプリもあったりするかも知れんし機能があるに越したことはないとは思う
x264やx265でAVX2使うと若干とはいえ遅くなりはするけど動作しないわけでもないし知識があれば回避できるわけだしな
0166名無しさん＠編集中 (ﾜｯﾁｮｲ 93d2-2tE1)
垢版 |
2018/04/27(金) 20:48:13.46ID:1O42is100
過去ログにいくつかあるね
ただ作られたのがかなり前だしプリセットの内容も変わってるから今だと参考にならない

x265 rev2 [転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1418252184/301

301 名前：名無しさん＠編集中[sage] 投稿日：2015/03/31(火) 12:12:14.04 ID:9g7lReBC
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

x265 rev3©2ch.net
http://mevius.2ch.net/test/read.cgi/avi/1462270195/633

633 名前：名無しさん＠編集中 (ﾜｯﾁｮｲ 9f3e-YTUC)[sage] 投稿日：2017/04/28(金) 23:26:59.96 ID:eUzMgdEP0
>>632
一応>>631のグラフにx265 veryslowも追加してみたけど、
SSIM/bitrateグラフでのラインとしてはslow,slowerと大して変わりない感じだね。

　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3406.jpg
0173名無しさん＠編集中 (ﾜｯﾁｮｲ e111-Bw3Y)
垢版 |
2018/06/19(火) 18:25:04.97ID:uDXUEk/b0
やっぱり画質が良くなるオプションは重いのね
いつもなら終わってた量のタスクが終わってなかったは

それはそうと新AQモードの実装はまだかな
画質あがって早くなったら嬉しいんだけども
0180名無しさん＠編集中 (ﾜｯﾁｮｲ 4711-UVFs)
垢版 |
2018/07/08(日) 11:05:54.93ID:qBHDX1Nu0
ryzen環境だけどAVX2のほうが早かった
ブラウザ閉じたり厳密なテスト環境ではないけど

x265 [info]: HEVC encoder version 2.8+40-0106f9f2f867

x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
encoded 720 frames in 48.33s (14.90 fps), 2510.94 kb/s, Avg QP:27.02
encoded 720 frames in 48.85s (14.74 fps), 2510.94 kb/s, Avg QP:27.02

x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
encoded 720 frames in 45.10s (15.96 fps), 2510.94 kb/s, Avg QP:27.02
encoded 720 frames in 44.41s (16.21 fps), 2510.94 kb/s, Avg QP:27.02
0184名無しさん＠編集中 (ﾜｯﾁｮｲ e716-UVFs)
垢版 |
2018/07/08(日) 12:01:26.32ID:a2fe6VVL0
俺環での同テスト
あくまで --asm avx 有無のみの差異。

x265 2.8+40-0106f9f2f867

--asm avx 有り
encoded 2000 frames in 64.96s (30.79 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 65.35s (30.61 fps), 1828.98 kb/s, Avg QP:23.40

--asm avx 無しの AVX2 使用
encoded 2000 frames in 64.95s (30.79 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 64.63s (30.94 fps), 1828.98 kb/s, Avg QP:23.40

（参考）
2.8+23-656b5b442f0b で AVX2 使用。
encoded 2000 frames in 65.81s (30.39 fps), 1828.98 kb/s, Avg QP:23.40
encoded 2000 frames in 65.85s (30.37 fps), 1828.98 kb/s, Avg QP:23.40

ということで現状はまだなんともだけど >>180 氏の言うとおり Ryzen 環境でも
AVX2 を使った方が微妙に速くなるかもしれん。
0185名無しさん＠編集中 (ﾜｯﾁｮｲ e716-UVFs)
垢版 |
2018/07/08(日) 12:28:09.63ID:a2fe6VVL0
追試というか x265 に吐かせた csv なログがあるので昨日エンコしてたソースを再度 2.8+40 でエンコしたログの比較。

アニメソース 34523 フレーム

2.8+40-0106f9f2f867, AVX2 使用 = エンコ時間 840.63s, 平均 41.07fps
2.8+23-656b5b442f0b, AVX2 未使用 = エンコ時間 875.67s, 平均 39.42fps

コミットみると AVX2 周り色々良くワカランが弄られてるからなんか良くなったんかね。
家はこれで --asm avx を削れそうですわ
0188名無しさん＠編集中 (ﾜｯﾁｮｲ 4711-UVFs)
垢版 |
2018/07/08(日) 14:17:34.19ID:qBHDX1Nu0
まぁ、たしかに解像度などで処理の負荷や傾向も変わるからね

ryzen 1700X
実写1440x1080 （Aviutlのafsでテレシネ解除しguiEX出力）
オプションは設定のリセットを忘れて常用ので走らせたので、ログに記載されてるオプションをペタリ

--input-depth 16 --output-depth 10 --input-csp i420 --crf 25 --qcomp 0.72 --rc-lookahead 25 --vbv-bufsize 7000 --vbv-maxrate
7000 --aq-strength 1.2 --psy-rd 1 --deblock -2:0 --no-sao --subme 3 --merange 55 --rect --limit-modes --ref 4 --max-merge 3
--weightb --rd 2 --colormatrix bt709 --colorprim bt709 --transfer bt709 --sar 4:3 --no-opt-qp-pps
--no-opt-ref-list-length-pps --no-strong-intra-smoothing --input-res 1440x1080 --fps 30000/1001 -o
0189名無しさん＠編集中 (ﾜｯﾁｮｲ 67ec-UVFs)
垢版 |
2018/07/08(日) 14:21:18.43ID:HkL359170
>>187
なんで笑ってんのかよくわからんけど、データを出すなら普通にあったほうがいい情報だと思うけどね。
言及し忘れたけど、オプション設定も書かれてないので、そういった情報もあればいいなあとは思う。
0190名無しさん＠編集中 (ﾜｯﾁｮｲ e716-UVFs)
垢版 |
2018/07/08(日) 14:32:40.17ID:a2fe6VVL0
俺も環境かいとく流れかな

偶然俺も Ryzen 7 1700X で定格。
映像ソースはアニメで 1440x1080 から AVS で 960x720 にリサイズして SAR 4:3 としてる。

x265 に喰わせてる引数はこれだけ。>>184 でやったテストはこの引数に --asm avx を付けるかどうかってだけの違い。
--crf 19 --preset medium --input-depth 8 --output-depth 10 --aq-mode 3 --aq-strength 0.6 --sar 1:1 -o OUTPUT.265 INPUT.avs

AVS ファイルの中身は Trim してロゴ消しからのインタレ解除、ノイズ除去とスムーサー通してリサイズ、アンシャープマスクにデバンドやってる。
で Avisynth+ r2728-MT にやらせてる。

中でどういう処理させてるかでは多少なり変わってくるかもしれないけど、俺環では速くなったので
この事を書いてくれた >>180 氏には感謝。気付かなければずっと AVX2 使わないままだったと思うしｗ
0199名無しさん＠編集中 (ﾜｯﾁｮｲ 5d11-LQig)
垢版 |
2018/07/13(金) 20:09:01.25ID:phGGD7kZ0
low-bitrate帯でボケる？ それとも割り当てられるbitrateが少なくなるからボケるのどっち？

crf26でmax-merge 5だとボケた感じになった覚えはあるんだけど
0201名無しさん＠編集中 (ﾜｯﾁｮｲ 5d11-LQig)
垢版 |
2018/07/14(土) 22:41:08.93ID:YCb4PdI30
高ビットレートだとボケないのかな？っていうことを聞きたかったんだけど、そこまでは読み取れない？
上から目線であれだけど、英文の記号の使い方とかよー分らん
0203名無しさん＠編集中 (ｱｳｱｳｳｰ Sa21-0235)
垢版 |
2018/07/15(日) 14:13:15.85ID:jCJzclqYa
ビットレートに余裕があるときにどんな動きをするか聞きたいんじゃない
問答無用でマージしてビットレート下げに行くのか、余裕があるなら働かないのか
0209名無しさん＠編集中 (ﾜｯﾁｮｲ 52d4-53i4)
垢版 |
2018/07/29(日) 03:19:48.57ID:ofEesbc00
質問です。
エンコードするときに設定するビットレートの目安を求めたいのですが、
ttp://web.archive.org/web/20130207145934/http://service.jp.real.com/help/faq/prod/faq_4226.html
とか
ttps://www.lizardk.net/2011/05/h264.html
に書いてある式と、それで求められる値は当てにして良いものですか？
コーデックの話であって、エンコーダによって全然違うとかあるなら微妙なんですが・・・。

さらに、ここで求めた値を50%〜60%くらいにすればx265でのビットレートとして使えますか？
0212名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM6e-0lTB)
垢版 |
2018/07/29(日) 09:00:12.20ID:WkF14PaEM
x264は動画版lame(mp3高性能エンコーダー)みたく規格上のギリギリで高効率に圧縮してるからなぁ
x264はほぼ完成してるけどx265はまだ発展途上だからまだ半分は行けないよな
0213名無しさん＠編集中 (ﾜｯﾁｮｲ 7f11-53i4)
垢版 |
2018/07/29(日) 09:41:12.17ID:p8xSZ0wf0
>>209
real playerのころとは比べ物にならないぐらい圧縮率は向上してるから半分ぐらいでちょうどいいと思うけど
どのみちビットレート指定方式では仕組み的に高画質は無理（6Mbpsぐらいつぎ込めば話は別だけど
ま、基本的にcrfモードを使うのが推奨された使い方

x264なら crf=22~23、x265なら crf=24~26 がビットレートと画質のバランスがいい
0216名無しさん＠編集中 (ﾆｸｸｴ 52d4-53i4)
垢版 |
2018/07/29(日) 13:46:57.15ID:ofEesbc00NIKU
Shift+Enterしてしまったごめんなさい

VBRの最大ビットレートはこの2倍くらいにします、とあるんですが、
CBRに比べたVBRやCQPのビットレートの振れ幅というのは2倍や0.5倍の範囲内に収まるものなんでしょうか。

詳しい方いましたら教えてください。
0220名無しさん＠編集中 (ﾆｸｸｴ MM43-Dn8R)
垢版 |
2018/07/29(日) 14:40:29.28ID:nivXCK+nMNIKU
最大ビットレートなんて、再生環境が使える上限値にしとくだけだよ
これ以上にすると再生できなくなるから超えないようにエンコードしなさいという値なのだから
2倍とか関係ない
0221名無しさん＠編集中 (ﾆｸｸｴ MM33-0lTB)
垢版 |
2018/07/29(日) 15:27:57.92ID:wdaToWzEMNIKU
例えば地デジtsなら上限10Mbpsで十分だな
てか何故かテレビ放送の実写はcrfの割に縮まないのは何故？
nlmeansなんかの縮むようなやつ使ってもcrf25で5Mbpsとかいくし、x264なんて8Mbps行くんだが
特に紀行番組や旅番組
0230名無しさん＠編集中 (ﾌﾟﾁﾌﾟﾁ ffeb-avOC)
垢版 |
2018/08/08(水) 18:12:29.32ID:g31F+e9100808
--asm AVXオプション使うと各コア均等に使うけど
使わないと偶数コアを優先的に使って結果ブーストが
効いているようにタスクマネージャからは見える


金があればスリッパ入れたいけど、2700xでも全コア使い切りってまずないんだよなぁ・・・
0231名無しさん＠編集中 (ﾌﾟﾁﾌﾟﾁ e311-Xflc)
垢版 |
2018/08/08(水) 21:56:58.29ID:dOumIDyx00808
>>230
AVX2使ってると実行ユニットをロックする（非SMT状態になる）みたいな感じかな？
でも使うと遅くなってた頃もあるから
x265で最適化が入ったかAVX2のコードの効率性が上がったかのどちらかかな
0232名無しさん＠編集中 (ﾜｯﾁｮｲ 6fc3-2km2)
垢版 |
2018/08/12(日) 00:10:58.10ID:aqFe3uD60
CPUのコア数が多いとどうしても余ってるコアが出てきちゃうから
ちゃんとした比較にならないんだよな

実際にエンコードするときは4〜6コア/exeくらいで並列でやるんだから、
ベンチマーク取るときもアフィニティ設定してコア数制限して測って欲しいわ
0235名無しさん＠編集中 (ｱｳｰｲﾓ MM2f-E5g5)
垢版 |
2018/08/14(火) 13:13:04.01ID:RAVBN7h8M
x265は、GPUによるエンコードの分担処理（※GPU内蔵のハードウェアエンコーダーは使わない）とかはできないんだよね？
1から10まで全部CPUでガリガリやるのではなく、部分的にGPUに任せる仕組みを導入してほしい
0237名無しさん＠編集中 (ﾜｯﾁｮｲ ff98-irNJ)
垢版 |
2018/08/14(火) 16:07:23.83ID:WtdvOqlK0
>>235
えーと
まぁ、いいや
0239名無しさん＠編集中 (ｱｰｸｾｰ Sx03-NQOt)
垢版 |
2018/08/14(火) 17:28:15.41ID:Ias8+6vNx
x264やx265ならGPGPU移植出来そうだが、マイニングソフトとちがって報酬ないからなぁ
1080tiならRyzenThreadripperを軽く越えるぐらいのエンコ速度出そうだけど
0244名無しさん＠編集中 (ﾜｯﾁｮｲ 9fec-2km2)
垢版 |
2018/08/15(水) 11:42:18.88ID:RPYkSQGg0
x264スレが落ちてるからこっちに書くけど、8/6にx264の更新(r2932？)があった模様。
主な内容としては、
　●i400(monochrome)エンコードのサポート （4:0:0 (monochrome) encoding support）
　●--avcintra-flavorの追加 （Add Sony XAVC, a flavour of AVC-Intra）
といったところかな。
0246名無しさん＠編集中 (ﾜｯﾁｮｲ 9feb-WJ3a)
垢版 |
2018/08/17(金) 23:58:02.69ID:LnVWCjgx0
>>240
別に1から10まで全部GPUにやらせようって話ではない


Intel「CPUで全部やる、AVXも512bitに拡張だ、まあ最適化したいならICC買ってね？」
AMD「CPU/GPUでリソース配分したほうが開発コストも演算コストも安くね？」

個人的にはAMDが正しいと思うけど、とはいえAVX2くらいは普通に実装してほしかったかなぁ・・・
0248名無しさん＠編集中 (ﾜｯﾁｮｲ 3bc3-ipLS)
垢版 |
2018/08/18(土) 00:52:04.94ID:3rhQHUTk0
IntelやAMDがソフトウェアを実装するわけじゃないから、勝手なことをいくらでも言えるわな
AMDはGPUも使えって言うんだったらx265をGPU化してみろってんだよ
0251名無しさん＠編集中 (ﾜｯﾁｮｲWW cb1b-0Gel)
垢版 |
2018/08/18(土) 01:26:43.79ID:9fCL5XG50
多用されてる離散コサイン変換はGPGPUで結構高速化出来るし
動きベクトル探索も良い研究成果が上がってきてるよね
開発環境整ってくれば期待できそう
0252名無しさん＠編集中 (ﾜｯﾁｮｲ 8b11-ipLS)
垢版 |
2018/08/18(土) 10:12:54.04ID:pf+FKHdi0
>>250
意味ないね
で、CPUの処理の中からGPUに適した処理をアウトそーソングしやすくしよう！って考えたのがAMD（のブラフィックス内蔵SoC）
ところが規模の問題などから性能メリットが少なくその方針は下火になったけど
GPUへ自動で処理を投げるコンパイラは今も開発継続中（x265開発してる会社へ譲渡して、のはず）
0256名無しさん＠編集中 (ﾜｯﾁｮｲ 4a60-4tvA)
垢版 |
2018/08/24(金) 19:03:44.23ID:ehs1hyuL0
個人デベロッパーがGPLでAMDでx265のGPU対応化とかさせるのならどうにでもできると思うけど
それと同じことを法人が勝手にやると最悪、つまらない訴訟騒ぎに発展するだろうな。
0262名無しさん＠編集中 (ﾜｯﾁｮｲ 29c3-PcWx)
垢版 |
2018/08/25(土) 01:11:30.72ID:DovDn/Ya0
GPLは大雑把に言うと、「バイナリ配布したらソース公開は必須」ってライセンス
企業側から見た問題は（個人でも変わらんが）「ソース公開必須」って部分

元々公開する気なら何の問題もない
企業がコミットしてるオープンソースなんて世の中いっぱいあるし、
むしろ、まとまった機能は企業からコミットされることのほうが多い
x265だってメインの開発者はMulticoreWareって企業でしょ

HEVCのパテントについては、radeonには既にHEVCのエンコーダが乗ってるんだから、
AMDがradeonで動くHEVCのエンコーダをドライバと一緒に配布しても追加コストはあまりないはず

問題があるとすれば、公開されたGPU対応コードが他の企業によって移植されて
geforceでも動くようになってしまう確率が高いこと

実際はそれが問題だろうね
自社の製品が売れるようにならなくちゃ企業は動かない
0263名無しさん＠編集中 (ﾜｯﾁｮｲ 29c3-PcWx)
垢版 |
2018/08/25(土) 01:41:52.75ID:DovDn/Ya0
あと、MulticoreWare以外の外部が開発したGPLの改変部分は、MulticoreWareが取り込むことはできないから、
オープンコミュニティでメンテする必要があるだろうね

MulticoreWareはx265の「ソースを公開する必要がないライセンス」も売ってるから、
他社が作ったGPLコードを取り込むと、それができなくなってしまう

個人の開発者も含めx265にコードを取り込んで欲しい場合は、
コードのライセンスを完全にMulticoreWareに譲渡する契約書を書かされるはず

オープンソースと言ってもいろいろある
0265名無しさん＠編集中 (ﾜｯﾁｮｲ d998-Kyiw)
垢版 |
2018/08/25(土) 15:19:58.90ID:B/A2lGb50
俺の理解だと、学術研究目的なら著作権問題を回避できるからオープンソースでしか配布できない
オープンソースといえどもそのソースに著作権は発生してその形は様々
0267名無しさん＠編集中 (ﾜｯﾁｮｲ 4a60-4tvA)
垢版 |
2018/08/27(月) 22:45:13.94ID:UkDWU1xZ0
>>266
x264エンコのニーズは依然健在だろうけど、
5ちゃんねるのスレ建て＆20レス保守がクソめんどくさいだけじゃないかと
x264もx265もエンコパラメータ次第でどっちでもそれなりの画質を維持できるし
使いたい方を使えばいいと思うけど。ちゃっちゃとエンコを済ませるならx264が適当だろう。
0273名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM35-gOc9)
垢版 |
2018/08/28(火) 11:42:07.42ID:OK6RUHGlM
>>272
45分ドラマ録画をエンコして400MBにするのか
へぇ
そしてBDとかにまとめ焼き？

基本的にはHDDに放送録画しても半分見ないで消すくらいだから、そうやってライブラリー残すために高圧縮でも綺麗という評価軸がなくなったよ

編集するのに、そこそこ軽くて扱うのが楽なCODECと設定だと、イントラ圧縮に落ち着く
XAVC-IもAVC-Intraも、イントラ内はH.264だと思ったけど違ったかな？
0274名無しさん＠編集中 (ﾜｯﾁｮｲ 6a11-PcWx)
垢版 |
2018/08/28(火) 14:18:09.97ID:mVsKTCut0
>>273
普通にお外付けHDDに溜め込んでる

自分は見ずに消すことなまずないな
かと言ってすぐ見るわけじゃなく、ある程度、話数が溜ってから・・とts保持し続けたらHDD容量が足りない
だからエンコードするわけだけど、せっかくエンコードしたものを消すのは忍びないって感じで見終わっても残してる
0279名無しさん＠編集中 (ﾜｯﾁｮｲ 6a11-PcWx)
垢版 |
2018/08/29(水) 10:08:51.88ID:PTb4PESu0
>>278
「いや」って否定される覚えはないが・・
VHSでとってたものは目ぼしいものだけサルベージした

ま、金銭感覚は人それぞれだから私は否定しないが
年単位でのコスパでいえば大した違いはないと思う（PCの初期投資は除く
0287名無しさん＠編集中 (ﾜｯﾁｮｲ 8bdc-P9Fo)
垢版 |
2018/09/02(日) 19:33:44.42ID:DuBTtQDB0
::::::::::::/　　　　　　　　　　ヽ::::::::::::
:::::::::::i　　キ　　じ　　ミ　　i::::::::::::
:::::::::::.ゝ　モ 　 つ 　.ネ　 ﾉ:::::::::::
:::::::::::/　 イ　　に 　 オ　ｲ:::::::::::::
:::::　 |　　な。　　　　は　ﾞi　　::::::
　　　＼_ 　　　　　　　 ,,-'
――--､..,ヽ__　　＿,,-''
:::::::,-‐､,‐､ヽ.　)ノ　　　　　　＿＿＿＿
:::::_|/ ｡|｡ヽ|-i､　　..　　　 ／ 淫厨
／. ` ' ● '　ﾆ ､　　　　（＿＿＿＿人
ニ　＿_ｌ＿_＿ノ　　　　（-◎-◎一
/￣　＿　　| i　　　　　（　(_　_)
|(￣`'　　）/ /　,..　　　 （　ε　 　（∴
`ー---―' / '（__ ）　　　ヽ＿＿＿＿
====（ i）==::::／　　　　　　,/ﾆ
:/ 　　 　ヽ:::i　　　　　　　/;;;;;;;;;;;;;;;;
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況