Home        Store        Learn        Blog

Video freezing and grey frames in QGC 4.0.5 when recording

Using video recording in new QGC version gives a lot of frozen frames with a grey image.
This occur on both livestream in QGC and recording. In recording there is no “grey frame effect” but freeze instead.
Processor load is general higher than earlier QGC, 30% without recording, 40-45 with recording.
Effect is intermittent, can run for minutes OK, followed by several in 30 seconds.
Always happens 6 seconds after starting recording.
When the effect occurs QGC processor load typically goes from 40 to 80%,
I thought new video processing should mean lower processor load, not higher.
Using internal Intel graphic card instead of Nvidia card gives same result, both in processor load and frozen frames. Maybe that could be a hint since using nVidia card in my mind should take load of processor?

Trying response via QGC Git. https://github.com/mavlink/qgroundcontrol/issues/8631
Screenshot:

Hi @Boko,

Can you check your processor load by logical cores? It is possible that some of them are maxing out.

Perfect! Thank you.

Also, What are the specs of your topside computer?

Hi @williangalvani !
Yes, processors are hitting close to 100%
Strange thing is that this did not happen in QGC 3.5.2
Tell if I can do more to narrow this down.

Spec of computer and load curve:

If you right click the CPU Load chart, you should be able to show the load for individual cores, I expect at least one will be at 100%.

I’m not quite sure what the cause is for the higher processor load, though.

Hi!
Yes, there are hits to 100%
Bo

@Boko I was having the same issue with my topside computer on 4.0.5. Try the 4.0.8 release.

That worked for me. My GPU driver (AMD) was also horribly out of date, so I updated that. I’m down to a 25% processor load and no more frozen grey frames. I may have just been a combination of things out of date. I still need to go out into the field and test.

Thanks for tip!
Installed 4.0.8, works better, still frozen frames, but more seldom.
Graphics already latest drivers.
Tweeked openGL settings in Nvidia settings, got even better.
Still froxen frames during recording, but seldom, almost usable…
Processor load around 50% average while recording, seems double of Yours.
Bo

If you have a dedicated GPU (not the Intel one), you can switch it over to run on that using these steps: https://www.addictivetips.com/windows-tips/force-app-to-use-dedicated-gpu-windows/

It took the load off my CPU and Intel UHD GPU.

1 Like

Thanks for tip, but I already use the Nvidia graphics by choosing that in both graphi9cs setup and OpenGL setup.
Thats why I wonder why the CPU load on 4.x QGC is more then 3.5.x

I had the exactly the same issue with my Lenovo P50 using the ROV. Changing the GPU in Windows as Kevin described did not help a lot, still the same behavior. What really helped is changing the GPU in the BIOS directly to use only the Nvidia GPU. Since then, no grey frames no video interruption while recording. Well not sure if it helps in your case but for me that was the solution.

Thanks for tip!
Ufortunatley BIOS do not have settings or choice of graphics.
Reason for that is the switching between graphics is done by software/windows.
All graphics passes the onboard Intel, even if its processed by Nvidia GPU.
Checking gamers forums I’ve seen similar problems due to bugs in games related to handling of dual graphics.

SInce this worked on QGC 3.x but not in the 64 bit QGC 4.x I guess there is an issue in graphics handling in new QGC.

We have also noticed significant video lag in QGC 4.0.8 (latest version), we’ve not tested 4.0.5. It is significantly worse when using the Ping360 at the same time. We have reverted to using the beta build linked from the last beta forum post - https://ci.appveyor.com/api/buildjobs/854u10xslgj1ynf5/artifacts/QGroundControl-installer.exe
This build does not have the issues. It doesn’t seem to matter whether we have the new ‘Low latency’ mode on or off in 4.0.8. Obviously something has changed which is causing the increase in latency. It is basically impossible to pilot due to lag of 2 seconds.
This needs to be resolved going forward or we are stuck with the older builds.

QGroundControl is using Software decoding of h.264 which is crazy. Most hardware in the last few years, down to the cheapest cell phones, have hardware decoding abilities.

This issue is driving me nuts. I will spend some time this weekend trying to enable hardware decoding, but it may a long road. If any of the BlueRobotics guys or someone else with experience can give me a QGroundControl dev primer over Skype I would appreciate it.

The following guide deals with hardware decoding:
https://gstreamer.freedesktop.org/documentation/tutorials/playback/hardware-accelerated-video-decoding.html?gi-language=c

I suspect that overlay will be an issue in recording:
https://gstreamer.freedesktop.org/documentation/additional/design/subtitle-overlays.html?gi-language=c

@gwa-gwa Nice if your idea ends in a solution!
Regarding overlay at recording, i don´t see the problem.
Today that is done with subtitles and .ass files.

Though it might be a problem with the live overlay in QGC of depth, heading etc?
Bo

Can’t help but chuckle every time I see a .ass file :joy:. Getting the dev environment set up now. Will keep you posted.

Hi, we are tracking the issue here on github, this might be a better place for you to coordinate:

I am testing/trying to fix this problem myself presently. If you want to talk about it by voice, you can arrange a meeting with me by private message.

There is no overlay in recording, as it would require re-encoding the video.