Sean-Der

What are your encoder settings? Mind joining the discord easier to debug I don’t actively check HN sorry :/

mediamtx is a great project! Use w/e works best for your use case. I just encourage people to use.

* Free Software

* Project is operated/managed by individuals

* Use Open Standards/Protocols

Google doesn't use any STUN/TURN servers I just went and confirmed. The following is the RTCPeerConfiguration used.

```

https://meet.google.com/***-***-\*\*, { iceServers: [], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 },

```

My public instance runs on a world addressable host and doesn't have TURN. I have no problem using it from my phone and it is behind a CG NAT. No TURN/Relay servers are needed.

> I've never been able to use any WebRTC-enabled service for this reason, nor anyone else I know

Is this a browser/agent issue? You aren't able to use Google Meet or Zoom in the browser?

I would have your friend stream to Broadcast Box. You can run it on the Raspberry Pi!

Then I would pull that source into your OBS. You have two options

* Pull Broadcast Box as a browser source

* Use my PR that adds WHEP Sources https://github.com/obsproject/obs-studio/pull/10353

For now I would do Browser Source (is easier/no custom builds). In the future when WHEP is merged that is the way to go. If you get stuck jump in the Discord and happy to help debug! https://discord.gg/An5jjhNUE3

H265 support is available in Chrome now! Launch with these flags

`--enable-features=WebRtcAllowH265Receive --force-fieldtrials=WebRTC-Video-H26xPacketBuffer/Enabled`

I haven't used it myself yet.

I am excited for you to use it!

If you run into bugs or have any cool ideas join the discord and would love to chat https://discord.gg/An5jjhNUE3

To build this quickly I would chain Broadcast Box instances. Have it look like a n-ary tree and spin up another broadcast box instance when you need it.

`OBS -> Broadcast Box -> Broadcast Box -> Broadcast Box -> Viewer`

To start I would do WHIP between the servers as well. More optimization can be done, but it would be a good quick start.

This is all done client side. OBS sends up multiple renditions, the server is just in charge of forwarding the specific layer. I think this is better in a few ways.

* Lower latency - The extra decode + encode adds enough latency that you start to lose the real-time latency.

* Better Quality - You get generational loss from the transcoding. You get better quality only encoding one times. Streaming services also optimize for cost. Having broadcasters control the encoding quality of everything makes for a better experience.

* Security/Trust - Servers shouldn't be able to modify video at all. I would like for broadcast services to eventually offer E2E encryption. It feels wrong to me that a streaming service is able to modify video however it pleases.

vdo.ninja is a fantastic project, can’t recommend it enough.

It made the dream of ‘co-streaming’ available to home users and not just those with hardware/pro setups.

Lots of options! More and more WebRTC SFUs are adding WHIP support. Check out https://galene.org/ it lets you do OBS in and has things like chat. Might be better if you are streaming to family and want chat. I would try and find a VPS that is best geographically located.

Cloudflare if you want this quick. Even though it is proprietary you have no vendor lock in, just change your WHIP URL in OBS if things aren’t going right.

Open Source doesn’t have an instant scalability offering yet. I hope someone takes it on!

Quite a few companies offer this a service though. Cloudflare, Twitch’s IVS, Dolby Millicast, Phenix RTS…

LiveKit did a write up on how they built theirs https://blog.livekit.io/scaling-webrtc-with-distributed-mesh...

I created Broadcast Box originally as a reference server to test OBS against. It was way easier for people to test my WebRTC/WHIP PRs against. Seeing people use it I am seeing the benefits/excitement more.

* low latency means you have a relationship with your audience. These intimate broadcasts are a new medium.

* Simulcast means it is way cheaper to run a streaming site. No more running ffmpeg/generating transcodes server side.

* AV1/H265/Opus means users with lower bandwidth can now broadcast. Users with enough bandwidth can stream at quality levels they couldn’t before

* UDP gives us IRL/Roaming streams. No custom setup for re-connects.

* Multi-track lets you send multiple video feeds or languages at once

* E2E Encryption means that P2P distribution could be a thing

I agree, if you are in a perfect network! If you have any packet loss, changes in throughput, or roaming it breaks down.

RTMP for me is preventing that next generation of use cases.

It drives me crazy that we have had the technical ability to do these things, but just not the demand. I believe it is a chicken/egg problem. It is one of those things that you don't get until you try it yourself.

I hope if more broadcasters (technical and non-technical) realize what is possible they will ask for it more!

> For vast majority of content, the viewer is consuming only your stream

Agree! I think it is that way because you can't have intimate/interactive streams yet. When it becomes possible I hope to see more streaming to smaller/more connected audiences.

The alternative today is ~few seconds.

This is from my T420 Thinkpad on Linux. The only significant input I can think is my RTT to the server.

``` Reply from 165.227.221.230: bytes=32 time=37ms TTL=49 Reply from 165.227.221.230: bytes=32 time=37ms TTL=49 ```

Check out https://github.com/pion/mediadevices it’s an attempt to make that way easier

Not that I am aware of! Happy to help build it if you are interested in starting it :)

You shouldn’t need TURN for Client/Server like Donut. The Donut server runs on a world addressable host. So luckily no TURN woes here!

In practice ~20% of users need TURN https://medium.com/@fippo/what-kind-of-turn-server-is-being-...

Did you end building it? What did yo use? What made it hard?

This is a great project. I really want to add a little JS lib so it could be all done client side

<donut server=‘’ src=‘rtmp://….’ />

src could be any protocol you want.

This allows you to view video from protocols the browser doesn’t support with very little added latency.

Things like RTMP/SRT/RIST/RTSP….

Connection is E2E encrypted when using TURN. Using TURN has no negative impact on security.

The TURN server can see the size/src/dst so that has a privacy implication!

Do you want this in the browser or a specific language?

Yep! If you do one non-browser WebRTC agents https://github.com/pion/offline-browser-communication

This could be possible browser to browser! I don’t think that has ever been an official use case

P2P broadcast is interesting. Send your video to two users, then they send it to two more. Makes things affordable.

P2P VPN I also like. Users connect directly instead of routing all traffic through relay.

Sorry about that! I will continue working on improving it.

I am also going to drop the 7z usage. Powershell has unzip built in

It definitely adds latency, not enough to be a bad experience.

We have vdo.ninja today and Twitch's Stream Together. Those both do the 'dual encoding' and it is a good enough experience that users are doing it!

I don't believe it is possible today, but I am working on it! It would be great for users trying to co-stream.

I created OBS2Browser[0] that is a good first step in the direction.

[0] https://github.com/Sean-Der/OBS2Browser

I doubt the protocol itself makes a big difference. I bet you can get 30ms with VNC. The difference with BitWHIP.

* Can play WebRTC in browser. That makes things easier to use.

* simpler/hackable software. BitWHIP is simple and uses nvenc etc… if you use nvenc with VNC I bet you can get the same experience