- 21 May, 2020 10 commits
-
-
Michael Niedermayer authored
Fixes: division by zero Fixes: 21677/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSD_MSBF_fuzzer-5712547983654912 Fixes: 21751/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSD_LSBF_fuzzer-5197097180856320 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: signed integer overflow: -1238335488 + -1003634688 cannot be represented in type 'int' Fixes: 21649/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-5112005765890048 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: signed integer overflow: -717241856 + -1434459904 cannot be represented in type 'int' Fixes: 21405/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5677143666458624 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: Timeout Fixes: 21104/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5129580475318272 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: signed integer overflow: -9223372036854775808 - 45000 cannot be represented in type 'long' Fixes: ticket8187 Found-by: Suhwan Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: signed integer overflow: 30000299 * 256 cannot be represented in type 'int' Fixes: ticket8184 Found-by: Suhwan Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
This should improve coverage Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: out of array access Fixes: stack-buffer-overflow-READ-0x0831fff1 Found-by: GalyCannon <galycannon@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
The limit is based on hevcdec.c Fixes: 20854/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5160442882424832 Fixes: out of array access Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
The TTA muxer writes a seektable in a dynamic buffer as it receives packets and when writing the trailer, closes the dynamic buffer using avio_close_dyn_buf(), writes the seektable and frees the buffer. But the TTA muxer already has a deinit function which unconditionally calls ffio_free_dyn_buf() on the dynamic buffer, so switching to avio_get_dyn_buf() means that one can remove the code to free the buffer; furthermore, it also might save an allocation if the seektable is so small that it fits into the dynamic buffer's write buffer or if adding the padding that avio_close_dyn_buf() adds necessitated reallocating of the underlying buffer. Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 20 May, 2020 8 commits
-
-
Andreas Rheinhardt authored
ff_id3v2_free_extra_meta() takes a ID3V2ExtraMeta ** so that it can already reset the pointer. Reviewed-by: Jun Zhao <mypopy@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
A buffer whose size is not a multiple of four has been initialized using consecutive writes of 32bits. This results in a stack-buffer-overflow reported by ASAN in the checkasm-sw_scale FATE-test. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Mark Thompson authored
If the RPS we are predicting from has maximum size then at least one of the pictures in it must be discarded before adding the current one. Also revert 588114ce, which added now-redundant checks for the special case of a too-large RPS with all pictures being in the same direction from the current one.
-
Martin Storsjö authored
Sticking a full frame in the extradata works, as the code for writing the avcC/hvcC extracts the relevant parameter set NAL units - provided that they actually exist in the frame. Some encoders don't provide split out extradata directly on init (or at all). In particular, the MediaFoundation encoder wrapper doesn't always (depending on the actual encoder device) - this is the case for Qualcomm's HEVC encoder on SD835, and also on some QSV H264 encoders). This only works for cases where the moov hasn't already been written (e.g. when not writing fragmented mp4 with empty_moov, unless using the delay_moov option). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Dale Curtis authored
2d8d554f added a new error condition to mov_read_stsz() but forgot to free a temporary buffer when it occurs. Signed-off-by: Dale Curtis <dalecurtis@chromium.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Zane van Iperen authored
single: Single-track track{0,1}: Dual-track trunc-t1: Truncated track 1 trunc-t2-track{0,1}: Fully-truncated track 2 trunc-t2a-track{0,1}: Partially-truncated track 2 trunc-h2: Truncated track 2 header Signed-off-by: Zane van Iperen <zane@zanevaniperen.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Mark Reid authored
changes since v1 - default behavior, no longer hidden behind decoder parameter - updated tests to reflect change Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
Properly unwrap phase.
-
- 19 May, 2020 17 commits
-
-
James Almer authored
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
wm4 authored
This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3. This is based on top of an original patch by wm4 <nfxjfg@googlemail.com>. The original patch supported both encoding and decoding, but this patch only includes encoding. The patch contains further changes by Paweł Wegner <pawel.wegner95@gmail.com> (primarily for splitting out the encoding parts of the original patch) and further cleanup, build compatibility fixes and tweaks for use with Qualcomm encoders by Martin Storsjö. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
Also fixes colorhold filtering.
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Steven Liu authored
because it need be check for success, is should not change the old way if it failure. fix ticket: 8674 Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
-
Andreas Rheinhardt authored
The Matroska muxer has always mapped the title tag to the FileDescription element for attachments streams since support for writing attachments was added in commit c7a63a52. This commit merely documents this fact. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Each AttachedFile in Matroska can have a FileDescription element that contains a human-friendly name for the attached file; yet this element has been ignored up until now. This commit changes this and exports it as title tag instead (the Matroska muxer mapped the title tag to the AttachedFile element since support for Attachments was added). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska muxer writes the Chapters early when chapters were already available when writing the header; in this case any tags pertaining to these chapters get written, too. Yet if no chapters had been supplied before writing the header, Chapters can also be written when writing the trailer if any are supplied. Tags belonging to these chapters were up until now completely ignored. This commit changes this: Writing the tags belonging to chapters has been moved to mkv_write_chapters(). If mkv_write_tags() has not been called yet (i.e. when chapters are written when writing the header), the AVIOContext for writing the ordinary Tags element is used, but not output, as this is left to mkv_write_tags() in order to only write one Tags element. Yet if mkv_write_tags() has already been called, mkv_write_chapters() will output a Tags element of its own which only contains the tags for chapters. When chapters are available initially, the corresponding tags will now be the first tags in the Tags element; but the ordering of tags in Tags is irrelevant anyway. This commit also makes chapter_id_offset local to mkv_write_chapters() as it is used only there and not reused at all. Potentially writing a second Tags element means that the maximum number of SeekHead entries had to be incremented. All the changes to FATE result from the ensuing increase in the amount of space reserved for the SeekHead (21 bytes more). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
This is needed so that it can access mkv_write_tag() and mkv_check_tag() without using forward declarations (which are unnecessary here). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Up until now, the Matroska muxer writes only one Tags level 1 element and therefore using a certain place to store the dynamic buffer used for writing it was hardcoded; yet the Matroska specifications allow an unlimited amount of Tags elements and we have reason to write a second one: If chapters are provided after writing the header, they are written when writing the trailer; yet the corresponding tags are ignored. This can be fixed by writing them in a second Tags element. Also use a MatroskaMuxContext * instead of an AVFormatContext * as parameter in mkv_write_tag() and mkv_write_tag_targets() as that is all these functions use. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Mostly reindentation after the last commit. Also remove a variable that is always zero; move another variable to a more local scope and don't assign a value to a local variable immediately before leaving the function. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
in mkv_write_stereo_mode(). Also check the size of the AVStereo3D side data. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
It can't fail since 9c8aa868. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Mainly reindentation plus some reordering in MatroskaMuxContext; moreover, use the IS_SEEKABLE() macro troughout the code. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 18 May, 2020 5 commits
-
-
Andreas Rheinhardt authored
EBML numbers are variable length numbers: Only seven bits of every byte are available to encode the number, the other bits encode the length of the number itself. So an eight byte EBML number can only encode numbers in the range 0..(2^56 - 1). And when using EBML numbers to encode the length of an EBML element, the EBML number corresponding to 2^56 - 1 is actually reserved to mean that the length of the corresponding element is unknown. And therefore put_ebml_length() asserted that the length it should represent is < 2^56 - 1. Yet there was nothing that actually guaranteed this to be true for the Segment (the main/root EBML element of a Matroska file that encompasses nearly the whole file). This commit changes this by checking in advance how big the length is and only updating the number if it is representable at all; if not, the unknown length element is not touched. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska muxer has a pair of functions designed to write master elements whose exact length is not known in advance: start_ebml_master() and end_ebml_master(). The first one of these would write the EBML ID of the master element that is about to be started, reserve some bytes for the length field and record the current position as well as how many bytes were used for the length field. When writing the master's contents is finished, end_ebml_master() gets the current position (at the end of the master element), seeks to the length field using the recorded position, writes the length field and seeks back to the end of the master element so that one can continue writing other elements. But if one wants to modify the content of the master element itself, then the seek back is superfluous. This is the scenario that presents itself when writing the trailer: One wants to update several elements contained in the Segment master element (this is the main/root master element of a Matroska file) that were already written when writing the header. The current approach is to seek to the beginning of the file to update the elements, then seek to the end, call end_ebml_master() which immediately seeks to the beginning to write the length and seeks back. The seek to the end (which has only been performed because end_ebml_master() uses the initial position to determine the length of the master element) and the seek back are of course superfluous. This commit avoids these seeks by no longer using start/end_ebml_master() to write the segment's length field. Instead, it is now written manually. The new approach is: Seek to the beginning to write the length field, then update the elements (in the order they appear in the file) and seek back to the end. This reduces the ordinary amount of seeks of the Matroska muxer to two (ordinary excludes scenarios where one has big Chapters or Attachments or where one writes the Cues at the front). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
If the AVIOContext for output was unseekable when writing the header, no space for Cues would be reserved even if the reserve_index_space option was used (because it is reasonable to expect that one can't seek back to the beginning to write the Cues anyway). But if the AVIOContext was seekable when writing the trailer, it was presumed that space for the Cues had been reserved when the reserve_index_space option indicated so even when it was not. As a result, the beginning of the file would be overwritten. This commit fixes this: If the reserve_index_space option had been used and no space has been reserved in advance because of unseekability when writing the header, then no attempt to write Cues will be performed when writing the trailer; after all, writing them at the front is impossible and writing them at the end is probably undesired. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
We won't be able to seek back to write the actual duration anyway. FATE-tests using the md5pipe command had to be updated due to this change. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska muxer behaves differently in several ways when it thinks that it is in unseekable/livestreaming mode: It does not add Cue entries because they won't be written anyway for a livestream and it writes some elements only preliminarily (with the intention to overwrite them with an updated version at the end) when non-livestreaming etc. There are two ways to set the Matroska muxer into livestreaming mode: Setting an option or by providing an unseekable AVIOContext. Yet the actual checks were not consistent: If the AVIOContext was unseekable and no AAC extradata was available when writing the header, writing the header failed; but if the AVIOContext was seekable, it didn't, because the muxer expected to get the extradata via packet side-data. Here the livestreaming option has not been checked, although one can't use the updated extradata in case it is a livestream. If the reserve_index_space option was used, space for writing Cues would be reserved when writing the header unless the AVIOContext was unseekable. Yet Cues were only written if the livestreaming option was not set and the AVIOContext was seekable (when writing the trailer), so if the AVIOContext was seekable and the livestreaming option set, the reserved space would never be used at all. If the AVIOContext was unseekable and the livestreaming option was not set, it would be attempted to update the main length field at the end. After all, it might be possible that the file is so short that it fits into the AVIOContext's buffer in which case the seek back would work. Yet this is dangerous: It might be that we are not dealing with a simple output file, but that our output gets split into chunks and that each of these chunks is actually seekable. In this case some part of the last chunk (namely the eight bytes that have the same offset as the length field had in the header) will be overwritten with what the muxer wrongly believes to be the filesize. (The livestreaming option has been added to deal with this scenario, yet its documentation ("Write files assuming it is a live stream.") doesn't make this clear at all. At least the segment muxer does not set the option for live and given that the chances of successfully seeking when the output is actually unseekable are slim, it is best to not attempt to update the length field in the unseekable case at all.) All these inconsistencies were fixed by treating the output as seekable if the livestreaming option is not set and if the AVIOContext is seekable. A macro has been used to enforce consistency and improve code readability. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-