VLC for WinRT: “Partial hardware decoding”
VLC pushed out a new update for Windows Phone which enables “Partial Hardware Decoding”. Now, this is a good thing. It enables all phones to be able to render out high quality video to nearly all devices, low to high end. The thing is, it’s not VLC doing it.
As many people know, at the time of this writing, Libvlc does not support hardware acceleration for ARM devices (So, Windows Phone and Windows RT). This is not ideal, but verses not having a release at all, it’s better than nothing. At least you know that VLC is actually rendering video. There is work being done to correct this, but, of course, it takes time. And apparently, with enough people on the Internet bitching about it, something had to be done.
As a stop gap, VLC for WinRT is now using MediaElement for video playback. If the video you picked does not support MediaElement, then it falls back to Libvlc. Let’s look at some code:
(InitializePlayback: MediaPlaybackViewModel.cs)
// First set the player engine // For videos AND music, we have to try first with Microsoft own player // Then we register to Failed callback. If it doesn't work, we set ForceVlcLib to true if (UseVlcLib) _playerEngine = PlayerEngine.VLC; else { var path = ""; if (!string.IsNullOrEmpty(media.Path)) path = Path.GetExtension(media.Path); else if (media.File != null) path = media.File.FileType; _playerEngine = VLCFileExtensions.MFSupported.Contains(path.ToLower()) ? PlayerEngine.MediaFoundation : PlayerEngine.VLC; }
Now on Windows Phone, we were already using the default Microsoft frameworks for audio. If the file did not support it (Ex. FLAC) then it would use Libvlc, but it would not play in the background. Now, I’m somewhat forgiving over why this had to be done. The Background Audio API on Windows Phone is, quite frankly, a royal pain in the ass to implement, and currently does not mesh well with Libvlc. It’s possible, but not practical. For video, I’m less forgiving.
To me, users are using VLC because they expect VLC to be, you know, running the file. They want the flexibility the library brings. That’s why so many people are excited about it being on the platform. But technically, right now, it’s not doing that. The built in frameworks are. If it works in the built in video player, it works here too. Exactly the same. Sure, people will be able to watch HD on their devices right now, but they could do that in other video apps on the platform. And now the video they watch will be acting exactly the same as it would in those other apps, just with a different UI... so to me, right now, VLC for WinRT is not nearly as special as it once was.
Now, of course, this stuff going to be changed out when actual hardware acceleration is ready, but I feel changing this right now to use media element is a waste of development time. I would argue (many times, as I did in the VLC ports chat room), that instead of taking the time to implement these services, other bugs and issues could have been addressed that are more important. The “Universal” UI is still a bitch to maintain, and it’s still being actively changed. The view models are a mishmash of operations and there is no separation between where they should go. The IValueConverters contain tons of business logic that should not belong there.
But that’s me.
