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.
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.
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>
* commit '94eed68ace9f2416af8457fcbf142b175928c06b':
lavc: Drop deprecated options moved to private contexts
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b183abfb5b6366b177cf44f244c66156257a6fd6':
vpx: Support color range
Decoder chunk not merged as the framework automatically copies avctx
color range to the frame color range. And we already set the avctx field
since cbcc88c039.
Merged-by: Clément Bœsch <cboesch@gopro.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>
with older versions of libvpx
since:
432be63 lavc/libvpx: Fix support for RGB colorspace.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Zern <jzern@google.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>
Anton Khirnov