x264 rev43©2ch.net

2017/01/28(土) 12:06:57.70

Q ニコニコ用の動画を作りたい。
A 板違い。Youtube板の"FLV/MP4エンコードスレ"でどぞ。

Q 圧縮codecありませんか？AviUtlのx264guiEx.auoの使い方は？
A x264 VFW GUI専用スレでどうぞ。
　　　x264vfw GUI専用スレ Part9
　　　http://peace.2ch.net/test/read.cgi/avi/1351856057/

Q コマンドラインの使い方が分かりません
A 初心者スレでどうぞ。
　　　x264 初心者質問スレ part6
　　　http://peace.2ch.net/test/read.cgi/avi/1347527423/

[本家]
http://www.videolan.org/developers/x264.html
http://git.videolan.org/?p=x264.git;a=summary (ソース/チェンジログ)
http://web.archive.org/web/20150419065724/http://x264dev.multimedia.cx/ (開発者ブログ跡地)
http://web.archive.org/web/20141203142708/http://doom10.org/index.php (公式フォーラム跡地)
irc://irc.freenode.net#x264(ユーザー用IRCチャンネル）
irc://irc.freenode.net#x264dev(開発者用IRCチャンネル）

**名無しさん＠編集中** (ﾜｯﾁｮｲ a9ec-DRuk) · 2017/10/26(木) 17:37:30.49

>>603
うーん・・・うちでそれらの画像を>>593（うちのIntel環境の結果）と比べると以下のように全然違って見えるけど・・・。

１番目（NV12+EVR）
　少しバンディングの出方が異なるが、「EVRCP-NV12」とほぼ同じくらい。

２番目（P010+EVR）
　P010出力なのに、３つの中で画質が最も酷い。細めの汚れたバンディングがはっきり見える。
　「madVR-P010-ditherOff」で生じているバンディングを更に悪化させたような感じ。
　「EVRCP-P010」や「madVR-P010-ditherON」の方がはるかに綺麗。

３番目（NV12+EVR(10bitサーフェス)）
　「madVR-NV12-ditherON」と似てはいるが、ざわつきが酷く画質としては劣る。
　バンディングがほぼ気にならないレベルになってるのは
　10bitサーフェスをデスクトップ(8bitRGB)に統合する時に、もう一度ディザリングしているのかな？
　結果的にバンディングが目立たなくなっているとはいえ、無駄な処理をしているとも言えるような。

うちはノートPCでモニタも6bit+FRCなTNというショボ環境だから、他の人の結果や意見も聞いてみたいところ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ a9ec-DRuk) · 2017/10/26(木) 17:45:49.30

>>603
２番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも？

>>604-605
> Intelグラはディザリングしないんだね

ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」（LAVがレンダラに渡しているデータ）と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。

>>610
部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー？

**名無しさん＠編集中** (ﾜｯﾁｮｲ a9ec-DRuk) · 2017/10/26(木) 17:58:50.33

まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
それを避けることもできるしLAVとも連携して開発されていて多機能高性能で自由に設定可能なmadVRを使った方が
手っ取り早く安定した高画質が得られるとは思う。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9111-Akqv) · 2017/10/26(木) 19:59:26.61

スケーラー的には
カスタムEVRのほうが比較対象になりえるかと

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9a5-20SA) · 2017/10/26(木) 22:29:15.67

>>611
こちらは4Kブラビア（KJ-49X8300D）にAVアンプ（AVR-X2100W）経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9a5-20SA) · 2017/10/26(木) 23:26:47.90

>>613
確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ a9ec-DRuk) · 2017/10/27(金) 00:05:48.90

>>614
スケーラーってなんぞ？madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな？

>>615-616
8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・？
>>611に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060＋そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9a5-20SA) · 2017/10/27(金) 00:52:10.89

>>617
> EVR-CPのP010処理が何か変

おかしくはないよ
うちの環境で「BE-白050-線-EVRCP-P010」を写してカメラで撮ってみた

>>593の画像
https://i.imgur.com/xPCZlun.jpg

>>603の画像
https://i.imgur.com/A5KuEHh.jpg

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9a5-20SA) · 2017/10/27(金) 01:02:44.22

一応、俺の感想を言うと
>>593の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる

ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9111-Akqv) · 2017/10/27(金) 09:54:55.94

>>617
EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず

だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも

**名無しさん＠編集中** (ﾜｯﾁｮｲ 13ec-DRuk) · 2017/10/27(金) 21:30:55.30

>>618-619
申し訳ない。こちらがボケてました。
　> 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。

もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。

>>620
拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9111-Akqv) · 2017/10/27(金) 23:21:04.83

>>621
プルダウンで簡単に使えるのが利点っちゃ利点＞EVRカスタム

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9a5-Akqv) · 2017/10/28(土) 12:50:01.41

>>621
白111-P010-EVRCP(8bitサーフェス)
https://i.imgur.com/ZL3n0Ai.png

**618** (ﾜｯﾁｮｲ d9a5-Akqv) · 2017/10/28(土) 12:51:23.89

ID変わってた

2017/10/28(土) 14:34:52.13

サンプルは>>516が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw

2017/10/28(土) 16:07:06.26

バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな？
例えばWOWOWの映画開始前の「これから流しますよ」的なタイトル絵がバンディングすごいけど、あれを低減できるレベルに設定値すればいいの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ a9ec-DRuk) · 2017/10/28(土) 22:29:00.96

>>623
ありがとうございます。参考にさせてもらいます。

>>626
そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9111-9/99) · 2017/10/28(土) 23:31:24.66

>>626
基本的にソースにあるバンディングを消すものだよ
けど、ソースを少なからず弄るものだから
冒頭の極端なものは無視するが吉

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1334-aAnL) · 2017/10/29(日) 09:40:11.40

MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ ebe8-caiW) · 2017/10/29(日) 09:43:54.16

no-info パラメータって x264 にはないんだっけ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ ebe8-caiW) · 2017/10/29(日) 09:45:36.07

>>630
あったとしても、エンコード日付までは消せないか
ソースいじって自ビルド使うしかなさそう

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sd33-j0vi) · 2017/10/29(日) 10:25:41.22

エンコード日とかって
muxし直したら新しく書き換えられるから
x264とはまた別じゃないかな？

**名無しさん＠編集中** (ﾆｸｸｴ 13ec-DRuk) · 2017/10/29(日) 12:30:57.98

>>632が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから
Muxだけやり直せば上書きされるはず。

**名無しさん＠編集中** (ﾜｯﾁｮｲ ebe8-T257) · 2017/10/30(月) 09:36:19.37

muxプログラムを改変する

**名無しさん＠編集中** (ｱｰｸｾｰ Sx9d-egjV) · 2017/10/30(月) 15:01:11.04

わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな

**名無しさん＠編集中** (ﾜｯﾁｮｲ ebe8-T257) · 2017/10/30(月) 15:02:21.57

P2Pなんでまだあんのか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ d1ec-DRuk) · 2017/10/30(月) 15:49:28.52

違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。

**名無しさん＠編集中** (ﾜｯﾁｮｲ d1eb-ogJj) · 2017/10/30(月) 16:38:40.79

ボクが一番早くエンコしたんだッ！

**名無しさん＠編集中** (ﾜｯﾁｮｲ 1334-aAnL) · 2017/10/30(月) 20:41:33.46

ファイルの並び順を作成日時でソートしているのですが
エンコードにミスがあったものをやり直すと話数順と合わなくなるので
作成日時を書き換えて合わせていました。
ですが、エンコード日やタグ付け日が作成日時と合っていないことが
個人的に気に入らなかったので質問させていただきました。
質問に答えていただき、ありがとうございました。

**名無しさん＠編集中** (ﾜｯﾁｮｲ d360-H4ak) · 2017/10/31(火) 11:38:38.08

>>635
デカ過ぎるcrf値にしていたり、ダイエットし過ぎたbitrate値にしているのをバレたくないとかじゃね？

**名無しさん＠編集中** (ﾜｯﾁｮｲ d360-H4ak) · 2017/10/31(火) 11:45:43.27

あとはme dia にしてるのをバレたくないとかw

2017/10/31(火) 12:28:54.81

>>639
それなら単純にファイラーで作成日時いじればいいだけなのは明らかにわかる
火消し必死な自称エンコ職人の違法アップロード野郎

**名無しさん＠編集中** (ﾜｯﾁｮｲ a9ec-DRuk) · 2017/10/31(火) 14:36:40.95

>>640-641
>>629が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。

>>642
「（ファイラーで）作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 13d2-kgpv) · 2017/10/31(火) 18:31:40.36

>>641
ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ

2017/11/05(日) 19:56:26.63

x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか?

2017/11/05(日) 22:57:38.08

悩む必要ないだろ

2017/11/06(月) 09:49:57.89

>>645
両方ともグリスバーガーだから、オーバークロック前提ならRyzenスレッドリッパー1950Xだろ
殻割りで壊すリスク冒すなら7920Xでもいいが

2017/11/06(月) 12:20:23.32

オーバークロックはしない前提で
1 定格クロックは7900xの方が高い
2 x264のマルチスレッド効果は20位で頭打ちとの説を見かける
3 もちろん7900xの方が安い
この辺を考慮すると7900xを買った方が幸せとの意見はないでごわすか?

**名無しさん＠編集中** (ｽｯｯﾌﾟ Sd62-2eRG) · 2017/11/06(月) 12:45:07.90

スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
毎回1本しかエンコしかしないなら7900Xにしとけば？
それでもコア数多い7920Xの方が速いだろうけど

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2260-apvC) · 2017/11/06(月) 13:05:09.71

threadsを最大にしても、殆ど全部使い切らないx264で
より多くのcoreを割り当てたところで速度アップにも画質(ソース画質の再現率)向上にも繋がらんよな。
それならいっそx264を経由する重めのavsフィルタ内部でより多くのcoreを割り振った方が
エンコ速度も画質向上も大きく改善できてメリットも増そうなもんだが。

Avsフィルタ類はCPUよりグラボに処理させてもいいんだけどな。
APU以降ならVCEを、APU未満でDX9を使えるグラは_GPU25で、NV系ならCUDAなどで。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 92eb-Q/5A) · 2017/11/06(月) 13:12:22.24

4～8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた

2017/11/06(月) 16:34:37.78

貴重なご意見いろいろと感謝でごわす。

2017/11/07(火) 09:07:41.08

並列でエンコードすればよいのでは？

2017/11/07(火) 09:14:27.30

良いプラグインを選んだり自分で最適化ビルドして
うまいことavsを書けばコア数の多さを
純粋に速度upに繋げることはできる

**名無しさん＠編集中** (ｽｯﾌﾟ Sd62-NeHO) · 2017/11/08(水) 15:50:54.81

x264のソースで、
参照しているマクロブロックについて
書かれているところが分かる人いないかな？

2017/11/08(水) 21:48:17.18

CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね

intel vtune買えるほど、こずかいあったら解析してみたいなー

2017/11/08(水) 21:53:09.78

メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない

**名無しさん＠編集中** (ｱｰｸｾｰ Sx33-WtbZ) · 2017/11/09(木) 03:55:05.26

x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
対応してたとしても、例えばHuffyuvのデコードは4スレッドまでしか対応してないし
あとは、ドライブの転送速度が追い付いてないとか

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5f11-02TF) · 2017/11/09(木) 12:08:59.88

>>656
h.264の基本設計が古いのが原因

2017/11/09(木) 21:23:04.94

>>659
は？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7feb-lB0v) · 2017/11/09(木) 23:26:26.85

>>648
6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな

**名無しさん＠編集中** (ｽｯｯﾌﾟ Sd9f-voEu) · 2017/11/10(金) 01:06:53.06

>>661
Doomで中の人が言っていたから本当
だが、それはSDサイズの話だろう
SDで6950Xだと70%くらいしか使わないんじゃないか？

2017/11/14(火) 22:36:13.81

x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる？

公式より、ちょこっと高速かも。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7f8a-ySnM) · 2017/11/14(火) 23:31:21.00

バイナリよりもソースコードが欲しい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5fc6-Ud84) · 2017/11/14(火) 23:54:34.74

最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
あれが対応しないと微量(6-8fps前後)だがエンコ速度に差が発生するから損した気分になる。

2017/11/16(木) 12:20:04.93

x264をvtuneで解析する方法

./configure ―extra-cflags=“-g3 -gdwarf-2”

**名無しさん＠編集中** (ﾜｯﾁｮｲ 419f-CT75) · 2017/11/16(木) 21:39:08.85

下手に触ったら、弄りすぎて壊れた…

x264の内部

関数内の処理時間順
ttp://iup.2ch-library.com/i/i1868333-1510835655.png
呼び出し回数順
ttp://iup.2ch-library.com/i/i1868332-1510835582.png

**名無しさん＠編集中** (ﾜｯﾁｮｲ 419f-CT75) · 2017/11/18(土) 15:36:47.29

Intel C compilerで作った x264@0.152.2851
https://dotup.org/uploda/dotup.org1391216.zip.html
ソースは、弄ってないバージョン

バイナリの環境はSandybridge以降に依存
依存したDLLとか調べてないから、動かなかったら教えて。

自分でビルドしたい人は、ｍｓｙｓのlinkerをmvしたりしないと通らないから要注意

**名無しさん＠編集中** (ﾜｯﾁｮｲ 25c6-bpph) · 2017/12/03(日) 22:51:56.93

>>667
その画像、jane styleでdecode errorになるのだが・・・つかえねぇなほんと。
画像うpするなら自分で消さなきゃなかなか消えない、imgurを使えよ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3d9f-GQwd) · 2017/12/03(日) 23:17:58.10

俺のjane styleではちゃんと表示できてるぞ
むしろimgurのがdat入れたりせにゃあかん

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9e11-HgL3) · 2017/12/03(日) 23:48:24.68

今、ブラウザでアクセスしたけどリンク切れだったよ
専ブラのキャッシュに残ってるのでは？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 25c6-bpph) · 2017/12/03(日) 23:55:28.12

結局janeのビューアが改善すればいいだけの話か。
susieプラグインとか2004年頃から更新されてないもんな・・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 937f-3E9j) · 2017/12/23(土) 15:27:24.06

r2345
誰か持って無いですか？VLCのはx264guiExに怒られるし
kmodはアーカイブ辿ってもないし

**名無しさん＠編集中** (ﾜｯﾁｮｲ a3ec-615/) · 2017/12/23(土) 21:21:11.03

>>673
怒られるっつっても
　　指定されたx264.exeはmp4出力に対応していません。
　　出力拡張子を".264"に変更して出力を行うため、muxが余分に発生し、時間がかかる可能性があります。
　　mp4出力に対応したx264.exeを使用することを推奨します。
と出るだけだから、何か試す程度ならVideoLANのバイナリでいいと思うが・・・。

muxがどれくらい遅くなるのかは知らないけど、わざわざr2345を常用したい理由でもあるの？
x264guiExも最新のバイナリにあわせて更新されてるから、
古いバイナリを使ったら設定値が思うように反映されなかったりすることもあるけど。

**名無しさん＠編集中** (中止 7398-GItX) · 2017/12/24(日) 13:25:40.34

自ビルドすればいい
たいして、手間はかからないだろ
何をしたいのか理解できないけど

**名無しさん＠編集中** (中止 cfe8-H9DT) · 2017/12/24(日) 13:47:04.26

ソースもみつからないんだろうよ

**名無しさん＠編集中** (中止 03c6-RBuR) · 2017/12/25(月) 00:09:20.14

>>673
つ ttps://www.solidfiles.com/v/XGnzXKeZQ8kWp

**名無しさん＠編集中** (中止 03c6-RBuR) · 2017/12/25(月) 00:12:41.45

基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ
でないともれなくウザいジャンクマルウェアがブラウザをフリーズさせようとするからw

**名無しさん＠編集中** (中止 03c6-RBuR) · 2017/12/25(月) 00:40:15.29

r2345にこだわる理由はおそらくこれじゃないか。
AMD環境でエンコするときは、r2345以降だと拡張命令が一つ無効にされるから
若干エンコが遅くなる。そこはryzenで改善されたけど

r2346
commit 0c738e30ec025f0effdb62802685fce40cf20057
Author: Henrik Gramner
Date: Fri Jul 5 21:15:43 2013 +0200

x86: Remove X264_CPU_SSE_MISALIGN functions
Prevents a crash if the misaligned exception mask bit is cleared for some reason.
Misaligned SSE functions are only used on AMD Phenom CPUs and the benefit is miniscule.

---
x86: X264_CPU_SSE_MISALIGN関数を削除。
何がしかの理由でmisaligned exception mask bitがクリアされていた場合のクラッシュを防ぐ。
Misaligned SSE関数はAMD Phenom CPUでのみ使用され、その利得は非常に小さい。

**名無しさん＠編集中** (中止 73b5-buzn) · 2017/12/25(月) 12:34:34.96

ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから
買い換えるという選択肢がないかもしれないけどRyzenはマジで優秀だからな
それなりにエンコする機会があるなら買って損はないと思う
性能がそこそこ優秀な割に異常に安価な1500Xあたりで組めばそれなりの価格で収まるし電気代も優しい

**名無しさん＠編集中** (中止 237f-3E9j) · 2017/12/25(月) 16:35:53.17

>>677
ありがとうございます。理由は>>679氏の指摘です
本当に助かりました

**名無しさん＠編集中** (中止 6f11-buzn) · 2017/12/25(月) 17:43:40.36

たしかそれ以降にもAMD向けのはガッツリ削られたんだっけ？＞XOPとか

**名無しさん＠編集中** (中止 Sx87-/Td7) · 2017/12/25(月) 18:01:10.84

>>680
ryzenAPU(GPU内蔵)が来年頭に出るらしいから、コンシューマ向けだとそれで完全に事足りるわな
ただし4コアしか出さないらしい

**名無しさん＠編集中** (中止 03c6-RBuR) · 2017/12/25(月) 19:28:13.40

余談だが、ブル世代のAPUとFXもMisaligned SSEが使えるわけだけど、それも無効にされている。
APUはVCEでハードエンコできるからまだいいが、FXは限界までOCしてゴリ押しするしか無いんだよな。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 638a-7LW1) · 2017/12/26(火) 11:10:32.20

r2893

**名無しさん＠編集中** (ﾜｯﾁｮｲ cf90-2X9o) · 2017/12/27(水) 21:16:05.28

暖房用にx264を全力で走らせてるんだが中々部屋が暖まらない寒いよー
冬季向けりヴぃじょんとかありますか？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 13a5-buzn) · 2017/12/27(水) 21:32:58.33

フィルタ処理をGPUにやらせて、PC台数も増やせば結構暖まるよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ f346-cSU3) · 2017/12/27(水) 23:48:27.66

PCの排熱を使用した暖房機器で電気代タダってのが外国でやってなかったっけ

**名無しさん＠編集中** (ﾜｯﾁｮｲ af17-M2I0) · 2017/12/28(木) 01:23:11.91

マイニング

**名無しさん＠編集中** (ﾜｯﾁｮｲ 3aeb-RYVm) · 2017/12/28(木) 01:42:45.33

副次的に温まるのは仕方がないが暖房に使おうという発想はおかしい

**名無しさん＠編集中** (ﾜｯﾁｮｲ ffb5-Auke) · 2017/12/28(木) 02:17:54.51

電熱による暖房は効率が悪いからな
電気暖房で効率重視なら現状ヒートポンプ一択
とはいえコスト度外視ならハイエンドPCを2台もフル回転させれば多分ちょっとしたセラミックヒーターくらいの発熱はあるはず
ただ熱を垂れ流すしか能がないヒーターよりは何らかの仕事をさせられる分だけ建設的なのかも知れん

2017/12/28(木) 02:31:54.29

いや～ん

**名無しさん＠編集中** (ﾜｯﾁｮｲ cbec-O50F) · 2017/12/28(木) 13:39:09.46

なんとなくr2893メモ

・8bitと10bitのバイナリを統合
　→１つのバイナリで8bitも10bitも出力できる。
　→出力ビット深度は、追加された --output-depth で指定。デフォルトは8bit。

・--transferに arib-std-b67 を追加。(HLG：Hybrid Log Gamma)
・--colormatrixに chroma-derived-nc / chroma-derived-c / ICtCp を追加。
　→2017年4月のH.264規格書で追加されたもの。

・--alternative-transferを追加
　→2017年4月のH.264規格書で追加されたもの。

・その他の細かいコミットは割愛

・--fullhelpでのqpmaxのデフォルト値表示がおかしい。
　　--qpmax <integer> Set max QP [2147483647]

・x264guiExの8/10bit統合対応が地味に面倒そうではある。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 83c6-SYER) · 2017/12/28(木) 14:26:10.04

10bitでエンコしてると8bitでエンコする機会なんて格段に減ると思うのだが。

**名無しさん＠編集中** (ｱｰｸｾｰ Sx03-JsY/) · 2017/12/28(木) 14:28:57.26

放送物はBDMV準拠で保存してるから、逆に10bitでエンコする機会がない

**名無しさん＠編集中** (ﾜｯﾁｮｲ f316-Auke) · 2017/12/28(木) 15:30:50.89

自分の好きなようにしたらエエ。
俺は PC で再生するだけだから 10bit 派。
そのくせ BlueskyFRC を挟んでFluid Motion してるから余り意味が無いという。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 83c6-SYER) · 2017/12/28(木) 16:45:46.07

x264.exeにフィルタ機能とかリサイズ機能とか正直いらないんだよな。
そういうのはAVSでやらせりゃいいんだし。

2017/12/28(木) 17:58:21.58

linuxでもWindowsでも同じようにフィルタかけられて便利

**名無しさん＠編集中** (ﾆｸｸｴ cbec-O50F) · 2017/12/29(金) 21:05:04.38

x264guiEx 2.53、r2893バイナリ対応

**名無しさん＠編集中** (ﾜｯﾁｮｲ 67fa-MiNv) · 2017/12/31(日) 11:38:00.81

誰でも自分ＰＣで稼げる方法など
参考までに、
⇒　『政道のゴウイウセレイイ』というＨＰで見ることができます。

グーグルで検索⇒『政道のゴウイウセレイイ』

A6L4JIAVLJ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0a0e-Auke) · 2017/12/31(日) 12:00:58.03

Komiser更新されないなあ

**名無しさん＠編集中** (ﾜｯﾁｮｲ cbec-O50F) · 2017/12/31(日) 13:19:58.29

× Komiser
〇 Komisar

tmodもまだだね。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 077f-XPej) · 2018/01/01(月) 14:51:32.47

今回modは判別ルーチン入れる必要あるしテストも含めて時間掛かるんじゃ

**名無しさん＠編集中** (ﾜｯﾁｮｲ c611-Auke) · 2018/01/01(月) 21:35:23.29

10bit版のパッチがなかったら移植の手間がかかるのでは

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9fec-BEZ7) · 2018/01/05(金) 12:33:57.79

tmodのr2893が来てた。
パッチとの互換性を考えてffmpegは2.8.xのままとか、新しいブランチ作ったとかのWARNINGあり。https://github.com/jpsdr/x264/releases

kmodはまだ来てない。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2bb3-dJp/) · 2018/01/07(日) 00:59:09.06

help見るとr2867になってるね

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0fe8-Xk1J) · 2018/01/07(日) 04:48:21.14

>>706
ホントだ

**名無しさん＠編集中** (ﾜｯﾁｮｲ bbec-BEZ7) · 2018/01/07(日) 15:36:59.83

>>705-707
WARNINGに少し書かれてるけどjpsdr版tmodのr2893(実際にはr2867+74)について。

・バージョン表記→ x264 core:155 r2867+74 66b5600 t_mod_Custom_2

・tmod用の各種パッチの互換性確保を優先して公式コミットを省いたりしているので、
　公式のr2893とは大きく異なるものになっている。
　8/10bit統合もしておらず、別バイナリのまま。ffmpegも古いv2.8.13のまま。

・r2867までは公式masterと同じなのだが、その後はr2893までの26個のコミットのうち、
　8/10bit統合のr2868を始めとした13個の公式コミットが省かれている。
　(x264_Customブランチ。コミット数2880(2867+13)(2893-13))

・x264_Customブランチをベースに各種パッチを当てていった
　t_mod_Custom_2ブランチ(コミット数2941)を元にバイナリがリリースされている。
　r2867+公式13＋パッチ61ということで、r2867+74。

2018/01/07(日) 19:43:34.12

3行で頼む

**名無しさん＠編集中** (ﾜｯﾁｮｲ 0fe8-Xk1J) · 2018/01/07(日) 19:48:26.48

>>708
説明お疲れ様です

>>709
公式とは別物
コアな機能改善が省かれてるかどうかはわからない
.

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2bb3-dJp/) · 2018/01/08(月) 00:29:53.77

個人的に分割してくれたほうがいい気がする(1つに集約＝その分重くなる？)
x265.exeでも感じたけど･･･