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 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.
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?
> 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.
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.
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)
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?
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 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.
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.
* 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