image2pipe reads two bmp images in one packet

[trebartha]

Summary of the bug: I am piping 241 bmp images to ffmpeg. Image2pipe consistently reads images 00089 & 00090 together in the one packet with the result that 00090 is not sent to the output and a total of only 240 frames are rendered.

How to reproduce: Unzip the attached set of images. Run:

cat render*.bmp | ffmpeg -y -v 9 -loglevel 99 -dump -report -thread_queue_size 100 -f image2pipe -framerate 1 -i - -f null -

This example command doesn't produce any output but the log shows where the problem is. The full log is attached, but I've included this pertinent section which shows that packet with pts 89 was read with precisely double the number of bytes of all of the other packets:

stream #0:
  keyframe=1
  duration=1.000
  dts=88.000  pts=88.000
  size=3686538
stream #0:
  keyframe=1
  duration=1.000
  dts=89.000  pts=89.000
  size=7373076
stream #0:
  keyframe=1
  duration=1.000
  dts=90.000  pts=90.000
  size=3686538

And at the end of the log only 240 packets were read in total:

Input file #0 (pipe:):
  Input stream #0:0 (video): 240 packets read (888455658 bytes); 240 frames decoded; 
  Total: 240 packets (888455658 bytes) demuxed

(888455658 = 3686538 * 241)

This behaviour is reproducible in the latest 3.0.1 as well as 2.8.6. It does not, however, occur in 2.2.1.

My only recourse is to run that older version but it doesn't have some of the newer features that I require, so I'm stuck at the moment until this can be fixed.

Cheers.

[Carl Eugen Hoyos]

Is the issue reproducible with current FFmpeg git head?

[trebartha]

Yes, I've just pulled the latest git head and reproduced. Please see the latest log attached.

Cheers.

[Michael Niedermayer]

Fixed in 8e26bdd59bf559d00c7e60c53fff292de10139ff

[Carl Eugen Hoyos]

Regression since 3c6d824b80022cc7c098658880b4b5c5778dc965 - related to ticket #3687