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>
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.
Refactoring copy_side_data into a separate function so that it can be called
in cases where side data needs to be duplicated.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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.
While we correctly "register" the side data when we split it,
the application (in this case FFmpeg) might not update the
AVPacket pool it uses to finally free the packet, thus
causing a leak.
This also makes the av_dup_packet unnecessary which could
cause an even worse leak in this situation.
Also change the code to not modify the user-provide AVPacket at all.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
p cannot be calculated before av_dup_packet since that one
might change avpkt->data, causing invalid reads and a
non-working range check.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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
Anton Khirnov
Michael Niedermayer
Roman Fietze
Ben Boeckel
Martin Storsjö
Vignesh Venkatasubramanian
Luca Barbato
Diego Biurrun
Clément Bœsch
Janne Grunau
Andrey Utkin
Mans Rullgard
Reimar Döffinger
Kostya Shishkov
Ramiro Polla
Thilo Borgmann