On 06/08, Mark Thompson wrote: > On 08/06/16 18:23, Will Kelleher wrote: > > Hi all - > > > > I'm experiencing some significant heap growth when encoding with VAAPI on > > my Ivy Bridge hardware. Based on what I'm seeing from Massif, it seems like > > the parameter buffers allocated in vaapi_encode_make_param_buffer are > > leaking. > > > > I came across this thread [1] that indicates that vaEndPicture might not be > > freeing the param buffers like the libva documentation says it should. > > > > I also noticed that VLC [2] seems to explicitly call vaDestroyBuffer on the > > param buffers after vaEndPicture. > > > > When I try that, the leak is gone. > > Yes, I wrote essentially the same code on observing the same issue. > > Unfortunately, you need a lot more machinery to do this safely - the change > makes all buffer operations thread-unsafe (another thread could allocate a > buffer with the ID you are about to try to destroy). That results in needing > VADisplay-global locks around pretty much everything to do with buffers > (including any time the user makes use of them). > > I don't much like the idea of writing all the code to have locking everywhere > (including in all user code talking to libavcodec), so I took the cowardly > approach of doing nothing and hiding behind the documentation :/ > > Therefore, dunno. Maybe we should talk to the libva people about it? > > - Mark > Hmm, good point.
I wonder if this is why libmfx seems to open separate va displays for each encode/decode session. Unfortunately unless we can solve this, the encoder is pretty useless for any long-running encodes. Talking to the libva people might help, but any fix that requires modifications to libva/libdrm is less than ideal because it would require people to likely build those components from source to get a recent enough version for this to work. That said... how sure are you about these thread safety concerns? Did you witness any instability when you tested your vaDestroyBuffer change? I've been running an encode of 12 streams with this patch for 17+ hours now without any issues. I would have crashed due to OOM by now without this. will > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fffmpeg.org%2fmailman%2flistinfo%2fffmpeg-devel&data=01%7c01%7cwkelleher%40gogoair.com%7c74085da316e24558151d08d38fccdd3a%7c2e6508518649457ea18abc0264c3b7d0%7c1&sdata=67%2btJgwLlFuEtAvLgP%2f6FP0Y8WBmzpxyV0lBLXCsCOQ%3d _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
