geminixdev

> 1. found out that the audio output should not be on gui thread, since if there is a hang in GUI, it crackles too, and audio impacts to GUI....

"Crackling" might not describe the audio correctly, it is more "stuttering".

Quick and dirty test, instead of QFuture with processEvents() now QThread with QEventloop, no more Waitconditions, no loop, setting audio directly when changed: it works fine, plays the audio. Not...

[qthread-audio.zip](https://github.com/valbok/QtAVPlayer/files/14511418/qthread-audio.zip) Yes, please see the attached zip. When you use the Qthread approach directly from a main method, then apparently a `processEvents()` call is needed, but it can be in...

> Also QThread itself already contains QEventLoop, looks another one is not needed. > Thanks for pointing me to this, I did not realize that. Now I can eliminate some...

> also fyi, if you don't use direct connection for QThread::started, it looks like you will create QAudioOutput on decoding thread, from the player, and not in QThread you expected....

Just to confirm: the code which I use in my App, based on what I proposed here above, is meanwhile running in hundreds of installations at users flawlessly. So in...

Just to make that clear: the slowness is not visible when testing with arm64-v8a devices. Unfortunately all Android Boxes are armeabi-v7a, and there it makes them unusable for anything better...

> > Also when you convert QAVVideoFrame to QVideoFrame there is hardcoded converting https://github.com/valbok/QtAVPlayer/blob/master/src/QtAVPlayer/qavvideoframe.cpp#L314 > > which downloads data from GPU, since there is no support for mediacodec in QRHI...

> Can you confirm that qml rendering is lagging? Using VideoOutput? Can you also disable sending video frames to VideoOutput, but received from the player and confirm that CPU is...