Most of user data unregistered SEIs are privated data which defined by user/
encoder. currently, the user data unregistered SEIs found in input are forwarded
as side-data to encoders directly, it'll cause the reencoded output including some
useless UDU SEIs.
I prefer to add one option to enable/disable it and default is off after I saw
the patch by Andreas Rheinhardt:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/AM7PR03MB66607C2DB65E1AD49D975CF18F7B9@AM7PR03MB6660.eurprd03.prod.outlook.com/
How to test by cli:
ffmpeg -y -f lavfi -i testsrc -c:v libx264 -frames:v 1 a.ts
ffmpeg -y -i a.ts -c:v libx264 -udu_sei 1 b.ts
ffmpeg -y -i a.ts -c:v libx264 -udu_sei 0 c.ts
# check the user data unregistered SEIs, you'll see two UDU SEIs for b.ts.
# and mediainfo will show with wrong encoding setting info
ffmpeg -i b.ts -vf showinfo -f null -
ffmpeg -i c.ts -vf showinfo -f null -
This fixes tickets #9500 and #9557.
Reviewed-by: "zhilizhao(赵志立)" <quinkblack@foxmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The check here is meant to check for whether avcintra-class option
(default value -1) has been set; yet it checks for the x264_param_t
value where 0 is the default value (treated as "no avcintra-mode"
by x264). This meant that in-band extradata has been added unnecessarily
when using global headers; furthermore, the first output packet
had two x264 SEIs.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x264.h: "the payloads of all output NALs are guaranteed to be
sequential in memory." Therefore we can omit the loop.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MISB ST 0604 and ST 2101 require user data unregistered SEI messages
(precision timestamps and sensor identifiers) to be included. That
currently isn't supported for libx264. This patch adds support
for user data unregistered SEI messages in accordance with ISO/IEC
14496-10:2020(E) section D.1.7 (syntax) and D.2.7 (semantics).
This code is based on a similar change for libx265 (commit
1f58503013).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
By default the x264 full range flag is set to -1. By not setting
it to something else, we can let libx264 handle the RGB case.
Additionally, change the preference order to user-specified range
first, and then any fall-back logic left for the YUVJ pix_fmts.
Fixes the capture part of #9374
We already require X264_BUILD >= 118, which includes an unconditional
definition of X264_CSP_BGR in itself, thus making this check
effectively always true.
Here the packet size is known before allocating the packet because
the encoder provides said information (and works with internal buffers
itself), so one can use this information to avoid the implicit use of
another intermediate buffer for the packet data; and by switching to
ff_get_encode_buffer() one can also allow user-supplied buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodecContext.extradata is freed generically by libavcodec for
encoders, so it is unnecessary for an encoder to do it on its own.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in 40cf1bbacc.
(The currently disabled filter vf_mcdeint and vf_uspp were users of
this field; they have not been changed, so that whoever wants to fix
them can see the state of these filters when they were disabled.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This cap is currently used to mark multithreading-capable codecs that
wrap external libraries with their own multithreading code. The name is
highly confusing for our API users, since libavcodec ALWAYS handles
thread_count=0 (see commit message in previous commit). Therefore rename
the cap and update its documentation to make its meaning clear.
The old name is kept deprecated until next+1 major bump.
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9 to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread_count=0 itself or pass the zero directly to the
codec implementation. Within this meaning, it is clearly supposed to be
an internal cap rather than a public one, since from the viewpoint of a
libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
in the generic code or within the codec internals is not a meaningful
difference for the caller.
External aspects of this flag will be dealt with in the following
commit.
x264 versions >= 153 can support multiple bitdepths; they also don't
export x264_bit_depth any more. The actual check whether a bitdepth
is supported is therefore performed at runtime in x264_encoder_open.
Ergo it is unnecessary to use init_static_data for these versions:
One can already set ff_libx264_encoder.pix_fmts to the value that
X264_init_static always sets it to.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The default for the chromaoffset field in AVCodecContext
is zero, which until now always ended up overriding the
AVOption-set value, thus leading to the AVOption not working.
Additionally, the previous usage prevented the usage of
negative values, while both the variable as well as x264's
API would successfully handle such.
Thus, the default value of the AVOption is changed to match
the default of x264 (and what is currently the default for
the AVCodecContext chromaoffset field), and the checks are
changed to check for nonzero values.
This way:
1. the library default is still utilized if the value is zero.
2. both negative and positive values are correctly passed to
x264.
For historical context, this was initially similarly
implemented in 5764d38173, and
then b340bd8a58 broke the
value.
Partially reverts commit b340bd8a58.
Signed-off-by: Takio Yamaoka <y.takio@gmail.com>
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 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>
