[FFmpeg-trac] #5598(avcodec:new): image2pipe disruption and OOM crash on BMP sequences with certain pixel values

[FFmpeg]

#5598: image2pipe disruption and OOM crash on BMP sequences with certain pixel
values
-------------------------------------+-------------------------------------
             Reporter:  CoJaBo       |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  important    |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  bmp          |               Blocked By:
  regression                         |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by CoJaBo):

 Replying to [comment:1 cehoyos]:
 > Is {{{-f image2pipe}}} necessary to reproduce? I ask because generally
 forcing an input format can make a ticket less important.

 It actually is not required; testing without it, I see that ffmpeg auto-
 detects the format as bmp_pipe instead of image2pipe, but this still
 exhibits the described bug.

 > > If such a frame occurs in the middle of a large input stream, upon
 hitting it ffmpeg will stop producing output and attempt to read the
 remainder of the input stream into RAM until it runs out of memory and
 dies.
 >
 > How can I reproduce this?

 Just repeat the blank frame until the input stream won't fit in RAM;
 here's a one-liner to do this (increase 500 as needed):

 {{{
 (cat blank.bmp error.bmp; for i in `seq 1 500`; do cat blank.bmp; done;) |
 ffmpeg -i - junk.mkv
 }}}

 For comparison, it works with only the blank frame, generating the
 expected 502 frames of output with no errors:

 {{{
 (cat blank.bmp blank.bmp; for i in `seq 1 500`; do cat blank.bmp; done;) |
 ffmpeg -i - junk.mkv
 }}}

 > So far you have reported that input exists for which the bmp parser is
 unable to produce correct output. This is a regression for the given input
 but it may be "wontfix" (because parsing bmp can be difficult).

 Should it be that difficult though? The size of the file including header
 is the 4 bytes at offset 0x02; once the format has been identified as BMP,
 ffmpeg should read that many bytes before expecting either another header
 or EOF. Instead, it seems to be continuously scanning for anything that
 appears to be another header; that's only a 2-byte sequence (BM), so it
 will inevitably happen.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5598#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker