More tests have to be done. The screenshots above were done both with the same CQ value of 62.276. The file size for both samples is almost the same. I didn't use any noise filters. Just this:

-kwag

For my samples (528x480, no noise) the file size difference was about 2mb :?. Strange.

Maybe the material does make a difference :?:
I'm currently encoding a sample of "The sum of all fears" with the BETA-1. I'll also encode the sample with the original matrix. I'll let you know how much difference there is.

-kwag

That's what I'm thinking. Resident Evil is very high-motion.

Here's what I'm doing to zero in on CQ value faster. The way I do it in CQ_VBR doesn't work correctly with CQ, and takes many many tries to hit the target. That is New_CQ_Value=(Wanted_Size/Sample_Size) * Current_CQ_Value
So this is what I do for CQ:
Run a sample session. Apply the formula above to correct CQ value. Note the new CQ value and run a second sample. Apply the formula again, and note the new CQ value correction . Then use New_CQ_Value (Last_CQ_Value + Current_CQ_Value ) / 2 ) and repeat.
This way I make less tries and hit the target faster :wink:

-kwag

...with the new, corrected value?

I'm not sure what you mean by "new", "last" and "current" here. Could you post an example?

Just run a sample. Use the formula and get a CQ correction. Store that on left brain :wink: .
Run another sample, use formula to get new CQ value. Store that on right brain 8O.
Now add both values and divide by 2. That's your new CQ value which is exactly between your last two CQ values. Next runs will be half of half of half, and you should get your target in 3 or 4 sample runs max.

-kwag

Ahhhh... I was reading what you posted as "new CQ value multipled by ..." instead of "new CQ value equals ..." ;).

:cyclops: */+- :cyclops: :mrgreen:

@SansGrip,

I tried Crop using VirtualDub -->Video->Filters->Add->null transform
and then clicking the "Cropping button" to bring up the cropping screen.
This was even better than Tmpgenc. Then I used FitCD to resize,
get the TV-overscan and correct aspect ratio. It all worked GREAT!!! :D
Thanks for your help.

@Kwag,

Tried the file prediction formula for CQ and this time I achieved 0%
difference between test file and predicted file size in 4 passes. 8O
This used to take 8 to 12 passes. Bless you Kwag :D I'm going
to wait until the Q-Matrix development is stable, so I used the
standard Q-Matrix for now. Seems you and SansGrip are still testing
and changing it. :)

-black prince

You're now doing it exactly how I do it :). It's pretty easy, but I still wish FitCD could determine the borders automatically :D.

Yeah! If just FitCD had a crop dialog like Vdub... That would be nice. :roll:
I'll search if I can find a delphi plugin that can read a dv2 file (or just extract some frames snapshots). :wink:

If Delphi can call external DLLs it wouldn't be hard to write a DLL to open an Avisynth script (or AVI) and display a frame for cropping. Reading from a d2v would be harder.

I guess delphi do can call external dlls! I just have to confirm that.
But it would be better if we can also do it from a d2v, cause that's what we usually use as the source file in FitCD.

I believe mpeg2dec can be called as a regular DLL, not just an Avisynth filter. If it can, reading d2v shouldn't be too difficult.

If it can, try this with it. Everything you need should be in the zip; it's just a question of translating the C header into something Delphi can work with.

In C, I would call it like this:

It doesn't matter what filename you put at the moment: it doesn't actually open any files. It just displays a message box (to let you know it worked) and then fills in the CROPINFO structure with pretend values:

ci.left = ci.right = 8
ci.top = ci.bottom = 16
ci.width = 704
ci.height = 448

So to test the DLL work out how to call it from the FitCD source then, on return, check the values in the structure match the above.

If you can get FitCD calling this DLL when a button is pressed, I'll make it actually do something ;).

any solution or resolution for matrix,cq or cq vbr......???
:)

something?

:ideasmiley:

Here's what I use, right now:

Old matrix (I find the new ones increase the file size too much :()
New GOP
For LBR, CQ_VBR without noise
For 352x240 and 352x480, CQ_VBR with noise
For 528x480 and above, CQ without noise

"Old matrix (I find the new ones increase the file size too much :()"
"For LBR, CQ_VBR without noise"
yes i get the same result in tests.


thank you! :D

Hi SansGrip,

Even though the new matrix ( BETA-1 ) increases the file size, did you compare the quality produced to the old matrix, by adjusting the CQ to match file sizes on both encodes :?:
At least on the tests I've made, the quality produced was slightly better on low light levels with the BETA-1 matrix. Did you notice that, or were your results different :?:

-kwag

Yep, and you're right: there's definitely slightly less blockiness in low-freq areas. However, I found that matched by a corresponding increase in macroblocks during high-motion scenes :(.

Did you use MAX=2,300 or MAX=2,500 :?:
I know it's not that much, but I'm using 2,500 even on the x3. The mods. on the matrix shouldn't affect high frequency areas at all 8O
Even on the movie I just watched, "Sum of all fears", the fire and explosions were blockless :!: I'll do more tests again with the matrixes on very high action scenes. Maybe I missed something :roll:

-kwag

I use 2500 for x3, but I do have to use a min of 400 with my player. That shouldn't make much difference, though.

They won't affect high-freq areas, but by decreasing the CQ level you're forcing the encoder to compromise somewhere, and on the tests I did (admittedly it was only a couple -- I should do more) that was manifested as an increase in macroblocks.

Strange. I noticed you posted your script elsewhere, so I'll double-check I'm not doing anything foolish. Could you post the beta-1 matrix again so I can make sure I'm using the correct version?

You bet :D
Here you go:

Well, I tried to make delphi calls your dll without success. But I know that it's just a matter of syntax. Maybe someone can help us... Here is what I did:

First I declared the CROPINFO type, that's pretty much like in C:
Before I can call your function I need to declare it as an external (please, check if the types are corrects):
I don't remember what is the & before ci parameter in C. But I assumed that it is just there to make the changes in the ci possible. I mean, the ci parameter is passed as a variable and not as a value. Is that right?

So, I called it like you said:
The program compiles with no errors, but when I press the button that calls your procedure, an error message pops up:
Access violation at address 77D48C2C in module 'user32.dll'. Read off address 00000008.
I never called external dlls in delphi, and I don't know what I'm doing wrong... :(
Any ideas? (anyone?)

That looks right, assuming Delphi uses the same size integers as the DLL (32-bit).

I've not used Pascal in a long long time, so I don't remember if those types are correct. I have vague memories that Pascal considers "string" to be a byte containing the length followed by the actual text. In C, a string is the actual text followed by a zero byte. You need to check this.

Also note that the function returns a "BOOL" type. I'm not sure how you specify return types in Pascal.

The & operator means "address of", so the structure's address in memory is passed to the function, not the structure itself. Based on the exception you get I'd say this is most likely the problem.

Pascal uses the stack in a different style from C, you have to make sure you're using "C-style" function calls when you call a DLL.

Look at the on-line help, it's clear there how to call a DLL.

RTFM :)

These examples are from Cantu's book:


declarations in C++:

extern "C" __declspec(dllexport)
int WINAPI Double *int n);

Calling in Delphi:

function Double (N: Integer): Integer;
stdcall; external 'CPPDLL.DLL' name 'Double';

Yes, it's 32-bit.

In Pascal a "string" is just an array of "chars". You can even index that string like: YourString[X] to get the char at position X.

function DisplayCropDialog(filename: string; version: integer; var lpci: TCropInfoStruct): boolean; external 'CropCD.dll';

Yes, that's what I mean. You pass just a "pointer" to the structure. I don't think that's the problem...
I think that the problem could be the totaly different C and Pascal "strings". That "zero byte" that C uses is a pain in the ass! :wink:


@ GFR
Yeah! Now we are getting progress!
I just add the "stdcall" and now I can open the CropDialog!
The dialog just show the name of the file and an OK buttom.
But as soom as I click the buttom, I get this error:
Access violation at address 00000010. Read off address 00000010.

So I assume that the error now should be the boolean retuned value... :roll:
(or could it be that weird C string type? :wink: )

Well, unfortunately I will have to go on a 3 days trip. (I leave in a few hours! 8O )
I’m the best man in the wedding of a great friend of mine. And the wedding will be far, far away from where I live. So I’ll spend the next 3 days drinking as much bear as I can :mrgreen: . Hope when I come back SansGrip would have finished the automated procedure, and we all can fit 3 hours of KVCDx3 on a single CD and with DVD quality!

See you all in 3 days!!

>>In Pascal a "string" is just an array of "chars". You can even index that string like: YourString[X] to get the char at position X.

You need to declare your variable as a "C" style string, null terminated. I think it's called a "PChar" type in Delphi.

I'll try to write a Delphi Application that just accesses SansGrip's dummy DLL and post the source; this way when you're back you can simply paste this in your code.

OK, with the following code:

At first I just called the DLL function ignoring the return. The CropDialog opens, with an ! sign and the Filename "teste.avi". When I close it there's the access violation bug.

Then I tried testing the return of the function and showing a message. As the CropDialog is closed, the 'OK!' dialog is shown, and then when I close it the same exception occurs.

I also tried using the PCropInfo pointer type and calling DisplayCropDialog('teste.avi',1,@testeCrop) but it is still the same.

Apparently, the string is passed OK because the CropDialog shows it OK;
Apparently, the BOOL return type is understood because the 'OK!' message is shown by the delphi program;

Perhaps the problem is with the struct, maybe it's not compatible with a pascal record?

This is hard to debug cause "When an exception is raised but not handled in a dynamically loadable library, it propagates out of the library to the caller. " (from the online help).

Then I tested this simple CPP dll from a book I have:

As you can see all functions return only integers, and all parameters are passed by value. Note also that the function Add has a "bad" name declaration. It is compiled with C++ Builder.

When it is called by the following Delphi code:

It works perfectly.

SansGrip, would you mind compiling some simpler versions of the DLL so that we can find what's the problem? (a version with no variable parameters, a version with no struct parameters, ???)

GFR

Ooops...

SansGrip, what's a "LPCTSTR"? In Delphi I only get

LPSTR (translates to a PChar) and
LPWSTR (translates to a PWideChar).

I've tried the PWideChar and the CropDialog only gives the first letter of filename, and when it goes back to the caller there's the access violation again.

When the DLL is compiled without Unicode support, an LPCTSTR is a const LPSTR. With Unicode support, it's a const LPWSTR.

This version of the DLL is compiled without Unicode, so the former is the correct translation.

wrt the access violation, it seems to be an error in the function call itself since for some reason the program counter is ending up at 00000010. This makes me suspect that it's because I left out __stdcall from the function definition. I'll add that and post another test.

@SansGrip and Kwag,

The walls and background are moving. Just encoded video using 528x480
CQ=64, Q-Matrix Beta-1, for 1 CD, resize 496x353. Picture looks GREAT!!
but, the static background has noticable movement in the walls, etc.
It happens to pulse, meaning as a second elapses the walls will appear
OK and the next second they have movement. I'm going to encode a
CQ_VBR version and see if this has the same problem. Except for
moving background, picture quality is excellent 8)

-black prince

I noticed that last night when I watched part of my American Pie encode (CQ, x3, old matrix) on the TV. It's subtle but noticible if you look for it.

I uploaded a new version in which I added explicit "__stdcall" modifiers to the function declaration. If this doesn't help I'll do what you suggest and add "features" back in until it starts crashing again :).

Edit: Forgot to say, it's at the same URL as before :).

Btw, I also got rid of the version parameter.

:tdown: ... Now when the program loads it says it can't locate DisplayCropDialog in the linked CROPCD.DLL ...

@SansGrip,

I have two versions of "Minority Report". CQ, KVCDx3 (528x480)
with the new GOP (1-12-2-1-24) and Q-Matrix BETA-1 and a CQ_VBR
version without the new GOP and Q-Matrix. The walls are stable in
the CQ_VBR version. There is slightly more Gibbs in the CQ_VBR
one, but picture quality in both is excellent. If I view the CQ version
in a dark room, it's even more noticable. The dark areas of the CQ
version show blockiness in a dark room where the CQ_VBR using
Blockbuster noise shows almost no blockiness. CQ's colors are too
dark (using Lanczos) vs CQ's (using bilinear). If only I could take
the best from both formats. Revisiting the CQ vs CQ_VBR tests might
not be a bad idea. :?

-black prince

Did you remember to change the function declaration to remove the "version" parameter?

Out of interest, is this a DVD backup or did you use the 3-disc AC3-Guru version floating round on the net?

Argh, many variables! ;) Which is the culprit? Is it CQ mode, is it the new GOP, is it the beta-1 matrix, or is it some combination?

If you can remember (or made a note of) the parameters you used to encode each, you could simply take a sample of a part of the movie showing bad blocks and make some tests to determine exactly which change caused the blocks...

I'm going to try to do the same with American Pie and we can see if our test results agree ;).