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

Signed-off-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Signed-off-by: Clément Bœsch <clement@stupeflix.com>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

FATE test changes because of the switch from shift to division.

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

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

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

This reverts commit 82c5f317.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Found-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This actually fixes an incorrect float literal. It is believed by
examining the precision that the literals were all pre-computed as
floats, resulting in this needless loss of precision. There is no
benefit to keeping such reduced precision:
1. These constants are used for static array computation, hence
compile-time.
2. They will be treated as doubles anyway, since f specifier was not
present.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Fixed point value remains unchanged.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This uses M_SQRT1_2, M_SQRT2 instead of the actual literals. This yields
greater precision in some places in avcodec/ac3, while fixed point
values remain unchanged.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This uses M_SQRT1_2, M_SQRT2 instead of the actual literals. Fixed point
values remain unchanged.
Patch tested with FATE on x86.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This simplifies the code.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

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

* commit '3edac01f':
  qsvenc: fix setting maxrate for VBR
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '4d8f536b':
  qsvenc: print the actual video parameters used by MSDK
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit 'f6c94457':
  mpegvideo_enc: enable rtp_mode when multiple slices are used
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit 'd80f0a4a':
  mpevideo_enc: disallow multiple slices for h261 and flv
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit 'ca489564':
  movenc: add fallback audio track tref support
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '79ae1e63':
  avcodec: Define side data type for fallback track
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '7f4ec436':
  avformat: expose av_stream_new_side_data helper

  Conflicts:
      libavformat/internal.h
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '21ab6fd0':
  lavf: document that passing valid timestamps to muxers is now mandatory
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '5c30ae1a':
  dvdsubdec: Validate the RLE offsets

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

* 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>