* Free Software
* Project is operated/managed by individuals
* Use Open Standards/Protocols
Sorry for hijacking your comment :)
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?
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.
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?
* 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.
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.
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).
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)
`--enable-features=WebRtcAllowH265Receive --force-fieldtrials=WebRTC-Video-H26xPacketBuffer/Enabled`
I haven't used it myself yet.
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.
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.
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.
* 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