mirror of https://github.com/FFmpeg/FFmpeg.git
When a Matroska Block is only stored in compressed form, the size of
the uncompressed block is not explicitly coded and therefore not known
before decompressing it. Therefore the demuxer uses a guess for the
uncompressed size: The first guess is three times the compressed size
and if this is not enough, it is repeatedly incremented by a factor of
three. But when this happens with lzo, the decompression is neither
resumed nor started again. Instead when av_lzo1x_decode indicates that x
bytes of input data could not be decoded, because the output buffer is
already full, the first (not the last) x bytes of the input buffer are
resent for decoding in the next try; they overwrite already decoded
data.
This commit fixes this by instead restarting the decompression anew,
just with a bigger buffer.
This seems to be a regression since 935ec5a1
.
A FATE-test for this has been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
pull/331/head
parent
6c735b96ee
commit
2ff687c17f
3 changed files with 16 additions and 1 deletions
@ -0,0 +1,10 @@ |
||||
#tb 0: 11337/500000000 |
||||
#media_type 0: audio |
||||
#codec_id 0: pcm_s16le |
||||
#sample_rate 0: 44100 |
||||
#channel_layout 0: 3 |
||||
#channel_layout_name 0: stereo |
||||
0, 0, 0, 4096, 16384, 0x00000000 |
||||
0, 4096, 4096, 4096, 16384, 0xad7eebf4 |
||||
0, 8192, 8192, 4096, 16384, 0x1d1ff9d9 |
||||
0, 12288, 12288, 4097, 16384, 0xf1d9e2e2 |
Loading…
Reference in new issue