You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(potentially) provides a stram definition (see Stream Definition Protocol) for what type of content it wants to access (video/audio codec type, multiplexing protocol, etc.).
SRT Listener
Receives the connection request. In a listener callback it checks SRT Access Control info (Stream ID) and Stream Definition Protocol.
It rejects the connection, sets rejection reason ID and provides rejection reason details (message), e.g. certain codec is not available.
TODO
This FR is a draft that has to be further defined.
Roughly it has two more or less independent features to implement.
Let listener send back not only rejection reason ID, but also a supplemental message with rejection details to the caller.
The caller that has to have an API function to retrieve this supplemental message.
Decide probably on additional handshake extension to transmit Stream Definition.
Example
For example, the client (caller) wants to initiate streaming. It provides metadata about audio/video codecs and containers used by the stream. Then, the server detects, that e.g. AAC codec is not supported, so it rejects the connection in the listener callback. And specifies the HTTP status code 406 Not Acceptable, and provides only the AAC field in the StreamID of the response handshake.
The text was updated successfully, but these errors were encountered:
We're interested in this as discussed with Maxim in obs-studio since we've expanded codec support for SRT (aac, opus, h264, hevc and av1 when its mpegts carriage spec is finalized). So we get into issues since the ingest server is not able to give info on the reason.
Another issue we had with Justus during the PlugFest was that Makito X decoder required 0 bframes so our obs stream was rejected but we didn't know why. Took a while to find out the reason.
So that's two examples of codec issues that we'd like the receiver to notify the sender:
Use Case
TODO
This FR is a draft that has to be further defined.
Roughly it has two more or less independent features to implement.
Let listener send back not only rejection reason ID, but also a supplemental message with rejection details to the caller.
The caller that has to have an API function to retrieve this supplemental message.
Decide probably on additional handshake extension to transmit Stream Definition.
Example
For example, the client (caller) wants to initiate streaming. It provides metadata about audio/video codecs and containers used by the stream. Then, the server detects, that e.g. AAC codec is not supported, so it rejects the connection in the listener callback. And specifies the HTTP status code 406 Not Acceptable, and provides only the AAC field in the StreamID of the response handshake.
The text was updated successfully, but these errors were encountered: