[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            |
-------------------------------------+------------------------------------

Comment (by virtuald):

 Replying to [comment:1 cehoyos]:
 > 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?

 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.

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