NO
That would lock PackShot to *Windows Only*, rendering it unuseable on other platforms. An edit box.
That's an excelent idea

-kwag

@ Phil

our intention is to do everything using internal mencoder filters so one of the main goals of mencoder is speed which will be lowered when going via Avisynth, no matter if via Avisynth or EVEN if we get avs to be read by mencoder ... as avs means a frameserver is running in backgr. which needs CPU power (you know that Phil but its said here also for the rest).

@ Kwag

I got a better Idea, ... which is more non-complex to the Program/Interface.

Ill add a "generate commandline only" button and one "start encoding", so no matter if in a box or in the batfile ... it would be the same for a user if he wants to enter the commandline, if its safed again, he can just doubleclick the .bat file and go to sleep.

Good Idea? As thsi would keep the GUI more compact.

Other Platforms??? But how you will get Besweet ac3enc azid.dll and all other for audio working on Linux???
(Well maybe well find some other binaries for Linus ,...he he)

@ Audioslave

480x576 is very common and so I will add that!

Yes
Then anyone can edit an tailor the parameters in the batch file

-kwag

GrEaT iDeA

This would help a lot in "fine tweaking" some settings, along with an advanced settings option and a only 1st pass. There are some films that, after first pass, you see that will need to lower/raise quantizers, or lower/raise scplx_mask, or change the B frames factor/offset,... and all this could be tweaked from inside pack-shot, done first pass, seen and if necessary changed.

ink,
if you can give a option to use .avs script for me will be great cos
time to encode don't bore me.....! ....pleeeease
i love to choose filters and his parameters cos i feel that i'm doing "something" !
but only if is possible.

Inc already answered about the besweet problem. I wil ladd other thing : how the encoder deals with pre-existent black borders taht are in the source ?
If you don't want to use external frmaserver, that means that you let the encoder filtering all the picture including the black bars !
What a severe step back For me to change the encoder does not mean to start doing things I WOULD NEVER DO with my current tools !

Beside this, I really do not trust mencoder about cropping (and computing the resize parameters). Moviestacker does it very well and I'll continue to trust it. (btw Inc, with overscan did you implemented into pack-shot ? I generally use 1 and I guess you set it to 2, don't you ?)

Then use MovieStacker to create your correct resize/crop/overscan parameters, and feed them to mencoder

-kwag

@Jorel,
No way Inc is gonna be doing that, Jorel .
We want everything in the encoding to be done really fast .
That way we can have Jorel more time with us in the forum so he can give us a lot of his help and friendship
Cheers

__________________
Rui

As soon as I'll have the edit box I suggested
(note: mencoder implements somethign equivalent to the resizer but does it has somethign correspondig to the "addborder" command ?)

There you CAN CHOOSE settings of wonderful filters ( )

No, lets talk serious...
You can enter in Packshot like Phil said by using MakeAvis.
And thats also a way how to get 480x576, 528x576, 544x576 (same also in ntsc) working as encoding size in Packshot.

The avs into Qenc thing is (IMHO) a trick by nic using libraries/code from makeavis which will be proceeded undercover!
As even Milan is right now not fully ready with his avs/mencoder project.

So the speed is the same as you defenitely still let a avs frameserver running. Ok, its more comfortable to directly go into mencoder using an avs .. but dont expect that much from "more speed" and I think phil can confirm that. As an direct avs import wont get rid of the frameserver itself and thats the one which makes mencoder slower.

Today I had my "graphedit" day as since some time I got problems when playing back my mpegs using software players else than Vdub.

And graphedit gave me a "ligos mpeg splitter" modul and that was it
and I fixed these module priorities using the options in Zoomplayer.

By doing that I could see how avs will be seen by the graph:

AVS .... ... AVI Decompressor .... ... Video Renderer
And I think Makeavis does simply add an AVI header AND a subroutine to the right system modules as shown above. And that maybe is also milans approach so mencoder can see avs to be directly treaten by an mencoder internal avi decompressor.

Hey, the guy is stealing my idea
That's what I've always done since I started testing mencoder
But let me advise you Phil That's basically what Inc. is doing in Packshot
Cheers guys

__________________
Rui

What I see is that noone did answer to my question about black bars. Is that because I reach a hurting point ?

Mencoder filters also these bars (surely changing them from true black to more or less dark gray, and I don't even imagine what "add noise" can do on them ).

If you can live with that, do it. I won't.

EDIT: I just saw the cropdetect function far deep into the documentation. I guess this can quope with the blackborders problem

Simple
How about a scale followed by crop to the exact film pixel area, followed by expand.
That's the equivalent of black borders, because everything outside the film pixels area will be pitch black

http://www.mplayerhq.hu/DOCS/man/en/manpage.html#GENERAL%20ENCODING%20OPTIONS%20(MENCO DER%20ONLY)

-kwag

Now a litle explanation HOW the resizing within packshot is done ..

I did generate TEMPLATES using FitCD (thats the answer to your "I do not bleive in mencoder auto rsizing") these Templates will be used in a mencoder syntax depending on an IF routine based on what will be recognised as input.
And thats why its difficult to add a full resolution bandwith support in case of INDIVIDUAL avi size inputs and therefore they have to be treaten by avisynth and makeavis and in Packshot the "no Resize" choosen!

And exactly theese params are added into the syntax of mencoder:

Here an example only for explaing:

Crop(8,0,704,576) = crop=704:576:8:0

LanczosResize(480,432) = scale=480:432::0:9

Addborders(...) = expand=480:576 .... here the image will be centered and fileld out automatically, but you alos can use expand=480:576:y to set the exact postion ... in case of placing the image á la mod16into the screen.

And for our friend Phil I got something nice here:
http://www.kvcd.net/forum/viewtopic....10637&start=16
(someone should make that thread sticky as it gots its purpose to be updated if someone finds a new filter combination or so. )

That's what I missed. The mencode man's page is quite long

It seems you missed the cropdetect parameters that should replace the gripcrop line we used to have in the scripts

Note: what are the two last parameters on the scale line ?

Cropdetect ONLY outputs log but does not auto crop the image in effective!
(see also the link above I just quoted!)

Also ther is something like "Trim()" but that one in mencoder only handles values in seconds! (if I remember) and not in frames!

But IF 1pass would become one time better, we could use that one to do a btach according to a prediction, means, a batch does continue the generating of several calculated parts to be encoded, the sum of all these encoded m2v slices will be the predicted estimated final size.

AS... you can not use multiple trim points in mencoder, only ONE slice

@ ink...you wrote:
"You can enter in Packshot like Phil said by using MakeAvis."

yes ink, clear but please remove that doubts:

i load the .avs script in vdubmod and got:
decompressor: XviD mpeg-4 codec

and using the file from makeavis and got:
decompressor: ffvfw mpeg-4 codec

it don't change "anything" in the image quality? (matizes(hue),sharpness..?)


@ Correia
you're a joker!
i stay more time here with my friends that with my own family...it's true!

@ Jorel Vdub says "which" avi decompressor is used, in case of avs the graphedit doesnt.

IF you use FFvfwMakeavis .. then that "avi" has to be interpeted by ffvfw cause its a FAKE avi ... as it gots a header but no effective movieinformation but a pointer to that refering avs file wjich inernally STILL needs the ffvfwmpeg4 or Xvid codec to read out the YV12 data.
And if you dont force to another colorspace when generating the avi, then no colorspace conversion etc. will be don, means quality will be the same as if you directly open the avs in vdub.

very clear ink, thanks

Syntax:

Scale=W:H:Interlaced:Chr_Drop:ScalingAlgorythm

If no interlaced image will be scaled, then:
Scale=W:H::Chr_Drop:ScalingAlgorythm
(two doublePoints!)

http://www.kvcd.net/forum/viewtopic....10637&start=16

There it seems I did quote the "old" maunal as now in the log when encoding NO colorpace conversion will be done (well it says so .. that YV12 will be still scaled using YV12)