MPV Player 0.35.1 Released With Wayland & PipeWire Fixes

[Brisse]

so if you have GFX9 or newer it should work]

I'm on gfx8

Curious to see if it will work with Vulkan video though when proper support has landed in both mpv and mesa.

[Brisse]

gpu-api=vulkan should not enforce vaapi-copy, as for video-sync=display-resample is a little tricky because the way mpv uses to monitor stats (the previously stats.lua script) is really hungry so if you watch the stats you get lower performance than you normally would. If even when not watching the stats you feel the video stuttering maybe try the wayland-disable-vsyc=yes option, I remember it used to make things better.

Thanks, will try. The feature relies on a bit of a hacky way to figure out the real display refresh rate and when I was watching the stats, the predicted refresh rate never stabilized properly, but was fluctuating a bit all the time. Not that I really need this feature. Playback is quite smooth without it.

[Quackdoc]

I'm on gfx8

Curious to see if it will work with Vulkan video though when proper support has landed in both mpv and mesa.

im curious on exactly the same thing xD. I myself have an rx 580 so I share the pain. I use vulkan myself however since the copy is negligible, I can use fsrcnnx 8 when using vulkan we 60fps footage with multiple other shaders, where as opengl barely can do 30fps, so IMO its very worth using vulkan anyways if possible.

[pWe00Iri3e7Z9lHOX2Qx]

I've actually been debating migrating to fedora rawhide or nobara and using arch inside of distrobox. the only thing that's stopping me is I do a good number of custom packages for dkms, kernel, qemu etc, all larger things I would rather keep easy to mod, and keep on the host OS. but I am really close at this point, I also thought about trying out pop OS since I actually have been testing cosmic for a while and its quite promising (pkgbuilds here if interested) albiet still quite buggy, I do love the hybrid stacking/tiling compositor design

Maybe Tumbleweed with your own repo in OBS (OpenSUSE Build Service) for your custom builds?

[pWe00Iri3e7Z9lHOX2Qx]

Because Arch isn’t rolling release. Use a real rolling release distro like openSUSE rawhide or Fedora tumbleweed

Besides flipping the ownership of those two distros, Rawhide and Tumbleweed aren't comparable at all in terms of stability / suitability as a daily driver for the overwhelming majority of people.

[openminded]

Besides flipping the ownership of those two distros, Rawhide and Tumbleweed aren't comparable at all in terms of stability / suitability as a daily driver for the overwhelming majority of people.

Esp Rawhide. Last time I checked, their kernel update policy was quite venturesome, to say the least. Using RC kernels isn't what laypeople would want.

[evasb]

I'm eyeing OpenSUSE Tumbleweed too.

The problem is the many Arch users like me won't do the jump because they maintain packages on AUR and learning OBS, remaking all the scripts is tedious.

I would love to see some tool to "convert" PKGBUILDs to .spec files.

[Berniyh]

Because Arch isn’t rolling release.

Uhm, what???

[Berniyh]

Because Arch maintainers do not bother. It has been a problem with Arch for years. Too many developers simply do not care for the project and are only involved for their self-serving reasons, while they refuse to let in new people to replace them. Many packages take too long to get an update. The only thing you can count on Arch to have in its repos immediately is KDE, everything else may take even many months before it gets updated.

Take for example Netbeans, an IDE i like personally. It is still version 14 in the repos, version 16 upstream. Hasn't been updated for half a year. They just don't see anything wrong with that. They have become Ubuntu.

Those people have lives, too, you should respect that.

If you think you can do better, feel free to step in, but also be ready to take the blame when something bad happened and you were responsible.
i.e. because you bumped something to quick or you didn't test it properly.
I've been doing packaging (although not on Arch) for more than 10 years now, trust me, I know what it takes and how badly you can mess up …

Also, my experience with Arch packages really isn't what you described. Most packages are updated relatively soon after a release, not only KDE, but most other packages as well.

[dwagner]

I for one have largely no reason to complain about Arch'es update speed. Sure, if you have a special interest in the bleeding edge version of some application (like I actually have for 'mpv'), then I compile the application on my own from the source code - NOT replacing the version I got with Arch, but putting it in /usr/local.

And on more than one occasion I was happy that I could easily run /usr/bin/mpv instead of my bleeding-edge /usr/local/bin/mpv, because sometimes bleeding edge is buggy and you do not have time immediately to fix the bugs.

Regarding the speed of adoption of ksomething applications - that was at times "too fast" for my taste. "kdenlive", for example, was updated to the "rewritten" version at a time when it was way too unstable and lacked relevant features the older version had. Luckily, "kdenlive" did mature again since then, but for quite a while I needed to retain a much older version to be able to work on video projects.

IMHO there is no comparison to Fedora - Fedora is not giving you the same freedom of choices what software to use if there are competing implementations.