-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
SRT: Support multiple querystring for authentication. #2893
Comments
This comment was marked as resolved.
This comment was marked as resolved.
…pairs with no nesting (ossrs#2893)
The parameters of RTMP must all be placed in the stream, not in the app. Originally, Adobe placed them in the app, but this looks messy.
It's better to place them naturally in the stream.
Therefore, the parameters of RTMP must not be placed in the app anymore. SRS supports placing them in the app for compatibility purposes, but the new ones cannot be placed here anymore.
|
This comment was marked as resolved.
This comment was marked as resolved.
Moved to #2893 (comment) |
…pairs with no nesting (ossrs#2893)
* SRT: parse srt url to supports multiple QueryStrings.(#2893) * SRT: url supports multiple QueryStrings by comma-separated key-value pairs with no nesting (#2893) * SRT: url supports multiple QueryStrings by comma-separated key-value pairs with no nesting (#2893) * SRT: Add comments for url. * Add utest for SRT URL parsing. * Update README. Co-authored-by: winlin <[email protected]>
Thanks @xiaozhihong @zhouxiaojun2008 |
Because SRT does not defines the querystring, or because streamid IS actually a querystring, so it's hard to use authentication in SRT URL. For example, a general SRT url defines as bellow:
How to pass something like
secret=xxx
in the URL? It's undefined, so we defined as:It also allows us to pass more than one querystring, for example:
SRT does not define QueryString, so there will be problems when switching to RTMP, and authentication cannot be done.
Usage
OBS streaming address:
rtmp://127.0.0.1/live/livestream?key1=value1&key2=value2
srt://127.0.0.1:10080?streamid=#!::r=live/livestream,key1=value1,key2=value2,m=publish
With VHOST parameter:
rtmp://127.0.0.1/live/livestream?vhost=host.com&key1=value1&key2=value2
srt://127.0.0.1:10080?streamid=#!::h=host.com,r=live/livestream,key1=value1,key2=value2,m=publish
FFPLAY playback address:
rtmp://127.0.0.1/live/livestream?key1=value1&key2=value2
srt://127.0.0.1:10080?streamid=#!::r=live/livestream,key1=value1,key2=value2,m=request
With authentication information:
rtmp://127.0.0.1/live/livestream?secret=xxx
srt://127.0.0.1:10080?streamid=#!::r=live/livestream,secret=xxx,m=publish
Publish by FFmpeg:
Play by ffplay:
Solution
If using domain (vhost) for push-pull streaming, the general correspondence between RTMP and SRT is:
rtmp://host.com/app/stream?key1=value1&key2=value2
srt://host.com:10080?streamid=#!::h=host.com,r=app/stream,key1=value1,key2=value2
It is also possible to directly use the IP to specify the domain for push-pull streaming.
rtmp://1.2.3.4/app/stream?vhost=host.com&key1=value1&key2=value2
srt://1.2.3.4:10080?streamid=#!::h=host.com,r=app/stream,key1=value1,key2=value2
Sometimes (often), SRS does not have a domain name (domain/vhost) and directly uses IP for push-pull streaming. In such cases:
rtmp://1.2.3.4/app/stream?key1=value1&key2=value2
srt://1.2.3.4:10080?streamid=#!::r=app/stream,key1=value1,key2=value2
Key points:
&
symbol should not be used, as it will be treated as a parameter separator by ffmpeg and OBS, resulting in the loss of input parameters.h=hostname
parameter needs to be included again in thestreamid
, whereas for RTMP, it is not required. This is because RTMP automatically includes thehostname
in thetcUrl
, while in SRT, it needs to be manually specified to differentiate the business domain.m=request|publish
represents whether it is a pull or push stream. The default is a pull stream.Regarding the definitions of
h
andr
, please refer to SRT: Standard Keys.r
: Resource Name identifies the name of the resource and facilitatesselection should the listener party be able to serve multiple resources.
h
: Host Name identifies the hostname of the resource. For example,to request a stream with the URI
somehost.com/videos/querry.php?vid=366
thehostname
field should havesomehost.com
, and the resource name can havevideos/querry.php?vid=366
or simply366
. Note that this is still a key to be specified explicitly. Support tools that apply simplifications and URI extraction are expected to insert only the host portion of the URI here.m
: Mode expected for this connection:request
(default): the caller wants to receive the streampublish
: the caller wants to send the stream databidirectional
: bidirectional data exchange is expectedReference document:
Compatible
The previously defined old URL format mainly included the stream information in the
h
parameter. It is currently still compatible, but it will be removed in the future. Please refrain from using it.Based on the article from the official SRT website: AccessControl
The latest modification to the SRT streaming address specification is:
URL for defaultVhost
URL for vhost
Based on the SRT official website, the format of the stream ID has Standard Keys. The SRT service in SRS should strive to comply with the official website standards.
Comply with the YAML format, starting with #!::.
The key "h" represents the vhost and appname/stream.
The key "m" represents publishing (publish) or requesting (request) a stream.
TRANS_BY_GPT3
The text was updated successfully, but these errors were encountered: