<div dir="ltr"><div>So, I dont think it's fair to upgrade the datatypes of these variables just to satisfy debug/check code. We're unnecessarily adding cycles.<br><br></div>I think the best solution here might be to remove these hacky checks in Mode.invalidate(), and Mode.ok() and add more robust checking into rdcost.h. <br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 9:45 AM, Divya Manivannan <span dir="ltr"><<a href="mailto:divya@multicorewareinc.com" target="_blank">divya@multicorewareinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">sse_ret_t is changed to uint64_t unconditionally in all the modes.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 23, 2015 at 8:21 PM, chen <span dir="ltr"><<a href="mailto:chenm003@163.com" target="_blank">chenm003@163.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>Which type?</div><div>in 8b/10b mode, sse_ret_t may 32-bits<br></div><div><div><div></div><div></div><div><br></div>At 2015-09-23 16:43:34,"Divya Manivannan" <<a href="mailto:divya@multicorewareinc.com" target="_blank">divya@multicorewareinc.com</a>> wrote:<br> <blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">The data type is changed to uint64_t and ok() is also changed accordingly in this patch. Please tell any other changes are required?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 21, 2015 at 9:52 PM, chen <span dir="ltr"><<a href="mailto:chenm003@163.com" target="_blank">chenm003@163.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div style="color:rgb(0,0,0);line-height:1.7;font-family:arial;font-size:14px"><div>The ok() is self verify code, we need correct it.<br></div><div><div><div></div><div></div><div><br></div>At 2015-09-21 12:39:24,"Divya Manivannan" <<a href="mailto:divya@multicorewareinc.com" target="_blank">divya@multicorewareinc.com</a>> wrote:<br> <blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">There is no dynamic range overflow in 8bpp and 10bpp mode. But the threshold in the ok() function is below the dynamic range for 10bpp mode.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 16, 2015 at 8:28 PM, chen <span dir="ltr"><<a href="mailto:chenm003@163.com" target="_blank">chenm003@163.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div style="color:rgb(0,0,0);line-height:1.7;font-family:arial;font-size:14px">Are you found dynamic range overflow in 8bpp and 10bpp mode?<span><div><br></div><pre><br>At 2015-09-16 17:11:29,"Divya Manivannan" <<a href="mailto:divya@multicorewareinc.com" target="_blank">divya@multicorewareinc.com</a>> wrote:
># HG changeset patch
># User Divya Manivannan <<a href="mailto:divya@multicorewareinc.com" target="_blank">divya@multicorewareinc.com</a>>
># Date 1442392516 -19800
># Wed Sep 16 14:05:16 2015 +0530
># Node ID ee39c10fd573444710aca40ec3bd572aac8b3cd0
># Parent 365f7ed4d89628d49cd6af8d81d4edc01f73ffad
>sse: fix data type for sse functions
>
>diff -r 365f7ed4d896 -r ee39c10fd573 source/common/common.h
>--- a/source/common/common.h Tue Sep 08 16:38:01 2015 +0530
>+++ b/source/common/common.h Wed Sep 16 14:05:16 2015 +0530
>@@ -134,12 +134,6 @@
> typedef int32_t ssum2_t; // Signed sum
> #endif // if HIGH_BIT_DEPTH
>
>-#if X265_DEPTH <= 10
>-typedef uint32_t sse_ret_t;
>-#else
>-typedef uint64_t sse_ret_t;
>-#endif
>-
> #ifndef NULL
> #define NULL 0
> #endif
</pre></span></div><br>_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br>_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div><br>_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br></blockquote></div><br></div>
</div></div><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" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br></blockquote></div><br></div>