1. # RK3576 Benchmark Test Project Guide

   ## 1. Project Positioning

   This project is designed to quantify three core capabilities of the `RK3576` platform:

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

   The goal of this project is not to build a business demo page. Instead, it provides a repeatable, comparable, and file-based benchmark workflow on the target board, which is useful for:

   - SoC capability evaluation
   - Security project selection
   - Model and resolution comparison
   - Version-to-version regression testing
   - Customer reporting and technical delivery

   The default benchmark scope matches the confirmed requirements of this project:

   - Encode test: `YUV420 -> MJPG / H264 / H265`
   - Decode test: `MJPG -> YUV420`
   - Inference test: `yolov8n / yolov8s / yolov8m` at `640x640`
   - Resolution coverage: `720p / 1080p / 2k / 4k / 8k`

   ## 2. Project Capabilities

   This benchmark project currently provides the following capabilities:

   - Generates test frames automatically without relying on external sample videos
   - Runs multi-resolution video encode benchmarks
   - Runs multi-resolution MJPG hardware decode benchmarks
   - Runs 640x640 YOLOv8 inference benchmarks
   - Outputs Markdown summary reports
   - Outputs CSV raw data for Excel / LibreOffice analysis
   - Supports repeated runs and side-by-side comparison under the same test methodology

   Default output files:

   - `benchmark_summary.md`
   - `video_codec_benchmark.csv`
   - `yolov8_inference_benchmark.csv`

   ## 3. Test Workflow

   The overall workflow is:

   1. Generate `YUV420SP(NV12)` test frames at the target resolutions
   2. Run `MPP Encoder` for `MJPG / H264 / H265`
   3. Keep the generated `MJPG` stream and run `MPP Decoder` for `MJPG -> YUV420`
   4. Generate `640x640 NV12` test frames and run `RKNN` inference for `YOLOv8n/s/m`
   5. Collect FPS, average latency, P95, encoded size, and related metrics
   6. Generate Markdown and CSV reports

   Key characteristics of this workflow:

   - Stable data source, not affected by external stream quality fluctuations
   - Unified input conditions across runs, suitable for regression testing
   - Better suited for evaluating the core engine capability of the project rather than a specific video clip

   ## 4. Technical Approach

   ### 4.1 Encoding Path

   The encoding path is based on `Rockchip MPP`. The input is internally generated `YUV420SP(NV12)` frames, and the benchmark covers:

   - `MJPG`
   - `H264`
   - `H265`

   This test is intended to evaluate video compression throughput on RK3576 across different resolutions, which maps well to the following security workloads:

   - IPC front-end encoding
   - NVR record-and-transcode pipelines
   - Multi-stream distribution
   - Snapshot stream / sub-stream output

   ### 4.2 Decoding Path

   The decoding path is based on `Rockchip MPP Decoder`, with the current fixed scope:

   - `MJPG elementary stream -> YUV420`

   Notes:

   - The decoder uses the `MPP` `MJPEG` hardware decode path, not software decode
   - The decode result in this README focuses on the "hardware decode core capability"
   - `Decode FPS` is defined by accumulated decode-core latency, excluding benchmark framework wall-clock overhead

   This is especially relevant to security workloads such as:

   - JPEG / MJPEG camera access
   - Snapshot stream decoding
   - Front-end image stream preprocessing
   - Edge gateway image unpacking and post-processing

   ### 4.3 Inference Path

   The inference path uses `RKNN + YOLOv8`, with fixed `640x640` input. The default benchmark models are:

   - `yolov8n_rk3576.rknn`
   - `yolov8s_rk3576.rknn`
   - `yolov8m_rk3576.rknn`

   Reported metrics include:

   - End-to-end inference FPS
   - Average latency
   - P95 latency
   - Average preprocess time
   - Average NPU time

   This is relevant to security applications such as:

   - Perimeter detection
   - Human and vehicle analytics
   - Single-stream real-time alerting
   - Lightweight NVR intelligence

   ## 5. How To Run

   It is recommended to run the benchmark on the RK3576 board.

   ### 5.1 Build

   ```bash
   cd /home/parker/Projects/rk3576_mpp_test
   chmod +x scripts/build-linux.sh
   ./scripts/build-linux.sh
   ```

   ### 5.2 Run the benchmark

   ```bash
   cd /home/parker/Projects/rk3576_mpp_test/install
   export LD_LIBRARY_PATH="$(pwd)/lib:${LD_LIBRARY_PATH}"
   ./bin/rk3576_benchmark
   ```

   ### 5.3 Common parameters

   ```bash
   ./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
   ```

   ## 6. Metric Definitions

   ### 6.1 Encode results

   Encode results are used to evaluate:

   - Throughput at different resolutions
   - Relative efficiency of different codecs
   - Balance between output bitstream size and real-time capability

   ### 6.2 Decode results

   Decode results only keep the "hardware decode core FPS" metric.

   That means:

   - `Decode Avg(ms)` is the average core decode latency per frame
   - `Decode FPS` is derived from accumulated core decode latency
   - It does not include extra framework overhead such as scheduling, logging, or debug reporting

   ### 6.3 Inference results

   Inference results are used to evaluate:

   - Throughput differences caused by model scale
   - Practical single-stream real-time analytics capability
   - Whether the platform is better suited for high-frame-rate detection or lower-frame-rate higher-accuracy analysis

   ## 7. Objective Assessment Based on Current Test Results

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

   ### 7.1 Video Encode and Decode Capability

   The current benchmark shows that RK3576 has a well-rounded video pipeline, especially for `MJPG` encode/decode and `H264/H265` encoding.

   #### 1. MJPG encoding

   `YUV420 -> MJPG` results:

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

   This indicates:

   - Very large throughput headroom for `720p / 1080p / 2k`
   - `4k` still stays well above real-time frame rate, which is useful for high-resolution snapshot, image stream encoding, and evidence-oriented scenarios
   - `8k` still runs, but throughput drops to around `20 FPS`, making it more suitable for capability demonstration or specific validation cases

   #### 2. H264 / H265 encoding

   `YUV420 -> H264` results:

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

   `YUV420 -> H265` results:

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

   These numbers support several practical conclusions:

   - `H264/H265` both provide solid real-time encoding capability at `720p / 1080p / 2k`
   - At `4k`, `H264` is close to `25 FPS`, while `H265` is around `21 FPS`, which is already near the practical edge for high-resolution real-time encoding
   - At `8k`, neither `H264` nor `H265` should be treated as a default real-time primary-stream solution

   From a compression-efficiency perspective:

   - At the same target bitrate, `H265` usually produces a smaller output file than `H264`
   - In this benchmark, `H265` throughput does not clearly exceed `H264`
   - On RK3576, `H265` is therefore better understood as a tradeoff: higher compression efficiency at the cost of some throughput

   #### 3. MJPG hardware decode

   `MJPG -> YUV420` hardware decode core results:

   - `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`

   All resolutions also completed `120/120` measured frames successfully.

   This means:

   - The `MJPG` hardware decode path on RK3576 is stable from `720p` to `8k`
   - At `1080p / 2k / 4k`, decode throughput stays far above real-time requirements
   - Even at `8k`, the platform still reaches `32.8 FPS`, which is close to real-time in the MJPG hardware decode domain

   This is especially valuable for security projects involving:

   - MJPEG camera integration
   - Snapshot stream decoding
   - Image-stream preprocessing
   - Front-end snapshot analytics

   ### 7.2 Inference Capability

   YOLOv8 inference results at `640x640`:

   - `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 results indicate that RK3576 is best used with a "lightweight model first" deployment strategy in security workloads.

   #### 1. yolov8n

   At `35.5 FPS`, `yolov8n` already covers typical `25/30 FPS` single-stream real-time analysis requirements.

   That makes it suitable for:

   - Single-stream real-time human/vehicle detection
   - Perimeter and intrusion-style analytics
   - Default edge deployment

   #### 2. yolov8s

   At `17.0 FPS`, `yolov8s` is still real-time for some workloads, but the headroom is much smaller.

   It is better suited for:

   - Scenarios where better accuracy is preferred over `yolov8n`
   - Real-time services with frame skipping
   - Single-stream medium-complexity analytics

   #### 3. yolov8m

   At `9.5 FPS`, `yolov8m` is closer to a lower-frame-rate intelligent analysis mode.

   It is better suited for:

   - Event-triggered analytics
   - Low-frame-rate inspection workflows
   - Offline review or non-continuous inference

   If the goal is full-frame-rate single-stream real-time detection, `yolov8m` is not the best default choice.

   ### 7.3 Objective Conclusion for Security Applications

   Based on the full benchmark results, the performance of RK3576 in the security domain can be summarized as follows:

   1. Video processing is strong, AI inference is medium-to-strong, and the overall balance is good for an edge SoC
   2. At common security resolutions, video encode/decode capability is clearly stronger than the inference bottleneck of light-to-medium models
   3. For most security projects, the practical system bottleneck is more likely to come from model complexity and concurrent workloads than from the base video pipeline itself

   More specifically:

   - For single-stream real-time intelligent detection, `RK3576 + yolov8n` is a very practical combination
   - For scenarios that need somewhat higher detection accuracy, `yolov8s` is feasible, but frame skipping or a reduced real-time target is recommended
   - For workloads with heavy JPEG / MJPEG input, snapshot streams, or image-based preprocessing, RK3576 provides clear engineering value
   - For `4k` video ingest combined with lightweight real-time analytics, RK3576 has a solid deployment foundation
   - For `8k + H264/H265 real-time encoding + heavy model real-time detection`, the full system budget must be evaluated very carefully, and this should not be treated as the default baseline

   Overall, RK3576 is well suited for:

   - Lightweight edge AI boxes
   - Intelligent NVR / analytics gateways
   - Single-stream or low-channel-count real-time detection terminals
   - Front-end devices focused on video ingest, snapshot handling, and basic object detection

   ## 8. Recommended Deployment Strategy

   For real-world security projects, the following strategy is recommended:

   1. Use `yolov8n` as the default model
   2. Treat `1080p / 2k` as the primary working resolution range for edge real-time analytics
   3. Use `4k` mainly as a high-quality video input, while pairing AI with scaling or frame skipping
   4. Use `8k` mainly for capability demonstration or special high-end validation, not as a default real-time AI baseline

   ## 9. Suggested Next Steps

   To make the report more complete, the next useful step is to add multi-stream concurrency data, for example:

   1. `2 x 1080p MJPG decode`
   2. `4 x 1080p MJPG decode`
   3. `1 x 1080p decode + 1 x yolov8n`
   4. `1 x 4k decode + 1 x yolov8n`

   That would move the evaluation from single-module capability to realistic security workload capability.
