FFmpeg/tests/ref/fate/matroska-lzo-decompression

#tb 0: 11337/500000000
#media_type 0: audio
#codec_id 0: pcm_s16le
#sample_rate 0: 44100
#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
avformat/matroskadec: Fix lzo decompression 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> 5 years ago			`#tb 0: 11337/500000000`
			`#media_type 0: audio`
			`#codec_id 0: pcm_s16le`
			`#sample_rate 0: 44100`
			`#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`