Keeping byte values read from the file as unsigned is consistent
with how they are subsequently used and avoids an undefined left
shift by 24 when bit 7 is set.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This changes so we assume EOF when we can't find the next
streams index entry for non interleaved file.
http://trac.xbmc.org/ticket/5585
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This uses the RIFF header stored size to figure out the expected AVI file size, instead
of the actual file. To work fully it requires handling failed avio_seek() instead
of assuming they always succeed.
Some fate file has been cut off and contains half a frame at the end which previously
was not output during demuxing. This frame is now output to encoder, thus fate
diff update.
It does not make sense (DV is interleaved by design) and
it avoids a crash when the non-interleaved code tries to
use the priv_data of streams created by the DV demuxer.
The crash could be avoided differently, but then that stream
would still lack an index and would not play correctly in
non-interleaved mode.
Fixes e.g. samples/ffmpeg-bugs/roundup/issue1514/Dennis0002_video1.avi
Official AVI specification says that stream header in case of video contains
BITMAPINFO, which is equal to BITMAPINFOHEADER and optional palette. Currently
lavf AVI demuxer thinks otherwise which produces garbage on codecs that have
both palette and extradata (luckily, there are not so many such codecs).
An example of such file is:
http://samples.multimedia.cx/V-codecs/KMVC/baseball1.avi
(IIRC, MSS1 or MSS2 also had such situation but they are still not supported
by lavc).
As a side note, passing palette in extradata as it's been done previously is
not quite correct since proper _extra_ data is surplus bytes in
BITMAPINFOHEADER, not including palette.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This enables non interleaved AVI mode for example.
Players that are picky on strict interleaving can set this.
Patches to only switch to non intereaved AVI mode when the index is not strictly
correctly interleaved are welcome.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
ff_get_wav_header is reading data from a WAVE file and then uses it
(without validation) to malloc a buffer. It then proceeded to read
data into the buffer, without verifying that the allocation succeeded.
To address this, change ff_get_wav_header to return an error if
allocation failed, and adapted all calling code to handle that error.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>