[MPlayer-users] MPlayer memory leak with lavc output

[Reimar Döffinger]

On 08.06.2017, at 14:18, Michael Kohne <mhkohne at moberg.com> wrote:

> On Wed, Jun 7, 2017 at 3:03 PM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> wrote:
> 
>> 
>> valgrind is the most useful tool to debug the leaks it should (after e.g.
>> aborting the command) tell quite clearly where all the memory was allocated.
>> It is however fairly likely it is not a leak.
>> Typical things that look like a leak:
>> - index data for AVI which must be kept in memory and written at the end.
>> It can get really large due to issues with "variable" frame rate or some
>> audio codecs in AVI
>> - audio and video are getting out of sync, requiring one to be buffered a
>> lot. Playing the file while recording might show it by one or the other
>> ending earlier. -noskip -mc 0 usually avoids the leak, but not other issues.
>> 
> 
> Well, I've solved the problem:
> - Valgrind turned out to be useless for this. It choked on some
> instructions in mencoder (I suspect some of the hand-written stuff). This
> is a far from unknown problem with valgrind - it even tells you to how to
> send a bug report with the offending instructions. I added my bug report to
> their tracker just like many others, but since I'm working in 32 bit mode,
> it's really not worth their fixing.

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.
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.
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.