My favorite feature is "video-sync=display-resample". This gives you perfect frame pacing by synchronizing the video to vertical refresh and resampling the audio to match. If you set your refresh rate to an integer multiple of the frame rate, every frame will be shown for the exact same time. The audio resampling compensates for very small discrepancies between speeds by imperceptibly changing the audio speed. It's similar to the proprietary DirectShow filter "ReClock", but AFAIK ReClock does not dynamically adjust the speed to compensate for clock drift like MPV does, in which case you could theoretically still get imperfect frame pacing. (I haven't actually used ReClock so I could be mistaken here.)
Also great is MPV's support for arbitrary OpenGL shaders. This can include very complicated shaders, e.g. real-time neural network upscaling:
One of my least favorite features of VLC (tied with network stream interruptions killing the playback rather than reconnecting) is that VLC guesses your audio hardware's sampling rate itself (rather than using the hardware's self-reported rate), and resamples even audio-only files that match your hardware's self-reported rate. And every time you seek in a file, VLC's guess of the hardware sampling rate is thrown off, causing VLC to start pitch-shifting the sound just enough (usually just barely, but sometimes up to 1 semitone) for you to notice and start doubting your sanity, if the audio pitch actually changed or if you're hallucinating things. There's a long-running bug report at https://code.videolan.org/videolan/vlc/-/issues/14287.
I think PipeWire does something similar to synchronize multiple audio devices without a shared word clock, but I haven't tested how much its rate analyzer drifts when starting/stopping playback or in steady state.
> tied with network stream interruptions killing the playback rather than reconnecting
So I'm not alone in hating this! How come this was never fixed?
I didn't want to switch from MX Player (Android), which worked quite well, for ages, but finally gave up because with MX Player you have to go look for some codecs.zip every (major?) update. (must be related to the licenses)
On top of VLC not being able to reconnect to the source, it also doesn't show the title of the video. So every time the stream dies I have to remember which episode I was on.
Exactly the same thing happens with mpv if you shift the audio manually. I experienced that recently. After shifting, whenever I go forward or backward it gets out of sync + the performance decreases ( without the shift going forward or backwards is instant)
I have experienced this with IPTV on Kodi, but I've only ever noticed it on the BBC News countdown tune, sining a semitone up and down. AFAIK that's using ffmpeg
> Also great is MPV's support for arbitrary OpenGL shaders. This can include very complicated shaders, e.g. real-time neural network upscaling:
Holy shit, I had no idea about this (that mpv could load OpenGL shaders nor that there is shaders that do RT neural upscaling), literally blowing my mind.
When I first experienced it, it made me realize how terrible VLC is; VLC can't play back video at a consistent framerate, and this is particularly noticeable in panning scenes in videos, especially anime.
People talk about VLC like it's a poster-child of open source, but really, I just see a bloated, crash-prone program that doesn't even do its primary function particularly well or efficiently.
VideoLAN is responsible for a whole lot of open source code that benefits the entire video ecosystem, like x264/x265/dav1d. Even if you dislike VLC, I think this is underselling their contributions to the world.
Also, I find VLC is a safe recommendation for someone who just wants to casually play some video files. It's fairly user friendly, it runs on literally everything, and it supports most multimedia formats anyone could ever care about. I like and use MPV, but I use VLC on some Android TV devices because it's readily available and runs buttery smooth on crappy hardware.
This is probably a interference of a chosen output method and a system compositor behavior (or its recent changes). Compositor redirection broke synchronization for most old code, and available interoperation and bypass methods have been changing with time. This was the reason media players and games introduced new fullscreen modes. Players, including VLC, have been capable of stutter-less video output for decades, the problem is that there is usually more to show on screen than just the video, and the user wants other things to happen in parallel.
It's true that VLC requires arcane knowledge of its architecture to configure all of its options, but basic operation still assumes you've read the fine manual.
Computer monitors are not all 60hz, and I cited anime as one example; TV and movies also have jerky playback.
VLC does the behavior described (jerky playback) on both a Mac with 60hz display that is several years old, and on a cutting edge PC that has a refresh rate more than five times the framerate of anime and supports variable refresh rate.
mpv plays anime butter-smooth on both systems.
I love it when I get a supremely condescending explanation that is also wrong.
> Computer monitors are not all 60hz, and I cited anime as one example; TV and movies also have jerky playback.
The ones that are 60hz are 60hz, and that's not the reason monitors aren't TVs. They aren't TVs because they don't have one of 1. black frame insertion 2. 60->120fps motion interpolation, so you have persistence of vision issues. (aka motion blur, jerkiness, or both at once)
Movies are also 24fps, though of course they're different from animation because they have built in motion blur (same as if you recorded with 1/24 exposure time vs 1/1000).
mpv's video retiming works some of the time, but means it changes the pitch of audio which is sometimes unacceptable, same as old NTSC->PAL transfers.
…if your monitor has variable refresh rate why are you using retiming?
>They aren't TVs because they don't have one of 1. black frame insertion 2. 60->120fps motion interpolation
Most older LCD TVs do not have either black frame insertion or motion interpolation. BFI causes motion artifacts (trailing ghost images) if the frame rate of the video is less than the refresh rate. Motion interpolation also adds its own artifacts.
>mpv's video retiming works some of the time, but means it changes the pitch of audio
The best way to use it is to set custom monitor timings (e.g. with xrandr) so that the adjustment needed is too small to detect. There are various scripts to automate this, although I haven't personally tried any (I just change mode manually).
>if your monitor has variable refresh rate why are you using retiming?
I have a VRR monitor, but I still use retiming because it only has a 6 bit panel, and VRR makes temporal dithering artifacts ("frame rate control") visible.
Yeah, those LCD panels aren't actually good enough to be TVs. A lot of them were 60hz as well, or at best 120hz with HDMI 2.0 which didn't support VRR so your playback device probably wouldn't send them 24fps.
Amazing! I tried it with a 360p video and scaling the player window to 1080p and it's looking sharp. The original looks blurry when you scale the window to 1080p.
You can force it to do that if you really want to, but by default it will speed it up to 24.00fps and play it alternating between 2 and 3 screen refreshes for each frame (i.e. 3:2 pulldown without the interlacing).
Is there any way to make it work with adaptive refresh to play the video at exactly its native speed and adjust the display refresh rate instead? Or should that just work automatically?
VRR support for MPV is disabled by default in /usr/share/drirc.d/00-mesa-defaults.conf. I am not sure why, because it works for me if enabled. Just fullscreen MPV and it will change the display refresh rate. This requires VRR enabled in both Xorg and your monitor's settings. I have not tried this with Wayland.
No, I forget what the exact limit is, but it does change the speed more than ~0.5%. So going from 59.97 to 60 or vice versa, but not 24 to 30 or 50 to 60.
But Yeah, I am in LOVE with this feature, even for 30fps footage on a 60fps screen. The more stable frame times make a huge difference.
Shouldn't display adaptive sync work better for syncing to video framerate though? Trying to resample the video to display refresh rate instead sounds like a worse approach.
If VRR works well with your hardware then it is probably a better option. You can edit /usr/share/drirc.d/00-mesa-defaults.conf to enable VRR with MPV.
I have a freesync 165hz display. What is the best mpv setting? In theory it should be possible to perfectly show video on my monitor without any stretching or pacing problems.
Unfortunately this is not quite the same thing, It just plays around with how the existing frames are displayed instead of generating new ones based on the motion vectors in video files.
How much does it have to adjust playback speed to get frames to an even multiple of refresh rate? Like 2%, or 20? This feature isn't for me -- I'm a big fan of the +/- 10% playback speed '['/']' buttons -- but it sounds neat.
Also great is MPV's support for arbitrary OpenGL shaders. This can include very complicated shaders, e.g. real-time neural network upscaling:
https://github.com/igv/FSRCNN-TensorFlow/releases
SD video can look surprisingly good after upscaling with this.