====== Grundlagen Live-Streaming ======
~~SLIDESHOW~~
\\
am Beispiel einer Free-Software-Lösung
für Anwendungsfälle mit geringem (oder komplett ohne) Budget
===== Live-Streaming ohne Budget =====
Also:
* Standard-Hardware (das, was da ist).
* freie Software (gratis, aber vor allem //quelloffen//)
* freie Codecs (möglichst plattformübergreifend)
===== Unser Anwendungsfall =====
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
===== Unser Anwendungsfall =====
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
===== Setup at CCRMA/LAC'12 =====
{{ :wiki:dvmctrl:lacstreaming2.jpg?800 }}
http://lac.linuxaudio.org/2012/video.php?id=27
===== Signalkette =====
- 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
===== 1. Quellen =====
\\
* 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
===== 2. Bildregie - Voraussetzungen =====
\\
* Standard-PC (2 Kerne Core2 2GHz oder besser)
* DVSwitch (http://dvswitch.alioth.debian.org)
* MIDI-Faderbox (z.B. Behringer BCF2k)
===== 2. Bildregie - Signalfluß (1) =====
{{ :wiki:img_20140511_191654.jpg?450 }}
===== 2. Bildregie - Signalfluß (2) =====
{{ :wiki:img_20140511_192032.jpg?450 }}
===== 2. Bildregie - Signalfluß (3) =====
{{ :wiki:img_20140511_192338.jpg?450 }}
===== 2. Bildregie - Uebersicht =====
+-------+ +-----------------+
/-->-=* | title | |cGRE Camera(s), |
: meta | video | | Video Projector |
+-=---->| files +---\ /---+ etc.. |
: |cGRE | | | | |
| +-------+ v v +-----------------+
/------\ +-----+-----+ +----------+
| | |cYEL | |cYEL |
| Midi | MIDI | | OSC | |
| +-=------->| dvmctrl +-=------->| dvswitch |
| Desk | | | | |
\------/ +-----------+ +--+----+--+
^ meta | | +----------------+
| *------\ | | | |
| : | \------>| Live Stream(s) |
: v v meta | cBLU |
+----+----+ +-------+ *-=---->| |
|{d} | |{s} | | |
| config | | HDD | +----------------+
| | |cBLU |
+---------+ +-------+
Legend:
-=----> control data +-----------+ +--------+ +------+
|cYEL | |cGRE | |cBLU |
------> video signals (DV) |application| |dvsource| |dvsink|
| | | | | |
+-----------+ +--------+ +------+
===== 2. Bildregie - Fernbedienung =====
* BCF2000 (MIDI) -> MIDI to OSC -> DVswitch
{{ :wiki:dvmctrl:bcf2000-dvmctrl.png?500 |BCF2000 MIDI mapping}}
===== 2. Bildregie - Implementation (1) =====
* ''dvswitch'' macht die Hauptarbeit (mixing)
* ''dvmctrl'' - controls dvswitch
* ''dvsource-dvgrab'' (camera capture)
* ''dvsource-file'' (title playback)
* ''dvsink-icecast2'' (stream)
* ''dvsink-files'' (disk dump)
===== 2. Bildregie - Implementation (2) =====
* 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)
===== 2. Bildregie - Implementation (3) =====
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".
===== 2. Bildregie - Troubleshooting =====
* 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)
===== 3. Senken =====
\\
* Aufnahme DV-Stream (Programmsignal)
* Kontrollmonitor (DVSwitch-GUI)
* Stream-Encoder hohe Bandbreite
* Stream-Encoder niedrige Bandbreite
===== 4. Video Format & Codecs =====
{{ :wiki:img_20140511_191640.jpg?700 }}
===== 4. Video Streaming/Segmentation (1) =====
{{ :wiki:img_20140511_193627.jpg?700 }}
===== 4. Video Streaming/Segmentation (2) =====
{{ :wiki:img_20140511_193806.jpg?700 }}
===== 4. Codecs & Licensing (1) =====
\\
Have you ever heard about the MPEG License Authority ?
===== 4. Codecs & Licensing (2) =====
\\
Have you ever heard about the MPEG License Authority ?
* 79 Seiten nur Patent-Nummern
===== 4. "Free" Codecs =====
\\
* 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)
===== 5. Sendeleitung =====
\\
* 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)
===== 6. Relay =====
\\
* 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
===== 7. Client-Software =====
\\
* einfachste Lösung: nativer Browser-Support in Google Chrome/Chromium, Firefox, Opera per HTML5
* 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
===== Netzwerk-Schichten-Modelle ======
+-----------------+ +-------------------------+
| **OSI/ISO** cYEL| | **IP Stack** cYEL |
+-----------------+ +-------------------------+
| | | |
| Application | | |
| | | |
| Presentation | | Application |
| | | |
| Session | | |
| | | |
| Transport | | Transport (TCP/UDP/...) |
| | | |
| Network | | Internet (IP) |
| | | |
| Data Link | | |
| | | Network Access |
| Physical cYEL | | cYEL|
+-----------------+ +-------------------------+
===== HTTP/TCP-Streaming (1) =====
HTTP-Streaming = Application/Session-Layer-Streaming
\\
**Vorteile:**
* sieht aus wie normaler Web-Traffic (geht also durch die meisten Firewalls)
* keine Paketverluste (TCP!)
===== HTTP/TCP-Streaming (2) =====
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
===== Exkurs: (mal wieder) sample clocks =====
\\
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.
===== Alternative: RTP/UDP-Streaming (1) =====
\\
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
===== Alternative: RTP/UDP-Streaming (2) =====
\\
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.
===== Fazit =====
\\
* 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
===== The End =====
\\
Danke für Eure Aufmerksamkeit.