libpeer VS broadcast-box

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.

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.

A simple C implementation to stream H.264 to browser using WebRTC\ (61 comments)

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...

> [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

This is a PR (with builds) to add AV1 support to the WebRTC output from OBS.

We also have been working on a reference server implementation with https://github.com/Glimesh/broadcast-box/ to make it easy to self host.

Simulcast builds of OBS are available. Simulcast is when a client generates multiple encodes of a video. Testers and feedback would be greatly appreciated!

Design Discussion: https://github.com/obsproject/rfcs/pull/55

Use it against your favorite WHIP ingest. If you don't have one check out https://github.com/glimesh/broadcast-box. It is a reference implementation of a WHIP/WHEP server.

I hope/believe the impact of this will be much greater then WebRTC. This could benefit all broadcast workflows.

* Higher Quality Videos - Decoding and re-encoding causes quality loss. Generating all the renditions from the source video is going to be a big improvement for viewers.

* Lower Latency - Removing the additional encoding/decoding allows video to be delivered faster.

* Reduce complexity - With Simulcast setting up a streaming server becomes dramatically easier. It is much easier for an individual to afford and manage a single broadcast server. RTMP -> Transcode -> HLS gets complicated and expensive quickly.

One of the devs commented on HN that you can use Broadcast Box handle the initial connection. That's open source so you can self-host that too

Try it out today with Broadcast Box. A reference server implementation. https://github.com/glimesh/broadcast-box. The PR to add WebRTC to OBS https://github.com/obsproject/obs-studio/pull/7926

I don't have an idea on how to do cascading OBS instances. I should write some software to make this easy though. I want to make 'self hosting' as easy as possible. I think https://github.com/glimesh/broadcast-box will fill that gap for now.

For my own usage I run WebRTC servers and have them 'replicate' the video traffic. LiveKit did a write up on this with some good graphics https://blog.livekit.io/scaling-webrtc-with-distributed-mesh...

I am really excited for this PR to land. Being able to use WebRTC for Broadcast and Playback is going to be huge.

Instead of doing fixed interval keyframe we can use receiver feedback (Massive reduction in bandwidth)

Instead of server side generated transcodes we can use Simulcast. Will be better quality AND massively reduced server load.

If anyone wants to use with Pion check out https://github.com/Glimesh/broadcast-box

Then run `ffmpeg -re -f lavfi -i testsrc=s=1280x720:r=30 -f lavfi -i sine=f=440:b=4 -vcodec libx264 -pix_fmt yuv420p -profile:v baseline -r 25 -g 50 -acodec libopus -ar 48000 -ac 2 -f rtc -authorization "STREAM_NAME" "http://localhost:8080/whip"