So I got the Raspberry Camera today and got stills working fine.
Capture an image in JPEG format:
raspistill -o image.jpg
Capture a 5-second video in H.264 format:
raspivid -o video.h264
I do not want to install any extra application as I want to leverage HTML5 that is readily available. Since Chrome/Safari has built-in decoders for H.264 I just want to point my browser to the URL and watch the stream.
How can I achieve this?
Apple's proprietary method of streaming live video. It is called HTTP Live Streaming (HLS) and is only supported by Apple's technology. Google (Chromium / YouTube) uses its own implementation called dash mpeg and everybody else is either confused or using H.264 encapsulated in MP4.
PROS
.m3u8 playlistsCONS
m3u8
.m3u8 is simply a UTF-8 version of the M3U format. (.m3u files can have various encodings.) Some people claim that renaming a .m3u8 to .m3u will work as expected on all HTML5 browsers. I tried this, and it did not work for me.The concept behind this streaming is that short segments of files, at least 5 seconds long (in this example - it possible new ways are available to speed it up) are recorded and saved to a proper file. The playlist file is updated with the new file name and the client always polls this playlist and downloads the most recent file. There are some mechanics involved to merge the video seamlessly on the client. This is why other developers do not want to implement this because it requires a a lot of effort and does not comply with HTML5 standards (even though there is no proper HTML5 standard for live streams?? Ehh, sigh).
Installing
You need to compile ffmpeg - do not use apt-get installfor FFmpeg
This can take up to 5 hours - It has to be version 1.1 or higher which supports segment streaming. You can use this to clone it and compile it.
cd /usr/src
git clone git://source.ffmpeg.org/ffmpeg.git
cd ffmpeg
./configure
make && make install
/usr/share/nginx/www/Make a Bash script file called something like video.sh, apply chmod +x to it and put paste this in. Change the base folder to where ever your HTTP server lives. I used nginx, /usr/share/nginx/www/
#!/bin/bash
base="/data/live"
cd $base
raspivid -n -w 720 -h 405 -fps 25 -vf -t 86400000 -b 1800000 -ih -o - \
| ffmpeg -y \
-i - \
-c:v copy \
-map 0:0 \
-f ssegment \
-segment_time 4 \
-segment_format mpegts \
-segment_list "$base/stream.m3u8" \
-segment_list_size 720 \
-segment_list_flags live \
-segment_list_type m3u8 \
"segments/%08d.ts"
trap "rm stream.m3u8 segments/*.ts" EXIT
# vim:ts=2:sw=2:sts=2:et:ft=sh
Create a HTML file that will load the playlist
<html>
<head>
<title>PiVid</title>
</head>
<body>
<video controls="controls" width="1280" height="720" autoplay="autoplay" >
<source src="stream.m3u8" type="application/x-mpegURL" />
</video>
</body>
</html>
Support
Original code: https://github.com/AndyA/psips/blob/master/examples/hls.sh
-segment_wrap 10 as an argument to ffmpeg it will use max 10 segment files.
segments/ when pointing to the segment-files, so I dropped the segments folder. Did I misunderstand something?
Thanks to comment from @mpromonet for the update on the Linux-Projects V4L2 driver that now implements MMAL very efficiently - but it is still a work in progress.
Follow these instructions to install the linux-project repository and install the UV4L driver with extras. Then install the server and mjpeg. If you want, you can experiment with the others too.
After you install everything, you can access the HTTP server on port 8080. You should also check the /etc/uv4l/conf file and set if you want mjpeg or H.264 as it makes a difference, but you can adjust a few settings via the built-in web server.
This is what we were all waiting for (called WebRTC) and thanks to the new driver it works great (on a Raspberry Pi 2).
First, follow these steps, http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=14:
curl http://www.linux-projects.org/listing/uv4l_repo/lrkey.asc | sudo apt-key add -
# Add the following line to the file /etc/apt/sources.list
# deb http://www.linux-projects.org/listing/uv4l_repo/raspbian/ wheezy main
sudo apt-get update
sudo apt-get install uv4l uv4l-raspicam
sudo apt-get install uv4l-raspicam-extras
Then on your Raspberry Pi 2 install this the WebRTC (for a Raspberry Pi 1, read the linked site for other options)
sudo apt-get install uv4l-webrtc
Restart all the drivers and go to
http://raspberry:8080/
You now have low-latency, high-quality video streaming direct into a modern browser like Chrome or Firefox. (Maybe Safari, but I can't check because they don't do Winblows any more and Internet Explorer... eh)
By default, it uses mjpeg at 1080p, and it's very sluggish. I tweaked it to 800x600 framesize and using something like iSpy to process video. For security, I get about 10 fps on a crisp video. It is way better than the 3 fps at 640x480 before this driver. It works on iPhone with Safari, Android Chrome and almost everything else.
http://raspberrypi:8080/stream/video.mjpeg
This also means that motion should (I still need to test and compare) work a lot better now. Make sure to set the configuration to use v4l2_palette 8 or v4l2_palette 2
This has now been fixed for "streaming", and we don't have to go to great lengths to watch H.264 video through VLC media player. The stream is sill RAW H.264, so you need to demux it or transcode/ encapsualte if you need it to work somewhere else. You should tweak the bitrate=xxxxxx in the configuration file if you are streaming over Wi-Fi.
In VLC media player, you must tell it that you want to use the H.264 demuxer. So if you're using the GUI, then make sure to add the argument :demux=264. From command line, vlc http.../video.h264 --demux h264. Otherwise, you will just see a blank screen even though the camera LED is turned on.
http://raspberrypi:8080/stream/video.h264
Voila! HD streaming with roughly 500 ms lag (with tweaking, down to 200 ms). It is definitely much easier than using the old methods. Quality and FPS is superb, but you can't embed this in HTML5 without transcodding to MP4 or WebM. I hope this will be implemented as it will truly make this a great standalone server.
Not supported/implemented
http://www.linux-projects.org/uv4l/tutorials/rtsp-server/
Not supported/implemented
There is no video4linux driver availabe yet. This means that we can't use ffserver to stream data using /dev/video0 or simlar like a USB webcam.
That is why it is so difficult to find proper live streaming for HTML5 browsers.
Gstreamer (not HTML5)<OBJECT ... :) (delayed)
video4linux driver the official V4L2 driver bcm2835-v4l2 and the userspace V4L2 driver [linux-projects.org/modules/sections/…
Commented
Oct 11, 2014 at 22:35
--demux h264 flag. We still need to transcode this for use on mobile or embedding as mp4/webm on webpages. But it is really great move forward in efficiently and quality. Dont confuse with the "other" UV4L non linux-project driver thing that is rubbish.
Commented
Oct 24, 2014 at 7:50
/usr/bin/cvlc v4l2:///dev/video0 --v4l2-width 800 --v4l2-height 400 --v4l2-chroma h264 --sout '#standard{access=http,mux=ts,dst=0.0.0.0:8080}' :demux=264
As of 2017 (or perhaps earlier) raspivid is no longer the preferred method, with the Pi devs recommending people use V4L2 instead.
So this method allows you to stream H264 via RTP using V4L2 instead of raspivid. I noticed this method results in fewer dropouts and allows a higher bitrate:
#!/bin/sh
# Use V4L2 (preferred) instead of raspivid
# exposure_dynamic_framerate=1 (raspivid --fps 0) - reduce framerate/increase exposure in low light
# scene_mode=8 (raspivid --exposure night) - allow framerate reduction to increase exposure
v4l2-ctl -v width=1296,height=972,pixelformat=H264 \
--set-ctrl=exposure_dynamic_framerate=1 \
--set-ctrl=video_bitrate=5000000 \
--set-ctrl=scene_mode=8
exec ffmpeg -f h264 -probesize 32 -r 30 -i /dev/video0 -vcodec copy -an -f rtp_mpegts udp://224.0.1.2:5004
This script multicasts the video, and it can be viewed on another machine on the LAN with a command like this:
ffplay -sync ext -an -fast -framedrop -probesize 32 -window_title "Raspberry Pi" -an udp://224.0.1.2:5004
-sync ext causes the video to be played as fast as possible so it will run in real time, as opposed to running it at a fixed framerate and lagging if the Pi is capturing frames faster than this. There's still some lag with this method, but no worse than the other raspivid methods.
(Tip: if you're plugged into a router or switch that supports IGMP, make sure 224.0.0.0/4 is not firewalled on your machine, otherwise when the router asks your PC whether it wants any multicast traffic the PC will never respond and you'll never see any video.)
As I mentioned recording in the comments below, I'll expand on that here. You can use a command like this to record the network stream to disk:
ffmpeg -y -i udp://224.0.1.2:5004 -c copy \
-f segment -segment_atclocktime 1 -segment_time 900 \
-reset_timestamps 1
-strftime 1 /path/to/storage/pi-%wT%H%M.mkv
Look at man strftime for the meanings of the % symbols in the filename. The ones in this example use the day number (0=Sunday, 1=Monday, etc.) followed by a T and then the time. It starts a new file every 15 minutes.
Just to be clear, this recording command is meant to be run on a remote PC (not on the Pi itself) although it will probably work on the Pi too (untested).
Since you get a new file every 15 minutes with the day and time in the filename, it means that after one week you'll start to get filenames generated that have already been used, causing the oldest files to get overwritten. In other words, you'll end up with a rolling loop of the previous week's worth of footage. This is ideal for a security camera where you will rarely need to go back more than a week.
As a side note this produces about 500GB worth of files, so you may want to adjust the bitrate, resolution, or overwrite the files sooner (say every 24 hours) if you don't want them taking up so much space.
ffserver or some other server system if you want more than one machine to display the feed. Then after maybe 2-3 clients (depending on the video bitrate) the Pi's USB Ethernet adapter will run out of bandwidth. With multicast there's no need to run a server (client machines just choose whether to listen to the traffic or ignore it) so you can have thousands of machines displaying the video with no impact on the Pi, which only ever sends out a single video stream.
Commented
Mar 20, 2017 at 23:58
raspivid was only meant to be a demo, and now V4L2 supports everything raspivid does.
Commented
Jan 29, 2020 at 23:39
U4VL
A kernel interface with a build in HTTP(S) server.
http://www.linux-projects.org/uv4l/tutorials/streaming-server/
Raspberry Pi Cam Web interface
A nice project by silvanmelchior that deploys a web server, dvr like, multi target streaming server. Needs more information
https://github.com/silvanmelchior/RPi_Cam_Web_Interface
Legacy method
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.
/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.)/usr/src, mkdir mjpg-streamer, cd mjpg-streamer ...git clone https://github.com/engine12/mjpg-streamer.gitmake USE_LIBV4L2=true clean allsudo ln -s /usr/include/libv4l1-videodev.h /usr/include/linux/videodev.hsudo ln -s /usr/include/lib4l2.h /usr/include/linux/lib4l2.hmjpg_streamer and its plugins input_*.so and output_*.so to /usr/local/bin. Otherwise, run it direct from the src directory.mkdir /tmp/streamraspistill -w 640 -h 480 -q 5 -o /tmp/stream/pic.jpg -tl 100 -t 9999999 -th 0:0:0 &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)http://<IP-address>:8080I 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.
I managed to stream from my Raspberry Pi to a web server with the compiled-in module nginx-rtmp.
To save hassles with ffmpeg, I recommend a rolling distribution like Arch Linux Arm.
raspivid -vf -t 0 -fps 25 -b 2000000 -o - |
ffmpeg -i - -vcodec copy -an -r 25 -f flv rtmp://x220/myapp/mystream
Some notes:
So on this basis, I think live streaming from a Raspberry Pi might be OK for a temporary broadcast, but not for an always-on Web cam since it's too bandwidth-hungry. You will not get audio and if you do, it will a mission to sync.
You can record audio more efficiently separately at the same time as recording video. Then later perhaps mux the audio feed in later and convert it to WebM and put it on your httpd as a static file with an HTML video tag. The workflow is pretty awkward, though it's the best I can think of for an efficient broadcast that will work painlessly across browsers.
Piotr Kula's answer seems to be on the right track but is outdated for Raspberry stretch.
There are updated instructions for uv4l on Raspberry stretch at
https://www.linux-projects.org/uv4l/installation/
# switch to superuser mode
sudo -s
# add the repository key for uv4l
curl http://www.linux-projects.org/listing/uv4l_repo/lpkey.asc | sudo apt-key add
# add the url for the u4vl repository to apt
echo "deb http://www.linux-projects.org/listing/uv4l_repo/raspbian/stretch stretch main" >> /etc/apt/sources.list
apt-get update
apt-get install uv4l uv4l-raspicam
apt-get install uv4l-raspicam-extras
# do not forget to install the server - see what happens if you do
# below
apt-get install uv4l-server
reboot
You can tweek the uv4l options via /etc/uv4l/uv4l-raspicam.conf and then restart the service with
sudo service uv4l_raspicam restart
In my case things didn't work out of the box (if forgot to install the uv4l-server ...). The following comments might help you debug similar problems.
I checked that the server is running with:
pgrep -fla uv4l
995 /usr/bin/uv4l -f -k --sched-fifo --mem-lock --config-file=/etc/uv4l/uv4l-raspicam.conf --driver raspicam --driver-config-file=/etc/uv4l/uv4l-raspicam.conf --server-option=--editable-config-file=/etc/uv4l/uv4l-raspicam.conf
and whether it listened with
sudo netstat -tulpn
but there was no entry for uv4l in the list. I had expected one for port 8080
so i tried the command from How to configure UV4L?
uv4l --sched-rr --mem-lock --driver raspicam \
> --width 960 --height 540 --framerate 30 \
> --encoding mjpeg --vflip --hflip
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct 6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 960x544, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Registering device node /dev/uv4l
But still the server didn't start automatically ...
man uv4l
then showed me the option
--enable-server [=arg(=required)] (=auto)
enable the streaming server. Possible values are: 'auto' (tenta‐
tively start the server), 'required' (exit if failing to start
the server, only works if --foreground is enabled), 'off' (no
server at all).
so I tried:
pkill uv4l
sudo uv4l --sched-rr --mem-lock --driver raspicam --encoding mjpeg --enable-server=required
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct 6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 1920x1080, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Registering device node /dev/uv4l
but still no server running on port 8080 or elswhere. So it seems i forgot the "--foreground" option which the man page states is necessary:
sudo uv4l --sched-rr --mem-lock --driver raspicam --encoding mjpeg --enable-server=required --foreground
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct 6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 1920x1080, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Trying to load the the Streaming Server plug-in...
<warning> [core] libserver.so: cannot open shared object file: No such file or directory
<alert> [core] No Streaming Server detected
Now that's a clear hint! There seems to be no server yet - so install it:
sudo apt-get install uv4l-server
and try again:
sudo uv4l --sched-rr --mem-lock --driver raspicam --encoding mjpeg --enable-server=required --foreground
<notice> [core] Trying to loading driver 'raspicam' from built-in drivers...
<notice> [core] Loading driver 'raspicam' from external plug-in's...
<notice> [driver] Dual Raspicam & TC358743 Video4Linux2 Driver v1.9.63 built Oct 6 2018
<notice> [driver] Detected camera imx219, 3280x2464
<notice> [driver] Selected format: 1920x1080, encoding: mjpeg, JPEG Video Capture
<notice> [driver] Framerate max. 30 fps
<notice> [core] Device detected!
<notice> [core] Trying to load the the Streaming Server plug-in...
<notice> [server] HTTP/HTTPS Streaming & WebRTC Signalling Server v1.1.125 built on Mar 9 2019
<warning> [server] SSL is not enabled for the Streaming Server. Using unsecure HTTP.
<notice> [core] Streaming Server loaded!
<notice> [core] Registering device node /dev/uv4l
<notice> [server] Web Streaming Server listening on port 8080
The server is now available at http://pi:8080 (replace pi with your server's ip or hostname)
After a reboot it worked with out entering another command.
UV4L now supports live Audio & Video Streaming with WebRTC and HTML5.
UV4L now supports live audio & video broadcasting to Jitsi Meet Rooms over the Web. No special configuration is required. It's as easy as filling your name, room and clicking on Start.
webkitRTCPeerConnection is not defined error. I normally use IceWeasel for WebRTC, but that is not supported for Jitsi.
Commented
Sep 17, 2015 at 10:28