[BUG] UDP messages can be too long, aren't broken up
See original GitHub issueDescribe the bug When utilizing UDP streaming as described in the docs, a resolution, bitrate, etc higher than shown easily cause an OSError: [Errno 90] Message too long. This appears to be because the UDP packets are larger than allowed by the OS, and need to be split up.
To Reproduce Use a resolution and bitrate large enough to create big packets. Example script (must change target ip):
#!/usr/bin/python3
import socket
import time
from picamera2 import Picamera2
from picamera2.encoders import H264Encoder
from picamera2.outputs import FileOutput
picam2 = Picamera2()
video_config = picam2.create_video_configuration({"size": (1640, 1232)})
picam2.configure(video_config)
encoder = H264Encoder(1000000, repeat=True)
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
sock.connect(("10.11.9.112", 1234))
stream = sock.makefile("wb")
picam2.start_recording(encoder, FileOutput(stream))
try:
time.sleep(10000)
finally:
picam2.stop_recording()
Expected behaviour No crashes because of UDP packets that are too big.
Console Output, Screenshots
Traceback (most recent call last):
File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
File "/usr/lib/python3.9/threading.py", line 892, in run
self._target(*self._args, **self._kwargs)
File "/home/pi/.local/lib/python3.9/site-packages/picamera2/encoders/v4l2_encoder.py", line 190, in thread_poll
self.outputframe(b, keyframe, (buf.timestamp.secs * 1000000) + buf.timestamp.usecs)
File "/home/pi/.local/lib/python3.9/site-packages/picamera2/encoders/encoder.py", line 183, in outputframe
out.outputframe(frame, keyframe, timestamp)
File "/home/pi/.local/lib/python3.9/site-packages/picamera2/outputs/fileoutput.py", line 77, in outputframe
self._write(frame, timestamp)
File "/home/pi/.local/lib/python3.9/site-packages/picamera2/outputs/fileoutput.py", line 95, in _write
self._fileoutput.write(frame)
File "/usr/lib/python3.9/socket.py", line 722, in write
return self._sock.send(b)
OSError: [Errno 90] Message too long
Hardware : Raspberry Pi 4, Raspbian Bullseye, IMX219 (Camera v2.1)
Additional context TCP streaming works fine, but is not applicable to our use case where we can’t directly access the device.
Issue Analytics
- State:
- Created a year ago
- Comments:8
Top Results From Across the Web
Why are particular UDP messages always getting dropped ...
There is no formal requirement that the packets dropped are the oldest or the newest being received. It could also be that a...
Read more >Possible bug causing loss of UDP packets
When, either there are more packets or not, the previous packet had not been completely processed by its correspondying handler module (ARP, ...
Read more >UDP Packet Loss | Baeldung on Computer Science
Explore several reasons for packet loss in UDP. ... Congestion in a network can increase the time a packet takes to reach the...
Read more >UDP/TCP/IP Performance Overview
UDP leaves the breaking up of the output to the IP layer. If necessary, IP fragments the output into pieces that comply with...
Read more >How to improve UDP performance when using udp() function ...
However, it is not recommended to send a payload over 512 bytes in a single UDP packet, because smaller packets would most likely...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes I think you’re write it might be tricky to fix in FileOutput. I’m just having a little look into UDP based protocols such as RTP. But will do some more investigation into how they work.
It sounds like RTP might be able to split the payload for us, as well as detecting out of order delivery and packet loss.
Thanks for reporting, will have a look at this