6 ms·

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

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

dangoodmanUT 2y ago
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?
- mannyv 2y ago
  I believe that's handled on the OBS side.
- Sean-Der 2y ago
  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.
  - ohthatsnotright 2y ago
    > 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.
    - spockz 2y ago
      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.
      - ohthatsnotright 2y ago
        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.
    - pjc50 2y ago
      Again, I think that's a "feature" a lot of users would prefer to design out.
  - mannyv 2y ago
    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).
  - pjc50 2y ago
    > 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)
mannyv 2y ago
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.
- pjc50 2y ago
  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.
Flockster 2y ago
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.
- Sean-Der 2y ago
  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.
- SahAssar 2y ago
  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.
oarsinsync 2y ago
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?
- Sean-Der 2y ago
  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
  - thnkman 2y ago
    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 :)
    - jack_pp 2y ago
      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.
    - tekknik 2y ago
      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?
  - oarsinsync 2y ago
    > 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?
    - 2y ago
breck 2y ago
> 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.
- tekknik 2y ago
  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.
  - breck 2y ago
    > 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.
mapcars 2y ago
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?
- Sean-Der 2y ago
  What are your encoder settings? Mind joining the discord easier to debug I don’t actively check HN sorry :/

dangoodmanUT 2y ago

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?

mannyv 2y ago
I believe that's handled on the OBS side.
Sean-Der 2y ago
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.
- ohthatsnotright 2y ago
  > 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.
  - spockz 2y ago
    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.
    - ohthatsnotright 2y ago
      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.
  - pjc50 2y ago
    Again, I think that's a "feature" a lot of users would prefer to design out.
- mannyv 2y ago
  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).
- pjc50 2y ago
  > 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)

mannyv 2y ago

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.

pjc50 2y ago
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.

Flockster 2y ago

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.

Sean-Der 2y ago
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.
SahAssar 2y ago
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.

oarsinsync 2y ago

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?

Sean-Der 2y ago
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
- thnkman 2y ago
  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 :)
  - jack_pp 2y ago
    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.
  - tekknik 2y ago
    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?
- oarsinsync 2y ago
  > 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?
  - 2y ago

breck 2y ago

> 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.

tekknik 2y ago
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.
- breck 2y ago
  > 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.

mapcars 2y ago

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?

Sean-Der 2y ago
What are your encoder settings? Mind joining the discord easier to debug I don’t actively check HN sorry :/