The second ; in a double ;; is actually a null statement. It triggers
the typical declaration-after-statement compiler-warnings if it occurs
in the middle of several declarations (like here).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/ivfenc: Don't use size_t for size of file
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/magicyuv: Check that there are enough lines for interlacing to be possible
Fixes: out of array access Fixes: 20763/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5759562508664832 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Mark Thompson [Sun, 16 Feb 2020 20:59:54 +0000 (20:59 +0000)]
hwcontext_vaapi: Only accept a render node when deriving from DRM device
If we are given a non-render node, try to find the matching render node and
fail if that isn't possible.
libva will not accept a non-render device which is not DRM master, because
it requires legacy DRM authentication to succeed in that case:
<https://github.com/intel/libva/blob/master/va/drm/va_drm.c#L68-L75>. This
is annoying for kmsgrab because in most recording situations DRM master is
already held by something else (such as a windowing system), leading to
device derivation not working and forcing the user to create the target
VAAPI device separately.
Linjie Fu [Wed, 15 Jan 2020 07:00:12 +0000 (15:00 +0800)]
lavu/hwcontext_vaapi: add vaapi_format_map support for Y210
VA_RT_FORMAT describes the desired sampling format for surface.
When creating surface, VA_RT_FORMAT will be used firstly to choose
the expected fourcc/media_format for the surface. And the fourcc
will be revised by the value of VASurfaceAttribPixelFormat.
Add vaapi_format_map support for new pixel_format Y210.
This is fundamental for both VA-API and QSV.
Linjie Fu [Wed, 15 Jan 2020 06:59:34 +0000 (14:59 +0800)]
swscale: Add swscale input support for Y210LE
Add swscale input support for Y210LE, output support and fate
test could be added later if there is requirement for software
CSC to this packed format.
Marton Balint [Fri, 14 Feb 2020 22:32:14 +0000 (23:32 +0100)]
avformat/libsrt: small fixes in libsrt_neterrno()
Return os error code if available, check for both SRT_EASYNCRCV and
SRT_EASYNCSND when transforming them to EAGAIN and only display error if it is
not EAGAIN.
Marton Balint [Thu, 13 Feb 2020 22:58:45 +0000 (23:58 +0100)]
avformat/libsrt: fix checking connection result in non-blocking mode
After f8990c5f414d4575415e2a3981c3b142222ca3d4 we properly set non-blocking
mode which makes the connect() call return always 0 even if no connection can
be established.
Fix this by always doing a poll after calling connect(). Also there was some
leftover copy paste code which checks for various errors which are simply not
possible with SRT.
Marton Balint [Thu, 13 Feb 2020 22:50:32 +0000 (23:50 +0100)]
avformat/libsrt: fix name of timeout option
rw_timeout is the generic URLcontext option, not the protocol specific timeout
option, also ?rw_timeout never worked because ?timeout was parsed instead.
Dale Curtis [Fri, 21 Feb 2020 20:53:30 +0000 (12:53 -0800)]
avformat/utils: Don't trigger errors for multiple id3 tags.
Such errors may make sense for specific formats, but general parsing
logic shouldn't be treating these as errors regardless of the error
recognition mode.
Fixes loading of the following wave when using -err_detect explode:
https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav
Signed-off-by: Dale Curtis <dalecurtis@chromium.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If an audio stream is present, the Sega FILM muxer checks for its
compability with the container during init, so that the very same check
needn't be repeated during writing the trailer.
Essentially the same is true for the presence of a video stream: It has
already been checked during init. Furthermore, after the check for the
presence of a video stream succeeded, a pointer is set to point to the
video stream. Yet said pointer (which was NULL before) will be
derefenced anyway regardless of the result of the check. Coverity thus
complained about this in CID 1434155 and removing this pointless check
will also fix this issue.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/pcm: Fix invalid shift in AV_CODEC_ID_PCM_LXF
Fixes: left shift of 233 by 24 places cannot be represented in type 'int' Fixes: 20736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PCM_LXF_fuzzer-4829212685107200 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read Fixes: 20742/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDTOONS_fuzzer-5738148607033344 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anssi Hannula [Thu, 20 Feb 2020 21:04:50 +0000 (23:04 +0200)]
avformat/spdifenc: fix TrueHD streams over 48kHz
Commit 36e156bef02 ("avformat/spdifenc: fix handling of large TrueHD
frame") added an obviously incorrect bitshift that caused incorrect
samples-per-frame calculation for TrueHD streams over 48kHz.
Anssi Hannula [Wed, 19 Feb 2020 20:46:35 +0000 (22:46 +0200)]
avformat/spdifenc: fix handling of large TrueHD frames
The TrueHD IEC 61937 encapsulation code uses a very naive method of
always inserting 24 TrueHD frames evenly in a MAT frame. This does not
work for larger frames as they may exceed the size of 1/24th of a MAT
frame.
To fix that, use the input_timing field in the TrueHD frame to determine
the proper position of the TrueHD frame in the MAT frame. That field is
basically a dts field, telling the time to feed this frame to the
decoder in sample count units.
This can cause a TrueHD frame to be split between two MAT frames, so a
second concatenation hd_buf is added, alternating with the first buffer.
Large frames are preceded by smaller frames that have input_timing
values that cause the frames to be sent out faster than the nominal rate
(i.e. increasing decoder latency, long decoder buffer), allowing the
larger frames to then be sent out slower than the nominal rate as the
decoder has enough data buffered to keep it busy.
Anssi Hannula [Thu, 20 Feb 2020 19:49:50 +0000 (21:49 +0200)]
avformat/spdifenc: make hd_buf an array
This is preparation for adding a second hd_buf in a followup commit.
Also, slightly improve the comments for hd_buf_x members to clarify
which ones are actually used and kept up-to-date depending on which
codec is being muxed.
avformat/wtvdec: Forward errors when reading packet
wtvfile_read_packet did not abide by the requirements of an
AVIOContext's read_packet-function: If it did not read anything,
it returned zero, which currently leads to a warning in read_packet_wrapper
in aviobuf.c. Said warning will be an av_assert2 as soon as
FF_API_OLD_AVIO_EOF_0 is zero (probably the next major version bump).
So instead forward the error code from the underlying protocol.
This error/assert is triggered in the wtv-demux FATE test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Peter Ross <pross@xvid.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access Fixes: 20660/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QDM2_fuzzer-5658290216501248 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
JonCookCubic [Tue, 21 Jan 2020 13:06:43 +0000 (13:06 +0000)]
libavcodec/qsvenc.c: Set mjpeg height and width alignment
Currently width_align and height_align are zero when encoding with mjpeg_qsv,
which causes "Error submitting the frame for encoding". This patch sets the alignments.
There is a little bit more about the problem here http://ffmpeg.org/pipermail/ffmpeg-user/2019-November/046143.html
Signed-off-by: JonCookCubic <jon.cook@cubicmotion.com> Signed-off-by: Zhong Li <zhongli_dev@126.com>
projects / ffmpeg / log