This mimics the behaviour of other av_*_new_side_data().
This is not caught by the malloc check, since padding
is always added to the allocated size.
Signed-off-by: Vittorio Giovara <vittorio.giovara@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'
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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>
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
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>
Freeing it in av_destruct_packet(), as is done currently, would mean
that we allow it to be allocated with other means. But that would make
av_packet_new_side_data() unsafe.
Side data is not expected to be large, so copying it if required
shouldn't be a problem.
Some code does call av_free_packet() on failed av_new_packets(), this
prevents the freeing of uninitialized pointers.
Originally committed as revision 20801 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVPacket structure now resides also.
Patch by Thilo Borgmann thilo.borgmann googlemail com, see the mailinglist
thread "Google Summer of Code participation" for additional discussion.
Originally committed as revision 18353 to svn://svn.ffmpeg.org/ffmpeg/trunk