[FFmpeg-devel] [PATCH] avcodec/magicyuv: add SIMD for median of 10bits

Ronald S. Bultje rsbultje at gmail.com
Sun Dec 25 18:11:15 EET 2016


Hi,

On Sat, Dec 24, 2016 at 9:29 AM, Paul B Mahol <onemda at gmail.com> wrote:

> On 12/24/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> > Hi,
> >
> > On Sat, Dec 24, 2016 at 6:09 AM, Paul B Mahol <onemda at gmail.com> wrote:
> >
> >> On 12/24/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > On Fri, Dec 23, 2016 at 6:18 PM, James Almer <jamrial at 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 <onemda at 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.


The parallelizable portion of it is the top-topleft, and you seem to do
that already. Other than that, I don't see much to be done. You can
probably use some mmxext instructions like pshufw to make life easier, but
I think you'll always be limited by the inherent limitation.

Ronald


More information about the ffmpeg-devel mailing list