Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.coded_side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer <jamrial@gmail.com>
the type is also changed to int as it is interpreted as int in av_get_packet()
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_WSVQA_fuzzer-6593408795279360
Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_WSVQA_fuzzer-4613908817903616
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 4481246996173000000 - -4778576820000000000 cannot be represented in type 'long'
Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-5063670588899328
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 91542414454000000 - -9154241494546000000 cannot be represented in type 'long'
Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-4739147999084544
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The demuxer does not set packet timestamps itself after
c6b6356635 and instead relies on the
parser to do it. However, this does not matter from the caller
perspective as it still happens inside the demuxer. The demuxer should
thus not be flagged as not having timestamps.
The parser does not have a timebase associated with it, so in general it
makes no sense for it to be exporting durations. Longer-term this
should be handled more cleanly with a new parser API.
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If not set, the muxer will not receive a NULL packet in
the write_packet function") it is actually an internal flag
that has been publically exposed because there was no internal
flags field for output formats for a long time. But now there is
and so use it by replacing the public flag with a private one.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have to write an explicit BlockDuration element (and use
a BlockGroup instead of a SimpleBlock) in case the Track
has a DefaultDuration that is inconsistent with the duration
of the packet.
The matroska-h264-remux test uses a file with coded fields
where the duration of a Block is the duration of a field,
not of a frame, therefore this patch writes said BlockDuration
elements.
(When using a BlockGroup, one has to add ReferenceBlock elements
to distinguish keyframes from non-keyframes. Unfortunately,
the AV1 codec mapping [1] requires us to reference all references
and to really use the real references, which requires a lot of
effort for basically no gain. When BlockGroups are used with AV1,
the created files are most likely invalid, both before and after
this patch, but this patch makes this more likely to happen.)
[1]: https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec/av1.md
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Suggested-by: Tomas Härdin <git@haerdin.se>
Fixes: 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5130394286817280
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It was added in cb114ed464 with the comment
"This will allow fixing several bugs with the -shortest option".
Since
* there is no explanation of what these bugs are
* libavformat is not the place to work around ffmpeg CLI bugs
* there is no indication that this feature is actually in use
deprecate it without replacement.
Avoid using the deprecated functions ssh_try_publickey_from_file among
others in favor of symbols introduced in libssh 0.6.0 (Jan 2014) and
update configure to require this version.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The 1000 did result in the appearance of a never ending reload loop
The RFC mandates that "If the client reloads a Playlist file and finds that it has not
changed, then it MUST wait for a period of one-half the target
duration before retrying." and if it has changed
"the client MUST wait for at least the target duration before attempting to reload the
Playlist file again"
Trying to reload 3 times seems a better default than 1000 given these
durations
Issue found by: Сергей Колесников
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 61991/clusterfuzz-testcase-minimized-ffmpeg_dem_JPEGXL_ANIM_fuzzer-5524679648215040
Fixes: 62181/clusterfuzz-testcase-minimized-ffmpeg_dem_JPEGXL_ANIM_fuzzer-5504964305485824
Fixes: 62214/clusterfuzz-testcase-minimized-ffmpeg_dem_JPEGXL_ANIM_fuzzer-4782972823535616
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For badly interleaved files, interleave packets from multiple tracks
at the demuxer level can trigger seeking back and forth, which can be
dramatically slow depending on the protocol. Demuxer level interleave
can be useless sometimes, e.g., reading mp4 via http and then
transcoding/remux to DASH. Disable this option when you don't need the
demuxer level interleave, and want to avoid the IO penalizes.
Co-authored-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Every code point in the BMP is representable with at most three bytes
in UTF-8 and every code point not in the BMP takes four bytes.
For each of the latter, the encoding of UTF-16 takes as many
bytes; for each of the former, it takes at most 3/2 as many.
Therefore one can decrease the size of the buffer allocated
here.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Happens when length > INT_MAX / 2; use unsigned for the computation,
but restrict the value to INT_MAX, because avio_get_str16le()
accepts an int as buf_len argument. Notice that it can happen
that the string read by avio_get_str16le() is truncated in this case.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
get_tag() is not designed with negative length in mind;
in this case, it will allocate a very small buffer
(LEN_PRETTY_GUID + 1) and might call avio_get_str16le()
with a negative maxlen (which relies on these parameters
to be signed).
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each of the 16 bytes of a GUID is written as a two-character
hex value and three hyphens, leading to a length of 35.
GCC 13 emits a -Wformat-truncation= warning because of this.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is undefined behaviour even in cases where it works
(it works because it is only a const uint8_t* vs. uint8_t* difference).
Instead add a cbuf parameter to pass a const buffer (for writing)
as well as a parameter indicating whether we are reading or writing;
retry_transfer_wrapper() itself then uses the correct function
based upon this information.
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Broken in e8704a8f60
when ffurl_read() has been turned into a static inline function
different from the actually used function ffurl_read2().
Fixes ticket #10562.
Tested-by: Mitzsch01
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mxf_match_uid() accepts two const UID and a len parameter.
UID is a typedef for an array of 16 uint8_t, so the const UID
parameter is actually a pointer to const uint8_t.
The point of mxf_match_uid() is to check whether the initial
part of two UIDs match; the length of said part is given
by the len parameter. Once an incomplete UID has been passed
to mxf_match_uid() (albeit with the correct len, so safe),
which makes GCC emit -Wstringop-overread warnings.
Fix this by using a const uint8_t[] as type; it is more
natural for incomplete UIDs.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are currently non-const for reasons unknown, although
avio_write() accepts a const buffer.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is undefined behaviour even in cases where it works
(it works because both are pointers). Instead change
the functions involved to use the type expected by the AVIO-API
and add inline wrappers for our internal callers.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only included because two very rarely used functions
use pointers to URLContexts; use struct URLContext instead.
Also move ffio_geturlcontext() so that one can avoid
a forward declaration of struct URLContext (which would be
necessary as soon as FF_API_AVIODIRCONTEXT is no more).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Incompatibility of the flags and the protocol's capabilities
are checked generically (see url_alloc_for_protocol()).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A switch is simpler than a lookup over a table with
three entries, only two of which can happen at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Broken in 0c6e5f321b.
Also add it to decklink_enc.cpp in order not to rely
on an implicit inclusion via libavfilter/ccfifo.h.
Reviewed-by: あんこ <mailcrystaldiskinfo@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes many warnings when using -Wcast-qual.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not necessary at all. So remove it.
This also breaks an inclusion cycle mem.h->avutil.h->common.h->mem.h.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Most users of ffio_init_context() simply want to wrap
a buffer into an AVIOContext; they do not provide
function pointers at all.
Therefore this commit adds shortcuts for these two common
operations. This also allows to accept const data when reading
(i.e. the const is now cast away at a central place in
ffio_init_read_context() instead of at several callers).
This also allows to constify the data in ff_text_init_buf().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodec is only ever used as an incomplete type (i.e. via a pointer
to an AVCodec) in avformat.h and it is not really part of the core
of avformat.h or libavformat; almost none of our internal users
make use of it (and none make use of hwcontext.h, which is implicitly
included). So switch to use struct AVCodec, but continue to include
codec.h for external users for compatibility.
Also, do the same for AVFrame and frame.h, which is implicitly included
by codec.h (via lavu/hwcontext.h).
Also, remove an unnecessary inclusion of <time.h>.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and also perform the remainder of the subtitle parsing directly
after mkv_parse_subtitle_codec().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely to a place after the AVStream has already been created,
so that it can be directly attached to it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
More exactly, factor codec-specific video parsing out of
matroska_parse_tracks(). This is intended to improve readability.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If the size of the data of an EbmlBin is > 0, its data is always
present, as ebml_read_binary() always leaves the buffer
in a consistent state (even on error).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
More exactly, factor codec-specific audio parsing out of
matroska_parse_tracks(). This is intended to improve readability.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, matroska_parse_tracks() has two main ways
to set AVCodecParameters.extradata: A generic way via CodecPrivate
(possibly with an offset) and by allocating a buffer manually;
the pointer to this buffer is stored in a stack pointer.
In particular, the latter method is problematic, as the buffer
needs to be freed manually in case of error (currently there
are no error conditions between the place where it is set
to AVCodecParameters.extradata).
Most of these buffers are very small (<= 22B), so replace
the pointer to an allocated buffer with a stack buffer
and set the extradata directly for the one place where
the buffer may not be small.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
In order to send VP9 tracks with FLV or RTMP, the enhanced RTMP
specification tells that VPCodecConfigurationRecord, a.k.a. vpcC
ISO-BMFF box, must be inserted into a metadata message. However, the
function responsible for generating vpcCs currently returns invalid
boxes, that are lacking the Version and Flag fields, inherited from
FullBox. For some reason, both flags were being added manually in
movenc. This patch fixes the issue.
Signed-off-by: Alessandro Ros <aler9.dev@gmail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
winbase.h defines IGNORE and is included via bzlib.h when compiling
for Windows. So rename this macro to NOTHING.
Also rename the muxer macro for consistency.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It includes various Windows-specific headers when compiling
for Windows and these sometimes cause issues: E.g. winbase.h
defines IGNORE, which clashes with a macro used in the Matroska
muxer (since 884653ee5b) and demuxer.
This header provides fallback defines for various stuff that is
mostly not used directly by (de)muxers at all:
mkdir, rename, rmdir, unlink, access, poll, pollfd, nfds_t,
closesocket, socklen_t, fstat, stat, lseek, SHUT_(RD|WR|RDWR)
and various POLL* constants.
Ergo fix this issue by not auto-including this header in lots
of places via an inclusion in internal.h and instead include
it everywhere where the above stuff is used (most of these
translation units already included os_support.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This simplification reduces codesize.
(It even reduces the size of .rodata here, because
the jump table used by the compiler is bigger than
the actual array.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When muxing, the AVStreams' side-data is typically set
by the caller before avformat_write_header();
it is not documented to be else. Yet the Matroska muxer
added an AVStereo3D side data if certain metadata
was present:
Since commit 4d686fb721
(adding support for AVStereo3D stream side-data),
the Matroska muxer checked certain stream tags that
contain Matroska's StereoMode and (if they are present)
converted this value into an AVStereo3D struct that
gets attached to the AVStream (reusing a function from
the demuxer). Afterwards the AVStereo3D side data struct
(whether it has just been added by the muxer or not) gets
parsed and converted back into a Matroska StereoMode.
Besides being an API violation this change broke
StereoMode values without a corresponding AVStereo3D
(namely the anaglyph ones).
This commit fixes this: A StereoMode given via tags
is now used-as-is; if no such tag exists and an AVStereo3D
side data exists, it is converted into the corresponding
StereoMode (if possible). This approach also fixes
handling of the anaglyph ones; the changes to the
matroska-stereo_mode are due to this.
The new STEREOMODE_STEREO3D_MAPPING has been put to
good use for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will allow to create tables for easy conversion from AVStereo3D
to stereomode and back again as well as derive the properties
of a given stereomode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has undefined behaviour in case the value does not fit into an int.
Also stop allowing to override a stream level "alpha_mode" tag
by an AVFormatContext one and properly check that the stereo_mode
number given via a tag is actually in the range 0..14: Negative
values would have been treated as zero before this patch.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the marker writing code was merged from libav to FFmpeg
in dc62016c, it failed to take into account that the meaning of
cluster_pos had changed in bda5b662; in particular, the special
value for “I'm not currently working on a cluster” had changed
from 0 to -1. This makes the avio_write_marker() call never
be called. Update the if statement to fix it.
Fixes: Ticket9843
Signed-off-by: Steinar H. Gunderson <steinar+ffmpeg@gunderson.no>
Signed-off-by: Martin Storsjö <martin@martin.st>
This prevents code duplication in the source form by calling the parse
code that was moved to avcodec last commit. The code will be duplicated
in binary form for shared builds (it's not that large), but for source
code it will only exist in one location now.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
because the flv specification said the video frametype
should use value range from 0x00 to 0x70,
so use 0xF0 have no problem before support enhanced flv,
but the 0xF0 will get incorrect result after support enhanced flv,
so should set the video frametype mask 0x70 to make it correct now.
Reported-By: flvAnalyser <hybase@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Writing the duration SimpleTag is special: It's size is
reserved in advance via an EBML Void element (if seekable)
and this reserved space is overwritten when writing the trailer;
it does not use put_ebml_string().
The string to write is created via snprintf on a buffer
of size 20; this buffer is then written via put_ebml_binary()
with a size of 20.
EBML strings need not be zero-terminated; if not, they
are implicitly terminated by the element's length field.
snprintf() always zero-terminates the buffer, i.e.
the last byte can be discarded when using an EBML string.
This patch does this.
The FATE changes are as expected: One byte saved for every
track; the only exception is the matroska-qt-mode test:
An additional byte is saved because an additional byte
could be saved from the enclosing Tags length field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do it only for video (the only thing for type for which HDR10+
makes sense).
This effectively reverts changes to several FATE ref-files
made in bda44f0f39.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Pass it as void* instead. While just at it, also constify
the pointee of AVDOVIDecoderConfigurationRecord* in
ff_isom_put_dvcc_dvvc().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These two AVIOContexts currently coincide, but this is not
guaranteed to remain so (in fact, I have plans to write each
TrackEntry into its own AVIOContext).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only WebVTT which is special in WebM; hypothetical future
subtitle codecs in WebM will presumably use the ordinary code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The demuxer uses a extradata offset of 26, so we would need
to recreate the missing 26 bytes somehow in the muxer, but
we just don't. Remuxed files (like real/rv30.rm from the FATE-suite)
don't work due to missing extradata.
(The extradata offset also applies to RV40 and the extradata
is indeed lost upon remuxing, yet remuxing real/spygames-2MB.rmvb
works; our RV40 decoder does not use extradata at all.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
RV10 and RV20 are unsupported because creating the correct CodecPrivate
is unsupported (the demuxer uses a codecpriv_offset of 26, so one
would need to recreate the missing 26 bytes); COOK and SIPR are
unsupported, because Matroska uses a packetization mode that is
different from what FFmpeg uses in its packets (see
matroska_parse_rm_audio() in the demuxer).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
bda44f0f39 added code that
potentially added another BlockMore master and BlockAdditional
data as well as BlockAddID number, yet it bumped the number
of EBML elements by four instead of only three.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska supports orthogonal transformations (both pure rotations
as well as reflections) via its 3D-projection elements, namely
ProjectionPoseYaw (for a horizontal reflection) as well as
ProjectionPoseRoll (for rotations). This commit adds support
for this.
Support for this in the demuxer has been added in
937bb6bbc1 and
the sample used in the matroska-dovi-write-config8 FATE-test
includes a displaymatrix indicating a rotation which is now
properly written and read, thereby providing coverage for
the relevant code in the muxer as well as the demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Note: There is a slight difference in the handling of
the max_file_size option: The earlier code used it to mean
to limit the size of the buffer to allocate; the new code
treats it more literally as maximum size to read from
the input.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids including lavc/codec_desc.h everywhere and thereby
forces users to include it directly instead of lazily and potentially
unknowingly relying on indirect inclusions.
Also add the proper inclusion to libavformat/demux.c, one of the
two files that actually use the new field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code currently presumes that a return value of AVERROR(ENOMEM)
implies that ac3hdr could not be allocated, so it need not be freed.
Yet any avpriv_ac3_parse_header() might allocate more than the
AC3HeaderInfo internally (it doesn't currently), so simply free
it unconditionally.
Fixes Coverity issues #1492870 and #1492868.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Change some internal APIs a bit to make it harder to make
such mistakes.
In particular, have the read chunk functions return an error
when the result is incomplete.
This might be less flexible, but since there has been no
use-case for that so far, avoiding coding mistakes seems better.
Add a function to queue a AVBPrint directly (ff_subtitles_queue_insert_bprint).
Also fixes a leak in lrcdec when ff_subtitles_queue_insert fails.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The contents are full TTML XML documents. TTML writing tests'
results are updated as the streams are now properly identified
as TTML ones.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
The size offset was previously being accounted for in flv_set_video_codec
for h264 and mpeg4, instead of being directly accounted for in the spot
where its read, which desynced on HEVC streams.
For clarity, move the size offset directly to the parsing, similar to
how its done for all other header fields.
Fixes: division by zero
Fixes: 57828/clusterfuzz-testcase-minimized-ffmpeg_dem_RKA_fuzzer-6571818338353152
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I cannot find the spec, but according to the original commit
d4fdba0df7, it's CAVS. e571305a71 changed it to AVS by
accident. Ten years on, nothing happened. We still have the
sample [1], however, since there is no cavs_mp4tofoobar bsf, the
cavs decoder doesn't work. I don't know if there is any use case.
[1] https://samples.ffmpeg.org/AVS/AVSFileFormat/AVSFileFormat.mp4
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
av_random_bytes() can use OS provided strong random functions and does not
depend soley on openssl/gcrypt external libraries.
Fixes ticket #10441.
Signed-off-by: Marton Balint <cus@passwd.hu>
Should set "number of frames" to bytes 24-27 of IVF header, not
duration.
It is described by [1], and confirmed by parsing all IVF files in [2].
This commit also updates the md5sum of refs to pass fate-cbs.
[1] Duck IVF - MultimediaWiki
https://wiki.multimedia.cx/index.php/Duck_IVF
[2] webm/vp8-test-vectors
https://chromium.googlesource.com/webm/vp8-test-vectors
Signed-off-by: Jianhui Dai <jianhui.j.dai@intel.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Fixes potential use of uninitialized values
in evc_read_nal_unit_length().
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For uint8_t buf[EVC_NALU_LENGTH_PREFIX_SIZE], &buf still points
to the beginning of buf, but it is of type "pointer to array of
EVC_NALU_LENGTH_PREFIX_SIZE uint8_t" (i.e. pointer arithmetic
would operate on blocks of size EVC_NALU_LENGTH_PREFIX_SIZE).
This is of course a different type than uint8_t*, which is why
there have been casts in evc_read_packet(). But these are unnecessary
if one justs removes the unnecessary address-of operator.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Content-Type can include charset and boundary which is not a part of
mime type and shouldn't be copied as such.
Fixes HLS playback when the Content-Type includes additional fields.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The discrepancy between the definition and the declaration
in allformats.c is actually UB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add demuxer to probe raw vvc and parse vvcc byte stream format.
Co-authored-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This partially reverts commit d0fc1b3507, which reintroduced a regression
originally fixed in 5e9986fd2d.
Signed-off-by: James Almer <jamrial@gmail.com>
mov_try_read_block() allocates 1MB at least, which can be more than
enough. It was called when reading saiz box, which can appear
periodically inside fmp4. This consumes a lot of memory.
We can fix mov_try_read_block() by clamp 'block_size' with 'size'.
However, the function is harmful than helpful. It avoids allocating
large memory when the real data is small. Even in that case, if
allocating large memory directly failed, it's fine to return ENOMEM;
if allocating success and reading doesn't match the given size, it's
fine to free and return AVERROR_INVALIDDATA. In other cases, it's a
waste of CPU and memory.
So I decided to remove the function, and replace it by call
av_malloc() and avio_read() directly.
mov_read_saiz() and mov_read_pssh() need more check, but they don't
belong to this patch.
Fixes#7641 and #9243.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
But ensure the value returned by evc_read_nal_unit_length() fits in an int.
Should prevent integer overflows later in the code.
Signed-off-by: James Almer <jamrial@gmail.com>
Before the introduction of AV_CODEC_ID_TIMED_ID3 for timed_id3 metadata streams
in mpegts (commit 4a4437c0fb), AV_CODEC_ID_SMPTE_KLV
was the only existing codec for metadata.
It seems that this codec has a 5-bytes metadata header[1] that, for some reason,
was always skipped when decoding data packets.
However, when working with a AV_CODEC_ID_TIMED_ID3 streams, this results in the
5 first bytes of the payload being cut-off, which includes essential informations
such as the ID3 tag version.
This patch fixes the issue by keeping the 5-bytes skip only for AV_CODEC_ID_SMPTE_KLV
streams.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array read
Fixes: 59828/clusterfuzz-testcase-minimized-ffmpeg_dem_JPEGXL_ANIM_fuzzer-5029813220671488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Incrementing a NULL pointer is undefined behaviour,
yet this is what would happen in case trailer were NULL
before the check.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In ff_rtp_send_jpeg, the type is defined based on PIX_FMT and
color-range parsed in. There is limitation on current design
where need to include support newly introduced PIX_FMT such as
AV_PIX_FMT_QSV and there might be more and more in future. Hence,
retrive the sampling factor from SOF0 in JPEG compressed header
directly. This introduces flexibility to handle different type of
new codec introduced in future.
Signed-off-by: Yeoh, Hoong Tee <hoong.tee.yeoh@intel.com>
This switches the jpegxl_collect_codestream_header function to use
avcodec/bytestream2, which better enforces barriers, and should avoid
overrunning buffers with jxlp boxes if the size is zero or if the size
is so small the box is invalid.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
- Changes in mov_write_video_tag function to handle EVC elementary stream
- Provided structure EVCDecoderConfigurationRecord that specifies the decoder configuration information for ISO/IEC 23094-1 video content
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
