x264_encoder_encode can return 0 with nnal 0. As a result, encode_nals will
return 0. In this condition, it's better to return 0 immediately to avoid
the following unneeded pict_type and flags setting.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").
However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.
Since libx264 has correctly parsed the level to int
(x4->params.i_level_idc), we should rely on this value instead of
attempting to parse the level string on our own.
Signed-off-by: Josh Brewster <josh.brewster@protonmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>
Fix the quantisation offset - use the whole range, and don't change the
offset size based on bit depth.
Iterate the list in reverse order. The first region in the list is the one
that applies in the case of overlapping regions.
perfer avctx->framerate first than use avctx->time_base when setting
the frame rate to encoder. 1/time_base is not the average frame rate
if the frame rate is not constant. In this case, we need to setting
avctx->framerate and avctx->time_base both, but avctx->framerate not
equal to 1/(avctx->time_base).
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This patch just enables the path from ffmpeg to libx264,
the more encoders can be added later.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
libx264 does have a field for opaque data to pass along with frames
through the encoder, but it is a pointer, while the libavcodec
reordered_opaque field is an int64_t. Therefore, allocate an array
within the libx264 wrapper, where reordered_opaque values in flight
are stored, and pass a pointer to this array to libx264.
Update the public libavcodec documentation for the AVCodecContext
field to explain this usage, and add a codec capability that allows
detecting whether an encoder handles this field.
Signed-off-by: Martin Storsjö <martin@martin.st>
libx264 does have a field for opaque data to pass along with frames
through the encoder, but it is a pointer, while the libavcodec
reordered_opaque field is an int64_t. Therefore, allocate an array
within the libx264 wrapper, where reordered_opaque values in flight
are stored, and pass a pointer to this array to libx264.
Update the public libavcodec documentation for the AVCodecContext
field to explain this usage, and add a codec capability that allows
detecting whether an encoder handles this field.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
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>
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 47687a2f8a.
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>
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>
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>
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>
James Almer
Jun Zhao
Limin Wang
Josh Brewster
Marton Balint
Carl Eugen Hoyos
Guo, Yejun
Mark Thompson
Martin Storsjö
Luca Barbato
wm4
Vittorio Giovara
Timo Rothenpieler
Carl Eugen Hoyos
Sasi Inguva
Michael Niedermayer
Andrey Turkin
Derek Buitenhuis