Hi, On Fri, Aug 21, 2015 at 10:02 AM, Anton Khirnov <an...@khirnov.net> wrote:
> Quoting Ronald S. Bultje (2015-08-21 14:24:47) > > 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. > > 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 There's no avx2. Will you write that too? I'd like to prevent ffmpeg/libav from massively diverging w.r.t. big features, and no avx2 will mean significant speed loss if I dump the current code on the ffmpeg side. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
