libpeer
mediasoup
libpeer | mediasoup | |
---|---|---|
11 | 24 | |
775 | 5,904 | |
- | 1.0% | |
8.1 | 9.5 | |
5 months ago | 7 days ago | |
C | C++ | |
MIT License | ISC License |
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.
libpeer
- VoRS: Vo(IP) Simple Alternative to Mumble
-
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 for the Curious
- Show HN: Bring phone calls into the browser (sip-to-WebRTC)
-
Drop packet
I am experimenting based on the pear project (https://github.com/sepfy/pear) and using the clumsy tool to simulate the case of dropping packets.
- Pear - A WebRTC Toolkit for IoT/Embedded Devices (a work-in-progress)
-
Hacker News top posts: Apr 8, 2021
A simple C implementation to stream H.264 to browser using WebRTC\ (61 comments)
-
A simple C implementation to stream H.264 to browser using WebRTC
I think there's some truth in what as-j is saying. Rust binaries (and C++ ones) tend to be larger than C ones. I think the major reasons are (a) Rust dependencies being statically linked due to a lack of ABI stability, (b) inclusion of portions of the (statically linked, see a) Rust standard library used by the program where C code uses libc, (c) code bloat due to monomorphization, (d) the ease of just using a full-featured library where someone writing in C might cheat a little bit. As an example of what I mean by the last point, see sdp_attribute_get_answer in this codebase. [1] It's writing JSON, but it doesn't use a JSON library that actually escapes the included string. It just assumes the included string doesn't have a quote character in it. Is that assumption valid? Will it always be valid? I'm not sure on quick inspection.
There are ways around all of these:
* a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version.
* b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use.
* c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems.
* d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust.
but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem.
Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security is historically horrible but I'd like to change that.
[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...
[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
mediasoup
- WebRTC for the Curious
-
Implementing group video conference seems quite hard. Any tips on what I might be doing wrong ?
Given the financial restraint, i was avoiding paid API's like twilio. I started looking at mediasoup https://github.com/versatica/mediasoup, but while implementing the SFU server, its seems a lot more involved. For ex, TURN and STUN, peers negotiating different video codecs, adaptively changing the quality of video etc. Is it usually this difficult to implement a video conferencing apps ?
-
STUNner Kubernetes media gateway for WebRTC
This release ships lots of new features to the already comprehensive set of them. Currently, we offer several working tutorials on how to set up STUNner with widely used WebRTC media servers and other applications that use WebRTC in Kubernetes, such as: - LiveKit - Jitsi - mediasoup - n.eko - Kurento
-
Free - Self-hosted - WebRTC - alternative to Zoom, Teams, Google Meet - Real time video calls, chat, screen sharing, file sharing, collaborative whiteboard, dashboard, rooms scheduler and more!
Architecture WebRTC SFU (server with Selective Forwarding Unit). Can handle unlimited rooms without limits of time, each having 8+ users, potentially many as it is scalable. Routing is a multiparty topology, where each participant sends its media to the MiroTalk media server mediasoup and receives all other’s media from it. This version is Ideally suited for large group video conferences.
-
Free Secure WebRTC P2P/SFU/C2C Video Calls, Screen Sharing, File Sharing, Chat and more.
I started the MiroTalk P2P & MiroTalk SFU projects during the pandemic period (about 1+ year ago), not knowing anything about the WebRTC. Making often the video conferences with my colleagues and not wanting to depend on Zoom, Teams, Google Meet... I decided to do some research about how it works and from there MiroTalk was born :) I Giving to everyone the chance to have its own instance of MiroTalk, which can be customized as you like and run in any cloud, vps, server. If you're just starting out, I suggest you take a look at the MiroTalk C2C (New) code, which can be a good starting point to understand how the architecture WebRTC Mesh (P2P) works. Later you can also study how the WebRTC SFU (Selective Forwarding Units - I recommend mediasoup which I personally love) or MCU (Multipoint Control Unit) architecture works. I wish you all the best!
- Jitsi: More secure, more flexible, and completely free video conferencing
-
WebRTC 102: Understanding libWebrtc
The "Mediasoup" project provides a high level JavaScript/TypeScript interface to the WebRTC APIs. The core logic of this project is implemented in C++/Rust. Consider taking a look at the project if you want an easy-to-use library instead of the low-level libWebRTC APIs. A notable project to mention is the Pion/webrtc project which has a Golang implementation of the WebRTC API. Of course, we should mention the rust port WebRTC.rs. Let’s keep all the rustaceans happy too!
-
Germany Forces a Microsoft 365 Ban Due to Privacy Concerns
Indeed, maddening, especially as the wonderful https://mediasoup.org/ is developed here. Europe will never have great tech companies when the answer seems to be throwing €€€ away instead of investing locally
-
WebRTC P2P/SFU - Open Source - Alternative to Jitsi, Zoom, Google-Meet, Microsoft-Teams...
Hello thedominux, Thanks for your interest in MiroTalk ;) MiroTalk SFU code is: - JAVA-SCRIPT: 85.2% - HTML: 10.0% - CSS: 4.5% And has built in mediasoup server, more details about: https://mediasoup.org/
-
How to Build a Video Chat App: Types, Cost, & Must-Have Features
Mediasoup
What are some alternatives?
libdatachannel - C/C++ WebRTC network library featuring Data Channels, Media Transport, and WebSockets
Pion WebRTC - Pure Go implementation of the WebRTC API
openmiko - Open source firmware for Ingenic T20 based devices such as WyzeCam V2, Xiaomi Xiaofang 1S, iSmartAlarm's Spot+ and others.
janus-gateway - Janus WebRTC Server
tiny-webrtc-gw - tiny/fast webRTC video conferencing gateway
jitsi - Jitsi is an audio/video and chat communicator that supports protocols such as SIP, XMPP/Jabber, IRC and many other useful features.
spchcat - Speech recognition tool to convert audio to text transcripts, for Linux and Raspberry Pi.
peerjs - Simple peer-to-peer with WebRTC.
cpufetch - Simple yet fancy CPU architecture fetching tool
webrtc-without-signaling-server - webrtc without signaling server. a stun server is still used if connecting over the internet.
Ory Keto - Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.
mirotalk - 🚀 WebRTC - P2P - Simple, Secure, Fast Real-Time Video Conferences Up to 4k and 60fps, compatible with all browsers and platforms.