Closed jsorg71 closed 6 years ago
@Zhziyao, please uses valgrind to check this issue. thanks
I ran valgrind already. I think this is a va surface leak or something because vaTerminate cleans it up when the app exits. I can see the leaks when I comment out vaTerminate but I can't figure out what's wrong.
hi @jsorg71 ,
how to see the leak. I comment out the vaTerminiate in your code, run it with
valgrind --leak-check=full ./encode --loop 50
Seems it does not leak anything. It always 6,370 bytes for any loop number.
thanks
==5828==
==5828== HEAP SUMMARY:
==5828== in use at exit: 6,370 bytes in 18 blocks
==5828== total heap usage: 10,246 allocs, 10,228 frees, 837,807,281 bytes allocated
==5828==
==5828== LEAK SUMMARY:
==5828== definitely lost: 0 bytes in 0 blocks
==5828== indirectly lost: 0 bytes in 0 blocks
==5828== possibly lost: 0 bytes in 0 blocks
==5828== still reachable: 6,370 bytes in 18 blocks
==5828== suppressed: 0 bytes in 0 blocks
==5828== Reachable blocks (those to which a pointer was found) are not shown.
==5828== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5828==
==5828== For counts of detected and suppressed errors, rerun with: -v
Can you run with --loop 10000 and then run top and watch VIRT and RES? What do they grow to? Then compare when adding --noencode.
It looks like Intel changed VAAPI https://github.com/01org/libva/commit/3eb038aa13bdd785808286c0a4995bd7a1ef07e9 Can this change affect yami?
@jsorg71 , It does not impact our case. It's just comment. In practice, for intel driver, we never delete the buffer in vaRenderPicture.
Hi @jsorg71 , I can reproduce your result seems only virtual memory grow, the physical memory is kind of stable. This is why we can't find issue using valgrind.
Hi @xhaihao , Seems we leak tons of virtual memory, any idea?
@xuguangxin I found 15 VA surfaces are created however only 14 VA surfaces are destroyed in a single loop.
@xuguangxin @jsorg71 could you have a try with https://github.com/xhaihao/intel-vaapi-driver/commit/a6f5a1c0a0aaf4e3dae9b308d86487b18e43d92c ?
It looks like that was it! Thanks @xhaihao @xuguangxin
I may have spoke too soon. I had a work around in place so it was not growing. I'll do some more testing and reply.
I'm convinced it's fixed. I changed my builder to take intel-vaapi-driver-1.8.2 and patch. I look forward to the next release.
Hi @jsorg71 This issue only happen when you do things like this pattern: "create an encoder ->encode a frame->free the encode->create an encoder->encode a frame....". It's not so efficient to always create encoder. If you just want every frame to be an I frame, you can set https://github.com/01org/libyami/blob/apache/interface/VideoEncoderDefs.h#L216 to 1.
@xuguangxin It happens as well when you "create an encoder -> encode 2 frames -> free encoder" or "create an encoder -> encode 100 frames -> free encoder" or "create an encoder -> encode 1000000 frames -> free encoder" It's the act of free encoder that leaks. I created the test program to exaggerate the scenario. It's not a real world thing you should do and I know there is better ways to get an I frame. A real world app can do something like create an encoder of size 640x640, encode 4000 frames, free encoder. Then later create an encoder or size 1280x720, encode 200 frame, free encoder. and so on. The real world app leaks much slower but after a while it can add up. BTW, this same leak happened when you resize the encoder via encodeStop, encodeGetParameters, encodeSetParameters, encodeStart, but good news, that is fixes now too.
@jsorg71 , You are right, thanks for the clarification.
close this since it fixed, thanks @jsorg71 for report this.
I have a test program here that causes memory to continuously grow. Maybe one of you can take a look to see if I'm doing something wrong.