2019-01-14 9:11 GMT+01:00, Peter Ross <pr...@xvid.org>: > On Sun, Jan 13, 2019 at 09:39:57PM +0100, Carl Eugen Hoyos wrote: >> 2019-01-13 21:02 GMT+01:00, Peter Ross <pr...@xvid.org>: >> > --- >> > libavcodec/vp56.c | 10 ++++++++++ >> > libavcodec/vp56.h | 1 + >> > libavcodec/vp56dsp.c | 19 ------------------- >> > 3 files changed, 11 insertions(+), 19 deletions(-) > >> > + if (dx) >> > + ff_vp4_h_loop_filter_12_c(yuv + 10-dx, stride, >> > bounding_values); >> > + if (dy) >> > + ff_vp4_v_loop_filter_12_c(yuv + stride*(10-dy), stride, >> > bounding_values); >> > + } >> > } >> >> This is your code now but I wonder why it helps not to merge >> this with 1/6. > > fair enough. > >> > - s->edge_filter_hor = vp6_edge_filter_hor; >> > - s->edge_filter_ver = vp6_edge_filter_ver; >> >> And why are the new functions called "_c" but >> are not part of the context? >> (Or do I misread the code?) > > i will drop the _c. > > and for consisistency they probably should be ff_vp3dsp_xxx. > > they are not part of the context, because they there are are no > asm alternative functions (yet). it seems like a waste creating > context function pointers that only every point to the one function.
If you plan to add asm functions (or if you believe they should be added) you could leave the function pointers as they are. But that's all your decision, Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
