Preparation for metadata changes in the following patches. Saves
having to create an extra buffer.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The refactoring in 844890b1bc caused
fate-source to point out that this could be av_clip_uintp2 (or
rather av_clip_uint8).
Signed-off-by: Martin Storsjö <martin@martin.st>
High color 15-bit VQA3 video streams contain high level chunks with
only codebook updates that shouldn't be considered new frames. Now
the demuxer stores a reference to such VQFL chunks and returns them
later along with a VQFR chunk with full frame data.
correct implementation of 'cenc' encryption scheme to support
decryption of partial cipher blocks at the end of subsamples
https://www.iso.org/standard/68042.html
Signed-off-by: Nachiket Tarate <nachiket.programmer@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
These will be used by HLS demuxer in case of sample decryption.
Signed-off-by: Nachiket Tarate <nachiket.programmer@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Fixes: OOM
Fixes: 39798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GEM_fuzzer-5611636853964800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 39736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARGO_fuzzer-4820016722214912
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 723c37d3b7.
Said commit was in preparation for auto-inserting the idet filter.
This has never happened; even if it did, the code is wrong, because
it segfaults if the filter instance doesn't have a name (having one
is not mandatory). Furthermore, it is documented for libavfilter to
not assign any semantics to the name, which this check violates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
I spotted an interesting pattern that I didn't see before that leads to the implementation being faster.
The bit shifting table I was using before is no longer needed, and was able to remove quite a few lines.
I also add use of FMA on the AVX2 version.
f32 1920x1080 1 thread with prelut
c impl
1434012700 UNITS in lut3d->interp, 1 runs, 0 skips
1434035335 UNITS in lut3d->interp, 2 runs, 0 skips
1423615347 UNITS in lut3d->interp, 4 runs, 0 skips
1426268863 UNITS in lut3d->interp, 8 runs, 0 skips
sse2
905484420 UNITS in lut3d->interp, 1 runs, 0 skips
905659010 UNITS in lut3d->interp, 2 runs, 0 skips
915167140 UNITS in lut3d->interp, 4 runs, 0 skips
915834222 UNITS in lut3d->interp, 8 runs, 0 skips
avx
574794860 UNITS in lut3d->interp, 1 runs, 0 skips
581035090 UNITS in lut3d->interp, 2 runs, 0 skips
584116720 UNITS in lut3d->interp, 4 runs, 0 skips
581460290 UNITS in lut3d->interp, 8 runs, 0 skips
avx2
301698880 UNITS in lut3d->interp, 1 runs, 0 skips
301982880 UNITS in lut3d->interp, 2 runs, 0 skips
306962430 UNITS in lut3d->interp, 4 runs, 0 skips
305472025 UNITS in lut3d->interp, 8 runs, 0 skips
gbrap16 1920x1080 1 thread with prelut
c impl
1480894840 UNITS in lut3d->interp, 1 runs, 0 skips
1502922990 UNITS in lut3d->interp, 2 runs, 0 skips
1496114307 UNITS in lut3d->interp, 4 runs, 0 skips
1492554551 UNITS in lut3d->interp, 8 runs, 0 skips
sse2
980777180 UNITS in lut3d->interp, 1 runs, 0 skips
986121520 UNITS in lut3d->interp, 2 runs, 0 skips
986489840 UNITS in lut3d->interp, 4 runs, 0 skips
998832248 UNITS in lut3d->interp, 8 runs, 0 skips
avx
622212360 UNITS in lut3d->interp, 1 runs, 0 skips
622981160 UNITS in lut3d->interp, 2 runs, 0 skips
645396315 UNITS in lut3d->interp, 4 runs, 0 skips
641057075 UNITS in lut3d->interp, 8 runs, 0 skips
avx2
321336400 UNITS in lut3d->interp, 1 runs, 0 skips
321268920 UNITS in lut3d->interp, 2 runs, 0 skips
323459895 UNITS in lut3d->interp, 4 runs, 0 skips
324949967 UNITS in lut3d->interp, 8 runs, 0 skips
This gets rid of of rist_receiver_data_read, rist_receiver_data_block_free and rist_parse_address
these functions have been deprecated since librist release v0.2.1 and are replaced with functions
suffixed with 2.
I added a version macro check at the top of the file to ensure ffmpeg can still be compiled against
older versions.
Signed-off-by: Gijs Peskens <gijs@peskens.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
The maximum allowed useful PES payload data was set to PES_packet_length, but
it is in fact smaller by the length of the PES header.
This changes how corrupt streams are packetized:
- If PES header length is bigger than PES_packet_length then the PES packet
payload will be handled as an unbound packet
- PES packets with payload across multiple MPEGTS packets will always be
splitted if with the next chunk of data the payload should exceed
PES_packet_length, previously a PES_header_length amount of excess was
allowed.
Fixes ticket #9355.
Signed-off-by: Marton Balint <cus@passwd.hu>
This renames PESContext->total_size to PESContext->PES_packet_length and keeps
it 0 for unbound packets, so its name and semantics will match the standard.
There should be no change in functionality.
Signed-off-by: Marton Balint <cus@passwd.hu>
(Inside a function a stray ';' is an empty statement; outside of
a function it is actually invalid, but compilers happen to accept
it without complaint (unless e.g. using -pedantic).)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The voice registration system in libflite is broken: It is not
thread-safe and also not based on internal counters; instead
any call to unregister a voice frees said voice even if there are still
many other users of said voice who have also registered said voice.
While there is no way to guard against another library unregistering
voices behind our back, we can at least be correct in the absence of
other users of libflite. The current code already tried this by using
a reference count of our own for each voice; but the implementation
of this is not thread-safe at all.
Fix this by using a mutex to guard all of libavfilter's libflite
registration and unregistration calls, thereby being thread-safe
in the absence of other libflite users.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When an flite filter instance is uninitialized and the refcount
of the corresponding voice_entry reaches zero, the voice is
unregistered, yet the voice_entry's pointer to the voice is not reset.
(Whereas some other pointers are needlessly reset.)
Because of this a new flite filter instance will believe said voice
to already be registered, leading to use-after-frees.
Fix this by resetting the right pointer instead of the wrong ones.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Could also happen if initializing flite failed* or if an unknown voice
has been selected or if registering the voice failed.
*: which it currently can't, because it is a no-op.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
