[MPlayer-dev-eng] CrystalHD & 1080p mkv memory leaks.
wallak at free.fr
wallak at free.fr
Thu Jun 2 01:32:06 CEST 2011
Quoting Philip Langdale <philipl at overt.org>:
> On Tue, 31 May 2011 01:23:39 +0300, Ivan Kalvachev
> <ikalvachev at gmail.com> wrote:
> > On 5/31/11, wallak at free.fr <wallak at free.fr> wrote:
> >> Hello All,
> >>
> >> I was trying the last mplayer / ffmpeg tree with my bcm970015
> >> board.
> >> Everything is fine on a .ts file, but I have 1MB/s memory leaks when
> >> I'm
> >> using
> >> the mkv container. I was unable to debug this situation.
> >>
> >> Any idea to solve this issue ?
> >
> > valgrind also have quite powerful memory leak debugging.
> > --leak-check=full --log-file=errors.log
> >
> > Focus on "definitely lost".
>
> It's also worth trying to reproduce using the software decoder. I
> assume it will run very slowly, but it will help establish whether
> the leak is crystalhd specific (unlikely if the ts played fine).
>
> Also, valgrind with crystalhd might have issues where the hardware
> gets unhappy with how slow the software is running.
>
> --phil
I was trying with the software decoder, everything is fine. This issue is
CrystalHD specific.
A line that trigger this state e.g.:
mplayer -fs -vc ffh264crystalhd -ao null sample-1080p.mkv
I've done some experiments with valgrind, when mplayer closed this memory seems
to be freed and is no more visible. So this 1MB/s memory increased is tracked
somewhere in the code. Maybe the h264 raw video stream ?
valgrind massif failed on my system.
finding the bad malloc line is not so easy.
Wallak.
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
More information about the MPlayer-dev-eng
mailing list