Grundlagen Live-Streaming

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)
• IRC-Rückkanal

http://lac.linuxaudio.org/2012/video.php?id=27

1. Quellen: Kameras, Zuspieler, Stills
2. Bildregie
3. Senken: Aufnahme, Kontrollmonitor, Stream-Encoder
4. Codec: aus 20Mbit/s mach 500kbit/s
5. Sendeleitung: HTTP-Ausspielung des kodierten Streams
6. Das Relay: aus eins mach N.
7. 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

• Standard-PC (2 Kerne Core2 2GHz oder besser)
• DVSwitch (http://dvswitch.alioth.debian.org)
• MIDI-Faderbox (z.B. Behringer BCF2k)

• 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 ?

• 79 Seiten nur Patent-Nummern

• Container-Format: OGG (http://xiph.org)
• Audio-Stream: Vorbis (http://xiph.org/vorbis)
• Video-Stream: Theora (http://xiph.org/theora)
• optional: Untertitle mit Kate (https://wiki.xiph.org/OggKate)

• HTTP-Stream über beliebigen Port (kein Problem mit Firewalls)
• Kommunikation mit dem Relay über libshout
• Bandbreitenbedarf kann angepasst werden (üblicherweise 200 kbit/s bis 2 Mbit/s)

• extern gehosteter Icecast2-Server
• Empfang auf beliebigem Port per HTTP
• Ausgabe auf beliebigem Port per HTTP (keine Probleme mit Firewalls)
• Bandbreitenskalierung über weitere Slave-Relays

• einfachste Lösung: nativer Browser-Support in Google Chrome/Chromium, Firefox, Opera per HTML5

<video/>

• video player (VLC, mplayer,..)
• 'Cortado' Applet + App (IE, mobile)
• OGG/Theora/Vorbis = Wikipedia's choice → https://en.wikipedia.org/wiki/Wikipedia:Media_help_%28Ogg%29

HTTP-Streaming = Application/Session-Layer-Streaming

Vorteile:

• sieht aus wie normaler Web-Traffic (geht also durch die meisten Firewalls)
• keine Paketverluste (TCP!)

HTTP-Streaming = Application/Session-Layer-Streaming

Nachteile:

• sieht aus wie normaler Web-Traffic
  • bringt Web-Proxyserver durcheinander
  • wird oft als nicht dringend behandelt
• 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:

1. Client schneller als Server: buffer underrun, drop-outs wenn buffer leer.
2. 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.