Hacker News new | ask | show | jobs
by Dylan16807 1173 days ago
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."
1 comments
der_rod 1173 days ago
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.

link
Dylan16807 1173 days ago
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?

link
der_rod 1173 days ago
> 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.

link