Hi, On Wed, Aug 19, 2015 at 7:31 PM, James Almer <jamr...@gmail.com> wrote:
> On 19/08/15 8:23 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Wed, Aug 19, 2015 at 6:34 PM, James Almer <jamr...@gmail.com> wrote: > > > >> On 19/08/15 4:43 PM, Anton Khirnov wrote: > >>> --- > >>> libavcodec/hevc.c | 6 +- > >>> libavcodec/hevc.h | 2 +- > >>> libavcodec/hevcdsp.c | 24 +- > >>> libavcodec/hevcdsp.h | 5 +- > >>> libavcodec/hevcdsp_template.c | 8 +- > >>> libavcodec/x86/Makefile | 3 +- > >>> libavcodec/x86/hevc_mc.asm | 816 > >> ++++++++++++++++++++++++++++++++++++++++++ > >>> libavcodec/x86/hevcdsp_init.c | 405 +++++++++++++++++++++ > >>> 8 files changed, 1258 insertions(+), 11 deletions(-) > >>> create mode 100644 libavcodec/x86/hevc_mc.asm > >> > >> I'm getting segmentation faults with quite a few of samples. > >> For example > http://www.elecard.com/assets/files/other/clips/bbb_1080p_c.ts > > > > > > So, at the risk of godwin, why was this reimplemented from scratch, > rather > > than basing it on what ffmpeg has? How could this possibly be an > advantage > > to our users? > > Or OpenHEVC for that matter, which is the source of almost every hevc asm > optimization, x86 or otherwise, and a project that afaik branched off > libav. Guys, please, this situation is awful enough as it is, can you please consider this concern? Ignoring me does not make it better. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
