Some encoders, like MediaCodec, provide SPS/PPS packets only when
decoding is started (in pf_encode_video). This is too late, because the
muxer is already open.
To avoid the problem, add the stream only when the encoder output format
is known.
Instead of using a custom cfg with an extra "audio filter".
i_chan_mode is already used by "audio converter" for dolbystereo.
The spatialaudio "audio filter" is converted to an "audio converter".
Such type of modules are loaded automatically when a conversion is needed
(the chan_mode conversion). Since this module is now an "audio
converter", don't override in/out fmt, but test for in/out fmt
compatibility.
The aout->current_sink_info.headphones special case is handled after the
aout is started. At this point, only the filters need to be updated (via
filters_cfg).
Now that the `vlc_ml_folder_list_t` replaced `vlc_ml_entry_point_list_t`
the VLC_ML_LIST_FOLDER enum value is a bit confusing and is renamed
VLC_ML_LIST_ENTRY_POINTS to better reflect its functionnality.
This better reflects the medialibrary internals while also allowing more
flexible medialibrary folder listing as vlc_ml_folder_t is now available
through a more generic name.
added against a function in d3fe7f2879,
left for seemingly no reason in e5fdeda43a
when the function it related to was removed
does not apply to the static array which is very much in use
ID3D11DeviceContext is a resource than should be protected in some cases. In
particular the hardware decoders must not do concurrent calls. So any use of
the same ID3D11DeviceContext must be protected as well. In VLC it is handled
but when the ID3D11DeviceContext comes from the host app it must also to the
same protection when using it outside of libvlc calls.
Setting this mutex in a GUID_CONTEXT_MUTEX private data is reserved for legacy
(UWP) apps.
This is more flexible as it doesn't depend on a shared ID3D11DeviceContext.
A NULL callback is still allowed as long as the host app does the
OMSetRenderTargets on their single ID3D11RenderTargetView.
For perfect rendering synchronisation, the change of window size must
be acknowledged after the last picture is rendered in the old size,
and before the first picture is rendered in the new size.
As of c9d6d95f29, the window resize is
processed synchronously. This provides for the "after" requirement. But
it failed to address the "before" requirement: the video output thread
can end render a picture so soon after the resize so the window
callback thread has not had time to perform acknowledgement procedures.
This adds a callback to the window resize event which is called before
the display lock (or equivalent) is released. This is guaranteed to be
invoked before the video output thread has the opportunity to render
anything.
Other options were considered:
1) Invoking a callback to the window provider from the video output
thread code code.
-> This can delay the callback unreasonably.
-> Taking the window lock on the video output thread is undesirable
if at all possible.
2) Invoking a windowing system type-specific callback to the window
provider from every display of that windowing system.
-> Same delay and locking problems as 1.
-> Requires patching several display plugins.
3) Exposing the display lock to the window plugin, via new callbacks.
-> This leaks internal implementation of the core to window
providers.
-> This gets really confusing as some callbacks would need explicit
locking and others not.
In comparison, this patch seems like the least of evils.
The callback is passed a parameter rather than as a property of the
window to distinguish it from the existing window callbacks which are
not reentrant.
Refs #25112.
This will allow offscreen OpenGL implementations, which will produce
picture_t.
Co-authored-by: Romain Vimont <rom1v@videolabs.io>
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>
As explained by 758052fa44, a filter does
not take ownership of the config_chain_t instance, and never needs a
non-const pointer.
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>