Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Gyan Doshi <ffmpeg@gyani.pro>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v4] avfilter/setpts: add option to decide framerate handling
Date: Sun, 26 Jan 2025 19:35:08 +0530
Message-ID: <5a0fd79d-3f6f-462f-95bd-9392277f1ad8@gyani.pro> (raw)
In-Reply-To: <CAEEMt2=-XK7GLMfZsNg++BemSF8g-fiFYaMJX02TQZymK928ow@mail.gmail.com>



On 2025-01-26 07:09 pm, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Jan 25, 2025 at 11:06 PM Gyan Doshi <ffmpeg@gyani.pro> wrote:
>
>>
>> On 2025-01-26 12:49 am, Marton Balint wrote:
>>>
>>> On Sat, 25 Jan 2025, Gyan Doshi wrote:
>>>
>>>> In f121d95, the outlink framerate was unconditionally unset.
>>>> This breaks/bloats outputs from CFR muxers unless the user explicitly
>>>> sets a sane framerate. And the most common invocation for setpts seen in
>>>> workflows, our docs and across the web is `PTS-STARTPTS` or others of
>>>> the
>>>> general form `PTS+constant` which preserves the input framerate.
>>>>
>>>> Fixes #11428
>>>> ---
>>>> v4: negated option sense and renamed to vfr
>>>>
>>>> doc/filters.texi          | 6 ++++++
>>>> libavfilter/setpts.c      | 6 +++++-
>>>> tests/fate/hevc.mak       | 2 +-
>>>> tests/fate/mov.mak        | 2 +-
>>>> tests/filtergraphs/setpts | 2 +-
>>>> 5 files changed, 14 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/doc/filters.texi b/doc/filters.texi
>>>> index b926b865ae..ea11d045ec 100644
>>>> --- a/doc/filters.texi
>>>> +++ b/doc/filters.texi
>>>> @@ -31478,6 +31478,12 @@ This filter accepts the following options:
>>>> @item expr
>>>> The expression which is evaluated for each frame to construct its
>>>> timestamp.
>>>>
>>>> +@item vfr (@emph{video only})
>>>> +Boolean option which determines if the original framerate metadata
>>>> is unset.
>>>> +If set to true, be advised that a sane frame rate should be explicitly
>>>> +specified if output is sent to a constant frame rate muxer.
>>> I propose a more understandable variant for the first sentence:
>>>
>>> Sets the filter output to variable frame rate by dropping the original
>>> constant framerate information if present. If set to true...
>> But that's not actually the case. This option does not make the output
>> VFR. If it did, this option would not be needed.
>> Once FR is unset, if the output goes to a CFR muxer and fps_mode is not
>> specified, ffmpeg will emit a  CFR stream using the time_base.
>> What the option does is a single narrow technical thing which has
>> implications depending on context. And that was the basis for the
>> original option name and description.
>>
>> 'strip_fps' and a corresponding description seems more accurate.
>
> (I'm the bug reporter.) I actually agree. Setting FPS doesn't mean CFR, it
> could just mean average frame rate or something. But please decide on
> something, we're currently stripping said metadata and there's no way to
> reinstate it except with lengthy hacks that we don't want people to start
> posting on stackoverflow - because then we'll never hear the end of it.

Ok, I'll change to strip_fps and push tomorrow (~18h) if there are no 
objections.

Regards,
Gyan

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2025-01-26 14:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-25  8:00 Gyan Doshi
2025-01-25 19:19 ` Marton Balint
2025-01-26  4:06   ` Gyan Doshi
2025-01-26 13:39     ` Ronald S. Bultje
2025-01-26 14:05       ` Gyan Doshi [this message]
2025-01-26 19:33         ` Marton Balint
2025-01-27 12:12           ` Ronald S. Bultje
2025-01-27 12:22             ` Gyan Doshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a0fd79d-3f6f-462f-95bd-9392277f1ad8@gyani.pro \
    --to=ffmpeg@gyani.pro \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git