vpp_rkrga filter causes hang and memory leak when using drm_prime #222

New issue

Closed

opened 2025-12-23 10:36:18 +01:00 by backuprepo · 1 comment

backuprepo commented

2025-12-23 10:36:18 +01:00

Owner

Originally created by @BlackJulySnow on GitHub (Nov 12, 2025).

Summary

When using the vpp_rkrga filter, ffmpeg hangs (no further progress), and memory usage continues to grow. After forcibly terminating with Ctrl+C, the memory is not released.

Environment

Board: Orange Pi 5
OS: Ubuntu 20.04 (arm64)
ffmpeg version: 298d5e7 (built from source)
GCC: 9.4.0
Configuration:

--prefix=/usr/local --enable-gpl --enable-version3 --enable-filter=drawtext
--enable-libharfbuzz --enable-libfreetype --enable-libdrm
--enable-rkmpp --enable-rkrga

Command

Video file

root@orangepi5:~# ffmpeg -y -hwaccel rkmpp -hwaccel_output_format drm_prime -i videoCache/1140774Download_0.mp4 -vf "vpp_rkrga=w=1920:h=1080:format=nv12" -c:v h264_rkmpp -rc_mode VBR -b:v 3M -maxrate 5M -bufsize 12M -profile:v high -r 20 -an videoCache/1140774Download.mp4
ffmpeg version 298d5e7 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.2)
  configuration: --prefix=/usr/local --enable-gpl --enable-version3 --enable-filter=drawtext --enable-libharfbuzz --enable-libfreetype --enable-libdrm --enable-rkmpp --enable-rkrga
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
  libavdevice    60.  3.100 / 60.  3.100
  libavfilter     9. 12.100 /  9. 12.100
  libswscale      7.  5.100 /  7.  5.100
  libswresample   4. 12.100 /  4. 12.100
  libpostproc    57.  3.100 / 57.  3.100
Input #0, mpeg, from 'videoCache/1140774Download_0.mp4':
  Duration: 00:01:04.19, start: 32714.118933, bitrate: 3861 kb/s
  Stream #0:0[0x1e0]: Video: hevc (Main), yuv420p(tv), 3840x2160, 20 fps, 20 tbr, 90k tbn
  Stream #0:1[0x1c0]: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (hevc (hevc_rkmpp) -> h264 (h264_rkmpp))
Press [q] to stop, [?] for help
rga_api version 1.10.4_[1]
Output #0, mp4, to 'videoCache/1140774Download.mp4':
  Metadata:
    encoder         : Lavf60.16.100
  Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), drm_prime(tv, progressive), 1920x1080, q=2-31, 3000 kb/s, 20 fps, 10240 tbn
    Metadata:
      encoder         : Lavc60.31.102 h264_rkmpp
frame= 1164 fps=225 q=22.0 size=   25344kB time=00:00:58.20 bitrate=3567.3kbits/s speed=11.2x

Behavior

The process hangs after several seconds.
Memory usage increases continuously.
Even after pressing Ctrl+C, the memory is not released until reboot.
Example of process state:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2030 root 20 0 582420 38548 11672 S 0.0 1.0 0:03.70 ffmpeg

Expected behavior

The filter should complete processing normally without hanging or leaking memory.

Additional info

rga_api version 1.10.4_[1]
Without the vpp_rkrga filter, encoding works fine.

Originally created by @BlackJulySnow on GitHub (Nov 12, 2025). ### Summary When using the `vpp_rkrga` filter, ffmpeg hangs (no further progress), and memory usage continues to grow. After forcibly terminating with `Ctrl+C`, the memory is not released. ### Environment - Board: Orange Pi 5 - OS: Ubuntu 20.04 (arm64) - ffmpeg version: 298d5e7 (built from source) - GCC: 9.4.0 - Configuration: ``` --prefix=/usr/local --enable-gpl --enable-version3 --enable-filter=drawtext --enable-libharfbuzz --enable-libfreetype --enable-libdrm --enable-rkmpp --enable-rkrga ``` ### Command [Video file](https://drive.google.com/file/d/14ZaAaxtZiY1lizRqVhRLMQmXXHFB0AGa/view?usp=sharing) ``` root@orangepi5:~# ffmpeg -y -hwaccel rkmpp -hwaccel_output_format drm_prime -i videoCache/1140774Download_0.mp4 -vf "vpp_rkrga=w=1920:h=1080:format=nv12" -c:v h264_rkmpp -rc_mode VBR -b:v 3M -maxrate 5M -bufsize 12M -profile:v high -r 20 -an videoCache/1140774Download.mp4 ffmpeg version 298d5e7 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.2) configuration: --prefix=/usr/local --enable-gpl --enable-version3 --enable-filter=drawtext --enable-libharfbuzz --enable-libfreetype --enable-libdrm --enable-rkmpp --enable-rkrga libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat 60. 16.100 / 60. 16.100 libavdevice 60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc 57. 3.100 / 57. 3.100 Input #0, mpeg, from 'videoCache/1140774Download_0.mp4': Duration: 00:01:04.19, start: 32714.118933, bitrate: 3861 kb/s Stream #0:0[0x1e0]: Video: hevc (Main), yuv420p(tv), 3840x2160, 20 fps, 20 tbr, 90k tbn Stream #0:1[0x1c0]: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s Stream mapping: Stream #0:0 -> #0:0 (hevc (hevc_rkmpp) -> h264 (h264_rkmpp)) Press [q] to stop, [?] for help rga_api version 1.10.4_[1] Output #0, mp4, to 'videoCache/1140774Download.mp4': Metadata: encoder : Lavf60.16.100 Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), drm_prime(tv, progressive), 1920x1080, q=2-31, 3000 kb/s, 20 fps, 10240 tbn Metadata: encoder : Lavc60.31.102 h264_rkmpp frame= 1164 fps=225 q=22.0 size= 25344kB time=00:00:58.20 bitrate=3567.3kbits/s speed=11.2x ``` ### Behavior - The process hangs after several seconds. - Memory usage increases continuously. - Even after pressing `Ctrl+C`, the memory is not released until reboot. - Example of process state: ``` PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2030 root 20 0 582420 38548 11672 S 0.0 1.0 0:03.70 ffmpeg ``` ### Expected behavior - The filter should complete processing normally without hanging or leaking memory. ### Additional info - `rga_api version 1.10.4_[1]` - Without the `vpp_rkrga` filter, encoding works fine.

backuprepo

2025-12-23 10:36:18 +01:00

closed this issue
added the
invalid
label

backuprepo commented

2025-12-23 10:36:20 +01:00

Author

Owner

@nyanmisaka commented on GitHub (Nov 12, 2025):

There are thousands of users running the same commands here. If such a significant leak were to occur, I couldn't possibly have missed it immediately.

Check your own kernel version and MPP/RGA kernel driver version; as far as I know, OrangePi almost never updates them.

For reference, this is the latest RK BSP kernel version used by Armbian:

    _             _    _                             __  __ _    _      _
   /_\  _ _ _ __ | |__(_)__ _ _ _ ___ _  _ _ _  ___ / _|/ _(_)__(_)__ _| |
  / _ \| '_| '  \| '_ \ / _` | ' \___| || | ' \/ _ \  _|  _| / _| / _` | |
 /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|   \_,_|_||_\___/_| |_| |_\__|_\__,_|_|

 v25.8.2 for NanoPC T6 running Armbian Linux 6.1.115-vendor-rk35xx

 Packages:     Ubuntu stable (noble)
 IPv4:         (LAN) 192.168.2.122, 192.168.2.131
 Containers:   jellyfin

 Performance:

 Load:         4%                Uptime:       2:53
 Memory usage: 4% of 15.58G
 CPU temp:     38°C              Usage of /:   25% of 233G

 Commands:

 Configuration : armbian-config
 Monitoring    : htop

nyanmisaka@nanopct6:~$ uname -a
Linux nanopct6 6.1.115-vendor-rk35xx #1 SMP Thu Oct 16 07:30:53 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

It is strongly recommended that you switch to it instead of using the outdated version from two years ago, which contains many unknown bugs.

@nyanmisaka commented on GitHub (Nov 12, 2025): There are thousands of users running the same commands here. If such a significant leak were to occur, I couldn't possibly have missed it immediately. Check your own kernel version and MPP/RGA kernel driver version; as far as I know, OrangePi almost never updates them. For reference, this is the latest RK BSP kernel version used by [Armbian](https://www.armbian.com/): ``` _ _ _ __ __ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ ___ _ _ _ _ ___ / _|/ _(_)__(_)__ _| | / _ \| '_| ' \| '_ \ / _` | ' \___| || | ' \/ _ \ _| _| / _| / _` | | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| \_,_|_||_\___/_| |_| |_\__|_\__,_|_| v25.8.2 for NanoPC T6 running Armbian Linux 6.1.115-vendor-rk35xx Packages: Ubuntu stable (noble) IPv4: (LAN) 192.168.2.122, 192.168.2.131 Containers: jellyfin Performance: Load: 4% Uptime: 2:53 Memory usage: 4% of 15.58G CPU temp: 38°C Usage of /: 25% of 233G Commands: Configuration : armbian-config Monitoring : htop nyanmisaka@nanopct6:~$ uname -a Linux nanopct6 6.1.115-vendor-rk35xx #1 SMP Thu Oct 16 07:30:53 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux ``` It is strongly recommended that you switch to it instead of using the outdated version from two years ago, which contains many unknown bugs.