GNOME Bugzilla – Bug 691074
playbin: excessive memory usage with certain subtitle streams
Last modified: 2013-01-13 12:40:36 UTC
i've got a few files (this one has dvd subtitles) that will freeze our dreambox after a few minutes because gstreamer consumes the entire memory. i couldn't really reproduce the problem on the pc until i forced audio and video sink to be fakesinks but then it munches about 1 mb/s on the pc aswell gst-launch-0.10 playbin2 uri=file:///net/media/Videos/HD/The.Best.Exotic.Marigold.Hotel.mkv text-sink="fakesink" video-sink="fakesink" audio-sink="fakesink" when i disable the subtitles with the flags property, then there is no memory leak gst-launch-0.10 playbin2 uri=file:///net/media/Videos/HD/The.Best.Exotic.Marigold.Hotel.mkv text-sink="fakesink" video-sink="fakesink" audio-sink="fakesink" flags=3 happens with 0.10.36 release and current git
Can you make the file available? Otherwise, perhaps you could run a G_SLICE=always-malloc valgrind --leak-check=yes gst-launch-0.10 .... 2>&1 | tee valgrind.log on the desktop.
Also, when you say "current git" which branch is that?
Created attachment 232729 [details] G_SLICE=always-malloc valgrind --leak-check=yes gst-launch-0.10 playbin2 uri=file:///net/media/Videos/HD/The.Best.Exotic.Marigold.Hotel.mkv text-sink="fakesink" video-sink="fakesink" audio-sink="fakes tim, does the ftp link work now? it's not completely uploaded but more than enough for the problem to be observable i'm afraid my valgrind log is meaningless. it sat there for 4+ hours but didn't really find any issues.
Created attachment 232734 [details] valgrind.log Well, you have to wait until it finishes, since it will only print any leaks at the end. Attached a valgrind log created using: G_SLICE=always-malloc valgrind --leak-check=yes .libs/lt-gst-launch-1.0 playbin uri=file:///mnt/core/samples/private/fraxinas/The.Best.Exotic.Marigold.Hotel.mkv text-sink=fakesink video-sink=fakesink audio-sink=fakesink 2>&1 | tee valgrind.log Note that 0.10 is not maintained any longer. There are some minor leaks, but nothing massive. I think matroskademux generates way too many GAP events though (as if it doesn't move on some marker once it generates a gap).
the memory doesn't technically get lost. it's correctly freed when the pipeline terminates. but memory consumption of 1 mb/s kills our embedded system within minutes.
Created attachment 232739 [details] massif.out Attached a massif.out file generated using: $ G_SLICE=always-malloc valgrind --tool=massif .libs/lt-gst-launch-1.0 playbin uri=file:///mnt/core/samples/private/fraxinas/The.Best.Exotic.Marigold.Hotel.mkv text-sink=fakesink video-sink=fakesink audio-sink=fakesink $ ms_print massif.out will show the details (here just the graph): MB 55.87^ # | ::::::#: | @ :::::: ::#: | ::::::@::: :::: ::#: | ::::: : @::: :::: ::#: | @::::::::::: :: : @::: :::: ::#: | @::::::@: : :: : :: :: : @::: :::: ::#: | ::::@:: :::@: : :: : :: :: : @::: :::: ::#: | ::::@:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | :::@@::: : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | @:::@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | :::@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | ::::::: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: | : :: :: :@: :@: :@ : : : @:::: @:: :::@: : :: : :: :: : @::: :::: ::#: 0 +----------------------------------------------------------------------->Gi 0 676.0 Number of snapshots: 53 Detailed snapshots: [7, 10, 13, 17, 22, 28, 39, 49 (peak)]
hmm yeah and that's less than a 6th of the movie's length so it will extrapolate to almost 200 mb by the end of the playback
Might be related to, or a duplicate of, bug #600648
yeah that's the same issue as slomo's! *** This bug has been marked as a duplicate of bug 600648 ***
Comment 3 marked as private as per request.