These values are only used by the mpegvideo unquantize functions,
yet these are not active when intrax is in use. Furthermore,
given that ff_intrax8_decode_picture() decodes multiple
macroblocks in a given call, it makes no sense to return
any value (that was in practice the maximum of the indices
of all the macroblocks decoded).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the mpegvideo unquantize functions which
this decoder does not use at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
dst_depth - src_depth where the result is 6 or 7 in a high bd path means this
is only executed for 16 -> 10 and 16 -> 9.
This patch makes this path general, supporting arbitrary formats as long as
dst_depth > src_depth > 8.
Signed-off-by: James Almer <jamrial@gmail.com>
If pps_single_slice_per_subpic_flag is 1,
slice_{width,height}_in_tiles are undefined and we must instead get the
dimensions of the slice by referring to the corresponding subpicture.
Signed-off-by: Frank Plowman <post@frankplowman.com>
av_frame_side_data_add() typically takes ownership of
the provided AVBufferRef reference and therefore
uses a parameter of type AVBufferRef**; yet with
the AV_FRAME_SIDE_DATA_FLAG_NEW_REF, it creates
new references instead, without touching the given
reference. Therefore it is safe to cast const away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
utils.c is getting quite crowded, and I need a new place to dump a lot of
format handling code for the ongoing rewrite. Rather than bloating this file
even more, start splitting format handling helpers off into a new file.
This also renames the existing utils.h header, which didn't really contain
anything except the SwsFormat definition anyway (the prototypes for what should
have been in utils.h are all still in the legacy swscale_internal.h).
This also makes remap optional (which is a good idea even if we decide to keep flip fixed)
Effect on compression (using 2 rawlsb, golomb rice, large context model with ACES_OT_VWG_SampleFrames
-rw-r----- 1 michael michael 499101306 Mär 11 14:58 float-303503-try3d-m2.nut
-rw-r----- 1 michael michael 503700199 Mär 11 14:57 float-303503-try3d-m1.nut
-rw-r----- 1 michael michael 518150578 Mär 11 14:57 float-303503-try3d-m0.nut
(the test above used the rawlsb patch, which is not applied yet)
Reviewed-by: Jerome Martinez <jerome@mediaarea.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
and call it from ff_ffv1_encode_init()
setting micro version from code writing the extradata is messy, this should
be cleaner
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has been deconstified in 2c2dfd9149
because the FFCodec is touched in av_codec_init_static because
of its get_supported_config callback. Yet this is easily remedied:
Only call get_supported_config to set pix_fmts if the codec does
not already have it set.
This also fixes a mismatch between the declaration of ff_mjpeg_encoder
in allcodecs.c and the definition in mjpegenc.c. Said mismatch is
actually undefined behaviour.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only two encoders (the native MPEG-1/2 ones) provide
supported_framerates and they don't implement the
get_supported_config callback. It is highly unlikely that
any codec will set supported_framerates dynamically at all,
so remove the code querying for frame rates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions check whether the AVCodec* is NULL, but this
has already been checked at a lot of places in our codebase,
so that it boils down to checking the is_decoder flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It also applies to scenarios where ff_encode_receive_frame()
is used. Also remove the redundant av_codec_is_decoder().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sbcdec_data.h is only included by sbcdec.c, so this won't
cause the data to be included multiple times in the binary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ///< or /**< form of doxygen comments are only to be used
when the documentation follows the member and the comment
block starts on the same line as the member. This commit
fixes wrong uses of them; in particular, this fixes the comment
for mb_height in H.264 SPS's structure which was wrongly added
to mb_width.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to inline put_vc2_ue_uint() everywhere;
only one call site is actually hot: The one in encode_subband()
(which accounts for 35735040 of 35739495 calls to said function
in a FATE run). Uninline all the others.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also remove the condition of AMF_DATA_TYPE_BOOL when parse color
info. There is no AMF_DATA_TYPE_BOOL type in color info.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
1. Rename metaVideoColor to meta_color_info
2. Allocated FLVMetaVideoColor together with FLVContext
3. Improve the use of meta_color_info_flag. Do a sequence of strcmp
only if meta_color_info_flag is FLV_COLOR_INFO_FLAG_PARSING.
4. Check return value of amf_parse_object().
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Up until now, the encoder processed only one bit at a time.
With this patch, it is eight bits.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The return value of ff_draw_init and ff_draw_init2 are not checked in
most usages. However, if they return an error, they don't get to the
point where they set the attributes of the FFDrawContext. These
functions are typically used in conjunction with ff_draw_color, which
checks draw->desc->flags, causing a null pointer dereference.
Signed-off-by: Nil Fons Miret <nilf@netflix.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch refactors the CUDA import code to allow for Vulkan images
with multiple planes to be mapped.
Currently, a driver bug exists which causes NV12 images to be mapped
incorrectly when the memory being mapped contains both planes, the
issue has been reported to NVIDIA.
yuv420p does work correctly, however.
This is still an improvement, as the code used to crash when trying to
map the memory, unless disable_multiplane=1 was given as an option.
