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>
* commit '31c51f7441de07b88cfea2550245bf1f5140cb8f':
avpacket: add a function for wrapping existing data as side data
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a9a60106370f862e191dea58e748626da6a8fe97':
avpacket: Provide an alloc and a free function for the struct
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '948f3c19a8bd069768ca411212aaf8c1ed96b10d':
lavc: Make AVPacket.duration int64, and deprecate convergence_duration
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Note that convergence_duration had another meaning, one which was in
practice never used. The only real use for it was a 64 bit replacement
for the duration field. It's better just to make duration 64 bits, and
to get rid of it.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '01bcc2d5c23fa757d163530abb396fd02f1be7c8':
lavc: Drop deprecated destruct_packet related functions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The stats are a superset of the quality factor, also allowing the picture type and encoder "PSNR" stats to be exported
This also replaces the native by fixed little endian order for the affected side data
AV_PKT_DATA_QUALITY_FACTOR is left as a synonym of AV_PKT_DATA_QUALITY_STATS
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '874390e163427c1fe7682ab27924a7843780dbb3':
lavc: add a convenience function for rescaling timestamps in a packet
Conflicts:
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cdf58f0599c39852ee3beafe5f64af7d57d4215b':
avpacket: fix copying side data in av_packet_copy_props()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Side data count is incremented by by calling av_packet_new_side_data()
in the following loop, setting it explicitly results in the resulting
value being twice what it should be.
CC: libav-stable@libav.org
This code changes the input packet, which is read only and can in
rare circumstances lead to decoder errors. (i run into one of these in
the audio decoder, which corrupted the packet during av_find_stream_info()
so that actual decoding that single packet failed later)
Until a better fix is implemented, this commit limits the problem.
A better fix might be to make the subtitle decoders not depend on
data[size] = 0 or to copy their input when this is not the case.
These functions are intended for use with side_data which comes in an
AVPacket.
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Reviewed-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously the wrong buffer pointer was checked, when buf
instead of *buf was checked. But checking the return value
instead is even better.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
* commit '7950e519bb094897f957b9a9531cc60ba46cbc91':
Disable deprecation warnings for cases where a replacement is available
Conflicts:
libavcodec/avpacket.c
libavcodec/pthread.c
libavcodec/utils.c
libavdevice/v4l2.c
libavfilter/avfiltergraph.c
libavfilter/buffersrc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The padding data is assumed to be 0 in several places, notably in
subtitles. This problem was not detected with fate-sub-srt test because
the first element of the side data (x1) is 0 in the test, so the
trailing side data present in the packet wasn't read by the decoder. The
issue can be observed with a large enough x1.
It is also noted in FF_INPUT_BUFFER_PADDING_SIZE doxy that MPEG
bitstreams require that padding with 0, so it might fix other issues.