The proper type was used until 73251678c8.
This covers all of the OS's that currently have V4L2 support, permutations
of Linux glibc/musl, Android bionic, FreeBSD, NetBSD, OpenBSD, Solaris.
Copied from FreeBSD ports patch.
Signed-off-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also update the checks that guard against inserting
a new enum entry in the middle of a range.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and rename it to FF_INFMT_INIT_CLEANUP. This flag is demuxer-only,
so this is the more appropriate place for it.
This does not preclude adding internal flags common to both
demuxer and muxer in the future.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both GCC and Clang create code that inlines the loops in
next_input() and next_output() at high optimization
levels (presumably when there are not too many devices)
and this code leads to the creation of .got entries:
e7: 48 3b 3d 00 00 00 00 cmp 0x0(%rip),%rdi # ee <av_input_video_device_next+0xe>
ea: R_X86_64_REX_GOTPCRELX ff_alsa_demuxer-0x4
ee: 74 43 je 133 <av_input_video_device_next+0x53>
f0: 48 3b 3d 00 00 00 00 cmp 0x0(%rip),%rdi # f7 <av_input_video_device_next+0x17>
f3: R_X86_64_REX_GOTPCRELX ff_fbdev_demuxer-0x4
f7: 74 41 je 13a <av_input_video_device_next+0x5a>
These relocations can't be fixed up lateron when it is known
that the symbols exist in the same DSO.
This commit therefore marks these symbols as hidden, leading
to code like this:
f7: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # fe <av_input_video_device_next+0xe>
fa: R_X86_64_PC32 ff_alsa_demuxer-0x4
fe: 48 39 c7 cmp %rax,%rdi
101: 74 55 je 158 <av_input_video_device_next+0x68>
103: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # 10a <av_input_video_device_next+0x1a>
106: R_X86_64_PC32 ff_fbdev_demuxer-0x4
10a: 48 39 c7 cmp %rax,%rdi
10d: 74 50 je 15f <av_input_video_device_next+0x6f>
(Note: It is actually strange that the compiler creates code
that tries to read the addresses from the .got given that the
addresses can be read directly from indev_list/outdev_list.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit does for AVInputFormat what commit
59c9dc82f4 did for AVOutputFormat:
It adds a new type FFInputFormat, moves all the internals
of AVInputFormat to it and adds a now reduced AVInputFormat
as first member.
This does not affect/improve extensibility of both public
or private fields for demuxers (it is still a mess due to lavd).
This is possible since 50f34172e0
(which removed the last usage of an internal field of AVInputFormat
in fftools).
(Hint: tools/probetest.c accesses the internals of FFInputFormat
as well, but given that it is a testing tool this is not considered
a problem.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Makes it robust against adding fields before it, which will be useful in
following commits.
Majority of the patch generated by the following Coccinelle script:
@@
typedef AVOption;
identifier arr_name;
initializer list il;
initializer list[8] il1;
expression tail;
@@
AVOption arr_name[] = { il, { il1,
- tail
+ .unit = tail
}, ... };
with some manual changes, as the script:
* has trouble with options defined inside macros
* sometimes does not handle options under an #else branch
* sometimes swallows whitespace
This can be achieved by using AV_OPT_TYPE_FLAGS instead of
AV_OPT_TYPE_STRING. It also avoids strcmp() when accessing
the option.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It implements BSD-specific support for very old analog capture cards,
which are highly unlikely to be useful today. After being added in 2005,
there were never any commits to it beyond compilation fixes and generic
maintenance. There have also been zero trac tickets for this device, and
the only related web search result I found concludes that it does not
work.
The code also does some unacceptable things, like messing with signal
handlers and storing its state in global variables.
Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:
src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long' [-Wint-conversion]
280 | hwnd = strtol(name, &p, 0);
| ^ ~~~~~~~~~~~~~~~~~~~
(With GCC and MSVC, this was a mere warning, but with recent Clang,
this is an error.)
After adding a cast, all compilers also warn something like this:
src/libavdevice/gdigrab.c:280:16: warning: cast to 'HWND' (aka 'struct HWND__ *') from smaller integer type 'long' [-Wint-to-pointer-cast]
280 | hwnd = (HWND) strtol(name, &p, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
On Windows, long types are 32 bit, so to get a usable pointer, we
need to use long long. And interpret it as unsigned long long
while at it - i.e. using strtoull.
Finally, right above it, the code triggered the following warning:
src/libavdevice/gdigrab.c:278:15: warning: mixing declarations and code is incompatible with standards before C99 [-Wdeclaration-after-statement]
278 | char *p;
| ^
Signed-off-by: Martin Storsjö <martin@martin.st>
x11grab can capture windows by their ID, but gdigrab can only capture
windows by their names, internally calling FindWindowW to lookup its
handle.
This patch simply allows the user to specify a window handle directly.
Signed-off-by: Lena <lena@nihil.gay>
<OS>_VERSION_MAX_ALLOWED indicates what version is available in
the SDK, while <OS>_VERSION_MIN_REQUIRED is the version we can
assume is available, i.e. similar to what is set with e.g.
-miphoneos-version-min on the command line.
This fixes build errors like these:
src/libavdevice/avfoundation.m:788:37: error: 'AVCaptureDeviceTypeContinuityCamera' is only available on macOS 14.0 or newer [-Werror,-Wunguarded-availability-new]
[deviceTypes addObject: AVCaptureDeviceTypeContinuityCamera];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVCaptureDevice.h:551:38: note: 'AVCaptureDeviceTypeContinuityCamera' has been marked as being introduced in macOS 14.0 here, but the deployment target is macOS 13.0.0
AVF_EXPORT AVCaptureDeviceType const AVCaptureDeviceTypeContinuityCamera API_AVAILABLE(macos(14.0), ios(17.0), macCatalyst(17.0), tvos(17.0)) API_UNAVAILABLE(visionos) API_UNAVAILABLE(watchos);
^
Alternatively, we could use these more modern APIs, if enclosed
in suitable @available() checks.
Building with macOS platform, the compiler has a warning: 'kAudioObjectPropertyElementMaster' is deprecated in macOS 12.0
Signed-off-by: xufuji456 <839789740@qq.com>
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession instead"
Signed-off-by: xufuji456 <839789740@qq.com>
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.coded_side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer <jamrial@gmail.com>
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If not set, the muxer will not receive a NULL packet in
the write_packet function") it is actually an internal flag
that has been publically exposed because there was no internal
flags field for output formats for a long time. But now there is
and so use it by replacing the public flag with a private one.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
After the AVFrame has been wrapped into a buffer,
it is owned by the buffer and must not be freed manually
any more. Yet this happens on subsequent errors.
This bug was introduced in 6ca43a9675.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_image_copy() accepts const uint8_t* const * as source;
lots of user have uint8_t* const * and therefore either
cast (the majority) or copy the array of pointers.
This commit changes this by adding a static inline wrapper
for av_image_copy() that casts between the two types
so that we do not need to add casts everywhere else.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Broken in 0c6e5f321b.
Also add it to decklink_enc.cpp in order not to rely
on an implicit inclusion via libavfilter/ccfifo.h.
Reviewed-by: あんこ <mailcrystaldiskinfo@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodec is only ever used as an incomplete type (i.e. via a pointer
to an AVCodec) in avformat.h and it is not really part of the core
of avformat.h or libavformat; almost none of our internal users
make use of it (and none make use of hwcontext.h, which is implicitly
included). So switch to use struct AVCodec, but continue to include
codec.h for external users for compatibility.
Also, do the same for AVFrame and frame.h, which is implicitly included
by codec.h (via lavu/hwcontext.h).
Also, remove an unnecessary inclusion of <time.h>.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
glcontext was added under CONFIG_SDL2
libavdevice/opengl_enc.c: In function ‘opengl_draw’:
libavdevice/opengl_enc.c:1204:15: error: ‘OpenGLContext’ has no member
named ‘glcontext’
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Since “2d924b3a63 fftools/ffmpeg: move each muxer to a separate thread”,
opengl_write_packet() is called from a different thread than
opengl_write_header() and would nothing for lack of a selected context.
BMDTimeValue is defined as LONGLONG on Windows, but int64_t on Linux/Mac.
Fixes format string warnings:
libavdevice/decklink_enc.cpp: In function ‘void construct_cc(AVFormatContext*, decklink_ctx*, AVPacket*, klvanc_line_set_s*)’:
libavdevice/decklink_enc.cpp:424:48: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 4 has type ‘BMDTimeValue {aka long int}’ [-Wformat=]
ctx->bmd_tb_num, ctx->bmd_tb_den);
~~~~~~~~~~~~~~~ ^
libavdevice/decklink_enc.cpp:424:48: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 5 has type ‘BMDTimeValue {aka long int}’ [-Wformat=]
Signed-off-by: Marton Balint <cus@passwd.hu>
Support decoding and embedding VANC packets delivered via SMPTE 2038
into the SDI output. We leverage an intermediate queue because
data packets are announced separately from video but we need to embed
the data into the video frame when it is output.
Note that this patch has some additional abstraction for data
streams in general as opposed to just SMPTE 2038 packets. This is
because subsequent patches will introduce support for other
data codecs.
Thanks to Marton Balint for review/feedback.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
