libvlc 1.1.0 not freeing resources

[AEtH]

Hi to everyone. I'm experiencing a problem involving canvas resources. I've migrated a player from 1.0.6 to 1.1.0 without problems, but I'm experiencing some problems. I'm my aplication, there are one libvlc instance and two media players, and when the first player is playing the second one is stopped, as in a sequence. The time between start-stop sequence is about 3 seconds.

In short, and easier to understand, one media player instance is playing (5 seconds) and stopped (3 seconds). Well, after about 6-8 hours (3000-4000 iterations), the operating system claims: Some operation could not be performed because the system is out of resources. Close some windows and try again.

I tried the same operation with 1.0.6. In that version, the problem is that the memory usage doesn't stop growing. With 1.1.0 the problem is solved (memory usage is stable), but it seems that the canvas handle is not released, and when the player starts playing again, another canvas handle is used.

Now I'm running a debug version with logging activated, maybe it can clarify what is happening.

Thanks

[Jean-Baptiste Kempf]

OS version ?

[AEtH]

Windows XP, video output set to directx.

[Jean-Baptiste Kempf]

Can you try D3D ?

[AEtH]

Yes, no prob. It usually takes about 6-8 hours to crash, so until tomorrow we will know nothing.

Good night.

[Jean-Baptiste Kempf]

k

[AEtH]

I woke up this morning and... the result wasn't good. The player died after about 1500 iterations in less than 4 hours.

[Jean-Baptiste Kempf]

OK, can you try other output modules, like dummy and GDI ?

[AEtH]

Yes no prob. I'll post the results as soon as I get it.

Bye.

[Jean-Baptiste Kempf]

I know this isn't cool, but I have no idea how to fix.

[AEtH]

Well, maybe the results with wingdi and dummy can bring you some enlightment, but until monday I will not have them.
If this can help you, with 1.0.5 and 1.0.6 the player hangs after 48 hours, with directx vout filter, and only because of the huge memory comsumption.

[Jean-Baptiste Kempf]

Yes, memory wise VLC 1.1.0 should be better. But the video outputs have been rewritten, which can be an issue for you.

[AEtH]

Tomorrow I'll post the results of the test, just started the playback (both dummy and wingdi) this afternoon and for the moment everything is fine.

Bye.

[AEtH]

Well... I don't know if the results can help you: dummy ouput was still running this morning without problems after about 20 hours. On the other hand, wingdi output crashed after about 3000 iterations (8 hours).

[Jean-Baptiste Kempf]

Hmm, so, it indeed is an issue of not freeing the HWNDs...

[AEtH]

I realize that is nearly impossible to catch that issue for you, I don't know how many people is running start-stop iterations in such a short time (6-8 seconds), but for sure we're not a lot.

If you want me to run some other test, or info about anything, just tell me. Right now I'm running a crazy test, on every start-stop cycle I'm releasing also the media player instance, something like that (I don't have the source core right now, but it's pretty much the same):

Code: Select all

libvlc_media_player_stop(); libvlc_media_player_release(); ... libvlc_media_new_location() libvlc_media_player_new() libvlc_media_player_set_media() libvlc_media_release() libvlc_media_player_set_hwnd() libvlc_media_player_play()

Let's see if something changes.

Bye

[Rémi Denis-Courmont]

I don't really understand what you mean by canvas. If you set the HWND yourself, VLC won't create nor destroy it. Do you mean that subsequent playbacks occur in independent windows??

As for LibVLC 1.0.x, it is unmaintained and horribly broken. I am totally not looking at it anymore.

[AEtH]

Damn it, I was answering but I closed the session without noticing.

Well, let's explain it another time. First of all, I'm not using 1.0.X neither, it's useless.

Right now, and with 1.1.X, it seems that the vlc instance uses all the graphics resources of the system after a bunch of start-stop cycles. As you wrote before, i set the HWND myself, and every subsequent playback plays occur in the same HWND. But, after every stop-start cycle, seems that the graphic resource is not released, and this happens with all of the video output filters, not only with directX.

I hope that I explained it better.

[AEtH]

Well, I have news, the last test I run obtained the same results, after 8 hours the system got out of resources. I tried with 1.1.1 and 1.2.0, even I set the hwnd to null before stop the video and reset the hwnd to the panel where I play the video just before playing again (another crazy test). This last 2 test resulted the same, after 8 hours the player crashed.

Tell me if a can help doing something. Bye.

[Jean-Baptiste Kempf]

But dummy works, right?
Did you try SDL ?

[AEtH]

Yes, yes, dummy works fine with 1.1.0, 1.1.1 and 1.2.0.
I tried SDL but libvlc_media_player_set_hwnd doesn't work, the video is not rendered in the HWND selected, another window is created and destroyed each iteration (VLC (software YUV SDL output)). Should I configure anything else?
I'm now trying opengl. As far as I understand, it's platform independent, maybe this vout works ok.

[AEtH]

The computer froze before obtaining any OpenGL results, now I'm running the test again.

Besides, are the logging API functions working well under win32?? libvlc_log_open, libvlc_log_count and similar are working well, but I'm uncapable of obtaining messages with libvlc_log_iterator_next.

[Jean-Baptiste Kempf]

This is annoying, I have to say, but I am afraid your only solution will be to fix vlc.

[AEtH]

Well, I'll be glad to help. I don't know if we should be speaking in this post or somewhere else. Anyway, with no debugging in win32 it's nearly impossible to fix anything, can anyone solve that or should I do it myself?? Getting to understand such a large amount of code is frigthening.

Once this is solved I'll try to focus on the differences between vout in 1.0.X and 1.1.X. I know the outputs have been rewritten, but with the debugging maybe I can catch not closing threads or anything similar. As I told before, I'll be really glad to help.

Bye

[Rémi Denis-Courmont]

The only way to debug is to compile yourself. I don't know how bad the situation is on Windows in that respect.