This makes it easier to split http.c and friends into their own
 library.
This allows distributions to ship a libopusfile with generic Opus
 parsing support, and a libopusurl with http/https support.
Keeping the latter in a separate library means that GPL
 applications don't have to link against the GPL-incompatible
 openssl, and distributions don't have to disable http support to
 allow GPL applications to use libopusfile.

If we actually have 255 packets on a page, this assertion always
 triggers, because ogg_stream_packetout doesn't fail until we ask
 for the _next_ packet.

If a stream starts with a non-zero granpos, we would subtract 80 ms
 from the target time, and then report failure when the best page
 we could find (the first page in the link) had a granpos larger
 than that.
This worked for normal streams because the subtraction would fail
 (granpos can't wrap past -1) and we checked for that.

This shouldn't be necessary, but apparently on OS X 10.4 fseeko()
 takes fpos_t instead of off_t, and thus doesn't guarantee that
 off_t is defined.

Matthew Chung authored 12 years ago and Timothy B. Terriberry committed 11 years ago

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

Ulrich Klauer authored 11 years ago and Timothy B. Terriberry committed 11 years ago

Libraries that are used internally by opusfile but are not part of
 its API should be listed in pkg-config "private" clauses.
Otherwise executables that are linked dynamically against opusfile
 will have unneeded direct dependencies (overlinking).

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

Ulrich Klauer authored 11 years ago and Timothy B. Terriberry committed 11 years ago

The library does not actually do any playback, as it does no sound
 output.

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

Ulrich Klauer authored 12 years ago and Timothy B. Terriberry committed 11 years ago

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

Ulrich Klauer authored 12 years ago and Timothy B. Terriberry committed 11 years ago

AC_SEARCH_LIBS will give a result of "none required" if the relevant
 function is available without any special libraries.
This is the case for lrintf on MinGW.
Make sure this special value isn't put verbatim into the pkg-config
 files, as it would cause the linker to search for files named
 "none" and "required", and fail.

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

I thought I had tested this before, but it was sufficiently broken
 that clearly I had not.

stdarg.h should've been inside the include guard.

- Made OP_SOFT_CLIP defined only when using floating point (libopus
   handles clipping when using the fixed-point API).
- Struct rearrangement for theoretically better packing on some
   platforms.
- Reset the state tracking channel count when re-initializing a
   decoder (and not the dither mute, because that gets reset for
   free).

When we decode using libopus's fixed-point APIs, libopus internally
 applies soft clipping prevention.
When we decode using libopus's floating-point APIs, this behavior
 is disabled.
If we're ultimately planning to output the data to the user in
 fixed-point, we need to apply the clipping prevention ourselves.

The caller can switch between the fixed/float APIs and the
 stereo/multichannel APIs on every call.
Detect this and reset the dither state to avoid potentially
 injecting noise from a very out-of-date state when switching from
 fixed to float back to fixed, or from the wrong channels when
 switching between stereo and multichannel.
Normal applications won't do this stuff, but we should be
 well-behaved if they do.

For multichannel files, this potentially caused writes beyond the
 end of the output buffer provided by the user.

Reduces cruft on 'make clean'. I've rearranged some of the
non-functional self-test targets, but not really fixed them.

The old ones gave a different warning on Apple's clang 4.2.

This is required by the xmingw build.

Just normalizing coding style.

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

OpenSSL on Windows does not pull certificates from any well-known
 location (in fact most binaries continue to use the default Unix
 path, which usually doesn't even exist).
We could ship our own set of certificates (e.g., cloned from the
 Mozilla root list), but I don't want to be responsible for
 releasing libopusfile updates when things like DigiNotar
 fiasco [1] happen.
That approach also means that we would need to load, parse, and
 keep a copy of every certificate in the system for every SSL
 session.

OpenSSL has had patches sitting in their bugtracker which load
 certificates from the Crypto API's system certificate store.
However, those patches have been sitting around for several years,
 so movement on that front in the near future seems unlikely.
We don't care about using OpenSSL's builtin CAPI engine, though, so
 we can do the same thing with less than 200 lines of code.
This puts the maintenance burden on Windows Update, which will be
 far more timely and effective than getting people to upgrade
 libopusfile, and gets us on-demand loading of just the
 certificates we need.

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=682927>

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

Apparently Vista includes more things in its Winsock implementation
 and errno.h than earlier versions of Windows.

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

This keeps differences which can be cleanly abstracted away clean
 (closesocket, ioctlsocket, getsockopt, setsockopt), and makes
 differences which cannot be cleanly abstracted explicit (SOCKET,
 INVALID_SOCKET, WSAGetLastError/WSASetLastError).
It also gets rid of wsockwrapper.[ch], since it contained just a
 single function.

This can successfully pass the seeking_example tests on
 big.chained.blob over https when built with i686-w64-mingw32 and
 run under wine.
It does not solve the certificate distribution problems with using
 OpenSSL on a real Windows system.

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

It turns out i686-pc-mingw32 does define these functions, and they
 are always available (unlike _fseeki64/_ftelli64).
This means we can build and link without requiring
 i686-w64-mingw32.
The resulting binary still doesn't run in wine for me, but that may
 be a personal problem.

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

This allows an i686-pc-mingw32 build to use getaddrinfo/
 freeaddrinfo correctly.
It's not needed for an i686-w64-mingw32 build, but it doesn't hurt
 to leave it in here.
i686-pc-mingw32 still won't work correctly, because it does not
 support fseeko/ftello, nor (unless using MSVCRT 8.0 or later)
 _fseeki64/_ftelli64.
We could define __MSVCRT_VERSION__ to 0x800 to get the latter, but
 this would require different MSVCRT versions than libogg and
 libopus are built with by default, which makes a bit of a mess.

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

Properly check for HTTP support and handle the case where it's
 disabled.
Also fixes the include paths broken by 3e7f0ddc.

Timothy B. Terriberry authored 12 years ago and Ralph Giles committed 12 years ago

The former is too generic.

Ralph Giles authored 12 years ago and Ralph Giles committed 12 years ago

Some tweak might be still needed to take care of OPENSSL_AppLink
to get https support working. In win32, user application of openssl
is required to include openssl/applink.c or something, when openssl
is compiled with OPENSSL_USE_APPLINK.

I don't know how it should be taken care of, from the library point of
view (it must be done by user of libopusfile, since openssl always
searches that function in executable module).

Posted to the hydrogenaudio format 2012 November 19.
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=97856&view=findpost&p=814582

Fixes Coverity #980717, #980718, #980719.

This lets us seek forward by small amounts (currently less than
 90 ms) by decoding forward instead of actually seeking.
This is often a good idea, since we would have to decode at least
 80 ms of pre-roll anyway.
This optimization also handles the case of seeking to what is
 already the current position cheaply.

This became relatively easy after we dropped op_pcm_seek_page()
 from the public API.
However, because others may look to libopusfile's seeking code as a
 model, we've added an OP_SMALL_FOOTPRINT #define to cordon off
 some of these complex sections of code that are deeply specific to
 libopusfile's design, ancillary to the main seeking algorithm,
 and relatively unimportant to overall seeking performance.

We should copy the minimum of the buffer size and the remaining
 bytes, not the maximum.
Fixes #1927.