On 8/17/20, Alexander Strasser <[email protected]> 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 > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
