Gst-nvinfer hangs at preroll (FPS=0) on Phytium aarch64 + RTX 5080 + DeepStream 8.0 SBSA container

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Hi,

I’m running DeepStream 8.0 on an aarch64 platform and experiencing
gst-nvinfer hanging at preroll stage. Looking for help or known workarounds.

=== Platform ===

  • CPU: Phytium (飞腾) aarch64 dual-socket
  • Motherboard: Great Wall RFMS5H2TA (BIOS T652FBE_V3.0.06)
  • OS: openEuler 24.03 LTS (aarch64)
  • GPU: RTX 5080
  • Driver: 570.133.20 (also tested 595.84, same result)
  • Container: nvcr.io/nvidia/deepstream:8.0-triton-arm-sbsa
  • TensorRT: 10.9.0.34 (inside container)
  • CUDA: 12.8
  • nvidia-container-toolkit: 1.19.1

=== Problem Description ===
When running any pipeline containing gst-nvinfer,
the pipeline hangs at PREROLLING stage forever (FPS=0.00).
No error is printed. The pipeline never proceeds past preroll.

When GST_DEBUG is enabled, this error appears:
gstnvinfer.cpp:1483:convert_batch_and_push_to_input_thread:
NvBufSurfTransform failed with error -2 while converting buffer

=== What WORKS ===

  1. trtexec runs perfectly with same engine:
    trtexec --loadEngine=resnet18_trafficcamnet_pruned.onnx_b4_gpu0_fp16.engine
    Result: 1624 qps, PASSED

  2. Pure decode + streammux + fakesink (NO nvinfer) works fine:
    gst-launch-1.0
    filesrc location=sample_1080p_h264.mp4 ! qtdemux ! h264parse !
    nvv4l2decoder ! m.sink_0
    nvstreammux name=m batch-size=4 width=1920 height=1080 !
    fakesink
    Result: 4 sources all EOS successfully, App run successful

  3. Official deepstream-app example WITHOUT nvinfer/tracker: works fine

=== What FAILS ===
Any pipeline with nvinfer hangs, even the simplest single-source case:

gst-launch-1.0
filesrc location=sample_1080p_h264.mp4 ! qtdemux ! h264parse !
nvv4l2decoder ! m.sink_0
nvstreammux name=m batch-size=1 width=1920 height=1080
live-source=0 batched-push-timeout=40000 !
nvinfer config-file-path=minimal_infer.txt !
fakesink -v

Last output before hanging forever:
Load new model: minimal_infer.txt successfully ← model loads OK
Pipeline is PREROLLING …
[all pad caps negotiated successfully] ← caps OK
0:00:00.0 / 0:00:48.1 (0.0%) ← stuck here forever

Official deepstream-app 4-source example WITH nvinfer:
FPS 0: 0.00 FPS 1: 0.00 FPS 2: 0.00 FPS 3: 0.00 (forever)

Same example on x86 (Ubuntu + bare-metal DS8.0):
FPS 0: 30.40 FPS 1: 30.40 FPS 2: 30.40 FPS 3: 30.40 (normal)

=== Already Ruled Out ===

  • TensorRT issue: trtexec works perfectly (1624 qps)
  • Engine file issue: engine builds and loads successfully
  • batch-size mismatch: tested batch-size=1 single source, same hang
  • Driver version: tested both 570.133.20 and 595.84, same result
  • nvbuf-memory-type: tested type=0 and type=2, same result
  • PCIe bandwidth: pure decode works fine under same PCIe conditions
  • libcuda version conflict: verified all libs point to 570.133.20
  • tracker/secondary-gie: disabled both, same hang with nvinfer only

=== Question ===

  1. Is there a known compatibility issue with gst-nvinfer /
    NvBufSurfTransform on SBSA aarch64 with Blackwell (sm_120) GPU?
  2. Is DeepStream 8.0 SBSA container officially validated on
    Phytium CPU + openEuler combination?
  3. Is there any workaround, such as using nvinferserver instead
    of nvinfer?

Any help would be greatly appreciated.
Thank you.

3
  1. As the shown in the doc, DeepStream can work on GB200, which is Blackwell.
  2. As shown in the doc, DeepStream only supports Ubuntu. Hence please fix this issue first. Please make sure you use the start command-line in the doc to start SBSA dokcer.
4

Thank you for your reply. To clarify my setup: 1. I am using the official SBSA docker container: docker pull nvcr.io/nvidia/deepstream:8.0-triton-arm-sbsa I understand the container itself is based on Ubuntu, so the OS inside the container is Ubuntu. The issue I’m describing is happening INSIDE this official docker container. 2. On the host machine (Phytium aarch64 CPU, openEuler 24.04 OS), I installed NVIDIA driver 570.133.20 and nvidia-container-toolkit, then launched the container with: docker run -it --rm --runtime=nvidia --network=host \ -e NVIDIA_DRIVER_CAPABILITIES=compute,utility,video,graphics \ --gpus all --privileged \ nvcr.io/nvidia/deepstream:8.0-triton-arm-sbsa 3. Inside this container, I ran the official deepstream-app examples. The problem I observed: When running any pipeline that includes nvinfer (even the simplest single-source case), the pipeline hangs at PREROLLING with FPS=0.00 forever. The decoder utilization (nvidia-smi dmon) shows 0%. However, when I disable nvinfer (primary-gie enable=0, tracker enable=0), the pipeline runs perfectly - all 4 sources decode and reach EOS successfully. Additional observation: Even before the nvinfer hang issue, I noticed that when starting the pipeline (both RTSP streams and local video files), it takes a very long time before the decoder starts working. The stream seems to take a long time to be pulled/opened. This delay does not happen on my x86 Ubuntu bare-metal setup running the same application with the same streams. My question: 1. Is there a known issue with gst-nvinfer / NvBufSurfTransform on ARM SBSA platform with RTX 5080 (Blackwell sm_120)? 2. Why does the pipeline hang specifically when nvinfer is enabled, while pure decode+streammux works fine? 3. Is there any workaround available, such as using nvinferserver instead of nvinfer? Thank you.

5

please refer to my last comment.

  1. no know compatibility issue with gst-nvinfer.
  2. No, as the shown in installation guide, you must install Ubuntu. As shown in the doc . And SBSA container only supports GH200, GB200, SBSA. Please make sure your aarch64 system is SBSA. AYK, not all aarch64 systems are SBSA.
  3. I suggest resolving the installation environment issue first. when you run with nvinfer, was the engine generated? The engine takes some time to generate. could you share a running log?
6

There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks.