User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Wed Jun 08, 2016 3:48 pm

"If it's encoding something that compresses very well, it will turn up the quality to use the extra bits." Is there an option to have a hard cap on per-frame bitrate? The image would become very blocky when a scene transition occurs, but that might be an OK tradeoff in some cases for a hard limit on bitrate.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Wed Jun 08, 2016 4:06 pm

(Going badly off topic here - please spawn a new thread if you really want to keep discussing this, even though there won't be a fix)
jbeale wrote:"If it's encoding something that compresses very well, it will turn up the quality to use the extra bits." Is there an option to have a hard cap on per-frame bitrate? The image would become very blocky when a scene transition occurs, but that might be an OK tradeoff in some cases for a hard limit on bitrate.
Already stated:
6by9 wrote:There's no going back to re-encode the frame with alternate compression values, partly because there isn't the bandwidth in the system, and partly as it will probably already have started processing the next frame using the one it has just encoded as a reference.
It's probably already a reference frame. If the decoder doesn't get that frame then it can't decode any more frames until it sees the next I frame.

For reference, non-overclocked 1080P encode is takes about 40ms per frame, but is pipelined so that it can accept a job every 33ms. Memory says that most of that last 7ms is CABAC encoding which will have a significant impact on bitrate, so there's potentially no tweaking of compression factors on the next frame either depending on exactly where the quantisation occurs. That's why CBR and high profile (allows CABAC) are not supported together - see https://github.com/raspberrypi/firmware/issues/254.

You could in theory drop to baseline profile and request CBR for a more tightly controlled bitrate, but you're losing some of the compression efficiency in doing so.

The codecs are not my area of in-depth knowledge, so there's no way I'm going to be going making significant changes to them. Except for investigating bugs, they are what they.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 4:58 am

I'm sorry if this has been answered, I believe I have read the thread through.

What is the max frame rate I can get in VGA resolution with the new camera? Actually I'm using 320x480 resolution. My project is a speed measurement system for RC flying, two cameras 100M apart taking video with the PI. However I do not use the hardware h264 encoder, I'm using the B&W part of the raw YUV data and send it to a multithreaded JPEG encoder and later send the images to a fast host computer for image analyzing in real time, that is analyzing 180 images per second with two cameras :) I have a lot of CPU time left on the PI3 for encoding JPEGs so that should be no problem.

On the v1.3 camera using 90FPS I get an error of about 1-2kmh when flying 200Kmh ona 100M course. Very good, but I want it better.

I've read something about new cropping on high framerates, do this apply to VGA resolution also? Might be a problem for me.

ethanol100
Posts: 583
Joined: Wed Oct 02, 2013 12:28 pm

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 9:29 am

LinusLarsson wrote: I've read something about new cropping on high framerates, do this apply to VGA resolution also? Might be a problem for me.
Yes, from the first post:
6by9 wrote: edit: As of rpi-update from 13/5/16, and raspbian update of 16/5/16, the mode list has been altered to more closely match the ordering on OV5647, and also to improve FOV for some modes.
- 1 - 1080P30 cropped (680 pixels off left/right, 692 pixels off top/bottom), up to 30fps
- 2 - 3240x2464 Full 4:3, up to 15fps
- 3 - 3240x2464 Full 4:3, up to 15fps (identical to 2)
- 4 - 1640x1232 binned 4:3, up 40fps
- 5 - 1640x922 2x2 binned 16:9 (310 pixels off top/bottom before binning), up to 40fps
- 6 - 720P binned and cropped (360 pixels off left/right, 512 pixels off top/bottom before binning), 40 to 90fps (120fps if overclocked)
- 7 - VGA binned and cropped (1000 pixels off left/right, 752 pixels off top/bottom before binning), 40 to 90fps (120fps if overclocked)
You will use a 1280x960px crop from the center of the sensors and use binning to half that resolution. You can specify mode 6 which yield a bigger (but still cropped) FOV, but I'm not sure if you can achieve 90fps. In mode 7 I reached a constant framerate of 100fps at VGA resolution(without any modification or overclocking, using a pi zero). And in theory you could get even higher framerates at 720P (up to 120).

Hope that helps. How do you get the timing between the two cameras? I assume you measure the time difference, when you see your flying object at each camera, and use the 100m distance to calculate the speed?

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 1:43 pm

ethanol100 wrote:Hope that helps. How do you get the timing between the two cameras? I assume you measure the time difference, when you see your flying object at each camera, and use the 100m distance to calculate the speed?
It helps a lot, 120 is better than 90. Have to get one and see what I can wrench out from it.

I'm just using the Unix clock synced with NTP for timestamping of the images. Done a lot of testing on this, putting the two cameras in front of eachoter and moving an object beetween them. NTP is exact enough, perhaps 1ms. I do not know if there is a timestamp on the video frame already, have not found one. I have to resort to timestamping it in the callback, with some jitter unfortunately. It's good, most of the time just a few milliseconds. But it's there.

I have a video here, cool stuff.
http://linlar.org/sleipnir/

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 8:13 pm

LinusLarsson wrote: I have to resort to timestamping it in the callback, with some jitter ... most of the time just a few milliseconds.
Is there a simple code fragment or example anywhere that shows how to get a timestamp for a video frame, with typically a few msec jitter? I'd be interested to see that.

User avatar
waveform80
Posts: 303
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 8:24 pm

jbeale wrote:
LinusLarsson wrote: I have to resort to timestamping it in the callback, with some jitter ... most of the time just a few milliseconds.
Is there a simple code fragment or example anywhere that shows how to get a timestamp for a video frame, with typically a few msec jitter? I'd be interested to see that.
The buffer that gets passed to the output port's callback usually contains the frame's timestamp (pts field in MMAL_BUFFER_HEADER_T). For example, picamera uses this as the frame.timestamp component. I can't recall whether that timestamp was for the start of the frame exposure or the end (6by9's answered that before in this forum though, I'm sure).

Dave.

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 8:34 pm

The PTS (presentation timestamp) in microseconds is based on some GPU clock if I am not mistaken, which I assume is simply a free-running counter started at boot time. Is there an easy way to connect that to real time (eg. system time-of-day clock as aligned to network time by NTP) ?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 8:36 pm

waveform80 wrote:
jbeale wrote:
LinusLarsson wrote: I have to resort to timestamping it in the callback, with some jitter ... most of the time just a few milliseconds.
Is there a simple code fragment or example anywhere that shows how to get a timestamp for a video frame, with typically a few msec jitter? I'd be interested to see that.
The buffer that gets passed to the output port's callback usually contains the frame's timestamp (pts field in MMAL_BUFFER_HEADER_T). For example, picamera uses this as the frame.timestamp component. I can't recall whether that timestamp was for the start of the frame exposure or the end (6by9's answered that before in this forum though, I'm sure).
It's the STC of the start of frame reception, so end of exposure of the first line. Use MMAL_PARAMETER_SYSTEM_TIME to get the current STC. Units are microsecs IIRC.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Thu Jun 09, 2016 8:41 pm

jbeale wrote:The PTS (presentation timestamp) in microseconds is based on some GPU clock if I am not mistaken, which I assume is simply a free-running counter started at boot time. Is there an easy way to connect that to real time (eg. system time-of-day clock as aligned to network time by NTP) ?
See the V4L2 driver.
Use MMAL_PARAMETER_SYSTEM_TIME to grab the STC, and some appropriate kernel system call to get the Linux time (V4L2 uses SYSTEM_TIME_MONOTONIC via a call to v4l2_get_timestamp()). For each frame that is returned, subtract the STC start offset, and then add the Linux start offset. How you want to handle clock corrections is up to you.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Fri Jun 10, 2016 6:04 am

Seems like more people are interested in calendar timestamping a video frame. To not derail this thread I started a new thread, the subject is very dear to me since on my project it's the number one problem to solve. Perhaps we can get some code examples going.

viewtopic.php?f=43&t=151025

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Fri Jun 10, 2016 7:53 pm

Updated first post as one OV5647 V1.3 sensor, and one IMX219 V2 sensor are now working simultaneously on the Compute Module, as are two IMX219s.

Please don't try stereoscopic with the mixed sensor combination - it won't work as the different characteristics of the two modules totally screws up any assumptions made.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ethanol100
Posts: 583
Joined: Wed Oct 02, 2013 12:28 pm

Re: New 8MP Camera - Q&A thread

Sat Jun 11, 2016 5:02 pm

6by9 wrote: Quick mod to the userland code at https://github.com/raspberrypi/userland ... id.c#L1424

Code: Select all

.num_preview_video_frames = 10,
just to give the codec and camera pipe a bundle more frames to play with to prevent camera pipeline stalls.

You've obviously found that you need to mod https://github.com/raspberrypi/userland ... id.c#L1726 to

Code: Select all

param.profile[0].level = MMAL_VIDEO_LEVEL_H264_42;
in order to exceed 245760 macroblocks/sec (720P68.3).

I must sort out that PR for raspivid. Always yet another thing to do...
I did some tests with the increased buffer number and level 4.2. Using a pi zero, I reach 120fps at VGA resolution and 96fps at 720P. The 120fps are even faster, looking at a stopwatch I measured ~125fps. That is really nice! In 720P I start to drop single frames at 98fps. I have modified my userland with 6by9 suggestions. I still need to try an overclocked pi3. If anyone wants to give it a try, you can find a compiled version of my modified raspivid here.
I have tested it with

Code: Select all

./raspivid -v -a 512 -t 60000  -w 1280 -h 720 -fps 96 --level 4.2 --additional-buffer 7 --save-pts video.pts -o video.h264 -t 30000 -a 512
(I am using the pi 0 as USB gadget, writing to my laptops hdd via sshfs, my SD was to slow and dropped frames.)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Sat Jun 11, 2016 7:11 pm

ethanol100 wrote:I did some tests with the increased buffer number and level 4.2. Using a pi zero, I reach 120fps at VGA resolution and 96fps at 720P. The 120fps are even faster, looking at a stopwatch I measured ~125fps. That is really nice! In 720P I start to drop single frames at 98fps. I have modified my userland with 6by9 suggestions. I still need to try an overclocked pi3. If anyone wants to give it a try, you can find a compiled version of my modified raspivid here.
I have tested it with

Code: Select all

./raspivid -v -a 512 -t 60000  -w 1280 -h 720 -fps 96 --level 4.2 --additional-buffer 7 --save-pts video.pts -o video.h264 -t 30000 -a 512
(I am using the pi 0 as USB gadget, writing to my laptops hdd via sshfs, my SD was to slow and dropped frames.)
Wow, that exceeds my expectations of it, particularly on a Pi0. I suspect both Naush and I were trying to write to the uSD card and that was our artificial performance limit, although I recall sending my data to /dev/null so I'm a little surprised.
I've got a USB HDD sitting in the corner, so it might call for some more experimentation.

Thanks for making those raspivid commits. I've made a couple of comments on them, but would be happy to accept a PR based on them :)
(Yes, I can be a bit of a stickler over code reviews sometimes. All I can say is there is that I work with a fussier guy than me, and at least we don't enforce checkpatch!)

125fps instead of 120 worries me a little - we may need to do some recalibration again, the same as we had to for OV5647. It is possible someone has forgotten to correct for the oscillator frequency again, although 4% is a long way out. I'd hope the Pi timestamps aren't that far out, but than then implies the main BCM283x oscillator is out. Hmm.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

'Night' exposure mode doesn't go to max ISO?

Mon Jun 13, 2016 6:00 am

I am using the Pi NoIR v2.1 with the PiKrellCam utility. I am finding the v2.1 camera is not as sensitive as I expect, when compared with the v1.3 camera. I am using both cameras in 'Night' exposure mode. I notice that I can make the v2.1 camera look brighter at night (maybe about 1 stop brighter) if I manually set ISO:800, rather than leaving it to the default, which was not the case with the older v1.3 camera. Is the v2.1 camera set to not use ISO 800 in night exposure mode by default, for some reason? The image in this case is nearly full black with a small area of very dim detail visible, so it should not be a case of automatic exposure turning down the gain.

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Thu Jun 16, 2016 10:11 am

I got myself a V2 camera yesterday and did some preliminary testing. My project is using high speed video and I need the FOV of the old camera, with little no cropping. I have two options as I see it.

1. The 720P high FPS mode (120?) could possibly work for what I'm doing as it seem to have quite a bit of FOV, but I would need to do an expensive resize in realtime to a smaller image (I'm using 320x480 on the old camera). I'm using YUV so the resize is at least straightforward.

2. Wait and hope for a low resolution full FOV mode to become available.

Is option number 2 on the radar/possible?

User avatar
waveform80
Posts: 303
Joined: Mon Sep 23, 2013 1:28 pm
Location: Manchester, UK

Re: New 8MP Camera - Q&A thread

Thu Jun 16, 2016 10:37 am

LinusLarsson wrote:I got myself a V2 camera yesterday and did some preliminary testing. My project is using high speed video and I need the FOV of the old camera, with little no cropping. I have two options as I see it.

1. The 720P high FPS mode (120?) could possibly work for what I'm doing as it seem to have quite a bit of FOV, but I would need to do an expensive resize in realtime to a smaller image (I'm using 320x480 on the old camera). I'm using YUV so the resize is at least straightforward.

2. Wait and hope for a low resolution full FOV mode to become available.

Is option number 2 on the radar/possible?
Resize needn't be expensive. There's a resizer component that you can throw into the MMAL pipeline to get the GPU to do the work in realtime (picamera uses this for its resize parameter).

Dave.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Thu Jun 16, 2016 10:47 am

LinusLarsson wrote:I got myself a V2 camera yesterday and did some preliminary testing. My project is using high speed video and I need the FOV of the old camera, with little no cropping. I have two options as I see it.

1. The 720P high FPS mode (120?) could possibly work for what I'm doing as it seem to have quite a bit of FOV, but I would need to do an expensive resize in realtime to a smaller image (I'm using 320x480 on the old camera). I'm using YUV so the resize is at least straightforward.

2. Wait and hope for a low resolution full FOV mode to become available.

Is option number 2 on the radar/possible?
Why do you think you need to do a resize operation rather than the GPU? There's a chunk of silicon area in the BCM283x chips called the ISP (Image (Sensor|Signal) (Pipeline|Processor)) that is doing all the image processing of the raw Bayer images, demosaicing, then a load of processing in the YUV or YCbCr domains, and the penultimate stage of that processing is a resize block. That resize has zero cost to the ARM.
Force the sensor mode to mode 6 (720P high frame rate), and then ask for your 320x480, and it'll crop and resize the 720P sensor data into 320x480 for you. (It'll take 480x720 of the pixels off the sensor).

No, I'm not going tweaking the sensor modes again unless it is to unify the FOVs or deliver even higher frame rates, so don't get your hopes up over option 2.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Thu Jun 16, 2016 11:11 am

6by9 wrote:Why do you think you need to do a resize operation rather than the GPU?
I Have no answer to this more than lacking in skill :)
6by9 wrote: There's a chunk of silicon area in the BCM283x chips called the ISP (Image (Sensor|Signal) (Pipeline|Processor)) that is doing all the image processing of the raw Bayer images, demosaicing, then a load of processing in the YUV or YCbCr domains, and the penultimate stage of that processing is a resize block. That resize has zero cost to the ARM.
Force the sensor mode to mode 6 (720P high frame rate), and then ask for your 320x480, and it'll crop and resize the 720P sensor data into 320x480 for you. (It'll take 480x720 of the pixels off the sensor).
This sound like the way forward, thank you!

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Fri Jun 17, 2016 6:10 am

I tested mode 6 with scaling yesterday, It's good but not perfect. I can get about 100FPS reliably, more than that and it start dropping frames. Not many though, still basically 120FPS but checking buffer->pts all frames are not delivered.

Are framedrops how a too slow PI would manifest itself, or am I doing something wrong? My "ugly sleep" is gone, so don't ask..

At VGA resolution 120FPS is stable and reliable, but perhaps too much cropping for my project. Really good work 6by9 anyway, you are a magician!

If I want to play with some overclocking, is it arm_freq and sdram_freq I should look at to perhaps squeeze out some more FPS?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7131
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: New 8MP Camera - Q&A thread

Fri Jun 17, 2016 8:56 am

LinusLarsson wrote:I tested mode 6 with scaling yesterday, It's good but not perfect. I can get about 100FPS reliably, more than that and it start dropping frames. Not many though, still basically 120FPS but checking buffer->pts all frames are not delivered.

Are framedrops how a too slow PI would manifest itself, or am I doing something wrong? My "ugly sleep" is gone, so don't ask..
Yes, frame drops are the symptom of the system being overloaded. The sensor is running at a fixed speed producing data, there's no way to interpolate a frame, nor any time to do so, so they just get dropped when buffering runs out.

ethanol100 seems to be the person who has played around the most with this so far at viewtopic.php?f=43&t=145815&start=300#p990405. His results too were VGA100 or 720P73 without overclocking. That is probably on the output side - I don't know if he tried forcing the 720P sensor mode but VGA out.
LinusLarsson wrote:At VGA resolution 120FPS is stable and reliable, but perhaps too much cropping for my project. Really good work 6by9 anyway, you are a magician!

If I want to play with some overclocking, is it arm_freq and sdram_freq I should look at to perhaps squeeze out some more FPS?
See earlier in this thread - viewtopic.php?f=43&t=145815&start=300#p990416 Reiterating that overclocking is entirely at your own risk.
I haven't had a chance to test out the automatic overclocking on out of spec requests, so you will need to use force_turbo=1 and risk your warranty bit.
arm_freq will do next to nothing as all the processing is GPU side.

If using raspividyuv or similar then there is an optimisation that avoids a memcpy of the output frames. I have a patch but no way of uploading to github whilst in the office. Basic premise is to add

Code: Select all

mmal_port_parameter_set_boolean(camera_video_port, MMAL_PARAMETER_ZERO_COPY, MMAL_TRUE);
before the port is enabled or the buffer pool is created (mmal_port_pool_create). It uses a service called VCSM (VideoCore Shared Memory) to map GPU memory into ARM space.
Please be aware that there has been a kernel deadlock situation observed recently when using zero copy that is being worked on. As it isn't used by default for anything we haven't advertised the issue, but kernel commit db8d464 seems to be the cause.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LinusLarsson
Posts: 12
Joined: Thu Jun 09, 2016 4:34 am

Re: New 8MP Camera - Q&A thread

Fri Jun 17, 2016 10:55 am

Thanks! Really good pointers for further testing. My program started out as raspividyuv, now it's something entirely different but setup of camera and such is unchanged.

gregeric
Posts: 1509
Joined: Mon Nov 28, 2011 10:08 am

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 10:55 am

Employing the increased buffer allocation in raspivid to raspividyuv, I am able to sustain 120fps from the V2 cam on my Zero for a few seconds, then the rate starts to drop off towards 100fps. This is a modified raspividyuv for finish line camera application. How long seems to depend on how much motion is in the scene - up to 5 seconds for a still scene and ~half of that when there's motion.

I played around varying the number of buffers - made things worse. Any idea why there's such a drop off?

ethanol100
Posts: 583
Joined: Wed Oct 02, 2013 12:28 pm

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 3:39 pm

At which resolution do you try to reach 120fps? Have you tried 6by9's suggestion of using MMAL_PARAMETER_ZERO_COPY?

User avatar
jbeale
Posts: 3476
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: New 8MP Camera - Q&A thread

Sun Jun 19, 2016 3:58 pm

gregeric wrote:Employing the increased buffer allocation in raspivid to raspividyuv, I am able to sustain 120fps from the V2 cam on my Zero for a few seconds, then the rate starts to drop off towards 100fps. This is a modified raspividyuv for finish line camera application. How long seems to depend on how much motion is in the scene - up to 5 seconds for a still scene and ~half of that when there's motion.
Sounds to me like the internal RAM is fast enough, but the memory (SD card I presume) can't keep up, so as soon as the buffer is full and you have to flush the RAM to the memory card, the system falls behind. When there is motion, the video bitrate goes up, so the system has to flush the buffers more quickly and the problem becomes worse.

Return to “Camera board”