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)
* 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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to