Knowing what codecs a server supports before negotiation

[danjenkins]

Knowing what codecs and profiles a server supports before negotiation may be important, and being able to deal with that programatically is also important.

Take the example of Twitch supporting WHIP but GStreamer being unable to send media to Twitch and that negotiation failing. OBS can push to Twitch fine but GStreamer can't.... is there a change in h264 profile needed?

Ignore the fact there are no docs.... this should be solvable without a human involved.

I'd like to propose an addition to WHIP (and potentially WHEP but let's chat about it in regards to WHIP first) of a HTTP path that gives back a list of codecs/profiles/etc that the server supports. Its easy enough to just offer a load of codecs and allow negotiation to happen but that doesn't work when you get into specific profiles. Unsure whether it would be a GET to a specific path or what.... curious what others think on this.

Docs don't solve the problem here - this should be something you can programatically figure out in a standardised way.

[murillo128]

Note that this is not supported in any other ingest protocol, neither RTMP or SRT supports that.

[danjenkins]

Sorry @murillo128 I didn't see your reply.

Sure, but that doesn't mean that we shouldn't enable that in WHIP? There are only 4 mandatory codecs in WebRTC, but within those are variations etc. Plus all the non mandatory codecs that are available....