Clients arrive with a chip number already chosen, usually because a board they saw online used it. With Rockchip that habit costs money, because the RV and RK families are built for different products: one is a camera with compute attached, the other is a computer with a camera input.
What the RV family is actually for
RV1126 and RV1109 are vision processors. The silicon budget goes into the ISP and the video encoder: three-frame HDR, multi-stage noise reduction, a 14 MP pipeline on the RV1126, hardware H.264/H.265 encoding at 4K on the RV1126 and 5 MP on the RV1109, and an NPU of 2 TOPS and 1.2 TOPS respectively. CPU is a quad or dual Cortex-A7 — enough to run a Linux camera application, not enough to host an app store.
That is the tell: RV is chosen when the product is defined by what the camera sees and what gets sent upstream. IP cameras, video doorbells, pet cameras, machine-vision heads, dash cameras.
What the RK family is actually for
RK3566 and RK3568 are quad Cortex-A55 parts with a Mali-G52 GPU and a 0.8 TOPS NPU; RK3588 is the flagship with four A76 plus four A55, a 6 TOPS NPU, 8K display capability and PCIe 3.0 / SATA 3.0 / USB 3.1 expansion. These are application processors: display pipelines, multi-window UI, Android, storage, networking, and enough NPU to run detection models on a few streams.
RK is chosen when the product is defined by its screen, its app or its interfaces — kiosks, HMIs, NVRs, robots, edge boxes.
The four questions that decide it
Is there a real screen? If the UI is the product, RK. A small status display for an RV product is fine; a touch UI with animation is not an RV job.
Does the product encode video continuously? Continuous encoding is what RV hardware is built around. On RK at the low end, encode capability lags decode, and you will spend CPU you do not have.
Does it run Android, or third-party apps? Only RK. RV projects run Linux and a fixed application.
What is the standby power target? Battery or PoE-budgeted products usually land on RV. RK boards idle higher and need more thermal headroom.
Where teams get this wrong
Two recurring mistakes. Putting a screen-heavy product on RV to save cost, then discovering the GPU-less platform cannot animate the UI the brand designed. And putting a camera-first product on RK3566 to “have room to grow”, then paying for a bigger board, more RAM and a heatsink to do what an RV1126 does on a smaller PCB.
How we settle it before quoting
We write the product’s five hard constraints — screen, encode, OS, interfaces, power — and check them against both families. It takes an hour and usually prevents a board redesign three months later.