Memory leak about mdk-sdk HOT 12 CLOSED

Ok, I've tried the https://github.com/wang-bin/mdk-examples/blob/master/SFML/sfmlplay.cpp example and it's not leaking, which means that the RenderTexture::create() cannot be called repeatedly, on each media reload.

So I'm wondering if there is a way of rendering a frame, but without drawing it on the screen, but just binding the texture buffer so I can draw it using OpenGL as I need to do some 3D transforms to the quad. It would be great to have updateTexture() and bindTexture() functions so I have full freedom when I want to update and how I want to draw it. I know it's kind off OpenGL specific, but I'm curious of your thoughts.

from mdk-sdk.

Additional reason of being able of not calling renderVideo() on each frame is that 30fps videos are stuttering like without my trick with timer we were talking about in my previous issue.

from mdk-sdk.

sfml does not release previous fbo in RenderTexture::create(). You can try to destroy the old RenderTexture and create a new one when size changed.

From your screenshot, memory increased to 3GB in 16s. Does it leaks when playing a single video?

So I'm wondering if there is a way of rendering a frame, but without drawing it on the screen, but just binding the texture buffer so I can draw it using OpenGL as I need to do some 3D transforms to the quad

RenderTexture is what you want. renderVideo() can draw video to any framebuffer. If draw on screen, it's the default fbo, otherwise it's the fbo currently active.

Additional reason of being able of not calling renderVideo() on each frame is that 30fps videos are stuttering like without my trick with timer we were talking about in my previous issue.

Can you update your mdktest example using custom update event?

from mdk-sdk.

From your screenshot, memory increased to 3GB in 16s. Does it leaks when playing a single video?

It only leaks when I recreate the RenderTexture with texture.create() I need to recreate it for each video reload because all the movies in the library have various resolutions and the switching between them is very frequent. The leak is unavoidable according to what they say on the SFML forum.

Can you update your mdktest example using custom update event?

I'm not sure what I supposed to do in the callback. When I get rid of the rendering in the main loop and move it to the callback:

player.setRenderCallback([=](void*){
	texture->setActive(true);
	player.renderVideo();
	texture->display();
	texture->setActive(false);
});

I get a black screen and a lockup.

from mdk-sdk.

I think I've managed to get rid of the memory leak by creating a dedicated sf::Context for the player. I've updated the test example from the first post. It's still leaking but very little comparing to the previous version, and I'm not sure if it only affects FFmpeg, MMAL seems fine, but maybe because half of my test videos is in yuv444 and showing a black screen.

from mdk-sdk.

I'm still getting this error though even after adding the context:

get Context 0xb42660/0xa2c610 has no local data for key 0xa80fe8, create 1(0xf98690)
get Context 0xb42660/0xa2c610 has no local data for key 0xbd5af8, create 1(0xfb0650)

Any clues? I run SFML in KMS environment.

from mdk-sdk.

I'm still getting this error though even after adding the context:

get Context 0xb42660/0xa2c610 has no local data for key 0xa80fe8, create 1(0xf98690)
get Context 0xb42660/0xa2c610 has no local data for key 0xbd5af8, create 1(0xfb0650)

Any clues? I run SFML in KMS environment.

It's not an error. maybe i forgot to remove these logs

from mdk-sdk.

I think I've managed to get rid of the memory leak by creating a dedicated sf::Context for the player. I've updated the test example from the first post. It's still leaking but very little comparing to the previous version, and I'm not sure if it only affects FFmpeg, MMAL seems fine, but maybe because half of my test videos is in yuv444 and showing a black screen.

only yuv444 videos are black?

from mdk-sdk.

Yes. But actually I did not have any videos encoded with other color spaces apart from yuv420 and yuv444. I may try to reencode and check. I suspect that only yuv420 is hw accelerated on PI so a fallback to ffmpeg for anything other than yuv420 would be neccessary.

from mdk-sdk.

。use v4l2m2m instead

from mdk-sdk.

Isn't v4l2 for encoding camera streams?

from mdk-sdk.

video decoding and encoding are supported on many arm devices. see the latest release note for more details

from mdk-sdk.