Stream is blocked by 20 seconds or more when reading an mjpeg stream at low resolutions (Bug #2877)

Added by Dustin Spicuzza over 1 year ago. Updated 9 months ago.

Status:Open Start date:2013-03-10
Priority:Normal Due date:
Assignee:Alexander Smorkalov % Done:


Target version:Next Hackathon
Affected version:2.4.0 - 2.4.5 Operating System:Any
Difficulty:Easy HW Platform:Any
Pull request:


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()'')   # 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.

Related issues (Add)


Updated by Dustin Spicuzza over 1 year ago

Note that the stream is coming from an AXIS M1011 camera.

Updated by Dustin Spicuzza over 1 year ago

I filed a bug at FFMpeg also:

Updated by Alexander Smorkalov over 1 year ago

Good Job!
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.

Updated by Dustin Spicuzza over 1 year ago

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.

Updated by Andrey Kamaev over 1 year ago

  • Target version changed from 2.4.5 to Next Hackathon

Updated by Daniel Angelov about 1 year ago

I can confirm that this problem(delay) still exists in using the C++ bindings. The delay is inverse proportional to the size of the image - 1600x1200 is around 4 sec.

Updated by Victor Kocheganov about 1 year ago

  • Affected version changed from 2.4.4 to 2.4.0 - 2.4.5
  • Operating System set to Any
  • HW Platform set to Any
  • Assignee changed from Vadim Pisarevsky to Alexander Smorkalov

Updated by Alexander Smorkalov about 1 year ago

Hello Dustin!

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

Updated by Dustin Spicuzza 9 months ago

Hey Alexander,

The last time I looked, there wasn't a custom parameter available to tune this setting. It would be great if we could add one.


Also available in: Atom PDF