Windows "failed to initialize mpv GL context" in console with example and "Couldn't load plugin" in window.

[sirisian]

If I use the latest mpv-1.dll (2020-10-04) this mpv.js project doesn't work. Neither the electron app or my own application. The regular mpv player works fine though so perhaps something changed with how mpv.js interacts with the dll.

If I randomly just grab an older mpv-1.dll from a few months ago (haven't tested specifically where it broke) then it starts working again.

(I'm posting this mostly for others as this is the first time I've ever had such an issue). Image for reference,

[sirisian]

Ah so this is very recent it turns out. On the 64-bit builds: https://sourceforge.net/projects/mpv-player-windows/files/64bit/

The 2020-08-30 one is the last one that works with the electron example player.

[vgarleanu]

This is due to the deprecation of all the functions in mpv/render_gl.h. This plugin should start using the mpv/render.h api

[n1kk]

Had same issue, but the link posted by @sirisian is for windows executable, I needed libmpv dll from here https://sourceforge.net/projects/mpv-player-windows/files/libmpv/ , took one from 2020-08-30 as @sirisian suggested and it worked.

Would be great if latest dll was supported.

[sirisian]

@vgarleanu That worked. For reference all I did was change render_gl.h to render.h in index.cc and copy and paste the two structs below from render_gl.h to the top of the index.cc file ad-hoc.

/**
 * For initializing the mpv OpenGL state via MPV_RENDER_PARAM_OPENGL_INIT_PARAMS.
 */
typedef struct mpv_opengl_init_params {
    /**
     * This retrieves OpenGL function pointers, and will use them in subsequent
     * operation.
     * Usually, you can simply call the GL context APIs from this callback (e.g.
     * glXGetProcAddressARB or wglGetProcAddress), but some APIs do not always
     * return pointers for all standard functions (even if present); in this
     * case you have to compensate by looking up these functions yourself when
     * libmpv wants to resolve them through this callback.
     * libmpv will not normally attempt to resolve GL functions on its own, nor
     * does it link to GL libraries directly.
     */
    void *(*get_proc_address)(void *ctx, const char *name);
    /**
     * Value passed as ctx parameter to get_proc_address().
     */
    void *get_proc_address_ctx;
    /**
     * This should not be used. It is deprecated and will be removed or ignored
     * when the opengl_cb API is removed.
     */
    const char *extra_exts;
} mpv_opengl_init_params;

/**
 * For MPV_RENDER_PARAM_OPENGL_FBO.
 */
typedef struct mpv_opengl_fbo {
    /**
     * Framebuffer object name. This must be either a valid FBO generated by
     * glGenFramebuffers() that is complete and color-renderable, or 0. If the
     * value is 0, this refers to the OpenGL default framebuffer.
     */
    int fbo;
    /**
     * Valid dimensions. This must refer to the size of the framebuffer. This
     * must always be set.
     */
    int w, h;
    /**
     * Underlying texture internal format (e.g. GL_RGBA8), or 0 if unknown. If
     * this is the default framebuffer, this can be an equivalent.
     */
    int internal_format;
} mpv_opengl_fbo;

I also had to go into the binding.gyp file and change the "C:/mpv-dev/x86_64" to "C:/mpv-dev" in the following section:

            }, "target_arch=='x64'", {
              "library_dirs": [
                "C:/nacl_sdk/pepper_49/lib/win_x86_64_host/Release",
                "C:/mpv-dev",
              ],
            }],

I think that's because I got the mpv-dev from here: https://sourceforge.net/projects/mpv-player-windows/files/libmpv/

@Kagami should be able to use the above information to fix this.

In any case this build does not work on the new versions of nw.js like 0.49.0 or the latest build. It works fine on 0.39.2 for example. I'm still investigating why, but I assume nw.js changed something or Chromium did to break compatibility with pepper plugins. I'll follow up with their developers. For reference I see:

[sirisian]

I fixed my nw.js issue. See here: nwjs/nw.js#7670 It all works again now.

[oguzkulcu]

@vgarleanu That worked. For reference all I did was change render_gl.h to render.h in index.cc and copy and paste the two structs below from render_gl.h to the top of the index.cc file ad-hoc.

/**
 * For initializing the mpv OpenGL state via MPV_RENDER_PARAM_OPENGL_INIT_PARAMS.
 */
typedef struct mpv_opengl_init_params {
    /**
     * This retrieves OpenGL function pointers, and will use them in subsequent
     * operation.
     * Usually, you can simply call the GL context APIs from this callback (e.g.
     * glXGetProcAddressARB or wglGetProcAddress), but some APIs do not always
     * return pointers for all standard functions (even if present); in this
     * case you have to compensate by looking up these functions yourself when
     * libmpv wants to resolve them through this callback.
     * libmpv will not normally attempt to resolve GL functions on its own, nor
     * does it link to GL libraries directly.
     */
    void *(*get_proc_address)(void *ctx, const char *name);
    /**
     * Value passed as ctx parameter to get_proc_address().
     */
    void *get_proc_address_ctx;
    /**
     * This should not be used. It is deprecated and will be removed or ignored
     * when the opengl_cb API is removed.
     */
    const char *extra_exts;
} mpv_opengl_init_params;

/**
 * For MPV_RENDER_PARAM_OPENGL_FBO.
 */
typedef struct mpv_opengl_fbo {
    /**
     * Framebuffer object name. This must be either a valid FBO generated by
     * glGenFramebuffers() that is complete and color-renderable, or 0. If the
     * value is 0, this refers to the OpenGL default framebuffer.
     */
    int fbo;
    /**
     * Valid dimensions. This must refer to the size of the framebuffer. This
     * must always be set.
     */
    int w, h;
    /**
     * Underlying texture internal format (e.g. GL_RGBA8), or 0 if unknown. If
     * this is the default framebuffer, this can be an equivalent.
     */
    int internal_format;
} mpv_opengl_fbo;

I also had to go into the binding.gyp file and change the "C:/mpv-dev/x86_64" to "C:/mpv-dev" in the following section:

            }, "target_arch=='x64'", {
              "library_dirs": [
                "C:/nacl_sdk/pepper_49/lib/win_x86_64_host/Release",
                "C:/mpv-dev",
              ],
            }],

I think that's because I got the mpv-dev from here: https://sourceforge.net/projects/mpv-player-windows/files/libmpv/

@Kagami should be able to use the above information to fix this.

In any case this build does not work on the new versions of nw.js like 0.49.0 or the latest build. It works fine on 0.39.2 for example. I'm still investigating why, but I assume nw.js changed something or Chromium did to break compatibility with pepper plugins. I'll follow up with their developers. For reference I see:

Thank you. MPV.JS was no longer working on macOS. When he followed what he said, he started working.

[n1kk]

I just recompiled the binary with latest libmpv and it all worked, no changes to index.cc were required. I realized that project uses prebuild that downloads pre-built binaries first and only if they are not available it builds from source. After figuring out where all sources need to be and adjusting some paths in bindings.gyp I just ran node-gyp rebuild against latest libmpv header files, latest dll and pepper sdk 49 and it started to work again.

Tricky part was to make sure all the paths are pointing to the right place. I've also found that appending location of dll to electrons env Path removed the need to copy it to System32 folder each time.

process.env.Path = `${libmpvDir};${process.env.Path}`;

Now all my dependent sources are in one place.

[nadecancode]

I just recompiled the binary with latest libmpv and it all worked, no changes to index.cc were required. I realized that project uses prebuild that downloads pre-built binaries first and only if they are not available it builds from source. After figuring out where all sources need to be and adjusting some paths in bindings.gyp I just ran node-gyp rebuild against latest libmpv header files, latest dll and pepper sdk 49 and it started to work again.

Tricky part was to make sure all the paths are pointing to the right place. I've also found that appending location of dll to electrons env Path removed the need to copy it to System32 folder each time.

process.env.Path = `${libmpvDir};${process.env.Path}`;

Now all my dependent sources are in one place.

Is there anyway that you can share the compiled binaries? I attempted your way and the @sirisian 's way but it's still could not load plugin.

[Kylart]

@Kagami Do you plan on fixing this problem with a new release?

I don't want to fell pushy, I'm asking so that everyone can know what to expect.

[vgarleanu]

@Kagami I think this project is pretty much unmaintained, you should probably just fork and fix it yourself.

[Kagami]

Sorry, I have no time to work on this right now.

[rmanzaneque]

Hi!

Same bug on mac 10.15.7

any solution?