fedora:24 will be end-of-life soon.

opus 1.1.5
openssl 1.0.2l

There's a newer branch (openssl 1.1.x) availabe now, but the
build script needs changes to make it work. Stay on 1.0.2 for now.

Thanks to Mark Harris for the report.

The tags have two possible representations of the binary suffix
 data.
An implicit one: if comment_lengths and user_comments are NULL,
 then the length of the binary suffix data is 0 and the pointer to
 that data is also implicitly taken to be NULL.
And an explicit one: if comment_lengths and user_comments are
 non-NULL, then comment_lengths[comments] and
 user_comments[comments] contains the length and pointer to the
 binary suffix data (where "comments" is the number of user
 comments).

The implicit one allows us to initialize a tags struct without
 doing any allocations, which ensures it always succeeds.
op_tags_ensure_capacity() may upgrade the implicit representation
 to the explicit representation.
However, when doing so, it stores the implicit (0, NULL) values
 in their new explicit locations at the end of the array assuming
 the requested capacity will become the new size.
If the caller of op_tags_ensure_capacity() then fails before
 enlarging the array to that size, then comment_lengths and
 user_comments will be non-NULL, but the explicit locations for the
 binary suffix data for the _old_ size may not have been
 initialized.

In particular, in opus_tags_parse_impl(), if there was exactly one
 comment, and any of the three checks at the start of the main loop
 failed, then the explicit locations for the binary suffix data
 would remain uninitialized, and the call to opus_tags_clear() in
 the caller would attempt to free them.
For counts larger than 1, the extra line marked "Needed by
 opus_tags_clear()" will update the explicit location as the array
 grows, but with a count of 1 this line never gets a chance to run.

This patch fixes the problem by making op_tags_ensure_capacity()
 promote the implicit representation to explicit at _both_ the old
 and new array sizes.
We could have fixed up opus_tags_parse_impl() to do this instead,
 as suggested in the original bug reports, but doing it this way
 ensures that the tags are always in a valid state when
 op_tags_ensure_capacity() returns.

Thanks to the Google AutoFuzz Team for the report.

Fixes #2324
Fixes #2325

Clarify that the value returned by op_current_link() is strictly
 less than the value returned by op_link_count() for seekable
 sources.

op_raw_seek() will fail if you try to seek to a byte position
 beyond the end of the file.
However, the "end" is defined in terms of _of->end, which is
 specifically the end of the last Ogg page found in the underlying
 source (excluding any trailing non-Ogg data).
op_raw_total(_of,-1) returns the total size of the stream by using
 _of->end, but it was also subtracting the offset of the first Opus
 page in the first link.
Since there might have been other Ogg streams concurrently
 multiplexed with the first Opus stream whose BOS pages appear
 first, or there might simply be non-Ogg junk at the start, that
 left the caller with no way to determine the valid range of byte
 offsets that could be passed to op_raw_seek().

Instead, make op_raw_total() pretend the first link starts at
 offset 0, and explicitly document that it's what defines the range
 of valid values to op_raw_seek().
This is how our own seeking_example.c was using it, anyway.

Previously, when we encountered a hole (a gap in the page sequence
 numbers), we would save off all of the packets from the first page
 after the hole, but not timestamp them.
That meant when they were actually decoded, op_pcm_tell() would
 report a timestamp of 0 until reaching the last packet on that
 page.

Instead, handle holes just like a raw seek.
We reset the granule position tracking, and attempt to timestamp
 packets backwards from the end of the page.
If the first page after the hole is an EOS page, we just throw it
 away (rather than risk playing invalid samples due to incorrect
 end-trimming).
We also throw away the first 80 ms of audio after a hole, to allow
 the decoder state to reconverge.

This patch also updates the example to report the hole and
 continue decoding, rather than immediately stopping when a hole is
 encountered, in order to test the above features.

Just in case some bozo makes a chained stream with 272,389 links
 with 16 samples in each (coded at 16 Mbps, including overheads).
This avoids quadratic behavior for simple straight-through
 playback: we no longer do a linear search on each chain boundary
 or each call to op_pcm_tell().
N seeks with M chains still requires O(N*log(M)) work.

No code changes.

As of version 1.0.2, OpenSSL can finally do automatic hostname
 validation for us.
Their implementation is likely to have received much better review
 than ours, and there are other good reasons to prefer it, so use it
 when we can.

RFC 6125 says that if the host is an IP address, a subjectAltName of
 type iPAddress must (no 2119 caps) be present and must be used.
We would still fall back to checking the Common Name if no
 subjectAltName was present.

https://marc.info/?l=openssl-dev&m=139617145216047&w=2 interprets
 RFC 6125 to say that if the host is a DNS name, but the certificate
 only contains a subjectAltName of type iPAddress, then we should
 still fall back to checking the Common Name.
We would only check the Common Name if there was no subjectAltName
 of any type.

Restructure the hostname validation to check IP addresses up-front
 and fall back to checking the Common Name in the proper cases.

sezero authored 8 years ago and Timothy B. Terriberry committed 8 years ago

If, e.g. using a differently configured config_types.h with a long
vs. int conflict in the int32 typedef, this would have resulted in
a build failure.

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

eroen authored 8 years ago and Timothy B. Terriberry committed 8 years ago

This fixes a build failure from undefined references to ASN1_STRING_data in
libopusurl.so.

ASN1_STRING_data is deprecated in openssl-1.1.0. The new ASN1_STRING_get0_data
is identical, except the returned string may not be modified, which we don't
do anyway.

Also include missing asn1.h header to silence compiler warnings.

X-Gentoo-Bug: 592456
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=592456

The fedora docker images ship without the necessary metadata
to reconstruct rpm packages from installed data, so attempting
to download delta rpm packages when updating the system just
wastes time and bandwidth.

Commit d0c82543 broke builds
with --enable-assertions with error: 'tag_len' undeclared.

Fixing the simple typo in the symbol reference resolves the issue.

The file in the parent directory was renamed; change the
reference in the Makefile as well.

Latest stable release.

Build against latest stable upstream release.

Different distributions of doxygen have different default
values of HAVE_DOT setting, so we need to pick a specific
setting to avoid 'missing dot' warnings on some platforms.

Doxygen uses it to generate inclusion graphs for our various
header files, which is somewhat useful, but not essential.
We therefore enable dot if it's present (usually through
the parent graphviz package) but disable it if it's not
available, silencing the warning, but not giving uniform
results.

Chocobo1 authored 8 years ago and Timothy B. Terriberry committed 8 years ago

Adopt markdown format

Some of these pointed to real potential overflows (given arbitrary
 inputs by the calling application).
I was sad about stripping const qualifiers from the struct addrinfo
 pointers, but MSVC seems to erroneously think that an array of
 pointers to constant data is itself a pointer to constant data (or
 maybe that it is not compatible with a const void *?), and
 converting the memmove()s to for loops triggered an erroneous
 warning about out-of-bounds array accesses in gcc (but on only one
 of the two identical loops).

The dependency isn't needed in this case, and it speeds up
the test considerably.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Using a custom config.h isn't enough, since additional libs have to
be available whether OP_ENABLE_HTTP is defined or not.

Don't bother compiling OpenSSL in Appveyor in this one.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Signed-off-by: Ralph Giles <giles@thaumas.net>

Stable branch used because master is on 1.1.x which doesn't work.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Signed-off-by: Ralph Giles <giles@thaumas.net>

Signed-off-by: Ralph Giles <giles@thaumas.net>

Signed-off-by: Ralph Giles <giles@thaumas.net>

Signed-off-by: Ralph Giles <giles@thaumas.net>

It seems we have to run this on ubuntu trusty images to satisfy
the libopus-dev dependency, which currently requires sudo
(I think as proxy to trigger a non-docker image?) and is
therefore slower than vanilla container builds.

No public API changes.