[FFmpeg-devel] [PATCH] Fix some typos in avfilter.h

The Wanderer inverseparadox
Wed Aug 27 02:26:58 CEST 2008

M?ns Rullg?rd wrote:

> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
>>> Index: libavfilter/avfilter.h
>>> ===================================================================
>>> --- libavfilter/avfilter.h	(revision 14964)
>>> +++ libavfilter/avfilter.h	(working copy)
>>> @@ -125,7 +125,7 @@
>>>   * list of the formats supported by each input and output pad. The list
>>>   * given for each pad need not be distinct - they may be references to the
>>>   * same list of formats, as is often the case when a filter supports multiple
>>> - * formats, but will always outut the same format as it is given in input.
>>> + * formats, but will always output the same format as it is given in input.
>                                                                       ^^
> "but the output will always be the same format as the input"

This doesn't seem grammatical to me given the context of the phrase (and
wouldn't really flow well even without that); the entire section after
the final occurrence of the noun "filter" is in effect an adjective
modifying that noun. I might paraphrase (not as a suggestion for actual
use!) as something like "This is often true of a filter which, though it
supports multiple formats, will always produce output which is in the
same format as its input".

>>>   * * In this way, a list of possible input formats and a list of
>>> possible * output formats are associated with each link. When a set
>>> of formats is @@ -184,8 +184,8 @@
>>>  /**
>>>   * Returns a format list which contains the intersection of the formats of
>>> - * a and b. And all the references of a and b, and a and b will be
>>> - * deallocated.
>>> + * a and b. Also, all the references of a, all the references of b, and
>>> + * a and b themselves will be deallocated.
> "Also, a and b, and all references to either, will be deallocated"

"references to X" and "references of X" do not mean the same thing - the
former indicates things which refer to X, the latter I would interpret
as indicating things which are referred to by X.

Also, this suggested form has the too-many-commas effect, which the form
in the patch does not. That could be mostly fixed by dropping the final
comma, but the state introduced by doing so has other problems which are
harder to pin down.

       The Wanderer did say this was almost impossible to perfect...

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.

More information about the ffmpeg-devel mailing list