cv::VideoCapture leaks memory on ethernet cams

System information (version)

• OpenCV => 3.2
• Operating System / Platform => Linux 64 Bit
• Compiler => GCC

Detailed description

I have been noticing my software memory usage grows (slowly) over time.

I used to believe it was some kind of buffer. But after I let it running overnight, and it crashed because it was out of memory, I had to debug.

My software uses 8 VideoCapture instances in RTSP Ethernet Cameras, each one in it's thread, at around 5FPS.

I found out if disable grab() and replace retrieve() for a still image, memory usage doesn't grow. A still image runs my algorithm normally.

After I re-enabled grab(), but not retrieve, the process memory grown 80MB in 1h23m.
After I re-enabled grab and retrieve, the process memory grown 120MB in 16min.

Steps to reproduce

I could reproduce the problem with the following code. More cameras make the memory usage grows faster.

cv::VideoCapture fb;

fb[0].open("rtsp://admin:admin@CAM_IP:554/ucast/11");

cv::Mat test;

while(true){
	fb.grab();
	fb.retrieve(test);
	std::cout << "size: " << test.size() << std::endl;
}

It gave some warnings while running.:
Output.txt
(I believe this is the source of the growing memory.)

More Info

• I sometimes get an error : " [rtsp @ 0xXXXXXXXXXXXX] Too short data for FU-A H.264 RTP packet"
• I have to do 5 grabs for 1 retrieve, so my image don't get delays.
• grab() and retrieve() happen in different threads.

Build details

OpenCV_Build.txt

Start by reproducing the leak with cv::VideoCapture using the RTSP camera pattern and the grab()/retrieve() loop described in the issue. Compare memory growth with grab() disabled and inspect the warnings about short H.264 RTP packets. Done means the reported growth is explained and a regression test or verified fix covers the affected capture path.