Televisió Digital Terrestre : Desenvolupament d'un "Personal Video Recorder" basat en l'estàndard DVB-MHP

Enginyeria de Telecomunicació - Projecte final de carrera Autor Jordi Mestres López Director Josep Ramon Casas Data Octubre de 2007 Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder” basat en l’estàndard DVBMHP. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 1 A la meva família, a la meva parella, i en especial a la meva germana petita. Molta força. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 2 Índex 0. DEFINICIÓ. ............................................................................................... 4 1. INTRODUCCIÓ. .......................................................................................... 5 1.1. MOTIVACIÓ DEL PROJECTE. ............................................................................ 6 1.2. OBJECTIUS............................................................................................. 6 2. CONTEXT. ................................................................................................ 8 2.1. LA TELEVISIÓ INTERACTIVA. ........................................................................... 8 2.1.1. Els Set-top box. .............................................................................. 9 2.1.1.1. El canal de retorn. ..................................................................... 10 2.1.2. Perfils interactius. ........................................................................ 11 2.1.3. Nivells d’interactivitat. .................................................................. 12 2.1.4. Tipus d’aplicacions interactives. ....................................................... 14 2.1.4.1. Enhanced TV............................................................................. 15 2.1.4.2. Serveis d’informació. .................................................................. 15 2.1.4.3. Serveis de comunicació i missatgeria. .............................................. 19 2.1.4.4. Serveis d’entreteniment. ............................................................. 20 2.1.4.5. T-Comerç. ............................................................................... 21 2.1.4.6. T-Administració......................................................................... 21 2.1.4.7. T-Aprenentatge. ........................................................................ 22 2.1.4.8. T-Salut. .................................................................................. 22 2.1.4.9. Business TV. ............................................................................. 23 2.2. LES APIS. ........................................................................................... 23 2.2.1. Les APIs propietàries. .................................................................... 24 2.2.2. Les APIs estandaritzades. ................................................................ 25 2.2.2.1. Multimedia Home Platform (MHP). ................................................. 26 2.2.2.1.1. Objectius de l’estàndard. ......................................................... 29 2.2.2.1.2. Què defineix l’MHP? ................................................................ 30 2.2.2.1.3. Globally Executable MHP (GEM). ................................................. 31 2.2.2.1.4. Arquitectura de l’MHP. ............................................................ 31 2.2.2.1.4.1. Els Plug-ins. .......................................................................... 33 2.2.2.1.5. L’Execució d’aplicacions MHP. .................................................... 34 2.2.2.1.6. L’Emissió d’aplicacions MHP. ..................................................... 36 2.2.2.1.7. Model de les aplicacions. .......................................................... 37 2.2.2.1.7.1. Aplicacions DVB-J: Els Xlets. ...................................................... 38 2.2.2.1.8. APIs de la plataforma DVB-J. ..................................................... 42 2.2.2.1.8.1. Gràfics. ................................................................................ 42 2.2.2.1.8.2. Interacció amb l’usuari. ........................................................... 44 2.2.2.1.8.3. Reproducció de continguts multimèdia. ........................................ 46 2.2.2.1.8.4. Accés a dades. ....................................................................... 48 2.2.2.1.8.5. Canal de retorn. ..................................................................... 50 2.2.2.1.8.6. Sincronització amb l’emissió. ..................................................... 50 2.2.2.1.8.7. Interacció entre aplicacions. ...................................................... 53 2.2.2.1.8.8. Altres APIs. ........................................................................... 55 3. DESCRIPCIÓ DE L’APLICACIÓ. ....................................................................... 56 Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 3 3.1. DEFINICIÓ. .......................................................................................... 56 3.2. HISTORIA. ........................................................................................... 56 3.3. PRINCIPALS FUNCIONALITATS. ....................................................................... 58 3.4. LES NORMATIVES “PVR/PDR EXTENSION TO THE MULTIMEDIA HOME PLATFORM” & “DIGITAL RECORDING EXTENSION TO GLOBALLY EXECUTABLE MHP”. .................................................. 62 3.4.1. ARQUITECTURA BÀSICA DEL MHP-PVR. .......................................................... 63 3.4.2. EL PROCÉS DE GRAVACIÓ I REPRODUCCIÓ. ......................................................... 65 3.4.2.1. GESTIÓ DE GRAVACIONS PLANIFICADES. ........................................................ 65 3.4.2.2. EL PROCÉS DE GRAVACIÓ. ...................................................................... 65 3.4.2.3. GESTIÓ DE GRAVACIONS COMPLETADES. ........................................................ 67 3.4.2.4. EL PROCÉS DE REPRODUCCIÓ. .................................................................. 67 3.4.2.5. TIMESHIFT. .................................................................................... 68 3.4.3. APIS DE GRAVACIÓ I REPRODUCCIÓ. .............................................................. 70 4. CONTEXTUALITZACIÓ TÈCNICA. ................................................................... 72 4.1. EL SISTEMA DE CREACIÓ I EMISSIÓ D’INTERACTIUS D’ACTIVA MULTIMÈDIA............................. 72 4.1.1. HandData. .................................................................................. 72 4.1.2. Digital FingerText. ........................................................................ 74 4.1.3. Llançadora. ................................................................................. 78 4.2. L'ENTORN DE DESENVOLUPAMENT. ................................................................... 79 4.2.1. iTextTools. ................................................................................. 79 4.2.2. Eclipse IDE & Osmosys SDK............................................................... 83 4.3. L’ENTORN DE PROVES. ............................................................................... 84 5. DESENVOLUPAMENT DE L'APLICACIÓ. ............................................................ 86 5.1. LA INTERFÍCIE D'USUARI. ............................................................................. 86 5.1.1. La pantalla Menú d'inici. ................................................................. 87 5.1.2. La pantalla Control de vídeo. ........................................................... 90 5.1.3. La pantalla Guia electrònica de programació. ...................................... 104 5.1.4. La pantalla Gestió de Gravacions. .................................................... 114 5.2. ELS BEANS. ......................................................................................... 123 5.2.1. EL BEAN VKBEAN. ............................................................................... 123 5.2.2. EL BEAN PVREPGBEAN. ........................................................................ 124 5.2.3. EL BEAN PVRMENUBEAN. ....................................................................... 126 5.3. ELS MÒDULS DE LÒGICA. ............................................................................ 127 5.3.1. El mòdul VKModule. ..................................................................... 128 5.3.2. El mòdul PVRModule. .................................................................... 130 6. CONCLUSIONS. ....................................................................................... 139 6.1. REFLEXIONS A DIA D’AVUI. .................................................................... 140 7. REFERÈNCIES. ........................................................................................ 143 7.1. BIBLIOGRAFIA. .................................................................................... 143 7.2. ENLLAÇOS D’INTERÈS. .......................................................................... 144 Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 4 0. Definició. Els “PVR” (Personal Video Recorders), son l’evolució dels antics “VCR” (Video Cassette Recorders). Son dispositius que incorporen al seu hardware un sistema d’emmagatzematge digital, i son capaços d’enregistrar i reproduir continguts audiovisuals en format digital. Els PVRs, basats ens discs durs, poden proporcionar un sèrie de serveis que no poden igualar-se amb els tradicionals VCRs. Per exemple: gravar i reproduir a la vegada i així proporcionar modes de reproducció de temps desplaçat (com pot ser pausar la TV en directe o el visionat no lineal), programar gravacions únicament prement un botó, la creació de canals virtuals basats en les preferències d’un usuari, compartir el contingut enregistrat entre usuaris, etc. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 5 1. Introducció. L’evolució de la televisió des de la seva irrupció massiva a la dècada dels setanta, ha estat vertiginosa i s’ha convertit, sense cap mena de dubte, en el mitjà de comunicació de masses amb major èxit i major difusió. Des de la introducció del color, l’esdeveniment més important ha estat l’aparició de la televisió digital terrestre (TDT). Aquesta no només proporciona als usuaris la possibilitat de rebre més canals al seu receptor de televisió amb una qualitat similar a la del DVD, sinó que també afegeix una interactivitat sense precedents. La TDT (Televisió Digital Terrestre) és un concepte relativament nou de televisió, encara que des de els anys noranta rebem una amplia programació en format digital a través de l’antena parabòlica. Els receptors digitals no seran totalment indispensables fins d’aquí uns anys (al 2010 a l’Estat Espanyol) amb l’anomenada “apagada analògica”, nom amb el qual es coneix al pròxim cessament de les emissions analògiques dels operadors de televisió i ràdio dels països de la Unió Europea. No obstant això, ja és possible gaudir en aquests moments de les atractives millores que aporta la TDT respecte a la televisió analògica. Tot apunta a que la televisió digital produirà una important revolució respecte a la televisió analògica convencional coneguda fins ara. Aquesta revolució no només suposarà un nou negoci per als fabricants de televisors i de receptors digitals, empreses d’instal·lació i manteniment d’antenes (donat que més de 22 milions de receptors analògics hauran de ser renovats abans del 2010), productors de programes televisius i empreses creadores de continguts interactius per a la nova televisió, sinó que també afectarà en gran mesura a la forma en la que l’espectador gaudeix de la televisió. La nova forma de veure la televisió, ve donada en gran part per les grans possibilitats que suposa la incorporació d’un “motor” en el hardware dels receptors digitals que permet l’execució d’aplicacions enviades pels radiodifusors, fet que obre un gran ventall d’opcions per a posar a l’abast del telespectador. Aquesta es la base de la nova televisió interactiva. Aquest projecte contempla el fet de que un cop que el telespectador ha adaptat la seva antena i ha adquirit un receptor de TDT, s’adonarà de que durant la transició de la tecnologia analògica a la digital ha perdut la possibilitat d’enregistrar fàcilment els seus programes favorits de televisió. El present document proposa una possible solució a aquest Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 6 problema fent ús de les possibilitats que ens ofereix la nova televisió digital. 1.1. Motivació del projecte. El present projecte ve donat per un conveni de cooperació que involucra l’Escola Tècnica Superior d’Enginyers de Telecomunicació de Barcelona i la Corporació Catalana de Radio i Televisió a través de l’empresa del grup Activa Multimèdia Digital, empresa que proporciona solucions i serveis per al sector audiovisual. Il·lustració 1: Logotip d’Activa Multimèdia Digital Activa Multimèdia Digital emmarca la seva activitat, entre d’altres tasques, en solucions complertes d’interactivitat per a televisió digital terrestre, des de la conceptualització, disseny i edició de les aplicacions, fins al manteniment de les seves dades (guies electròniques de programació, teletext digital, el temps, etc.), així com el sistema d’emissió d’interactius. Amb aquest conveni de cooperació, Activa Multimèdia Digital, ha volgut estudiar una possible solució a la problemàtica que apareix a l’hora de realitzar o visualitzar gravacions, per part dels telespectadors, amb la transició de la televisió analògica a la televisió digital terrestre. 1.2. Objectius. L’objectiu principal d’aquest projecte és el disseny d’una aplicació per a televisió digital terrestre que realitzi les funcions d’un “Gravador de Vídeo Personal” o PVR (Personal Video Recorder). L’aplicació serà dissenyada per a descodificadors de televisió digital terrestre dotats d’MHP versió 1.1.2 amb la API PVR i amb un sistema d’emmagatzematge de tipus disc dur. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 7 Aquesta aplicació solucionarà de forma eficient i intuïtiva la problemàtica apareguda en la transició de la tecnologia analògica a la digital en el camp de les gravacions domèstiques de continguts televisius. També veurem quines noves funcionalitats i requeriments representa la implantació d’aquest nou tipus de gravador digital així com de quina manera afectarà a la forma de veure la televisió a la que estem acostumats. D’altra banda, també es pretén fer una breu introducció a la televisió interactiva des del punt de vista tecnològic, des del punt de vista dels radiodifusors, així com des del punt de vista de l’usuari final, es a dir, els telespectadors. Aquest projecte també pretén introduir-nos a l’estàndard DVB-MHP, el middleware per a televisió interactiva especificat pel DVB Project. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 8 2. Context. La implantació de la televisió digital terrestre obre un nou món de possibilitats d’interacció amb el telespectador i acosta la tecnologia a un ampli sector de la població. La televisió digital terrestre ofereix, a part d’una major qualitat d’àudio i vídeo, la possibilitat que l’usuari no només vegi i escolti, sinó que a més participi, aportant així un nou concepte de televisió que ofereix un ampli ventall de noves opcions per posar al servei del telespectador. 2.1. La Televisió interactiva. Podem definir la Televisió interactiva (TVi) com una forma de veure la televisió a la qual l’usuari pot gaudir de continguts i serveis addicionals sumats als continguts de la televisió convencional. Gràcies a les aplicacions interactives, la programació i el mateix concepte de “televisió” afronten un canvi radical. En essència, la televisió interactiva suposa el desenvolupament de la televisió amb tecnologies que incorporen un canal de retorn i donen la possibilitat als telespectadors d’utilitzar aquest medi d’una nova forma. Aquesta nova forma de veure la televisió modifica substancialment l’esquema de la televisió com a medi de comunicació unilateral. La televisió interactiva possibilita que l’espectador deixi de ser un receptor passiu d’informació i adopti un paper actiu al nou context d’oportunitats que se li ofereixen: configurant la senyal que observa, interactuant amb aplicacions que complementen la senyal televisiva amb informació addicional, particularitzant qualitativa i quantitativament la seva publicitat, programant el seu receptor en funció d’events i continguts, etc. En poques paraules, se’ns obre un món semblant al que ja gaudim als nostres PCs, però ara als nostres televisors, s’obren a la televisió les oportunitats que avui en dia ja ens ofereix l’ordinador com a canal de serveis, fonamentalment a través d’Internet: serveis de compres, reserves, tràmits, sol·licituds i una inesgotable font d’informació. Clarament, els sistemes que poden fer ús d’aquestes característiques han de ser compatibles amb l’estàndard MHP i disposar d’un canal de retorn en funció del tipus de servei. La interactivitat és una de les principals avantatges de la televisió digital enfront a la televisió analògica. Encara que el nivell d’interactivitat Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 15 • “TV Sites” Són aplicacions a pantalla complerta sense contingut audiovisual. Són molt semblants a un Web-Site, però adaptades per a ser vistes a través d’un televisor: caràcters i cursors grans, pensades per a navegar amb el comandament a distància enlloc d’utilitzar el teclat i el ratolí, etc. Alguns exemples podrien ser aplicacions de telebanca o d’administració electrònica. A continuació podem veure alguns exemples d’aquestes aplicacions. 2.1.4.1. Enhanced TV. Són aplicacions que aporten informació relacionada al programa que s’està emetent. Per tant són mostrades de forma que no desllueixen els principals elements de la programació, que continuen sent els continguts audiovisuals. Il·lustració 2: Portal interactiu dels Jocs Olímpics d’Hivern de 2006 2.1.4.2. Serveis d’informació. Són aplicacions de gran utilitat per als usuaris donat que posen al seu abast un ampli ventall d’informació d’interès. Dins d’aquest tipus d’aplicacions podem trobar les següents: Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 16 • EPGs Les guies electròniques de programació són aplicacions molt esteses entre els radiodifusors. Les EPGs ofereixen un llistat dels canals de televisió disponibles i dels programes que s’emeten o s’emetran a dits canals. Podem dir que usualment, els EPGs són guies de programació setmanals. La informació dels canals i dels programes s’obté normalment a través de la lectura de les dades de la taula SI (Service Information) dels serveis de broadcast. Entre d’altres informacions, la taula SI també es capaç d’informar a l’usuari sobre quin es el programa que està sen emès actualment, el següent programa en emissió, canvis en la programació dels canals, etc. Normalment, els terminals d’usuari ofereixen aquesta informació a través d’una interfície gràfica definida pels fabricants d’aquests receptors, però molts radiodifusors ofereixen la seva guia electrònica de programació especifica, i d’aquesta manera poden guiar al telespectador cap a certs programes o cap a d’altres canals del mateix radiodifusor. Il·lustració 3: EPG d’Avalpa Digital Engineering • Notícies Existeixen diferents tipus de serveis de noticies: la majoria d’ells son planes tipus “portal” amb la informació distribuïda per categories entre diferents seccions, i n’existeixen d’altres amb un format més simple que mostren la seva informació per pantalla fent ús de “tickers” que presenten totes les noticies cíclicament. Els serveis de noticies poden cobrir un ampli ventall Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 17 d’àmbits d’aplicació, des de esdeveniments esportius, com poden ser unes olimpíades o un mundial, fins a qualsevol tipus d’esdeveniment cultural. Il·lustració 4: Portal de notícies de SalzburgTv • Informació meteorològica Els serveis d’informació meteorològica són normalment de tipus “broadcast only”, del que hem parlat amb anterioritat. La interactivitat radica principalment al fet que els usuaris poden escollir informació meteorològica detalla de certes zones, ja siguin regions, zones d’àmbit nacional o internacional pel dia que l’espectador desitgi. Il·lustració 5: Servei d’informació meteorològica de la televisió d’Extremadura Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 18 • Informació de trànsit De forma similar a les aplicacions d’informació meteorològica, els serveis d’informació de trànsit ofereixen als usuaris informació detallada de l’estat del trànsit a les zones que l’usuari desitgi. Per tant, la interactivitat torna a estar basada en el fet que l’usuari decideix quin tipus d’informació de transit desitja o bé, de quina zona vol aquesta informació. Normalment aquestes aplicacions també aporten als usuaris informació de l’estat i horaris dels transports públics així com de les estacions de ferrocarrils o aeroports. Il·lustració 6: Servei d’informació viaria de TVC Multimèdia • Digitext / Teletext La televisió interactiva ofereix la possibilitat d’oferir tot tipus d’informació complementaria relacionada amb els canals de televisió de la mateixa forma amb la que es realitza amb els seus portals d’Internet. En adició als tradicionals portals basats en continguts en forma de text, els radiodifusors o els proveïdors de serveis poden oferir imatges i continguts d’àudio i/o vídeo en els seus portals interactius. En aquests portals apareix sobretot la interacció bidireccional, especialment en els serveis de distribució de continguts audiovisuals. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 19 Il·lustració 7: Digitext de TVE 2.1.4.3. Serveis de comunicació i missatgeria. Són aplicacions que permeten la comunicació entre els usuaris de la plataforma. Amb la irrupció dels missatges SMS aquest tipus d’aplicacions ha sofert un creixement molt considerable donat que constitueixen una font d’ingressos extra per a aquells canals i plataformes que inclouen aquest tipus d’aplicacions entre els seus serveis. Actualment ja és més habitual que aquestes aplicacions utilitzin un canal de retorn diferent al telèfon mòbil, com per exemple el canal de retorn referent a la interfície de comunicacions (Ethernet, mòdem, etc.) del terminal d’usuari. • T-Mail / T-Chat Diverses empreses del mercat d’MHP ofereixen clients de correu basats en l’estàndard MHP. Aquests clients poden ser integrats pels radiodifusors com a serveis per a la comunitat d’usuaris de les seves plataformes o bé integrats directament als terminals d’usuari com succeeix amb les guies electròniques de programació. Les aplicacions de correu o chat son aplicacions clarament de tipus bidireccional donat que permeten la comunicació entre els usuaris finals. Òbviament és totalment necessari l’ús del canal de retorn per a poder connectar als servidors de correu o sales de chat de la xarxa, de la mateixa forma que també es totalment necessari l’ús d’un teclat, ja sigui físic o un de virtual mostrat per la pantalla del televisor. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 20 2.1.4.4. Serveis d’entreteniment. Encara que a l’Estat Espanyol aquest tipus d’aplicacions no han gaudit encara de gaire acceptació, a d’altres països han suposat tota una sorpresa. Les seves possibilitats de negoci i ingressos a través del denominat “pay-per-play” en el cas dels jocs, i “pay-per-view” en el cas dels serveis de vídeo sota demanda, fan d’aquests tipus d’aplicacions de les més atractives per a les plataformes audiovisuals. • Jocs El ventall de jocs interactius per a televisió digital terrestre s’estén des dels d’interactivitat “bidireccional” fins als d’interactivitat tipus “broadcast only”. Els jocs de tipus “broadcast only” són jocs d’estil “arcade” com per exemple el joc anomenat “Tetris” o jocs de cartes en modalitat solitari. Aquests jocs són, interactivament parlant, els més compatibles amb les possibilitats de la televisió interactiva, donat que només es requereixen unes poques tecles del control remot per a poder ser controlats per l’usuari. Aquestes aplicacions són relativament petites i usualment no estan relacionades amb els programes de televisió, amb el que es habitual trobar-se-les integrades als terminals d’usuari de forma similar al que succeeix amb les terminals de telefonia mòbil. Actualment estan començant a aparèixer portals interactius que permeten la descàrrega d’aquests jocs al terminal d’usuari a través del canal de retorn, possibilitant un altre tipus de mercat, l’anomenat “pay-per- play”. Molts radiodifusors també han desenvolupat jocs relacionats amb programes específics, permetent als usuaris, d’aquesta manera, participar en aquests programes. Aquestes aplicacions per als concursos de tipus “preguntes i respostes” són especialment adients per a la interfície d’usuari dels receptors de TDT, això succeeix donat que només són possibles un número finit de respostes, fàcilment assignables i identificables amb les tecles de colors dels comandaments a distància dels terminals. • Vídeo Sota Demanda La televisió interactiva també pot actuar com element de distribució de vídeos sota demanda (VoD) fent ús de portals, on els usuaris finals, poden seleccionar qualsevol de les pel·lícules o programes oferts pel proveïdor del servei. Cal comentar que per Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 21 a poder gaudir d’aquest tipus de servei, els terminals d’usuari, requereixen estar connectats a un accés de banda ampla per on els continguts audiovisuals seran entregats. 2.1.4.5. T-Comerç. La televisió interactiva possibilita un gran nombre d’oportunitats per a tot tipus de comerç, des de la publicitat interactiva fins a qualsevol transacció de tipus comercial realitzada utilitzant l’entorn televisiu. • Tele-Shopping Existeixen molts tipus de portals de compres per a la televisió interactiva. Tots aquests portals son de tipus bidireccional, en ells, els usuaris poden veure, seleccionar i comprar tot tipus de productes a partir de llistats de productes, que han estat adaptats per a ser mostrats per la pantalla de televisió, de la mateixa manera que si ho fessin a través d’Internet. • Publicitat interactiva Els tipus de campanyes de publicitat a través de la televisió digital van des dels típics “banner web” sobreimpressionats en pantalla, fins a campanyes realitzades amb complets portals de tipus “Enhanced TV”, on un petit banner pot redireccionar a l’usuari interessat al portal del producte. 2.1.4.6. T-Administració. Les aplicacions de T-Administració (T-Gobernment) pretenen acostar als usuaris tot tipus de serveis de l’Administració Pública, com per exemple: informació ciutadana, consultes de l’administració als ciutadans, accés als serveis de sanitat publica, etc. Aquest tipus d’aplicacions utilitzen el canal de retorn de forma bidireccional, però el més rellevant del seu funcionament radica en l’ús de targetes d’identificació intel·ligents, es a dir, targetes que incorporen un xip de memòria amb les dades necessàries per a identificar als usuaris. Cal a dir que per a poder gaudir d’aquest tipus d’aplicacions es necessari que el receptor dels usuaris incorporin un lector de targetes intel·ligents, fet no gaire habitual en els receptors actuals. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 22 Il·lustració 8: Portal de l’Agència Tributaria Espanyola 2.1.4.7. T-Aprenentatge. Anàlogament a les aplicacions d’“e-Learning”, les aplicacions de T- Aprenentatge o “T-Learning”, cobreixen tot un ventall d’aplicacions educatives, però en aquest cas, en l’àmbit de la televisió. Aquest ventall avarca des d’aplicacions que aporten material educatiu extra per a un programa en emissió fins a aplicacions interactives independents que segueixen el progrés d’aprenentatge de l’usuari. 2.1.4.8. T-Salut. El terme “T-Salut” cobreix bàsicament qualsevol tipus d’aplicació de televisió digital referida a temes mèdics i sanitaris. Existeixen aplicacions d’aquest tipus amb un elevat grau d’interactivitat i completament bidireccionals, que a part de presentar informació medicosanitària, són capaces de connectar els pacients, o usuaris, amb les seves institucions sanitàries mitjançant la TDT. Aquests tipus d’aplicacions juntament amb les targes d’identificació intel·ligents possibilita realitzar accions tan quotidianes com realitzar consultes mèdiques o concertar visites sanitàries des dels receptors dels usuaris . Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 23 Il·lustració 9: Portal del Departament de Salut de la Generalitat de Catalunya 2.1.4.9. Business TV. Business TV és més aviat un escenari d’ús que no pas un tipus d’aplicacions de TV digital. Tanmateix, la idea de combinar serveis d’informació, comunicació, T-Comerç, T-Administració, i T-Aprenentatge, acosta a la televisió interactiva l’escenari conegut com a “Intranet” en el sector de les xarxes informàtiques. Les organitzacions poden utilitzar aquest tipus d’aplicacions per a proveir tota mena d’informació i comunicació als seus empleats, i en menor mesura, a socis de negocis i clients. Per posar un exemple, una societat alemanya d’arrendataris, ofereix a totes les seves cases, mitjançant la TDT, tot tipus d’informació per als seus llogaters i informació per a les persones potencialment interessades en els seus habitatges. 2.2. Les APIs. L’arribada de la televisió interactiva ha suposat la introducció a les llars dels descodificadors que transformen la senyal digital a analògica, adaptant-la als televisors, majoritàriament encara analògics. El nombre de fabricants de descodificadors i de components es molt elevat, i els avanços en matèria de hardware es succeeixen molt ràpidament. Aquí radica la Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 24 necessitat de les APIs (Aplication Program Interface). Una API és una capa intermèdia entre el hardware del descodificador i les aplicacions interactives, és a dir, és un llenguatge de programació que permet accedir a les funcionalitats del descodificador. La API permet la independència entre el llenguatge de programació de les aplicacions interactives respecte al hardware i el sistema operatiu del descodificador, permetent que aquests puguin evolucionar independentment. Les funcionalitats de les APIs són les següents: • Descodificar àudio i vídeo. • On Screen Display (OSD): Es tracta d’una o de diverses capes gràfiques sobre les quals es mostraran les aplicacions interactives. • Canal de retorn: És el mitjà amb el que l’usuari i el proveïdor de serveis es poden enviar o rebre dades. Habitualment es tracta d’un mòdem connectat a la xarxa telefònica, o bé, un tarja Ethernet. • Entrada d’usuari: EL comandament a distància, l’eina que utilitzarà l’usuari per a interactuar amb les aplicacions. • Accés a la CPU i a la memòria del descodificador. • Accés a dispositius d’emmagatzematge: Normalment discs durs integrats al hardware del descodificador. • Accés condicional (CA): Normalment mitjançant lectors de targetes intel·ligents. Al mercat actual han sorgit un gran nombre d’APIs per a la creació d’aplicacions interactives. Aquestes es poden dividir en dos grans grups que comentarem al punt següent, les APIs propietàries i les APIs estandaritzades. 2.2.1. Les APIs propietàries. Les APIs propietàries són apis orientades a un mercat vertical, on un únic proveïdor proporciona tot el necessari: les aplicacions, el software i hardware per a realitzar-les i fins i tot proporciona els receptors als seus abonats. Aquest tipus d’APIs és la utilitzada per les plataformes de pagament, a les que interessa tenir un control total sobre els continguts, i Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 31 Una altra cosa molt important que proporciona el MHP és un joc de proves de conformitat que ajuden a verificar quan una implementació MHP segueix les especificacions correctament. 2.2.2.1.3. Globally Executable MHP (GEM). Donat que l’MHP és un estàndard del DVB, està construït sobre altres estàndards DVB per a la transmissió digital com ara el “DVB Service Information” i els estàndards bàsics que defineixen com el vídeo i l’àudio són codificats i transmesos. Això és perfecte si s’usa una aplicació MHP sobre una xarxa DVB (com a la major part d’Europa o alguns països d’Àsia), però no és tan bo si la xarxa segueix els estàndards de radiodifusió digital americans. És per aquesta raó que el DVB va publicar l’especificació Globally Executable MHP (GEM). Aquesta està basada en el MHP versió 1.0.2 i elimina tots els elements que són específics dels estàndards DVB. A més, també afegeix un sistema per a que d’altres organismes d’estandardització puguin reemplaçar elements del GEM per altres tecnologies més rellevants en els seus mercats. Per exemple, l’organització japonesa ARIB ho ha usat per substituir el suport per “DSM-CC object carousel” pel suport per “DSMCC data carousel” que són usats en els estàndards ARIB. 2.2.2.1.4. Arquitectura de l’MHP. Amb la finalitat d’aconseguir els objectius d’interoperabilitat i de compatibilitat amb versions anteriors de l’estàndard, la plataforma s’organitza seguint una arquitectura en capes la qual podem veure a la següent figura: Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 32 Il·lustració 12: Arquitectura de l’MHP Un cop vista aquesta estructura podem comentar les diferents capes que la composen: • Capa de Recursos: És el nivell físic del terminal d’usuari, que inclou múltiples funcions del hardware, com per exemple el processat MPEG, els dispositius d’entrada i sortida, dispositius d’emmagatzematge, la CPU, etc. • Capa de Software: És la capa que ens proporciona el control sobre els recursos, i aïlla les aplicacions de les funcions del hardware. Aquesta capa consta de les següents parts diferenciades: o Application Manager (o Navigator): Com veurem més endavant, és el bloc encarregat de controlar el cicle de vida de les aplicacions i el seu correcte funcionament. o Protocols de transport. o Màquina virtual Java. o APIs de Java Sun, HAVI, DAVIC i DVB. OS, Drivers, Firmware, … APIs d’MHP Dades Llibreries Aplicacions interoperables MHP Màquina virtual Java (JVM) Application Manager APIs DAVIC Protocols de transport Plug-in específic Plug-in genèric APIs DVB APIs HAVI APIs SUN Capa d’aplicacions Capa de software Capa de recursos Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 33 • Capa d’APIs d’MHP: Aquesta capa ens permet associar els recursos del sistema a les nostres aplicacions, com per exemple: reproducció de vídeo, interpretació de comandes, accés a fitxers de dades, accés a recursos de hardware, etc. • Capa d’Aplicacions: És la capa on es situen les diverses aplicacions descarregades que utilitzen els serveis oferts per les capes anteriors. 2.2.2.1.4.1. Els Plug-ins. L’arquitectura de la plataforma MHP es complementa amb la capacitat d’admetre plug-ins, que aporten una gran flexibilitat a la mateixa. Un plug-in es defineix com un conjunt de funcionalitats que poden ser afegides a la plataforma, de tal forma que aquesta sigui capaç d’interpretar aplicacions i formats de dades que no han estat definits a l’especificació. Mitjançant el concepte de plug-in es resolen dos problemes simultàniament. Per un costat, s’aconsegueix que un ampli espectre d’aplicacions que han estat desenvolupades sobre altres plataformes puguin arribar a funcionar sobre una plataforma MHP, facilitant en certa mesura la adopció de l’estàndard a través d’una transició suau cap el mateix. D’altra banda, si es forcés la situació obligant a que totes les plataformes MHP funcionessin de la mateixa manera i amb les mateixes característiques, s’estarien eliminant elements diferenciadors que al cap i a la fi són els que permeten competir als proveïdors de terminals d’usuari. Utilitzant els plug-ins, aquests, poden incloure a la seva plataforma certes funcionalitats que d’altres proveïdors no ofereixen, mostrant d’aquesta manera un element diferenciador amb el qual competir. Per a poder realitzar la seva funció, aquests plug-ins han d’encaixar d’alguna manera a l’arquitectura de la plataforma, amb ho que es situen a les capes de software de l’arquitectura definides anteriorment, podent ser classificats per aquesta situació. Per un costat es tenen els denominats Plug-ins Interoperables, que son desenvolupats utilitzant la API Java de la plataforma i que, per tant, es situen a la capa d’aplicacions. D’altra banda es defineixen els Plug-ins d’Implementació Específica, que es realitzen en codi natiu, i que poden implementar una API Java no especificada, podent utilitzar les aplicacions que es desenvolupen sobre elles. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 34 Podem concloure en que DVB-MHP ja especificat una plataforma estàndard basant-se amb el coneixement acumulat d’experiències anteriors i tractant de proveir mecanismes que facilitin la seva adopció al mercat de la manera menys traumàtica possible. Per això, els seus principis de funcionament es basen en la definició d’uns perfils que marquen l’evolució de la plataforma, juntament amb una arquitectura pensada per a facilitar la portabilitat i interoperabilitat d’aplicacions que estan sotmeses a un cicle de vida molt definit. 2.2.2.1.5. L’Execució d’aplicacions MHP. En un receptor de televisió compatible amb MHP, la interactivitat s’implementa mitjançant l’execució d’una o més aplicacions. Conceptualment, una aplicació es defineix a l’especificació com “una implementació funcional, en forma de software, que s’executa en una entitat hardware o en un conjunt relacionat d’elles”. Les aplicacions MHP poden executar-se de manera concurrent, i poden comunicar-se i cooperar entre elles i amb els recursos del receptor. En qualsevol cas, l’execució d’una aplicació MHP sempre està sotmesa al control de l’anomenat Application Manager, un programari resident en el receptor que forma part de la implementació del middleware, i que controla el cicle de vida complet de l’aplicació o, dit d’una altra manera, controla en exclusiva quan es posa en funcionament i quan s’atura cada aplicació. Per prendre aquestes decisions, l’application manager pot basar-se en diversos factors. En alguns casos, pot rebre una petició provinent del programari del receptor, o fins i tot d’una altra aplicació en execució, com per exemple llançadores d’aplicacions o menús de serveis. De tota manera, la principal font a partir de la qual l’application manager basa el seu comportament és l’anomenada Application Information Table o AIT. L’AIT és una taula d’informació que s’afegeix a les especificades a l’estàndard d’informació de servei DVB-SI, i que essencialment informa de les aplicacions emeses en un transport stream. En particular, hi ha una AIT individual per a cada servei que, a més de descriure cada aplicació, especifica la seva vinculació particular amb aquest servei. A partir d’aquesta informació, i del servei que l’espectador hagi seleccionat, l’application manager iniciarà o aturarà les aplicacions. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 35 Il·lustració 13: Esquema d’execució d’aplicacions MHP A partir d’aquí, les possibles vinculacions entre una aplicació i un servei inclouen: • Inici automàtic: L’aplicació s’inicia automàticament quan l’espectador selecciona el servei. • Execució permesa: L’aplicació es pot iniciar a petició de l’espectador (normalment a través de la interfície resident del receptor), mentre el servei sigui el seleccionat. • Execució tolerada: Si l’aplicació està iniciada, i l’espectador selecciona el servei, es permet que continuï la seva execució. En cas contrari, no és possible iniciar-la. • Execució prohibida: Si l’aplicació està iniciada, i l’espectador selecciona el servei, s’atura immediatament. Independentment d’aquesta relació, una aplicació pot estar declarada com a limitada al servei (service bound), de manera que, en sortir d’ell, sempre s’aturi (encara que sigui tolerada pel nou servei seleccionat). A més, l’AIT també pot especificar quin perfil d’MHP necessita l’aplicació Application Manager Aplicació Emissió Espectador Aplicació Programari receptor Receptor Peticions Control Selecció de serveis Selecció d’aplicacions AIT Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 36 per poder funcionar, de manera que l’application manager la pugui descartar si el receptor no satisfà els requeriments. 2.2.2.1.6. L’Emissió d’aplicacions MHP. Com en un sistema informàtic convencional, una aplicació MHP també està formada per un conjunt de fitxers (executables, recursos, etc.) organitzats en directoris. Encara que, des de la versió 1.1 d’MHP, és possible obtenir les aplicacions a través del canal de retorn (també conegut com canal d’interacció), o fins i tot obtenir-les d’una memòria resident no volàtil del receptor, en el cas més paradigmàtic les aplicacions formen part de l’emissió de televisió, transmetent-se a través d’un elementary stream més de dades. Aquest medi, però, és un medi de transmissió unidireccional, de manera que cal trobar un compromís que permeti, d’alguna manera, emular un sistema de fitxers convencional en un entorn com aquest, on no és possible l’habitual intercanvi de peticions entre el client (el receptor) i un servidor (de fitxers). Amb aquest propòsit, i en lloc d’idear un mecanisme de nova construcció, l’especificació d’MHP aprofita part d’un altre estàndard anomenat DSM-CC (Digital Storage Media – Command and Control), concretament la definició del que es designa com a Object Carousel. Un object carousel està format per una sèrie de blocs de dades anomenats mòduls, que es transmeten cíclicament, de manera anàloga a les pàgines del teletext convencional. Per tant, tot i que un mòdul pot contenir un, diversos, o només part d’un fitxer (o definició de directori), es pot fer una simplificació conceptual i considerar que, d’aquesta manera, els fitxers de l’aplicació es transmeten un darrera de l’altre: Il·lustració 14: Esquema d’Object Carousel simple Per tant, quan l’application manager o la pròpia aplicació vulguin accedir al contingut d’un fitxer, hauran d’esperar a que el cicle de la transmissió hi arribi, cosa que, en el pitjor cas, pot obligar a esperar el temps d’un cicle complet. Per millorar el rendiment de les aplicacions, Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 37 però, hi ha diverses estratègies aplicables. D’una banda, els receptors usualment implementen mecanismes de caché o càrrega anticipada de parts o de mòduls complets. De fet, les pròpies aplicacions poden indicar al receptor, en temps d’execució, quins fitxers hauria de precarregar si es presenta la possibilitat. Simultàniament, a més, els object carousels es poden planificar amb més detall per, sense perdre el seu caràcter cíclic, millorar el temps d’accés als fitxers més importants, incloent emissions redundants d’algun mòdul a dins del cicle general. Il·lustració 15: Esquema d’Object Carousel redundant A més de permetre representar una estructura de sistema de fitxers, però, els object carousels presenten algunes característiques addicionals, que resulten de gran utilitat en l’entorn de la televisió interactiva. D’una banda, el contingut d’un carousel pot ésser modificat d’un cicle a un altre, i MHP incorpora mecanismes per notificar les aplicacions d’aquest fet. Aquesta característica és especialment útil per implementar serveis d’informació (com una aplicació de notícies o d’estat del trànsit, per exemple), on els fitxers amb el contingut a publicar canvien amb certa freqüència. D’altra banda, un object carousel pot contenir, a més de fitxers i directoris, el que s’anomena com stream events. Aquests events (o notificacions), que no tenen res a veure amb els events de la terminologia DVB (que corresponien als continguts emesos per un servei), són unes marques que s’emeten en un moment donat, i que serveixen essencialment per permetre sincronitzar l’emissió de televisió amb el comportament de les aplicacions d’una manera arbitrària (establerta pel programador). 2.2.2.1.7. Model de les aplicacions. En MHP es defineixen dos models d’aplicacions que estan clarament diferenciats. Per un costat tenim les aplicacions DVB-J, basades en tecnologies Java, i per altre banda, les aplicacions DVB-HTML, basades en Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 38 l’ús de HTML i JavaScript. Encara que entre els dos models existeixen algunes diferències, es presenten algunes característiques comunes a totes elles. En primer lloc, com ja s’ha comentat anteriorment, les aplicacions presenten un cicle de vida molt definit, evitant el pas per estats incontrolats que podrien portar a la plataforma a inestabilitzar-se. De totes maneres, per a major seguretat, existeixen mecanismes que permeten que l’operador pugui controlar l’estat de les aplicacions mitjançant la senyalització des de la capçalera. En segon lloc, MHP permet la concurrència, es a dir, un mateix terminal pot estar executant diverses aplicacions al mateix temps. Això implica un control d’accés als recursos, que es realitza a través del Application Manager. Finalment, les aplicacions estan associades a un servei, es a dir, a un canal. El moment en el que l’usuari canvia de canal, la plataforma consulta quines aplicacions ha d’executar i procedeix en conseqüència. Per aquest fet, MHP especifica un mecanisme per a la senyalització d’aplicacions. D’aquesta manera, els desenvolupadors d’aplicacions només tenen que preocupar-se d’utilitzar les APIs disponibles. En el cas d’aplicacions DVB-J, aquestes són interfícies Java, recollides de múltiples fonts, com DAVIC, HAVI, JavaTV, i alguns de nou desenvolupament com el paquet org.dvb.si. Per a les aplicacions DVB-HTML, s’utilitza tecnologia HTML i ECMAScript, fent visible la API Java a aquest últim per a poder portar a terme l’accés a la plataforma. Ens centrarem a la plataforma DVB-j, donat que és la més madura i utilitzada a l’estàndard i la utilitzada en el present projecte. 2.2.2.1.7.1. Aplicacions DVB-J: Els Xlets. El primer tipus d’aplicació, des d’un punt de vista d’aparició cronològica, és el denominat DVB-J. Aquestes aplicacions estan constituïdes per un conjunt de classes Java que, per tant, s’executen en una màquina virtual Java present al receptor. Com s’ha explicat amb anterioritat, però, tota aplicació MHP ha d’estar sotmesa al control d’una entitat externa (l’application manager) i, per aquest motiu, les aplicacions DVB-J no poden estar construïdes com una aplicació Java tradicional, amb una classe executable d’entrada amb Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 39 control total sobre la màquina virtual. En el seu lloc, s’ha optat per seguir el model especificat en la plataforma JavaTV, elaborat amb una filosofia semblant a la dels Applets (classes inseribles a pàgines HTML, que també estan sotmeses en tot moment al control extern del navegador). Concretament, la classe principal d’una aplicació DVB-J és aquella que implementa la interfície javax.tv.xlet.Xlet, que únicament defineix quatre mètodes: - void initXlet(XletContext ctx) - void startXlet() - void pauseXlet() - void destroyXlet(boolean unconditional) Aquests quatre mètodes seran invocats per l’application manager quan sigui necessari i, en cada cas, s’espera que l’aplicació realitzi una acció coherent amb el significat de cada un d’ells. D’aquesta manera, per tant, s’estableix el cicle de vida d’una aplicació DVB-J, que és el representat en el següent diagrama: Il·lustració 16: Cicle de vida de les aplicacions DVB-J En aquest model, quan l’AIT així ho indica, l’application manager construeix un objecte de la classe principal de l’aplicació (l’Xlet), que entra en l’estat “Carregat”. Quan és el moment de començar la seva execució, invoca el mètode initXlet, amb el qual l’aplicació realitza les inicialitzacions necessàries i, en retornar, la deixa en un estat de pausa. A partir d’aquí, l’application manager pot traslladar l’aplicació entre els estats d’activitat, en el qual pot interactuar amb l’usuari; i pausa, on hauria d’alliberar el màxim dels recursos que ostenta, mitjançant la crida als mètodes startXlet i pauseXlet. Finalment, des de qualsevol dels estats l’application manager en pot decidir la destrucció mitjançant la crida a destroyXlet. Carregat Pausat Actiu Destruït initXlet startXlet destroyXlet destroyXlet destroyXlet pauseXlet Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 40 Fixant-se amb més detall en l’especificació dels mètodes de la interfície, però, es pot apreciar com el mètode initXlet rep com a paràmetre una referència a un objecte de la classe javax.tv.xlet.XletContext (en realitat es tracta d’una interfície). Aquest objecte és el recurs principal de què disposa l’aplicació DVB-J per comunicar-se amb l’application manager, ja que li permet, entre altres coses, sol·licitar un canvi del propi estat (que pot ser concedit o no). Un cop en funcionament, doncs, per dur a terme la seva activitat les aplicacions poden accedir a una versió limitada de la biblioteca de classes Java, basada en la versió 1.1.8 i encara més restringida per l’especificació d’MHP. Per tal d’accedir als recursos del receptor, a més, disposen d’un conjunt d’APIs format per una combinació de paquets estàndard de Java seleccionats, paquets provinents d’altres estàndards de televisió digital i paquets de nova creació, que serà explicada més endavant. Finalment, podem veure el que seria l’estructura bàsica d’un Xlet mitjançant una aplicació molt simple, únicament escriu diferents missatges quan es cridat cadascun dels mètodes, però que serveix per a comprovar el flux d’execució d’aquestes aplicacions: FirstXletExample.java // La classe principal de cada Xlet ha d’implementar aquesta // interfície, si no ho fa, el middleware MHP no el pot executar public class FirstXletExample implements javax.tv.xlet.Xlet { // Cada Xlet té un XletContext, similar al context dels Applets donats en una pàgina web. private javax.tv.xlet.XletContext context; // Atribut per desar si el Xlet s’ha iniciat per primer cop private boolean hasBeenStarted; // Cada Xlet hauria de tenir un constructor per defecte que no // tingués paràmetres. Cap altre constructor serà cridat. public FirstXletExample() {} // Inicialitza l’Xlet. El context per aquest Xlet serà passat // en aquest mètode i s’haurà de desar si és necessari més tard // Aquí és on s’ha de portar a terme qualsevol inicialització // a no ser que aquesta requereixi molt temps o recursos. public void initXlet(javax.tv.xlet.XletContext context) throws javax.tv.xlet.XletStateChangeException { this.context = context; hasBeenStarted = false; Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 47 televisiva (on el receptor té un control molt més reduït sobre la seva reproducció). Concretament, la correspondència entre els diferents tipus de contingut i els orígens d’on es poden obtenir es resumeix en aquesta taula: Contingut Fitxer Emissió Vídeo No Sí Animacions Sí Sí Àudio Sí (Clips en MPEG-1 Layer I/II) Sí (Emissió MPEG-2) Subtítols No Sí Taula 2: Relació Contingut-Origen de continguts multimèdia Fent una ullada a aquestes correspondències, es poden treure algunes conclusions. La primera i, probablement, més important d’elles és que una aplicació DVB-J no pot reproduir un vídeo qualsevol en el moment que vulgui. Això significa que, en aquest àmbit, les aplicacions es veuen limitades a seleccionar un elementary stream d’entre els que en un moment donat s’estiguin rebent com a part de l’emissió televisiva, i a realitzar un conjunt reduït d’operacions amb ell (reproducció, congelació, redimensionament i col·locació del vídeo). D’aquesta manera, per implementar aplicacions de vídeo sota demanda (com serveis de pel·lícules pay-per-view o retransmissions esportives multiangle) cal emetre simultàniament un nombre determinat d’streams de vídeo i, sobre aquesta emissió, implementar una aplicació que en seleccioni un o un altre. El mateix mecanisme existeix pels elementary streams d’àudio (per implementar serveis de fil musical, per exemple), encara que en aquest cas, donats els inferiors requeriments de memòria, l’estàndard també ofereix la possibilitat de reproduir arbitràriament petits clips emmagatzemats en fitxers de l’aplicació, el format dels quals, però, està restringit a MPEG-1 Layer I/II. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 48 Per la seva banda, les animacions estan emmagatzemades en un format de nova creació anomenat video drip, que essencialment és una simplificació del format complet MPEG-2. Aquestes animacions també es poden reproduir sota demanda, de manera que no han de superar certs límits de memòria i, per aquest motiu, generalment es transmeten en fitxers del carousel de l’aplicació. Finalment, encara que el seu volum no sigui un impediment, el fort lligam amb la temporització de la resta de l’emissió televisiva fa que els subtítols també s’emetin com un elementary stream, i que per tant el control de la seva reproducció estigui sotmès a les restriccions habituals en aquest casos. Així doncs, per poder implementar aquest mecanisme de funcionament, s’han incorporat una sèrie d’extensions i modificacions a JMF, que es poden classificar en dos grups. En primer lloc, i utilitzant un mecanisme ja previst pel propi JMF, hi ha una sèrie de controls que permeten realitzar les operacions de manipulació abans esmentades. Aquests controls estan repartits entre paquets de l’estàndard JavaTV, paquets de l’estàndard DAVIC i paquets de nova creació. El segon grup d’extensions sorgeix de la necessitat de representar els orígens dels diferents continguts multimèdia que, com s’ha vist, formen un conjunt heterogeni. Amb aquest propòsit, s’utilitza el concepte definit per la classe Locator, els objectes de la qual representen aquests orígens, que poden correspondre a un fitxer o a un stream de l’emissió. Un Locator es construeix a partir d’una URL i, a més de la reproducció de continguts multimèdia, també s’utilitza en altres àmbits de la plataforma DVB-J (per fer referència a serveis o a transport streams complets, per exemple). Per aquest motiu i, tot sigui dit, per una certa desorganització, aquest concepte està representat en diferents jerarquies de classes de la plataforma DVB-J: javax.media.MediaLocator i les seves subclasses (procedent de JMF, de propòsit general), javax.tv.locator.Locator i les seves subclasses (procedent de JavaTV, específic per la televisió digital), i org.davic.net.Locator i les seves subclasses (procedent de l’estàndard DAVIC, específic per l’àmbit DVB). 2.2.2.1.8.4. Accés a dades. Com s’ha esmentat diverses vegades, una aplicació està integrada per un conjunt de fitxers, que habitualment es transmeten en forma d’un Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 49 Object Carousel. Per tant, l’API de la plataforma DVB-J inclou, entre els seus paquets, diversos mitjans per a que les aplicacions puguin accedir aquests fitxers. El més simple, en aquest sentit, és l’ús de les classes del paquet java.io de la biblioteca de classes estàndard de Java, que està implementat a la plataforma DVB-J però que presenta certes limitacions. La solució a aquestes limitacions, de fet, és el que caracteritza a la segona alternativa, l’ús del paquet org.dvb.dsmcc. Aquest paquet, de fet, és l’API per treballar amb el protocol DSM-CC (el que especifica l’estructura d’un object carousel), i per tant ofereix més funcionalitats que les relatives al tractament de fitxers. De tota manera, només en aquest àmbit, el paquet permet: • Càrrega asíncrona. Els diferents fitxers d’un carousel s’emeten de manera cíclica, motiu pel qual la latència entre la petició i el final d’una càrrega pot arribar a ser molt gran. Per aquest motiu, mitjançant aquest paquet es permet a les aplicacions carregar els fitxers de manera asíncrona, és a dir, realitzant la petició i essent notificades de la seva arribada en instants diferents, sense bloquejar l’execució de l’aplicació en l’interval d’espera. • Gestió de caché. Donada la naturalesa del mitjà de transmissió abans descrita, en molts casos els receptors incorporen mecanismes de caché, amb els quals l’aplicació pot cooperar mitjançant aquest paquet. En particular, l’aplicació pot indicar quins fitxers precarregar i, a més, en realitzar una petició pot especificar si accepta una versió de caché o bé prefereix esperar a rebre la més actual possible de l’emissió. • Gestió de versions. Com s’ha explicat, el contingut d’un object carousel pot canviar d’una iteració a una altra del cicle. Mitjançant aquest paquet, les aplicacions poden ésser notificades quan es produeixen aquests canvis. • Accés a múltiples fonts. A través dels objectes del paquet, les aplicacions poden accedir a qualsevol dels object carousels emesos, i no només a aquell on hi és la seva classe inicial. A més dels object carousels, però, un receptor MHP pot disposar d’algun dispositiu d’emmagatzematge persistent, que també és accessible per les aplicacions mitjançant el paquet estàndard java.io, amb algunes extensions, relatives a permisos i atributs comuns dels fitxers en aquest Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 50 entorn, representades en les classes del paquet de nova creació org.dvb.io.persistent. Finalment, una aplicació també pot optar per una tercera via de més baix nivell per tal d’obtenir dades, consistent en accedir els blocs reservats a tal efecte en els streams MPEG-2, anomenats seccions privades, i a través dels quals s’emeten els object carousels o les taules d’informació de servei, entre d’altres. Aquesta funcionalitat està agrupada en les classes de paquet org.davic.mpeg.sections. 2.2.2.1.8.5. Canal de retorn. Com s’ha esmentat amb anterioritat, els dos perfils més elevats d’MHP (emissió interactiva i accés a Internet) contemplen l’existència d’un canal de retorn mitjançant el qual el receptor pot comunicar-se amb l’exterior. A partir d’aquí, però, l’especificació no imposa cap requeriment sobre la naturalesa d’aquest canal que, en la majoria dels receptors, sol tractar-se d’una connexió telefònica per mòdem, o bé d’una connexió permanent a una xarxa Ethernet. Per tant, si es troba disponible en el receptor, les aplicacions poden utilitzar el canal de retorn mitjançant dos paquets. El primer d’ells és el paquet org.dvb.net.rc, i inclou la funcionalitat necessària per establir la connexió amb el canal (fet especialment important en connexions per mòdem). Un cop establerta la connexió, per dur a terme la comunicació les aplicacions disposen d’un versió reduïda del paquet estàndard de la llibreria de classes java.net. La reducció en la funcionalitat d’aquest paquet prové del fet que l’especificació només obliga als receptors a implementar el protocol TCP/IP, establint com a opcional la implementació d’HTTP deixant la resta a les aplicacions. 2.2.2.1.8.6. Sincronització amb l’emissió. Durant el seu temps d’execució, i si els seus requeriments així ho fan necessari, el comportament d’una aplicació pot estar molt vinculat a l’emissió de la qual hi forma part. Concretament, en aquest temps existeix una relació d’influència mútua entre tots dos, ja que l’aplicació pot respondre a indicacions provinents de l’emissió, però simultàniament Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 51 també pot manipular-la en el seu benefici, obtenint informació sobre ella i filtrant, a ulls de l’espectador, el seu contingut. Per aquest motiu, l’API DVB-J proporciona els mitjans necessaris per implementar aquesta interacció. En primer lloc, per aconseguir que les aplicacions puguin ésser influïdes des de l’exterior, la plataforma DVB-J permet l’enviament, com a part d’un object carousel de l’emissió, d’uns objectes anomenats stream events, l’arribada dels quals és notificada a les aplicacions interessades, que poden respondre adequadament a partir d’aquell moment. Aquests stream events, bàsicament, presenten les següents característiques: • Immediats o programables. Un stream event pot ser llançat per tal d’ésser notificat a les aplicacions immediatament després d’arribar, o bé pot vincular-se a un instant del temps de referència de l’emissió. Aquesta darrera opció, a més de l’òbvia planificació avançada d’esdeveniments, permet realitzar emissions redundants d’un mateix event per tal de reduir el risc de pèrdua per un error de la transmissió. • Amb informació adjunta. Com si d’un missatge de correu electrònic es tractés, un stream event pot incorporar un bloc de dades amb significat arbitrari, que interpretarà l’aplicació destinatària. • Declaració obligatòria. Abans d’enviar cap stream event, cal incloure en el seu object carousel un conjunt dels anomenats stream event objects, que serveixen per declarar quins stream events s’espera rebre, atorgant-los un identificador únic vàlid. Aquesta aproximació presenta múltiples avantatges, ja que per una banda redueix la feina del receptor, que pot descartar aquells events que no estiguin declarats. A més, també permet que les aplicacions notifiquin per anticipat quins en volen rebre, evitant haver de processar-los tots. Finalment, aquest mecanisme proporciona un nivell d’estructuració addicional als programadors, que poden agrupar events de naturalesa semblant sota una mateixa declaració i reduir o eliminar la quantitat d’informació adjunta. Els stream events estan especificats a l’estàndard DSM-CC, de manera que el paquet que conté les classes pel seu processament és el ja esmentat org.dvb.dsmcc. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 52 Per la seva banda, l’altre sentit de la interacció aplicació - emissió, el que permet a la primera manipular els continguts de la segona, es pot dividir funcionalment en tres parts diferents. La primera d’elles, de fet, és en realitat una passa prèvia a les altres dues, ja que tracta de com les aplicacions poden obtenir informació sobre l’emissió actual. Aquesta informació, de fet, no és altra que la continguda al conjunt de taules d’informació de servei (estàndard DVB-SI) descrita anteriorment, per aquest motiu, el paquet on s’agrupen les classes és un de nova creació anomenat org.dvb.si. En particular, la funcionalitat proporcionada per aquest paquet inclou: • Accés a totes les taules de DVB-SI, excepte a l’AIT. Per tant, mitjançant aquesta API es pot obtenir informació sobre les xarxes, la seva organització física en transport i elementary streams, la seva organització lògica en serveis, events, i bouquets, i la correspondència entre tots dos esquemes. Per accedir a la informació de l’AIT, existeix una altra API que s’explicarà en el següent apartat. • Operació asíncrona. La informació de servei es transmet, de manera similar a la dels object carousels, de manera cíclica, i per tant entre la petició i l’arribada de la informació pot transcórrer un temps significatiu. Per aquest motiu, l’operació mitjançant aquesta API es realitza de manera asíncrona, permetent a les aplicacions continuar la seva execució mentre s’espera l’arribada de les dades (però també complicant una mica la programació com a contrapartida). • Notificació de canvis. Donada la naturalesa dinàmica de la informació de servei, l’API permet que les aplicacions interessades siguin notificades dels canvis que es puguin produir (per exemple, per actualitzar la informació de l’event o programa actualment emès, en una guia de programació). • Gestió de caché. Generalment, considerant el context on existeix aquesta informació de servei, els receptors disposen d’una còpia en memòria per accelerar les operacions d’accés. A partir d’aquí, l’API permet accedir de manera immediata a aquesta caché o bé, si no es pot comprometre la seguretat de disposar de la darrera informació, ignorar-la i esperar a l’arribada del següent cicle d’informació. Per tant, doncs, les aplicacions poden disposar d’una informació que pot resultar interessant consultar en alguns casos però que, en general, Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 53 resulta especialment útil per tal de filtrar i manipular el contingut de l’emissió. Concretament, mitjançant l’API de selecció de servei, una aplicació pot canviar el servei que actualment té seleccionat l’espectador, per un dels que hagi pogut trobar amb la consulta a les taules DVB-SI. A la plataforma MHP, aquesta API ha estat directament incorporada de JavaTV, i per aquest motiu les classes que ofereixen aquesta funcionalitat estan agrupades al paquet javax.service i als seus subpaquets. Per assolir una funcionalitat completa en aquest àmbit, però, encara falta una darrera barrera a superar. Com s’ha explicat anteriorment, diversos serveis estan normalment continguts en un mateix transport stream, que es correspon amb un canal físic del mitjà de transmissió. D’aquesta manera, en l’àmbit de la televisió digital hi ha una separació entre els canals físics i els canals lògics (els serveis), que també impregna l’API de la plataforma DVB-J. Per aquest motiu, de manera independent a l’API de selecció de servei, la plataforma inclou un altre conjunt de paquets dedicats al control de sintonització, de manera que una aplicació pot determinar quin transport stream ha de rebre el receptor en un moment donat. En la pràctica, això implica que, quan una aplicació vol canviar el servei seleccionat, ha de determinar prèviament si cal canviar de transport stream, i actuar (o no) en conseqüència. Aquesta API ha estat incorporada de l’estàndard DAVIC i per això està formada pel paquet org.davic.net.tuning. Durant l’ús d’aquestes dues darreres APIs, de fet, una aplicació ha de mantenir algunes precaucions addicionals. Principalment, i coneixent les possibles relacions entre aplicacions i serveis explicades, una aplicació ha d’ésser conscient que l’AIT del nou servei seleccionat pot implicar el final de la seva execució. 2.2.2.1.8.7. Interacció entre aplicacions. A l’apartat anterior, ja s’ha avançat el fet que l’API de selecció de servei permet consultar totes les taules de l’estàndard DVB-SI excepte l’AIT, que és precisament la que inclou la informació sobre les aplicacions MHP d’un servei. La importància d’aquesta taula, de fet, mereix un tractament diferenciat, no només perquè conté informació sobre les pròpies aplicacions en execució, sinó perquè aquesta informació és la base d’una altra API més potent: l’API de descoberta i llançament d’aplicacions, que es troba al paquet org.dvb.application. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 54 Com el seu nom indica, aquesta API proporciona dues funcionalitats ben diferenciades. D’una banda, permet a les aplicacions conèixer quines aplicacions estan presents en un moment donat, quin és el seu estat (en execució o no) i, en general, quins són els seus atributs (les dades allotjades a l’AIT). Així, l’estat en un moment donat dependrà del servei seleccionat (i de les seves aplicacions associades), així com de les reminiscències de serveis anteriorment seleccionats, algunes de les aplicacions dels quals poden haver estat iniciades i romandre encara en execució. L’accés a aquesta informació, a més, és lliure per a qualsevol aplicació, cosa que separa aquesta part de l’altra meitat de l’API: la que permet controlar el cicle de vida de les aplicacions existents. En la pràctica, això vol dir que, si una aplicació disposa dels permisos requerits, pot iniciar, aturar o pausar una altra aplicació (sempre indirectament, a través de l’application manager), així com ésser notificada dels canvis que es produeixin sense la seva influència (per exemple, quan es tanca l’aplicació). D’aquesta manera, és possible implementar un mecanisme bàsic d’interacció entre aplicacions, com per exemple el d’una aplicació de llançadora o menú. De tota manera, aquest model d’interacció entre aplicacions no és l’únic contemplat per la plataforma DVB-J ni, sobretot, el més sofisticat. Aquest adjectiu, en tot cas, hauria de ser patrimoni d’algun dels models que es poden construir mitjançant l’API de comunicació inter-Xlet que, essencialment, fa possible la cooperació entre diverses aplicacions concurrents. Així, es poden dissenyar sistemes més modulars on, per exemple, unes aplicacions implementin tasques generals, exercint de servidor i d’altres exercint d’aplicacions client. La base d’aquesta API és el sistema RMI (Remote Method Invocation) de Java, que estableix un protocol mitjançant el qual una aplicació pot publicar un conjunt dels seus objectes, els mètodes dels quals poden ser invocats per les aplicacions externes interessades. La implementació d’RMI està continguda a les classes del paquet java.rmi. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 55 2.2.2.1.8.8. Altres APIs. A més de les esmentades, la plataforma incorpora altres APIs amb propòsits diversos. D’una banda, DVB-J incorpora de l’estàndard JavaTV l’API de temporització que, mitjançant les classes del paquet javax.tv.util, proporciona a les aplicacions la possibilitat de programar esdeveniments dels quals seran notificades en un instant donat. En segon lloc, el paquet org.dvb.user incorpora classes que permeten a les aplicacions accedir a una sèrie de preferències d’usuari (normalment definides mitjançant els menús de configuració del receptor), entre les quals hi ha: - Informació regional (codi del llenguatge i del país). - Bloqueig parental. - Informació de l’usuari (nom, direcció postal i direcció d’e-mail). - Mida de lletra preferit. Finalment, utilitzant els mètodes de la classe java.lang.System, una aplicació DVB-J pot obtenir els valors sobre un conjunt de propietats que, bàsicament, l’informen sobre els perfils que implementa el receptor i, si ho desitja, sobre cada característica en particular (ja que algunes estan declarades com a opcionals, fins i tot en el perfil més avançat). Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 56 3. Descripció de l’aplicació. 3.1. Definició. Els Personal Video Recorders o PVRs són l’evolució natural dels ja gairebé obsolets Video Cassette Recorders o VCRs, i amb la seva arribada revolucionaran el món del broadcasting i la manera amb la que la societat veu la televisió, donat que donen la possibilitat als seus usuaris d’alliberarse de les limitacions provocades per la linealitat de la radiodifusió. Els PVRs, basats en dispositius d’emmagatzematge de tipus disc dur, poden proporcionar una sèrie de serveis que no poden igualar-se amb els serveis proporcionats per els tradicionals VCRs, com per exemple, la possibilitat de gravar i reproduir alhora continguts audiovisuals, utilitzar els “trick modes” (pausar, rebobinar, avançar, etc.) durant el visionat dels canals de broadcast, la programació de gravacions només prement un únic botó del comandament a distància, etc. La present aplicació permet explotar les funcionalitats dels terminals d’usuari amb dispositius d’emmagatzematge de tipus disc dur, i dotats de la interfície MHP versió 1.1.2 que comptin amb la API PVR. Cal notar que l’aplicació serà distribuïda als usuaris mitjançant el canal de broadcast, i aquesta pot ser genèrica per a tots els canals d’un mateix radiodifusor, generant d’aquesta manera un mercat de tipus horitzontal. 3.2. Historia. A finals de l’any 1999 les empreses TiVo i Replay TV van llançar una nova forma de veure la televisió al introduir al mercat gravadors de vídeo amb discos rígids inclosos. El funcionament d’aquests equips radicava en que la senyal de televisió, rebuda per cable o via satèl·lit, travessava la memòria del dispositiu i d’aquí era entregada a l’aparell de televisió per al seu visionat, d’aquesta manera, es feia possible la gravació i la reproducció simultània de la senyal televisiva, permetent als usuaris la possibilitat d’aturar, rebobinar o avançar la programació com si es tractés d’un simple reproductor de DVD o d’un VCR. Una de les possibilitats més innovadores d’aquests dispositius era la de poder elegir i programar el receptor per a l’enregistrament de qualsevol dels programes llistats a la guia de programació d’aquestes empreses. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 63 3.4.1. Arquitectura bàsica del MHP-PVR. Il·lustració 19: Arquitectura bàsica del MHP-PVR En aquest diagrama podem observar els seus elements principals de l’arquitectura dels PVRs, el “List of recordings” i el “Recording Manager”. El “List of recordings” o “Llistat de gravacions”, és un llistat de les gravacions realitzades i emmagatzemades al disc dur del dispositiu i de les gravacions pendents de realització. Aquest llistat de gravacions inclou informació de cadascuna de les seves entrades, ja siguin gravacions pendents o gravacions realitzades. La informació donada radica en la descripció de com ha de ser realitzada la gravació, o bé, de com ha estat realitzada, per tant, inclou dades com l’hora d’inici de la gravació, la seva durada, el servei enregistrat, el que ha d’ésser enregistrat o que és el que ha estat enregistrat, l’estat de la gravació, etc., així com qualsevol tipus de metadades descriptives definides per “DVB-Service Information” o bé, MHP PVR application TVAnytime Content Referencing API Recording Management API Playback API Time-shift API List of recordings Recording Manager Recording Engine Playback Engine Storage device TVAnytime Content Referencing Resolution Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 64 ”TVAnytime Content Referencing Specification”. Aquest element també ha de permetre la gestió d’aquestes gravacions, com per exemple: esborrarles, visualitzar-les o cancel·lar-les. D’altra banda, el “Recording Manager” és el responsable principal de la realització d’aquestes gravacions, i per tant, realitza les següents tasques: • Tractament de les gravacions pendents de realització. • Controla el “Recording Engine”, mitjançant la seva interfície, quan s’han de realitzar les gravacions. • Proporciona la informació necessària per als mecanismes d’indexació de continguts definits per “DVB-Service Information” o bé, ”TVAnytime Content Referencing Specification”. • Actualitza l’estat de les gravacions a la “Recording List” durant la seva realització. Si observem amb més detall l’estructura marcada per la norma, ens trobem amb la “Recording Management API”. Les aplicacions de tipus MHP-PVR poden utilitzar aquesta API per a la realització de diferents tasques, com per exemple: • Per a la petició de gravacions a realitzar. • Per a l’administració de les gravacions pendents. • Per a la recerca de gravacions realitzades o pendents segons qualsevol criteri de les seves descripcions. Com podem veure al gràfic, les aplicacions MHP-PVR poden utilitzar la “TVAnytime Content Referencing API” per a poder accedir a les metadades obtingudes per el “TVAnytime content referencing mechanism”. Anàlogament, també és completament vàlida la utilització dels mecanismes descrits per la “DVB-SI API” per a l’obtenció d’aquestes metadades referides als serveis i programes televisius. L’habilitat de pausar els directes de televisió ve suportada per la “Time-shift API”, que proporciona els mecanismes de control sobre el “Recording engine”, el “Playback engine” i el buffer del set-top box. Finalment la “Playback API”, és l’element que s’encarrega de la reproducció de les gravacions ja realitzades, amb el que és capaç de controlar el “Playback engine” a partir de la informació obtinguda de la “Recording list”. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 65 3.4.2. El procés de gravació i reproducció. A continuació descriurem els processos de gravació i reproducció definits per la norma a tots els escenaris d’utilització possibles. 3.4.2.1. Gestió de gravacions planificades. La norma indica que el procés de gestió de gravacions programades o planificades ha d’incloure les següents activitats: • Mantenir una llista de peticions d’enregistrament que romanen en l’estat de pendent fins, com a mínim, a l’expiració del període de validesa de cadascuna de les peticions. • Mantenir una llista que contingui les peticions d’enregistrament que hagin estat completades amb èxit, les que hagin estat iniciades correctament però no hagin pogut ser finalitzades de forma satisfactòria, i les gravacions planificades que no hagin pogut ser iniciades per qualsevol motiu. • Iniciar el procés de gravació de les gravacions pendents en el moment adequat, incloent la gestió de l’estat del receptor en el cas de que aquest es trobi en “standby”. • Detectar conflictes entre les múltiples peticions d’enregistrament i conflictes entre aquestes peticions i els recursos dels sistema. • Resoldre els possibles conflictes generats per les noves gravacions en front a les gravacions ja planificades. Nota: El document no defineix intencionadament ni els algorismes ni els mecanismes de resolució de conflictes. L’únic requeriment és que la implementació ha de incloure aquest mecanisme. • Incloure DVB-SI metadata associada a les peticions d’enregistrament. 3.4.2.2. El procés de gravació. La norma indica que el procés de gravació o enregistrament ha de realitzar les següents activitats: Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 66 • Identificar quins fluxos de vídeo enregistables han de ser enregistrats. Si es tracten de fluxos de vídeo especificats quan la gravació va ser programada, l’aplicació ha de ser capaç de sintonitzar-los i enregistrar-los. Si els fluxos de vídeo no van ser especificats quan es programà la gravació, aleshores haurà de ser enregistrat el canal sintonitzat per defecte. • Enregistrar els fluxos de vídeo identificats tenint en compte les capacitats limitades dels receptors. Si no es possible l’enregistrament simultani de diversos fluxos audiovisuals per les limitacions tècniques del terminal d’usuari, s’hauran d’implementar mecanismes per a la resolució del conflicte tenint en compte les prioritats d’aquestes gravacions. • Enregistrar suficient informació sobre les línies temporals que formen part d’un gravació amb el propòsit de permetre que puguin ser correctament reconstruïts durant la seva reproducció. • Generar un “media time” que s’incrementi linealment amb un índex de 1,0 des del principi fins al final de la gravació. • Enregistrar suficient informació del DVB-SI associada a la gravació realitzada, que permeti la seva descripció i identificació. • Tractar els següents casos relacionats amb la interrupció de l’energia del terminal durant una gravació planificada en els següents casos: - S’està realitzant la gravació i el terminal es queda sense energia. - La gravació s’hauria d’haver iniciat mentre que el terminal no disposava energia, però aquesta retorna abans del final de la gravació programada. • En tots els casos, el terminal ha d’enregistrar tots els continguts que li siguin possibles. • Adquirir els permisos del radiodifusor sobre els continguts a enregistrar. En el cas de que l’enregistrament d’aquests continguts no sigui permès, l’enregistrament no haurà d’iniciar, i la petició d’enregistrament passarà a l’estat “FAILED_STATE”. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 67 3.4.2.3. Gestió de gravacions completades. La norma indica que el procés per al tractament o gestió de les gravacions completades ha d’incloure les següents activitats: • Mantenir juntament amb totes les gravacions realitzades (COMPLETED_STATE O INCOMPLETE_STATE) la següent informació mentre aquestes segueixin emmagatzemades al terminal. - El canal i l’hora en la qual es va realitzar la gravació. - Les dades especifiques de l’aplicació associades amb la gravació. - Si la gravació és completa o incompleta, o simplement si es desconeix aquesta informació. - Les metadades descriptives relacionades amb els continguts enregistrats. • Donar la possibilitat d’esborrar les gravacions (incloent les seves entrades a la “List of recordings”, les dades enregistrades i qualsevol altre informació associada ) un cop s’hagi sobrepassat l’“expiration period” corresponent a la gravació. 3.4.2.4. El procés de reproducció. La norma indica que el procés de reproducció ha d’incloure les següents activitats: • Iniciar la reproducció de clips enregistrats. • Quan s’està reproduint un contingut que alhora està sent enregistrat, si s’arriba al final del contingut que ha de ser enregistrat i finalitza el procés de gravació, la reproducció ha de continuar sense cap tipus d’interrupció, independentment de qualsevol procés d’emmagatzematge i gestió de buffers. • S’ha de generar una línia temporal des de l’inici al final del contingut enregistrat. Aquesta línia temporal s’ha d’utilitzar com a la base de temps i “media time” definides per Java Media Framework. • En la reproducció de gravacions formades per múltiples segments, aquests segments han de ser tractats com a una única gravació. Aquests segments han de ser reproduïts en el mateix ordre en el que van ser enregistrat i seguint la línia de temps Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 68 descrita en el punt anterior. El temps de transició en la reproducció entre dos segments ha de ser minimitzat. Cal a dir que els events (o notificacions) generats quan la reproducció arriba a l’inici o al final del contingut enregistrat, han de ser tractats i suportats per l’aplicació. 3.4.2.5. Timeshift. El “Timeshift” aporta al PVR la funcionalitat de gaudir del “fals directe”, per tant, disposa dels processos de reproducció i enregistrament. El procés d’enregistrament ha d’incloure les següents activitats: • Identificar el flux de dades a enregistrar i emmagatzemar-lo al buffer de timeshift. • Identificar les línies temporals transmeses del contingut enregistrat i emmagatzemar suficient informació per a que sigui possible una reproducció acurada. • Gestionar el buffer de timeshift de tal forma que quan aquest estigui ple, la gravació continuï de forma progressiva sobre el contingut mes antic emmagatzemat. El procés de reproducció ha d’incloure les següents activitats: • El comportament de la reproducció ha de ser el següent: Situació Comportament Esdeveniment Java Avanç ràpid fins al final del buffer timeshift. Canviar la taxa de reproducció a x1sense destruir el contingut del buffer de timeshift. EndOfContentEvent + EnteringLiveModeEvent Rebobinat fins l’inici del buffer de timeshift. Canviar la taxa de reproducció a x1 i començar a reproduir des del BeginningOfContentEven t Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 69 principi del buffer. Reproducció fins al final del buffer de timeshift. Passar a reproduir els continguts rebuts en directe. EnteringLiveModeEvent Pausa o reproducció amb una taxa menor de x1 fins que ocasiona que el buffer s’ompli y aquest es sobreescrigui fins punt de la reproducció. Canviar la reproducció a x1des del punt actual del buffer. BeginningOfContentEven t Taula 1: Comportament del procés de reproducció • Per a totes les línies temporals transmeses vàlides en el buffer de timeshift, reconstruir cada línia temporal quan el temps de la reproducció actual es trobi en el rang per al qual aquesta línia temporal és vàlida. • La línia temporal per a cada ubicació en el buffer de timeshift serà el valor assignat a aquesta ubicació en el punt que es va gravar . No han d’haver discontinuïtats a les línies de temps en el contingut del buffer, incloent l’inici del buffer, on el contingut és el mateix que el contingut rebut actualment. • Situar el punt de reproducció a un valor corresponent a POSITIVE_INFINITY ha d’establir la posició de reproducció al punt d’enregistrament actual si la gravació és encara en curs, o, si no, al final de l'enregistrament . • Si la posició de reproducció és la mateixa que el punt d’enregistrament (és a dir, s'està reproduint el directe), el contingut s’ha de visualitzar sense retards en relació amb el contingut d'emissió original. Les implementacions que puguin reproduir el contingut enregistrat sense cap tipus de retard en relació amb continguts en directe, poden reproduir el contingut Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 70 enregistrat. Les altres implementacions han de mostrar el contingut de l'emissió del directe . 3.4.3. APIs de gravació i reproducció. Les APIs de gravació permeten a les aplicacions realitzar gravacions de dues maneres diferents: • Programar una gravació per a que aquesta sigui realitzada en algun moment futur. • Enregistrar continguts audiovisuals provinents d’emissions en directe. Això també pot incloure les parts del continguts audiovisuals que es troben emmagatzemats al buffer de timeshift. L’aplicació ha de mantenir una base de dades dels enregistraments, representada per l’objecte “RecordingManager”. Aquest objecte també permet realitzar dites gravacions mitjançant la crida del seu mètode “record()”. Aquesta operació afegeix una nova entrada a la base de dades d’enregistraments. Aquestes entrades estan representades per instancies a l’element “RecordingRequest”. Quan es crea un enregistrament, les aplicacions especifiquen un conjunt de paràmetres. Un d’aquests paràmetres és el període de caducitat, mesurat des del moment en el que es va realitzar la gravació. Un cop s’ha superat aquest període de caducitat, la implementació ha d’esborrar la gravació. Les aplicacions poden adquirir un conjunt d’enregistraments, representats per l’objecte “RecordingList”. Aquest conjunt d’enregistraments pot ser filtrat mitjançant l’objecte “RecordingListFilter”. Aquests filtrat es pot realitzar mitjançant filtres creats per la mateixa aplicació, o be, per filtres prèviament definits per la API. Els filtres poden ser utilitzats en cascada, de forma que la sortida d’un filtre pot ser l’entrada per a un filtre posterior. Quan els continguts audiovisuals comencen a ser enregistrats per a una gravació programada, es crea un objecte anomenat “RecordedService”. Aquesta classe és una extensió de la interfície JavaTV i serveix com a pont entre la API de gravació i la API de reproducció. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 71 D’altra banda, les APIs de reproducció permeten a les aplicacions realitzar les reproduccions de dues maneres diferents, depenent de si es volen o no iniciar les aplicacions que poden formar part de la gravació: • Executant el mètode select(Service) d’un “ServiceContext” passant-li com a paràmetre un objecte “RecordedService”, reproduirà tots els components del servei incloent-hi totes les aplicacions senyalitzades com “autostart” que hi hagin enregistrades. • Executant el mètode getMediaLocator() d’un “RecordedService” i passant-li el resultat al mètode createPlayer(MediaLocator) de la classe javax.media.Manager. D’aquesta forma, al cridar al mètode start() o syncStart() s’iniciarà únicament la reproducció dels continguts audiovisuals i no pas de les possibles aplicacions enregistrades. Un cop iniciada la reproducció, existeixen dues opcions que permeten tenir el control sobre ella: • Utilitzant els controls de Java Media Framework retornats pel mètode Player.getControl(String) per a funcions com la selecció d’idiomes i escalat d’imatge. • Utilitzant Player.setRate(float) per a controlar la velocitat de reproducció incloent-hi els canvis entre velocitat de reproducció normal, avançament ràpid (FF), rebobinatge (RW) i pausa. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 72 4. Contextualització tècnica. Per a poder comprendre l’estructura de l’aplicació desenvolupada en el present projecte és necessari detallar primer el sistema de creació i emissió d’interactius utilitzada per Activa Multimèdia Digital. 4.1. El sistema de creació i emissió d’interactius d’Activa Multimèdia. El sistema d'interactius d'Activa Multimèdia consta d'una plataforma d'emissió de serveis de dades (HandData), un motor d'aplicacions interactives (Digital FingerText), i una llançadora d'aplicacions que s'executa al terminal de l'usuari per permetre la navegació als serveis interactius oferts pel radiodifusor. 4.1.1. HandData. HandData és la plataforma d’emissió de serveis de dades desenvolupada per Activa Multimèdia Digital. Està dissenyada per a controlar, gestionar i emetre serveis de dades sobre xarxes d’emissió terrestres, satel·litals o de cable. A la següent imatge podem veure la interfície d’usuari de l’aplicació. A la seva part esquerra ens trobem l’arbre de navegació dels diferents serveis de dades en emissió, a la part dreta els paràmetres configurables d’aquest serveis de dades, a la part superior les accions disponibles sobre els serveis de dades i els seus paràmetres, i a la part inferior la resposta del sistema a les accions realitzades sobre ell. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 79 aplicacions. A la següent imatge podem veure un exemple d’aquesta aplicació: Il·lustració 27: Llançadora de TVE 4.2. L'entorn de desenvolupament. 4.2.1. iTextTools. La suite iTextTools és un conjunt d’eines creades per Activa Multimèdia Digital enfocades al procés de creació, disseny, configuració i edició de continguts d’aplicacions interactives per TDT basades en el motor DigitalFingerText. Les eines que composen aquesta suite son les següents: • iTextCompositor: iTextCompositor és una eina que permet la creació, disseny i edició de l’apartat gràfic de les aplicacions basades en Digital FingerText. L’aplicació permet crear mitjançant un entorn visual el que serà el layout de l’aplicació interactiva. A la següent imatge podem veure la interfície d’usuari de l’aplicació. A la part superior esquerra ens trobem el ventall d’elements o beans disponibles al motor i a la part inferior esquerra apareixen els beans utilitzats al layout que s’està dissenyant. La part central està destinada a mostrar de forma gràfica el resultat final del disseny i a la part dreta de la interfície apareixen els paràmetres configurables dels beans seleccionats. Finalment, la part inferior de la interfície mostra a l’usuari el resultat de les operacions realitzades sobre el layout. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 80 Il·lustració 28: Entorn d’usuari d’iTextCompositor L’eina fa ús del sistema “Drag and Drop”, permetent arrossegar els elements disponibles a la zona de treball que mostra el layout final per a col·locar-los a la posició desitjada. Aquest fet ajuda a minimitzar el temps necessari per a la creació de les plantilles de les aplicacions. L’eina tradueix el layout creat en pantalla en documents XML que serviran de base per a crear posteriorment els fitxers de propietats gràfiques de l’aplicació MHP. • iTextContent: iTextContent és una aplicació web que permet l’edició dels continguts de les plantilles generades prèviament amb iTextCompositor. L’eina bàsicament afegeix les imatges i els textos dels elements que formen cada una de les planes de l’aplicació. iTextContent proporciona als responsables de continguts una forma ràpida i àgil d’editar la informació textual i gràfica, i també permet mantenir les aplicacions actualitzades sense haver de recompilar-les després de cada modificació dels continguts a mostrar. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 81 L’aplicació permet previsualitzar el resultat final de cada una de les planes de les aplicacions, i esta connectada mitjançant la xarxa ethernet a les capçaleres d’emissió, fet que permet publicar els continguts a les aplicacions maquetades. De la mateixa forma que iTextCompositor, iTextContent genera els fitxers XML que serviran per a generar els fitxers de continguts de les aplicacions MHP. A la següent imatge podem veure la pantalla d’accés al sistema d’edició de continguts. Il·lustració 29: Pantalla d’accès a iTextContent • iTextPacketizer: ITextPacketizer és l’aplicació encarregada de convertir els fitxers XML generats anteriorment amb iTextCompositor i iTextContent en el format que interpreta el motor de Digital FingerText. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 82 Il·lustració 30: Esquema de conversió de formats realitzada per l’iTextPacketizer Desprès d’aquest canvi de format, empaqueta aquests fitxers de propietats juntament amb els recursos dels que consta l’aplicació (imatges, mòduls extra i classes Java) en el format d’emissió final. Il·lustració 31: Esquema de l’empaquetament realitzat per l’iTextPacketizer Finalment, desprès de veure la funcionalitat de cadascuna de les eines que formen la suite iTextTools, és senzill d’entendre l’esquema de treball per a la creació d’aplicacions interactives. Classes XML XSL GFX iTextPacketizer Format d’edició Format d’emissió Classes XML XSL GFX iTextPacketizer iTextCompositor iTextContent Edició de grafisme Edició de continguts Conversió de format Digital FingerText Format d’emissió Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 83 4.2.2. Eclipse IDE & Osmosys SDK. Eclipse és un Entorn de Desenvolupament Integrat, de l’anglès Integrated Development Environment (IDE), per a tot tipus d’aplicacions, inicialment desenvolupat per IBM i actualment gestionat per la fundació eclipse. Aquesta eina de disseny, està principalment desenvolupada per a la creació d’aplicacions en llenguatge Java, facilitant al màxim la gestió de projectes col·laboratius mitjançant el control de versions “cvs”. Un dels trets més potents d’aquest entorn de programació, és la possibilitat d’afegir a l’editor noves funcionalitats a través de nous mòduls o “plugins”. Un d’aquests plugins és l’”Osmosys SDK”. Il·lustració 32: Entorn de desenvolupament del plugin “Osmosys SDK” L’Osmosys SDK, com hem dit anteriorment, és un plugin per a l’entorn de programació Eclipse, desenvolupat per Osmosys Technologies, que permet als desenvolupadors crear tant aplicacions MHP com aplicacions OCAP. Aquest SDK suporta la creació d’aplicacions DVR (Digital Video Recoring) i té la capacitat de poder processar fluxos de transport (transport streams) emmagatzemats al disc dur. La principal funcionalitat d’aquest entorn, és la capacitat de poder testejar les aplicacions generades utilitzant el seu emulador propi, o bé, utilitzant un descodificador connectat al PC per port sèrie. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 84 4.3. L’entorn de proves. Per a la realització de les proves de la present aplicació s’ha utilitzat una capçalera d’emissió de televisió digital terrestre gestionada per la plataforma d’emissió HandData descrita anteriorment. Com a descodificador, s’ha utilitzat un prototip del fabricant ADB, l’ADB- 5810TX. Il·lustració 33: Descodificador ADB-5810TX L’ADB-5810TX és un descodificador de televisió digital terrestre d’ alta gama amb capacitats de DVR (Digital Video Recorder). Incorpora l’estàndard MHP v1.1.2 i disposa d’un disc dur intern de 80GB, condicions indispensables per al correcte funcionament de la present aplicació. Les seves principals característiques son les següents: • Doble receptor de TDT. • Compatible amb l’estàndard MHP v1.1.2. • Funcionalitat de DVR (Digital Video Recorder). • Formats de vídeo suportats: - MPEG-1 (SD) - MPEG-2 MP@ML (SD) i MP@HL (HD) - MPEG-4 p.10 (H.264) MP@L3 (SD) i [email protected] (HD) • Resolucions de vídeo suportades: - 1080i - 720p - 480p/576p - 480i/576i Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 85 • Formats d’àudio suportats: - MPEG-1 Layers I, II, III (MP3) - MPEG-2 Layer 2 - MPEG-2 AAC LC and AAC+ - MPEG-4 AAC LC 2-channel/5.1, MPEG-4 AAC+SBR 2- channel/5.1 • Canal de retorn: IEEE 802.3 10/100 Ethernet. • Unitat d’emmagatzematge: Disc dur de 80GB. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 86 5. Desenvolupament de l'aplicació. Un cop vista l’arquitectura de les aplicacions interactives basades en Digital FingerText podem passar a detallar el disseny del present Personal Video Recorder. Aquest disseny consta d’una part gràfica, les pantalles que donen accés als usuaris a les funcionalitats del PVR, i d’una part lògica, que es la que s’encarrega d’implementar aquestes funcionalitats brindades pel Personal Video Recorder. L’aplicació està formada per quatre pantalles i dos mòduls extra que implementen la part lògica, per tant, tenint en compte l’arquitectura de les aplicacions realitzades amb el motor de Digital FingerText, l’estructura de l’aplicació correspon al següent esquema: Il·lustració 34: Arquitectura de l’aplicació 5.1. La interfície d'usuari. La interfície d’usuari correspon a l’apartat gràfic de l’aplicació. Està formada per quatre pantalles, i com hem vist al punt anterior, cadascuna Logic Manager Mòdul PVR Mòdul Teclat virtual Digital FingerText Pantalles Gestió Inici Control EPG Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 87 d’elles està generada a partir d’un fitxer de layout i un altre fitxer de continguts generats a partir de la suite iTextTools d’Activa Multimèdia Digital. Aquestes pantalles són: • Menú d’inici: És la pantalla inicial de l’aplicació la qual permet als usuaris accedir a la resta de pantalles. • Control de vídeo: La qual brinda als usuaris les funcions típiques d’un PVR, es a dir, gravació, “timeshifting”, control de reproducció, etc. • Guia electrònica de programació: La qual mostra la programació del canal on està sintonitzat el Personal Video Recorder. D’es d’aquí els usuaris poden programar la gravació dels diferents events mostrats a la guia amb un sola pulsació al comandament a distància. • Gestió de gravacions: És la pantalla que permet a als usuaris administrar les gravacions realitzades o programades. D’es d’aquí, l’usuari pot reproduir les gravacions realitzades, consultar les gravacions programades, veure l’estat de les programacions o gravacions i eliminar les gravacions o programacions que l’usuari desitgi. Un cop enumerades les pantalles que formen la interfície d’usuari, passem a detallar-les en major profunditat. 5.1.1. La pantalla Menú d'inici. La pantalla “Menú d’inici”, com el seu propi nom indica, es un simple menú que permet als usuaris navegar entre les diferents pantalles de l’aplicació. Aquesta pantalla està formada per quatre beans, un bean tipus “Icon” i tres beans tipus “Link”. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 88 Il·lustració 35: Pantalla “Menú d’inici” Els beans tipus “Icon”, presenten una imatge en pantalla en la posició indicada. No són navegables i tampoc poden generar cap acció sobre el motor o els mòduls extra. Es a dir, presenten en pantalla imatges simplement decoratives o informatives. Els beans tipus “Link”, presenten en pantalla una imatge en la posició indicada i poden enviar events (notificacions) o accions al motor i als mòduls extra, per tant, són elements actius dins de la plana. En la present plana, ens trobem aquests beans de la següent forma: • Bean tipus “Icon”: És l’encarregat de mostrar la següent imatge: Il·lustració 36: Contingut del bean tipus “Icon” • Beans tipus “Link”: Estan encarregats de proporcionar la navegació a la resta de pantalles. Per a realitzar aquesta acció, envien una notificació al motor que fa que aquest carregui i mostri la pantalla indicada. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 95 directe” com si es tractés de la reproducció d’un vídeo enregistrat. Aquesta opció llança l’acció PVR_Pause del mòdul extra PVRModule, que descriurem més endavant, per a realitzar questa tasca.  RW: La opció RW del menú permet als usuaris rebobinar els continguts audiovisuals reproduïts pel PVR. Aquesta opció està disponible tant si s’està reproduint un vídeo enregistrat anteriorment com si s’està reproduint un canal rebut “en directe”. En el cas de rebobinar un canal rebut “en directe”, el reproductor o “player” del PVR fa ús del buffer de reproducció, que conté els continguts audiovisuals rebuts anteriorment per anar-los visualitzant de forma inversa, i alhora, continua emmagatzemant en aquest buffer els continguts rebuts per antena. Al executar repetidament aquesta opció del menú la velocitat de reproducció inversa varia de forma cíclica segons la següent progressió “2x”-“4x”-“8x”-“16x”-“32x”. Un cop s’arriba a l’inici del buffer de reproducció o a l’inici del vídeo enregistrat anteriorment, el vídeo passa a ser reproduït des d’aquest inici a una velocitat de “1x”. Aquesta opció del menú executa l’acció PVR_Reverse del PVRModule que modifica la velocitat de reproducció del reproductor i representa en pantalla els beans que indiquen la velocitat de reproducció actual en el cas de que aquesta sigui diferent de “1x”.  FF: La opció FF del menú permet als usuaris fer córrer endavant els continguts audiovisuals reproduïts pel PVR. Aquesta opció està disponible tant si s’està reproduint un vídeo enregistrat anteriorment com si s’està reproduint un canal en “fals directe”. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 96 En el cas d’estar visionant un canal en “fals directe”, el reproductor del PVR fa ús del buffer de reproducció, que conté els continguts audiovisuals emmagatzemats anteriorment per anar-los visualitzant de forma accelerada, i alhora, continua emmagatzemant en aquest buffer els continguts rebuts per antena. Cal a dir que si el PVR està reproduint un canal rebut “en directe” questa opció no està disponible donat que el buffer de reproducció no disposa dels continguts audiovisuals necessaris ja que encara no han estat rebuts. Al executar repetidament aquesta opció del menú la velocitat de reproducció s’accelera de forma cíclica segons la següent progressió “2x”-“4x”-“8x”-“16x”-“32x”. Si s’està reproduint un canal en “fals directe”, un cop s’arriba al final del buffer de reproducció el vídeo passa a ser reproduït a una velocitat de “1x”, donat que es passa de reproduir el canal en “fals directe” a visionar el canal “en directe”. En el cas de que s’estigui reproduint un vídeo enregistrat anteriorment, al arribar al final d’aquest vídeo, el player del PVR passa a reproduir el canal en el que estava sintonitzat abans de començar la reproducció d’aquest vídeo. Aquesta opció del menú executa l’acció PVR_Forward del PVRModule que modifica la velocitat de reproducció del reproductor i representa en pantalla els beans que indiquen la velocitat de reproducció actual en el cas de que aquesta sigui diferent de “1x”.  Stop: La opció Stop del menú de control de vídeo permet als usuaris aturar les gravacions iniciades mitjançant la opció REC d’aquest mateix menú. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 97 La opció no te cap utilitat si no s’està realitzant cap gravació o si s’està realitzant una gravació programada mitjançant la pantalla “Guia Electrònica de Programació” que veurem més endavant. L’acció executada per aquesta opció del menú és l’acció PVR_Stop del mòdul extra PVR_Module que descriurem posteriorment.  TV: La opció TV d’aquest menú permet als usuaris tornar a reproduir el canal d’origen en el cas de que el reproductor estigui reproduint un vídeo enregistrat anteriorment. Ens referim a “canal d’origen” com el canal en el que estava sintonitzat el descodificador abans d’iniciar la reproducció del vídeo enregistrat. Cal a dir que aquesta opció no te cap utilitat en el cas de que s’estigui reproduït un canal, ja sigui “en directe” o en “fals directe”. Aquesta opció del menú executa l’acció PVR_Return del PVRModule que veurem més endavant. o Menú de resolució de conflictes temporals en les gravacions: Aquest bean apareix en pantalla en el cas de que es detecti un conflicte temporal a l’hora de realitzar una gravació mitjançant el boto REC del menú de control del PVR, es a dir, que la gravació a realitzar es solapi temporalment amb alguna gravació programada mitjançant la pantalla “Guia Electrònica de Programació”. El bean representa en pantalla un menú vertical amb tres opcions que permeten a l’usuari actuar per a solucionar aquest conflicte. A la imatge següent podem veure el menú representat en pantalla així com la seva imatge de selecció. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 98 Il·lustració 45: Bean de tipus “MenuLite” de resolució de conflictes L’usuari pot interactuar amb aquest menú utilitzant les tecles del comandament a distància del seu receptor. Les tecles utilitzades son: les tecles direccionals amunt i avall per a navegar entre les diferents opcions del menú i la tecla “OK” per a executar l’opció seleccionada en aquell moment. Un cop executada l’opció seleccionada el bean desapareix de la pantalla. A continuació passarem a detallar les opcions que composen aquest menú citant les accions que criden als mòduls extra que descriurem més endavant:  Modificar l’hora d’inici i la durada de la nova gravació: Aquesta opció del menú modifica l’hora d’inici i la durada de la nova gravació per tal de que no entri en conflicte amb cap de les gravacions programades. De forma gràfica vindria a ser el següent: Gravació programada t t Gravació programada Gravació programada Gravació programada Nova gravació Nova gravació Il·lustració 46: Estratègia de resolució de conflictes Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 99 Aquesta opció del menú executa l’acció PVR_Modif del mòdul extra PVRModule que veurem posteriorment.  Cancel·lar la nova gravació: Aquesta opció del menú cancel·la la realització de la nova gravació deixant intactes les gravacions programades que entraven en conflicte amb ella. Per a realitzar tal tasca, aquesta opció del menú executa l’acció PVR_Cancel del PVRModule.  Cancel·lar les gravacions conflictives: Aquesta opció del menú cancel·la les gravacions conflictives permetent d’aquesta manera la realització de la nova gravació. Aquesta opció del menú executa l’acció PVR_Fix del mòdul extra PVRModule que descriurem més endavant. o Menús informatius de les resolucions de conflictes temporals: Aquests beans apareixen en pantalla desprès de resoldre un conflicte temporal a partir del menú de resolució de conflictes temporals en les gravacions. Aquests menús únicament informen del resultat de la resolució del conflicte, per tant, no executen cap acció en els mòduls de lògica extra. Presenten en pantalla un menú amb una única opció que al ser executada envia una acció al motor que fa que el menú desaparegui de la pantalla donant a l’usuari per informat. L’usuari pot interactuar amb aquests beans utilitzant la tecla “OK” del comandament a distància del set-top box. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 100 El primer d’aquests menús informa de que la modificació de l’hora d’inici i la seva durada s’ha realitzat correctament, amb el que representa en pantalla la següent imatge: Il·lustració 47: Bean informatiu de tipus “MenuLite” El segon d’aquests menús informa de que no ha estat possible la resolució del conflicte temporal de la nova gravació, amb el que la nova gravació ha estat cancel·lada. El grafisme que informa a l’usuari d’aquest fet es el següent: Il·lustració 48: Bean informatiu de tipus “MenuLite” Aquesta situació es dona quan la nova gravació queda completament solapada per una o varies gravacions programades anteriorment. • Bean tipus “VKBean”: El bean tipus VKBean es un bean lligat al mòdul extra VKModule que s’encarrega d’emular un teclat alfanumèric a partir del comandament a distància del set-top box. Aquest bean representa en pantalla una caixa de text on l’usuari pot introduir la duració desitjada de les gravacions realitzades a partir de la opció “REC” del menú de control del PVR. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 101 Il·lustració 49: Bean “VkBean” d’introducció de la durada dels enregistraments El bean es comunica tant amb el mòdul extra VKModule, el qual l’informa de quins caràcters han estat introduïts amb el teclat numèric del comandament a distància, així com amb el mòdul extra PVRModule, al qual informa mitjançant l’acció PVR_RECORD d’aquesta durada introduïda un cop pressionat el botó “OK” del comandament a distància. Un cop introduïda la durada desitjada per a la nova gravació, el bean es esborrat de la pantalla i es mostra, en cas de que sigui necessari, el menú de resolució de conflictes temporals en les gravacions. • Beans tipus “Icon”: En la present plana, els beans tipus Icon s’encarreguen de mostrar les següents imatges: o Imatge “Technical test”: Il·lustració 50: Contingut del bean tipus “Icon” o Imatges de velocitat de reproducció: Aquestes imatges informen a l’usuari de la velocitat de reproducció del vídeo que s’està reproduint. Apareixen en pantalla cada cop que l’usuari executa les opcions “RW” o “FF” del menú de control del PVR i es presenten en forma de “pop-up” cada cop que el mòdul extra PVRModule rep l’acció de “rebobinar” o “avançar” enviada pel menú de control. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 102 Il·lustració 51: Continguts dels beans tipus “Icon” Les imatges es representen de forma cíclica, controlada per cada una de les pulsacions dels botons “RW” o “FF”, i desapareixen de la pantalla quan la velocitat de reproducció passa a ser “1x”. Finalment, podem veure mitjançant diagrames de flux, com intervenen els elements descrits anteriorment en les accions disponibles a la present pagina de l’aplicació. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 103 • Acció “REC”: Il·lustració 52: Flux de l’acció “REC” Realizació de la gravació Conflicte? Opció “REC” Sí No Opció “Cancel·lar les gravacions conflictives” Opció “Modificar l’hora d’inici i la durada de la nova gravació” Sí No Realitzable? Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 104 • Acció “FF” i “RW”: Il·lustració 53: Flux de les accions “FF” i “RW” 5.1.3. La pantalla Guia electrònica de programació. La pantalla “Guia electrònica de programació” de la present aplicació permet als usuaris consultar la programació del canal o servei sintonitzat en aquells moments pel descodificador. A part d’aquesta funcionalitat, també permet als usuaris programar gravacions o obtenir informació addicional de qualsevol dels programes o events que apareixen a la graella de programació mostrada en pantalla. Opció “FF”/”RW” Opció “FF”/”RW” Opció “FF”/”RW” Opció “FF”/”RW” Opció “FF”/”RW” Opció “FF”/”RW” Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 111 Il·lustració 61: Bean informatiu de tipus “MenuLite” Il·lustració 62: Bean informatiu de tipus “MenuLite” • Bean tipus “Link”: Permet als usuaris navegar a la pantalla “Menú d’inici” de l’aplicació pressionant el botó vermell del comandament a distància del receptor i mostra en pantalla la següent imatge: Il·lustració 63: Contingut del bean tipus “Link” Per tant, aporta la següent navegació a l’aplicació: Il·lustració 64: Navegació generada pel bean Finalment, podem veure mitjançant diagrames de flux, com intervenen els elements descrits anteriorment en les accions disponibles a la present pagina de l’aplicació. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 112 • Acció “Descripció”: Il·lustració 65: Flux de l’acció “Descripció” Acció “Descripció” “OK” Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 113 • Acció “REC”: Il·lustració 66: Flux de l’acció “REC” Programació de la gravació Conflicte? Sí No Acció “REC” Opció “Cancel·lar les gravacions conflictives” Opció “Modificar l’hora d’inici i la durada de la nova gravació” Sí No Realitzable? Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 114 5.1.4. La pantalla Gestió de Gravacions. La pantalla “Gestió de gravacions”, com el seu nom indica, permet als usuaris gestionar les gravacions realitzades i les gravacions pendents de realitzar pel Personal Video Recorder. D’es d’ella els usuaris poden reproduir les gravacions realitzades, eliminar les gravacions, cancel·lar gravacions programades i comprovar tant l’estat de les gravacions realitzades com de les pendents. L’apartat gràfic de la pantalla està format per un bean tipus “Link”, dos beans tipus “Icon”, un bean tipus “MenuLite” i un bean tipus “PVRMenuBean” dissenyat específicament per a la present aplicació, mentre que l’apartat lògic ve donat pel mòdul extra “PVRModule”. Il·lustració 67: Pantalla “Gestió de gravacions” Com ja hem vist anteriorment, els beans tipus “Icon”, presenten una imatge en pantalla en la posició indicada, no són navegables i tampoc poden generar cap acció sobre el motor o els mòduls extra, els beans tipus “Link”,que son beans actius, presenten en pantalla una imatge en la posició indicada i poden enviar notificacions o accions al motor i als mòduls extra, i finament, els beans tipus “MenuLite”, que també son beans actius dins de la pantalla que representen en ella menús completament configurables. A part d’aquests beans, en aquesta pantalla ens trobem un bean tipus “PVRMenuBean”. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 115 El bean tipus “PVRMenuBean” representa en pantalla un llistat de les gravacions realitzades i programades al Personal Video Recorder, i permet als usuaris comprovar els seus estats, visionar els vídeos enregistrats i eliminar tant les gravacions programades com les realitzades. Les dades representades pel bean “PVRMenuBean” es mostren en format de menú vertical, de forma que els usuaris poden navegar per totes les gravacions programades o realitzades presents al menú utilitzant les tecles direccionals “amunt” i “avall” del comandament a distància del descodificador, d’aquesta manera es fa possible realitzar qualsevol de les accions disponibles sobre qualsevol de les gravacions, ja siguin programades o realitzades. El bean és altament configurable, podent-se configurar tant el seu apartat gràfic (la imatge de fons, la imatge de selecció, el nombre d’events per plana, etc.) així com les tecles del comandament a distància amb les que el bean realitzarà les seves accions. En la present plana, ens trobem aquests beans de la següent forma: • Beans tipus “Icon”: En la present plana, els beans tipus Icon s’encarreguen de mostrar les següents imatges: o Imatge “Technical test” Il·lustració 68: Contingut del bean tipus “Icon” o Imatge “Play” Aquest bean, presenta una imatge en pantalla que informa als usuaris de que poden reproduir qualsevol de les gravacions realitzades presents a la graella de gravacions pressionant la tecla “OK” del comandament a distància del set-top box. Il·lustració 69: Contingut del bean tipus “Icon” Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 116 o Imatge “Esborrar” Aquest bean, mostra en pantalla una imatge que informa als usuaris de que poden esborrar qualsevol de les gravacions programades o realitzades presents a la graella de gravacions pressionant el botó blau del comandament a distància del descodificador. Il·lustració 70: Contingut del bean tipus “Icon” • Bean tipus “PVRMenuBean”: Com ja hem dit anteriorment, el bean tipus PVRMenuBean és un bean desenvolupat especialment per a la realització del present Personal Video Recorder. El bean s’encarrega de presentar per pantalla el llistat de gravacions realitzades i programades obtingudes a partir del mòdul extra PVRModule de l’aplicació. La informació és mostrada a la part central del bean, i admet paginació. A la informació mostrada per cadascuna de les entrades ens hi trobem el nom del canal d’on s’ha realitzat la gravació i el nom del programa enregistrat, dades obtingudes de la taula Service Information del canal sintonitzat a la hora de programar la gravació, la durada de la gravació, el dia i l’hora en que es va realitzar o s’ha de realitzar la gravació i finalment l’estat de la gravació realitzada o programada. És important dir que tota aquesta informació mostrada es obtinguda del RecordingManager, l’element de la API PVR d’MHP que s’encarrega de gestionar les gravacions realitzades i pendents de realitzar pel descodificador. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 117 Il·lustració 71: Bean tipus “PVRMenuBean” Els possibles estats de les gravacions realitzades o programades son els següents:  “Completed”: Estat que indica que una gravació s’ha realitzat satisfactòriament.  “Failed”: Estat que indica que una gravació no s’ha realitzat satisfactòriament. Aquest estat es pot donar per exemple quan el descodificador no disposava de l’espai suficient per a emmagatzemar la gravació, el descodificador no estava sintonitzat al canal a enregistrar, el descodificador estava apagat a l’hora de realitzar l’enregistrament.  “Deleted”: Estat que indica que una gravació ha estat eliminada, o be, que la programació d’una gravació ha estat cancel·lada.  “Pending”: Estat que indica que la programació d’una gravació està pendent de ser realitzada i que en aquells moments no existeix cap problema que pugui causar que la gravació no sigui realitzada.  “Conflict”: Estat que indica que la gravació està pendent de ser realitzada però existeix algun problema que pot causar que la gravació no sigui realitzada, com per exemple que el descodificador no disposi d’espai suficient per a emmagatzemar-la.  “Recording”: Estat que indica que la gravació està sent realitzada en aquells moments. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 118 El bean permet als usuaris interactuar amb qualsevol dels elements mostrats a la taula de gestió mitjançant dues accions, l’acció “Play” i l’acció “Esborrar”, que passem a descriure a continuació:  Acció “Play”: L’acció “Play”, en la present aplicació, està configurada per a ser executada mitjançant el botó “OK” del comandament a distància del descodificador. Aquesta acció permet reproduir gravacions realitzades amb anterioritat pel descodificador. La present acció del PVRMenuBean crida l’acció PVR_PLAY del mòdul extra PVR_Module, el qual carrega la gravació seleccionada al reproductor de vídeo del descodificador, inicia la seva reproducció i l’aplicació passa a mostrar la pantalla “Control de vídeo”, on els usuaris poden controlar la reproducció de la gravació escollida. És important dir que aquesta acció només pot ser realitzada sobre gravacions el estat de les quals sigui “Completed”, es a dir, gravacions finalitzades i realitzades sense cap tipus d’error. Un cop finalitzada la reproducció, el Player de vídeo tornarà a reproduir l’últim canal sintonitzat pel descodificador.  Acció “Esborrar”: L’acció “Esborrar ”, en la present aplicació, està configurada per a ser executada mitjançant el botó blau del comandament a distància del descodificador. Aquesta acció permet esborrar gravacions finalitzades així com cancel·lar la programació de gravacions pendents de ser realitzades pel descodificador. Cal a dir que abans de realitzar l’esborrat o cancel·lació de l’opció seleccionada, l’aplicació mostra en pantalla un menú de confirmació d’esborrat per a evitar possibles errors. La present acció del PVRMenuBean crida l’acció PVR_Delete del mòdul extra PVR_Module, que presenta en pantalla el menú de confirmació comentat anteriorment. En el cas de confirmar Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 119 l’esborrat, aquest menú crida l’acció PVR_Delete_OK del mòdul extra, que realitzarà l’esborrat de l’element seleccionat i tancarà el menú de confirmació. En el cas de no confirmar l’esborrat, aquest menú crida l’acció CANCELAR del PVR_Module, que simplement provoca que el mòdul extra tanqui aquest menú de confirmació. • Bean tipus “MenuLite”: El bean tipus MenuLite de la present plana s’encarrega de mostrar en pantalla el menú de confirmació d’esborrat. Il·lustració 72: Bean tipus “MenuLite” utilitzat per a la confirmació d’esborrat Aquest menú apareix en mode de “pop-up” cada cop que el mòdul extra rep l’acció d’esborrar un element del PVRMenuBean descrita anteriorment. Com també hem vist a la descripció de l’acció “Esborrar”, la opció “Esborrar” d’aquest menú crida l’acció PVR_Delete_OK del mòdul extra PVR_Module , que realitzarà l’esborrat de la opció seleccionada i tancarà el menú, mentre que la opció “Cancel·lar” crida l’acció CANCELAR que provoca que el mòdul extra tanqui aquest menú sense realitzar l’esborrat de l’acció seleccionada. • Bean tipus “Link”: Permet als usuaris navegar a la pantalla “Menú d’inici” de l’aplicació pressionant el botó vermell del comandament a distància del receptor i mostra en pantalla la següent imatge: Il·lustració 73: Contingut del bean tipus “Link” Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 120 Per tant, aporta la següent navegació a l’aplicació: Il·lustració 74: Navegació generada pel bean Finalment, podem veure mitjançant diagrames de flux, com intervenen els elements descrits anteriorment en les accions disponibles a la present pagina de l’aplicació. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 127 seleccionat. mètode actionPerformed(Acció) de la superclasse BasicComponent. Tecla “OK” Reproducció de l’element del llista t de gravacions seleccionat, sempre que el seu estat sigui “Completed”. Els crida la acció “PVR_PLAY” del mòdul PVR_Module mitjançant el mètode actionPerformed(Acció) de la superclasse BasicComponent. Taula 5: La interacció al “PVRMenuBean” 5.3. Els mòduls de lògica. Els mòduls extra de la plataforma DigitalFingertext hereten d’una classe anomenada GenericInterfaceCommunication. Aquesta classe defineix tres mètodes abstractes que el motor de DigitalFingertext utilitzarà per a poder comunicar-se amb el mòdul de lògica extra. Aquest mètodes són: • getActions(): Aquest mètode retorna un array d’Strings amb els noms de les diferents accions que pot portar a terme el mòdul. • doAction(Emissor, Acció, Paràmetres): És el principal mètode de la classe. Aquest mètode permet al motor indicar al mòdul que ha d’executar una acció. Un cop cridat, el mòdul filtra la acció demanada i executa els processos necessaris per a poder portar a terme dita acció. • cleanResources(): Aquest mètode és cridat pel motor quan es vol deixar d’utilitzar el mòdul, amb el que allibera tots els recursos utilitzats per ell. A part d’aquests mètodes, la classe GenericInterfaceCommunication implementa d’antres mètodes importants, com per exemple el mètode executeMotorAction(emissor,acció,paràmetres), que permet al mòdul extra executar les accions genèriques amb les que compta el motor. A continuació passem a descriure els aspectes més importants dels mòduls extra desenvolupats per a la present aplicació. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 128 5.3.1. El mòdul VKModule. El mòdul VKModule implementa els mecanismes necessaris per simular el comportament d’un teclat alfanumèric utilitzant el comandament a distància del receptor. Està pensat per ser usat conjuntament amb el bean VKBean que presenta en pantalla la sortida d’aquest teclat virtual. Aquest mòdul, es capaç de recollir els events produïts per la pulsació dels botons del comandament i convertir-los al caràcter adient. El mòdul pot operar en dos modes basics intercanviables en qualsevol moment, el mode “numèric” i el mode “alfanumèric”. En el mode numèric, el teclat nomes treballa amb els dígits del 0 al 9 que corresponen a cada botó del comandament, mentre que el model alfanumèric permet treballar, a més, amb els caràcters alfabètics. Bàsicament, el que fa el mòdul, és recollir les pulsacions del comandament a distància del receptor, transformar aquestes pulsacions en caràcters i notificar al bean vinculat al mòdul del caràcter a mostrar. La correspondència entre pulsacions i caràcters es la següent: Tecla polsada Caràcter en mode “Numèric” Seqüencia de caràcters en mode “Alfanumèric” 1 “1” “1” 2 “2” “2”, “a”, “b”, “c” 3 “3” “3”, “d”, “e”, “f”. 4 “4” “4”, “g”, “h”, “i”. 5 “5” “5”, “j”, “k”, “l”. 6 “6” “6”, “m”, “n”, “o”. 7 “7” “7”, “p”, “q”, “r”, “s”. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 129 8 “8” “8”, “t”, “u”, “v”. 9 “9” “9”, “x”, “y”, “z”. 0 “0” “0” Taula 6: Correspondència pulsacions-caràcters Per a poder processar les seqüencies de caràcters alfanumèrics, el mòdul implementa el mètode timerWentOff() de la classe TVTimerWentOffListener. Aquest mètode captura la finalització d’un temporitzador que s’inicia a cada pulsació, que indica la finalització d’una seqüencia de pulsacions. Altres tecles processades pel mòdul son les següents: Tecla direccional Acció realitzada “Esquerra” Esborra l’últim caràcter introduït. “Dreta” Afegeix un espai en blanc. “Amunt” Canvia els caràcters a majúscules. “Avall” Canvia els caràcters a minúscules. Taula 7: Altres accions Per a poder realitzar aquesta tasca, el mòdul disposa de les següents accions que permeten controlar-lo des del bean VKBean: • VK_SET_ACTIVE: Permet activar o desactivar el teclat virtual. Per a realitzar aquesta tasca, el mòdul utilitza els mètodes addUserEventListener(UserEventListener, UserEventRepository) o removeUserEventListener(UserEventListener) de la classe EventManager depenent de si es volen seguir capturant o no els events provinents del comandament a distancia del receptor. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 130 • VK_SET_MODE: Permet establir el mode d’escriptura (“Numeric” o “Alfanumeric”). • VK_KEY_PRESSED: Notifica al mòdul la pulsació d’una tecla al comandament a distància per a que aquest la processi. • VK_END_INPUT: Notifica al mòdul la finalització de la introducció de caràcters. Cal a dir que en la present aplicació, aquest mòdul sempre esta configurat en mode numèric, donat que únicament és utilitzat per a notificar al PVR_Module les durades de les gravacions realitzades des de la pantalla “Control de vídeo”. 5.3.2. El mòdul PVRModule. El PVRModule és el mòdul que aporta a l’aplicació totes les funcionalitats típiques d’un Personal Video Recorder. Permet, entre d’altres, controlar el reproductor de vídeo, gestionar les gravacions del dispositiu i obtenir la programació dels canals. Per a poder realitzar aquestes tasques, el mòdul implementa les següents classes: • ControllerListener: Permet capturar les notificacions generades pel reproductor, com per exemple les generades al arribar al final o a l’inici d’un vídeo o les generades al passar de reproduir un contingut enregistrat a un contingut obtingut per antena. • RecordingChangedListener: Permet detectar els canvis d’estat de les gravacions programades al descodificador. Per tant, ens permet veure a temps real l’estat de les gravacions a la pantalla “Les Meves Gravacions” de l’aplicació. • SIRetrievalListener: Permet obtenir la taula “Service Information” del canal sintonitzat pel descodificador. Per tant, ens permet adquirir les escaletes de programació per a mostrarles a la pantalla “Guia Electrònica de Programació” de l’aplicació. • SIRequestor: Permet obtenir informació dels events presents a la taula “Service Information”, com per exemple la seva descripció. • SIMonitoringListener: Permet detectar els canvis en el contingut de la taula “Service Information” del canal sintonitzat pel Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 131 descodificador. Per tant, ens permet veure a temps real la programació dels canals. A part de les classes que implementades pel mòdul, també és important enumerar les següents classes utilitzades: • Player: Classe del paquet “javax.media” que proporciona mecanismes de control del reproductor del descodificador. • Service: Classe del paquet “javax.tv.service” que proporciona mecanismes per accedir als continguts de la taula “Service Information” d’un servei broadcast. • RecordingManager: Classe del paquet “org.ocap.shared.dvr” que representa la entitat que realitza i gestiona la base de dades de gravacions del descodificador. • ServiceRecordingSpec: Classe del paquet “org.ocap.shared.dvr” que especifica les característiques d’una nova gravació. • RecordingList: Classe del paquet “org.ocap.shared.dvr.navigation” que representa el llistat de gravacions presents a la base de dades del descodificador. • LeafRecordingRequest: Classe del paquet “org.ocap.shared.dvr” que representa la informació corresponent a la programació d’un d’enregistrament. • DvbLocator: Classe del paquet “org.davic.net.dvb” que permet encapsular una URL de tipus DVB d’un servei o canal en aquest objecte. • SIService: Classe del paquet “org.dvb.si” que representa un servei d’un Transport Stream. La classe aporta mètodes que permeten obtenir tot tipus d’informació d’aquest servei. • SIDatabase: Classe del paquet “org.dvb.si” que representa l’arrel de la jerarquia de la informació continguda a la taula Service Information. • SIEvent: Classe del paquet “org.dvb.si” que representa un event particular dins d’un servei. La classe aporta un conjunt de mètodes que permeten obtenir tot tipus d’informació d’aquest event. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 132 El mòdul disposa de les següents accions que permeten que aquest sigui controlat des dels diferents beans de l’aplicació: • PVR_Pause: Permet pausar la reproducció dels continguts audiovisuals que estigui reproduint el descodificador en aquells moments, ja siguin continguts prèviament enregistrats o aquests continguts estiguin sent rebuts per antena. Per a realitzar aquesta tasca el mòdul pren el control del Player i utilitza el seu mètode setRate(float) passant-li com a paràmetre el valor “0”, aturant, d’aquesta forma, la seva reproducció. En el cas de que el reproductor estigui reproduint continguts provinents del canal de broadcast, aquests s’emmagatzemen en el buffer de timeshift per al seu posterior visionat. Cal a dir, que un cop realitzada la tasca, el mòdul elimina de la pantalla qualsevol bean informatiu de la velocitat de reproducció existent mitjançant el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.CLOSE_POPUP i l’identificador del bean en qüestió. • PVR_Reverse: Permet rebobinar els continguts audiovisuals que estigui reproduint en aquells moments el descodificador. Aquests continguts han d’haver estat prèviament enregistrats, o be, han d’estar prèviament emmagatzemats en el seu buffer de timeshift provinents del canal de broadcast. Per a realitzar aquesta tasca el mòdul pren el control del Player i utilitza el seu mètode setRate(float) passant-li com a paràmetre un valor inferior a “0”, fet que fa que el Player reprodueixi els continguts de forma inversa. Cal a dir, que un cop realitzada la tasca, el mòdul utilitza el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.OPEN_POPUP o BasicCInterface.CLOSE_POPUP i l’identificador del bean que correspongui, per a mostrar o eliminar de la pantalla els beans informatius de velocitat de reproducció. • PVR_Forward: Permet avançar els continguts audiovisuals que estigui reproduint en aquells moments el descodificador. Aquests Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 133 continguts han d’haver estat prèviament enregistrats, o be, han d’estar prèviament emmagatzemats en el seu buffer de timeshift provinents del canal de broadcast. Per a realitzar aquesta tasca el mòdul pren el control del Player i utilitza el seu mètode setRate(float) passant-li com a paràmetre un valor superior a “1”, fet que fa que el Player reprodueixi els continguts de forma accelerada. Cal a dir, que un cop realitzada la tasca, el mòdul utilitza el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.OPEN_POPUP o BasicCInterface.CLOSE_POPUP i l’identificador del bean que correspongui, per a mostrar o eliminar de la pantalla els beans informatius de velocitat de reproducció. • PVR_Resume: Força la reproducció a una velocitat 1x dels continguts audiovisuals que estava reproduint el Player del descodificador després de que aquests hagin estat pausats, o aquests estiguin sent reproduïts de forma accelerada. Per a realitzar aquesta tasca el mòdul pren el control del Player i utilitza el seu mètode setRate(float) passant-li com a paràmetre el valor “1”, fet que fa que el Player continuï reproduint els continguts a una velocitat de 1x. Cal a dir, que un cop realitzada la tasca, el mòdul elimina de la pantalla qualsevol bean informatiu de la velocitat de reproducció existent mitjançant el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.CLOSE_POPUP i l’identificador del bean en qüestió. • PVR_Play: Permet reproduir un contingut audiovisual prèviament enregistrat. Per a realitzar aquesta tasca, el mòdul utilitza el mètode select(Service) de la classe ServiceContext, al qual se li passa com a paràmetre el RecordedService desitjat emmagatzemat a l’objecte RecordingList del PVR. Cal a dir que només podran ser reproduïts aquells serveis el estat dels quals sigui “Completed”, es a dir, que la seva gravació hagi estat finalitzada de forma satisfactòria. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 134 Amés a mes, l’acció força que la velocitat de reproducció sigui 1x, mitjançant el mètode setRate(float) de l’objecte Player, passant-li com a paràmetre el valor “1”, i elimina de la pantalla qualsevol bean informatiu de la velocitat de reproducció existent. • PVR_Return: Permet retornar al servei broadcast que estava reproduint el Player abans d’iniciar la reproducció d’un servei enregistrat. Per a realitzar aquesta tasca, el mòdul utilitza el mètode select(Service) de la classe ServiceContext, al qual se li passa com a paràmetre el servei que estava reproduint el Player abans d’iniciar-se la reproducció dels continguts audiovisuals enregistrats. Cal a dir que l’acció força que la velocitat de reproducció sigui 1x, mitjançant el mètode setRate(float) de l’objecte Player, passant-li com a paràmetre el valor “1”, i elimina de la pantalla qualsevol bean informatiu de la velocitat de reproducció existent. • PVR_Rec: Presenta en pantalla el bean VKBean, que permet la introducció de la durada desitjada d’una gravació. Per a realitzar aquesta tasca, el mòdul fa ús del mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.OPEN_POPUP i l’identificador del bean VKBean. Cal a dir que l’acció força que la velocitat de reproducció sigui 1x, mitjançant el mètode setRate(float) de l’objecte Player, passant-li com a paràmetre el valor “1”, i elimina de la pantalla qualsevol bean informatiu de la velocitat de reproducció existent. • PVR_Record: Elimina de la pantalla el bean VKBean i realitza una gravació a partir de la durada introduïda. Per a tancar el bean VKBean, el mòdul utilitza el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.CLOSE_POPUP i l’identificador del bean VKBean. Per a la realització de la gravació, el mòdul utilitza el mètode record(ServiceRecordingSpec) de l’objecte “RecordingManager”, passant-li com a paràmetre les especificacions de la nova Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 135 gravació. Aquestes especificacions son el servei broadcast a enregistrar, l’hora d’inici, la durada i el període de vigència de la nova gravació. El procés es capaç de detectar si la nova gravació entra en conflicte amb qualsevol altre gravació ja programada i en cas afirmatiu, demana a l’usuari que prengui una decisió per a solucionar aquest conflicte. Per a tal tasca, el mòdul obté el seu LeafRecordingRequest del RecordingManager i comprova el seu estat. Si aquest és LeafRecordingRequest.PENDING_WITH_CONFLICT_STATE, es a dir, la nova gravació pendent colisiona amb d’altres gravacions ja programades, el mòdul mostra en pantalla el bean de resolució de conflictes utilitzant el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.OPEN_POPUP i l’identificador d’aquest bean de resolució de conflictes. • PVR_Stop: Permet aturar una gravació realitzada mitjançant l’acció PVR_Record. Per a la realització d’aquesta tasca, el mòdul utilitza el mètode stopRecording() de l’objecte RecordingManager del PVR. • PVR_Fix: Permet cancel·lar les gravacions programades que entren en conflicte amb la programació d’una nova gravació per a que aquesta pugui ser realitzada correctament. Per a la realització d’aquesta acció, el mòdul obté el RecordingList (llistat de gravacions) de l’objecte RecordingManager i compara les especificacions (LeafRecordingRequest) de les gravacions amb status PENDING_WITH_CONFLICT_STATE amb l’especificació, ServiceRecordingSpec, de la nova gravació, cancel·lant-ne aquelles que hi entren en conflicte. Per a realitzar aquestes cancel·lacions, es fa ús del mètode delete() de l’objecte LeafRecordingRequest que representa aquestes gravacions programades. • PVR_Modif: Permet ajustar les especificacions d’una nova gravació per que aquesta no entri en conflicte amb cap altre gravació programada. Per a realitzar aquesta tasca, el mòdul calcula una nova hora d’inici i una nova durada per a la nova gravació a partir de les Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 136 especificacions de les gravacions programades anteriorment que hi entraven en conflicte. Aquestes noves especificacions, es calculen a partir de de les LeafRecordingRequest de les gravacions conflictives ja programades, obtingudes del RecordingManager. Un cop obtingudes aquestes especificacions, es genera un nou ServiceRecordingSpec i es torna a programar la gravació mitjançant el mètode record(ServiceRecordingSpec) de l’objecte RecordingManager. Un cop programada la nova gravació, el procés mostra per pantalla el bean informatiu de resolució de conflictes mitjançant el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.OPEN_POPUP i l’identificador d’aquest bean d’informació de resolució de conflictes. • PVR_Cancel: Permet cancel·lar una nova gravació que entra en conflicte amb gravacions programades anteriorment. Per a realitzar aquesta tasca, el mòdul obté l’objecte LeafRecordigRequest, que descriu la programació de la nova gravació, de l’objecte RecordingManager i executa el seu mètode delete(), el qual la eliminarà del llistat de gravacions del RecordingManager. • PVR_Delete: Mostra per pantalla el menú de confirmació d’esborrat d’una gravació. Per a mostrar aquest menú, el mòdul utilitza el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció BasicCInterface.OPEN_POPUP i l’identificador d’aquest bean de confirmació d’esborrat. • PVR_Delete_OK: Esborra una gravació i elimina de la pantalla el bean de confirmació d’esborrat. Per a la realització de l’esborrat, el mòdul obté la LeafRecordingRequest de la gravació seleccionada a partir de l’objecte RecordingManager i executa el seu mètode delete(), el qual la eliminarà del llistat de gravacions del RecordingManager. Un cop esborrada la gravació, el mòdul crida el mètode executeMotorAction(BasicComponent, Action, String) de la superclasse GenericInterfaceCommunication, passant-li com a paràmetres l’objecte del propi mòdul, la acció Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 143 7. Referències. 7.1. Bibliografia. [1] Sun Microsystems, Inc: JavaBeans API Specification. 1997. [2] The MHP Knowledge Project: The MHP-Guide. 2006. [3] Digital Video Broadcasting (DVB): Multimedia Home Platform (MHP) Specification 1.1.2. 2005. [4] Digital Video Broadcasting (DVB): Introduction to the MHP PVR/PDR/DVR Specification. 2005. [5] Digital Video Broadcasting (DVB): PVR/PDR Extension to the Multimedia Home Platform, Rev. 1. 2007. [6] Digital Video Broadcasting (DVB): Digital Recording Extension to Globally Executable MHP (GEM), Rev. 1. 2007. [7] Digital Video Broadcasting (DVB): Specification for Service Information (SI) in DVB-systems. 2004. [8] The MHP Knowledge Project: Documention on SI Access. 2005. [9] EBU Technical Review: Personal Digital Recorders. 2000. [10] OpenCable™: OpenCable™ Application Platform Specification: OCAP Digital Video Recorder (DVR). 2005. [11] Foro Técnico de la Televisión Digital: Guía de Implementación de la TDT en España. 2005. [12] Foro Técnico de la Televisión Digital: Documento sobre Situación de MHP en España. 2005. [13] TVC Multimèdia: Estat actual de l’estàndard MHP. 2005 [14] BBC Reseach&Development: TV Gets Personal. 2001. [15] Vivar, Hipolito; García Alberto: La interactividad: concepto y factor de impulso de la TDT. 2009. [16] León, Bienvenido; García, José Alberto: Los retos de la implantación de la televisión interactiva a la luz de su própia historia. 2007. [17] Dirección RTVE Digital: Estudio de campo de las aplicaciones interactivas de RTVE. 2006. [18] Fundación Auna: Descripción de tecnologias para middleware, software y passarel·les residenciales. 2006. [19] Grenier, Gerhard; de Buigne, Werner: Impact of Key Technology Trends on DVB MHP. 2004. [20] Cañigueral, Albert: Retos tecnólogicos de los decodificadores comerciales. 2008. Televisió Digital Terrestre: Desenvolupament d’un “Personal Video Recorder ” basat en l’estàndard DVBMHP. 10 de mayo de 2012 144 7.2. Enllaços d’interès. [1] DVB Project: www.dvb.org [2] Web oficial de DVB-MHP i DVB-GEM: www.mhp.org [3] Impulsa TDT: www.impulsatdt.es [4] TV Without Borders: www.interactivetvweb.com [5] Interactive TV Knowledgebase: www.mhpkdb.org [6] Ministerio de Industria, tecnología y turismo. Televisión digital: www.televisiondigital.es [7] Digital Television Action Group: www.digitag.org [8] ADB: www.adbglobal.com [9] Osmosys: www.osmosys.tv [10] Activa Multimèdia Digital: www.activamultimedia.com