./ffmpeg -loop 1 -s 1200x1440 -i tux16.png \
    -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p16le -nostats test.raw

./ffmpeg -loop 1 -s 1200x1440 -i tux16.png \
    -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p -nostats test.raw

32-bit mul, power8 only

2x speedup for hScale8To19_vsx (x86 SSE2 is 2.37):
  30896 UNITS in hscale,    8192 runs,      0 skips
  63956 UNITS in hscale,    8192 runs,      0 skips

2.06 for hScale16To15_vsx:
  30531 UNITS in hscale,    8192 runs,      0 skips
  63161 UNITS in hscale,    8192 runs,      0 skips

./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
    -s 2400x720 -f rawvideo -y -vframes 5 -pix_fmt yuv420p16le -nostats test.raw

2.26 speedup (x86 SSE2 is 2.32):
  23772 UNITS in hscale,    4096 runs,      0 skips
  53862 UNITS in hscale,    4096 runs,      0 skips

Currently profile mapping is hard-coded, and not flexible to do extactly
map (E.g: libmfx treats H264 constrained baseline to be baseline profile).

vaapi profile mapping funtion provides a better soultion than current
qsv mapping.
Signed-off-by: Zhong Li <zhong.li@intel.com>

libmfx hevc level defination is same as h264, not level_idc of SPEC.
Signed-off-by: Zhong Li <zhong.li@intel.com>

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.
Signed-off-by: Zhong Li <zhong.li@intel.com>

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/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: James Almer <jamrial@gmail.com>

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.

Fixes tickets #7271 and #7869.
Signed-off-by: James Almer <jamrial@gmail.com>

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.

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.

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.

Fixes ticket #7859
Reported and tested by Steffen Ohrendorf, steffen d ohrendorf a gmx d de

avfilter/vf_freezedetect: fix missing freeze_start when the freeze length is around the detection duration

Fixes ticket #7875.
Signed-off-by: Marton Balint <cus@passwd.hu>

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.

Fixes ticket #7867.
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

avcodec/h263dec: Fixed VA API, VDPAU, and VideoToolbox hardware acceleration due to missing `hw_configs` property.

Bug originally introduced in commit 758fbc54.

Allows running fate from out-of-tree builds on wsl.

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/ffmpegReviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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/ffmpegReviewed-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.

It's been fixed both AviSynth+-side and locally.

These pix_fmts have been added to FFmpeg in the 31 months since
commit 92916e85 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.

Could not be used in apply_dependent_coupling because of alignment issues.

Ever since 59ad5046, the demuxer expects its seek arg to be PTS
and adjusts internally to search index by DTS.

Signed-off-by: James Almer <jamrial@gmail.com>

Prevents pointless register saving on win64 for the sse3 and avx
versions of the function.
Signed-off-by: James Almer <jamrial@gmail.com>