f777504f640260337974848c7d5d7a3f064bbb45 changed a - in +
---
libavcodec/h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 7a81a71..7f9683e 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -3896,7 +3896,7 @@ static int
On Sat, 22 Feb 2014, Luca Barbato wrote:
f777504f640260337974848c7d5d7a3f064bbb45 changed a - in +
---
libavcodec/h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This seems correct.
// Martin
___
libav-devel mailing list
And do not left shift a negative value while at it.
CC: libav-sta...@libav.org
---
Maybe this way looks nicer.
libavcodec/hevc_filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
index eb3f5f3..37cbbd4 100644
---
On 22 Feb 2014, at 02:47, Luca Barbato lu_z...@gentoo.org wrote:
On 22/02/14 02:20, Tim Walker wrote:
On 21 Feb 2014, at 21:18, Luca Barbato lu_z...@gentoo.org wrote:
Can you elaborate?
currently avconv passes as codec timebase the filter timebase and it is
usually 1/90k or such value.
On 22/02/14 15:03, Tim Walker wrote:
Are you setting FrameRateExtN and FrameRateExtD? Those aren't made
for the timebase, only the frame rate.
Yes, the frame-rate is at best a hint or unused, the problem is that it
rejects bogus values.
We have this problem and solving it doesn't start if not
On 22/02/14 06:54, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
configure | 5 +
libavutil/x86/cpu.h | 3 +++
2 files changed, 8 insertions(+)
Looks fine to me.
___
libav-devel mailing list
On 22/02/14 06:53, James Almer wrote:
These are the missing instruction sets introduced with Haswell/Piledriver
CPUs.
Last two patches are based on x264 detection code.
The set doesn't look bad at all but I'm wondering about it's usage:
James Almer (3):
x86: add missing XOP checks and
On 22/02/14 1:29 PM, Luca Barbato wrote:
On 22/02/14 06:53, James Almer wrote:
These are the missing instruction sets introduced with Haswell/Piledriver
CPUs.
Last two patches are based on x264 detection code.
The set doesn't look bad at all but I'm wondering about it's usage:
James
On 22/02/14 17:42, James Almer wrote:
On 22/02/14 1:29 PM, Luca Barbato wrote:
On 22/02/14 06:53, James Almer wrote:
These are the missing instruction sets introduced with Haswell/Piledriver
CPUs.
Last two patches are based on x264 detection code.
The set doesn't look bad at all but I'm
Hi,
following patch set holds Christophe's remaining DCA changes with
arm asm changes from me. I did a couple of minor cosmetic changes
and changed some commit messages. The pre-scaling of the lfe_dir
coefficients uses a macro so that it can be easily be undone when
required. PATCH 5 is further
From: Christophe Gisquet christophe.gisq...@gmail.com
Timings for Arrandale:
CSSE
win32: 2108 334
win64: 1152 322
Factorizing the inner loop with a call/jmp is a 15 cycles cost, even with
the jmp destination being aligned.
Unrolling for ARCH_X86_64 is a 20 cycles gain.
From: Christophe Gisquet christophe.gisq...@gmail.com
This change is inspired by x86 asm where it frees a register.
Signed-off-by: Janne Grunau janne-li...@jannau.net
---
libavcodec/dcadsp.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dcadsp.c
From: Christophe Gisquet christophe.gisq...@gmail.com
The scaling factor is constant so it is faster to scale the
FIR coefficients in the tables during compilation.
Signed-off-by: Janne Grunau janne-li...@jannau.net
---
libavcodec/arm/dcadsp_init_arm.c | 12 +-
libavcodec/arm/dcadsp_neon.S
From: Christophe Gisquet christophe.gisq...@gmail.com
Results for Arrandale/Windows:
32: 1670 - 316
64: 728 - 298
Signed-off-by: Janne Grunau janne-li...@jannau.net
---
libavcodec/x86/dcadsp.asm| 87
libavcodec/x86/dcadsp_init.c | 4 ++
2 files
From: Christophe Gisquet christophe.gisq...@gmail.com
The vector dequantization has a test in a loop preventing effective SIMD
implementation. By moving it out of the loop, this loop can be DSPized.
Therefore, modify the current DSP implementation. In particular, the
DSP implementation no longer
Based on a patch from Christophe Gisquet.
Unrolling of the m == 0 case avoids a possible use of the uninitilized
value sum when s-predictor_history is not set. I failed to find a
sample for it. It also reduced the cycle count from 220 to 150 on
sandy bridge, x86_64 linux, gcc 4.8.2 compared to
---
libavcodec/arm/dcadsp_init_arm.c | 46 ++--
libavcodec/arm/dcadsp_neon.S | 29 +
2 files changed, 35 insertions(+), 40 deletions(-)
diff --git a/libavcodec/arm/dcadsp_init_arm.c b/libavcodec/arm/dcadsp_init_arm.c
index
On Fri, 26 Apr 2013 12:21:40 +0200, Anton Khirnov an...@khirnov.net wrote:
---
doc/APIchanges |1 +
libavresample/avresample.h |8
libavresample/utils.c |5 +
3 files changed, 14 insertions(+)
2/3 and 3/3 approved by Justin on IRC in May 2013,
On Wednesday 19 February 2014 22:43:08 Luca Barbato wrote:
+#define PX(op, x) \
+PU(x0 op ((x) hshift))
+#define PY(op, y) \
+PU(y0 op ((y) vshift))
+#define IS_INTRA(xop, x, yop, y) \
+MVF(PX(xop, x), PY(yop, y)).is_intra
This seems rather ugly, why not simply replace each
On Wednesday 19 February 2014 22:43:11 Luca Barbato wrote:
---
libavcodec/hevcdsp_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 104c1eb..f02e175 100644
--- a/libavcodec/hevcdsp_template.c
On Wednesday 19 February 2014 22:43:12 Luca Barbato wrote:
---
libavcodec/hevc_filter.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
OK.
___
libav-devel mailing list
libav-devel@libav.org
On Wednesday 19 February 2014 22:43:13 Luca Barbato wrote:
+if (x 0)
+x_pos = -((-x / 2) s-sps-pixel_shift);
This seems very weird to me, x and y are used to get an index inside the
chroma frame so x should never be negative.
On 11/02/13 09:21 am, Diego Biurrun wrote:
It is a processor feature, so it belongs there.
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 5f49265..b635d33 100755
--- a/configure
+++ b/configure
@@ -1194,6 +1194,7 @@
On 22/02/14 21:24, Guillaume Martres wrote:
This seems rather ugly, why not simply replace each xshift by * (1
because of OMGspeed and the set being wrote in sort of autopilot. I
wanted to make sure clang+asan miscompilations weren't related to those
UB. (they are not =/)
lu
On 23/02/14 00:52, Dave Yeo wrote:
HAVE_LIST has ARCH_EXT_LIST
ARCH_EXT_LIST has ARCH_EXT_LIST_X86
I'm wondering why it is broken for you since it should not.
lu
___
libav-devel mailing list
libav-devel@libav.org
On 22/02/14 21:34, Guillaume Martres wrote:
On Wednesday 19 February 2014 22:43:13 Luca Barbato wrote:
+if (x 0)
+x_pos = -((-x / 2) s-sps-pixel_shift);
This seems very weird to me, x and y are used to get an index inside the
chroma frame so x
On 22/02/14 11:57 PM, Luca Barbato wrote:
On 23/02/14 00:52, Dave Yeo wrote:
HAVE_LIST has ARCH_EXT_LIST
ARCH_EXT_LIST has ARCH_EXT_LIST_X86
I'm wondering why it is broken for you since it should not.
lu
https://fate.libav.org/x86.os2.444/2014002516
Probably related.
On 23/02/14 04:02, James Almer wrote:
On 22/02/14 11:57 PM, Luca Barbato wrote:
On 23/02/14 00:52, Dave Yeo wrote:
HAVE_LIST has ARCH_EXT_LIST
ARCH_EXT_LIST has ARCH_EXT_LIST_X86
I'm wondering why it is broken for you since it should not.
lu
---
avconv_opt.c| 12 +++-
doc/avconv.texi |2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/avconv_opt.c b/avconv_opt.c
index d62d11f..7bc41c9 100644
--- a/avconv_opt.c
+++ b/avconv_opt.c
@@ -463,6 +463,8 @@ static void add_input_streams(OptionsContext *o,
29 matches
Mail list logo
