It is a shortcut to set all the params using x264_param_parse,
makes simpler importing settings from other software using x264.

Can be used to set multiple key/value pairs from a string.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This is a length limited version of strstr()
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Some 3D systems overload the meaning of the field for other purposes.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

It is an arch-specific header not suitable for standalone compilation.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

It is required for building the shared H.264 code.

The code was copied from per cpu extension init function so the checks
for supported extensions was overlooked.

The sh4 optimizations are removed, because the code is
100% identical to the C code, so it is unlikely to
provide any real practical benefit.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The script can and will change.

Previously PIC was enabled as a magic workaround for binaries that
built fine, but failed to function at all.  This problem no longer
exists, possibly since the introduction of symbol versioning.

In ff_rtp_get_payload_type, the AVFormatContext is used for checking
whether the payload_type or rtpflags options are set. In rtpenc_chain,
the rtpctx struct is a newly initialized struct where no options have
been set yet, so no options can be fetched from there.

All muxers that internally chain rtp muxers have the "rtpflags" field
that allows passing such options on (which is how this worked before
8034130e), so this works just as intended.

This makes it possible to produce H263 in RFC2190 format with chained
RTP muxers.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Not sure if this actually happens, but we do the same check when
checking payload_type further above in the function, so it might
be needed.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes encoding where the idct setting originally was set to
FF_IDCT_AUTO and dsputil chose a default idct with a non-null
permutation - even if the permutation tables were updated,
dct_quantize in x86/mpegvideoenc_template.c also checked the
value of this type variable.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes crashes with muxing H263 into RTSP.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

The check `start + res < start' is broken since pointer overflow is
undefined behavior in C.  Many compilers such as gcc/clang optimize
away this check.

Use `res > end - start' instead.  Also change `res' to unsigned int
to avoid signed left-shift overflow.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

A negative `size' will bypass FFMIN().  In the subsequent memcpy() call,
`size' will be considered as a large positive value, leading to a buffer
overflow.

Change the type of `size' to unsigned int to avoid buffer overflow, and
simplify overflow checks accordingly. Also change a literal buffer
size to use sizeof, and limit the amount of data copied in another
memcpy call as well.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Sanity checks like `data + size >= data_end || data + size < data' are
broken, because `data + size < data' assumes pointer overflow, which is
undefined behavior in C.  Many compilers such as gcc/clang optimize such
checks away.

Use `size < 0 || size >= data_end - data' instead.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes sure that the restrict keyword is mapped to whatever
keyword the compiler prefers/supports. This fixes building on MSVC
(and possibly on GCC 2.x as well).
Signed-off-by: Martin Storsjö <martin@martin.st>

These are never used.

This is never used.

It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

The input is not guaranteed to be aligned.

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Also wrap usage of AVCodecContext.request_channels in FF_API_REQUEST_CHANNELS directives.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Allows users to configure the output based on what's actually decoded, rather than the full native layout.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Fixes bug 401.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

CC:libav-stable@libav.org

Fixes bug 208.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

CC:libav-stable@libav.org

Also stop storing the channel arrangement in the header info, as it's unused outside of ff_mlp_read_major_sync.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

CC:libav-stable@libav.org

This makes the aac decoder and all voice codecs independent of dsputil.

This makes wmadec/enc, twinvq and mpegaudiodec (i.e. mp2/mp3)
independent of dsputil.

Now, nellymoserenc and aacenc no longer depends on dsputil. Independent
of this patch, wmaprodec also does not depend on dsputil, so I removed
it from there also.