This is needed to pull in the define for ERROR_TIMEOUT
Signed-off-by: Dave Yeo <daveryeo@telus.net>
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

dlopen contains additional security to prevent dll hijacking compared to standard LoadLibrary.

This adds a decoder for Broderbund's sprite-based QuickTime CDToons
codec, based on the decoder I wrote for ScummVM.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>

There's just no reason not to when its so easy (albeit messy) and its also
reducing the precision of all non-power-of-two transforms that use it.

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

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes "passing argument 2 of ‘strtoul’ from incompatible pointer
type [-Wincompatible-pointer-types]" ("expected ‘char ** restrict’ but
argument is of type ‘const char **’") for GCC and "passing 'const char
**' to parameter of type 'char **' discards qualifiers in nested pointer
types [-Wincompatible-pointer-types-discards-qualifiers]" for Clang.

The cast itself is safe; it is only needed because strtoul itself is not
const-correct.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

If i is greater than 0, it is a requirement of bitstream conformance that point_y_value[ i ] is greater than point_y_value[ i - 1 ].
If i is greater than 0, it is a requirement of bitstream conformance that point_cb_value[ i ] is greater than point_cb_value[ i - 1 ].
If i is greater than 0, it is a requirement of bitstream conformance that point_cr_value[ i ] is greater than point_cr_value[ i - 1 ].
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Saves 2 additions.

It was renamed and no warning was given for undeffing a nonexisting one.

Required minimal changes to the code so made sense to implement.
FFT and MDCT tested, the output of both was properly rounded.
Fun fact: the non-power-of-two fixed-point FFT and MDCT are the fastest ever
non-power-of-two fixed-point FFT and MDCT written.
This can replace the power of two integer MDCTs in aac and ac3 if the
MIPS optimizations are ported across.
Unfortunately the ac3 encoder uses a 16-bit fixed point forward transform,
unlike the encoder which uses a 32bit inverse transform, so some modifications
might be required there.

The 3-point FFT is somewhat less accurate than it otherwise could be,
having minor rounding errors with bigger transforms. However, this
could be improved later, and the way its currently written is the way one
would write assembly for it.
Similar rounding errors can also be found throughout the power of two FFTs
as well, though those are more difficult to correct.
Despite this, the integer transforms are more than accurate enough.

FMO is not supported and fields related to FMO are not parsed, meaning
that any fields which follow will be corrupt.
Signed-off-by: James Almer <jamrial@gmail.com>

For audio packets with dts != AV_NOPTS_VALUEs the dts was converted
twice to the muxer's timebase during streamcopy, once as a normal
packet and once specifically as an audio packet. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: left shift of negative value -463
Fixes: 20542/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5688714435231744

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Compared to ad-hoc if(printed) ... code this allows the user to disable
it by adjusting the log level
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When e2_pts == INT64_MIN and e1_pts >= 0 the calculation of
e2_pts - e1_pts will overflow an int64_t.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

In order for rate control to correctly allocate bitrate to each temporal
layer, correct temporal layer id has to be set to each frame. This
commit provides the ability to set correct temporal layer id for each
frame.
Signed-off-by: James Zern <jzern@google.com>

Previously, it was always left in the automatic mode, if the option
was set to the only special (negative) value. Now there's two separate
special values for this option, -1 for automatic (metadata based)
and -2 for explicitly disabled.
Signed-off-by: Martin Storsjö <martin@martin.st>

It was disabled by default in 2dbd35b0
as it added delay, but now we compensate for the delay properly
by offsetting timestamps.
Signed-off-by: Martin Storsjö <martin@martin.st>

The delay is normally zero when the level limiter is disabled,
but if enabled, there's a small delay.
Signed-off-by: Martin Storsjö <martin@martin.st>

The AVPacket destined for a demuxer's output has already been
initialized before it reaches the demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

Even in this scenario, the frame still contains references to data that
won't be freed if the frame isn't unreferenced. And the AVFrame itself
will leak, too.

Fixes Coverity issue #1441422.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Since bae8844e the packet will always be unreferenced when a demuxer
returns an error, so that a lot of calls to av_packet_unref() in lots of
demuxers are now redundant and can be removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>