Add accelerated tensor-native media runtimes

[alexnorell]

Summary

This stacked PR adds accelerated, tensor-native media runtimes for NVIDIA Jetson and cloud GPUs. It is intentionally based on mvp/new-inference-pipeline.

• builds FFmpeg 7.1.3, GStreamer 1.24.12, and OpenCV 4.13 with the platform-appropriate NVIDIA acceleration paths
• adds native GStreamer/CUDA tensor bridges without a jetson-utils runtime dependency
• preserves Jetson BSP NVDEC/NVENC, NVJPEG, and NVMM support while retaining upstream nvcodec support for cloud/dGPU images
• enables RTSP, RTSPS, and the GStreamer WebRTC feature/dependency set
• adds a dedicated JetPack 7.2 media Dockerfile and GitHub Actions workflow
• keeps build toolchains, development packages, Mesa/LLVM, and intermediate artifacts out of runtime images
• gates tensor-frame delivery on consumer support and restores telemetry for tensor-native manager dispatches
• leaves camera-vendor SDKs out of the base image while retaining GStreamer, OpenCV, and V4L integration points for planned Basler/LUCID frame-grabber work

Why

The pipeline needs both hardware acceleration and tensor-native frame transport. Depending on the unmaintained Dusty-NV jetson-utils project would enlarge and constrain the base runtime, so the required zero-copy bridge behavior is implemented directly in this repository. The source builds provide a consistent feature surface across Jetson and cloud GPU targets while preserving NVIDIA's Jetson BSP plugins where they are required.

Validation

Automated

• targeted Python suites: 122 passed
• camera/manager suites: 137 passed, 28 deselected
• workflow boundary/tensor suites: 114 passed
• Black, isort, selected flake8 checks, shell syntax, and Python compile checks passed
• the new workflow passes actionlint (excluding the repository's custom Depot runner label)
• cold cloud build: https://github.com/roboflow/inference/actions/runs/29276246356
• warm-cache cloud build: https://github.com/roboflow/inference/actions/runs/29279087897 (60 seconds total; 26-second Depot build step)

JetPack 7.2 hardware (Thor)

• H.264 NVDEC, H.265 NVDEC, and NVJPEG hardware engines exercised
• OpenCV CUDA passed for Bayer 8/16-bit conversion, color conversion, resize, Gaussian filtering, and GStreamer capture
• H.264, H.265, and JPEG bridges reported zero host-pixel copies, zero H2D/D2H copies, and zero flatten copies; retained tensor lifetime passed
• product RTSPS path decoded 30 frames through uridecodebin with SAN-valid CA verification, NVMM, and nvJPEG
• WebRTC plugins and dependencies were verified; external signaling-peer interoperability was not exercised
• no Mesa, jetson-utils, compiler/dev dependencies, or build artifacts were present
• logical rootfs decreased from 1,100,011,666 bytes to 878,354,582 bytes (-20.15%); same-engine zstd export decreased from 358,816,837 bytes to 328,442,379 bytes (-8.47%)

JetPack 6.2 hardware (Orin AGX and Orin NX)

• SM87 bridge, JPEG/MJPEG zero-copy, NVJPEG, RTSPS, and OpenCV CUDA paths passed on both devices
• the available Orin devices run JetPack 6.2, so the exact JetPack 7.2-on-Orin image has not yet been exercised
• H.264/H.265 validation was blocked by the codec state of those BSP installations, rather than a repository build failure

Image/runtime notes

The Jetson image uses NVIDIA's BSP media plugins rather than the upstream GStreamer nvcodec plugin. Cloud GPU images retain the upstream nvcodec path. Runtime output contains only the libraries and plugins needed to execute these paths; compilation occurs in builder stages.

[PawelPeczek-Roboflow]

let's see here - since appsink is there passing to the other side - probably "frame is done" is assumed at the moment of passing frame to the app - and therefore decoding of file may not wait for frame to be fully processed

[PawelPeczek-Roboflow]

I would just empirically check and move on