Frame Drop

[monanto]

I record video with 60 second splitter. Some time its complete 60 sec video file

and sometimes its only 53,54,56 second Some seconds accelerate with frames skipped

Using pi 2 and cam version 1.3

It also happens with motion detection videos

Nothing in logs No errors

[roberttidey]

If you look in scheduler log you can see when capture started and stopped. If that shows that these are 60 seconds apart but videos are shorter then it does sound that frames are getting dropped.

This should not happen even with Pi Zeros. Have you checked camera cables? Also ensure power supply is good and any USB cable used is short and thick to avoid voltage drop.

Do you have any other heavy duty software running? Run top in a console to see CPU usage.

Other thing to check is GPU memory allocation. This should be 128MB at least.

[monanto]

Hi

"you can see when capture started and stopped" Yes they are 60 seconds apart

"Have you checked camera cables" check what ?

Also there is no red led blinking or any voltage normalized in dmesg "Do you have any other heavy duty software running? Run top in a console to see CPU usage." No nothing I have even disabled MP4Box conversion

Yes its 256 Mb "Other thing to check is GPU memory allocation. This should be 128MB at least."

[monanto]

Strangely i ran And i get perfect 60 seconds videos with no drop at all or any accelerated frames

for i in {1..10};do raspivid -t 60000 -o vi$(date +%H%M%S).h264;done

So iam certain its not hardware issue

[roberttidey]

Strange.

By camera cable I meant check it is inserted well at both ends and also the tiny ribbon on the module is well pressed down.

But if raspivid is working OK it is unlikely to be a cable problem.

I just did a test with split and got twenty files OK, no frame drop. I haven't had this issue arise before.

Have you got any buffering turned on under camera settings? Try it with 0 if you have.

[monanto]

Yes 3000 buffer "Try it with 0 if you have." Ok i will

[monanto]

Same issue with buffer 0 Which rpi version and kernel you tested with ?

[roberttidey]

The one I ran the test on was raspbian Stretch (9), kernel 4.9.80-v7+ #1098. I have run this on a lot of different versions right through from wheezy, through jessie etc.

There is a simple logging facility for the video callback routine which handles the data from the camera. One enables this by changing the mmal_log config setting to say //dev/shm/mjpeg/mmallogfile This can be done either in the main /etc/raspimjpeg config file or by putting an entry in uconfig in the web folder

[monanto]

I have 4.14 Got with rpi-update

[roberttidey]

OK. 4.9.80 was the version stretch was released with.

I'll run some tests on various kernel upgrades since then to see if the problem arises from that.

You can use rpi-update to revert the kernel if you wanted to try that.

[roberttidey]

I'm not seeing an immediate problem after rpi-update but I need to do some more detailed tests.

Where are you getting your duration numbers from? The times on the thumbnails will not be accurate as they are based on file time stamps.

I may also try building against latest videoCore library as that is one of the things that can change when kernel is updated. That may take a couple of days to do.

[monanto]

No

I download file and play with mpv player on ubuntu Also i have time annotation and i see skipped seconds or fast frames

[roberttidey]

Have you tried playing the video directly in the web browser?

Note you can also put %k in annotation string to get the video frame count (0-24), making it easier to see drop frames.

[monanto]

Yes its same in browser I also tried in b+ (512 mb)

Still same issue

[roberttidey]

Couple of things.

Are you recording to the local SD memory or some other location? If the latter then you should use the boxing_path facility so the h264 files are recorded locally and then boxed to mp4 to the final location. Details in wiki.

Can you get a mmallogfile for me to check out. This is obtained by editing the /etc/raspimjpeg file and setting mmal_logfile /dev/shm/mjpeg/mmallogfile

This records some extra debug data from every callback requesting camera video data to be handled.

Stop and start the camera system and then let video record for a few 60 second cycles (till you think there has been frames dropped.

Then turn off that logging by setting the value back to

mmal_logfile

Grab the /dev/shm/mjpeg/mmallogfile, zip it and post here.

Thanks

[monanto]

Its class 10 card both things are done locally

I even tested with boxing off and generate only h264 files and then download h264 to Ubuntu system and then box them Even then i get same results

I had 2 cameras having issues with both of them

mmallogfile.zip

[roberttidey]

OK. Thanks for the log. It will take a little while to analyse

[monanto]

I see something like {2018/10/27 20:36:53} Capturing with split of 30 seconds {2018/10/27 20:36:53} Capturing started {2018/10/27 20:37:23} Stopping video from timer {2018/10/27 20:37:23} Capturing stopped {2018/10/27 20:37:23} Restarting next split of 30 seconds {2018/10/27 20:37:23} Capturing started [2018/10/27 20:37:31] Logged in user:: [2018/10/27 20:37:31] UserLevel 6 [2018/10/27 20:37:36] Logged in user:: [2018/10/27 20:37:36] UserLevel 6 {2018/10/27 20:37:53} Stopping video from timer {2018/10/27 20:37:53} Capturing stopped {2018/10/27 20:37:53} DEBUG 3 {2018/10/27 20:37:53} Restarting next split of 30 seconds {2018/10/27 20:37:53} Capturing started [2018/10/27 20:38:17] Logged in user:: [2018/10/27 20:38:17] UserLevel 6 {2018/10/27 20:38:23} Stopping video from timer {2018/10/27 20:38:23} Capturing stopped {2018/10/27 20:38:23} DEBUG 3 {2018/10/27 20:38:24} Restarting next split of 30 seconds {2018/10/27 20:38:24} Capturing started [2018/10/27 20:38:24] Logged in user:: [2018/10/27 20:38:24] UserLevel 6 {2018/10/27 20:38:54} Stopping video from timer {2018/10/27 20:38:54} Capturing stopped {2018/10/27 20:38:54} DEBUG 3 {2018/10/27 20:38:54} Restarting next split of 30 seconds {2018/10/27 20:38:54} Capturing started

This is like some thing "{2018/10/27 20:38:54} DEBUG 3"