|9 days ago||11 days ago|
|GNU Lesser General Public License v3.0 only||MIT 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.
Wanting some advice on streaming audio from a raspberry pi to browsers.
1 project | reddit.com/r/WebRTC | 12 Dec 2021
I was doing some research and it seems like I need to use a native webrtc api, however I am a bit lost on which native implementation to use. Pion Webrtc seems to have the most community usage (just going based off of github stars), so I am leaning towards that, but I am aware that there is a C++ api (google's : https://webrtc.googlesource.com/src/+/main/docs/native-code/index.md ) and also this one: https://github.com/paullouisageneau/libdatachannel .
Libwebsockets a powerful and lightweight pure C library
7 projects | news.ycombinator.com | 6 Sep 2021
How to build a simple SFU server?
3 projects | reddit.com/r/WebRTC | 24 Apr 2021
- A simple C implementation to stream H.264 to browser using WebRTC
Show HN: WebRTC-Echoes: Interop for C#, C++, Python, TypeScript, Go and Servers
7 projects | news.ycombinator.com | 29 Mar 2021
WebRTC is now a W3C and IETF standard
9 projects | reddit.com/r/programming | 27 Jan 2021
Also: https://github.com/paullouisageneau/libdatachannel (C/C++)
Pear - A WebRTC Toolkit for IoT/Embedded Devices (a work-in-progress)
1 project | reddit.com/r/C_Programming | 8 Apr 2021
Hacker News top posts: Apr 8, 2021
6 projects | reddit.com/r/hackerdigest | 8 Apr 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
1 project | reddit.com/r/patient_hackernews | 8 Apr 20211 project | reddit.com/r/hackernews | 8 Apr 2021
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.  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. 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  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.
What are some alternatives?
Pion WebRTC - Pure Go implementation of the WebRTC API
janus-gateway - Janus WebRTC Server
libjuice - JUICE is a UDP Interactive Connectivity Establishment library
openmiko - Open source firmware for Ingenic T20 based devices such as WyzeCam V2, Xiaomi Xiaofang 1S, iSmartAlarm's Spot+ and others.
µWebSockets - Simple, secure & standards compliant web server for the most demanding of applications
sora-unity-sdk - WebRTC SFU Sora Unity SDK
SIPSorcery - A WebRTC, SIP and VoIP library for C# and .NET. Designed for real-time communications apps.
tiny-webrtc-gw - tiny/fast webRTC video conferencing gateway
libwebsockets - canonical libwebsockets.org networking library
WebUDP - Minimal WebRTC datachannel server