MPV Player 0.35.1 Released With Wayland & PipeWire Fixes

[TemplarGR]

As far as I can tell (which is still an assumption), is that the maintainers are testing certain things to assure some credibility to the update. A library package is a sensitive node that (in many cases) can cause problems to other packages and screw up a lot of systems if not handled correctly.

Also, not updating fast doesn't mean "do not care", it could mean "taking our time to handle this correctly with the resources we have". At times people need to be aware of the circumstances at play and not just assume that the end-user wishes has to be met at all cost.

They don't have to meet any end-user wishes at all. They don't owe us anything, and i never implied that they do. But we end-users do not owe them to never criticize them or the distro either...

That said, if you have been an old Arch user, you can certainly feel the difference and the lag in updating packages. Not all packages, some core (not just from core repository, just "essential") packages do get updated soon. But this makes Arch feel like Ubuntu, where some select packages are the stars of the show and the vast majority are in limbo and if you need/want them you have to add them yourself manually or use ppas.

Most of the time it is just laziness. Don't pretend it is anything other than that. They are not testing anything. For example they wait for LLVM to "mature" because they do not want to update it often when it gets point versions. They want to deliver it once it is clear it won't get any point versions. They don't do the same for the kernel or mesa though, and those are more likely to break and affect systems badly, than LLVM/Clang... Same with GNOME. Even if a brand new version breaks some extensions, who cares? We can disable them until they are compatible, no reason to delay getting the new GNOME version. Extensions are not part of the main GNOME experience. They just do not care. KDE gets updated instantly and it too has extensions and themes...

[Quackdoc]

As far as I can tell (which is still an assumption), is that the maintainers are testing certain things to assure some credibility to the update. A library package is a sensitive node that (in many cases) can cause problems to other packages and screw up a lot of systems if not handled correctly.

Also, not updating fast doesn't mean "do not care", it could mean "taking our time to handle this correctly with the resources we have". At times people need to be aware of the circumstances at play and not just assume that the end-user wishes has to be met at all cost.

the issue with arch specifically is that it happens really often lately, they either need to downsize the number of packages that are being maintained, or need to take a long look at what is going on and fix it, I get conflicts happen, but when even ubuntu is beating arch in how up to date some packages are...

[TemplarGR]

the issue with arch specifically is that it happens really often lately, they either need to downsize the number of packages that are being maintained, or need to take a long look at what is going on and fix it, I get conflicts happen, but when even ubuntu is beating arch in how up to date some packages are...

Or perhaps post a call for more developers on the front page, and define a clear procedure to recruit new people for the team. For many years, their recruiting procedure has been very fuzzy and unclear. Of course they will deny this as they have done in the past, but then again, ask them what to do to be in the team, you will find out soon enough they don't really want you. They appear to be lacking people, but do not want to recruit new blood either. They prefer to let the distro suffer instead of allowing new people in.

I get it, they can't allow every single stranger access to modifying the distro, but they should restructure their team and repositories in a way to allow for a "core team" and an "extended team" of maintainers, doing the work for less significant packages. Not much different to the existing way with trusted users and community repo, but with more "trusted users" and more stuff in the "community" repo. Anything that the core team can't pledge to dedicate resources to in a timely manner, should be relegated to community.

But they just won't do it because that is the nature of volunteer projects: They don't feel the need to make them really better and don't really want to lose the "power" they have over the project. They would rather make the project suffer instead. I am only using Arch these days because i am lazy and i don't want to bother distro hopping again. But i have been eyeing stuff like Opensuse tumbleweed for some time.

[lumks]

Too many developers simply do not care for the project and are only involved for their self-serving reasons

Thats why you should get involved. If you dont care about the packages you maintain, it will lower the quality. It's as simple as that.

, while they refuse to let in new people to replace them

Thats BS. They look for more people to maintain things. It's the people who are unwilling or unable to join/maintain specific things. Arch even got rid of the Trusted users and Developers concept to be more open. Even relatively new maintainers can now do changes to extra. That was previously not possible.

. Many packages take too long to get an update.

Thats often for a reason. Since Arch tries to not do versioned packages "libblabla4", they have to wait for downstream to be compatible with the new version of libblabla before they can upgrade it. There are more reasons. Just ask the mailinglist or the maintainer directly.

The only thing you can count on Arch to have in its repos immediately is KDE

The KDE Team/ARojas does pretty good work, yes.

, everything else may take even many months before it gets updated.

It's a community project. Join the team and change this

[QUOTE]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.

Have you asked what the reason for this is?

They have become Ubuntu.

A Stable release? Not at all.

[lumks]

I was actually here to ask if mpv by now works better on GNOME-Wayland?

[TemplarGR]

Thats why you should get involved. If you dont care about the packages you maintain, it will lower the quality. It's as simple as that.



Thats BS. They look for more people to maintain things. It's the people who are unwilling or unable to join/maintain specific things. Arch even got rid of the Trusted users and Developers concept to be more open. Even relatively new maintainers can now do changes to extra. That was previously not possible.

Nice to know that they made changes recently. I do admit that i haven't looked in their internal procedures recently, i only judge by the outcome. It is nice that they look to rectify these issues. I will look at joining them in the future. Last time i checked, years ago to be honest, the thing i found out was that i should be an AUR maintainer and perhaps i would get to become a Trusted User in the future. But most AUR packages i am interested in already have a maintainer.

[lumks]

Nice to know that they made changes recently. I do admit that i haven't looked in their internal procedures recently, i only judge by the outcome. It is nice that they look to rectify these issues. I will look at joining them in the future. Last time i checked, years ago to be honest, the thing i found out was that i should be an AUR maintainer and perhaps i would get to become a Trusted User in the future. But most AUR packages i am interested in already have a maintainer.

I think you still need to be on the AUR. But for the lookup process you only need to show that you're trustworthy and can do work with packaging, conflict resolving and such stuff. Your PKGBUILDs/packages will for some time still be validated by a "senjor"-maintainer at least before they go to the repo.

[Brisse]

I was actually here to ask if mpv by now works better on GNOME-Wayland?

Works for me with the following settings.

#mpv 0.35
vo=gpu-next
#gpu-api=vulkan
#gpu-context=auto
profile=gpu-hq
#scale=ewa_lanczos
#cscale=ewa_lanczos
#video-sync=display-resample
#interpolation
#tscale=oversample
hwdec=auto-safe
​

Things that don't work properly:

video-sync=display-resample

Supposed to make playback as smooth as possible, but does the opposite in my case

gpu-api=vulkan

Actually works now, but forces vaapi-copy so I see no reason to use it

vo=dmabuf-wayland

Not working on GNOME. Said to need changes in mutter before it can work.

And lastly, mutter does not yet support idle inhibit protocol. I use this plugin as a workaround.

[Quackdoc]

gpu-api=vulkan

Actually works now, but forces vaapi-copy so I see no reason to use it

what you lose by doing vaapi copy, you gain back by using vulkan instead of opengl, vulkan is far more preformant then the opengl one, meaning you can either save power in the rendering, or you can run heavier shaders like fsrcnnx or nnedi and get better performance from them.

EDIT: its important to note that vaapi-copy should only be forced on older cards for AMD and for intel... not entirely too sure actually, this is due to a missing vulkan extension required for libplacebo to do zero copy. so if you have GFX9 or newer it should work

https://gitlab.freedesktop.org/mesa/mesa/-/issues/5882

[Tian]

Works for me with the following settings.

#mpv 0.35
vo=gpu-next
#gpu-api=vulkan
#gpu-context=auto
profile=gpu-hq
#scale=ewa_lanczos
#cscale=ewa_lanczos
#video-sync=display-resample
#interpolation
#tscale=oversample
hwdec=auto-safe
​

Things that don't work properly:

video-sync=display-resample

Supposed to make playback as smooth as possible, but does the opposite in my case

gpu-api=vulkan

Actually works now, but forces vaapi-copy so I see no reason to use it

vo=dmabuf-wayland

Not working on GNOME. Said to need changes in mutter before it can work.

And lastly, mutter does not yet support idle inhibit protocol. I use this plugin as a workaround.

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.