Comet5G: displaying a static text image can take~2.5Mbit/sec?

KVM
1

I've got my RM10RC connected to a Linux PC that's in headless, text-only mode (VT, not KDE), 1920x1200@60Hz. I'm looking at the stats on the bottom of the glkvm.com page and that static, text-only image easily takes > 1MBit/sec (and as high as 5MBit/sec!) in any of the selectable video modes even with no new text on the screen.

Isn't there any kind of RLE(?) compression being used? I would think a screen like that should use a few Kbits/sec at most. I was hoping to use a SIM with a limited amount of data as the 5G backup, but I could easily see blowing thru a few GBytes in just an hour :frowning_face_with_open_mouth:

2

What firmware are you running on said device?

3

You should use smart mode; the bandwidth usage will be very low when displaying static images.

4

The latest, V1.9.1 release1

5

I've tried that and all the various options and combinations ... look at this screenshot ... what's on the screen is 240x67 plain VT text that's not moving- why does that need ~8mbit/sec of bandwidth?

Screenshot_20260728_214223
Screenshot_20260728_214223503×853 37.4 KB

6

image
image797×1382 57.9 KB

This is very strange. My bandwidth usage is very low. Please try using regular WebRTC instead of WebRTC FEC.

7

imageAlternatively, you can try normal mode and select a lower quality.

8

~6Mbit/sec :confused:

If someone from GLi wants to get into my Comet, or needs some debugging info, let me know please.

9

Is your controlled computer equipped with a VGA or HDMI interface?

10

Again, I've tried every combination ... it's never lower than ~3Mbit/sec on a completely static image.

11

HDMI.

If this somehow matters, it's an AMD Ryzen-based NUC: https://www.microcenter.com/product/708606/gmktec-nucbox-m8-mini-pc

12

ustreamer-dump --sink kvmd::ustreamer::h264 --output - | ffmpeg -use_wallclock_as_timestamps 1 -i pipe: -c:v copy /userdata/media/my_video.mp4

Please run this command record a video and send it to us. We will analyze your video to see what was happening. It will save a video record in virtual media named myvideo.mp4.

14

OK, I have the output file (had to actually start a session to get the video to start, I deleted my previous reply). There's nothing sensitive in it, but it's ~71Mbytes; how should I send it to you?

What's interesting is when I view it in vlc, it appears to ... pulse(?) once per second- maybe this is the reason for the high bitrate?

15

maybe google drive?

16

I have a Dropbox link ... send me a PM

17

I see what your problem is. Your video shows a strong breathing effect. Essentially, this chip is designed for cameras. It is not good at handling such high-definition computer screens. The breathing effect causes its bitrate to never decrease.

This type of issue usually requires support from the chip manufacturer, and there is a very high probability that the answer is no.

18

You can give this a try, but I can't guarantee it will definitely work.

touch /tmp/smart && killall ustreamer
19

... um, whaaaaa? Isn't the entire point of the Comet (5G, et al.) to "handle such high-definition computer screens"?! I'm even using 1080p (vs. one of the 4K options your firmware offers even) to keep the bitrate down :frowning_face_with_open_mouth:

What am I missing here?

20

No change (as you'd expected)

21

OK, so I'd rebooted it and now get this:

Screenshot_20260731_185935
Screenshot_20260731_185935435×586 12.4 KB

... so now I wonder if it's some sort of pixel-synchronization error? :man_shrugging:t4:

At least now I know my Comet is capable of doing static images at low bitrates ... now I just need to see if I can figure out what causes it to go apesh-t high-bitrate