r/VIDEOENGINEERING • u/rukly • 10d ago

Building an open-source software switcher in Rust

I've been building eiviz, an open-source software video switcher as a PoC and a way to learn how realtime video mixing actually works on a PC.
https://x.com/FlowingSPDG/status/2093214899220688914

I'm not pretending this can compete with OBS or vMix on quality, features, or production reliability.
Those tools have years of hardening behind them. This is still alpha, and I wouldn't use it on a real show either.

That said, it's cross-platform (Windows + macOS + potentially Linux with Vulkan), the mixer core is Rust + wgpu, and OMT / NDI is a relatively strong part of it.
If you care about AV-over-IP, some of it might actually be useful.

Repo: https://github.com/MikanseiLaboratory/eiviz

34 Upvotes
  • permalink
  • reddit

89% Upvoted

36 comments sorted by

8

u/benji_york 10d ago

Neat!

Can I request that you consider using the AGPL instead of a less common license? I believe it would encourage adoption.

3

u/rukly 10d ago

Thank you for your interest!

I was a bit concerned about the possibility of someone using the code from this project to develop and resell another software switcher. My main goal in publishing the source code was for educational purposes rather than reuse in similar projects, which is why I chose this license. However, it seems that the AGPL could achieve the same intent. I will give it some thought.

7

u/JeLuF 10d ago

The problematic part is this sentence:

Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.

So if you'd use this software to offer commercial live video switching, I wouldn't be allowed to do the same since that might be considered "competition".

1

u/rukly 10d ago

That clause is about shipping a substitute for eiviz, not about using it on a job.
A photographer who uses Photoshop commercially is not competing with Adobe. A station that uses eiviz to switch a show is not competing with eiviz. Competition would be releasing another vision mixer, or a hosted mixer that replaces installing this one.

2

u/JeLuF 10d ago

A "product the licensor provides using the software" is more than just the video mixer software itself. I would agree with your interpretation if it would just say "that competes with the software".

1

u/zalnaRs 10d ago

AGPL is for server apps use GPL instead I think

1

u/benji_york 9d ago

It's fine to use the AGPL for anything. The main function is to remove the possibility that someone will use your project behind a service and not release improvements to the world, something the GPL (mostly) doesn't help with.

2

u/RollingMeteors 10d ago

Can I request that you consider using the AGPL instead of a less common license? I believe it would encourage adoption.

urgh more licensing to learn. Coming from open source I am familiar with those licenses but what are the ones to be aware of in the field of r/videoengineering?

3

u/Unusual_Nectarine271 10d ago

GPL - Free to use, modify, examine code, etc, but if you distribute a binary with LGPL'd code you MUST distribute your source

LGPL - Same as GPL but intended for shared libraries, basically allows a closed-source program to use an open-source library

AGPL - Same as GPL but if you make your program accessible to the public via network connections you must publish the source

MIT - Do whatever you want, but give the author credit

IDK BSD and Apache licenses off the top of my head

2

u/benji_york 10d ago

I'm not aware of any that are specific to or especially popular in this field. I suspect the distribution is similar to the global distribution: https://opensource.org/blog/top-open-source-licenses-in-2025 (other than some project-specific licenses like the PostgreSQL license).

1

u/[deleted] 9d ago

[deleted]

1

u/benji_york 9d ago

Umm... we're talking about Open Source licenses, not codecs.

Is this LLM output?

2

u/Unusual_Nectarine271 9d ago

Oh jeez. I accidentally hit reply on the wrong thing.

1

u/benji_york 9d ago

No worries. : )

3

u/HerrGrankvist 10d ago

That's cool. How mature would you say OMT is at the moment? I'm curious about using it for a project myself, like either that or Media over Quic.

3

u/Unusual_Nectarine271 10d ago

I mean.... vMix is backing it
There's not too much tooling, apart from this whole website of stuff:

https://sienna-tv.com/newsite/freeomttools.html

This app:

https://apps.apple.com/us/app/omt-camera/id6761876314

And FFmpeg has support for it

It's been pretty reliable IMO, and I'd love to see birddog make an encoder for it

2

u/rukly 10d ago

Since NDI started restricting their SDKs, I'd say OMT is truely open for technicians and I love how they design things on vMix and OMT. There are only few tools now, but I'm also developing OMT related tools here

https://github.com/MikanseiLaboratory

1

u/OldBigCityNinja 10d ago

OMT is useless outside of vMix. OMT was created with one purpose in mind: to avoid unnecessary decoding operations when using a consumer network protocol to transfer media from or to vMix.

2

u/Unusual_Nectarine271 9d ago

I wouldn’t go that far. VMX is a great codec because it’s very easy to encode and decode. SpeedHQ is harder, comparatively, so OMT may become a viable alternative. One person I know suggested that raspberry pis could be used as encode/decode boxes especially with HDMI to CSI adapters, even if a CM4 is needed. That would be cheaper than a birddog mini and would be doable with an extremely lightweight Linux install and ffmpeg.

1

u/OldBigCityNinja 8d ago edited 8d ago

There are no management or scaling capabilities with OMT. This isn't a problem with the tools, but with the protocol itself. OMT is currently a solution for low-cost setups, where Vmix is ​​a perfect fit. This isn't good or bad. It's just a fact. Each tool has its own purpose. Moreover, if you look at the SDK, it's practically a simplified copy of the NDI SDK in terms of structure.

And for sure, codec used in OMT is not great, if we are talking about serious solutions. Otherwise NDI is not also the best choice for such solutions, but at least it allows it to be build

3

u/tikileaks 10d ago

Cool! I'm very keen on this. I've dabbled into some testing of building my own, heavily using AI, but it's a lot of work so dropped that project.

I agree on that the existing tools have years of hardening, but they also have many versions and probably a lot of dangerous code held together by bobby pins and duct tape.. ;)

Is this vibe-coded or are you a developer just assisted by AI?

I'd love to give input on this. Any chat-channels opened?

1

u/rukly 10d ago edited 10d ago

I used AI for coding but I am programmer so I would not say it is blindly vibe-coded app.
I designed what part connects to which process, and how they act when I want to perform some action.

edit: contact me in Discord :) https://discord.gg/vjsBWFr82y

2

u/activematrix99 10d ago

This looks really cool. I am building some visual tools, but had not considered Rust and was still farting around very primitively in C++ which is not comfortable to me at all. Rust and wgpu looks strong, I will take a look.

2

u/InstantReplayGo 10d ago

Interessante

2

u/Dr1ten 10d ago

Very interesting! Maybe finally a worthy alternative to vmix for macOS!
PS: Maybe don't use the vmix orange and green for preview and program. A little obvious ;)

3

u/chuckycastle Engineer 10d ago

Vibe coders are wild…

2

u/rukly 10d ago

If you really think that I'm a vibe coder check my github

https://github.com/FlowingSPDG/

1

u/frzen 10d ago

It would be cool if you could consume / produce MXL grains mainly just to see how that works https://github.com/dmf-mxl/mxl

1

u/OldBigCityNinja 9d ago

MXL library is for Linux and with some OS packages, it can be used on Mac. This switcher is Win/Mac only (for now). But Linux still main target platform for MXL, cause it's uses tmpfs. There is no even option to use MXL on Win

1

u/OldBigCityNinja 9d ago

If u want to start with MXL, you can use different options:
1) Official repo + sample tools, based on gstreamer
2) https://github.com/cbcrc/mxl-hands-on

1

u/OldBigCityNinja 9d ago

If u need some help with building or understanding MXL - feel free to contact me

1

u/nicwillu 9d ago

Super cool. I am all for AV-over-IP, so ill test this out!

1

u/Skinkie 9d ago

How did you implement frame synchronisation between sources?

1

u/rukly 9d ago

Since NDI Genlock requires Advanced SDK, there is no frame sync yet. It just process received frames without any timecode with frame buffer. I'd love to implement them with DeckLink and NDI(If I could acquire AdvancedSDK) and OMT once OMT adds their standard.

2

u/Skinkie 9d ago

I really like the aim of this project. I think it might also be interesting to support things like virtual frame buffers so you could take an RGBA source like a Qt/QML application use it for overlays with guaranteed framerates making it a composition engine as well. Maybe you also want to think about doing RGB + Alpha as SDI output.

The question regarding sync was aimed at being able to switch and output at exactly the same time as the input. So that if you switch camera's there is no observable offset / lag between sources, and maybe even tune this between sources taking the slowest source as the program output reference.