- Mar 09, 2024
-
-
Automatically enable the headers, but detect the currently available header version with cppcheck since the pkgconfig file will actually detect the version of the loader. cppcheck cannot understand the full header version, which was also not available before 1.3 anyway. Moreover, the major and minor versions are not defined directly, but instead either through cast or not at all (before 1.3), so we use the header guards defines and the VK_HEADER_VERSION for the last patch revision number, which directly matches the actual package revision. v1.3.239 is the version provided by the vulkan-loader package on debian bookworm, and the main constraint we have is the presence of the vulkan/vulkan_beta.h header which should be present and the presence or absence of the old/new video_decode extension that was promoted. 238 is the first revision removing the previous video_decode extension and adding the new one. Tested on linux with headers present and android with system header being obsolete.
-
libplacebo depends directly on vulkan-headers, not transitionally. The constraint was written like this to not always install the headers if some were provided by the system.
-
Steve Lhomme authored
-
- Mar 08, 2024
-
-
Steve Lhomme authored
This is the latest in the 6.x branch. We already build with 6.1 in the Debian unstable Docker.
-
Steve Lhomme authored
This is the latest in the 5.x branch.
-
spirv-opt provided by spirv-tools is used by Qt Shader Builder (qsb) for shader optimization.
-
- Mar 07, 2024
-
-
Since the video output cannot be the master clock, there's no reason to artificially change the date matching with the displayed frame. Indeed, the video output was using two points that felt weird: - When the picture was late, it was "forcing" the timestamp by using VLC_TICK_MAX as system time. - When the picture was rendered before the deadline, it was using system_pts, ie. the date at which the clock computed when it should be rendered, as the system time for the clock. In both cases, it was basically only disabling drift computation in traces, since the drift is not used in the video output so changing its value doesn't change the behaviour and the clock points will never be used in a master clock. Drift would always be zero on the traces. This commit re-establish the drift computation, using the time at which the frame is finished being displayed as system time. It won't match the "exact" time since it doesn't account display latency nor supports using dates from VSYNC (ref #26184) but the error will almost always be a constant part (for the latency not being used) plus a bounded part (for the VSYNC sampling delay), meaning that every non-stable behaviour like drifting can be measured. Reference also commit 207fcd92 which tried to apply that to the clock wait. Reference commit abb6e135 which asserted that drift should be 0 given that the whole sampling process is controlled by the clock, which is only true if the vout_display doesn't stall the video_output. Reference commit 013aa3aa which started to use VLC_TICK_MAX (INT64_MAX back then) so that the clock update would notify the player. Important: The intent of the commit above is disabled by this commit. Note that this commit virtually introduce a huge initial drift. This drift is actually expected given that we draw the first frame regardless of the actual date, and playback constraints might have the video track earlier at the beginning than audio track. This also introduce increasing drift when a frame is re-drawn, which is also by design since we didn't update the frame. A motion-interpolating filter would generate intermediate frames and avoid this, which makes it more representative of the true video output drift.
-
-
Otherwise we carry over some scaling rounding in the original region, even if nothing was changed.
-
This reverts commit 372e62c0. This commit broke SPU positioning for this DVD: https://streams.videolan.org/samples/MPEG-VOB/menus%20DVD/Avcd%2023032b
-
François Cartegnie authored
Prefixes and namespaces are required to be able to correctly parse multiple namespaces documents or simply prefixed documents
-
François Cartegnie authored
-
François Cartegnie authored
-
François Cartegnie authored
UDP is unreliable
-
Forward the tracing key/value entries as an array instead of using va_list. Using an array is easier to interop with in other languages, but also and more importantly much easier to store and forward. This will allow to implement hierarchical tracing context.
-
The module was added in 4d691734.
-
The file was added in 7c9f7725 to provide common code between h264 and h265 handling.
-
Tristan Matthews authored
See: https://opus-codec.org/demo/opus-1.5/
-
- Mar 05, 2024
-
-
-
-
-
-
-
-
François Cartegnie authored
Was not inserted if there's no pre-frame NAL units
-
macosx: Set VLCLibraryWindow XIB constraint for path control view to top of superview as a placeholder Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
Signed-off-by:
Claudio Cambra <developer@claudiocambra.com>
-
The linkers platform_version argument does not support the value "macosx" but expects "macos" here instead.
-
Added isADir() method in NetWorkmediaModel's anonymous namespace to list folders-before-files through the NetWorkmediaModel's getSortFunction(). fix: #28371
-
-
Steve Lhomme authored
-
Steve Lhomme authored
-
- Mar 03, 2024
-
-
Video using the ffmpeg qtrle decoder are failing to play with: [qtrle @ 0x76117804fc00] Unsupported colorspace: 0 bits/sample? [0000761178024760] avcodec decoder error: cannot start codec (qtrle) [0000761178024760] main decoder error: Codec `rle ' (Apple QuickTime RLE Video) is not supported. [0000761178024760] main decoder error: Codec not supported [0000761178024760] main decoder error: VLC could not decode the format "rle " (Apple QuickTime RLE Video) Indeed, QTRLE format can compress source with either 1, 2, 4, 8, 16, 24 or 32 bpp, and the actual bpp is stored in the stst atom, not in the decoder payload. The demux has to forward this value to the decoder one way or another. Regression from 12030f5ccac852aaa3f9f66b20606d2fc344f8f4, which starts setting the bpp to zero in avcodec because there is no chroma yet. Defining a chroma instead of forwarding the bpp would be possible for 8, 16, 24 RLE data cases, but would not work for lower RLE data cases. The correct i_bits_per_pixel field being removed in commit 1d46d8b7, a hack is implemented instead. The hack is from 3e5f2e5d and other places that needed it. Fixes #28550
-
- Mar 02, 2024
-
-