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>
HDR10+ metadata is stored in the bit stream for HEVC. The story is
different for VP9 and cannot store the metadata in the bit stream.
HDR10+ should be passed to packet side data an stored in the container
(mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is
passing it to the AVPacket side data.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Zern <jzern@google.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Reviewed-by: James Zern <jzern@google.com>
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>
Several options that were too codec-specific were deprecated between
0e6c853221 and
0e9c4fe254.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.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.
Getting rid of unnecessary use of AVDictionary object in parsing
vpx_svc_ref_frame_config.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Zern <jzern@google.com>
In order to fine-control referencing schemes in VP9 encoding, there
is a need to use VP9E_SET_SVC_REF_FRAME_CONFIG method. This commit
provides a way to use the API through frame metadata.
similar to:
36e51c190b avcodec/libaomenc: use pix_fmt descriptors where useful
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Zern <jzern@google.com>
In order for rate control to correctly allocate bitrate to each temporal
layer, correct temporal layer id has to be set to each frame. This
commit provides the ability to set correct temporal layer id for each
frame.
Signed-off-by: James Zern <jzern@google.com>
This commit reuses the configuration options for VP8 that enables
temporal scalability for VP9. It also adds a way to enable three
preset temporal structures (refer to the documentation for more
detail) that can be used in offline encoding.
Signed-off-by: James Zern <jzern@google.com>
Current default is 200kbps, which produces inconsistent
results (too high for low-res, too low for hi-res). Use
CRF instead, which will adapt. Affects VP9. Also have
VP8 use a default bitrate of 256kbps.
Signed-off-by: James Zern <jzern@google.com>
This commit adds configuration options to libvpxenc.c that can be used to
tune the sharpness parameter for VP8 and VP9.
Signed-off-by: Rene Claus <rclaus@google.com>
Signed-off-by: James Zern <jzern@google.com>
This commit adds configuration options to libvpxenc.c that can be used to
enable VP8 temporal scalability. It also adds a way to programmatically set the
per-frame encoding flags which can be used to control usage and updates of
reference frames while encoding with temporal scalability enabled.
Signed-off-by: James Zern <jzern@google.com>
The libvpx doxy says that a value of 0 for the g_threads field is
equivalent to a value of 1, whereas for avctx->thread_count it means
the maximum amount of threads possible for the host system.
Use av_cpu_count() to get the correct thread count when auto threads
is requested.
Reviewed-by: James Zern <jzern@google.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>
Corpus VBR mode is a variant of standard VBR where the complexity
distribution midpoint is passed in rather than calculated for a specific
clip or chunk.
The valid range is [0, 10000]. 0 (default) uses standard VBR.
Signed-off-by: James Zern <jzern@google.com>
vp9_cx_iface actually allows values in range [0..2].
This fixes ticket #5894.
Signed-off-by: Kagami Hiiragi <kagami@genshiken.org>
Signed-off-by: James Zern <jzern@google.com>
Andreas Rheinhardt
Adam Chelminski
Mohammad Izadi
Matthieu Patou
Andreas Rheinhardt
Anton Khirnov
Wonkap Jang
James Almer
James Zern
Marton Balint
elliottk
Guo, Yejun
Jun Zhao
Rene Claus
Ard Oerlemans
Chirag Lathia
wm4
Vittorio Giovara
Kagami Hiiragi
Alex Converse
Carl Eugen Hoyos
Luca Barbato