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/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貴族

**924** · 2020/03/01(日) 22:46:06.45

>>925　> bitが多いのは解像度上げるようなもんだよ
>>932　> 同じものを表現するのに10bitはそれだけ多くのデータがいる。

他の人も言ってくれてるけど俺なりに説明しておくと．．．

何の圧縮もしてないデータなら、8bit映像より10bit映像の方がデータ量が多いのは当たり前。そんな話はしていない。
上でしているのは、

　　Ａ．8bit映像を(10bitに変換して)10bitエンコードしたもの
　　Ｂ．8bit映像を8bitエンコードしたもの
　　※ただしＡとＢは同じビットレートとする

を比較した場合の話。"両者をデコードして映像を比較"すると、
（基本的には）Ａの方が圧縮効率が良くなるため、Ａの方がＢよりも多少画質はよくなる（ことが多い）ということ。
ただし上でも書いたようにソースやエンコーダの出来や設定等で結果が変わることもある。

なので、8bit映像を特に何もせず10bitエンコしても（基本的には）特に害はなく、
画質向上あるいはファイルサイズ削減というメリットが得られる（ことが多い）。
問題があるとすれば、使用環境（再生ソフトとか編集ソフトとか）で10bitエンコしたファイルが扱えるかどうかってことくらいか。

ちなみに3年前にQSVスレでSSIMとビットレートの関係を調べたグラフならある。（古いので現状との齟齬はあると思う）
　　http://mevius.5ch.net/test/read.cgi/avi/1486130737/335

慎重に説明してみたけど変なとこがあれば言ってくれ。

**924** · 2020/03/02(月) 01:18:47.54

次スレは>>980が立てることになってるからまだ先だけど、とりあえず次スレ用のテンプレ案を作っておきました。

　AviUtlスレ92用テンプレ案
　https://pastebin.com/K9qZdafP

変更点は書いてあるとおり。意見などがあれば更新していくつもりなので今のうちに。

時間があればL-SMASH Worksの現状についてもまとめメモを作っておきたいところ。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 10:05:52.02

8→10bだと1.5%縮むが、8→12bだと4%増えるのか・・・むつかしいな
デコード負荷も当然増えるんだよな？

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 10:07:14.57

ダメダメなL-SMASH Worksがメジャー級に紹介されてるのがイヤなところ。
せめて、ここだけは、そこを改善しよう。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 11:12:04.42

>>941
他に代わりになるようなプラグインあんの？

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 11:31:05.98

>>942
最近Twitterで見かけたのだと、Media Foundationを利用して読みこむという

　GitHub - amate/MFVideoReader
　https://github.com/amate/MFVideoReader

ってのがあるね。ただ、まだ自分で試せてないし、書かれてるような制限や問題点もあるから
L-SMASH Worksの代わりになるとまでは言えないと思う。

ついでに紹介しとくと、同じようにMedia Foundationを利用してMP4出力を行う「かんたんMP4出力」ってのを
別の人がリリースしてくれてるね。

　Aviutl プラグイン「かんたんMP4出力」 : プログ
　http://aoytsk.blog.jp/aviutl/34586383.html

こういうのって、こまめにSNSとか見てないと気付かないから、見かけた人は積極的にスレに書き込んでもらえるとありがたいな。

以前は自分も結構チェックしてたんだけど、SNSに割く時間がなかなかとれなくなってきてるというか
SNSに縛られてるような感覚が嫌になってきて疎遠になってきてるというか・・・。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 12:04:04.59

かんたんMP4出力って
あまりにも簡単すぎて何も出来ないのね…

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 12:23:43.86

>>944
まあMedia Foundationのエンコーダは圧縮効率もよくないし、
rigaya氏の各種出力プラグインが使えるなら、かんたんMP4出力を使う意味はあまりない。
画質とかに特にこだわりとかのない色々と割り切った人向けって感じだろうね。
色々と作って選択肢を増やしてくれる人がいるのは、とてもありがたいこと。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 12:33:48.29

相変わらず思い込みだけで話してるなとしか言いようがない
bit数増えてサイズが影響受けないならなんで16bitて映像保存しないんだって話でしかないわ。基本製作時は16bitだしnleで考えるなら32とも言えるが。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 12:52:43.23

DGIndexでavs出してのavisynth経由での読み込みが一番
L-SMASH worksは画質比較でmp4読み込んだりするときはいいんだけど
ts読み込みだと不安定で結局DGIndexに舞い戻ってる

>>946
分かってない話は無理にしなくておｋ

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 13:21:00.09

>>946
理解力や理解しようとする努力の不足を棚に上げて人を貶めたり、話をずらして（あるいはずれていることにすら気づけず）
積極的に自分の傷口を広げていくスタイルを見せてくれるのはこっちにとっても好都合ではあるんだけど
>>924で示したものを含む10bitエンコ関連資料が、昔書いた以下のレスにまとめてあるから読んでおくといいよ。

　【2016】 H.265/HEVC Part7 【7680x4320】
　https://mevius.5ch.net/test/read.cgi/avi/1485191956/726

HQXコーデックの日本語ホワイトペーパーのURLが無効になってるので、そちらは
　　https://www.ediusworld.com/jp/products/whitepaper/index.html
からPDFを落として読むといいと思う。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 15:05:28.08

>>946
なんでって再生側が対応してないからだよ
再生互換性考えないなら16bitで保存すればいいよ

bit数増えてもエンコードはソフトウェアでやれば問題ないけど、
デコードは家電や携帯機器でも行われるから、
回路の規模やメモリ使用量が増えるのが問題

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 15:34:06.13

画質に対してかかる時間と圧縮率のコスパもなぁ

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 16:36:53.75

>>949
再生側が対応してないからというか、それ以前の問題として
　　「人間の視覚の限界や再生デバイスの能力を考えると、
　　　少なくとも現時点で完成映像を消費者に届けるなら10～12bit深度もあれば十分」
って理由もあるよね。Dolby Visionだって最大12bitなわけで。

>>946
> bit数増えてサイズが影響受けないならなんで16bitて映像保存しないんだ

「bit数をいくら増やしても問題ない」なんて言っていない。
8bitエンコを10bitエンコにするくらいなら、圧縮効率の向上によってデータ量増加分を吸収することもできると言ってるだけ。
さすがに16bitとかにするとそういうわけにはいかないでしょ。

> 基本製作時は16bitだしnleで考えるなら32とも言える

撮影素材や編集についてはカメラの性能を生かすためとか、各種処理で高精度が求められるからといった理由で
32bit浮動小数点とか16bit整数とかで扱う必要があるだけ。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 16:51:18.29

失われた情報は完全には戻らないし
修復可能だとしても手間だしな