[MPlayer-users] MPlayer memory leak with lavc output

[Michael Kohne]

>
>
> Yeah, I guess you have your reasons, but 32 bit x86 is really unsuitable
> for multimedia (easily 10% slower on average) so it's not tested much.
>

Not at all surprising or unreasonable. In this case we're using a modified
version of mencoder to capture data from a video camera and feed it into
our medical monitor. The whole thing goes back over 10 years, and upgrading
things in the medical field is...problematic. On the next hardware rev I'll
be able to force through the switch to a 64 bit OS, but until them I'm
stuck at 32 bit. I'm just glad I was able to upgrade to a later
mplayer/mencoder - newer cameras forced our hand on that one, or I'd still
be using 1.0pre8.

But you should be able to use something like --target=generic configure
> option to disable all architecture-specific optimizations.
>
Just in case you might need to use valgrind after all at some point.
>

Oh, I hadn't considered that. I'm far from familiar with valgrind, so that
never occurred to me. Thank you.


> And yes, there are more lightweight alternatives that avoid such issues
> and are faster. google perftools is another option that might be more
> polished (your description sounds like your tool has problems reading
> advanced debug info). But they are a bit harder to use, so I usually
> recommend valgrind as first option.
>

I think for most folks valgrind is very much the right option. It's just
that I am (in so very many things) the outlier. I'll have to check out
perftools in the future. For the moment, now that I know what it needs,
HeapUsage did the job.

Thanks!


-- 

Michael Kohne
Senior Software Engineer
Office: 215.283.0860 x208 <(215)%20283-0860>
mhkohne at moberg.com


Transforming Neurocritical Care

Moberg Research, Inc.
224 S Maple Street, Ambler, PA 19002
24/7 Customer Support: 1-888-662-7246 <(888)%20662-7246>
www.moberg.com