VB6 - Screen Capture to Video, Grab a Window or the Full Screen & Encode to MP4 Video

[VanGoghGaming]

This is more of a continuation to my previous Windows Graphics Capture project but with enough modifications to warrant a new thread. Now, in addition to capturing any top level window or the whole monitor and displaying it in a PictureBox, the captured frames are also fed in real time into a "MediaStreamSource" object that takes care of encoding and saving them to an MP4 video file.

To start capturing a window just have the program in the foreground (to maintain focus), hover the mouse over the window you want to capture and press "Enter". The same goes for capturing the monitor if you have more than one. The capture process works even in background if you want to do something else in the meantime. The video file will be saved in the "App.Path" folder with a name generated from the current date and time.

There are just three custom properties in the video encoding class, BitRate, FrameRate and FileName (if you're not happy with the defaults). I've seen that a BitRate of 3Mbps and a FrameRate of 60FPS produce nice quality, decent size files.

The program responds to external events such as the target window being resized or closed and there is also the possibility to pause and resume the capture process. The pause duration is not included in the video file so on playback it would seem the action skipped right ahead!



Here is the demo project: ScreenCaptureToVideo.zip

I've done quite a bit of testing and it seems to work fine so far but I'd like to know if there are any bugs. Most of the API functions involved are asynchronous in nature meaning they don't return a value right away but also they don't block the execution like VB6 does. Implementing such asynchronous behavior in VB6 (with delegate callbacks as to keep the UI responsive) has been challenging without resorting to the infamous "DoEvents" which I wanted to avoid at all costs!

[-Franky-]

Very nice project. I can well imagine how much energy and time you must have put into this project. Just a question about that. Why don't you use the Windows.Graphics.Capture.GraphicsCapturePicker to select a window or screen that should then be recorded?

[The trick]

Good! Thank you!

[HackerVlad]

I don't know what people here admire so much if the project doesn't work. I downloaded the ZIP archive. I unpacked everything into a folder, launched the project by pressing F5 and immediately an error flew out that some obscure file was not found there. I compiled it into an EXE and launched it, too, an error. Nothing is working.

[VanGoghGaming]

Sorry mate, I forgot to mention, this project requires Windows 10 or newer.

[Elroy]

Hey VanGogh,

I tried it and the MP4 seemed like it was color shifted or some such thing. Here's just a random YouTube video viewed in Chrome. I tried it in four different video players, all with the same results.

[VanGoghGaming]

Thanks for testing Elroy. I've managed to reproduce the distorted colors on a Windows 11 system with an integrated graphics card. It seems to be happening when the captured window has odd (as opposed to even) width and/or height values. The C# tutorial mentions this:

    // Make sure the dimensions are are even. Required by some encoders.
    width = (width % 2 == 0) ? width : width + 1;
    height = (height % 2 == 0) ? height : height + 1;

I did include this code in the VB6 project:

    If m_lWidth Mod 2 Then m_lWidth = m_lWidth + 1
    If m_lHeight Mod 2 Then m_lHeight = m_lHeight + 1

And it seems to work fine for odd widths and heights on my current Windows 10 machine that has a dedicated graphics card.

I don't know whether the problem with distorted colors for odd dimensions in Windows 11 is caused by the lack of a dedicated graphics card or not. Try resizing the window or maximize it, that should have an even width and height...

[Elroy]

Trying your suggestion now.

Ahhh, I see it's not a recommended change. I'll try and test anything you think I should test.

[VanGoghGaming]

Ok so if you have a dedicated graphics card then from our tests so far we can deduce:

- in Windows 10 the colors are okay regardless of the dimensions of the captured window
- in Windows 11 the colors are okay for even dimensions and distorted for odd dimensions (either width or height)

[yereverluvinuncleber]

Not bad, needs a bit of polishing to the UI to make into a day to day usable tool that matches what is already available in other tools but it is good to see VB6 capable of the same basic functionality. It would be useful to see a version for previous Windows versions, Win 7/Vista and XP.

[Elroy]

Personally, I'd definitely put the FrameRate and BitRate in textboxes so they could be easily changed by the user. Also, a file specification textbox would also be nice, possibly with a "..." button beside it so it could be easily changed. There'd need to be some validity checking on that as well: Folder exists?, File exists?, Check file extension?, Overwrite Yes/No (if exists)?

I suppose all of that would need to be disabled when it was recording.

[Elroy]

Yep, I validated that, on my hardware configuration, either an odd width or height (or both), it does that color shift. But, if they're both even all is fine.

---

Also, with appropriate attribution, how would you feel about me incorporating this work into my screen-capture utility? For me, it'd just be nice if we could just specify the exact area we wished to capture as a video.

Ohh, and another super-nice improvement would be the optional inclusion of audio.

[VanGoghGaming]

Yep, I validated that, on my hardware configuration, either an odd width or height (or both), it does that color shift. But, if they're both even all is fine.

Yep, this seems to be a Windows 11 problem (not related to hardware configuration). They must've changed something because it works fine in Windows 10...

Also, with appropriate attribution, how would you feel about me incorporating this work into my screen-capture utility? For me, it'd just be nice if we could just specify the exact area we wished to capture as a video.

Ohh, and another super-nice improvement would be the optional inclusion of audio.

Sure thing mate, go wild with it!

The ability to capture an exact area is already implemented with the "SetCaptureRegion" method (you can see it in the screenshot from the first post above). For quick and dirty testing purposes I've just put 4 text boxes on the form to specify the dimensions of the region to be captured (Left, Top, Width, Height). "Left" and "Top" are relative to the item being captured (window or monitor).

I've thought about capturing audio as well but it's easier said than done. While there are WinRT classes for both audio capturing and encoding to MP3, it's like looking for the needle in multiple haystacks without some examples or guidance. Most articles I've seen focus on capturing output from your webcam and microphone. Since audio can be played from multiple sources at once (each tab in Chrome could be playing a different audio for example), it would be a challenge identifying which audio source you want to capture. And then it would come to adding and synchronizing audio with the captured video frames.

[VanGoghGaming]

Very nice project. I can well imagine how much energy and time you must have put into this project. Just a question about that. Why don't you use the Windows.Graphics.Capture.GraphicsCapturePicker to select a window or screen that should then be recorded?

In my opinion, that "GraphicsCapturePicker" dialog is a totally useless nuisance! Usually you already know exactly what item you want to capture and you certainly don't want to be interrupted by a dialog popping up every time!

In general, I've seen that UWP (Universal Windows Platform) applications are very limited in terms of access rights and they can't do much without the user explicitly selecting something from a dialog. A perfect example of this behavior is in the beginning of the C# tutorial I've used to create this project:

    // Create a destination file - Access to the VideosLibrary requires the "Videos Library" capability
    var folder = KnownFolders.VideosLibrary;
    var name = DateTime.Now.ToString("yyyyMMdd-HHmm-ss");
    var file = await folder.CreateFileAsync($"{name}.mp4");

As you can see, they say that "Access to the VideosLibrary requires the "Videos Library" capability". So it is my understanding that if this were a UWP application then its manifest file would have needed to include this "Videos Library" capability! If this isn't a nuisance, I don't know what is!

Fortunately, good old Win32 applications are not restricted in this draconic fashion. I didn't want to limit the app to saving files only in the "VideosLibrary" folder. Also I didn't want to display the "Folder Picker" dialog every time (since this doesn't work when the IDE is run as administrator). So instead of calling the "folder.CreateFileAsync" method to create the video file, I used the plain "CreateFileW" API from "kernel32"! An UWP app would be restricted from calling this API outside the folder where it resides (the so-called package folder) as I've gathered...

[-Franky-]

Whether the GraphicsCapturePicker is unusable is a matter of taste. At least you can also use it to select windows that are hidden by other windows. It is known that the WinRT dialogs in the VB6 IDE do not work in elevated mode. I test this in the IDE without elevated mode and the WinRT dialogs work. So far I haven't been able to find out that there are any restrictions regarding certain paths. A simple test for "PhotoCapture from WebCam" shows that the image can be saved to the VideosLibrary without any problems. Set StorageFolder = FolderPicker.PickSingleFolderAsync -> Set StorageFile = StorageFolder.CreateFileAsync("Capture.png", CreationCollisionOption_GenerateUniqueName) -> MediaCapture.CapturePhotoToStorageFileAsync(ImageEncodingProperties, StorageFile)

Alternatively, if you don't want to use a dialog, you can also get a StorageFolder, like in my WinRT example "KnownFolders". -> Set StorageFolder = KnownFolders.VideosLibrary

[VanGoghGaming]

Whether the GraphicsCapturePicker is unusable is a matter of taste. At least you can also use it to select windows that are hidden by other windows.

I didn't say it was unusable, I said it was a nuisance, you know annoyance, Belästigung!

It is known that the WinRT dialogs in the VB6 IDE do not work in elevated mode. I test this in the IDE without elevated mode and the WinRT dialogs work. So far I haven't been able to find out that there are any restrictions regarding certain paths.

Yes, I meant the restrictions are only for UWP apps. Win32 apps can get away with pretty much anything when calling these WinRT APIs. WinRT dialog restrictions come into effect only between processes of different elevation levels. So if you run your EXE elevated then the dialog will raise an access denied exception. I am not sure if this can be fixed with a signed executable and a manifest with "<requestedExecutionLevel level="highestAvailable" uiAccess="true"/>"

A simple test for "PhotoCapture from WebCam" shows that the image can be saved to the VideosLibrary without any problems. Set StorageFolder = FolderPicker.PickSingleFolderAsync -> Set StorageFile = StorageFolder.CreateFileAsync("Capture.png", CreationCollisionOption_GenerateUniqueName) -> MediaCapture.CapturePhotoToStorageFileAsync(ImageEncodingProperties, StorageFile)

So far I have avoided to wrap these WinRT objects into VB6 classes in order to obtain maximum performance. I'm still not sure if this is the right approach though. The number of classes would quickly explode since every little thing requires its own class. The "FolderPicker" dialog does have the most modern look though, way better than the classic "OpenFolder" dialog from "comdlg32"...

Alternatively, if you don't want to use a dialog, you can also get a StorageFolder, like in my WinRT example "KnownFolders". -> Set StorageFolder = KnownFolders.VideosLibrary

Yep, this is certainly one way to go. Currently I didn't implement any folder selection, I just create an empty file in "App.Path" or wherever the user wants and obtain an "IStorageFile" object from it by calling "IStorageFileStatics_GetFileFromPathAsync". It seemed the quickest way to get the job done. There's certainly room for improvement!

To be honest, I would have avoided the StorageFile object as well if I could but it's needed for getting a "RandomAccessStream" for the "MediaStreamSource" object to save video frames into...

[-Franky-]

The number of classes would quickly explode since every little thing requires its own class.

Yes, although you don't necessarily need a separate class in VB for each WinRT class. A pointer and the vTable entry of the required WinRT class/function are enough.

[VanGoghGaming]

That's what I've been doing so far. I've also reused the same VTable for all EventHandler objects instead of creating a new BAS module for each one. Seems to work great!

[xiaoyao]

maybe need 3 method for cut screen img:
winrt:win10
dxgi:win8
printwindow:win7 up