paintEvent() cease to function?
-
Background:
I'm using libvlc to create an application that displays video and visualize audio signal, I have got the video display working for quite a while now and I recently starting to code audio visualization. I have also got it working but I start running into a problem where one or more widget (video/audio display or even other UI widgets) stops updating after letting it run for a while, the widgets are still "working" but the paintEvent() of them never gets called again. When I disable audio visualization and only display video, it never freezes.I'm unsure if video/audio is causing the issue, so I'll post both code here. The basic idea is I have a callback function for both video/audio where I get raw data from libvlc, I'm pretty sure the callback should be running in a thread controlled by libvlc.
Video Code:
The callback function for libvlc, I use this to store the image of the frame in a context structstatic void unlock(void *opaque, void *picture, void *const *planes) { struct context *ctx = (context *)opaque; ctx->m_frame = QImage((unsigned char *)*planes, VIDEO_WIDTH, VIDEO_HEIGHT, QImage::Format_ARGB32); ctx->m_mutex.unlock(); }
The video code is a bit sloppy but I do plan to refactor it to make it work similarly to audio. When I start the camera, I start a timer with a fix interval so the timeout will be called roughly in 60fps:
m_timer.start(16); connect(&m_timer, &QTimer::timeout, this, &VLCWrapper::timeout);
Then at the timeout function, I'll grab the image stored and paint it to my label widget
void VLCWrapper::timeout() { ctx.m_mutex.lock(); QImage frame = ctx.m_frame; ctx.m_mutex.unlock(); m_videoWidget->setPixmap(QPixmap::fromImage(frame.scaled(640, 360))); }
Audio Code:
Callback function, this function is called about every 20msstatic void cbAudioPlay(void* p_audio_data, const void *samples, unsigned int count, int64_t pts) { struct contextAudio *ctx = (contextAudio *)p_audio_data; ctx->m_manager->pushAudioData(samples, count, pts); }
The audio manager will also push the data to the display widget, right now this is still running in libvlc thread. When I finish pushing the data, I use QWidget::update() to allow paintEvent() to be called
void AudioManager::pushAudioData(const void *samples, unsigned int count, int64_t pts) { size_t sampleSize = count * m_audioFormat.bytesPerFrame(); m_displayWidget->sendData_rawWave(m_audioFormat, (const char*)samples, sampleSize); } void AudioDisplayWidget::sendData_rawWave(const QAudioFormat &format, const char* samples, size_t sampleSize) { m_displayMutex.lock(); { // caching data for display... } m_displayMutex.unlock(); QWidget::update(); }
The paint event
void AudioDisplayWidget::paintEvent(QPaintEvent* event) { QWidget::paintEvent(event); m_displayMutex.lock(); { paintImage(); } m_displayMutex.unlock(); }
The Question:
After I run the program for a while, sometimes the audio display will freeze, sometimes video display, sometimes the entire program freezes, but I can still press the button to stop the media capture. The freeze seems to only happen when I run both audio and video display together. So the question is what would cause the paintEvent() to stop working? -
I notice when my audio/video widget freezes, if I resize my window, the widget updates again but only if I keep resizing. So my QWidget::update() call doesn't seems to work anymore?
I also tried to remove all data manipulation and only do below, but again it can also freezes :(
void AudioDisplayWidget::sendData_rawWave(const QAudioFormat &format, const char* samples, size_t sampleSize) { QWidget::update(); } void AudioDisplayWidget::paintEvent(QPaintEvent* event) { QWidget::paintEvent(event); }
-
So I might have found the issue, because I'm calling QWidget::update() on the libvlc thread, now I've changed the code to:
connect(this, &drawSignal, this, &drawSlot) AudioManager::callback() { emit drawSignal(); } AudioManager::drawSlot() { QWidget::update(); }
And it has not froze ever since, so I guess I should avoid calling any Qt class functions on other threads?
-
@BrianL said in paintEvent() cease to function?:
so I guess I should avoid calling any Qt class functions on other threads
Not in general. What is not supported is to change UI stuff from other threads than GUI thread. And that was exactly what you was doing.