AG Medieninformatik

Bachelorarbeit

Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu r ein Online-Ru ckenstudio

Patrick Schnetger

Juli 2013

Erstgutachter: Zweitgutachter:

Prof. Dr. Oliver Vornberger Dr. Jutta G oers

Zusammenfassung
Das hier ist eine Zusammenfassung. . . .

Abk urzungsverzeichnis

Inhaltsverzeichnis
1 Einleitung 1.1 ViaVitale . . . . . . . . . . . . . . . . 1.1.1 Team . . . . . . . . . . . . . . 1.2 Konzept . . . . . . . . . . . . . . . . . 1.3 Zielsetzung . . . . . . . . . . . . . . . 1.3.1 Livestreaming . . . . . . . . . . 1.3.2 Video-on-Demand . . . . . . . 1.4 Kurzbeschreibung der Webanwendung 1.5 Verwendete Technologien . . . . . . . 1 1 1 1 2 3 3 3 3 5 5 6 6 8 10 11 11 11 11 12 12 13 13 15 15 17 21 27 28

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

2 Video-Komponente 2.1 Livestreaming . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Herausforderungen . . . . . . . . . . . . . . . . 2.1.2 Client-Server Architektur . . . . . . . . . . . . 2.1.3 C++ RTMP SERVER . . . . . . . . . . . . . . 2.1.4 Flash Media Live Encoder . . . . . . . . . . . . 2.1.5 Flowplayer . . . . . . . . . . . . . . . . . . . . 2.1.6 Zusammenfassung Livestreaming-Komponente 2.2 Video-on-Demand . . . . . . . . . . . . . . . . . . . . 2.2.1 Amazon Web Services . . . . . . . . . . . . . . 2.2.2 FFmpeg . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Paperclip . . . . . . . . . . . . . . . . . . . . . 2.2.4 Bitraten . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Zusammenfassung VoD-Komponente . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

3 Schlussteil 3.1 Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Literaturverzeichnis 5 Abbildungsverzeichnis 2.1: users.lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 vplayback.lua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 rtmpappprotocolhandler.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 rtmpappprotocolhandler.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 32

vi

Kapitel 1

Einleitung
Hier kommt noch eine Einleitung hin. Diese schreibe ich jedoch erst wenn die Arbeit fertig ist!:!:!:!:!:!:! :)

1.1

ViaVitale

Firma mit Sitz auf Mallorca (www.pilatesaufmallorca.com). Gr undung 2002. Inhaber Heike und Thomas Niemeier Ausgebildete Trainer im Bereich (R ucken-)Pilates, Personaltraining und Kinderboxen.

1.1.1

Team

Heike und Thomas als Inhaber mit der Gesch aftsidee. Zust andig f ur Organisation und Planung. Webdesigner, J urgen Jaskowiak. Rene und Sascha Gerritsen (www.nerdbrothers.de) Entwicklung und Integration der einzelnen Komponenten + Ver oentlichung des Gesamtsystems. Junges Start-Up Entwicklerteam. Markus f ur Video und Tonproduktion. Henning Str uber als Student f ur seine Bachelorarbeit. Verantwortlich f ur die Entwicklung der Social Network Komponente. Patrick Schnetger f ur die Entwicklung der Video-Komponente. Sp ater noch Firmen f ur Marketing usw. . . .

1.2

Konzept

Die Firma ViaVitale hat bei diversen Treen ein komplexes Konzept zur Gr undung des ersten Onlien R uckenstudios vorgestellt. Das Kernprodukt soll eine Social-Media-Network Webanwendung sein, die eine besondere Nische in dem stark wachsenden Online Fitnessstudio-Segment ausf ullt.

Kapitel 1. Einleitung

Neben klassischen R ucken ubungen bekommt das Online-Angebot durch das Verfolgen der Yoga und Pilates Philosophie einen besonderen Schwerpunkt. Nicht nur das Training selbst sonder auch die Verbindung zwischen k orperlicher und geistiger An- und Entspannung steht dabei im Vordergrund. Die Webanwendung soll nicht nur kostenpichtige Inhalte sondern auch Kostenfreie Inhalte bieten. Eine SOS-Seite soll neuen Nutzern bei akuten Problemen schnelle Hilfe anbieten um schlimmeres zu vermeiden. Arzte, Trainer und Physiotherapeuten ver oentlichen in einem Blog regelm aig Artikel zum Thema R ucken und Fitness. Kurze Trainingsvideos und Beispieltrainingspl ane geben zudem einen Einblick was ein Abo-Konto f ur Vorteile bietet. Ein Abo soll monatlich EUR 12,95 kosten und zudem jederzeit k undbar sein. Wer sich f ur ein Abo entscheidet bekommt neben allen sozialen Funktionen (R uckenfreunde nden, Trainingspl ane, Erfolge, Freundschaften und Termine teilen) auch Zugang zu regelm aig ausgestrahlten Livesendungen und einer Vielzahl an aufgezeichneten Trainingsvideos. Ein Erfolgssystem soll die Kundenbindung erh ohen und zu einer l angeren Mitgliedschaft beitragen. Eine eigene Produktlinie soll u onnen ber den eigenen Online-Shop vertrieben werden. Dort k Nutzer auch Mobile-Apps oder Trainingswochenenden auf Mallorca direkt kaufen. Wer sich eine pers onlichere Betreuung beim Training w unscht kann hier zudem Stunden bei einem ausgebildeten Trainer buchen. Erg anzend zur Webanwendung soll eine App f ur IOS und Android Tablets und Smartphones entwickelt werden, welche es Nutzern erm oglicht auch Mobil auf alle Inhalte zugreifen zu k onnen. Um die Zielgruppe zu erweitern m ochte die Firma ViaVitale auch an Firmen herantreten und eine eigene Desktopanwendung anbieten. Diese soll in regelm aigen Abst anden zu kurzen Pausen motivieren in denen Ubungen zur Haltungsverbesserung oder Entspannung durchgef uhrt werden. Alle Anwendungen sollen neueste Technologien verwenden um ein zeitgem aes Produkt auf den Markt zu bringen.

1.3

Zielsetzung

Aus dem vorgestellten Konzept wurde die folgende Zielsetzung f ur die Video-Komponente herausgearbeitet. Die Video-Komponente besteht aus zwei Teilen. Zum Einen die Livestreaming-Komponente und zum Anderen die Video-on-Demand-Komponente. F ur die Entwicklung beider Komponenten gilt es die Kompatibilit at zu den zur Zeit g angigen Endger aten unter der Beachtung der Breitbandverf ugbarkeit zu gew ahrleisten.

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

1.4. Kurzbeschreibung der Webanwendung

1.3.1

Livestreaming

Das Ziel der Livestreaming-Komponente ist es eine Empfehlung f ur eine geeignete Client- und Serverarchitektur zu liefern. Dabei wird bei allen beteiligten Systemen (Streaming Client, Streaming Server und Webanwendung) geeignete Hardware vorgestellt und eine sinnvolle Konguration der Software vorgeschlagen. F ur die Entwicklung und Einbindung soll so weit wie m oglich auf Open-Source-Software zur uckgegrien werden. Erg anzend sollen Konzepte und eigene Beispiele zur Sicherheit des Streaming Servers vorgestellt werden. Dazu geh ort die Serverseitige Validierung des Streaming-Clients, ein Authentizierungsmechanismus des Clients zum Server und die Validierung der Anwendung auf dem der Stream letztendlich abgespielt wird.

1.3.2

Video-on-Demand

Aufgezeichnete Livesendungen beziehungsweise gestellte Trainingsvideos sollen unter der Verwendung aktueller Technologien an den Nutzer gebracht werden. Videos sollen kategorisierbar und in nutzerspezischen Wiedergabelisten verwendet werden k onnen. Eine Empfehlung zur Absicherung der Videoinhalte solle ebenfalls vorgestellt werden. Wie beim Livestreaming sollen Videos nur von der Webseite selbst oder den zugeh origen Apps abgespielt werden k onnen. mal sehen ob ich das wirklich schreibe

1.4

Kurzbeschreibung der Webanwendung

Entwicklung der Webanwendung. Aufgeteilt in zwei Bereiche die als Empfehlung f ur das Gesamtsystem dient. Schwerpunkt social network und video streaming (live und on demand)

1.5

Verwendete Technologien

Ruby on Rails thin websockets paperclip aws-sdk haml ... Ajax PushServer Technologie javascript

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

4 jQuery Bibliothek c++ RTMP Server AWS FMLE metroUI (Demoseite) als CSS/HTML5 Framework Flowplayer

Kapitel 1. Einleitung

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Kapitel 2

Video-Komponente
Die Videokomponente umfasst zwei Bereiche. Zum Einen ein Livestreaming-Dienst und zum Anderen ein Video-on-Demand Angebot. Livestreaming verwendet open source technologien (c++ rtmp server, fmle, owplayer, ..) VoD verwendet bestehende AWS Infrastrukturen (Serverauslastung und Speicherplatz,. . . ) Datenbankdesign Manuelle Playlisten im Backend

2.1

Livestreaming

Die Livestreaming-Komponente verlangt anders als die sp ater vorgestellte Video-on-DemandKomponente die direkte Interaktion zwischen dem ViaViale-Team und der Hardware (Kamera und Computer). F ur die richtigen Kameraeinstellungen und Verkabelung ist XYZ vor Ort verantwortlich. Eine einfache Interaktion und Konguration des Livestreaming-Clients ist daher notwendig. Neben der Nutzerinteraktion spielt auch die Beachtung der unterschiedlichen Endger ate und Breitbandverf ugbarkeiten eine Rolle. Um die unterschiedlichen Breitbandverf ugbarkeiten abzudecken ist es notwendig den Video-Stream in unterschiedlichen Bitraten bereitzustellen. W ahrend station are PCs und Laptops mit aktuellen Browser keine Probleme mit dem RTMP-Protokoll haben muss f ur IOS und Android Ger ate ein alternatives Protokoll zum Einsatz kommen wenn man den Endnutzern keine zus atzliche Arbeit mit der Installation von Plugins o. a. machen m ochte Quelle. Nativ unterst utzen IOS Browser RTSP und Android Browser RTP ????. Entweder alllgemein verfasst. . . . Im folgenden wird eine Empfehlung aller beteiligten Computer Systeme gegeben. Diese Umfasst die Hard- und Software des Streaming-Clients und -Servers. Sowie m ogliche Kongurationen

Kapitel 2. Video-Komponente

und Einsch atzungen von Belastbarkeit und Qualit at des aufgesetzten Systems. Oder schon explizit die technologien erw ahnen? Die Streaming-Architektur besteht aus einem Streaming Client und einem oder mehrerer Streaming Server. Mit dem Streaming Client ist eine hochau osende Kamera verbunden. F ur die Ubertragung des Video- und Audiosignals kommt der Adobe Flash Media Live Encoder (FMLE) zum Einsatz. Servereitig sorgt ein Open Source C++ RTMP-Server f ur die Bereitstellung des Streams via RTMP/RTSP. In der Webanwendung l auft der Flowplayer, welcher den RTMP Stream abruft. Im folgenden werden alle notwendigen Schritte zur Konguration von Hard- und Software mit Erl auterungen aufgef uhrt.

2.1.1

Herausforderungen

Streaming-Client muss ausreichend Upload-Kapazit aten f ur den Multi-Bitrate-Stream haben. Ausgehend von ca 2500 mbps Upstream sollten lt. Livestreaming.org mind. 5 mbps Upstream zur Verf ugung stehen. Verf ugbarkeit Sicherheit Qualit at entsprechend der unterschiedlichen Anbindung d. Endger ate Au osung d. Videos Videoformate

2.1.2

Client-Server Architektur

Die einfache Variante (Single-Server-Modell ) der Livestreaming Architektur (Abb 2.1) besteht aus Akteuren welche z.B. ein Gruppentraining mit einer HD Kamera lmen. Das Videosignal von der Kamera wird direkt vom Streaming-Client mit laufendem Flash Media Live Encoder ausgelesen, in unterschiedliche Bitraten konvertiert und nach erfolgreicher Anmeldung an den CRTMP-Server gesendet. Dieser kann je nach Konguration die eintreenden Videostreams als RMTP- oder RTSP-Stream auf vordenierten Ports zur Verf ugung stellen. Von dem auf der Webanwendung laufenden Flashplayer wird der Videostream dann bei Bedarf auf ClientPCs/Tablets/Smartphones abgespielt.

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

2.1. Livestreaming

Abbildung 2.1: Livestreaming Architektur - Einzelner Server

Die Architektur zeigt schon, dass der Server die zentrale Komponente ist und der Groteil von Einschr ankungen von diesem ausgehen. Je nachdem wie viele Nutzer sich mit dem Server verbinden um den Stream zu sehen werden Hardwareressourcen und vor allem Netzwerkressourcen eingefordert. W ahrend sich die Hardwareressourcen auf das verarbeiten von maximal drei Videostreams beschr ankt, enth ullt eine einfache Rechnung, dass bei gew ohnliche UploadKapazit aten schnell gesprengt werden. Annahme: durchschnittliche Bitrate 1500 kbps bei 500 Clients = 750 Mpbs 500 Clients ist auch ca. die Anzahl an Nutzern, bei der die Hardware bis zu 60% ausgelastet ist. Optimal Auslastung um auch spikes abzufangen. Was tun bei mehr Nutzern? Das Aufsetzen eines Clusters (Abb. 2.2) kann das skalierungs (??) Problem l osen. Der Master-Server wird wie im Single Server Model aufgesetzt mit dem Unterschied, dass der Server nur Verbindungen von Mirror-Servern zul asst. Jeder Mirror-Server hat dann auch wieder f ur bis zu 500 Nutzer Kapazit aten. Die korrekte Funktionsweise (??) erfordert eine Plugin zum Load Balancing. M ochte ein Nutzer den Livestream ansehen wird zun achst die Latenz zu den jeweiligen Mirror-Servern u uft und die Last auf den Servern verglichen. Dem berpr Nutzer wird anschlieend ein Server zugewiesen. Ist ein Server voll weicht ein Nutzer auf Server mit h oherer Latenz aus.

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Kapitel 2. Video-Komponente

Abbildung 2.2: Livestreaming Architektur - Server Cluster

2.1.3

C++ RTMP SERVER

Auf jedem Server l auft ein C++ RTMP Server (CRTMP-Server). Dabei handelt es sich um einen in C++ geschriebenen Streaming-Server welcher es Videos aufzunehmen bzw. zu senden. CRTMP-Server unterst utzt diverse Technologien. Der Server ist in der Lage Flash zu Empfangen und zu Senden (RTMP,RTMPE, RTMPS, RTMPT, RTMPTE), Signale von eingebetteten Ger aten (Android, IP-Kameras, Hardware-Encoders) zu Empfangen und zu Senden, Videos von IOS-Ger aten zu Empfangen und via MPEG-TS, RTSP/RTCP und RTP zu streamen. Die Verwendung dieser Technologien wird eine Kompatibilit at zu allen g angigen Endger ate ohne zus atzliche Plugins erreicht. W ahrend herk ommliche nicht IOS-Ger ate

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

2.1. Livestreaming KEIN IOS SUPPORT !!!

L osung: HLS Plugin selber schreiben oder kommerzielel Version Evostream verwenden. In den Ausblick Konguration CRTMP-Server wird mit LUA-Skripten konguriert (s. Anhang 2.1 und 2.2). Die Hauptkongurationsdatei stellt in diesem Fall die vplayback.lua Datei dar. Entscheidend ist neben dem Einstellen von Log-Dateien die Konguration der Ports auf welchen der Server mit bestimmten Protokollen kommuniziert. Die Firma ViaVitale wird auf dem Client-System den FMLE verwenden. Dieser kommuniziert mit dem RTMP Protokoll. Nachdem eine Anwendung mit einem Namen und einer Beschreibung sowie weiterer optionaler Parameter festgelegt wird folgt die Denition der Akzeptoren (acceptors ). In der vplayback.lua wird Port 1395 f ur das RTMP Protokoll freigegeben. Der sogenannte acceptor. Weitere acceptors sind m oglich (z.B. f ur inboundv, inboundRTSP, inboundRTP, . . . ) --[[./config/flvplayback.lua]]-38 39 40 41 42 43 44 45

acceptors = { { ip =0.0.0.0 , p o r t =1935 , p r o t o c o l =inboundRtmp }, }, Anschlieend kann der Server noch einen Authentizierungsmechanismus aktivieren. Daf ur wird validateHandshake auf true gesetzt. Gefolgt von einem Authentizierungsblock --[[./config/flvplayback.lua]]--

46 47 48 49 50 51 52 53 54 55

v a l i d a t e H a n d s h a k e=t r u e , a u t h e n t i c a t i o n= { rtmp={ type=adobe , e n c o d e r A g e n t s= { FMLE/ 3 . 0 ( c o m p a t i b l e ; FMSc / 1 . 0 ) , }, u s e r s F i l e = u s e r s . l u a Die in Zeile 55 angegebene users.lua Datei enth alt die Nutzernamen/Passwort-Kombinationen. In diesem Fall haben nur die beiden Inhaber Thomas und Heike einen eigenen Zugang.

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

10 --[[./config/users.lua]]-1 2 3 4 5 6

Kapitel 2. Video-Komponente

[[./ c o n f i g / u s e r . l u a ]] u s e r s= { h e i k e=#################### , thomas=################### }

Sicherheit Der Server wird auf unterschiedlichen Ebenen abgesichert: Nur Verbindung eines Encoders zum Server wenn Nutzername/passwort bekannt Server validiert IP-Adresse vom Encoding-Client, von weiteren Mirror-Servern und den DN sowie die IP-Adresse der Webandwendung. Dadurch wird verhindert, dass der Stream von anderen Anwendungen verwendet werden kann. Authentizierung wie zuvor beschrieben sch utzt davor, dass andere sich andere Encoder mit dem Server verbinden um diesen zum Streamen zu verwenden. Validierung von IP-Adressen und Domain-Names ndet beim Verbinden statt. Diese Funktion ist in der Open-Source-Variante des CRTMP-Servers nicht implementiert. Um diese Funktionalit at zu erreichen m ussen Header und C++ Dateien im rtmpprtocolhandler u ange berarbeitet (Anh 2.3/2.4) und neu kompiliert werden [1]. Hardware VM308 der Uni Osnabr uck Laut evo stream bis zu 12000 Clients/Instanz !!Upstream!! Stresstest

2.1.4

Flash Media Live Encoder

Adobe Tool Einstellungsm oglichkeiten Erl auterung der Ober ache konkretes Anwendungsbeispiel Verwendung in Kombination m. CRTMP

Konguration Konkretes Kongurationsbeispiel wie es ViaVitale verwenden k onnte Erkl arungen

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

2.2. Video-on-Demand Hardware Anbindung ans Breitbandnetz Rechenbeispiel Resultierende Hardwareanforderungen Erl auterung

11

2.1.5

Flowplayer

Was ist das Verwendung im Frontend M oglichkeiten zur Konguration kostenpichtige Version Anpassung ans CD m oglich .... HTML5-Player mit Flash-Fallback Anwendungsbeispiel

2.1.6

Zusammenfassung Livestreaming-Komponente

verwendete Soft- und Hardware Schwachstellen Vorteile Oene Fragen

2.2

Video-on-Demand
Verwendung von bestehender L osung wie Amazon Web Services. Skalierbarkeit und Speicherplatz. Anforderungen Herausforderungen

2.2.1

Amazon Web Services

Pay what you need gute api f ur entwickler exibel auch andere Produkte wie die ec2 instanzen erl autern

AmazonCloudFront Streaming Server.

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

12 Edge node verteilung Verkn. mit S3 signed urls validierung m oglich Konguration d. Komponente Codebeispiel

Kapitel 2. Video-Komponente

Erkl arungen

Amazon S3 Erl auterung Nur Datenspeicher Bereitgestellt f. CloudFront Public/Private Buckets Rails Integration via Paperclip

2.2.2

FFmpeg

Was ist das Transkodierungsbeispiel f. die g angigen Formate source mp4 target mp4, oggtheora und webm jpeg thumbnail aus dem sourcevideo codebeispiel

2.2.3

Paperclip

RoR gem Verwalten von Dateiuplaod f. Avatare oder Videos migrations anderung zeigen model anderung zeigen erl auterung preprocessing m oglich warum wollen wir das?

Pre-Processing Beispiel f ur den mpeg Preprocessor und die Style attribute Thumbnails

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

2.2. Video-on-Demand *

13

2.2.4

Bitraten

Tabelle mit den generierten Bitraten anhand der Einsellungen im Preprocessor Gegen uberstellung

2.2.5

Zusammenfassung VoD-Komponente

Technologien aufz ahlen hardware nicht mehr entscheidend => Alle g angigen Endger ate k onnen d. Streams Abrufen

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Kapitel 3

Schlussteil
3.1 Fazit und Ausblick

15

Kapitel 4

Literaturverzeichnis

17

Literaturverzeichnis
[1] Rani: Protecting your streams from webpage. protect_streams. Version: Oktober 2012 http://wiki.rtmpd.com/tutorial_

19

Kapitel 5

Abbildungsverzeichnis

21

Abbildungsverzeichnis
2.1 2.2 Livestreaming Architektur - Einzelner Server . . . . . . . . . . . . . . . . . . . . Livestreaming Architektur - Server Cluster . . . . . . . . . . . . . . . . . . . . . 7 8

23

Erkl arung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbst andig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe.

Osnabr uck, Juli 2013

Anhang
2.1: users.lua
1 2 3 4 5 6

[[./ c o n f i g / u s e r . l u a ]] u s e r s= { h e i k e=#################### , thomas=################### }

27

28

Abbildungsverzeichnis

2.2 vplayback.lua
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

[[./ c o n f i g / f l v p l a b a c k . l u a ]] c o n f i g u r a t i o n= { daemon=f a l s e , p a t h S e p a r a t o r =/ , logAppenders= { { name= c o n s o l e appender , type= c o l o r e d C o n s o l e , l e v e l =6 }, { name= f i l e appender , type= f i l e , l e v e l =6, f i l e N a m e =./ l o g s / c r t m p s e r v e r , f i l e H i s t o r y S i z e =10 , f i l e L e n g t h =1024 1024 , s i n g l e L i n e=t r u e } }, a p p l i c a t i o n s= { r o o t D i r e c t o r y = a p p l i c a t i o n s , { d e s c r i p t i o n =FLV Playback , name= f l v p l a y b a c k , p r o t o c o l = d y n a m i c l i n k l i b r a r y , d e f a u l t=t r u e , a l i a s e s= { live }, acceptors = { { ip =0.0.0.0 , p o r t =1935 ,

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Abbildungsverzeichnis p r o t o c o l =inboundRtmp }, }, v a l i d a t e H a n d s h a k e=t r u e , a u t h e n t i c a t i o n= { rtmp={ type=adobe , e n c o d e r A g e n t s= { FMLE/ 3 . 0 ( c o m p a t i b l e ; FMSc / 1 . 0 ) , }, u s e r s F i l e = u s e r s . l u a }, }, }, } }

29

43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

30

Abbildungsverzeichnis

2.3 rtmpappprotocolhandler.h
1 2 3 4 5 6

/ /

Copyright ( c ) 2 0 1 0 , G a v r i l o a i e EugenAndrei ( s h i r e t u @ g m a i l . com ) This f i l e i s p a r t o f c r t m p s e r v e r . c r t m p s e r v e r i s f r e e s o f t w a r e : you can r e d i s t r i b u t e i t and/ o r modify i t under t h e terms o f t h e GNU G e n e r a l P u b l i c L i c e n s e a s p u b l i s h e d by t h e Free S o f t w a r e Foundation , e i t h e r v e r s i o n 3 o f t h e L i c e n s e , o r ( a t your o p t i o n ) any l a t e r v e r s i o n . c r t m p s e r v e r i s d i s t r i b u t e d i n t h e hope t h a t i t w i l l be u s e f u l , but WITHOUT ANY WARRANTY; w i t h o u t even t h e i m p l i e d warranty o f MERCHANTABILITY o r FITNESS FOR A PARTICULAR PURPOSE. See t h e GNU G e n e r a l P u b l i c L i c e n s e f o r more d e t a i l s . You s h o u l d have r e c e i v e d a copy o f t h e GNU G e n e r a l P u b l i c L i c e n s e a l o n g with c r t m p s e r v e r . I f not , s e e < h t t p : / /www. gnu . o r g / l i c e n s e s / >.

8 9 10 11 12 13 14 15 16 17

18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

#i f d e f HAS PROTOCOL RTMP #i f n d e f RTMPAPPPROTOCOLHANDLER H #d e f i n e RTMPAPPPROTOCOLHANDLER H #i n c l u d e p r o t o c o l s /rtmp/ b a s e r t m p a p p p r o t o c o l h a n d l e r . h namespace a p p f l v p l a y b a c k { c l a s s RTMPAppProtocolHandler : p u b l i c BaseRTMPAppProtocolHandler { public : RTMPAppProtocolHandler ( V a r i a n t &c o n f i g u r a t i o n ) ; v i r t u a l RTMPAppProtocolHandler ( ) ; v i r t u a l b o o l P r o c e s s I n v o k e G e n e r i c ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) ; / ANFANG NEUER FUNKTIONEN /

36 37 38

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Abbildungsverzeichnis

31

39 40

41 42 43 44 45 46

v i r t u a l b o o l P r o c e s s I n v o k e C o n n e c t ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) ; v i r t u a l b o o l V a l i d a t e R e q u e s t ( V a r i a n t &r e q u e s t ) ; / ENDE NEUE FUNKTIONEN / private : b o o l P r o c e s s G e t A v a i l a b l e F l v s ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) ; b o o l P r o c e s s I n s e r t M e t a d a t a ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) ; }; } #e n d i f / RTMPAPPPROTOCOLHANDLER H / #e n d i f / HAS PROTOCOL RTMP /

47

48 49 50 51

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

32

Abbildungsverzeichnis

2.4 rtmpappprotocolhandler.cpp
1 2 3 4 5 6

/ /

Copyright ( c ) 2 0 1 0 , G a v r i l o a i e EugenAndrei ( s h i r e t u @ g m a i l . com ) This f i l e i s p a r t o f c r t m p s e r v e r . c r t m p s e r v e r i s f r e e s o f t w a r e : you can r e d i s t r i b u t e i t and/ o r modify i t under t h e terms o f t h e GNU G e n e r a l P u b l i c L i c e n s e a s p u b l i s h e d by t h e Free S o f t w a r e Foundation , e i t h e r v e r s i o n 3 o f t h e L i c e n s e , o r ( a t your o p t i o n ) any l a t e r v e r s i o n . c r t m p s e r v e r i s d i s t r i b u t e d i n t h e hope t h a t i t w i l l be u s e f u l , but WITHOUT ANY WARRANTY; w i t h o u t even t h e i m p l i e d warranty o f MERCHANTABILITY o r FITNESS FOR A PARTICULAR PURPOSE. See t h e GNU G e n e r a l P u b l i c L i c e n s e f o r more d e t a i l s . You s h o u l d have r e c e i v e d a copy o f t h e GNU G e n e r a l P u b l i c L i c e n s e a l o n g with c r t m p s e r v e r . I f not , s e e < h t t p : / /www. gnu . o r g / l i c e n s e s / >.

8 9 10 11 12 13 14 15 16 17

18 19 20 21 22 23 24 25 26 27 28 29 30

#i f d e f HAS PROTOCOL RTMP #i n c l u d e r t m p a p p p r o t o c o l h a n d l e r . h #i n c l u d e p r o t o c o l s /rtmp/ b a s e r t m p p r o t o c o l . h #i n c l u d e p r o t o c o l s /rtmp/ m e s s a g e f a c t o r i e s / m e s s a g e f a c t o r i e s . h #i n c l u d e a p p l i c a t i o n / b a s e c l i e n t a p p l i c a t i o n . h #i n c l u d e s t r e a m i n g / b a s e i n n e t s t r e a m . h #i n c l u d e s t r e a m i n g / s t r e a m s t y p e s . h u s i n g namespace a p p f l v p l a y b a c k ; RTMPAppProtocolHandler : : RTMPAppProtocolHandler ( V a r i a n t &c o n f i g u r a t i o n ) : BaseRTMPAppProtocolHandler ( c o n f i g u r a t i o n ) { } RTMPAppProtocolHandler : : RTMPAppProtocolHandler ( ) { }

31 32 33 34 35 36 37

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Abbildungsverzeichnis

33

38

39 40 41 42 43 44 45 46 47

b o o l RTMPAppProtocolHandler : : P r o c e s s I n v o k e G e n e r i c ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) { s t r i n g functionName = M INVOKE FUNCTION( r e q u e s t ) ; i f ( functionName == g e t A v a i l a b l e F l v s ) { r e t u r n P r o c e s s G e t A v a i l a b l e F l v s ( pFrom , r e q u e s t ) ; } e l s e i f ( functionName == i n s e r t M e t a d a t a ) { r e t u r n P r o c e s s I n s e r t M e t a d a t a ( pFrom , r e q u e s t ) ; } else { r e t u r n BaseRTMPAppProtocolHandler : : P r o c e s s I n v o k e G e n e r i c ( pFrom , r e q u e s t ) ; } } // adding f u n c t i o n s f o r f i l t e r v a l i d a t i o n s b o o l RTMPAppProtocolHandler : : P r o c e s s I n v o k e C o n n e c t ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) { / / 1 . Get t h e r e q u e s t params i f (M INVOKE PARAMS( r e q u e s t ) . MapSize ( ) < 1 ) { FATAL( I n v a l i d r e q u e s t ) ; return f a l s e ; } V a r i a n t c o n n e c t P a r a m e t e r s = M INVOKE PARAM( r e q u e s t , 0 ) ; i f ( authMethod != ) { //we have adobe auth e n a b l e d s t r i n g flashVer = connectParameters [ RM INVOKE PARAMS CONNECT FLASHVER ] ; i f ( ! c o n f i g u r a t i o n [ CONF APPLICATION AUTH ] [ CONF APPLICATION AUTH ENCODER AGENTS ] . HasKey ( flashVer ) ) { // t h i s c o n n e c t i o n w i l l not be a u t h e n t i c a t e d , s o we w i l l t r y t o v a l i d a t e t h e URI s i f ( ! ValidateRequest ( request ) ) { FATAL( I n v a l i d c o n n e c t r e q u e s t ) ; return f a l s e ; } } } else { //we don t have adobe auth e n a b l e d a t a l l . We w i l l t r y t o v a l i d a t e t h e URI s i f ( ! ValidateRequest ( request ) ) { FATAL( I n v a l i d c o n n e c t r e q u e s t ) ;

48 49 50 51 52

53 54 55 56 57 58 59 60 61 62

63

64

65 66 67 68 69 70 71

72 73

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

34 return f a l s e ; } }

Abbildungsverzeichnis

74 75 76 77 78 79

r e t u r n BaseRTMPAppProtocolHandler : : P r o c e s s I n v o k e C o n n e c t ( pFrom , request ) ; } b o o l RTMPAppProtocolHandler : : V a l i d a t e R e q u e s t ( V a r i a n t &r e q u e s t ) { //TODO: V a l i d a t e t h e v a r i o u s URI s i n s i d e t h e r e q u e s t h e r e / / 0 . Dump t h e r e q u e s t on c o n s o l e , j u s t t o s e e i t s s t r u c t u r e FINEST( I n i t i a l r e q u e s t : \ n%s , STR( r e q u e s t . T o S t r i n g ( ) ) ) ; / / 1 . Get t h e c o n n e c t params from t h e c o n n e c t i n v o k e V a r i a n t connectParams = M INVOKE PARAM( r e q u e s t , 0 ) ; / / 2 . This s h o u l d be a key v a l u e map i f ( connectParams != V MAP) { FATAL( I n c o r r e c t i n v o k e params : \ n%s , STR( r e q u e s t . ToString ( ) ) ) ; return f a l s e ; } / / 3 . Let s e x t r a c t few v a l u e s . Make s u r e we e x t r a c t them u s i n g nonc a s e s e n s i t i v e k e y s V a r i a n t t c U r l = connectParams . GetValue ( RM INVOKE PARAMS CONNECT TCURL, f a l s e ) ; // I f you a r e s u r e about c a s e s e n s i t i v e s e t t i n g s , you can extract it directly like this V a r i a n t s w f U r l = connectParams [ RM INVOKE PARAMS CONNECT SWFURL ] ; // V a r i a n t t c U r l = connectParams [ RM INVOKE PARAMS CONNECT TCURL ] ; V a r i a n t pageUrl = connectParams [ RM INVOKE PARAMS CONNECT PAGEURL ] ;

80 81 82 83 84 85 86 87 88 89 90 91 92

93 94 95 96

97

98 99

100

101

102

103 104 105 106 107 108

/ / 4 . Do some v a l i d a t i o n on them . i f ( pageUrl != V STRING) { FATAL( I n c o r r e c t RM INVOKE PARAMS CONNECT PAGEURL : % s , STR( r e q u e s t . T o S t r i n g ( ) ) ) ;

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Abbildungsverzeichnis return f a l s e ; }

35

109 110 111 112 113

114 115 116 117 118 119 120 121 122 123 124 125 126 127 128

i f ( t c U r l != V STRING) { FATAL( I n c o r r e c t RM INVOKE PARAMS CONNECT TCURL : \ n% s , STR( r e q u e s t . T o S t r i n g ( ) ) ) ; return f a l s e ; } s t r i n g rawURI ; URI u r i ; i f ( ! URI : : FromString ( pageUrl , t r u e , u r i ) ) { FATAL( Unable t o p a r s e t h e u r i %s , STR( rawURI ) ) ; return f a l s e ; } // a s p r o t o we a r e g o i n g t o v a l i d a t e rtmp/ rtmpe // added i f / e l s e i f / e l s e and INFO l i k e Andriy s u g g e s t e d i f ( ( ( s t r i n g ) t c U r l ) != rtmp : / / r z 3 0 8 . uos . de / l i v e s t r e a m ) { INFO( Connect schema i s \ % s \ , STR( ( s t r i n g ) t c U r l ) ) ; } e l s e i f ( ( ( s t r i n g ) t c U r l ) != rtmpe : / / r z 3 0 8 . uos . de / livestream ) { INFO( Connect schema i s \ % s \ , STR( ( s t r i n g ) t c U r l ) ) ; } else { FATAL( I n c o r r e c t RM INVOKE PARAMS CONNECT TCURL : %s , STR( r e q u e s t . T o S t r i n g ( ) ) ) ; return f a l s e ; } // we u s e our s t a t i c f l o w p l a y e r which i s always on t h e same address // added i f / e l s e i f / e l s e and INFO l i k e Andriy s u g g e s t e d i f ( ( ( s t r i n g ) s w f U r l ) != h t t p : / /www. backzoom . de / f l o w p l a y e r / f l o w p l a y e r 3 . 2 . 5 . swf ) { INFO( F l a s h p l a y e r a d d r e s s i s \ % s \ , STR( ( s t r i n g ) swfUrl ) ) ; } e l s e i f ( ( ( s t r i n g ) s w f U r l ) != h t t p : / /www. backzoom . de / l i v e s t r e a m / p l a y e r . swf ) { INFO( F l a s h p l a y e r a d d r e s s i s \ % s \ , STR( ( s t r i n g ) swfUrl ) ) ; } else { FATAL( I n c o r r e c t RM INVOKE PARAMS CONNECT SWFURL : %s , STR( r e q u e s t . T o S t r i n g ( ) ) ) ;

129 130 131 132

133 134 135

136 137

138

139

140

141 142 143

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

36 return f a l s e ; }

Abbildungsverzeichnis

144 145 146 147 148 149 150

151

152 153 154

155 156 157 158 159 160

// i p which r e s o l v e our c a l l i n g webpage ( s ) / w e b s i t e ( s ) // added i f / e l s e i f / e l s e and INFO l i k e Andriy s u g g e s t e d i f ( ( ( s t r i n g ) u r i . i p ) == 8 3 . 1 3 3 . 9 7 . 2 2 2 ) { INFO( Stream c a l l i n g webpage i s \ % s \ , STR( ( s t r i n g ) pageUrl ) ) ; INFO( stream C a l l i n g webpage IP i s \ % s \ , STR( ( string ) uri . ip ) ) ; } else { FATAL( I n c o r r e c t RM INVOKE PARAMS CONNECT PAGEURL : %s , STR( r e q u e s t . T o S t r i n g ( ) ) ) ; return f a l s e ; } return true ; } b o o l RTMPAppProtocolHandler : : P r o c e s s G e t A v a i l a b l e F l v s ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) { Variant parameters ; p a r a m e t e r s . PushToArray ( V a r i a n t ( ) ) ; p a r a m e t e r s . PushToArray ( V a r i a n t ( ) ) ; v e c t o r <s t r i n g > f i l e s ; i f ( ! l i s t F o l d e r ( c o n f i g u r a t i o n [ CONF APPLICATION MEDIAFOLDER ] , files )) { FATAL( Unable t o l i s t f o l d e r %s , STR( c o n f i g u r a t i o n [ CONF APPLICATION MEDIAFOLDER ] ) ) ; return f a l s e ; } s t r i n g f i l e , name , e x t e n s i o n ; s i z e t normalizedMediaFolderSize = 0; s t r i n g mediaFolderPath = n o r m a l i z e P a t h ( c o n f i g u r a t i o n [ CONF APPLICATION MEDIAFOLDER ] , ) ; i f ( ( mediaFolderPath != ) && ( mediaFolderPath [ mediaFolderPath . s i z e ( ) 1 ] == PATH SEPARATOR) ) n o r m a l i z e d M e d i a F o l d e r S i z e = mediaFolderPath . s i z e ( ) ; else n o r m a l i z e d M e d i a F o l d e r S i z e = mediaFolderPath . s i z e ( ) + 1;

161 162 163 164 165 166 167 168 169

170 171 172 173 174 175

176

177 178 179

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

Abbildungsverzeichnis

37

180 181 182

FOR VECTOR ITERATOR( s t r i n g , f i l e s , i ) { f i l e = VECTOR VAL( i ) . s u b s t r ( n o r m a l i z e d M e d i a F o l d e r S i z e ); s p l i t F i l e N a m e ( f i l e , name , e x t e n s i o n ) ; e x t e n s i o n = lowerCase ( e x t e n s i o n ) ; i f ( e x t e n s i o n != MEDIA TYPE FLV && e x t e n s i o n != MEDIA TYPE MP3 && e x t e n s i o n != MEDIA TYPE MP4 && e x t e n s i o n != MEDIA TYPE M4A && e x t e n s i o n != MEDIA TYPE M4V && e x t e n s i o n != MEDIA TYPE MOV && e x t e n s i o n != MEDIA TYPE F4V && e x t e n s i o n != MEDIA TYPE TS && e x t e n s i o n != MEDIA TYPE NSV) continue ; s t r i n g flashName = ; i f ( e x t e n s i o n == MEDIA TYPE FLV) { flashName = name ; } e l s e i f ( e x t e n s i o n == MEDIA TYPE MP3) { flashName = e x t e n s i o n + : + name ; } e l s e i f ( e x t e n s i o n == MEDIA TYPE NSV) { flashName = e x t e n s i o n + : + name + . + extension ; } else { i f ( e x t e n s i o n == MEDIA TYPE MP4 | | e x t e n s i o n == MEDIA TYPE M4A | | e x t e n s i o n == MEDIA TYPE M4V | | e x t e n s i o n == MEDIA TYPE MOV | | e x t e n s i o n == MEDIA TYPE F4V) { flashName = MEDIA TYPE MP4 : + name + . + extension ; } else { flashName = e x t e n s i o n + : + name + . + extension ; } }

183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203

204 205 206

207

208

209

210

211 212

213 214 215

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru

38

Abbildungsverzeichnis p a r a m e t e r s [ ( u i n t 3 2 t ) 1 ] . PushToArray ( flashName ) ; } map< u i n t 3 2 t , BaseStream > a l l I n b o u n d S t r e a m s = G e t A p p l i c a t i o n ( )>GetStreamsManager ( )> FindByType ( ST IN NET , t r u e ) ; FOR MAP( a l l I n b o u n d S t r e a m s , u i n t 3 2 t , BaseStream , i ) { p a r a m e t e r s [ ( u i n t 3 2 t ) 1 ] . PushToArray (MAP VAL( i )> GetName ( ) ) ; } V a r i a n t message = G e n e r i c M e s s a g e F a c t o r y : : GetInvoke ( 3 , 0 , 0 , false , 0 , SetAvailableFlvs , parameters ) ; r e t u r n SendRTMPMessage ( pFrom , message ) ;

216 217 218 219 220

221 222 223

224 225 226

227 228 229 230 231 232

} b o o l RTMPAppProtocolHandler : : P r o c e s s I n s e r t M e t a d a t a ( BaseRTMPProtocol pFrom , V a r i a n t &r e q u e s t ) { NYIR ; } #e n d i f / HAS PROTOCOL RTMP /

233 234 235

r ein Entwicklung einer Livestreaming- und Video-on-Demand-Komponente fu ckenstudio Online-Ru