In many older QuickTime files, the audio format, or "fourcc", is
0x00000000. The QuickTime File Format Specification states the following
regarding this situation:
"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."
MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In many older QuickTime files, the audio format, or "fourcc", is
0x00000000. The QuickTime File Format Specification states the following
regarding this situation:
"This format descriptor should not be used, but may be found in some
files. Samples are assumed to be stored in either 'raw ' or 'twos'
format, depending on the sample size field in the sound description."
MPlayer handles this logic by itself, but FFmpeg/FFplay currently does
not.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the spirit of commit a956840cbc. Simple method to reproduce:
pass -vstats_file /dev/full to ffmpeg.
All raw fclose usages in ffmpeg.c taken care of here.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is faster; precision assured as result is a float.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Use two separate functions, depending on whether VFP/NEON is available.
This is set to require armv5te - it uses blx, which is only available
since armv5t, but we don't have a separate configure item for that.
(It also uses ldrd, which requires armv5te, but this could be avoided
if necessary.)
Signed-off-by: Martin Storsjö <martin@martin.st>
The previous check only caught sizes from -AV_INPUT_BUFFER_PADDING_SIZE
to -1.
This fixes ubsan runtime error: signed integer overflow: 2147483647 + 32
cannot be represented in type 'int'
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Both avio_skip and detect_unknown_subobject use int64_t for the size
parameter.
This fixes a segmentation fault due to infinite recursion.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Alexandra Hájková <alexandra.khirnova@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Otherwise invalid values are used unchecked in the next run.
This can cause NULL pointer dereferencing.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Alexandra Hájková <alexandra.khirnova@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes out of array read
Fixes: test_case-mdc.264 (b47be15a120979f5a1a945c938cbef33)
Found-by: Tyson Smith <twsmith@mozilla.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. The stagefright "API" is not public, and the
MediaCodec API is the proper way to do this.
Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.
[1] http://stackoverflow.com/a/29362353/3115956
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
sqrt is faster, and is sometimes more accurate depending on the libm.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
avio_closep is not guaranteed to succeed, and its return value can
contain information regarding failure of preceding writes and silent
loss of data (man 2 close, man fclose). Users should know when the
progress was not successfully logged, and so a diagnostic is printed
here.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The previous check only caught sizes from -AV_INPUT_BUFFER_PADDING_SIZE
to -1.
This fixes ubsan runtime error: signed integer overflow: 2147483647 + 32
cannot be represented in type 'int'
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Otherwise this can have some surprising effects (crashes), so let's
better not allow it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
