match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: James Almer <jamrial@gmail.com>
AVIF still and animations are now supported by the MOV parser.
Add the "avif" extension to the list of supported extensions to
AVInputFormat.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm
surprised this didn't break any previous system versions.
Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on
Mac OS Monterey. Fixes likely bug that none of the AudioToolbox
decoders work on Monterey.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This filter is designed to parse embedded ICC profiles and attempt
extracting colorspace tags from them, updating the AVFrame metadata
accordingly.
This is intentionally made a separate filter, rather than being part of
libavcodec itself, so that it's an opt-in behavior for the time being.
This also gives the user more flexibility to e.g. first attach an ICC
profile and then also set the colorspace tags from it.
This makes #9673 possible, though not automatic.
Signed-off-by: Niklas Haas <git@haasn.dev>
This filter is designed to specifically cover the task of generating ICC
profiles (and attaching them to output frames) on demand. Other tasks,
such as ICC profile loading/stripping, or ICC profile application, are
better left to separate filters (or included into e.g. vf_setparams).
Signed-off-by: Niklas Haas <git@haasn.dev>
This introduces an optional dependency on lcms2 into FFmpeg. lcms2 is a
widely used library for ICC profile handling, which apart from being
used in almost all major image processing programs and video players,
has also been deployed in browsers. As such, it's both widely available
and well-tested.
Add a few helpers to cover our major use cases. This commit merely
introduces the helpers (and configure check), even though nothing uses
them yet.
It's worth pointing out that the reason the cmsToneCurves for each
AVCOL_TRC are cached inside the context, is because constructing a
cmsToneCurve requires evaluating the curve at 4096 (by default) grid
points and constructing a LUT. So, we ideally only want to do this once
per curve. This matters for e.g. ff_icc_profile_detect_transfer, which
essentially compares a profile against all of these generated LUTs.
Re-generating the LUTs for every iteration would be unnecessarily
wasteful.
The same consideration does not apply to e.g. cmsCreate*Profile, which
is a very lightweight operation just involving struct allocation and
setting a few pointers.
The cutoff value of 0.01 was determined by experimentation. The lowest
"false positive" delta I saw in practice was 0.13, and the largest
"false negative" delta was 0.0008. So a value of 0.01 sits comfortaby
almost exactly in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
Related to #9673, this helper exists to facilitate "guessing" the right
primary tags from a given set of raw primary coefficients.
The cutoff value of 0.001 was chosen by experimentation. The smallest
"false positive" delta observed in practice was 0.023329, while the
largest "false negative" delta was 0.00016. So, a value of 0.001 sits
comfortably in the middle.
Signed-off-by: Niklas Haas <git@haasn.dev>
These are needed beyond just vf_colorspace, so give them a new home in
colorspace.h.
In addition to moving code around, also merge the white point and
primary coefficients into a single struct to slightly increase the
convenience and shrink the size of the new API by avoiding the need
to introduce an extra function just to look up the white point as well.
The only place the distinction matters is in a single enum comparison,
which can just as well be a single memcpy - the difference is
negligible.
Signed-off-by: Niklas Haas <git@haasn.dev>
This patch supports AVIF still images conforming to the
final specification that have exactly one item (i.e. no alpha channel).
The iloc box is parsed and the mov index populated.
Partially fixes#7621.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
60 fps content have "Number of Frames" set to 30 in the tmcd atom, but the
frame duration / timescale reflects the original video frame rate.
Therefore we multiply the frame count with the quotient of the rounded timecode
frame rate and the "Number of Frames" per second to get a frame count in the original
(higher) frame rate.
Note that the frames part in the timecode will be in high frame rate which will
make the timecode different to e.g. MediaInfo which seems to show the 30 fps
timecode even for 120 fps content.
Regression since 428b4aacb1.
Fixes ticket #9710.
Fixes ticket #9492.
Signed-off-by: Marton Balint <cus@passwd.hu>
Otherwise its effect might not work causing CPU_COUNT to not get defined.
Fixes cpu count detection to actually use sched_getaffinity if available.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: signed integer overflow: -2515507630940093440 * 4 cannot be represented in type 'long'
Fixes: 46318/clusterfuzz-testcase-minimized-ffmpeg_dem_GENH_fuzzer-5009637474172928
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: signed integer overflow: 9223371898743775808 - -138111000000 cannot be represented in type 'long'
Fixes: 46245/clusterfuzz-testcase-minimized-ffmpeg_dem_OGG_fuzzer-5075129786302464
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 avoids having to do one pass to calculate the full length to allocate
followed by a second pass to actually append values.
Signed-off-by: Martin Storsjö <martin@martin.st>