MediaPlayerElement - WinRT Xaml Island

[argumentum]

14 hours ago, WildByDesign said:

By the way, compiled binaries fail without <maxversiontested Id="10.0.18362.1"/>. So I ended up modifying AutoIt3Wrapper.au3 to include:

..we'll still need those *.manifest for testing the scripts w/o compiling.
Hopefully @Jon get's to compile the next AutoIt3 version with this in it.

[MattyD]

2 hours ago, MattyD said:

Windows.Foundation.TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, System.Object>.  So registration is failing here.

Resolving the IID for this is a bit complex, and I'm close - but not there yet

Ok think I've cracked it.

To resolve the IID, I first need to modify some stuff in WinRT_MetaDataLocator (ATM metadatalocator is not correctly handling delegates),
Then,with _WinRT_GetParameterizedTypeInstanceIID:
Windows.Foundation.TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, System.Object> should actually be passed as:
Windows.Foundation.TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, Object>

So long story short - At some point I'll modify _WinRT_CreateDelegate() so we have the ability to create a delegate of a certain "type".

I'm thinking something like:  

_WinRT_CreateDelegate("MediaOpen", "TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, Object>")

or if we get that far, I might even generate some constants:

_WinRT_CreateDelegate("MediaOpen", $sIID_TypedEventHandler_2_MediaPlayer_Object)

Then it'll be a matter of  shuffling some internals so our delegate can respond to QI requests to its own IID, in addition to IUnknown.

Stay tuned...

[MattyD]

Ok here's the fruits of a couple more hours work.  I'll update post #1 once I'm reasonably happy with things, and eventually the main WinRT thread. - which admittedly has been a bit neglected of late...

MediaPlayer_2.zip

[Jos]

12 hours ago, MattyD said:

That's probably a question for @Jos. I'd say its unlikely to get up, but there's no harm in asking.

When it is a generic change we should make and works for all win10 compiled scripts, then obviously the change can be made.
Just give me the details of the change for the current Autoit3Wrapper.au3, and I will make those changes.  🙂 

Cheers,
Jos

[WildByDesign]

42 minutes ago, Jos said:

When it is a generic change we should make and works for all win10 compiled scripts, then obviously the change can be made.

So I guess the big question is whether or not this change could have any possible negative effects for any Win10 binaries.

And if so, is it worthwhile having a separate flag to enable it in the wrapper?

@MattyD I am not personally very familiar with WinRT stuff. But I feel like I’ve read somewhere before that different features could potentially have a different value required. Can you shed some light on this? Or would the maxversion value always remain the same?

[argumentum]

41 minutes ago, WildByDesign said:

So I guess the big question is whether or not this change could have any possible negative effects for any...

The manifest in my view is "I can do this and, I can do this and, I can do this and, ... "
So, you have a manifest that say "in can do it all", and you do what you can.
But at least you're not limited by the OS saying "oh no, you can't do that".

That's my take.

[Jos]

1 hour ago, WildByDesign said:

And if so, is it worthwhile having a separate flag to enable it in the wrapper?

I am fine with that too as long as it all makes sense and is useful for most.

[MattyD]

3 hours ago, WildByDesign said:

Can you shed some light on this? Or would the maxversion value always remain the same?

It seems like (for a win32 app) that the maxversiontested element really is just for XAML Islands, at least for now. From here:

Quote

This is intended to be used by desktop applications that use XAML Islands and that are not deployed in an MSIX package.

And it can appear multiple times - one for each version of windows that the app was "tested" on.

So does the version really matter? I don't know, but I don't think so.  Xaml islands only appeared in win10 1903 - so maybe maxversiontested exists to stop apps being run on win10 builds earlier than that. But that's obviously speculation.

The version must be 10.0.18362.0 or higher. (Win10 1903).  Also, windows can't predict the version numbers of future releases -  so if you set maxversiontested to a 20H2 build for example, you won't be able to run your app on 1903. (probably, as mentioned here)

so.. I guess if we're adding maxversiontested as a static value, 10.0.18362.0 probably makes the most sense.  Otherwise, if we have the ability to specify the value(s), it might be best to have the ability to specify multiple builds for back compatibility.

Edited October 25 by MattyD
spelling

[WildByDesign]

I did some testing with various maxversiontested value. The original value that Matty suggested seems to be the best:

<maxversiontested Id="10.0.18362.1" />

So while it is called maxversiontested, it really seems to operate more like a minimum value. And in that sense, it seems very harmless and makes the most sense to keep it at the lower value as Matty already suggested.

It would be nice if it were possible to do a DllCall during process init to allow maxversiontested value similar to DPI scaling, but I don't believe it is possible.

I honestly don't think that it can cause any harm if it's compiled into every Win10 binary that AutoIt builds.

So, @Jos, whether you feel it should get compiled into any binary when the user opts for Win10 compatibility or if you think it should have some sort of separate flag to enable it is totally up to you. I am happy either way. As long as it's available in the AutoIt3Wrapper script, it will be beneficial. Thank you for your time, I appreciate it.

[WildByDesign]

@MattyD There is something that I find fascinating about this. When I do some type of script blocking, such as Sleep(10000) or keeping a MsgBox open for a duration of time, the video continues to play uninterrupted. This is a good thing, for sure.

But from a technical perspective I am curious, how is it doing that? Is the MediaPlayerElement working on a separate thread from the AutoIt process?

From what I can see, everything is in the same thread. I did see AppXSvc (AppX Deployment Service) start at the same time. But the process for that isn't using any CPU nor does it have any windows.

[Jos]

So the change that is proposed is like this at line 2000 in Autoit3Wrapper v 25.205.1420.13  ?:

                ; SET DEFAULT TO WIN10 when not specified
                If $INP_Res_Compatibility = "" Then $INP_Res_Compatibility = "Win10"
                If $INP_Res_Compatibility <> "ignore" Then
                    FileWriteLine($hTempFile2, '    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">')
                    FileWriteLine($hTempFile2, '        <application>')
                    If StringInStr($INP_Res_Compatibility, "Win10") Then
                        FileWriteLine($hTempFile2, '            <maxversiontested Id="10.0.18362.1"/>')
                        FileWriteLine($hTempFile2, '            <!--The ID below indicates application support for Windows Vista -->')
                        FileWriteLine($hTempFile2, '            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>')
                        FileWriteLine($hTempFile2, '            <!--The ID below indicates application support for Windows 7 -->')
                        FileWriteLine($hTempFile2, '            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>')
                        FileWriteLine($hTempFile2, '            <!--The ID below indicates application support for Windows 8 -->')
                        FileWriteLine($hTempFile2, '            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>')
                        FileWriteLine($hTempFile2, '            <!--The ID below indicates application support for Windows 8.1 -->')
                        FileWriteLine($hTempFile2, '            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>')
                        FileWriteLine($hTempFile2, '            <!--The ID below indicates application support for Windows 10 -->')
                        FileWriteLine($hTempFile2, '            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>')
                        _Write_RC_Console_Msg("Setting Program Compatibility Manifest information to Windows10", "", "...", 0)

 

[WildByDesign]

2 minutes ago, Jos said:

So the change that is proposed is like this at line 2000 in Autoit3Wrapper v 25.205.1420.13  ?:

Yes, this is exactly the same as I have modified in my own setup and have confirmed that the compiled binaries (when Win10 compat set) work as expected.

[Jos]

Updated v25.205.1420.14 available in Beta. 

 

[MattyD]

13 hours ago, WildByDesign said:

But from a technical perspective I am curious, how is it doing that? Is the MediaPlayerElement working on a separate thread from the AutoIt process?

Yeah, it's still single threaded. While you have a msgbox up, Autoit doesn't just drop everything - the message pump and windowproc still needs to do its thing.  It's the same reason why you can still minimize, and restore your gui etc...  

To demonstrate, this will properly lock things up!

ConsoleWrite("sleep start" & @CRLF)
DllCall("kernel32.dll", "none", "Sleep", "dword", 5000)
ConsoleWrite("sleep end" & @CRLF)

Edited Monday at 01:22 AM by MattyD

[MattyD]

Hi folks, here's a bit of a bonus.

All the WinRT stuff is crammed into one include file, then there's the beginnings of another "UDF Layer" on top of that.  Its all about simplifying things for people wanting to use this media player control in their projects. "Media player 4 all" type vibes .

TBH I probably won't be taking this particular thing much further... It'll be the underlying WinRT class/interface libraries (in the folder structure) getting the development time sorry!  So if anyone else wants run with this, feel free, and I'm happy to support if need be.

I've used up all my attachment space here - so here's a sourceforge link!

 PS: its really just something that I threw together last night - so I'm sure there's plenty there to improve on!

Edited Tuesday at 09:40 AM by MattyD

[WildByDesign]

Thank you for all of the work that you've put into this, Matty. You newest demo is great and showcases the different settings very well and is a great start for anyone wanting to get familiar with the UDF. And the UDF itself is well organized and certainly a much more viable option now for anyone wanting to get started with it.

By the way, the 3 or 4 different *SetIsFullWindow functions do work as I've tested True/False with them before and the Get* functions for them report back with the correct value that I had set. From my understanding, though, is that they don't do what we would expect (eg. fullscreen). They seem to do some sort of optimizations because I had some very large 4K videos stutter a bit before and after enabling IsFullWindow, everything is smooth now. I run mine at fullscreen size anyway, but not true fullscreen in that sense though.

Question: Have you ever been able to get the video and/or ConsoleWrite to work in VSCode or SciTE?

If I run the au3 file from File Explorer, the video works. But when I run it from VSCode or SciTE, the GUI will load but no video and therefore no island, I assume. So I've had to resort to using MsgBox at various stages during testing to get returns on certain things.

[MattyD]

That's interesting about the full screen.  You're probably on the money - Its supposed to perform "System Level Optimizations", so I guess that part is working.

10 hours ago, WildByDesign said:

Question: Have you ever been able to get the video and/or ConsoleWrite to work in VSCode or SciTE?

yep, mine's working fine from scite. I'm still patching my Autoit exe with the manifest rather than using the registry, so not sure if that has something to do with it. Maybe the registry method works for ShellExecute, but not running the exe from the command line? Dunno, just guessing. 

[WildByDesign]

17 minutes ago, MattyD said:

You're probably on the money - Its supposed to perform "System Level Optimizations", so I guess that part is working.

Yes, the optimization part definitely works. I can see several issues on their GitHub repo where they were going to finally implement a proper fullscreen mode but it seemed to have always gotten delayed, pushed off to another issue or cancelled. So I wont hold my breath on that one. But I am happy with the optimizations.

19 minutes ago, MattyD said:

I'm still patching my Autoit exe with the manifest rather than using the registry, so not sure if that has something to do with it. Maybe the registry method works for ShellExecute, but not running the exe from the command line? Dunno, just guessing. 

This proved to be correct. I decided to patch my AutoIt binary and sure enough, the console messages are coming though. That is interesting. I guess that is a limitation of the registry (external manifest) method, unfortunately.

[WildByDesign]

I've discovered that the *IsFullWindow functions that worked on your earlier versions of this MediaPlayerElement cause it to crash in the latest UDF version.

IMediaElement2_SetIsFullWindow($pThis, $bValue)
IMediaElement2_GetIsFullWindow($pThis)

IMediaPlayerElement_SetIsFullWindow($pThis, $bValue)
IMediaPlayerElement_GetIsFullWindow($pThis)

IMediaPlayerPresenter_SetIsFullWindow($pThis, $bValue)
IMediaPlayerPresenter_GetIsFullWindow($pThis)

IMediaTransportControls_SetIsFullWindowButtonVisible($pThis, $bValue)
IMediaTransportControls_GetIsFullWindowButtonVisible($pThis)

IMediaTransportControls_SetIsFullWindowEnabled($pThis, $bValue)
IMediaTransportControls_GetIsFullWindowEnabled($pThis)

In particular, according to MS docs, I believe that IMediaPlayerElement_SetIsFullWindow is the more important one regarding the system level optimizations.

But anyway, in the previous version I would run the *GetIsFullWindow* funcs in a consolewrite to note the initial True/False values. Then I would run the *SetIsFullWindow* funcs all set to True, then follow up with a second round of *GetIsFullWindow* funcs in a consolewrite to note that the final values had changed successfully.

In the current UDF version, the *GetIsFullWindow* funcs work and do not cause a crash. However, all five of the *SetIsFullWindow* funcs do cause a crash. Therefore, in the UDF version I have been unable to successfully set the IsFullWindow mode.

I am still not incredibly familiar with WinRT stuff and therefore I have no idea what the cause of the crash is. Also, I cannot obtain any kind of error return either. I've tried every way that I know and it crashes before an error can be written to console.

[MattyD]

Ok, so we don't have MediaElement or MediaPlayerPresenter objects, so those won't work. But the others look ok on my end - well the fullscreen button doesn't actually show with the transport funcs, but they don't crash. 

By the latest do you mean that sourceforge link a few posts up with the MediaPlayerUDF.au3 file in it (there is only 1 of those!)? My versioning is an absolute mess with this WinRT stuff atm!