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 <[email protected]> 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 <[email protected]> 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 [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
