- Apr 12, 2025
-
-
Signed-off by: Ash <ashutoshv191@gmail.com>
-
-
- Apr 11, 2025
-
-
In the default config, audio packets are 40ms long and video is 25/1 frame per seconds, so frames are displayed every 40ms. When changing framerate to 50/1, everything still works correctly and the DemuxVideo call will generate two frames for one audio packet, and the sys->clock accumulator will move forward 40ms too. However, when using any frame rate value that would make 40ms not divisible by the video frame duration, eg. 60/1fps which is a period of 16.666ms, then the video would drift apart from the other tracks. Symmetrically, when using any frame rate value < 25/1 that would not be divisible by 40ms, the audio would drift apart from the other tracks. It came from the fact that video and audio were allowed to move forward the same amount starting from their previous pts value, which is not the same starting point for each track in case the divisibility condition is not met. The following graph represents the situation by drawing the two tracks with different origins to show how the video makes more progress than the audio in the case audio has 40ms packet and video is 60/1fps. PTS video ^ audio * --+ | * / | We go further than the | / * | audio track here. But | / / | we'll continue sending | / * --+ packets by group of 3. | / / | * * | / / | / * | / / | / * | * / | / * --+ | / / | This shows we can generate three | / * | video packet for each audio | / / | packet in the current state. | * * --+ | / / +---------------------------------------->ts By keeping the track-specific start point, we don't miss any value, and by setting the maximum date from sys->clock instead of the track-specific start point, we ensure we don't send more packets than wanted. Fix #29122 -
-
François Cartegnie authored
-
- Apr 08, 2025
-
-
Steve Lhomme authored
-
Steve Lhomme authored
MINGW is properly handled now, but not the 32-bit version. According to [^1] 32-bit may not work at all. [^1]: https://github.com/msys2/MINGW-packages/issues/17029
-
Steve Lhomme authored
It can supports 16KB aligned page sizes with a flag in the NDK build package. [^1] It is not on by default so we can test things without being stuck with this image. The relevant change will need to be done on the libvlcjni side, including switching to this image as well. This is done in [^2]. [^1]: https://developer.android.com/guide/practices/page-sizes#compile-r27 [^2]: libvlcjni!112
-
Steve Lhomme authored
We assume the Vulkan headers are not found so they are found in contribs. This reverts b0d6f9ad
-
Steve Lhomme authored
With NDK27 vk.xml is not found anymore. We can install our own headers instead. NDK27c comes with Vulkan 1.3.275 headers.
-
Steve Lhomme authored
To match the Android NDK27.
-
Steve Lhomme authored
The build folder is no longer build but vlc_build. The proper pkg_static call is done during unpaking.
-
Signed-off-by:Claudio Cambra <developer@claudiocambra.com>
-
- Apr 07, 2025
-
-
It does not make any sense to use stack view here.
-
It does not make any sense to use stack view here.
-
It does not make any sense to use stack view here.
-
By default we expect the viewport to cover the content width or height depending on the orientation, so in normal cases we only need one scroll bar. This behavior can obviously be overridden where the list view is reused. This fixes multiple things: - Not being able to interact with the bottom part of the list view even if the orientation is vertical and the viewport covers the whole content width, because the scroll bar may still be technically visible and consume events even though it does not display anything visually. - Flashing scroll bar upon creation of the view until the content and viewport sizes are determined (regarding the orientation where scroll bar is not wanted).
-
Now that we have our own customized scroll bar, we can define its implicit size in `VLCStyle.qml` directly.
-
Currently we don't account for `QT_HAS_LIBATOMIC` being `0`.
-
-
-
-
Having radio buttons requires one click less to adjust the speed from the presets.
-
Based on Qt Quick Basic Style, the difference being mainly custom colorization and sizing.
-
Currently, the Continue Watching row is visible only when medialibrary has some videos. Signed-off by: Ash <ashutoshv191@gmail.com>
-
Hide the header when EmptyLabel is present to be displayed when model is empty. Signed-off by: Ash <ashutoshv191@gmail.com>
-
If there is a specific header, obey to its visibility otherwise hide the column sort row if model is empty. Signed-off by: Fatih Uzunoglu <fuzun54@outlook.com>
-
This is because EmptyLabel now has implicitWidth, implicitHeight. Signed-off by: Ash <ashutoshv191@gmail.com>
-
Stop unloading the grid / list view in MainViewLoader when model is loading or when model is empty. Signed-off by: Ash <ashutoshv191@gmail.com>
-
Signed-off by: Fatih Uzunoglu <fuzun54@outlook.com>
-
Use the default loading indicator in BrowseTreeDisplay Signed-off by: Fatih Uzunoglu <fuzun54@outlook.com>
-
Signed-off by: Fatih Uzunoglu <fuzun54@outlook.com>
-
-
-
Signed-off by: Ash <ashutoshv191@gmail.com>
-
qt: do not call `updateSizes()` and update root item size explicitly in `CompositorX11UISurface::setContent()` When the content is set, there is no reason to call `updateSizes()`, because it updates the sizes of multiple things, where in this case we only want to set the initial size of the root item.
-
During initialization, `QVLCTools::restoreWindowPosition()` is called before the window is shown (intentionally, as we don't want to resize after showing the window). This is done before the content is set, which makes root item point to a valid location. Unlike what its name suggests, `QVLCTools::restoreWindowPosition()` may adjust the size of the window which in turn may cause a resize event be generated, and this event may be sent immediately (synchronous) and not deferred until going back to the event loop. In this case `updateSizes()` may be called, which is normally expected to be called when everything is ready (i.e., root item, and its window are valid pointers). We can simply check if the root item pointer is null in `updateSizes()`, and not dereference it if it is a null pointer. This should be safe because when the root item is set, its size is set anyway. We don't need to check for `m_uiWindow`, because it is set during construction.
-
The event filter dereferences `m_uiWindow` (among other things) without checking if it is a null pointer, so it should not be installed before `m_uiWindow` is a valid pointer.
-
By default `WheelHandler` only accepts mouse (unlike other handlers where all devices are accepted by default), and it also does not make use of synthesized mouse events. We can accept all devices here, I don't see why we should limit the accepted devices here. Currently on Wayland certain mouse types are not reported as "mouse", this is a problem for the wheel functionality of the playback speed control. Accepting all devices fixes this issue.
-
This makes it possible to not consume the events when there is nothing shown. We can do this because in this scroll bar style when `size` is smaller than 1.0, the handle is always visible. So this change is mostly relevant when `size` is 1.0, which means viewport size covers the content size. This is useful for situations such as, playlist height is equal or greater than the combined height of the items added to it. With this patch, clicking on the items where the scroll bar would be shown makes it possible for items to react to the events (such as, selecting or showing the context menu). I did not use `background.visible` or `contentItem.visible` because they already depend on the control's visibility (as if parent is invisible the children would be invisible).
-
