PDF [422 kB] - bei der IBH IT-Service GmbH

ibh.de

PDF [422 kB] - bei der IBH IT-Service GmbH

IP Video Streaming

Einleitung

IP Video Streaming

Ein Erfahrungsbericht

◆Das ursprüngliche Internet

● Telnet, FTP und Email

● Gemeingut Internet – begrenzte Ressourcen

● Kommerzielle Explosion durch das WWW

◆Das heutige Internet

André Beck

IBH Prof. Dr. Horn GmbH

Gostritzer Str. 61-63

01217 Dresden

http://www.ibh.de/

support@ibh.de

1

● Immer mehr vorher unbekannte Bandbreite für immer mehr

Nutzer

● Vorreiter Audio – der MP3-Boom

● Video folgt Audio fast immer einige Jahre später

● Wir sind heute mitten in dieser Entwicklung

2

Internet vs. Intranet

Grundlagen

Herkömmliche Videoübertragung

◆Bandbreite im Internet wächst

◆Nach wie vor für die Nutzermehrzahl zu knapp für

Video

◆Situation in Intranets ist völlig anders:

● Die IP-Konvergenz ist nahezu abgeschlossen

● 100BaseTX zum Desktop

● 1000Base im Backbone

● Zunehmend VLANs nach 802.1pQ

● Unterstützung von 802.1p ein willkommener Nebeneffekt

◆Bandbreite in Intranets heute meist ausreichend

◆Phase 1 des Projektes – Grundlagen lernen

◆Herkömmliches Video und TV

● Entwicklung, die über ein Jahrhundert Technikgeschichte

umfasst

● Paradigma #1: Rückwärtskompatibilität

● Seit ca. 1980 ist das System technisch veraltet

● HDTV ist, zumindest in Deutschland und Europa, ein

Trauerspiel

● Jetzt HDTV-Welle in den USA – Hoffnung auf Einfluss auf

den europäischen Markt

3

4

Grundlagen

TV Standards

Grundlagen

TV Standards

◆Die Geschichte des TV

◆Europa zieht nach

● 1872 – Entdeckung der photoresistiven Eigenschaften von

Selen

● Ursprünglich mit führend in der Entwicklung, aber WKII wirft

alle zurück

● 1884 – Paul Nipkow und seine Scheibe – die Ära des

mechanischen TV

● 1926 – Erste brauchbare Ergebnisse

● Europa einigt sich auf CCIR als s/w-Standard

● 50er Jahre: Henri de France entwickelt SECAM, Walter

Bruch entwickelt PAL

● 1931 – Viele Ingenieure haben jahrelang am elektronischen

TV entwickelt – Manfred von Ardenne demonstriert es als

erster öffentlich

● 1965 – Der große Bruch, Europa einigt sich nicht

◆ SECAM in Frankreich

◆ SECAM-Ost im OIRT-Raum sowie der DDR

● 1933/34 – Ikonoskop und TV-Systeme mit 240 Zeilen

● 1941 – NTSC als Standard angenommen

◆ PAL im restlichen Westeuropa

◆Heute dominieren NTSC und PAL

● 1953 – NTSC Farbstandard

● PAL steht auch häufig als Sammelbegriff für CCIR

5

6

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 1


¡

IP Video Streaming

Grundlagen

Das Videosignal

Grundlagen

Farbe ins Bild

◆Zeilenweise Bildabtastung

● Analoges Helligkeitssignal als Bildinformation

● Zeilen- und Bildaustastsignale zur Synchronisation

● Bildaustastsignal BAS (Composite)

● Es gibt keine Pixel – analoges Signal mit typisch 5 bis 6MHz

Auflösung

● Auflösungsangabe durch Linien – nicht zu verwechseln mit

Zeilen

● Angenommenes Seitenverhältnis 4:3 – aber nicht implizit

kodiert ( 16:9 anamorph machbar)

● Diskrete Zeilen: 525 (NTSC) bzw. 625 (CCIR)

7

◆Hauptziel Rückwärtskompatibilität

● s/w-TV muss weiterfunktionieren

● Man kann nicht einfach RGB ausstrahlen

● Farbraumtransformation von RGB nach YUV

◆ Y ist das reine Helligkeitssignal

◆ U und V sind Farbdifferenzsignale

◆ YUV und RGB sind praktisch verlustfrei ineinander überführbar

● Y wird ausgestrahlt wie immer

● U und V werden zusammen auf einen Farbträger C

moduliert und dem Signal beigemischt

● NTSC, PAL und SECAM unterscheiden sich in der Art, wie

U und V ermittelt und zu C gemischt werden

8

Grundlagen

Das Farbsignal

◆Farb-BAS (FBAS) bzw. Composite

◆Intermodulationsprobleme der Signalmischung

◆Höherwertige Übertragung durch Vermeidung der

Mischung:

● S-Video: BAS und C werden getrennt übertragen, aber C ist

immer noch anfällig

● Komponenten: Drei Signale für höchste Qualität

◆ Europa präferiert RGB über SCART (dabei liegt Sync zusätzlich in Form

eines FBAS vor)

◆ Rest der Welt präferiert YUV (YCrCb), wobei Sync im Y vorliegt, also Y

ein BAS ist.

9

◆NTSC

Grundlagen

NTSC vs. CCIR

● 525 Zeilen, davon 480 sichtbar. 30Hz Bildfrequenz.

● Bekannte Probleme mit Farbinterferenzen („Never The

Same Color“) 29.97Hz verbessert die Lage

◆CCIR

● 625 Zeilen, davon 575 sichtbar. 25Hz Bildfrequenz.

● Verschiedene Farbsysteme mit eigenen Problemen (aber

besser als NTSC)

● PALplus zur rückwärtskompatiblen Ausstrahlung von 16:9

ohne übermäßigen Verlust an Vertikalauflösung

◆Bei beiden Verfahren dauert eine Zeile 64µs

10

Grundlagen

TV vs. Kinofilm

◆Filmprojektion im Vollbild

● Schneller Weitertransport durch Mechanik

● Bildfrequenz von 24Hz

● Bildverbesserung durch Abdeckung

● Flimmern

● Mehrfache Abdeckung täuscht 48Hz oder 72Hz

Bildfrequenz vor

◆TV mit Bildfrequenzen von 25Hz bis 30Hz

● Die Probleme ähneln sich stark

● Im Gegensatz zum Film ist das frühe TV nicht in der Lage,

ein Bild einfach zwischenzuspeichern Die „Abdeckung“

muss vom Sender ausgehen

11

Grundlagen

Interlace

◆Die Lösung: Das Zeilensprungverfahren

● Das TV-Signal wird mit verdoppelter Bildfrequenz und

halbierter Zeilenzahl ausgestrahlt

● Die Halbbilder (Fields) erscheinen also mit 50Hz bzw. 60Hz

nacheinander auf dem Bildschirm

● Die vertikale Auflösung wird beibehalten:

◆ 1. Halbbild enthält ungerade Zeilen des Originals

◆ 2. Halbbild enthält gerade Zeilen des Originals

mit zwei Halbbildern wird die volle Vertikalauflösung übertragen

● Ausnutzen der Halbbildnatur für flüssigere Bewegung

◆Interlace heute: Ein Bremsklotz

12

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 2


IP Video Streaming

Grundlagen

Interlace und Filmtransfer

◆Deinterlace: angewandte Magie

● In echtem Videosignal fehlen 50% der Informationen, die für

eine progressive Aufbereitung nötig wären

● Interpolation der Information mit zunehmendem Aufwand

(100Hz TVs)

● Hochkomplexe Verfahren in Hardware (Philips Natural

Motion) oder Software (DScaler)

◆Filme stammen von Vollbildern

● Videotransfer von Filmen ist interlaced, aber stammt von

Vollbildern Rückgewinnung denkbar

● NTSC: 3:2 Pulldown

● CCIR/PAL: Speedup von 24Hz auf 25Hz.

◆CCIR 601

Grundlagen

Digitale Videoformate 1

● Digitalisierung von Video mit 13.5MHz Samplingrate

● Digitalisiert werden nur die sichtbaren Zeilen:

◆ CCIR: 576 Zeilen

◆ NTSC: 480 Zeilen

● Horizontal 720 Pixel (d.h. die Pixel sind nicht quadratisch)

● Speicherung als Komponenten Y, U und V, quantisiert mit

8Bit (später auch mehr)

● Reduzierung der Farbkomponenten U und V empfohlen

(Subsampling, z.B. 4:2:2)

● Rohdaten haben enorme Bandbreite

13

14

Grundlagen

Digitale Videoformate 2

◆Basierend auf CCIR 601

● D1 (Sony/BTS): 4:2:2 mit 4 Tonkanälen, 173MBit/s

● D2 (Ampex/Sony): Nur Composite, 115MBit/s

● D3 (Panasonic): Nur Composite, 110MBit/s

● D5 (Panasonic): 4:2:2 mit 8-10Bit, bis 207MBit/s

● D6 (Sony/BTS/Hitachi): 4:2:2, HDTV, bis 860MBit/s

◆Kompression – so verlustarm wie möglich

● DigiBeta (Sony), DCT (Ampex): 2:1

● Consumer: DV (Sony/Panasonic/JVC) 4:2:0, 8Bit, 5:1

24MBit/s

● Semiprofessionell: DVCAM, DVCPRO, DVCPRO50,

Betacam SX und D9 Digital S. 22-50MBit/s.

Grundlagen

Videokompression

◆Wie die Datenraten reduzieren?

● Herkömmliche Verfahren (LZ, Huffman) erreichen auf

digitalisiertem Video durchschnittlich 2:1 oder weniger

● Die Redundanz ist auf höherer Ebene angesiedelt

● Notwendigkeit verlustbehafteter Kompression

● Humanphysiologische Datenreduktion

● Discrete Cosine Transform (DCT) für Bilddaten:

◆ Bilddaten in alternative Darstellung als Frequenzkoeffizienten überführen

◆ Die Koeffizienten quantisieren, wobei viele wegfallen

◆ Die Ergebnisse entropiekodieren, etwa mit Huffman

◆ JPEG

15

16

Grundlagen

Deltakompression

◆DCT allein ist gut für 3:1 bis 5:1

● DCT neigt bei höheren Raten zum „Kacheln“

● Was bei Einzelbildern noch nicht auffällt, wird bei Video

schnell als temporaler Artefakt sichtbar

◆DCT reduziert die spatiale Redundanz

◆Video ist auch (und besonders) temporal redundant

◆Kodierung von Videoframes als Deltainformation zu

vorangegangenen Frames

◆Deltakompression & Paketverlust

Grundlagen

MPEG 1

◆MPEG1 wurde primär für Video-CD entwickelt

● System Stream mit 1x Datenrate, gemuxt aus

◆ MPEG1 Video Stream mit 1150kBit/s

◆ MPEG1 Layer2 Audio Stream mit 224kBit/s

◆ CIF Auflösung (352x288@25 bzw. 352x240@30)

◆ Progressiv mit NTSC/CCIR Vollbildrate: Es fällt Interlace weg

◆ Ohne Interlace praktisch kaum für Videomaterial geeignet, nur für

Filmtransfers

◆ Intention war „so gut wie VHS“, konnte aber nur unter idealen

Bedingungen erreicht werden, die Laufzeit der CD (74min) tat ein übriges

– VCD hat sich (außerhalb des asiatischen Raums) nicht durchgesetzt.

17

18

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 3


IP Video Streaming

Grundlagen

MPEG 2

Grundlagen

MPEG

◆MPEG2 als Nachfolger von MPEG1

● Unterstützt explizit Interlace

● Auflösungen bis 1920x1152 (HDTV) möglich

● Überarbeitetes Audio (Mehrkanal) und System

● Lizenzpflichtig

● Profile wie MP@ML erleichtern die Implementation der

Decoder in Hardware

● Grundlage für DVB und DVD, auch auf S-VCD

● Heute verbreitetste Videokompression, in MP@ML bei

Bitraten oberhalb 4MBit/s meist hochwertiger als S-VHS.

19

◆Konzept

● Input ist YUV mit verschiedenen Farbsubsamplings:

◆ MPEG1 4:2:0

◆ MPEG2 4:2:0, 4:2:2 und 4:4:4

● Zerlegung des Bildes in Makroblöcke (16x16)

● Ausnutzung zeitlicher Redundanzen durch Motion

Compensation

◆ Prediction: Makroblock tauchte ähnlich in einem vorigen Frame auf, es

wird ein Motion Vector darauf erzeugt

◆ Bidirectional Prediction: Makroblock lässt sich durch Interpolation zweier

Blöcke aus einem vorherigen und einem nachfolgenden Frame annähern

zwei Motion Vectors

¡

● Ausnutzung räumlicher Redundanz durch DCT

20

Grundlagen

MPEG Frametypen

◆Kodierung von Makroblöcken

● Makroblöcke können direkt kodiert werden (Intra), oder als

predicted oder bidirectional predicted Makroblock

● Welche Kodierung erlaubt ist, wird durch den Typ des

Frames weiter eingeschränkt:

◆ I-Frames: nur intracodierte Makroblöcke

◆ P-Frames: intracodierte und predicted Makroblöcke

◆ B-Frames: intracodierte, predicted und bidirectional Makroblöcke

● Typische Framesequenz: IBBPBBPBBP

Limitiert Fehlerfortpflanzung der Deltakompression

● GOP – Group of Pictures

● Übertragungsreihenfolge vs. Darstellungsreihenfolge

21

Grundlagen

MPEG 4

◆Konsequente Weiterentwicklung des MPEG-

Frameworks

● Gesamtkonzept ist höchst komplex

● Elementary Streams ähneln noch denen von MPEG2, sind

aber effizienter

● Zwei Metalayer oberhalb der ES: Objektbildung und

Szenenarrangement Nicht mehr einfach nur Video

◆ Sprachsynthese

◆ Skalierende Komplexität

◆ Integration von Bildern und 3D-Objekten (auch nichtrechteckig und mit

Alpha)

◆ Face Animation

◆MS, Apple, ISMA und das Lizenzdilemma

22

Grundlagen

Das unvermeidliche OSI-Modell

Grundlagen

IP und Realtime

7

6

5

4

Endknoten

Application Layer

Presentation Layer

Session Layer

Transport Layer

Zwischenknoten

Protokoll

Protokoll

Protokoll

Protokoll

Endknoten

Application Layer

Presentation Layer

Session Layer

Transport Layer

◆IP ist best effort delivery:

● Paketverlust

● Paketvervielfachung

● Änderung der Paketreihenfolge

◆Routing, Queuing und Forwarding

3

2

1

Network Layer

Data Link Layer

Physical Layer

Router

Network Layer

Data Link Layer

Physical Layer

Ingress

Interface

Interface

Input

Queue

Forwarding

Engine

Interface

Output

Queue

Egress

Interface

23

24

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 4


¡

IP Video Streaming

Grundlagen

TCP und UDP

◆Transmission Control Protocol

● Flusskontrolle, sichergestellte Integrität des Datenstroms

● Für Video nur begrenzt geeignet, da wiederholte

Übertragung bei Fehlern implizit im Protokoll

● Nur Unicast

◆User Datagram Protocol

● Erlaubt Applikationsprotokollen direkten Zugriff auf die

Datagramm-Semantik von IP

● Optionale Datenintegrität

● Broadcast und Multicast

Grundlagen

RTP

◆Real Time Protocol

● Grundstock von Funktionen, die in jedem paketorientierten

Protokoll für Mediastreaming nötig sind:

◆ Profile (Payload Type Codes, Headeraufbau und Extensions) sowie

Formate (Aufbau der im Profil vereinbarten Payloads)

◆ Unicast, Broadcast und Multicast

◆ Typischerweise auf UDP aufgesetzt

◆ Sequenznummern kodieren die Paketreihenfolge

◆ Zeitstempel kennzeichnen zusammengehörige Pakete und die

Darstellungsreihenfolge (MPEG!)

◆ RTCP zur Steuerung und Qualitätsüberwachung

● Verwendet u.a. von den MBONE-Tools

25

26

Grundlagen

Video & IP Multicast

◆Ressourcenschonendste 1 many Distribution

● Paket wird jedem Empfänger zugestellt, aber auf jedem

PTP-Link und in jedem MA-Netz nur genau einmal

übertragen.

● MA-Netze wie Ethernet und FDDI sind Broadcastnetze

● Lösung des Problems individueller Erreichbarkeit mit MAC-

Adressen

● Zugang zum Broadcast-Mechanismus über spezielle MAC-

Adresse ff-ff-ff-ff-ff-ff (Broadcast-MAC)

Zieladresse Quelladresse Typ Payload FCS

6 Byte 6 Byte 2 Byte 46 - 1500 Byte 4 Byte

27

Grundlagen

Broadcast auf L2 und L3

◆Broadcast ist ein L2-Mechanismus

● Wie von IP aus ansprechen?

● Spezielle Adressen auf IP-Ebene werden auf L2-Broadcasts

abgebildet:

◆ Local Net Broadcast 255.255.255.255

◆ Directed Broadcast – Hostanteil im Zielnetz ist all ones

● Z.B. Audio-Pakete an eine der Broadcast-IPs schicken, um

alle Rechner im LAN zu erreichen

Radio Free Ethernet

◆Broadcast empfängt jeder

● NIC gibt es prinzipiell nach oben, erst höhere Schichten

droppen es Hohe Bandbreiten ineffizient

¡

28

◆ Lösung: L2 Multicast

Grundlagen

Multicast auf L2 und L3

● Spezielle Klasse von MAC-Adressen, die nicht NICs zugeordnet

werden, sondern Empfängergruppen

● NIC hört neben ihrer Unicast- und der Broadcast-MAC zusätzlich auf

eine Anzahl von Multicast-MACs

◆ Abbildung auf IP

● RFC 1112 reserviert den ehemaligen Class-D Raum für

Multicastadressen (224.0.0.0 – 239.255.255.255)

● Rechner treten Multicastgruppen bei, indem sie deren Adresse binden

(IP_ADD_MEMBERSHIP)

● Abbildung auf L2 ist abhängig vom konkreten L1/L2.

● Ethernet: Die unteren 23Bit der Multicast-IP werden in die unteren 23Bit

von 01-00-5e-00-00-00 eingeblendet

Grundlagen

IP Multicast Routing

◆ Broadcastdomain

● In einer Broadcastdomain funktioniert IP Broadcast und IP

Multicast ohne weitere Maßnahmen

● In einer gerouteten Infrastruktur werden Broadcasts nicht

verbreitet

◆ Routed Domain

● IP Multicast kann explizit verbreitet werden, das erfordert

aber spezielles IP Multicast Routing

● Protokoll IGMP

● Multicastrouter, IGMP Query und IGMP Report

● IGMPv2 und IGMP Leave

● Multicastrouting und die TTL

29

30

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 5


IP Video Streaming

Grundlagen

Dense IP Multicast Routing

◆ Dense Mode

● Annahme: Nahezu jeder im Netz will empfangen

● Flooding & Pruning ähnlich STP

● RPF gegen Loops

● Verbreitung wird vom Sender forciert

● Nicht interessierte Empfänger bestellen explizit ab

● Pruning wird regelmäßig vergessen und muss erneuert

werden, damit neue Empfänger beitreten können

● MBONE, DVMRP, MOSPF, PIM-DM

Grundlagen

Sparse IP Multicast Routing

◆ Sparse Mode

● Dense Mode skaliert im Internet nicht

● Sparse Mode wird vom Empfänger getriggert

● Empfänger und Sender verabreden sich an sogenannten

Rendezvous Points

● Shared Tree mit RP als Wurzel

● Wichtigster Vertreter: PIM-SM

◆ PIM Join (Empfänger)

◆ PIM Register (Sender), Encapsulation, Source Specific Join vom RP zum

Sender und RegisterStop

◆ Bildung eines Shortest Path (Umgehung des Shared Tree) zwischen

Empfänger und Sender

31

32

Grundlagen

PIM-SM

◆ Beispiel – Beitritt zu einer PIM-SM Domain

S1

MR1

MR3

RP

MR

S2

MR

Übertragungssysteme

◆Pioniere und Nachzügler

◆Proprietäre und offene Systeme

◆Digital Rights Management

◆Die Lizenzproblematik

◆Plattformen

MR2

MR

Schritt

1

G 2

3

4

MR

33

34

Real Media

◆Streaming Pionier

◆Komponenten des Systems:

● RealProducer

● RealServer

● RealPlayer

◆Das Real Streamformat

● Dateien und Streams

● Mehrere Bandbreiten gemuxt

● Bei CIF ab ca. 1000kBit/s gut und ab 1500kBit/s hochwertig

● Bild ruckelte ca. aller 2s

Real Media – die Architektur

◆Zusammenspiel der Komponenten

Real

Producer

Live

A/V- Quellen

Real

Real

Producer

Server

Real

Producer

RealMedia

Dateien

35

Real

Player

Real

Player

Real

Player

Real

Player

Real

Player

Real

Player

Real

Player

36

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 6


IP Video Streaming

Real im Testaufbau

Real im Testaufbau 2

◆Einfachster Fall: Broadcastdomain

Komplexer:

FastEthernet6/0

ISP Backbonesegment

FastEthernet0/0

Core Router Cisco7206

Access Router 7204VXR

Video- Kamera

S- Video

Videograbber

Soundkarte

RealProducer Plus

RealServer

Diverse OS

RealPlayer 8

RealOne Player

Geroutete

Infrastruktur

ISP Serversegm ent

Internet Service Provider

FastEthernet0/0

PA- MC- 8E1

(8x 2Mbps)

G.703/E1

Mikrofon

Grabber

Sound

Karte

1GHz Athlon

1GHz Athlon

D2MS WAN Festverbindungen

Kunde m it D2MS

WIC- 1T

Serial0

Cisco1603

X.21 X.21/G.703- E1

Kunde mit

2x D2MS

VWIC- 2MFT- E1

2x 2Mbps G.703/E1

Cisco2650

Ethernet0

Terminal Adapter

Fas tEthernet0/0

Broadcast Domain

37

38

Real und IP Multicast

◆Backchannel Multicast

● Client per TCP mit Server verbunden

● Aushandlung der Multicastgruppen im Protokoll (PNA oder

RTSP)

● Bug im Player verhindert Funktion mit RTSP

◆Scaleable Multicast

● Speziell zu lizenzieren

● Client bekommt SDP-Datei mit Informationen zum Stream

auf irgendeinem Weg (z.B. HTTP)

● Theoretisch beliebig skalierbar

◆Qualität

Real Fazit

● Aus unserer Sicht erreicht man hochwertige Qualität mit

einem aktuellen PC als Encoder durch:

◆ CIF-nahe Auflösung 384x288, beschnitten auf 380x284, 25fps

◆ Gesamtbitrate von 1492kBit/s

● Niedrigere Bitraten führen schnell zu unerträglichen

Artefakten. Eine höhere Auflösung war auf unserem

Testsystem nicht mehr in 25fps zu erreichen (CPU).

◆Vorteile

● Automatische Abstimmung inkl. Streamparameter

● Exakte Einhaltung der Bitrate

● Verfügbarkeit auf zahlreichen Plattformen

39

40

Microsoft Media

◆VfW, Codecs, AVI

◆DirectShow

◆ASF, WMV, WMA & Windows Media

◆MS MPEG4V2 und MPEG4V3

◆DivX ;-)

◆Windows Media Streaming

Microsoft Media Komponenten

◆Windows Media Encoder

● 7.1 mit GUI

● 8 mit CLI

◆Windows Media Player

◆Windows Media Services

● Optionale Komponente, der Media Player kann auch direkt

per TCP mit dem Encoder Verbindung aufnehmen

● Nur für NT4 und integriert in W2k Server

● Zwingend notwendig für Multicast

41

42

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 7


IP Video Streaming

Microsoft Media Architektur

◆Zusammenspiel der Komponenten

Windows Media Testaufbau

◆Testaufbau Broadcastdomain

Live

A/V- Quellen

Media

Encoder

Media

Encoder

TCP Aufbaurichtung

der HTTP- Verbindung

Media

Services

Windows

Media

Dateien

Video- Kamera

S- Video

Win2k Prof.

Videograbber

Soundkarte

Windows Media

Encoder 7.1

Win2k Server

Windows Media

Services

800MHz Duron

Win2k Prof.

Windows Media

Player

1GHz Athlon

Media

Encoder

Mikrofon

Grabber

Sound

Karte

1GHz Athlon

TCP Aufbaurichtung

der HTTP- Verbindung

Broadcast Domain

Media

Player

Media

Player

Media

Player

Media

Player

Media

Player

´Media

Player

Media

Player

43

44

Windows Media Parameter

◆Parameter ähneln Real

● Wir benutzten den Codec MS MPEG4V3

● Auflösung war CIF-nah 384x288 (Crop nicht möglich, Rand

nur schwarz abgedeckt)

● Eigenes Profil spezifiziert (wie auch bei Real) für 1492kBit/s

Gesamtbandbreite und 25fps.

◆Beobachtungen

● Hochwertiges Bild ähnlich Real bei vergleichbarer Bitrate

● Häufig unerklärliche Zusammenbrüche der Wiedergabe

selbst unter idealen Bedingungen

45

Windows Media und Multicast

◆ Ähnlich Scalable Multicast

● MS verwendet ein Konzept, das Scalable Multicast gleicht,

aber nicht die SDP-Dateien und das Format aus dem

RTSP-Umfeld (IETF) verwendet, sondern ein eigenes

(NSC)

● Jede Änderung an Encodingparametern erfordert


◆ Encodingparameter neu durch den Encoder exportieren lassen (in eine

ASF-Datei)

◆ Encodingparameter in Windows Media Services einlesen

◆ Neue NSC-Datei erzeugen und den Clients zugänglich machen

Bitrate schwankt stark, auch über den eingestellten

Maximalwert – Besondere Maßnahmen (Priority Queuing)

notwendig

46

Windows Media Fazit

◆ Ähnlich brauchbar wie Real

◆ Außer in trivialen Fällen Serverlizenzen nötig

◆ Hoher Aufwand für Multicast, kein Unicast-Fallback

für den Media Player

◆ Traffic Pattern ist bursty und neigt zum

Überschreiten der Bitrate

◆ Zielgruppe mit Windows Media Player enorm groß

◆ Player und Encoder verursachen keine

Zusatzkosten

Cisco IP/TV

◆ Von Precept begonnen und durch Aufkauf zu Cisco

gelangt

◆ RTP/RTCP basiertes, auf Multicast fokussiertes

System, konsequente Weiterentwicklung der

MBONE-Tools

◆ Primäre Zielgruppe ist der professionelle Bereich

(Broadcast, Kabelnetze)

◆ MPEG1, MPEG2 und andere Formate

◆ Windows only

47

48

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 8


IP Video Streaming

Cisco IP/TV

◆ Komponenten:

● Cisco IP/TV Server



◆ Sendet Unicast (on demand) und Multicast (scheduled) anhand seiner

Content Database

Cisco IP/TV Content Manager

◆ Erzeugt die Content Database für den Server

Cisco IP/TV Viewer

◆ Holt sich die Liste mit empfangbarem Content vom Server oder Content

Manager und erlaubt den Beitritt zu scheduled und den Start von on

demand Programmen

Cisco IP/TV

◆ Zusammenspiel der Komponenten

IP/TV

Content Manager

Mediendateien

Live

A/V- Quellen

IP/TV

Server

IP/TV

IP/TV

IP/TV

IP/TV

IP/TV

IPT/V

IP/TV

Viewer

Viewer

Viewer

Viewer

Viewer

Viewer

Viewer

49

50

◆Encoding

Cisco IP/TV

● Cisco IP/TV beinhaltet keine spezielle Encoderkomponente

● Es wird davon ausgegangen, dass für hochwertiges

Encoding eine MPEG2 Capture Card eingebaut ist, die Half-

D1 oder Full-D1 unterstützt

● Ein gewöhnlicher VfW-Grabber wird erkannt, uns gelang

aber nur H.261 Encoding in unbefriedigender Auflösung.

● MS MPEG4V3 sollte ebenfalls möglich sein, die

Demoversion oder andere Umstände ließen das aber nicht

zu

◆Profitool

Cisco IP/TV Fazit

● Fokussiert auf hochwertig vorproduziertes Material und Live

MPEG2 Capturing mit Hardwaresupport

● Qualität nur abhängig von der Bitrate

● MPEG2 liefert bewährt gute bis sehr gute Ergebnisse, bei

MP@ML und über 4MBit/s ist DVD-Qualität machbar

● Shrink Wrapped als Hardware-Software-Bundle verfügbar

● Besonders für Intranet/LAN geeignet (hohe Bandbreite,

Multicast)

51

52

MPEG4IP

◆Neues Projekt aus dem OpenSource-Umfeld

◆Einige der vormaligen IP/TV-Entwickler bei Cisco

waren mit dem Konzept (Windows only, closed

source) unzufrieden

◆Ziel: OpenSource, Open Standards, Open Streaming

◆Grundlage ist MPEG4 und ISMA

◆Entwicklungsstand ist frühe Betaversion

◆Plattform z.Z. Linux

53

MPEG4IP Komponenten

◆Live Encoder mp4live

● Encodet von V4L-Grabber und Soundkarte

● Schreibt Datei oder schickt RTP Unicast oder Multicast an

eine Zieladresse

● Formatübermittlung mit SDP

◆Player mp4player/gmp4player

● Empfängt per RTSP/TCP oder Multicast

◆Streaming Server

● Der Server ist optional und ermöglicht den Zugriff des

Players mit RTSP/TCP (Unicast)

● Es kommt Apples DSS zum Einsatz (Darwin Streaming

Server)

54

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 9


IP Video Streaming

MPEG4IP Architektur

◆Zusammenspiel der Komponenten

Playlist

mp4live

Broadcaster

Unicast RTP

Live

A/V- Quellen

mp4live

Darwin

Streaming Server

Multicast RTP

mp4live

Unicast RTP

Quicktime

Dateien

(ISO MPEG4)

RTSP Triggered

Unicast RTP

MPEG4IP Beobachtungen

◆Wir testeten mit ähnlichen Parametern wie Real:

● CIF-Auflösung ohne Crop (352x288)

● 25fps Framerate

● Gesamtbitrate 1492kBit/s gemuxt aus

◆ Audio AAC 160kBit/s

◆ Video MPEG4 1332kBit/s

◆Bildqualität nicht vergleichbar

● Blockartefakte, Unschärfen

● Erst ab ca. 2200kBit/s gut

Weiteres Tuning nötig

mp4player

mp4player mp4player mp4player mp4player mp4player mp4player

55

56

MPEG4IP Fazit

◆ Work in Progress:

● Encodingqualität nicht mit MS und Real vergleichbar

● Player instabil

● Wiederaufsetzen von Sendungen

● Probleme mit Windows-Playern (QT, Real mit Envivio)

◆Vielversprechend

● Fortgeschrittenstes Projekt

● MPEG4 und AAC

● ISMA Kompatibilität

● Potentiell kompatibel mit Apple QT 6

● Open Source

Andere Lösungen

◆FFMPEG/FFSERVER

◆GStreamer

◆MBONE-Tools (vic, rat, sdr)

57

58

Resultate

◆Hohe Qualität ist wesentlich für die Akzeptanz

◆Sie ist nur mit Bitraten jenseits der Megabitgrenze

wirklich erreichbar

◆Diese Bitraten stehen z.Z. primär in Firmennetzen,

Intranets und Providerbackbones zur Verfügung

◆In diesen Netzen sind heute Lösungen möglich, die

im Internet kaum Publikum fänden, weil kaum jemand

die nötigen Bandbreiten hat

◆Near Video on Demand ist ein gangbarer

Kompromiss für ISPs

59

©202IBHProf.Dr.HornGmbH©202IBHProf.Dr.HornGmbH© 2002

IBH Prof. Dr. Horn GmbH 10

Weitere Magazine dieses Users
Ähnliche Magazine