Ronald S. Bultje <[email protected]> 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 <[email protected]>
<https://roundup.ffmpeg.org/issue2393>
________________________________________________
