ffmpeg VS broadcast-box

And furthermore, C and C++ code can participate in the Zig package ecosystem. For example, here is ffmpeg packaged for consumption by a Zig project:

https://github.com/andrewrk/ffmpeg

Why not use a system package? Well, because the user's system might not have such a package. They might be on Windows, for example. Or their package might be out of date. [Or the system might have chosen sides in a nasty fork war](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html).

So, while system packages are nice for end users, they might not always satisfy the needs of upstream application developers.

It's a bit more nuanced than that, as detailed by AndyKelley (andrewrk@) on github[1].

As I understand it, C/C++ interop and support in the build system is not going away; instead it might be accomplished via a separately maintained clang package. (Aside: for an example of this kind of thing can work, see ffmpeg[2] converted to use the Zig build system which pulls in nasm[3] as a Zig package; presumably the clang solution would be a bit more integrated than that, but it serves to show that it can be done).

Zig will still support compilation using LLVM, but instead of directly linking to LLVM and using LLVM's IRBuilder API, it will directly output LLVM bitcode instead[4]. The build system will then handle linking this into an executable.

The idea seems to be to reduce dependencies of the main executable, while keeping the build system flexible enough that it does not impact existing use cases.

I'm not affiliated with the Zig project in anyway, so my understanding of this may be off. I'd recommend reading the GH issues and comments I've linked below to get a better idea of it.

[1]: https://github.com/ziglang/zig/issues/16270#issuecomment-161...

[2]: https://github.com/andrewrk/ffmpeg

[3]: https://github.com/andrewrk/nasm

[4]: https://github.com/ziglang/zig/issues/13265

I am not entirely sure with were you are going with this comment but FYI here is an ffmpeg fork with the build system replaced with a "build.zig" file and the Zig build environment: https://github.com/andrewrk/ffmpeg

If you want to see a fun example of this build system in action, have a look at my ffmpeg fork which has the build system ported to zig build:

https://github.com/andrewrk/ffmpeg

Particularly interesting is the use of nasm as a package dependency, which is executed to compile many assembly files into object files, then linked into the ffmpeg static library.

I'm using this package in a work-in-progress reboot of Groove Basin (a music player server) in Zig:

https://github.com/andrewrk/groovebasin/tree/zig-pkg

Point being that if you want to collaborate on the music player project, you don't need to screw around with a million system dependencies, it's just `zig build` and you're off to the races - no matter whether you are using Windows, macOS, or Linux.

The zig build system is under heavy construction during this release cycle of Zig. I recommend to check it out at the end of May when Zig 0.11.0 is released, and a few more issues will be smoothed over. Of course, if you want to get your hands dirty and help work on a bleeding-edge build system & package manager, come on over and give master branch a try.

Thank you so much for the kind words and encouragement!

> Would you be up for sending a PR to [0] to deprecate it and point to your repo?

Absolutely, I’d be glad to submit a PR! I'll carve out some time soon to get that done.

> If you are up for it you should join the Discord in https://github.com/glimesh/broadcast-box and maybe https://pion.ly/discord I would feel honored to have you in these communities.

I’m already in the Discord server listed at the broadcast-box repo, and I’d be glad to join Pion's Discord as well! It would also be an honor for me to be part of both communities and contribute however I can.

> Lastly have you posted this on X or LinkedIn? Could I share with others.

So far, I’ve only shared the project on HN and r/rust subreddit, so I’d certainly appreciate you helping spread the word.

Thanks again for your support!

It's so exciting.

Especially with Simulcast it will make it SO cheap/easy for people.

I made https://github.com/Glimesh/broadcast-box in a hope to make self-hosting + WebRTC a lot easier :)

I am so incredibly excited for WebRTC broadcasting. I wrote up some reasons in the Broadcast Box[0] README.

Now that GStreamer, OBS and FFmpeg all have WHIP support we finally have a ubiquitous protocol for video broadcasting for all platforms (Mobile, Web, Embedded, Broadcasting Software etc...)

[0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...

I’m so excited for this. If we get better protocols I anticipate so many more projects will get built. Check out this [0] article to get more on what WHIP solves.

https://github.com/Glimesh/broadcast-box is also a decent jumping off point

[0] https://webrtchacks.com/webrtc-cracks-the-whip-on-obs/

> [1] https://github.com/Glimesh/broadcast-box

This is really interesting! Any latency benchmarks comparing it to gstreamer UDP, P2P primarily?

This release includes WebRTC support. I would really appreciate if people could try it! I have so many things I want to improve with broadcasting.

——

* Serverless Streaming - WebRTC is P2P so you can video right into your browser. You don’t have to stand up a server anymore to stream for a small audience.

* Sub-Second Latency - Create content and interact with viewers instantly. There is something magical about having a real conversation with your viewers.

* Multitrack Input - Upload your transcodes instead of generating then server side. Give viewers multiple video tracks to see action from all sides.

* Mobility - WebRTC lets you switch networks at any time. Go from WiFi -> Mobile with zero interruptions.

* E2E Authentication - WebRTC lets you add authentication on the sender and receiver. Broadcasters could sign their video streams so viewers can be sure it wasn’t modified.

Try it out with Broadcast Box. A reference server implementation. https://github.com/glimesh/broadcast-box