4.05 was giving me grey frames every 5 or seconds as well as ~1 second latency.
Just installed the test build (2020-10-07) that @jwalser linked to and I’m not having any issues with grey frames or latency.
1 Like
Hi there,
last weekend I did 1 and a half hour testddives and I think I can confirm that version @jwalser linked to solved the problem of lag and grey freezings during the dive. 4.0.5 and 4.0.8 still have this problems so I stay with this developer version that runs without any issues. Thanks for that!!
Chris
Hi!
Uppgraded to QGC 4.1.2 that seems to solve the problem.
In QGC application settings there now is a listbox setting for chosing the video decoding in QGC.
Using the standard “default” seems to be a mix of using the nVidia card and software decoder, in plain english the video freezing happens sometimes, even if processor load never goes over 45%.
I think there is a mix of software/GPU usage happening in this state.
Using “Force nVidia” gives good video with no freezing, but video mp4 recording is not working.
Sometimes there are a recorded file sized 0kB after quitting QGC
Using “Force DirectX 3D” seems to solve all problems, no freezing and good video recording!!
This seems to work also with a Windows 7 OS Laptop
1 Like
@jwalser , is that test build still available? The link isn’t working. Or have the changes been incorporated into the daily build?
I’m running an RTSP stream, which runs perfectly through VLC. In QGC 4.0.5 and the daily build, when the camera is stationary GPU use is about 20%, as soon as the camera moves, GPU activity drops to 0-1% and the video feed skips/gets blocky/lags etc.
Hi Marcus,
In Jacob’s ‘information about the patch’ link the last update is the PR got closed in December last year because
This seems to match Bo’s message that
ok thanks. I’m still seeing issues in the daily build with GPU activity dropping. Strangely, with some QGC sessions, GPU activity stays high, and the feed is fine, but most times it drops out as soon as the camera moves. It’s not a consistent fault, and I haven’t been able to find what might be causing it. Doesn’t seem to be improved by any of the hardware decoding options.
QGC has been added to the “Graphics Settings” list and set to high performance. And as I said, it works fine with VLC. It is a 4K RTSP feed, CPU runs at appx 65-70%, RAM runs at 25%. I would assume it’s a PC CPU issue, except that when the GPU activity remains high, the feed is excellent with no problems. So it is possible, just for some reason QGC is not always using the GPU
Have you tried using “Force DirectX 3D” in the video decoding section of the daily build, as per Bo’s suggestion above?
Also not sure if these other suggestions could be helpful.
yes, have tried every combo of settings and those suggestions, so its a bit of a mystery
Damn, never fun.
My main thoughts would be some kind of power saving ‘feature’, or just straight up throttling for cool down purposes if the GPU is getting too hot or something.
Have you tested moving the camera while viewing the stream with VLC, and looked at the GPU usage while doing so? I believe VLC does smoothing on dropped/damaged frames, whereas QGC just displays frames as soon as they arrive, and only smooths recorded videos. It’s possible it’s a signal noise or power issue when you move the servo, which VLC could just be hiding the results of.
I’m on a wired connection and this exact behavior has plagued me for awhile but seems to have gotten worse in newer versions. v20 seems to be where it’s most stable. Any ideas?
ETA: Ardusub 4.0.3 and QGC 4.0.5
Hi @Lucas,
I’ve moved your comment here because it’s more appropriate for your issue.
Assuming you’re on Windows please try updating to the latest version of QGC 4.1 - it integrated some video fixes as discussed in this thread. We’re in the process of making 4.1 the main release for everyone, but there have been a couple of issues with Mac integration that have held things back.
I got 4.1.4 working and video seems to be smooth. Thanks!
1 Like