Hi NVIDIA team,
I’m testing NMOS Receiver control with DeepStream (using the nvdsnmosbin + nvdsudpsrc path) and I’m trying to enable SMPTE ST 2022-7 (redundant streams). I’m facing two issues:
constraintsdoes not allow selecting the expected interfaces (looks auto-decided)
When I query receiver constraints, I get something like:
[
{
"destination_port": {},
"interface_ip": { "enum": ["192.168.2.3"] },
"multicast_ip": {},
"rtp_enabled": {},
"source_ip": {}
}
]
Even though the container has multiple media interfaces (e.g. 192.168.1.3 and 192.168.2.3), interface_ip is constrained to a single IP. It feels like the selection is made internally (maybe by nvdsudpsrc / Rivermax) and cannot be controlled via NMOS Connection API.
Also, when I PATCH with an IP not listed in the constraint, schema validation fails:
curl -v -X PATCH \
"http://<nmos_host>:<port>/x-nmos/connection/v1.1/single/receivers/<receiver_id>/staged" \
-H "Content-Type: application/json" \
--data-binary '{
"master_enable": true,
"activation": { "mode": "activate_immediate" },
"transport_params": [
{
"interface_ip": "192.168.1.3",
"multicast_ip": "239.0.0.1",
"destination_port": 5004,
"rtp_enabled": true
}
]
}'
Response example:
{"code":400,"error":"Bad Request","debug":"schema validation failed at /transport_params/0/interface_ip ..."}
- Activating the staged parameters crashes the process (segfault)
If I stage parameters using the allowed interface_ip, the PATCH returns 200 OK.
But when I send activation, the HTTP connection returns “Empty reply from server”, and the container / python process crashes. Docker shows exit code 139 and host dmesg shows a segfault in python3 / libc.so.6. Core dumps are generated.
• Hardware Platform: GPU
• DeepStream Version: 8.0
• JetPack Version: none
• TensorRT Version: none
• NVIDIA GPU Driver Version: 570.172.08
• Issue Type: questions
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
-
Run a DeepStream container that exposes NMOS Node API and Connection API via
nvdsnmosbin(receiver) usingnvdsudpsrc(Rivermax path). -
Confirm receivers exist via the Node API:
GET http://<nmos_host>:<port>/x-nmos/node/v1.3/receivers/
-
Check constraints for a receiver:
-
GET http://<nmos_host>:<port>/x-nmos/connection/v1.1/single/receivers/<receiver_id>/constraints -
Observed:
interface_ip.enumcontains only one IP even though the container has two media NIC IPs (for ST 2022-7).
-
-
Stage transport parameters (using the allowed
interface_ip) and confirm it returns 200 OK:PATCH .../stagedwithmaster_enable=trueandtransport_params[0](interface_ip, multicast_ip, destination_port, rtp_enabled).
-
Trigger activation:
-
PATCH .../stagedwith{"activation":{"mode":"activate_immediate"}} -
Observed: HTTP client gets “Empty reply from server”, then the container crashes (exit code 139 / segfault). Core dump is generated on the host.
-
(Additional observation) If we PATCH interface_ip not listed in constraints, the API returns 400 Bad Request (schema validation error at /transport_params/0/interface_ip).
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
This might be a bug, but we also want to confirm if it’s supported / correct usage.
We want to control a SMPTE ST 2022-7 redundant receiver via the NMOS Connection API.
-
Expected: constraints should allow selecting the correct NIC/IPs (and ideally two paths) for ST 2022-7.
-
Expected: activation should apply staged parameters safely without crashing.
-
Question: Is ST 2022-7 via NMOS Connection API supported in
nvdsnmosbin/nvdsudpsrc? If yes, what is the correct schema/transport_params shape and workflow?