[gelöst] Script gesucht für Szenensteuerung (Theater)

[spiralnebelverdreher]

Hallo zusammen,
ich schildere mal den Kontext meiner Frage:
Eine Theatergruppe mit wenig Budget will für eine Serie von (n < 10) Aufführungen erreichen, dass auf vier im Raum verteilten Fernsehmonitoren (Röhrenmonitore!) unterschiedliche Videostreams zu sehen sind. Diese Streams sollen sich szenenabhängig speisen (kombiniert) aus
a) vorab produziertem Videomaterial (auf Datenträger)
b) live während der Theatervorführung produzierten Streams aus Smartphones

Es soll möglich sein, auf jedem beliebigen Monitor jeden Livestream abzuspielen, also auch auf allen Monitoren ein- und denselben Stream. Wichtig ist dabei, dass ggfs. alle Streams gleichzeitig beginnen auf den TV-Monitoren.

Den Ansatz zur Umsetzung habe ich wie folgt gewählt:
Jeder Fernsehmonitor wird von einem Raspi bespielt (älterer Typ mit Composite Videoausgang nötig). Auf der Speicherkarte des Raspis ist das vorab produzierte Videomaterial sowie Playlisten abgelegt; die Raspis sind alle per LAN mit einem Steuerrechner verbunden. Ebenfalls im LAN sind (per WLAN) integriert die Smartphones mit einer entsprechenden Streaming App (z.B. RTP Camera). Der VLC auf dem Raspi soll so konfiguriert werden, dass er per http steuerbar ist. Die Smartphones sollen kontiniuerlich per Broadcast streamen. Einiges wurde schon mal ausprobiert: Streaming vom Smartphone an VLC auf einen PC und ein Notebook sowie Fernsteuerung des VLC mittels http (wget --http-user="" --http-passwd=das_geheime_passwort -b http://127.0.0.1:8080/requests/status.x ... play\&id=9 spielt Tdie ID-Nummer 9 der Playlist ab) auf dem Desktop PC.
Noch durchzuführen sind natürlich weitere Tests mit einem älteren Raspi.

Da die vorhandene Lichttechnik so was (Ansteuerung Röhren TV) nicht hergibt, soll ein Steuerrechner im LAN (debian Notebook) die Raspis ansteuern. Dies soll durch ein einfach zu bedienendes Interface auf dem Notebook möglich sein: Ein Tastendruck (Leertaste bspw.) für nächste Szene, ein anderer Tastendruck (Backspace bspw) für die vorherige Szene (wichtig für die Proben vor der Aufführung) und eine Resettaste für alles auf Anfang. Die Raspis sollen wie gesagt möglichst zeitgleich mit dem Streamen beginnen, so dass vier geöffnete Browserfenster und Mausbedienung gar keine Option sind. Der Bediener muss ja gleichzeitig noch das konventionelle Lichtpult bedienen.

Nun zu meiner Frage:
Wie lässt sich das mit wenig Aufwand realisieren? Ich habe selbst keinerlei Übung in Bash Skripting, könnte aber Anpassungen in einem einfacheren Skript vornehmen. Hat schon mal jemand so was geschrieben oder weiß, wo das zu finden ist?
Eine Alternative wäre für mich, ein Python Programm zu schreiben, dass mittels Iteratoren durch eine vordefinierte Liste navigiert. Aber auch das wäre für mich Neuland und ich wäre für Beispiele und Code sehr dankbar.

[NAB]

Hast du dir mal HTTP Live Streaming (HLS) näher angeguckt? Das scheint sich bei unseren Fernsehsendern immer mehr durchzusetzen:
https://wiki.ubuntuusers.de/Internet-TV/Stationen/

Mein unausgegorener Hintergedanke ist, dass du alle vier Clients von einem (oder vier?) zentralen Webserver aus beschickst und sie nur jeweils mit der aktuellen Playlist füttern musst. So wie die Playlist aussieht, müsstest du auch lokale Dateien damit abspielen lassen können. Einfachstenfalls müsste die GUI dann nur zentral per "cp" die richtige Playlist in den (die?) Webserver kopieren - das könnte man noch per Zenity hinbekommen. (Und die VLCs neu starten?)

Google hat mich da gerade noch über "OBS Studio" stolpern lassen ... du könntest mal gucken, ob das scriptbar ist (sieht mir nicht so aus).

"gleichzeitig" wird ein Problem werden. Asynchronitäten von ca. 100 ms werden sich kaum vermeiden lassen. Optisch fällt das kaum auf, wenn die Bildschirme nicht direkt nebeneinander stehen. Akustisch ist das aber eine Katastrophe. Falls die Videos Ton haben, solltet ihr euch gleich auf einen Lautsprecher bzw. ein Verstärkersystem festlegen. Oder gucken, ob ihr da einen Tontechniker findet.

[debianoli]

Ich würde es auf dem Laptop mit 4 Instanzen Vlc probieren, von denen jede einzelne einen Video-Stream an einen genau zugeordneten RaspberryPi schickt. Auf jedem RaspberryPi läuft dann Vlc und entfängt vom entsprechenden Port das Laptops seinen Videostream. So kann man das von einer zentralen Stelle aus steuern.

Die Smartphones haben in Webcam Programm installiert, mit dem sie an den Laptop senden, der das Signal dann weiterstreamt. Bringt allerdings Verzögerungen mit sich. Insgesamt dürfte das alles allerdings recht eng im Netzwerk werden. Vor allem bei den Livestreams.

[heisenberg]

Bzgl. einer synchronen Wiedergabe hatte ich mir mal das mit mplayer mal umgesetzt.

http://www.linuxforen.de/forums/showthr ... -abspielen

[Meillo]

Nun zu meiner Frage:
Wie lässt sich das mit wenig Aufwand realisieren? Ich habe selbst keinerlei Übung in Bash Skripting, könnte aber Anpassungen in einem einfacheren Skript vornehmen. Hat schon mal jemand so was geschrieben oder weiß, wo das zu finden ist?
Eine Alternative wäre für mich, ein Python Programm zu schreiben, dass mittels Iteratoren durch eine vordefinierte Liste navigiert. Aber auch das wäre für mich Neuland und ich wäre für Beispiele und Code sehr dankbar.

Hier ein Script:

Code: Alles auswählen

#!/bin/sh

if [ $# -ne 1 ]; then
        echo "Usage: control.sh COMMANDFILE" >&2
        exit 1
fi

list="$1"

execute() {
        if [ "$1" -lt 1 ]; then
                echo "out of range -- first command is: 1"
                return
        fi
        if [ "$1" -gt `wc -l <"$list"` ]; then
                echo "out of range -- last command is: `wc -l <"$list"`"
                return
        fi
        eval `sed -n "$1"p "$list"`
}

help() {
        cat <<-!
                current command: $n
                total commands: `wc -l <"$list"`

                e = execute current command
                f = first command
                n = next command
                p = previous command
                NUMBER = command number NUMBER
                l = show list
                q = quit
!
}

n=1
help
while :; do
        printf "> "
        read cmd
        case "$cmd" in
        q)      exit ;;
        h)      help ;;
        e)      execute "$n" ;;
        l)      cat -n "$list" ;;
        f)      n=1; execute "$n" ;;
        n)      n=`expr $n + 1`; execute "$n" ;;
        p)      n=`expr $n - 1`; execute "$n" ;;
        [0-9]*) n="$cmd"; execute "$n" ;;
        esac
done

Es erwartet als ersten Parameter eine Datei, die die gewuenschten Befehle -- einen je Zeile -- enthaelt. Das Script startet dann eine Schleife, in der man durch die Befehle navigieren kann. Man einfachsten, man probiert es mit lauter echo-Befehlen aus. Das Script koennte in manchen Randfaellen noch verbessert werden, aber es sollte doch etwa deinem Wunsch entsprechen.

[spiralnebelverdreher]

Euch allen vielen Dank für eure hilfreichen Antworten und insbesondere Meillo für das Script!

@NAB: HLS hatte ich bisher nicht in Betracht gezogen, ebenso einen zentralen Server der alle Inhalte streamt. Grund dafür war ein erster Test mit dem (älteren) debian Notebook, auf dem vlc die Webcam des Notebooks als Stream verteilen sollte. Der Lüfter ging sofort und heftig an und pustete mächtig warme Luft heraus, obwohl Auflösung und Bildwiederholrate sehr moderat eingestellt waren. Das Transkodieren von Inhalten scheint mir extrem rechenintensiv zu sein, wenn man nicht wirklich Ahnung hat von diesem ganzen Video-Codec Zeugs, HW-Unterstützung und den tausenden Optionen.
Ob ein um 100 ms versetztes Abspielen ein Problem ist, wird sich zeigen. Audio ist definitiv kein Problem, da erstens der Theaterraum nicht sehr groß ist und zweitens in der Gruppe Leute mit Ausbildung als Veranstaltungstechniker mitmachen. Licht, Ton und Bühne haben die super im Griff, nur beim Video streamen brauchen sie Unterstützung.

@debianoli: Die Netzwerklast durch einen Videostream meines eigenen Smartphones liegt bei moderater Auflösung und 24fps bei 1-2 Mbit/s. Es werden mindestens zwei WLAN Access Points eingesetzt, die statisch auf nicht überlappenden Frequenzbändern arbeiten (Umgebungs-WLANs und unbeabsichtigte Hotspots der Zuschauer sind aber m.E. ein mögliche Störquelle). Der Rest ist per LAN mit 100 Mbit/s oder Gbit/s verbunden und sollte ausreichen.

[NAB]

Grund dafür war ein erster Test mit dem (älteren) debian Notebook, auf dem vlc die Webcam des Notebooks als Stream verteilen sollte. Der Lüfter ging sofort und heftig an und pustete mächtig warme Luft heraus, obwohl Auflösung und Bildwiederholrate sehr moderat eingestellt waren. Das Transkodieren von Inhalten scheint mir extrem rechenintensiv zu sein, wenn man nicht wirklich Ahnung hat von diesem ganzen Video-Codec Zeugs, HW-Unterstützung und den tausenden Optionen.

Deswegen meinte ich "angucken". HLS erwartet H.264. Das dürfte das Format sein, in dem die Smartphones die Videos eh anliefern. Da müsste dann nichts "transkodiert" werden. Allerdings muss das Video (die Videos) in Echtzeit in einen Mpeg2-Transportstrom verpackt werden ... oder auch nicht, falls es eine Smartphone-App gibt, die das von sich aus macht. Theoretisch gäbe es da sogar Nginx für Android ...

[spiralnebelverdreher]

Grund dafür war ein erster Test mit dem (älteren) debian Notebook, auf dem vlc die Webcam des Notebooks als Stream verteilen sollte. Der Lüfter ging sofort und heftig an und pustete mächtig warme Luft heraus, obwohl Auflösung und Bildwiederholrate sehr moderat eingestellt waren. Das Transkodieren von Inhalten scheint mir extrem rechenintensiv zu sein, wenn man nicht wirklich Ahnung hat von diesem ganzen Video-Codec Zeugs, HW-Unterstützung und den tausenden Optionen.

Deswegen meinte ich "angucken". HLS erwartet H.264. Das dürfte das Format sein, in dem die Smartphones die Videos eh anliefern. Da müsste dann nichts "transkodiert" werden. Allerdings muss das Video (die Videos) in Echtzeit in einen Mpeg2-Transportstrom verpackt werden ... oder auch nicht, falls es eine Smartphone-App gibt, die das von sich aus macht. Theoretisch gäbe es da sogar Nginx für Android ...

Danke für deine Infos. Bin mir nicht sicher, ob ich deine Idee richtig verstanden habe:
Du schlägst vor, auf dem Notebook alle Videostreams (mein Smartphone streamt tatsächlich H.264 Format) aufzusammeln, in einen MPEG2 Transportstrom zu verpacken und mit einem nginx Webserver an die Clients zu streamen. Das heißt, die Aufgabe vier Streams (je einen für die Raspis) inhaltlich zusammenzustellen (je nach Erfordernis der Szenen im Theaterstück) erfolgt durch eine Schnittstelle des nginx Webservers. Meine Kernaufgabe (Szenensteuerung für Videostreams) würde dann nur den Webserver beeinflussen.
Richtig?
Ich verstehe ehrlich gesagt, nicht so ganz was ich dabei wirklich gewinnen würde. Als Vorteile von HLS werden genannt, dass der Client sich (entsprechend der Qualität der Netzwerkverbindung) den passenden Stream aussuchen kann und dass das http Protokoll die Durchquerung von üblichen Firewalls leicht macht. Das ist alles in einem Weitverkehrsnetz mit Firewalls etc sehr sinnvoll, aber in meinem kleinen LAN?

[spiralnebelverdreher]

.... Es erwartet als ersten Parameter eine Datei, die die gewuenschten Befehle -- einen je Zeile -- enthaelt. Das Script startet dann eine Schleife, in der man durch die Befehle navigieren kann. Man einfachsten, man probiert es mit lauter echo-Befehlen aus. Das Script koennte in manchen Randfaellen noch verbessert werden, aber es sollte doch etwa deinem Wunsch entsprechen.

Habe das Skript mal angepasst und bin sehr zufrieden mit seiner Funktion! Eine Änderung würde ich für sinnvoll halten: Ist es möglich, in der Datei mit den Menübefehlen am Anfang jeder Befehlszeile (oder über der Ziele) einen Raum für Kommentar zu schaffen, um eine sprechende Kurzbezeichnung der Szene zu haben statt eventuell nur einer Zeilennummer im Editor. Am Ende der Zeile habe ich bereits Kommentare eingefügt, aber vorne wäre halt besser.

[Meillo]

Habe das Skript mal angepasst und bin sehr zufrieden mit seiner Funktion! Eine Änderung würde ich für sinnvoll halten: Ist es möglich, in der Datei mit den Menübefehlen am Anfang jeder Befehlszeile (oder über der Ziele) einen Raum für Kommentar zu schaffen, um eine sprechende Kurzbezeichnung der Szene zu haben statt eventuell nur einer Zeilennummer im Editor. Am Ende der Zeile habe ich bereits Kommentare eingefügt, aber vorne wäre halt besser.

Du kannst sowas eintragen wie:

Code: Alles auswählen

echo "Titel der Szene"; Der-eigentliche-Befehl

Damit wird in der Kommandoschleife der Titel ausgegeben, wenn er gestartet wird. Zudem sieht man den Titel wenn man den List-Befehl verwendet. (Bloss auswaehlen kann man den Befehl nicht anhand seines Titels, aber das ist wohl weder gewollt noch sinnvoll.)

Wenn du den Titel nur in der Liste sehen willst, aber nicht ausgeben, dann verwende:

Code: Alles auswählen

: "Titel der Szene"; Der-eigentliche-Befehl

[NAB]

Ich verstehe ehrlich gesagt, nicht so ganz was ich dabei wirklich gewinnen würde.

Tja, dann bringt es dir vermutlich nichts. Für mich sieht dein Ansatz ganz schön fummelig aus, vier Raspis *schnell* fernzusteuern. Ich hielt die zentrale Steuerung für vorteilhaft.

Richtig, die genannten Vorteile von HLS sind für dich keine.

Die Vorteile von HLS aus meiner Sicht sind:
1) das "live" Streaming (dafür ist es ja gemacht). Der Videostrom wird in kurze Segmente zerlegt (z.B. 1 Sekunde) und in vielen kleinen Dateien übertragen (HLS segmenter). Das würde bedeuten, du könntest im fliegenden Wechsel den anderen statt den einen Videostrom ausliefern. Der Client würde gar nicht merken, dass ein Wechsel stattgefunden hat - er würde weiterhin kurze Segmente des für ihn immer gleichen Videostroms empfangen.

Ich sehe den Vorteil hier darin, dass der Techniker bei vier Videoströmen (für vier Raspis) nur noch entscheiden muss, woher welcher Strom gerade kommen muss. Das könnte er blind bedienen ... "12345" für den ersten Raspi, "qwert" für den zweiten, u.s.w. Mögliche Stolperfallen sehe ich aber auch. Vorallem finde ich keine einfache Software ... zwischen ffmpeg und teurer Studiosoftware scheint da kaum was zu sein.

2) die zentral verwalteten Playlisten.
die sehe ich unabhängig von 1) als Spielfläche, mit der man experimentieren könnte. Die können auch auf lokale Dateien auf dem Raspi zeigen, oder auf ne andere HTTP-Adresse. Falls man auf den Smartphones Nginx und HLS zum Laufen kriegt, könntest du dir das zentrale Streaming vom Notebook aus auch sparen.

Meine bescheidenen eigenen Erfahrungen mit HLS beschränken sich auf Experimente mit Mythtv. Da schafft es ein popeliger Pentium aber immerhin, vier unterschiedliche SD-Programme gleichzeitig auszuliefern ... und das mit Transkodierung. Daheim im LAN, also ungefähr deine Kragenweite.

Aber wenn ich sehe, wie zufrieden du mit Meillos Script bist, habe ich wohl deine Anforderungen falsch eingeschätzt. Ich dachte eher an Situationen wie im Fernsehstudio ... "Und jetzt Kamera 3 auf den großen Bildschirm!" ... "Und jetzt Trailer 3!" ...

[NAB]

Himmel ist das nervig, in Python einzelne Tastendrücke auszulesen ...

spiralnebelverdreher, ich hab dir alternativ was in Python zusammengeschustert:

Code: Alles auswählen

#!/usr/bin/python3
import sys, curses, subprocess

befehle = {
            "a" :      [ "ehallo", "/bin/bash", "-c", "echo hallo" ],
            "q" :      [ "quit", "/bin/true" ],
            "b" :      [ "beep", "/usr/bin/beep" ],
            "\n":      [ "beep tiefer", "/usr/bin/beep", "-f 500" ],
            "KEY_UP" : [ "beep shellscript", "/home/me/beep.sh" ],
            "s" :      [ "sleep", "/home/me/sleep.sh" ],
          }

def main(stdscr):
    stdscr.addstr("Taste   - Befehl")
    pos = 1
    for befehl in sorted(befehle):
        zeile = "{0:7} - {1}".format(befehl, befehle[befehl][0]) # "Taste" ist 7 Buchstaben lang
        stdscr.addstr(pos, 0, zeile + "\n")
        pos+=1

    eingabe = ""
    while eingabe != "q":
        eingabe = stdscr.getkey()
        # Auskommentieren um Tasten-Kuerzel zu finden:
        #print("Eingabe = " + eingabe + "\r")
        if eingabe in befehle.keys():
            subprocess.Popen(befehle[eingabe][1:])

curses.wrapper(main)

Die Sache ist erklärungsbedürftig. Über "befehle" konfigurierst du das Ding. Als Beispiel diese Zeile:

Code: Alles auswählen

 "a" :      [ "ehallo", "/bin/bash", "-c", "echo hallo" ],

Der Buchstabe "a" wird dir angezeigt mit der Befehlserläuterung "ehallo".
Ausführen tut der Buchstabe "a" den Befehl /bin/bash.
Dem Befehl /bin/bash werden zusätzlich die Argumente "-c" und "echo hallo" übergeben.
Dementsprechend führt "b" den Befehl /usr/bin/beep aus, ohne zusätzliche Argumente.

Du kannst nach dem gleichen Muster beliebig weitere Kombinationen aus Taste, Beschreibung und Befehl hinzufügen. Das Script passt sich an.

Und dann komme ich mal zu den Problemen:
Wenn du es ausführst, sieht es so aus:

Code: Alles auswählen

Taste   - Befehl

KEY_UP  - beep shellscript
a       - ehallo
b       - beep
q       - quit
s       - sleep

Wie du siehst, fehlt die Zeile mit dem \n. Logisch, das \n wird gedruckt und führt gleich zu einer neuen Zeile. Ich wollte aber testen, ob man die Eingabetaste belegen kann - und es geht. "Enter" führt /usr/bin/beep -f 500 aus. Ich war zu faul, solche Fälle abzufangen.

Das Kürzel "KEY_UP" habe ich herausbekommen, indem ich die Zeile, die unter "# Auskommentieren" steht, auskommentiert habe. Die Pfeil-nach-oben-Taste führt ein Shellscript aus.

Wenn du "a" drückst, siehst du vermutlich, dass es dir gnadenlos die (nichtvorhandene) Eingabemaske zerlegt, sobald eins der aufgerufenen Kommandos Text ausgibt. Ich hab Curses nicht unter Kontrolle bekommen. Das Script reagiert natürlich weiter auf Eingaben, man sieht nur die "Gebrauchsanleitung" irgendwann nicht mehr.

Weitere Mankos:
* Er sortiert dir deine Befehle in der Anzeige alphabetisch (oder was er dafür hält), egal ob du willst oder nicht.
* "q" ist hart kodiert, also ändere die Zeile nicht (oder ändere while eingabe != "q": gleich mit)

[spiralnebelverdreher]

Aber wenn ich sehe, wie zufrieden du mit Meillos Script bist, habe ich wohl deine Anforderungen falsch eingeschätzt. Ich dachte eher an Situationen wie im Fernsehstudio ... "Und jetzt Kamera 3 auf den großen Bildschirm!" ... "Und jetzt Trailer 3!" ...

In den Aufführungen ist die Anforderung relativ simpel: Den definierten Startzustand herstellen, dann eine Szene nach der anderen, und das bitte zuverlässig und einfach bedienbar.
Vorher, während der Proben, wird natürlich mehr ausprobiert und da wäre das von dir skizzierte Feature natürlich hilfreich. Das tritt aber - bei begrenzter Zeit und begrenztem Budget - hinter der Hauptanforderung zurück.

[spiralnebelverdreher]

Ich habe den Thread schon mal auf gelöst gesetzt, obwohl die Aufführungen noch bevorstehen. Aber das wird schon werden.

Falls es jemanden interessiert: Das Theaterstück "Die Illegalen" stammt von Günter Weisenborn und wird im April 2018 in Frankfurt/Main an einem recht kleinen Spielort aufgeführt, in der Raumstation Rödelheim. Flyer und Ankündigungen im Netz sind noch in Arbeit.

[spiralnebelverdreher]

Hier die Ankündigung der Theatervorstellungen http://nachtgewitter.insel14.de/ , in denen auch Open Source Software und debian zum Einsatz kommen.

Wen es aus technischer Sicht interessiert: Als Player kommt auf den Raspis der OMXplayer (statt vlc) zum Einsatz. Der hat u.a. die charmante Eigenschaft, dass er mittles Layering den fliegenden Wechsel zwischen zwei Live-Streams erlaubt: Stream 1 läuft, Stream 2 wird gestartet und legt sich nach dem Start (knapp 3 Sekunden auf einem Raspi 3) über das Bild von Stream 1. Dann wird Stream 1 gestoppt.

[Meillo]

Herzlichen Dank fuer das Update und die technischen Details!

[spiralnebelverdreher]

Da es anscheinend manche User interessiert, was man mit der Szenensteuerung und den Raspis so anfangen kann, will ich hier mal fortfahren und berichten wie sich das Theaterprojekt technisch entwickelt hat. Die Hardware ist inzwischen komplett aufgebaut und die Probenwoche hat begonnen.

Im Raum verteilt sind 5 Röhren-Fernseher, jeweils mit einem Raspi 3 als Video-Quelle für den Scart-Eingang. Die Raspis haben vierpolige Klinkensteckerausgänge für Audio plus Composite Videosignal. Einer der Raspis speist den Ton der vorher aufgenommenen Videos in die Verstärkeranlage, die anderen sind stumm.

Weiterhin sind im Bühnenraum verteilt zwei zugelaufene WLAN-Router und ein ausgeliehener Access Point. Zur Steuerung des Ganzen dient ein Notebook.
Für die Erfassung der Live-Video Streams (alles scharzw-weiß) stehen drei Android Smartphones mit Streaming-Apps (RTP Camera, RTSP Camera) bereit; jedes Smartphone verbindet sich auf einer statisch zugewiesenen Frequenz mit einem anderen WLAN Router oder AP um Datenstau auf der Luftstrecke zu vermeiden.
Notebook, Router, AP und die Raspis sind in einem Gigabit-LAN verbunden.

Auf dem Notebook kommt nun doch nicht Meillos Script zum Einsatz (vielen Dank nochmal, es hat am Anfang zur Entwicklung des technischen Konzeptes sehr geholfen); ein Hinweis eines der Mitwirkenden hat nämlich ergeben, dass in debian testing das Paket linux-show-player enthalten ist. Dieses Programm kommt aus der Audio-Ecke , hat aber auch eine "command cue" Schnittstelle, über die man Kommandozeilenbefehle absetzen kann. Die Steuerung der vorher aufgenommenen Audio-Einspielungen sowie die Steuerung der Videoeinspielungen kann damit aus einem einzigen Werkzeug heraus erfolgen.

Die Raspis (Raspbian stable) haben alle ssh-Server laufen, kennen den öffentlichen Schlüssel des Notebook-Users und erhalten ihre Befehle (ssh username@raspiname kommandoname) damit sogar verschlüsselt und authentifiziert überreicht. Als Videoplayer auf den Raspis kommt der OMXPlayer zum Einsatz; diesem wird (über ssh) mitgeteilt, welche (lokal auf SD-Karte vorhandene) vorproduzierte Videoteile er abspielen soll bzw. welchen Stream er abspielen soll. Wie im vorherigen Beitrag beschrieben, kann man mittels Layering sogar unterbrechungsfrei zwischen verschiedenen Streams umschalten.

In der Summe ist das alles zwar nicht ganz wenig Zeugs, aber doch noch übersichtlich und handhabbar: Smartphones mit Streaming-Apps, Raspis mit ssh-Server und OMXPlayer, Notebook mit ssh-add, linux-show-player sowie einige kleine Shell-Skripte. Dazu noch etwas Hardware wie Scart-Adapter, Switch, Kabel, AP und die WLAN-Router. Also alles OpenSource Software, bis auf die Software im AP und Router.

Erwähnen sollte ich vielleicht noch, welche Ansätze verworfen wurden und was schwierig war: der zuerst eingesetzte vlc wurde aussortiert, da er etwas zickig auf manche Video-Streams reagiert hat (abhängig von Codec, Auflösung, Framerate und Kompression). Wäre vermutlich aber durch souveränes Beherrschen der umfangreichen Optionen-Klaviatur beherrschbar gewesen. Um den Ton der Videos zeitsynchron abzuspielen wurde ein Raspi mit der Verstärkeranlage plus TV verbunden. Ein alter Raspi der ersten Generation wurde aussortiert, da er doch deutlich lahmer reagiert als die Geräte der dritten Generation. Für die Videostreams musste etwas rumprobiert werden, welche Codecs, Frame- und Kompressionsraten richtig waren.

Danke an alle für eure hilfreichen Beiträge und Anregungen in diesem Thread!