Hi.
Ich melde mich mal wieder zum Thema „StopMotion-Filme“ drehen …
Da wir in unserem Computerraum nicht an jedem PC eine WebCam betreiben (und auch nicht wollen), erstellen die Schüler die Bildersequenzen ihrer StopMotion-Filme zur Zeit mit ihren Smartphones (die sie natürlich immer dabei haben und die auch viel bessere Bilder liefern). Das klappt zwar prinzipiell, doch ist der Transfer der Bilder immer etwas mühsam…
Es gibt natürlich auch Apps für’s Smartphone, die ganz anständig funktionieren, doch die Handhabe auf den kleinen Displays ist letztlich immer ein Kompromiss. Direkt am PC wäre es eleganter, größer, einfacher …
„Professionelle“ Stop-Motion-Programme auf dem PC können zudem natürlich sehr viel mehr, wenn sie direkt auf die Kamera zugreifen können („onion skinning“ usw usw). Daher war mein Gedanke: Kann man von einem StopMotion-Programm aus evtl irgendwie die Smartphone-Cam als IP-Kamera ansprechen, so dass man die Bilder der Smartphone-Kamera direkt in dem Programm verwenden kann? Ein erster Kandidat auf dem Smartphone ist die App „DroidCam“. Damit kann man dann RAW auf die Kamera zugreifen, wenn man im Browser oder im VLC die Adresse http://ip-des-smartphones:4747/mjpegfeed
eingibt. Das ist schon mal was!
Leider fehlt jetzt noch der Schritt, wie man daraus ein „local-Device“ a la /dev/video1 machen müsste, so dass auch Programme wie „StopMotion“ auf diesen Stream zugreifen können? Hat da jemand zufällig eine Idee?
Gefunden habe ich bisher das hier: https://superuser.com/questions/751568/use-a-ip-camera-as-a-virtual-camera
Das andere Problem ist ein ganz praktisches: Bei uns befinden sich die Smartphones natürlich im blauen/transparenten Netz hinter dem CoovaChilli – es müsste also auch noch eine Regel her, die den Zugriff auf Port 4747 auf alle Geräte von GRÜN <–> BLAU erlaubt.
Vielleicht lohnt sich der ganze Aufwand auch gar nicht … aber elegant wäre es
Ich habe das Script nochmal stark verbessert, da ja die Schüler selbst ihre IP nachsehen und eingeben müssen.
Daher jetzt mit Syntax-Check und Zenity:
#!/bin/bash
#######################################################################################################################
# Scriptname : smartphone-ipcam.sh
# Author : div. Vorlagen zu zenity und Syntax-Checks; geändert von M.H.
# https://superuser.com/questions/751568/use-a-ip-camera-as-a-virtual-camera
# https://stackoverflow.com/questions/13015206/variables-validation-name-and-ip-address-in-bash
# https://stackoverflow.com/questions/21368107/how-to-get-the-values-of-different-forms-in-zenity
# Date : 2017-10-22
# Requires : ffmpeg, zenity, v4l2loopback-utils; Smartphone: DroidCam
# Category : Smartphone-Cam --> IP-Cam --> StopMotion-Videos
#Version : 1.0
#######################################################################################################################
#Dieses Script prueft, ob eine eigegebene IP-Adresse die richtige Syntax besitzt und gibt eine
#entsprechende *grafische* Rueckmeldung an den User!
#Anschliessend wird der Zugriff auf die Smartphone-Webcam bereitgestellt.
#zenity und ffmpeg muessen installiert sein.
#Zuvor muss das folgende Paket installiert werden (erstellt ein virtual device)
#sudo apt install v4l2loopback-utils
#Auf dem Smartphone muss die App "DroidCam" (https://www.dev47apps.com/) installiert sein.
#Zugriff (RAW) unter: http://ip.des.smart.phones:4747/mjpegfeed
#Die Smartphone-Cam kann nun z.B. mit "stopmotion" direkt unter /dev/$device angesprochen werden.
#to-do: Check, ob nur 4 Oktetts eingegeben wurden einbauen?
device=$(ls -la /sys/class/video4linux |grep virtual |awk '{print $9}');
IP_ADDRESS=$(zenity --forms --title="WiFi IP-Adresse eingeben" --text="Die IP-Adresse deines Smartphones?" --separator="." --add-entry="Wifi IP:" --width=300)
accepted=$?
if ((accepted != 0)); then
echo "Es ist etwas schief gegangen."
exit 1
fi
ip=$(awk -F, '{print $1}' <<<$IP_ADDRESS)
if echo "$ip" | egrep -E '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'
then
# Then the format looks right - check that each octect is less
# than or equal to 255:
VALID_IP_ADDRESS="$(echo $ip | awk -F'.' '$1 <=255 && $2 <= 255 && $3 <= 255 && $4 <= 255')"
if [ -z "$VALID_IP_ADDRESS" ]
then
# echo "Die eingegebene Adresse ist keine IP-Adresse. Alle Zahlen müssen kleiner als 255 sein!"
zenity --warning --text="Die eingegebene Adresse ist keine IP-Adresse. \n Alle Zahlen müssen kleiner als 255 sein!"
else
# echo "Die Adresse ist ok!"
zenity --info --text "Die Adresse $ip ist ok. \n \n Die Kamera ist unter /dev/$device ansprechbar."
if ping -c 1 $ip &> /dev/null
then
#IP-Cam nach /dev/$device mit folgendem Befehl:
ffmpeg -i http://$ip:4747/mjpegfeed -f x11grab -r 15 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/$device;
else
zenity --warning --text="Das Smartphone ist nicht erreichbar!"
fi
fi
else
# echo "Die IP-Adresse wurde nicht richtig angegeben."
zenity --warning --text="Die IP-Adresse wurde nicht richtig angegeben."
fi
exit 0;
Tja … das was bei mir zu Hause funktionierte, klappt in der Schule noch lange nicht. Eine Regel, die von GRÜN → BLAU funktioniert, ist scheinbar nicht so einfach herzustellen, wenn sich da ein Coova dazwischen befindet?
Hat da jemand einen brauchbaren Tipp?
es müsste also auch noch eine Regel her, die den Zugriff auf Port
4747 auf alle Geräte von GRÜN <–> BLAU erlaubt.
… das geht so ohne Probleme: die Regel ist einfach und funktioniert sofort.
Sobald du sie eingerichtet und übernommen hast, erreicht jeder Cleint
aus Grün alle Cleints in Balu auf dem Port 4747
… alle Clients bedeutet dummerweise: nur der Coovaserver: in Blau sind
nämlich keine anderen Clients…
Die die du erreichen willst sind in violett: also vom IPFire aus gesehen
jenseits des Coova und auch noch hinter einem NAT.
Las es mich mal so sagen: das wirst du mit der WLAN Lösung so nicht
hinbekommen …
Das ist schade. Ich hatte es aber befürchtet, als ich näher darüber nachgedacht habe.
Aber evtl eine Alternative: einen temporären Accesspoint mit in den Raum hängen, der weitere IPs aus dem gleichen Subnetz verteilt (die ja gar nicht in der workstations-Datei stehen müssen, da sie nur intern erreichbar sein müssen).
Dann bleibt der Zugriff auf die “IP-Cams” im gleichen Segment. Auf diesem Weg müsste es klappen, oder???
Das ist schade. Ich hatte es aber befürchtet, als ich näher darüber
nachgedacht habe.
Aber evtl eine Alternative: einen temporären Accesspoint mit in den Raum
hängen, der weitere IPs aus dem gleichen Subnetz verteilt (die ja gar
nicht in der workstations-Datei stehen müssen, da sie nur intern
erreichbar sein müssen).
Dann bleibt der Zugriff auf die “IP-Cams” im gleichen Segment. Auf
diesem Weg müsste es klappen, oder???
ist dein NEtz segmentiert?
Dann geht das nämlich auch nicht so einfach: dein AP müßte VLANs können
und er würde nur an getaggten Switchports funktionieren, die alle
nötigen VLANs liefern.
Ja, es ist segmentiert.
Ich hatte an einen “dummen” AP gedacht, den ich einfach mit in das gleiche VLAN hänge wie die PCs in dem Raum (untagged). Der soll ja nur IPs für das eine Subnetz an die Smartphones per WLAN verteilen – mehr nicht.
Ja, es ist segmentiert.
Ich hatte an einen “dummen” AP gedacht, den ich einfach mit in das
gleiche VLAN hänge wie die PCs in dem Raum (untagged). Der soll ja nur
IPs für das eine Subnetz an die Smartphones per WLAN verteilen – mehr nicht.
das könnte gehen.
Voraussetzung:
die IPs kommen vom Server, nicht vom AP
in dem Segment ist der „Rechneraufnahmebereich“ in der
/etc/linuxmuster/subnets definiert
dann bekommen die WLAN Geräte eine IP, die nicht auf den Server oder das
Internet zugreifen kann: man müßte aber von anderen Rechnern im Segment
aus auf die WLAN Clients zugreifen können.
Ja, an so etwas hatte ich gedacht. Es geht in diesem Fall ja nur darum, dass die Smartphones “irgendwie” auf Port 4747 erreichbar sind. Das ganze nur temporär (wobei ja nicht wirklich viel passieren kann??). Evtl ginge es sogar einfach mit 'nem Freifunk-Router (mit Kanonen auf Spatzen geschossen?)?
… aber es wäre ja zuuuu schade, wenn ich diese Lösung jetzt nicht @school umsetzen könnte, denn es klappt ja schließlich
Ja, an so etwas hatte ich gedacht. Es geht in diesem Fall ja nur darum,
dass die Smartphones “irgendwie” auf Port 4747 erreichbar sind. Das
ganze nur temporär (wobei ja nicht wirklich viel passieren kann??). Evtl
ginge es sogar einfach mit 'nem Freifunk-Router (mit Kanonen auf Spatzen
geschossen?)?
mit einem Freifunk Router geht es überhaupt nicht, weil der die mobilen
Geräte per VPN aus dem Schulnetz raustunnelt: weiter weg von deinem Netz
bekommst du sie ohne weiteres garnicht…
Ja, hast Recht – war Quatsch. Aber die andere Idee mit dem „dummen“ AP könnte klappen … ich schaue mal, was wir noch rumfliegen haben.
Ich habe einen LinkSys Accesspoint Wireless-G so konfiguriert, dass er genau das tut, was Holger vorgeschlagen hat: Er leitet nur weiter und übernimmt die DHCP-Adressen vom Server. Zudem habe ich in der subnet-Datei einen DHCP-Bereich für den entsprechenden Raum freigegeben. Damit sind alle Voraussetzungen geschaffen.
Morgen zeigt sich, ob’s klappt – ich gehe jetzt aber davon aus! Die Smartphones, die über diesen AP eine IP-Adresse erhalten, könnten natürlich prinzipiell den Server attackieren, da sie ja auf das Servernetz „zugreifen“ können. Aber ich halte die Gefahr dennoch für überschaubar; zumal das Schüler aus Klasse 6 sind
Nachtrag: Es funktioniert alles wie beschrieben . Man sollte sich aber darauf gefasst machen, dass die Übertragung der Streams zu den einzelnen Clients nicht allzu flüssig läuft. Eine Messung bei mir zu Hause hat ergeben, dass so ein Stream zur Smartphone-Cam/“IP-Cam” mit default-Settings ca 0.2- 1.1 MiB/s liefern muss und dann auch fluffig läuft. Wenn man das aber mit einer großen Klasse plant, wird es ruckelig (zumindest mit dem AP, den wir eingesetzt hatten – dahinter geht’s mit GBit weiter)
Man kann dieses Script auch verwenden, um Videos mit dem Smartphone als Webcam aufzuzeichnen.
Und mit vokoscreen kann man Screencasts erstellen … die werden sofort im Matroska-Format (.mkv) abgespeichert und sind schön handlich. Ich weiß aber noch nicht, ob man solche Videos problemlos unter moodle hochladen und streamen könnte, falls es den Bedarf gibt…
