Skip to main content
deleted 114 characters in body
Source Link
goldilocks
  • 60.1k
  • 17
  • 115
  • 230

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=14 A kernel interface with a build in HTTP(S) server.

Also refer to comments and updated answers on this page, which use the linux-projects UV4L driver that provides much better performance and quality.http://www.linux-projects.org/uv4l/tutorials/streaming-server/

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=14

Also refer to comments and updated answers on this page, which use the linux-projects UV4L driver that provides much better performance and quality.

A kernel interface with a build in HTTP(S) server.

http://www.linux-projects.org/uv4l/tutorials/streaming-server/

Copy edited (e.g. ref. <https://en.wiktionary.org/wiki/alot#Adverb> and <https://en.wiktionary.org/wiki/bottleneck#Noun>) - but more work is needed near "with its self" and "no difference on LAN". (its = possessive, it's = "it is" or "it has".)
Source Link

RPIRaspberry Pi Cam Web interface

A nice project by silvanmelchior that deploys a web server, dvr like, multi target streaming server. needNeeds more infoinformation

Streaming with mjpg is supported by almost all browsers, including IE 6Internet Explorer 6. AllotA lot of cameras used before h264H.264 used hardware mjpg, which essentially dumped jpgJPEG files as fast as possible into a folder while mjpg read the file into a buffer and deleted them. Some devices could achieve up to 25fps25 fps and even if you had a bad connection you would get at least 1fps1 fps.

Support for mjpg was dropped in HD cameras because the jpgJPEG file just got too large to stream over the internetInternet and h264H.264 is a much faster and better quality protocol.

Since we have no way to broadcast h264H.264 using the camera module nativly this seems like a viable fallback  ...

It is pretty much instant, but don't expect to get more than 1.5 fps fps. This is down to raspistill being extremely SLOOOW! Using the time-lapse function set to 100ms100 ms which should give us 10fps10 fps does not work because raspistill just chokes up and has serious performance issues within it selfitself.

  1. changeChange /tmp to use RAM for speed /etc/default/tmpfs - change RAMTMP=yes (This is an effort to increase fps, but raspistill just cannot keep with its self.)
  2. Reboot
  3. apt-get install git
  4. apt-get install libjpeg8-dev
  5. apt-get install libv4l-dev
  6. apt-get install imagemagick
  7. cd /usr/src, mkdir mjpg-streamer, cd mjpg-streamer ...
  8. git clone https://github.com/engine12/mjpg-streamer.git
  9. make USE_LIBV4L2=true clean all
  10. OPTIONAL If you have errors
  11. sudo ln -s /usr/include/libv4l1-videodev.h /usr/include/linux/videodev.h
  12. sudo ln -s /usr/include/lib4l2.h /usr/include/linux/lib4l2.h
  13. insideInside the makefile, comment out all the plugins except for input_file and output_http and do make again. I had allota lot of issues here.
  14. copyCopy the binary, mjpg_streamer and its plugins input_*.so and output_*.so to /usr/local/bin otherwise. Otherwise, run it direct from the src directory.
  15. Optional end
  16. mkdir /tmp/stream
  17. raspistill -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &
  18. LD_LIBRARY_PATH=./ ./mjpg_streamer -i "input_file.so -f /tmp/stream" -o "output_http.so -w ./www" (run this where the binary and plugins are)
  19. gotoGoto http://<IP-address>:8080
  20. Here are a few option, enjoy "live" streaming the old fashioned way ... supported by most browsers - modern, old and experimental.

I struggled to compile it for about for 5 hours.... sigh, but I think I will use this as I can access the stream from any phone and any browser. JustI just have to wait till we get better drivers... anotherAnother year or two. :(

No matter what quality I try, I get no faster or no slower than 1fps1 fps using stream. I used 720p and 1080p and only image quality gets better, but fps is no difference on LAN. I suppose smaller settings will help with WAN/3G or other radio transmissions.

raspistill writes the image to a single file. This could be a bottle neckbottleneck. It writes the file, mjpg strreamer reads it and deletes it causing a blocking I/O, so raspistill cannot write to the file.

The only thing I can think of is using raspivid piped into ffmpegFFmpeg that will create jpgJPEG files for us - I need to try this and possibly itsit's much faster than usign raspistill. I managed to get 25 fps fps at a shocking quality, and it was delayed about 10 seconds... tweakingTweaking the settings got me about 3 fps fps, but 100% cpuCPU. No hardware is being used to process the video stream...

raspivid -w 640 -h 480 -fps 25 -vf -t 86400000 -b 1800000 -o -  \ 
ffmpeg -i - \
    -f image2(?) \
    -c:v mjpeg \
    stream%d.jpg

I was also reading and found that we can use %d%d in the raspistill output file name. I wonder if that will boost the fps. Also JPG encoding is hardware accelerated in raspistill, so I am really struggling to figure out why itsit's so slow...

I got a staggering 2 FPS FPS using %d%d in the filename. For some reason, writing the jpgJPEG file is horribly slow from raspistill sigh. Sigh.

RPI Cam Web interface

A nice project by silvanmelchior that deploys a web server, dvr like, multi target streaming server. need more info

Streaming with mjpg is supported by almost all browsers, including IE 6. Allot of cameras used before h264 used hardware mjpg, which essentially dumped jpg files as fast as possible into a folder while mjpg read the file into a buffer and deleted them. Some devices could achieve up to 25fps and even if you had a bad connection you would get at least 1fps

Support for mjpg was dropped in HD cameras because the jpg file just got too large to stream over the internet and h264 is a much faster and better quality protocol.

Since we have no way to broadcast h264 using the camera module nativly this seems like a viable fallback  ...

It is pretty much instant but don't expect to get more than 1.5 fps. This is down to raspistill being extremely SLOOOW! Using the time-lapse function set to 100ms which should give us 10fps does not work because raspistill just chokes up and has serious performance issues within it self.

  1. change /tmp to use RAM for speed /etc/default/tmpfs - change RAMTMP=yes (This is an effort to increase fps but raspistill just cannot keep with its self)
  2. Reboot
  3. apt-get install git
  4. apt-get install libjpeg8-dev
  5. apt-get install libv4l-dev
  6. apt-get install imagemagick
  7. cd /usr/src, mkdir mjpg-streamer, cd mjpg-streamer ...
  8. git clone https://github.com/engine12/mjpg-streamer.git
  9. make USE_LIBV4L2=true clean all
  10. OPTIONAL If you have errors
  11. sudo ln -s /usr/include/libv4l1-videodev.h /usr/include/linux/videodev.h
  12. sudo ln -s /usr/include/lib4l2.h /usr/include/linux/lib4l2.h
  13. inside the makefile comment out all the plugins except for input_file and output_http and do make again. I had allot of issues here.
  14. copy the binary, mjpg_streamer and its plugins input_*.so and output_*.so to /usr/local/bin otherwise run it direct from the src directory.
  15. Optional end
  16. mkdir /tmp/stream
  17. raspistill -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &
  18. LD_LIBRARY_PATH=./ ./mjpg_streamer -i "input_file.so -f /tmp/stream" -o "output_http.so -w ./www" (run this where the binary and plugins are)
  19. goto http://<IP-address>:8080
  20. Here are a few option, enjoy "live" streaming the old fashioned way ... supported by most browsers - modern, old and experimental.

I struggled to compile it for about for 5 hours.... sigh but I think I will use this as I can access the stream from any phone and any browser. Just have to wait till we get better drivers... another year or two. :(

No matter what quality I try I get no faster or no slower than 1fps using stream. I used 720p and 1080p and only image quality gets better but fps no difference on LAN. I suppose smaller settings will help with WAN/3G or other radio transmissions.

raspistill writes the image to a single file. This could be a bottle neck. It writes the file, mjpg strreamer reads it and deletes it causing a blocking I/O so raspistill cannot write to the file.

The only thing I can think of is using raspivid piped into ffmpeg that will create jpg files for us - I need to try this and possibly its much faster than usign raspistill. I managed to get 25 fps at a shocking quality and it was delayed about 10 seconds... tweaking the settings got me about 3 fps but 100% cpu. No hardware is being used to process the video stream...

raspivid -w 640 -h 480 -fps 25 -vf -t 86400000 -b 1800000 -o -  \ 
ffmpeg -i - \
    -f image2(?) \
    -c:v mjpeg \
    stream%d.jpg

I was also reading and found that we can use %d in raspistill output file name. I wonder if that will boost the fps. Also JPG encoding is hardware accelerated in raspistill, so I am really struggling to figure out why its so slow...

I got a staggering 2 FPS using %d in the filename. For some reason writing the jpg file is horribly slow from raspistill sigh

Raspberry Pi Cam Web interface

A nice project by silvanmelchior that deploys a web server, dvr like, multi target streaming server. Needs more information

Streaming with mjpg is supported by almost all browsers, including Internet Explorer 6. A lot of cameras used before H.264 used hardware mjpg, which essentially dumped JPEG files as fast as possible into a folder while mjpg read the file into a buffer and deleted them. Some devices could achieve up to 25 fps and even if you had a bad connection you would get at least 1 fps.

Support for mjpg was dropped in HD cameras because the JPEG file just got too large to stream over the Internet and H.264 is a much faster and better quality protocol.

Since we have no way to broadcast H.264 using the camera module nativly this seems like a viable fallback...

It is pretty much instant, but don't expect to get more than 1.5 fps. This is down to raspistill being extremely SLOOOW! Using the time-lapse function set to 100 ms which should give us 10 fps does not work because raspistill just chokes up and has serious performance issues within itself.

  1. Change /tmp to use RAM for speed /etc/default/tmpfs - change RAMTMP=yes (This is an effort to increase fps, but raspistill just cannot keep with its self.)
  2. Reboot
  3. apt-get install git
  4. apt-get install libjpeg8-dev
  5. apt-get install libv4l-dev
  6. apt-get install imagemagick
  7. cd /usr/src, mkdir mjpg-streamer, cd mjpg-streamer ...
  8. git clone https://github.com/engine12/mjpg-streamer.git
  9. make USE_LIBV4L2=true clean all
  10. OPTIONAL If you have errors
  11. sudo ln -s /usr/include/libv4l1-videodev.h /usr/include/linux/videodev.h
  12. sudo ln -s /usr/include/lib4l2.h /usr/include/linux/lib4l2.h
  13. Inside the makefile, comment out all the plugins except for input_file and output_http and do make again. I had a lot of issues here.
  14. Copy the binary, mjpg_streamer and its plugins input_*.so and output_*.so to /usr/local/bin. Otherwise, run it direct from the src directory.
  15. Optional end
  16. mkdir /tmp/stream
  17. raspistill -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &
  18. LD_LIBRARY_PATH=./ ./mjpg_streamer -i "input_file.so -f /tmp/stream" -o "output_http.so -w ./www" (run this where the binary and plugins are)
  19. Goto http://<IP-address>:8080
  20. Here are a few option, enjoy "live" streaming the old fashioned way ... supported by most browsers - modern, old and experimental.

I struggled to compile it for about for 5 hours... sigh, but I think I will use this as I can access the stream from any phone and any browser. I just have to wait till we get better drivers... Another year or two. :(

No matter what quality I try, I get no faster or no slower than 1 fps using stream. I used 720p and 1080p and only image quality gets better, but fps is no difference on LAN. I suppose smaller settings will help with WAN/3G or other radio transmissions.

raspistill writes the image to a single file. This could be a bottleneck. It writes the file, mjpg strreamer reads it and deletes it causing a blocking I/O, so raspistill cannot write to the file.

The only thing I can think of is using raspivid piped into FFmpeg that will create JPEG files for us - I need to try this and possibly it's much faster than usign raspistill. I managed to get 25 fps at a shocking quality, and it was delayed about 10 seconds... Tweaking the settings got me about 3 fps, but 100% CPU. No hardware is being used to process the video stream...

raspivid -w 640 -h 480 -fps 25 -vf -t 86400000 -b 1800000 -o -  \
ffmpeg -i - \
    -f image2(?) \
    -c:v mjpeg \
    stream%d.jpg

I was also reading and found that we can use %d in the raspistill output file name. I wonder if that will boost the fps. Also JPG encoding is hardware accelerated in raspistill, so I am really struggling to figure out why it's so slow...

I got a staggering 2 FPS using %d in the filename. For some reason, writing the JPEG file is horribly slow from raspistill. Sigh.

added 260 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105

RPI Cam Web interface

A nice project by silvanmelchior that deploys a web server, dvr like, multi target streaming server. need more info

https://github.com/silvanmelchior/RPi_Cam_Web_Interface

Legacy method

Legacy method

RPI Cam Web interface

A nice project by silvanmelchior that deploys a web server, dvr like, multi target streaming server. need more info

https://github.com/silvanmelchior/RPi_Cam_Web_Interface

Legacy method

added 274 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 180 characters in body; Post Made Community Wiki
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 147 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 236 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 212 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 1273 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 251 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 165 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
deleted 283 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 152 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 152 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
added 32 characters in body
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading
Source Link
Piotr Kula
  • 17.3k
  • 6
  • 66
  • 105
Loading