VideoTexture module repeated loading of images causes memory leak #43033

New Issue

Joshua Dolan · 2014-12-27T01:03:54+01:00

Joshua Dolan commented

2014-12-27 01:03:54 +01:00

System Information
Mac OS X 10.10.1
MacBook Pro 15in Early 2011 2.2 GHz Core i7 16GB Ram, Intel HD3000 / Radeon 6750M

Blender Version
Broken: 2.27b hash: 9e963ae 2014-10-21 11:38
Worked: 2.69.0 r60991 Mac 64bit

Short description of error
Repeatedly loading images from disk using the VideoTexture module will cause the ram usage of Blender to constantly increase while running the scene under the BGE. This leads eventually to the BGE hanging while running requiring a force quit.

Exact steps for others to reproduce the error

Open Blender 2.72b
Load the attached .blend file.
Run the BGE by pressing P (The scene will automatically start cycling through textures.)
Observe the blender process memory usage in a system monitoring application. (Activity Monitor on OS X)

Included in the folder is a screen cap showing the memory use while running. I did not observe this in 2.69.0 with over 1,000 repeated loads of images.Monkey_VT_Bug_DelTex.zip

**System Information** Mac OS X 10.10.1 MacBook Pro 15in Early 2011 2.2 GHz Core i7 16GB Ram, Intel HD3000 / Radeon 6750M **Blender Version** Broken: 2.27b hash: 9e963ae 2014-10-21 11:38 Worked: 2.69.0 r60991 Mac 64bit **Short description of error** Repeatedly loading images from disk using the VideoTexture module will cause the ram usage of Blender to constantly increase while running the scene under the BGE. This leads eventually to the BGE hanging while running requiring a force quit. **Exact steps for others to reproduce the error** 1. Open Blender 2.72b 2. Load the attached .blend file. 3. Run the BGE by pressing P (The scene will automatically start cycling through textures.) 4. Observe the blender process memory usage in a system monitoring application. (Activity Monitor on OS X) Included in the folder is a screen cap showing the memory use while running. I did not observe this in 2.69.0 with over 1,000 repeated loads of images.[Monkey_VT_Bug_DelTex.zip](https://archive.blender.org/developer/F133758/Monkey_VT_Bug_DelTex.zip)

Joshua Dolan commented

2014-12-27 01:03:54 +01:00

Changed status to: 'Open'

Joshua Dolan commented

2014-12-27 01:03:54 +01:00

Added subscriber: @jdolan

Raf Colson commented

2015-01-11 05:59:26 +01:00

Added subscriber: @raco

Raf Colson commented

2015-01-11 05:59:26 +01:00

I can confirm the bug.

Nothing seems to help. Tried Texture.close().

Tried also this:

    if not hasattr(logic, "texture"):
        mat_id = texture.materialID(obj, "IMDetails000.png")
        logic.texture = texture.Texture(obj, mat_id)
        logic.texture.source = texture.ImageFFmpeg(img_name)
    else:
        logic.texture.source.reload(img_name)
    logic.texture.refresh(True)

So even just reloading will cause the memory leak.

I can confirm the bug. Nothing seems to help. Tried Texture.close(). Tried also this: ``` if not hasattr(logic, "texture"): mat_id = texture.materialID(obj, "IMDetails000.png") logic.texture = texture.Texture(obj, mat_id) logic.texture.source = texture.ImageFFmpeg(img_name) else: logic.texture.source.reload(img_name) logic.texture.refresh(True) ``` So even just reloading will cause the memory leak.

Joshua Dolan commented

2015-03-31 22:27:08 +02:00

Still present in 2.74rc and release.

Benoit Bolsee was assigned by Jorge Bernal

2015-04-01 08:41:49 +02:00

Jorge Bernal commented

2015-04-01 08:41:49 +02:00

Added subscriber: @JorgeBernalMartinez

Jorge Bernal commented

2015-04-01 08:41:49 +02:00

Benoit,

As you are touching again VideoTexture module, could you investigate this bug?

Benoit, As you are touching again VideoTexture module, could you investigate this bug?

Joshua Dolan commented

2015-04-30 20:40:15 +02:00

Update: While investigating this a bit more it seems that it is the .png images that are causing the problem. Exporting the same images as .jpg allows the textures to be swapped continuously without any issues. (I stopped the loop at 3,500 where as with the original .png files it will crash between 250 and 254.) I will continue to test with other image types that FFMpeg supports.

Edit:
Tested the following formats with these results yesterday -
Image Type, Number of loads, Result, Number of tests
jpeg, 3,500, no crash, 5
jpeg 2k, ~318, crash, 3
png, ~250, crash, 20+
tiff lzw, ~300, crash, 2
tiff, ~258, crash, 2
tga rle, 1,000+, no crash, 2

Update: While investigating this a bit more it seems that it is the .png images that are causing the problem. Exporting the same images as .jpg allows the textures to be swapped continuously without any issues. (I stopped the loop at 3,500 where as with the original .png files it will crash between 250 and 254.) I will continue to test with other image types that FFMpeg supports. Edit: Tested the following formats with these results yesterday - Image Type, Number of loads, Result, Number of tests jpeg, 3,500, no crash, 5 jpeg 2k, ~318, crash, 3 png, ~250, crash, 20+ tiff lzw, ~300, crash, 2 tiff, ~258, crash, 2 tga rle, 1,000+, no crash, 2

Aaron Carlisle commented

2015-06-07 02:25:36 +02:00

Added subscriber: @Blendify

Aaron Carlisle commented

2015-06-07 02:27:11 +02:00

I think that #43033 can be merged seems like the same issue

Ulysse Martin commented

2015-07-05 17:10:43 +02:00

Added subscriber: @you.le

Ulysse Martin commented

2015-07-05 17:10:43 +02:00

Hi! The commit behind the bug is here: https://developer.blender.org/diffusion/B/change/master/source/gameengine/VideoTexture/VideoFFmpeg.cpp%3Bff08acc556d8e40d501522efcbecac68bb8973c6

I can try to look for a solution but I'm not sure to succeed.

Hi! The commit behind the bug is here: https://developer.blender.org/diffusion/B/change/master/source/gameengine/VideoTexture/VideoFFmpeg.cpp%3Bff08acc556d8e40d501522efcbecac68bb8973c6 I can try to look for a solution but I'm not sure to succeed.

Jorge Bernal commented

2015-07-06 08:10:06 +02:00

I haven't check it but perhaps:
thread_count = 1 --> stopCache() + m_isThreaded = false;

I haven't check it but perhaps: thread_count = 1 --> stopCache() + m_isThreaded = false;

Ulysse Martin commented

2015-07-06 13:05:57 +02:00

Hi! I tested your solution but it doesn't work. The problem seems related only to PNG decoding. You can delete this lines:

foreach ($list as $item) {
if (m_isImage)
            {
                *If we're an image, we're probably not going to be here often,* so we don't want to deal with delayed frames from threading.
                *There might be a better way to handle this, but I'll leave that* for people more knowledgeable with ffmpeg than myself. We don't
                // need threading for a single image anyways.
                m_codecCtx->thread_count = 1;
            }
  work_miracles($item);
}

and if you replace png images with jpg, it will work without problem. The memory leak is due to threading but I had a look at AVCodecContext (m_codecCtx type = AVCodecContext) API and found no simple way to end the threads. I read somewhere that new ffmpeg libraries have a better support of PNG but I think it's complex to update libraries (how many files to modify)? Another (maybe stupid) idea would be to convert png images in another format before decoding (I guess it will take some time). But threading with an external API is too complex to manage in my opinion. So I'll try the idea to convert png before decoding (but I don't know if it's possible and efficient). I'm not experimented so you may have better ideas :) Good day/night! A link I found on the net: https://trac.ffmpeg.org/ticket/4404

Hi! I tested your solution but it doesn't work. The problem seems related only to PNG decoding. You can delete this lines: ``` foreach ($list as $item) { if (m_isImage) { *If we're an image, we're probably not going to be here often,* so we don't want to deal with delayed frames from threading. *There might be a better way to handle this, but I'll leave that* for people more knowledgeable with ffmpeg than myself. We don't // need threading for a single image anyways. m_codecCtx->thread_count = 1; } work_miracles($item); } ``` and if you replace png images with jpg, it will work without problem. The memory leak is due to threading but I had a look at AVCodecContext (m_codecCtx type = AVCodecContext) API and found no simple way to end the threads. I read somewhere that new ffmpeg libraries have a better support of PNG but I think it's complex to update libraries (how many files to modify)? Another (maybe stupid) idea would be to convert png images in another format before decoding (I guess it will take some time). But threading with an external API is too complex to manage in my opinion. So I'll try the idea to convert png before decoding (but I don't know if it's possible and efficient). I'm not experimented so you may have better ideas :) Good day/night! A link I found on the net: https://trac.ffmpeg.org/ticket/4404

Ulysse Martin commented

2015-07-08 12:46:56 +02:00

Hi! I propose this fix: http://www.pasteall.org/59457/diff

The problem is that the new while loop can turn in an infinite while loop if tha data can't definitely be read. But we can make a counter m_counter = 0; m_counter+=1 (at the end of the while loop), change while ((input->data- [x]==0 && input->data- [x]==0 && input->data- [x]==0 && input->data- [x]==0) || m_counter < 10). And after the while loop, m_counter = 0; (or something like that)

Sorry about my poor english. Good day/night!

Hi! I propose this fix: http://www.pasteall.org/59457/diff The problem is that the new while loop can turn in an infinite while loop if tha data can't definitely be read. But we can make a counter m_counter = 0; m_counter+=1 (at the end of the while loop), change while ((input->data- [x]==0 && input->data- [x]==0 && input->data- [x]==0 && input->data- [x]==0) || m_counter < 10). And after the while loop, m_counter = 0; (or something like that) Sorry about my poor english. Good day/night!

Ulysse Martin commented

2015-07-08 18:18:50 +02:00

http://www.pasteall.org/59472/diff (That's what I thought about...). From what I have read about png decoding with certain ffmpeg versions, to properly decode png you can use the codecContext->thread_count = 1 workaround but in Blender it can cause memory leak, Or you can try to decode png several time until this is finally decoded properly. That's the solution I used. It's not elegant but it seems that works. What do you think about it? I'll ask IRC to have other devs opinion about that.

blender-admin commented

2015-09-13 20:59:24 +02:00

This issue was referenced by e443dd4d97

This issue was referenced by e443dd4d9768394a61197dc187eb21c65aad7941

Porteries Tristan commented

2015-09-13 21:00:13 +02:00

Changed status from 'Open' to: 'Resolved'

Porteries Tristan closed this issue

2015-09-13 21:00:13 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VideoTexture module repeated loading of images causes memory leak #43033