On Tue, Jul 24, 2012 at 8:34 AM, Måns Rullgård <[email protected]> wrote: > Jason Garrett-Glaser <[email protected]> writes: > >> On Tue, Jul 24, 2012 at 8:05 AM, John Stebbins <[email protected]> >> wrote: >>> On 06/25/2012 02:42 PM, Mans Rullgard wrote: >>>> >>>> Module: libav >>>> Branch: master >>>> Commit: 82992604706144910f4a2f875d48cfc66c1b70d7 >>>> >>>> Author: Mans Rullgard <[email protected]> >>>> Committer: Mans Rullgard <[email protected]> >>>> Date: Sat Jun 23 19:08:11 2012 +0100 >>>> >>>> x86: fft: convert sse inline asm to yasm >>>> >>>> --- >>>> >>>> libavcodec/x86/Makefile | 1 - >>>> libavcodec/x86/fft_mmx.asm | 139 >>>> ++++++++++++++++++++++++++++++++++++++++--- >>>> libavcodec/x86/fft_sse.c | 110 ---------------------------------- >>>> 3 files changed, 129 insertions(+), 121 deletions(-) >>>> >>> >>> Hi, >>> >>> This commit is causing some strange interaction with libx264 in HandBrake >>> under certain conditions. x264 is encoding at about 1/10th it's normal rate >>> after updating to this commit. >>> >>> A little more background. When doing ac3 passthru HandBrake encodes a >>> single packet of silence data to ac3 that is uses for filling any gaps that >>> it detects in the audio. Encoding of this packet happens before any other >>> encoding or decoding starts. For some crazy reason, if we encode this >>> silence, we get the x264 slowdown. If we do not encode the silence, the >>> speed is ok. I ran gprof on the code to see where all the time is being >>> spent and it is all in x264. So it's not like there is some run-away loop >>> somewhere that is bringing everything to it's knees. I'm guessing some cpu >>> state must not be getting cleared or restored properly somewhere. >>> >>> John >> >> Could it have anything to do with denormals/NaN? > > Does x264 use floating-point SSE instructions anywhere?
Yes, in macroblock-tree (because floating-point reciprocal is fast and IDIV is slow), and in ratecontrol. Jason _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
