AviUtl総合スレッド85©2ch.net

ここはAviUtl本体及びプラグインについての情報交換を目的としたスレです。
ただし「拡張編集」に関する話題は禁止なので、下記の専用スレに誘導して下さい。

AviUtl拡張編集Pluginスレッド Part11
http://potato.2ch.net/test/read.cgi/streaming/1456458041/

---

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

■前スレ
AviUtl総合スレッド84©2ch.net
http://potato.2ch.net/test/read.cgi/software/1478931207/

★初歩的な質問はDTV板の初心者質問スレで
【初心者歓迎】総合質問スレッド-83-【ダウソNG】
http://peace.2ch.net/test/read.cgi/avi/1454932012/

■x264guiEx関係はDTV板x264 GUI専用スレで
x264vfw GUI専用スレ Part9
http://peace.2ch.net/test/read.cgi/avi/1351856057/

■その他
・ニコニコ動画関係はYouTube板→ http://potato.2ch.net/streaming/
・ダウンロードした動画はダウンロード板→ http://mint.2ch.net/download/
・次スレは>>980が立てること。

h.264ならバグがない限りデコード結果は常に一定じゃろ
mpeg2とかならちょっと変わるかもしれないけど気にするほどじゃないでしょ

なに言ってんだ
デコード結果が変わるのは大問題だろ…

h.264は知らないけど
mpe2はデコーダーで画質は変わるよ
画質が良い悪いじゃなく変わる

デコードした後の補正の違いじゃなくて？
復号の結果に差が出るの？

wikiソースで悪いが、これ読む限り古いコーデックは実装によってデコード結果が違うんじゃないの？

https://ja.wikipedia.org/wiki/H.264
>演算がすべて整数精度で行われることで、実数演算の実装差による「デコーダごとの演算結果の差分」を生じさせることなくエンコードすることが可能となった。
>これは、エンコード時の局部復号器の結果とすべてのデコーダでの出力結果が全く同一になることを意味している。
>エンコード時の局部復号器の結果とデコーダの出力結果が異なる場合、エンコーダが作成する再構成画像とデコーダが作成する再構成画像が異なることとなるため、フレームが経過するごとに画像にノイズが蓄積してしまう。
>これを回避するため従来技術ではそのDCT演算誤差の帳消しのために定期的にイントラマクロブロックを挿入する必要があった。
>H.264では整数変換を用いており誤差の問題が生じないため、定期的にイントラマクロブロックを挿入する必要がない。
>デコーダの実装差による出力結果の違いが生じないことは、デコーダの規格適合性を検証する上でも有利となる。
>H.264の関連規格であるH.264.1はH.264規格適合性の検証手法を定めるもので、H.264で符号化済の試験用ビットストリームとそのデコード結果の組が多数付属している。
>開発中のデコーダに試験用ビットストリームを入力し、その出力結果とH.264.1付属のデコード結果が厳密に一致しているかどうかを確かめることで、規格適合性の判断を行うことができる。

ﾁﾝﾌﾟﾝｶﾝﾌﾟﾝ

ちょっと気になったから調べてみたわ。
だいぶ前に自分でビルドしたr765 FFmpeg N-68790-g037b527とAvisynth wikiのとこのr929でそれぞれtsを読み込んでUt Videoで出力。
出力したAVI同士でPSNRを比較したら結果が一致した。

FFmpegのmpeg2デコーダは長いこと出力結果が変わってないので画質の違いは気にしなくてよさそう。

>>815
浮動小数点演算が行われるデコーダーならコンパイラのオプションやアーキテクチャによって誤差が出るはず
ただし違いを目で見て分かるわけじゃないし差分取らないと分からないレベルだろう

ソースコードレベルなら上にも書かれてるけどffmpegやlibav側のデコーダーがデバグやエンバグされてその結果違いが出ることはあるはず
どっちにしろ気にすんなってことだ

MPEG2デコーダーの誤差はIDCT関数の違いで出るってことじゃないのかな
FPだけじゃなく整数を使う関数も幾つかあるし

たしかffmpegに関数を変えるオプションあったはず
まるも氏のMPEG2プラグインにもある

muken氏のツイッターを見た感じ、とりあえず>>796-797の報告には気づいてもらえたっぽい。
>>808が言ってるようにLW-Libavを使えば回避できる問題だし、のんびり改修待ちやね。

>>818
それって、
lsmashvideosource()
で読むか
lsmashsource_lwlibavvideosource()
で読むかってこと？

後者だと問題ないのかな？？
後者のが万能だから、基本すべて読み込みは後者しか使わないけど、
それだと何か問題あるの？？

バグ云々は別として、単純に前者と後者を使い分ける意味があるのかってことね。
前者とで読めない場合は後者で読める、それなら後者しか使わなけれゃいいってなるよね、普通。

L-SMASHで動画を読み込み、x264guiexで出力するとmp4のタグのコーデック欄に「MPEG-4 AAC (L-SMASH)」と書き込まれます
これをMPEG-4 AACに書き換えたいのですが、どのようなソフトウェアを使えばできるのでしょうか？
Mp3tagではできませんでした

なんの見栄だよ。
ﾍｯﾀﾞ書き換えって。

>>819-820
Libav+L-SMASH（＝LSMASHVideoSource()）は、一部を除きMP4やMOVを
インデックスファイルの生成無しで読み込めるのが利点。
インデックスファイルの生成という手間が入っても構わないなら常時LwLibavでいいかもね。
あとわざわざlsmashsource_lwlibavvideosource()というDLL名_関数名記法にせずとも
普通にLwLibavVideoSource()でいいと思う。競合するようなもん無いし。

>>821
L-SMASH Worksで読み込んでるのは全然関係ない。
関係あるとしたらmuxで使ってるL-SMASHのmuxer.exeだろうけど、
「L-SMASH Audio Handler」みたいなメディアハンドラ名はつけるけど、
「MPEG-4 AAC (L-SMASH)」なんてタグ（？）は付けてない。
「MP4のタグのコーデック欄」て、どんなソフトで確認したの？

qonohaかmpc-hcか忘れたけど再生中にLAVFilterのsplitterの項目で見かけた気がする

>>823
mp3tagって書いてあるじゃん
L-Smash muxerでm4a作るとコーデック列がそんな名前になってたと思う
あそこはユーザがどうにかできるものじゃなさそうだし
AviUtl関係ないな

>>825
横からで済まないがmp3tagじゃ変更できなかったという意味で書いてるだけでmp3tagで件のタグを確認したと書かれてるわけじゃないと思うぞ

>>819
>>820
https://twitter.com/OumaeKumikoBot/status/505281540335497216

ffmpegやlibavはシークに問題がある　だからindexファイルを予め生成しておいてその問題を回避しようとしてる
LSMASHVideo/AudioSource()は読み込めるフォーマットが限られてる代わりにその面倒くさい問題がなくなる

AviUtlは自動で切り替えてくれるしAviSynthとVapourSynthはテンプレ作るなり拡張子で分岐させるなりtry catchなりすれば切り替えは容易
indexファイルとか言うゴミの処理面倒だし、indexファイル生成しないようにしたら読み込むたびに解析終わるまで待たないといけない

以上のこと踏まえて後者しか使わなくていいよねってのはちょっと同意できない

batでlwiの生成までやってしまえばおｋ

60FPSで録画しても60FPSの動画がどうにも作れん、散々調べて60FPSに設定したが
エンコ後は60出てない、エンコ後のファイルを調べても60FPSになってて
youtubeに上げても60になってるが、映像は明らかに30FPSくらい、何でかわからん

上げた動画晒せ

同じコマが2回続いてる60fpsなんだろうよ

>>829
キャプチャ時の時点で30FPSなんじゃないの？
ゲームなんかだと60FPSかと思っていたら30FPSだったなんてよくある話

あとエスパー回答になるが、アマレココでデスクトップ・キャプチャを選択してると30FPSに制限される
ウインドウ・キャプチャだとそういう制限はない

>>829
テンプレ>>2のA2の情報を全部出せ。

キャプチャ時に30fpsならエンコ後も30でしょ
通常読み込みなら

>>835
ごめん、言い方が紛らわしかった
表記は60FPSだけど実レートが30FPSって事

インタレの60iなんじゃね？

ちょっと聞くけどG3258＠4.3GHzからRyzen1700に変更したらエンコ速度が倍くらい早くなるかな？

4倍くらいじゃね？

x265なら4倍は速くなるんじゃね

mpeg1なら10倍速くなるんじゃね

Ryzenはx265不得手じゃなかったか？

やや苦手らしい
今はB2 steppingのRyzen出そうだから
買う気ならその情報を確かめてからの方がいい

爆熱！

>>842
sky/kabyに比べれば最良ではないけど
G3258はavx2ないんでしょ？
劇的に速くなると思うよ

60iテロップのちらつきを抑える方法って無いかな？

はい

avisynthにはあるよ

30pにすれば解決

>>845
>>726

面倒ならautovfrで処理

CPU
corei5でこのソフトってスペックたりる？

何年前からあるソフトだと思ってるんだ

>>851
ソフト使うだけならもっと低スぺでも余裕で動く

ゴキブリ１６１０セロリンでエンコしてるよ、寝てる間にだけどね

Pentium3でも動く

pentium-nはどうでしょうか？

perfume notch

結構久々にaviutl使ってmp4にエンコしたら、出力の際に左上に出力中ってなる前に検索中になるんだけど、こんなんあったっけ？
使ってない期間にアップデートした覚えはないけど、勝手に仕様変わることあるの？

おまかん

>>858
エンコードが実際に始まる前に、左上に検索中と表示されるやつかな
アプデとか関係なく数年前から俺も出ることはある

システムドライブが処理可能になっているけど、データドライブの処理が間に合わない時に出るだろ
最近ではシステムがSSDで他のHDDにデータがある場合なんかにはよく出る
昔はS-ATAのシステムとUSBのドライブの組み合わせで起きた

>>860
そうそれ
これまで出た記憶なかったからなんで出るようになったか疑問

>>861
でも俺PCの構成ここ数年変えた覚えないんだけど
むしろ今よりゴミスペックのコア2デュオとか使ってた5〜6年前ですら出たことなかったはず
.exeやら付随するファイルも普通の外付けHDDの中にあるし、録画データに関してはUSB3.0の別の外付けHDDの中だし

>>862
音量の最大化を有効にしてない？

>>863
サンキュー
多分これだわ

L-SMASHで、VFR→CFRできない時、
ffmpeg.exeでMKVにコンテナだけ入れ替えてから読み込むといける
原理はよく分からない

mkvはLW-Libavで読み込むから

絶チルBDBOXのエンコを終えて視聴しているんだが、
アニメを30pで制作するとパンやズームがすげぇスムースになるんだな
24fpsか24/30fps混合しか見たことがなかったんで、これ程差が出るとは思わんかった
60fpsがヌルヌルだということは知ってたけども、6フレームの差だけでこんなに変わるとは

まぁ、どっかで繋ぎが破錠したフレームが出てるだろうね

プルダウンしてるのと比べればそりゃ違うだろうけど
24fpsでも24p出力して倍速補間かければパンやズームならスムーズになるよ

>>867
DVDだとコーミングノイズにも影響あるな
同じシリーズで30の種と24/30混合の種死比べると画質が全然違う

再生時にGPU使ってくれたら死ぬほど使いたいのにCPUしか使えないの勿体無さ過ぎて咽び泣く
AEあるのに扱い易すぎてずっとAviutlだわ

aviutlってメモリ2GBでつかえる？4GBは必要？

>>872
ID:/0LGSmd60 と同じやつっぽいけど
グダグダ言ってないでまず使ってみたら

windows7を普通に動かすのに必要なメモリは3GB

>>872
さすがにメモリ2GBじゃ苦しいかなと処理する対象にもよるだろうけど、
そもそもOSだけでかなり消費するし(自分の環境だと最初PCを起動した時にすでに2GB弱使ってる状態)
4GBあればまぁかなりましになる(OS＋2GB超使えるようになる)と思うし、HD解像度でとか高望みしなきゃまぁそこそこ使えるかな
でも変なとこでケチらずメモリは8GBくらいは詰んでおいてもいいと思うけどね、そんな差額があるって訳でもないんだし

どうしても4GBで行きたいのなら、たとえば連続で処理する場合にフリーのめもりーくりーなーも導入して
処理が終わるたび小まめにメモリ使用量を掃除してやるようにするとか工夫が必要になってくる場合もあるかも

win98時代からあったソフトだぞ
メモリなんか1Gなくても動くわ

98時代と10じゃWindows自体が食ってるメモリも違うだろうけどね

メモリがあったところで編集時のシークが速い程度の恩恵しかない
エンコには関係ない

拡張編集はスレッド違いの話題です

時間が延びるだけでそれ以外は関係ないだろうに

>>879
本体機能による切り出しや削除はノーマル編集であって拡張じゃねえよアホか

15年前のPCとかじゃなければまず動くし最低限の機能は使えるでしょ

Pen4 3.06HTで超爆熱エンコ
しかもありえないほどクソ遅い！

Pen4 3.4G現役
2時間物の1080p→720pで丸2日とか

流石にそれ現役はないわー

そもそもPen4マシンとかよく動いてるなと思った。

>>884
丸2日の消費電力を考えたらエンコ用途PCを
i7かRyzen7で確保した方が良さそうな…

そのエンコが手持ちのi7-2600Kなら
何時間ぐらいで終わるか少し気になるけど
面倒いんで試す気までは無いｗ
長めに見積もって3時間ってトコかね

CPU使用率100%で丸2日も動いていることを褒めてあげたいよ。

>>885-888
そろそろ替えたいとこだが愛着ありすぎて手放せん

実稼動時間は年平均で最低5000時間と見積もっても裕に50000時間越え

時間と電気代の無駄だ

RFFフラグが付いたTSを正常に読み込ませるにはどうすればいいのでしょうか？

>>891
「RFFフラグが付いたTSを正常に読み込ませるにはどうすればいいのでしょうか？」でググれ。

なんかチェック付ける

初心者で申し訳ないのですが、1920×1080の新規プロジェクトを開いて、何かファイルを追加すると、横に縮んだように表示されます…
例えば図形オブジェクトの「円」を開くと、明らかに楕円になってたり…
どうすれば解決するでしょうか？

>>894
スレチだから>>1の冒頭を見て移動な。ここで続けないように。
まあどうせ本体側で何らかのリサイズをしてるんだろう。

スレチなんですね。すみませんでした。

ソシャゲに飲み込まれた開発者

2台のSSD（CとDドライブ）を使っているのですが、
Dのデータのエンコードした出力先は同じDの方がいいのですか？
それとも物理的に別のSSDであるCのほうがいいのでしょうか？

お前が保存したい方に出力すりゃいいだろ

何を心配してどちらが良いのか
迷ってる理由を述べよ

ひとつのドライブに同時に読み書きをすると寿命を縮めてしまう
みたいな文句を広大なネットの何処かで読みかじったのだと予想

>>898
Eドライブに保存するのが一番良いよ
イーだけに

>>898
寿命もそうだけど単純に1つのディスクに読みながら書くより、2つのディスクで読み書きを分散したほうが速いって話じゃないの？HDDなら。
SSDなら物理的な稼働が無いから微妙そうだけど。

>>903
マジレスするとHDDだろうが大抵の場合はエンコ処理の方がボトルネックになるから関係ねえよ
無圧縮の超大容量ファイルをaviutlで編集してまた無圧縮で書き出すとかならReadとWriteで
物理的に分散した方が速くなるだろうがそんな極論のケースじゃないだろうし

同じHDDドライブに入ってるアプリの起動は速くなる

mp4の編集で使ってて最近気付いたんだけどカットするために分割するのって映像音声の順で分割した方が待ち時間短い?

>>904
x264guiExみたいな、映像と音声を別々に一時出力して最後にmuxを行うような場合、
mux処理の場所と出力場所は物理的に別のドライブにした方が早いけどね
往々にしてエンコ時間に比べれば大したことの無い差ではあるけど、
数とサイズ次第ではそれなりに差が出てくる

http://egg.2ch.net/test/read.cgi/software/1489813428/