RTSP streams freeze at version 3.1+ but not at 3.0

[miloMich]

System information (version)

• OpenCV => 3.1+ including 3.4.1
• Operating System / Platform => Windows .Net C# x86
• Compiler => Visual Studio 2017

Detailed description

Using an RTSP camera such as "AimCam", the stream freezes after 10 seconds. It does not freeze when using EMGU 3.0. It does not freeze when run through VLC utility either

Steps to reproduce

             _capture = new VideoCapture("rtsp://192.168.1.254/12345678.mov");
               _capture.ImageGrabbed += processFrame;
               _capture.Start();
…
// processFrame
           _capture.Retrieve(_frame);
            _frameBmp?.Dispose();
               _frameBmp = _frame.Bitmap;

   ```

[alalek]

EMGU

There is no support for C# bindings here.

incomplete

It is very hard to reproduce issues with remote video streams.
You should investigate this problem yourself and provide more details.

[miloMich]

Regardless of binding, it appears the problem is directly within the OpenCV library though. It is verified to not exist in version 3, yet does exist in later versions.

[miloMich]

Freeze - stops collecting video frames.

This is not solicitation of troubleshooting assistance. There is an underlying issue within OpenCV library that didn't exist in older version.

C++ code:

#include <opencv2/core.hpp>
#include <opencv2/videoio.hpp>
#include <opencv2/highgui.hpp>
#include <iostream>
#include <stdio.h>
using namespace cv;
using namespace std;
int main(int, char**)
{
Mat frame;
//--- INITIALIZE VIDEOCAPTURE
VideoCapture cap;
// open the  camera using RTSP stream
    cap.open( "rtsp://192.168.1.254/12345678.mov");

// check if we succeeded
if (!cap.isOpened()) {
        cerr << "ERROR! Unable to open camera\n";
return -1;
    }
//--- GRAB AND WRITE LOOP
    cout << "Start grabbing" << endl
        << "Press any key to terminate" << endl;
for (;;)
    {
// wait for a new frame from camera and store it into 'frame'
        cap.read(frame);
// check if we succeeded
if (frame.empty()) {
            cerr << "ERROR! blank frame grabbed\n";
break;
        }
// show live and wait for a key with timeout long enough to show images
imshow("Live", frame);
if (waitKey(5) >= 0)
break;
    }
// the camera will be deinitialized automatically in VideoCapture destructor
return 0;
}

[berak]

hmm, the lines below will close the rtsp stream, and reopen a local, usb webcam stream:

int apiID = cv::CAP_ANY;      // 0 = autodetect default API
// open selected camera using selected API
    cap.open(deviceID + apiID);

(that's for sure not, what you wanted, also not helpful to debug the original (ip related) problem)

[berak]

you update your code above, and i'll strike the comment, i'd say.

also, it will be only reproducable, if we can agree on a publicly viewable ip (NOT 192.168.x.x)

[miloMich]

The request for a different URL is understood. Unfortunately, this is a URL relevant to the "AimCam" camera I have issues with. When testing against the public "bunny" video at the link below, has no issue. When running through debugger - the application hangs within the OpenCV_ffmpeg dll.

rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov

the aim-cam camera model: (this is the store page, no intention to solicit purchase)
https://www.aimcam.com/products/aimcam-pro-2-black

like mentioned above. The steam does not halt process when run with version 3.0 of open-cv. Also, the stream does not "freeze" (as explained above) when run through VLC or through its own android application.

Current stack trace when stops responding:
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]

opencv_ffmpeg340.dll!69d072ca() Unknown
opencv_ffmpeg340.dll!69cf9615() Unknown
opencv_ffmpeg340.dll!6a5caf91() Unknown
opencv_ffmpeg340.dll!69ca1150() Unknown
opencv_ffmpeg340.dll!69cf9615() Unknown
opencv_ffmpeg340.dll!69ca111e() Unknown
[External Code]
opencv_ffmpeg340.dll!6a5caf91() Unknown
[External Code]
opencv_ffmpeg340.dll!69d11e93() Unknown
[External Code]
opencv_ffmpeg340.dll!69d11f13() Unknown
opencv_ffmpeg340.dll!69cf9615() Unknown
opencv_ffmpeg340.dll!69ca7601() Unknown
[External Code]
opencv_ffmpeg340.dll!69d11f13() Unknown
opencv_ffmpeg340.dll!69cf9615() Unknown
opencv_ffmpeg340.dll!6a5caf91() Unknown
opencv_ffmpeg340.dll!69ca755e() Unknown

[berak]

3.4.0 -- no more relevant. please use at least 3.4.1 , better even. latest master branch (4.0.0.dev)

[berak]

no problem, using latest master branch here:

int main(int argc, char** argv)
{
	VideoCapture cap("rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov");
	cout << cap.isOpened() << endl;
	while(1) {
		Mat frame;
		cap >> frame;
		imshow("M",frame);
		waitKey(10);
	}
    return 0;
}

( emgu or not, i don't think, you have a valid issue here, in the 1st case)

[miloMich]

Like I mentioned, the "bunny" video isn't demonstrating the issue. I can only reproduce this issue with the camera I mention above, which is streaming on its own wifi and cannot be made public. And it appears to be locked at the ffmpeg dll. I'm in the process of building it again with 3.4.1 to verify again.

[berak]

Like I mentioned, the "bunny" video isn't demonstrating the issue.

why mention it, then ?

[miloMich]

Several comments above I'm asked to supply a URL. My comment was that I'm looking for one, and the only public one I found with quick search doesn't demonstrate an issue.

[berak]

@miloMich cmon. right now youre fighting something that has all of the BADDIES , -- unsupported 3rdparty wrappers (emgu), outdated opencv versions, and in the end, you're probably fighting some problem due to your (local) ip cam not complying to any standards

again i do not think, you have enough "proof" to submit a bug report here. so, please close it. (rather do some more research on your own, and come back if you really found something).

[miloMich]

lockup on version 3.4.1 as well. Stack trace:
[External Code]
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]

opencv_ffmpeg341.dll!69d0f2ca() Unknown
opencv_ffmpeg341.dll!69d01215() Unknown
opencv_ffmpeg341.dll!6a5f0841() Unknown
opencv_ffmpeg341.dll!69ca7e30() Unknown
[External Code]
opencv_ffmpeg341.dll!69d01215() Unknown
opencv_ffmpeg341.dll!69ca7dfe() Unknown
[External Code]

This is not EMGU, this is in opencv. It is possibly an issue with manufacturer's compliance with some standard, however the issue is not in version 3 of opencv. I hear your comments requesting I close it. I'm not arguing or anything. I opened this issue here because I was directed here. The lockup is happening, but there is no tool to open and see what in opencv_ffmpeg341.dll is locking up or why. If it isn't something that can be resolved here, and that's why you wish I close this issue - then that's how it'll be.

[berak]

@miloMich apologies for being overly harsh before !

(but again, -- as long as we cannot access your ipcam, we can't debug your problem)

[miloMich]

Understood - I'll see if anything further can be done to assist. If it's OK - I'll leave this open for the next few days as I look into ways to provide a sample stream

[kinchungwong]

On the internet there are instructions for saving the stream to a file (without any re-encoding). Please give it a try, and see if the freeze problem can be re-created when reading from that file.

Based on internet discussions, it is true that ip cameras can behave erratically, such as closing streams unexpectedly or reboot. The only way to investigate would be to ask the ip camera manufacturer to investigate. Otherwise, another venue is to ask in the user forums for that vendor/brand of ip camera.

[alalek]

OpenCV doesn't work with cameras / video streams directly. It uses some libraries/SDK/APIs.
In this case OpenCV uses FFmpeg to grab rstp stream.

opencv_ffmpeg.dll is a wrapper over FFmpeg sources.
OpenCV 3.0 uses very old FFmpeg (something like FFmpeg 2.x).
OpenCV 3.4.1 uses FFmpeg 3.4.2.

Did you observe issues with FFmpeg tools without OpenCV? Try "ffmpeg" binary to capture your rstp stream and write it into file.
If possible try both fresh (3.4) and old (2.x) FFmpeg versions.

Try to play with TCP/UDP settings (OpenCV 3.3.1+ via OPENCV_FFMPEG_CAPTURE_OPTIONS): https://github.com/opencv/opencv/blob/3.4.1/modules/videoio/src/cap_ffmpeg_impl.hpp#L811-L823

Also you could try to "replace" this wrapper DLL with older one. External interfaces of opencv_ffmpeg wrapper may be compatible (not tested!), so try to rename opencv_ffmpeg DLL from OpenCV 3.0 to 3.4.1.