[FFmpeg-trac] #9535(undetermined:new): PNG decoder fails processing more than a certain number of frames
FFmpeg
trac at avcodec.org
Sat Nov 27 23:05:19 EET 2021
#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.
>
> Sending a kill 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
> }}}
New description:
Summary of the bug: trying to encode a video from .png sequence with more
than a certain number of frames in a given directory 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 a kill 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:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list