Raspivid: Allow specification of --frame_rate_num and --frame_rate_den to allow time lapse recording

[pdr0663]

I am doing time lapse photograpy using raspistill and other software to make movies. I am left with lots of still images I don't need, and manipulationof the images on another system. It occurred to me that time lapse videos are just normal videos recoded at a slow frame rate and played back at a higher rate. Can we specify the input and output frame rates separately, in order to do timelapse?

I note that the code includes FRAME_RATE_NUM and FRAME_RATE_DEN. These can be arranged to get slow inpu framerates for time lapse quite easily, and I assume that the output frame rate is just metadata and could be specified separately.

Can this be added?

Paul

[6by9]

We already have an fps parameter, however it currently takes an integer, so 1fps is the slowest you can go.

The slowest the sensors can frame varies between sensors

• v1 is 6secs
• v2 is 10secs
• HQ is ~200secs You can not exceed those limits without dropping frames or similar, and that is not supported within the pipelines.

Internally the frame rate is stored in steps of 1/256 fps, so you're not going to get exact frame rates. Otherwise converting fps to being a floating point parameter and setting it should work.

Bitrate control may well go wrong - the headers there are also integer values, so it may need some tweaking.

[HinTak]

There is probably no need to switch to fractional input parameters - you can probably "overload" an integer input in the negative direction i.e. -6 fps to mean 1 frame fevery 6 sec, or 1/6, fps.

I doubt anything different, like 2.5 fps ( between 2 fps and 3 fps) or 1 frame for each 2.5 sec ( 0.4, between 1/2 and 1/3 fps) are useful at all. So using the -ve half of input might be "good enough".

[6by9]

There is probably no need to switch to fractional input parameters - you can probably "overload" an integer input in the negative direction i.e. -6 fps to mean 1 frame fevery 6 sec, or 1/6, fps.

Yuck, no. It's only userspace code that needs to convert to floats, so that's simple. We already have floats in there for the AWB gains, so it's no hardship adding them. The value passed to MMAL is a rational, which is then converted to fixed point within the firmware. Floats also keep it logical to the user - 0.1fps means 1/10 of a frame/second, or 10secs/frame.

[HinTak]

0.1 fps = 1 frame every 10 sec may be simple, but say, 1 frame per minute? 1 frame every 2 minutes? It is easier to write -60 and -120, -180 than 0.016666667 and 0.00833333 , 0.00555555 for 1 frame for every 3 minutes ?

You may be forcing people to do 0.02 and 0.01 and 0.005 (every 50 sec and every 100 sec and 200 sec) instead.

[HinTak]

At the lower end, -2, -3, -4, -5, -6, -7,-8, -9 seems easier than 0.5, 0.3333, 0.25, 0.2, 0.16667, 0.142857, 0.125, and 0.11111 ...

[popcornmix]

Floats allow anything to be specified. How about 1.5 fps? or 0.6fps?

[HinTak]

Yes, but I am thinking of the convenience of the often used cases. Once you get to the slow frame rates, you want the large values - 1 frame per 200 s (just over 3 minutes) as 0.005 is less meaningfull that 1frame per 3 minutes, but the latter will be 0.00833333...

[HinTak]

And what about 2 frames per minute, or 10 frames per minutes? (30s and 6s). I am just thinking that people like to think in 1 frame per N sec, once it is slow enough.