Quote:
|
Quote:
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 |
Quote:
Quote:
Quote:
|
Quote:
Here you go: Code:
Name25="KVCD Notch BETA-1" |
Quote:
First I declared the CROPINFO type, that's pretty much like in C: Code:
TCropInfoStruct = record Code:
procedure DisplayCropDialog(filename: string; version: integer; var lpci: TCropInfoStruct); external 'CropCD.dll'; So, I called it like you said: Code:
var ci: TCropInfoStruct; 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?) |
Quote:
Quote:
Also note that the function returns a "BOOL" type. I'm not sure how you specify return types in Pascal. Quote:
|
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'; |
Quote:
Quote:
Quote:
Quote:
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 Quote:
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:
Code:
unit Unit1; 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:
//--------------------------------------------------------------------------- When it is called by the following Delphi code: Code:
unit CallCppF; 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. |
Quote:
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 |
Quote:
|
Quote:
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 |
Quote:
|
Quote:
Quote:
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 ;). |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.