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
