Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-14 Thread Lennart Sorensen 
On Sat, Nov 12, 2016 at 10:00:53PM +0200, Adrian Bunk wrote:
> I do not understand this part.
> 
> -maltivec should only be set for the code that is behind the runtime 
> feature check, so this code is only run on hardware that has AltiVec.

Well a mistake in the configure script is making it set for everything.

After fixing that there is the problem of how to build merge.c in
deinterlace with only -maltivec for the altivec merge function, and not
the rest of the file which is supposed to be the generic C implementation.

I guess like the yuv file that has altivec support, the altivec merge
function needs to be built by itself with -maltivec while the rest of
the file is built without it.

I am trying to figure out how to do that but haven't quite figured it
out yet.  Certainly that is the correct way to fix it.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-08 Thread Lennart Sorensen 
On Fri, Nov 04, 2016 at 01:33:36PM -0400, Lennart Sorensen wrote:
> And of course I made a typo while copying things into the patch.
> 
> Doing another build test of it now.
> 
> --- vlc-2.2.4.orig/configure.ac   2016-05-31 12:11:07.0 -0400
> +++ vlc-2.2.4/configure.ac2016-11-04 12:22:02.543265439 -0400
> @@ -1422,25 +1422,24 @@
>VLC_SAVE_FLAGS
>AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
>[ac_cv_c_altivec], [
> -CFLAGS="${CFLAGS} -maltivec"
> +CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
>  [#include ]], [
>  [vec_ld(0, (unsigned char *)0);]])], [
> -  ac_cv_c_altivec="-maltivec"
> +  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
>  ], [
>ac_cv_c_altivec="no"
>  ])
>])
> -  VLC_RESTORE_FLAGS
>AS_IF([test "${ac_cv_c_altivec}" != "no"], [
>  CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
>  AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
> are available.])
> -VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> -ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> -VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
> +ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}"
> +VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
> ${ac_cv_c_altivec_abi}])
>  have_altivec="yes"
>])
>AC_CHECK_HEADERS(altivec.h)
> +  VLC_RESTORE_FLAGS
>  
>VLC_SAVE_FLAGS
>LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

That did not quite work, so I had to try the slightly more complicated
patch.

This patch works:

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-08 10:28:54.763640362 -0500
@@ -1422,25 +1422,23 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"
--- vlc-2.2.4.orig/modules/video_filter/Modules.am  2015-02-02 
14:42:29.0 -0500
+++ vlc-2.2.4/modules/video_filter/Modules.am   2016-11-08 10:28:31.391639060 
-0500
@@ -29,6 +29,7 @@
 libdeinterlace_plugin_la_SOURCES += deinterlace/merge_arm.S
 libdeinterlace_plugin_la_CFLAGS += -DCAN_COMPILE_ARM
 endif
+libdeinterlace_plugin_la_CFLAGS += $(ALTIVEC_CFLAGS)
 video_filter_LTLIBRARIES += libdeinterlace_plugin.la
 
 libdynamicoverlay_plugin_la_SOURCES = \

With this patch, only functions inside a CPU feature check for altivec
support has any vector instructions.

And I realized the reason it was broken is that when using -maltivec and
-O4 (which vlc uses), you get -ftree-vectorize automatically enabled
which means gcc starts to automatically generate vector instructions
all over the place, which is not desired in this case.  It rather defeats
the purpose of having a cpu feature check after all.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-04 Thread Lennart Sorensen 
And of course I made a typo while copying things into the patch.

Doing another build test of it now.

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-04 12:22:02.543265439 -0400
@@ -1422,25 +1422,24 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-tree-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-tree-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
+VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
${ac_cv_c_altivec_abi}])
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"


-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-04 Thread Lennart Sorensen 
Actually maybe this simpler version is better.  I think I just figured
out why libdeinterlace wasn't getting the altivec flags, which was that
it was listed as deinterlace rather than libdeinterlace.

Doing a build test of it now.

--- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400
+++ vlc-2.2.4/configure.ac  2016-11-04 12:22:02.543265439 -0400
@@ -1422,25 +1422,24 @@
   VLC_SAVE_FLAGS
   AC_CACHE_CHECK([if \$CC groks AltiVec C extensions],
   [ac_cv_c_altivec], [
-CFLAGS="${CFLAGS} -maltivec"
+CFLAGS="${CFLAGS} -maltivec -fno-vectorize"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#include ]], [
 [vec_ld(0, (unsigned char *)0);]])], [
-  ac_cv_c_altivec="-maltivec"
+  ac_cv_c_altivec="-maltivec -fno-vectorize"
 ], [
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
-VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
-ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
-VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
+ALTIVEC_CFLAGS="$ALTIVEC_CFLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
+VLC_ADD_CFLAGS([libdeinterlace],[${ac_cv_c_altivec} 
${ac_cv_c_altivec_abi}])
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-03 Thread Lennart Sorensen 
On Tue, Nov 01, 2016 at 01:42:17PM -0400, Lennart Sorensen wrote:
> Well that looks like it only adds it for libvlccore.

So at least something like this is needed, but I think the VLCCORE is
wrong too, and maybe the deinterlace has to be moved to only merge.c
rather than all of deinterlace.

--- configure.ac.orig   2016-11-03 13:56:25.826878272 -0400
+++ configure.ac2016-11-03 13:56:55.558878272 -0400
@@ -1431,7 +1431,6 @@
   ac_cv_c_altivec="no"
 ])
   ])
-  VLC_RESTORE_FLAGS
   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
 CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"
 AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
@@ -1441,6 +1440,7 @@
 have_altivec="yes"
   ])
   AC_CHECK_HEADERS(altivec.h)
+  VLC_RESTORE_FLAGS
 
   VLC_SAVE_FLAGS
   LDFLAGS="${LDFLAGS} -Wl,-framework,vecLib"

The CPPFLAGS are being clobbered with the -maltivec, which is only needed
when testing altivec.h, and should be removed again after that.

That removes the -maltivec that was showing up everywhere at least, and
now it is only in a few places, although perhaps still a few too many.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen 
On Tue, Nov 01, 2016 at 07:37:33PM +0200, Adrian Bunk wrote:
> On Tue, Nov 01, 2016 at 01:08:03PM -0400, Lennart Sorensen wrote:
> > On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote:
> > > On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> > > > This doesn't looks wrong to me.
> > > > 
> > > > Note that depending on the software --enable-altivec can either mean
> > > > - compile unconditionally for AltiVec, or
> > > > - enable AltiVec parts with autodetection to only use them when the
> > > >   hardware supports it
> > > 
> > > Well in VLC it means build with -maltivec among other things.
> > > 
> > > > As I already wrote, vlc contains AltiVec-specific code and 
> > > > autodetection 
> > > > for using it only when the hardware supports it.
> > > > 
> > > > This should be enabled on all ppc ports, except the SPE one.
> > > > 
> > > > --enable-altivec also adding -maltivec elsewhere is a bug.
> > > 
> > > Well it certainly appears to have been done on purpose in the configure
> > > script.  Maybe it is a bug.  Perhaps I should poke it a bit...
> > > 
> > > > And due to this bug the whole AltiVec autodetection in vlc is
> > > > pretty useless.
> > > 
> > > Well if it has such auto detection, then yes it is.
> > 
> > I currently suspect:
> > 
> > configure.ac:
> > ...
> >   ])
> >   VLC_RESTORE_FLAGS
> >   AS_IF([test "${ac_cv_c_altivec}" != "no"], [
> > CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"  <-- this looks wrong
> > AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec 
> > extensions are available.])
> > VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> > ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} 
> > ${ac_cv_c_altivec_abi}"
> > ...
> > 
> > I think that line should not be there since all over CPPFLAGS is used as
> > part of the COMPILE variable, meaning not just CFLAGS gets -maltivec when
> > needed through ALTIVEC_CFLAGS, but in fact everywhere that has CPPFLAGS
> > gets it, meaning everything.
> 
> I was more suspecting the VLC_ADD_CFLAGS() would be the problem,
> but since the build log says "-maltivec -maltivec" it is actually
> likely that this is wrong in more than one place.

Well that looks like it only adds it for libvlccore.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen 
On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote:
> On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> > This doesn't looks wrong to me.
> > 
> > Note that depending on the software --enable-altivec can either mean
> > - compile unconditionally for AltiVec, or
> > - enable AltiVec parts with autodetection to only use them when the
> >   hardware supports it
> 
> Well in VLC it means build with -maltivec among other things.
> 
> > As I already wrote, vlc contains AltiVec-specific code and autodetection 
> > for using it only when the hardware supports it.
> > 
> > This should be enabled on all ppc ports, except the SPE one.
> > 
> > --enable-altivec also adding -maltivec elsewhere is a bug.
> 
> Well it certainly appears to have been done on purpose in the configure
> script.  Maybe it is a bug.  Perhaps I should poke it a bit...
> 
> > And due to this bug the whole AltiVec autodetection in vlc is
> > pretty useless.
> 
> Well if it has such auto detection, then yes it is.

I currently suspect:

configure.ac:
...
  ])
  VLC_RESTORE_FLAGS
  AS_IF([test "${ac_cv_c_altivec}" != "no"], [
CPPFLAGS="${CPPFLAGS} ${ac_cv_c_altivec}"  <-- this looks wrong
AC_DEFINE(CAN_COMPILE_C_ALTIVEC, 1, [Define to 1 if C AltiVec extensions 
are available.])
VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
...

I think that line should not be there since all over CPPFLAGS is used as
part of the COMPILE variable, meaning not just CFLAGS gets -maltivec when
needed through ALTIVEC_CFLAGS, but in fact everywhere that has CPPFLAGS
gets it, meaning everything.

I will try compile testing that as soon as I have the system ready.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen 
On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote:
> This doesn't looks wrong to me.
> 
> Note that depending on the software --enable-altivec can either mean
> - compile unconditionally for AltiVec, or
> - enable AltiVec parts with autodetection to only use them when the
>   hardware supports it

Well in VLC it means build with -maltivec among other things.

> As I already wrote, vlc contains AltiVec-specific code and autodetection 
> for using it only when the hardware supports it.
> 
> This should be enabled on all ppc ports, except the SPE one.
> 
> --enable-altivec also adding -maltivec elsewhere is a bug.

Well it certainly appears to have been done on purpose in the configure
script.  Maybe it is a bug.  Perhaps I should poke it a bit...

> And due to this bug the whole AltiVec autodetection in vlc is
> pretty useless.

Well if it has such auto detection, then yes it is.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen 
On Mon, Oct 31, 2016 at 11:13:00PM +0200, Adrian Bunk wrote:
> This actually looks like a bug in upstream configure.ac to me:
> VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}])
> ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}"
> VLC_ADD_CFLAGS([deinterlace],[${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}])
> 
> It is correct that this adds -maltivec to AltiVec-specific code,
> and vlc has proper autodetection to run this only when AltiVec
> is actually present.
> 
> The VLC_ADD_CFLAGS here look just wrong - it is not the job of 
> configure.ac to add such flags to generic code (whatever march
> and hardware features are present is defined through compiler
> defaults and the CFLAGS passed by the user).

Actually what looks really wrong is that debian/rules builds ffmpeg with
--disable-altivec and then builds vlc with --enable-altivec.

Since powerpc can't assume you have altivec, perhaps vlc shouldn't be
built with it, or at least ought to have justification for why it is
done that way.  Maybe it was thought that no CPU without altivec would
be powerful enough to bother using vlc, but I think that may not in fact
be a valid assumption these days.

Certainly a 2.5GHz e5500 core is pretty decent performance, but has
no altivec.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#774651: liblo7 is not multiarch enabled preventing installation of amd64 and i386 versions at the same time

2015-01-05 Thread Lennart Sorensen 
Package: liblo7
Version: 0.28-3
Severity: important
Tags: patch

I was helping a friend figure out why he couldn't install dssi-vst:i386 on
his amd64 Linux Mint 17 without it wanting to remove some other packages.

I pretty quickly noticed that the problem was in fact that installing
liblo7:i386 wants to remove liblo7:amd64 because it isn't multiarch
enabled.  The version of the package in Linux Mint 17 is the same as
the one in Ubuntu which is the same as the one in Debian, and since I
use Debian, I figure the problem ought to be solved at the root directly.

Here is a patch that makes liblo7 multiarch, and it has solved my friends
problem and is working fine there.  Both 32 and 64bit programs using
liblo7 are now happy.

-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF8, LC_CTYPE=en_CA.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
Len Sorensen
diff -r -u liblo-0.28/debian/control liblo-0.28.multiarch/debian/control
--- liblo-0.28/debian/control	2014-02-10 09:49:11.0 -0500
+++ liblo-0.28.multiarch/debian/control	2015-01-05 12:57:53.024415513 -0500
@@ -1,10 +1,10 @@
 Source: liblo
 Priority: optional
 Section: libs
-Build-Depends: cdbs,
+Build-Depends: cdbs (= 0.4.93~),
  autotools-dev,
  dh-autoreconf,
- debhelper,
+ debhelper (= 8.1.3),
  dh-buildinfo,
  doxygen
 Homepage: http://liblo.sourceforge.net/
@@ -49,6 +49,8 @@
 Suggests: liblo-dev
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Multi-Arch: same
 Description: Lightweight OSC library
  LibLO is a lightweight, easy to use implementation of the OSC (Open
  Sound Control) protocol (see 
diff -r -u liblo-0.28/debian/liblo7.install liblo-0.28.multiarch/debian/liblo7.install
--- liblo-0.28/debian/liblo7.install	2014-02-10 09:49:11.0 -0500
+++ liblo-0.28.multiarch/debian/liblo7.install	2015-01-05 12:52:16.911371733 -0500
@@ -1 +1 @@
-debian/tmp/usr/lib/lib*.so.*
+debian/tmp/usr/lib/*/lib*.so.*
diff -r -u liblo-0.28/debian/liblo-dev.install liblo-0.28.multiarch/debian/liblo-dev.install
--- liblo-0.28/debian/liblo-dev.install	2014-02-10 09:49:11.0 -0500
+++ liblo-0.28.multiarch/debian/liblo-dev.install	2015-01-05 12:55:06.483868874 -0500
@@ -1,5 +1,5 @@
 debian/tmp/usr/include/*
-debian/tmp/usr/lib/lib*.a
-debian/tmp/usr/lib/lib*.so
-debian/tmp/usr/lib/pkgconfig/*
+debian/tmp/usr/lib/*/lib*.a
+debian/tmp/usr/lib/*/lib*.so
+debian/tmp/usr/lib/*/pkgconfig/*
 doc/html usr/share/doc/liblo-dev
diff -r -u liblo-0.28/debian/rules liblo-0.28.multiarch/debian/rules
--- liblo-0.28/debian/rules	2014-02-10 09:49:11.0 -0500
+++ liblo-0.28.multiarch/debian/rules	2015-01-05 12:55:58.806785215 -0500
@@ -27,6 +27,7 @@
 # suppress optional build-dependencies
 CDBS_BUILD_DEPENDS_rules_upstream-tarball =
 CDBS_BUILD_DEPENDS_rules_utils_copyright-check =
+DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
 pre-build::
 	test $(DEB_HOST_ARCH_CPU) != sparc
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#774651: liblo7 is not multiarch enabled preventing installation of amd64 and i386 versions at the same time

2015-01-05 Thread Lennart Sorensen 
On Mon, Jan 05, 2015 at 05:03:08PM -0300, Felipe Sateler wrote:
 Excellent! I am unfortunately fairly busy these days. I would welcome
 a team upload or even an NMU to experimental with this patch.

I am just a user.  One of these days I should apply to become a DD.

 Unfortunately, given the freeze it will not make it to jessie :(

Well that makes sense.  I doubt it is a common problem.  I think most
people don't really use multiarch.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-03-04 Thread Lennart Sorensen 
On Tue, Mar 04, 2014 at 02:59:44AM +, peter green wrote:
 Seems sane to me. armv7 devices without neon are relatively uncommon
 so while it's important that they are supported it's IMO not vitally
 important to squeeze out every last drop of performance from them.

I don't agree.  At least the fisrt Tegra chips did not have neon, and the
marvell chips often don't have neon (the newer ones are starting to now
that they are moving to using Cortex-A designs, rather than marvell custom
cores (like the JP4 used in the armada 510 in the cubox for example),
but many chips don't have neon).  Do the qualcomm designs have neon?
I have been mostly ignoring them due to the anti open source attitude
of qualcomm.

If with=arm_fpu auto selects neon or VFP3 automatically, then I think
armhf is perfect for all armv7 devices.

 I wonder what we should use on raspbian? I haven't tested on a Pi
 yet but it seems that on all tests i've seen so-far the generic fpu
 code is quite a bit slower than the arm nofpu code. Is there any
 quality difference from using a fpu vs nonfpu decoder? If so how
 much performance degredation do you beleive should be accepted in
 exchange for that quality improvement.

So VFP2 is slower than interger math?  Interesting.

 IMO it's often better to be explicit about this sort of thing. While
 upstreams defaults may align with debian armhf's requirements at the
 present time and on the present build hardware such defaults are
 subject to change either as a result of upstream changes in new
 versions or as a result of different build hardware.

I suppose that makes sense.  Avoids unexpected surprises later.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-03-03 Thread Lennart Sorensen 
On Sun, Mar 02, 2014 at 12:02:40PM +0100, Thomas Orgis wrote:
 After Tahei didn't stop at this (big thanks from here!), we got a new
 snapshot,
 
   http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 ,
 
 that will hopefully become mpg123 1.19.0 soon (not 1.18.x
 because of feature additions regarding this very debian issue). The
 main points:
 
 - float output with all decoders (also arm_nofpu)
 - ARM decoders (esp. NEON) working with debian toolchain
 - new --with-cpu=arm_fpu choice with runtime detection to switch
   between NEON or normal FPU
 
 So, the number of builds for optimal treatment of differing platforms
 reduces to two:
 
 1. --with-cpu=arm_nofpu
 2. --with-cpu=arm_fpu
 
 I hope we can all be happy about that. I'd also be glad to get some
 confirmation from debian that it really works now. Release will be
 imminent, then.
 
 Thanks for staying with us with all the chattering about this ...

I now see (with arm_fpu of course, which it seems to have auto detected 
correctly):

perl scripts/benchmark-cpu.pl `which mpg123` /convergence_-_points_of_view/*mp3
Found 3 CPU optimizations to test...

#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
NEON7.587.84
generic 19.23   14.56
generic_dither  20.97   14.54

Looks good.  I ran it 3 times and they were very close, and the cpu pinned
itself at 1.5GHz during the test, and went back to 1.0GHz when idle again.
One of the two cores was very bored though with nothing to do.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-03-03 Thread Lennart Sorensen 
On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote:
 That sounds like if the mpg123 package should use:
 
 on armel: --with-cpu=arm_nofpu
 on armhf: --with-cpu=arm_fpu
 
 
 Does this make sense to everybody?

I think so.  armhf's current debian rules automatically picked arm_fpu
with the new version's configure script, so at least that one doesn't
seem to need any explicit help.  armel might though.

 Thank you for handling this issue (and basically every issue other
 that popped out in Debian for mpg123) so quickly!

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-25 Thread Lennart Sorensen 
On Tue, Feb 25, 2014 at 11:18:50AM +0100, Thomas Orgis wrote:
 Am Tue, 25 Feb 2014 17:37:41 +0900
 schrieb Taihei Momma t...@mac.com: 
 
  #0  0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
   ^
  not a multiple of 4.
 
 Oh, d'oh! It could be that simple.
 
  I've just committed a fix to mpg123 repository 
 
 I generated a new snapshot,
 
   http://mpg123.org/snapshot/mpg123-20140225111416.tar.bz2 ,
 
 and also attached the patch for the rather small change that hopefully
 has a big effect. Care to test this?
 
 
 Alrighty then,
 
 Thomas
 
 -- 
 Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
 OrgisNetzOrganisation ---)=- http://orgis.org
 GPG public key D446D524: http://thomas.orgis.org/public_key
 Fingerprint: 7236 3885 A742 B736 E0C8 9721 9B4C 52BC D446 D524

 Index: src/libmpg123/dct64_neon_float.S
 ===
 --- src/libmpg123/dct64_neon_float.S  (Revision 3514)
 +++ src/libmpg123/dct64_neon_float.S  (Revision 3515)
 @@ -44,6 +44,7 @@
   .word 1060439283
   .word 1060439283
   .globl ASM_NAME(dct64_real_neon)
 + ALIGN4
  ASM_NAME(dct64_real_neon):
   vpush   {q4-q7}
  
 Index: src/libmpg123/dct64_neon.S
 ===
 --- src/libmpg123/dct64_neon.S(Revision 3514)
 +++ src/libmpg123/dct64_neon.S(Revision 3515)
 @@ -44,6 +44,7 @@
   .word 1060439283
   .word 1060439283
   .globl ASM_NAME(dct64_neon)
 + ALIGN4
  ASM_NAME(dct64_neon):
   vpush   {q4-q7}
  

root@rceng05:/mpg123-20140225111416# gdb --args 
/tmp/mpginst/usr/local/bin/mpg123 -e s16 -q --cpu NEON -t 
/convergence_-_points_of_view/*mp3
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as arm-linux-gnueabihf.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /tmp/mpginst/usr/local/bin/mpg123...done.
(gdb) run
Starting program: /tmp/mpginst/usr/local/bin/mpg123 -e s16 -q --cpu NEON -t 
/convergence_-_points_of_view/01\ -\ Bleed.mp3 
/convergence_-_points_of_view/02\ -\ Strike\ the\ end.mp3 
/convergence_-_points_of_view/03\ -\ Listen.mp3 
/convergence_-_points_of_view/04\ -\ Six\ feet\ under.mp3 
/convergence_-_points_of_view/05\ -\ Always\ the\ same.mp3 
/convergence_-_points_of_view/06\ -\ Breath.mp3 
/convergence_-_points_of_view/07\ -\ Vanished\ memories.mp3 
/convergence_-_points_of_view/08\ -\ Silent.mp3 
/convergence_-_points_of_view/09\ -\ Nothing\ else.mp3 
/convergence_-_points_of_view/10\ -\ Train\ to\ leave.mp3

Program received signal SIGILL, Illegal instruction.
0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:49
49  vpush   {q4-q7}
(gdb) disassemble
Dump of assembler code for function INT123_dct64_neon:
   0xb6fb9330 +0: vpush   {d8-d15}
   0xb6fb9334 +4: sub r3, pc, #140; 0x8c
   0xb6fb9338 +8: vld1.32 {d0-d3}, [r2]!
   0xb6fb933c +12:vld1.32 {d4-d7}, [r2]!
   0xb6fb9340 +16:vld1.32 {d8-d11}, [r2]!
   0xb6fb9344 +20:vld1.32 {d12-d15}, [r2]
   0xb6fb9348 +24:vld1.32 {d24-d27}, [r3 :128]!
   0xb6fb934c +28:vld1.32 {d28-d31}, [r3 :128]!
   0xb6fb9350 +32:vrev64.32   q4, q4
   0xb6fb9354 +36:vrev64.32   q5, q5
   0xb6fb9358 +40:vrev64.32   q6, q6
   0xb6fb935c +44:vrev64.32   q7, q7
   0xb6fb9360 +48:vswpd8, d9
   0xb6fb9364 +52:vswpd10, d11
   0xb6fb9368 +56:vswpd12, d13
   0xb6fb936c +60:vswpd14, d15
   0xb6fb9370 +64:vsub.f32q8, q0, q7
   0xb6fb9374 +68:vsub.f32q9, q1, q6
   0xb6fb9378 +72:vsub.f32q10, q2, q5
   0xb6fb937c +76:vsub.f32q11, q3, q4
   0xb6fb9380 +80:vadd.f32q0, q0, q7
   0xb6fb9384 +84:vadd.f32q1, q1, q6
   0xb6fb9388 +88:vadd.f32q2, q2, q5
   0xb6fb938c +92:vadd.f32q3, q3, q4
   0xb6fb9390 +96:vmul.f32q4, q8, q12
   0xb6fb9394 +100:   vmul.f32q5, q9, q13
   0xb6fb9398 +104:   vmul.f32q6, q10, q14
   0xb6fb939c +108:   vmul.f32q7, q11, q15
   0xb6fb93a0 +112:   vld1.32 {d24-d27}, [r3 :128]!
   0xb6fb93a4 +116:   vld1.32 {d28-d31}, [r3 :128]
   0xb6fb93a8 +120:   vrev64.32   q2, q2
   0xb6fb93ac +124:   vrev64.32   q3, q3
   0xb6fb93b0 +128:   vrev64.32   q6, q6
   0xb6fb93b4 +132:   vrev64.32   q7, q7
   0xb6fb93b8 +136:   vswpd4, d5
   0xb6fb93bc +140:   vswpd6, d7
   0xb6fb93c0 +144:   vswpd12, d13
   0xb6fb93c4 +148:   vswpd14, d15
   0xb6fb93c8 +152:   vsub.f32q8, q0, q3
   0xb6fb93cc +156:   vsub.f32q9, q1, q2

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-25 Thread Lennart Sorensen 
On Wed, Feb 26, 2014 at 01:59:12AM +0900, Taihei Momma wrote:
 On 2014/02/26, at 1:44, Thomas Orgis wrote:
 
  That address didn't change.
 
 
 Well, the function itself is properly aligned (so my fix didn't take effect 
 anyway).
  0xb6fb9330 +0: vpush   {d8-d15}
  0xb6fb9334 +4: sub r3, pc, #140; 0x8c
 
 But the processor decoded the first instruction as 2-byte (thumb?), then 
 increased PC by 2. And it raised SIGILL at
  0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:49
 
 
 So, I guess
  - assembler emits a bad machine code for vpush
 or
  - kernel is not configured properly to run vfp instructions

Is that a kernel option?  I wouldn't have thought armhf would run without
that (unless no floating point code is every being run).

Well the kernel that is running has this:

CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

 I'd like to look into objdump -d result to check the machine code. 

Remember Debian armhf is -mthumb by default.  Any assembly code needs
to be properly flagged with .arm, or .syntax unified or whatever is
appropriate (still trying to wrap my head around this myself).  That is
if the assembly code is written in arm rather than thumb2 assembly.
At least that's my understanding so far.  If I add .syntax unified and
.fpu neon, then I no longer have to pass -mfpu neon to the CFLAGS to
get it to compile, but it still fails.  I am just about to test the new
version to see if that helps anything.

The disassembly in gcc shows 4 byte alignment, but the address of the
illegal instruction is 2 bytes past the vpush instruction's address.

In fact if I add -marm to the CFLAGS, then it seems to work, so the .S
files are not being flagged correctly as being arm code, or they are
missing thumb interworking bits or something.

root@rceng05:/mpg123-20140225173909# perl scripts/benchmark-cpu.pl src/mpg123 
/convergence_-_points_of_view/*mp3
Found 1 CPU optimizations to test...

#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
NEON7.527.65

That was with CFLAGS=-g -mcpu=cortex-a15 -mfpu=neon -marm

Without -marm, it crashes with illegal instruction.  But since -mthumb
is the default on armhf, then passing -marm seems wrong.

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-24 Thread Lennart Sorensen 
On Sat, Feb 22, 2014 at 10:05:35AM +0100, Thomas Orgis wrote:
 Am Fri, 21 Feb 2014 11:25:12 -0500
 schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca: 
 
  Testing with the neon build I get a return code of 4, and it seems to
  be failing to run.  It was a pain to even get it to compile.  Using just
  the configure option, the assembler complained about the NEON instructions
  being invalid for the chosen cpu type.  Adding -mfpu=neon to the CFLAGS
  made it able to compile, but it still crashes with illegal instruction.
  I tried with CFLAGS set to -mcpu=cortex-a15 -mfpu=neon, and that still
  gives illegal instruction when running it.
 
 This is weird. What happened in debian side since
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667653#35 ? We have
 the current code working on this setup:
 
 device: iPod touch 4G with iOS 5.1.1
 toolchain: gcc 4.2.1(from Xcode 3.2.6) on OSX 10.6.8, clang 3.3(from Xcode 
 5.0.2) on OSX 10.9.1 (double checked)
 configure script option: --host=armv7-apple-darwin --with-cpu=arm_nofpu[neon] 
 --with-audio=dummy --disable-shared --enable-static [--enable-int-quality]
 
 Taihei also just checked the compliance of the decoder choices
 including NEON. That illegal instruction ... care to fire up the
 debugger to tell us where it actually occurs? The NEON assembly is
 written as plain assembler input (cpp + as), you can see the
 instructions we use right there and it doesn't differ from iOS.
 
  It might be a good idea to have the benchmark script actuall check the
  return code of system()
 
 Yes.
 
  I was building and testing under Debian armhf sid.
  gcc (Debian 4.8.2-16) 4.8.2
  
  CPU is a dual Cortex-A15 1.5GHz (TI OMAP 57xx).
 
 
 Alrighty then,

Any help from this:

(gdb) run
Starting program: /tmp/mpginst/usr/local/bin/mpg123 -e s16 -q --cpu NEON -t 
/convergence_-_points_of_view/01\ -\ Bleed.mp3 
/convergence_-_points_of_view/02\ -\ Strike\ the\ end.mp3 
/convergence_-_points_of_view/03\ -\ Listen.mp3 
/convergence_-_points_of_view/04\ -\ Six\ feet\ under.mp3 
/convergence_-_points_of_view/05\ -\ Always\ the\ same.mp3 
/convergence_-_points_of_view/06\ -\ Breath.mp3 
/convergence_-_points_of_view/07\ -\ Vanished\ memories.mp3 
/convergence_-_points_of_view/08\ -\ Silent.mp3 
/convergence_-_points_of_view/09\ -\ Nothing\ else.mp3 
/convergence_-_points_of_view/10\ -\ Train\ to\ leave.mp3

Program received signal SIGILL, Illegal instruction.
0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
48  vpush   {q4-q7}
(gdb) where
#0  0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
#1  0xb6fab71c in INT123_synth_1to1_stereo_neon (bandPtr_l=optimized out, 
bandPtr_r=0x36400, fr=0x291d8) at synth.c:892
#2  0xb6fb8328 in INT123_do_layer3 (fr=0x291d8) at layer3.c:2060
#3  0xb6fa725e in decode_the_frame (fr=fr@entry=0x291d8) at libmpg123.c:699
#4  0xb6fa823e in mpg123_decode_frame_64 (mh=0x291d8, num=num@entry=0x28490 
framenum, audio=audio@entry=0xbefff8e8, bytes=bytes@entry=0xbefff8f0) at 
libmpg123.c:838
#5  0x00012fce in play_frame () at mpg123.c:667
#6  0xb2f0 in main (sys_argc=optimized out, sys_argv=optimized out) at 
mpg123.c:1177

-- 
Len Sorensen

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-21 Thread Lennart Sorensen 
On Fri, Feb 21, 2014 at 01:29:40AM +, peter green wrote:
 Thomas Orgis wrote:
 So, I got conversion to float implemented now and tested with the
 generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
 too;-) If you'd like to check the current snapshot of mpg123,
 
  http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 ,
 
 you hopefull will find that any normal build of mpg123 (unless
 specifying --disable-float explicitly) now offers all usual formats. As
 a bonus, I even implemented the 8 Bit A-Law output, which has always
 just been a placeholder (nobody missed it, apparently).
 
 I'd be interested on some timings of
 
  mpg123 -t -e s16 test.mp3
  mpg123 -t -e f32 test.mp3
 
 with the various builds you'll do for the ARM variants. Best would be running
 
  perl scripts/benchmark-cpu.pl src/mpg123 
  convergence_-_points_of_view/*.mp3
 
 with
 
  http://mpg123.orgis.org/convergence_-_points_of_view.tar.gz
 
 as reference album, as mentioned on
 
  http://mpg123.orgis.org/benchmarking.shtml
 
 to be able to compare the performance of the code and machine to
 others. This yields output like this:
 
 #mpg123 benchmark (user CPU time in seconds for decoding)
 #decoder t_s16/s t_f32/s
 x86-64   3.394.05
 generic  6.156.01
 generic_dither   6.365.97
 
 ... or this, with --with-cpu=generic_fpu:
 
 #mpg123 benchmark (user CPU time in seconds for decoding)
 #decoder t_s16/s t_f32/s
 generic  6.146.29
 
 (on a Core2Duo machine)
 Ok, on a 1GHz freescale IMX53 (cortex A8) in a (probablly somewhat
 out of date) debian sid armhf chroot I tested with perl
 scripts/benchmark-cpu.pl src/mpg123
 convergence_-_points_of_view/*.mp3 in the following configurations.
 
 Built with ./configure --with-cpu=arm_nofpu
 #mpg123 benchmark (user CPU time in seconds for decoding)
 #decodert_s16/s t_f32/s
 ARM 30.36   34.26
 
 Built with ./configure --with-cpu=generic_fpu
 #mpg123 benchmark (user CPU time in seconds for decoding)
 #decodert_s16/s t_f32/s
 generic 148.66  138.49
 
 Build with CFLAGS=-mfpu=neon ./configure --with-cpu=neon
 #mpg123 benchmark (user CPU time in seconds for decoding)
 #decodert_s16/s t_f32/s
 NEON0.030.04
 
 I found the neon result unbelivable so I decided to run the test
 program you mentioned to me in my private mail asking about how to
 run the benchmarks.
 root@plugwash:/mpg123-test#
 LD_LIBRARY_PATH=/mpg123-20140220132548-arm_nofpu/src/libmpg123/.libs/
 perl compliance.pl /mpg123-20140220132548-arm_nofpu/src/mpg123
 
  Layer 1 
 -- 16 bit signed integer output
 fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL)
 fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL)
 fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL)
 fl4.bit:RMS=1.510105e-01 (FAIL) maxdiff=5.277658e-01 (FAIL)
 fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL)
 fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL)
 fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL)
 fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL)
 -- 32 bit integer output
 fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL)
 fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL)
 fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL)
 fl4.bit:RMS=1.513207e-01 (FAIL) maxdiff=4.787517e-01 (FAIL)
 fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL)
 fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL)
 fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL)
 fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL)
 -- 24 bit integer output
 fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL)
 fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL)
 fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL)
 fl4.bit:RMS=1.494715e-01 (FAIL) maxdiff=4.984906e-01 (FAIL)
 fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL)
 fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL)
 fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL)
 fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL)
 -- 32 bit floating point output
 fl1.bit:RMS=3.486054e-02 (FAIL) maxdiff=5.002832e-02 (FAIL)
 fl2.bit:RMS=3.485670e-02 (FAIL) maxdiff=5.008233e-02 (FAIL)
 fl3.bit:RMS=3.485293e-02 (FAIL) maxdiff=5.008245e-02 (FAIL)
 fl4.bit:RMS=1.137037e-01 (FAIL) maxdiff=4.459082e-01 (FAIL)
 fl5.bit:RMS=3.109439e-01 (FAIL) maxdiff=4.475173e-01 (FAIL)
 fl6.bit:RMS=1.649138e-01 (FAIL) maxdiff=4.589995e-01 (FAIL)
 fl7.bit:RMS=2.211659e-02 (FAIL) maxdiff=2.959942e-01 (FAIL)
 fl8.bit:RMS=3.484906e-02 (FAIL) maxdiff=5.002034e-02 (FAIL)
 
  Layer 2 
 -- 16 bit signed integer output
 fl10.bit:

Bug#641478: Patch to fix ffmpeg 0.5.5-1 build on powerpc.

2011-11-09 Thread Lennart Sorensen 
On Tue, Nov 08, 2011 at 04:42:56PM -0500,  wrote:
 This patched fixes building of ffmpeg 0.5.5-1 on powerpc for me.
 It matches what the code is now like in newer versions of ffmpeg.
 
 diff -urN ffmpeg-0.5.5/libavcodec/cavs.h 
 ffmpeg-0.5.5.powerpcfix/libavcodec/cavs.h
 --- ffmpeg-0.5.5/libavcodec/cavs.h2011-11-05 07:57:22.0 -0400
 +++ ffmpeg-0.5.5.powerpcfix/libavcodec/cavs.h 2011-11-08 16:27:24.051972526 
 -0500
 @@ -136,7 +136,7 @@
MV_BWD_X3
  };
  
 -DECLARE_ALIGNED_8(typedef, struct) {
 +DECLARE_ALIGNED(8, typedef, struct) {
  int16_t x;
  int16_t y;
  int16_t dist;
 
 
 So not much to the patch.  Compiles on squeeze for me.
 
 Haven't looked at the armel one yet, but I probably could.

Same patch actually fixed armel compile as well.

-- 
Len Sroensen



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#641478: Patch to fix ffmpeg 0.5.5-1 build on powerpc.

2011-11-08 Thread Lennart Sorensen 
This patched fixes building of ffmpeg 0.5.5-1 on powerpc for me.
It matches what the code is now like in newer versions of ffmpeg.

diff -urN ffmpeg-0.5.5/libavcodec/cavs.h 
ffmpeg-0.5.5.powerpcfix/libavcodec/cavs.h
--- ffmpeg-0.5.5/libavcodec/cavs.h  2011-11-05 07:57:22.0 -0400
+++ ffmpeg-0.5.5.powerpcfix/libavcodec/cavs.h   2011-11-08 16:27:24.051972526 
-0500
@@ -136,7 +136,7 @@
   MV_BWD_X3
 };
 
-DECLARE_ALIGNED_8(typedef, struct) {
+DECLARE_ALIGNED(8, typedef, struct) {
 int16_t x;
 int16_t y;
 int16_t dist;


So not much to the patch.  Compiles on squeeze for me.

Haven't looked at the armel one yet, but I probably could.

-- 
Len Sorense



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#639948: Bug#638250: Needs to be adapted for libav/0.7

2011-09-04 Thread Lennart Sorensen 
On Sun, Sep 04, 2011 at 08:47:59AM +0200, Reinhard Tartler wrote:
 I strongly disagree that this arch specific defect on ppc is in any way
 a blocking bug for recompiling moc-ffmpeg-plugin against the new libav
 libraries.  It only affects (some?) altivec enabled machines and can be
 easily avoided by disabling the altivec variant.
 
 Ideally, we find a porter that can identify the bug and provide a patch
 for fixing the segmentation fault. I've copied the powerpc porters and
 ask them hereby for their assistance.
 
 Or, if porters approached me, I also could disable the altivec builds in
 libav completely, penalizing potential altivec users that do not
 experience this issue.

Are there any that don't experience it?

I just tried running ffmpeg on a power6+ machine under gdb and got:

Program received signal SIGSEGV, Segmentation fault.
0x0f6ff37c in ff_fft_calc_altivec () at 
/root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447
447 DECL_FFTS 0
(gdb) where
#0  0x0f6ff37c in ff_fft_calc_altivec () at 
/root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447
#1  0x0f6feaa8 in ff_imdct_half_altivec (s=optimized out, output=optimized 
out, input=optimized out) at 
/root/libav-0.7.1/libavcodec/ppc/fft_altivec.c:93
#2  0x0f437ce8 in imdct_and_windowing (ac=0x10040ca0, sce=0xf7f260c0) at 
/root/libav-0.7.1/libavcodec/aacdec.c:1856
#3  0x0f43caa8 in spectral_to_sample (ac=optimized out) at 
/root/libav-0.7.1/libavcodec/aacdec.c:2015
#4  aac_decode_frame_int (avctx=optimized out, data=0xf7f95020, 
data_size=0xda78, gb=optimized out) at 
/root/libav-0.7.1/libavcodec/aacdec.c:2170
#5  0x0f43ccec in aac_decode_frame (avctx=optimized out, data=optimized 
out, data_size=optimized out, avpkt=optimized out)
at /root/libav-0.7.1/libavcodec/aacdec.c:2216
#6  0x0f77f25c in avcodec_decode_audio3 (avctx=0x100406a0, samples=optimized 
out, frame_size_ptr=optimized out, avpkt=optimized out)
at /root/libav-0.7.1/libavcodec/utils.c:726
#7  0x0ff3f924 in try_decode_frame (avpkt=0x100466e0, st=0x1003ede0) at 
/root/libav-0.7.1/libavformat/utils.c:2104
#8  av_find_stream_info (ic=0x1003e840) at 
/root/libav-0.7.1/libavformat/utils.c:2388
#9  0x1000b200 in opt_input_file (opt=optimized out, filename=optimized 
out) at /root/libav-0.7.1/ffmpeg.c:3271
#10 0x1000f0fc in parse_options (argc=4, argv=0xe184, options=0x10026720, 
parse_arg_function=0x1000cfd0 opt_output_file) at 
/root/libav-0.7.1/cmdutils.c:287
#11 0x100067c8 in main (argc=4, argv=optimized out) at 
/root/libav-0.7.1/ffmpeg.c:
(gdb) Program received signal SIGSEGV, Segmentation fault.

Anyone have an idea what to look at exactly?  I really wish debug builds
wouldn't have so much 'optimized out' stuff that makes reading stack
traces so hard.

-- 
Len Sorensen



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#639948: Bug#638250: Needs to be adapted for libav/0.7

2011-09-04 Thread Lennart Sorensen 
On Sun, Sep 04, 2011 at 04:13:52PM -0400, Lennart Sorensen wrote:
 Are there any that don't experience it?
 
 I just tried running ffmpeg on a power6+ machine under gdb and got:
 
 Program received signal SIGSEGV, Segmentation fault.
 0x0f6ff37c in ff_fft_calc_altivec () at 
 /root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447
 447 DECL_FFTS 0
 (gdb) where
 #0  0x0f6ff37c in ff_fft_calc_altivec () at 
 /root/libav-0.7.1/libavcodec/ppc/fft_altivec_s.S:447
 #1  0x0f6feaa8 in ff_imdct_half_altivec (s=optimized out, output=optimized 
 out, input=optimized out) at 
 /root/libav-0.7.1/libavcodec/ppc/fft_altivec.c:93
 #2  0x0f437ce8 in imdct_and_windowing (ac=0x10040ca0, sce=0xf7f260c0) at 
 /root/libav-0.7.1/libavcodec/aacdec.c:1856
 #3  0x0f43caa8 in spectral_to_sample (ac=optimized out) at 
 /root/libav-0.7.1/libavcodec/aacdec.c:2015
 #4  aac_decode_frame_int (avctx=optimized out, data=0xf7f95020, 
 data_size=0xda78, gb=optimized out) at 
 /root/libav-0.7.1/libavcodec/aacdec.c:2170
 #5  0x0f43ccec in aac_decode_frame (avctx=optimized out, data=optimized 
 out, data_size=optimized out, avpkt=optimized out)
 at /root/libav-0.7.1/libavcodec/aacdec.c:2216
 #6  0x0f77f25c in avcodec_decode_audio3 (avctx=0x100406a0, samples=optimized 
 out, frame_size_ptr=optimized out, avpkt=optimized out)
 at /root/libav-0.7.1/libavcodec/utils.c:726
 #7  0x0ff3f924 in try_decode_frame (avpkt=0x100466e0, st=0x1003ede0) at 
 /root/libav-0.7.1/libavformat/utils.c:2104
 #8  av_find_stream_info (ic=0x1003e840) at 
 /root/libav-0.7.1/libavformat/utils.c:2388
 #9  0x1000b200 in opt_input_file (opt=optimized out, filename=optimized 
 out) at /root/libav-0.7.1/ffmpeg.c:3271
 #10 0x1000f0fc in parse_options (argc=4, argv=0xe184, options=0x10026720, 
 parse_arg_function=0x1000cfd0 opt_output_file) at 
 /root/libav-0.7.1/cmdutils.c:287
 #11 0x100067c8 in main (argc=4, argv=optimized out) at 
 /root/libav-0.7.1/ffmpeg.c:
   (gdb) Program received signal SIGSEGV, Segmentation fault.
 
 Anyone have an idea what to look at exactly?  I really wish debug builds
 wouldn't have so much 'optimized out' stuff that makes reading stack
 traces so hard.

So it turns out it was reported to ffmpeg upstream 3 months ago and fixed 
already.

http://ffmpeg.org/trac/ffmpeg/ticket/272

The patch to libavcodec/ppc/asm.S is in comment #8.

It no longer segfaults for me with that patch applied.

Apparently when compiling in pic mode, the new assembly altived fft
code always segfaults, while the old version was C code and worked fine.
Apparently an offset calculation was done wrong as far as I understand it.

-- 
Len Sorensen



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers