The VideoLAN Forums

The VLC unit needs to depend on the sound server service. Alternatively, use ALSA directly (but then no other app will be able to use audio).

This is more of a PA or PW problem; this would affect essentially any app, so this forum might not be the best place to get good answers, TBH.

I'm pretty sure I recall seeing plugins for Windows too, not that I tried any of them.

Uh, native YT-DLP was merged in VLC 4.0 already 4.5 years ago, and there are several unofficial plug-ins available to integrate it in VLC 3.0.

That sounds like a bug in the Scarlet device drivers.

To create a playlist, you need an SD plugin but before that, you need an input plugin to set the tuner up. That won't work with scripts.

Patches welcome.

Maybe but there's still too little space left and this seems very niche.

Historically the digit keys are assigned to bookmarks. That feature is not used by anyone, I think, so it should be possible to switch to YT style with little difficulty; patches welcome.

Adding an action is feasible; patches welcome.

Adding a default hotkey is not going to happen. Too few keys left.

Assuming you're using PulseAudio (or PipeWire through PA), there's no simple answer. VLC just displays the PA stream volume, and it doesn't really know what PA does with it. 100% is a good bet, but...

You can request an HDR pixel format, but even then you can't retrieve colorimetry with that API, so... I don't think that there's really a way. Patches are welcome.

RTSP proper is always over TCP. Only the data transport can change.

Hardware decoding acceleration is not typically (if ever) implemented in the GPU proper, and nobody said that it was "GPU acceleration", well except you. So it's not really surprising that it has very little impact on the GPU usage.

What happens here is the libavcodec H.264 decoder failing. Impossible to say why for anyone but you, realistically.

You change the stereo mode in preferences but it makes no sense to use reverse stereo permanently.

VLC has always used extensions as a first guess to speed up opening a file.

You need to transcode if you want a more reasonable bit rate

You seem to be mixing up native and Windows build procedures.

MacOS guides are only relevant to MacOS

DO NOT force ALSA. It won't work well if you use PulseAudio or PipeWire and it won't do anything if you do use plain ALSA.

With that said, stutter on resume is a classic problem with some hardware. Only solution until VLC 4 is to wait it out.

There's no autodetection of anything. RTP just uses a better default because it was defined later with the benefit of hindsight.

There are three compounding reasons why VLC may be slow to start:

• the plug-in cache is missing or corrupt,
• an antivirus is taking its sweet time scanning VLC files,
• the disk cache is cold (especially on Windows, which is the most ineffective OS in this respect).

If it shows Simplified Chinese correctly, I imagine that it does in fact not show Traditional Chinese and Japanese correctly - because of how Unicode was designed.

But anyway VLC can't pick a default that's not universalmy available - it has to do autodetection. You're free to change the settings.

The @ is not and never was mandatory as such. You can argue that the choice of default is unfortunate, but that's easy to say with 20+ years hindsight. Raw UDP was deprecated over 15 years ago and it's only left there for backward compatibility. We can't change the syntax, lest we break that compati...

Make a playlist with the files in the intended order and do NOT enable shuffle.

@ is part of the URL standard, and you're free not to use it if your use case doesn't need it. There's no standard for udp:// or at least there wasn't one when VLC introduced that, so your comment doesn't make much sense.