No interface changes.

Not harder to read in a editor, and looks better in the web
interface.

These make for a nicer landing page for people coming from
the gitlab repo interface on the web. They parallel github
in that we can't override the git snapshots labelled as
'source' but we can link to packages.

We keep checksums of the release packages in the repo as a
redundant and trustworthy reference.

Update the build environment container to use the gitlab.xiph.org
url instead of the no-longer-available git.xiph.org.

This is faster. We still don't have good dependency tracking
among the components, but roughly:

    make
    make opusfile-0.dll
    make package

Should automate the basics of putting together a win32 binary
package. It still doesn't include documentation. See the
mingw/README for additional steps there.

Also, don't copy dll.a files. They don't seem to be necessary.

Invoking ../configure from the mingw directory would clobber
the mingw-specific Makefile, which is confusing. Instead
have the `make opusfile` target invoke the autotools build
within a subdirectory.

Download the most recent working release of openssl.
- Enable asm, since it seems to work now.
- Link ssl and crypto libraries statically, since the
  dll target seems to be broken.

The 1.0.2 series of openssl releases is no longer supported.
However, 1.1.1 and later broke the hooks we were using to
reference the Windows certificate store, so this is also
the newest release where opusurl works.

As such, this shouldn't be used in production (unless you have a
support contract for openssl!) but it's a useful reference
configuration to have in the repository.

Hopefully a replacement api will be available in openssl 3 or 4
and we can port to that for future releases.

This seems to have changed to be more like the unix build.
We'll probably need libcrypto-1_1.dll too, but I haven't
gotten to the link step yet. This fails because of api
changes between (no longer supported) 1.0.x versions
and the current stable 1.1.

This was a reference from an older build script and it no longer
necessary. Having in the Makefile just confuses things.

We had a request for 64-bit Windows binaries at some point, but
win32 is more broadly compatible. Since everything's broken,
let's concentrate on that and add rules to generate a separate
opusfile-${version}-win64 package later.

Latest release versions and checksums.

This is the current release.

The gcc runtime dll filename has changed, so the package script
is also updated.

In theory `mingw/Makefile` can build a binary release, but
it doensn't quite works and omits some niceties, so we still
need the detailed build instructions to compare with.

However, the details aren't relevent to the general release
checklist, so pretend `make -C ming package` works at that
level.

Also convert the mingw README to markdown for better
display on hosting sites.

Documentation should be copied to the website as part of the
source release process, not building win32 binaries.

https://github.com/doxygen/doxygen/issues/6456 is fixed in
Doxygen 1.8.15. Update teh release checklist to reflect this

Thanks to derf for checking this.

Specify an explicit version of the base container image for more
repeatable results. Note that this will need to be bumped periodically.

Signed-off-by: Marvin Scholz <epirat07@gmail.com>

Verify the stand-along Makefile for formatting the API documentation.

We ship a default Makefile which can be used to invoke doxygen
to format the API documentation outside of the autotools build,
which requires implementing subsitition of the appropriate
variables in Doxyfile.in.

This commit adds a missing substitution, telling doxygen to
expect `dot` from the graphviz package to be available.

Ensure test coverage for the non-autotools makefile. This is
much faster than the autotools build, but doesn't currently
support tests or a `dist` target.

The syntax of the travis-ci.org build description file makes
it tedious to add alternate build types. It's much easier with
gitlab, so it's nice to have testing outside of jenkins.

Set up a basic autotools job to run on gitlab's continuous
integration runner, so we get some feedback on commits to
that repository.

The actual guarantees we are making in op_read_native() are:
- if _pcm == NULL, then _buf_sz <= 0 (requirement on the caller),
- op_get_packet_duration() will succeed and return a positive value
   no larger than 120*48 (guaranteed by op_collect_audio_packets()
   filtering out any packets with invalid TOC sequences), and
- nchannels is a small number greater than 0 (guaranteed by the
   validation in opus_parse_head()).
However, trying to assert these things is not enough to convince
 clang to take the nsamples*nchannels>_buf_sz or
 duration*nchannels>_buf_sz branches when _pcm==NULL, so instead
 we have to be a bit more direct.

There really isn't anything that guarantees we can find timestamps
 within the bounds of the link, or within 2 billion samples of the
 target, if people resort to nasty things like swapping out all of
 the underlying file data on us at the right moment.
Reported by clang's static analysis in
 https://github.com/xiph/opusfile/issues/16

Thanks to kcgen for filing the report.

Reported by clang's static analysis in
 https://github.com/xiph/opusfile/issues/16
This would have taken about 22 TB of junk data before the first
 decoded sample to trigger, so not very likely to occur in
 practice.

Thanks to kcgen for filing the report.

Bump the base image for macOS travis builds to XCode 11.3 on
macOS 10.14. This have more up-to-date software than the
default image, which is conservative.

The downside is that this version will need to be bumped periodically.

Use the declarative support for installing packages from
homebrew on the travis-ci.org continuous integration service
macOS images, rather than conditional shell.

This also removes the `brew update` step. There's support
for that as well with the `update: true` key-value pair,
but since travis doesn't update their images often, the
base set of homebrew packages is often very out of date,
and the corresponding update step can take a very long time.

Unbreaks test builds on this service.

The Visual Studio build of the ogg library was changed
recently to build static libraries by default, and the
`_static` name suffix was removed. Reference this target
when building the ogg library debpendency from a git
checkout on the Appveyor continuous integration service.

Signed-off-by: Mark Harris <mark.hsj@gmail.com>

Recently the ogg reference library Visual Studio build was
updated to produce static libraries by default and the
`_static` filename suffix was removed.

This makes the corresponding change to the dependency
in opusfile's Visual Studio project files for the
example client executables. Linking against a new-style
ogg build is now required.

Signed-off-by: Mark Harris <mark.hsj@gmail.com>

 src/opusfile.c:3242:18: warning: implicit conversion from 'unsigned
       int' to 'float' changes value from 4294967295 to 4294967296
       [-Wimplicit-int-float-conversion]
           r=seed*OP_PRNG_GAIN;
                  ^~~~~~~~~~~~
 src/opusfile.c:3179:29: note: expanded from macro 'OP_PRNG_GAIN'
 # define OP_PRNG_GAIN (1.0F/0xFFFFFFFF)
                            ~^~~~~~~~~~

The ftime() function, introduced in V7 Unix (1979), gets the current
time in seconds and milliseconds, and time zone information.  It was
marked as a legacy interface in POSIX.1-2001, and removed altogether
from POSIX.1-2008.  The gettimeofday() function, originally from
4.1 BSD, gets the current time in seconds and microseconds, and optional
time zone information, and was marked as obsolete in POSIX.1-2008
although it was kept in the standard.  The POSIX recommended function
for getting time with sub-second resolution is clock_gettime(), which
was introduced in POSIX.1b-1993 and is now part of the base POSIX
standard; it supports multiple clocks and nanosecond resolution.
Additionally the function timespec_get() was introduced in C11 and also
supports nanosecond resolution.

To support dates beyond the year 2038, glibc and other libraries are
being updated to support 64-bit time_t even on 32-bit architectures,
requiring new implementations of interfaces that work with time.  As
part of this effort, the ftime() function was deprecated in glibc 2.31
(released February 1, 2020), a warning is now issued when building code
that uses this function, and removal is planned for a future version of
glibc (https://sourceware.org/pipermail/libc-announce/2020/000025.html).

ftime() is used in http.c to measure time intervals with millisecond
resolution.  To avoid the glibc 2.31 deprecation warning and further
issues when the function is removed entirely from glibc, clock_gettime()
is now used instead when it is available in the C library, as it is on
current Linux systems.  Prior to glibc 2.17, clock_gettime() required
linking with librt; on such systems ftime() will continue to be used, to
avoid an additional library dependency.  macOS provides clock_gettime()
starting in macOS 10.12; earlier versions will continue to use ftime().
Windows provides ftime() but not clock_gettime(), so ftime() will
continue to be used on Windows.

ftime(), gettimeofday(), and clock_gettime() with the CLOCK_REALTIME
clock get the "real time", which is subject to jumps if set by an
administrator or time service.  The CLOCK_MONOTONIC clock does not have
this problem and is more suitable for measuring time intervals.  On
Linux, the CLOCK_BOOTTIME clock measures the time since last boot and is
the same as CLOCK_MONOTONIC except that the Linux CLOCK_MONOTONIC clock
does not advance when the system is suspended.  Because it is used to
measure time intervals, CLOCK_BOOTTIME or CLOCK_MONOTONIC are used when
available, when clock_gettime() is used.  However the only clock
required by POSIX.1-2008 is CLOCK_REALTIME, so that will be used if the
other clocks are not available.

Chris Lamb authored 7 years ago and Mark Harris committed 4 years ago

Fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881788

It is possible for us to buffer multiple out-of-sequence pages with no packets
 on them before getting one that does have packets.
In this case, libogg will report each hole in the page sequence numbers
 separately.
Since we were only checking for the actual packets once after encountering a
 hole, if the total number of holes was even, we could exit
 op_fetch_and_process_page() with valid packets still in the libogg buffer.
Then, if the next page had a lot of packets, we might wind up with a total of
 more than 255 of them, overflowing our stack buffer for their durations.
That's bad.

Instead, make sure we always drain all hole reports from libogg any time we
 encounter one, to ensure we get the actual packets behind it.

Thanks to Felicia Lim for the report.

The C standard says that calling library functions (including
 memcpy) with invalid arguments (including a NULL pointer) is
 undefined behavior unless otherwise noted (which memcpy doesn't).
op_filter_read_native() invokes op_read_native() with NULL for the
 _pcm buffer, which triggers such a memcpy invocation.
Even though it should be perfectly fine in practice to pass NULL to
 memcpy when copying zero bytes, don't do it.

Thanks to a person who did not wish to be credited for the report.

The seeking functions on Windows internally dispatch to
 SetFilePointer(), whose behavior is undefined if you do not call
 it on "a file stored on a seeking device".
Check the type of file when it is opened and manually force seeks
 to fail if we do not have such a file.

Thanks to L W Anhonen for the report and Mark Harris for pointing
 out the solution used by opus-tools to avoid this problem.

When seeking using SEEK_END, the win32-specific implementation of
 op_fseek() would add the offset to the file size to get the
 absolute seek position.
However, op_mem_seek() and op_http_stream_seek() would subtract the
 offset instead.
The documentation of fseek() is not at all clear which behavior is
 correct, but I believe that the op_fseek() behavior is.

This inconsistency didn't matter for opusfile in practice, because
 we only ever use SEEK_END with an offset of 0.
However, the user can also open files with our API and use the
 resulting callbacks for their own purposes, so it would be good to
 be consistent for them.

Thanks to a person who did not wish to be credited for the report.