AMWA NMOS IS-05 1.2-dev / MXL Support#483
Conversation
jonathan-r-thorpe
commented
Mar 5, 2026
- Prototype used to demonstrate MXL integration with NMOS
…e and use "auto" in /staged)
…id-auto Add support for "auto" to MXL sender flow_id transport parameter
…nnections Renamed flow_id to mxl_flow_id in MXL sender and receiver connections
garethsb
left a comment
There was a problem hiding this comment.
Forgot to submit this last week, sorry...
| // BCP-007-03: PATCH /staged for MXL receivers must not contain transport_file. | ||
| // See https://specs.amwa.tv/bcp-007-03/branches/publish-auto-null/docs/NMOS-With-MXL.html |
There was a problem hiding this comment.
@jonathan-r-thorpe I think this is a mistake in the spec? Given that the response schema requires that transport_file is present, I think it should be valid to stage:
"transport_file": {
"type": null,
"data": null
}There was a problem hiding this comment.
The BCP-007-03 spec is ambiguous on this so I'll raise it as an issue on the spec.
BCP-007-03 says PATCH /staged for MXL receivers is “not expected to contain” transport_file, and that controllers “MUST NOT provide” the attribute — which I read as prohibiting the key entirely. That’s stricter than the IS-05 stage schema, as you point out. I think this might become moot if the position on transport_file changes in the spec...
There was a problem hiding this comment.
Yeah, I think that MUST NOT is a mistake that makes an edge case where there need not be one.
| flow = nmos::make_raw_audio_flow(flow_id, source_id, device_id, 48000, 32, model.settings); | ||
| flow.data[nmos::fields::media_type] = value::string(U("audio/float32")); |
There was a problem hiding this comment.
⬇️ Maybe we should use make_audio_flow or have another overload of make_raw_audio_flow, so we don't have to rewrite the media_type?
There was a problem hiding this comment.
Use nmos::make_coded_audio_flow perhaps?
There was a problem hiding this comment.
Yeah... except we want bit_depth, I think?
There was a problem hiding this comment.
Good catch - will update
Co-authored-by: Gareth Sylvester-Bradley <31761158+garethsb@users.noreply.github.com>
Get-NetIPConfiguration fails when multiple adapters map to one interface; use the default route and Get-NetIPAddress instead, and only disable vEthernet (nat) when present.
…_audio_flow for MXL audio ports
| // video_type: media type of video flows, e.g. "video/raw" or "video/jxsv", see nmos::media_types | ||
| const web::json::field_as_string_or video_type{ U("video_type"), U("video/raw") }; | ||
|
|
||
| // mxl_video_type: media type of MXL video flows and receivers, e.g. "video/v210" or "video/v210a", see nmos/mxl.h | ||
| const web::json::field_as_string_or mxl_video_type{ U("mxl_video_type"), nmos::media_types::video_v210.name }; | ||
|
|
There was a problem hiding this comment.
@jonathan-r-thorpe I can't decide if it's a good idea to use the nmos::media_types::video_v210.name here (so long as it never suffers from static initialization order fiasco? that might be the reason that we didn't do it above for "video/raw"?)
There was a problem hiding this comment.
Keep it consistent I think.
| fi | ||
|
|
||
| do_run_test IS-04-01 $expected_disabled_IS_04_01 --host "${host}" --port 1080 --version v1.3 | ||
| do_run_test IS-04-01 $expected_disabled_IS_04_01 --host "${host}" --port 1080 --version v1.3 --ignore test_19 |
There was a problem hiding this comment.
Do we need to raise an issue or PR on the NMOS Testing Tool?
There was a problem hiding this comment.
Already did it AMWA-TV/nmos-testing#895 👍
|
@jonathan-r-thorpe @lo-simon If this isn't going to get merged imminently (although that would be nice!) would you consider extracting d499aac into a separate PR so we can have running CI on Windows again? |