Capturing to avi format with libav codec writes wrong fps to fil

[ShovelJockey]

Hi there I am aiming to record 1 hr videos at 500x375) from a raspberry pi (running 64-bit bullseye).

Using this command line in a bash script:

libcamera-vid -t $filmDuration --framerate 5 --width 500 --height 375 --nopreview -- --codec libav --libav-format avi -o "$(date +%Y%m%d_%H%M.avi)" --tuning-file /usr/share/libcamera/ipa/raspberrypi/imx219_noir.json

This records the footage as needed but the file information incorrectly has 600.000fps which prevents use of this video with other software.

This figure is not accurate apparent both from watching, them having the correct number of frames for 3600 seconds at 5 fps and software that interprets the 600fps as true quickly running out of frames.

Am I missing something here or is this unintended behaviour? I found that by changing the container to mp4 the information was correct but any interruption of the recording would corrupt the video missing moov files.

Any help would be greatly appreciated.

[6by9]

Issue duplicated at https://forums.raspberrypi.com/viewtopic.php?p=2046166 (now locked)

For MP4 and ctrl-C, see #387 and #389

[ShovelJockey]

For the mp4 ctr c handling I assume this would not help in cases of unexpected system shutdown?

[6by9]

For the mp4 ctr c handling I assume this would not help in cases of unexpected system shutdown?

MP4 has an equivalent of a table of contents at the beginning of the file, therefore it is not possible to create a valid file without closing it cleanly.

IIRC MKV operates in a mode which doesn't need a clean close. Unexpected system shutdown is still going to result in some data loss (worst case fully corrupt SD card), but it has a better chance of keeping more of your recording.

[naushir]

Just tried this out and indeed the AVI framerate always reports as 600fps. Interestingly mkv containers also have this problem (reporting 30fps always). However, mp4 seems fine...

[ShovelJockey]

Is this data particularly easy to change? The videos are otherwise fit for purpose but this information really throws off the package I am using. Something to do with how the opencv element tries to plot data against frames means it vastly overestimated the total number of frames and fails to analyse them correctly.

MP4 does seem to work fine, would using mpegts as the format and saving to an MP4 container make the recording less likely to be corrupted? Saw it as a suggestion but haven't had a chance to test it.

[naushir]

Is this data particularly easy to change? The videos are otherwise fit for purpose but this information really throws off the package I am using. Something to do with how the opencv element tries to plot data against frames means it vastly overestimated the total number of frames and fails to analyse them correctly.

I'm having a look now to see what could cause this. As far as I can tell, all the stream durations/timestamps, etc. are all set correctly, so its a matter of finding what's missing in my libav setup.

MP4 does seem to work fine, would using mpegts as the format and saving to an MP4 container make the recording less likely to be corrupted? Saw it as a suggestion but haven't had a chance to test it.

You might be able to use mpegts, I've not checked if it has the same problem with framerate as the other containers.

[naushir]

Interestingly the mediainfo tool reports the correct framerate for the mkv file while ffprobe is still wrong. mediainfo still reports 600fps for any avi file though.

[ShovelJockey]

Will test mpegts see the effects on mp4 container corruption but also if it effects the written framerate. I did notice the mkv files were also not reporting fps correctly but was less sure than AVI that it was definitely incorrect as 600fps is much more anomalous.

[naushir]

I have manged to fix the mkv case - it turns out that there are some additional(!) framerate fields in the stream structure that need filling in. Change is at https://github.com/raspberrypi/libcamera-apps/pull/392.

However, this still does not fix the AVI case. I have to continue looking into this one.

[naushir]

Will test mpegts see the effects on mp4 container corruption but also if it effects the written framerate. I did notice the mkv files were also not reporting fps correctly but was less sure than AVI that it was definitely incorrect as 600fps is much more anomalous.

Just a quick note on this - mpegts is a stream format, as is mp4. So you cannot put an mpegts in an mp4 container. To create an mpegts stream output, you can use something like:

libcamera-vid --nopreview --codec libav --frames 100 -o test.ts --framerate 30 --libav-format mpegts

[ShovelJockey]

Great new on the mkv front, as from what I have tested mkv provides a similar sort of flexibility and robustness that I looked for in avi. I didn't know that about mpegts, I appreciate the help as video is very new to me.

[naushir]

I think I found the cause of the avi container reporting 600fps. This is due to a limitation in the libav library itself, where it was using the timebase to calculate framerate, rather than the actual framerate field!

The fix has been added to https://github.com/raspberrypi/libcamera-apps/pull/392.

[ShovelJockey]

Great! looking forward to implementing this.

[naushir]

This should now be available through apt-update.

Resolving now. Feel free to re-open if it still does not work for you.