Well, I never understood all these color spaces correctly. :oops:

OK. If I understand you (?), this should happen when you try to use any VDub filters with AviSynch. Well, MovieStacker do not support any VDub filters... but if VDub filters support only RGB input, shouldn't we use a ConvertToRGB instead of ConvertToYUY2?

Or maybe you are trying to use the AVS script as input for VDub. If this is true, and as you said VDub only supports RGB input, then just a ConvertToRGB at the end of the script should resolve the problem. Although I never needed “ConvertToRGB” to open the AVS in VDub and use its filters.

Yep... I saw this one. I'll fix it.

Well, I never used CCE and I don't know what an ECL look like.
But can't CCE open an AVS script as input? 8O 8O 8O

:mrgreen: :mrgreen: :mrgreen:

Re: AVIsynth and *.DLL versoin info..
 

8O v1.0 beta!!!!! 8O
Oh please, go get 2.07 NOW!! :D
here: http://sourceforge.net/project/showf...group_id=57023

I don't know, but maybe this is the reason you have to change from one color space to another. :roll:
Go update your AviSynch... and tell us if this fix your problem. :wink:

Hi mauddib..

Thanks. :)

I'll check it out.
-vhelp

Sampler frames error
 

Hi muaddib,

Please check your "Sampler" parameter generation routine. I have set "Use frame rate" and "Use movie time in minutes" on the "Filter settings", but it only works on the current/last movie (.d2v) I have loaded. Any .d2v that I open later, retains the last settings. Even if I exit MovieStacker and run it again.

-kwag

Hi kwag,

I'm not sure if I understand what you mean, but I found 2 bugs in the sampler dialog.

First the labels text was inverted :oops: :mrgreen: . In front of the "Number of samples" should be the "Use movie time in minutes" label, and in front of "Length of each sample" should be the "Use frame rate" label.
They are working right, just the text is inverted.

Second (I think that's what you said), when you check "use movie time" and "use frame rate", these information are not being updated when you load a different source.

Both bugs are now corrected. :wink:
Thanks for pointing that out!

ok mauddib..

R U ready for my 2 cents ??

Be right back, just getting last minute notes together.

I hope you and Kwag are ready for some late-night cramming !!

..or not, pending your answer(s)

-vhelp

hay mauddib..

Well, I did say I would get back to ya..

sorry for not getting back to you sooner. Had too many things going
on, plus being too lazy and all and last, I've ben suffering a few of
my OWN pc crashing and headackes as well :(

Anyways.. here is something I've noticed when dealing w/ LOTS of WS
movies (though mostly DVD, captured sources in WS prove the same)

The short..
When I am preparing a WS movie (DVD or captured off air) and proceed to
work with the Letterbox or cropping top and bottom black bars, etc.
I notice that the MAJORITY of all the sources I work with do NOT have
EQUAL Letterboxing or black bars in them. So, my quesiton to you is..

in MStacker, is this/there any compensation to this ??
I don't think that there is, becase this is a MANUAL eye cathing thing.

I would think, that this would mess up the final AR or throw off the
AR and consiquently, taint the quality by at least some degree !! 8O !!

Don't you agree ??

Do I hear you saying, " give me some examples ?? "

Perhaps a list should be create for future encodings, using MStacker
would be a feature to add in ??
It could be from a .txt file, based on your Movie title. Then, MStacker
could count for this in it's final .AVS script. Same for Snolly's
SwiftAVS (if his require any cropping features) (if you're listening
Snolly pal.

So, lets say you have a DB list of CROP values for Movies, and using a
dropdown list box and selecting your movie, ie, Dogma 53x57
Your MStacker app would compensate for the Movies incorrect black bars
and produce an .AVS script with corrected black bars (or letterbox)

What do you think ?? Have you overlooked this ?? I think you have 8O he he..

Well, here's what I do, when I have an un-even pair of boarders, I just
basically (roughly speaking) continue my cropping, then I add (or insert)
a scanline, and then, when I feed into TMPG, I verify that the boarders
are NOW equal, and if so, I incode.

Surely this IS effecting the encoding to some degree. Surely !!
If I understand correctly ( and please do "correct" me if I'm wrong he he.. )
that the encoding is based on 16 pixel blocks 8O and if a black boarder is
not equal, and the 16 pixel block is overlaping another block that has
some other color other than black (not evenly) then, wouldn't that have
some tainting in quality ?? ?? ?? 8O
I mean, we're talking about maximizing pixel block encoding, right ??
If you asked me, if we could calculate a fair and EQUAL amount of black
bar between top and bottom using an 16x16 pixel block (top and bottom)
and leave whatever's left of 16x16 block black bar from where the actual
picture start on a 16x16 pixel block boundary, we could fine tune even
more quality with this technique. This has ben on my mind for many months
now, but I couldn't get it out right. Hopefully, you and perhaps Kwag
are understanding this issue clearly enough, to warrant an INVESTIGATION !!
And, as I understand it, Kwag LOVES, LOVES this stuff !! he he..
And, He's ALWAYS looking for ANYTHING, ANYTHING that will give him an
edge !! right ?? he he..

Weather small or not, I'm sure that those that are COUNTING their bits
per cd would appreciate this little tid-bit and perhaps some testing may
be in order to see where this could benefit us (if fixed) in our final
encode !! I think that in theory, the above is true. So, Kwag..
if you're listing, you might want something more :) fun :) to keep you
busy, as I know you just LOVE, LOVE having something interesting to test
out.. even if its that LAST bit of UMFF to put more on a CDR or to add
quality too.

Now, depending upon your answer(s) to my lenghty notes above, if this turns
out to be an issue, then I do hope you can find time to include these
fixes in your next update.

Well, no matter what, it's something to look into anyways. So, please
have fun.

Well, I'm busy jugling many things on my list, and it's Friday (TGIF)
and I'm happily cramming away he he..

-vhelp
PS 1: get your PC fixed!! I just upgrated my ram w/ ad'nL 256MB (now 524mb)
PS 2: AND, i'm working on getting my next Analog Capture card (Osprey) for
testing (I have some hunches to work out)

Hi vhelp,

Now it's my turn to say sorry for not getting back to you sooner.
Don't go thinking that I forgot you. I was just suffering from more PC crashes.
Now was my 400W PSU that smoked out! I just can't believe it! :grr1: :evil:

Well it's 4:00am and my wife is probably waiting me with a knife! 8O
I want to read your post carefully to see if I can understand it all. :roll:
Tomorrow I will answer you... (well, I hope so :wink: )

cya!

hi mauddib..

Ok.

Take your time. I know I'm not crazy w/ the top and bottom bars.

They ARE off in many DVD movies and that includes TV captures too.

I'm figuring around the 16x16 blocks. I hope that when you read this,
and re-read it, think about it. ok ??

If you got a 16x16 block that is completely black (ie, a portion of your
black bar) and the encoder sees this as it encodes, the encoding process
will (in short) encode this 16x16 blocks (or areas) effeciantly, but WHAT IF
A 16x16 BLOCK (going accross, left to right) is mixed w/ some black and
then partially w/ the video ?? 8O 8O Doesn't that mess up on the quality
to SOME degree ?? It must.

Kwag.. I'm sure you can piece together the above, and probably in
better words than me, but surely you understand what I'm getting at ??

Well, it's gettng late forme too. It's 3:14am here in NY, and my eyes are
weighing heavily.

See you all tomorrow - TGIF..
-vhelp

Hi vhelp,

Here we go! :D
I’m not sure if I completely understand every thing that you said, but I will try to answer you. Let’s go step by step…

Yes, that’s true. Many movies have encoded top/bottom black bars and frequently these black bars are not exactly the same size. This will make the movie shift two or three pixels up or down. Not a big deal.
I really don’t know why these black bars are there in the beginning. In my opinion, if a movie is anamorphic then should be NO black bars at all!


Sure there is! Well, sort of…
You have two ways to deal with these encoded black bars.
One is manual and other is automatic. Here they are:

1) You can manually (VDub or TMPG or next version of MovieStacker :wink: ) find the size of the frame (without the black bars) and set the Film Pixel option in MovieStacker. This way MovieStacker will crop the black bars and leave you with just the film pixels.

2) You can use GripFit to automatically crop the black bars. GripCrop will analyze your source, find if there are any black bars and cut them off, leaving you with just the film pixels.


No. With MovieStacker the AR will always be correct! 8)
Let’s analyze all the different ways we have to do this.

1) If you leave the encoded black bars in the frame, MovieStacker will “see” this frame (with black bars) as if it was only film pixels. The black bars will be resized together with the film. MovieStacker will do this taking care of the correct AR, adding the correct amount of black borders to “fill” the frame properly.

2) If you manually set the film pixels, MovieStacker will also calculate the crop values together with the black borders addition (base on the new cropped frame) to keep the correct AR.

3) If you use GripFit, MovieStacker will not deal with the AR, but GripCrop, GripSize and GripBorders will with keep the correct AR for you.

As you see, the AR is maintained in every way you do it.
Many times the AR is not 100% accurate, but you can see the error margin in the “Aspect Ratio” little square. This error occurs essentially because of the “round to” sliders and the “crop method” you choose. These options interfere in the AR and in the way MovieStacker will calculate the crop and resize.


As you said, it surely affects the encoding to some degree.
The big question here is how much it will affect the encoding :?:
I had asked it to my self a thousand times.
Will the encode suffer if I crop in the middle of a macro block :?:
Well, I think so, but will it be significant that I need to worry about :?:
I don’t know… but anyway, MovieStacker can take care of it, and do every thing you suggested above! :mrgreen:

If you set all the “round to” sliders in the “mpeg resize” section to 16, you will have all the black borders and the film area based on 16 pixels blocks. And if you set the crop method to accurate, MovieStacker will do all that assuring the correct aspect ratio!

So if what you wanna do is crop the incorrect encoded borders, keep the film area based on the original 16 pixels blocks, add black borders that are also based on 16 pixels blocks and do all this keeping the most possible correct aspect ratio… MovieStacker already do it for you! 8)

I think the only drawback of setting MovieStacker the way I said, is that you probably will have to crop more film pixels then you want… that’s the price you have to pay.

That’s why I ask you (kwag and everyone else) again:
How much will it affect the encode if I do not keep everything based on 16 pixels block? :roll:
Will the quality be improved so it worth the price of cutting off film pixels? :roll: