[FFmpeg-trac] #11126(ffmpeg:new): Filter "setpts=PTS-STARTPTS" in 2-pass may cause abnormal bitrate allocation
FFmpeg
trac at avcodec.org
Tue Aug 6 17:55:01 EEST 2024
#11126: Filter "setpts=PTS-STARTPTS" in 2-pass may cause abnormal bitrate
allocation
-------------------------------------+-------------------------------------
Reporter: Saul Baker | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: ffmpeg
Version: git-master | Resolution:
Keywords: regression | Blocked By:
setpts 2-pass |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by MasterQuestionable):
͏ Don't quite understand your previous words.
͏ Post interpreted for reference:
[ Saul Baker @ CE 2024-08-06 13:27:57 UTC:
https://trac.ffmpeg.org/ticket/11126#comment:17
͏ Yes, and indeed a parameterless "setpts": as "PTS" is the default
expression.
͏ fa110c32b5168d99098dc0c50c6465054cf9d20b
͏ f121d954ac89060cb7b07da230479cffe5bf9e5c
͏ ; mean the FPS and duration stripping apply regardless of the actual
expression:
͏ Seemingly intended as fix for: https://trac.ffmpeg.org/ticket/10886
͏ Anton's rationale about them not being accurate after "setpts"
application, does seem reasonable; but I'm unsure:
͏ How is it expected to be re-applied if needed inside the filtergraph,
without externally scripting a literal into the FPS filter?
͏ If this combined behavior with 2-pass outweighs the perceived
correctness of dropping the FPS and durations, rather than providing a
param to explicitly do the same?
͏ A bit of a tension here between "translating" the PTS under which the
FPS and duration are constant, and "transforming" them in arbitrary ways:
͏ The filter can do both and the dropping of the FPS and duration only
really holds for the latter. ]
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11126#comment:19>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list