avcodec: Add missing FF_API define for libavcodec pix fmt API
avcodec_find_best_pix_fmt2 has been deprecated and replaced by
avcodec_find_best_pix_fmt_of_2 in 2a54ae9df8cbc1717b3929222ac75f384e2ff240.
avcodec_find_best_pix_fmt_of_2 and avcodec_get_pix_fmt_loss meanwhile
were deprecated in 617e866e25b72fa5d9f9d6bbcbd7e4bd69e63a54 when these
functions were de facto moved to libavutil; this has been mentioned in
APIchanges in f7a1c5e4d2294a8970ede7f6deb2fe0a64e202a5. Yet the
attribute_deprecated was never set for the latter two functions and they
were not wrapped in an FF_API define. This commit does this.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/avcodec: Add missing deprecation to AVCodecParser.next
The whole old next API has been deprecated in commit 7e8eba2d8755962d9dca5eade57bf8f591a73c0c, yet deprecating the next
pointer has been forgotten (the next pointers of other structures are
below the public API delimiter, but such a delimiter doesn't exist for
AVCodecParser).
Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/gifenc: Only write frame palette entries that actually used
GIF palette entries are not compressed, and writing 256 entries,
which can be up to every frame, uses a significant amount of
space, especially in extreme cases, where palettes can be very
small.
Example, first six seconds of Tears of Steel, palette generated
with libimagequant, 320x240 resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Derek Buitenhuis [Sat, 20 Feb 2021 17:22:51 +0000 (17:22 +0000)]
avcodec/gifenc: Add global_palette option
This option will disable the writing of the global palette in global
GIF header if it is set to 0, causing only the frame-level palette
to ever be written.
This will be useful later on when further frame-level palette
optimizations are introduced.
The default is 1, which maintains current default behavior.
Anton Khirnov [Sat, 12 Dec 2020 14:09:10 +0000 (15:09 +0100)]
Handle AVID MJPEG streams directly in the MJPEG decoder.
AVID streams - currently handled by the AVRN decoder - can be (depending
on extradata contents) either MJPEG or raw video. To decode the MJPEG
variant, the AVRN decoder currently instantiates a MJPEG decoder
internally and forwards decoded frames to the caller (possibly after
cropping them).
This is suboptimal, because the AVRN decoder does not forward all the
features of the internal MJPEG decoder, such as direct rendering.
Handling such forwarding in a full and generic manner would be quite
hard, so it is simpler to just handle those streams in the MJPEG decoder
directly.
The AVRN decoder, which now handles only the raw streams, can now be
marked as supporting direct rendering.
This also removes the last remaining internal use of the obsolete
decoding API.
Guo, Yejun [Thu, 25 Feb 2021 06:38:12 +0000 (14:38 +0800)]
avfilter/vf_vif.c: fix build warning for [-Wmain]
src/libavfilter/vf_vif.c: In function ‘process_frame’:
src/libavfilter/vf_vif.c:542:20: warning: ‘main’ is usually a function [-Wmain]
AVFrame *out, *main = NULL, *ref = NULL;
^~~~
Guo, Yejun [Thu, 25 Feb 2021 06:38:11 +0000 (14:38 +0800)]
avfilter/vf_ssim.c: fix build warning for [-Wmain]
The build warning message:
src/libavfilter/vf_ssim.c: In function ‘ssim_plane_16bit’:
src/libavfilter/vf_ssim.c:246:24: warning: ‘main’ is usually a function [-Wmain]
const uint8_t *main = td->main_data[c];
^~~~
src/libavfilter/vf_ssim.c: In function ‘ssim_plane’:
src/libavfilter/vf_ssim.c:289:24: warning: ‘main’ is usually a function [-Wmain]
const uint8_t *main = td->main_data[c];
^~~~
Anton Khirnov [Sun, 14 Feb 2021 15:37:33 +0000 (16:37 +0100)]
pngdec: fix and simplify apng reference handling
Current code is very confused and confusing. It uses two different
reference frames - "previous" and "last" - when only one is really
necessary. It also confuses the two, leading to incorrect output with
APNG_DISPOSE_OP_PREVIOUS mode.
Anton Khirnov [Sun, 14 Feb 2021 15:12:39 +0000 (16:12 +0100)]
lavc/lscrdec: drop unapplicable private capabilities
FF_CODEC_CAP_ALLOCATE_PROGRESS makes no sense because the decoder does
not support frame threading.
FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM makes no sense because the decoder
does not handle skip_frame.
James Almer [Sat, 20 Feb 2021 13:21:47 +0000 (10:21 -0300)]
avutil/buffer: free all pooled buffers immediately after uninitializing the pool
No buffer will be fetched from the pool after it's uninitialized, so there's
no benefit from waiting until every single buffer has been returned to it
before freeing them all.
This should free some memory in certain scenarios, which can be beneficial in
low memory systems.
Based on a patch by Jonas Karlman.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: James Almer <jamrial@gmail.com>
avcodec/x86/diracdsp_init: Make functions only used here static
This allowed to remove forward declarations. Because compilers expect
declarations for all functions they encounter even when it is within
blocks disabled via "if (0 && foo)", one has to use a real #if in
ff_diracdsp_init_x86.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Unused since a1f3b18bf55f106c974eacb1dc831be4d2bd5277, yet as nonstatic
functions the compiler can't detect this, so that these functions aren't
stripped and no warning is emitted.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/acelp_pitch_delay: Inline small functions only used once
ff_acelp_decode_8bit_to_1st_delay3, ff_acelp_decode_4bit_to_2nd_delay3
and ff_acelp_decode_5_6_bit_to_2nd_delay3 are all only used once (by
g729dec) whereas ff_acelp_decode_9bit_to_1st_delay6 and
ff_acelp_decode_6bit_to_2nd_delay6 are completely unused; with the
possible exception of ff_acelp_decode_4bit_to_2nd_delay3, these
functions are so small that inlining them is appropriate; and as long as
ff_acelp_decode_4bit_to_2nd_delay3 is only called once, this is also
true for it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/bitstream: Rewrite code to avoid triggering compiler warning
Clang infers from the existence of a default case that said case can be
taken. In case of libavcodec/bitstream.c said default case consisted of
an av_assert1 that evaluates to nothing in case of the ordinary assert
level. In this case (that doesn't happen) a variable wouldn't be
initialized, so Clang emitted Wsometimes-uninitialized warnings.
Solve this by making sure that the default path also initializes
the aforementioned variable.
Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The counter for the number of styles is written on two bytes, ergo
anything > UINT16_MAX is invalid. This also fixes a compiler warning
because of a tautologically true check on 64bit systems.
Reviewed-by: Philip Langdale <philipl@overt.org> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
tiff.c is the only user of the data from tiff_data.c (the dependency of
the tiff encoder of it is spurious). Therefore this commit moves all the
data from tiff_data.c to tiff_data.h (which is only included by tiff.c)
and makes the objects declared therein static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The options of the w64 demuxer are a proper subset of the options for
the wav demuxer, making it possible to reuse a part of the options for
the wav demuxer for the w64 demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/isom: Split movaudio/movvideo tags off into a separate file
The NUT and avi demuxers only need ff_codec_movvideo_tags and so this
removes a dependency on the rest of isom.c as well as on mpeg4audio.c
(which isom depends on); it is similar for the Matroska demuxer and
muxers, except that the mpeg4audio.c dependency can't be avoided.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also remove the isom.h header; and while just at it, remove an unused
mathematics.h inclusion.
(isom.c actually depends upon mpeg4audio from libavcodec for
avpriv_mpeg4audio_get_config2 and avpriv_mpa_freq_tab; yet there is
no configure dependency for iso_media which leads to failure of shared
builds.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/g2meet, mjpegdec: Factor out common VLC initialization code
While just at it, remove the nb_codes parameter: It is redundant
(the number of codes is implicitly contained in the array containing how
many entries of a specific size there are) and for this reason it might
even be wrong, so it is better to check what is actually used instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The avrn decoder actually only needs one thing: The MJPEG decoder.
Instead the Makefile made it compile mjpegdec and configure required
some of the prerequisites of the MJPEG decoder (exif and jpegtables).
Even if all the prerequisites of the MJPEG decoder were required, it
would still not make the MJPEG decoder usable, because for that
the MJPEG decoder needs to be in the list of codecs in codec_list.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Neither the feature, public fields, or AVOptions were ever truly deprecated,
nor will have been removed if this FF_API_ define was left in place, so
get rid of it as it's misleading.
Anton Khirnov [Mon, 8 Feb 2021 11:14:27 +0000 (12:14 +0100)]
ffprobe: stop printing deprecated fields
The FF_API macros are private and must not be used by external callers.
As the fields in question are to be removed without replacement, just
drop them.
The fields are:
AVPacket.convergence_duration
AVCodecContext.time_base
AVCodecContext.timecode_frame_start
AV_PIX_FMT_FLAG_PSEUDOPAL pixel descriptor flag
Mark Reid [Sun, 17 Jan 2021 01:48:45 +0000 (17:48 -0800)]
avformat/mov: fix timecode with counter mode flag set
The current behaviour ends up squaring the avg_frame_rate if the conter mode flag is set.
This messes up the timecode calculation, and looks to me as a regression that
seems to have been introduced 428b4aac.
Upon further testing is seems that no special case is need for having the counter flag set.
av_timecode_init appears to handles the timecode correctly, at least in the sample files
I have.
Here is a sample mov file with the counter flag set
https://www.dropbox.com/s/5l4fucb9lhq523s/timecode_counter_mode.mov
before the patch ffmpeg will report the timecode as:
00:37:11:97 and warns that the timecode framerate is 576000000/1002001
projects / ffmpeg / log