Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3856 closed defect (invalid)

Incorrect frame rate for webm (vp8, libvpx)

Reported by: lespaul75 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:
Output rate option (-r) is ignored and rate is forced to 25 fps.

How to reproduce:
1) Create a directory with 120 JPG images.
2) Encode to webm with command:

ffmpeg -f image2 -start_number 0012910 -i "G%07d.JPG" -vf "crop=1778:1000:250:0, scale=1280x720" -r 60 -crf 16 -b:v 60M -an tst.webm -report

Output file should be exactly 2 seconds. Instead, it is 4.78 seconds, giving a calculated frame rate of 25 fps.

However, the output of FFmpeg claims to be producing 60 fps, even though the total time displayed is clearly 4.78 seconds.

Further, playback in both FFplay and MPC-HC is at 25 fps. Oddly, opening the "properties" window of MPC-HC displays "60 fps" even while playing at 25 fps.

FFmpeg version is reported as: N-64757-g277e5ca (not sure how this correlates to 2.xxx version number)

Workaround: Specifying the "-r 60" option on both the input and output does correctly set the rate to 60 fps.

Attachments (1)

ffmpeg-20140814-221704.log (298.6 KB ) - added by lespaul75 10 years ago.
Output log

Download all attachments as: .zip

Change History (3)

by lespaul75, 10 years ago

Attachment: ffmpeg-20140814-221704.log added

Output log

comment:1 by Carl Eugen Hoyos, 10 years ago

Component: ffmpegundetermined
Resolution: invalid
Status: newclosed

You forgot to set the input frame rate (it defaults to 25).
Please understand that this is a bug tracker not a support forum.

comment:2 by lespaul75, 10 years ago

Please understand that this is a bug tracker not a support forum.
Understood, and that's why I posted a bug report and not a request for support. If you think that it's correct behavior for FFmpeg to output a 25fps video that is "tagged" as 60fps, and claims to be 60fps when played back, then you are correct in marking this as invalid. It is not correct behavior.

I have a workaround so I don't care whether you care about the bug or not. Another option would be to just not have a bug tracker, then you wouldn't have to dodge bug reports by calling them "support" requests.

Note: See TracTickets for help on using tickets.