As suggested by Andreas Rheinhardt, most code of v210 demuxer is common code
which is duplicated from rawvideodec, so it's better to move v210/v210x
demuxer code to rawvideodec.c and reuse the common code.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This is done a second time for 5.0 because master was
merged into 5.0 so that it contains the recent DOVI additions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, we had a PacketList structure which is actually
a PacketListEntry; a proper PacketList did not exist
and all the related functions just passed pointers to pointers
to the head and tail elements around. All these pointers were
actually consecutive elements of their containing structs,
i.e. the users already treated them as if they were a struct.
So add a proper PacketList struct and rename the current PacketList
to PacketListEntry; also make the functions use this structure
instead of the pair of pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is quite small (96B with GCC 11.2 on x64 Ubuntu 21.10
at -O3), making it more economical to duplicate it into libavformat
instead of exporting it as avpriv: Doing so saves 2x24B in .dynsim,
2x16B in .dynstr, 2x2B .gnu.version, 24B in .rela.plt, 16B in .plt,
16B in .plt.sec (if enabled), 4B .gnu.hash; besides the actual
duplicated code this also adds 2x8B .eh_frame_hdr and 24B .eh_frame.
In other words: Duplicating is neutral size-wise (it is also presumed
neutral for other systems). Given that it avoids the runtime
overhead of dynamic symbols, it is advantageouos to duplicate the
function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These arrays have a size of 180 resp. six bytes. This does not
make it worthwhile to export them due to the overhead this occurs;
for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 20+23B).
Therefore these symbols are unavprived and duplicated for shared
builds.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_mpeg4audio_sample_rates has a size of 64B and it is currently
avpriv; a clone of it exists in aacenctab.h and from there it is inlined
in aacenc.c (which also uses the avpriv version) and in the FLV muxer.
This means that despite it being avpriv both libavformat as well as
libavcodec have copies already.
This situation is clearly suboptimal. Given the overhead of exporting
symbols (for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 31B)) the object is
unavprived, i.e. duplicated into libavformat when creating a shared
build; but the duplicates in the AAC encoder and FLV muxer are removed.
This involves splitting of the sample rate table into a file of its own;
this allowed to break some spurious dependencies (e.g. both the AAC
encoder as well as the Matroska demuxer actually don't need the
mpeg4audio_get_config stuff).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
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>
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>
We do not support this as we multiply by 1000
Fixes: signed integer overflow: -45318575073853696 * 1000 cannot be represented in type 'long'
Fixes: 42804/clusterfuzz-testcase-minimized-ffmpeg_dem_LIVE_FLV_fuzzer-4630325425209344
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The values for the essence element type were updated in the spec
from 0x05/0x06 (ST2019-4 2008) to 0x0C/0x0D (ST2019-4 2009).
Fixes ticket #6380.
Thanks-to: Philip de Nier <philip.denier@bbc.co.uk>
Thanks-to: Matthieu Bouron <matthieu.bouron@gmail.com>
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: division by zero
Fixes: 42814/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4787014237552640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Reviewed-by: John-Paul Stewart <jpstewart@personalprojects.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adds support for concat demuxer to copy the side data information
from the input file to the resulting file. It will behave like the
metadata copy, where the metadata of the first file is kept in the
the output file.
Extract the current code that already performs the stream side_data
copy into a separate method and reuse the method in the concat demuxer.
Signed-off-by: Gerard Sole <g.sole.ca@gmail.com>
Resolves a warning that duration is being innaccurately estimated based
on bitrate.
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Peter Ross <pross@xvid.org>
Prior to this patch, for version 2 of the file format the frame rate was
hard-coded at 15 fps. This uses the 64-bit floating-point value from
the data stream, similar to what is already done for version 3 of the
file format (around line 206).
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Peter Ross <pross@xvid.org>
There is no mxfenc dependency any more since commit
b9a26b9d55.
Also remove a dnxhddata.h inclusion in mxfenc that was forgotten
in the very same commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
