Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: