#10150: Variable framerate with a maximum value
-------------------------------------+-------------------------------------
Reporter: Zoont | Owner: (none)
Type: defect | Status: open
Priority: important | Component:
| undetermined
Version: git-master | Resolution:
Keywords: fps | Blocked By:
framerate vfr cfr vsync |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Tynach):
Replying to [comment:2 elenril]:
> Are you entirely sure this worked as you wanted? I see no indication
that -fpsmax was ever intended to work with VFR. As per the manpage:
> -fpsmax[:stream_specifier] fps (output,per-stream)
> Set maximum frame rate (Hz value, fraction or abbreviation).
>
> Clamps output frame rate when output framerate is auto-set and is
higher than this value. Useful in batch processing or when input framerate
is wrongly detected as very high. It cannot be set together with "-r". It
is ignored during streamcopy.
>
> In other words, it affects the way the output framerate is selected, but
there still is a fixed output framerate.
I used to do the same thing, using `-r` and `-vsync vfr` together. I
thought it was a nifty undocumented feature. Also, elenril, while I'm not
the same person as the one who opened this bug, I ''have'' extensively
tested it, and it ''did'' used to do what is described (allow a variable
framerate with a maximum output framerate).
Personally, I think that commit should be completely reverted, and instead
the documentation changed to reflect the actual behavior. The commit in
question only provides one reason for their change, and that is that the
behavior didn't match the documentation.. But this is **clearly** a
regression in functionality.
Either revert the commit and make a different commit that updates the
documentation, or add another flag that provides the old behavior. Seeing
as `-fpsmax` already exists and sounds like it ought to do what used to be
possible, and according to Zoont used to also provide this desired
behavior, then if it's decided ''not'' to fully revert the offending
commit then I propose that `-fpsmax` is modified to allow the previous
behavior.
Also, for what it's worth, I documented this working back in 2016 by
writing [https://superuser.com/a/1073260/184072 this Super User answer].
Given it has 35 upvotes, it's almost certain that there are other people
who depend on this functionality, or at least have used it at some point
in the past.
In regards to the original reason why the change was made.. There are
PLENTY of undocumented behaviors in FFmpeg, including undocumented command
line parameters. Looking at the commit in question, it seems like the
tests had to be changed in order to pass.. That should have been a red
flag that the changes shouldn't have been made to begin with. if tests
didn't need to be changed for this commit to pass them, then the test
changes should have been a separate commit.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10150#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
