Precise Timing offset and - /+ buttons
Is your feature request related to a problem? Please describe.
- Timing (audio, subtitle) offset need more precision
- Tweaking timing offset with mouse is not convenient if you need precision. It's even harder on touchscreen
Describe the solution you'd like
- 50 ms precision
- Add a
-and+button for a better UX
Additional context
Features available in VLC UWP
Thanks for considering this,
Tip: You can use the arrow keys on your keyboard for more precision (50 ms).
As for the UX choices, it's open for discussion, but we should pick one or the other. Currently, it's a complex trade-off between mouse, keyboard, and controller, requiring us to find the best compromise.
Tip: You can use the arrow keys on your keyboard for more precision (50 ms).
Didn't know about the arrow keys precision.
As for the UX choices, it's open for discussion, but we should pick one or the other. Currently, it's a complex trade-off between mouse, keyboard, and controller, requiring us to find the best compromise.
How about touchscreen experience then ? The -and + buttons request were mainly intended for touchscreen experience.
Screenbox should have improvements in this area as well(already reported gestures and other issues btw).
I often suggest it to Surface Pro users when it comes to a media player. I personally use my device without keyboard attached when playing video.
How about touchscreen experience then ? The -and + buttons request were mainly intended for touchscreen experience.
I agree that it's not ideal for touchscreen, like I said it's a delicate balance.
Take the VLC UWP image you shared, wouldn't you agree that the touch targets are too small and could potentially conflict with each other? Those specific flyouts are not the final design, I experimented with some changes in #203.
Screenbox should have improvements in this area as well(already reported gestures and other issues btw).
For sure, there are several areas where touch support falls short.
Take the VLC UWP image you shared, wouldn't you agree that the touch targets are too small and could potentially conflict with each other? Those specific flyouts are not the final design, I experimented with some changes in #203.
Touch targets in VLC UWP are great. As you can see in below GIF, there is enough padding/marging.
GIF - Action performed with touch
The following layout that you shared in #203 can potentially be the solution after some changes regarding arrows size.
Arrows aren't touch friendly
I agree that there isn't really a need of a slider for audio and subtitle offset.
Touch targets in VLC UWP are great. As you can see in below GIF, there is enough padding/marging.
I disagree, it's too easy to accidentally adjust the slider while interacting with the buttons.
https://github.com/user-attachments/assets/cba03599-dd9b-42c4-9ca4-c62df6d2772c
[...]after some changes regarding arrows size
The non-compact option offers a better illustration of what it would look like
I agree that there isn't really a need of a slider for audio and subtitle offset.
For touch, yes, but I believe it's a better control for pointer and gamepad.
For the time being, we could decrease the StepFrequency to 50 ms and the SmallChange to 5 ms, although it would somewhat negatively impact the gamepad experience.
Will be great to have all offset controls in a single floating window instead of the current implementation! @United600 would keep the aspect ratio out of the window.
As we talked about in the other thread with United600, the best option is these WinUI control, Its perfect for mouse, touch and manual entry values. The slider is only suitable for the speed of the video.
Will be great to have all offset controls in a single floating window instead of the current implementation!
For the present maybe, but it will be severely constrained in the future with the addition of more options. That was why I dropped it.
As we talked about in the other thread with United600, the best option is these WinUI control, Its perfect for mouse, touch and manual entry values. The slider is only suitable for the speed of the video.
I disagree. What degree of precision is really needed? Maybe we can tweak the SmallChange values, but with the wide range of inputs in mind, a Slider appears to be the better-fitting default control.
For the present maybe, but it will be severely constrained in the future with the addition of more options. That was why I dropped it.
Oh I didn't know that! in that case yes, it should be a single window for all the options.
I disagree. What degree of precision is really needed?
Not much, the 100/50ms steps you mentioned are perfect, but I think the buttons work better in any scenario (touch, mouse and gamepad). For example, the current slider goes up to 3000ms, but what if you need to add 10000ms? with such a wide range in a slider you lose precision, with buttons you don't have that problem.
Being able to manually add the value is also just as important.
Not much, the 100/50ms steps you mentioned are perfect, but I think the buttons work better in any scenario (touch, mouse and gamepad).
Have you ever used the NumberBox with a gamepad, let me tell you it's definitely not fun. Do you know if there are any use of it anywhere else in the system? From what I can see, I can't find any, Around 95% of it is either a Slider or ComboBox.
For example, the current slider goes up to 3000ms, but what if you need to add 10000ms? with such a wide range in a slider you lose precision, with buttons you don't have that problem.
In my opinion, 3000 ms is too high. I would even argue that such a substantial synchronization issue should be addressed using more specialized tools.
You're probably right, I only have gamepad experience with GameBar.
Do you know if there are any use of it anywhere else in the system? From what I can see, I can't find any, Around 95% of it is either a Slider or ComboBox.
I don't remember, just the WinUI Gallery examples.
In my opinion, 3000 ms is too high. I would even argue that such a substantial synchronization issue should be addressed using more specialized tools.
There are few cases where you need +3000ms, but perhaps it is good to keep it in mind and prevent the user from having to go to another app. I don't know, just a suggestion.
- 50 ms precision
As of the most recent update (0.14.2), the default precision for timing offsets is now set to 50 ms.