<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 16, 2014 at 3:30 PM, <span dir="ltr"><<a href="mailto:x265-devel-request@videolan.org" target="_blank">x265-devel-request@videolan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send x265-devel mailing list submissions to<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:x265-devel-request@videolan.org">x265-devel-request@videolan.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:x265-devel-owner@videolan.org">x265-devel-owner@videolan.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of x265-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [PATCH] replace sse_sp(residual, ZERO) by ssd_s(residual)<br>
(chen)<br>
2. Re: [PATCH] replace sse_sp(residual, ZERO) by ssd_s(residual)<br>
(Steve Borho)<br>
3. Re: A few warnings from GCC 4.8.2 (Steve Borho)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 16 Jul 2014 07:38:47 +0800 (CST)<br>
From: chen <<a href="mailto:chenm003@163.com">chenm003@163.com</a>><br>
To: "Development for x265" <<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a>><br>
Subject: Re: [x265] [PATCH] replace sse_sp(residual, ZERO) by<br>
ssd_s(residual)<br>
Message-ID: <<a href="mailto:643dec21.f6c.1473c648855.Coremail.chenm003@163.com">643dec21.f6c.1473c648855.Coremail.chenm003@163.com</a>><br>
Content-Type: text/plain; charset="gbk"<br>
<br>
<br>
<br>
At 2014-07-16 07:32:51,"Steve Borho" <<a href="mailto:steve@borho.org">steve@borho.org</a>> wrote:<br>
>On 07/15, Min Chen wrote:<br>
>> # HG changeset patch<br>
>> # User Min Chen <a href="mailto:chenm003@163.com">chenm003@163.com</a>><br>
>> # Date 1405471890 25200<br>
>> # Node ID 78f7b217e5d53ab981bb0b5ac0f43e8c46260c9f<br>
>> # Parent c923f4a9494619665bf49db7ae0e250e2f8c4ec7<br>
>> replace sse_sp(residual, ZERO) by ssd_s(residual)<br>
>><br>
>> diff -r c923f4a94946 -r 78f7b217e5d5 source/Lib/TLibEncoder/TEncSearch.cpp<br>
>> --- a/source/Lib/TLibEncoder/TEncSearch.cpp Mon Jul 14 17:27:04 2014 +0530<br>
>> +++ b/source/Lib/TLibEncoder/TEncSearch.cpp Tue Jul 15 17:51:30 2014 -0700<br>
>> @@ -2374,9 +2374,8 @@<br>
>> if ((cu->getSlice()->getPPS()->getTransquantBypassEnableFlag()))<br>
>> {<br>
>> bIsTQBypassEnable = true; // mark that the first iteration is to cost TQB mode.<br>
>> - tqBypassMode = 2;<br>
>> - if (m_param->bLossless)<br>
>> - tqBypassMode = 1;<br>
>> + if (!m_param->bLossless)<br>
>> + tqBypassMode = 2;<br>
><br>
>The patch looks good except this part, I'd like Ashok to review this<br>
>change. it looks unrelated to the rest of the patch anyway.<br>
><br>
Its a part of another patch, please remove it.<br></blockquote><div><br></div><div>We can push the above changes in a separate patch. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mailman.videolan.org/pipermail/x265-devel/attachments/20140716/c981f17a/attachment-0001.html" target="_blank">http://mailman.videolan.org/pipermail/x265-devel/attachments/20140716/c981f17a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 15 Jul 2014 21:29:20 -0500<br>
From: Steve Borho <<a href="mailto:steve@borho.org">steve@borho.org</a>><br>
To: Development for x265 <<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a>><br>
Subject: Re: [x265] [PATCH] replace sse_sp(residual, ZERO) by<br>
ssd_s(residual)<br>
Message-ID: <<a href="mailto:20140716022920.GA86129@zeppelin.attlocal.net">20140716022920.GA86129@zeppelin.attlocal.net</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 07/16, chen wrote:<br>
><br>
><br>
> At 2014-07-16 07:32:51,"Steve Borho" <<a href="mailto:steve@borho.org">steve@borho.org</a>> wrote:<br>
> >On 07/15, Min Chen wrote:<br>
> >> # HG changeset patch<br>
> >> # User Min Chen <a href="mailto:chenm003@163.com">chenm003@163.com</a>><br>
> >> # Date 1405471890 25200<br>
> >> # Node ID 78f7b217e5d53ab981bb0b5ac0f43e8c46260c9f<br>
> >> # Parent c923f4a9494619665bf49db7ae0e250e2f8c4ec7<br>
> >> replace sse_sp(residual, ZERO) by ssd_s(residual)<br>
> >><br>
> >> diff -r c923f4a94946 -r 78f7b217e5d5 source/Lib/TLibEncoder/TEncSearch.cpp<br>
> >> --- a/source/Lib/TLibEncoder/TEncSearch.cpp Mon Jul 14 17:27:04 2014 +0530<br>
> >> +++ b/source/Lib/TLibEncoder/TEncSearch.cpp Tue Jul 15 17:51:30 2014 -0700<br>
> >> @@ -2374,9 +2374,8 @@<br>
> >> if ((cu->getSlice()->getPPS()->getTransquantBypassEnableFlag()))<br>
> >> {<br>
> >> bIsTQBypassEnable = true; // mark that the first iteration is to cost TQB mode.<br>
> >> - tqBypassMode = 2;<br>
> >> - if (m_param->bLossless)<br>
> >> - tqBypassMode = 1;<br>
> >> + if (!m_param->bLossless)<br>
> >> + tqBypassMode = 2;<br>
> ><br>
> >The patch looks good except this part, I'd like Ashok to review this<br>
> >change. it looks unrelated to the rest of the patch anyway.<br>
> ><br>
> Its a part of another patch, please remove it.<br>
<br>
ok, queued without this chunk<br>
<br>
--<br>
Steve Borho<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 16 Jul 2014 02:19:15 -0500<br>
From: Steve Borho <<a href="mailto:steve@borho.org">steve@borho.org</a>><br>
To: Development for x265 <<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a>><br>
Subject: Re: [x265] A few warnings from GCC 4.8.2<br>
Message-ID:<br>
<CACD6pqP26HDt6JM2wmG7Ko61cr8HXCZ=<a href="mailto:vKbyE%2BrmecVQLAWEzQ@mail.gmail.com">vKbyE+rmecVQLAWEzQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Sun, Jul 13, 2014 at 4:33 PM, Mario Rohkr?mer <<a href="mailto:contact@ligh.de">contact@ligh.de</a>> wrote:<br>
> level.cpp<br>
> +----<br>
> h:/MSYS/home/LigH/x265/source/encoder/level.cpp: In function 'void<br>
> x265::determineLevel(const x265_param&, x265::Profile::Name&,<br>
> x265::Level::Name&, x265::Level::Tier&)':<br>
> h:/MSYS/home/LigH/x265/source/encoder/level.cpp:143:24: warning: array<br>
> subscript is above array bounds [-Warray-bounds]<br>
> while (levels[i].levelIdc < param.levelIdc && levels[i].levelIdc)<br>
> ^<br>
> h:/MSYS/home/LigH/x265/source/encoder/level.cpp:143:24: warning: array<br>
> subscript is above array bounds [-Warray-bounds]<br>
> +----<br>
<br>
I have a patch for this; gcc took quite some convincing that the loop<br>
bounds were correct. I'll push it tomorrow after some testing.<br>
<br>
> ratecontrol.cpp<br>
> +----<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp: In member function<br>
> 'bool x265::RateControl::initPass2()':<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:<br>
> 'minVal' may be used uninitialized in this function [-Wmaybe-uninitialized]<br>
> bool RateControl::initPass2()<br>
> ^<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:<br>
> 'maxVal' may be used uninitialized in this function [-Wmaybe-uninitialized]<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning: 'a'<br>
> may be used uninitialized in this function [-Wmaybe-uninitialized]<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:<br>
> 'minVal' may be used uninitialized in this function [-Wmaybe-uninitialized]<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:<br>
> 'maxVal' may be used uninitialized in this function [-Wmaybe-uninitialized]<br>
> h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning: 'a'<br>
> may be used uninitialized in this function [-Wmaybe-uninitialized]<br>
> +----<br>
<br>
These I've tracked to the CLIP_DURATION() macros which map to Clip3(<br>
MIN, MAX, f ) where MIN and MAX are constant floats. I haven't the<br>
slightest clue why GCC thinks the minVal/maxVal arguments might be<br>
uninitialized, when they are constants: 0.01 and 1.00.<br>
<br>
This is gcc 4.8.1. Older versions of gcc don't seem to complain about it.<br>
<br>
--<br>
Steve Borho<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<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>
<br>
<br>
------------------------------<br>
<br>
End of x265-devel Digest, Vol 14, Issue 45<br>
******************************************<br>
</blockquote></div><br></div></div>