There is no reason to wrap them in #ifndef guards, they should only be
defined here and nowhere else. The define guards just add the
possibility to accidentally use the same FF_API name in different
libraries.
Fixes memleaks in case the trailer is never written.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_image_copy() expects an array of four pointers according to its
declaration; although it currently only touches pointers that
are actually in use (depending upon the pixel format) this might
change at any time (as has already happened for the linesizes
in d7bc52bf45).
This fixes ticket #9264 as well as a warning from GCC 11.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The problem here is that the lock ctx->frame_lock will become
an unreleased lock if the program returns at patched lines.
Bug tracker link: https://trac.ffmpeg.org/ticket/9386\#ticket
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
The problem here is that the lock ctx->frame_lock will
become an unreleased lock if the program returns at
line 697, line 735 and line744.
Bug tracker link: https://trac.ffmpeg.org/ticket/9385\#ticket
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
It only uses an AVIOContext and an AVBPrint.
When doing so, it turned out that several non-users of
ff_read_line_to_bprint_overwrite() and ff_bprint_to_codecpar_extradata()
relied on libavformat/internal.h to include bprint.h or avstring.h
for them. In order to avoid a repeat of this and in order to reduce
unnecessary dependencies, a forward declaration of struct AVBPrint is
used instead of including bprint.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in 40cf1bbacc.
(The currently disabled filter vf_mcdeint and vf_uspp were users of
this field; they have not been changed, so that whoever wants to fix
them can see the state of these filters when they were disabled.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These are auxiliary side-data functions, so they should have been
switched to size_t in d79e0fe65c,
but this has been forgotten.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The next pointer is kept at the end for backwards compatability until the
major bump, when it should ideally be moved at the front.
Signed-off-by: James Almer <jamrial@gmail.com>
The option allows to select a specific window instead of the whole
screen.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Keep on reading fragments until we got fragment_size amount of data, otherwise
we might get frames with 1-2 samples only if pa_stream_peek is called slightly
less frequently than sample rate.
Note that fragments might contain a lot less data than fragment_size, so
reading multiple fragments to get fragment_size amount of data is intentional.
Signed-off-by: Marton Balint <cus@passwd.hu>
Otherwise we might return 1-2 samples per packet if av_read_frame() call rate is
only sligthly less than the stream sample rate.
Signed-off-by: Marton Balint <cus@passwd.hu>
av_gettime_relative() is using the monotonic clock therefore more suitable for
elapsed time calculations. Packet timestamps are still kept absolute, although
that should be configurable in the future.
Related to ticket #9089.
Signed-off-by: Marton Balint <cus@passwd.hu>
It has been added in 6db42a2b6b,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevice_capabilities_free/create and can already remove the function
pointers at the next major bump; given that the documentation explicitly
states that av_device_capabilities is not to be used by a user, it's
options can already be removed (save for the sentinel).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
xserver defines the endianness of the grabbed images. Use this information
to set the correct pixel format.
This also fixes format selection in configuration depth=32/bpp=32 with
xserver on a little endian machine. Before the patch, the big endian
layout 0RGB was always selected which is incorrect because BGR0 should
be used. RGB24 was also incorrectly assumed (but this format was removed
in xserver 1.20).
The big-endian settings can be tested using docker+qemu from a little-endian
machine:
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker run --rm -it -v /tmp:/tmp powerpc64/debian /bin/bash
In docker container
$ apt-get update
$ apt-get install xvfb
$ apt-get install x11-apps
To test AV_PIX_FMT_0RGB32
$ Xvfb :2 -screen 0 720x480x24 &
$ export DISPLAY=:2
$ xclock -geometry 720x480 -bg green #test different colors
On your host machine grab the frames using the following
command. View output to check that colors are rendered correctly
$ ./ffmpeg -y -f x11grab -i :2.0 -codec:v mpeg2video out.mp4
Other pixel formats can be tested by modifying how Xvfb is started in the docker
container:
AV_PIX_FMT_RGB565
$ Xvfb :2 -screen 0 720x480x16
AV_PIX_FMT_RGB555
$ Xvfb :2 -screen 0 720x480x15
AV_PIX_FMT_BGR24 / AV_PIX_FMT_RGB24
This is difficult to test because bpp=24 support was removed in xserver 1.20
https://lists.x.org/archives/xorg-devel/2018-February/056175.html?hmsr=joyk.com&utm_source=joyk.com&utm_medium=referral
However, I was able to run previous version of Xvfb (with some
modifications to force 24bpp) to check that images are rendered correctly.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
