We require mingw-w64 v8 since e5725fe5cd which
has it properly defined.
And HAVE___X_ABI_CWINDOWS_CSTORAGE_CIAPPLICATIONDATA2 was not defined in meson.
These functions use the same code on both variants of Windows:
- config_GetSysPath()
- config_GetLibDir()
These functions are not the same:
- platform_GetUserDir()
They are all internal to the core.
It should return the folder where private executables are.
For an installed/packaged VLC on Windows that's the root of the VLC folder,
where vlc-cache-gen.exe is, which is the same folder as vlc.exe. For libvlc
users that should be the same although it's not guaranteed.
The only known variable is $(SUBLIBS) in LIBS which is a variable that doesn't exist in the
makefile. It's only found when Qt is compiled as dynamic libraries.
We just skip the variable.
Without this $(SUBLIBS) is passed to the Makefile with the other libs.
This is fine with autotools which ignores the undefined variable.
But meson doesn't like it.
Ref. #29585
Although it is not as rapid as size change (layer resize case), comparison key
may still change often. Now that we have a property to enable notify all
changes, we can make comparison key changes not notified by default.
When `true` (by default `false`), all properties are notified on change.
This property may be set to `true` when the source is a static texture.
It is strongly discouraged to set it `true` for rapidly changing cases,
such as when the source is a layer, since if the connections are queued,
they can easily backlog when the texture changes rapidly (such as with
resize).
`onNextTextureChange` was meant for effective change, not necessarily
if the texture actually changes. This means that if both the previous
and the next textures the same but differ in sub-rect (such as, being
different parts of the atlas), an update should be scheduled.
The parameter is renamed to `onNextEffectiveTextureChange` to reflect
the changed behavior.
This was not considered before, because the use case in `Player.qml`
requests the texture to be mipmapped, which means that the texture
would not be placed in the atlas and normal rect would remain
(0.0, 0.0, 1.0, 1.0) while the actual texture changes. The problem
is that there is no guarantee that the texture is going to be mip-
mapped, even if explicitly requested.
This fixes background blur effect not updated on track change in
the player page.
Previously, vlc_process_Spawn unconditionally passed STDERR_FILENO (2)
to the spawner.
The code was missing validation for this descriptor. As a result, it
passed an invalid handle when stderr was not associated with a stream,
which caused process creation to fail.
This failure was observed in the logs as:
> main libvlc error: Fail to create Process in process_pool
To safely pass a file descriptor, we must use _get_osfhandle to
validate that it points to a real handle. On Windows, this function
returns the special value -2 (indicating no associated stream). This
patch adds the missing check ensuring we only pass STDERR_FILENO if
the underlying handle is valid (neither -1 nor -2).
Update to the latest available stable sparkle release.
This sparkle release supports macOS 10.13 as minimum version,
which is the minimum version we require on VLC 4 now as well.
If artwork is undefined/null, fallback is not used because the mechanism that
switches to the fallback source is activated when the status becomes
`Image.Error`. In undefined/null case, the source ends up being an empty string,
which makes the status `Image.Null`, rather than `Image.Error`.
Currently we are not additionally checking if the address is available but
empty.
It is not deterministic relative to the time it takes to update the properties,
currently in some cases properties may be updated before `sourceChanged()` is
emitted and in some cases not, depending on the pace of the rendering and the
rendering thread.
If we signal the change immediately after the source changes, we don't have
this problem.
Currently this is asymptomatic, but better to correct it.
This is mostly relevant when the new source is null (no more source),
since if there is a new source the properties would be updated in
most cases in 1/FPS, if everything goes well, provided that the new
source is a texture provider.
This eases maintenance, because we don't need to have additional
rectangle where `DualKawaseBlur` is reused depending on the
graphics backend when background coloring is wanted.
This fixes exposing what is underneath, provided that the source texture is not
ready or was invalidated.
This is especially problematic when switching to the player page, because bare
window may be exposed, which means in most cases what is beneath the interface
window getting exposed (such as the desktop). We currently rely on transparency
to expose the video window, so this is not limited to window backdrop blur case.
This should also fix the same in other situations, such as switching the artist
in the artists page, but I can still reproduce the issue. It appears that this is
because when `Image` source changes to another valid source, its texture (it is a
texture provider) is not invalidated in between (even though we are not using
`retainWhileLoading`). This issue is handled with a workaround in a later commit.
Note that if blending is set to false, which may be due to automatic adjustments,
any translucent fragment is going to punch a hole in the interface. This may be
a problem during texture changes, since `DualKawaseBlur` makes the decision on
whether to use blending or not based on what the texture says. This decision is
routed through the QML engine due to technical reasons, so it is not possible to
fix this problem completely. If that is a problem, `blending` may be set to `true`
manually or the source texture may be invalidated before switching to a new
texture with different properties (such as old texture is opaque while new one
is translucent). Currently this is not a symptomatic matter therefore is not
considered to be a problem.
There are 2 now paths, the legacy path (before API 30) and the AImage
path (after API 31).
The new AImage path:
- No more inflight pictures: picture can outlive the decoder and be
displayed more than one time (the AImageReader need to outlive all
pictures but it's handled naturally from the video context).
- Can be rendered by OpenGL or directly (ASurfaceControl), without
hardcoding it before creating MediaCodec (contrary to the legacy path)
fmt_out color should already be set by the demuxer or the packetizer.
I don't know if there is a possibility that the hdr metadata is found by
the decoder and not by our demuxer or packetizer.
Will replace MediaCodec direct rendering once AImageReader is handled by
MediaCodec.
- Support HDR metadata (should be the same than legacy vout).
- Fully support vout crop/scale/size controls, without the need to
external JNI calls to libvlcjni AWindow class.
- Support picture re-display (it was not possible before)
Both APIs are avalaible since API 29+, but some new functions were added
in API 31. As I don't want to add a third behavior to test (legacy,
API29, API31), I force usage of API31+ to enable new AImageReader /
ASurfaceControl path.
François Cartegnie
Steve Lhomme
Fatih Uzunoglu
Krish Ganatra
David Fuhrmann
Thomas Guillem