- May 18, 2021
-
-
Martin Finkel authored
-
Martin Finkel authored
-
Martin Finkel authored
-
- May 12, 2021
-
-
Martin Finkel authored
-
- May 02, 2021
-
-
vd->source doesn't contain the new chroma that has been chosen by the chroma fallback mechanism, so when using VAAPI chroma, it was leading to the display module trying to use a VAAPI libplacebo format description although it doesn't have one, and thus leading to NULL dereferencement.
-
Add a `vulkan platform` implementation for wayland, effectively enabling the usage of the vulkan libplacebo display on Wayland environments.
-
The header is mostly unused now.
-
-
-
The platform support has been offloaded to the `vulkan platform` capability, keep the `vulkan` capability to provide multiple Vulkan implementation through the VkInstance and initial functions pointers.
-
-
On Windows the swapchain might not be re-created automatically, which results in glitches when using the vk output. This enforces the creation of the swapchain as soon as the display size is changed. On Wayland, the size of the window is the size of the content so there is no automatic swapchain sizing and this call is mandatory. Co-authored-by:
Niklas Haas <git@haasn.xyz>
-
Instead of recompiling surface.c while implementing its public functions, and so as to remove surface.c.
-
Instead of recompiling surface.c while implementing its public functions, and so as to remove surface.c.
-
Instead of recompiling surface.c while implementing its public functions and so as to implement the wayland surface provider side by side with the XCB surface provider.
-
The vulkan providers are not supposed to depend upon libplacebo, and only the display is supposed to bring the libplacebo dependency. In addition, many of the libplacebo options are designed for the display.
-
-
Instead of recompiling surface.c while implementing its public functions and so as to implement the wayland surface provider side by side with the XCB surface provider.
-
The platform string will be used by vulkan implementation not following the surface.c implementation so as to remove it later.
-
libplacebo 1.18 is required for pl_swapchain_resize.
-
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.
-
Switch to a more generic error message. Theses errors message can be triggered by local filesystem errors or any timeouts. Assuming all the errors will come from network is incorrect and potentially misleading.
-
-
The medialibrary has files sizes and last modification dates in its database. This patch exposes theses two previously ignored values.
-
Previously, input_files's slaves where just ignored while creating ml files. These changes take into account these files, create them in the ml hierarchy and link them with their relatives.
-
Previously, input_files's slaves where just ignored while creating ml files. These changes take into account these files, create them in the ml hierarchy and link them with their relatives.
-
The createFile method in the FsFactory was using the mrl incorrectly by creating a temporary directory with the full mrl of the file instead of truncating the file name.
-
- May 01, 2021
-
-
Hugo Beauzée-Luyssen authored
-
Hugo Beauzée-Luyssen authored
-
Hugo Beauzée-Luyssen authored
-
The medialib does not properly support multiple simultaneous clients, so running two VLC with medialib enabled would cause issues. If the medialibrary is already in use, by enabling the "lockFile" flag, NewMediaLibrary() will return nullptr. In that case, VLC will behave as if --no-media-library was passed. Signed-off-by:
Hugo Beauzée-Luyssen <hugo@beauzee.fr>
-
Hugo Beauzée-Luyssen authored
Co-authored-by:
Romain Vimont <rom1v@videolabs.io>
-