@@ -7766,6 +7766,19 @@ static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
}
return ret;
}
+#if CONFIG_DV_DEMUXER
+ if (mov->dv_demux && sc->dv_audio_container) {
+ AVBufferRef *buf = pkt->buf;
+ ret = avpriv_dv_produce_packet(mov->dv_demux, pkt, pkt->data, pkt->size, pkt->pos);
+ pkt->buf = buf;
+ av_packet_unref(pkt);
+ if (ret < 0)
+ return ret;
+ ret = avpriv_dv_get_packet(mov->dv_demux, pkt);
+ if (ret < 0)
+ return ret;
+ }
+#endif
if (sc->has_palette) {
uint8_t *pal;
@@ -7777,16 +7790,6 @@ static int mov_read_packet(AVFormatContext *s, AVPacket *pkt)
sc->has_palette = 0;
}
}
-#if CONFIG_DV_DEMUXER
- if (mov->dv_demux && sc->dv_audio_container) {
- avpriv_dv_produce_packet(mov->dv_demux, pkt, pkt->data, pkt->size, pkt->pos);
- av_freep(&pkt->data);
- pkt->size = 0;
- ret = avpriv_dv_get_packet(mov->dv_demux, pkt);
- if (ret < 0)
- return ret;
- }
-#endif
if (st->codecpar->codec_id == AV_CODEC_ID_MP3 && !st->need_parsing && pkt->size > 4) {
if (ff_mpa_check_header(AV_RB32(pkt->data)) < 0)
st->need_parsing = AVSTREAM_PARSE_FULL;
The code for demuxing DV audio predates the introduction of refcounted packets and when the latter was added, changes to the former were forgotten. This meant that when avpriv_dv_produce_packet initialized the packet containing the AVBufferRef, the AVBufferRef as well as the underlying AVBuffer leaked; the actual packet data didn't leak: They were directly freed, but not via their AVBuffer's free function. Moreover, errors in avpriv_dv_produce_packet were ignored; this has been changed, too. Furthermore, in the hypothetical scenario that the track has a palette, this would leak, too, so reorder the code so that the palette code appears after the DV audio code. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> --- Completely untested as I don't have a sample for it. I also don't think that a dv audio stream can have a palette, but better safe than sorry. libavformat/mov.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)