在開發音視頻播放器時，多線程設計是不可避免的挑戰。音頻和視頻的解碼、播放需要高效運行，同時還要與主線程或其他線程同步，例如通過信號通知播放進度。本文基于一個實際案例，分析了兩種線程設計在死循環和信號槽使用中的表現，探討其原因，并給出選擇建議。
問題表現
我在實現音頻播放線程時，遇到了一個問題：主線程通過 QMetaObject::invokeMethod 調用 terminateDecode 無法終止音頻線程，而直接調用 m_audioThread->terminateDecode() 卻能穩定生效。后來，我將視頻解碼線程改為 QObject + QThread + std::thread 的設計后，invokeMethod 開始生效。這讓我疑惑：為什么死循環會影響信號槽？如何選擇合適的設計？
具體表現如下：
- 音頻線程（AudioPlayerThread）：
- 使用 QThread 子類，重寫 run() 為死循環。
- 主線程調用 QMetaObject::invokeMethod(m_audioThread, "terminateDecode", Qt::QueuedConnection) 無效。
- 直接調用 m_audioThread->terminateDecode() 生效。
- 視頻線程（m_videoWorker）：
- 使用 QObject 移入 QThread，解碼死循環在 std::thread 中。
- QMetaObject::invokeMethod(m_videoWorker, "terminateDecode", Qt::QueuedConnection) 生效。
此外，音頻線程需要發送 avClockUpdated 信號與視頻同步，這在死循環中似乎不受影響。問題出在哪里？
原因分析
問題的根源在于 Qt 的信號槽機制與線程設計的關系，特別是事件循環的作用。
1. 信號發送（emit）不受死循環影響
- 機制：在 Qt 中，emit 一個信號會根據連接類型（Qt::DirectConnection 或 Qt::QueuedConnection）直接調用槽函數或將信號放入目標線程的事件隊列。emit 本身是線程安全的，不依賴事件循環。
- 音頻線程的表現：
emit avClockUpdated(current_pts);
- 在 AudioPlayerThread 的死循環中，只要線程執行到 emit，信號就會發出，通知視頻線程或其他組件。死循環不會阻止信號發送。
2. 信號接收需要事件循環
- 機制：當使用 Qt::QueuedConnection 調用槽函數（如 terminateDecode），Qt 會將調用請求放入目標線程的事件隊列，等待事件循環處理。如果線程沒有事件循環，隊列中的信號無法被執行。
- 音頻線程的問題：
- run() 是一個 while (true) 死循環：
void AudioPlayerThread::run() {while (true) {// 等待文件和播放邏輯}
}?
-
- 沒有調用 exec()，事件循環未啟動。
- QMetaObject::invokeMethod 的調用被排隊但無法處理，因此無效。
- 直接調用的原因：
- m_audioThread->terminateDecode() 是同步調用，不依賴事件循環，直接修改 m_stopRequested 并喚醒條件變量，線程得以退出。
3. 視頻線程的改進
- 設計：
- m_videoWorker 是 QObject，通過 moveToThread 移入 QThread。
- QThread 默認運行事件循環（exec()）。
- 解碼死循環在 std::thread 中：
class VideoWorker : public QObject { public:VideoWorker() {m_decodeThread = std::thread([this] { decodeLoop(); });} public slots:void terminateDecode() { m_stopRequested = true; } private:void decodeLoop() { while (!m_stopRequested) { /* 解碼 */ } }std::thread m_decodeThread;std::atomic<bool> m_stopRequested{false}; };
? - 結果：
- QThread 的事件循環處理 invokeMethod，觸發 terminateDecode。
- 死循環在 std::thread 中，不干擾事件循環。
-
4. 音視頻同步的需求
- 音頻線程發出 avClockUpdated 信號，視頻線程接收以同步。
- 如果視頻需要控制音頻（例如暫停），音頻線程也需要接收信號。死循環設計在這方面受限。
-
設計選擇
基于以上分析，我對比了兩種設計：
設計 1：AudioPlayerThread（QThread 死循環）
- 特點：
- 重寫 run() 為死循環，使用條件變量同步。
- 通過直接調用控制線程。
- 優點：
- 高效：無事件循環開銷，適合音頻實時性。
- 簡單：邏輯集中，易于實現。
- 缺點：
- 無法接收信號：需手動檢查狀態。
- 擴展性差：復雜控制需額外同步。
- 適用場景：單一任務，實時性要求高。
-
設計 2：m_videoWorker（QObject + QThread + std::thread）
- 特點：
- QThread 運行事件循環，std::thread 執行死循環。
- 通過信號槽控制。
-
如何選擇？
- 音頻實時性優先：選擇設計 1，優化終止邏輯（例如在內層檢查 m_stopRequested）。
- 音視頻同步和控制：選擇設計 2，支持雙向信號通信。
- 我的需求：音頻需要發送 avClockUpdated 與視頻同步，可能還需要接收控制信號。設計 2 更合適。
-
優化建議
對于音視頻同步，我推薦設計 2：
- 優點：
- 支持信號槽：發送和接收信號都方便。
- 擴展性強：適合音視頻同步和復雜交互。
- 缺點：
- 復雜性增加：多線程管理。
- 輕微開銷：事件循環和線程切換。
- 適用場景：需要雙向通信或 UI 交互。
?
// 音頻工作類
class AudioWorker : public QObject {Q_OBJECT
public:AudioWorker() { m_audioThread = std::thread([this] { audioLoop(); }); }~AudioWorker() { m_stopRequested = true; if (m_audioThread.joinable()) m_audioThread.join(); }
public slots:void terminateDecode() { m_stopRequested = true; }
signals:void avClockUpdated(qint64 pts); // 發送音頻時間戳
private:void audioLoop() {while (!m_stopRequested) {qint64 pts = /* 計算音頻時間戳，例如 av_rescale_q */;emit avClockUpdated(pts); // 通知視頻線程// 音頻解碼和播放邏輯std::this_thread::sleep_for(std::chrono::milliseconds(10)); // 模擬播放}}std::thread m_audioThread;std::atomic<bool> m_stopRequested{false};
};// 視頻工作類
class VideoWorker : public QObject {Q_OBJECT
public:VideoWorker() { m_videoThread = std::thread([this] { videoLoop(); }); }~VideoWorker() { m_stopRequested = true; if (m_videoThread.joinable()) m_videoThread.join(); }
public slots:void terminateDecode() { m_stopRequested = true; }void syncWithAudio(qint64 audioPts) { m_currentAudioPts = audioPts; // 根據音頻時間戳調整視頻播放}
private:void videoLoop() {while (!m_stopRequested) {qint64 videoPts = /* 計算視頻時間戳 */;if (m_currentAudioPts > 0 && std::abs(videoPts - m_currentAudioPts) > 100) {// 如果視頻與音頻時間差過大，調整播放（例如跳幀或等待）}// 視頻解碼和渲染邏輯std::this_thread::sleep_for(std::chrono::milliseconds(40)); // 模擬播放}}std::thread m_videoThread;std::atomic<bool> m_stopRequested{false};std::atomic<qint64> m_currentAudioPts{0};
};// 主線程中的管理類
class MainClass : public QObject {Q_OBJECT
public:void startAV() {// 初始化音頻線程m_audioThread = new QThread();m_audioWorker = new AudioWorker();m_audioWorker->moveToThread(m_audioThread);// 初始化視頻線程m_videoThread = new QThread();m_videoWorker = new VideoWorker();m_videoWorker->moveToThread(m_videoThread);// 連接音頻信號到視頻槽，實現同步connect(m_audioWorker, &AudioWorker::avClockUpdated, m_videoWorker, &VideoWorker::syncWithAudio, Qt::QueuedConnection);// 啟動線程m_audioThread->start();m_videoThread->start();}void stopAV() {if (m_audioThread) {QMetaObject::invokeMethod(m_audioWorker, "terminateDecode", Qt::QueuedConnection);m_audioThread->quit();m_audioThread->wait();delete m_audioThread;delete m_audioWorker;}if (m_videoThread) {QMetaObject::invokeMethod(m_videoWorker, "terminateDecode", Qt::QueuedConnection);m_videoThread->quit();m_videoThread->wait();delete m_videoThread;delete m_videoWorker;}}private:QThread* m_audioThread = nullptr;AudioWorker* m_audioWorker = nullptr;QThread* m_videoThread = nullptr;VideoWorker* m_videoWorker = nullptr;
};?
總結
- 信號發送：死循環不影響 emit，音頻可以通知視頻。
- 信號接收：死循環無事件循環，需用設計 2 或狀態檢查解決。
- 選擇依據：實時性選設計 1，同步和擴展性選設計 2。
通過將死循環移到 std::thread，結合 QThread 的事件循環，我實現了音頻和視頻的高效同步。這種設計既滿足了實時性，又提供了靈活性，是音視頻播放器的推薦方案。
?
)
、WSL、SSL/TSL)
