Opened 8 years ago
Closed 8 years ago
#6296 closed defect (needs_more_info)
Encoding automatically rounds frame rate
Reported by: | LordHDL | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug: When not specifying frame rate, the rate of the output video will be rounded instead of being left at the source rate.
For instance, if the source video is at 59.91 the output video will be rounded to 59.94.
How to reproduce: Encode without using -framerate
, -r
, or -vf fps
.
Terminal output attached.
Attachments (1)
Change History (5)
by , 8 years ago
Attachment: | FPS Rounding added |
---|
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Forgot to add: AFAIK, 59.91 is probably bogus, while 59.94 is an accurate approximation of 60000/1001, a standard frame rate.
comment:3 by , 8 years ago
59.94 is just an example, that's not always what it rounds to. The software I use to record captures frames on arrival as opposed to me specifying a fixed rate, hence the video may wind up with a rate like 59.91 or something odd. I could wind up with 59.94 and ffmpeg will round that up to 60, or I may get something non-standard.
Is -r
as an output option the correct way to prevent this?
comment:4 by , 8 years ago
Component: | ffmpeg → undetermined |
---|---|
Resolution: | → needs_more_info |
Status: | new → closed |
Please reopen this ticket if you can provide input file, command line (without -hide_banner
), complete, uncut console output and if you can explain what is wrong with the output file.
Do not use
-hide_banner
for bug reports.The 59.94 you observe is the average frame rate, and the difference corresponds very accurately to one frame, so it is probably only caused by a slightly different computation of the average.