[der_rod]

Well there just isn't "something better". Yet.

MoQ (Media over QUIC) development is underway at the IETF - with involvement from Twitch/YouTube/Facebook/Cisco/etc. - but will probably still take quite some time before its finalised and can be adopted.

[Sean-Der]

I use WebRTC today and am happy with it! Works great for broadcasting from Web, Mobile and tools that support it (GStreamer)

I have a PR open to OBS for it right now https://github.com/obsproject/obs-studio/pull/7926

[tracker1]

How many of those users are direct vs. relaying through a TURN server? I'm genuinely curious, as I kind of anticipate that the majority of users are relaying, but I guess if p2p requests can open router ports in the common config, that could work.

[londons_explore]

IPv6 users usually manage a direct connection, and that is ~half the world now.

IPv4 users seem to manage a connection ~70% of the time in my experience. Remember only one peer needs to have a router with a suitable config for everything to work.

[tracker1]

I realize most of that... just didn't realize how many work in terms of direct connection, which is nice to hear.

[londons_explore]

When a PR sits for many months and has hundreds of comments, it probably means it's getting near to bikeshed territory and it would have been better to get small PR's in adding the groundwork and a project plan agreed with leads beforehand...

[Sean-Der]

Project leads created the original PR + RFC

* PR https://github.com/obsproject/obs-studio/pull/7192

* RFC https://github.com/obsproject/rfcs/pull/43

I tried to keep the size as small as I could. It is just basic audio+video (no Simulcast/ICE Renegotiation etc...) It has been a tough process, but I am going to keep working on it until I can get consensus.

[Sesse__]

SRT is definitely “something better”. It doesn't support codec negotiation, but it's more generally much more reasonable than RTMP for video ingest.

[der_rod]

Doesn't support AV1.

[Dylan16807]

1. It looks like RTMP didn't support it, and arguably still doesn't, since they link to an "enhanced RTMP" spec.

2. "Unlike some other protocols that only support specific video and audio formats, SRT does not limit you to a specific container or codec, since it is media or content agnostic. SRT operates at the network transport level, acting as a wrapper around your content. This means it can transport any type of codec, resolution or frame rate. This is important because it can future proof workflows by working transparently with MPEG-2, H.264, and HEVC for example."

[der_rod]

1. Yes, it's an extension to the spec published by an organisation Adobe and Google are a part of. It extends the protocol in a backwards-compatible way.

2. SRT, in practice, is only ever used with MPEG-TS as the container for audio/video data, which does not support AV1.

[Dylan16807]

The point is, you don't even need to extend the protocol for SRT. You just need to set up servers that are ready, just like companies are in the middle of doing for other techs.

Which I'm sure is still significant work, but is it much harder to do with SRT?

[der_rod]

> You just need to set up servers that are ready

The "just" is doing a lot of work here. Extending existing RTMP infrastructure is obviously much easier than spinning up an entirely different one. And you'd still have specify a way to use anything but MPEG-TS to send audio/video over SRT, which de facto does not exist (at least not that I can find).

I agree that extending RTMP isn't ideal, but other solutions have their own set of limitations, problems, and challenges. Whether that's SRT, RIST, or WebRTC.

For better and worse, RTMP and dealing with it at scale is well understood.

[Sesse__]

SRT is transport-agnostic. I've streamed AV1 within MKV within SRT.