[NEW] opencore-amr-0.1.3

2012-03-20 Thread Jan Stary
I am trying again to get this commited.

Is there something I can do to increase the amount of fsck given,
or is there actually objections to this?

Jan



port-opencore-amr-0.1.3.tar.gz
Description: application/tar-gz


[NEW] opencore-amr-0.1.3

2012-03-06 Thread Jan Stary
While I was trying to get this commited, a new version came out.
So here goes: AMR, an implmentation of the Adaptive Multi Rate
speech codec, version 0.1.3.

Comments? OK?

Jan



port-opencore-amr-0.1.3.tar.gz
Description: application/tar-gz


[NEW] opencore-amr

2012-02-27 Thread Jan Stary
This is a port of opencore-amr, an implementation
of the Adaptive Multi Rate speech codec.
http://opencore-amr.sourceforge.net/

(This has been reviewed a few times, and occasionally OK'd,
but I never got anyone to actually commit it.)

Jan



port-opencore-amr-0.1.2.tar.gz
Description: application/tar-gz


Re: [NEW] opencore-amr

2012-01-11 Thread Jan Stary
On Jan 02 13:18:25, Jan Stary wrote:
 On Dec 20 22:34:46, Jan Stary wrote:
  On Dec 16 11:16:48, Jan Stary wrote:
   On Dec 13 20:55:01, Jan Stary wrote:
Are there further comments or objections to commiting this?
   
   Is there something else I need to do
   for someone with commit rights to consider this?
  
  Is it the Christmass or is there simply zero interest in this?
 
 So, I got an OK from David Coppa. Anyone else interested
 in this, preferebaly with commit rights? Any further comments?

What other options do I have to get this in besides asking again?

Jan



Re: [NEW] opencore-amr

2012-01-02 Thread Jan Stary
On Dec 20 22:34:46, Jan Stary wrote:
 On Dec 16 11:16:48, Jan Stary wrote:
  On Dec 13 20:55:01, Jan Stary wrote:
   Are there further comments or objections to commiting this?
  
  Is there something else I need to do
  for someone with commit rights to consider this?
 
 Is it the Christmass or is there simply zero interest in this?

So, I got an OK from David Coppa. Anyone else interested
in this, preferebaly with commit rights? Any further comments?

Thank you

Jan



Re: [NEW] opencore-amr

2011-12-21 Thread David Coppa
On Tue, Dec 20, 2011 at 10:34 PM, Jan Stary h...@stare.cz wrote:
 On Dec 16 11:16:48, Jan Stary wrote:
 On Dec 13 20:55:01, Jan Stary wrote:
  Are there further comments or objections to commiting this?

 Is there something else I need to do
 for someone with commit rights to consider this?

 Is it the Christmass or is there simply zero interest in this?

Used this to watch a few 3gp videos of our son that my wife shot with
her Android phone, and it worked well: ok for me.

ciao,
David



Re: [NEW] opencore-amr

2011-12-20 Thread Jan Stary
On Dec 16 11:16:48, Jan Stary wrote:
 On Dec 13 20:55:01, Jan Stary wrote:
  Are there further comments or objections to commiting this?
 
 Is there something else I need to do
 for someone with commit rights to consider this?

Is it the Christmass or is there simply zero interest in this?

Jan



Re: [NEW] opencore-amr

2011-12-16 Thread Jan Stary
On Dec 13 20:55:01, Jan Stary wrote:
 Are there further comments or objections to commiting this?

Is there something else I need to do
for someone with commit rights to consider this?

Thank you

Jan



Re: [NEW] opencore-amr

2011-12-13 Thread Jan Stary
  audio/sox
  graphics/ffmpeg
  multimedia/avidemux
  multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)

The above seem to not be broken (or in fact influenced)
by the presence of opencore-amr as installed from the port
(as attached) - see previous posts.

The tests described in my previous posts have been done on
current/i386 and current/amd64.

Are there further comments or objections to commiting this?

Thanks

Jan





opencore-amr-0.1.2.tar.gz
Description: application/tar-gz


Re: [NEW] opencore-amr

2011-12-13 Thread Christian Weisgerber
Jan Stary h...@stare.cz wrote:

 Is this OK?
 http://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec#Licensing_and_patent_issues
 
 # Apache 2.0
 PERMIT_PACKAGE_CDROM  = patents, http://www.voiceage.com/amr_licterms.php
 PERMIT_PACKAGE_FTP= Yes
 PERMIT_DISTFILES_CDROM= patents, 
 http://www.voiceage.com/amr_licterms.php
 PERMIT_DISTFILES_FTP  = Yes

Yes, that's fine.

-- 
Christian naddy Weisgerber  na...@mips.inka.de



Re: [NEW] opencore-amr

2011-12-11 Thread Marc Espie
On Sat, Dec 10, 2011 at 10:37:38PM +0100, Jan Stary wrote:
 Once gstreamer/core is installed and I try to build
 streamer/plugins-bad, the build stops with
 
 === Verifying specs: glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 xml2  z m
 pcre gstreamer-0.10 intl=5 iconv=6 glib-2.0 gmodule-2.0 gobject-2.0
 gthread-2.0 xml2  z m pcre gstreamer-0.10 intl=5 iconv=6 BPM GL SDL
 SoundTouch X11 Xau Xdamage Xdmcp Xext Xfixes Xrender Xxf86vm ass bz2
 cairo cdaudio croco-0.6 crypto curl dca drm dvdnav dvdread enca expat
 fontconfig freetype gdk_pixbuf-2.0 gio-2.0 gsm gstaudio-0.10
 gstbase-0.10 gstcontroller-0.10 gstinterfaces-0.10 gstpbutils-0.10
 gstriff-0.10 gstrtp-0.10 gstsdp-0.10 gsttag-0.10 gstvideo-0.10 idn
 jasper lrdf mms mpcdec orc-0.4 pango-1.0 pangocairo-1.0 pangoft2-1.0
 pixman-1 png pthread-stubs raptor rsvg-2 schroedinger-1.0 sndfile sndio
 ssl stdc++ usbhid vpx xcb xcb-render xcb-shm xslt glib-2.0 gmodule-2.0
 gobject-2.0 gthread-2.0 xml2  z m pcre gstreamer-0.10 intl=5 iconv=6
 gstbase-0.10 neon  crypto expat ssl asn1 gssapi krb5 glib-2.0
 gmodule-2.0 gobject-2.0 gthread-2.0 xml2  z m pcre gstreamer-0.10
 intl=5 iconv=6  gstbase-0.10 stdc++ mjpegutils-1.9 mpeg2encpp-1.9
 mplex2-1.9
 Missing library for BPM=0.0
 Missing library for SoundTouch=0.0
 Missing library for croco-0.6=0.0
 Missing library for gstaudio-0.10=0.0
 Missing library for gstinterfaces-0.10=0.0
 Missing library for gstpbutils-0.10=0.0
 Missing library for gstriff-0.10=0.0
 Missing library for gstrtp-0.10=0.0
 Missing library for gstsdp-0.10=0.0
 Missing library for gsttag-0.10=0.0
 Missing library for gstvideo-0.10=0.0
 Missing library for rsvg-2=0.0
 Missing library for sndfile=0.0
 Missing library for mjpegutils-1.9=0.0
 Missing library for mpeg2encpp-1.9=0.0
 Missing library for mplex2-1.9=0.0
 Fatal error
 *** Error code 1
 
 Is there something I need to install first that would pull these
 as dependencies, as opposed to installing them explicitly?
 Am I missing something?

You're trying to mix -current with older stuff, that doesn't work.
you need to have a fully current infrastructure...



Re: [NEW] opencore-amr

2011-12-11 Thread Jan Stary
On Jul 01 17:01:41, Stuart Henderson wrote:
 The following ports are very likely to pick this up:
 
 audio/sox
 graphics/ffmpeg
 multimedia/avidemux
 multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)
 
 These need to be built with opencore-amr already installed and checked as
 to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
 but also LIB*_EXTRALIBS in ffmpeg). Ports depending on these also need to
 be checked for additional WANTLIB.

 The current gstreamer/core build breaks for me,
 for reasons unrelated to opencore-amr:

On Dec 11 10:53:52, Marc Espie wrote:
 You're trying to mix -current with older stuff, that doesn't work.
 you need to have a fully current infrastructure...

I have upgraded and gstreamer builds fine.
With opencore-amr installed, the configure does not pick it up,
and the resulting binaries and libraries do ot depend on it (says ldd).

What else is there to test?

Thanks

Jan



Re: [NEW] opencore-amr

2011-12-11 Thread Jan Stary
On Dec 10 22:37:38, Jan Stary wrote:
 I am trying again to get this AMR port commited:
 http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz

On Dec 10 14:06:27, Marc Espie wrote:
 There's been some recent confusion as to which version of a patch someone
 was referring to, because it was an external link, and the external link
 got changed to something else.

 That's a common rookie mistake: as soon as you publish/send a patch link
 to someone, consider that link eternal. If you change the patch later,
 it's totally trivial to give it a version number, and *make sure to provide
 a different link*.
 
 Otherwise, it's really easy to lose track and attribution. And such mix-ups
 tend to lead to the wrong code being committed ('but he said it was okay
 nah, I never saw that version of the patch'), which leads to further
 time lost to figure out the fuck-up...
 
 
 Also, your work may be more easily/quickly reviewed if it's included
 *directly* in your email.

 People with commit access are chronically overworked.  every small thing you
 can do to make things easier is generally appreciated, thank you.

OK, I get it. Sorry.  Attached is the current state of opencore-amr.

Jan



opencore-amr-0.1.2.tar.gz
Description: application/tar-gz


Re: [NEW] opencore-amr

2011-12-10 Thread Jan Stary
Replying to an old thread when I finally got around to it,
I am trying again to get this AMR port commited:
http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz

Meanwhile, I have found that David Coppa tried to
get this in before (and later OK'd my attempt):
http://marc.info/?t=12761017433r=1w=2
http://marc.info/?l=openbsd-portsm=130952776413954w=2
(David, why is it you were building --with-pic?)

However, there were objections, which I try to address below.

On Jul 01 17:01:41, Stuart Henderson wrote:
 On 2011-07-01, Giovanni Bechis giova...@openbsd.org wrote:
  On 07/01/11 15:39, David Coppa wrote:
  To anyone who wants to import it, you have my ok.
  Enable regression test as well, ok for me.
 The following ports are very likely to pick this up:
 
 audio/sox

I maintain audio/sox; in fact, the reason I am trying
to import AMR is to have AMR support in SoX.

SoX's configure has --with-amrnb and --with-amrwb,
but also picks up http://opencore-amr.sourceforge.net/
or http://ftp.penguin.cz/pub/users/utx/amr/ silently,
in that order of preference.

That makes a hidden dependency if either is present.
That's why we have --without-amrnb and --without-amrwb
in the current SoX Makefile. (I have a sox diff prepared
that I want to put in once the opencore-amr port gets in.)


 graphics/ffmpeg

ffmpeg's configure recognizes --enable-libopencore-amrnb
and --enable-libopencore-amrwb which both default to 'no';
the port does not override this and ffmpeg ignores
the installed openore-amr (and uses its own internal AMR
implementation in libavcodec/*amr*, which in turn is itself
a copy of the opencore implementation). ldd says the resulting
ffmpeg does not depend on the opencore libraries.

Anyway, we've been here:
http://marc.info/?l=openbsd-portsm=130956193621550w=2


 multimedia/avidemux

http://marc.info/?l=openbsd-portsm=130969989416158w=2

avidemux configure ignores the installed opencore-amr,
and ldd says the resulting avidemux does not depend on it.

However, it silently picks up another AMR implementation library,
namely that provided at http://ftp.penguin.cz/pub/users/utx/amr/
So I think avidemux already has the problem we are trying to discover,
but with respect to amrnb. Indeed, ldd says the resulting avidemux
depends on libamrnb.so (those are NOT the opencore-amr
liraries, but the http://ftp.penguin.cz/pub/users/utx/amr/ libs).



 multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)

The current gstreamer/core build breaks for me,
for reasons unrelated to opencore-amr:

checking for flex...  /usr/local/bin/gflex
/usr/ports/pobj/gstreamer-0.10.35/gstreamer-0.10.35/configure[21243]: 
/usr/local/bin/gflex: not found
checking flex version  = 2.5.31... Use of uninitialized value 
$flex_version_major in numeric gt () at - line 3.

It seems that gstreamer/core BUILD_DEPENDS on flex but doesn't say so.
Similarly, the build apparently depends on gobject-introspection.

Once gstreamer/core is installed and I try to build
streamer/plugins-bad, the build stops with

=== Verifying specs: glib-2.0 gmodule-2.0 gobject-2.0 gthread-2.0 xml2  z m
pcre gstreamer-0.10 intl=5 iconv=6 glib-2.0 gmodule-2.0 gobject-2.0
gthread-2.0 xml2  z m pcre gstreamer-0.10 intl=5 iconv=6 BPM GL SDL
SoundTouch X11 Xau Xdamage Xdmcp Xext Xfixes Xrender Xxf86vm ass bz2
cairo cdaudio croco-0.6 crypto curl dca drm dvdnav dvdread enca expat
fontconfig freetype gdk_pixbuf-2.0 gio-2.0 gsm gstaudio-0.10
gstbase-0.10 gstcontroller-0.10 gstinterfaces-0.10 gstpbutils-0.10
gstriff-0.10 gstrtp-0.10 gstsdp-0.10 gsttag-0.10 gstvideo-0.10 idn
jasper lrdf mms mpcdec orc-0.4 pango-1.0 pangocairo-1.0 pangoft2-1.0
pixman-1 png pthread-stubs raptor rsvg-2 schroedinger-1.0 sndfile sndio
ssl stdc++ usbhid vpx xcb xcb-render xcb-shm xslt glib-2.0 gmodule-2.0
gobject-2.0 gthread-2.0 xml2  z m pcre gstreamer-0.10 intl=5 iconv=6
gstbase-0.10 neon  crypto expat ssl asn1 gssapi krb5 glib-2.0
gmodule-2.0 gobject-2.0 gthread-2.0 xml2  z m pcre gstreamer-0.10
intl=5 iconv=6  gstbase-0.10 stdc++ mjpegutils-1.9 mpeg2encpp-1.9
mplex2-1.9
Missing library for BPM=0.0
Missing library for SoundTouch=0.0
Missing library for croco-0.6=0.0
Missing library for gstaudio-0.10=0.0
Missing library for gstinterfaces-0.10=0.0
Missing library for gstpbutils-0.10=0.0
Missing library for gstriff-0.10=0.0
Missing library for gstrtp-0.10=0.0
Missing library for gstsdp-0.10=0.0
Missing library for gsttag-0.10=0.0
Missing library for gstvideo-0.10=0.0
Missing library for rsvg-2=0.0
Missing library for sndfile=0.0
Missing library for mjpegutils-1.9=0.0
Missing library for mpeg2encpp-1.9=0.0
Missing library for mplex2-1.9=0.0
Fatal error
*** Error code 1

Is there something I need to install first that would pull these
as dependencies, as opposed to installing them explicitly?
Am I missing something?


 These need to be built with opencore-amr already installed and checked as
 to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
 but also LIB*_EXTRALIBS in ffmpeg).


Re: [NEW] opencore-amr

2011-12-10 Thread Jan Stary
On Jul 03 21:11:22, Christian Weisgerber wrote:
 Jan Stary h...@stare.cz wrote:
 
  http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz
  
  It comes with the Apache License 2.0; I am not sure
  what that means for the PERMIT_* variables; I asked
  upstream, but someone here surely knows.
 
 AMR is patent-encumbered.  We may not be able to put this on the
 CDROM.

Is this OK?
http://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec#Licensing_and_patent_issues

# Apache 2.0
PERMIT_PACKAGE_CDROM= patents, http://www.voiceage.com/amr_licterms.php
PERMIT_PACKAGE_FTP  = Yes
PERMIT_DISTFILES_CDROM  = patents, http://www.voiceage.com/amr_licterms.php
PERMIT_DISTFILES_FTP= Yes

Jan



libtool --mode=link and compilers flags (was Re: [NEW] opencore-amr)

2011-07-04 Thread Stuart Henderson
On 2011-07-01, Jan Stary h...@stare.cz wrote:
 On Jul 01 18:09:53, Stuart Henderson wrote:
 On 2011-07-01, Jan Stary h...@stare.cz wrote:
  It builds fine with USE_LIBTOOL=gnu.
 
  Yes it does. Thank you.
 
  I didn't know I could use USE_LIBTOOL=gnu.
 
 I forgot to comment on this earlier; it's available in cases where
 something doesn't package with ports libtool and a fix can't be
 found, but it's really a last resort.

 Well, does anyone know how to fix the USE_LIBTOOL issue
 described in the original post? It seems it puts '-x c'
 in front of *.o files, but I don't know libtool enough
 to spot and fix the exact bug.

cc'ing steven as the person who probably knows ports libtool the best ;)
quick summary: new port opencore-amr is having problems with our libtool.
port isn't committed yet, see http://junkpile.org/opencore-amr.tgz

it's setting -x c in flags to libtool for both compiler and linker.

/usr/ports/infrastructure/bin/libtool  --tag=CXX--mode=link c++ -Iblah 
blah, bunch of include paths -x c -std=c99  -O2 -pipe -version-info 0:2:0  -o 
libopencore-amrwb.la -rpath /usr/local/lib wrapper.lo blah blah, bunch of 
.lo's -lm

libtool passes this to the linker and this breaks the build.

For --mode=link, GNU libtool only include the specific flags relevant
to the linker, and strips out anything else. I think this behaviour
makes sense, diff below seems to work for opencore-amr but hasn't
been thoroughly tested and I don't really understand libtool well
enough to know if it will cause other problems.

So this needs more testing (a full bulk build would be good), and
review by somebody who knows how libtool is supposed to work.

Index: LibTool/Parser.pm
===
RCS file: /cvs/ports/infrastructure/lib/LibTool/Parser.pm,v
retrieving revision 1.1
diff -u -p -r1.1 Parser.pm
--- LibTool/Parser.pm   5 Dec 2010 16:37:50 -   1.1
+++ LibTool/Parser.pm   4 Jul 2011 10:24:07 -
@@ -295,7 +295,7 @@ sub parse_linkargs2
push(@$result, -Wl,$f);
}
} else {
-   push(@$result, $a);
+   Trace::debug {ignoring $a\n};
}
}
Trace::debug {end parse_linkargs2\n};



Re: [NEW] opencore-amr

2011-07-03 Thread Jan Stary
On Jul 01 17:01:41, Stuart Henderson wrote:
 multimedia/avidemux

This seems to ignore the installed opencore-amr libraries,
but has no ./configure options to explicitly disable them.
It uses its own libamr.c then.

Does that mean that avidemux is safe from the possible opencore-amr
import? Is there something else that can be done to make sure?

Jan


PS: it recognizes libamrnb, as disctributed at
http://ftp.penguin.cz/pub/users/utx/amr/ - so it has
another hidden dependency. I plan to port amrnb and
amrwb next.



Re: [NEW] opencore-amr

2011-07-03 Thread Brad

On 03/07/11 3:46 AM, Jan Stary wrote:

On Jul 01 19:08:47, Brad wrote:

On 01/07/11 6:18 PM, Jan Stary wrote:

audio/sox


I will take care of audio/sox. In fact, I have an update for
audio/sox ready, as my main motivation for porting AMR was
to have AMR functionality in SoX.


Make sure to update the license marker in the Makefile to
GPLv3+.


Why? Sox 14.3.2 comes with GPLv2, the sox libraries come with LGPLv2.1.
Now it contains new functionality of the opencore-amr that comes with
Apache License 2.0; why does it make GPLv3 the right thing for
the SoX port?


Because you cannot add opencore-amr to the SoX port if its under GPLv2. 
The licenses are incompatible.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: [NEW] opencore-amr

2011-07-03 Thread Jan Stary
On Jul 03 13:24:43, Brad wrote:
 On 03/07/11 3:46 AM, Jan Stary wrote:
 On Jul 01 19:08:47, Brad wrote:
 On 01/07/11 6:18 PM, Jan Stary wrote:
 audio/sox
 
 I will take care of audio/sox. In fact, I have an update for
 audio/sox ready, as my main motivation for porting AMR was
 to have AMR functionality in SoX.
 
 Make sure to update the license marker in the Makefile to
 GPLv3+.
 
 Why? Sox 14.3.2 comes with GPLv2, the sox libraries come with LGPLv2.1.
 Now it contains new functionality of the opencore-amr that comes with
 Apache License 2.0; why does it make GPLv3 the right thing for
 the SoX port?
 
 Because you cannot add opencore-amr to the SoX port if its under
 GPLv2. The licenses are incompatible.

Yes; but how does GPLv3 make it compatible?
opencore-amr itself is under Apache License 2.0.
Why does it mean that a package of SoX that uses
opencore-amr should be under GPLv3? Does GPLv3
somehow incorporate the Apache License?  I don't
mean I am against it; I just want to understand.



Re: [NEW] opencore-amr

2011-07-03 Thread Jan Stary
On Jul 01 17:01:41, Stuart Henderson wrote:
 On 2011-07-01, Giovanni Bechis giova...@openbsd.org wrote:
  On 07/01/11 15:39, David Coppa wrote:
  To anyone who wants to import it, you have my ok.
  
  Enable regression test as well, ok for me.
 
 The following ports are very likely to pick this up:
 
 audio/sox
 graphics/ffmpeg

The maintainer of ffmpeg says it is safe with respect to
possible AMR presence as it is.

 multimedia/avidemux
 multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)
 
 These need to be built with opencore-amr already installed and checked as
 to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
 but also LIB*_EXTRALIBS in ffmpeg). Ports depending on these also need to
 be checked for additional WANTLIB.
 
 I know this is a bunch of work - but I am not OK with importing this
 until it's done as it risks breaking a lot of packages.
 



Re: [NEW] opencore-amr

2011-07-03 Thread Brad

On 03/07/11 1:52 PM, Jan Stary wrote:

Why? Sox 14.3.2 comes with GPLv2, the sox libraries come with LGPLv2.1.


Then the SoX license marker in the port should also be updated to add 
the missing LGPL license too.



Now it contains new functionality of the opencore-amr that comes with
Apache License 2.0; why does it make GPLv3 the right thing for
the SoX port?


Because you cannot add opencore-amr to the SoX port if its under
GPLv2. The licenses are incompatible.


Yes; but how does GPLv3 make it compatible?


GPLv2 and GPLv3 are different licenses.


opencore-amr itself is under Apache License 2.0.
Why does it mean that a package of SoX that uses
opencore-amr should be under GPLv3?


Because they're INCOMPATIBLE. You cannot link AL 2.0 licensed
code to a GPLv2 licensed project.


Does GPLv3 somehow incorporate the Apache License?  I don't
mean I am against it; I just want to understand.


http://www.apache.org/licenses/GPL-compatibility.html

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: [NEW] opencore-amr

2011-07-03 Thread Jan Stary
On Jul 03 15:11:49, Brad wrote:
 http://www.apache.org/licenses/GPL-compatibility.html

Thanks, that's what I've been missing.



Re: [NEW] opencore-amr

2011-07-03 Thread Christian Weisgerber
Jan Stary h...@stare.cz wrote:

 http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz
 
 It comes with the Apache License 2.0; I am not sure
 what that means for the PERMIT_* variables; I asked
 upstream, but someone here surely knows.

AMR is patent-encumbered.  We may not be able to put this on the
CDROM.

-- 
Christian naddy Weisgerber  na...@mips.inka.de



Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
On Jun 29 21:35:25, Jan Stary wrote:
 http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz
 
 This is a port of opencore-amr, which is an implementation
 of the Adaptive Multi Rate speech codec that seems to be
 used by many modern mobile devices (such as my android).
 (This is my first new port - please be gentle.)
 
 The main motivation is to have AMR support in SoX
 (which will be the next step if this goes in).
 Neither libsndfile nor libaudiofile support AMR.
 
 Tested on amd64 and i386.
 
 Issues:
 
 (1)
 It comes with the Apache License 2.0; I am not sure
 what that means for the PERMIT_* variables; I asked
 upstream, but someone here surely knows.

Upstream confirms that all our PERMIT* variables
can be set to 'Yes' (as they are now).

 (2)
 With USE_LIBTOOL=Yes, the build fails in a strange way (see below).
 Without USE_LIBTOOL, everything goes fine. But I don't know enough
 about libtool to spot the exact problem (see my guess below, though).
 
   Comments?
 
   Jan
 
 
 # make
 ===  Configuring for opencore-amr-0.1.2
 configure: WARNING: unrecognized options: --disable-silent-rules
 configure: loading site script /usr/ports/infrastructure/db/config.site
 checking for a BSD-compatible install... /usr/bin/install -c -o root -g bin
 [configures fine]
 
 ===  Building for opencore-amr-0.1.2
 Making all in amrnb
 [builds fine, until]
 
 c++ -shared -fPIC -DPIC -o .libs/libopencore-amrnb.so.0.2 -I../oscl 
 -I../opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/src 
 -I../opencore/codecs_v2/audio/gsm_amr/amr_nb/common/include 
 -I../opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/include 
 -I../opencore/codecs_v2/audio/gsm_amr/common/dec/include 
 -I../opencore/codecs_v2/audio/gsm_amr/amr_nb/enc/src -x c -std=c99 -O2 -pipe 
 .libs/wrapper.o .libs/agc.o .libs/amrdecode.o .libs/a_refl.o .libs/b_cn_cod.o 
 .libs/bgnscd.o .libs/c_g_aver.o .libs/d1035pf.o .libs/d2_11pf.o 
 .libs/d2_9pf.o .libs/d3_14pf.o .libs/d4_17pf.o .libs/d8_31pf.o 
 .libs/dec_amr.o .libs/dec_gain.o .libs/dec_input_format_tab.o 
 .libs/dec_lag3.o .libs/dec_lag6.o .libs/d_gain_c.o .libs/d_gain_p.o 
 .libs/d_plsf_3.o .libs/d_plsf_5.o .libs/d_plsf.o .libs/dtx_dec.o 
 .libs/ec_gains.o .libs/ex_ctrl.o .libs/if2_to_ets.o .libs/int_lsf.o 
 .libs/lsp_avg.o .libs/ph_disp.o .libs/post_pro.o .libs/preemph.o 
 .libs/pstfilt.o .libs/qgain475_tab.o .libs/sp_dec.o .libs/wmf_to_ets.o 
 .libs/amrencode.o .libs/autocorr.o .libs/c1035pf.o .libs/c2_11pf.o 
 .libs/c2_9pf.o .libs/c3_14pf.o .libs/c4_17pf.o .libs/c8_31pf.o 
 .libs/calc_cor.o .libs/calc_en.o .libs/cbsearch.o .libs/cl_ltp.o 
 .libs/cod_amr.o .libs/convolve.o .libs/cor_h.o .libs/cor_h_x2.o 
 .libs/cor_h_x.o .libs/corrwght_tab.o .libs/div_32.o .libs/dtx_enc.o 
 .libs/enc_lag3.o .libs/enc_lag6.o .libs/enc_output_format_tab.o 
 .libs/ets_to_if2.o .libs/ets_to_wmf.o .libs/g_adapt.o .libs/gain_q.o 
 .libs/g_code.o .libs/g_pitch.o .libs/hp_max.o .libs/inter_36.o 
 .libs/inter_36_tab.o .libs/l_abs.o .libs/lag_wind.o .libs/lag_wind_tab.o 
 .libs/l_comp.o .libs/levinson.o .libs/l_extract.o .libs/lflg_upd.o 
 .libs/l_negate.o .libs/lpc.o .libs/ol_ltp.o .libs/pitch_fr.o .libs/pitch_ol.o 
 .libs/p_ol_wgh.o .libs/pre_big.o .libs/pre_proc.o .libs/prm2bits.o 
 .libs/qgain475.o .libs/qgain795.o .libs/q_gain_c.o .libs/q_gain_p.o 
 .libs/qua_gain.o .libs/s10_8pf.o .libs/set_sign.o .libs/sid_sync.o 
 .libs/sp_enc.o .libs/spreproc.o .libs/spstproc.o .libs/ton_stab.o 
 .libs/vad1.o .libs/add.o .libs/az_lsp.o .libs/bitno_tab.o 
 .libs/bitreorder_tab.o .libs/bytesused.o .libs/c2_9pf_tab.o .libs/div_s.o 
 .libs/extract_h.o .libs/extract_l.o .libs/gains_tbl.o .libs/gc_pred.o 
 .libs/get_const_tbls.o .libs/gmed_n.o .libs/gray_tbl.o .libs/grid_tbl.o 
 .libs/int_lpc.o .libs/inv_sqrt.o .libs/inv_sqrt_tbl.o .libs/l_deposit_h.o 
 .libs/l_deposit_l.o .libs/log2.o .libs/log2_norm.o .libs/log2_tbl.o 
 .libs/lsfwt.o .libs/l_shr_r.o .libs/lsp_az.o .libs/lsp.o .libs/lsp_lsf.o 
 .libs/lsp_lsf_tbl.o .libs/lsp_tab.o .libs/mult_r.o .libs/negate.o 
 .libs/norm_l.o .libs/norm_s.o .libs/overflow_tbl.o .libs/ph_disp_tab.o 
 .libs/pow2.o .libs/pow2_tbl.o .libs/pred_lt.o .libs/q_plsf_3.o 
 .libs/q_plsf_3_tbl.o .libs/q_plsf_5.o .libs/q_plsf_5_tbl.o .libs/q_plsf.o 
 .libs/qua_gain_tbl.o .libs/reorder.o .libs/residu.o .libs/round.o 
 .libs/set_zero.o .libs/shr.o .libs/shr_r.o .libs/sqrt_l.o .libs/sqrt_l_tbl.o 
 .libs/sub.o .libs/syn_filt.o .libs/weight_a.o .libs/window_tab.o -L.libs -lm
 .libs/wrapper.o:1: error: stray '\177' in program
 .libs/wrapper.o:1: error: stray '\2' in program
 .libs/wrapper.o:1: error: stray '\1' in program
 .libs/wrapper.o:1: error: stray '\1' in program
 
 - and similarly for every *.o file entioned in the above line;
 there seems to be an error message for almost every char on
 almost evry 'line' of these files.
 
 .libs/agc.o:1: error: stray '\177' in program
 .libs/agc.o:1: error: stray '\2' in program
 .libs/agc.o:1: error: stray '\1' in program
 .libs/agc.o:1: error: stray '\1' in program
 
 ... etc ...
 
 

Re: [NEW] opencore-amr

2011-07-01 Thread Giovanni Bechis
On 07/01/11 13:05, Jan Stary wrote:
 (2)
 With USE_LIBTOOL=Yes, the build fails in a strange way (see below).
 Without USE_LIBTOOL, everything goes fine. But I don't know enough
 about libtool to spot the exact problem (see my guess below, though).

It builds fine with USE_LIBTOOL=gnu.
 Cheers
  Giovanni



Re: [NEW] opencore-amr

2011-07-01 Thread David Coppa
On Fri, 01 Jul 2011, Jan Stary wrote:

 On Jun 29 21:35:25, Jan Stary wrote:
  http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz
  
  This is a port of opencore-amr, which is an implementation
  of the Adaptive Multi Rate speech codec that seems to be
  used by many modern mobile devices (such as my android).
  (This is my first new port - please be gentle.)
  
  The main motivation is to have AMR support in SoX
  (which will be the next step if this goes in).
  Neither libsndfile nor libaudiofile support AMR.
  
  Tested on amd64 and i386.
  
  Issues:
  
  (1)
  It comes with the Apache License 2.0; I am not sure
  what that means for the PERMIT_* variables; I asked
  upstream, but someone here surely knows.
 
 Upstream confirms that all our PERMIT* variables
 can be set to 'Yes' (as they are now).

Hi,

Fixed some stuff in your port: have a look.

ciao
David


opencore-amr_fixed.tgz
Description: application/tar-gz


Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
On Jun 29 21:35:25, Jan Stary wrote:
 This is a port of opencore-amr, which is an implementation
 of the Adaptive Multi Rate speech codec that seems to be
 used by many modern mobile devices (such as my android).
 (This is my first new port - please be gentle.)
 
 The main motivation is to have AMR support in SoX
 (which will be the next step if this goes in).
 Neither libsndfile nor libaudiofile support AMR.
 
 Tested on amd64 and i386.
 
 Issues:
 
 (1)
 It comes with the Apache License 2.0; I am not sure
 what that means for the PERMIT_* variables; I asked
 upstream, but someone here surely knows.
 
 (2)
 With USE_LIBTOOL=Yes, the build fails in a strange way (see below).
 Without USE_LIBTOOL, everything goes fine. But I don't know enough
 about libtool to spot the exact problem (see my guess below, though).

 It builds fine with USE_LIBTOOL=gnu.

Yes it does. Thank you.

I didn't know I could use USE_LIBTOOL=gnu.
The Makefile template says

# Programs that uses libtool should use this option,
# unless there is a really good reason not to.
#USE_LIBTOOL =  Yes

and only mentions 'gnu' as a possible value for CONFIGURE_STYLE
(which I did). Did I miss something? Is the possibility of
USE_LIBTOOL=gnu documented somewhere else?


On Jul 01 14:04:47, David Coppa wrote:
 Fixed some stuff in your port: have a look.

Thank you; I merged your modifications into a new version:
http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz

What exactly does the 0.0 mean in SHARED_LIBS?

SHARED_LIBS +=  opencore-amrnb 0.0
SHARED_LIBS +=  opencore-amrwb 0.0

Running 'make plist' suggests this; but if I build the software natively
(outside of the ports), the libraries are built and installed as *.so.0.2
Why is the above better than

SHARED_LIBS +=  opencore-amrnb 0.2
SHARED_LIBS +=  opencore-amrwb 0.2

Thank you for your time

Jan



Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
 What exactly does the 0.0 mean in SHARED_LIBS?
 
 SHARED_LIBS +=  opencore-amrnb 0.0
 SHARED_LIBS +=  opencore-amrwb 0.0
 
 Running 'make plist' suggests this; but if I build the software natively
 (outside of the ports), the libraries are built and installed as *.so.0.2
 Why is the above better than
 
 SHARED_LIBS +=  opencore-amrnb 0.2
 SHARED_LIBS +=  opencore-amrwb 0.2

In fact, pobj/opencore-amr-0.1.2/build-i386/shared_libs.log says:

# SHARED_LIBS+= libname  obsd version # orig version
SHARED_LIBS +=  opencore-amrnb   0.2  # .0.2
SHARED_LIBS +=  opencore-amrwb   0.2  # .0.2

So that's what I have put in.



Re: [NEW] opencore-amr

2011-07-01 Thread David Coppa
On Fri, 01 Jul 2011, Jan Stary wrote:

  What exactly does the 0.0 mean in SHARED_LIBS?
  
  SHARED_LIBS +=  opencore-amrnb 0.0
  SHARED_LIBS +=  opencore-amrwb 0.0
  
  Running 'make plist' suggests this; but if I build the software natively
  (outside of the ports), the libraries are built and installed as *.so.0.2
  Why is the above better than
  
  SHARED_LIBS +=  opencore-amrnb 0.2
  SHARED_LIBS +=  opencore-amrwb 0.2
 
 In fact, pobj/opencore-amr-0.1.2/build-i386/shared_libs.log says:
 
 # SHARED_LIBS+= libname  obsd version # orig version
 SHARED_LIBS +=  opencore-amrnb   0.2  # .0.2
 SHARED_LIBS +=  opencore-amrwb   0.2  # .0.2
 
 So that's what I have put in.

man bsd.port.mk

 SHARED_LIBS   List of shared libraries that the port may build, as a list
   of the form `libname' `libversion'.  Used to set variables
   of the form LIBlibname_VERSION that are then used for
   substitution by pkg_create(1).  The porter is responsible
   for making sure the port uses those version numbers when
   shared libraries are built.

   The intent is that the OpenBSD ports system must have
   control over shared library versions because of global
   changes that may require bumping the major version of every
   shared library in the system, or simply because the third
   party programmers do not understand the rules for shared
   library versions, thus breaking the update mechanism.  For
   that reason it is advised to set libversion to 0.0 when
   first importing a port.



Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
On Jul 01 14:41:24, David Coppa wrote:
 On Fri, 01 Jul 2011, Jan Stary wrote:
 
   What exactly does the 0.0 mean in SHARED_LIBS?
   
   SHARED_LIBS +=  opencore-amrnb 0.0
   SHARED_LIBS +=  opencore-amrwb 0.0
   
   Running 'make plist' suggests this; but if I build the software natively
   (outside of the ports), the libraries are built and installed as *.so.0.2
   Why is the above better than
   
   SHARED_LIBS +=  opencore-amrnb 0.2
   SHARED_LIBS +=  opencore-amrwb 0.2
  
  In fact, pobj/opencore-amr-0.1.2/build-i386/shared_libs.log says:
  
  # SHARED_LIBS+= libname  obsd version # orig version
  SHARED_LIBS +=  opencore-amrnb   0.2  # .0.2
  SHARED_LIBS +=  opencore-amrwb   0.2  # .0.2
  
  So that's what I have put in.
 
 man bsd.port.mk

OK, thanks. It is now in the port.
Further comments?



opencore-amr-0.1.2.tar.gz
Description: application/tar-gz


Re: [NEW] opencore-amr

2011-07-01 Thread David Coppa
On Fri, Jul 1, 2011 at 2:51 PM, Jan Stary h...@stare.cz wrote:

 OK, thanks. It is now in the port.
 Further comments?

Yes. You cannot sort stuff as you like.
Please, try to follow /usr/ports/infrastructure/templates/Makefile.template

ciao,
david



Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
On Jul 01 15:09:03, David Coppa wrote:
 On Fri, Jul 1, 2011 at 2:51 PM, Jan Stary h...@stare.cz wrote:
 
  OK, thanks. It is now in the port.
  Further comments?
 
 Yes. You cannot sort stuff as you like.
 Please, try to follow /usr/ports/infrastructure/templates/Makefile.template

It is in the template order now.

Jan



opencore-amr-0.1.2.tar.gz
Description: application/tar-gz


Re: [NEW] opencore-amr

2011-07-01 Thread David Coppa
On Fri, Jul 1, 2011 at 3:32 PM, Jan Stary h...@stare.cz wrote:
 On Jul 01 15:09:03, David Coppa wrote:
 On Fri, Jul 1, 2011 at 2:51 PM, Jan Stary h...@stare.cz wrote:

  OK, thanks. It is now in the port.
  Further comments?

 Yes. You cannot sort stuff as you like.
 Please, try to follow /usr/ports/infrastructure/templates/Makefile.template

 It is in the template order now.

And now it's good

To anyone who wants to import it, you have my ok.

Cheers!
David



Re: [NEW] opencore-amr

2011-07-01 Thread Giovanni Bechis
On 07/01/11 15:39, David Coppa wrote:
 To anyone who wants to import it, you have my ok.
 
Enable regression test as well, ok for me.
 Cheers
  Giovanni


opencore-amr-0.1.2.tar.gz
Description: application/gzip


Re: [NEW] opencore-amr

2011-07-01 Thread Stuart Henderson
On 2011-07-01, Giovanni Bechis giova...@openbsd.org wrote:
 On 07/01/11 15:39, David Coppa wrote:
 To anyone who wants to import it, you have my ok.
 
 Enable regression test as well, ok for me.

The following ports are very likely to pick this up:

audio/sox
graphics/ffmpeg
multimedia/avidemux
multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)

These need to be built with opencore-amr already installed and checked as
to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
but also LIB*_EXTRALIBS in ffmpeg). Ports depending on these also need to
be checked for additional WANTLIB.

I know this is a bunch of work - but I am not OK with importing this
until it's done as it risks breaking a lot of packages.




Re: [NEW] opencore-amr

2011-07-01 Thread Stuart Henderson
On 2011-07-01, Jan Stary h...@stare.cz wrote:
 It builds fine with USE_LIBTOOL=gnu.

 Yes it does. Thank you.

 I didn't know I could use USE_LIBTOOL=gnu.

I forgot to comment on this earlier; it's available in cases where
something doesn't package with ports libtool and a fix can't be
found, but it's really a last resort.




Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
On Jul 01 18:09:53, Stuart Henderson wrote:
 On 2011-07-01, Jan Stary h...@stare.cz wrote:
  It builds fine with USE_LIBTOOL=gnu.
 
  Yes it does. Thank you.
 
  I didn't know I could use USE_LIBTOOL=gnu.
 
 I forgot to comment on this earlier; it's available in cases where
 something doesn't package with ports libtool and a fix can't be
 found, but it's really a last resort.

Well, does anyone know how to fix the USE_LIBTOOL issue
described in the original post? It seems it puts '-x c'
in front of *.o files, but I don't know libtool enough
to spot and fix the exact bug.



Re: [NEW] opencore-amr

2011-07-01 Thread Jan Stary
On Jul 01 17:01:41, Stuart Henderson wrote:
 On 2011-07-01, Giovanni Bechis giova...@openbsd.org wrote:
  On 07/01/11 15:39, David Coppa wrote:
  To anyone who wants to import it, you have my ok.
  
  Enable regression test as well, ok for me.
 
 The following ports are very likely to pick this up:

What does 'pick it up' mean? If they want to use opencore-amr,
they will put it in their *_DEPENDS, edit their configure --options,
etc. They will not just 'pick it up' by accident, right?

 audio/sox

I will take care of audio/sox. In fact, I have an update for
audio/sox ready, as my main motivation for porting AMR was
to have AMR functionality in SoX.


Index: Makefile
===
RCS file: /cvs/ports/audio/sox/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile15 Jun 2011 08:29:34 -  1.49
+++ Makefile1 Jul 2011 22:13:31 -
@@ -3,7 +3,7 @@
 COMMENT=   Sound eXchange, the Swiss Army knife of audio manipulation
 
 DISTNAME=  sox-14.3.2
 
 CATEGORIES=audio
 HOMEPAGE=  http://sox.sourceforge.net/
@@ -18,8 +18,10 @@ PERMIT_DISTFILES_FTP=Yes
 MODULES=   converters/libiconv
 
 WANTLIB += c m ogg sndio z
-WANTLIB += vorbis vorbisenc vorbisfile FLAC magic
-WANTLIB += mad id3tag mp3lame wavpack png gsm
+WANTLIB += vorbis vorbisenc vorbisfile FLAC
+WANTLIB += opencore-amrnb opencore-amrwb
+WANTLIB += mad id3tag mp3lame wavpack
+WANTLIB += magic png gsm
 
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=sox/}
 
@@ -31,6 +33,7 @@ LIB_DEPENDS=  audio/libvorbis \
audio/libid3tag \
audio/lame \
audio/wavpack \
+   audio/opencore-amr \
graphics/png \
audio/gsm
 
@@ -58,8 +61,8 @@ CONFIGURE_ARGS+=--without-sndfile \
--with-mad \
--with-id3tag \
--with-lame \
-   --without-amrwb \
-   --without-amrnb \
+   --with-amrnb \
+   --with-amrwb \
--with-wavpack \
--with-png \
--without-ladspa




 graphics/ffmpeg

ffmpeg's configure recognizes

--enable-libopencore-amrnb
--enable-libopencore-amrwb

which default to [no] (but shouldn't ffmpeg's CONFIGURE_ARGS say

--disable-libopencore-amrnb
--disable-libopencore-amrwb

explicitly if it doesn't use it?).
Currently, the output of ffmpeg's configure just says

libopencore-amrnb support   no
libopencore-amrwb support   no

even with opencore-amr installed and seems to ignore it
(unlike other stuff, whose --enable-* defaults to [autodetect])


Index: Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.73
diff -u -p -r1.73 Makefile
--- Makefile24 Jun 2011 11:16:21 -  1.73
+++ Makefile1 Jul 2011 22:07:48 -
@@ -87,6 +87,8 @@ CONFIGURE_ARGS+= ${CONFIGURE_SHARED} \
--disable-outdev=oss \
--enable-gpl \
--enable-libgsm \
+   --disable-libopencore-amrnb \
+   --disable-libopencore-amrwb \
--enable-libmp3lame \
--enable-libschroedinger \
--enable-libspeex \


 multimedia/avidemux
 multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)

 These need to be built with opencore-amr already installed and checked as
 to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
 but also LIB*_EXTRALIBS in ffmpeg). Ports depending on these also need to
 be checked for additional WANTLIB.

What happens if some port's build chooses to use the installed 
opencore-amr libs, but doesn't mention it in WANTLIB etc?

 I know this is a bunch of work - but I am not OK with importing this
 until it's done as it risks breaking a lot of packages.

Would it be OK to explicitly --disable AMR in these ports
(before someone else chooses to correctly add the AMR
functionality to those ports), as above for ffmpeg?

Jan



Re: [NEW] opencore-amr

2011-07-01 Thread Landry Breuil
On Sat, Jul 02, 2011 at 12:18:23AM +0200, Jan Stary wrote:
 On Jul 01 17:01:41, Stuart Henderson wrote:
  On 2011-07-01, Giovanni Bechis giova...@openbsd.org wrote:
   On 07/01/11 15:39, David Coppa wrote:
   To anyone who wants to import it, you have my ok.
   
   Enable regression test as well, ok for me.
  
  The following ports are very likely to pick this up:
 
 What does 'pick it up' mean? If they want to use opencore-amr,
 they will put it in their *_DEPENDS, edit their configure --options,
 etc. They will not just 'pick it up' by accident, right?

That happens more than you think, and that's why you need to check it.
Or go the safe route and explicitely disable it there...

Landry



Re: [NEW] opencore-amr

2011-07-01 Thread Brad

On 01/07/11 6:18 PM, Jan Stary wrote:

audio/sox


I will take care of audio/sox. In fact, I have an update for
audio/sox ready, as my main motivation for porting AMR was
to have AMR functionality in SoX.


Make sure to update the license marker in the Makefile to
GPLv3+.


graphics/ffmpeg


ffmpeg's configure recognizes

--enable-libopencore-amrnb
--enable-libopencore-amrwb

which default to [no] (but shouldn't ffmpeg's CONFIGURE_ARGS say

--disable-libopencore-amrnb
--disable-libopencore-amrwb

explicitly if it doesn't use it?).


No.


Currently, the output of ffmpeg's configure just says

libopencore-amrnb support   no
libopencore-amrwb support   no

even with opencore-amr installed and seems to ignore it
(unlike other stuff, whose --enable-* defaults to [autodetect])


That's fine.


multimedia/avidemux
multimedia/gstreamer-0.10 (plugins-bad and plugins-ugly)

These need to be built with opencore-amr already installed and checked as
to whether they need additional deps listing (WANTLIB/LIB_DEPENDS as usual,
but also LIB*_EXTRALIBS in ffmpeg). Ports depending on these also need to
be checked for additional WANTLIB.


What happens if some port's build chooses to use the installed
opencore-amr libs, but doesn't mention it in WANTLIB etc?


If its installed and a program happens to pick it up it could
result in a hidden dependency and thus binar(ies) that are
broken in the resulting package.


Would it be OK to explicitly --disable AMR in these ports
(before someone else chooses to correctly add the AMR
functionality to those ports), as above for ffmpeg?


Not necessary for FFmpeg, the rest will be done.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



[NEW] opencore-amr

2011-06-29 Thread Jan Stary
http://stare.cz/~hans/.tmp/opencore-amr-0.1.2.tar.gz

This is a port of opencore-amr, which is an implementation
of the Adaptive Multi Rate speech codec that seems to be
used by many modern mobile devices (such as my android).
(This is my first new port - please be gentle.)

The main motivation is to have AMR support in SoX
(which will be the next step if this goes in).
Neither libsndfile nor libaudiofile support AMR.

Tested on amd64 and i386.

Issues:

(1)
It comes with the Apache License 2.0; I am not sure
what that means for the PERMIT_* variables; I asked
upstream, but someone here surely knows.

(2)
With USE_LIBTOOL=Yes, the build fails in a strange way (see below).
Without USE_LIBTOOL, everything goes fine. But I don't know enough
about libtool to spot the exact problem (see my guess below, though).

Comments?

Jan


# make
===  Configuring for opencore-amr-0.1.2
configure: WARNING: unrecognized options: --disable-silent-rules
configure: loading site script /usr/ports/infrastructure/db/config.site
checking for a BSD-compatible install... /usr/bin/install -c -o root -g bin
[configures fine]

===  Building for opencore-amr-0.1.2
Making all in amrnb
[builds fine, until]

c++ -shared -fPIC -DPIC -o .libs/libopencore-amrnb.so.0.2 -I../oscl 
-I../opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/src 
-I../opencore/codecs_v2/audio/gsm_amr/amr_nb/common/include 
-I../opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/include 
-I../opencore/codecs_v2/audio/gsm_amr/common/dec/include 
-I../opencore/codecs_v2/audio/gsm_amr/amr_nb/enc/src -x c -std=c99 -O2 -pipe 
.libs/wrapper.o .libs/agc.o .libs/amrdecode.o .libs/a_refl.o .libs/b_cn_cod.o 
.libs/bgnscd.o .libs/c_g_aver.o .libs/d1035pf.o .libs/d2_11pf.o .libs/d2_9pf.o 
.libs/d3_14pf.o .libs/d4_17pf.o .libs/d8_31pf.o .libs/dec_amr.o 
.libs/dec_gain.o .libs/dec_input_format_tab.o .libs/dec_lag3.o .libs/dec_lag6.o 
.libs/d_gain_c.o .libs/d_gain_p.o .libs/d_plsf_3.o .libs/d_plsf_5.o 
.libs/d_plsf.o .libs/dtx_dec.o .libs/ec_gains.o .libs/ex_ctrl.o 
.libs/if2_to_ets.o .libs/int_lsf.o .libs/lsp_avg.o .libs/ph_disp.o 
.libs/post_pro.o .libs/preemph.o .libs/pstfilt.o .libs/qgain475_tab.o 
.libs/sp_dec.o .libs/wmf_to_ets.o .libs/amrencode.o .libs/autocorr.o 
.libs/c1035pf.o .libs/c2_11pf.o .libs/c2_9pf.o .libs/c3_14pf.o .libs/c4_17pf.o 
.libs/c8_31pf.o .libs/calc_cor.o .libs/calc_en.o .libs/cbsearch.o 
.libs/cl_ltp.o .libs/cod_amr.o .libs/convolve.o .libs/cor_h.o .libs/cor_h_x2.o 
.libs/cor_h_x.o .libs/corrwght_tab.o .libs/div_32.o .libs/dtx_enc.o 
.libs/enc_lag3.o .libs/enc_lag6.o .libs/enc_output_format_tab.o 
.libs/ets_to_if2.o .libs/ets_to_wmf.o .libs/g_adapt.o .libs/gain_q.o 
.libs/g_code.o .libs/g_pitch.o .libs/hp_max.o .libs/inter_36.o 
.libs/inter_36_tab.o .libs/l_abs.o .libs/lag_wind.o .libs/lag_wind_tab.o 
.libs/l_comp.o .libs/levinson.o .libs/l_extract.o .libs/lflg_upd.o 
.libs/l_negate.o .libs/lpc.o .libs/ol_ltp.o .libs/pitch_fr.o .libs/pitch_ol.o 
.libs/p_ol_wgh.o .libs/pre_big.o .libs/pre_proc.o .libs/prm2bits.o 
.libs/qgain475.o .libs/qgain795.o .libs/q_gain_c.o .libs/q_gain_p.o 
.libs/qua_gain.o .libs/s10_8pf.o .libs/set_sign.o .libs/sid_sync.o 
.libs/sp_enc.o .libs/spreproc.o .libs/spstproc.o .libs/ton_stab.o .libs/vad1.o 
.libs/add.o .libs/az_lsp.o .libs/bitno_tab.o .libs/bitreorder_tab.o 
.libs/bytesused.o .libs/c2_9pf_tab.o .libs/div_s.o .libs/extract_h.o 
.libs/extract_l.o .libs/gains_tbl.o .libs/gc_pred.o .libs/get_const_tbls.o 
.libs/gmed_n.o .libs/gray_tbl.o .libs/grid_tbl.o .libs/int_lpc.o 
.libs/inv_sqrt.o .libs/inv_sqrt_tbl.o .libs/l_deposit_h.o .libs/l_deposit_l.o 
.libs/log2.o .libs/log2_norm.o .libs/log2_tbl.o .libs/lsfwt.o .libs/l_shr_r.o 
.libs/lsp_az.o .libs/lsp.o .libs/lsp_lsf.o .libs/lsp_lsf_tbl.o .libs/lsp_tab.o 
.libs/mult_r.o .libs/negate.o .libs/norm_l.o .libs/norm_s.o 
.libs/overflow_tbl.o .libs/ph_disp_tab.o .libs/pow2.o .libs/pow2_tbl.o 
.libs/pred_lt.o .libs/q_plsf_3.o .libs/q_plsf_3_tbl.o .libs/q_plsf_5.o 
.libs/q_plsf_5_tbl.o .libs/q_plsf.o .libs/qua_gain_tbl.o .libs/reorder.o 
.libs/residu.o .libs/round.o .libs/set_zero.o .libs/shr.o .libs/shr_r.o 
.libs/sqrt_l.o .libs/sqrt_l_tbl.o .libs/sub.o .libs/syn_filt.o .libs/weight_a.o 
.libs/window_tab.o -L.libs -lm
.libs/wrapper.o:1: error: stray '\177' in program
.libs/wrapper.o:1: error: stray '\2' in program
.libs/wrapper.o:1: error: stray '\1' in program
.libs/wrapper.o:1: error: stray '\1' in program

- and similarly for every *.o file entioned in the above line;
there seems to be an error message for almost every char on
almost evry 'line' of these files.

.libs/agc.o:1: error: stray '\177' in program
.libs/agc.o:1: error: stray '\2' in program
.libs/agc.o:1: error: stray '\1' in program
.libs/agc.o:1: error: stray '\1' in program

... etc ...

.libs/window_tab.o:54: error: stray '\340' in program
.libs/window_tab.o:54: error: stray '\1' in program
.libs/window_tab.o:54:1326: warning: null character(s) ignored
.libs/window_tab.o:54:1347: warning: null character(s)