GNOME Bugzilla – Bug 744253
multiqueue: Memory leak with DASH stream
Last modified: 2015-03-15 14:23:24 UTC
Hello, This gst-launch line leaks rapidly: gst-launch-1.0 uridecodebin uri=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-720p-stereo-nodvb.mpd caps="video/x-h264 ; audio/mpeg" ! fakesink sync=true After examination, it turns out that the cause is an internal multiqueue that is steadily increasing its internal limit, apparently because one queue is not linked. Here is an excerpt of log lines that show the leak: gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2507/2508, bytes 6664375/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2508/2508, bytes 6667271/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2508/2509, bytes 6667271/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2509/2509, bytes 6670167/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2509/2510, bytes 6670167/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2510/2510, bytes 6673063/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2510/2511, bytes 6673063/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2511/2511, bytes 6675959/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2511/2512, bytes 6675959/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2512/2512, bytes 6677407/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2512/2513, bytes 6677407/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2513/2513, bytes 6681503/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2513/2514, bytes 6681503/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2514/2514, bytes 6681751/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2514/2515, bytes 6681751/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2515/2515, bytes 6684647/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2515/2516, bytes 6684647/0, time 7680000000/0 gstmultiqueue.c:2230:single_queue_check_full:<multiqueue0> queue 0: visible 2516/2516, bytes 6687543/0, time 7680000000/0 and this shows when it is increased: gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2448 gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2449 gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2450 gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2451 gstmultiqueue.c:2136:single_queue_overrun_cb:<multiqueue0> Queue 1 is not-linked gstmultiqueue.c:2157:single_queue_overrun_cb:<multiqueue0> All other queues are not linked gstmultiqueue.c:2163:single_queue_overrun_cb:<multiqueue0> Bumping single queue 0 max visible to 2452 This happens with all versions up to and including the current git one. On the PC it does not happen with playbin, however. It also does not happen wih these other pipelines: gst-launch-1.0 uridecodebin uri=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-720p-stereo-nodvb.mpd caps="audio/x-m4a ; video/quicktime" ! fakesink sync=true gst-launch-1.0 souphttpsrc location=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-720p-stereo-nodvb.mpd ! decodebin caps="video/x-h264 ; audio/mpeg" ! fakesink sync=true I presume because in both cases, that multiqueue0 isn't present.
This was introduced as part of bug #719893 and bug #722891. Unfortunately nobody remembers why that was a good idea, and it also does not seem to make any sense at all currently. Per, do you remember anything?
I don't remember the details either, but I was working with trying to solve issues with gaps in streams. We ended up using the watchdog element to handle the extreme cases, but I don't remember if we need these changes too to handle other cases.
If I remember correctly it will not grow indefinitely, just until one of the limits “max-size-bytes” or “max-size-time” is reached.
Problem is that both other limits are not set in this situation :) Not sure how gaps would influence anything here. Do you mean gaps in the unlinked streams, or the one linked stream?
commit 5fc2a3fd6683541aae2ac9a6053d2f71b232db69 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Mar 15 14:19:17 2015 +0000 multiqueue: Don't grow queue infinitely if only one pad is linked This was introduced by https://bugzilla.gnome.org/show_bug.cgi?id=719893 https://bugzilla.gnome.org/show_bug.cgi?id=722891 but it doesn't make any sense at all and causes huge memory leaks. https://bugzilla.gnome.org/show_bug.cgi?id=744253