@@ -56,6 +56,8 @@ static int is_animated_webp_packet(AVPacket *pkt)
int skip = 0;
unsigned flags = 0;
+ if (!pkt->size)
+ return 0;
if (pkt->size < 4)
return AVERROR_INVALIDDATA;
if (AV_RL32(pkt->data) == AV_RL32("RIFF"))
@@ -145,8 +147,6 @@ static int webp_write_packet(AVFormatContext *s, AVPacket *pkt)
WebpContext *w = s->priv_data;
int ret;
- if (!pkt->size)
- return 0;
ret = is_animated_webp_packet(pkt);
if (ret < 0)
return ret;
@@ -159,7 +159,8 @@ static int webp_write_packet(AVFormatContext *s, AVPacket *pkt)
int ret;
if ((ret = flush(s, 0, pkt->pts)) < 0)
return ret;
- av_packet_ref(&w->last_pkt, pkt);
+ if (pkt->size > 0)
+ av_packet_ref(&w->last_pkt, pkt);
}
++w->frame_count;
Before f9043de99a23e35a34c79bfbc9ef17b27f7236d1, sending zero-sized packets to the WebP muxer led to memleaks (unless the muxer was already in animation mode). Therefore said commit simply returned immediately if such a packet were sent to the muxer. But now it turns out that such packets are not that irregular; in particular, one needs to account for them in the frame count. This patch achieves this by treating such packets the same way that they were treated before f9043de99a23e35a34c79bfbc9ef17b27f7236d1 with the only difference that they are not cached (and can therefore not leak). Fixes ticket #9179. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> --- There is btw a big leak left in the encoder; I wonder whether we are properly closing the library. libavformat/webpenc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)