Handle SRT Flow event attributes in live events in ninjs

[bquinn]

Word doc shared by @amitesharqiva :

DPP LPX Flow Parameters v1.docx

Quick summary of parameters needed (highlighted fields from word doc):

• Source name (short text string)
• Source type: SRT Listener, SRT Caller. (these will be ood enough for the hackathon. might need to add RTP, RIST, MediaConnect, Zixi Push, in the future)
• Fields from SRT Listener example:
  • Max bitrate bits/sec (number)
  • CIDR ?? (check if we need it, it wasn't highlighted in the doc)
  • Port (number 1024-65535)
  • SRT Password (optional, short text string)
• Fields from SRT Caller example:
  • Max bitrate bits/sec (number)
  • Min latency (ms) (number, should be between 100 and 15,000 ms)
  • port (number 1024-65535)
  • listener address (valid IP address or fully qualified domain name)
  • stream ID (optional, string up to 255 chars - first and last characters must be [a-zA-Z0-9] all other characters must be [a-zA-Z0-9-_])
  • SRT Password (optional, short text string)
• Fields from Profile form:
  • Codec (AVC and others...?)
  • Framerate numerator / framerate denominator
  • width, height
  • Scan type (progressive or interlaced)
  • Bitrate (bps)
  • GOP (frames) (number or "unspecified")
  • Colourspace (dropdown/enum, values are: REC_601, REC_709, HLG_2020, HDR10)
  • Rate control mode (dropdown/enum, values are: QVBR, VBR, CBR)

[iyoung]

@bquinn @himslm01 discussed on today's session. Brings up the in the URL or in the attributes (or both) conversation again and Mark's kindly going to ask if the URL is acceptable for the technical parameters above or if there's a value in them being broken out into attributes of the rendition.

[himslm01]

The feedback I got was that some of the properties naturally fit in the url, such as the stream id, but some don’t naturally fit.

For example from the feedback, max bitrate and min latency are more meta. They calibrate the SRT process.

It was suggested that a good process flow should enable a process to lift a URL as is without any processing and drop in to a SRT application.

The thoughts we that max bitrate and latency need to be provided outside of the URL. And an SRT application could assume some default values for these and/or validate values.

From the feedback, we can imagine a world where max bitrate forms part of a negotiation between a sender and receiver to manage network capacity. Or is calculated with properties of the renditions intended to be passed around.

[iyoung]

Looking at the SRT standard it looks like the protocol supports "max bandwidth" in bytes rather than max bitrate so that might be where max bitrate is seen as metadata to accompany the stream. Latency from what I can see is a widely supported parameter which is often supported in the URL (though I'm no expert). "It’s important to note that max bandwidth in SRT is measured in bytes per second. To set the max bandwidth parameter, first convert your bitrate to bytes per second (divide by 8). Then multiply by 2." - https://medium.com/@michael_70509/configuring-srt-properly-d89517354d0d

So I am wondering if we don't include these unless we're sure they're helpful as we do then have the issue of them diverging from the values in the URL in the case of latency or differing from the bitrate based calculation used to determine the max bandwidth set in the URL.