GNOME Bugzilla – Bug 721077
avviddec: Leaking buffers if default allocation is used
Last modified: 2014-02-16 09:25:39 UTC
Created attachment 264896 [details] totem-3.10.1_valgrind_h264.log.xz Both totem 3.10.0 and 3.10.1 use up all memory when playing h264 or xvid videos on my system. The same files play all right using gst-launch-1.0. Valgrind log attached. This was originally reported at https://bugs.gentoo.org/show_bug.cgi?id=494282
Found this in Mageia 4 Cauldron as well.
Same here on Mageia 4 beta: the totem process was killed by the kernel after about one minute: [ 615.277605] Out of memory: Kill process 828 (totem) score 801 or sacrifice child [ 615.277609] Killed process 828 (totem) total-vm:8432620kB, anon-rss:2766368kB, file-rss:14472kB
FYI upgrading all gstreamer packages to 1.2.2 does not fix this.
(In reply to comment #0) > Created an attachment (id=264896) [details] > totem-3.10.1_valgrind_h264.log.xz > > Both totem 3.10.0 and 3.10.1 use up all memory when playing h264 or xvid videos > on my system. The same files play all right using gst-launch-1.0. Valgrind log > attached. Does this also happen when you use cluttersink? gst-launch-1.0 playbin uri=file:///path/to/video videosink=cluttersink What video card do you use? If it's an intel one, do you have the GStreamer vaapi plugin installed?
(In reply to comment #4) > (In reply to comment #0) > > Created an attachment (id=264896) [details] [details] > > totem-3.10.1_valgrind_h264.log.xz > > > > Both totem 3.10.0 and 3.10.1 use up all memory when playing h264 or xvid videos > > on my system. The same files play all right using gst-launch-1.0. Valgrind log > > attached. > > Does this also happen when you use cluttersink? > gst-launch-1.0 playbin uri=file:///path/to/video videosink=cluttersink There is no excessive memory usage when playing the files using gst-launch-1.0. > > What video card do you use? If it's an intel one, do you have the GStreamer > vaapi plugin installed? I use nvidia cards.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #0) > > > Created an attachment (id=264896) [details] [details] [details] > > > totem-3.10.1_valgrind_h264.log.xz > > > > > > Both totem 3.10.0 and 3.10.1 use up all memory when playing h264 or xvid videos > > > on my system. The same files play all right using gst-launch-1.0. Valgrind log > > > attached. > > > > Does this also happen when you use cluttersink? > > gst-launch-1.0 playbin uri=file:///path/to/video videosink=cluttersink > > There is no excessive memory usage when playing the files using gst-launch-1.0. Even with that videosink selected? I doubt it... > > What video card do you use? If it's an intel one, do you have the GStreamer > > vaapi plugin installed? > > I use nvidia cards. The valgrind trace points to a problem with one of GStreamer, libav, clutter-gst, or even cogl not freeing the decoded video. Reassigning to GStreamer for now. ==26738== 252,216,187 (227,800 direct, 251,988,387 indirect) bytes in 335 blocks are definitely lost in loss record 29,806 of 29,807 ==26738== at 0x4C2C840: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26738== by 0x65A08B0: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==26738== by 0x65B5A02: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==26738== by 0x65B5F55: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.3800.2) ==26738== by 0x39FF9229: gst_ffmpegviddec_get_buffer (gstavviddec.c:535) ==26738== by 0x3A924AAB: ff_get_buffer (utils.c:831) ==26738== by 0x3A8A1DD0: ff_thread_decode_frame (pthread.c:569) ==26738== by 0x3A92607E: avcodec_decode_video2 (utils.c:2059) ==26738== by 0x39FF7381: gst_ffmpegviddec_video_frame (gstavviddec.c:1169) ==26738== by 0x39FF7E1A: gst_ffmpegviddec_frame (gstavviddec.c:1296) ==26738== by 0x39FF842E: gst_ffmpegviddec_handle_frame (gstavviddec.c:1412) ==26738== by 0x7807A0F: gst_video_decoder_decode_frame (gstvideodecoder.c:2760) ==26738== ==26738== 802,524,222 bytes in 258 blocks are possibly lost in loss record 29,807 of 29,807 ==26738== at 0x4C2C840: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26738== by 0x65A08B0: g_malloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==26738== by 0x65B5A02: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3800.2) ==26738== by 0x7C74670: _sysmem_new_block (gstallocator.c:415) ==26738== by 0x7C7E655: gst_buffer_new_allocate (gstbuffer.c:668) ==26738== by 0x78063AA: video_buffer_pool_alloc (gstvideopool.c:195) ==26738== by 0x7C818F8: do_alloc_buffer.constprop.2 (gstbufferpool.c:272) ==26738== by 0x7C81BF6: default_acquire_buffer (gstbufferpool.c:995) ==26738== by 0x7C83075: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1099) ==26738== by 0x780F50E: gst_video_decoder_allocate_output_frame (gstvideodecoder.c:3262) ==26738== by 0x39FF7AFE: gst_ffmpegviddec_video_frame (gstavviddec.c:1036) ==26738== by 0x39FF7E1A: gst_ffmpegviddec_frame (gstavviddec.c:1296)
That's probably a duplicate of bug #693772. Does it still happen with GStreamer 1.2.2 and gst-libav 1.2.2?
(In reply to comment #6) > > > Does this also happen when you use cluttersink? > > > gst-launch-1.0 playbin uri=file:///path/to/video videosink=cluttersink > > > > There is no excessive memory usage when playing the files using gst-launch-1.0. > > Even with that videosink selected? I doubt it... You are right! There's a typo in the command you gave (videosink should read video-sink), so in fact I again tested xv instead of clutter. I repeated the test with the correct pipeline and indeed observed excess memory usage. (In reply to comment #7) > That's probably a duplicate of bug #693772. Does it still happen with GStreamer > 1.2.2 and gst-libav 1.2.2? According to comment #3, it is not fixed in gstreamer 1.2.2. Will try on my system and report back.
I can reproduce it with gst 1.2.2 and the command line gst-launch-1.0 playbin uri=file:///some-file.mkv video-sink=cluttersink
(In reply to comment #8) > (In reply to comment #6) > > > > Does this also happen when you use cluttersink? > > > > gst-launch-1.0 playbin uri=file:///path/to/video videosink=cluttersink > > > > > > There is no excessive memory usage when playing the files using gst-launch-1.0. > > > > Even with that videosink selected? I doubt it... > > You are right! There's a typo in the command you gave (videosink should read > video-sink), so in fact I again tested xv instead of clutter. I repeated the > test with the correct pipeline and indeed observed excess memory usage. My mistake. > (In reply to comment #7) > > That's probably a duplicate of bug #693772. Does it still happen with GStreamer > > 1.2.2 and gst-libav 1.2.2? > > According to comment #3, it is not fixed in gstreamer 1.2.2. Will try on my > system and report back. You need gst-libav 1.2.2 as well.
(In reply to comment #10) > You need gst-libav 1.2.2 as well. I do have it, I have updated all gstreamer components to 1.2.2.
Created attachment 265796 [details] gst-launch-1.0_cluttersink_valgrind_h264.log Upgrading to gstreamer-1.2.2 and gst-plugins-libav-1.2.2 did not fix it. Valgrind log for gst-launch-1.0 playbin uri=file:///path/to/video.mp4 video-sink=cluttersink attached.
I hit this one too yesterday. I am using a Lenovo Laptop with Intel graphics. Tired the suggested gst-launch pipeline and I can see the memory usage tick up in 'top'. I am using Git master of GStreamer from earlier this week.
Also using Totem 3.10.1
Ok, did some testing GStreamer 1.2.2 and libav 1.2.2 works fine for me using the included libav library. Switching to libav 1.3.x from git master triggers the issue. Building avplay from the gst-libav sources and trying to play does not trigger the bug.
My gst-libav was built against ffmpeg 2.0.2 and has the bug.
(In reply to comment #16) > My gst-libav was built against ffmpeg 2.0.2 and has the bug. How did you even build gst-libav 1.2.2 against ffmpeg 2? Did you backport the libav 10 related changes?
(In reply to comment #17) The Mageia package has patches for this: http://svnweb.mageia.org/packages/cauldron/gstreamer1.0-libav/current/SOURCES/
Would've been good to mention that in the bug report, so this is not 1.2.2 but 1.2.2 with some random patches built against ffmpeg 2... so basically almost like git master. But that confirms at least that it's something related to the switch to new libav/ffmpeg that somehow causes memory leaks in the way we use libav/ffmpeg that did not cause memory leaks before.
commit 81cef109e20cbce285bacaf673597aef57fc30f3 Author: Wim Taymans <wtaymans@redhat.com> Date: Fri Jan 10 17:18:53 2014 +0100 avviddec: release buffers when not direct rendering New libav will not call the release_buffer callback anymore when avcodec_default_get_buffer() is called from get_buffer. Releasing of the memory in a picture should now be done by registering a callback to the avbuffer objects in the picture. There is some compatibility code to wrap the memory we provide in get_buffer in avbuffer with a callback to release_buffer but that is not done when avcodec_default_get_buffer() is called. Work around this by adding a dummy avbuffer object to the picture that will release the frame. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721077
*** Bug 708335 has been marked as a duplicate of this bug. ***
The backport seems to have broke the build http://arracacha.collabora.co.uk:8080/job/GStreamer-1.2/987/console
I applied the patch from comment 20 to gst-libav-1.2.2 and it fixed the memleak for me. Finally, I can use totem again - thanks a lot for the quick fix!
From the 1.2.3 ChangeLog looks like the patch was reverted: 2014-01-11 19:19:24 +0000 Tim-Philipp Müller <tim@centricular.com> * ext/libav/gstavviddec.c: Revert "avviddec: release buffers when not direct rendering" This reverts commit fcf09aff3272a12b1f91168a856637f146ced113. This broke the build. In theory the problem might occur with libav 9 too, but it seems in practice it doesn't, unless you link against ffmpeg 2.x, but then you're on your own anyway. https://bugzilla.gnome.org/show_bug.cgi?id=721077 Does this mean we are forced to use libav instead of ffmpeg?
Nobody forces you to anything, you have the code and can change it to work fine with ffmpeg ;) Longer story is, that this patch was reverted from the 1.2 branch because libav v9 (as used in 1.2) does not have the API that is required by this patch. And also is in general not compatible with the libav v10 API. To have 1.2 working with ffmpeg you needed custom patches in the past anyway, and just having an additional one (this here) does not make much of a difference. With gst-libav 1.3/1.4 we will support the libav v10 API (only), and that should be compatible with the latest ffmpeg API. No patches required then anymore. Same goes if you build gst-libav from current git master.
OK, thanks for the explanation :)