#11320 closed defect (invalid)
ffmpeg DESTROYS input files
Reported by: | ffmpeg.pete | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
Sorry, unable to append gdb output. Followed the instructions, didn't work for me. ???
I'm creating a video from jpegs. This has never failed for me. Always works.
Today, I'm using really crappy input, i.e. the jpegs are not all of uniform height and width, so I was expecting a problem.
But I did not expect ffmpeg to DESTROY the input files.
So, I'll correct my input files and re-run. No problem.
But I wanted to give you guys the heads up! on this.
No way should the input files ever be overwritten.
How to reproduce:
- Unzip the attached files (bunch of very small jpegs).
- Then run the command below
% ffmpeg -y -i 00/* -r 25 result.mp4 ffmpeg version built on ... ffmpeg version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2000-2021 the FFmpeg developers built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)
Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.
Attachments (1)
Change History (4)
by , 2 hours ago
comment:1 by , 2 hours ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
-i 00/* -r 25 result.mp4
Considering for simplicity that directory 00
contains just two files named 0
and 1
, your shell would expands this part of the commandline to -i 00/0 00/1 -r 25 result.mp4
, which means
- one input:
00/0
- two outputs:
00/1
andresult.mp4
In other words, this is not a bug, has nothing to do with input files being corrupted, and did not ever do what you want unless the directory had just one file.
comment:2 by , 2 hours ago
Update: I made all the files uniform in height and width using imagemagick command
- resize all input files to 64x64
- set background black
- pad as necessary
- center resulting
mogrify -path 64x64/ -resize 64x64 -background black -gravity center -extent 64x64 *.jpg
I confirm the output file size in the directory 64x64/ to be 64x64 in size:
...
00001_00.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 64x64, components 1
...
Same result. So maybe I'm not allowed to create such a small mp4?
But!!! The input files are DESTROYED.
Even for stupid users like me. This should never happen.
Noticing lots of messages like this:
[swscaler @ 0x55a8763ab600] deprecated pixel format used, make sure you did set range correctly
But the images look fine on inspection.
File contains around 1,600 small jpegs of non-uniform height and width.