Hi,
On Tue, Jul 15, 2014 at 7:53 PM, James Almer <jamr...@gmail.com> wrote: > It's also used by some decoders > > Signed-off-by: James Almer <jamr...@gmail.com> > --- > configure | 4 +- > libavcodec/diracdec.c | 12 ++-- > libavcodec/mpegvideo_enc.c | 8 +-- > libavcodec/mpegvideoencdsp.c | 30 -------- > libavcodec/mpegvideoencdsp.h | 6 -- > libavcodec/snow.c | 7 +- > libavcodec/snow.h | 1 - > libavcodec/snowenc.c | 2 +- > libavcodec/videodsp.c | 30 ++++++++ > libavcodec/videodsp.h | 6 ++ > libavcodec/x86/mpegvideoencdsp_init.c | 118 > -------------------------------- > libavcodec/x86/videodsp_init.c | 124 > +++++++++++++++++++++++++++++++++- > 12 files changed, 175 insertions(+), 173 deletions(-) I have some pretty strong objections to this. We have measured in several high-quality and well-optimized decoders that using emulated_edge on-demand is _always_ faster than draw_edges. So why would we want any decoder to use draw_edges? Looks like cargo-cult to me. Also, I don't want vp8, vp9 or h264 to depend on draw_edges code. My suggestion is to remove draw_edges from the decoders still using it. It'll be faster. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
