Just check for the existence of the bsf. This is equivalent to
the old criterion of the AVCodecContext being a decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is now checked by FATE that no encoder capable of flushing
uses frame threads, so this now redundant runtime check can
be removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If an AVCodec has a private class, its priv_data_size must be > 0
and at the end of a successful call to avcodec_open2()
the AVCodecContext's priv_data must exist and its first element
must be a pointer to said AVClass. This should not be conditional
on priv_data_size being > 0 (which is tested by FATE) or
on the private context having been successfully allocated
(which has to have happened at that point). So remove these
preconditions to make the test stricter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current name comes from a time in which libavcodec/utils.c
contained the whole core of libavcodec.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the list of pixfmts is reallocated every time an entry
is added to it; there are currently 196 pixel formats, so this matters:
It causes 5541704 calls to av_realloc_array() in a typical FATE run,
which is the majority for said function (8095768 calls) and even
a large chunk of the calls to av_realloc() itself (12589508 calls).
Fix this by using ff_formats_pixdesc_filter() instead.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, it has returned the AVFilterFormats list via
an AVFilterFormats** parameter; the actual return value was an int
that was always AVERROR(ENOMEM) on error. The AVFilterFormats**
argument was a pure output parameter which was only documented
by naming the parameter rfmts. Yet nevertheless all callers
initialized the underlying AVFilterFormats* to NULL.
This commit changes this to return a pointer to AVFilterFormats
directly. This is more in line with the API in general, as it
allows to avoid checks for intermediate values.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids a -Wstringop-truncation warning from GCC which takes
issue with the fact that the destination might not be NUL-terminated.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When a color indexing transform with 16 or fewer colors is used,
WebP uses "pixel packing", i.e. storing several pixels in one byte,
which virtually reduces the width of the image (see WebPContext's
reduced_width field). This reduced_width should always be used when
reading and applying subsequent transforms.
Updated patch with added fate test.
The source image dual_transform.webp can be downloaded by cloning
https://chromium.googlesource.com/webm/libwebp-test-data/
Fixes: 9368
Signed-off-by: James Zern <jzern@google.com>
This muxer was untested up until now; had it been tested, it would
have been obvious that it has been broken for years.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The terminating '\0' is no longer included in the size of
the extradata output by the demuxer since commit
36e61e24e7.
E.g. if one remuxes the JACOsub sample JACOsub_capability_tester.jss
from the FATE suite, one receives a file not recognized as JACOsub
before this patch.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Dead since commit 93016f5d1d
which ensured that the packets received by encoders are always blank.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes leaks in case the allocation of the H.264-specific stuff fails.
Fixes Coverity issues #1442911 and #1442914.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Command below failed.
ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128
-init_hw_device qsv=qs@va -hwaccel qsv -hwaccel_device qs
-filter_hw_device va -c:v h264_qsv
-i 1080P.264 -vf "hwmap,format=vaapi" -c:v h264_vaapi output.264
Cause: Assign pair->first directly to data[3] in vaapi frame.
pair->first is *VASurfaceID while data[3] in vaapi frame is
VASurfaceID. I fix this line of code. Now the command above works.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
This improves performance: For msvideo1, the performance improved by
4.8% when encoding the sample from the fate-vsynth1-msvideo1 test;
when encoding the sample from fate-vsynth1-cinepak, performance
improved by 2%. The compiler user was GCC 10 and the calls to encode2
have been timed.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is currently unused and it is only added to enable changes
while maintaining ABI compatibility. The type is uintptr_t in order
to potentially accept a pointer argument.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the number of elements needed in each
recursion step decreases geometrically, so the geometric series
provides an upper bound for the sum of number of elements of
the needed buffers.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Every filter exposing the framesync options via its child_next
callback already calls framesync_preinit() in its preinit callback.
So the filter is already preinited whenever its child_next is called.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Andreas Rheinhardt
Paul B Mahol
Maryla
Zhao Zhili
Limin Wang
James Almer
Wenbin Chen