FFmpeg.AutoGen VS Uno Platform

It's been a while since I messed with this stuff, but FFmpeg.AutoGen it's pretty good once you get a few wrappers set up to abstract away all the ugly API calls.

I would recommend you take a look at https://github.com/Ruslan-B/FFmpeg.AutoGen which provide thin wrapper for FFMPEG for dotnet. Because this is thin wrapper, you probably have to teach yourself a bit on FFmpeg APi which is a pain. Maybe you can try other libraries which do not claim mobile support, I think you just need native DLL to make other project works.

I have some problems with outdated methods like "avcodec_decode_video2", currently frame splits to three horizontally and turns into black-white, i can't provide my code now because im not at pc but it really same to https://github.com/Ruslan-B/FFmpeg.AutoGen/blob/master/FFmpeg.AutoGen.Example/VideoStreamDecoder.cs, it not related to C# because i using FFmpeg.Autogen (unsafe bindings without any wrapping)

https://github.com/Ruslan-B/FFmpeg.AutoGen is great, but quite tricky to use. Basically you'll need to create an AVFormatContext with a custom AVIOContext (pb field, see libavformat docs). This IOContext contains the read() and seek() functions, which you'll create using avio_alloc_context(). For the seek() implementation, just make a new request with Content-Range for subsequent reads. After everything is set up, you can just seek based on a time code using avformat_seek_file().

We used libav directly with FFmpeg.Autogen, with some manual tweaking to certain structures that allowed us to inject proprietary ad timing metadata (not my decision, that came from higher up). Gave me a great excuse to learn how .NET interop works.

It actually uses the native FFmpeg C API directly (libav) instead of the command line tool, with FFmpeg.AutoGen.

And Uno Platform (https://platform.uno/) is akin to React Native in terms of native controls usage.

also UNO Platform (C#) which is suitable for simple or complex cross platform business applications : https://platform.uno/

Why is this a problem? At face value, it isn't a problem. Taking a step back at a more global level, what does "uComponents" mean to the rest of the world? Many of the .NET developers who heavily use NuGet may have not even heard of Umbraco CMS, let alone a 3rd party plugin for it. What if people from the Uno Platform community are browsing NuGet for some kind of components extension library? You can see, this could get confusing outside the scope of the Umbraco community/ecosystem. On top of this, uComponents was developed against Umbraco v4, with its last release in 2016, now it's there to be lingering on the NuGet repository until the end of time, set in stone.

Not a fan of XAML after trying to get into it, but there is Uno Platform. It wraps native widgets on mobile, just like React Native (which is good for accessibility), and uses C#. https://platform.uno/

My guess is that it's mainly focused on mobile. On Windows, it has no overhead (behaving like a normal WinUI 3 app), on macOS I think it uses Catalyst by default (which was developed by Apple to make more iOS apps available for Mac desktops) and on Linux it draws its own widgets that the devs try imitating the GTK style with.

On Android and iOS, it just uses the native widgets which I think is a better experience so you can see my reasons for guessing it's mobile-first. That may or may not be what you want.

5- Uno

> ...building UIs with the document/element api

When the whole premise is flawed, JSX or not, does it really matter if there is a better or worse way of misusing a technology not meant for UIs?

Leave HTML and JavaScript to Wikipedia and other hypertext document libraries.

Unfortunately, WASM is not there yet, but people are trying: https://platform.uno.

Uno Platform is fully open source, under Apache 2.0 license. You can see the license here https://github.com/unoplatform/uno/blob/master/License.md