内蔵フィルタLanczosResizeはLanczos3Resizeに精度で劣るらしいけど
LanczosResize使ってYV12でエンコーダに渡すのと
Lanczos3Resizeの前にYUY2にしてエンコードでは
どっちが画質よくなるのだろう?
見比べても俺には違いがわからんと思うので前者でやってますが
>>916 それは少し極端な例だけど、その理解でいいと思う
なるほど
これでようやく+と++を使い分けられるよ
読み込んだソースをそのまま結合するときは++
そこからTrimしたものは+でいいかな
基本的にはそういう感じの使い分けでいいと思うよ。
別ソースを+で繋いでも同期が狂わないなら全て+でいいし、
同期より音の連続性を取りたければ全て+でいけばいいし、
あるいは、とりあえず一切合切+で結合しエンコしたあと、
ある接続部から同期が狂って音ズが起きていたら
その接続を++に変えてsound 出力/muxし直すと言う
柔軟な使い方でもいいんじゃないかな
>>920 Lanczos3Resizeのほうが幸せになれるかも?
色空間変換はあんまり多くないほうがいいけど
俺はDivXやXvidでエンコする場合はYV12でLanczosResizeを使ってます、速いんだもん。
YUY2はhuffyuvやWMV9でエンコするときに・・・
>>917 あれはテンプレなので、順番とか設定とかは、自分なりに変更してください。
>>922 AviSynth.orgなどを見ると、AVI(ソース)の結合は+、Trimの結合は++が推奨されているような印象があります。
>>925 >AviSynth.orgなどを見ると、AVI(ソース)の結合は+、Trimの結合は++が推奨されているような印象があります。
で?その先が重要なわけだが
これまでの説明だとAVIこそ++でTrimは+でかまわないような気がするのだが
>>926 ソース結合の場合は
>>923の考え方で+を使い、
Trimは音を編集した場合やfps変換をしたときのことを考慮して++
そういうことかな?
とりあえずこのスレでの認識が間違ってるということではないよね?
+(UnalignedSplice)
映像□□□□■■■■
音声○○○●●●●
++(AlignedSplice)
映像□□□□■■■■
音声○○○_●●●●
>>924 それではLanczos3Resize使うことにします
なんでWMV9だとYUY2なのか?と思ったらYV12ではインタレース保持エンコできないのか
失敗ファイルたくさん作ってしまうところでしたな…
今ちょうどYV12で処理するように書き換えてから
初のインタレエンコ中だったりするので助かりました
音声と映像がずれるようなソースを使わなきゃいいじゃないか
キャプチャしたソースだと音と映像の長さが微妙に違うことがある
いくつか+でつなげると後ろのほうに行くほど音がずれていくよ
へぼいキャプチャ機器使ってるからじゃないの?
そういう問題ではないから
>Trimは音を編集した場合やfps変換をしたときのことを考慮して++
意味わからん
わかれ
utlとsynthスレにネタ投下。意見きぼん。
http://www.tenchi.ne.jp/~yoko/aviutl/ 今のところちょっと手間かかりますが…。
可変フレームレート出力 for AviUtl
24/30fps混合ソースを適当に可変フレームレート出力する
プラグインセット。
■itvfrプラグイン(逆テレシネ)
AviSynthのITプラグインを改造(AviSynth用)
削除フレームを調べて共有メモリに記録する。
■itvfr対応出力プラグイン
共有メモリに記録されたデータをもとにVFR出力するプラグイン。
・まるも拡張AVI出力改
・wmvout0.3改
の2つを公開
可変フレームレート?
120fpsで出力されるってことか?
wmvout0.3改って書いてるじゃん。
asfコンテナ使って可変フレームレートで出力するんだろ
すんのか?
まるも拡張AVI出力改は120fpsで
wmvout0.3改は可変フレームレートってことのようだな
なんで120fpsなんかにするの?なめらかになるかもしれんけど、
サイズバカでかくなるじゃん。なめらかにするんなら、インタレ
エンコした方がよくないか?
>>943 コピーフレームは再生時に表示されるだけで、データ的にはフラグもってるだけ
映像データじゃないからでかくならない
無論インタレエンコより滑らか
大体現状のAVIやwmvでインタレエンコっていってもなぁ
>>943 釣り? それともmpeg2でしかエンコードした事無い人?
API4のXviD以外のインターレースエンコードはサイズがばかでかく
なるし、PCモニタで見る前提ならインタレエンコした物なんて24fpsの
部分が見れたもんじゃないと思うが。
アニオタはご苦労やのう
947 :
名無しさん@編集中:04/02/09 00:19
いやいや、音楽PVにも24、30、60混在は少なくないよ。
60混在はさすがにすげー少ないと思うぞ
いや分かるけど
60i混在のPVなんてめったに見ないぞ
PCでの再生も考えれば704x480の30i
30iってウケル
>>937 addrangeでCMカット
→itvfr
→NRなど各種フィルタ
→auoencでまるも拡張AVI出力改(wmvout0.3改)で出力
というふうにavisynthだけでできるのかな?
>>953 できなきゃバラバラでやるのと変わりないよね、混合fpsのソースに当たったら試してみるかな。
でもこういうのは自動判定でいい思い出がない・・・
>>954 単純に24fpsにするのでさえ自動は難しいんだから混合だと誤爆しやすいのは仕方ないだろうかと。
aviutl用のtprivtcがほしい
tpr読ませるとRGB変換入っちゃうから
AVS経由じゃだめなん?
tmpgを通してる時点でRGB変換されてると思われ
TMPGEncはRGB32だっけ?
>>961 VFAPIもTMPGEnc自体もRGBオンリー。
んで、tprivtcではフレームの取捨情報しかつかわんから、色空間は関係なし。
avisynthを使ってみたんだけどエンコ速度が変わらないのはなんで
なのか質問したいです。普通にエンコしてもavsファイルを通したのも
終了時間が同じ。MPEG2で長さが1分しかないソースだからでしょうか。
MPEG2DEC3でDVD2AVI1.773のプロジェクトファイルを読み込んでるんですが。
>>963 AVSスクリプトを経由するってだけでエンコ速度が速くなる訳じゃないョ
>>963 フィルタかけた時の時間がAviUtlに比べて遥かに速い。
つまりフィルタをほとんど使って無いのなら、「普通にエンコ」とやらを
した時とさほど変わらないのかもしれないね。
まあ厳密な比較はできないけどAviUtl98から移植したNRと
インターレース解除を使ってできるだけ似た設定にした場合は
Avisynth+VirtualDub等の方が圧倒的に速いと思うよ。
(そんな比較に意味があるとは思えないが)
マシンスペックが高ければ高い程、ソースが短ければ短い程、
当然差は縮まるので、その辺りも考慮すべき。
君はAvisynthを宝島か何かのように考えているのかね?
>>964,965
解説してもらいありがとうございました。
>>967 ちょっと上でも話題になってたけど、色空間も知っとくといいかも
というか知らないと使えるフィルタが限られてくるような・・・
色空間つか、YUY2、YV12、RGBって単語だけ知ってれば
なんとかなると思う(w
Avisynthエラーで大体わかるからね。 エラーが出たら、
YV12toYUY2、ConvertToYUY2を使い分ければモーマンタイ。