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.

Still present in 2.74rc and release.

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

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.

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

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 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[0]==0 && input->data[1]==0 && input->data[2]==0 && input->data[3]==0) || m_counter < 10). And after the while loop, m_counter = 0; (or something like that)

Sorry about my poor english. Good day/night!

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.