[Details einblenden]

[Details ausblenden]

1. Benutzer und Paßwörter

Unter "Security" sollte man zunächst ein Root-Paßwort vergeben, da ansonsten jeder von außen an der Konfiguration des Videoservers herumspielen könnte. Wenn Besucher von außen auf den Videostream oder das Kamerabild zugreifen können sollen, kann man zusätzliche Benutzer einrichten oder durch Setzen des entsprechenden Häkchens dem Benutzer "demo" (ohne Paßwort) lesenden Zugriff erlauben.

 

2. FTP-Server für automatische Bilder-Uploads

Als nächstes sollte unter "Network" ein FTP-Server konfiguriert werden, auf den die Kamerabilder in regelmäßigen Abständen - oder alternativ durch den Bewegungsmelder ausgelöst - hochgeladen werden:

 

Wenn es sich um den Webserver handelt, auf dem auch die Homepage liegt, dann empfehle ich, dort aus Sicherheitsgründen einen neuen FTP-Zugang anzulegen, der ausschließlich für das Hochladen der Kamerabilder verwendet wird und der nur in ein Unterverzeichnis auf dem Server schreiben darf, z.B. "/autoupload". Da bei FTP-Anmeldungen Benutzername und Paßwort unverschlüsselt "im Klartext" durch das Internet gesendet werden, könnte ansonsten ein böser Hacker den Benutzernamen und das Paßwort mitlesen und so z.B. den Server hacken. So kann er sich nur an den Kamerabildern vergreifen.

Die Länge für Benutzername und Paßwort des FTP-Servers ist auf 14 Zeichen begrenzt, was in den meisten Fällen ausreichen sollte – so zumindest wird sich der Hersteller das wohl gedacht haben. Leider beträgt der FTP-Benutzername bei meinem Webspace mindestens 15 Zeichen, daher mußte ich auf einen anderen Webserver ausweichen und das Bild quasi "Website-übergreifend" einbinden.

Der VIVOTEK VS3100P bietet zwar die Möglichkeit, zwei FTP-Server anzugeben, aber aus einem mir unverständlichen Grund benutzt er immer nur den ersten davon. Es wäre schön gewesen, wenn man die Bilder auf zwei Server gleichzeitig hochladen könnte, z.B. auf einen Webserber im Internet und zusätzlich auf den FTP-Server der Fritzbox mit angeschlossenem USB-Speicherstick. Leider spielt aber auch hier der VIVOTEK VS3100P seine Schwächen voll aus und läßt dies nicht zu. ;->

3. Bewegungserkennung

Wenn die Kamerabilder nur bei Erkennung einer Bewegung im Bild hochgeladen werden sollen, dann muß nun die Bewegungserkennung konfiguriert werden. Hierzu geht man ins Menü "Motion detection", aktiviert das obere Häkchen, legt ein Fenster an, zieht es auf die richtige Größe, gibt ihm einen Namen (hier: "alles", weil ich das Fenster maximal groß gemacht habe) und stellt die Schieberegler durch Ausprobieren so ein, daß Bewegungen von Meisenvögeln zwar noch zuverlässig erkannt werden, aber nicht gleich jede Fliege eine Bilderflut auslöst:

 

4. Betriebsart

Zu guter Letzt kann man noch im Konfigurationsmenü "Application" angeben, unter welchen Bedingungen Bilder automatisch per FTP hochgeladen oder bei Bedarf auch per E-Mail verschickt werden sollen. Mögliche Auslöser hierfür sind:

• Elektrische Signale an einem der beiden Alarm-Eingänge des Videoservers. Hier könnte man z.B. einen "echten" Infrarot-Bewegungsmelder oder einen elektromechanischen Kontakt anschließen.
• Die integrierte Bewegungserkennung des Videoservers, die allerdings nur auf Änderungen des Bildinhaltes reagiert, z.B. auch auf Helligkeitsänderungen, und die dementsprechend viele Fehlauslösungen produziert.
• Zeitliche Intervalle (regelmäßig alle x Sekunden).

 

Erst einmal sollte hier durch Setzen des Häkchens vor "All the time..." angegeben werden, daß es keine zeitliche Einschränkung geben soll. Nun kann man wählen, ob man a) einen ereignisgesteuerten (also z.B. durch Bewegungserkennung ausgelösten) Upload des aktuellen Kamerabildes durchführen möchte, oder b) einen regelmäßigen Upload alle x Sekunden. Im Fall a) hakt man "Event operation" und unter "Trigger condition" bei "Detect motion in:" das zuvor angelegte Fenster für die Bewegungserkennung an (in meinem Fall "alles") an. Im Fall b) hakt man "Sequential operation" an und gibt unter "Snapshot every" ein, alle wieviel Sekunden (z.B. 10) das aktuelle Kamerabild per FTP hochgeladen werden soll. Schließlich wählt man noch "Send snapshots by FTP" aus. Wenn man das Kamerabild unter einem unveränderlichen Namen in die Webseite einbinden möchte, sollte man auf jeden Fall das Häkchen bei "FTP put snapshots with date and time suffix" entfernen. Ohne dieses Häkchen ist das Bild unter dem immer gleichen Namen "video.jpg" erreichbar, mit Häkchen wird der Dateiname durch den aktuellen Zeitstempel erweitert (z.B. "videotrg20110304065840.jpg"), was sich nicht verlinken ließe.

[Details einblenden]

[Details ausblenden]

FTP-Benutzername zu kurz

Beim diesem Videoserver läßt sich zwar nun einstellen, ob an die Namen der hochgeladenen Dateien ein Zeitstempel-Suffix angehängt werden soll oder nicht, jedoch hat sich nach Inbetriebnahme leider herausgestellt, daß die Länge des FTP-Benutzernamens für den Upload der Snapshots auf 14 Zeichen begrenzt ist; ich brauche jedoch mindestens 15 Zeichen, da sich bei meinem Webhoster die Benutzernamen der FTP-Accounts aus einem variablen Teil von mindestens einem Zeichen Länge und einem fixen Teil von in meinem Fall 14 Zeichen Länge zusammensetzen. Es ist also bei diesem Gerät nicht möglich, die FTP-Accountdaten meines Webspace-Providers für den automatischen Bilder-Upload einzugeben. Als Workaround blieb nur, auf einen anderen FTP-Server auszuweichen, bei dem der Benutzername nicht länger als 14 Zeichen ist. Eine neue Firmware wird es laut Support nicht mehr geben, da das Gerät "schon" 3 Jahre auf dem Markt ist und nicht mehr verbessert wird. Statt dessen wurde mir zu dem 80 Euro teureren Nachfolgemodell VS7100 geraten, das erstaunliche 64 Zeichen lange FTP-Benutzernamen unterstützt. Dieses hätte allerdings andere Einschränkungen gehabt (s.u.).

Kein Live-Stream

Eine weitere Einschränkung des VIVOTEK VS3100P betrifft die Tatsache, daß er keinen M-JPEG-Stream anbietet, sondern nur einen H.263-Stream in irgend einem propritären Format, das sich nur mittels ActiveX im Internet-Exploder unter Windoze darstellen läßt. Daher dachte ich mir, daß es doch über ein serverseitiges Perl-Script möglich sein müßte, die Einzelbilder in Form eines M-JPEG-Streams auszugeben. Bei einem M-JPEG-Stream handelt es sich schließlich um nicht viel mehr als um aneinandergereihte, einzelne JPG-Bilder, zwischen denen jeweils ein Header eingefügt wird. Das Einbinden des M-JPEG-Streams in die Webseite müßte alledings mittels Flash- oder Java-Applet erfolgen, da nur die wenigsten Browser von sich aus M-JPEG-Streams darstellen können (z.B. Firefox und Chrome). Hier ist die Auswahl an verfügbaren Applet allerdings äußerst rar - auch nach langem Suchen bin ich nur auf Cambozola gestoßen, das zwar gut funktioniert, jedoch nicht "signiert" ist, weshalb die Java-Runtime-Umgebung beim ersten Start eine unschöne, benutzerverwirrende Sicherheits-Warnmeldung anzeigt. Also nichts, was man in eine Startseite einbinden sollte. Außerdem mußte ich leider feststellen, daß mein Webspace-Provider die Laufzeit von Perl-Scripts auf 120 Sekunden begrenzt hat, d.h. der Stream würde nach max. 2 Minuten abbrechen. Somit ist serverseitiges M-JPEG-Streamimg zwar eine schöne Idee, die auch auf meinem lokalen Apache gut funktioniert, aber für die praktische Anwendung im Web leider unbrauchbar ist.

Ständige Abstürze

Doch dies waren nicht die einzigen Mängel des VIVOTEK VS3100P. Das Hauptproblem war, daß er sich - wie auch der von Grandtec - ständig "aufhing" und dann nichts mehr tat außer Strom in Wärme zu verwandeln.

Solange der Videoserver zeitgesteuert alle 10 Sekunden Bilder per FTP auf den Webserver hochlud, lief er über lange Zeit (Wochen bis Monate) weitestgehend stabil. Nur wenn die Internetverbindung unterbrochen wurde, während gerade ein FTP-Upload im Gange war, hing er sich manchmal auf und mußte dann kurz vom Strom genommen werden, damit er weitermachte. Da das nur sporadisch auftrat und ich es nicht immer sofort bemerkte, installierte ich auf dem Webserver einen alle 15 Minuten aufgerufenen cronjob, der mit Hilfe dieses Shellscripts das Alter der hochgeladenen Datei überprüfte und eine E-Mail schickte, wenn die Datei älter als 10 Minuten war.

Seit ich jedoch die Bewegunkserkennungs-Funktion aktiviert hatte, um die Bilder in eine Fotogalerie auf dem Webserver hochzuladen, hing er sich mehrmals pro Stunde auf. Aus diesem Grund griff ich erst mal zu der naheliegendsten Notlösung und schloß das Netzteil des Videoservers an eine Zeitschaltuhr an, die den Videoserver regelmäßig alle 2 Stunden für 1 Minute aus- und anschließend wieder einschaltete:

AEG-Methode: Ausschalten - Einschalten - Geht wieder!
 

Leider wurde durch diese "Brachialmethode" der Server auch dann neu gestartet, wenn es gar nicht nötig war; andererseits konnte es bis zu 2 Stunden dauern, bis er neu gestartet wurde, wenn er dann tatsächlich mal hing. Besser wäre daher eine "intelligente" Automatik, die den Server nur dann neu start, wenn er auch wirklich hängt. Eine Möglichkeit hierzu wäre, das Blinken der grünen "Heartbeat-LED" des Videoservers auszuwerten. Im Normalbetrieb blinkt diese LED mit 1 Hz vor sich hin; wenn der Server hängt, ist sie entweder dauerhaft an oder dauerhaft aus. Man bräuchte also bloß das Blinken auszuwerten und - wenn es ausbleibt - ein Relais anansteuern, das die Stromversorgung des Servers kurz unterbricht. Die Umsetzung dieser Methode resultierte in der Entwicklung des "Videoserver-Lifeguard".

Eine andere Idee zu einem Automatismus für Neustarts bei Hängern war, die Digital-Ein-/Ausgänge des Videoservers zu nutzen: Wenn man den Videoserver so konfigurieren würde, daß er auf eine Änderung des Eingangspegels mit dem Schalten des Relais reagiert, könnte man das mit einer kleinen Zusatzschaltung auswerten. Diese Schaltung müßte dazu alle paar Minuten den Eingang auf "H" setzen und schauen, ob der Ausgang durchschaltet. Wenn nicht, hängt der Server. Der Nachteil wäre nur, daß es dann regelmäßig klacken würde... Allerdings hat sich diese Idee ohnehin in Wohlgefallen aufgelöst, nachdem ich feststellen mußte, daß der Ausgang dach einem Impuls am Eingang zwar durchschaltet, aber dann nicht wieder zurückgesetzt wird. Es gibt zwar hierfür extra einen Punkt "Reset output" im Konfigurationsdialog "Application" (s.o.), aber leider wird das Häkchen auch nach Klick auf "Save" nicht gespeichert - noch so ein übler Firmware-Bug.

[Details einblenden]

[Details ausblenden]

Flaues Bild

Das erste, was mir auffiel, nachdem ich die Kamera mit dem Videoserver verband und das Live-Bild im Browser betrachtete, waren die äußerst flauen Farben und die schwachen Kontraste, die sich über auch die Regler für Helligkeit, Kontrast und Farbe im Konfigurationsmenü nicht zufriedenstellend einstellen ließen. Beim VIVOTEK VS3100P war hier der Einstellbereich größer und man konnte ein annehmbareres Ergebnis erzielen.

Trotz Justierung von Helligkeit und Kontrast im Konfigurationsmenü des Videoservers AXIS M7001 ist das Bild farb- und kontrastarm

Nach Anpassung von Helligkeit und Gammawert im Einstellungsmenü der Kamera (BSC 8W) ist das Bild etwas besser geworden

 

Nun muß man natürlich zugestehen, daß eine Nistkasten-Kamera, die mit wenig Licht auskommen muß, kein optimales Bild liefert, aber etwas mehr "Reserve" bei den Bildkorrektur-Einstellungen des Videoservers wären schon sinnvoll gewesen. Zum Glück bietet die Kamera (BSC 8W) ebenfalls Möglichkeiten der Bildkorrektur, und nachdem ich Helligkeit und Gammawert etwas angepaßt hatte, konnte ich auch über den AXIS M7001 ein einigermaßen akzeptables Bild erzielen. Mit einfachen Kameras ohne digitalen Bildprozessor wäre das vermutlich nicht möglich gewesen.

Bildschärfe

Bei halber Bildgröße (384 x 288) ist das JPG-Standbild trotz geringer JPEG-Komprimierung unschärfer, als wenn es in voller Größe (768 x 576) ausgegeben und anschließend verkleinert wird (z.B. mit einem Grafikprogramm). Dies deutet auf einen qualitativ minderwertigen Bildskalierungs-Algorithmus des AXIS M7001 hin.

Originalbild vom Videoserver: CIF (384 × 288), Compression: 15, Größe: 20 KB

Originalbild: 4CIF (768 × 576), Compression: 50, Größe: 31 KB, per GD::Image->copyResized verkleinert auf 384 × 288 (41 KB)

 

Zur Ausgabe des Webcam-Bildes auf der Webseite verwende ich daher ein serverseitiges Perl-Script, das das vom Videoserver gelieferte Originalbild (768 × 576 Pixel) 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. Außerdem fügt dieses Script noch einen eigenen Zeitstempel und einen Zuschauerzähler in das Bild ein, da mir der vom Videoserver eingeblendete Zeitstempel zu viel vom Bild überdeckt hatte und zudem oft falsch ist (s.u.). Leider ist dieser Zeitstempel nicht in den per FTP hochgeladenen Bildern für die Galerie enthalten, aber vielleicht bastle ich mir hierfür auch noch etwas (Stichwort HTTP-Upload).

Streifen im Bild

Je nach Einstellung von Kontrast und Helligkeit bei Kamera oder Videoserver erscheinen im Bild unregelmäßige, helle Streifen, die von oben nach unten laufen. Dies passiert bei beiden Kameras (Farbe und Schwarzweiß) und liegt somit nicht an den angeschlossenen Kameras, zumal dieselben Kameras an allen anderen Videogeräten (Fernseher, TV-Karte, USB-Grabber, VIVOTEK VS3100P) ein störungsfreies Bild liefern. Für mich sieht das so aus, als ob entweder die Elektronik oder irgend ein Bildbearbeitungs-Algorithmus des Videoservers zu leicht übersteuert wird.

Streifen im Bild bei zu hohe Kontrast- und Helligkeitswerten
 

Falsche Zeit

Nachdem man diverse Einstellungsmenüs aufgerufen hat, verstellt sich die Zeit des Videoservers immer wieder von selbst, was zur Folge hat, daß der Zeitstempel im Dateinamen des per FTP hochgeladenen Bildes und/oder der im Bild eingeblendete Zeitstempel nicht mehr stimmen. Dies passiert vor allem dann, wenn man in Einstellungsmenüs des Videoservers war, in denen ein Live-Bild angezeigt wird (z.B. "Video > Camera Settings"). Nachdem die Videoserver-Zeit über das entsprechende Konfigurationsmenü ("Basic Setup > Date & Time > New Server Time") korrigiert wurde, sollte der Server sofort neu gestartet werden, da jede Verzögerung zu einer Zeitabweichung führt und dann die Zeitstempel im Bild und im Dateinamen falsch sind!

HTTP-Fehler 503

Es ist kein gleichzeitiger Zugriff auf das Einzelbild (JPG) und das Live-Bild möglich - dies führt zu einem HTTP-Error "503 Service Unavailable - The maximum number of clients are already connected", der einem zu vermitteln versucht, daß die "maximale Anzahl" von Verbindungen erreicht wurde (ich wußte gar nicht, daß ein Videoserver überhaupt solche Beschränkungen haben muß - bei WebcamXP etc. kann man sich beliebig oft connecten).

Hier kommt niemand mehr rein!
 

Dieser Fehler tritt auch schon dann auf, wenn man einfach nur in das Konfigurationsmenü des Videoservers geht und eine Seite aufruft, auf der ein Live-Bild dargestellt wird. Aber er trat auch schon auf, nachdem einfach nur in "Video Stream Settings" der Wert "Compression" von 15 auf 10 geändert wurde und anschließend der Button "Save" betätigt wurde. Während der Fehler auftritt, wird auch kein Kamerabild auf der Webseite angezeigt. Das Ärgerliche ist, daß der Fehler nicht wieder von selbst verschwindet, nachdem man den Browser beendet und somit die zusätzliche Verbindung zum Videoserver getrennt hat, sondern daß dazu i.d.R. der Videoserver neu gestartet werden muß. Nach dem Restart stimmt dann oft die Uhrzeit wieder nicht und muß neu gesetzt werden (s.o.).