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>
avformat/smacker: Avoid potential inifinite loop on error
When reading a new frame, the Smacker demuxer seeks to the next frame
position where it excepts the next frame; then it (potentially) reads
the palette, the audio packets associated with the frame and finally the
actual video frame. It is only at the end that the frame counter as well
as the position where the next frame is expected get updated.
This has a downside: If e.g. invalid data is encountered when reading
the palette, the demuxer returns immediately (with an error) and if the
caller calls av_read_frame again, the demuxer seeks to the position where
it already was, reads the very same palette data again and therefore will
return an error again. If the caller calls av_read_frame repeatedly
(say, until a packet is received or until EOF), this meight become an
infinite loop.
This could also happen if e.g. the size of one of the audio frames was
invalid or if the frame size was gigantic.
This commit changes this by skipping a frame if it turns out to be
invalid or an error happens otherwise. This ensures that EOF will be
returned eventually in the above scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Smacker demuxer buffers audio packets before it outputs them, but it
increments the counter of buffered packets prematurely: If allocating
the audio buffer fails, an error (most likely AVERROR(ENOMEM)) is returned.
If the caller decides to call av_read_frame() again, the next call will
take the codepath for returning already buffered audio packets and it
will fail (because the buffer that ought to be allocated isn't) without
decrementing the number of supposedly buffered audio packets (it doesn't
matter whether there would be enough memory available in subsequent calls).
Depending on the caller's behaviour this is potentially an infinite loop.
This commit fixes this by only incrementing the number of buffered audio
packets after having successfully read them and unconditionally reducing
said number when outputting one of them. It also changes the semantics
of the curstream variable: It is now the number of currently buffered
audio packets whereas it used to be the index of the last audio stream
to be read. (Index refers to the index in the array of buffers, not to
the stream index.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Lu Jiao [Tue, 16 Jun 2020 14:10:10 +0000 (22:10 +0800)]
avcodec/amfenc_hevc: set default gops_per_idr 1
Previously gops_per_idr default 60 would make amd gpu encoding hevc
has erratic seek bar behaviour as descripted in this ticket:
https://trac.ffmpeg.org/ticket/7272
This bad default is already fixed in newer AMF headers:
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/blob/master/amf/public/include/components/VideoEncoderHEVC.h
Derek Buitenhuis [Fri, 26 Jun 2020 13:08:37 +0000 (14:08 +0100)]
ffprobe: Allow unknown format private AVOptions
This useful, because by ffprobe's very nature, you use it to probe
a file and find out what it is. Requiring every format private option
to be known to the demuxer forces one to run ffprobe twice, if one
wants to use ffprobe in a generic way.
For example, say one wants to probe all user-uploaded files, while
also ignoring edit lists for any MP4s that are uploaded. Currently,
you'd have to run ffprobe twice: once to identify the format, and
once again to actually probe the metadata you want. After this
patch, you could set -ignore_editlist 1 on every call and only
probe once.
Fixes: signed integer overflow: 6500736 * 473 cannot be represented in type 'int' Fixes: 23259/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5179394271477760 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/hcadec: Check total_band_count against imdct_in size
Fixes: index 128 out of bounds for type 'float [128]' Fixes: 23465/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-5089866596745216 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/tiff: Do not overrun the array ends in dng_blit()
Fixes: out of array access Fixes: 23589/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5110559589793792.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/dstdec: Replace AC overread check by sample rate check
Real files do skip coding 0 bits at the end, thus this kind of check
does not work reliable.
Fixes: Ticket 8770 Fixes: dst-256fs44-6ch-refdstencoder.dff
The samplerate is specified in ISO/IEC 14496-3:2005(E) as one of 3 fixed
values, this also can be used to limit the duration and avoid the timeout
projects / ffmpeg / log