Signed-off-by: Kyle Swanson <k@ylo.ph>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

These functions return an error typically when the key size is an
incorrect number. AVERROR(EINVAL) is more specific than -1.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Commit 3a0a2f33 claims large performance
advantages for AV_QSORT over libc's qsort. The reason is that I suspect
that libc's qsort (at least on non LTO builds, like the typical FFmpeg config)
can't inline the comparison callback:
https://stackoverflow.com/questions/5290695/is-there-any-way-a-c-c-compiler-can-inline-a-c-callback-function.
AV_QSORT has two things going for it:
1. The guaranteed inlining of qsort itself. This yields a negligible
boost that may be ignored.
2. The more serious possibility of potentially allowing the comparison
function to be inlined - this is likely responsible for the large boosts
reported.

There is a comment explaining that this is a place that could use some
performance improvement. Thus AV_QSORT is used to achieve that.

Benchmarks deemed unnecessary due to existing claims about AV_QSORT.
Tested with FATE.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

libavutil was always built, allow its dependencies to be enabled.

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

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

When the encoder is fed with less frames than its delay, the picture list looks like { NULL, NULL, ..., frame, frame, frame }. When flushing the encoder (input frame == NULL), we need to ensure the picture list is shifted enough so that we do not return an empty packet, which would mean the encoder has finished, while it has not encoded any frame.

Before the patch, the command:
'./ffmpeg_g -loglevel debug -f lavfi -i "testsrc=d=0.01" -bf 2 -vcodec mpeg2video out.mxf' prints:

Output stream #0:0 (video): 1 frames encoded; 0 packets muxed (0 bytes);

After:

Output stream #0:0 (video): 1 frames encoded; 1 packets muxed (8058 bytes);

Relates to ticket #4817.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

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

This clarifies and adds Doxygen for ff_fmt_is_in.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

There were some errors in the calculation as well as an entire
unnecessary loop to find the gain coefficient. Merge the
two loops.
Thanks to @ubitux for the suggestions and testing.

Having it as a float didn't even allow enough precision to check
for INT_MAX/2.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Having it as a float didn't even allow enough precision to check
for INT_MAX/2.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

avcodec/aacenc: Fix "libavcodec/aacenc.c:540:13: warning: ISO C90 forbids mixed declarations and code"
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This makes it consistent with ffprobe
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes ticket #4924.
Found-by: Jaroslav Šnajdr <jsnajdr@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Marton Balint <cus@passwd.hu>

av_warn_unused_result is added to functions whose return status should
be checked. Currently does not trigger any warnings, but should be
useful for future robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

The wtv demuxer doesn't reference any functionality from asfdec or asfcrypt

The fate test command line is supposed to serve as an example. It's
nicer to explicitly state the profile rather than setting options
to force it for you.

Suggested by ubitux.
Convenient.

A value of 2048 will overflow 11 bits.

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

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

Fixes make fate V=2
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fails on some newer systems (archlinux with a modern GCC version).

Since it became the default option, in order to prevent interference
with the other tests, disable it.

In light of the recent changes to the TNS system, it has been
deemed worthy and robust enough to be turned on by default.

Changes:
 - strongly prefer dual filters to a single filter
 - less strict about using 2 filters w.r.t. energy
 - scrap the usage of threshold and spread, useless
 - use odd-shaped windows to set the filter direction
 - use 4 bits instead of 3 bits for short windows
 - simplify and reduce the main loop to a single level
 - add stricter regulations for short windows

All of this now makes the TNS implementation operate
as good as it can and it definitely shows. The frequency
thresholds are now even better defined by looking at
the spectrals and the overall sound has been improved at
the price of just a few bits that are well worth it.

It's simpler and has 2 less levels than the previous which
was practically lifted from the decoder with put_bits() instead
of get_bits().

Too much effort and work has been spent on such a simple function.
It simply refuses to work as the specifications say, the
transformation is NOT lossless and creates some crackling and
distortions.
Therefore disable it by default and add a couple of warnings to
scare people away from touching it or wasting their time the
way I did.

The decoder does this so I guess we better do that as well.
There's barely any difference between the autoregressive and
the moving average filters looking at spectrals though.

Silences warnings regarding `clCreateCommandQueue` being deprecated.

Only a very limited number of products support 2.0. Since the
replacement API (`clCreateCommandQueueWithProperties`) is only available
in 2.0, we should not update it just yet.