yep, I loaded the .avs into VDub and the !!! scene change detected !!! messages were right where they're supposed to be :beard: The encoding time didn't go up either :wink:

ren

Hi.

I'm encoding my DVD of Holy Grail now, and so far so good (with the sample), couldn't believe the quality with the sample I got, no transition problems or variance in brightness problems like I had with red dwarf. This is encoding at 704x576 (pal) no probs.
I'll test the full movie out when it's finished.
Only thing I added to the script for Red-Dwarf was the FieldDeinterlace btw as far as I remember,

Red

Script updated :!:
Some minor tweaks, because of funny behaviour on variables assigned :roll:
(Order of precedence on calling YDifferenceToNext() and YDifferenceFromPrevious() :?: :roll: )
Also, on high speed horizontal movements, sometimes it would detect scene change when in reality is was very high speed action. Now it doesn't "false" on that.

-kwag

Hi Kwag,

Why did you change the "Scene change trigger value" from 1.0 to 10 :?: :oops:

Because before I was dividing the returned value by 16 and using that for the range. Now I divide only for the value to be applied to the mergeluma, and use the returned value for scene change calculations, which is a wider fluctuating range.
And the script was just updated again :!:

-kwag

Hi Kwag,
Did you purposely place this: FrameEvaluate("lf = YDifferenceToNext()") at the very end because when I first load up the script, Virtual Dub says it doesn't know the what is the vaule for "val", but after I move forward a few frames, it knows the valule and no more warning.

That's weird :!:, I don't get that error.
The purpose of the "FrameEvaluate("lf = YDifferenceToNext()" at the end, is to assign the value AFTER all calculations, and retain the variable "lf" for the next iteration (next frame) so I can compare last frame to current frame difference :)

-kwag

Well you know i get an error also if a i load the script with Frame Evaluate or Script Clip im still not sure whether or not is part of the script.
However it works with out it.

Tweak is apparently built into version 2.5:

Tweak

Tweak(clip, float "hue", float "sat", float "bright", float "cont")

This function provides the means to adjust the hue, saturation, brightness, and contrast of a video clip.

Tweak requires YUY2 input. Use ConvertToYUY2() if necessary.

Hue: (-180.0 to +180.0, default 0.0) is used to adjust the color hue of the image. Positive values shift the image towards red. Negative values shift it towards green.

Sat: (0.0 to 10.0, default 1.0) is used to adjust the color saturation of the image. Values above 1.0 increase the saturation. Values below 1.0 reduce the saturation. Use sat=0 to convert to grayscale.

Bright: (-255.0 to 255.0, default 0.0) is used to change the brightness of the image. Positive values increase the brightness. Negative values decrease it.

Cont: (0.0 to 10.0, default 1.0) is used to change the contrast of the image. Values above 1.0 increase the contrast. Values below 1.0 decrease the contrast

Thanks for the tip Smoochie3 :)
Script updated :!: (again!)

I've fixed a LOT of logic errors, and simplified the logic. The line that does most of the magic is this:

ScriptClip("((cf - lf) < scd_trigger) ? (val < MaxTreshold) ? MergeLuma(blur(val)) : MergeLuma(blur(MaxTreshold)) : MergeLuma(blur(1.5))")

Basically the line does this:

(1) If the frame currently being displayed is not a scene change, and the current value is below the mergeluma treshold, then it uses the returned value and applies it to mergeluma. If the value is equal to or greater than the maximum allowed ( 1.58 ), then use the maximum.
(2) If the frame is a scene change, then saturate mergeluma with a max value. This is an interesting experiment :!:, because to the eye, we can't see a fast transition between scene changes (a single frame ), but for the encoder, it's a very heavy penalty. Every scene change causes a loss of compression because of the sharp transition. So what I did is "dampen" the frame after the scene change with a full saturation of mergeluma. The effect will probably be several extra megabytes of space saved per movie 8)
Now, back to encoding :D

-kwag

YEEEEAHHHH :ole:

Previous CQ for the movie "The Foreigner" was 63.97.
New CQ with the current script is 64.256 :mrgreen:

Here's the short sampler made by ToK: www.kvcd.net/06022003-test.mpg

Now we're cooking :mrgreen:

*** Please update your script from the current script ***

Edit: Here's an Extreme scene change detection sample with the latest script: www.kvcd.net/extreme-scenechange.mpg
Same CQ as the previous sample (64.256)

-kwag

I think Tweak works in YV12 now. I'm at work now but sure I tried it last night :?: .

ozjeff99

Yes - Tweak has been built into AviSynth for nearly a year - and it works nicely in YV12. I would however still recommend using ColorYUV - much more flexible.

@kwag:

How about:
...or why not leave out SCD altogether and go back to using YDifferenceFromPrevious to control the Blur? It always maxed out on scene changes anyway.

Have you considered using a non-linear motion->blur function? I wondered if something like a log function or the distance formula would be better, so that blurring would be small for low motion scenes but very quickly ramp up as motion increased. I found a PDF with graphs of some common functions that might help illustrate what I'm on about: here

I'm also not sure if I agree with lf=YDifferenceToNext being at the end of the script, but I havent decided yet so Im certainly not going to post about it before I have :wink:

i quote my own post for special news.

thank you very much to accept my invite sh0dan.
:D

MipSmooth 0.9 released:
http://www.kvcd.net/forum/viewtopic.php?t=4281

:wink:

I have tried it with the new Script... It works fine :wink:

Hi DorvalCS good pickup and a much-valued refinement Latexxx. Thought we might have to start another "Where's Sansgrip" thread. :P

Couple of questions for anyone:

Interesting, both Vdub (through ffvfw codec) and Tmpgenc pick up the script OK but WMP9 inverts it 8O . Anyone else had this prob?

shOdan mentions YUY2 space gives more flexibility however if all filters used work OK, is YV12 better because it is faster?

ozjeff99

No, because the whole idea of the linear adaptation is indeed to produce the sharpest result on slowest motion, and increase the blur in a linear manner as the activity increases. That's exactly what the function does now! But then, right after a scene change, it applies maximum merluma, which is a very heavy blur at that point. It does basically the same as we used blur.That's exactly what it does, but I'm not sure if logarithmically would be better than linear :roll: I'll take a look at the link. Thanks! That's just to read the value of the following frame, and use it as the variable as last frame for comparison on the next iteration. At least, that's the way I was able to make it work!. If you add debugging variables as subtitles, you can see the changes as you step frames, and you see the differences between cf and lf.

-kwag

Kwag and the rest of you genius's are AWESOME!!! :bugeyes:

Keep it up and pretty soon we'll be able to put a whole movie on my 256mb Thumb Drive.

Hey I realize this is just the beginning, but if this is the beginning then I can't wait until it reaches full maturity. Yeah Baby, Yeah!

Racer99

If you have a Pocket PC, you can put "The Matrix" on one 128MB flash card :!:, and it looks pretty damn good on the iPaq screen :D
I did that a long time ago, without any of the latest techniques, so now it would probably look even better 8)

-kwag