Mpv: lua 5.3 or luajit support needed

[ilovezfs]

I have upgraded lua in Homebrew from 5.2 to 5.3 in https://github.com/Homebrew/homebrew-core/pull/21300. This broke lua support, so mpv now needs

depends_on "[email protected]"

In Homebrew, @ formulae for older versions are temporary, so depending on [email protected] is not a viable long-term solution for mpv.

Some possibilities for mpv in Homebrew:

1. mpv becomes lua 5.3 compatible and switches back to depends_on "lua"
2. mpv switches from depends_on "[email protected]" to depends_on "luajit" (if that works?)
3. mpv builds without lua support
4. something else that makes people :)

[mia-0]

I think by now it is probably okay to depend on Lua 5.3 while dropping compatibility with older versions of the language.

[ilovezfs]

@lachs0r unfortunately mpv with lua 5.3 doesn't actually work yet otherwise that's exactly what we would do :)

[jeeb]

Luajit is already used by various people and should work (I'm pretty sure I build my Windows builds with it). 5.2 to 5.3 upgrade on the API side is not a simple task, so if you have luajit packaged you might just do that on your side.

If someone gets bored they can of course enable upstream 5.3 to work as well.

edit: I don't have any MacOS build VMs around right now so I can't say much about LuaJIT + mpv on MacOS. Just that in general it seems to work.

[Argon-]

Last time I tried: luajit doesn't work with mpv on OSX. wm4 once told me on IRC and I tried to confirm it, successfully: https://github.com/mpv-player/mpv/issues/1110#issuecomment-302879492 I didn't try to figure out the problem back then as I assumed there was a reason it is (still) broken although known.

A switch to 5.3 will also (most likely?) require modifications to all built-in lua scripts. And then we are still left with dozens of potentially incompatible user scripts: https://github.com/mpv-player/mpv/wiki/User-Scripts
I'm not sure how sever the language differences are to be honest.

[ilovezfs]

By default, upstream lua (and Homebrew) build 5.3 with the 5.2 compat option, so I don't think breaking the user scripts is an issue unless they're doing 5.1-only things.

[ilovezfs]

Last time I tried luajit doesn't work with mpv on OSX.

This appears to still be true. Not sure why that would be macOS specific?

With luajit

==> /usr/local/Cellar/mpv/0.27.0_4/bin/mpv --ao=null /usr/local/Homebrew/Library/Homebrew/test/support/fixtures/test.wav
[osc] Could not initialize Lua.
[osc] Could not load lua script @osc.lua
[ytdl_hook] Could not initialize Lua.
[ytdl_hook] Could not load lua script @ytdl_hook.lua
Playing: /usr/local/Homebrew/Library/Homebrew/test/support/fixtures/test.wav
 (+) Audio --aid=1 (pcm_s16le 1ch 8000Hz)
AO: [null] 8000Hz mono 1ch s16


Exiting... (End of file)
[ao/null] buffer underrun

vs. with [email protected]

==> /usr/local/Cellar/mpv/0.27.0_3/bin/mpv --ao=null /usr/local/Homebrew/Library/Homebrew/test/support/fixtures/test.wav
Playing: /usr/local/Homebrew/Library/Homebrew/test/support/fixtures/test.wav
 (+) Audio --aid=1 (pcm_s16le 1ch 8000Hz)
AO: [null] 8000Hz mono 1ch s16


Exiting... (End of file)
[ao/null] buffer underrun

[ghost]

Lu 5.1, 5.2, and 5.3 are different languages. You can compare it to Python2 vs. 3, except with worse compatibility. 5.3 in particular adds an integer data type, which requires major changes both to API user and Lua scripts.

The often cited 5.2 compatibility in 5.3 doesn't seem to exist. There are some compatibility flags, which control the visibility of new and/or deprecated symbols, and a flag for something metamethod related. There is nothing that makes 5.3 run unmodified 5.2 scripts, nor anything that removes the need for major changes in API user code.

So this compatibility mode is a red-herring from what I can tell. But even if it weren't, we couldn't rely that everyone who builds mpv builds Lua with this compatibility enabled. It could even be that such a compatibility mode (which would be a hack from the Lua creator's point of view) would not conflict with legitimate Lua 5.3 API users and scripts, which would further decrease the chance of support.

Moreover, LuaJIT does not support 5.3 (apparently because the author dislikes the language changes). Switching to Lua 5.3 would mean dropping LuaJIT support for good.

Even if you ignore the script compatibility issue, supporting both 5.1/5.2/LuaJIT and Lua 5.3 would be a big mess.

There is a large number of user scripts: https://github.com/mpv-player/mpv/wiki/User-Scripts Certainly we don't want to brick them over night, but from what I can tell, the newly introduced integer type could cause random runtime failures because the scripts do not expect it. I don't know how bad it actually would be (there's a small chance all issues can actually be avoided), but at this point it just seems not worth supporting 5.3.

In fact I have yet to hear a good reason to support 5.3 (or even 5.2), other than that it's "newer". But be reminded again, 5.3 is not just a compatible maintenance release over 5.2 (as the version number might suggest), but a new language based on 5.2.

There is a bit of history about this issue. There is a small FAQ entry, at least 2 rejected PRs for adding 5.3 support, and probably a bunch of closed issues. We won't change just because an overzealous maintainer doesn't understand the issue and demands that we do things that were discussed and rejected years ago.

Anyway, as it stands, there are three choices:

• keep the current status (means everything works, but unhappy homebrew maintainers)
• add support for 5.3 without breaking 5.1/5.2 (this would mean user scripts randomly don't work if they were written for a different Lua version)
• drop support for 5.1./5.2/LuaJIT (probably would break most user scripts, but the situation would stabilize, until Lua 5.4 happens)

(LuaJIT does support OSX, but because of some OSX idiocy (typical Apple), a special build flag is needed: http://luajit.org/install.html (search for image_base). I think it's actually in pkg-config, but waf filters it out for god knows what awful reasons.)

[ilovezfs]

We won't change just because a smug maintainer doesn't understand the issue and demands that we do things that were discussed and rejected years ago.

Just so we're all clear: that person is me and I'm not demanding anything.

[ghost]

Well, making an issue that 5.3 support is "needed" sure sounds demanding to me. mpv will probably require 5.1/5.2 for a long time, so dropping support for those in homebrew also implicitly puts pressure on us to move to a different version of Lua (and, if removed knowingly, certainly implies a strong demand).

It seems you're also suggesting LuaJIT. That is merely a third party implementation of Lua 5.1, with improvements. I don't know if it's as portable as official Lua, but there sometimes are problems associated with it doing JIT (such as the OSX runtime problem).

[ilovezfs]

@wm4 what title would you suggest instead? I'm happy to change it.

[ilovezfs]

In fact I have yet to hear a good reason to support 5.3 (or even 5.2), other than that it's "newer". But be reminded again, 5.3 is not just a compatible maintenance release over 5.2 (as the version number might suggest), but a new language based on 5.2.

It seems you're also suggesting LuaJIT.

5.3 has been the current upstream version of Lua for nearly three years now, there hasn't been a new 5.2.x release in as much time, and there hasn't been a 5.1.x release in nearly six years.

By contrast, LuaJIT 2.0.5 and 2.1.0-beta3 were released in May of this year. So, yes, if Lua > 5.2 is going to be in the "never" column, looking toward a language implementation that's acceptable and currently maintained seems reasonable to me.

That said, according to our analytics for the last 30 days

Install events:
Lua: 46,962
LuaJIT: 16,715

Install-on-request events:
Lua: 6,517
LuaJIT: 1,143

So I would recommend trying to stay on the mainline Lua train if possible in terms of what users will likely be wanting to use over the longer term.

[ghost]

As I've been trying to tell you, 5.2 and 5.3 are different, incompatible (even if similar) languages. On some level that's like trying to argue that we should switch to JavaScript because JS is more actively developed.

I expect that users most likely want working user scripts. Also, nobody ever asked us to support Lua 5.3 because they wanted features that are only in 5.3. (Actually, it appears Lua is mostly hated by those who try to write scripts, but for some reason it seems it's still preferred over mpv's JS scripting support.)

Even if 5.3 and 5.2 are very similar, the change will brick user scripts, and that's not really acceptable. Note that I haven't really tried to quantify how much will break, so you're welcome to try to update mpv to use Lua 5.3 and demonstrate that it doesn't break most scripts (Lua 5.3 compiled without compat options, see my previous post why we wouldn't want those).

[ilovezfs]

Lua 5.3 compiled without compat options, see my previous post why we wouldn't want those

The upstream default configuration and binaries are compiled with the 5.2 compat option, so it's rather peculiar to take that the position that only 5.3 without compat is worth considering.

[ghost]

Which compat options are you specifically talking about? There is LUA_COMPAT_5_2 (which is indeed enabled by default), but affects only very little of the language or the API.

The define mentioned above does the following:

• control whether some deprecated math functions are present (doesn't matter to us, not having them might break 1 or 2 user scripts, but surely those would be updated quickly, or we could provide them manually)
• define whether the "bit32" lib is present (doesn't matter to us)
• controls how the __ipairs metamethod works (doesn't matter to us)
• enable 3 helper macros in the lua.h main API header (virtually useless, we could just define those ourselves if we needed them)

In particular, the compat option does not:

• do anything that helps in mpv's case
• keep compatibility with old Lua scripts even in simple cases (any time you use numbers there is a chance of breakage)
• keep compatibility with the C API

In addition, the manual states that these compat options will be removed in the future.

PRs which tried to support are #1516 and #1914. As you see, they both required changes to the C code and our internal Lua code. (Keep in mind that the OSC is basically a user script, just shipped as part of mpv. This indicates that user scripts would probably need updates as well to work with 5.3.)

All this is actually the same for 5.1 vs. 5.2: some scripts work only on one of those versions, and mpv's C code has some horrible ifdeffery to attempt to support both. But I suspect the situation is way worse in 5.3 because of the integer change, and it would mean we have to support/test 3 Lua versions, which would mean reconfiguring/recompiling 3 times on every meaningful change to the Lua wrapper, or our internal Lua scripts. (I guess we could drop Lua 5.2 support though, which would make it a bit easier again.)

So stop pretending this is easy, just because you don't want to maintain a 5.1 package. At this point you wasted more of our time than it would have been effort to maintain such a package anyway.

In any case, anyone is free to analyze the impact of Lua 5.3 support further (both in mpv's code and user scripts), but I still think this integer type introduction poses inherent compatibility problems that are not easy to fix. There are still 2 fixed outcomes:

• support 5.3 and 5.1 (for LuaJIT) => script authors have to explicitly write code that is compatible with both 5.3 and earlier, and some old scripts will break
• support only 5.3 => LuaJIT support is lost, and some old scripts will break

Doesn't seem very attractive. Just to support some maintainers a few minutes of work every other month.

[ilovezfs]

This.

[ghost]

Well, it doesn't do anything you claimed it does. If you would read my posts...

[ilovezfs]

@wm4 I've read your posts. Try to scale back the hostility a few notches.

[ghost]

Well, it would be nice if you replied to _any_ of the technical points, instead of focusing on perceived hostility and making an issue out of that.

[ilovezfs]

So stop pretending this is easy, just because you don't want to maintain a 5.1 package.

I'm not pretending anything is easy so try not to stick words in my mouth. I am telling you that we won't support a [email protected] in perpetuity.

At this point you wasted more of our time than it would have been effort to maintain such a package anyway.

It's not about the effort to maintain the package. It's about carrying software that has no upstream support, which is the case if there isn't an actively maintained separate 5.1.x release line.

It sounds like the best option at least for the medium term will be to find a way to get the formula working properly using depends_on "luajit" instead of depends_on "[email protected]".

[ilovezfs]

It looks like mpv works with LuaJIT 2.1.0-beta3 built with

brew install --with-gc64 --devel luajit

Not sure yet why --with-gc64 isn't the default.

So it does seem likely LuaJIT 2.0.5, which doesn't have the --with-gc64 option, will work too if the -pagezero_size 10000 -image_base 100000000 thing is sorted out.

[ilovezfs]

@wm4 Is there a reason to prefer Lua 5.1.5 over LuaJIT, or LuaJIT over Lua 5.1.5, from your perspective in terms of what mpv should use?

[ghost]

Just for completeness for anyone unaware:

Lua 5.3 handles numbers differently, which breaks compatibility with _scripts_.

In all previous versions of Lua, numbers were always floats. A number such as "103.0" was printed as "103" and treated as an integer everywhere. A number such as "103.1" was printed as a float.

In 5.3, an integer is always an integer and a float is always a float. A float of "103" is printed as "103.0".

And in a player where numbers are used for on-screen display formatting, assumptions about decimals (103 vs 103.0) were never a problem before but could be a big problem now. It changes everything about numbers and requires analyzing every Lua script to make sure they're going to survive the new number handling (for example: some core scripts in mpv require rewrites to round numbers properly in Lua 5.3).

Another big problem with supporting 5.3 (even with script-side "compat flags") is that some people/distros may compile 5.3 without compat flags, and those flags are going to vanish in a future 5.3 release, and other distros may not even bundle Lua 5.3 at all. Supporting another language (5.3) isn't viable.

As for solving this via LuaJIT: Seems okay unless there are bugs associated with that VM together with mpv (no idea, have personally only used mpv with Lua 5.1). @wm4 mentioned some OS X issues with LuaJIT's JIT above...

[ghost]

In theory, you could write code that doesn't care whether a number is integer or float, but it seems pretty easy to run into conflicts anyway (this affects both in C using the Lua API, and Lua code).

@ilovezfs not really. LuaJIT provides the same API and language as Lua 5.1, so it doesn't matter for us. LuaJIT might have a different set of obscure bugs.

[ddevault]

We can't ignore the issue forever.

Just to support some maintainers a few minutes of work every other month.

Not all downstreams are going to be willing to ship old versions of Lua forever. Eventually Lua 5.4 is going to come out, then Lua 5.5, then maybe Lua 6.0... the situation is only going to get worse. Even if the change is difficult it's still something we're going to have to face. Maybe we can try to support both for a while, but eventually we're almost certainly just going to have to let user scripts break.

[avih]

The problem is that lua maintainers, as far as I know, are willing to break backward compatibility of existing scripts, which makes it hard to depend on them in the long term. If it was only the embedding API then it's probably worth the effort to move to new version, but if a new version can break scripts then it's a really big problem.

With javascript there's standardization, and it's well defined how new versions should behave with regards to older scripts - typically just fine. Of course, js is not perfect either, because well-backed implementations are far from trivial to use (v8 etc), and smaller implementations have the usual issues of projects without many active developers.

It's a real problem overall.

[ddevault]

We can petetion the maintainers to avoid breaking backwards compatability in the future. We can push for language standardization. Let's express our concerns with them and try to work together instead of in a vaccum.

[ghost]

@avih Yeah. Lua is one of the worst languages in the world from a maintenance perspective. They need to learn semantic versioning and respect backwards compatibility. In any other library, 5.1 and 5.2 and 5.3 imply minor versions, but in Lua they are all incompatible with each other.

What's the point of having version numbers if they have zero meaning to Lua? They should just name it Lua@HEAD and be done with it.

Regarding JavaScript: Until today, I didn't even know that mpv had JS support. It uses "MuJS", a tiny single-file, super basic ES5 implementation. It's unfortunately lacking modern ES6 features. But still, JavaScript is lightyears ahead of Lua. For example, Lua doesn't have a built-in string split function (even though splitting and joining strings is one of the most common operations in any program). Instead, it has a "pattern matcher" (gmatch) which is only able to match the text chunks themselves (as opposed to their delimiters). How can anyone take such a language seriously? Lua is only prevalent because its engine is so lightweight and easy to integrate. But as a language it's ridiculously bad.

Regarding MuJS: There are runtime .js libraries which polyfill many ES6 features, which would help the situation a lot and make mpv's JavaScript engine more powerful, but those big libraries would need to be embedded in mpv to be efficient (as opposed to needing to be individually shared with every script).

[ghost]

@avih I think the Lua developers would argue that the correct way to use Lua for embedding is to copy the Lua sources into your project, and then to forget about it (game dev style). Some chances they'd ignore reality as well, and argue that "good" Lua 5.2 code works in 5.3 by not conceptually mixing number types.

@SirCmpwn it's like you didn't read any of my posts. Also nice attempt at ignoring reality thinking that you could convince the Lua devs of anything.

[ghost]

@wm4 Definitely. I also get the impression that Lua's developers prefer Lua to be stuck at static versions embedded inside of applications.

[ddevault]

@SirCmpwn it's like you didn't read any of my posts.

I did, but I can address your points more explicitly if you prefer.

In fact I have yet to hear a good reason to support 5.3 (or even 5.2), other than that it's "newer". But be reminded again, 5.3 is not just a compatible maintenance release over 5.2 (as the version number might suggest), but a new language based on 5.2.

I'm tired of hearing this meme from you over and over again. It's not true. Languages deprecate and break features all the time, perhaps with a little more finesee than Lua has shown.

There is a large number of user scripts: https://github.com/mpv-player/mpv/wiki/User-Scripts Certainly we don't want to brick them over night, but from what I can tell, the newly introduced integer type could cause random runtime failures because the scripts do not expect it. I don't know how bad it actually would be (there's a small chance all issues can actually be avoided), but at this point it just seems not worth supporting 5.3.

"Send patches to known Lua 5.3 userscripts" sounds like a good idea to include in the acceptance criteria of the change.

Also nice attempt at ignoring reality thinking that you could convince the Lua devs of anything.

If we don't approach it with good faith then why should we expect them to?

[avih]

mujs ... super basic ES5 implementation

Not that super basic. I'd call it a pretty complete ES5.1 implementation. Not 1000% standard compliant, but it's quite close and the developers are listening and improve it where required.

Regarding MuJS: There are .js libraries which polyfill many ES6 features

First, this issue is about lua. I only mentioned js as an example.

Specifically for ES6 polyfill, mujs currently can't run it IIRC. There were some mpv versions (in one of my branches) which supported both mujs and duktape and I _think_ duktape can use these ES6 polyfill. But when we merged it to mpv-master we dropped duktape support. It can be restored but requires some effort and agreement, but for now it's indeed only mujs.

Also, typically, mpv scripts are not mega-projects, and ES5.1 is a perfectly good standard on its own and for the vast majority of scripting tasks in mpv, even if ES6 adds features which some like to use.

Let's not get into more details of mpv and js for now, and keep this issue about Lua. Thanks.

[ghost]

@avih Thanks for the extra info. Duktape looks like a better project than MuJS and are moving up from ES5.1 (they have full/partial support for many modern features http://wiki.duktape.org/PostEs5Features.html). But anyway, let's not discuss it here... I agree.

[avih]

looks like a better project than MuJS (they have full/partial support for most modern

"Better" is a very subjective thing which may include many more things than supported features. Like how easy it is to integrate (duktape is more similar to Lua, where mujs is more standard in this regard), code quality, and many more. Don't get there. Both exist, both are good, and they do things a bit differently. For now, We only support MuJS.

[dreness]

While I have no strong feelings about Lua, I do appreciate mpv's script interface and agree that it's important to keep it healthy - and I recognize that this means different things to different people. Without making any assertions about the best time for mpv to use a newer Lua, it does seem at least possible that it will happen at some point. Some percentage of that work would be upgrading the user scripts.

On the topic of script compatibility: does anyone know if it's possible to write an average mpv Lua script in a way that can be reasonably expected to be compatible with 5.1 and also 5.3? For example, maybe there are a set of guidelines / constraints / conventions that, if carefully followed, should result in compatibility across these versions. I haven't looked at the Lua version deltas much yet, but an example guideline might be something like: "Always unambiguously represent numbers as floats, even if they are whole numbers, by including a decimal point and at least one trailing digit" (and I have no idea if that's valid at all in this case, I say it merely to illustrate the concept of a coding convention). If this is possible, documenting compatibility guidelines for mpv script authors might allow the work of upgrading mpv user scripts to be more equitably distributed across space and time.

[avih]

@heelsleeh you completely failed to understand the issue. Upstream maintainers (like for homebrew) don't want to maintain "old" lua 5.1, which create an issue for users, because mpv doesn't want to break existing user scripts by upgrading to a newer versions, but homebrew (and others) don't want to keep supporting lua 5.1 forever.

It's a real issue, which stems from the fact that lua maintainers break compatibility with their new versions. This is beyond the control of both mpv developers and upstream maintainers, and yet both suffer from it.

[mc4man]

Homebrew looks like it'll be a continual complainer here, at some point they'll "upgrade" 5.3 to 5.4 or 5.x, ect.
Why they didn't just add 5.3 for the few instances where it would matter is unclear (if any..
(- most linux distros just provide new versions but don't drop one for the next. I've 5.1, 5.2 & 5.3 available here.

[dreness]

@mc4man I'm not sure there is any single right way to manage stuff like this, because different projects have different values and conventions. From my perspective (and I don't represent homebrew, or anyone else), the job of a package manager is to be aware of these problems and try to minimize their impact as much as possible for end users. That includes having a dialog with project operators.

I found an old Macports thread about this general problem with Lua. Personally I agree 100% with Ryan in comment#20 where he advocates for distinct version-locked lua ports, which are perfectly fine existing along side a moving-target lua package. Today Macports still offers both "lua", and also "lua50", "lua51", "lua52". I think that's a reasonable compromise, as long as the cost of maintaining the older lua packages is reasonable.

If those older Lua versions are not maintained by the lua project, eventually they will become impractical to maintain, because package managers are probably not willing to take unlimited measures to keep them working in the face of all the standard forces (like entropy). Software can become obsolete for a variety of reasons that do not apply evenly across the entire population. That's not a bug, that's a feature :) The ability to use different versions of software includes the responsibility of managing the versions of software being used (this applies to users, developers, and package managers). I'm not saying everybody should be hamstrung by the lowest common denominator, but rather that some form of compromise should be reached.

So anyway... I agree that brew would do well to switch mpv to a version-locked package of lua, because mpv gets no direct benefit from upgrading, and some significant downside. However, even though you may not care about the cost for homebrew of maintaining old lua ports, I think it would be helpful to acknowledge that this cost does exist, and may grow in the future. After all, lots of people get to mpv through homebrew, so in theory there is some shared interest here. With all that in mind, if there are low-cost practices for mpv script authors that can make a possible future Lua upgrade easier, and those practices can take place slowly over time, I think it's worthwhile. I'll do some investigation.

[avih]

if there are low-cost practices for mpv script authors that can make a possible future Lua upgrade easier

The point is: who knows? If lua 5.4 breaks compatibility again then we're back at square 1, so what's the point of such effort if it has to be made over and over?

If the lua maintainers declare that they will make a strong and meaningful effort to keep scripts compatibility (and highly preferably embedding API compatibility) to some lua version, then sure, it's worth the effort and breakage, but if not, then IMO it's just not worth the change, and lua 5.1/5.2 will remain the supported version for as long as possible, and once it's not possible, who knows.

[Teathief]

Could just send a message, drop support for Lua as it diverges and keep Luajit.
Do you have to do anything at all to implement that policy?
You don't have to treat it as the main implementation of the language if you don't want too.
And if a platform doesn't support compiling it with jit support, have scripting in that language disabled during compile on that platform.

[ghost]

@Teathief Agreed. Lua has no respect for backwards compatibility, which is fine for static linking inside game engines but not in big apps that dynamically link to random system-versions of Lua.

LuaJIT is a much safer bet for long-term reliability.

[avih]

Thanks to @wiiaboo , here's the exact issue:

1. Building mpv with luajit on OSX succeeds, but ends up with mpv not able to initialize lua at runtime.
2. The luajit installation page says:

If you're building a 64 bit application on OSX which links directly or indirectly against LuaJIT, you need to link your main executable with these flags: -pagezero_size 10000 -image_base 100000000 .

1. luajit.pc doesn't have these flags - I didn't try homebrew but I did try luajit from macports and also built luajit git-master myself - both luajit.pc don't have them.
2. Even if luajit.pc does have the correct link flags (I added them manually to the Libs section), waf fails to use them correctly. Instead it passed one flag while compiling each C file, clang warns on every file, and the end result is the same - mpv cannot initialize lua at runtime.

So the only solution I have so far is to manually set LDFLAGS while configuring mpv, like so:

LDFLAGS="-pagezero_size 10000 -image_base 100000000 ${LDFLAGS-}" ./waf configure
./waf build

This ends up with working luajit in mpv, confirmed working both with macports luajit and with my own luajit git-master which I built myself, and I'd guess it will work with homebrew's luajit too.

[ilovezfs]

yes it's in our .pc https://github.com/Homebrew/homebrew-core/blob/8b574ec9e76dd620789bf9e3d82d3313ef260c7a/Formula/luajit.rb#L74

[Argon-]

Devel luajit from homebrew compiles just fine with mpv. In fact, I'm running it for 2 weeks now.

In this time I haven't noticed serious regressions, however, I have noticed around 5 rendering bugs with the OSC and mpv-progressbar so far that I have never seen before. As they are rare (5 in 2 weeks) and not reproducible for me, I can't tell (yet) if this is just coincidence or because of luajit.
The errors in question were incorrectly sized ASS elements, so probably something happened while calculating dimensions for these respective elements. We're talking about "big" mistakes, like a play-button overlapping the whole video, not some minor stuff.

Edit: make that 6 although in this case it's a minor problem with a "kind of recent" feature, so might be a bug:

[avih]

I have noticed around 5 rendering bugs with the OSC and mpv-progressbar so far that I have never seen before

Considering you're using Devel + GC64, it could be the cause of the bug. I suggest that you try my method with the release version and the manual LDFLAGS setup.

Devel is luajit 2.1 (beta 3 currently), GC64 is not enabled by default at the Makefile or homebrew, and considering this relatively recent comment:

The mailing list is still pretty active in terms of bug reports with this feature

and the (relatively slow) pace of luajit development, I'd say it could be it.

[jdek]

brew install luajit --devel --with-gc64 is what I've been using, for anyone stumbling across this issue. GC64 does seem to be a 'working fix'.

[rnkn]

@wm4

In fact I have yet to hear a good reason to support 5.3 (or even 5.2), other than that it's "newer".

To add a non-technical perspective, having only just discovered mpv, I went to install it but then stopped when I saw it depended on an old version of Lua. In my experience, outdated dependencies is usually a sign of a dying project. I found this thread out of curiosity but I'd guess others just see [email protected] and don't install.

[CounterPillow]

Yes, person who no longer works on mpv, please change the fabric of the universe to make sure that bigger number not bigger so user looking at dependencies not confused! Me think too different for look at repository to see if project alive, me now off to charge AirPods. Mmmm crayons.

[rnkn]

@CounterPillow I think you're missing the point. A layperson isn't going to look at the repository. But I'll let you get back to your crayons 😉

[CounterPillow]

A layperson isn't going to look at dependencies, comparing them to the latest version.

[rnkn]

I'm a layperson. I don't know the difference between Lua 5.1 and 5.3. I don't know Lua. I just know that mpv wanted to install the old version, which made me wrinkle my nose.

[CounterPillow]

Choose one:

• Break every user script written and no longer support Luajit
• Make rnkn wrinkle his nose

This is a tough one.

[rnkn]

I guess you assume most people ought to prefer the first option, but I think this is misguided. If the layperson passes over a project at the installation stage, it doesn't really matter what's going to break afterwards. I'm not suggesting the maintainers should make appeasing my laypeople brethren and I their top priority, I was just adding a perspective that those smarter than me perhaps wouldn't have considered, i.e. given my naivety concerning different versions of Lua, I was hesitant to install an old version because I don't know if that would cause me problems.

[jeeb]

I don't think multiple Lua versions replace each other. If they do that's a deliberate choice on the packager's side.

For example, Fedora (and I think Debian f.ex.) still have Lua 5.1 as compat-lua* (as that seems to be the more popular one of those based on the older version). mpv also supports Lua 5.2 just fine, which happened to have less changed compared to 5.3 where they suddenly did some changes that change more fundamental things. I think this shows that mpv is not the only application still utilizing the older Lua language (which is separate from software versions of Lua).

Also if you don't like to install older official Lua or for some reason or your packaging system doesn't support installing two of them next to each other, then LuaJIT is another alternative, which is an alternative implementation of the language as it was with Lua 5.1. I have been using it with my Windows builds for quite a while now.

I think at some point there was a patch to add Lua 5.3 support, but I don't think anyone even had the time to test if the scripts included in mpv (including the on-screen controls and youtube-dl integration). Even if we ignore all external scripts, we would at the very least have to test those included with the player itself and add a warning to users that if you choose to build with 5.3 it can cause breakage with scripts.

[ghost]

There's also a FAQ entry: https://github.com/mpv-player/mpv/wiki/FAQ#Why_does_mpv_not_support_Lua_53

In summary, I don't think mpv will ever switch away from Lua 5.2, even if it's considered "outdated" by some. Unless a newer Lua version (Lua 5.4 etc.) restores some compatibility, or someone can demonstrate a way to switch to 5.3 without breaking user scripts. Both pretty unlikely.

[Akemi]

luajit works, lua5.3 support won't come for reasons mentioned. colsing.