Capitolo 1 - AIRT Lab - Università Politecnica delle Marche

Transcript

UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTÀ DI INGEGNERIA
Corso di Laurea in
Ingegneria Informatica e dell’Automazione
DIGITAL VIDEO BROADCASTING E LINUX:
INSTALLAZIONE E SPERIMENTAZIONE DI UNA
SCHEDA DVB-T SU UN SISTEMA LINUX
MINIMALE
Relatore:
Prof. Aldo Franco Dragoni
Tesi di Laurea di:
Matteo Pandolfi
Anno Accademico 2006/2007
Indice
Indice ................................................................................................................................. i Elenco delle figure........................................................................................................... v Elenco dei listati ............................................................................................................. vi Capitolo 1: Lo standard DVB .......................................................................................... 1 1.1 Introduzione ....................................................................................................... 1 1.2 Il consorzio DVB Project ................................................................................... 2 1.3 Le specifiche ...................................................................................................... 3 1.4 Il DVB-T: lo standard per la televisione digitale terrestre ................................. 3 1.4.1 La codifica MPEG-2 ................................................................................... 5 1.4.2 Il flusso di trasporto .................................................................................... 8 1.4.3 Le informazioni di servizio ....................................................................... 10 1.4.4 Ricerca e decodifica di un programma ..................................................... 12 1.4.5 Accesso Condizionato e Cifratura ............................................................ 12 1.4.6 Le specifiche di livello fisico .................................................................... 13 1.4.7 Bit rate e configurazioni tipiche................................................................ 16 1.4.8 La trasmissione gerarchica........................................................................ 16 1.4.9 Schema del sistema di trasmissione .......................................................... 17 1.5 Il DVB-T in Italia ............................................................................................. 18 1.6 MHP: lo standard per la TV interattiva ............................................................ 19 1.6.1 Architettura ............................................................................................... 20 1.6.2 I profili ...................................................................................................... 21 1.6.3 Il protocollo di trasporto ........................................................................... 21 Capitolo 2: LinuxTV...................................................................................................... 23 2.1 Introduzione ..................................................................................................... 23 i
Indice
2.2 Storia del progetto ............................................................................................ 23 2.3 Le Linux DVB API .......................................................................................... 24 2.3.1 La struttura delle API ................................................................................ 25 2.3.2 Il riconoscimento dei dispositivi DVB ..................................................... 25 2.3.3 Frontend API............................................................................................. 26 2.3.4 Dispositivi di demux ................................................................................. 28 2.3.5 Decoder video ed audio ............................................................................ 29 2.3.6 Dispositivi per l’accesso condizionato ..................................................... 30 2.3.7 La quarta versione delle API .................................................................... 30 2.4 Le Video4Linux API ........................................................................................ 30 2.5 Utilities per il DVB .......................................................................................... 31 2.5.1 Scan ........................................................................................................... 32 2.5.2 Zap ............................................................................................................ 33 2.5.3 Dvbsnoop .................................................................................................. 36 Capitolo 3: Le schede per la TV digitale ....................................................................... 39 3.1 Introduzione ..................................................................................................... 39 3.2 Classificazione ................................................................................................. 39 3.2.1 Interfaccia di collegamento ....................................................................... 40 3.2.2 Tipo di segnale .......................................................................................... 40 3.2.3 Standard di trasmissione ........................................................................... 41 3.2.4 Caratteristiche hardware ........................................................................... 41 3.3 Anatomia di una scheda DVB .......................................................................... 42 3.4 La differenza tra le schede Budget e Premium ................................................ 43 3.5 La scheda ASUS My Cinema-P7131 Hybrid................................................... 44 3.5.1 Il chip TDA10046A .................................................................................. 45 3.5.2 Il chip SAA7131E ..................................................................................... 46 ii
Indice
Capitolo 4: Installazione e gestione della scheda DVB-T ............................................. 47 4.1 Le scelte progettuali ......................................................................................... 47 4.2 Ubuntu 6.06 LTS .............................................................................................. 48 4.2.1 Edizioni ..................................................................................................... 48 4.2.2 Installazione della versione desktop ......................................................... 49 4.2.3 Software indispensabile ............................................................................ 52 4.3 Installazione della scheda ................................................................................. 53 4.3.1 Firmware ................................................................................................... 53 4.3.2 Requisiti .................................................................................................... 54 4.3.3 Procedura di installazione ......................................................................... 55 4.3.4 Il telecomando........................................................................................... 56 4.4 Fase di test ........................................................................................................ 57 4.4.1 Scan ........................................................................................................... 58 4.4.2 Zap ............................................................................................................ 67 4.4.3 Prove di sintonizzazione dei canali ........................................................... 68 4.5 Visualizzazione della TV ................................................................................. 70 4.5.1 Impostazione di Gxine .............................................................................. 70 4.5.2 Uso del telecomando ................................................................................. 71 4.5.3 Registrazione della TV ............................................................................. 72 4.6 Analisi delle DVB-SI con Dvbsnoop ............................................................... 73 4.6.1 Program Association Table ....................................................................... 75 4.6.2 Network Information Table ...................................................................... 76 4.6.3 Service Description Table ......................................................................... 76 4.6.4 Event Information Table ........................................................................... 76 4.6.5 Time and Date Table................................................................................. 77 4.6.6 Program Map Table .................................................................................. 77 iii
Indice
4.6.7 Private stream ........................................................................................... 77 4.6.8 Application Information Table ................................................................. 78 4.6.9 Conditional Access Table ......................................................................... 78 4.7 Cenni di interattività ......................................................................................... 79 Capitolo 5: Conclusioni ................................................................................................. 82 5.1 Requisiti minimi ............................................................................................... 82 5.2 Vantaggi e limiti della tecnologia .................................................................... 84 Appendice ...................................................................................................................... 89 PAT ............................................................................................................................. 89 NIT .............................................................................................................................. 90 SDT ............................................................................................................................. 92 EIT .............................................................................................................................. 94 TDT ............................................................................................................................. 95 PMT 258 ..................................................................................................................... 96 AIT .............................................................................................................................. 98 Televideo .................................................................................................................. 100 CAT .......................................................................................................................... 102 Bibliografia .................................................................................................................. 103 iv
Elenco delle figure
Figura 1.1: Logo del DVB ................................................................................................ 1 Figura 1.2: Struttura organizzativa del DVB Project ........................................................ 2 Figura 1.3: Mappa mondiale di diffusione del DVB-T .................................................... 4 Figura 1.4: Schema standard del GOP di tipo MPEG-2 ................................................... 7 Figura 1.5: Costellazione di tipo QPSK.......................................................................... 14 Figura 1.6: Costellazione di tipo 16-QAM ..................................................................... 15 Figura 1.7: Bit rate utile (in Mbit/s) per tutte le configurazioni possibili ....................... 16 Figura 1.8: Diagramma a blocchi del sistema di trasmissione ....................................... 17 Figura 1.9: Area di copertura della rete Dfree ................................................................ 19 Figura 2.1: Logo del LinuxTV project............................................................................ 23 Figura 2.2: Struttura delle Linux DVB API .................................................................... 25 Figura 2.3: Logo del programma Dvbsnoop ................................................................... 36 Figura 3.1: Quattro tipi diversi di schede DVB-T .......................................................... 39 Figura 3.2: Schema dei componenti di una scheda DVB ............................................... 42 Figura 3.3: Schema del chip TDA10046 ........................................................................ 45 Figura 3.4: Schema del chip SAA7134 .......................................................................... 46 Figura 4.1:Schermata di scelta della lingua .................................................................... 49 Figura 4.2: Schermata del fuso orario ............................................................................. 50 Figura 4.3: Schermata scelta tastiera .............................................................................. 50 Figura 4.4: Schermata del partizionamento .................................................................... 51 Figura 4.5: Il sito DGTVi ............................................................................................... 59 Figura 4.6: Rete4 e Repubblica TV ................................................................................ 68 Figura 4.7: Finestra di Gxine con relativa Playlist ......................................................... 70 Figura 4.8: Menu in sovraimpressione di Gxine............................................................. 72 Figura 4.9: Pagina del televideo ..................................................................................... 78 Figura 4.10: Finestra di XleTView ................................................................................. 81 v
Elenco dei listati
Listato 2.1: Funzione di settaggio del frontend .............................................................. 34 Listato 2.2: Help di Dvbsnoop ........................................................................................ 38 Listato 4.1: Subroutine per ottenere il firmware della scheda ........................................ 54 Listato 4.2: Output di Mercurial ..................................................................................... 55 Listato 4.3: Lista delle periferiche PCI installate ........................................................... 56 Listato 4.4: Riconoscimento del telecomando ................................................................ 57 Listato 4.5: File delle frequenze iniziali per lo scan ....................................................... 60 Listato 4.6: Output del programma Scan ........................................................................ 64 Listato 4.7: File channels.conf ........................................................................................ 67 Listato 4.8: Confronto tra i canali Rete4 e Repubblica TV ............................................ 69 Listato 4.9: Parametri del segnale ricevuto con antenna portatile .................................. 69 Listato 4.10: Scansione dei PID con Dvbsnoop ............................................................. 74 Listato 4.11: Output del programma Dvbdata ................................................................ 80 vi
Capitolo 1: Lo standard DVB
Figura 1.1: Logo del DVB
1.1 Introduzione
Il DVB (Digital Video Broadcasting) rappresenta un insieme di standard europei per il
broadcasting della TV digitale, le cui specifiche vengono ratificate dall’ETSI, l’Istituto
Europeo per gli standard di Telecomunicazione. Esso è nato nel 1991 quando alcuni
broadcaster, produttori ed altri enti competenti in Europa si riunirono per discutere sulla
formazione di un gruppo che sorvegliasse l’introduzione della TV digitale. Tale gruppo,
conosciuto come ELG (European Launching Group, Gruppo di Lancio Europeo), puntò
su una struttura basata sul consenso, dove ogni attore coinvolto poteva essere d’accordo
riguardo alle tecnologie più adatte da utilizzare. Fu quindi elaborato un Memorandum
d’intesa (MoU) in cui i soggetti interessati s’impegnavano a mettere in disparte le
strategie competitive di mercato per perseguire un percorso basato sulla fiducia
reciproca. Tale atto venne firmato nel Settembre del 1993 da tutti i partecipanti
dell’ELG che in quella stessa data cambiarono il nome del gruppo da ELG a DVB
Project. Attualmente il consorzio è composto da più di 260 partner sparsi in
trentacinque paesi differenti.
Il gruppo si concentrò per primo sull’introduzione del digitale nella TV satellitare,
poiché aveva compreso che lo standard MAC (Multiplexed Analogue Components), nel
quale erano multiplexati audio digitale e video analogico, avrebbe presto lasciato spazio
ad una tecnologia completamente digitale. Così, nel Dicembre del 1993, vennero
formalizzate le specifiche dello standard DVB-S a cui fecero seguito, solamente tre
mesi dopo, quelle del DVB-C, lo standard per la televisione via cavo. Introdurre questi
primi due standard fu relativamente facile, in quanto non esistevano delle grandi
1
difficoltà tecnologiche da superare ed inoltre il quadro regolamentatorio non era
alquanto rigido.
Quando vennero raggiunti gli obiettivi prefissati inizialmente, forte della diffusione
degli standard DVB-S e DVB-C su scala ormai mondiale, il gruppo concentrò maggiori
sforzi sulla produzione delle specifiche per altri metodi di trasmissione. Così, accanto ai
primi due, nacque nel 1997 il DVB-T, lo standard per la TV digitale terrestre, che fu
seguito dal DVB-H, per i dispositivi mobili, e recentemente dal DVB-S2, per la
televisione satellitare di seconda generazione.
1.2 Il consorzio DVB Project
Il DVB Project è strutturato in quattro moduli coordinati dallo Steering Board.
Quest’ultimo agisce sotto la sorveglianza dell’Assemblea Generale. L’Assemblea
Generale è la massima autorità del consorzio; essa, rappresentata da tutti i membri che
hanno firmato il MoU, ha il compito di eleggere lo Steering Board e di ratificare tutte
decisioni prese dai gruppi sottostanti. Presidente dell’Assemblea, dal 1996, è Theo
Pheek (Philips). Lo Steering Board è l’organo operativo del progetto. Si occupa
principalmente di coordinare i gruppi sottostanti, decidendo la politica, le priorità ed il
budget. I moduli operativi sono invece quattro e sono suddivisi a seconda della
problematica affrontata: i primi due, quello Commerciale e quello Tecnico, sono il
motore del progetto e vengono divisi in ulteriori gruppi di lavoro, ognuno incaricato di
uno specifico compito. Gli altri due invece si occupano rispettivamente della gestione
dei brevetti e della promozione del lavoro del consorzio nel mondo.
Figura 1.2: Struttura organizzativa del DVB Project
La creazione di ognuno degli standard DVB parte dal Modulo Commerciale. Questo,
infatti, dopo aver ultimato uno studio accurato delle esigenze di mercato, stila un elenco
2
di requisiti commerciali che tengono conto fra l’altro di modalità di accesso ai servizi,
tempistiche e costi. Solo quando il Modulo Commerciale raggiunge un accordo su
questi ultimi, il progetto della specifica viene passato al Modulo Tecnico. Così, vengono
individuate varie soluzioni tecniche idonee e, sempre sulla base del consenso, viene
scelta ed implementata la migliore. Alla fine del processo la specifica viene presentata
di nuovo al modulo Commerciale che la invia allo Steering Board per la definitiva
approvazione. Per la ratificazione infine, il progetto viene mandato ad un organo di
standardizzazione competente come l’EBU (European Broadcasting Union, Ente
Radiotelevisivo Europeo) o l’ETSI. Secondo il consorzio il successo del DVB è dovuto
proprio a questi principi base di organizzazione e di progettazione orientata al mercato.
1.3 Le specifiche
Nel complesso, tutti gli standard ratificati dal DVB Project, definiscono una serie di
specifiche che riguardano tutti gli aspetti caratteristici di un sistema per la trasmissione
televisiva digitale. Queste possono essere suddivise in due categorie principali:
•
Livello logico:
- Formato di compressione Audio/Video
- Aggregazione di servizi
- Formato dei pacchetti
- Segnalazione dei servizi
- Incapsulamento di dati generici non A/V e di protocolli non DVB
- Realizzazione e distribuzione di applicazioni interattive
•
Livello fisico
- Specifiche sul segnale fisico nei vari mezzi trasmissivi (cavo, satellite,
terrestre)
1.4 Il DVB-T: lo standard per la televisione digitale terrestre
Questo standard tecnico, descritto da un documento dell’ETSI intitolato “EN 300 744
V1.5.1”, specifica la struttura, la codifica di canale e la modulazione per la trasmissione
della televisione digitale terrestre.
Il processo di realizzazione di questo formato è stato abbastanza lungo se lo si confronta
con gli altri realizzati precedentemente dal consorzio. Questo perché, la diffusione delle
trasmissioni in ambito terrestre comporta una complessità tecnica maggiore e numerosi
3
ostacoli da superare, rispetto al satellite o al cavo. Infatti, nelle bande di trasmissione
terrestri, quelle VHF (Very High Frequency, da 30 a 300 MHz) ed UHF (Ultra High
Frequency, da 300 MHz a 3 GHz), dato che l’aria non è né un mezzo isotropo né
omogeneo, la propagazione delle onde elettromagnetiche è soggetta ad elevato rumore
dovuto a fenomeni di attenuazione, riflessione e fading. Ulteriori difficoltà sono dovute
alla regolamentazione dello spettro di frequenze utilizzabili che risultava quasi
completamente congestionato dalle trasmissioni analogiche attive in tutto il territorio
europeo. Grazie a tutto questo, per il consorzio, il DVB-T non risultava una priorità.
Solo in seguito, grazie a progetti europei sull’alta definizione in ambito terrestre
(HDTV-T), vennero raggiunti i requisiti definiti dal Modulo Commerciale del DVB
Project e si procedette quindi alla realizzazione dello standard.
Figura 1.3: Mappa mondiale di diffusione del DVB-T
Dal 1997, quando fu pubblicato, ad oggi, questo sistema è diventato il più adottato al
mondo, contando più di 40 milioni di ricevitori distribuiti in 30 paesi diversi. Queste
specifiche hanno assunto una particolare importanza anche nel nostro paese da quando
nel 2003, data di lancio ufficiale del DVB-T in Italia, è iniziata la transizione dalla
televisione analogica a quella digitale. Tale processo, a causa della non ancora completa
copertura del segnale e della scarsa diffusione dei dispositivi di ricezione, è ancora
molto lento ma si concluderà probabilmente nel 2012, anno previsto per lo switch-off,
quando verranno definitivamente interrotte le trasmissioni analogiche.
4
Per quanto riguarda l’aspetto tecnico, il sistema DVB-T adotta, a livello logico, lo
standard MPEG-2 per il flusso video e l’MPEG-1 layer II per l’audio. Recentemente è
stato aggiunto il supporto per altri formati come il DTS o l’AC3 per l’audio multicanale
e il formato H.264 per il video in alta definizione. La scelta iniziale è stata determinata
dal fatto che, al momento della costituzione del DVB Project, l’MPEG-2 era il formato
più diffuso a livello mondiale. Oltretutto, accanto alle notevoli qualità di compressione,
l’MPEG-2 ha come pregio principale quello della flessibilità. Infatti è possibile adattare
il tipo di compressione e quindi la qualità delle immagini, a seconda delle condizioni di
trasmissione. A livello fisico è stata adottata la modulazione multi portante CODFM
(Coded Orthogonal Frequency Division Multiplexing), una tecnica molto robusta,
pensata appositamente per le trasmissioni terrestri.
1.4.1 La codifica MPEG-2
L’MPEG-2 è uno standard introdotto nel 1994 dal Moving Pictures Expert Group.
Oltre alla codifica di sorgente audio e video, esso è responsabile anche del formato di
multiplazione e del trasporto, che viene utilizzato per servizi multimediali di diffusione.
La caratteristica di scalabilità e flessibilità, che ha motivato la scelta di questo standard
come supporto per il broadcast televisivo, è originata dal fatto che l’MPEG-2 è
costituito da profili e livelli la cui combinazione consente di spaziare dalla più bassa
risoluzione fino all’alta definizione. I livelli determinano la risoluzione dell’immagine
ed il suo bit rate massimo. Ne sono definiti 4:
•
low level:
risoluzione uguale a quella dell’MPEG-1 con 352x288 pixel,
raggiunge una qualità non superiore a quella di un VCR domestico;
•
main level: formato 720x576 pixel, la qualità è simile a quella dei sistemi PAL e
NTSC ed è anche il livello adottato per la codifica dei DVD
•
high 1440: livello dedicato per il video ad alta definizione HDTV, la risoluzione
è 1440x1152;
•
high level: formato ad alta definizione detto Full HD, ottimizzato per schermi a
16:9, adotta la risoluzione 1920x1152.
I profili riguardano invece la modalità di compressione utilizzata e quindi definiscono il
tasso di compressione e la complessità del decodificatore. Ne sono presenti 5. Ognuno
contiene un set di tool per la compressione specifico del livello più tutti i tool del profilo
precedente, in modo da mantenere la compatibilità verso l’alto:
5
•
simple profile: contiene solamente i tool di base consentendo una notevole
semplificazione del codificatore/decodificatore. Per la predizione temporale, che
verrà spiegata in seguito, utilizza soltanto i frame I (Intra-frame) e P (Predictedframe);
•
main profile: è il formato con il miglior compromesso tra qualità e tasso di
compressione. Per la predizione utilizza oltre ai precedenti anche il frame di tipo
B (Bidirectional Frame);
•
4:2:2 profile: definito per applicazioni professionali, questo profilo, con bit rate
massimo di 50 Mbit/s, consente una qualità molto elevata delle immagini anche
dopo molte codifiche e decodifiche;
•
SNR profile: profilo con una qualità scalabile a seconda dell’SNR, il rapporto
segnale rumore;
•
spatial profile: costituisce un sistema scalabile spazialmente. Il flusso è
costituito da due strati, il primo con una definizione convenzionale e il secondo
contenente informazione aggiuntiva che consente una definizione più elevata;
•
high profile: utilizzato principalmente per l’alta definizione, quando il bit rate
del flusso video non risulta un problema.
La combinazione che viene convenzionalmente adottata dal DVB-T è costituita da Main
Level e Main Profile (ML@MP), raggiungendo circa 15 Mbit/s.
Per la compressione del video, l’MPEG-2 utilizza una tecnica lossy basata sulla
rimozione della ridondanza spaziale e temporale, tramite una codifica detta Intra-frame
e Inter-frame. La prima tecnica è simile a quella che viene utilizzata per il formato
JPEG. Ogni frame del video è considerato come una singola immagine, che viene divisa
in blocchi di 8x8 pixel a cui viene applicata la DCT (Trasformata Discreta Coseno), in
modo da ottenere una matrice composta da 64 elementi per blocco. Questa trasformata
prende in ingresso una matrice contenente i valori dei pixel e produce in uscita una
matrice contenente i coefficienti di frequenza spaziale, ordinati in modo crescente dal
primo in alto a sinistra fino all’ultimo in basso a destra. In pratica questa tecnica
analizza, partendo da un punto e spostandosi verso altri punti adiacenti, la variazione del
valore dei pixel. Quando questo valore cambia lentamente si ha una frequenza spaziale
bassa, che descrive l’immagine nelle sue linee principali, mentre quando cambia
rapidamente si è di fronte ad una frequenza spaziale alta, che rappresenta i dettagli. Il
6
motivo di questa trasformazione risiede nel passo successivo, quando alla matrice
ottenuta si applica una matrice di quantizzazione che elimina le componenti ad alta
frequenza dell’immagine. In questo passaggio avviene una irreversibile perdita di
informazione ma la qualità rimane pressoché inalterata all’occhio umano, perché non è
in grado di percepire le alte frequenze. In seguito il processo continua operando a zigzag, in modo da mettere in fila più valori uguali a 0 possibile. Lungo questo percorso
viene prima applicata una codifica RLE (Run Length Encoding) e poi un codice di
Huffman. La tecnica Inter-frame si basa invece sul fatto che ogni frame trasmesso
risulta essere molto simile al frame precedente e a quello successivo. Si può pensare
perciò di trasmettere minori informazioni ricavando ogni frame dal precedente.
Vengono definiti quindi, tre tipi di frame: I-frame è quello originale, codificato con la
tecnica illustrata precedentemente, P-frame
è un’immagine contenente soltanto le
differenze con l’I-frame precedente e B-frame è invece bidirezionale, può cioè essere
confrontato sia con il frame precedente che con quello successivo. Per rispettare le
specifiche di non propagazione degli errori e di scorrimento del filmato, è impensabile
costruire un flusso video contenente un solo I-frame. Le immagini vengono invece
organizzate in GOP (Group Of Pictures) contenenti ognuno un solo I-frame e un
numero variabile di P e B frame. Il pattern tipico è quello descritto in Figura 1.4.
Figura 1.4: Schema standard del GOP di tipo MPEG-2
Per quanto riguarda la codifica del segnale audio, lo standard MPEG Layer II (MP2)
utilizza le conoscenze derivate dalla psicoacustica, cercando di sfruttare al meglio i
limiti dell’orecchio umano, in modo da ottenere una buona compressione senza
7
degradare la qualità. Il range di udibilità del nostro orecchio è compreso tra 20 e 20000
Hz. La soglia di udibilità invece, è molto variabile a seconda della frequenza ed è
massima tra 2 e 4 kHz; si può quindi pensare di codificare con meno bit le frequenze
dove l’orecchio è meno sensibile. Un’altra analisi che viene effettuata è quella del
mascheramento, che può essere di due tipi. Il mascheramento in frequenza consiste nel
fatto che un suono con intensità elevata nasconde all’udito tutti gli altri suoni con
intensità minore che si trovano nello stesso range di frequenza. Il mascheramento
temporale invece si basa sul fatto che quando un tono di intensità elevata cessa,
l’orecchio impiega alcuni millisecondi di tempo prima di sentire i toni successivi,
periodo variabile a seconda della differenza di intensità dei suoni. Fatta questa
premessa, è possibile illustrare il metodo di codifica vero e proprio. In pratica l’MP2
divide il segnale originale in 32 sottobande di frequenza differenti e le analizza; se la
differenza tra bande contigue è superiore ad una certa quantità, la banda con intensità
più bassa non viene codificata. Non viene utilizzato invece il mascheramento temporale
che sarà poi adottato da tecniche di codifica più avanzate come l’MP3.
1.4.2 Il flusso di trasporto
Il risultato della codifica audio e video da origine a due flussi separati di dati binari, che
vengono chiamati Elementary Streams (ES). Oltre a questi si possono aggiungere anche
ES contenenti dati di controllo o dati aggiuntivi come sottotitoli, guide ai programmi
ecc. Va detto però che ogni stream contiene soltanto un tipo di dati e non include
nessuna informazione riguardo la temporizzazione e il sincronismo. Questi flussi
vengono poi trattati e codificati singolarmente. Il primo passo è quello di suddividere
questa struttura continua di dati in pacchetti di dimensione variabile formando il
Packetized Elementary Stream (PES). Ognuno di questi pacchetti è formato da un
campo intestazione ed un campo dati. Il primo contiene varie informazioni come lo
stream_id, diverso per ogni ES, il PTS (Presentation Time Stamp) e il DTS (Decoding
Time Stamp) per la ricostruzione temporale dei flussi. Inoltre, possono essere presenti
anche altre informazioni aggiuntive non obbligatorie. Il campo dati contiene invece i
vari segmenti dell’ES.
A questo punto del processo i vari PES confluiscono in un multiplex dove vengono
ricampionati e rimpacchettati all’interno di un unico stream finale di uscita. Per questa
operazione lo standard MPEG definisce due tipi di tecniche per lo stream:
8
•
Program Stream (PS): simile al flusso dell’MPEG-1, con cui mantiene la
compatibilità, esso può contenere un solo programma TV multiplexando uno o
più ES che devono però avere la stessa base temporale. Il PS è stato studiato
solo per applicazioni con basso tasso di errore dato che è formato da pacchetti di
lunghezza elevata e variabile. Viene utilizzato nello standard DVD.
•
Transport Stream (TS): composto da vari Elementary Streams, anche di più
programmi TV, per i quali non è necessaria una base temporale comune. In
questo caso i PES vengono suddivisi in pacchetti di dimensione fissa, pari a 188
byte, che vengono chiamati Transport Packets. Questo tipo di stream è quello
utilizzato per il broadcasting televisivo.
Ciò che si vuole ottenere, alla fine di tutto il procedimento, è un flusso di dati multi programma, cioè composto da più canali televisivi e da dati di vario tipo, che dovrà poi
essere trasmesso in una specifica banda di frequenza. Per fare questo, si utilizza come
prima cosa un encoder MPEG per ogni canale, in modo da creare vari stream diversi
chiamati Single Program Transport Stream o SPTS. Questi vengono poi aggregati da
dispositivi chiamati multiplexer e vanno a formare il Multiple Program Transport
Stream (MPTS), un flusso unico di dati che contiene però separati tutti i flussi
elementari di ogni programma più le informazioni per identificarli e ricostruirli
correttamente.
Alla base di tutto il meccanismo c’è il Transport Packet. Come già detto esso è
costituito da 188 byte di cui 4 vanno a formare l’header e il resto il payload, cioè i dati
veri e propri. A volte è presente anche un ulteriore campo detto Adaption Field che
serve soltanto a mantenere fissa la dimensione dei pacchetti. L’intestazione è formata da
8 campi diversi che vengono utilizzati dal decodificatore per garantire il sincronismo, la
gestione degli errori e il riconoscimento dei vari flussi diversi. Questi sono:
•
Sync byte: permette di sincronizzare la trasmissione definendo l’inizio di un TP;
è costituito da 8 byte fissi con il valore 0x47.
•
Transport error ind: indica se il pacchetto è danneggiato.
•
Payload Unit Start ind: settato a 1 quando il pacchetto contiene l’inizio di un
PES.
•
Transport Priority: serve a dare priorità ad alcuni pacchetti.
9
•
Transport Scrambling Control: indica il tipo di cifratura del pacchetto, 00 se non
è presente.
•
Adaption Field Control: indica la presenza del campo opzionale Adaption Field.
•
Continuity Counter: contatore che viene incrementato per ogni Transport Packet
dello stesso Elementary Stream; è utile per rilevare la perdita di pacchetti.
•
PID (Packet Identifier): identificativo unico dei pacchetti; con questo campo si
crea una mappatura utile per identificare i vari servizi: tutti i Tranport Packets
che contengono il medesimo PID trasportano lo stesso flusso di dati elementare,
come per esempio il video o l’audio di un certo programma televisivo oppure
dati di servizio.
Per quanto riguarda la trasmissione di flussi di dati, il multiplexer non fa differenza, li
incapsula all’interno dei pacchetti e gli assegna un PID allo stesso modo di qualunque
altro stream audio o video. Sarà poi compito del decoder, riconoscere i vari tipi di
pacchetti e ricostruire i dati in maniera opportuna.
1.4.3 Le informazioni di servizio
Per aiutare il ricevitore ad identificare e ricostruire gli stream elementari, il Transport
Stream, descritto nel paragrafo precedente, viene ampliato con una serie di informazioni
di servizio che ne descrive la struttura. Tali informazioni, suddivise in un set di tabelle,
vengono specificate dallo standard DVB-SI (Service Information) con la pubblicazione
da parte dell’ETSI del documento “EN 300 468 v1.7.1”, la cui ultima versione risale al
2006. Alcune di queste informazioni però vengono solo citate dal DVB-SI, perché
fanno già parte dell’MPEG-2, contenute nella Program Specific Information (PSI).
Questa struttura gerarchica è costituita da 4 tabelle che vengono suddivise in sezioni e
pacchettizzate nel Transport Stream. Esse sono:
•
Program Association Table (PAT): al livello più alto della gerarchia, elenca il
numero di programmi TV e servizi presenti nel TS multiplexato. Per ognuno di
questi fornisce il riferimento (tramite indicazione del PID) con cui recuperare la
tabella dettagliata di ogni singolo canale, la PMT. Inoltre, il programma numero
0 indica sempre il PID della tabella NIT, la quale verrà spiegata in seguito. La
PAT è la prima informazione letta dal ricevitore ed ha PID fisso pari a 0.
•
Program Map Table (PMT): trasmessa su un PID arbitrario, solitamente il
numero 16, rintracciabile dalla PAT. Questa tabella contiene la lista degli stream
10
elementari che compongono un singolo canale o servizio come ad esempio
audio, video, sottotitoli e la PCR (Program Clock Reference), utilizzata per la
sincronizzazione.
•
Network Information Table (NIT): contiene informazioni sulla rete che sta
trasmettendo il TS come nome del network, lista dei transponder, parametri di
modulazione ecc. La sintassi adottata da questa tabella non è quella standard
MPEG-2 ma viene modificata dalle direttive DVB-SI.
•
Conditional Access Table (CAT): è presente in caso di stream criptati e fornisce
dettagli sul tipo di scrambling utilizzato, indicando altri PID dove sono
contenute ulteriori informazioni per la decodifica. Il formato di queste ultime è
però proprietario, per ovvi motivi.
Accanto al PSI, le specifiche DVB-SI definiscono ulteriori tabelle in cui sono inserite
informazioni aggiuntive riguardo ai canali ed ai servizi, consentendo, ad esempio, di
generare anche una guida elettronica dei programmi detta EPG. La differenza
sostanziale tra PSI e DVB-SI sta nel fatto che, mentre il primo contiene informazioni
riguardanti soltanto il multiplexer in cui esso è trasmesso, quest’ultimo invece può
comprendere dati di multiplex e perfino di network differenti. La struttura delle Service
Information è composta da 9 tabelle, più la Network Information Table che viene
rivisitata. Qui di seguito se ne elencano le più importanti e significative:
•
Bouquet Association Table (BAT): contiene informazioni sul bouquet, cioè un
insieme di servizi raggruppati seguendo uno schema logico.
•
Service Description Table (SDT): elenca le informazioni riguardanti i singoli
servizi trasmessi dal TS come ad esempio il nome del canale ed il fornitore.
•
Event Information Table (EIT): contiene la programmazione, in ordine
cronologico, degli eventi di ogni singolo canale. Viene indicato l’evento
corrente, il prossimo ed altri eventi programmati, tutti comprensivi di nome ora
di inizio durata ecc.
•
Running Status Table (RST): è responsabile del corretto timing degli eventi
programmati e contiene i flag che indicano se un evento è iniziato o no.
•
Time and Date Table (TDT): indica la data e l’ora corrente nel fuso orario di
riferimento.
11
Tutte queste tabelle appena descritte devono essere iniettate nel Transport Stream a
cadenza ciclica, per far si che in ricezione vengano riconosciute rapidamente ed in
qualsiasi momento. Inoltre data l’importanza di queste informazioni spesso le tabelle
vengono protette da CRC (Cyclic Redundancy Check), un metodo utile per il controllo
dell’integrità di stringhe di dati. Completato dal DVB-SI, il flusso digitale MPEG-2 TS
è pronto per la trasmissione.
1.4.4 Ricerca e decodifica di un programma
La procedura con cui viene sintonizzato un canale TV è piuttosto semplice e consiste di
pochi passi. Per prima cosa il sintonizzatore deve agganciare la frequenza del Transport
Stream. Poi si estraggono da esso tutti i pacchetti con PID uguale a zero, in modo da
ricostruire la PAT. A questo punto, a seconda di che canale si vuole sintonizzare, si va a
cercare il record della PAT contenente il riferimento PID necessario per riuscire ad
estrarre la relativa PMT. Quest’ultima, come già spiegato precedentemente, presenta
una lista di PID su cui vengono trasmessi il flusso ES audio e video. Questi PID
vengono poi filtrati in parallelo ed inizia il processo di decodifica sincronizzata. Per
completare le informazioni sui flussi, vengono anche lette tutte le altre tabelle, come la
SDT e la EIT.
1.4.5 Accesso Condizionato e Cifratura
L’Accesso Condizionato, in inglese Conditional Access (CA), è un sistema di
protezione dei contenuti che viene specificato dal DVB tramite tre documenti, DVBCA, DVB-CSA e DVB-CI, che definiscono rispettivamente l’accesso condizionato,
l’algoritmo di cifratura e l’interfaccia comune. Secondo questo sistema, l’utente, per
poter accedere al segnale televisivo che viene trasmesso in forma criptata, deve
rispondere a dei criteri prefissati. Questi ultimi sono definiti nella tabella di servizio
CAT, dove viene indicata l’associazione tra programmi ed i requisiti necessari alla loro
visione. Un sistema ad accesso condizionato si basa su una combinazione di scrambling
e crittografia; il primo si occupa del rimescolamento dei dati per renderli intellegibili
mentre il secondo gestisce lo scambio delle chiavi segrete che consentono di decriptare i
dati.
Lo standard DVB permette due tecniche distinte per la cifratura: simulcrypt e multicript.
Il primo consiste nel trasmettere i programmi criptati con differenti sistemi d’accesso
12
condizionato. In questo modo, tramite un accordo tra i fornitori, l’utente può accedere a
più servizi differenti utilizzando la stessa smart card. La seconda tecnica invece lascia
l’onere della decifratura del segnale a moduli esterni, detti Conditional Acces Module
(CAM). In questo modo però, è necessario uno slot ad interfaccia comune per ogni
sistema ad accesso condizionato che si vuole decodificare.
1.4.6 Le specifiche di livello fisico
Il DVB ha definito uno specifico standard per ognuno dei canali fisici di trasmissione,
adattandolo ogni volta alle specifiche caratteristiche del mezzo in cui il flusso digitale
viene irradiato. Per quanto riguarda il DVB-T, esso consente di trasmettere il TS con
tecnica digitale utilizzando lo stesso spettro di frequenze utilizzate dalla TV analogica
(VHF e UHF), suddiviso in canali da 6, 7 o 8 MHz. In questo modo è possibile
impiegare, per la ricezione, le normali antenne della TV analogica. A differenza del
segnale satellitare, quello terrestre viene ricevuto anche in assenza di cammino ottico tra
la stazione e il ricevitore, sfruttando la propagazione multi - cammino dovuta a
riflessioni e rifrazioni. Purtroppo, anche se da un lato questa ultima caratteristica è
vantaggiosa per l’efficienza di propagazione, dall’altro può portare ad un degrado
elevato del segnale ricevuto. Lo stesso segnale, infatti, percorrendo cammini differenti,
può giungere a destinazione in istanti successivi generando disturbo, che in questo caso
viene detto interferenza di simbolo.
Per questi motivi, dopo accurate valutazioni tecniche, è stato scelto per la modulazione,
lo schema CODFM (Coded Orthogonal Frequency Division Multiplexing), una tecnica
molto complessa ma che consente un uso efficiente della banda di trasmissione con una
elevata protezione agli errori. Con questa tecnica il flusso di trasporto, anziché essere
direttamente modulato con una singola portante, viene suddiviso in moltissime portanti
ortogonali equispaziate in frequenza. Ognuna di queste trasmette quindi un flusso con
bit rate pari ad un n-esimo del totale (se n è il numero di portanti), generando un segnale
a bassa velocità di trasmissione che consente un margine maggiore contro l’interferenza
di simbolo: gli echi del segnale appena ricevuto hanno più tempo per attenuarsi, prima
che interferiscano con il campione successivo. Il processo viene effettuato tramite una
IFFT (Inverse Fast Fourier Transform, trasformata veloce inversa di Fourier), che
consente due modalità operative: 2k caratterizzata da 1705 portanti, in caso di canale da
8 MHz, e 8k con ben 6817 portanti. Ciascuna singola portante viene poi modulata
13
utilizzando uno dei tre schemi diversi definiti dallo standard: QPSK, 16QAM o
64QAM. Nella modulazione di tipo digitale, la portante si sposta continuamente,
assumendo diverse posizioni predefinite di fase ed ampiezza chiamate simboli. Ogni
simbolo rappresenta una diversa sequenza di bit che viene trasmessa. Per descrivere la
modulazione si utilizza uno schema chiamato costellazione, nel quale vengono
rappresentate tutte le possibili configurazioni della portante tramite un diagramma
fase/ampiezza, dove la fase è data dall’angolo con l’asse delle ascisse e l’ampiezza dalla
distanza dal centro. La differenza principale, che esiste tra le tre modulazioni digitali
utilizzate, è proprio la costellazione. La QPSK (Quadrature Phase Shift Keying) è una
modulazione di fase estremamente robusta. Come si può notare in Figura 1.5, essa è
caratterizzata da quattro posizioni possibili nella costellazione e quindi possiede una
capacità di 2 bit per simbolo. Questa è la configurazione utilizzata dal DVB-S ma va
ricordato che mentre in quel caso è solo una portante ad essere modulata, nella
trasmissione terrestre sono le sottoportanti ad essere modulate in modalità QPSK. Lo
schema QAM (Quadrature amplitude modulation) utilizza invece, rispetto al
precedente, sia una modulazione di fase che di ampiezza, raggiungendo quindi un
numero più elevato di configurazioni nella costellazione e quindi un più alto bit rate
possibile. Più precisamente, come si nota in Figura 1.6, è costituita da 16 posizioni per il
16QAM con 4 bit per simbolo e 64 posizioni nell’altro caso, con 6 bit. Questo tipo di
modulazione ha però lo svantaggio di una maggiore vulnerabilità agli errori.
Figura 1.5: Costellazione di tipo QPSK
14
Figura 1.6: Costellazione di tipo 16-QAM
Per migliorare ulteriormente la resistenza del sistema contro gli echi multi cammino,
viene introdotto un intervallo di guardia temporale tra simboli successivi. Il
trasmettitore in questo spazio non produce segnale utile e il ricevitore, dopo aver
ricevuto un simbolo, attende un periodo di tempo pari all’intervallo di guardia e solo
dopo campiona il simbolo successivo. In questo lasso di tempo tutti gli echi da cammini
multipli che raggiungono il ricevitore vengono scartati e non generano quindi
interferenza. Nello standard DVB-T l’intervallo di guardia può assumere il valore di
1/4, 1/8, 1/16 ed 1/32 della durata del simbolo utile. Un valore alto consente una
maggiore robustezza al rumore di questo tipo ma di conseguenza non permette il
raggiungimento di un elevato bit rate mentre, al contrario, un valore basso fa
raggiungere un ottimo bit rate ma con un segnale molto vulnerabile.
Infine, un ulteriore livello di protezione è garantito da un potente schema di correzione
degli errori, che viene realizzato utilizzando una codifica di tipo FEC (Forward Error
Correction). Accanto al flusso di dati utili vengono aggiunti dei bit addizionali, che
consentono di rilevare se i dati sono stati ricevuti correttamente. In caso contrario, si
cerca di utilizzare questi bit anche per correggere gli errori. La quantità di errori che
possono essere corretti è limitata e dipende dal rapporto tra il numero di bit di controllo
e di dati. Nel DVB-T questo tasso può essere: 1/2, 2/3, 3/4, 5/6 e 7/8. Come al solito un
valore più elevato migliora la resistenza agli errori ma riduce drasticamente il bit rate
utile di trasmissione.
15
1.4.7 Bit rate e configurazioni tipiche
Figura 1.7: Bit rate utile (in Mbit/s) per tutte le configurazioni possibili
La configurazione più robusta possibile ai disturbi, quella in cui è richiesto un rapporto
portante/rumore (C/N) di soli 3,1 dB, è quella con modulazione QPSK, un code rate 1/2
(1 bit di protezione su 2 trasmessi) ed un intervallo di guardia di 1/4. In questo caso
però, come si vede anche in Figura 1.7, il bit rate massimo consentito è di 4,98 Mbit/s
utilizzabile soltanto per la trasmissione di un solo canale televisivo. Invece, il massimo
bit rate possibile, 31,67 Mbit/s, si ottiene con una modulazione 64QAM, FEC 7/8 ed
intervallo di guardia pari ad 1/32. Il segnale è però molto vulnerabile e richiede un
rapporto C/N di circa 26 dB per la corretta ricezione. La scelta della corretta
configurazione comunque, deve essere fatta valutando attentamente tutte le variabili e
facendo un compromesso tra capacità trasmissiva e robustezza agli errori del segnale. In
Italia per esempio si utilizza la modalità 8k con sottoportanti modulate 64QAM, un
intervallo di guardia di 1/32 ed un tasso di codifica 2/3; viene quindi trasmesso con un
bit rate di circa 24 Mbit/s che consente di trasmettere da 4 a 6 canali televisivi in qualità
normale.
1.4.8 La trasmissione gerarchica
Il DVB-T consente anche una tecnica di trasmissione detta gerarchica. Lo scopo di
questa tecnica è quello di trasmettere contemporaneamente, utilizzando lo stesso
trasmettitore e lo stesso canale, due Transport Stream con programmi differenti. Il
primo TS è detto ad alta priorità ed è caratterizzato da un bit rate basso ed una
robustezza elevata, anche in condizioni di segnale disturbato. Il secondo è invece detto a
16
Capitolo 1: Lo
L standard DVB
baassa prioritàà e, al contrrario del priimo, ha un alto bit ratee ma è ricevvibile solo in
i ottime
coondizioni. Un
U esempioo è quello di trasmetttere contem
mporaneam
mente un seegnale a
deefinizione video
v
standaard ed uno in
i alta defin
nizione, in modo
m
che siia possibile ricevere
coomunque laa trasmissioone, anche con
c scarsa copertura. La trasmisssione geraarchica è
baasata sulla tecnica di
d modulazzione 16QA
AM o 64Q
QAM. Nell diagramm
ma della
coostellazionee, il flusso primario
p
deffinisce il qu
uadrante deel simbolo, ccome se si trattasse
dii una moduulazione QP
PSK, con tuutti i vantag
ggi che ne derivano,
d
m
mentre il seccondario
deefinisce la posizione
p
essatta del sim
mbolo all’in
nterno del quuadrante inddicato dal primario.
p
Peer facilitare ulteriormennte la decoddifica del seegnale ad alta priorità ssi possono utilizzare
u
deelle costellaazioni non uniformi.
u
Inn pratica i siimboli venggono distanzziati dagli assi
a della
coostellazionee in modo più
p o menoo accentuato
o a secondaa del gradoo di uniform
mità, che
viiene indicatto con la lettera α e puuò assumeree i valori 1, 2 e 4. Talle pratica va
v però a
diiscapito del flusso secoondario che necessiterà sempre di più
p di un seegnale ottim
mo.
1..4.9 Schem
ma del sisteema di trassmissione
Figura 1.8: Diagram
mma a blocchii del sistema di trasmissioone
Laa proceduraa di trasmisssione dellaa televisionee digitale teerrestre inizzia dalla codifica di
soorgente MPE
EG-2. I varri flussi, viddeo, audio e di dati, venngono codifficati separaatamente
peer poi conflluire in un multiplexerr MPEG, ch
he produce in uscita ill Transport Stream.
N caso si vogliano
Nel
v
traasmettere duue flussi con
ntemporaneeamente, il TS passa atttraverso
unn divisore (vedi Paraggrafo 1.4.8)). Nel blocco successiivo, il flusso viene sccorrelato
uttilizzando una
u tecnica di dispersioone di energ
gia. In seguuito, i bloccchi definiti in
i figura
17
con il nome di external encoder ed external interleaver forniscono una prima protezione
agli errori grazie ad una codifica Reed-Solomon RS (204, 188, t = 8) ed a una tecnica di
interleaving di tipo convoluzionale. L’output di quest’ultimo passa al blocco
codificatore interno che fornisce un’ulteriore protezione dei dati grazie alla tecnica FEC,
già descritta in precedenza. A questo punto i flussi della trasmissione gerarchica
confluiscono nell’interleaver interno, dove subiscono un ulteriore processo di
riadattamento contro errori di tipo burst. Il flusso di bit risultanti viene poi mappato in
banda base, con una delle tre tecniche di modulazione possibile e i simboli risultanti da
questo processo vengono raggruppati in blocchi di lunghezza costante. Questi, vengono
ulteriormente raccolti in gruppi da 64 andando a formare un frame. A questi vengono
anche aggiunti dei segnali pilota e informazioni aggiuntive per semplificare la ricezione,
poi si esegue la modulazione con la tecnica COFDM. Soltanto dopo questo passaggio, si
inserisce l’intervallo di guardia. Infine il segnale viene trasformato in analogico e
modulato a frequenze radio VHF o UHF.
1.5 Il DVB-T in Italia
Attualmente l’Italia sta affrontando la fase di transizione dalla televisione analogica
tradizionale a quella digitale terrestre, dello standard DVB-T, per adeguarsi alle norme
comunitarie che impongono, per tutti i paesi membri, questo tipo di passaggio. Questa
fase è iniziata in via sperimentale a Torino, nel 2001 ma il lancio ufficiale avviene nel
2003, con la legge Gasparri del riordino del Sistema Televisivo Italiano. In quella data
era stato anche deciso che il termine ultimo per la conversione da analogico a digitale, il
cosiddetto switch-off, doveva essere il 31 Dicembre 2006. Questa scadenza si è rivelata
però poco realistica ed è quindi stata posticipata, prima al 2008 e poi al 2012. Soltanto
per la Sardegna e la Valle d’Aosta il termine è rimasto quello del 2008, a Marzo per la
prima regione e ad Ottobre per la seconda. Tuttavia, anche se queste date sono ormai
relativamente vicine, la diffusione del digitale terrestre in Italia non è ancora sufficiente
per sopportare lo switch-off. Molte zone, infatti, soprattutto quelle alpine e
appenniniche, non sono ancora coperte dal segnale DVB-T. Inoltre, nelle zone coperte,
non tutti hanno provveduto all’acquisto del set-top box o dispositivi analoghi, quindi
anche essi non sono in grado di sfruttare questa nuova tecnologia. La mancata
diffusione deriva probabilmente proprio dalla riluttanza delle persone ad acquistare un
18
nuovo dispositivo che, all’atto pratico, non fornisce la sensazione di un valore aggiunto.
Per agevolare l’acquisto dei STB (Set-Top Box) nel 2004 erano stati anche stanziati
degli incentivi ma recentemente questi sono stati sanzionati perché non rispettavano le
leggi sulla concorrenza.
Figura 1.9: Area di copertura della rete Dfree
Ciò che probabilmente invece riuscirà a diffondere la TV digitale, oltre alla data di
switch-off, sono tutti quei servizi aggiuntivi che stanno recentemente prendendo parte al
panorama televisivo nazionale. Questi servizi sono ad esempio la pay-per-view per le
partite di calcio e le applicazioni interattive dello standard MHP che permettono
all’utente di interagire tramite il canale di ritorno.
1.6 MHP: lo standard per la TV interattiva
Il DVB-MHP (Digital Video Broadcasting - Multimedia Home Platform), detto anche
più brevemente MHP, è una piattaforma software completa che permette di poter
19
usufruire di servizi ed applicazioni per la TV interattiva. In termini tecnici l’MHP è uno
strato software, situato al di sopra del sistema operativo, che fornisce un’interfaccia tra
l’applicazione da eseguire e l’hardware della macchina su cui è situato. Un software di
questo tipo viene più propriamente detto Middleware. Questo standard è abbastanza
recente, creato dal DVB Project e ratificato dall’ETSI nel Maggio del 2000 con il
documento intitolato “ES 201 812”. Lo scopo del progetto è stato fin dal principio
quello di creare uno standard aperto con cui poter accedere a tutte le applicazioni scritte
da qualsiasi produttore di software e fornite da qualsiasi broadcaster al mondo senza
problemi di compatibilità. Nei primi anni di diffusione della TV digitale, infatti, alcune
aziende avevano sviluppato alcuni applicativi per la TV interattiva ma questi si
basavano su una tecnologia proprietaria. Quindi, per poterne usufruire, era necessario
possedere un dispositivo hardware sviluppato con quella stessa tecnologia, che spesso
veniva fornito dallo stesso broadcaster che offriva i servizi. Con gli anni, soprattutto
nell’ambito della TV satellitare, erano state prodotte varie piattaforme proprietarie,
quasi tutte incompatibili tra loro; era quindi giunto il momento di sviluppare un’unica
architettura completa che funzionasse con tutti gli standard televisivi digitali e con tutti i
dispositivi di ricezione.
1.6.1 Architettura
L’architettura di base dell’MHP è costituita da tre livelli:
•
Resources: rappresenta le risorse hardware e software del ricevitore (Set-top
box). Queste vengono fornite, dall’MHP, in maniera trasparente alle
applicazioni.
•
System software: il software di sistema fornisce alle applicazioni una visione
astratta delle risorse. In questa maniera, separando l’applicazione dall’hardware,
si garantisce la portabilità dell’applicazione stessa. Questo livello comprende un
Application manager, chiamato anche navigatore, che è responsabile della
gestione di tutte le applicazioni. Di questo strato fa parte anche la JVM 1.1
(Java Virtual Machine) nella versione Personal Java che serve per eseguire le
applicazioni e rappresenta quindi il nucleo dell’MHP. Infine fanno parte del
System software, le API definite dallo standard ed il protocollo di trasporto.
•
Applications: le applicazioni sono tutti quei software che implementano i servizi
interattivi come ad esempio la guida ai programmi EPG, giochi ed altri servizi.
20
1.6.2 I profili
Per semplificare l’implementazione dello standard MHP è stato introdotto il concetto di
profilo. Ognuno di questi è riferito ad una certa area di applicazioni e ad uno specifico
tipo di hardware necessario a farle funzionare. Attualmente i profili specificati finora
sono tre, raccolti in due diverse versioni dello standard, la prima chiamata MHP 1.0 e la
seconda MHP 1.1:
•
Enhanced Broadcast Profile: definito nell’MHP 1.0, è il profilo di base che
permette soltanto l’interazione con informazioni ed immagini, senza il canale di
ritorno. Esso è stato creato per mantenere la compatibilità con i sistemi esistenti
e non richiede particolari prestazioni hardware.
•
Interactive TV Profile: definito sempre nell’MHP 1.0, è il profilo intermedio che
consente l’esecuzione di servizi con interattività superiore rispetto al precedente.
In questo caso, infatti, è previsto l’utilizzo del canale di ritorno (rete PSTN,
ISDN, ADL ecc.), che può essere utilizzato anche per caricare le applicazioni.
Nel precedente invece si potevano utilizzare soltanto applicazioni provenienti
dal canale di broadcast. Questo profilo necessita di caratteristiche prestazionali
superiori.
•
Internet Access Profile: definito questa volta nell’MHP 1.1, è il profilo più
elevato e contiene i due definiti precedentemente. Esso contiene un componente
aggiuntivo, chiamato DVB-HTML, che consente un’interattività totale
permettendo l’accesso ai contenuti internet. Questo profilo necessità però di un
hardware che consenta prestazioni di alto livello, in grado di poter eseguire un
browser web.
1.6.3 Il protocollo di trasporto
Una rete broadcast è per sua natura monodirezionale. Questo significa che il server, in
questo caso interpretato dal trasmettitore, decide i dati da inviare ed il client,
rappresentato dal ricevitore, non può ne rispondere ne effettuare richieste. In questa
situazione un client di una rete broadcast non potrà mai accedere ad uno specifico file
del server, come invece avviene in una rete tra computer. Per ovviare a questo problema
si utilizza una tecnica simile a quella adottata per la trasmissione del teletext. In pratica
il server trasmette ciclicamente tutti i file del suo file system ed il ricevitore deve
21
attendere i file a cui è interessato. Questo tipo di soluzione viene comunemente
chiamato carosello.
Il protocollo utilizzato per inviare il carosello è il DSM-CC (Digital Storage Media Command and Control), uno standard per la trasmissione di dati basato sullo stream
MPEG. Questo protocollo era nato per il collegamento tra VTR (Video Tape Recorder),
ma si è successivamente sviluppato fino a supportare il controllo in rete dei server video
e la trasmissione dei dati. Il DSM-CC supporta due tipi di carosello: data carousel e
object carousel. Il data carousel è il più semplice tra i due, ma è anche quello che offre
minori servizi. I dati vengono divisi in moduli e poi trasmessi a rotazione senza nessuna
informazione aggiuntiva sul contenuto di quello che viene inviato. Per applicazioni più
complesse, come quelle MHP, questo non è sufficiente perciò viene adottato l’object
carousel. Questo protocollo si pone al di sopra del data carousel, fornendo funzionalità
analoghe a quelle di un file system tradizionale. In pratica il carosello è costituito da un
albero di directory suddiviso in vari moduli, dove ognuno di questi può contenere più
file o directory. La dimensione totale di ogni modulo non può superare i 64 kb ed inoltre
non è permesso suddividere un file in più moduli diversi. Questo implica che un file da
trasmettere non può essere più grande di quella dimensione. Tutti questi moduli,
disposti uno dopo l’altro, vanno poi a formare il carosello. Il ricevitore, per poter
accedere ad un singolo file deve attendere la trasmissione di tutto il flusso di dati fino al
modulo contenente il file desiderato.
Questo metodo di trasmissione, con l’aumentare della mole di dati da trasmettere,
diventa alquanto svantaggioso poiché il tempo di attesa può essere elevato ed inoltre
non è prevedibile. La ricezione, infatti, può essere quasi immediata se al momento della
richiesta viene trasmesso il modulo precedente a quello necessario, ma molto lunga se,
al contrario, il modulo ricercato è stato appena trasmesso. Per velocizzare le operazioni
di scaricamento, spesso i ricevitori memorizzano nella cache parte dei dati necessari.
Inoltre, a volte, i moduli più importanti vengono ripetuti più volte all’interno del singolo
carosello, cosicché il loro accesso sia più veloce.
22
Capitolo 2: LinuxTV
Figura 2.1: Logo del LinuxTV project
2.1 Introduzione
Il progetto LinuxTV è costituito da un gruppo informale di volontari che sviluppano
software per la televisione digitale compatibile con il sistema operativo Linux. Questa
comunità, reperibile al sito internet http://www.linuxtv.org, sviluppa e mantiene tutto il
sottosistema dei driver del DVB che è contenuto attualmente nella versione 2.6.x del
kernel di Linux. I dispositivi supportati da LinuxTV, non sono però solo quelli per la
televisione digitale terrestre, ma sono compresi anche i sistemi per il satellitare, per la tv
via cavo e perfino i moduli per l’accesso condizionato, in modo da poter usufruire anche
dei contenuti protetti. I driver disponibili, al momento, sono compatibili con un notevole
numero di periferiche DVB per PC, del tipo PCI, PCI Express, PCMCA ed USB. Essi
sono però in costante sviluppo, in modo da migliorare sempre di più l’efficienza e il
supporto per le schede TV di nuova fattura che vengono messe sul mercato dai maggiori
produttori di elettronica di tipo consumer. Dato che praticamente, quasi la totalità delle
imprese operanti sul mercato, fornisce, incluso nel pacchetto di acquisto dell’hardware,
soltanto software compatibile con sistemi operativi proprietari, è soltanto grazie a
questa comunità che è possibile l’utilizzo della Tv digitale in sistemi open source come
Linux.
2.2 Storia del progetto
Il progetto LinuxTV è nato a Berlino, nel 1998, fondato dall’azienda tedesca
Convergence Integrated Media GmbH. Inizialmente esso aveva lo scopo di distribuire
software open source gratuito per la produzione, la fornitura e la ricezione della
televisione digitale. Secondo i membri dell’azienda, infatti, soltanto l’accesso al codice
sorgente della televisione futura poteva garantire l’indipendenza dei contenuti e della
23
Capitolo 2: LinuxTV
tecnologia. Nel 2002, dopo alcuni problemi finanziari la società venne acquisita dalla
Galaxis AG, un’azienda tedesca produttrice di set-top box, e cambiò nome in Galaxis
GmbH. Infine, nel 2005, sia la Convergence che la Galaxis AG dichiararono bancarotta
ed abbandonarono il progetto. Da questo momento in poi il LinuxTV project vive
indipendentemente, supportato solamente da una vasta comunità di sviluppatori che si
era riunita nel corso degli anni attorno al progetto.
2.3 Le Linux DVB API
Il codice dei driver sviluppati da LinuxTV si appoggia a delle API, acronimo di
Application Program Interface. Una API è un insieme di routine, disponibili al
programmatore, in modo che esso non debba ogni volta scrivere codice dal nulla, ma si
possa appoggiare a procedure ben definite. Di per se una API è una astrazione che
permette di creare una interfaccia tra hardware e codice sorgente o tra software di alto e
basso livello. In questo caso le API a cui si appoggia il sorgente di questi driver sono
chiamate Linux DVB API ed attualmente sono disponibili nella versione 3. È però in
sviluppo una quarta versione anche se, al momento, il progetto è quasi completo, ma
non è più attivo. Le Linux DVB API, insieme ai driver e ad altre applicazioni utili, sono
sempre mantenute e supportate dal LinuxTV project.
La prima API scritta per una scheda DVB fu utilizzata dalla Convergence, alla fine del
1999, per pilotare una scheda PCI. A quel tempo quella era soltanto una estensione del
codice Video4Linux, delle API utilizzate per il supporto delle schede di acquisizione
video e dispositivi analoghi. Esse quindi non erano molto adatte all’utilizzo con le
schede DVB poiché non veniva supportato ad esempio, il filtraggio contemporaneo dei
vari flussi, MPEG e dati. Successivamente, nel 2000, la Nokia si interessò al progetto di
queste API, con il fine di sviluppare dei terminali basati su questo standard aperto.
Nello stesso anno venne sviluppata da C. Theiss e dai fratelli Metzler, per conto della
Convergence, la prima versione del codice. Questa fu resa subito disponibile, pubblicata
attraverso il sito attuale del progetto, a tutti gli sviluppatori di Linux. La prima
implementazione delle Linux DVB API fu invece realizzata attraverso la creazione dei
driver per la scheda DVB PCI Siemens/Hauppauge. Dopo un lavoro di sviluppo di un
anno si arrivò finalmente alla terza versione che fu inclusa per la prima volta nel kernel
ufficiale di Linux, a partire dal numero 2.5.44 del 2002. Nel frattempo vennero anche
24
Capitolo 2: LinuxTV
aggiunti, ai repository di LinuxTV, molti nuovi driver, creati da sviluppatori di codice
di tutto il mondo, in modo da supportare un numero sempre più elevato di schede DVB.
2.3.1 La struttura delle API
Le Linux DVB API sono strutturate attraverso un certo numero di parti diverse,
seguendo lo schema generale dei componenti di una scheda DVB (di questo se ne
discuterà successivamente, al Paragrafo 3.3). Ogni sezione contiene le procedure
riguardanti ognuno dei tipi di dispositivi che è possibile incontrare in una scheda, come
ad esempio il frontend, il decodificatore ecc. Per ogni dispositivo inoltre vengono
elencati i tipi di dati e le procedure dettagliate, complete di parametri, delle chiamate di
funzioni. La struttura generale delle API è quella indicata in Figura 2.2.
Figura 2.2: Struttura delle Linux DVB API
2.3.2 Il riconoscimento dei dispositivi DVB
Nel sistema operativo Linux, ogni dispositivo hardware di Input/Output collegato viene
visto come un file. Così facendo si può trattare ogni operazione di input/output come
una richiesta di lettura o scrittura da file. Questi file speciali sono generalmente
contenuti nel file system all’interno della directory /dev.
Nelle prime API, quelle sviluppate dalla Nokia, i dispositivi DVB venivano collocati
nella directory /dev/ost/, dove OST sta per Open Standards Terminal, e non venivano
numerati. Ci si accorse però che in quel caso si garantiva il supporto per soltanto una
scheda. Inoltre, con l’avanzare della tecnologia, i nuovi dispositivi hardware erano in
grado di contenere, in un solo chip, più componenti, quindi era necessario che ognuno
di essi fosse riconosciuto singolarmente. Per esaudire queste richieste si cambiò tecnica
25
Capitolo 2: LinuxTV
ed ora i dispositivi sono accessibili attraverso un insieme strutturato di directory simile
alla seguente:
•
/dev/dvb/adapterX/frontendY
•
/dev/dvb/adapterX/demuxY
•
/dev/dvb/adapterX/videoY
•
/dev/dvb/adapterX/audioY
•
/dev/dvb/adapterX/caY
•
ecc.
In questa struttura, le lettere X e Y rappresentano rispettivamente la numerazione,
partendo sempre da zero, delle schede installate nel sistema e dei dispositivi per ogni
tipo della stessa scheda. Attualmente in commercio è disponibile una enorme varietà di
schede per il DVB, ognuna con caratteristiche e con chip hardware diversi. Questo per
dire che nel file system di Linux appariranno, per ogni adapter, soltanto i file
corrispondenti ad un dispositivo presente nella scheda e verranno omessi tutti gli altri.
Ad esempio, se non è presente il modulo per l’accesso condizionato, non esisterà il file
caY, oppure, se la scheda non ha il decodificatore MPEG, non appariranno i file videoY
e audioY.
2.3.3 Frontend API
Vengono supportati attualmente tre tipi di frontend: DVB-S, DVB-C e DVB-T. Tra i
tipi di dati e le strutture che vengono definite sono presenti numerose informazioni che
caratterizzano il dispositivo, alcune di esse sono comuni altre variano da dispositivo in
dispositivo e non sono supportate da tutti. Le più significative sono:
•
il tipo di frontend, che viene indicato, per ragioni storiche, attraverso il tipo di
modulazione, cioè FE_QPSK per il satellite, FE_QAM per il cavo e FE_ODFM
per il terrestre;
•
le potenzialità del dispositivo, che descrive quello che il sistema supporta, come
ad esempio il tipo di modulazione. In questo caso le capacità differiscono molto
a seconda del metodo di trasmissione adottato;
•
le informazioni del SEC, sono presenti soltanto nelle schede satellitari, vengono
utilizzate per gestire il dispositivo situato nella parabola chiamato LNB;
26
Capitolo 2: LinuxTV
•
lo stato del frontend, utile per gestire al meglio la scheda. Questo dato è quello
che viene letto da tutte le utility di gestione del DVB. I valori che possono essere
assunti, ed i relativi codici in esadecimale sono: FE_HAS_SIGNAL (0x01), se
viene trovato un segnale che supera la soglia del rumore, FE_HAS_CARRIER
(0x02),
se
viene
riconosciuto
un
segnale
dello
standard
DVB,
FE_HAS_VITERBI (0x04) se il FEC è stabile, FE_HAS_SYNC (0x08) se
vengono trovati i byte di sincronizzazione, FE_HAS_LOCK (0x10), se tutto
funziona correttamente e il segnale è sintonizzato, FE_TIMEOUT (0x20), se il
dispositivo non assume lo stato di lock in un numero di secondi prefissato, e
FE_REINIT (0x40), se il frontend viene re inizializzato;
•
i parametri di modulazione, diversi a seconda del tipo di hardware. Per la tecnica
CODFM i valori dei parametri sono divisi per tecnica di trasmissione, larghezza
di banda, tipo di costellazione tasso di codifica FEC (sia in alta che in bassa
priorità), intervallo di guardia e tipo di gerarchia (vedi Paragrafo 1.4.6).
Le chiamate di funzioni sono per la maggior parte delle richieste di informazioni sullo
stato del frontend, più le procedure per la sintonizzazione. Le funzioni indicate in
carattere minuscolo sono delle chiamate di sistema standard di Linux. Invece, le
funzioni indicate tutto in maiuscolo rappresentano il parametro che viene assegnato
utilizzando la funzione di Linux ioctl. Dato che nel sistema operativo Linux tutti i
dispositivi vengono individuati tramite un file specifico, non è sempre possibile riuscire
a gestirli tramite le funzioni usate per i file normali; per questo motivo è stata prevista
dal sistema l’esistenza di una funzione apposita, la ioctl, con cui poter eseguire le
operazioni specifiche di ogni particolare dispositivo. Tale funzione prende come
parametro il file descriptor, ottenuto di solito all’atto dell’apertura del dispositivo, e il
parametro request, cioè i vari parametri che vengono in seguito definiti con il carattere
maiuscolo. Le chiamate principali sono:
•
open(): con questa system call si apre il dispositivo, indicandone il nome
attraverso il percorso (es. /dev/dvb/adapter0/frontend0). Un frontend può essere
attivato in due modalità diverse: in sola lettura, che permette solo attività di
monitoraggio e statistiche, oppure in lettura/scrittura, che consente ogni tipo di
operazione. In sistemi con più di un frontend installato, generalmente, non è
possibile aprire contemporaneamente due dispositivi in scrittura. Questa
27
Capitolo 2: LinuxTV
chiamata ritorna il valore del file descriptor, parametro che verrà in seguito
utilizzato per gestire tutte le altre chiamate;
•
close(): con questa chiamata si chiude un dispositivo precedentemente aperto.
All’atto della chiusura è previsto anche lo spegnimento automatico
dell’hardware;
•
FE_READ_STATUS: con questa si ottengono le informazioni sullo stato del
dispositivo. I dati che si ricevono in seguito a questa chiamata sono quelli
descritti precedentemente;
•
FE_READ_BER,
FE_READ_SNR,
FE_READ_SIGNAL_STRENGTH
e
FE_READ_UNCORRECTED_BLOCKS: queste chiamate ritornano varie
informazioni riguardo al segnale appena ricevuto, come il tasso di errore, il
rapporto segnale/rumore, la forza del segnale e il numero di blocchi non corretti.
Queste funzioni, come anche la precedente, possono essere eseguite in modalità
di sola lettura;
•
FE_SET_FRONTEND: con questa chiamata si iniziano le operazioni di
sintonizzazione del frontend. Per farlo, si inviano con la chiamata tutti i
parametri di modulazione definiti precedentemente. Se questi ultimi sono validi,
la funzione avrà successo ed inizierà la procedura di tuning. Questa operazione
può essere effettuata solo in modalità scrittura ed è asincrona, cioè se viene
iniziata una nuova operazione di sintonizzazione, la precedente viene abortita.
Questa sezione delle Linux DVB API è quella fondamentale per il corretto
funzionamento della scheda. Il frontend, infatti, è l’unico componente che non può mai
mancare in una scheda TV digitale. Tutti gli altri dispositivi invece possono anche
essere emulati via software dalla CPU.
2.3.4 Dispositivi di demux
Il dispositivo di demultiplex è quello che controlla il filtraggio, dal Transport Stream,
dei vari flussi elementari. A questo componente può anche essere associato un
dispositivo logico, chiamato dvrY, e contrassegnato con lo stesso numero del file
demuxY. Il dvr viene utilizzato per la ricezione del flusso di trasporto che verrà poi
registrato digitalmente.
Tra i vari tipi di dati che vengono dichiarati, riguardo questa parte delle API, viene
definito l’output del dispositivo e il tipo di PES (Packetized Elementary Stream, v.
28
Capitolo 2: LinuxTV
Paragrafo 1.4.2). Il primo consente di ridirigere l’output verso tre differenti direzioni,
verso il decoder MPEG (DMX_OUT_DECODER), verso il dispositivo logico DVR
(DMX_OUT_TS_TAP) oppure verso una direzione qualunque, che viene definita dalla
chiamata ioctl (DMX_OUT_TAP). I tipi di PES invece possono essere tutti quelli visti
finora, cioè video, audio, sottotitoli ecc. Per quanto riguarda le chiamate di sistema,
oltre alle classiche open() e close(), che sostanzialmente hanno la stessa funzione di
quelle definite precedentemente, ne sono definite alcune più specifiche per leggere i dati
e pilotare il filtro dei pacchetti. Ad esempio, per iniziare le operazioni di filtraggio si
utilizza
la
chiamata
DMX_START,
che
viene
seguita
dalle
chiamate
DMX_SET_FILTER e DMX_SET_PES_FILTER. Queste impostano il filtro tramite
vari parametri come il PID e il tempo di timeout per la prima, mentre per la seconda
deve essere indicato anche il tipo di PES e la direzione dell’output.
2.3.5 Decoder video ed audio
Le API per i dispositivi video ed audio controllano il decodificatore MPEG-2 presente
nella scheda TV. Se quest’ultimo non è presente i file videoY e audioY non
compariranno nell’albero del file system. Questa sezione controlla soltanto la decodifica
MPEG del flusso, mentre non si interessa affatto di come viene gestita la
visualizzazione in uno schermo televisivo o in un monitor. In un PC, di solito, questo
compito è infatti affidato ad altri dispositivi, che lavorano con le API di video4linux.
Per quanto riguarda il video, le informazioni necessarie per la codifica che vengono
definite sono tutti quei parametri standard di un filmato, come l’aspect ratio (4:3 o
16:9), il formato di visualizzazione (Pan scan, letterbox ecc.), il sistema video dello
schermo (PAL o NTSC) ed altri parametri che indicano lo stato del video e che
gestiscono la riproduzione dei filmati. Anche per quanto riguarda l’audio vengono
forniti dei parametri caratteristici del flusso audio, come ad esempio il numero di canali
(mono o stereo) ed il volume. Il decoder può processare separatamente i flussi audio e
video provenienti dal dispositivo di demux oppure può anche ricevere i dati da
applicazioni software, tramite la chiamata write(). Sia il decoder audio che quello video
possono supportare vari formati, a seconda dell’hardware inserito nella scheda; oltre
all’MPEG-2, infatti, può essere decodificato anche l’MPEG-1 o l’H264 per il video
mentre per l’audio oltre all’MPEG Layer II anche il DTS, l’AAC o l’AC3.
29
Capitolo 2: LinuxTV
2.3.6 Dispositivi per l’accesso condizionato
Una sezione delle API è destinata al controllo dell’hardware per la gestione dell’accesso
condizionato. In realtà però questa parte delle API non è molto sviluppata poiché le
uniche operazioni definite sono quelle di apertura e di chiusura del dispositivo. Oltre a
queste chiamate esistono poi dei parametri che descrivono il tipo di dispositivo,
l’interfaccia e l’algoritmo di descrambling. Queste però hanno soltanto una funzione
informativa e non operativa.
2.3.7 La quarta versione delle API
Nel 2003, la Convergence e la Toshiba Electronic Europe iniziarono lo sviluppo della
quarta versione delle Linux DVB API. La terza versione, infatti, presentava alcuni
problemi e, anche se era molto diffusa tra le applicazioni e conosciuta dai
programmatori, era inevitabile che ne venisse creata un’altra per risolvere i bug
principali. Il principale svantaggio della terza versione delle API riguarda il fatto che
tutti i trasferimenti di dati avvengono attraverso i buffer della memoria e non esiste
nessun supporto per il DMA (Direct Memory Access) che, tramite l’accesso diretto alla
memoria, ridurrebbe di molto il carico della CPU. Inoltre, molti degli hardware moderni
non vengono gestiti correttamente poiché non è definito un supporto esplicito per
frontend o decodificatori multipli. Infine, dato che la prima API era basata sulla scheda
PCI della Siemens, sono rimaste alcune inconsistenze nei namespace ed alcuni errori di
programmazione. Per risolvere questo tipo di problemi, non era sufficiente creare una
estensione delle API esistenti ma era necessario crearne altre completamente da capo.
Queste ultime però dovevano mantenere pressoché inalterate le caratteristiche principali
in modo che venisse garantita la portabilità. Al giorno d’oggi il progetto non è più
attivo, non è stato scartato ma è rimasto in una sorta di stand-by.
2.4 Le Video4Linux API
Le API Video4Linux sono state create inizialmente per l’utilizzo con i dispositivi di
video cattura. In seguito, nel 2002, è stata rilasciata una seconda versione (v4l2) per
ampliare le capacità della precedente e correggere i bug. Da quel momento le
Video4Linux API sono entrate a far parte stabilmente del kernel di Linux.
Queste API hanno la funzione di creare una interfaccia tra il kernel e i dispositivi video.
La loro struttura deve essere ben nota a qualsiasi programmatore di driver ed
30
Capitolo 2: LinuxTV
applicazioni per il sistema operativo Linux. Le Video4Linux API infatti supportano una
notevole varietà di dispositivi che non sono necessariamente di tipo video. Tra questi
possiamo trovare:
•
video capture interface: sono i comuni dispositivi di video cattura, comprese ad
esempio le schede per la TV, sia analogiche che digitali. Le schede di tipo DVB,
come è stato detto precedentemente, vengono governate dalle DVB API, ma
queste controllano soltanto i dispositivi specifici che solo una scheda DVB
possiede. La parte che riguarda invece l’interfacciamento, ad esempio, tra la
scheda ed il bus PCI, è gestita dalle API Video4Linux;
•
video output interface: rappresentano tutti i dispositivi in grado di codificare
sequenze di immagini in un segnale video analogico;
•
video overlay interface: sono quei dispositivi che consentono la visualizzazione
diretta di ciò che viene acquisito dalle periferiche di video cattura. In pratica i
dati vengono spostati dal dispositivo di acquisizione a quello di output, ad
esempio una scheda video, senza gravare sulla CPU;
•
radio interface: rappresentano i ricevitori della radio analogica, AM e FM.
I dispositivi appena indicati, tranne quelli radio, vengono individuati dai file speciali
chiamati /dev/videoX, dove la X rappresenta il solito numero progressivo che parte da 0.
I dispositivi radiofonici invece vengono indicati dal file /dev/radioX.
2.5 Utilities per il DVB
Il pacchetto LinuxTV dvb-apps contiene una serie di applicazioni utili per il setup
iniziale e per il monitoraggio di una scheda TV. Riguardo questo pacchetto, c’è stato nel
tempo un po’ di confusione, poiché mentre il pacchetto del codice sorgente, scaricabile
dal sito della comunità, viene chiamato linuxtv-dvb-apps, non tutte le distribuzioni di
Linux si riferiscono a questo con lo stesso nome. Ad esempio, nelle distribuzioni
Debian e derivate, quindi anche su Ubuntu, il pacchetto viene rinominato dvb-utils,
mentre in altri sistemi si fa ancora più confusione poiché viene chiamato dvbtools,
confondendolo con un altro insieme di applicazioni, esterne al LinuxTV Project.
Le utilities vengono suddivise in due gruppi principali, a cui corrispondono le due
directory /test e /util. I programmi contenuti nella prima directory servono, come dice
anche il nome, per testare il dispositivo. Di questi, alcuni sono relativi soltanto alle
31
Capitolo 2: LinuxTV
schede satellitari poiché lavorano soltanto con il dispositivo SEC del frontend. Gli altri
invece sono piccole applicazioni generali che testano il demultiplexer ed il decoder
audio e video. Nella seconda directory invece, sono contenute delle applicazioni
fondamentali per far funzionare la scheda DVB dopo l’installazione. L’elenco completo
delle applicazioni è questo:
•
loadkeys: una utility per definire la mappatura del telecomando a infrarossi, se
presente;
•
dvbdate: un programma per settare la data e l’ora di sistema che viene letta dalla
scheda Digitale Terrestre;
•
dvbnet: uno script che gestisce il dispositivo /dev/dvb/adapter0/net0;
•
dvbtraffic: un programma che analizza il traffico della scheda DVB;
•
scan: una utility per effettuare la scansione dei canali;
•
zap: un’applicazione che testa il segnale DVB.
Questi programmi sono stati tutti scritti da sviluppatori del progetto LinuxTV, nel
linguaggio di programmazione C. Tra tutte queste applicazioni, quelle fondamentali
sono le ultime due, che vengono trattate dettagliatamente nei prossimi due paragrafi.
2.5.1 Scan
Il programma scan è una utility, eseguibile da linea di comando, che effettua la
scansione dei canali. Questa applicazione però non effettua una scansione automatica
dei canali che possono essere ricevuti, come avviene ad esempio quando si vuole
sintonizzare un set-top box per la TV digitale terrestre oppure un comune televisore.
Esso necessita invece di un file delle frequenze di base contenente la lista dei MUX
disponibili. Come descritto precedentemente, lo standard del digitale terrestre consente
di combinare, tramite un multiplexer, più flussi audio e video derivati da canali
televisivi diversi, in un flusso di trasporto (TS).Questo viene poi trasmesso utilizzando
una sola banda di frequenze di 8 MHz. Ogni multiplex (MUX) che viene diffuso da una
stazione quindi, contiene una serie di canali, sia televisivi che radiofonici, e differisce
da tutti gli altri soltanto per la frequenza. Per questo motivo, il file necessario alla
corretta riuscita del comando è formato da una serie di righe con alcuni parametri in
comune. Il formato è il seguente:
T “frequenza in Hz” 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
32
Capitolo 2: LinuxTV
Gli attributi che seguono il valore della frequenza riguardano i parametri di
modulazione e servono per settare correttamente il frontend della scheda. Inoltre il
programma supporta anche delle righe di commento, individuabili dal fatto che
presentano ad inizio riga il carattere “#”. I commenti servono solo per creare un file più
comprensibile per un essere umano, mentre vengono ignorati dall’applicazione. Essi
possono essere utili ad esempio per indicare quali canali contiene ogni MUX.
Il programma si basa completamente sulle Linux DVB API, utilizzando tutte le strutture
e le chiamate definite nella parte che riguarda il frontend e in particolare la funzione
FE_SET_FRONTEND, che serve proprio per la sintonizzazione. Lo scan inizia
leggendo riga per riga il file delle frequenze iniziali e utilizzando quelle informazioni
imposta il frontend. Se viene individuato un segnale buono, cioè se viene ritornato il
valore FE_HAS_LOCK dopo la chiamata ioctl del tipo FE_READ_STATUS, il
programma inizia a filtrare e a decodificare le tabelle di servizio del DVB-SI, ottenendo
così un elenco di programmi televisivi. Ciò che si ottiene alla fine della scansione è un
file chiamato channels.conf. Questo file contiene l’elenco di tutti i canali disponibili
nell’area di ricezione dell’antenna, comprensivi di tutte le informazioni utili per la
successiva visualizzazione, come ad esempio il valore del PID del flusso audio e video.
Il formato di questo file è molto semplice: ogni riga contiene i parametri di un solo
canale ed inizia proprio con il nome del canale. Ogni successiva informazione è
separata dalle altre tramite il carattere “:”, creando così una specie di tabella. Dopo il
nome viene indicato, in ordine, la frequenza del MUX, il modo di inversione, la banda
occupata, il tasso del FEC in alta e bassa priorità, la costellazione, il modo di
trasmissione, l’intervallo di guardia, le informazioni sulla gerarchia, il PID video e
audio ed infine l’ID di servizio del canale. Tra tutte queste informazioni, di solito,
quelle che variano di canale in canale sono soltanto la frequenza, i valori dei PID dei
flussi e l’identificativo di servizio. Il file channels.conf, nel formato appena descritto,
viene riconosciuto dalla maggior parte delle applicazioni che funzionano sotto il sistema
operativo Linux.
2.5.2 Zap
Il programma zap, eseguibile da linea di comando, è quello che effettua il tuning dei
canali televisivi analizzandone il segnale. L’applicazione deriva proprio il suo nome
33
Capitolo 2: LinuxTV
dall’operazione di sintonizzazione di un canale che viene comunemente detta
“zapping”. Esso supporta tutti gli standard del DVB, per ciascun mezzo trasmissivo, ed
ha un comando specifico per ognuno: tzap per il digitale terrestre, szap per il satellitare,
czap per la TV via cavo e azap per l’ATSC, lo standard digitale terrestre utilizzato negli
Stati Uniti e in America Centrale.
Per funzionare con successo, il programma necessita del file di configurazione dei
canali (channels.conf), da cui estrae le informazioni utili per la sintonizzazione. Il
comando tzap inoltre, prende come argomento il nome del canale da sintonizzare che, in
caso contenesse spazi, deve essere scritto tra virgolette singole o doppie. Esso in pratica
esegue una ricerca indicizzata, utilizzando come parola chiave il nome del canale che
deve essere sintonizzato, all’interno del file channels.conf. Se tale ricerca ha successo,
vengono estratte le informazioni relative alla frequenza ed ai parametri di modulazione.
Poi ha inizio il tuning. Questa utility, come anche la precedente, è fortemente collegata
con le DVB API. Questo fatto lo si può notare facilmente se si analizza il codice
sorgente del programma ed in particolare la funzione check_frontend(…) che è la
subroutines principale:
static
int check_frontend (int fe_fd)
{
fe_status_t status;
uint16_t snr, signal;
uint32_t ber, uncorrected_blocks;
do {
ioctl(fe_fd,
ioctl(fe_fd,
ioctl(fe_fd,
ioctl(fe_fd,
ioctl(fe_fd,
&uncorrected_blocks);
FE_READ_STATUS, &status);
FE_READ_SIGNAL_STRENGTH, &signal);
FE_READ_SNR, &snr);
FE_READ_BER, &ber);
FE_READ_UNCORRECTED_BLOCKS,
printf ("status %02x | signal %04x | snr %04x | "
"ber %08x | unc %08x | ",
status, signal, snr, ber, uncorrected_blocks);
if (status & FE_HAS_LOCK)
printf("FE_HAS_LOCK");
usleep(1000000);
printf("\n");
} while (1);
return 0;
}
Listato 2.1: Funzione di settaggio del frontend
34
Capitolo 2: LinuxTV
Una volta analizzato il programma, si può dire che il tuning consiste nel settare il
frontend, ricevere informazioni sul suo stato, utilizzando le chiamate standard definite
nelle LinuxTV DVB API, e stampare sul terminale i parametri ottenuti. Una volta
avviato, le prime tre righe di output del comando indicano quello che tzap sta facendo.
Viene cioè indicato quale dispositivo si sta sintonizzando e con quali parametri (sono
quelli corrispondenti al file channels.conf). A partire dalla quarta riga vengono poi
mostrate le informazioni sul segnale. Tutte le successive righe invece rappresentano
solamente l’aggiornamento delle informazioni precedenti. Questo processo si ripete
continuamente generando una riga aggiornata ogni secondo. Per interrompere questo
task è necessario premere Ctrl+C, la combinazione di tasti standard della shell di Linux
per uccidere il programma in esecuzione.
Questi sono i sei campi, in formato esadecimale, che appaiono nel rapporto stampato dal
tzap:
•
status: stato attuale del ricevitore. Il valore 0x00 indica che la scheda è stata
inizializzata ma nessun segnale è stato ancora decodificato. Il valore 0x1f invece
significa che il canale è sintonizzato e tutto funziona correttamente. Per altri
valori ci si può riferire al Paragrafo 2.3.3 che descrive le API del frontend;
•
signal: forza del segnale. Un valore alto sta ad indicare un buon segnale in
ricezione. In realtà questo parametro non è molto indicativo e può essere
fuorviante poiché ogni scheda TV fornisce valori differenti. Esso è utile soltanto
nel confronto tra i vari canali utilizzando lo stesso supporto hardware. Per voler
dare una soglia di qualità si può definire buono un segnale che supera il valore di
0x8000;
•
snr: (signal/noise ratio) rapporto segnale rumore. Questo è il più importante
indicatore del corretto funzionamento della scheda, e della corretta ricezione di
un canale. Il valore non deve essere necessariamente il più alto possibile, è
importante invece che non abbia fluttuazioni. Anche in questo caso, i valori che
superano 0x8000 si possono considerare validi;
•
ber: (bit error rate) tasso di errore. Questo valore deve essere il più basso
possibile, preferibilmente uguale a zero. Esso va comunque valutato prendendo
anche in considerazione il tasso di codifica del segnale, poiché se quest’ultimo è
abbastanza robusto, può sopportare anche un tasso di errore elevato;
35
Capitolo 2: LinuxTV
•
unc: (uncorrected block error) errori dei blocchi non corretti. Anche in questo
caso il valore dovrebbe essere il più possibile uguale a 0. In caso contrario i
pacchetti errati non verranno codificati correttamente dal decoder MPEG-2 e si
presenteranno dei disturbi sul segnale in output;
•
FE_HAS_LOCK: indica che il canale è stato sintonizzato correttamente.
Il programma tzap, oltre per la fase di test, può essere utilizzato anche per registrare un
programma TV nell’hard disk. Questo avviene perché l’applicazione tzap, grazie
all’opzione “-r”, rende disponibile il flusso di trasporto MPEG-2 come output della
periferica virtuale dvr. Da questa si può poi registrare lo stream nel disco rigido. Questa
redirezione dell’output viene effettuata al momento del settaggio del dispositivo di
demux, tramite una linea di codice in cui viene definito il valore dell’output del
demuxer.
pesfilter.output = dvr ? DMX_OUT_TS_TAP : DMX_OUT_DECODER
Anche con questa opzione attivata, tzap fornisce in output tutte le informazioni
riguardanti il segnale; quindi se non si è interessati la si può disattivare attraverso
l’opzione “-S”.
2.5.3 Dvbsnoop
Figura 2.3: Logo del programma Dvbsnoop
Dvbsnoop è un analizzatore del flusso DVB che serve per monitorare, o fare il dump del
flusso digitale proveniente dalla scheda DVB. Esso fa parte di un progetto esterno alla
comunità LinuxTV ma si basa anche esso sulle Linux DVB API. Il programma inoltre è
un software libero che viene rilasciato sotto la licenza GNU General Public License.
Questa applicazione consente di analizzare tutti i flussi digitali standard del DVB come
il Transport Stream e il PES, fornendo anche alcuni parametri statistici sul segnale
ricevuto. Inoltre, Dvbsnoop è in grado di decodificare tutte le tabelle di servizio che
vengono iniettate dai broadcaster nel TS, sia quelle PSI dello standard MPEG-2 che
36
Capitolo 2: LinuxTV
quelle definite dal DVB-SI. Il programma, durante il suo funzionamento, non si occupa
però del settaggio del frontend della scheda, quindi deve essere obbligatoriamente
eseguito in contemporanea con un software per la sintonia, come tzap. In questo modo,
mentre tzap si sintonizza sulla frequenza desiderata, Dvbsnoop può analizzare il flusso
uscente dalla scheda. Per visualizzare il contenuto di un PID, utilizzando tutte le
impostazioni di default, basta digitare:
$ dvbsnoop <PID>
In alternativa è possibile vedere tutte le impostazioni accettate, come visualizzato nel
Listato 2.2, utilizzando il comando
$ dvbsnoop -help
dvbsnoop - a dvb/mpeg2 stream analyzer tool
Version: 1.4.00/api-3 (Oct 25 2005 15:48:51)
http://dvbsnoop.sourceforge.net/
(c) 2001-2005 Rainer Scherg (rasc)
Usage:
dvbsnoop [opts] pid
Options:
-s type:
snoop type or mode <type> [-s sec]
stream type: sec, pes, ps or ts
or special scan type:
pidscan = transponder pid scan,
bandwidth = data rate statistics for pid
signal = signal rate statistics
feinfo = frontend information
stream type or pidscan
-demux device: demux device [/dev/dvb/adapter0/demux0]
-dvr device:
dvr device [/dev/dvb/adapter0/dvr0]
-frontend device: frontend
device [/dev/dvb/adapter0/frontend0]
-adapter n:
select dvb adapter/card no. <n> using default path
-devnr n:
select device no. <n> using default dvb adapter/card
-if file:
input file, reads from binary <file> instead of demux
device
<file>="-" = /dev/stdin
-timeout ms: section/signal read timeout in <ms> msec. [-timeout
0]
-maxdmx n:
max demux filters <n> to use in pidscan mode (0=max)
[-maxdmx 0]
-buffersize kb: read buffersize in KBytes [-buffersize 0]
(0 = use default read buffer size)
-f filter:
filtervalue for 'sec' demux [-f 0]
multibyte filter syntax: 0x1A.34.56.7F.01
-m mask:
maskvalue for 'sec' demux [-m 0]
multibyte mask syntax: 0x1A.00.F6.55
37
Capitolo 2: LinuxTV
-crc:
-nocrc:
-softcrc:
nosoftcrc]
-nosoftcrc:
nosoftcrc]
-sync:
[-snyc]
-nosync:
-n count:
-N count:
CRC check when reading 'sec' [-nocrc]
no CRC check when reading 'sec' [-nocrc]
internal soft CRC check when reading 'sec' [no internal soft CRC check when reading 'sec' [simple packet header sync when reading 'ts' or 'pes'
no header sync when reading 'ts' or 'pes' [-snyc]
receive/read max. <count> packets (0=no limit) [-n 0]
decode max. <count> packets (0=no limit) [-N 0]
this will limit -n, e.g. when using soft filters.
-spiderpid:
snoop referenced section pids (sets -n 1)
-tssubdecode: sub-decode sections or pes from ts stream decoding
-tsraw:
read raw/full TS in TS snoop mode
-b:
binary output of packets (disables other output)
-ph mode:
data hex dump mode, modes: [-ph 4]
0=none, 1=hexdump, 2=hex line 3=ascii line
4=hexdump2
-hexdumpbuffer:
print hex dump of read buffer [-hexdumpbuffer]
-nohexdumpbuffer: don't print hex dump of read buffer [hexdumpbuffer]
-nph:
don't print hex dump of buffer [= -nohexdumpbuffer]
-pd verbose: print stream decode (verbose level 0..9) [-pd 7]
-npd:
don't print decoded stream (= -pd 0)
-t[n|d|f]:
print timestamp (no, delta, full) [-tf]
-privateprovider id: set provider <id> string for decoding private
tables and descriptors
-hideproginfo: hide copyright and program info header at program
start
-help:
this usage info...
Listato 2.2: Help di Dvbsnoop
38
Capitolo 3: Le schede per la TV digitale
3.1 Introduzione
Una scheda TV è un componente hardware che permette di vedere la televisione tramite
un normale computer. Queste periferiche hanno cominciato a diffondersi sul mercato
consumer a partire dall’anno 2000 circa, quando raggiunsero un prezzo accettabile per
l’acquisto. Una volta installata, la scheda prende in ingresso il segnale proveniente dal
cavo coassiale, che a seconda del tipo di trasmissione ricevuta può avere origine da
un’antenna o da una parabola, e produce in uscita un segnale digitale. Questo viene poi
inviato, tramite interfacce diverse, al computer, che lo gestisce per la visualizzazione.
Figura 3.1: Quattro tipi diversi di schede DVB-T
3.2 Classificazione
Le schede TV attualmente disponibili sul mercato sono molte ed hanno caratteristiche
molto diverse tra loro. Per permettere una maggiore comprensione, che consenta di
districarsi più facilmente tra i vari prodotti che le aziende offrono, queste si possono
classificare secondo alcuni parametri significativi. Tra i vari termini di raffronto si
possono citare: l’interfaccia di collegamento, il tipo di segnale ricevibile, lo standard di
trasmissione e le caratteristiche hardware.
39
3.2.1 Interfaccia di collegamento
Tra i vari tipi di schede che esistono in commercio, sono disponibili quelle con
interfaccia PCI (Peripheral Component Interconnect), PCI Express ed ExpressCard. La
differenza sta tutta nel tipo di bus di connessione. Il primo è il comune standard di
connessione in un PC fisso, con transfer rate di 133 MB/s di picco per la versione a 32
bit. Il secondo è più veloce (raggiunge 266 MB/s per la versione a singolo canale) e
presto andrà a sostituire il precedente standard PCI. Il terzo invece è il formato
progettato per i laptop, con interfaccia PCI Express e possibilità di collegamento a
caldo; ciò vuol dire che il sistema è in grado di riconoscere la periferica senza che sia
necessario il riavvio. Inoltre, ultimamente, sul mercato sono apparsi nuovi dispositivi,
con collegamento USB ed una dimensione paragonabile a quella delle comuni chiavette
per la memorizzazione dei dati. Questo tipo di schede sta ultimamente avendo molto
successo a causa della trasportabilità e della facilità di installazione. Questa tecnologia
presenta comunque dei limiti, in quanto necessita di una connessione veloce (deve
essere supportato lo standard USB 2.0 che consente di raggiungere i 60 MB/s) per non
far perdere fluidità al flusso video, ed inoltre molti modelli non sono compatibili con il
sistema operativo Linux.
3.2.2 Tipo di segnale
A seconda del tipo di segnale ricevibile dal sintonizzatore, le schede si possono
raggruppare in quattro categorie: analogiche, digitali, ibride e combinate. Le prime,
consentono di ricevere la normale TV analogica e sono costituite da un convertitore
analogico/digitale e a volte anche da un encoder MPEG. Di solito questo tipo di schede
viene utilizzato soprattutto per l’acquisizione video da sorgenti analogiche come SVideo o video composito. Le schede digitali sono quelle che possono ricevere la TV
digitale, codificata con lo standard DVB. Queste svolgono lo stesso compito dei set-top
box che si collegano nei normali televisori. I sintonizzatori ibridi poi, sono quelli che
possono gestire sia il segnale analogico che quello digitale, a seconda di come vengono
configurati. Il passaggio tra i due tipi non può però essere effettuato al volo. Le schede
combinate invece, hanno sia un sintonizzatore analogico che uno digitale. La differenza
con le precedenti sta nel fatto che, in questo caso, sono presenti due sintonizzatori
anziché uno solo; quindi questi consentono di gestire contemporaneamente i due tipi di
segnale, mentre nel caso delle schede ibride questo non poteva accadere. Questi ultimi
40
due tipi di schede stanno diventando molto popolari in tutti quei paesi, come l’Italia,
dove si sta effettuando il passaggio dalla TV analogica a quella digitale. Entrambi i
formati, infatti, permettono di usufruire del segnale digitale ma consentono di guardare
anche in analogico quei canali che non hanno ancora una buona copertura.
3.2.3 Standard di trasmissione
Le schede DVB si possono ulteriormente classificare in tre categorie diverse, a seconda
dello standard di trasmissione che viene adottato: DVB-S per la TV satellitare, DVB-T
per la televisione digitale terrestre e DVB-C per quella via cavo. Fondamentalmente, ciò
che distingue questi tipi di trasmissione, è la modulazione del segnale, che viene ogni
volta adattata alle caratteristiche di propagazione del mezzo trasmissivo utilizzato. Per il
DVB-S, caratterizzato da un segnale a larga banda e limitato in potenza, risulta idonea
la tecnica QPSK a singola portante. La trasmissione via cavo è invece soggetta a
distorsioni lineari e limitazioni di banda, quindi viene utilizzata la modulazione QAM,
che risulta più adatta allo scopo. Per la modulazione del segnale terrestre infine viene
adottata la tecnica COFDM (vedi Paragrafo 1.4.6). Data questa differenza, viene
montato un decodificatore DVB diverso a seconda di quale segnale la scheda è adibita a
ricevere.
3.2.4 Caratteristiche hardware
Ogni scheda infine, a seconda del costo e della qualità, può avere più o meno
componenti hardware installati. Ad esempio, esistono schede caratterizzate da più di un
sintonizzatore e decodificatore. Queste sono quindi in grado di ricevere tutti i tipi di
trasmissione descritti precedentemente. Un termine comune di distinzione inoltre
riguarda la presenza o meno del decodificatore del flusso MPEG-2. Le schede che ne
sono provviste vengono dette Full Featured mentre le altre vengono dette Budget. Una
trattazione
più
dettagliata
su
queste tipologie
di
schede viene sviluppata
successivamente, al Paragrafo 3.4, dove vengono analizzati i vantaggi e gli svantaggi di
entrambe.
41
3.3 Anatomia di una scheda DVB
Figura 3.2: Schema dei componenti di una scheda DVB
Generalmente, una scheda DVB PCI è costituita dai seguenti componenti hardware
principali: Frontend, Conditional Access, Demuxer e Decoder Mpeg-2 audio e video.
Inoltre, soltanto nel Frontend delle schede DVB satellitari, è presente un dispositivo
SEC (Satellite Equipment Control) che serve per controllare lo LNB, un convertitore,
posizionato nel punto di fuoco della parabola, che amplifica il segnale e lo trasla di
banda. In Figura 3.2 è rappresentato lo schema di un generico ricevitore DVB.
Il Frontend è formato dal sintonizzatore e dal demodulatore DVB. Questo è il primo
componente hardware del ricevitore che è raggiunto dal segnale proveniente
dall’antenna. Il Frontend converte il segnale ricevuto verso frequenze più basse,
riportandolo in banda base. Poi lo trasforma in un segnale digitale, tramite un
convertitore A/D, ed infine lo demodula effettuando tutti i passi descritti nel paragrafo
1.4.6, ma all’inverso. Ciò che si ottiene, in uscita dal dispositivo, dopo questo processo,
è un Transport Stream (TS) MPEG-2.
Il CA (Conditional Access) è il dispositivo utile per la decodifica dei canali criptati.
Tale hardware è costituito anche da un adattatore CI (Conditional Interface) ed uno o
più slot per le smart card. In questo passo del processo, vengono identificati, tramite la
smart card, quali sono i programmi a cui l’utente può avere accesso. Questi vengono
decodificati in real time e vengono reinseriti di nuovo nel Transport Stream originario.
Il Demuxer (o Demultiplexer) filtra gli stream DVB che devono essere visualizzati.
Esso divide il Transport Stream nelle componenti Audio e Video che poi verranno
inviate separatamente al decodificatore. In questo passo vengono anche individuati e
separati i flussi contenenti le informazioni di servizio.
42
Il decodificatore MPEG-2 riceve i flussi audio e video provenienti dal Demuxer e li
elabora separatamente. Dopo la codifica, i flussi non compressi sono pronti per
raggiungere lo schermo del computer ed essere visualizzati. Alcuni ricevitori sono
costituiti anche di un encoder PAL/NTSC per poter collegare il dispositivo direttamente
ad uno schermo televisivo.
3.4 La differenza tra le schede Budget e Premium
Il flusso di dati MPEG (il Transport Stream), proveniente dal decodificatore DVB-T che
lo ha demodulato, per poter essere visualizzato necessita di una fase di decodifica.
Questa può essere effettuata via hardware, mediante un chip dedicato, o via software,
attraverso un algoritmo di decodifica installato nel PC. Nelle schede TV di tipo
Premium, dette anche Full Featured Card, il Transport Stream MPEG-2 viene gestito
direttamente dalla stessa, attraverso un chip di decodifica MPEG. Nelle schede invece
di tipo Budget, dove il nome sta per Low Budged Card, cioè schede a basso costo,
l’hardware di decodifica non è presente quindi il TS deve essere gestito via software
attraverso la CPU. Considerando lo schema in Figura 3.2, una scheda FF (abbr. Full
Featured) ha installati tutti i dispositivi descritti, eccetto il modulo CA che spesso deve
essere acquistato separatamente. La scheda quindi acquisisce il segnale DVB
proveniente dall’antenna, lo elabora e rende disponibile il video e l’audio decodificati,
attraverso una o più uscite collegabili direttamente alla TV o ad un monitor. In questo
caso essa funge sia da periferica di input che di output. La scheda Budget invece,
integra soltanto il frontend. Il flusso di trasporto quindi passa, attraverso il bus PCI,
dalla scheda alla memoria di sistema, dove viene prima decodificato tramite la CPU e
poi inviato alla scheda video che ne gestisce l’output.
La differenza hardware che esiste tra i due tipi di periferiche, in termini di complessità e
numero di componenti installati, si riflette anche nel prezzo. Una scheda di tipo Full
Featured, infatti, viene venduta ad un prezzo che si aggira da 150 a 200 euro, a seconda
delle caratteristiche, mentre una di tipo Budget si può acquistare a circa 50 euro. Questa
spesa superiore non è però ricompensata dalle prestazioni finali del sistema, in quanto le
macchine moderne sono in grado di decodificare agilmente un flusso MPEG-2,
rendendo inutile la presenza del decoder hardware. Le schede Premium, sono state le
prime ad essere apparse sul mercato, quando ancora i computer non erano abbastanza
43
performanti da gestire una codifica software in tempo reale. Ad esempio, le schede
DVB della Siemens e TechnoTrend che venivano supportate dalla prima versione delle
API di LinuxTV, erano di questo tipo, poiché comprendevano al loro interno il chip
AV711x che funzionava da decodificatore MPEG-2. Al giorno d’oggi però, con
l’avanzare della tecnologia, le prime periferiche Full Featured sono ormai fuori
produzione e, per i motivi descritti precedentemente, non ne vengono quasi più
commercializzate di nuove.
3.5 La scheda ASUS My Cinema-P7131 Hybrid
La Asus My Cinema-P7131 Hybrid è una scheda TV PCI di tipo budget adatta per
vedere la televisione digitale terrestre (DVB-T) tramite il PC di casa. La periferica è
compatibile con tutte le motherboard dotate di connettore standard PCI versione 2.2 o
superiore ed è riconosciuta dai sistemi operativi Windows, con driver forniti
all’acquisto. Per Linux invece, devono essere utilizzati i driver sviluppati dalla comunità
LinuxTV. La scheda, grazie al suo sintonizzatore ibrido, permette la ricezione della TV
digitale, della TV analogica e della radio FM. Inoltre, tramite un ingresso audio/video
(composto da un cavo con collegamento audio, video composito e S-Video), è possibile
anche catturare fonti video esterne. Con l’acquisto della scheda è compreso anche il
telecomando, con sensore IR (Infra-red) collegabile direttamente ad un ingresso della
periferica, un’antenna TV portatile unidirezionale, un’antenna per la radio FM e un
bundle di software, compatibile però solo con sistema operativo Windows. Per quanto
riguarda l’hardware vero e proprio, la ASUS My Cinema-P7131 Hybrid è composta da
un sintonizzatore in silicio con due ingressi, uno per il digitale terrestre ed uno per la
TV analogica, un decodificatore di canale DVB-T (Philips TDA10046A) ed un decoder
audio e video (Philips SAA7131E). Quest’ultimo è utilizzato per l’acquisizione del
segnale della televisione analogica e per la gestione del flusso di trasporto del DVB che
deve essere inviato al bus PCI. Oltre a questi, è presente anche un oscillatore a basso
costo a 4 MHz, come sorgente del segnale di clock. Dato che è una scheda budget, non
è integrato né il demultiplexer, né il chip per la decodifica MPEG.
44
3.5.1 Il chip TDA10046A
Figura 3.3: Schema del chip TDA10046
Il componente hardware Philips TDA10046A è un decodificatore del segnale DVB-T.
Tra le sue caratteristiche annovera, in un singolo chip: un demodulatore COFDM
conforme allo standard “ETSI EN 300 744” (quello del DVB-T), che opera sia in
modalità 2K che 8K, un convertitore A/D (da analogico a digitale) a 10 bit, un
algoritmo detto “Pulse Killer” per ridurre i disturbi impulsivi provocati dagli
elettrodomestici, un dispositivo di scansione veloce delle bande UHF e VHF ed un
basso consumo (450 mW). Come si può notare in Figura 3.3, il dispositivo prende in
ingresso il segnale a media frequenza proveniente dal tuner e produce in uscita un
Transport Stream MPEG-2, attraverso un processo composto da alcuni passi
fondamentali che verranno adesso descritti. Prima il segnale giunge ad un convertitore
analogico/digitale che lo campiona a 10 bit, poi viene convertito in banda base. A
questo punto il segnale passa attraverso il demodulatore FFT (Fast Fourier Transform)
che lo trasforma. La risposta in frequenza del canale viene poi valutata e filtrata sia nel
dominio del tempo che della frequenza, per poi venire utilizzata per equalizzare il
segnale. Inoltre viene anche effettuata una correzione dell’errore di fase prodotta dal
sintonizzatore. Infine viene applicato l’algoritmo di correzione FEC, producendo alla
porta di uscita del dispositivo il Transport Stream MPEG-2 decodificato.
45
3.5.2 Il chip SAA7131E
Figura 3.4: Schema del chip SAA7134
Il dispositivo Philips SAA7131E è un decodificatore audio e video PCI, altamente
integrato ed a basso costo, che consente l’acquisizione della televisione in un PC, sia
quella analogica che quella digitale (DTV e DVB). I dati multimediali che vengono
acquisiti sono trasportati attraverso il bus PCI con una operazione di master - write, in
modo da sfruttare in maniera ottimale le capacità di streaming dei moderni sistemi. Per
il trattamento dei segnali analogici, provenienti dal sintonizzatore o dall’ingresso video,
il dispositivo ha incorporati due convertitori A/D e tutta la circuiteria necessaria alla
codifica di qualsiasi segnale analogico, anche non standard. Il dispositivo permette
anche che l’immagine video venga ritagliata, diminuita o ingrandita in entrambe le
direzioni (verticale e orizzontale) prima di passare attraverso un filtro adattativo che
previene il fenomeno di aliasing. Circuiti dedicati sono presenti anche per la codifica
del segnale audio stereo della TV e della radio FM che viene inviato anche ad una uscita
audio interna. Tutti i dati decodificati, compreso il Transport Stream proveniente da un
decodificatore DVB, vengono inviati, attraverso l’interfaccia della periferica, al bus per
poi essere catturati dalla memoria di sistema.
46
Capitolo 4: Installazione e gestione della
scheda DVB-T
4.1 Le scelte progettuali
Lo scopo del progetto è stato quello di realizzare un sistema minimale, basato sul
sistema operativo Linux, che consenta di ricevere il segnale televisivo digitale terrestre
dello standard DVB-T. La prima scelta che è stata compiuta, riguarda le caratteristiche
hardware della macchina adibita allo scopo. Per realizzare un sistema economico si è
pensato di non servirsi di hardware dedicato. Viene utilizzato infatti un normale sistema
host domestico con componenti a basse prestazioni e quindi anche a basso costo. Il PC
scelto è caratterizzato da un processore Pentium III a 600 MHz, una memoria RAM pari
a 360 Mbyte e una scheda video nVidia Vanta con 16 Mbyte di RAM dedicati.
Per quanto riguarda il sistema operativo si è pensato di utilizzare Ubuntu 6.06 LTS, una
distribuzione di GNU/Linux basata su Debian. La scelta di utilizzare Linux, invece che
un sistema della Microsoft come Windows, è dettata principalmente da due fattori.
Prima di tutto Ubuntu risponde alla caratteristica di economicità perché è un software
libero al cento per cento e quindi completamente gratuito. Poi Linux offre molte
possibilità di sviluppo, attraverso i vari moduli e pacchetti che è possibile installare.
Inoltre esso riesce a funzionare in modo abbastanza efficace anche su sistemi datati e
non altamente performanti.
La scheda TV utilizzata invece è la ASUS My Cinema-P7131 Hybrid, descritta al
Paragrafo 3.5, che consente la ricezione della televisione digitale terrestre. La
valutazione in questo caso è stata piuttosto difficile perché, acquistare un prodotto
destinato ad un sistema operativo come Linux, dove spesso la compatibilità ed il
supporto sono un problema, risulta sempre una spesa rischiosa. La scelta finale si è
basata soprattutto sul fatto che quella adottata è una periferica a basso costo, che viene
indicata tra le schede supportate dai driver sviluppati dalla comunità LinuxTV. Questo
fatto non consente una completa sicurezza poiché è sempre possibile che una scheda
47
Capitolo 4: Installazione e gestione della scheda DVB-T
prima supportata non venga più riconosciuta a causa, ad esempio, di bug nel kernel o
modifiche hardware non dichiarate dal produttore. Per questo motivo sono stati anche
analizzati i componenti hardware della scheda, che risultavano però anch’essi
compatibili. Più precisamente, il chip della Philips SAA7131E viene supportato dal
modulo del kernel chiamato saa713x.
4.2 Ubuntu 6.06 LTS
Ubuntu è un sistema operativo basato su GNU/Linux, nato nel 2004 dalla distribuzione
Debian. Questi due sistemi sono strettamente connessi ma Ubuntu si differenzia da
Debian per lo spiccato orientamento verso configurazioni desktop e per la maggiore
facilità di utilizzo; caratteristiche studiate per cercare di attirare utenti provenienti da
sistemi Microsoft. Di Ubuntu viene rilasciata regolarmente una versione nuova ogni sei
mesi e, per ognuna di queste, ne vengono realizzate due edizioni, una desktop ed una
server, e diverse varianti, ufficiali e non, che si diversificano soprattutto per l’ambiente
desktop. La versione che è stata scelta per il progetto è la 6.06 LTS (Long Time
Support), detta anche Dapper Drake. Questa è basata sul kernel Linux 2.6.15. La
Dapper non è una versione nuova, è stata rilasciata a Giugno del 2006, ma viene
garantito un supporto a lungo termine, fino al 2009. La 6.06 LTS è stata preferita alla
nuova versione, la 7.04 rilasciata il 19 Aprile 2007, perché con l’ultima versione del
kernel, la numero 2.6.20, sussistevano dei problemi di compatibilità con i driver e le
API create da LinuxTV.
4.2.1 Edizioni
L’edizione desktop è basata sull’interfaccia grafica GNOME (GNU Network Object
Model Environment). Questo ambiente desktop è completamente libero ed è
caratterizzato da una struttura semplice ed intuitiva ma anche altamente flessibile e
personalizzabile. Questa versione ha già con sé la maggior parte dei driver necessari al
funzionamento del sistema; inoltre è corredata da una selezione di applicazioni utili sia
per l’ufficio che per l’intrattenimento e la navigazione in internet, come Firefox,
OpenOffice, Evolution, Totem ecc.
L’edizione Server è caratterizzata invece da un’ottima robustezza e da eccellenti
prestazioni, date anche dal fatto che questa versione non installa alcun ambiente grafico.
Un altro aspetto chiave è la sicurezza; una volta installato, infatti, il sistema contiene
48
Capitolo 4: Innstallazionee e gestione della sched
da DVB-T
soolamente il software necessario
n
a
all’utilizzo
server, senzza nessuna porta aperrta verso
l’eesterno. Quuesta edizionne fornisce una valida piattaforma per lo sviiluppo di seerver per
innternet graziie ad Apachhe, MySQL e PHP.
4..2.2 Installlazione della versionee desktop
Trra le ediziioni del siistema operrativo adotttato è stata scelta lla desktop. Questa
prreferenza deeriva dal faatto che unn sistema ad
dibito alla ricezione
r
edd alla visio
one della
teelevisione digitale
d
ha bisogno
b
di un
u ambientee grafico addeguato. Inooltre Ubunttu ha dei
reequisiti minnimi, dichiaarati dalla comunità, che non soono troppoo esigenti poiché
p
è
neecessario sooltanto una CPU a 4000 MHz e 256 MB di RAM.
R
I componenti hardware
h
uttilizzati, inffatti, riescoono a soppoortare efficacemente il carico di lavoro e non
n si è
obbbligati ad installare
i
la versione seerver.
U
Ubuntu
6.06 LTS edizione desktopp viene forrnita tramitee un LiveC
CD, che con
nsente di
prrovare il sistema operattivo senza averlo
a
primaa installato,, in modo chhe si possan
no anche
teestare le fuunzionalità ed il correetto riconosscimento dii tutte le pperiferiche. Tramite
quuesto LiveC
CD è poi possibile intraprendeere la proccedura d’innstallazione,, che si
prresenta in modalità
m
grafica.
Figura 4.1: Schermata di
d scelta della lingua
49
da DVB-T
Figura 4..2: Schermata del fuso oraario
Figura 4.3:
4 Schermatta scelta tastiera
50
da DVB-T
Figura 4.4: Schermata del
d partizionaamento
Peer iniziare a lavorare con
c Ubuntuu 6.06 LTS è sufficiennte inserire iil CD e riav
vviare il
sistema, assiccurandosi che
c il BIOS sia configu
urato per l’avvio da CD-ROM. Al
A reboot
apppare la prrima scherm
mata del siistema opeerativo, dovve, premenddo F2, è possibile
p
sccegliere la liingua. Da qui
q ha inizioo l’avvio di Ubuntu livve. Finito il caricamento
o, si è di
fronte ad un sistema com
mpleto funzzionante da CD. Per laanciare l’insstallazione basta un
dooppio clickk sull’iconaa installa. In seguito
o, durante la proceduura d’installlazione,
veengono pressentate variie schermatte dove, una volta effeettuata la sccelta, basta cliccare
suul pulsante avanti perr confermaare. La priima scherm
mata (Figurra 4.1) rigu
uarda la
seelezione deella lingua. L’italiano è presentee nel CD ma per installare i pacchetti
p
coompleti è neecessaria unna connessiione interneet attiva. Neella secondaa schermataa (Figura
4.2) va seleziionato il fusso orario inndicando la città di rifeerimento dellla zona geo
ografica.
Inn alternativaa è possibilee anche imppostare l’orra manualm
mente. La suuccessiva scchermata
(F
Figura 4.3) chiede la mappaturaa della tastiiera; la corrretta sceltaa va poi verificata
v
diigitando alccuni caratterri in una texxt-box a fon
ndo finestraa. A questo punto va effettuata
e
l’ooperazione più critica: il partizionnamento del disco rigido (Figura 4.4).
L’installazionne di base prevede
p
la creazione di due partiziooni:
51
•
il file system, detto root, ed indicato con il simbolo “/”, è la partizione dove
viene installato il SO;
•
l’area di swap è quella necessaria per la memoria virtuale. La dimensione di
questa è in funzione dell’uso e della memoria installata nel computer: è
consigliata l’allocazione di uno spazio che va da uno a due volte la RAM.
A queste si possono aggiungere altre partizioni per contenere, ad esempio, ulteriori
sistemi operativi installati. La procedura da eseguire consiste nel selezionare la
partizione esistente, ridimensionarla e, con lo spazio ricavato, creare le due partizioni
necessarie. In seguito deve essere indicata nella tabella dei punti di mount, in quale
partizione deve essere installata la partizione di root e in quale quella di swap. Infine
cliccando su continua le modifiche vengono applicate irreversibilmente e la procedura
d’installazione ha inizio. Da qui in poi è tutto automatico; verrà solo chiesto, alla fine
del processo, se si vuole riavviare il sistema o continuare con il LiveCD.
4.2.3 Software indispensabile
Una volta che il sistema è stato installato correttamente, al riavvio è necessario
installare alcuni software indispensabili per la corretta visualizzazione del flusso DVBT. Questi sono:
•
i driver per la scheda video: per la Vanta si devono utilizzare i nvidia-glx-legacy,
che sono dei driver creati per mantenere la compatibilità con le schede video più
obsolete;
•
il player multimediale: viene utilizzato Gxine, corredato con i relativi codec per
il video MPEG-2 e l’audio. GXine è un frontend grafico, basato su Gnome, del
software xine, un riproduttore multimediale per Linux, rilasciato sotto la licenza
GNU General Public Licence. Tramite questo player è possibile utilizzare la
scheda DVB-T per visualizzare i vari canali;
•
lirc: il demone per la gestione del telecomando.
Questi possono essere installati sia utilizzando il gestore standard dei pacchetti, APT,
che tramite i sorgenti reperibili nei siti ufficiali. Dato che alcuni di questi programmi
non sono supportati ufficialmente da Ubuntu, è necessario anche abilitare i repository
Universe e Multiverse. Un repository è un archivio di software, dove sono conservati
tutti i programmi installabili tramite il gestore dei pacchetti. Ubuntu utilizza quattro
categorie di repository: Main, per il software ufficiale, Restricted, per quello non
52
completamente libero, Universe, per quello supportato dalla comunità e Multiverse che
contiene software non gratuito. All’atto dell’installazione del sistema sono abilitati
soltanto i primi due, quindi è necessario abilitare anche i restanti per poter installare i
codec e i driver della scheda video.
Inoltre, dato che il sistema utilizzato è stato rilasciato circa un anno fa, è preferibile
aggiornarlo in modo che tutti i pacchetti siano i più recenti possibili. Per farlo si
utilizzano i seguenti comandi da shell:
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
Il primo di questi aggiorna la lista dei pacchetti mentre il secondo e il terzo installano
tutti i pacchetti nuovi che sono stati trovati. In questo modo si ottiene un sistema
corretto da tutti i bug riguardanti la sicurezza scoperti finora.
4.3 Installazione della scheda
L’installazione di una scheda DVB inizialmente risulta piuttosto complessa. Questo
perché spesso non tutte le periferiche risultano pienamente supportate, a fronte, per la
maggior parte delle volte, di modifiche hardware delle schede più nuove rispetto alle
precedenti. È quindi necessario adattare la procedura di installazione ad ognuna di esse.
Dopo alcune prove, è stato formulato un metodo di installazione che sembra il più
corretto; quello che può essere utilizzato per la maggior parte delle schede in
commercio. Questo metodo viene descritto nei paragrafi seguenti.
4.3.1 Firmware
Questa scheda necessita del firmware per il demodulatore DVB-T, un file che va
copiato nella directory dei firmware del sistema. Questo file è di fondamentale
importanza per la buona riuscita dell’installazione quindi è necessario trovare quello
giusto. Il chip utilizzato dalla scheda ASUS My Cinema-P7131 Hybrid è, come già
indicato in precedenza (Paragrafo 3.5.1), il Philips TDA10046A. Il firmware giusto è
quindi quello chiamato dvb-fe-tda10046.fw. Per ottenerlo, dato che il produttore non ne
distribuisce una versione per linux, si utilizza uno script Perl, chiamato
get_dvb_firmware, che è incluso nei sorgenti del kernel. La subroutine a cui siamo
interessati è quella nel Listato 4.1. In realtà questo script prende i driver per windows di
53
un’altra scheda, la LifeWiew FlyDVB-T Hybrid, ma, dato che il chip è lo stesso, il
firmware risulta compatibile con la scheda utilizzata nel progetto.
sub tda10046lifeview {
my $sourcefile = "Drv_2.11.02.zip";
my $url = "http://www.lifeview.com.tw/drivers/pci_card/FlyDVBT/$sourcefile";
my $hash = "1ea24dee4eea8fe971686981f34fd2e0";
my $outfile = "dvb-fe-tda10046.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
checkstandard();
wgetfile($sourcefile, $url);
unzip($sourcefile, $tmpdir);
extract("$tmpdir/LVHybrid.sys", 0x8b088, 24602, "$tmpdir/fwtmp");
verify("$tmpdir/fwtmp", $hash);
copy("$tmpdir/fwtmp", $outfile);
$outfile;
}
Listato 4.1: Subroutine per ottenere il firmware della scheda
Il percorso di sistema dove sono contenuti tutti i firmware non è uguale per tutte le
distribuzioni di Linux. Quello standard è /lib/firmware/ mentre in questo caso il
percorso è leggermente diverso. Per copiare il file desiderato nella giusta directory, si
può utilizzare il comando:
$ sudo cp dvb-fe-tda10046.fw /lib/firmware/2.6.15-28-386
4.3.2 Requisiti
Prima di iniziare l’installazione vera e propria, per poter scaricare e compilare i driver
necessari al funzionamento della scheda, sono indispensabili i seguenti software:
•
Mercurial: un sistema di controllo di revisione simile a CVS e Subversion. La
differenza rispetto questi ultimi due è che Mercurial è un sistema distribuito,
senza nessun repository centrale, ma con un database diverso per ogni
sviluppatore. Esso è necessario per ottenere i sorgenti aggiornati dei driver della
scheda DVB-T;
•
kernel-headers: sono i file header che servono per compilare i moduli esterni al
kernel;
•
build-esential: un pacchetto che contiene tutti i compilatori, come make e gcc,
che sono necessari per installare qualsiasi software dal codice sorgente.
54
Su Ubuntu, e comunque su tutte le altre distribuzioni basate su Debian, i pacchetti
necessari possono essere installati con il gestore dei pacchetti tramite il comando
$ sudo apt-get install mercurial linux-headers-$(uname –r)
build-essential
4.3.3 Procedura di installazione
Installati tutti i software richiesti, è possibile scaricare, dal sito LinuxTV, il codice
sorgente più recente dei driver v4l-dvb. Per farlo si deve utilizzare il programma appena
installato, Mercurial. Tramite il seguente comando, in pratica, si crea, nel file system
locale, un clone del repository di LinuxTV situato all’URL indicato:
$ hg clone http://linuxtv.org/hg/v4l-dvb
requesting all changes
adding changesets
adding manifests
adding file changes
added 6221 changesets with 16904 changes to 1238 files
Listato 4.2: Output di Mercurial
Dopo l’esecuzione del comando, che produrrà l’output descritto nel Listato 4.2, se tutto
è andato a buon fine verrà creata, nel percorso corrente, una directory chiamata v4l-dvb
con all’interno i sorgenti dei driver desiderati. Fatto questo bisogna entrare nella
directory appena creata e compilarli:
$ cd v4l-dvb
$
make
Infine vanno installati i driver, tramite il seguente comando e poi va riavviato il sistema:
$ sudo make install
Riavviata la macchina, per confermare che la scheda venga riconosciuta correttamente,
deve essere presente la directory /dev/dvb/adapter0 che deve contenere i file speciali
demux0, dvr0, frontend0, e net0, così come è definito nelle Linux DVB API (Paragrafo
2.3.2). Da notare che se sono state installate altre schede, la cifra finale della directory e
dei file non sarà 0 ma un altro numero consecutivo. La verifica può essere fatta
velocemente utilizzando il comando:
$ ls –l /dev/dvb/adapter*
55
Invece, per visualizzare un elenco delle periferiche hardware, con bus PCI, che sono
installate nel sistema, si utilizza il comando:
$ lspci –w
Con la macchina del laboratorio l’output è il seguente (Listato 4.3):
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX
AGP bridge (rev 03)
0000:00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA
(rev 02)
0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE
(rev 01)
0000:00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB
(rev 01)
0000:00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev
02)
0000:00:08.0 SCSI storage controller: Advanced System Products, Inc
ABP940-U / ABP960-U (rev 03)
0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8139/8139C/8139C+ (rev 10)
0000:00:0b.0 Multimedia controller: Philips Semiconductors SAA7133
Video Broadcast Decoder (rev d1)
0000:00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97]
(rev 08)
0000:01:00.0 VGA compatible controller: nVidia Corporation NV6
[Vanta/Vanta LT] (rev 15)
Listato 4.3: Lista delle periferiche PCI installate
Nell’elenco appare il decoder Philips SAA7133. In realtà questo non è proprio quello
della scheda Asus installata, ma viene dichiarato come un chip compatibile, dotato delle
stesse funzionalità del SAA7131E.
4.3.4 Il telecomando
Il segnale del telecomando della scheda in questione, viene ricevuto da un sensore
Infra-red che si collega direttamente ad essa, attraverso un connettore esterno. Per
questo motivo, una volta installata la periferica, il telecomando viene identificato
automaticamente. Per verificare il corretto riconoscimento si digita il comando:
$ dmesg | grep input
Durante l’avvio del sistema, il kernel annota, in un file di log, tutta una serie di
messaggi relativi alle operazioni effettuate ed alle periferiche riconosciute. Tramite il
comando dmesg vengono richiamati tutti questi messaggi prodotti dal kernel che sono
56
stati salvati in questo file di log. Dato che spesso dmesg produce una mole di dati molto
ampia, quando si cerca un’informazione specifica, si usa filtrarlo con il comando grep
seguito dalla parola chiave cercata. Questa operazione si effettua utilizzando il
metacarattere “|” (pipe), che ridirige lo standard output del comando a sinistra nello
standard input del comando a destra. Se tutto è corretto quindi, questi comandi in
cascata dovrebbero produrre il seguente output:
[17179597.008000] input: saa7134 IR (ASUSTek P7131 Hybri as
/class/input/input4
Questa stringa conferma che il telecomando è stato riconosciuto all’avvio del sistema.
Per un ulteriore conferma si può ricorrere al comando riportato nel Listato 4.4, che
analizza il contenuto del file dove vengono elencate tutte le periferiche di input del
sistema. Il comando deve produrre l’output indicato.
linuxbox@linuxbox-desktop:~$ cat /proc/bus/input/devices
[…]
I: Bus=0001 Vendor=1043 Product=4876 Version=0001
N: Name="saa7134 IR (ASUSTeK P7131 Hybri"
P: Phys=pci-0000:02:0b.0/ir0
S: Sysfs=/class/input/input4
H: Handlers=kbd event4
B: EV=100003
B: KEY=108c0322 2104000 0 0 0 0 10000 4180 801 9f16c0 0 0 10000ffc
Listato 4.4: Riconoscimento del telecomando
4.4 Fase di test
Installata correttamente la scheda, si procede con una fase di test, nella quale si effettua
anche la scansione dei canali che si possono ricevere. Questi saranno diversi a seconda
della copertura presente in zona.
Alcuni dei programmi utili per questa fase sono quelli già descritti precedentemente:
•
scan: per effettuare la scansione dei canali;
•
tzap: per effettuare il tuning e visualizzare alcune proprietà di ogni canale.
Dato che su Ubuntu, come già detto, i due sono mantenuti nel repository Universe, in
un pacchetto denominato dvb-utils, essi devono essere installati tramite il seguente
comando:
$ sudo apt-get install dvb-utils
57
4.4.1 Scan
L’utility scan, così come già descritto al Paragrafo 2.5.1, non effettua una scansione
automatica dei canali che possono essere ricevuti ma necessita di un file delle frequenze
di base, contenente la lista dei MUX disponibili. Questi file iniziali sono specifici a
seconda della locazione geografica in cui ci si trova perché contengono le informazioni
sulle stazioni più vicine che trasmettono il segnale DVB-T. Essi, per molte località del
mondo, vengono forniti con il pacchetto dvb-apps ma la posizione esatta dove questi
vengono installati può variare a seconda della versione del pacchetto e della
distribuzione di Linux utilizzata. In questo caso, con Ubuntu 6.06 LTS, il percorso è il
seguente:
/usr/share/doc/dvb-utils/examples/scan/dvb-t
Il nome di questi file ha un formato standard, del tipo xx-Yyyyy. In questa stringa, i
primi due caratteri rappresentano un’abbreviazione, di due lettere, del paese a cui si
riferisce il file, mentre Yyyyyy è il nome della località dove è collocato il trasmettitore.
Va detto però, visto che sono presenti file per tutto il mondo, che molto probabilmente
quello per la località desiderata o non esisterà per niente o comunque risulterà
incompleto. I file già presenti infatti costituiscono soltanto un esempio di come
strutturare il file. Per la città di Ancona, il file delle frequenze iniziali esiste, con il nome
di it-Conero. Questo però, contiene soltanto poche righe e dovrà quindi essere ampliato
e corretto, in caso risultassero dati errati.
Per creare un file per lo scanning, si possono utilizzare le informazioni riguardanti la
copertura del digitale terrestre, contenute nel sito http://www.dgtvi.it. L’associazione
DGTVi è costituita da aziende come Rai, Mediaset e Telecom Italia Media, al fine di
cooperare per promuovere tutte le iniziative che riguardano il digitale in Italia. Nel loro
sito, come si vede in Figura 4.5, si può trovare una lista, divisa per province e comuni,
delle frequenze in MHz dei principali canali televisivi. Inoltre viene indicata anche la
copertura ed il sito di trasmissione.
58
Figura 4.5: Il sito DGTVi
Attraverso il file già esistente e le informazioni prese da questo sito, è stato creato il file
relativo al comune di Ancona. Il contenuto di questo file, chiamato it-Ancona, è il
seguente (Listato 4.5):
#
T
T
T
MUX DFREE
674000000
722000000
842000000
(Rete 4,Italia1,SportItalia,LCI,RadioItalia Tv)
8MHz 2/3 1/2 QAM64 8k 1/32 NONE
8MHz 2/3 1/2 QAM64 8k 1/32 NONE
8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX LA7/MTV (La 7,MTV ITALIA,Canale D,Music Box)
T 802000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
T 226500000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX MEDIASET1 (Canale 5,Class News,Sole 24 Ore TV,BBC
World,Boing,Mediashopping)
T 522000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
T 490000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX MEDIASET2 (Canale 5,Class News,24 Ore TV,Coming Soon,BBC World)
T 554000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
59
# MUX-A RAI (Rai uno, Rai due, Rai tre, Rai utile)
T 706000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX-B RAI (Rai Doc,RaiSportSAT,RaiNews24,Rai EDU1)
T 219500000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
T 474000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX QOOB (Qoob,La 7,MTV)
T 666000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX RTV38 (Rtv38,38 news,Rtl102.5)
T 177500000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
T 194500000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX ALLMUSIC (AllMusic,RepubblicaTv,RadioDeejay)
T 618000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
# MUX TV LOCALI
T 698000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
T 770000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
T 786000000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE
Listato 4.5: File delle frequenze iniziali per lo scan
Va subito notato che ogni MUX di canali può avere più di una frequenza. Questo
perché, nel comune in cui ci si trova, si possono captare segnali che provengono da siti
di trasmissione diversi oppure perché vengono utilizzate dallo stesso multiplex due tipi
di bande: UHF e VHF.
Ora, dopo aver collegato la scheda TV all’antenna, si può incominciare con la scansione
dei canali digitando il seguente comando:
$ scan it-Ancona > channels.conf
In questo modo la procedura produrrà in output un file di testo, chiamato channels.conf,
contenente la lista dei canali per ogni MUX disponibile, completa dei relativi parametri.
Questo file sarà poi utilizzato, da altri programmi, per sintonizzare il canale desiderato.
Non è conveniente, almeno durante la fase di scansione, utilizzare l’antenna portatile
fornita in dotazione con la scheda; questo tipo di antenne infatti è spesso inadeguato e
non consente una ricezione corretta del segnale. E’ preferibile invece collegare la
scheda TV ad una presa a muro domestica; in questo modo sarà più probabile che
vengano riconosciuti tutti i canali disponibili nella zona.
Lo scan, mentre tenta di trovare i canali dalle frequenze del file iniziale, produce un
copioso output nella shell:
60
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 674000000 0 2 1 3 1 0 0
>>> tune to:
674000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSM
ISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to:
ISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed)
>>> tune to:
>>> tune to:
>>> tune to:
0x0384 0x000b: pmt_pid 0x0120 Mediaset -- Rete 4 (running, scrambled)
0x0384 0x000c: pmt_pid 0x0121 (null) -- Italia 1 (running, scrambled)
0x0384 0x000d: pmt_pid 0x0122 (null) -- Teleradio Padre Pio (running,
scrambled)0x0384 0x000e: pmt_pid 0x0123 (null) -- Sportitalia
(running, scrambled)
0x0384 0x000f: pmt_pid 0x0124 (null) -- Si Live 24 (running,
scrambled)
0x0384 0x0010: pmt_pid 0x0125 (null) -- S16 (running)
0x0384 0x03e7: pmt_pid 0x0063 (null) -- DV (running)
Network Name 'Mux DFree'
>>> tune to:
61
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
WARNING: filter timeout pid 0x0011
>>> tune to:
>>> tune to:
>>> tune to:
0x0389 0x0015: pmt_pid 0x0100 Mediaset -- Canale 5 (running,
scrambled)
0x0389 0x0017: pmt_pid 0x0102 Mediaset -- Class News (running,
scrambled)
0x0389 0x0018: pmt_pid 0x0103 Mediaset -- Coming Soon (running)
0x0389 0x0019: pmt_pid 0x0104 Mediaset -- BBC World (running)
0x0389 0x001a: pmt_pid 0x0105 (null) -- Mediashopping (running,
scrambled)
0x0389 0x001b: pmt_pid 0x0106 (null) -- Sportitalia (running,
scrambled)
0x0389 0x001c: pmt_pid 0x0107 (null) -- SI Live 24 (running,
scrambled)
0x0389 0x001d: pmt_pid 0x0020 (null) -- s9 EI (running)
0x0389 0x001e: pmt_pid 0x0021 (null) -- s10 EI (running)
Network Name 'Mediaset2'
>>> tune to:
0x0001 0x0d49: pmt_pid 0x0000 RAI -- RaiUno (running)
62
0x0001 0x0d4a: pmt_pid 0x0000 RAI -- RaiDue (running)
0x0001 0x0d4b: pmt_pid 0x0000 RAI -- RaiTre (running)
0x0001 0x0d52: pmt_pid 0x0000 RAI -- RaiUtile (running)
0x0001 0x0cf2: pmt_pid 0x0000 Rai -- FD LEGGERA (running)
0x0001 0x0d7b: pmt_pid 0x0000 Rai -- Rai HD 1 (not running)
0x0001 0x0d7c: pmt_pid 0x0000 Rai -- Rai HD 2 (not running)
0x0001 0x0d7d: pmt_pid 0x0000 Rai -- Rai HD 3 (not running)
0x0001 0x0d7e: pmt_pid 0x0000 Rai -- Rai HD 4 (not running)
0x0001 0x0d7f: pmt_pid 0x0000 Rai -- Rai HD 5 (not running)
0x0001 0x0d80: pmt_pid 0x0000 Rai -- Rai HD 6 (not running)
0x0001 0x0d79: pmt_pid 0x0000 Rai -- Rai Test 1 (not running)
0x0001 0x0d7a: pmt_pid 0x0000 Rai -- Rai Test 2 (not running)
WARNING: filter timeout pid 0x02bc
WARNING: filter timeout pid 0x02c6
WARNING: filter timeout pid 0x02be
WARNING: filter timeout pid 0x02bb
WARNING: filter timeout pid 0x02bf
WARNING: filter timeout pid 0x02bd
Network Name 'Rai'
>>> tune to:
>>> tune to:
>>> tune to:
474000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QPSK:TRANSMIS
SION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
>>> tune to:
474000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QPSK:TRANSMIS
SION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE (tuning failed)
>>> tune to:
>>> tune to:
63
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
>>> tune to:
dumping lists (35 services)
Done.
Listato 4.6: Output del programma Scan
64
Osservando l’output del comando si può notare che all’inizio vengono fornite alcune
informazioni sui transponder utilizzati, poi il programma inizia ad analizzare tutte le
frequenze una per una. Per ogni frequenza esaminata, se la scansione fallisce viene
visualizzato un avvertimento (WARNING:>>>tuning failed!!!). Lo scan però non si
interrompe e la ricerca viene ripetuta una seconda volta. Se questa fallisce di nuovo si
passa ad analizzare la frequenza successiva. Se invece lo scanning ha successo viene
elencata una lista dei canali trovati completa di PID, nome del canale e nome del
network che li trasmette. Alla fine, il file di configurazione che si ottiene è quello
indicato nel Listato 4.7:
Rete
4:842000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:513:660:11
Italia
Teleradio Padre
Pio:842000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TR
ANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:514:670:13
Sportitalia:842000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:515:680:
14
Si Live
24:842000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRA
NSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:526:790:15
S16:842000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TR
DV:842000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRA
Canale
Class
News:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:T
RANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:514:670:23
Coming
Soon:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:T
RANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:515:680:24
BBC
World:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:
TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:516:690:25
Mediashopping:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2
:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:517:70
65
0:26
Sportitalia:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:Q
AM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:518:710:
27
SI Live
s9
EI:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRA
s10
EI:554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRA
RaiUno:706000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64
:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:512:650:3401
RaiDue:706000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64
RaiTre:706000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64
RaiUtile:706000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_
64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:523:604:341
0
FD
LEGGERA:706000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_6
4:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:673:3314
Rai HD
Rai HD
Rai HD
Rai HD
Rai HD
Rai HD
Rai HD
Rai HD
Rai HD
66
Rai HD
Rai Test
Rai Test
Listato 4.7: File channels.conf
Il formato del file channels.conf è stato descritto anch’esso al Paragrafo 2.5.1, dove
viene data anche una breve spiegazione dei valori fondamentali che lo costituiscono.
C’è da segnalare che, uno o entrambi i campi che riguardano il PID dell’audio e del
video di un canale potrebbe assumere il valore zero. Questo è quello che accade ad
esempio per tutti i canali Rai HD e Rai Test. Le cause di questo comportamento sono da
imputare a tre cause, diverse a seconda di quale dei PID vale zero:
•
se il PID video è 0 mentre il PID audio è diverso da zero, significa che molto
probabilmente si tratta di un canale radiofonico. Questo è quello che accade per i
PID di FD Leggera che infatti è proprio una radio;
•
se al contrario è il PID audio ad essere a 0 significa che lo scan ha dei problemi
ad individuare il flusso audio del rispettivo canale. Questo accade spesso,
probabilmente a causa di un bug all’interno del programma, quando l’audio del
canale viene trasmesso in formato AC3 anziché MPEG. In questo caso è
necessario modificare manualmente il file channels.conf;
•
se entrambi i PID sono pari a zero invece vuol dire che lo scan ha rilevato un
segnale troppo debole per la ricezione oppure che si tratta di un canale di test o
non ancora utilizzato. In pratica il canale è presente nella tabella PAT dei servizi
trasmessi ma non ha associato nessun flusso audio e video.
4.4.2 Zap
Il programma zap, o più precisamente tzap per il DVB-T, già introdotto nel Paragrafo
2.5.2, serve per effettuare la sintonizzazione dei canali televisivi e l’analisi delle
caratteristiche del segnale. Come già accennato, per funzionare con successo il
programma ha bisogno del file di configurazione dei canali (channels.conf). Questo,
67
dopo essere stato creato dall’utility scan, deve essere collocato dentro la directory
nascosta contenuta nella home e chiamata .tzap:
$ mkdir ~/.tzap
$ cp channels.conf /.tzap/
Una volta fatto questo il programma è pronto all’uso. Per farlo partire basta digitare il
comando tzap seguito dal nome del canale che si vuole esaminare.
4.4.3 Prove di sintonizzazione dei canali
In questo paragrafo viene analizzata la qualità del segnale di due emittenti televisive,
utilizzando le informazioni fornite dal programma tzap. I due canali in questione sono
Rete 4 e Repubblica TV. Il primo fa parte del MUX di trasmissione chiamato Dfree,
caratterizzato da una copertura attuale molto ampia, pari a circa il 73%. Il secondo
invece fa parte del MUX All Music, con una copertura molto minore.
Figura 4.6: Rete4 e Repubblica TV
linuxbox@linuxbox-desktop:~$ tzap 'rete 4'
tuning to 842000000 Hz
video pid 0x0201, audio pid 0x0294
status 00|signal 9494|snr 4949|ber 0001fffe|unc 00000000|
status 1f|signal 9393|snr fefe|ber 00000036|unc 00000047| FE_HAS_LOCK
status 1f|signal 9393|snr fefe|ber 0000003c|unc 00000000| FE_HAS_LOCK
status 1f|signal 9292|snr fefe|ber 0000004c|unc 00000000| FE_HAS_LOCK
linuxbox@linuxbox -desktop:~$ tzap 'repubblica tv'
video pid 0x1f42, audio pid 0x1f43
68
status 00|signal 8f8f|snr 8888|ber 0001fffe|unc
status 1f|signal 8e8e|snr 9a9a|ber 0001fffe|unc
status 0d|signal 8f8f|snr 6767|ber 0001fffe|unc
status 1f|signal 8e8e|snr f3f3|ber 00011a30|unc
status 1f|signal 8e8e|snr f1f1|ber 000120de|unc
status 1f|signal 8e8e|snr f1f1|ber 000123a0|unc
Listato 4.8: Confronto tra i canali Rete4 e Repubblica TV
00000000|
ffffffff|
ffffffff|
ffffffff|
ffffffff|
ffffffff|
FE_HAS_LOCK
FE_HAS_LOCK
FE_HAS_LOCK
FE_HAS_LOCK
Dalla visione dei due canali (vedi Figura 4.6) risulta subito evidente la differenza che
esiste rispetto alla qualità del segnale ricevuto. I dati provenienti da tzap (Listato 4.8), in
pratica, confermano questa impressione. Rete 4, rispetto a Repubblica TV, presenta dei
valori più alti per quanto riguarda la forza del segnale. Questi però, come già spiegato
precedentemente, non sono sufficienti a stabilire la reale qualità del segnale poiché un
valore “8f8f”, fatto segnare da Repubblica TV, potrebbe anche essere considerato
buono. Analizzando poi il rapporto S/N, la differenza tra i due canali si fa più marcata.
Il secondo inoltre presenta anche dei valori oscillatori mentre Rete 4 invece è stabile.
Per quanto riguarda il tasso di errore, il primo canale analizzato presenta dei valori
molto bassi mentre il secondo è afflitto da un tasso di qualche ordine di grandezza più
elevato. Significativo infine, è il numero di blocchi non corretti che nel caso di Rete 4 è
pari a zero mentre Repubblica TV raggiunge il fondo scala.
Per valutare le capacità di ricezione dell’antenna portatile omnidirezionale, fornita a
corredo con la scheda, è stata effettuata un’altra prova con tzap. Il canale sintonizzato è
sempre Rete 4 ma questa volta si è utilizzata questa antenna anziché la classica presa a
muro. Il risultato finale, come si evince confrontando i dati forniti da tzap (vedi Listato
4.9), è inequivocabile. Il segnale di Rete 4, che prima risultava più che buono, con
l’antenna portatile è in pratica non sintonizzabile. Esso, infatti, presenta dei valori anche
peggiori del segnale di Repubblica TV, ma soprattutto accade che il frontend della
scheda non riesce a sintonizzarsi ed a bloccare il segnale.
linuxbox@linuxbox-desktop:~$ tzap 'rete 4'
video pid 0x0201, audio pid 0x0294
status 00|signal 7878|snr 3f3f|ber 0001fffe|unc 00000000|
status 1f|signal 7777|snr f7f7|ber 00019fa0|unc ffffffff| FE_HAS_LOCK
status 01|signal 7676|snr 4a4a|ber 0001f002|unc ffffffff|
status 1f|signal 7777|snr f7f7|ber 0001a1ec|unc ffffffff| FE_HAS_LOCK
status 00|signal 7575|snr 6464|ber 0001fffe|unc 00000000|
status 1f|signal 7575|snr f6f6|ber 0001b78a|unc ffffffff| FE_HAS_LOCK
Listato 4.9: Parametri del segnale ricevuto con antenna portatile
69
4.5 Visualizzazione della TV
Dopo che la scheda è stata installata correttamente e che la fase di test è andata a buon
fine, si può finalmente usufruire della scheda TV per la visione dei canali televisivi in
digitale. Per farlo è necessario un player multimediale corredato con le relative librerie
per la gestione e la decodifica del Transport Stream MPEG-2. Tra i vari software a
disposizione è stato scelto Gxine. Questo, in realtà, è solo un frontend grafico basato su
Gnome del software xine, un riproduttore multimediale per Linux rilasciato sotto la
licenza GNU General Public Licence. Xine supporta l’esecuzione di CD audio, VCD,
DVD e la maggior parte dei formati audio e video disponibili. Il programma è costituito
principalmente dalla libreria condivisa chiamata xine-lib, alla quale poi si appoggia la
maggior parte dei frontend grafici diffusi per il sistema operativo Linux. Questo player
è stato scelto perché, oltre alla riproduzione dei filmati, esso consente di utilizzare la
scheda TV per la visualizzazione dei vari canali televisivi.
Figura 4.7: Finestra di Gxine con relativa Playlist
4.5.1 Impostazione di Gxine
Innanzitutto si deve precisare che Gxine non implementa ne gestisce nessuna scansione
per la ricerca dei canali televisivi. Per funzionare necessita invece del file channels.conf,
quello creato in precedenza tramite l’utility scan (vedi Paragrafo 4.4.1). Da questo file
Gxine ricava i PID dei programmi televisivi e tramite le sue librerie (xine-lib)
decodifica il segnale MPEG-2 proveniente dalla scheda. Il file, per essere individuato
correttamente, deve essere posto nella directory di default del programma. Da shell,
posizionandosi nel percorso dove è stato creato il file di configurazione, per copiare il
file nel percorso giusto si può digitare il comando
70
$ cp channels.conf ~/.xine
In seguito, per iniziare la visione della televisione digitale, una volta avviato il player
Gxine, è sufficiente selezionare, dal menu File, l’opzione DVB. A questo punto inizia la
riproduzione dell’ultimo canale che era stato visto in precedenza, o in alternativa, il
primo canale nella lista di channels.conf. Per avviare più rapidamente la riproduzione
del segnale DVB-T in Gxine, è possibile utilizzare questo semplice comando:
$ gxine -f ‘dvb:RaiUno’
Con questo il player inizia la riproduzione, a pieno schermo, del canale desiderato, in
questo caso RaiUno. Se invece si vuole sintonizzare l’ultimo programma visto in
precedenza, è possibile omettere dal comando il nome del canale. Associando questo
comando ad una icona del Desktop è possibile, con un solo click, iniziare la visione
della TV digitale terrestre. Un’altra soluzione è invece quella di indicare questo
programma come uno dei servizi da eseguire all’avvio del sistema.
4.5.2 Uso del telecomando
Per poter utilizzare il telecomando con Gxine è necessario accedere alla schermata di
configurazione delle scorciatoie, attraverso il menu File/Configura…, ed impostare i
comandi desiderati. Il telecomando fornito con la scheda ASUS non è del tutto
supportato. Esso infatti presenta dei tasti specifici che funzionano soltanto con il
software a corredo con la scheda. I comandi principali invece, come ad esempio le
quattro frecce direzionali ed il pulsante Enter, vengono riconosciuti senza alcun
problema. Impostare il telecomando è importante perché Gxine implementa un menu di
scelta dei canali che appare in sovraimpressione sullo schermo quando si preme la
freccia avanti o indietro. In questo modo, per cambiare canale, non è necessario aprire
ogni volta la finestra di playlist. Questo menu infatti può essere gestito comodamente
con il telecomando.
71
Figura 4.8: Menu in sovraimpressione di Gxine
4.5.3 Registrazione della TV
Uno dei vantaggi di avere un sistema per la ricezione della televisione digitale terrestre,
integrato in un PC è proprio la presenza di un Hard Disk. Questo può essere sfruttato
infatti per registrare i programmi desiderati. Come già detto precedentemente, l’utility
tzap è in grado di poter ridirigere l’output della scheda alla periferica virtuale dvr, che
viene poi utilizzata per la registrazione. Ad esempio, per registrare quello che viene
trasmesso in questo momento su Raiuno è sufficiente digitare:
$ tzap -r
‘RaiUno’
In questo modo, grazie all’opzione “-r”, si abilita lo stream nella periferica dvr di
default, individuata dal file /dev/dvb/adapter0/dvr0. Per registrare il flusso si utilizza poi
il comando:
$ cp /dev/dvb/adapter0/dvr0 Raiuno.ts
A questo punto il programma viene salvato nel file indicato della directory corrente.
Come estensione del file si è scelto di scrivere “.ts” per indicare che si tratta di un
Transport Stream ma in realtà è possibile anche omettere questa dicitura. Per
interrompere la registrazione è sufficiente premere la combinazione di tasti Ctrl+C.
L’utility tzap in realtà non fornisce molte funzionalità ma effettua correttamente i
compiti per cui è stato progettato, senza un eccessivo dispendio di risorse.
Un altro software in grado di registrare la TV su disco rigido è Dvbstream. Esso è
presente nel repository Universe di Ubuntu quindi è facilmente ottenibile grazie al
72
gestore dei pacchetti APT. Una volta installato, il programma si esegue tramite la linea
di comando. Per la registrazione del canale, in questo caso, è necessario conoscere i
parametri di modulazione e i valori del PID video ed audio del canale a cui si è
interessati. Il funzionamento di questo software può essere riassunto dal seguente
comando di base:
$ dvbstream -f “frequenza canale” -tm 8 “PID video” “Pid
audio” -o > “nome file”
A questo vanno poi sostituiti di volta in volta i vari parametri specifici del programma
TV desiderato. Per quanto riguarda la modulazione, i valori adottati in Italia
corrispondono a tutti quelli che il programma considera di default, eccetto il modo di
trasmissione che deve essere infatti specificato esplicitamente (-tm 8). Una volta che
tale comando è stato digitato, Dvbstream si occupa del settaggio del frontend e, una
volta ricevuto il valore FE_HAS_LOCK, inizia la registrazione.
4.6 Analisi delle DVB-SI con Dvbsnoop
Grazie al programma descritto al Paragrafo 2.5.3, che consente di analizzare il flusso
digitale proveniente dalla scheda DVB, è possibile visualizzare e decodificare le DVB
Service Information. Queste sono tutte quelle tabelle, definite nello standard DVB-SI ed
illustrate al Paragrafo 1.4.3, che il DVB utilizza per decodificare il Transport Stream e
per veicolare alcune informazioni aggiuntive al flusso video ed audio. Per lo studio
pratico di questi flussi informativi si è utilizzato il programma Dvbsnoop per
decodificare gli stream trasmessi dal MUX-A della Rai. La scelta si è basata soltanto sul
fatto che questa rete digitale, in zona, è una delle migliori per quanto riguarda la qualità
di ricezione. Dato che, come già detto in precedenza, Dvbsnoop non gestisce il settaggio
del frontend, questa operazione è stata effettuata grazie a tzap. In pratica, mentre
l’utility in questione sintonizzava uno dei canali facenti parte del MUX Rai, il TS
MPEG-2 in uscita dalla scheda è stato analizzato con Dvbsnoop.
Prima di tutto, per venire a conoscenza di quali flussi vengono trasmessi, è stata
effettuata una scansione di tutti i PID disponibili, tramite il seguente comando che ha
generato l’output del Listato 4.10:
$ dvbsnoop -s pidscan
73
--------------------------------------------------------Transponder PID-Scan...
--------------------------------------------------------PID found:
0 (0x0000) [SECTION: Program Association Table (PAT)]
PID found:
16 (0x0010) [SECTION: Network Information Table (NIT) actual network]
PID found:
17 (0x0011) [SECTION: Service Description Table (SDT) actual transport stream]
PID found:
18 (0x0012) [SECTION: Event Information Table (EIT) actual transport stream, present/following]
PID found:
20 (0x0014) [SECTION: Time Date Table (TDT)]
PID found:
21 (0x0015) [SECTION: ITU-T Rec. H.222.0|ISO/IEC13818
reserved]
PID found: 256 (0x0100) [SECTION: Program Map Table (PMT)]
PID found: 282 (0x011a) [SECTION: Program Map Table (PMT)]
PID found: 512 (0x0200) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or
ISO/IEC 11172-2 video stream]
PID found: 523 (0x020b) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or
PID found: 576 (0x0240) [PES: private_stream_1]
PID found: 589 (0x024d) [PES: private_stream_1]
PID found: 604 (0x025c) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3
audio stream]
PID found: 650 (0x028a) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3
audio stream]
PID found: 651 (0x028b) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3
audio stream]
PID found: 652 (0x028c) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3
audio stream]
PID found: 673 (0x02a1) [PES: ISO/IEC 13818-3 or ISO/IEC 11172-3
audio stream]
PID found: 2003 (0x07d3) [SECTION: DSM-CC- Download Data Messages DDB]
PID found: 2004 (0x07d4) [SECTION: DSM-CC- Download Data Messages DDB]
PID found: 2021 (0x07e5) [SECTION: DSM-CC- Download Data Messages DDB]
PID found: 2031 (0x07ef) [SECTION: DSM-CC- Download Data Messages DDB]
PID found: 3010 (0x0bc2) [SECTION: MHP- Application Information Table]
PID found: 3020 (0x0bcc) [SECTION: MHP- Application Information Table]
PID found: 3030 (0x0bd6) [SECTION: MHP- Application Information Table]
PID found: 3040 (0x0be0) [SECTION: MHP- Application Information Table]
Listato 4.10: Scansione dei PID con Dvbsnoop
74
La scansione è molto utile perché oltre a generare l’elenco dei PID trasmessi, fornisce
anche una descrizione di quello che ognuno di essi contiene, in modo che si possa
direttamente andare ad analizzare il flusso cercato. Il MUX-A Rai è quello che trasmette
i canali TV Raiuno, Raidue, Raitre, Rai Utile e il canale radio chiamato FD Leggera. Si
può notare infatti che tramite la scansione dei PID sono stati trovati cinque stream audio
e solo quattro stream video.
I flussi trovati sono di due tipi diversi: section e PES. Il primo tipo rappresenta le tabelle
informative del DVB e per decodificarle è necessario, con Dvbsnoop, utilizzare
l’opzione “-s sec”; in realtà non è necessario specificarla poiché questa è già l’opzione
predefinita. Per la decodifica invece dei PES MPEG-2 si utilizza l’opzione “-s pes”. In
seguito si sono analizzati alcuni di questi flussi, in modo da comprendere meglio la
struttura del DVB. Più in particolare, lo studio si è soffermato maggiormente sul canale
Raiuno, così da verificare i passaggi che, partendo dalla PAT, portano alla decodifica
del video e dell’audio di questo programma. Tutto l’output prodotto dal programma
Dvbsnoop, utilizzando i comandi indicati, lo si può trovare nell’Appendice.
4.6.1 Program Association Table
$ dvbsnoop 0
La Program Association Table (PAT) si trova sempre al PID numero zero. Questa
tabella elenca i programmi TV e i servizi presenti nel Transport Stream dopo che è stato
multiplexato. Per ognuno di questi viene fornito il riferimento, tramite indicazione del
PID, con cui recuperare la tabella dettagliata di ogni singolo canale, la PMT. Nella
PAT, lo standard vuole che il record numero zero indichi sempre il PID della tabella
NIT. Le righe seguenti invece sono libere e indicano i riferimenti per andare a trovare le
PMT dei canali trasmessi. La tabella PAT è indicizzata a seconda del
“Program_number”; per ognuno di questi è indicato il numero del PID. Il
“Program_number” è fondamentale poiché tutte le successive tabelle del DVB-SI
utilizzeranno questo numero per indicare a quale canale o servizio si riferiscono. Il
canale Raiuno ad esempio, è quello individuato dal numero 3401, a cui corrisponde la
tabella PMT che può essere filtrata dal TS attraverso il PID 258.
75
4.6.2 Network Information Table
$ dvbsnoop 16
La Network Information Table (NIT) si trova di norma al PID 16. Questa tabella
contiene tutte le informazioni che riguardano la rete in questione. Viene indicato il
nome del Network, in questo caso Rai, e tutti i parametri di modulazione che vengono
utilizzati. Per ognuno di questi parametri vengono impiegati due byte, che sono
caratterizzati da dei valori standard, in modo che possano essere facilmente decodificati.
Ad esempio, per quanto riguarda la costellazione, il valore esadecimale 0x00 significa
QPSK mentre 0x02 significa QAM64. In realtà non è necessario conoscere i valori
standard perché Dvbsnoop li decodifica automaticamente.
4.6.3 Service Description Table
$ dvbsnoop 17
La Service Description Table (SDT) elenca le informazioni riguardanti i singoli servizi
trasmessi. Nel MUX-A Rai si trova al PID 17. Questa tabella è indicizzata secondo il
“Service_ID”, che corrisponde al “Program_number” della PAT. Per ogni record viene
indicato il nome del fornitore ed il nome del servizio. Inoltre sono presenti ulteriori
informazioni sullo stato di servizio e sulla cifratura. Anche se prima era già stato detto
che la rete Raiuno era identificata dal numero 3401, questa informazione era stata
ottenuta analizzando già in precedenza la SDT. Solo in questa tabella infatti vengono
indicati i nomi dei canali, mentre nelle altre è indicato soltanto l’ID di servizio.
4.6.4 Event Information Table
$ dvbsnoop 18
La Event Information Table (EIT) contiene la programmazione degli eventi di ogni
singolo canale. Viene mostrato, in ordine cronologico, l’evento corrente, il prossimo, ed
altri eventi programmati. Per ognuno di essi è indicata la data e l’ora di inizio, la durata,
lo stato corrente, il nome dell’evento ed anche una breve descrizione opzionale. La EIT
viene spesso utilizzata da vari software del DVB-T per compilare la EPG (Electronic
Program Guide), la guida elettronica ai programmi. Questo tipo di informazioni di
servizio, dato che la mole di dati è più elevata, viene veicolata in modo diverso nel TS.
Le altre tabelle infatti vengono contenute interamente in un pacchetto che viene ripetuto
76
nello stream di trasporto ad intervalli regolari. La EIT invece è composta di un
pacchetto per ogni evento, quindi occorre più tempo prima che queste informazioni
vengano ripetute.
4.6.5 Time and Date Table
$ dvbsnoop 20
La Time and Date Table (TDT) indica semplicemente la data e l’ora correnti nel fuso
orario UTC (Coordinated Universal Time) che è il fuso orario di riferimento per tutti gli
altri fusi orari del mondo ed è calcolato mediante orologi atomici. Nel caso in questione
(vedi Appendice) indica le 08:45 UTC del 17 settembre 2007, cioè le 10:45 dell’ora
italiana, poiché il fuso orario nazionale è UTC+1 ed inoltre in questo periodo è in vigore
l’ora legale.
4.6.6 Program Map Table
$ dvbsnoop 258
La Program Map Table (PMT) contiene la lista degli Elementary Stream che
compongono un singolo canale. La PMT individuata dal PID 258 ha il
“Program_number” 3401; questo indica che si tratta della tabella di Raiuno. Di seguito
vengono elencati tutti gli stream relativi a questo canale: audio, video e dati. Per ognuno
di questi, oltre al PID, vengono dati anche alcuni parametri caratteristici, diversi a
seconda del tipo di segnale. Ad esempio, per il flusso video viene indicato il tipo di
codifica mentre per il flusso audio viene indicata la lingua. Da questa tabella è stata
prelevata l’indicazione di quali stream andare ad analizzare in seguito; questo per
studiare sempre il canale Raiuno.
4.6.7 Private stream
$ dvbsnoop -s pes 576
Il PID 576, identifica uno stream privato che è stato identificato, grazie alla PMT, come
il flusso che trasporta le informazioni sul teletext. In questo caso, dato che questi
pacchetti non contengono tabelle di servizio, vanno codificati con l’opzione “-s pes”. Il
flusso del televideo viene decodificato riga per riga. Per ognuno di esse, oltre ai dati veri
e propri, vengono indicate anche le informazioni sul numero di pagina, di sezione e
77
l’offset della riga di cui i dati fanno parte. La pagina del televideo in Figura 4.9 è quella
che corrisponde ai dati nell’appendice.
Figura 4.9: Pagina del televideo
4.6.8 Application Information Table
$ dvbsnoop 3010
La MHP - Application Information Table (AIT) viene utilizzata dal ricevitore per
gestire l’interattività, attraverso lo standard DVB-MHP. Questa tabella fornisce
informazioni utili per amministrare le applicazioni che vengono trasmesse attraverso il
protocollo DSM-CC. Vengono infatti indicate quali sono le Xlet che devono essere
avviate per prime e la loro posizione nel file system. In questo modo si possono
identificare i moduli del carosello che devono essere presi in considerazione. Ad
esempio, in quello che è stato acquisito con Dvbsnoop (vedi Appendice) viene indicata,
come classe iniziale, quella situata nella directory /ApplicationManager con il nome
tv.simple.launcher.Launcher. A questa viene inoltre associato il parametro di autostart,
cioè di avvio automatico alla sintonizzazione del canale.
4.6.9 Conditional Access Table
La Conditional Access Table (CAT) è la tabella che viene utilizzata per l’accesso
condizionato ai servizi. Essa in pratica fornisce alcune informazioni sul tipo di cifratura
utilizzato per codificare il flusso audio e video di un canale a pagamento. Inoltre,
78
contiene i riferimenti ad altri PID in cui è possibile trovare i dati necessari alla
decodifica del segnale. Il Transport Stream della Rai, dato che trasmette tutti i suoi
canali in chiaro, non contiene la tabella CAT. Per riuscire a studiarne una è stato
analizzato il MUX Mediaset. Nella CAT di quest’ultima viene indicato, come sistema di
codifica, il “Kudelski SA”. Questo è il nome di un gruppo leader nel settore della
codifica del segnale per la TV digitale terrestre. I suoi prodotti per l’accesso
condizionato vengono anche chiamati Nagra o Nagravision e sono proprio quelli
utilizzati da Mediaset per l’offerta dei canali premium.
4.7 Cenni di interattività
Come è stato visto nel Paragrafo 4.6.8, tra le varie informazioni che vengono trasmesse
attraverso il Transport Stream, sono presenti anche quelle che riguardano le applicazioni
interattive MHP. Attraverso un’applicazione open source chiamata Dvbdata, creata da
Richard Palmer e rilasciata sotto licenza GNU General Public License, è possibile
analizzare questo tipo di dati. Questa, per funzionare correttamente, necessita di una
libreria chiamata Libdsmcc, utile per la gestione del carosello DSM-CC. I sorgenti di
questa applicazione, si possono trovare al sito http://sourceforge.net/projects/libdsmcc/,
divisi in due pacchetti, uno contenente la libreria Libdsmcc e l’altro l’applicazione vera
e propria. Una volta scaricati, va prima decompresso l’archivio contenente i file della
libreria, in modo da formare la directory libdsmcc. La libreria deve poi essere compilata
tramite il comando make. Una volta terminato, va decompresso anche l’altro pacchetto,
quello chiamato dvbdata.tar.gz. A questo punto, prima di compilare anche questo, va
copiato il file libdsmcc.a, creato con la precedente operazione di make, all’interno della
directory dvbdata.
La parte di codice che si occupa del settaggio del frontend della scheda è lo stesso del
programma chiamato Dvbstream, descritto al Paragrafo 4.5.3; quindi per i parametri di
modulazione ci si può riferire direttamente a quello. La differenza consiste nel fatto che,
mentre Dvbstream richiedeva il PID video ed audio del canale, in questo caso Dvbdata,
per riconoscere il flusso DSM-CC, necessita dell’ID di servizio del canale. Questo
parametro può essere ottenuto analizzando le DVB-SI con Dvbsnoop (vedi paragrafo
4.6) oppure, più semplicemente, lo si può ricercare nel file channels.conf creato con la
utility scan (al Paragrafo 4.5.1). Questo parametro è l’ultimo valore che viene indicato
79
per ogni canale. Se, per esempio, si vuole acquisire il file system dell’MHP di Raiuno,
basta digitare il comando indicato nella prima riga del Listato 4.11.
$ ./dvbdata -f 706000 -tm 8 -pnr 3402 -n "RAI2"
Using DVB card "Philips TDA10046H DVB-T"
tuning DVB-T (in United Kingdom) to 706000000 Hz
polling....
Getting frontend event
FE_STATUS:
polling....
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Bit error rate: 1606
Signal strength: 34695
SNR: 65021
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Listato 4.11: Output del programma Dvbdata
Il programma, dopo aver settato correttamente la scheda, trova il flusso DSM-CC e
salva il file system trasmesso all’interno della directory temporanea /tmp/cache/RAI1.
Questi file verranno cancellati all’arresto del sistema, quindi, per conservarli, è
necessario effettuare una copia in un altro percorso del file system. Analizzando quello
che è stato acquisito, si nota una struttura ad albero composta principalmente da classi
java, file xml ed immagini. Le prime rappresentano proprio il codice delle applicazioni
interattive mentre gli altri file costituiscono tutte le informazioni di supporto ad esse.
Una volta ottenute, queste applicazioni necessitano, per poter funzionare, di un software
che gestisca le Xlet.
XleTView è un emulatore che consente di vedere le Xlet MHP utilizzando un normale
PC. Il software, sviluppato da Martin Sveden, viene rilasciato sotto licenza GNU
General Public License ed è scaricabile al sito http://xletview.sourceforge.net/, dove si
possono trovare sia i sorgenti che il programma già compilato. Dato che XleTView è
scritto in linguaggio Java, è indispensabile che nella macchina sia installata una JVM
(Java Virtual Machine) versione 1.4 o superiore. Questa, dato che è presente nel
repository di Ubuntu, può essere direttamente installata attraverso il gestore dei
pacchetti APT.
80
Una volta che il pacchetto compresso xletview-0.3.6.zip è stato scaricato, per far partire
il programma è sufficiente, da shell, posizionarsi nella directory dove l’archivio è stato
decompresso e digitare il seguente comando:
$ java -jar xletview.jar
A questo punto il programma va in esecuzione mostrando una finestra costituita da una
schermata vuota ed un telecomando (vedi Figura 4.10). Per poter eseguire una Xlet, si
accede al menu Applications/Manage applications e si inseriscono le Xlet da eseguire,
complete di nome e percorso. Poi si lancia l’applicazione desiderata selezionandola dal
menu Applications. Quando la Xlet viene avviata, oltre a quello che appare nella
schermata del programma, può produrre anche dell’output di servizio nella shell.
XleTView non è un implementazione né certificata né completa dell’MHP. Questo può
produrre numerosi problemi in quanto non emula fedelmente tutte le funzionalità che
può avere un set-top box, causando la generazione di numerosi errori ed eccezioni. Di
fatto non è garantito che una applicazione completa, scaricata attraverso la rete
broadcast, possa funzionare correttamente su questa piattaforma.
Figura 4.10: Finestra di XleTView
81
Capitolo 5: Conclusioni
5.1 Requisiti minimi
Quando si progetta un sistema minimale, la scelta dei componenti hardware giusti
diventa fondamentale. Risulta quindi necessario conoscere i requisiti minimi per far sì
che tutto funzioni in maniera ottimale. La distribuzione di Linux scelta, Ubuntu 6.06
LTS Desktop, in se per se non è un problema significativo. Questa infatti richiede
soltanto un processore a 400 MHz, 256 Mbyte di RAM ed un Hard Disk con almeno 3
GB liberi. Tale configurazione, risulta abbastanza economica se si considera che la
Microsoft dichiara, come requisiti minimi per il nuovo Windows Vista, un processore a
1GHz, 1 GB di RAM e 15 GB liberi nell’Hard Disk.
Ciò che invece innalza le richieste minime di hardware è la periferica per la TV. La
scheda scelta, infatti, la ASUS My Cinema-P7132 Hybrid, è una scheda di tipo budget
che quindi, come già affermato in precedenza, non gestisce la decodifica del TSMPEG2. Questo sposta un carico maggiore verso la CPU, che deve riuscire a
decodificare lo streaming in tempo reale per la visualizzazione. Per riuscire a gestire un
flusso medio di 5 Mbit al secondo, una CPU a 400 MHz non è sufficiente. Quindi, per
quanto riguarda il processore, i requisiti dichiarati dalla comunità di Ubuntu non sono
più da considerare minimi per un sistema di decodifica del DVB-T.
Consultando il manuale del produttore, i requisiti della scheda ASUS che vengono
dichiarati risultano particolarmente elevati. Viene infatti raccomandato l’utilizzo di un
processore Pentium 4 a 2.6 GHz, 256 MB di memoria di sistema ed una scheda video
con almeno 32 MB di memoria. Questi però sono riferiti all’utilizzo della scheda con il
sistema operativo Windows XP, quindi non corrispondono necessariamente a ciò che è
veramente indispensabile in un sistema Linux minimale. Purtroppo però non viene data
nessun’altra indicazione per quanto riguarda ambienti di lavoro alternativi.
Per ottenere maggiori risposte è stata effettuata una ricerca sui requisiti di sistema
dichiarati da altri produttori di schede TV analoghe. Il risultato, che viene qua di seguito
riportato, risulta interessante:
82
•
La Hauppauge dichiara che per la scheda WinTV-NOVA-T PCI è sufficiente un
Processore Pentium 3 a 733 MHz con 64 MB di RAM. Questa scheda ha però
un chip diverso, il Conexant cx2388x, ma con funzionalità analoghe. Per la
WinTV-HVR-1100, che è come la ASUS una scheda ibrida, le caratteristiche si
innalzano, per quanto riguarda il processore, a 1.5 GHz per la visione e
registrazione del DVB-T e fino a 2.8 GHz per la TV analogica.
•
La TechnoTrend TT-Budget T-1500 richiede anch’essa una CPU a 733 MHz. In
questo caso il risultato è ancora più significativo perché i dispositivi integrati
nella scheda sono il Philips SAA7146 e TDA10046H, che risultano
praticamente compatibili a quelli della ASUS. Per la TV ad alta definizione è
invece raccomandata una CPU a 2,4 GHz.
•
La scheda Compro VideoMate DVB-T 200, con chipset analogo alla scheda
adottata, richiede, per la visualizzazione della TV, un processore da 600 MHz e
128 MB di RAM. Viene però sottolineato che per altre attività, come la
registrazione del segnale analogico in qualità DVD, i requisiti per la CPU
salgono fino ad una velocità di 1.7 GHz.
•
Tutti gli altri produttori invece dichiarano requisiti più elevati di quelli elencati
finora.
Una volta analizzati questi dati, si può facilmente affermare che i requisiti dichiarati
dall’ASUS sono troppo elevati e non rispecchiano la realtà di un sistema Linux
minimale. Essi possono però in parte essere giustificati dal fatto che la periferica My
Cinema-P7131H è una scheda ibrida e che quindi sono necessarie maggiori risorse per
gestire la tv analogica e l’acquisizione del video.
Un ulteriore dato sui requisiti minimi lo si può ricavare dalla macchina utilizzata per il
progetto. Questa è costituita (vedi Paragrafo 4.1.1) tra le altre cose, da un processore
Pentium 3 a 600 MHz. Durante la riproduzione, con segnale DVB-T buono, è stato
monitorato un carico medio della CPU di circa il 90%, che corrispondeva però ad una
decodifica video fluida, visivamente accettabile per la fruizione della televisione.
Inoltre, la memoria occupata dal sistema, durante la riproduzione, è risultata di 130 MB
ma, di questi, solo 42 MB vengono occupati dal processo Gxine, il player multimediale
utilizzato.
83
Considerato ciò che viene dichiarato dai maggiori produttori ed analizzata l’esperienza
di laboratorio, si può affermare che, per la visione della TV digitale a definizione
standard 720 x 576 pixel, utilizzando una scheda DVB-T budget, è sufficiente una
macchina con la seguente configurazione:
•
processore Pentium 3 a 733 MHz o equivalente,
•
128 MB di memoria di sistema,
•
scheda video con almeno 32 MB di memoria e
•
3 GB di spazio libero su disco.
Infine c’è da dire che, per ridurre il carico di lavoro della CPU in modo da abbassare
ulteriormente i requisiti minimi, è possibile compiere due scelte opposte. La prima
consiste nel considerare l’acquisto di una scheda Full Featured in alternativa a quella di
tipo Budget. Questa soluzione infatti, grazie al decoder MPEG hardware, alleggerirebbe
di molto il lavoro del processore perché il flusso video, che viene fornito dalla
periferica, è già decodificato. Queste schede però, vendute ad un prezzo che si aggira
attorno ai 150-200 Euro, sono molto più costose sia delle schede budget che dei
tradizionali set-top box che si collegano alla TV. Per questo il loro acquisto non è
conveniente e di conseguenza queste periferiche sono difficili da trovare sul mercato.
La seconda soluzione possibile è quella di dotarsi di una scheda video con chip per la
decodifica hardware del flusso MPEG. Queste schede video, come la Dxr3 o la
Hollywood plus prodotte da Creative e Sigma, venivano vendute in passato insieme ai
primi lettori DVD per supportare i processori più lenti nella codifica dell’MPEG-2.
Attualmente questi modelli, con l’avanzare della tecnologia, non sono più sul mercato
ma, grazie all’avvento dell’HDTV, sono in questo momento in commercio alcune
schede nuove che consentono la codifica del segnale ad alta definizione.
5.2 Vantaggi e limiti della tecnologia
La TV digitale ha il vantaggio di permettere la trasmissione di un numero maggiore di
programmi televisivi rispetto a quanto era invece possibile con la TV analogica. Questo
risolve, in pratica, il problema del sovraffollamento delle frequenze terrestri che non
permetteva, fino ad ora, la fondazione di nuovi canali televisivi. Con la stessa larghezza
di banda (7 o 8 MHz) infatti, è possibile trasmettere dai 4 ai 6 canali digitali al posto di
uno solo analogico. Ad esempio in Italia, come già illustrato nel Paragrafo 1.4.7, i
84
parametri di modulazione utilizzati consentono un flusso complessivo, per un singolo
canale, di circa 24 Mbit/s. Questo, grazie alla tecnica di multiplexing, può essere
suddiviso in 6 programmi da 4 Mbit/s, 4 programmi da 6 Mbit/s o qualsiasi altra
configurazione. Inoltre, dato che vengono utilizzate le stesse frequenze operative
dell’analogico, questo nuovo sistema risulta compatibile con il vecchio, quindi non
comporta la sostituzione degli apparati di trasmissione e ricezione come le antenne
domestiche direzionali di tipo Yagi o Log-periodiche.
La tecnologia digitale poi, grazie alla codifica in MPEG-2, consente una qualità delle
immagini nettamente superiore a quella dello standard analogico. Questa caratteristica è
particolarmente sentita in questi ultimi tempi in cui stanno prendendo piede i nuovi
televisori LCD ed al Plasma che garantiscono una definizione superiore ai normali CRT
(Catode Ray Tube). Proprio con questi apparati di ultima generazione si nota la
differenza che sussiste tra la TV tradizionale e il DVB, poiché, mentre con la prima si
notano disturbi e interferenze tra i canali, con il digitale terrestre invece, una volta che
l’intensità del segnale ha superato la soglia di ricezione, la qualità del video rimane
costante ed insensibile a disturbi esterni. In realtà, nei normali ricevitori l’uscita è
sempre dello standard PAL o NTSC, quello dalla tv analogica, ma questa può essere
sfruttata al massimo della qualità possibile.
Un ulteriore vantaggio della tv digitale terrestre riguarda la trasmissione del segnale. Il
DVB-T, infatti, necessita di una potenza di emissione inferiore per coprire la stessa
distanza raggiungibile con il segnale analogico. Questo consente una riduzione del
numero delle stazioni di trasmissione, con la conseguente diminuzione dei costi e
dell’inquinamento elettromagnetico. Oltretutto, grazie alla modulazione digitale
COFDM è possibile realizzare reti di diffusione a isofrequenza. Si può cioè utilizzare lo
stesso canale di trasmissione per aree adiacenti, senza che insorgano disturbi ed
interferenze. Questa ultima caratteristica consente anche di migliorare la copertura in
zone difficili da raggiungere, come valli e gallerie, utilizzando i Gap Filler. Questi
dispositivi sono dei piccoli ripetitori, a bassa potenza, che ricevono il segnale e lo
ritrasmettono alla stesa frequenza, senza quindi occupare bande aggiuntive.
Venendo ora al progetto vero e proprio, si può dire che l’utilizzo di una scheda TV da
installare in un PC, al posto di un set-top box collegato direttamente ad uno schermo
televisivo, consente di sfruttare tutte le potenzialità hardware e software che un
85
computer può offrire, rispetto a quelle limitate dei decoder. I set-top box che vengono
venduti attualmente, infatti, non sono caratterizzati da una elevata qualità costruttiva e
di conseguenza offrono una ristretta capacità di calcolo e disponibilità di risorse. Questi
inoltre, sono sprovvisti di un sistema di memorizzazione permanente, come ad esempio
un hard disk, e ciò limita la personalizzazione e condizione le scelte per possibili
applicazioni future. Un sistema Ubuntu completo invece, anche se minimale, è dotato di
una potenza di calcolo che è di gran lunga superiore. Inoltre, con Linux, si ha un totale
controllo delle risorse della macchina e delle periferiche installate. È possibile infatti
effettuare numerosi test sul comportamento della scheda e sul segnale trasmesso,
analizzando sia i dati fisici che tutte le informazioni aggiuntive veicolate all’interno del
flusso MPEG. Questo garantisce quindi una piattaforma di studio, a basso costo, sullo
standard DVB-T.
Per quanto riguarda invece gli aspetti pratici, la presenza di un hard disk consente di
trasformare, ad un prezzo non troppo elevato, il PC in un Personal Video Recorder, in
grado di registrare e riprodurre, direttamente in formato digitale, tutto ciò che viene
trasmesso
dai
broadcaster
televisivi.
Inoltre,
collegando
alla
macchina
un
masterizzatore DVD, il sistema può funzionare anche da DVD Recorder, dotato di
caratteristiche superiori a quelli attualmente sul commercio, sia per quanto riguarda
l’hardware che il software. Ad esempio, su Linux esistono numerosi programmi che
forniscono la possibilità di authoring per i filmati. Va considerato poi che, una volta
interrotta la trasmissione in analogico, non sarà più possibile, con un solo decoder,
registrare un canale mentre se ne guarda un altro, a meno di non adottare un sistema
come questo.
Questa tecnologia, al momento, presenta però alcuni svantaggi. Il primo limite che si
incontra è la scarsa compatibilità delle schede TV con Linux. Tutti i maggiori
produttori, infatti, non forniscono alcun driver o firmware in grado di funzionare con
questo sistema operativo. È soltanto quindi grazie al lavoro svolto dalla comunità di
LinuxTV che è possibile utilizzare correttamente queste periferiche. La realizzazione di
driver compatibili con Linux però richiede tempo, quindi la maggior parte delle schede
nuove disponibili in commercio potrebbe non essere utilizzabile fino che non venga
realizzato un driver adeguato. L’acquisto della scheda TV si rivela così abbastanza
rischioso. Oltretutto, ogni scheda, se costituita da chip differenti, può avere una
86
procedura di installazione diversa da quella illustrata nel Paragrafo 4.3, che va poi
analizzata caso per caso.
Un aspetto controverso di questo progetto riguarda invece l’utilizzo di apparecchi di
ricezione attraverso dispositivi mobili. Cioè in pratica, si tratta di utilizzare schede TV,
di tipo USB, con computer portatili. Il tipo di modulazione adottata dal DVB-T, infatti,
consente la possibilità di ricezione mobile, anche ad alta velocità, senza le
problematiche che caratterizzavano le normali trasmissioni analogiche. Infatti, è
sufficiente che l’intensità del segnale sia al di sopra della soglia di ricezione e che i
cammini multipli cadano all’interno dell’intervallo di guardia, per garantire una qualità
costante delle immagini. Il problema però è che la copertura del digitale terrestre, in
molte zone d’Italia, non è ancora sufficiente da garantire una buona ricezione neanche
attraverso le normali antenne domestiche. Di conseguenza, le antenne portatili
unidirezionali, dotate di una capacità di ricezione nettamente inferiore rispetto a quelle
fisse, non consentono, di fatto, di vedere nulla, come dimostrato anche nel Paragrafo
4.4.3. Si è quindi di fronte ad un dilemma. Da un lato il passaggio al digitale consente
una sensibile riduzione della potenza di trasmissione. Dall’altro, se si vuole usufruire
della ricezione mobile, che costituisce un valore aggiunto di questa tecnologia, è
necessario di nuovo aumentare la potenza del segnale o adottare una modulazione più
robusta che limita però la banda disponibile, in termini di bit rate.
Un altro aspetto controverso riguarda l’interattività. Questa consiste in pratica, grazie
all’utilizzo di un decoder munito di canale di ritorno, nella possibilità di interagire
attraverso il telecomando, con l’emittente televisiva. L’interattività rappresenta uno dei
principali vantaggi dell’adozione della televisione digitale. Questo perché, mentre con
la televisione analogica era consentita soltanto la ricezione del segnale, il digitale,
adottando lo standard DVB-MHP, permette ad esempio di partecipare a programmi
televisivi, eseguire operazioni bancarie (T-Banking) ed usufruire di molti altri servizi
aggiuntivi offerti dall’emittente. La problematica però sta nel fatto che finora non esiste
uno stack MHP certificato per una macchina Linux. Esistono soltanto dei software che
emulano il funzionamento dell’MHP, come XleTView e OpenMHP, ma questi sono
unicamente delle implementazioni incomplete, che mancano di numerose funzionalità.
Con XleTView infatti, durante l’esperimento, non si sono raggiunti risultati degni di
nota. Questo perché il programma si comporta bene per piccole applicazioni di una o
87
più classi, ma presenta molte difficoltà con applicazioni più complesse, come sono
quelle trasmesse dalle emittenti televisive.
La motivazione della mancanza dell’MHP è da ricercarsi probabilmente nella debole
richiesta di mercato di questi dispositivi. Il sentimento di riluttanza, da parte degli
italiani, verso l’acquisto di un decoder per la televisione digitale terrestre si ripercuote,
infatti, anche nella vendita delle schede TV per PC. Questo è incentivato poi dalla
debole copertura del segnale, insufficiente per la ricezione con antenne portatili. È
verosimile che, in Italia, finché non verranno migliorati questi aspetti, il passaggio alla
nuova tecnologia digitale non potrà essere completato con successo. Di conseguenza il
sistema studiato in questa tesi ha, al momento, uno sbocco commerciale limitato. Detto
questo però, va considerato che, grazie anche all’avvento della televisione ad alta
definizione, il digitale rappresenta comunque il futuro delle trasmissioni terrestri, tanto
che il DVB Project sta già studiando un nuovo standard (DVB-T2), il cui ingresso sul
mercato è previsto per il 2009.
88
Appendice
PAT
-----------------------------------------------------------SECT-Packet: 00000001
PID: 0 (0x0000), Length: 44 (0x002c)
Time received: Mon 2007-09-17 10:33:54.725
-----------------------------------------------------------PID: 0 (0x0000) [= assigned for: ISO 13818-1 Program Association
Table (PAT)]
Guess table from table id...
PAT-decoding....
Table_ID: 0 (0x00) [= Program Association Table (PAT)]
section_syntax_indicator: 1 (0x01)
(fixed): 0 (0x00)
reserved_1: 3 (0x03)
Section_length: 41 (0x0029)
Transport_Stream_ID: 1 (0x0001)
Version_number: 1 (0x01)
current_next_indicator: 1 (0x01) [= valid now]
Section_number: 0 (0x00)
Last_Section_number: 0 (0x00)
Program_number: 0 (0x0000)
reserved: 7 (0x07)
Network_PID: 16 (0x0010)
Program_number: 3401 (0x0d49)
reserved: 7 (0x07)
Program_map_PID: 258 (0x0102)
Program_number: 3402 (0x0d4a)
reserved: 7 (0x07)
Program_number: 3403 (0x0d4b)
reserved: 7 (0x07)
[…]
Program_number: 3450 (0x0d7a)
reserved: 7 (0x07)
Program_map_PID: 700 (0x02bc)
CRC: 3883646850 (0xe77bbf82)
89
Appendice
NIT
PID: 16 (0x0010) [= assigned for: DVB Network Information Table
(NIT), Stuffing Table (ST)]
NIT-decoding....
Table_ID: 64 (0x40) [= Network Information Table (NIT) - actual
network]
Section_length: 140 (0x008c)
Network_ID: 418 (0x01a2) [= >>ERROR: not (yet) defined... Report!<<]
reserved_4: 15 (0x0f)
Network_descriptor_length: 5 (0x0005)
DVB-DescriptorTag: 64 (0x40) [= network_name_descriptor]
Descriptor_length: 3 (0x03)
Network_name: "Rai" -- Charset: Latin alphabet
Transport_stream_loop_length: 122 (0x007a)
[…]
Transport_stream_ID: 1 (0x0001)
Original_network_ID: 318 (0x013e) [= Eutelsat Satellite System
13°E | European Telecommunications Satellite Organization]
Transport_descriptor_length: 62 (0x003e)
DVB-DescriptorTag: 65 (0x41) [= service_list_descriptor]
service_ID: 3401 (0x0d49)[ --> refers to PMT
program_number]
service_type: 1 (0x01) [= digital television service]
service_ID: 3402 (0x0d4a)[ --> refers to PMT
program_number]
service_ID: 3403 (0x0d4b)[ --> refers to PMT
program_number]
program_number]
90
Appendice
service_type: 1 (0x01)
[= digital television service]
service_ID: 3314 (0x0cf2)[ --> refers to PMT
program_number]
service_type: 2 (0x02) [= digital radio sound service]
service_ID: 3450 (0x0d7a)[ --> refers to PMT
program_number]
program_number]
DVB-DescriptorTag: 90 (0x5a) [=
terrestrial_delivery_system_descriptor]
Descriptor_length: 11 (0x0b)
Center frequency: 0x000186a0 (= 1000.000 kHz)
Bandwidth: 1 (0x01) [= 7 MHz]
priority: 1 (0x01) [= HP (high priority)]
Time_Slicing_indicator: 1 (0x01) [= Time Slicing is not
used.)]
MPE-FEC_indicator: 1 (0x01) [= MPE-FEC is not used.)]
Constellation: 2 (0x02) [= 64-QAM]
Hierarchy information: 0 (0x00) [= non-hierarchical]
Code_rate_HP_stream: 1 (0x01) [= 2/3]
Code_rate_LP_stream: 0 (0x00) [= 1/2]
Guard_interval: 0 (0x00) [= 1/32]
Transmission_mode: 1 (0x01) [= 8k mode]
Other_frequency_flag: 0 (0x00)
reserved_2: 4294967295 (0xffffffff)
DVB-DescriptorTag: 131 (0x83)
[= User defined/ATSC
reserved]
Descriptor-data:
0000: 0d 49 fc 01 0d 4a fc 02
13
.I...J...K...R..
0010: 0d 79 fc 14 0d 7a fc 15
.y...z..
CRC: 4073960607 (0xf2d3b49f)
91
0d 4b fc 03 0d 52 fc
Appendice
SDT
PID: 17 (0x0011) [= assigned for: DVB Service Description Table
(SDT), Bouquet Association Table (BAT)]
SDT-decoding....
Table_ID: 66 (0x42) [= Service Description Table (SDT) - actual
transport stream]
Section_length: 159 (0x009f)
Transport_Stream_ID: 1 (0x0001)
Original_network_ID: 318 (0x013e) [= Eutelsat Satellite System 13°E
| European Telecommunications Satellite Organization]
reserved_4: 255 (0xff)
Service_id: 3401 (0x0d49) [= --> refers to PMT program_number]
EIT_schedule_flag: 0 (0x00)
EIT_present_following_flag: 1 (0x01)
Running_status: 4 (0x04) [= running]
Free_CA_mode: 0 (0x00) [= unscrambled]
Descriptors_loop_length: 14 (0x000e)
DVB-DescriptorTag: 72 (0x48) [= service_descriptor]
Descriptor_length: 12 (0x0c)
service_provider_name_length: 3 (0x03)
service_provider_name: "RAI" -- Charset: Latin alphabet
service_name_length: 6 (0x06)
Service_name: "RaiUno" -- Charset: Latin alphabet
Service_id: 3402 (0x0d4a) [= --> refers to PMT program_number]
92
Appendice
Service_name: "RaiDue" -- Charset: Latin alphabet
Service_id: 3403 (0x0d4b) [= --> refers to PMT program_number]
Service_name: "RaiTre" -- Charset: Latin alphabet
Service_id: 3410 (0x0d52) [= --> refers to PMT program_number]
Descriptors_loop_length: 16 (0x0010)
Descriptor_length: 14 (0x0e)
Service_name: "RaiUtile" -- Charset: Latin alphabet
[…]
CRC: 4859909 (0x004a2805)
93
Appendice
EIT
dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/
-----------------------------------------------------------SECT-Packet: 00000004
PID: 18 (0x0012), Length: 59 (0x003b)
-----------------------------------------------------------PID: 18 (0x0012) [= assigned for: DVB Event Information Table (EIT)]
EIT-decoding....
Table_ID: 78 (0x4e) [= Event Information Table (EIT) - actual
transport stream, present/following]
Service_ID: 3401 (0x0d49) [= --> refers to PMT program_number]
Transport_stream_ID: 1 (0x0001)
Original_network_ID: 318 (0x013e) [= Eutelsat Satellite System 13°E |
European Telecommunications Satellite Organization]
Segment_last_Section_number: 1 (0x01)
Last_table_id: 78 (0x4e) [= Event Information Table (EIT) - actual
transport stream, present/following]
Event_ID: 5922 (0x1722)
Start_time: 0xd458085000 [= 2007-09-17 08:50:00 (UTC)]
Duration: 0x0000959 [= 00:09:59 (UTC)]
Running_status: 0 (0x00) [= undefined]
Descriptors_loop_length: 29 (0x1d)
DVB-DescriptorTag: 77 (0x4d) [= short_event_descriptor]
Descriptor_length: 27 (0x1b)
ISO639_2_language_code: ita
event_name_length: 22 (0x16)
event_name: "Appuntamento al cinema" -- Charset: Latin
alphabet
text_length: 0 (0x00)
text_char: ""
CRC: 2335101803 (0x8b2ed36b)
94
Appendice
TDT
-----------------------------------------------------------SECT-Packet: 00000002
PID: 20 (0x0014), Length: 29 (0x001d)
-----------------------------------------------------------0000: 73 70 1a d4 58 08 45 39 f0 0f 58 0d 49 54 41 02
sp..X.E9..X.ITA.
0010: 02 00 d4 81 01 00 00 01 00 d7 7f 60 44
...........`D
PID: 20 (0x0014) [= assigned for: DVB Time and Date Table (TDT),
Time Offset Table (TOT)]
TOT-decoding....
Table_ID: 115 (0x73) [= Time Offset Table (TOT)]
Section_length: 26 (0x001a)
UTC_time: 0xd458084539 [= 2007-09-17 08:45:39 (UTC)]
Descriptors_loop_length: 15 (0x000f)
DVB-DescriptorTag: 88 (0x58) [= local_time_offset_descriptor]
Descriptor_length: 13 (0x0d)
Country_code: ITA
Country_region_ID: 0 (0x00)
local_time_offset_polarity: 0 (= plus to UTC)
Local_time_offset: 02:00
Time_of_change: 0xd481010000 [= 2007-10-28 01:00:00 (UTC)]
Next_time_offset: 01:00
CRC: 3615449156 (0xd77f6044)
95
Appendice
PMT 258
PID: 258 (0x0102)
PMT-decoding....
Table_ID: 2 (0x02) [= Program Map Table (PMT)]
(fixed '0'): 0 (0x00)
Section_length: 266 (0x010a)
Program_number: 3401 (0x0d49)
PCR PID: 512 (0x0200)
Program_info_length: 0 (0x0000)
Stream_type loop:
Stream_type: 2 (0x02) [= ITU-T Rec. H.262 | ISO/IEC 13818-2 Video
| ISO/IEC 11172-2 constr. parameter video stream]
Elementary_PID: 512 (0x0200)
ES_info_length: 5 (0x0005)
MPEG-DescriptorTag: 2 (0x02) [= video_stream_descriptor]
multiple_frame_rate_flag: 1 (0x01)
frame_rate_code: 3 (0x0003)
MPEG_1_only_flag: 0 (0x00)
constrained_parameter_flag: 1 (0x01)
still_picture_flag: 0 (0x00)
Stream_type: 3 (0x03) [= ISO/IEC 11172 Audio]
Elementary_PID: 650 (0x028a)
MPEG-DescriptorTag: 10 (0x0a) [=
ISO_639_language_descriptor]
ISO639_language_code: ITA
Audio_type: 0 (0x00) [= undefined]
Stream_type: 11 (0x0b)
[= ISO/IEC 13818-6 DSM-CC U-N Messages]
96
Appendice
Elementary_PID: 2001 (0x07d1)
ES_info_length: 14 (0x000e)
stream_identifier_descriptor]
component_tag: 4 (0x04)
MPEG-DescriptorTag: 19 (0x13)
carousel_identifier_descriptor]
Carousel_id: 1 (0x00000001)
format_id: 0 (0x00)
[=
[=
DVB-DescriptorTag: 102 (0x66) [=
data_broadcast_id_descriptor]
Data_broadcast_ID: 240 (0x00f0) [= MHP Object Carousel]
[…]
Stream_type: 6 (0x06) [= ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES
packets containing private data]
Elementary_PID: 576 (0x0240)
DVB-DescriptorTag: 86 (0x56) [= teletext_descriptor]
Teletext_type: 1 (0x01) [= initial teletext page]
Teletext_magazine_number: 1 (0x01)
Teletext_page_number: 0 (0x00)
Stream_type: 5 (0x05) [= ITU-T Rec. H.222.0 | ISO/IEC 13818-1
private sections]
Elementary_PID: 3010 (0x0bc2)
stream_identifier_descriptor]
component_tag: 14 (0x0e)
DVB-DescriptorTag: 111 (0x6f)
application_signalling_descriptor]
CRC: 2583213138 (0x99f8b452)
97
[=
[=
Appendice
AIT
PID: 3010 (0x0bc2)
AIT-decoding....
Table_ID: 116 (0x74) [= MHP- Application Information Table (AIT)]
Section_syntax_indicator: 1 (0x01)
section_length: 337 (0x0151)
test_application_flag: 0 (0x00)
application_type: 1 (0x0001) [= DVB-J application]
Current_next_indicator: 1 (0x01) [= valid now]
Last_section_number: 0 (0x00)
common_descriptors_length: 0 (0x0000)
application_loop_length: 324 (0x0144)
organisation_id: 1 (0x00000001)
appliction_id: 0 (0x0000) [= unsigned applications]
application_control_code: 1 (0x01) [= AUTOSTART]
reserved: 15 (0x0f)
application_descriptor_loop_length: 114 (0x0072)
MHP_AIT-DescriptorTag: 2 (0x02) [= Transport protocol
descriptor]
protocol_id: 1 (0x0001) [= MHP Object Carousel]
transport_protocol_label: 0 (0x00)
remote_connection: 0 (0x00)
reserved: 127 (0x7f)
component_tag: 5 (0x05)
MHP_AIT-DescriptorTag: 0 (0x00) [= Application descriptor]
application_profile_length: 5 (0x05)
application_profile: 1 (0x0001)
version.major: 1 (0x01)
version.minor: 0 (0x00)
version.micro: 2 (0x02)
service_bound_flag: 0 (0x00)
visibility: 3 (0x03) [= application visible to user and appl.
listening api]
reserved: 31 (0x1f)
application_priority: 0 (0x00)
98
Appendice
transport_protocol_label: 0 (0x00)
MHP_AIT-DescriptorTag: 1 (0x01) [= Application name
descriptor]
application_name_length: 12 (0x0c)
application_name: "RaiLauncher" -- Charset: Latin
alphabet no. 5
MHP_AIT-DescriptorTag: 3 (0x03)
descriptor]
Descriptor_length: 26 (0x1a)
parameter_length: 3 (0x03)
Parameter: "Rai"
Parameter: "1"
Parameter: "20000"
Parameter: "6 7"
Parameter: "UCT debug"
[= DVB-J application
MHP_AIT-DescriptorTag: 4 (0x04) [= DVB-J application location
descriptor]
base_directory_length: 19 (0x13)
base_directory: "/ApplicationManager"
classpath_extension_length: 0 (0x00)
classpath_extension: ""
initial_class: "tv.simple.launcher.Launcher"
[…]
CRC: 451945869 (0x1af0258d)
99
Appendice
Televideo
Packet_start_code_prefix: 0x000001
Stream_id: 189 (0xbd) [= private_stream_1]
PES_packet_length: 1282 (0x0502)
reserved1: 2 (0x02)
PES_scrambling_control: 0 (0x00) [= not scrambled]
PES_priority: 0 (0x00)
data_alignment_indicator: 1 (0x01)
copyright: 0 (0x00)
original_or_copy: 1 (0x01)
PTS_DTS_flags: 2 (0x02)
ES_rate_flag: 0 (0x00)
additional_copy_info_flag: 0 (0x00)
PES_CRC_flag: 0 (0x00)
PES_extension_flag: 0 (0x00)
PES_header_data_length: 36 (0x24)
PTS:
Fixed: 2 (0x02)
PTS:
bit[32..30]: 2 (0x02)
marker_bit: 1 (0x01)
bit[29..15]: 1250 (0x04e2)
bit[14..0]: 12253 (0x2fdd)
==> PTS: 2188455901 (0x82712fdd) [= 90 kHz-Timestamp:
6:45:16.176]
stuffing bytes:
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
...............
PES_data (private_stream_1):
EBU data:
data_identifier: 16 (0x10) [= EBU data EN 300 472
(teletext)]
…
data_unit_id: 2 (0x02) [= EBU Teletext non-subtitle data]
data_unit_length: 44 (0x2c)
Teletext data:
reserved: 3 (0x03)
field_parity: 1 (0x01)
line_offset: 13 (0x0d)
frame_coding: 228 (0xe4) [= EBU Teletext]
=> decoded:
magazine number (X): 7 (0x07)
packet number (Y): 5 (0x0005) [= normal packet
intended for direct display]
packet data (parity stripped):
0000: 07 20 20 20 4f 67 67 69 20 07 44 6f 6d
100
Appendice
61 6e 69
74 69 17
.
Oggi .Domani
0010:
.Versanti.
0020:
20 20 20 20 20 20 03 56
65 72 73 61 6e
23 23 20 20 20 20 20 20
##
Teletext data:
reserved: 3 (0x03)
line_offset: 14 (0x0e)
=> decoded:
0000: 14 3c 2c 03 37 30 32 14 2c 2c 03 37 30
33 14 2c
.<,.702.,,.703.,
0010: 24 1d 03 41 6c 70 69 20 65 20 56 61 6c
70 61 64
$..Alpi e Valpad
0020: 61 6e 61 20 20 20 20 20
ana
Teletext data:
reserved: 3 (0x03)
line_offset: 15 (0x0f)
=> decoded:
0000: 14 35 20 03 37 30 34 20 07 20 03 37 30
35 14 20
.5 .704 . .705.
0010: 20 1d 03 4c 69 67 75 72 65 20 65 20 54
69 72 72
..Ligure e Tirr
0020: 65 6e 69 63 6f 20 20 20
enico
[…]
101
Appendice
CAT
dvbsnoop V1.4.00 -- http://dvbsnoop.sourceforge.net/
-----------------------------------------------------------SECT-Packet: 00000001
PID: 1 (0x0001), Length: 35 (0x0023)
-----------------------------------------------------------0000: 01 b0 20 ff ff cb 00 00 09 04 18 04 e5 78 09 04
..
..........x..
0010: 18 03 e5 78 09 09 01 00 e1 2b 01 e1 2c 00 b1 37
...x.....+..,..7
0020: ca 0e bc
...
PID: 1 (0x0001) [= assigned for: ISO 13818-1 Conditional Access
Table (CAT)]
CAT-decoding....
Table_ID: 1 (0x01) [= Conditional Access Table (CAT)]
(fixed): 0 (0x00)
reserved_2: 262143 (0x3ffff)
MPEG-DescriptorTag: 9 (0x09) [= CA_descriptor]
CA_system_ID: 6148 (0x1804) [= Kudelski SA]
reserved: 7 (0x07)
CA_PID: 1400 (0x0578)
CA_system_ID: 6147 (0x1803) [= Kudelski SA]
reserved: 7 (0x07)
CA_PID: 1400 (0x0578)
CA_system_ID: 256 (0x0100) [= Canal Plus (Seca/MediaGuard)]
reserved: 7 (0x07)
CA_PID: 299 (0x012b)
Private Data:
0000: 01 e1 2c 00 b1
..,..
CRC: 935988924 (0x37ca0ebc)
102
Bibliografia
[1]
DVB Project, http://www.dvb.org
[2]
Ars Docendi, http://www.ars-docendi.de
[3]
ETSI EN 300 744, Digital Video Broadcasting (DVB); Framing structure,
channel coding and modulation for digital terrestrial television
[4]
Wikipedia, http://www.wikipedia.org
[5]
Dfree, http://www.dfree.tv
[6]
LinuxTV Project, http://www.linuxtv.org
[7]
Dvbsnoop, http://dvbsnoop.sourceforge.net
[8]
ASUSTeK Computer Inc., http://www.asus.com
[9]
Terratec Electronic GmbH, http://www.terratec.net
[10]
NXP Semiconductors, http://www.nxp.com
[11]
Ubuntu, http://www.ubuntu.com
[12]
Associazione DGTVi, http://www.dgtvi.it
[13]
AGCOM (Autorità per le Garanzie nelle Telecomunicazioni), Il Libro Bianco
sulla televisione digitale terrestre
103
Bibliografia
[14]
ETSI EN 300 468, Digital Video Broadcasting (DVB); Specification for Service
Information (SI) in DVB systems
[15] MHP, http://www.mhp.org
[16] Interactive TV Web, http://www.interactivetvweb.org
104

Capitolo 1 - AIRT Lab - Università Politecnica delle Marche

Transcript

Documenti analoghi

decoder mpeg2- 4 hdtv

Diagnostica preimpianto I

DVB-H e SH Mobile TV - Rai - Centro Ricerche e Innovazione

Annuario 2013-2014 - Rai - Centro Ricerche e Innovazione

Lo Standard USB - Home page sito web prof. Cleto Azzani

Powerline

Introduzione ai fogli di stile CSS