- 19 May, 2020 4 commits
-
-
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 10 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>
-
Andreas Rheinhardt authored
If the Matroska muxer's AVIOContext was unseekable when writing the header, but is seekable when writing the trailer, the code for writing the trailer presumes that a dynamic buffer exists and tries to update its content in order to overwrite data that has already been preliminarily written when writing the header, yet said buffer doesn't exist as it has been written finally and not preliminarily when writing the header (because of the unseekability it was presumed that one won't be able to update the data anyway). This commit adds a check for this and also for a similar situation involving updating extradata with new data from packet side-data. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
James Almer authored
It's the correct dedicated capability reported by supported encoders. Otherwise, the frame thread path will be used for unsupported encoders like r210 for no gain. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: James Almer <jamrial@gmail.com>
-
Linjie Fu authored
Enables HEVC Range Extension encoding support (Linux) for 4:2:2 8/10 bit on ICL+ (gen11 +) platform. Restricted to linux only for now. Signed-off-by: Linjie Fu <linjie.fu@intel.com>
-
Linjie Fu authored
Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit on ICL+ (gen11 +) platform. Restricted to linux only for now. Signed-off-by: Linjie Fu <linjie.fu@intel.com>
-
- 17 May, 2020 4 commits
-
-
Andreas Rheinhardt authored
The parsing process of the AVOpt-enabled string controlling the mapping of input streams to variant streams is roughly as follows: Space and tab separate variant stream group maps while the entries in each variant stream group map are separated by ','. The parsing process of each variant stream group proceeded as follows: At first the number of occurences of "a:", "v:" and "s:" in each variant stream group is calculated so that one can can allocate an array of streams with this number of entries. Then the string is split along ',' and each substring is parsed. If such a substring starts with "a:", "s:" or "v:" it is treated as stream specifier and (if there is a correct number after ':') a stream of the variant stream is mapped to one of the actual input streams. Nothing actually guarantees that the number of streams allocated initially equals the number of streams that are mapped to an actual input stream. These numbers can differ if e.g. the name, the sgroup, agroup or ccgroup of the variant stream contain "a:", "s:" or "v:". The problem hereby is that the rest of the code presumes these numbers to be equal and segfaults if it isn't (because the corresponding input stream is NULL). This commit fixes this by modifying the initial counting process to only count occurences of "a:", "s:" or "v:" that are at the beginning or that immediately follow a ','. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
Michael Niedermayer authored
This avoids accessing an old, no longer valid buffer. Fixes: out of array access Fixes: crash_audio-2020 Found-by: le wu <shoulewoba@gmail.com> Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Derek Buitenhuis authored
Prevents wrap-around to negative values while calculating the duration string. Before: Duration: -411422:-59:-42.17, start: 0.000000, bitrate: 0 kb/s After: Duration: 781623:28:34.17, start: 0.000000, bitrate: 0 kb/s Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
- 16 May, 2020 7 commits
-
-
Michael Niedermayer authored
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int' Fixes: 19950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-5765514337189888 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Suggested-by: Paul Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: memleak Fixes: 21784/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-565256551058636 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Gautam Ramakrishnan <gautamramk@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Martin Storsjö authored
This function doesn't call emms. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Andreas Rheinhardt authored
Call it directly from write_packets_common() instead of indirectly through prepare_input_packet(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
This commit stops using pkt->stream_index as index in an AVFormatContext's streams array before actually comparing the value with the count of streams in said array. 96e5e6ab used pkt->stream_index in prepare_input_packet() before checking and 64063512 did likewise in write_packets_common(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 15 May, 2020 15 commits
-
-
Martin Storsjö authored
This allows speeding up format conversions from yuv420 to nv12. Cortex A53 A72 A73 interleave_bytes_c: 86077.5 51433.0 66972.0 interleave_bytes_neon: 19701.7 23019.2 15859.2 interleave_bytes_aligned_c: 86603.0 52017.2 67484.2 interleave_bytes_aligned_neon: 9061.0 7623.0 6309.0 Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Cortex A53 A72 A73 get_pixels_c: 140.7 87.7 72.5 get_pixels_neon: 46.0 20.0 19.5 get_pixels_unaligned_c: 140.7 87.7 73.0 get_pixels_unaligned_neon: 49.2 20.2 26.2 diff_pixels_c: 209.7 133.7 138.7 diff_pixels_neon: 54.2 31.7 23.5 diff_pixels_unaligned_c: 209.7 134.2 139.0 diff_pixels_unaligned_neon: 68.0 27.7 41.7 Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Cortex A7 A8 A9 A53 A72 get_pixels_c: 144.7 146.0 143.0 137.7 69.0 get_pixels_armv6: 112.0 106.7 90.2 95.0 72.5 get_pixels_neon: 69.0 29.7 68.7 40.2 19.0 get_pixels_unaligned_c: 144.7 146.2 143.0 137.7 69.0 get_pixels_unaligned_neon: 77.0 36.5 72.5 48.5 19.0 diff_pixels_c: 376.7 319.7 265.5 307.7 148.0 diff_pixels_armv6: 179.0 159.5 205.5 139.0 142.0 diff_pixels_neon: 69.0 40.2 77.5 53.2 26.0 diff_pixels_unaligned_c: 376.7 319.7 265.5 307.7 148.0 diff_pixels_unaligned_neon: 85.0 54.5 93.5 66.7 26.0 Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Josh de Kock authored
The NEON hscale function only supports X8 filter sizes and should only be selected when these are being used. At the moment filterAlign is set to 8 but in the future when extra NEON assembly for specific sizes is added they will need to have checks here too. The immediate usecase for this change is making the hscale checkasm test easier and without NEON specific edge-cases (x86 already has these guards). This applies the same fix from 718c8f9a on the 32 bit arm version of the function, fixing fate-checkasm-sw_scale there. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Thierry Foucu authored
If you have a file with multiple Metadata Keys, the second time you parse the keys, you will re-alloc c->meta_keys without freeing the old one. This change will avoid parsing all the consecutive Metadata keys. Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Dale Curtis authored
Many places are using their own custom code for handling overflow around timestamps or other int64_t values. There are enough of these now that having some common saturated math functions seems sound. Signed-off-by: Dale Curtis <dalecurtis@chromium.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Dale Curtis authored
Signed-off-by: Dale Curtis <dalecurtis@chromium.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Martin Storsjö authored
Also fill x8-x17 with garbage before calling the function. Figure out the number of stack parameters and make sure that the value on the stack after those is untouched. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Figure out the number of stack parameters and make sure that the value on the stack after those is untouched. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
We should just use a normal bl here, and the linker will add the 'x' bit if necessary. This fixes calling the checkasm_fail_func on windows, where the code is built in thumb mode (and the linker doesn't clear the 'x' bit in the blx instruction). Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This makes it easier to share code with e.g. the dav1d implementation of checkasm. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
On windows and darwin (and modern android), the x18 register is reserved and shouldn't be modified by user code, while it is freely available on linux. Strictly avoid it, to keep the assembly code portable. This would have helped catch the issue fixed in 872790b1 immediately. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Marton Balint authored
This reverts commit 339593ca. Fixes null pointer dereference. Signed-off-by: Marton Balint <cus@passwd.hu>
-