Mencoder: Move the noise parameter to the beginning of your script!
 

Please make the following changes to your scripts.

Move the "noise" parameter" to the beginning of your script, before the crop parameter.

If you don't, the noise is inserted on the complete frame. The following noise generated images show what happens:

With this line (pre crop noise):
You get this:
http://www.digitalfaq.com/archives/i.../2004/06/1.png


But with this line (post crop noise):
You get this:
http://www.digitalfaq.com/archives/i.../2004/06/2.png

-kwag

I don't understand why you (and others) changed your way of processing.

Before mencoder we always crop / filters / add borders. Here you do all resizing/borders BEFORE to do any filters. That is why you have noise in the borders when you add it at last pos.

Personally I continue to crop the frame, then filter, then scale/expand it. As I always did :!:

This is my line :
As you can see, the border are in the end. And noise is ONLY on the picture area of the frame (between the crop and the scale but I can also do crop -> scale -> filter). I just tested with 99th like you did to be sure.

:arrow: Let represent the filter chain as an avs script if it can help you.

My line does the same as :

For sure if you put "noise" after "expand" it's like if you add "blockbuster(noise)" after "addborders".

I don't see any surprise in that.

It's no surprice Phil. It's something that normally can't be seen, unless a noise rain is applied, just like I did.
Both MencodeME and PackShot are adding the noise at different places, both before the "crop" command.
The noise should be added before everything, not like we were used to in AviSynth.
Add it at the top level, so when the crop command executes, it will cut everything, including the out-of-bounds noise.

-kwag

And that's wrong for mencoder, because noise IS a filter, so you are injecting noise AFTER crop, which results in global noise on the full frame.

-kwag

Ignore previous post. Noise DOES work fine between crop and expand.
:douh:

:oops:

Okay so it was not a surprise for you too. That is just something that jumped into my eyes at my first usage of mencoder and the surprise is to see that Inc didn't notice that ;-))

Yes, and that is what we always did (and IMHO the logical way of doing). What is the purpose to put noise on a part of the screen that you will cut with the crop ? Losing time :?:

More : remember that your DVD source always have blackborders hard encoded (only 1.78 source don't have, and 4:3 also of course).
So you are adding noise into this borders too ? Why ?

EDIT: too late for the second post ;-)

And I haven't even had a :drink: yet :!: :Drunk:

And I don't even sleep yet.
It's 5:17, the clock is set on 8:00 tomorrow... I think I would go now :-p

See ya.

Hi, I know this was posted before, but I don't know what behaviour to have, so:
1 - Should us aply noise always?
2 - It is for deal with min bitrate?
3 - Always must be 3th value?

Thank you.


--------------------------
Visit: Intermediate guide: MencodeMe/Win32 - Avisynth - MakeAvis by Prodater64.
Visit: KVCD - MencodeMe - Auxiliar Task - KVCD Docking Gate by Prodater64.
Visit: Mencoder scripting with AVSEdit and Guide for Multiple Files by Prodater64.
Visit: Mini-guide quick and easy - DVD to (S)KVCD with MencodeMe by Maurus.
Visit: Mencode-me: a newbie oriented GUI - 0.23 is out! by VMesquita.
--------------------------
http://www.digitalfaq.com/archives/error.gif

I guess I wasn't so off anyway :!:

When using this line:
You get this:

http://www.digitalfaq.com/archives/i.../2004/06/3.png

As you can see, there is still noise in the black bars, which result in extra bitrate lost.

What's the solution :?:
Add a crop to exact film pixels, just before the final expand :D
Like this:
And now you get this :cool:

http://www.digitalfaq.com/archives/i.../2004/06/4.png

Which is the same effect of AddBorders in AviSynth ;)

Comments :cool:

-kwag

Yes.Exactly.3th keeps the MIN bitrate aroud 300Kbps, which is perfect for KVCDs and good enough to keep dark areas DCT Blockless, even on KDVDs ;)

-kwag

I just HAD to post this here :lol:
Here's the complete 46 second clip, weighting at only 5,138KB, at 704x480 using an average bitrate of 905Kbps (with CalcuMatic) to target the movie on one CD-R :D

http://www.kvcd.net/red-planet-1CD-704x480-mencoder.m2v

The configuration file used was this:
And the batch file was this:
Edit: The peak bitrate of that clip is 1,564Kbps :P

-kwag

In Packshot the follwoing order is determinet:

Scale,Crop,Filtering,Expanding! So Theres no noise after expanding! (or I got a mega Bug in Packshots commndline generating 8O )

Phil,

Theres no difference if you first scale, then crop or if you first crop and then scale ... as in avisynth you also do apply gripcrop,Gripsize....Here now you got the effective pixel area only ... then filter, gripborders.

Kwag,

The problem on your sample is that you deal with a2.35:1 source, meas, even in your orig source state you still got black bars on its anamorph input. So an option in Packshot (2.35 yes,no) makes sense as it pre-crops the anamorph image to its effective pixel state!

I think that is it but you are to tired to catch it the first time ;-)

And can you explain to me why you cut in the first place to 672:360 as obviously your picture area is far smaller than this (as you can see on your first picture) ?
Why the hell don't you cut DIRECTLY the film area, and ONLY it, with the first crop ?
This way you won't have ANY border left and you won't have ANY point in them (for sure as they do not exist anymore)

I'm starting to ask myslef if anyone cutted really the film area before as it should always be done :?:

For sure it is :!:

Take a 400x400 pixel square then scale it to 720*576 and crop to 300x300. You obtain a 300x300 square, right ?
Take a 400x400 pixel square, crop it to 300x300 and scale it to 720*576. What do you guess you obtain :?: :?:

Yes : crop THEN scale.
You will never have scale THEN crop ! Do you :?:

I think you all need vacations :-P

So should I change my MencodeMe DVD.fil to

And I think you need more sleep as you dont look whats going on really in Mencalc (and therefore my way and also suggested by the reference link) :P

For shure in the case of first scaling and then cropping a different scaling value! is applied!

The case 720x576 to 352x288:

Mencalc:
scale to 360x288! then crop at the sides by 4 pix which gives you a perfect 352x288!
Fitcd/MS: Crop by 8px to 704x576 and then scale to 352x888

Both do end up in EXACT the same image! With exact the same PAR!

Means after the scale/crop or crop scale process you got the SAME image data, ... then you can apply the filters and then you can addborders/expand if needed :!:

The Problem Kwag explained IS DUE that a 2.35:1 source still comes with black bars and these also WOULDNT be respected by FitCD or MS If you WOULDNT enter the active picture area.
( And thats finally the "quintessence" of the "problem" in here :!: as we "thought" that mencoder could be intelligent to "not affect" the totally black area ;-) :arrow: Theres the error in effective! )

So the Problem above is not mencoder or mencalc routine/way related but Source related.

See my exlanation above as in the way of scale/crop other scale params are used which do ENDUP in the exact same image.

In case of mencalc usage I DO! And NEVER had problems as BEFORE expanding I got the exact same picture data/size/PAR as if I would crop/scale ..... see my explanantion above related to diff sclaing params when first scaling .... do have a look at that reference link, please.
THERE ITS EXPLAINED THAT ALSO THE CASE OF FIRST SCALING THEN CROPPING GIVES YOU ALSO THE CORRECT PICTURE DATA.

Example2 720x576 to 528x576:
Mencalc: scale to 544x576, crop to 528x576 - ready
FitCD/MS: Crop to 704x576, scale to 528x576

... as Mencalc uses in its routines a scaling of mod8 a minimal error could result (In the case above 0.5% maybe, wow :lol: .... but show me a resizing in MS/FitCD where you end up in Error=0%! )


:wink:

He cuts to 672 width AS HE used ovelayed overscan!

Thats cause (still) no active PixelArea Determiantion in mencalc is included :? And if a second crop is applied well ... and IF that second crop doesnt reduce encoding speed ... than this way isnt that "elegant" BUT the quality will be EXACT the same.
You could say "ok .... but Ill stay on my princips" .... ok, no problem but IF (and that would be interesting) a second crop doesnt affect speed/quality ... then I see no problem. As a crop/scale/expand routine would cost a hell more of generating a mathematical resizing calculation ...

(IF a second crop doesnt affect sped/quality) then We are argumenting in here about "shown" commandline cosmetics which do have NOTHING to do with the "real" result as its still correct.
And IF I got the time when everything is implementated well in PAckshot THEN my next project will be to find out that "hell" mathematical routine for crop/sclae/expand.

I was figuring that while I was taking my lunch. I found this idea too crazy to be true but I see you are crazy enought :-)
By "crazy" I mean that you should have screwed up your brain to find the correct formula to apply while the other way was straight to the solution, but I agree with you, the result is the same :-).

That's what I said : it seems I'm the only one that used this area :!:

Since a long time I'm saying that 1.85 DVD have a 16 pixels border and 2.35 a 72 pixels border that must be cropped before any filtering is applied (except for PP or blindPP of course). That's what I do any time and I just figured that any others 'guru' here did the same. I was may be wrong...

Did I put the guilt on mencoder ?

720*576 to 704*576 is 0% (just a crop is done in this case)
720*576 to 352*288 is also 0%.

Those are two example :-). Okay, these are trivials but you just asked for an example :-p

I never saw, and didn't know, that Kwag was just referencing a line generated by mencalc .
That's all the mistake causing my "strong" speech and your "self-defense" response.

For me Kwag was using a line he did by himlsef so I didn't understand why he don't just cut the film area. Now I understand easily that this feature is not implemented (yet ? ;-)) in mencalc !

Its not that crazy at all! Its the simple way it would be done also by the TV!

A 720x576 gots an active pixelarea of 702x576 at PAR 128/117(=1,094)
(I do round these 702 to mod8 704!)

720x576 resized correct to PAR 1:1 square pixels TV state will become:
788x576! And as PAL only gots 768x576 the rest will "be out of bounds", means: Cropped.

Well in Packshot the first of all placed filters (if choosen) is pp .. then a deinterlacer (if choosen) followed by the scaler etc. ;-) So that will not be a "big" problem.
And thats why I told that my next toDo will be 2 option checkboxes (2.35:1 and 1.85:1) for the resizing routine.

[/quote]

And I give you the answer that a simple resize from 720 width to 352 width (without cropping by 8 before) is wrong and will be endup in a wrong AR! Thats a fact.
As 352 width is PAR 128/117 so it bases on an original "cropped to" 704 width ( PAR 128/117 ) ... so you defenitely have only two choices:

a) The MS/FitCD way:
Crop 720 to 704 and scale down to 352

b) Mencalc
Scale 720 to 360 and Crop to 352

same result, same time, same quality ;-)

And as you had a nice lunch Ill give you a nice aperitif:

http://www.uwasa.fi/~f76998/video/co...nversion_table

:)

PS:
No "strong spech" or "self-defense" ;-)

"strong spech" and therfore a resulting "argumentation" as I dont need to defend myself but the little rules as shown in the link above :D

The relaxing thing is that we both know each other a bit "behind the wall" :lol:

I use the Incredible's MenCalc scale, crop and expand values in the script of my KSVCD Express method.

I use also the Kwag advice for the noise=3th before the expand and use also hqdn3d=3:6:2, as you can see in the previous code:


And I obtain allways good aspect ratio and good quality. I hope to be using the correct values... :)

What is yours opinions?

Thanks.


-Maurus

In both crop and expand if you don't want to bother yourself to calcute the coordinates of the upper left corner, you can just use in any case -1:-1 (insteed od 16:16 in your example).

That's always 4 values you won't have to change everytime :-)

Yep, right .....

these calculated values are still results from the time when I did force vertical Macroblock alignment, but in a case of overscan=1 and 352x288/240 this would cause an ugly big border below at 16px height.
So now they will be alignet vertically centered and that also be don by "-1" values in crop and expand as mentioned by Phil.

I use only KSVCD PAL at 480x576 and my overscan factor is 2 (16 pixels), not 1.

This values are obtained in MenCalc. Are they correct?
If no, what are the good values for my PAL KSVCD overscan=2? Not is correct still Mencalc?

The correct values are the sames that I am using, but -1:-1 in the center values instead of 16:16?

How about of position of noise filter?

-Maurus

All filters seem to be in good place IMHO.

If you cose an overscan of 2 wich is 16 than everytime its vertical & horizontal macroblock aligned cause of 16 pix borders added to each side and thats macroblock based.

Your Syntax would be:

Yes, I have this, but with 16:16 as it is in MEncalc. But with 16:16 I'm not see something wrong... The aspect ratio is correct and the overscan seems correct in my tv.

And for 4:3 LetterBoxed, I have this settings:

It's correct?. What are the correct settings here?

Thanks for all.

-Maurus

Why they shouldnt be correct?
Thats what I thought that THIS thread could cause confusing. ;-)
In generall they are totally correct.
And according to black borders they are totally correct for a 1.778:1 Source ... as we deal with overlayed overscan, so only overscan at the sides will be applied as in case of letterboxing already black bars are present on top/bottom.

And the correct replacings to "-1" you can see on the example above.

where at crop/expand the x and the y (from XXX,YYY,x,y) at "-1" do just say "centered".

But I dont know the BIG DEAL about these -1,-1 as you already use MenCalc (copy&paste) and the x,y Settings are correct values, so the effective result will be the same.

Ok, I'm here, but a little late :D
I guess I missed all the fun :lol:
I think Phil was indeed a little tired to understand that I was doing 2 overscan blocks ;)
Anyway, as already has been verified, this last crop (or we can call it a final black "MASK"), will indeed kill any noise or filtering that is out of bounds.
I can't see any speed difference, by adding or removing the "crop" before the final expand.
But even with a noise=3th, which is just a very small value, the sample file size (video stream) was a tad smaller with the final crop.
5,038KB with final crop, 5,042KB without.

-kwag

I'm sorry kwag but no matter what overscan you are doing or not : to not remove the complete black border existing in the source, putting noise into it and finally cut it out with a crop command is nothing but stupid. No offense !

Inc explained that is just a feature not yet implemented but you seems to say that for you this is a normal situation and I can't agree :wink:

Note: You are answering to Inc about speed but for sure the speed will be better if you cut out everything since the begining (as the working area for the filters will be smaller). Even if the speed gain won't be really big actually.

This is NOTHING related to overscan :!:
Please ignore the values I used, and try to focus on the problem.
The problem is that if you don't do the final crop, you have stray noise OUTSIDE the film pixels area. That's a fact :!:
I don't think that's too hard to understand, as you can clearly see it on the last screenshots I posted :roll:
If you don't add the final crop, you will have noise outside the true film pixel area, causing a loss of final quality, because of additional noise being encoded outside the real movie area. I think a screenshot is worth a thousand words, and that's why I posted them.
I also re-created the problem, by encoding with and without the final crop, and verifying that indeed, it's superior quality with the final crop, and the final aspect ratio is also identical.
What's wrong with that :?: At least for my last two test encodes, there was ZERO difference in speed with or without the final "crop".

-kwag

It doesn't :)Elegance is for "taylors". I want results, no matter it they are spartan :lol:
And the results are perfect ;)

-kwag

I think Phil doesnt still meant the "overscan" situation, ...
He told that it would be more senseful if FIRST a cropping would delete all unneeded black parts OR not wanted picture area and then via scale and expand the process as a whole seems more elegant/logic.

Well .. in relation to "cosmetic" I do agree that a second crop is not elegant, BUT till a new resizing routine is written for Mencalc and as Kwag proofed that NO speed or Quality loss is the result, ... I think the solution is ok (for now, ... so I still see your point Phil! ).

I do think there are much more other problems on mencoder so that THIS issue related to 2 times cropping is one of the tyniest problems.

According to speed .... well Even if that 2nd cropping will cause 1/2 fps loss in speed .... I think there are so many users which dont use a CPU optimized build ... and that REALLY causes speed loss.

I really see your Point Phil and its an issue we have to work on (and for shure me on Mencalc) .... but for now ... lets see the thing as a whole and therefore its speed/quality.

So does this mean that we all have to watch a "noisy" black border area :?:
Because I can clearly see it in my TVs :!:
I rather loose 1/2 FPS, and watch a clear picture without any noise outside the film area, than having very dim black bars shown.
Is it only me that can see this effect :roll:
Because it IS clearly visible, specially on a 60" TV set :!:

-kwag

Speed correction!
 

Correction, speed IS FASTER with the final "crop" :!:
Seems that the extra noise on the complete screen does slow down the process, so adding the last crop to mask around the FILM area, does speed up the encoding, at least by 1 to 2 FPS.
Try it :D

-kwag

Another very sensible point in case of MencodeME/Packshot/ManualCommandline - Mencoder usage.

In here many users want "more than fast" the 100% of the potential of that encoder "mencoder".

Lets see it like that .... CCE (and also its fast speed) is EVERYtime used via Avisynth .... and for SHURE avisynth even lets CCE going down to its knees if heavy routines are used. CCE doesnt got an internal resizer so Avisynth is more than needed.

Conclusion ... even if a second crop is used .... the capability of internal resizing of mencoder makes it avs independand and thats causes speed advantage!

So I dont see in here the situation why something should be "stupid" we're doing here .... all our techniques are approaches.

Show me another place where that "mencoder" subject is treaten that intensive as in here ;-)

No matter if some apps are build by me or VM .... seen as a "whole" we in here do made many experiences, build apps ... and so on.

And if I do see the situation ACTUALLY .... Im very happy with the things we "all" already made now and how the things do work. The rest is a matter of time :)

This post was not adressed to someone, its something general do I think.

;-)

Nope that means that I can live for now with that 2nd crop solution as it doesnt hurt ;-)
But I also do see that it "could" be more elegant to find a resizing solution where the picture will be pre-processed more elegant, so the noise also in such a case would be added optimal (like now). But ... I do now have other things in "ToDo" wich are more importend to solve than cosmetics related to a commandline which wouldnt give a final difference ;-) ot adressed to someone! but said as my point of view.
BUT ... as it works and we do not suffer from speed loss or quality (the last one for shure) ... its ok.

Thats what I meant: As both ways give correct outputs ... for now we can "live" with that
;-)

But there IS a final quality difference 8O
I just verified that with the last crop, the final size in a 1-pass is smaller, meaning that on a full 2-pass encode, there are more bits available to the film area, that are not being wasted on the black bars :!: As I just said, there's actually a speed increase.

Do you remember the issue that SansGrip recommended using LegalClip() before and after the filters :?:
Well, this is exactly the same, as the first crop takes care of the initial cropping, and the last crop removes anything that is outside the film area. Just as LegalClip() removed any levels faults that any filter could have introduced.
I see it as a "PRE" and a "POST condition, which indeed is a VERY "elegant" programming practice :) (At least on Eiffel language. Called "Programming by contract" ;) )

-kwag

Only the Mplayer developers in their mailing lists ;)

-kwag