RK3399 vs RK3568 for H.264 encoding

I’m deciding between ordering a Rock Pi 4 or a Rock Pi 3A. My main objective is to put the SBC to work with streaming and the most relevant part I’m looking at is H.264 encoding. From the specs, I can’t answer some questions I have, so I hope you can help with them.

  1. Can both GPUs handle H.264 encoding at 720p and 60fps?
  2. I’m looking for high-speed H.264 encoding that must result in ultra-low latency streaming. Which one do you think will give me the lower latency?


Just some thoughts / considerations about your question;
Looks like you want a live encoding with a webcam, right? 720p 60fps is familiar with webcam, i guess.

I have rk3399 with a dual camera (ov4689), although the camera can work at 720p 180fps (according to specification) , the available driver works with 30fps, unless it is modified by a kernel expert. You may face the same problem with imx219, i don’t have one to confirm this is true. There is a post about imx219 with rockpi 4, you may ask him what frame rate is possible.

I have not done any benchmark, rk3568 seems to have a better and faster encoder than rk3399 but latency does not depend only on encoding speed, and rk3399 is a more powerhouse that could influence the final latency results.

If you set it for 720p 30fps it could be possible to do some simple benchmarks and compare.

BTW, Rock 5B will have imx415 (4K@90fps), but again you may face something like this: https://github.com/rockchip-linux/kernel/issues/245
But it is just a matter of time till someone fixes the driver.

Thanks, @avaf. I think I’ll go with the RK339. I’ll then report my results.

Just for the record, i tried to do some simple vpu benchmarks following the cnx article here: https://www.cnx-software.com/2022/05/22/linux-hardware-video-encoding-on-amlogic-a311d2-processor/

I ran several times the command to cache the input file, running from SD CARD.

Original file: Big_Buck_Bunny_1080_10s_10MB.mp4 - 10484984 bytes
NV12 Input file: Big_Buck_Bunny_1080_10s_10MB.nv12.yuv - 1866240000 bytes

For the timings:

time ./mpi_enc_test -f 0 -t 7 -i Big_Buck_Bunny_1080_10s_10MB.nv12.yuv -o /dev/null -w 1920 -h 1080 -v q

Saving the file:

./mpi_enc_test -f 0 -t 7 -i Big_Buck_Bunny_1080_10s_10MB.nv12.yuv -o enc.h264 -w 1920 -h 1080 -v q

RK3568 - Debian 10

real 0m15.443s
user 0m2.808s
sys 0m4.982s

Output file size when saved: enc.h264 18844493 bytes

RK3399 Debian 10

real 0m28.126s
user 0m2.309s
sys 0m6.219s

Output file size when saved: enc.h264 19714524 bytes

RK3399 - Ubuntu 20.04

real 0m45.088s
user 0m2.339s
sys 0m7.264s

Output file size when saved: enc.h264 18802221 bytes

The odd thing is that Debian is faster than Ubuntu for this command. It should be the other way around.
RK3399 encodes some frames (a few ones) with artifacts, while RK3568 encoded all frames fine.

The enc.h264 frame with artifacts at the bottom (1920x1080):

Thanks, @avaf! How many frames do those video have (trying to have and idea of how many milliseconds one frame take)? The difference between RK3568 and RK3399 is quite high. I was not expecting such a difference.

Yeah, should measure a single encoded frame to be something more precise. But it is just to have an idea.

— RK3568 - DEBIAN 10
encode 601 frames time 11828 ms delay 14 ms fps 50.81 bps 7525239

– RK3568 - Ubuntu 20.04.3
encode 601 frames time 16270 ms delay 14 ms fps 36.94 bps 7525239

The Kernel used on both boards: 4.19.193
SD CARD same maker and specification, but can’t guarantee one is not fake.

I think the worst thing is the frame with some artifacts, maybe someone else try it and share some info.