The aim of this is twofold: a) Clang warns when setting a deprecated
field in a definition and because several of the widely set
AVCodec fields are deprecated, one gets several hundred warnings
from Clang for an ordinary build. Yet fortunately Clang (unlike GCC)
allows to disable deprecation warnings inside a definition, so
that one can create simple macros to set these fields that also suppress
deprecation warnings for Clang. This has already been done in
fdff1b9cbf for AVCodec.channel_layouts.
b) Using macros will allow to easily migrate these fields to internal ones.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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)
The value was being parsed as base 4, so the value "4" was invalid and
would result in ts_layering_mode being set to 0.
Signed-off-by: Aaron Thompson <dev@aaront.org>
Signed-off-by: James Zern <jzern@google.com>
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>
Also rewrite the code so that a variable that is only used
depending upon CONFIG_LIBVPX_VP9_ENCODER is not declared
outside of the #if block.
(The variable was declared with av_uninit, but it should have been
av_unused, as the former does not work for all compilers.)
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
Co-authored-by: Erik Språng <sprang@webrtc.org>
Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com>
Signed-off-by: James Zern <jzern@google.com>
Makes it robust against adding fields before it, which will be useful in
following commits.
Majority of the patch generated by the following Coccinelle script:
@@
typedef AVOption;
identifier arr_name;
initializer list il;
initializer list[8] il1;
expression tail;
@@
AVOption arr_name[] = { il, { il1,
- tail
+ .unit = tail
}, ... };
with some manual changes, as the script:
* has trouble with options defined inside macros
* sometimes does not handle options under an #else branch
* sometimes swallows whitespace
Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Prevent the fifo used in encoding VPx videos from filling up and
stopping encode when it reaches 21845 items, which happens when the
video has more than that number of frames.
Incorporated suggestion from James Zern to prevent calling
frame_data_submit() at all when performing the first pass of a 2-pass
encode so the fifo is not filled at all; replaces original patch which
drained the fifo after filling to prevent it from becoming full.
Fixes the regression originally introduced in
5bda4ec6c3
Co-authored-by: James Zern <jzern@google.com>
Signed-off-by: David Lemler <david@lemler.family>
Signed-off-by: James Zern <jzern@google.com>
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
If the packets returned by libvpx and our internal frame properties
queue get desynchronized for some reason (should not happen, but it is
not clear libvpx API guarantees this), we will keep adding to the queue
indefinitely and never remove anything.
Change the code to drain the queue even if timestamps do not match.
This AVFifo is used to propagate HDR metadata from input frames to
output packets, since libvpx does not allow passing through arbitrary
user data.
It will be extended to pass through other kinds of data in future
commits, so give it a more generic name.
It is not used, except to check whether the packet is valid before
writing HDR metadata to the packet in storeframe(). However, that check
serves no purpose, as the encoded packet is already treated as valid
higher up in this function.
This change improves the performance and multicore scalability of the vp9
codec for streaming single-pass encoded videos by taking advantage of up
to 64 cores in the system. The current thread limit for ffmpeg codecs is 16
(MAX_AUTO_THREADS in pthread_internal.h) due to a limitation in H.264 codec
that prevents more than 16 threads being used.
Experiments show that increasing the thread limit to 64 for vp9 improves
the performance for encoding 4K raw videos for streaming by up to 47%
compared to 16 threads, and from 20-30% for 32 threads, with the same quality
as measured by the VMAF score.
Rationale for this change:
Vp9 uses tiling to split the video frame into multiple columns; tiles must
be at least 256 pixels wide, so there is a limit to how many tiles can be
used. The tiles can be processed in parallel, and more tiles mean more CPU
threads can be used. 4K videos can make use of 16 threads, and 8K videos
can use 32. Row-mt can double the number of threads so 64 threads can be used.
Signed-off-by: James Zern <jzern@google.com>
this maps to the vpxenc argument with the same name and the
VP9E_SET_MIN_GF_INTERVAL codec control
Signed-off-by: James Zern <jzern@google.com>
Reviewed-by: Vignesh Venkatasubramanian <vigneshv@google.com>
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>
There's no warranty that vpx_codec_encode() will generate a list with the same
amount of packets for both the yuv planes encoder and the alpha plane encoder,
so queueing packets based on what the main encoder returns will fail when the
amount of packets in both lists differ.
Queue all data packets for every vpx_codec_encode() call from both encoders
before attempting to assemble output AVPackets out of them.
Fixes ticket #9884
Reviewed-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Almer <jamrial@gmail.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>
The general decoding API uses bitstream filters and an AVFifo
and therefore AVCodecInternal contains pointers to an AVBSFContext
and to an AVFifo and lavc/internal.h includes lavc/bsf.h and
lavu/fifo.h.
Yet actually, only two files are supposed to use these, namely
avcodec.c and (mainly) decode.c. For all the other files,
it should be an opaque type that they should not touch and that
they need not know anything about. This can be achieved by not
including these headers and using the structs instead of the
corresponding typedefs.
This also forces translation units that really use the BSF
and the FIFO APIs themselves to include the relevant headers
directly instead of relying on indirect inclusions (up until now,
even avcodec.c and decode.c relied on fifo.h to be included
by internal.h).
Of course, it also avoids unnecessary rebuilds when bsf.h or fifo.h
change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
When encoding yuva420 (alpha) frames, the vpx encoder uses a second
vpx_codec_ctx to encode the alpha stream. However, codec options were
only being applied to the primary encoder. This patch updates
codecctl_int and codecctl_intp to also apply codec options to the alpha
codec context when encoding frames with alpha.
This is necessary to take advantage of libvpx speed optimizations
such as 'row-mt' and 'cpu-used' when encoding videos with alpha.
Without this patch, the speed optimizations are only applied to the
primary stream encoding, and the overall encoding is just as slow
as it would be without the options specified.
Signed-off-by: Adam Chelminski <chelminski.adam@gmail.com>
Signed-off-by: James Zern <jzern@google.com>
It is not used here at all; instead, add it where it is used without
including it or any of the arch-specific CPU headers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
