[FFmpeg-trac] #5598(avcodec:reopened): 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:  reopened
             Priority:  important    |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  bmp          |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by CoJaBo):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 The fix above doesn't seem to have completely resolved the issue. Attached
 is another set of files that still exhibits the bug.

 The cause is more or less the same, ffmpeg is still looking for a BMP
 header located randomly in the image data-

 {{{
 00000000  42 4d 36 ec 5e 00 00 00  00 00 36 00 00 00 28 00
 |BM6.^.....6...(.|
 00000010  00 00 80 07 00 00 38 04  00 00 01 00 18 00 00 00
 |......8.........|
 00000020  00 00 00 ec 5e 00 00 00  00 00 00 00 00 00 00 00
 |....^...........|
 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
 *
 00137cb0  00 00 00 00 00 42 4d 51  39 44 47 2f 37 3d 16 1d
 |.....BMQ9DG/7=..|
 00137cc0  24 02 09 0e 00 00 00 00  00 00 00 00 00 00 00 00
 |$...............|
 00137cd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 |................|
 *
 005eec36
 }}}

 Any fix for this is going to need to actually correct that behavior and
 look for headers only after the end of the preceding file; I'm not sure
 from the diff if the previous patch attempted this or simply made the
 header check more strict. It goes without saying that BMP headers are
 loose enough to occur by chance every few minutes in HD video, and it
 undoubtedly gets worse at 4K.

 To reproduce:
 {{{
 (for i in `seq 1 3982`; do cat blank.bmp; done; cat error2.bmp;) | ffmpeg
 -i - -f null -
 }}}

 An error is generated this time, and the output is 3982 frames instead of
 the expected 3983.

 And here is the variant that causes an OOM crash (again, you'll need to
 increase {{{500}}} if you have more than about 4GB RAM):
 {{{
 (for i in `seq 1 3982`; do cat blank.bmp; done; cat error2.bmp; for i in
 `seq 1 500`; do cat blank.bmp; done;) | ffmpeg -i - -f null -
 }}}

 In both cases, I'm using {{{-f null}}} to speed things up (since we're
 reading nearly 25GB of data); using {{{ffmpeg -i - junk.mkv}}} as before
 will fail exactly the same way.


 As an aside, is there a way to have ffmpeg (or another OSS tool) generate
 a BMP stream? This would be much easier to exhaustively test if there
 were, as simply transcoding any 1080p or 4K video and feeding it to ffmpeg
 would replicate this very quickly.

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