DLL Call Problems

[UEZ]

I'm sorry to hear that. 😔

You’re just a year younger than my mother – really impressive that you’re working with programming! 

v0.5.0 animation is just the header only. As the file is created, I assume you didn't get any error message, right?

I updated the x86 version only. Can you please test it? I changed the variable timestamp_ms back to long again. The only difference which is left is the "_WinAPI_FileExistsW" function which checks Unicode files names. FB can only check ANSI file names.

Edited August 22, 2025 by UEZ

[pixelsearch]

23 minutes ago, UEZ said:

updated the x86 version only. Can you please test it?

Thank you so much for your try. Unfortunately, any example doesn't work any more and we're back in the immediate error message found in this post ("The NtCreateFile API failed etc...")

As I presume, when you compiled earlier today dll 0.5.0 (August 22, 2025) then you choosed some parameter in the compiler environment that made the dll work back on XP (and that's a real miracle !)

So if you could please just think deeply, trying to remember what was the option you choosed when you compiled it earlier today and made it XP compatible again, then it would be fantastic for all your future dll's !

Many thanks dear UEZ and sorry for the inconvenience.

 

 

[UEZ]

I assume it has something to do with GraphicsCaptureWrapper.dll which I added again and this seems not to be compatible with WinXP. The uploaded version was 0.5.1.

I removed the GraphicsCaptureWrapper code from the DLL. Please try it again.

 

Maybe I will leave GraphicsCaptureWrapper out of the DLL because on my Notebook it doesn't give me a real benefit regarding capturing speed. GraphicsCaptureWrapper should use the GPU and should be able to capture fullscreen at 60 fps.

 

Edited August 22, 2025 by UEZ

[pixelsearch]

9 minutes ago, UEZ said:

I removed the GraphicsCaptureWrapper code from the DLL. Please try it again.

 

Sure, I just tried it again.

All examples work back again. Example09 (screen capture) still shows a uniform white background (why is that ? I got no white background while typing in notepad during the screen capture) . No text or mouse move is shown in the animation (it's the same static pic I uploaded in the last post of precedent page 1 in this thread)

44 minutes ago, UEZ said:

I assume you didn't get any error message, right?

sorry I forgot to answer this question before. No, no error message at all.

45 minutes ago, UEZ said:

The only difference which is left is the "_WinAPI_FileExistsW" function which checks Unicode files names. FB can only check ANSI file names.

If you think it's worth a quick try to make sure that it will solve the issue by my side, please let's try it if you want

Thanks

 

[UEZ]

WebP_CreateWebPCreateAnim(), WebP_GetAnimFileInfo(), WebP_ConvertAPNG2WebP(), WebP_ScaleImage() and WebP_GetImageQuality() are using _WinAPI_FileExistsW, too.

Can you please check if these examples are working?

 

Can you try to mark fullscreen and test? 

Edited August 22, 2025 by UEZ

[pixelsearch]

1 hour ago, UEZ said:

Can you please check if these examples are working?

Sorry it took me a bit long because I checked ALL examples (from 01 to 18 included) . They all work except example09 (screen capture) which means that yes, all functions you indicated work by my side with _WebP_x86.dll you uploaded 1 hour ago

1 hour ago, UEZ said:

Can you try to mark fullscreen and test? 

Now that's strange, it captures all icons found in the marked area, text is never captured and the  background is white (even if the background was colored or there was a wallpaper on the desktop : background will always be white)

Compared to 0.4.4 : version 0.4.4 captures everything correctly, the mouse move, the text in the window, the wallpaper, the icons etc...

That's why I suggest to leave it "as-is" if you're ok, as it works fine for everybody but me. If I ever needed to create an animated webp file from a screen capture, then I'll use dll 0.4.4

Many thanks UEZ for all your efforts !

Edited August 22, 2025 by pixelsearch

[UEZ]

Sorry, I was not drunken but I was in a different function - doh.

Yes, WebP_CreateWebPCreateAnimFromScreenCapture was heavily modified to get more speed. It is a good question, what causes the issues now.

I added a new parameter "$bXPMode" to Web.au3:

Func WebP_CreateWebPCreateAnimFromScreenCapture($x, $y, $w, $h, $sec, $sOutfile, $fps = 30, $CapCursor = 1, $quality = 75.0, $lossless = 0, $method = 0, $filter_strength = 60, $sns_strength = 50, _
        $pass = 1, $filter_sharpness = 0, $near_lossless = 100, $alpha_compression = 0, $alpha_filtering = 0, $alpha_quality = 100, $target_size = 0, $loop_count = 0, _
        $WebPImageHint = $WEBP_HINT_DEFAULT, $pCallback = 0, $bXPMode = False, $sPath2DLL = "")

Please set it to true and try again.

 

Btw, WebP officially only supports Vista+ operating systems! You are lucky that it works with WinXP.

Edited August 22, 2025 by UEZ

[pixelsearch]

1 hour ago, UEZ said:

Btw, WebP officially only supports Vista+ operating systems! You are lucky that it works with WinXP.

If you knew how many times I read this on msdn pages ("Vista+ needed") when it still works on WinXP SP3...

Unfortunately the last test doesn't make it, fatal error with this display in AutoIt console :

Progress: 0%
>Exit code: 3221225477

Example09 was launched with True added as "last" Parameter

Global $iResult = WebP_CreateWebPCreateAnimFromScreenCapture($xPos, $yPos, $w, $h, $iRecordSeconds, $sFile, 30, 1, 75, 0, 0, 60, 50, 1, 0, 100, 0, 0, 100, 0, 0, _
    $WEBP_HINT_DEFAULT, DllCallbackGetPtr($iCB), True)

Which corresponds to this, in downloaded WebP.au3

...
; $pCallback - [optional] a pointer value. Default is 0. Callback pointer for progress status
; $bXPMode   - [optional] a boolean value. Default is False.
; $sPath2DLL - [optional] a string value. Default is "". Path to WebP dll if not in script dir.

and the dll has been updated too, as seen with example03 which shows the date of the dll (August 23)

UEZ honestly it's not a problem if this function can't be updated for XP. As this function works fine for XP with dll 0.4.4 then I truly feel sorry for the time you're spending on it in dll 0.5.0

You know, sometimes we should just let things go, especially when it works for 99.9999% of other users.
Really, I thank you for all your efforts, very appreciated.

[UEZ]

Never say never 😉

It was too late and I forgot to set the correct stride value for 24bit capturing. I uploaded the x86 version which should work now.

We’ll figure it out if it’s still not working.

Edited August 23, 2025 by UEZ

[pixelsearch]

52 minutes ago, UEZ said:

I uploaded the x86 version which should work now.

Bravissimo UEZ
(_WebP_x86.dll v0.5.0 build 2025-08-23 beta) (Libwebp v1.0.3)

Example09 (screen capture) works fine now by my side with this dll and last param. True in example09
Now all examples are working with this dll, from example01 to example18

Thanks for your time and incredible efforts to solve this, you made it !
Have a great day

[RTFC]

@UEZ & @pixelsearch: You two are both amazing.

[UEZ]

The C++ DLL now works perfectly, at least on my system.

Could someone please test the WebP example “Example09.1.au3”, which can be found here? -> WebP.7z. Requires Windows10 build 18362+.

It should work on both architectures—x86 and x64. It records for 10 seconds at 30 FPS; at least, that’s the goal. Please run the script via SciTE, select the entire primary monitor, and start recording. As soon as the yellow rectangle appears, recording begins.

If possible, it would be great to see the utilization level in the GPU monitor. In theory, the recording should use the GPU. You can use Process Explorer from Sysinternals to see GPU.

Once the recording is complete, a summary should appear in the SciTE console, similar to the one shown here:

...
Animation file size: 56571058 bytes
Dimension: 1920 x 1080
Frame count: 158
Duration: 10046 ms
Estimated FPS: 15.7276527971332

 

CPU: Intel Core Ultra 5 135U

GPU: Intel(R) Graphics

 

Can you post your result here? Which CPU / Gfx card you have used for testing?

Thanks.

Edited Thursday at 10:32 AM by UEZ

[Gianni]

Animation file size: 57182968 bytes
Dimension: 1920 x 1080
Frame count: 115
Duration: 10000 ms
Estimated FPS: 11.5

GPU about 40%

Intel(R) HD Graphics 530

Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (3.19 GHz)

Edited Wednesday at 11:46 PM by Gianni

[Werty]

Getting nothing, just exits script at 39%.

Dimension: 3840 x 2160
CPU: Intel 10900K
GPU: nVidia RTX 3080 12GB
RAM: 32GB

Windows 10 Pro 21H2 19044

Probably doesnt like 4K UHD.

Tried again changing this line...

;~ Global $aCoord = _WinAPI_MarkScreenRegion()
Global $aCoord[4] = [0,0,1920,1080]

And that worked, got...

Animation file size: 842044 bytes
Dimension: 1920 x 1080
Frame count: 86
Duration: 10016 ms
Estimated FPS: 8.58626198083067

...which seems rather low compared to yours and Giannis results and hardware, only had music playing via MPC-HC.

Edited Thursday at 12:16 PM by Werty

[AndyG]

Animation file size: 94421942 bytes
Dimension: 2560 x 1440
Frame count: 186
Duration: 9984 ms
Estimated FPS: 18.6298076923077
WebP-dll.bas: (1399) Error allocating frames!

in the function WebP_ExtractAnimFramesToMem() , I used some debug-code, returns with

@@ Debug(543) : $iFrames = 186
>Error code: 0
@@ Debug(546) : DllStructGetPtr($tImgPtr) = 0x04D7EE00
>Error code: 0
@@ Debug(548) : $aReturn[0] = -3
>Error code: 0
@@ Debug(78) : $tFrames = -3   ;return from function WebP_ExtractAnimFramesToMem()
>Error code: 4
WebP-dll.bas: (1399) Error allocating frames!
->14:02:32 AutoIt3.exe ended.rc:1

 

with low resolution/capturing dimensions, no issues...

Animation file size: 78116946 bytes
Dimension: 599 x 437
Frame count: 302
Duration: 9968 ms
Estimated FPS: 30.2969502407705

clipping/cutting from YT Video 1080p 30FPS

 

Radeon RX590, Ryzen 5 9600X, 32GB RAM, Win11pro 24H2

 

 

 

Edited Thursday at 12:10 PM by AndyG

[Werty]

Hmm, seems to be content aware somehow, tried again this time actually recording something moving (youtube vid) and not just Idle desktop and got better results...

Animation file size: 219574468 bytes
Dimension: 1387 x 774
Frame count: 220
Duration: 10000 ms
Estimated FPS: 22

Though sometimes it doesnt exit correct, it runs to 100% but saves nothing and no results in the scite console, would suck if recording something long which you then misses because it didnt save it. 😕

Edited Thursday at 12:39 PM by Werty

[UEZ]

@Werty Estimated FPS is only an indicator not real FPS because WebP uses delta frames that means only the differences will be saved. When nothing is changing no additional frames will be saved. Probably WebP codec is not designed for realtime recording, especially for large screens. Wondering why it fails at 3840 x 2160. When save fails the webp dll returns a negative value which should be displayed when recording has finished.

 

@AndyG obviously all frames couldn't extracted to memory -> probably out of memory or WebPMalloc() cannot handle it - it needs several gigs of memory for this screen resolution. Is the recording saved?

 

Thank you all three for testing!

Edited Thursday at 01:11 PM by UEZ

[AndyG]

2 hours ago, UEZ said:

Is the recording saved?

Yes, animation is saved. I took two tests....

2560x1440 , the "animation" is the part of the scrolling console (10 seconds) of the script, poor quality but only 76MB filesize!

2560x1440 , the "animation" is a capure of a fullscreen YT video (10 seconds) , poor quality but only 406MB filesize!

 

Edited Thursday at 03:14 PM by AndyG

[UEZ]

1 hour ago, AndyG said:

Yes, animation is saved. I took two tests....

2560x1440 , the "animation" is the part of the scrolling console (10 seconds) of the script, poor quality but only 76MB filesize!

2560x1440 , the "animation" is a capure of a fullscreen YT video (10 seconds) , poor quality but only 406MB filesize!

 

You actually specified the file size above, so the question was unnecessary.
For high-resolution video recordings, you shouldn't enable in-memory decoding. The script roughly checks whether there is enough memory for the decompression in the memory. If not, playback is skipped.

The lower the quality and bitrate settings are, the faster the encoding speed, but the lower the recording quality.

I need to figure out how to use other codecs for full-screen video recordings. WebP isn't really suitable for that.

[UEZ]

Can somebody please test ScreenRecorder_vfw? Before you run any of the executable files, please run “Configure_x264vfw.cmd”, adjust the settings according to this screenshot, and then click “OK”:

It should record the primary monitor in full-screen mode at 30 fps for 10 seconds. The result should be saved in the file output.avi.

Is it working for you? Which resolution? Is 30 fps achieved? Can be checked e.g. with MediaPlayerClassic, VLC Player, etc.

THANKS!

Edited 1 hour ago by UEZ