Issue title: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5VideoCapture leaks memory on ethernet cams
 Issue body: ##### 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.

##### Steps to reproduce
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.

##### 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](https://github.com/opencv/opencv/files/761794/OpenCV_Build.txt)

 Comments: 
 Comment 0: These warnings are come from ffmpeg.
Please add valgrind memory leaks report (with stack traces related to OpenCV/FFmpeg).
 Comment 1: [main_cpp.txt](https://github.com/opencv/opencv/files/764265/main_cpp.txt)
[valgrind_videocapture.txt](https://github.com/opencv/opencv/files/764262/valgrind_videocapture.txt)

 Comment 2: I see these OpenCV leaks:
- cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5getInitializationMutex()
- cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Mat38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5getStdAllocator()
- cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5TLSData<cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5oreTLSData>38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5reateDataInstance()
- cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5TLSDataContainer38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5getData()
- cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5ipp38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5useIPP()
They are all non critical.

Did I miss something? What part of logs should blame OpenCV in mentioned memory leaks?
 Comment 3: I am not very used to Valgrind, so I may be misusing the info I got.

On that log, I found 10 ocurrences of cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5VideoCaptur38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5retrieve(), but at the maximum of 256 bytes.
These are "still reachable in loss record". 

This means these bits will increase the program size ?




 Comment 4: About this part I got from my software, does it mean something?


==20659== 5,529,680 bytes in 2 blocks are possibly lost in loss record 935 of 938
==20659==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20659==    by 0x51E731: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5stMalloc(unsigned long) (in /home/usr/my_code/)
==20659==    by 0x62194A: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Mat38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5reate(int, int const*, int) (in /home/usr/my_code/)
==20659==    by 0x621E98: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Mat38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5reate(int, int, int) (in /home/usr/my_code/)
==20659==    by 0x642DF7: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5_OutputArray38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5reate(int, int, int, int, bool, int) const (in /home/usr/my_code/)
==20659==    by 0x5809B2: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5Mat38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5opyTo(cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5_OutputArray const&) const (in /home/usr/my_code/)
==20659==    by 0x93AB0F: cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5VideoCaptur38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5retrieve(cv38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5_OutputArray const&, int) (in /home/usr/my_code/)
==20659==    by 0x4CA235: EthCapture(Camera*) (in /home/usr/my_code/)
==20659==    by 0xE6B158E: execute_native_thread_routine (thread.cc:83)
==20659==    by 0xEC89453: start_thread (in /usr/lib/libpthread-2.24.so)
==20659==    by 0xF5E37DE: clone (in /usr/lib/libc-2.24.so)
 Comment 5: This means what there are no release calls for Mat in `retrieve()` argument
 Comment 6: I found the problem is related with cv:Mat, even if you do not capture video. Have you found a fix?
 Comment 7: I have not.
I have started looking at it, but I start focusing in another aspect of my project, due to project planning. If you have any tip, I will take note for when I go back to this part of the project.

Can you explain better how you reproduce the problem, so it's easier to fix?
Thank you!
{'source': 'GithubIssues', 'repo_name_with_owner': 'opencv/opencv', 'issue_id': 206306331, 'repo_stars': 58402.0}