3.3.- Sistemes MPEG-2

 - Fins ara hem estat comentant la necessitat de la compressió de vídeo i d’àudio per tal que la televisió digital sigui viable. Ara bé, en cap moment hem parlat de com s’ha d’enviar aquesta informació per tal que els descodificadors MPEG-2 siguin capaços de recuperar el vídeo i l’àudio d’un o diversos programes. Els sistemes MPEG-2 (MPEG-2 systems) defineixen com s’ha de multiplexar el vídeo i l’àudio comprimit, a més de possibles dades per tal de formar un únic flux de dades que permeti ser transmès o emmagatzemat. Si vols ampliar la informació que apareix a continuació pots anar al següent tutorial ralitzat per l'Edgar Romero, col·laborador del Laboratori i del Centre de Televisió Digital.

 - Hi ha dos tipus de multiplexat especificats pels sistemes MPEG-2. El program stream és la multiplexació d’un sol programa  i és l’utilitzat, per exemple, pel DVD. Per una altra banda, el transport stream defineix com es multiplexen diversos programes i és el que utilitza DVB, entre d’altres. Aquests dos multiplexats faciliten la inclusió de la PSI (Program Specific Information), que dóna informació de les dades que es multiplexen. Els sistemes MPEG-2 utilitzen unes referències temporals per tal que les dades es representin en el moment adequat ja que, per exemple, el so i les imatges no viatgen en paral·lel, però l’usuari final les ha de percebre en el mateix moment. A més a més, els sistemes MPEG-2 donen flexibilitat per tal d’incloure noves sintaxis, afegir informació de control d’accés condicional, dades, ... A la figura 3.37 hi tenim un exemple gràfic.


Figura 3.37. Multiplexació MPEG-2

 - La normativa MPEG-2 no especifica com s’ha de realitzar aquesta multiplexació ni com protegir-la. Com a títol orientatiu, només esmentar que els dos tipus de multiplexació que s’estan manegant actualment són o bé TDM (Multiplexació per Divisió de Temps), o bé estadística. La TDM és aquella que sempre assigna un espai de temps concret i constant a cada component del program stream.

 - La multiplexació estadística, a diferència de la TDM, representa un canvi de mentalitat respecte al conegut fins ara. Ara ja no s’assigna un espai de temps determinat i concret, sinó que els diferents program streams es van passant informació de quant ample de banda requereixen per a la transmissió. Així doncs, un programa que en necessiti molt podrà beneficiar-se d’un que n’ocupi poc i que, d’altra manera, es desaprofitaria utilitzant bits de farciment (stuffing bits).
 

3.3.1.- Elementary Streams

 - Els Elementary Streams (ES) són les dades tal i com surten del codificador MPEG-2. Les dades que entren al codificador, com per exemple les imatges, s’anomenen unitats de presentació i les dades comprimides són les unitats d’accés. A la figura 3.38 es pot veure la diferència entre unitats d’accés i unitats de representació sobre la compressió d’una seqüència de vídeo.


Figura 3.38. Unitat de presentació i unitat d’accés

 - El resultat de la codificació d’una seqüència de vídeo és una successió d’unitats d’accés. Això és el que forma el Video Elementary Stream. A la figura 3.39 podem apreciar aquesta trama.

Figura 3.39. Video Elementary Stream

 - Per entendre els camps anteriors només cal referir-se al punt 3.2.1.4. De manera similar, l’àudio està format per una successió d’unitats d’accés que formen l’Audio Elementary Stream (figura 3.40). Cada unitat d’accés conté unes desenes de milisegons d’àudio comprimit.

Figura 3.40. Audio Elementary Stream (pel Layer II de l’MPEG-1)

 - Per entendre els diferents camps cal referir-se al punt 3.2.2.
 

3.3.2.- Packetised Elementary Streams

 - El següent punt en el procés de multiplexació és convertir cada Elementary Stream en un Packetised Elementary Stream (PES). Un paquet PES consisteix en capçalera i payload. El payload consisteix en les dades agafades seqüencialment de l’stream elemental. No hi ha necessitat d’alinear les unitats d’accés i el començament dels PES payloads. És més, una nova unitat d’accés pot començar en qualsevol punt del payload. A continuació tenim un exemple de com s’insereix la informació de l’Elementary Stream dintre dels paquets PES.


Figura 3.41. Pas de ES a PES

 - Els paquets PES poden ser de longitud variable fins a un màxim de 64 Kbytes. L’estructura d’un paquet PES és el que hi ha a la figura 3.42.


Figura 3.42. Paquet PES simplificat

 - Els primers 4 bytes de la capçalera formen el codi d’inici del paquet PES. Evidentment, durant tot el paquet PES només hi pot haver aquesta seqüència de bits, ja que si no es podria interpretar com l’inici d’un nou paquet.

 - El camp stream_id permet distingir paquets PES d’un mateix programa. L’MPEG especifica els valors permesos per aquest camp, incloent 32 per a streams elementals d’àudio i 16 per a streams elementals de vídeo.

 - Els flags 1 i 2 són bits que indiquen la presència o absència de camps opcionals en la capçalera. Aquests paquets opcionals donen idea de, per exemple, si la informació continguda està encriptada, té alguna prioritat, porta informació de copyright i un camp opcional de control d’errors pel paquet PES.

 - Dels esmentats flags, n’hi ha dos que són de gran importància. Són els que estan marcats com a P i D a la figura 3.42. Quan aquests bits estan actius indiquen la presència del Presentation Time Stamp (PTS) i el Decoding Time Stamp (DTS). Aquests seran els elements que permetran la correcta sincronització dels diferents ES en recepció. S’explicarà amb més detall més endavant.

 - A continuació hi ha el paquet de longitud de capçalera, que indica quants bytes opcionals hi ha a la capçalera abans que comenci el primer byte de payload. A la figura 3.43 es poden apreciar tots els camps opcionals i obligatoris d’un paquet PES.


Figura 3.43. Paquet PES complert

 - A la figura 3.44 es mostra un exemple de la informació que pot transportar la capçalera d’un PES i d’un ES d’àudio (per al cas de l’MPEG-1, capa 3).


Figura 3.44. Informació de la capçalera PES i ES d’àudio






3.3.3.- El Program Stream

 - Aquest tipus de multiplexació està basada en la que es va establir per a la multiplexació del senyal MPEG-1. Només permet la inclusió d’un sol programa en un determinat flux de bits i està dirigida a entorns sense propensió a errors, com pot ser, per exemple, el DVD (Digital Versatile Disc).

 - El Program Stream s’encarrega de multiplexar tot el vídeo, àudio i dades auxiliars. El PS és una successió de paquets de longitud variable (bastant llargs) on cada paquet comença amb una capçalera. Un error en aquesta capçalera provoca que tot el paquet es perdi. Ja que cada paquet de dades en pot contenir fins a 64Kbytes, es pot produir un error important en la representació de la informació. D’altra banda, la longitud variable dels paquets provoca que el descodificador estigui escanejant contínuament el PS per tal de veure on comença un nou paquet de dades (o on acaba l’anterior). A més, ha de llegir la informació de la capçalera que li indicarà quina és la longitud d’aquesta.

 - En un Program Stream, els paquets PES que es deriven dels streams elementals s’organitzen en “packs”, tal i com s’aprecia a la figura 3.45. Un pack està format per una capçalera, una capçalera de sistema opcional i qualsevol número de paquets PES de qualssevol dels streams elementals. La longitud dels packs pot ser qualsevol sempre que hi hagi una capçalera de pack cada 0.7 segons, ja que la capçalera d’un pack conté informació de temporització (és  la referència de rellotge del sistema (System Clock Reference)). La capçalera del sistema conté informació de les característiques del PS, com, per exemple, el màxim flux de dades, el número d’streams elementals de vídeo i àudio que el formen, més informació de temporització, ... Un descodificador pot agafar la informació de sistema de la capçalera per saber si és capaç de descodificar el senyal o no.


Figura 3.45. Estructura de la multiplexació del PS

 - Gràficament, tot el procés per arribar fins al PS queda resumit a la següent imatge:


Figura 3.46. Multiplexat del Program Stream

 - A continuació es pot apreciar un esquema d’un descodificador de Program Stream:


Figura 3.46. Descodificador de program stream






3.3.4.- El Transport stream

 - El Transport Stream (TS) soluciona els problemes crítics pel que fa a la pèrdua d’un paquet, ja que es limita la longitud d’aquests a 188 bytes, per la qual cosa està orientat a la radiodifusió de vídeo malgrat que cal afegir encara mètodes de protecció contra errors. D’altra banda, el Transport Stream multiplexa diversos programes dintre d’un mateix flux binari de dades.

 - La multiplexació del transport stream consisteix, com s’ha dit, en petits paquets de longitud constant. Un paquet de transport és sempre de 188 bytes, dels quals 4 són de capçalera més un camp d’adaptació opcional i 184 són d’informació (payload), tal i com es pot apreciar a la figura 3.48. Els paquets PES són dividits entre els payloads dels paquets de transports.

 - El procés de divisió de paquets ha de seguir dues premisses. Una és que el primer byte de cada paquet PES ha de ser el primer del payload del paquet de transport. La segona premissa és que cada paquet de transport només pot portar informació d’un PES.

 - És bastant probable que no hi hagi un número enter de paquets de transport per portar tot el PES, amb la qual cosa ens queden paquets sense acabar d’omplir. Per tal que es compleixin les premisses anteriors, existeix un camp d’adaptació que permet acabar d’omplir el paquet. Són els anomenats bits de farciment. Aquest ús es pot minimitzar utilitzant longituds de paquets PES grans, ja que així assegurem una gran part dels paquets de transport completament plens.


Figura 3.47. Generació dels paquets TS a partir dels paquets PES

 - Els paquets que resulten d’aquest procés formen el Transport Stream. No s’especifica l’ordre en què els paquets de transport arriben al multiplexor. L’únic que sí que s’especifica és que els paquets d’un mateix PES han d’enviar-se seqüencialment.

 - La següent imatge mostra de quins camps es composa un paquet del transport stream:


Figura 3.48. Camps d’un paquet TS

 - El significat dels camps més importants és el següent:
 


- A continuació es detallen alguns dels camps existents dintre d’un camp d’adaptació:
 


- Per finalitzar aquest apartat, es pot apreciar a la següent imatge un exemple d’un TS de Canal Satélite Digital i els Bit Rates dels diferents ES que el composen. Com es pot veure, en un mateix TS caben 8 canals de televisió i 13 de ràdio, més informació relativa a la interactivitat, teletext, ...


Figura 3.49. Exemple de TS



3.3.4.1.- Paquets del TS sobre cel·les ATM

- El fet que els paquets siguin de 188 bytes no és arbitrari. En efecte, si observem la imatge de la figura 3.50, podem veure el procés d’empaquetament d’una trama de 188 bytes de sistemes MPEG-2 dins de diferents cel·les ATM del nivell d’adaptació 5 (AAL-5). Si fem els càlculs podem apreciar-ho millor. Suposem 8 cel·les ATM composades de 48 bytes d’informació útil cadascuna. Això són 384 bytes. Si agafem dos paquets del TS obtenim 188x2=376 bytes. Aquests 376 juntament amb les capçaleres de l’AAL-5 (8 bytes) donen un total de 384 bytes. Això és un bon resultat, ja que no utilitzem bits de farciment en les cel·les ATM.


Figura 3.50. TS dins d’AAL-5

 - L’AAL-5 ha estat escollit com a estàndard per a la transmissió de VOD (Vídeo Sota Demanda) als EUA. Ara bé, AAL-5 no té protecció contra errors, per la qual cosa una congestió en la xarxa podria provocar la pèrdua de cel·les senceres. A l’hora de transmetre, a Europa es prefereix utilitzar l’AAL-1 ja que té protecció contra errors a més d’un bit rate constant.

 - Una cel·la AAL-1 ja no té 48 bytes d’informació sinó que se n’utilitza 1 per a correcció d’errors. Segons la figura 3.51, agafem 47 paquets de 188 bytes més 16 bytes de correcció Reed Solomon. Ara aquests bytes es trossegen verticalment mitjançant 128 cel·les ATM. A continuació, aquestes dades anirien sobre PDH (Jerarquia Digital Plesíncrona) o SDH (Jerarquia Digital Síncrona). L’SDH és el que té més fàcil implementació.

 - Aquest sistema ha estat dissenyat per tal de tenir un BER de 10-4. Això és el màxim que es pot esperar d’un cable coaxial i es considera que és suficient per a SDH/PDH. Contràriament al que molta gent es pensa, en televisió per cable, la fibra òptica normalment no arriba a la casa de l’abonat, sinó que es tracta d’un coaxial que prové des d’un node que pot estar més o menys proper a la seva llar.

 - La idea d’aquest posicionament de les trames MPEG-2 respecte a les cel·les ATM és que es puguin recuperar 2 cel·les ATM completes que tinguin error. A més a més, d’aquesta manera, també podem protegir d’errors a ràfegues.


Figura 3.51. TS dins d’AAL-1

3.3.5.- Program Specific Information (PSI)

 - En un TS cada paquet de transport té el seu propi PID, que indica a quin ES pertany el payload que conté. Hi ha molts ES que pertanyen a diferents programes cadascun. Com pot, doncs, un descodificador saber quins PID corresponen a un determinat programa? La resposta recau en incloure informació addicional sobre el TS per explicitar la interrelació dels diferents PID que el formen. Aquesta informació és la PSI i cada TS l’ha de tenir.

 - La PSI especificada per MPEG-2 conté 4 tipus de taules (més endavant veurem que DVB n’afegeix unes quantes més). Aquestes són la Program Map Table (PMT) (Taula de Mapejat de Programes), la Program Association Table (PAT) (Taula d’Associació de Programes), la Network Information Table (NIT) (Taula d’Informació de Xarxa) i la Conditional Acces Table (CAT) (Taula d’Accés Condicional). Aquestes taules viatjaran en un o més paquets del TS. A continuació s’explicarà cadascuna:



Figura 3.52. Exemple de PAT i PMT


 - Així doncs, acabem de veure quines són les 4 taules que defineixen els sistemes MPEG-2 per al transport stream. A la figura 3.53 es pot apreciar l’estructura de la PSI resumida.

 - A part de la definició de la PSI per al TS, cal esmentar que també se’n defineix per poder-se utilitzar sobre un multiplexat de PS. Com que un PS només porta informació d’un programa, tots els ES pertanyen al mateix programa. Una taula que es diu Program Stream Map (PSM) dóna informació del tipus de dades que conté cada ES.


Figura 3.51. Exemple d’estructura de la PSI



3.3.6.- DVB-SI

- El consorci DVB, tal i com s’especificarà més endavant, es basa en la banda base MPEG-2, però, a part de les quatre taules especificades per l’MPEG-2, DVB n’especifica unes quantes més. Això es fa amb la finalitat de facilitar l’ús del descodificador a l’usuari final, ja que aquestes noves taules contenen dades que faciliten la localització automàtica de programes i fan més amigable la relació home-màquina.

- La normativa és la DVB-SI i està definida en el document de l’ETSI (Institut d’Estàndards Europeus de Telecomunicacions) EN 300 468. Existeix també un escrit tècnic de l’ETSI que dóna més informació. És l’ETR 211.

- A continuació s’explicaran cadascuna de les taules que defineix DVB-SI. S’ha cregut adient fer una altra menció a la NIT ja que la normativa fa una especial esmena a aquesta taula.
 

3.3.6.1.- Network Information Table (NIT)

- Realment aquesta és la definició de la NIT, ja que MPEG-2 no la definia gaire extensament. La NIT dóna informació de la xarxa sobre la qual va el senyal. La informació de la taula pot fer-se servir durant els moments de set-up de l’IRD (Integrated Receiver-Decoder), d’on s’extrau informació de sintonització del senyal que pot emmagatzemar-se en una memòria no volàtil. A més, la NIT pot fer-se servir per senyalitzar canvis de sintonització.

- La transmissió de la NIT és obligatòria i s’ha d’enviar, com a mínim, 8 cops cada 10 segons. El SI utilitza dues etiquetes: identificació de xarxa i identificació de la xarxa original. Aquesta última té com a finalitat identificar l’origen d’un servei contingut en un TS quan ha estat transferit a una altra via de difusió. Això és important ja que l’única manera de referenciar un paquet TS  és amb el binomi identificador de xarxa original/identificador de transport stream. Per identificar un servei, a aquest binomi s’afegeix l’identificador de servei. A més, cada identificador de servei és únic per a cada identificador de xarxa original. Quan un servei canvia de sistema de difusió, només la identificació de xarxa canvia.

- La NIT està organitzada de la següent manera:

/* header ....*/
for i = 0; i < N; i++ { /* 1st descriptor loop */
descriptor()
}
for ( i = 0; i < N; i++) {
/* loop over Transport Streams */
transport_stream_id
original_network_id
for ( j = 0; Ij < M; j++) { /* 2nd descriptor loop */
descriptor()
}
}
/* CRC etc. */


 - La funció descriptor va cridant els diferents descriptors de la taula. El primer de tots és el descriptor d’unió (linkage), que es fa servir per unir un servei amb un altre o TS. Es pot passar més d’un cop, així, per exemple, es podria duplicar la informació d’un TS. El valor del descriptor, en aquest cas, depèn del tipus d’unió. Si aquest és 0x01, es refereix a un servei que conté informació sobre la xarxa. Si és 0x02, es refereix a l’EPG (Electronic Program Guide). Si és 0x04 es refereix a un TS que porta informació de servei (SI).

 - Descriptor de multillengua. S’utilitza per transportar el nom de la xarxa en una o vàries llengües. Aquest descriptor és opcional i és molt similar al descriptor de nom de xarxa que s’utilitza per transmetre el seu nom físic. Per exemple, “Astra”, “Hispasat”, “Menta”, etcètera.

 - El segon bucle comença amb els descriptors de lliurament de sistema. En té un per a cable, un per a satèl·lit i un de terrestre. S’utilitza per transmetre els paràmetres físics de cada multiplexat de la xarxa.

- Un segon descriptor d’aquest segon bucle és el de llista de servei. S’utilitza per llistar els serveis i tipus de serveis de cada TS. Els serveis es diferencien per un identificador de servei (similar al número de programa MPEG-2). L’identificador de TS i l’identificador de xarxa original es donen en aquest moment també.

- L’últim descriptor és el de llista de freqüències, que dóna informació de freqüències alternatives on trobar el mateix multiplexat. La seva inclusió és opcional, però, si es presenta, és obligatori que estigui complerta.
 

3.3.6.2.- Bouquet Association Table (BAT)

- La primera de les taules definides pel DVB és la BAT. Un bouquet es podria definir com una sèrie de serveis que es marquen com una sola entitat. Per exemple, podríem dir que existeix el bouquet d’esports, que farà que els programes esportius que s’estiguin emetent tinguin un identificador comú. D’aquesta manera és molt més fàcil organitzar les EPG (Electronic Program Guides).

- Un sol programa pot estar present en BAT diferents, així com una BAT pot portar informació de programes que no estiguin viatjant en el mateix TS, sempre que siguin aportats pel mateix proveïdor. L’accés a la informació de tots els serveis d’un (o diversos) TS queda reforçada per la Service Description Table (SDT). De manera similar, la NIT també proporciona un accés més fàcil als serveis. A més a més, cal fer esment en el fet que normalment existeixen diverses BAT en cada TS, una per a cada bouquet diferent.

- L’algorisme de la BAT és el següent:

/* header ....*/
for i = 0; i < N; i++ { /* 1st descriptor loop */
descriptor()
}
for ( i = 0; i < N; i++) {
/* loop over Transport Streams */
transport_stream_id
original_network_id
for ( j = 0; I < M; j++) { /* 2nd descriptor loop */
descriptor()
}
}
/* CRC etc. */


 - En el primer bucle se cerca el nom del bouquet al qual els serveis que vénen a continuació estan associats. Aquest camp és obligatori. Un altre identificador és el d’accés condicional. La seva transmissió és opcional i identifica un o més sistemes d’accés condicional que s’apliquen als serveis de la BAT.

 - Un tercer descriptor és el de la disponibilitat de país, que indica si un bouquet està disponible per a un país determinat. No té res a veure amb l’accés condicional, però pot evitar, per exemple, que un receptor de França sigui capaç de rebre les emissions de TVC internacional (si es volgués). Aquesta taula es passa dues vegades per a cada BAT. Una on s’indiquen els països als quals aquella BAT està destinada, i l’altra amb els països als quals no està destinada. La transmissió d’aquest descriptor és opcional.

 - El quart descriptor d’aquest bucle és el d’unió, que proporciona una unió amb un altre TS, i la seva transmissió és opcional. El valor de l’identificador determina el tipus d’informació que conté. Si aquest és 0x01, es refereix a un servei que conté informació sobre aquest bouquet. Si és 0x02, es refereix a l’EPG (Electronic Program Guide) pel bouquet. Si és 0x04, es refereix a un TS que porta informació de servei (SI) que conté dades dels serveis del bouquet.

 - L’últim descriptor d’aquest bucle és el de bouquet multilingüe. Serveix per posar el nom del bouquet en una o més llengües. La seva inclusió és opcional.

 - Pel que fa al segon bucle, només conté el descriptor de llistes de serveis. S’utilitza per tenir un llistat del serveis i tipus de serveis per a cada TS que pertany al bouquet. Això permet trobar tots els serveis que pertanyen a un bouquet determinat. La transmissió d’aquest descriptor és obligatòria si s’envia la BAT.
 

3.3.6.3.- Event Information Table (EIT)

 - La taula d’informació d’events s’utilitza per transmetre informació d’events actuals i futurs. Existeix una subtaula EIT per a cada servei. La normativa de l’SI especifica que la mida màxima d’una secció EIT sigui de 4096 bytes. També especifica que han d’existir dues seccions per servei per a una EIT, que corresponen a la informació del programa actual i a la informació del següent programa. L’identificador d’aquestes seccions és 0x00 i 0x01, respectivament. Un exemple d’EIT el trobem en l’emissió de Canal Satélite Digital: si estem en un programa determinat i premem la tecla “Piloto”, ens apareix la informació d’aquell programa i del següent.

 - Aquestes normes no són aplicables, però, al cas de l’NVOD (Near Video On Demand) ja que tenen més d’un descriptor d’event per secció i es pot donar el cas que hi hagi més de dues seccions.

 - L’organització de l’EIT es basa en saber quin és el programa actual i quin és el següent. Per saber quin és l’event actual, se segueix el següent esquema:
 

a) En cada moment només hi ha un event.
b) L’event actual només pot ser descrit a la secció 0.
c) Quan no hi ha event actual s’envia la secció 0 buida.
d) El camp d’estat actual té les interpretacions de la taula següent:
Indefinit
Només informació d’estat.
Els IRD i els VCR tracten l’event actual com si estigués en emissió.
En emissió
Els IRD i els VCR tracten l’event actual com si estigués en emissió.
No està en emissió
Els IRD i els VCR tracten l’event actual com si no estigués en emissió. Per exemple, es podria donar el cas que l’event no hagués començat encara.
En pausa
Els IRD i els VCR tracten l’event actual com si estigués en pausa. L’event actual ha començat, però el que s’està emetent no és part de l’event pròpiament dit (anuncis, ...).
Comença en breu
Els IRD i VCR es preparen per a un canvi d’estat a “en emissió” en pocs segons.
 - La durada d’un event, tal i com ha estat codificada en el camp de duració de l’EIT, pot incloure la informació dels moments en què l’event té l’estat de “no està en emissió” o “en pausa”. L’hora d’inici d’un event es troba al camp d’inici de l’EIT.
e) A cada moment ha d’haver-hi, com a mínim, un event següent.
f) Aquest event següent ha de ser descrit a la secció 1.
g) Si no existeix aquest event, la secció 1 s’envia buida
h) El camp d’estat actual del següent event pot tenir les interpretacions següents:
Indefinit
Només informació d’estat.
Els IRD i els VCR tracten l’event actual com si estigués en emissió.
En emissió
No és possible.
No està en emissió
Els IRD i els VCR tracten l’event actual com si no estigués en emissió. 
En pausa
Es fa servir per indicar que el següent event començarà en algun moment, però actualment està sobreposat per un altre event.
Comença en breu
Els IRD i VCR es preparen per a un canvi d’estat a “en emissió” en pocs segons.

 - La informació de la programació de l’EIT està estructurada de manera que l’accés a la informació sigui flexible. Les taules d’esdeveniments es fan segons les normes següents:
 

a) La programació de l’EIT es distribueix sobre 16 identificadors de taula que comprenen els valors de 0x50 a 0x5F, per al TS actual, i de 0x60 a 0x6F, per a altres TS, els quals s’ordenen cronològicament.
b) Les 256 seccions de cada subtaula es distribueixen en 32 segments de 8 seccions.
c) Cada segment conté informació sobre events que comencen en les properes 3 hores.
d) La informació dels events està ordenada cronològicament sobre els segments.
e) Si s’utilitzen menys de 8 seccions d’un segment, la informació es posa en les primeres seccions. Per senyalitzar que les últimes no s’utilitzen, es fa servir el valor s0+n-1, on s0 és el primer número de secció del segment i n és el número de seccions utilitzades. Aquest valor s’ha d’enviar al camp que indica l’últim número de secció de la capçalera EIT.
f) Els segments que continguin totes les seccions han de tenir s0+7 en l’esmentat camp.
g) Les seccions que estiguin buides totalment tindran el valor s0+0.
h) Els horaris es posen referenciats a un temps t0 que es correspon a l’última mitjanit, segons l’UTC (Temps Universal Coordinat). Per exemple, si suposem que són les 17:00 a la zona UTC-6 vol dir que a la zona UTC+0 són les 23:00 i, per tant, t0 a la zona UTC-6 són les 18:00.
i) El segment 0 de la taula 0x50 conté informació del events entre les 00:00:00 i les 02:59:59, i així successivament. Això vol dir que la primera subtaula conté informació dels primers 4 dies a partir de la mitjanit actual (un dia es divideix en 8 franges horaries i 4 dies fan els 32 segments d’una taula).
j) El camp “últim número de secció” s’utilitza per indicar el final de la subtaula.
k) Per indicar el final d’una EIT s’utilitza el camp “últim identificador de taula”.
l) Les taules no són aplicables al NVOD ja que el temps d’inici d’aquests events és indefinit.


- Les taules EIT poden ser encriptades. Perquè això sigui possible, és necessari crear una associació amb les trames d’accés condicional, cosa que es fa mitjançant un identificador de servei en la PSI que descrigui les taules EIT encriptades.

 - L’algorisme que segueix el descodificador per extreure la taula és el següent:

table_id /* classification of the EI-section : present following etc. */
/* header ....*/
service_id
transport_stream_id
original_network_id
for i = 0; i < N; i++ { /* descriptor loop */
event_id
start_time
duration
running_status
free_CA_mode
for ( j = 0; j < M; j++){
descriptor()
}
}
/* CRC etc. */
 - Els descriptors es criden en el bucle tal i com es pot apreciar. El primer que es troba és el descriptor de components, que s’utilitza per especificar tots els streams que es relacionen amb un event. Aquest descriptor pot aparèixer més cops en el bucle ja que pot haver-hi més d’un stream. La seva inclusió és obligatòria en els EIT actuals i següent del TS actual i és opcional per a altres EIT.

 - Un altre descriptor és el de contingut, que s’utilitza per descriure el contingut d’un event.

 - El descriptor de transmissió de dades s’utilitza per identificar la transmissió de dades orientades a event sobre DVB.

 - Per transmetre una major quantitat de text que descrigui l’event, s’utilitza el descriptor d’event extès. És possible d’enviar-ne diversos, d’aquests descriptors, per tenir més dels 255 bytes que ofereix un descriptor sol. Per permetre unions amb altres serveis que estiguin relacionats amb l’event actual es fa servir el d’escriptor d’unió.

 - Per tal d’escriure text en diferents llengües s’utilitza el descriptor multilingüe. Per tal d’evitar que persones intel·lectualment sensibles puguin veure programes amb continguts no adients per a ells, hi ha el descriptor paternal.

 - Un altre descriptor que és obligatori és el d’event curt, que s’utilitza per transmetre el nom i una petita descripció de l’event.
 

3.3.6.4.- Service Description Table (SDT)

 - L’SDT es fa servir per fer un llistat dels noms i altres paràmetres dels serveis entre TS. Per a cada TS existeix una SDT. El procés que assegura l’adquisició dels paràmetres és el següent:

 - La transmissió de l’SDT pel TS actual és obligatòria i, a més, l’SDT ha de tenir una llista amb, com a mínim, tots els serveis d’aquell TS. Com a recomanació s’estableix que els identificadors dels serveis siguin únics en una xarxa, ja que així es permet als IRD tenir una llista amb els programes preferits de l’usuari, ...

 - L’algorisme que segueix el descodificador per extreure les dades és el següent:

table_id /* distinction between actual & foreign MUXes */
/* header ....*/
transport_stream_id
original_network_id
for i = 0; i < N; i++ { /* descriptor loop */
service_id
EIT_schedule_flag
EIT_present_following_flag
running_status
free_CA_mode
for ( j = 0; j < M; j++){
descriptor()
}
}
/* CRC etc. */
- En el bucle es cerquen els descriptors següents: 3.3.6.5.- Time and Date Table (TDT)

 - Transmet l’UTC actual codificat com a Data Juliana Modificada (MJD). Es pot fer servir per sincronitzar el rellotge intern d’un IRD. La TDT s’ha de transmetre, com a mínim, un cop cada 30 segons. L’EIT s’actualitza gràcies a la TDT.
 

3.3.6.6.- Time Offset Table (TOT)

 - La TOT transmet el temps UTC actual, incloent informació d’offset codificada com a MJD. També es pot fer servir per sincronitzar el rellotge intern del receptor. La seva transmissió és opcional, però, si es transmet, s’ha de fer cada 30 segons, com a màxim.

 - Existeix un descriptor per a aquesta taula. És el descriptor d’offset del temps local, que s’utilitza per indicar aquest offset del temps local així com ajustar automàticament el rellotge de l’IRD per als horaris d’estiu i d’hivern.

 - Les dades d’aquest descriptor sempre seran les mateixes, excepte quan es produeixin els esmentats canvis d’horaris. Si un país té més d’una zona horària, existeix un identificador regional que les identifica.
 

3.3.6.7.- Running Status Table (RST)

- Es fa servir per saber de manera ràpida l’estat d’un event (si està en emissió, ...). Aquesta taula només s’envia quan un event canvia d’estat, i no ho fa repetidament com les altres taules. Quan es transmet una RST per a un event determinat, aquest invalida l’estat de l’event actual transmès anteriorment per l’EIT. El següent cop que s’enviï una EIT s’haurà d’actualitzar l’estat de l’event.

- Amb això el que s’intenta és que els IRD o VCR siguin capaços de commutar-se just quan l’event escollit comenci, tot fent un polling de l’RST de l’event.
 

3.3.6.8.- Stuffing Table (ST)

 - Una taula de farciment pot aparèixer en qualsevol taula de l’SI. S’utilitzen per reemplaçar o invalidar subtaules o bé per completar taules SI. Per garantir la consistència, no es permet un farciment parcial d’una subtaula, sinó que aquesta s’ha de farcir completament.
 

3.3.6.9.- Descriptors de la PMT

 - A part dels descriptors propis que defineix l’MPEG-2, DVB en defineix de nous per a la PMT. Aquests són:
 


3.3.6.10.- Discontinuity Information Table (DIT)

 - La taula de discontinuïtat d’informació s’utilitza en els punts de transició en què la informació de servei és discontínua. Aquesta discontinuïtat pot ser produïda per un canvi de xarxa, per exemple.
 

3.3.6.11.- Selection Information Table (SIT)

 - Conté un resum de totes les informacions importants que hi ha en el TS. La seva presència identifica els bitstreams com un TS parcial provinent d’una interfície digital. En aquest cas, el receptor no mirarà la informació que li arriba del DVB-SI i només es fixarà en la informació que li arriba de la SIT.
 

3.3.6.12.- PID de les diferents taules

 - A la taula següent es presenten els PID que corresponen a cadascuna de les taules que comprenen el multiplexat DVB:
 

Taula
Valor del PID
PAT
0x0000
CAT
0x0001
TSDT
0x0002
Reservat
0x0003 a 0x000F
NIT, ST
0x0010
SDT, BAT, ST
0x0011
EIT, ST
0x0012
RST, ST
0x0013
TDT, TOT, ST
0x0014
Sincronització de xarxa
0x0015
Reservat per a un futur
0x0016 a 0x001D
DIT
0x001E
SIT
0x001F

3.3.6.13.- Freqüència de repetició de les taules

 - En aquest cas, cal distingir les emissions de DVB per cable i satèl·lit de les terrestres. Per satèl·lit i cable se suposa que hi haurà suficient ample de banda en un canal per transportar la informació. Les freqüències de repetició són les següents:

a) Totes les seccions de la NIT han de ser transmeses, com a mínim, cada 10 segons, incloses aquelles que viatgin per altres camins de difusió, si és que hi són.
b) Totes les seccions de la BAT han de ser transmeses, com a mínim, cada 10 segons, si està present.
c) Totes les seccions de l’SDT del multiplexat actual han de ser transmeses cada 2 segons, com a mínim.
d) Totes les seccions de l’SDT d’altres TS s’han de transmetre, com a mínim, cada 10 segons.
e) Totes les seccions de l’EIT dels events actual i següent del TS actual s’han de transmetre cada 2 segons, com a mínim.
f) Totes les seccions de l’EIT d’events d’altres TS s’han de transmetre cada 10 segons, com a mínim, si és que existeixen.
g) Totes les seccions de la programació de l’EIT dels primers 8 dies s’han de transmetre, com a mínim, cada 10 segons, si és que existeixen.
h) Totes les seccions de la programació de l’EIT de dies més enllà del vuitè s’han de transmetre cada 30 segons (incloent-hi les dels altres TS), si és que existeixen.
i) La TDT i la TOT s’han de transmetre cada 30 segons, com a mínim.


 - Pel que fa a les emissions de televisió digital terrestre, l’ample de banda és molt limitat per a la quantitat d’informació que s’ha de transmetre i es defineixen les següents repeticions:

a) Totes les seccions de la NIT han de ser transmeses, com a mínim, cada 10 segons, incloses aquelles d’altres camins de transmissió, si és que hi són.
b) Totes les seccions de la BAT han de ser transmeses, com a mínim, cada 10 segons, si està present.
c) Totes les seccions de l’SDT del multiplexat actual han de ser transmeses cada 2 segons, com a mínim.
d) Totes les seccions de l’SDT d’altres TS s’han de transmetre, com a mínim, cada 10 segons.
e) Totes les seccions de l’EIT dels events actual i següent del TS actual s’han de transmetre cada 2 segons, com a mínim.
f) Totes les seccions de l’EIT d’events d’altres TS s’han de transmetre cada 20 segons, com a mínim, si és que existeixen.
g) Totes les seccions de la programació de l’EIT del dia actual s’han de transmetre, com a mínim, cada 10 segons, si és que existeix.
h) Totes les seccions de la programació de l’EIT del dia actual d’un altre TS s’ha de transmetre cada 30 segons.
i) Totes les seccions de la programació de l’EIT del TS s’han de transmetre, com a mínim, cada 30 segons, si és que existeixen.
j) Totes les seccions de la programació de l’EIT d’altres TS s’han de transmetre, com a mínim, cada 30 segons, si és que existeix.
k) La TDT i la TOT s’han de transmetre cada 30 segons, com a mínim.


3.3.6.14.- Aplicacions

 - La Informació de Serveis (SI) del DVB ha estat dissenyada per treballar sobre un gran marge d’aplicacions. A continuació s’expliquen algunes aplicacions de l’SI:
 

3.3.6.14.1.- NVOD

- El concepte de Near Video On Demand (NVOD) es defineix com la repetició d’un programa durant tot el dia, però desplaçada en instants de temps. A la figura 3.52 es pot apreciar un exemple de NVOD on apareixen sis versions desplaçades del mateix servei.


Figura 3.52. Exemple de NVOD

- Per descriure aquest servei de NVOD amb un SI convencional es requeriria l’existència de sis EIT. En comptes de malgastar d’aquesta manera l’ample de banda, el que es fa és donar un servei de referència. Aquesta referència es troba a l’identificador de servei de referència que enllaça una descripció dels events d’un servei per a tots els serveis que pertanyen a un servei de NVOD. L’EIT del servei de referència es troba al TS on estan allotjats els serveis de NVOD.

- Cada servei desplaçat té informació de la identificació del TS, de la identificació de la xarxa original i de la identificació de servei que està llistat al descriptor de la referència de NVOD de l’SDT. A més a més, cada servei desplaçat està descrit pel descriptor de servei de temps desplaçat de l’EIT que apunta a la descripció de referència de la mateixa EIT. Aquest procés està esquematitzat a la figura 3.53.


Figura 3.53. Descripció dels serveis de NVOD

- Utilitzant aquest mètode, la quantitat de dades a transmetre es redueix uns 5 cops. L’hora d’inici de l’EIT es posa tota a 1, ja que l’hora d’inici dels events es dóna a les EIT dels respectius serveis de temps desplaçat. Tots els events del servei de referència NVOD han d’estar descrits en l’EIT del servei actual/següent.
 

3.3.6.14.2.- Mosaic

- Els serveis de mosaic poden afectar a més d’un TS. El mosaic s’estructura en forma d’arbre. Està composat per una sèrie de petites imatges de diferents programes sobre una mateixa imatge. Aquestes petites imatges es codifiquen en l’origen de tal manera que cadascuna ocupa una àrea determinada a la imatge.

- Cada àrea s’anomena cel·la lògica i estan composades de cel·les elementals, poden haver-hi fins a 8x8, totes numerades. Cada cel·la lògica s’identifica amb un identificador de cel·la.

- El descriptor del mosaic identifica les cel·les elementals, les agrupa per formar cel·les lògiques i estableix una unió entre el contingut de totes (o algunes) les cel·les lògiques i la informació corresponent de l’SDT, EIT o BAT ja que hi ha relació entre el descriptor de servei i les altres taules. El descriptor de mosaic viatja a les seccions del servei de mosaic de l’SDT i/o PMT. Si s’utilitza només a l’SDT, es redueix la interacció entre DVB-SI i les taules MPEG. Sigui com sigui, un servei de mosaic que contingui múltiples components de vídeo pot ser descrit únicament amb el descriptor de mosaic, apareixent múltiples vegades sobre la secció PMT.

- Un exemple d’elecció d’un programa mitjançant un mosaic es pot veure a la figura 3.54. Val a dir que també s’ajunta amb el concepte de guia electrònica.


Figura 3.54. Exemple de mosaic

- L’algorisme per cercar un servei d’un mosaic és el següent:

3.3.6.15.- Visualització per pantalla

 - A la figura 3.53 es pot veure un exemple d’ús de les taules MPEG-2 PSI i DVB-SI:


Figura 3.53. Ús de MPEG-2 PSI i DVB-SI

 - El que mostra aquesta figura és la informació tal i com la pot arribar a veure l’usuari mitjançant la interfície home-màquina que els sistemes DVB volen fer més amigable. En primer terme, podem apreciar la PMT, que conté la informació de quins són els PID dels elementary streams que composen el programa, Méteo en aquest cas. En segon terme hi ha la NIT, que ens indica les característiques dels transponedor de satèl·lit que estem sintonitzant (tot això es veurà àmpliament al capítol 4).

 - Sobre la imatge, es poden apreciar les diferents dades a les que pot arribar a accedir l’usuari mitjançant l’ús de diferents botons del seu comandament a distància i amb quina taula estan relacionades cadascuna d’aquestes informacions en pantalla.

 - El servei “Canal Méteo interactivo” es podria equiparar a un “teletext” d’alta qualitat en el qual un usuari pot triar en qualsevol moment veure la informació del temps, sobre un mapa de símbols, que hi haurà en una zona determinada de l’Estat Espanyol.

 - Al capítol 5, es podran veure amb detall les taules que formen la plataforma Quiero TV i quines dades transporten, així com diferents mesures RF sobre els diferents canals d’aquesta plataforma.
 
 

3.4.- Time stamps i clock references

- La figura 3.54 mostra un exemple de descodificador MPEG-2 capaç de descodificar àudio i vídeo d’un TS o bé d’un PS. Els commutadors estan controlats de tal manera que només agafen els paquets de transport (o els paquets PES, si es tracta de PS) que corresponen a l’àudio, vídeo o dades, segons convingui, i els posen al buffer corresponent. Aquest buffer es va omplint d’unitats d’accés.

- El descodificador sabrà en quin moment descodificar cada imatge (o àudio) pel Time Stamp. Evidentment, amb aquest procés ens assegurarem que el vídeo, l’àudio i les dades que formen un determinat programa estiguin completament sincronitzats, a més d’evitar possibles solucions d’underflow o overflow als buffers.


Figura 3.54. Exemple de descodificador

- Si ara ens fixem més en la part del vídeo i seguim l’exemple de la figura 3.54, veurem que el codificador de vídeo ha generat tres unitats d’accés: la 10:27, la 10:28 i la 10:29. Així doncs, la primera ha de ser descodificada quan quedin 3 minuts per a dos quarts d’onze, la segona quan en quedin dos, i així successivament. Evidentment, aquest és un exemple macroscòpic on no s’ha tingut en compte la representació real del temps. Més endavant se’n parla, de tot plegat.

- Per tal de col·locar els Time Stamps, el codificador ha de tenir una referència de temps. L’hora actual resideix en un rellotge dins del multiplexor (ha de ser molt precís). Cada cop que es crea una nova unitat d’accés, s’escaneja el temps actual i es crea un Time Stamp per a aquesta unitat d’accés. La marca temporal no es correspon amb l’hora actual, sinó que és el moment en què s’haurà de descodificar el senyal.

- Aquest moment de descodificació (offset respecte al moment de codificació) és variable i està subjecte a diversos factors, com poden ser, per exemple, la mida del buffer del codificador i del descodificador i del bit rate amb el qual es multiplexa tot el senyal MPEG-2. Aquest offset ha de ser el suficientment important perquè la unitat d’accés pugui travessar el buffer del codificador, passar pel multiplexat i ser escrit posteriorment en el buffer del descodificador.


Figura 3.55. Exemple de marcatge de temps

- Per interpretar les marques de temps, el descodificador necessita del seu propi rellotge per determinar el moment apropiat per descodificar una unitat d’accés. Ara bé, aquest rellotge està en perfecte sincronia amb el del codificador, cosa que s'aconsegueix afegint mostres del temps actual al multiplexat MPEG-2.

- Els rellotges del multiplexor i del descodificador es mesuren en realitat en unitats de 27MHz que governen un comptador de 42 bits, i no es requereix que els rellotges es relacionin amb l’hora de la nació.

- En un PS, el rellotge del multiplexor és l’anomenat rellotge de sistema (System Clock). Mostres del rellotge del sistema s’envien regularment al descodificar mitjançant la capçalera d’un paquet PES, podent mantenir així la sincronia requerida. Aquestes mostres són les referències de rellotge del sistema (System Clock References (SCR)). Una SCR ha d’aparèixer cada 0.7 segons (1,42 cops per segon).

- En un TS, cada programa té el seu propi rellotge. És el rellotge de programa (Program Clock). Aquest no ha d’estar necessàriament sincronitzat amb els altres rellotges de programa, encara que està permès. Les mostres del rellotge de cada programa s’envien dins dels paquets que formen el TS. Una PCR per a cada programa ha d’aparèixer, com a mínim, un cop cada 0.1 segons. La informació sobre quin PID té informació d’un rellotge determinat apareix a la PMT. La informació del rellotge viatja o bé en un paquet o bé en el camp d’adaptació.

- Les marques de temps pròpiament dites són mostres d’un comptador binari de 33 bits governat per un rellotge de 90 kHz.

- Hi ha dos tipus de marques de temps. La primera, i més important, és  la marca de temps de representació (Presentation Time Stamp (PTS)). Especifica el moment en què una unitat d’accés ha de ser llegida del buffer del descodificador, descodificada i representada a l’espectador. La normativa MPEG pressuposa que aquest temps és instantani, però això no és del tot veritat ja que el procés de descodificació ja porta un cert temps. El dissenyador del descodificador haurà de compensar aquest aspecte.

- Per a molts ES, els PTS són les marques de temps que es necessitaran. En canvi, per a ES que portin informació de vídeo, aquestes marques no són suficients i es requereix de les marques de temps de descodificació (Decoding Time Stamps (DTS)).

- Un DTS determina el moment en què una unitat d’accés ha de ser llegida del buffer, descodificada, però no representada a l’espectador. En comptes d’aquest últim punt, la imatge és temporalment emmagatzemada en una memòria per a una representació posterior. I això per què? Doncs perquè existeixen les imatges P i B que necessiten d’una imatge I (o una altre P) per a la seva descodificació i, per tant, aquesta ha d’estar a la memòria del descodificador com a imatge referència (o imatges referència). Per exemple, si hi ha una imatge B, necessitem de la imatge I precedent i de les imatges P dels frames posteriors. Gràficament, tot aquest procés es pot apreciar a la figura 3.56.

- Una DTS no pot existir sense una PTS. En vídeo, la PTS especificarà el moment en què la imatge emmagatzemada serà representada per pantalla. Per tant, la PTS tindrà un valor més elevat que la DTS.


Figura 3.56. Exemple de DTS i PTS

- Les marques de temps no han d’estar necessàriament en cada unitat d’accés. Els descodificadors sabran normalment el període en què els arribaran les instruccions per descodificar les unitats d’accés.
 
 
 

Tornar a l'índex general
Passar al següent capítol: DVB



Per qualsevol comentari, escriu un e-mail a:
Xavier Puig i Farré
Laboratori de Vídeo i Televisió / CeTVD (Centre de Televisió Digital)
Enginyeria La Salle



Enginyeria La Salle
Universitat Ramon Llull
Passeig Bonanova, 8 - 08022 Barcelona. Telf: 290 24 00 - Fax: 290 24 16
Departament de Vídeo i Televisió / CeTVD. Telf: 290 24 28
E-mail: video_tv@salleURL.edu

Última Actualització: 11-11-01