This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames continue to be copied.
Additionally, this enabled passing through video frames that previously
were impossible to process, like hardware frames or other special
formats that couldn't be packed into a rawvideo packet.
According to API docs avdevice_list_devices(), avdevice_list_input_sources()
and avdevice_list_input_sinks() should return the number of autodetected
devices on success. This is redundant with AVDeviceInfoList->nb_devices so it
was not noticed earlier that none of the underlying device list functions work
like that.
Let's fix it in generic code to make it in line with the API docs.
Fixes ticket #9820.
Signed-off-by: Marton Balint <cus@passwd.hu>
The packets given to muxers need not be writable,
so it is best to access them via const uint8_t*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't assume each sample is one byte in size. Doing so results in wrong and
occasionally non-monotonically-increasing timestamps.
Fix nearby cosmetic typo.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reduces default fragment size from the pulse audio default of 2 sec to 50 ms.
This also has an effect on the size of the returned frames, which will be
around 50 ms as well, making timestamps more accurate.
This should fix the regression in ticket #9776.
Pulseaudio timestamps for monitor sources are still pretty inaccurate for me,
but I don't see how else should we query latencies from the library.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reverts commit 7f059a250b.
Apparently adjusting latency makes a difference even if fragment size is specifed.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fix for f125c504d8, requested_sample_rate
and such should be used.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This file is both for the various public APIs that are demuxer-only
as well as for the demuxer-only internal functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
a1c4929f accidentally undid part of d9a9b4c8, so the bug in ticket #9420
resurfaced. Fixing again.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids unnecessary churn and build breakage for users, by
making sure the whole version.h is included like it has been so far,
while keeping the benefit of not needing to rebuild most files in
the ffmpeg tree on minor/micro bumps.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also bump the minor versions of all libraries, to signify the
API change of splitting the version.h headers and adding the
new version_major.h header.
Signed-off-by: Martin Storsjö <martin@martin.st>
xvmc.h used FF_API_* macros before, but they were removed in
1c63aed232, leaving the include
unused.
The ones in android_camera.c and mediacodec_wrapper.c have been
added due to a misunderstanding, fixed in
c0bce367e4 and
13b77af2f0.
The one in mediacodec.c seems to never have been used at all.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some of these were made possible by moving several common macros to
libavutil/macros.h.
While just at it, also improve the other headers a bit.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
iec61883_parse_queue_hdv() is only called when the mpegts-demuxer
is available and can be optimized away when not. Yet this
optimization is not a given and it fails with e.g. GCC 11 when
using -O0 in which case one will get a compilation error
because the call to the unavailable avpriv_mpegts_parse_packet()
is not optimized away. Therefore #if the offending code away
in this case.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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 group is mainly for the users of *_mpeg4audio_get_config2();
it is not for those who only use avpriv_mpeg4audio_sample_rates.
This is in preparation for splitting the latter into a file of its own;
if there were no CONFIG_EXTRA group for *_mpeg4audio_get_config2()
users, one would have to add a dependency to the new file for all
these users on top of the existing dependency on mpeg4audio.o.
Adding a new CONFIG_EXTRA group only takes effect after a reconfigure;
so in order to force a reconfigure some unnecessary headers from
libavdevice/alldevices.c have been removed.
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>
