AviUtl総合スレッド91

**sage** · 2019/09/19(木) 17:24:24.16

ここはAviUtl本体及びプラグインについての情報交換を目的としたスレです。

■当スレのルール
・「拡張編集」に関する話題は専用スレが用意されていますので禁止です。下記の専用スレに移動して下さい。

AviUtl拡張編集Pluginスレッド Part14
https://egg.5ch.net/test/read.cgi/streaming/1544284061/

・AviUtlの動作対象外となる、HDRやBT.2020、BT.2100に関する話題はスレ違いですので禁止です。

・一人語りや自演は、当スレに限らず掲示板では基本的に禁止事項です。ブログ等で一人でひっそり行ってください

■本家
AviUtlのお部屋（AviUtl本体、拡張編集プラグイン等）
http://spring-fragrance.mints.ne.jp/aviutl/

■前スレ
AviUtl総合スレッド90
https://egg.5ch.net/test/read.cgi/software/1562672744/

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 09:53:51.01

>>837
がらくたハウスのがらくた置き場 https://web.archive.org/web/20190330072446/http://www.geocities.jp/flash3kyuu/
　[インタレース維持リサイズ] [非線形処理な先鋭化] [非線形処理な先鋭化用前置フィルタ]

前スレのテンプレではちゃんと書いてたのにな・・・

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 09:59:05.39

テンプレのなにかがNGワードに引っかかってたと予想

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 21:55:53.28

rigaya氏のx264guiExで動画を出力した場合って
MPEG-LAに使用料を支払わないといけないのかなぁ

あと、有志の方がいっぱいスクリプトを作ってくださってるけど
商用利用に関する規約を明記されていないパターンが多々あるので
AviUtlで作った動画をYoutube(収益化)チャンネルに投稿するのは
色々と問題がありそう

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 21:59:04.50

会社でやってるならともかく個人がそこまで気にしなくてええやろ

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 22:11:24.16

ちょっとググってみたけど「エンドユーザが無料で視聴できる」場合はライセンス料は無料らしいぞ
YouTubeはこれに該当するでしょ

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 22:12:42.57

未だにこんなこと言ってるアホいるのか
かなり前から個人利用・ネット配信でのH.264パテントライセンスは無料化されてる

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 22:26:56.48

>>842
>>843
それはYoutube上での処理の話じゃないの？
Youtubeにアップロードする前に
自分でH.264にエンコードすると思うけど
そこは該当しないんじゃないか？

**名無しさん＠お腹いっぱい。** · 2020/02/21(金) 23:23:33.22

>>837
どうだった？報告キボン

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 00:50:20.39

>>838,839,845
遅れて申し訳ないです

>>839氏のおっしゃっている件が該当していまして
自分の専ブラでは>>838氏の書き込みによる指摘も見えていませんでした
がらくたハウスさんで公開されていたフィルタは
　・非線形処理な先鋭化 … https://web.archive.org/web/20190330072446/http://www.geocities.jp/flash3kyuu/auf/nlsharpen.zip
　・非線形処理な先鋭化用前置フィルタ … https://web.archive.org/web/20190330072446/http://www.geocities.jp/flash3kyuu/auf/prefilter.zip
　・エッジレベル調整 … https://web.archive.org/web/20190330072446/http://www.geocities.jp/flash3kyuu/auf/edgelevel.zip
にてダウンロードできました

ただ、以前ver1.10でプラグインのダイアログがうまく表示されない事がある
というものにうちではLanczos 3-lobed 拡大縮小がひっかかってしまいまして
このように全体を表示する事が出来ず、解像度を数値入力する事が出来ませんでした
https://i.imgur.com/ImsOfft.jpg
こちらの問題はAviUtlのほうで設定している解像度までは上部スライダで設定する事が出来るようで
1920x1080に設定した上でスライダを目一杯右に動かしてやるといけるようです

>>836氏が紹介して下さっているサイトに従って環境構築したところまでで
まだ実エンコは試していないので全てうまくいっているか分かりませんが
自分が把握しているのはこのようなことになっております

以上、長々と失礼致しました

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 01:17:33.56

何かおかしいと思ったらそれ2010年12月19日の情報だったわ
もっと最新の情報で試そうかｗ

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 03:20:54.10

>>844
自分で処理するものも含めてだよ
商用利用するならそれ用のライセンス契約が必要だけど

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 04:04:07.98

エンドユーザは無料で視聴できるけど
広告料が発生する場合はどうなるんだろう

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 09:52:23.63

>>846
リサイズはココのを使う（splineおすすめ）　http://nilposoft.info/aviutl-plugin/
エッジレベル調整はrigayaさんが高速化版を公開してくれてる

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 09:55:10.06

>>844
https://www.itmedia.co.jp/news/articles/1008/27/news021.html
H.264のライセンス料、無料ネット動画は恒久的に不要に

ただ作成ツールやアプリに関しては触れられてないので厳密に言えばヤバいかもな

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 23:33:00.60

win7からwin10に移行したらプラグイン出力（x264出力）のエンコ速度が40fps→20fpsになったんだが、
考えられる原因があれば助言いただきたい

パーツは共通で、起動用NVMeはW7とW10で別々に用意
※win10はクリーンインストール。最新状態までUG済

映像ファイルやAVIUtl関連のファイルはローカルHDD（SATA3接続）の同じものを使用
なので、OS以外に大きなパラメータの違いはないと思ってます
試しにw10でバッチ出力予約ししたものをw7で出力してみましたが、同じようにエンコ速度に差が出ます

タスクマネージャやHWMonitorで確認する限り
全コアやスレッドを使用してるように見えますし、W7とW10で使用率に大きな差は見えません

確認事項、考えられる原因があれば助言いただきたいので、お願いします

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 23:38:34.42

デコーダー

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 23:41:24.31

インテルのアレで半分は差が有りすぎだし
とりあえず裏でなんか動いてないかタクスマネージャーで確認

**名無しさん＠お腹いっぱい。** · 2020/02/22(土) 23:50:47.39

ランタイムの入れ忘れとか
自分は2003ぐらいから全部入れるようにしてる

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 00:01:46.98

Win10はアップデートした後しばらくシステムが裏でいろいろ動くから
1、2日放置しておいたら落ち着くかも

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 01:02:26.90

>>852
電源プランは？

**852** · 2020/02/23(日) 10:08:01.29

皆様、助言ありがとうございます

>>857
電源プランは元々の「バランス」でHDD省エネを0分（無効）にしてます
それ以外はモニタ関係、スタンバイ時間、ハイバネ無効くらいです

>>854
タスクマネージャとリソースモニタで観察してみたところ以下の事実がわかりました
・W7（80～90%推移）
CPU：AVIUtil：30～60%／ｘ264：60～30%
ディスクIO：3M～4MB/Sec（AVIUtlイメージ）
・W10（50～60%推移）
CPU：AVIUtil：30～40%／ｘ264：20～30%
ディスクIO：AVIUtilに関わるディスクIO見えず（DドライブのIOも0%のまま）

W7は常に3M～4MB/SecのIOが発生している（AVIUtilイメージ）に対して
W10はAVIUtlイメージがないというか、DドライブのIOが動いてないんですよね・・・
関連ファイルはDドライブ割り当てHDDに保存してます
試しに他のドライブ（RAMドライブ）でやってみましたが、結果は同じでした

ここから思いつくような対策ありますか？

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 10:10:01.44

>>858
Win10はクリーンインストールした？

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 10:53:43.42

ドライバ入れるのサボってるとか
PCの問題なのかSWのせいか切り分けるために
新規にセットアップしてエンコードしてみたら

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 11:13:25.38

>>858
>OS以外に大きなパラメータの違いはないと思ってます
レジストリに設定されている内容を引き継ぎしてなさそうだから、tsをMPEG-2 VIDEO File Reader辺りで読んでいて
その設定が初期化されているのが原因の気がするけどね

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 11:26:27.78

ピクセルアスペクト比を有効にすると1440x1080のTSが1920x1080で読み込まれるんだっけ？

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 11:26:56.08

もしWin10のProならSandbox使えるからまずはそこでテストしてみるのもありかもな

**852** · 2020/02/23(日) 11:40:39.38

>>861
当たりでした
まるも氏のツールってレジストリだったんですね。。。
失念しておりました

読み込み環境の記載が不足しており、ご迷惑おかけしました
レスいただきました方も含めて、皆様どうもありがとうございました

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 15:02:44.49

861のエスパー能力にワロタw
すげぇ

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 15:13:23.43

＞タスクマネージャやHWMonitorで確認する限り
＞全コアやスレッドを使用してるように見えますし、W7とW10で使用率に大きな差は見えません
自分が見た時はこれだったから余計に思考の彼方だったわｗ

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 15:24:40.86

>>862
それ設定するとむしろ遅くならない？

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 15:35:09.73

>>867
うん、もし有効になってしまっていたら遅くなるね、って意味で書いた

**名無しさん＠お腹いっぱい。** · 2020/02/23(日) 19:10:36.95

>>140
L-SMASH Worksでスカパーのfps誤爆がひどくて悩んでましたが、
プラグインをPOP氏のビルドからnekopanda氏のビルドに変更することで解決しました。

たいへん有益な情報をありがとうございました。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 00:00:43.53

x264guiEx_2.64に同梱のffmpeg_audenc.exeが落ちるわ。
Zeranoeとこのやつは落ちないのでね。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 09:53:02.42

具体的な環境とか設定とかコマンドとかも書いたほうがいいと思うが。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 11:01:48.24

>>870
試してみたけど正常動作する

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 15:12:41.41

質問失礼します
先程AviUtlを使い始めたのですが、動画のMP4出力ができません。
aviではきちんと出力できるのですが、プラグイン出力から×264を選択すると「ファイルの出力に失敗しました」と出てできません。
ダウンローダーから再インストールして上書きしたり、管理者として実行は試しました。
頬下になにか試せそうなものがあればなにか教えて下さい。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 15:27:35.37

>>873
今使い始めるならおとなしくRESOLVEかshotcut使ったほうがいい

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 15:51:33.10

>>873
記述が全く足りないからよくわからんが、とりあえずx264guiEx 2.64でインストーラが
大きく変更されたばかりだから、ゼロから環境を作り直せ。

あと、x264guiExで出力する場合は、出力ファイル名などを入れるダイアログで
必ず「ビデオ圧縮」を押してx264guiExの設定画面を出し、設定して「OK」を押してから「保存」で出力するように。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:08:12.31

RESOLVEおじさん嫌われてるけど初心者の相手をいちいちするのも疲れたので別のソフトのスレで引き取って欲しいような気もしてきた

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:09:03.63

やり方を>>875が書いてくれてるが、そこまで外部プラグイン弄り倒してまでやるかどうか、ということ。
utlは外部依存が強すぎる。
avcで良いのならRESOLVEでは無料なのが嘘のような高度な処理出来るし、shotcutは殆どのフォーマットを自由に扱える。
凝ったタイムラインも扱えるし。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:11:15.20

>>876
俺もね、utlではゴミしかできないだから辞めとけ、じゃないんだわ。
hdrやlut、aces扱えない点はゴミと思ってるけど。
utl今からやるにしては何もかもが面倒すぎて時間の無駄だからタダでやりたいならRESOLVEかshotcut使えと言ってるに過ぎない

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:13:38.35

ただしaeゴッコがしたい、特殊なインタレ解除がしたい場合はutlは選択肢には入る。
が、aeごっこなら正直fusion覚えた方がいい。
インタレ解除はインターレース素材=録画素材だろ？インターレース解除の良し悪しなんてほとんど気にしても仕方ないくらい放送の時点で劣化してるから気にするだけ無駄だと思う。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:15:22.01

自分で録画した物なら気にすることなく適当でいい。
yadifでも問題ない
今どきインターレースって時点で撮影素材の状態も知れてる。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:35:47.90

突然の自分語りはアスペの主症状

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:38:07.31

>>876
キーワードが召喚呪文になっちゃうんだから真スルーを覚えようぜ・・・

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 16:42:45.58

俺ももういい加減初心者にAviUtl使わせるのやめさせたほうがいいと思うわ
rigaya氏なんかずっと対応に追われててクタクタになってるじゃん

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:04:46.32

>>883
「初心者にAviUtlを使うのをやめさせる」なんて非現実的なことを考えても無意味だろ・・・。
▲▲(後者)は知らんが、初心者を●●(前者)に誘導したって、情報とか少なくて挫折して戻ってくるのがオチだと思うし・・・。

rigaya氏のブログに駆け込んで、まともな情報も書かずに質問してる初心者以前のアホどもを見てイライラするのはわかるし
それらに根気よく対応してるrigaya氏の負担を心配する気持ちもものすごくよくわかるんだが、
せめてこのスレに来てしまった連中がrigaya氏のブログに駆け込んでしまわないよう最低限の対応をして
少しでも負担を減らす（減る気がしねえというのはあるが・・・）ことを考えたほうがまだマシではないかと・・・。
あまりにも酷いのはテンプレにあるとおり初心者スレ送りにすればいいだけだし。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:09:09.94

初心者の教えて君はここでわからなきゃ聞きに行くだけ
utlを崇めてるのはいいんだがそれなら初心者用にチュートリアル映像でも作ってやればいいじゃん
うちはhdrの作り方、最低限は分かるように公開してるしlutも公開してる

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:11:08.61

動画サイトに上げる人はエンコを動画サイト任せにして細かい事考えんな
と言っとけばかなり負担が減る気はする

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:17:05.07

>>886
無理無理。そういうやつに限ってやれ画質がとかサイズがとか、下手すると他のプラットフォームで再生できない、だの言い出す

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:19:07.24

つべに至ってはどの道フルHDで上げた所でVP9に変換されるから拘った所で意味がない

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:19:41.70

>>888
h.264もあるぞ

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:23:27.55

＞無理無理。そういうやつに限ってやれ画質がとかサイズがとか、下手すると他のプラットフォームで再生できない、だの言い出す
流石HDRおじさん、自分がそうだと言う自覚無し。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:24:07.19

初心者ってYouTubeにアップしたあと画質が悪くなるのをAviUtlのせいにするからな
問題の切り分けが出来ないアホども

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:25:55.44

>>890
俺は単純に今の水準に必要な機能を満たしてないから批判してるだけ。
4k 60pもマトモには対応出来てないね。
個人的にはutlは録画素材の違法リッピング品の処理専用だと思うが。
処理能力、インタレ解除ともにこれだとちょうど合う

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:31:21.47

聞いても無い事を延々語る発達障害
家に遊びに来てなかなか帰ってくれない発達障害
居たよなぁ（遠い目

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 17:56:40.76

この流れで質問しても大丈夫か不安なのですが・・・

① https://1.gigafile.nu/0429-d3d65f1fc0877336ce3916d5279047f89
② https://1.gigafile.nu/0429-c96c7794dae4a3aa7a84cf077458a428e

グラボ交換を機に、ゲーム動画の録画をし始めて気になった問題です。
上記①のような動画をcrf18やCQP18ほどの設定で圧縮すると②の様に酷く劣化してしまいます。
(特にTEST文字の変化や◎模様など、MPC+madVRで比較すると顕著)

サイズ的にロスレスで保存しておくことは出来ないので再エンコは必須です。
そこそこの画質で構わないのですが、どんなフィルタやエンコーダー設定を用いるのがベターでしょうか？

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 18:10:05.86

>>894
YUV420に変換しているのが原因だから問題を完全に回避することは出来ない
気休め程度の軽減をしたいなら「UVダウンサンプリングフィルタ」と「色褪せ軽減β」を使う

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 18:15:20.57

>>894
わかってて質問してるんじゃなかろうかという気がするが・・・。

前者は10bit YUV4:4:4のH.265/HEVC。
後者は8bit YUV4:2:0のH.264/AVC。

文字の劣化は主に YUV4:4:4→YUV4:2:0変換によるもの。
色差が間引かれてピクセルの色が周囲と混ざったようになって劣化が発生する。

円形グラデーション部分の劣化は、主に10bit→8bit変換によるもの。
10bit（1024段階）階調で細かく表現できていたものが、8bit(256段階)階調で荒く表現されてしまうことで
バンディング（縞々）が発生する。

これらに更にエンコードによる劣化が加わることになる。

一番の大元のファイルがどういう形式なのかは知らんが、
一番いいのは前者のように10bit YUV4:4:4のH.265/HEVCでエンコードして保存しておくこと。

どうしても8bitでエンコしたいというなら>>895のようなフィルタとか
flash3kyuデバンド＋ディザリングみたいな手法をとることになるだろうけど
多分満足いくものにはならないと思う。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 18:17:56.77

>>894
RESOLVEでおｋ

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 18:24:38.15

>>896訂正
× flash3kyuデバンド
〇バンディング低減MT

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 18:25:43.38

バイオハザード7にレンダリング方式でインターレースが選択できますがそれはどうですか

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 18:37:41.31

>>894
RESOLVEでcineform、と言いたいが現実的にはhevc main10。文字のボヤけは諦めるかせいぜい422にする程度だな。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 19:06:16.34

>>895-896
録画自体はOBSというソフトで行っていてその段階ではレンダラーDX11-RGB、
NVENC用外部プラグインでLossLess指定なので巨大ファイルになってます。
スマホが若干古く本体はH264までの対応なので>8bit YUV4:2:0のH.264/AVCで解決出来ればと思ったのですが、
完全回避は難しい様なので保存用と持ち出しで分けても良いかもしれないですね。
（後出しっぽくてすみません）

教えていただいた、
「UVダウンサンプリングフィルタ」
「色褪せ軽減β」
flash3kyuデバンド＋ディザリング
バンディング低減MT

この辺りを試してみます！ありがとうございました。

>>897,900
ソフトの紹介ありがとうございます。
多少慣れている事もありAviUtlでの作業を念頭に置いてますが、RESOLVEについて聞く際にはRESOLVEのスレの方で聞かせて貰いますね。

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 19:10:03.89

あと世の中の映像は基本420と言うのは知っておいたほうがいいよ

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 19:39:19.69

スレの基本ルールも守れないRESOLVEおじさんが映像の基本を偉そうに語ってもなあ…

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 19:55:16.84

>>903
これは知っといたほうがいいことだからなぁ
そうでないものってカラリストでもなきゃ要らないし

**名無しさん＠お腹いっぱい。** · 2020/02/29(土) 20:09:13.11

初心者質問スレの新スレ

　【初心者歓迎】総合質問スレッド-86-【ダウソNG】
　https://mevius.5ch.net/test/read.cgi/avi/1582971304/

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 10:24:19.95

>>894
試しに①にバンディング低減だけかけて再エンコしてみたが
crf17で低周波ゴリゴリ盛って元の半分のファイルサイズまで膨らませてもこんなんだから
保存目的ならhevc422が良い気がする

http://www.axfc.net/u/4020607

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 10:33:51.74

RESOLVEは荒らしなのでNGワード登録推奨

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 10:54:42.13

>>901
OBSの標準色空間はbt.601だった気がするから
入力色空間をbt.601にすると多少はマシになるかも

最終出力にx265を使うなら--ditherも付けとくと良いはず

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 11:04:29.18

>894の映像で比較したけど--ditherは違いあり
切り出した画像での比較であって
映像での比較ではないから効果は薄いかもしれないが

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 11:12:17.34

>>901によると

> NVENC用外部プラグインでLossLess指定なので巨大ファイルになってます。
> スマホが若干古く本体はH264までの対応なので8bit YUV4:2:0のH.264/AVCで解決出来ればと思ったのですが、
> 完全回避は難しい様なので保存用と持ち出しで分けても良いかもしれないですね。

ってことだから、保存用はHEVC 10bit 4:4:4で許容できる品質で再エンコ（ロスレスに比べればだいぶ縮むだろう）、
スマホ用はフィルタかけて（もしくは割り切ってそれすらせずに）AVC 8bit 4:2:0で再エンコでいいんじゃないかな。
NVEncCが使えればどちらも高速エンコできるはずだし。

あとはそれ以前に「保存用」の必要性・重要度を考慮することも大事かな。
「保存したけどその後再び使うことはなかった」なんてありがちだし、どこまで割り切るかという話。

>>906
> 保存目的ならhevc422が良い気がする

8bitのことか10bitのことかわからんけど中途半端だしNVEncが422に対応してないはずだから選択肢としてはいまいちかも。

>>908
> 入力色空間をbt.601にすると多少はマシになるかも

そうなんだっけ？だとしても意味が出るほどには変わらないと思う。

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 11:40:01.49

>>901
すっかり忘れてたけど、拡張NVEnc出力またはNVEncC(CLI)を使うなら、
バンディング低減MTフィルタとほぼ同等で、かつ高速なバンディング低減処理が実装されてるようだから、そっちを使うといいと思う。

拡張NVEnc出力なら、設定画面の「フィルタ」タブにある「バンディング低減」で設定。
NVEncCなら--vpp-debandを使う。

　rigayaの日記兼メモ帳 NVEncにバンディング低減を追加 (CUDA)
　https://rigaya34589.%62%6cog135.fc2.com/blog-entry-937.html

　https://github.com/rigaya/NVEnc/blob/master/NVEncC_Options.ja.md#--vpp-deband-param1value1param2value2

NVEncC（CLI）を使えば、AviUtlでやるよりも高速でエンコできるので、習得しておくと色々便利だと思う。

**908** · 2020/03/01(日) 11:46:37.90

調べたら自分で設定できるみたいだから
OSBで設定した色空間を選択すればおｋ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 11:55:45.58

横やりですまないが、今まで何も考えずにx265デフォエンコしてたんだけど
8bitと10bitってそんなに違うの？(12bitもあるようだけど)

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 12:02:45.14

全然違うで
hevcなら標準規格のうちだから使わないのはもったいない
ただ遅くなるけどね

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 12:20:30.92

>>913
8bitは色が間引きされて赤がガクガクになる。バンディングが出る
x265は8bitより10bitの方がエンコ速い
なので特別な理由がなければ10bitエンコすべき

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 12:25:19.64

サイズ気にしないならそれもいいが、8bitソースに対してはデノイズやデバンドやらないなら無意味だぞそれ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 12:25:40.56

詳しくありがとうございます
今度から10bitに設定してエンコします
時間が許すなら12bitのほうが更にいいのかな

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 14:45:36.05

>>915
> 8bitは色が間引きされて赤がガクガクになる

なんか混同してるから一応つっこんでおくけど、>>896でも少し書いたように、
赤とかがガクガクになったり濁ったりして激しく劣化するのはRGB(or YUV4:4:4)→YUV4:2:0変換での色差の間引きが原因。

10bitだろうが12bitだろうが16bitだろうが、4:4:4→4:2:0変換で色差間引きが行われれば、赤がガクガクになるのは変わらない。

Avisynth+でRGB画像を読み込んで、ConvertBits(16).ConvertToYUV420().ConvertToRGB32() を試してみればわかる。
（RGB32→RGB64→YUV420P16→RGB32変換）

>>916
> サイズ気にしないならそれもいいが、8bitソースに対してはデノイズやデバンドやらないなら無意味だぞそれ

「10bitエンコしたら8bitエンコよりもエンコード後のデータ量が増える」というのは、よくある勘違い。
10bitエンコードは丸め誤差とかの関係で、理論的には8bitよりも圧縮効率がよくなるらしいので、
同じファイルサイズ（ビットレート）なら8bitよりも良い画質にできるというメリットもある。
なので8bitソースをそのまま10bitエンコする場合も、圧縮効率の向上というメリットがあるので、無意味というわけじゃないと思う。
まあエンコーダとか設定とかにもよるだろうから、そのへんの調整は必要だろうけど。

>>917
10bitで十分だと思うよ。

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 15:06:36.60

>>918補足

> 10bitだろうが12bitだろうが16bitだろうが、4:4:4→4:2:0変換で色差間引きが行われれば、赤がガクガクになるのは変わらない。
> Avisynth+でRGB画像を読み込んで、ConvertBits(16).ConvertToYUV420().ConvertToRGB32() を試してみればわかる。
> （RGB32→RGB64→YUV420P16→RGB32変換）

前に作ったサンプルが残ってたから上げとくわ。

　元画像：　　　　　　　　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3560.png
　YUV420P16変換後： http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3561.png

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 15:07:37.60

>>918
そのレベルの追い込みをかけなきゃいけないものを素人にやれとは言えないな
理論上は裏技あるよ、はこの場合だと不適切。
ただ少なからずの処理をしているなら10bitは好ましいが。

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 15:29:38.49

>>920
別に難しく考える必要はないと思うよ。

ふーん、10bitは8bitより圧縮効率いいのかー
　→とりあえず今までの設定で8bitエンコしてみっかー
　→同じもんを同じ設定で10bitエンコしてみっかー
　→10bitのファイルサイズが8bitと同じくらいになるようにcrfの値だけ調整してみっかー
　→同じサイズの8bitと10bitを見比べてみたら、10bitの方がちょっとだけ画質よさげだな。（まあそこまでわかるか微妙かもだが・・・）
　　　このままでもいいけど、もうちょいサイズ減らしてもよさそうだから10bitのcrfの値だけ調整して画質調べてみっかー
　→これくらいで十分そうだな。今後はこの設定で10bitエンコすっかー

あくまでも一例としてだけど、こんな感じで十分じゃないかなと思う。
もっと単純に言うなら、「とりあえず10bitにして好みのcrfにすればいいんじゃね」で済むくらい。
俺はエンコへのこだわりが強いわけじゃないので異論は認めるｗ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 15:44:42.84

まぁその程度の認識ならそれはそれでいいけど
基本的にビットレートあげずに解像度上げるようなもので害しかないと思うよ
映像に処理加えるならわからなくもないけど

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 15:51:41.99

このアプコンメモはアニメ用らしいんですが実写用にはどう調整すれば良いですか？
https://blog-imgs-102-origin.fc2.com/m/t/k/mtkdt/20170220165128382.jpg

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:15:59.82

>>922
> 基本的にビットレートあげずに解像度上げるようなもので害しかないと思うよ

全然違うと思うけど、具体的にどんな害があると思ってる？

以下はx264の10bitエンコができるようになった時に出てた資料だけど、
この資料だと10bitエンコした場合5～20%くらいのビットレート削減ができると書かれてる。
まあ実際にはそこまでの効果はないとは思うし、自分でちゃんとした検証はできてないけどね。

　Why does 10-bit save bandwidth (even when content is 8-bit)?
　http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

しかしx264.nlって一応まだ生きてるんだな・・・。トップに行こうとするとVideoLANに飛ばされるけど。

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:25:50.67

>>924
bitが多いのは解像度上げるようなもんだよ
まぁ試してみるといいんじゃない？

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:33:43.96

もったいぶった感じで内容ゼロな人の信用度なんてゼロに等しいよ、残念だけど
人に試せという前に自分が試しましょう（少なくとも924は自分で試してる人だろうに

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:37:06.10

解像度弄るのは画素数変わるけど
色深度の桁数変えた所で画素数は変わらない
処理過程で扱いが変わる程度

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:39:20.21

PSNRやらSSIMの効率は10bitのほうがちょっとだけ良いしな

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:50:27.96

>>927
流石にそれはわかってなさすぎ
hdmi2.0で4k 60p 10bit rgbは通らんよ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:58:25.57

で、ここからRESOLVEに持ってくんですね
俺は詳しいんだ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 16:59:33.76

>>929
いや、今はエンコの話でディスプレイ出力の話は帯域やらなんやら有るからまた別やろと…あっ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 17:02:49.61

>>931
同じものを表現するのに10bitはそれだけ多くのデータがいる。

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 17:07:43.04

>>932
今話してるのは
エンコの過程で8bitだと捨てられるものが10bitだと残ったりするって話であって
もっと言えば圧縮と言う処理の関係上大して容量も変わらず暗部やグラデも綺麗にと
貴方が言ってるのはその先の話

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 17:32:28.99

データの絶対量がそもそも違うものを圧縮したといっても品質同じならその差はひっくり返らないよ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 17:37:50.62

この中にひとり解像度とビット深度とサブピクセルフォーマットとデータ伝送帯域をごちゃまぜにしている人がいる

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 18:07:20.46

分からない・知らない・勘違いは仕方がないし、それを理由に責められてたら同情もするが
上から目線で言ってたりするのが痛いところ

**名無しさん＠お腹いっぱい。** · 2020/03/01(日) 20:04:34.05

AV貴族