Heavily based upon ff_add_bytes by Christophe Gisquet.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>

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

Also replace the last two usages of avpriv_float_dsp_init with
avpriv_float_dsp_alloc.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

It was replaced by avpriv_ac3_parse_header2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

These headers contain functions supposed to be public.

libavutil/des.h:
 av_des_alloc
 av_des_crypt
 av_des_init
 av_des_mac
libavutil/rc4.h:
 av_rc4_alloc
 av_rc4_crypt
 av_rc4_init
libavutil/tree.h
 av_tree_destroy
 av_tree_enumerate
 av_tree_find
 av_tree_insert
 av_tree_node_alloc
 av_tree_node_size
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This reverts commit 628e6d01 and uses
a better fix.

Before:
4483 decicycles in get_pixels_8x4_sym,  131032 runs,     40 skips

After:
2569 decicycles in get_pixels_8x4_sym,  131054 runs,     18 skips

The parser only reads the dca core sample rate, which is limited to a
maximum of 48000 Hz, while X96 and HD extensions can increase the sample
rate up to 192000 Hz.

This change prevents the parser and decoder fighting over the sample rate,
potentially confusing user applications. This also fixes sample rate
display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.

Fixes ticket #4397

Commit 2b3e9bbf caused problems for a
certain API user:

https://code.google.com/p/chromium/issues/detail?id=537725
https://code.google.com/p/chromium/issues/detail?id=542032

The problem seems rather arbitrary, because if there's junk, anything
can happen. In this case, the imperfect junk skipping just caused it to
read different junk, from what I can see.

We can improve the accuracy of junk detection by a lot by checking if 2
consecutive frames use the same configuration. While in theory it might
be completely fine for the 1st frame to have a different format than the
2nd frame, it's exceedingly unlikely, and I can't think of a legitimate
use-case.

This is approximately the same mpg123 does for junk skipping. The
set of compared header bits is the same as the libavcodec mp3 parser
uses for similar purposes.

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

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

This is how the other perl scripts in git call perl
Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It is done this way in huffyuvdsp as well.

That's where all yasm initiation steps are. Also removes the overlap
between the two files.

This function does not exist.

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

treat this the same as an over-sized superframe packet to break out of
the parser loop and allow the decoder to fail.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Zern <jzern@google.com>

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

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

Example:

% ./ffmpeg -h encoder=aac
  -aac_coder         <int>        E...A... Coding algorithm (from -1 to 3) (default twoloop)
     faac                         E...A... FAAC-inspired method
     anmr                         E...A... ANMR method
     twoloop                      E...A... Two loop searching method
     fast                         E...A... Constant quantizer
[...]

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>