On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote: > On Tue, Feb 7, 2017 at 3:57 PM, <u-9...@aetey.se> wrote: > > 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
Do you mean the about dozen lines which by the bitstream design are doing exactly the same but are repeated almost literally in every of the 10 finctions? This is the duplication I see, do you mean this or something else? > look rather questionable, and on top of that some built-in yuv > conversion is not really appropriate. Packing into different RGB Why not appropriate if it is useful? Any other way to do equally fast decoding to YUV? > formats is one thing, but actually converting to another color format > entirely is quite something else. Whats next, handling all sorts of You talk past me! What makes you accept the one but not the other? :) > various yuv colorspaces and subsampling factors? Why not, if there will be a data consumer with this hypothetical format and we will need speed? Why not? This _is_ efficient at the decoder, it is just many of the developers ignored this fact until now. > 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. What is the criteria to choose where the job is to be done? My point is efficiency. What is yours? Regards, Rune _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
