Ronald S. Bultje <rsbul...@gmail.com> added the comment: I see the behaviour. The stream is ... dysfunctional at best. It's probably supported, because there's code in the decoder for handling this, but lacking a test-case it broke.
Stream #0.0: Video: rawvideo, yuv420p, 960x544, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding Reinit <- called when tables are inited with size 960x544 Deinit <- called when free_tables() is called because of size change Reinit <- reinit with different size 1920x1088 [h264 @ 0x101014200] mb_type -1 in I slice too large at 0 0 [h264 @ 0x101014200] error while decoding MB 0 0 [h264 @ 0x101014200] concealing 8160 DC, 8160 AC, 8160 MV errors Input Stream #0.0 frame size changed to 1920x1088, yuv420p bash-3.2$ What happens is that the tables are not cleaned up correctly or not reinitialized correctly or some variables not cleaned up from the old state. I have to look further as for what it all means, but I just wanted to say that the stream is messy. ________________________________________________ FFmpeg issue tracker <iss...@roundup.ffmpeg.org> <https://roundup.ffmpeg.org/issue2393> ________________________________________________