サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
rigaya34589.blog.fc2.com
2024.03 << 123456789101112131415161718192021222324252627282930 >> 2024.05 これまでの記事 Ryzen9 5950Xの準備編 Ryzen9 5950Xで自作PC (組み立て) Ryzen9 5950Xのメモリ設定 Ryzen9 5950XでのPBOとCOの効果 Ryzen9 5950Xでベンチマーク Ryzen9 5950Xのメモリ・キャッシュ帯域 Ryzenシリーズには、熱などの環境の許す限り自動でオーバークロックしてパフォーマンスを引き上げるPBO(Precision Boost Overdrive)が搭載されている。 一方、今回の5000番台では従来のPBOに加えてCO(Curve Optimization)という新機能を追加したPBO2にバージョンアップされている。 そこで、5950XでPBO2の設定を行って性
エンコーダ x264 r3085 x265 3.5+13 svt-av1 0.9.0+14 QSVEncC 6.08 NVEncC 5.43 入力動画 sakura_op.mpg MPEG1 1280x720 30fps 3501frame AvisynthのLWLibavVideoSourceで読み込み (SWデコード) 使用コマンド x264 medium --crf <x> x264 veryslow --crf <x> --preset veryslow x265 medium --crf <x> x265 veryslow --crf <x> --preset veryslow x265 medium 10bit --crf <x> --input-depth 10 --output-depth 10 x265 veryslow 10bit --crf <x> --input-d
Windows11のバージョンはこんな感じ。 キャッシュ・メモリのレイテンシ まずはレイテンシから。最初はキャッシュの構造の見やすい少し規則性のあるアクセスパターンから。 5950Xは一つのコアから見えるL3キャッシュは32MBなので、Windows10ではそのぐらいまでレイテンシが低い状態が続き、まあこれが想定される状態なのだけど、Windows11では2MB(2048KB)ぐらいから急激にレイテンシが上昇し、メモリアクセスと変わらない感じになってしまっている。 完全ランダムアクセスの場合も同様で、Windows11では2MB(2048KB)以降でキャッシュが見えなくなっているみたい。 キャッシュ・メモリ帯域 今度はシングルスレッドの帯域。 Windows10では32MBまでL3キャッシュによると思われる高い帯域が持続するが、Windows11では2MB(2048KB)以降メモリアクセス
使用ソフト x264 r2988 x64 x265 3.3+2 x64 NVEncC 4.68 x64 QSVEncC 3.33 x64 VCEEncC 5.04 x64 入力 sample_movie_1080p.mpg MPEG2 1920x1080 29.97fps 5203frame 使用コマンド QSVEnc/NVEncについては、おそらく画質が一番高くなるであろうオプションを試した。x264/x265はきりがないのでpresetをそのまま使用している。 なお、x264/x265では、今回入れてない--tune ssimを入れてssimに最適化したエンコをすることでさらにssim的には改善の余地があることに注意。 x264 medium --crf <x> x264 veryslow --crf <x> --preset veryslow x265 medium --crf <x
使用ソフト x264 r2901 x64 x265 2.8+74 x64 NVEncC 4.22 x64 QSVEncC 3.11 x64 入力 sample_movie_1080p.mpg MPEG2 1920x1080 29.97fps 5203frame 使用コマンド なお、x264/x265では、今回入れてない--tune ssimを入れてssimに最適化したエンコをすることでさらにssim的には改善の余地があることに注意。 x264 medium --crf <x> x264 veryslow --crf <x> --preset veryslow x265 medium --crf <x> x265 veryslow --crf <x> --preset veryslow x265 medium 10bit --crf <x> --input-depth 10 --output
使用ソフト x264 r2901 x64 x265 2.8+74 x64 NVEncC 4.22 x64 QSVEncC 3.11 x64 入力 サクラノ詩 OP sakura_op.mpg 1280x720 30fps 3501frame 使用コマンド なお、x264/x265では、今回入れてない--tune ssimを入れてssimに最適化したエンコをすることでさらにssim的には改善の余地があることに注意。 今回、同じ結果を使って画像で比較するので、ssim最適化は行わなかった。 x264 medium --crf <x> x264 veryslow --crf <x> --preset veryslow x265 medium --crf <x> x265 veryslow --crf <x> --preset veryslow x265 medium 10bit --crf <x
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 どんなメディアにもたいてい寿命がある。 寿命が短いというと、フロッピーとかSDカードとかで、調べるとだいたい5年～10年とかと書いてあって、やっぱり結構短めだ。というかSDカード等のフラッシュ系って2～3年しか保たない印象あるが…、まあそれはいいか…。 こうした中、比較的寿命が長いとされているDVDをはじめとする光ディスク系だと、5年だったり、数十年だったり、なんかいろんなことが書いてある。 まあたしかに、メディアの品質、書き込み方法、保管状態等、条件が変われば大きく変わってしまうということになるんだろうけど、結局どんなもんなのかよくわからない。 で、じゃあ、自分の持ち物ではどうだったのか、という話。 500枚の古いDVDを読み込んでデータ
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 GPUのファンがイカれてきてしまい、大変もったいないのでなんとかしようと簡易水冷化をやってみたら、意外と簡単…と思ったらちょっとトラップにはまってしまった…。 問題のGPUはZOTAC GeForce GTX 1080 AMP Editionというやつ。まあWebサイトにはめっちゃ冷えるみたいなことが書いてあるのでハズレを引いただけかもだが、とにかく買った当初からあんまり冷えず、あっという間に80℃をこえ、90℃が近づいてきて、すぐクロックが落ちてきてしまう子だった。 最近特にひどいな、と思いつつもまあ夏だしそんなもんかと放置していたら、PCからジジジジジジ…みたいな音がし始め、見てみるとこのGPUの片方のファンが原因、とわかった。 どうも
結構、実行するたびに値がブレることがあるので注意。2回ほどやって速い方の値だが、まだバックグラウンドのタスクなどで遅くなってしまっているのがあるかもしれない。 まずは、XSの結果から。 ・5960X@3.6GHz,2chと5960X@3.6GHz,4chがほぼおなじで、このサイズだとキャッシュが効いてほとんどメモリは関係ない模様。 ・8コア使い切ったときはR7 1700@3.6GHzのほうが、5960X@3.6GHzより高速で、これはx264とかでも同じ。Ryzenの演算力の高さが表れている。さすがに5960X@4.2GHzには勝てない。 ・5960XでもR7 1700でも、P2 > L4, P4 > L8などとなっていて、この場合にはSMTを切ったほうがいいらしい。これは同じコアにスレッドが入ることで、L1/L2キャッシュで競合がおき、遅くなってしまっていると思われる。 次にLサイズの結
※R7 1700のみ、Windowsの電源プランは高パフォーマンス。 結局、長時間のエンコードで安定させようと思うと、うちのR7 1700では1.225V程度必要、ということがわかった。当たりとは言いにくいのかな…。 まずはRyzenお得意のCinebench R15から。 R7 1700@3.6Ghzを同クロックの5960X@3.6Ghzと比べると、single threadでほぼ同じ、multi threadでは大きく勝ち越していて、Ryzenの優秀さがよくわかる。4.8GHzの7700Kはsingle threadでは圧倒的だが、multi threadでは所詮は4コアのため、大敗。 適当に書いた自作プログラムによるメモリ速度測定。 →正しく測定できていなかったので、測定しなおしました。 さて、本題のx264。 環境は Aviutl 1.00 x264guiEx 2.50 x264
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 8/18から、ニコ動で投稿可能なファイルサイズが緩和されたのだが、この仕様がいろいろ残念。 再エンコ回避ができるのかどうかについては、100MB以下ならOKという話と、100MB以下でも問答無用で再エンコされるという話があって、よくわからないことになっている。まあそもそもは公式にこういう情報を出さないからいけないのだが…。 やっとのことですこし情報が出たけど、必ずサーバー側で再エンコがかかるとのこと。 再エンコされると強制的に1280x720にリサイズし、それを2000kbpsでエンコードするらしい(これが上限で、それ以下の画質も用意されるらしいがそんなもんに興味はない)。なんというか、720pで2000kbpsって足りないんじゃないの、と
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 Intlドライバの3220が出てる、とのコメントを頂きありがとうございました。 ためしてみるとAPI v1.7として認識され、無事Lookaheaadモードが動作した。 このLookaheadモードを細かく調べてみる…というのが内容。割といいかも? QSVの問題点 1. 画質が悪い。 2. 特にビットレート指定モードの画質が悪い。 動きが激しかったり、場面の切り替わりだったり、フェードイン・アウトだったりするような容量を喰う場面で十分なビットレートを割り当られず、そうした場面で映像が破綻する。 3. CQP・VQPはそうした心配は無いものの、それでも画質が不安定。圧縮率がそもそも低いうえに、グラデーションのようなところを端折りがちで、ブロッ
ビットレートはだいたい1800kbpsにそろえた。速度は参考までに。x264/x265は2pass目の速度。NVEnc HEVC CQPはなんか速度が遅すぎる気がする…。 769フレーム目 (1からカウント) オリジナル 髪の輪郭とか、背景の空とかをみるとよくわかる。よくわからない場合は、クリックして別タブで開き、切り替えて比較してみるとよいかもしれません。 オリジナル QSV H.264 CQP PG 1749.19 kbps ざらつきが気になる。 QSV H.264 ICQ 1782.23 kbps CQPより少しよいが、それでもざらつきが… QSV H.264 LA-ICQ 1838.55 kbps かなりすっきりしてきている感じ。 QSV HEVC CQP 1802.41 kbps H.264のCQPよりさらに悪い気が。 QSV HEVC ICQ 1725.3 kbps なんかHE
Intel内蔵GPU以外にGPUが搭載されているPCについて Win7ではiGPUからデスクトップが出力されていること Win8以降も、iGPUからの画像出力を推奨 使用準備 Windowsでの使用 QSVEnc_x.xx.zipをダウンロードしたら、中のQSVEncCフォルダの中身を解凍して好きな場所に移動して使用してください。 avs読み込みが行いたい場合にはAvisynthを、vpy読み込みを行いたい場合にはVapourSynthをインストールしてください。インストールしたものがｘ86版(32bit版)ならQSVEncCもx86フォルダにあるものを、x64版をインストールした場合にはQSVEncCもx64フォルダにあるものをご利用ください。 Linuxでの使用 Intel Media Severをインストール後、QSVEnc_x.xx.zip内のQSVEnc_src.7z内のソースコ
2024.05 << 123456789101112131415161718192021222324252627282930 >> 2024.07 この前x264guiEx 2.00を公開した。基本的には簡易インストーラでインストールしてくれればと思うけど、手動でやりたい、あるいは簡易インストーラがうまく動かない場合に、手動でx264guiEx 2.xxを導入する方法も一応書いておく。1.xxとは違ってL-SMASH使用で説明。 簡易インストーラを使った簡単な使用方法は x264guiEx 1.xx/2.xxの導入 (簡易インストーラ) に。こちらも合わせて更新しておいた。 あと、Aviutlの内部形式とx264guiExの色変換について書いたpdfにLW48モードについて追記したので、LW48について知りたい方は読んでいただければと。 その他関連記事 x264guiEx 1.xx につい
2024.05 << 123456789101112131415161718192021222324252627282930 >> 2024.07 最近のCatalystの更新で、面白そうなものにFluid Motion(流体モーション)というのがあった。 4.gamers - その名は「Catalyst Omega」。AMD，Catalystの大規模アップデートを発表 大雑把に言うと、かくかくしがちな24p再生をいい感じに60pに変換してぬるぬる表示させてくれるものらしい。これまでは自由に使えなかったらしいのだけど、今回のドライバアップデートでDXVA向けに解禁されたようだ。これを受けて、さっそくDXVA用のフィルタを作ってくださった方がいらっしゃるようなので、ありがたく使わせていただいた。 mpc-hcと組み合わせて使ってみるとちゃんと動作し、結構ぬるぬる～。 使用中のGPU負荷は、ず
※ただし、i7 4610Yはタブレットに搭載されているものであり、TDP=6～7.5Wの制限がかかっていて、2.9GHzで動作することは少ない。 メモリ速度 ここで作ったプログラムで測定。 スレッドごとのメモリ速度 DDR3-1600の2chなので、理論帯域は25.6GB/sなのだけど、なんかえらい遅い気が…。同じメモリ構成のi7 4610Yとかなり大きな差がある。3スレッド目で速度が伸びるのは、Silvermontは2コアを1モジュールとする構成なので、2モジュール目を使い出すのが3スレッド目からだからかもしれない。1モジュールだけだと5GB/s弱が限界なのだろうか。 こうしてみるとやはり徹底して省電力向けのCPUであり、本来メモリはDual channelでなくてもいいのかな、という気がする。 キャッシュ・メモリ速度 N3150は24K x 4 = 96KまでがL1キャッシュ、2MBま
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 NVEncでHEVCに対応したので、 ・NVEnc (H.264/AVC) ・NVEnc (H.265/HEVC) ・x264 ・x265 8bit ・x265 10bit で容量をそろえて画質比較してみる。 検証環境 環境1 (NVEnc) Win8.1 x64 Intel Core i7 5960X @ (Core:4.4GHz, Uncore:3.8GHz) ASUS X99 Deluxe GeForce GTX 970 DDR4-2666, 16GB RAM, 15-15-15-36-1 NVIDIA グラフィックドライバ 347.25 環境2 (x264, x265, QSVEnc) Win8.1 x64 Intel Core i
リモートデスクトップをしたり、ネットワークドライブの録画データをAviutlでシークしたり、単なるファイルコピーではなく細かいファイルを大量にコピーしたりすると、ネットワークのレイテンシが邪魔して、だいぶもっさりする。 レイテンシに関しては、無線は論外なのだけど、有線であっても、ハブを経由しているとやはりレイテンシはだいぶ増える。なので、これを解消するには2台のマシンを直結してやれば良い。 さいわいにして、メインマシンのマザーボード X99 Deluxeにはネットワークアダプタが2つある。あとは、LANカードをネットワークドライブのあるPCに追加して、LANケーブルで直結し、適当にIPアドレスをふっておけば、最短経路を使ってアクセスしてくれるようになる。 2. SMB Multichannelでスループットの向上 Gigabit LANの帯域はその名の通り1Gbpsで、理論帯域は125MB
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 動画関連のリンク集。特にAviutl関係。 2014.5.21 もう少し追加 2014.5.22 さらに昔お世話になったものなどを増強 2014.8.27 解析系ツール (真空波動研・mp3infp) / NL-Means DX11追加 2015.1.31 L-SMASH Worksにリンク追加、Avisynth/VapourSynth追加、その他フィルタをいくつか追加 2015.2.11 L-SMASH、およびL-SMASH Worksのビルド方法 更新、音声エンコーダを幾つか追加、ほか 2015.3.08 透過性ロゴ(改)を追加。 2015.9.23 x265のリンクを追加。 2015.12.28 いろいろ追加。 2016.12.01
2024.06 << 12345678910111213141516171819202122232425262728293031 >> 2024.08 NVIDIAのKepler以降のGPUに載っているNVEncを使ってみるはなし。 こんなかんじのログが出る。 最近は、GPUに動画のハードウェアデコード・エンコード機能を載っけるのが流行っているらしく、IntelのQSV、AMDのVCE同様、NVIDIAのKepler以降のGPUにもNVEncと呼ばれるハードウェアエンコード機能がついている。GPUの有効活用、という点ではこういう機能もぜひ使っていきたいところ。 ↑あまり有効利用してないこいつを有効に活用するのだ…。 しかし、これまでGeforceではこの機能がロックされていて、自由に使うことができなかった。(Tesla買えということですね、わかります) が、少し前、グラフィックドライバの更
2024.06 << 12345678910111213141516171819202122232425262728293031 >> 2024.08 のんびりポケモンをやりつつ、x265も軽くテスト。 H.265/HEVC、わりとすごいかもしれない? x265の今後に期待。 エンコードする前にやったこと ・コマンドいじってテストするの嫌いなのでguiExを改造したGUIを作ってAviutlとつなげた。まだバグだらけだけどひとまず動く。 ・現状のx265が標準入力を受け取れないので、input\yuv.cppだけいじってstdin専用にした(←適当すぎ)。まあテスト用なんでそれでいいでしょう。 ・muxerはL-SMASHで(rev778)。 ・デコーダの準備。まだLAV Filtersとかには入ってないのかな…ということで、muken様のlibav + L-SMASH WorksでAvi
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 Introduction to AVX2 optimizations in x264に詳しく関数ごとの高速化率とか書いてあって面白い。2割ぐらいは速くなるのかな? 以下、Introduction to AVX2 optimizations in x264からおおまかに意味をとると、 x264は様々なデータ型を多様なSIMD命令を使って計算している。SIMDコードのうち、128bitから256bitへ素直に拡張できるのはほんの少しで、多くはもっと複雑である。64bitから128bitへの拡張した際に倍速になることがほとんどなかったように、128bitから256bitへの移行も倍速となることはほとんどないだろう。 SSE2からAVX2への移行は
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 x264guiEx 1.00ではひとつしか設定のない「その他の設定」だったのだけど、いまやいろいろ増えてきたので、まとめ。 その他の設定 タブ1枚目 設定ファイルの保存場所 設定画面の上部から表示できるプロファイル設定(stgファイル)の保存場所。あそこで表示されるプロファイルの実体は、この「設定ファイルの保存場所」フォルダのなかのstgファイルのこと。指定されたフォルダの階層構造も反映して表示されている(1.34以降)。プロファイルを追加・削除するには、設定画面から操作するだけでなく、「設定ファイルの保存場所」フォルダに直接stgファイルをコピーしたり、削除したりでもOK。 この設定を変えることで、「設定ファイルの保存場所」を変更し、別の
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 要望があったので書いておく。 アップデートの方法は、 ・自動インストーラ(auo_setup.exe)を使用 ・手動 の2つがあって、 ・初回インストール時に自動インストーラを使った ・x264guiEx.iniをいじってない 上の2つの条件を満たしていれば、アップデートも自動インストーラで行える。 その他の場合は、手動でアップデートを行う。 自動インストーラ(auo_setup.exe)行う方法 まず、自動インストーラ(auo_setup.exe)を使う方法。 しつこいけど、もう一度書くと、 ・初回インストール時に自動インストーラを使った ・x264guiEx.iniをいじってない 場合に使用可能。 また、stgファイル、neroaace
2024.09 << 12345678910111213141516171819202122232425262728293031 >> 2024.11 x264guiExでBlu-ray用に出力する方法について。 あと、x264guiEx 1.70v2でBlu-ray出力用プロファイルを追加。 TMSR4 (TMPGEnc MPEG Smart Renderer 4)を使う簡単な方法と、tsMuxeR + ImgBurnな方法と、両方書いておく。 ここでそのうち書くよ、と言っていた内容。 まず、x264でBluray出力するために必要な設定はこんな感じ。 --colormatrix bt709 --colorprim bt709 --transfer bt709 --aud --nal-hrd vbr --bluray-compat --weightp 1以下 --b-pyramid st
2024.01 << 1234567891011121314151617181920212223242526272829 >> 2024.03 2週間ちょい前ぐらいからRadeon HD 7770というものを使っている。 こんなの。 ただ、わたしの場合放っておくと、これを普通の描画と、madVRと、NL-Means計算ボードとしてしか利用しない。これでは1万円の使い方として大変もったいないので、ちょっと違った使い方として、Radeon HD 7xxxについているVideo Codec Engine (以下VCE)を有効利用することを考えてみる。 Video Codec Engine (VCE) まあようはあれです、AMD版QSVというかなんというか。GPUに載っているハードウェア回路でH.264エンコードを行うもの。 QSVと違うのは、QSVが動き探索・動き予測などをGPU EUで、符号化
2024.04 << 12345678910111213141516171819202122232425262728293031 >> 2024.06 正直びっくりした。 QSVEncはメモリ速度に結構左右される、とは思っていたけど、これほどまでとは…。 ふと、QSVEncの速度がメモリの速度に左右されやすいのではないか、と思い至った。 調べてみると、 4.gamers - Ivy Bridge基礎検証。CPUの基本性能やGPGPU性能などから，Sandy Bridgeとの違いを徹底的に探ってみるのグラフ11などで、QSVにメモリ速度が関係あるかもしれない、ようなことが指摘されている。 そこで、実際に測ってみた。 環境 Win7 x64 Intel Core i7 3770K (4C/8T / 3.9GHz) HD Graphics HD4000 @ 1150MHz DDR3-xxxx 1
2024.04 << 12345678910111213141516171819202122232425262728293031 >> 2024.06 これまでの x264の--threads 続 x264の--threads の続き。 指定した--threadsの値によって変化する容量と画質について調べてみた。 x264の--threadsでは、bitrateの増加は気にしない、と書いた。で、今度は一応そのへんも気にしてみよう、ということ。 画質はとりあえずssimの値で評価する。(まあ画質をssimだけで比較するのは微妙だろうけど、それ以外に客観的に比較できないので) 環境 Intel Core i7 3770K (4C/8T, 3.9GHz @ 1.05V) メモリ DDR3-1600 9-9-9-24 16GB Win7 x64 Aviutl 0.99m x264 r2208 x6
次のページ
このページを最初にブックマークしてみませんか？
『rigayaの日記兼メモ帳』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
