* commit 'eda18328':
  travis: Enable OSX integration
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '79d89cf2':
  flacenc: Clamp user-supplied min/max prediction orders

  Conflicts:
      libavcodec/flacenc.c
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '4bb1070c':
  ffv1: Explicitly name the coder type

  Conflicts:
      libavcodec/ffv1.h
      libavcodec/ffv1dec.c
      libavcodec/ffv1enc.c
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

These are all no-ops.

* commit '9fd2bf09':
  hqx: correct type and size check of info_offset
  dds: disable palette flag for compressed images
  segafilm: Fix current_sample after seeking and avio_seek return type
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '62b4a6f1':
  rtmpcrypt: Provide the xtea keys in little endian format for consistency
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '588b6215':
  rtmpcrypt: Do the xtea decryption in little endian mode
  xtea: Add functions for little endian mode

  Conflicts:
      libavutil/xtea.c
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Reviewed-by: James Almer

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

This improves the mathematical behavior of hypotenuse computation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

It is known that the naive sqrt(x*x + y*y) approach for computing the
hypotenuse suffers from overflow and accuracy issues, see e.g
http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
This adds hypot support to FFmpeg, a C99 function.

On platforms without hypot, this patch does a reaonable workaround, that
although not as accurate as GNU libm, is readable and does not suffer
from the overflow issue. Improvements can be made separately.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

isnan and isinf are actually macros as per the standard. In particular,
the existing implementation has incorrect signature. Furthermore, this
results in undefined behavior for e.g double values outside float range
as per the standard.

This patch corrects the undefined behavior for all usage within FFmpeg.

Note that long double is not handled as it is not used in FFmpeg.
Furthermore, even if at some point long double gets used, it is likely
not needed to modify the macro in practice for usage in FFmpeg. See
below for analysis.

Getting long double to work strictly per the spec is significantly harder
since a long double may be an IEEE 128 bit quad (very rare), 80 bit
extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
On the other hand, any potential future usage of long double is likely
for precision (when a platform offers extra precision) and not for range, since
the range anyway varies and is not as portable as IEEE 754 single/double
precision. In such cases, the implicit cast to a double is well defined
and isinf and isnan should work as intended.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
for rationale.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This also adds a new fate test
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Doing that doesn't make sense, because the only purpose of sbr_dequant
is to process the data from read_sbr_data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

This should fix a infinite loop
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

server_attached is newly added so the demuxer knows if there is an attached server
that can update the write index. This is needed to fix a infinite loop
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Also rearranged the relevant check to reduce code duplication
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

See https://github.com/mpv-player/mpv/issues/2506

The ad-hoc pi constant has a ludicrous number of digits that offer no
value whatsoever. M_PI is more consistent and readable across the
codebase.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
for rationale.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
for rationale.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
for rationale.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
for rationale.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

See e.g https://stackoverflow.com/questions/1666353/are-typedef-and-define-the-same-in-c
for rationale.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

If videotoolbox_common_end_frame failed, then the AVFrame was returned
to the API user with the dummy buffer (in AVFrame.buf[0]) still set, and
the decode call indicating success.

These "half-set" AVFrames with dummy buffer are a videotoolbox specific
hack, because the decoder requires an allocated AVFrame for its internal
logic. Videotoolbox on the other hand allocates its frame itself
internally, and outputs it only on end_frame. At this point, the dummy
buffer is replaced with the real frame (unless decoding fails).

The replaced check should have become redundant
Found-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Found-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It is used as size argument of ff_canopus_parse_info_tag, which uses it
as size argument to bytestream2_init, which only supports sizes up to
INT_MAX.
Changing it's type to unsigned simplifies the check.
Reviewed-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

* commit '1fc94724':
  xtea: Clarify that the current API works in big endian mode
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

These are all no-op merges.

* commit '7b2211bf':
  dds: add missing newline to log messages
  dds: validate compressed source buffer size
  dds: validate source buffer size before copying
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>