[x265] x265-devel Digest, Vol 14, Issue 45

Ashok Kumar Mishra ashok at multicorewareinc.com
Wed Jul 16 12:52:52 CEST 2014


On Wed, Jul 16, 2014 at 3:30 PM, <x265-devel-request at videolan.org> wrote:

> Send x265-devel mailing list submissions to
>         x265-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mailman.videolan.org/listinfo/x265-devel
> or, via email, send a message with subject or body 'help' to
>         x265-devel-request at videolan.org
>
> You can reach the person managing the list at
>         x265-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of x265-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: [PATCH] replace sse_sp(residual, ZERO) by ssd_s(residual)
>       (chen)
>    2. Re: [PATCH] replace sse_sp(residual, ZERO) by ssd_s(residual)
>       (Steve Borho)
>    3. Re: A few warnings from GCC 4.8.2 (Steve Borho)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 16 Jul 2014 07:38:47 +0800 (CST)
> From: chen  <chenm003 at 163.com>
> To: "Development for x265" <x265-devel at videolan.org>
> Subject: Re: [x265] [PATCH] replace sse_sp(residual, ZERO) by
>         ssd_s(residual)
> Message-ID: <643dec21.f6c.1473c648855.Coremail.chenm003 at 163.com>
> Content-Type: text/plain; charset="gbk"
>
>
>
> At 2014-07-16 07:32:51,"Steve Borho" <steve at borho.org> wrote:
> >On 07/15, Min Chen wrote:
> >> # HG changeset patch
> >> # User Min Chen chenm003 at 163.com>
> >> # Date 1405471890 25200
> >> # Node ID 78f7b217e5d53ab981bb0b5ac0f43e8c46260c9f
> >> # Parent  c923f4a9494619665bf49db7ae0e250e2f8c4ec7
> >> replace sse_sp(residual, ZERO) by ssd_s(residual)
> >>
> >> diff -r c923f4a94946 -r 78f7b217e5d5
> source/Lib/TLibEncoder/TEncSearch.cpp
> >> --- a/source/Lib/TLibEncoder/TEncSearch.cpp  Mon Jul 14 17:27:04 2014
> +0530
> >> +++ b/source/Lib/TLibEncoder/TEncSearch.cpp  Tue Jul 15 17:51:30 2014
> -0700
> >> @@ -2374,9 +2374,8 @@
> >>      if ((cu->getSlice()->getPPS()->getTransquantBypassEnableFlag()))
> >>      {
> >>          bIsTQBypassEnable = true; // mark that the first iteration is
> to cost TQB mode.
> >> -        tqBypassMode = 2;
> >> -        if (m_param->bLossless)
> >> -            tqBypassMode = 1;
> >> +        if (!m_param->bLossless)
> >> +            tqBypassMode = 2;
> >
> >The patch looks good except this part, I'd like Ashok to review this
> >change. it looks unrelated to the rest of the patch anyway.
> >
> Its a part of another patch, please remove it.
>

We can push the above changes in a separate patch.

>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.videolan.org/pipermail/x265-devel/attachments/20140716/c981f17a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Jul 2014 21:29:20 -0500
> From: Steve Borho <steve at borho.org>
> To: Development for x265 <x265-devel at videolan.org>
> Subject: Re: [x265] [PATCH] replace sse_sp(residual, ZERO) by
>         ssd_s(residual)
> Message-ID: <20140716022920.GA86129 at zeppelin.attlocal.net>
> Content-Type: text/plain; charset=us-ascii
>
> On 07/16, chen wrote:
> >
> >
> > At 2014-07-16 07:32:51,"Steve Borho" <steve at borho.org> wrote:
> > >On 07/15, Min Chen wrote:
> > >> # HG changeset patch
> > >> # User Min Chen chenm003 at 163.com>
> > >> # Date 1405471890 25200
> > >> # Node ID 78f7b217e5d53ab981bb0b5ac0f43e8c46260c9f
> > >> # Parent  c923f4a9494619665bf49db7ae0e250e2f8c4ec7
> > >> replace sse_sp(residual, ZERO) by ssd_s(residual)
> > >>
> > >> diff -r c923f4a94946 -r 78f7b217e5d5
> source/Lib/TLibEncoder/TEncSearch.cpp
> > >> --- a/source/Lib/TLibEncoder/TEncSearch.cpp        Mon Jul 14
> 17:27:04 2014 +0530
> > >> +++ b/source/Lib/TLibEncoder/TEncSearch.cpp        Tue Jul 15
> 17:51:30 2014 -0700
> > >> @@ -2374,9 +2374,8 @@
> > >>      if ((cu->getSlice()->getPPS()->getTransquantBypassEnableFlag()))
> > >>      {
> > >>          bIsTQBypassEnable = true; // mark that the first iteration
> is to cost TQB mode.
> > >> -        tqBypassMode = 2;
> > >> -        if (m_param->bLossless)
> > >> -            tqBypassMode = 1;
> > >> +        if (!m_param->bLossless)
> > >> +            tqBypassMode = 2;
> > >
> > >The patch looks good except this part, I'd like Ashok to review this
> > >change. it looks unrelated to the rest of the patch anyway.
> > >
> > Its a part of another patch, please remove it.
>
> ok, queued without this chunk
>
> --
> Steve Borho
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 16 Jul 2014 02:19:15 -0500
> From: Steve Borho <steve at borho.org>
> To: Development for x265 <x265-devel at videolan.org>
> Subject: Re: [x265] A few warnings from GCC 4.8.2
> Message-ID:
>         <CACD6pqP26HDt6JM2wmG7Ko61cr8HXCZ=
> vKbyE+rmecVQLAWEzQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Jul 13, 2014 at 4:33 PM, Mario Rohkr?mer <contact at ligh.de> wrote:
> > level.cpp
> > +----
> > h:/MSYS/home/LigH/x265/source/encoder/level.cpp: In function 'void
> > x265::determineLevel(const x265_param&, x265::Profile::Name&,
> > x265::Level::Name&, x265::Level::Tier&)':
> > h:/MSYS/home/LigH/x265/source/encoder/level.cpp:143:24: warning: array
> > subscript is above array bounds [-Warray-bounds]
> >          while (levels[i].levelIdc < param.levelIdc &&
> levels[i].levelIdc)
> >                         ^
> > h:/MSYS/home/LigH/x265/source/encoder/level.cpp:143:24: warning: array
> > subscript is above array bounds [-Warray-bounds]
> > +----
>
> I have a patch for this; gcc took quite some convincing that the loop
> bounds were correct.  I'll push it tomorrow after some testing.
>
> > ratecontrol.cpp
> > +----
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp: In member function
> > 'bool x265::RateControl::initPass2()':
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:
> > 'minVal' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> >  bool RateControl::initPass2()
> >       ^
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:
> > 'maxVal' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning: 'a'
> > may be used uninitialized in this function [-Wmaybe-uninitialized]
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:
> > 'minVal' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning:
> > 'maxVal' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> > h:/MSYS/home/LigH/x265/source/encoder/ratecontrol.cpp:731:6: warning: 'a'
> > may be used uninitialized in this function [-Wmaybe-uninitialized]
> > +----
>
> These I've tracked to the CLIP_DURATION() macros which map to Clip3(
> MIN, MAX, f ) where MIN and MAX are constant floats.  I haven't the
> slightest clue why GCC thinks the minVal/maxVal arguments might be
> uninitialized, when they are constants: 0.01 and 1.00.
>
> This is gcc 4.8.1.  Older versions of gcc don't seem to complain about it.
>
> --
> Steve Borho
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
> ------------------------------
>
> End of x265-devel Digest, Vol 14, Issue 45
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140716/fa6427e7/attachment-0001.html>


More information about the x265-devel mailing list