Basically, here seems to be some work to to: the cmplayer dev(s) needs
to push the changes upstream. This is not something done is a haste,
it means producing a number of patches which could be justified
upstream, and probably also some modifications in cmplayer to adapt to
a more generic. upstream.
It might turn out that this is not possible. In that case, I think a
bundling exception could be discussed. However, so far no attempt has
been made, and according to the GL we should not grant an exception in
such cases.
Which admittedly is sad thing to say. Has anyone some way around here?
Perhaps by saying I'm plain wrong? In a way, it would be a relief ;)
--alec
On 1/27/14, Ben Reedy <thebenj88(a)gmail.com> wrote:
On 28/01/14 00:01, Miro HronĨok wrote:
> Dne 27.1.2014 12:48, Alec Leamas napsal(a):
>> Here a t least two possibilities:
>> - You could build using the upstream sources. This an accepted way in
>> a situation like this if there is no library.
>> - You could cooperate with upstream and make them release a library.
>> Miro: are you listening?
>
> Yes I am listening.
>
> I would like to see a real attempt to communicate with mpv upstream,
> to release a library - if that fails, then go with the first option.
>
> To be clear - I'm not doing this, that's up to Ben. I can provide
> help, though.
>
I've contacted one of the MPV developers [1], and they said that there
are plans for a shared library. However, they also re-iterated what the
CMPlayer developer stated:
> But note that cmplayer is not really a frontend. It includes its own
video output and a bunch of other stuff instead of native mpv
functionality.
They also mentioned that the use of the planned shared library wouldn't
work either:
> No... just that cmplayer uses mpv in a way it probably won't be able
to use the shared lib.
[1]
https://github.com/mpv-player/mpv/issues/510