am Beispiel einer Free-Software-Lösung
für Anwendungsfälle mit geringem (oder komplett ohne) Budget
Also:
Standard-Hardware (das, was da ist).
freie Software (gratis, aber vor allem quelloffen)
freie Codecs (möglichst plattformübergreifend)
Linux Audio Conference 2012 (CCRMA, Stanford University)
Ziele:
Die Konferenz auch für Mitglieder der Community zu öffnen, die aus Zeit- oder Kostengründen nicht vor Ort sein können.
Echte Partizipation, d.h. inkl. Rückkanal
nachhaltige Dokumentation
Linux Audio Conference 2012 (CCRMA, Stanford University)
Technik pro Vortragssaal:
Bildmischer/Stream Operator
Closeup/Halbtotale mit Kamera-Operator
Feste Totale (bzw. bedient durch Stream Operator)
-
Quellen: Kameras, Zuspieler, Stills
Bildregie
Senken: Aufnahme, Kontrollmonitor, Stream-Encoder
Codec: aus 20Mbit/s mach 500kbit/s
Sendeleitung:
HTTP-Ausspielung des kodierten Streams
Das Relay: aus eins mach N.
Client-Software
2x Consumer/Prosumer-Camcorder mit DV-Output per IEEE 1394
Screen capture VGA→DV (Scan converter)
Screen capture (local screen)
Cartwall mit Intro-Videos für jeden Beitrag
BCF2000 (MIDI) → MIDI to
OSC → DVswitch
dvswitch
macht die Hauptarbeit (mixing)
dvmctrl
- controls dvswitch
dvsource-dvgrab
(camera capture)
dvsource-file
(title playback)
dvsink-icecast2
(stream)
dvsink-files
(disk dump)
dvswitch - B. Hutchings - entstand fuer debconf. (GPLv2)
dvwitch Fernbediening (
OSC) - R. Gareus (now upstream)
MIDI →
OSC gateway - Nettingsmeier + Gareus (contrib upstream)
Auto-start skripte - Nettingsmeier + Gareus (custom software, git repository)
Ein globales startup script welches einzelne modualare skripte aufruft:
start dvswitch
start dvmctrl
camera-grab (x3)
disk-dump (archiv)
high-quality stream
low-quality stream
Ein “doppelclick”.
Murphy is everywhere
Module werden automatisch neu gestartet (solange dvswich lauft)
'kill-switch' fuer jede Kamera (manual|auto-restart)
'kill+relaunch' fuer Senken (disk-dump, encoder)
Aufnahme DV-Stream (Programmsignal)
Kontrollmonitor (DVSwitch-
GUI)
Stream-Encoder hohe Bandbreite
Stream-Encoder niedrige Bandbreite
Have you ever heard about the MPEG License Authority ?
Have you ever heard about the MPEG License Authority ?
HTTP-Streaming = Application/Session-Layer-Streaming
Vorteile:
HTTP-Streaming = Application/Session-Layer-Streaming
Nachteile:
sieht aus wie normaler Web-Traffic
massiver Jitter (
TCP-Resends), dadurch große buffer nötig
clock recovery so gut wie unmöglich
großer Overhead, viel Zustandsinformation in Server und Client
Problem: der Echtzeit-Stream ist senderseitig getaktet.
Der Client benutzt aber eine lokale Clock. Mögliche Szenarien:
Client schneller als Server: buffer underrun, drop-outs wenn buffer leer.
Client langsamer als Server: Server muss Queue-Buffer immer weiter vergrößern. Wenn zulässiges Maximum erreicht: Client wird rausgeworfen.
Methode: fire and forget
Vorteile:
wenig Overhead
ist als “realtime”-Strom erkennbar
kaum Zustandsinforation in Server und Client
nicht mit normalem Web-Traffic verwechselbar
keine Transport-Layer-Resends, daher geringer Jitter
Clock recovery ist möglich
Methode: fire and forget
Nachteile:
Pakete können verloren gegen, daher:
Packet Loss Concealment ist notwendig
braucht spezielle Firewall-Regeln
UDP ist “best effort”, d.h. selbst ein Router, der 100% aller Pakete verwirft, ist noch standardkonform.
komplette Open-Source-Lösung
'Free' (license+patent unencumbered) codecs
nicht ohne Ecken und Kanten
suboptimale Effizienz
aber: kostnix und man kann unter die Haube schauen.
ideal für Open-Source-Projekte :D
Danke für Eure Aufmerksamkeit.