- 28 May, 2022 8 commits
-
-
Jean-Baptiste Kempf authoredSee #26921
-
Jean-Baptiste Kempf authored
The next release, 4.0, is a massive API change
-
Jean-Baptiste Kempf authored
Fuzzing fixes...
-
Jean-Baptiste Kempf authored
-
Jean-Baptiste Kempf authored
-
Fixes notably: CVE-2018-9251 CVE-2018-14567 CVE-2018-14404 CVE-2021-3541 CVE-2022-23308 CVE-2022-29824 And move to the official Gnome Infrastructure
-
Jean-Baptiste Kempf authored
-
fixes #26990
-
- 27 May, 2022 18 commits
-
-
This fixes the CSS parser when the numeric locale has a comma instead of a dot as decimal separator (notably the French locales).
-
-
This matches the naming convention of vlc_strerror_c(), and avoids clobbering the global namespace.
-
-
-
-
-
-
When accessing an FTP without specifying a path, the generated MRLs would lack the trailing / after the hostname, leading to a ton of errors because of bogus hostnames in the MRLs.
-
-
-
Fix #26046
-
Rémi Denis-Courmont authored
This actually calls the zoom change control only when the effective value of the zoom changes. Previous the control would be invoked even with autoscale enabled, even though that effectively overrode the zoom.
-
We don't need to print six digits (zeroes) after the decimal separator.
-
Core/LibVLC code should only inherit values from core variables. Defaults cannot be inherited from variables that may not exist as configuration items. Fixes #26881.
-
-
Jean-Baptiste Kempf authored
Close #26774
-
The sample code demonstrate how to bind an NSView to a media player to integrate video playback in a Cocoa application.
-
- 26 May, 2022 4 commits
-
-
-
We do not handle the reset_pictures callback so we can't return an error here. We never returned one anyway.
-
Asynchronous window resizes cannot be kept in sync with EGL. To keep the underlying X11 window and the EGL drawable sizes in sync, embed a new X11 window so that EGL can synchronously resize. At a high level, to resize, we (1) wait until EGL is done drawing, (2) resize the X11 window, and (3) wait for the window to be resized before EGL resumes drawing. With Nvidia, eglWaitNative() is sufficient to wait for the window to be resized. With Mesa, it is not, so after eglWaitNative() we (for the Xlib backend) check if Xlib knows if the X server has already processed the resize and, if not, XSync(), or (for the XCB backend) wait on the void cookie corresponding to our resize request. To work around an issue with Mesa, we also call eglQuerySurface(EGL_HEIGHT) to coerce Mesa to observe the new X11 window size and resize its EGL surface. On Nvidia, this is not required, but we call it in any case. Refs #26734 for EGL.
-
Asynchronous window resizes cannot be kept in sync with GLX. To keep the underlying X11 window and the GLX drawable sizes in sync, embed a new X11 window so that GLX can synchronously resize. At a high level, to resize, we (1) wait until GLX is done drawing, (2) resize the X11 window, and (3) wait for the window to be resized before GLX resumes drawing. With Nvidia, glXWaitX() is sufficient to wait for the window to be resized. With Mesa, it is not, so after glXWaitX() we check if Xlib knows if the X server has already processed the resize and, if not, XSync(). Refs #26734 for GLX.
-
- 25 May, 2022 8 commits
-
-
The kVTVideoDecoderReferenceMissingErr error is not a critical one, but without it being handled here, it would lead to aborting with VideoToolbox and falling back to Software. Reproduced this with a sample provided by zhilizhao(赵志立), related to !1790. I assume that before this error code was introduced in macOS 12/iOS 15, VT did just return the NULL image buffer with a success status code, leading to the issue seen in !1790.
-
Chrono are estimating the duration of the rendering when displaying frames, but they were only initialized at the vout thread creation, and not whenever the decoder outputs a different format (eg. because it's a different decoder). It means that when rendering a 8k 24fps frame, and then 360p 60fps picture, we'd expect that the first frames from the 360p stream renders with the same timing as the 8k 24fps, which could lead to useless drops. vout_Request was usually followed with a forced picture, which helped mitigate the issue, but the chrono are averaging with previous values, leading to local increase of expected rendering time at the beginning. Likewise, when flushing, timing constraints could have change, though admittedly there is less obvious reason for the constraints to change in this case. It still solves issues in the following cases: - The framerate matches the refresh rate and the offset-to-VSYNC has changed. It would reduce or increase the rendering time virtually without controls from VLC. - The rendering has been paused by a debugger at the middle of the measurement. It would artifically set chrono to a very high value, like 30 seconds, which means that a frame must arrive 30 seconds in advance from the decoder to the video output to be displayed. Rationnally, the chrono system is a heuristic to fast-forward the video pipeline when the stream cannot be rendered in normal condition and resetting the timestamps would not break already working streams, whereas it would only display at most one more late picture in the broken stream, which was already the case at the beginning of the stream because of forced pictures.
-
Filters like deinterlacers are using timestamps interpolation to generate intermediate frames, which might not work reliably when the timestamps are not from consecutive frames. When dropping a decoded picture, we were not notifying those filters and the next frame was arbitrarily further than the one the filter might expect. Ideally, we would notify which frames has been dropped to the filter, so that it can differentiate a real discontinuity from a drop and can handle its history correctly, but flushing is still better than doing nothing and history is not really well exposed for now anyway.
-
fix regression from 9b7514f9
-
VLC 4.0 targets macOS 10.11, so we can always assume this is available.
-
-
The size saved here is always overwritten right before rendering so it is not necessary at all, as nothing is reported anymore here, this is handled by the window.
-
When transitioning to fullscreen, the codepath for non-live resize was used and did not trigger rendering here. As the size if now handled by the window however, this resulted in a wrong size as it was never actually updated. To prevent that, always render with the proper size from the layer regardless if we are in live-resize or not. Fixes #26962
-
- 24 May, 2022 2 commits
-
-
It returns true when it overflows.
-
The warning was always triggered because __builtin_constant_p actually checks whether the tested value is constant at compile time and strlen() was never constant at compile time. Note that __builtin_constant_p can be used with a non-constant test expression while using the same expression after ? in a ternary condition.
-
