As indicated in the function documentation, the header MUST be
checked prior to calling it because no consistency check is done
there.
CC:libav-stable@libav.org
(cherry picked from commit f2f2e7627f)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Instead of using a fixed bitrate_idx, calculate a matching bitrate for
the XING header.
Using a fixed bitrate_idx causes tools such as file(1) and mediainfo(1)
to report wrong bitrate and bitrate mode when using CBR.
Bug-Id: https://bugs.debian.org/736088
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 617a1a98a6)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 0f6e309b97)
It is my understanding that "Unless otherwise stated, all data in a
QuickTime movie is stored in big-endian byte ordering" [1] in MOV files.
I have a couple of thousand files, which technically are invalid because
their sound sample description element 4CC is 'lpcm' but its version is
0 - and "Version 0 supports only uncompressed audio in raw ('raw ') or
twos-complement ('twos') format" [2]
Because isom.c only contains a mapping for 4CC 'lpcm' to
AV_CODEC_ID_PCM_S16LE, these files have their audio decoded as LE when
it is actually BE.
This commit adds AV_CODEC_ID_PCM_S16BE as the first match for 4CC 'lpcm'.
[1]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 21
[2]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 178
Reviewed-by: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>
(cherry picked from commit 360022bd3b)
(cherry picked from commit d37fac6dbb)
The correct point that seperates ISO and MAC language codes is 0x400
according to the current QT spec. Old QT specs did not list where this
seperation is but apparently only defined the meaning of the first 137.
(cherry picked from commit 9e71cc81f3)
(cherry picked from commit 7940306a47)
Previously, if read_connect failed, the ret variable was unmodified
and had the value 0, indicating success, which then was returned from
the rtmp_open function, even though it actually failed.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 6477139721)
It could probably also be considered an error if the pointer isn't
null at this point, but then we might risk rejecting some
slightly broken files that we might have handled so far.
Sample-Id: 00000496-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 2620df1310)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
These arrays are normally freed at the end of mov_read_trak,
but make sure they're freed in case mov_read_trak returned
early (due to errors) or in case the atoms that allocate arrays
are encountered at some other point than within a trak (which
we don't have checks against).
Sample-Id: 00000496-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit d51f09962d)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Always use the actually read size as the offset instead of making
possibly invalid assumptions.
Addresses: CVE-2012-6618
(cherry picked from commit 2115a35974)
Conflicts:
libavformat/utils.c
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It might be passed to code requiring padding, such as lzo decompression.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 30be1ea33e)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
When the protocol is missing ffurl_alloc() should return
AVERROR_PROTOCOL_NOT_FOUND instead of AVERROR(ENOENT).
Bug-Id: 577
CC: libav-stable@libav.org
(cherry picked from commit ea71aafd68)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
The code cannot handle there being none, but that should not happen for
valid files.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
(cherry picked from commit 1b5d065ca7)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Abort if it is invalid if strict error checking has been requested.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 0f310a6f33)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Conflicts:
libavformat/rmdec.c
This makes sure errors in setting stream parameters are passed
on to the caller. This avoids successfully opening files while
some parameters aren't filled in properly.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit cc41167aed)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This avoids setting a negative number of frames, ending up with a
negative average frame rate.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit c231987662)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If a zero-length video packet is to be returned, just return
AVERROR(EAGAIN) and switch back to the audio stream.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 9fc7184d1a)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This avoids divisions by zero later (and possibly assertions in
time base scaling), since an invalid rate_flag combined with an
invalid bitrate below could pass the mode combination test.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 9277050e29)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Justin Ruggles