- 18 May, 2020 8 commits
-
-
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 19 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>
-
Marton Balint authored
This reverts commit d88e1c98. Fixes null pointer dereference. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Josh de Kock authored
This tests the hscale 8bpp to 14/18bpp functions with different filter sizes. Signed-off-by: Josh de Kock <josh@itanimul.li>
-
Martin Storsjö authored
This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
-
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). Signed-off-by: Josh de Kock <josh@itanimul.li>
-
- 14 May, 2020 2 commits
-
-
Zachariah Brown authored
The h264_nvenc and hevc_nvenc encoders aren't respecting the framerate in the codec context. Instead it was using the timebase which in our use-case was 1/1000 so the encoder was behaving as if we wanted 1000fps. This resulted in poor encoding results due to an extremely low bitrate. Both the amf and qsv encoders already contain similar logic to first check the framerate before falling back to the timebase. Signed-off-by: Zachariah Brown <zachariah@renewedvision.com> Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
-
James Almer authored
It's not meant for audio or subtitles, or for encoders of any kind. Reviewed-by: mypopy@gmail.com <mypopy@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-