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>
