Jeff Downs <[email protected]> added the comment:
Confirming that the issue is indeed caused by the changing of the picture
layout/decoding parameters, causing them to be out of sync with the current
picture. Subsequent decoding causes picture buffers to be overrun, resulting in
heap corruption.
A simplistic fix is not allowing rogue picture coding extensions to be processed
when not creating new pictures:
--- libavcodec/mpeg12.c (revision 19605)
+++ libavcodec/mpeg12.c (working copy)
@@ -1538,6 +1538,8 @@
s->current_picture.key_frame= s->pict_type == FF_I_TYPE;
s->first_slice= 1;
}
+ if (!s->first_slice)
+ return;
s->intra_dc_precision = get_bits(&s->gb, 2);
s->picture_structure = get_bits(&s->gb, 2);
s->top_field_first = get_bits1(&s->gb);
A more complete fix could be adding state-based control to the start code
processing loop. Pre-picture look at seq, gop, pic, extension headers, at first
slice, create picture buffer and from there only look at slices until the end of
the frame (as given by the parser, since decoder seems to depend on parsed input
already). This approach would prevent all decoding parameters from being changed
in the middle of decoding a picture. I could work on this but would like to hear
if it is preferred over the simplistic fix above, or if there are other ideas,
first.
----------
substatus: reproduced -> analyzed
____________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue487>
____________________________________________________
