Hi @john6,
The H264 encoding is done on the camera module, so the bitrate is determined by the camera, and unaffected by the streaming pipeline.
I’ve summarised your Wireshark results below, along with my own set of similar results.
Your results:
| Frame Size | FPS | Measured Bitrate | Avg. Packet Size |
|---|---|---|---|
| 1280 x 720 | 30 | 5.7 Mbps | 10.68 kbits |
| 1280 x 720 | 15 | 11.5 Mbps | 11.11 kbits |
| 320 x 240 | 30 | 6.0 Mbps | 10.77 kbits |
My results:
Frame Size | FPS | Measured Bitrate | Avg. Packet Size
-|-|-|-|-
1920x1080 | 30 | 11 Mbps | 10.68 kbits
1920x1080 | 15 | 11 Mbps | 11.08 kbits
1280x720 | 30 | 11 Mbps | 10.71 kbits
1280x720 | 15 | 11 Mbps | 11.09 kbits
800x600 | 30 |11 Mbps | 10.79 kbits
640x360 | 15 | 9.9 Mbps | 11.04 kbits
320x240 | 30 | 7.0 Mbps | 10.25 kbits
320x240 | 15 | 3.5 Mbps | 10.22 kbits
It looks like the average packet size is quite consistent, regardless of camera settings, which I expect is set by gstreamer when it converts the H264-encoded stream into RTP/UDP packets.
There’s more to quality than just framerate and frame size (which is discussed somewhat in the “camera” section in this post). It seems like the bitrate is set to a constant ~11 Mbps, but when the video frames are small and/or infrequent enough then there’s presumably no more quality that can be gained by sending extra bits, so it reduces the bitrate.
Unfortunately
and the implemented v4l2 controls don’t include bitrate specification, so finer-grained control of the bitrate isn’t possible.
On a separate note, I suspect the “doubling” you saw may in fact be an error of the settings in your first screenshot not being the ones that were actually applied for the Wireshark window in that screenshot - you could check that quite easily by setting 1280x720@30fps and re-testing with Wireshark 