artclarke
commented
12 years ago I don't think you're right. See Line 207 where the items you claim are not deleted are actually deleted. That's the xuggle objects at least.
The other (Java) objectsI cannot be responsible for -- the java GC should collect them (e.g. the int[] and the RasterModel). I suspect they are (as you state) staying in memory, but not because they are 'leaked'; only because they are not collected. To see if I'm right, force a garbage collection and you'll likely see that memory drops back down. If not, use something like YourKit to find where the leak is :) Alternately, if there is a cleanup call for those Java objects, please let me know what they are.
That said, I think that method in general is not strong, and you may want to reimplement the same method in a way that COPIES that data using the IBuffer commands into an array that you maintain separately. That way, you don't allocate new objects on the heap repeatedly and don't stress the collector as much.
- Art
On Tue, Jul 31, 2012 at 1:15 PM, rfkrocktk < reply@reply.github.com
wrote:
I'm writing an application which needs to decode transparent frames from an FLV file, so I've activated the scary ArgbConverter in order to make this happen. Nothing about the actual output images would indicate any problem with FFMPEG support, but I noticed a massive memory leak in the method. All of the bytes of each individual frame are kept in memory indefinitely, so if I decode a short, 4 second video into a sequence of images, the actual allocated memory jumps to around 150MB, while the virtual memory jumps to over 700MB:
I'm even calling
IVideoConverter.delete()after each frame is generated to try and wipe it, but this is definitely an in-JVM bug and not something that directly has to do with C types, as far as I can see.The code which seems to be causing the leak is here:
final ByteBuffer byteBuf = picture.getByteBuffer(ref); // now, for this class of problems, we don't want the code // to switch byte order, so we'll pretend it's in native java order byteBuf.order(ByteOrder.BIG_ENDIAN); final IntBuffer intBuf = byteBuf.asIntBuffer(); final int[] ints = new int[picture.getSize() / 4]; intBuf.get(ints, 0, ints.length); // create the data buffer from the ints final DataBufferInt db = new DataBufferInt(ints, ints.length); // create an a sample model which matches the byte layout of the // image data and raster which contains the data which now can be // properly interpreted final SampleModel sm = newSinglePixelPackedSampleModel(db.getDataType(), w, h, mBitMasks); final WritableRaster wr = Raster.createWritableRaster(sm, db, null);
None of these items are ever unallocated, the method simply returns the generated
BufferedImageinstance shortly afterward.I'm not sure what the best way to clear out these buffers and
int[]s would be, so I'm open to suggestions from those who know the codebase better (ahem, @xuggle), but yeah, that's the issue.
Reply to this email directly or view it on GitHub: https://github.com/xuggle/xuggle-xuggler/issues/4
http://www.xuggle.com/ xu‧ggle (zŭ' gl) v. To freely encode, decode, and experience audio and video.
Use Xuggle to get the power of FFmpeg in Java.
RyanfaeScotland
naftulikay
bokken
jkolobok
I'm writing an application which needs to decode transparent frames from an FLV file, so I've activated the scary ArgbConverter in order to make this happen. Nothing about the actual output images would indicate any problem with FFMPEG support, but I noticed a massive memory leak in the method. All of the bytes of each individual frame are kept in memory indefinitely, so if I decode a short, 4 second video into a sequence of images, the actual allocated memory jumps to around 150MB, while the virtual memory jumps to over 700MB:
I'm even calling
IVideoConverter.delete()after each frame is generated to try and wipe it, but this is definitely an in-JVM bug and not something that directly has to do with C types, as far as I can see.The code which seems to be causing the leak is here:
ArgbConverter.java:181-201
None of these items are ever unallocated, the method simply returns the generated
BufferedImageinstance shortly afterward.I'm not sure what the best way to clear out these buffers and
int[]s would be, so I'm open to suggestions from those who know the codebase better (ahem, @xuggle), but yeah, that's the issue.