[FFmpeg-devel] [PATCH 1/2] ffmpeg: add disable_all_auto_conversion_filters option.

[Paul B Mahol]

On 8/17/20, Alexander Strasser <eclipse7 at gmx.net> wrote:
> On 2020-08-16 23:12 +0200, Nicolas George wrote:
>> Alexander Strasser (12020-08-16):
>> > I dislike the negative name too, because like mentioned by Marton it
>> > doesn't work well with overriding the option to turn it off.
>> >
>> > On one hand for this option in particular it wouldn't be that important,
>> > on the other hand it will be something (new) developers will see when
>> > writing tests and scratch their heads about it.
>>
>> But I want new developers writing tests to see it and scratch their
>> head! I want to scratch their heads and find a better way if
>> implementing their test. It is one of the points of the patch: find where
>> tests are inefficients and give an incentive to make them more
>> efficient.
>>
>> And I want reviewers to see the option, and make a comment about it;
>> tests lines are frequently long, a short option is easy to overlook.
>
> I need to differentiate here. I agree on adding an option to the tests
> where there are still autoconversions happening.
>
> I'm not in favor of adding an option with an unwieldy name and double
> negation (nodisable).
>
> I think the pendulum can swing in both direction here. So the overall
> effect is not clear to me. E.g. one developer may think
>
>     "hey what's this -> i need to fix it"
>
> another might think
>
>     "hey what's this -> better just copy and not look into it"
>
> and a third might think
>
>     "hey what's this -> just another idiosyncrasy :("
>
>
>> > I'm not convinced that using the long name on purpose is good here
>> > or in general.
>> >
>> > 1. It would not be so great to have to invent convenient names for
>> >    every option that shouldn't be used "normally"
>> > 2. If users want to use an option they will use it no matter how
>> >    long the name. (This is from experience, we had a very longish
>> >    and worse named option in MPlayer for a similar reason.)
>>
>> At least, it will make Carl Eugen's work easier, or whoever deals with
>> user questions on the mailing list somewhat easier: if somebody uses the
>> option and break their command line cluelessly, it will be easy to spot,
>> even in the middle of half a page of scale= arithmetic formulas and
>> unrelated encoding options.
>
> Might be. I suspect it will not help much, but sure I might be wrong.
> I didn't do lots of bug wrangling in the last years.
>
>
>> I am not adamant on the name. If somebody suggests something better and
>> there is a consensus, I will change it, of course. But I think these are
>> good points for a very visible name.
>
> I'm neither insisting on anything. I like this patch set.
>
> Here are some suggestions in no particular order:
>
> * auto_conversion_filters (from Marton)

This is very good one.

The double negation is making user and developers think about it
several times upon reading.

> * lavfi_auto_conversion
> * lavfi_autoconv
> * lavfi_sample_format_conversion
> * lavfi_fmt_conversion (in reference to pix_fmt and sample_fmt)
> * lavfi_fmt_conv
>
>
> Best regards,
>   Alexander
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".