Slot-Funktion in QObject::connect wird nicht aufgerufen

Th69

Der Compiler scheint VideoScreenHelper nicht zu kennen. Fehlt #include "VideoScreenHelper.h"?

Aber hast du mal QMetaObject::invokeMethod(...) statt dem emit ausprobiert?

makopo

VideoScreenHelper.h ist eingebunden. Eigentlich sollte IntelliSense ja die Instanz kennzeichnen, wenn diese nicht integriert ist.

Ich hatte allerdings die Qt Versionen zwischenzeitlich gewechselt. Weil es ein Problem mit Qt-Header-Dateien in Version 5.15.1 und 6.1.2. gab. Könnte es daran liegen?

QMetaObject::invokeMethod(...) habe ich noch nicht ausprobiert. Werde ich mir aber noch anschauen.

makopo

Fehler gefunden. Ich habe in der Hilfsklasse VideoScreen.h inkludiert und in VideoScreen.h ja wiederum die Hilfsklasse.

makopo

Die DrawFrame Methode sieht nun so aus und ich bin mir nicht sicher ob das so richtig ist:

HRESULT VideoScreenHelper::DrawFrame(IDeckLinkVideoFrame* frame) {
	QMetaObject::invokeMethod(this, "FrameChanged", Qt::QueuedConnection, Q_ARG(CComPtr<IDeckLinkVideoFrame>, frame));
	qDebug() << "VideoScreenHelper: emitting FrameChanged.";
	return S_OK;
}

Ich kann nicht prüfen ob das so richtig ist, da ich auf diese Weise einen Folgefehler erhalte, der mit connect aber nichts zu tun hat. Daher meine Frage.

Und nach wie vor erhalte auf der Konsole nach Aufruf des Konstruktors VideoScreen die Meldung das Thread X und Thread Y mit Code 1 beendet wurden.

Th69

Ja, der Code sollte so passen.

Und die Threads können ja auch von der externen Lib kommen (kannst ja im "Threads"-Fenster deiner IDE mal während des Debuggens überprüfen).

makopo

Klappt nach stundenlangem Debuggen leider nicht. Wenn ich mir die Thread-IDs ausgebe, dann sehe ich das der Konstruktor der Klasse VideoScreen und die Funktion DrawFrame (die steht in einer anderen Klasse) unterschiedliche IDs haben.
Zusätzlich habe ich noch eine Klasse die die GUI-Main ist und mit der ich über Signal/Slot die Funktion aufrufe die letztlich das Video startet. In dieser müsste doch der Main-Thread laufen? Und diese läuft auch im gleichen Thread wie der Konstruktor von VideoScreen.
Der Thread von DrawFrame() muss doch im gleichen Thread wie VideoScreen laufen?

//VideoScreen.cpp
VideoScreen::VideoScreen(QWidget* parent) :
	m_previewHelper(nullptr)
{
	//Registering the type name of type CComPtr<IDeckLinkVideoFrame>, requires include<QMetaType>
	//Create and destroy objects of the type dyamically at runtime after registration
	qRegisterMetaType<CComPtr<IDeckLinkVideoFrame>>("CComPtr<IDeckLinkVideoFrame>");

	m_vsThread = new QThread();
	m_drawFrame = new VideoScreenHelper(parent);
	m_drawFrame->moveToThread(m_vsThread);
	//QObject::connect(const QObject *sender, PointerToMemberFunction signal, const QObject *receiver, PointerToMemberFunction method, Qt::ConnectionType type = Qt::AutoConnection)
	QObject::connect(m_drawFrame, &VideoScreenHelper::FrameChanged, this, &VideoScreen::HandleFrame, Qt::QueuedConnection);
	QObject::connect(m_vsThread, &QThread::finished, m_drawFrame, &QObject::deleteLater); //Deletes VideoScreenHelper object
	QObject::connect(m_vsThread, &QThread::finished, m_vsThread, &QObject::deleteLater); //Deletes QThread object
	m_vsThread->start();
	qDebug() << "VideoScreen Ctor: Thread-ID is " << QThread::currentThreadId();
}

//QVideoMeter.cpp
QVideoMeter::QVideoMeter(QWidget* parent)
    : QWidget(parent)
{
    //initializes ControlVideo with a decklink instance
    m_control = std::make_unique<ControlVideo>(m_init->CreateDeckLinkInstance());
    m_videoScreen = new VideoScreen(parent);
    
    ui.setupUi(this);
    //Observer pattern in Qt style. If the start button is released, the video stream starts
    QObject::connect(ui.startBtn, &QPushButton::clicked, this, &QVideoMeter::QStartVideo);
    QObject::connect(ui.stopBtn, &QPushButton::released, this, &QVideoMeter::QStopVideo);

    qDebug() << "QVideoMeter CTOR" << QThread::currentThreadId();
}

Th69

Genau dafür sollte eigentlich dann QueuedConnection sorgen, daß das Signal von einem Thread zu einem anderen gelangt (indem der andere [UI-]Thread diese in seiner Message-Loop verarbeitet) - also VideoScreen::HandleFrame sollte dann im UI-Thread ausgeführt werden (und nicht im gleichen Thread wie VideoScreenHelper::DrawFrame).

Wenn aber immer noch nicht VideoScreen::HandleFrame dabei aufgerufen wird, dann solltest du mal testen, ob es wenigstens vom gleichen Thread (d.h. UI-Thread) aufgerufen werden kann (also das Signal mal per Button o.ä. per emit oder direkt per QMetaObject::invokeMethod aufrufen).

makopo

@Th69

Der Thread vom Slot HandleFrame läuft im gleichen Thread wie die QVideoMeter (GUI-Klasse) und VideoScreen. Nur das Signal aus der Hilfsklasse läuft in einem eignen Thread. Das Vorschaubild in der GUI bleibt aber schwarz.
So wie ich das verstehe, scheint mit dem Threading dann ja alles in Ordnung zu sein.

makopo

Ich denke das ganze Problem beruht nicht auf dem Threading, sondern darauf das bei der Speicherverwaltung irgendetwas schief läuft. Ich nutze jetzt in meinem gesamten Programm raw-Pointer und der Eventloop läuft. Allerdings wird der recht schnell, aber unregelmäßig abgebrochen. Fehlermeldungen sind entweder Critical error detected c0000374 oder 0xC0000005: Zugriffsverletzung beim Ausführen an Position xyz.
Gibt es den Abbruch weil der Speicher vollläuft da die Zeiger nicht freigegeben werden.

Wenn ich COM-Zeiger im Programm benutze, tritt dieses Problem nicht auf. Für diese ist ja aber auch die Release-Funktion implementiert.

makopo

Ich habe den Fehler gefunden. QOpenGLWidget::paintGL() wurde nur bei Änderungen an der GUI aufgerufen (z.B.: resizing). Wenn man paintGL() um die Funktion QWidget::update() ergänzt wird paintGL regelmäßig aufgerufen und das Videobild wird gerendert.
Thema damit erledigt.