I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain an explicit
assignment of their supported color ranges, with codecs in category
4 being set to MPEG-only for safety.
It might be considered redundant to distinguish between 0 (category 5)
and MPEG+JPEG (category 3), but in doing so we effectively communicate
that we can guarantee that these tags will be encoded, which is distinct
from the situation where there are some codecs that simply don't have
tagging or implied semantics (e.g. rawvideo).
A full list of codecs follows:
JPEG range only:
- amv
- roqvideo
MPEG range only:
- asv1, asv2
- avui
- cfhd
- cljr
- dnxhd
- dvvideo
- ffv1
- flv
- h261, h263, h263p
- {h263,vp8}_v4l2m2m
- huffyuv, ffvhuff
- jpeg2000
- libopenjpeg
- libtheora
- libwebp, libwebp_anim
- libx262
- libxavs, libxavs2
- libxvid
- mpeg1video, mpeg2video
- mpeg2_qsv
- mpeg2_vaapi
- mpeg4, msmpeg4, msmpeg4v2, wmv1, wmv2
- mpeg4_omx
- prores, prores_aw, prores_ks
- rv10, rv20
- snow
- speedhq
- svq1
- tiff
- utvideo
Explicitly tagged (MPEG/JPEG):
- {av1,h264,hevc}_nvenc
- {av1,h264,hevc}_vaapi
- {av1,h264,hevc,vp8,vp9,mpeg4}_mediacodec
- {av1,h264,hevc,vp9}_qsv
- h264_amf
- {h264,hevc,prores}_videotoolbox
- libaom-av1
- libkvazaar
- libopenh264
- librav1e
- libsvtav1
- libvpx, libvpx-vp9
- libx264
- libx265
- ljpeg
- mjpeg
- vc2
Broken (encoder ignores tags):
- {av1,hevc}_amf
- {h264,hevc,mpeg4}_v4l2m2m
- h264_omx
- libxeve
- magicyuv
- {vp8,vp9,mjpeg}_vaapi
N/A:
- ayuv, yuv4, y41p, v308, v210, v410, v408 (headerless)
- pgmyuv (headerless)
- rawvideo, bitpacked (headerless)
- vnull, wrapped_avframe (pseudocodecs)
And move the choice of desired container to `flags`. This is needed to
handle differing API requirements (e.g. libx265 requires the NAL RBSP,
but CBS BSF requires the unescaped bytes).
x265 added support for alpha starting with build 210.
While doing so, x265_encoder_encode() changed its fifth arg to
an array of pointers to x265_picture. This broke building lavc/libx265.c
This patch simply unbreaks the build and maintains existing single-layer
non-alpha encoding support.
Fixes#11130
The SEI handling of libx265 is buggy and can easily lead
to memory corruption: It reuses certain buffers, but when
reusing them it presumes that it is enough for these buffers
to exist and does not check whether they are actually large
enough to hold what is intended to be stored in them.*
Our users are exposed to this because forwarding A53 CC data
is enabled by default. Change this to make it disabled
by default.
"Fixes" tickets #10411, #11052 and (presumably) #10906.
*: See https://trac.ffmpeg.org/ticket/9666#comment:1
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Newer specifications such as H.273 have, and probably will further
in the future add new values to these, so - instead of trying to update
these limits - we should simply check if the values are not set to the
value of "unspecified".
This should allow newer avutil values such as IPT-C2 or YCgCo-R
variants be passed to x265 itself, which apparently does its own
validation further down the line.
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_frame_side_data_get() has a const AVFrameSideData * const *sd
parameter; so calling it with an AVFramesSideData **sd like
AVCodecContext.decoded_side_data (or with a AVFramesSideData * const
*sd) is safe, but the conversion is not performed automatically
in C. All users of this function therefore resort to a cast.
This commit changes this: av_frame_side_data_get() is renamed
to av_frame_side_data_get_c(); furthermore, a static inline
wrapper for it name av_frame_side_data_get() is added
that accepts an AVFramesSideData * const * and converts this
to const AVFramesSideData * const * in a Wcast-qual safe way.
This also allows to remove the casts from the current users.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The latter need not be save, because av_log() expects
to get a pointer to an AVClass-enabled structure
and not only a fake object. If this function were actually
be called in the following way:
const AVClass *avcl = avctx->av_class;
handle_mdcv(&avcl, );
the AVClass's item_name would expect to point to an actual
AVCodecContext, potentially leading to a segfault.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This code uses the AVBPrint API for exactly one av_bprintf()
in a scenario in which a good upper bound for the needed
size of the buffer is available (with said upper bound being
much smaller than sizeof(AVBPrint)). So one can simply use
snprintf() instead. This also avoids the (always-false due to
the current size of the internal AVBPrint buffer) check for
whether the AVBPrint is complete.
Furthermore, the old code used AV_BPRINT_SIZE_AUTOMATIC
which implies that the AVBPrint buffer will never be
(re)allocated and yet it used av_bprint_finalize().
This has of course also been removed.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The newer of these two are the separate integers for content light
level, introduced in 3952bf3e98c76c31594529a3fe34e056d3e3e2ea ,
with X265_BUILD 75. As we already require X265_BUILD of at least
89, no further conditions are required.
Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
CC libavcodec/libx265.o
libavcodec/libx265.c: In function ‘libx265_encode_frame’:
libavcodec/libx265.c:781:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
libavcodec/libx265.c:782:1: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’
FF_DISABLE_DEPRECATION_WARNINGS
^~~
Signed-off-by: Marton Balint <cus@passwd.hu>
This is intended to be a more convenient replacement for
reordered_opaque.
Add support for it in the two encoders that offer
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE: libx264 and libx265. Other
encoders will be supported in future commits.
Current code stores a pointer to allocated data in libx265 and frees it
when the encoded packet is retrieved. This will leak if the packet is
never retrieved, e.g. if the encoder is closed without being flushed.
Restructure the code such that only indices to an array stored in our
private data are given to libx265. This ensures no allocated memory can
be lost.
x265_sei is available since X265_BUILD 88. Bump required version
to 89 to fix the regression from commit 1f58503013, and remove a
conditional compilation.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
added a new option 'a53cc' (on by default, as in libx264) for rendering
AV_FRAME_DATA_A53_CC as hevc sei payloads.
the code is a blend of the libx265.c code for writing
AV_FRAME_DATA_SEI_UNREGISTERED with the libx264.c code for writing atsc
a/53 payloads.
It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation of switching the default init-thread-safety
to a codec being init-thread-safe.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently the format listing misses the J formats completely, yet
they are marked as supported in the encoder. Thus to make the logic
support them while not explicitly listing them, make the logic
utilize chroma subsampling information in both width and height
available through the pixel format descriptor.
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This structure is no longer declared in a public header,
so using an FF-prefix is more appropriate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Unlike libx264, libx265 does not handle the chroma format check
on its own side, so in order to not write out values which are
supposed to be ignored according to the specification, we limit
the writing out of chroma sample location to 4:2:0 only.
Unlike libx264, libx265 does not have a separate "unspecified"/"auto"
default for color range, so we do always have to specify it.
Thus, we are required to handle the RGB case on the libavcodec
side to enable the correct value to be written out in in case
of RGB content with unspecified color range being received.
In other words:
1. If the user has set color range specifically, follow that.
2. If the user has not set color range specifically, set full
range by default in case of RGB and YUVJ pixel formats.
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 libx265. This patch adds support
for user data unregistered SEI messages in accordance with
ISO/IEC 23008-2:2020 Section D.2.7
The design is based on nvenc, with support finished up at
57de80673c
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Here the packet size is known before allocating the packet,
so that supporting user-supplied buffers is trivial.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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.
Gyan Doshi
Niklas Haas
Andreas Rheinhardt
Jan Ekström
James Almer
Anton Khirnov
Marton Balint
Zhao Zhili
erankor
Limin Wang
Brad Hards