Zhong Li [Thu, 25 Apr 2019 10:51:10 +0000 (18:51 +0800)]
lavc/qsvdec: add query function and provide error message
It is helpful to know why some clips decoding failed.
Ticket#7330 is a good example, with this patch it is easily to
know bitstream codec level is out of support range.
Reference: Table 8: Interpretation of valid BITPIX value from FITS standard 4.0 Fixes: runtime error: division by zero Fixes: 14581/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5652382425284608 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>
James Almer [Thu, 25 Apr 2019 22:04:01 +0000 (19:04 -0300)]
avformat/aacdec: fix demuxing of small frames
10 bytes (id3v2 header amount of bytes) were being read before any checks
were made on the bitstream. The result was that we were overreading into
the next frame if the current one was 8 or 9 bytes long.
avcodec/hevcdec: Declare that VDPAU can handle HEVC 4:4:4 content
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. This change adds AV_PIX_FMT_VDPAU as a valid format
for HEVC 4:4:4 8 bit.
avcodec/vdpau_hevc: Pass sps and pps range extension flags to VDPAU
Pass SPS, PPS range extensions to VDPAU layer via
VdpPictureInfoHEVC444. Added VdpPictureInfoHEVC444 struct to
VdpPictureInfo union to populate the range extension params. Mapped
FF_PROFILE_HEVC_REXT to VDP_DECODER_PROFILE_HEVC_MAIN_444.
ManojGuptaBonda [Fri, 3 May 2019 20:57:53 +0000 (02:27 +0530)]
avutil/hwcontext_vdpau: Map 444 pix fmts to new VdpYCbCr types
New VdpYCbCr Formats VDP_YCBCR_FORMAT_Y_U_V_444 and,
VDP_YCBCR_FORMAT_Y_UV_444 have been added in VDPAU with libvdpau-1.2
to be used in get/putbits for YUV 4:4:4 surfaces. Earlier mapping of
AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_YV12 is not valid.
Hence this Change maps AV_PIX_FMT_YUV444P to VDP_YCBCR_FORMAT_Y_U_V_444
to access the YUV 4:4:4 surface via read-back API's of VDPAU.
Marton Balint [Wed, 1 May 2019 10:47:43 +0000 (12:47 +0200)]
avdevice/decklink: fix checking video mode in SDK version 11
Apparently in the new SDK one cannot query if VANC output is supported, so we
will fall back to non-VANC output if enabling the video output with VANC fails.
avcodec/jvdec: Use ff_get_buffer() when the content is not reused
Fixes: Timeout (11sec -> 5sec) Fixes: 14473/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5761630857592832 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>
avcodec/pnm_parser: clear state if buffer is discarded
Fixes: Assertion failure Fixes: 14484/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5150016408125440 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>
This commit was merged in a couple years ago as a no-op because we
had already switched from GetProcAddress to dlsym some time before
that. However, not applying the actual cast causes warnings about
FARPROC and when attempting to build FFmpeg in MSVC with AviSynth-GCC
32-bit compatibility, those FARPROC warnings turn into FARPROC errors.
Directed to the AviSynth+ entry on AviSynth Wiki rather than to
the github repository, since the wiki page is both more informative
and has the relevant Git/download links. The github releases page
is little more than a changelog.
These pix_fmts have been added to FFmpeg in the 31 months since
commit 92916e8542e425ca20daddb490261a5818643206 added support for
the larger number of pix_fmts that AviSynth+ can use. They were
present in AviSynth+ even then, just not in libavutil.
As part of the update, it is now possible to test 32-bit GCC builds
of AviSynth+ with FFmpeg by using the AVS_WIN32_GCC32 define. Due to
different calling conventions between MSVC and GCC regarding 32-bit
Windows, this is unfortunately necessary.
The last argument of av_strlcpy is supposed to contain the size of the
destination buffer, but it was filled with the size of the source
string, effectively negating its very purpose.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/truemotion2: Fix 2 integer overflows in tm2_update_block()
Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in type 'int' Fixes: 14107/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5694078680825856 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/pnm_parser: Remember the length already scanned for ascii images
Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm Found-by: Michael Koch Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/nvenc: only unregister input resources when absolutely needed
This reverts nvenc to old behaviour, which in some super rare edge cases
performs better.
The implication of this is that any potential API user who relies on
nvenc cleaning up every frames device resources after it's done using
them will have to change their usage pattern.
That should not be a problem, since pretty much every normal usage
pattern automatically implies that surfaces are reused from a common
pool, since constant re-allocation is also very expensive.
Jun Zhao [Tue, 16 Apr 2019 04:54:58 +0000 (12:54 +0800)]
lavf/hls: Remove HLSContext.strict_std_compliance field
After the commit 9f61abc8111, we can use AVFormatContext.strict_std_compliance
instead of HLSContext.strict_std_compliance to avoid the code redundancy.
projects / ffmpeg / log