Video devices categorized by AVFoundation as
'AVCaptureDeviceTypeExternal(Unknown)' (like USB video streams) were not
recognized by libavdevice.
Signed-off-by: Theo Fabi <fabi.theo@gmail.com>

When the SPS associated with a particular SPS ID changes, invalidate all
the PPSs which use that SPS ID.  Fixes crashes with illegal bitstreams.
This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
ID reuse validation, as parts of the CBS parsing process for PPSs
depend on the SPS being referred to.
Signed-off-by: Frank Plowman <post@frankplowman.com>

Encoder options have been updated to the current version of the AMF.
Signed-off-by: Araz Iusubov <Primeadvice@gmail.com>

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

                                  Before    After
-------------------------------------------------
make fate-vvc CPU Time (No ASM)  131.52s  134.83s
libavcodec/vvc/* Line Coverage     95.3%    96.9%
inter_template.c Line Coverage     74.3%    88.2%
inter.c Line Coverage              85.3%    99.2%
Signed-off-by: Frank Plowman <post@frankplowman.com>

Fixes: out of array access
Fixes: 68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: James Almer <jamrial@gmail.com>

They are all zeroes, not ones.
Signed-off-by: James Almer <jamrial@gmail.com>

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

Fixes: CID1592939 Dereference after null check

Sponsored-by: Sovereign Tech Fund
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: CID1598548 Logically dead code

Sponsored-by: Sovereign Tech Fund
Reviewed-by: "Xiang, Haihao" <haihao.xiang@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This or fifo needs to be freed on errors explicitly

Fixes: memleak
Fixes: 68937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-4830831016214528

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

Fixes: out of array access
Fixes: 68302/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4665793796177920

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: out of array access
Fixes: 68584/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6256656668229632

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

chrRangeFromJpeg_8_c: 29.2
chrRangeFromJpeg_8_neon: 19.5
chrRangeFromJpeg_24_c: 80.5
chrRangeFromJpeg_24_neon: 34.0
chrRangeFromJpeg_128_c: 413.7
chrRangeFromJpeg_128_neon: 156.0
chrRangeFromJpeg_144_c: 471.0
chrRangeFromJpeg_144_neon: 174.2
chrRangeFromJpeg_256_c: 842.0
chrRangeFromJpeg_256_neon: 305.5
chrRangeFromJpeg_512_c: 1699.0
chrRangeFromJpeg_512_neon: 608.0
chrRangeToJpeg_8_c: 51.7
chrRangeToJpeg_8_neon: 22.7
chrRangeToJpeg_24_c: 149.7
chrRangeToJpeg_24_neon: 38.0
chrRangeToJpeg_128_c: 761.7
chrRangeToJpeg_128_neon: 176.7
chrRangeToJpeg_144_c: 866.2
chrRangeToJpeg_144_neon: 198.7
chrRangeToJpeg_256_c: 1516.5
chrRangeToJpeg_256_neon: 348.7
chrRangeToJpeg_512_c: 3067.2
chrRangeToJpeg_512_neon: 692.7
lumRangeFromJpeg_8_c: 24.0
lumRangeFromJpeg_8_neon: 17.0
lumRangeFromJpeg_24_c: 56.7
lumRangeFromJpeg_24_neon: 21.0
lumRangeFromJpeg_128_c: 294.5
lumRangeFromJpeg_128_neon: 76.7
lumRangeFromJpeg_144_c: 332.5
lumRangeFromJpeg_144_neon: 86.7
lumRangeFromJpeg_256_c: 586.0
lumRangeFromJpeg_256_neon: 152.2
lumRangeFromJpeg_512_c: 1190.0
lumRangeFromJpeg_512_neon: 298.0
lumRangeToJpeg_8_c: 31.7
lumRangeToJpeg_8_neon: 19.5
lumRangeToJpeg_24_c: 83.5
lumRangeToJpeg_24_neon: 24.2
lumRangeToJpeg_128_c: 440.5
lumRangeToJpeg_128_neon: 91.0
lumRangeToJpeg_144_c: 504.2
lumRangeToJpeg_144_neon: 101.0
lumRangeToJpeg_256_c: 879.7
lumRangeToJpeg_256_neon: 177.2
lumRangeToJpeg_512_c: 1794.2
lumRangeToJpeg_512_neon: 354.0

Only flush state when we started parsing data, otherwise just error out.
Remove the 'fail' label to make this a bit less confusing to read.

This is used by future versions of the spec to implement metadata
compression. Given that we don't yet implement that spec, validate that
this is equal to 0 for now.

In the spec, dm_metadata_present also toggles all extension blocks, so
we need to move them inside the branch.

This is not an internal use function.

Storing the color metadata alongside the data mapping is no longer
needed, so we can simplify this array's type.

Move `vdr` into local scope and point only to the field we actually care
about.

Despite the suggestive size limits, this metadata ID has nothing to do
with the VDR metadata ID used for the data mappings. Actually, the
specification leaves them wholly unexplained, other than acknowleding
their existence. Must be some secret dolby sauce. They're not even
involved in DM metadata compression, which is handled using an entirely
separate ID.

That leaves us with a lack of anything sensible to do with these IDs.
Since we unfortunately only expose one `dm_metadata_id` field to the
user, just ensure that they match; which appears to always be the case
in practice. If somebody ever hits this error, I would really much
rather like to see the triggering file.

When this is 0, the metadata is explicitly inferred to stated default
values from the spec, rather than inferred from the previous frame's
values.

Likewise, when encoding, instead of checking if the value changed since
the last frame, we need to check if it differs from the default.

According to the spec, missing previous VDR RPU IDs do not constitute an
error, but we should instead fallback first to VDR RPU with ID 0, and
failing that, synthesize "neutral" metadata.

That's nontrivial though as the resulting metadata will be dependent on
other properties of the RPU, and this case is not hit in practice so
I'll defer it to a rainy day.

This is specified to be in the range -1 to 4095, apparently the only
extension level with such a restriction.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Otherwise a bunch of SEI units that should not be in hvcC will be included,
and generate different output with builds where extract_extradata_bsf is not
present.
Signed-off-by: James Almer <jamrial@gmail.com>

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

These boxes are created by the Apple Vision Pro and the iPhone 15+ when
capture for the Vision Pro is enabled.

Based off of the swift API:
  * https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofviewSigned-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This box is provided by files created by the Apple Vision Pro, as well
as the iPhone 15+ when capture for Vision Pro is enabled.

The boxes are a mix of things documented by Apple in some PDFs, their
API docs, and reverse engineering. Ideally we will have a real spec
one day.

Links:
  * https://developer.apple.com/av-foundation/Stereo-Video-ISOBMFF-Extensions.pdf
  * https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeyeSigned-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Based on what is in the files themselves, and what the API provides
to users.

URLs:
  * https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
  * https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofviewSigned-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

These originate from the Apple Vision Pro, and are documented here:

    https://developer.apple.com/documentation/coremedia/cmprojectiontypeSigned-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Fixes ticket #11057.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

On m1, kpc_get_counter_count(KPC_MASK) return 8 in my test. The
exact value doesn't matter in our case, as long as we have a
sufficiently large array
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

mach/mach_time.h was included only when CONFIG_MACOS_KPERF wasn't
been defined.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

The check should be >= 0, not > 0. The check itself is redundant
since uninit only being called after init is success.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

As of mbedTLS 3.6.0 TLSv1.3 is enabled by default and certificate verification
is now mandatory. Our default configuration does not do verification, so
downgrade to 1.2 in these situations to avoid breaking it.

ref: https://github.com/Mbed-TLS/mbedtls/issues/7075Signed-off-by: Anton Khirnov <anton@khirnov.net>