This improves the documentation by exposing a C++-idiomatic way to
handle the resources without leaking for most users copying this part of
the code to their application.
QOpenGLFramebufferObject::takeTexture is detaching the current texture
and transfering ownership to the caller, and the texture was never
destroyed afterwards. It was leading to a huge memory consumption and
leak when using the sample app.
From the documentation[^1] in Qt5:
Returns the texture id for the texture attached to this framebuffer
object. The ownership of the texture is transferred to the caller.
If the framebuffer object is currently bound, an implicit release()
will be done. During the next call to bind() a new texture will be
created.
[1]: https://doc.qt.io/qt-5/qopenglframebufferobject.html#takeTexture
Co-authored-by: Alexandre Janniaux <ajanni@videolabs.io>
For the commit message and cleaning the fix mostly.
Fixes#25867
Precision is available but no-op on GLSL 130 (see [3], section 4.5.2)
and mandatory for OpenGL ES. It was first reserved on GLSL 120 and
didn't exist in GLSL <= 110 (= OpenGL 2.0). Since it's a no-op, the
easiest solution is to never use it for OpenGL code.
This description is also copied into the sample to explain to the users
that they might have difference in behaviour depending on whether they
are using OpenGL or OpenGL ES2, and depending on the version of OpenGL
used.
The precision qualifier was added because Qt was linked from the
contribs, which was linked with -opengl angle and thus was actually
using OpenGL ES2, which needs the precision qualifier.
Resources used:
[1]: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.1.10.pdf
[2]: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.1.20.pdf
[3]: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.1.30.pdf
On Windows if I don't set this I get the following error:
QOpenGLShader::compile(Fragment): ERROR: 0:3: '' : No precision specified for (float)
ERROR: 0:8: ';' : syntax error
This is more flexible as it doesn't depend on a shared ID3D11DeviceContext.
A NULL callback is still allowed as long as the host app does the
OMSetRenderTargets on their single ID3D11RenderTargetView.
In some cases the decoder might ask for a decoder device that will use the
setup callback. But in the end it's not using the decoder device. Then the
display module is created, without knowing about that decoder device (via a
video context) and calls the setup callback again.
Unless the decoder device that is created in the vout is passed to the display
module, we need to allow those multiple calls per session.
Fix the D3D11 sample to take this in account. The D3D9 sample already takes
care of it.
It allows to configure the example with, for instance, the following
command line:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ qmake ..
PKG_CONFIG_PATH can be adapted to the path where libvlc has been
installed and/or where Qt is available.
This also remove the unused parts, and add QT += widgets which is needed
to compile.
VLCVideo was not released, probably because it was considered like a
QObject (new VLCVideo(this)) and thus expected to be destroyed
automatically like a QObject.
Use a std::unique_ptr<> to destroy it when the parent widget is
destroyed.
We don't need to display avcodec logs typically, and we mostly want to
give feedback to the user about what is loaded and what is happening,
meaning info, error, warn, dbg.
We're waiting for the surface to be available and protecting the surface
from having multiple clients at the same time, but it typically didn't
return the token when cleanup(), meaning that any second open was
actually a deadlock in the waiting.
cfg, out, width and height are needed when the user want to adapt the
aspect ratio of the video on the rendering surface, but the sample
doesn't show this, so silence the warnings anyway.
Since there were two threads running concurrently for the same context,
eglMakeCurrent could fail almost everytime.
When two such threads exist, different OpenGL context must be assigned
to each of them and the correct resource sharing mechanism must be
enabled so that the rendering thread can use the resources generated by
the producing (VLC) thread.
In addition, we need the OpenGL context from the actual window for the
rendering, which will not be available right in the constructor, so
synchronize its creation through a semaphore, delaying the opening of
the vglmem module on the VLC side until the video is ready to be
rendered on the Qt side too.
The sample can now be built using either directly `qmake` (using
pkg-config to find the library on the system) or with the longer
`PKG_CONFIG_PATH=/path/where/vlc/is/installed qmake`.
Jean-Baptiste Kempf
Alexandre Janniaux
Hugo Beauzée-Luyssen
Craig Turner
Steve Lhomme
Rémi Denis-Courmont
Martin Finkel
Romain Vimont
Thomas Guillem