Broken "Render to Texture Buffer" with libvlc 4.0

Greetings,

LibVLC May nightly build do work beautifully with code similar to:

https://github.com/videolan/vlc/blob/master/doc/libvlc/QtGL/qtvlcwidget.cpp

More recent builds have been broken in regard to render to texture buffer and it's been really difficult to locate the actual problem on my own.

The visual result now is that the render buffer is outputting solid green frames.

To help solving the issue, I've upload two versions of the log to compare/diff:

May build (working): http://hymedia.ca/hymedia.ca/vlc/vlc_working.txt

Latest build (broken): http://hymedia.ca/hymedia.ca/vlc/vlc_broken.txt

One thing that stands out is that Lua scripts are not being loaded in recent builds, could that cause any issues?

Thank you,

Added attachment:

• vlc_broken.txt

Added attachment:

• vlc_working.txt

assigned to @alexandre-janniaux

Hi,

I broke it, and fixed it, sent on the ML, but unfortunately it needed changes and I haven't tested vgl and other things like it currently after those so it's not merged, and there will be changes needed in your code.

What broke it is the libvlc_opengl refactor. I fixed it in https://patches.videolan.org/patch/29519/, and in your case especially:

> -libglwin32_plugin_la_CFLAGS = $(AM_CFLAGS) $(OPENGL_COMMONCFLAGS) -DHAVE_GL_CORE_SYMBOLS
> -libwgl_plugin_la_CFLAGS = $(AM_CFLAGS) $(OPENGL_COMMONCFLAGS)
> +libglwin32_plugin_la_CFLAGS = $(AM_CFLAGS) $(OPENGL_COMMONCFLAGS)
> +libwgl_plugin_la_CFLAGS = $(AM_CFLAGS) $(OPENGL_COMMONCFLAGS) -DHAVE_GL_CORE_SYMBOLS

which fixes the currently broken glwin32. However with opengl callbacks it means that you'll need to actually provide the OpenGL implementation, and your get_proc_address implementation will need to provide all opengl functions, meaning you'll probably need a GetProcAddress in addition to wglGetProcAddress.

I'll try to do the testing leftover and resubmit in the next days.

added Component::Video: misc. plugins label

Oh, very well then. Would you considered making changes to qtvlcwidget.cpp (or else) so we have an example to chew on?

Replying to [comment:2 neosettler]:

Oh, very well then. Would you considered making changes to qtvlcwidget.cpp (or else) so we have an example to chew on?

Of course, that's planned before the sending of the v2 patchset.

Hi Alexandre, I do not mean to rush things by any means but is there an ETA approximation for resolving this issue?

Replying to [comment:4 neosettler]:

Hi Alexandre, I do not mean to rush things by any means but is there an ETA approximation for resolving this issue?

I've merged the addition to the QtGl sample, but not yet the other patches. I'll try by the end of the week or next week since it's almost ready, I was wondering whether I find a solution for #25256 (closed) (ie. typically EGL extensions through the OpenGL callbacks, but wgl would need that too) before.

Hi Alexandre, how is it going, any progress?

Hi,

Actually I was mistaken, the commit I've linked did break it for you, but the fix is actually on you side, you'll need to implement the get_proc_address callback like this on Windows for wgl: https://patches.videolan.org/patch/31310/

Basically we'll expect all function to be loadable through get_proc_address.

Hi Alexandre, thank you for your support.

The link you've sent is quite confusing to read. I use Windows nightly build:

https://download.videolan.org/pub/videolan/vlc/

Is this patch already merged with the master? What about qtvlcwidget/QtGl, are they updated as well? How are we supposed to compare the before and after mechanic?

Qt implements the same behaviour, as described here: https://code.videolan.org/videolan/vlc/-/blob/master/doc/libvlc/QtGL/qtvlcwidget.cpp#L167

The patch is not merged, but describe the fix to achieve on your side.

Can you share your get_proc_address implementation to help you fix this?

Hi Alexandre, thanks again for your support.

This is starting to feel like a misunderstanding.

getProcAddress mechanic was already in qtvlcwidget.cpp in May 2020 and my implementation was working fine at that time. Same code base on my part stop working between may 2020 and this post (3 months ago). If I cant get my hands on your patch using the nightly builds and qtvlcwidget.cpp is about the same today compared to May 2020, I'm not sure what needs to be fix on my side. What am I missing here?

Hi,

Indeed, I haven't looked into details but there's some additional work to do on the extension discovery. I've found a workaround for this and #25256 (closed) but I might not have time until next week. I'll keep you updated.

Hi,

I've sent the fix to the mailing list for windows: https://patches.videolan.org/patch/31488/ If accepted, I'll merge and then close the ticket, so you'll be able to test through the nightly build that follows the merge. I'll iterate on the other platform afterwards.

added Platform::Windows desktop label

changed milestone to %4.0

Hi, note that this is not merged because it leads to a black screen unfortunately for now.

marked this issue as related to #25867 (closed)