2 Ziele dieser Arbeit

Transcription

1
Eidesstattliche Erklärung
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Diplomarbeit selbständig und
ohne unzulässige fremde Hilfe angefertigt habe. Alle verwendeten Quellen und Hilfsmittel sind angegeben.
Furtwangen, den ……………….
………………………………….
(Philipp Lamp)
Abstract
Abstract
Die vorliegende Diplomarbeit beschäftigt sich mit der Konzeption und der prototypischen Realisierung eines 24/7 Sendespeichers für das DVB-Fernsehsignal beim Zweiten
Deutschen Fernsehen.
Für das ZDF ist ein solches System, welches den DVB-Datenstrom des gesamten eigenen Programmbouquets aufzeichnen und zur Auswertung vorhalten kann, aus verschieden Gründen gewünscht. Für unterschiedliche Anwendungsbereiche bietet ein DVB
Rückempfangssystem die ideale Datenbasis zur Weiterverarbeitung.
Betrachtet man die Audio/Video Ebene des Sendesignals, also MPEG Daten, so stellen
diese ein digitales Format dar, welches für vielfache Zwecke in andere Digitalformate
transcodiert werden kann. Exemplarisch sei hier die nachträgliche Codierung von gesendetem Programm für das Internetstreaming in internetspezifische Formate genannt. Weiterhin ist eine Speicherung der Audio/Video Inhalte auf einem digitalen Medium, zum
Beispiel DVD, in nativer Qualität gewünscht, um eine spätere Revision des gesendeten
Materials zu vereinfachen.
Im Hinblick auf die Technischen Parameter des Sendesignals, bietet ein Sendespeicher
mit angegliedertem Analysesystem die Möglichkeit, eventuell aufgetretene technische
Sendestörungen oder Fehler zu rekapitulieren. Oftmals berichten Zuschauer von Störungen an ihren Empfangsgeräten, die mithilfe eines solchen Systems nachvollzogen werden
können.
Im Rahmen dieser Diplomarbeit wurde eine Plattform prototypisch implementiert, die
das DVB Angebot des ZDF rund um die Uhr nahtlos aufzeichnet und verschiedene
Schnittstellen für die jeweiligen Anforderungen bereitstellt.
Das System speichert den DVB Transportstrom in unveränderter Form ab, sodass sämtliche Parameter des DVB Sendesignals erhalten bleiben.
Es besteht die Möglichkeit, einen Ausschnitt des aufgezeichneten Transportstromes nativ
zu extrahieren, um ihn einem beliebigen externen messtechnischen System zuzuführen.
Weiterhin kann die Auswahl als DVD Material exportiert werden. Das am aufwändigsten
implementierte Feature ist ein Analysemodul für diverse DVB spezifische Parameter.
Diese werden in Tabellenform für den ausgewählten Zeitpunkt dargestellt.
Danksagung
Danksagung
Für die Betreuung der Diplomarbeit möchte ich zunächst Herrn Prof. Nikolaus Hottong
und Herrn Prof. Wilhelm Walter danken, die mir bei Fragen immer zur Verfügung standen.
Für die Betreuung vor Ort danke ich insbesondere Herrn Thorsten Weber, der mit stets
mit Rat und Tat zur Seite stand. Außerdem danke ich auch Herrn Dietmar Nothof, der es
mir ermöglichte, diese Arbeit im ZDF durchführen zu können.
Ein herzlicher Dank gilt außerdem den Herren Daniel Boldt, Daniel Klein und Robert
Neumann, die mir bei Fragen jeder Zeit geduldig zur Seite standen.
Zusätzlich danke ich allen Kollegen und Mitarbeitern der Abteilung „Sendeabwicklung
Informationsdienste“ für das unverwechselbare und angenehme Arbeitsklima.
Weiterhin danke ich meinen Eltern, meiner Familie sowie Freunden, die mich stets auf
meinem Weg hier her begleiteten.
1
Inhaltsverzeichnis
I
ABBILDUNGSVERZEICHNIS.......................................................................3
II
ABKÜRZUNGSVERZEICHNIS .....................................................................5
1
EINFÜHRUNG .....................................................................................................9
2
ZIELE DIESER ARBEIT .......................................................................................11
3
GRUNDLAGEN ZU DIGITALEM FERNSEHEN ...................................................... 13
3.1
DVB-S/C/T .............................................................................................................15
3.2
Der DVB-Transportstrom......................................................................................15
3.3
DVB-SI / PSI ...........................................................................................................19
3.3.1 Grundlagen......................................................................................................19
3.3.2 Übersicht SI / PSI .........................................................................................20
3.3.3 Aufbau von SI-/PSI Daten ............................................................................23
4
5
3.3.3.1
Tables...................................................................................................................24
3.3.3.2
Sections................................................................................................................24
3.3.3.3
Descriptors..........................................................................................................26
ANALYSE UND ERLÄUTERUNG DER RANDBEDINGUNGEN ............................... 29
4.1
Randbedingungen ....................................................................................................29
4.2
Vorhandene Systeme auf dem Markt....................................................................29
4.3
Hauptschwerpunkt...................................................................................................30
KONZEPT EINER ZIELLÖSUNG ......................................................................... 31
5.1
Diskussion und Evaluierung verschiedener Lösungsansätze ............................31
5.1.1 Open-Source ....................................................................................................31
5.1.2 Eigens programmierte Software.........................................................................33
5.2
Funktionen im gewählten System..........................................................................33
5.2.1 Aufnahme .......................................................................................................33
5.2.2 Ringpuffer........................................................................................................34
5.2.3 Extrahierung der SI-Daten .............................................................................35
5.2.4 Organisation der Daten ...................................................................................36
5.2.5 Präsentation.....................................................................................................38
5.2.6 Ausfallsicherheit ..............................................................................................39
5.3
6
Methoden zur Umsetzung ......................................................................................40
UMSETZUNG DES KONZEPTS ............................................................................ 43
6.1
TS-Buffer...................................................................................................................43
6.2
TS-Recorder..............................................................................................................48
2
Inhaltsverzeichnis
6.3
CTSPacket.................................................................................................................53
6.4
TSFilterBank.............................................................................................................53
6.5
TS2PS-Worker .........................................................................................................58
6.5.1 Re-Multiplexing ..............................................................................................60
6.5.2 Transcoding (Frameserver) ...............................................................................63
6.6
Tables-Socket-Service .............................................................................................66
6.7
TS-Analyzer-Applet.................................................................................................71
6.8
Webfrontend ............................................................................................................74
6.8.1 Extraktion von Video-Material ......................................................................76
6.8.2 Analyse der SI-/PSI-Daten............................................................................78
6.8.3 Extrahierung von Transportstromfragmenten ...................................................79
6.8.4 DVD-Generierung .........................................................................................81
7
INSTALLATION, KONFIGURATION UND BETRIEB .............................................83
8
ZUSAMMENFASSUNG .........................................................................................85
8.1
9
Kritische Würdigung ...............................................................................................85
FAZIT / AUSBLICK .............................................................................................87
III LITERATURVERZEICHNIS........................................................................89
A
Listings.............................................................................................................93
A.1
DTDs.........................................................................................................................93
A.1.1 Tables-Socket-Service .....................................................................................93
B
A.2
TS2PS Job-Files .......................................................................................................94
A.3
Beispiel Konfigurationsdatei ..................................................................................94
Pflichtenheft zum System ................................................................................96
I Abbildungsverzeichnis
I
3
Abbildungsverzeichnis
ABBILDUNG 1
VERTEILUNG VON DVB-SIGNALEN [LENZ] .....................................................15
ABBILDUNG 2
UMWANDLUNG VON ELEMENTARSTROM ZU TRANSPORT STROM ................16
ABBILDUNG 3
AUFBAU EINES PES PAKETS ..................................................................................17
ABBILDUNG 4
AUFBAU EINES TS PAKETS .....................................................................................18
ABBILDUNG 5
PAKETIERUNG DER DATENSTRÖME BEI DVB...................................................18
ABBILDUNG 6
ÜBERSICHT ALLER PSI / SI TABLES ......................................................................20
ABBILDUNG 7
ZUSAMMENSPIEL D. TABLES PAT UND PMT......................................................21
ABBILDUNG 8
AUFBAU EINER TABLE .............................................................................................24
ABBILDUNG 9
BEISPIEL EINER SECTION........................................................................................25
ABBILDUNG 10
BEISPIEL EINES DESCRIPTORS ...............................................................................27
ABBILDUNG 11
DVB-RÜCKEMPFANG ..............................................................................................29
ABBILDUNG 12
BEISPIEL-USECASE FÜR TS-BUFFER .....................................................................44
ABBILDUNG 13
INHALT DES RINGPUFFER-VERZEICHNISSES ......................................................44
ABBILDUNG 14
NAMENSGEBUNG VON RINGPUFFER-DATEIEN ................................................45
ABBILDUNG 15
AKTIVITÄTENDIAGRAMME LESEN/SCHREIBEN IN RINGPUFFER ..................46
ABBILDUNG 16
KLASSENDIAGRAMM TS-BUFFER ..........................................................................47
ABBILDUNG 17
BEISPIEL EPG-XML ................................................................................................49
ABBILDUNG 18
KLASSENDIAGRAMM TECHNOTREND SDK (AUSZUG).....................................51
ABBILDUNG 19
KLASSENDIAGRAMM TS-RECORDER ....................................................................52
ABBILDUNG 20
KLASSENDIAGRAMM TS-PACKET..........................................................................53
ABBILDUNG 21
KLASSENDIAGRAMM TS-FILTER ...........................................................................54
ABBILDUNG 22
EINBETTUNG VON SECTIONS IN TS-PAKETE.....................................................56
ABBILDUNG 23
AKTIVITÄTENDIAGRAMM SECTION-FILTER .......................................................57
ABBILDUNG 24
TS2PS-WORKER........................................................................................................58
ABBILDUNG 25
TS2PS-WORKER JOBFILES ......................................................................................59
ABBILDUNG 26
PVASTRUMENTO ......................................................................................................62
ABBILDUNG 27
PROJECT-X .................................................................................................................62
ABBILDUNG 28
FUNKTIONSWEISE EINES FRAMESERVERS ...........................................................64
ABBILDUNG 29
DGINDEX ..................................................................................................................65
ABBILDUNG 30
LOGISCHE STRUKTUR BEIM „FRAMESERVING“..................................................66
ABBILDUNG 31
NON-LINEARE TRANSPORTSTROMANALYSE ......................................................69
ABBILDUNG 32
BEISPIEL XML-ANTWORT TS-INTERPRETATION ..............................................70
ABBILDUNG 33
TS-ANALYZER-APPLET ...........................................................................................73
ABBILDUNG 34
TS-ANALYZER DETAILANSICHT............................................................................73
ABBILDUNG 35
WEBFRONTEND – VIDEO EXTRAHIERUNG 1 .....................................................76
4
I Abbildungsverzeichnis
ABBILDUNG 36
WEBFRONTEND – VIDEO EXTRAHIERUNG 2 .....................................................77
ABBILDUNG 37
WEBFRONTEND – TRANSPORTSTROMANALYSE .................................................78
ABBILDUNG 38
WEBFRONTEND – TRANSPORTSTROM-EXTRAHIERUNG ..................................79
ABBILDUNG 39
CODE-AUSSCHNITT TRANSPORTSTROM-EXTRAHIERUNG ...............................80
ABBILDUNG 40
WEBFRONTEND – DVD-EXPORT .........................................................................81
II Abkürzungsverzeichnis
AMD
API
ARS
ASI
ATA
AV
AVI
BAT
BBC
BDA
CAT
CBR
CMS
DTD
DTS
DVB
DVB-C
DVB-S
DVB-T
DVD
EIT
EPG
ES
ETSI
GNU
GPL
GUI
HTML
ID
IDE
IP
ISO
JVM
KiKa
LAMP
LGPL
MPEG
Advanced Micro Devices
Application Programming Interface
Asi Record Server
Asynchronous Serial Interface
Advanced Technology Attachment
Audio / Video
Audio Video Interleaved
Bouquet Association Table
British Broadcasting Corporation
Broadcast Driver Architecture
Conditional Access Table
Constant Bit Rate
Content Management System
Document Type Definition
Decode Time Stamp
Digital Video Broadcasting
Digital Video Broadcasting per Kabel
Digital Video Broadcasting per Satellit
Digital Video Broadcasting terrestrisch
Digital Versatile Disc
Event Information Table
Electronic Program Guide
Elementarstrom
European Telecommunications Standards Institute
GNU’s Not Unix
General Public License
Graphical User Interface
Hypertext Markup Language
Identifikations-Nummer
Integrated Development Environment
Internet Protocol
International Organisation for Standardization
Java Virtual Machine
Kinderkanal
Linux Apache Mysql Php
Lesser General Public License
Moving Picture Experts Group
5
6
MS
Mux
MVCD
NIT
PAT
PC
PES
PID
PHP
PMT
PS
PSI
PTS
PVA
RAID
RST
SATA
SCSI
SDI
SDK
SDT
SI
ST
TB
TDT
TOT
TS
TSDT
TV
UK
UPnP
UTC
VBR
VCD
VDR
VHS
WAMP
XML
ZDF
Microsoft
Multiplex(ing)
Mole VCD
Network Information Table
Program Association Table
Personal Computer
Packetized Elementary Stream
Packet ID
PHP Hypertext Preprocessor
Program Map Table
Program Stream
Program Specific Information
Presentation Time Stamp
Packet Video Audio
Redundant Array of Inexpensive Disks
Running Status Table
Serial ATA
Small Computer Systems Interface
Serial Digital Interface
Software Development Kit
Service Description Table
Service Information
Stuffing Table
Tera-Byte
Time and Date Table
Time Offset Table
Transportstrom
Transport Stream Description Table
Television
United Kingdom
Universal Plug and Play
Universal Time Coordinated
Variable Bit Rate
Video-CD
Video Disk Recorder
Video Home System
Windows Apache Mysql Php
Extensible Markup Language
Zweites Deutsches Fernsehen
7
8
1 Einführung
1
9
Einführung
Digitales Fernsehen und DVB1 sind Begriffe, die spätestens seit der Einführung des digitalen terrestrischen Fernsehens in Deutschland immer geläufiger werden. Digitale Fernsehempfänger, so genannte Set-Top-Boxen halten immer weiter Einzug in deutschen
Wohnzimmern.
Auch auf Senderseite gewinnt die Verbreitung der Fernsehsignale auf digitalen Verbreitungswegen wie Satellit, Kabel oder Terrestrisch immer mehr an Bedeutung. Die Vorteile
dieser Technik stellen sich sowohl auf Seite der Sender als auch auf Seite des Fernsehkonsumenten immer mehr in den Vordergrund. Innerhalb gleicher Frequenzbänder, die
das analoge Fernsehen nutzt, lassen sich dank digitaler Technik mehrere Programme
übertragen, wo beim analogen Fernsehen nur für ein Programm Platz ist. Zusätzlich lassen sich im digitalen Fernsehen Zusatzdaten, so genannte SI2- oder PSI3-Daten übertragen. Diese Daten dienen einem Empfänger dazu, sich beispielsweise selbsttätig auf alle
Programme einzustellen oder den „Electronic Program Guide“ (EPG) aufzubauen, mit
dem der Fernsehzuschauer eine „Fernsehzeitschrift“ direkt über den Fernseher abrufen
kann.
Die Tatsache, dass sich digitale Signale ohne Qualitätsverlust aufzeichnen lassen, öffnet
die Pforten für neue Anwendungen. Deshalb entstand im ZDF der Wunsch nach einem
zentralen Sendespeicher, welcher – durch die digitale Technik – multifunktional ist und
sowohl Sendemitschnitte ermöglicht, als auch die Kontrolle der Sendequalität bzw. zur
Lokalisierung eventueller Fehler dient. Nicht selten kommt es vor, dass von Zuschauern
der Hinweis gegeben wird, es seien bestimmte Merkmale wie beispielsweise der Surround4-Sound nicht gesendet worden bzw. ausgefallen. Vorwürfe dieser Art lassen sich
bis dato nicht weiter verfolgen, da in den meisten Fällen keine Mitschnitte existieren.
Deshalb muss ein zentrales System eingeführt werden, welches rund um die Uhr das
komplette Sendeangebot des ZDF mitschneidet und bei Bedarf in entsprechender Form
zur Verfügung stellt.
DVB – Digital Video Broadcasting
SI – Service Information
3 PSI – Program Specific Information
4 Surround – Mehrkanal-Tonsystem, um räumlichen Klang zu erzeugen
1
2
10
1 Einführung
Diese Arbeit besteht aus 9 Kapiteln.
Kapitel 1 stellt eine Einführung dar, welche einen kurzen Überblick über das in dieser
Diplomarbeit behandelte Thema gibt.
Kapitel 2 legt die Ziele dar, welche durch Bearbeitung dieser Arbeit erreicht werden sollen.
In Kapitel 3 werden die benötigten Grundlagen zum Themengebiet digitales Fernsehen
vermittelt. Hierzu gehören die Verbreitung von Signalen, der Aufbau des Datenstromes
sowie die Struktur dessen Inhalts.
Kapitel 4 erläutert die infrastrukturellen und organisatorischen Randbedingungen, welche
sich auf die Planung und Realisierung des Systems auswirken.
Ein Konzept zur Erreichung der Ziele dieser Arbeit wird in Kapitel 5 erstellt, wodurch
die nötigen Grundlagen für die darauf folgende Umsetzung erarbeitet werden.
In Kapitel 6 wird dann auf die Umsetzung des zuvor erstellten Konzepts eingegangen.
Hierzu gehören sowohl die Methoden und Werkzeuge der Umsetzung als auch die resultierenden Softwaremodule.
Kapitel 7 erklärt kurz das Vorgehen zur Installation und zum Betrieb des entstandenen
Systems.
Kapitel 8 bietet eine kurze Zusammenfassung der Ergebnisse.
Kapitel 9 gibt schließlich einen Ausblick auf die zukünftige Verwendung und denkbare
weitere Verwendungsmöglichkeiten.
2
11
Ziele dieser Arbeit
Das ZDF plant, eine zentrale Stelle zum Mitschneiden des eigenen Programms zu schaffen. Diese Forderung hat ihren Ursprung an verschiedenen Stellen im Haus.
Ein solches System wird unter anderem benötigt, um Zuschaueranfragen, welche sich um
das Nicht-Vorhandensein von Diensten/Angeboten oder Sendefehler drehen, besser
bearbeiten zu können. Des Weiteren ist die aktuelle Situation so, dass beispielsweise Redaktionen ihre eigenen Sendungen aufnehmen. Hierfür kommen die verschiedensten
Techniken von VHS-Rekordern über DVD-Rekorder bis hin zu anderen Aufzeichnungstechniken zum Einsatz. Solche „Privatmitschnitte“ sollen durch das geplante System
unnötig werden, da dadurch eine zentrale Stelle entsteht, an der ein Interessierter
Sendeinhalte in vielen verschiedenen Formaten abrufen kann.
Weiterhin ist geplant, das On-Demand-Streaming5 Angebot des ZDF zu erweitern und
dieses System als Quell-Plattform für Sendeinhalte zu verwenden. Da sämtliche Sendeinhalte bereits vorgehalten werden, bietet sich dies an.
Hierbei ist es nötig, das komplette Bouquet6 des ZDF, zurzeit bestehend aus ZDF,
ZDFinfokanal, ZDFdokukanal, ZDFtheaterkanal, 3sat und KiKa in unveränderter Qualität aufzuzeichnen.
Um die Fehlerfreiheit der Signale kontrollieren zu können, ist es erforderlich, die Sendedaten nicht an einer verfügbaren Stelle im Haus, das heißt vor dem Senden zu analysieren, sondern das bereits gesendete und über DVB-S rückempfangene Satellitensignal zu
verwenden. Oft liegen auftretende Fehler nämlich nicht im Hause des Senders selbst,
sondern irgendwo in der Sendekette zwischen ZDF und den verschiedenen Empfängern.
Hierfür soll ein System geschaffen werden, das 24 Stunden am Tag alle Inhalte des ZDFBouquets mitschneidet und entsprechende Möglichkeiten anbietet, sowohl AudioVideodaten zu extrahieren, als auch den DVB Datenstrom auf Fehler zu analysieren.
5
6
On-Demand-Streaming – Fernsehinhalte auf Abruf, die übers Internet betrachtet werden können
Bouquet – Logische Gruppierung verschiedener Sender. Alle Spartensender des ZDF bilden z.B. ein
Bouquet
12
3 Grundlagen zu digitalem Fernsehen
3
13
Grundlagen zu digitalem Fernsehen
Die Digitaltechnik hat in den letzten Jahren in sehr vielen Bereichen große Fortschritte
gemacht. Besonders ausgeprägt ist diese Entwicklung im Elektronik-Sektor. Nahezu kein
heutiges elektronisches Gerät kommt ohne Digitaltechnik aus.
Signale, die früher analog verarbeitet wurden, werden heute vollkommen digital übertragen. Der Vorteil einer digitalen Übertragung liegt darin, dass sichergestellt ist, dass ein
Signal beim Empfänger in derselben Qualität ankommt wie es vom Sender gesendet
wurde.
Ein einfaches Beispiel ist das Telefon. Wo früher noch analoge Signale übertragen wurden, ist heutzutage das komplette Telefonnetz digital. Selbst sehr lange Entfernungen
werden dank Digitaltechnik heute mit dem Telefon in unverminderter Tonqualität überbrückt.
In der heutigen Fernsehproduktion hat die Digitaltechnik bereits vor Jahren ihren Siegeszug begonnen. Geräte wie Kameras, Schnittcomputer oder Bildmischer besitzen heutzutage alle Schnittstellen, um ihre Daten in digitaler Form auszutauschen. Im Bereich der
professionellen Videotechnik hat sich SDI7 etabliert, das je nach Quellenformat Daten in
unkomprimierter Form mit Datenraten von 143 Mbit/s bis 540 Mbit/s überträgt.
Mit der Übertragung digitaler Fernsehsignale beschäftigt sich das im Jahre 1993 gegründete DVB-Project. Zur Datenreduktion kommt hier der MPEG-2 Standard zum Einsatz,
wodurch es ermöglicht wird, Videodaten über die schmalbandigen Fernsehkanäle zu
übertragen.
So wurde dann Ende 1993 DVB-S vom europäischen Normungsinstitut ETSI als Standard für die digitale Satellitenübertragung verabschiedet. In den darauf folgenden zwei
Jahren erschienen auch Entwürfe für die terrestrische (DVB-T) und kabelgebundene
(DVB-C) Übertragung. [DVBORG]
Bis heute hat sich DVB in vielen Teilen der Welt als Übertragungsstandard für digitale
Fernsehsignale etabliert.
Dank der geringen Datenraten der MPEG-2 Videosignale ist es bei DVB nicht nur möglich, mehrere Programme innerhalb der Frequenz eines herkömmlichen analogen
7
SDI – Serial Digital Interface – Übertragung von digitalen Videosignalen via Koaxialkabel
14
Kanals unterzubringen, sondern es erlaubt darüber hinaus auch die Übertragung von
Zusatzinformationen.
Die Übertragung dieser verschiedenartigen Daten wird möglich, indem ein so genannter
Multiplex gebildet wird, in dem die unterschiedlichen Daten zu einem einzigen Datenstrom – dem Transportstrom – zusammengesetzt werden.
Die logische Zusammensetzung mehrerer Programme wird Bouquet genannt. Ein Bouquet ist immer logisch zu sehen, nicht physikalisch. So kann ein Transportstrom durchaus
mehrere Bouquets enthalten oder es kann sich ein Bouquet über mehrere Transportströme verteilen.
3.1 DVB-S/C/T
3.1
15
DVB-S/C/T
Abbildung 1 beschreibt mögliche Verbreitungswege der digitalen Fernsehsignale. Dies
kann über verschiedene Ausstrahlungswege geschehen. Als Haupt-Signal werden immer
Signale des DVB-S Systems verwendet, die für DVB-C und DVB-T an Kopfstationen
der Netzbetreiber empfangen werden. Dort werden sie entsprechend bearbeitet8 und
über das eigene Netz gesendet.
Die verschiedenen Ausbreitungswege unterscheiden sich nur in der physikalischen Übertragung. Die Form der empfangenen Daten ist immer gleich.
Abbildung 1: Verteilung von DVB-Signalen [LENZ]
3.2
Der DVB-Transportstrom
Um Fernsehprogramme über DVB zu übertragen, werden zunächst alle Audio- und Videosignale getrennt in MPEG-2 kodiert. Es entsteht also für jede Komponente ein sepa-
8
Anpassung von Datenraten, neues Multiplexing, etc.
16
rater Elementarstrom9 (ES). Diese Ströme werden wiederum von einem Packetizer in
kleinere Elemente variabler Länge zerlegt.
Neben diesen Audio- und Videoströmen werden auch Zusatzdaten auf die gleiche Art
und Weise paketiert. Eine vorherige Digitalisierung entfällt dabei, da diese Daten ohnehin
bereits in digitaler Form vorliegen.
Die so gebildeten PES-Pakete formen nach dem Passieren des Packetizers wiederum
jeweils einen Packetized Elementary Stream (PES). Dieser Vorgang wird in Abbildung 2
verdeutlicht.
Abbildung 2: Umwandlung von Elementrastrom zu Transport Strom
Ein solches PES-Paket besteht immer aus einem charakteristischen, festgelegten Header10
und den Nutzdaten, dem Payload.
Elementarstrom (Elementary Stream) – Datenstrom, der nur ein einziges Element (Audio, Video, Daten)
transportiert
10 Header – Metadaten am Anfang einer Datei / eines Datenblocks, um z.B. den Ursprung der Daten zu
kennzeichnen
9
3.2 Der DVB-Transportstrom
17
Abbildung 3: Aufbau eines PES Pakets
Der Header bezeichnet, um welche Art von Daten (Audio, Video, Zusatzdaten) es sich
handelt und gibt die Länge des gesamten Pakets an. Außerdem enthält er – vorausgesetzt
es handelt sich um Audio- oder Videodaten – die PTS11- bzw. DTS12- Zeitstempel, die für
die Synchronisation der Datenströme verwendet werden.
Die Länge eines PES-Pakets ist variabel, wobei die maximale Gesamtlänge auf
65541 Bytes [KLEIN] begrenzt ist.
Nach der Paketierung in PES-Pakete werden diese wiederum vom Multiplexer in kleinere, gleich große Pakete von 188 Bytes zerlegt, welche den Transportstrom (TS) bilden.
Hier wäre es grundsätzlich auch möglich, einen „Program Stream“ (PS) zu generieren,
wie er beispielsweise auf einer DVD zu finden ist. Der Program Stream besteht im Gegensatz zu einem Transport Stream aus Paketen variabler Länge. Ein Program Stream
eignet sich allerdings nicht für fehlerbehaftete Transportwege wie die Satellitenübertragung. Deshalb wurde für DVB festgelegt, ausschließlich einen Transport Stream zu verwenden. Darüber hinaus ist es nur mit einem Transport Stream möglich, Programme mit
unterschiedlichen Zeitbasen innerhalb eines Kanals zu übertragen. [REIMERS]
Die Pakete des Transport Streams bestehen ebenfalls aus einem Header und Nutzdaten.
Um die nachfolgenden Daten richtig interpretieren zu können, muss ein Empfänger des
Transport Streams den Beginn eines solchen TS-Pakets suchen. Hierfür besteht das erste
Byte des Headers eines TS-Pakets aus einer charakteristischen Bitfolge, dem Sync-Byte.
Dies identifiziert den Beginn eines TS-Pakets eindeutig. Das Sync-Byte besitzt immer die
Bitfolge 0100 0111 = 0x47 (Dezimal: 71).
11
12
PTS – Presentation Timestamp
DTS – Decode Timestamp
18
Abbildung 4: Aufbau eines TS Pakets
Neben dem Sync-Byte ist ein weiteres wichtiges Feld im Header eines TS Pakets die Packet-ID (PID). Dieser Wert repräsentiert die Zugehörigkeit eines TS-Pakets. Pakete mit
identischer PID gehören auch zum selben Elementarstrom. Das heißt jede Komponente,
also jeder Elementarstrom, des Transport Streams besitzt eine eigene eindeutige PID.
Aus den vorangehend erläuterten Eigenschaften wird die Struktur des DVB-Signals in
Abbildung 5 dargestellt.
Abbildung 5: Paketierung der Datenströme bei DVB
Die Pakete des PES werden samt Header in den Payload der TS-Pakete gemapped13. Da
PES-Pakete im Allgemeinen größer sind als TS-Pakete, wird im jeweils folgenden TS-
13
Mapping – hier: Aufteilen
3.3 DVB-SI / PSI
19
Paket an der entsprechenden Stelle des PES-Pakets angesetzt, wo das Schreiben des letzten Pakets beendet wurde. Ist ein PES-Paket fertig und es besteht noch Raum im TSPaket, so werden so genannte Stuffing-Bytes eingefügt, um den Rest des TS-Pakets mit
Null-Werten zu füllen und somit die vorgeschriebene Länge des Pakets zu gewährleisten.
[ISO 13818-1]
3.3
DVB-SI / PSI
3.3.1 Grundlagen
Beim digitalen Fernsehen besteht neben der Möglichkeit, mehrere Audio- und VideoProgramme zu übertragen die Möglichkeit, Zusatzinformationen mitzusenden. Diese
Zusatzinformationen werden als PSI (Program Specific Information) und SI (Service
Information) Daten bezeichnet.
PSI Daten werden durch MPEG-2 [ISO 13818-1] definiert und dienen dem Decoder
dazu, sich im Datenstrom zu orientieren. Eine Funktion ist beispielsweise, die verschiedenen PES14 ihren entsprechenden Programmen zuzuordnen.
SI Daten sind eine Erweiterung, welche durch den DVB-Standard [ETSI 300468] definiert werden. Hierzu gehören beispielsweise Sender- und Bouquetnamen oder die elektronische Programmzeitschrift (EPG), welche Sendezeiten und Beschreibungen zu den
Sendungen enthält.
Diese Zusatzdaten werden in Form von „Tabellen“ (Tables) übertragen. Es gibt verschiedene Arten von Tables, die sich untereinander in ihrem Inhalt unterscheiden, von
der Struktur her jedoch alle einen ähnlichen Aufbau besitzen. Jede Table besitzt eine
charakteristische Table-ID, durch die der Inhalt der Table festgelegt wird.
Bei der Übertragung werden die Tables innerhalb des Transportstroms zyklisch ausgespielt. Dafür legt der Standard bestimmte Minimal- und Maximalintervalle für die einzelnen Tabellenarten fest. Es ergeben sich also unterschiedliche Häufigkeiten der Tables im
Transportstrom. Wichtige werden häufiger gesendet als weniger wichtige.
14
PES – Packetized Elementary Stream
20
3.3.2 Übersicht SI / PSI
Abbildung 6 liefert einen Überblick über alle PSI / SI Tabellen sowie deren zugehörige
Ausspiel-Intervalle [ETSI 300468].
Abbildung 6: Übersicht aller PSI / SI Tables
Im Folgenden werden die Bedeutungen einiger dieser Tables erläutert.
3.3 DVB-SI / PSI
21
PAT (Program Association Table)
Die PAT enthält Informationen über die verschiedenen Services15 eines Transportstroms.
Der Empfänger kann anhand der PAT interpretieren, wie viele Services im Transportstrom existieren und die entsprechenden PIDs zu deren PMT zuordnen, welche weitere
Informationen enthält. Die PAT besitzt immer die PID 0x00 und die Table-ID 0x00.
PMT (Program Map Table)
Für jeden Service im Datenstrom existiert je eine PMT. Diese beinhaltet Informationen
darüber, welche PES-Datenströme (Audio, Video, Zusatzdaten) – welche jeweils wiederum eine eigene PID besitzen – zu welchem Service gehören.
Die PAT in Verbindung mit der PMT ist ein essentieller Bestandteil der PSI-Daten. Anhand dieser Daten kann sich ein Empfänger im Datenstrom orientieren und die verschiedenen Elementarströme untereinander in Verbindung bringen.
Abbildung 7: Zusammenspiel d. Tables PAT und PMT
15
Service – bezeichnet ein Programm welches durch den Transportstrom übertragen wird
22
NIT (Network Information Table)
Die NIT enthält Informationen über das physikalische Netzwerk. Sie transportiert Informationen über das aktuelle Netzwerk, sowie über die Transportströme, die über dieses
Netzwerk übertragen werden.
Ein Netzwerk bezeichnet nach [ETSI 300468] alle Transportstrom-Multiplexe eines bestimmten Übertragungssystems. Beispielsweise bilden die Transportströme, welche über
das Astra16 Satellitennetzwerk gesendet werden, ein Netzwerk.
Durch den Empfang dieser Table bekommt ein Empfänger Informationen über alle ihm
zur Verfügung stehenden Transportströme und kann sich so selbständig für diese weiteren Ströme konfigurieren.
BAT (Bouquet Association Table)
Ein Bouquet ist die Zusammenfassung mehrerer Programme zu einer logischen Einheit.
Die Sender beispielsweise, die logisch – aber nicht zwingend physikalisch – zum ZDF
gehören, bilden ein Bouquet.
Diese zusammengehörenden Programme müssen nicht zwangsweise auf dem gleichen
Transportstrom ausgestrahlt werden, sondern es ist möglich, die Programme eines Bouquets über mehrere Transportströme zu verteilen, diese aber als eine logische Einheit
anzeigen zu lassen.
SDT (Service Description Table)
Die SDT enthält Beschreibungen der in einem Transportstrom vorhandenen Services17.
Hierzu gehören beispielsweise der Name und die Sprache des Services.
Ein Empfänger kann diese Table dazu benutzen, die Namen der empfangenen Programme anzuzeigen.
EIT (Event Information Table)
Die EIT enthält Daten zu den Events18, welche auf den verschiedenen Services ausgestrahlt werden.
Astra – Name einer Flotte von 13 geostationären Kommunikationssatelliten im Eigentum der Firma SES
Global [ASTRA]
17 Service – Ein „Programm“. Z.B. ZDF oder 3sat
18 Event – Ein Event ist bei DVB eine Sendung, die eine festgelegte Startzeit und Dauer besitzt
16
3.3 DVB-SI / PSI
23
Anhand dieser Tabelle ist es einem Empfänger möglich, den „EPG“19 (Elektronische
Programmzeitschrift) zu generieren.
Die EIT enthält u. a. Namen und Inhalt von Sendungen, deren Startzeit und Dauer. Außerdem liefert sie Informationen über die Altersfreigabe sowie das Programmgenre
(Nachrichten, Spielfilm, Sport, usw.)
Um möglichst umfassende Programminformationen aufbauen zu können, ist in [ETSI
300468] vorgesehen, sowohl Event-Informationen für den eigenen Transportstrom zu
senden („actual TS“), als auch für andere Transportströme („other TS“).
Außerdem wird bei der EIT unterschieden zwischen „EIT present/following“ und „EIT
schedule“. Syntaktisch20 sind diese beiden Varianten identisch. Die EIT present/following allerdings beschreibt lediglich zwei Events, nämlich den aktuell gesendeten und den unmittelbar darauf folgenden. Durch dieses System kann ein Empfänger –
wenn nun die EIT present/following sich ändert – den genauen Zeitpunkt feststellen, zu
dem eine neue Sendung beginnt. Das Vorhandensein der EIT present/following ist im
Standard zwingend festgelegt, wobei die EIT schedule als optional definiert ist.
Die EIT schedule beschreibt Events, die nach diesen zwei unmittelbar folgenden auftreten und stellt somit eine Gesamtübersicht über das Programm dar.
TDT (Time and Date Table)
In dieser Tabelle wird die aktuelle UTC-Zeit21 übertragen. Damit ist es einem Empfänger
möglich, seine interne Uhr zu synchronisieren.
3.3.3 Aufbau von SI-/PSI Daten
DVB SI-/PSI-Daten bestehen aus verschiedenen Elementen. Die Hauptstruktur hierbei
repräsentieren Tables, welche eine oder mehrere Sections beinhalten. Sections wiederum
besitzen Descriptoren. Das Wort „Table“ in diesem Sinne ist anfangs leicht verwirrend,
da sich die Bezeichnung nicht wirklich auf die Form der Datenstruktur zurückführen
lässt. Ein Table ist vielmehr ein logischer Verbund mehrerer Sections.
EPG – Electronic Program Guide
Syntax – Festgelegte formale Grammatik
21 UTC – Universal Time Coordinated – Referenzzeit, von der alle Zeitzonen abgeleitet werden (Nachfolger der GMT – Greenwich Middle Time)
19
20
24
3.3.3.1
Tables
Abbildung 8: Aufbau einer Table
Eine Table kann aus einer oder einem Satz von bis zu 256 Sections bestehen. Eine Section ist eine Untereinheit einer Table. Aufgrund ihres Aufbaus kann eine Section auch
einzeln Informationen liefern, jedoch steht eine Table immer für einen kompletten Satz
an Informationen.
3.3.3.2
Sections
Eine Section hat eine variable Größe von bis zu 1024 Byte. Sections der EIT stellen hier
eine Ausnahme dar, da diese bis zu 4096 Bytes lang sein dürfen [ETSI 300468]. Im Gegensatz zur DVB-Table, welche aus mehreren Sections bestehen kann, ist eine Section an
sich in ihrer Form schon eher als Tabelle anzusehen.
Abbildung 9 zeigt ein Beispiel einer Event Information Section der EIT:
3.3 DVB-SI / PSI
25
Abbildung 9: Beispiel einer Section
Für jede Art von Table (PAT, NIT, EIT, usw.) ist der Aufbau deren Sections unterschiedlich.
Es gibt jedoch einige Felder, die den Sections zu allen Tables gleich sind. Dies sind die
ersten 8 Byte von table_id bis last_section_number.
table_id
Die table_id ist für jeden Typ von Section eindeutig definiert ([ISO 13818-1], [ETSI
300468]) und ordnet so einer Section ihren Typ zu. Auf den ersten Blick lässt sich aus
Abbildung 6 ableiten, die PID würde bereits die Aufgabe übernehmen, eine Table eindeutig einzuordnen. Es ist allerdings auch möglich, dass mehrere Tables über eine PID
gesendet werden (siehe TDT, TOT in Abbildung 6), was diese zusätzliche Unterscheidung notwendig macht.
26
section_syntax_indicator
Section_syntax_indicator ist ein 1-bit Feld, welches meistens einen festgelegten Wert besitzt
oder – je nach Art der Table – einen bestimmten Zustand beschreibt.
section_length
Beschreibt die Länge der Section in Bytes. Gezählt wird ab dem diesem Wert direkt folgenden Byte. Das heißt, da section_length genau bei der Position 3 Bytes endet, besitzt eine
Section immer eine tatsächliche Länge von section_length + 3 Bytes.
table_id_extension
Dieser Wert wird genutzt, um so genannte Subtables zu identifizieren. Der Name des
Feldes ist für jede Table anders, hier in der EIT lautet die Bezeichnung „service_id“.
version_number
Dieses Feld wird verwendet, um Änderungen an einer Table zu identifizieren. Bei jeder
Änderung der Daten einer Table wird diese Nummer um 1 erhöht und bei Erreichen des
Werts 31 wieder bei 0 angefangen. Innerhalb einer Table existiert immer dieselbe version_number.
section_number
Da eine Table aus mehreren Sections bestehen kann, wird dieses Feld dazu genutzt, die
einzelnen Sections eindeutig zu identifizieren und untereinander zu ordnen.
last_section_number
Gibt die section_number der letzten genutzten Section für diese Table an.
Wie aus Abbildung 8 erkennbar, kann eine Section neben diesen Feldern zusätzlich noch
so genannte Loops und Descriptoren enthalten.
Ein Loop besteht aus einer bestimmten Anzahl sich wiederholender Felder. Im obigen
Beispiel der EIT repräsentiert der dort vorhandene Loop jeweils einen Event.
3.3.3.3
Descriptors
Descriptoren beinhalten die eigentlichen Nutzdaten einer Table. Das Format von Descriptoren ist ähnlicher Natur wie das von Sections. Es können also sowohl Felder als auch
3.3 DVB-SI / PSI
27
Loops vorhanden sein. Lediglich ein weiterer Descriptor kann sich nicht innerhalb eines
Descriptors befinden.
Es existiert eine sehr große Auswahl an Descriptoren. Jeder Descriptor beschreibt einen
anderen Inhalt und wird in den Standards [ETSI 300468] und [ISO 13818-1] definiert.
Als Beispiel in Abbildung 10 die Struktur des „Service Descriptor“:
Abbildung 10: Beispiel eines Descriptors
Descriptoren wiederum besitzen einen eigenen Header, welcher aus descriptor_tag und
descriptor_length besteht. Wie Tables auch besitzt jeder Descriptor eine eindeutige Identifizierung, das descriptor_tag. Dieses beschreibt, um welche Art von Descriptor es sich handelt.
Abbildung 10 ist weiterhin zu entnehmen, dass beispielsweise Textdaten wie service_name
in Form von Loops aus einzelnen Zeichen (char) übertragen werden.
28
29
4.1 Randbedingungen
4
4.1
Analyse und Erläuterung der Randbedingungen
Randbedingungen
Als Host-System sollte ein handelsüblicher Server-PC
mit Intel oder AMD-Prozessoren dienen.
Das Signal darf nicht – wie auf den ersten Blick plausibel – an einer beliebigen verfügbaren Stelle im Hause des ZDF, also vor dem Senden abgegriffen werden. Um ein möglichst genaues Abbild der gesendeten Signale zu erhalten, müssen diejenigen Signale
Abbildung 11: DVB-Rückempfang
empfangen werden, welche bereits vom Satellit
stammen und in jedem Haushalt Deutschlands ebenso zu empfangen sind. Dies wird
„Rückempfang“ genannt.
Das DVB-Signal des ZDF besteht momentan aus einem Transportstrom, welcher auf
einem Transponder gesendet wird. Ein DVB-Transportstrom besitzt eine NettoDatenrate von 38 Mbit/s. Dies entspricht einer benötigten Speicherkapazität von ca. 401
GByte pro Tag.
4.2
Vorhandene Systeme auf dem Markt
Zu Beginn dieser Arbeit waren keine Systeme auf dem freien Markt vorhanden, die das
gewünschte Funktionsspektrum abdecken.
Während der Bearbeitung dieser Diplomarbeit wurde von der Firma Dimetis22 der ARS –
ASI Record Server fertig gestellt. Dieser Server ähnelt in seiner Funktionalität sehr dem
in dieser Arbeit entwickelten System.
Die größten Unterschiede zu dem geplanten System dieser Arbeit sind unter anderem,
dass der ARS-Server von Dimetis zum Daten-Empfang statt DVB-Karten teure ASI23Karten verwendet. Dies bringt einerseits etwas mehr Flexibilität, benötigt allerdings zusätzlich einen Demultiplexer, um die empfangenen DVB-Daten in einen ASI-Strom umzuwandeln. Weiterhin wurde die Funktion „Video extrahieren“ in diesem Produkt gänzlich nicht verfolgt. Zur Analyse des Transportstroms wird die externe Software StreamX-
22
23
Dimetis - http://www.dimetis.de/
ASI – Asynchronous Serial Interface
4 Analyse und Erläuterung der
30
Randbedingungen
pert der Firma DekTec verwendet, welche zwar umfangreiche Funktionen bietet, allerdings in der Verwendung stark eingeschränkt ist. Die Software ist ausschließlich lauffähig,
wenn eine ASI-Karte derselben Firma im Rechner eingebaut ist, was sich sehr nachteilig
auf eine Client-Server Architektur auswirkt.
Neben dem ARS von Dimetis wird derzeit ein System von der Firma Promise.tv im Auftrag der BBC entwickelt. Es besitzt 3,2 TB Festplattenkapazität und ist damit in der Lage,
alle sechs terrestrischen DVB-T Multiplexe im UK eine Woche lang zu speichern.
Bei diesem „Pandora Box“ genannten Prototyp geht es BBC darum zu erforschen, wie
sich Fernsehzuschauer verhalten, wenn sie eine solch enorme Programmauswahl zur
Verfügung haben.
Leider ist dieses Projekt noch ein Prototyp und es scheint, als würde nicht weiter daran
entwickelt. [INFORMITV]
4.3
Hauptschwerpunkt
Der Hauptschwerpunkt dieser Arbeit liegt auf der Aufnahme und effizienten Weiterverarbeitung von DVB-Daten. Hierfür müssen für die gesamte Kette, das heißt Aufnahme,
Speicherung und Organisation, Verarbeitung (Daten, Video) und Ausgabe Konzepte
erstellt werden.
Da allerdings auch der leistungsfähigste Einzelserver nicht als vollwertiger EncoderRechner zu sehen ist, wird auf die eigentliche Ausgabe weniger tief eingegangen, da ohnehin eine Anbindung an das Streaming-System des ZDF vorgesehen ist.
5.1 Diskussion und Evaluierung verschiedener Lösungsansätze
5
31
Konzept einer Ziellösung
5.1
Diskussion und Evaluierung verschiedener Lösungsansätze
Zur Realisierung des Vorhabens sind verschiedene grundsätzliche Herangehensweisen
denkbar. Da im Bereich DVB bereits mehrere Projekte – vor allem im Open-Source Sektor – existieren, ist eine sich bietende Möglichkeit, existierende Software zu verwenden
und entsprechend den eigenen Bedürfnissen anzupassen bzw. zu erweitern.
Die andere Möglichkeit besteht darin, Software von Grund auf in Eigenregie zu entwickeln, was dem Programmierer mehr Freiheiten lässt und vor allem mehr Einblicke in das
zu Grunde liegende System bietet.
5.1.1 Open-Source
Der Ausdruck Open-Source steht für „Quellen-Offenheit“. Er bedeutet im Sinne der
„Open Source Definition“, dass jeder die Möglichkeit hat, Einblick in den Quellcode zu
haben sowie die Erlaubnis, diesen Quellcode zu verändern und/oder weiterzugeben.
Die zwei am weitesten verbreiteten Open-Source Lizenzen sind die GNU General Public
License (GPL) und GNU Lesser General Public License (LGPL). Open-Source Lizenzen
werden von der Free Software Foundation [FSF] herausgegeben.
Folgende sind die grundsätzlichen Inhalte der GPL Lizenz:
-
Jeder darf unter GPL Lizenzierte Software uneingeschränkt und zu jedem Zweck
nutzen.
-
Jeder darf Kopien des Programms verteilen. Der Source-Code muss allerdings
mitverteilt werden bzw. die Möglichkeit geschaffen werden, den Source-Code
einzusehen.
-
Die Software darf nach Belieben verändert werden.
-
Veränderte Software darf unter Berücksichtigung der vorhergehenden Regeln ebenfalls vertrieben werden. Diese muss ebenfalls unter GPL lizenziert sein.
Die LGPL-Lizenz enthält dieselben Grundzüge. LGPL-Software und veränderte LGPLSoftware darf ebenfalls nur unter LGPL oder GPL vertrieben werden. Der größte Unterschied zu GPL liegt darin, dass es erlaubt ist, gegen LGPL-Lizenzierte Software dynamisch zu linken, ohne dass das entsprechende Programm auch unter GPL oder LGPL
32
5 Konzept einer Ziellösung
lizenziert ist. So eignet sich LGPL für Bibliotheken, die auch in kommerziellen Produkten verwendet werden.
Da die Open-Source-Gemeinde im Internet ständig wächst, liegt es nahe, in diesem Bereich nach geeigneten Tools zu suchen und diese zu nutzen.
Hier gibt es so genannte Media-Center-Software, die in erster Linie dafür ausgelegt ist,
einen PC zur Fernseh-Zentrale zu machen. Diese Programme bieten auch die Möglichkeit, Fernsehprogramme aufzunehmen. Dank digitaler Übertragungstechnik gibt es mehrere Produkte, die bei Bedarf alle Programme eines Transponders aufnehmen können.
Auf diese wird hier nun näher eingegangen.
VDR
VDR ist eines der bekanntesten und beliebtesten Open-Source Mediacenter Projekte.
Der Name VDR steht für „Video Disk Recorder“ und wurde ursprünglich von Klaus
Schmidinger entwickelt. VDR besitzt seinen Schwerpunkt in der Aufnahme und Wiedergabe von Fernsehprogrammen.
Dank der Open-Source-Architektur ist es möglich, eigene Plugins24 zu programmieren,
von denen auch eine große Anzahl existiert. So lässt sich VDR Stück für Stück an eigene
Bedürfnisse anpassen.
VDR besitzt von Haus aus die Möglichkeit, mit einer DVB-Karte mehrere Programme
(vorausgesetzt, sie liegen auf dem gleichen Transponder) gleichzeitig in unveränderter
Qualität aufzunehmen.
Für VDR existiert eine sehr große Community, welche sich bei einer Eigenentwicklung
von Plugins unterstützend auswirkt.
MythTV
MythTV sieht, ganz ähnlich wie VDR seine Hauptaufgabe in der Aufnahme von Fernsehprogrammen und deren Wiedergabe. MythTV kommt in der Grundkonfiguration
bereits mit mehr Features zum Anwender, als VDR. Da diese Plugins alle darauf ausgerichtet sind, eine „Multimedia-Zentrale“ aufzubauen, sind diese für die vorliegende Arbeit
nicht nutzbar. Außerdem sind keinerlei Informationen über die Entwicklung zusätzlicher
Plugins für diese Software zu finden.
24
Plugin – Softwaremodul, welches in eine andere Software „eingeklinkt“ wird
5.2 Funktionen im gewählten System
33
Ein allgemeines Problem dieser so genannten Media-Center-Softwares stellt die Tatsache
dar, dass diese Programme auf möglichst komfortable Verwendung im Wohnzimmer
ausgelegt sind. Sie setzen zur Aufnahme alle so genannte Premium DVB-Karten ein.
Eine Premium DVB-Karte hat im Gegensatz zu den so genannten Budget DVB-Karten
einen eigenen MPEG-2-Prozessor bereits in der Hardware integriert. Durch diesen ist es
möglich, die Programme eines Transportstroms einzeln zu interpretieren und auf Festplatte zu schreiben. Unmöglich ist es dagegen, diesen Decoder zu umgehen und die
Transportstromdaten unverändert an den Datenspeicher weiterzugeben.
Da es für diese Arbeit essentiell ist, alle Daten eines Transportstroms in unveränderter
Qualität zu erhalten, eignen sich diese Premium DVB-Karten und somit die darauf aufsetzenden Media-Center Programme wie VDR oder MythTV nicht.
5.1.2 Eigens programmierte Software
Nach einer eingehenden Analyse der vorhergehenden Alternativen wird ersichtlich, dass
es wirtschaftlich am sinnvollsten ist, statt einem Top-Down Vorgehen (Grundsoftware
vorhanden, Zusatzfunktionen selbst programmieren) ein Bottom-Up Vorgehen zu wählen. Hierbei werden die zentralen Elemente eigenständig entwickelt und für kleinere Aufgaben Fragmente anderer Software hinzugefügt.
5.2
Funktionen im gewählten System
Das Resultierende System lässt sich in 3 groben Funktionsfeldern beschreiben. Diese sind
erstens die Aufnahme, bei der es um die Frage geht, auf welchem Weg und in welcher
Form die Daten ins System gelangen. Das zweite Feld besteht aus der Organisation der
Daten, wobei beschrieben wird, wie die empfangenen Daten im System abzulegen sind.
Das dritte große Feld ist die Präsentation. Hier geht es um die Ausgabe sämtlicher Daten.
Damit ist sowohl die Extrahierung von Video-Daten, als auch die Analyse des Transportstroms gemeint.
5.2.1 Aufnahme
Um ein genaues Abbild der gesendeten DVB-Signale zu bekommen, wird der gesamte
Transportstrom in roher Form auf die Festplatten geschrieben. Dies geschieht in einer
Form, die es ermöglicht, bei Erreichen der Maximalkapazität des Datenspeichers alte
34
Daten zu entfernen um Platz für neue zu schaffen. Für diesen Zweck muss ein Ringpuffer-Mechanismus entworfen werden, durch den diese Aufgabe bearbeitet wird.
Die Aufnahme der Signale wird durch eine DVB-Empfangskarte realisiert. Die richtige
Auswahl dieser Karte ist ein wichtiges Element, da Karten verschiedener Hersteller verschiedene Software-Schnittstellen besitzen, welche wiederum unterschiedliche Funktionen und Möglichkeiten bieten.
Für diese Arbeit wurden mehrere Modelle evaluiert. Zum einen Karten der Firma Technotrend, Technotrend Budget und Technotrend Premium Line, zum anderen auch Karten von Hauppauge und Technisat.
Gleich zu Anfang fielen Karten der Technotrend Premium Line aus dem Rennen. Solche
Karten besitzen wie bereits beschrieben einen Decoder-Chip auf der Platine, welcher das
Verarbeiten des DVB-Transportstroms bereits übernimmt und somit keine Rohdaten an
die Software weitergeben kann.
Von der Firma Technisat wurde die Karte SkyStar 2 ausgetestet. Diese Karte bietet eine
sehr übersichtliche und gut dokumentierte Software-Schnittstelle. Trotz aller Übersichtlichkeit bietet diese allerdings recht wenige Funktionen. Unter anderem wird die direkte
Speicherung des DVB-Transportstroms nicht unterstützt und es können lediglich bis
maximal 39 PIDs gleichzeitig empfangen werden. Eine Kopie des Technisat-SDK sowie
dessen Dokumentation befindet sich auf der CD im Anhang zu dieser Diplomarbeit.
Während die Lieferung der Budget-Karte von Technotrend noch ausstand, wurde ein
angeblich zu dieser baugleiches Modell mit dem Namen Nova-SE2 der Firma Hauppauge
getestet. Dieser Test schlug direkt fehl, da die Karte sich nicht durch das SoftwareDevelopment-Kit von Technotrend ansprechen ließ.
Die endgültige Auswahl wurde mit dem Eintreffen der Technotrend-Karte Budget S1400 getroffen. Diese Karte verfügt über alle Funktionen, die benötigt werden. Ein kleiner Nachteil bleibt. Das Software-Development-Kit25 ist zwar sehr mächtig, leider existiert aber keinerlei Dokumentation hierfür, was die spätere Software-Entwicklung manchmal erschwerte.
5.2.2 Ringpuffer
Der Ringpuffer besteht aus einer Software-Schnittstelle und einem festgelegten Verzeichnis auf der Festplatte. Darin gespeicherte Daten werden in passende Dateigrößen von bis
25
Software-Development-Kit (SDK) – Kollektion von Funktionen, Klassen, etc., welche es einem Entwickler erlauben, Anwendungen zu erstellen, die darauf basieren
35
zu 2 Giga-Byte aufgeteilt. Diese Grenze wurde eingeführt, da Datei-Operationen der
Programmiersprache C++ Dateien nur bis zu einer Obergrenze von exakt 2 GB adressieren können. Betriebssystem-Interne Funktionen wären zwar in der Lage, größere Dateien
zu verarbeiten, was allerdings mit enorm erhöhtem Aufwand einhergehen würde. Aus
diesem Grund wurde entschieden, diese Grenze von 2 GB festzulegen.
Der Ringpuffer muss sich darum kümmern, alte Elemente bei Erreichen der maximalen
Größe zu entfernen, um neue Elemente hinzufügen zu können.
Außerdem wird die Aufgabe des Schreibens und automatischen Teilens, sowie des dateiübergreifenden und nahtlosen Lesens aus dem Ringpuffer übernommen.
5.2.3 Extrahierung der SI-Daten
Um später komfortabel im Strom navigieren zu können, ist es nötig, einige Daten aus
dem Transportstrom zu extrahieren, die als Navigationshilfe dienen können.
Zur Navigation innerhalb des Datenstroms benötigt man Informationen über die Sender
und deren zugehörigen MPEG-Ströme, sowie die Programm-Informationen, die die Sendezeiten von Sendungen angeben.
Um dies zu bewerkstelligen müssen folgende Tabellen ausgelesen werden:
-
PAT (Program Association Table)
Um auszulesen, welche Services (Programme) im Strom vorhanden sind und die
PIDs der zugehörigen PMTs zu erhalten.
-
PMT (Program Map Table)
Für jeden Service existiert eine PMT, auf die von der PAT aus verwiesen wird.
Die PMT enthält die PIDs zu den verschiedenen Elementardatenströmen der jeweiligen Services.
-
EIT actual transport stream p/f
Die EIT enthält Titel, Beschreibung, Sendezeit etc. zu den Sendungen, die über
die verschiedenen Services ausgestrahlt werden.
Da hier keine „Fernsehzeitschrift“ aufgebaut werden muss, sondern lediglich die
Sendungen katalogisiert werden müssen, die auch tatsächlich aufgenommen werden, reicht es hier, nur die EIT actual transport stream, present/following auszulesen. Die EIT p/f enthält ausschließlich Informationen über aktuelle und direkt
darauf folgende Sendungen.
-
SDT actual transport stream
Die SDT actual TS enthält verschiedene Informationen über die Services des
36
Transportstroms. Die hier relevante Information ist der Name des Services, welcher zur Navigation ausgewertet wird.
Diese Daten werden in einer bzw. mehreren XML26-Dateien gespeichert, die bei Bedarf
ausgelesen werden können.
5.2.4 Organisation der Daten
Dieser Abschnitt beschreibt einige Lösungsansätze zur Organisation der ausgelesenen
Daten.
Speicherung der Daten
Zu Anfang waren zwei grundsätzliche Wege zu evaluieren, die empfangenen Daten zu
speichern.
Das ist erstens die Speicherung der Ströme separat, das heißt Speicherung jedes Audio- u.
Video-Stroms einzeln, zusätzlich zu den SI-/PSI-Daten. Der Vorteil dieser Lösung liegt
klar auf der Hand. Da bereits fertige Audio- und Videoströme gespeichert werden, ist es
ein Leichtes, diese später zur weiteren Verwendung zu verarbeiten. Allerdings entstehen
bei dieser Methode auch Probleme. Die Organisation des Ringpuffers wird erschwert, da
nicht ein einziger Strom, sondern mehrere Ströme mit unterschiedlichen Datenraten gespeichert werden müssen. Zusätzlich existiert bei dieser Methode das Problem der Filterung. Um die Zusatzdaten zu erhalten, muss alles gespeichert werden, was kein Videooder Audio-Strom (die ja separat gespeichert werden) ist. Diese Funktionalität zu implementieren, würde einen sehr komplizierten Code und vor allem zur Laufzeit sehr viel
Rechenleistung benötigen, da jedes einzelne Datenpaket von 188 Bytes analysiert werden
müsste. Außerdem wäre es unmöglich, bei Bedarf das ursprüngliche Originalsignal wieder
herzustellen.
Die zweite Möglichkeit mit den empfangenen Daten zu verfahren ist, den Transportstrom in unveränderter Form auf die Festplatten zu schreiben. Bei dieser Methode gehen
keinerlei Daten verloren, da hiermit das ursprüngliche Signal erhalten bleibt. Da nur ein
einziger Datenstrom gespeichert werden muss, ist die Verwaltung des Ringpuffers weniger aufwändig, ebenso wie der Aufwand beim Empfangen der Daten. Bei diesem Vorgehen können größere Pakete als 188 Bytes verwendet werden. Da diese nicht analysiert
werden müssen, können sie direkt und ohne weitere Verarbeitung in den Ringpuffer geschrieben werden. Neben diesen gravierenden Vorteilen ist allerdings das Extrahieren der
26
XML – Extensible Markup Language
37
Daten – vor allem der Audio-/Videodaten – zu einem späteren Zeitpunkt aufwändiger,
da hier keine vorherige Trennung vorgenommen wurde und die gewünschten Ströme
umständlich aus dem Gesamtdatenstrom herausgelöst und neu gemultiplext werden müssen.
Insgesamt bietet die zweite Methode mehr Vorteile. Da die Daten unverändert gespeichert werden, bietet dieses Verfahren mehr Flexibilität auch für zukünftige Formen der
Weiterverarbeitung.
Extrahierung von EPG-Daten
Die Extrahierung der SI-Daten, um den EPG für das Frontend aufzubauen, muss kontinuierlich geschehen. Um unnötige Systembelastung zu vermeiden, ist hierfür eine sinnvolle Lösung nötig.
Zu diesem Thema gehören zwei Fragen:
1. Wie werden die Daten gespeichert? (Datenbank, XML)
2. Wie werden sie extrahiert? (Während der Aufnahme oder im Nachhinein)
Zur ersten Frage existiert nach der Untersuchung beider Möglichkeiten kein „besser“
oder „schlechter“. Beide Speichermöglichkeiten haben ihre Vor- und Nachteile.
Datenbank
XML
Vorteile:
Vorteile:
-
hohe Geschwindigkeit
-
Überprüfung auf doppelte Einträge -
Universelle Schnittstellen in alle gängi-
kann bereits von DB-System gesche-
gen Programmiersprachen
hen
Nachteile:
-
Flexibel
-
Wenig Infrastrukturabhängig
-
Keine zusätzliche Infrastruktur nötig
Nachteile:
-
DBMS27 muss installiert sein
-
Schnittstellen nicht für alle Program- -
Sehr viele unterschiedliche Parser28
miersprachen verfügbar
verfügbar, viele davon sind schlecht
Zu viele Freiheiten in der Gestaltung
implementiert
-
-
Langsamer als Datenbank
der Datenbankstruktur
27
28
DBMS – Database Management System
Parser – (XML-Parser) Softwareschnittstelle, welche Dateien im XML-Format interpretiert und in eine
Datenstruktur überführt
38
Die Entscheidung fiel vor allem wegen der höheren Flexibilität auf die Speicherung im
XML-Format. Um den signifikanten Geschwindigkeitsunterschied von XML zu einem
DBMS zu verringern, wird pro Tag eine separate XML-Datei geschrieben, welche dann
separat ausgelesen werden kann.
Die zweite Frage ist, wann die Daten extrahiert werden sollen. Von der Programmstruktur her wäre es grundsätzlich logisch, die EPG-Daten im Nachhinein, das heißt aus den
bereits gespeicherten Datendateien im Ringpuffer auszulesen. Bei Versuchen zeigte sich
allerdings, dass hier die Festplatten eine extreme Engstelle darstellen und der Vorgang
des Auslesens von EPG-Daten auf dem Entwicklungsrechner (ohne Raid) ca. 10 Minuten
pro 2GB Ringpuffer-Datei benötigt. Da EPG-Daten kontinuierlich ausgelesen werden
müssen, wäre dies erstens ein Prozess, der die Rechnerleistung des Servers dauerhaft
belegt und zweitens aufgrund der hohen Festplattenaktivität untragbar für die Hardware
wäre.
Deshalb wird eine andere Möglichkeit gewählt. Die DVB-Karten der Firma Technotrend
erlauben es, neben der Speicherung des eigentlichen Transportstroms so genannte „Section-Filter“ zu definieren. Diese analysieren die ankommenden Datenpakete aus dem
Transportstrom direkt auf der DVB-Karte, also völlig ohne weitere Festplattenaktivität
oder ähnlichem. Eine Section besitzt wie in Teilabschnitt 3.3.3.2 erläutert, eine PID und
zusätzlich eine table_id. Der „Section-Filter“, welcher vom SDK zur Technotrend DVBKarte zur Verfügung gestellt wird, setzt selbsttätig die gewünschten Sections entsprechend zusammen und gibt diese, sobald sie komplett sind, in binärer Form an den Benutzer weiter. Diese müssen dann noch entsprechend interpretiert und in die XML-Datei für
den EPG geschrieben werden.
5.2.5 Präsentation
Die Präsentations-Schicht ist das Element, mit dem ein Benutzer des Systems in Kontakt
kommt. Für die Realisierung dieser Schicht sind unterschiedliche Wege denkbar.
Da – vor allem bei der Analyse des Transportstroms – relativ viele Anzeigemöglichkeiten
nötig sind, würde sich eine GUI29-Applikation anbieten. Eine eigenständige Applikation
29
GUI – Graphical User Interface
39
allerdings wäre wiederum nicht von jedem Rechner aus zu erreichen, da diese zuerst auf
einer Maschine installiert werden müsste.
Aus diesem Grund ist ein Wunsch des ZDF, dieses System über ein Webfrontend im
Intranet bedienen zu können. Zur Analyse des Transportstromes wird dennoch ein JavaApplet in das Webfrontend eingebettet, um wenigstens hier die Vorzüge einer grafischen
Benutzeroberfläche nutzen zu können.
5.2.6 Ausfallsicherheit
Bei Systemen, die rund um die Uhr verfügbar sein sollen, hat die Ausfallsicherheit stets
hohe Priorität. Um Daten- und Ausfallsicherheit zu gewährleisten, muss Hardware doppelt vorhanden sein und Daten mit entsprechender Sicherung gespeichert werden.
Raid 5
RAID steht für „Redundant Array of Inexpensive Disks“ und vereint zwei oder mehr
Festplatten zu einer logischen Einheit. Die Gründe, ein RAID-System einzuführen sind
vielfältig. Neben der Datensicherheit (Redundanz) und Steigerung der Leistung dient
RAID auch anderen sekundären Faktoren wie zum Beispiel dem Austausch/Hinzufügen
von Festplatten im laufenden System oder der Kostenreduktion durch preiswerte Festplatten.
Es gibt verschiedene Arten von RAID, welche durch ihre „Levels“ unterschieden werden. Jeder Level dient einem anderen Ziel. Die drei am Häufigsten verwendeten RAIDLevel sind RAID-0, RAID-1 und RAID-5.
RAID-0 (Striping) beschleunigt Lese- und Schreibzugriffe, indem Daten auf zwei oder
mehr Festplatten im Verbund verteilt werden und so ein „quasi-paralleles“ Schreiben auf
mehrere Datenträger möglich ist. So werden zwar die Zugriffe beschleunigt, die Sicherheit der Daten aber verringert, da beim Ausfall einer Festplatte sämtliche Daten verloren
gehen.
RAID-1 (Mirroring) bietet eine zuverlässige Datensicherung, da Daten „gespiegelt“ werden. Ankommende Daten werden auf alle im Verbund befindlichen Festplatten geschrieben. Wenn eine dieser Festplatten ausfällt, existieren sämtliche Daten noch auf einer anderen. Eine Geschwindigkeitssteigerung resultiert aus RAID-1 nicht. RAID-1 ist kostenintensiv, da nur die Hälfte der Gesamtkapazität zur Verfügung steht.
RAID-5 ist eine Kompromisslösung aus verschiedenen Levels. Es bietet hohe Leistung
beim Lesen und Redundanz bei geringen Kosten, da nur ein kleiner Teil der zur Verfügung stehenden Speicherkapazität für Redundanz-Daten verwendet wird. Hier werden
40
die Nutzdaten wie bei RAID-0 auf alle Festplatten verteilt. Gleichzeitig werden – ebenfalls auf alle Festplatten verteilt – Redudanzinformationen mitgeschrieben, welche es
erlauben, beim Ausfall einer Platte alle ursprünglichen Daten wiederherzustellen. Nachdem eine Festplatte ausgefallen ist und diese ausgetauscht wurde, werden die Daten anhand der zuvor verteilt gespeicherten Paritydaten wiederhergestellt. Während dieses Vorgangs nimmt die Performance des Gesamtverbunds abermals deutlich ab. [PATTERSON]
Zum Einsatz kommt hier ein RAID-5, welches relativ gute Leistung mit hoher Datensicherheit vereint und zudem günstig in der Anschaffung ist. Der finanzielle Aspekt ist bei
Speicherkapazitäten im Terabyte-Bereich nicht zu vernachlässigen.
Redundanz
Redundanz bedeutet, dass wichtige Teile eines Systems doppelt vorhanden sind. So kann
beim Ausfall eines dieser Teile das andere die Arbeit übernehmen. Dies schützt vor Systemausfällen. Der Server, auf dem das System läuft, wird überwiegend mit redundanten
Bauteilen ausgestattet sein. Im Detail sind das unter anderem doppelt vorhandene Netzteile, Lüfter etc.
Des Weiteren sollte darauf geachtet werden, ein Rechnersystem zu verwenden, welches
bei Einsatz mehrerer Prozessoren einen evt. ausgefallenen Prozessor durch Redundanz
ersetzen kann.
5.3
Methoden zur Umsetzung
Um einen Überblick über das komplette zu entwickelnde System zu erhalten, wurde zu
Anfang in Zusammenarbeit mit einigen Mitarbeitern der Abteilung Sendeabwicklung des
ZDF ein kurzes Pflichten-/Lastenheft erstellt, anhand dessen die einzelnen Elemente
gestaltet und entwickelt wurden. Eine Kopie dieses Pflichtenhefts befindet sich in Anhang IIIB zu dieser Arbeit.
Zur Entwicklung der Software kamen unterschiedliche Werkzeuge zum Einsatz. Die
Entwicklung der C++ Software wurde in Microsoft Visual Studio .NET 2003 vorgenommen. Die Festlegung auf diese Entwicklungsumgebung war nicht zu letzt vorgeschrieben durch die Auswahl der DVB-Karte der Firma Technotrend, da das hierfür
5.3 Methoden zur Umsetzung
41
verfügbare Software-Development-Kit auf MS Visual C++ basiert. Unabhängig davon
hat sich diese Entwicklungsumgebung als außerordentlich angenehm und fähig herausgestellt.
Die Entwicklung des Web-Frontends geschah in PHP bzw. Java für das Applet zur
Transportstrom-Analyse. Für beide Sprachen wird die frei verfügbare Entwicklungsumgebung Eclipse30 verwendet. Eclipse wurde ursprünglich entwickelt zur komfortablen
Erstellung von Java-Software. Durch ein gutes Plugin-System existieren mittlerweile allerdings für viele Programmiersprachen entsprechende Erweiterungen. Für die Sprache
PHP existiert das Plugin PHPEclipse31, welches in seinem Funktionsumfang auch kommerzielle PHP-IDEs32 aus dem Rennen wirft.
Eclipse – http://www.eclipse.org
PHPEclipse – http://www.phpeclipse.org
32 IDE – Integrated Development Environment
30
31
42
6.1 TS-Buffer
6
43
Umsetzung des Konzepts
Zur Umsetzung des zuvor erstellten Konzepts erfolgte die Realisierung jedes SoftwareModuls Stück für Stück. Da einige dieser Module aufeinander aufbauen, wurde die zeitliche Reihenfolge bereits durch deren Architektur festgelegt.
Zur Konfiguration wird eine zentrale Konfigurationsdatei verwendet, auf die sämtliche
Softwaremodule Zugriff haben und ihre benötigten Einstellungen entsprechend auslesen.
Externe Elemente
Sämtliche Aktionen, welche die DVB-Karte betreffen, werden über das Software Development Kit der Firma Technotrend erledigt. Dies betrifft das Modul TS-Recorder, welches anhand dieser Software-Schnittstelle das Initialisieren, Tunen, Auslesen von TSDaten u. Auslesen von SI-/PSI-Daten in binärer Form realisiert.
Zur Arbeit mit SI-/PSI-Daten wurde eine Klasse benutzt, die bereits von früheren Diplomanden des ZDF [BOLDT] entwickelt worden ist. Da nach den Standards [ETSI
300468] und [ISO 13818-1] sehr viele verschiedenartige Sections und noch mehr unterschiedliche Arten von Descriptoren existieren, wurde entschieden, diese bereits existierende Software zu verwenden. In ihrer Ursprünglichen Form deckte diese Klasse die
meisten in [ETSI 300468] definierten Arten von Tables, Sections und Descriptoren ab.
Die restlichen in diesem Standard befindlichen, sowie alle Tables, Sections und Descriptoren, welche zusätzlich in [ISO 13818-1] definiert sind, wurden im Rahmen dieser Diplomarbeit hinzuprogrammiert.
Zusätzlich wird zur Extraktion von Video-Material externe Software eingesetzt. Zum
einen für das so genannte „Frameserving“, zum anderen wird zum Umwandeln von Video-Signalen in unterschiedliche Formate beliebige Encoder-Software sowie Codecs verwendet.
6.1
TS-Buffer
TS-Buffer repräsentiert die Verwaltungsklasse des Ringpuffers. Sie muss die Speicherung
und das Auslesen der Daten aus dem Ringpuffer übernehmen. Hierbei soll sie für den
Benutzer transparent arbeiten, das heißt der Benutzer soll sich weder darum kümmern
44
6 Umsetzung des Konzepts
müssen, bei erreichen der Speichergrenze alte Elemente zu entfernen noch darum, die
Dateien des Puffers in Segmente aufzuteilen.
Abbildung 13 zeigt einige Grundfunktionen des Ringpuffers als Usecase Diagramm.
Abbildung 13: Beispiel-Usecase für TS-Buffer
Die Namensgebung der Dateien des Ringpuffers folgt immer demselben Schema. Sie
besitzen einen festlegbaren Präfix, gefolgt
von
der
Start-Zeit
im
Format
YYYYMMDDHHMMSS gefolgt von der
Endzeit im selben Format. Schematisch
Abbildung 12: Inhalt des Ringpuffer-Verzeichnisses
lässt sich ein Dateiname des Ringpuffers
6.1 TS-Buffer
45
wie in Abbildung 14 darstellen. Anhand der Zeitangaben in den Dateinamen wird auch
die grobe Schnell-Navigation innerhalb des Puffers bewerkstelligt.
Abbildung 14: Namensgebung von Ringpuffer-Dateien
Um den Ringpuffer verwalten zu können, müssen zuerst einige Einstellungen vorgenommen werden. Hierzu dient die Struktur sTSBufferSettings. Sie enthält Angaben
zu den Elementen der Dateinamen und dem Verzeichnis, in dem die Ringpuffer-Dateien
gespeichert werden sollen, sowie Informationen über die Gesamtgröße des Ringpuffers
und die Größe einer Datei.
Abbildung 16 zeigt das Klassendiagramm des Ringpuffers. Bei Instantiierung eines Objekts dieser Klasse können mit der Funktion StartIndexingProcess() und
StartCleanUpProcess() zwei Threads33 gestartet werden, die sich um die „Pflege“
des Ringpuffers kümmern.
IndexBufferDirectory() übernimmt die Aktualisierung der im Puffer befindlichen
Daten. Dafür wird in einem einstellbaren Zeitintervall eine Liste aller Dateien, die sich im
Puffer-Verzeichnis befinden erstellt und im Objekt abgelegt. Anhand dieser Liste wird
die Navigation innerhalb des Puffers realisiert.
StartCleanUpProcess() räumt – wie der Name der Methode bereits verrät – den
Ringpuffer auf. In einem einstellbaren Zeitintervall wird die Gesamtgröße der im Puffer
befindlichen Dateien summiert. Wenn dieser Wert über die anhand von sTSBuffer-
33
Gleichzeitige, unabhängige Ausführung zweier “Handlungsstränge” innerhalb eines Programms [KRUEGER]
46
Settings eingestellte Gesamtgröße hinausgeht, wird sukzessive die älteste Datei des
Puffers gelöscht, bis die Gesamtgröße wieder unterhalb der Maximalgröße liegt.
Abbildung 15: Aktivitätendagramme Lesen/Schreiben in Ringpuffer
Die Methode zum Schreiben wurde aus zwei Gründen bewusst schlank gehalten. Zum
einen sollten Transportstromdaten, die aus 188 Byte langen Paketen bestehen, auch nur
an den Paketgrenzen auseinander geschnitten werden. Deshalb werden Schreibvorgänge
immer komplett in die jeweilige Datei vorgenommen. Ein Dateiwechsel wird immer vor
dem gesamten Block vorgenommen. Dadurch bekommen die geschriebenen Dateien
zwar nicht exakt die festgelegte Größe, diese ist jedoch unwichtig, da alle Operationen
6.1 TS-Buffer
47
des Puffers auf den tatsächlichen Dateigrößen basieren und nicht auf den fest eingestellten.
Der zweite Grund für den einfachen Aufbau der Schreibroutine ist Performance. Da die
DVB-Daten in einem Strom ankommen, muss jedes Paket exakt zur Ankunftszeit geschrieben werden können. Ist dies nicht der Fall, wird es verworfen und es kommt zu
Datenverlust.
Abbildung 16: Klassendiagramm TS-Buffer
48
6.2
TS-Recorder
Der Transportstrom-Recorder nimmt rund um die Uhr den DVB-Transportstrom auf.
Seine Aufgabe ist das Lesen der Daten von der DVB-Karte und das Schreiben in den
Ringpuffer.
Außerdem ist der TS-Recorder dafür zuständig, gleichzeitig die wichtigen SI-Daten für
den Aufbau eines EPG auszulesen (vgl. Abschnitt 5.2.3).
Dafür hat das Modul zwei nebenläufige Threads. Jeweils einer davon ist für das Aufnehmen des Transportstroms zuständig, der andere extrahiert die benötigten EPG-Daten.
Beim Auslesen der EPG-Daten werden, wie in Abschnitt 5.2.3 beschrieben Sections der
Tabellen PAT, PMT, EIT und SDT ausgelesen, entsprechend miteinander in Verbindung
gebracht und für die spätere Verwendung gespeichert.
Die Speicherung erfolgt im XML-Format. Um den Aufwand, diese Daten zu interpretieren, möglichst gering zu halten, wird pro Tag ein XML-Dokument verwendet, was es
ermöglicht, die Daten für jeden Tag separat zu parsen34, um den Electronic Program
Guide aufzubauen.
Für jeden Tag werden die empfangenen Ströme, Programme und die dazugehörigen Sendungen im XML-Dokument gespeichert. Bei einer Änderung der Belegung des
Transponders – wie es vor kurzem durch den Wegfall von Eurosport und Euronews
beim ZDF der Fall war – werden die richtigen Daten dann spätestens zum darauf folgenden Tageswechsel wieder korrekt angezeigt.
Abbildung 17 zeigt hierfür eine Beispieldatei im XML-Format.
34
Parsen – Analysieren und Überführen von Daten einer Festgelegten Struktur (meistens Textformat) in
eine andere, meistens native Datenstruktur
6.2 TS-Recorder
Abbildung 17: Beispiel EPG-XML
49
50
Technotrend SDK35
Um auf die DVB-Karte zugreifen zu können, ist es nötig, eine Software-Schnittstelle
zwischen Programmiersprache und Treiber der DVB-Karte zu besitzen.
Microsoft verabschiedete mit BDA36 eine Standardisierte Schnittstelle für digitale TVKarten. Die BDA-Schnittstelle ist eine Treiberarchitektur für die Verwendung von TVund Radiokarten unter Windows [MSBDA]. Software, welche die Microsoft BDASchnittstelle benutzt, bietet hohe Kompatibilität, da dadurch alle Empfangskarten, für die
Treiber in BDA-Architektur verfügbar sind, unterstützt werden. Die Firma Technotrend
bietet BDA-Treiber für ihre Produkte zwar ebenfalls an, allerdings beschränkt sich die
Palette der Möglichkeiten aufgrund der BDA-Architektur nur auf Grundfunktionen. Da
für diese Arbeit auch speziellere Funktionen von Nöten sind, wurde entschieden, auf
Kosten der Kompatibilität die proprietären Treiber und Software Development Kits des
Herstellers zu verwenden. Dieses so genannte SDK ist nicht im Lieferumfang einer solchen DVB-Karte enthalten, Technotrend stellt es allerdings auf persönliche Anfrage und
Unterzeichnung einer Nutzungsvereinbarung kostenlos jedem Interessierten zur Verfügung.
Um über die DVB-Karte auf die Daten des DVB-Signals zugreifen zu können, müssen
zuvor einige Einstellungen vorgenommen werden. Als Grundlage hierfür dienen die
Klassen CDVBBoardControl und CDVBFrontend, welche mit dem SoftwareDevelopment-Kit von Technotrend ausgeliefert werden.
Aufnehmen des Transportstroms
Um die Aufnahme der DVB-Signale zu starten, muss zuerst die Schnittstelle des SDK
sowie die DVB-Karte initialisiert werden. Dies geschieht durch Methoden der Klassen
CDVBCommon, CDVBBoardControl und CDVBFrontend.
35
36
SDK – Software Development Kit
BDA – Broadcast Driver Architecture
6.2 TS-Recorder
51
Abbildung 18: Klassendiagramm Technotrend SDK (Auszug)
Um einen Sender zu empfangen, stellt die Klasse CDVBFrontend die Methode SetChannel() zur Verfügung. Dieser wird eine Struktur übergeben, welche alle erforderli-
chen Eckdaten enthält, um den Tuner auf den entsprechenden Transponder einzustellen.
Um den Transponder des ZDF zu empfangen, müssen beispielsweise folgende Daten
angegeben werden (Stand 02.02.2006):
Frequenz:
11,95350 GHz
Symbolrate:
27500
Polarisation:
Horizontal
Der eigentliche Aufnahme-Vorgang ist nicht aufwändig. Da sich die Ringpuffer-Klasse
bereits eigenständig um die Organisation innerhalb des Ringpuffers kümmert, müssen
ankommende Pakete nur noch an die Ringpuffer-Klasse weitergereicht werden. Hierbei
ist eine geeignete Blockgröße zu wählen. Ein Transportstrom-Paket besitzt eine Länge
von 188 Bytes. Da das Schreiben von 188 Byte großen Blöcken auf die Festplatten unnö-
52
tige Geschwindigkeitseinbußen hervorrufen würde, muss eine geeignete Blockgröße gewählt werden.
Damit die Transportstrom-Pakete an den Übergängen der einzelnen Dateien im Ringpuffer nicht in der Mitte geteilt werden, bietet sich die Wahl eines Vielfachen von 188 an.
Hier wurde eine Blockgröße von 1880000 ≈ 1,8MB gewählt.
Abbildung 19: Klassendiagramm TS-Recorder
53
6.3 CTSPacket
6.3
CTSPacket
Die Klasse CTSPacket ist eine
Datenstruktur, welche ein Paket des
DVB-Transportstroms repräsentiert.
Solche Pakete sind stets 188 Bytes
lang
und
besitzen
bestimmte
Elemente, auf die durch diese Klasse
komfortabel
zugegriffen
werden
kann. Unter anderem lässt sich durch
die
Funktion
GetPayloadUnitStartIndicat
or() erkennen, ob eine SI-/PSI-
Table in diesem Paket beginnt oder
Abbildung 20: Klassendiagramm TS-Packet
nicht. Da die Performance wie bereits bemerkt, bei Datenmengen im Giga- und TeraByte Bereich sehr wichtig ist, werden unnötige Kopiervorgänge im Speicher vermieden.
Deshalb existiert beispielsweise eine Funktion SetDataCpy() und SetDataPtr().
Diese Methoden weisen beide dem Objekt den Bitstrom eines Transportstrom-Paketes
zu. Die eine Methode kopiert die übergebenen Daten zuerst im Speicher wobei die
andere lediglich einen Pointer37 anlegt. Die Methode, die die Daten zuerst kopiert und
dann im Objekt speichert ist für einen Programmierer sicherer. In diesem Fall kümmert
sich dann nämlich die Klasse selbst darum, nicht mehr benötigten Speicher freizugeben.
Die Methode, die einen Pointer als Argument annimmt, verlangt eine größere Sorgfalt
des Programmierers. Dabei ist er zum Einen selbst für das Freigeben von Speicher
verantwortlich, zum Anderen darf der Speicher noch nicht freigegeben werden, solange
das entsprechende Objekt von CTSPacket noch existiert und arbeitet. Es ist dem
Programmierer bzw. dessen Sorgfalt und dem Anwendungsfall überlassen, welche dieser
beiden Methoden benutzt werden soll.
6.4
TSFilterBank
Die Klasse TSFilterBank und deren zugehörigen Klassen sind für die Weiterverarbeitung der DVB-Daten ein zentrales Element.
37
Pointer – Programmiertechnik: Ein Zeiger ist eine Variable, in der sich die Adresse eines Datenobjekts
bzw. einer Funktion befindet. [LOUIS]
54
Sie dienen dazu, Elemente aus dem Datenstrom herauszulösen.
Abbildung 21: Klassendiagramm TS-Filter
Der Filtermechanismus ist aufgeteilt in die FilterBank-Klasse CTSFilterBank und die
Filter-Klassen.
6.4 TSFilterBank
55
CTSFilterBank dient als Zentrale, über die sämtliche Funktionen gesteuert und an die
Filter weitergegeben werden.
Die Filter-Klassen sind als ein Designpattern des Typs „Chain of Responsibility“ organisiert. Ein Designpattern (deutsch „Entwurfsmuster“) beschreibt eine generische Lösung
für ein in der Praxis immer wieder auftretendes Problem. Somit ist ein Design-Pattern
eine Vorlage zur Lösung bestimmter Probleme. Unterschieden wird zwischen drei Anwendungsgebieten:
-
Creational Patterns (Erzeugungsmuster)
-
Structural Patterns (Strukturmuster)
-
Behavioural Patterns (Verhaltensmuster)
Das hier zum Einsatz kommende Muster „Chain of Responsibility“ gehört zur Gruppe
der Behavioural Patterns. Eine Chain of Responsibility vermeidet die Kopplung zwischen
Sender und Empfänger bzw. dem Bearbeiter. Diese Empfänger bilden eine Kette, in der
eine Anfrage so lange an den jeweiligen Nachfolger durchgereicht wird, bis eines der
Kettenobjekte die Anfrage bearbeiten kann oder die Kette zu Ende ist. [GAMMA]
Eine Besonderheit ist hier die Klasse CTSSectionFilter, die eine zusätzliche abstrakte Klasse in der Vererbungshierarchie darstellt. Sie wurde eingeführt, da das Extrahieren
von Sections direkt aus dem Transportstrom eine aufwändige Prozedur ist. Da dies jedoch eine ebenso häufige Aufgabe wie die Extrahierung von einzelnen PIDs darstellt,
wurde hierfür bereits eine Abstrakte Klasse gebildet, die für diese Aufgabe verwendet
werden kann.
Die Extraktion von Sections aus dem Transportstrom ist deshalb so aufwändig, weil innerhalb einer PID mehrere verschiedenartige Sections mit ihren unterschiedlichen
table_ids auftreten können.
Ein gutes Beispiel hierfür ist die SDT (Service Description Table) und BAT (Bouquet
Association Table). Sie werden beide in Transportstrompaketen mit der PID 0x11 transportiert, besitzen aber unterschiedliche table_ids (Siehe [ETSI 300468]). Der DVBStandard beschreibt auch das „Mapping“ von Sections in Transportstrompakete.
Interpretiert wird immer Paket für Paket. Ein Paket hat eine Länge von 188 Bytes, was es
nötig macht, Sections, die bis zu 4096 Bytes groß sein können, auf mehrere Transportstrompakete aufzuteilen. Da Sections bereits in binärer Form vorliegen, werden diese
direkt in die Transportstrom-Pakete „gemapped“. Das heißt sie werden vorher nicht, wie
bei A/V-Daten der Fall, in PES-Pakete aufgeteilt.
56
Abbildung 22: Einbettung von Sections in TS-Pakete
Abbildung 22 veranschaulicht das Mapping von Section-Daten in Transportstrompakete.
Laut [ISO 13818-1] kann eine Section sowohl zu Anfang eines TS-Pakets beginnen als
auch irgendwo in der Mitte. Um diesen Beginn zu kennzeichnen, wird der pointer_fieldMechanismus verwendet. Um die Existenz eines Section Beginns innerhalb des TSPakets zu signalisieren, bekommt das Feld payload_unit_start_indicator des TS-PaketHeaders den Wert 1 zugewiesen. Wenn innerhalb eines Paketes kein Section-Beginn vorliegt, dann besitzt payload_unit_start_indicator den Wert 0.
Durch den Wert 1 wird signalisiert, dass die ersten 8 Bits des Payloads aus dem so genannten pointer_field bestehen. Dieses Feld gibt den Abstand zwischen sich selbst und
dem Beginn der ersten Section in diesem Paket an, weist also exakt auf die table_id. Ist der
Wert von pointer_field also 0, so beginnt die erste Section direkt im auf pointer_field folgenden Byte.
Darauf folgende Sections innerhalb desselben Transportstrom-Pakets beginnen exakt
hinter dem letzten Byte der vorhergehenden Section. Das Ende einer Vorhergehenden
Section wird durch den Wert section_length im Section-Header festgelegt.
Nachdem das pointer_field und damit der Beginn der ersten Section identifiziert ist, wird
die Länge der Section ausgelesen, welche in den bits 12 bis 24 nach dem Startpunkt der
Section gespeichert ist.
6.4 TSFilterBank
57
Abbildung 23: Aktivitätendiagramm Section-Filter
Nachdem das pointer_field identifiziert ist (1), wird die Länge der Section ausgelesen, welche in den Feldern 12-24 bit nach dem Start der Section steht. Da Sections aufgrund ihrer
Größe meistens auf mehrere Transportstrom-Pakete aufgeteilt werden, wird nun der
Payload jedes Transportstrom-Paketes angehängt, bis eine Länge von section_length erreicht ist (2).
Tritt dieser Fall ein, so ist die Section komplett ausgelesen und kann weiterverarbeitet
werden (3).
Verbleiben jetzt keine restlichen Bytes mehr im aktuellen Transportstrom-Paket, ist die
Aktion für dieses Paket somit beendet.
Sind allerdings doch noch Daten übrig (4), existieren zwei Möglichkeiten. Die erste Möglichkeit ist das Vorhandensein so genannter „Stuffing-Bytes“. Diese werden verwendet,
58
um den Rest des Paketes mit Null-Daten38 aufzufüllen. Stuffing-Bytes werden identifiziert
durch den Wert 0xFF. Tritt also direkt nach dem Ende einer Section ein Wert von 0xFF
auf, so bestehen die restlichen Daten des Transportstrom-Pakets ebenso aus StuffingBytes, welche verworfen werden können.
Sind die verbleibenden Bytes keine Stuffing-Bytes (also ungleich 0xFF), so fängt hier
nahtlos die nächste Section mit ihrer table_id an. Hierfür wird erneut ein leerer Speicherbereich geöffnet und die Daten ab dieser Stelle wieder so lange gesammelt (2), bis die
Section ebenfalls komplett ist.
Wurde eine Section komplett eingelesen, wird die Methode OnSectionComplete()
der abgeleiteten Klasse aufgerufen, in der der Programmierer festlegen muss, wie mit den
Daten verfahren wird.
6.5
TS2PS-Worker
TS2PS-Worker dient der Extrahierung von anschaubarem A/V-Material aus dem Transportstrom. Da Sichergestellt
werden muss, dass nicht
mehrere solcher Extrahierungsvorgänge parallel ablaufen, musste hierfür ein
Warteschlangensystem entworfen werden. Dieses sieht
so aus, dass wenn ein Encode-Job vom Frontend aus Abbildung 24: TS2PS-Worker
abgesetzt wird, eine Job-Datei im XML-Format in einem festgelegten Verzeichnis abgelegt wird. TS2PS-Worker läuft ununterbrochen im Hintergrund. Dabei wird im Abstand
von 10 Sekunden kontinuierlich dieses Verzeichnis ausgelesen. Eine solche Job-Datei
wird erkannt anhand einer bestimmten Struktur des Dateinamens.
38
Null-Daten – Daten, welche keine Bedeutung besitzen und zur zum Füllen leerer Räume gedacht sind
6.5 TS2PS-Worker
59
Abbildung 25: TS2PS-Worker Jobfiles
Eine solche Job-Datei enthält wie in Abbildung 25 erkennbar unter anderem die Startund Endzeiten sowie die PIDs, welche es zu extrahieren gilt. Außerdem wird durch das
Jobfile die Email-Adresse des Auftraggebers gespeichert, um nach erfolgreicher Bearbeitung des Auftrags eine automatisierte Email zu versenden, welche einen Link zum extrahierten Videomaterial enthält.
Das Tag <format> gibt das Ausgabeformat an. Dieses muss sowohl auf Senderseite
(Web-Frontend) des Auftrags als auch auf Empfängerseite (TS2PS-Worker) bekannt sein.
Da die Abwicklung verschiedener Methoden bzw. die Ansteuerung unterschiedlicher
Encoder stark voneinander abweichen kann, wurde von der Möglichkeit, dynamisch verschiedene Ausgabeformate zu definieren (z.B. durch eine Konfigurationsdatei) abgesehen. Zum jetzigen Stand der Software muss – sollte ein neues Format benötigt werden –
die Ansteuerung des Encoders im Programmcode hinzuprogrammiert werden.
Grundsätzlich muss bei der Extrahierung zwischen zwei Möglichkeiten unterschieden
werden. Dem Re-Multiplexing und dem Transcoding. Zur reinen Sendekontrolle ist das
Re-Multiplexing essentiell wichtig, da die AV-Signale unverändert zur Übertragung wiedergegeben werden können. Bei diesem Vorgang entstehen enorm große Dateien. Für die
reine Video-Extraktion ohne Kontrolle des Materials bietet sich diese Möglichkeit also
nicht an.
Für diese Aufgabe existiert die Möglichkeit des Transcodings. Transcoding bedeutet,
Quell-Material durch eine festzulegende Encoder-Software erneut zu komprimieren und
somit z. B. in das speichersparende MPEG-4 Format zu überführen
60
6.5.1 Re-Multiplexing
Durch Re-Multiplexing wird sichergestellt, dass Video-Ströme unverändert zum OriginalMaterial extrahiert werden.
Dies ist wichtig, um z.B. bei Verwendung variabler Bitrate (VBR39) Bitratenschwankungen etc. analysieren zu können. Bei diesem Vorgang werden die nötigen Transportstrompakete (Audio und Video) (vgl. Unterkapitel 3.2) aus dem Transportstrom gelöst und
danach zu einem MPEG-2 Program Stream zusammengesetzt. Da an den Nutzdaten
selbst keine Veränderung vorgenommen wird, resultiert hieraus auch keine Veränderung
zum Originalmaterial.
Für die softwaretechnische Realisierung werden hierfür die zuvor erläuterten SoftwareElemente TS-Buffer und TS-FilterBank verwendet.
Um durch die Hinzunahme des Standards für MPEG-2 Video den Rahmen dieser Diplomarbeit nicht zu sprengen, wurde zusätzlich eine eigenständige Freeware-Software
Namens PVAStrumento40, verwendet, um MPEG-2 konforme Audio-/Videoströme zu
remultiplexen. PVAStrumento wird weiter unten in diesem Abschnitt erläutert.
Im Folgenden ein exemplarischer Auszug aus dem Quellcode zu TS2PS-Worker zur Verdeutlichung der Verwendung der Module TS-Buffer und TSFilterbank:
//Instantiieren der TS-Buffer Verwaltung
CTSBuffer ts_buffer;
ts_buffer.Init(s);
ts_buffer.IndexBufferDirectory(); //Puffer-Verzeichnis einmal in das
Objekt einlesen
ts_buffer.InitInputStream()); //Inputstream des Buffers initialisieren
//Zur Start-Zeit der Extrahierung spulen
ts_buffer.IFGotoTime(&ltime_CutStart);
//Outputstream initialisieren
std::ofstream out;
out.open(outputFile, ios_base::out | ios_base::trunc | ios_base::binary);
if (!out.is_open()) { //Fehlerbehandlung
//Fehler. Also beenden
39
40
VBR – Variable Bit Rate
PVAStrumento – http://www.offeryn.com/
6.5 TS2PS-Worker
61
}
//Filterbank instantiieren
CTSFilterBank TSfilterbank;
/* PacketBuffer: Kleine Klasse, die die 188-Byte-Pakete bis zu einer
festgelegten Größe speichert und dann erst in den Outputstream
schreibt, um Festplattenaktivität zu vermindern. */
CMyTSPacketBuffer write_buffer
write_buffer.SetOFStream(&out);
//Jetzt für jede PID einen Filter setzen
CMyTSPacketFilter *filters = new CMyTSPacketFilter[pids.size()];
for (unsigned int i=0; i<pids.size(); i++) {
filters[i].SetPID(pids[i]);
filters[i].SetPacketBuffer(&write_buffer);
//Filter in die Chain-of-Responsibility einfügen
TSfilterbank.AddFilter(&filters[i]);
}
size_t length = 188;
char *buf = new char[length];
unsigned __int64 geschrieben = 0;
unsigned __int64 gelesen = 0;
while (ts_buffer.readIs(buf)) {
//Daten in die Filter-Kette reichen
if (TSfilterbank.PushData((unsigned char*)buf)) {
geschrieben += length;
}
//Bei Bedarf am Ende schneiden
if (bCutEnd) {
if (ts_buffer.GetAktIFTime() >= ltime_CutEnd) {
//Wenn die End-Zeit erreicht ist, die Schleife verlassen,
um die Datei zu schließen
break;
}
}
}
//Den Schreib-Puffer flushen, um alles in die Datei zu schreiben
write_buffer.flush_buffer();
out.close(); //Erst jetzt den Output-Stream schließen
Durch diesen Programmcode werden alle im Transportstrom vorkommenden Pakete,
welche die relevanten PIDs besitzen, aus dem Strom gelöst und in einer temporären Datei aneinandergefügt. Die resultierende Datei besteht nun nur noch aus Transportstrompaketen mit zwei unterschiedlichen PIDs, nämlich Paketen mit der PID des gewählten
Video-Stromes und der PID des gewählten Audio-Stromes. Die Daten, die nun vorliegen, folgen in dieser Form keinem gängigen Standard, da hier lediglich Transportstrom-
62
pakete aneinandergereiht wurden, ohne entsprechende PMT oder PAT-Tables mit in den
Strom zu integrieren. Für normale Decoder beziehungsweise Player-Software wären diese
Daten nicht zu lesen.
Nun werden diese Daten der Software PVAStrumento übergeben.
PVAStrumento wurde ursprünglich
entwickelt, um von einer DVB-Karte
im
PVA-Format41
Videoprogramme
aufgenommene
in
von
einem
MPEG-2 Player lesbare MPEG-2
Program
Streams
umzuwandeln. Abbildung 26: PVAStrumento
Hierfür besitzt PVAStrumento zusätzlich einige Funktionalitäten, um Fehler im Strom zu
korrigieren und kümmert sich außerdem gleichzeitig darum, Audio und Video lippensynchron zu multiplexen.
Nach der Ausführung von PVAStrumento wird die entstandene Datei in einem Auslieferungsverzeichnis abgelegt, wo sie dann weiterverarbeitet bzw. per Netzwerkfreigabe oder
Webserver abgeholt werden kann.
Leider konnte keine Software gefunden werden, welche die beiden zuvor beschriebenen
Arbeitsschritte (1. PIDs extrahieren,
2. PVAStrumento) zuverlässig in
einem Schritt erledigt. Es existiert
zwar eine Software Namens ProjectX, welche ebenfalls unter Open
Source Lizenz vertrieben wird. Diese
wird normalerweise für solche Aufgaben verwendet, sie scheint jedoch
mit den geteilten TransportstromdaAbbildung 27: Project-X
teien aus dem Ringpuffer nicht zu-
recht zu kommen. In Versuchen mit Project-X waren die Audio- und Videospur stets
unsynchron42.
PVA – Packet Video Audio – Proprietär entwickeltes Format von Technotrend, optimiert für die Aufnahme von AV-Material über DVB-Empfänger
42 Synchron – Abgespielter Ton passt zeitlich genau zum gezeigten Video
41
6.5 TS2PS-Worker
63
6.5.2 Transcoding (Frameserver)
Transcoding ist die Methode der Wahl zur Extraktion von Video-Programmen, welche
nicht auf Sendefehler analysiert werden sollen, sondern nur des Videos wegen extrahiert
werden. Beim Transcoding werden die Pakete nicht wie beim Re-Multiplexing entsprechend neu angeordnet, sondern es findet ein komplett neuer Komprimierungsprozess
statt. Dadurch können die von TS-Recorder aufgenommenen Inhalte in praktisch jedes
beliebige Video-Format konvertiert werden. Dazu gehören unter anderem die aktuell
populären MPEG-4 Codecs43 wie DivX oder XVid, oder auch Formate für das InternetStreaming wie Windows Media (WMV).
Da keine der bekannten Encoder-Software die Möglichkeit besitzt, einen Transportstrom
als Quelle anzugeben und nur die Ströme mit den gewünschten PID zu encoden, muss
hier eine Brücke geschaffen werden. Theoretisch wäre es natürlich möglich, zuerst die
gewünschten PIDs wie in Abschnitt 6.5.1 erläutert zu demultiplexen und danach die dadurch entstandenen Ströme durch eine Encoder-Software zu transcodieren. Da diese
Daten allerdings auf die Festplatten zwischengespeichert werden müssten, würde dies
wiederum zu einem Zeitverlust führen.
Zur Zeitsparenden Realisierung dieser Brücke kommen deshalb so genannte Frameserver
zum Einsatz. Ein Frameserver ist eine Software, die Videodaten in Echtzeit aus einer
Quelle auslesen, bei Bedarf bearbeiten und direkt an ein empfangendes Programm weiterleiten kann. Dadurch entsteht kein Overhead44 durch das Zwischenspeichern von Daten.
Codec – Akronym: Coder Decoder – Verfahren / Programm zur Codierung und Decodierung von
Daten oder Signalen
44 Overhead – Zusätzliche, nicht zu verarbeitende Daten, welche nur zur Verwaltung benötigt werden
43
64
Abbildung 28: Funktionsweise eines Frameservers
Die Software des Frameservers verhält sich dabei transparent45 und arbeitet im Hintergrund. Grundlage hierfür ist die Frameserverdatei, welche Anweisungen zum Importieren
von Quell-Material und dessen Bearbeitung enthält (Siehe Abbildung 28).
Wird diese Datei von einem Programm geöffnet, welches Videodaten erwartet, verhält sie
sich für das öffnende Programm wie eine unkomprimierte AVI Videodatei. Dieses Format ist für alle bekannten Video-Programme lesbar.
Beim Öffnen der Frameserverdatei beginnt im Hintergrund die Software zu arbeiten, lädt
die benötigten Daten aus der Quelldatei bzw. den Quelldateien, bearbeitet diese entsprechend den Anweisungen aus der Frameserverdatei und gibt die resultierenden Videodaten dann direkt an das öffnende Programm weiter.
Ein sehr populärer und mächtiger Frameserver ist AVISynth46. Diese Software besitzt
zahlreiche Funktionen, mit denen ein non-lineares Schneiden von Videomaterial kom-
Transparente Software – Software, deren Existenz für den Benutzer weder direkt erkennbar noch relevant ist
46 AVISynth – http://www.avisynth.org/
45
65
6.5 TS2PS-Worker
plett ohne grafische Oberfläche, sondern durch reine Script-Programmierung ermöglicht
wird.
AVISynth ist vollständig in Open-Source veröffentlicht, was es ermöglicht, eigene Plugins zu entwickeln, wenn diese benötigt werden.
Leider existiert derzeit kein Plugin, welches Transportströme direkt öffnen kann, um die
Video-/Audiospuren mit bestimmten PIDs als Video- bzw. Audioquelle zu verwenden.
Um, wie bereits in Abschnitt 6.5.1 bemerkt, den Rahmen der Diplomarbeit nicht zu
sprengen, wird hierfür eine zweite Frameserver-Software hinzugezogen.
Diese Software nennt sich DGIndex47 und ist ebenfalls als Open-Source erhältlich. Ihre
Hauptaufgabe besitzt sie im Demultiplexen
von
MPEG-
Strömen. Leider ist es unumgänglich, dass DGIndex den
Audio-Strom extrahieren und auf
Platte schreibt, bevor die Daten
weiterverarbeitet werden können.
Lediglich den Videostrom kann
Abbildung 29: DGIndex
sie in Form eines Frameservers
bereitstellen. Da das Speichern eines Audiostroms allerdings dennoch weniger Zeit benötigt als das komplette Remultiplexen des Datenstromes, wird diese Lösung vorerst so
angewandt.
Für den späteren Produktionsbetrieb ist deshalb die Entwicklung eines entsprechenden
Plugins für die AVISynth Software zu empfehlen, womit der Schritt über DGIndex
komplett entfällt.
Abbildung 30 veranschaulicht noch einmal die Zusammenarbeit von DGIndex und AVISynth.
47
DGIndex – http://neuron2.net/dgmpgdec/dgmpgdec.html
66
Abbildung 30: Logische Struktur beim "Frameserving"
6.6
Tables-Socket-Service
Tables-Socket-Service ist das zentrale Element zur Transportstromanalyse. Da die Bedienung der Software durch eine Client-Applikation erfolgen muss, ist es notwendig, ein
Softwaremodul zu entwickeln, welches den Transportstrom lokal auf dem Server analysiert und die Ergebnisse an den Client weitergibt.
6.6 Tables-Socket-Service
67
Aufgrund der Datenmengen des Transportstroms wäre eine Analyse am Client, das heißt
mit vorheriger Übertragung bzw. IP-Streaming48 eines Teils der gespeicherten Transportstromdaten, nicht empfehlenswert. Bei einer Datenrate von 38 Mbit pro Sekunde besitzt
eine Minute Transportstrommaterial bereits 285 MB an Daten. Bei einem heutigen
Netzwerk, welches rechnerisch 100 Mbit pro Sekunde übertragen kann, würde die Übertragung von nur einer Minute Transportstromdaten im Idealfall ca. 23 Sekunden dauern.
In der Praxis hat sich gezeigt, dass ein solches 100 Mbit Netzwerk einen durchschnittlichen Datendurchsatz von ca. 7-10 MB pro Sekunde erreicht, was einer tatsächlichen Datenrate von 56-80 Mbit pro Sekunde entspricht. Rechnet man diese Datenrate wiederum
mit den 285 MB für eine Minute Transportstromdaten zusammen, erhält man für die
reine Datenübertragung eine Dauer von ca. 29 bis 41 Sekunden.
Abgesehen von den Zeiten für die Datenübertragung existiert natürlich parallel dazu auch
anderer Netzwerkverkehr, der nicht zu dieser Software gehört und dessen Aktivitäten die
Übertragung nochmals ausbremsen würden. Gleichzeitig würde die Übertragung solcher
Datenmengen eine sehr hohe Belastung für das gesamte Netzwerk darstellen, da diese
Daten – je nach Position des Clients – unter Umständen durch das komplette Netzwerk
des ZDF-Komplexes geroutet49 werden müsste.
Aus diesem Grund wird festgelegt, die Analyse des Transportstroms auf dem Server stattfinden zu lassen, da dieser sowohl über die nötige Prozessorleistung als auch über ein
schnelles Festplattensystem durch RAID verfügt.
Um diese Funktionalität zur Verfügung zu stellen, wurde eine Serversoftware entwickelt,
welche mit dem Interpretations-Client per Socket50 kommuniziert.
Hierfür wurde ein Protokoll51 auf XML Basis entwickelt, welches die Datenübertragung
zum und vom Server ermöglicht. Ein Beispiel für eine Anfrage des Clients an den SocketServer findet sich in Abbildung 31.
Nachdem eine solche Anfrage durch das XML Protokoll empfangen wurde, beginnt die
Software, die gewünschten Informationen aus dem Transportstrom auszulesen.
Streaming – Technik zur Datenübertragung, bei der empfangene Daten direkt weiterverarbeitet werden
können
49 Routing – Durch-/Weiterleiten von Datenpaketen über eine geeignete Leitung
50 Socket – Bidirektionale Software-Schnittstelle zur Inter-Process- / Netzwerk-Kommunikation
51 Protokoll – Vereinbarung einer Datenstruktur, woran sich Sender und Empfänger halten, um eine gemeinsame „Sprache“ zu unterstützen
48
68
Um ein wahrheitsgetreues Bild des Transportstroms zu einem bestimmten Zeitpunkt zu
erhalten, ist es notwendig, die Transportstrom-Analyse Non-Linear zu gestalten. NonLinear bedeutet in diesem Zusammenhang, dass der Benutzer beliebig im Datenstrom
navigieren kann und somit jeden beliebigen Zeitpunkt erreichen kann.
Da DVB-Sections zyklisch ausgespielt werden, ist hierfür ein geeigneter Mechanismus
nötig, um den Zustand zu einem bestimmten Zeitpunkt abzubilden.
Dies wird erreicht durch die Speicherung der Section seit ihrem letzten Auftreten. Der
maximale Abstand zwischen der Ausstrahlung von Sections ist laut Standard 30000ms (=
30 Sekunden). Deshalb wird auf Anfrage für eine Bestimmte Uhrzeit im TransportstromPuffer zu einer Position, die 30 Sekunden vor dem gewünschten Zeitpunkt liegt, navigiert. Daraufhin wird der Datenstrom mit Hilfe der zuvor besprochenen Softwaremodule
TS-Buffer und TSFilterBank ausgelesen und jeweils die neuste Version der gewünschten
Section(s) zwischengespeichert.
Am Ende der 30 Sekunden angekommen, befindet sich der Zeiger exakt am gewünschten
Zeitpunkt und besitzt die Daten, die zu diesem Zeitpunkt aktuell waren (Siehe Abbildung
31).
6.6 Tables-Socket-Service
69
Abbildung 31: Non-lineare Transportstromanalyse
Die jeweils letzte im Stapelspeicher befindliche Section ist die aktuelle. Nachdem der
Endzeit-Punkt erreicht worden ist, beginnt die Rückgabe der Daten über dasselbe Socket,
worüber die Anfrage empfangen worden ist.
Hierfür werden die binären Daten, aus der die Section besteht, wiederum in lesbaren
XML Code überführt. Dieser XML Code entspricht einer DTD, die es der empfangenden Software ermöglicht, die Daten zu interpretieren und daraufhin anzuzeigen.
70
Abbildung 32: Beispiel XML-Antwort TS-Interpretation
6.7 TS-Analyzer-Applet
71
Im Antwort XML existiert für jedes <get>-Element aus der Anfrage (siehe Abbildung
31) je ein korrespondierendes <response>-Element. Über das Attribut id bekommen die
beiden Tags ihren Zusammenhang.
Innerhalb der Antwort ist das Tag <rows> von großer Bedeutung. Dieses beschreibt die
Inhalte einer Section. Zusätzlich existieren Tags mit dem Namen <descriptor>, welche
eine textuelle Beschreibung der in der Section vorhandenen Descriptoren enthalten.
Loops werden durch ein gleichnamiges Tag <loop> repräsentiert, worin wiederum
<rows> und <descriptor> enthalten sein können.
Eine DTD52 für diese XML Nachrichten befindet sich im Anhang zu dieser Arbeit.
6.7
TS-Analyzer-Applet
Das TS-Analyzer-Applet stellt die Benutzeroberfläche bzw. die Client-Applikation zu
Tables-Socket-Service dar.
Um die Analyse des Transportstroms einigermaßen komfortabel gestalten zu können, ist
es nötig, eine flexible Oberfläche zu generieren. Da die Möglichkeiten bei der für Webseiten verwendeten Auszeichnungssprache HTML53 sehr begrenzt sind, musste eine geeignete andere Lösung gefunden werden.
Hierfür standen zwei Möglichkeiten zur Auswahl. Die erste Möglichkeit war, eine FlashAnwendung zu entwerfen und die zweite Möglichkeit bestand in der Entwicklung eines
Java-Applets54.
Grundsätzlich wäre Flash angenehm gewesen, da in Flash erstellte Dateien im swfFormat im Gegensatz zu Java-Applets um einiges schlanker sind. Über programmiertechnische Möglichkeiten würde Flash ebenfalls verfügen dank der mittlerweile sehr
mächtigen Script-Sprache Actionscript, welche in Flash integriert ist. Leider fehlen Flash
entsprechende GUI55-Elemente, welche für eine Anwendung wie diese benötigt werden.
Zwar stellt Flash von Haus aus einige wenige GUI-Elemente zur Verfügung, die allerdings weniger für die Programmierung von Grafischen Oberflächen vorgesehen sind,
sondern mehr für die Ersetzung der Formular-Elemente von HTML. So sind lediglich
DTD – Document Type Definition – Inhaltsmodell für ein XML-Dokument. Definiert die erlaubten
und nicht erlaubten Elemente u. Attribute für ein Dokument / eine Klasse von Dokumenten bzw. deren
Reihenfolge [VONHOEGEN]
53 HTML – Hypertext Markup Language
54 Applet – Java-Applikation, welche im Kontext eines Internetbrowsers ausgeführt wird
55 GUI – Graphical User Interface
52
72
Buttons, Checkboxen, Textfelder etc. bereits in Flash vorimplementiert. Sämtliche anderen benötigten Elemente müssten selbst entwickelt werden.
Ein Applet ist eine Java-Anwendung, welche im Kontext eines Webbrowsers ausgeführt
wird. Hierzu wird vom Webbrowser eine entsprechende Laufzeitumgebung – die JVM
(Java Virtual Machine) – für Applets gestartet und das Applet innerhalb dieser Laufzeitumgebung ausgeführt. Dank dieser Laufzeitumgebung bestehen einige Sicherheitsrichtlinien für Applets, welche die Verwendung von Applets im Internet sicher machen und
beispielsweise Verhindern, dass ein vertrauensunwürdiger Betreiber einer Webseite
Zugriff auf lokale Dateien des Rechners eines Internetsurfers bekommt.
Die Programmierung eines Applets unterscheidet sich von einer normalen JavaAnwendung – abgesehen von den verschiedenen Restriktionen, welche durch die JVM
vorgegeben werden – lediglich im Startverhalten. Normale Java-Anwendungen besitzen
eine Methode mit der Signatur public static void main(String[] args).
Ein Applet besitzt eine solche Methode nicht, vielmehr werden hier verschiedene Methoden bereitgestellt, welche den Zustand des Applets kontrollieren. Diese Methoden
sind init(), start(), stop() und destroy(). Sie werden beim Eintritt in
den jeweiligen Zustand automatisch von der JVM aufgerufen. Aus diesen Methoden heraus werden sämtliche Vorgänge in einem Applet begonnen.
Um überhaupt in der JVM des Browsers gestartet werden zu können muss die Hauptklasse eines Applets zusätzlich von der Klasse java.Applet
vax.swing.JApplet abgeleitet sein.
oder ja-
73
6.7 TS-Analyzer-Applet
Abbildung 33: TS-Analyzer-Applet
Im Gegensatz zu anderen auf dem Markt erhältlichen Softwareprodukten zur Transportstromanalyse, welche es nicht erlauben, innerhalb von gespeicherten Transportstromdaten zu navigieren, soll wie in Kapitel 6.6 bereits beschrieben bei diesem Ansatz das NonLineare Analysieren ermöglicht werden.
Abbildung 33 zeigt die Analyse-Oberfläche. Sie
besteht aus drei Bereichen. Im linken Teil stehen
die unterstützten Tabellen zur Auswahl, wo der
Benutzer die Möglichkeit bekommt, die für ihn
relevanten Tabellen zur Analyse auszuwählen. Im
Hauptteil rechts werden die ausgewählten Tabellen dann in einer Schnellübersicht, das heißt ohne
Loops und ohne Descriptoren angezeigt. Im unteren Teil der Oberfläche hat der Benutzer die Möglichkeit, anhand des Zeitschiebers jede Position
Abbildung 34: TS-Analyzer Detailansicht
innerhalb des Stroms zu erreichen.
Ist die gewünschte Stelle im Strom gefunden, lässt sich im Hauptteil der Oberfläche
durch einen Klick auf die Gewünschte Tabelle die Detailansicht, wie in Abbildung 34
dargestellt, öffnen.
Hierfür wird ein zusätzliches Fenster geöffnet, in dem nur diese Tabelle alleine und komplett mit allen Loops und Descriptoren abgebildet ist.
74
6.8
Webfrontend
Das Webfrontend bildet die Bedienoberfläche für den Anwender. Als Grundlage einer
jeden HTML-Seite dient immer ein so genannter „Web-Server“, welcher Anfragen eines
Web-Browsers56 entgegennimmt und die gewünschten Webseiten ausliefert. Für die
Funktionalität, das heißt für nicht-statische Abläufe wird zusätzlich eine entsprechende
Programmiersprache benötigt, welche dynamische Abläufe in dieser Webseite realisiert.
Zusätzlich wird, um Daten zu speichern optimaler Weise eine Datenbank verwendet,
welche Datenzugriffe kapselt und eine einheitliche Schnittstelle für die Speicherung und
den Abruf von Daten bereitstellt.
Für diese Arbeit wird die zu diesem Zeitpunkt aktuelle und bewährte Kombination aus
der Webserversoftware „Apache“, dem Scriptinterpreter „PHP“ und der Datenbank
„MySql“ für diese Aufgabe verwendet. Aus dieser Kombination ergeben sich die weitläufigen Abkürzungen WAMP (Windows – Apache – MySql – PHP) bzw. LAMP (Linux –
Apache – Mysql – PHP). Diese Softwarekomponenten entwickeln sich enorm rasant,
weshalb regelmäßig und in sehr kurzen Abständen neue Versionen der herausgegeben
werden. Grundsätzlich sollten diese neueren Versionen abwärtskompatibel sein, im Zweifel sollten jedoch die hier beschriebenen Versionen für das System benutzt werden:
-
Apache 2.0.55
-
PHP 5.0.5
-
MySql 5.0.15
Da die Installation dieser Programme und die Herstellung einer Verbindung untereinander relativ aufwändig ist und auch für den Profi einen nicht unerheblichen Zeitaufwand
darstellt, existieren im Internet bereits vorkonfigurierte Fertigpakete, welche alle dieser
Komponenten (und mehr) bereits in fertig eingerichtetem Zustand enthalten und sich
automatisch auf einem Rechner installieren. Ein solches WAMP Paket wurde auch bei
der Entwicklung dieses Systems verwendet. Dieses Paket trägt den Namen XAMPP57 und
enthält neben den erwähnten Versionen von Apache, PHP und MySql mehrere zusätzliche Programme und Erweiterungen, welche für diese Arbeit allerdings uninteressant sind
und außer Acht gelassen werden können. Um XAMPP Distributionen eindeutig zu unterscheiden, besitzt das XAMPP Projekt eine eigene Versionierung. In dieser Arbeit
kommt die Version 1.4.17 zum Einsatz.
56
57
Web-Browser – Programm zum Betrachten von Webseiten im Internet
XAMPP – http://www.apachefriends.org/de/xampp.html
6.8 Webfrontend
75
Als Softwareplattform kommt ein bereits früher entwickeltes Web-Content-ManagementSystem (CMS) zum Einsatz. Dieses bringt bereits wichtige Funktionen wie Benutzerverwaltung und Navigationsverwaltung mit, wodurch die aufwändige Entwicklung solcher
nicht trivialen und nicht zum Thema gehörenden Dinge unnötig werden.
Ein Content-Management-System dient der Trennung von Programmierung, Administration und Redaktion. Bei der klassischen Erstellung von Webseiten muss sich der Entwickler gleichzeitig mit der Gestaltung, der logischen Programmierung sowie mit der
Verwaltung (wie Navigationsstruktur oder Zugriffskontrolle) auseinandersetzen. Ein
Content-Management-System trennt diese Bereiche, indem es separate Eingabemöglichkeiten hierfür bietet. Die Navigationsstruktur beispielsweise wird an einer komplett anderen Stelle festgelegt, als die Inhalte der Webseiten dieser Navigationsstruktur. [DASAT]
Hier wurde das eingesetzte CMS weniger als Redaktionssystem für Inhalte verwendet,
sondern mehr als Rahmen für die eigentliche Anwendung, welcher im Grunde lediglich
die Verwaltung der Navigationsstruktur und die Benutzerverwaltung übernimmt.
Innerhalb des Web-Frontends hat der Benutzer die Möglichkeit, verschiedene Aktionen
durchzuführen. Diese sind:
-
Extraktion von Video-Material
-
Analyse von SI-Daten
-
Extrahierung von Fragmenten des Transportstroms
-
Automatische DVD Generierung (z.B. für Beweissicherung)
-
Anpassung des „Benutzerprofils“
76
6.8.1 Extraktion von Video-Material
Abbildung 35: Webfrontend - Video Extrahierung 1
Zur Extrahierung von Video-Material bekommt der Benutzer eine Art „Fernsehzeitschrift“ (EPG) angeboten. Zu Anfang wird ein Kalender sowie die Programmauswahl
präsentiert. Wählt der Benutzer nun einen Tag aus, werden alle Sendungen dieses Tages
in der Spalte neben dem Kalender angezeigt.
Um direkt zu erkennen, ob die jeweilige Sendung im Ringpuffer vorhanden ist, werden
vorhandene Sendungen weiß angezeigt, während nicht im Ringpuffer befindliche Sendungen in schwarzer Farbe gehalten werden. Um die Suche zu verfeinern hat der Benutzer außerdem die Möglichkeit, seine Auswahl auf einzelne Sender einzuschränken.
Die Daten dieses EPGs werden ausgelesen aus den XML Dateien, welche während der
Aufnahme des Transportstroms von TS-Recorder geschrieben werden (vergleiche Unterkapitel 6.2). Aus diesen Daten werden sämtliche Informationen für den EPG gewonnen.
Das heißt sowohl die Sendungen selbst als auch die verfügbaren Programme / Sender
werden automatisch ausgelesen, wodurch sich das Programm im Falle einer Änderung
des Bouquets selbstständig daran anpasst, ohne speziell konfiguriert werden zu müssen.
Außerdem ermöglicht dies eine direkte Umschaltung auf andere Transponder.
6.8 Webfrontend
77
Abbildung 36: Webfrontend - Video Extrahierung 2
Nach der Auswahl der gewünschten Sendung erscheint eine weitere Maske.
Da die Möglichkeit besteht, dass für ein Programm mehrere Audio-Ströme vorhanden
sind, bekommt der Benutzer die Möglichkeit, die PID eines der zum gewählten Programm gehörenden Audio-Ströme auszuwählen. Um Sendefehler während dem Übergang verschiedener Sendungen erkennen zu können, existiert außerdem die Möglichkeit,
die Zeitspanne zur Extraktion nach vorne bzw. nach hinten auszudehnen.
Zuletzt gibt es in dieser Ebene die Möglichkeit, das Format des extrahierten Videomaterials auszuwählen und so den persönlichen Wünschen zu entsprechen.
Durch Klick auf den Button „Job erstellen“ wird eine Job-Datei für TS2PS-Worker (siehe Unterkapitel 6.5) erstellt und in einem hierfür vorgesehenen Verzeichnis abgelegt.
Beim nächsten Durchlauf von TS2PS-Worker wird diese Job-Datei interpretiert und entsprechend abgearbeitet.
78
6.8.2 Analyse der SI-/PSI-Daten
Abbildung 37: Webfrontend – Transportstromanalyse
Zur Analyse der SI-/PSI-Daten wird das in Unterkapitel 6.7 beschriebene Java-Applet in
das Webfrontend eingebettet. Da dieses bereits dort ausführlich beschrieben wurde, wird
hier nicht näher darauf eingegangen. In Abbildung 37 ist außerdem ein Detail-Fenster,
welches sich bei einem Klick auf eine der im Hauptfenster angezeigten Tabellen öffnet.
6.8 Webfrontend
79
6.8.3 Extrahierung von Transportstromfragmenten
Abbildung 38: Webfrontend - Transportstrom-Extrahierung
Hier kann der Benutzer unveränderte Teile des gesamten Transportstroms extrahieren.
Dies ist nötig, wenn Daten auf andere Art als die in diesem System angebotene analysiert
werden sollen, zum Beispiel durch externe Software.
Der Benutzer wählt den gewünschten Start- und Endzeitpunkt, aus denen der Transportstrom extrahiert werden soll.
Da die Extrahierung des rohen Transportstroms wenige Berechnungen benötigt, sondern
zum größten Teil aus dem Kopieren von Daten besteht, wird für diese Aufgabe kein
Programm im Hintergrund beauftragt. Die Daten werden auf Ebene des Web-Servers,
das heißt per PHP in einem Schritt aus dem Ringpuffer extrahiert und an den Benutzer
weitergegeben. Abgesehen von der Datenübertragung der unter Umständen sehr großen
Datenmenge entstehen so keine Wartezeiten für den Benutzer.
80
Abbildung 39: Code-Ausschnitt Transportstrom-Extrahierung
6.8 Webfrontend
81
6.8.4 DVD-Generierung
Weiterhin existiert die Möglichkeit, bestimmte Zeitspannen oder ganze Tage auf externe
Datenträger wie z.B. DVD zu exportieren.
Zur Beweissicherung ist es nötig für längere Zeit ein Abbild von gesendeten Inhalten zu
besitzen. Hierfür gibt es die Funktion „DVD-Export“, welche es einem Benutzer ermöglicht, die Videodaten in sehr platzsparenden Komprimierungsweisen zu speichern. Bei
diesen Platzsparenden Methoden ist der Aspekt der Qualität egal. Wie in Abbildung 40
zu sehen, wird hier unter anderem das Format „MVCD“ angeboten, welches eine Auflösung von 352 auf 288 Pixeln besitzt.
Abbildung 40: Webfrontend - DVD-Export
Das Format „MVCD“ ist ein nicht standardkonformes MPEG-1 Format, welches bis zu
200 Minuten [MVCD] auf eine CD brennen kann. Bei Hochrechnung auf die Größe
einer DVD unter Verwendung von 4300MB sind das ca. 20 Stunden, welche auf eine
DVD geschrieben werden. In der Praxis allerdings weniger, weshalb bis zu 16h im
Webfrontend angegeben wird.
82
Das markante am MVCD Format ist, dass im Gegensatz zu standardisiertem MPEG-1
mit variabler Bitrate (VBR58) gearbeitet wird. Außerdem wird die Bitrate des Tons von
standardisiert 224 kbit/s auf 128 bis 192 kbit/s gesenkt, sowie die Codierungstechnik
„Joint-Stereo59“ angewandt.
Der Vorgang der Extraktion erfolgt analog zum Verfahren der Transcodierung (vergleiche Abschnitt 6.5.2). Nach der Transcodierung wird je nach gewähltem Format ein entsprechendes Dateisystem generiert.
Damit die entstandenen Datenträger problemlos gebrannt werden können, wird ein so
genanntes Image60 erstellt. Dies wird durch die Software Magic Iso Maker61 realisiert.
Nach der Erstellung dieser Image-Datei wird dem Benutzer ebenfalls eine Email zugesandt mit einem Link zu den generierten Dateien.
Variable Bitrate – Hohe Bitrate für Szenen mit viel Inhalten (=schnelle Szenen), niedrige Bitrate für
Szenen mit wenig Inhalten (=ruhige Szenen)
59 Joint-Stereo – Ansatz: Speicherung nur eines Kanals + Unterschied zum zweiten Kanal
60 Image – Abbild eines Datenträgers verpackt in einer einzigen Datei
61 Magic Iso Maker - http://www.magiciso.com/
58
7 Installation, Konfiguration und Betrieb
7
83
Installation, Konfiguration und Betrieb
Um das Software-Paket auf einem Computer zu installieren und einzurichten sind verschiedene Arbeitsschritte nötig. Zum einen muss die benötigte Infrastruktur geschaffen
werden, welche es der Software und Hardware ermöglicht, ihren Dienst zu verrichten,
zum Anderen muss die Software entsprechend den aktuellen Gegebenheiten bzw. Erfordernissen angepasst werden. Dieser Abschnitt gibt einen kurzen Überblick über die nötigen Schritte.
Nötig ist ein aktuell ausgestatter Server-Computer mit einer Budget DVB-Karte der Firma Technotrend. Der Computer sollte über ausreichend Rechenleistung verfügen. Zum
Stabilen Betrieb ist mindestens ein Doppelprozessor-System mit mindestens 2,5 GHz
Taktfrequenz pro Prozessor nötig. Bei dieser Anwendung ist der Arbeitsspeicher nicht
entscheidend, um allerdings einen stabilen und unterbrechungsfreien Serverbetrieb sicherzustellen, sollte der Rechner über mindestens 1024 MB Arbeitsspeicher verfügen.
Zur Datenspeicherung muss ein RAID-System (siehe auch Absatz 5.2.6) zum Einsatz
kommen. Hierbei ist eine sinnvolle Verteilung zwischen Kapazität der einzelnen Festplatten und deren Anzahl wichtig. Für optimale Performance wird ein Verbund mit mindestens 5 Festplatten mit Umdrehungszahlen von 7200 Umdrehungen pro Minute empfohlen. Aufgrund der enormen Datenmengen wird diese Menge allerdings in der Praxis ohnehin überschritten, da die Maximalkapazität handelsüblicher SATA62-Festplatten momentan im besten Fall 500MB beträgt. Aufgrund der Leistung des relativ jungen SATA
(Serial ATA) Standards ist es nicht mehr nötig, Geld in ein teures SCSI-Raid-System zu
investieren.
Als Betriebssystem ist ein Windows XP kompatibles System zu wählen, also zum Beispiel
Microsoft Windows Server 2003.
Um die Software nun zu installieren müssen zuerst einige Vorarbeiten erledigt werden.
Hierzu gehört die Installation eines WAMP Servers (siehe Unterkapitel 6.8) sowie die
Vorbereitung mit der Installation der Treiber für die DVB-Karte. Der in Unterkapitel 6.8
besprochene WAMP Server XAMPP befindet sich als Installationspaket auf der im Anhang befindlichen CD. Die Konfiguration dieses Servers wird hauptsächlich innerhalb
der Dateien httpd.conf und php.ini vorgenommen, welche von der XAMPP Installationsroutine auf der Festplatte erstellt werden.
62
SATA – Serial ATA – Serielle Schnittstelle für Festplatten
84
7 Installation, Konfiguration und Betrieb
Neben dieser Software-Installation müssen einige Verzeichnisse erstellt werden. Diese
sind:
-
Verzeichnis für Job-Files von TS2PS-Worker (6.5)
-
Verzeichnis für extrahiertes Video-Material von TS2PS-Worker
-
Verzeichnis für EPG-Daten im XML-Format
-
Verzeichnis, in das die Dateien des Ringpuffers geschrieben werden (5.2.2)
Entsprechend diesen Verzeichnissen und den individuellen Anforderungen ist später die
Konfigurationsdatei TS_Recorder.ini anzupassen, welche sich im Rootverzeichnis des
Software-Pakets befindet.
Dafür wird das Verzeichnis „running_system“ von der im Anhang befindlichen CD in
ein beliebiges Verzeichnis auf der Festplatte kopiert. Die Verzeichnisstruktur muss eingehalten werden, damit die einzelnen Software-Module die Möglichkeit besitzen, sich
gegenseitig zu finden.
Damit das Web-Frontend funktioniert und erreichbar ist, muss zuerst die Struktur hierfür
anhand der beigefügten sql-Datei in die Datenbank importiert werden. Danach muss der
so genannte Web-Root63 in der Konfigurationsdatei httpd.conf des Apache Webservers
entsprechend gesetzt werden. Das entsprechende Verzeichnis befindet sich auf der Installations- CD im Verzeichnis „running_system\htdocs“.
Nachdem dies erledigt ist, müssen die Programme TS-Recorder, TS2PS-Worker und
Tables-Socket-Service beim Start des Rechners automatisch ausgeführt werden. Dies
kann zum Beispiel durch den in Windows integrierten Taskplaner geschehen. Damit die
Software startet, muss sich der Benutzer, nachdem der Server-Rechner hochgefahren ist,
ein Mal anmelden.
63
Webroot – Startverzeichnis eines Webservers
8 Zusammenfassung
8
85
Zusammenfassung
In dieser Diplomarbeit wurde ein System realisiert, welches grundsätzlich 24 Stunden am
Tag einen Transportstrom des DVB-Netzwerkes zur Weiterverarbeitung mitschneidet.
Die Struktur des Transportstroms wird automatisch interpretiert, sodass die Software
auch ohne weitere Anpassungen auf andere Transponder als den des ZDF eingestellt
werden kann.
Der mitgeschnittene Transportstrom kann dann auf verschiedene Weise weiterverarbeitet
werden. Es ist zum Beispiel möglich, die im Transportstrom enthaltenen DVB-SI und
DVB-PSI Informationen auszulesen und deren inhaltliche Struktur zu analysieren.
Weiterhin können aus den gespeicherten Daten beliebige Sendungen extrahiert werden.
Für die Extraktion existiert eine Formatauswahl, welche neben verschiedenen aktuellen
Codecs wie DivX oder XviD auch die Extraktion der Daten in ihrer originalen MPEG-2
Struktur anbietet und somit eine weitere Möglichkeit bietet, die Sendequalität zu beurteilen und zu analysieren.
Um beliebigen weiteren Analysemethoden nicht den Weg zu versperren, ist es ebenfalls
möglich, Teile des gespeicherten Transportstroms in roher Form zu extrahieren und diesen mit beliebigen externen Analysetools zu verarbeiten.
Die Bedienung dieser Funktionen wird durch eine Web-Oberfläche bewerkstelligt. Je
nach Bedarf und Netzwerk-Konfiguration wird es so ermöglicht, dieses System von jedem Rechner, der an das Internet (bzw. an das ZDF-Netzwerk) angeschlossen ist, zu
bedienen.
Weiterhin entstanden neben dem eigentlichen Produkt diverse Software-Elemente, welche einem Entwickler die Universelle Weiterverwendung zur Programmierung in diesem
Themenbereich möglich machen.
8.1
Kritische Würdigung
Im Zuge von ersten Tests, die nach der Fertigstellung eines jeden Moduls parallel zur
Weiterentwicklung durchgeführt wurden, wurde herausgestellt, dass das System funktioniert und die nötigen Funktionen bereitstellt. Sämtliche Funktionen arbeiten im Allgemeinen fehlerfrei, jedoch muss auf absolut korrekte Bedienung geachtet werden, da im
aktuellen prototypischen Zustand wenige Fehlerüberprüfungen vorgenommen werden.
Weiterhin ist für einen Regelbetrieb das komplette System in einer Serverumgebung zu
86
8 Zusammenfassung
testen, da während der Bearbeitung dieser Diplomarbeit alle Tests auf einem Entwicklungsrechner durchgeführt wurden.
In Gesprächen mit diversen Mitarbeitern des ZDF wurde klar, dass ein solches System
einen sehr guten Ansatz für den Einsatz in einer Sendeanstalt darstellt. Viele der Mitarbeiter, mit denen gesprochen wurde, hatten eigene Vorschläge, womit der Nutzen des
Systems abermals erhöht werden kann. Leider konnte aufgrund des begrenzten Zeitrahmens und Umfangs einer Diplomarbeit den meisten Wünschen nicht entsprochen werden. Deshalb wäre es wünschenswert, diesen Ansatz in der Zukunft aufzugreifen und
weiterzuentwickeln.
Im Laufe der Bearbeitung und der Tests hat sich die Wahl des Webfrontends für die
Bedienung durch den Benutzer als unfunktional herausgestellt, da einige Funktionen
mehr Elemente benötigen, als HTML zur Verfügung stellt. Auch die Überwachung des
Systemstatus und des Aufnahmestatus sollte über ein Frontend möglich sein, was in
HTML nur eingeschränkt möglich wäre. Eine eigenständige Applikation mit einer entsprechenden Netzwerkschnittstelle am Server ist hier wünschenswert. Um weiterhin die
örtliche Unabhängigkeit zu erhalten, ist der Einsatz von Techniken wie Java Web Start
denkbar.
Weiterhin ist unbedingt auf Performance zu achten. Die in Abschnitt 6.5.2 empfohlene
Entwicklung eines Plugins für den Frameserver AVISynth ist unbedingt nötig, da Tests
zeigten, dass DGIndex sehr Fehleranfällig ist. Einerseits werden bei Fehlern während der
Bearbeitung keinerlei Informationen über das Auftreten eines Fehlers zurückgegeben,
andererseits wird bei Fehlern im Strom teilweise unsynchrones Videomaterial produziert.
Ein weiteres noch nicht gelöstes Problem stellt die Extrahierung von TransportstromFragmenten durch das Webfrontend dar. Es scheint dem Apache Webserver nicht möglich, aneinanderhängende Daten mit mehr als 4 GB an einen Internetbrowser auszuliefern. Da Transportstromdaten relativ schnell größer als 4 GB werden können, stellt dies
ein Problem dar. In Tests mit IIS64 konnte derselbe Effekt festgestellt werden. Durch die
Einführung einer GUI-Applikation würde dieses Problem allerdings verschwinden.
64
IIS – Microsoft Internet Information Server
9 Fazit / Ausblick
9
87
Fazit / Ausblick
Die Speicherung des kompletten Fernsehprogramms ist eine sehr gute Grundlage für die
Weiterverarbeitung jeglicher Art. Die Weiterverarbeitungsmöglichkeiten, welche durch
diese Diplomarbeit beschrieben werden, sind nur ein kleiner Teil der denkbaren Anwendungsgebiete.
So wie es entwickelt wurde, soll das System in Zukunft beim ZDF eingesetzt werden. Ein
zukünftiger Einsatzbereich wird das Internet-Streaming sein. Das ZDF bietet momentan
ausgewählte Sendeinhalte innerhalb der „ZDF Mediathek“ über das Internet an. Aktuell
sind diese Inhalte sehr begrenzt, es ist aber geplant, das Angebot zu erweitern. Das größte Hindernis bei der Erweiterung dieses Angebots sind Lizenzrechtliche Fragen. Für
Sport-Veranstaltungen beispielsweise besitzt das ZDF keine Rechte, dieses Material über
das World Wide Web zu verbreiten oder es ist nicht genau geklärt, in wie weit das Material für das Internet verwendet werden darf. Wenn diese Fragen geklärt sind, plant das
ZDF, das Streaming Angebot zu erweitern und das Encoding System dafür an das in
dieser Diplomarbeit entstandene System anzukoppeln.
Weiterhin wird – auch auf Hinblick der aktuellen Olympia-Veranstaltung – der Wunsch
nach Beweissicherung innerhalb der Redaktionen laut. Beweissicherung bedeutet, alles
gesendete Material ohne Beachtung auf die Qualität zu sichern. Hierfür ist bereits die
Funktion „DVD Extrahieren“ im Webfrontend eingeplant. Da der Qualitätsaspekt hier
vernachlässigbar ist, ist es denkbar, einen kompletten Tag eines Senders auf wenige
DVDs zur Archivierung zu exportieren.
Auch die technische Seite des ZDF ist mit eingebunden. Für die Abteilung Sendeabwicklung ist es denkbar, einen Mechanismus zur automatischen Erkennung von Fehlern zu
entwickeln, bei dem nach dem Auftreten eines Fehlers unverzüglich ein Verantwortlicher
informiert wird.
Durch die immer weiter steigenden Computer- und vor allem Speicherkapazitäten rückt
die Realisierung eines solchen Systems für heimische Wohnzimmer in finanzierbare Bereiche. Deshalb wäre es denkbar, dieses System als privaten „Über-Videorecorder“ zu
verwenden. Beispielsweise mit Anschluss an eines der in Abschnitt 5.1.1 genannten
Freeware-Projekte oder als eigenständiger Server mit Funktionen nach den aktuellen
UPnP65-Standards.
65
UPnP – Universal Plug and Play – Zur Herstellerunabhängigen Ansteuerung von Geräten über ein IPbasiertes Netzwerk
88
89
III Literaturverzeichnis
[REIMERS]
Reimers, Ulrich: Digital Video Broadcasting. The International
Standard for Digital Television. Heidelberg: Springer-Verlag Berlin Heidelberg, 2001
[VONHOEGEN]
Vonhoegen, Helmut: Einstieg in XML. 2. Auflage. Bonn: Galileo Press GmbH, 2004
[KRUEGER]
Krüger, Guido: Handbuch der Java-Programmierung. 3. Auflage. München: Addison-Wesley, 2002
[LENZ]
Lenz, Martin: Digitales Fernsehen in der Praxis. Der sichere
Start in die digitale Zukunft. Poing: Franzis-Verlag GmbH, 1999
[LOUIS]
Louis, Dirk: C/C++. Die praktische Referenz.
München: Markt + Technik Verlag, 2003
[GAMMA]
Gamma, Erich: Design Patterns. Elements of Reusable ObjectOriented Software. München: Addison-Wesley, 1996
[ETSI 300468]
ETSI EN 300 468 Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems. V1.6.1,
11.2004
[ISO 13818-1]
ISO/IEC 13818-1 Information technology - Generic coding of
moving pictures and associated audio information: Systems.
01.12.2000
[BOLDT]
Boldt, Daniel: Konzeption und Realisierung eines Dienstes zur
Aufbereitung und Codierung von DVB-SI Tabellen aus Content
Management Daten. Diplomarbeit, TU Ilmenau 2004
90
[KLEIN]
Klein, Daniel: Konzeption und Realisierung von SoftwareKomponenten zur Extraktion von DVB-SI Daten für die Weiterverarbeitung im Rahmen des ZDF-DVB-SI-ManagementProjekts, FH Wiesbaden 2005
[FSF]
Free Software Foundation: “Various Licenses and Comments
about Them”,
URL: http://www.fsf.org/licensing/licenses/
[Stand: 15. Februar 2006]
[INFORMITV]
informitv.com: “BBC opens Pandora box on a Promise” URL:
http://informitv.com/articles/2005/08/07/bbcopenspandora/i
ndex.shtml [Stand: 14. November 2005]
[PATTERSON]
Patterson, David A.: „A Case for Redundant Arrays of Inexpensive Disks (RAID)”, URL:
http://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf
[Stand: 12. Januar 2006]
[DVBORG]
DVB Project: DVB Timeline,
URL: http://www.dvb.org/about_dvb/history/dvb_timeline
[ASTRA]
SES-Global:
The
Astra
Fleet,
URL:
http://www.ses-
astra.com/corpSite/siteSections/ASTRAFleet/index.php
[MSBDA]
Microsoft: “Protected Broadcast Driver Architecture”, URL:
http://www.microsoft.com/whdc/device/stream/BDA_protect
.mspx [Stand: 25. April 2006]
91
[DASAT]
Dasat: “Was ist ein CMS?“ URL:
http://www.dasat.com/content-management-system/was-istein-cms-/online-content-management-system--cms_100132_0.html [Stand: 26.01.2006]
[MVCD]
MoleVCD: „MoleVCD 2003“
URL: http://www.molevcd.de/mvcd.htm [Stand: 26.01.2006]
92
A Listings
A Listings
A.1
DTDs
A.1.1 Tables-Socket-Service
Anfrage:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT table_id (#PCDATA)>
<!ELEMENT pid (#PCDATA)>
<!ELEMENT timestamp (#PCDATA)>
<!ELEMENT get (table_id, pid, timestamp)>
<!ATTLIST get
ID #REQUIRED
(yes | no) #REQUIRED
(yes | no) #REQUIRED
>
Antwort:
<!ELEMENT descriptor (#PCDATA)>
<!ATTLIST descriptor
CDATA #REQUIRED
>
<!ELEMENT rows ANY>
<!ELEMENT loop (rows, descriptor*)>
<!ATTLIST loop
ID #REQUIRED
>
<!ELEMENT table (rows, descriptor*, loop*)>
<!ATTLIST table
CDATA #REQUIRED
CDATA #REQUIRED
>
<!ELEMENT response (table)>
<!ATTLIST response
ID #REQUIRED
>
<!ELEMENT answer (response+)>
93
94
A.2
A Listings
TS2PS Job-Files
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
title (#PCDATA)>
filename (#PCDATA)>
format (#PCDATA)>
begin (#PCDATA)>
end (#PCDATA)>
vorlauf (#PCDATA)>
nachlauf (#PCDATA)>
email (#PCDATA)>
pid (#PCDATA)>
<!ELEMENT TS2PSJOB (title, filename, format, begin, end,
vorlauf, nachlauf, email, pid+)>
A.3
Beispiel Konfigurationsdatei
[Tuner]
Frequenz=11954000
Symbolrate=27500000
;Polarisation: h -> Horizontal v -> Vertikal
Polarisation=h
QAM=2
[LNB]
LOF1=9750000
LOF2=10600000
LOFSW=11700000
;true/false
LNBPower=true
[TS_Save]
TS_Files_Path=C:\Temp\TS_SAVE
TS_Files_Name=TS_
TS_Files_Extension=.ts
;TS_Files_Size --> Dateigröße der Dateien, die geschrieben werden in Bytes. Max. Groesse 2GB. Hier einige MB unter 2GB angeben,da beim Aufnehmen die Dateien nicht genau geschnitten werden können
TS_Files_Size=2000000000
;Maximalgroesse des Verzeichnisses in GB, wo die TS-Files reingeschrieben werden
TS_Files_Folder_Max_Size=110
[Logfile]
;Es wird dann bei jedem Start ein Logfile erstellt nach dem
Schema <Log_file_Dir>\<Log_File_Prefix><timestamp>.log
A Listings
95
Log_File_Dir=C:\Temp\TSLOGS
Log_File_Prefix=TS_Log
[Encoding]
Path_To_DGIndex=C:\DA\Software\dgmpgdec145\DGIndex.exe
DGIndex_Save_Path=C:\Temp\TS_SAVE\DGIndex_Save
Encoder_Tasks_Dir=C:\DA\apache_webroot\webinterface_cms\Scripte\D
GIndex_Klasse\tasks
AVS_Template_Path=C:\DA\apache_webroot\webinterface_cms\Scripte
\DGIndex_Klasse\AVS_Template.avs
Video_Delivery_Dir=C:\Temp\apache_videos
[Misc]
Tmp_Dir=C:\Temp
[EPG]
EPG_XML_Path=C:\DA\apache_webroot\EPG
EPG_XML_File_Prefix=EPG_
[TS2PS]
;In dieses Verzeichnis kommen Job-Dateien rein, die von
TS2PS_Worker abgearbeitet werden sollen
TS2PS_job_dir=C:\DA\Software_Entwicklung\TS2PS_Worker\jobs
;In dieses Verzeichnis werden die fertigen MPEG2-Files gelegt,
damit sie vom Empfänger abgerufen werden können
TS2PS_target_dir=C:\Temp\apache_videos
[Software]
PVAStrumento=C:\DA\Software\pvas21015\cmdshell\cPVAS.exe
96
B Pflichtenheft zum System
B Pflichtenheft zum System

2 Ziele dieser Arbeit

Transcription

Similar documents

Paper

- Deutsch-Rumänische Gesellschaft

[re•flex] #26

TX-SR505E

Über Omnis Studio

TX-SR606

MediaStation 6