Since commit 979b5b89594c7628bd846c63198cb64ef9d81d16, reverting the Matroska ContentCompression is no longer done inside matroska_parse_frame() (the function that creates AVPackets out of the parsed data (unless we are dealing with certain codecs that need special handling)), but instead in matroska_parse_block(). As a consequence, the data that matroska_parse_frame() receives is no longer always owned by an AVBuffer; it is owned by an AVBuffer iff no ContentCompression needed to be reversed; otherwise the data is independently allocated and needs to be freed on error.
Whether the data is owned by an AVBuffer or not is indicated by a variable buf of type AVBufferRef *: If it is NULL, the data is independently allocated, if not it is owned by the underlying AVBuffer (and is used to avoid copying the data when creating the AVPackets). Because the allocation of the buffer holding the uncompressed data happens outside of matroska_parse_frame() (if a ContentCompression needs to be reversed), the data is passed as uint8_t ** in order to not leave any dangling pointers behind in matroska_parse_block() should the data need to be freed: In case of errors, said uint8_t ** would be av_freep()'ed in case buf indicated the data to be independently allocated. Yet there is a problem with this: Some codecs (namely WavPack and ProRes) need special handling: Their packets are only stored in Matroska in a stripped form to save space and the demuxer reconstructs full packets. This involved allocating a new, enlarged buffer. And if an error happens when trying to wrap this new buffer into an AVBuffer, this buffer needs to be freed; yet instead the given uint8_t ** (holding the uncompressed, yet still stripped form of the data) would be freed (av_freep()'ed) which certainly leads to a memleak of the new buffer; even worse, in case the track does not use ContentCompression the given uint8_t ** must not be freed as the actual data is owned by an AVBuffer and the data given to matroska_parse_frame() is not the start of the actual allocated buffer at all. Both of these issues are fixed by always freeing the current data in case it is independently allocated. Furthermore, while it would be possible to track whether the pointer from matroska_parse_block() needs to be reset or not, there is no gain in doing so, as the pointer is not used at all afterwards and the sematics are clear: If the data passed to matroska_parse_frame() is independently allocated, then ownership of the data passes to matroska_parse_frame(). So don't pass the data via uint8_t **. Fixes Coverity ID 1462661 (the issue as described by Coverity is btw a false positive: It thinks that this error can be triggered by ProRes with a size of zero after reconstructing the original packets, but the reconstructed packets can't have a size of zero). Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> --- Sorry for this. Will push this soon if no one objects. I would really appreciate another pair of eyes looking over this. Coverity ID 610554 is btw a false positive stemming from Coverity not knowing that the packet data is always owned by an AVBuffer when ContentCompression is not in use. libavformat/matroskadec.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index 917c106258..24104837a5 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -3414,13 +3414,13 @@ static int matroska_parse_webvtt(MatroskaDemuxContext *matroska, static int matroska_parse_frame(MatroskaDemuxContext *matroska, MatroskaTrack *track, AVStream *st, - AVBufferRef *buf, uint8_t **data, int pkt_size, + AVBufferRef *buf, uint8_t *data, int pkt_size, uint64_t timecode, uint64_t lace_duration, int64_t pos, int is_keyframe, uint8_t *additional, uint64_t additional_id, int additional_size, int64_t discard_padding) { - uint8_t *pkt_data = *data; + uint8_t *pkt_data = data; int res = 0; AVPacket pktl, *pkt = &pktl; @@ -3432,7 +3432,7 @@ static int matroska_parse_frame(MatroskaDemuxContext *matroska, goto fail; } if (!buf) - av_freep(data); + av_free(data); buf = NULL; } @@ -3445,7 +3445,7 @@ static int matroska_parse_frame(MatroskaDemuxContext *matroska, goto fail; } if (!buf) - av_freep(data); + av_free(data); buf = NULL; } @@ -3525,7 +3525,7 @@ FF_ENABLE_DEPRECATION_WARNINGS no_output: fail: if (!buf) - av_freep(data); + av_free(pkt_data); return res; } @@ -3659,7 +3659,7 @@ static int matroska_parse_block(MatroskaDemuxContext *matroska, AVBufferRef *buf if (res) return res; } else { - res = matroska_parse_frame(matroska, track, st, buf, &out_data, + res = matroska_parse_frame(matroska, track, st, buf, out_data, out_size, timecode, lace_duration, pos, !n ? is_keyframe : 0, additional, additional_id, additional_size, -- 2.20.1 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".