CSI-2 2 & 4 Lane Support
ETE-Design opened this issue · comments
Hi.
The Raspberry Pi 5 seems to Support CSI-2 - 4 Lane, and there is already some camera chip that support 4-lane. Wouldn't it give a performance gain to support it? And do you know how to make this part?
Yes, the RPi5 supports 4 lane cameras. I have a couple here that I am testing. But this is probably a discussion more appropriate for the raspberry pi forums or kernel repository https://github.com/raspberrypi/linux/ rather than a camera streamer application.
In terms of 'performance gain' ... it really depends on what you're trying to achieve. You can either transfer twice the pixels in the same amount of time, or you can use half the clock speeds to transfer the same quantity of data.
But all of that is dependant upon the sensors and drivers supporting those modes and settings.
4 Lane support does however give a bigger range of cameras that can be supported. Some modules are only supported in 4 lane configurations for instance.
@kbingham So when the kernel support 4-lane this software will automatic support it, is that correct understod?
Would like to live stream 4k60Hz Video over Lan, so was hoping 4-lane would make it possible.
@ETE-Design Unlikely to happen, since 4k60HZ are unlikely to be software encoded by the CPU. I will be testing this yet, but I would not have my hopes high. I'm looking at adding software encoding in camera-streamer now, as this appears as an only way to make some features to work.
Indeed, you're going to hit encoder performance limitations long before you hit MIPI Data lane limitations I believe.
@ayufan Note that Pi5 does not have a hardware encoder at all. RPi use ffmpeg in their rpicam-apps on pi5.
@kbingham Yeah, I corrected my message. I know which makes even h264 1080p@60fps at the edge on pi5 :)
Encoding is one of the troubling points for me. So many people "expect" libcamera to handle it - but it's not libcamera's job. ... Maybe it should be 'libencoders' job - but there's already ffmpeg and gstreamer for all that.
I'm thinking the same, so I will use ffmpeg for that. There's no reason to reinvent a wheel.
The awesome part then will mean your camera-streamer will really not be tied to RPi devices ... and it would run on /any/ libcamera supported platform.
Correct. That is the idea. I also work on reverse process: support USB h264 compatible cams, to decode h264 to provide JPEG screenshots. Which would work on any device. As doing jpeg/yuyv re-encoding to h264 is rather too expensive for majority devices.