1. 11 May, 2020 1 commit
  2. 04 May, 2020 6 commits
  3. 02 May, 2020 6 commits
    • Mark Harris's avatar
      ae4968d1
    • Timothy B. Terriberry's avatar
      Silence scan-build false positives. · ccdef60e
      Timothy B. Terriberry authored
      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.
      ccdef60e
    • Timothy B. Terriberry's avatar
      Relax some assumptions about our seeking success. · 77121e1b
      Timothy B. Terriberry authored
      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.
      77121e1b
    • Timothy B. Terriberry's avatar
      Avoid a potential divide-by-zero. · a931e217
      Timothy B. Terriberry authored
      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.
      a931e217
    • Ralph Giles's avatar
      Update travis builds to xcode 11.3. · 9f181180
      Ralph Giles authored
      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.
      9f181180
    • Ralph Giles's avatar
      Update travis config for macOS. · f24f8e4f
      Ralph Giles authored
      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.
      f24f8e4f
  4. 01 May, 2020 2 commits
    • Ralph Giles's avatar
      Update appvayor ci for ogg library name changes. · bb2fe921
      Ralph Giles authored
      
      
      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's avatarMark Harris <mark.hsj@gmail.com>
      bb2fe921
    • Ralph Giles's avatar
      Update VS2015 projects for libogg.lib name change. · 51068512
      Ralph Giles authored
      
      
      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's avatarMark Harris <mark.hsj@gmail.com>
      51068512
  5. 30 Apr, 2020 3 commits
    • Mark Harris's avatar
      Silence clang 10 conversion warning · 8f00bcbf
      Mark Harris authored
       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)
                                  ~^~~~~~~~~~
      8f00bcbf
    • Mark Harris's avatar
      http: Fix use of deprecated function ftime() · 069dc6e8
      Mark Harris authored
      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.
      069dc6e8
    • Chris Lamb's avatar
  6. 24 Apr, 2020 1 commit
    • Timothy B. Terriberry's avatar
      Fix handling of holes again. · 85f7aa22
      Timothy B. Terriberry authored
      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.
      85f7aa22
  7. 22 Nov, 2019 1 commit
  8. 10 Dec, 2018 2 commits
    • Timothy B. Terriberry's avatar
      Fix to avoid technically undefined behavior. · 1bd200bc
      Timothy B. Terriberry authored
      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.
      1bd200bc
    • Timothy B. Terriberry's avatar
      Fix seekability detection on win32. · 24cb5eae
      Timothy B. Terriberry authored
      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.
      24cb5eae
  9. 06 Nov, 2018 1 commit
    • Timothy B. Terriberry's avatar
      Fix SEEK_END usage in seek implementations. · 34f945bb
      Timothy B. Terriberry authored
      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.
      34f945bb
  10. 01 Nov, 2018 1 commit
    • Stefan Strogin's avatar
      http: use new API with LibreSSL >=2.7.0 · d2577d7f
      Stefan Strogin authored
      
      
      LibreSSL is not yet fully API compatible with OpenSSL 1.0.2 and later,
      However many APIs from OpenSSL 1.0.2 and 1.1 are already implemented in
      LibreSSL 2.7.0 and later. Old approach works in newer LibreSSL version
      as well, but it's not nice to force deprecated functions on LibreSSL
      users.
      
      Add additional conditionals for new LibreSSL versions to use the
      available new APIs.
      Signed-off-by: Ralph Giles's avatarRalph Giles <giles@thaumas.net>
      d2577d7f
  11. 01 Oct, 2018 1 commit
    • Stefan Strogin's avatar
      http: fix compilation with LibreSSL · d59a17ec
      Stefan Strogin authored
      LibreSSL defines OPENSSL_VERSION_NUMBER to 0x20000000L, but its API is
      compatible with OpenSSL 1.0.1.
      Therefore redefine OPENSSL_VERSION_NUMBER to 0x1000115fL (1.0.1u) if
      LibreSSL is used.
      
      Fixes: #2327
      d59a17ec
  12. 19 Sep, 2018 3 commits
  13. 18 Sep, 2018 1 commit
  14. 20 Aug, 2018 3 commits
  15. 12 Jun, 2018 3 commits
  16. 08 Jan, 2018 4 commits
  17. 29 Dec, 2017 1 commit