Stream is blocked by 20 seconds or more when reading an mjpeg stream at low resolutions

[Dustin Spicuzza]

When opening a network-based mjpeg stream from an AXIS M1011 camera, the stream doesn't actually get opened 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.

How to reproduce:

% ffmpeg -i http://192.168.0.10/mjpg/video.mjpg

The problem shows up on version 1.1.3 on Windows (32-bit) and Linux (64-bit).

It also shows up on the version installed on my Ubuntu box by default, 0.8.5-6:0.8.5-0ubuntu0.12.10.1.

Note that in the logfile I attached, it hangs right before the line "[mjpeg @ 0x1016500] max_analyze_duration 5000000 reached at 5000000" for about 25 seconds or so. And yes, it ends in an error saying that there is no output file, but an output file isn't necessary to illustrate the issue. The point is that it hangs. :)

I originally found this issue when using OpenCV, but the ffmpeg executable has the same problem. I was able to remove the delay in OpenCV by setting max_analyze_duration to 50000 on the context. However, it seems like the default setting should just work.

Reference: ​http://code.opencv.org/issues/2877

[Dustin Spicuzza]

Debug logfile

[Carl Eugen Hoyos]

Replying to virtuald:

The problem shows up on version 1.1.3 on Windows (32-bit) and Linux (64-bit).

Am I correct that you get the same problem with current git head?

It also shows up on the version installed on my Ubuntu box by default, 0.8.5-6:0.8.5-0ubuntu0.12.10.1.

(This is an intentionally broken version of FFmpeg that is not supported here.)

Note that in the logfile I attached, it hangs right before the line "[mjpeg @ 0x1016500] max_analyze_duration 5000000 reached at 5000000" for about 25 seconds or so. And yes, it ends in an error saying that there is no output file, but an output file isn't necessary to illustrate the issue. The point is that it hangs. :)

(As your post explains, it does not hang, it waits for 5000000 ms of audio/video data because you did not specify another value on the command line.)

I originally found this issue when using OpenCV, but the ffmpeg executable has the same problem. I was able to remove the delay in OpenCV by setting max_analyze_duration to 50000 on the context. However, it seems like the default setting should just work.

How should FFmpeg know that you are playing a stream with a very uncommon low bitrate before looking into the stream (for the duration to analyze that you specify on the command line, if you don't specify it, the default rate - which is very low for many real-world streams - will be used)?

Reducing the default value for -analyzeduration seems unacceptable to me.
Maybe an additional option -analyze_real_world_duration could be implemented.

[DonMoir]

I found with IP cameras, there can be a long delay on open. Generally speaking, each IP camera has it's own best way of opening and sometimes multiple ways of opening for same camera. There are some generic types like: rtsp:// ​http:// These URL's are good enough for basic playback but allow no additional control like pan,tilt,zoom (PTZ) and can introduce an unwanted delay. I am finding it necessary to provide a special open call for IP cameras. For testing I am setting max_analyze_duration to 0. In the case of the camera I am testing with, I know it's mjpeg, how to control PTZ, etc. So it boils down to 'knowing' the camera. There have been some attempts to formalize but its not complete. The IP camera interfaces are all over the place.

I have a long way to go on the above, but one thing for sure is I don't want delayed video for a real time LAN based camera. For testing, I ignore all timing and display the frames as fast as they arrive. The timing itself is not to much of an issue, but the initial delay can throw things way off in terms of seeing real time video. Like if I wave my hand in front of the camera I want to see it as soon as possible and not 5 to 10 seconds later.

A generic open in this case is just not going to work well.

[Dustin Spicuzza]

Replying to cehoyos:

Replying to virtuald:

The problem shows up on version 1.1.3 on Windows (32-bit) and Linux (64-bit).

Am I correct that you get the same problem with current git head?

I presume, I haven't tested it yet. I'll try testing it in the near future.

It also shows up on the version installed on my Ubuntu box by default, 0.8.5-6:0.8.5-0ubuntu0.12.10.1.

(This is an intentionally broken version of FFmpeg that is not supported here.)

Yes, I realize that it isn't supported. The primary reason to point it out here is that since this is a quite old version, the problem has probably existed for a long time.

Note that in the logfile I attached, it hangs right before the line "[mjpeg @ 0x1016500] max_analyze_duration 5000000 reached at 5000000" for about 25 seconds or so. And yes, it ends in an error saying that there is no output file, but an output file isn't necessary to illustrate the issue. The point is that it hangs. :)

(As your post explains, it does not hang, it waits for 5000000 ms of audio/video data because you did not specify another value on the command line.)

How should FFmpeg know that you are playing a stream with a very uncommon low bitrate before looking into the stream (for the duration to analyze that you specify on the command line, if you don't specify it, the default rate - which is very low for many real-world streams - will be used)?

Reducing the default value for -analyzeduration seems unacceptable to me.
Maybe an additional option -analyze_real_world_duration could be implemented.

Yes you're right, it's waiting as opposed to hanging. However, it appears that the intent of the max_analyze_duration parameter is to specify a wait for 5 seconds (5000000 us), and then exit. This seems like a reasonable enough default (though it would be nicer if it detected [perhaps via the codec or whatever other information it has?] that the stream didn't end, and delay less than a second), but as I said it actually delays 30 seconds, which is definitely much less acceptable. I suppose that is the real bug here, though I'm not quite sure where the bug actually resides.

[Carl Eugen Hoyos]

Does it help if you specify a value for -probesize ?

[Andrey Utkin]

It may take too long because MJPEG streams don't include timestamps, and by default they are generated by ffmpeg like there's 25 FPS.
Try ffmpeg -use_wallclock_as_timestamps 1 -i ​http://...
Try ffmpeg -f mjpeg -use_wallclock_as_timestamps 1 -i ​http://...
Try ffmpeg -f mjpeg -i ​http://...

Try also -probesize 32 -analyzeduration 0 or something like that to reduce probing period.

[Michael Niedermayer]

can you post the mjpeg stream dumped with tools/aviocat
i dont think anything can be done without the stream or the camera