| | <<<Back 1 day (to 2014/12/14) | 20141215 |
| Robin_Watts | >tor8 Post arrived. Many thanks! | 10:57.10 |
| | D'Oh. Wrong talker. | 10:57.17 |
| avih | tor8: https://github.com/mpv-player/mpv/pull/1351 | 11:24.45 |
| | so try to make api changes less frequent ;) | 11:27.43 |
| tor8 | avih: cool! | 11:28.07 |
| avih | :) | 11:28.18 |
| tor8 | avih: you've only had to suffer through one API change, IIRC | 11:28.25 |
| avih | it's a big patch, probably has bugs with only me testing it until now | 11:28.41 |
| | 2 i think, actually. to and back from context+flags at newstate :) | 11:29.21 |
| | and the function names. | 11:29.30 |
| | no biggie :) | 11:29.34 |
| tor8 | yeah, that was a short-lived one. the function names is the one I was thinking of. | 11:29.43 |
| avih | tor8: the mpv guys have some concerns with APL3 compatibility with GPL2. would you mind joining the conversation at #mpv-player-dev at freenode? | 11:33.08 |
| Robin_Watts | avih: The only difference between AGPL3 and GPL3 is in what happens if you have code running on a server on the web. | 11:39.27 |
| avih | mpv is GPLv2... | 11:39.55 |
| Robin_Watts | I can't see why you'd ever want the MPV code to run on a server (it might get served by the server, but it runs locally, right?) | 11:39.58 |
| | hence the question is probably GPLv3 vs GPLv2, right? | 11:40.11 |
| avih | we'd want to distribute mpv binaries, which we want to include mujs... | 11:40.33 |
| tor8 | the "problem" as it is, is between GPLv2 and AGPLv3 (the extra A-clause is possibly incompatible with GPLv2, and there is no language to make an exception like there is with GPLv3) | 11:41.14 |
| | Robin_Watts: so in summary, the A in the AGPLv3 creates licensing incompatibility headaches for GPLv2 projects | 12:00.11 |
| Robin_Watts | right. | 12:16.40 |
| tor8 | might be worth discussing whether moving to AGPLv3 has been worth the trouble, or whether we should just go back and be more licensing friendly with plain GPL | 12:17.52 |
| Robin_Watts | tor8: For gs etc, where running on a server is a big thing, I think it's worth it. | 12:20.01 |
| tor8 | Robin_Watts: clause 13 of the AGPL (the A clause) has an explicit exception for linking with GPLv3 | 12:20.08 |
| Robin_Watts | For mujs, maybe less so. | 12:20.12 |
| tor8 | which works for GPLv2+ projects but not GPLv2only | 12:20.23 |
| Robin_Watts | but then embedding js on a tiny iot device which offers a webserver is a use case for mujs. | 12:21.16 |
| tor8 | right, dropping the A is irrelevant for mpv. their beef is with GPLv3. not much we can do there as things currently stand. | 12:29.01 |
| avih | Robin_Watts: "iot"? | 12:53.34 |
| kens2 | IoT = Internet of Things | 13:07.06 |
| avih | right | 13:08.21 |
| | Robin_Watts: tor8: summary: either mujs adds GPLv2 or some other GPLv2only compatible license, or we're at a licensing issue which will most probably make mujs impractical for mpv. | 13:08.45 |
| | in a scale of 1-10, how likely is this ^ to happen? | 13:09.37 |
| Robin_Watts | And the mpv developers have an objection to moving to GPLv3? | 13:09.47 |
| | I think it's unlikely to happen, certainly in the short term. | 13:10.03 |
| avih | it would seem so. seems they already have issues with GPLv2+ | 13:10.09 |
| Robin_Watts | mujs is a new product, and we're still feeling out how to make money from it. | 13:10.32 |
| | Releasing a version under GPLv2 is a bell we can only ring once. | 13:11.04 |
| avih | yeah, not complaining. trying to understand where we stand, and regretting not checking the license compatibility issues deeper earlier. shit happens... | 13:12.07 |
| | i put some time into adding mujs support, but IMO licensing issues carry more weight. so right now this probably means the patch will not integrate into mpv-master, and i probably won't keep rebasing it. which means it's likely to go into oblivion. | 13:14.14 |
| Robin_Watts | avih: That is a shame. It would appear that you've been a really useful source of bug reports/fixes. | 13:17.37 |
| avih | Robin_Watts: i'd like to think of myself more than that, but yeah, that too :) | 13:18.34 |
| Robin_Watts | sorry, I was in no way meaning to denigrate your contribution - rather trying to acknowledge it. | 13:19.39 |
| avih | i know, no worries :) | 13:19.50 |
| | i did have fun (and some pain) with it. the thing which i think is a shame is not my wasted time (well, a bit of that too) but mostly that mpv probably missed an opportunity to integrate a very familiar scripting language which could bring more users to use scripting (lua is, afterall, less common than js)... | 13:21.23 |
| | or, if you prefer, that mujs missed an opportunity for much wider audience than it had till now (and there were quite a few mujs crash bugs which were not fixed while only mupdf was using it) | 13:26.19 |
| | since mpv is slowly but surely replacing mplayer as the best video player around | 13:27.07 |
| | and me.. i just wanted to script mpv with js ;) | 13:28.56 |
| Robin_Watts | avih: You could ship 2 binaries of mpv, one with mujs and one without? The one with would have to be GPLv3, and then end users could pick? | 13:30.03 |
| avih | anyway, if the licensing situation changes, pls ping me | 13:30.09 |
| Robin_Watts | avih: We will have a staff meeting on here tomorrow (in about 26 hours time) | 13:30.31 |
| avih | Robin_Watts: we could, but apparently it's also an issue for libmpv | 13:30.33 |
| Robin_Watts | We'll try to raise it again tomorrow. | 13:30.42 |
| | AIUI (and IANAL of course), it's not a problem for any GPLv2 code to be released as GPLv3. | 13:31.13 |
| | s/again/at the meeting/ | 13:31.25 |
| avih | the plan was to make it a default component, but if it can't be expected to work on cases mpv cares about (such as libmpv), then it probably better off without it, IMHO. | 13:32.16 |
| Robin_Watts | Would mujs have been part of libmpv? | 13:32.33 |
| | Or would libmpv just have had the ability to use mujs if present? | 13:32.47 |
| | The former would be a problem, the later not, AIUI. | 13:33.07 |
| avih | as for the license compatibility issue, tor8 was at #mpv-player-dev having this discussion a bit earlier, and i posted here what i understand to be the summary of this discussion. | 13:33.08 |
| | IANAL either, but it appears that libmpv has an issue with AGPL3 and even with GPLv2+. | 13:34.02 |
| tor8 | my takeaway from the discussion is that mpv care more about adoption than open source, which makes me wonder why not use BSD in the first place | 13:34.47 |
| avih | Robin_Watts: but you're welcome to pop to #mpv-player-dev and discuss this issue with wm4 (the main maintainer and strong opinion-ed about licensing guy) | 13:34.49 |
| Robin_Watts | I am not trying to change the opinions of anyone. | 13:35.11 |
| avih | neither do i | 13:35.26 |
| tor8 | but with a hundred cooks and old code base license, relicensing to BSD is nigh impossible | 13:35.31 |
| Robin_Watts | If libmpv was to have mujs bundled into it, then I completely see that there is a problem. | 13:35.37 |
| tor8 | Robin_Watts: I suspect it's the which compile-time options do we use for this distribution question that's the problem with libmpv, and not wanting to maintain multiple variants | 13:36.36 |
| Robin_Watts | If, on the other hand, libmpv was simply to have a scripting plugin API as part of it that could be entirely GPLv2. | 13:36.45 |
| | Then we could have a wrapped up mujs plugin that used that API. And people could only install that plugin if they were happy with GPLv3. | 13:37.21 |
| avih | Robin_Watts: licensing issues aside, it would seem to me that both mujs and mpv has much to gain from such integration. but apparently the licensing issues stand in the way right now, and personally i fully respect those issues. but if you guys and wm4 could sort it out.. i'll be the last to say anything against it ;) | 13:37.51 |
| Robin_Watts | but that does lead to a more complex situation than just the "here is 1 binary, it does everything" situation. | 13:37.52 |
| tor8 | Robin_Watts: a dlopen-style plugin interface. | 13:38.00 |
| Robin_Watts | tor8: I have no opinion on what sort of mechanism, but sure. | 13:38.32 |
| tor8 | Robin_Watts: yeah. I think 's the way to do plugins as optional components rather than built-in. | 13:40.15 |
| Robin_Watts | avih: I suspect it wouldn't be too much work to convert your changes to mpv into such a form. | 13:42.05 |
| | but then you'd presumably want to ensure than the mpv guys were happy with that approach before going to any more trouble. | 13:42.33 |
| avih | Robin_Watts: not sure exactly what form it is, but i suspect you're right. however, before you add those changes, i'd still discuss it with wm4 to make sure it ends well :) | 13:42.56 |
| Robin_Watts | avih: The changes would be to your code. | 13:43.16 |
| | Let me see if I can describe it some more. | 13:43.24 |
| avih | i'm fine with changes to my code as long as it doesn't create issues for mpv | 13:43.36 |
| Robin_Watts | At the moment, you have some changes to mpv that perform calls into the mujs lib, right? | 13:43.55 |
| | I'm suggesting that you recast those changes a bit. | 13:44.13 |
| avih | platform being mpv/mpvlib ? | 13:44.15 |
| Robin_Watts | I didn't mention platform. | 13:44.36 |
| avih | (and yes, it links with libmujs) | 13:44.37 |
| | sorry, perform. yes, it does | 13:44.47 |
| Robin_Watts | Right. | 13:44.53 |
| | So I'm suggesting that you split that code in two. | 13:45.03 |
| avih | i'm listening | 13:45.15 |
| Robin_Watts | You have a layer that mujs calls. | 13:45.16 |
| avih | ? | 13:45.32 |
| | mujs doesn't call anything... | 13:45.48 |
| Robin_Watts | Bah. Typo. Let me try that again. | 13:46.02 |
| avih | :) | 13:46.07 |
| Robin_Watts | You have a layer that mpv/mpv lib calls. | 13:46.15 |
| avih | ok | 13:46.23 |
| Robin_Watts | This layer checks for there being a mujs plugin available. If there is, it loads the plugin, and then forwards the calls through to that plugin. | 13:46.24 |
| avih | you mean in runtime? | 13:46.38 |
| Robin_Watts | All that code is GPLv2 and can be bundled as part of libmpv/mpv. | 13:46.46 |
| | yes, it's a runtime check. | 13:46.50 |
| avih | including mujs.h? | 13:47.04 |
| Robin_Watts | No. | 13:47.11 |
| avih | ah | 13:47.20 |
| | i need to wrap that too then | 13:47.26 |
| Robin_Watts | No mujs specific dependencies in that part. | 13:47.26 |
| tor8 | the code in mpv would dlopen a shared library containing mujs and some wrapper code. | 13:47.47 |
| avih | yeah, i understand | 13:47.57 |
| Robin_Watts | All the mujs specifics go into the other half of the code with mujs itself. | 13:48.08 |
| avih | but then we'll have to distribute that library also, and it's back to square one, is it not? | 13:48.14 |
| Robin_Watts | That forms the 'mpv mujs plugin'. | 13:48.26 |
| tor8 | then call a function in the dlopened library, passing in a struct of function pointers (the mpv functions that the mpv-mujs-plugin needs to call) and it also returns a struct of function pointers that the mpv-side can call | 13:48.27 |
| Robin_Watts | avih: The end point of this is that mpv/libmpv can continue to be shipped as GPLv2. | 13:48.59 |
| avih | but that dlopened library (let's call it libmujsmpv) will have exactly the same issues we have now | 13:49.02 |
| tor8 | then you can make the mujs+wrapper code optional, a runtime link dependency | 13:49.07 |
| | and ship it separate from mpv, but if it's there it can be used | 13:49.19 |
| Robin_Watts | And if people *choose* to, and are happy with AGPLv3 they can also install the mpvmujsplugin. | 13:49.39 |
| tor8 | and hence, you can ship mpv with its gpl2 license, and the plugin (which at the time you load it) will make the whole gpl3 | 13:49.50 |
| Robin_Watts | So you're keeping the main project 'pure', but enabling users to make the choice if they want. | 13:50.24 |
| avih | this would need a distribution channel for mpvmujsplugin, separate from mpv | 13:50.30 |
| | a maintenance nightmare... | 13:50.47 |
| Robin_Watts | (And of course, it means anyone else could implement a different plugin that didn't use mujs if they so wished) | 13:50.55 |
| avih | TBH, for the relatively small piece of code which mujs is, it sounds to me like too much overhead | 13:51.41 |
| | if it can't distribute with mpv, then it's back to square one mostly IMO. maybe step 1.5. | 13:52.32 |
| | ("small piece of code" is actually a complement for the coding, as it's seriously useful IMO) | 13:53.13 |
| Robin_Watts | avih: The only further argument I can offer for this solution is this... | 13:53.54 |
| | if the split of your code is done sufficiently nicely, then it need not have any js specifics in there. | 13:54.25 |
| | You can implement a generic 'scripting plugin interface' for mpv. So that other people can add plugins for any language they want. | 13:55.02 |
| tor8 | like the existing Lua plugin interface | 13:55.32 |
| avih | rai don't disagree. but i already have mujs specific code, so if i'm rewriting and refactoring, i might as well start again with something which has a more compatible license ;) | 13:55.33 |
| Robin_Watts | C#, VisualBasic, python, perl... | 13:55.35 |
| avih | Robin_Watts: ^ | 13:55.39 |
| | Robin_Watts: the "generic scripting interface" already exists. the 2K LOC the patch contains make it use mujs | 13:56.35 |
| Robin_Watts | avih: But it's not a plugin interface, right? It's a compile time thing. | 13:56.59 |
| avih | most of the code is for converting between mpv to javascript data structures, adapting argument types between js calls to mpv's api, and generic non-mujs-specific js code which implement modules/require, js timers, etc | 13:57.58 |
| | yeah, not generic as in runtime loading. | 13:58.13 |
| Robin_Watts | avih: Right, the thing that's missing is the runtime loading. With that, the issues of GPL compatibility are moved from the binary maker to the installer. | 13:59.30 |
| avih | Robin_Watts: the issue is that if it can't be distributed together with mpv/libmpv, then it loses much of its attractiveness. | 14:00.22 |
| | you can have a look at the patch here https://github.com/mpv-player/mpv/pull/1351/files | 14:00.37 |
| Robin_Watts | avih: The MPV guys would be unhappy hosting a second download (the plugin) alongside their binary downloads? | 14:01.43 |
| avih | i'm willing to put more effort into making it happen if that's possible, but if it can't be distributed together with mpv, then i don't want to put that time | 14:01.53 |
| Robin_Watts | I completely understand. | 14:02.21 |
| avih | Robin_Watts: mpv is distributed with many linux distributions. it's more than about hosting | 14:02.40 |
| Robin_Watts | avih: Lots of linux distributions have to cope with this stuff already. Ubuntu has separate repos for differently licensed things. | 14:03.29 |
| avih | Robin_Watts: this is not my natural playground (licensing issue and working around them). if you can sort something out with wm4 from mpv, then i'm willing to put the work to implement it. | 14:04.39 |
| yukam | (jbig2dec) finally, solved 042_1[34].jb2 WTFness; in addition to half dozen inane jbig2dec bugs, they were produced by pre-standard encoder (that have not handled REFAGGNINST=1 as special case) | 14:23.10 |
| avih | Robin_Watts: Robin_Watts: no worries, i enjoyed it and learned while doing this. even if mpv doesn't end with js support soon. and i do think it's an impressive piece of code, so thanks for maintaining it (tor8 mostly probably) :) | 14:42.38 |
| | and i'm fine with it and take the blame for not checking the licensing issues deeper than what i have. see, another lesson learned ;) | 14:43.33 |
| tor8 | avih: like Robin I am sorry that your work seems like it will come to a sad end | 14:43.41 |
| | and I really appreciate your work in helping to iron the kinks out of mujs | 14:44.04 |
| avih | tor8: thx. and cheers for mujs and your great support for it :) | 14:44.19 |
| tor8 | avih: any time. | 14:44.53 |
| avih | and if you think the licensing issues could somehow be solved, do ping me (that is, if i still haven't started using another embedded js implementation yet) | 14:45.09 |
| kens | Gahhh!!!! The PCL interpreter gaily replaces the4 color procs in the device....... | 16:42.25 |
| Robin_Watts | kens: It stashes them and replaces them with other ones that call through to the originals? | 16:49.56 |
| kens | It stahes them then replaces tehm with completely different ones. Later it puts them back. | 16:50.16 |
| Robin_Watts | boggle. | 16:50.24 |
| kens | THis doesn't work at all for a forwarding device | 16:50.25 |
| | Because the forwarding device passes the call on to the underlying device, only it now has different color mapping procs..... | 16:50.52 |
| | Well, differnt to the ones that PCL thinks it has | 16:51.13 |
| | It looks like a nasty hack to handle 'monochrome mode' (aka gray scale) | 16:51.31 |
| Robin_Watts | yes. | 16:52.24 |
| kens | Its going to have to change. | 16:52.34 |
| | I have a work around in place to test it with | 16:52.45 |
| | The more I look into all this, the cleasre it becomes why my bbox forwarding device didn't work. | 16:53.45 |
| Robin_Watts | I think in general it's a bad thing to do. | 17:00.05 |
| | It's OK for the device to switch bits of itself out, but callers should never delve into the device. | 17:00.23 |
| kens | Yes, I agree too (and this applies to the clist too). | 17:00.39 |
| | It also breaks what I'm trying to do totally. | 17:00.50 |
| Robin_Watts | Well, the clist is a slightly different animal. | 17:01.00 |
| kens | But its not the only place that does this | 17:01.01 |
| Robin_Watts | The clist is *part* of the device, and therefore is (more) permitted to change the internals of the device. If you're going to be a clist device, you have to accept that the clist is going to molest you in personal places. | 17:03.19 |
| kens | I don't think the clist *should* be part of the device. | 17:03.34 |
| Robin_Watts | That's a separate argument :) | 17:03.46 |
| kens | The clist should be a device in its own right, in front of the rendering device | 17:03.50 |
| Robin_Watts | At the moment the clist *is* part of the device. It would be much nicer as you describe. | 17:04.03 |
| kens | Eventually, I may push ot do that work too, but not till I've recovered from this particular nightmare | 17:04.20 |
| mvrhel_laptop | morning | 17:04.27 |
| kens | Morning Michael | 17:04.34 |
| Robin_Watts | But the caller really should not be fiddling with such stuff. | 17:04.36 |
| | morning. | 17:04.38 |
| kens | Robin_Watts : yeah, but like I said, its not the only place :-( | 17:04.50 |
| Robin_Watts | kens: Is the list of such places large? | 17:05.04 |
| kens | Which leaves me with some rather outre arsing about to work around the problems. | 17:05.06 |
| | Robin_Watts : I no longer remember, I;ve been working on this too long. If you want to guess you can look at the device_subclassing branch on my repo. All but the latest PCL fix is there | 17:05.45 |
| | OK so PostScript, PDF and PCL all now work with all the devices we test on a cluster push, just some weirdnesses with XPS to go. | 17:07.36 |
| | But at least that's the pdfwrite fmaily, clist and non-clist modes for the common rendering devices (and including the odd psdcmyk device) | 17:08.15 |
| | Apparently I'm going out for a pizza... Night all | 17:12.19 |
| mvrhel_laptop | cool got the crazy encoded images working for xpswrite | 19:55.08 |
| | Forward 1 day (to 2014/12/16)>>> | |
IRC Logs