Seit 2009 ist der Nistkasten live "auf Sendung" als Webcam - zunächst noch über ein Netbook mit USB-Videoadapter und Webcam-Software, später dann über einen kleinen Videoserver.
Anfangs wurde das Bild der Kamera alle 10 Sekunden per FTP auf den Webserver hochgeladen, während es auf der Webseite per JavaScript ebenfalls im 10-Sekunden-Takt immer wieder neu geladen wurde. Mittlerweile beträgt das Aktualisierungs-Intervall nur noch 2 Sekunden, und das Bild wird dazu auch nicht mehr per FTP hochgeladen, sondern direkt vom Videoserver geholt. Den FTP-Upload nutze ich nun im Zusammenhang mit der integrierten Bewegungserkennung des Videoservers: Immer wenn eine ausreichend starke Veränderung des Bildinhaltes erkannt wird, wird das Bild in eine Fotogalerie auf dem Webserver hochgeladen.
Inhaltsverzeichnis
Einleitung
Zur Einbindung der aktuellen Kamerabildes in die Webseite verwende ich derzeit einen Videoserver. Hierbei handelt es sich um ein kleines Gerätchen von 8,5 x 3,5 x 3 cm mit Video- und Netzwerk-Anschluß, das autonom arbeitet, nur sehr wenig Strom verbraucht und nicht auf einen ständig laufenden Rechner angewiesen ist. Angeschlossen an einen freien LAN-Port des DSL-Routers, über den die Internetverbindung hergestellt wird, stellt er die Bilder der Nistkasten-Kamera im Internet bereit. Durch ein in die Webseite eingebettetes JavaScript wird das aktuelle, vom Videoserver gelieferte Kamerabild in regelmäßigen Zeitabständen abgerufen und angezeigt. Einen "echten" Video-Stream kann ich derzeit wegen meines begrenzten DSL-Upstreams (nur 512 kBit/s) nicht anbieten.
Die Konfiguration der einzelnen Komponenten (DSL-Router, Videoserver und Webseite) wird in den folgenden Abschnitten detailliert beschrieben.
DSL-Router
Der DSL-Router (in meinem Fall eine FRITZ!Box Fon WLAN 7170 von AVM) stellt unabhängig vom PC die Internetverbindung her und erlaubt so den Betrieb des Videoservers, auch ohne daß dafür der Rechner laufen muß. Der Vidoserver wird dazu einfach per LAN-Kabel an den Router angeschlossen und kann darüber ins Internt.
DSL-Router AVM FRITZ!Box Fon WLAN 7170
Konfiguration
Wenn der Videoserver ständig von außen über das Internet erreichbar sein soll, z.B. um den direkten Audio/Video-Stream über das Internet zugänglich zu machen, oder um ohne den Umweg über FTP-Uploads direkt auf die Einzelbilder der Kamera zugreifen zu können (wie in meinem Fall), dann muß der DSL-Router zuvor passend konfiguriert werden. Wer nur die Einzelbilder der Kamera durch den Videoserver in regelmäßigen Abständen per FTP hochladen lassen möchte, um sie in die Webseite einzubinden, braucht sich damit nicht auseinanderzusetzen und kann dieses Kapitel überlesen und sofort zum Kapitel "Videoserver" springen.
Damit der Videoserver trotz der täglichen Neuvergabe der IP-Adresse durch den Zugangs-Provider immer unter demselben Namen im Internet erreichbar ist, kann man einen DynDNS-Dienst benutzen. Dieser leitet Anfragen an einen Servernamen, den man sich selbst aussuchen kann, an die eigene IP-Adresse weiter, auch wenn sich diese durch die täglichen "Zwangstrennungen", die es bei vielen DSL-Providern noch gibt, ständig ändert. Um den Dienst nutzen zu können, kann man sich bei DynDNS.com anmelden und kostenlos einen Domainnamen einrichten, z.B. "meinserver.dyndns.org". Diesen Namen und die Anmeldedaten trägt man dann unter "Freigaben" / "Dynamic DNS" in die Fritzbox-Konfiguration ein:
Wenn nun die Internetverbindung getrennt und wieder neu aufgebaut wird, sendet die Fritzbox automatisch die aktuelle IP-Adresse an den DynDNS-Dienst. Sollte der DSL-Router keine Möglichkeit bieten, einen DynDNS-Dienst zu benutzen, dann kann dieser ggf. auch beim Videoserver eingerichtet werden.
2. Internet-Verbindung
In den Internet-Verbindungseinstellungen sollte eingestellt sein, daß die Internetverbindung dauerhaft gehalten wird, damit der Videoserver immer erreichbar ist. Wenn der Provider alle 24 Stunden eine Zwangstrennung der Internetverbindung vornimmt, kann man außerdem ein Zeitfenster angeben, in dem dies geschehen soll (in diesem Beispiel 6-7 Uhr):
3. Port-Freigaben
Da die Fritzbox eine Firewall für eingehende Verbindungen integriert hat, müssen die Ports des Videoservers dort freigegeben werden, damit er von außen erreichbar ist. Hierzu habe ich die UDP-Ports 5001-5003 für den Audio- und Videostream (den ich allerdings nicht nutze) und den HTTP-Port 80 freigegeben. Diese Angaben finden sich im Handbuch des Videoservers. Der Port 80 des Videoservers wird von der Fritzbox nach außen hin als 8001 freigegeben, weil ich unter Port 80 manchmal den Apache-Webserver laufenlasse. Der Videoserver ist dadurch unter der Adresse "meinserver.dyndns.org:8001" erreichbar (als Beispiel).
4. Priorisierte Anwendungen
Wenn der Videoserver auch bei voll ausgelasteter Internetverbindung immer gut erreichbar sein soll, kann man ihn unter "Priorisierung" als "Priorisierte Anwendung" eintragen:
Videoserver
An den Videoserver ist die Kamera (bzw. in meinem Fall über die Umschaltbox die beiden Kameras) angeschlossen. Dieser digitalisiert das analoge PAL-Videosignal und bereitet es als Video-Stream im Format H.264, als Motion-JPEG-Stream (MJPEG) und als einzeln abrufbare JPEG-Standbilder auf, auf die dann über das Netzwerk "empfangen" werden können. Dazu ist der Videoserver per LAN-Kabel an die Fritzbox angeschlossen. Die Kamera ist an den Videoserver und parallel dazu an die TV-Karte (Hauppauge WinTV PCI-FM) meines Rechners angeschlossen, sodaß ich das Live-Bild mit Ton auch direkt am PC ansehen und ggf. mitschneiden kann (hierzu benutze ich die Software Debut Video Capture von NCH, allerdings in der älteren Version 1.42, die noch Freeware ist).
Als Videoserver verwende ich derzeit den AXIS M7001, das kleine weiße Kästchen im Vordergrund:
Videoserver AXIS M7001
Da der AXIS M7001 über das Netzwerkkabel mit Strom versorgt wird, ist zudem ein POE-Netzteil ("POE-Injector") erforderlich. Ich verwende hierzu den DIGITUS DN-95101, das etwa dreimal so große, schwarze Kästchen hinter dem Videoserver.
Leider mußte ich schnell feststellen, daß auch ein Markengerät wie der AXIS M7001 nicht frei von groben Firmware-Bugs ist, die umständliche Workarounds notwendig machen. Eine Übersicht über die verschiedenen, bisher von mir getesteten Videoserver und meine "Erfahrungen" damit habe ich auf einer eigenen Seite zusammengestellt, da diese den Rahmen dieser Beschreibung sprengen würden...
Konfiguration
Nach dem Anschließen bezieht der Videoserver vom Router per DHCP automatisch eine lokale IP-Adresse und ist somit im Netzwerk erreichbar. Vor der ersten Inbetriebnahme müssen jedoch noch einige Einstellungen vorgenommen werden, wie beispielsweise die Vergabe eines Paßwortes für den Administrations-Benutzer "root", die Einstellung der Videoparameter (Auflösung, Helligkeit, Kontrast, Farbe), oder die Aktivierung bestimmter Funktionen wie das bewegungserkennungs- oder zeitgesteuerte Hochladen von Bildern auf einen Webserver.
Für meinen Anwendungsfall habe ich den Videoserver so konfiguriert, daß bei Bewegungserkennung automatisch Bilder per FTP auf den Webserver hochgeladen werden, wo sie in einer Bilder-Galerie angezeigt werden. Für das Live-Bild auf der Startseite wird per JavaScript ca. alle 2 Sekunden ein aktuelles Standbild direkt vom Videoserver geholt.
Alle Einstellungen werden über die Web-Oberfläche des Videoservers vorgenommen. Dazu gibt man in die Adreßzeile seines Lieblings-Browsers die lokale IP-Adresse des Videoservers ein und klickt sich durch die Konfigurations-Menüs. Einige der wichtigsten Einstellungen des AXIS M7001 führe ich im Folgenden exemplarisch auf:
(Bemerkungen zu den Einstellungen sind mit grüner Schriftfarbe gekennzeichnet.)
Basic Setup
Users
User List
User Name: root , User Group: Administrator (Der Administrator-Benutzer "root" wird automatisch angelegt; ein Paßwort muß beim ersten Start eingegeben werden.)
User Settings
Enable anonymous viewer login (no user name or password required)
(Hierdurch wird zum Abruf des Kamerabildes kein Login benötigt.)
TCP/IP (unverändert)
Date & Time
New Server Time
(Setzt Datum und Uhrzeit des Videoservers. Leider verstellt sich die Zeit immer wieder, nachdem man diverse andere Einstellungsmenüs aufgerufen hat, was zur Folge hat, daß der Zeitstempel im Dateinamen des per FTP hochgeladenen Bildes und der im Bild eingeblendete Zeitstempel nicht mehr stimmen. Nachdem die Videoserver-Zeit über dieses Konfigurationsmenü korrigiert wurde, sollte der Server sofort neu gestartet werden, da andernfalls trotz richtiger Serverzeit die Zeitstempel im Bild und im Dateinamen falsch sind! *bang-head-here*)
Time zone: GMT+1 (Amsterdam, Berlin, Rome, Stockholm, Warsaw) (do sin mer ze Huss)
Automatically adjust for daylight saving time changes.
Synchronize with NTP server NTP server: 0.de.pool.ntp.org
Date & Time Used in Images
(Bestimmt das Format, in dem Datum und Uhrzeit im Bild eingeblendet werden. Ob Datum und Zeit tatsächlich eingeblendet werden, hängt allerdings von der Einstellung "Overlay Settings" im Menü "Video Stream" (s.u.) ab.)
Specify date format: Own %d.%m.%Y (entspricht der deutschen Schreibweise, z.B. 31.12.2011)
Specify time format: Own %H.%M.%S (entspricht der deutschen Schreibweise, z.B. 23:59:59)
Video Stream: Image
Image Appearance
Resolution: Aspect ratio correction (korrigiert das Seitenverhältnis zu 4:3) / 4CIF (768 × 576) (Ich lasse das Bild vom Videoserver doppelt so groß ausgeben, wie es auf der Webseite dargestellt wird. Dadurch ist das Bild schärfer, als wenn es bereits durch den Videoserver in halber Größe (384 × 288) ausgegeben werden würde. Mehr dazu hier.)
Compression: 50 (Bestimmt die JPEG-Komprimierung. Bei halber Bildgröße (384 × 288) sollte der Wert 15 gewählt werden.)
Overlay Settings
Include date / Include time
(Das Einfügen von Datum und Zeit in das Bild habe ich deaktiviert, da sich die Videoserver-Zeit aufgrund eines Firmware-Bugs häufig verstellt. Stattdessen wird der aktuelle Zeitstempel über ein Script auf dem Webserver eingefügt. Mehr dazu hier.)
Text color: white / Text background color: semitransparent
Place text/date/time at top of image
Video
Video Stream (siehe "Basic Setup")
Stream Profiles (unverändert)
Camera Settings
Image Appearance
Color level: 95 (Die Sättigung wurde sehr hoch eingestellt, um die schwachen Farben der Kamera auszugleichen.)
Brightness: 65
Contrast: 80
Image Appearance
4CIF de-interlacing: (Vermeidet Artefakte bei schnellen Bewegungen.)
Privacy Mask (unverändert)
Events
Event Servers
(Hier kann mittels "Add FTP" ein FTP-Server angelegt werden, auf den die Bilder bei Bewegungserkennung automatisch hochgeladen werden. Da das FTP-Paßwort unverschlüsselt übertragen wird, ist es ratsam, hierfür einen eigenen Account auf dem FTP-Server anzulegen und den Zugriff auf das Upload-Verzeichnis, das dort als Unterverzeichnis angelegt wird, zu beschränken.)
FTP Server
Name: Galerie
Network address: www.meinserver.de (Hostname oder IP-Adresse des FTP-Servers)
Upload path: /gallery (Verzeichnis/Ordner, in dem die hochgeladenen Bilder abgelegt werden sollen)
Port number: 21 (Standardwert für FTP)
Login Information
User name: benutzername (Benutzername zur Anmeldung an den FTP-Server)
Password: passwort (Paßwort zur Anmeldung an den FTP-Server)
Advanced Settings
Use passive mode: (normalerweise nicht erforderlich)
Use temporary file: (sinnvoll, damit keine unvollständigen Bilder angezeigt werden)
Event Types
(Hier können Ereignisse definiert werden, bei denen etwas geschehen soll, z.B. daß zeitgesteuert oder bei Erkennung von Bewegungen im Bild Bilder oder Videosequenzen auf einen FTP-Server hochgeladen werden sollen. Um das zeitgesteuerte Hochladen von Bildern, z.B. alle 10 Sekunden, zu aktivieren, kann mittels "Add scheduled" ein zeitgesteuertes Ereignis definiert werden. Ich habe dies bisher jedoch nicht getestet und kann deshalb hier keine Beispielwerte angeben. Stattdessen habe ich mittels "Add triggered" einen Ereignistyp für Bewegungserkennung hinzugefügt:)
In window: Nest when motion detection starts (Hier den Namen des unter "Motion Detection" definierten Bewegungserkennungs-Fenstern auswählen.)
When Triggered...
Save stream (Schnappschüsse speichern) (Die folgenden 4 Einstellungen bestimmen, wie oft und wann bei Auslösung durch Bewegungserkennung Schnappschüsse erstellt werden.)
Image frequency: 1 frame(s) per second(s) (1 Bild pro Sekunde sollte reichen...)
Include pre-trigger buffer 1 second(s) (Schnappschüsse vor der Bewegungserkennung)
Include post-trigger buffer 1 second(s) (Schnappschüsse nach der Bewegungserkennung)
Continue image upload (unbuffered) (Schnappschüsse während der Bewegungserkennung) Upload for 1 second(s) Upload as long as the trigger is active
(Ich habe den Eindruck, daß die Schnappschüsse vor und nach der Bewegungserkennung weniger unscharf werden als die während der Bewegungserkennung, weswegen ich nur die ersteren beiden Häkchen gesetzt habe.)
Select type: FTP
Upload to FTP server
Primary: Galerie (Hier den Namen des FTP-Servers auswählen, der unter "Event Servers > FTP Server > Name" eingegeben wurde.)
Create folder: %Y-%m-%d (Dies bewirkt, daß die Bilder in einem nach dem aktuellen Datum benannten Unterverzeichnis landen, das dazu ggf. zuvor erstellt wird, z.B. "2011-06-01" für den 1. Juni 2011.)
Base file name: %y%m%d_%H%M%S_#s.jpg (Hierdurch erhält jedes hochgeladene Bild einen eindeutigen Dateinamen mit dem aktuellen Zeitstempel (Datum und Uhrzeit) und einer Sequenznummer, z.B. 110601_144330_00011.jpg für ein am 01.06.2011 um 14:43:30 Uhr hochgeladenes Bild mit der Sequenznummer 11.)
Overwrite/Use own file format.
(Damit das unter "Base file name" angegebene Dateinamens-Format auch benutzt wird.)
Motion Detection
(Hier können mittels "Add Window" verschiedene Bereiche/Fenster innerhalb des Kamerabildes definiert werden, innerhalb derer Bewegungen registriert werden. Ich habe ein verkleinertes Fenster namens "Nest" definiert, das lediglich das Nest, aber nicht die Nistkasten-Wände erfaßt. (Bei dem vorgegebenen maximierten "Default Window" ergaben sich zu häufige Auslösungen der Bewegungserkennung.) Mit 3 Schiebereglern kann für jedes Fenster die Empfindlichkeit eingestellt werden, bei der die Bewegungserkennung auslöst und einen Schnappschuß erstellt. Diese Werte müssen experimentell ermittelt werden, damit die Bewegungserkennung weder zu oft noch zu selten anspricht. Leider werden bei den Schiebereglern keine direkten Prozentwerte angezeigt; die genannten Werte stammen daher aus der Konfigurationsdatei des Videoservers.)
Motion Detection
Include / Exclude
Fenstername: Nest
Object Size: 15%
History: 60%
Sensitivity: 78%
Webseite
Nachdem der Videoserver läuft, geht es nun darum, das vom Videoserver gelieferte Kamera-Bild als "bewegtes Bild" in die Webseite einzubinden. Da meine DSL-Bandbreite (512 kBit/s Upload-Geschwindigkeit) nicht ausreicht, um einen echten Live-Stream anzubieten, habe ich die bandbreitenschonendere Lösung gewählt, bei der ein in die Webseite eingebundenes Standbild alle paar Sekunden durch den Browser aktualisiert wird. Hierzu gibt es verschiedene Möglichkeiten, von denen im Folgenden drei vorgestellt werden:
Automatische Aktualisierung des Webcam-Bildes per JavaScript
Das vom Videoserver per FTP regelmäßig hochgeladene Bild – oder alternativ das aktuelle Standbild direkt aus dem Videoserver – kann sehr einfach mit z.B. <img src="autoupload/video.jpg"> in die Webseite eingebunden werden. Allerdings würde ein Besucher so immer nur das zuletzt hochgeladene Bild sehen. Um ein neues, aktuelles Bild zu sehen, müßte er die Seite neu laden. Damit das automatisch geht, kann man in die Seite ein kleines JavaScript einbetten, das das regelmäßige Neuladen des Bildes (nicht der ganzen Seite) vornimmt. Hierbei sollte das Intervall des Neuladens dem Intervall entsprechen, mit dem der Videoserver seinerseits die Bilder hochlädt, also z.B. 10 Sekunden. Des weiteren sollte bedacht werden, daß das regelmäßige Aktualisieren des Bildes Netzwerklast ("Traffic") verursacht. Manche Webspace-Provider geben hier eine Begrenzung pro Monat vor - vor allem bei kleineren Webspace-Paketen. So ein Bild hat ca. 10-12 KB; wenn es alle 10 Sekunden neu geladen wird, macht das 3,5 MB pro Stunde. Wenn nun 10 Besucher die Seite 24 Stunden am Tag geöffent hätten, wären das schon 250 GB im Monat (falls ich mich jetzt nicht verrechnet habe). Aus diesem Grund ist es sinnvoll, die maximale Übertragungsdauer für die Webcam-Bilder zu begrenzen, z.B. auf eine halbe Stunden oder auch 10 Minuten. Nach Ablauf dieser Zeit erscheint statt des Kamerabildes eine statisches Bild und in der Statuszeile unter dem Bild der Hinweis "Übertragung beendet" sowie ein Link zum Neustarten der Übertragung.
// Script zum automatischen Laden des Webcam-Bildes in bestimmten Zeitabständen:// Konfiguration
var nUpdateInterval = 10; // Aktualisierungs-Intervall in Sekunden
var nMaxSeconds = 1800; // Anzahl Sekunden bis zum Übertragungsende
var strSnapshotUrl = "autoupload/video.jpg"; // URL zum Webcam-Bild
var strStopImageUrl = "webcam_stop.jpg"; // URL zum Bild "Übertragungsende"
var strErrorImageUrl = "webcam_error.jpg"; // URL zum Bild "Fehler beim Laden"// Initialisierung
var nEndTime = (new Date()).getTime() + nMaxSeconds * 1000;
var nRefreshTime = (new Date()).getTime();
function SnapshotRefresh()
{
nRefreshTime = (new Date()).getTime();
if(nRefreshTime < nEndTime)
{
// Webcam-Bild
document.images.webcam.src = strSnapshotUrl + "?" + nRefreshTime;
// Statuszeile
document.getElementById('statustext').innerHTML = ' ';
}
else
{
// Webcam-Bild
document.images.webcam.src = strStopImageUrl;
// Statuszeile
document.getElementById('statustext').innerHTML =
'Übertragung beendet [<a href="" onClick="SnapshotRestart(); return false;">Neu starten</a>]';
}
}
function SnapshotSchedule()
{
if(nRefreshTime < nEndTime)
{
var nCurrentTime = (new Date()).getTime();
var nTimeSpanSinceLastRefresh = nCurrentTime - nRefreshTime;
var nTimeSpanWait = nUpdateInterval * 1000 - nTimeSpanSinceLastRefresh;
if(nTimeSpanWait < 0)
nTimeSpanWait = 0;
setTimeout('SnapshotRefresh()', nTimeSpanWait);
}
}
function SnapshotError()
{
document.images.webcam.src = strErrorImageUrl;
}
function SnapshotRestart()
{
nEndTime = (new Date()).getTime() + nMaxSeconds * 1000;
SnapshotSchedule();
}
Die fett gekennzeichneten Angaben sollten den eigenen Gegebenheiten angepaßt werden; die Bedeutung dieser Variablen ist in den grünen Kommentaren rechts daneben angegeben.
Dieses Script wird z.B. unter dem Namen "webcam.js" auf den Webspace hochgeladen und mit den folgenden Anweisungen in den Abschnitt zwischen <head> und </head> der Webseite einbunden:
Das Kamerabild bindet man an der gewünschten Stelle zwischen <body> und </body> wie folgt ein, wobei die fett markierten Angaben für Breite (width) und Höhe (height) des Bildes an die tatsächlichen Pixel-Abmessungen des Kamerabildes angepaßt werden sollten:
Automatische Aktualisierung des Webcam-Bildes per Java- oder Flash-Applet
Anstelle des JavaScripts können auch Java- oder Flash-Applets benutzt werden, um das Webcam-Bild in regelmäßigen Abständen neu zu laden und anzuzeigen. Ein möglicher Vorteil gegenüber JavaScript wäre, daß hierbei das ständige Flackern der Statuszeile bzw. der Lade-Fortschrittsanzeige des Browsers unterbunden wird, das beim regelmäßigen Laden des Bildes per JavaScript auftritt. Da die verfügbaren Applets keine Funktion zur zeitlichen Begrenzung der Übertragung enthalten, kann man jedoch auf JavaScript nicht ganz verzichten.
Zu den bisher beschriebenen Methoden zum automatischen Neuladen des Webcam-Bildes per JavaScript sind diverse Verbesserungen und Erweiterungen denkbar, wie z.B.:
1. Umgehen der Authentifizierung des Videoservers bei Direktzugriff auf das Kamerabild
Der direkte Zugriff auf das aktuelle Standbild der an den Videoserver angeschlossenen Kamera erfolgt normalerweise über eine Bild-URL, z.B. "http://meinserver.dyndns.org:8001/cgi-bin/video.jpg". Hierüber ließe sich z.B. das Webcam-Bild wunderbar in eine Webseite einbinden, ohne den Umweg über FTP-Uploads gehen zu müssen. Manche Videoserver wie z.B. der VIVOTEK VS3100P bieten jedoch keinen anmeldefreien Zugriff auf den Videostream oder das Standbild. Versucht man nun, über den Browser die Bild-URL aufzurufen, oder ruft man eine Webseite auf, in der das Standbild über die o.g. Bild-URL direkt eingebunden ist, wird man mit einem Anmelde-Dialog konfrontiert, der einen zur Eingabe von Benutzername und Paßwort auffordert. Selbst wenn kein Paßwort angegeben werden muß, erscheint trotzdem dieser Authentifizierungs-Dialog. Den naheliegenden Versuch, Benutzername und ggf. Paßwort direkt in der URL anzugeben (z.B. http://benutzername:passwort@meinserver.dyndns.org:8001/cgi-bin/video.jpg), betrachten die meisten heutigen Browser als Sicherheitsrisiko und zeigen deshalb eine unschöne Sicherheits-Warnmeldung an, die ein Besucher der Webseite immer erst "wegklicken" müßte.
Die clientseitige Authentifizierung läßt sich mit Hilfe eines kleinen Perl-Scripts, das bei Aufruf via CGI diese HTTP-Authentifizierung vornimmt und das Webcam-Bild an den Browser zurücksendet, umgehen:
#!/usr/bin/perl
use strict;
use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
$ua->timeout(10);
$ua->credentials("meinserver.dyndns.org:8001", "Video Server", "benutzername", "passwort");
my $response = $ua->get("http://meinserver.dyndns.org:8001/cgi-bin/video.jpg");
if($response->is_success)
{
print "Content-type: image/jpg\n\n";
binmode(STDOUT);
print $response->content;
}
else
{
print "Location: /nistkasten/webcam_error.png\n\n";
}
exit 0;
Die fett gekennzeichneten Angaben (Server-Adresse und ggf. hinter einem Doppelpunkt die Portnummer, falls abweichend von 80; Hostname des Videoservers - hier "Video Server"; Benutzername; Paßwort; Bild-URL des Videoservers; Pfad zu einem Fehlerbild, das statt des Kamerabildes angezeigt wird, falls keine Verbindung zum Videoserver aufgebaut werden kann) müssen natürlich den eigenen Erfordernissen gemäß angepaßt werden. Dieses Script lädt man dann z.B. unter dem Namen "webcam.pl" in den Ordner "cgi-bin" des Webservers hoch (im ASCII-Modus!) und versieht es mit Ausführungsrechten (chmod a+x webcam.pl). Auf der Webseite kann dann das aktuelle Kamerabild einfach über die URL http://www.meineseite.de/cgi-bin/webcam.pl abgerufen werden.
Gegenüber dem regelmäßigen Upload des Bildes per FTP hat diese Methode den Vorteil, daß nur dann Daten übertragen werden, wenn tatsächlich jemand "guckt". Ein weiterer Vorteil ist, daß man nicht auf vorgegebene Update-Intervalle des Webservers angewiesen ist (manche Videoserver, wie z.B. der VIVOTEK VS7100, lassen z.B. als Upload-Intervalle nur ganzahlige Minuten-Werte zu). Stattdessen bestimmt der Client (also die im Browser des Zuschauers geladene Webseite), in welchen zeitlichen Abständen das Bild aktualisiert wird. Die maximale Aktualisierungsfrequenz hängt allerdings auch stark von der Geschwindigkeit der Internetverbindung ab, da das Bild ja zuerst vom Videoserver durch die DSL-Leitung zum Webserver und von dort wieder zurück zum Browser des Benutzers übertragen werden muß. Viel mehr als 1 Bild pro Sekunde wird man damit wohl nur unter optimalen Bedingungen erzielen können.
Ein Nachteil dieses sehr einfachen Scripts ist, daß die vom Videoserver zum Webserver übertragene Datenmenge proportional mit Anzahl der gleichzeitigen Zuschauer anwächst, wodurch der Upstream der DSL-Verbindung, an der der Videoserver hängt, schnell ausgeschöpft sein kann. Mit der im folgenden Abschnitt vorgestellten erweiterten Version des Scripts wird dieses Problem gelöst.
2. Begrenzung der Upstream-Datenmenge durch serverseitige Zwischenspeicherung des Webcam-Bildes
Der Nachteil des oben beschriebenen, einfachen Perl-Scripts zum direkten Download des Kamera-Bildes vom Videoserver ist, daß das Bild für jeden einzelnen Zuschauer separat über die DSL-Verbindung gesendet wird, an der der Videoserver hängt. Bei einem Update-Intervall von 2 Sekunden und einer Bildgröße von 10 KB gingen so bei 10 gleichzeitigen Zuschauern durchschnittlich schon 400 kBit/s über die Leitung. Ein DSL-Upstream von (wie in meinem Fall) 512 kBit/s würde da schnell an seine Grenzen stoßen. Um die Datenmenge, die über die eigene DSL-Leitung gesendet wird, zu begrenzen, kann man das Webcam-Bild serverseitig cachen (zwischenspeichern) und nur dann vom Videoserver abrufen, wenn es älter als z.B. 1 Sekunde ist. Auf diese Weise gehen unabhängig von der Anzahl der gleichzeitigen Zuschauer maximal 80 kBit/s über die DSL-Leitung.
Trotz 7 gleichzeitiger Zuschauer bleibt der Upstream hier immer unterhalb von 100 kBit/s
Die normale Video-Auflösung bei PAL-Signalen beträgt 768 × 576 Pixel und ist für manche Webseiten vielleicht schon zu groß. Auch sind viele Kameras nicht hochauflösend genug, um diese Auflösung ausnutzen zu können, wordurch das Bild unscharf wirkt. Daher bieten die meisten Videoserver die Möglichkeit, kleinere Auflösungen einzustellen, z.B. halb so groß (384 × 288 Pixel). Leider gibt es aber Videoserver (wie z.B. der AXIS M7001), bei denen hierdurch die Bildqualität trotz geringer JPG-Komprimierung schlechter ist als wenn man das Originalbild mit z.B. einem Grafikprogramm verkleinern würde, d.h. der Videoserver verwendet einen qualitativ minderwertigen Umrechnungs-Algorithmus. Auch hier kann man sich zum Glück behelfen, indem man das vom Videoserver gelieferte Originalbild (768 × 576 Pixel) mit Hilfe eines serverseitigen Perl-Scripts verkleinert und dann ausgibt. Das Resultat ist ein merklich detailreicheres Bild, erkennbar z.B. an den feinen Härchen des weißen Polstermaterials im Nest unten links:
Originalbild: 4CIF (768 × 576), Compression: 50, Größe: 31 KB, per GD::Image->copyResized verkleinert auf 384 × 288 (41 KB)
Es wäre theoretisch auch möglich, andere Bildwerte wie Helligkeit, Kontrast, Sättigung und Gammawert mit Hilfe des Perl-Scripts weiter anzupassen und sogar automatisch zu optimieren. Erste Versuche in dieser Richtung sahen auch erfolgversprechend aus und funktionierten auf meinem lokalen PC, liefen aber auf dem öffentlichen Webserver (Strato) nur sehr langsam (ein Aufruf dauerte mehrere Sekunden; vermutlich laufen die Scripts auf den Strato-Servern nur mit sehr niedriger Priorität).
Normalerweise bieten Videoserver die Option, in das Webcam-Bild den aktuellen Zeitstempel (Datum und Uhrzeit) einzublenden. Nicht immer ist die Darstellung des Zeitstempels aber optimal, z.B. wenn das Datum nur in englischer Schreibweise angezeigt wird, oder wenn er ungünstig plaziert oder zu klein oder groß ist oder aus sonstigen Gründen nicht geeignet ist. Manche Videoserver, wie z.B. der AXIS M7001, zeigen gar einen falschen Zeitstempel im Bild an, weil sich die Serverzeit aus unerfindlichen Gründen spontan verstellt. Um Abhilfe zu schaffen, könnte man den Zeitstempel einfach selbst per Perl-Script in das Bild einblenden. Hierzu wird einfach die aktuelle Zeit des Webservers genommen, auf dem das Perl-Script ausgeführt wird, nach Belieben formatiert und in das Bild gezeichnet, bevor es ausgegeben wird. Im Beispiel-Bild wurde der Zeitstempel mit halbtransparentem Hintergrund links oben in das Bild eingefügt:
Webcam-Bild mit eingeblendetem Zeitstempel (oben links)
Zur Anzeige der Zahl gleichzeitiger Zuschauer auf der Webseite könnte man dem Perl-Script eine Nummer mitgeben, die für jeden gleichzeitigen Zuschauer unterscheidlich ist. Dies könnte einfach eine Zufallszahl sein, die zu Beginn der Übertragung per JavaScript ermittelt und dann bei jedem Abruf des aktuellen Kamerabildes als URL-Parameter an das Perl-Script übergeben wird (z.B. http://www.meineseite.de/cgi-bin/webcam.pl?id=12345). Das Script schreibt dann diese eindeutige Nummer (ID) zusammen mit einem aktuellen Zeitstempel in eine Logdatei auf dem Webserver. Zur Ermittlung der Anzahl gleichzeitiger Zuschauer wird diese Logdatei dann ausgewertet. Hierzu wird einfach geschaut, wieviele unterscheidliche IDs innerhalb eines zurückliegenden Zeitfensters von z.B. 10 Sekunden in der Logdatei enthalten sind. Diese Zahl entspricht theoretisch der Anzahl gleichzeitiger Zuschauer.
Die so ermittelte Zahl wird dann vom Perl-Script oben rechts mit halbtransparentem Hintergrund in das Webcam-Bild eingeblendet:
Webcam-Bild mit eingeblendeter Anzahl Zuschauer (oben rechts)
Zu den Punkten 2. bis 5. hier ein entsprechendes Beispiel:
Die bei Bewegungserkennung automatisch erstellten Schnappschüsse werden vom Videoserver in ein Verzeichnis /gallery/Jahr-Monat-Tag auf dem Webserver hochgeladen, wobei Jahr, Monat und Tag dem Datum des jeweiligen Schnappschusses entsprechen. (Das Verzeichnis /gallery/2011-06-01 z.B. steht also für den 1. Juni 2011.) Somit landen alle Schnappschüsse eines Tages automatisch in einem Tagesverzeichnis. Auf der Website werden die Bilder mit Hilfe eines Perl-Scripts in Form einer Fotogalerie dargestellt, die automatisch anhand der auf dem Webserver vorhandenen Verzeichnisstruktur erstellt wird:
Die Bilder-Galerie im verkleinerten Firefox-Fenster
Die Verzeichnisse mit den Bildern erscheinen dabei auf der linken Seite als "Alben". Durch die Benennung der Tagesverzeichnisse nach Jahr-Monat-Tag lassen sich diese leicht so sortieren, daß die Alben mit den aktuellsten Bildern immer ganz oben erscheinen. Die Alben selbst enthalten die Bilder in chronologischer Reihenfolge, aufgeteilt auf Seiten mit maximal 100 Bildern. Die Bilder werden außerdem automatisch in zeitlich zusammengehörige Bildsequenzen unterteilt, damit man z.B. einzelne Besuche des Nistkastens leichter unterscheiden kann. Hierzu wird einfach der Zeitstempel jedes Bildes mit dem des vorherigen Bildes verglichen. Liegt mehr als eine Minute dazwischen, dann beginnt eine neue Sequenz. Der Zeitstempel der Bilder kann dabei anhand des letzten Änderungsdatums der Datei oder anhand des Dateinamens ermittelt werden (individuell für jedes Album einstellbar). Ersteres ist geeignet für den automatischen Bilder-Upload bei Bewegungserkennung, da hier die Dateien ungünstig benannt sind; Letzteres verwende ich für die Tages-Alben, bei denen die Bilder nach dem Muster "JahrMonatTag_StundeMinuteSekunde_LaufendeNummer.jpg" (z.B. "20110301_071245_1.jpg") benannt sind.
Was das Galerie-Script derzeit noch nicht kann, ist das Anzeigen von Vorschaubildern sowie von Texten (Titel und Bildbeschreibung) zu den Bildern. Vielleicht kommt das ja irgendwann noch...
Wer das Galerie-Script verwenden will, kann es sich gerne hier herunterladen. Die Zip-Datei enthält eine Beispiel-Galerie aus 2 Alben mit je 3 Bildern zum Testen. Darin sind auch die HTML-Templates enthalten, die nach Belieben angepaßt werden können. Es können dort z.B. auch eigene Stylesheets eingebunden werden. Die Startdatei für die Galerie ist das Frameset "galerie.htm". Zum Ausprobieren am besten einfach das komplette Verzeichnis "Beispielgalerie" auf den Webserver ins Wurzelverzeichnis und das Perl-Script "autogallery.pl" ins Verzeichnis "cgi-bin" hochladen. Je nach Konfiguration des Webservers kann die Endung des Scripts auch in ".cgi" geändert werden; allerdings muß dies dann auch in den HTML-Templates geändert werden. Wie jedes CGI-Script benötigt auch dieses Ausführungsrechte, was man mit dem FTP-Programm erledigen kann. Wichtig ist auch, daß das Script im ASCII-Modus hochgeladen wird, da ansonsten der Webserver meckert.
Wenn statt der Beispiel-Galerie eine eigene Galerie angelegt werden soll, müssen die entsprechenden Pfade in dem Abschnitt "Konfiguration" des Perl-Scripts und in den HTML-Templates eingetragen werden. Bei mehreren Galerien empfiehlt es sich, mehrere angepaßte Versionen des Scripts und der dazugehörigen Templates in jeweils eigene Unterverzeichnisse zu legen.
Die Parametrisierung des Galerie-Scripts erfolgt weitestgehend über URL-Parameter, die Befüllung der HTML-Templates durch das Script anhand von Template-Variablen (z.B. @@ALBUM_NAME@@ für den Album-Namen oder <image>/</image> für ganze Zeilen-Bereiche – in diesem Fall ein Bild). Eine Doku hierzu existiert leider noch nicht – am besten einfach die Beispiele ansehen, dann kommt man sicherlich schon irgendwie dahinter... ;-)
