<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">I have made patch to remove _new suffix and also looking into Min's suggestions.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 2:54 PM, Steve Borho <span dir="ltr"><<a href="mailto:steve@borho.org" target="_blank">steve@borho.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/13, Ashok Kumar Mishra wrote:<br>
> The patch series is intended for intra optimization.<br>
><br>
> In HEVC implementation, the left neighbouring pixels were storing in<br>
> 144 bytes apart. The optimized version of the code uses only<br>
><br>
> 257(1 + 2 * 128) bytes which is reduced from (1152 * 1056 + 768) bytes<br>
> initially used. Both left and above neighboring pixels are stored in<br>
> one buffer.<br>
><br>
> Apart from that planar and angular prediction functions are modified<br>
> to optimize. Because of that reason it was required to rewrite the<br>
> corresponding asm functions.<br>
<br>
</span>I have the series queued locally, but it won't be pushed until Min's<br>
concerns are addressed, and all traces of *_new_* are expunged by<br>
follow-up patches.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Steve Borho<br>
_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div>