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

It appears that Xbox ADPCM is same as WAV adpcm.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

Fixes: CID1322305 and CID1322304
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Avoids memleak on error
Fixes CID1322342
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Revert "Merge commit '8b830ee9'" (avconv: Do not try to configure filter outputs without streams)

FFmpeg already tests for this case in configure_output_filter() and printed a
clearer error message

example:
./ffmpeg -f lavfi -i color -f lavfi -i color -filter_complex "[1]null[x],[0][1]overlay" -f null -
before the merge / after the revert:
Filter null has a unconnected output

after the merge / before the revert:
Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination
Error configuring complex filters.
Invalid argument

This reverts commit 3e3779cd, reversing
changes made to 0b28039a.
Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>

This reduces the memory & cache need from 256 to 64 bytes
the code also seems faster with this change
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This uses Stein's binary GCD algorithm:
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
to get a roughly 4x speedup over Euclidean GCD on standard architectures
with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
At the moment, the compiler intrinsic is used on GCC and Clang due to
its easy availability.

Quick note regarding overflow: yes, subtractions on int64_t can, but the
llabs takes care of that. The llabs is also guaranteed to be safe, with
no annoying INT64_MIN business since INT64_MIN being a power of 2, is
shifted down before being sent to llabs.

The binary GCD needs ff_ctzll, an extension of ff_ctz for long long (int64_t). On
GCC, this is provided by a built-in. On Microsoft, there is a
BitScanForward64 analog of BitScanForward that should work; but I can't confirm.
Apparently it is not available on 32 bit builds; so this may or may not
work correctly. On Intel, per the documentation there is only an
intrinsic for _bit_scan_forward and people have posted on forums
regarding _bit_scan_forward64, but often their documentation is
woeful. Again, I don't have it, so I can't test.

As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
use a compiled version based on the De-Bruijn method of Leiserson et al:
http://supertech.csail.mit.edu/papers/debruijn.pdf.

Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
make fate.

aac-am00_88.err:
builtin:
714 decicycles in av_gcd,    4095 runs,      1 skips

de-bruijn:
1440 decicycles in av_gcd,    4096 runs,      0 skips

previous:
2889 decicycles in av_gcd,    4096 runs,      0 skips
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes CID1322359, CID1322358
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
3. I suspect that we want to be similar to Sox and its relevant options.

The converse is also true: improper names should not be capitalized
generally.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.

These have been observed with Clang, -fsanitize-undefined on Arch Linux,
though other configurations may also generate such temporaries.

The solution here is on lines with the Linux kernel's .gitignore:
https://github.com/torvalds/linux/blob/master/.gitignore.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.

The converse is also true: improper names should not be capitalized
generally.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

av_fifo_generic_write() does not return any error code.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

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

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

This should fix the undefined behavior reported in:
https://trac.ffmpeg.org/ticket/4727.

I can reproduce this at runtime: simply stick in an abort call in
asym_quant to check if c < 0 and run FATE. I don't know ac3 so I can't
confirm if negative coefficients are intentional, but at the moment they
clearly are according to FATE.

This resolves the undefined behavior. Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit 'c3e5c47b':
  libopenh264enc: Added max_nal_size option
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '00cc10ae':
  asfdec: do not skip padding if offset is above packet size - padding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'a8956eca':
  cabac: Make CABAC states hardcoded
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

There's not much reason to generate such a small table at runtime.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This becomes unuseful in the following commit.

This reverts commit 092d1977.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

* commit '2830bce4':
  w32pthreads: Load dynamically loaded functions on demand
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'b22693b0':
  w32pthreads: Add pthread_once emulation
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '8b830ee9':
  avconv: Do not try to configure filter outputs without streams
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'd7a5a178':
  configure: When disabling a library disable all the related components
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '58b42345':
  dcadec: reorganise context data
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '3a4d369e':
  g2m: Relax resolution change constraints
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

p1 and p2 are int32_t.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes trac #3842

the pps offset is used to locate pps in the spspps_buf; however, the
current calc method is wrong because it is the offset of the original
avctx->extradata;
when there is only one sps in the avcc; the value is correct by
coincidence, however, it will fail in avcc with multi sps
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

This fixes a warning observed on Clang 3.7:
"warning: attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes]"
and thus enables deprecation warning for the relevant struct.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This should fix the first undefined behavior reported in:
https://trac.ffmpeg.org/ticket/4727.

I can't reproduce the runtime behavior reported in the ticket, hence I
can't confirm that this actually fixes the exact issue reported in the
ticket.

Regardless, I can confirm that this is a genuine issue, and that
negative shifts can (and do) occur, fixed by this.

Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Currently only 2 profiles are evaluated because they are the only 2
with distributed test sequences.
- CID 1260: YUV 4:2:2 10 bits with block-adaptive interlace coding,
  from ticket 4876;
- CID 1270: YUV 4:4:4 10 bits (HR), 1920x839, from ticket 4581.

They were generated from the ticket sequences by running the
following kind of command-line;
ffmpeg -i $INPUT -an -sn -vcodec copy -vframes 1 -y $OUTPUT.mov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>