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`.
Now that we use a union we can differentiate each properly.
In particular the D3D9 is an unsigned FourCC.
It's still not as strongly typed as it could be (no DXGI_FORMAT for example).
VLC adjusts the text rendering based on the rendering area size, so we should
be able to adapt to changes in the host app.
This is using the wextern dummy window, like it's done with D3D callbacks. The
callback is given to the host app when the window is enabled and reset when the
window is disabled.
Not sure how it's supposed to be done with Android but given it uses a
regular window, it probably reports size changes already.
The OpenGL callbacks can now tell the bitdepth request, the full/studio range,
the color space/primary/transfer.
For now we only support 8-bits full range BT.709 rendering.
Alexandre Janniaux
Martin Finkel
Steve Lhomme
Thomas Guillem