Hacker News Reader

Comment by rcme | Hacker News Reader

Does codec negotiation really make sense? Encoding video is so expensive that you can only realistically support one or two codecs at a given time. Anything else is wasteful.

> * P2P. Stream your OBS output directly to another user. It is frustrating to see users struggle with setting up RTMP servers/HLS when they want to share their video with just one or two other people. The other use case I really care about is co-streaming.

The nginx RTMP plugin supports converting an RTMP stream into an HLS stream. It's pretty easy to set up. Even if OBS used WebRTC or some other p2p solution, you would still need some type of signaling / connection negotiation setup.

View on HN

> Does codec negotiation really make sense

On startup you could be connecting two clients that have completely different sets of codecs. What if you have a low powered device that only has a H264 hardware decoder? What if you have two desktops that prefer AV1. WebRTC lets each side publish what codecs they support, and their priority

> It's pretty easy to set up

Yea it is not bad if you are comfortable with those things. I want to empower users who have no idea what Linux, codecs or systemd is. I want to create something like 12 year old me would have used. I could have had a lot of fun with my friends if we could have done P2P.

> you would still need some type of signaling / connection negotiation setup.

I use QR codes for this.

For public signaling is also cheap enough that it could be provided for free. I think the project name was simplewebrtc? Hosting RTMP/HLS for free is prohibitively expensive though.

>What if you have a low powered device that only has a H264 hardware decoder? What if you have two desktops that prefer AV1.

You recode on the server.

You don't have a server (and in my cases you don't want)

* I don't want to upload my video from my security camera to a remote host. It has security and privacy implications

* I don't have the bandwidth available

* I don't want to pay the bandwidth and compute costs.

* I don't want to incur the extra latency

That's not a good solution for... almost anybody. Most people would rather have the remote server recode, they would rather not have to open ports (with some connections you just can't), they would rather not expose their IP addresses, etc.

I can see your point but it has nothing to do with what platforms like Twitch are for.

You wouldn’t open ports, you are in the same network.

I don’t think P2P is the answer to everything, in the same manner servers aren’t the answer to everything.

> Encoding video is so expensive that you can only realistically support one or two codecs at a given time. Anything else is wasteful.

Even consumer nVidia cards support at least three simultaneous encode streams, which would be perfectly cromulent for a relay-only streaming service (high / medium / phone).

Although in practice you often don't want to do these completely separately. What you want to do is encode the lowest quality as a "base" then medium as extra data that you can add on top, then high as extra data on top of that. This does make the higher qualities slightly less efficient but requires only slightly more data to broadcast different qualities. It would be extra cool in P2P use cases where everyone will be re-sharing the low quality instead of the users with the best connections using a completely separate stream and leaving no good connections to re-share the low quality stream.

Of course at some number of viewers in a centralized setup it probably does make sense to send just upload the top quality and make separate lower quality streams for small efficiency gains that add up.

Reply on news.ycombinator.com