x264 rev43©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
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 文字目以降の引数が切り捨てられる。 https://support.microsoft.com/ja-jp/help/2823587 違法な無反応チューナーやB-CASの規約に違反するTS抜きに関するスレッドを皆で追い出しましょう。 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 その部分だけを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 --qpfile とか --cqmfile みたいに、 --zonesfile オプションがほしい いろいろ試してみたけどやっぱりディザが残らない そういえばpsy-rd使うとなんとかｑｐ-offsetがマイナスになった気がするからpsy-rdを0：0（効果を分かりやすくするため）でやってみたら？ マイナスになるのはchromaじゃなかったかな？ そもそも無理だからバンディング低減フィルタが生まれたのではないのか なんで糞忙しそうなmuken氏に聞こうとするんですかね・・・ >>58 >>34 >>60 >>r2345以降のx264でエンコさせると平均で6～8fps前後遅くなるし。 そもそもx264でエンコする人がいまだにWin7未満を使い続けてるとは到底考えられないんだが。 ライゼンってSSEが十倍の性能らしいからコア数とあいまってエンコはかどるかな？ 理由は不明 自動インストーラってAviUtlに必要なん？ >>75 Readmeを見て自分でファイルを集めてこれない人向けだから… 久々に来てみたがネ実のクズ共の荒らし行為って沈静化したん？ >>74 >73 コアあたりの性能は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 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 ちゃんとVBVを設定してHigh@4.1までならどのハードでも安心 >>123 >>124 >>126 --crf *を指定しなくてもエンコ出来たんですが--crf 23とサイズが同じでした >>127 RFFフラグを使ったソフトテレシネ素材をx264でエンコしたいのですが、 --pulldown 32のオプションがあった気もするがこれがソフトテレシネであるかは忘れた >>135 zoneはきっと使えないから--stitchableと--sps-idを使って分割エンコして最後に結合すればなんとかなるんじゃない？ なるほど・・・そこまでやるんだったらx264cliを改造したほうが簡単かもしれないですね。ソース読んでみます x264はMBAFFインタレだからインタレ保持にしてもPAFFインタレよりは符号化効率高いよな x264cli改造してRFFフラグをファイルから入力できるようにした https://github.com/nekopanda/x264/commit/6d734de56d0bb7e1dc5c660634c9a2f4fb3bd02d >>140 感激！そうかmuxでずれるのはタイムスタンプいれてやればいいのか。夜試してみるわ すごく内容に興味あるんだけど、うまくいったらこの--pdfile-inの書き方を教えてくれないかな？ muken氏語ってるね うぉぉーできたー！timelineeditorでタイムコード入れたらちゃんと再生できるようになった。 家電系は放送の変態ストリームに耐性があるけど、PC系は違うんだわな すまん、カクカクだったのは俺のタイムコード生成プログラムのバグだったわ >>147 まさにそういう状況だわ >>144 mpc-hcというかLAVはどうもインタレ、プログレ混在は苦手っぽい ffmpegだとフラッグのみbobすればよかったような 参照しているフレームの情報を利用したいんだけど、どうすればいいかな？ あれから出力されたストリーム詳しく見たりしてたけど、 >>144 https://github.com/nekopanda/Amatsukaze/blob/master/Amatsukaze/TranscodeManager.hpp#L1126 >>152 Ryzen 1700環境を手に入れたんだが、どんなに設定を弄ってもCPU使用率100％いかないんだが >>158 x264GUIはややスレチだけど、メニーコアなCPUだとCPUを完全に使い切れないことは多い Ryzen7ならL3キャッシュが4コアずつに分かれてるから >>158 x264に限らずフィルターもマルチコアに最適化されないとどうにもならないんだから まじか。今のx264だとまだ性能出しきれるほど最適化されてないのか。 最適化はもう限界に近いでしょ x264だけなら100%近く出せると思うけど実際にそれだけという人はいないから 5960X環境だけどUt_videoのavi食わせてるだけなのに100％なんていかないよ ベンチスレ見てても多コアなやつは100%までいってなかったような CPUが100%に張り付けばいいってもんじゃないと開発者が言ってたと思うよ。 マルチプロセスでスレッド数を減らすことを意識したほうがいい >>168 いままで8bitエンコしかして来なかったけどhighDepthオプションつけて10bitエンコにしようかと思うんだが なんで10bitエンコがいいのかぐぐればすぐわかること >>174 >>175-177 hevcかどっちか忘れたけど素のまま10bitエンコするだけでも onedriveにアドレス残ってた http://peace.2ch.net/test/read.cgi/avi/1418252184/ >>179 jpegをjpegで圧縮するような状態だったのを 主にアニメとかでバンディングを軽減するため10bitでエンコするんだよ 色深度の話は圧縮とは別で >>180 で展開されてるのはデコード時のディザの話で >>184 flash3kyuuDeband() >>188 >>189 >>184 >>186 ｒ2829 そうだったら面白そうだったのに違うのか。発売まであと1ヶ月ちょっと なんかAVX512にもいろいろなバージョンがあるらしい AVX-512に対応しても、256bitを2クロックで実行だったらあまり意味がなさそう >>205 >>174 >>211 そういう意味じゃなくて、MGVCのtsをx264でエンコするために12bitデコードできるPC用のプログラムが手に入るのかって話 ＞MGVCのサブストリームデータには特別な暗号化が施されており、これをデコードするためには、ハードウェア側にカギを仕込む必要がある。 まぁパナの一部の機種しかデコードできないようなオレオレコーデックに対応しても旨味がなさすぎるし無理だろう ここで聞くのがいいのか分からんけど、x264の8bitで俺的アニメ最適設定とか実写最適設定的なのを参考までに教えてくれる人いないですか... >>220 画質的に向上する余地なんてないんだから AVX-512関係ばっかりだし x265に乗り換えてからx264の最新ビルドに対する興味が薄くなった。 赤潰れやハイライト削りすぎは改善れれる余地はあるの？ 赤色が劣化してるように見えるのは色空間の問題が大きいからなぁ・・・ >>234 ダウンサンプリングのお話 --chroma-qp-offsetは効果がなかったですね サンプルの画像でも貼ってくれないと何のこと言ってるのか分からない 有名な話ではあるけど8bit ビデオコーデックの限界でなかろうか >>238 >>237 が言ってるように元画がYUV4:2:0の映像なら元画の時点で赤の劣化が起きてると思うのだが。 > ハイライト削ると、バンディングもどきが現れたり バンディングのディザによる解決は害悪だよね つくづく、地デジもBDも10bith264と思いきればよかったのにと思う。 BSで新しい衛星を立ち上げて地上波のサイマルをH264使ってやればいいのにな >>245 BSで4KをHEVCでやるんだから今更必要ないだろ 16 : 宇野壽倫の告発2017/07/11(火) 19:22:00.17 ID:5/TEkUSo http://ameblo.jp/jcjk-now/entry-12148228389.html ベンチマークスレに、環境情報を自動取得してx264/x265ベンチマークを行うバッチを http://egg.2ch.net/test/read.cgi/jisaku/1460032466/796-797 エンコの時にハイライトを捨ててるんだろう >>251 自分の世界しか見えてないから他人に説明できないんだよ。きっと ハイライトは最も明るく目立つ部分だから白付近をごっそりクリップしたんじゃないの > 白付近をごっそりクリップ 自演じゃあるまいし 目玉のおやじの白い部分をごっそりクリップするとグロ映像になるよな >>257 mp4boxで複数音声をmuxする場合、lang=jpnで指定してるんだけど、 違う言語で割り当てちゃえばいいよ もの凄いボケボケのブロックノイズ塗れになった crfmaxパラメータあたりで上限変えれんじゃね。ゴミ画質に劣化するだけだから誰も触れないけどw >>265 >>264 が言ってるように、--crfは51以上を指定しても51にされるだけだね。 rc-lookaheadを300にしてるとか言ってる奴も昔どっかで見たけど250に丸め込まれるよね クリッピングの意味で丸め込むってウチでも使うけど、そんなに変か？ 草はやされるほどおかしいとは思わないが >>277 >>277 さくっと試したら>>267 、>>279 の言う通りだった x264 sandboxによるとx264が大きく変わるようだ そういう動画はプレイヤーによっては再生できなくなるんじゃね。 スマホやゲーム機は10bit/12bitの動画とかHWデコーダが対応してないからSW再生しかできないんだよな H.265 Main 10に対応したハードウェアデコーダーは増えてきているけど、H.264 High 10に対応する物は一向に増えないな >>285 ピンク色をエンコードすると 低くても、か RGB -> YUVへの減食ミスとかじゃね 固定品質のQP0(可逆)でもそれがでるのかどうかを確認しよう http://www.rupan.net/uploader/download/1501125272.zip >>290 やな ログを見るとYUY2 -> nv12pになってる UVダウンサンプリングフィルタをやってみたところ、 Aviutlって普通にエンコしても黄色っぽくなるんじゃないの >>295 読んでると色変換設定ミスの可能性高いな >>295 >>299 http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3437.png >>292 のencoded.bmpが変に明るくなってるのが気になった。 >>296 自分は分ってる風だけのスレなんて無駄じゃないか 何もフィルターかけてないのに色が変わるんだったら可逆圧縮なんて成り立たないでしょうに ゲームのエンコの時は「拡張色調補正」の「TV -> PC スケール補正」をONにする必要があったと記憶している PCスケール補正ONとかそんな地雷情報誰が流布しているんだろうな >>292 のencoded.bmpみたいに明るさや色が変わる そもそもORIG.bmpが正しいやり方でキャプったのかっていう問題がある >>300 >>304 うーん、h264はYUV420でエンコードするのが殆どだから>>292 みたいな元画との差異の追求の話をするには >>308 >>300 で書いたような色変換時に必然的に起こる変化のことを勘違いしてるといったところでは。 >>309 >>310 >>311 >>310 に書いた内容。 こういう切りない無駄な言い争いになるから辞めろって言ったんだ 何にせよもう終わった話だし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 ps3の限界を探ってみた結果、2つのストリームのlevelが同じなら >>334 >>336 CPU能力有り余っててsubme=11を常用してたけど、10に変更したら主観的に画質レートエンコ速度が良くなった 俺も意味不明 限界まで圧縮高めればノイズも出易い submeを「限界まで圧縮高める」ものだと思ってるのか >>344 どうやらsubme上げると圧縮高まってノイズが出やすいらしい けど実際にガッツリ削れてブロックノイズが出たた気がする submeなんて「ソースによる」としか・・・。 自分の目にはsubmeは9が一番画質いいように見える >>349 昨日久々にaviutl一から環境作り直したけど keyintのデフォ値はなんであんなキチガイみたいな値なんだろうな ゴミCPU使ってなきゃGOP300でも気にならんがなぁ >>356 シークの重さなんて、設定とか環境とか使ってる再生ソフト次第でもあるし、それらを明示しないとなあ。 keyintはBDだと1秒分のフレーム数だし、私もそれに合わせている そうだね。以前はOpenGOPがMP4で定義されていなかったりしたけど、今は特にデメリットを思いつかない 動画配信とかの用途ではopengopを使うと不具合が起きるみたいだね BDだと最大キーフレームは最大2秒でしょ keyintは最大GOPサイズの指定であって、それ以下でも必要と判断したら勝手にIフレームにするから >>367 単に最大間隔を広げるだけだと思ってる奴が多いが というかその必要な部分の判別はどうやってやるの？ > それとも思い込み？ x264 [info]: frame I:31 Avg QP:31.14 size: 50769 >>372 x264ってタイムコード入力できるからfpsって必要ないんじゃないの？ >>373 >>375 >>370 >>369 は説明していたのだと思う。 そのIDRフレームってのは、H.264はIフレームでも前後フレームと関連つけてあるから、関連性をリセットするIフレームってことでしょ？ OpenGOPだとIDRフレームは生成されないよ IDRフレームでしかシークできないわけではないし、OpenGOPは「GOPが無い」わけではないからね。 BDMV互換重視してるから >>383 youtubeのことかと思ったらyou達（たち）だったのね 何年も前から使えるなら移行する気満々で環境だけは整えてるけど できるならH265にしてるだろうけど、エンコードも再生もそこそこ性能が必要だから現状厳しい 一番の問題はx265の完成度が低すぎる所 H.265が「H.264の2倍の圧縮率」てのを発表したのはSSIMではなくてPSNRでの評価。 >>390 馬鹿でも出来るという言葉があるが馬鹿の程度にもよるしな x264vfwの最新版が7月で64bit版は15年で止まってるんですが >>396 あ、そうなんだ㌧クス 翻訳サイトで読んだけどちょっとよく分かりませんでした >>392 >>392 規格とエンコーダの違いがわかってなくて規格(机上の空論)だけで比較した気になってる人でしょう 1passVBRのcrf指定でエンコする場合、presetはどれに設定しても >>403 >>403 ありがとう。MicroSDも随分大容量になった昨今、エコ的には容量に ハズレ石の6700Kで夏場は水冷でも熱暴走しまくって、OCを4400MHzに抑えてたが、 電源をずしんと重いやつに変えれば夏でも安定すんじゃね？ >>408 ライゼンはええわ 流石にその比較で2倍違うのはおかしい こんな人間いるのかな？って突如疑問に思ったんで質問してみる BDのH.264ってとりあえず最高ビットレートで入れとけって感じだから、再エンコでも結構縮む >>424 720p付近で作ってるアニメなら容赦なく720pにしちゃう >>423 一度HDDにエンコして入れとけば見たい時にサクッと見られるからな BDを再エンコするのはノートPCでいつでも気軽に見られる様に入れておきたいって用途しか無いなあ 何でエンコするかは各自の自由な。 x264はaviutlでサクッと編集して4:4:4 Predictive+10bit+crf16ぐらいで妥協してたな。 俺はアニメなんてエンコしなくてもエンコ職人がP2Pで流してるからそれ拾うわ 地デジソースとかエンコ職人がアップしたやつを見たこと有るけど テロ入っちまった時点でゴミだからそんなもんに手間かけても仕方ないがな いや、テロといっても横スクロールのやつな。地デジでは恒例だろ。 補間フレーム生成したりVFRにしたりとかしてまでテロなんぞを滑らかに動かさなくてもいいよ >>438 何度も見る事やないんやけんある程度見れてたらそれでええわ 横にテロが動くときに妙にぎこちなかったり、カックンカックンしたりするとアニメ本編に集中できずにイラつくだろ？ どこの局のソースかが大事だからな >>444 x265でアニメエンコしてたけど 定期的に現れるけど、単に8bitでエンコしてるだけでは？ 仮にそうだとしても、ソースも8ビットなわけで、 「その条件」ならそうかもしれんが、>>447 はその条件にこだわってないだろ 暗部といったら aq-mode 3 だろ >>451 >>447 の対策（バンディングと暗部のディテールは違うと思うが）がx265ではなくx264を使うということだったのでは？ ソースが10ビットなら知らんが、 暗部保護ならaq-mode 3とno-mbtree両方設定しとくべき？ 入力が 8bit でも Avisynth やらでフィルター噛ませば出力 10bit でも多少効果でるもんじゃないん? aviutlでノイズフィルタ使ってるなら色深度変わってくるから10bitがいいんでないの？ デバンドは意味あると思うが10bit化は無駄多すぎ ソースを加工するならたしかにまあ 8ビット高ビットレートでバンディング低減されてるソース（放送もブルーレイもそう）を まぁ、あまりいいディスプレイじゃなければ分からないかもしれないけど、 ブルレイ互換でエンコが基本の自分としては10bitはそもそも選択肢に入らないけどなぁ 447だが 8bitソース素通しでも10bitでエンコードする理由はあるよ バンディングだけは目に見えて効果あるよな10bit化 >>465 >>466 >>469 1/5程度のレートなら余裕余裕 アニメのBDはマーケティングの都合で1枚に2話とかしか入ってなくてレート減らすインセンティブ皆無だからな crfが適切で、aq-mode 3 使って、デバンドかけてれば ソース https://i.imgur.com/GWNr9Ru.png https://i.imgur.com/ezLaNm5.png https://i.imgur.com/SjCSAiu.png https://i.imgur.com/ofiKhB3.png https://i.imgur.com/Z3tRpYN.png おれ環では aq-strength を調整すれば 8bit + デバンド でいいや・・・ デバンドするしないでも選択肢変わるだろうし なんでアニオタばかりなの？ デノイズはNL-Means使ってる 実写メインの人ってHDD録画かBD-Rにムーブして終わりじゃね >>474 https://i.imgur.com/GWNr9Ru.png https://i.imgur.com/ezLaNm5.png >>460 で言ったとおり んでもって、x264は >>466 のような話は散々出てくるし、 10bitで書き出すならデバンド要らなくない？ >>481 まだx265が開発途上なだけでしょ >>482 >>474 ） >>474 ） >>483 >>485 >>486 >>487 crf 20 出来上がりのファイルサイズめっちゃデカくなりそうだけど アニメならそうでもない ソースを忠実に再現って言うと聞こえはいいかもしれないけど、 >>474 ） 8bitきったねぇわろたｗｗｗｗｗｗｗ >>480 >>495 >>494 >>493 話がややこしくなってきたので改めて整理すると >>466 >>474 にはデバンド無し10bitの結果が無いのでその比較にはなっていない >>494 のようなめくらには副作用があるって言っても 地デジはともかくブルーレイだと>>474 のデバンドあり圧縮前のような これが>>474 デバンドあり圧縮前をcrf0で8bit化したavc（の静止画） https://dotup.org/uploda/dotup.org1367941.png https://i.imgur.com/HkBnse4.png https://i.imgur.com/1QptJMb.png >>500 https://i.imgur.com/JWaCj0O.png https://i.imgur.com/ISi0Xnv.png https://i.imgur.com/OBQeZKO.png https://i.imgur.com/dloXldb.png 素通しで8bitソースを10bitにエンコするときにバンディング減ったように見えるのはdeblockが効いてるからだと予想 別に絵画の精細度なんてどうでも良いんだがｗｗｗ ＿人人人人人人人人人＿ >>498 >>499 >>502 を見るとどう考えても10bit＞8bitじゃんｗ 静止画だから分かりづらいけど うーん、8ビット素材でバンディングの出ていないものを同じ8ビットで圧縮してバンディングが出るんで >>513 >>502 >>474 >>474 https://i.imgur.com/SjCSAiu.png >>502 https://i.imgur.com/HkBnse4.png 黒ストッキングとか黒髪とかの微妙な風合いを見たいのに、 よく見えんところをはしょってごまかすのが圧縮の本質だからなあ >>517 >>515 バンディングで突っ込めなくなって今度は色がどうの騒いでんのかよｗｗ 別に検証画像がインチキだと言ってるわけじゃ無いのでお前がやれは些か的外れだよ >>519 >>520 >>514 https://i.imgur.com/fA43LEJ.png >>514 やってみた。 それについては、ブロックノイズが出まくる領域だとたしかに内部計算的には周辺の平均をとって、 実験結果 https://i.imgur.com/UCaT1tA.png https://i.imgur.com/ezvIeKW.png https://i.imgur.com/gil6CHK.png https://i.imgur.com/6oLeO8V.jpg https://i.imgur.com/mfzemcd.png https://i.imgur.com/B6IT06k.png https://i.imgur.com/BCUfJB5.png https://i.imgur.com/IKlVQcS.png なるべく途中で変な処理が入らない用意全部コマンドラインでエンコードした https://pastebin.com/b5fBXuRy imgur使うとある程度のサイズ超えるとjpgになってしまう ちなみに色に関しては解像度で自動的に認識してくれるかなーと思ったのと、 >>530 >>527 >>502 見てもだいたい12増えてデータ量は同じくらいになってるでしょ >>533 >>531 >>532 >>535 https://forum.videohelp.com/threads/380991-ffmpeg-x264-RGB-to-YUV >>534 ディザでバンディングを軽減した8bitソース(source2 10秒) https://light.dotup.org/uploda/light.dotup.org487838.png https://i.imgur.com/fA43LEJ.png https://light.dotup.org/uploda/light.dotup.org487835.png https://dotup.org/uploda/dotup.org1368691.png https://light.dotup.org/uploda/light.dotup.org487836.png https://light.dotup.org/uploda/light.dotup.org487837.png >>539 >>474 にあるようにディザは消えちゃうんだよ >>537 >>541 >>542 >>539 のcrf35ほどの低レートではなくて、 >>539 のcrf20や>>523 のようにディザが残るほどの高レートでもない >>543 >>523 は20Mbps指定でエンコしたけど、これCRF12でエンコしても13Mbpsくらいになるから さらに言うと、データ量減らすためにエンコしてるんだから、 うーん、なんかだいぶcrfに対する感覚が違うなぁ >>547 >>512 にあるように「うにょんうにょん」になる BDだとこの「うにょんうにょん」が出ないんだろうね >>548 そのうにょんうにょんってのが何なのか分からんのだが、 >>551 >>552 ちなみに60i→60p変換はavisynthとQTGMCという激重だけど品質は最高峰の方法でやってる。 あるいは60iのMPEG2になる時点で不可避な60Hz/30Hzで付加されるアーティファクトを >>553 https://i.imgur.com/bhoxmSQ.png >>503 普段からタブレットやスマホでx264でエンコした動画を再生しているのだが >>560 >>556 >>559 >>558 >>474 はしきい値が高すぎてかなり強く掛かってるから副作用出まくり >>560 >>544 >>567 >>556 >>568 >>568 で、x2648bitだけでデバンドはどうすりゃいいの？ >>569 >>556 はQTGMCの後に補間するから原理はちょっと違う >>570 >>571 >>573 >>574 >>571 >>575 >>571 の１または２がほとんどであり、３(デコーダでRGB化)にしてる人はほぼいないだろう。 >>576 >>568 にも書いたけど、別にそういう再生環境にしなくても、10bitは効果があるって言ってる >>577 >>578 あと デバンド10bitがファイナルアンサーってことでおｋ？ >>582 >>579-580 >>579-580 >>574 の後半は少し間違ってたかも。 バンディング低減かまして 10bit エンコした奴でも BlueskyFRC 通すと内部で一旦 8bit におとされるのなｗ 最小限、VLCでまともに見れれば問題ないんじゃね？っていう。 >>585 >>474 の「デバンドあり 10bit --input-depth 16 --crf 20 --aq-mode 3 --tff」を https://i.imgur.com/FDzP7Hu.png >>474 はAviUtlで読み込んでキャプチャしたから、 MPC-BEのEVR-CP試してみたけど、インタレ動画再生すると >>590 これが汚い原因分かった >>589-592 https://pastebin.com/PjXMXesZ https://www.axfc.net/u/3856752.zip >>593 >>593 >>595 >>595 >>597 エンコ前のソースではなく、デコーダに渡される10bitでエンコされたものをソースと言ってるように読める >>599 >>600 >>597 の書き方は誤解を生んでしまうかも。 >>601 >>601 >>594 で同じって言ったけどあれはウソだった。よく見たらちょっと違ってた https://i.imgur.com/JUXbiHR.png >>593 とちょっと色の出方が違うけど、バンディングは同じようにも見える https://i.imgur.com/kL0gCho.png >>593 のmadVR-P010-ditherONと同じような表示になった https://i.imgur.com/BqmypsW.png >>593 のmadVR-NV12-ditherONと同じような表示になった Intelグラはディザリングしないんだね UltraHD Blu-rayがIntelのiGPUでしか再生できないのに、何故糞と言えるのか >>603 比較するなら何故接続方法とディスプレイを同じにしないのかなぁ >>603 >>603 >>593 （うちのIntel環境の結果）と比べると以下のように全然違って見えるけど・・・。 >>603 >>604-605 >>610 まあ根本的な話として、GPU補正の影響を避けられないEVRを使うより、 スケーラー的には >>611 >>613 >>614 >>615-616 >>611 に書いた通り、そちらの環境のEVR-CPのP010処理が何か変みたいだから、 >>617 >>593 の画像 https://i.imgur.com/xPCZlun.jpg >>603 の画像 https://i.imgur.com/A5KuEHh.jpg 一応、俺の感想を言うと >>593 の画像(Intel GPU)は、ディザリングされてないから境界のはっきりした細かいバンディングが出てる >>603 の画像(Pascal)は、ディザリングされてるから境界ははっきりしてないけど、バンディングもどきは出てる >>617 >>618-619 >>620 >>621 サンプルは>>516 が黒髪ないし黒ストッキングの画像用意してくれるそうだから、それで比較しようよw バンディング低減フィルターって、ソースに入ってるバンディングにも効くように設定すべきなのかな？ >>623 >>626 >>626 MediaInfoで表示されるエンコード日やタグ付け日ってどうすれば変更できますか？ no-info パラメータって x264 にはないんだっけ？ >>630 エンコード日とかって >>632 が言う通り、エンコード日やタグ付け日はコンテナに入れる時にMuxerが記録してるものだから わざわざヘッダーいじくるのって、やっぱり違法P2Pに流すためなんだろうな 違法流しだとしてもエンコード日付の変更になんの意味があるんだろう。 ファイルの並び順を作成日時でソートしているのですが >>635 あとはme dia にしてるのをバレたくないとかw >>639 >>640-641 >>629 が聞いてるのは日付の変更方法であって、設定オプションは関係ないと思うぞ。 >>642 >>641 x264vfwでリアルタイムエンコする場合、7920xと7900xのどっちがいいだすか? >>645 オーバークロックはしない前提で スレッドは20Cだろうが128Cだろうが使うが使用率100%は使えないってだけ threadsを最大にしても、殆ど全部使い切らないx264で 4～8コアでいいから高クロック動作させるのが速さの秘訣と誰かが言ってた 良いプラグインを選んだり自分で最適化ビルドして x264のソースで、 CPU遊んでるのはメモリの帯域がボトルネックだったりするんかね メモリのアクセス待ちのレベルまでOSが関知してないからタスクマネージャーとかで見るCPU使用率には現れない x264に入るまでの前段のデコード、フィルタ、色空間変換のいずれかがマルチスレッドに対応してないからだろ >>648 >>661 x264(32bit版) gitのソースをちょいイジったバイナリ欲しい人いる？ 最新ビルドでAMD向けのSSEMisalignに対応するビルドが欲しいわ x264をvtuneで解析する方法 下手に触ったら、弄りすぎて壊れた… Intel C compilerで作った x264@0.152.2851 https://dotup.org/uploda/dotup.org1391216.zip.html >>667 俺のjane styleではちゃんと表示できてるぞ 今、ブラウザでアクセスしたけどリンク切れだったよ 結局janeのビューアが改善すればいいだけの話か。 r2345 >>673 自ビルドすればいい >>673 基本、ダウンローダかFirefoxでDLするように。くれぐれもIEやChromeやEdgeでDLするなよ r2345にこだわる理由はおそらくこれじゃないか。 ブラウザやメール、ビジネスアプリくらいしかやらない人にとってはPhenom系のCPUで全然問題ないから >>677 >>679 氏の指摘です たしかそれ以降にもAMD向けのはガッツリ削られたんだっけ？＞XOPとか >>680 余談だが、ブル世代の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が来てた。 https://github.com/jpsdr/x264/releases >>705-707 >>708 >>709 個人的に分割してくれたほうがいい気がする(1つに集約＝その分重くなる？) うちでr2851kModとr2893(rigaya版)を一発比較した限りじゃ特に変わらんようだけど。 ■10bit 普通に考えて8bitか10bitか毎フレーム判断するわけないわな 60000/1001で同じようにエンコしてどのぐらい出るか知りたい。 crf20でそんなに縮むのはアニメだからだな >>717 何がだよ。SAOの映画とか60fpsでエンコしてみろ、動きがヌルヌル過ぎてすげー気持ちいいから 映像自体が60のアニメもまったく無いわけではないがごく一部だけだな 特にエンディングのスタッフロールとかは60fpsでエンコすると >>717 >>722 >>718 >>712-713 のtest-1080p.mkvは、x264/x265ベンチマークスレで使ってる実写映画の予告動画だよ。 >>722 一時期あった30/24混合のアニメは面倒だからインタレ保持でやってる むしろ動いてないところは削りまくってタイムコードで引き伸ばしてるわ 60iを60pにしたというオチじゃないよな 昔からドラマのOPをヌルヌル綺麗にエンコしたいとか散々見たような >>729 フレーム補間の60fps化だろ >>733 俺のブラビアで再生すれば240fpsで超ヌルヌルだぜ エンコ日が動画埋め込まれるのを消したり変更したりはできないの？ すまぬ、訂正 >>741-742 >>731 エンコ日やmux日を偽装や隠蔽して一体なにがしたいのやら。 違法アップロードのエンコでこんなに低いcrfなのに低ビットレートってスゲー、って思われたいんだろ 旧作アニメのエンコをして、当時の放送日時に合わせて日付を設定しちゃおう！っていうのなら エンコ日時フィールドにエンコ日時以外を入れたいとは思わないな 俺のエンコは、mkvでmuxするときにTSから拝借したEIT情報を埋め込むぐらいだな。 エンコ日を偽装したいとは思わんが、 https://i.imgur.com/eQTcsUg.png 気がついたら同じような動画を何回も拾ってる >>753 >>753 >>753 x264guiExで実写を品質基準VBR (crf)でエンコしてるのですが ソースによって変わるからソースにあわせてcrf値を調整するしかない。 内容的に --tune ssim は関係ないやろ。 >>760 ちなみに、その0.985っていう値はどこから出てきたの？ SSIMの表示には --ssim が必要だけど、>>764 が言いたいのは値の取得方法ではなく psy入れてたらSSIMも糞もないだろうな 地デジ、実写、爆発シーンがあるアクション映画がソースで crfで綺麗にエンコできる設定だからって crfこそがきれいにエンコオードできる設定だからね >>770 上限じゃなく平均レートに6~10Mbpsを指定する必要がある ノイズかどうかって人間の目ならだいたいわかるんだから googleがビッグデータを使ってディテールを予測して補完するエンコーダーの研究してるよな 771からの話だとして、なぜ平均レート6～10Mbpsと言い出したのかよくわからんのだが・・・ crfやめて2passで高画質を狙うなら crfとか2passとか設定出さずに爆破シーンのエンコとか >>781 >>782 >>783 マルチパスは画質を捨てて、エンコ後のデータ量を揃えたい人限定じゃね？ crf使ってるのに何度もエンコしてファイルサイズ揃えようとする馬鹿も笑えるよな psy入れてるのに毎回ログでSSIM解析値残してる俺 >>786 ロスレスは劣化が無いと信じて使ってたけど RGBソースをYUV4:2:0の可逆で保存してたってことかな。 ■ このスレッドは過去ログ倉庫に格納されています
