memory leak with vaapi decode since ffmpeg_vaapi: Convert to use hw_frames_ctx only - ffmpeg-user - lists.ffmpeg.org

newer
Float formatting in drawtext

memory leak with vaapi decode since ffmpeg_vaapi: Convert to use hw_frames_ctx only

older
how to pass output of lavfi to xv?

Andy Furniss

26 May 2017 26 May '17

8:44 p.m.

First reported on mpv github issues. Since below ffmpeg -hwaccel vaapi -i sommething-h264 -f null - will steadily eat memory. commit 542a65d0b33abf81e5087ec9142bb11a54f23cde Author: Mark Thompson <sw@jkqxz.net> Date: Sun Jul 31 22:51:45 2016 +0100 ffmpeg_vaapi: Convert to use hw_frames_ctx only Most of the functionality here has moved into lavc. (cherry picked from commit 3e8651a7ccd8e89cc2f162cf614a3c9f7f4d9fcf)

Show replies by date

Andy Furniss

28 May 28 May

11:22 a.m.

Andy Furniss wrote:

First reported on mpv github issues.

Since below ffmpeg -hwaccel vaapi -i sommething-h264 -f null -

will steadily eat memory.

commit 542a65d0b33abf81e5087ec9142bb11a54f23cde Author: Mark Thompson <sw@jkqxz.net> Date: Sun Jul 31 22:51:45 2016 +0100

ffmpeg_vaapi: Convert to use hw_frames_ctx only

Most of the functionality here has moved into lavc.

(cherry picked from commit 3e8651a7ccd8e89cc2f162cf614a3c9f7f4d9fcf)

valgrind 10k frames bluray valgrind --leak-check=full --fullpath-after=/mnt/sdb1/Gits /mnt/sdb1/Gits/ffmpeg/ffmpeg_g -hwaccel vaapi -i 00023.m2ts -vframes 10000 -an -sn -f null - ==13089== Memcheck, a memory error detector ==13089== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==13089== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==13089== Command: /mnt/sdb1/Gits/ffmpeg/ffmpeg_g -hwaccel vaapi -i 00023.m2ts -vframes 10000 -an -sn -f null - ==13089== ffmpeg version N-86289-g6c3a63f Copyright (c) 2000-2017 the FFmpeg developers built with gcc 5.3.0 (GCC) configuration: --prefix=/usr --disable-doc --enable-gpl --enable-libvpx --enable-libx265 --enable-libx264 --enable-gnutls libavutil 55. 63.100 / 55. 63.100 libavcodec 57. 96.101 / 57. 96.101 libavformat 57. 72.101 / 57. 72.101 libavdevice 57. 7.100 / 57. 7.100 libavfilter 6. 90.100 / 6. 90.100 libswscale 4. 7.101 / 4. 7.101 libswresample 2. 8.100 / 2. 8.100 libpostproc 54. 6.100 / 54. 6.100 [mpegts @ 0xb80bc80] start time for stream 10 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 11 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 12 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 13 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 14 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 15 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 16 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 17 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 18 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 19 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 20 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 21 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] start time for stream 22 is not set in estimate_timings_from_pts [mpegts @ 0xb80bc80] Could not find codec parameters for stream 10 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 11 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 12 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 13 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 14 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 15 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 16 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 17 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 18 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 19 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 20 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 21 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0xb80bc80] Could not find codec parameters for stream 22 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options Input #0, mpegts, from '00023.m2ts': Duration: 01:37:58.75, start: 11.650667, bitrate: 41481 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), s32p (24 bit) Stream #0:2[0x1101]: Audio: dts (DTS) ([130][0][0][0] / 0x0082), 48000 Hz, 5.1(side), fltp, 768 kb/s Stream #0:3[0x1102]: Audio: dts (DTS) ([130][0][0][0] / 0x0082), 48000 Hz, 5.1(side), fltp, 768 kb/s Stream #0:4[0x1103]: Audio: dts (DTS) ([130][0][0][0] / 0x0082), 48000 Hz, 5.1(side), fltp, 768 kb/s Stream #0:5[0x1104]: Audio: dts (DTS) ([130][0][0][0] / 0x0082), 48000 Hz, 5.1(side), fltp, 768 kb/s Stream #0:6[0x1105]: Audio: dts (DTS) ([130][0][0][0] / 0x0082), 48000 Hz, 5.1(side), fltp, 768 kb/s Stream #0:7[0x1106]: Audio: dts (DTS) ([130][0][0][0] / 0x0082), 48000 Hz, 5.1(side), fltp, 768 kb/s Stream #0:8[0x1107]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:9[0x1108]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 192 kb/s Stream #0:10[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:11[0x1201]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:12[0x1202]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:13[0x1203]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:14[0x1204]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:15[0x1205]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:16[0x1206]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:17[0x1207]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:18[0x1208]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:19[0x1209]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:20[0x120a]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:21[0x120b]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream #0:22[0x120c]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090) Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help libva info: VA-API version 0.40.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'radeonsi' libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_0_40 libva info: va_openDriver() returns 0 Output #0, null, to 'pipe:':ze=N/A time=-577014:32:22.77 bitrate=N/A speed=N/A Metadata: encoder : Lavf57.72.101 Stream #0:0: Video: wrapped_avframe, nv12, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc Metadata: encoder : Lavc57.96.101 wrapped_avframe frame=10000 fps= 24 q=-0.0 Lsize=N/A time=00:06:57.08 bitrate=N/A speed=0.998x video:5156kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown ==13089== ==13089== HEAP SUMMARY: ==13089== in use at exit: 1,641,516,251 bytes in 201,131 blocks ==13089== total heap usage: 2,075,668 allocs, 1,874,537 frees, 68,823,339,225 bytes allocated ==13089== ==13089== 368 bytes in 1 blocks are possibly lost in loss record 908 of 932 ==13089== at 0x4C28B06: malloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) ==13089== by 0xFBED2DE: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:56) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2C21: ff_vaapi_decode_make_param_buffer (/ffmpeg/libavcodec/vaapi_decode.c:40) ==13089== by 0xAFDA07: vaapi_h264_start_frame (/ffmpeg/libavcodec/vaapi_h264.c:286) ==13089== by 0x853E0B: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:690) ==13089== by 0x853E0B: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 22,968 bytes in 11 blocks are possibly lost in loss record 922 of 932 ==13089== at 0x4C28B06: malloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) ==13089== by 0xFBED2DE: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:56) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2D46: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:86) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 3,042,432 (800,640 direct, 2,241,792 indirect) bytes in 10,008 blocks are definitely lost in loss record 925 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2C21: ff_vaapi_decode_make_param_buffer (/ffmpeg/libavcodec/vaapi_decode.c:40) ==13089== by 0xAFDBA9: vaapi_h264_start_frame (/ffmpeg/libavcodec/vaapi_h264.c:299) ==13089== by 0x853E0B: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:690) ==13089== by 0x853E0B: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 4,483,216 (800,640 direct, 3,682,576 indirect) bytes in 10,008 blocks are definitely lost in loss record 927 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2C21: ff_vaapi_decode_make_param_buffer (/ffmpeg/libavcodec/vaapi_decode.c:40) ==13089== by 0xAFDA07: vaapi_h264_start_frame (/ffmpeg/libavcodec/vaapi_h264.c:286) ==13089== by 0x853E0B: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:690) ==13089== by 0x853E0B: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 6,872,207 bytes in 150 blocks are possibly lost in loss record 928 of 932 ==13089== at 0x4C28B06: malloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) ==13089== by 0xFBED2DE: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:56) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2DA5: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:100) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 86,766,408 (3,202,560 direct, 83,563,848 indirect) bytes in 40,032 blocks are definitely lost in loss record 930 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2D46: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:86) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 1,540,168,859 (3,202,560 direct, 1,536,966,299 indirect) bytes in 40,032 blocks are definitely lost in loss record 932 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2DA5: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:100) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== LEAK SUMMARY: ==13089== definitely lost: 8,006,400 bytes in 100,080 blocks ==13089== indirectly lost: 1,626,454,515 bytes in 99,918 blocks ==13089== possibly lost: 6,895,543 bytes in 162 blocks ==13089== still reachable: 159,793 bytes in 971 blocks ==13089== suppressed: 0 bytes in 0 blocks ==13089== Reachable blocks (those to which a pointer was found) are not shown. ==13089== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==13089== ==13089== For counts of detected and suppressed errors, rerun with: -v ==13089== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)

Mark Thompson

1:39 p.m.

On 28/05/17 12:22, Andy Furniss wrote:

==13089== HEAP SUMMARY: ==13089== in use at exit: 1,641,516,251 bytes in 201,131 blocks ==13089== total heap usage: 2,075,668 allocs, 1,874,537 frees, 68,823,339,225 bytes allocated ==13089== ==13089== 368 bytes in 1 blocks are possibly lost in loss record 908 of 932 ==13089== at 0x4C28B06: malloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) ==13089== by 0xFBED2DE: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:56) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2C21: ff_vaapi_decode_make_param_buffer (/ffmpeg/libavcodec/vaapi_decode.c:40) ==13089== by 0xAFDA07: vaapi_h264_start_frame (/ffmpeg/libavcodec/vaapi_h264.c:286) ==13089== by 0x853E0B: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:690) ==13089== by 0x853E0B: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 22,968 bytes in 11 blocks are possibly lost in loss record 922 of 932 ==13089== at 0x4C28B06: malloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) ==13089== by 0xFBED2DE: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:56) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2D46: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:86) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 3,042,432 (800,640 direct, 2,241,792 indirect) bytes in 10,008 blocks are definitely lost in loss record 925 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2C21: ff_vaapi_decode_make_param_buffer (/ffmpeg/libavcodec/vaapi_decode.c:40) ==13089== by 0xAFDBA9: vaapi_h264_start_frame (/ffmpeg/libavcodec/vaapi_h264.c:299) ==13089== by 0x853E0B: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:690) ==13089== by 0x853E0B: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 4,483,216 (800,640 direct, 3,682,576 indirect) bytes in 10,008 blocks are definitely lost in loss record 927 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2C21: ff_vaapi_decode_make_param_buffer (/ffmpeg/libavcodec/vaapi_decode.c:40) ==13089== by 0xAFDA07: vaapi_h264_start_frame (/ffmpeg/libavcodec/vaapi_h264.c:286) ==13089== by 0x853E0B: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:690) ==13089== by 0x853E0B: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 6,872,207 bytes in 150 blocks are possibly lost in loss record 928 of 932 ==13089== at 0x4C28B06: malloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:299) ==13089== by 0xFBED2DE: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:56) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2DA5: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:100) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 86,766,408 (3,202,560 direct, 83,563,848 indirect) bytes in 40,032 blocks are definitely lost in loss record 930 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2D46: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:86) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== 1,540,168,859 (3,202,560 direct, 1,536,966,299 indirect) bytes in 40,032 blocks are definitely lost in loss record 932 of 932 ==13089== at 0x4C2A898: calloc (/home/andy/Src2016/valgrind-3.12.0/coregrind/m_replacemalloc/vg_replace_malloc.c:711) ==13089== by 0xFBED2C0: vlVaCreateBuffer (/mesa/src/gallium/state_trackers/va/buffer.c:49) ==13089== by 0x603BB82: vaCreateBuffer (/libva/va/va.c:1116) ==13089== by 0xED2DA5: ff_vaapi_decode_make_slice_buffer (/ffmpeg/libavcodec/vaapi_decode.c:100) ==13089== by 0xAFCCBB: vaapi_h264_decode_slice (/ffmpeg/libavcodec/vaapi_h264.c:380) ==13089== by 0x853CCD: decode_nal_units (/ffmpeg/libavcodec/h264dec.c:703) ==13089== by 0x853CCD: h264_decode_frame (/ffmpeg/libavcodec/h264dec.c:1008) ==13089== by 0xA0A54F: frame_worker_thread (/ffmpeg/libavcodec/pthread_frame.c:199) ==13089== by 0x8D12433: start_thread (in /lib/libpthread-2.22.so) ==13089== by 0x901106C: clone (in /lib/libc-2.22.so) ==13089== ==13089== LEAK SUMMARY: ==13089== definitely lost: 8,006,400 bytes in 100,080 blocks ==13089== indirectly lost: 1,626,454,515 bytes in 99,918 blocks ==13089== possibly lost: 6,895,543 bytes in 162 blocks ==13089== still reachable: 159,793 bytes in 971 blocks ==13089== suppressed: 0 bytes in 0 blocks ==13089== Reachable blocks (those to which a pointer was found) are not shown. ==13089== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==13089== ==13089== For counts of detected and suppressed errors, rerun with: -v ==13089== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)

Hmph, looks like the parameter buffer confusion strikes again. The original VAAPI specification contained the following functions: """ /** * After this call, the buffer is deleted and this buffer_id is no longer valid * Only call this if the buffer is not going to be passed to vaRenderBuffer */ VAStatus vaDestroyBuffer ( ... /** * Send decode buffers to the server. * Buffers are automatically destroyed afterwards */ VAStatus vaRenderPicture ( """ The newer lavc implementation follows this, and does not call vaDestroyBuffer() on buffers passed to vaRenderPicture(). Not doing this would cause random crashes in multithreaded programs, because another buffer with the same ID could be created between the two calls. However, the Intel implementation never actually followed the specification - it leaked the buffers passed to vaRenderPicture(). So, a special driver quirk was added to detect that driver and additionally destroy the buffers in that case: <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4926fa9a4aa03f3b751f52e900b9efb87fea0591>. This restored same behaviour as old lavc with the Intel driver without breaking other implementations. That worked for a bit. Unfortunately, Intel got tired of people complaining that their driver was broken. Rather than fixing it, they decided to change the specification: <https://github.com/01org/libva/commit/3eb038aa13bdd785808286c0a4995bd7a1ef07e9> (this is an ABI and API break, and the SONAME was not changed). Thus we have the state now: VAAPI < 0.40: A) Destroy buffers: wrong, will crash in multithreaded programs. B) Don't destroy buffers: correct, driver quirk restores behaviour for Intel. VAAPI >= 0.40: A) Destroy buffers: correct, but may crash old drivers which haven't been updated (not detectable, because the library allows loading old drivers without telling the user). B) Don't destroy buffers: wrong, driver quirk restores correct behaviour for Intel, others may leak memory. lavc currently chooses (B) in both cases on the grounds that leaking memory is preferable to crashing randomly. There is some thought of switching to (A) for VAAPI >= 0.40, but given that we can't detect the version at runtime and the libraries consider everything to be compatible this seems dangerous. For Mesa, I feel like I remember it having a correct < 0.40 implementation, but looking again it doesn't seem to and there isn't any obvious change (maybe I am just wrong). Do you know if this changed? Adding the driver quirk like the Intel driver is probably the right thing to do if it has always been like that, if it hasn't then we need more magic to be able to distinguish versions to prevent older ones from crashing. Thanks, - Mark

Andy Furniss

10:32 p.m.

Mark Thompson wrote:

Hmph, looks like the parameter buffer confusion strikes again.

The original VAAPI specification contained the following functions:

""" /** * After this call, the buffer is deleted and this buffer_id is no longer valid * Only call this if the buffer is not going to be passed to vaRenderBuffer */ VAStatus vaDestroyBuffer ( ... /** * Send decode buffers to the server. * Buffers are automatically destroyed afterwards */ VAStatus vaRenderPicture ( """

The newer lavc implementation follows this, and does not call vaDestroyBuffer() on buffers passed to vaRenderPicture(). Not doing this would cause random crashes in multithreaded programs, because another buffer with the same ID could be created between the two calls.

However, the Intel implementation never actually followed the specification - it leaked the buffers passed to vaRenderPicture(). So, a special driver quirk was added to detect that driver and additionally destroy the buffers in that case: <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4926fa9a4aa03f3b751f52e900b9efb87fea0591>. This restored same behaviour as old lavc with the Intel driver without breaking other implementations.

That worked for a bit.

Unfortunately, Intel got tired of people complaining that their driver was broken. Rather than fixing it, they decided to change the specification: <https://github.com/01org/libva/commit/3eb038aa13bdd785808286c0a4995bd7a1ef07e9> (this is an ABI and API break, and the SONAME was not changed).

Thus we have the state now:

VAAPI < 0.40: A) Destroy buffers: wrong, will crash in multithreaded programs. B) Don't destroy buffers: correct, driver quirk restores behaviour for Intel.

VAAPI >= 0.40: A) Destroy buffers: correct, but may crash old drivers which haven't been updated (not detectable, because the library allows loading old drivers without telling the user). B) Don't destroy buffers: wrong, driver quirk restores correct behaviour for Intel, others may leak memory.

lavc currently chooses (B) in both cases on the grounds that leaking memory is preferable to crashing randomly. There is some thought of switching to (A) for VAAPI >= 0.40, but given that we can't detect the version at runtime and the libraries consider everything to be compatible this seems dangerous.

For Mesa, I feel like I remember it having a correct < 0.40 implementation, but looking again it doesn't seem to and there isn't any obvious change (maybe I am just wrong). Do you know if this changed? Adding the driver quirk like the Intel driver is probably the right thing to do if it has always been like that, if it hasn't then we need more magic to be able to distinguish versions to prevent older ones from crashing.

Thanks for the explanation. I haven't seen anything change in mesa and st/va search on cgit doesn't come up with anything obvious. In your github link there is a link to a bug that states gstreamer always released, and testing it doesn't leak. Since AMD devs develop with that, they wouldn't have seen this, or, I guess, needed to implement in driver.

Carl Eugen Hoyos

11:42 a.m.

2017-05-26 22:44 GMT+02:00 Andy Furniss <adf.lists@gmail.com>:

First reported on mpv github issues.

Since below ffmpeg -hwaccel vaapi -i sommething-h264 -f null -

will steadily eat memory.

My only suggestion is to open a ticket on trac with the valgrind output, feel free to also test avconv. Carl Eugen

3390

Age (days ago)

3392

Last active (days ago)

Download

4 comments

3 participants

tags

participants (3)

Andy Furniss
Carl Eugen Hoyos
Mark Thompson