On Tue, Feb 7, 2017 at 3:57 PM, <u-9...@aetey.se> wrote: > On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote: >> On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote: >> [...] >> > > No, code quality is not outside the scope of your patch. >> > >> > Code quality is a subjective matter. >> > >> >> I'm not going to fight with you > > Appreciated. > >> several developers consider your patch >> does not pass the quality requirements of the project. It's arbitrary, >> [... skipped ...], but that's the current policy of the project. > > Well said. > >> Changing that policy is outside the scope of this patch. > > :) > >> [...] >> > > The use of the environment variable is not tolerable, this is a blocker. >> > >> > It is explicitly specified that it is _not_ being used, >> >> Then please drop the dead code. > > Ok, why not. > > Still, given the disapproval of the "code quality" without a tangible > criteria to follow, I can hardly take any accomodating steps, barring > the omission of the unused code - would this step be enough? >
The code duplication is still enormous and makes the entire approach look rather questionable, and on top of that some built-in yuv conversion is not really appropriate. Packing into different RGB formats is one thing, but actually converting to another color format entirely is quite something else. Whats next, handling all sorts of various yuv colorspaces and subsampling factors? So at the very least the YUV part should be dropped at this point, its not a decoders job to convert from RGB to YUV. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
