[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