This makes it clear they don't modify the state, which is a useful
 indicator of what is safe to call from the application decode
 callback.

Otherwise we would have failed to open the stream.

This is a little easier to read, and allows us to save some
 subtractions and a comparison.

The increasingly-inaccurately named op_shaped_dither16() can serve
 this role instead, without much additional complexity (perhaps
 less, once you consider the required shuffling around of the
 function parameters).

This is to correspond to the feature in opus-tools's opusdec.
opusdec itself probably won't be able to use it, because it still
 wants to do dithering after resampling, but the motivation for the
 feature is the same.

Previously I'd said this would require a large stack buffer, which
 was true if you simply wanted to re-use the existing
 op_short2float_filter() and floating-point op_stereo_filter().
But the latter is not normally compiled for fixed-point anyway, so
 we can instead write new code that doesn't need the stack buffer
 without harming anything.

These were unlikely when I originally expected applications to
 normally provide a decode buffer in the right format of sufficient
 size.
However, the decode filter API works by asking to decode into a
 0-byte buffer, which will trigger both of these tests on every
 packet.
Since this is how three of the four decoding APIs are implemented,
 this is not really that unlikely anymore.

This makes op_fetch_and_process_page() always try to fetch another
 page, like it used to (and like its name implies).
There was only one place where we needed the early return for
 unprocessed packets, and getting rid of that actually simplifies
 the logic there (replacing a conditional continue with an
 unconditional one in a slightly different location).

This is needed to allow advanced usage, like that of opusdec in
 opus-tools, which can simulate packet loss or save the range coder
 state for decoder verification.
It could also be used in a pinch to use libopusfile for access to
 the raw Ogg packets, though this is somewhat of a hack.

Also refactor the other tag functions to centralize the memory
 allocation logic, plus a few other minor cleanups.

It seems somewhat silly to have to write your own strcasecmp to
 satisfy the usage pattern found in opusfile_example: scanning the
 whole tags list and handling certain tags specially (as opposed to
 searching for specific tags, as opus_tags_query() does).
Given that we were already using an equivalent function internally
 to implement opus_tags_query, just expose it directly.

OP_INT32_MIN and OP_INT32_MAX were added in commit 97917914.
This fixes at least one bug, since one of the (extremely unlikely)
 overflow checks had an extra F in it.

Mostly minor stuff.

This allows the application to report details about the server for
 HTTP[S] streams.
For all HTTP[S], this includes the server software, content-type,
 and whether or not it's using HTTPS.
For live streams, it also includes the station name, description,
 genre, homepage, nominal bitrate, and whether or not it's publicly
 listed.

This was treating every unknown header as a Server header.
Good thing this was last!
The only damage was that we might have enabled pipelining even on
 known-bad servers.

I guess no one was using these.
Clearly we need to test this more often, but this is a pain without
 a reliable public proxy, or a local proxy server setup.

These were only non-static because of oversight.

Finally managed to cross-compile a shared version of openssl
so I can use the autotools opusfile build.

We've added opus_picture_tag.

This lets us pick up runtime library path changes when the project
files are updated to newer versions on Visual Studio. This fixes
a link error with VS2012, but I still get one from VS2010.

Windows still doesn't support tar.gz out of the box. If we're
bothering with project files we might as well make it easy
to get the source releases.

Surprisingly, the actual initial value of this variable is
 irrelevant, since we always insert 24 bits of data into and then
 read only those bits out.
However, fixing this still removes undefined behavior and removes
 extraneous register dependencies.

- Reject 'not a character' values 0xFFFE and 0xFFFF.
- Remove some unnecessary string length checks.

This makes it easier for applications to support album art.
This is still relatively untested.

Incremental linking fails on my unpatched VS2010 compiler
with "failure during conversion to COFF: file invalid or corrupt".
Other than testing both configurations there's no particular
reason to use the option here.

This satisfies the Makefile's dependency on itself when buiding
in a parallel directory, like I use for the mingw builds, without
having to 'touch Makefile' as a work-around.

We've been able to differentiate between a read error and EOF since
 e2d7b266.

gcp authored 11 years ago and Timothy B. Terriberry committed 11 years ago

This is a big squashed commit of Garf's add_msvc_projects branch.
It currently does not include HTTP[S] support, as no one has sat
 down and worked out the best way to link against OpenSSL.

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

Previously we used _fseeki64() and _ftelli64() for 64-bit file
 access on Windows, but this requires MSVCRT80 (which requires MSVC
 2005 and is not shipped on XP by default).
Reimplement these functions using the C89 fgetpos() and fsetpos(),
 relying on the MSVCRT/minw32-specific definition of fpos_t.

As requested here:
http://www.hydrogenaudio.org/forums/index.php?showtopic=101817