[FFmpeg-devel] Guidance needed for a semi-breaking change

[FFmpeg-devel] Guidance needed for a semi-breaking change

[MCC CS]

Hi,

It's my first time writing an (original) patch for ffmpeg, so I would like your help.

I’m planning to propose a diff to an encoder param for aac_at, which is, as currently listed by "ffmpeg -h encoder=aac_at”:

  -aac_at_quality    <int>        E...A...... quality vs speed control (from 0 to 2) (default 0)

Currently, 0 uses HIGH, and 1, 2 use MID, LOW quality encodings.

I’d like to change this param so that all 5 levels listed by Apple (MAX, HIGH, MID, LOW, MIN) can be used.

Do I change it to:

  -aac_at_quality    <int>        E...A...... quality vs speed control (from 0 to 4) (default 0)

and migrate everyone to a higher-quality encoding preset

or
  -aac_at_quality    <int>        E...A...... quality vs speed control (from -1 to 3) (default -1)

so that previous levels are kept as they are, adding only MAX and MIN, which were previously out of range.

I’d like to know: Which of these aligns better with FFMPEG’s policies?

Many thanks
_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[Timo Rothenpieler]

You need to keep API and ABI compatibility, cause otherwise it's a 
breaking change which can only happen at a major bump.
Any and all existing applications and commandline need to keep working 
as they do right now.

What you could do is convert the option into a OPT_TYPE_CONST one, and 
offer the new values as actual textual option, and set up the numerical 
values so that they align with what's currently offered.
_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[MCC CS]

I wasn't considering a breaking change, those using
-aac_at_quality 0 or -aac_at_quality 2 would continue to use those.
However, would moving -aac_at_quality 0 from HIGH (currently highest
used by FFMPEG) to MAX be welcome? I'd assume that those using
-aac_at_quality 0 do so to use the highest quality option available.

If not, extending the range (0,2) to (-1,3) without moving any
previous options would work. From what I understand negative
numbers are OK in ffmpeg since `-q:a -1` produces higher quality
than `-q:a 0` for me.

How about this?

Thanks again

Sent: Wednesday, April 27, 2022 at 1:49 PM
From: "Timo Rothenpieler" <timo@rothenpieler.org>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] Guidance needed for a semi-breaking change
You need to keep API and ABI compatibility, cause otherwise it's a
breaking change which can only happen at a major bump.
Any and all existing applications and commandline need to keep working
as they do right now.

What you could do is convert the option into a OPT_TYPE_CONST one, and
offer the new values as actual textual option, and set up the numerical
values so that they align with what's currently offered.
_______________________________________________
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".
_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[Timo Rothenpieler]

Any existing commandline should produce the exact same output after the 
change.
Not sure if the encoder is bitexact, but if it is, the output should match.
_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 407 bytes --]

Timo Rothenpieler (12022-04-27):
> Any existing commandline should produce the exact same output after the
> change.

I do not agree.

Small changes in default behavior are acceptable, since the user did not
specify what they want.

(I would argue that changes that fix a bug and changes that are
unambiguously and exclusively an improvement are acceptable.)

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[MCC CS]

The default for AAC_AT is to produce highest quality audio, which I'll keep undoubtedly
in the same direction. However, the question is this:

Should the one who explicitly set `-aac_at_quality 0` (highest quality available) be moved from HIGH to MAX,
HOWEVER causing the side effect of moving everyone up in the quality-speed tradeoff by one,

(or we can eliminate HIGH and just replace it with MAX which has no tradeoffs AFAIK)

OR add `-1`, so that only those who entered no `aac_at_quality` be moved to -1,
and keeping explicit people having set `-aac_at_quality 0` at HIGH for them,
although they might have meant MAX when they started using it?
(i.e. no regression nor improvement for them)

---
Sent: Wednesday, April 27, 2022 at 2:18 PM
From: "Nicolas George" <george@nsup.org>
To: "FFmpeg development discussions and patches" <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Guidance needed for a semi-breaking change
Timo Rothenpieler (12022-04-27):
> Any existing commandline should produce the exact same output after the
> change.

I do not agree.

Small changes in default behavior are acceptable, since the user did not
specify what they want.

(I would argue that changes that fix a bug and changes that are
unambiguously and exclusively an improvement are acceptable.)

Regards,

--
Nicolas George
_______________________________________________
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".
_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[Timo Rothenpieler]

On 27.04.2022 16:07, MCC CS wrote:
> The default for AAC_AT is to produce highest quality audio, which I'll keep undoubtedly
> in the same direction. However, the question is this:
> 
> Should the one who explicitly set `-aac_at_quality 0` (highest quality available) be moved from HIGH to MAX,
> HOWEVER causing the side effect of moving everyone up in the quality-speed tradeoff by one,
> 
> (or we can eliminate HIGH and just replace it with MAX which has no tradeoffs AFAIK)
> 
> OR add `-1`, so that only those who entered no `aac_at_quality` be moved to -1,
> and keeping explicit people having set `-aac_at_quality 0` at HIGH for them,
> although they might have meant MAX when they started using it?
> (i.e. no regression nor improvement for them)

The strictly correct approach here would be to add version guards, and 
switch to the new behaviour next major bump.
I do agree though that that seems a bit over the top for this, and 
specially if there is a higher quality than what ffmpeg currently 
offers, I could definitely see keeping 0 as "highest possible quality".
_______________________________________________
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".

Re: [FFmpeg-devel] Guidance needed for a semi-breaking change

[MCC CS]

Would you then approve changing current 0 from HIGH to MAX? Alternatively
-1 can be added until a major bump, while keeping 0 as default.
Either would be nondestructive.

And do you have an example/doc text about adding version guards to an arg?
I hope there's a general preprocessor variable for FFMPEGv6

Sent: Wednesday, April 27, 2022 at 4:18 PM
From: "Timo Rothenpieler" <timo@rothenpieler.org>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] Guidance needed for a semi-breaking change
On 27.04.2022 16:07, MCC CS wrote:
> The default for AAC_AT is to produce highest quality audio, which I'll keep undoubtedly
> in the same direction. However, the question is this:
>
> Should the one who explicitly set `-aac_at_quality 0` (highest quality available) be moved from HIGH to MAX,
> HOWEVER causing the side effect of moving everyone up in the quality-speed tradeoff by one,
>
> (or we can eliminate HIGH and just replace it with MAX which has no tradeoffs AFAIK)
>
> OR add `-1`, so that only those who entered no `aac_at_quality` be moved to -1,
> and keeping explicit people having set `-aac_at_quality 0` at HIGH for them,
> although they might have meant MAX when they started using it?
> (i.e. no regression nor improvement for them)

The strictly correct approach here would be to add version guards, and
switch to the new behaviour next major bump.
I do agree though that that seems a bit over the top for this, and
specially if there is a higher quality than what ffmpeg currently
offers, I could definitely see keeping 0 as "highest possible quality".
_______________________________________________
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".
_______________________________________________
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".