- 19 May, 2021 5 commits
-
-
-
-
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).
-
-
- 12 May, 2021 3 commits
-
-
-
vlc_player_AddAssociatedMedia() was only accepting audio and spu.
-
Indeed, video slaves are also valid.
-
- 07 May, 2021 2 commits
-
-
Signed-off-by:
Martin Finkel <martin@videolabs.io> -
Signed-off-by:Martin Finkel <martin@videolabs.io>
-
- 05 May, 2021 1 commit
-
-
(add common defines for specifying hidden category/subcategory)
-
- 02 May, 2021 9 commits
-
-
This adds new functions to list and access the medialibrary folder interface.
-
As theses ml calls actually simply list folders, moving them to the "VLC_ML_LIST" interface makes more sense.
-
-
-
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.
-
The medialibrary has files sizes and last modification dates in its database. This patch exposes theses two previously ignored values.
-
- 01 May, 2021 4 commits
-
-
Hugo Beauzée-Luyssen authored
Co-authored-by:
Romain Vimont <rom1v@videolabs.io> -
Function actually works on #RRGGBB[AA] not #[AA]RRGGBB. AARRGGBB is the order of color channel bytes (MSB...LSB) in the returned integer.
-
docs listed named and hex, but not decimal-based rgb[a], which the function does actually support
-
-
- 30 Apr, 2021 1 commit
-
-
- 29 Apr, 2021 1 commit
- 27 Apr, 2021 1 commit
-
-
- 20 Apr, 2021 1 commit
-
-
Signed-off-by:
Pierre Lamot <pierre@videolabs.io>
-
- 16 Apr, 2021 1 commit
-
-
Signed-off-by:Pierre Lamot <pierre@videolabs.io>
-
- 02 Apr, 2021 3 commits
-
-
Steve Lhomme authored
-
Steve Lhomme authored
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.
-
Steve Lhomme authored
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.
-
- 28 Mar, 2021 1 commit
-
-
Jean-Baptiste Kempf authoredClose #22534
-
- 22 Mar, 2021 1 commit
-
-
Signed-off-by:Alexandre Janniaux <ajanni@videolabs.io>
-
- 15 Mar, 2021 2 commits
-
-
Rémi Denis-Courmont authoredFor 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 c9d6d95f, 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.
-
Signed-off-by:Pierre Lamot <pierre@videolabs.io>
-
- 01 Mar, 2021 4 commits
-
-
Alexandre Janniaux authored
This will allow offscreen OpenGL implementations, which will produce picture_t. Co-authored-by:
Romain Vimont <rom1v@videolabs.io>
Signed-off-by: -
As explained by 758052fa , a filter does not take ownership of the config_chain_t instance, and never needs a non-const pointer. Signed-off-by:
-
Thomas Guillem authored
-
Signed-off-by:Pierre Lamot <pierre@videolabs.io>
-
