Haivision
Utility API to parse and/or set common SRT parameters from an URI
The intent of the ticket is to track a recurring request for a utility API implementation allowing to parse a URI string into a set of SRT parameters that can be used to create an SRT connection. The function should take into consideration existing implementations of SRT interface in the products and frameworks that are already in the field, thus some of the parameters will have more than one definition with the same meaning.
Here is a table of currently known parameter definitions:
| SRT option or special | srt-live-transmit | GStreamer plugin | other 1 |
|---|---|---|---|
| special:mode | mode:{"client"/"caller","server"/"listener","rendezvous"} | mode:{"caller","listener","rendezvous"} | mode:{"client"/"caller","server"/"listener","rendezvous"} |
| special:blocking | blocking:{BOOL} | ||
| special:timeout | timeout:{INT} | ||
| special:adapter | adapter:{STRING} | localaddress:{STRING} | localaddress:{STRING} |
| SRTO_TSBPDMODE | tsbpd:{BOOL} | ||
| SRTO_MAXBW | maxbw:{INT} | maxbw{INT, -1...} | maxbw{INT, -1...} |
| SRTO_PBKEYLEN | pbkeylen:{INT} | key*:{"0","128","192", "256"} | key*:{"0","128","192", "256"} |
| SRTO_PASSPHRASE | passphrase:{STRING} | pass*:{STRING} | pass*:{STRING} |
| SRTO_MSS | mss:{INT} | mss:{INT, -1...} | mss:{INT, -1...} |
| SRTO_FC | fc:{INT} | ||
| SRTO_SNDBUF | sndbuf:{INT} | srt-send:{INT, 0...} | srt-send:{INT, 0...} |
| SRTO_RCVBUF | rcvbuf:{INT} | srt-recv:{INT, 0...} | srt-recv:{INT, 0...} |
| SRTO_IPTTL | ipttl:{INT} | ipttl:{INT, -1...255} | ipttl, ttl:{INT, -1...255} |
| SRTO_IPTOS | iptos:{INT} | iptos:{INT, -1...255} | iptos, tos:{INT, -1...255} |
| SRTO_INPUTBW | inputbw:{INT} | input-rate, inrate:{INT. -1...} | input-rate, inrate:{INT. -1...} |
| SRTO_OHEADBW | oheadbw:{INT} | overhead:{INT, 5...100} | overhead, ohead:{INT, 5...100} |
| SRTO_LATENCY | latency:{INT} | ||
| SRTO_TSBPDDELAY | tsbpdelay:{INT} | latency, srtlatency:{INT, 0...} | latency:{INT, 0...} |
| SRTO_TLPKTDROP | tlpktdrop:{BOOL} | too-late:{INT, -1...1} | too-late:{INT, -1...1} |
| SRTO_NAKREPORT | nakreport:{BOOL} | ||
| SRTO_CONNTIMEO | conntimeo:{INT} | conntimeo:{INT, -1...} | |
| special:port | port:{INT} | localport:{INT, 1...} | localport:{INT, 1...} |
| special:ttl | ttl:{INT} | ||
| SRTO_RCVLATENCY | rcvlatency:{INT} | ||
| SRTO_PEERLATENCY | peerlatency:{INT} | ||
| SRTO_SENDER | sender:{BOOL} | side:{"sender","receiver"} | |
| SRTO_UDP_SNDBUF | udp-send:{INT, 0...} | udp-send:{INT, 0...} | |
| SRTO_UDP_RCVBUF | udp-recv:{INT, 0...} | udp-recv:{INT, 0...} |
The current vision is to provide the functionality via auxiliary API header, srt_uri.h or srt_utils.h
| SRT option or special | srt-live-transmit | GStreamer plugin | other 1 |
|---|---|---|---|
| SRTO_LINGER | linger:{INT} |
Actually the current implementation (since UDT) requires SRTO_LINGER to pass the struct linger type value, not integer. We can't even change it now without breaking backward compatibility.
@ethouris In URI parser we don't have to pass the actual struct linger.
Hi,
This is an old one but it could be worth increasing its priority. The RIST implementation in librist already does this and it greatly simplifies the development of applications and make them more resistant to enhancements in the SRT library.
Currently, all parameters have to be specified somehow in application settings and specific srt calls shall be used. If new features, new parameters, new srt functions are introduced, the applications shall be modified. If everything can be passed in a URI and a generic srt call with a semantics such as "start the connection with all parameters from the URI", then new features are transparent to applications, just relink or event just activate the new libsrt shared object.
