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

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

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

横からですまんが8ビットより10ビットが圧縮効率良くなる理由がよくわからん
あと8ビット→10ビットの場合色域はどうすれば良いの？ソースのまま？

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 18:24:22.07

8bit10bit論争なんて今どきやるなよ
エンコなんて画質を落として容量減らす作業なんだから
誰でもどこでも見れる8bitで良いんだよ
高画質を望むならHDDが安いんだからTSで保存する

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 18:39:54.49

>>953
差分圧縮的に暗部やグラデーション部のゆらぎが影響するとかじゃね？

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

>>949
相変わらずむちゃくちゃ言ってるな
4K 60p RGB 10bitが通らないのはサイズがデカすぎるからという単純な現実がある。

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

>>951
あと12bitで良いってのはデータを間引きしてるから。それがPQの本質。
それやらないなら14とか16bitいるぞ。

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

>>953

>>924の資料を読むのが一番だけど、とりあえず一部のみ雑に直訳。

■なんでH.264 10bitエンコーダーは8ビットエンコーダーより良いの？
　10ビットでエンコードを行った場合、圧縮処理はたったの8ビットではなく
　最低でも10ビット精度で動作します。
　そうすると切り捨て誤差が減り、特に動き補償の処理において圧縮効率が向上します。
　また、それにより、目標ビットレートを達成するための量子化の必要性が少なくなります。
　結果として「同じビットレートでより良い画質を実現」、
　「同じ画質をより低ビットレートで実現」できるということになります。
　典型的なソースでは5%～20%の(ビットレート削減)効果があります。

自分も細かいことまで理解してるわけじゃないけどね。

> 8ビット→10ビットの場合色域はどうすれば良いの？ソースのまま？

色域というと用語的によくなさそうだけど、入出力色空間の設定とか
colormatrixとかの設定については8bitの時と同じで問題ないよ。

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

>>958
それはNLEで高度な処理をする場合、の話
ここのやつがやるような単純な変換だとただの無駄。
デバンド、デノイズをかけてるなら別だがな

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

一応言っておくけど、俺はなんでもかんでも10bitにすればいいと言ってるわけじゃなく、
話の流れというか、アレのあんまりなアレっぷりをより明確にしておくためというか、
これに懲りて他のスレでも少しはおとなしくなってくれればいいなーでも無理かなーどうせ無理なんだろーなーとか
ついでに誰かの役に立てばいいなーとか思いながら資料等を出しつつ10bit出力の効果について説明してるだけなので、
10bit出力を採用するかどうかは各自で判断してね。

>>956-957 >>959
で、元の話から根本的に勘違いしてることは理解できたの？できてないよね？話が全くかみ合ってないけど？
やっぱり自分の間違いに気づいたり、それを素直に認めたりするのは無理？無理なんだろうな～。

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 20:25:45.88

HDR基地いつまでも相手する奴も荒らしな

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 20:26:44.42

x264チームとかEDIUSの開発元みたいなプロの資料持って来ても話通じないのか
思い込みで話してるのはどっちなんだろうねえ

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

そもそもSDR動画をHDRモードのディスプレイで映してバンドのズレで白くミルキーに成ってるのに
SDR動画の方がおかしいとか言ってHDR化と言う名の階調潰れ動画作って自慢してる人間だぞ
増してエンコードとデコード＆出力の区別もつかないんじゃ話が通じる訳がない

**名無しさん＠お腹いっぱい。** · 2020/03/02(月) 22:19:33.79

>>960
横レスだけどコイツの言ってる事は事実だったわ
適当な地デジアニメと>>894の①のいずれでも10bitエンコの方がSSIM(All) PSNR(Avg) VMAF、ファイルサイズともに概ね良好な結果になる
1例だけ例外があって、YUV420P8⇒x265.exe --output-depth 8のケースで何故かVMAFの結果だけが突出して良かった（ssim,psnrは悪いのに謎ｗ

neo_f3kdbでデバンドした場合、AvisynthでConvertbits(10,dither=-1)とディザ無し補間無しで10bit化した場合、
8bitインプットのまま--output-depth 10or8にした場合のどのケースでも10bitが優秀
しかもビットレートは10%以上差が付いてるんですが、、マジかよ。そいう大事な事はもっと早く言ってくれよｗ

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

私がたびたび書いてるditherオプションとかも総スルーだし
自分が気になること以外は目に入りにくい法則

**名無しさん＠お腹いっぱい。** · 2020/03/03(火) 20:26:34.21

書き込みテスト

**名無しさん＠お腹いっぱい。** · 2020/03/03(火) 22:10:13.98

>>960
いつまでも現実認めないアホの末路がそれかw

**名無しさん＠お腹いっぱい。** · 2020/03/03(火) 22:11:15.56

>>965
デバンドやデノイズをするなら10bitの意味はある
そうしないならバンディング出てるのをわざわざ10bitにしてデータ増やすだけ

**名無しさん＠お腹いっぱい。** · 2020/03/03(火) 22:12:04.54

>>963
お前はHDRのまともな視聴環境持ってない時点で論外w

**名無しさん＠お腹いっぱい。** · 2020/03/03(火) 22:35:34.43

あー・・・最初から期待はしてなかったけどやっぱり駄目だったかー。
常人なら恥ずかしくて戻ってこれなくなるはずなんだけど常人なわけもなく。
まあゲームシステム的に言うと
　　「根拠を示した懇切丁寧な説明を受けても何が理解できていないかすら理解できず
　　　叩きのめされている自覚すら持てず１人で見当違いなことばかり叫び続けたサル」
の称号くらいは付与できたと思うんで、当初の目的達成ということでスルーに戻りま。

**名無しさん＠お腹いっぱい。** · 2020/03/03(火) 22:36:57.44

>>970
色と光を理解できない時点で論外だよw

**名無しさん＠お腹いっぱい。** · 2020/03/04(水) 03:37:21.70

>>971
お前の目が腐ってる時点で論外

**名無しさん＠お腹いっぱい。** · 2020/03/04(水) 11:20:52.14

>>961

**名無しさん＠お腹いっぱい。** · 2020/03/04(水) 11:50:52.36

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

**名無しさん＠お腹いっぱい。** · 2020/03/04(水) 17:12:09.85

>>974
RESOLVEでおｋ

**名無しさん＠お腹いっぱい。** · 2020/03/04(水) 17:33:44.53

そろそろ>>980なので>>939の次スレ用テンプレ案を再掲。

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

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 12:40:38.70

nekopanda氏がAmatsukaze 0.9.1.3用に、高速化版L-SMASH(Worksの方ではない)をリリースしてくれてる。

更新内容は「H264,HEVCのmuxとtimelineeditorを高速化」となっててmuxer.exeとtimelineeditor.exeのみ。
Amatsukazeスレでの報告だと
　> 60分ドラマでMux処理が2分30秒だったのが20秒ほどに劇的に高速化されました。
とのこと。

　リリース
　https://github.com/nekopanda/Amatsukaze/releases

　ソース
　https://github.com/nekopanda/l-smash/tree/fast

　Amatsukaze その2
　http://jbbs.shitaraba.net/bbs/read.cgi/computer/44736/1562757840/531-

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 14:47:16.01

Bandicamだと音質がどうしてもひずむが、MAD類はどうやって音質をクリアに保ってるんだ？

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 14:58:56.31

>>978
スレ違いなので初心者質問スレあたりにいくといい。

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

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 15:01:14.37

980到達ということで、次スレ立てに行ってみます。
1時間ほど経っても音沙汰がなく、スレが立ってる様子もなければ、規制された可能性があるので、どなたかよろしくお願いします。

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 15:30:05.04

連投規制最大5分間隔＆5連投程で規制の場合有り
（クッキー＆回線繋ぎ変えで回避可能かも）
更に書き込み出来なかった場合全く同じ内容だとコピペ規制で書き込めない
（URLのh抜きなどで対処）
ここのテンプレ貼りは浪人無いと厳しいかもね

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 15:40:16.66

次スレ

　　AviUtl総合スレッド92
　　https://egg.5ch.net/test/read.cgi/software/1583388182/

>>981
2回ほど連投警告をくらったり毎回Cookie消したりしながら・・・なんとか・・・貼り・・・きっ・・・・た・・・よ・・・

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 15:42:33.22

ダビンチ君大暴れだな
本当に酷い糖質荒らしだよこいつは

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 15:47:35.44

>>982
よくやった！
もうちんでええで

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 15:58:44.19

>>983
関連キーワードが召喚呪文になってしまうので次スレでは真スルー推奨やで。

>>984
おぅ！

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 16:09:03.70

5ちゃんで　やで　とか言っちゃうJ民巣に帰れ

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 18:14:24.34

33-4 とかだっけ

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 19:47:11.30

>>975
筆者はPowerDirecotrを推しておきます。

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 20:58:48.33

>>974
埋めついでに個人的感想を述べておくと、ブログの記事のURLではなく記事中の画像のURLだけ示されると見る気が失せる。
URLでググれば元記事を見つけるのは簡単だけど、よほど強く興味を惹かれる内容でもなければその手間をかけることすらめんどい。
まあ俺は実写も含めてアプコン処理を追求したことはないので回答できないんだけどね。

ついでに回答にはならないことを承知で言うと、綺麗に拡大視聴したいというだけならmadVRを使うという方法もあるよ。

**名無しさん＠お腹いっぱい。** · 2020/03/05(木) 21:05:21.22

>>974
あ、あとはwaifu2xってのもあったっけ。caffeとやらでは実写対応しているらしいけど、AviUtlプラグインの方は知らぬ。

**名無しさん＠お腹いっぱい。** · 2020/03/06(金) 09:28:13.02

要するに出来無いって事か

**名無しさん＠お腹いっぱい。** · 2020/03/06(金) 16:20:44.31

どの程度のどんな状態で納得が行くかを判断するのは個人によるので
そもそも正解が無い

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

nekopandaさんのl-smash
くっそ速いね

**名無しさん＠お腹いっぱい。** · 2020/03/07(土) 21:13:19.36

muken氏はもうソフトの更新する気無いのかな
仕事が忙しいとかバグ修正で休日を潰しまくって嫌になったとかあるんだろうけど

**名無しさん＠お腹いっぱい。** · 2020/03/07(土) 22:19:08.73

　Aさんはソフト更新の気力を溜めている・・・

　生活事情や趣味の攻撃！溜めていた気力が霧散した！

　気力溜めリキャスト可能まであと●●日です
　
　
何かしらの割と大きなきっかけがないと気力が溜まりきらないとか、
そもそも気力を溜め始めることに意識が向かないという感覚はなんとなくわからないでもない。
（muken氏がそうかどうかは知らないけど・・・）

**名無しさん＠お腹いっぱい。** · 2020/03/07(土) 22:31:30.40

ソシャゲにずっとハマってて、録画したゲーム動画を扱うためにL-SMASH worksに手を入れるも
もとの録画データが糞でスマホ変えっぞクソがと呟いてたのは見た気がする