avcodec/v4l2_m2m_dec: remove redundant packet and fix double free
v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
the next call. Currently the ownership transfer between the two packets
is not properly handled. A double free occurs if
ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
returns EINVAL.
In fact, having two AVPackets is not needed and everything can be
handled by s->buf_pkt.
This commit removes the local avpkt from v4l2_receive_frame(), meaning
that the ownership transfer doesn't need to be handled and the double
free is fixed.
avformat/riffenc: indicate storage of flipped RGB bitmaps
Some legacy applications such as AVI2MVE expect raw RGB bitmaps
to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
they are always stored top-down and thus write a negative value
for height. This can prevent reading of these files.
Option flipped_raw_rgb added to AVI and Matroska muxers
which will write positive value for height when enabled.
Note that the user has to flip the bitmaps beforehand using other
means such as the vflip filter.
The number of declared vdpau formats can vary depending on which
version of libvdpau we build against, so the number of pix fmts
can vary too. Let's make sure we keep those numbers in sync.
Ben Clayton [Fri, 10 Jul 2020 15:53:12 +0000 (16:53 +0100)]
libavfilter/glslang: Remove unused header
The <glslang/Include/revision.h> include was not used, and revision.h has
been removed from glslang master.
See: https://github.com/KhronosGroup/glslang/pull/2277
No audio stream is created unconditionally and if none has been created,
no packet with stream_index 1 may be returned. This fixes an assert in
ff_read_packet() in libavformat/utils reported in ticket #8782.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/tiff: Check input space in dng_decode_jpeg()
Fixes: out of array read Fixes: 24034/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5111884337119232 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 86987846-429c8d80-c197-11ea-916b-bb4738e09687.jpg Fixes: Regression since ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/cbs_jpeg: Fix uninitialized end index in cbs_jpeg_split_fragment()
Fixes: Out of array read Fixes: 24043/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5084566275751936.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ManojGuptaBonda [Sat, 27 Jun 2020 13:34:22 +0000 (19:04 +0530)]
avcodec/hevcdec: Add VDPAU to list of supported formats
Added VDPAU to list of supported formats for HEVC10 and 12 bit formats
also added 42010 bit to surface_parameters and new VDP chroma formats to
VDPAUPixFmtMaps
Add HEVC 420 10/12 Bit and 444 10/12 Bit support for VDPAU
YUV444P10 is defined as the 444 surface with 10bit valid data in LSBs
but H/w returns Data in MSBs Hence if we map output as YUV444p16 it
is filtering out the LSB to convert to p10 format.
Signed-off-by: Philip Langdale <philipl@overt.org>
Limin Wang [Sat, 20 Jun 2020 13:09:09 +0000 (21:09 +0800)]
avcodec/h264_slice: add timecode metadata
Please test with below command:
./ffplay -vf drawtext="fontfile=/Library/Fonts/Arial.ttf:text=\\'%{metadata\\:timecode}\\'" \
../fate-suite/h264/crew_cif_timecode-2.h264
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
We return 0 for this particular architecture but should instead be
returning the number of lines.
Fixes users who check the return value matches what they expect.
avcodec/apedec: Fix undefined integer overflow with 24bit
Fixes: signed integer overflow: 8683744 * 256 cannot be represented in type 'int' Fixes: 23527/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5679885932822528 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/loco: Fix integer overflow with large values from loco_get_rice()
Fixes: signed integer overflow: 155 + 2147483647 cannot be represented in type 'int' Fixes: 23421/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LOCO_fuzzer-5652849097965568 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anton Khirnov [Tue, 9 Jun 2020 11:08:49 +0000 (13:08 +0200)]
pthread_frame: change the criterium for updating thread contexts
Currently the next thread's context is updated from the previous one's
if the codec descriptor is not marked as intra-only. That is not
entirely correct, since that property does not necessarily imply
anything about how a specific decoder implementation behaves.
Instead, use the presence of the update_thread_context() callback to
decide whether an update should be performed. Fixes races in CFHD,
should cause no behaviour change in any other decoders.
Important part of this algorithm is the double threshold step: pixels
above "high" threshold being kept, pixels below "low" threshold dropped,
pixels in between (weak edges) are kept if they are neighboring "high"
pixels.
The weak edge check uses a neighboring context and should not be applied
on the plane's border. The condition was incorrect and has been fixed in
the commit.
avcodec/h26[45]_metadata_bsf: Use separate contexts for reading/writing
Currently, both bsfs used the same CodedBitstreamContext for reading and
writing; as a consequence, the state of the writer's context at the
beginning of writing a fragment is exactly the state of the reader after
having read the fragment; in particular, the writer might not have
encountered one of its active parameter sets yet.
This is not nice and may lead to invalid output even when the input
is completely spec-compliant: Think of an access unit containing
a primary coded picture referencing a PPS with id id (that is known from
an earlier access unit/from extradata), then a new version of the PPS
with id id and then a redundant coded picture that is also referencing
the PPS with id id. This is spec-compliant, as the standard allows to
overwrite a PPS with a different PPS in between coded pictures and not
only at the beginning of an access unit. In this scenario, the reader
would read the primary coded picture with the old PPS and the redundant
coded picture with the new PPS (as it should); yet the writer would
write both with the new PPS as extradata which might lead to errors or
to invalid data being output without any error (e.g. if the two PPS
differed in redundant_pic_cnt_present_flag).
The above scenario does not directly translate to HEVC as long as one
restricts oneself to input with nuh_layer_id == 0 only (as cbs_h265
does: it currently strips away any NAL unit with nuh_layer_id > 0 when
decomposing); if one doesn't the same issue as above can happen.
If one also allowed input packets to contain more than one access unit,
issues like the above can happen even without redundant coded
pictures/multiple layers.
Therefore this commit uses separate contexts for reader and writer.
Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Oliver Woodman [Fri, 8 May 2020 02:09:29 +0000 (03:09 +0100)]
avcodec/h264: support sps/pps AV_PKT_DATA_NEW_EXTRADATA
Commit 601c238854 added support for AV_PKT_DATA_NEW_EXTRADATA, but
only for avcC extradata.
This commit adds support for sps/pps extradata as well. This makes
support consistent for passing new extradata consistent with the
types of extradata that can be passed when initializing the decoder.
Signed-off-by: Oliver Woodman <ollywoodman@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
avcodec/tiff: Check frame parameters before blit for DNG
Fixes: out of array access Fixes: 23888/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-6021365974171648.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/smacker: Don't read only one byte at a time
Instead use ffio_read_size to read data into a buffer. Also check that
the desired size was actually successfully read and combine the check
with the check for reading the extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A Smacker file can contain up to seven audio tracks. Up until now,
the pts for the i. audio packet contained in a Smacker frame was
simply the end timestamp of the last i. audio packet contained in
an earlier Smacker frame.
The problem with this is that a Smacker stream need not contain data in
every Smacker frame and so the current i. audio packet present may come
from a different underlying stream than the last i. audio packet
contained in an earlier frame.
The sample hypnotix.smk* exhibits this. It has three audio tracks and
the first of the three has a longer first packet, so that the audio for
the first track is contained in only 235 packets contained in the first
235 Smacker frames; the end timestamp of this track is 166696 (about 7.56s
at a timebase of 1/22050); the other two audio tracks both have 253 packets
contained in the first 253 Smacker frames. Up until now, the 236th
packet of the second track being the first audio packet in the 236th
Smacker frame would get the end timestamp of the last first audio packet
from the last Smacker frame containing a first audio packet and said
last audio packet is the first audio packet from the 235th Smacker frame
from the first audio track, so that the timestamp is 166696. In contrast,
the 236th packet from the third track (whose packets contain the same number
of samples as the packets from the second track) has a timestamp of
156116 (because its timestamp is derived from the end timestamp of the
235th packet of the second audio track). In the end, the second track
ended up being 177360/22050 s = 8.044s long; in contrast, the third
track was 166780/22050 s = 7.56s long which also coincided with the
video.
This commit fixes this by not using timestamps from other tracks for
a packet's pts.
avformat/smacker: Stop caching and copying audio frames
The layout of a Smacker frame is as follows: For some frames, the
beginning of the frame contained a palette for the video stream; then
there are potentially several audio frames, followed by the data for the
video stream.
The Smacker demuxer used to read the palette, then cache every audio frame
into a buffer (that gets reallocated to the desired size every time a
frame is read into this buffer), then read and return the video frame
(together with the palette). The cached audio frames are then returned
by copying the data into freshly allocated buffers; if there are none
left, the next frame is read.
This commit changes this: At the beginning of a frame, the palette is
read and cached as now. But audio frames are no longer cached at all;
they are returned immediately. This gets rid of copying and also allows
to remove the code for the buffer-to-AVStream correspondence.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>