Hacker News Reader

Comment by Sean-Der | Hacker News Reader

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

View on HN

Is there a reason why I'd want to use Broadcast Box instead of mediamtx, which features RTMP, RTSP, WebRTC/WHIP, and (LL)HLS in a single small binary?

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

I think this is a highly underrated comment. It seems today, people wont create for free any more, just for the joy of creating and distributing some thing you care about. It's always please donate x to y. Or subscribe to get access to premium content.

Sorry for hijacking your comment :)

this seems like a reasonable comment on its face, but then it reads selfishly. why should a developer donate time when a house isn’t donated to that programmer?

Economy is shit, what do you expect. Very few humans have the financial luxury to release free software and not try to monetize it at all.

> mediamtx is a great project! Use w/e works best for your use case.

I agree, I'm just struggling to differentiate what BB offers that MMTX does not, so I can identify if there's a USP. If it's a passion project to scratch a personal itch, that's also great!

Also, can you share your latency measuring methodology?

I think Broadcast Box may have implemented WHIP/WHEP before MediaMTX so it tends to be one of the first results when looking up a WHIP-capable server. Plus it has a public instance so if you want to test WHIP real quick, it's pretty easy to just point OBS somewhere instead.

MediaMTX used to be "rtsp-simple-server" which really undersold what it was capable of (even back then it could ingest RTMP and output HLS and WebRTC).

Overall I think MediaMTX has more features and can do everything that Broadcast Box can.

I didn't know this existed, so thanks.

Just pouring through the code, one thing I think it's missing is transcoding to multiple (lower) resolutions as well so weaker connections can watch.

Is that correct? I took a brief look a the WHIP protocol and it seems like maybe it's just a matter of converting the frames before writing?

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.

> It feels wrong to me that a streaming service is able to modify video however it pleases.

This would significantly complicate services such as Twitch and YT Live going to server-side ad insertion if the source video were E2E. I think server-side ad insertion is likely the only method available for providers that isn't able to be circumvented by ad-block or DNS blocking plugins.

Why? The advertisements could still be added as separate video layers? Sure, they are also easier to be circumvented. But I’d rather supported something like this than end up with real time edited video to insert ads or even worse have “influencers” promote something without ever having really tried it.

If it's a separate layer or different server you can bet that someone will figure out how to remove it from the DOM, hide it, or prevent it from even loading.

Again, I think that's a "feature" a lot of users would prefer to design out.

There is by definition a layer of trust between the broadcaster, the server, and the client.

That said, you could use TLS from the server to client, which is what many services do (since it's actually quite difficult to use http these days for streamed content due to browser polices).

> I would like for broadcast services to eventually offer E2E encryption

Is this even conceptually possible? I suppose you could sign the stream, but if you want to hide it how would you prevent the server from simply adding itself as a viewer?

(also, if you do this, start a countdown for getting raided as a CSAM distributor)

I believe that's handled on the OBS side.

Hi, this looks great but I tried to do the setup as described in the readme using OBS and streaming to your server and I saw 3-4 seconds delay, how exactly can I reach sub-second?

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

I always wondered why broadcasters don't transcode on the client side.

RTMP can't handle it, but SRT (and apparently WebRTC can). It would reduce latency for sure. Of course, it does require a good network connection on the client end, but so does streaming.

I suspect it's a desire to minimise CPU/GPU usage, especially if you're trying to stream a game from a PC through OBS.

> These intimate broadcasts are a new medium.

You hit the nail on the head here. I mean live streaming is already quite big but it seems like it's going to be going up 10x - 100x next few years.

It's really an amazing thing that makes the Internet more human.

I feel the opposite. I’ve watched streaming as my primary form of media for over 10 years now, and it seems a majority of the small, “intimate” broadcasters that were fun to watch have had to get real jobs, or are sailing the world, or what have you. To me, it seems like it’s dying in favor of short form doomscroll videos.

> I’ve watched streaming as my primary form of media for over 10 years now

My goodness, you are living in the future. What else are you into? Where can I follow you (blog, twitter, warpcast, etc?)? Love to follow early adopters.

How does it work with H265? My last info was, that WebRTC only supports H264 and VP8. It would be great to stream H265 via WebRTC.

WebRTC is codec agnostic as far as I know, it's up to the peers to negotiate the codecs used. Of course browsers will have more narrow support, but can sometimes activate more codecs via flags or you can use a non-browser client.

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.

Reply on news.ycombinator.com