The width/height you specify is always that of the final output buffers.
Taking your 2nd command, you've asked for an output that is 4:3, so that means you need a 3:4 image off the sensor. There are no 3:4 modes, so it will normally choose 1296x972, crop it to 730x972 to give 3:4, and then rotate and upscale it to give you 1296x972 out. Not great for FOV or image quality.
Your third command is correct to get the full original frame but rotated 90.
However what you've tripped over is a firmware bug
The codec takes a specific weird image format as input, and that has a maximum height image that it can handle without switching to a different mode. That used to at 1344, but a change has been made that appears to have dropped that down to 1264.
Code: Select all
raspivid -w 972 -h 1264 -rot -o file/h264
Code: Select all
raspivid -w 972 -h 1266 -rot -o file/h264
(1266 requires the next 16x16 macroblock, so is actually 1280 high).
I've done a very quick firmware mod to reduce the threshold down from 1344 to 1264 and both your V4L2 commands and the raspivid command work fine. I'll double check the numbers and push a patch to be released when Dom next makes a release (normally about once a week to be picked up with rpi-update - treat rpi-update with caution!).
And thanks for the report
We can't test everything and these things do occasionally go wrong.
The change that broke this was either July or November 2015, so you can tell how few people hit this use case.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.