How to prevent QT from drawing to the screen? (prevent flickering when video played with gstreamer) - qt

This is QT5. Its on an embedded Yocto system, with QT drawing to the framebuffer, no X11. The problem is this. I want to play a video using gstreamer. So, I tried to launch gstreamer with gst-launch-1.0 linked to a touch event in QT. Problem is, it flickers as QT also tries to render frames.
Next, we tried Q media player. However, this proprietary gstreamer doesn't support playbin, so, I went into QGstreamerPlayerSession and modified the constructor to use gst_parse_launch to set up my pipeline instead of playbin.
This works, in that my video plays. However, there is still the same flickering! I tried to throw up a white rectangle before launching the video, but it still flickers.
How could I prevent QT from redrawing? Do I need an empty scene before playing the video? Or is there a function call to pause redrawing?
I could of course send a SIGSTOP to QT, play the video in an external application, then resume with a SIGCONT. That works, but is obviously a very inelegant and restrictive solution (I need the app to be processing in the background still as its controlling other things as well).

Related

Audio unable to play in Aframe unless the inspector is opened

I have been working on adding background music to a Glitch project. I followed the Aframe.io documents to create a sound component and set it to automatically play upon running, however, when I try to run the project, the sound does not play automatically on my laptop. I have to open the Aframe inspector and un-pause my project for the music to begin. For some reason, I have not encountered this issue when I tried the same project on my phone. The sound played as expected once the program is up and running. I am not sure what is causing the sound to malfunction but any help is greatly appreciated. Here is the project I am working on: https://glitch.com/edit/#!/animation-animate?path=index.html%3A15%3A23
when working with sounds natively with Aframe, I had the same problem and one of the recommendations that I can give you is to play sounds with the HowlerJS sound library, which is compatible with most frameworks and also compatible with A-Frame
I share their page and the documentation, this library is very easy to use and implement to the project
https://howlerjs.com/
https://github.com/goldfire/howler.js#documentation
Autoplay audio on most modern browsers requires user interaction before enabling audio. You can put a div in front of your scene that upon click starts playing your background audio.
Check out a related SO question / answer for video autoplay that should help:
Autoplaying videosphere from A-frame is not working on any browser(Safari/Chrome)
Another user on A-Frame discord provided this example demo:
https://aframe-autoplay-background-music.glitch.me/

A-Frame: how to simulate tracked controllers when developing on desktop?

My HTC Vive is set up in a different room to my developer workstation. When developing for A-Frame, I understand I can: use my desktop monitor instead of a headset; use mouse dragging instead of motion controls; use WASD instead of room-scale tracking. However, what is the preferred way to simulate the tracked controllers?
For example, how can I move the cubes in this demo from my desktop: https://aframe.io/examples/showcase/tracked-controllers
This is not yet released, but we're working on tools to be able to record camera and controllers, output to a file, and then you can load it up any device and replay the camera and controller pose and events without needing a headset. Project is led by Diego:
https://github.com/dmarcos/aframe-motion-capture
http://swimminglessonsformodernlife.com/aframe-motion-capture/examples/
This will become the common way to develop for VR without having to enter and re-enter VR to test each code change, and to do it on the go

Qt camera image stays black after adding a QOpenGLWidget

Reproducing the issue
Go to the Welcome page in the Qt Creator and select the 'Camera Example'. Verify that your camera is working properly first by compiling it. Then add a QOpenGLWidget in the designer to the camera.ui form. Run again, now the webcam should stay black.
Specs:
Windows 8.1
Qt 5.5
This is how it looks like for me:
http://i.stack.imgur.com/oE2Pe.png
A little more backstory
I'm working on a project that requires a video feed to work with OpenGL. I was using a QAbstractVideoSurface to get the image data for individual frames. I ran into this issue by just trying to add a QOpenGLWidget into the mix to see what happens. I haven't looked further into it yet other than searching for other reports of this. I couldn't find anything specific though.

QML window resize/move flicker

I'm developing a simple QML application right now and I noticed that resizing and moving a QML window generates an ugly flicker compared to a QtWidgets window, for instance.
So I created 2 test applications to show the difference:
QWidgets:
QML:
As you can see the QML version of the application flickers pretty ugly while the QtWidgets one is clean. Now this gets pretty ugly when your UI grows in complexity.
Do you have any knowledge about this? Is this a bug? Is there any fix/workaround for this issue?
You can try this:
int main(int argc, char* argv[]) {
QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);
or
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
The first option uses OpenGl2DirecX angle library (like Google Chrome)
The second one uses OpenGL emulation by software... for small programs work very good and is 100% compatible with old OS like Windows XP.
Note: You can try with Qt 5.7 and new Qtquick.Controls 2.0 ...performs much better...
https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/
The issue with resizing of QML apps is about updating a window with outdated geometry. The fix would be to sync the updates and resizing.
Since there might be sudden updates from update timer to render scene graph, which can update the window at any time, it causes drawing of the content with outdated geometry.
https://bugreports.qt.io/browse/QTBUG-46074
Either Basic or Extended synchronization should be used to synchronize resizing and the window updates.
Currently Basic sync is used and implemented in Qt, but still need to synchronize the window updates (from timer) with resizing events from Windows Manager.
But, as always, there is a list of issues:
The problem is observed when the window is being resizing too fast.
Since sync events (from WM) should be sent consistently, next after previous:
<= _NET_WM_SYNC_REQUEST is sent from WM, the size is changing now.
_NET_WM_SYNC_REQUEST is received and handled by app.
<= some other events received, like new geometry.
.. update the content, swapBuffers.
=> Sent _NET_WM_SYNC_REQUEST_COUNTER back to WM.
<= _NET_WM_SYNC_REQUEST is sent again from WM, the size is changing.
.. swapBuffers // here is the problem, the update is performed when the window is being changing its geometry.
_NET_WM_SYNC_REQUEST received and handled again.
So the issue happens when (7) swapBuffers appears after _NET_WM_SYNC_REQUEST is sent but not received/processed yet.
And finally conclusion:
Actual resizing of the window is started right after _NET_WM_SYNC_REQUEST is sent by The Window Manager. And not when the app receives it. The window could be even updated at this time, when sync request is sent, but not handled by the app yet. Which will draw the content with outdated geometry.
_NET_WM_FRAME_DRAWN could help to sync between resizing and updates, but also might not be supported (and guess it is not) by The Window Manager.
In other words, either basic or extended synchronization does not help, (at least without _NET_WM_FRAME_DRAWN), because there is no way to know when actual resizing is done.
Extended sync protocol is a try to handle this, but since actual changing of geometry is done without syncing with the client, as I can see, without _NET_WM_FRAME_DRAWN there is always a chance to update the window with outdated geometry.
https://lists.freedesktop.org/archives/xcb/2019-February/011280.html
In my case, i solved this by adding the next flag:
QQuickWindow::setSceneGraphBackend(QSGRendererInterface::Software);
But this will add other rendering problems. Or not.
In golang therecipe/qt this help me :
func main() {
var format = gui.NewQSurfaceFormat()
format.SetVersion(4, 5)
format.SetProfile(gui.QSurfaceFormat__CoreProfile)
format.SetRenderableType(gui.QSurfaceFormat__OpenGL)
format.SetSwapInterval(0)
format.SetDefaultFormat(format)
os.Setenv("QT_SCALE_FACTOR", "1")
ap := widgets.NewQApplication(len(os.Args), os.Args)
ap.SetApplicationName("APP 1.1")
System: Linux debian 10
gpu: Radeon 570
but the animations are faster because not all frames are rendered...

libvlc_media_player_set_hwnd doesn't work with QWidget Handle

I am using Qt4.8 Windows version to develope an application to stream video using libvlc 2.2.1. When I use libvlc_media_player_set_hwnd() to render the video on my QWidget, its rather creating a separate window to display the video.
libvlc_media_player_set_hwnd(m_player, (void*)videoWidget->winId());
I have tried all versions of libvlc and all the examples related to libvlc with Qt. Also followed the steps given in https://wiki.videolan.org/LibVLC_SampleCode_Qt/
But I am not sure if I m missing anything.
It looks like as if libvlc_media_player_set_hwnd() is not able to take the QWidget WinId and creating its own window. However the value of (void*)videoWidget->winId() seems to be a valid one. (I got the value as 0x65).
Please let me know if I am missing anything.
You need to make sure you are configuring your VLC instance correctly first, so that it uses the dummy interface, for example:
/* Load the VLC engine */
std::vector<const char*> options;
options.push_back("--intf=dummy");
return libvlc_new(int(options.size()), options.data());
Also, are you sure you are passing the handle to the correct widget to render on? Also, make sure to set some size on the parent widget, otherwise you may not see anything render at all. Finally, check what media options you are setting to your media player instance, you may be inadvertently telling it to render to generated window.
I've been able to get VLC to work in my own Qt application using the following example as a starting point, even though it is for VLC 1.X:
LibVLC SampleCode Qt - VideoLAN Wiki

Resources