nthnm
Posts: 15
Joined: Wed Apr 01, 2015 9:35 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 11:54 am

btidey wrote:That is definitely not going to work. Time lapse and video capture are mutually exclusive at the lowest camera connection level in raspimjpeg.

The web interface stops you doing this, but as you have discovered it is possible to send commands to do this and the process then curls up and dies. We can put some extra checks in to reject tl commands in active video mode and vice versa to prevent the crash.

Whether it is even possible to do this at all I am not sure about, but the priority at the moment is to get built in motion detection using motion vectors to replace 'motion'.
Thanks, good to have a definite answer. I assumed it was possible because the timelapse pauses the preview, so I thought timelapse and video capture would be on different buses or something.

And yes, looking forward to the motion detection being better integrated.

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 12:29 pm

nthnm wrote:
btidey wrote:That is definitely not going to work. Time lapse and video capture are mutually exclusive at the lowest camera connection level in raspimjpeg.

The web interface stops you doing this, but as you have discovered it is possible to send commands to do this and the process then curls up and dies. We can put some extra checks in to reject tl commands in active video mode and vice versa to prevent the crash.

Whether it is even possible to do this at all I am not sure about, but the priority at the moment is to get built in motion detection using motion vectors to replace 'motion'.
Thanks, good to have a definite answer. I assumed it was possible because the timelapse pauses the preview, so I thought timelapse and video capture would be on different buses or something.

And yes, looking forward to the motion detection being better integrated.
I am double checking this as I am now not sure whether they are indeed mutually exclusive or whether it is something else that may be the problem here.

toadleyb
Posts: 21
Joined: Sat Jan 04, 2014 11:05 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 12:36 pm

btidey wrote:Thanks for testing that.

It doesn't make sense to me from a pure coding perspective because with the log lines commented out it is the same as the original.

One theory I have is whether there could be a difference in the operation between the scheduler started up automatically after boot, and one which is stopped and restarted from the web interface. Mine tends to run after a web page restart as I am fiddling around and time based purging is working Ok with that. In testing the logging version you would probably have done that also. It would be interesting to see if correct operation survives a reboot.

I'm not sure at the moment how that could affect time based purging and not size based.
I can confirm that this is the issue. Mine was also not purging old files. I just tested by stopping scheduler from the web interface and then starting it. As soon as I did this the old files were purged.

KarolGT
Posts: 12
Joined: Tue Jan 27, 2015 3:31 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 12:39 pm

OK, I found where was the problem

in the new version (5.1), previously I had 4.x
I had to add to my rc.local

sleep 4;raspimjpeg > /dev/null &

instead of

sleep 4;raspimjpeg

because my script after raspimjpeg couldn't start

Thank you for your help.

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

Re: RPi Cam Web Interface

Fri May 01, 2015 2:07 pm

just FYI. Now that the web interface isn't usually crashing at sunset, it exposes a behavior of the camera: about 20 minutes after local sunrise and 50 minutes after local sunset (we are currently on PDT - daylight savings time) where it is locally dawn/dusk the camera image becomes more noisy and the autoexposure is unstable, it will flicker up and down in exposure within a second. This triggers the "motion" detection to start a new video record every 5 seconds or so. After about 20 minutes, the light changes enough that exposure stabilizes and the problem is gone. The source of the problem is the camera tuning itself but I don't think that will be revisited at this point, so I'm trying to tweak the 'motion' settings to overcome it. In the full set of motion parameters there is an "auto-exposure" setting (true or false), I wonder how this works. There is also a "light switch" setting (from 0 to 100) which is supposed to ignore sudden brightness changes as from turning on a light, but it doesn't always work.

I should add; this sunset/sunrise false trigger happens on only one of my two outdoor cameras. The problem is with the one with a light surface in part of the frame, and a darker shadowed area on the other side of the frame, so that condition is probably a factor.
Last edited by jbeale on Fri May 01, 2015 2:24 pm, edited 1 time in total.

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 2:09 pm

btidey wrote:
I am double checking this as I am now not sure whether they are indeed mutually exclusive or whether it is something else that may be the problem here.
Video and image capture are not mutually exclusive. I don't know why I said that as some time ago I had actually enabled the image capture button even when a recording is taking place.

However, I think there are some restrictions. In particular from a few tests I've done then I think the aspect ratio of the image set up and the video need to be the same. For example if I select the Full 4:3 then both the video and image are 4:3 and for me then I can kick off a video recording, and then send a tl 1 to initiate a time lapse and it all works. If I try to mix aspect ratio like a 16:9 video with a 4:3 image then I get errors and it falls apart.

I think also you may get slight disturbances in the video during image capture.

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 2:40 pm

jbeale wrote:just FYI. Now that the web interface isn't usually crashing at sunset, it exposes a behavior of the camera: about 20 minutes after local sunrise and 50 minutes after local sunset (we are currently on PDT - daylight savings time) where it is locally dawn/dusk the camera image becomes more noisy and the autoexposure is unstable, it will flicker up and down in exposure within a second. This triggers the "motion" detection to start a new video record every 5 seconds or so. After about 20 minutes, the light changes enough that exposure stabilizes and the problem is gone. The source of the problem is the camera tuning itself but I don't think that will be revisited at this point, so I'm trying to tweak the 'motion' settings to overcome it. In the full set of motion parameters there is an "auto-exposure" setting (true or false), I wonder how this works. There is also a "light switch" setting (from 0 to 100) which is supposed to ignore sudden brightness changes as from turning on a light, but it doesn't always work.

I should add; this sunset/sunrise false trigger happens on only one of my two outdoor cameras. The problem is with the one with a light surface in part of the frame, and a darker shadowed area on the other side of the frame, so that condition is probably a factor.
The reference for motion parameters is http://www.lavrsen.dk/foswiki/bin/view/ ... ileOptions but some of the descriptions don't make it clear the applicability. I think things like auto exposure might only be applying when motion is getting a live feed from the camera rather than a url based image sequence.

The one that seemed to help me was minimum_motion_frames as this allows short term variations to be filtered out. Now there is a capture buffer the latency introduced before a trigger is less important.

When we switch to motion vectors for detection inside raspimjpeg then that holds the promise of being less sensitive to light variations, but we are building in the equivalent of minimum_motion_frames as well.

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 2:48 pm

toadleyb wrote:
btidey wrote:
One theory I have is whether there could be a difference in the operation between the scheduler started up automatically after boot, and one which is stopped and restarted from the web interface.
I can confirm that this is the issue. Mine was also not purging old files. I just tested by stopping scheduler from the web interface and then starting it. As soon as I did this the old files were purged.
Found the cause of this which was a stupid relative path problem. Fixed in latest version

johng
Posts: 41
Joined: Thu Apr 23, 2015 10:00 am

Re: RPi Cam Web Interface

Fri May 01, 2015 2:57 pm

I am still getting iframe errors on two installations notwithstanding that I am running 5.1.3 with buffer set to 4000 on both.

Summary log from one attached.

Code: Select all

line no	log entry
1	{2015/04/30 23:23:39} RaspiMJPEG Version 5.1.3
2	{2015/04/30 23:25:00} RaspiMJPEG Version 5.1.3
3	{2015/04/30 23:25:01} MJPEG streaming, ready to receive commands
4	{2015/04/30 23:26:17} Motion detection started
5	{2015/04/30 23:26:25} Motion detection stopped
6	{2015/04/30 23:26:27} Motion detection started
7	{2015/05/01 00:09:22} Error: Error in iframe list
	604 error in iframe entries
612	{2015/05/01 00:09:29} Error: Error in iframe list
613	{2015/05/01 00:44:35} Capturing started
614	{2015/05/01 00:44:44} Capturing stopped
615	{2015/05/01 00:44:44} Boxing in background
	18 normal capture entries
634	{2015/05/01 05:24:19} Capturing started
635	{2015/05/01 05:25:35} Capturing stopped
636	{2015/05/01 05:25:36} Boxing in background
637	e list
638	{2015/05/01 05:25:36} Error: Error in iframe list
	90 error in iframe entries
729	{2015/05/01 05:25:53} Error: Error in iframe list
730	{2015/05/01 05:53:10} Capturing started
731	{2015/05/01 05:53:28} Capturing stopped
732	{2015/05/01 05:53:28} Boxing in background
	from 05:53 to now (15:30); no problems
It looks as if there is some logging error at line 637, incomplete line.

Curiously, although buffer is showing as 4000 on both browser screens under camera settings (and remains at 4000 after reboot), raspimjpeg is showing 3000 on one machine and 0 on the other under setting video_buffer. Is video_buffer the same as buffer under camera settings and if so should I change video_buffer manually?

Many thanks,

John G

nthnm
Posts: 15
Joined: Wed Apr 01, 2015 9:35 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 3:07 pm

btidey wrote:
jbeale wrote:just FYI. Now that the web interface isn't usually crashing at sunset, it exposes a behavior of the camera: about 20 minutes after local sunrise and 50 minutes after local sunset (we are currently on PDT - daylight savings time) where it is locally dawn/dusk the camera image becomes more noisy and the autoexposure is unstable, it will flicker up and down in exposure within a second. This triggers the "motion" detection to start a new video record every 5 seconds or so. After about 20 minutes, the light changes enough that exposure stabilizes and the problem is gone. The source of the problem is the camera tuning itself but I don't think that will be revisited at this point, so I'm trying to tweak the 'motion' settings to overcome it. In the full set of motion parameters there is an "auto-exposure" setting (true or false), I wonder how this works. There is also a "light switch" setting (from 0 to 100) which is supposed to ignore sudden brightness changes as from turning on a light, but it doesn't always work.

I should add; this sunset/sunrise false trigger happens on only one of my two outdoor cameras. The problem is with the one with a light surface in part of the frame, and a darker shadowed area on the other side of the frame, so that condition is probably a factor.
The reference for motion parameters is http://www.lavrsen.dk/foswiki/bin/view/ ... ileOptions but some of the descriptions don't make it clear the applicability. I think things like auto exposure might only be applying when motion is getting a live feed from the camera rather than a url based image sequence.

The one that seemed to help me was minimum_motion_frames as this allows short term variations to be filtered out. Now there is a capture buffer the latency introduced before a trigger is less important.

When we switch to motion vectors for detection inside raspimjpeg then that holds the promise of being less sensitive to light variations, but we are building in the equivalent of minimum_motion_frames as well.
I've experienced this issue as well. I found that minimum_motion_frames has to be set to at least 3 to nullify it, as the camera will jump to a lighter setting then back to darker or vice versa, resulting in two frames of motion. It all depends whether losing that much motion is acceptable. Lightswitch suppressed false positives some of the time when I set it to about 80... any lower and it starts ignoring real motion. This will all depend on lighting conditions and the type of motion you're interested in, so YMMV. I think it needs caution to make sure that defaults are sensible and relaxed, and not tailored to one specific set of lighting conditions.

nthnm
Posts: 15
Joined: Wed Apr 01, 2015 9:35 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 3:13 pm

btidey wrote:we are building in the equivalent of minimum_motion_frames as well
Will this work as it does now (not trigger recording until the number of frames has been reached) or will it work as motion does when recording natively, which is to record continuously in the background and save the recording once the minimum number of frames has triggered? Obviously the latter would be desirable, but I suspect significantly more difficult to implement.

johng
Posts: 41
Joined: Thu Apr 23, 2015 10:00 am

Re: RPi Cam Web Interface

Fri May 01, 2015 3:23 pm

A couple of queries:-

1a. is it possible to put additional commands into the motion on_event_start and on_event_end settings? I am currently running a pi with the standard motion mmal and using these settings to communicate motion on and off to Domoticz so that I can trigger other actions but I would like to move to using RPI Cam Web for this.

1b. Following on from this, I see that there is talk of changing away from motion. If this is achieved, will there still be a facility to notify external programs of motion events?

2. I am slightly confused as to how to update the software to the latest vesion. if I re-install using git clone https://github.com/silvanmelchior/RPi_C ... erface.git, it demands that I delete the Rpi_Web_Cam_Interface directory. Is this right or is there a simpler way. I think I saw somewhere that there is an update or upgrade parameter I can use instead of new instal. If there is, does it overwrite config files?

Many thanks, John G

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 3:25 pm

johng wrote:I am still getting iframe errors on two installations notwithstanding that I am running 5.1.3 with buffer set to 4000 on both.

It looks as if there is some logging error at line 637, incomplete line.

Curiously, although buffer is showing as 4000 on both browser screens under camera settings (and remains at 4000 after reboot), raspimjpeg is showing 3000 on one machine and 0 on the other under setting video_buffer. Is video_buffer the same as buffer under camera settings and if so should I change video_buffer manually?

John G
The screwed up logging there is a consequence of the iframe errors being logged from within the callback function from the camera system when it returns each buffer of data. This is asynchronous to the main raspimjpeg process and so if the foreground process happens to be logging an event at exactly the same time then they can clash and a bit can get lost. We could do something about this but the logging from the callback is really just for gross errors like these iframes, so it is better to fix those rather than worry about this bit.

Certainly setting buffer up helps to avoid these and I find with > 3000 I rarely get them. There have also been some improvements in the buffer handling which should help avoid these but these are in the branch of code for motion vector handling so isn't ready for main use yet.

The buffer size is almost certainly correct on the web interface. The reason why you see a 'difference' is because there are 2 raspimjpeg config files. The one in /etc is the factory defaults that you can also edit to change the basic defaults. The other is the uconfig file held in /var/www which holds any changes you have made from the web interface. raspimjpeg reads the default one first then it reads uconfig which can update any values it holds. So for example if you have video_buffer 3000 in /etc/raspimjpeg then make a change from the web to 4000 then you will find video_buffer 4000 in uconfig and that will be the active one. By doing a reset settings from the web uconfig is wiped and all values then revert to the factory defaults.

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

circular buffer for pre-trigger video?

Fri May 01, 2015 3:26 pm

btidey wrote: Now there is a capture buffer the latency introduced before a trigger is less important.
Can you expand upon this point? I see at http://elinux.org/RPi-Cam-Web-Interface it mentions "Circular buffer to capture the last actions afterwards" as a feature, but that is the only mention of "buffer" on that page. Is this buffer always active, or can it be turned on and off? Can the length be configured?

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

Re: RPi Cam Web Interface

Fri May 01, 2015 3:39 pm

johng wrote:2. I am slightly confused as to how to update the software to the latest vesion. if I re-install using git clone https://github.com/silvanmelchior/RPi_C ... erface.git, it demands that I delete the Rpi_Web_Cam_Interface directory. Is this right or is there a simpler way. I think I saw somewhere that there is an update or upgrade parameter I can use instead of new instal. If there is, does it overwrite config files?
I don't execute any git commands, I just navigate to the directory and do

Code: Select all

./RPi_Cam_Web_Interface_Installer.sh install
That automatically updates to the latest version from github, stops the current running raspimjpeg process, and then re-installs. Afterwards I usually reboot although not sure if necessary.

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: circular buffer for pre-trigger video?

Fri May 01, 2015 3:41 pm

jbeale wrote:
btidey wrote: Now there is a capture buffer the latency introduced before a trigger is less important.
Can you expand upon this point? I see at http://elinux.org/RPi-Cam-Web-Interface it mentions "Circular buffer to capture the last actions afterwards" as a feature, but that is the only mention of "buffer" on that page. Is this buffer always active, or can it be turned on and off? Can the length be configured?
There is a video_buffer setting in /etc/raspimjpeg (default 0) and it can also be set from the camera settings (buffer). The value is an estimate in msec.

If the value is 0 then operation is as it were originally; a video capture starts capturing the h264 camera stream to a file. With the various latencies using motion detection then the trigger and the start of a capture can be a second or so after motion really started and this action is lost.

If the value is set to say 3000 (3 seconds) then raspimjpeg captures video data all the time into a RAM memory circular buffer sized to contain nominally 3 seconds but in practice normally more as static video compresses well. When a video capture then starts most of the contents of this buffer is then prepended into the video file which is now capturing data. This means that file recording actually contains video from before the trigger. You control the amount before by adjusting the buffer.

As an aside when I show this to non technical people where a video capture shows them emerging from a door after a few seconds, the normal reaction is 'how the heck does it do that'.

The thumbnail image is still taken from the trigger moment so it helps show the cause. You will also notice that the thumbnail has a time stamp later than the start of the video. The difference is effectively the size of the buffer.

I wouldn't use buffer sizes below 3000 at the moment as there can be errors looking for iframes in a small buffer.

nthnm
Posts: 15
Joined: Wed Apr 01, 2015 9:35 pm

Re: circular buffer for pre-trigger video?

Fri May 01, 2015 3:46 pm

btidey wrote:
jbeale wrote:
btidey wrote: Now there is a capture buffer the latency introduced before a trigger is less important.
Can you expand upon this point? I see at http://elinux.org/RPi-Cam-Web-Interface it mentions "Circular buffer to capture the last actions afterwards" as a feature, but that is the only mention of "buffer" on that page. Is this buffer always active, or can it be turned on and off? Can the length be configured?
There is a video_buffer setting in /etc/raspimjpeg (default 0) and it can also be set from the camera settings (buffer). The value is an estimate in msec.

If the value is 0 then operation is as it were originally; a video capture starts capturing the h264 camera stream to a file. With the various latencies using motion detection then the trigger and the start of a capture can be a second or so after motion really started and this action is lost.

If the value is set to say 3000 (3 seconds) then raspimjpeg captures video data all the time into a RAM memory circular buffer sized to contain nominally 3 seconds but in practice normally more as static video compresses well. When a video capture then starts most of the contents of this buffer is then prepended into the video file which is now capturing data. This means that file recording actually contains video from before the trigger. You control the amount before by adjusting the buffer.

As an aside when I show this to non technical people where a video capture shows them emerging from a door after a few seconds, the normal reaction is 'how the heck does it do that'.

The thumbnail image is still taken from the trigger moment so it helps show the cause. You will also notice that the thumbnail has a time stamp later than the start of the video. The difference is effectively the size of the buffer.

I wouldn't use buffer sizes below 3000 at the moment as there can be errors looking for iframes in a small buffer.
Ah ha. Ignore my previous question. This addresses it.

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

Re: RPi Cam Web Interface

Fri May 01, 2015 3:58 pm

I look forward to trying out this feature! I also took the liberty of adding this information to http://elinux.org/RPi-Cam-Web-Interface ... ure_Buffer

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 4:20 pm

johng wrote:A couple of queries:-

1a. is it possible to put additional commands into the motion on_event_start and on_event_end settings? I am currently running a pi with the standard motion mmal and using these settings to communicate motion on and off to Domoticz so that I can trigger other actions but I would like to move to using RPI Cam Web for this.

1b. Following on from this, I see that there is talk of changing away from motion. If this is achieved, will there still be a facility to notify external programs of motion events?


Many thanks, John G
Yes. You can currently put additional commands separated by ; into motion events.

I was a little bit uncomfortable with this myself as it means that any operating system command can be added from the web interface which is a bit dangerous from a security view.

That is why I have added the macros folder where one can put a limited set of commands (scripts) and only those can be selected for running from the web interface. These can be run either as the scheduler management_command or can be included in any of the scheduler motion trigger start stop or period entries.

You can do that even today instead of putting it in the motion set up and then it will still be applicable when motion is swapped out. So for example in a motion start box that currently has ca 1 you could put ca 1;sy notify.sh This will then start capturing video and will then try to run a script called notify.sh in the macros folder. You must create and put notify.sh in that folder first and give it execution rights. You have to do that outside of the web interface as the purpose is to lock down what can be run.

Jasimo
Posts: 51
Joined: Mon Apr 27, 2015 11:50 am

Re: RPi Cam Web Interface

Fri May 01, 2015 7:51 pm

btidey wrote:
That is certainly how it supposed to work and seems OK on mine it is regularly purging files based on the initial time criteria.

Somebody else reported that is wasn't working for them so I produced a special version of scheduler that just had a bit of extra logging in to show the time comparisons for each file during the purge check. It' in a fairly recent post 2 or 3 days ago.

When they tried it then purge started working even though it was just the same code. So I said to take the logging out but haven't heard where that ended up.
That was me ;-) but I have still have problems with the schedule.php and purging of files. It looks like that it make a different when stop/starting the schedule.php in the GUI and a reboot. My experience is, that it only work for me when i stop/start the schedule.php over the Web GUI, after a reboot the funktion is gone and i have again stop/start the scheduler to get it up and running.
rgs
Jan

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 8:35 pm

Jasimo wrote: I have still have problems with the schedule.php and purging of files. It looks like that it make a different when stop/starting the schedule.php in the GUI and a reboot. My experience is, that it only work for me when i stop/start the schedule.php over the Web GUI, after a reboot the funktion is gone and i have again stop/start the scheduler to get it up and running.
rgs
Jan
A few posts up. When invoked at start up it was looking in the wrong place.

Now fixed.

Jasimo
Posts: 51
Joined: Mon Apr 27, 2015 11:50 am

Re: RPi Cam Web Interface

Fri May 01, 2015 8:47 pm

found it, will update tomorrow. Keep up the good work
rgs
Jan

btidey
Posts: 1616
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Fri May 01, 2015 9:46 pm

btidey wrote:
solar3000 wrote:I was just concerned that this program runs as root and that it creates files as root.
Would there be any security concerns?
I was thinking of opening a port to this web interface program.
I don't think there is anything major stopping the current raspimjpeg being run under different authorisation but would require changes to at least the installation, joining the video group, boot up processes, etc. If any body wants to play with that and submit any changes that would be most welcome.
I've had a go at changing the install / start up and it seems to work. It ends up with raspimjpeg running as www-data (the apache default user) and the media files are stored as www-data.

I have not updated the Git yet as I want to give it a bit longer to make sure it's running OK.

If anybody else wants to try it the attached zip contains the 2 files involved.

1. Copy the files into say home directory
2. sudo cp rc.local.1 /etc/rc.local
3. cp RPi_Cam_Web_Interface_Installer.sh /RPi_Cam_Web_Interface
4. sudo usermod -a -G video www-data
5. sudo reboot

Step 3 is only really needed if you do stop start commands from the Installer script. It is the rc.local which will control the normal boot.
nonroot.zip
(2.62 KiB) Downloaded 42 times
Edit: It will need step 4 put into the install script for a first time install but that doesn't affect this test.

sknic
Posts: 2
Joined: Tue Apr 21, 2015 10:37 am

Re: RPi Cam Web Interface

Sat May 02, 2015 6:31 am

Hi, I play with raspberry pi as cam using rpi cam web interface. Using default settings and watching live video from pi it consumes 18Mbit/s of bandwitch. This is pretty much and on mobile internet it is not possible. How to lower this bandwitch to 3Mbit/s? Thanks

xab
Posts: 23
Joined: Sat Jan 24, 2015 1:24 pm

Re: RPi Cam Web Interface

Sat May 02, 2015 7:15 am

sknic wrote:Hi, I play with raspberry pi as cam using rpi cam web interface. Using default settings and watching live video from pi it consumes 18Mbit/s of bandwitch. This is pretty much and on mobile internet it is not possible. How to lower this bandwitch to 3Mbit/s? Thanks
Check /etc/raspimjpeg , find the line with "video_bitrate" and then modify the number, by default it should be 17Mbit/s ;)

Return to “Camera board”