◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:x264 rev43©2ch.net ->画像>47枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/avi/1485572817/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
Q ニコニコ用の動画を作りたい。 http://peace.2ch.net/test/read.cgi/avi/1351856057/ 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 (公式フォーラム跡地) [バイナリ] http://komisar.gin.by/ http://echo.2ch.net/test/read.cgi/avi/1454050806/ CLIで使用できる文字数って上限有りますか？
ググったらvista 以降は32000字と出てきた
・echo コマンドで、8192 文字目以降の引数が切り捨てられる。
・Cmd.ex e から、子プロセスを起動する際、渡される引数の一部に抜けが生じる。
https://support.microsoft.com/ja-jp/help/2823587 違法な無反応チューナーやB-CASの規約に違反するTS抜きに関するスレッドを皆で追い出しましょう。
【自治】DTV板自治スレ5©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1485486086/ 作業用に一時的にHi10PなイントラでCBRエンコしようしてるけど流石に早いな。
https://translate.google.com/translate?sl=en& ;tl=ja&js=y&prev=_t&hl=ja&ie=UTF-8&u=http%3A%2F%2Fkomisar.gin.by%2F&edit-text=
残っていたMMX部分SSE2にしたっぽいが速度上がるかな？
2762、若干速くはなっているけど、微々たる物だな
Ryzenどうなるかなー
x264の実行時間の半分はSIMD以外の計算と言う話だから、AVX2が128bitでも、コアが増えるのは有効だろう
現行FXより速くなるだろうから、それだけでもかなり良いと思う。エンコだけなら無難な速度だしてくれるからねｗ
ジャップランドからだと落とせないのかｗ
2762駄目じゃね？、少なくともx86版
なら何でmodビルドではないplainなビルドで試さないのさ
crf 0って量子化が可逆なだけで、refとかmeが違うと別物のファイルを吐くんだな
Iフレームでディザが消えててフレームを進めるとディザが復活してきて
>>42 ちょっとでも動きの激しいGOPの部分でよく見るわ
fgo=1にしてもほぼ改善しなくてバンディングが発生するから私も悩んでる
その部分だけをTrimしてエンコするとfgo=0でもディザはきれいに残るから何が悪いのかわからない
元からあるとかいう話じゃなくて？
pbratioかな？
名前の通りPとBだね
Crfエンコでのビットレートで2passのエンコをすると、そっちではディザが保持された
ごめん
階調割れを防ぐためのディザを残そうとしてる
psy-rdを1.35:0.4に変更して、fgo=1を追加してもあまり改善はみられなかった
それで
>>51 の設定で2passエンコをしたらディザが保持できていた
もう画質とかあまり考えずにx265へ移行したから的外れ（記憶違い）かもしれないけおｄ
me=umh, subme=9, merange=32, qcomp=0.8, deblock=-2:-2
そうか残念・・今、あと思いつくのはsubme=11のno-mbtree だけ
>>55 --no-mbtreeは効きそうですね
--pbratioが有効になるから、1付近に設定すればマシになりそう
--qpfile とか --cqmfile みたいに、 --zonesfile オプションがほしい
いろいろ試してみたけどやっぱりディザが残らない
そういえばpsy-rd使うとなんとかｑｐ-offsetがマイナスになった気がするからpsy-rdを0：0（効果を分かりやすくするため）でやってみたら？
マイナスになるのはchromaじゃなかったかな？
そもそも無理だからバンディング低減フィルタが生まれたのではないのか
なんで糞忙しそうなmuken氏に聞こうとするんですかね・・・
かつて野良ビルドしてた人だけどx264devじゃないでしょ
>>58 取り敢えず画像上げてみたら？ソースとcrfエンコ後、2passエンコ後の3種類
>>34 >PhenomⅡやCore2でエンコしている人は其れなりに大きいって感じか
FXまでのAMDプロセッサを使う場合は、r2345以降は思ったほど速度でないから。
r2345以降のx264でエンコさせると平均で6～8fps前後遅くなるし。
>>60 ソース見ないと、対策できるものかどうかなんとも
思いつくのは、まずは詳細ログを取って該当箇所のフレームタイプとqp値を調べる事かな
自分なら実験として、10bitやb無しをためしてみる
yを少しいじるだけで、かなりブロックが出てくるソースて結構あって
それをエンコすると俺には階調に見えたりする事もあった
(ffmpgのssim見るとx264のエンコはyが大きく落ちる傾向にある)
それも考慮に入れて見ては
>>r2345以降のx264でエンコさせると平均で6～8fps前後遅くなるし。
そもそもx264でエンコする人がいまだにWin7未満を使い続けてるとは到底考えられないんだが。
ライゼンってSSEが十倍の性能らしいからコア数とあいまってエンコはかどるかな？
理由は不明
自動インストーラってAviUtlに必要なん？
README見て必要なものを集めてくんじゃないの？ｗ
>>75 急増騒きは少し前だと思うよ
その時期にYoutubeに手順動画が流れてにわかユーザーが増えたからじゃないかな
理解しないで適当インストールを繰り返してアクセスが増えたのは確かかな
今も増えてるようだけど、安易に変なインストーラ作らないで欲しいと思うよ
Readmeを見て自分でファイルを集めてこれない人向けだから…
久々に来てみたがネ実のクズ共の荒らし行為って沈静化したん？
>>74 それで良いと思うよ
ツール使ってダウンロードしないでくれって書いてあるし
よっぽど行儀の悪いアクセスしていたか、数が半端じゃなかったんだろうよ
>73
よかったな 速いぞ
Encodage video : x264 et x265 - AMD Ryzen 7 1800X en test, le retour d'AMD ? - HardWare.fr
http://www.hardware.fr/articles/956-13/encodage-video-x264-x265.html AVX2オフにするとパフォーマンス上がる
コアあたりの性能はIntelとほぼ同等まで追いついて価格が驚異的に安い
まさかx264エンコードでも上行くとは
611 名前：名無しさん＠編集中[sage] 投稿日：2016/12/07(水) 21:57:43.12 ID:Ast4Hrma [3/3] http://rigaya34589.blog135.fc2.com/ https://github.com/jpsdr/x264/releases http://web.archive.org/web/*/http ://komisar.gin.by/ 1700で十分だな
2ソケットできるNaplesだと1800Xよりさらに上か・・・
Naples x 2だと合計128スレッドで、現時点でのx264の--threadsの限界に達するな
確かスレッド増えるとファイルサイズも僅かに大きくなるよね
--threads 12で--threads 1よりビットレートが1%ぐらい大きくなってた気がするけど
ccx内で完結するように2本流して速度稼ぐのが良いのでは？
実際にはx264はRyzenが非常に得意な分野だから
>>99 このスレじゃいかんの？
【x264+Avisynth】実用エンコベンチ Part5.1 [無断転載禁止]©2ch.net
http://potato.2ch.net/test/read.cgi/jisaku/1460032466/ アドバイスお願いします。
--qcompを盛ってみる 0.8とか
deblock -2:-2, psy-rd <unset>:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8
質問スレとかなくなっちゃったんだね
posix versionsって何？
x264で盛り過ぎると再生(デコード)時にやたら負荷のかかるパラメータってなんだっけ？
x264 core 148 r2744 b97ae06 High10 Lv5.1
refもbframesもスマホ向きじゃないぐらい大きいね
解像度によってはref16はかなりのハイレベルになるよ
8bitエンコにするなりrefを3~4にするなりbframesを減らしてみるなり手はあると思うんだ
エンコ環境やノートPCでは何の不都合もなく再生できていたから
少なくともbframesは盛ったところで縮みはするけど画質が上がるとは限らないと思う
素人で再生互換性とかよくわからないからほぼデフォルトプリセットしか使ってない
費用対効果的に
まあBフレ増やして節約した容量分、crf下げれば
veryslowベースの設定なのかもしれんが、「crf=15.5」ってのも結構やばいのでは・・・
他のコマンドにもよるだろうけど、crf16あたりからが人間の眼では劣化が分からなくなるんじゃなかったっけ？
どこが悪いというか、スマホで動かすには悪いところ多すぎてわらたｗ
スマフォならHWデコードだから大して差は無いと思うが、そもそも10bitデコードに対応してる機種なの？
ハードウェアデコードとはいえ、無制限ではないからな。
>>122-123 H.264の10bitのHWデコードに対応してるものなんて無いだろ。10bitはSWデコードのみ。
ちゃんとVBVを設定して
[email protected] までならどのハードでも安心
>>123 その制限がプロファイルとレベルだと思うんだが範囲内ならドロップしたことは無いかなぁ
>>124 俺も見たこと無いんだが、スマフォでSWデコードはキツくねって言いたかった
>>126 そうでもない
円盤はランダムシークに弱いからBフレも参照距離も3程度がベター
もっとも16とか指定しても使わなければ問題ないわけ（HWデコード全般で）だけど
万が一に備えると厳しめになる
--crf *を指定しなくてもエンコ出来たんですが--crf 23とサイズが同じでした
>>127 なんか、突っ込む気力が失せるくらい色々痛いな
RFFフラグを使ったソフトテレシネ素材をx264でエンコしたいのですが、
--pulldown 32のオプションがあった気もするがこれがソフトテレシネであるかは忘れた
>>135 それはソフトテレシネなのですが、フレームごとに指定することができない（する方法が分からない）ので、
60i混在ソースだと使えないんです
zoneはきっと使えないから--stitchableと--sps-idを使って分割エンコして最後に結合すればなんとかなるんじゃない？
なるほど・・・そこまでやるんだったらx264cliを改造したほうが簡単かもしれないですね。ソース読んでみます
x264はMBAFFインタレだからインタレ保持にしてもPAFFインタレよりは符号化効率高いよな
x264cli改造してRFFフラグをファイルから入力できるようにした
https://github.com/nekopanda/x264/commit/6d734de56d0bb7e1dc5c660634c9a2f4fb3bd02d これでエンコしたやつ、H264のrawストリームはmpc-hcで再生してちゃんと再生されてるようにみえるんだけど
mp4にmuxするとおかしくなる。
L-SMASHだとfpsを引数で指定してるのになぜか出力がVFRになっちゃって
再生するとフレームレートが半分くらいになっちゃう
MP4boxだとpulldownしてるところがちゃんと認識されないのかL-SMASHとは逆に1.2倍速くらいに速くなっちゃう
エンコはできてもmuxできないというオチorz
x264だとソフトテレシネはプログレッシブでのエンコードになるから、60iとの混在ソースだと
エンコ途中でプログレッシブとインターレースを切り替えるためにx264_encoder_reconfigを呼ぶ必要があって
なんか危なそうだし、やめておいたほうがいいかな
>>140 うーんどうだろうH.264やmp4(ISOBMFF)の規格に詳しくないから分からない
もう全体的に60iとしてエンコしてしまったほうがいいんじゃないかな x264はインタレェでもそれなりに圧縮率いいし
--stitchableと--sps-idを使って最後に結合する方法は規格上問題ないとは聞いた
muken氏とかH.264とISOBMFFの両方に精通してる人に聞かないと正しい実装に出来ないんじゃないかな
感激！そうかmuxでずれるのはタイムスタンプいれてやればいいのか。夜試してみるわ
すごく内容に興味あるんだけど、うまくいったらこの--pdfile-inの書き方を教えてくれないかな？
muken氏語ってるね
うぉぉーできたー！timelineeditorでタイムコード入れたらちゃんと再生できるようになった。
家電系は放送の変態ストリームに耐性があるけど、PC系は違うんだわな
すまん、カクカクだったのは俺のタイムコード生成プログラムのバグだったわ
直したらmpc-hc、Xperia Z4 Tabletともにカクカクはなくなった
これでXperia Z4 Tablet、PS3では全く問題無く再生できるようになった
ただ、mpc-hcだと、プログレッシブとインターレースの切り替わりで問題があるっぽい
インターレース縞が残ったり、フレームが一瞬戻ったりする
>>147 まさにそういう状況だわ
変態ストリームというかPC系がちゃんと実装してないだけなんだよな
mp4のファイル自体は問題なさそうだから、これでソフトテレシネと
60iインターレースの混在ソースをそのままエンコードできるようになった
>>144 今作ってるフロントエンドのプログラムそのうち公開するから待って
mpc-hcというかLAVはどうもインタレ、プログレ混在は苦手っぽい
ffmpegだとフラッグのみbobすればよかったような
参照しているフレームの情報を利用したいんだけど、どうすればいいかな？
あれから出力されたストリーム詳しく見たりしてたけど、
reconfigじゃインタレとプログレの切り替えはできないことが判明して
プルダウンのときはdelta_poc_bottomがゼロになるように改めて修正した
mpc-hcでフレームが一瞬戻ったりってのもなくなったし、
FFmpegでデコードしてRFFフラグをちゃんと取得できるのを確認したから、
規格上も問題ないストリームになったかな
>>144 pdfile-inはこんな感じ↓
https://github.com/nekopanda/Amatsukaze/blob/master/Amatsukaze/TranscodeManager.hpp#L1126 >>152 なんか本当に形になるとは思ってなかった
ありがたくウォッチさせてもらうは
Ryzen 1700環境を手に入れたんだが、どんなに設定を弄ってもCPU使用率100％いかないんだが
>>158 AviSynth+のMT版に以降して、Prefetch(16)を試してみたら
x264GUIはややスレチだけど、メニーコアなCPUだとCPUを完全に使い切れないことは多い
Ryzen7ならL3キャッシュが4コアずつに分かれてるから
>>158 aviutlスレにも書いたけど1本のエンコードで100%は無理
それでもAviutlと合わせて80%越えてたら十分でしょ
x264に限らずフィルターもマルチコアに最適化されないとどうにもならないんだから
まじか。今のx264だとまだ性能出しきれるほど最適化されてないのか。
最適化はもう限界に近いでしょ
x264だけなら100%近く出せると思うけど実際にそれだけという人はいないから
5960X環境だけどUt_videoのavi食わせてるだけなのに100％なんていかないよ
ベンチスレ見てても多コアなやつは100%までいってなかったような
CPUが100%に張り付けばいいってもんじゃないと開発者が言ってたと思うよ。
マルチプロセスでスレッド数を減らすことを意識したほうがいい
>>168 それぐらいが丁度いいんじゃないの？
80~90%ぐらいが
いままで8bitエンコしかして来なかったけどhighDepthオプションつけて10bitエンコにしようかと思うんだが
なんで10bitエンコがいいのかぐぐればすぐわかること
>>174 tsそのままだとあまり意味無いね
なんらかの技術で10bit精度に補間したものを改めて10bitで収録し直すみたいな形ならともかく
>>175-177 あっ、なんか意図が伝わってなくてスマソ。アスペなもんで。
8bit深度に大してH.265で採用されている10bit深度の画質的メリットはもちろん理解
しているんですが、ソースが8bit深度の映像を10bitで出力したところで画質向上には
ならないんじゃないかなと思いまして。
いろいろ調べてもTSソースを10bit補間してエンコしたみたいな話は見かけないから
そもそも10bitエンコ自体普及してないのかなぁ・・・
最近閉鎖で騒がれているnyaaとかには10bit精度でエンコされた動画でわざわざ
アップしている職人もいたと聞くが。
hevcかどっちか忘れたけど素のまま10bitエンコするだけでも
onedriveにアドレス残ってた
http://peace.2ch.net/test/read.cgi/avi/1418252184/ ここの70番あたりを読むと8bitソースを10bitなモードでエンコードしても効果あるということらしい
>>179 それ言う人がいるけど勘違いしてると思うよ
D-A変換されたものがそのまままた10bitにA-D変換されて記録されるだけの事だから
同じD-A変換のアルゴリズムを使ってる限り8bitエンコードも10bitエンコードも変わらないよ
jpegをjpegで圧縮するような状態だったのを
主にアニメとかでバンディングを軽減するため10bitでエンコするんだよ
色深度の話は圧縮とは別で
たとえ可逆圧縮だったとして8bitを10bitで記録しても8bitの深度にしかならないよ
>>180 で展開されてるのはデコード時のディザの話で
これはつまりデコード時にディザを付加してるのだからデコーダーの補間の話になる
このデコーダーで8bit映像をデコードするのとそれを10bitで縁jコードした映像は変わらない
つまりこのデコーダーを使う限り8bitのソースで充分という事になる
>>184 8bitの元ソースを8bitでエンコードしてバンディングが出るのはビットレートが低すぎるからだろう
近似値の平滑化の度が過ぎて目で見て分かるほど差が出てしまったという事だ
10bitでエンコードするよりその分8bitでビットレートを高くした方が良いと思うがな
flash3kyuuDeband()
>>188 ()がつくということは失笑するレベルなのか。
>>189 マジで言ってるのかAviSynth知らないのか判断に迷う
>>184 lavつかって再生すると、結局あんまりでないんだよなぁ
>>186 8bitでバンディングを出なくするにはディザを残す必要があるからBD並みのビットレートが必要
少なくともフルHDで10Mbps以上。x264だとcrf=12程度が限界
だからTSを圧縮するには実質的に使えない
ｒ2829
そうだったら面白そうだったのに違うのか。発売まであと1ヶ月ちょっと
なんかAVX512にもいろいろなバージョンがあるらしい
AVX-512に対応しても、256bitを2クロックで実行だったらあまり意味がなさそう
>>205 今のところ2種類だよね
Phiと、これから出るSkylake(Kabylake)-X
違ったら訂正よろ
>>174 テレビは8bit
ブルーレイは10bit
これが基本
>>211 マジかw よく見たら俺の持ってるUB90も対応してたわwww
これをデコードできるソフトがあるのか知らんけど
そういう意味じゃなくて、MGVCのtsをx264でエンコするために12bitデコードできるPC用のプログラムが手に入るのかって話
＞MGVCのサブストリームデータには特別な暗号化が施されており、これをデコードするためには、ハードウェア側にカギを仕込む必要がある。
まぁパナの一部の機種しかデコードできないようなオレオレコーデックに対応しても旨味がなさすぎるし無理だろう
ここで聞くのがいいのか分からんけど、x264の8bitで俺的アニメ最適設定とか実写最適設定的なのを参考までに教えてくれる人いないですか...
>>220 とりあえずプリセットとプロファイルを指定して
そこれプラス --b 3 --ref3 でBフレームとrefの制限だけしとけばおｋ
あとおまじないで --aud --nal-hrd も追加しとけばいい
画質的に向上する余地なんてないんだから
AVX-512関係ばっかりだし
x265に乗り換えてからx264の最新ビルドに対する興味が薄くなった。
赤潰れやハイライト削りすぎは改善れれる余地はあるの？
赤色が劣化してるように見えるのは色空間の問題が大きいからなぁ・・・
>>234 赤色の劣化の原因は色空間なの？元画はなんともないのに？
赤の認識は国や地域で大きく違うから、それが反映されて無視されてるのかと思ってた
ハイライト削ると、バンディングもどきが現れたり
--chroma-qp-offsetは効果がなかったですね
サンプルの画像でも貼ってくれないと何のこと言ってるのか分からない
有名な話ではあるけど8bit ビデオコーデックの限界でなかろうか
>>238 ・元画と言ってるのは、どういうソフト（やカメラなど）でどのように作った映像なのか。RGBなのかYUVなのか。
>>237 が言ってるように元画がYUV4:2:0の映像なら元画の時点で赤の劣化が起きてると思うのだが。
・「ハイライトを削る」とは具体的にどのような処理を行っているのか。
このあたり、ちゃんと詳しく書いた方がいいと思うよ。
あとフルレンジかどうかは今回の件についてはあまり関係ない。
> ハイライト削ると、バンディングもどきが現れたり
バンディングのディザによる解決は害悪だよね
つくづく、地デジもBDも10bith264と思いきればよかったのにと思う。
BSで新しい衛星を立ち上げて地上波のサイマルをH264使ってやればいいのにな
>>245 もし出来たとしても結局版権問題でBSジャパン（テレ東と同時にBSで放送する予定だった）と同じルート辿りそう
BSで4KをHEVCでやるんだから今更必要ないだろ
16 : 宇野壽倫の告発2017/07/11(火) 19:22:00.17 ID:5/TEkUSo
皆さん十分にご注意ください
http://ameblo.jp/jcjk-now/entry-12148228389.html 17 : 宇野壽倫の告発2017/07/11(火) 19:22:46.64 ID:5/TEkUSo
死ね！キモブサ川高志!!
ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを
投下してみましたので、検証協力して下さる方がおられましたら、よろしくお願いいたします。
http://egg.2ch.net/test/read.cgi/jisaku/1460032466/796-797 エンコの時にハイライトを捨ててるんだろう
>>251 「だろう」って、「ハイライト削りすぎ」という表現を持ち出したのはお前さんなのに、なぜ他人事・・・。
個人的にはカラーグレーディングで高輝度部分をちょっと下げたみたいなことを連想してたけど
「エンコの時にハイライトを捨ててる」ってのが何を指してるのかさっぱりわからん。
自分の世界しか見えてないから他人に説明できないんだよ。きっと
ハイライトは最も明るく目立つ部分だから白付近をごっそりクリップしたんじゃないの
> 白付近をごっそりクリップ
自演じゃあるまいし
目玉のおやじの白い部分をごっそりクリップするとグロ映像になるよな
>>257 もともとグロ説
目立つところをおかしくするのって、psy-rdを負側にかけるとかそういうトリッキーなオプションじゃないと出来ないのではなかろうか
mp4boxで複数音声をmuxする場合、lang=jpnで指定してるんだけど、
違う言語で割り当てちゃえばいいよ
もの凄いボケボケのブロックノイズ塗れになった
crfmaxパラメータあたりで上限変えれんじゃね。ゴミ画質に劣化するだけだから誰も触れないけどw
>>265 -crf_maxも--crf-maxもCRF+VBVの時にRF値を制限するためのオプションであって
--crfで指定できるRF値の上限を変えるもんじゃないだろとマジレス。
>>264 が言ってるように、--crfは51以上を指定しても51にされるだけだね。
rc-lookaheadを300にしてるとか言ってる奴も昔どっかで見たけど250に丸め込まれるよね
クリッピングの意味で丸め込むってウチでも使うけど、そんなに変か？
草はやされるほどおかしいとは思わないが
>>277 試してログ見れば本当だってすぐにわかるだろ。疑うくらいならさくっと試しなよ・・・。
>>277 rc-lookaheadはkeyintと同じ数値までか、250までだったと思うよ。
keyintが300だったとして、rc-lookaheadも300にしても250まで丸め込まれちゃうはず。
keyintが120なのにrc-lookaheadを250とかにしても「keyintまで」のはずだから、この場合もrc-lookaheadは120に丸め込まれちゃうはず。
間違えてたらごめンゴ
さくっと試したら
>>267 、
>>279 の言う通りだった
どうもです
x264 sandboxによるとx264が大きく変わるようだ
そういう動画はプレイヤーによっては再生できなくなるんじゃね。
スマホやゲーム機は10bit/12bitの動画とかHWデコーダが対応してないからSW再生しかできないんだよな
H.265 Main 10に対応したハードウェアデコーダーは増えてきているけど、H.264 High 10に対応する物は一向に増えないな
>>285 増えるも何もH.264の10bitのHWデコードに対応してる物なんて無いんじゃ？DXVAの規定も無い。
ピンク色をエンコードすると
低くても、か
RGB -> YUVへの減食ミスとかじゃね
固定品質のQP0(可逆)でもそれがでるのかどうかを確認しよう
http://www.rupan.net/uploader/download/1501125272.zip パスワード abcd
こんな感じ
尼子の文字の隣にある家紋色が違ってしまい
動くとチラチラして見える
ピンクかと思ったら拡大したら群青とオレンジだった
>>290 やな
AviUtl使ってるならUVダウンサンプリングフィルタを使うとマシになるかもしれない
ログを見るとYUY2 -> nv12pになってる
UVダウンサンプリングフィルタをやってみたところ、
Aviutlって普通にエンコしても黄色っぽくなるんじゃないの
>>295 aqもpsyも0.2ぐらいまで下げてもいいはず
読んでると色変換設定ミスの可能性高いな
>>295 >>299 なんとなく解説画像作ってみた。
FrapsのFPS1コーデックは変に古いものを使ってでもいない限りRGB形式らしい。
AviUtlはRGB→(YC48)→YUY2変換時に左側の色差だけ取るので
RGBソースの場合はUVダウンサンプリングとかで平均色差をとった方がいいよという話。
RGBソースをAviUtlでエンコする場合はUVダウンサンプリングで平均色差とった方がいいよというお話
あと、
>>292 のencoded.bmpが変に明るくなってるのが気になった。
多分再生ソフトか何かで色補正が効いてる状態で撮ったもんだと思うけど、
サンプルとして出すには不適切なので、AviUtlに読み込んで撮ったものとかを出した方がいいと思う。
>>296 >Aviutlって普通にエンコしても黄色っぽくなるんじゃないの
それは無い。どこかしらで何か変なことをしてるだけと思われ。
自分は分ってる風だけのスレなんて無駄じゃないか
何もフィルターかけてないのに色が変わるんだったら可逆圧縮なんて成り立たないでしょうに
ゲームのエンコの時は「拡張色調補正」の「TV -> PC スケール補正」をONにする必要があったと記憶している
PCスケール補正ONとかそんな地雷情報誰が流布しているんだろうな
RGB->YUVをストレート変換しているのと同義でたぶん
>>292 のencoded.bmpみたいに明るさや色が変わる
色変わろうがそれでいいってんなら俺がとやかく言うことじゃないけど
てかスレチすぎる
そもそもORIG.bmpが正しいやり方でキャプったのかっていう問題がある
>>300 黄色かどうか忘れたけど変わるよ
元ソースと比べないと分からないレベルだけど
>>304 Y/C伸長がいるのはリミテッドな色空間で出力したゲーム動画をRGBで録画したときだけで
PCゲームの内部キャプチャ、フルレンジ出力したものをRBGで録画したときは不要
うーん、h264はYUV420でエンコードするのが殆どだから
>>292 みたいな元画との差異の追求の話をするには
RGBに比べてYUVは色情報での解像度が低くなるとかの知識は共通認識で持っていた方が良いと思うので
テンプレに追加した方が良いのでは無いか
>>308 > 黄色かどうか忘れたけど変わるよ
変わらんでしょ。そんな問題があるなら重要情報として広く知られてるはずだし、
・そもそもソースの確認の仕方がおかしい
・入力プラグインの設定がおかしい
・入出力色空間の設定がおかしい
・colormatrixとかの設定がおかしい
・再生環境がおかしい
といったミスをしてるか、過去にあった何かしらのバグの話と混同してるか、
>>300 で書いたような色変換時に必然的に起こる変化のことを勘違いしてるといったところでは。
>>309 さすがにテンプレにはいらないと思う。昔は色空間スレってのがあってそのログも色々参考にさせてもらったけど、
過疎スレだったし今更立てても需要は無いだろうし。
>>310 ミスじゃないでしょ だからただん劣化の比喩表現
自動という素人でもできるエンコでどうやって間違えるんだ
同じモニター同じデコードで比べても色は劣化してるだし
劣化という表現を色がおかしいという言葉で言うのが問題なら訂正する
でもわかりそうなもんだけどな
>>311 何を言いたいのかよくわからない。「自動という素人でもできるエンコ」というのが
「特に何も考えずにAviUtlに放り込んでエンコ」ってことなら、それこそが問題であって、
「使い方がよくわかってなくて設定が間違ってるかもしれない」という初心者（素人）が
間違えることがある要素が
>>310 に書いた内容。
劣化の比喩表現と言ってるのもよくわからない。x264のエンコードによって劣化が起きてボケたり
微妙な色変化が起きたりすることはあるだろうけど、それはAviUtlに問題があるからではない。
「同じモニター・同じデコードで比べても～」と言ってるけど、colormatrixを間違えてれば
そこで変わるし、レンダラのバグやDXVA、GPUとの相性等で色が変わってしまうこともある。
そういった要素を極力排除して正しい条件で比較する必要がある。
AvsPmodやAviUtlで適切な入力プラグインで適切な設定で読み込んで比較するといった形が望ましい。
ということで、結論としては一連の設定や確認の中のどこかでミスしてるだけだと思うよ。
AviUtlに問題があるわけじゃない。
こういう切りない無駄な言い争いになるから辞めろって言ったんだ
何にせよもう終わった話だしAviUtlはスレチだからこれで終わり
そだね。何かあればAviUtlスレの方でテンプレの情報出して質問してくれればなるべく対応しま。
>>316 お前の脳味噌が劣化、というか頭がおかしい
将来的にTMPGEncあたりがUltra-HD Blu-rayオーサリングに対応しそうだから規格準拠した10bitx265でつくっておきたい
しばらく実写ソースに対してaq-mode3の0..4でやってみたけど
BDRIPの動画を8bitでエンコするやつの気が知れない。
BDなんかわざわざRIPしてエンコする馬鹿の気が知れない。
ソースが8bitだから再エンコはバンディング低減効果しかない、というかそれが目的でしょ
いちいちBDをケースから引っ張り出すの嫌だから
x264で解像度の違う２つの動画をエンコしてa.264とb.264を得たとする
問題なかったって言うのはウソだった
>>333 無茶苦茶なことやるなあ
muken氏が血を吹いて死ぬぞ
ps3の限界を探ってみた結果、2つのストリームのlevelが同じなら
画面サイズやエンコ設定（mediumとslowerとか）が違くても再生できることが分かった
1440x1080と1280x720はlevel自動にしてたから結果違うlevelになって再生できなかったけど
4.1に統一したら再生できるようになったわ
L-SMASHだとサンプルエントリのwidth,heightがデタラメな値になるけど問題ないっぽい
>>334 発端は分割エンコで--stitchable付けなかったらどうなるんだろうっていうのを確かめたかったんだよね
同じ画面サイズ・エンコ設定でも分割ごとにPPSが変わるが、
L-SMASHは複数のサンプルエントリを置くのに対応してるから
規格上は問題ないMP4が生成されるはずで、
ちゃんと実装されてるプレーヤーなら問題ないっていうのが俺の中での結論
まぁ、win10デフォのプレーヤーだとサンプルエントリが2つ以上あるmp4はどれも再生できなかったが・・・
で、それができるんなら、画面サイズやエンコ設定が違くても、できるんじゃねって思ってやってみた
>>336 他に何かある？
ちなみにmkvは試したけど↓こうなった
>mkvmerge.exe --append-to 1:0:0:0 -o out.mkv a.264 + b.264
mkvmerge v15.0.0 ('Duel with the Devil') 64-bit
'a.264': Using the demultiplexer for the format 'AVC/h.264'.
'b.264': Using the demultiplexer for the format 'AVC/h.264'.
'a.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
'b.264' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
Error: The track number 0 from the file 'b.264' cannot be appended to the track number 0 from the file 'a.264'. The width of the two tracks is different: 1440 and 1280
残念！
CPU能力有り余っててsubme=11を常用してたけど、10に変更したら主観的に画質レートエンコ速度が良くなった
俺も意味不明
限界まで圧縮高めればノイズも出易い
submeを「限界まで圧縮高める」ものだと思ってるのか
>>344 サブピクセルに対して動き予測を行う精度が高い→圧縮率を高める可能性がある→高圧縮
無能で理解できてない癖に揚げ足取ってる俺カッケーってかwww
どうやらsubme上げると圧縮高まってノイズが出やすいらしい
けど実際にガッツリ削れてブロックノイズが出たた気がする
submeなんて「ソースによる」としか・・・。
自分の目にはsubmeは9が一番画質いいように見える
>>349 動き予測妥協してるんだから速度は早くなるだろ
昨日久々にaviutl一から環境作り直したけど
keyintのデフォ値はなんであんなキチガイみたいな値なんだろうな
ゴミCPU使ってなきゃGOP300でも気にならんがなぁ
>>356 palだかの25fpsの10秒分で250って話らしいね
デフォルトとしては確かに自分も微妙な値だと思うｗ
シークの重さなんて、設定とか環境とか使ってる再生ソフト次第でもあるし、それらを明示しないとなあ。
keyintはBDだと1秒分のフレーム数だし、私もそれに合わせている
そうだね。以前はOpenGOPがMP4で定義されていなかったりしたけど、今は特にデメリットを思いつかない
動画配信とかの用途ではopengopを使うと不具合が起きるみたいだね
BDだと最大キーフレームは最大2秒でしょ
keyintは最大GOPサイズの指定であって、それ以下でも必要と判断したら勝手にIフレームにするから
ほとんど動かないシーンが長時間続いた場合にどこまでシークしやすくするかを制御するものだろう
>>367 確かに全てがfps非依存であるべきというのは言い過ぎだった(refとかbframesとか)
けどkeyint/min-keyintの用途からいってfps依存にする必要ある？って思うわけよ
単に最大間隔を広げるだけだと思ってる奴が多いが
というかその必要な部分の判別はどうやってやるの？
> それとも思い込み？
x264 [info]: frame I:31 Avg QP:31.14 size: 50769
>>372 どっちがどっちなのよ
あとx264にわたってるfpsは同じなの？
x264は入力fpsでcrfの品質基準が変わるから注意
x264ってタイムコード入力できるからfpsって必要ないんじゃないの？
>>373 フレーム数を見ていただければ分かるように、上がフレームを削ったもの、下がループしたものです
>>375 どこまでインテリジェントに対応してくれるんだろう・・
入力されたファイルのfpsが30fpsだった場合、不明・24fpsの場合と比べて
crfの数字に0.2～0.3ほど内部で増やされるんだけど、その適応もしてくるれるんだろうか
>>370 IDRフレームが挿入されるタイミングは、
100 * (1 - (Pフレームのビットサイズ) / (Iフレームのビットサイズ) ) < scenecut * (直前のIDRフレームとの間隔) / keyint
の式で求まるらしい。
IDRフレームってのはH.264/AVCから追加されたフレームで、特定のフラグを持ったIフレームとしても機能するフレームの様だ。
IDRフレームとIフレームしっかり区別して解説しているWEBページは少ないようだ。
ちなみにH.264のGOPの境目はIDRフレームになっている。なのでこれがキーフレームなどと呼ばれる。
さっきの式を計算してもらえば分かると思うが、keyintを大きくすると「直前のIDRフレームとの間隔」が近づきにくくなるので、IDRフレームが挿入されにくくなる。
それを
>>369 は説明していたのだと思う。
そのIDRフレームってのは、H.264はIフレームでも前後フレームと関連つけてあるから、関連性をリセットするIフレームってことでしょ？
OpenGOPだとIDRフレームは生成されないよ
IDRフレームでしかシークできないわけではないし、OpenGOPは「GOPが無い」わけではないからね。
BDMV互換重視してるから
>>383 使ってるよ
別にこのスレに書いてるからと言ってx265を使っていないことにはならない
youtubeのことかと思ったらyou達（たち）だったのね
何年も前から使えるなら移行する気満々で環境だけは整えてるけど
できるならH265にしてるだろうけど、エンコードも再生もそこそこ性能が必要だから現状厳しい
一番の問題はx265の完成度が低すぎる所
H.265が「H.264の2倍の圧縮率」てのを発表したのはSSIMではなくてPSNRでの評価。
んで、そういう機械評価ではなくて、実際の主観的な評価（眼で見た時）はどうなのかと、圧縮率をH.264の倍にしてテストも、92.5%はテストクリア（半分にしても違いが分からない）という結果が出ている。
http://www.bbc.co.uk/rd/blog/2016-01-h-dot-265-slash-hevc-vs-h-dot-264-slash-avc-50-percent-bit-rate-savings-verified >>390 8bitでエンコしてあればx265のエンコ動画はスマホでも余裕で再生できるけど？
馬鹿でも出来るという言葉があるが馬鹿の程度にもよるしな
x264vfwの最新版が7月で64bit版は15年で止まってるんですが
>>396 統合されたので、最新版を入れれば32bitと64bitの両方が入るよ。
あ、そうなんだ㌧クス 翻訳サイトで読んだけどちょっとよく分かりませんでした
>>392 規格作った所の公式テストの話じゃなくて、x264に比べてx265の最適化が発展途上って話なんだが
>>392 どうせ比較したH.264エンコーダーが糞なんだろうな
x264はmp3でいうLAMEみたいに規格内で極限まで最適化を志向するエンコーダー
規格とエンコーダの違いがわかってなくて規格(机上の空論)だけで比較した気になってる人でしょう
1passVBRのcrf指定でエンコする場合、presetはどれに設定しても
>>403 画質という表現だとちょっとあれだが、前にSSIMを調べた時には
fasterより早いプリセットは他に比べて明らかに値が低くなってしまっていた気がする。
>>403 機能的にはそのはずだけど画質はfasterとslowではそれなりに差が出る
使える機能を絞ってるわけだから当然なのかなと思ってる
ありがとう。MicroSDも随分大容量になった昨今、エコ的には容量に
ハズレ石の6700Kで夏場は水冷でも熱暴走しまくって、OCを4400MHzに抑えてたが、
電源をずしんと重いやつに変えれば夏でも安定すんじゃね？
>>408 オンボ環境で1000Wの電源積んでる(将来のグラボ追加のための皮算用)んですがね
ライゼンはええわ
[email protected] で地デジソースがveryslow＆お気に入りフィルタの重めの設定でリアルタイムfps出てるわ
[email protected] だと実時間の倍掛かるのに
流石にその比較で2倍違うのはおかしい
こんな人間いるのかな？って突如疑問に思ったんで質問してみる
BDのH.264ってとりあえず最高ビットレートで入れとけって感じだから、再エンコでも結構縮む
>>424 ああ そういう感覚なのか
容量あるから考えなしにビットレート高くしとけっていう事ね
ありがとすっきりした
720p付近で作ってるアニメなら容赦なく720pにしちゃう
>>423 BD-BOXをエンコしてBD-R SL1枚にまとめれたら最高じゃね？
あとは特典だけ手元に残してBD-BOXをオクに流せばいいだけ。
一度HDDにエンコして入れとけば見たい時にサクッと見られるからな
BDを再エンコするのはノートPCでいつでも気軽に見られる様に入れておきたいって用途しか無いなあ
何でエンコするかは各自の自由な。
x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。
俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ
地デジソースとかエンコ職人がアップしたやつを見たこと有るけど
テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな
いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。
補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ
>>438 テロップに惨敗して負け惜しみ言ってるようにしか見えない
何度も見る事やないんやけんある程度見れてたらそれでええわ
横にテロが動くときに妙にぎこちなかったり、カックンカックンしたりするとアニメ本編に集中できずにイラつくだろ？
どこの局のソースかが大事だからな
>>444 そこがそれほどイラつくなら素直にBDを買うか借りるかした方が幸せになれそうだ
x265でアニメエンコしてたけど
定期的に現れるけど、単に8bitでエンコしてるだけでは？
仮にそうだとしても、ソースも8ビットなわけで、
「その条件」ならそうかもしれんが、
>>447 はその条件にこだわってないだろ
バンディング対策をしたくない理由とは？
暗部といったら aq-mode 3 だろ
>>451 で、その
>>447 の対策（バンディングと暗部のディテールは違うと思うが）がx265ではなくx264を使うということだったのでは？
バンディングでいうと、ソースが8ビットならばいくらエンコの設定工夫しても無駄
逆にいえば少なくともx264ならエンコの設定ちゃんとすればスクリーンキャプチャしてソースと差分取ってもほぼ0にはできる
ソースが10ビットなら知らんが、
暗部保護ならaq-mode 3とno-mbtree両方設定しとくべき？
入力が 8bit でも Avisynth やらでフィルター噛ませば出力 10bit でも多少効果でるもんじゃないん?
aviutlでノイズフィルタ使ってるなら色深度変わってくるから10bitがいいんでないの？
デバンドは意味あると思うが10bit化は無駄多すぎ
ソースを加工するならたしかにまあ
8ビット高ビットレートでバンディング低減されてるソース（放送もブルーレイもそう）を
まぁ、あまりいいディスプレイじゃなければ分からないかもしれないけど、
ブルレイ互換でエンコが基本の自分としては10bitはそもそも選択肢に入らないけどなぁ
447だが
8bitソース素通しでも10bitでエンコードする理由はあるよ
バンディングだけは目に見えて効果あるよな10bit化
>>465 ソースくれ、その部分だけでいいから
できれば静止画でなく動画で
>>466 x265は知らんが、x264なら素通しなら8ビットでソースと寸分違わないレベルの画は出るんだよ
劣化するにしても動きやディテール部分が溶けるだけで、バンディングなんでひどくもならない
そうならないとしたら設定がおかしいか（画質が目に見えて劣化する低レートは知らん）、素通しのつもりがそうなってないパターン
>>469 君が劣化しているところに気づいてないだけだと思うよ
BDでさえバンディングは問題になっているのに、その5分の1以下のビットレートで
問題にならないってありえないだろ
1/5程度のレートなら余裕余裕
アニメのBDはマーケティングの都合で1枚に2話とかしか入ってなくてレート減らすインセンティブ皆無だからな
crfが適切で、aq-mode 3 使って、デバンドかけてれば
ソース
フィルタなし 8bit --crf 20 --aq-mode 3 --tff
デバンドあり 8bit --crf 20 --aq-mode 3 --tff
デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff
デバンドありの圧縮前
全部AviUtlでrigaya氏の拡張x264で出力
デバンドはrigaya氏のバンディング低減MT SIMD (25/15/15/15/0/0/1/0/off/off)
これで8bitがきれいに見えるならいいんじゃないか。そういう環境ならね・・・
おれ環では aq-strength を調整すれば 8bit + デバンド でいいや・・・
デバンドするしないでも選択肢変わるだろうし
なんでアニオタばかりなの？
デノイズはNL-Means使ってる
実写メインの人ってHDD録画かBD-Rにムーブして終わりじゃね
>>474 ＞ソース
＞
と、
＞フィルタなし 8bit --crf 20 --aq-mode 3 --tff
＞
はほぼ寸分違わないよな。
ということを言ってるんだよ。
ソースを加工して情報を補完する場合はその限りではないと
>>460 で言ったとおり
あくまでもソースを忠実に再現するためのエンコードという観点でしか話してなかった
デバンド等でぱっと見は綺麗になったように見えるんだけど、
一方で細部の意図したざわざわなディテールも消失するし（地デジなんかのソースにはそもそもそんな情報ほぼ残ってないだろうが）、
いいことばかりの魔法のフィルターは無いのだ。その辺は好みだね。
あくまでもソース寸分違わないかどうかという観点では10bitエンコードは無駄という話。
んでもって、x264は
＞8bit --crf 20 --aq-mode 3 --tff
みたいなほぼプリセットそのままな設定でソースほぼそのままの忠実なエンコードができるんだが、
>>466 のような話は散々出てくるし、
x265は依然としてそのレベルに達してないのだろうか
10bitで書き出すならデバンド要らなくない？
>>481 x265はビットレートをつぎ込んでの高画質はまだx264に負ける
っていうかx265は4k向けの高圧縮コーデックだから2kで負けるのは仕方ない
まだx265が開発途上なだけでしょ
>>482 そういうことでもない
デバンド（も含めソースの加工）をしないならソースと同じビット数でエンコードすればいいだけ
8bitのソースを8bitビットでエンコードして当たり前だがソースからほぼ劣化が無くできるのだから、
それを10bitでエンコードしてもデータを無駄に水増しして互換性を下げているだけ
たしかにフィルターをかけたら元の8bitでは表せない中間の値が出てきてしまうので、
それを10bitで表現するというのはありだし、実際効果はある（
>>474 ）
もちろん再び8bitに落としてもある程度フィルター効果は残ってはいるが完ぺきではない（
>>474 ）
>>483 H264の普及初期段階もH264は低ビットレートでそれなりに見られるようにするコーデックで、
高解像度高ビットレートではMPEG2のほうがきれいだとか言われていたが、
それは単に当時のコーデックの実装が未熟だっただけで、今どきそんな戯言を言うやつはいないのでそれと同じことだろう
>>485 その水増しってのが認識を間違ってる証拠だと思う
なにも水増しはしてないんだから
>>486 なるのかな
h.264がHD画質でmpeg2より高画質になったのは必然だけど・・
>>487 8bit to 8bitでまさにソースそのままにエンコードできるのだから、
そういう場合に10bitでエンコードすることがどう
＞なにも水増しはしてない
なのか詳しく
何度も言うがソースに何らかの加工を施す場合はこの限りではない
crf 20 出来上がりのファイルサイズめっちゃデカくなりそうだけど
アニメならそうでもない
ソースを忠実に再現って言うと聞こえはいいかもしれないけど、
MPEG2圧縮でできたノイズやアーティファクトまで再現しようとしなくていい
しかも実際は再現できてなくて、バンディングは悪化してる（
>>474 ）
（圧縮で情報量が落ちる分仕方ないのだけれど）
デノイズしてから圧縮したほうが綺麗なることも多いし、
テレビは「高画質化エンジン」で加工しまくって表示してる
そもそも圧縮で情報量落ちる分、ある意味「加工」されちゃう
8bitきったねぇわろたｗｗｗｗｗｗｗ
>>480 この違いがわからないなんてよっぽどひどいモニタ使ってるんだね
>>495 「寸分違わず」という表現はどうかと思うけど、別に違いがわかってないわけじゃなく
趣旨としては「汚いソースをほぼそのまま再現」と言ってるだけだろうから妥当なとこじゃね。
>>494 デバンドフィルタに何の副作用もないと思い込んでるお前がめくらなだけ
緻密なざわざわしたディテールが消えるから一長一短で単なる好みの問題だって言ってるだろう
特に放送波のMPEG2だとそんなものは残ってないか、残ってても汚いだけだから消しちゃうってのは一つの考え方
というか元から保存用はもちろんTSだわ
スレ違いになるのでそれについては深入りはしないが
MPEG2の60iじゃ取り回しが面倒だから視聴用、持ち出し用にエンコードしたりはする
>>493 意味が分からない
じゃあ128bitにでも増やしてデータ容量が何十倍になっても水増しとは言わないというならば、
もう水増しという言葉の認識が違うだけでもうこれ以上平行線だと思う
話がややこしくなってきたので改めて整理すると
>>466 に対する反論として、
8bitソース素通しなら10bitでエンコードする必要はない、少なくともx264ならば
ということを俺言ってるだけ
8bitソースは汚いのでデバンドかけますとかいうことについては好みの問題で、そういう場合は最初から含めていない
んでもってその観点でいうならば、
>>474 にはデバンド無し10bitの結果が無いのでその比較にはなっていない
ま、8bitの時点でソースを十分再現できているわけで、10bitにしたところでこれ以上どうなると思えないが
>>494 のようなめくらには副作用があるって言っても
具体的な例を示してやらないとわからないだろうから言っておくと、
たとえばデバンドかけたほうは（圧縮前の時点で）右上の絵画（？）の色の境界ソフトになってるよな
BDのように高画質なソースだったらこの程度の微細なディテールはざらにあるよ
そういう部分に目が行かず、
＞8bitきったねぇわろたｗｗｗｗｗｗｗ
＞こんなんどう見てもデバンド+10bitだろｗｗｗｗｗｗｗｗ
みたいに草生やしてるだけだからお前はめくらなんだよ
地デジはともかくブルーレイだと
>>474 のデバンドあり圧縮前のような
色の階調部分のディザを保っているからな～
少し試してみようか
これが
>>474 デバンドあり圧縮前をcrf0で8bit化したavc（の静止画）
------------------------
これがそのavcをcrf20 8bitエンコしたもの
QP:19.37 size: 31899byte
------------------------
こっちはcrf20 10bitエンコ
QP:31.10 size: 29806byte
QPがとても上がってるせいかサイズは10bitの方が少ない
画質の評価は見た人に任せるよｗ
>>500 そう、これ使えねーなと思ってさ、直したんだよ
バンディング低減MTは、Y,Cb,Crを色別に差を見てるんだけど、
そこ変更して、「全部の色がしきい値未満だったら」にした
対象と判定されたピクセルを表示してみた結果↓
判定表示（改造前）
判定表示（改造後）
デバンドありの圧縮前（改造後）
オレオレバンディング低減
どうよこれ
素通しで8bitソースを10bitにエンコするときにバンディング減ったように見えるのはdeblockが効いてるからだと予想
別に絵画の精細度なんてどうでも良いんだがｗｗｗ
＿人人人人人人人人人＿
>>498 1,000円札を100円玉 x10に換金することをお金の水増しというのなら
「水増し」という言葉使いで正しいと思う
>>499 そうね
自分のエンコードの目的は「出力サイズを小さくする」ことだから
10bitでアラが目立たなくなるなら、そのぶんcrfを大きくしてサイズを小さくできる10bitってスゴイ優秀って先入観で書いちゃった
8bitソースを10bitでエンコードする必要性ではなく、10bittエンコーダーのほうが優れてるってだけの主張ね＞大元は
>>502 を見るとどう考えても10bit＞8bitじゃんｗ
ファイルサイズ8bitの方が小さいならまだ分かるけど
大きくてこれとかイイとこなしｗ
静止画だから分かりづらいけど
うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで
>>513 ＞8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出る
っていう分かりやすいサンプル（できれば追試できるようにソースも公開されてるとなおよいが難しいだろう）があればな
単に何らかのミスで素通しになってないか、エンコード設定がおかしいだけじゃないのって気がする
素通しでそんなことになったこと無いもの
x265はほぼ使ったこと無いので知らん
現状のx265なら
「8ビット圧縮で使ってる圧縮技術より10ビット圧縮で使ってる圧縮技術の方が優れてる」
ということもあるのかもね
>>502 と
>>474 で全部色が変わってしまっていて何かがおかしい
＞デバンドあり圧縮前をcrf0で8bit化したavc
っていう中間形式の作り方の詳細がよく分からないので何とも言えないけど、
色が変わってしまっているってことはどこかの段階で色空間かレンジの変換がかかってるということはないすか？
ちゃんとやれば、crf0が厳密には可逆圧縮ではないけどほぼ無劣化でエンコードできて
中間形式を経由した影響はほぼないはずで、
>>474 デバンドあり 8bit --crf 20 --aq-mode 3 --tff
と
>>502 これがそのavcをcrf20 8bitエンコしたもの
QP:19.37 size: 31899byte
で色が変わってしまうということは起こらないはず
黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、
よく見えんところをはしょってごまかすのが圧縮の本質だからなあ
>>517 バランスの問題もあるな
明るいところとかもっと削ってもばれねーよってときに暗いところ端折りまくるのがね
x264ならその方面のことは設定でなんとかなる柔軟性はあると思う
>>515 おかしいと思うなら自分でやってみたら
1枚の画像から1フレームの動画を作るくらいできるだろう
10bit主張する人は検証画像いろいろ上げてるの、
このスレやググったりして見かけるけど、
8bit主張する人で画像を上げた人が一人もいないんだよね
論より証拠なのに勘ぐってしまう
バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよｗｗ
別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ
>>519 動きのない完全静止の動画でよければ良ければやってみるよ
>>520 完全素通しっていう前提で主張してるのに、色が変わった（のが分からない人はさすがにいないよな）ならもうそれはカバーできない条件だわ
>>514 ソースにディザが残ってるのを圧縮してディザを消しちゃうとバンディングが出る
デバンドあり 8bit --bitrate 20000 --aq-mode 3 --tff
↑8bitだけどビットレート高いからディザが残っててバンディングが出てない
ブルーレイとかはこんな感じ
>>514 チューニング次第では？
基本的な技術は同じで違うのは色深度だけなんだから
やってみた。
それについては、ブロックノイズが出まくる領域だとたしかに内部計算的には周辺の平均をとって、
実験結果
バンディングがある8bitソース(GWNr9Ru.png 10秒)
[enc1_crf20_8] 8bit crf20 199KB
[enc1_crf20_10] 10bit crf20 178KB
[enc1_crf35_8] 8bit crf35 47.9KB
[enc1_crf35_10] 10bit crf35 48.4KB
ディザでバンディングを軽減した8bitソース(GWNr9Ru.png 10秒)
[enc2_crf20_8] 8bit crf20 275KB
[enc2_crf20_10] 10bit crf20 245KB
[enc2_crf35_8] 8bit crf35 47.5KB
[enc2_crf35_10] 10bit crf35 48.2KB
なるべく途中で変な処理が入らない用意全部コマンドラインでエンコードした
一連のコマンドは禁止ワードに引っかかったのでpastebinに貼っておいた
https://pastebin.com/b5fBXuRy imgur使うとある程度のサイズ超えるとjpgになってしまう
ちなみに色に関しては解像度で自動的に認識してくれるかなーと思ったのと、
>>530 そうなんだ、それは知らなんだ
まあURLから見ても特にこちらの主張が成り立たなくなるほどの劣化は無いと思う
コマンドは示したので、興味があれば手元で追試することもできるのでそこで確認してくれ
>>527 > 10bitだと概ね2割増しのデータを保存しないといけない
この認識は間違ってる
保存するのは量子化した後の値だから量子化ステップの幅（QP値から計算される）に依存する
8bitから10bitに2bit増えても、量子化ステップが4倍になれば理論的にデータ量は変わらない
H264の場合、QP値が6増えると量子化ステップが2倍になるから、
>>502 見てもだいたい12増えてデータ量は同じくらいになってるでしょ
>>533 単純計算して2割増しになるってのはおっしゃる通り、
QPを増やさない（＝一切副作用無く画面全体に8bit→10bitの恩恵を受ける）場合のこと
単純にそうはならないしても、同じファイルサイズで考えたとき
どこかで10bit分の量子化の恩恵を受ける分8bitよりデータが増え、
他のどこかがそれの割を食わないとファイルサイズが8bitと同じにならない
のっぺりした部分に8bitのときよりも細かい量子化を行う（つまりQPが12ほどは増えない）分、
そのほかの部分でQPを12以上増やさないとファイルサイズは同じにならないでしょ
（これも量子化の後にエントロピー圧縮を行うので単純にそうはならないかもしれないが、話を簡単にするために）
実際ファイルサイズがほぼ同じになるcrf35で比較して、のっぺりした部分の再現性は10bitのほうが上だけど、輪郭は8bitのほうが若干よく見える
>>531 >>532
いあ正にその色に問題出てるのよ
jpgはYUV420だがpngは24bit
IrfanViewだと目視じゃ違いが見当たらないが
Firefoxや古めの画像ビューアでみた時、pngだけ色が違う
ちゃんと正解の画像見れてるのかモヤっとする
>>535 ffmpegでRGB→YUV変換するときにちゃんとどういう色空間のYUVにするかちゃんと指定しないといけない
（何も指定しないとたぶんBT601になる？）
https://forum.videohelp.com/threads/380991-ffmpeg-x264-RGB-to-YUV とかいうのもあったりするので、もうちょっとちゃんとオプションを精査したうえで追試してPNGのまま上げられるところ探して上げるわ
普段YUVのソースしかエンコードしないので、今回使えるソースがRGBのPNGだったので、
手際が悪くなって申し訳ない
>>534 のっぺりした部分に8bitよりも多くデータ量割かないと
10bitの恩恵が受けられないってのは確かにそう
で、バンディングに関して言うと、8bitでバンディングを回避するには
ディザを残さなくちゃいけないけど、
8bitでディザを保持するためのデータ量に比べれば
のっぺりした10bit分の色を保持するためのデータ量の方が
圧倒的に小さい
だから、バンディングに関しては10bitの方が圧倒的に有利
↓こんな感じ
データ量
(8bitでディザを残す) >>> (のっぺりした10bit) > (のっぺりした8bit)
画質
(8bitでディザを残す) ≒ (のっぺりした10bit) >>> (のっぺりした8bit)
実験結果
バンディングがある8bitソース(source1 10秒)
生成元
と色も含めほぼ変わらないのを確認※
[enc1_crf20_8] 8bit crf20 185KB
[enc1_crf20_10] 10bit crf20 166KB
[enc1_crf35_8] 8bit crf35 47.9KB
[enc1_crf35_10] 10bit crf35 48.2KB
（続く）
ディザでバンディングを軽減した8bitソース(source2 10秒)
生成元
と色も含めほぼ変わらないのを確認※
[enc2_crf20_8] 8bit crf20 264KB
[enc2_crf20_10] 10bit crf20 234KB
[enc2_crf35_8] 8bit crf35 47.6KB
[enc2_crf35_10] 10bit crf35 47.1KB
※一部の領域の色が違う（ディザのほうはちょっとだけバンディング出てる）のはおそらくRGB→YUB→RGBと戻ってきたときの誤差
こればかりはソースとして一度RGBになってしまったものを使う以上仕方ない
結論としては特に変わらず
>>539 8bit crf20だとディザが残ってるね。静止画だからビット数多く割けたのかな
動画だと
>>474 にあるようにディザは消えちゃうんだよ
>>537 のっぺりする＝ソースのディテールを再現できないほどの低レート、なんだから、
＞画質
＞(8bitでディザを残す) ≒ (のっぺりした10bit)
という等号はおかしい
のっぺり度とファイルサイズは無関係な量じゃなくて関数になってるんだからどちらかを固定しないと不等号として意味が無い
正しくは
データ量
A:(10bitでディザ(≒ディテール)を残す) ≒ B:(8bitでディザを残す) >>> C:(のっぺりした10bit) ≒ D:(のっぺりした8bit)
としたとき、
画質
A:(10bitでディザ(≒ディテール)を残す) ≧ B:(8bitでディザを残す) >>> C:(のっぺりした10bit) >> D:(のっぺりした8bit)
ではないの？
・AとBなら再生互換性があってとくにデメリットがないB
・CとDなら互換性は無視できればC、ただし画質の劣化の方向性が違うのでトレードオフ要素あり
じゃないの？
>>541 そうなるってことはディザ部分に割り当てる情報量が不足しているということだと思う
単なるCRFの話じゃなくて（動画で単にCRFだけ上げると他の要素の情報量が過剰になる）、
psy-rdとかの出番だと思う、もちろんファイルサイズは（単にCRFを上げるほどではないにしても）増えるけど
まあ、上の例でいえばABとCDの中間の状態になるわけで、
ソースのディテールを逐一再現するほどではねーわ、多少ディテール捨ててのっぺりさせてでもサイズは減らしたい、
っていうときは10bitにも利点はあると思う
ある意味フィルターをかけてるとの同じことになるわけで
>>542 > のっぺりする＝ソースのディテールを再現できないほどの低レート
まず、想定しているのは
>>539 のcrf35ほどの低レートではなくて、
>>539 のcrf20や
>>523 のようにディザが残るほどの高レートでもない
その中間
（試してるのが両極端すぎるｗ）
フルHDで２～８Mbpsとかの一般的に使われるレートだよ
そのレートだと、ディザは消えるけど、他のほとんどの目立つディテールは残る
で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
MPC-HCとかオプションにディザのオプションとかあるでしょ
だから、出力される絵は8bitでディザが残ってるのと同じような絵になる
8bitだとディザが消えてのっぺりしちゃったら、もうそれまで
8bit→8bitでディザを付加したりはしないからバンディングはそのまま
>>543 動画でディザが残せるのは相当高ビットレートだよ
>>523 は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから
20MbpsってCRFだと相当低い
ブルーレイ並のビットレートがないとディザは残せない（8bitでも10bitでも）
さらに言うと、データ量減らすためにエンコしてるんだから、
うーん、なんかだいぶcrfに対する感覚が違うなぁ
>>547 なるほど、BDだとソースが良いから状況がいいんだと思う
放送だとMPEG2だしビットレートそんなに高くないから、
ディザは残せなくて、それでもバンディングを目立たなくするために
時間軸方向に色をパタパタたさてるんだよ
それを普通に8bitでエンコすると
>>512 にあるように「うにょんうにょん」になる
時間軸方向にパタパタさせてるもんだから、ディザを追加してもエンコしたら消えちゃう
時間軸方向NRを多少強力に掛ければまともになるのかもしれないけど、
副作用があったりで難しいんだよ
BDだとこの「うにょんうにょん」が出ないんだろうね
>>548 地デジソースもたまにエンコードするけど、
ソースに加工しない（ソース時点で起こっているあらゆるアーティファクトはそのまま）という前提なら
crf20ぐらいでアニメならソースほぼそのままでサイズもいい線（半分程度）にはなるんだがな
さすがに地デジにドット単位の粒子は無いという前提で、psy-rdはいじらない
まあさすがに実写はこのcrfだとだめね、平気でソース並みのサイズになる
ソースを加工してでもバンディング消す（＝8bitならディザを残して大幅にエントロピーを増やさざるをえない）かどうかが
この感覚の差なのかな？
そのうにょんうにょんってのが何なのか分からんのだが、
>>551 ソースでは細かくパタパタしてるだけなんだけど、
エンコするとそのパタパタの周期が落ちて目立つようになってくる
ビットレート低いとさらにその周期が落ちて「にょんうにょん」動くようになる
放送ソースだとx264との相性が悪いっぽくてビットレート低いと悲惨なことになる
QSVだとビットレート低くてもあまり動かないから目立たない（バンディングは残るけど）
crf20だと、まだそんなに周期落ちてなくて目立たないから気づかないかもしれない
>>552 なんかその現象はこちらはピンと来ないんだよな。
関係あるか分からないけどインターレースに起因するアーティファクトってことはないすか？
＞エンコするとそのパタパタの周期が落ちて目立つようになってくる
っていう時点でエンコかける時点で避けられない劣化みたいに言ってるように見えるので。
まずこちらにやり方として、アニメのエンコとして異端なんだとは思うんだけど、
アニメだろうが何だろうが地デジソースは60iを60pに変換して24pは一切考慮しない。
なぜならばテロップは60iで動いてたりするし、一切誤爆のない60p→24p変換ってのもないと思うから。
そもそもエンコードの目的がtsの取り回しを良くするのと
リアルタイムI/P変換の品質が悪いのであらかじめ60p化しておきたいという目的だから。
60Hz以外のモニタ持ってないから60Hz系以外のフレームレートにしても意味ないし。
まあでもこれはこちらが60p化で止めてるものを24pに落とせばいいだけで、
むしろデータ量が多少減らせる（60pでもほぼ差分の無いフレームなので大差はない）ぐらいで
悪いことは特に起こらないと思うけど。
ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。
あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを
>>553 ごめん、もう説明するの疲れたわ
QTGMCはBob化ベースだから細かい文字とか潰れるんだよね
だから、QTGMC掛けた後にソースから細かい文字だけマージするフィルタ作ったわ
SouceMatchやLossless使うよりも効果があって、処理も軽いよ！
どうよこれ
あと、CUDAしたKTGMC使えばかなり速くなるよ。時間があったら試してみて
>>503 改造版のaufいただけませんか？
アド晒すので送ってください。
m y o k u 3 5 1 @ n e k o 2 . n e t
普段からタブレットやスマホでx264でエンコした動画を再生しているのだが
>>560 動画の出来をチェックするならバンディングとかちゃんと見えたほうがいいと思うのだが
きれいに見たいだけならWindowsでもレンダラ選べる再生ソフトに変えたらいいと思うぞ
>>556 KTGMC、試すアル
>>559 もうあったぞ
>>558 これ実装したときはあまり効果がなかったなと思って、
改めて見てみたら、デフォルトのしきい値15は高すぎるんだった
8bitYUVの差1はだいたい5に相当するから、6～10が適正値だね
>>474 はしきい値が高すぎてかなり強く掛かってるから副作用出まくり
普通に使えばこんな副作用でない
しきい値6～8なら改造版使ってもほとんど変わらないから、あまり意味なかったわ
>>560 単にタブレットやスマホはコントラスト低いから目立たないだけじゃね
Windowsって言っても動画再生はGPUに依存する
Intelの内蔵GPUはクソ画質
>>544 >で、「のっぺりした10bit」は、のっぺりしてても10bitの色なんだよ
>で、プレーヤーが8bitに落とし込むときにディザを付加するんだよ
>MPC-HCとかオプションにディザのオプションとかあるでしょ
>だから、出力される絵は8bitでディザが残ってるのと同じような絵になる
LAV Video Decoderのディザリングのことかな？
10bit深度の動画を見るのにデコーダで8bit化して出力してる人なんているんだろうか？
10bit使うような人はmadVR使うとか、MPC-BEで内臓デコーダー＋EVR-CPとかにして
10bitYUV4:2:0をそのままレンダラに渡すようにしてる人がほとんどだろうから、
LAVでディザリングするような使い方をしてる人はあまりいないのでは・・・？
>>567 8bit出力でも効果があるっていう原理を説明しただけ
ほとんどデフォのままでも10bitならきれいになる
モニタまで10bitで出力できるような環境ならそれでいいんじゃない
>>556 QTGMC(EdiMode="TDeint")
で、TDeintと同じように輪郭はボケなくなる
結局TDeintと動作原理は同じなのかもしれないけど、
QTGMCのおかげでいい感じの動きに補完してくれてエッジのわさわさが消えてくれる
まあ動きは補完してるので、1ピクセル単位の微細な動きのときに微妙な変形が起こって、
コマ送りすると変なんだけど、等倍の速度で見ると意外なほど自然
60iで失われてるところをもっとも自然に補完するとこうなるんだと思う
>>568 というかYUVの8bitとRGBの8bitが1:1に対応してないから
最終段階(RGB)が8bitなら変換前の色空間(YUV)はそれ以上のビット数無いと劣化するって話で、
RGBにディザをかけるかけないは全く不要だと思う
正しいモニタで正しいグラフィック出力が行えてればRGBの8bitのバンディングなんて見えることはないわけで
>>568 で、x2648bitだけでデバンドはどうすりゃいいの？
>>569 そういう方法もあるのね
QTGMC(EdiMode="TDeint")だとQTGMCのベースの絵にTDeint使うけど、
>>556 はQTGMCの後に補間するから原理はちょっと違う
確かにデフォルトのNNEDI3と比べてちょっとノイズっぽいのが増えるけど
動画で見ると分からないね
まぁ、ぶっちゃけコマ送りだと動いてるところはTDeint汚いけど
動画で見ると動いてるところは分からないから、TDeintだけでも十分なんだよなｗ
>>570 > RGBの8bitのバンディングなんて見えることはない
AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ
>>571 そうなんだ
素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの？
>>573 >AviUtlは内部が12bitで表示は8bitRGBだけど、NR系フィルタで滑らかにするとバンディングでるよ
試したことはないけど、高深度であっても、バンディングが発生するようなフィルタ処理をすれば
バンディングが発生するのは当然では・・・
>素のwindowsにmpc-hcとか入れただけでも10bit再生したらレンダラ10bitYUV渡してくれるの？
10bitYUVを受け取ってくれる（渡して意味がある）レンダラは「madVR」と「MPC-BEのEVR-CP」かな。
MPDNあたりも大丈夫そうだと思うけど使ったことないのでわからん。
EVRやMPC-HCのEVR-CPではレンダラ内部のMixerでYUY2化されてしまうので無意味だったと思う。
>>574 > 10bitYUVを受け取ってくれる（渡して意味がある）レンダラは「madVR」と「MPC-BEのEVR-CP」かな。
なるほど、サンクス
レンダラが10bitに対応してなくても8bitRGBで渡せば問題ないよね
モニタまで10bitで出力したいって場合は別だけど
>>571 世の中の人は「madVR」か「MPC-BEのEVR-CP」を使うのが一般的なのか
mpc-hcとか使ってる人は「ほぼいない」のか
ちょっと認識にずれがあるようだ・・・
>>575 なんかうまく伝わってないようなので書いとくけど、
・10bitエンコにこだわるような人は10bitを生かすような再生方法もちゃんと考えるものだろう。
・その場合、採用するのは
>>571 の１または２がほとんどであり、３(デコーダでRGB化)にしてる人はほぼいないだろう。
・１か２を採用する場合、madVR（多分ほとんどの人がこれかな）や、MPC-BEのEVR-CPを使うしかないだろう。
ということであって、世間一般という話はしてないよ。10bitユーザに関してはそういうものだろうという話。
まあ別に統計調査したわけじゃないけども。
３の方式にこだわる理由って何かあるの？
>>576 そういうことね
>>568 にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる
てか、上の方から見れば分かると思うけど、バンディングの話してる
8bitRGBでもバンディングは十分消せる
> ３の方式にこだわる理由って何かあるの？
世の中一般的な人の手を煩わせないこと
>>577 >世の中一般的な人の手を煩わせないこと
LAVで出力をRGBに絞るための手動設定が必要だし、10bit以外も全部RGB化されることになるし、
DXVA(native)も使えないしで、余計に煩わしい気がするので、おとなしくmadVRかMPC-BEを入れた方がいい気がする。
まあそれぞれの自由だけど。
>>578 分かっよ。デフォルトだと8bitYUVになるから、
ちゃんと10bitに対応した再生環境を入れろって言いたいのね
拘りがあるみたいだし、詳しそうだから聞くけど、
デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとで
どれくらい差があるの？
あと
デバンド10bitがファイナルアンサーってことでおｋ？
>>582 １人で空騒ぎを続けてる姿はなんか見てて可哀相になるんだけど、戻れるならそろそろ正気に戻った方がいいんじゃ・・・
>>579-580 > デコーダで8bitYUVに変換したのと、レンダラで8bitRGBサーフェスに描画したのとでどれくらい差があるの？
暗めのグラデーションとかで試してみればわかると思うけど、
デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。
>>579-580 >>574 の後半は少し間違ってたかも。 バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなｗ
最小限、VLCでまともに見れれば問題ないんじゃね？っていう。
>>585 > 暗めのグラデーションとかで試してみればわかると思うけど、
> デコーダで10bitYUV→8bitYUV変換をしちゃったらバンディング起きまくりになるよ。
これが違う。適切にディザリングされてればバンディングは発生しない
>>474 の「デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff」を
LAVのデコーダで10bitYUV→8bitYUV変換してEVRで表示したときの画像
これがバンディング出てるように見える？
>>474 はAviUtlで読み込んでキャプチャしたから、
ディザリングなしで8bitRGBへの変換が行われてバンディングが出てるけど、
ちゃんとディザリングすれば8bitYUVへの変換でもバンディングは出ない
何度も書いてるけど10bitでエンコしたやつを8bitで再生してもバンディングは出ない
MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると
>>590 これが汚い原因分かった
RGBやP010だとグラボの高品質デインタレが対応してないから汚くなる
インタレ動画はデフォルトのNV12が一番綺麗だね
グラフィックがAMDやIntelの環境は知らないけど
>>589-592 https://pastebin.com/PjXMXesZ https://www.axfc.net/u/3856752.zip >>593 おーお疲れ。うちの環境でも表示のされ方はだいたい同じだったよ
なるほど、YUVでディザリングはしてるけど、YUV→RGB変換が1対1に対応しないから、
値を飛び越えちゃうところで色の違いが出てるのかなぁ
いろいろな影響があって難しいね
>>593 ところで8bitで再生って具体的にどうやるんだ？
プレイヤーとかデコーダにそんな細かな設定項目はないだろ？
>>595 無知な上にスレチな話題を無駄に広げるんじゃねーよ
>>595 >>597 俺が元々言ってたのは
「8bitソースを8bitでエンコして8bitで再生」するより
「8bitソースを10bitでエンコして8bitで再生」した方がきれいになるって話
「8bit or 10bitソースを10bitでエンコして10bit再生」した方がきれいだってのは
そりゃそうだけど、そんな話してなかったし、
「10bit動画をいかに綺麗に再生するか」って話はここだとちょっとスレチかも
エンコ前のソースではなく、デコーダに渡される10bitでエンコされたものをソースと言ってるように読める
>>599 そちらの話をきっかけに10bit動画の再生検証とまとめをしてみただけなのであまり気にしないでくれ。
>>600 あー、たしかに
>>597 の書き方は誤解を生んでしまうかも。
そちらの指摘どおり、「10bitソース」とあるのは「10bitエンコされた動画」のことです。
>>601 うにょんうにょんの話から始まってたのか
色々しらべてくれてありがとう
>>601 じゃあ、もう少し乗っかってみる
>>594 で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた
環境はGTX1060でWindows10。全部MPC-BEでEVR-CPレンダラ
LAV→(NV12)→EVR(8bitサーフェス→8bitRGBディスプレイ）
>>593 とちょっと色の出方が違うけど、バンディングは同じようにも見える
LAV→(P010)→EVR(8bitサーフェス→8bitRGBディスプレイ）
>>593 のmadVR-P010-ditherONと同じような表示になった
LAV→(NV12)→EVR(10bitサーフェス→8bitRGBディスプレイ）
>>593 のmadVR-NV12-ditherONと同じような表示になった
Intelグラはディザリングしないんだね
UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか
>>603 うち、マルチモニタ環境なんだけど
Chrome[ハードウェア アクセラレーションが使用可能な場合は使用する]にチェック入れて
モニタ1：GTX660→DVI接続→IPSパネル
モニタ2：4790KインテルHD→アナログ接続→VAパネル
でそれぞれpngを開くと、モニタ1だとどれも階調分からん、モニタ2側だと一番上のはガッツリ色割れが見える
GPUなのかモニタ原因なのか接続方法なのか…オモシロｗ
比較するなら何故接続方法とディスプレイを同じにしないのかなぁ
>>603 どうせ比較するならカラーバーにしてほしかった。
何故黒背景なんだ？違いがわかりにくすぎるわ。
>>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というショボ環境だから、他の人の結果や意見も聞いてみたいところ。
>>603 ２番目の画像を見る限り、そちらの環境では、EVRがP010を綺麗に処理できていないように見える。
「madVR-P010-ditherOff」が、LAVがレンダラに渡してるP010データとほぼ同等なはずだが、それより酷くされている。
nVidiaコンパネで何らかの映像補正処理がONになってる可能性もあるかも？
>>604-605 > Intelグラはディザリングしないんだね
ディザリングというべきかデバンドというべきかよくわからないけど、
「madVR-**-ditherOff」（LAVがレンダラに渡しているデータ）と「EVRCP-**」を比べると、
後者の方がバンディングが目立たなくなってるので、処理はされてる模様。
>>610 部屋を暗くしてモニタを明るめにすればわかりやすいと思うけど・・・。
そもそもバンディングの話をしてるのに、なぜカラーバー？
まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、
スケーラー的には
>>611 こちらは4Kブラビア（KJ-49X8300D）にAVアンプ（AVR-X2100W）経由で繋いでる
「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
>>613 確かにIntel GPUの糞な補正が掛かるよりはmadVRの方がきれいだってのは分かる
うちのPascal GPU環境だとEVRとmadVRはどちらもいいろこ悪いところがあってどっちもどっちって感じ
だから動作が軽くて安定してるEVR使ってるわ
>>614 スケーラーってなんぞ？madVRだとChromaUpScalingの設定が各自でバラバラになるからとかそういうことかな？
>>615-616 8bitRGBディスプレイって書いてるから普通のPCモニタかと思ったらブラビアだったのか・・・。
ブラビア側でデスクトップ映像全体が補正されて、発生してるバンディングがほぼ見えなくなってたってことかな・・・？
>>611 に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、
ブラビアまかせじゃなく出力そのものを良くしたいなら、GPU補正設定の再確認やmadVRへの移行をした方がいいと思う。
GTX1060＋そのブラビアならmadVRを入れて直接接続すればYoutubeのHDR動画とかも見れて楽しそう。
まあさすがにx264とは全然関係ない話になるのでこのへんで・・・。疑問とかあればmadVRスレへ。
>>617 > EVR-CPのP010処理が何か変
おかしくはないよ
うちの環境で「BE-白050-線-EVRCP-P010」を写してカメラで撮ってみた
>>593 の画像
>>603 の画像
一応、俺の感想を言うと
>>593 の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる
>>603 の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる
ちなみに、暗いところのバンディングは画質設定で黒を目立たなくすれば見えなくはなる
ただし暗いところが潰れて見えるようになって画質が落ちるからそれはやりたくない
>>617 EVRはbilinear
EVRカスタムはbicubic
madVRでいうimage upsamplingのはず
だったんだけどGPUによって差があるみたいだからDXVAたたいた時は
GPUのエンジンを使うのかも
>>618-619 申し訳ない。こちらがボケてました。
> 「6bit+FRCなTN」と「4Kブラビア」じゃ環境が違いすぎて見えてるものが違うんだと思う
これですよね。モニタサイズも解像度も違うんだから見え方違って当たり前だ・・・。念のため26インチTVで確認して納得。
見え方だけじゃなく画像の差分をとったりもしたんだけど何か間違えてたっぽいです。
もしよければそちらの「白111-P010-EVRCP(8bitサーフェス)」のスクショも上げていただけると嬉しいです。
>>620 拡縮まで入るとややこしいので等倍のみ考えてました。なおBEもHCもEVR-CPのリサイザのデフォはbilinearの模様。
>>621 プルダウンで簡単に使えるのが利点っちゃ利点＞EVRカスタム
>>621 白111-P010-EVRCP(8bitサーフェス)
サンプルは
>>516 が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw
バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな？
>>623 ありがとうございます。参考にさせてもらいます。
>>626 そのタイトル絵は知らんけど細部がつぶれるといった副作用もあるんだし、自分の好みで調整するものでは。
>>626 基本的にソースにあるバンディングを消すものだよ
けど、ソースを少なからず弄るものだから
冒頭の極端なものは無視するが吉
MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか？
no-info パラメータって x264 にはないんだっけ？
>>630 あったとしても、エンコード日付までは消せないか
ソースいじって自ビルド使うしかなさそう
エンコード日とかって
>>632 が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから
Muxだけやり直せば上書きされるはず。
わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな
違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。
ファイルの並び順を作成日時でソートしているのですが
>>635 デカ過ぎるcrf値にしていたり、ダイエットし過ぎたbitrate値にしているのをバレたくないとかじゃね？
あとはme dia にしてるのをバレたくないとかw
>>639 それなら単純にファイラーで作成日時いじればいいだけなのは明らかにわかる
火消し必死な自称エンコ職人の違法アップロード野郎
>>640-641 >>629 が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。
>>642 「（ファイラーで）作成日時をいじったけど、MediaInfoで見れるエンコード日などもそれにあわせたかった」ってことでしょ。
まあ変なこだわりだとは思うけど、これ以上どうこういっても無意味。
>>641 ソースがノイズだらけのフレームは me dia で psy-rd も 0:0 にしてるわ
x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか?
>>645 両方ともグリスバーガーだから、オーバークロック前提ならRyzenスレッドリッパー1950Xだろ
殻割りで壊すリスク冒すなら7920Xでもいいが
オーバークロックはしない前提で
スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ
threadsを最大にしても、殆ど全部使い切らないx264で
4～8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた
良いプラグインを選んだり自分で最適化ビルドして
x264のソースで、
CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね
メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない
x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ
>>648 6950XだとフルHDアニメのx264(10bit)エンコードでほぼ100%にはりつく
20スレッドより多いcpuで試したことないからその20位で頭打ちとの説が本当かどうかわからんな
>>661 Doomで中の人が言っていたから本当
だが、それはSDサイズの話だろう
SDで6950Xだと70%くらいしか使わないんじゃないか？
x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる？
最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ
x264をvtuneで解析する方法
下手に触ったら、弄りすぎて壊れた…
x264の内部
関数内の処理時間順
呼び出し回数順
Intel C compilerで作った
[email protected] https://dotup.org/uploda/dotup.org1391216.zip.html ソースは、弄ってないバージョン
バイナリの環境はSandybridge以降に依存
依存したDLLとか調べてないから、動かなかったら教えて。
自分でビルドしたい人は、ｍｓｙｓのlinkerをmvしたりしないと通らないから要注意
>>667 その画像、jane styleでdecode errorになるのだが・・・つかえねぇなほんと。
画像うpするなら自分で消さなきゃなかなか消えない、imgurを使えよ。
俺のjane styleではちゃんと表示できてるぞ
今、ブラウザでアクセスしたけどリンク切れだったよ
結局janeのビューアが改善すればいいだけの話か。
r2345
>>673 自ビルドすればいい
基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ
r2345にこだわる理由はおそらくこれじゃないか。
ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから
>>677 ありがとうございます。理由は
>>679 氏の指摘です
本当に助かりました
たしかそれ以降にもAMD向けのはガッツリ削られたんだっけ？＞XOPとか
>>680 ryzenAPU(GPU内蔵)が来年頭に出るらしいから、コンシューマ向けだとそれで完全に事足りるわな
ただし4コアしか出さないらしい
余談だが、ブル世代のAPUとFXもMisaligned SSEが使えるわけだけど、それも無効にされている。
暖房用にx264を全力で走らせてるんだが中々部屋が暖まらない寒いよー
フィルタ処理をGPUにやらせて、PC台数も増やせば結構暖まるよ
PCの排熱を使用した暖房機器で電気代タダってのが外国でやってなかったっけ
副次的に温まるのは仕方がないが暖房に使おうという発想はおかしい
電熱による暖房は効率が悪いからな
なんとなくr2893メモ
10bitでエンコしてると8bitでエンコする機会なんて格段に減ると思うのだが。
放送物はBDMV準拠で保存してるから、逆に10bitでエンコする機会がない
自分の好きなようにしたらエエ。
x264.exeにフィルタ機能とかリサイズ機能とか正直いらないんだよな。
linuxでもWindowsでも同じようにフィルタかけられて便利
x264guiEx 2.53、r2893バイナリ対応
誰でも自分ＰＣで稼げる方法など
× Komiser
今回modは判別ルーチン入れる必要あるしテストも含めて時間掛かるんじゃ
10bit版のパッチがなかったら移植の手間がかかるのでは
tmodのr2893が来てた。
パッチとの互換性を考えてffmpegは2.8.xのままとか、新しいブランチ作ったとかのWARNINGあり。
https://github.com/jpsdr/x264/releases kmodはまだ来てない。
>>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。
>>708 説明お疲れ様です
>>709 公式とは別物
コアな機能改善が省かれてるかどうかはわからない
.
個人的に分割してくれたほうがいい気がする(1つに集約＝その分重くなる？)
うちでr2851kModとr2893(rigaya版)を一発比較した限りじゃ特に変わらんようだけど。
■10bit
普通に考えて8bitか10bitか毎フレーム判断するわけないわな
60000/1001で同じようにエンコしてどのぐらい出るか知りたい。
crf20でそんなに縮むのはアニメだからだな
>>717 アニメで60fpsとかよそで言うと恥ずかしいから気をつけろよ
何がだよ。SAOの映画とか60fpsでエンコしてみろ、動きがヌルヌル過ぎてすげー気持ちいいから
映像自体が60のアニメもまったく無いわけではないがごく一部だけだな
特にエンディングのスタッフロールとかは60fpsでエンコすると
>>717 >>722 フレーム補間という手法を覚えたばかりではしゃぎたくなるのはわかるけど、スレ違いなので他でやっとくれ。
何を使ってフレーム補間してるのか知らないけど、逆テレシネしてないアニメをソースにしたり
いまどきMBlockFPS()を使ってるなんてオチがなければいいけど。
>60000/1001で同じようにエンコしてどのぐらい出るか知りたい
エンコード速度(fps)は毎秒どれだけのフレームを処理できるかを表すので、元動画のフレームレートは関係ない。
フレーム数が増えれば必要時間は増えるし、フレーム補間してるならその負荷がかかるけど
それはx264とは別の話なのでこのスレでは関係ない。
>>718 >>712-713 のtest-1080p.mkvは、x264/x265ベンチマークスレで使ってる実写映画の予告動画だよ。
>>722 このスレでも無知を晒し続けるのマジで恥ずかしいからそれ以上やめろ
俺の共感性羞恥に効く
一時期あった30/24混合のアニメは面倒だからインタレ保持でやってる
むしろ動いてないところは削りまくってタイムコードで引き伸ばしてるわ
60iを60pにしたというオチじゃないよな
昔からドラマのOPをヌルヌル綺麗にエンコしたいとか散々見たような
>>729 上から目線で他人のエンコ趣味をコケにしてそんなに楽しいかね？
フレーム補間の60fps化だろ
>>733 A's Video Encoder なら Fluid Motion でフレーム補完したエンコがでける。
俺のブラビアで再生すれば240fpsで超ヌルヌルだぜ
エンコ日が動画埋め込まれるのを消したり変更したりはできないの？
すまぬ、訂正
>>741-742 ありがとう
参考にしたいと思います
ちと使ったことのないソフトを使うようで俺には難しいかな
>>731 すまんね
ドヤ顔でキリッの相手は、幼稚園の先生かママにお願いしてください
エンコ日やmux日を偽装や隠蔽して一体なにがしたいのやら。
違法アップロードのエンコでこんなに低いcrfなのに低ビットレートってスゲー、って思われたいんだろ
旧作アニメのエンコをして、当時の放送日時に合わせて日付を設定しちゃおう！っていうのなら
エンコ日時フィールドにエンコ日時以外を入れたいとは思わないな
俺のエンコは、mkvでmuxするときにTSから拝借したEIT情報を埋め込むぐらいだな。
エンコ日を偽装したいとは思わんが、
グループポリシーで自動更新関連を全て無効、サービスでも自動更新関連を無効にしているにもかかわらず
動画エンコード開始して寝て起きたら、なんと1時間ごとに再起動されていた
当然ファイルは破損していた
もうやだこのゴミOS
Windows10 16299.192
気がついたら同じような動画を何回も拾ってる
>>753 WindowsUpdateサービスを無効にすれば解決するぞ。ただし、長期間そのままにしてあると
定期的なライセンス認証の確認作業に不具合が生じてバルーンヘルプが出始めるかもしれないが
>>753 寝ている時間をアクティブ時間にすればいいのでは？
１度も勝手に再起動された事はないな。
>>753 RS2までロールバックしてみたら？
Win10は一度ロールバックするかクローンHDDから復旧させてCBBのWU確認期限を１年間にしておけば
重要なアップデートが見つかっても検知されないまま放置される。
x264guiExで実写を品質基準VBR (crf)でエンコしてるのですが
ソースによって変わるからソースにあわせてcrf値を調整するしかない。
内容的に --tune ssim は関係ないやろ。
>>760 やっぱそういう感じなんですね。
ありがとうございます。
ちなみに、その0.985っていう値はどこから出てきたの？
SSIMの表示には --ssim が必要だけど、>>764 が言いたいのは値の取得方法ではなく psy入れてたらSSIMも糞もないだろうな
地デジ、実写、爆発シーンがあるアクション映画がソースで
crfで綺麗にエンコできる設定だからって
crfこそがきれいにエンコオードできる設定だからね
>>770 上限ビットレートを12Mbpsぐらいにしとけばいいんじゃね？
上限じゃなく平均レートに6~10Mbpsを指定する必要がある
ノイズかどうかって人間の目ならだいたいわかるんだから
googleがビッグデータを使ってディテールを予測して補完するエンコーダーの研究してるよな
771からの話だとして、なぜ平均レート6～10Mbpsと言い出したのかよくわからんのだが・・・
crfやめて2passで高画質を狙うなら
crfとか2passとか設定出さずに爆破シーンのエンコとか
>>781 > あとｘ264出力(GUI)Exでエンコしてんだけどマルチパスとか
> サイズ確認付き品質基準の「上限ファイルビットレート」項目の
> 設定もビットレートのピークを制限するものだよね？
全然違う。
あれはできあがったファイルサイズ(ビット単位)を秒数で割った数値がそれ以下になるようにするというもの。
昔のニコ動のエコノミー回避や一般会員のビットレート制限のために作られた。
ニコ動の仕様が変わったので、もう使われることはないだろう・・・多分。
>>782 ありがとう。
品質基準の「上限ファイルビットレート」は
目的が全く違うんだね。
>>783 いるよなｗ
CCEの影響か
マルチパスは画質を捨てて、エンコ後のデータ量を揃えたい人限定じゃね？
crf使ってるのに何度もエンコしてファイルサイズ揃えようとする馬鹿も笑えるよな
psy入れてるのに毎回ログでSSIM解析値残してる俺
>>786 VBVでビットレ制限すればcrfでもデータ量を揃えることは可能だが
アニメ以外だと高いSSIM値になっていても糞画質な映像に仕上がってることが多い。
ロスレスは劣化が無いと信じて使ってたけど
RGBソースをYUV4:2:0の可逆で保存してたってことかな。
このスレへの固定リンク： http://5chb.net/r/avi/1485572817/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「x264 rev43©2ch.net ->画像>47枚 」 を見た人も見ています：・ミッションBOINC@unix run-level6 【留守録無理】DECULTURE PT2X2 Rev.20【視聴はOK】 NONA REEVES Part.7 Nerf Rev-25(ﾜｯﾁｮｲ+IP) Homefront: The Revolution 「CTGP Revolution」フレンド募集 北斗の拳 LEGENDS ReVIVE part14 Republic: The Revolution 日本語翻訳スレ 産業革命（Industrial Revolution） 【R2】Reign of Revolution まだまだイケル 【AC】crossbeats REV. 24th STAGE【クロスビーツ】 【3波】 アースソフトPT1/PT2/PT3 Rev178【TS】 ★ASUS (エイスース) マザーボード友の会★ Rev.57 Androidプログラミング質問スレ revision54 【3波】 アースソフトPT1/PT2/PT3 Rev.151【TS】 † Red Devils Manchester United 1296 † † Red Devils Manchester United 1277 † † Red Devils Manchester United 1291 † 【パク王】NAOKIさんアンチスレ 55ヤキソバ【HG REVIVE】 【3波】 アースソフトPT1/PT2/PT3 Rev.152【TS】 【パク王】NAOKIアンチスレ 58ヤキャo【HG REVIVE】 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 178 【BFT】NAOKIアンチスレ 29ヤキソバ【HG REVIVE ©3ch.net 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 6 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 45 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 70 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 92 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 49 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 34 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 155 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 166 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 108 【SEGA】ソウルリバース ゼロ：SOUL REVERSE ZERO Part.130【ソルゼロ】 【L2R】リネージュ2 レボリューション / Lineage2 Revolution Part 120 【宝塚】雪組 梅芸『炎のボレロ/Music Revolution！』ライブ配信・実況 Part.2 【神運営】リネージュ2 レボリューション / Lineage2 Revolution Part 183 【糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 215 【L2R】リネージュ2 レボリューション / Lineage2 Revolution 質問スレ part9 【糞糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 233 【L2R】無課金専用リネージュ2 レボリューション / Lineage2 Revolution Part 11 【L2R】無課金専用リネージュ2 レボリューション / Lineage2 Revolution Part 20 【セブリバ】セブンス・リバース(セブンスリバース)【SEVENTH REBIRTH】part62 【セブリバ】セブンス・リバース(セブンスリバース)【SEVENTH REBIRTH】part63 タイトル：【究極糞運営】リネージュ2 レボリューション / Lineage2 Revolution Part 182【L2R 【#コンパス】ギルティギアXrdREV2 vs ストリートファイターV Round121【異種格闘技解析システム】 [無断転載禁止] [Turing]NVIDIA GeForce RTX20XX総合 Part78 [Turing]NVIDIA GeForce RTX20XX総合 Part92 [Turing]NVIDIA GeForce RTX20XX総合 Part58 [Turing]NVIDIA GeForce RTX20XX総合 Part100 [Turing]NVIDIA GeForce RTX20XX総合 Part121 [Turing]NVIDIA Geforce RTX20XX総合 Part2 [Turing]NVIDIA GeForce RTX20XX総合 Part40 [Turing]NVIDIA Geforce RTX20XX総合 Part19 [Turing]NVIDIA GeForce RTX20XX総合 Part49 [Turing]NVIDIA GeForce RTX20XX総合 Part53 [Turing]NVIDIA GeForce RTX20XX総合 Part38 [Turing]NVIDIA GeForce RTX20XX総合 Part60 [Turing]NVIDIA GeForce RTX20XX総合 Part43 [Turing]NVIDIA GeForce RTX20XX総合 Part111 [Turing]NVIDIA GeForce RTX20XX総合 Part112 Perfumeのっち、Core i9+GeForce RTX2080Tiのパソコンを購入 【悲報】AMD RadeonVIIさん、7nmなのに12nmのNVIDIA RTX2080に実ゲーム性能で負ける 麻枝准13年ぶりの完全新作ゲーム『Heaven Burns Red』2020年に配信決定。公式サイトではやなぎなぎによるテーマソングも公開 Nerf Rev-20 AG-DVX200 Part4
16:18:09 up 46 days, 17:21, 0 users, load average: 8.14, 9.18, 20.33
in 0.098417043685913 sec
@0.098417043685913@0b7 on 030106
