Loading a profile automatically based on video info #977

Closed
Soukyuu opened this Issue Aug 2, 2014 · 25 comments

Projects

None yet

5 participants

@Soukyuu
Soukyuu commented Aug 2, 2014

I saw mpv supports profiles, but they have to be manually loaded by the user from what I see. Would it be possible to add further configurations options allowing setting conditions to load a profile automatically depending on video

  • resolution
  • fps
  • bit depth
  • ...

Use case would be for example to use a different scaling algorithm based on video resolution or fps, to either improve video quality or save some resources in case of a weaker gpu.

@wm4 wm4 added the enhancement label Aug 2, 2014
@wm4
Member
wm4 commented Aug 2, 2014

Not really simple, because by the time e.g. the resolution is known, it's already too late. (And more dynamic methods of changing settings would be needed than the config file loader.)

@Soukyuu
Soukyuu commented Aug 2, 2014

I guess it would require parsing the file metadata before starting to render. mpv only has a simple GUI, I guess a more advanced one could handle this... and would just pass the --profile switch to mpv or something?

@wm4
Member
wm4 commented Aug 2, 2014

What does this have to do with GUIs?

@Soukyuu
Soukyuu commented Aug 2, 2014

It just struck me that having a sort of profile rules dialog in a GUI would make the whole decision making external to mpv (core?) itself, and more a feature of the GUI/wrapper program (kind of like SMplayer for mplayer).

Of course, integrating it into mpv itself would be nice to have.

@wm4
Member
wm4 commented Aug 2, 2014

Also note that you can use Lua scripting and the (undocumented) vo_cmdline command to automatically change vo_opengl options at runtime.

It's just that the profile loading mechanism really doesn't fit in here.

@Shudouken
Contributor

You could write a lua script that runs before loading the video file and calls mediainfo on it, then parses parameters like fps, resolution and so on and changes the options. Would only work on linux though I guess, not sure if os x or windows have mediainfo. Also wouldn't work with youtube links etc. unless you download the file first.

@Argon-
Contributor
Argon- commented Apr 18, 2015

Well, that's basically what wm4 said.
While this works in theory, it would result in lua scripts being used as config files and I guess we can agree on this is not the way things were supposed to be.

Imo the ability to change or activate --profiles with LUA scripts would be better.

@ghost
ghost commented May 5, 2015

I am really interested in profile autoloading to adjust settings according to the video.
Is it possible to autoload a profile with a lua script ?
If yes, can someone give an exemple to write that script please ?

Thank you

@wm4
Member
wm4 commented May 5, 2015

Is it possible to autoload a profile with a lua script ?

Not yet. But on the other hand, this wouldn't do more than setting options and properties, which you can do with Lua anyway. (Though it'd force you to have your own profile files and parsing.)

Personally, I'd like to wait until I unify options and properties, so the users don't have to figure out what's the difference between them.

@Soukyuu
Soukyuu commented May 27, 2015

I'm currently tinkering with a lua script (first time writing one, really) and I got so far that I can parse file properties. Is triggering the lua function with mp.register_event("start-file", profile_select) already too late to change vo options? Can you please share some more info on that undocumented vo_cmdline command?

@wm4
Member
wm4 commented May 27, 2015

Is triggering the lua function with mp.register_event("start-file", profile_select) already too late to change vo options?

No, but it may be too late at this point (because event delivery is asynchronous). You can work this around by using a hook (like the ytdl script). Also, if the VO is already created (e.g. because this is the second file being played), changing the options will currently do nothing.

What I plan is:

  • make options settable at runtime, in a way that they are actually applied even to VOs
  • make profiles settable at runtime
  • make profiles and their contents accessible to Lua

But it could take weeks until I get there. (There are other things to do too.)

@Argon-
Contributor
Argon- commented May 27, 2015

Is using a hook more reliable/earlier than just "letting the script run (once)" when loaded? That's what I'm currently doing and it's fast enough to change the VO, unless you use force-window=immediate.

@Soukyuu
Soukyuu commented May 27, 2015

So it will at least work for single files for now. Good to know.

@Argon- : do you mind sharing the script you are using?

@Argon-
Contributor
Argon- commented May 27, 2015

This one. I'm basically using it only for VO options, although it can set other options as well (e.g. like hwdec in l.153). Not particularly nice, but it's only supposed to be "bridge technology" until I can use this script to set profiles (then I'm going to define them in mpv.conf and set them with this script).

@wm4
Member
wm4 commented May 27, 2015

Is using a hook more reliable/earlier than just "letting the script run (once)" when loaded?

They're different use-cases. A hook is called per-file, and before the file is actually loaded.

That's what I'm currently doing and it's fast enough to change the VO, unless you use force-window=immediate.

If it's convenient, scripts could be loaded before the VO is created the first time.

@Argon-
Contributor
Argon- commented May 27, 2015

It certainly would be convenient for this purpose, however, not sure about the implications for other things. Maybe a special "before anything actually happens/is configured/set" hook?

@wm4
Member
wm4 commented May 27, 2015

Changed the point at which scripts are loaded.

@Argon-
Contributor
Argon- commented May 27, 2015

Ok, great, thanks.

@wm4 wm4 added the low priority label Jul 18, 2015
@wm4 wm4 added a commit that referenced this issue Aug 28, 2016
@wm4 wm4 command: export profile list as a property
Targeted at scripts, which can do whatever they want with it. This comes
with the promise that they could get randomly broken any time.

See #977.
f42e437
@wm4
Member
wm4 commented Aug 28, 2016

Since this isn't progressing at all, I added a way to export profiles (see above).

I imagine this could be used to attempt to apply profiles at runtime, by setting each profile item as property, and if that not works, via the options/ property.

I might even try to implement this in mpv/C, but there's a lot of crap to deal with since options and properties are still inconsistent at times (also, updating VO options).

@lachs0r
Member
lachs0r commented Nov 5, 2016

https://github.com/wm4/mpv-scripts/blob/master/auto-profiles.lua

I consider this solved with that script.

@lachs0r lachs0r closed this Nov 5, 2016
@Soukyuu
Soukyuu commented Nov 5, 2016

Thank you. The script could use some (more) examples, though, like how to load a profile based on a name pattern or resolution (this used to work with the script posted by Argon above). Or is there some extended documentation somewhere?

For example, I just tried it with

cond:string.find(mp.get_property_osd("filename"), 'mypattern')

and the script errored that condition did not return a boolean.

@Soukyuu
Soukyuu commented Nov 5, 2016

Actually, all of the useful properties (filename, path, width, height) listed in the manual seem to be nil when the condition is evaluated. So my condition obviously also evaluates to 'nil`

The script is completely useless like this, unless I'm doing it wrong, which is highly possible.

@lachs0r
Member
lachs0r commented Nov 5, 2016 edited

You’re doing it wrong.
cond:string.find(get("filename", ""), "mypattern") ~= nil

@Soukyuu
Soukyuu commented Nov 8, 2016

Ok, that seems to be working, thanks. Is there more documentation for this, though?

@Argon-
Contributor
Argon- commented Nov 8, 2016 edited

Actually, all of the useful properties (filename, path, width, height) listed in the manual seem to be nil when the condition is evaluated. So my condition obviously also evaluates to 'nil`

No. Well, yes, at the very start but conditions get re-evaluated when the properties of this condition change. So yeah, first evaluation will probably yield unwanted results as many properties are nil but once their values change the appropriate conditions get re-evaluated and profiles applied. Using get you can set default values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment