There are seven MJPEG-tables, five small (1x12, 4x17) and two
not small (2x162). These are all avpriv, despite this not being
worthwhile due to the overhead of exporting a symbol: The total
overhead for each symbol consists of two entries in .dynsym (24B each),
one entry in the importing library's .rela.dyn (24B) and one in .got
(8B) as well as 2x2B for symbol versions and 4B for symbol hashes
in the exporting library; in addition to that, the name of the symbol
is included in both exporting and importing libraries, using 2x210 bytes
in this case.
(The above numbers are for a x64 Elf/Linux/GNU system. Other platforms
will give different numbers.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said table is 64 bytes long and exported so that it can be used both
in libavcodec and libavformat. This commit stops doing so and instead
duplicates it for shared builds, because the overhead of exporting the
symbol is bigger than 64 bytes. It consists of the length of the name of
the symbol (2x24 bytes), two entries in .dynsym (2x24 bytes), two
entries for symbol version (2x2 bytes), one hash value in the exporting
library (4 bytes) in addition to one entry in the importing library's
.got and .rela.dyn (8 + 24 bytes).
(The above numbers are for a Linux/GNU/Elf system; the numbers for other
platforms may be different.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is small (16 B) and therefore the overhead of exporting it more
than outweighs the size savings from not having duplicated symbols:
When the symbol is no longer avpriv, one saves twice the size of
the string containing the symbols name (2x30 byte), two entries
in .dynsym (24 bytes each on x64), one entry in the importing libraries
.got and .rela.dyn (8 + 24 bytes on x64) and two entries for the
symbol version (2 bytes each) and one hash value in the exporting
library (4 bytes).
(The exact numbers are of course different for other platforms
(e.g. when using dlls), but given that the strings saved alone
more than outweigh the array size it can be presumed that this
is beneficial for all platforms.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavcodec currently exports four avpriv symbols that deal with
PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
lists of PixelFormatTags, the former returns such a list and the second
searches a list for a pixel format that matches a given fourcc; only
one of the aforementioned three lists is ever searched.
Yet for avpriv_pix_fmt_bps_avi, avpriv_pix_fmt_bps_mov and
avpriv_find_pix_fmt the overhead of exporting these functions actually
exceeds the size of said objects (at least for ELF; the following numbers
are for x64 Ubuntu 20.10):
The code size of avpriv_find_pix_fmt is small (GCC 10.2 37B, Clang 11 41B),
yet exporting it adds a 20B string for the name alone to the exporting
as well as to each importing library; there is more: Four bytes in the
exporting libraries .gnu.hash; two bytes each for the exporting as well
as each importing libraries .gnu.version; 24B in the exporting as well
as each importing libraries .dynsym; 16B+24B for an entry in .plt as
well as the accompanying relocation entry in .rela.plt for each
importing library.
The overhead for the lists is similar: The strings are 23B and the
.plt+.rela.plt pair is replaced by 8B+24B for an entry in .got and
a relocation entry in .rela.dyn. These lists have a size of 80 resp.
72 bytes.
Yet for ff_raw_pix_fmt_tags, exporting it is advantageous compared to
duplicating it into libavformat and potentially libavdevice. Therefore
this commit replaces all library uses of the four symbols with a single
function that is exported for shared builds. It has an enum parameter
to choose the desired list besides the parameter for the fourcc. New
lists can be supported with new enum values.
Unfortunately, avpriv_get_raw_pix_fmt_tags could not be removed, as the
fourcc2pixfmt tool uses the table of raw pix fmts. No other user of this
function remains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes regression in a1c4929f: there apparently are devices out there
that expose a pin default format that has parameters outside the
capabilities of any of the formats exposed on the pin (sic?). The
VirtualCam plugin (v 2.0.5) of OBS-Studio (v 27.1.3) is such a device.
Now when a default format was found, but not selected when iterating all
formats, fall back to directly setting the default format.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
fix regression introduced in 911ba8417e.
Removal of WINAPI decoration from function signatures caused crashed
when using dshow on x86.
Fixes#9568
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
Cleanup was missing for when the show_analog_tv_tuner_audio_dialog is
true.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something like
av_format_inject_global_side_data, which is unfortunately not the
default.
This commit is not the time and place to change that behavior, though.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To avoid the ref for this growing to a very large size when attaching
the parsed RPU side data. Since this sample does not have any dynamic
metadata, two frames will serve just as well as 100.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.
Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.
Since the distinction matters greatly for parsing the color matrix
values, this includes a small helper function to guess the right profile
from the RPU itself in case the user has forgotten to forward the dovi
configuration record to the decoder. (Which in practice, only ffmpeg.c
and ffplay do..)
Notable omissions / deviations:
- CRC32 verification. This is based on the MPEG2 CRC32 type, which is
similar to IEEE CRC32 but apparently different in subtle enough ways
that I could not get it to pass verification no matter what parameters
I fed to av_crc. It's possible the code needs some changes.
- Linear interpolation support. Nothing documents this (beyond its
existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
seem largely congruent with ST2094, HDR10, or other existing forms of
side data, so I will defer parsing/attaching them to a future commit.
- The patent describes a mechanism for predicting coefficients from
previous RPUs, but the bit for the flag whether to use the
prediction deltas or signal entirely new coefficients does not seem to
be present in actual RPUs, so we ignore this subsystem entirely.
- In the patent's spec, the NLQ subsystem also loops over
num_nlq_pivots, but even in the patent the number is hard-coded to one
iteration rather than signalled. So we only store one set of coefs.
Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In order to be able to extend this struct later (as the Dolby Vision RPU
evolves), all of the 'container' structs are considered extensible, and
the individual constituent fields must instead be accessed via offsets.
The precedent for this style of access is set in
<libavutil/detection_bbox.h>
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Improves readability and slightly decreases codesize.
While just at it, also remove a check whether the packet list is
nonempty before freeing it, as freeing an empty list is fine
and basically a no-op.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes one of the last usages of sizeof(AVPacket)
in the generic muxing code.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case of shared builds, some object files containing tables
are currently duplicated into other libraries: log2_tab.c,
golomb.c, reverse.c. The check for whether this is duplicated
is simply whether CONFIG_SHARED is true. Yet this is crude:
E.g. libavdevice includes reverse.c for shared builds, but only
needs it for the decklink input device, which given that decklink
is not enabled by default will be unused in most libavdevice.so.
This commit changes this by making it more explicit about what
to duplicate from other libraries. To do this, two new Makefile
variables were added: SHLIBOBJS and STLIBOBJS. SHLIBOBJS contains
the objects that are duplicated from other libraries in case of
shared builds; STLIBOBJS contains stuff that a library has to
provide for other libraries in case of static builds. These new
variables provide a way to enable/disable with a finer granularity
than just whether shared builds are enabled or not. E.g. lavd's
Makefile now contains: SHLIBOBJS-$(CONFIG_DECKLINK_INDEV) += reverse.o
Another example is provided by the golomb tables. These are provided
by lavc for static builds, even if one uses a build configuration
that makes only lavf use them. Therefore lavc's Makefile contains
STLIBOBJS-$(CONFIG_MXF_MUXER) += golomb.o, whereas lavf's Makefile
has a corresponding SHLIBOBJS-$(CONFIG_MXF_MUXER) += golomb_tab.o.
E.g. in case the MXF muxer is the only component needing these tables
only libavformat.so will contain them for shared builds; currently
libavcodec.so does so, too.
(There is currently a CONFIG_EXTRA group for golomb. But actually
one would need two groups (golomb_avcodec and golomb_avformat) in
order to know when and where to include these tables. Therefore
this commit uses a Makefile-based approach for this and stops
using these groups for the users in libavformat.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The packet given to muxers is not used afterwards; it is always
unreferenced by libavformat. Ergo muxers are allowed to keep
the references in the packets and e.g. move the ownership to
a packet list. This is what this commit does.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Improves code legibility by not using bit shifts.
Also avoids duplicating the dvcC/dvvC ISOM box writing code.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To avoid duplicating code. The implementation in dovi_isom is identical.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Adds handling of dvcC/dvvC block addition mappings.
The parsing creates AVDOVIDecoderConfigurationRecord side data.
The configuration block is written when muxing into Matroska,
if DOVI side data is present for the track.
Most of the Matroska element parsing is based on Plex's FFmpeg source code.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both parse/write implementations are based on mov/movenc.
This only adds support for the "Dolby Vision configuration box".
Other configuration boxes, such as
"Dolby Vision enhancement layer configuration box" are not supported.
The new functions will be used to implement parsing/writing the DOVI config
for Matroska, as well as to refactor both mov/movenc to use dovi_isom functions.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
'*src' and '*avctx' point to the same memory. It is enough to keep one of them.
Signed-off-by: Yu Yang <yuyang14@kuaishou.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The former is useless without the latter.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
On 64 bit Operating System, sizeof(ScaleVulkanContext):
reduce from 2400 to 2392 on Linux
reduce from 2416 to 2408 on Windows
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The following command is on how to apply passthrough option:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,transpose_vulkan=passthrough=landscape,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
We don't use it. Was copied from libplacebo's recommended defaults.
Creates problems with validation on Intel devices, where the driver
still advertizes it, even though it's not usable without a swapchain.
No speex samples with non default frame sizes are known (to me)
the official speexenc seems to only generate the 3 default ones.
Thus it may be that the fuzzer samples where the first non default
values encountered by the decoder.
Possibly the "<" should be "!="
Fixes: out of array access
Fixes: 42821/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-5640695772217344
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Users may take the description literally which leads to inverted
results.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: Jun Zhao <barryjzhao@tencent.com
added "cache_redirect" option to http.
when enabled, requests issued after seek will use the latest redirected
url.
when disabled, each call to seek will revert to the original url that
was sent to http_open.
currently, the default remains 'enabled', until the next major
libavformat bump, where it will change to 'disabled'.
Very high stts sample deltas may occasionally be intended but usually
they are written in error or used to store a negative value for dts correction
when treated as signed 32-bit integers.
This option lets the user set an upper limit, beyond which the delta is clamped to 1.
Values greater than the limit if negative when cast to int32 are used to adjust onward dts.
Unit is the track time scale. Default is UINT_MAX - 48000*10 which
allows upto a 10 second dts correction for 48 kHz audio streams while
accommodating 99.9% of uint32 range.
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Andreas Rheinhardt