libavcodec/libx264: fix reference frame computation based on level
The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").
However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.
Since libx264 has correctly parsed the level to int
(x4->params.i_level_idc), we should rely on this value instead of
attempting to parse the level string on our own.
Signed-off-by: Josh Brewster <josh.brewster@protonmail.com> Signed-off-by: Josh de Kock <josh@itanimul.li>
avcodec/v4l2_m2m_enc: Reduce log verbosity for some params
Currently the user gets unhelpful warnings when some default parameters
are not supported by the device. The verbosity of these log messages has
been changed to AV_LOG_DEBUG.
Reviewed-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
libswscale/vscale.c makes extensive use of function pointers and in
doing so it converts these function pointers to and from a pointer to
void. Yet this is actually against the C standard:
C90 only guarantees that one can convert a pointer to any incomplete
type or object type to void* and back with the result comparing equal
to the original which makes pointers to void generic pointers to
incomplete or object type. Yet C90 lacks a generic function pointer
type.
C99 additionally guarantees that a pointer to a function of one type may
be converted to a pointer to a function of another type with the result
and the original comparing equal when converting back.
This makes any function pointer type a generic function pointer type.
Yet even this does not make pointers to void generic function pointers.
Both GCC and Clang emit warnings for this when in pedantic mode.
This commit fixes this by using a union that can hold one member of any
of the required function pointer types to store the function pointer.
This works even for C90.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat: only allow a single bitstream filter when muxing
Current muxers only use a single bitstream filter, so there is no need to
maintain code which operates on a list of bitstream filters. When multiple
bitstream filters are needed muxers can simply use a list bitstream filter.
If there is a use case in the future when different bitstream filters should be
added at subsequent packets then a new API possibly involving reconfiguring the
list bitstream filter can be added knowing the exact requirements.
Mark Thompson [Mon, 13 Apr 2020 15:33:20 +0000 (16:33 +0100)]
ffmpeg: Use hardware config metadata with encoders
This can support encoders which want frames and/or device contexts. For
the device case, it currently picks the first initialised device of the
desired type to give to the encoder - a new option would be needed if it
were necessary to choose between multiple devices of the same type.
Mark Thompson [Mon, 13 Apr 2020 15:33:16 +0000 (16:33 +0100)]
lavc/qsvenc: Add hardware config metadata
All of these encoders can accept libmfx surfaces directly in a hardware
frames context, or they can accept software frames if a suitable device
is supplied to use.
avcodec/cbs_h265_syntax_template: Check num_negative/positive_pics when inter_ref_pic_set_prediction_flag is set
Fixes: out of array access Fixes: 20446/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5707770718584832 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/dirac_vlc: Fix integer overflow in ff_dirac_golomb_read_32/16bit()
Fixes: left shift of 1073741824 by 1 places cannot be represented in type 'int32_t' (aka 'int') Fixes: 21245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5683334274613248
Change to int16_t suggested by Lynne
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Lynne <dev@lynne.ee> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Martin Storsjö [Thu, 23 Apr 2020 06:19:25 +0000 (09:19 +0300)]
dnn-layer-mathbinary-test: Fix tests for cases with extra intermediate precision
This fixes tests on 32 bit x86 mingw with clang, which uses x87
fpu by default.
In this setup, while the get_expected function is declared to
return float, the compiler is (especially given the optimization
flags set) free to keep the intermediate values (in this case,
the return value from the inlined function) in higher precision.
This results in the situation where 7.28 (which actually, as
a float, ends up as 7.2800002098), multiplied by 100, is
728.000000 when really forced into a 32 bit float, but 728.000021
when kept with higher intermediate precision.
For the multiplication case, a more suitable epsilon would e.g.
be 2*FLT_EPSILON*fabs(expected_output), but just increase the
current hardcoded threshold for now.
libavutil/mem.h is unneeded since 33d18982fa03feb061c8f744a4f0a9175c1f63ab,
the commit that introduced the new packet-based bsf API, because with
this switch the allocations were no longer performed directly, but by
av_new_packet().
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
With 33d18982fa03feb061c8f744a4f0a9175c1f63ab, the commit introducing
the new packet-based bsf API, a new buffer was no longer allocated
directly, but via av_new_packet(), so that libavutil/mem.h was no longer
needed.
Moreover since commit dc99ee6b08e54de13b4c82ff265609b6ab83e3d8
av_packet_make_writable() is employed which copies the data in case it
is unavoidable so that string.h is no longer used (it was used for
memcpy()).
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since 33d18982fa03feb061c8f744a4f0a9175c1f63ab (the commit that
introduced the new bsf API) allocating an enlarged buffer in case
extradata needs to be added to a packet is done via av_new_packet(),
so that libavutil/mem.h is no longer needed.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This bsf doesn't have any options, so including libavutil/opt.h is
unnecessary.
Reviewed-by: Peter Ross <pross@xvid.org> Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mux.c was split from utils.c in 55f9037f38bc3beacb2f5a17408c1d24c077d7fd
and during this split all headers were simply copied without checking if
they were only needed in the part that stayed in utils.c (or whether
these haeders were needed at all). As a result quite a lot of headers
in mux.c are unnecessary. This commit removes them.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
libavutil/pixdesc.h has been included for av_get_pix_fmt_name() in 603b8bc2a109978c8499b06d2556f1433306eca7 and is unused since commit 2fb7501938b7103624c9bef740ca498258cacdab that removed the stuff belonging
to FF_API_FORMAT_PARAMETERS. Notice that this file still uses
AV_PIX_FMT_NONE and that therefore the header libavutil/pixfmt.h has
been included (this header is included in pixdesc.h as well as also in
libavutil/internal.h which is also included).
libavcodec/avpacket: Don't simply forward return value of av_dict_set()
The documentation of av_dict_set() states that values >= 0 indicate
success, whereas av_packet_unpack_dictionary() implies that return
values > 0 are impossible. So only forward the return value of
av_dict_set() in av_packet_unpack_dictionary() on error.
(Btw: av_dict_set() does currently not return values > 0.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
support dvcC/dvcC box from spec Dolby Vision Streams Within the
ISO Base MediaFile Format Version 2.1.2
(https://www.dolby.com/in/en/technologies/dolby-vision/dolby-vision\
-bitstreams-within-the-iso-base-media-file-format-v2.1.2.pdf)
avcodec/iff: Check length before memcpy() in decode_deep_rle32()
Fixes: out of array read Fixes: 20796/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5111364702175232.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
hwcontext_vulkan: correctly download and upload flipped images
We derive the destination buffer stride from the input stride,
which meant if the image was flipped with a negative stride,
we'd be FFALIGNING a negative number which ends up being huge,
thus making the Vulkan buffer allocation fail and the whole
image transfer fail.
Only found out about this as OpenGL compositors can copy an entire
image with a single call if its flipped, rather than iterate over
each line.
Reindentation, removal of { } if they contain only one statement
and moving the return statement to a line of its own in situations
like "if (ret < 0) return ret;". Moreover, several overlong lines
were made shorter and a camelCase variable received a name in line
with our naming conventions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Redo handling of FlagDefault
Up until now, the Matroska muxer would mark a track as default if it had
the disposition AV_DISPOSITION_DEFAULT or if there was no track with
AV_DISPOSITION_DEFAULT set; in the latter case even more than one track
of a kind (audio, video, subtitles) was marked as default which is not
sensible.
This commit changes the logic used to mark tracks as default. There are
now three modes for this:
a) In the "infer" mode the first track of every type (audio, video,
subtitles) with default disposition set will be marked as default; if
there is no such track (for a given type), then the first track of this
type (if existing) will be marked as default. This behaviour is inspired
by mkvmerge. It ensures that the default flags will be set in a sensible
way even if the input comes from containers that lack the concept of
default flags. This mode is the default mode.
b) The "infer_no_subs" mode is similar to the "infer" mode; the
difference is that if no subtitle track with default disposition exists,
no subtitle track will be marked as default at all.
c) The "passthrough" mode: Here the track will be marked as default if
and only the corresponding input stream had disposition default.
This fixes ticket #8173 (the passthrough mode is ideal for this) as
well as ticket #8416 (the "infer_no_subs" mode leads to the desired
output).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
At the end of encoding, the FLAC encoder sends a packet whose side data
contains updated extradata (e.g. a correct md5 checksum). The Matroska
muxer uses this to update the CodecPrivate.
In doing so, the stream's codecpar was copied. But given that writing
a FLAC CodecPrivate does not modify the used AVCodecParameters at all,
there is no need to do so and this commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Don't waste bytes on length fields
Several EBML Master elements for which a good upper bound of the final
length was available were nevertheless written without giving an
upper bound of the final length to start_ebml_master(), so that their
length fields were eight bytes long. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Only write Tracks if there is a track
The Matroska muxer does not write every stream as a Matroska track;
some streams are written as AttachedFile. But should no stream be
written as a Matroska track, the Matroska muxer would nevertheless
write a Tracks element without a TrackEntry. This is against the spec.
This commit changes this and only writes a Tracks if there is a Matroska
track.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Warn that WebM doesn't support Attachments
As WebM doesn't support Attachments, the Matroska muxer drops them when
in WebM mode. This happened silently until this commit which adds a
warning for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Don't use size of inexistent Cluster
In order to determine whether the current Cluster needs to be closed
because of the limits on clustersize and clustertime,
mkv_write_packet() would first get the size of the current Cluster by
applying avio_tell() on the dynamic buffer holding the current Cluster.
It did this without checking whether there is a dynamic buffer for
writing Clusters open right now.
In this case (which happens when writing the first packet)
avio_tell() returned AVERROR(EINVAL); yet it is not good to rely on
avio_tell() (or actually, avio_seek()) to handle the situation
gracefully.
Fixing this is easy: Only check whether a Cluster needs to be closed
if a Cluster is in fact open.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Add check for using explicit TrackNumber
When creating DASH streams, the TrackNumber is externally prescribed
and not derived from the number of streams in the AVFormatContext, so
if the number of tracks for a file using an explicit TrackNumber was
more than one, the resulting file would be broken (it would be impossible
to tell to which track a Block belongs if different tracks share the
same TrackNumber). So disallow this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Improve Cues in case of no video
The Matroska muxer currently only adds CuePoints in three cases:
a) For video keyframes. b) For the first audio frame in a new Cluster if
in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
files won't have any Cues which impedes seeking.
This commit changes this. For every track in a file without video track
it is checked and tracked whether a Cue entry has already been added
for said track for the current Cluster. This is used to add a Cue entry
for each first packet of each track in each Cluster.
Implements #3149.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Remove limit on the number of tracks
The Matroska file format has practically no limit on the number of
tracks (the current limit is 2^56 - 1); yet because they are encoded in
a variable length format in (Simple)Blocks this muxer has simply imposed
a limit on the number of tracks in order to ensure that they can always
be written on one byte in order to simplify the muxing process.
This commit removes said limit.
Also, zero is an invalid TrackNumber, so disallow this value in the
dash_track_number option.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit factors the ability to write ordinary EBML numbers out of
the functions for writing EBML lengths. This is in preparation for
future commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Rename functions to better reflect what they do
EBML uses variable length integers both for the EBML IDs as well as for
the EBML lengths; Matroska also uses them for the TrackNumber in
(Simple)Blocks and for the lengths of laces when EBML lacing is used.
When encoding EBML lengths, certain encodings have a special meaning,
namely that the element has an unknown length. This is not so when
encoding general EBML variable length integers.
Yet the functions called ebml_num_size() and put_ebml_num() had this
special meaning hardcoded, i.e. they are there to write EBML lengths and
not general EBML numbers. So rename them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Make ebml_num_size() more robust
Matroska (or actually EBML) uses variable-length numbers where only
seven bits of every byte is usable for the length; the other bits encode
the length of the variable-length number. So in order to find out how
many bytes one needs to encode a given number one can use a loop like
while (num >> 7 * bytes) bytes++; the Matroska muxer effectively did this.
Yet it has a disadvantage: It is impossible for the result of a single
right shift of an unsigned number with most significant bit set to be
zero, because one can only shift by 0..(width - 1). On some
architectures like x64 it is not even possible to do it with undefined
right shifts in which case this leads to an infinite loop.
This can be easily avoided by switching to a loop whose condition is
(num >>= 7). The maximum value the so modified function can return
is 10; any value > 8 is invalid and will now lead to an assert in
put_ebml_num() or in start_ebml_master() (or actually in
put_ebml_size_unknown()).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use the mime_types of the corresponding AVCodecDescriptor instead of
tables specific to Matroska. The former are generally more encompassing:
They contain every item of the current lists except "text/plain" for
AV_CODEC_ID_TEXT and "binary" for AV_CODEC_ID_BIN_DATA.
The former has been preserved by special-casing it while the latter is
a hack added in c9212abf so that the demuxer (which uses the same tables)
sets the appropriate CodecID for broken files ("binary" is not a correct
mime type at all); using it for the muxer was a mistake. The correct
mime type for AV_CODEC_ID_BIN_DATA is "application/octet-stream" and
this is what one gets from the AVCodecDescriptor.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>