CQ vs. CQ_VBR ... Very Interesting... - Page 16

SansGrip · #**301** 01-01-2003, 11:35 PM

Quote:

Originally Posted by kwag

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

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

.

kwag · #**302** 01-01-2003, 11:40 PM

Quote:

Originally Posted by SansGrip

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

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

-kwag

SansGrip · #**303** 01-01-2003, 11:44 PM

Quote:

Originally Posted by kwag

Did you use MAX=2,300 or MAX=2,500

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.

Quote:

The mods. on the matrix shouldn't affect high frequency areas at all

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.

Quote:

Even on the movie I just watched, "Sum of all fears", the fire and explosions were blockless

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?

kwag · #**304** 01-01-2003, 11:46 PM

Quote:

Originally Posted by SansGrip

Could you post the beta-1 matrix again so I can make sure I'm using the correct version?

You bet

Here you go:

Code:

Name25="KVCD Notch BETA-1" 
ReadOnly25=0 
Intra25_0=8 6 8 22 26 27 29 34 
Intra25_1=6 7 10 26 27 29 34 37 
Intra25_2=8 10 14 27 29 34 37 38 
Intra25_3=22 26 27 31 36 37 38 40 
Intra25_4=26 27 29 36 39 38 40 48 
Intra25_5=27 29 34 37 38 40 48 58 
Intra25_6=29 34 37 38 40 48 58 69 
Intra25_7=34 37 38 40 48 58 69 79 
NonIntra25_0=16 18 20 22 24 26 28 30 
NonIntra25_1=18 20 22 24 26 28 30 32 
NonIntra25_2=20 22 24 26 28 30 32 34 
NonIntra25_3=22 24 26 30 32 32 34 36 
NonIntra25_4=24 26 28 32 34 34 36 38 
NonIntra25_5=26 28 30 32 34 36 38 40 
NonIntra25_6=28 30 32 34 36 38 42 42 
NonIntra25_7=30 32 34 36 38 40 42 44

muaddib · #**305** 01-02-2003, 08:07 AM

Quote:

Originally Posted by SansGrip

In C, I would call it like this:

Code:

CROPINFO ci;
DisplayCropDialog("the_file.avi", 1, &ci);

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:

Code:

 TCropInfoStruct = record
    left, right, top, bottom : integer;
    width, height : integer;
 end;

Before I can call your function I need to declare it as an external (please, check if the types are corrects):

Code:

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

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:

Code:

var ci: TCropInfoStruct;
DisplayCropDialog('temp.avi', 1, ci);

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?)

SansGrip · #**306** 01-02-2003, 08:13 AM

Quote:

Originally Posted by muaddib

First I declared the CROPINFO type, that's pretty much like in C:

Code:

 TCropInfoStruct = record
    left, right, top, bottom : integer;
    width, height : integer;
 end;

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

Quote:

Code:

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

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.

Quote:

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?

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.

GFR · #**307** 01-02-2003, 08:48 AM

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';

muaddib · #**308** 01-02-2003, 10:08 PM

Quote:

Originally Posted by SansGrip

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

Yes, it's 32-bit.

Quote:

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.

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.

Quote:

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

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

Quote:

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.

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!

@ GFR

Quote:

Originally Posted by GFR

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

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...

(or could it be that weird C string type?

)

muaddib · #**309** 01-02-2003, 10:26 PM

Well, unfortunately I will have to go on a 3 days trip. (I leave in a few hours!

)
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

. 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!!

GFR · #**310** 01-03-2003, 05:27 AM

>>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.

GFR · #**311** 01-03-2003, 07:43 AM

OK, with the following code:

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;


TCropInfo=record
	left, right, top, bottom:integer;
	width, height: integer;
end;

PCropInfo=^TCropInfo;

var
  Form1: TForm1;

implementation

{$R *.dfm}

const
 cropCD='CropCD.dll';

function DisplayCropDialog(filename:PChar; version:integer; var lpci:TCropInfo):BOOL;stdcall;external cropCD;

procedure TForm1.Button1Click(Sender: TObject);
var
  testeCrop: TCropInfo;
begin
  with testeCrop do
    begin
      left:=10; right:=50; top:=20; bottom:=70;
     	width:=100; height:=200;
    end;
  If DisplayCropDialog('teste.avi',1,testeCrop) then
    ShowMessage('OK!');
end;

end.

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:

Code:

//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
    return 1;
}

//---------------------------------------------------------------------------

extern "C" __declspec(dllexport)
int WINAPI Double (int n)
{
	return n * 2;
}

extern "C" __declspec(dllexport)
int WINAPI Triple (int n)
{
	return n * 3;
}

__declspec(dllexport)
int WINAPI Add (int a, int b)
{
	return (a + b);
}

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:

Code:

unit CallCppF;

interface

uses
  SysUtils, Windows, Messages, Classes, Graphics, Controls,
  Forms, Dialogs, StdCtrls, Spin, ExtCtrls;

type
  TForm1 = class(TForm)
    BtnDouble: TButton;
    SpinEdit1: TSpinEdit;
    Label1: TLabel;
    BtnTriple: TButton;
    Label2: TLabel;
    SpinEdit2: TSpinEdit;
    BtnAdd: TButton;
    Label3: TLabel;
    Edit1: TEdit;
    Bevel1: TBevel;
    procedure BtnDoubleClick(Sender: TObject);
    procedure BtnTripleClick(Sender: TObject);
    procedure BtnAddClick(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

{definition of the functions of the DLL}
function Add (A, B: Integer): Integer;
  stdcall; external 'CPPDLL.DLL' name '@Add$qqsii';
function Double (N: Integer): Integer;
  stdcall; external 'CPPDLL.DLL' name 'Double';
function Triple (N: Integer): Integer;
  stdcall; external 'CPPDLL.DLL';

procedure TForm1.BtnDoubleClick(Sender: TObject);
begin
  SpinEdit1.Value := Double (SpinEdit1.Value);
end;

procedure TForm1.BtnTripleClick(Sender: TObject);
begin
  SpinEdit2.Value := Triple (SpinEdit2.Value);
end;

procedure TForm1.BtnAddClick(Sender: TObject);
begin
  Edit1.Text := IntToStr (Add (
    SpinEdit1.Value, SpinEdit2.Value));
end;

end.

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

GFR · #**312** 01-03-2003, 08:32 AM

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.

SansGrip · #**313** 01-03-2003, 10:01 AM

Quote:

Originally Posted by GFR

SansGrip, what's a "LPCTSTR"?

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.

black prince · #**314** 01-03-2003, 10:29 AM

@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

-black prince

SansGrip · #**315** 01-03-2003, 10:36 AM

Quote:

Originally Posted by black prince

The walls and background are moving.

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.

SansGrip · #**316** 01-03-2003, 10:38 AM

Quote:

Originally Posted by GFR

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, ???)

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.

GFR · #**317** 01-03-2003, 11:33 AM

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

black prince · #**318** 01-03-2003, 11:43 AM

@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

SansGrip · #**319** 01-03-2003, 12:21 PM

Quote:

Originally Posted by GFR

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

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

SansGrip · #**320** 01-03-2003, 12:27 PM

Quote:

Originally Posted by black prince

I have two versions of "Minority Report"

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

Quote:

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.

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

.