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>
Commit 0d1229f1d2 factored the main part
of the voc demuxer's read_packet function out; yet when this Libav
commit was merged in f99195d56f, the
dependency of the other users of this function on vocdec.o was
unnecessarily kept. This commit fixes this.
While just at it, also disable the data only used by the voc demuxer
and muxer in voc.c if both of them are disabled.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
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>
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>
This is a result of the mov channel parsing stuff being factored out
of mov.c twice: Once in 91b782720f
to isom.c and later in 3bab7cd128.
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>
It only existed because some code in mjpegenc_common.c relied on it;
yet said code was actually only used by mjpegenc.c and has been moved
there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allows to make ff_init_uni_ac_vlc static;
ff_mjpeg_encode_picture_frame has also been made static, but it could
always have been made static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since g2meet.c doesn't use it any more, only encoders use it and
the place for their common code is mjpegenc_common.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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 MJPEG decoder is already activated by configure whenever the tiff
decoder is selected; ergo it is unnecessary to add a dependency in the
Makefile.
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>
Add inline function for vec_xl if VSX is not supported. vec_xl intrinsic
is only available on POWER 7 or higher.
Fixes ticket #8750.
Signed-off-by: Andriy Gelman <andriy.gelman@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.
Signed-off-by: James Almer <jamrial@gmail.com>
Zero is the recommended value in Nvidia coding samples for low latency use-cases.
Signed-off-by: Michal Novotny <michal.novotny@comprimato.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
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
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
after patch:
14:50:55:02
Signed-off-by: Anton Khirnov <anton@khirnov.net>
