DVD playback

[brabebhin]

I was minding my own business the other day, when I realized I had some DVDs around which I never used. So then I remembered one of the things our framework doesn't support is DVD playback.

So then I grabbed one of the DVDs, hooked it up to my "old" laptop which still comes with one of these readers, and fired it up.

So after a few minutes of research, we have the following

1. UWP allows us to access the DVD. In fact, if we target past 16299, .net standard comes with a little class called DriveInfo, which allows us to enumerate stuff on a DVD.

2. FFmpegInterop can open most of the file streams already on the DVD.

3. the only thing we are missing is the intro menu, where one selects episodes/scenes/chapters whatever. Since VLC can render that thing, and the intro seems different for various DVDs, I am thinking maybe we can too. VLC is probably rendering something on the disk itself.

I am sure there is more research needed here, but what say you, @lukasf ?

[brabebhin]

Unfortunately, I did not have much time to dig deeper into this. xD

It is a nice to have feature, but not really necessary.

[lukasf]

There are DirectShow APIs to render DVDs, including menus and stuff. I used them years ago. But they are not available for WinRT. BluRay is not available as well (which would be much more interesting).

FFmpeg can include libbluray and libaacs to decode BluRays, maybe this will also allow to render the menus and stuff. I guess this is how VLC does it. But I don't know if these libs can be used in WinRT, and I currently don't have the time to investigate this. I expect it to be lots of effort to get this working correctly, including full menu support and mouse interaction.

[brabebhin]

Come to think of it, perhaps sticking to UWP is not that wise anymore. Looks like desktop apps can interop almost freely with winRT APIs. And they run in packages with full trust and without the random limitations of UWP.

[touseefbsb]

Dvd playback has high demand in the user base and there are some apps out there which do it so i assume technically its possible i think movies and tv also supports it and it is a uwp

[brabebhin]

All those apps are packaged desktop apps.
it may be trivial to go from UWP to packaged desktop apps with xaml islands though.

[touseefbsb]

well we do have FileSystemAccess capability in uwp, would that help or is that still limiting for our purpose?

[lukasf]

I don't see a problem in adding support for DVD/BluRay (dropping UWP compatibility), as long as it is still possible to build a pure UWP version of FFmpegInterop. I am not sure though about the performance of Xaml Islands. High resolution video rendering is heavy load on the video system, and the interop from UWP to WPF might kill performance. When I created a WPF based video player years ago, I opened a separate borderless WinForms window and overlayed it on top of the WPF window, because rendering directly into WPF resulted in poor performance (at least when playing HD material). However, that is years ago, and maybe they can render with better performance, since both WPF and UWP are somehow based on Direct3D.

You could try even now to create a desktop app with XamlIslands and use FFmpegInterop from that. It should work right away (theoretically). Then you can see how the performance (and CPU load) is when playing high res / 4K stuff.

But even if performance is fine, it will be a lot of work, and someone has to do all that. For BluRay through ffmpeg: Fork libbluray and libaacs, create a WinRT platform target build config, make the libs build successfully, create an option in our build script so it can link those libs into ffmpeg, then find out how to use all that stuff and make it work.

For DVD I don't know right now. Those old DirectShow APIs cannot be used, since they will only render to GDI or WinForms and will decode through DirectShow, which is not compatible at all with our MediaFoundation-based UWP pipeline. It might be possible to do DVD playback through ffmpeg as well (similarly to BluRay), but on a short search I did not find something in there.

[brabebhin]

They seem to be supporting MediaPlayerElement in xaml islands, i expect it to render video properly.

My plan is to host the entirety of my app within an xaml island and use the wpf app as host, since it provides better access to the system. I do not believe it to ne worth it though, as I expect the lines to continue to blur to the point where one can call win32 apis from uwp.

Even if we have broadFileSystem restricted capability, i find uwp file APIs very slow compared to classic .Net

[lukasf]

WinUI 3.0 will allow desktop apps to directly create and use UWP UIs, without any Xaml Islands interop layer. Still, I feel like this feature is not going to happen anytime soon, or an I wrong @mcosmin222? Can we close this issue for now, or are you going to do some more investigations in this area?

[brabebhin]

we can close it. I didn't have much time to do further research in this area, and I doubt I will in the coming weeks.

[villagra]

Xaml islands will be still required

…

On Sun, Sep 22, 2019, 8:55 AM mcosmin ***@***.***> wrote: we can close it. I didn't have much time to do further research in this area, and I doubt I will in the coming weeks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#125?email_source=notifications&email_token=AAH5RMIRXB2ITUDDGKC2CU3QK4JFPA5CNFSM4H6WPRJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7I7X5Q#issuecomment-533855222>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH5RMJQR66IMLNBWN2ZAQ3QK4JFPANCNFSM4H6WPRJQ> .

[brabebhin]

Thought so. I looked over the road map. But I think this is roughly the future: desktop host app + xaml island. This solves a lot of problems, like efficient file enumeration (winRT is just too slow for mass file processing), easier life cycle management etc. I will try to do a performance test and see how media playback messures up

It does look like UWP xaml is dead come 2020.

[lukasf]

As per my understanding, the plan for future WinUI is that you can directly host it from a Win32 desktop app, without XAML Islands. It might not make it into initial WinUI 3.0 release, but I think it is high on the list. MS is finally aware that people really want this to replace their old WPF UIs, without having to switch their LOB applications to the UWP App model.

[lukasf]

Also check this issue here:

microsoft/microsoft-ui-xaml#1365

There is no answer yet, but this is also what I understood. WinUI desktop will render into GDI, without intermediate WPF layer. I'd guess that WinUI UWP will still have best performance (direct rendering into Windows compositor), with WinUI desktop coming second and Xaml Islands third.

[brabebhin]

Alright, I have a sample app running ^^ any suggestions for a performance intensive file? :D

preferably something that's not HEVC ^^ I don't have the entire ffmpeginterop MSS setup, so just system supported formats are available.

Well, technically, I could host my entire app inside an WindowsXAMLHost .... meh, this is actually quite complicated: you cannot just reference the UWP project from WPF. So in reality, it will take a bit of refactoring and project modifications to migrate an UWP to Desktop app (probably one will need to wrap the existing UWP app as a Windows Runtime Component and reference that in .net). Quite ironic that a few years back Microsoft was doing the exact opposite: show us how to move from WPF to UWP.

Anyway, I tested with a bunch of files with wrapped MediaPlayerElement and performance seems OK. On the other hand, I am running this from a fairly recent CPU (i7 6700HQ) with SSD storage.