[HOW-TO] inconsistent video duration

[Mat24amal]

I am having trouble getting a consistent video output recording a slow mo video. My code records an 8 second video at 242 fps, this should result in a 32 min video after encoding it at 1 fps. However, when running the code, I sometimes get video duration of 1 min sometimes 18 mins and sometimes the 30 mins I should be getting. It is really inconsistent.

This is my code:

def slow_mo_242fps() -> str | None:
    date_and_time = datetime.datetime.now().strftime("%d-%m-%Y_%H:%M:%S")
    camera = Picamera2()
    time.sleep(2)
    config = camera.create_video_configuration(
        main={"size": (640, 400)},
        encode="main",
        buffer_count=12,
        controls={
            "FrameDurationLimits": (2000, 2000),
            "NoiseReductionMode": controls.draft.NoiseReductionModeEnum.Off,
            "ExposureTime": 29,
        },
    )
    camera.configure(config)
    time.sleep(1)

    encoder = H264Encoder(framerate=1, enable_sps_framerate=True)
    output_file = "242fps_RawData_" + date_and_time + ".h264"

    camera.start_recording(encoder, output_file, pts="timestamps.txt")
    time.sleep(8)
    camera.stop_recording()

I have tried rebooting my Raspberry Pi before each recording, but it doesn't seem to make a difference

I am using an OV9281 camera

How do I make it consistent? Any suggestions?

Thanks in advance for the help

[davidplowman]

Can you say what kind of a Pi this is? That might make a difference, because high framerates are going to use lots of CPU. I'd start by trying some experiments:

• Do you actually get 242fps when nothing else (such as video encoding) is actually running?
• What does timestamps.txt tell you about where and when frames are being dropped?
• Can you send the video stream to /dev/null and see if that makes a difference?
• What if you write the video to a memory file (in /dev/shm)?
• What happens if you don't encode at all? I think you can use the base Encoder class as the "null" encoder, and the base Output class to "dump" the video output.

You could also try the rpicam-vid application as that will avoid the overheads associated with running Python.

[Mat24amal]

Sorry for the late response, didn't have time to work on this project last weak.

I found an extra "problem" that I forgot I ignored in the past. The Frame Duration limits I am using are not even for 242 fps. They are for 500 fps but i realized they semi consistently gave 242 fps, so I decided to go with them. If I use the frame duration limits for 242 (4132) i get around 220 ish fps. Form the timestamps.txt file i can see that the interval is mostly right but i get two instances where the interval is really far of. one being 20 ms and the other one being 28 ms. I guess thats where i loose the 20 frames.

Another thing I noticed is that the really high differences between video duration occur when there is movement in the video. When there is no movements i still get the usual 20 frame drop but I don't drop frames as bad as when there is movement. However, I have already gotten videos with movement and with minimal frame drop. The problem is consistency.

Additionally, looking at the sensor modes, the camera should be capable of doing max 325 fps

[{'bit_depth': 8,
#   'crop_limits': (0, 0, 1280, 800),
#   'exposure_limits': (29, None),
#   'format': R8,
#   'fps': 325.52,
#   'size': (640, 400),
#   'unpacked': 'R8'}, 

The Pi I am using is a pi 4 model B with 8 gb of ram.

I will experiment with what you suggested today.

Thank you for your for helping me with this issue

[Mat24amal]

Using the code I provided (with 4132 for frame duration limit) I took a 5 second video. This are some of the deltas I get between frames:

8.278
4.1419999999999995
4.154999999999999
4.135000000000002
4.135999999999999
4.1370000000000005
4.138000000000002
4.143999999999998
4.136000000000003
4.144999999999996
4.137999999999998
4.146000000000001
4.139000000000003
4.137999999999998
4.138999999999996
4.143000000000001
4.1370000000000005
4.150000000000006
4.131
4.140999999999991
4.143000000000001
4.140000000000001
8.283000000000001
4.1440000000000055
4.132000000000005
4.143000000000001
20.71499999999999
4.123999999999995
8.28200000000001
8.280000000000001
4.140999999999991
8.283999999999992
4.142000000000024
8.281999999999982

I is just a section of the deltas but in general they look like this. The big 20 ms delta is in a section of the recording with there is a fast motion. but even in section of the video where there is no motion i see inconsistent deltas. I don't know it this helps