How to register to video receiver node to support 1080p and 720p, 60fps and 50fps

[DaveHu-TVU]

Hi all,

I need to support registering a receive node for video which can support 720p and 1080p, 50fps and 60fps video, so how should my sdp file be defined?

code:
NvNmosReceiverConfig sourceConfig[2] = { 0 };
sourceConfig[0].sdp = strVRecSdpContent.c_str();
sourceConfig[1].sdp = strARecSdpContent.c_str();
nodeConfig.receivers = &sourceConfig[0];
nodeConfig.num_receivers = 2;

the contant of strVRecSdpContent is:
v=0
o=- 1735271365 1735271365 IN IP4 192.168.1.233
s=TVU 46BB/video
t=0 0
a=x-nvnmos-id:sourcev46BB
a=x-nvnmos-group-hint:rx46BB:video
a=recvonly
m=video 7000 RTP/AVP 96 97 98
c=IN IP4 224.1.1.3/64
a=source-filter: incl IN IP4 224.1.1.3 192.168.1.231
a=rtpmap:96 raw/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1920; height=1080; depth=10; exactframerate=60/1; TCS=SDR; colorimetry=BT.709; PM=2110GPM; SSN=ST2110-20:2017; TP=2110TPN
a=rtpmap:97 raw/90000
a=fmtp:97 sampling=YCbCr-4:2:2; width=1920; height=1080; depth=10; exactframerate=60000/1001; TCS=SDR; colorimetry=BT.709; PM=2110GPM; SSN=ST2110-20:2017; TP=2110TPN
a=rtpmap:98 raw/90000
a=fmtp:98 sampling=YCbCr-4:2:2; width=1920; height=1080; depth=10; exactframerate=30/1; TCS=SDR; colorimetry=BT.709; PM=2110GPM; SSN=ST2110-20:2017; TP=2110TPN
a=mediaclk:direct=0
a=x-nvnmos-iface-ip:192.168.1.233

but it doesn't work, can you help to debug it or tell me the way to register it ? thanks!!

[garethsb]

This feature request is on our roadmap.

For background, NMOS basically requires that Senders always indicate the precise format for which they are currently configured, even if they're not currently transmitting. The SDP passed to add_nmos_sender_to_node_server is used to initialize this. The common IS-04 and IS-05 APIs do not provide any way for a client to change the format, only the transport parameters (destination IP address, port, etc.). There is a more recent specification, IS-11 Stream Compatibility Management, which allows a sender to indicate that its format can be reconfigured within certain constraints. This is not widely implemented yet (server-side or client-side), but I expect this to be supported in nmos-cpp and nvnmos during 2025 first half - see sony/nmos-cpp#271. For now, you would need to implement a proprietary API to allow the format of a Sender to be reconfigured externally.

For Receivers, the IS-04 API has more flexibility, via optional “Receiver Capabilities”, to describe a range of formats it can accept, or to leave it completely unconstrained. Currently, nvnmos uses the SDP file passed to add_nmos_receiver_to_node_server to tightly constrain the format. During 2025 Q1, I intend to add support for creating (a) fully unconstrained Receivers, (b) partially constrained Receivers (via multiple constraint sets and/or less-constraining ones). That could be requested using multiple dynamic payload types as you show, or simply multiple SDP files. Right now, you can implement fully unconstrained Receivers simply by removing the code that adds constraint_sets (e.g. nvnmos_impl.cpp#L368-L381 for video Receivers).

[DaveHu-TVU]

Got it, thanks! please commit here when you are done this feature.

[DaveHu-TVU]

Hi @garethsb ,
I remove the source code from nvnmos_impl.cpp#L368-L381, it works well, but how about the audio receiver node? I referenced video to also remove this code from audio and it doesn't seem to be working. I was expecting something like those parameters for video, with the audio bit depth, number of channels and sample rate also unaffected.

[garethsb]

OK, when I configure an audio receiver with L24/48000/2 it normally does not accept L24/48000/8 (change in channel count) or L24/96000/2 (change in sample rate) or L16/48000/2 (change in sample depth).

When I remove the constraints code as you have done, it does accept the first two, but still doesn't allow L16/48000/2 with the error "Transport file error - sdp processing error - unsupported encoding name".

This is due to the media_types capability which is set up by the audio.bit_depth argument to the nmos::make_audio_receiver call on the previous line. If we change this as well, e.g. to { 16, 24 }, to use a different overload, it will construct a receiver with:

  "caps": {
    "media_types": [
      "audio/L16",
      "audio/L24"
    ]
  }

All of the above are then accepted by the receiver.