Configuration#
VSR NIM ST 2110 deployments are configured through Helm values or through the NvidiaVsrNimMediaFunction custom resource.
VSR Processing Parameters#
The Helm chart and operator both expose VSR processing parameters.
For Helm, configure these values in the following location:
nvidia-vsr-nim-h4m-service:
vsr:
hqsr: true
srLevel: ultra
For the operator, configure them in the following location:
spec:
parameters:
vsr:
hqsr: true
srLevel: ultra
The following are common VSR parameters:
Parameter |
Type |
Default |
Description |
|---|---|---|---|
|
|
|
Enable super-resolution upscaling. This is the primary VSR enhancement path and adds GPU processing. |
|
|
|
Super-resolution quality level: |
|
|
|
Super-resolution mode for high-bitrate or uncompressed input. |
|
|
|
Enable denoise pre-processing to reduce source noise before upscaling. Enabling it adds GPU work and can affect performance. |
|
|
|
Denoise quality level: |
|
|
|
Enable deblur pre-processing to sharpen soft or blurred input before upscaling. Enabling it adds GPU work and can affect performance. |
|
|
|
Deblur quality level: |
|
|
|
Enable synthetic noise injection. |
Pipeline Configuration#
The sample chart uses global.vsrPipeline as the single source of truth for sender, VSR NIM service, and receiver transport values.
Configure this section to specify the following:
Input and output multicast groups.
UDP video ports.
Packet sizes.
Input and output video formats.
Sender and receiver behavior.
The default sample pipeline is as follows:
Sender 720p30 4:2:2 10-bit -> VSR NIM -> Receiver 4Kp30 4:2:2 10-bit
In the default sample pipeline, the ST 2110 input and output over the wire use UYVP / YCbCr 4:2:2 10-bit video. The sample receiver’s saved H.264 MPEG-TS artifact is encoded as H.264 High, yuv420p, 8-bit.
The sample sender generates a live SMPTE color bars test pattern by default and requires no input asset.
Replace the test multicast addresses with addresses allocated by your network team before production use.
Default global.vsrPipeline Structure#
The sample Helm chart uses the following global.vsrPipeline structure to keep the sender, VSR NIM service, and receiver aligned:
global:
vsrPipeline:
input:
multicastIp: "233.252.0.1"
videoPort: 50004
udp:
headerSize: 20
payloadSize: 800
packetsPerLine: 4
useRtpTimestamp: 1
ptpSrc: "set"
format:
width: 1280
height: 720
framerate: 30
sampling: "YCbCr-4:2:2"
depth: 10
colorimetry: "BT709"
output:
multicastIp: "233.252.0.2"
videoPort: 50004
udp:
headerSize: 20
payloadSize: 1220
packetsPerLine: 8
numPackets: 300000
outputQueueMaxBuffers: 0
sync: 0
async: 0
passRtpTimestamp: 1
rtpTimestampOffset: 2000000
ptpSrc: "set"
format:
width: 3840
height: 2160
framerate: 30
sampling: "YCbCr-4:2:2"
depth: 10
colorimetry: "BT709"
Network, UDP, RTP, and PTP Settings#
The sender/VSR-input hop and the VSR-output/receiver hop must agree on multicast groups, ports, and packet shape. For the sample chart, configure these values through global.vsrPipeline.
Parameter |
Default |
Description |
|---|---|---|
|
|
Sender to VSR input multicast group. The sender emits to this address and the VSR service subscribes on it. |
|
|
UDP port for the sender-to-VSR input hop. |
|
|
VSR output to receiver multicast group. The VSR service emits to this address and the receiver subscribes on it. |
|
|
UDP port for the VSR output-to-receiver hop. |
|
|
RTP header size in bytes for the sender-to-VSR input hop. |
|
|
RTP payload bytes after the header for the sender-to-VSR input hop. |
|
|
Sender packets per active video line. |
|
|
VSR input |
|
|
VSR input |
|
|
RTP header size in bytes for the VSR output-to-receiver hop. |
|
|
VSR output UDP payload bytes, including the RTP header. |
|
|
VSR output packets per active video line. |
|
|
Receiver Rivermax RX ring buffer depth, in packets. |
|
|
VSR output |
|
|
VSR output |
|
|
VSR output |
For the default 3840 × 2160 10-bit 4:2:2 output, the VSR output hop renders payload_size=1220, packets_per_line=8, and receiver payload-size=1200.
Video Format Settings#
The format fields render the SDP a=fmtp:96 media attributes for each stream.
Field |
Default |
SDP Attribute |
Description |
|---|---|---|---|
|
|
|
Frame width in pixels. |
|
|
|
Frame height in pixels. |
|
|
|
Frame rate in Hz. |
|
|
|
Color sampling. |
|
|
|
Component depth in bits. |
|
|
|
Colorimetry. Supported values for VSR include |
The chart renders SDP TCS=SDR for both hops. For YCbCr-4:2:2 10-bit, the GStreamer pipeline uses format=UYVP.
NMOS and Static ST 2110#
Mode |
Configuration |
|---|---|
NMOS |
Enable NMOS and provide registry and controller access through the Holoscan for Media platform. |
Static ST 2110 |
Disable NMOS and configure transport through Helm values or inline SDP in the operator CR. |
In static ST 2110 mode, the Helm chart and operator self-activate local IS-05 senders and receivers from the configured transport values.
In NMOS mode, an empty registration URL uses DNS-SD discovery for the NMOS registry. If DNS-SD is not available, set the explicit IS-04 registration URL for the Helm chart or spec.parameters.nmosRegistrationUrl for the operator CR. Verify VSR NIM registration in the NMOS registry before relying on explicit registration URL mode.
Network Attachments#
VSR NIM uses one receive attachment and one transmit attachment by default:
highSpeedNetwork:
- name: media-a-rx-net
- name: media-a-tx-net
The in-pod local interface names must align with the generated ST 2110 configuration. The examples use net1 for receive and net2 for transmit.
For Helm service values, the equivalent network keys are as follows:
network:
rxName: media-a-rx-net
txName: media-a-tx-net
The rxName and txName keys describe how the VSR NIM pod uses each interface. The default media-a-rx-net and media-a-tx-net names are sample values. Replace them with the NetworkAttachmentDefinition resources available in your cluster. If the selected attachments support the traffic direction used by the pod, the underlying media networks do not need to be RX-only or TX-only.
If your SR-IOV device plugin exposes named Rivermax resources, set optional resource-pool annotations:
network:
rxPoolResource: nvidia.com/rivermax_rx
txPoolResource: nvidia.com/rivermax_tx
rxPoolCount: 1
txPoolCount: 1
For clusters in which the VSR input and output attachments must come from the same NUMA-local SR-IOV pool, set both VSR network names to the same attachment and request two virtual functions from that pool:
nvidia-vsr-nim-h4m-service:
network:
rxName: media-b-rx-net
txName: media-b-rx-net
rxPoolResource: openshift.io/media_b_rx_pool
rxPoolCount: 2
txPoolResource: ""
input:
video:
localInterfaceName: net1
output:
video:
localInterfaceName: net2
Under Multus, each secondary network attachment appears inside the pod as an interface such as net1 or net2. The VSR NIM service uses input.video.localInterfaceName and output.video.localInterfaceName to bind Rivermax to the intended media interfaces. Keep the defaults unless your CNI assigns different in-pod interface names.
Runtime and Logging#
The following are common runtime settings:
Setting |
Description |
|---|---|
|
Sets the VSR application GPU ID. Kubernetes device plugins own GPU allocation. |
|
Sets |
|
Sets |
|
Secret mounted at |
|
Kubernetes image pull secrets for private registry images. |
|
CPU, memory, hugepages, and GPU requests and limits. |
|
Scheduler used for the media function pod. |
|
Node selection constraints. |
gpuId is the GPU ordinal visible inside the VSR container. It is not the physical GPU number on the host. With the default one-GPU pod, keep gpuId set to "0" and use Kubernetes node selection, scheduler policy, or NVIDIA device plug-in configuration to steer the pod to a physical GPU.