RPi Cam Web Interface

[btidey]

Hi all. Firstly I just want to say that this is my first experience of following a project since I bought my Pi, and it's certain helping me learn a few new things. I'd been looking around and trying a few Pi camera web streaming projects, but I couldn't get any of them to work very well. However, yours does almost everything I could have wanted and actually worked (almost) "out of the box". So well done for some amazing work here!

I just have a couple of questions and I have tried searching this post and the wiki, but with no luck:

1. How do I update to the latest version, or do I have to do a fresh install?

2. Whenever I try and change the image quality from 25 (which it always defaulted to and not 85 as stated) the number stays, but with no noticeable change to the video above. When I navigate away and back though it say 25 again. Am I missing something, or is this not even the streaming outputs quality but the quality if still images are captured?

Excuse my newbie questions, but I'm trying to learn as I go!

Thanks very much.

1. You can just run the installer script again. It refetches any changes from the git repository before proceeding. If you use 'install' on the end it will put all the changes in but you may lose any changes you have made to motion config or the default raspimjpeg config. You can also use 'update' instead of install; that only changes the code and leaves your configs alone but if there have been any additions to say the raspimjpeg file then they wouldn't get included.

2. There was a bug in the 'image quality'. There are actually two qualities internally; one used for thumbnail / live screen and one used for the quality of captured high quality still images. The web interface was changing the still image quality as intended but displaying the thumbnail quality.

This is now fixed.

[btidey]

btidey, I sent You a PM regarding that topic as well. But perhaps there are some people who know more about streaming than the two of us. What I'm having in mind is that there isn't the need to make every .h264 file to .mp4 ... I mean seriously.. Who watches all of the videos anyway? Maybe I'm getting this wrong but perhaps the only time when someone wants to watch some certain video is when there is something suspicious going on (and usually user knows when it could be going on). Then one can transcode/transmux/?? the video to mp4.
So perhaps its reasonable to investigate ways of streaming raw h264 to web (so that it could be played in html video tag? or some other neat plugin) .. Perhaps VLC/ffmpeg should be used for that?


Also, after my rpi-update for some weird reason my build of raspimjpeg does not work.. any thoughts on that ?
Apparently something went wrong with config, no idea what...

I just did a full refresh update, upgrade rpi-update and still running OK. Are you getting errors logged (to scheduleLog.txt)? Is raspimjpeg running or does it die?

On the h264 to mp4 encoding, I don't think that is a big issue for the cases you are talking about. It is run in the background normally so has little impact. Although one could do it on demand when viewing a video one was interested in I think most users would be more upset about waiting for the conversion to complete if that still had to be done. The nice thing about using mp4 is it a fully supported web standard and the packaging means that all video details are included so that it can be easily decoded.

[bkcarter333]

Using: v5.1.3 on RPi B+

On the schedule setting screen if I change the GMT Offset it updates the current sunrise and sunset values, but leave the current time at GMT, and the period follows the GMT time. Is this a bug or by design. If I knew how to code it I would try to fix, but I'd be in WAY over my head! The local time is 8:09pm but the screen shows 02:09 as the current time.

Thanks

[xab]

Sorry, I was lazy with my phrasing.. what I was trying to say was that there was something wrong with raspimjpeg config. I got new config file from github and replaced paths + added my own settings and then it worked again... That's why I had no idea what was wrong.

[Stinnaz]

Hi all. Firstly I just want to say that this is my first experience of following a project since I bought my Pi, and it's certain helping me learn a few new things. I'd been looking around and trying a few Pi camera web streaming projects, but I couldn't get any of them to work very well. However, yours does almost everything I could have wanted and actually worked (almost) "out of the box". So well done for some amazing work here!

I just have a couple of questions and I have tried searching this post and the wiki, but with no luck:

1. How do I update to the latest version, or do I have to do a fresh install?

2. Whenever I try and change the image quality from 25 (which it always defaulted to and not 85 as stated) the number stays, but with no noticeable change to the video above. When I navigate away and back though it say 25 again. Am I missing something, or is this not even the streaming outputs quality but the quality if still images are captured?

Excuse my newbie questions, but I'm trying to learn as I go!

Thanks very much.

1. You can just run the installer script again. It refetches any changes from the git repository before proceeding. If you use 'install' on the end it will put all the changes in but you may lose any changes you have made to motion config or the default raspimjpeg config. You can also use 'update' instead of install; that only changes the code and leaves your configs alone but if there have been any additions to say the raspimjpeg file then they wouldn't get included.

2. There was a bug in the 'image quality'. There are actually two qualities internally; one used for thumbnail / live screen and one used for the quality of captured high quality still images. The web interface was changing the still image quality as intended but displaying the thumbnail quality.

This is now fixed.

Hi. Thanks for the reply. I'll try 1. later today then. With regards to 2. the image quality setting does set the quality of the live stream from the cam, not just the image captures?

Thanks very much.

[jussi24]

Hello btidey,

what's the "subdir_char" standig for? "Flattens the subfolder path for thumbnails"...??

subject behind: there are always two files created when activating "thumb_gen" with v, i and t. This disturbs my picture processing a little bit. But if I drop thumb_gen, I don't see any entries in the website download section any more although the snapshots were taken and stored in /var/www/media.
Maybe the thumbnails could be stored in a seperate subfolder? Is this what subdir_char means? How to use it?

Thanks!

[jussi24]

Important: A look into the future

I'd love the idea of letting the GPU do all the cost-intensive work. Is there enough power left in the GPU for the functions that are available today? E.g. i'm streaming with 800x600 a good looking mjpeg...

Side question (HD streaming is a subject of mine, as the above may have adumbrated): would it be a hard thing to have a real h264 preview stream? I played a bit around with some python scripts and had an example demo running that streamed h264 with almost the same latency as now with mjpeg...

Thanks!!!

[jussi24]

And once more me...

pushed/pulled mjpeg:
According to my latest observations the push version of mjpeg does not mean that the delivery of preview images is coupled to their origin. Means that (at dawn, with shutter_speed to 300000 e.g.) the pictures are taken about one per second but the stream is delivered with about 5 fps. Hoped that a pushed stream would save the used bandwith in that situations while still having a fast frame rate at daylight.

Did I misunderstand someting?

Thanks!

[xab]

Important: A look into the future

I played a bit around with some python scripts and had an example demo running that streamed h264 with almost the same latency as now with mjpeg...

Did you stream the raw video file? How did you view the stream?

[btidey]

Hi. Thanks for the reply. I'll try 1. later today then. With regards to 2. the image quality setting does set the quality of the live stream from the cam, not just the image captures?

Thanks very much.

Yes, thumbnails, live preview, and current motion detection are all based on the updating cam.jpg produced by raspimjpeg and there is a separate quality setting for that.

Maybe we should also allow adjusting that quality as well from the web interface. You can manually set it by changing the defaults in /etc/raspimjpeg but that change is likely to get lost every time you install a new update.

[btidey]

Hello btidey,

what's the "subdir_char" standig for? "Flattens the subfolder path for thumbnails"...??

subject behind: there are always two files created when activating "thumb_gen" with v, i and t. This disturbs my picture processing a little bit. But if I drop thumb_gen, I don't see any entries in the website download section any more although the snapshots were taken and stored in /var/www/media.
Maybe the thumbnails could be stored in a separate subfolder? Is this what subdir_char means? How to use it?

Thanks!

Thumbnails are currently what drives much of the web interface. They are stored in the root media folder. Initially all captures video, stills, time lapses were also stored there and that is still the default. Some users wanted to separate out the captures into different folders and that is possible by putting that in the video_path, image_path, lapse_path defintions in /etc/raspimjpeg providing they all live under media root. The sub-folder definitions can be fixed or made dynamic by moving say year and month into subfolder places in the definitions.

This is where the subdir_char comes in. Currently the web logic has to be able to tie a thumbnail to the associated capture files no matter where they are stored or how their name is constructed. There is no database or catalogue in the current system. So it does this by using the path to the capture and replacing the / by @ (subdir_char). That way the capture filename can be reconstructed from the thumbnail very easily.

So if you want to have a clean subfolder with just images and no thumbnails that is very easy. Just make the image_path /var/www/media/images/rest of name. Image thumbnails will now start images@ and everything will work as normal.

[Stinnaz]

Hi. Thanks for the reply. I'll try 1. later today then. With regards to 2. the image quality setting does set the quality of the live stream from the cam, not just the image captures?

Thanks very much.

Yes, thumbnails, live preview, and current motion detection are all based on the updating cam.jpg produced by raspimjpeg and there is a separate quality setting for that.

Maybe we should also allow adjusting that quality as well from the web interface. You can manually set it by changing the defaults in /etc/raspimjpeg but that change is likely to get lost every time you install a new update.

Thank you very much!

Now to update then, see what doesn't work and follow thru from there

On a separate note, I hope you don't mind me suggesting maybe adding a brief "How to upgrade to latest version" section to the Wiki.

Thanks again for your help.

[celinda]

i have one problem right now.

on_motion_detected i use this setting to get notification




but after i test i get many email in one time. sometime it can get around 20++ email.



is there an solution for this problem?

thank you

[xab]

i have one problem right now.

on_motion_detected i use this setting to get notification




but after i test i get many email in one time. sometime it can get around 20++ email.



is there an solution for this problem?

thank you

Try putting that email command at the end of the "on event start", it might help.. (I'm not sure how that event handling works..).
also , seperate commands with ";"

[btidey]

i have one problem right now.

on_motion_detected i use this setting to get notification




but after i test i get many email in one time. sometime it can get around 20++ email.



is there an solution for this problem?

thank you

I believe some have used that method OK, but my understanding is that motion fires that event when any frame has motion detected. If that is true then you can get multiple events.

What you could do instead is add your email call onto the end of the on_event_start call. Just add a semicolon followed your command

[btidey]

Using: v5.1.3 on RPi B+

On the schedule setting screen if I change the GMT Offset it updates the current sunrise and sunset values, but leave the current time at GMT, and the period follows the GMT time. Is this a bug or by design. If I knew how to code it I would try to fix, but I'd be in WAY over my head! The local time is 8:09pm but the screen shows 02:09 as the current time.

Thanks

The raspberry itself must have the correct timezone set up for this to work.

Configure the time zone using raspi-config and select your local time zone. You can put the same timezone string into the GMT offset field rather than a number to keep it simple. E.g. Europe/London

[btidey]

And once more me...

pushed/pulled mjpeg:
According to my latest observations the push version of mjpeg does not mean that the delivery of preview images is coupled to their origin. Means that (at dawn, with shutter_speed to 300000 e.g.) the pictures are taken about one per second but the stream is delivered with about 5 fps. Hoped that a pushed stream would save the used bandwith in that situations while still having a fast frame rate at daylight.

Did I misunderstand someting?

Thanks!

I think a lot of us lack understanding around exposure modes and fps! It's a very confusing area.

Setting for example night mode does make various changes to the internal settings of the camera including effective fps to lengthen exposures. However, these don't seem to apply to video captures which still use the specified video fps and that is why video captures can be very dark in comparison to the live picture.

The preview update rate is based on the video fps (with a divider setting from raspimjpeg). The divider by default is 1 so the updates try to take place at 25fps but I think are then limited by download speeds etc so you don't get that rate. You should however be able to up the divider to say 8 to slow down the rate of preview generation. Currently the divider is a config in /etc/raspimjpeg and isn't changeable from web i/f.

[jbeale]

According to http://elinux.org/RPi-Cam-Web-Interface the install procedure is:

Code: Select all

git clone https://github.com/silvanmelchior/RPi_Cam_Web_Interface.git
cd RPi_Cam_Web_Interface
chmod u+x RPi_Cam_Web_Interface_Installer.sh
./RPi_Cam_Web_Interface_Installer.sh install

I have done this at home and it works. The install procedure seems to require an active network connection. Is there any way to install this on a Pi that is not directly connected to the internet? I want to demonstrate this program on a machine at work, where the firewall allows the R-Pi to talk to my Win7 desktop, but not to access the internet directly on its own. So I can download the github archive as a .zip from Windows, and then SCP it over to the Pi, but then the installer wants to download all the dependencies (Apache, etc.) via network.

EDIT: I suspect the correct answer is: set it up at home, where the network actually works .

[silvanmelchior]

According to http://elinux.org/RPi-Cam-Web-Interface the install procedure is:

Code: Select all

git clone https://github.com/silvanmelchior/RPi_Cam_Web_Interface.git
cd RPi_Cam_Web_Interface
chmod u+x RPi_Cam_Web_Interface_Installer.sh
./RPi_Cam_Web_Interface_Installer.sh install

I have done this at home and it works. The install procedure seems to require an active network connection. Is there any way to install this on a Pi that is not directly connected to the internet? I want to demonstrate this program on a machine at work, where the firewall allows the R-Pi to talk to my Win7 desktop, but not to access the internet directly on its own. So I can download the github archive as a .zip from Windows, and then SCP it over to the Pi, but then the installer wants to download all the dependencies (Apache, etc.) via network.

EDIT: I suspect the correct answer is: set it up at home, where the network actually works .

You could also download all deb-packages that are installed with the apt-get install-command in the installer and install by hand, but together with the dependencies there are so many packages that this is very tedious.

[btidey]

I've expanded the change I put in to allow change of preview jpeg quality to allow changing the width and the divider ratio.

If the quality is reduced then the jpgs will be smaller decreasing loads around the system but going below 15 starts to introduce fairly visible degradation.

Width controls the size on the live screen but if increased the size of the images fed through to motion also increases and may also slow down the display of the capture preview page as the thumbnails will be slightly larger files.

The divider controls the rate at which the preview jpgs are produced based on the video frame rate. E.g. a default divider 1 and a video_frame rate of 25 fps tries to produce 25 new jpgs / sec. This was not necessarily the same as the rate at which data arrived at the browser. The MJPEG stream option did obey the divider but the default image loader used to try to load images as fast as it could no matter what the divider was. So even if divider was set to 4 (6 fps) then the loader ended up retrieving lots of repeated images. I have changed this so the image loader also obeys the divider and lowers the fetch rate. This may be used to significantly lower the data traffic at the expense of a little bit of smoothness of the live preview. THis does not change the quality of captures.

I have seen one lock up when changing the divider ratio which necessitated stopping and starting via the script commands. I am checking that out.

[jussi24]

Important: A look into the future

I played a bit around with some python scripts and had an example demo running that streamed h264 with almost the same latency as now with mjpeg...

Did you stream the raw video file? How did you view the stream?

There were some examples with the python raspberry pi camera classes. I altered them and, as said, played a little bit. Take a look here:
http://picamera.readthedocs.org/en/rele ... ng-capture
Client on the other side was vlc or browsers.

[xab]

There were some examples with the python raspberry pi camera classes. I altered them and, as said, played a little bit. Take a look here:
http://picamera.readthedocs.org/en/rele ... ng-capture
Client on the other side was vlc or browsers.

Without going head in to this topic.. What You're saying is that basically you can achieve streaming raw .h264 files to browsers without transcoding them to mp4? If this is the case then I think this should be used (since it should save some resources)

[jussi24]

There were some examples with the python raspberry pi camera classes. I altered them and, as said, played a little bit. Take a look here:
http://picamera.readthedocs.org/en/rele ... ng-capture
Client on the other side was vlc or browsers.

Without going head in to this topic.. What You're saying is that basically you can achieve streaming raw .h264 files to browsers without transcoding them to mp4? If this is the case then I think this should be used (since it should save some resources)

Not sure if I understand you correctly.
It's about live streaming, not file downloading. Streaming with h264 could save much bandwith in comparison to mjpeg. And thanks to the GPU-build-in encoder it costs no cpu power. Because I love having HD-quality streaming (bird's live viewing. Really ) this could be the way to get it.

[jussi24]

I think a lot of us lack understanding around exposure modes and fps! It's a very confusing area.

Setting for example night mode does make various changes to the internal settings of the camera including effective fps to lengthen exposures. However, these don't seem to apply to video captures which still use the specified video fps and that is why video captures can be very dark in comparison to the live picture.

The preview update rate is based on the video fps (with a divider setting from raspimjpeg). The divider by default is 1 so the updates try to take place at 25fps but I think are then limited by download speeds etc so you don't get that rate. You should however be able to up the divider to say 8 to slow down the rate of preview generation. Currently the divider is a config in /etc/raspimjpeg and isn't changeable from web i/f.

Thanks for these basics. I love knowing how things work and how they are combined.
Let's illuminate the point after creation of the preview jpgs. Regarding the output of cam_pic_new.php (pushed mjpeg). As you said the pushing of jpegs only follows the divider/fps settings, not the real creation of new images. Is it possible for future releases to get these two things in sync? New jpg in mjpeg stream when a new image is created? Of course with upper/lower limitation controls? This would make the fps preview rate dynamically and could save much ressources (bandwith) in dawn/dark situations.

[moononournation]

Seems great! I want to try it with webiopi for my new robot project!