On 9/11/2025 4:59 PM, Marco Oman via ffmpeg-devel wrote:
> Hi,
> I compiled the example hw_decode.c on Ubuntu 24.04 with ffmpeg 7.0 compiled with --enable-cuda-nvcc. Then lauched the decoding over a small mp4 file with a video encoded H264 and checked the whole thing with valgrind with the following command:

Please try latest master, not some old version.

> valgrind --leak-check=yes --log-file=hw_decode.log ./hw_decode cuda a.mp4 a.raw
> 
> The resulting log is quite large, suggesting that there is a memory leak . Anyone found somehting similar?
> Is the leak real or valgrind is giving a false positive?
> 
> Here there are two sections from hw_decode.log
> 
> ==1495328== 48 bytes in 1 blocks are definitely lost in loss record 24 of 118
> ==1495328==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==1495328==    by 0x7029E01: pthread_cond_broadcast@GLIBC_2.2.5 (old_pthread_cond_broadcast.c:33)
> ==1495328==    by 0x22095866: ???
> ==1495328==    by 0x22064373: ???
> ==1495328==    by 0x2201800E: ???
> ==1495328==    by 0x4E3CC65: nvdec_test_capabilities (nvdec.c:127)
> ==1495328==    by 0x4E3CC65: nvdec_decoder_create (nvdec.c:218)
> ==1495328==    by 0x4E3CC65: ff_nvdec_decode_init (nvdec.c:404)
> ==1495328==    by 0x4ADDBA3: hwaccel_init (decode.c:1193)
> ==1495328==    by 0x4ADDBA3: ff_get_format (decode.c:1331)
> ==1495328==    by 0x4BE3B97: get_pixel_format (h264_slice.c:909)
> ==1495328==    by 0x4BE5A87: h264_init_ps (h264_slice.c:1142)
> ==1495328==    by 0x4BE95F7: h264_field_start (h264_slice.c:1393)
> ==1495328==    by 0x4BE95F7: ff_h264_queue_decode_slice (h264_slice.c:2150)
> ==1495328==    by 0x4BEE8C5: decode_nal_units (h264dec.c:656)
> ==1495328==    by 0x4BEE8C5: h264_decode_frame (h264dec.c:1058)
> ==1495328==    by 0x4ADC4C9: decode_simple_internal (decode.c:409)
> ==1495328==    by 0x4ADC4C9: decode_simple_receive_frame (decode.c:579)
> ==1495328==    by 0x4ADC4C9: decode_receive_frame_internal (decode.c:608)
> 
> Plus many more of this kind
> 
> ==1495328== 72 bytes in 1 blocks are possibly lost in loss record 44 of 118
> ==1495328==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==1495328==    by 0xA91E6D9: ??? (in /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20)
> ==1495328==    by 0xA80E7A9: ??? (in /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20)
> ==1495328==    by 0xA7FF82C: ??? (in /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20)
> ==1495328==    by 0xA7CD210: ??? (in /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20)
> ==1495328==    by 0xA81B671: ??? (in /usr/lib/x86_64-linux-gnu/libcuda.so.570.133.20)
> ==1495328==    by 0x5EB4E90: cuda_device_create (hwcontext_cuda.c:446)
> ==1495328==    by 0x5EB177E: av_hwdevice_ctx_create (hwcontext.c:619)
> ==1495328==    by 0x10A5A6: hw_decoder_init (in /home/marco/hw_decode)
> ==1495328==    by 0x10AD66: main (in /home/marco/hw_decode)
> 
These all point into nvidia code, so not much we can do about it if 
they're real.