MenCalc: a resizing calculator for Mencoder
 

http://www.digitalfaq.com/archives/i.../2004/05/7.gif

mencalc1.1b - beta state!

All resizings do refer to the PAR respected calculation method:
http://www.uwasa.fi/~f76998/video/co...nversion_table
Second: The overscan now is a resized overscan.

I rounded the active Pixel source/dest areas to mod8, means a very correct pal active pixel size would be 702 and not 704 ... but 704 is at least mod8.

All Inputs will be parsed in their resolution if they do confirm to a legal fullPAL/NTSC or mpeg or ITU resolution (i.E. 720x576, 768x576, 352x288, 704x480,352x480 etc etc etc), means anything else will be seen as PAR 1:1 (i.E. mpeg4).

The old mencalc1.01.0 Version (just in case)

;-)

Inc.

------------------------------------

1.1b
Beta State!
Routines are totally rewritten. Now the usual way of first cropping and then resizing will be proceeded. Overscan now is no longer overlayed but resized, also the oportunity of determining an active Moviearea has been added - tweakable Xposition and Yposition parameters will be available soon.

1.01.0
Routine is rewritten, where now also all non PAR 1:1 avis are supported, means still 16:9 state Avis via DVD2AVI/AVISynth/Makeavis processes, and for shure common capture resolutions in NTSC and PAL.
Changing in some cases from vertical macroblock aligning to vertical centered alignment - especially when doing 352x288/240 which at macroblock vertic. alignment that caused a 16px sized border at the bottom! That's fixed now.
As I got some PM about it would be less confusing that for instance a 720x576/480 to 480x576/480 resizing should still come out as full width without 8px out of TV bounds area ... this has been changed.

Now, both, the Mpeg- AND the PAR1:1 Avi- source resizing ways are done by the PAR based resizing method taken from that reference link http://www.uwasa.fi/~f76998/video/co...nversion_table


1.00.4 05/22/2004 18:35h CET

Fixed a cropping issue when resizing VOB/mpeg1/2 sources at NTSC mode.

Great Inc :!: ,
downloaded and tested :wink: OK.

... I know that you know, just:
- It would be great a "Copy to clipboard" button, to paste then in our hand-made command-lines.
- It would be nice it was inside PackShot 1.02.4 :lol: :lol: (OK,OK, maybe in v 1.02.5).

Very nice, clean, useful, ... tool
:wink:

Great inc, I think you can read my thoughts. :wink:

Re: MenCalc ... a resizing calculator for Mencoder
 

:oops:
Almost did it pal :lol:
And since your explanation on that issue is so clean, I have no bug report for now.
Just as digi.doc I'd like a copy paste button on it, that's just about it :)
Thanks buddy

Re: MenCalc ... a resizing calculator for Mencoder
 

"but FitCD gives me diff. outputs".... and MovieStacker too....
i told you, i told you....well i was trying but my english don't help me in that thread!!! :lol: :lol:

thanks for MenCalc ink!
:wink:

Thats why "that" little Commandlinewindow in the appl. is not "read only".
So just go in it select everything, :arrow: right mousetab ... and "copy".

8)

Jore and ALL,

I do NOT say that my claculator is 10000% correct or EVEN that its more correct than fitCD/Moviestacker.

But I wrote that line above cause many people do just look at resulted values and you have to think about it like the case that FitCD does "resized" overscan only, where Moviestacker offers both.

So it CAN be that maybe a 1-3px difference is given. So in that case .... well :lol:

But if you encounter a real bug, shure let me know!

:!: Btw I did found a bug in case of NTSC dvd resizing to lower sizes ... hold on.

:)
... we know. Is that difficult to include the button? (I ask from real ignorance :oops: )

And, what about incluing it in Pack-Shot (along with support for those resolutions...)? Sure you already thought this...

hey ink, 10000% correct "seems" too much! :lol:

don't misunderstand me my friend see that scripts from:
source 720x480 toy story2 (4:3) ---> target 720x480

BicubicResize(720, 478, 0, 0.6, 0, 1, 720, 478)# from moviestacker
AddBorders(0, 1, 0, 1)# from moviestacker

Crop(0,0,720,480)# from Fitcd

-vf scale=720:480::0:9,crop=704:480:8:0,expand=720:480 :8:0
from MenCalc

compare the scripts....that is what i'm (and was) trying to show ink!
:wink:

edited>
i forgot......MenCalc and PackShot deserve an " cool icons" !
:idea:

So what?? Everything is ok!

As at even 720 width encoding the active pixel area on Tv is 704.
(if you would be totally right it would be in case of NTSC 710, means 3+3pixels wrong in MY calculator ... but 3pix I think thats really ok if you think about it that even MS or FITcd do generate scripts where on the right side the "error" report almost never shows "Error 0%").

So IMHO it makes no sense to feed the encoder with information which would be NEVER seen, even on a TV set which "would have" no overscan!

Cause the 720 would get out of the offset of 640px ntsc tv width area finally!

In your case Jore, you just left the stream "as it is", means if your source gots an anamorph state, then that one will be preserved! So a 16:9 flag will be added to your encoding - and afterwards your DVD STA will recognise that flag and squeeze the height to 360px so egg-heads wont be possible. Rest of hight to match the 480 will be filled with black bars top/bottom.

So IF you still see eggheads on your tv when feeding the DVD STA with an anamorph stream .... do look in the options of your DVD STA where you can set the "Letterbox" option so the 16:9 input will be resized to your 4:3 tvset!

BUT ... IF you do encode to 352x480 or 352x288 YOU HAVE TO SET "16:9 to 4:3 Letterboxed" or in moviestacker source= anamorph, target = not!
;-) As anamorph state is not supported in 352 width , no matter if 352x480, 352x576, 352x240, 352x288 :!:



----------------------

New MenCalc link is updated (1.00.4)

I'm getting this error -

Option vf: Error while parsing scale parameter interlaced (interlaced)

I'm using mencoder:
MEncoder dev-CVS-040506-06:00-3.3.1 (C) 2000-2004 MPlayer Team

Any ideas?

Fixed! :wink:

thanks for hints ink but you don't saw the point:
MovieStacker give me that script
BicubicResize(720, 478, 0, 0.6, 0, 1, 720, 478)# from moviestacker
AddBorders(0, 1, 0, 1)# from moviestacker
:arrow: but it don't open in vdub!!!
i get "avisynth open failure...Evaluate: unrecognized exception" :!: 8O
this is what i call as "wrong information", understand me now?

Thanks Inc., you're the greatest (a little purr goes your way!)

I'll give it a try.

<edit> : YES !!: <edit>
PURRRRRRR!!!!

Line makes no sense as...:

- first resizing to 720x478 (out of 720x480)
- then cropping by "1"px to a STILL! "720x478" area ... that cant be! As if you crop, then .. well then there will be something cropped which results in LESS size then before! And this isnt the case in here.

And thats the thing I meant.
Moviestacker (with respect to muaddib) wants to resize from 480 height to 478 height! ... even if it would be right, it makes no sense AS tell me a person who will recognis a wrong AR of 1or2 px!
But by beeing that mega exact that line above SCALES to 478, means :arrow: taking a) valuable CPU power and b) the most important: THERE WILL BE AN INTERPOLATION by a scaling which causes blurring! Means the image even its mega correct resized (if its really?!) does have a worse image quality afterwards. :arrow: See my point ? ;-)

:)
Inc.

PS: Jorel, I checked that in Moviestacker AND FitCD ....
HOW can it be that these apps. do resize to 478 ?????

No matter which "round to" at height resizing (2,4,8,16,32) still 480 do come out!
So I do hope you did set at "resize" a "round to" value to 16 (block optimized) .. as we do resize to mod16 values!! = Macroblock orientated!
( I talked a time ago with shh why he calls a round to 16 "block optimised" as 16 is macroblock optimised.?!)

yes, i saw(a long days) the point and you too but i could not wrote this all so clear!!!(thanks GOD!)
8) 8) 8) :encore: ink, you're a teacher!

thanks for new version!
:D

Great work, Inc. :wink: 8)

Is it that hard to just select it with the mouse, and type "CTRL+C" :?:
That's all it takes to put it on the clipboard :roll:

-kwag

"right click" ---> select all ---> "right click" ---> copy ....is in the clipboard!
very easy :!:
:wink:

Thanks Inc for this excellent Calc tool. :)

Well the routine at the beginning was purposed for Packshot, ... but I did implementate it in a standalone appl. as there has been asked for ;-)

8O
No Kwag, it isn't hard.
I think Inc took the comment as it was intended to be.
Every comment I make is to be helpful.
If it doesn't help, the programmer just forget it.
That's all.
:roll:

The only little problem is ... coding needs time and if every little "cosmetic" is respected now, the things will take more and more time to develope, and the main intention of this calc routine was purposed as a developement for Packshot. This result as Standalone App. was just a little bonbon for Commandline Programmers .
:)

So I put my focus yesterday on a BitrateCalculation routine (see my "Developement status"-Posting in the "Packshot suggestions" Thread.

Great, great, great :D .
You have extrasensorial powers, man 8O :o .
Yesterday, while I was loading a big d2v in new calcumatic, with 2 films to be PackShot-Menc-KDVDed, and trying to put in audio 0 kbps, or 0 audio tracks (as I already have my ac3 tracks, wanted calcumatic not to consider audio), I thought: It would be great to have a new PackShotBitrateCalc... and here you are :!: .
First suggestion for your still not delivered tool ( :roll: :lol: ): it would be nice you could input manually the filesize of your ac3 tracks.

This one will be the part of Packshots window where AVGbitrate will be calculated.
http://home.arcor.de/packshot/bitratecalculator.exe
The liitle avg Output field will be the one which already exists in packshot.
No matter what you or where you do enter values, the calculation result bases on the the sum of everything which you do input in the fields.

You can set Audio kbs! And when entering the right length of the movie the exact correct size in MBs of audio internally will be calculated, as anyway you have to know and enter the movie source length! So manual MB size input is not needed, and would cause MORE inputfileds where user will get confused.

Downloaded and "tasted",
- What does overheat stand for?.
- Is automatically calculated the mux overhead for each film? (sorry, maybe this is the answer to my previous question :oops: )
- Did you include a minimum amount of MB for authoring later? (don't know exactly what's needed. I think that with DVDlab I used about 180 MB).

I selected 2 films, 120 min each, with audio track nº1 384 kbps and audio track nº2 192 kbps... and I got avg 1400... maybe too low.
Does it any difference if audio tracks are 5.1 ch or 2 ch? (in file size I mean).

I'll do more tests and post results (maybe better I'll open a new thread, if you think it worth).

Great, another toy to play with... :wink:

Uops, I thought I already fixed that mistyping 8) Done!

Well the overhead should include these needed MBs for authoring, as I did a test when using an other claculator and the final avg matches! Also I did comparisons with CQmatic and almost the same comes out, ... ok Kwag applied a little more "safe" space if I do see it right. But internally this routine above uses the same calculation sheme like used in MencodeME... as Vmesquita gave me the formula.
As said, I did a compraison with cqmatic and even there less bits in avg came out.

And, what counts is Bitrate and not if its an 5.1 or 2.0 Encoding! ;-)

Heres the importand part of the code and below you can see the formula:

Regarding overhead, I've noticed that you can assume that a DVD is 4350 MB in size. I've used it for 2-3 movies per disc and also with TV series, 6-8 episodes per disc and it's always been on the spot, leaving only a tiny bit unused.

Hi Inc,

Check your calculations, because the resulting average is way higher than what's supposed to be.
For example, for one 120 minute movie with audio at 112Kbps on one DVD-5, the average bitrate is 4897.9 (without any overhead).
But Mencalc gives me 5109, which is too high.

-kwag

Inc,
I've revised your post slightly, so I may be wrong. But I used your calculator, and made calculations "by hand", and get different values. I think one error may be in audio calculation:
I don't think it's the same:
as
I do get different results. I think the first one is the correct.
But this just gives an error if using 2 or 3 films. I don't know where may be the error Kwag is getting with 1 film.

I dont know Kwag, but If using Fit2disk, enabling everything like VOb muxing, DVD authoring and all we do need to be included in the claculation...

... at 1movie at 120mins incl. 112kbit audio... in Fit2disk 5006 do come out!

... "Bitratecalculator", means my engine outputs 5005 (incl 90mb overhhead)

:?:

Also ... that routine is exactly the same as in mencodeMe , as its the claculation of VMesquita.
Therefore a DVD5 Size of 4482 is used in the claculation .... or is that wrong

And to your point Digi Doc .... thats a thought wich could be true!
Kwag what do you think about it??

I think that the "way" the formula is is correct, as I do get in Calcumatic the same relation if 2 or three movies are selected and then 2 or 3 audios!

Well "his" avg is smaller seen as a whole (and thats why quoted my DVD Media MBs above so he can see if its correct) but in relation the output if more than one movie is choosen is the same

Perhaps kwag using CalcuMatic for his bitrate an he set DVD-5 to 4300 MB and you to 4482? :?:

All with DVD mux overhead included tested:

- movie 1= 120
- audio 1 =112 kbit

CQ Matic = 4869.4
mine = 5005



- movie 1= 120
- movie 2= 120
- audio 1 =112 kbit
- audio 2 =112 kbit

CQ Matic = 2252.5
mine = 2334



- movie 1= 120
- movie 2= 120
- movie 3= 120
- audio 1 =112 kbit
- audio 2 =112 kbit
- audio 3 =112 kbit


CQ Matic = 1305.5
mine = 1369




:?:

You see digiDoc. at least the relation of multiple movies/audio seem to be correct .... now Kwag should tell me which Mediasize/overhead he uses as I think there we're different.

Kwag: To me it seems you use a DVD media size of 4400 minus Overhead??

He's using 4300 MBs! :wink:

Nope!
Not in his version 1.09a!

Sorry, I haven't seen. :oops: :D

BTW: This calculator is NOT "MenCalc " :lol:
"MenCalc" is just the resizing engine.

That Bitratecalculator got no name as it wasnt purposed as Standalone Appl., Its just the Part which will be used in Packshot :wink:
As already many BitrateClaculators as Standalone appl. are out ;-)

@Encoder Master & incredible
Off-topic
I was just wondering if you're brothers? I compared your avatars, and damn you look alike! :lol:

I hope for you that avatars aren't always the photography of the user :-)

@Dialhot
:lol: :lol: :lol: