Stream is blocked by 20 seconds or more when reading an mjpeg stream at low resolutions (Bug #2877)
When opening a network-based mjpeg stream using OpenCV's VideoCapture, the stream doesn't actually get displayed until 20 or 30 seconds later, and the program blocks waiting for ffmpeg to evaluate the stream parameters (as it freezes in avformat_find_stream_info). I find that I don't notice it with 640x480
30fps streams, but at 320x260 5fps the delay is huge. If one enables the ffmpeg logging, after the freeze is done you can see a message similar to "max_analyze_duration 5000000 reached at 5000000".
The following python code can reproduce the problem.
import cv2 vc = cv2.VideoCapture() vc.open('http://192.168.0.10/mjpg/video.mjpg') # freezes on this line
I found that you can fix this problem by inserting "ic->max_analyze_duration = 50000;" at line 532 (in CvCapture_FFMPEG::open(), right before avformat_find_stream_info() is called). However, it's not clear to me whether this is a problem that OpenCV should have a setting to fix, or whether this is an ffmpeg problem (though preferably it should be fixed in both locations). It's also not clear to me whether setting the max_analyze_duration affects anything -- as far as I can see, the video stream still works perfectly fine for me.
This affects OpenCV 2.4.4 on Windows (32 bit) and Linux (64 bit). I'm using the Python bindings, but that shouldn't matter at all, I imagine it affects the C++ bindings also.
Thank you for your bug report. OpenCV is open source project and you can contribute your changes via pull request on Github. It will be really faster. Find instruction here. Your change just fixes a bug and does not break compatibility with previous version, so I recommend you to make pull request to branch 2.4.
I might do that, but it's not clear to me whether this will break other things that actually use the analyze duration period. For even faster startup time, I set the period to zero, and this seems to work just fine for live video streams (which don't have a duration anyways). I don't have any other video files around to test this on, however, and it's not clear to me what kinds of bugs it could provoke.
I investigate the issue and solution you proposed. FFMPEG uses this period of time to wait for camera initialization and to analyze stream parameters. You fix decrease this time and can break compatibility with other cameras that are very slow. The only solution applicable here is custom VideoCapture parameter for ffmpeg+ip camera case. Alternatively, you can change encoding format from mjpeg to something else. It decrease initialization time in most cases.
- Difficulty set to Easy