Jeff Downs <[email protected]> added the comment: At one point (at least) in this file, a picture coding extension is being processed without having seen a (new) picture start code. The extension is changing s->picture_structure, which causes the (already allocated) picture to have the wrong linesize (and maybe other things that depend on picture_structure).
Dump of start codes at problem point of file: [mpeg2video @ 0x9033fe0]111 at 127146 left 337450 [mpeg2video @ 0x9033fe0]00 motion_type at 0 16 [mpeg2video @ 0x9033fe0]112 at 127157 left 337439 [mpeg2video @ 0x9033fe0]00 motion_type at 0 17 [mpeg2video @ 0x9033fe0]1BF at 127170 left 337426 [mpeg2video @ 0x9033fe0]1B5 at 127209 left 337387 [mpeg2video @ 0x9033fe0]101 at 127218 left 337378 [mpeg2video @ 0x9033fe0]102 at 127226 left 337370 [mpeg2video @ 0x9033fe0]invalid mb type in P Frame at 1 1 [mpeg2video @ 0x9033fe0]103 at 127234 left 337362 Seems as though we should be forcing picture reinitialization (and maybe output of the picture already being decoded) on changes to decoding parameters like this. Input on proper fix invited. ____________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/roundup/ffmpeg/issue487> ____________________________________________________
