That makes our usage of mingw-w64 structures like stat, _stat32, _stat64i32
invalid. Plus calls to functions expecting a smaller type.
If we need a bigger type, we need to use our own.
We already set _FILE_OFFSET_BITS so that off_t can be larger than usual.
The existence of search.h is not relevant for that. search.h may exist but does
not provide tfind, as on Windows.
If tfind.c is included for compilation, then the code needs to be built.
We only need to define them if they are used in an API but they are not. The
names are very generic and may collide with some defines, so avoid potential
compilation issues.
Only the VISIT enum is needed by twalk().
So that we don't have to include search.h each time vlc_fixups.h is used.
The Win32 prototype of lfind() expects an unsigned* for 'nelp', not a size_t*.
For input items without a know type (imem access for example) preparsing
is not possible. With this option we allow forcing the preparsing in that
case, optionally. By default the current behavior remains the same.
For users of libvlc with manual DLL loading (especially languages not
compatible with C that have to recode the access to the libvlc DLL) it is
important to know the ABI version of the DLL, in case of API/ABI changes the
wrapper need to be updated and know when the provided DLL package matches or
not. This is especially critical for VLC 4.0 which has not changed version in
4 years and yet the libvlc API keeps changing.
This is similar to the versions of libavcodec/libavformat/etc. When the API is
changed the version values should be updated as well, and hopefully documented
as well.
One should avoid loading the DLL of a mismatching libvlc major ABI version.
Since it's likely to not be usable in the end, it's better not to load it at
all.
This should also be backported to VLC 3.0.
We don't need to know it's a pointer and can save 2 characters.
No functional changes. This is simply renaming "dec->p_fmt_in",
"decoder->p_fmt_in", "dec.p_fmt_in" and "packetizer->p_fmt_in"
The function was only used by the two last visualization modules, but is
now unused and unfit to the purpose of push model. Pools should be
created locally instead of from the video output.
Removing the function allows simplifying the video output.
This fixes a compilation error on OS/2:
-----
CC stream_out/udp.lo
stream_out/udp.c: In function 'CreateSDP':
stream_out/udp.c:89:16: error: 'INET6_ADDRSTRLEN' undeclared (first use in this function); did you mean 'INET_ADDRSTRLEN'?
89 | char dhost[INET6_ADDRSTRLEN];
| ^~~~~~~~~~~~~~~~
| INET_ADDRSTRLEN
stream_out/udp.c:89:16: note: each undeclared identifier is reported only once for each function it appears in
stream_out/udp.c:89:10: warning: unused variable 'dhost' [-Wunused-variable]
89 | char dhost[INET6_ADDRSTRLEN];
| ^~~~~
-----
This was missing from the current implementation of DoVi, which only
forwarded the per-frame RPUs. This is, however, insufficient for all
consumers of this metadata - some will need to decide whether DoVi
reshaping is required or not up-front, at init time. To do this cleanly
we need access to the stream-wide DoVi configuration record.
The main constructor, accepting a pointer, is explicit:
my_ptr_type *p = ...;
MySharedPtr ptr = p; /* invalid */
MySharedPtr ptr{ p }; /* ok */
This prevents to mistakenly assign a pointer to a shared pointer.
However, assignment to nullptr should be acceptable:
MySharedPtr ptr = nullptr; /* should be ok */
When the input is stopped or an error occurred, the capabilities
should reflect that, so that on_capabilities_changed is invoked
as expected.
Fix#27047
There is no usage for picture_pool_Cancel anymore. The pool cancellation
was a mechanism for asynchronous signalling within decoders that the
decoder was being flushed and that waiting on picture could be
cancelled. Since it was a concern for decoders, it was moved to the
decoder handling code by ensuring the decoder has enough picture to
finish decoding and reach the pf_flush function.
vlc_fifo_t are coming with their own lock which is exposed on the public
interface, so provide sanitization state check functions like those
available for vlc_mutex_t.
It is currently unspecified what happens if the process does not exit
cleanly, so clarify that. Since this can actually happen, the
documentation ought to state what the result is to some extent.
There's no other object that can handle the configuration loading/saving.
We don't need to inherit the options, they can only be in the libvlc_int_t
object. var_GetNonEmptyString() is equivalent to var_InheritString() in that
case.
My bad, libvlc_time_t is in ms. The timer API should use the sane unit
than libvlc_clock(), that is us in int64_t.
Also add missing vlc_tick_t <-> us conversion (no harm since 1 tick = 1
us for now).
Any LibVLC users could request a timer from the player. This Media Player
timer has its own event API since:
- It is only used to receive time update points:
- The timer is not locked by the player lock. Indeed the player lock can be
too "slow" (it can be recursive, it is used by the playlist, and is it held
when sending all events). So it's not a good idea to hold this lock for
every frame/sample updates.
- The minimum delay between each updates can be configured: it avoids to flood
the UI when playing a media file with very high fps or very low audio sample
size.
The libvlc_media_player_time_point struct is used by timer update
callbacks. This public struct hold all the informations to interpolate a
time at a given date. It can be done with the
libvlc_media_player_time_point_interpolate() helper. That way, it is
now possible to get the last player time without holding any locks.
There is only one type of timer (for now):
libvlc_media_player_watch_time(): update are sent only when a frame or a
sample is outputted. Users of this timer should take into account that
the delay between each updates is not regular and can be up to 1seconds
(depending of the input). In that case, they should use their own timer
(from their mainloop) and use
libvlc_media_player_time_point_interpolate() to get the last time.
The window backend triggers a callback of the vout, and the vout
forwards this to the display using another callback. There are several
unfortunate layers of glue and indirections in the callchain. In
particular, we need to persist these ICC profile objects in some layer,
because of init order between windowing system and the window / vout
display module itself. I've chosen to add them to `vout_display_cfg_t`
because it fits well with the other "dynamic window state" properties in
there.
This approach also allows capable vouts to read directly from the
allocated ICC profile memory, minimizing the number of memcpys.
The API is available on UWP builds and doesn't rely on dirent which may not be
compiled as UNICODE in mingw-w64.
The call to FindFirstFileExW already gets the first entry so we are always
ahead of one entry.
This will avoid some dirty casts between DIR and vlc_DIR on Windows.
The Windows handling could be done entirely without dirent.h which is not a
standard Windows API.
When compiling and not having writev/readv, the following error happens:
make[2]: Entering directory '/home/janniaux/Projects/videolabs/vlc/build-tsan/compat'
CC strlcpy.lo
CC strnstr.lo
In file included from ../config.h:952,
from ../../compat/strnstr.c:22:
../../include/vlc_fixups.h:232:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
232 | ssize_t readv(int, const struct iovec *, int);
| ^~~~~~~
| size_t
In file included from ../config.h:952,
from ../../compat/strlcpy.c:22:
../../include/vlc_fixups.h:232:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
232 | ssize_t readv(int, const struct iovec *, int);
| ^~~~~~~
| size_t
../../include/vlc_fixups.h:237:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
237 | ssize_t writev(int, const struct iovec *, int);
| ^~~~~~~
| size_t
../../include/vlc_fixups.h:237:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
237 | ssize_t writev(int, const struct iovec *, int);
| ^~~~~~~
| size_t
make[2]: *** [Makefile:1531: strnstr.lo] Error 1
win64 has its own version of lfind() but assumes the 3rd parameter is an
unsigned.
This commit matches the #ifdef _WIN64 below this code which uses the Windows
version with the unsigned limit. The comment is copied from there as well.
This is the first step for the `SetPCR` implementation in stream output.
These callbacks will allow stream outputs to have precise information
about the stream time advancement.
This patchset only provides the basis for now, a correct implementation
for all stream filters will come in a separate merge request.
Refs #27050
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
This partially reverts commit 02293b1df3.
Don't update the audio clock from this event but store the points in a
circular buffer. The play function will update the clock according to
these points.
Refs #27023
vlc_stream_ReadPartial() is similar to pf_read of stream_t. It is often used
as such in pf_read callbacks.
vlc_stream_Read() uses it that way as well. On negative return values (-1)
it continues reading.
Internally it's calling vlc_stream_ReadRaw() which also returns pf_read return
values verbatim.
We store the ICC profile as part of the (ancillary) data allocation,
using a trailing unsized array. This is because we need to copy it in
and out of various libraries anyway, to avoid having to expose things
like AVBufferRef.
The (as of writing) current ICC specification can be found at
https://www.color.org/specification/ICC.1-2022-05.pdf
Document that the function must be called with a context enabled. Even
if most low-level implementation will allow getting an address without
a context, so as to keep the same symbol across contexts, some other
common implementations like glfw[^1] will require an active context.
[^1]: https://www.glfw.org/docs/3.3/group__context.html#ga35f1837e6f666781842483937612f163
The semantics and names mimick the C/C++2X latch. Latches are a
generalisation of barriers, whence counting down and waiting are
(or rather, can be) done separately.
Note that the C2X uses ptrdiff_t but with does not define negative
values. This uses size_t instead, not squandering the sign bit.
So far the video can only be fit within the window. This adds other
modes for fitting to the larger dimension, only to the width or only to
the height. These new modes in effect compute the scale/zoom
differently, potentially causing the video to be cropped.
The warning was always triggered because __builtin_constant_p actually
checks whether the tested value is constant at compile time and strlen()
was never constant at compile time.
Note that __builtin_constant_p can be used with a non-constant test
expression while using the same expression after ? in a ternary
condition.
Replace typeof by a decltype()-based equivalent on compilers not
supporting typeof.
Decltype is not equivalent to typeof, but we are mostly concerned about
removing references from the type, since it has no use in C code like
VLC list.
Note that this fixup is there to fix the usage of headers using typeof
in C++ code, not to provide "typeof" directly C++ to replace decltype.
It exists in very old gcc and clang.
VLC_WARN_CALL/VLC_ERROR_CALL may not warn though.
Don't define check_delay/check_deadline otherwise and don't force the
vlc_tick_sleep/vlc_tick_wait calls.
Like on x86 (e.g. VLC_SSE), this macro enables the use of AltiVec for
just a given function. Thus the other functions in the same C module
can be compiled without AltiVec and run on non-AltiVec processors.
This puts all the video size and placement properties back together as
vout_display_cfg_t originally was before other parameters were added.
No functional changes.
Steve Lhomme