# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414489826 -3600
# Tue Oct 28 10:50:26 2014 +0100
Make FrameEncoder partially virtual so it can be overloaded
FrameEncoder is a logical place to use a hardware accelerator or an alternative
core encoder
On 02/03/2015 07:21 PM, Steve Borho wrote:
m_frameEncoder = new FrameEncoderKalray[m_param-frameNumThreads] should
still work unless you plan to use a mixture of FrameEncoder and
FrameEncoderKalray.
Actually it doesn't. Because m_frameEncoder is declared as an array of
FrameEncoder, later
On 02/02/2015 11:43 AM, Deepthi Nandakumar wrote:
We ran into this exact issue doing performance analyses on 40-core+ machines,
where we found slicetypeDecide being a bottleneck. Please checkout this commit.
Changeset:
9033 (d36211d0190f) slicetype: allow queue to fill past full
and probably some trickery to
handle zero-latency encoding but we will need to do some of these changes for
our encoder so I'd love to have some feedback from you and maybe even agree to
have such changes upstream !
Regards
Nicolas
--
Nicolas Morey Chaisemartin
Phone : +33 6 42 46 68 87
No problems.. Steve told me that it might be possible to get these patches in,
but if you'd rather not, I'll keep them on my end.
If people are interested, these patches are accessible on my github:
https://github.com/nmorey/x265.git
Nicolas
On 11/04/2014 11:40 AM, Deepthi Nandakumar wrote:
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414077144 -7200
# Thu Oct 23 16:12:24 2014 +0200
Add entropy coder support for tile header generation
---
source/common/slice.h | 11 +++
source/encoder/encoder.cpp | 3 +++
source/encoder
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414492715 -3600
# Tue Oct 28 11:38:35 2014 +0100
Modify WPP Entry point generation to be more generic
---
source/encoder/entropy.cpp | 10 +-
source/encoder/entropy.h| 2 +-
source
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414664871 -3600
# Thu Oct 30 11:27:51 2014 +0100
Save intra mode in lowres
---
source/common/lowres.cpp | 2 ++
source/common/lowres.h | 1 +
source/encoder/slicetype.cpp | 1 +
3 files changed, 4
On 10/30/2014 05:07 PM, Steve Borho wrote:
On 10/30, Nicolas Morey-Chaisemartin wrote:
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414664871 -3600
# Thu Oct 30 11:27:51 2014 +0100
Save intra mode in lowres
I assume this is a precursor to a --superfast
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414664871 -3600
# Thu Oct 30 11:27:51 2014 +0100
Save intra mode in lowres
---
source/common/lowres.cpp | 2 ++
source/common/lowres.h | 1 +
source/encoder/slicetype.cpp | 1 +
3 files changed, 4
On 10/28/2014 02:24 AM, Steve Borho wrote:
if --ctu 16 is used, then the max TU size is actually 4. I think it
would be more correct as: X265_MIN(g_maxLog2CUSize, 5);
My bad, I queued the wrong patch version...
sps-quadtreeTULog2MinSize = 2;
sps-quadtreeTUMaxDepthInter =
On 10/28/2014 01:51 AM, Steve Borho wrote:
On 10/27, Nicolas Morey-Chaisemartin wrote:
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414074805 -7200
# Thu Oct 23 15:33:25 2014 +0200
Add flag to enable/disable temporal MVP
queued locally. I had to apply
Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414077144 -7200
# Thu Oct 23 16:12:24 2014 +0200
Add support for tile header generation
---
source/common/slice.h | 8
source/encoder/encoder.cpp | 3 +++
source/encoder/entropy.cpp | 22 --
3 files
On 10/28/2014 05:10 PM, Steve Borho wrote:
On 10/28, Nicolas Morey-Chaisemartin wrote:
Hi,
I don't know if this makes sense for the mainstream but we use x265 to
generate a bitstream with tiles. This is a patch that simply add the
capabilities to generate tile compliant headers although
Morey-Chaisemartin wrote:
Simply changing back the computation SEGV on master (worked on 1.3).
From the look of things, the number of layers in the Search class changed from
m_numLayers = g_log2Size[param.maxCUSize] - 2 + 1;
to
m_numLayers = g_log2Size[param.maxCUSize] - 2;
Some time ago
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414074805 -7200
# Thu Oct 23 15:33:25 2014 +0200
Add flag to enable/disable temporal MVP
---
source/CMakeLists.txt | 2 +-
source/common/cudata.cpp | 4 ++--
source/common/param.cpp| 2 ++
source
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1414077353 -7200
# Thu Oct 23 16:15:53 2014 +0200
[PATCH 1/1] Set tuQTMaxLog2Size to MIN(5, maxLog2CUSize)
---
source/common/param.cpp| 2 +-
source/encoder/encoder.cpp | 2 +-
source/encoder/search.cpp
---
source/common/param.cpp | 3 +++
source/x265.cpp | 3 +++
2 files changed, 6 insertions(+)
diff --git a/source/common/param.cpp b/source/common/param.cpp
index ce3f56e..cf256ab 100644
--- a/source/common/param.cpp
+++ b/source/common/param.cpp
@@ -557,6 +557,8 @@ int
---
source/Lib/TLibCommon/TComDataCU.cpp | 5 +++--
source/common/param.cpp | 2 ++
source/common/slice.h| 1 +
source/encoder/encoder.cpp | 1 +
source/encoder/entropy.cpp | 9 +
source/x265.h| 3 +++
6 files
Quick question about the max TU size.
It used to be something like
tuQTMaxLog2Size = MIN(5, maxLog2CUSize)
Now it is simply maxLog2CUSize -1.
It makes no difference for 64x64 CTU but it tends to worsen quality (or
increase bitrate) for smaller CTU sizes.
Is this a wanted behaviour and if so,
On 10/23/2014 04:46 PM, Steve Borho wrote:
ignoring the white-space and rebase issues, I'm fine with the patch. I
was actually considering doing this myself just this week.
Does the patch format (git format-patch) also works for you or do I need to
find a way to export it in hg format ?
/23/2014 04:39 PM, Steve Borho wrote:
On 10/23, Nicolas Morey-Chaisemartin wrote:
Quick question about the max TU size.
It used to be something like
tuQTMaxLog2Size = MIN(5, maxLog2CUSize)
Now it is simply maxLog2CUSize -1.
It makes no difference for 64x64 CTU but it tends to worsen quality
Just a quick question out of curiosity:
I assume these info will be used as hints and not as the actual mode to pick.
In this case, would it make sense to use fill these structs (partially at
least) with pre-analysis data?
I'm not sure what the gain could be but it seems a shame to just throw
in this - especially if you can also include some efficiency
(bitrate vs SSIM) metrics that describe the penalty moving from
X265_LOWRES_SCALE of 4 to higher scales.
On Mon, Jul 21, 2014 at 8:49 PM, Nicolas Morey-Chaisemartin
nmo...@kalray.eu wrote:
Hi,
We recently profiled x265 pre-analysis
On 07/21/2014 07:11 PM, Steve Borho wrote:
Interesting. I imagine much 4k content would work decently well even
with further downscaling of the lookahead pictures.
The lowres motion vectors are used in weight analysis as well, so that
file would need to be updated.
I'll have a look at it. It
On 07/22/2014 10:08 AM, Steve Borho wrote:
On 07/22, Nicolas Morey-Chaisemartin wrote:
I'll have a look at it. It doesn't semm as straight forward as the
other files though.
it is slightly more complicated; you'll want to scale up the block sizes
used for motion-compensated weight analysis
# HG changeset patch
# User Nicolas Morey-Chaisemartin nmo...@kalray.eu
# Date 1406020650 -7200
# Tue Jul 22 11:17:30 2014 +0200
# Node ID fc75f5f4f85e0d9441dc73b09ec60a36c20f
# Parent 4c9ce4db74d1c9768abc61290bd1bda002b79f4e
lowres: Enhanced scaling
* Replace hard coded values
Hi,
We recently profiled x265 pre-analysis to estimate what performance we could
reach using our accelerator and I was quite disappointed by the performance.
When running on a Core-i7 with AVX at roughly 2.7GHz, we barely reached the
30fps mark using ultrafast preset on a 4K video.
After a
to VBV.
Recovery Point SEI are now generated at each keyframe
In the near future we will be focusing on two-pass encoding and making
mode decision more efficient.
--
signature
*Nicolas Morey-Chaisemartin*kalray_logo http://www.kalray.eu/
*KALRAY SA*
Software Architect
is unlikely to
change, and that would be a good layer to migrate/off-load work.
Sounds great !
Now we just need to have an encoder working ;)
Thanks for the feedback.
--
Nicolas Morey Chaisemartin
Phone : +33 6 42 46 68 87
___
x265-devel mailing list
x265
.) and convert/transfer it to our core.
What is your opinion on this approach?
Is HM classes (at least structure wise) an interface stable enough to do this?
We are still in the design phase about this so any idea is more than welcome.
Regards
--
Nicolas Morey Chaisemartin
Phone : +33 6 42 46 68 87
31 matches
Mail list logo
