KWAG, Incredible or Dialhot (or whoever can help)

Just a question about the most recent "Optimal Script" posted 21/10/2003. It seems in another rather lengthy post regarding the MA portion of the script, that the MergeLuma line is not needed, and would produce further blurring since the MA included UnFilter on all the time.

Also there was some discussion as to the parameters for TemporalSoften.

What was the outcome of that post? I was a little lost reading it. Should the MA script be used as it appears in the sticky thread or should MergeLuma be deleted and TemporalSoften settings changed?

Try it as it is posted, and check the result. If it's too blurred, remove the MergeLuma line.

-kwag

For MergeLuma, the actual value is so light that the impact (visually and on the filesize) of the line is not really big. You can remove it if you are more happy without it, that's not really important.

For temporalsoften, I do not remember the discussion you mention but it's the kind of subject Incredible surely introduced. So I let him answer

You can trust the MA. I do not say that there is no way to improve the present script in the temporalsoften line, but , the current script gives awesome results.

Edit: you remove your posts faster than I answer to them

Thanks guys. You are video kings.

KWAG- OT...¿En que parte de P.R. vives?

Phil,

I think you edited e1miran post
I was going to reply, but the post is no longer here

@e1miran,
I'm in San Juan

-kwag

I deleted it because Dialhot had answered the question before I posted.

Not this time . He erased it while I was answeriing
Tht's what we call an efficient forum

No complaints here.

Including the hope, not to be erased ... I do give my opinion on Temporalsoften

Change the last two values of temporalsoften to ...,1,2) or ...15,2) instead of ...1,1) . Its reported that the mode2 (last value in the line) bug is solved and does give an advantage "they say"

According to MergeLuma(Blur(...)) I can only say that this version will shurely MORE blur at even very lowmo scenes compared to the threshold based version of MA before. Cause if NF already becomes 1 the blur of unfilter gets (-2,-2) means already a visible effect like the mergeluma(blur(...)) ... because the blurring process now processes continously! And thats the sense of the new MA: to avoid "oszillating" on Threshold value "edges" like it could happend at the threshold based version of MA before.

Thats why I deleted the MergeLuma(Blur(..)) line .... as blurring already starts that early, but thats only my personal IMHO

Just to add my own one cent to this thread... I noticed the optimal scripts don't bother to deinterlace. I on the other hand, always deinterlace. Perhaps that was why when I tried the MA script it was too slow... interesting..

@cweb

as in here in effective 90% of the encodings are progressive that MA wasnt purposed "in that state" to treat interlaced sources.
So be aware "what" you do interlace as here MANY users think they do need this as its very often really NOT needed (I only point to that NTSC DVD2AVI statistics window issue!).

Even telecined sources do get "restored easely" by adding a telecine().decimate() right after the importline of the MA script.
In case of Hybrid sources do take notice what the decimate() documentation says.

If you got a real interlaced soucre like documentations/concerts etc. you can watch out for Boulders "interlaced MA" version in here where the MA part does work correct on each "field" separately and will be "interleaved" after.

Do look here where you also find a way where you can convert 29.97i to 23.976p
http://www.kvcd.net/forum/viewtopic.php?t=9808


Inc.

Thanks for the tips, incredible..

Yes I do use the fixed (non-MA) script for both interlaced sources (dvb-s pal) and non-interlaced sources (progressive dvd).

What I'm trying tonight with the MA script is a 90's tv show with lots of dancing and singing.. it has lots of movement. I took a small clip and found that it encoded very fast.. it surprised me actually (CQ 89) (also results with deinterlacing and without seemed quite similar, but the deinterlaced sample was smaller), so I was trying on the whole recording but that gave me a terribly low CQ (34).

I'll try the interlaced ma script on this one, thanks...

Look in the interlacing guide I posted above.

Interlaced encodings do need horrible much more bitrate to end up in the same quallity compared to progressive ones.
Thats also why on NTSC 29.97 "real" interlaced sources Sharfis_Brains function makes really sense, maybe the 60 fields per second smoothness wont be anymore but veeeeeery less risk of resulting blocks on movements. I think the relation speaks for itself