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?
Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
