Hi,
I'm looking for a way to change the default bitrate for Opus. Can someone please tell me which files need to be edited in the source to compile an executable with the new default values?
My intention is to raise them (64kbps mono / 96kbps coupled) "just to be sure" as I'm about to batch encode the audio tracks of my movie collection since I need to remux them anyway. I've been using -V 91 with the Apple encoder (QAAC) and it gives somewhat larger bitrates than Opus at default values.
opusenc.c
/*Lower default rate for sampling rates [8000-44100) by a factor of (rate+16k)/(64k)*/
bitrate=((64000*header.nb_streams+32000*header.nb_coupled)*
(IMIN(48,IMAX(8,((rate<44100?rate:48000)+1000)/1000))+16)+32)>>6;
This seems like the bit that sets the defaults.
Thanks, I'll try that out
Hold up a sec... You want to modify source code and recompile, but you don't want to pass a command line argument to a utility? Is this because you're dealing with both stereo and mono input?
Hold up a sec... You want to modify source code and recompile, but you don't want to pass a command line argument to a utility? Is this because you're dealing with both stereo and mono input?
That is my problem - I'm dealing with material ranging from mono to 5.1 channels.
I've not yet succeeded in compiling Opus as it requires ogg. I have put libogg-1.3.2 in the include folder of my MSYS installation but no luck. Googling things doesn't reveal anything useful to me since I'm much of a beginner what comes to compiling stuff.
If you don't know how to compile a program, you may be biting off more than you can chew to modify it. Still, there's always a time to learn
libogg-1.3.2 sounds like the executable portion of the library to me. The include files for compiling against the library would be a separate package (called something like libogg-dev in Linux), and that is what you need before you can compile opus. You might need other stuff too.
Okay, I think I see what's going on here. The reference Vorbis encoder (oggenc) uses a quality setting that scales your bitrate accordingly, but the Opus reference encoder doesn't have this.
This is definitely about learning
I did manage to install ogg (had to compile and then install, learnt something about the package stuff along the way), now it shows with pkg-config --list-all. However, configure halts because it cannot detect opus:
checking for OGG... yes
checking for OPUS... no
configure: error: Package requirements (opus >= 1.0.3) were not met:
Requested 'opus >= 1.0.3' but version of Opus is unknown
You may find new versions of Opus at http://opus-codec.org/ (http://opus-codec.org/)
pkg-config shows this:
$ pkg-config --list-all
liblzma liblzma - General purpose data compression library
libarchive libarchive - library that can create and read several streaming archi
ve formats
openssl OpenSSL - Secure Sockets Layer and cryptography libraries and tools
guile-1.8 GNU Guile - GNU's Ubiquitous Intelligent Language for Extension
libcrypto OpenSSL-libcrypto - OpenSSL cryptography library
opus Opus - Opus IETF audio codec (floating-point build)
libxml-2.0 libXML - libXML library version2.
zlib zlib - zlib compression library
autoopts AutoOpts - A semi-automated generated/library option parser
minizip minizip - Minizip zip file manipulation library
ogg ogg - ogg is a library for manipulating ogg bitstreams
libssl OpenSSL - Secure Sockets Layer and cryptography libraries
I'm getting there but cannot find my way around this.
What are you trying to compile ?
What are you trying to compile ?
Opus-tools to get opusenc.exe.
Google turns up these instructions:
http://lists.xiph.org/pipermail/opus/2014-March/002561.html (http://lists.xiph.org/pipermail/opus/2014-March/002561.html)
Same problem. When your configure says "checking for...", it means it is checking for the include headers for that library. In Linux this would be libopus-dev (NOT libopus, that is just the library itself, not the headers). Look for something similar that contains files like opus.h and opus_types.h. Then your configure will continue and you'll be able to build.
Building libogg yourself shouldn't be necessary, but the source code for it necessarily contains the headers that you need to compile against that library so it gets you where you need to be.
The include files for compiling against the library would be a separate package (called something like libogg-dev in Linux)
In Linux this would be libopus-dev (NOT libopus, that is just the library itself, not the headers).
For the sake of accuracy.
Splitting headers is just a packaging policy enforced by some distributions. It has nothing to do with (GNU/)Linux.
Other distributions do their packaging sanely (and as upstream intended). They either never split headers. Or only split them in extreme cases (Boost and its huge headers come to mind).
Other distributions do their packaging sanely (and as upstream intended). They either never split headers. Or only split them in extreme cases (Boost and its huge headers come to mind).
Sanely? What's sane about installing thousands of files only needed for development on every non-developer machine, wasting space, traffic ...
And either do the splitting consistently or let it be.
(For the same reasons it can make sense to split architecture independent data, docs and large debug symbols ...)
Same problem. When your configure says "checking for...", it means it is checking for the include headers for that library. In Linux this would be libopus-dev (NOT libopus, that is just the library itself, not the headers). Look for something similar that contains files like opus.h and opus_types.h. Then your configure will continue and you'll be able to build.
Building libogg yourself shouldn't be necessary, but the source code for it necessarily contains the headers that you need to compile against that library so it gets you where you need to be.
Is there a way to check where it is looking for those? The files are there under my MSYS folder (in c:\utils\msys\include\opus to be exact) as that is where they were installed when I built opus and that is where ogg is as well but that one is found by the configure script. I have tried --PREFIX=c:/utils/msys as a parameter in configure but that doesn't help.
configure: error: Package requirements (opus >= 1.0.3) were not met:
Requested 'opus >= 1.0.3' but version of Opus is unknown
These lines clearly show where the configure script failed.
You need opus >= 1.0.3 but "pkg-config --version opus" didn't return a sane version number for some reason
(The result of pkg-config --list-all show that you actually have opus installed).
You can examine $prefix/lib/pkgconfig/opus.pc, but probably you have to re-install opus (maybe by building opus yourself).
Thanks, I'll check that. I did build and install opus beforehand but maybe something went wrong there.
I got one step forward before I got off to work; I took a look at the config.log and noticed some empty environment variables related to paths to the various required packages. I set the Opus-related variables according to what the paths are in my MSYS installation - which configure should automatically pick as it already picks Ogg - and then got past that one. The next error was that FLAC is not installed, which is correct as I had not yet done that.
So maybe it is just that the Opus version is not returned or parsed correctly?
I had the same problem on linux when I installed opus from git.
Find the opus pkgconfig file itself. In linux it's called opus.pc and located in a folder named pkgconfig.
In that file there's a line starting "Version:" . Yours will say "unknown" . Change it to "1.1" .
I had the same problem on linux when I installed opus from git.
Find the opus pkgconfig file itself. In linux it's called opus.pc and located in a folder named pkgconfig.
In that file there's a line starting "Version:" . Yours will say "unknown" . Change it to "1.1" .
That's it! Incredibly frustrating and silly, but that's it
I ran into the next problem while trying to make, but I'll try to figure it out myself first. I have a feeling that my MSYS installation is not proper in some way. Actually I didn't install it but got it from XhmikosR's site - works fine for x264 or x265 though.
The next issue proved to be bigger than me, so I need to bother you again.
Configure runs fine now, but make fails: I get the dreaded error "conflicting types for 'ssize_t'". I don't have the exact error message here right now, but it seemed that in some .h it was declared as int and in some as long.
Is this a problem with the sources or my MSYS environment? I'm afraid this might be off topic here but since we're talking about compiling, and maybe it helps someone else too..
I do not understand your problems.
MSYS on Windows? Just grab pkg-config from gtk.org (http://win32builder.gnome.org/packages/3.6/pkg-config_0.28-1_win32.zip), extract to /usr/local
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig; tar xf opus-1.1.tar.gz; cd opus-1.1; ./configure; make; make check; make install
Do the same for opus-tools-0.1.9. If it requires other libraries then either get them and do the same as above or disable them with ./configure --without-flac for example. See the last page of ./configure --help
Worked for me in a few minutes.
I'm not able to make it work.
Here's what I've done:
(Downloaded XhmikosR's MSYS package from http://xhmikosr.1f0.de/tools/msys/) (http://xhmikosr.1f0.de/tools/msys/))
1) Unpack MSYS to c:\ so it's at c:\msys
2) Run pi.bat and entered path to MinGW as c:/msys/mingw
3) Run msys.bat
4) cd /c/sources/libogg-1.3.2
5) ./configure --prefix=/c/msys; make; make install
6) cd ..
7) cd opus-1.1.1-beta
8) ./configure --prefix=/c/msys; make; make install
6) cd ..
7) cd opus-tools-0.1.9
8) ./configure --prefix=/c/msys --without-flac; make; make install
After that last make statement (not make install), I get a bunch of errors regarding some conflicting types.
I added the config.log here since it will probably show what the real problem is. There are quite a few warnings there but they are not shown in the console during configure.
I'm probably doing something wrong but I'm too confused to know what at this point.
[attachment=8162:config.zip]
If you are seriously trying to cross-compile using mingw, you're gonna have a bad time.
(Downloaded XhmikosR's MSYS package from http://xhmikosr.1f0.de/tools/msys/) (http://xhmikosr.1f0.de/tools/msys/))
Why?
But anyway, even this version of msys works fine here.
Where did you get your mingw? What's your gcc version? What does
make check
tell you for opus-1.1?
1) Unpack MSYS to c:\ so it's at c:\msys
2) Run pi.bat and entered path to MinGW as c:/msys/mingw
Usually it's the other way around, i.e. msys is under mingw, but it shouldn't matter since msys.bat mounts the mingw path.
5) ./configure --prefix=/c/msys; make; make install
Why the weird prefix? Do you really want to install stuff into the msys root? At least use /usr, but I'd stick with what I posted above.
Why don't you export the PKG_CONFIG_PATH if you use a nonstandard location?
After that last make statement (not make install), I get a bunch of errors regarding some conflicting types.
edit: fix your pkg-config path problems and you should be fine
If you are seriously trying to cross-compile using mingw, you're gonna have a bad time.
There is no cross-compilation here, but even so it does work very well. I've "recently" cross-compiled 64-bit mpv (http://mpv.io) a couple of times successfully.
I get the dreaded error "conflicting types for 'ssize_t'". I don't have the exact error message here right now, but it seemed that in some .h it was declared as int and in some as long.
Is this a problem with the sources or my MSYS environment?
Then why don't you post the error message? GCC should have provided you with enough information.
(Downloaded XhmikosR's MSYS package from http://xhmikosr.1f0.de/tools/msys/) (http://xhmikosr.1f0.de/tools/msys/))
Why?
Because it has a pre-compiled toolchain, and has been working fine for compiling x264 and x265.
Where did you get your mingw? What's your gcc version? What does make check
tell you for opus-1.1?
MinGW is included in that package, gcc is version 4.9.2. Make check passes all items for opus-1.1.1-beta.
1) Unpack MSYS to c:\ so it's at c:\msys
2) Run pi.bat and entered path to MinGW as c:/msys/mingw
Usually it's the other way around, i.e. msys is under mingw, but it shouldn't matter since msys.bat mounts the mingw path.
That's how it is in the package, I've not changed it in any way.
5) ./configure --prefix=/c/msys; make; make install
Why the weird prefix? Do you really want to install stuff into the msys root? At least use /usr, but I'd stick with what I posted above.
Why don't you export the PKG_CONFIG_PATH if you use a nonstandard location?
If I install stuff without setting that prefix, they are installed under c:\msys\local. In the package, everything is pre-installed under the msys root. I can move things to c:\msys\local and set PKG_CONFIG_PATH to what you suggested (and test that pkg-config --list-all finds everything) but I still get the errors during make.
Then why don't you post the error message? GCC should have provided you with enough information.
Dang, I though the config.log included those.. Here's what make prints out:
$ make
make all-recursive
make[1]: Entering directory `/c/sources/opus-tools-0.1.9'
Making all in .
make[2]: Entering directory `/c/sources/opus-tools-0.1.9'
CC src/opusenc-opus_header.o
In file included from C:/MSYS/local/include/ogg/os_types.h:38:0,
from C:/MSYS/local/include/ogg/ogg.h:25,
from src/opus_header.h:31,
from src/opus_header.c:32:
C:/MSYS/local/include/sys/types.h:137:14: error: conflicting types for 'ssize_t'
typedef long ssize_t;
^
In file included from c:\msys\mingw\i686-w64-mingw32\include\crtdefs.h:10:0,
from c:\msys\mingw\i686-w64-mingw32\include\stddef.h:7,
from c:\msys\mingw\lib\gcc\i686-w64-mingw32\4.9.2\include\stddef.h:1,
from C:/MSYS/local/include/ogg/ogg.h:24,
from src/opus_header.h:31,
from src/opus_header.c:32:
c:\msys\mingw\i686-w64-mingw32\include\_mingw.h:389:13: note: previous declaration of 'ssize_t' was here
typedef int ssize_t;
^
make[2]: *** [src/opusenc-opus_header.o] Error 1
make[2]: Leaving directory `/c/sources/opus-tools-0.1.9'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/sources/opus-tools-0.1.9'
make: *** [all] Error 2
Once again, thanks to everyone. I understand how frustrating it can sometimes be to guide a newbie (at work I often train new and existing users to use a rather complicated system)
C:/MSYS/local/include/sys/types.h:137:14: error: conflicting types for 'ssize_t'
c:\msys\mingw\i686-w64-mingw32\include\_mingw.h:389:13: note: previous declaration of 'ssize_t' was here
typedef int ssize_t;
Don't you have c:\msys\mingw\i686-w64-mingw32\include\sys\types.h ? It is the right one to be picked up when you are targeting i686-w64-mingw32. However, the compiler seems to have picked up sys/types.h from incorrect place -- maybe the one targeting msys itself , not i686-w64-mingw32.
Still, I don't understand why it is C:/MSYS/
local/include and not C:/MSYS/include. Do you happen to have an idea about that? Is it a directory that you have created yourself to install packages you have built locally? Then why sys/types.h is there?
Anyway, it's about the toolset setup and something is going wrong here. A quickest fix might be to rename C:/MSYS/local to C:/MSYS/bar or something.
Works fine for me, even with the mingw/compiler included in that package. (I didn't notice it because mingw-get usually installs MSYS within mingw, not the other way around.)
But I'm using the latest stable versions found on the websites.
I almost resolved the issue, I'll just need to do some double-checking and then post my results. I have some questions I need to verify first
I tested the operation on my Win7 laptop at work: installed the MSYS/MinGW package to C:\TEMP\MSYS and in fstab set the /mingw mount point to c:/temp/msys/mingw. The directory structure is kind of backwards like xnor mentioned, MinGW is installed under MSYS.
It seems that everything that is readily installed, is installed under the MSYS root. After installing, pkg-config --list-all will list
$ pkg-config --list-all
liblzma liblzma - General purpose data compression library
libarchive libarchive - library that can create and read several streaming archive formats
openssl OpenSSL - Secure Sockets Layer and cryptography libraries and tools
guile-1.8 GNU Guile - GNU's Ubiquitous Intelligent Language for Extension
libcrypto OpenSSL-libcrypto - OpenSSL cryptography library
zlib zlib - zlib compression library
libxml-2.0 libXML - libXML library version2.
autoopts AutoOpts - A semi-automated generated/library option parser
minizip minizip - Minizip zip file manipulation library
libssl OpenSSL - Secure Sockets Layer and cryptography libraries
If I now try - without setting a specific path to pkgconfig - to simply configure, make and install, everything goes fine and items appear in the pkg-config list until the make of opustools which fails as I've posted. Is this just a "feature" of compiling it with this particular toolset or is there something wrong with the setup?
Extracting pkgconfig to the path xnor mentioned (which didn't exist in the MSYS package) and setting the environment variable, I was able to compile all the necessary libraries and executables. During make of opustools, I did get these warnings:
$ make
make all-recursive
make[1]: Entering directory `/c/temp/sources/opus-tools-0.1.9'
Making all in .
make[2]: Entering directory `/c/temp/sources/opus-tools-0.1.9'
CC src/opusenc-opus_header.o
CC src/opusenc-opusenc.o
CC src/opusenc-picture.o
CC src/opusenc-resample.o
src/resample.c: In function 'update_filter':
src/resample.c:607:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<st->filt_len;j++)
^
src/resample.c:688:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<st->magic_samples[i];j++)
^
src/resample.c:696:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<olen-1;j++)
^
src/resample.c:699:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (;j<st->filt_len-1;j++)
^
src/resample.c:706:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<st->filt_len-1+st->magic_samples[i];j++)
^
src/resample.c: In function 'opustools_resampler_process_float':
src/resample.c:872:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c:875:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c: In function 'opustools_resampler_process_int':
src/resample.c:928:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c:935:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c:945:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<ochunk+omagic;++j)
^
CC src/opusenc-audio-in.o
CC src/opusenc-diag_range.o
CC src/opusenc-flac.o
CC src/opusenc-lpc.o
CC win32/opusenc-unicode_support.o
CCLD opusenc.exe
CC src/opusdec-opus_header.o
CC src/opusdec-wav_io.o
CC src/opusdec-wave_out.o
CC src/opusdec-opusdec.o
src/opusdec.c: In function 'main':
src/opusdec.c:891:20: warning: 'opus_serialno' may be used uninitialized in this
function [-Wmaybe-uninitialized]
fprintf(stderr,"\nError: Apparent chaining without changing
serial number (%" I64FORMAT "==%" I64FORMAT ").\n",
^
CC src/opusdec-resample.o
src/resample.c: In function 'update_filter':
src/resample.c:607:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<st->filt_len;j++)
^
src/resample.c:688:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<st->magic_samples[i];j++)
^
src/resample.c:696:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<olen-1;j++)
^
src/resample.c:699:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (;j<st->filt_len-1;j++)
^
src/resample.c:706:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<st->filt_len-1+st->magic_samples[i];j++)
^
src/resample.c: In function 'opustools_resampler_process_float':
src/resample.c:872:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c:875:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c: In function 'opustools_resampler_process_int':
src/resample.c:928:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c:935:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(j=0;j<ichunk;++j)
^
src/resample.c:945:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j=0;j<ochunk+omagic;++j)
^
CC src/opusdec-diag_range.o
CC win32/opusdec-unicode_support.o
CCLD opusdec.exe
CC src/opusinfo-opus_header.o
CC src/opusinfo-opusinfo.o
CC src/opusinfo-info_opus.o
CC src/opusinfo-picture.o
CC win32/opusinfo-unicode_support.o
CCLD opusinfo.exe
CC src/opusrtp.o
CCLD opusrtp.exe
make[2]: Leaving directory `/c/temp/sources/opus-tools-0.1.9'
make[1]: Leaving directory `/c/temp/sources/opus-tools-0.1.9'
Is this anything to worry about? My sources are always 48kHz so resampling won't be applied.
The other remaining question now is, should I recompile those pre-compiled libraries to suggested location /usr/local or can I copy them under /usr/local and edit the paths in .pc files accordingly?
The warnings can be ignored.
As for libraries, I don't think you need any of those. opus-tools requires opus and ogg, that should be it.
Everything's working smoothly now, except that the binary is quite a lot slower than the "official" build (10x vs 17.1x realtime). Is there something possibly missing, assembly optimizations are not available according to configure.
Static build, different compiler (Visual Studio), possibly some compiler optimizations enabled ...
Everything's working smoothly now, except that the binary is quite a lot slower than the "official" build (10x vs 17.1x realtime). Is there something possibly missing, assembly optimizations are not available according to configure.
You're probably missing out on SIMD optimizations.