Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Supplemental rejection reason details exchange #1292

Open
maxsharabayko opened this issue May 15, 2020 · 1 comment
Open

[FR] Supplemental rejection reason details exchange #1292

maxsharabayko opened this issue May 15, 2020 · 1 comment
Labels
[core] Area: Changes in SRT library core Type: Enhancement Indicates new feature requests
Milestone

Comments

@maxsharabayko
Copy link
Collaborator

Use Case

  1. SRT caller
  • defines Stream ID according to the SRT Access Control guidelines.
  • (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.).
  1. 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.

  1. 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.

  2. 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.

@maxsharabayko maxsharabayko added Type: Enhancement Indicates new feature requests [core] Area: Changes in SRT library core labels May 15, 2020
@maxsharabayko maxsharabayko added this to the v1.5.0 milestone May 15, 2020
@maxsharabayko maxsharabayko modified the milestones: v1.5.0, v1.5.1 Jun 19, 2020
@mbakholdina mbakholdina modified the milestones: v1.5.1, Backlog May 26, 2021
@pkviet
Copy link

pkviet commented May 24, 2023

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:

  • codec not supported,
  • b frames not supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[core] Area: Changes in SRT library core Type: Enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

3 participants