e for FFMPEGv6
Sent: Wednesday, April 27, 2022 at 4:18 PM
From: "Timo Rothenpieler"
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 audi
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
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"
To: "FFmpeg development discussions and patches"
Subject: Re: [FFmpeg-devel] Guidance needed for a
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
un
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-
l 27, 2022 at 1:49 PM
From: "Timo Rothenpieler"
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
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 th
