Grundlagen Live-Streaming

View page as slide show


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

Signalkette

  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

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


2. Bildregie - Signalfluß (1)

2. Bildregie - Signalfluß (2)

2. Bildregie - Signalfluß (3)

2. Bildregie - Uebersicht

2. Bildregie - Fernbedienung

  • BCF2000 (MIDI) → MIDI to OSC → DVswitch

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

4. Video Streaming/Segmentation (1)

4. Video Streaming/Segmentation (2)

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


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/>

Netzwerk-Schichten-Modelle

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:

  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.

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.

 
wiki/dvswitch_slides.txt · Last modified: 12.05.2014 07:37 by rgareus