RK3576 VPU and NPU Hardware Acceleration Benchmark

RK3576 Benchmark Test Project Description

This project is used to quantitatively test the following three core capabilities on the RK3576 platform:

1. MPP video encoding capability
2. MPP video decoding capability
3. RKNN inference capability

It is intended for users of the reComputer RK3576 for:

• Chip capability assessment
• Security project selection
• Horizontal comparison of models and resolutions
• Regression testing during version iteration
• Customer reporting and technical delivery

Test contents:

• Encoding test: YUV420 -> MJPG / H264 / H265
• Decoding test: MJPG -> YUV420
• Inference test: 640x640 input with yolov8n / yolov8s / yolov8m
• Resolution coverage: 720p / 1080p / 2k / 4k / 8k

RK3576 Benchmark Summary

• generated_at: 2026-07-28 16:34:52
• target_fps: 30
• codec_frames: warmup 20 + measured 120
• infer_frames: warmup 20 + measured 200

Video Encode Benchmark (YUV420 -> MJPG / H264 / H265)

Video Decode Benchmark (MJPG -> YUV420)

YOLOv8 640x640 Inference Benchmark

Notices

• Video encode benchmark uses internally generated YUV420SP frames.
• Video decode benchmark uses internally generated MJPG elementary streams and measures MJPG -> YUV420 output.
• Inference benchmark uses 640x640 synthetic NV12 frames and measures full Infer call latency.

1. How to Run the Benchmark Project

It needs to be run on the reComputer RK3576 board.

Run the benchmark

sudo apt update && sudo apt install unzip -y
wget https://files.seeedstudio.com/RK3576/install.zip -O install.zip && unzip install.zip
cd ./install && export LD_LIBRARY_PATH="$(pwd)/lib:${LD_LIBRARY_PATH}" && chmod +x ./bin/rk3576_benchmark
sudo ./bin/rk3576_benchmark

Benchmark results

After the program finishes running, the results are located at:

ls benchmark_results/
benchmark_summary.md  video_codec_benchmark.csv  yolov8_inference_benchmark.csv

Common parameters

./bin/rk3576_benchmark \
  --output-dir ./benchmark_results \
  --resolutions 720p,1080p,2k,4k,8k \
  --models yolov8n,yolov8s,yolov8m \
  --codec-warmup 20 \
  --codec-frames 120 \
  --infer-warmup 20 \
  --infer-frames 200

2. Project Capabilities

The current benchmark project has the following capabilities:

• Automatically generate test frames without relying on external sample streams
• Automatically execute multi-resolution video encoding benchmarks
• Automatically execute multi-resolution MJPG hardware decoding benchmarks
• Automatically execute 640x640 YOLOv8 inference benchmarks
• Automatically output a Markdown summary report
• Automatically output CSV raw data for import into Excel or LibreOffice
• Support repeated tests and horizontal comparisons under the same test criteria

The output files by default include:

• benchmark_summary.md
• video_codec_benchmark.csv
• yolov8_inference_benchmark.csv

3. Test Process

The overall workflow is as follows:

1. Generate YUV420SP(NV12) test frames at the specified resolution
2. Call MPP Encoder to run MJPG / H264 / H265 encoding tests separately
3. Retain the MJPG bitstream and call MPP Decoder to run the MJPG -> YUV420 decoding test
4. Generate 640x640 NV12 test frames and call RKNN to run YOLOv8n/s/m inference tests
5. Aggregate metrics such as FPS, average latency, P95 latency, and output bitstream size
6. Generate Markdown and CSV reports

The characteristics of this workflow are:

• Stable data sources, unaffected by external stream quality fluctuations
• Uniform test input conditions for each run, suitable for version regression testing
• More suitable for evaluating the “core engineering capability” than a specific video asset

4. Technical Approach

4.1 Encoding Solution

The encoding part is implemented based on Rockchip MPP. The input is internally generated YUV420SP(NV12) frames, and the following are tested separately:

• MJPG
• H264
• H265

The focus is to evaluate the video compression throughput capability of RK3576 at different resolutions, which is suitable for the following security scenarios:

• IPC front-end encoding
• NVR edge recording and transcoding
• Multi-stream distribution
• Snapshot stream / sub-stream output

4.2 Decoding Solution

The decoding part is based on Rockchip MPP Decoder, and the current test metric is fixed as:

• MJPG elementary stream -> YUV420

Notes:

• The decoding path uses MPP's MJPEG decode path rather than software decoding
• The current README emphasizes the “hardware decode core capability” in the decoding results
• The definition of Decode FPS has been adjusted to be based on the accumulated core decoding latency rather than mixing in the wall-clock overhead of the test framework itself

This type of test is more suitable for the following security scenarios:

• JPEG / MJPEG camera access
• Snapshot stream decoding
• Front-end multi-channel snapshot analysis
• Edge gateway image unpacking and post-processing

4.3 Inference Solution

The inference part uses RKNN + YOLOv8, with a fixed input of 640x640. The current default test models are:

• yolov8n_rk3576.rknn
• yolov8s_rk3576.rknn
• yolov8m_rk3576.rknn

The statistical metrics include:

• Overall inference FPS
• Average latency
• P95 latency
• Average preprocessing latency
• Average NPU latency

This type of test is more suitable for the following security scenarios:

• Perimeter detection
• Human/vehicle unstructured analysis
• Single-channel real-time alerting
• Lightweight NVR intelligent analysis

5. Explanation of Result Metrics

5.1 Encoding Results

The encoding results are used to evaluate:

• Encoding throughput at different resolutions
• Relative efficiency of different encoding formats
• Balance between output bitstream size and real-time performance

5.2 Decoding Results

The decoding results currently retain only the “hardware decode core FPS” metric.

In other words:

• Decode Avg(ms) represents the average single-frame core decoding latency
• Decode FPS represents the throughput derived from the core decoding latency
• It does not include additional scheduling, logging, or debug reporting overhead from the test framework

5.3 Inference Results

The inference results are used to evaluate:

• Throughput differences caused by model size changes
• The achievable capability of single-channel real-time analysis
• Whether the solution is better suited to “high-frame-rate real-time detection” or “low-frame-rate high-accuracy analysis”

6. Objective Assessment Based on Current Test Results

The following assessment is based on the latest benchmark results already saved in install/benchmark_summary.md.

6.1 Video Codec Capability Assessment

Based on the current test results, the video-side capability of RK3576 is fairly complete, especially in MJPG encoding/decoding and H264/H265 encoding, where it performs stably.

1. MJPG Encoding Capability

The YUV420 -> MJPG encoding results are as follows:

• 720p: 480.7 FPS
• 1080p: 237.6 FPS
• 2k: 159.5 FPS
• 4k: 77.7 FPS
• 8k: 20.5 FPS

This result indicates that:

• At 720p / 1080p / 2k, MJPG encoding has a very large throughput margin
• At 4k, it still clearly exceeds real-time frame rate and is suitable for high-resolution snapshot capture, fast image-stream encoding, and forensics scenarios
• At 8k, although it can still run, throughput drops to about 20 FPS, making it more suitable for capability demonstration or specific project validation

2. H264 / H265 Encoding Capability

The YUV420 -> H264 encoding results are as follows:

• 720p: 154.7 FPS
• 1080p: 90.7 FPS
• 2k: 43.4 FPS
• 4k: 24.5 FPS
• 8k: 7.1 FPS

The YUV420 -> H265 encoding results are as follows:

• 720p: 179.2 FPS
• 1080p: 88.8 FPS
• 2k: 38.6 FPS
• 4k: 21.7 FPS
• 8k: 6.6 FPS

Based on the above data, a fairly clear conclusion can be drawn:

• At 720p / 1080p / 2k, both H264 and H265 have good real-time encoding capability
• At 4k, H264 is close to 25 FPS and H265 is around 21 FPS, which is close to the engineering limit for high-resolution real-time encoding
• At 8k, neither H264 nor H265 is suitable as a regular real-time main-stream encoding solution

3. MJPG Hardware Decoding Capability

The hardware decode core results for MJPG -> YUV420 are as follows:

• 720p: 380.4 FPS, average 2.6 ms
• 1080p: 268.6 FPS, average 3.7 ms
• 2k: 191.0 FPS, average 5.2 ms
• 4k: 108.6 FPS, average 9.2 ms
• 8k: 32.8 FPS, average 30.5 ms

In addition, all resolutions completed the 120/120 measured frames.

This indicates that:

• RK3576's MJPG hardware decode path is stable across the range from 720p to 8k
• At 1080p / 2k / 4k, decode throughput is significantly higher than real-time requirements, making it suitable for a variety of JPEG / MJPEG image-front-end scenarios
• At 8k, it still reaches 32.8 FPS, showing that the chip still has near-real-time processing capability in the MJPG hardware-decoding direction

This is especially valuable for security scenarios, because it means RK3576 is not only capable of handling traditional video streams, but is also suitable for:

• MJPEG camera access
• Snapshot stream decoding
• Pre-processing of image streams
• Front-end snapshot analysis

7.2 Inference Capability Assessment

The YOLOv8 inference results for 640x640 input are as follows:

• yolov8n: 35.5 FPS, average 27.3 ms
• yolov8s: 17.0 FPS, average 58.2 ms
• yolov8m: 9.5 FPS, average 104.2 ms

These data reflect that RK3576 is better suited to a “lightweight-model-first” deployment approach on the AI side for security applications.

1. yolov8n

yolov8n reached 35.5 FPS in the current test, which already covers common single-channel real-time analysis requirements of 25/30 FPS.

This means:

• Suitable for single-channel real-time human/vehicle detection
• Suitable for perimeter protection, intrusion detection, and basic object recognition
• Better suited as the default deployment model for edge devices

2. yolov8s

yolov8s reaches 17.0 FPS, which is in the range of “real-time capable, but with limited margin.”

It is better suited for:

• Scenarios where detection accuracy is more important than yolov8n
• Real-time services that use frame sampling or frame skipping
• Single-channel intelligent analysis with medium complexity

3. yolov8m

yolov8m reaches 9.5 FPS, which is closer to low-frame-rate intelligent analysis capability.

It is better suited for:

• Event-triggered analysis
• Low-frame-rate inspection analysis
• Offline review or non-continuous inference

If the goal is “single-channel full-frame-rate real-time detection,” yolov8m is not the most suitable default option.

7. Recommended Deployment Strategy

If the target is a real security project, the following strategy is recommended:

1. Prefer yolov8n as the default model
2. Use 1080p / 2k as the primary working resolution for edge real-time analysis
3. Use 4k as a high-quality video input source, with scaling or frame sampling on the AI side
4. Use 8k mainly to demonstrate chip capability or validate specific high-end scenarios; it is not recommended as a regular real-time AI baseline