go2rtc VS broadcast-box

Not my project but I have had great success with https://github.com/gtxaspec/wz_mini_hacks & V3 model.

The V3 models need to be downgraded to a specific firmware first and patching it exposes RSTP streams using https://github.com/AlexxIT/go2rtc. Everything doable without ever installing Wyze app on an environment air gapped environment with no internet.

go2rtc can stream from the rtsp of the camera and push out to YouTube etc

Maybe this is what your lookin for, https://github.com/AlexxIT/go2rtc

I don't think that will ever be possible unfortunately. WebRTC requires DTLS+SRTP for the mandatory security, don't ever see that being made optional.

For RTSP/WebRTC bridging I have used https://github.com/AlexxIT/go2rtc and really enjoy it.

I will try to add the stream with go2rtc, which I have running either way. https://github.com/AlexxIT/go2rtc/issues/403

Yes it is normal to have a 8-10 second delay. I use shinobi to record, not to monitor. for monitoring I use go2rtc. On Unraid its in the app store, or get it here https://github.com/AlexxIT/go2rtc . Its a zero delay zero cost rtc camera viewer software and I absolutely love it and it does exactly what it says. I simply pulled down the container in Unraid and pasted my rtsp stream and it was right there instantly. Everything playing in exact real time. This is the easiest solution you will find. Throw it behind a reverse proxy and you have it to view from anywhere in the world. I have no password on mine so I mostly use the http 127.321.313:1984 address. I am not sure there is a way to lock it if you use a reverse proxy I am still working on that.

Never dived into it (yet) but I’m intrigued by https://github.com/AlexxIT/go2rtc

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