There should be no difference because the video track hasn’t been touched. Some software will display the length of the longest track rather than the length of the main video track. It’s likely that the the audio track was originally longer than the video track and because of the offset it’s now shorter.

You can use tools like ffmpeg and mediainfo to count the actual frames in each to verify.

Koboldcpp should allow you to run much larger models with a little bit of ram offloading. There’s a fork that supports rocm for AMD cards: https://github.com/YellowRoseCx/koboldcpp-rocm

Make sure to use quantized models for the best performace, q4k_M being the standard.

I only have 60 down and 12 up so I cap about 80% of the time with a short uncapped window late at night.

Tun0 is the interface that most vpns are using so I assume proton is the same.

French laws don’t recognize software patents so videolan doesn’t either. This is likely a reference to vlc supporting h265 playback without verifying a license. These days most opensource software pretends that the h265 patents and licensing fees don’t exist for convenience. I believe libavcodec is distributed with support enabled by default.

Nearly every device with hardware accelerated h265 support has already had the license paid for, so there’s not much point in enforcing it. Only large companies like Microsoft and Red Hat bother.

Get yt-dlp then run: yt-dlp -x ‘video-url’

I believe if you’re willing to check the format codes on the video you can download audio only but both will get you the least compressed audio available.

I’ve used the tplink ones that they’re using and they’ve been pretty solid. I can’t say how they’d fare in a 24/7 setup though since they’re not really intended for that.

I’m surprised there isn’t something already with how google has been marketing gaming on Chromebooks via streaming services.