6by9
commented
6 years ago TBH V4L2 just doesn't map very well onto the camera stack on the Pi, so you either go for stupid amounts of complexity in returning results, or over-generalise. Currently it over-generalises.
V4L2 expects to be closely mapped onto sensor modes - 99.99% of V4L2 devices will return a discrete list of supported resolutions, and so much software only handles V4L2_FRMSIZE_TYPE_DISCRETE.
In the case of the Pi you've got the sensor, ISP, and codecs combined into the one V4L2 device, mainly as it reduces complexity for clients. Whilst the sensor does support a fixed set of modes(*), the ISP will crop and and resize the sensor output to almost anything up to a maximum of around 150MPix/s. The H264 codec does have a hard limit of 1920x1088, and will enforce the limits imposed by the H264 level. MJPEG should do 5MPix happily, and probably the 8MPix off the v2 sensor (I don't recall trying it).
When writing the driver, trying to describe that lot through the V4L2 API just wasn't worth the effort.
The one limit that might be worth correcting is for H264, as it will always fail on anything above 1920x1088. This should already fail at STREAMON, but wouldn't be too onerous to advertise correctly.
The format/resolution and H264 level can be set in either order, so the first time it can be checked is at STREAMON, and that should already throw an error if it exceeds the limits. (I have just noticed we don't advertise levels 4.1 and 4.2 which may work if you overclock. v2 sensors can achieve 720P120 which requires level 4.2).
All the other formats will be on a best-efforts basis. Yes it will allow you to ask for 5MPix90, a v1 sensor will be set to VGA90 to achieve the framerate, and the ISP will be upscaling as fast as it can. The resulting images will look rubbish due to the large upscale, and as it equates to 450MPix/s the ISP will be dropping frames, but it won't actively fail.
If you felt strongly enough to create a PR that amended the responses to VIDIOC_ENUM_FRAMEINTERVALS and VIDIOC_ENUM_FRAMESIZES then it'd be reviewed. The returned values need to differ between the V1 and V2 sensors, and be easily extendable should there be further sensors added.
Shouldn't the max resolution for video capture be 1920x1080?
The "Video Capture" string is v4l2-ctl expanding out the buffer type V4L2_BUF_TYPE_VIDEO_CAPTURE. There is no buffer type defined for "stills", so if you want to get an image of any type then it's V4L2_BUF_TYPE_VIDEO_CAPTURE (or on some other devices V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, but that's a totally different discussion).
Are you really wanting to remove the ability to capture any images above your magic limit of 1080P? On what basis?
(*) See https://picamera.readthedocs.io/en/latest/fov.html#sensor-modes for the list of the actual modes off the sensor - the docs link is really regurgitating the Omnivision and Sony datasheets rather than reality. The camera stack chooses the most appropriate sensor mode for the requested output resolution and works from that.
JamesH65
Hello,
the following link suggests that for Camera Module v1, the framerates drop as the resolution increases: https://www.raspberrypi.org/documentation/hardware/camera/README.md
at 1080p, the framerate is 30. For 720p, it's 60. at 480p, it is 90 fps, etc. using ffmpeg, I was able to setup capture streams with these settings, but video capture over 1080p didn't work and choosing a higher framerate for a given resolution didn't work.
However, the v4l2 api reports the same maximum framerate regardless of the resolution: 90 fps.
Also, the following image suggests you can capture video at the maximum resolution for any pixel format.
Shouldn't the max resolution for video capture be 1920x1080? As it is now, using v4l2-ctl to determine settings isn't very useful and neither is using the v4l2 api in software.