[FFmpeg-trac] #9535(undetermined:new): PNG decoder fails processing more than a certain number of frames

[FFmpeg]

#9535: PNG decoder fails processing more than a certain number of frames
-------------------------------------+-------------------------------------
             Reporter:  panthalassa  |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:  png          |               Blocked By:
  decoding                           |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Description changed by panthalassa:

Old description:

> Summary of the bug: trying to encode a video with more than a certain
> number of frames from a .png sequence results in corrupted output and an
> out-of-memory scenario
>
> How to reproduce:
> Sorry but due to the absurd bandwith requirements I likely won't be able
> to upload the offending files. This can likely be reproduced by
> converting a long, losslessly compressed video into a sufficient number
> of PNG's (my stats: 11 minute 1080p video at 60fps = ~39,000 frames, each
> frame 1.9mb making the uncompressed video around 80gb) I acquired these
> frames from rendering in Blender
>
> Present on all versions I've tested from 3.4.8 to 4.4.1. Any png-based
> input fails with too many files in the directory - symptoms include the
> encoded video having scrambled frame order after about 1000 frames, as
> well as the [png @ 0x??? chunk too big] error after about 14750 processed
> frames.
>
> Taking a generous swathe of images around the error points and processing
> them separately produces no errors implying that a corrupted PNG is not
> to blame.
>
> Putting a smaller (1-2000) number of frames in a directory and processing
> them separately produces a successful result longer than 1000 frames,
> past the previous point of onset for corruption. Unknown exactly how many
> frames are needed to cause the error.
>
> Any format encoding that receiving raw PNG input appears to be bugged -
> libx264rgb, libx265, ffv1 tested
>
> Latest tested version: clean install of N-104671-g2cddb2f7a8 on a live
> USB of Linux Mint 19.1 MATE following the instructions on the Compile
> FFMPEG page
>
> {{{
> % ffmpeg -framerate 60 -f image2 -pattern_type glob -i $1'/*.png' -vcodec
> libx265 -pix_fmt yuv420p10le -vf scale=out_range=pc $2
>
> % ffmpeg -framerate 60 -f image2 -pattern_type glob -i $1'/*.png' -vcodec
> ffv1 -coder 1 -level 3 -threads 4 -slices 4 -pix_fmt bgra $2
>
> ffmpeg version: N-104671-g2cddb2f7a8
> built on ... Linux Mint 19.1 MATE live USB
> }}}

New description:

 Summary of the bug: trying to encode a video with more than a certain
 number of frames from a .png sequence results in corrupted output and an
 out-of-memory scenario

 How to reproduce:
 Sorry but due to the absurd bandwith requirements I likely won't be able
 to upload the offending files. This can likely be reproduced by converting
 a long, losslessly compressed video into a sufficient number of PNG's (my
 stats: 11 minute 1080p video at 60fps = ~39,000 frames, each frame 1.9mb
 making the uncompressed video around 80gb) I acquired these frames from
 rendering in Blender

 Present on all versions I've tested from 3.4.8 to 4.4.1. Any png-based
 input fails with too many files in the directory - symptoms include the
 encoded video having scrambled frame order after about 1000 frames, as
 well as the [png @ 0x??? chunk too big] error after about 14750 processed
 frames.

 Sending an ^C signal for a soft quit producing a video of just over 1000
 frames displays the same issue.

 Taking a generous swathe of images around the error points and processing
 them separately produces no errors implying that a corrupted PNG is not to
 blame.

 Putting a smaller (1-2000) number of frames in a directory and processing
 them separately produces a successful result longer than 1000 frames, past
 the previous point of onset for corruption. Unknown exactly how many
 frames are needed to cause the error.

 Any format encoding that receiving raw PNG input appears to be bugged -
 libx264rgb, libx265, ffv1 tested

 Latest tested version: clean install of N-104671-g2cddb2f7a8 on a live USB
 of Linux Mint 19.1 MATE following the instructions on the Compile FFMPEG
 page

 {{{
 % ffmpeg -framerate 60 -f image2 -pattern_type glob -i $1'/*.png' -vcodec
 libx265 -pix_fmt yuv420p10le -vf scale=out_range=pc $2

 % ffmpeg -framerate 60 -f image2 -pattern_type glob -i $1'/*.png' -vcodec
 ffv1 -coder 1 -level 3 -threads 4 -slices 4 -pix_fmt bgra $2

 ffmpeg version: N-104671-g2cddb2f7a8
 built on ... Linux Mint 19.1 MATE live USB
 }}}

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9535#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker