UDP Examples not working

[Torxed]

Every other example works, rtsp has huge delays and tcp implementation is a bit sketchy (SO_REUSEADDR does not appear to be set, and if the "client" disconnects from the camera everything breaks and you'll have to fiddle with finding the pids of the background processes etc)

So I thought I'd give UDP a go, to get some performance out of the network and skipping VLC, as VLC creates some severe bottlenecks on the hardware.

Using for instance:

libcamera-vid -t 0 --inline -o udp://target-ip.lan:8554

And then on the target machine doing:

vlc udp://@:8554 :demux=h264

It produces nothing. I've tried with multicast addresses too.
I don't know why, but libcamera-vid does simply not want to produce the expected stream.

I can clearly see the traffic coming from the pi and being received on the target machine using tcpdump and wireshark.
The firewalls are turned off, VLC sometimes picks up that there was something on the port, but then stops the stream attempt (probably a frame misinterpreted).

So I don't know what information to give here, or where something goes wrong.
But the UDP implementation appears broken, and rtsp creates way to much delay/latency/frame glitches.

Model: Raspberry Pi 4 Model B Rev 1.1
CPU: ARMv7 Processor rev 3 (v7l)

[lurch]

ping @davidplowman and @naushir

However this sounds like it might be a question for the https://forums.raspberrypi.com/ than an issue with the https://www.raspberrypi.com/documentation/ ? 🤷

[naushir]

I've noticed this as well recently. VLC just does not seem to work correctly. ffplay on the other hand seems fine. I wonder if we should only include the ffplay command line in the examples?

[aallan]

It would be good to update these examples as well, https://www.raspberrypi.com/documentation/computers/os.html#playing-audio-and-video, now omxplayer isn't included. But that depends on whether we're recommending VLC or ffplay I guess?

[Torxed]

I've noticed this as well recently. VLC just does not seem to work correctly. ffplay on the other hand seems fine. I wonder if we should only include the ffplay command line in the examples?

That alone is cause for changing the examples I would argue.
But note that the UDP examples don't utilize VLC on the sending side, and it appears that the data stream is corrupt/not working. And this is with --inline as well. Might be a separate bug. I know OBS uses VLC in the background (?) for media streams such as UDP, so I can't completely rule it out. But it feels like UDP is just broken overall in libcamera-vid.

[naushir]

But note that the UDP examples don't utilize VLC on the sending side, and it appears that the data stream is corrupt/not working.

Probably not the place to talk about this, but the udp streaming example worked perfectly for me provided I used ffplay on the client instead of vlc.

[naushir]

I will update the docs with ffplay examples, and provide a note saying that current vlc versions seem to be temperamental with streaming.

[aallan]

Thanks @naushir!

[naushir]

Done: #2396

[aallan]

Done: #2396

Should we try and replace those omxplayer examples in the documentation with ffplay at this point?

[naushir]

Should we try and replace those omxplayer examples in the documentation with ffplay at this point?

Yes, that is probably needed as well. Is omxplayer still used on Pi 3/2/1?

[aallan]

Yes, that is probably needed as well. Is omxplayer still used on Pi 3/2/1?

omxplayer got removed in Bullseye I think, so "it depends" is probably the correct answer. Is ffplay installed by default? If so, I guess it doesn't matter so long as we can replicate the examples using it.