When using the player inside a program, memory isn't freed afterwards.

[solarstrings]

Hi!

I took the player (tutorial07.c), changed the main into: playVideoFile(char *filename); by simply exchanging argv to filename. Everything works, but when exiting the player function, the memory isn't freed.

In order to get audio to play the second time you want to play a movie within your program, you need to call SDL_CloseAudio(); in the SDL_QUIT event, like so:

        case SDL_QUIT:
            SDL_CloseAudio();
            is->quit = 1;

otherwise the audio won't play the 2nd time you start a video.

I'm trying to find what memory to free, but I'm new to thread programming (just started learning them by writing a web server in C for a Lab at the university), so I haven't found what to free yet.

When playing a video, it allocates the memory it needs, then stays there. And when closing down the
video, the memory is still allocated, in my case around 72Mb

[solarstrings]

I've run the code through valgrind, and this is the output:

http://dream-code.se/temp/valgrind.txt

==8789== LEAK SUMMARY:
==8789== definitely lost: 52 bytes in 4 blocks
==8789== indirectly lost: 352 bytes in 8 blocks
==8789== possibly lost: 2,992 bytes in 11 blocks
==8789== still reachable: 12,059,503 bytes in 1,396 blocks
==8789== suppressed: 0 bytes in 0 blocks

The problem here is: "still reachable". The program I'm writing is giving the option to select between many different tutorial movies, However, for this to work smoothly, the "still reachable" memory has to be freed, or else the user will be out of memory after playing only a few video files.

If someone could help fix this problem I would be very grateful!

[mpenkov]

Is this a problem with the tutorials or with the ffmpeg library itself?
Speaking of which, which version of ffmpeg are you using?

On 27 February 2014 18:24, solarstrings notifications@github.com wrote:

I've run the code through valgrind, and this is the output:

http://dream-code.se/temp/valgrind.txt

==8789== LEAK SUMMARY:
==8789== definitely lost: 52 bytes in 4 blocks
==8789== indirectly lost: 352 bytes in 8 blocks
==8789== possibly lost: 2,992 bytes in 11 blocks
==8789== still reachable: 12,059,503 bytes in 1,396 blocks
==8789== suppressed: 0 bytes in 0 blocks

The problem here is: "still reachable". The program I'm writing is giving
the option to select between many different tutorial movies, However, for
this to work smoothly, the "still reachable" memory has to be freed, or
else the user will be out of memory after playing only a few video files.

If someone could help fix this problem I would be very grateful!

Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-36224036
.

[solarstrings]

which version of ffmpeg are you using?

I'm trying with different builds, both latest and the older one which comes with Enlightenment OS Luna (basically Ubuntu 12.04). Installed from repository.
Both latest build and the old one results in memory leak, try it with valgrind yourself.

Anyway!
I've been reading up on things, and one thing that needs to be added to the code is:
SDL_WaitThread.

Quoted from: http://wiki.libsdl.org/SDL_WaitThread
"Remarks
Wait for a thread to finish. Threads that haven't been detached will remain (as a "zombie") until this function cleans them up. Not doing so is a resource leak. "

There are two SDL_CreateThreads in the code, but SDL_WaitThread is not called, thus resulting in resource leak.

I played a 25 min long anime episode, and the allocated memory constantly kept growing. It started at about 70MB of allcoated memory and grew to 90+ MB. The same thing does not happen with ffplay.

//-------------

Is this a problem with the tutorials or with the ffmpeg library itself?

It's the tutorials, because ffplay doesn't leak memory. Sure, for a "command-line" player which plays one video file, it's somewhat "ok"... the "still reachable memory" will be free for access again once the program closes (handled by the OS), but if you want to play many different videos, in a row, it's not acceptable.

[mpenkov]

Can you confirm that calling SDL_WaitThread resolves the problem?

On 28 February 2014 05:04, solarstrings notifications@github.com wrote:

I'm trying with different builds, both latest and the older one which
comes with Enlightenment OS Luna (basically Ubuntu 12.04). Installed from
repository.
Both latest build and the old one results in memory leak, try it with
valgrind yourself.

Anyway!
I've been reading up on things, and one thing that needs to be added to
the code is:
SDL_WaitThread.

Quoted from: http://wiki.libsdl.org/SDL_WaitThread
"Remarks
Wait for a thread to finish. Threads that haven't been detached will
remain (as a "zombie") until this function cleans them up. Not doing so is
a resource leak. "

There are two SDL_CreateThreads in the code, but SDL_WaitThread is not
called, thus resulting resource leak.

I played a 25 min long anime episode, and the allocated memory constantly
kept growing. It started at about 70MB of allcoated memory and grew to 90+
MB. The same thing happens with ffplay.

Is this a problem with the tutorials or with the ffmpeg library itself?

It's the tutorials, because they are based upon the code of ffplay, which
also doesn't free the allocate memory in the end. Sure, for a
"command-line" player, its ok... the "still reachable memory" will be free
for access again once the program closes (handled by the OS), but if you
want to play many different videos, in a row, it's not acceptable.

Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-36284994
.