From a developer point of view, VLC has several integration points depending on what you are trying to achieve. They provide different levels of abstractions, capabilities and complexity.

The most common and straightforward way is the LibVLC API. It is the SDK used by most applications that embed VLC, and LibVLCSharp makes it available to .NET developers. If you need to play media in your app, this is the way to go.

Then there is the Lua scripting layer. VLC ships with Lua scripts for things like the HTTP interface, playlist parsers and extensions. It is more limited than native code, but it is a dynamic scripting language that is easy to write and update. It is also, historically, the main approach for writing extensions to the main VLC desktop application.

And then there are native VLC plugins. These target libvlccore directly and provide the most capabilities: video filters, audio filters, demuxers, codecs, renderers, and more.

Unlike a LibVLC setup where the host app loads libvlc and calls into it, native plugins are automatically loaded and unloaded by the VLC core depending on what is needed. The core selects them based on capabilities and priorities.

These modules have traditionally been written in C or C++. More recently, there has been work on writing them in Rust as well, though that is also relatively new and limited to a few modules so far.

This got me thinking. What about C#?

The experiment

I had this idea over 6 years ago but never got around to it.

It is possible through the use of AOT (Ahead-Of-Time) compilation. For .NET developers not familiar with it: AOT compiles your C# code directly to native machine code at build time. No JIT, no runtime code generation, minimal runtime overhead. The CLR is still there under the hood (AOT does not remove it entirely), but what you get is a self-contained native binary with performance characteristics close to C/C++. In our case, that means a native DLL that VLC can load just like any other plugin.

I wanted to see if this was actually possible. Could we write a fully native VLC 4.x plugin in C#, have it loaded by VLC, process video frames, and render things on screen?

Turns out, yes. The result is VLCLR, a framework for building VLC 4.x plugins in C# using Native AOT.

What it looks like

Here is a simplified video filter plugin. The framework provides a base class and Roslyn source generators handle all the entry point boilerplate:

[VLCModule("dotnet_overlay")]
[VLCCapability("video filter")]
[VLCDescription(".NET Native AOT Video Filter Overlay")]
[VLCConfig("dotnet-overlay-opacity", VLCConfigType.Float,
    Default = 1.0f, Min = 0.0f, Max = 1.0f,
    Description = "Overlay opacity")]
public partial class VideoOverlayFilter : VLCVideoFilterBase
{
    protected override bool OnOpen(VLCFilterContext context)
    {
        // Initialize your filter
        return true;
    }

    protected override void ProcessFrame(VLCFrame frame)
    {
        // Access frame.Pixels, frame.Width, frame.Height
        // Modify the frame data directly
    }

    protected override void OnClose()
    {
        // Clean up
    }
}

No C code. No interop stubs. You decorate your class with a few attributes, override the methods you need, and the Roslyn source generator produces the vlc_entry function, the module descriptor, the config options registration, everything VLC needs to discover and load the plugin. Minimal setup, nice developer experience.

Under the hood, the framework provides native type definitions matching VLC 4.x C structures, base classes that handle instance management and callback marshaling, and imaging utilities for frame format conversion and compositing. The source generators inspect your class attributes and generate the exact binary layout VLC expects for module registration. This catches many registration issues at compile time rather than at runtime.

The key parts of the .csproj are what you would expect for a Native AOT library, plus the VLC-specific bits:

<PropertyGroup>
    <PublishAot>true</PublishAot>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <AssemblyName>libdotnet_overlay_plugin</AssemblyName>
</PropertyGroup>

<ItemGroup>
    <ProjectReference Include="..\..\src\VLCLR\VLCLR.csproj" />
    <!-- Source generator for VLC entry points -->
    <ProjectReference Include="..\..\src\VLCLR.Generators\VLCLR.Generators.csproj"
                      OutputItemType="Analyzer"
                      ReferenceOutputAssembly="false" />
</ItemGroup>

<!-- Link against libvlccore for direct P/Invoke -->
<ItemGroup>
    <DirectPInvoke Include="libvlccore" />
    <NativeLibrary Include="..\..\lib\libvlccore.lib" />
</ItemGroup>

The full project file is on GitHub.

You run dotnet publish, drop the resulting DLL into VLC’s plugin folder, and it just works. The video overlay plugin compiles down to a 4.3 MB native DLL. That includes the .NET runtime, a third-party graphics library, and an embedded font. For comparison, VLC’s built-in logo plugin written in C is 30 KB. Most of the difference is the bundled .NET runtime.

Drawing on frames with ImageSharp

For the actual rendering, drawing text and graphics onto video frames, I used the excellent ImageSharp by James Jackson-South. It is a fully managed 2D graphics library with no native dependencies, which makes it a perfect fit for AOT compilation.

The video overlay sample uses it to render .NET debug information directly onto each video frame, here it is in action during video playback:

Things only a native plugin can do

LibVLCSharp does let you access raw video frames from the LibVLC API for processing. But some things are only possible as a native plugin.

The repo includes a subtitle renderer sample. Subtitle rendering is not a capability exposed by the LibVLC API. You need a native plugin for this.

VLC’s subtitle pipeline sends text segments to the renderer with full styling metadata: font families, sizes, colors, outline thickness, shadow offsets, and background regions. The C# renderer receives these segments, walks the styling tree, builds the layout with ImageSharp’s text engine, and returns a rendered pixel region that VLC composites onto the video.

Outline rendering was one of the trickier parts: the plugin draws outlines as offset copies of the text in 8 directions, then layers the fill text on top. Getting this to look right while keeping per-frame rendering fast took some iteration.

This is what makes native plugins interesting. VLC already has a Whisper-based speech-to-text module. Imagine building something similar in C# with access to the .NET ML ecosystem (speech recognition, real-time video analysis, intelligent subtitle generation), all running inside VLC as a native plugin. These are things that are simply not reachable from the LibVLC API. If you are a .NET developer and have ever wanted to extend VLC itself rather than just embed it, this is that door.

What was hard

The trickiest part was marshaling. VLC’s internal C structures are complex: deeply nested, with unions, flexible array members, and platform-specific layout differences. Getting the C# struct definitions to match the exact binary layout VLC expects required careful work. A single field offset being wrong means silent corruption or a crash with no useful stack trace. This is the kind of interop where you spend more time reading C headers than writing C#.

The VLC 4.x plugin API is itself still evolving, which adds another layer. Some things are harder to express in managed code than others, and memory management across the native/managed boundary requires care.

Performance

A common concern with managed code in a video pipeline is latency. In practice, the video overlay filter processes 1080p frames without visible frame drops during playback. The hot path is a memory copy from VLC’s plane buffer into an ImageSharp image, the drawing operations, and a copy back, all on contiguous memory. There is no GC pressure per frame since the buffers are pre-allocated and reused. AOT-compiled code does not have JIT warmup, so the first frame is as fast as the thousandth.

Current status

This is a proof of concept. The sample plugins work and I use them during development, but the API surface and struct definitions will evolve alongside VLC 4.x.

Currently it only runs on Windows. Linux and macOS support requires building against the platform-specific VLC SDK and testing the struct layouts. Both .NET and VLC are cross-platform, so no fundamental blockers exist. The same applies to Android and iOS.

What this demonstrates is that the .NET Native AOT toolchain is now mature enough to produce plugins for complex native applications like VLC.

Try it yourself

git clone https://github.com/mfkl/vlclr.git
cd vlclr
dotnet publish samples/VideoOverlay -c Release -r win-x64

Copy the resulting DLL from samples/VideoOverlay/bin/Release/net10.0/win-x64/native/ into your VLC 4.x plugins/video_filter/ folder, and play a video. Note that VLC 4.x is still in development, so you will need a nightly build. See the README for full setup instructions including where to get the VLC 4.x nightly and SDK.

What’s next

There are more plugin types to explore (audio filters, demuxers, stream outputs), each with their own callback signatures and lifecycle. The framework currently covers video filters and subtitle renderers, but the pattern is the same: define the C# structs, write a base class, and let the source generator handle registration.

The code is on GitHub: mfkl/vlclr. Contributions, feedback, and ideas are welcome. Open an issue or reach out on GitHub.

I designed the architecture and APIs for this project. Claude wrote the implementation. Having an AI handle the code helped me finally get started on something I had been putting off for years, and move significantly faster than I would have on my own.

I just launched pkgstore.io, and I want to tell you why. 🎉

The Discovery Problem 🔎

The .NET ecosystem has hundreds of high-quality commercial packages: Uno Platform, Avalonia, Blazorise, Iron Software, Hangfire, and many more you’ve probably never heard of.

But where do you find them?

NuGet.org lists everything, but it doesn’t distinguish between a weekend hobby project and a business-backed library with professional support. Google searches surface scattered blog posts and outdated comparisons. You find packages by accident, word-of-mouth, or because you already know the big vendors.

For developers: Discovery is fragmented and inefficient.

For publishers: You’ve built a quality library, maybe proprietary, maybe open-source with commercial licensing, but how do developers find you?

For companies: When you need guarantees around support, security updates, maintenance, and SLAs, how do you discover which packages offer that?

Sustainability and Support 🛡️

Here’s something important: not every project can or should go commercial, and that’s completely fine.

Open-source community projects are the backbone of the .NET ecosystem. Many libraries thrive without a business model, maintained by passionate developers and communities.

But let’s be honest: for niche, specialized, large, or complex software, donations rarely work for long-term sustainability of open source projects.

If you’re building a library that needs consistent maintenance, security updates, professional support, or compliance guarantees, you need a real business model:

• 💼 Commercial proprietary software (licensing, seats, tiers)
• 🤝 Open-source with paid support/consulting
• ⚡ Open-core and freemium models
• 📋 Dual licensing
• ✨ Premium builds and features

For companies evaluating packages, commercial backing often means:

• Paid support options
• Regular security updates
• Long-term maintenance commitments
• Legal protection and licensing clarity
• Professional documentation and onboarding

What I built 🚀

pkgstore.io is a curated, searchable directory of commercially-backed .NET packages.

Phase 1 (live now):

• ✅ 16 publishers already listed (Uno Platform, Avalonia, Blazorise, Iron Software, Hangfire, and more)
• 🧹 Clean, searchable directory
• 🔗 Direct links to packages, documentation, and pricing
• 🆓 Free listing for all publishers
• 📋 Clear inclusion criteria (support, pricing, maintenance signals)

Whether you’re an enterprise vendor or an indie developer, if you have a sustainable business model around your .NET package, you belong here.

Get Started

• 🔎 Developers: Browse the directory → pkgstore.io
• 📰 Publishers: Get listed → sign up to the newsletter on pkgstore.io

What’s Coming 🔔

This directory is just phase one.

I’m building pkgstore.io to become the home for commercial .NET packages, with features that will fundamentally change how publishers reach developers and how developers discover tools.

But I wanted to start with something useful today. Get feedback. Learn what the community actually needs. Then build what matters.

More announcements coming soon. 👀

Following the official deprecation of Xamarin.Forms, we are announcing the LibVLCSharp integration for MAUI.

Initial release

Starting from 3.8.5, LibVLCSharp.MAUI officially supports iOS (net6.0+) and Android (net7.0) modern .NET MAUI targets.

We have had some trouble with the Android version, since some underlying tooling changed and we found a regression affecting our wanted final deployment structure. But we worked around it for now (or until it gets fixed?).

What’s next for LibVLCSharp.MAUI?

As we get more user feedback and tweak these initial releases, we will be looking into expanding platform support with macOS and Windows (WinUI) support.

Another exciting feature will be to bring back our MediaElement control from Xamarin.Forms ashes, and make it MAUI-ready. This control was very popular as it was plug-and-play and came with many implemented features.

We are always looking for contributors and corporate sponsors for this work. Feel free to reach out if you can help!

Today, we are announcing the release of VLC for Unity (macOS) on the Videolabs Store!

This Unity plugin allows you to use a LibVLC-powered video player in your Unity-based macOS apps and games. Whether you need to support a rare video format, live streaming, HLS, RTSP or play a 4K video in your latest production, we got you covered. Feel free to give it a try!

All LibVLC features available in your macOS Unity game

Given that this plugin is using LibVLCSharp (which uses LibVLC), it exposes more or less the same feature set and same codecs support than VLC, such as:

• Play every media file formats, every codec and every streaming protocols
• Run on every platform, from desktop (Windows, Linux, Mac) to mobile (Android, iOS) and TVs
• Hardware and efficient decoding on every platform, up to 8K
• Network browsing for distant filesystems (SMB, FTP, SFTP, NFS…) and servers (UPnP, DLNA)
• Playback of Audio CD, DVD and Bluray with menu navigation
• Support for HDR, including tonemapping for SDR streams
• Audio passthrough with SPDIF and HDMI, including for Audio HD codecs, like DD+, TrueHD or DTS-HD
• Support for video and audio filters
• Support for 360 video and 3D audio playback, including Ambisonics
• Able to cast and stream to distant renderers, like Chromecast and UPnP renderers.

And more!

Hardware acceleration on macOS with Unity and LibVLC

Hardware acceleration is often a highly requested features for video players. Decoding videos with the GPU allows much more efficient decoding allowing to playback high res samples that the CPU could not, while saving battery life and CPU cycles for other apps.

On macOS, GPU hardware video decoder access is performed through either OpenGL or Metal.

At the time of writing, LibVLC does not yet offer a fully featured and battle-tested Metal-based video output for Apple Platform, only OpenGL is available.

So how to do? 🤔

Well, a nice workaround was implemented by Alexandre Janniaux to be able to perform OpenGL calls within a Metal context, notably using CVMetalTextureCacheCreateTextureFromImage.

This way both LibVLC and Unity constraints are satisfied, and both iOS and macOS on Unity use the same Unity Metal backend.

Testing VLC in your Unity for macOS app

As of today, the initial VLC for Unity macOS release includes both Intel x64 and Apple Silicon ARM64 binaries.

It is possible to build through XCode by generating an XCode project file, or directly generating the final app binary through the Unity Editor. Running VLC Unity in the Unity Editor is also supported, although it can sometimes take a while to load all the libraries. We will be working on speeding that up next.

✨ This is the second Apple platform supported by VLC Unity, after the iOS release last month. Future possible Apple target platforms, depending on your interest, could be tvOS and visionOS! Do reach out if you are interested in any platform not yet supported.

Feel free to let me know what you think on Twitter.

Today, we are announcing the release of VLC for Unity (iOS) on the Videolabs Store!

This Unity plugin allows you to use a LibVLC-powered video player in your Unity-based iOS apps and games. Whether you need to support a rare video format, live streaming, HLS, RTSP or play a 4K video in your latest production, we got you covered. Feel free to give it a try!

All LibVLC features available in your iOS Unity game

Given that this plugin is using LibVLCSharp (which uses LibVLC), it exposes more or less the same feature set and same codecs support than VLC, such as:

• Play every media file formats, every codec and every streaming protocols
• Run on every platform, from desktop (Windows, Linux, Mac) to mobile (Android, iOS) and TVs
• Hardware and efficient decoding on every platform, up to 8K
• Network browsing for distant filesystems (SMB, FTP, SFTP, NFS…) and servers (UPnP, DLNA)
• Playback of Audio CD, DVD and Bluray with menu navigation
• Support for HDR, including tonemapping for SDR streams
• Audio passthrough with SPDIF and HDMI, including for Audio HD codecs, like DD+, TrueHD or DTS-HD
• Support for video and audio filters
• Support for 360 video and 3D audio playback, including Ambisonics
• Able to cast and stream to distant renderers, like Chromecast and UPnP renderers.

And more!

Hardware acceleration on iOS with Unity and LibVLC

Hardware acceleration is often a highly requested features for video players, especially on mobile devices. Decoding videos with the GPU allows much more efficient decoding allowing to playback high res samples that the CPU could not, while saving battery life and CPU cycles for other apps.

On iOS, GPU hardware video decoder access is performed through either OpenGL ES or Metal. While according to Apple, OpenGL ES is officially deprecated on iOS, it is still working, the App Store still accepts submissions of apps that rely OpenGL ES and in fact, many games, browsers and video players (amongst others) still make use of OpenGL ES for various reasons.

However, Unity removed the option to pick OpenGL ES as a graphics API backend when building iOS apps using Unity. Metal is the default and only option.

At the time of writing, LibVLC does not yet offer a fully featured and battle-tested Metal-based video output for Apple Platform, only OpenGL is available.

So how to do? 🤔

Well, a nice workaround was implemented by Alexandre Janniaux to be able to perform OpenGL ES calls within a Metal context, notably using CVMetalTextureCacheCreateTextureFromImage.

This way both LibVLC and Unity constraints are satisfied, and the bridge between both ecosystems on iOS is complete! 🙌

Testing VLC in your Unity for iOS app

As of today, the initial VLC for Unity iOS release includes ARM64 binaries only. The simulator support will come in a later release.

However, as you might know already, iOS apps can be ran on modern Apple Silicon Macs which can speed up the development experience. Deploying to an iPhone device can be time consuming and a hassle.

We also included initial support for the macOS platform in the VLC Unity asset. This allows you to test VLC features and develop your app using the macOS Editor (or XCode builds) for faster iteration.

✨ This is the first Apple platform supported by VLC Unity. A future macOS release will come soon, tvOS could be an option as well. Do reach out if you are interested in any platform not yet supported.

Feel free to let me know what you think on Twitter.

VLC for Unity integration

For the readers unaware, we started distributing binaries on the Unity Store for the open-source VLC for Unity integration back in December 2019.

The integration essentially was a bridge between the Unity game engine and the VLC multimedia engine, allowing to build your own media-player based on the VLC engine in Unity-based games. Both Unity, through Mono, and LibVLC are highly portable so this is a compelling argument for this cross-platform integration.

Since the start, we have had many users downloading the assets from the Unity Store for their Unity apps and games when requiring demanding multimedia solutions. We had 3 assets targeting specific platforms:

• Windows,
• UWP,
• Android.

Unity Store ban

This all changed at the end of the summer 2023 when Unity emailed us the following:

And just like this, our publisher account was instantly banned.

After months of slow back-and-forth over email trying to find a compromise, including offering to exclude LGPL code from the assets, Unity basically told us we were not welcome back to their Store, ever. Even if we were to remove all LGPL code from the Unity package.

Where it gets fun is that there are currently hundreds if not thousands of Unity assets that include LGPL dependencies (such as FFmpeg) in the Store right now. Enforcement is seemingly totally random, unless you get reported by someone, apparently.

It gets better… Unity itself, both the Editor and the runtime (which means your shipped game) is already using LGPL dependencies! Unity is built on libraries such as Lame, libiconv, libwebsockets and websockify.js (at least). Full list of open-source Unity dependencies here.

So Unity gets to use and benefit from LGPL open-source libraries, games built with Unity depend on LGPL code by default (hello glibc!), but publishers and Unity users are not allowed to do so through the Unity Store?

Introducing the Videolabs Store

If you are a company requiring multimedia products or consulting for your own projects, this store will be of interest to you.

After our assets got removed, previous and new customers started emailing us about the status of VLC for Unity. Are we going to keep maintaining the assets? How to get build updates? etc.

Numerous companies make use of the LibVLC SDK and other related technologies (like FFmpeg).

For this reason, we decided to publish a simple Store on the Videolabs website.

This way, existing and new customers can still purchase the binaries for the open-source VLC Unity plugin without our presence on the Unity Store. Of course, users can still build VLC for Unity themselves, as it is open source.

Flexible multimedia consulting packages

Sometimes users will run into issues or request a new feature and while the community can sometimes help, the limited time of a few volunteers only goes so far. I have written about OSS sustainability before and that is very much on topic here.

It is in the best interest of both open-source project maintainers and commercial consumers to have a clear products and services offering for a given project, and that is what we have created with the Videolabs Store for both LibVLC and FFmpeg.

The Videolabs team is composed of VLC and FFmpeg experts in most protocols, formats and platforms.

If you are using or planning to use LibVLC or FFmpeg in your project and need help, whether it be custom builds, bug fixes, SDK integration or simply answers to your questions for your specific needs, these packages are for you!

We have created 3 multimedia consulting packages: 3 hours, 10 hours and 24 hours. They can be purchased for a one-time service or a monthly subscription.

No matter which OS platform or toolkit you are building with, we can help.

Other products

The LibVLCSharp commercial license and the LibVLC ebook can also be found in the Videolabs Store, as well as other upcoming products such as Kyber, our new ultra low latency game/desktop streaming and remote control SDK, and more game engine integration such as Unreal.

The NuGet VideoLAN account just reached 2 million downloads in the .NET ecosystem.

As we reach this new arbitrary milestone, I’d like to reflect on the current LibVLC ecosystem developments and what is coming next for our users.

LibVLC 4 support

We are working hard towards the support of LibVLC 4 in LibVLCSharp. This includes surfacing new native APIs and modifying existing ones, while keeping in mind ease of use and .NET conventions for a seamless developer experience across all supported platforms.

We also work closely with core VLC developers to provide feedback and help shape the upcoming LibVLC APIs that will enable new capabilities for your applications. A couple of examples of new exciting LibVLC 4 APIs (already/eventually available in all programming languages through LibVLC bindings) include:

• A new mediaplayer recording API

/**
 * Start/stop recording
 *
 * \note The user should listen to the libvlc_MediaPlayerRecordChanged event,
 * to monitor the recording state.
 *
 * \version LibVLC 4.0.0 and later.
 *
 * \param p_mi media player
 * \param enable true to start recording, false to stop
 * \param dir_path path of the recording directory or NULL (use default path),
 * has only an effect when first enabling recording.
 */
LIBVLC_API void libvlc_media_player_record( libvlc_media_player_t *p_mi, 
                                            bool enable, const char *dir_path);

• A new advanced mediaplayer custom video rendering GPU API.

This rather complex LibVLC API allows consumers to handle the hardware accelerated rendering themselves, instead of pointing LibVLC to a Window handle. Performant game engine integration, such as Unity3D and Unreal, is one of the key use cases of this new LibVLC 4.0 API.

/**
 * Set callbacks and data to render decoded video to a custom texture
 *
 * \warning VLC will perform video rendering in its own thread and at its own rate,
 * You need to provide your own synchronisation mechanism.
 *
 * \param mp the media player
 * \param engine the GPU engine to use
 * \param setup_cb callback called to initialize user data
 * \param cleanup_cb callback called to clean up user data
 * \param resize_cb callback to set the resize callback
 * \param update_output_cb callback to get the rendering format of the host (cannot be NULL)
 * \param swap_cb callback called after rendering a video frame (cannot be NULL)
 * \param makeCurrent_cb callback called to enter/leave the rendering context (cannot be NULL)
 * \param getProcAddress_cb opengl function loading callback (cannot be NULL for \ref libvlc_video_engine_opengl and for \ref libvlc_video_engine_gles2)
 * \param metadata_cb callback to provide frame metadata (D3D11 only)
 * \param select_plane_cb callback to select different D3D11 rendering targets
 * \param opaque private pointer passed to callbacks
 *
 * \note the \p setup_cb and \p cleanup_cb may be called more than once per
 * playback.
 *
 * \retval true engine selected and callbacks set
 * \retval false engine type unknown, callbacks not set
 * \version LibVLC 4.0.0 or later
 */
LIBVLC_API
bool libvlc_video_set_output_callbacks( libvlc_media_player_t *mp,
                                        libvlc_video_engine_t engine,
                                        libvlc_video_output_setup_cb setup_cb,
                                        libvlc_video_output_cleanup_cb cleanup_cb,
                                        libvlc_video_output_set_window_cb window_cb,
                                        libvlc_video_update_output_cb update_output_cb,
                                        libvlc_video_swap_cb swap_cb,
                                        libvlc_video_makeCurrent_cb makeCurrent_cb,
                                        libvlc_video_getProcAddress_cb getProcAddress_cb,
                                        libvlc_video_frameMetadata_cb metadata_cb,
                                        libvlc_video_output_select_plane_cb select_plane_cb,
                                        void* opaque );

The version 4 of LibVLC is still in development, so the API is not frozen yet, but the core functionality is already quite stable and used by many clients on all platforms, as well as the Unity integrations.

Unity

We recently shipped support for the UWP platform in VLC Unity, enabling the use of LibVLCSharp and LibVLC in Microsoft HoloLens devices, desktop and Xbox platforms, in addition to the existing Android and Windows classic targets.

As we are finalizing support for VLC Unity on iOS and macOS, we will then focus on general developer experience improvements as well as documentation efforts to solidify the Unity integration.

The feedback we have received so far is great: the video decoding performance is unmatched and VLC Unity is one of the most capable and advanced media player asset currently available on the Videolabs Store in terms of features.

Uno Platform

While we initially released a LibVLCSharp / Uno integration back in 2019, it has not been updated for a while to keep up with the latest Uno releases and accompanying API changes.

This may all change soon, now that Uno decided to use LibVLC for their Linux mediaplayer support.

We are looking forward to work together to improve the developer experience for .NET developers in the multimedia space across all platforms that Uno and VLC support.

Commercial licensing and consulting offering

Exactly 2 years ago, we introduced the LibVLCSharp Commercial License in an effort to secure the long term maintenance of the project. I firmly believe companies should be put to contribution when it comes to opensource sustainability, not individuals, and I have written about this topic before.

If your company relies on LibVLCSharp for their commercial products, we encourage you to support the project and help secure the long term maintenance by purchasing a commercial license today.

For more general multimedia needs, such as consulting, training, specific LibVLC / FFMPEG features or bug fixes, or even new platforms support, Videolabs is the partner of choice with experts on all platforms.

LibVLC community update

LibVLC Discord server

Almost 3 years ago, we created the LibVLC Discord Server to foster the LibVLC community with both LibVLC users and bindings maintainers, for all 12 supported programming languages.

The Discord server has grown steadily to 1200+ members and it is a place where LibVLC users can get support from other members of the LibVLC community. Bindings maintainers also help each others out at times.

When someone has a cool use case or sample they want to share with the community, they can post in the showcase channel on the LibVLC Discord. For example, that is how I learned about the existence of the VLC support in Minecraft, using the awesome VLCJ bindings from Caprica.

Zig

The latest cool kid on the block, ziglang, made an appearance in the VLC community with libvlc-zig which allows Zig developers to enjoy a compelling developer experience while using LibVLC and Zig. We are looking forward to see the apps you build with Zig and LibVLC!

While libvlc-zig focuses on the LibVLC API, it is also possible to use Zig to build native VLC plugins using the lower level VLC API, such as this vlc-mixer example.

Stay tuned.

Today, we are announcing the initial release of VLC for Unity (UWP) on the Videolabs Store!

This Unity plugin allows you to use a LibVLC-powered video player in your Unity-based UWP apps and games. Whether you need to support a rare video format, live streaming, HLS, RTSP or play a 4K video in your latest production, we got you covered. Feel free to give it a try!

All LibVLC features available in your Unity game

Given that this plugin is using LibVLCSharp (which uses LibVLC), it exposes more or less the same feature set and same codecs support than VLC, such as:

• Play every media file formats, every codec and every streaming protocols
• Run on every platform, from desktop (Windows, Linux, Mac) to mobile (Android, iOS) and TVs
• Hardware and efficient decoding on every platform, up to 8K
• Network browsing for distant filesystems (SMB, FTP, SFTP, NFS…) and servers (UPnP, DLNA)
• Playback of Audio CD, DVD and Bluray with menu navigation
• Support for HDR, including tonemapping for SDR streams
• Audio passthrough with SPDIF and HDMI, including for Audio HD codecs, like DD+, TrueHD or DTS-HD
• Support for video and audio filters
• Support for 360 video and 3D audio playback, including Ambisonics
• Able to cast and stream to distant renderers, like Chromecast and UPnP renderers.

And more!

Hardware-accelerated video playback in your UWP Unity apps and games

The 4.0 development version of LibVLC provides a powerful API which allows to perform custom rendering yet retaining hardware accelerated decoding.

In the context of Unity, this means using VLC for Unity allows you to use video frames as GPU textures in your Unity games. For UWP, this solution is based on Direct3D11.

This is as simple to use for you as writing

MediaPlayer.GetTexture(out texture);

and uploading it to Unity for post-processing in your game scene.

The CPU architectures supported on UWP by VLC Unity are as follows:

• arm64-v8a,
• x86_64.

Xbox and Hololens devices, in addition to regular Windows 10/11 desktop devices are therefore supported. This is the 3rd platform supported by VLC for Unity, in addition to Windows Classic and Android.

Feel free to let me know what you think on Twitter.

Download the Free Trial version

Today, we are announcing the initial release of LibVLCSharp for WinUI on NuGet

WinUI

LibVLCSharp has had support for the Universal Windows Platform (UWP) since the early days. Before LibVLCSharp, the work to integrate LibVLC with the UWP platform and make the LibVLC engine work well on it, was pioneered by the now defunct VLC for WinRT project.

WinUI is the next evolution of the modern UI toolkit for the Windows desktop after UWP (unfortunately, the Xbox target is not supported with WinUI).

As of LibVLCSharp version 3.7.0, building multimedia apps using WinUI 3 is now supported with LibVLC. Expect the usual goodies such as default hardware decoding enabled.

Both Packaged and Unpackaged WinUI apps are supported with LibVLCSharp.

There are several important caveats and changes from the previous UWP LibVLCSharp support that I will detail below, for users migrating or supporting both UWP and WinUI.

API Breaking change for existing UWP users

When upgrading to LibVLCSharp version 3.7.0, users currently targeting UWP will need to address a build failure as there was a needed namespace change.

In your XAML files:

-xmlns:lvs="using:LibVLCSharp.Platforms.UWP"
+xmlns:lvs="using:LibVLCSharp.Platforms.Windows"

In your C# files:

-using LibVLCSharp.Platforms.UWP;
+using LibVLCSharp.Platforms.Windows;

This should be quick and as painless as possible to fix as you upgrade to LibVLCSharp 3.7.0 in your UWP applications. The minor version of LibVLCSharp is bumped according to our documented versioning strategy.

LibVLC build type

With UWP apps using LibVLCSharp, the user needs to add a special, custom-built LibVLC variant, the VideoLAN.LibVLC.UWP nuget package. This has always been the case and is due to the expectation of the underlying runtime of the UWP platform.

For WinUI targets, the classic Windows LibVLC build, VideoLAN.LibVLC.Windows, must be used and only from version 3.0.18 minimum. Using a UWP LibVLC build will not work. As always, starting from the official sample app is a good idea.

Minimum Target Framework Version

The minimal WinUI TFM supported version is net6.0-windows10.0.17763.0. Do make sure you target it for your WinUI project (or anything above).

As we release this initial support of WinUI on NuGet, please make sure to tell us if you encounter any issue and what apps you build with LibVLCSharp for WinUI!