Right now it is possible for the pointer for the current frame to
be set in the context even when it could not be properly set up;
this does not influence the ordinary ref frames, but only
VP8Context.prev_frame. And since this code has been ported to the
ProgressFrame API in d48d7bc434f30dfbdf346f16715e4f2044b3e000,
this leads to segfaults, because the ProgressFrame API is less
forgiving than the ThreadFrame API (waiting on an uninitialized
ProgressFrame segfaults, waiting on an uninitialized ThreadFrame
is a no-op (the code behaves as if frame-threading is not in use)).
Fix this by maintaining the consistency of the frame pointers
in the context (by setting them later).
Fixes: NULL pointer dereference
Fixes: 68192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP8_fuzzer-6180311026171904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids a potential overflow when multiplying nb_colors by 6.
Also make the nb_colors check a bit more strict.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is written as region_id which is a single byte.
Also fixes a potential (defined) overflow in the num_rects * 6
multiplication later; this has been found by 김승호 <kimsho98@naver.com>.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have already calculated the size of the packet
and therefore don't need to rely on these implicit checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This can be easily done because we have a count of the number of
values and the length of the associated codes. This allows
to switch to ff_get_encode_buffer() and thereby avoids an implicit
intermediate buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that we can calculate the size of each slice in advance,
we can determine the position in the output packet where it
needs to be put and can therefore avoid the intermediate buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code only used the counts from the last slice.
The two FATE tests using slices show compression improvements
due to this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Every frame contains an array of uint8_t with values
0..(s->planes * s->nb_slices - 1), so this needs to fit
into an uint8_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do not derive it via av_cpu_count() in case AVCodecContext.slices
is unset. Instead default to AVCodecContext.thread_num instead
(which is one in case frame-threading is used and gives the actual
number of slice threads for slice threading).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Vulkan's main issue around using BGR is simple.
The letters in the shader don't match up (rgba in shader, bgra in format).
So of course, rather than allowing "bgra" or other permutations of
formats in the shader, they went the nuclear option and spent months writing
an extension to get rid of the need to have a format in the shader to begin
with.
All this to solve a problem that should never have existed to begin with.
This fixes BGRA images since enabling WithoutFormat, as the GPU now remaps
without your involvement.
Seeing the offset of video and audio streams to each other is often
a useful metric in diagnosing and understanding issues with playback
or transcoding.
This commit adds those offsets to the stream info print.
Signed-off-by: softworkz <softworkz@hotmail.com>
The previous code expected a segment of type CLUT definition to exist
in order to accept a set of segments to be complete.
This was an incorrect assumption as the presence of a CLUT segment
is not mandatory.
(version 1.6.1 of the spec is probably a bit more clear about this
than earlier versions: https://www.etsi.org/deliver/etsi_en/
300700_300799/300743/01.06.01_20/en_300743v010601a.pdf)
The incorrect condition prevented proper fallback to using the default
resolution for the decoding context.
This also adds variables and moves the fallback check to the outside
for better clarity.
Signed-off-by: softworkz <softworkz@hotmail.com>
This add support for WebVTT subtitles in HLS streams.
Just like for separate audio streams, it supports all available
WebVTT streams in all renditions.
No new options are added, it just works and provides subtitles streams
like any other demuxer.
The code prevents downloading subtitle segments which are farther
in the future than the main segments, to avoid loading hundreds
of subtitle segments in advance.
Signed-off-by: softworkz <softworkz@hotmail.com>
In filtering, and SDR encoding, we use storage images.
This fixes using Vulkan filters on Intel.
Tested not to break anything on the three major vendors.
This implements support for reading and writing storage images with
no format.
The issue is that we define our images as arrays, and arrays can
only have a single type, which means that f.ex. NV12 needs two
different images, R8 and RG8.
The only driver known not to advertise support for the extension
as a whole is Intel, because they have parial support for odd formats
we never use. Therefore, just always enable it by default.
It is unnecessary, as we already have the entries sorted by
probability and therefore implicitly by length. All we need
on top of that to build the tree is the number of entries
of a given length.
Doing so gives a 3.6% speedup of ff_mjpeg_encode_huffman_close()
here; it also saves about 640B of .text here.
The new code puts values with higher probability to the left
of the tree. The old code did not and therefore
the FATE checksums needed to be updated. Due to MJPEG's
0xFF unescaping file sizes as well as file checksums
needed to be updated; the decoded picture hashes stayed
the same. Given that codes on the left of the tree have
on average fewer bits set than codes on the right, the
file sizes mostly improve (all except vsynth3-mjpeg-444).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We violated the spec, which, despite the actual command buffer pool
*not* being involved in any functions which require external synchronization
of the pool, *require* external synchronization even if only the
command buffers are used.
This also has the effect of *significantly* speeding up execution
in case command buffers are contended.
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d6dcd520e781754d986e9907d74270e
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
We currently populate the color encoding bundle and then check to see
if there's an ICC profile to attach, and set the color encoding bundle
in either case. The ICC profile overrides the color encoding bundle, so
we should not calculate enum-based color encoding if we have an ICC
profile present. Fixes several unnecessary warnings from being emitted.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
see: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance
but in short, first our API since 16years says we dont have multiple values per key
(which it supports since 9 years only)
and it causes some problems for ffprobe apparently.
I do believe the original patch is the correct direction but it requires
more changes. So revert this until other things are in place and until
we have a consensus.
This reverts commit 80b77e8e8d0630710ad6069133f397459015f139.
fix ticket #11531
the rtsp aac did not marked keyframe which cannot easy copy to output.
because f265f9c9d04863180503707bfad285f48e6bf080 commit change the AAC props to match xHE-AAC.
in some formats like MOV, need_parsing is set, so AAC can be still parsed be keyframe
but rtsp did not, so this patch add it
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
