[FFmpeg-trac] #2343(avformat:new): Stream is blocked by 20 seconds or more when reading an mjpeg stream at low resolutions

[FFmpeg]

#2343: Stream is blocked by 20 seconds or more when reading an mjpeg stream at low
resolutions
-------------------------------------+------------------------------------
             Reporter:  virtuald     |                    Owner:
                 Type:  enhancement  |                   Status:  new
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+------------------------------------
Changes (by cehoyos):

 * priority:  normal => wish
 * type:  defect => enhancement
 * version:  1.1.3 => git-master
 * component:  undetermined => avformat


Comment:

 Replying to [ticket:2343 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.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2343#comment:1>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker