Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. Lagasse
Onderzoeksgroep Wireless & Cable Directeur: prof. dr. ir. L. Martens
Ontwikkeling van een DVB playout manager voor interactieve digitale televisie door Tom Swennen
Promotor: prof. dr. ir. L. Martens Scriptiebegeleider: ir. T. Deryckere Scriptiebegeleider: lic. M. Ide
Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen
Academiejaar 2005–2006
“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen ervan te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting uitdrukkelijk de bron te vermelden bij het aanhalen van resultaten uit deze scriptie.” “The author gives the permission to use this thesis for consultation and to copy parts of it for personal use. Every other use is subject to the copyright laws, more specifically the source must be extensively specified when using from this thesis.” Gent, Juni 2004 De auteur
Tom Swennen
i
Woord vooraf Met een bang hart ben ik gestart aan het brugprogramma voor industrieel ingenieurs. De twee belangrijke, uitputtende jaren vlogen voorbij door hard werken en sleutelen aan verschillende projecten. Het belangrijkste werk moest natuurlijk nog komen: de thesis. Een keuze tussen de verschillende onderwerpen maken was moeilijk, maar het grote project maken des te moeilijker. Nieuwe technologie¨en, apparaten, . . . een hele uitdaging om eraan te beginnen en het af te maken.
Natuurlijk sta je er niet helemaal alleen voor en word je deskundig begeleid door de promotor en de assistenten. Mijn familie en vriendin zorgden dan weer voor de andere steun om erdoor te geraken en om de motivatie telkens weer aan te wakkeren.
Ik dank hiervoor alle mensen die me geholpen en begeleid hebben. Het is een uitzonderlijke, harde ervaring geweest als brugstudent, maar een uiterst voldoening gevende.
Tom Swennen Gent 24 Mei 2006
ii
Ontwikkeling van een DVB playout manager voor interactieve digitale televisie door Tom Swennen Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: prof. dr. ir. L. Martens Scriptiebegeleider: ir. T. Deryckere Scriptiebegeleider: lic. M. Ide Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. Lagasse Onderzoeksgroep Wireless & Cable Directeur: prof. dr. ir. L. Martens
Samenvatting Playout is een term, in de broadcasting terminologie, voor de transmissie van radio- of tvkanalen vanuit de broadcaster naar een netwerk voor verdere verspreiding naar het publiek. Het multiplexen van transportstromen, het zetten van data op een carrousel en het toevoegen van de geschikte service informatie zijn enkele belangrijke taken van een playoutsysteem. De playoutmanager implementeert een dergelijk systeem voor interactieve digitale televisie met het Multimedia Home Platform. Via een grafische interface wordt de Program Specific en Service Information opgesteld. De manager zorgt voor de configuratie van hardware en software componenten om de transportstroom samen te stellen en te bezorgen naar de verschillende set-top boxen via een aparte multiplexer. De tool maakt het mogelijk om het principe van broadcasting, MHP application signalling/delivery uitvoerig te onderzoeken. Een Event Information Table (EIT) editor en generator vervolledigen het systeem. Electronic Programme Guides (EPG) (en andere programma’s) kunnen dan getest worden met eigen opgestelde event informatie.
Trefwoorden playout, iDTV, MHP, Program Specific en Service Information
iii
Development of a DVB play-out manager for Interactif Digital Television Tom Swennen Supervisor(s): Prof. Dr. Ir. Luc Martens, Ir. Tom Deryckere, Lic. Michiel Ide Abstract— This article presents a play-out system for iDTV and MHP. We will show the architecture of a modular play-out system with reuse of broadcast software components. This system enables the user to configure a transport stream and to broadcast applications designed for the MHP platform. The play-out manager will allow the addition of PSI/SI control and wizards to lower the level of user input. Other broadcast components can easily be integrated. Keywords— Playout,interactif Digital Television, iDTV, Multimedia Home Platform, MHP, Program Specific Information, PSI, Service Information, SI
the broadcaster, is necessary. The basic principle of a carousel is that specific data, chosen by the service provider, is sent and repeated periodically. The Object Carousel and Object Streamer form together a DSM-CC object carousel. • Data Inserter: The Data Inserter creates transport packets from the DSM-CC data stream. Through the ethernet interface it reads the data stream (Multi protocol encapsulling), generates transport packets from the data and transports them to a modulator or multiplexer.
I. I NTRODUCTION
This article starts with the requirements of the playout manager, followed by the explanation of the software architecture. In section IV the article is concluded.
P
LAY-OUT refers to the transmission of radio or television from broadcaster to the delivery network, and so to the audience. Multiplexing of transport streams, configuration of data carousels and the addition of the appropriate Program Specific [1] and Service Information [2], [3] (PSI, SI) are the most important task of a play-out system. The play-out manager implements such a system for interactif Digital Television[4] with the Multimedia Home Platform[3]. It composes Program Specific and Service Information through a graphical user interface and configures hardware and software components. These components build the physical transport stream and deliver it to the set-top boxes through a distinct multiplexer. With this tool it’s possible to investigate broadcasting, MHP application signalling and delivery in detail. An Event Information Table (EIT) editor and generator complete the system to test Electronic Program Guides (EPG) (and others) with self-composed event information. The system will reuse existing software components for the application delivery:
II. R EQUIREMENTS A. Mission Statement The implementation of a play-out system through the reuse of Rohde & Schwarz software components. It provides a graphical frontend for the datainserter. Its main tasks are: Configuration and generation of PSI and SI (PAT, PMT, NIT, SDT, EIT, AIT) • Make wizards available for the most common PSI and SI configurations •
B. Target End Users The play-out manager will extend the current test platform of the Wireless and Cable (WICA) research group. The researchers are the target end-users. Knowledge of PSI and SI is necessary for the extensive testing. For regular application testing basic knowledge of PSI and SI is sufficient because the wizards will deal with the configuration of PSI and SI.
•
C. Quality Attributes
Ghent University (UGent), Wireless & Cable group, Department of Information Technology, Gent, Belgium. E-mail: [email protected] .
The architecture is built around the most important quality attributes. Modifiability and usability will be handled in the play-out manager. The reuse of broadcast software or hardware components implies a dependence on manufacturer. The implementation of the play-out manager should minimize this dependence and provide possibilities for the replacement and insertion of components.
Object Carousel and Object Streamer: A Digital Storage Media Command and Control (DSM-CC) object carousel provides a protocol to transport data over a broadcast channel. In a broadcast channel the user can’t dynamically choose which data he wants to receive. A mechanism, that initiates the transfer of data from
PSI and SI configuration and generation is an extensive task. To prevent confused users, a clear view on the transport stream must always be provided. Due to the large specifications, the control logic (references between tables, . . . ) of the PSI and SI must be easy extendable. III. S OFTWARE A RCHITECTURE In figure 1 the module view of the architecture is shown. The architecture is split up in different projects according to their functionality, each has its own responsibility. The interaction, dedicated by arrows, between the modules must be kept as low as possible.
Fig. 2. Module architecture of the XML module.
packets for its configuration. A special generator for the parsing is implemented. Through the sequential implementation of the binarisation, reuse of this component is simple; the binary format of the tables, the splitted format with or without header are all available. C. GUI
Fig. 1. Overview of the architecture.
The Object Carousel, Object Streamer and DataInserter modules represent the reused software components. A. XML This module takes care of the PSI and SI. All the data is stored in XML format. Each PSI and SI table has its own XML scheme, including supported descriptors. Internal datasets are created from the schemes for easy, comfortable data management. Figure 2 shows the structure of this module. A Transport Stream class implements the control of the PSI and SI. The different Data Accessors classes take care of the data storage in corresponding datasets, generated form the collection of schemes in Tables. The Extra Data Accessor class provides methods to include non supported descriptors (not included in the different XML schemes) of the PSI/SI tables. B. Hardware The Hardware module abstracts the different broadcast software components used in the play-out manager. Per component a class takes care of the configuration and invocation. The DataInserter needs the binary representation[1, Section 2.4.4][2, Sections 5 and 6][3, Section 10, page 75 ff.] of the tables divided in transport
The GUI consists of the Displayer, Wizard and BusinessLogic (figure 1). The Displayer module deals with the general user interface. It provides a clear view on the transport stream and simplifies the use of the playout manager. The BusinessLogic calls the different reused software components under orders of the Displayer. It performs the configuration and invocation of the software components. The BusinessLogic forms, together with the hardware modules, a virtual machine by which different broadcast software components can be introduced to the system. With the Wizard module addition of wizards is simple; implement an interface, define it in the BusinessLogic and the play-out manager is updated. IV. C ONCLUSIONS The play-out manager for iDTV implements a playout system which is extendable to other broadcast components. Furthermore it can be adopted to the experience of the user through the devision of control and data in the XML module. With the wizard mechanism, easy application broadcasting and many more common task can be inserted in the tool. R EFERENCES [1] I NTERNATIONAL O RGANISATION FOR S TANDARDISATION, “Generic coding of moving pictures and associated audio, systems recommendation H.222.0”, ISO/IEC 13818-1, November 1994. [2] E UROPEAN B ROADCASTING U NION , D IGITAL V IDEO B ROADCASTING, “Specification for Service Information in DVB systems”, ETSI EN 300 468 V1.6.1, June 2004. [3] E UROPEAN B ROADCASTING U NION , D IGITAL V IDEO B ROADCASTING, “Multimedia Home Platform Specification 1.0.2”, ETSI TS 101 812 V1.2.1, June 2002. [4] S TEVEN M ORRIS , ATHONY S MITH C HAIGNEAU, “Interactive TV Standards, A Guide to MHP, OCAP and JavaTV”, Focal Press, ISBN: 0240806662, April 21, 2005.
Inleiding Bij een playoutsysteem voor interactieve digitale televisie (iDTV) komen verschillende technologie¨en kijken: Digital Video Broadcasting (DVB) voor de transmissie van digitale televisie en het Multimedia Home Platform (MHP)1 voor de ondersteuning van applicaties.
1.1
Digital Video Broadcasting
Het Digital Video Broadcasting Consortium
2
is een industrieel consortium dat de verschillende
aspecten van het uitzenden van digitale televisie en data services standaardiseert. De DVB standaarden omvatten alle aspecten van digitale televisie van transmissie, interfacing, conditionele toegang tot interactiviteit.
Bij DVB wordt beeld en geluid volgens de MPEG-2-standaard gecomprimeerd, figuur 1.1. Dit levert elementaire MPEG-stromen (ES) op. Deze worden vervolgens in MPEG-2-transportpakketten met vaste lengte verdeeld. Elk pakket bevat een header met o.a. een identificatieveld: de pakket identifier (PID). Met deze PID kan men verschillende (televisie)kanalen multiplexen, m.a.w. ze worden afwisselend achter elkaar geplaatst. Dit levert een MPEG-transportstroom (TS) op. Deze wordt vervolgens over ´e´en van de mogelijke DVB-standaarden3 uitgezonden.
1
MHP is niet het enigste platform. Andere voorbeelden zijn OCAP, Open TV, MediaHighway, Power TV,
Liberate . . . Vele van deze platforms zijn MHP compliant. MHP applicaties kunnen m.a.w. ook op deze platforms uitgevoerd worden. Het verschil zit in de extra features die de andere platformen aanbieden. Ze zijn ook meestal niet op een open standaard gebaseerd en worden door commerci¨ele instellingen gebruikt. 2 http://www.dvb.org 3 DVB-Cable, DVB-Terrestrial of DVB-Satellite
1
Hoofdstuk 1. Inleiding
2
Figuur 1.1: Vorming van een enkelvoudige programmatransportstroom.
Zonder extra informatie is deze transportstroom niet bruikbaar. De decoder weet niet tot welke (televisie)kanalen de verschillende pakketten behoren. Daarom voegt DVB nog extra data toe naast de beeld- en geluidstromen, de Program Specific en Service Information (PSI en SI). Deze metadata levert o.a. de structurele informatie aan de decoders om de verschillende kanalen te onderscheiden. De PSI en SI worden ook in MPEG-2 TS-pakketten verdeeld en verstuurd. Met een Program Association tabel (PAT) worden de verschillende services4 gedefinieerd, figuur 1.2. Het vertelt waar de decoders de definities, Program Map tabellen (PMT), van de services kan vinden in de transporstroom d.m.v. een PID. De PMT bevat een opsomming van de elementaire stromen die samen de service vormen.
Figuur 1.2: Eenvoudige voorstelling van de structurele vorming van een transportstroom
4
Services worden ook wel programma’s genoemd. Het zijn de verschillende individuele hedendaagse zenders
zoals VRT, VTM, VT4, . . .
Hoofdstuk 1. Inleiding
1.2
3
Multimedia Home Platform
Het Multimedia Home Platform5 is een open standaard voor middleware ontwikkeld voor interactieve digitale televisie. Dit platform is onafhankelijk van de onderliggende, producent-specifieke hardware en software. MHP is gebaseerd op het gebruik van een Java virtuele machine en de definitie van generieke Application Programming Interfaces (API) die toegang geven tot de resources van de set-top boxen. De MHP applicaties worden bovenop deze API’s uitgevoerd. Via een return-kanaal, een modem connectie, kunnen de applicaties communiceren met de buitenwereld. MHP kent twee soorten applicaties: 1. DVB-HTML applicaties zijn een set HTML pagina’s die als deel van een service gebroadcast worden. Deze applicaties zijn niet zo populair omdat ze pas vanaf MHP 1.1 beschikbaar waren en omdat vele ontwikkelaars, broadcasters, content providers ze te complex vinden. 2. De DVB-Java applicaties zijn de populairste. Ze worden geschreven in Java, gebruikmakend van de MHP API’s, en bestaan uit een set van klasse-bestanden die binnen een service worden verzonden. DVB-J applicaties zijn bekend als “Xlets”. Het concept is gelijkaardig
aan applets voor webpagina’s en het werd ge¨ıntroduceerd door Sun
cificatie. Zoals applets, worden de XLets door een externe manager gecontroleerd. Deze applicatiemanager zorgt voor het starten, stoppen en pauzeren van de applicatie. Binnen WICA
6
zijn er andere thesissen die applicaties ontwikkelen voor dit platform, o.a. een
elektronische programma gids (EPG), messenger applicatie, t-commerce, . . .
1.3
Playoutsysteem
Playout is een term, in de broadcasting terminologie, voor de transmissie van radio- of tv-kanalen vanuit de broadcaster naar een netwerk voor verdere verspreiding naar het publiek. Het multiplexen van transportstromen, het zetten van data op een carrousel en het toevoegen van de geschikte service informatie zijn enkele belangrijke taken van een playoutsysteem. Een algemeen playoutsysteem (figuur 1.3), gebaseerd op DVB, bevat de volgende componenten.
5 6
http://www.mhp.org WICA: Wireless & Cable research groep
Hoofdstuk 1. Inleiding
4
Figuur 1.3: Een algemene voorstelling van een playoutsysteem, gebaseerd op DVB.
Een encoder zorgt voor de digitalisatie en compressie van video en audio. Een carrousel zorgt voor het periodiek herhalen van een gegeven directory. De Packetisers nemen de elementaire stromen en stoppen ze in MPEG-2 transportstroom-
pakketten. De Transportstream builder stelt een transportstroom op met de verpakte elementaire
stromen. De structuur wordt aangegeven via de Program Specific en Service Information. De Re-Multiplexer neemt de verschillende transportstromen op zijn input en vermengt ze
tot ´e´en transportstroom. Het is een actieve multiplexer. ES’en met overlappende PID’s zullen verzonden worden met een andere PID’s. De Modulator verstuurt de digitale informatie over het verspreidingsnetwerk volgens ´e´en
van de DVB standaarden. In het testlabo van WICA is een soortgelijk systeem opgesteld, figuur 1.4. Een encoder en MPEG-analyser zorgen voor het versturen van video en audio. Om MHP-applicaties te broadcasten gebruiken we een Rohde & Schwarz (R&S) datainserter. Via een carrousel ontvangt de datainserter de datastroom. Program Specific en Service Informatie wordt apart opgesteld en doorgestuurd. Met deze informatie gaat de datainserter een transportstroom opbouwen met enkel een datastroom.
Hoofdstuk 1. Inleiding
5
Figuur 1.4: Blokschema van de opstelling in het testlabo.
1.4
Doelstellingen
Deze thesis richt zich op het opstellen van de Program Specific en Service Information en het configureren van de nodige carrousels. Een transportstroom-multiplexer zorgt voor het bundelen van de verschillende bronnen in de interactieve digitale televisie testopstelling van WICA. De playoutmanager voor iDTV zal zich voor de R&S datainserter positioneren en de transmissie van zijn TS besturen.
Momenteel verzorgt een R&S MHPWizard de playout. Het configureert een minimum aan PSI/ SI en voegt ´e´en MHP applicatie toe aan de TS. PSI, SI, DVB en MHP kunnen veel meer: meer applicaties binnen een service, meerdere services, extra event informatie, . . . Kortom om elk soort MHP applicatie te kunnen testen, moeten er meer mogelijkheden komen.
De ontwikkeling van een playoutsysteem biedt een oplossing. Via een duidelijke grafische interface moet een onderzoeker in staat zijn om MHP broadcasting en signalisatie uitgebreid te testen. Opstellen van PSI en SI is het middel om dit mogelijk te maken.
Hoofdstuk 1. Inleiding
6
Via beschikbare componenten (datainserter, Object Carrousel (OC) en Object Streamer (OS)7 ) zal een playoutsysteem gebouwd worden. De playoutmanager voor iDTV is de grafische interface en de bestuurder van het systeem. Opstellen van PSI en SI, aanroepen van carrousels en streamers zijn zijn voornaamste taken.
Een grondige studie van PSI en SI (MPEG ISO/IEC 13818-1 , [1] DVB ETSI EN 300 468 [2] en MHP ETSI TS 101 812 [3]) was onvermijdelijk. De werkwijze, de structurele eigenschappen, de syntax van een TS moest eerst bestudeerd worden alvorens de implementatie kon starten. Hoofdstuk 2 geeft een summier overzicht van de gebruikte PSI en SI.
Met het hergebruik van de R&S componenten werd de software van een paar taken verlost. Het moest zich niet veel aantrekken van de vorming van een carrousel (DSM-CC berichten, . . . ) of het laden van de verschillende ES, PSI en SI op het medium. Hoofdstuk 3 bespreekt de werking van de R&S componenten.
Met de verzamelde informatie kon de ontwikkeling van de playoutmanager voor iDTV starten. Een software architectuur werd ontworpen (Hoofdstuk 4) en ge¨ımplementeerd. Hoofdstuk 5 bespreekt enkele implementatie-details.
Ik heb gekozen om het systeem te ontwikkelen in C# met Visual Studio .NET. Het lijkt zeer onlogisch om, in een op Java gebaseerde MHP-wereld, te werken met een andere ontwikkelomgeving. Maar een playoutsysteem staat buiten DVB Java en MHP. Opstellen van PSI/SI, uitvoeren van processen en gebruik van XML is niet gebonden aan een ontwikkelomgeving of programmeertaal. Deze kan dus vrij gekozen worden. Mijn motivatie voor C# is gebaseerd op: Een uitgebreide ervaring in het ontwikkelen met C# en Visual Studio .NET. De vele grafische mogelijkheden van applicatie-ontwikkeling in .NET. De uitgebreide mogelijkheden om met XML, XML-schema’s en datasets te werken.
7
De Object Carrousel en Streamer vormen samen een carrousel. De streamer verstuurt de periodiek herhaalde
data naar de datainserter over ethernet.
Hoofdstuk 2
Program Specific Information en Service Information Om een playoutsysteem te implementeren moet er metadata over de TS’en worden opgesteld. Deze informatie is gestandaardiseerd door meerdere specificaties. Men gebruikt de MPEG ISO/IEC 13818-1 [1] specificatie om informatie over de elementaire stromen, over de onderlinge groepering en structuur te geven. Verder geeft deze specificatie details omtrent het fysieke netwerk waarover de stromen worden verstuurd. De DVB ETSI EN 300 468 specificatie [2] beschrijft de informatie nodig bij het versturen van digitale televisie. Men stelt tabellen op om o.a. de programmering van een individuele zender te beschrijven en services te detailleren. Door MHP ETSI TS 101 812 [3] wordt applicatiesignalisatie toegevoegd met behulp van een Application Information Table (AIT). Deze beschrijft welke applicaties er zich binnen een programma bevinden. ETR 211 [4] behandelt het eigenlijke gebruik van de SI. Het beschrijft o.a. het gebruik van descriptoren, sectie-opdeling en -nummering, . . .
Dit hoofdstuk bespreekt enkel de belangrijkste tabellen en descriptoren voor de playoutmanager. Een uitgewerkt voorbeeld verduidelijkt het gebruik van de descriptoren en de tabellen.
De verschillende tabellen zijn eigenlijk maar een conceptueel begrip. Ze moeten nooit volledig heropgebouwd worden door een decoder omdat deze secties verwerkt. Een sectie kan men vergelijken met een subtabel van de hele PSI/SI tabel. De verschillende specificaties defini¨eren de syntax van de secties en niet van de ganse tabel. Secties kunnen de grenzen van een TS-pakket (zie paragraaf 3.4.2 en [1, paragraaf C.2]) overschrijden (184 bytes) en men moet ze hierdoor
7
Hoofdstuk 2. Program Specific Information en Service Information
8
opsplitsen in meerdere MPEG-2 TS-pakketten. Een sectie kan maximaal 1024 (210 ) bytes groot zijn. De eerste 2 bits van het section length veld zijn vast ‘00’. EIT-secties vormen een uitzondering: deze mogen de volledige sectielengte benutten (4096 bytes). Secties werden ingevoerd om enerzijds de decoder te ontlasten met het verwerken van grote tabellen en anderzijds om gemakkelijk private data-secties te kunnen toevoegen; de decoder verwerkt de private data zoals de andere secties. Elke sectie heeft een aantal vaste velden: Het table id veld definieert het soort tabel. Het section number veld geeft het volgnummer van de sectie aan. Er kunnen 28 opeen-
volgende secties zijn binnen eenzelfde definitie-groep. Een groep wordt door verschillende id’s bepaald afhankelijk van het soort tabel. Het last section number veld definieert het volgnummer van de laatste sectie. Het version number veld duidt de versie van de tabel aan. Het current next indicator veld is ´e´en bit dat aangeeft of de huidige tabel al toepasbaar
is. M.a.w. of de set-top box de tabel kan aanvaarden. Wanneer in de sectiedefinities van de verschillende tabellen descriptor() voorkomt, wil dit zeggen dat er geen of meerdere descriptoren kunnen voorkomen op die positie binnen de tabelsectie. Een descriptor is gestructureerde informatie. De betekenis van de descriptoren is afhankelijk van zijn descriptor tag.
2.1
Program Specific Information
Een set-top box heeft metadata nodig om de TS te demultiplexeren. Met behulp van drie verplichte tabellen is de set-top box voorzien van genoeg informatie om de TS te ontleden. De Program Association Table bevat de definitie van de services in de TS. De Program Map Table geeft een gedetailleerd overzicht van de servicestructuur. De Network Information Table (NIT) definieert de fysieke organisatie van de TS’en en
netwerk-afhankelijke gegevens.
Hoofdstuk 2. Program Specific Information en Service Information
2.1.1
9
Program Association Table
De PAT wordt met PID 0x0000 en table id 0x00 verzonden. Figuur 2.1 toont de structuur van een sectie. Via een programmalus worden de verschillende programma’s opgegeven. Met een program number en program map PID is een service uniek gedefinieerd en de koppeling naar de service’s PMT opgegeven. De set-top box weet nu waar het de verschillende PMT’s moet zoeken om hun ES’s te vinden. Bij de sectienummering worden geen extra id’s gebruikt, enkel de vaste table id.
Figuur 2.1: Een sectie van de PAT. Bron: [1, paragraaf 2.4.4.3]
2.1.2
Program Map Table
Een service omvat verschillende ES’en. Audio, video en/of data kunnen deel uitmaken van een service. De PMT (table id 0x02) vertelt de set-top box waar en welke ES’s er zich in de service bevinden. Figuur 2.2 geeft de structuur van een PMT-sectie weer. Een ES wordt door een PID uniek gedefinieerd. Het stream type veld bepaalt het type element, bijvoorbeeld 0x0A geeft een object carrousel datastroom aan met Digital Storage Media Command and Control (DSM-CC) berichten volgens ISO/IEC 13818-6 type A [in 1, Tabel 2-36]. Descriptoren in de program info loop gelden voor heel de service. Bij elke ES hoort een aantal descriptoren die worden verzameld in de ES-info loop. De PMT gebruikt geen onderverdeling in secties. De
Hoofdstuk 2. Program Specific Information en Service Information
10
velden voor de sectienummering zijn toch gedefinieerd om de algemene definitie van een sectie te respecteren. Een programmadefinitie moet dus in ´e´en sectie opgesteld worden. Indien dit niet kan, moet er een ander programma in de PAT opgemaakt worden.
Figuur 2.2: Een sectie van de PMT. Bron: [1, paragraaf 2.4.4.8]
De volgende descriptoren worden rechtstreeks ondersteund in de playoutmanager: De Application Signalling Descriptor wordt gebruikt bij ES’en met als type 0x05. De ES
bevat dan een AIT. De Data Broadcast Id Descriptor identificeert het type datacomponent en kondigt een
data-ES aan. De Stream Identifier Descriptor dient om de identificatie van de ES’en, binnen een TS,
niet enkel afhankelijk te maken van de PID. Het koppelt een component tag aan de ES waarnaar andere descriptoren kunnen verwijzen.
Hoofdstuk 2. Program Specific Information en Service Information
11
De Private Data Specifier Descriptor wordt gebruikt om velden en descriptoren buiten de
standaard toe te laten. De Carousel Id Descriptor bevat extra identificatie velden voor een object carrousel. De Video Stream Descriptor deelt parameters mee voor het decoderen van een videostroom. De Audio Stream Descriptor geeft parameters voor het decoderen van een audiostroom. De Maximum Bitrate Descriptor definieert de maximale bitsnelheid van een videostroom. De ISO 639 Language Descriptor specificeert de gebruikte taal bij het geassocieerde pro-
grammaelement.
2.1.3
Network Information Table
De NIT geeft informatie over de fysieke organisatie van de TS’en en over de specifieke netwerkkarakteristieken. Men maakt een onderscheid tussen de huidige TS (actual network ) en die van een ander netwerk (other network ). Dit onderscheid wordt gemaakt door een verschillende table id te hanteren, 0x40 duidt het actuele netwerk en 0x41 een ander netwerk. Figuur 2.3 geeft een NIT-sectie weer. Een TS wordt door de combinatie original network id , transportstream id en network id uniek ge¨ıdentificeerd. Onder PID 0x0010 verstuurt men de NIT naar de set-op boxen. Net zoals de PMT bevat de NIT een zogenaamde common loop, die descriptoren bevat geldig voor het ganse netwerk, en een transportstream loop met de TS afhankelijke descriptoren. De eerste sectie zal het sectienummer 0x00 hebben. Het sectienummer zal verhoogd worden met elke volgende sectie met eenzelfde network id en table id [2, p. 17]. Aangezien de testopstelling in het labo uit een kabelnetwerk bestaat, zullen de descriptoren hierop afgestemd worden. De playoutmanager ondersteunt de volgende descriptoren: De Network Name Descriptor geeft de naam van het netwerk door. De Service List Descriptor geeft een lijst van de services via de service id’s en service types
mee. De Cable Delivery System Descriptor is een descriptor van 13 bytes die parameters over
het kabelnetwerk bevat. Door een vast aantal bytes te nemen voor de delivery system descriptoren, kan men gemakkelijk overschakelen tussen verschillende systemen door de bytes te verwisselen en de Cyclic Redundancy Check (CRC) te herberekenen.
Hoofdstuk 2. Program Specific Information en Service Information
12
Figuur 2.3: Een sectie van de NIT. Bron: [2, paragraaf 5.2.1]
2.2
Service Information
Tot hiertoe heeft de gebruiker zelf niet veel extra bruikbare informatie over de verschillende services. De set-top box is nu enkel in staat om de services onderling te distanti¨eren en om op de verschillende services te tunen. Met de SI wordt de bestaande metadata uitgebreid en beschikt de set-top box over extra informatie en beschrijvingen die niet tot het louter demultiplexeren bijdragen. De Service Description Table (SDT) geeft informatie over de services in de TS. De Event Information Table (EIT) kan de verschillende ES’s opdelen in events en hierover
extra informatie (tekstbeschrijvingen, type inhoud, . . . ) meegeven. Deze tabellen zijn een bron van informatie voor de EPG’s en andere applicaties.
2.2.1
Service Description Table
De SDT beschrijft elke service binnen een bepaalde TS. Net zoals de NIT heeft de SDT twee soorten tabellen: een actual en een other SDT, met respectievelijk 0x42 en 0x46 als table id .
Hoofdstuk 2. Program Specific Information en Service Information
13
De SDT wordt onder de PID 0x0011 verstuurd. Elke SDT-sectie, figuur 2.4, heeft een EIT schedule flag en EIT present following flag, die de ontvangers vertellen welke eventinformatie er beschikbaar is. De running status duidt de huidige status van de service weer; bijvoorbeeld pausing, running, . . . Free CA Mode geeft aan of de toegang tot de service via een Conditional Access (CA) systeem verloopt. Een sectienummer wordt verhoogd, startend met 0x00, met elke volgende sectie met eenzelfde table id, transportstream id en original network id . De playoutmanager implementeert de volgende descriptoren:
Figuur 2.4: Een sectie van de SDT. Bron: [2, paragraaf 5.2.3]
De Service Descriptor deelt naast de naam van de service en van de service provider, ook
het type service mee. De Service Identifier Descriptor geeft een tekstuele beschrijving van de service. De Country Availability Descriptor identificeert in welke landen de service beschikbaar of
onbeschikbaar is, afhankelijk van de country availability flag. De Data Broadcast Descriptor verzorgt een beschrijving van een datacomponent. Naast
een tekstuele beschrijving, worden selector bytes meegegeven. De structuur van deze bytes is afhankelijk van de data broadcast id .
Hoofdstuk 2. Program Specific Information en Service Information
14
De Private Data Specifier Descriptor , net zoals in paragraaf 2.1.2. De Telephone Descriptor wordt toegevoegd wanneer men met een modem of narrowband
kanaal werkt. De Bouquet Name Descriptor geeft de naam van het bouquet1 waartoe de service behoort
door.
2.2.2
Event Information Table
De EIT geeft informatie, in chronologische volgorde, over de events in elke service. Er zijn 4 classificaties: De Actual TS, present/following event informatie, onderscheidbaar door table id 0x4E. De other TS, present/following event informatie, onderscheidbaar door table id 0x4F. De actual TS, event schedule informatie, onderscheidbaar door table id’s 0x50 tot 0x5F. De other TS, event schedule informatie, onderscheidbaar door table id’s 0x60 tot 0x6F.
Door het grote aantal table id’s ziet men duidelijk dat de ganse EIT een zeer grote tabel kan worden. Per table id (buiten de present/following table id’s) zijn er 256 secties die zelf 4096 bytes groot kunnen zijn. Dit geeft 1048576 bytes. Met de 34 mogelijke table id’s spreekt men over ongeveer 35 Mbytes voor ´e´en service. Aangezien de sectienummering ook nog afhankelijk is van de service id, transportstream id en original network id , kan een EIT grote proporties aannemen. Men verhoogt het sectienummer enkel bij opeenvolgende secties met eenzelfde table id, service id, transport stream id en original network id . Per subtabel (256 secties) worden de secties in 32 segmenten van 8 secties onderverdeeld. Een segment is goed voor eventinformatie van een periode van 3 uur. Het segment last section number geeft het sectienummer van de laatste sectie in het segment. Een voorbeeld ter verduidelijking: segment 2 bevat slechts 2 secties, het segment last section number veld zal de waarde 8 (segment 1) + 2 (segment 2) - 1 (starten van 0) = 9 hebben [4, paragraaf 4.1.4.2]. Het opdelen in secties versnelt de processing in de decoder aanzienlijk en vermindert het geheugenverbruik. 1
Een verzameling van services die samen het bouquet vormen. De groepering kan over de grenzen van een TS
gaan.
Hoofdstuk 2. Program Specific Information en Service Information
15
Figuur 2.5: Een sectie van de EIT. Bron: [2, paragraaf 5.2.4]
De present/following EIT zal slechts 2 events bevatten, namelijk het huidige event en het daarop volgende event. Elk event wordt in een verschillende sectie verstuurd. Uitgebreidere event informatie kan door de event schedule EIT’s worden verzorgd. Het stelt een lijst op, in chronologische volgorde, van meerdere events. Elke EIT-sectie, figuur 2.5, zal verzonden worden met de PID 0x0012. De transport stream id , original network id en service id identificeren de betrokken service. De playoutmanager ondersteunt de volgende descriptoren: De component descriptor identificeert het type van ES en geeft een tekstuele beschrijving. De content descriptor geeft classificatie-informatie over het event volgens een vaste tabel.
[in 2, Tabel 28] De short event descriptor geeft een korte beschrijving van het event. De extended event descriptor verzorgt een uitgebreidere versie van de short event descrip-
tor . Meerdere instanties van deze descriptor kunnen in ´e´en event-descriptorlus omvat worden. De parental rating descriptor stelt richtlijnen op, per land, omtrent de leeftijdscategorie.
Hoofdstuk 2. Program Specific Information en Service Information
2.2.3
16
Andere tabellen
DVB definieert nog meer tabellen maar deze zijn voor de huidige testopstelling overbodig. Wat volgt is een korte opsomming van de tabellen, extra informatie omtrent hun structuur kan gevonden worden in [2, Paragraaf 5.2 en 7.1]. - Een Bouquet Association Table (BAT) zorgt voor de opstelling van bouquets en wordt verzonden onder de PID 0x0011 met table id 0x4A. - Een Running Status Table (RST) geeft de broadcaster een manier om snel en accuraat een update door te voeren van de running en timing statussen van de events op het netwerk. Deze wordt verzonden onder de PID 0x0013 en table id 0x71. - Een Time and Date Table (TDT) bevat enkel informatie over de UTC2 tijd en datum en wordt verzonden onder de PID 0x0014 en table id 0x70. - Een Time Offset Table (TOT) draagt de UTC tijd en datum en de lokale offset. Het is een uitbreiding van de TDT. De PID en de table id moeten respectievelijk 0x0014 en 0x73 zijn. - Een Stuffing Table (ST) wordt gebruikt om een bestaande sectie te invalideren bij een delivery system grens, bijvoorbeeld bij een kabel head-end. Als een sectie van een subtabel wordt overschreven, dan zullen alle secties van de subtabel ook worden overschreven. Zo wordt de integriteit van de sectienummers behouden. - Een Discontinuity Information Table (DIT) moet worden toegevoegd op overgangspunten waarbij de SI discontinu kan worden. - Een Selection Information Table (SIT) beschrijft de service(s) en event(s) gedragen door een “parti¨ele TS”. Een parti¨ele TS zal geen SI tabellen bevatten buiten de SIT en de DIT. De PSI zal enkel een PAT en PMT bevatten om de stromen correct te beschrijven binnen de parti¨ele TS. 2
UTC staat voor Universal Time Coordinated waarbij UT de eigenlijke afkorting is met de toevoeging dat
het hier om co¨ ordinaat-afhankelijke tijdsweergave gaat. Het wordt ook “Zulu time” genoemd. Voluit wordt UTC meestal Coordinated Universal Time genoemd. Het is bijna gelijk aan wat vroeger GMT (Greenwich Mean Time) werd genoemd. UTC is echter een atoomtijd, terwijl GMT een astronomische tijd is. Via een 40 bits veld wordt de tijd en datum doorgegeven. De datum is in Modified Julian Date (MJD) gecodeerd en de 16 Least Significant Bits worden genomen. De tijd stelt men voor als zes cijfers (xx:xx’:xx”) van vier bits gecodeerd volgen Binary Coded Decimal (BCD).
Hoofdstuk 2. Program Specific Information en Service Information
2.3
17
Signalisatie van applicaties
Met de gegeven PSI en SI beschikt de set-top box over informatie om op een service af te stemmen en te kijken welke events er zijn. Voor audio en video is er verder geen extra metadata nodig. Voor applicaties is dit echter anders. De set-top box heeft informatie nodig over de locatie, het type, de code bestanden enz. van de applicaties. ETSI TS 101 812 [3] lost dit op door application signalling in te voegen. Via de Application Information Table zal de nodige metadata aan de decoder doorgeven worden om applicaties te kunnen uitvoeren op het MHP platform.
2.3.1
Application Information Table
De AIT geeft de begeleidende informatie voor het uitzenden van applicaties. Elke applicatie, in de service, heeft een descriptorlus in de AIT. De decoder beschikt, via de AIT, over de nodige parameters om de applicatie uit te voeren, indien deze het applicatietype natuurlijk ondersteund. Elke applicatie bevat een application identifier . Het bevat een application Id en een organisation Id . Figuur 2.6 toont de structuur van een AIT sectie. De tabel wordt met table id 0x74 verzonden en met de PID opgegeven in de PMT (application signalling descriptor ). Een AITsectie heeft een common descriptors loop dat descriptoren bevat die voor elke applicatie gelden. Een application loop maakt het mogelijk de verschillende applicaties te defini¨eren. De status van een applicatie wordt door de application control code (Autostart, present, . . . ) doorgegeven. Sectienummering is afhankelijk van de table id en van het type applicatie. Een sectienummer zal verhoogd worden met elke volgende sectie met eenzelfde table id en applicatietype. Bijna elke descriptor, gespecificeerd in [3, paragraaf 10], wordt ge¨ımplementeerd door de playoutmanager. Enkel de IP-routing descriptoren zijn niet toegevoegd omdat de testopstelling uit een kabel infrastructuur bestaat. De structuren zijn echter wel toegevoegd in het XML-schema van de AIT. De playoutmanager ondersteunt de volgende descriptoren: De Application Descriptor is een verplichte descriptor voor elk soort applicatie. Het profiel
van de applicatie wordt opgegeven om de decoder in staat te stellen na te gaan of het de applicatie kan uitvoeren. Een service bound flag duidt aan of de applicatie gekoppeld is aan een service. Een service bound applicatie wordt door de decoder gestopt als men van service wisselt. Verder worden de visbility, priority en transport protocol labels bijgevoegd.
Hoofdstuk 2. Program Specific Information en Service Information
18
Figuur 2.6: Een sectie van de AIT. Bron: [3, paragraaf 10.4]
De Application Name Descriptor geeft de naam van de applicatie door. Deze descriptor
is ook verplicht voor elke applicatie. De Application Icons Descriptor laat toe om iconen te associ¨eren aan applicaties. Via een
DVB icon locator [3, pagina 88 e.v.] wordt een icoon gekoppeld aan de applicatie. De External Application Authorisation Descriptor definieert de applicaties die toestem-
ming krijgen om hun uitvoering voort te zetten bij het zappen. De Transport Protocol Descriptor definieert het gebruikte transportprotocol bij de appli-
catie en geeft protocol afhankelijk informatie door. Via selector bytes kan men, afhankelijk van het protocol id , de nodige gegevens doorgeven. Met protocol id 0x0001 gaat het transport via een object carrousel, 0x0002 zegt dat het over IP gaat. Bij OC transport worden service id, transportstream id, original network id en component tag opgegeven om de data ES te identificeren in de TS. De Prefetch Descriptor wordt gebruikt bij het OC transport. Het duidt aan welke modules
Hoofdstuk 2. Program Specific Information en Service Information
19
belangrijker zijn en die dan eventueel een voorkeursbehandeling krijgen. De DII Location Descriptor
3
maakt een lijst op van de extra DII berichten om de modules,
gespecificeerd in de prefetch descriptor , te kunnen ophalen. De default DII berichten komen hier niet in voor [5][p. 79 e.v., hoofdstuk 12]. De DVB-J Application Descriptor geeft parameters door bij het gebruik van een DVB
Java applicatie. De DVB-J Application Location Descriptor wordt gebruikt om de base directory, classpath
en initial class door te geven aan de decoder. De DVB-HTML Application Descriptor beschrijft de DVB-HTML specifieke parameters. De DVB-HTML Application Location Descriptor geeft de fysieke locatie, op het transport-
medium, van de applicatie. De physical root en initial path worden doorgegeven. De DVB-HTML Application Boundary Descriptor is een optionele descriptor die zorgt voor
de aflijning van een applicatie. Via een algemene expressie beschrijft het de dataelementen die de applicatie vormen.
2.4
PSI en SI, een uitgewerkt voorbeeld
Als voorbeeld4 wordt een TS opgemaakt met twee verschillende programma’s. De eerste service zal een audio- en videostroom bevatten, de andere zal een data-ES (met een DVB Java applicatie) hebben en daarbij ook een stroom voor de AIT. Eerst starten we met het opstellen van de PAT. Figuur 2.7 geeft een overzicht van wat er werd geconfigureerd. We voegen twee programma’s toe aan de programmalus van de PAT. De eerste PMT krijgt PID 0x0020 en de andere 0x0030, de programmanummers zijn respectievelijk 0x0001 en 0x0002. Het programma met nummer 0x0000 geeft de NIT aan en kan niet door een ander programma gebruikt worden. Paragraaf A.2.1 geeft de XML-voorstelling van de configuratie. Nu zijn er twee PID’s gereserveerd om voor elke service een PMT mee te sturen. Het defini¨eren van de inhoud van de service is de volgende stap. We starten met de eerste service die een audio3
Digital Storage Media Command and Control (DSM-CC) DownloadInfoIndication (DII) berichten vertellen
de ontvanger welke DSM-CC modules de carrousel opmaken. 4 Extra voorbeelden van PSI en SI DVB snoop protocol analyser tool, http://dvbsnoop.sourceforge.net
Hoofdstuk 2. Program Specific Information en Service Information
20
Figuur 2.7: Overzicht van het voorbeeld
en videocomponent bevat. Twee stromen worden toegevoegd met type 0x02 (H.262, ISO/IEC 13818-2 Video, ISO/IEC 11172-2) voor de video en type 0x04 (ISO/IEC 13818-3 Audio) voor de audio. We moeten ook een ES PID opgegeven: voor de video 0x0021 en audio 0x0022. Voor de videostroom defini¨eren we een video stream descriptor , een maximum bitrate descriptor en een stream identifier descriptor (Component tag 0x01), en voor de audiostroom een audio stream descriptor , een ISO 639 language descriptor (ISO 639 language code: deu; Audio type: 0x01, clean effects) en een stream identifier descriptor (Component tag 0x02). De andere service bevat een data-ES (PID 0x0031), met het type 0x0b (DSM-CC, object carrousel). Bij deze stroom moet er een data broadcast Id descriptor
5
en een carousel identifier
descriptor toegevoegd worden. Een stream identifier descriptor (Component tag 0x03) is niet verplicht, maar is wel voorzien omdat de transport protocol descriptor in de AIT ernaar verwijst. 5
Dit is eigenlijk de MHP data broadcast id descriptor waarbij de id specific data ingevuld wordt met de
applicatietypes. De broadcast id 0x00F0 duidt op een MHP object carrousel. Een gewone object carrousel krijgt de data broadcast id 0x0007.
Hoofdstuk 2. Program Specific Information en Service Information
21
De data-ES is niet genoeg om de applicatie door de set-top box te laten uitvoeren. We moeten een AIT toevoegen en dit doen we door nog een stroom te defini¨eren met type 0x05 (H.222.0 private sections, AIT)(PID 0x0032). Bij deze stroom hoort een application signalling descriptor (application type 0x0001 DVB Java) om te zeggen dat de inhoud van de stroom een AIT zal zijn. Paragraaf A.2.2 geeft de XML-voorstelling van de PMT’s. De TS is nu opgebouwd uit ES’en. Enkel de extra gegevens voor de set-top box moeten nog doorgegeven worden. De tweede service bevat ´e´en DVB Java applicatie, in de AIT zal dus maar ´e´en applicatie gedefinieerd zijn. Het application type veld in de AIT wordt 0x0001 voor DVBJava. Verder zal de applicatie automatisch starten (application control code 0x01) en moeten de volgende descriptoren aanwezig zijn: een application descriptor (het transport protocol label identificeert de gebruikte transport protocol descriptor binnen de AIT sectie), een application name descriptor , een transport protocol descriptor , een DVB-J application descriptor en een DVB-J application location descriptor . Paragraaf A.2.3 geeft de XML-voorstelling van de AIT. Al de gegevens van de ES’en zijn ingevuld, nu moeten we de TS vervolledigen met de NIT, SDT. De NIT zal slechts ´e´en TS (original network id 0x0001, transportstream id 0x0001) bevatten met een service list descriptor . De descriptor bevat een lijst van service id’s die dezelfde waarden hebben als de programmanummers in de PAT (service id’s, 0x0001 en 0x0002; service types 0x01 digitale televisie service en 0x10 DVB MHP service). Paragraaf A.2.4 geeft de XML-voorstelling. De SDT definieert twee services met telkens een service descriptor . Het service type komt overeen met de gedeclareerde types in de NIT service list descriptor . Per service wordt er enkel een EIT-tabel met present/following secties meegegeven (EIT present following 0x1 en EIT schedule flag 0x0). De services worden niet gescrambled (Free CA mode 0x0). De SDT XML-voorstelling wordt in paragraaf A.2.5 getoond. Per ES kunnen er verschillende events opgemaakt worden in de EIT. De koppeling van event en ES maakt men door de component descriptor . Deze geeft de ES op d.m.v. de component tag, gedefinieerd door de stream identifier descriptor in de PMT van de ES. In dit voorbeeld zullen we enkel de present/following EIT, actual TS opmaken, zoals gedefinieerd in de SDT, en een nieuwe sectie starten bij elk event. De twee events in de EIT starten respectievelijk op 12:00:00 en 13:00:00 op 8-4-2006. Deze velden worden op een speciale manier gecodeerd: Modified Julian Date [2, Annex C]. Bij het eerste event zal er een extended event descriptor en een short event descriptor opgegeven worden. Voor het tweede event worden, naast een short event descriptor ,
Hoofdstuk 2. Program Specific Information en Service Information
22
twee component descriptors toegevoegd die verwijzen naar de volgende ES’en: De audiostroom
component tag 0x02; stream content en component type vormen samen: audio/stereo, 2 channels [2, Tabel 26] De videostroom
component tag 0x01; stream content en component type vormen samen: video, 4:3 aspect ratio, 25 Hz short event descriptor toegevoegd. Paragraaf A.2.6 geeft de XML-voorstelling van de EIT. Meer uitleg omtrent de structuur van de descriptoren vindt men in [1, paragraaf 2.6], [2, paragraaf 6.2] en [3, vanaf paragraaf 10.7]. Meer informatie over het gebruik van de SI kan men vinden in [4]. Vele velden van de descriptoren hebben vaste waarden volgens verscheidene tabellen. Al deze mogelijkheden vallen buiten de scope van deze thesisbundel.
Hoofdstuk 3
Rohde & Schwarz componenten Dit hoofdstuk behandelt de configuratie in het testlabo van de R&S oplossing. Via een “Wizard” stelt men de PSI en SI op en worden de nodige object carrousels en object streamers aangeroepen.
Figuur 3.1: Een beknopte voorstelling van de testopstelling
Een carrousel zorgt voor het periodiek herhalen van een gegeven directory op de desktop PC. De streamer verstuurt de carrousel data naar de DataInserter (DI). Er wordt gewerkt via multi protocol encapsulling: de streamer neemt de TS-pakketten van de OC (DSM-CC) en verstuurt ze naar de DI in TCP/IP-pakketten. De DI zal de pakketten decapsuleren en op het kabelnetwerk doorsturen. Figuur 3.1 toont een eenvoudige voorstelling van de testopstelling. Per R&S component zullen de configuratie mogelijkheden besproken worden en hun relevantie bij de playoutmanager.
23
Hoofdstuk 3. Rohde & Schwarz componenten
3.1
24
Object Carrousel
De OC wordt door carousel.ini geconfigureerd . Bijlage C.1 geeft het originele configuratiebestand. Carousel.ini behandelt de directory tree reader service
1
configuratie. Enkel Carousel-
Number, Port, DirTreeRoot zijn relevant voor de playoutmanager. CarouselNumber definieert het nummer van de carrousel. Meerdere carrousels op een machine moeten een verschillend nummer hebben. Port definieert de poort waar de carrousel beschikbaar is voor de Object Streamer. Deze is 5000 plus het carrouselnummer. DirTreeRoot moet het volledige path bevatten van de locatie van de data-pool op de lokale computer. Verder moet de RemoteControlPort nog aangepast worden naar 5100 plus het carrouselnummer, om een volledig correcte bestand te verkrijgen.
3.2
Object Streamer
De OS wordt via de ObjectStreamer.ini geconfigureerd, bijlage C.3. PortSource bevat het poortnummer waarop de carrousel beschikbaar is, 5000 + carrousel-nummer. Het IP-adres van de machine met object carrousel wordt aangegeven door het AddrSource veld. De volgende drie Port velden bevatten respectievelijk de poorten van de algemene bestemming, de mediarouter en de DI. Het eerste en laatste zijn belangrijk voor de playoutmanager. Deze specificeren, samen met de volgende Addr velden, de bestemming waarnaar de OS zijn pakketten moet sturen. AddrDest en AddrDI moeten dus op 192.168.30.40 staan (IP-adres van de DI). ChooseRouterInterface duidt aan welke bestemming er gebruikt moet worden (0 voor de datainserter). De velden InitSourceDir en SourceDirsList bevatten de submappen die de OS naar de DI verzendt . De laatste parameters zeggen welke carrousel er gebruikt moet worden als source. De PID wordt gebruikt als MPEG-2 TS PID van alle objecten in de carrousel. Het CarouselId veld geeft de ID van de carrousel binnen de MPEG-2 TS. De AssociationTag linkt alle objecten binnen de object carrousel, onafhankelijk van de elementary PID (pid veld). De waarde van dit veld komt overeen met de component tag van de overeenkomstige stream identifier descriptor van de datastroom. De parameters, die niet via de grafische interface van de R&S OS instelbaar zijn, worden gebundeld in ObjectCarousel.ini, bijlage C.2. De CarouselId, AssociationTag en ElementaryPID zijn dezelfde die geconfigureerd werden als in ObjectStreamer.ini. De velden Transaction Id, 1
Het broadcasten van een volledige directory-structuur.
Hoofdstuk 3. Rohde & Schwarz componenten
25
Blocksize, Module Id en Object Key kunnen ongewijzigd blijven.
3.3
DataInserter
Het opstellen van een TS wordt door de DI gedaan. Als input krijgt het een binair bestand van de PSI en SI tabellen, en een configuratiebestand dat de werkwijze van de DI bepaalt. Er zijn twee soorten operatiemodi: inserter en generator . De inserter modus voegt de nieuwe informatie toe bij de TS op de DI’s input. Elke tabel van de PSI en SI wordt door de DI bewerkt en gegenereerd om een correcte samengevoegde TS te krijgen. De andere modus leest de tabellen in en bouwt zo een eigen TS (zonder een input TS) op. De generator is de bruikbare modus voor de playoutmanager om een hele TS op te bouwen. De inserter.ini, in bijlage C.4, bestaat uit verschillende gebieden die geldig zijn bij een bepaalde modus. De voornaamste velden die gewijzigd moeten worden zijn: InsGen duidt aan in welke mode de DI moet werken. Voor generator komt hier de waarde
“Gen”. PCRPID geeft de PID op van de program clock reference. NumberOf zegt hoeveel tabellen de DI moet genereren. TablesFile bevat de naam van het .trp-bestand die de opgebouwde PSI en SI tabellen
bevat. De DI plaatst alle MPEG2 TS-pakketten, met PSI en SI secties, zonder enige controle op de TS. SDTOn, NITOn, EITOn en AITOn kunnen de waarden 0 of 1 hebben en zeggen welke
tabellen er moeten gegenereerd worden.
3.4
Rohde & Schwarz Wizard
De basiscomponenten om een TS te broadcasten zijn opgemaakt. Men heeft nu enkel nog een applicatie nodig om enerzijds de gebruiker de PSI en SI te laten invullen en anderzijds om deze informatie door te geven aan de DI. De signalling information bestaat uit TS pakketten met als inhoud de binaire tabelsecties. Het invullen van de PSI en SI gebeurt d.m.v. MHPWizard.exe en de signalling door SigGen.exe.
Hoofdstuk 3. Rohde & Schwarz componenten
3.4.1
26
MHPWizard
Met deze applicatie kan men de nodige PSI en SI opstellen om ´e´en MHP applicatie op de TS te zetten. Men is er dus vanuit gegaan dat de DI enkel zal gebruikt worden om een MHP applicatie naar een set-top box te transporteren. De wizard zal dus voornamelijk de AIT en de PMT configureren om de data broadcast mogelijk te maken. Een EIT opstellen is niet rechtstreeks mogelijk via de wizard, men moet verschillende .inibestanden manueel aanpassen om zo tot een formulatie van een EIT te komen. Vervolgens moet men deze converteren naar de binaire voorstelling en doorgeven aan de DI via een manueel samengevoegd .trp-bestand. Dit is een omslachtige procedure en zeker niet gebruiksvriendelijk.
3.4.2
SigGen
Deze component zorgt voor de omzetting van de PSI en SI naar hun binair equivalent. Een table.trp bestand wordt aangemaakt in de homedirectory van de DI. Dit bestand bestaat uit volwaardige MPEG2 TS-pakketten. Een TS header is 4 bytes lang en heeft een vaste opdeling volgens figuur 3.2. Een adaptation field wordt niet gebruikt bij het opstellen van de header. De sync byte heeft een vaste waarde van 0x47. Transport error indicator geeft aan of er al dan niet een niet corrigeerbare biterror is voorgekomen in het TS-pakket (Default ‘0’). Een belangrijk veld is de payload unit start indicator dat aangeeft of een sectie in dit TS-pakket start. Indien dit het geval is moet er een pointer bijgevoegd worden die verwijst naar het begin van de sectie in het TS pakket. Verder moet de PID en de transport priority ingevuld worden. Transport scrambling control duidt aan of de payload van het TS-pakket gescrambled is. De continuity counter wordt telkens, voor opeenvolgende pakketten onder dezelfde PID, verhoogd. Dit is een doorlopende teller die herstart bij zijn maximum waarde (overgang van 15 naar 0). De decoder is nu in staat verloren pakketten te detecteren met behulp van deze teller. Het adaptation field control veld is standaard “01” [in 6, Paragraaf 11.2]. Al deze parameters kan men wijzigen in siggen.ini . De verschillende tabellen worden ook via .ini-bestanden aan de generator doorgegeven. De descriptoren worden in een apart bestand gestoken en allemaal samen gegroepeerd (NIT, SDT, PMT en AIT descriptoren). Een link tussen de descriptor en de betreffende tabel wordt via een indicatie in het .ini-bestand van de tabel gemaakt. Alle descriptoren worden dus samengenomen en de tabellen worden voorzien van koppelingen. Hoe men meerdere applicaties binnen een
Hoofdstuk 3. Rohde & Schwarz componenten
27
Figuur 3.2: De structuur van een TS header. Bron: [1, tabel 2.3]
service kan defini¨eren, is onduidelijk. Hoe men bijvoorbeeld de DVB-J application descriptors gaat onderscheiden in het gemeenschappelijke descriptor.ini bestand is niet af te leiden.
3.5
Besluit
De bedoeling van een wizard is om de gebruikersinvoer te beperken en zo snel mogelijk tot een oplossing te laten komen voor een specifiek gericht probleem. De MHPWizard tracht om snel een MHP applicatie te broadcasten naar de set-top box. Men moet met deze wizard veel instellen omdat de PSI en SI volledig dient opgesteld te worden. De gebruiker moet voortdurend op “next” drukken zonder enige wijzigingen aan te brengen. Een EIT-editor is niet voorhanden, maar deze tabel wordt wel ondersteund. Men kan een EIT manueel opstellen door de verschillende .ini-bestanden te wijzigen. Het manueel aanpassen van de .ini-bestanden vergt echter al heel wat kennis van de PSI/SI en de interne werking van de .ini-bestanden. De SigGen.exe stelt het binair formaat op van de tabellen maar hoe het zich over secties ontfermt, is niet duidelijk. Met de playoutmanager wordt een nieuwe tool opgebouwd om enerzijds PSI en SI te editeren en te genereren en anderzijds om de veel voorkomende gevallen snel en gemakkelijk uit te voeren.
Hoofdstuk 4
Architectuur In de cursus Software Architectuur [7] zijn er bepaalde methoden gedefinieerd om een architectuur op te stellen en te documenteren. Ik heb me gebaseerd op het proces Attribute Driven Design [7, paragraaf 7.2]. Dit proces gaat als volgt: eerst gaat men na welke attributen, afgeleid uit de vereisten, de architectuur het meest zullen be¨ınvloeden (architectural drivers), via deze in het achterhoofd tracht men het systeem te decompositioneren, startend met het globale systeem. Bij elke stap kiest men een architecturale driver relevant bij de decompositie en patronen die deze oplossen. Vervolgens instantieert men de modules en definieert men interfaces. De architectuur die volgt, is het resultaat van dit proces. Na een korte situering worden de vereisten van het systeem behandeld. Verder volgt een opsomming van de gekozen architecturale drivers en de patronen die deze oplossen. Daarna worden de verschillende modules bekeken met hun verantwoordelijkheden en als laatste de gekozen strategie¨en en tactieken. Hoofdstuk 5 bespreekt het ontwerp van de lay-out en de implementatie van enkele belangrijke componenten. Dit hoofdstuk focust zich op de globale softwarearchitectuur van de playoutmanager.
4.1
Mission statement
Het implementeren van een playoutmanager gebruikmakend van de bestaande software geleverd door R&S. Het opstellen van een frontend voor de DI, waarbij er enkele wizards dienen opgesteld te worden om de meest voorkomende taken te begeleiden.
28
Hoofdstuk 4. Architectuur
4.1.1
29
Hoofdkarakteristieken en belangrijke eigenschappen
Opstellen van een XML-beschrijving.
Via een XML-beschrijving van de PSI/SI (PAT, PMT, AIT, SDT, NIT, EIT en allen met descriptoren) configureert men de TS. Een EIT-editor moet zeker voorzien zijn. .ini-bestanden bewerken.
Om de hardware te kunnen configureren moet de manager de .ini-bestanden van de OC, OS en DI bewerken. Een signaalgenerator
Er moet een rechtstreekse vertaling komen van het XML-formaat naar het binaire formaat van de tabeldefinities. Opstarten van de OC, OS en DI.
Na de configuratie moeten de verschillende componenten uitgevoerd worden zodat het broadcasten kan beginnen. Invoegen van wizards voor de meest voorkomende taken.
Zoals in de R&S software voorzien is, moet de manager dergelijke wizards bevatten. Deze moeten echter duidelijker zijn en de gebruiker sneller tot een oplossing laten komen. Meerdere applicaties in ´e´en service.
Via de R&S software is het tot nu toe nog niet gelukt om een service met meerdere applicaties te broadcasten. Eerst gaat men testen of dit mogelijk is met de voorziene hardware en het moet dan ge¨ımplementeerd worden in de playoutmanager.
4.1.2
Bijkomende vereisten
De playoutmanager mag zich niet uitsluitend richten tot de R&S oplossing. M.a.w. het moet uitbreidbaar zijn naar een andere broadcasttechniek, met andere apparatuur. Mits er nu een DVB Playout Server (IRT1 ,V2.0) gekocht is, kan deze ook ge¨ıntegreerd worden in de playoutmanager.
4.2
Kwaliteitsattributen
Er bestaan ongeveer zes belangrijke systeemkwaliteitsattributen, namelijk: beschikbaarheid, wijzigbaarheid, performantie, testbaarheid, beveiliging en bruikbaarheid. Het systeem ligt aan 1
Institut f¨ ur Rundfunktechnik
Hoofdstuk 4. Architectuur
30
de broadcasters kant dat niet toegankelijk is voor de gebruikers. Beveiliging is altijd een belangrijk algemeen begrip, maar hier niet van toepassing. Beschikbaarheid en performantie vormen niet de belangrijkste attributen omdat het op een systeem met een grote performantie draait. Uitbreidbaarheid/wijzigbaarheid en bruikbaarheid zijn zeker van toepassing: men wil niet aan ´e´en producent vastzitten en het systeem moet natuurlijk handig in gebruik zijn.
4.2.1
Wijzigbaarheid
Men definieert interfaces voor de belangrijke modules. Alle modules, die interageren met hardware/software, worden geabstraheerd zodat deze
hardware/software eenvoudig vervangen kan worden door andere versies of door hardware/software van een andere producent.
4.2.2
Bruikbaarheid
Een logische en duidelijke volgorde van de taken moeten de gebruikers helpen het systeem
sneller onder de knie te krijgen en toelaten het systeem effici¨ent te gebruiken. De grafische lay-out moet gestructureerd en overzichtelijk zijn.
4.2.3
Architecturale driver
Wijzigbaarheid is de belangrijkste driver van de systeemarchitectuur. De meeste tactieken en patronen concentreren zich hierop.
4.3
Architecturale patronen
De architectuur van de playoutmanager heeft veel weg van een gelaagde structuur. Er vormen zich al logisch 2 lagen: de Grafische Interface en Hardware. Er werd voor de naam “Hardware” gekozen omdat de playoutmanager een frontend vormt voor de DI, een hardware component. Verder moet er nog een laag voorzien worden om de XML-functionaliteiten te bundelen. De hardwarelaag implementeert het patroon of style van een virtual machine. Met tracht de hardware/software componenten te abstraheren zodat eventuele wijzigingen in de componenten of configuratie mogelijkheden, een minimaal effect hebben op andere modules. Bij de beschrijving van de verschillende modules zal de werking verder uitgelegd worden.
Hoofdstuk 4. Architectuur
4.4 4.4.1
31
Opstellen van modules Gelaagde structuur
De playoutmanager bestaat uit een hardwarelaag die opdrachten ontvangt van de grafische user-interface (GUI). De hardwarelaag verzorgt de integratie van de R&S componenten in de playoutmanager. De GUI communiceert met de hardwarelaag via de BusinessLogic klasse, dat in de GUI is opgenomen. De XML-laag wordt aangeroepen om de PSI en SI tabellen op te stellen. Deze tabellen worden doorgegeven aan de hardwarelaag die de OS, OC en DI instelt. De hardwarelaag raadpleegt de XML om de nodige informatie te verkrijgen. De beide lagen gebruiken de XML-laag en deze biedt een gemeenschappelijke dienst aan. Het staat dus eigenlijk buiten de lagenstructuur en overlapt de andere twee lagen.
Figuur 4.1: De hoofdstructuur van de playoutmanager.
Naast de pure logica van het systeem bestaat er nog een console applicatie dat de verschillende lagen kan testen. Dit is ingevoerd om, tijdens de ontwikkeling van de verschillende lagen, reeds tussentijdse testen te kunnen uitvoeren. Figuur 4.1 geeft het lagen model. Men ziet de 2 hoofdlagen Graphical user interface en de Hardware die gebruik maken van de gemeenschappelijke XML-laag. Buiten het hele systeem staat de Test Console Application voor het evalueren van de aparte lagen.
4.4.2
Module Decomposition View
Per laag wordt er top-down verder opgesplitst. Hierbij starten we vanaf figuur 4.1.
Hoofdstuk 4. Architectuur
32
GUI De GUI bestaat uit twee pakketten en een klasse. Het Displayer -pakket verzorgt het hoofdvenster en de invoer van de PSI en SI door de gebruiker. Het bestaat uit verschillende vensters en dialogen. De implementatie van de wizards wordt in het Wizard -pakket samengebracht. De klasse BusinessLogic spreekt de hardware/software componenten aan, in opdracht van de Displayer . De BusinessLogic roept ook de verschillende wizards aan die dan de TS configureren volgens hun doel. Later wordt de controle terug aan de BusinessLogic en dan aan de Displayer gegeven. Zo kan de gebruiker nog wijzigingen aan de TS-configuratie maken alvorens de configuratie uit te voeren.
Figuur 4.2: De GUI.
Wizard De wizard bestaat niet enkel uit een paar formulieren/vensters. Het bevat ook een klasse Pre Config dat zorgt voor het opstellen van de TS en het aanroepen van de juiste formulieren om gebruikersinvoer mogelijk te maken. Het geeft een Transport stream klasse, van de XML-laag, terug aan de BusinessLogic. Het hoofdvenster van de Displayer zal met deze nieuwe TS-configuratie getoond worden. De interface IPre Config moet ge¨ımplementeerd worden door elke wizard. Naast het uitvoeringscommando Run() zijn er nog 3 andere methoden die de geconfigureerde TS, de Carrousel Id’s en de OC bronmapnamen teruggeven. Hardware Er is een logische opdeling, volgens component, in deze laag: een Object Streamer-, Object Carousel- en Data Inserter -pakket, figuur 4.4. Telkens worden er methodes voorzien om de compo-
Hoofdstuk 4. Architectuur
33
Figuur 4.3: De Wizard structuur.
nenten te starten en de juiste .ini-bestanden te configureren.
Figuur 4.4: De Hardware laag.
Het OS-pakket, figuur 4.5, moet ObjectStreamer.ini configuren. Het bestand wordt gemapt aan de klasse OS ini Object Streamer configuration dat getters en setters voorziet voor elke parameter in dit bestand. De OS klasse zelf staat in voor het oproepen van de executable van de OS en het wegschrijven en inlezen van ObjectStreamer.ini.
Figuur 4.5: Het OS pakket.
Eenzelfde stramien wordt gevolgd voor de OC, figuur 4.6. Een OC klasse voor het oproepen van de executable, het wegschrijven en inlezen van de twee .ini bestanden: carousel.ini en ObjectCarousel.ini. Deze hebben elk een gemapte klasse met getters en setters voor de verschillende parameters. Het DI pakket is uitgebreider. Naast een configuratie file, via DI ini inserter configuration, moet er ook de table.trp gegenereerd worden. De hoofdklasse DI roept de onderliggende klassen
Hoofdstuk 4. Architectuur
34
Figuur 4.6: Het OC pakket.
aan voor de creatie van de binaire voorstelling. SigGen is de generator van de binaire voorstelling. Het zorgt voor de correcte opstelling van de TS header en het verdelen in pakketten. Verder zijn er functies om de verschillende tabellen apart weg te schrijven. De klasse SigGen TS ini bevat de parameters van de TS header en functies voor het opmaken van de binaire voorstelling van de header. Het pakket SigGen Tables bevat voor elk soort tabel een generator om de binaire voorstelling terug te geven. Elke tabelgenerator bevat de nodige functies om de ge¨ımplementeerde descriptoren aan de binaire voorstelling van de tabel toe te voegen. Bewerkingen die door elke tabelgenerator moeten gedaan worden, zijn gebundeld in het utilities pakket. Het bevat o.a. functies voor byteoperaties (byte arrays samenvoegen, vervangen van bits in een byte array, . . . ), het berekenen van een CRC-32, conversies en hexadecimale bewerkingen.
Figuur 4.7: Het DI pakket.
Hoofdstuk 4. Architectuur
35
XML Dit pakket zorgt voor de centralisatie van de PSI, SI tabellen en descriptoren, onder de vorm van XML. De verschillende soorten tabellen zijn beschreven door XML-schema’s (in Tables). De descriptoren werden oorspronkelijk apart door een XML-schema beschreven, maar omdat het overzicht binnen de tabellen duidelijk moet overkomen, zijn de verschillende descriptoren bij het schema van de bijhorende tabel geplaatst. Het invoegen wordt hierdoor vereenvoudigd en het aantal bestanden, voor het bewaren van de PSI en SI, wordt zo drastisch verminderd. Nu is er enkel per tabel ´e´en XML-bestand. Vanuit de verschillende schema’s worden datasets gecre¨eerd. Ze omvatten de eigenlijke PSI en SI data, terwijl de schema’s enkel de structuur van de PSI en SI defini¨eren. Bij elke dataset, van een tabel, hoort een Data Accessor, figuur 4.8. Deze implementeert methodes om informatie toe te voegen aan de verschillende tabellen en dit zonder enige controle. Er wordt niet gekeken naar de betekenis van de input. Indien men van datadrager wil veranderen, moet men enkel de verschillende accessoren aanpassen.
Figuur 4.8: De XML-laag.
De controle van de invoer wordt door de Transport stream.cs gecentraliseerd. Bijna elke
Hoofdstuk 4. Architectuur
36
methode uit alle data accessoren is door deze klasse overgenomen. Zo is er een opsplitsing voor het beheer van de datasets en het beheer van de TS. Wijzigingen, uitbreidingen in het beheer van een TS resulteren dan slechts in de aanpassing van de TS klasse. De interface van deze klasse dient als toegangspunt voor de andere lagen in de architectuur. Voor niet ondersteunde descriptoren is er Data Accessor Extra Descriptor.cs opgesteld. Een extra descriptor bevat identificatie velden (table id, section number, service id, program number, event id , . . . ) om de positie van de descriptor in een tabel aan te geven. Verder kunnen er velden toegevoegd worden van de volgende types: string, integer en hexadecimale string. Samen met het type moet het aantal gebruikte bits, het volgnummer en natuurlijk de veldwaarde ingevuld worden. De binaire voorstelling wordt, volgens volgnummer geordende velden, opgebouwd door de corresponderende SigGen Extra Descriptor.cs.
4.5
Architecturale tactieken en strategie¨ en
Deze paragraaf beschrijft de ingevoerde tactieken en strategie¨en die in de software gehanteerd worden. Hierdoor tracht men de vooropgestelde kwaliteitsattributen te verwezenlijken. Voor wijzigbaarheid worden de volgende tactieken en strategie¨en toegepast:
4.5.1
Lokaliseer de verwachte wijzigingen
Het doel van deze verzameling tactieken is om de verantwoordelijkheden aan de verschillende modules toe te wijzen zodat de invloed van de verwachte wijzigingen in omvang beperkt wordt [7, pagina 106 e.v.]. Behoud van semantische coherentie
Semantische coherentie duidt op de relaties tussen de verantwoordelijkheden van de modules. Het doel is dat de verschillende verantwoordelijkheden samenwerken met een minimale afhankelijkheid. Modules mogen dus geen overlappende verantwoordelijkheden hebben. Maak de gemeenschappelijke diensten abstract
Een onderdeel van semantische coherentie is het abstraheren van gemeenschappelijke diensten. Meestal wordt deze tactiek gebruikt voor hergebruik, maar deze kan ook voor wijzigbaarheid dienen. Wijzigingen worden dan beperkt tot de modules die deze dienst implementeren. De XML-laag is een gemeenschappelijke dienst die de andere twee lagen gebruiken.
Hoofdstuk 4. Architectuur
37
Anticipeer de verwachte wijzigingen
Men wil niet vast hangen aan de R&S software/hardware. De playoutmanager moet dus uitgebreid kunnen worden naar een ander broadcastplatform. De verschillende modules die met de hardware/software componenten zullen communiceren moeten beperkt worden. Via een BusinessLogic module zal de GUI afgeschermd worden van de hardware/software. De BusinessLogic, samen met de verschillende componentmodules, zorgen voor het implementeren van het Virtual Machine patroon. Het is geen zuivere Virtual Machine: hierbij moet er een vaste interface naar de component gemaakt worden en deze interface moet de algemene werking van het soort component opvangen. Ik heb gekozen om via de BussinesLogic de interface naar de verschillende componenten te maken omdat andere mogelijke broadcastsystemen niet via een aparte OC, een OS of een DI kunnen werken, bijvoorbeeld de DVB playout server in het testlabo. Wijzigingen in apparatuuren/of softwarecomponenten worden dus door de BusinessLogic en de componentmodules opgevangen.
4.5.2
Preventie van een domino-effect
Om het effect van wijzigingen in de software niet naar alle modules door te laten lopen, moeten er bepaalde tactieken worden ge¨ımplementeerd: Behoud de bestaande interfaces
Voor de gemeenschappelijke XML-laag is het belangrijk dat de interface vast staat. Wanneer dit niet zou zijn, zal een wijziging in de definitie van de interface een verandering vergen in elke module die deze laag gebruikt. Gebruik een tussenpersoon
De koppeling tussen de BusinessLogic en de componenten is, door het ontwerp, al zeer sterk. Door een tussenformaat te hanteren (XML-laag) probeert men deze koppeling te verminderen door de afhankelijkheid aan de PSI en SI naar de gemeenschappelijk gebruikte dienst af te schuiven. Ze worden dus enkel afhankelijk qua technologie en niet van de nodige PSI en SI daarbij.
Hoofdstuk 5
Software oplossing Met de architectuur hebben we een goede basis voor de uiteindelijke softwareoplossing. In dit hoofdstuk gaat men de andere kant van de software bekijken: de grafische lay-out en enkele belangrijke componenten van de playoutmanager. In de documentatie van de thesis zal geen code opgenomen worden, daar dit te veel overhead zou vormen. De belangrijkste componenten zullen echter wel besproken worden: de SigGen, de Data Accessor EIT, de Transport stream klasse en de BusinessLogic klasse. Het configureren van de .ini-bestanden en de verschillende vensters wordt niet behandeld.
5.1
Lay-out
Alvorens te programmeren ben ik op zoek gegaan naar hedendaagse playoutsystemen 1 . Hieruit bleek nogmaals dat de R&S MHPWizard duidelijk niet bedoeld was voor het genereren van een TS en enkel voor het testen van ´e´en applicatie. Zonder een duidelijk overzicht van de TS, is het zeer moeilijk om als gebruiker het geheel te zien. Een eerste noodzaak dringt zich snel op: er moet altijd een overzicht van de informatie in de TS aanwezig zijn voor de gebruiker. Wat er toegevoegd wordt, moet onmiddellijk zichtbaar zijn en duidelijk overkomen bij de gebruiker. 1
Enkele PSI/SI software voorbeelden: - Streamvalve III, A Stand Alone MPEG-2 DVB ASI Disk Recorder Player Application, Het analyser menu is hier enkel relevant. http://www.computermodules.com - CODICO
® SI-3050, PSI / SI Generator
http://www.scopus-europe.de
38
Hoofdstuk 5. Software oplossing
39
De vensterstructuur van de applicatie is zo eenvoudig mogelijk gebouwd: een hoofdvenster begeleidt de gebruiker door de verschillende bewerkingen. Dialogen om secties aan te maken en specifieke tabelitems toe te voegen worden rechtstreeks vanuit het hoofdvenster opgeroepen. Verder kan men vanuit het selectievenster (figuur 5.2) de mogelijke descriptor-dialogen aanroepen.
5.1.1
Het hoofdvenster
Figuur 5.1: Het hoofdvenster van de playoutmanager.
Hoofdstuk 5. Software oplossing
40
Het hoofdscherm wordt gesplitst in twee delen: Regio 1, in figuur 5.1, toont de TS in zijn geheel. Het geeft een overzicht van wat reeds
geconfigureerd is. De PAT, SDT, NIT en EIT zijn de algemene tabellen op vaste PID’s en worden onder Transportstream geschikt. Een PMT wordt onder de PAT sectie geplaatst waar het werd gedefinieerd. De secties van eenzelfde AIT worden onder de application signalling descriptor , die deze AIT aankondigt, geschikt. Elke descriptor, gedefinieerd in een tabel, wordt getoond onder de correcte lus. Een gemeenschappelijke-lus-descriptor staat direct onder de desbetreffende tabel. Een descriptor van een specifiek item wordt onder dit item geschikt. Een tabelsectie bewerken gaat als volgt; eerst selectie van de sectie in regio 1 en vervolgens zal het programma het geselecteerde tonen in regio 2 voor bewerkingen. Regio 2 in figuur 5.1 geeft een gedetailleerder overzicht van een tabelsectie. Hierin kan men
de geselecteerde sectie bewerken. Afhankelijk van de selectie wordt ´e´en van de 6 tabbladen, ´e´en per ondersteunde tabel, getoond en met de juiste gegevens ingevuld. In deze regio kan men nu de sectie bewerken: descriptoren toevoegen, algemene tabeleigenschappen aanpassen, . . . Samengevat wordt in regio 1 de globale tabellen bewerkt, secties verwijderd en toegevoegd, en na selectie kan men in regio 2 een sectie aanpassen.
5.1.2
Descriptoren
Descriptoren worden in alle tabellen gebruikt, buiten de PAT. Een uniforme procedure bij het bewerken van descriptoren maakt het duidelijker voor de gebruiker. Figuur 5.2 toont de gebruikte dialoog voor elke toevoeging, bewerking, verwijdering van een descriptor. Uit een tabelafhankelijke lijst selecteert men de descriptoren die men wenst te bewerken. Vervolgens worden de geselecteerde descriptoren, afhankelijk van de opdracht, bewerkt. De dialogen voor de specifieke descriptoren worden niet getoond. Er is gekozen voor een gerichte aanpak door voor elke ge¨ımplementeerde descriptor een aparte dialoog te defini¨eren met de specifieke velden. Als men een invoerveld van een descriptor meer gedetailleerder wil maken, dan moet men enkel de desbetreffende dialoog aanpassen. Indien er met een algemene voorstelling van een descriptor werd gewerkt, verliest men voor een stuk de betekenis van de mogelijke veldwaarden. Dit komt bijvoorbeeld tot uiting bij het gebruik van component type en stream
Hoofdstuk 5. Software oplossing
41
Figuur 5.2: De dialoog om descriptoren toe te voegen. Hier kunnen AIT applicatiedescriptoren toegevoegd worden.
content in de component descriptor van een EIT-sectie [in 2, paragraaf 6.2.8, tabel 26], zie ook paragraaf 2.4. Door te kiezen voor een afzonderlijke aanpak, kan men de manier van input bij de verschillende descriptoren individueel wijzigen. Indien de tabellen te omslachtig waren, werden ze als hexadecimale velden aangegeven. Men moet de link dan zoeken in de specificaties. De descriptoren zijn te vinden in [1, paragraaf 2.6], [2, paragraaf 6.2] en [3, paragraaf 10.4 e.v.].
5.2
Enkele belangrijke componenten
Door de grote overeenkomsten, bij de implementatie, tussen de verschillende tabel accessoren, wordt er slechts ´e´en accessor (Data Accessor EIT.cs) besproken. Paragraaf 5.2.2 behandelt de Transport stream.cs werkwijze om de gekoppelde TS correct te houden bij het toevoegen van PSI/SI. Verder zal de werking van SigGen.cs uitgelegd worden aan de hand van het genereren van de binaire voorstelling van een EIT. Paragraaf 5.2.4 BusinessLogic.cs behandelt de procedures voor het aanroepen van de verschillende R&S componenten. Als voorbeeld wordt een wizard voor het broadcasten van ´e´en MHP-applicatie uitgelegd.
5.2.1
Data Accessor EIT
Een data accessor bevat een dataset van datatabellen. Voor de EIT is dit een Tables.dsEIT object. Het bezit de verschillende tabellen die een EIT kan bevatten: EIT-sectietabel, eventtabel, EIT-descriptorentabellen. Rijen van de eventtabel en EIT-descriptorentabellen zijn allemaal gekoppeld aan een EIT-sectierij. Figuur 5.3 geeft een alternatieve voorstelling van het XML-
Hoofdstuk 5. Software oplossing
42
Figuur 5.3: Een eenvoudig overzicht van de tabeldefinities van dsEIT. De structuren van de descriptoren wordt niet getoond.
schema van de EIT. De verschillende velden in figuur 5.3 zijn de kolommen in een datatabel. Elk veld wordt als string beschouwd om gemakkelijk met de hexadecimale voorstelling om te gaan. Elke data accessor bevat karakteristieke functies: 1 2 3 4
{ Thesis.XML.Tables.dsEIT.XXXDataTable output = new Thesis.XML.Tables.dsEIT.XXXDataTable(); ... return output;
6 7 8 9 10 11 12 13 14 15 16 17
43
} public Thesis.XML.Tables.dsEIT.XXXRow Get_XXX(...) { Thesis.XML.Tables.dsEIT.XXXRow output = new Thesis.XML.Tables.dsEIT.XXXRow(); ... return output; }
Om een rij toe te voegen zal er een Add XXX methode (lijn 1) zijn, waarbij XXX de naam van de datatabel krijgt. De inputparameters zijn de waarden van de verschillende velden aanwezig in de tabel. Edit XXX implementeert het wijzigen van een rij en Delete XXX het verwijderen. De Get XXX methode is de enige methode die een return waarde heeft: een instantie van een rij (lijn 13) of van een data-tabel (lijn 6). Voor elke tabeldefinitie in de dataset zijn er dergelijke functies ge¨ımplementeerd. Identificatie van de positie in de EIT-dataset gaat als volgt: table id, section number, service id, transportstream id en original network id bepalen de EIT-sectie waar men iets wil bewerken, vervolgens bepaalt men met de event id het correcte event. Elke data accessor bevat ook een Write XML en Read XML methode om de inhoud van de tabellen naar een XML-bestand te exporteren of van een XML-bestand te importen.
5.2.2
Transport stream.cs
Deze klasse zorgt voor de correcte invulling van de TS. Transport stream.cs neemt de methoden van de data accessoren over. De controle van de TS gebeurt nu op ´e´en plaats en de toegang tot de datalaag wordt beperkt tot ´e´en interface. Het controleren van de uniciteit van de gebruikte id’s, PID’s, component tags, programmanummers, . . . in de tabellen is o.a. een taak van deze klasse. Via ArrayList objecten, dynamische lijsten, houdt Transport stream.cs de te controleren velden bij. Sommige descriptoren mogen niet samen in een bepaald item (service, event, applicatie,. . . ) voorkomen en Transport stream.cs beheert dit ook. Op dit moment is de onderlinge koppeling tussen de PSI/SI tabellen minimaal om zo de gebruiker toe te laten de tabellen zo afzonderlijk mogelijk op te stellen. Een voorbeeld hiervan is de koppeling tussen een PMT’s programmanummer en een SDT-service: de service id moet hetzelfde zijn als het programmanummer. In code wordt deze koppeling niet gemaakt. De gebruiker moet zelf zorgen voor de consistentie. De flexibiliteit is dan maximaal om de verschillende mogelijkheden te on-
Hoofdstuk 5. Software oplossing
44
derzoeken. Het invoeren van de koppelingen kan eenvoudig gemaakt worden door de betrokken functies in Transport stream.cs aan te passen.
5.2.3
SigGen.cs
Deze parser vormt de verschillende datasets om naar MPEG2 TS-pakketten met correcte header en binaire voorstelling. Oorspronkelijk was het de bedoeling om de R&S SigGen component te herbruiken maar door de onduidelijke structuur van de PSI/SI .ini-bestanden, moest er zelf een generator gebouwd worden.
Figuur 5.4: Een definitie van een present/following EIT-tabel
Met een present/following EIT-tabel zal de werking uitgelegd worden (Figuur 5.4). De tabel bevat 2 secties, chronologisch geordend, met elk ´e´en event. Het eerste event heeft een extended event descriptor naast de verplichte short event descriptor . Bij het tweede event is er nog een component descriptor, content descriptor en een parental rating descriptor gedefinieerd. SigGen.Create Binary EIT wordt aangeroepen. Deze functie delegeert de opdracht om de secties de binariseren naar SigGen EIT.Create EIT Byte format. Deze functie converteert de verschillende secties, conform de specificatie [2], naar een ArrayList van sectiebytes. SigGen.Create Binary EIT gaat per binair sectieformaat de volgende stappen uitvoeren: 1. De bytes opsplitsen in pakketten van 184 bytes met uitzondering van het eerste deel van een sectie. Deze mag slechts 183 bytes bevatten omdat er een pointer moet toegevoegd worden naar het begin van de sectie in het MPEG2 TS-pakket. [1, paragraaf 2.4.3.3][6, paragraaf 11.2.2] 2. Na de opsplitsing voegt het een header [1, paragraaf 2.4.3.2][6, paragraaf 11.2.3] toe, met de corresponderende PID en continuity counter . Bij het eerste pakket van een sectie wordt de pointer en de payload start indicator gezet. SigGen.cs neemt de header en voegt er de
Hoofdstuk 5. Software oplossing
45
opgesplitste segmenten aan toe, met natuurlijk telkens de verhoogde continuity counter . Indien het laatste segment geen 184 of 183 bytes data bevat, worden de MPEG2 TSpakketten opgevuld met 0xFF bytes tot de vaste lengte bereikt is. 3. Na het opstellen van de MPEG2 TS-pakketten van alle secties, worden ze allen achter elkaar gebundeld en weggeschreven. Deze procedure herhaalt zich bij de verschillende tabellen.
5.2.4
BusinessLogic.cs
De logica van de TS zit in Transport stream.cs. De logica van het aanroepen van de hardware/software componenten wordt opgevangen door BusinessLogic.cs. Run Configuration(), Run DI(), Run OS() en Run OC() zijn de gebruikte functies voor het aanroepen van de componenten. Volgens een public Transport Stream.cs object gaat BusinessLogic.cs beslissen wat er moet ingesteld worden. De DI configuratie bestaat uit het invullen van het .ini-bestand en het binariseren van de PSI en SI. Voor de OC en OS is het moeilijker aangezien er meerdere instanties nodig kunnen zijn. Per datastroom wordt er gezocht naar de carousel identifier descriptor en stream identifier descriptor . Via de carousel id , in de carousel identifier descriptor , wordt het bron path van de OC achterhaald. De component tag in de stream identifier descriptor bepaalt de gebruikte Association Tag. Na het invullen van de carousel.ini , start BusinessLogics.cs de OC. Het systeem configureert en start vervolgens de streamer.
5.2.5
Een wizard
De interface IPre Config bevat 4 functies: bool Run()
Het implementeert het opstellen van een Transport Stream.cs object en het opvragen van de nodige extra informatie aan de gebruiker. Thesis.XML.Transport stream Get ts()
Het geeft het geconfigureerde Transport Stream.cs object aan de BusinessLogic indien de run methode correct werd uitgevoerd. ArrayList Get source maps() en ArrayList Get carousel ids()
Deze bezorgen de bronmappen en gelinkte carousel id’s om de nodige OC’s te kunnen configureren.
Hoofdstuk 5. Software oplossing
46
De playout manager bevat ´e´en wizard die de functionaliteit van de MHPWizard vervangt. (DVBJ single application onder het Wizard menu) Figuur 5.6 toont de input die gegeven moet worden door de gebruiker. Na deze dialoog is de TS opgesteld en klaar voor broadcasting. (Figuur 5.5)
Figuur 5.5: Overzicht van het opgebouwde TS door de wizard.
Figuur 5.6: De nodige input van de gebruiker.
Om een nieuwe wizard toe te voegen moet men de interface IPre Config implementeren en een Transport stream object configureren in de Run() methode. In de BusinessLogic.cs constructor definieert men de nieuwe wizard en geeft men een tekstbeschrijving dat in het menu van de wizards, in GUI.Displayer, zal worden getoond. Enkel de BusinessLogic.cs zal dus gewijzigd moeten worden.
Hoofdstuk 6
Conclusies en perspectieven Bij de ontwikkeling van deze thesis heb ik een aantal stappen gevolgd: 1. Literatuurstudie: PSI en SI worden door verschillende specificaties beschreven [1, 2, 3]. Een grondige studie van deze specificaties was nodig om alle begrippen te kennen. 2. Achtergrondstudie: Er moest nagegaan worden welke R&S software componenten binnen het systeem pasten en welke niet. Enkel de OC, OS en DI waren geschikt. De SigGen component was niet gedocumenteerd en niet bruikbaar door de onduidelijke werking. 3. Na de studie was het tijd om te starten met de ontwikkeling. Een software project moet altijd beginnen met een analyse van de vereisten. Hieruit werd dan een architectuur gedestilleerd. 4. Met de opgestelde architectuur kon het implementeren beginnen. De verschillende stappen zijn gedocumenteerd in een overeenkomstig hoofdstuk. Als laatste zullen de mogelijkheden en uitbreidingen van de software aangekaart worden, gevolgd door een evaluatie.
47
Hoofdstuk 6. Conclusies en perspectieven
6.1
Mogelijkheden
6.1.1
Actual en other
48
Door de opsplitsing van data en functionele kant is het mogelijk om zowel de actual als de other TS te voorzien van PSI en SI. Een sectie is een rij in de dataset, toegankelijk via de id’s die een sectie uniek bepalen. Toevoeging van other of actual tabelsecties wordt dan vereenvoudigd tot het defini¨eren van rijen in de dataset.
6.1.2
Het testen van applicaties
Meerdere applicaties ´ en van de doelstelling van deze thesis was het broadcasten van meerdere applicaties. Via het E´ opstellen van de PSI en SI is het eenvoudig om dit te implementeren: 1. Definieer de nodige datastromen in de PMT. Men kan kiezen om applicaties binnen dezelfde datastroom te verzenden of telkens een aparte ES op te stellen. De playoutmanager zal bij elke carousel identifier descriptor een nieuwe OC en OS starten. 2. Definieer meerdere applicaties in de AIT van het programma. Door de DVBJ application location descriptor , in de descriptorlus van elke applicatie, kan men de applicaties binnen eenzelfde datastroom distanti¨eren. Men moet dan de klasse aanduiden die zal uitgevoerd worden als de applicatie geselecteerd wordt. De transport protocol descriptors, in de applicatie descriptorlus, bepalen de gebruikte datastroom. (Zie paragraaf 2.4) Met twee verschillende “Hello World” applicaties, met verschillende kleuren en zonder resourcesreservatie, zijn enkele configuraties getest. Er werd telkens met ´e´en OC gewerkt, zie paragraaf 6.3.1. 1. Twee applicaties binnen eenzelfde AIT sectie. De set-top box kan de twee applicaties onderscheiden. Via een applicatielijst kiest men de applicatie. 2. Twee applicaties in een verschillende AIT sectie onder dezelfde PID. Per applicatie wordt er een nieuwe AIT sectie gedefinieerd. De transport protocol descriptors wijzen naar de datastroom en de application descriptors worden dan weer gelinkt aan
Hoofdstuk 6. Conclusies en perspectieven
49
deze descriptoren via het transport protocol label . De verschillende secties worden back-toback in MPEG-2 TS-pakketten gegoten. De verschillende applicaties worden keurig in de lijst van applicaties getoond. 3. Twee applicaties in een verschillende AIT sectie onder verschillende PID binnen dezelfde service. De twee applicaties worden door een aparte AIT tabel gedefinieerd. De twee AIT secties worden in een aparte MPEG-2 TS-pakketten gestoken met telkens de correcte PID. Vervolgens worden ze doorgegeven aan de DI via het tables.trp bestand en hier stopt het. De multiplexer ziet de definitie van de twee tabellen in de PMT maar ´e´en van de AIT’s wordt niet mee verstuurd door de DI. I.p.v. een AIT sectie detecteert de multiplexer niets. Het lijkt of de DI enkel ´e´en AIT tabel aankan. Service bound en unbound applicaties Service bound applicaties worden be¨eindigd bij het wisselen van service op de set-top box. Een alternatief hiervoor is het opstellen van een domein voor een applicatie. Een domein is een verzameling van services waar de applicatie in de AIT’s is opgenomen. Dit kan in de applicatielus van de tabel of in de de lijst van de external application authorisation descriptor (in de common loop). Bij het bekijken van een service buiten het domein van een applicatie zal de applicatie be¨eindigd worden door de set-top box. De service bound flag van de applicatie moet wel op ‘0’ gezet worden als men de uitvoering in het domein niet wil onderbreken. Indien de applicatie wel als service bound gedefinieerd werd, zal het ook binnen het domein van de applicatie gestopt worden als men een andere service selecteert. Er zijn drie mogelijkheden [3, paragraaf 10.5.2] om de levenscyclus van een applicatie te be¨ınvloeden tijdens het wisselen van service op de set-top box: 1. Bij een serviceovergang zal de uitvoering van een momenteel lopende applicatie met een service bound flag ‘0’ niet onderbroken worden als zijn applicatie identifier is opgenomen in de applicatielus van de AIT van de nieuwe service. 2. Een service unbound applicatie zal ook blijven lopen als het werd opgenomen in de lijst van applicaties van de external authorisation descriptor in de common loop van de AIT van de nieuwe service.
Hoofdstuk 6. Conclusies en perspectieven
50
3. Een service bound applicatie wordt gekilled bij een serviceovergang. De eerste twee mogelijkheden kunnen eenvoudig worden opgesteld in de playoutmanager maar door de beperkingen van de R&S componenten is het niet mogelijk om deze te testen, zie paragraaf 6.3.1. Men moet immers twee verschillende AIT’s opstellen. Wat niet in de specificatie staat is het gedrag van een service unbound applicatie dat door een serviceovergang buiten zijn domein valt. Men wenst en verwacht dat de applicatie be¨eindigd zal worden omdat het buiten zijn domein is. Maar de applicatie zal nog een twintigtal seconden blijven draaien waarna het gekilled wordt.
6.1.3
EIT
De meeste playoutsystemen ondersteunen allen het broadcasten van de EIT. Het opstellen van de EIT moet echter via andere tools gebeuren. Dit komt door de grote hoeveelheid data verwerkt in een EIT. De playoutmanager behandelt het opstellen van de EIT w´el. De configuratie verloopt zoals de andere tabellen en kan gemakkelijk ge¨exporteerd worden naar andere playoutsystemen via het binair formaat of via een aangepaste parser van het XML-formaat. Door het grote volume kan men wel beter overschakelen naar een externe database.
6.1.4
DVB playout server IRT
De playoutmanager is compatibel met enerzijds de R&S oplossing via OC, OS en DI, maar ook met de DVB Playout Server van IRT. Dit playoutsysteem leest de opgestelde binaire secties van de playoutmanager in en configureert zelf de nodige componenten. Het bouwt rechtstreeks een TS op. De DVB Playout Server implementeert dus de functionaliteit van de carrousel en de TS-builder. Momenteel kunnen alle binaire secties doorgegeven worden, maar enkel de voorzieningen voor EIT secties zijn onderzocht. Meer compatibiliteit kan door een aparte parser ge¨ımplementeerd worden. Door de late aankoop van de IRT Playout Server is verdere compatibiliteit niet onderzocht. De thesis baseerde zich op de R&S componenten.
6.2
Uitbreidingen
Dynamisch aanpassen van de PSI en SI met XML als input.
De PSI en SI kan op een dynamische manier aangepast worden. Door XML-bestanden in te vullen en te verzenden kan een extensie van de playoutmanager de ontvangen bestanden
Hoofdstuk 6. Conclusies en perspectieven
51
inladen, controleren en de TS PSI en SI aanpassen. GUI.Business Logic.cs moet aangepast worden om deze functionaliteit toe te voegen. De DI zal nieuwe PSI en SI moeten detecteren en zijn TS updaten. Door zijn slome karakter moet het wel onderzocht worden of de update snel genoeg gebeurt op de TS. Audio en video
De huidige versie van de playoutmanager ondersteunt PSI en SI voor audio en video. Streamers hiervoor zijn niet ge¨ımplementeerd. Mits beschikbaarheid van dergelijke streamers kan de manager een volledige TS opbouwen met audio, video en data. Configuratie en aanroeping van de streamers kan door de GUI.Business Logic.cs worden opgevangen. Ondersteuning van dergelijke streamers door de DI is niet verder onderzocht en kan leiden tot problemen aangezien de DI geen echte TS builder is, figuur 1.4. Het stelt enkel een TS met een datastroom op. Analyser
Met een extra omzetting van binair naar XML van de PSI en SI, kan de playoutmanager bijkomend als PSI/SI analyser gebruikt worden. Er is natuurlijk nog een extractor nodig om de TS PSI en SI van het medium te lezen. Met een aanpassing van de GUI.Business Logic.cs en een aparte extractor kan deze functie toegevoegd worden aan de playoutmanager. Playout Server van IRT
De AIT en PMT worden via tekstfiles geconfigureerd. Een parser naar dit formaat laat volledige configuratie van de TS van de Playout Server van IRT toe. Als men enkel via de binaire voorstelling werkt van de secties, kan men de gegevens niet meer bekijken en bewerken in de grafische interface van deze server. Multiplexer, meerdere TS’en.
Door Transport stream.cs opnieuw te gebruiken kan een multiplexer bestuurd worden. De inputkanalen zullen telkens aparte Transport stream.cs objecten aan het nieuwe systeem doorgeven. Samenvoeging kan dan gebeuren door de verschillende TS’en te vermengen met aanpassing van dubbele PID’s, programmanummers, . . . Het is geen rechtstreekse uitbreiding van de playoutmanager maar de logica van de PSI en SI kan opnieuw gebruikt worden. Er moet een interface naar een fysieke multiplexer zijn enerzijds om commando’s door te geven en anderzijds om de verschillende PSI en SI tabellen in te lezen. De huidige
Hoofdstuk 6. Conclusies en perspectieven
52
fysieke multiplexer kan via een webinterface geconfigureerd worden. Indien deze interface toegankelijk is en met specifieke commando’s werkt, kan deze gebruikt worden om een multiplexer-controller te bouwen met Transport stream.cs objecten.
6.3 6.3.1
Evaluatie Rohde & Schwarz
Het hergebruik van de R&S software componenten bespaarde enorm veel tijd. Echter in de laatste fase van de thesis ontstonden er problemen met de testopstelling. Door de vele installaties van andere software, werkte de testopstelling niet meer. Zelfs met de originele software van R&S was het niet meer mogelijk om een applicatie te versturen naar de set-top box. Het genereren en opstellen van de PSI en SI vormde geen enkel probleem. De playoutmanager heeft deze taak met succes overgenomen. De multiplexer kan de gegenereerde informatie inlezen, wat bewijst dat het binair formaat correct is. Present/following EIT-secties worden ook keurig gelezen door de multiplexer. Het werken met de OC en OS is voor ´e´en applicatie aanvaardbaar maar voor meerdere applicaties zijn de componenten niet flexibel genoeg. Hoewel hun .ini-bestanden het wel toelaten, is het opstellen van meerdere OC’s op ´e´en machine niet vanzelfsprekend. Als men twee OC’s wil opstellen moet men twee verschillende datastromen defini¨eren in de PMT en telkens een andere carousel id opgeven. Weerom is het eenvoudiger in de PSI en SI dan in de eigenlijk opstelling. Als de twee OC’s samen uitgevoerd worden, genereert ´e´en carrousel fouten. Met het manueel instellen van de carrousels en streamer is het mogelijk om de carrousels naast elkaar te laten lopen maar slechts ´e´en van de datastromen zal zijn weg vinden naar de DI. Een oplossing voor dit probleem kan het werken met meerdere PC’s zijn. Op elke PC zal dan een carrousel draaien. De verschillende streamers moeten w´el op ´e´en PC draaien door de hardlock beveiliging en vanuit verschillende directories worden gestart. Deze opstelling is nog niet getest. Meerdere services opstellen kan ook met de DI. De multiplexer kan de structuur van de TS afleiden. Als er meerdere AIT’s (verschillende PID) moeten verstuurd worden, dan blokkeert de DI of de multiplexer zoals in het derde voorbeeld van meerdere applicaties in paragraaf 6.1.2. Een lege sectie wordt gelezen door de multiplexer.
Hoofdstuk 6. Conclusies en perspectieven
53
Samengevat zijn de mogelijkheden met de R&S componenten: Meerdere applicaties in ´e´en OC. Meerdere secties voor de tabellen. Slechts ´e´en AIT. Meerdere services
De volledige vrijheid in het opstellen van de PSI en SI door de playoutmanager kan niet doorgevoerd worden naar de onderliggende componenten. De DI kan bijvoorbeeld slechts ´e´en AIT verwerken. Door al de problemen met de componenten wordt het gebruik van de playoutmanager beperkt. Uitbreiding naar een ander broadcastsysteem laat toe om alle mogelijkheden van de playoutmanager uit te buiten.
6.3.2
Uitgebreidheid van de PSI en SI
PSI en SI omvatten enorm veel informatie. Ik heb een selectie moeten doorvoeren van de te ondersteunen tabellen en descriptoren om de thesis implementeerbaar te houden. Het toevoegen van niet ondersteunde descriptoren kan via de Extra Descriptor. Toevoeging van niet ondersteunde tabellen is niet ge¨ımplementeerd. Met de beperkte testopstelling vormt dit echter geen probleem. Alle nodige informatie kan opgesteld worden om MHP applicaties te testen. Uitbreiding met een tabel, met bijhorend XML-schema, is mogelijk door een nieuwe data accessor en bijhorende generator te implementeren. Verder moet de nieuwe accessor gekoppeld worden aan XML.Transport stream.cs. Men kan een reeds bestaande tabeloplossing als codeleidraad nemen. De GUI.Displayer moet verder uitgebreid worden om de gegevensinvoer toe te laten. Om de nieuwe tabel in het TS-overzicht, regio 1 figuur 5.1, te krijgen moet men Display TreeView() wijzigen in GUI.Displayer.Form Main.cs. Vervolgens moet men in regio 2 van figuur 5.1 een nieuw tabblad en de nodige dialogen (descriptoren, secties, . . . ) opstellen. treeView Service Information AfterSelect() verzorgt de selectie van de tabbladen en moet ook ge¨ updatet worden. Een uitbreiding met een nieuwe tabel vergt dus heel wat wijzigingen. De architectuur concentreerde zich op de afhankelijkheid van de hardware en software componenten. PSI en SI staat altijd centraal en heeft veel invloed op de componenten. Deze invloed wordt enigszins beperkt
Hoofdstuk 6. Conclusies en perspectieven
54
door de XML.Transport stream.cs maar de GUI zal wel steeds aangepast moeten worden door de specifieke werking per tabel. Dit was een trade-off tussen leesbaarheid en uitbreidbaarheid. Met een algemenere werking, generieke tabel en descriptoren, verloor men een deel van de details van de PSI en SI en verminderde men de leesbaarheid. Het gebruik van XML-schema’s per tabel bemoeilijkte ook een algemene werking. Deze zijn tabelspecifiek en de velden kunnen per tabel een verschillend aantal bits aannemen. Een optimalisatie of een uitbreidbare oplossing voor de generator zou kunnen zijn om met een gelijklopend schema te werken dat het aantal bits van de tabelvelden bevat. De generator zoekt dan eerst het aantal bits op om vervolgens het veld correct te binariseren. Opmerking over CRC-32 Het gebruik van de CRC-32 wordt beschreven in [1, Annex B] en [2, Annex B]. De gegeven informatie in deze annexen is echter onvoldoende. Men weet niet of men de CRC moet berekenen met de voorwaartse of de reverse CRC methode. De gehanteerde CRC methode is een voorwaartse CRC-32, zonder finale XOR en met initi¨ele waarde 0xFFFFFFFF.
6.3.3
Werking met XML
Door de mogelijke enorme hoeveelheid informatie kan het werken met XML ineffici¨ent worden. Werken met een externe database lost dit probleem op (aanpassing van de data accessoren). De XML-schema’s kunnen herbruikt worden om de data intern voor te stellen en door te geven tussen de verschillende functies. Aangezien de beperkte mogelijkheden van de testopstelling vormt dit echter geen probleem.
Bijlage A
XML, XML schema’s en datasets A.1
XML schema’s en datatsets
Datasets zijn opslagplaatsen met een gedisconnecteerde cache, zonder fysieke connectie tot het eigenlijke opslagmedium. De structuur van een dataset is vergelijkbaar met deze van een relationele databank; het stelt een hi¨erarchisch object model voor van tabellen, rijen en kolommen. Zelfs contraints en relaties kunnen gedefinieerd worden. Met deze offline mode kunnen we een model voor de TS PSI en SI opbouwen en parsen naar het fysiek opslagmedium; namelijk de binaire vorm. De fundamentele delen van een dataset worden d.m.v. standaard programmeerconcepten (properties en collections) aan de developer aangeboden. Zo kan men alle rijen, kolommen, kindrelatie, ouder-relatie, . . . flexibel toevoegen, verwijderen of wijzigen. Een dataset is een view van data dat in XML kan weergegeven worden. In Visual Studio .NET en het .NET framework is XML het formaat voor het bewaren en verzenden van alle soorten data. Hierdoor hebben datasets een nauwe band met XML. Deze relatie tussen datasets en XML laat toe om de volgende voordelen te halen uit het werken met datasets: 1. De structuur van een dataset (zijn tabellen, kolommen, relaties en constraints) kunnen gedefinieerd worden met een XML-schema. XML-schema’s zijn standaardformaten van het W3C1 om de structuur van XML-data te defini¨eren. Datasets kunnen XML-schema’s, die structurele informatie bevatten, schrijven en lezen. 1
World Wide Web Consortium
55
Bijlage A. XML, XML schema’s en datasets
56
2. Men kan een dataset cre¨eren vanuit een XML-schema om de verschillende data structuren (zoals bijvoorbeeld rijen en kolommen) als class members te defini¨eren. Men heeft dan rechtstreekse toegang tot deze members. Deze klasse wordt automatisch gegeneerd. 3. Men kan een XML-document inlezen in een dataset en een XML-document wegschrijven met de inhoud van de dataset. Voor de uitbreiding naar bijvoorbeeld het dynamisch instellen van PSI en SI is XML, en daarbij ook datasets, enorm handig. Men hoeft dan slecht een XML document op te stellen volgens het XML schema. De 2 applicaties kunnen deze gegevens dan uitwisselen zonder enige tussenkomst of incompatibiliteiten (Java, .NET). Per tabel (PAT, PMT, . . . ) is er een XML schema opgesteld, volgens de specificaties, met de descriptoren als subtabellen en met de nodige relaties. Figuur 5.3 geeft een voorbeeld van een schema in Visual Studio .NET voor de EIT. In een dataset kan men rijen toevoegen volgens de schemastructuur, parent/child relaties opbouwen (tussen een EIT sectie en event, event en descriptoren), . . .
A.2
XML bestanden
Deze paragraaf bevat een voorbeeld van een TS. Het correspondeert met het uitgewerkte voorbeeld in paragraaf 2.4.
<short_event_descriptor> <descriptor_tag>4D <descriptor_lenght /> eng <event_name_lenght /> <event_name_chars>My event My text <EIT> 4E <section_syntax_indicator>1 FFFF <section_lenght /> <service_id>0001 FF00 <current_next_indicator>1 <section_number>01 0100010001 <segment_last_section_number>01 4E <events> <event> <event_id>0002 <start_time>d249130000 01020300 <descriptors_loop_lenght /> <descriptors> <descriptor_tag>50 <descriptor_lenght /> FF <stream_content>1 0101engMy vieo <descriptor_tag>50 <descriptor_lenght />
65
Bijlage A. XML, XML schema’s en datasets
FF <stream_content>2 0302ENGMy audio <short_event_descriptor> <descriptor_tag>4D <descriptor_lenght /> eng <event_name_lenght /> <event_name_chars>My event 2 My text
66
Bijlage B
Handleiding De software kan op elke PC draaien waarop enerzijds het .NET framework is ge¨ınstalleerd en anderzijds toegang is tot de OC, OS en DI. De volgende paragrafen zullen uitleggen hoe men met de playoutmanager kan werken.
B.1
Het Hoofdscherm
Figuur 5.1 geeft het startvenster, en tevens hoofdvenster, van de applicatie. Regio 1 bevat het algemeen overzicht van de TS. Tabel secties toevoegen vindt in deze regio plaats. In regio 2 kan men de ingevoerde sectie verder bewerken. Regio 1 wordt dus enkel gebruik voor het weergeven van de volledige TS en voor het bewerken van secties. Via een rechtermuis klik, in deze view, komt een help-menu, figuur B.1, te voorschijn waar men de gewenste sectie kan selecteren. Om een sectie toe te voegen aan een bestaande tabel, moet men de uit te breiden tabelsectie selecteren in regio 1 en vervolgens via het sectiemenu de gewenste handeling selecteren. Om een tabelsectie te bewerken moet deze geselecteerd worden in Regio 1, TS overzicht. Automatisch zal het correcte tabblad in regio 2 (Sectie overzicht) getoond worden met de huidige gegevens. Per tabblad kan men de karakteristieke gegevens bewerken. Als voorbeeld van de werking zullen de PAT (paragraaf B.2) en PMT (paragraaf B.3) behandeld worden. De andere tabellen kan men op een analoge manier opstellen. Alvorens te starten met de PSI en SI configuratiemogelijkheden, worden de verschillende menu-items in het hoofdscherm overlopen.
67
Bijlage B. Handleiding
68
Figuur B.1: Het menu na rechter muisklik in Regio 1 van figuur 5.1
B.1.1
Menu
File Het menu-item File bevat 4 instanties: 1. New XML configuration Voor het starten van een nieuwe TS configuratie. 2. Load XML configuration Met deze functie kan men een bewaarde configuratie inladen. Men moet de map specificeren waar het zich bevindt. 3. Save XML configuration De opgestelde configuratie zal bewaard worden in de gespecificeerde map. Per tabel zal er een XML bestand gecre¨eerd worden. (PAT.xml, PMT.xml, NIT.xml, SDT.xml, EIT.xml, AIT.xml, dirs.xml voor de R&S software component padnamen, paths.xml voor de bronmappen van de OC en extra.xml voor de extra descriptoren) 4. Close Sluit de applicatie. Configuration In deze menu kan men de locatie van OC, OS en DI opgeven. Er is voorzien om de verschillende .ini-bestanden rechtstreeks te configureren, maar dit is niet ge¨ımplementeerd en dus niet actief.
Bijlage B. Handleiding
69
Via de dialoog (figuur B.2) moeten de locaties opgegeven worden van de software componenten van R&S en het IP adres van de DI.
Figuur B.2: De dialoog voor het opgeven van de verschillende directories
Run Dit submenu verzorgt het uitvoeren van verschillende opdrachten. 1. Run Configuration Configureert en start de verschillende OC en OS. Binariseert de ingestelde TS PSI en SI en stelt de DI in. Na het starten van de OC en OS moeten de nieuwe .ini-bestanden geladen worden. Via “open ini” in de R&S componenten moet men voor de OC carouselxxxxxxxx.ini selecteren en voor de OS ObjectStreamerxxxxxxxx.ini. De x’en staan voor de carousel id. 2. Generate binary PAT sections Bewaart de ingestelde PAT secties in een bestand naar keuze. Het gaat hier enkel om de binaire voorstelling van de verschillende secties, achter elkaar bewaard in de file. Dus zonder enige MPEG2 TS pakket-vorming en -opsplitsing. 3. Generate binary PMT sections Zoals de PAT secties. Enkel moet men de gewenste PMT tabel, aan de hand van het programmanummer, selecteren in een keuzedialoog (figuur B.3) alvorens men de binaire voorstelling van de verschillende secties kan bewaren. 4. Generate binary NIT sections Bewaart de ingestelde NIT secties in een bestand naar keuze.
Bijlage B. Handleiding
70
5. Generate binary SDT sections Bewaart de ingestelde SDT secties in een bestand naar keuze. 6. Generate binary EIT sections Bewaart de ingestelde EIT secties in een bestand naar keuze. 7. Generate binary AIT sections Bewaart de ingestelde AIT secties in een bestand naar keuze na selectie, aan de hand van de PID, van de gewenste AIT. 8. Run with carousel and streamer Hier kan men kiezen of enkel de PSI/SI moet doorgegeven worden aan de DI, of heel de configuratie moet herstart worden met carrousels en streamers. Dit is handig om een update van de PSI/SI door te geven zonder de huidige databroadcast te be¨ınvloeden.
Figuur B.3: Het selectiedialoog
Wizard Hier worden alle mogelijk wizards verzameld. Momenteel is er slechts ´e´en opgesteld als voorbeeld; DVBJ single application. Figuur 5.6 toont het venster voor de invoer van de gebruiker. Applicatie naam, base directory, classpath extension, initial class en de bronmap voor de OC moeten opgegeven worden. Alle overige configuraties voert de wizard uit. Help Dit submenu bevat het “About” dialoogje dat alle software producten hebben.
Bijlage B. Handleiding
71
Figuur B.4: Het versie venster
B.2
Een PAT sectie
De applicatie start met ´e´en PAT sectie. Na selectie in het TS overzicht, kan men deze sectie bewerken. Regio 2 in het hoofdscherm toont de PAT sectie. De algemene velden van de PAT sectie kan men in Main table settings (figuur B.5, nummer 1) wijzigen. Drukken op de Apply PAT changes bewaart de veranderde parameters. Met de Save PAT knop kan men de PAT tabel apart in een XML-bestand opslaan.
B.2.1
Een PAT program
Onder PAT programs (figuur B.5, nummer 2) kan men services toevoegen aan de PAT sectie. De dataview geeft een lijst van de verschillende programma’s die reeds zijn gedefinieerd. Met de knoppen Add Program, Delete Program en Change Program kan men respectievelijk een programma toevoegen (figuur B.6), een programma verwijderen en programmagegevens wijzigen. Bij het verwijderen of wijzigen moet het betreffende programma in de lijst geselecteerd zijn. In het TS overzicht zal de corresponderende PMT ook toegevoegd, verwijderd of gewijzigd worden.
B.3
Een PMT sectie
Omdat de PAT geen descriptoren bevat, zal het bewerken van een PMT sectie uitgelegd worden. De gevolgde methodiek is dezelfde bij de andere tabellen. Na toevoeging van een programma in de PAT zal er een eerste sectie verschijnen in regio 1 van het hoofdscherm. Na selectie van de PMT sectie in regio 1, kan men de sectie bewerken in regio 2 van het hoofdscherm. Onder Main table settings (figuur B.7, nummer 1) kan men de karakteristieke tabelparameters aanpassen, zoals de PAT. Drukken op de Apply PMT changes knop, bewaart de doorgevoerde wijzigingen van de karakteristieke tabel settings.
Bijlage B. Handleiding
72
Figuur B.5: Het tabblad van de PAT
Figuur B.6: Een programma toevoegen
Figuur B.7 (nummer 2) geeft een overzicht van de common descriptors. Via de knoppen Add descriptor, Edit descriptor en Delete Descriptor kan men een descriptor toevoegen, bewerken of verwijderen, de laatste 2 weer na selectie in de lijst van common descriptoren. Met de Save PMT knop kan men de PMT tabellen apart in een XML bestand opslaan.
Bijlage B. Handleiding
73
Figuur B.7: Het tabblad van de PMT.
B.3.1
Een PMT ES
Net zoals bij de PAT programma’s maar dan voor stromen, wordt er een lijst van de verschillende stromen in deze PMT sectie weergegeven (figuur B.7, nummer 3). Toevoegen van een stroom gebeurt door op de knop Add stream te drukken en het getoonde venster in te vullen (figuur B.8). Verwijderen en wijzigen van de stroomparameters kan door eerst de gewenste stroom in de lijst te selecteren en vervolgens respectievelijk op de knop Delete stream en Change stream te drukken.
Bijlage B. Handleiding
74
Figuur B.8: Dialoog voor het toevoegen van een stream.
Figuur B.9: Selectiedialoog van de descriptoren in de PMT.
B.3.2
Descriptoren
Bij een stroom kan men descriptoren defini¨eren. Na selectie van een stroom in de ES lijst van de PMT sectie, kan men descriptoren toevoegen, bewerken of verwijderen. Door respectievelijk op de knop Add Descriptors, Edit Descriptors en Delete Descriptors te drukken, verschijnt er een selectiedialoog voor descriptoren (figuur B.9). Afhankelijk van de gedrukte knop zullen de geselecteerde descriptoren toegevoegd, bewerkt of verwijderd worden. Voor het toevoegen en bewerken zal er per descriptor een venster verschijnen om de descriptor gegevens te bewerken. Bij het toevoegen van een application signalling descriptor zal er ook een nieuwe AIT sectie gedefinieerd worden. Enkel met een dergelijke descriptor kan een startende AIT tabel (onder de nieuwe PID) toegevoegd worden.
Bijlage C
.ini-bestanden Ter verduidelijking van de verschillende parameters van een OC, OS en DI worden de originele .ini-bestanden getoond. De bestanden bevatten meer uitleg over de verschillende velden. ObjectCarousel.ini is een extra configuratiebestand voor parameters die niet grafisch of via ObjectStreamer.ini opgesteld kunnen worden.
INI for Carousel Dir Tree Reader Service Meaning of the adjustments: Section [carousel] WinPosition: last position of the window (don’t chnage this parameter) CarouselNumber: abstract id value of this Carousel instance, must be different from any other Carousel Service on the same computer (1..99) Port: TCP/IP port on which the carousel service is available for OWS clients (all free ports 1025-65535, default = 5000 + CarouselNumber) DirTreeRoot: Root Directory with the data pool (full path specifier) MaxThreads: number of independet threads (tasks) which can work parallel (internal, 2..4) ErrorMsgLevel: level of debug messages in the main window (1 (few) .. 3(all)) SyncWithDownload: synchronisation with the R&S Download Tool (0 (off), 1 (on)) RemoteControlOn: Enables remote control on Carousel by TCP/IP session RemoteControlPort: TCP/IP port where Carousel waits for remote control connections, default = 5100 + CarouselNumber LoadOnStartup: auto run application after power on (0 (off), 1 (on)) StartListening: data server ready for connctions from OWS clients (0 (off), 1 (on))
[GUI_settings] pid=0x0200 carouselId=0x00000005 associationTag=0x00000005 inputDirectory=OCDest outputDirectory=OCSource fastGen=1 [DSI] DSI.transactionId=0x800A0001 // transactionIds cannot be chosen arbitrary! bit 0 is updateFlag, // bits 16 to 30 are moduleVersion, // bits 31 and 32 are reserved; see spec. for details [DII] DII.transactionId=0x800A0003 blockSize=0x0FE2 // intial module id moduleId=0x7001 [BIOP] // intial object key objectKey=0x80000000 [misc]
C.3
ObjectStreamer.ini
; INI for CarouselReader ; ; ; ; ; ; ;
Meaning of the adjustments: Section [CarReader] WinPosition: last position of the window (don’t chnage this parameter) PortSource: TCP/IP port (IN) on which the Carousel service is available (s. Carousel settings) AddrSource: IP address or DNS name of the PC on which the Carousel Server is running (IN)
TunnelPortDest: UDP/IP port of Data Inserter waiting for the TS packets as paylod of the UDP/IP TunnelDest: IP address of Data Inserter waiting for the TS packets as paylod of the UDP/IP DataPacketLen: length of files reading blocks in bytes (100-16000) RetransmitCount: number of retransmitts (0 means forever, 1..1024) PauseTransmit: time in seconds between retransmitts (0..3600 secs) TranSpeed: number of reading blocks per second (1..65000) SyncOutput: synchronisation with the R&S NDIS driver IPGate (only for internal use !) LogLevel: level of debug messages in the main window (Error (few) .. Info(all)) LogFileName: name of the log file (absolute or relative path) LoadOnStartup: auto run application after power on (0 (off), 1 (on)) StartListening: client ready for connctions to Carousel server after start (0 (off), 1 (on)) InitSourceDir: directories reading from Carousel, created automaticly after pressing Refresh-Button under Settings (don’t change this list) SourceDirsList: all directories in the root directory of Carousel (don’t change this list) AppToStart: application to start after all files have received from Carousel CycleTime: the interval (in secs) the server checks for new content if it makes a pause between transmissions. RemoteControlPort: The Port on what the server waits for commands: START STOP KILL ?RUN
;Object Craousel Settings: ; CarouselID: ID of the Object Carousel withinthe MPEG-2 TS ; AssociationTag: Tag liniking all objects within the Object Carousel ; independent of elementary PID ; ElementaryPID: MPEG-2 TS PID of all Objects of the Object Carousel ; chooseRouterInserter: 1 = Media Router , 0 = Data Inserter ; FastGen: 1=Generation of binary TS file or 0=all intermediate results [ObjectStreamer] WinPosition=0,1,-1,-1,-1,-1,132,132,900,669 PortSource=5001 CarouselNumber=1 AddrSource=127.0.0.1 PortDest=8000 PortMR=6100 PortDI=8000 AddrDest=127.0.0.1 AddrMR=127.0.0.1 AddrDI=127.0.0.1 chooseRouterInserter=0 DataPacketLen=1024 RetransmitCount=0 PauseTransmit=0 TranSpeed=1000
;In the header of this file comments and value ranges of ALL POSSIBLE DIP ;parameters ;are provided ;Following abrevation are used in the description: ;AS - automatically saved, don’t change this value (!!!) ;RW - read/write parameter, will read from ini and can be changed via ;settings dialog ;RO - read only parameter, only for experts (!!!), will be read from ini ;file (if set), ; ;[WINPOS] ;WinPosition - position and size of the main window, AS ;[MODE] ;;InsGen - selction of the hardware working mode: MPEG-2 Inserter or ;MPEG-2 generator, RW, (values: Ins, Gen) ;[GENERATOR] ;;GenTSRate - data rate of generated MPEG-2 TS, only generator mode, RW, ;(values: in Mbit/s, in 1 kbit steps) ;PCROnOff - switching the PCR generation On or Off, only generator mode, ;RW, (values: 0,1) ;PCRDistance - distance between two PCR stamps in MPEG-2 TS, ;only generator mode, RW, ;(values: in TS packets) ;PCRPID - PID on which the PCR is generated, only generator mode, RW, ;(values: 0x10 - 0x1ffe) ;[TSInput] ;Type - MPEG-2 TS input port, only inserter mode, RW, (values: ASI or SPI) ;TSRateSet - mode of the incoming MPEG-2 TS, only inserter mode, RW, ;(values: 0: cont, ;1: burst mode ;[MPEG] ;MaxPayload - rate of whole TS incl. V/A + Data (opportunistic), RW, ;(values: in Mbit/s, 10.0 - 54.0) ;ChangePID - base PID for range of PIDs which will be replaced in TS by data, ;RW, (values: 0x10 - 0x1fff)
78
Bijlage C. .ini-bestanden
;ChangeMask - mask for replacing ranges of PIDs in TS by data, RW, ;(values: 0x0 - 0x1ffe) ;MeasurePID - data rate of this PID will be displayed in the main GUI, RW, ;(values: 0x0 - 0x1fff) ;MeasureRates - measuring data rates in hardware will be performed ;(performance), RO, (values: ON or OFF) ;* START: ********** PSI signalling with DIP010_011, MEPG-2 inserter device ;***************************** ;[PSI] ;PMTSiganlisation - adding data service PSI to predef. PMT on-the-fly, ;only inserter mode, RW, (0: Off, 1: On) ;PMTPID - PID of PMT table to be changed, only inserter mode, RW, ;(values: 0x1 - 0x1ffe) ;TimerPMT - interval between two changed PMT (in ms), only inserter mode, RO, ;(values: 10 - 500 ms) ;[SERVICES] ;NumberOf - number of signalised services in new PMT, only inserter mode, RO, ;(value: 1 - 16) ;SPIDx - signalised PID of the data service, i.e SPID1=0x3D, RO ;DataBroadcastIdx - signalised ID of the data service, ;i.e DataBroadcastId1=0x0001, RO ;ComponentTagx - signalised Tag of the data service, i.e ComponentTag1=0x01, RO ;* END: ********** PSI signalling with DIP010/011, MEPG-2 inserter device ;******************************** ;* START: ********** PSI signalling with DIP020_021, MEPG-2 generator device ;***************************** ;[PSI_TABLES] ;NumberOf - number of tables read from the PSI tables file, RO, only generator, ;(0: default fix tables, 1..6) ;TablesFile - file name of the file including PSI tables, relative path, RO, ;only generator, (default ’table.trp’ if NumberOf > 0) ;PSI_FREQ - interval for insertion of all PSI tables read from file, RO, ;only generator, (100-500 ms, default: 150, in ms) ;NewPSICheckFreq - interval for checking for PSI table file update, ;fix token: ’table.new’, RO, only generator, (100-10000 ms default: 1000, in ms) ;[PSI_GEN] ;PSIGenOn - tables generation will be switched on here, RW, only generator, ;(0: Off, 1: On) ;SDTOn - SDT will be generated, RW, only generator mode, (values: 0: Off, 1: On) ;SDTDist - intervall between SDT packets, RW, only generator mode, (in ms) ;(values: 100 - 500ms) ;NITOn - NIT will be generated, RW, only generator mode, (values: 0: Off, 1: On) ;NITDist - intervall between NIT packets, RW, only generator mode, (in ms) ;(values: 100 - 500ms) ;EITOn - EIT will be generated, RW, only generator mode, (values: 0: Off, 1: On) ;EITDist - intervall between EIT packets, RW, only generator mode, (in ms) ;(values: 100 - 500ms) ;AITOn - AIT for MHP services will be generated, RW, only generator mode, ;(values: 0: Off, 1: On) ;AITDist - intervall between AIT packets, RW, only generator mode, (in ms) ;(values: 100 - 2000ms) ;* END: ********** PSI signalling with DIP020_021, MEPG-2 generator device ;***************************** ;[LOG] ;LogLevel - log info level for debug window and log file, RW,
79
Bijlage C. .ini-bestanden
;(values: 1: INFO, 2: WARNING, 3: ERROR) ;LogFileOn - enable logging into a log file , RW, (values: 0: off, 1: on) ;LogFileName - name of the log file, RW, (values: string length < 100) ;LogFileSize - size of the log file (wrap around), RW, ;(value: look on your hard disc, max. 1 MByte) ;[REMOTE] ;ConsoleOn - console for remote access on status information, RW, ;(values: 0: off, 1: on) ;ConsolePort - TCP port on which remote console resides, RW, ;(value: above 1024, not already used) ;[REC_PORT] ;localUdpPort - UDP port for sourcing IP data in QoS tunneling format, RW, ;(value: same as Media Router output) ;[BUFFER] ;RBufferSize - size of internal Ring Buffer for intermediate buffering, RW, ;(value: 8-64 kByte) ;UDPBufferSize - size of buffer of the UDP receiving socket, RW, ;(value: 8-64 kByte) ;[INTERNAL] ;FastTransfer - data transfer speed to hardware slow (8/16 bit) or fast (32 bit), ;RO, (value: 0: slow, 1: fast) ;ISA_EPP - for data transfer use ISA bus or EPP interface, RO, ;(value: 0: ISA, 1: EPP) (!) ;MeasureTSSync - read MPEG-2 TS sync information from the hardware, RO, ;(value: 0: off, 1: on) ;RefreshRate - refresh rate for displaying statistics on GUI, in ms, RW, ;(value: 100-10000 ms) ;[HEARTBEAT] ;OnOff - switching Heartbeat property on/off, RW, (value: 0: off, 1: on) ;Interval - interval for sending UDP heart beat packets, in ms, RW, ;(value: 100-5000) ;TargetPort - target port of heart beat packets, RW, ;(value: above 1024, not already used) ;TargetIP - target IP address of heart beat packets (unicast/multicast), ;RW, (value: valid IP address) ;LocalIP - in case TargetIP is multicast, real network adpater IP is required, RW, ;(value: read it with ’ipconfig’) ;Message - srting send in teh heart beat packets, RW, (value: length < 255) ;[IDENTIFICATION] ;Ident - identification of the DIP read via remote console (string), RW, ;(value: length < 255) [WINPOS] WinPosition=0,1,-1,-1,-1,-1,260,492,1097,715 [MODE] InsGen=Gen [GENERATOR] GenTSRate=20.000000 PCROnOff=1 PCRPID=0x0020 PCRDistance=80 [TSInput] Type=ASI TSRateSet=0 [MPEG]
Bibliografie [1] International Organisation for Standardisation, “Generic coding of moving pictures and associated audio, systems recommendation H.222.0”, ISO/IEC 13818-1, November 1994. [2] European Broadcasting Union, Digital Video Broadcasting, “Specification for Service Information in DVB systems”, ETSI EN 300 468 V1.6.1, June 2004. [3] European Broadcasting Union, Digital Video Broadcasting, “Multimedia Home Platform Specification 1.0.2”, ETSI TS 101 812 V1.2.1, June 2002. [4] European Broadcasting Union, Digital Video Broadcasting, “Guidelines on implementation and usage of Service Information (SI)”, ETR 211, August 1997. [5] Steven Morris, Athony Smith Chaigneau, “Interactive TV Standards, A Guide to MHP, OCAP and JavaTV”, Focal Press, ISBN: 0240806662, April 21, 2005. [6] Edward M. Schwalb, “iTV Handbook: Technologies and Standards”, Prentice Hall PTR, ISBN: 0131003127, July 25, 2003. [7] Len Bass, Paul Clements, Rick Kazman, “Software Architecture in Practice ”, Pearson Education, ISBN: 0321154959, 2003.
