doc/developer: Fix typos

[softworkz]

No description provided.

[softworkz]

/submit

[ffmpeg-codebot]

Submitted as pull.103.ffstaging.FFmpeg.1750920409775.ffmpegagent@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-103/softworkz/submit_typos-v1

To fetch this version to local tag pr-ffstaging-103/softworkz/submit_typos-v1:

git fetch --no-tags https://github.com/ffstaging/FFmpeg tag pr-ffstaging-103/softworkz/submit_typos-v1

[ffmpeg-codebot]

On the FFmpeg mailing list, Gyan Doshi wrote (reply to this):

On 2025-06-26 12:16 pm, softworkz wrote:
> From: softworkz <softworkz@hotmail.com>
>
> Signed-off-by: softworkz <softworkz@hotmail.com>
> ---
>      doc/developer: Fix typos
>
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-103%2Fsoftworkz%2Fsubmit_typos-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-103/softworkz/submit_typos-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/103
>
>   doc/developer.texi | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 108558b9e0..f4ae300c2b 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -424,7 +424,7 @@ paste it from a random place, use an existing file as template.
>   @subheading You must not commit code which breaks FFmpeg!
>   This means unfinished code which is enabled and breaks compilation,
>   or compiles but does not work/breaks the regression tests. Code which
> -is unfinished but disabled may be permitted under-circumstances, like
> +is unfinished but disabled may be permitted under circumstances, like
>   missing samples or an implementation with a small subset of features.
>   Always check the mailing list for any reviewers with issues and test
>   FATE before you push.
> @@ -546,7 +546,7 @@ FFmpeg also has a defined scope - your new API must fit within it.
>   
>   @subsubheading Replacing existing APIs
>   If your new API is replacing an existing one, it should be strictly superior to
> -it, so that the advantages of using the new API outweight the cost to the
> +it, so that the advantages of using the new API outweigh the cost to the
>   callers of changing their code. After adding the new API you should then
>   deprecate the old one and schedule it for removal, as described in
>   @ref{Removing interfaces}.

LGTM.

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