Libx264 uses strtok which is not thread safe. Strtok is used in
x264_param_default_preset in param_apply_tune in x264/common/base.c.
Therefore the flag must be removed.

x264 fixed the issue, once the fix is pushed to stable, an #if can be added
to re-enable the flag based on X264_BUILD number.

Fixes ticket #7446.

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

It has native simultaneus 8 and 10 bit support.

This partially reverts a change in behavior introduced in 2a111c99.

Signed-off-by: James Almer <jamrial@gmail.com>

x264 now supports multibitdepth builds, with a slightly changed API to
request bitdepth during initialization.

Reviewed-by: Ricardo Constantino <wiiaboo@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

The x264_bit_depth constant has been removed in newer x264 builds.

Signed-off-by: James Almer <jamrial@gmail.com>

Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.

Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.

AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.

Based on a patch by Philip Langdale <philipl@overt.org>.

Merges Libav commit 47687a2f.

Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.

Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.

AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.

Based on a patch by Philip Langdale <philipl@overt.org>.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Replaces the now dropped global option.

Addresses ticket #6771.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Deprecated in 10/2014 and 07/2015.

Currently, it forces IDR frames for both true and false.
Not entirely sure what the original idea behind the tri-state bool
option is.

Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

This avoids enabling and building the x264rgb encoder when its actually not supported and
thus would not work

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

First check the context, then check internal option. Drop the ! typo.
Introduced in 60f0fde3.

The private options chromaoffset, sc_threshold, and noise_reduction
were set to 0 rather than -1, and were always initializing values
in libx264 rather than letting the library use its default.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

The private options chromaoffset, sc_threshold, and noise_reduction
were set to 0 rather than -1, and were always initializing values
in libx264 rather than letting the library use its default.

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

After the merge the default threshold was unconditionally overwritten

A similar fix was written by Vittorio Giovara, but i didnt see that before
i wrote this and it also doesnt apply cleanly

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

Libav, for some reason, merged this as a public API function. This will
aid in future merges.

A define is left for backwards compat, just in case some person
used it, since it is in a public header.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This option is only used by mpegvideoenc, x264, xavs, and vpx.
It is a very codec-specific option, so deprecate the global variant.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This option is only used by mpegvideoenc, x264, and xavs.
It is a very codec-specific option, so deprecate the global variant.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This option is only used by x264 and xavs.
It is a very codec-specific option, so deprecate the global variant.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

The b_frame_strategy option is only used by mpegvideoenc, qsv, x264, and
xavs, while b_sensitivity is only used by mpegvideoenc.

These are very codec-specific options, so deprecate the global variants.
Set proper limits to the maximum allowed values.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Fixes ticket #5142.

Most option values are simply unused or ignored and in practice the
majory of codecs only need to check whether to enable rle or not.

Add appropriate codec private options which better expose the allowed
features.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This patch moves the pointer validity check outside the macro,
and silences the -Waddress observed with GCC 5.2.

Note that this changes the error message slightly, from:
"bad option..." to "Error parsing option...".

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

Assumes 'GA94' format (ATSC standard)

Signed-off-by: DHE <git@dehacked.net>
Tested-by: Anshul <anshul.ffmpeg@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When forwarding the frame type information, by default x264 can
decide which kind of keyframe output, add an option to force it
to output IDR frames in to support use-cases such as preparing
the content for segmented streams formats.

x264 build 147 adds the native support for NV21.

Useful to avoid additional pixel format conversion when encoding
from a wide range of capture devices, Android among those.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Currently, when forcing an I frame, via API, or via the ffmpeg cli,
using -force_key_frames, we still let x264 decide what sort of
keyframe to user. In some cases, it is useful to be able to force
an IDR frame, e.g. for cutting streams.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

libx264 added support for NV21 input recently.

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