Want to work on mpv?
you want to work on mpv and don't know where to start? there are open issues that could possibly be fixed. though this might not be a good or easy start into mpv.
there are various things that still need to be done, with varying difficulties and different scopes. some of these are a good start into our code and can be done independently from any other tasks. anyway, the plan is to finish every task on the list, let everyone know of the current status, keeping track of people working on those tasks and coordinating that work properly. if you want to do any of those yourself, just let us know and we will plan appropriately and try to assist you as well as possible.
General
| S | D | Description | Assignee |
|---|---|---|---|
| :x: | :green_circle: | a community manager that handles various tasks, communicating with users, triaging issues, adjusting docs, etc | |
| :x: | :green_circle: | fix remaining compilation warnings and remove exclusions from meson.build ➜ | |
| :white_check_mark: | :green_circle: | ~fix remaining lua lint warnings ➜~ | @guidocella |
| :white_check_mark: | :green_circle: | ~add Python linting to CI ➜~ | @nathanruiz |
| :x: | :yellow_circle: | port our website to an up-to-date version of Middleman / Ruby | |
| :x: | :red_circle: | add a way for libmpv to work with libplacebo/gpu-next | |
| :x: | :red_circle: | add a way to package mpv scripts/shaders/etc. and make them updatable, to automatically manage these scripts |
Linux
| S | D | Description | Assignee |
|---|
macOS
| S | D | Description | Assignee |
|---|---|---|---|
| :x: | :green_circle: | update wiki for compiling distro releases | |
| :x: | :green_circle: | fix fixable deprecation warnings | |
| :x: | :green_circle: | add meaningful verbose/info logging to common/windowing | |
| :x: | :yellow_circle: | use swiftc (swift compiler) instead of swift (swift frontend) for building osdep/mac/meson.build meson.build | |
| :x: | :yellow_circle: | rewrite bundling scripts dylib_unhell.py and osxbundle.py in swift | |
| :x: | :yellow_circle: | move cohesive functionality from common code into separate modules | |
| :x: | :red_circle: | rewrite messy calculateWindowPosition function with a nonlinear function |
|
| :x: | :red_circle: | full featured CI builds with target 10.15 | |
| :x: | :red_circle: | find maintainer for CoreAudio code |
Windows
| S | D | Description | Assignee |
|---|
Legend
| S = Status | D = Difficulty |
|---|---|
| :x: todo | :red_circle: hard |
| :white_check_mark: done | :yellow_circle: medium |
| :green_circle: easy |
Table Editor
Read, edit and output Markdown tables: https://tableconvert.com/markdown-to-markdown
add a way to package mpv scripts/shaders/etc. and make them updatable, to automatically manage these scripts
I have a stupid workaround that will only work on Windows machine, this is just what I use until there's a proper solution to this. (Since this is a stupid workaround I will tag this comment as off-topic)
For windows users who want to auto update user scripts:
Create a .bat file and use scheduled tasks to run this file every day:
powershell -c "Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/po5/trackselect/master/trackselect.lua' -OutFile 'C:\Users\Username\Desktop\mpv\scripts\trackselect.lua'"
So windows will grab the raw github user script and paste it to the directory of user scripts. (Change the URL and directory accordingly)
add a way to package mpv scripts/shaders/etc. and make them updatable, to automatically manage these scripts
I have a very rough proof-of-concept for managing plugins via git. Currently tested on linux and windows 10: https://codeberg.org/NRK/mpvget
My current opinion from working on this is that the ideal long term solution would be for mpv project to come up with a standardized plugin directory structure (similar to vim) and somehow get everyone to update their plugin to conform to such structure. It would eliminate the need for external "package managers" since you can basically just use git submodules at that point.
Also why hand-write markdown tables in here instead of just using github labels? It seems much more flexible. E.g you can have meta:difficulty-{easy,mid,hard} tags for difficulty. We already have os:* tags. And github issues also supports "assignees" already.
Also why hand-write markdown tables in here instead of just using github labels? It seems much more flexible. E.g you can have
meta:difficulty-{easy,mid,hard}tags for difficulty. We already haveos:*tags. And github issues also supports "assignees" already.
i am not really writing the table by hand though. various reasons:
- i don't think the issue tracker is a place for code cleanup and refactoring work. it should be kept to issues, feature request, etc
- the issue tracker is imo already full enough
- the point of this list, is the list itself and not being 'hidden' in the issues
- if there isn't any interested from anyone working on any of the then created 'issues', it would have been a waste of effort and time creating those (filling them with info etc)
- issues on the tracker can still be created when work has been picked by someone and it feels appropriate for communication and/or discussion
- atm it's mostly just my personal backlog/worklog
- i wanted to see if there is even a general interest in this, by people who want to work on something and by others filling the various lists
- imo the issue tracker isn't really more flexible. it just has a different presentation with a set amount of features that can be used to track such things. though if you need something more specific that can't be mapped to any of the features, your are out of luck. in that case some custom list can be extended with such things. eg previously there was a field with dependencies, that indicated which issues depend on other issues.
Any more info on the calculateWindowPosition requirements? Or on the advantage of a nonlinear function here
the hope is to considerably simplify the whole function. atm it's a lot of ifs and it's hard to know/see what those are for.
the function also handles the case that the window changes screens or the screen resolution changes (when in fs), and the window is placed relative at the same position but the same size as before. with a linear function this would place the window off-screen in some cases.
also it seems the function broke a bit over the iterations of new macOS versions and does place the window at weird positions in some cases.
I implemented a script manager some time ago, maybe it's not the best solution, hope it can provide some ideas.
https://github.com/mpv-easy/mpsm-scripts
These are some of the problems encountered during implementation
- The script contains multiple files. We can use the directory tree format, but this will be a little troublesome when removing and upgrading. It is not currently supported.
- js seems to be very suitable for writing scripts. Now that everything can be bundled, no matter how complex the script is, it can be packaged into a js file, which greatly simplifies the management difficulty.
- js does not support reading and writing binary files, which makes it impossible to package fonts and some programs into js. For example, if you need cross-platform clipboard operations, we can use rust to implement it, and then package the binary files of different platforms into one js file, so that the binary files can be automatically detected and generated when the script is running. However, js cannot write binary files, so you can only copy them manually.
- Script dependencies. Some scripts require other scripts to be installed first. Direct installation will not work. Although this package management can use the dependencies field, it will have the same problems as npm. Considering the complexity, it is not implemented yet.