[FFmpeg-trac] #5598(avcodec:reopened): image2pipe disruption and OOM crash on BMP sequences with certain pixel values
FFmpeg
trac at avcodec.org
Sun Jun 5 01:00:17 CEST 2016
#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
More information about the FFmpeg-trac
mailing list