[FFmpeg-devel] [libav-user] Memory errors when decoding mixed-resolution video streams

[Haakon Riiser]

The memory error described in the quoted part below was first
posted on libav-user.  The bug can be reproduced using the
ffmpeg tool, so I hope the Cc to <ffmpeg-devel at mplayerhq.hu>
is appropriate.

A tiny test clip can be downloaded here:
http://iad.project.ifi.uio.no/tmp/mixed_res_sample.zip

The ZIP file contains three files: mixed_res.ts, segment1.ts
and segment2.ts (segment1.ts is a 448x240 clip, segment2.ts
is 640x336, and mixed_res.ts is simply the two segments concatenated
together).

Using valgrind, I can reproduce the memory errors by

  valgrind ffmpeg -i mixed_res.ts -an -f rawvideo - >/dev/null

Running the same test on segment1.ts and segment2.ts separately
produces zero errors.

Currently confirmed this on Fedora 12 (x86_64).

-hr

-----Original Message-----
From: Haakon Riiser <haakon.riiser at fys.uio.no>
Sent: Tue, Sep 14, 2010 at 03:04:19PM +0200

I'm trying to decode some MPEG-2 TS streams containing H.264 video.
The video stream is made completely by closed GOPs (that is, all
frame references stay within the GOP boundary).  This means that any
GOP can be decoded independently of others, and so the resolution
can change from one GOP to the next.

I do not know in advance when a resolution change will occur, since
that information is not encoded in the MPEG-2 TS container, only
in the H.264 bitstream, which I do not parse in my application.

On the surface, libavcodec handles this scenario just fine:
I can call

  avcodec_decode_video(&avcodeccontext, &avframe, data, data_size)
  
without knowing if the resolution has changed since the last call,
and libavcodec happily produces frames in the correct resolution.
On return of this function, I can test avcodeccontext.width and
avcodeccontext.height to determine how big the decoded picture was.

Things were looking good until I randomly started seeing strange
artifacts on decoding.  I ran the program through valgrind, and
found that libavcodec generates *thousands* of memory errors
immediately when the resolution changes.

Here are some examples of errors (using FFmpeg 0.6):

==8741== Invalid read of size 4
==8741==    at 0x4D83C08: decode_slice_header (bswap.h:42)
==8741==    by 0x4D8D0C2: decode_nal_units (h264.c:2820)
==8741==    by 0x4D8DA31: decode_frame (h264.c:2981)
==8741==    by 0x4F3B904: avcodec_decode_video2 (utils.c:611)
==8741==    by 0x4F3C6CE: avcodec_decode_video (utils.c:597)
...
==8741==  Address 0x6032351 is 1 bytes inside a block of size 25,280 free'd
==8741==    at 0x4A04D72: free (vg_replace_malloc.c:325)
==8741==    by 0x5B202CB: av_freep (mem.c:153)
==8741==    by 0x4D81969: free_tables (h264.c:672)
==8741==    by 0x4D838DA: decode_slice_header (h264.c:1805)
==8741==    by 0x4D8D0C2: decode_nal_units (h264.c:2820)
==8741==    by 0x4D8DA31: decode_frame (h264.c:2981)
==8741==    by 0x4F3B904: avcodec_decode_video2 (utils.c:611)
==8741==    by 0x4F3C6CE: avcodec_decode_video (utils.c:597)
...

I tried various different FFmpeg snapshots, and the same thing
happens.  Is this a bug, or do I need to prepare libavcodec for
the resolution change somehow?

(I can provide a minimal test application and a sample video clip
if that helps.  Don't have it ready right now, though.)

-- 
 Haakon
_______________________________________________
libav-user mailing list
libav-user at mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/libav-user