Substracting 1 to refcount first, means it goes back to unused state
temporarily. It may be picked by another thread as well before calling
atomic_fetch_sub().
In the end we don't need the -1,+1 it's already in the "used once" state (2)
after the atomic_compare_exchange() call.
This also prevent the leak of sys happening when the wrong type of
window is used when opening the display, and move the test after the
trivial check for window type.
The CGL context was destroyed too early, so move around the
vout display removal to prevent using the already-gone context.
Forward port from 3.0.x branch.
Cherry-picked from commit 7d1e7f289d.
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>
This is anyway not properly supported currently so opting in to it
here does not change anything for the better.
Forward port from 3.0.x branch.
Cherry-picked from commit 4591255d8e.
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>
sys->embed was used to store the window created from the display in
pre-3.0 design, but now the display is created after the window and the
window is available in vd->cfg->window.
The sys->embed was storing the same pointer in the normal case, but
ironically, it was undefined in the libvlc embedding case and was
leading to crash.
The SMB modules cannot do the Bonjour lookup, so resolve the hostname
and forward the first IP, which typically is the preferred value.
This fixes vlc-ios#1319
vlc_pa_get_latency() might return an invalid tick ("no timing info")
when the stream was just uncorked from the Drain callback.
To fix this issue, setup the drain timer from the latency callback when
the stream is draining.
AVCodecContext.thread_safe_callbacks will be removed in API 60:
> Thread-unsafe get_buffer2() implementations will be invalid starting
> with LIBAVCODEC_VERSION_MAJOR=60; in other words, libavcodec will
> behave as if this field was always set to 1.
In current FFmpeg 5.0 (API 59), we must still set the variable, and it
is already deprecated, so we can't get rid of the deprecation warning.
ffmpeg/a83098ab03a47179d54a9b9c8bcefc81b9c6aafd (deprecation)
ffmpeg/54e5d21acabb452e5680de5db3bf7567d351d68e (doc)
It appeared the EAGL context buffer allocation fails on tvOS when the display isn't connected.
Given the attached render buffer was incomplete, it led to a crash when a draw was attempted by the renderer.
There are two locations where this patch attempts to improve the situation by prepraring the buffers if a failure was previously encountered :
- As the UIApplicationDidBecomeActiveNotification is dispatched when a screen connection is happening on tvOS, we observe it to restore the render buffers if needed.
- We also try to restore the render buffers when the drawing context is requested from make_current
VSYNC can easily happens in multiple modules at the same time, and the
CFRunLoop code to avoid deadlock seems to lead this to inversions, so
remove the VSYNC when disabling the window.
I hate the myself of 2years ago for the lack of explanion on the
original commit. But DTS 14b inside WAV is now played as PCM, using the
same receiver with the same Windows machine than 2 years ago.
Reverting this commit fix it (for 14b and 16b). Maybe a receiver or a
Windows update fixed it ?
This reverts commit 3c68e5ff1f.
Previously, the volume and mute properties would read their default
values (0 and false respectively) since neither Open() or Start()
would call aout_{Volume,Mute}Report by themselves.
Now, the initial volume and mute status are read during Start(), which
means that setting the volume should work after the first
volume_changed event is received by a libvlc consumer.
Partial workaround for #26032.
As a result, reporting the volume level after (un)muting is no longer
necessary (d104faec19).