Seeed Studio2026-11-12

Raspberry Pi 5 vs RK3588: Reproducible 4K60 HEVC Decode Benchmark

Compare Raspberry Pi 5 stateless V4L2 hardware decoding with Rockchip MPP on RK3588 using the same verified 4K60 HEVC source, unpaced throughput, and paced two- and four-stream tests.

BenchmarkRaspberry Pi 5RK3588VPUHEVCGStreamerGitHub

Watch on YouTube · Open the 4K60 HEVC decode report · Source repository

This project compares the Raspberry Pi 5 v4l2slh265dec stateless V4L2 path with the RK3588 mppvideodec path. Both devices decode the same verified HEVC Main, 3840×2160, 60 fps, 8-bit 4:2:0 source and deliver decoded frames to a GStreamer appsink.

Measured results

TestRaspberry Pi 5RK3588
Unpaced single-stream throughput, three-run median164.90 fps455.65 fps
Paced 2×4K60 for 60 secondsPASS, zero late framesPASS, zero late frames
Paced 4×4K60 challengeReal-time FAIL at 10 secondsPASS at 60 seconds, 14,400/14,400 frames on time

RK3588 delivered about 2.76 times the unpaced single-stream throughput of Raspberry Pi 5 in this test. The paced tests show that both devices sustained two simultaneous 4K60 streams for 60 seconds, while only RK3588 completed the published four-stream challenge.

Test method

The benchmark uses a 5-second closed-GOP source with no B-frames. Its published SHA-256 is:

text
743afe788b81814550f9ac2677906aecc03a5b9c8572e68996d572ff3f9de864

The strict paced benchmark requires normal end-of-stream, exact agreement among planned, input, decoded, and delivered frame counts, no late deliveries, and no timestamp or duplicate errors. A frame is late when it reaches appsink more than 100 ms after its scheduled due time.

The measurement covers decoded frames delivered to appsink. It does not validate HDMI presentation timing, pixel-perfect output, power consumption, thermals, or 30-minute stability.

Reproduce the benchmark

Requirements

  • Linux, Python 3, Python GI bindings, and GStreamer 1.0
  • ffprobe, dmesg, findmnt, and flock
  • Raspberry Pi 5: a working v4l2slh265dec plugin
  • RK3588: working Rockchip MPP drivers and the mppvideodec plugin
  • Access to the video/render devices and permission to read the kernel log

Check the relevant decoder before running a measurement:

bash
gst-inspect-1.0 v4l2slh265dec  # Raspberry Pi 5
gst-inspect-1.0 mppvideodec    # RK3588

Get the pinned source

Run the benchmark from a separate checkout on each device. This revision matches the content reviewed for this page:

bash
git clone https://github.com/xinjiechen727/raspberrypi-rockchip_benchmark_lab.git
cd raspberrypi-rockchip_benchmark_lab
git checkout da5f78fbd6d167b61f33d533ada84c6d3bb04c70
cd decode

Source media is not committed. Follow decode/README.md to prepare source-4k60.mp4, then stop if its SHA-256 differs from the published value.

Run unpaced throughput

On Raspberry Pi 5:

bash
python3 demo_throughput.py --source ./source-4k60.mp4 --decoder v4l2slh265dec --frames 3600 --repeats 1 --json-out throughput-pi5.json

On RK3588:

bash
python3 demo_throughput.py --source ./source-4k60.mp4 --decoder mppvideodec --frames 3600 --repeats 1 --json-out throughput-rk3588.json

Run the paced multi-stream tests

Use the device's decoder name and a unique output directory. For the same-load 2×4K60 comparison:

bash
# Raspberry Pi 5
python3 demo_parallel.py --source ./source-4k60.mp4 --decoder v4l2slh265dec --streams 2 --seconds 60 --repeats 1 --out /dev/shm/pi5-2x4k60-$(date +%s%N)

# RK3588
python3 demo_parallel.py --source ./source-4k60.mp4 --decoder mppvideodec --streams 2 --seconds 60 --repeats 1 --out /dev/shm/rk3588-2x4k60-$(date +%s%N)

The published four-stream challenge used 10 seconds on Pi 5 as an intentionally short overload demonstration and 60 seconds on RK3588. See the pinned decode/README.md for those commands, optional display playback, output files, and known warnings.

The measurements were made with 16 GB devices. Product availability, pricing, operating-system images, and bundled accessories can change; check the product pages before ordering.

Limits and source notes

The RK3588 MPP run emitted recurring HEVC SEI parse warnings and sometimes client 12 driver is not ready!, while still delivering every expected frame in the published runs. Preserve these messages during reproduction and evaluate them together with the frame accounting; pixel-level validation remains outside this benchmark.

For the complete methodology and interactive presentation, use the decode README and 4K60 HEVC decode report.