Quoting Ronald S. Bultje (2015-08-21 14:24:47) > Hi, > > On Wed, Aug 19, 2015 at 7:31 PM, James Almer <[email protected]> wrote: > > > On 19/08/15 8:23 PM, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Wed, Aug 19, 2015 at 6:34 PM, James Almer <[email protected]> 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.
There's a couple of reasons - dealing with the openhevc code has proven to be massive pain in the past, requiring significant rewrites to be readable - the existing mc asm in ffmpeg taken from openhevc seems to conform to this as well - it does a bunch of changes to the c code, which smart people told me are better not done - the codebase in ffmpeg is quite different, so extracting the changes is yet more pain - I had almost no experience with writing SIMD before this, so I wouldn't have been able to review the code properly - the result is smaller, more readable (IMO) and faster -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
