Re: [libav-devel] [PATCH 2/2] swscale: Add GRAY12

[Vittorio Giovara]

On Thu, Nov 3, 2016 at 4:45 PM, Luca Barbato  wrote:
> ---
>  libswscale/input.c | 2 ++
>  libswscale/swscale_internal.h  | 2 ++
>  libswscale/swscale_unscaled.c  | 1 +
>  libswscale/utils.c | 2 ++
>  tests/ref/fate/filter-pixdesc-gray12be | 1 +
>  tests/ref/fate/filter-pixdesc-gray12le | 1 +
>  tests/ref/fate/filter-pixfmts-copy | 2 ++
>  tests/ref/fate/filter-pixfmts-null | 2 ++
>  tests/ref/fate/filter-pixfmts-scale| 2 ++
>  tests/ref/fate/filter-pixfmts-vflip| 2 ++
>  10 files changed, 17 insertions(+)
>  create mode 100644 tests/ref/fate/filter-pixdesc-gray12be
>  create mode 100644 tests/ref/fate/filter-pixdesc-gray12le

set seems ok to me
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/5] [RFC] configure: more fine-grained link-time dependency settings

[Janne Grunau]

On 2016-10-25 23:30:50 +0200, Diego Biurrun wrote:
> On Fri, Sep 09, 2016 at 08:08:55PM +0200, Janne Grunau wrote:
> > On 2016-09-05 20:31:39 +0200, Diego Biurrun wrote:
> > > Previously all external library dependencies were added as link-time
> > > dependencies to all components. This adds bogus dependencies to some
> > > components, so only add dependencies to components if said components
> > > actually make use of a dependency.
> > > ---
> > > 
> > > This can still be improved a bit I guess.  Better function names welcome 
> > > for
> > > starters. Janne had some more substantive comments. Our pkg-config files 
> > > have
> > > many more issues, even after this patch...
> > 
> > I don't think this is the right approach.  The fundamental problem in 
> > this patch is that it mixes the checks functions/libraries with the 
> > information which part of libav uses the library.  The basic idea would 
> > be to set fn_$(func)_extralibs in check_lib(2) and have components 
> > depend fn_$(func).  We can't check for multiple functions in 
> > check_lib(2) after that at once but we don't do it atm.  The 
> > dep_extralibs handling in check_deps() needs to be modified (looks like 
> > it is missing in this patch).
> 
> I'm not sure if we're on the same page here. I attached a very rough sketch
> of what I interpret to be your idea. It's not exactly turning out simpler,
> so if I'm going down the wrong path, I'm all ears for better suggestions.

It's more or less what I had in mind. I didn't thought of need to match 
components back to libraries. But I never claimed that it would be 
simpler. It does the right thing wrt to deps. Your previous patch would 
still have linked libavformat against bzlib even then the matroska 
demuxer was disabled (and bzlib is present and not disabled explicitly).

> 
> diff --git a/configure b/configure
> index 6a04c33..ba8e3c8 100755
> --- a/configure
> +++ b/configure
> @@ -621,10 +621,11 @@ do_check_deps(){
>  eval dep_sgs="\$${cfg}_suggest"
>  eval dep_ifa="\$${cfg}_if"
>  eval dep_ifn="\$${cfg}_if_any"
> +eval dep_lbs="\$${cfg}_libs"
>  
> -pushvar cfg dep_all dep_any dep_sel dep_sgs dep_ifa dep_ifn
> +pushvar cfg dep_all dep_any dep_sel dep_sgs dep_ifa dep_ifn dep_lbs
>  do_check_deps $dep_all $dep_any $dep_sel $dep_sgs $dep_ifa $dep_ifn
> -popvar cfg dep_all dep_any dep_sel dep_sgs dep_ifa dep_ifn
> +popvar cfg dep_all dep_any dep_sel dep_sgs dep_ifa dep_ifn dep_lbs
>  
>  [ -n "$dep_ifa" ] && { enabled_all $dep_ifa && enable_weak $cfg; }
>  [ -n "$dep_ifn" ] && { enabled_any $dep_ifn && enable_weak $cfg; }
> @@ -635,6 +636,24 @@ do_check_deps(){
>  if enabled $cfg; then
>  enable_deep $dep_sel
>  enable_deep_weak $dep_sgs
> +for lib in $dep_lbs; do
> +eval append dep_extralibs "\$${lib}_extralibs"
> +done
> +if test -n "$dep_extralibs"; then
> +case $cfg in
> +*coder|*parser|*bsf)
> +add_extralibs_lib avcodec $dep_extralibs ;;
> +*muxer)
> +add_extralibs_lib avformat $dep_extralibs ;;
> +*indev|*outdev)
> +add_extralibs_lib avdevice $dep_extralibs ;;
> +*filter)
> +add_extralibs_lib avfilter $dep_extralibs ;;
> +*)
> +add_extralibs $dep_extralibs ;;
> +esac
> +unset dep_extralibs
> +fi
>  fi
>  
>  disable ${cfg}_checking
> @@ -648,8 +667,6 @@ check_deps(){
>  
>  for cfg in $allopts; do
>  enabled $cfg || continue
> -eval dep_extralibs="\$${cfg}_extralibs"
> -test -n "$dep_extralibs" && add_extralibs $dep_extralibs
>  done
>  }
>  
> @@ -739,6 +756,13 @@ add_extralibs(){
>  prepend extralibs $($ldflags_filter "$@")
>  }
>  
> +add_extralibs_lib(){
> +lib=$1
> +shift
> +prepend extralibs_${lib} $($ldflags_filter "$@")
> +unique  extralibs_${lib}
> +}
> +
>  add_host_cppflags(){
>  append host_cppflags "$@"
>  }
> @@ -1001,10 +1025,11 @@ EOF
>  
>  check_lib(){
>  log check_lib "$@"
> -headers="$1"
> -funcs="$2"
> -shift 2
> -check_func_headers "$headers" "$funcs" "$@" && add_extralibs "$@"
> +name="$1"
> +headers="$2"
> +func="$3"
> +shift 3
> +check_func_headers "$headers" "$func" "$@" && eval 
> ${name}_extralibs="\$@"

I would have used $func as identifier for the extralibs instead of 
introducing an extra identifier.

>  }
>  
>  check_pkg_config(){
> @@ -1100,7 +1125,7 @@ require(){
>  headers="$2"
>  func="$3"
>  shift 3
> -check_lib "$headers" $func "$@" || die "ERROR: $name not found"
> +check_lib $name "$headers" $func "$@" || die "ERROR: $name not found"
>  }
>  
>  require_pkg_config(){
> 

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Martin Storsjö]

On Thu, 3 Nov 2016, Janne Grunau wrote:


On 2016-11-02 14:58:41 +0200, Martin Storsjö wrote:

---
 libavcodec/aarch64/Makefile  |   2 +
 libavcodec/aarch64/vp9dsp_init_aarch64.c | 139 ++
 libavcodec/aarch64/vp9mc_neon.S  | 733 +++
 libavcodec/vp9.h |   1 +
 libavcodec/vp9dsp.c  |   2 +
 5 files changed, 877 insertions(+)
 create mode 100644 libavcodec/aarch64/vp9dsp_init_aarch64.c
 create mode 100644 libavcodec/aarch64/vp9mc_neon.S

diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 764bedc..6f1227a 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -17,6 +17,7 @@ OBJS-$(CONFIG_DCA_DECODER)  += 
aarch64/dcadsp_init.o
 OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
 OBJS-$(CONFIG_VC1_DECODER)  += aarch64/vc1dsp_init_aarch64.o
 OBJS-$(CONFIG_VORBIS_DECODER)   += aarch64/vorbisdsp_init.o
+OBJS-$(CONFIG_VP9_DECODER)  += aarch64/vp9dsp_init_aarch64.o

 # ARMv8 optimizations

@@ -43,3 +44,4 @@ NEON-OBJS-$(CONFIG_MPEGAUDIODSP)+= 
aarch64/mpegaudiodsp_neon.o
 NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/dcadsp_neon.o   
\
aarch64/synth_filter_neon.o
 NEON-OBJS-$(CONFIG_VORBIS_DECODER)  += aarch64/vorbisdsp_neon.o
+NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9mc_neon.o
diff --git a/libavcodec/aarch64/vp9dsp_init_aarch64.c 
b/libavcodec/aarch64/vp9dsp_init_aarch64.c
new file mode 100644
index 000..3d414af
--- /dev/null
+++ b/libavcodec/aarch64/vp9dsp_init_aarch64.c



+LOCAL_ALIGNED_16(uint8_t, temp, [((sz < 64 ? 2 * sz : 64) + 8) * sz]); 
   \


((1 + (sz < 64)) * sz + 8) * sz

nit, looks nicer imo. no need to change it


diff --git a/libavcodec/aarch64/vp9mc_neon.S
b/libavcodec/aarch64/vp9mc_neon.S
new file mode 100644
index 000..9ca2a32
--- /dev/null
+++ b/libavcodec/aarch64/vp9mc_neon.S
@@ -0,0 +1,733 @@
+/*
+ * Copyright (c) 2016 Google Inc.
+ *
+ * This file is part of Libav.
+ *
+ * Libav is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * Libav is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with Libav; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+const regular_filter, align=4


can't we use the constants from C? the single sign extend will be lost 
in the noise. same applies to the arm version


Yes, I guess we could. They are currently a static array in vp9dsp.c 
though, so they'd need to be made available from there.



+// All public functions in this file have the following signature:
+// typedef void (*vp9_mc_func)(uint8_t *dst, ptrdiff_t dst_stride,
+//const uint8_t *ref, ptrdiff_t ref_stride,
+//int h, int mx, int my);
+
+function ff_vp9_copy64_neon, export=1
+1:
+ldp x5,  x6,  [x2]
+stp x5,  x6,  [x0]
+ldp x5,  x6,  [x2, #16]


use more registers we have enough, probably not noticable


Ok, will try


+function ff_vp9_copy4_neon, export=1
+1:
+ld1 {v0.s}[0], [x2], x3
+ld1 {v1.s}[0], [x2], x3
+st1 {v0.s}[0], [x0], x1
+ld1 {v2.s}[0], [x2], x3
+st1 {v1.s}[0], [x0], x1
+ld1 {v3.s}[0], [x2], x3
+subsw4,  w4,  #4
+st1 {v2.s}[0], [x0], x1
+st1 {v3.s}[0], [x0], x1
+b.ne1b
+ret
+endfunc
+
+function ff_vp9_avg4_neon, export=1
+1:
+ld1r{v4.2s}, [x2], x3


is there a difference between ld1r and ld1 {}[0]? eiether way we should
just use one variant for loading 4 bytes unless we specificially need
one of them. Iirc the cortex-a8 is the only core were a load to all
lanes is faster than a load to all lanes.


Not that I know of here; I just brought the pattern over from arm, and it 
doesn't cause any slowdown. But I can switch it to ld1 {}[0] since that's 
more readable/understandable, if there's no known gain from it on aarch64.



+ld1r{v1.2s}, [x0], x1
+ld1r{v6.2s}, [x2], x3
+ld1r{v2.2s}, [x0], x1
+ld1r{v7.2s}, [x2], x3
+ld1r{v3.2s}, [x0], x1
+sub 

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Janne Grunau]

On 2016-11-03 23:36:08 +0200, Martin Storsjö wrote:
> On Thu, 3 Nov 2016, Diego Biurrun wrote:
> 
> >On Thu, Nov 03, 2016 at 11:02:17PM +0200, Martin Storsjö wrote:
> >>On Thu, 3 Nov 2016, Diego Biurrun wrote:
> >>>On Thu, Nov 03, 2016 at 09:42:44PM +0100, Janne Grunau wrote:
> On 2016-11-03 20:38:11 +0100, Diego Biurrun wrote:
> > On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
> > > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
> > > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
> > > > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
> > > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
> > > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
> > > > > >>Technically, having a _neon prefix for them is wrong, but 
> > > > > >>anything else
> > > > > >>(omitting these two while hooking up avg32/avg64 separately) is 
> > > > > >>more
> > > > > >>complication - although I'm open for suggestions on how to 
> > > > > >>handle it best.
> > > > > >
> > > > > >Where exactly is the complication? In the way you assign the 
> > > > > >function
> > > > > >pointers in the init file?
> > > > > > > > > Yes, it'd require splitting up those macros a bit;
> either for assigning the
> > > > > same function pointers, but with a different simd instruction set 
> > > > > suffix, or
> > > > > for only assigning the avg function pointer for those sizes.
> > > > > > > Try something like
> > > > > > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
> > > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
> > > > > > > before the assignment macros. You don't have to somehow drop
> some of the
> > > > assignments in the macros then. There's precedent for this in some 
> > > > of the
> > > > x86 init files.
> > > > > That only fixes the function names but not the cpu_flag based
> assignment > > if I understand it correctly. And it is a little bit
> silly since neon is > > not really optional on aarch64. At least in the
> Application profile.
> > > I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64
> > should be assigned to the function pointer unconditionally before
> > checking for neon support.
> 
> unconditionally is not nice since we want to compare them to C in
> checkasm. That's the reason why we have the otherwise pointless
> AV_CPU_FLAG_ARMV8
> >>>
> >>>Unconditional in the aarch64 init function is not unconditional:
> >>>
> >>>libavcodec/foodsp.c:
> >>> if (ARCH_AARCH64)
> >>> init_aarch64(..);
> >>>
> >>>libavcodec/aarch64/foodsp_init.c:
> >>> init_aarch64(..)
> >>> {
> >>> function.pointer = ff_vp9_copy32_aarch64;
> >>>
> >>> if (have_neon())
> >>> something.else = ff_whatever;
> >>>
> >>>Anyway, you get the idea. Quite possibly I'm overlooking something
> >>>and it does not work as I envision...
> >>
> >>Yes, because as Janne said, in that case, you can't via cpuflags choose not
> >>to use this function, and you can't benchmark against the C version in
> >>checkasm, since the C version always gets overridden by this function,
> >>regardless of cpuflags.
> >>
> >>That's why we've introduced the flag AV_CPU_FLAG_ARMV8, and one should wrap
> >>such functions within have_armv8(cpuflags) instead of have_neon(cpuflags).
> >
> >OK, last try then :)
> >
> > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
> >
> > init_aarch64(..)
> > {
> >  if (have_armv8())
> >  function.pointer = ff_vp9_copy32_aarch64;
> >
> >  if (have_neon())
> >  [neon macro trickery
> >  function.pointer = ff_vp9_copy32_neon;
> >   neon macro trickery]
> 
> Sure, something like that would work. Except if we go this way, I wouldn't
> assign it at all within the neon section, since it already is hooked up
> within have_armv8.

No the basic idea was to assign the same functions twice. Once under if 
(have_armv8()) with their real name and once under if (have_neon()) with 
the current macros. The missing _neon functions are provided by '#define 
ff_vp9_copy32_neon ff_vp9_copy32_aarch64'. That's not too messy and the 
functions have the correct debug symbols.

I can live with the current misleading function names but this solution 
is not too messy.

Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Janne Grunau]

On 2016-11-02 14:58:41 +0200, Martin Storsjö wrote:
> ---
>  libavcodec/aarch64/Makefile  |   2 +
>  libavcodec/aarch64/vp9dsp_init_aarch64.c | 139 ++
>  libavcodec/aarch64/vp9mc_neon.S  | 733 
> +++
>  libavcodec/vp9.h |   1 +
>  libavcodec/vp9dsp.c  |   2 +
>  5 files changed, 877 insertions(+)
>  create mode 100644 libavcodec/aarch64/vp9dsp_init_aarch64.c
>  create mode 100644 libavcodec/aarch64/vp9mc_neon.S
> 
> diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
> index 764bedc..6f1227a 100644
> --- a/libavcodec/aarch64/Makefile
> +++ b/libavcodec/aarch64/Makefile
> @@ -17,6 +17,7 @@ OBJS-$(CONFIG_DCA_DECODER)  += 
> aarch64/dcadsp_init.o
>  OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
>  OBJS-$(CONFIG_VC1_DECODER)  += aarch64/vc1dsp_init_aarch64.o
>  OBJS-$(CONFIG_VORBIS_DECODER)   += aarch64/vorbisdsp_init.o
> +OBJS-$(CONFIG_VP9_DECODER)  += aarch64/vp9dsp_init_aarch64.o
>  
>  # ARMv8 optimizations
>  
> @@ -43,3 +44,4 @@ NEON-OBJS-$(CONFIG_MPEGAUDIODSP)+= 
> aarch64/mpegaudiodsp_neon.o
>  NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/dcadsp_neon.o 
>   \
> aarch64/synth_filter_neon.o
>  NEON-OBJS-$(CONFIG_VORBIS_DECODER)  += aarch64/vorbisdsp_neon.o
> +NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9mc_neon.o
> diff --git a/libavcodec/aarch64/vp9dsp_init_aarch64.c 
> b/libavcodec/aarch64/vp9dsp_init_aarch64.c
> new file mode 100644
> index 000..3d414af
> --- /dev/null
> +++ b/libavcodec/aarch64/vp9dsp_init_aarch64.c

> +LOCAL_ALIGNED_16(uint8_t, temp, [((sz < 64 ? 2 * sz : 64) + 8) * sz]);   
>  \

((1 + (sz < 64)) * sz + 8) * sz

nit, looks nicer imo. no need to change it

> diff --git a/libavcodec/aarch64/vp9mc_neon.S 
> b/libavcodec/aarch64/vp9mc_neon.S
> new file mode 100644
> index 000..9ca2a32
> --- /dev/null
> +++ b/libavcodec/aarch64/vp9mc_neon.S
> @@ -0,0 +1,733 @@
> +/*
> + * Copyright (c) 2016 Google Inc.
> + *
> + * This file is part of Libav.
> + *
> + * Libav is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * Libav is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with Libav; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/aarch64/asm.S"
> +
> +const regular_filter, align=4

can't we use the constants from C? the single sign extend will be lost 
in the noise. same applies to the arm version

> +// All public functions in this file have the following signature:
> +// typedef void (*vp9_mc_func)(uint8_t *dst, ptrdiff_t dst_stride,
> +//const uint8_t *ref, ptrdiff_t ref_stride,
> +//int h, int mx, int my);
> +
> +function ff_vp9_copy64_neon, export=1
> +1:
> +ldp x5,  x6,  [x2]
> +stp x5,  x6,  [x0]
> +ldp x5,  x6,  [x2, #16]

use more registers we have enough, probably not noticable

> +stp x5,  x6,  [x0, #16]
> +subsw4,  w4,  #1
> +ldp x5,  x6,  [x2, #32]
> +stp x5,  x6,  [x0, #32]
> +ldp x5,  x6,  [x2, #48]
> +stp x5,  x6,  [x0, #48]
> +add x2,  x2,  x3
> +add x0,  x0,  x1
> +b.ne1b
> +ret
> +endfunc
> +
> +function ff_vp9_avg64_neon, export=1
> +mov x5,  x0
> +1:
> +ld1 {v4.16b,  v5.16b,  v6.16b,  v7.16b},  [x2], x3
> +ld1 {v0.16b,  v1.16b,  v2.16b,  v3.16b},  [x0], x1
> +ld1 {v20.16b, v21.16b, v22.16b, v23.16b}, [x2], x3
> +urhadd  v0.16b,  v0.16b,  v4.16b
> +urhadd  v1.16b,  v1.16b,  v5.16b
> +ld1 {v16.16b, v17.16b, v18.16b, v19.16b}, [x0], x1
> +urhadd  v2.16b,  v2.16b,  v6.16b
> +urhadd  v3.16b,  v3.16b,  v7.16b
> +subsw4,  w4,  #2
> +urhadd  v16.16b, v16.16b, v20.16b
> +urhadd  v17.16b, v17.16b, v21.16b
> +st1 {v0.16b,  v1.16b,  v2.16b,  v3.16b},  [x5], x1
> +urhadd  v18.16b, v18.16b, v22.16b
> +urhadd  v19.16b, v19.16b, v23.16b
> +

Re: [libav-devel] [PATCH] ppc: pixblockdsp: do unaligned block accesses correctly again

[Andreas Cadhalpun]

On 03.11.2016 22:06, Luca Barbato wrote:
> On 03/11/2016 21:35, Andreas Cadhalpun wrote:
>> On 03.11.2016 09:36, Luca Barbato wrote:
>>> The patch makes sense only if line_size is not a multiple of 16 and
>>> normally AVFrames have their linesizes multiple of 32 ...
>>
>> Yes, but this limitation is not documented and the C variant of the
>> function doesn't have it (there's an extra get_pixels_8_c function),
>> so it's a bug in the altivec implementation.
> 
> Not really. A larger number of functions implemented assume a certain
> alignment (currently the 32-alignment is just because we do not have
> larger vectors) and would break quite horribly without it and a fallback
> would be quite slower.

Well, don't use it if you think it's not needed.
I just thought you'd find it useful.

>> I guess the following FFmpeg commit makes a difference for the tests:
>> fb6b6b5 tests/checkasm/pixblockdsp: Test 8 byte aligned positions
>>
>> 6051bb3 libavcodec/dnxhdenc: add edge emulate for dnxhr
>> [...]
>> +uvlinesize = 8;
>> [...]
>> +pdsp->get_pixels(ctx->blocks[2], ptr_u,  uvlinesize);
>>
> 
> The emu edge should have a linesize of 32 and you won't slow down that
> function I guess, I'd appreciate the edge emu code anyway.

Feel free to cherry-pick/improve it.

Best regards,
Andreas

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Martin Storsjö]

On Thu, 3 Nov 2016, Diego Biurrun wrote:


On Thu, Nov 03, 2016 at 11:02:17PM +0200, Martin Storsjö wrote:

On Thu, 3 Nov 2016, Diego Biurrun wrote:
>On Thu, Nov 03, 2016 at 09:42:44PM +0100, Janne Grunau wrote:
>>On 2016-11-03 20:38:11 +0100, Diego Biurrun wrote:
>>> On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
>>> > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
>>> > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
>>> > > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
>>> > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
>>> > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
>>> > > > >>Technically, having a _neon prefix for them is wrong, but anything 
else
>>> > > > >>(omitting these two while hooking up avg32/avg64 separately) is more
>>> > > > >>complication - although I'm open for suggestions on how to handle 
it best.
>>> > > > >
>>> > > > >Where exactly is the complication? In the way you assign the function
>>> > > > >pointers in the init file?
>>> > > > > > > > Yes, it'd require splitting up those macros a bit;
>>either for assigning the
>>> > > > same function pointers, but with a different simd instruction set 
suffix, or
>>> > > > for only assigning the avg function pointer for those sizes.
>>> > > > > > Try something like
>>> > > > > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
>>> > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
>>> > > > > > before the assignment macros. You don't have to somehow drop
>>some of the
>>> > > assignments in the macros then. There's precedent for this in some of 
the
>>> > > x86 init files.
>>> > > > That only fixes the function names but not the cpu_flag based
>>assignment > > if I understand it correctly. And it is a little bit
>>silly since neon is > > not really optional on aarch64. At least in the
>>Application profile.
>>> > I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64
>>> should be assigned to the function pointer unconditionally before
>>> checking for neon support.
>>
>>unconditionally is not nice since we want to compare them to C in
>>checkasm. That's the reason why we have the otherwise pointless
>>AV_CPU_FLAG_ARMV8
>
>Unconditional in the aarch64 init function is not unconditional:
>
>libavcodec/foodsp.c:
> if (ARCH_AARCH64)
> init_aarch64(..);
>
>libavcodec/aarch64/foodsp_init.c:
> init_aarch64(..)
> {
> function.pointer = ff_vp9_copy32_aarch64;
>
> if (have_neon())
> something.else = ff_whatever;
>
>Anyway, you get the idea. Quite possibly I'm overlooking something
>and it does not work as I envision...

Yes, because as Janne said, in that case, you can't via cpuflags choose not
to use this function, and you can't benchmark against the C version in
checkasm, since the C version always gets overridden by this function,
regardless of cpuflags.

That's why we've introduced the flag AV_CPU_FLAG_ARMV8, and one should wrap
such functions within have_armv8(cpuflags) instead of have_neon(cpuflags).


OK, last try then :)

 #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64

 init_aarch64(..)
 {
  if (have_armv8())
  function.pointer = ff_vp9_copy32_aarch64;

  if (have_neon())
  [neon macro trickery
  function.pointer = ff_vp9_copy32_neon;
   neon macro trickery]


Sure, something like that would work. Except if we go this way, I wouldn't 
assign it at all within the neon section, since it already is hooked up 
within have_armv8.


Either of those requires splitting up the macros for setting function 
pointers (since it's not just one pointer but a bunch of them). Not hard 
though, but makes the pretty unwieldy code even more unwieldy.


In any case, yes, it's doable. But I'm waiting for Janne's opinion. :P

// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] avconv_opt: Rework hwaccels array iteration to avoid a warning on empty array

[Luca Barbato]

On 03/11/2016 18:32, Diego Biurrun wrote:
> -for (i = 0; i < FF_ARRAY_ELEMS(hwaccels) - 1; i++) {
> +while (hwaccels[i++].name)

for (i = 0; hwaccels[i].name; i++) {

Is how it is used everywhere else.

Alternatively we can drop `-Wtype-limits` and use the FF_ARRAY_ELEMS()
everywhere.

I prefer having the `for (i = 0; hwaccels[i].name; i++) {` everywhere
for consistency.

lu

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Diego Biurrun]

On Thu, Nov 03, 2016 at 11:02:17PM +0200, Martin Storsjö wrote:
> On Thu, 3 Nov 2016, Diego Biurrun wrote:
> >On Thu, Nov 03, 2016 at 09:42:44PM +0100, Janne Grunau wrote:
> >>On 2016-11-03 20:38:11 +0100, Diego Biurrun wrote:
> >>> On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
> >>> > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
> >>> > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
> >>> > > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
> >>> > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
> >>> > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
> >>> > > > >>Technically, having a _neon prefix for them is wrong, but 
> >>> > > > >>anything else
> >>> > > > >>(omitting these two while hooking up avg32/avg64 separately) is 
> >>> > > > >>more
> >>> > > > >>complication - although I'm open for suggestions on how to handle 
> >>> > > > >>it best.
> >>> > > > >
> >>> > > > >Where exactly is the complication? In the way you assign the 
> >>> > > > >function
> >>> > > > >pointers in the init file?
> >>> > > > > > > > Yes, it'd require splitting up those macros a bit;
> >>either for assigning the
> >>> > > > same function pointers, but with a different simd instruction set 
> >>> > > > suffix, or
> >>> > > > for only assigning the avg function pointer for those sizes.
> >>> > > > > > Try something like
> >>> > > > > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
> >>> > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
> >>> > > > > > before the assignment macros. You don't have to somehow drop
> >>some of the
> >>> > > assignments in the macros then. There's precedent for this in some of 
> >>> > > the
> >>> > > x86 init files.
> >>> > > > That only fixes the function names but not the cpu_flag based
> >>assignment > > if I understand it correctly. And it is a little bit
> >>silly since neon is > > not really optional on aarch64. At least in the
> >>Application profile.
> >>> > I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64
> >>> should be assigned to the function pointer unconditionally before
> >>> checking for neon support.
> >>
> >>unconditionally is not nice since we want to compare them to C in
> >>checkasm. That's the reason why we have the otherwise pointless
> >>AV_CPU_FLAG_ARMV8
> >
> >Unconditional in the aarch64 init function is not unconditional:
> >
> >libavcodec/foodsp.c:
> > if (ARCH_AARCH64)
> > init_aarch64(..);
> >
> >libavcodec/aarch64/foodsp_init.c:
> > init_aarch64(..)
> > {
> > function.pointer = ff_vp9_copy32_aarch64;
> >
> > if (have_neon())
> > something.else = ff_whatever;
> >
> >Anyway, you get the idea. Quite possibly I'm overlooking something
> >and it does not work as I envision...
> 
> Yes, because as Janne said, in that case, you can't via cpuflags choose not
> to use this function, and you can't benchmark against the C version in
> checkasm, since the C version always gets overridden by this function,
> regardless of cpuflags.
> 
> That's why we've introduced the flag AV_CPU_FLAG_ARMV8, and one should wrap
> such functions within have_armv8(cpuflags) instead of have_neon(cpuflags).

OK, last try then :)

  #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64

  init_aarch64(..)
  {
   if (have_armv8())
   function.pointer = ff_vp9_copy32_aarch64;

   if (have_neon())
   [neon macro trickery
   function.pointer = ff_vp9_copy32_neon;
neon macro trickery]

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] ppc: pixblockdsp: do unaligned block accesses correctly again

[Luca Barbato]

On 03/11/2016 21:35, Andreas Cadhalpun wrote:
> On 03.11.2016 09:36, Luca Barbato wrote:
>> On 02/11/2016 21:34, Andreas Cadhalpun wrote:
>>> Tested with qemu on ppc32be and ppc64be.
>>
>> How did you configure it?
> 
> I used qemu-ppc64-static for ppc64be and 
> 'export QEMU_CPU=7400_v2.9; qemu-ppc-static' for ppc32be.
> 
> On 03.11.2016 10:21, Luca Barbato wrote:
>> On 02/11/2016 21:34, Andreas Cadhalpun wrote:
>>
>>> @@ -67,10 +67,10 @@ static void get_pixels_altivec(int16_t *restrict block, 
>>> const uint8_t *pixels,
>>> ptrdiff_t line_size)
>>>  {
>>
>> The patch makes sense only if line_size is not a multiple of 16 and
>> normally AVFrames have their linesizes multiple of 32 ...
> 
> Yes, but this limitation is not documented and the C variant of the
> function doesn't have it (there's an extra get_pixels_8_c function),
> so it's a bug in the altivec implementation.

Not really. A larger number of functions implemented assume a certain
alignment (currently the 32-alignment is just because we do not have
larger vectors) and would break quite horribly without it and a fallback
would be quite slower.

> I guess the following FFmpeg commit makes a difference for the tests:
> fb6b6b5 tests/checkasm/pixblockdsp: Test 8 byte aligned positions
> 
> 6051bb3 libavcodec/dnxhdenc: add edge emulate for dnxhr
> [...]
> +uvlinesize = 8;
> [...]
> +pdsp->get_pixels(ctx->blocks[2], ptr_u,  uvlinesize);
> 

The emu edge should have a linesize of 32 and you won't slow down that
function I guess, I'd appreciate the edge emu code anyway.

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Martin Storsjö]

On Thu, 3 Nov 2016, Diego Biurrun wrote:


On Thu, Nov 03, 2016 at 09:42:44PM +0100, Janne Grunau wrote:

On 2016-11-03 20:38:11 +0100, Diego Biurrun wrote:
> On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
> > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
> > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
> > > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
> > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
> > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
> > > > >>Technically, having a _neon prefix for them is wrong, but anything 
else
> > > > >>(omitting these two while hooking up avg32/avg64 separately) is more
> > > > >>complication - although I'm open for suggestions on how to handle it 
best.
> > > > >
> > > > >Where exactly is the complication? In the way you assign the function
> > > > >pointers in the init file?
> > > > 
> > > > Yes, it'd require splitting up those macros a bit; either for assigning the

> > > > same function pointers, but with a different simd instruction set 
suffix, or
> > > > for only assigning the avg function pointer for those sizes.
> > > 
> > > Try something like
> > > 
> > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64

> > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
> > > 
> > > before the assignment macros. You don't have to somehow drop some of the

> > > assignments in the macros then. There's precedent for this in some of the
> > > x86 init files.
> > 
> > That only fixes the function names but not the cpu_flag based assignment 
> > if I understand it correctly. And it is a little bit silly since neon is 
> > not really optional on aarch64. At least in the Application profile.
> 
> I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64

> should be assigned to the function pointer unconditionally before
> checking for neon support.

unconditionally is not nice since we want to compare them to C in 
checkasm. That's the reason why we have the otherwise pointless 
AV_CPU_FLAG_ARMV8


Unconditional in the aarch64 init function is not unconditional:

libavcodec/foodsp.c:
 if (ARCH_AARCH64)
 init_aarch64(..);

libavcodec/aarch64/foodsp_init.c:
 init_aarch64(..)
 {
 function.pointer = ff_vp9_copy32_aarch64;

 if (have_neon())
 something.else = ff_whatever;

Anyway, you get the idea. Quite possibly I'm overlooking something
and it does not work as I envision...


Yes, because as Janne said, in that case, you can't via cpuflags choose 
not to use this function, and you can't benchmark against the C version in 
checkasm, since the C version always gets overridden by this function, 
regardless of cpuflags.


That's why we've introduced the flag AV_CPU_FLAG_ARMV8, and one should 
wrap such functions within have_armv8(cpuflags) instead of 
have_neon(cpuflags).


// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 2/2] swscale: Add GRAY12

[Luca Barbato]

---
 libswscale/input.c | 2 ++
 libswscale/swscale_internal.h  | 2 ++
 libswscale/swscale_unscaled.c  | 1 +
 libswscale/utils.c | 2 ++
 tests/ref/fate/filter-pixdesc-gray12be | 1 +
 tests/ref/fate/filter-pixdesc-gray12le | 1 +
 tests/ref/fate/filter-pixfmts-copy | 2 ++
 tests/ref/fate/filter-pixfmts-null | 2 ++
 tests/ref/fate/filter-pixfmts-scale| 2 ++
 tests/ref/fate/filter-pixfmts-vflip| 2 ++
 10 files changed, 17 insertions(+)
 create mode 100644 tests/ref/fate/filter-pixdesc-gray12be
 create mode 100644 tests/ref/fate/filter-pixdesc-gray12le

diff --git a/libswscale/input.c b/libswscale/input.c
index 9f2ef72..d8560a1 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1120,6 +1120,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_YUV420P16LE:
 case AV_PIX_FMT_YUV422P16LE:
 case AV_PIX_FMT_YUV444P16LE:
+case AV_PIX_FMT_GRAY12LE:
 case AV_PIX_FMT_GRAY16LE:
 c->lumToYV12 = bswap16Y_c;
 break;
@@ -1148,6 +1149,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 case AV_PIX_FMT_YUV420P16BE:
 case AV_PIX_FMT_YUV422P16BE:
 case AV_PIX_FMT_YUV444P16BE:
+case AV_PIX_FMT_GRAY12BE:
 case AV_PIX_FMT_GRAY16BE:
 c->lumToYV12 = bswap16Y_c;
 break;
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index abcdb9f..e7a6eed 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -603,6 +603,8 @@ static av_always_inline int isRGB(enum AVPixelFormat 
pix_fmt)
 #define isGray(x)  \
 ((x) == AV_PIX_FMT_GRAY8   ||  \
  (x) == AV_PIX_FMT_YA8 ||  \
+ (x) == AV_PIX_FMT_GRAY12BE||  \
+ (x) == AV_PIX_FMT_GRAY12LE||  \
  (x) == AV_PIX_FMT_GRAY16BE||  \
  (x) == AV_PIX_FMT_GRAY16LE||  \
  (x) == AV_PIX_FMT_YA16BE  ||  \
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 24c65cc..d3863bb 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1097,6 +1097,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_BGR555) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_BGR565) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_BGRA64) ||
+IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GRAY12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GRAY16) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YA16)   ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12)||
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 1c3bbb3..6034b70 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -107,6 +107,8 @@ static const FormatEntry format_entries[AV_PIX_FMT_NB] = {
 [AV_PIX_FMT_RGBA]= { 1, 1 },
 [AV_PIX_FMT_ABGR]= { 1, 1 },
 [AV_PIX_FMT_BGRA]= { 1, 1 },
+[AV_PIX_FMT_GRAY12BE]= { 1, 1 },
+[AV_PIX_FMT_GRAY12LE]= { 1, 1 },
 [AV_PIX_FMT_GRAY16BE]= { 1, 1 },
 [AV_PIX_FMT_GRAY16LE]= { 1, 1 },
 [AV_PIX_FMT_YUV440P] = { 1, 1 },
diff --git a/tests/ref/fate/filter-pixdesc-gray12be 
b/tests/ref/fate/filter-pixdesc-gray12be
new file mode 100644
index 000..de99734
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-gray12be
@@ -0,0 +1 @@
+pixdesc-gray12bebff4fa5910e99725b275fb70270b0cf9
diff --git a/tests/ref/fate/filter-pixdesc-gray12le 
b/tests/ref/fate/filter-pixdesc-gray12le
new file mode 100644
index 000..c2c5f68
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-gray12le
@@ -0,0 +1 @@
+pixdesc-gray12led0900fab4e757ef17fff8c1ffd0b3816
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index d9a5166..bd16f11 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -23,6 +23,8 @@ gbrp12le654861b1837d312569395f598da1a2a1
 gbrp9be cbe1bf8ead497a92362a749bd4b0a57e
 gbrp9le f88c68df5d699a4a7f1b0152df9f25fe
 gray8c941e9bbf6da5336384c57f15a4a454
+gray12beaecffce8ea67ab93527dc74c1a523454
+gray12leeac4b15c8686f04ea73751294f40b8e0
 gray16be43bda75c197b0d59a9b87ee941553644
 gray16lea4ea1369ef1efff0e1341a1dc42dbfdf
 monob   e13b2cbfb93d3ed6fdc1f256662ea959
diff --git a/tests/ref/fate/filter-pixfmts-null 
b/tests/ref/fate/filter-pixfmts-null
index d9a5166..bd16f11 100644
--- a/tests/ref/fate/filter-pixfmts-null
+++ b/tests/ref/fate/filter-pixfmts-null
@@ -23,6 +23,8 @@ gbrp12le654861b1837d312569395f598da1a2a1
 gbrp9be cbe1bf8ead497a92362a749bd4b0a57e
 gbrp9le f88c68df5d699a4a7f1b0152df9f25fe
 gray8c941e9bbf6da5336384c57f15a4a454
+gray12beaecffce8ea67ab93527dc74c1a523454
+gray12le

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Diego Biurrun]

On Thu, Nov 03, 2016 at 09:42:44PM +0100, Janne Grunau wrote:
> On 2016-11-03 20:38:11 +0100, Diego Biurrun wrote:
> > On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
> > > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
> > > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
> > > > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
> > > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
> > > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
> > > > > >>Technically, having a _neon prefix for them is wrong, but anything 
> > > > > >>else
> > > > > >>(omitting these two while hooking up avg32/avg64 separately) is more
> > > > > >>complication - although I'm open for suggestions on how to handle 
> > > > > >>it best.
> > > > > >
> > > > > >Where exactly is the complication? In the way you assign the function
> > > > > >pointers in the init file?
> > > > > 
> > > > > Yes, it'd require splitting up those macros a bit; either for 
> > > > > assigning the
> > > > > same function pointers, but with a different simd instruction set 
> > > > > suffix, or
> > > > > for only assigning the avg function pointer for those sizes.
> > > > 
> > > > Try something like
> > > > 
> > > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
> > > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
> > > > 
> > > > before the assignment macros. You don't have to somehow drop some of the
> > > > assignments in the macros then. There's precedent for this in some of 
> > > > the
> > > > x86 init files.
> > > 
> > > That only fixes the function names but not the cpu_flag based assignment 
> > > if I understand it correctly. And it is a little bit silly since neon is 
> > > not really optional on aarch64. At least in the Application profile.
> > 
> > I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64
> > should be assigned to the function pointer unconditionally before
> > checking for neon support.
> 
> unconditionally is not nice since we want to compare them to C in 
> checkasm. That's the reason why we have the otherwise pointless 
> AV_CPU_FLAG_ARMV8

Unconditional in the aarch64 init function is not unconditional:

libavcodec/foodsp.c:
  if (ARCH_AARCH64)
  init_aarch64(..);

libavcodec/aarch64/foodsp_init.c:
  init_aarch64(..)
  {
  function.pointer = ff_vp9_copy32_aarch64;

  if (have_neon())
  something.else = ff_whatever;

Anyway, you get the idea. Quite possibly I'm overlooking something
and it does not work as I envision...

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 1/2] pixfmt: Add GRAY12

[Luca Barbato]

---
 libavutil/pixdesc.c | 22 ++
 libavutil/pixfmt.h  |  4 
 2 files changed, 26 insertions(+)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 7987f29..db90229 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -493,6 +493,27 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 },
 .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_ALPHA,
 },
+[AV_PIX_FMT_GRAY12BE] = {
+.name = "gray12be",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 0, 12, 1, 11, 1 },   /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_BE,
+.alias = "y12be",
+},
+[AV_PIX_FMT_GRAY12LE] = {
+.name = "gray12le",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 2, 0, 0, 12, 1, 11, 1 },   /* Y */
+},
+.alias = "y12le",
+},
 [AV_PIX_FMT_GRAY16BE] = {
 .name = "gray16be",
 .nb_components = 1,
@@ -1950,6 +1971,7 @@ enum AVPixelFormat av_pix_fmt_swap_endianness(enum 
AVPixelFormat pix_fmt)
 case AV_PIX_FMT_ ## fmt ## LE: return AV_PIX_FMT_ ## fmt ## BE
 
 switch (pix_fmt) {
+PIX_FMT_SWAP_ENDIANNESS(GRAY12);
 PIX_FMT_SWAP_ENDIANNESS(GRAY16);
 PIX_FMT_SWAP_ENDIANNESS(YA16);
 PIX_FMT_SWAP_ENDIANNESS(RGB48);
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 0bee724..5a7b78a 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -245,6 +245,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_GBRAP12BE,  ///< planar GBR 4:4:4:4 48bpp, big-endian
 AV_PIX_FMT_GBRAP12LE,  ///< planar GBR 4:4:4:4 48bpp, little-endian
 
+AV_PIX_FMT_GRAY12BE,  ///

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Janne Grunau]

On 2016-11-03 20:38:11 +0100, Diego Biurrun wrote:
> On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
> > On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
> > > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
> > > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
> > > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
> > > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
> > > > >>Technically, having a _neon prefix for them is wrong, but anything 
> > > > >>else
> > > > >>(omitting these two while hooking up avg32/avg64 separately) is more
> > > > >>complication - although I'm open for suggestions on how to handle it 
> > > > >>best.
> > > > >
> > > > >Where exactly is the complication? In the way you assign the function
> > > > >pointers in the init file?
> > > > 
> > > > Yes, it'd require splitting up those macros a bit; either for assigning 
> > > > the
> > > > same function pointers, but with a different simd instruction set 
> > > > suffix, or
> > > > for only assigning the avg function pointer for those sizes.
> > > 
> > > Try something like
> > > 
> > > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
> > > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
> > > 
> > > before the assignment macros. You don't have to somehow drop some of the
> > > assignments in the macros then. There's precedent for this in some of the
> > > x86 init files.
> > 
> > That only fixes the function names but not the cpu_flag based assignment 
> > if I understand it correctly. And it is a little bit silly since neon is 
> > not really optional on aarch64. At least in the Application profile.
> 
> I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64
> should be assigned to the function pointer unconditionally before
> checking for neon support.

unconditionally is not nice since we want to compare them to C in 
checkasm. That's the reason why we have the otherwise pointless 
AV_CPU_FLAG_ARMV8

Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] ppc: pixblockdsp: do unaligned block accesses correctly again

[Andreas Cadhalpun]

On 03.11.2016 09:36, Luca Barbato wrote:
> On 02/11/2016 21:34, Andreas Cadhalpun wrote:
>> Tested with qemu on ppc32be and ppc64be.
> 
> How did you configure it?

I used qemu-ppc64-static for ppc64be and 
'export QEMU_CPU=7400_v2.9; qemu-ppc-static' for ppc32be.

On 03.11.2016 10:21, Luca Barbato wrote:
> On 02/11/2016 21:34, Andreas Cadhalpun wrote:
> 
>> @@ -67,10 +67,10 @@ static void get_pixels_altivec(int16_t *restrict block, 
>> const uint8_t *pixels,
>> ptrdiff_t line_size)
>>  {
> 
> The patch makes sense only if line_size is not a multiple of 16 and
> normally AVFrames have their linesizes multiple of 32 ...

Yes, but this limitation is not documented and the C variant of the
function doesn't have it (there's an extra get_pixels_8_c function),
so it's a bug in the altivec implementation.

> The fate tests in Libav pass w/out the patch on real hardware and qemu,
> could you please tell me how do you get a line_size that is not multiple
> of 16 ?

I guess the following FFmpeg commit makes a difference for the tests:
fb6b6b5 tests/checkasm/pixblockdsp: Test 8 byte aligned positions

6051bb3 libavcodec/dnxhdenc: add edge emulate for dnxhr
[...]
+uvlinesize = 8;
[...]
+pdsp->get_pixels(ctx->blocks[2], ptr_u,  uvlinesize);

Best regards,
Andreas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC] [PATCH] configure: Make sure config.h isn't accidentally included in builds for the host

[Martin Storsjö]

On Thu, 3 Nov 2016, Diego Biurrun wrote:


On Thu, Nov 03, 2016 at 02:32:10PM +0200, Martin Storsjö wrote:

In aacps_tablegen.h, only include libm.h if building for the target.

If actual fallbacks are needed here (in practice, sinf and cosf,
which are missing on Plan 9 - they are present even on MSVC), we need
to include libm.h, but this relies on configure test results for the
target. These test results can't be used for the host (e.g. when this
header is used when building with --enable-hardcoded-tables).

This clearly breaks builds with hardcoded tables on Plan 9 (not
cross builds from another host to Plan 9 though), instead of relying on
coincidences that config.h for the target might match the host build
config as well.


So, speaking of Plan 9, IMO we should discuss if keeping support for it
is worth the trouble. It was a nice joke and pun with the 9 release, but
that has run its course.


Well, keeping it in itself isn't too much trouble, except we have no idea 
if it still works, and for things like this particular include of libm.h, 
I can't test. That said, I'm not opposed to removing it either, bringing 
the set of things back to things we test regularly.



--- a/configure
+++ b/configure
@@ -3719,6 +3719,7 @@ check_cc -D_LARGEFILE_SOURCE <

You can merge these two lines.


Ah, yes

// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Drop unreachable break and return statements

[Vittorio Giovara]

On Thu, Nov 3, 2016 at 4:12 PM, Diego Biurrun  wrote:
> On Thu, Nov 03, 2016 at 04:04:54PM -0400, Vittorio Giovara wrote:
>> On Thu, Nov 3, 2016 at 1:25 PM, Diego Biurrun  wrote:
>> > ---
>> >
>> > Dropped the cmdutils.c part, which is a tad more complicated, as noticed 
>> > by Luca.
>> >
>> >  libavcodec/bmvvideo.c  | 1 -
>> >  libavcodec/hevc_sei.c  | 1 -
>> >  libavcodec/indeo3.c| 2 --
>> >  libavcodec/sanm.c  | 3 ---
>> >  libavformat/rtpproto.c | 1 -
>> >  libavformat/rtspdec.c  | 1 -
>> >  libavformat/smush.c| 1 -
>> >  libavutil/opt.c| 2 --
>> >  8 files changed, 12 deletions(-)
>>
>> I must say I'm not totally fond of the idea.
>
> sentence I parse cannot this.

I hate this patch
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Drop unreachable break and return statements

[Diego Biurrun]

On Thu, Nov 03, 2016 at 04:04:54PM -0400, Vittorio Giovara wrote:
> On Thu, Nov 3, 2016 at 1:25 PM, Diego Biurrun  wrote:
> > ---
> >
> > Dropped the cmdutils.c part, which is a tad more complicated, as noticed by 
> > Luca.
> >
> >  libavcodec/bmvvideo.c  | 1 -
> >  libavcodec/hevc_sei.c  | 1 -
> >  libavcodec/indeo3.c| 2 --
> >  libavcodec/sanm.c  | 3 ---
> >  libavformat/rtpproto.c | 1 -
> >  libavformat/rtspdec.c  | 1 -
> >  libavformat/smush.c| 1 -
> >  libavutil/opt.c| 2 --
> >  8 files changed, 12 deletions(-)
> 
> I must say I'm not totally fond of the idea.

sentence I parse cannot this.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] avconv_opt: Rework hwaccels array iteration to avoid a warning on empty array

[Vittorio Giovara]

On Thu, Nov 3, 2016 at 3:42 PM, Anton Khirnov  wrote:
> Quoting Diego Biurrun (2016-11-03 18:32:35)
>> avconv_opt.c:188:19: warning: comparison of unsigned expression < 0 is 
>> always false [-Wtype-limits]
>> ---
>>  avconv_opt.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/avconv_opt.c b/avconv_opt.c
>> index 1064cf4..a3fd3dd 100644
>> --- a/avconv_opt.c
>> +++ b/avconv_opt.c
>> @@ -187,12 +187,11 @@ static double parse_frame_aspect_ratio(const char *arg)
>>
>>  static int show_hwaccels(void *optctx, const char *opt, const char *arg)
>>  {
>> -int i;
>> +int i = 0;
>>
>>  printf("Supported hardware acceleration:\n");
>> -for (i = 0; i < FF_ARRAY_ELEMS(hwaccels) - 1; i++) {
>> +while (hwaccels[i++].name)
>>  printf("%s\n", hwaccels[i].name);
>> -}
>>  printf("\n");
>>  return 0;
>>  }
>> --
>> 2.1.4
>
> I am against uglifying perfectly valid code just to please some
> compilers.

+1, also the new codec is IMO harder to read

-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Drop unreachable break and return statements

[Vittorio Giovara]

On Thu, Nov 3, 2016 at 1:25 PM, Diego Biurrun  wrote:
> ---
>
> Dropped the cmdutils.c part, which is a tad more complicated, as noticed by 
> Luca.
>
>  libavcodec/bmvvideo.c  | 1 -
>  libavcodec/hevc_sei.c  | 1 -
>  libavcodec/indeo3.c| 2 --
>  libavcodec/sanm.c  | 3 ---
>  libavformat/rtpproto.c | 1 -
>  libavformat/rtspdec.c  | 1 -
>  libavformat/smush.c| 1 -
>  libavutil/opt.c| 2 --
>  8 files changed, 12 deletions(-)

I must say I'm not totally fond of the idea.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/3] mov: Change MOVTrack.entry to unsigned

[Diego Biurrun]

On Thu, Nov 03, 2016 at 08:41:10PM +0100, Anton Khirnov wrote:
> Quoting Diego Biurrun (2016-11-03 18:32:34)
> > libavformat/movenc.c:3170:12: warning: assuming signed overflow does not 
> > occur when assuming that (X - c) > X is always false [-Wstrict-overflow]
> 
> This is not sufficient explanation for the commit.
> 
> Just the fact that some compiler warns about some piece of code does not
> necessarily mean that anything is wrong. And just the fact that the
> patch makes the warning go away does not mean it is the right thing to
> do.

Certainly. I forgot to add the [RFC] marker to this one as I originally
intended to.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/3] avconv_opt: Rework hwaccels array iteration to avoid a warning on empty array

[Anton Khirnov]

Quoting Diego Biurrun (2016-11-03 18:32:35)
> avconv_opt.c:188:19: warning: comparison of unsigned expression < 0 is always 
> false [-Wtype-limits]
> ---
>  avconv_opt.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/avconv_opt.c b/avconv_opt.c
> index 1064cf4..a3fd3dd 100644
> --- a/avconv_opt.c
> +++ b/avconv_opt.c
> @@ -187,12 +187,11 @@ static double parse_frame_aspect_ratio(const char *arg)
>  
>  static int show_hwaccels(void *optctx, const char *opt, const char *arg)
>  {
> -int i;
> +int i = 0;
>  
>  printf("Supported hardware acceleration:\n");
> -for (i = 0; i < FF_ARRAY_ELEMS(hwaccels) - 1; i++) {
> +while (hwaccels[i++].name)
>  printf("%s\n", hwaccels[i].name);
> -}
>  printf("\n");
>  return 0;
>  }
> -- 
> 2.1.4

I am against uglifying perfectly valid code just to please some
compilers.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/3] mov: Change MOVTrack.entry to unsigned

[Anton Khirnov]

Quoting Diego Biurrun (2016-11-03 18:32:34)
> libavformat/movenc.c:3170:12: warning: assuming signed overflow does not 
> occur when assuming that (X - c) > X is always false [-Wstrict-overflow]

This is not sufficient explanation for the commit.

Just the fact that some compiler warns about some piece of code does not
necessarily mean that anything is wrong. And just the fact that the
patch makes the warning go away does not mean it is the right thing to
do.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCHv2] aarch64: vp9: Add NEON optimizations of VP9 MC functions

[Diego Biurrun]

On Wed, Nov 02, 2016 at 07:24:03PM +0100, Janne Grunau wrote:
> On 2016-11-02 15:29:34 +0100, Diego Biurrun wrote:
> > On Wed, Nov 02, 2016 at 04:00:38PM +0200, Martin Storsjö wrote:
> > > On Wed, 2 Nov 2016, Diego Biurrun wrote:
> > > >On Wed, Nov 02, 2016 at 03:23:14PM +0200, Martin Storsjö wrote:
> > > >>On Wed, 2 Nov 2016, Martin Storsjö wrote:
> > > >>Technically, having a _neon prefix for them is wrong, but anything else
> > > >>(omitting these two while hooking up avg32/avg64 separately) is more
> > > >>complication - although I'm open for suggestions on how to handle it 
> > > >>best.
> > > >
> > > >Where exactly is the complication? In the way you assign the function
> > > >pointers in the init file?
> > > 
> > > Yes, it'd require splitting up those macros a bit; either for assigning 
> > > the
> > > same function pointers, but with a different simd instruction set suffix, 
> > > or
> > > for only assigning the avg function pointer for those sizes.
> > 
> > Try something like
> > 
> > #define ff_vp9_copy32_neon ff_vp9_copy32_aarch64
> > #define ff_vp9_copy64_neon ff_vp9_copy64_aarch64
> > 
> > before the assignment macros. You don't have to somehow drop some of the
> > assignments in the macros then. There's precedent for this in some of the
> > x86 init files.
> 
> That only fixes the function names but not the cpu_flag based assignment 
> if I understand it correctly. And it is a little bit silly since neon is 
> not really optional on aarch64. At least in the Application profile.

I forgot to say that ff_vp9_copy32_aarch64 and ff_vp9_copy64_aarch64
should be assigned to the function pointer unconditionally before
checking for neon support.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [RFC] [PATCH] configure: Make sure config.h isn't accidentally included in builds for the host

[Diego Biurrun]

On Thu, Nov 03, 2016 at 02:32:10PM +0200, Martin Storsjö wrote:
> In aacps_tablegen.h, only include libm.h if building for the target.
> 
> If actual fallbacks are needed here (in practice, sinf and cosf,
> which are missing on Plan 9 - they are present even on MSVC), we need
> to include libm.h, but this relies on configure test results for the
> target. These test results can't be used for the host (e.g. when this
> header is used when building with --enable-hardcoded-tables).
> 
> This clearly breaks builds with hardcoded tables on Plan 9 (not
> cross builds from another host to Plan 9 though), instead of relying on
> coincidences that config.h for the target might match the host build
> config as well.

So, speaking of Plan 9, IMO we should discuss if keeping support for it
is worth the trouble. It was a nice joke and pun with the 9 release, but
that has run its course.

> --- a/configure
> +++ b/configure
> @@ -3719,6 +3719,7 @@ check_cc -D_LARGEFILE_SOURCE < -D_LARGEFILE_SOURCE
>  EOF
>  
>  add_host_cppflags -D_ISOC99_SOURCE
> +add_host_cppflags -DHOST_BUILD

You can merge these two lines.

>  check_host_cflags -std=c99
>  check_host_cflags -Wall
>  check_host_cflags -O3
> @@ -5356,6 +5357,9 @@ cat > $TMPH <  #define EXTERN_PREFIX "${extern_prefix}"
>  #define EXTERN_ASM ${extern_prefix}
>  #define SLIBSUF "$SLIBSUF"
> +#ifdef HOST_BUILD
> +#error config.h must not be included in host builds
> +#endif
>  EOF

Go figure, I had practically the same idea some time ago ..

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Drop unreachable break and return statements

[Luca Barbato]

On 03/11/2016 18:25, Diego Biurrun wrote:
> ---
> 
> Dropped the cmdutils.c part, which is a tad more complicated, as noticed by 
> Luca.
> 

This subset looks safe.

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/3] x86: Drop stray semicolons after function definitions

[Luca Barbato]

On 03/11/2016 18:32, Diego Biurrun wrote:
> libavcodec/x86/rv40dsp_init.c:97:2: warning: ISO C does not allow extra ‘;’ 
> outside of a function [-Wpedantic]
> libavcodec/x86/vp9dsp_init.c:94:40: warning: ISO C does not allow extra ‘;’ 
> outside of a function [-Wpedantic]
> ---
>  libavcodec/x86/rv40dsp_init.c |  2 +-
>  libavcodec/x86/vp9dsp_init.c  | 20 ++--
>  2 files changed, 11 insertions(+), 11 deletions(-)
> 

Seems fine.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 3/3] x86: Drop stray semicolons after function definitions

[Diego Biurrun]

libavcodec/x86/rv40dsp_init.c:97:2: warning: ISO C does not allow extra ‘;’ 
outside of a function [-Wpedantic]
libavcodec/x86/vp9dsp_init.c:94:40: warning: ISO C does not allow extra ‘;’ 
outside of a function [-Wpedantic]
---
 libavcodec/x86/rv40dsp_init.c |  2 +-
 libavcodec/x86/vp9dsp_init.c  | 20 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavcodec/x86/rv40dsp_init.c b/libavcodec/x86/rv40dsp_init.c
index 7bf3ecd..f6d4165 100644
--- a/libavcodec/x86/rv40dsp_init.c
+++ b/libavcodec/x86/rv40dsp_init.c
@@ -94,7 +94,7 @@ static void OP ## rv40_qpel ##SIZE ##_mc ##PH ##PV 
##OPT(uint8_t *dst,  \
 ff_ ##OP ##rv40_qpel_h ## OPT(dst + i, stride, src + i, \
   stride, SIZE, HCOFF(PH)); \
 }   \
-};
+}
 
 /** Declare functions for sizes 8 and 16 and given operations
  *  and qpel position. */
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index 58aedcb..59cde79 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -100,21 +100,21 @@ ff_vp9_ ## avg ## _8tap_1d_ ## dir ## _ ## sz ## _ ## 
opt(uint8_t *dst, \
 }
 
 #define mc_rep_funcs(sz, hsz, opt, type, f_sz) \
-mc_rep_func(put, sz, hsz, h, opt, type, f_sz); \
-mc_rep_func(avg, sz, hsz, h, opt, type, f_sz); \
-mc_rep_func(put, sz, hsz, v, opt, type, f_sz); \
+mc_rep_func(put, sz, hsz, h, opt, type, f_sz)  \
+mc_rep_func(avg, sz, hsz, h, opt, type, f_sz)  \
+mc_rep_func(put, sz, hsz, v, opt, type, f_sz)  \
 mc_rep_func(avg, sz, hsz, v, opt, type, f_sz)
 
-mc_rep_funcs(16, 8,  sse2,  int16_t,  8);
+mc_rep_funcs(16, 8,  sse2,  int16_t,  8)
 #if ARCH_X86_32
-mc_rep_funcs(16, 8,  ssse3, int8_t,  32);
+mc_rep_funcs(16, 8,  ssse3, int8_t,  32)
 #endif
-mc_rep_funcs(32, 16, sse2,  int16_t,  8);
-mc_rep_funcs(32, 16, ssse3, int8_t,  32);
-mc_rep_funcs(64, 32, sse2,  int16_t,  8);
-mc_rep_funcs(64, 32, ssse3, int8_t,  32);
+mc_rep_funcs(32, 16, sse2,  int16_t,  8)
+mc_rep_funcs(32, 16, ssse3, int8_t,  32)
+mc_rep_funcs(64, 32, sse2,  int16_t,  8)
+mc_rep_funcs(64, 32, ssse3, int8_t,  32)
 #if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
-mc_rep_funcs(64, 32, avx2,  int8_t,  32);
+mc_rep_funcs(64, 32, avx2,  int8_t,  32)
 #endif
 
 #undef mc_rep_funcs
-- 
2.1.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 1/3] mov: Change MOVTrack.entry to unsigned

[Diego Biurrun]

libavformat/movenc.c:3170:12: warning: assuming signed overflow does not occur 
when assuming that (X - c) > X is always false [-Wstrict-overflow]
---
 libavformat/movenc.c | 2 +-
 libavformat/movenc.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index f99617a..bcd405f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -573,7 +573,7 @@ static int mov_get_lpcm_flags(enum AVCodecID codec_id)
 }
 }
 
-static int get_cluster_duration(MOVTrack *track, int cluster_idx)
+static int get_cluster_duration(MOVTrack *track, unsigned cluster_idx)
 {
 int64_t next_dts;
 
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index f4ed188..93350a8 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -78,7 +78,7 @@ typedef struct MOVFragmentInfo {
 
 typedef struct MOVTrack {
 int mode;
-int entry;
+unsignedentry;
 unsignedtimescale;
 uint64_ttime;
 int64_t track_duration;
-- 
2.1.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 2/3] avconv_opt: Rework hwaccels array iteration to avoid a warning on empty array

[Diego Biurrun]

avconv_opt.c:188:19: warning: comparison of unsigned expression < 0 is always 
false [-Wtype-limits]
---
 avconv_opt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/avconv_opt.c b/avconv_opt.c
index 1064cf4..a3fd3dd 100644
--- a/avconv_opt.c
+++ b/avconv_opt.c
@@ -187,12 +187,11 @@ static double parse_frame_aspect_ratio(const char *arg)
 
 static int show_hwaccels(void *optctx, const char *opt, const char *arg)
 {
-int i;
+int i = 0;
 
 printf("Supported hardware acceleration:\n");
-for (i = 0; i < FF_ARRAY_ELEMS(hwaccels) - 1; i++) {
+while (hwaccels[i++].name)
 printf("%s\n", hwaccels[i].name);
-}
 printf("\n");
 return 0;
 }
-- 
2.1.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] Drop unreachable break and return statements

[Diego Biurrun]

---

Dropped the cmdutils.c part, which is a tad more complicated, as noticed by 
Luca.

 libavcodec/bmvvideo.c  | 1 -
 libavcodec/hevc_sei.c  | 1 -
 libavcodec/indeo3.c| 2 --
 libavcodec/sanm.c  | 3 ---
 libavformat/rtpproto.c | 1 -
 libavformat/rtspdec.c  | 1 -
 libavformat/smush.c| 1 -
 libavutil/opt.c| 2 --
 8 files changed, 12 deletions(-)

diff --git a/libavcodec/bmvvideo.c b/libavcodec/bmvvideo.c
index f4b8f29..4fb42f0 100644
--- a/libavcodec/bmvvideo.c
+++ b/libavcodec/bmvvideo.c
@@ -191,7 +191,6 @@ static int decode_bmv_frame(const uint8_t *source, int 
src_len, uint8_t *frame,
 if (dst == dst_end)
 return 0;
 }
-return 0;
 }
 
 static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 8865cec..8c913f9 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -173,7 +173,6 @@ static int decode_nal_sei_message(HEVCContext *s)
 } else { /* nal_unit_type == NAL_SEI_SUFFIX */
 return decode_nal_sei_suffix(s, payload_type, payload_size);
 }
-return 0;
 }
 
 static int more_rbsp_data(GetBitContext *gb)
diff --git a/libavcodec/indeo3.c b/libavcodec/indeo3.c
index 89c11e6..314548f 100644
--- a/libavcodec/indeo3.c
+++ b/libavcodec/indeo3.c
@@ -831,8 +831,6 @@ static int parse_bintree(Indeo3DecodeContext *ctx, 
AVCodecContext *avctx,
 break;
 }
 }//while
-
-return 0;
 }
 
 
diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
index 3d23195..7b00049 100644
--- a/libavcodec/sanm.c
+++ b/libavcodec/sanm.c
@@ -926,13 +926,10 @@ static int process_frame_obj(SANMVideoContext *ctx)
 case 1:
 case 3:
 return old_codec1(ctx, top, left, w, h);
-break;
 case 37:
 return old_codec37(ctx, top, left, w, h);
-break;
 case 47:
 return old_codec47(ctx, top, left, w, h);
-break;
 default:
 avpriv_request_sample(ctx->avctx, "Subcodec %d", codec);
 return AVERROR_PATCHWELCOME;
diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
index 6582e4a..21a96d2 100644
--- a/libavformat/rtpproto.c
+++ b/libavformat/rtpproto.c
@@ -436,7 +436,6 @@ static int rtp_read(URLContext *h, uint8_t *buf, int size)
 if (h->flags & AVIO_FLAG_NONBLOCK)
 return AVERROR(EAGAIN);
 }
-return len;
 }
 
 static int rtp_write(URLContext *h, const uint8_t *buf, int size)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 03374dc..8e8b340 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -700,7 +700,6 @@ static int rtsp_listen(AVFormatContext *s)
 return AVERROR_INVALIDDATA;
 }
 }
-return 0;
 }
 
 static int rtsp_probe(AVProbeData *p)
diff --git a/libavformat/smush.c b/libavformat/smush.c
index 262b941..817e736 100644
--- a/libavformat/smush.c
+++ b/libavformat/smush.c
@@ -129,7 +129,6 @@ static int smush_read_header(AVFormatContext *ctx)
 break;
 default:
 return AVERROR_INVALIDDATA;
-break;
 }
 }
 
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 7cb3d66..44d6299 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -240,8 +240,6 @@ static int set_string_number(void *obj, void *target_obj, 
const AVOption *o, con
 return 0;
 notfirst = 1;
 }
-
-return 0;
 }
 
 int av_opt_set(void *obj, const char *name, const char *val, int search_flags)
-- 
2.1.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 8/9] Use avpriv_report_missing_feature() where appropriate

[Diego Biurrun]

On Mon, Oct 31, 2016 at 07:36:14PM +0100, Diego Biurrun wrote:
> On Thu, Oct 27, 2016 at 08:54:59PM +0200, Diego Biurrun wrote:
> > ---
> >  libavcodec/aacdec.c |  3 +--
> >  libavcodec/alac.c   |  8 
> >  libavcodec/bmp.c|  3 ++-
> >  libavcodec/fraps.c  |  4 +---
> >  libavcodec/g2meet.c | 11 +--
> >  libavcodec/g723_1enc.c  |  3 ++-
> >  libavcodec/h264_ps.c|  5 ++---
> >  libavcodec/hevc_ps.c|  7 +++
> >  libavcodec/hevc_ps_enc.c| 10 ++
> >  libavcodec/libopenjpegdec.c |  2 +-
> >  libavcodec/libopusenc.c |  5 +++--
> >  libavcodec/mjpegdec.c   |  7 ---
> >  libavcodec/opus_silk.c  |  2 +-
> >  libavcodec/shorten.c|  4 ++--
> >  libavcodec/takdec.c |  2 +-
> >  libavcodec/txd.c|  7 +++
> >  libavcodec/vp5.c|  2 +-
> >  libavcodec/xwddec.c |  2 +-
> >  libavdevice/vfwcap.c|  3 +--
> >  libavdevice/xcbgrab.c   |  2 +-
> >  libavformat/avienc.c|  3 +--
> >  libavformat/lxfdec.c|  5 ++---
> >  libavformat/matroskadec.c   |  7 +++
> >  libavformat/mpc8.c  |  2 +-
> >  libavformat/oggparseopus.c  |  6 +++---
> >  libavformat/qcp.c   |  4 ++--
> >  libavformat/rsoenc.c|  2 +-
> >  libavformat/rtpdec_jpeg.c   |  2 +-
> >  libavformat/rtpdec_latm.c   |  6 +++---
> >  libavformat/rtpdec_xiph.c   | 14 ++
> >  libavformat/rtsp.c  |  3 +--
> >  libavformat/spdifenc.c  |  3 ++-
> >  libavformat/wvdec.c |  3 ++-
> >  33 files changed, 73 insertions(+), 79 deletions(-)
> 
> ping

pong

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] Add support for CUVID decode

[Diego Biurrun]

On Wed, Nov 02, 2016 at 08:15:01AM +, Ruta Gadkari wrote:
> >> --- a/libavcodec/Makefile
> >> +++ b/libavcodec/Makefile
> 
> >As I said before, you do not add all the necessary entries.
> 
> >See also 
> >https://www.libav.org/documentation/developer.html#New-codecs-or-formats-checklist
> 
> I have tried compiling all the new codecs as in the link, compilation is 
> successful but need to enable cuvid and cuda as well.
>./configure --disable-everything --enable-nonfree --enable-cuvid 
> --enable-cuda --enable-decoder=h264_cuvid
> 
> I have added entries in Makefile for all codecs added under cuvid. Is 
> anything else required that I am missing?

What about the hwaccels? You need to hook up those as well (and test
their standalone compilation).

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] vf_hwupload_cuda: Fix build error

[Diego Biurrun]

On Thu, Nov 03, 2016 at 04:33:25PM +, Mark Thompson wrote:
> Broken by e3fb74f7f9a8f1895381355f40c92cac3c1023d9.
> ---
>  libavfilter/vf_hwupload_cuda.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] mov: Export spherical information

[Diego Biurrun]

On Wed, Nov 02, 2016 at 02:15:07PM -0400, Vittorio Giovara wrote:
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3154,6 +3155,242 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  
> +static int mov_read_st3d(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +mode = avio_r8(pb);
> +switch(mode) {

switch (

> +static int mov_read_sv3d(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +switch(tag) {
> +case MKTAG('c','b','m','p'):

same

> +if (sc->spherical) {
> +AVPacketSideData *sd, *tmp;
> +
> +tmp = av_realloc_array(st->side_data,
> +   st->nb_side_data + 1, sizeof(*tmp));
> +if (!tmp)
> +return AVERROR(ENOMEM);
> +
> +st->side_data = tmp;
> +st->nb_side_data++;
> +
> +sd = >side_data[st->nb_side_data - 1];
> +sd->type = AV_PKT_DATA_SPHERICAL;
> +sd->size = sizeof(*sc->spherical);
> +sd->data = (uint8_t *)sc->spherical;
> +sc->spherical = NULL;
> +}
> +if (sc->stereo3d) {
> +AVPacketSideData *sd, *tmp;
> +
> +tmp = av_realloc_array(st->side_data,
> +   st->nb_side_data + 1, sizeof(*tmp));
> +if (!tmp)
> +return AVERROR(ENOMEM);
> +
> +st->side_data = tmp;
> +st->nb_side_data++;
> +
> +sd = >side_data[st->nb_side_data - 1];
> +sd->type = AV_PKT_DATA_STEREO3D;
> +sd->size = sizeof(*sc->stereo3d);
> +sd->data = (uint8_t *)sc->stereo3d;
> +sc->stereo3d = NULL;
> +}

The code duplication here should be refactored IMO.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] vf_hwupload_cuda: Fix build error

[Mark Thompson]

Broken by e3fb74f7f9a8f1895381355f40c92cac3c1023d9.
---
 libavfilter/vf_hwupload_cuda.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_hwupload_cuda.c b/libavfilter/vf_hwupload_cuda.c
index 94d5013..b5631c2 100644
--- a/libavfilter/vf_hwupload_cuda.c
+++ b/libavfilter/vf_hwupload_cuda.c
@@ -151,7 +151,7 @@ static int cudaupload_config_output(AVFilterLink *outlink)
 static int cudaupload_filter_frame(AVFilterLink *link, AVFrame *in)
 {
 AVFilterContext   *ctx = link->dst;
-CudaUploadContext   *s = ctx->priv;
+AVFilterLink  *outlink = ctx->outputs[0];

 AVFrame *out = NULL;
 int ret;
-- 
2.10.1

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/5] pixblockdsp: Have function pointer prototype match implementation

[Diego Biurrun]

On Tue, Nov 01, 2016 at 05:51:16PM +0100, Diego Biurrun wrote:
> libavcodec/pixblockdsp.c(58) : warning C4028: formal parameter 1 different 
> from declaration
> libavcodec/pixblockdsp.c(63) : warning C4028: formal parameter 1 different 
> from declaration
> libavcodec/pixblockdsp.c(66) : warning C4028: formal parameter 1 different 
> from declaration
> ---
>  libavcodec/pixblockdsp.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

OKed by Vittorio on IRC.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 5/5] float_dsp: Have implementation match function pointer prototype

[Diego Biurrun]

On Tue, Nov 01, 2016 at 05:51:18PM +0100, Diego Biurrun wrote:
> libavutil/x86/float_dsp_init.c(144) : warning C4028: formal parameter 1 
> different from declaration
> libavutil/x86/float_dsp_init.c(144) : warning C4028: formal parameter 2 
> different from declaration
> ---
>  libavutil/x86/float_dsp_init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

OKed by Vittorio on IRC.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/5] ituh263dec: Have function signature match across declaration and definition

[Diego Biurrun]

On Tue, Nov 01, 2016 at 05:51:15PM +0100, Diego Biurrun wrote:
> libavcodec/ituh263dec.c(215) : warning C4028: formal parameter 1 different 
> from declaration
> libavcodec/ituh263dec.c(215) : warning C4028: formal parameter 2 different 
> from declaration
> ---
>  libavcodec/h263.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

OKed by Vittorio on IRC.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] configure: Silence lld-link when getting the version number

[Luca Barbato]

On 03/11/2016 13:15, Martin Storsjö wrote:
> In recent lld-link versions, this command prints the version to
> stdout, but also prints an error to stderr:
> 
> $ lld-link -flavor gnu --version
> LLD 4.0.0 (trunk 285641)
> lld-link: error: no input files
> lld-link: error: target emulation unknown: -m or at least one .o file required
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 9264bb5..23be425 100755
> --- a/configure
> +++ b/configure
> @@ -3291,7 +3291,7 @@ probe_cc(){
>  _type=lld-link
>  # The link.exe mode doesn't have a switch for getting the version,
>  # but we can force it back to gnu mode and get the version from 
> there.
> -_ident=$($_cc -flavor gnu --version)
> +_ident=$($_cc -flavor gnu --version 2>/dev/null)
>  _ld_o='-out:$@'
>  _flags_filter=msvc_flags
>  _ld_lib='lib%.a'
> 

Sure.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [RFC] [PATCH] configure: Make sure config.h isn't accidentally included in builds for the host

[Martin Storsjö]

In aacps_tablegen.h, only include libm.h if building for the target.

If actual fallbacks are needed here (in practice, sinf and cosf,
which are missing on Plan 9 - they are present even on MSVC), we need
to include libm.h, but this relies on configure test results for the
target. These test results can't be used for the host (e.g. when this
header is used when building with --enable-hardcoded-tables).

This clearly breaks builds with hardcoded tables on Plan 9 (not
cross builds from another host to Plan 9 though), instead of relying on
coincidences that config.h for the target might match the host build
config as well.
---
 configure   | 4 
 libavcodec/aacps_tablegen.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/configure b/configure
index 9264bb5..b43642f 100755
--- a/configure
+++ b/configure
@@ -3719,6 +3719,7 @@ check_cc -D_LARGEFILE_SOURCE < $TMPH 

[libav-devel] [PATCH] configure: Silence lld-link when getting the version number

[Martin Storsjö]

In recent lld-link versions, this command prints the version to
stdout, but also prints an error to stderr:

$ lld-link -flavor gnu --version
LLD 4.0.0 (trunk 285641)
lld-link: error: no input files
lld-link: error: target emulation unknown: -m or at least one .o file required
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 9264bb5..23be425 100755
--- a/configure
+++ b/configure
@@ -3291,7 +3291,7 @@ probe_cc(){
 _type=lld-link
 # The link.exe mode doesn't have a switch for getting the version,
 # but we can force it back to gnu mode and get the version from there.
-_ident=$($_cc -flavor gnu --version)
+_ident=$($_cc -flavor gnu --version 2>/dev/null)
 _ld_o='-out:$@'
 _flags_filter=msvc_flags
 _ld_lib='lib%.a'
-- 
2.7.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] ppc: pixblockdsp: do unaligned block accesses correctly again

[Luca Barbato]

On 02/11/2016 21:34, Andreas Cadhalpun wrote:

> @@ -67,10 +67,10 @@ static void get_pixels_altivec(int16_t *restrict block, 
> const uint8_t *pixels,
> ptrdiff_t line_size)
>  {

The patch makes sense only if line_size is not a multiple of 16 and
normally AVFrames have their linesizes multiple of 32 ...

The fate tests in Libav pass w/out the patch on real hardware and qemu,
could you please tell me how do you get a line_size that is not multiple
of 16 ?

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] options_table: Remove a now unnecessary include of config.h

[Martin Storsjö]

On Thu, 3 Nov 2016, Martin Storsjö wrote:


The include of config.h was added in 2012 in 1d9c2dc8, due to
the use of CONFIG_SHOW_ENCODER ifdefs within options_table.h.


CONFIG_SNOW_ENCODER, of course. Amended locally.

// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] options_table: Remove a now unnecessary include of config.h

[Luca Barbato]

On 03/11/2016 09:58, Martin Storsjö wrote:
> The include of config.h was added in 2012 in 1d9c2dc8, due to
> the use of CONFIG_SHOW_ENCODER ifdefs within options_table.h.
> When the snow codec was dropped later (in a0c5917f8 in 2013),
> this include no longer served any purpose.

Ok with s/SHOW/SNOW/ I guess.

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3.5/8] qsvdec: Only warn about unconsumed data if it happens more than once

[Luca Barbato]

On 02/11/2016 23:23, Mark Thompson wrote:
> ---
> To fit into the middle of the qsv set, before VC-1.
> 
> Mitigates the spam output from the vc1_qsv decoder - a single failure like 
> this is probably just a residual fragment of a packet, not a real problem.
> 

Should also mitigate the spam in h264 bitstreams with trailing zeroes.

Fine for me for sure =)

lu

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] options_table: Remove a now unnecessary include of config.h

[Martin Storsjö]

The include of config.h was added in 2012 in 1d9c2dc8, due to
the use of CONFIG_SHOW_ENCODER ifdefs within options_table.h.
When the snow codec was dropped later (in a0c5917f8 in 2013),
this include no longer served any purpose.

options_table.h is included in builds for the host as well, when
building documentation. config.h should not be included in code
that is built for the host, since it can contain workarounds
for the target compiler/environment, like adding a missing define
of restrict, defining getenv(x) to NULL for environments that lack
getenv.

The seemingly innocent include reordering in 2025d37871 broke
builds that have getenv(x) defined to NULL in config.h (Windows CE
and Windows Phone/RT), since libavcodec/options_table.h include
config.h, while libavformat/options_table.h end up bringing in
more system headers, and those system headers can contain a proper
definition of getenv, which clash with the getenv define in config.h.
This was avoided earlier as long as libavformat/options_table.h (or
avformat.h) was included before libavcodec/options_table.h.

This fixes builds for Windows Phone/RT and CE.
---
 libavcodec/options_table.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 04cb20d..b1f9a92 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -26,7 +26,6 @@
 #include "libavutil/opt.h"
 #include "avcodec.h"
 #include "version.h"
-#include "config.h"
 
 #define OFFSET(x) offsetof(AVCodecContext,x)
 #define DEFAULT 0 //should be NAN but it does not work as it is not a constant 
in glibc as required by ANSI/ISO C
-- 
2.7.4

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCHv4] arm: vp9: Add NEON optimizations of VP9 MC functions

[Janne Grunau]

On 2016-11-02 23:14:28 +0200, Martin Storsjö wrote:
> On Wed, 2 Nov 2016, Martin Storsjö wrote:
> 
> I'll push the arm version tomorrow unless there's more comments on it.

patch ok. push when you want.

Janne
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] ppc: pixblockdsp: do unaligned block accesses correctly again

[Luca Barbato]

On 02/11/2016 21:34, Andreas Cadhalpun wrote:
> Tested with qemu on ppc32be and ppc64be.

How did you configure it?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel