* commit 'd719981273bc779c7d1e879d88404fd867f93a0e':
4xm: Check that the read track value is non-negative
Conflicts:
libavformat/4xm.c
See: 0838cfdc8a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5bcd3ae5b167fb74215520b01d5d810e0c8986ab':
matroskadec: Check that .lang was allocated and set before reading it
Conflicts:
libavformat/matroskadec.c
See: 01fd1aa0ad
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This ensures that no read timestamp functions finds packets before the search window in ff_find_last_ts()
which could cause an infinite loop
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes an infinite loop
An alternative fix would be to revert d73cbc22c5
but that would worsen error resilience.
Found-by: Justin Ruggles
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
On openbsd the exif-image-jpg test fails but diff treats the files as
binary due to some non ascii symbols in them. This should force it to
treat them as text, which should result in more informative output
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Otherwise buffer size calculations in allocate_buffers could
overflow later, making the code think a large enough buffer
actually was allocated.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Skip the "\r" as normal text. Otherwise it will be the first character
of the string passed to sscanf(), which then fill fail to match the
timestamps.
Signed-off-by: Clément Bœsch <u@pkh.me>
* commit '488b2984fece7ad0c2596826fee18e74aa904667':
ape demuxer: check for EOF in potentially long loops
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a7c1689dedd11689edb30088d467ac03f9b8d1cf':
4xm: check that bits per sample is strictly positive
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The check added in df33a58e53 does not work
at all, rather it broke the summing of bitrates completely.
The comparission was wrong way around.
This commit replaces it by a simpler and hopefully clearer check
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fab694dd3931b1c0bc3c598c3f88b1902c14a303':
lavf: move a variable declaration to the block where it's used
Conflicts:
libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fe9bb61f9a16be19ad91875632c39e44b7a99a8a':
pictordec: pass correct context to avpriv_request_sample
Conflicts:
libavcodec/pictordec.c
No change as the avpriv_request_sample() has already been replaced by an implementation
of the codepath.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5f7aecde02a95451e514c809f2794c1deba80695':
pictordec: break out of both decoding loops when y drops below 0
Conflicts:
libavcodec/pictordec.c
The added check is redundant.
It shows the error path more clearly though
See: f3f488423a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This should improve write performance quite significantly.
---
Tested with both writing a normal mp4, by using the faststart
feature and writing a fragmented mp4 file; all turn out with the
same md5sum as before.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes Ticket2896
An alternative to this would be to change the code to support any
stride.
The condition of differing strides should be rare.
If theres no speedloss supporting any stride would be better
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixing av_packet_copy_side_data to work correctly when source and
destination are the same. This makes sure that there is no memory
leak and double frees.
Signed-off by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Otherwise picmemset can get called with negative y, resulting in an
invalid write.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
