Re: [x265] dynamicHDR10 branch probably not cleaned?

2017-06-06 Thread Mario *LigH* Rohkrämer 

I mean "make clean-generated", not "make clean".

I am not sure which difference between them is intended. All I can tell is  
that executing the sequence


make clean-generated
make

rebuilds all the sub-targets ("encoder", "common", "cli") apparently  
completely, only the sub-target "dynamicHDR10" seems to build only changed  
files; you can see that ~5% are skipped. So I wonder if either CMake  
builds too little for dynamicHDR10, or too much for the rest, in case of  
this sequence. Depends on the intended meaning of this target.




Am 06.06.2017, 11:34 Uhr, schrieb Bhavna Hariharan  
:



On Mon, May 29, 2017 at 3:43 PM, Mario *LigH* Rohkrämer 
wrote:


I believe that the "dynamicHDR10" sub-target is not yet included in the
"clean-generated" rule, causing previously compiled files not to be  
deleted

in this directory branch when a cleanup was desired.

+
Scanning dependencies of target dynamicHDR10
[  1%] Building CXX object dynamicHDR10/CMakeFiles/dynami
cHDR10.dir/metadataFromJson.cpp.obj
+
# missing many more files here which are not built because their
compilation result probably still exists, despite a previous "make
clean-generated"



What are the files that aren't getting cleaned? I tried reproducing the
issue, all the dhdr10 files are being deleted after "make clean" and they
are re-generated after "make".



+
[  6%] Built target dynamicHDR10
Scanning dependencies of target encoder
+

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel





Regards,

Bhavna Hariharan



--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] MV refinement for multipass encoding

2017-06-06 Thread Pradeep Ramachandran 
On Mon, Jun 5, 2017 at 3:45 PM,  wrote:

> # HG changeset patch
> # User Ashok Kumar Mishra 
> # Date 1496656244 -19800
> #  Mon Jun 05 15:20:44 2017 +0530
> # Node ID c04d02d71f206431b6b6e60460b81dcc85fc5db5
> # Parent  de49a722b256d94c9ba30b5d88459026bea528b8
> MV refinement for multipass encoding
>

Pushed to default branch


>
> diff -r de49a722b256 -r c04d02d71f20 doc/reST/cli.rst
> --- a/doc/reST/cli.rst  Wed May 24 20:01:59 2017 +0530
> +++ b/doc/reST/cli.rst  Mon Jun 05 15:20:44 2017 +0530
> @@ -911,6 +911,12 @@
> inter modes for blocks of size one smaller than the min-cu-size of
> the
> incoming analysis data from the previous encode. Default disabled.
>
> +.. option:: --refine-mv
> +
> +   Enables refinement of motion vector for scaled video. Evaluates
> the best
> +   motion vector by searching the surrounding eight integer and
> subpel pixel
> +positions.
> +
>  Options which affect the transform unit quad-tree, sometimes referred to
>  as the residual quad-tree (RQT).
>
> diff -r de49a722b256 -r c04d02d71f20 source/CMakeLists.txt
> --- a/source/CMakeLists.txt Wed May 24 20:01:59 2017 +0530
> +++ b/source/CMakeLists.txt Mon Jun 05 15:20:44 2017 +0530
> @@ -29,7 +29,7 @@
>  option(STATIC_LINK_CRT "Statically link C runtime for release builds" OFF)
>  mark_as_advanced(FPROFILE_USE FPROFILE_GENERATE NATIVE_BUILD)
>  # X265_BUILD must be incremented each time the public API is changed
> -set(X265_BUILD 120)
> +set(X265_BUILD 121)
>  configure_file("${PROJECT_SOURCE_DIR}/x265.def.in"
> "${PROJECT_BINARY_DIR}/x265.def")
>  configure_file("${PROJECT_SOURCE_DIR}/x265_config.h.in"
> diff -r de49a722b256 -r c04d02d71f20 source/common/param.cpp
> --- a/source/common/param.cpp   Wed May 24 20:01:59 2017 +0530
> +++ b/source/common/param.cpp   Mon Jun 05 15:20:44 2017 +0530
> @@ -280,6 +280,7 @@
>  param->scaleFactor = 0;
>  param->intraRefine = 0;
>  param->interRefine = 0;
> +param->mvRefine = 0;
>  }
>
>  int x265_param_default_preset(x265_param* param, const char* preset,
> const char* tune)
> @@ -963,6 +964,7 @@
>  OPT("scale-factor") p->scaleFactor = atoi(value);
>  OPT("refine-intra")p->intraRefine = atobool(value);
>  OPT("refine-inter")p->interRefine = atobool(value);
> +OPT("refine-mv")p->mvRefine = atobool(value);
>  else
>  return X265_PARAM_BAD_NAME;
>  }
> @@ -1685,6 +1687,7 @@
>  s += sprintf(s, " scale-factor=%d", p->scaleFactor);
>  s += sprintf(s, " refine-intra=%d", p->intraRefine);
>  s += sprintf(s, " refine-inter=%d", p->interRefine);
> +s += sprintf(s, " refine-mv=%d", p->mvRefine);
>  BOOL(p->bLimitSAO, "limit-sao");
>  s += sprintf(s, " ctu-info=%d", p->bCTUInfo);
>  #undef BOOL
> diff -r de49a722b256 -r c04d02d71f20 source/encoder/analysis.cpp
> --- a/source/encoder/analysis.cpp   Wed May 24 20:01:59 2017 +0530
> +++ b/source/encoder/analysis.cpp   Mon Jun 05 15:20:44 2017 +0530
> @@ -2267,14 +2267,16 @@
>  int cuIdx = (mode.cu.m_cuAddr *
> parentCTU.m_numPartitions) + cuGeom.absPartIdx;
>  mode.cu.m_mergeFlag[pu.puAbsPartIdx] =
> interDataCTU->mergeFlag[cuIdx + part];
>  mode.cu.setPUInterDir(interDataCTU->interDir[cuIdx +
> part], pu.puAbsPartIdx, part);
> -for (int dir = 0; dir < m_slice->isInterB() + 1;
> dir++)
> +for (int list = 0; list < m_slice->isInterB() + 1;
> list++)
>  {
> -mode.cu.setPUMv(dir, interDataCTU->mv[dir][cuIdx
> + part], pu.puAbsPartIdx, part);
> -mode.cu.setPURefIdx(dir,
> interDataCTU->refIdx[dir][cuIdx + part], pu.puAbsPartIdx, part);
> -mode.cu.m_mvpIdx[dir][pu.puAbsPartIdx] =
> interDataCTU->mvpIdx[dir][cuIdx + part];
> +mode.cu.setPUMv(list,
> interDataCTU->mv[list][cuIdx + part], pu.puAbsPartIdx, part);
> +mode.cu.setPURefIdx(list,
> interDataCTU->refIdx[list][cuIdx + part], pu.puAbsPartIdx, part);
> +mode.cu.m_mvpIdx[list][pu.puAbsPartIdx] =
> interDataCTU->mvpIdx[list][cuIdx + part];
>  }
>  if (!mode.cu.m_mergeFlag[pu.puAbsPartIdx])
>  {
> +if (m_param->mvRefine)
> +m_me.setSourcePU(*mode.fencYuv, pu.ctuAddr,
> pu.cuAbsPartIdx, pu.puAbsPartIdx, pu.width, pu.height,
> m_param->searchMethod, m_param->subpelRefine, false);
>  //AMVP
>  MV mvc[(MD_ABOVE_LEFT + 1) * 2 + 2];
>  mode.cu.getNeighbourMV(part, pu.puAbsPartIdx,
> mode.interNeighbours);
> @@ -2285,6 +2287,12 @@
>  continue;
>  mode.cu.getPMV(mode.interNeighbours, list,
> ref,

Re: [x265] dynamicHDR10 branch probably not cleaned?

2017-06-06 Thread Bhavna Hariharan 
On Mon, May 29, 2017 at 3:43 PM, Mario *LigH* Rohkrämer 
wrote:

> I believe that the "dynamicHDR10" sub-target is not yet included in the
> "clean-generated" rule, causing previously compiled files not to be deleted
> in this directory branch when a cleanup was desired.
>
> +
> Scanning dependencies of target dynamicHDR10
> [  1%] Building CXX object dynamicHDR10/CMakeFiles/dynami
> cHDR10.dir/metadataFromJson.cpp.obj
> +
> # missing many more files here which are not built because their
> compilation result probably still exists, despite a previous "make
> clean-generated"
>

What are the files that aren't getting cleaned? I tried reproducing the
issue, all the dhdr10 files are being deleted after "make clean" and they
are re-generated after "make".


> +
> [  6%] Built target dynamicHDR10
> Scanning dependencies of target encoder
> +
>
> --
>
> Fun and success!
> Mario *LigH* Rohkrämer
> mailto:cont...@ligh.de
>
> ___
> x265-devel mailing list
> x265-devel@videolan.org
> https://mailman.videolan.org/listinfo/x265-devel




Regards,

Bhavna Hariharan
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel