On 12/24/16, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Sat, Dec 24, 2016 at 6:09 AM, Paul B Mahol <one...@gmail.com> wrote: > >> On 12/24/16, Ronald S. Bultje <rsbul...@gmail.com> wrote: >> > Hi, >> > >> > On Fri, Dec 23, 2016 at 6:18 PM, James Almer <jamr...@gmail.com> wrote: >> > >> >> On 12/23/2016 8:00 PM, Ronald S. Bultje wrote: >> >> > Hi, >> >> > >> >> > On Fri, Dec 23, 2016 at 12:32 PM, Paul B Mahol <one...@gmail.com> >> wrote: >> >> > >> >> >> diff --git a/libavcodec/lossless_videodsp.h b/libavcodec/lossless_ >> >> >> videodsp.h >> >> >> >> >> > [..] >> >> > >> >> >> @@ -32,6 +32,7 @@ typedef struct LLVidDSPContext { >> >> >> >> >> > [..] >> >> > >> >> >> + void (*add_magy_median_pred_int16)(uint16_t *dst, const >> uint16_t >> >> >> *top, const uint16_t *diff, unsigned mask, int w, int *left, int >> >> *left_top); >> >> >> >> >> > >> >> > That seems wrong. Why would you add a magicuv-specific function to >> >> > losslessdsp-context which is intended for functions shared between >> many >> >> > (not just one) lossless codecs? You probably want a new dsp for >> magicyuv >> >> > specifically. >> >> > >> >> > I know this is tedious, but we're very specifically trying to prevent >> >> > dsputil from ever happening again. >> >> > >> >> > Ronald >> >> >> >> Some functions in this dsp are used only by huffyuv. Only one is used >> >> by >> >> both huffyuv and magicyuv. >> >> To properly apply what you mention, it would need to be split in two, >> >> huffyuvdsp and lldsp, then this new function added to a new dsp called >> >> magicyuvdsp. >> > >> > >> > That would be even better, yes. >> >> What about yasm code? >> >> I wanted that to be commented. > > > It's like dithering, it uses the immediately adjacent pixel in the next > loop iteration, can you really simd this effectively?
Apparently, and someone is making money from it. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel