Description
Describe the bug
Depending on the video, setting MediaPlayer.Source can block the UI thread for a few hundred milliseconds, which is noticeably jarring. I experimented with setting it on a background thread, but I found that I also had to prevent any access to MediaPlayer.Source and MediaPlayer.PlaybackSession properties until the SourceChanged event had fired before I managed to achieve partial success in not blocking the UI thread (I also had to use it is frame server mode).
Steps to reproduce the bug
Do some UI update then set MediaPlayer.Source to a new MediaPlaybackItem(MediaSource.CreateFromStorageFile(file)). Also maybe try to access other properties immediately after such as accessing the MediaPlayer.PlaybackSession.NaturalVideoWidth. The UI update is delayed by up to a few hundred milliseconds, depending on the video.
Expected behavior
Setting MediaPlayer.Source should not block the UI thread. If this requires some internal queuing in the media player, then so be it. Note it is fine for the natural size properties to return 0 immediately after, since the do most of the time anyway.
Screenshots
No response
NuGet package version
No response
Packaging type
Packaged (MSIX)
Windows version
Windows 11 version 21H2 (22000)
IDE
Visual Studio 2022
Additional context
I know that this repo is perhaps not directly responsible for MediaPlayer, bit it is still a key part of Windows App SDK apps, so I am reporting this bug here.
Also there are some other MediaPlayer bugs. For example, if you have two separate media players and you set MediaPlayer.Source to a new MediaPlaybackItem(MediaSource.CreateFromStorageFile(file)) (separate instances) at the same time, where the file is the same for both, then you can get an exception. The ones I am getting are audio device in use and Shutdown has already been called. This depends on the video type.