microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.27k stars 674 forks source link

WinUI MediaPlayerElement #5172

Closed Fernand-Delavy closed 1 year ago

Fernand-Delavy commented 3 years ago

I need MediaPlayer on WinUI or Reunion for Windows

On the page : https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.mediaplayerelement?view=winrt-20348

I read : Equivalent WinUI class: Microsoft.UI.Xaml.Controls.MediaPlayerElement.

if using Microsoft.UI.Xaml.Controls.MediaPlayerElement;

But MediaPlayerElement is not present on :

WinUI UWP, WinUI for Desktop , Project Reunion 0.5.7 and 0.8.0 with .NET 5

What is wrong ? How to use MediaPlayerElelemnt ?

StephenLPeters commented 3 years ago

MediaPlayerElement isn't currently supported in Winui3,

@MikeHillberg @codendone or @Austin-Lamb to weigh in on the plan for it.

codendone commented 3 years ago

See the WinUI 3.0 Feature Roadmap for the latest status on plans, including Media Controls. We currently do not have a specific release timeline for MediaPlayerElement.

maxkatz6 commented 3 years ago

I wonder if it will include MediaElement or will it be removed as previously deprecated control.

DarrylDreiling-Sphero commented 3 years ago

It would be pretty helpful for us to have the MediaPlayerElement available to WinUI applications.

We use video content in our educational app to help users learn and complete their school activities, so Media Player support would be very helpful. Rather than sending students out of the app to a browser to view the video content, we’d like to have them view their content inside the app while doing their programming work.

We also believe the MediaPlayerElement would allow us to swap out our large library of sounds (which are mono, low bit-rate .wav files), for higher fidelity stereo .mp3 files. This would help us reduce our app install size as well. The Sound Player we are currently using doesn't have a way for us to detect when a sound is done playing, the MediaPlayerElement does.

Overall, better video playback would ensure that our Windows app is competitive with the other versions of our app on iOS, macOS, Android, and ChromeOS, and better ensure the Windows app is a viable solution for our ~200,000 MAU during the school season.

qJake commented 2 years ago

I wanted to port my WPF app to WinUI 3 which relies heavily on video playback. This is very disappointing. Please add support for this!

erikvanappeldoorn commented 2 years ago

I contribute to an UWP app with background audio streaming (radio). Would be nice to convert the app to WinUI 3, so no media support would be a show stopper.

tesar-tech commented 2 years ago

I would like to update my Video Detail Player to WinUI 3 in the near future. This kind of blocks me. The MediaPlayerElement in UWP evolved in pretty useful control I have to say, it's shame to leave it behind (But I also understand, it's not easy to port it).

ianier commented 2 years ago

I would like to update my Video Detail Player to WinUI 3 in the near future.

Same goes for my app Chronotron. Is it possible to mix and match UWP/WinUI3 controls? (e.g. using the old Windows.UI.Xaml.MediaPlayerElement in a WinUI 3 UWP app?)

agenne commented 2 years ago

We urgently need the Control MediaPlayerElement or MediaElement! The roadmap says it will come in a future release, but we need to know when (Q1, Q2?). We would very much like to switch our UWP app to WinUI3 because we urgently need WebView2, but as long as there is no MediaElement, we cannot make the switch.

HermanEldering commented 2 years ago

For me this issue is also problematic since it is not possible to use XAML Islands in WPF with .NET 5/6 and WinUI3 doesn't support MediaPlayerElement. So other than creating/using a third party media control I think the only solutions are to use either .NET Core 3.1 or UWP? Which both are end-of-life.

agenne commented 2 years ago

Microsoft, please tell us, will you offer the MediaControls at all? More than half a year is invested in the acrylic features. Who needs that? Would it be possible to know how much longer we have to wait? Unbelievable!

stefffdev commented 2 years ago

You can load the video in a WebView2 and use the HTML5 video API via JavaScript interaction.

agenne commented 2 years ago

You can load the video in a WebView2 and use the HTML5 video API via JavaScript interaction.

That's a possibility if playing videos is a marginal feature. We have a digital signage system where this is one of the core features... In addition, there are problems in memory management with WebView2 that can only be solved with WorkAround's.

HermanEldering commented 2 years ago

You can load the video in a WebView2 and use the HTML5 video API via JavaScript interaction.

For me this is probably also not a solution because I create an overlay using a IBasicVideoEffect.

ianier commented 2 years ago

For me this is probably also not a solution because I create an overlay using a IBasicVideoEffect.

Yes, audio and video effects are a must have, at least for me.

stefffdev commented 2 years ago

For me this is probably also not a solution because I create an overlay using a IBasicVideoEffect.

Yes, audio and video effects are a must have, at least for me.

Never tried it but maybe you could implement custom effects in JavaScript as well and trigger them from within your .NET app.

tesar-tech commented 2 years ago

Never tried it but maybe you could implement custom effects in JavaScript as well and trigger them from within your .NET app.

Yeah, or we can try to write the whole app in some other technology than c# and xaml. ToTalLy ViAbLe oPtioN... "Fck you in particular UWP developers!" No feature parity in platform you invested in, and even not enough feedback!

ianier commented 2 years ago

Yeah, or we can try to write the whole app in some other technology than c# and xaml. ToTalLy ViAbLe oPtioN... "Fck you in particular UWP developers!" No feature parity in platform you invested in, and even not enough feedback!

Indeed. Quoting myself from https://github.com/microsoft/WindowsAppSDK/discussions/1055#discussioncomment-1282924: "Otherwise, if the cost of moving ahead is rewriting most of the app, I'd rather do it on a platform that shows better commitment to its developers."

agenne commented 2 years ago

This is exactly where Microsoft finally has to say honestly if and when the important controls (MediaPlayerElement, InkCanvas and Win2D) will be made available. Not making any statements is very disrespectful to the community.

zipswich commented 2 years ago

This is the only remaining showstopper for our primary app that relies on MediaPlayerElement.

pwillies commented 2 years ago

We are in a similar situation to many on this thread. We want to move up to WebView2, but our app also has a video/audio playing component. So - WinUI 2.8 (with WebView2) is not released - and with no clear timeframe on release. And WinUI 3.0 has WebView2, but is missing MediaPlayerElement etc. - and no clear timeframe on release.

nikolayvpavlov commented 2 years ago

Looking at the number of commits and active contributors draws a dark shadow over my heart. For such a project to succeed, there must be a big team working actively on it. Now, WinUI 3 looks like a hobbist project. MAUI gets more love even in the newsletters, while WinUI 3 is nowhere to be seen.

ianier commented 2 years ago

WinUI 3 is nowhere to be seen

I keep saying Microsoft abandoned UWP way too early. Perhaps they underestimated the work to be done to get WinUI 3 to feature-parity, or just decided that the few of us developing UWP apps should be "sacrificed".

KPixel commented 2 years ago

In all fairness, UWP still works just fine as-is. They just decided that adding more features to it (esp support for .NET 5+) would be way too much work, which is hard to evaluate unless you understand these technologies at the deepest level.

To get back on topic, I am also really surprised and disappointed that they haven't provided a precise roadmap for the MediaPlayerElement. There is likely a big hurdle to overcome, but we don't even know what that is.

ianier commented 2 years ago

In all fairness, UWP still works just fine as-is.

I kind of agree with this statement, as long as you don't rely on too many 3rd party libraries. The feature I'm perhaps hoping the most for is ARM64EC support in .Net Native, which in all fairness, isn't supported in .Net 5/6 either!

nikolayvpavlov commented 2 years ago

But really, look at this: Accouncing Net 7 Preview 1 There is not a single word about WinUI. Not a single one.

asklar commented 2 years ago

Hey folks, I've put together a sample for what could be a replacement for MediaPlayerElement in WinAppSDK for scoped-down scenarios; it's a prototype at this point, doesn't support fullscreen, I haven't tried it with DRM content, and it does not include the full media transport controls, but maybe even in this state it is useful to the folks on this thread. You can find it here: https://github.com/asklar/WinAppSDK-MediaPlayer

PRs welcome :)

agenne commented 2 years ago

It's more of a strategic thing. I am not allowed to use any third party technology that is a core functionality of the application. For apps where that is a minor matter, great thing. Couldn't that be an inspiration for the winui3 developers?

asklar commented 2 years ago

Hi @agenne, Disclaimer: I'm a developer in the Windows Developer platform team :) In order for this control to be part of the built-in WinUI 3 controls., it would likely require significant amounts of additional work to fill in the gaps relative to what the XAML control offers. Even if this was treated as just a stepping stone, it would take work to convert the prototype into a reusable control, integrate it into the existing codebase, etc. so it's "free" as in "free puppy", not as in "free beer" :).

For many apps, those gaps are non-blocking, so they would be able to be unblocked by the code I shared above (maybe they just need a little bit more e.g. a seek bar).

MuleaneEve commented 2 years ago

@asklar Thank you for providing the sample. Having something basic that can fill the need of just playing a media file would indeed alleviate a large part of this issue.

Can you explain what the sample is doing? (You could put it directly in your ReadMe)

Also, is it in C++ because it uses Direct3D? (If so, could something like SharpDX or its successor achieve the same result in C#?)

HermanEldering commented 2 years ago

I have been thinking of a similar approach to @asklar but instead of referencing winrt::Windows::Media::Playback::MediaPlayer I was thinking of using IBasicVideoEffect. I already have the c# code to work with IBasicVideoEffect, but the drawback is that it probably wouldn't have the timing features (droping frames etc).

I'd probably implement my app with WPF or Avalonia then though...

agenne commented 2 years ago

@asklar I can well imagine that it is a lot of work. But planning something and then communicating should be quicker. The Windows Developer platform team should tell us when the feature is coming, and if it's coming at all. Currently it says "in one of the future releases". How are you supposed to plan?

ianier commented 2 years ago

@HermanEldering: in addition to the timing features, unfortunately using IBasicVideoEffect in C# is painfully slow due to the frequent interop calls, even under .Net Native. By looking at @asklar's example I realize that, while awaiting the full-fledged MediaPlayerElement, a MediaPlayerFrameServerPanel control or similar intermediate solution could do the trick for many apps.

agenne commented 2 years ago

Agreed, but a CSharp example would be very helpful

Hanzalah-Adalan commented 2 years ago

planned for future just like the doomsday..

zipswich commented 2 years ago

@asklar Thank you for the effort. We use MPE as follows:

myMediaPlayerElement.Source = MediaSource.CreateFromMediaStreamSource(myCustomMediaStreamSourceVideo);

asklar commented 2 years ago

@zipswich It seems like that should work fine, since MediaPlayer.Source can take the MediaSource returned from CreateFromMediaStreamSource. https://docs.microsoft.com/en-us/uwp/api/windows.media.playback.mediaplayer.source

zipswich commented 2 years ago

@asklar Thank you for the confirmation. I am using Uno Platform. Any pointer to a source to help me integrate your repository with Uno would be greatly appreciated.

asklar commented 2 years ago

@zipswich sorry I'm not familiar enough with Uno or its inner workings, I recommend filing an issue in their repo.

zipswich commented 2 years ago

@asklar How can this be used by a C# based app? Is there an example? The last time I mixed C++ code with C# was using SimpleCommunication

agenne commented 2 years ago

There is another new web site for planning winappsdk. https://portal.productboard.com/winappsdk/1-windows-app-sdk/tabs/1-under-consideration Could you please all upvote the MediaControls Thank You in advance

PierreHenriKT commented 2 years ago

Hello,

Thanks to @asklar's sample, I managed to publish a NuGet package that provides a Media Player Element for WinUI 3. You can find a sample here.

It is still fairly basic and there are some issues to resolve, so the package is marked as prereleased for now.

This package is designed to be temporary: It uses the Microsoft.UI namespace so that, when WinUI introduces its own MediaPlayerElement, you should be able to just remove this package, and change nothing else in your code. Although, I'm not sure if that's ok...

The main issue is that the sample app fails to run when adding the MediaPlayerElement directly in XAML. So for now, that part is done in the code-behind.

If you wish to discuss this package in-depth, please create a new issue in its repo (let's not side-track the goal of this issue).

agenne commented 2 years ago

This is great! Thanks a lot.

emceelovin commented 2 years ago

This is great. The ability to actually create a custom stream source in the problem with EVERY MediaPlayer/Element in windows. EXCEPT the UWP implementation. Which offers in/out stream configurations(paramount IMO for VoIP video chat etc). A/V is paramount in applications. Microsoft always seems to ditch necessary things and work on other stuff that's useless. Great job man!

castorix commented 2 years ago

Agreed, but a CSharp example would be very helpful

Another way to play videos is to embed the WMP control I tested with VB.NET/WinUI 3, with ATL to embed it ("AtlAxWin" class), but I needed a Win32 Region so that it appears...

WinUI3_WMP

brabebhin commented 2 years ago

Hi @asklar

Your sample will crash when attempting to do subtitles. You can check with this URL:

https://mediaplatstorage1.blob.core.windows.net/windows-universal-samples-media/elephantsdream-clip-h264_sd-aac_eng-aac_spa-aac_eng_commentary-srt_eng-srt_por-srt_swe.mkv

castorix commented 2 years ago

I just tested the Media Engine and it seems to work very fine I tested in C# on Windows 10, in Frame-server mode with DXGI or in classic Rendering mode, It is atm the best Video Player that I could test with WinUI 3 (I tested WMP, Direct Show, ...)

WinUI3_MediaEngine

MuleaneEve commented 2 years ago

@castorix Have you tried this simple MediaPlayerElement?

It doesn't have all the features built-in yet, but I think it is the best solution in the long term.

castorix commented 2 years ago

@castorix Have you tried this simple MediaPlayerElement?

Yes, I had tried, but it has the known resizing problem of the SwapChainPanel when scale > 100% By using CreateSwapChainForHwnd , then resizing the target surface from any XAML control, I don't have this problem with the Media Engine or any Direct2D content

PierreHenriKT commented 2 years ago

That issue was resolved a couple of weeks ago. Feel free to test it.

(Edit: There is still an issue when the window is small, though...)