memory leak with videocapture, memory goes up with the function of read(image)

[XuqxMaritech]

Hello! I am using opencv 3.0 beta with visual studio 2013 under windows 7 and 64bit. I downloaded opencv3.0 beta for windows from http://opencv.org/downloads.html. The following is the code I am using to capture the video from rtsp stream and then save some frames every several minutes. It has no problem to capture and read the stream. But I found, the function "read(InputArrray Image)" cause the memory leak. The memory goes up slowly, about one MB for two or three hours. But it keep going up. I am using it for severy months continually. so it is seriouly problem for me. The following is my code for test. Please help me find out where is my problem with these code. Thanks a lot! int main() { string fileNameSave; string URLName;

BOOL stop = FALSE;
BOOL saveFrame = TRUE;
BOOL got_frame = FALSE;
string fileSave = "saveFrame.jpg";
URLName = "rtsp://username:password@IP adress:554/h264/ch1/main/av_stream";
VideoCapture capture;
Mat frame;
capture.open(URLName);
if (!capture.isOpened()){
    cout << " channel 1st has error " << endl;
}
while (!stop){  
    got_frame = capture.read(frame); //here the memory keep goes up
    //save the frame every minute locally
    if (saveFrame == TRUE){
        if (got_frame){
            imwrite(fileSave, frame);
        }
    }
}
capture.release();
return 0;

}

[venkatesh009]

Can we stop memory leak ,If we place frame.release();/releasing the mat memory / at the end of "body" in while loop?

Becoz I think that Mat release the memory for every while loop iteration.

Thank you

[XuqxMaritech]

Thank you! I have tried that method. but it did not work. The memory usage is still keeping increase. I found that most time, the increase is less than the size of one picture(for me the picture is about 100k). It is not always increase with every iteration of read(image), but it do increase after several minutes.

xuqx

From: venkatesh009 Date: 2015-11-26 15:42 To: Itseez/opencv CC: XuqxMaritech Subject: [SPAM] [Disarmed] Re: [opencv] memory leak with videocapture, memory goes up with the function of read(image) (#5715) Shall we stop memory leak ,If we place frame.release();/releasing the mat memory / at the end of while loop. Thank you — Reply to this email directly or view it on GitHub.

[XuqxMaritech]

Thank you! I have tried that method. but it did not work. The memory usage is still keeping increase. I found that most time, the increase is less than the size of one picture(for me the picture is about 100k). It is not always increase with every iteration of read(image), but it do increase after several minutes.

[mshabunin]

@XuqxMaritech , can you reproduce the issue with OpenCV 3.0 release (can be found on sourceforge), or current master branch version?

[XuqxMaritech]

Thanks a lot! I am using opencv 3.0. During running the process(the code is as I have put before). After a few hours, I check the task manager, the memory used for this process has increased a lot (sometimes a few MB). I do think it maybe caused by the function of av_read_frame() from FFMPEG when the network is not stable. In most time, it only increase several KBs for a few minutes. Please help me. The project needs to be running for a few months or years, the problem of memory leak is quite important. In addition, with my coder, would you like to test it for a while? Thanks a lot!

xuqx

From: Maksim Shabunin Date: 2015-12-03 17:17 To: Itseez/opencv CC: XuqxMaritech Subject: [Disarmed] Re: [opencv] memory leak with videocapture, memory goes up with the function of read(image) (#5715) @XuqxMaritech , can you reproduce the issue with OpenCV 3.0 release (can be found on sourceforge), or current master branch version? — Reply to this email directly or view it on GitHub.

[mshabunin]

Seems to be fixed in latest release: comment https://github.com/Itseez/opencv_contrib/issues/455#issuecomment-163534274

[XuqxMaritech]

sorry, I am testing that for a long time. It seems that it happens again. I will report it tomorrow with testing it for a long time.

Thanks!

xuqx

From: Maksim Shabunin Date: 2015-12-10 17:31 To: Itseez/opencv CC: XuqxMaritech Subject: [SPAM] [Disarmed] Re: [opencv] memory leak with videocapture, memory goes up with the function of read(image) (#5715) Seems to be fixed in latest release: comment Itseez/opencv_contrib#455 (comment) — Reply to this email directly or view it on GitHub.

[XuqxMaritech]

I have tested the newest version of OpenCV3.0 downloaded from sourcefordge over the night. The same problem happened again with the same code which I have put before.

Wait for your reply.

Thanks!

xuqx

From: Maksim Shabunin Date: 2015-12-10 17:31 To: Itseez/opencv CC: XuqxMaritech Subject: [SPAM] [Disarmed] Re: [opencv] memory leak with videocapture, memory goes up with the function of read(image) (#5715) Seems to be fixed in latest release: comment Itseez/opencv_contrib#455 (comment) — Reply to this email directly or view it on GitHub.

[shawnsnyder]

Hello, testing on osx 10.11.
3.1 and the current master seem to have the same memory leak when using capture.read(frame1); repeated and subsequent calls to frame1.release() does not resolve the leak.

[BarrettLowe]

I'm getting the same thing on osx 10.12.4. I may have time to look into it but honestly I'm pretty unfamiliar with the source. Anybody still working on this?

[alalek]

@BarrettLowe Feel free to investigate reasons of this issue.

[enazoe]

I'm getting the same thing on ubuntu 16.04！！！！

[yentsun]

Getting same memory leak on OpenCV 3.4 (ubuntu 16.04)

[sohussain]

Can confirm on OpenCV 3.4, ubuntu 16.04, still leaks memory when reading from an RTSP stream.

[trocolit2]

I got memory leak when I read a regular mp4 (H.264) video. The leak happens with OpenCV 3.4.1 on ubuntu 16.04. The input video can be found on https://github.com/trocolit2/opencv_workshop/blob/master/dataset/video_01.mp4

The code to read video frames.

cv::VideoCapture cap_video( "path/video.mp4" );
  cv::Mat frame;
  uint i = 0;
  while(cap_video.read(frame)){
    std::cout << "Frame: " << ++i << std::endl;
    cv::imshow( "Frame", frame );
    cv::waitKey(1);
  }

I can provide more details if needed.

[alalek]

Please provide info about your OpenCV build: cv::getBuildInformation() ("Video I/O" section).

You could run your application via valgrind. It is able to show more information about memory leaks. Also remove imshow / waitKey calls - they are not related to mentioned problem. Provide minimal reproducer.

[trocolit2]

The information about Video I/O got by cv::getBuildInformation():

Video I/O:
    DC1394:                      YES (ver 2.2.4)
    FFMPEG:                      YES
      avcodec:                   YES (ver 56.60.100)
      avformat:                  YES (ver 56.40.101)
      avutil:                    YES (ver 54.31.100)
      swscale:                   YES (ver 3.1.101)
      avresample:                NO
    GStreamer:                   
      base:                      YES (ver 1.8.3)
      video:                     YES (ver 1.8.3)
      app:                       YES (ver 1.8.3)
      riff:                      YES (ver 1.8.3)
      pbutils:                   YES (ver 1.8.3)
    libv4l/libv4l2:              NO
    v4l/v4l2:                    linux/videodev2.h
    gPhoto2:                     NO

The summary of valgrind analysis :

==28587== HEAP SUMMARY:
==28587==     in use at exit: 1,258,916,694 bytes in 28,055 blocks
==28587==   total heap usage: 75,814 allocs, 47,759 frees, 1,365,341,099 bytes all$
==28587==
==28587== LEAK SUMMARY:
==28587==    definitely lost: 64,498 bytes in 205 blocks
==28587==    indirectly lost: 273,806,623 bytes in 479 blocks
==28587==      possibly lost: 982,919,030 bytes in 329 blocks
==28587==    still reachable: 2,057,887 bytes in 26,720 blocks
==28587==                       of which reachable via heuristic:
==28587==                         length64           : 8,032 bytes in 190 blocks
==28587==                         newarray           : 1,680 bytes in 25 blocks
==28587==         suppressed: 0 bytes in 0 blocks
==28587== Reachable blocks (those to which a pointer was found) are not shown.
==28587== To see them, rerun with: --leak-check=full --show-leak-kinds=all

The complete valgrind log file is available at https://github.com/trocolit2/opencv_workshop/blob/master/samples/valgrind.txt

[mshabunin]

@trocolit2 , could you please check the latest 3.4 branch version? The GStreamer backend has been slightly refactored after 3.4.1 release (#11320), so the issue can be fixed already.

[mshabunin]

@trocolit2 , I've found the issue, please try the fix from PR #11573.

[trocolit2]

Thanks @mshabunin and @alalek ! I updated and the VideoCapture worked properly!

[rashikcs]

Migrated to the newest version but still the problem persists.

System information (version)

• OpenCV => 4.0.0
• Operating System / Platform => Ubutu 64bit
• Compiler => g++ -std=c++11

[roter-mann]

I think I found the problem with the gstreamer backend. If your application is actual a little bit slower than your configured fps you got a memory leak. If you look at the cap_gstreamer.cpp file at line 768 gst_app_sink_set_drop is why ever out commented. The internal buffer is set to one but you must also set gst_app_sink_set_drop true to delete the internal queue of gstreamer or comment out bool streamer.

If you set this function to true all looks fine. But this should only be done if you stream something and you want only the most updated frame because if you do not poll accurate the stream some frames will be skipped!

You can simply test this problem if you set your stream for example to 25 fps and call the read method every one second.

The whole problem is described here: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsink.html.

[tripzero]

Submitted patch but it won't fly. I attempted a custom pipeline with "drop=true" set on appsink. It has not appeared to solve the memory leak issues with rtsp streaming and opencv 4.1. I'm seeing about 550+KB per second leaked.

rtspsrc location=rtsp://something:554/stream ! rtph265depay ! h265parse ! msdkh265dec ! videoconvert ! appsink drop=true

[Abu-Abdullah]

Submitted patch but it won't fly. I attempted a custom pipeline with "drop=true" set on appsink. It has not appeared to solve the memory leak issues with rtsp streaming and opencv 4.1. I'm seeing about 550+KB per second leaked.

I have the same issue https://github.com/opencv/opencv/issues/13801#issuecomment-496869220 and non of sync=false max-buffers=1 drop=true is working. it is very clear in my case that i'm loosing 4MB in every file reading even after releasing the object. there is a leak for sure here and cannot find a workaround for it

[ghost]

I'm experiencing leaks too but i see them when i try to open VideoCapture. My configuration is Ubuntu 18.04, OpenCV 4.1.0, GStreamer 1.16 (built from source). This is a sample program that tries to connect to a non existing rtsp server:

#include <opencv2/highgui.hpp>
#include <opencv2/videoio.hpp>
#include <iostream>

int main(int argc, char *argv[])
{
    bool connected = false;
    size_t connection_tries = 10;

    std::string gst_pipe =
                std::string("rtspsrc location=rtsp://root:root@127.0.0.1/axis-media/media.amp ") +
                std::string("protocols=GST_RTSP_LOWER_TRANS_TCP latency=0 timeout=5000000 ") +
                std::string("! rtph264depay ! queue ! vaapih264dec ! videoconvert ! video/x-raw, format=BGR ! appsink sync=true");

    std::cout << "gst_pipe: "  << gst_pipe << std::endl;

    // tries to connect
    for (size_t i = 0; i < connection_tries && !connected; i++)
    {
        cv::VideoCapture vidcap;

        vidcap.open(gst_pipe, cv::CAP_GSTREAMER);
        connected = vidcap.isOpened();

        if (!connected)
        {
            // print every 100 tries
            if (connection_tries < 20 || i % 100 == 0)
            {
                std::cout << "trying to open stream..." << std::endl;
                fflush(stdout);
            }
        }

        vidcap.release();
    }

    return 0;
}

I ran it with valgrind using the following command in order to exclude gstreamer false positives (suppression file at https://github.com/GStreamer/common/blob/master/gst.supp) G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=full --log-file=./valgrind.log --suppressions=./gst.supp ./a.out

An extract of The valgrind log (full log attached):

==9150==    at 0x78C1A04: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==9150==    by 0x78A2747: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==9150==    by 0x78A3EE4: g_object_new_with_properties (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==9150==    by 0x78A4960: g_object_new (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
==9150==    by 0x75AE791: gst_element_factory_create (gstelementfactory.c:372)
==9150==    by 0x75AE87D: gst_element_factory_make (gstelementfactory.c:445)
==9150==    by 0x7622AE6: priv_gst_parse_yyparse (grammar.y:813)
==9150==    by 0x7623B64: priv_gst_parse_launch (grammar.y:1176)
==9150==    by 0x761A92E: gst_parse_launch_full (gstparse.c:339)
==9150==    by 0x4E75B85: GStreamerCapture::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (cap_gstreamer.cpp:639)
==9150==    by 0x4E77F38: cv::createGStreamerCapture_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (cap_gstreamer.cpp:1131)
==9150==    by 0x4E6DB75: cv::StaticBackend::createCapture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (backend_static.cpp:34)
==9150== 
==9150== LEAK SUMMARY:
==9150==    definitely lost: 14,801 bytes in 34 blocks
==9150==    indirectly lost: 56,948 bytes in 559 blocks
==9150==      possibly lost: 0 bytes in 0 blocks
==9150==    still reachable: 250,847 bytes in 3,045 blocks
==9150==                       of which reachable via heuristic:
==9150==                         length64           : 2,496 bytes in 54 blocks
==9150==                         newarray           : 1,936 bytes in 41 blocks
==9150==         suppressed: 1,810,509 bytes in 22,643 blocks
==9150== Reachable blocks (those to which a pointer was found) are not shown.
==9150== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==9150== 
==9150== For counts of detected and suppressed errors, rerun with: -v
==9150== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 70 from 70)

valgrind.log

But there's more. If I put a bigger number of connection_tries in the sample program (say 10000000) and launch it without valgrind the program will terminate unexpectedly printing the following error: GLib-ERROR **: 08:18:23.731: Creating pipes for GWakeup: Too many open files

and as in this issue of a non-OpenCV related program, with the command ls -la /proc/$PID/fd | wc -l

I see an increasing number of file descriptors which have these kind of names:

pipe:[778011]
pipe:[778012]
anon_inode:[eventfd]
/dev/dri/renderD128

Once the number of file descriptors reaches 1027 the program stops. If I run it in debug a SIGTRAP is caught and usually it falls in file gstgldisplay.c in the static function _event_thread_main (GstGLDisplay * display) while calling display->main_context = g_main_context_new ();

I'm not sure where the problem is located but from valgrind I would say that the resources allocated at VideoCapture's open() are not correctly released when VideoCapture is released/destroyed.

Can someone confirm this behavior? Hope these info can help.

[TyroneLi]

Thanks @mshabunin and @alalek ! I updated and the VideoCapture worked properly!

I met the same isuue using opencv3.4.6,ubuntu18.Can you tell me which opencv version did you update so that everything worked fine?Here is my build infos: `General configuration for OpenCV 3.4.6 ===================================== Version control: unknown

Platform: Timestamp: 2019-06-18T02:55:29Z Host: Linux 4.15.0-29-generic x86_64 CMake: 3.10.2 CMake generator: Unix Makefiles CMake build tool: /usr/bin/make Configuration: RELEASE

CPU/HW features: Baseline: SSE SSE2 SSE3 requested: SSE3 Dispatched code generation: SSE4_1 SSE4_2 FP16 AVX AVX2 AVX512_SKX requested: SSE4_1 SSE4_2 AVX FP16 AVX2 AVX512_SKX SSE4_1 (14 files): + SSSE3 SSE4_1 SSE4_2 (2 files): + SSSE3 SSE4_1 POPCNT SSE4_2 FP16 (1 files): + SSSE3 SSE4_1 POPCNT SSE4_2 FP16 AVX AVX (6 files): + SSSE3 SSE4_1 POPCNT SSE4_2 AVX AVX2 (28 files): + SSSE3 SSE4_1 POPCNT SSE4_2 FP16 FMA3 AVX AVX2 AVX512_SKX (2 files): + SSSE3 SSE4_1 POPCNT SSE4_2 FP16 FMA3 AVX AVX2 AVX_512F AVX512_SKX

C/C++: Built as dynamic libs?: YES C++11: YES C++ Compiler: /usr/bin/c++ (ver 5.5.0) C++ flags (Release): -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winit-self -Wno-delete-non-virtual-dtor -Wno-comment -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -msse -msse2 -msse3 -fvisibility=hidden -fvisibility-inlines-hidden -O3 -DNDEBUG -DNDEBUG C++ flags (Debug): -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winit-self -Wno-delete-non-virtual-dtor -Wno-comment -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -msse -msse2 -msse3 -fvisibility=hidden -fvisibility-inlines-hidden -g -O0 -DDEBUG -D_DEBUG C Compiler: /usr/bin/cc C flags (Release): -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wuninitialized -Winit-self -Wno-comment -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -msse -msse2 -msse3 -fvisibility=hidden -O3 -DNDEBUG -DNDEBUG C flags (Debug): -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wuninitialized -Winit-self -Wno-comment -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -msse -msse2 -msse3 -fvisibility=hidden -g -O0 -DDEBUG -D_DEBUG Linker flags (Release): -Wl,--gc-sections
Linker flags (Debug): -Wl,--gc-sections
ccache: NO Precompiled headers: YES Extra dependencies: m pthread cudart_static -lpthread dl rt nppc nppial nppicc nppicom nppidei nppif nppig nppim nppist nppisu nppitc npps cublas cufft -L/usr/local/cuda-10.0/lib64 -L/usr/lib/x86_64-linux-gnu 3rdparty dependencies:

OpenCV modules: To be built: calib3d core cudaarithm cudabgsegm cudafeatures2d cudafilters cudaimgproc cudalegacy cudaobjdetect cudaoptflow cudastereo cudawarping cudev dnn features2d flann highgui imgcodecs imgproc ml objdetect photo shape stitching superres ts video videoio videostab Disabled: cudacodec world Disabled by dependency: - Unavailable: java js python2 python3 viz Applications: tests perf_tests apps Documentation: NO Non-free algorithms: NO

GUI: GTK+: YES (ver 2.24.32) GThread : YES (ver 2.56.4) GtkGlExt: NO OpenGL support: NO VTK support: NO

Media I/O: ZLib: /usr/lib/x86_64-linux-gnu/libz.so (ver 1.2.11) JPEG: /usr/lib/x86_64-linux-gnu/libjpeg.so (ver 80) WEBP: /usr/lib/x86_64-linux-gnu/libwebp.so (ver encoder: 0x020e) PNG: /usr/lib/x86_64-linux-gnu/libpng.so (ver 1.6.34) TIFF: build (ver 42 - 4.0.10) JPEG 2000: build (ver 1.900.1) OpenEXR: build (ver 1.7.1) HDR: YES SUNRASTER: YES PXM: YES

Video I/O: DC1394: YES (ver 2.2.5) FFMPEG: YES avcodec: YES (ver 57.107.100) avformat: YES (ver 57.83.100) avutil: YES (ver 55.78.100) swscale: YES (ver 4.8.100) avresample: NO GStreamer: NO libv4l/libv4l2: NO v4l/v4l2: linux/videodev2.h

Parallel framework: TBB (ver 2017.0 interface 9107)

Trace: YES (with Intel ITT)

Other third-party libraries: Lapack: NO Eigen: YES (ver 3.3.4) Custom HAL: NO Protobuf: build (3.5.1)

NVIDIA CUDA: YES (ver 10.0, CUFFT CUBLAS NVCUVID) NVIDIA GPU arch: 30 35 37 50 52 60 61 70 75 NVIDIA PTX archs:

OpenCL: YES (no extra features) Include path: /home/lijinlong/toolkits/opencv-3.4.6/3rdparty/include/opencl/1.2 Link libraries: Dynamic load

Python (for build): /usr/bin/python2.7

Java:
ant: NO JNI: NO Java wrappers: NO Java tests: NO

Install to: /home/lijinlong/toolkits/opencv3Install -----------------------------------------------------------------`

[mshabunin]

@TyroneLi , that fix have been introduced since 3.4.2, but it relates to GStreamer backend which is disabled in your case. So you have to try and investigate details in your specific case.

@brtndr , there are several more fixes for GStreamer backend, e.g. #15092. Could you please try to reproduce your issue with latest master branch?

[muzammil360]

Hi. I am also facing memory leakage issue with OpenCV video writer. I am using OpenCV with GStreamer to stream videos over RTMP.

OS: Ubuntu 18.04.3 LTS OpenCV Version: 3.4.6 GStreamer version: 1.14.5

For me the memory leakage is around 1MB/video.

@mshabunin, you are pointing @brtndr towards #15092. How exactly am I supposed to use that? I am sorry if its a stupid question.

@TyroneLi , @brtndr were you able to resolve the issue? If so, can you help me point to the fix?

[AmmarHSufyan]

2020 and the problem still persists

[Bixiii]

I also have this problem (tried with OpenCV 3.4.2, 3.4.7 and 4.1.0)

[MDOBreno]

I'm on 3.4.9, and the problem still persist

[paulrisk3]

Checking in in 2021 and I'm still seeing the leak. Of note: nmon shows my "Free Percent" of memory steadily declining. However, free shows that only a small amount of RAM is actually "used", while the amount of RAM allotted to "buff/cache" is steadily growing.

[mshabunin]

Growing "cache" memory is not a sign of a memory leak (https://www.linuxatemyram.com/).

[kdavis523]

Using opencv 4.4 I am experiencing this issue as well

[dexception]

Using opencv-python 4.1.2.30 and still facing the issue. Every call to VideoCapture is increasing memory by 20MB.

This is a shame and disaster that even after 7 years this bug has not been fixed and nobody has bothered to provide a solution.

[Y-T-G]

The tiny leak is probably due to the internal frame counters which allocate more memory as they get bigger. OpenCV should add the ability to reset the internal frame counters.

[chuong98]

8 years later, in Mar 2023, version 4.5.0, the problem is still persist. Thank you for your hard work.

[nospotfer]

8 years later, in Jun 2023, version 4.7.0, the problem is still persist. Thank you for your hard work.

[TheDemonMahesh]

before capturing or doing the stream set the capture width and size. cv::VideoCapture capture(0); capture.set(cv::CAP_PROP_FRAME_WIDTH, 640); capture.set(cv::CAP_PROP_FRAME_HEIGHT, 360); capture.set(cv::CAP_PROP_FPS, 30); these will stop increasing the memory.

[dennisappel]

@TheDemonMahesh unfortunately setting the size doesn't help. In my application it seems that the problem was the buffer buf, _ := gocv.IMEncode(".jpg", img) I didn't close it now my code looks like this buf, _ := gocv.IMEncode(".jpg", img) img.Close() byteBuf := buf.GetBytes() handler2 <- byteBuf buf.Close()
and the memory leak seems to be gone. Hope that helps some of you.