starred/pikvm-pikvm

Fork 0

mirror of https://github.com/pikvm/pikvm.git synced 2026-03-02 18:16:56 -05:00

Increasing Max H.264 Overridable Max and Default GOP to Hardware Limit (if any) #776

New issue

Closed

opened 2026-02-20 14:06:02 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 14:06:02 -05:00

Owner

Originally created by @dyehya on GitHub (Nov 17, 2023).

Originally assigned to: @mdevaev on GitHub.

Is your feature request related to a problem? Please describe.
By default, the max value for H.264 GOP is 60. This appears to be an overridable setting and can be reduced or matched from 60 or lower but anything above that results in an error. I am not aware of any hardware or software limitations increasing the overridable values would have.

I have access to a few low bandwidth fiber networks (1.5Mbps, 5Mbps, 50Mbps) that have limited bandwidth but no packet loss (usually) as well as some home cable connections that have few dropped packets. Having a higher GOP will allow for more efficient transmission without sacrificing quality at all and is easy to adjust if network conditions change assuming I have a much, much higher upper limit.

To Reproduce
Steps to reproduce the behavior, like:

SSH as root
rw
nano /etc/kvmd/override.yaml
Put in:
kvmd: streamer: h264_gop: max: 240
Save and exit
ro
systemctl restart kvmd
500 Error

Describe the solution you'd like
Overridable Max and overridable default GOP above 60 will work and not result in errors. 1800 would be approximately 1 new full frame a minute (roughly 30 fps*60 seconds) but even a value of 240 or 300 would be great.

I am not saying that the "default max" has to be above 60 or 300 or whatever. I leave that to you all. If the current settings are preferred as the base configuration, then just allowing it to be overridable beyond the "default max" not being the upper bound like it currently is. There could be a comment in the YAML saying what the "true" upper limit is (or in the documentation).

PiKVM info:
PiKVM v4 Lite

KVMD version: pacman -Q | grep kvmd

kvmd 3.274-1
kvmd-fan 0.26-1
kvmd-oled 0.25-1
kvmd-platform-v4mini-hdmi-rpi4 3.274-1
kvmd-webterm 0.44-1

uStreamer version: pacman -Q | grep ustreamer
ustreamer 5.45-1
Linux kernel: uname -a
`Linux pikvm 6.1.61-1-rpi-ARCH #1 SMP Fri Nov 3 20:48:52 MSK 2023 armv7l GNU/Linux

Additional context
I did verify YAML syntax by lowering it below 60 and it worked as expected.
Error as shown in journalctl -fu kvmd: ConfigError: Invalid value 240 for key 'kvmd/streamer/h264_gop/max': The argument '240' must be stream H264 GOP and lesser or equal then 60

Originally created by @dyehya on GitHub (Nov 17, 2023). Originally assigned to: @mdevaev on GitHub. **Is your feature request related to a problem? Please describe.** By default, the max value for H.264 GOP is 60. This appears to be an overridable setting and can be reduced or matched from 60 or lower but anything above that results in an error. I am not aware of any hardware or software limitations increasing the overridable values would have. I have access to a few low bandwidth fiber networks (1.5Mbps, 5Mbps, 50Mbps) that have limited bandwidth but no packet loss (usually) as well as some home cable connections that have few dropped packets. Having a higher GOP will allow for more efficient transmission without sacrificing quality at all and is easy to adjust if network conditions change assuming I have a much, much higher upper limit. **To Reproduce** Steps to reproduce the behavior, like: 1. SSH as root 2. rw 3. nano /etc/kvmd/override.yaml 4. Put in: `kvmd: streamer: h264_gop: max: 240 ` 5. Save and exit 6. ro 7. systemctl restart kvmd 8. 500 Error **Describe the solution you'd like** Overridable Max and overridable default GOP above 60 will work and not result in errors. 1800 would be approximately 1 new full frame a minute (roughly 30 fps*60 seconds) but even a value of 240 or 300 would be great. I am not saying that the "default max" has to be above 60 or 300 or whatever. I leave that to you all. If the current settings are preferred as the base configuration, then just allowing it to be overridable beyond the "default max" not being the upper bound like it currently is. There could be a comment in the YAML saying what the "true" upper limit is (or in the documentation). **PiKVM info:** `PiKVM v4 Lite` - KVMD version: `pacman -Q | grep kvmd` ``` kvmd 3.274-1 kvmd-fan 0.26-1 kvmd-oled 0.25-1 kvmd-platform-v4mini-hdmi-rpi4 3.274-1 kvmd-webterm 0.44-1 ``` - uStreamer version: `pacman -Q | grep ustreamer` `ustreamer 5.45-1` - Linux kernel: `uname -a` `Linux pikvm 6.1.61-1-rpi-ARCH #1 SMP Fri Nov 3 20:48:52 MSK 2023 armv7l GNU/Linux **Additional context** I did verify YAML syntax by lowering it below 60 and it worked as expected. Error as shown in journalctl -fu kvmd: ConfigError: Invalid value 240 for key 'kvmd/streamer/h264_gop/max': The argument '240' must be stream H264 GOP and lesser or equal then 60

deekerman

2026-02-20 14:06:02 -05:00

closed this issue
added the
resolution:fixed

type:question
labels

deekerman commented

2026-02-20 14:06:04 -05:00

Author

Owner

@mdevaev commented on GitHub (Nov 17, 2023):

Hello. Try zero gop, it will reduce latency and will make a gop-on-demand. This should work well on your network.

@mdevaev commented on GitHub (Nov 17, 2023): Hello. Try zero gop, it will reduce latency and will make a gop-on-demand. This should work well on your network.

deekerman commented

2026-02-20 14:06:05 -05:00

Author

Owner

@dyehya commented on GitHub (Nov 17, 2023):

Hi @mdevaev First you are awesome, thank you for all you do. Second, I tried 0 and it was definitely much lower bandwidth as compared to 60, but I am not clear on what you mean by "make a gop-on-demand". Is the kvmd web client requesting a GOP if frame loss is occuring, is it just deciding based on the number of changes between frames, it will decide whether to do a keyframe (full frame) or an i-frame?

I thought (maybe incorrectly) that being able to set an arbitrarily high number would result in it not attempting to do more keyframes between the GOP interval unless the size of the keyframe would be smaller than the i-frame or just always do i-frames but not an expert here.

However, I was thinking being able to force a keyframe interval based on observed video artifacts during use, so if there was a small amount of loss or more moderate or severe, I could have the GOP go between 0,1800+ down to 500, 250, 60,30, etc. with the slider depending on the content on the screen and what is happening, having a larger range is helpful since @1080P it is about 30 frames per second so every 30 GOP is about 1 second so limiting full frames to 1 minute or more may be fine when watching a progress bar (or probably 0 setting). 1 full frame every 10 seconds should be more than enough for word doc editing or mostly static screens, maybe even higher like 20-30 seconds even with frame/packet loss. Anyway, that was my thoughts for the request. For the very low latency low bandwidth, 0 may be the equivalent of infinity but I tried to read the encoder code and wasn't sure how it was actually deciding to use it other than seeing it get passed around and into the encoder.

Thanks.

@dyehya commented on GitHub (Nov 17, 2023): Hi @mdevaev First you are awesome, thank you for all you do. Second, I tried 0 and it was definitely much lower bandwidth as compared to 60, but I am not clear on what you mean by "make a gop-on-demand". Is the kvmd web client requesting a GOP if frame loss is occuring, is it just deciding based on the number of changes between frames, it will decide whether to do a keyframe (full frame) or an i-frame? I thought (maybe incorrectly) that being able to set an arbitrarily high number would result in it not attempting to do more keyframes between the GOP interval unless the size of the keyframe would be smaller than the i-frame or just always do i-frames but not an expert here. However, I was thinking being able to force a keyframe interval based on observed video artifacts during use, so if there was a small amount of loss or more moderate or severe, I could have the GOP go between 0,1800+ down to 500, 250, 60,30, etc. with the slider depending on the content on the screen and what is happening, having a larger range is helpful since @1080P it is about 30 frames per second so every 30 GOP is about 1 second so limiting full frames to 1 minute or more may be fine when watching a progress bar (or probably 0 setting). 1 full frame every 10 seconds should be more than enough for word doc editing or mostly static screens, maybe even higher like 20-30 seconds even with frame/packet loss. Anyway, that was my thoughts for the request. For the very low latency low bandwidth, 0 may be the equivalent of infinity but I tried to read the encoder code and wasn't sure how it was actually deciding to use it other than seeing it get passed around and into the encoder. Thanks.

deekerman commented

2026-02-20 14:06:05 -05:00

Author

Owner

@mdevaev commented on GitHub (Nov 17, 2023):

Is the kvmd web client requesting a GOP if frame loss is occuring, is it just deciding based on the number of changes between frames, it will decide whether to do a keyframe (full frame) or an i-frame?

WebRTC in the browser requests a keyframe if it detects irreparable signal loss, or at the first handshake. In any case, it works very well, and I'm going to make 0 the default value in one of the future releases.

I thought (maybe incorrectly) that being able to set an arbitrarily high number would result in it not attempting to do more keyframes between the GOP interval unless the size of the keyframe would be smaller than the i-frame or just always do i-frames but not an expert here.

As far as I remember, keyframes are always generated at the GOP interval, even if the I-frames are too large. The hardware is pretty stupid in this way and just follows the configuration.

the rest part

If your video stream only occasionally suffers from frame loss, then 0 will solve the problem using automation. If the losses are frequent enough, it is better to send a frame every 60 frames. In any case, these are two boundary values that really make sense. I've been experimenting with it all.

@mdevaev commented on GitHub (Nov 17, 2023): > Is the kvmd web client requesting a GOP if frame loss is occuring, is it just deciding based on the number of changes between frames, it will decide whether to do a keyframe (full frame) or an i-frame? WebRTC in the browser requests a keyframe if it detects irreparable signal loss, or at the first handshake. In any case, it works very well, and I'm going to make 0 the default value in one of the future releases. > I thought (maybe incorrectly) that being able to set an arbitrarily high number would result in it not attempting to do more keyframes between the GOP interval unless the size of the keyframe would be smaller than the i-frame or just always do i-frames but not an expert here. As far as I remember, keyframes are always generated at the GOP interval, even if the I-frames are too large. The hardware is pretty stupid in this way and just follows the configuration. > *the rest part* If your video stream only occasionally suffers from frame loss, then 0 will solve the problem using automation. If the losses are frequent enough, it is better to send a frame every 60 frames. In any case, these are two boundary values that really make sense. I've been experimenting with it all.

deekerman commented

2026-02-20 14:06:05 -05:00

Author

Owner

@dyehya commented on GitHub (Nov 18, 2023):

Thanks for taking the time to explain. I defer to your expertise and will use 0 exclusively. Should work based on what you said.

@dyehya commented on GitHub (Nov 18, 2023): Thanks for taking the time to explain. I defer to your expertise and will use 0 exclusively. Should work based on what you said.

deekerman commented

2026-02-20 14:06:06 -05:00

Author

Owner

@dyehya commented on GitHub (Nov 18, 2023):

Closing based on your feedback.

@dyehya commented on GitHub (Nov 18, 2023): Closing based on your feedback.

deekerman commented

2026-02-20 14:06:06 -05:00

Author

Owner

@mdevaev commented on GitHub (Nov 18, 2023):