ffmpeg
webrtc-echoes
ffmpeg | webrtc-echoes | |
---|---|---|
4 | 6 | |
126 | 160 | |
- | - | |
9.9 | 0.0 | |
9 days ago | 10 months ago | |
C | C++ | |
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ffmpeg
-
Odin Programming Language
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.
-
Extend a C/C++ Project with Zig (2021)
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
-
WebRTC support being added to FFmpeg
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
-
Zig Build System
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.
webrtc-echoes
-
Pure C WebRTC
I am really excited about https://github.com/sepfy/libpeer. It has examples ready for ESP32 etc....
When working on KVS I wasn't familiar with the embedded space at all. I saw 'heavyweight' embedded where you were running on Linux. Then you had RTOS/No OS at all. I wasn't prepared for these devices at all. If we can make WebRTC work in the embedded space I think it will really accelerate what developers are able to build!
Remotely driven cars, security cameras, robots in hospitals that bring iPads to infectious patients etc... Creative people are building amazing things. The WebRTC/video space needs to work harder and support them :)
-----
I love how diverse the WebRTC space is now. Outside of this implementation you have plenty of other options!
* https://github.com/shinyoshiaki/werift-webrtc (Typescript)
* https://github.com/pion/webrtc (Golang)
* https://github.com/webrtc-rs/webrtc (Rust)
* https://github.com/algesten/str0m (Rust)
* hhttps://github.com/sepfy/libpeer (C/Embedded)
* https://webrtc.googlesource.com/src/ (C++)
* https://github.com/sipsorcery-org/sipsorcery (C#)
* https://github.com/paullouisageneau/libdatachannel (C++)
* https://github.com/elixir-webrtc (Elixir)
* https://github.com/aiortc/aiortc (Python)
* GStreamer’s webrtcbin (C)
See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.
-
WebRTC support being added to FFmpeg
Lots of other WebRTC implementation exist (in many languages). Happy to help if you have any questions
See https://github.com/sipsorcery/webrtc-echoes for examples of all of them running against each other.
-
WebTorrent
Lots of great WebRTC implementations exist. Do you want to stick with node.js?
I am a big fan of https://github.com/shinyoshiaki/werift-webrtc it is pure Typescript.
Check out https://github.com/sipsorcery/webrtc-echoes for all the other implementations.
-
GStreamer 1.20: Embedded and WebRTC lead the way
WebRTC has so many great implementations now! The author of the C# implementation started a really great project webrtc-echoes[0] that shows them all working together.
The next big challenge in the space seems to be getting widely available congestion control. The hard part is making sure it is understandable and customizable for everyones use cases.
[0] https://github.com/sipsorcery/webrtc-echoes
- WebRTC-Echoes: Interop for C#, C++, Python, TypeScript, Go and Servers
- Show HN: WebRTC-Echoes: Interop for C#, C++, Python, TypeScript, Go and Servers
What are some alternatives?
sokol-zig - Zig bindings for the sokol headers (https://github.com/floooh/sokol)
SIPSorcery - A WebRTC, SIP and VoIP library for C# and .NET. Designed for real-time communications apps.
raylib-zig - Manually tweaked, auto-generated raylib bindings for zig. https://github.com/raysan5/raylib
janus-gateway - Janus WebRTC Server
str0m - A synchronous sans I/O WebRTC implementation in Rust.
libdatachannel - C/C++ WebRTC network library featuring Data Channels, Media Transport, and WebSockets
go2rtc - Ultimate camera streaming application with support RTSP, RTMP, HTTP-FLV, WebRTC, MSE, HLS, MP4, MJPEG, HomeKit, FFmpeg, etc.
werift-webrtc - WebRTC Implementation for TypeScript (Node.js), includes ICE/DTLS/SCTP/RTP/SRTP/WEBM/MP4
broadcast-box - A broadcast, in a box.
aiortc - WebRTC and ORTC implementation for Python using asyncio
ffmpeg-webrtc - Support WebRTC(WHIP) for FFmpeg.
Pion WebRTC - Pure Go implementation of the WebRTC API