#1771 closed defect (fixed)
The file size limit almost never works.
| Reported by: | Agustín Dall'Alba | Owned by: | |
|---|---|---|---|
| Priority: | minor | Component: | documentation |
| Version: | git-master | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description
Just what it says on the tin. I couldn't find a single file-codec combination such that ffmpeg obeys the file size limit imposed with the -fs switch. It always overshoots.
How to reproduce:
- Pick any file
- Transcode/remux/cut it with ffmpeg while specifying a file size limit with -fs
- Measure the size of the resulting file. It's almost always slightly bigger than requested.
Change History (7)
follow-up: 3 comment:1 by , 12 years ago
| Component: | undetermined → documentation |
|---|---|
| Priority: | normal → minor |
| Reproduced by developer: | set |
| Status: | new → open |
comment:2 by , 12 years ago
So it's supposed to work this way? Should I make this ticket a feature request then or open a new one?
follow-up: 4 comment:3 by , 12 years ago
Replying to cehoyos:
Imo, this is a documentation issue.
IMO, this is a bug. If the user needs this option, it is because she usually has an upper bound size constraint, getting a "slightly bigger" file is not very helpful. Thus the behaviour should be changed.
On the other hand, the additional size may be due to the format trailer, which is not always (easily) predictable, so that may be the reason of the observed behavior.
comment:4 by , 12 years ago
Replying to saste:
On the other hand, the additional size may be due to the format trailer, which is not always (easily) predictable, so that may be the reason of the observed behavior.
I tried with ffmpeg -i dinah.mp4 -an -f rawvideo -fs xxxx -y out.raw, where dinah.mp4 is a yuv420p 480x360 video. Each frame is (6B/4px)*480*360px = 259200 bytes of raw video. Coincidentally out.raw is always the smallest multiple of 259200 bytes that's bigger than xxxx in the command line.
comment:5 by , 6 years ago
| Component: | documentation → ffmpeg |
|---|
The documentation was clarified in 9effa012553167d3662f1392310671c575c9322f, so this ticket, if valid, is a ffmpeg bug/limitation.
comment:6 by , 6 years ago
| Component: | ffmpeg → documentation |
|---|---|
| Keywords: | limit_size removed |
| Resolution: | → fixed |
| Status: | open → closed |
I don't see how this can be realistically improved, the documentation issue was fixed by Umair.
comment:7 by , 6 years ago
In theory, one could
1) allow the user to set a trailer size threshold in % terms, or use a hardcoded value.
2) write_packet could abort if current output size + pkt.size + above trailer estimate exceeds the fs limit.
One complication would be missing interim frames for video streams with delay. But that could perhaps be ameliorated by taking into account video_delay from the stream's codecpar.
Imo, this is a documentation issue.