On 7 May 2016 at 18:55, Christophe Gisquet <christophe.gisq...@gmail.com> wrote:
> 2016-05-07 19:12 GMT+02:00 Rostislav Pehlivanov <atomnu...@gmail.com>: > > There is a slight performance drop associated with this change, making > > the encoder slower by 1.15 times, however this is necessary in order to > > avoid undefined behavior and overflows. > > This means no asm has been written yet. Is the performance drop mostly > in transforms, or rather any coefficient manipulation (like rate > evaluation etc), or memory bandwidth? > In the former case, it might be less critical in the future. > > The costliest part of the encoder right now is encoding the coefficients (~36%). Slightly less-costly is rate control (~31%), and after that is the transform (~12%). There really isn't anything else, other than 3 copies (input image converted to signed and copied to a buffer, then because the transform is out of place there's a copy to another buffer and then back), but they don't take that much time. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
