-
Notifications
You must be signed in to change notification settings - Fork 1
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
1.0-AF-edits #9
1.0-AF-edits #9
Conversation
docs/Overview.md
Outdated
|
||
Although the NDI Advanced SDK does allow NDI Native Devices to specify additional Sender transport parameters, these parameters and properties SHOULD NOT be exposed in NMOS. | ||
#### source_url | ||
The URL of the sender as utilized by the NDI SDK. Sender MUST report this upon activation. The contents are proprietary to the NDI SDK and SHOULD NOT be interpreted. A controller SHOULD specify `auto` or the current value when setting this property. If a controller does not specify `source_url` when updating the transport parameters, the sender shall treat it as `auto`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree with that requirement. The Sender shall be able to report the url before activation. The url is not the property of the NDI SDK, it is ndi:// ... and the device that implement an NDI Sender or Receiver is free to interpret it.
docs/Overview.md
Outdated
**group_name**: | ||
The NDI group of the source, `null` indicates the default group. | ||
#### source_url | ||
The URL of the sender as utilized by the NDI SDK. The contents are proprietary to the NDI SDK and SHOULD NOT be interpreted. A controller SHOULD specify this parameter with values provided by a sender's `transport_params` or the NDI SDK discovery methods. If this parameter is set to `null` or `auto`, the receiver shall determine for itself the value of `source_url`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above. The vendor implementing the NDI Receiver is free to interpret the url. The only requirement is that the url start with "ndi://"
…params and add section on IS-05 connection behaviour.
docs/Overview.md
Outdated
} | ||
] | ||
``` | ||
#### machine_name | ||
The name of the sender node in the NDI domain. A node MUST report the machine name being utilized by the NDI SDK. A controller SHOULD NOT specify a new `machine_name` but SHOULD use `null` or the current `machine_name`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"but SHOULD use auto
or the current machine_name
."
I think auto
should be used to tell the Sender to select the proper value.
docs/Overview.md
Outdated
|
||
Native NDI Devices will not necessarily support all these methods, so Controllers and Devices SHOULD specify as much information as is known in `transport_params`. If the NDI Receiver is not provided with one or more of the above parameters, but is able to determine the additional parameters, it MUST report these updated `transport_params` upon activation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As said in the Slack channel I think this is asking too much to the Receiver ans I would remove this sentence "If the NDI Receiver is not provided with one or more of the above parameters, but is able to determine the additional parameters, it MUST report these updated transport_params
upon activation."
…ms and IS-05 Connection Behaviour text
Update transport_params to include only machine_name, source_name, and source_url. Define Sender tags to specify NDI groups.