C compilers can have GNU extensions to support typeof in C code, but
some C++ compilers like clang are removing the builtin since decltype
can be used in C++ without the constraints from typeof. Decltype is not
100% equivalent for this reason: references will be kept in the returned
type.
The check in m4/typeof.m4 comes from graydon/monotone and dovecot/core
and was slightly modified to namespace the define for C++ code.
in previous code, for path "C:/image.jpg", the url scheme will be "C" and
the call to QQmlFile::urlToLocalFileorQrc with fail since url scheme is not "file"
but the provided input path is valid file path, fix such cases
x-test syntax (x$foo = xyes/xno) is used to circumvent the fact that
shell variables are substituted and not just defining an argument, so
that $foo doesn't expand to no argument at all.
But "" in posix shell syntax is considered as an argument by itself, so
using quotes around the variable removes this issue. Thus, x-test is
useless in the case where it has been removed in this patch.
Looking through the tar command line help is brittle, and as a matter of
facts fails miserably with non-English locales.
Just feed a sorted list of files for tar to archive instead. This should
work regardless of the tar tool version in use.
Fixes Debian #990247.
The interface cannot be closed before the vout_window_t object is
disabled, since the playlist/player is running from outside the
interfaces.
When it happens, a warning was raised from skins2 and the OpenGL code
would stay stuck waiting for xcb events, preventing the full closing of
the interface resources and delaying the close of the application itself.
This commit ensures that no skins2 window is enabled before leaving the
Close function from the interface, and no new skins2 window will be
enabled in a racy pattern while or after the Close function from the
interface is running.
The issue was highlighted in previous commit, including the commit
04409ebd45 which required in its commit
description that interface modules should outlive the vout window
instances they provide, but didn't provide a mechanism to do so.
The added mutex was removed in 6083d3f103
because it was useless as-is. This commit adds a reference count of
opened window, and a wait for this reference count to reach zero before
ending the interface Close() function, which justify the use of a mutex.
Note also that this patch uses the Enable/Disable lifecycle of the
window to manage the reference count and skins2 resources, because
there is an inversion between the playlist destruction and the
interface destruction.
We cannot wait for the vout_window_t object to be destroyed while we're
waiting in the interface Close(), since the vout is potentially reused
up to the playlist destruction (or more precisely, input resource
destruction) which can only happen after every interface is destroyed.
The implementation here is a bit different to what has been done for
other interfaces like Qt. The Qt interface is creating a new libvlc
object and stashes the interface state there, while refcounting it.
It means that the interface implementation itself will continue to exist
even if the interface object is dead. It has particular benefit when
the interface is not the usual interface but a dialog provider one.
The submitted approach here tries to keep the lifecycle of the
interface tied together with its object, to simplify the use of its
object for variable or logging, and avoid unnecessary object allocation.
The destination texture (sys->sceneTexture) has the visible dimensions, not the
decoder dimensions.
Factorize the size processing for the stretching and the vertex computing.
Ref. https://forum.videolan.org/viewtopic.php?f=14&t=159861
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.
As it has become a one-liner function.
`assert( !sout_frame->p_next );` is irrelevant as `sout_frame->p_next`
is guaranteed to be NULL by the calling code anyway.
Currently, a decoder thread is spawned to handle both the display and
the stream output. The decoder thread is actually unneeded by the stream
output as packetizing is the only task to do before forwarding the data
to the stream output. No heavy decoding is involved.
In addition to make the runtime lighter for stream output, having the
sout handling synchronous would help a lot for the implementation of
`PCR` forwarding in stream output (see !1394) as the asynchronous
`SetPCR` handling could be then managed in transcode only.
This patch removes the decoder thread usage in stream output scenarios
directly in the `vlc_input_decoder`. While this is far from ideal and
looks hacky, it's the best way I found to not change the code base too
much and not introduce unseen regressions right before 4.0 release.
These changes can be considered temporary as the plan in the long run
(after 4.0) is to remove stream output mention from `vlc_input_decoder`
and create a stream output specific `es_out` implementation.
Refs #26870#26825
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 was added ostensibly to fix compilation of the run-time AltiVec
test which was removed in bc146294cf.
Unfortunately, it causes the compiler to emit AltiVec instructions,
such that the executable crashes if AltiVec is not available.
Regression from e48d619555.
This gets set explicitly when the video output is started, which always
results in the window being (re)enabled. Conversely, this gets
implicitly unset when the video output is stopped, which always results
in the window being disabled.
Alexandre Janniaux