When an encoder exports sum-of-squared-differences information in
encoded packets, print_report() will print PSNR information in the
status line. However,
* the code computing PSNR assumes 8bit 420 video and prints incorrect
  values otherwise; there are no issues on trac about this
* only a few encoders (namely aom, vpx, mpegvideo, snow) export this
  information; other often-used encoders such as libx26[45] do not
  export this, even though they could

This suggests that this feature is not useful and it is better to remove
it rather than spend effort on fixing it.

Otherwise main and overlay videos share the same input region. Note NULL
pointer imples the whole overlay video will be processed.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>

- qsv_internal.h: Remove unnecessary include va_drm.h
- qsv_internal.h: Enable AVCODEC_QSV_LINUX_SESSION_HANDLE on Linux/VA only
- hwcontext_qsv.c: Do not allow child_device_type VAAPI for Windows until
  support is added, keep D3D11/DXVA2 as more prioritary defaults.

Initial review at https://github.com/intel-media-ci/ffmpeg/pull/619/Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Wu, Tong1 <tong1.wu@intel.com>

Initial review at https://github.com/intel-media-ci/ffmpeg/pull/619/Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Wu, Tong1 <tong1.wu@intel.com>

Libva 2.17+ adds a new libva-win32 node and Mesa 22.3 adds a VAAPI driver
based on Direct3D 12 for Windows. Both of them are available at:
https://www.nuget.org/packages/Microsoft.Direct3D.VideoAccelerationCompatibilityPack

Initial review at https://github.com/intel-media-ci/ffmpeg/pull/619/Signed-off-by: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Wu, Tong1 <tong1.wu@intel.com>

When write multi-trun box, the MOV_TRUN_FIRST_SAMPLE_FLAGS flag
need judge by first param, not 0.
If the original video contains consecutive I frames,
this will cause the packets of fmp4 have error sample_flags ,
and then incorrect keyframes were generated,
and then error packet will be seeked.
Signed-off-by: Wang Yaqiang <wangyaqiang03@kuaishou.com>
Signed-off-by: Steven Liu <liuqi05@chinaffmpeg.org>

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

Fix #10327.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

Adds JPEG 2000 decoder tests using materials from the conformance suite specified in
Rec. ITU-T T.803 | ISO/IEC 15444-4.

The test materials are available at https://gitlab.com/wg1/htj2k-codestreamsSigned-off-by: Pierre-Anthony Lemieux <pal@palemieux.com>

Signed-off-by: Pierre-Anthony Lemieux <pal@palemieux.com>

Signed-off-by: Pierre-Anthony Lemieux <pal@palemieux.com>

Fixes: Timeout
Fixes: 55116/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VORBIS_fuzzer-4572159970508800
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout
Fixes: 55106/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5052199338377216

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

framebuf is only allocated when the new width/height are larger than the old
but nothing sets the old so its always allocated.
Use av_fast_mallocz() instead.

Fixes: Timeout
Fixes: 55094/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5116909932904448

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 100183269 - -2132769113 cannot be represented in type 'int'
Fixes: 55063/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5039294027005952

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

num_ref_idx_l0_active_minus1, num_ref_idx_l1_active_minus1,
num_ref_idx_l0_default_active_minus1, and num_ref_idx_l1_default_active_minus1
are all in the range 0 to 14, inclusive.
Signed-off-by: James Almer <jamrial@gmail.com>

refine the code
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Support full range videos when transcoding, enabled the
YUVJ420P to avoid auto scale from YUVJ420P to YUV420P
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

If it's not empty here, then a leak would ocurr immediately after.
Signed-off-by: James Almer <jamrial@gmail.com>

Added framecrc tests for RGB JPEGs to verify future changes to the
decoder.

The change introduced in b18a9c29
created a regression for non-subsampled progressive RGB jpegs. This
should fix that.

Additionally, this should fix other RGB JPEGs broken before the recent
patches, such as those in Trac issue #10190.

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

When enable lcms2, the fate-png-icc-parse will get error bellow.
TEST    png-icc-parse
This because updated how PNG handles colors (no
longer using mastering display metadata for that).
Reviewed-by: Leo Izen <leo.izen@gmail.com>
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>

The decoder is tagged as being FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM, so might as
well make use of it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Also remove the _plus* and _minus* parts of some of these to be in line with
other similar fields in the decoder.
Signed-off-by: James Almer <jamrial@gmail.com>

The spec states that the range of values for them is −2^14 to 2^14 − 1, inclusive.
Signed-off-by: James Almer <jamrial@gmail.com>

The spec says: "The value of num_ref_loc_offsets shall be in the range of 0 to
vps_max_layers_minus1, inclusive".
Signed-off-by: James Almer <jamrial@gmail.com>

Remove now-obsolete code setting packet durations pre-muxing for CFR
encoded video.

Changes output in the following FATE tests:
* numerous adpcm tests
* ffmpeg-filter_complex_audio
* lavf-asf
* lavf-mkv
* lavf-mkv_attachment
* matroska-encoding-delay
  All of these change due to the fact that the output duration is now
  the actual input data duration and does not include padding added by
  the encoder.

* apng-osample: less wrong packet durations are now passed to the muxer.
  They are not entirely correct, because the first frame duration should
  be 3 rather than 2. This is caused by the vsync code and should be
  addressed later, but this change is a step in the right direction.
* tscc2-mov: last output frame has a duration of 11 rather than 1 - this
  corresponds to the duration actually returned by the demuxer.
* film-cvid: video frame durations are now 2 rather than 1 - this
  corresponds to durations actually returned by the demuxer and matches
  the timestamps.
* mpeg2-ticket6677: durations of some video frames are now 2 rather than
  1 - this matches the timestamps.