Right now we will always use GLTextureHandle frames with Quick. This is
great in many cases, but not always. Applications that wish to examine
the frames (e.g. via video filters) will sometimes prefer frames in
system memory, even if this is slower to display.
Add QT_QUICK_NO_TEXTURE_VIDEOFRAMES which can be used to disable texture-based
video frames.
[ChangeLog] The environment variable QT_QUICK_NO_TEXTURE_VIDEOFRAMES
can now be used to disable OpenGL texture based video frames. This can be useful
in applications that wish to filter and process the video frames and are not
GPU based.
Change-Id: I5ca6f6d485d5bc6c2da8d47db563cd910c238ac9
Reviewed-by: Yoann Lopes <yoann.lopes@theqtcompany.com>
There's no good reason to do so. Backends can actually provide empty
frames, for example when flushing the pipeline or after stopping
playback.
Change-Id: I687c12b667e31b25e91c3201f59c52a8969d8e05
Reviewed-by: Andrew den Exter <andrew.den.exter@qinetic.com.au>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I1c6faa4f59f8eca54f01ef20941fa60161dd7872
Reviewed-by: Yoann Lopes <yoann.lopes@theqtcompany.com>
Add the QAbstractVideoFilter base class and integrate it with VideoOutput.
This can be used to perform arbitrary filtering or image processing
on the frames of a video stream of a VideoOutput element right before
the OpenGL texture is provided to the scenegraph by the video node.
This opens up the possibility to integrate computer vision
frameworks or accelerated image processing with Qt Quick applications
that display video streams using Qt Multimedia.
Conceptually it is somewhat similar to QVideoProbe, this
approach however allows modifying the frame, in real time
with tight integration to the scenegraph node, and targets
Qt Quick meaning setting up the filter and processing the results
of the computations happen completely in QML.
[ChangeLog] Added QAbstractVideoFilter that serves as a base class for QML
video filtering elements that integrate compute, vision, and image processing
frameworks with VideoOutput.
Change-Id: Ice1483f8c2daec5a43536978627a7bbb64549480
Reviewed-by: Yoann Lopes <yoann.lopes@theqtcompany.com>
Enable qt.multimedia.video to get the logs. Also enhance the printing
when creating the video node implementation. It is essential to have
an easy way to figure out what handle and formats the node in use
supports.
Change-Id: Idf3a9f076ba03b5e613c19f2347204c841850b45
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
Each plugin must provide its own unique key. Otherwise we will only ever
see one single plugin.
Right now running on i.MX6 is often broken because the imx6 videonode plugin is
not picked up since only the egl one is seen by the system. With the fix both plugins
provide their own unique key so both become visible.
Additionally, introduce a QT_VIDEONODE environment variable. This is useful to specify
which plugin to use. This is necessary in case multiple custom videonode plugins support
the same formats.
Change-Id: Iaa1988f8436dcb938cb9a95e2e0d68a4e92e113c
Reviewed-by: Yoann Lopes <yoann.lopes@theqtcompany.com>
[ChangeLog] Added a VideoNode plugin which allows direct rendering of
EGLImageKHR backed video frames.
Change-Id: I36fb6fd27680dbe9c71a446bbd54df95488725f8
Reviewed-by: Yoann Lopes <yoann.lopes@digia.com>
This patch uses the GL_OES_EGL_image extension to create a OpenGL Texture handle
for a libscreen pixmap. If the extension is not available it uses the "old"
technique as fallback where the image data is copied into a QImage.
This reduces the CPU load by more than 70% and allows HD videos to be played jitter-free.
Task-number: QTBUG-37752
Change-Id: I4cad22c39390e4cf9eb5be5f0bfe446544a11b9e
Reviewed-by: Bernd Weimer <bweimer@blackberry.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Move QDeclarativeVideoOutput to the private QtMultimediaQuickTools
library to make the QDeclarativeVideoOutputBackend interface
implementable by a plugin.
Change-Id: I763c483a1fc9ec56dc7b8be0bc71523f029a36ee
Reviewed-by: Yoann Lopes <yoann.lopes@digia.com>
