Add hardware codec support for rkmpp#6182
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
NodudeWasTaken
left a comment
There was a problem hiding this comment.
I have reviewed some of the code.
On another note, is the Rockchip encoder any good?
Then i might consider getting a good Rockchip SBC
| case VideoCodecRK264: | ||
| // For Rockchip, no extra mapping here. If there is no scale filter, | ||
| // leave frames in DRM_PRIME for the encoder. |
There was a problem hiding this comment.
Does the Rockchip decoder change for the format to nv12 so we dont need to enforce it here for full hardware encoding?
There was a problem hiding this comment.
Yes — RKMPP decodes to DRM_PRIME frames with NV12 as sw_pix_fmt, so you don’t need to force format=nv12 in the full-HW path (only when falling back to system memory/non-full-HW).
pkg/ffmpeg/codec_hardware.go
Outdated
| case VideoCodecRK264: | ||
| if !fullhw { | ||
| return VideoFilter(sargs) | ||
| } | ||
| // Rockchip fallback chain for maximum compatibility: | ||
| // RGA scale → system memory → upload → rkmpp encoder. | ||
| // This avoids hwmap(rkrga→rkmpp) failures (-38/-12) seen on some builds. | ||
| template = "scale_rkrga=$value:format=nv12,hwdownload,format=nv12,hwupload" |
There was a problem hiding this comment.
"seen on some builds".
So this bug was fixed? If so you should check which version of ffmpeg this was fixed on.
So we can use the more optimal scale_rkrga
There was a problem hiding this comment.
I'm getting this error on my machine, and I don't have enough machines to test what's wrong, so I'm going with the safest option.
Theoretically, this shouldn't be a problem, but I'm getting the error here.
There was a problem hiding this comment.
I'm getting this error on my machine, and I don't have enough machines to test what's wrong, so I'm going with the safest option. Theoretically, this shouldn't be a problem, but I'm getting the error here.
I fixed the problem, it was a problem with the device tree and kernel of my system.
Alright, we're good to go with zero-copy now. The updated code's been deployed.
pkg/ffmpeg/codec_hardware.go
Outdated
| // BUG: scale_rkrga expects positive sizes. | ||
| isRockchip := codec == VideoCodecRK264 | ||
| return VideoFilter(templateReplaceScale(sargs, template, match, vf, isIntel || isApple || isRockchip)) |
There was a problem hiding this comment.
Checking the source code it does call the scaler, leading me to believe that it does support negative sizes:
https://github.com/nyanmisaka/ffmpeg-rockchip/blob/cc5de845d52265dd25cea3738952d331708c2374/libavfilter/vf_vpp_rkrga.c#L219
pkg/ffmpeg/codec_hardware.go
Outdated
| VideoCodecRK264: | ||
| return 4096, 4096 |
There was a problem hiding this comment.
Compared to intel n100 qsv, the encoding quality is almost the same, but the speed will be much faster! In the case of 4K HEVC 8bit → 1080p H.264 8 Mbps RK3588:77 fps / 1.28× ,rtime 23.34 s Regarding the issue you raised, it's been addressed. |
WithoutPants
left a comment
There was a problem hiding this comment.
I don't have the necessary hardware to test this, but the code looks ok.
Added hardware codec support via rkmpp, tested on the RK3588.
Tested using the following Docker build script and Docker Compose configuration.
docker file
entrypoint.sh
docker compose
The docker image is built on the rk3588 board like this
sudo docker build --platform linux/arm64 -t stash-rkmpp .