[FFmpeg-devel] [PATCH] Fix some typos in avfilter.h
Wed Aug 27 03:37:51 CEST 2008
The Wanderer <inverseparadox at comcast.net> writes:
> 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".
I disagree. The word "but" starts a new independent clause, the
subject of which is "the output", implicitly understood to be that of
the filter discussed in the previous clause. However, upon rereading
it, I agree it doesn't fit well. In fact, the entire sentence is
unwieldy, but I'm too tired to try to think of a better one.
>>>> * * 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.
Reading the original again, I can't quite figure out what it's trying
> 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.
Why are people so afraid of commas nowadays? Commas help, not hinder,
mans at mansr.com
More information about the ffmpeg-devel